Bug#1064343: tput sgr0 adds uncalled-for codes

[Adam Borowski]

On Tue, Feb 20, 2024 at 07:41:42PM +0100, Sven Joachim wrote:
> > On Tue, Feb 20, 2024 at 04:15:30PM +0800, Paul Wise wrote:
> >>$ tput sgr0 | hd
> >>  1b 28 42 1b 5b 6d |.(B.[m|
> >
> > Here's the culprit.  The code you asked for is "\e[0m" -- shortenable to
> > non-canonical but valid "\e[m", which is the second half of tput's output.
> >
> > What you did not ask for, is "\e(B", which is not allowed in UTF-8 mode,
> > and in non-Unicode world would switch to an ancient "US" charset.
> 
> Maybe that is true for the Linux console, but we are talking about xterm
> here.

It's not a property of the terminal, but of ECMA-35.

And what "xterm" are you talking about?  tput has no way to know the
terminal on the other side, as the string TERM=xterm (and
TERM=xterm-256color) applies to over a hundred different terminals using
tens of different code bases.  And you can't even blame their authors, as:
 * most Unices stopped maintaining their terminfo databases (eg. Solaris
   still hasn't learned about TERM=linux.  Solaris is no longer relevant now
   but was relevant for most of that time frame.)
 * even if the databases were maintained, a new terminal would become useful
   only several years after it gets released (as the terminfo entry would
   need to be deployed on every box you might possibly ssh into, with
   failure mode being complete breakage of any terminfo-using program)
Thus, putting aside historic terminals, there are only three TERM values:
 * linux
 * rxvt (used by its derivatives like aterm)
 * xterm (everything else)
(Skipping decorations like -256color which most programs hard-code anyway. 
I thus had to implement 256 color fallbacks in the kernel in 2016; it seems
that eg. 24-bit color is moving the same way.)

> > Putting aside arguments if this code is allowed or not (eg. the author of
> > Putty has strong feelings on the matter), it's very clearly not what you
> > asked for, thus the real bug is on tput's side.

> > Thus:
> > "tput sgr0" should produce sgr0, not setusg0 sgr0.
> 
> It does of course produce sgr0, i.e. it emits whatever escape sequence
> $TERM's terminfo entry declares as sgr0.  In the case of xterm-256color,
> sgr0=\E(B\E[m.

And it's that entry what's wrong.  sgr0 means "\e[0m" (or "\e[m"); see
eg. docs for real xterm: https://www.xfree86.org/current/ctlseqs.html

> 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.

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

> People are relying on this behavior, see #595484 for instance.

Seems like an XKCD 1172 case.

> 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.

I'll work around this misbehaviour (as it's no extra work for me: I need
to handle legitimately occuring G0/G1 changes anyway).  Still, it is a bug
even if its severity is negligible: thanks to PuTTY's author's stubborness
no maintained software uses G0/G1 anymore.

Thus, the only real fallout is bloating terminal output.  It's still too
slow on serial links or inferior terminals (I felt bad about Scaleway's
web console just hours ago); saving three bytes per sgr0 is not much but
it is a very frequently used sequence.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄

Bug#1064341: colorized-logs: ansi2txt/ansi2html turn sgr0 into B instead of empty string

[Adam Borowski]

Control: clone -1 -2
Control: retitle -2 tput sgr0 adds uncalled-for codes
Control: reassign -2 ncurses-bin

On Tue, Feb 20, 2024 at 04:15:30PM +0800, Paul Wise wrote:
> ansi2txt/ansi2html turn sgr0 into 'B' instead of an empty string.

>$ echo $TERM 
>xterm-256color
> 
>$ tput sgr0 | hd
>  1b 28 42 1b 5b 6d |.(B.[m|

Here's the culprit.  The code you asked for is "\e[0m" -- shortenable to
non-canonical but valid "\e[m", which is the second half of tput's output.

What you did not ask for, is "\e(B", which is not allowed in UTF-8 mode,
and in non-Unicode world would switch to an ancient "US" charset.

Putting aside arguments if this code is allowed or not (eg. the author of
Putty has strong feelings on the matter), it's very clearly not what you
asked for, thus the real bug is on tput's side.

I'm reassigning to ncurses-bin as I believe that terminfo is merely an
implementation detail here -- and a grossly obsolete one as the very concept
of terminfo has stopped working by mid-1980's -- but ncurses-bin and
ncurses-base come from the same source package so this hardly matters.

Thus:
"tput sgr0" should produce sgr0, not setusg0 sgr0.

---

There's a second bug, though, this time on my side:

>$ tput sgr0 | ansi2txt ; echo
>B
>
>$ tput sgr0 | ansi2html --no-header
> style="color:#bbb;white-space:pre-wrap;word-wrap:break-word;overflow-wrap:break-word">B

When the text being parsed contains G0/G1 settings, whether intentional or
not, they should be recognized and either implemented or ignored. ansi2txt
promises to remove all ANSI codes, not merely ones that would make sense in
the given context.

It's probably not worth the effort to implement charset conversions anymore
as non-Unicode is thoroughly dead by now; I'll thus ignore these codes.

I guess other codes should be looked at, too...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1061076: kbtin: FTBFS with stack-clash-protection on armhf due to valgrind segfault

[Adam Borowski]

On Wed, Jan 17, 2024 at 04:29:10PM +0100, Emanuele Rocca wrote:
> Source: kbtin
> Severity: serious
> Usertags: 32bit-stackclash

> kbtin currently fails to build from source on armhf. The failure is due
> to an incompatibility between valgrind and stack-clash-protection on
> 32bit arm reported upstream at:
> https://bugs.kde.org/show_bug.cgi?id=479699

Thanks for the report (and fix).  I've applied it in git.  However... during
testing, while the package now builds fine on armhf (and armel amd64 ...),
I see it makes valgrind crash on arm64 with:

Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92
valgrind: m_debuginfo/readdwarf.c:2822 (copy_convert_CfiExpr_tree): Assertion 
'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

and likewise this doesn't appear to be a problem with kbtin itself -- it's
just a regular C program that does nothing weird.

While these bugs are unrelated (other than both being failures due to
valgrind not liking new toolchains), it makes no sense to upload the fix
right now.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on
⢿⡄⠘⠷⠚⠋⠀ the maternity ward.
⠈⠳⣄

Bug#1054607: btrfs-progs: btrfs prop set causing system to reboot

[Adam Borowski]

On Thu, Oct 26, 2023 at 08:00:20PM +0300, a...@me.com wrote:
> Package: btrfs-progs

The bug in question is in the kernel, not in btrfs-progs (but see below).

> sudo find "/dev/snd" -exec btrfs prop set {} compression zstd \;
> Causing stuck on /dev/snd/pcmC1D0p file and insta reboots in 5 mins.
> ls -al /dev/snd/pcmC1D0p
> crw-rw+ 1 root audio 116, 5 окт 26 19:37 /dev/snd/pcmC1D0p

This is very clearly not a btrfs filesystem.  The driver associated with
the device in question (ie, your sound card) should either accept the
request or cleanly reject it, not crash the whole machine.

If you could say what driver is responsible for the sound card in your
machine, it'd be possible to fix the crash.  This information can be found
eg. in /proc/asound/cards or other files there.

What btrfs-progs are doing here is setting an xattr named btrfs.compression
(with a value that you provide); unlike ioctls which are at risk of having
a different meaning for an unrelated device, that xattr is cleanly
namespaced.  Thus, my guess is that your sound card's driver will crash
for any xattr whose name it doesn't understand.

You don't need btrfs-progs to reproduce that, you could set the xattr
directly (via the setfattr command), copy it via some backup tool (rsync
in particular teaches people to use -X or lose the ability to use /bin/ping
etc), etc.  And this is (kind of) an unprivileged operation...


The real bug aside, there's a question whether btrfs-progs should protect
the user and fstatfs() every file it processes.  That could be reasonable
but could break remote filesystems from transporting this setting (I don't
know if they do).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up.  This
⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project.
⠈⠳⣄

Bug#1057295: bcachefs-tools: breaks "mount" if the package is installed

[Adam Borowski]

Package: bcachefs-tools
Version: 24+really1.3.4-1
Severity: important

If bcachefs-tools is installed, "mount" fails to mount any bcachefs
filesystems, saying:

.
Unknown command /dev/nvme0n1p2
bcachefs - tool for managing bcachefs filesystems
usage: bcachefs  []

Superblock commands:
  format   Format a new filesystem
  show-super   Dump superblock information to stdout
  set-option   Set a filesystem option
[... (eleventy lines of help snipped)]
`

Conversely, if the package is _not_ installed, everything goes fine.
Stracing "mount", I see that it tries to run /sbin/mount.bcachefs (which
is symlinked to "bcachefs") if it exists.

The culprit is:
.--[ bcachefs.c ]
#ifndef BCACHEFS_NO_RUST
if (strstr(full_cmd, "mount"))
return cmd_mount(argc, argv);
#endif

...

#ifndef BCACHEFS_NO_RUST
if (!strcmp(cmd, "mount"))
return cmd_mount(argc, argv);
if (strstr(cmd, "completions"))
return cmd_completions(argc, argv);
#endif
`

Ie, the "mount" subcommand (both invoked explicitly and via argv[0]) is not
compiled in our current package.  It's not actually needed for basic operation
(the default logic in /sbin/mount is good enough), but if the helper exists,
"mount" will abort if it the helper fails.

I found it puzzling that no one reported this, quite fatal, bug in two weeks
since your upload (I for one have been away from this machine for a while).
However, it turns out systemd does not use this helper but reinvents it
(expect incompatible ways of handling options, but I digress).  This means,
out of 21 popcon votes, most folks had boot-time mount succeed, while only
manual mount would fail.

In other words:
 ✓ boot-time via systemd
 ✗ boot-time via initscripts
 ✗ manual via "mount"

A simple workaround would be to just drop the /sbin/mount.bcachefs symlink
until rust pieces are back.  But alas, I see that the helper is needed for
handling UUID= stanzas.  A typical person would say /dev/nvme0n1p2 while
d-i prefers PARTUUID= thus that'd _usually_ work... but still not ideal.

On the other hand, at least UUID= has never worked for bcachefs on Debian,
thus at least that part is no regression.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (666, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.0-rc5-mithlond-02787-gf0f2365d02d9 (SMP w/4 CPU threads; 
PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages bcachefs-tools depends on:
ii  libaio1   0.3.113-5
ii  libblkid1 2.39.2-6
ii  libc6 2.37-12
ii  libkeyutils1  1.6.3-2
ii  liblz4-1  1.9.4-1
ii  libsodium23   1.0.18-1
ii  liburcu8  0.14.0-2
ii  libuuid1  2.39.2-6
ii  libzstd1  1.5.5+dfsg2-2
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages bcachefs-tools recommends:
ii  initramfs-tools [linux-initramfs-tool]  0.142

bcachefs-tools suggests no packages.

-- no debconf information

Bug#1052058: apt: refuses to downgrade itself to a version that works on the system

[Adam Borowski]

Package: apt
Version: 2.7.5
Severity: important


Once again we have a package that some people consider broken.  That's
natural, disagreements happen.  That apt insists on a bad scheme not
supported by dpkg has been said about elsewhere.  Normally, that would
be solvable by a simple downgrade.

Except, in this case, apt refuses to do this:

# apt install apt=2.7.3 apt-utils=2.7.3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  apt-doc
The following packages will be DOWNGRADED:
  apt apt-utils
0 upgraded, 0 newly installed, 2 downgraded, 0 to remove and 2 not upgraded.
E: /bin resolved to a different inode than /usr/bin
E: Unmerged usr is no longer supported, install usrmerge to continue.
N: See 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#a-merged-usr-is-now-required
 for more details.

As you can see, the action I requested specifically solves the problem,
yet apt considers it no good.  Thus, I'd need to take steps that are not
obvious to a regular user, and for this specific package risky to break the
system if done wrong.

Thus, apt should consider an operation that touches apt itself to be
another exception for the usrmerge demand.


Meow!
-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "et

Bug#1051959: RFP: itd -- daemon to control watches running InfiniTime (such as PineTime)

[Adam Borowski]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: kilob...@angband.pl

* Package name: itd
  Upstream Contact: Arsen Musyaelyan 
* URL : https://gitea.elara.ws/Elara6331/itd
* License : GPL3
  Programming Lang: Go :(
  Description : daemon to control watches running InfiniTime (such as 
PineTime)

InfiniTime is a daemon to connect to and control watches running InfiniTime
(currently PineTime but it's open hardware).  It can update time, relay
messages, send weather/navigation/files, receive music control, do firmware
upgrades, and more.



(There's also an optional GUI, but even upstream packages don't ship it, and
I haven't tried it.)

Alas, this piece of software is written in an unholy language I've learned
to stay away from, thus I can't package this myself.  Requesting then...

Bug#1051948: irssi: no indication that you're scrolled up

[Adam Borowski]

Package: irssi
Version: 1.4.4-1
Severity: normal
X-Debbugs-Cc: kilob...@angband.pl

Hi!
If you use PgUp to scroll up, there is no visual indication of any kind
that what you're seeing is not the most recent data.  This notoriously leads
to responding to days old stuff, etc -- especially if you're an inattentive
oaf like me.  Unlike most other programs with such a kind of display,
switching off a window and back to it doesn't scroll you to the bottom;
such a position persistence is likely to make you forget that you've scrolled.

Possible ideas:
 * (like I did in kbtin): the input bar replaced with a line of ^
 * (like in zMud): split window with a few lines on the bottom showing what
   is going on
 * an extra indicator on the edge of the status bar


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (250, 'unstable'), (201, 'experimental')
merged-usr: no
Architecture: arm64 (aarch64)

Kernel: Linux 6.4.0-4-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages irssi depends on:
ii  libc6   2.37-7
ii  libglib2.0-02.78.0-1
ii  libperl5.36 5.36.0-7
ii  libssl3 3.0.10-1
ii  libtinfo6   6.4+20230625-2
ii  perl5.36.0-7
ii  perl-base [perlapi-5.36.0]  5.36.0-7

irssi recommends no packages.

Versions of packages irssi suggests:
pn  irssi-scripts  

-- no debconf information

Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field

[Adam Borowski]

On Sat, Sep 09, 2023 at 02:53:00PM -0700, Russ Allbery wrote:
> Samuel Thibault  writes:
> > Architecture: !s390 !s390x
> > Architecture: !hppa !hurd-any !kfreebsd-any
> > Architecture: linux-any kfreebsd-any !hppa !m68k-any

> > which would be understood as [ (linux-any or kfreebsd-any) and not hppa
> > and not m68k-any ]. I.e. if no positive specification is set, an "any"
> > positive specification is assumed.

> > I guess support would be needed in dpkg, lintian, etc.

> I agree that this would be useful.  This has come up frequently over the
> years, and back when I was maintaining architecture-specific packages, the
> lack of this feature was often annoying.
> 
> But (as may be obvious from the long delay in even getting a response),
> Policy can't drive the implementation of this change and therefore
> probably isn't a good place to start with the request.  I think it would
> need to start with dpkg and ftp-master (for DAK).  I'm therefore probably
> going to have to close this bug against Policy as unactionable since I
> don't know of any efforts towards implementing this support, and Policy
> would only be able to change once the support is available.

Agreed, but it might be good to say "it would be good to have this",
and send a bug/mail to the relevant teams, asking if there are objections
before anyone spends work to implement this.

I for one have currently no less than three related ideas:
 * this
 * richer arch aliases (better than current dpkg aliases; could be
   implemented like shell foo-$@-bar word multiplication, thus linux-64bit
   would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind
   of shot before though
 * replacing explicit arch names in source packages by facets (like:
   x86, little-endian, sse2, time64, ...) that are expanded at build time;
   procrastiplanning to propose this

It's good to discuss such things -- if someone offers to implement such a
change.


> going to have to close this bug against Policy as unactionable since I
> don't know of any efforts towards implementing this support, and Policy
> would only be able to change once the support is available.

Could we oh so please have this as a policy policy in other cases, too?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Elemental clouds:
⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation)
⢿⡄⠘⠷⠚⠋⠀ • fire:  pyrocumulus (forestry, volcanism)
⠈⠳⣄ No known relations of clouds to air or water.

Bug#1051314: fonts-recommended: recognise noto-core as alternative to dejavu-core

[Adam Borowski]

On Sat, Sep 09, 2023 at 11:24:04PM +0200, Gunnar Hjalmarsson wrote:
> After our conversation I made two installs for test purposes:
> 
> 1. Debian 12 with GNOME
>Result: fonts-noto-core was not included by default.
> 
> 2. Debian trixie with GNOME
>Result: fonts-noto-core was included by default.
> 
> I suspect that the change can be explained by this commit:
> https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/5aa10dde

There's a lot of Debian outside GNOME -- and in fact, if you are already
using their metapackages, you don't need more.  I'd prefer for non-GNOME
metapackages to be universal, and thus what a particular desktop already
depends or does not depend on is not a concern for me.

Thus: OP's request is neither mooted nor vindicated by whatever GNOME does.

> > Alas, noto has the downside of making font pickers next to useless,
> > as it declares every single of languages it supports as a separate
> > font family. So instead off just "Noto Sans" "Noto Mono" "Noto
> > Slightly Serifed", you have "Noto Western Klingon" "Noto Eastern
> > Klingon" and so on, making the list of available fonts one big noto
> > fest.
> 
> If you assume that users often want to change much, I can understand that
> you see that as a disadvantage. OTOH, a user who wants to do it differently
> can uninstall fonts-noto-core and with that get a significantly shorter
> list.

Noted.  You don't care about fonts just whether a particular character is
covered, me and other people in the Fonts Team obviously have more interest
in distinct fonts.  That's the diff between eg. linguists vs layout
designers, different people have different priorities.

> Myself is involved in changing the default selection of fonts and font
> configuration for Ubuntu. In that context we focus on offering the users a
> sensible default

Aye!

> which most users are comfortable with, and the way Noto
> provides different fonts for different scripts and purposes is an advantage
> to achieve that Ubuntu is about to prefer Noto for most scripts, but to the
> extent exceptions proves to be motivated, that can be handled relatively
> easy via font configuration.

As this metapackage was written by me, I'm kind of concerned I use "royal
we" too much and say stuff about the opinions of Debian Fonts team more
than warranted -- but, with paragraph^^ above, perhaps the description and
the focus of this metapackage could be changed, to explicitly cater to a
different audience?  Having multiple metapackages do essentially the same
thing is kind of redundant.

> Something that would have been harder with
> DejaVu Sans as the preferred font.

DejaVu has a decent but not universal coverage; it's included on the list
more for technical legacy reasons, just like Windows-compatible fonts are.

> I have no firm opinion, at least not yet, on the role of fonts-recommended
> and whether the proposed change is motivated. But I just posted a list
> message about the ongoing transition from DejaVu to Noto, to reach a broader
> audience:

> https://lists.debian.org/debian-devel/2023/09/msg00053.html

I'm behind reading mailing lists, but I agree 100% with what other members
of the Fonts Team said.  Noto is ugly, a bit too disk heavy for 60% of
keyboard-attached boxen I use, and pollutes font lists too much.


Besides, Noto can be said to be a metapackage by itself, providing a large
set of fonts -- even if it claims to be a single font, it presents hundreds
of them to the system and UI interfaces.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Elemental clouds:
⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation)
⢿⡄⠘⠷⠚⠋⠀ • fire:  pyrocumulus (forestry, volcanism)
⠈⠳⣄ No known relations of clouds to air or water.

Bug#1051314: fonts-recommended: recognise noto-core as alternative to dejavu-core

[Adam Borowski]

On Wed, Sep 06, 2023 at 07:22:36AM +0100, Justin B Rye wrote:
> Package: fonts-recommended
> Version: 1
> Severity: wishlist

> Various major desktops now default to fonts-noto-core instead of
> fonts-dejavu-core.   During a conversation with a fontconfig-config
> maintainer on debian-l10n-english about the knock-on effects
> ("https://lists.debian.org/debian-l10n-english/2023/09/msg1.html";)
> I noticed that the dependency chains ensuring that fonts-noto-core is
> actually installed at all are surprisingly weak.
> 
> This font package used to be very nearly the only one I needed to have
> manually installed to ensure I got everything I was likely to want

Alas, noto has the downside of making font pickers next to useless, as
it declares every single of languages it supports as a separate font family.
So instead off just "Noto Sans" "Noto Mono" "Noto Slightly Serifed", you
have "Noto Western Klingon" "Noto Eastern Klingon" and so on, making the
list of available fonts one big noto fest.

Given that you can install Noto yourself if that is your choice, removing
any need for this metapackage, I don't quite see the point of declaring
an alternative.  On the other hand, Dejavu has the technical quirk of
having been taken for granted for so long by random pieces of software,
I'd rather not skip it.  Somehow despite Noto's ubiquity in the Android
world this is not the case for it, as software doesn't get ported (at least,
not without significant changes) between Android and regular OSes much.

I thus consider removing all (or most) alternatives here, and make this
metapackage a single opinionated set.  Alternatives are good for tasks/etc
where there's a serious downside to having them not installed -- for a
set of fonts, not so much.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
⠈⠳⣄

Bug#1049902: raspi-firmware on non-rpi arm64

[Adam Borowski]

gwolf wrote:
> The only risk I can think of is that the bug might still impact users of
> non-Raspberry ARM systems. However, the likelihood of having it installed is
> minor (due to the available hardware being different).

Given that the laptop I use on the DebConf right now has 100% likelihood of
having this firmware installed (because of no network otherwise), you might
want to test stuff on it.

On the other hand, while the package can't be removed nor upgraded without
manually messing with both the hook and the postinst, it couldn't be
installed in the first place without doing so as well, thus people are at
least aware.  Thus, my priority is in getting rid of raspi-only bits...

In any case, I'd be glad helping test -- and you can put your hands on
this box if you fancy so.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
⠈⠳⣄

Bug#1050650: eom: deletion fails with "Couldn't access trash."

[Adam Borowski]

Package: eom
Version: 1.26.0-2
Severity: normal

Hi!
When trying to delete a file, I get:

Error on deleting image IMG_12345678_1234_123_LL.jpg

Couldn't access trash.

In this particular case, the filesystem is mounted with jmtpfs, but I
guess this can happen for plenty other reasons.  What matters though, is
that if whatever place eom tries to stick Windows-style "trash" into
has a layout not expected by eom, it will refuse the deletion at all.

I'd expect to be able to continue.

As, unusually, I can actually test Windows' behaviour today (where you
copied this idea from), and there it doesn't block the action, instead
slightly changing the wording depending on the filesystem layout the image
resides on: "Do you want to" ... "move to trash" vs "delete" ... "?".

I also recall a system somewhere that skipped any smarts, and presented the
user with two menu entries: "move to trash", "delete".

I can't seem to find any related settings in eom's preferences, nor any
hidden but semi-obvious combinations like Shift-Del.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc5-00086-g156eb820897e (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  eom-common   1.26.0-2
ii  gir1.2-eom-1.0   1.26.0-2
ii  libatk1.0-0  2.49.90-5
ii  libc62.37-7
ii  libcairo21.16.0-7
ii  libexempi8   2.6.4-1
ii  libexif120.6.24-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.76.1-5
ii  libgl1   1.6.0-1
ii  libgl1-mesa-glx  23.1.3-1
ii  libglib2.0-0 2.77.2-1
ii  libgtk-3-0   3.24.38-4
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  libmate-desktop-2-17 1.26.1-1
ii  libpeas-1.0-01.36.0-2
ii  librsvg2-2   2.54.7+dfsg-2
ii  librsvg2-common  2.54.7+dfsg-2
ii  libx11-6 2:1.8.6-1
ii  libxml2  2.9.14+dfsg-1.3
ii  mate-desktop-common  1.26.1-1
ii  shared-mime-info 2.2-1
ii  webp-pixbuf-loader   0.2.4-2
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages eom recommends:
ii  libgdk-pixbuf2.0-bin  2.42.10+dfsg-1+b1

eom suggests no packages.

-- no debconf information

Bug#1049884: birdtray: FTBFS on armhf, armel, mipsel due to thunderbird build-dep

[Adam Borowski]

On Mon, Aug 21, 2023 at 10:38:52AM +0200, Emanuele Rocca wrote:
> Hi Adam,
Hi Em!

> On 2023-08-16 05:14, Adam Borowski wrote:
> > This is not a regression, thus why would it be a bug?
> 
> Well FTBFS is a bug isn't it? :-)

A FTBFS on an architecture that has built before (and hasn't been RMed)
is a bug, and one that's policied as high severity.

A FTBFS that's not a regression is a wishlist, a porting opportunity.
And here it's not even a build failure but a failure to install b-deps.

Obviously we'd prefer thunderbird:armhf to be a thing, but unless/until it
can be fixed, talk about thunderbird addons on armhf is quite moot.
And the way b-deps are written, the moment thunderbird:armhf hits incoming
its addons get enabled in wanna-build, with no human action needed.

> > There's nothing in birdtray itself that would prevent it from being built on
> > these architectures the moment problems in thunderbird are resolved
> 
> Why does birdtray build-depend on thunderbird? It seems to build
> perfectly fine in a clean armhf chroot without it.

Build yes, work no.  The result would be a pointless package you can't use;
adding this (otherwise superfluous) build-dependency avoids having a
non-installable package in the archive.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy.
⠈⠳⣄

Bug#1042252: pmdk: diff for NMU version 1.13.1-1.1

[Adam Borowski]

On Fri, Aug 11, 2023 at 02:02:36PM +0300, Adrian Bunk wrote:
> I've prepared an NMU for pmdk (versioned as 1.13.1-1.1) and uploaded
> it to DELAYED/2. Please feel free to tell me if I should cancel it.

> +pmdk (1.13.1-1.1) unstable; urgency=low
> +
> +  * Non-maintainer upload.
> +  * Ignore check-manpages failure until Pandoc creates manpages
> +that are accepted by the latest groff. (Closes: #1042252)
> +
> + -- Adrian Bunk   Fri, 11 Aug 2023 13:28:04 +0300

It's okay.  I waited for the problem to be fixed in pandoc and/or groff,
as pmdk is merely an user of these tools, but apparently this takes a
while.  Thus, papering over the failing test for now is a good idea.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
⢿⡄⠘⠷⠚⠋⠀   ./configure --host=zx-spectrum --build=pdp11
⠈⠳⣄

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Adam Borowski]

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
>  * Package name : libtypec
>Version  : 0.3-1
>  * URL  : https://github.com/Rajaram-Regupathy/libtypec

>   libtypec1 - generic interface for efficient USB-C port management
>   libtypec-dev - Development files for an interface for USB-C port management

>  libtypec (0.3-1) unstable; urgency=low
>  .
>* Initial release (Closes: #1023477)
>* Add patch 0001-fix-libtypec-so-version.patch to fix .so name version

Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ A tit a day keeps the vet away.
⠈⠳⣄

Bug#1041319: RFS: msc-generator/8.4.1-1 RC -- Signalling chart generator

[Adam Borowski]

On Mon, Jul 17, 2023 at 01:04:37PM +, Gábor Németh wrote:
> Changes since the last upload:
> 
>   * New upstream v8.4.1
>   * Re-enable tests on non-amd64 in allow-to-fail mode
>   * Remove patches applied upstream 0002-autoconf.patch,
> 0003-diff-text.patch, 0004-loffice-test.patch, and
> 0005-imgui-reverse.patch
>   * Remove unused 0001-asan-imgui.patch from source root
>   * Add DEP-3 header to 0001-debian-example.patch
>   * Add 0002-remove-generated.patch to fix dist tarball issue
>   * Add 0003-gcc13-include.patch to fix building with g++-13 (Closes:
> #1037782)
>   * Switch dependency to libfreetype-dev
>   * Switch libreoffice for a recent enough libreoffice-impress-nogui in
> Build-Depends (Closes: #1024840)
>   * Removed more files and directories not in the tarball and unused
> by the build system (cf. 6d94428).

Hi!
It's a good idea to always run lintian before uploading a package anywhere.
This allows skipping round-trips as it automates a great majority of stuff
to look for.

In this particular case there's:

E: msc-generator: missing-depends-on-sensible-utils sensible-browser 
[usr/bin/msc-gen]
E: msc-generator changes: unreleased-changes
W: msc-generator source: build-depends-on-1-revision Build-Depends: 
libreoffice-impress-nogui (>= 4:7.5.4~rc2-1) [amd64] 

And as usually, the explanations given by -i are good.

Let's fix that first; I did not notice any other problems so far but I took
only a brief glance.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

[Adam Borowski]

Package: debootstrap
Version: 1.0.128+nmu3
Severity: grave

bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the
aliased-dirs scheme.  While it's currently the default scheme for non-buildd
systems, it is both not supported by dpkg (with no solution in sight), but
is also likely to produce packages that are explicitely forbidden by a
recent CTTE ruling that disallows moving files between directories aliased
by the current usrmerge scheme.

Quoting the still unsolving issues is pointless (you can read about them
in massive threads in a number of places) as bluca seems to be ignoring
them completely.

But, what matters here is the CTTE ruling in #1035831 -- for the time being,
packages must not move files between locations affected by the aliasing.

Packages built in an usrmerged chroot place such files under /usr while
built without usrmerge into whatever place they were installed to -- which
is a direct breach of the ruling.

Thus, that change needs to be reverted for now, and all packages built
with 1.0.128+nmu3 need to be either rebuilt or at least checked for such
a violation (as most are unaffected).


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.21-1
ii  debian-archive-keyring  2023.3
ii  gnupg   2.2.40-1.1

Versions of packages debootstrap suggests:
ii  binutils 2.40.90.20230705-1
pn  squid-deb-proxy-client   
ii  ubuntu-archive-keyring   2020.06.17.1-1
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1
ii  xz-utils 5.4.1-0.2
ii  zstd 1.5.5+dfsg2-1

-- no debconf information

Bug#1041206: python-clickhouse-driver: FTBFS if source is included: aborting due to unexpected upstream changes

[Adam Borowski]

Source: python-clickhouse-driver
Version: 0.2.5-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
With any build type that includes the source, your package fails with:

dpkg-source: info: local changes detected, the modified files are:
 python-clickhouse-driver-0.2.5/clickhouse_driver/bufferedreader.c
 python-clickhouse-driver-0.2.5/clickhouse_driver/bufferedwriter.c
 python-clickhouse-driver-0.2.5/clickhouse_driver/columns/largeint.c
 python-clickhouse-driver-0.2.5/clickhouse_driver/varint.c
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/python-clickhouse-driver_0.2.5-1.diff.aYpmik
dpkg-source: info: Hint: make sure the version in debian/changelog matches the 
unpacked source tree


Full build log attached.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.85.2 (11 March 2023) on valinor.angband.pl

+==+
| python-clickhouse-driver (amd64) Sat, 15 Jul 2023 16:07:40 + |
+==+

Package: python-clickhouse-driver
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-2168482a-634b-4d8e-b5d4-42b1136edf8b'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/python-clickhouse-driver-QFihkK/resolver-njOJ3X' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'python-clickhouse-driver' packaging is maintained in the 'Git' version 
control system at:
https://salsa.debian.org/debian/python-clickhouse-driver.git
Please use:
git clone https://salsa.debian.org/debian/python-clickhouse-driver.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 297 kB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main 
python-clickhouse-driver 0.2.5-1 (dsc) [2200 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main 
python-clickhouse-driver 0.2.5-1 (tar) [292 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main 
python-clickhouse-driver 0.2.5-1 (diff) [3228 B]
Fetched 297 kB in 0s (4024 kB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/python-clickhouse-driver-QFihkK/python-clickhouse-driver-0.2.5' with 
'<>'
I: NOTICE: Log filtering will replace 'build/python-clickhouse-driver-QFihkK' 
with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), dh-python, cython3, 
python3-all-dev, python3-setuptools, python3-sphinx, python3-tzlocal, 
build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), dh-python, cython3, 
python3-all-dev, python3-setuptools, python3-sphinx, python3-tzlocal, 
build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [707 B]
Get:5 copy:/<>/apt_archive ./ Packages [739 B]
Fetched 2055 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)
--

Bug#1041203: FTBFS: InvalidRequirement: Expected end or semicolon

[Adam Borowski]

Source: macs
Version: 2.2.7.1-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build, with:
pkg_resources.extern.packaging._tokenizer.ParserSyntaxError: Expected end or 
semicolon (after name and no valid version specifier)
numpy>=>=1.17

Full log attached.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.85.2 (11 March 2023) on valinor.angband.pl

+==+
| macs (amd64) Sat, 15 Jul 2023 15:59:52 + |
+==+

Package: macs
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-6c3ec2b5-ebd2-4821-9c2c-b590aa40ebd9'
 with '<>'
I: NOTICE: Log filtering will replace 'build/macs-QwMUa0/resolver-kV6wWG' with 
'<>'

+--+
| Update chroot|
+--+

Get:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease [199 kB]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main Sources.diff/Index 
[63.6 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 
Packages.diff/Index [63.6 kB]
Get:4 http://apt-rosy.angband.pl:3142/debian unstable/main Sources 
T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [38.2 kB]
Get:4 http://apt-rosy.angband.pl:3142/debian unstable/main Sources 
T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [38.2 kB]
Get:5 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages 
T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [14.4 kB]
Get:5 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages 
T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [14.4 kB]
Fetched 379 kB in 1s (275 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  libtool
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 517 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 libtool all 
2.4.7-6 [517 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 517 kB in 0s (16.6 MB/s)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14595 files and directories currently installed.)
Preparing to unpack .../libtool_2.4.7-6_all.deb ...
Unpacking libtool (2.4.7-6) over (2.4.7-5) ...
Setting up libtool (2.4.7-6) ...
Processing triggers for man-db (2.11.2-2) ...

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'macs' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/med-team/macs.git
Please use:
git clone https://salsa.debian.org/med-team/macs.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 136 MB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 (dsc) 
[2102 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 (tar) 
[135 MB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 
(diff) [1268 kB]
Fetched 136 MB in 0s (336 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 'bui

Bug#1040621: binutils-mipsen: missing shlib dependencies

[Adam Borowski]

Source: binutils-mipsen
Version: 10+c3
Severity: grave
Justification: renders package unusable

mips* binutils tools crash on startup:
$ mips64el-linux-gnuabi64-as
mips64el-linux-gnuabi64-as: error while loading shared libraries: 
libsframe.so.0: cannot open shared object file: No such file or directory

The culprit is:
$ ldd /usr/lib/x86_64-linux-gnu/libopcodes-2.40.50-mips64el.20230611.so
libsframe.so.0 => not found
which would be prevented by package relationships/DAK/etc, had the
dependency on libsframe be included in binaries you produce.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.2-00035-g5920c330f094 (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1040359: RFS: vim-julia/0.0~git20221020.fca7e3e-1 [ITA] -- Vim support for Julia language

[Adam Borowski]

On Tue, Jul 04, 2023 at 10:05:39PM +0100, Thiago Marques wrote:
>  vim-julia (0.0~git20221020.fca7e3e-1) unstable; urgency=medium
>  .
>* New maintainer (Closes: #1013212).
>* New upstream release.
>* Bump Standards-Version to 4.6.2.
>* debian/control: update to use the new dh-vim-addon (supporting 
> vim/neovim).
>* debian/patches: added patch to fix script-not-executable.

Alas, the autopkgtest fails:
autopkgtest [16:46:44]: test command1: vam install julia
autopkgtest [16:46:44]: test command1: [---
Warning: ignoring 'julia' which is missing source files
autopkgtest [16:46:44]: test command1: ---]
autopkgtest [16:46:45]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL stderr: Warning: ignoring 'julia' which is missing 
source files
autopkgtest [16:46:45]: test command1:  - - - - - - - - - - stderr - - - - - - 
- - - -
Warning: ignoring 'julia' which is missing source files


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ You're alive.  But that's just a phase.
⠈⠳⣄

Bug#1040513: wireplumber: non-installable due to hardcoded Depends: dbus-user-session

[Adam Borowski]

Package: wireplumber
Version: 0.4.14-3
Severity: grave

Hi!
In version 0.4.14-3, you added a hard dependency on a specific session
model of dbus, rather than the virtual package defined by the Policy
(dbus-session-bus).  This makes it non-installable on any box where a
dependency of that package is non-functional or unwanted.

As of policy 4.3.0, the expected dependency is:
default-dbus-session-bus | dbus-session-bus

We have two implementations of  in Debian:
 * dbus-user-session:
   + works with wayland
   - no multiseat support
   - requires systemd
 * dbus-x11
   - requires x11
   + allows multiple sessions
   + portable even to non-linux

I confirm that, as of 0.4.14-2 wireplumber works well with dbus-x11, and
earlier versions did so for quite a while too.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.2-00035-g5920c330f094 (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.65.2
ii  libc6 2.37-4
ii  libglib2.0-0  2.74.6-2
ii  libpipewire-0.3-0 0.3.73-1
ii  libwireplumber-0.4-0  0.4.14-2
ii  pipewire  0.3.73-1

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.73-1

Versions of packages wireplumber suggests:
pn  libspa-0.2-bluetooth  
pn  wireplumber-doc   

-- no debconf information

Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer

[Adam Borowski]

On Sun, May 21, 2023 at 07:35:36AM +0200, Cyril Brulebois wrote:
> Adam Borowski  (2023-05-20):
> > The JFS filesystem is deprecated in the kernel: on life support since 2009
> > and with talks of removal altogether.  Thus, we really shouldn't offer to
> > format new setups with it.  There are people who kind-of remember JFS being
> > the fastest back in the day, and it's irresponsible to set them for failed
> > upgrades past Bookworm.
> > 
> > Thus: please remove JFS from the installer.
> 
> It doesn't seem reasonable to do that weeks away from the release, without
> any kind of heads-up. That can be done during the Trixie release cycle,
> e.g. in Alpha 1.

Aye, sorry for having distracted you during the most busy time.  I filed the
bug when I learned about plans of giving JFS the axe.

> Feel free to ping this bug report a few weeks/months into the next release
> cycle

So... it might be a better time now.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk,
⣾⠁⢠⠒⠀⣿⡁   ash nazg gimbatul,
⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk
⠈⠳⣄   agh burzum-ishi krimpatul.

Bug#1039450: ndctl: Split ndctl-monitor (and cxl-monitor?) into own package

[Adam Borowski]

Control: severity -1 wishlist

> I often use a custom livecd verision of Debian with various utilities
> pre-installed, so they can be easily used offline, or without needing to
> reinstall them after each reboot.

Such a livecd is a non-standard (but not non-important!) usage, and it
already customizes other facets of packages it includes.  What about
configuring that livecd to not start such daemons?

> But often, if I boot this same livecd on a machine that does not have cxl
> or nvm dimm devices, deamon will complain, and fail at boot (with big red
> warning), and sytemd will continue restarting it afaik (or maybe not, it
> looks like it tries to run it only once on my system, then gives up).

That's news to me.  I don't run systemd myself (heck, it's so buggy it even
fails to boot my main workstation, and I have a severe dislike of it for
other reasons), and I've included the .service from upstream as-is, after
very superficial testing.  The daemon is supposed to gracefully exit if
there's nothing to monitor:

2023-06-19T06:01:41.874004+02:00 valinor ndctl: ndctl monitor daemon started
2023-06-19T06:01:41.874062+02:00 valinor ndctl: no dimms to monitor, exiting

I had even suggested/implemented some improvements here to upstream, but not
surprisingly 99% of my testing was done with sysvinit and openrc.

Still, it's surprising the upstream would fail to notice what you report:

> root@debian:~# systemctl status ndctl-monitor.service 
> × ndctl-monitor.service - Ndctl Monitor Daemon
>  Loaded: loaded (/lib/systemd/system/ndctl-monitor.service; enabled; 
> preset: enabled)
>  Active: failed (Result: exit-code) since Wed 2023-06-28 22:11:35 UTC; 
> 25min ago
>Duration: 89ms
> Process: 2412 ExecStart=/usr/bin/ndctl monitor (code=exited, status=250)
>Main PID: 2412 (code=exited, status=250)
> CPU: 9ms
> 
> Jun 28 22:11:35 debian systemd[1]: Started ndctl-monitor.service - Ndctl 
> Monitor Daemon.
> Jun 28 22:11:35 debian ndctl[2412]: no dimms to monitor, exiting
> Jun 28 22:11:35 debian systemd[1]: ndctl-monitor.service: Main process 
> exited, code=exited, status=250/n/a
> Jun 28 22:11:35 debian systemd[1]: ndctl-monitor.service: Failed with result 
> 'exit-code'.

Maybe this redness is a regression?

> It is not a big deal, but something that is not perfect in my opinion.

Seems like something to investigate once tuits are more abundant.
 
> For my livecd, I can clearly modify some systemd unit files manually
> (using build scripts for live-build), but I wonder if defaulting to
> running a daemon by default is a good idea in general. Most of the time
> probably yes, but sometimes not.

The rule in Debian is to start a daemon if it's installed; eg. Red Hat has
the opposite custom.  There's usually no point in installing daemons that
are not needed; and it those rare cases you do, the admin can disable them
from starting.  This sounds like a good modification for the livecd.

> As of smartmontools you mentioned. I have exactly same issue. I need
> smartctl tools for troubleshooting various computers on my livecd, but I
> DO NOT WANT smartd to start. For very similar reason I opened a bug
> against smartmontools few days ago: https://bugs.debian.org/1039454

As their user count is many orders of magnitude larger than that of ndctl,
and so is diversity of supported hardware (NVDIMMs are found only in fat
servers), they also have far more collective brain cells.  I'd thus wait
for their decision then copy it.

> Feel free to downgrade to wishlist and think if this makes sense at all.

Done this for now.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.

Bug#1039450: ndctl: Split ndctl-monitor (and cxl-monitor?) into own package

[Adam Borowski]

On Mon, Jun 26, 2023 at 12:40:54AM +, Witold Baryluk wrote:
> Package: ndctl
> Version: 76.1-1
> Severity: normal

> ndctl and cxl can be used on its own, installation of them should not
> imply one wants to run ndctl-monitor (or as I see in version 77 also
> cxl-monitor).
> 
> Move systemd service units and init scripts to own packages,
> ndctl-monitor and cxl-monitor?

That's a reasonable request.  However, I wonder, how intrusive the daemon
is?  If there are no failures, it just sits there doing nothing, not taking
any significant amount of memory.  It's same as eg. smartmontools.
If the daemon is still unwanted, it can be disabled via update-rc.d or
systemd equivalent.

Splitting the two daemons away would make sense for packages that run on
resource-constrained systems, but machines that have pmem are very, very far
from that :)

Thus: could you tell me if your use case would suffer if you had to manually
disable the daemons from starting?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#1039514: RFS: cil/0.07.00-13 -- command line issue tracker

[Adam Borowski]

On Mon, Jun 26, 2023 at 10:08:17PM +0200, Jörg Frings-Fürst wrote:
>  cil (0.07.00-13) unstable; urgency=medium
>  .
>* Declare compliance with Debian Policy 4.6.2.0 (No changes needed).
>* Migrate to debhelper-compat 13:
>  - Change debhelper (>= 11) to debhelper-compat (= 13) in debian/control.
>  - Remove debian/compat.
>* debian/control:
>  - Change to new repository URL.
>  - Add Rules-Requires-Root: binary-targets.
>* debian/copyright:
>  - Add 2023 to myself.
>* debian/watch:
>  - Bump to version 4.

Seems broken:

autopkgtest [08:49:30]: test autodep8-perl-recommends: [---

#   Failed test '/usr/bin/perl -wc /usr/share/perl5/CIL/Git.pm exited 
successfully'
#   at 
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t line 124.

#   Failed test '/usr/bin/perl -wc /usr/share/perl5/CIL/Issue.pm exited 
successfully'
#   at 
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t line 124.

#   Failed test '/usr/bin/perl -wc /usr/share/perl5/CIL.pm exited 
successfully'
#   at 
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t line 124.
# Looks like you failed 3 tests of 27.

#   Failed test 'all modules in cil pass the syntax check'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t 
line 127.
# Looks like you failed 1 test of 4.
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t .. 
1..4
ok 1 - Package cil is known to dpkg
ok 2 - Got status information for package cil
ok 3 - Got file list for package cil
# Subtest: all modules in cil pass the syntax check
1..27
ok 1 - /usr/bin/perl -wc /usr/share/perl5/CIL/Attachment.pm exited 
successfully
ok 2 - /usr/bin/perl -wc /usr/share/perl5/CIL/Base.pm exited successfully
ok 3 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Add.pm exited 
successfully
ok 4 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Am.pm exited 
successfully
ok 5 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Attach.pm exited 
successfully
ok 6 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Comment.pm exited 
successfully
ok 7 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/DependsOn.pm exited 
successfully
ok 8 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Edit.pm exited 
successfully
ok 9 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Extract.pm exited 
successfully
ok 10 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Fsck.pm exited 
successfully
ok 11 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Init.pm exited 
successfully
ok 12 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Label.pm exited 
successfully
ok 13 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/List.pm exited 
successfully
ok 14 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Precedes.pm exited 
successfully
ok 15 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Show.pm exited 
successfully
ok 16 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Status.pm exited 
successfully
ok 17 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Steal.pm exited 
successfully
ok 18 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Summary.pm exited 
successfully
ok 19 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Track.pm exited 
successfully
ok 20 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command/Work.pm exited 
successfully
# Useless use of a constant ("end of package CIL::Command") in void context 
at /usr/share/perl5/CIL/Command.pm line 17.
ok 21 - /usr/bin/perl -wc /usr/share/perl5/CIL/Command.pm exited 
successfully
ok 22 - /usr/bin/perl -wc /usr/share/perl5/CIL/Comment.pm exited 
successfully
# Can't locate Git.pm in @INC (you may need to install the Git module) 
(@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 
/usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
/usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 
/usr/local/lib/site_perl) at /usr/share/perl5/CIL/Git.pm line 28.
# BEGIN failed--compilation aborted at /usr/share/perl5/CIL/Git.pm line 28.
not ok 23 - /usr/bin/perl -wc /usr/share/perl5/CIL/Git.pm exited 
successfully
# Can't locate Git.pm in @INC (you may need to install the Git module) 
(@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 
/usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
/usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 
/usr/local/lib/site_perl) at /usr/share/perl5/CIL/Git.pm line 28.
# BEGIN failed--compilation aborted at /usr/share/perl5/CIL/Git.pm line 28.
# Compilation failed in require at /usr/share/perl5/CIL.pm line 29.
# BEGIN failed--compilation aborted at /usr/share/perl5/CIL.pm line 29.
# Compilation failed in require at /usr/share/perl5/CIL/Issue.pm line 28.

Bug#824691: time to go

[Adam Borowski]

Control: clone -1 -2
Control: retitle -2 RM: tangerine-icon-theme
Control: reassign -2 ftp.debian.org

In May 2016 it was written:
> In case it's not picked up eventually I'll ask for its removal.

It hasn't, and 7 years later, it is time for it to go.

Its packaging is of incredibly low quality: empty dirs, stuff installed to
wrong dirs -- including a bogus directory right under /usr, sometimes
building infinitely long, etc, etc.

It's also non-free when so many alternatives exist.

Thus: please RM it from the archive.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#1037174: RFS: damo/1.8.4-1 [ITP] -- Data Access Monitoring Operator

[Adam Borowski]

On Tue, Jun 06, 2023 at 09:45:25PM -0500, Michel Alexandre Salim wrote:
>  * Package name : damo
>Version  : 1.8.4-1
>Upstream contact : SeongJae Park 
>  * URL  : https://damonitor.github.io/
>  * Vcs  : https://salsa.debian.org/python-team/packages/damo

>  damo (1.8.4-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #1037157)

Hi!
The commands you run for % targets will fail badly if ran in parallel, and
that's the default these days.  Please run that only once, eg from
override_dh_auto_configure (as that's a target that's run early).

Other nice to have bits:
 * the description doesn't say what DAMON is, even "Data Access Monitoring
   Operator" doesn't shed much light
 * a command-line tool really should have a man page

(but only the first part is a blocker)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ ʀᴜꜱꜱɪᴀɴᴇꜱ ᴇᴜɴᴛ ᴅᴏᴍᴜꜱ
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer

[Adam Borowski]

Package: partman-jfs
Severity: important

Hi!
The JFS filesystem is deprecated in the kernel: on life support since 2009
and with talks of removal altogether.  Thus, we really shouldn't offer to
format new setups with it.  There are people who kind-of remember JFS being
the fastest back in the day, and it's irresponsible to set them for failed
upgrades past Bookworm.

Thus: please remove JFS from the installer.


Meow!

Bug#1035621: ncurses uses its own autoconf

[Adam Borowski]

> - Why does dh_autoreconf error out on some architectures, but not on
>   others?
> - Why is AM_LANGINFO_CODESET not found, despite being defined in
>   aclocal.m4?

ncurses uses its own fork of autoconf, autoconf-dickey, that's peculiar to
ncurses' upstream.  Not surprisingly, it lacks improvements and fixes from
mainline.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Bug#1035018: btrfs-progs: /sbin/fsck.btrfs missing from udeb

[Adam Borowski]

On Thu, Apr 27, 2023 at 04:58:46PM +0200, Emanuele Rocca wrote:
> 
> the btrfs-progs udeb currently includes only /bin/btrfs and /bin/mkfs.btrfs.
> 
> Please add /sbin/fsck.btrfs as well so that it can be included in the 
> initramfs
> generated by the debian installer. Patch attached.

That file is a no-op script that's there just to placate mount mechanisms
which blindly run fsck on startup.  Unlike ext4 which still supports
ext2 filesystems that risk damage, possibly widespread and/or hidden,
in the case of an unsafe shutdown, modern filesystems (btrfs, xfs, jfs, …)
no longer require that.

If the kernel is unable to recover on its own, the cause must have been a
hardware or software problem which can't happen during normal operation,
and data loss of some kind is likely -- thus there's nothing that's prudent
to try to fix _automatically_.

Ie, /sbin/fsck.btrfs serves no purpose that'd be useful in an udeb.

Before I close this report, may I ask if you have a purpose for this
stub?  You probably wanted a full-blown recovery tool, but I may be
getting you wrong.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ ʀᴜꜱꜱɪᴀɴᴇꜱ ᴇᴜɴᴛ ᴅᴏᴍᴜꜱ
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1022222: valgrind-if-available shouldn't stop providing valgrind on mipsel

[Adam Borowski]

Control: severity -1 normal

(I intended to avoid having to argue by implementing specific objective
tests that valgrind has to meet to be declared available, but I did not
manage to get that done.  Thus, arguing...)

On Sat, Oct 22, 2022 at 12:12:40PM +0300, Adrian Bunk wrote:
> Package: valgrind-if-available
> Severity: serious

> valgrind-if-available (3.18.1-1-1) unstable; urgency=medium
> ...
>   * Drop mipsel as valgrind disagrees about blah blah baseline Loongson.

> This is wrong, and it makes at least qtmir FTBFS.

(as said already elsewhere) Failing to build because valgrind is not
available means you're using the package wrong: it may or may not pull in
valgrind, and the set of architectures can and will change without any
warning.  The whole purpose of this metapackage is to track valgrind's
availability so 100+ individual packages don't need to.

Ie, instead of:
  if arch in (foo bar baz quux)
 build --valgrind=yes
  else
 build --valgrind=no
you do:
  if `which valgrind >/dev/null`
 build --valgrind=yes
  else
 build --valgrind=no

> If there is any problem with valgrind on mipsel
> it should be discussed and resolved in valgrind first,
> if valgrind is available then valgrind-if-available
> has to provide it.

No, this particular problem is that valgrind doesn't work on _some_
mipsel machines.  This doesn't make valgrind itself useless, but makes
it unsuitable for being ran as a part of automated testsuites.

As our buildds appear to be all Loongsons, coding some complex machinery
to detect the subarch at runtime would be a waste of time.  Flat out
saying "disable valgrind tests on mipsel" is easier and works good enough
for now.

> It is also unclear what the baseline problem is this changelog
> entry is referring to, there is no open bug in the valgrind package
> mentioned and the closest I could find was a bug that was fixed (sic)
> 5 years ago.

It fails at least in 3.19 (unstable) and 3.20 (experimental):
https://buildd.debian.org/status/fetch.php?pkg=valgrind-if-available&arch=mipsel&ver=3.19.0-1-1&stamp=1667563987&raw=0

==1833049== Memcheck, a memory error detector
==1833049== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1833049== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1833049== Command: /tmp/___
==1833049== 

VEX: Unsupported baseline
 Found: Loongson-baseline
Cannot continue. Good-bye

vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==1833049==at 0x5804FB44: ??? (in 
/usr/libexec/valgrind/memcheck-mips32-linux)
==1833049==by 0x5804FA2C: ??? (in 
/usr/libexec/valgrind/memcheck-mips32-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 1833049)
==1833049==at 0x401B920: __start (in /lib/mipsel-linux-gnu/ld.so.1)
==1833049==by 0x7EB7B088: ???
client stack range: [0x7EB78000 0x7EB7BFFF] client SP: 0x7EB7B090
valgrind stack range: [0x42878000 0x42977FFF] top usage: 5512 of 1048576


It appears that no one, both upstream and _in Debian_, cares enough about
mipsel to fix bugs or even report them, thus I don't expect it to be solved
anytime soon -- or, probably, ever, as mipsel is not long for this world.

But, as the trivial solution would be removing support for mipsel completely
from valgrind, I think users are better served by being provided something
that works on at least _some_ hardware.
 
> It is also suprising if this is really a mipsel-only issue as the
> changelog claims, I would have expected any issues to also show
> up on mips64el.

This very same test works fine on mips64el.

> Therefore please report any issues with valgrind on mipsel as bugs
> against src:valgrind, but in any case please make valgrind-if-available
> always provide valgrind on all architectures where it is available.

Seems we understand "available" differently:
* for you, it means "shipped at all",
* for me, it means "works for a typical set of tasks".

valgrind on mipsel is functional on old hardware but dies even on "hello
world" on Loongson.  I consider this availability to be lacking.


My plans for this bug are:
* s/available/available and functional/ in the description
* run all tests even on marginal archs, but don't fail the build if it's
  an expected failure


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Only flat-earthers have a problem folding a fitted sheet.
⢿⡄⠘⠷⠚⠋⠀ I instead shape it into a ball.
⠈⠳⣄

Bug#1033275: RFS: zstd-jni-java/1.5.4-2+ds-1 [Team] -- JNI bindings for Zstd (Architecture-specific files)

[Adam Borowski]

On Tue, Mar 21, 2023 at 01:13:35AM +, sun min wrote:
> I am looking for a sponsor for my package "zstd-jni-java":

> Changes since the last upload:
> 
> zstd-jni-java (1.5.4-2+ds-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream release.
+  * Update debian/libzstd-jni1.symbols.
+
+ -- sun min   Wed, 08 Mar 2023 16:40:55 +0800

This doesn't look like an update that's fit for Bookworm during the hard
freeze.  There's no description of changes attached, thus I can't tell if
these are bugfixes only.  If so, please say so.

Otherwise, let's use experimental or just refrain from uploading until
Bookworm is released.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Q: Is it ok to combine wired, wifi, and/or bluetooth connections
⢿⡄⠘⠷⠚⠋⠀in wearable computing?
⠈⠳⣄ A: No, that would be mixed fabric, which Lev19:19 forbids.

Bug#1032967: [btrfs-progs][armhf] Cannot delete a subvolume or create a snapshot

[Adam Borowski]

On Tue, Mar 14, 2023 at 11:36:29PM +0200, Παύλος Γκέσος wrote:
> Package: btrfs-progs
> Version: 5.10.1-2 armhf
> 
> When I try to delete a previous created btrfs subvolume I get this:
> ERROR: Could not statfs: Value too large for defined data type
> 
> The same when I try to make a btrfs snapshot.

Hi, there are known issues with large filesystems on 32-bit.  Not just
btrfs for that matter -- it's just more likely to be affected because of
native multi-device support and two layers of addressing.

Thus:
* how big is the filesystem?
* does it consist of multiple devices?
* has it been rebalanced or converted to a different redundancy profile?

If the sum of all parts that are (or ever have been) included in the
filesystem approaches 8TB, this would be the cause.  In addition, any
address space that was allocated in the past but had been balanced/converted
away is lost -- virtual offsets always go up.  This is not a concern on
64-bit as you can't possibly use them up, but for 32-bit the limit can be
exceeded even with a single large disk.

Other filesystems also suffer from this limit, although MD at least moves
the threshold from being applied to raw device size to the available size
which allows redundant raid as long as the resulting size is below[1] 8TB.

Shedding the limit would require changing many parts of the kernel, and
there is currently no intention of ever doing that.  Thus, I'm afraid you
need to either use a smaller filesystem or a 64-bit kernel (which your CPU
doesn't support).

There's little support for 32-bit in general, it's in maintenance mode
these days...


Did I assume correctly that you ran into the limit?  If not, please say so.
Otherwise, all we can do is improving error messages.


[1]. Because disk manufacturers cheat on the definition of "terabyte",
an "8TB" disk has less than 1099511627776 bytes.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Q: Is it ok to combine wired, wifi, and/or bluetooth connections
⢿⡄⠘⠷⠚⠋⠀in wearable computing?
⠈⠳⣄ A: No, that would be mixed fabric, which Lev19:19 forbids.

Bug#1001889: patch doesn't seem to help

[Adam Borowski]

Hi!
Sorry for missing the bug report somehow -- on team packages, uploaders
don't receive notifications by default, and I dun goofed while subscribing.

It's bad to have wxmaxima crash because of a mere theme...
But, even after applying your fix, wxmaxima continues to crash.

Since you already figured out the issue before, could you take a glance at
  https://salsa.debian.org/desktop-themes-team/darkcold-gtk-theme
branch "wip" and see what am doing wrong?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Q: Is it ok to combine wired, wifi, and/or bluetooth connections
⢿⡄⠘⠷⠚⠋⠀in wearable computing?
⠈⠳⣄ A: No, that would be mixed fabric, which Lev19:19 forbids.

Bug#1032041: FTBFS: error: ‘size_t’ does not name a type

[Adam Borowski]

Source: arm-compute-library
Version: 20.08+dfsg-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build, with:

In file included from src/core/ITensorPack.cpp:24:
./arm_compute/core/ITensorPack.h:89:5: error: ‘size_t’ does not name a type
   89 | size_t size() const;
  | ^~
./arm_compute/core/ITensorPack.h:29:1: note: ‘size_t’ is defined in header 
‘’; did you forget to ‘#include ’?
   28 | #include 
  +++ |+#include 
   29 | 

Full log attached.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (490, 'testing'), (250, 'unstable'), (201, 'experimental')
merged-usr: no
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-3-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on rhun

+==+
| arm-compute-library (arm64)  Sat, 25 Feb 2023 23:54:14 + |
+==+

Package: arm-compute-library
Distribution: unstable
Machine Architecture: arm64
Host Architecture: arm64
Build Architecture: arm64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-arm64-sbuild-edf3fc6f-42f6-4973-91ef-878c3886c3bc'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/arm-compute-library-q3qKDi/resolver-psabH1' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'arm-compute-library' packaging is maintained in the 'Git' version 
control system at:
https://salsa.debian.org/wookey/arm-compute-library
Please use:
git clone https://salsa.debian.org/wookey/arm-compute-library
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 1941 kB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 
20.08+dfsg-5 (dsc) [2339 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 
20.08+dfsg-5 (tar) [1924 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 
20.08+dfsg-5 (diff) [14.7 kB]
Fetched 1941 kB in 0s (27.9 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/arm-compute-library-q3qKDi/arm-compute-library-20.08+dfsg' with 
'<>'
I: NOTICE: Log filtering will replace 'build/arm-compute-library-q3qKDi' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), dh-exec (>= 0.3), scons (>= 
2.4), doxygen, graphviz, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 12), dh-exec (>= 0.3), scons (>= 
2.4), doxygen, graphviz, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [670 B]
Get:5 copy:/<>/apt_archive ./ Packages [702 B]
Fetched 1981 B in 0s (57.8 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  dh-exec doxygen fontconfig fontconfig-config fonts-dejavu-core graphviz
  libabsl20220623 libann0 libaom3 libavif15 libbrotli1 libbsd0 libcairo2
  libcdt5 libcgraph6 libclang-cpp14 libclang1-14 libdatrie1 libdav1d6
  libde265-0 libdeflate0 libedit2 libexpat

Bug#1032032: FTBFS: error: AM_INIT_AUTOMAKE expanded multiple times

[Adam Borowski]

Source: fenix-plugins
Version: 0.0.20070803-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build; I see a lot of autoconf warnings,
then they get fatal:

Makefile.am: installing './depcomp'
configure.ac:12: error: AM_INIT_AUTOMAKE expanded multiple times
/usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:11: the top level
/usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:12: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal: error: /usr/bin/autom4te failed with exit status: 1
autoreconf: error: aclocal failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i agua-1.0 exec-0.4a fgfx-1.0 fire-1.0 
fsock-1.0 image-1.0 mixer-1.0 mpeg-1.0 net-1.0 tcpsock-2.0 ttf-1.0 returned 
exit code 1

It appears the package is not compatible with new autotools; they have
been updated quite a while ago but as the package is 32-bit only the
failure wasn't noticed during usual QA efforts.

I've verified the fail on i386 and armhf.

Full log attached.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-00034-g2ff294a21c8d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on valinor.angband.pl

+==+
| fenix-plugins (i386) Sun, 26 Feb 2023 01:31:02 + |
+==+

Package: fenix-plugins
Distribution: unstable
Machine Architecture: amd64
Host Architecture: i386
Build Architecture: i386
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-i386-sbuild-f27f2fb3-5a2c-41fa-94ad-2023f47260fb'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/fenix-plugins-gpzT6Q/resolver-zNf5Pt' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'fenix-plugins' packaging is maintained in the 'Git' version control 
system at:
https://salsa.debian.org/games-team/fenix-plugins.git
Please use:
git clone https://salsa.debian.org/games-team/fenix-plugins.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 7775 kB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 
0.0.20070803-8 (dsc) [2749 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 
0.0.20070803-8 (tar) [7766 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 
0.0.20070803-8 (diff) [6336 B]
Fetched 7775 kB in 0s (262 MB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/fenix-plugins-gpzT6Q/fenix-plugins-0.0.20070803' with '<>'
I: NOTICE: Log filtering will replace 'build/fenix-plugins-gpzT6Q' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), zlib1g-dev, libsdl1.2-dev, 
libsdl-image1.2-dev, libsdl-net1.2-dev, libsdl-mixer1.2-dev, libsmpeg-dev, 
libfreetype6-dev, fenix, fenix-dev, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 12), zlib1g-dev, libsdl1.2-dev, 
libsdl-image1.2-dev, libsdl-net1.2-dev, libsdl-mixer1.2-dev, libsmpeg-dev, 
libfreetype6-dev, fenix, fenix-dev, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ I

Bug#1031698: RFS: dhcpdump/1.8-5 [QA] -- Parse DHCP packets from tcpdump

[Adam Borowski]

On Mon, Feb 20, 2023 at 05:10:34PM -0300, Jpaulo wrote:
>  dhcpdump (1.8-5) experimental; urgency=medium
>  .
>* QA upload.
>* debian/control:
>- Set Rules-Requires-Root:no.
>- Set homepage-field.
>- Bumped Standards-Version to 4.6.1.
>- Set debhelper-compat version in Build-Depends.
>- Added Depends ${shlibs:Depends} in Depends fields.
>* debian/rules:
>- Rewrite to use dh-sequencer.
>* debian/metadata:
>- Added missing upstream metadata.
>- Added upstream's key.
>* debian/watch:
>- Add watch file.

Hi!
I believe it's better if packages carry some non-metadata contents, which
the new version currently lacks...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Q: Is it ok to combine wired, wifi, and/or bluetooth connections
⢿⡄⠘⠷⠚⠋⠀in wearable computing?
⠈⠳⣄ A: No, that would be mixed fabric, which Lev19:19 forbids.

Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

[Adam Borowski]

On Thu, Feb 16, 2023 at 11:05:42AM +0800, kevin wrote:
>  * Package name : libkysdk-base
>Version  : 1.0.1-1

>  libkysdk-base (1.0.1-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #1031344)

Hi!
Alas, the package fails to build:

.
dh_missing: warning: etc/kysdk/kysdk-base/kylog-rotate-default exists in 
debian/tmp but is not installed to anywhere (related file: 
"src/log/kylog-rotate-default")
dh_missing: warning: usr/include/kysdk/kysdk-base/libkylog.h exists in 
debian/tmp but is not installed to anywhere (related file: "src/log/libkylog.h")
dh_missing: warning: usr/include/kysdk/kysdk-base/listdata.h exists in 
debian/tmp but is not installed to anywhere (related file: 
"src/utils/data-structure/linklist/listdata.h")
dh_missing: warning: usr/include/kysdk/kysdk-base/skip_linklist.h exists in 
debian/tmp but is not installed to anywhere (related file: 
"src/utils/data-structure/linklist/skip_linklist/skip_linklist.h")
dh_missing: error: missing files, aborting

While detecting missing files, dh_missing noted some files with a 
similar name to those
that were missing.  This error /might/ be resolved by replacing 
references to the
missing files with the similarly named ones that dh_missing found - 
assuming the content
is identical.

As an example, you might want to replace:
 * src/log/kylog-rotate-default
with:
 * etc/kysdk/kysdk-base/kylog-rotate-default
in a file in debian/ or as argument to one of the dh_* tools called 
from debian/rules.
(Note it is possible the paths are not used verbatim but instead 
directories 
containing or globs matching them are used instead)

Alternatively, add the missing file to debian/not-installed if it 
cannot and should not
be used.

The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libkysdk-base (0), libkysdk-base-dev (1), 
libkysdk-config (2), libkysdk-config-dev (3), libkysdk-log (5), 
libkysdk-log-dev (3), libkysdk-timer (2), libkysdk-timer-dev (3), 
libkysdk-utils (4), libkysdk-utils-dev (9)
 * dh_installdocs: libkysdk-base (0), libkysdk-base-dev (0), 
libkysdk-config (0), libkysdk-config-dev (0), libkysdk-log (0), 
libkysdk-log-dev (0), libkysdk-timer (0), libkysdk-timer-dev (0), 
libkysdk-utils (0), libkysdk-utils-dev (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
`


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1029754: please support telling the architecture of a vmlinuz image

[Adam Borowski]

On Wed, Jan 25, 2023 at 08:58:47AM +0100, Helmut Grohne wrote:
> arch-test already is great, but maybe it can do even more. I would like
> to know which architecture corresponds to a given vmlinuz image.
> 
> A vmlinuz image tends to consist of a boot stub followed by a compressed
> ELF image. The compression scheme varies and we don't exactly know where
> the compressed image starts. A relatively hacky way to do this is runnig
> linux.git/scripts/extract-vmlinux and then feeding the output to
> elf-arch. Maybe we can pull part of this functionality into arch-test?

I looked into it, but it seems that extract-vmlinux will fail at least for
uncompressed EFI kernels: it won't skip the PE wrapper to get to ELF.

And apparently I'm too much of an idiot to find how the wrapper's length is
stored within over multiple hours of searching.  While I bet I could solve
the problem after some more thinking, I'll prioritize other stuff for now.

> There is not much ugrency to this. It just feels like arch-test would be
> the right place to own this functionality. Thanks for considering. If
> you end up considering this out-of-scope (e.g. due to the need for
> various decompressors), don't hesitate to close this as wontfix.

It's a valid request, I'm just a bit short on tuits these days.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1030950: btrfs-convert is built without support for reiserfs

[Adam Borowski]

Control: clone -1 -2
Control: reassign -2 reiserfsprogs
Control: retitle -2 please provide the library
Control: block -1 by -2

On Thu, Feb 09, 2023 at 10:07:56PM +0100, Oswald Buddenhagen wrote:
> Package: btrfs-progs
> Version: 6.1.2-1
> Severity: normal
> 
> for the purpose of helping people to move away from reiserfs, it would 
> make sense to actually build btrfs-convert with support for it.
> 
> the catch is that libreiserfscore is not packaged separately; rather, 
> it's built into reiserfsprogs. i guess factoring out a static-only 
> libreiserfscore-dev would make sense.

This would require help from the src:reiserfsprogs side.  I'm thus cloning
accordingly.

Too bad, the freeze blocks the usual ways of introducing such a library. 
There are ways to work around that but none are pretty.

But, it's Felix (reiser maintainer) who knows how the library looks like;
compiling against a library is trivial in comparison.  Thus, it's him who
can enlighten us.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1030633: marked as done (RFS: fdflush/1.0.1.3+nmu1 [NMU] [RC] -- Flush out-of-date disk buffers)

[Adam Borowski]

On Wed, Feb 08, 2023 at 04:24:06AM +, Debian Bug Tracking System wrote:
> Version: 1.0.1.3+rm
> 
> Dear submitter,
> 
> as the package fdflush has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.
> 
> For details on the removal, please see https://bugs.debian.org/1030754

Well, what I suggested was orphaning the package rather than removing, but
you're right, the latter is probably for the better.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1030589: RFS: libhx/4.10-1 -- C library providing queue, tree, I/O and utility functions

[Adam Borowski]

On Sun, Feb 05, 2023 at 01:09:53PM +0100, Jörg Frings-Fürst wrote:
>  libhx (4.10-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Declare compliance with Debian Policy 4.6.2.0 (No changes needed).
>* Fix lintian overrides.
>* debian/watch:
>  - Bump standard version to 4.
>  - Switch to new download URL.
>* debian/copyright:
>  - Refresh years.
>  - Add year 2022 to myself.
>* Refresh symbols files.
   ^^
>* debian/libhx-dev.lintian-overrides:
>  - Add override for no-code-sections.

The symbols don't seem to be up to date.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1030633: RFS: fdflush/1.0.1.3+nmu1 [NMU] [RC] -- Flush out-of-date disk buffers

[Adam Borowski]

On Sun, Feb 05, 2023 at 11:10:28PM +0100, Gioele Barabucci wrote:
>  fdflush (1.0.1.3+nmu1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* d/rules: Update to debhelper 13 (Closes: #939725, #965520, #999200)
>* d/source: Use 3.0 (native) format
>* d/control: Update standards version to 4.6.2
>* Makefile: Do not force installation with root user
>* d/control: Specify Rules-Requires-Root: no
>* debian/copyright: Update and convert to DEP-5

Hi!
These changes are not something that's fit for a NMU.
On the other hand, a QA upload is long overdue...

Could you please orphan the package?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1028388: Processed: Re: Processed: reassign 1028388 to orphan-sysvinit-scripts

[Adam Borowski]

On Sun, Feb 05, 2023 at 04:34:23PM +0100, Michael Biebl wrote:
> Apologies to the orphan-sysvinit-scripts maintainers. Only after the
> reassignment from Adam I noticed that he is not actually a maintainer of it
> and he is playing pointless BTS ping-pong.

Refrigerator, kettle, black?

> I asked the BTS admins to step in here.

Based on this bug's history, the BTS admin's action would be welcome,
indeed.  Because, comparing the contents of my mail and your response,
I have trouble assuming a lack of malice.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1028388: Processed: reassign 1028388 to orphan-sysvinit-scripts

[Adam Borowski]

Control: reassign -1 rsyslog

On Sun, Feb 05, 2023 at 12:54:03PM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> Bug #1028388 [orphan-init-scripts] Please restore the init script for 
> ad-hocery, tests, etc.
> Warning: Unknown package 'orphan-init-scripts'
> Bug reassigned from package 'orphan-init-scripts' to 
> 'orphan-sysvinit-scripts'.
> Ignoring request to alter found versions of bug #1028388 to the same values 
> previously set
> Ignoring request to alter fixed versions of bug #1028388 to the same values 
> previously set
> > thanks
> Stopping processing here.

That's not helpful.  The bug is not "please implement an init script",
it's "please restore it in the package that ships the daemon".

The o-s-s package has an implementation that works in the _usual_ cases.
But here we have at least two legitimate but less widespread uses:
 * running the daemon by hand / initless (Ian)
 * a preinstalled system by mavens from Oracle Cloud (which is as solid as
   its name suggests) that I tried to sanitize but apparently missed
   something
and that's just a tiny slice of things that Debian users do.

Ie, despite all the efforts, the o-s-s machinery fails in some corner cases,
and it appears it's either not possible to make it handle such cases or it'd
require ideas that elude us at the moment (do you have a suggestion?).  All
of which can be trivially fixed by just statically shipping the init script
in the daemon package just like everything but a few daemon packages in
Debian do.

While, per the GR, init script support is "only" a "should" rather than
"must", here we have:
 * a very prominent package
 * ... that, according to your words, is redundant on systemd
 * ... but is vital for everyone else
 * had an init script for 1½ decades -- which is not known to have regressed
 * there's no dearth of users+DDs who test and provide patches
 * it's not easy to "explore alternatives" without basic logging

Ie, expectations are different for a core package than for some random
doodad, and here you're doing a disservice to the majority of remaining
users when the package is no longer installed by default on systemd.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1028388: marked as done (Please restore the init script for ad-hocery, tests, etc.)

[Adam Borowski]

Control: reopen -1
Control: severity -1 important

(Rationale: with systemd users apparently not requiring logs that survive a
crash, most users of this package in bookworm+ are expected to run other
inits -- and the package as-is is non-functional.)

On Sat, Feb 04, 2023 at 05:30:06PM +, Debian Bug Tracking System wrote:
> [...] marked as done.

> I find the mechanism provided by orphan-init-scripts more than sufficient
> for niche use cases like the above and thus don't intend to re-introduce the
> SysV init script.

I just installed a new box, and I see that rsyslog is not started, despite
orphan-init-scripts being installed (I'll need to find out why, busy rn).

Thus, evidently the hacks required for o-i-s to mess with conffiles on
installation of a different package are not robust enough.  This can be
argued to be a bug in o-i-s -- but all this complexity shouldn't be needed
in the first place.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1030265: RFS: ruby-mdl/0.12.0-3 -- Markdown lint tool

[Adam Borowski]

On Wed, Feb 01, 2023 at 08:22:56PM +0100, Norwid Behrnd wrote:
>  ruby-mdl (0.12.0-3) unstable; urgency=medium
>  .
>* correct maintainership and address
>* correct upstream/metadata, addresses
>* provide two scripts to collect contributor list debian/copyright
>* use consistently ruby-mdl in/by man page to refer to the package
>* move package from section ruby to section text

Oif, the man page itself shouldn't be renamed.  As the executable in $PATH
is "mdl", the man page should be named so.

I'm not thinking right on the wrong side of dusk -- heck, it was barely the
crack of noon :/


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1030395: mk-build-deps: adds bogus arch qualifiers

[Adam Borowski]

Package: devscripts
Version: 2.22.2
Severity: normal

[an arm64 box]# dpkg -i /tmp/zst-build-deps_0.2-1_all.deb 
Selecting previously unselected package zst-build-deps.
(Reading database ... 35686 files and directories currently installed.)
Preparing to unpack .../zst-build-deps_0.2-1_all.deb ...
Unpacking zst-build-deps (0.2-1) ...
dpkg: dependency problems prevent configuration of zst-build-deps:
 zst-build-deps depends on build-essential:amd64.

The package in question has:
Build-Depends: debhelper-compat (= 13),
 cmake,
 libbz2-dev,
 liblzma-dev,
 libz-dev,
 libzstd-dev (>> 1.4~),
 bzip2,
 xz-utils,
 zstd,

-- as you see, there's not a single bit that differs based on arch.
Thus, it makes no sense to invent such a qualifiers.

Alternatively, if, to simplify implementation, you assume that the B-Deps
always differ per-arch, the resulting dependency package should be arch:any
rather than arch:all.



Meow!
-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBCHANGE_RELEASE_HEURISTIC=log
DEBSIGN_KEYID=FD9CE2D8D7754B78AB279BBD2C3B436FEAC68101
DSCVERIFY_KEYRINGS="~/.gnupg/pubring.gpg"

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-rc6-00035-ge75b49cddeeb (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.19
ii  fakeroot  1.30.1-1.1
ii  file  1:5.44-3
ii  gnupg 2.2.40-1
ii  gpgv  2.2.40-1
ii  libc6 2.36-8
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.67-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.1-3
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.5.5
ii  curl7.87.0-2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput-ng [dput]  1.35
ii  equivs  2.3.1
ii  libdistro-info-perl 1.5
ii  libdpkg-perl1.21.19
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.26-2
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-2
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck3.3.5-1
ii  lintian 2.116.2
ii  man-db  2.11.2-1
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.5.2+b1
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.1-0.1
ii  unzip   6.0-27
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.1

Versions of packages devscripts suggests:
pn  adequate  
ii  at3.2.5-1+b1
ii  autopkgtest   5.28
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20220412cvs-1
ii  build-essential   12.9
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 13.11.4
pn  diffoscope
pn  disorderfs
ii  dose-extra7.0.0-1+b2
pn  duck  
pn  elpa-devscripts   
ii  faketime  0.9.10-2.1
pn  gnuplot   
pn  how-can-i-help
ii  libauthen-sasl-perl   2.1600-3
pn  libdbd-pg-perl
ii  libfile-desktopentry-perl 0.22-3
pn  libnet-smtps-perl 
ii  libterm-size-perl 0.211-1+b2
ii  libtimedate-perl  2.3300-2
pn  libyaml-syck-perl 
ii  mmdebstrap1.3.1-2
pn  mozilla-devscripts
ii  mutt

Bug#1027364: golang-github-go-co-op-gocron: FTBFS (missing build-depends on tzdata)

[Adam Borowski]

Control: close 1027364

On Sat, Jan 28, 2023 at 04:31:25PM +0100, Santiago Vila wrote:
> retitle 1027364 golang-github-go-co-op-gocron: FTBFS (missing build-depends 
> on tzdata)
> reopen 1027364
> found 0.5.0-2
> thanks
> 
> Adam, please don't close bugs just because they say "bullseye" in the title.
> In most cases, I really meant "bullseye and later".

I've just re-tested:

Distribution: bullseye
Host Architecture: amd64
Source-Version: 0.5.0-2
Status: successful

So the package does build ok.  Do you have an example of a build environment
that is not explicitly declared "totally broken" by the Policy (§2.5)?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1027905: not reproducible in a valid sbuild chroot

[Adam Borowski]

Control: tags -1 +unreproducible
Control: severity -1 wishlist

Hi!
You've done a MBF despite _negative_ consensus in several discussions
(debian-devel, debootstrap, policy, ...); folks seem to be in agreement
that either the Policy doesn't require building in an environment that
is explicitly "totally broken" (§2.5), or at least that the issue is
not RC.

Thus: is there a way to reproduce this failure without intentionally
removing tzdata?  If not, I believe this bug should be closed -- and,
if the change has already been applied in git, that it should be
reverted.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1029430: it's not tzdata

[Adam Borowski]

Control: tag -1 -patch

Hi!
The alleged patch doesn't fix the FTBFS.  Besides the non-bug (per numerous
discussions on debian-devel and elsewhere) of non-depending on a required
package "tzdata", the package fails from an actual build failure even in
a non-sabotaged build chroot.

I'm thus untagging "patch".


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#919348: bring it in for Bookworm?

[Adam Borowski]

Hi!
Would you be willing to reconsider for Bookworm?

While you do have reservations about xfce4-screensaver, the question is
not whether it's perfect, but how it fares against alternatives.  And
lightm-locker is so buggy it's outright useless for a good deal of users
while reports for xfce4-screensaver are better.

Thus even if not default, it'd be good to have it as an alternative --
at least installable.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Adam Borowski]

On Fri, Jan 20, 2023 at 03:57:17PM +0200, Wouter Verhelst wrote:
> On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote:
> > Preferring to use Unicode does seem to be the direction that all of
> > computing is going in, as a simplifying assumption - for example W3C
> > advice for HTML is "You should always use the UTF-8 character encoding"[1]
> > - and as we know, things that aren't tested usually don't work. So I
> > think the level of functionality for non-UTF-8 locales and encodings in
> > the software we package is going to decline over time, whether Debian
> > wants it to or not.
> 
> If the world's most populous country uses something that is not UTF-8, I
> think it's safe to say it's being tested, if only by people who will
> file bugs when things go awry.

And we do know there's not a single bug filed with a GB* locale within the
last 12 years.

There's far fewer reports from Chinese people than the population would
indicate: 0.75% of those with locale information, but that's still 3241
reports; I find it implausible that there's a non-negligible number of
users that go with GB* yet not a single of them gave a single bit of
feedback.

> If the PRC government *requires* a non-UTF-8 encoding for things sold to
> them, we would be doing our users who want to sell a product containing
> Debian to the PRC government a disservice by dropping support for it
> altogether.

It appears to me they require the character _set_ but not encoding: ie,
that all glyphs can be displayed, they can be entered from keyboard, etc.
The standard talks a lot about font support, etc.

> We don't have to ensure it works perfectly out of the box; just that
> support is achievable with a reasonable amount of work.

Our installer doesn't allow choosing such a locale, thus if indeed the
encoding not character set is legally required, then we'd need to change
so before the release.

But I don't expect that to be the case -- a few years ago I played with
Deepin and don't remember any weird encoding being used.  It would be good
to either check again, or ask one of their maintainers.

But for now, I gotta run.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1021079: NMU w/o ppc64el?

[Adam Borowski]

On Mon, Jan 16, 2023 at 08:26:37AM +0200, Konstantinos Margaritis wrote:
> On 15/1/23 03:33, Adam Borowski wrote:
> > Hi!
> > As you're apparently too busy to either fix ppc or suggest a different plan,
> > I'd make a NMU dropping ppc64el for now so the package can be released with
> > Bookworm.
> > 
> > Please say if I shouldn't.

> It is true that I am busy during this period, which may explain the lack of
> communication. Now regarding vectorscan w/o ppc64le, I have 2 serious bugs I
> want to fix before a new version upload (5.4.9), one is on Arm (a regression
> compared to x86) and the other is the failure on ppc64le. How long do I have
> to make an upload and ensure bookworm release? If that is too soon, then I
> will make an upload asap myself disabling ppc64le until I fix this locally.

Feb 12 is the cut-off; the package must be in testing at that time.  Then if
you have autopkgtests (vectorscan does), there's two more months before hard
freeze.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1029017: RM: pmdk-convert -- ROM; useless, killed upstream

[Adam Borowski]

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


Hi!
Please remove pmdk-convert.  It can be used only to upgrade on-memory data
from old releases of pmdk which haven't even been in Debian.  While pmdk
itself stays, it has managed to avoid format compat breakages that would
require offline manual conversion for quite a long time.  And the fancy
structures have been used only for high-level stuff that has been just
killed upstream.  Other stacks that have been built atop pmdk don't use
that -- and in the very unlikely case a conversion would be needed in
the future, we can revive the package.  For now, though, it has been killed
upstream -- and considering flaws in its design, I'd rather rewrite the
converter from scratch.

Thus: please send pmdk-convert to the great bit bucket in the sky.

Bug#1029016: RM: libpmemobj-cpp, pmemkv, pmemkv-python -- ROM; low popcon, freshly dead upstream

[Adam Borowski]

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


Hi!
Please remove the following packages:
 * libpmemobj-cpp
 * pmemkv
 * pmemkv-python
They form a stack that has just been discontinued.  As you still need
a fat mucho-$$$ server to use hardware this software requires for any
non mocked up purpose, it doesn't have any real popcon.

Note: while the description of libpmemobj-cpp speaks mostly about it
being bindings for libpmemobj which stays, in fact it turned into a
massive project that implemented the real guts of pmemkv.  While in
theory one could use parts of that library for pmemobj, I wouldn't
do so without upstream maintenance.  Thus, let's send it to a nice
pasture...

Bug#1029014: RM: vmemcache -- ROM; low popcon, cancelled upstream

[Adam Borowski]

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


Hi!
Please remove vmemcache.  This library has been declared unmaintained
upstream, and it has no reverse dependencies nor popcon to speak of.

Bug#1029013: RM: miniasync -- ROM; experimental library, development cancelled

[Adam Borowski]

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


Hi!
Please make miniasync an unthing.  While it's mostly functional, upstream
development of projects miniasync was meant for has been cancelled, making
miniasync itself a casualty as well.  I wouldn't recommend anyone to use the
library at its present stage, and with no one to finish it... oh well...

There are no users in Debian.

Bug#1021079: NMU w/o ppc64el?

[Adam Borowski]

Hi!
As you're apparently too busy to either fix ppc or suggest a different plan,
I'd make a NMU dropping ppc64el for now so the package can be released with
Bookworm.

Please say if I shouldn't.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1028529: RFS: libfilezilla/0.41.0-1 -- build high-performing platform-independent programs (runtime lib)

[Adam Borowski]

On Fri, Jan 13, 2023 at 05:15:29AM +, Philip Wyett wrote:
> I thought any change to push soname bumps through experimental was still only 
> a discussion?
> 
> As you are aware, libfilezilla is only consumed by filezilla and any
> soname bumps are not dangerous to other libaries or applications.  Could
> this change pass through directly to unstable if I modify the changelog to
> state this fact?

I think so, yeah.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1028529: RFS: libfilezilla/0.41.0-1 -- build high-performing platform-independent programs (runtime lib)

[Adam Borowski]

On Thu, Jan 12, 2023 at 12:05:10PM +, Philip Wyett wrote:
>  libfilezilla (0.41.0-1) unstable; urgency=medium
>  .
>* New upstream version 0.41.0
>* Soname bump rename package to libfilezilla34

Hi,
the ftp team has requested that soname bumps go through experimental,
because of transition freeze, and that requests to do otherwise are
clearly marked in the changelog, saying why.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk,
⣾⠁⢠⠒⠀⣿⡁   ash nazg gimbatul,
⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk
⠈⠳⣄   agh burzum-ishi krimpatul.

Bug#1021079: disable the ppc64el binary for now?

[Adam Borowski]

Hi!
As the window for new packages to [re-]enter bookworm will close soon,
and fixing vectorscan on ppc doesn't appear to be coming, what about
disabling that arch for now?

It is described as "in development", thus it's not surprising it's
not working yet.  It'd be shame for the package to miss bookworm.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1028314: RM: librpmem* -- NBS; librpmem dropped upstream

[Adam Borowski]

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


Hi!
Please remove the following binary packages, no longer built by src:pmdk :
 * librpmem1
 * librpmem1-debug
 * librpmem-dev
They have been removed upstream for the upcoming 1.13, and I've just removed
them in 1.12.1-2 so there'll be no ftpmaster action required during freeze.

Bug#1028209: RFS: mailgraph/1.14-20 -- RRDtool frontend for Mail statistics

[Adam Borowski]

On Sun, Jan 08, 2023 at 04:27:03PM +0100, Jörg Frings-Fürst wrote:
>  mailgraph (1.14-20) unstable; urgency=medium
>  .
>* Declare compliance with Debian Policy 4.6.2.0 (No changes needed).
>* Update Brazilian Portuguese debconf templates translation
>  (Closes: #1028075).
>* debian/copyright:
>  - Add year 2023 to myself.

Hi!
I'm afraid you lose the changelog entry for 1.14-19.1 (NMU), please add it
back.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ “Exegi monumentum aere perennius” -- “I made a monument more
⢿⡄⠘⠷⠚⠋⠀ durable than bronze”.
⠈⠳⣄   -- Horace (65-8 BC), leaving the loo, constipated

Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)

[Adam Borowski]

Control: severity -1 wishlist
Control: tags -1 +wontfix

On Sun, Jan 01, 2023 at 11:49:26PM +0100, Santiago Vila wrote:
> [ Thanks for fixing the bug in unstable so fast ]

... too fast, in fact.  Per the discussion on debian-policy, it's not a bug,
and this way I have a redundant dependency which actually is a bug (for a
good reason: it makes it harder to reorganize unrelated packages).

I've thus reverted the change -- in git, not worth a separate upload.

> > I'm all for fixing bugs in stable that:
> >   * are obviously bugs (rather than a point of debate)
> 
> You are the only one debating this, but it should really not be a point of 
> debate.

Per debian-policy, indeed.  Good that the debate has been resolved.

[...]
> [ In fact, I wonder why you bothered to add the missing B-D if you really 
> believe it
> is not a bug.

Because I considered doing so to be less effort than arguing.  Which has
proven to be premature.

[...]

> I think it is important to honor the promises we made to the users. We
> promised a stable release without FTBFS bugs, and we are almost delivering
> it, but not completely.
> 
> In the end, it boils down to where do we draw the line. You think having
> a reduced number of packages which FTBFS according to Policy is ok. I think
> the only acceptable number of FTBFS bugs to have in a stable release is zero,
> and I am working towards such goal.

Here I agree, but inventing new bugs where there's no FTBFS is not helpful.

"FTBFS" means the package actually fails to build from source, using
any of build machinery present in the archive, on a realistic
hardware/kernel/setup, for a distribution the given bug is marked as
affecting.

Thus, for example: a FTBFS with a future version of gcc or with buildflags
that are not enabled yet is not a RC bug, becoming serious only once such a
compiler/configuration is actually uploaded to unstable.  Likewise, a change
to the build environment where tzdata is no longer available, would be RC
only in unstable but not in bullseye.
 
> So the only thing I ask is that you do not insist that this is not a bug
> when I reopen it for bullseye. Since I will be the one doing the work,
> I think I should be allowed to use the BTS to track those bugs.

Okay, I'm not closing the bug for bullseye.  I did though reduce the
severity to wishlist as it's (per the debian-policy discussion) neither
RC nor even contravening bullseye's nor current unstable's policy,
and the change is opposed by a number of people.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line:
⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day."
⠈⠳⣄

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Adam Borowski]

On Mon, Jan 02, 2023 at 04:43:34PM -0800, Noah Meyerhans wrote:
> > Debian's default sysctl settings should reside in procps (as it owns
> > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> > package.
> 
> Is that documented anywhere?  It's certainly not the case today:
> 
> $ for i in /usr/lib/sysctl.d/*.conf; do
>   dpkg -S $i
> done
> tracker-miner-fs: /usr/lib/sysctl.d/30-tracker.conf
> bubblewrap: /usr/lib/sysctl.d/50-bubblewrap.conf
> systemd-coredump: /usr/lib/sysctl.d/50-coredump.conf
> systemd: /usr/lib/sysctl.d/50-pid-max.conf
> procps: /usr/lib/sysctl.d/99-protect-links.conf

$ apt-file search /etc/sysctl
ceph-osd: /etc/sysctl.d/30-ceph-osd.conf  
corekeeper: /etc/sysctl.d/corekeeper.conf
lxc: /etc/sysctl.d/30-lxc-inotify.conf
lxd: /etc/sysctl.d/10-lxd-inotify.conf
octavia-agent: /etc/sysctl.d/octavia-agent-sysctl.conf
open-infrastructure-container-tools: /etc/sysctl.d/zz-container.conf
open-infrastructure-system-images: 
/usr/share/system-images/container-server/config/includes.chroot/etc/sysctl.d/net.ipv4.ip_forward.conf
procps: /etc/sysctl.conf
procps: /etc/sysctl.d/README.sysctl
systemd: /etc/sysctl.d/99-sysctl.conf
tup: /etc/sysctl.d/unprivileged-clone.conf

Most settings are in /etc/sysctl.conf, especially network related ones.

That /usr/lib/sysctl.d/ path doesn't have its settings applied normally.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Adam Borowski]

On Tue, Jan 03, 2023 at 12:43:31AM +0100, Marco d'Itri wrote:
> On Jan 02, Noah Meyerhans  wrote:
> > I'm entirely happy to reassign this request to systemd and have the
> > setting applied more broadly.
> Some options:
> - conflict with systemd < version_with_the_new_default
> - wait for a full release and then just drop it
> - when sysctl in postinst reports the new default
> - a mix of the last two options

Debian's default sysctl settings should reside in procps (as it owns
/sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
package.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)

[Adam Borowski]

On Sun, Jan 01, 2023 at 01:53:31PM +0100, Santiago Vila wrote:
> Adam Borowski escribió:
> > nor any of people running archive rebuilds so far.
> 
> FWIW: I am one of those people running archive rebuilds.
> I rebuilt the entire bullseye distribution, and I'm trying
> to make it FTBFS bug free, as mandated by both Debian Policy
> and Release Policy.

Bullseye has been a non-moving target for two years, thus changing
requirements packages there are expected to meet is grossly belated.
There are cases where adding such a requirement is worth the effort
(eg. new hardware, or a hitherto unknown type of bugs), but I don't
see how something with no practical benefit qualifies.

This doesn't mean I intend to stop your efforts for releases currently
in development -- I've already fixed this very bug in unstable (even
though I disagree with the premise).  But doing this for stable...
come on...


On Sun, Jan 01, 2023 at 01:46:06PM +0100, Santiago Vila wrote:
> El 1/1/23 a las 12:58, Adam Borowski escribió:
> > Control: tags -1 +unreproducible moreinfo
> 
> I don't think the unreproducible tag applies here.
> 
> To reproduce, just try to build it in a chroot which does
> not include tzdata. If debootstrap does not do that by default,
> then it follows that you should not simply accept debootstrap's defaults.

No tool in Bullseye produces such build chroots, and this is what matters
here.  There's no practical benefit of retroactively changing packages:
neither security rebuilds nor packages built by the users themselves will
lack tzdata (the former because of build tools, the latter because of how
Policy 2.5 defines "required").

Thus: I argue this is not a bug, and that even if it actually is a bug,
there are no practical benefits of fixing it in _stable_.

We are free to redefine requirements for future releases, of course.

> This is Policy 4.2:
> 
> > If build-time dependencies are specified, it must be possible to build the
> > package and produce working binaries on a system with only essential and
> > build-essential packages installed and also those required to satisfy the
> > build-time relationships > (including any implied relationships).
> 
> So yes, this is undoubtedly a bug, because tzdata is not build-essential.

It is.  It is merely not included in the _informational_ list shipped by
a metapackage by that name; it explicitly says:

# This package is NOT the definition of what packages are
# build-essential; the real definition is in the Debian Policy Manual.
# This package contains merely an informational list, which is all
# most people need.   However, if this package and the manual disagree,
# the manual is correct.

And Policy 4.2 which you just quoted says:

# (including any implied relationships)

I'd say that the Policy declaring systems that lack Priority:required
packages to be broken fulfills this clause.

> I could agree that everything would be easier if debootstrap was fixed once 
> and forever:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060
> 
> If you can push for that bug to be fixed for bookworm, that would certainly 
> help.

It seems that multiple debootstrap maintainers disagree -- and so do I.
But, as I said before, I have no real objections to changing this for
Bookworm.  Making an upload to add the B-Dependency was less effort than
arguing, and I've already one so, thus complying with whatever rule wins.

> > I have nothing against adding such a B-Dependency in unstable: this is where
> > new development is supposed to be done, preparing a new upload costs but a
> > few mins of my time.  On the other hand, updating stable requires extensive
> > process and wastes the time of me, the Release Team, of people preparing the
> > new point release announcement, of users testing and deploying the update.
> 
> Of course fixing bugs takes a little bit of time, but it may also be argued 
> that
> not fixing this kind of bugs produces weird effects which makes some people 
> to lose
> some of their time (for example, me building the whole archive trying to keep 
> stable free
> from any kind of FTBFS bugs).

These bugs are caused only by your intentional change to build chroots
you use.  You can save that time by not doing that _active_ step for past
releases.

> If, despite having a trivial fix for the bug, you decide
> not to fix it in stable and leave the fix for others, I will have less time 
> for other things
> which I also want to fix. I know that some people will not agree, but I 
> believe fixing
> FTBFS bugs in stable should be primarily a responsibility of the affected 
> maintainers.
> Offloading the work to those particularly interested in stable does not scale 
> well.

I'm all for fixing bugs in stable that:

Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)

[Adam Borowski]

Control: tags -1 +unreproducible moreinfo

On Fri, Dec 30, 2022 at 07:04:09PM +0100, Santiago Vila wrote:
> Package: src:safeclib
> Version: 3.5-3
> Severity: serious
> Tags: ftbfs patch

> During a rebuild of all packages in bullseye, your package failed to build:

> FAIL: t_gmtime_s
> FAIL: t_localtime_s
> PASS: t_getenv_s
> PASS: t_bsearch_s
> PASS: t_qsort_s

I can't reproduce the failure using any of common menthods of creating a
build chroot.  Neither could the buildds nor any of people running archive
rebuilds so far.

Is there any way _relevant for bullseye_ that would produce the build chroot
without a Priority:required package such as tzdata?

If not, I don't believe this is a bug for stable.  Not merely a serious bug,
not a bug at all -- it can't happen on buildds nor on user systems.

I have nothing against adding such a B-Dependency in unstable: this is where
new development is supposed to be done, preparing a new upload costs but a
few mins of my time.  On the other hand, updating stable requires extensive
process and wastes the time of me, the Release Team, of people preparing the
new point release announcement, of users testing and deploying the update.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git

[Adam Borowski]

On Sat, Nov 19, 2022 at 11:29:15PM +0100, Christoph Anton Mitterer wrote:
> Hey Jonas :-)

Jonas, ping: any chance of uploading this?

> On Thu, 2022-11-17 at 18:45 +0100, Jonas Smedegaard wrote:
> > What helps the most, and also seems possibly, is to name it
> > "delta" - just not right now - and with that long-term plan I think
> > it
> > is double confusing to introduce a _third_ name (since the name
> > "git-delta" has already been introduced by some downstreams).
> 
> Well the best would be if upstream could give another name, but if
> that's unlikely... this might be the best option.

The executable name is free.

> > Oke way you can help is to initiate the process of (attempting to) kick
> > out (or alternatively rename) current package "delta" from Debian.

> I'm not really sure whether I like this either. ;-)
> 
> I had a small look at the current "delta" package, and while the
> package is maintained by the QA group and the upstream website
> (http://delta.tigris.org/) named in the copyright file seems dead...
> the program might be still useful to some people... and it had the name
> first.

Its use is basically mandatory any time you submit a bug to gcc, thus
there's no chance it goes away -- even if indeed no one is stepping up
for full-time maintenance.  It's just code that works well enough, and
doesn't seem to require new upstream updates basically ever.

> Asking them now to rename,... well even if done politely, they may feel
> somehow obligated to do... or even drop the package at all, which I
> think would be bad.

A package rename would take at least a couple of Debian releases, thus
isn't something that works in a reasonable timeframe.

Thus, you'd need to upload as git-delta or such now, then maybe be able
to take over the name in the future...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1026823: RFS: zvbi/0.2.39-1 -- Vertical Blanking Interval (VBI) utilities

[Adam Borowski]

On Wed, Dec 21, 2022 at 07:04:11PM +0200, Ileana Dumitrescu wrote:
>  zvbi (0.2.39-1) unstable; urgency=medium
>  .
>* New upstream release.
>* debian/rules: Remove NOCONFIGURE=1.

✓

> I am also hoping to work with a mentors team member to help secure a key
> endorsement for my DM application. Please let me know what I can do!

The old way involves meeting in person, briefly waving a government-looking
id in the face of someone who has no ability to verify the id's authenticity
in any way -- and, as we joke, an id is valid if the photo doesn't look like
you as that's how real ids look (only a forger would be a try-hard enough to
get a photo that actually resembles you!).  And it's trivial to get fakes
that are good enough to fool professionals anyway.

The new way is to have a quick video chat (in order to ascertain you didn't
hire a random drunkie), and wave aforemented government-looking id.

In either case, you can use any DD, me included.
 * for a physical meeting, you're probably far from Gdańsk, Poland
 * but you likely have a camera-equipped device

Thus: if you're not afraid of the trauma of seeing my face, I'm a valid
endorser.  Or you can ask anyone else...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1026358: RFS: streamlink/5.1.2-1 -- CLI for extracting video streams from various websites to a video player

[Adam Borowski]

On Mon, Dec 19, 2022 at 01:19:03AM +0100, Alexis Murzeau wrote:
> streamlink (5.1.2-1) unstable; urgency=medium
> 
>* New upstream version 5.1.2
>* d/README.source: update instructions
>* d/streamlink.{install,manpages}: update completion scripts location
> 
>   -- Alexis Murzeau   Mon, 19 Dec 2022 00:25:14 +0100

Hi,
this upload uses an old version of debian/changelog for 5.1.1-1:

 streamlink (5.1.1-1) unstable; urgency=medium
 
   * New upstream version 5.1.1
-  * Control: add build-dep on python3-certifi.
 
- -- Alexis Murzeau   Tue, 29 Nov 2022 08:51:03 +
+ -- Alexis Murzeau   Mon, 28 Nov 2022 21:49:55 +0100

Please update that to be same as in the archive.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢠⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Adam Borowski]

On Mon, Dec 19, 2022 at 07:08:09PM +, Simon McVittie wrote:
> On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote:
> > As of Bookworm, legacy locales are no longer officially supported.
> 
> For clarity, I think when you say "legacy locales" you mean locales
> whose character encoding is either explicitly or implicitly something
> other than UTF-8 ("legacy national encodings"), like en_US (implicitly
> ISO-8859-1 according to /usr/share/i18n/SUPPORTED) and en_GB.ISO-8859-15
> (explicitly ISO-8859-15 in its name). True?

Aye.

> Many of the non-UTF-8 encodings are single-byte encodings in the
> ISO-8859 family, but if I understand correctly, your reasoning applies
> equally to multi-byte east Asian encodings like BIG5, GB18030 and EUC-JP.
> Also true?

Aye.  Anything but UTF-8.

> Meanwhile, locales with a UTF-8 character encoding, like en_AG
> (implicitly UTF-8 according to /usr/share/i18n/SUPPORTED) or en_US.UTF-8
> (explicitly UTF-8), are the ones you are considering to be non-legacy.
> Also true?

Right.

> I think for Policy use, this would have to say something more precise,
> like "locales with a non-UTF-8 character encoding". I wouldn't want to
> get en_US speakers trying to argue that en_GB.UTF-8 is a legacy locale,
> or en_GB speakers like me trying to argue that en_US.UTF-8 is a legacy
> locale :-)

English (traditional) vs English (simplified) :p

> When you say "officially supported" here, do you refer to the extent
> to which they are supported by the glibc maintainers, or some other
> group? Or are you describing a change request that they *should not*
> be officially supported by Debian - something that is not necessarily
> true yet, but in this bug you are asking for it to become true?

My primary source is glibc, especially the debconf questions from "locales",
although bit-rot and/or outright droppage is widespread in other packages.

> > * Software may assume they always run in an UTF-8 locale, and emit or
> >   require UTF-8 input/output without checking.
> 
> I suspect this is already common: for example, ikiwiki is strictly
> UTF-8-only and ignores locales' character sets, which is arguably a bug
> right now but would become a non-bug with your proposed policy.

Exactly, I want to declare that a non-bug, thus saving developer time.

> This is a "may" so it can't possibly make a package gain bugs. It might
> make packages have fewer bugs.

Aye.

> > * The execution environment (usually init system or a container) must
> >   default to UTF-8 encoding unless explicitly configured otherwise.
> 
> Is this already true? This seems like the sort of thing which should be
> fixed in at least the major init systems and container managers before it
> goes into Policy, in the interests of not making those init systems and
> container managers retroactively buggy.

Systemd does so since version 240, sysvinit relies on settings in /etc/
thus in the case of bare debootstrap the variables might be unset -- which
is mostly moot since glibc 2.35.  We briefly discussed an one-line patch
to ensure there's a fallback default, it's currently not applied (but can
be).  This would be relevant only for corner cases like an unconfigured
system running non-glibc non-musl binaries that rely on LC_*.

I'm less knowledgeable about containers, but they appear to work.  It might
be due to copying variables from the host or having template defaults...

Anyway, my aim is more to tell packages that they are allowed to misbehave
when the settings are missing than to hunt misuse scenarios.  But, if such
a scenario is found, with the current Policy there is no recourse, while
if this rule is added it would be a bug.

> > * Legacy locales are no longer officially supported, and packages may
> >   drop support for them and/or exclude them from their testsuites.
> > * Packages may retain support for legacy locales, but related bug reports
> >   (unless security related) are considered to be of wishlist severity.
> 
> Is the C (aka POSIX) locale still a non-UTF-8 locale (if I remember
> correctly its character encoding is officially 7-bit ASCII), or has it
> been redefined to be UTF-8? Given the special status of the C locale in
> defaults and standards, it might be necessary to say that it's the only
> supported locale with a non-UTF-8 character encoding.

Hmm... if I recall correctly, old POSIX left the behaviour of characters
above 126 undefined, making C.UTF-8 _almost_ match the requirements (with
only exception being iswblank() IIRC), but current version specifies ASCII
(rather than C standard's "portable subset") with no additions to character
classes other than cntrl and punct allowed.

This is the locale all processes s

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Adam Borowski]

On Mon, Dec 19, 2022 at 10:44:12PM +0100, Bill Allombert wrote:
> Which raise the question: does the corresponding user group moved to UTF-8 ?
> Judging from ,
> neither Chinese nor Japanese users have overwhelmingly moved to UTF-8,
> so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP.

We actually do have data about locale usage in Debian.
I've copied .report files from bugs-mirror, and
grep -arm1 ^Locale: */*/*.report
shows that:
* most recent use of BIG5 is #925894 from March 2019
* there's no use of any GB locale (other than en_GB :p) past #609517 (2011)
* for EUC there's #1001207 (2021) #953616 #939588 #939494 #893625

Thus:
* Chinese encodings are totally dead for being used as a system locale
* Japanese are nearly so

That Wikipedia page presents stuff from 2008 as new developments, thus is
a wee bit outdated...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver!
⠈⠳⣄

Bug#1026278: fonts-cardo: replacement tokens block actual characters

[Adam Borowski]

Package: fonts-cardo
Version: 1.04-3
Severity: normal

A bunch of ranges that are only partially supported by Cardo have the rest
of the block filled with replacement tokens.  These tokens block a proper
glyphs being borrowed from another font.  As Cardo has a high priority
(for a good reason -- it's usually good), this effectively breaks the
affected blocks if Cardo is installed.

These blocks are:
* Runic (U+16A0..U+16F0)
* single glyph U+2112 (script capital L)
* circle arrows U+27F2, U+27F3, U+2938..U+293F
* Gothic U+10330..U+1034A
* math fraktur U+1D504..U+1D52D



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-rc8-00038-gd0ebd6ceed50 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#1021053: check-dfsg-status: doubled report

[Adam Borowski]

On Sat, Dec 17, 2022 at 03:35:58PM +, Holger Levsen wrote:
> On Sat, Oct 01, 2022 at 10:54:20AM +0200, Adam Borowski wrote:
> > When you renamed the package from vrms to check-dfsg-status, you forgot to
> > migrate the cron job.  As a result, its now sends it monthly reports twice.
> > 
> > /etc/cron.monthly/vrms
> > /etc/cron.monthly/check-dfsg-status
>  
> on don't see this here on a fresh install (of both packages from current sid),
> so am I correct to assume this happened on upgrade from non-transitional 
> package
> vrms?

Yeah.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Adam Borowski]

Package: debian-policy
Version: 4.6.1.1
Severity: wishlist

Hi!
As of Bookworm, legacy locales are no longer officially supported.  In order
to not break testsuites, they're mostly working if you install locales-all,
and you may manually request their generation by editing /etc/locale.gen --
but functionality is expected to bit rot and/or be removed in the future.

Thus, what about spelling this in the Policy?:

* Software may assume they always run in an UTF-8 locale, and emit or
  require UTF-8 input/output without checking.
* The execution environment (usually init system or a container) must
  default to UTF-8 encoding unless explicitly configured otherwise.
* Legacy locales are no longer officially supported, and packages may
  drop support for them and/or exclude them from their testsuites.
* Packages may retain support for legacy locales, but related bug reports
  (unless security related) are considered to be of wishlist severity.
* Filesystems may be configured to reject file names that are not valid
  printable UTF-8 encoded Unicode.
* So-called BOM (U+FEFF) must not be added to plain-text output, and if
  present, editors/viewers customarily used for editing code should not
  hide its presence.
* Human-readable files outside of packages' private data must be encoded
  in UTF-8.  This applies especially to files in /usr/share/doc and /etc
  but applies to eg. executable scripts in /bin or /sbin as well.

Rationale: it takes non-trivial amount of code to support diverse encodings;
Unicode is a strict superset of all legacy charsets thus there's no loss of
functionality by switching to it exclusively.  In todays Unicode world, text
files of other encodings present a barrier to being read by the user.

While data received from outside the network may legitimately use legacy
locales, requiring all of stdin/stdout/stderr and filesystem data to use
UTF-8 would simplify code.  It's not like we pay more than lip service to
other encodings anymore...

While diversity in software is welcome, diversity in standards is not:
UTF-8 will not damage your pinky finger nor require Alt-F2 kill -9 to
exit; will not make your computer fail to boot or require a trip to the
data center; nor infect your K desktop with gnomeitis.  [Of course, there's
no plausible reason to use Postfix, ever!].  In other words, having multiple
phone vendors is essential but having multiple charging connectors is bad.

As for BOM, it is explicitly discouraged by the Unicode Consortium, and can
cause security vulnerabilities where scripts that pass human review act
different than it appears.  #!/bin/perl gets executed by bash, and
this is just one of examples.

As for inits/containers declaring LC_CTYPE=C.UTF-8, systemd has been doing
this for a while, in sysvinit land we debated whether that's still needed
when glibc started to consider unset locale to mean C.UTF-8 rather than C
-- but then, some language compilers do not use glibc.  debootstrap doesn't
configure a default locale, while not all higher-level tools do so,
rendering a system installed in non-standard but reasonable way to lack
the setting, to the surprise of the admin.


Meow!

Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

[Adam Borowski]

On Thu, Dec 15, 2022 at 03:12:21PM +0100, Guillem Jover wrote:
> On Wed, 2022-12-14 at 15:27:18 +0100, Juri Grabowski wrote:
> > * Package name: distribution-gpg-keys
> >   Upstream Author : Miroslav Suchý 
> > * URL : https://github.com/xsuchy/distribution-gpg-keys/
> >   Description : GPG keys by various Linux distributions
> > 
> > used by various Linux distributions to sign packages.
> > 
> > needed by mock/3.5 and I need a sponsor for this package. See current 
> > packaging in
> > https://salsa.debian.org/pkg-rpm-team/distribution-gpg-keys
> > After I know ITP bug number I upload this source package to
> > https://mentors.debian.net/package/distribution-gpg-keys/

> (If this project is also intended to only cover RPM-based distributions,
> as Adam brought up, you might want to further ask them to make that clear
> from the project name, say rpm-distribution-openpgp-keys or similar.

When in that project's native environment, ie a RPM distribution, the name
_is_ adequate.  It's only in Debian (/Alpine/Arch/Gentoo/...) where the
name can be confusing.  But then, there's no requirement for the package
name to match upstream.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player

[Adam Borowski]

On Fri, Dec 09, 2022 at 02:10:32PM +0100, Helmar Gerloni wrote:
> Tuxguitar 1.5 is now built with Maven and comes with build scripts for Linux 
> on amd64 (x86_64), i386 (x86) and armv7hl. The differences between the build 
> scripts for amd64 and i386 are minor, and for many other architectures 
> supported by Debian there are no build scripts at all.

> So my idea was to use the upstream build scripts for amd64 for all 
> architectures and modify/patch them so that they hopefully work on all 
> architectures supported by Debian.

... wasn't the whole idea of Java to be arch independent?

> This is the reason why i removed all non-amd64 build scripts from the Debian 
> sources (among other things).
> But maybe this is not the right way, i don't know. Right now i only have 
> amd64 
> hardware available, so i can't build on other architectures (cross-compile 
> maybe, but that doesn't sound trivial).

While I do have a bunch of hardware to test, and qemu for the rest, I'm
afraid Maven issues are completely out of my expertise areas.  Thus, it
seems that someone else will need to help here.

> > Sounds like you missed a build dependency...
> I thought ${maven:CompileDepends} in debian/control handles this build 
> dependencies, but somehow it did not work.
> I added some more dependencies to the Build-Depends, so hopefully they are 
> complete now.

It builds on amd64 for me, yay!

The package is marked as UNRELEASED in the changelog, thus explicitly not
for upload.  I'll leave further review to someone with a clue about Java
and Maven...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1026037: RFS: gnuit/4.9.5-4 [ITA] [RC] -- GNU Interactive Tools, a file browser/viewer and process viewer/killer

[Adam Borowski]

On Tue, Dec 13, 2022 at 04:26:51PM +0100, Josef Schneider wrote:
>  gnuit (4.9.5-4) unstable; urgency=medium
>  .
>* New maintainer (Closes: #1014171).
>* debian/control:
>  + Update to debhelper-compat version 13 (Closes: #965566).
>  + Standards-Version 4.6.1.
>  + Add Rules-Requires-Root: no.
>  + Add Depends on sensible-utils.
>  + Remove Build-Depends on autotools-dev.
>  + Change http to https.
>* debian/compat: Deleted.
>* debian/copyright:
>  + Update to dep5 format.
>  + Update licensing.
>* debian/rules:
>  + Update for debhelper-compat version 13 (Closes: #998945).
>  + Add configure command to correctly pass --host flag (Closes: #869489).
>* debian/patches: Add fix-printf-string.patch to fix FTBFS.
>* debian/watch: Update to version 4.
>* debian/source:
>  + Add format file.
>  + Add lintian-overrides to remove false positive warning.

Hi!
There's a dropping in /usr/bin : ".gitaction".

Looks good otherwise.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1025871: RFS: d11amp/0.59-1 [ITP] -- Simple MP3 player (All green now)

[Adam Borowski]

On Sat, Dec 10, 2022 at 11:32:04PM +0100, Thomas Dettbarn wrote:
> The package is ready, and you can use it to have your
> very own retro MP3 player on your desktop. It has the
> big advantage that the license situation is 100% clear.

While, as Bastian mentioned, we have plenty of MP3 players in the archive
already, I don't believe that's a reason to block someone from working on
something they consider to be worth spending their time on -- as long as
there's no significant cost to the project.

A random package like this costs us ~1KB increase of Packages index
downloads, minor cycles during archive rebuilds, and basically that's it.

>  * Package name : d11amp
>Version  : 0.59-1
>Upstream contact : Thomas Dettbarn
>  * URL  :https://www.dettus.net/d11amp/
>  * License  : BSD-2-Clause
>  * Vcs  :https://github.com/dettus/d11amp/

> The source builds the following binary packages:
>   d11amp - Simple MP3 player

Alas, the package fails for me:
/bin/sh: 1: pkg-config: not found [eleventy times]
src/audiooutput/audiooutput_portaudio.c:28:10: fatal error: portaudio.h: No 
such file or directory
   28 | #include 
  |  ^
src/decoder/decoder.c:26:10: fatal error: gtk/gtk.h: No such file or directory
   26 | #include 
  |  ^~~
In file included from src/gui/theme_manager.c:33:
src/gui/theme_manager.h:30:10: fatal error: gdk-pixbuf/gdk-pixbuf.h: No such 
file or directory
   30 | #include 
  |  ^
... and so on.  Full log attached.


I see, your Build-Depends list binary libraries rather than headers:
Build-Depends: debhelper (>=11),
   debhelper-compat (= 13),
   libc6 (>= 2.34),
   libcairo2 (>= 1.2.4),
   libgdk-pixbuf-2.0-0 (>= 2.22.0),
   libglib2.0-0 (>= 2.31.8),
   libgtk-4-1 (>= 4.0.0),
   libmpg123-0 (>= 1.28.0),
   libportaudio2 (>= 19+svn20101113),
   libzip4 (>= 0.10)
What you need is to replace the runtimes with devel packages:
libgtk-4-dev
libzip-dev
and so on.

There's no need to list libc6/libc-dev (it's in build-essential), the
bdependency on debhelper is redundant (you already pull debhelper-compat),
and as shown by the "pkg-config: not found" you need pkgconf (which is
the new implementation of pkg-config that replaced it).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄
sbuild (Debian sbuild) 0.84.2 (08 December 2022) on valinor.angband.pl

+==+
| d11amp 0.59-1 (amd64)Sun, 11 Dec 2022 03:27:26 + |
+==+

Package: d11amp
Version: 0.59-1
Source Version: 0.59-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-be06e3f8-860f-46d9-bca5-2719e07ee12e'
 with '<>'
I: NOTICE: Log filtering will replace 'build/d11amp-0YbdFE/resolver-QbUZvN' 
with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

d11amp_0.59-1.dsc exists in .; copying to chroot
I: NOTICE: Log filtering will replace 'build/d11amp-0YbdFE/d11amp-0.59' with 
'<>'
I: NOTICE: Log filtering will replace 'build/d11amp-0YbdFE' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 11), debhelper-compat (= 13), libc6 (>= 
2.34), libcairo2 (>= 1.2.4), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglib2.0-0 (>= 
2.31.8), libgtk-4-1 (>= 4.0.0), libmpg123-0 (>= 1.28.0), libportaudio2 (>= 
19+svn20101113), libzip4 (>= 0.10), build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 11), debhelper-compat (= 13), libc6 (>= 
2.34), libcairo2 (>= 1.2.4), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglib2.0-0 (>= 
2.31.8), libgtk-4-1 (>= 4.0.0), libmpg123-0 (>= 1.28.0), libportaudio2 (>=

Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player

[Adam Borowski]

On Thu, Dec 01, 2022 at 09:35:15PM +0100, Helmar Gerloni wrote:
> The package builds and runs on amd64.  I was not able to build it on i386
> because of missing libswt-gtk-4-java.

That's not a problem, upstream of that package has dropped support for
32-bit and unless it somehow comes back, tuxguitar will stay
BD-Uninstallable on those architectures.

Because of the off chance the dependences _do_ come back, it's better
to leave them enabled instead of explicitly dropping in debian/control.

> I don't know if it builds on other architectures; probably not
> out-of-the-box.

The previous versions were ok, I tested arm64 and it fails the same way
amd64 does.  Which is:

[ERROR] Plugin org.apache.maven.plugins:maven-antrun-plugin:1.7 or one of
its dependencies could not be resolved: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the artifact
org.apache.maven.plugins:maven-antrun-plugin:jar:1.7 has not been downloaded
from it before.

Sounds like you missed a build dependency...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1025372: RFS: nss-tls/1.1-1.1 [NMU] -- utility like nslookup(1), but uses libnss_tls.so instead of DNS

[Adam Borowski]

On Sat, Dec 03, 2022 at 11:53:23AM +0100, Gioele Barabucci wrote:
> I am looking for a sponsor for a NMU of the package "nss-tls":

>  nss-tls (1.1-1.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* d/libnss-tls.nss: Install NSS service `tls` via dh_installnss
>  (Closes: #1024688)

Hi!
Could you please follow the NMU procedure?  This is not a high-severity or
urgent bug, thus I see no reason to skip the rules.

The Policy has details, but in short: please post to a bug (in this case
#1024688) that you intend to do a NMU, adding a debdiff of the proposed
changes (in this case, the Salsa merge request should be enough).

Only then the clock starts ticking, which is 10 days for regular NMUs.
Of course, if you believe the maintainer won't react, uploading to
DELAYED/10 (which in this case is done by a sponsor) will fulfill this
requirement while not requiring you to remember to do an action in the
future.  But in either case, the intent-to-NMU mail is still required.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1025427: pipewire: frequent crashes on x11 bell

[Adam Borowski]

Package: pipewire
Version: 0.3.61-1
Severity: normal

Hi!
On a machine with no physical PC honker, I have the x11 bell enabled.
And that causes random but frequent crashes in pipewire:


Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:40
40  ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or 
directory.
[Current thread is 1 (Thread 0x7f1426c0 (LWP 522))]
(gdb) bt full
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:40
No locals.
#1  0x7f143037bb55 in loader_callback (item=0x7f142e70, 
userdata=)
at libltdl/lt_dlloader.c:56
vtable = 
name = 
__PRETTY_FUNCTION__ = "loader_callback"
#2  0x7f143037efb0 in lt__slist_find (slist=0x7f142e70, 
find=find@entry=0x7f143037bb40 , 
matchdata=matchdata@entry=0x7f13d1421330)
at libltdl/slist.c:126
result = 0x0
__PRETTY_FUNCTION__ = "lt__slist_find"
#3  0x7f143037bcaa in lt_dlloader_find (
name=name@entry=0x7f13d1421330 )
at libltdl/lt_dlloader.c:214
No locals.
#4  0x7f143037bcd6 in lt_dlloader_remove (
name=0x7f13d1421330 )
at libltdl/lt_dlloader.c:156
vtable = 
id_string = "lt_dlloader_remove"
iface = 
handle = 
in_use = 
in_use_by_resident = 
#5  0x7f143037d558 in lt_dlexit () at libltdl/ltdl.c:340
next = 0x7f142dd0
vtable = 
level = 
loader = 0x7f142e70
handle = 
errors = 0
#6  0x7f14303de115 in driver_destroy (c=c@entry=0x7f142b70) at 
./src/dso.c:298
p = 0x7f142d20
ret = 0
__PRETTY_FUNCTION__ = "driver_destroy"
#7  0x7f14303d5988 in ca_context_destroy (c=0x7f142b70) at 
./src/common.c:186
ret = 0
__PRETTY_FUNCTION__ = "ca_context_destroy"
#8  0x7f14308687fe in play_sample (impl=)
at ../src/modules/module-x11-bell.c:135
sample = 0x7f14308691eb "bell-window-system"
ca = 0x7f142b70
res = 
sample = 
ca = 
res = 
__func__ = "play_sample"
exit = 
exit_destroy = 
#9  do_play_sample (loop=, async=, seq=, data=, size=, user_data=) at 
../src/modules/module-x11-bell.c:142
No locals.
#10 0x7f1431d7298a in flush_items (impl=0x561fd8337a68) at 
../spa/plugins/support/loop.c:181
item = 0x561fd8337b58
block = false
index = 0
res = 
__func__ = "flush_items"
#11 0x7f1431d727f9 in source_event_func (source=0x561fd833fb90) at 
../spa/plugins/support/loop.c:592
s = 0x561fd833fb90
count = 1
res = 
__func__ = "source_event_func"
#12 0x7f1431d74e8e in loop_iterate (object=0x561fd8337a68, timeout=-1) at 
../spa/plugins/support/loop.c:431
s = 
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = 
{94694771227408, -2109903483977498334, 4294967295, 94694771226728, 
140725934194656, 139724672987136, -5715082852569611998, -5715122637836680926}, 
__mask_was_saved = 0}}, __pad = {0x7f142fffeef0, 0x0, 0x0, 0x0}}
__cancel_routine = 0x7f1431d72320 
__cancel_arg = 
__not_first_call = 
impl = 0x561fd8337a68
ep = {{events = 1, data = 0x561fd833fb90}, {events = 0, data = 0x0} 
}
e = 
i = 0
nfds = 1
cdata = {ep = 0x7f142fffec80, ep_count = 1}
__func__ = "loop_iterate"
#13 0x7f143206e4fa in ?? () from 
/usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0
No symbol table info available.
#14 0x7f1431e76fd4 in start_thread (arg=) at 
./nptl/pthread_create.c:442
ret = 
pd = 
out = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139724681377472, 
5658682304508821794, -128, 0, 140725934194656, 139724672987136, 
-5715082852466851550, -5715122499345481438}, mask_was_saved = 0}}, priv = {pad 
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
#15 0x7f1431ef766c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (666, 'testing'), (500, 'testing-debug'), (500, 'unstable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages pipewire depends on:
ii  adduser  3.129
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.61-1
ii  pipewire-bin 0.3.61-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1024887: Subject: RFS: wxmaxima/22.11.0-1 -- GUI for the computer algebra system Maxima

[Adam Borowski]

On Sun, Nov 27, 2022 at 02:55:34PM +0100, Gunter Königsmann wrote:
>  * Package name : wxmaxima
>Version  : 22.11.0-1

>  wxmaxima (22.11.0-1) unstable; urgency=medium
>  .
>* New upstream version
>* Disallowed to build with the old wxWidgets 3.0
> Seems like the last of these two changes is especially important as
> debian actively wants to get actively rid of the old 3.0 version of
> wxWidgets.

Hi!
It looks like you have a bunch of droppings of a failed merge left in
debian/


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1024991: RFS: jamulus/3.9.1+dfsg-1 [QA] -- real-time collaborative music session client and server

[Adam Borowski]

On Mon, Nov 28, 2022 at 08:52:48PM +0800, Bo YU wrote:
>  * Package name : jamulus
>Version  : 3.9.1+dfsg-1
>Upstream contact : https://sourceforge.net/p/llcon/discussion/
>  * URL  : https://jamulus.io/
>  * License  : GPL-2.0+ and MIT-STK, CC0, GPL-2.0+, BSD3-OPUS, 
> famfamfam-flag-icons
>  * Vcs  : 
> https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/jamulus.git;a=shortlog;h=refs/heads/master
>Section  : sound

>  jamulus (3.9.1+dfsg-1) unstable; urgency=medium
>  .
>* QA upload.
>* Set Debian QA as maintainer. See #1023670.
>* New upstream version 3.9.1.
>* Update d/copyright:
>  - adjust Files-Excluded due to repack.
>  - update file-pattern due to upstream change.
>* Add support for riscv64. (Closes: #1024984)
>* Rebase all patches.
>* Adjust d/source/lintian-overrides
>* Update execute_after_dh_auto_install

Hi!

.--[ debian/source/lintian-overrides ]
# old repo
jamulus source: orphaned-package-not-maintained-in-debian-infrastructure
`

This is not a false positive -- an orphaned package's packaging repo is
supposed to be moved to some place that's writeable by people other than
the previous maintainer.

Of course, there's no need to fix everything, especially not in a QA upload
where the only expectation is for the new version to be better than the old
one -- but hiding issues is no good.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1025141: powermgmt-base: Doesn't correctly detect we are on AC power

[Adam Borowski]

On Wed, Nov 30, 2022 at 08:52:41AM +0100, Santiago García Mantiñán wrote:
> I'm running Debian stable on a HP ProDesk 600 G6 Small Form Factor PC
> (Family: 103C_53307F HP ProDesk)
> 
> It is a desktop machine which ovbiously runs on AC all the time, however
> on_ac_power returns 1 which is stopping things like unattended upgrades from 
> being run.
> 
> On /sys/class/power_supply/ there is only:
> lrwxrwxrwx 1 root root 0 Nov 29 14:53 ucsi-source-psy-USBC000:001 -> 
> ../../devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:001
> and there... /sys/class/power_supply/ucsi-source-psy-USBC000\:001/type
> says USB.

The SoC might be shared with laptops/etc and thus expose devices that are
present but not fully functional.

> I have opened the machine and the power supply seems to use only a couple of 
> 12V
> 4 pin connectors like the one introduced with the P4, but that's it, no sign 
> of USB.

The hardware block known as "power supply" it just one of possible sources
for the machine.  For example, Pine64 boards can be powered by:
 * "ac" (dumb USB micro-B)
 * battery
 * USB type A OTG (a _host_ not gadget interface)
 * (sort of) UART (insufficient power for stable operation)
and only the first two even have sensors that inform the kernel.

> My guess is that the USB thing there is one USB-c connector on the front of
> the machine, in fact it says on usb_type [C] PD PD_PPS which I guess means
> that the connector is compatible with power delivery.

It's possible that your machine can indeed be powered via USB C, new laptops
usually can.  Which leads to fun like laptop that wants to be charged by a
phone -- and indeed negotiating it that way.

> For what I see, acpi doesn't have info on power suppy, no sign of it
> executing acpi -V and /proc/acpi only has wakeup inside.  And there is no
> pmu or apm info either.

ACPI doesn't (usually?) know about USB devices; PMU and APM are stuff from
the distant past.

> I don't know what other info to add here, but please don't hesitate to ask
> whatever you need.

Could you perhaps provide:
cd /sys/class/power_supply && grep . */* 2>/dev/null|grep -v /uevent:


Thanks for your report -- with all those new USB-C power delivery schemes
actually being used by machines in the wild, it's time to recognize them,
instead of relying on the old assumption that "USB power supply" means
incoming power.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#972315: sysvinit still misses B-D: libcrypt-dev

[Adam Borowski]

On Tue, Nov 22, 2022 at 11:20:07AM +0100, Helmut Grohne wrote:
> On Tue, Nov 22, 2022 at 11:01:31AM +0100, Adam Borowski wrote:
> > sysvinit (3.05-7) unstable; urgency=medium
> >   * Drop libcrypt-dev from B-Depends, we don't ship sulogin since Stretch
> > which was what we needed the library for.

> Yes, I got a build failure when I tried making libcrypt-dev
> non-build-essential (which is the goal here).

> A relatively simple method to simulate its absence is:
> | sbuild -d unstable --starting-build-commands="rm /usr/include/crypt.h" 
> sysvinit

> | sulogin.c:42:10: fatal error: crypt.h: No such file or directory
> |42 | #include /* added to make this compile on Fedora 28 */
> |   |  ^

> So not being shipped does not seem to imply not being built. Can you
> figure out how to make it not build sulogin? That would be a better
> solution than adding back the dependency indeed.

As this is a change in upstream code, I've submitted a PR there:
https://github.com/slicer69/sysvinit/pull/15

Do you intend to drop the build-essentiality of libcrypt-dev shortly?  If
not, I'd just let the PR go through the normal flow towards next upstream
release then the package.

An expedited upload is of course an option, but I suspect you're not in
a hurry.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#972315: sysvinit still misses B-D: libcrypt-dev

[Adam Borowski]

On Mon, Nov 21, 2022 at 07:28:54PM +0100, Helmut Grohne wrote:
> reopen -1
> thanks
> 
> sysvinit lost its libcrypt-dev dependency. Please add it back.

sysvinit (3.05-7) unstable; urgency=medium
  * Drop libcrypt-dev from B-Depends, we don't ship sulogin since Stretch
which was what we needed the library for.

The sulogin executable is no longer needed (it's built by util-linux
nowadays), and its source inside src:sysvinit is dormant.  I've just
re-checked: the package builds and cross-builds successfully.

Is there a reason for this B-Dependency that I missed?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1024256: birdtray: Process birdtray dumped core on halt or logout

[Adam Borowski]

On Wed, Nov 16, 2022 at 02:22:42PM +0100, luca.pedrielli wrote:
> Package: birdtray
> Version: 1.9.0+ds-2+b1

> Every logout birdtray core dump.
> With a builded 1.10 version seems better.

Not for me, but your mention of a "1.10 version" sounds interesting.
Apparently there's such a version in upstream git, but not yet tagged.

I think, let's wait a bit to see whether the version is not yet
finalized or it's a case of a missing tag.

And, to reduce required effort from my side, I'm assuming the crash that
happens for you but not me is fixed in 1.10, thus sparing me efforts to
reproduce it :)

On the other hand, the unread mails count is broken since the last
Thunderbird update, and that's the main point of birdtray for me.  Thus
I'm looking forward to the release, but as new commits continue to come,
I'm hurrying slowly.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#398710: bell-style audible makes baby Pollito cry

[Adam Borowski]

Hi!
Big fat +1 to defaulting bell-style to either "none" or "visible".

As just discussed on #pipewire, emulating the bell on machines w/o a
hardware pc speaker is off by default because "most people want to
rip out the beeper".  And that's specifically because of bash & co
beeping whenever you press backspace or tab.

The bell is supposed to alert the user that something is wrong (or that
a long-running task on a remote server is done...), not to make a
racket during normal use.

Thus: for the love of father Dagon and mother Hydra, could you please
silence the bell by default?

/usr/share/readline/inputrc
# do not bell on tab-completion
# set bell-style none
# set bell-style visible
⬑ one of these 


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1023575: neo-cli: charset=runic includes pseudo-runes

[Adam Borowski]

Package: neo-cli
Version: 0.6.1-1
Severity: normal

Hi!
If you run neo with --charset=runic, besides of actual runes (ie, letters
that have been used in various historical periods), the program also uses
a bunch of symbols that had no real-life use (U+16F1..U+16F8):
 * Tolkien:
   * U+16F1 included in The Hobbit when Tolkien found no way to spell his
 name within Anglo-Saxon runes
   * U+16F2 and U+16F3 from a personal letter
 * Franks Casket:
   * U+16F4..U+16F8 (these at least come from 8th century) are weird
 variant letters not attested anywhere else, for reasons not
 known despite generations of research but conjectured to be unique
 numerologic rune magic.

But you probably care less about actual historical reasons.  A practical
one is that the rest of runes come from Unicode 3.0 (1999) while the
U+16F1..U+16F8 symbols were added only in Unicode 7.0 (2014) and thus
are missing from most fonts we ship.  This results in ugly replacement
symbols marring the display.

Also: eg. cyrillic uses actual letters only, not a medieval scribe's
doodles like "multiocular o" that was drawn in a single copy of a book
from 1429 -- yet got encoded in Unicode anyway.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-rc3-00018-g38bb0e6b7ef0 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages neo-cli depends on:
ii  libc6 2.36-4
ii  libgcc-s1 12.2.0-9
ii  libncursesw6  6.3+20220423-2
ii  libstdc++612.2.0-9
ii  libtinfo6 6.3+20220423-2

neo-cli recommends no packages.

neo-cli suggests no packages.

-- no debconf information

Bug#1023528: mipsel: crash: VEX: Unsupported baseline Found: Loongson-baseline

[Adam Borowski]

Package: valgrind
Version: 1:3.19.0-1
Severity: normal

Hi!
On any modern mips machine (ie, loongson -- at least as our infra is
concerned; CIP United is rumoured to disagree), valgrind crashes with:

.
VEX: Unsupported baseline
 Found: Loongson-baseline
Cannot continue. Good-bye

vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==1833049==at 0x5804FB44: ??? (in 
/usr/libexec/valgrind/memcheck-mips32-linux)
==1833049==by 0x5804FA2C: ??? (in 
/usr/libexec/valgrind/memcheck-mips32-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 1833049)
==1833049==at 0x401B920: __start (in /lib/mipsel-linux-gnu/ld.so.1)
==1833049==by 0x7EB7B088: ???
client stack range: [0x7EB78000 0x7EB7BFFF] client SP: 0x7EB7B090
valgrind stack range: [0x42878000 0x42977FFF] top usage: 5512 of 1048576


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
`

Bug#1023527: mips64el: false positive 100% calls of memcheck; rseq in all tools

[Adam Borowski]

Package: valgrind
Version: 1:3.19.0-1
Severity: normal

Hi!
Valgrind reports a false positive during glibc initialization on mips64el:

Conditional jump or move depends on uninitialised value(s)
   at 0x400746C: cached_fpabi_reject_phdr_p (dl-machine-reject-phdr.h:57)
   by 0x400746C: elf_machine_reject_phdr_p (dl-machine-reject-phdr.h:217)
   by 0x40079E0: open_verify.constprop.0 (dl-load.c:1793)
   by 0x400ABA8: _dl_map_object (dl-load.c:2211)
   by 0x401DA2C: map_doit (rtld.c:647)
   by 0x401B3C8: _dl_catch_exception (dl-error-skeleton.c:208)
   by 0x401B478: _dl_catch_error (dl-error-skeleton.c:227)
   by 0x401D96C: do_preload (rtld.c:822)
   by 0x401F058: handle_preload_list (rtld.c:898)
   by 0x4021BC4: dl_main (rtld.c:1859)
   by 0x401CD98: _dl_sysdep_start (dl-sysdep.c:140)
   by 0x401E3D0: _dl_start_final (rtld.c:497)
   by 0x401E684: _dl_start (rtld.c:586)

This makes all packages that run valgrind during their testsuite fail if
they consider this error to be fatal.

Also, all tools report the following warning:

WARNING: unhandled mips64-linux syscall: 5327
You may be able to write your own handler.
Read the file README_MISSING_SYSCALL_OR_IOCTL.
Nevertheless we consider this a bug.  Please report
it at http://valgrind.org/support/bug_reports.html.

The syscall in question is rseq, added in 2018.  For a package to fail
it'd need to do so on unexpected stderr -- but that's the default for
some test engines.

Bug#1023526: s390x: false positive in drd: memcpy > _IO_new_file_xsputn

[Adam Borowski]

Package: valgrind
Version: 1:3.19.0-1
Severity: normal
Tags: patch

Hi!
As detected by valgrind-if-available testsuite (on zelenka, as buildds
for this arch are slooow), drd reports the following false positive:

.
drd, a thread error detector
Copyright (C) 2006-2020, and GNU GPL'd, by Bart Van Assche.
Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
Command: /tmp/___

Thread 3:
Conflicting store by thread 3 at 0x052581c0 size 2
   at 0x486A32A: memcpy (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x490EBBD: _IO_new_file_xsputn (fileops.c:1235)
   by 0x490EBBD: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EA709: outstring_func (vfprintf-internal.c:239)
   by 0x48EA709: __vfprintf_internal (vfprintf-internal.c:767)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???
Address 0x52581c0 is at offset 0 from 0x52581c0. Allocation context:
   at 0x48456DE: malloc (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x4901215: _IO_file_doallocate (filedoalloc.c:101)
   by 0x4910A83: _IO_doallocbuf (genops.c:347)
   by 0x4910A83: _IO_doallocbuf (genops.c:342)
   by 0x490FCC3: _IO_file_overflow@@GLIBC_2.2 (fileops.c:744)
   by 0x490EC61: _IO_new_file_xsputn (fileops.c:1243)
   by 0x490EC61: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EA709: outstring_func (vfprintf-internal.c:239)
   by 0x48EA709: __vfprintf_internal (vfprintf-internal.c:767)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???
Other segment start (thread 2)
   at 0x49942A8: clone (clone.S:48)
   by 0x49954C3: __clone_internal (clone-internal.c:83)
   by 0x: ???
Other segment end (thread 2)
   at 0x48639F2: pthread_rwlock_wrlock@* (in 
/usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x108BE7: worker (threaded.c:23)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???

Conflicting store by thread 3 at 0x052581c6 size 1
   at 0x486A35E: memcpy (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x490EBBD: _IO_new_file_xsputn (fileops.c:1235)
   by 0x490EBBD: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EA709: outstring_func (vfprintf-internal.c:239)
   by 0x48EA709: __vfprintf_internal (vfprintf-internal.c:767)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???
Address 0x52581c6 is at offset 6 from 0x52581c0. Allocation context:
   at 0x48456DE: malloc (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x4901215: _IO_file_doallocate (filedoalloc.c:101)
   by 0x4910A83: _IO_doallocbuf (genops.c:347)
   by 0x4910A83: _IO_doallocbuf (genops.c:342)
   by 0x490FCC3: _IO_file_overflow@@GLIBC_2.2 (fileops.c:744)
   by 0x490EC61: _IO_new_file_xsputn (fileops.c:1243)
   by 0x490EC61: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EA709: outstring_func (vfprintf-internal.c:239)
   by 0x48EA709: __vfprintf_internal (vfprintf-internal.c:767)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???
Other segment start (thread 2)
   at 0x49942A8: clone (clone.S:48)
   by 0x49954C3: __clone_internal (clone-internal.c:83)
   by 0x: ???
Other segment end (thread 2)
   at 0x48639F2: pthread_rwlock_wrlock@* (in 
/usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x108BE7: worker (threaded.c:23)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???

Conflicting store by thread 3 at 0x052581c7 size 1
   at 0x486A090: memcpy (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x490EBBD: _IO_new_file_xsputn (fileops.c:1235)
   by 0x490EBBD: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EBB71: outstring_func (vfprintf-internal.c:239)
   by 0x48EBB71: __vfprintf_internal (vfprintf-process-arg.c:213)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpr

Bug#1023305: ITP: zst -- CLI tool for zstd (and other) compression

[Adam Borowski]

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

* Package name: zst
  Version : not released yet
  Upstream Author : yours truly
* URL : https://github.com/kilobyte/zst
  Programming Lang: C
  Description : CLI tool for zstd (and other) compression

 This is an alternate tool for zstd compression, one that takes a lot
 less space than the official one.  It also behaves in a way consistent
 with other Unix compressors: the level goes only up to 9, the original
 copy of the file is not kept, etc.
 .
 The executable can also replace gzip xz bzip2.


A bunch of features are not yet ready, but I'm filing this ITP now that
the core functionality is already working but there's still time for
design changes.  Stuff that's aimed for important/Essential needs to
be discussed well...

Existing compressors:
  | tool | lib
--+--+-
gzip  | Ess  | Ess
bzip2 | std  | Ess (but it'd be nice to remove it)
xz| std  | Ess
zstd  | opt  | Ess
lz4   | opt  | libsystemd0 but not libelogind0

Bug#1023161: RFS: libghc-filesystem/1.15.12-1 [ITP] -- Implementation of C++17 std::filesystem for C++11-20

[Adam Borowski]

On Sun, Oct 30, 2022 at 09:35:57PM +, Ben Westover wrote:
>  * Package name : libghc-filesystem
>Version  : 1.15.12-1
>Upstream contact : Steffen Schümann 
>  * URL  : https://github.com/gulrak/filesystem

>  libghc-filesystem (1.15.12-1) unstable; urgency=medium
>  .
>* Initial Package (Closes: #1023160)

.--[ debian/lintian-overrides ]
# While ghc usually refers to Haskell packages, this package using the
# namespace ghc isn't related to Haskell; according to the upstream, it
# stands for "gulrak's helper classes".
wrong-section-according-to-package-name
`

Is there a reason you picked that specific name?  Unlike some other
languages, there's no convention to name C++ packages after their
internal namespace, and this particular one clashes with Haskell,
confusing both machines and humans.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1021998: CXL -- Salsa MR added

[Adam Borowski]

https://salsa.debian.org/kernel-team/linux/-/merge_requests/563

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄