date:20230215

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkysdk-system":

 * Package name : libkysdk-system
   Version  : 2.0.0-1
   Upstream contact : Zhikai Chen 
 * URL  : https://gitee.com/openkylin/libkysdk-system
 * License  : BSL-1.0, Apache-2.0, GPL-2+, BSD-3-clause, LGPL-3+,
BSD-2-clause, Expat
 * Vcs  : https://gitee.com/openkylin/libkysdk-system
   Section  : utils

The source builds the following binary packages:

  libkysdk-system - Kylin System Layer Developer Kit
  libkysdk-system-dev - Kylin System Layer Developer Kit - Development Library
  libkysdk-disk - System Disk Information Acquisition Library
  libkysdk-disk-dev - System Disk Information Acquisition Library - Development
Library
  libkysdk-systime - Library of system time-related operations
  libkysdk-sysinfo - system information acquisition library
  libkysdk-sysinfo-dev - System information acquisition library - Development
Library
  libkysdk-filesystem - File system library
  libkysdk-filesystem-dev - File system library - Development Library
  libkysdk-hardware - Hardware information acquisition library
  libkysdk-hardware-dev - Hardware information acquisition library -
Development Library
  libkysdk-package - Package management library
  libkysdk-package-dev - Package management library - Development Library
  libkysdk-proc - Runtime information acquisition library
  libkysdk-proc-dev - Runtime information acquisition library - Development
Library
  libkysdk-powermanagement - Power management library
  libkysdk-powermanagement-dev - Power managementlibrary - Development Library
  libkysdk-ocr - AI text recognition function
  libkysdk-ocr-dev - AI text recognition function - Development Library
  libkysdk-location - Geographic location library
  libkysdk-location-dev - Geographic location library - Development Library
  libkysdk-net - Network information library
  libkysdk-net-dev - Network information library - Development Library
  libkysdk-realtime - Instantaneous information library
  libkysdk-realtime-dev - Instantaneous information library - Development
Library

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

  https://mentors.debian.net/package/libkysdk-system/

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

  dget -x https://mentors.debian.net/debian/pool/main/libk/libkysdk-
system/libkysdk-system_2.0.0-1.dsc

Changes for the initial release:

 libkysdk-system (2.0.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1031340)

Regards,
--

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

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkysdk-base":

 * Package name : libkysdk-base
   Version  : 1.0.1-1
   Upstream contact : Zhikai Chen 
 * URL  : https://gitee.com/openkylin/libkysdk-base
 * License  : LGPL-3
 * Vcs  : https://gitee.com/openkylin/libkysdk-base
   Section  : libs

The source builds the following binary packages:

  libkysdk-base - Kylin SDK basic library
  libkysdk-base-dev - development files for libkysdk-base
  libkysdk-timer - C style timer module
  libkysdk-timer-dev - development files for libkysdk-timer
  libkysdk-config - configuration file module
  libkysdk-config-dev - development files for libkysdk-config
  libkysdk-log - C style log module
  libkysdk-log-dev - development files for libkysdk-log
  libkysdk-utils - Basic tool function module
  libkysdk-utils-dev - development files for libkysdk-utils

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

  https://mentors.debian.net/package/libkysdk-base/

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

  dget -x https://mentors.debian.net/debian/pool/main/libk/libkysdk-
base/libkysdk-base_1.0.1-1.dsc

Changes for the initial release:

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

Regards,
--

Bug#960231: kubernetes: provision of 'kubeadm' command-line utility

Source: kubernetes
Followup-For: Bug #960231
Control: submitter -1 ja...@reciperadar.com

Bug#1002501: release-notes: Quotes (" and ') in commands in PDF release notes are "smart" (”*” / ’hold$’) so don't copy/paste

Package: release-notes
Followup-For: Bug #1002501
X-Debbugs-Cc: 1002501-submit...@bugs.debian.org

On Thu, 15 Dec 2022 14:01:49 +0100, Paul Gevers wrote:
> The release notes are generated with docbook. I spend about an hour to 
> find out how to prevent conversion of straight quotes to curly quotes

Funny how it's sometimes the seemingly-simple fixes that prove the most
infuriating to fix, isn't it? :)

I spent a significantly longer amount of time on this one; I learned fairly
early on that the 'upquote' LaTeX package was a potential fix (thanks to
aerostitch[1] and postgis[2]), but in practice getting that to work with
the PDF documentation generation involved various failed attempts.

However..

In addition to including the 'upquote' package, it seems that a combination of
two additional changes[3] produces the desired result:

  * Using single straight quotes instead of double quotes

  * Placing the relevant text within a 'screen' docbook element

Fortunately single-quotes is probably a safer and better recommendation anyway
since it's generally less prone to globbing, at least in bash.

(note: I also had to temporarily rename some font filenames[4] locally in order
for the build to succeed when using 'make pdf LINGUA=en architecture=arm64')

[1] - https://aerostitch.github.io/misc/asciidoc/asciidoc-pdf_keep_quotes.html

[2] - https://github.com/postgis/postgis/pull/128

[3] - 
https://salsa.debian.org/jayaddison/release-notes/-/commit/4922a80e12db746de8bf8cad45d4fe63d43d9f90

[4] - 
https://salsa.debian.org/jayaddison/release-notes/-/blob/4922a80e12db746de8bf8cad45d4fe63d43d9f90/Makefile#L82-85

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

2023-02-15 Thread Lisandro Damian Nicanor Perez Meyer

On martes, 14 de febrero de 2023 19:28:53 -03 Soren Stoutner wrote:
> Which part do you not understand about not being needed on both Qt 5 and Qt
> 6? The part about building the .bdic files or the part about Qt WebEngine
> using the .bdic files at runtime?

Sorry, wrong question on my side.

I just went trough the whole thread. I understand that these bdic files are 
needed for packages that use Qt[5 6]webengine. But I do not like the idea of 
**other** packages making use of them.

Let me explain you why:

- webengine is the most complicated package we handle, it is the very example 
of a PITA. It embeds the world, it takes ages to compile, it has weird 
errors...

- Hunspell dictionaries should be handled by... hunspell. Yes, I know this was 
considered and it's still not possible. But the fact that webengine ships them 
is not enough a reason to expose them to the world instead of doing the right 
thing: handling them there.

- They are not built by default by Qt itself. This is weird... or they do not 
want to handle possible build errors. Should we Qt maintainers? No.

- If the patches are taken and at some point webengine upstreams decide to 
switch to something else then we the Qt maintainers get the broken pieces. 
Insta RC bugs, we get this package stopped from migrating to testing until 
solving the issue... a pain.

So no, I'm totally against these change. Dmitry, Patrick: my suggestion is to 
reverse the patches.

Bug#1031381: UDD/dmd: Incorrectly considers patches needing work

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi!

As mentioned in #1028503, the DMD shows a nice panel with patch
status, and which ones need work, but that seems to be failing to take
into account several of the other fields that signify that the patch
has been applied or taken from upstream.

Specifically at least:

I think the Origin field needs to be taken into account too, in
particular when it has an "upstream" or a "backport" value. As well as
the Applied-Upstream field.

Thanks,
Guillem

Bug#1028503: UDD: Unknown "yes" value for Forwarded field in patch metadata

Hi!

On Sun, 2023-01-15 at 21:12:53 +0100, Lucas Nussbaum wrote:
> > I'm wondering why diverge from the patch metadata guidelines? If there's
> > a desire to change the field semantics, perhaps it would be better to
> > change the guidelines instead? :)
> >·
> > But given this interchange, perhaps we should try to make it more
> > clear or explicit about some of these aspects there!
>·
> Originally I admit that I misread the DEP3 rules.
> Now the implementation is much closer to DEP3. Unfortunately, DEP3 was
> probably not written with automatic processing in mind.

> The current status of the data is the following[1]:

Thanks for collecting and analyzing these!

> With some comments:
>  no  | No Forwarded, No Bug field 
>   | 100145 |   68.12
> => that sticks to the DEP3 specification. (no forwarded: + no bugs: => 
> implicit no)
>·
>  not-needed  |
>   |  19329 |   13.15
> => that's an explicit "Forwarded: not-needed"
>·
>  yes |
>   |  12217 |8.31
> => Those are the cases where it's clear that the bug has been forwarded
>·
>  no  | Explicit Forwarded=no  
>   |  11448 |7.79
> => that's an explicit "Forwarded: no"

All ack.

> The remaining lines are the ones that could require discussion.
> First, it's worth noting that they only account for 2.63% of the
> patches.
>·
>  invalid | Invalid value for Forwarded field  
>   |   2270 |1.54
> => I looked at the values considered invalid[2], and could not really convince
> myself that they should automatically fit in one of the above
> categories.

I see what you mean. Although from skimming over these values, the two
things that become clear are things that I've already wondered about,
forwarding to email addresses (there are "many" instances of those
there), and how to represent "no" due to no-upstream (which TBH it
seems we are lacking a more general way to mark packages as such,
because there is also the debian/watch and several lintian tags that
trigger but should probably not be considered issues when there is no
upstream).

I guess several of these bogus ones could perhaps be fixed up by the
janitor.

>  invalid | Forwarded=yes, but no Bug field
>   |   1119 |0.76
> => I think that we should strongly encourage leaving a public trace when
> forwarding bugs

While I agree that would be ideal, that has the problem I mentioned
when upstream does not have any such public avenue. Since then I
adopted the suggestion by Paul Wise to use a mail address, but from
the previous entry, I think that makes parsing probably tricky. :/

The other reason I've set Forwarded=yes in the past is when I've
submitted the patches and they have been merged very quickly, and
having to go look for the web archive URL references or similar seems
more work than it's worth, when just adding the commit id in the Origin
field is quicker (but see below.)

>  invalid | No forwarded, Debian bug in Bug: field. Bug-Debian: should 
> be used instead.  |283 |0.19
> => quite obviously invalid

Ack.

>  no  | No Forwarded, Upstream bug, but not a URL  
>   |190 |0.13
> => those are mostly patches misusing the Bug: field for the Debian
> bug.[3]. Since the specification requires a URL here, it could be
> considered invalid as well.

Is this perhaps being too strict? Some of the URLs seem to be valid,
just prefixed with whitespace? The rest seem indeed invalid.

>  invalid | Forwarded=yes, Debian bug in Bug: field. Bug-Debian: 
> should be used instead. |  8 |0.01
> => quite obviously invalid

Ack.

> So, all in all, my implementation[4] sounds sane.

I think the guidelines might need some work to add clearly missing
states or declarative information; and then having this kind of
more strict validator (or ideally automatic fixer) will eventually
make the data more correct. Lintian seems rather lenient in its
parsing, but following the guidelines more closely perhaps.

> > I otherwise do not know how we can mark patches as forwarded when
> > for example you send them directly to upstream via email or to a mailing
> > list that has no public archive or similar.
>·
> That's true. Other than blinding accepting "Forwarded: yes", I don't
> know how this could be addressed.

I still see value in a "faith" based "yes", but I can see how this
can be seen as rather unsatisfactory from a global point of view. But
perhaps this is tied with the following point, and "yes" should only
be accepted when there's "proof" from other fields that it got
forwarded (say because it's merged already).

> > I think the Origin field needs

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

2023-02-15 Thread Wookey

Just noticed this bug.

The discussion in this bug makes me worry that people do not fully
understand the implications of enabling 64-bit time and large file
system support respectively.

It's great to see people starting to care about this issue and fix
things (it's overdue), but I'm just chiming in to point out that some
care is needed before turning these options on. Debian is in the
process of developing a plan for this transition, but has not got very far yet.

I have just started a wiki page to cover the issues (and tagged this
bug): https://wiki.debian.org/ReleaseGoals/64bit-time
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-de...@lists.debian.org;tag=time64

If tar is currently building without LFS enabled, I'd suggest maybe
turning that on, checking things, and uploading before also turning on
64bit time_t. They can be done separately (in that order only). Both
have the potential to change file formats and ABIs (although tar is a
program not a library so no ABI is exposed). Hopefully upstream has
looked at all this carefully and is reasonably sure nothing important
will break?

For LFS enablement you should be aware that LARGEFILE_SOURCE and
FILE_OFFSET_BITS=64 do different things. The former enables both 32
and 64-bit interfaces, the latter chooses the 64-bit interface
only. You probably only want the latter. (depending how these are used
in the codebase, it may not make any practical difference)

For 64-bit time_t enablement you might want to wait for the dpkg
standard debian mechanism to appear and use that:
https://bugs.debian.org/1030159

You certainly want to be sure that things tar depends on (and expose
ABIs or file formats that change) have switched first. Now tar is
close to the bottom of the stack so this may well be fine, but it's
linked against libacl, libselinux, libc and libpcre2, so we should
check those.

I am in the process of running abi-compliance-checker over all debian
libraries to get a list of ones that expose an ABI change from either
enabling LFS or 64bit-time_t. tests so far say:
libacl1 is safe (no change)
libselinux is unknown (did not build)
libpcre2 is unknown (did not build)
(I'll take a look at those now as they are pretty fundamental)

If you choose to use gnulib, note that it turns 64-bit time on by
default if detected in glibc, unless you set a macro to explicitly keep 32-bit
time.

So in summary, tar is a good candidate for enabling LFS and time64
early but some checks should be done first, unless it is known that
there are no external interface changes other than to glibc.

I hope that is helpful.

Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

2023-02-15 Thread Theodore Ts'o

On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote:
> 
> You argue about shared libraries for non-packaged binaries.
> I think we mostly don't care about that, and again, I think that's at
> least a generally recognized thing that came out of our focus on
> packages and package dependencies.

Note that package dependencies doesn't allow a binary created on
Debian N to work on Debian N-1.  It just *prevents* the package from
being installed on Debian N-1.  If you care about allowing the package
to be instaslled on Debian N-1, that's what build chroots are for.
That's how we create packages for backports, after all.

I'm making a similar argument for mkfs and bootable images for older
distributions.  Just as you use a build chroot when you build a
package for Debian N-1, you should use a chroot when building a
bootable image for Debian N-1.  And that means using the chroot for
*everything*; not just installing the grub bootloader, but also
running mkfs.

(Note that using the sid grub bootloader while using the sid's
mkfs.ext4 would work in this particular case, but if you want a pure
"Bullseye" image which is identical to what running the Bullseye d-i
would create, then you should run Bullseye's mkfs, not sid's mkfs.)

  - Ted

Bug#1031380: install: options --compare (-C) and --preserve-timestamps are mutually exclusive

2023-02-15 Thread Frank Heckenbach

Package: coreutils
Version: 8.32-4+b1
Severity: normal

===

% install -C -p x y
install: options --compare (-C) and --preserve-timestamps are mutually exclusive
Try 'install --help' for more information.
% install --help
Usage: install [OPTION]... [-T] SOURCE DEST
  or:  install [OPTION]... SOURCE... DIRECTORY
  or:  install [OPTION]... -t DIRECTORY SOURCE...
  or:  install [OPTION]... -d DIRECTORY...

This install program copies files (often just compiled) into destination
locations you choose.  If you want to download and install a ready-to-use
package on a GNU/Linux system, you should instead be using a package manager
like yum(1) or apt-get(1).

In the first three forms, copy SOURCE to DEST or multiple SOURCE(s) to
the existing DIRECTORY, while setting permission modes and owner/group.
In the 4th form, create all components of the given DIRECTORY(ies).

Mandatory arguments to long options are mandatory for short options too.
  --backup[=CONTROL]  make a backup of each existing destination file
  -b  like --backup but does not accept an argument
  -c  (ignored)
  -C, --compare   compare each pair of source and destination files, and
in some cases, do not modify the destination at all
  -d, --directory treat all arguments as directory names; create all
components of the specified directories
  -D  create all leading components of DEST except the last,
or all components of --target-directory,
then copy SOURCE to DEST
  -g, --group=GROUP   set group ownership, instead of process' current group
  -m, --mode=MODE set permission mode (as in chmod), instead of rwxr-xr-x
  -o, --owner=OWNER   set ownership (super-user only)
  -p, --preserve-timestamps   apply access/modification times of SOURCE files
to corresponding destination files
  -s, --strip strip symbol tables
  --strip-program=PROGRAM  program used to strip binaries
  -S, --suffix=SUFFIX  override the usual backup suffix
  -t, --target-directory=DIRECTORY  copy all SOURCE arguments into DIRECTORY
  -T, --no-target-directory  treat DEST as a normal file
  -v, --verbose   print the name of each directory as it is created
  --preserve-context  preserve SELinux security context
  -Z  set SELinux security context of destination
file and each created directory to default type
  --context[=CTX] like -Z, or if CTX is specified then set the
SELinux or SMACK security context to CTX
  --help display this help and exit
  --version  output version information and exit

The backup suffix is '~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.
The version control method may be selected via the --backup option or through
the VERSION_CONTROL environment variable.  Here are the values:

  none, off   never make backups (even if --backup is given)
  numbered, t make numbered backups
  existing, nil   numbered if numbered backups exist, simple otherwise
  simple, never   always make simple backups

GNU coreutils online help: 
Report any translation bugs to 
Full documentation 
or available locally via: info '(coreutils) install invocation'

===

I see no explanation there why these options should be mutually exclusive.
(RTFS did not reveal any insight either.)

If the error message is unnecessary, please remove it.

Otherwise, please provide an explanation why and possible workarounds.

What I want to achieve is to preserve timestamps and to avoid doing extra work.
Both goals seem rather natural, and I see no reason why they should not be 
combined.

(In fact it seems "-p" should make it *easier* to implement "-C" as
timestamps will compare equal when nothing's changed. Then again,
need_copy() doesn't seem to care about times at all, so why should
it be incompatible with "-p"?)

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u5
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1031379: (no subject)

2023-02-15 Thread SDA

Package: kaffeine
Version: 2.0.18-1+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: marathon.duran...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Simply opening up Kaffeine and viewing a TV channel. Channel selection doesn't 
work either

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

Kernel: Linux 6.1.12-1-liquorix-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kaffeine depends on:
ii  iso-codes4.12.0-1
ii  kinit5.103.0-1
ii  kio  5.103.0-1
ii  libc62.36-8
ii  libdvbv5-0   1.22.1-5+b1
ii  libkf5configcore55.103.0-1
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5solid5 5.103.0-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5windowsystem5  5.103.0-1
ii  libkf5xmlgui55.103.0-1
ii  libqt5core5a 5.15.8+dfsg-2
ii  libqt5dbus5  5.15.8+dfsg-2
ii  libqt5gui5   5.15.8+dfsg-2
ii  libqt5sql5   5.15.8+dfsg-2
ii  libqt5sql5-sqlite5.15.8+dfsg-2
ii  libqt5widgets5   5.15.8+dfsg-2
ii  libqt5x11extras5 5.15.8-2
ii  libqt5xml5   5.15.8+dfsg-2
ii  libstdc++6   12.2.0-14
ii  libvlc5  3.0.18-2
ii  libxss1  1:1.2.3-1
ii  vlc-plugin-base  3.0.18-2
ii  vlc-plugin-video-output  3.0.18-2

kaffeine recommends no packages.

Versions of packages kaffeine suggests:
pn  libdvdcss2  

-- no debconf information

Bug#1031378: lintian: Does not know Binary-Only key-value from debian/changelog

Package: lintian
Version: 2.116.3
Severity: normal

Hi!

I'm getting a false-positive (on the UDD lintian summary page) for a
binNMU due to the Binary-Only field in the changelog header line:

,---
debsig-verify (0.28+b1) sid; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild for outdated Built-Using

 -- amd64 / i386 Build Daemon (x86-ubc-01) 
  Sun, 12 Feb 2023 21:30:22 +
`---

And this is the lintian output:

,---
$ lintian debsig-verify_0.28+b1_amd64.deb
W: debsig-verify: syntax-error-in-debian-changelog "unknown key-value key 
Binary-only - copying to XS-Binary-only" 
[usr/share/doc/debsig-verify/changelog.gz:1]
`---

Thanks,
Guillem

Bug#1031377: UDD/lintian: Needs to run lintian on all binaries generated from same source

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi!

There are some lintian tags (I know at least of
lacks-unversioned-link-to-shared-library), which require multiple
packages to be linted together for them to be emitted. In this case
libfooN and libfoo-dev for example. I'm getting unused-override tags
as these are not triggering (an example would be libbsd).

I guess the lintian runner used by UDD is executing lintian for each
.deb independently, because I assume it has no access to the .changes
files? If so, to avoid these false positives, it would need to get the
list of binary packages for a source and lint all of them with the same
lintian call.

Thanks,
Guillem

Bug#1031376: tzdata 2022g-3 removed /etc/timezone without a proper transition, breaking multiple packages

2023-02-15 Thread Daniel Leidert

Package: release.debian.org
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

A recent upload of tzdata [1] removes the file /etc/timezone from user's
computers. This broke multiple packages of the ruby-team (samizdat and
ruby-et-orbi being two of them). A quick search on codesearch.d.o [2] for the
usage of the file reveals more packages that are likely affected. While the
change itself is not unreasnable, it has a bad timing, and since it went
unannounced, multiple package require fixing now for Bookworm. I ask you to
find a reasonable approach to deal with this for the Bookworm release.

[1] 
https://tracker.debian.org/news/1418475/accepted-tzdata-2022g-3-source-into-unstable/
[2] https://codesearch.debian.net/search?q=%2Fetc%2Ftimezone=1

Regards, Daniel

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmPtdMMACgkQS80FZ8KW
0F11txAAxzQK/ackamzXJT8RChyY+EurntwQaMCuS6GzgVV/cdHEklSUzT51XAWk
Su4C3umDtcjmBQgMNqP94umV/Xp32zHJboVxC1RDmjxcK0CoWlgVNiCtNOO7K/sm
3t+oIMlsIsFbjxsJaCKuW1Q7Ob+ebJ9cEUI7y59zt0hWKxtgeqBeDbrgyuwguW/y
THigG9PnF4ObosO8HV8EgvdREl5GjynYALLlEv1quWX9lc6JKgt8uTW8+txjsE0o
jRiz7iXxHZdPwnVV10WFZM3MXO5Nbibe0YDd4lRIqBC58owE8KmeDv3eDpdl5vyA
CLBDlFUyq5gysgpte7veN0OMUh0HCL5akFc1EBda6xwI5+PqehQoULaTKvmSZ25A
HcY15c6eLJ+qPVYWZC7XFsnYH9ETOtRhkiuKEOxuVsKq+dwgaX1PYQiSo/OHqmXF
cOQQ7R0Mwc6CNnDVVbFHerUdS8Ur42MRm7OkaFfoBP/qkIBjjNBxlMgmkuV0GZw6
pLkTltK+ITooSXBh4307uo0qybq6QesE81NEbMGAB94yTSi1YIn0yXikd1JT2PYR
tdvxn9z1X6ssmAUSiy9y9q6wFqv/GTTGSXe33ieRGah11OD+oP1GcLx5ESo7W9Cz
IhHCX0nQxdS1EQbSnl6ZkM4ephqZ/41P4z+2MQLoHAJyBNNyMSo=
=ASWO
-END PGP SIGNATURE-

Bug#642207: Probably fixed upstream

2023-02-15 Thread Ben Harris


Control: tags -1 fixed-upstream

I've just committed what I hope is an adequate fix for this upstream, 
adding "in order" to the description of each set of clues.


https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=232cbaf5a8affcb0c61f1355f0569efaae534ad9

--
Ben Harris

Bug#1031375: wpa_cli: non-root server may be unable to reply to wpa_cli

2023-02-15 Thread Michael Gold

Package: wpasupplicant
Version: 2:2.10-11

Dear Maintainer,

I configured wpa_supplicant to run as a non-root user (with CAP_NET_RAW
and CAP_NET_ADMIN as the README suggests), and found that wpa_cli would
hang on startup when trying to connect to it.  strace shows that wpa_cli
creates named sockets in /tmp (despite $TMPDIR pointing elsewhere):
  bind(3, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_4848-1"}, 110) = 0
  bind(4, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_4848-2"}, 110) = 0
And then wpa_supplicant cannot reply:
  sendto(12, "OK\n", 3, 0, {sa_family=AF_UNIX, sun_path=
 "/tmp/wpa_ctrl_4824-2"}, 23) = -1 EACCES (Permission denied)
This is due to the umask and uid/gid being applied:
  srwx--x--x 1 michael michael 0 Feb 15 14:10 /tmp/wpa_ctrl_4824-2

A workaround is to set umask to 0 before running wpa_cli.

On Linux, it would be better for wpa_cli to use the "autobind" feature
(see man 7 unix) by calling bind() with addrlen==sizeof(sa_family_t).
This seems to work fine, and then the server needs no special permission
to reply and doesn't need access to /tmp (and the client won't leave
garbage there if it exits abnormally).

Also, maybe wpa_cli's existing Android code to chmod() the socket should
be enabled more widely.  POSIX says, for connect(), that "For SOCK_DGRAM
sockets, the peer address [...] limits the remote sender for subsequent
recv() functions"; so, if anyone other than the server sent messages to
the world-writable socket, the client wouldn't see them.

(I think SOCK_SEQPACKET would be a better fit than SOCK_DGRAM for the
control sockets, but that would require server and client changes.)

- Michael


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

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

Versions of packages wpasupplicant depends on:
ii  adduser3.131
ii  libc6  2.36-8
ii  libdbus-1-31.14.6-1
ii  libnl-3-2003.7.0-0.2+b1
ii  libnl-genl-3-200   3.7.0-0.2+b1
ii  libnl-route-3-200  3.7.0-0.2+b1
ii  libpcsclite1   1.9.9-1
ii  libreadline8   8.2-1.3
ii  libssl33.0.8-1

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information




signature.asc
Description: PGP signature

Bug#1031374: lxc: kaka@dmz103:~$ uname -a

2023-02-15 Thread John

Package: lxc
Version: 1:5.0.2-1
Severity: normal
X-Debbugs-Cc: johnw.m...@gmail.com

Dear Maintainer,

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

I see a lot of apparmor error messages like this, I want to know, how to 
allow/deny it (mute this "unix socket file_lock" error message), thanks.

2023-02-16T06:51:06.656725+08:00 dmz103 kernel: [32682.801651] audit: type=1400 
audit(1676501466.649:142): apparmor="DENIED" operation="file_lock" 
profile="lxc-container-default-cgns-local" pid=14515 comm="(crub_all)" 
family="unix" sock_type="dgram" protocol=0 requested_mask="send"
kaka@dmz103:~$ uname -a
Linux dmz103 6.1.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.11-1 (2023-02-09) 
x86_64 GNU/Linux


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]1.5.82
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  iproute2 6.1.0-1
ii  iptables 1.8.9-2
ii  libapparmor1 3.0.8-3
ii  libc62.36-8
ii  libcap2  1:2.66-3
ii  libgcc-s112.2.0-14
ii  liblxc-common1:5.0.2-1
ii  liblxc1  1:5.0.2-1
ii  libseccomp2  2.5.4-1+b3
ii  libselinux1  3.4-1+b5
ii  nftables 1.0.6-2
ii  sysvinit-utils [lsb-base]3.06-2

Versions of packages lxc recommends:
ii  apparmor   3.0.8-3
pn  debootstrap
ii  dirmngr2.2.40-1
ii  gnupg  2.2.40-1
pn  libpam-cgfs
ii  lxc-templates  3.0.4.48.g4765da8-1
ii  lxcfs  5.0.3-1
ii  openssl3.0.8-1
ii  rsync  3.2.7-1
pn  uidmap 
ii  wget   1.21.3-1+b2

Versions of packages lxc suggests:
ii  btrfs-progs  6.1.3-1
ii  lvm2 2.03.16-2
ii  python3-lxc  1:5.0.0-1+b1

-- Configuration Files:
/etc/default/lxc-net changed:
USE_LXC_BRIDGE="false"

/etc/lxc/default.conf changed:
lxc.net.0.type = veth
lxc.net.0.link = lxcbr30
lxc.net.0.flags = up
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 0


-- debconf information:
* lxc/auto_update_config: false

Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705

2023-02-15 Thread Amanda Trusted

Hi Jose,

Here are the relevant bug fixes -
[0] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37704 
https://www.cve.org/CVERecord?id=CVE-2022-37704
Fix - https://github.com/zmanda/amanda/pull/197

[1] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37705 
https://www.cve.org/CVERecord?id=CVE-2022-37705
Fix - https://github.com/zmanda/amanda/pull/196


[2] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37703 
https://www.cve.org/CVERecord?id=CVE-2022-37703
Fix - https://github.com/zmanda/amanda/pull/198

These 3 fixes are due for release as part of Amanda 3.5.3 within a week.

Let us know if there are any other action items for us.

Regards,

AmandaTrusted

Confidentiality Notice | The information transmitted by this email is intended 
only for the person or entity to which it is addressed. This email may contain 
proprietary, business-confidential and/or privileged material. If you are not 
the intended recipient of this message, be aware that any use, review, 
re-transmission, distribution, reproduction or any action taken in reliance 
upon this message is strictly prohibited. If you received this in error, please 
contact the sender and delete the material from all computers.

Bug#1031373: eric: Eric7 hangs during startup

2023-02-15 Thread MichaelR

Package: eric
Version: 23.2+ds1-1
Severity: important
X-Debbugs-Cc: michael...@runbox.com

Eric7 hangs during statup after upgrading from eric6 (and an upgrade
from Devuan Chimaera to Daedalus (Bullseye -> Bookworm). The main window
and splash screen are visible. The main window status bar says "Looking
for Documentation...".  The eric7_errorlog is included below. It seems
to be looking for some QT5 doc files.  I installed qt5-doc but it was no
help and pyqt5-doc does not exist.

I have purged ~/.eric7/  and  ~/.config/Eric7/ and renamed the
corresponding Eric6 dirs to try a clean start but it has no effect.  I
have also tried copying the contents of the eric6 dirs to the eric7
dirs - also with no effect.

This all happened initially with 23.1.1+ds1-1 but continues with
23.2+ds1-1.

## begin eric7_errorlog ##


: 
'NoneType' object has no attribute 'split'

  File 
"/usr/lib/python3/dist-packages/eric7/QtHelpInterface/HelpDocsInstaller.py", 
line 167, in run
changes |= self.__installQtDoc(doc, version, engine)
   ^
  File 
"/usr/lib/python3/dist-packages/eric7/QtHelpInterface/HelpDocsInstaller.py", 
line 195, in __installQtDoc
lst = info.split("|")
  ^^


Version Numbers:
  Python 3.11.1, 64-Bit
  Qt 6.4.2
  PyQt6 6.4.1
  PyQt6-Charts 6.4.0
  PyQt6-WebEngine 6.4.0
  PyQt6-QScintilla 2.13.3
  sip 6.7.6
  WebEngine 102.0.5005.177
(Security) 108.0.5359.94
  eric7 23.2 (rev. 9e14817925e5)

Platform: linux
3.11.1 (main, Dec 31 2022, 10:23:59) [GCC 12.2.0]

Desktop: XFCE

Session Type: X11

Plugins Version Numbers:
  PluginAbout 23.2
  PluginCodeStyleChecker 23.2
  PluginEricapi 23.2
  PluginEricdoc 23.2
  PluginSyntaxChecker 23.2
  PluginTranslator 23.2
  PluginVcsGit 23.2
  PluginVcsMercurial 23.2
  PluginVcsPySvn 23.2
  PluginVcsSubversion 23.2
  PluginVmListspace 23.2
  PluginVmTabview 23.2
  PluginWizardDotDesktop 23.2
  PluginWizardEricMessageBox 23.2
  PluginWizardEricPlugin 23.2
  PluginWizardPyRegExp 23.2
  PluginWizardQColorDialog 23.2
  PluginWizardQFileDialog 23.2
  PluginWizardQFontDialog 23.2
  PluginWizardQInputDialog 23.2
  PluginWizardQMessageBox 23.2
  PluginWizardQRegularExpression 23.2
  PluginWizardSetup 23.2

Distribution Info:
  /etc/os-release
PRETTY_NAME="Devuan GNU/Linux 5 (daedalus/ceres)"
NAME="Devuan GNU/Linux"
VERSION_ID="5"
VERSION="5 (daedalus/ceres)"
VERSION_CODENAME="daedalus ceres"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/;
SUPPORT_URL="https://devuan.org/os/community;
BUG_REPORT_URL="https://bugs.devuan.org/;

## end eric7_errorlog ##


-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)

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

Versions of packages eric depends on:
ii  black   22.12.0-1
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-hotkeys0~20130707+git2d51e3a9+dfsg-2.1
ii  libjs-jquery-isonscreen 1.2.0-1.1
ii  libjs-jquery-tablesorter1:2.31.3+dfsg1-3
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  python3 3.11.1-3
ii  python3-asttokens   2.2.1-1
ii  python3-chardet 5.1.0+dfsg-2
ii  python3-coverage6.5.0+dfsg1-2+b1
ii  python3-distutils   3.10.8-1
ii  python3-editorconfig0.12.3-1
ii  python3-isort   5.6.4-1
ii  python3-jedi0.18.2-1
ii  python3-parso   0.8.3-1
ii  python3-pygments2.14.0+dfsg-1
ii  python3-pyqt6   6.4.1-1
ii  python3-pyqt6.qsci  2.13.3+dfsg-3
ii  python3-pyqt6.qtcharts  6.4.0+dfsg-2
ii  python3-pyqt6.qthelp6.4.1-1
ii  python3-pyqt6.qtserialport  6.4.1-1
ii  python3-pyqt6.qtsvg 6.4.1-1
ii  python3-pyqt6.qtwebengine   6.4.0-1
ii  python3-send2trash  1.8.1~b0-2
ii  python3-trove-classifiers   2022.12.22-2

Versions of packages eric recommends:
ii  eric-api-files  23.2+ds1-1
ii  python3-rope1.7.0-1

Versions of packages eric suggests:
pn  pyqt5-doc 
pn  pyqt6-dev-tools   
pn  python3-doc   
pn  qt5-doc-html  
pn  qtbase5-doc-html  
pn  ruby  

-- no debconf information

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

2023-02-15 Thread Sam Hartman

> "Theodore" == Theodore Ts'o  writes:

Theodore> On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
>> 
>> I.E. I think your question of "for how long" has a very simple
>> answer based on our history: if we care about stability in this
>> instance it's for +/-1 Debian release.
>> 
>> I'm struggling trying to figure out whether we should commit to
>> that stability.

Theodore> I recogniuze that there are precedents that go in both
Theodore> directions.  We have *never* required that shared library
Theodore> linkages created in Debian N work in Debian N-1.  Sure,
Theodore> there are workarounds that you can use (e.g., compiling
Theodore> with -static), but I've listed workarounds for mke2fs as
Theodore> well.

For what it's worth, I don't think the shared library situation is at
all analogous.
We've basically decided that we care about shared libraries as they
interact with packages, and we've invented a whole bunch of dependency
logic to deal with them.
Which is to say we've explicitly turned shared libraries into a special
case.

You argue about shared libraries for non-packaged binaries.
I think we mostly don't care about that, and again, I think that's at
least a generally recognized thing that came out of our focus on
packages and package dependencies.

Which is to say that I think shared libraries are such a special case in
Debian you cannot use them to argue for or against anything else.

You make some good arguments based on other things.  I just don't want
us using shared library handling as a precedent for anything other than
shared libraries, so I am arguing against it.

Bug#1017780: Version bump: 1.4.230

2023-02-15 Thread Chris Knadle


Hello Jarl.

Jarl Gullberg:

I've got a patchset that reworks the control files for proper CMake
support and a couple of fixes to the existing patches in order to make
1.4.287 play nice with OpenSSL 3.0. I'm not sure if I've updated the
upstream source in line with policy for this package, though, and
could use some help making sure I'm doing it right.


Debian Unsable is currently in "soft freeze" because of the upcoming release of 
Debian 12 "Bookworm", such that only small targeted fixes can be uploaded at 
this point.


   https://release.debian.org/testing/freeze_policy.html

It's not realistic to try to upload 1.4.287 to Debian to get it into the next 
release at this point. However; it would still be useful to have a newer version 
packaged in order to release it for the Mumble Ubuntu PPA which is also out of 
date. I've been working on the Mumble 1.5.517 snapshot release, but 
unfortunately its not ready for release because the systemd service file it 
ships is broken and the sysv init file was removed.


I'll send another email to this bug + all involved with the bug as to the status 
of the 1.5.517 work and what got uploaded to Debian (1.3.4-4) and the MR 
requests that were incorporated.



At the moment, this is what I've done:
1. downloaded the upstream release tarball
3. renamed it to mumble_1.4.287.orig.tar.gz
2. cd mumble && pristine-tar commit ../mumble_1.4.287.orig.tar.gz
3. unpack tarball in upstream branch, commit and tag as 'upstream/1.4.287'
4. merge 'upstream' into 'debian'


I haven't tested doing the above manually, but on first glance it looks right. 
I believe these are the same general steps that git-buildpackage does when 
running 'gbp import-orig '. If you don't use git-buildpackage yet and 
are interested there are some hints about using it here:


  https://wiki.debian.org/PackagingWithGit

And the DebConf conferences have recorded videos on using git-buildpackage also, 
I think starting around 2013.



I only found the 'extras/make-mumble-git-tarball.sh' script after the
fact, and I do see that that script does some cleanup. I'm also seeing
a lot of dpkg-source warnings about removed files when I build, so I'm
pretty sure I've done something wrong.


If you're importing a tarball, make-mumble-git-tarball.sh isn't meant to be 
used.

The make-mumble-git-tarball.sh was specifically written for mumble 1.3 from Git 
and isn't meant for Mumble 1.4 and above; 1.4 changes file structure 
significantly. It was a script I had to build because at the time upstream 
wanted me to release Mumble 1.3 and there wasn't a tarball available to do it 
from, and Mumble's git repo uses submodules such that a standard 'git archive' 
command to build a tarball won't work alone.


Upstream built another tool to extract a tarball from git which is a Python 3 
script which is part of the upstream Git repo, so the make-mumble-git-tarball.sh 
script I created is outdated.


  https://github.com/mumble-voip/mumble/pull/6016

This is how to create a 1.5.x tarball within the 1.5.x Git checkout:

   scripts/create_source_archive.py --revision 1.5.x --format=tar

But again this is only for the situation of creating a tarball from Git to work 
from; it's not needed if there's already a tarball to import.



That aside, everything seems to run fine (with some hiccups related to
config files for mumble-server that I assume has something to do with
the above). I can open up a couple of MRs on Salsa if you want,
provided I can get some handholding in regards to how you want it done
:)


Please do not open an MR right now, as I have 1.5.517 to push to the repo, so I 
won't be able to pull an MR for 1.4.287 unless its to a Git branch, which I 
don't know how to do off the top of my head.


Also, MRs for the Mumble repo in Salsa are disabled for all but those within the 
VoIP team for now, because they've been happening without my knowledge. I need 
to figure out how to configure email notifications -- there were MRs put there 
for a long time that I was never notified by, with no BTS bug report associated 
with. I never knew MRs in Salsa were a thing until discussion about them in this 
particular bug.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

2023-02-15 Thread Theodore Ts'o

On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
> 
> I.E. I think your question of "for how long" has a very simple answer
> based on our history: if we care about stability in this instance it's
> for +/-1 Debian release.
> 
> I'm struggling trying to figure out whether we should commit to that
> stability.

I recogniuze that there are precedents that go in both directions.  We
have *never* required that shared library linkages created in Debian N
work in Debian N-1.  Sure, there are workarounds that you can use
(e.g., compiling with -static), but I've listed workarounds for mke2fs
as well.

In other cases, we may have gone out of our way to provide these sorts
of transitions.

> I also think it would be reasonable for the project to decide we care
> about this stability, and that we want bullseye grub to work with a
> filesystem made on sid.

Well, I agree that it's a Distribution level decision.  And if the
distribution decides that we should acccomodate this particular case
case, we can certainly make a Debian-specific change to the
/etc/mke2fs.conf config file which doesn't enable metadata_csum_seed
by default.

> I understand you do not support that stability decision.

The argument I would make is that it is a case by case decision, and
not a global one where *all* all generated objects created by Debian N
have to work in Debian N-1.  For example, this is most manifestly
*not* true for any shared library compiled by default that uses glibc.
And I don't personally consider vmdb2 to be important enough to be
worth this kind of solicitude when we haven't done it for shared
library lankage --- just based on the popcon statistics if nothing
else.

But, if the release team belives that a note in the release notes is
not sufficient, I can certainly change the default for Debian.  The
*reason* why the default features can be configured in
/etc/mke2fs.conf is because distributions or individual users might
want to make different decisions about the defaults than the upstream
maintainer of e2fsprogs.  So I'll certainly abide by the ruling of the
release team in this matter, and I guess if Daniel doesn't like the
decision they make, he can always appeal this to the Debian TC.

The appeal chain on this one seems pretty clear.  As the Debian
maintainer for the e2fsprogs package; I have my opinion on how this
can be resolved.  Daniel has appelaed this to release team, and if
necessary, he can appeal to the Technical Committee, and he can ever
try to organize a Debian GR if he feels so strongly about the issue.

Given that there are some *very* easy workarounds, which I have
listed, just as there are simple workarounds for creating a binary for
Bookworm that will work for Bullseye, I really do believe this is a
tempest in a teacup.

Best regards,

- Ted

Bug#1031372: podman-compose: Unable to start container via compose file when network_mode=host

2023-02-15 Thread Chris Coughlan

Package: podman-compose
Version: 1.0.3-3
Severity: important

Dear Maintainer,

Attempted to run the following compose file:

```
version: "3.9"
services:
  plex:
container_name: plex
image: linuxserver/plex:latest
network_mode: host
ports:
  - 32400:32400
  - 3005:3005
  - 8324:8324
  - 32469:32469
  - 1900:1900
  - 32410:32410
  - 32412:32412
  - 32413:32413
  - 32414:32414
devices:
  /dev/dri:/dev/dri
volumes:
  - /home/chris/appdata/docker:/config
  - /mnt/nfs/media/movies:/movies:ro
  - /mnt/nfs/media/tv:/tv:ro
  - /mnt/nfs/media/hallmark:/hallmark:ro
environment:
  - VERSION=docker
  - PUID=99
  - PGID=100
restart: unless-stopped
```

When running `podman-compose up`, I received the following error:

```
chris@hg-app-01:~$ podman-compose up
['podman', '--version', '']
using podman version: 4.3.1
** excluding:  set()
['podman', 'network', 'exists', 'chris_default']
podman create --name=plex --label io.podman.compose.config-hash=123 --label 
io.podman.compose.project=chris --label io.podman.compose.version=0.0.1 --label 
com.docker.compose.project=chris --label 
com.docker.compose.project.working_dir=/home/chris --label 
com.docker.compose.project.config_files=docker-compose.yaml --label 
com.docker.compose.container-number=1 --label com.docker.compose.service=plex 
--network host --device / --device d --device e --device v --device / --device 
d --device r --device i --device : --device / --device d --device e --device v 
--device / --device d --device r --device i -e VERSION=docker -e PUID=99 -e 
PGID=100 -v /home/chris/appdata/docker:/config -v 
/mnt/nfs/media/movies:/movies:ro -v /mnt/nfs/media/tv:/tv:ro -v 
/mnt/nfs/media/hallmark:/hallmark:ro --net chris_default --network-alias plex 
-p 32400:32400 -p 3005:3005 -p 8324:8324 -p 32469:32469 -p 1900:1900 -p 
32410:32410 -p 32412:32412 -p 32413:32413 -p 32414:32414 --restart 
unless-stopped linuxserver/plex:latest
Error: cannot set multiple networks without bridge network mode, selected mode 
host: invalid argument
exit code: 125
podman start -a plex
Error: no container with name or ID "plex" found: no such container
exit code: 125
```

I found a Github issue that covers the same, or similar, issue, that appears to 
be resolved upstream, but not yet released.

https://github.com/containers/podman-compose/issues/512

Thanks,
Chris Coughlan

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

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

Versions of packages podman-compose depends on:
ii  python3 3.11.1-3
ii  python3-dotenv  0.21.0-1
ii  python3-yaml6.0-3+b2

Versions of packages podman-compose recommends:
ii  podman  4.3.1+ds1-5+b2

podman-compose suggests no packages.

-- no debconf information

Bug#1031189: libogre-dev: Does not automatically derive plugin path

2023-02-15 Thread Matthew Fennell

Sorry for wasting your time, I think I was wrong to raise this bug and it can be
closed.

I see that /usr/lib/x86_64-linux-gnu/OGRE/cmake/OGREConfig.cmake defines
OGRE_PLUGIN_DIR, and that this path contains a plugins.cfg file that includes
the correct PluginFolder filepath.

Therefore, no magic is required - I simply needed to pass this variable to my
application.

Thanks again for maintaining this package - and thanks also Andreas for
moving on my report to the correct list,
Matthew

Bug#1031371: curl: CVE-2023-23914 CVE-2023-23915 CVE-2023-23916

2023-02-15 Thread Moritz Mühlenhoff

Source: curl
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for curl.

CVE-2023-23914
curl: HSTS ignored on multiple requests
https://curl.se/docs/CVE-2023-23916.html

CVE-2023-23915
curl: HSTS amnesia with --parallel
https://curl.se/docs/CVE-2023-23915.html

CVE-2023-23914
curl: HSTS ignored on multiple requests
https://curl.se/docs/CVE-2023-23914.html


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-23914
https://www.cve.org/CVERecord?id=CVE-2023-23914
[1] https://security-tracker.debian.org/tracker/CVE-2023-23915
https://www.cve.org/CVERecord?id=CVE-2023-23915
[2] https://security-tracker.debian.org/tracker/CVE-2023-23916
https://www.cve.org/CVERecord?id=CVE-2023-23916

Please adjust the affected versions in the BTS as needed.

Bug#1031370: python-werkzeug: CVE-2023-23934 CVE-2023-25577

Source: python-werkzeug
Version: 2.2.2-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for python-werkzeug.

CVE-2023-23934[0]:
| Werkzeug is a comprehensive WSGI web application library. Browsers may
| allow "nameless" cookies that look like `=value` instead of
| `key=value`. A vulnerable browser may allow a compromised application
| on an adjacent subdomain to exploit this to set a cookie like
| `=__Host-test=bad` for another subdomain. Werkzeug prior to 2.2.3 will
| parse the cookie `=__Host-test=bad` as __Host-test=bad`. If a Werkzeug
| application is running next to a vulnerable or malicious subdomain
| which sets such a cookie using a vulnerable browser, the Werkzeug
| application will see the bad cookie value but the valid cookie key.
| The issue is fixed in Werkzeug 2.2.3.


CVE-2023-25577[1]:
| Werkzeug is a comprehensive WSGI web application library. Prior to
| version 2.2.3, Werkzeug's multipart form data parser will parse an
| unlimited number of parts, including file parts. Parts can be a small
| amount of bytes, but each requires CPU time to parse and may use more
| memory as Python data. If a request can be made to an endpoint that
| accesses `request.data`, `request.form`, `request.files`, or
| `request.get_data(parse_form_data=False)`, it can cause unexpectedly
| high resource usage. This allows an attacker to cause a denial of
| service by sending crafted multipart data to an endpoint that will
| parse it. The amount of CPU time required can block worker processes
| from handling legitimate requests. The amount of RAM required can
| trigger an out of memory kill of the process. Unlimited file parts can
| use up memory and file handles. If many concurrent requests are sent
| continuously, this can exhaust or kill all available workers. Version
| 2.2.3 contains a patch for this issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-23934
https://www.cve.org/CVERecord?id=CVE-2023-23934
[1] https://security-tracker.debian.org/tracker/CVE-2023-25577
https://www.cve.org/CVERecord?id=CVE-2023-25577

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1031369: gss-ntlmssp: CVE-2023-25563 CVE-2023-25564 CVE-2023-25565 CVE-2023-25566 CVE-2023-25567

Source: gss-ntlmssp
Version: 1.0.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for gss-ntlmssp.

CVE-2023-25563[0]:
| GSS-NTLMSSP is a mechglue plugin for the GSSAPI library that
| implements NTLM authentication. Prior to version 1.2.0, multiple out-
| of-bounds reads when decoding NTLM fields can trigger a denial of
| service. A 32-bit integer overflow condition can lead to incorrect
| checks of consistency of length of internal buffers. Although most
| applications will error out before accepting a singe input buffer of
| 4GB in length this could theoretically happen. This vulnerability can
| be triggered via the main `gss_accept_sec_context` entry point if the
| application allows tokens greater than 4GB in length. This can lead to
| a large, up to 65KB, out-of-bounds read which could cause a denial-of-
| service if it reads from unmapped memory. Version 1.2.0 contains a
| patch for the out-of-bounds reads.


CVE-2023-25564[1]:
| GSS-NTLMSSP is a mechglue plugin for the GSSAPI library that
| implements NTLM authentication. Prior to version 1.2.0, memory
| corruption can be triggered when decoding UTF16 strings. The variable
| `outlen` was not initialized and could cause writing a zero to an
| arbitrary place in memory if `ntlm_str_convert()` were to fail, which
| would leave `outlen` uninitialized. This can lead to a denial of
| service if the write hits unmapped memory or randomly corrupts a byte
| in the application memory space. This vulnerability can trigger an
| out-of-bounds write, leading to memory corruption. This vulnerability
| can be triggered via the main `gss_accept_sec_context` entry point.
| This issue is fixed in version 1.2.0.


CVE-2023-25565[2]:
| GSS-NTLMSSP is a mechglue plugin for the GSSAPI library that
| implements NTLM authentication. Prior to version 1.2.0, an incorrect
| free when decoding target information can trigger a denial of service.
| The error condition incorrectly assumes the `cb` and `sh` buffers
| contain a copy of the data that needs to be freed. However, that is
| not the case. This vulnerability can be triggered via the main
| `gss_accept_sec_context` entry point. This will likely trigger an
| assertion failure in `free`, causing a denial-of-service. This issue
| is fixed in version 1.2.0.


CVE-2023-25566[3]:
| GSS-NTLMSSP is a mechglue plugin for the GSSAPI library that
| implements NTLM authentication. Prior to version 1.2.0, a memory leak
| can be triggered when parsing usernames which can trigger a denial-of-
| service. The domain portion of a username may be overridden causing an
| allocated memory area the size of the domain name to be leaked. An
| attacker can leak memory via the main `gss_accept_sec_context` entry
| point, potentially causing a denial-of-service. This issue is fixed in
| version 1.2.0.


CVE-2023-25567[4]:
| GSS-NTLMSSP, a mechglue plugin for the GSSAPI library that implements
| NTLM authentication, has an out-of-bounds read when decoding target
| information prior to version 1.2.0. The length of the `av_pair` is not
| checked properly for two of the elements which can trigger an out-of-
| bound read. The out-of-bounds read can be triggered via the main
| `gss_accept_sec_context` entry point and could cause a denial-of-
| service if the memory is unmapped. The issue is fixed in version
| 1.2.0.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-25563
https://www.cve.org/CVERecord?id=CVE-2023-25563
[1] https://security-tracker.debian.org/tracker/CVE-2023-25564
https://www.cve.org/CVERecord?id=CVE-2023-25564
[2] https://security-tracker.debian.org/tracker/CVE-2023-25565
https://www.cve.org/CVERecord?id=CVE-2023-25565
[3] https://security-tracker.debian.org/tracker/CVE-2023-25566
https://www.cve.org/CVERecord?id=CVE-2023-25566
[4] https://security-tracker.debian.org/tracker/CVE-2023-25567
https://www.cve.org/CVERecord?id=CVE-2023-25567

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1031368: php8.2: CVE-2023-0567 CVE-2023-0568 CVE-2023-0662

Source: php8.2
Version: 8.2.2-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for php8.2, making the
bureport RC to ideally have those fixed before bookworm release goes
out.

CVE-2023-0567[0]:
| PHP: Password_verify() always return true with some hash

CVE-2023-0568[1]:
| PHP: 1-byte array overrun in common path resolve code

CVE-2023-0662[2]:
| PHP: DOS vulnerability when parsing multipart request body

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-0567
https://www.cve.org/CVERecord?id=CVE-2023-0567
[1] https://security-tracker.debian.org/tracker/CVE-2023-0568
https://www.cve.org/CVERecord?id=CVE-2023-0568
[2] https://security-tracker.debian.org/tracker/CVE-2023-0662
https://www.cve.org/CVERecord?id=CVE-2023-0662

Regards,
Salvatore

Bug#1031365: sox: rec and play tty output

2023-02-15 Thread Salve

Package: sox
Version: 14.4.2+git20190427-3.4
Severity: important

Dear Maintainer,

Recording (rec) and playing (play) seems to work correctly. But the writing to 
the tty is messed up:
Time counting is updated only around every third second, and the peaklevel 
meter is not responding or is not in sync. Also, the cursor moves slowly to the 
left.

I run pipewire as sound server.

...$ LANG=C dpkg -l 'sox*' 'pipewire*' 'pulse*' 'wireplumber*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  VersionArchitecture 
Description
+++-=-==--===
ii  pipewire:amd640.3.65-2   amd64audio 
and video processing engine multimedia server
ii  pipewire-alsa:amd64   0.3.65-2   amd64
PipeWire ALSA plugin
un  pipewire-audio-client-libraries   (no 
description available)
ii  pipewire-bin  0.3.65-2   amd64
PipeWire multimedia server - programs
ii  pipewire-jack:amd64   0.3.65-2   amd64
PipeWire JACK plugin
rc  pipewire-media-session0.4.1-4+b1 amd64
example session manager for PipeWire
un  pipewire-media-session-pulseaudio (no 
description available)
ii  pipewire-pulse0.3.65-2   amd64
PipeWire PulseAudio daemon
un  pulseaudio(no 
description available)
un  pulseaudio-module-bluetooth   (no 
description available)
ii  pulseaudio-utils  16.1+dfsg1-2+b1amd64
Command line tools for the PulseAudio sound server
ii  sox   14.4.2+git20190427-3.4 amd64Swiss 
army knife of sound processing
ii  wireplumber   0.4.13-1   amd64
modular session / policy manager for PipeWire
un  wireplumber-doc   (no 
description available)


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

Kernel: Linux 6.1.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=nn_NO.UTF-8, LC_CTYPE=nn_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nn_NO:nn:no_NO:no:nb_NO:nb:da:sv:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sox depends on:
ii  libc62.36-8
ii  libsox-fmt-alsa  14.4.2+git20190427-3.4
ii  libsox-fmt-base  14.4.2+git20190427-3.4
ii  libsox3  14.4.2+git20190427-3.4

sox recommends no packages.

Versions of packages sox suggests:
pn  libsox-fmt-all  

-- no debconf information

Bug#1030455: schedule: FTBFS: AssertionError: ScheduleValueError not raised by until

2023-02-15 Thread Étienne Mollier

Control: tags -1 + patch

Hi schedule maintainers,

I prepared a patch fixing the present issue in attachment
(assuming I don't screw up my email); I also informed
upstream[1], although they didn't seem very active in the past
year.  Instead of assuming tests are alway run on office hours,
I make sure the deadline is one hour ago.  The test should be
much more robust to fully automated QA/CI tasks in such
configuration.

[1]: https://github.com/dbader/schedule/pull/563

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.
On air: Gilgamesh - One End More / Phils Little Dance - For Phi…
Description: fix test failure when run early
 Since introduction of the "until" job scheduling method to apply deadlines,
 the test_until_time fails when run between midnight and 5am local hour.
 This patch ought to ensure the deadline is always one hour ago independently
 of the time of the day, or night.
Author: Étienne Mollier 
Bug: https://github.com/dbader/schedule/issues/488
Bug-Debian: https://bugs.debian.org/1030455
Forwarded: https://github.com/dbader/schedule/pull/563
Last-Update: 2023-02-15
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- schedule-1.1.0.orig/test_schedule.py
+++ schedule-1.1.0/test_schedule.py
@@ -314,7 +314,8 @@
 self.assertRaises(
 ScheduleValueError, every().day.until, datetime.timedelta(minutes=-1)
 )
-self.assertRaises(ScheduleValueError, every().day.until, datetime.time(hour=5))
+one_hour_ago = datetime.datetime.now() - datetime.timedelta(hours=1)
+self.assertRaises(ScheduleValueError, every().day.until, one_hour_ago)
 
 # Unschedule job after next_run passes the deadline
 schedule.clear()


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

2023-02-15 Thread Sam Hartman

> "Theodore" == Theodore Ts'o  writes:
 the answer to your "how long" is that packages
>> should also work with the kernel from the previous and the kernel
>> from the next Debian release.

Theodore> This isn't a problem with the kernel.

I don't think that was Adrian's point.
I think Adrian was making an analogy and suggesting that filesystems
made by bookworm should be usable by bullseye and by the release after
bookworm--usable by the bootloaders etc.
Or at least that would be a reasonable thing to do based on stability
guarantees we've made in other cases.

I.E. I think your question of "for how long" has a very simple answer
based on our history: if we care about stability in this instance it's
for +/-1 Debian release.

I'm struggling trying to figure out whether we should commit to that
stability.
I do find this change after the transition freeze to be kind of late.  I
understand it's not a traditional transition.
But for example you're not leaving a lot of time for asking programs
like vmdb2 or fai-diskimage to adjust how they call fsck.
If you made this change a few months ago, it would be reasonable to file
bugs against those packages and ask them to adjust how they call
mkfs.ext4.

I want to stress that I'm not  affiliated with the release team; my
opinion here has no official weight.
But I would ask you to consider that it is kind of late to make  a
change in the required filesystem features for bookworm and suggest a
more orderly process would be to make the change in the next release and
give packages that need to build vm images a chance to adjust.

I also think it would be reasonable for the project to decide we care
about this stability, and that we want bullseye grub to work with a
filesystem made on sid.
I understand you do not support that stability decision.

signature.asc
Description: PGP signature

Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

2023-02-15 Thread Sebastian Ramacher

Control: clone -1 -2
Control: reassign -2 vmdb2 0.26-2

On 2023-02-14 01:01:38 +0100, Daniel Leidert wrote:
> Hi Steve,
> 
> I believe that your fix to grub2 in Sid is not enough to handle
> #1030939/#1030846.
> 
> This problem breaks e.g. vmdb2. I can no longer create a Bullseye
> system image with vmdb2 on Sid, because the grub-install step in the
> Bullseye chroot now fails, because the created filesystem (created with
> e2fsprogs on Sid) cannot be recognized by grub. I have to downgrade
> e2fsprogs to the version in Testing to get the build going again. It
> also means that a Bookworm system can never be used to format and
> debootstrap a Bullseye or Buster system that requires a grub
> installation.
> 
> I guess that the fix applied to grub2 in Sid would have to be applied
> to grub2 in Bullseye as well (and basically to any grub2 package in any
> Debian or Ubuntu or Raspbian release supported by debootstrap).
> 
> This situation is really messy. It breaks basically all my image builds
> with vmdb2.

Regardless of the outcome of #1031325, this issue will need to be fixed
in vmdb2 eventually. vmdb2, similar to other bootstraping tools, has to
account for the feature and disable it if necessary for older
distributions.

Cloning and reassign to vmdb2.

Cheers
-- 
Sebastian Ramacher

Bug#1031356: pinctrl: linux-image-6.1.0-3-amd64 : kernel NULL pointer dereference with intel pinctrl driver

Hi,

On Wed, Feb 15, 2023 at 04:53:49PM +0100, Frederic Buisson wrote:
> Package: src:linux
> Version: 6.1.8-1
> Severity: important
> File: pinctrl
> X-Debbugs-Cc: frederic.buis...@f-g.fr
>
> Dear Maintainer,
>
> The problem appears at boot time  :
>
> [1.582787] BUG: kernel NULL pointer dereference, address: 
> [1.582816] #PF: supervisor read access in kernel mode
> [1.582831] #PF: error_code(0x) - not-present page
> [1.582845] PGD 0 P4D 0
> [1.582856] Oops:  [#1] PREEMPT SMP NOPTI
> [1.582870] CPU: 0 PID: 142 Comm: systemd-udevd Not tainted 6.1.0-3-amd64 
> #1  Debian 6.1.8-1
> [1.582893] Hardware name: To Be Filled By O.E.M. To Be Filled By 
> O.E.M./IMB-1004, BIOS P1.10 04/19/2022
> [1.582917] RIP: 0010:strcmp+0xc/0x30
> [1.582934] Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 
> c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 
> 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c0 c3
> [1.582976] RSP: 0018:a7e9c037fc50 EFLAGS: 00010246
> [1.582991] RAX:  RBX: c02f8c40 RCX: 
> a7e9c037fc28
> [1.583009] RDX:  RSI: c02f6c9f RDI: 
> 
> [1.583026] RBP:  R08: 925240c113d0 R09: 
> a7e9c037fa00
> [1.583043] R10:  R11:  R12: 
> c02fa0e0
> [1.583059] R13:  R14: 925242e64428 R15: 
> 
> [1.583076] FS:  7f961323e8c0() GS:9253c840() 
> knlGS:
> [1.583096] CS:  0010 DS:  ES:  CR0: 80050033
> [1.583111] CR2:  CR3: 0001013a2000 CR4: 
> 00350ef0
> [1.583128] Call Trace:
> [1.583139]  
> [1.583147]  intel_pinctrl_get_soc_data+0x6b/0xc0
> [1.583169]  intel_pinctrl_probe_by_uid+0xe/0x30
> [1.583186]  platform_probe+0x41/0x90
> [1.583201]  really_probe+0xdb/0x380
> [1.583214]  ? pm_runtime_barrier+0x50/0x90
> [1.583228]  __driver_probe_device+0x78/0x170
> [1.583242]  driver_probe_device+0x1f/0x90
> [1.583254]  __driver_attach+0xce/0x1c0
> [1.583267]  ? __device_attach_driver+0x110/0x110
> [1.583281]  bus_for_each_dev+0x84/0xd0
> [1.583295]  bus_add_driver+0x1ae/0x200
> [1.583747]  driver_register+0x89/0xe0
> [1.584209]  ? 0xc02fd000
> [1.584651]  do_one_initcall+0x56/0x220
> [1.585070]  do_init_module+0x4a/0x200
> [1.585478]  __do_sys_finit_module+0xac/0x120
> [1.585882]  do_syscall_64+0x58/0xc0
> [1.586287]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> [1.586696] RIP: 0033:0x7f96139475a9
> [1.587094] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
> f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 
> 01 f0 ff ff 73 01 c3 48 8b 0d 27 08 0d 00 f7 d8 64 89 01 48
> [1.588359] RSP: 002b:7ffc2256b558 EFLAGS: 0246 ORIG_RAX: 
> 0139
> [1.588783] RAX: ffda RBX: 56554ca8c6b0 RCX: 
> 7f96139475a9
> [1.589205] RDX:  RSI: 7f9613adaefd RDI: 
> 0005
> [1.589603] RBP: 7f9613adaefd R08:  R09: 
> 56554ca705f0
> [1.589996] R10: 0005 R11: 0246 R12: 
> 0002
> [1.590408] R13:  R14: 56554ca8f920 R15: 
> 56554c70fe4f
> [1.590824]  
> [1.591209] Modules linked in: pinctrl_elkhartlake(+) button
> [1.591610] CR2: 
> [1.592004] ---[ end trace  ]---

This could be the same/simliar as
https://bugzilla.kernel.org/show_bug.cgi?id=213365 (cf.
https://bugzilla.redhat.com/show_bug.cgi?id=1948468).

Please have a look if you have an update for the BIOS.

Regards,
Salvatore

Bug#1030882: RFS: dbus-c++/0.9.0-11 [QA] -- C++ API for D-Bus

2023-02-15 Thread Bastian Germann


Am 15.02.23 um 19:25 schrieb Thomas Uhle:
After reverting the split of the package libdbus-c++-1v5 into seperate packages and assuming the 
other updates make their way into bookworm just in time, would it then make sense to wait until the 
release of bookworm to prepare another revision of dbus-c++ with this remaining change targeted for 
unstable or would it then also be required to upload to experimental at first?


No, you can wait after bookworm release date and directly go unstable.

Should I already change "UNRELEASED" into "unstable" in debian/changelog or shall I leave this as it 
is?


Yes, please target unstable.

Bug#801065: Documenting how to not fail postinst on service fails to start

2023-02-15 Thread Marvin Renich

* Steve Langasek  [230214 13:09]:
> On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote:
> > * Steve Langasek  [230212 00:03]:
> > > FWIW I think that it's the wrong thing to do if the "circumstances" 
> > > include
> > > reverse-dependencies on the package which expect to interact with the
> > > service the package provides, as these packages may themselves do such
> > > interaction in the maintainer script, resulting in cascading damage.
> 
> > > And the decision for whether there are reverse-dependencies on your 
> > > package
> > > is non-local and asynchronous.
> 
> > > Therefore I think it's always wrong for a package's postinst to exit 0 if:
> 
> > >  - it ships a service,
> > >  - it is a new install or an upgrade on a system where the service was
> > >previously started successfully, and
> > >  - the service fails to start in the postinst.
> 
> > I have to strongly disagree with this.  Suppose package A ships a
> > service, and package B depends on A and requires A's service to be
> > running in order for package B to be useful.  If I install A and disable
> > its service, and then install B, I would be very disappointed if B's
> > postinst script failed and left B in what dpkg considers an unconfigured
> > state.
> 
> > Succeeding the install and requiring the user to manually run some
> > documented configuration steps is _so_ much more user friendly than
> > leaving a broken package (from dpkg's POV).  I intentionally disabled A,
> > so when I want to use B, I will take the necessary steps.  I would
> > expect that attempting to use B without completing the configuration
> > would produce a useful error message.
> 
> Up until now the conversation has been about the semantics of exit codes for
> package A's maintainer script.
> 
> You are now arguing that a package *B* is not allowed to fail on install if
> the conditions for its full configuration have not been met.
> 
> And I absolutely disagree!  Your rationale that it's user-unfriendly to
> leave a package in an unconfigured state, if followed to its logical
> conclusion, applies to *any* package.  We might as well not care about
> postinst exit codes at all!

You are right, I went off on a tangent.  I agree that if a package
installation script is unable to leave the package's own configuration
in a "usable" state (barring explicit misconfiguration prior to upgrade
by the sysadmin), that it should fail.

The condition in the original bug report was that the problem that
prevented the service from starting or restarting was orthogonal to
anything the installation script was doing.  In that case, the
installation script will leave the filesystem in an identical state
regardless of whether starting the service succeeds or fails.  The
package is installed and perfectly usable if and when the outside
condition, unrelated to the package installation, is fixed.

In these cases, there is nothing more that the installation scripts can
or should do, so there is no need to leave the package in a dpkg
half-configured state.

I think the real problem is that the ideas of "configured" and "running"
have been conflated specifically for services.  The same type of issue
with a user program would not cause a failure of installation.

The part of your message that I disagree with is

> > >  - the service fails to start in the postinst.

This implies that "the service is running" is part of "the service is
configured", which is where I disagree.

...Marvin

Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x

Source: qemu
Followup-For: Bug #1030545

After further investigation, the absence of the 'getenforce' binary in
the libguestfs build-deps appears to be a non-issue (and in hindsight was not
relevant in a 'src:qemu' bug thread, anyway).  There is a comment[1] in
the source mentioning that failures to find and run that command can safely
be ignored.

Also, I didn't mean to infer in my previous message that the text I quoted was
my own words; I'm using reportbug from the command-line and forgot to add an
MUA-style author attribution.  I think I'll step away from attempts to resolve
this issue because I seem to be adding more noise than value.

[1] - 
https://salsa.debian.org/libvirt-team/libguestfs/-/blob/967a8cff7dda94b873d0ec88e5e738f18c50335f/test-tool/test-tool.c#L205-210

Bug#1010317: raspi-firmware: broken support for CM3 and CM4 devices

2023-02-15 Thread Cyril Brulebois

Diederik de Haas  (2023-02-15):
> It would be useful to know what the current status is (for Bookworm) with 
> version 1.20220830+ds-1 and ideally also with upstream's 1.20230106.
> 
> (I really hope upstream releases another version as they've now also switched 
> to the 6.1 kernel series)

As far as I know it's been fine since the first release from last year.
I haven't checked lately for possible regressions since then, but I'll
be sure to file bug reports for them and come up with a plan if needed.

Next “let's play with Raspberry devices” window for me is a few weeks
from now.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1010317: raspi-firmware: broken support for CM3 and CM4 devices

2023-02-15 Thread Diederik de Haas

On Thu, 28 Apr 2022 20:47:02 +0200 Cyril Brulebois  wrote:
> Package: raspi-firmware
> Version: 1.20210303+ds-2
> Severity: important

It would be useful to know what the current status is (for Bookworm) with 
version 1.20220830+ds-1 and ideally also with upstream's 1.20230106.

(I really hope upstream releases another version as they've now also switched 
to the 6.1 kernel series)

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

Bug#1031215: ITP Gradience

2023-02-15 Thread matthias . geiger1024

Hi Lorenzo,

I saw you mail. Gradience could probably be maintained with the Debian GNOME 
team since it's somewhat related. There you could easily find someone to 
sponsor you upload. At the moment there is the debian freeze in place for the 
bookworm release, meaning no new packages will be uploaded. This doesn't mean 
you can't start working on the package.  For gradience to be distributed all 
dependencies have to be in debian. Looking at 
https://github.com/GradienceTeam/Gradience/blob/main/requirements.txt there 
might be some missing ones which in turn might need packaging first.
 
For an example of a gnome/gtk python app and the packaging you can take a look 
at https://salsa.debian.org/gnome-team/wike . Feel free to send me an email if 
any questions arise.

CC Jeremy: Looks like someone was faster ;)

Happy hacking,

Matthias Geiger (werdahias)

Bug#1021041: Aw: Bug#1021041: ITP: parallel-hashmap --

2023-02-15 Thread Steffen Möller

Hi Andrius,
Thank you tons, yes, by all means, please proceed.
Best,
Steffen

> Gesendet: Mittwoch, 15. Februar 2023 um 08:12 Uhr
> Von: "Andrius Merkys" 
> An: 1021...@bugs.debian.org, "Steffen Moeller" 
> Betreff: Bug#1021041: ITP: parallel-hashmap --  description>
>
> Hi Steffen,
>
> On Fri, 30 Sep 2022 23:50:47 +0200 Steffen Moeller 
> wrote:
> > Subject: ITP: parallel-hashmap -- 
> > Package: wnpp
> > Owner: Steffen Moeller 
> > Severity: wishlist
>
> I found your ITP and initial packaging for parallel-hashmap. I need this
> library to package pytorch-sparse (#1031265). Is it OK if I finalise and
> upload it, or do you prefer to do so yourself?
>
> Best wishes,
> Andrius
>

Bug#1031360: rsyslog: SEGV on startup with truncated files in spool

2023-02-15 Thread Michael Biebl


Am 15.02.23 um 19:27 schrieb Michael Biebl:

Am 15.02.23 um 18:16 schrieb Michael Biebl:

Control: tags -1 + moreinfo

Hi,

thanks for the bug report.

Am 15.02.23 um 17:16 schrieb Matthew Vernon:

I attach a tarball of the offending files in case they help.


Can you share your rsyslog configuration and the output of
running "rsyslogd -d -n" ?


I can try to reproduce the issue once I have the full rsyslog config.
Otherwise, a backtrace (with debug symbols) would be helpful as well.


I'm asking because if I can't reproduce the issue myself, I would kindly 
ask you to try rsyslog from bpo and if it's still reproducible there, 
file the issue directly upstream at

https://github.com/rsyslog/rsyslog/issues
It's likely that they will have further questions which are best 
answered by you directly.


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#960231: kubernetes: provision of 'kubeadm' command-line utility

Source: kubernetes
Followup-For: Bug #960231

Also: from attempting dpkg-buildpackage with the patch applied, I think that it
is incomplete (an additional .install file is required, for example).  I'll
try to fix that soon.

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

2023-02-15 Thread Felix Zielcke

On Wed, 15 Feb 2023 12:38:15 +0100 Adam Borowski 
wrote:
> 
> 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.
> 
> 

Hi,

When uploading -4 I didn't think the lib would be ever needed. So I
just removed it.
I packaged it now the proper way and uploaded -5 to mentors.
I'm just a DM so I'll need a sponsor for binNEW.

Adam do you have interest in doing this one upload or should I file a
RFS?

Bug#960231: kubernetes: provision of 'kubeadm' command-line utility

Source: kubernetes
Followup-For: Bug #960231
Control: severity -1 wishlist

Hi Janos,

I'm reducing the severity of this report, because I don't think that the
initial severity was correct (my apologies).

Attached is an updated patch; please note:

  - This won't be in time for bookworm as I understand it (too far into freeze)
  - I'm not sure about the version number I've suggested in the changelog
  - The changelog entry is attributed to my work email since it is work-related

The patch should apply with patch options '-Np1' in the Debian source package
directory.

Thank you,
James
diff -Nru a/debian/changelog b/debian/changelog
--- a/debian/changelog  2020-05-03 22:13:17.0 +0100
+++ b/debian/changelog  2023-02-15 18:30:42.0 +0100
@@ -1,3 +1,11 @@
+kubernetes (1.20.5+really1.20.2-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * kubernetes-admin
+- New package containing kubeadm command (Closes: #960231)
+
+ -- James Addison   Wed, 15 Feb 2023 18:30:42 +0100
+
 kubernetes (1.20.5+really1.20.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
--- a/debian/control2020-05-03 22:12:59.0 +0100
+++ b/debian/control2023-02-15 18:24:28.0 +0100
@@ -6,6 +6,19 @@
 Standards-Version: 4.5.0
 Homepage: http://kubernetes.io/
 
+Package: kubernetes-admin
+Architecture: amd64 i386 armel armhf arm64 s390x
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Description: Kubernetes master binaries
+ Kubernetes is a portable, extensible, open-source platform for managing
+ containerized workloads and services, that facilitates both declarative
+ configuration and automation. It has a large, rapidly growing ecosystem.
+ Kubernetes services, support, and tools are widely available.
+ .
+ This package ships the Kubernetes kubeadm binary, which can be used
+ to initialize and configure clusters.
+
 Package: kubernetes-client
 Architecture: amd64 i386 armel armhf arm64 s390x
 Depends: ${shlibs:Depends}, ${misc:Depends}
diff -Nru a/debian/copyright b/debian/copyright
--- a/debian/copyright  2020-03-22 10:53:29.0 +
+++ b/debian/copyright  2023-02-15 18:24:28.0 +0100
@@ -846,6 +846,11 @@
2013 TOML authors
 License: Expat
 
+Files: vendor/sigs.k8s.io/yaml/*
+Copyright: 2014 Sam Ghods
+   2012, 2013 The Go Authors
+License: Expat and BSD-3-clause-SIGS-YAML
+
 Files: vendor/vbom.ml/util/*
 Copyright: 2015 Frits van Bommel
 License: Expat
@@ -1812,3 +1817,29 @@
   .
   Creative Commons may be contacted at creativecommons.org.
 
+License: BSD-3-clause-SIGS-YAML
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions are
+  met:
+  .
+ * Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above
+  copyright notice, this list of conditions and the following disclaimer
+  in the documentation and/or other materials provided with the
+  distribution.
+ * Neither the name of Google Inc. nor the names of its
+  contributors may be used to endorse or promote products derived from
+  this software without specific prior written permission.
+  .
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff -Nru a/debian/kubernetes-admin.bash-completion 
b/debian/kubernetes-admin.bash-completion
--- a/debian/kubernetes-admin.bash-completion   1970-01-01 01:00:00.0 
+0100
+++ b/debian/kubernetes-admin.bash-completion   2023-02-15 18:24:28.0 
+0100
@@ -0,0 +1 @@
+_output/bash-completion/kubeadm
diff -Nru a/debian/kubernetes-admin.docs b/debian/kubernetes-admin.docs
--- a/debian/kubernetes-admin.docs  1970-01-01 01:00:00.0 +0100
+++ b/debian/kubernetes-admin.docs  2023-02-15 18:24:28.0 +0100
@@ -0,0 +1,3 @@
+README.md
+SUPPORT.md
+_output/NOTICE
diff -Nru a/debian/kubernetes-admin.install b/debian/kubernetes-admin.install
--- a/debian/kubernetes-admin.install   1970-01-01 01:00:00.0 +0100
+++ b/debian/kubernetes-admin.install   2023-02-15 18:24:28.0 +0100
@@ -0,0 +1 @@
+_output/bin/kubeadm usr/bin/
diff -Nru

Bug#1029913: Fwd: Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability

2023-02-15 Thread Frank Heckenbach

Siep Kroonenberg wrote:

> The problem was that the test was specifically for a file rather
> than for any filesystem item.
> 
> In the updated TL package, the test has been removed altogether
> since there was already a later test for successful generation of a
> temp subdirectory.
> 
> The updated package is now available as both a CTAN package and a TL
> package.

I tried it, and it fixes the problem as I reported.

Of course, chdir into /tmp is a bit risky as any file creation
before the next chdir would be susceptible to the same problem, but
I assume you made sure this won't happen.

BTW, when looked at the changes made, I noticed this:

  io.stdout:write('cannot cd into '..d..'\n')

I don't know much about Lua conventions, but normally I'd expect
such messages to be written to stderr, not stdout.

Bug#1031360: rsyslog: SEGV on startup with truncated files in spool

2023-02-15 Thread Michael Biebl


Am 15.02.23 um 18:16 schrieb Michael Biebl:

Control: tags -1 + moreinfo

Hi,

thanks for the bug report.

Am 15.02.23 um 17:16 schrieb Matthew Vernon:

I attach a tarball of the offending files in case they help.


Can you share your rsyslog configuration and the output of
running "rsyslogd -d -n" ?


I can try to reproduce the issue once I have the full rsyslog config.
Otherwise, a backtrace (with debug symbols) would be helpful as well.

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030882: RFS: dbus-c++/0.9.0-11 [QA] -- C++ API for D-Bus

2023-02-15 Thread Thomas Uhle


On Wed, 15 Feb 2023, Bastian Germann wrote:


On Wed, 8 Feb 2023 18:58:49 +0100 Thomas Uhle 
 wrote:

 + Put libdbus-c++-ecore-1.so.* and libdbus-c++-glib-1.so.* in their own
   binary packages libdbus-c++-ecore-1-0 and libdbus-c++-glib-1-0 resp.
   to avoid pulling in e.g. Ecore libraries (and their dependencies) on
   systems where these libraries are not needed. (Closes: 1018772)


It is too late for bookworm. So please target experimental with the new binary 
packages.
If you want the other changes to get into bookworm, you should separate them 
into their own unstable revision.


Thanks a lot for your response and having a look into the changes.

After reverting the split of the package libdbus-c++-1v5 into seperate 
packages and assuming the other updates make their way into bookworm just 
in time, would it then make sense to wait until the release of bookworm to 
prepare another revision of dbus-c++ with this remaining change targeted 
for unstable or would it then also be required to upload to experimental 
at first?


Should I already change "UNRELEASED" into "unstable" in debian/changelog 
or shall I leave this as it is?


Best regards,

Thomas Uhle

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

2023-02-15 Thread Milan Oravec

On Tue, Feb 14, 2023 at 1:04 PM Ritesh Raj Sarraf  wrote:

> Hello Migo,
>
>
Hello Ritesh Raj Sarraf,

On Sun, 2023-02-12 at 11:29 +0100, migo wrote:
> > Package: open-iscsi
> > Version: 2.1.3-5
> > Severity: normal
> > X-Debbugs-Cc: migo.ora...@gmail.com
> >
> > Dear Maintainer,
> >
> > I want to apologize if this is not the right place to report this
> > issue, but I need somewhere to start.
> >
> > I've lot of this error messages ind dmesg:
> >
> > Feb 09 10:56:05 virt2n kernel:  connection2:0: detected conn error
> > (1015)
> > Feb 09 10:56:05 virt2n iscsid[2790]: connection2:0 is operational
> > after recovery (1 attempts)
> > Feb 09 10:56:05 virt2n iscsid[2790]: connection1:0 is operational
> > after recovery (1 attempts)
>
> Connection dropped and re-established. Looks normal.
>

Yes I understand that message but WHY this happens, what can be the cause
for this? Link is stable and no errors are reported on ifaces connected to
SAN switch:

ens1f0: flags=4163  mtu 9000
inet 10.11.12.17  netmask 255.255.255.0  broadcast 10.11.12.255
inet6 fe80::9640:c9ff:fe5f:9172  prefixlen 64  scopeid 0x20
ether 94:40:c9:5f:91:72  txqueuelen 1000  (Ethernet)
RX packets 184466309231  bytes 146589180968929 (133.3 TiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 86121730517  bytes 284905539017306 (259.1 TiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 102  memory 0xa582-a583

ens1f1: flags=4163  mtu 9000
inet 10.11.14.17  netmask 255.255.255.0  broadcast 10.11.14.255
inet6 fe80::9640:c9ff:fe5f:9173  prefixlen 64  scopeid 0x20
ether 94:40:c9:5f:91:73  txqueuelen 1000  (Ethernet)
RX packets 114453605386  bytes 85545283479332 (77.8 TiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 236069263519  bytes 283187128321034 (257.5 TiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 132  memory 0xa580-a581



>
> > Feb 09 10:56:05 virt2n iscsid[2790]: Kernel reported iSCSI connection
> > 1:0 error (1015 - ISCSI_ERR_DATA_DGST: Data digest mismatch) state
> > (3)
> > Feb 09 10:56:05 virt2n iscsid[2790]: Kernel reported iSCSI connection
> > 2:0 error (1015 - ISCSI_ERR_DATA_DGST: Data digest mismatch) state
> > (3)
> > Feb 09 10:56:10 virt2n iscsid[2790]: connection1:0 is operational
> > after recovery (1 attempts)
> > Feb 09 10:56:10 virt2n iscsid[2790]: connection2:0 is operational
> > after recovery (1 attempts)
>
> Conn 2:0 recovered but the earlier error it gave looks misleading to
> me. What target controller you have ? What there a failover across the
> nodes ? How does the target handle the transition period to initiator
> queries ?
>

yes, two paths with failover


>
> > Feb 09 10:56:28 virt2n kernel:  connection1:0: detected conn error
> > (1015)
> > Feb 09 10:56:28 virt2n kernel:  connection2:0: detected conn error
> > (1015)
> > Feb 09 10:56:28 virt2n iscsid[2790]: Kernel reported iSCSI connection
> > 1:0 error (1015 - ISCSI_ERR_DATA_DGST: Data digest mismatch) state
> > (3)
> > Feb 09 10:56:28 virt2n iscsid[2790]: Kernel reported iSCSI connection
> > 2:0 error (1015 - ISCSI_ERR_DATA_DGST: Data digest mismatch) state
> > (3)
> > Feb 09 10:56:33 virt2n kernel:  connection1:0: detected conn error
> > (1015)
> > Feb 09 10:56:33 virt2n kernel:  connection2:0: detected conn error
> > (1015)
> > Feb 09 10:56:33 virt2n iscsid[2790]: connection2:0 is operational
> > after recovery (1 attempts)
> > Feb 09 10:56:33 virt2n iscsid[2790]: connection1:0 is operational
> > after recovery (1 attempts)
>
> Same logs again.
>
> > ... snipped ...
>
> > or enventually this:
> >
> > Feb 10 20:39:39 virt2n kernel:  connection1:0: ping timeout of 5 secs
> > expired, recv timeout 5, last rx 19077132455, last ping 19077133712,
> > now 19077134976
> > Feb 10 20:39:39 virt2n kernel:  connection1:0: detected conn error
> > (1022)
> > Feb 10 20:39:39 virt2n kernel: scsi_io_completion_action: 11
> > callbacks suppressed
> > Feb 10 20:39:39 virt2n kernel: sd 1:0:0:5: [sdl] tag#122 FAILED
> > Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
> > Feb 10 20:39:39 virt2n kernel: sd 1:0:0:5: [sdl] tag#122 CDB: Test
> > Unit Ready 00 00 00 00 00 00
> > Feb 10 20:39:39 virt2n kernel: sd 1:0:0:16: [sdah] tag#103 FAILED
> > Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
> > Feb 10 20:39:39 virt2n kernel: sd 1:0:0:16: [sdah] tag#103 CDB: Test
> > Unit Ready 00 00 00 00 00 00
> > Feb 10 20:39:39 virt2n kernel: sd 1:0:0:24: [sdax] tag#115 FAILED
> > Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
> > Feb 10 20:39:39 virt2n kernel: sd 1:0:0:24: [sdax] tag#115 CDB: Test
> > Unit Ready 00 00 00 00 00 00
> >
> > When this happens iscsi opration is interupted for few seconds,
> > multipath -ll reports (this is only example, i/o pending is reported
> > dor all 30 dm-s:
> >
>
> This all looks normal to me. If

Bug#1031345: [Pkg-electronics-devel] Bug#1031345: kicad: Please update

2023-02-15 Thread Bdale Garbee

Carsten Schoenert  writes:

> unfortunately this will not happen, it's simply to late get KiCad 7.0.0 
> into the next stable release.

The same is true for the ringdove suite, including pcb-rnd.

> We will work on providing backported packages as usual once the bookworm 
> release is out.

Indeed.

Bdale


signature.asc
Description: PGP signature

Bug#1031363: librnp0 from experimental breaks thunderbird openpgp feature

2023-02-15 Thread Eric Valette

Package: librnp0
Version: 0.17.0~git20220428-1
Severity: serious
Justification: makes unrelated software on the system

Thre is no dependency and the packages installs but thunderbird do not manage 
to dlopen the dddl and it breaks opengpg.

Downgrading to unstable version fixes the problem.


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.93 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librnp0 depends on:
ii  libbotan-2-19  2.19.3+dfsg-1
ii  libbz2-1.0 1.0.8-5+b1
ii  libc6  2.36-8
ii  libgcc-s1  12.2.0-14
ii  libjson-c5 0.16-2
ii  libstdc++6 12.2.0-14
ii  zlib1g 1:1.2.13.dfsg-1

librnp0 recommends no packages.

librnp0 suggests no packages.

-- no debconf information

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

2023-02-15 Thread Theodore Ts'o

On Wed, Feb 15, 2023 at 11:47:08AM +0200, Adrian Bunk wrote:
> 
> For normal library dependencies
>   Depends: libc6 (>= 2.34)
> will do the right thing automatically.

Sure, but dependencies only apply if you are using building packages.
If you are not building packages, but just moving binaries between
distribution versions --- which is analogous to what is going on here
when someone moves a file system from one distro version to another.
For example:

% echo 'int main() { printf("Hello, world\n"); return 0; }' > /tmp/foo.c ; gcc 
-w -o /tmp/foo /tmp/foo.c ; /tmp/foo ; schroot -c bullseye-amd64 /tmp/foo
Hello, world
/tmp/foo: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found 
(required by /tmp/foo)

> e2fsprogs adding Breaks against older versions of bootloaders and other 
> software that lacks support for the new default might be a good idea.
> 
> The situtation is different when a relationship cannot be reliably 
> expressed by package dependencies.

Unfortunately, package dependencies won't address the concern raised
by Daniel.  The mkfs.ext4, debootstrap, etc., are being run on a one
version of the distro, such as for example sid or Bookworm, but then
when the grub bootloader is installed --- presumably in a chroot, so
that you get the Bullseye grub on a Bullseye VM image --- it won't
know that the base file system was built on Sid or Bookworm.  Of
course, if you run the mkfs.ext4 in a Bullseye chroot, everything will
work *just* *fine*.  It's just that this isn't Daniel's workflow.

> For the kernel the answer to your "how long" is that packages should 
> also work with the kernel from the previous and the kernel from the
> next Debian release.

This isn't a problem with the kernel.  For the ext4 feature that
Daniel cited, metadata_csum_seed was first supported in 4.4 kernel
(note that Debian *stretch* used the 4.9 kernel and 4.4 was first
released in 2016 --- six years ago).  On the file system utility side,
e2fsprogs 1.43 also support for metadata_csum_seed (again, support
going back to stretch).

The xfs bigtime feature, which was similarly enabled in Bookworm, was
supported in the kernel the xfsprogs for **many** years.  In general,
file system developers do understand the concern of needing to wait
before enabling a feature by default in mke2fs.conf.

The issue here is in grub support.  Part of the issue is that
admittedly, file system developers don't worry as much about
bootloaders as much as we do for kernels and the file system
utilities.  The other is that the grub2 upstream simply hasn't been as
responsive or quick at doing releases.  The fix landed in grub2
upstream in June of 2021.  So all distributions tend to carry large
number of grub2 cherry-picks.

> If the feature stays enabled by default in bookworm:
> Everyone using grub is an x86 thing, for embedded ARM it is more common 
> to use a once ported ancient u-boot on your hardware forever.[1]
> A bug against the release-notes pseudo-package with text describing
> the incompatibility and possible workarounds would be appreciated.

Would you prefer that we repurpose (and retitle) this bug, or open a
new one?

Here's a quick rough draft of what that text might look like, at least
for the ext4 metadata_csum_seed.  (If it's helpful, I can try to also
write a blurb for XFS, although I'd want to run it by the XFS kernel
maintainer, Darrick Wong first.)

 cut here ---

In the Bookworm release, the mkfs.ext4 will enable the orphan_file and
metadata_csum_seed feature.  The orphan_file feature significantly
improves performance for workloads which are truncated or deleting
files in parallel.  The orphan_file feature is an ext4 "compat"
feature, so file systems with the orphan_file feature can be mounted
on older kernels who do not understand the orphan_file feature, so
long as the file system was cleanly unmounted.  If the file system was
not cleanly unmounted (for example, due to a crash or power failure),
the file system must be fsck'ed or mounted on a Bookworm system before
the file system is transferred to an older system.

The metadata_csum_seed feature allows the file system UUID to
be modified without needing to update all of the file system metadata,
which is often important in VM context where root file systems are
cloned from read-only images, and having unique UUID's is important to
avoid confusion when the block device might be mounted on another
whose root file system is similarly cloned from the same base image.

The metadata_csum_seed feature is an ext4 "incompat" feature, which
means that the kernel must understand the feature before it will be
able mount a file system with that feature.  Fortunately, the Linux
kernels starting with 4.4 (and the Debian 9.0 "stretch" release)
support the metadata_csum_seed feature.  So data disks formatted with
metadata_csum_seed can be mounted on systems with older distro
versions without concerns in nearly all case.

Unfortunately, grub2 support for the metadata_csum_seed

Bug#1031362: python-pycdlib: FTBFS (undeclared build-dependency on tzdata)

2023-02-15 Thread Santiago Vila


Package: src:python-pycdlib
Version: 1.12.0+ds1-4
Severity: important
Tags: ftbfs patch

Dear maintainer:

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


[...]
 debian/rules binary-indep
make: pyversions: No such file or directory
py3versions: no X-Python3-Version in control file, using supported versions
dh binary-indep --with python3
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
make[1]: pyversions: No such file or directory
py3versions: no X-Python3-Version in control file, using supported versions
echo "Do nothing..."
Do nothing...
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
make[1]: pyversions: No such file or directory
py3versions: no X-Python3-Version in control file, using supported versions
echo "Do nothing..."
Do nothing...
make[1]: Leaving directory '/<>'
   create-stamp debian/debhelper-build-stamp
   dh_prep -i
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
make[1]: pyversions: No such file or directory
py3versions: no X-Python3-Version in control file, using supported versions
pkgos-dh_auto_install --no-py2 --in-tmp
+ PKGOS_IN_TMP=no
+ echo WARNING: --no-py2 is deprecated and always on.
WARNING: --no-py2 is deprecated and always on.
+ shift
+ PKGOS_IN_TMP=yes
+ shift
+ dpkg-parsechangelog -SSource
+ SRC_PKG_NAME=python-pycdlib
+ echo python-pycdlib
+ sed s/python-//
+ PY_MODULE_NAME=pycdlib
+ py3versions -vr
+ PYTHON3S=3.11
+ [ yes = yes ]
+ TARGET_DIR=tmp
+ pwd
+ python3.11 setup.py install --install-layout=deb --root 
/<>/debian/tmp
running install
/usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip 
and other standards-based tools.
  warnings.warn(
running build
running build_py
creating build
creating build/lib
creating build/lib/pycdlib
copying pycdlib/isohybrid.py -> build/lib/pycdlib
copying pycdlib/pycdlibexception.py -> build/lib/pycdlib
copying pycdlib/facade.py -> build/lib/pycdlib
copying pycdlib/utils.py -> build/lib/pycdlib
copying pycdlib/inode.py -> build/lib/pycdlib
copying pycdlib/eltorito.py -> build/lib/pycdlib
copying pycdlib/pycdlib.py -> build/lib/pycdlib
copying pycdlib/headervd.py -> build/lib/pycdlib
copying pycdlib/udf.py -> build/lib/pycdlib
copying pycdlib/dr.py -> build/lib/pycdlib
copying pycdlib/path_table_record.py -> build/lib/pycdlib
copying pycdlib/pycdlibio.py -> build/lib/pycdlib
copying pycdlib/dates.py -> build/lib/pycdlib
copying pycdlib/backport_functools.py -> build/lib/pycdlib
copying pycdlib/__init__.py -> build/lib/pycdlib
copying pycdlib/rockridge.py -> build/lib/pycdlib
running build_scripts
creating build/scripts-3.11
copying and adjusting tools/pycdlib-explorer -> build/scripts-3.11
copying and adjusting tools/pycdlib-extract-files -> build/scripts-3.11
copying and adjusting tools/pycdlib-genisoimage -> build/scripts-3.11
changing mode of build/scripts-3.11/pycdlib-explorer from 644 to 755
changing mode of build/scripts-3.11/pycdlib-extract-files from 644 to 755
changing mode of build/scripts-3.11/pycdlib-genisoimage from 644 to 755
running install_lib
creating /<>/debian/tmp
creating /<>/debian/tmp/usr
creating /<>/debian/tmp/usr/lib
creating /<>/debian/tmp/usr/lib/python3
creating /<>/debian/tmp/usr/lib/python3/dist-packages
creating /<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/isohybrid.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/pycdlibexception.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/facade.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/utils.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/inode.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/eltorito.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/pycdlib.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/headervd.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/udf.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/dr.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/path_table_record.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/pycdlibio.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/dates.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/backport_functools.py -> 
/<>/debian/tmp/usr/lib/python3/dist-packages/pycdlib
copying build/lib/pycdlib/__init__.py ->

Bug#1031352: Chromium on Wayland: Cannot join a Microsoft Teams enterprise meeting

2023-02-15 Thread Andres Salomon

Chromium 110.0.5481.77 is currently in stable and unstable (not yet in 
testing because of various delays). Please try with that instead.


On Wed, Feb 15 2023 at 03:19:08 PM +0100, Amr Ibrahim 
 wrote:

Package: chromium
Version: 109.0.5414.119-1
Severity: normal

Dear Maintainer,

Running Chromium on Wayland: I cannot join a Microsoft Teams 
enterprise

meeting.

An enterprise meeting is a meeting (external from my organisation), 
which I am
not automatically authorised to enter until someone who is already 
inside the

meeting accepts my request to enter the meeting.

Once someone accepts my request to enter the meeting, I get thrown 
out of the

meeting and have to try again without success.

Please let me know if more info is required.

Best,
Amr


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (50, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common
109.0.5414.119-1

ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.36-8
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-1+b2
ii  libdbus-1-31.14.6-1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1
ii  libevent-2.1-7 
2.1.12-stable-5+b1

ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   
2.12.1+dfsg-4

ii  libgbm122.3.3-1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.5-1
ii  libgtk-3-0 3.24.36-3
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-1+b1
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87-1
ii  libopenjp2-7   2.5.0-1+b1
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 
1.50.12+ds-1

ii  libpng16-161.6.39-2
ii  libpulse0  
16.1+dfsg1-2+b1
ii  libre2-9   
20220601+dfsg-1+b1

ii  libsnappy1v5   1.1.9-2
ii  libstdc++6 12.2.0-14
ii  libwebp7   1.2.4-0.1
ii  libwebpdemux2  1.2.4-0.1
ii  libwebpmux31.2.4-0.1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.3-3
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   
2:1.3.4-1+b1

ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml2
2.9.14+dfsg-1.1+b3

ii  libxnvctrl0520.56.06-1
ii  libxrandr2 
2:1.5.2-2+b1

ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-backend]  43.1-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.14.1-1
ii  zlib1g

Bug#1031361: unblock: grub2/2.06-8

2023-02-15 Thread Steve McIntyre

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

Hey folks!

Please unblock package grub2

We have a slew of bug fixes that we want in bookworm:

  * Fix an issue in an f2fs security fix which caused mount
failures. Closes: #1021846. Thanks to программист некто for helping
to debug the problem!
  * Switch build-deps from gcc-10 to gcc-12. Closes: #1022184
  * Include upstream patch to enable EFI zboot support on arm64.
Closes: #1026092
  * grub-mkconfig: Restore umask for the grub.cfg. CVE-2021-3981
Closes: #1001414
  * postinst: be more verbose when using grub-install to install onto
devices.
  * /etc/default/grub: Fix comment about text-mode console.
Fixes #845683
  * grub-install: Don't install the shim fallback program when called
with --removable. Closes: #1016737
  * grub-install: Don't use our grub CD EFI image for --removable.
Closes: #1026915. Thanks to Pascal Hambourg for the patch.
  * Ignore some new ext2 flags to stay compatible with latest mke2fs
defaults. Closes: #1030846

Several of these are major issues for people affected, particularly
#1030846. We'd like to get the new version in to work with the next
d-i release please. Kibi is already aware!

unblock grub2/2.06-8

Bug#1031360: rsyslog: SEGV on startup with truncated files in spool

2023-02-15 Thread Michael Biebl


Control: tags -1 + moreinfo

Hi,

thanks for the bug report.

Am 15.02.23 um 17:16 schrieb Matthew Vernon:

I attach a tarball of the offending files in case they help.


Can you share your rsyslog configuration and the output of
running "rsyslogd -d -n" ?

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030901: zoph: [INTL:it] Italian po-debconf translation

2023-02-15 Thread Ceppo

Oh, one last thing: at  was suggested a
very good correction at line 34.  Here is the updated version.
Sorry for the multiple versions, I forgot to go through the Request For Review
before sending the translation.


--
Ceppo
# zoph po-debconf Italian translation.
# Copyright (C) 2023 zoph's copyright holder
# This file is distributed under the same license as the zoph package.
# Ceppo , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: zoph\n"
"Report-Msgid-Bugs-To: z...@packages.debian.org\n"
"POT-Creation-Date: 2016-12-15 12:45+\n"
"PO-Revision-Date: 2023-02-08 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Description
#: ../zoph.templates:1001
msgid "Remove image files (photos) you uploaded ?"
msgstr "Rimuovere i file immagine (fotografie) caricati?"

#. Type: select
#. Description
#: ../zoph.templates:1001
msgid ""
"Zoph imports files into, by default, /var/lib/zoph If you decide to remove "
"the zoph package, but wish to keep the photos you uploaded answer yes. To "
"have the files removed, answer no. To be asked at package removal time "
"answer ask."
msgstr ""
"Per impostazione predefinita, zoph importa i file in /var/lib/zoph. Se si "
"decide di rimuovere il pacchetto zoph ma si desidera mantenere le fotografie "
"caricate, rispondere sì. Perché i file vengano rimossi, rispondere no. "
"Perché venga chiesto al momento della rimozione del pacchetto rispondere "
"chiedi."

#. Type: boolean
#. Description
#: ../zoph.templates:2001
msgid "Keep uploaded image files after removal ?"
msgstr "Mantenere dopo la rimozione i file immagine caricati?"

#. Type: boolean
#. Description
#: ../zoph.templates:2001
msgid ""
"You have imported some photos into /var/lib/zoph, and are removing the zoph "
"package."
msgstr ""
"Alcune fotografie sono state importate in /var/lib/zoph, e si sta rimuovendo "
"il pacchetto zoph."

Bug#1031354: Fwd: Bug#1031354 closed by Paul Tagliamonte (Re: Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an

2023-02-15 Thread Paul Tagliamonte

On Wed, Feb 15, 2023 at 11:23:29AM -0500, Paul Tagliamonte wrote:
> >$ dpkg -S $(which ps)
> >On a system with /usr/bin/ps

Also, forgot to reply to this bit; this is due to usr merge. This is a
known sharp edge that folks are actively working on.

While it's present at `/usr/bin`, that's because `/bin` is symlinked,
dpkg, abet confusingly, knows it as /bin/ps, not /usr/bin/ps

$ dpkg -S /bin/ps
procps: /bin/ps

  paultag

-- 
:wq

Bug#1031356: pinctrl: linux-image-6.1.0-3-amd64 : kernel NULL pointer dereference with intel pinctrl driver

2023-02-15 Thread Diederik de Haas

On Wednesday, 15 February 2023 16:53:49 CET Frederic Buisson wrote:
> Package: src:linux
> Version: 6.1.8-1
> Severity: important
> File: pinctrl

Please try the 6.1.12-1 version when it becomes available to you.
There are several pinctrl fixes in that version.

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

Bug#1031354: Fwd: Bug#1031354 closed by Paul Tagliamonte (Re: Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an

2023-02-15 Thread Paul Tagliamonte

On Wed, Feb 15, 2023 at 11:21:02AM -0500, Steve Roggenkamp wrote:
>I attempted to use the phusion passenger package, but it would not
>properly run because it needs /usr/bin/ps for somer reason.

This happens with some other packages too, like Jenkins, a friend
pointed out to me.

>No
>problem, I will just install it. When I searched for the package
>containing it on [5]packages.debian.org, the search returns no results.
> That is, there is no package that  contains /usr/hin/ps.  I expected

The package is `procps`

Description: /proc file system utilities
 This package provides command line and full screen utilities for browsing
 procfs, a "pseudo" file system dynamically generated by the kernel to
 provide information about the status of entries in its process table
 (such as whether the process is running, stopped, or a "zombie").
 .
 It contains free, kill, pkill, pgrep, pmap, ps, pwdx, skill, slabtop,
 snice, sysctl, tload, top, uptime, vmstat, w, and watch.

>it would be in coreutils, but it is not.  It seems to be present on a
>another recent Debian bullseye install I did, but, again, it is
>contained in any package.  It should be contained in a package in the
>base_system, but it is not.  How does it get there? What if there is a
>security issue identified with the program, would it be updated? Having
>a binary program installed on a system without it being contained in a
>package seems to contravene the Debian packaging policies.
>Downstream distributions, such as Ubuntu are also affected.  I
>confirmed the /usr/bin/ps is not contained in any package for 22.04
>LTS, although I have not filed a bug report.
>You can reproduce the problem easily by either searching for
>/usr/bin/ps on [6]packages.debian.org or
>$ dpkg -S $(which ps)
>On a system with /usr/bin/ps
>Thanks,
>Steve

Hope that helps,
  Paul

-- 
:wq

Bug#1031354: closed by Paul Tagliamonte (Re: Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an ISO install.)

2023-02-15 Thread Steve Roggenkamp

Thanks for your prompt attention.

This is an unusual problem. I wish I could have provided a better explanation 
of the problem, but I did not have access to a text editor in the bullseye-slim 
environment.

I attempted to use the phusion passenger package, but it would not properly run 
because it needs /usr/bin/ps for somer reason.  No problem, I will just install 
it. When I searched for the package containing it on packages.debian.org, the 
search returns no results.  That is, there is no package that  contains 
/usr/hin/ps.  I expected it would be in coreutils, but it is not.  It seems to 
be present on a another recent Debian bullseye install I did, but, again, it is 
contained in any package.  It should be contained in a package in the 
base_system, but it is not.  How does it get there? What if there is a security 
issue identified with the program, would it be updated? Having a binary program 
installed on a system without it being contained in a package seems to 
contravene the Debian packaging policies.

Downstream distributions, such as Ubuntu are also affected.  I confirmed the 
/usr/bin/ps is not contained in any package for 22.04 LTS, although I have not 
filed a bug report.

You can reproduce the problem easily by either searching for  /usr/bin/ps on 
packages.debian.org  or

$ dpkg -S $(which ps)

On a system with /usr/bin/ps

Thanks,
Steve


> On Feb 15, 2023, at 10:36 AM, Debian Bug Tracking System 
>  wrote:
> 
> This is an automatic notification regarding your Bug report
> which was filed against the installation-reports package:
> 
> #1031354: installation-reports: I cannot find /usr/bin/ps in any package, but 
> it is normally installed with via an ISO install.
> 
> It has been closed by Paul Tagliamonte .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Paul Tagliamonte 
>  by
> replying to this email.
> 
> 
> -- 
> 1031354: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031354
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 
> From: Paul Tagliamonte 
> Subject: Re: Bug#1031354: installation-reports: I cannot find /usr/bin/ps in 
> any package, but it is normally installed with via an ISO install.
> Date: February 15, 2023 at 10:33:47 AM EST
> To: Cyril Brulebois 
> Cc: Steve Roggenkamp , 1031354-d...@bugs.debian.org, 
> tia...@debian.org, paul...@debian.org
> 
> 
> On Wed, Feb 15, 2023 at 04:30:25PM +0100, Cyril Brulebois wrote:
>>> Boot method: via a Docker build
>>> Image version: bullseye-slim current
>> 
>> Furthermore, I'm pretty sure Docker images are meant to be lightweight,
>> and you aren't normally supposed to log in and inspect processes inside
>> such images, so I can perfectly understand why people responsible for it
>> didn't include procps.
> 
> doubly so on the -slim variant. I think everything's working as
> intended. If you wish to use a Docker image as more than just that, I
> would suggest creating a Dockerfile adding packages you require and
> using your local image.
> 
> The docker images intentionally do not have everything from a full
> install. Including things like GRUB or Linux, since neither are
> required.
> 
>> Lowering severity and cc-ing accordingly.
> 
> Closing this report. Thank you for the heads up, and thanks for the
> report!
> 
> -- 
> :wq
> 
> 
> 
> From: Steve Roggenkamp 
> Subject: installation-reports: I cannot find /usr/bin/ps in any package, but 
> it is normally installed with via an ISO install.
> Date: February 15, 2023 at 10:03:30 AM EST
> To: Debian Bug Tracking System 
> 
> 
> Package: installation-reports
> Severity: serious
> Tags: d-i
> Justification: Policy 3.7, 10.1
> X-Debbugs-Cc: roggenka...@acm.org
> 
> (Please provide enough information to help the Debian
> maintainers evaluate the report efficiently - e.g., by filling
> in the sections below.)
> 
> Boot method: via a Docker build
> Image version: bullseye-slim current
> Date: 
> 
> Machine: Apple Macbook Pro Intel
> Partitions: 
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [ ]
> Detect network card:[ ]
> Configure network:  [ ]
> Detect media:   [ ]
> Load installer modules: [ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
>   and ideas you had during the initial install.>
> 
> 
> Please make sure that any installation logs that you think would
> be useful are attached to this report. Please compress large
> files using gzip.
> 
>

Bug#1031359: mjpegtools: New upstream release (2.2.1, 2021-09-05)

2023-02-15 Thread Florian Ernst

Source: mjpegtools
Version: 1:2.1.0+debian-7
Severity: wishlist

Dear maintainer,

there is a new upstream release available, cf.
,
containing "a lot of fixes and a lot of cleanup since the last (2.1.0)
release".

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1031358: rclone should suggest ca-certificates

2023-02-15 Thread Neil Wilson

Package: rclone
Version: 1.53.3-4ubuntu1
Severity: normal

Dear Maintainer,

rclone uses TLS to connect to remote repositories, but lacks a Suggests
on ca-certificates. This leads to "x509: certificate signed by unknown
authority" errors.

Adding it in would mirror the Suggests in the 'openssl' package etc.


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500,
'jammy'), (100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-60-generic (SMP w/3 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rclone depends on:
ii  libc6  2.35-0ubuntu3.1

rclone recommends no packages.

rclone suggests no packages.

-- no debconf information

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

2023-02-15 Thread 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#1031357: firefox 109 is obsolete/insecure, firefox 110 needs rustc >= 1.65, not in unstable

2023-02-15 Thread Vincent Lefevre

Package: firefox
Version: 109.0-1
Severity: serious

Several vulnerabilities have been fixed in Firefox 110:
  https://www.mozilla.org/en-US/security/advisories/mfsa2023-05/

So Firefox should be updated to this version. However, it now
build-depends on rustc >= 1.65, which will not be in unstable
during the freeze, thus not before several months.

There should either be an alternate way to get Firefox 110 in
unstable (e.g. include rust for the Firefox build or ask for a
rustc-unstable package[*]?), or it should (permanently?) move
to experimental.

[*] which will never go to testing, just like the firefox package.

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.6-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.5-1
ii  libgtk-3-0   3.24.36-3
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.3-3
ii  libx11-xcb1  2:1.8.3-3
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.2-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec59  7:5.1.2-2

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20.1-1
ii  pulseaudio 16.1+dfsg1-2+b1

-- no debconf information

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

Bug#1031356: pinctrl: linux-image-6.1.0-3-amd64 : kernel NULL pointer dereference with intel pinctrl driver

2023-02-15 Thread Frederic Buisson

Package: src:linux
Version: 6.1.8-1
Severity: important
File: pinctrl
X-Debbugs-Cc: frederic.buis...@f-g.fr

Dear Maintainer,

The problem appears at boot time  :

[1.582787] BUG: kernel NULL pointer dereference, address: 
[1.582816] #PF: supervisor read access in kernel mode
[1.582831] #PF: error_code(0x) - not-present page
[1.582845] PGD 0 P4D 0 
[1.582856] Oops:  [#1] PREEMPT SMP NOPTI
[1.582870] CPU: 0 PID: 142 Comm: systemd-udevd Not tainted 6.1.0-3-amd64 #1 
 Debian 6.1.8-1
[1.582893] Hardware name: To Be Filled By O.E.M. To Be Filled By 
O.E.M./IMB-1004, BIOS P1.10 04/19/2022
[1.582917] RIP: 0010:strcmp+0xc/0x30
[1.582934] Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 
c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14 
07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c0 c3
[1.582976] RSP: 0018:a7e9c037fc50 EFLAGS: 00010246
[1.582991] RAX:  RBX: c02f8c40 RCX: a7e9c037fc28
[1.583009] RDX:  RSI: c02f6c9f RDI: 
[1.583026] RBP:  R08: 925240c113d0 R09: a7e9c037fa00
[1.583043] R10:  R11:  R12: c02fa0e0
[1.583059] R13:  R14: 925242e64428 R15: 
[1.583076] FS:  7f961323e8c0() GS:9253c840() 
knlGS:
[1.583096] CS:  0010 DS:  ES:  CR0: 80050033
[1.583111] CR2:  CR3: 0001013a2000 CR4: 00350ef0
[1.583128] Call Trace:
[1.583139]  
[1.583147]  intel_pinctrl_get_soc_data+0x6b/0xc0
[1.583169]  intel_pinctrl_probe_by_uid+0xe/0x30
[1.583186]  platform_probe+0x41/0x90
[1.583201]  really_probe+0xdb/0x380
[1.583214]  ? pm_runtime_barrier+0x50/0x90
[1.583228]  __driver_probe_device+0x78/0x170
[1.583242]  driver_probe_device+0x1f/0x90
[1.583254]  __driver_attach+0xce/0x1c0
[1.583267]  ? __device_attach_driver+0x110/0x110
[1.583281]  bus_for_each_dev+0x84/0xd0
[1.583295]  bus_add_driver+0x1ae/0x200
[1.583747]  driver_register+0x89/0xe0
[1.584209]  ? 0xc02fd000
[1.584651]  do_one_initcall+0x56/0x220
[1.585070]  do_init_module+0x4a/0x200
[1.585478]  __do_sys_finit_module+0xac/0x120
[1.585882]  do_syscall_64+0x58/0xc0
[1.586287]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[1.586696] RIP: 0033:0x7f96139475a9
[1.587094] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 27 08 0d 00 f7 d8 64 89 01 48
[1.588359] RSP: 002b:7ffc2256b558 EFLAGS: 0246 ORIG_RAX: 
0139
[1.588783] RAX: ffda RBX: 56554ca8c6b0 RCX: 7f96139475a9
[1.589205] RDX:  RSI: 7f9613adaefd RDI: 0005
[1.589603] RBP: 7f9613adaefd R08:  R09: 56554ca705f0
[1.589996] R10: 0005 R11: 0246 R12: 0002
[1.590408] R13:  R14: 56554ca8f920 R15: 56554c70fe4f
[1.590824]  
[1.591209] Modules linked in: pinctrl_elkhartlake(+) button
[1.591610] CR2: 
[1.592004] ---[ end trace  ]---

-- Package-specific info:
** Version:
Linux version 6.1.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.8-1 (2023-01-29)

** Command line:
BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.1.0-3-amd64 
root=UUID=a84d7397-a9c1-4e8a-9270-beb97be1680a ro rootflags=subvol=@rootfs 
1920x1080 iomem=relaxed quiet i915.force_probe=* i915.enable_guc=3 
8250.nr_uarts=2

** Tainted: UDOE (12480)
 * taint requested by userspace application
 * kernel died recently, i.e. there was an OOPS or BUG
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends International, LLC.
bios_version: P1.10
board_vendor: ASRock
board_name: IMB-1004
board_version: 

** Loaded modules:
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
sunrpc
rfkill
qrtr
binfmt_misc
nls_ascii
nls_cp437
intel_rapl_msr
vfat
fat
mei_hdcp
intel_rapl_common
snd_sof_pci_intel_tgl
x86_pkg_temp_thermal
intel_powerclamp
snd_sof_intel_hda_common
coretemp
soundwire_intel
soundwire_generic_allocation
kvm_intel
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
kvm
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
irqbypass
snd_soc_hdac_hda
snd_hda_ext_core
snd_hda_codec_realtek
snd_soc_acpi_intel_match
snd_soc_acpi

Bug#1030753: rust-all: need for rust 1.66.1

2023-02-15 Thread Fabian Grünbichler

On Wed, Feb 15, 2023 at 02:28:51PM +0100, Vincent Lefevre wrote:
> On 2023-02-07 11:40:54 +0100, Fabian Grünbichler wrote:
> > rustc will be updated in experimental once 1.64 builds are done on all
> > release architectures. first to 1.65, then to 1.66.1, then to 1.67 and
> > so on.
> > 
> > bookworm will stay on 1.63 (besides any potential backports). note that
> > firefox has its own rust toolchain in Debian (old*)stable:
> > 
> > https://tracker.debian.org/pkg/rustc-mozilla
> > 
> > for future reference - there is no need to file bugs to get rustc
> > updated in unstable (or experimental, during freeze time) - the rust
> > team will always pull in updates, but given the fast release schedule
> > and the amount of architecture related issues each release requires to
> > sort out, combined with the fact that updates have to happen one major
> > version after another, we'll likely always lag behind a bit.
> 
> Any news? rustc >= 1.65 is now needed for Firefox 110, which includes
> security fixes. So this is a bit urgent. See:
> 
>   https://buildd.debian.org/status/package.php?p=firefox

rustc 1.64 is now built for all (relevant) archs in experimental, so
1.65.0 will follow suite some time this week. there are currently no
plans to upload it to unstable during freeze though.

Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an ISO install.

2023-02-15 Thread Cyril Brulebois

Control: tag -1 - d-i
Control: severity -1 normal

Hi,

Steve Roggenkamp  (2023-02-15):
> Package: installation-reports
> Severity: serious
> Tags: d-i
> Justification: Policy 3.7, 10.1
> X-Debbugs-Cc: roggenka...@acm.org
> 
> (Please provide enough information to help the Debian
> maintainers evaluate the report efficiently - e.g., by filling
> in the sections below.)
> 
> Boot method: via a Docker build
> Image version: bullseye-slim current

If you're using a Docker build, you're definitely not using the
installer, so removing the d-i flag.

Furthermore, I'm pretty sure Docker images are meant to be lightweight,
and you aren't normally supposed to log in and inspect processes inside
such images, so I can perfectly understand why people responsible for it
didn't include procps.

Lowering severity and cc-ing accordingly.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1031355: setxattr does not set owner to root when file is unknown

2023-02-15 Thread Sebastian von Ohr

Package: fakeroot
Version: 1.30.1-1.1

The default behavior for fakeroot is to show unknown files owned by root. When 
setting extended attributes on a file the owner stored by fakeroot is the real 
owner. The behavior can be observed when running the following commands inside 
fakeroot:

touch testfile
ls -l # shows owner as root
attr -s test -V x testfile
ls -l # shows real owner

I've looked at the code and there is some logic to set the owner to root if the 
uid/gid from the buffer is -1. I don't see where this value is ever sent by the 
client. Instead, I propose to always set the owner to root, just like in 
process_chmod. See attached patch.


setxattr_unknown_is_root.patch
Description: setxattr_unknown_is_root.patch

Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an ISO install.

2023-02-15 Thread Steve Roggenkamp

Package: installation-reports
Severity: serious
Tags: d-i
Justification: Policy 3.7, 10.1
X-Debbugs-Cc: roggenka...@acm.org

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: via a Docker build
Image version: bullseye-slim current
Date: 

Machine: Apple Macbook Pro Intel
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.

Bug#1031353: ostree: test-rofiles-fuse is skipped

2023-02-15 Thread Graham Inggs

Source: ostree
Version: 2022.7-2

Hi Maintainer

While investigating an autopkgtest regression in Ubuntu [1], it was
discovered that test-rofiles-fuse runs in Ubuntu, but is skipped in
Debian [2].  I've copied what I hope is the relevant part of the log
below.

It should be possible to get this test to run if libcap2-bin is
installed, and /sbin is on the path (or tests/libtest.sh is patched:
capsh -> /sbin/capsh), and the autopkgtest user has cap_sys_admin
capabilities.  Due to differences in autopkgtest infrastructure, these
conditions are met in Ubuntu but not in Debian.

Regards
Graham


[1] https://bugs.launchpad.net/ubuntu/+source/ostree/+bug/2006483
[2] https://ci.debian.net/packages/o/ostree/testing/amd64/


Running test: libostree/test-rofiles-fuse.sh.test
Copying gpghome to /tmp/test-tmp-libostree_test-rofiles-fuse.sh.test-WOT4Z1
checking for xattrs.../usr/bin/setfattr
/tmp/test-tmp-libostree_test-rofiles-fuse.sh.test-WOT4Z1
/tmp/test-tmp-libostree_test-rofiles-fuse.sh.test-WOT4Z1
# testlabel.txt: security.selinux: No such attribute
Unable to retrieve SELinux label, assuming disabled
/tmp/test-tmp-libostree_test-rofiles-fuse.sh.test-WOT4Z1
done
checking for overlayfs whiteouts...done
/usr/libexec/installed-tests/libostree/libtest.sh: line 688: capsh:
command not found
1..0 # SKIP No cap_sys_admin in bounding set, can't use FUSE

Bug#1031352: Chromium on Wayland: Cannot join a Microsoft Teams enterprise meeting

2023-02-15 Thread Amr Ibrahim

Package: chromium
Version: 109.0.5414.119-1
Severity: normal

Dear Maintainer,

Running Chromium on Wayland: I cannot join a Microsoft Teams enterprise
meeting.

An enterprise meeting is a meeting (external from my organisation), which I am
not automatically authorised to enter until someone who is already inside the
meeting accepts my request to enter the meeting.

Once someone accepts my request to enter the meeting, I get thrown out of the
meeting and have to try again without success.

Please let me know if more info is required.

Best,
Amr


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages chromium depends on:
ii  chromium-common109.0.5414.119-1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.36-8
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-1+b2
ii  libdbus-1-31.14.6-1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1
ii  libevent-2.1-7 2.1.12-stable-5+b1
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-4
ii  libgbm122.3.3-1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.5-1
ii  libgtk-3-0 3.24.36-3
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-1+b1
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87-1
ii  libopenjp2-7   2.5.0-1+b1
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libre2-9   20220601+dfsg-1+b1
ii  libsnappy1v5   1.1.9-2
ii  libstdc++6 12.2.0-14
ii  libwebp7   1.2.4-0.1
ii  libwebpdemux2  1.2.4-0.1
ii  libwebpmux31.2.4-0.1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.3-3
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.1+b3
ii  libxnvctrl0520.56.06-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-backend]  43.1-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.14.1-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  109.0.5414.119-1

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n109.0.5414.119-1
pn  chromium-shell   

Versions of packages

Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability

2023-02-15 Thread Hilmar Preuße


Am 29.01.2023 um 00:00 teilte Frank Heckenbach mit:

Hello Frank,


Package: texlive-pictures
Version: 2020.20210202-3
Severity: grave
File: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu

Classic /tmp write vulnerability: function dir_writable writes to
"/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient
checks.

Harmless demonstration:



Siep Kroonenberg released a new version of that epspdf.tlu. I've put a
new package of texlive-pictures here [1]. Let me know if that solves the
issue for you. I'd like to upload the new package ASAP.

Hilmar

[1] https://freeshell.de/~hille42/TL_2023-2/
--
sigfault

Bug#1025350: qt6ct: Font changes are not saved in configuration file

2023-02-15 Thread Peter B


Hi,

I can reproduce the problem now.
Font changes are not stored in the configuration file when qt6ct exits.

A workaround would be to edit this file manually.
config/qt6ct/qt6ct.conf

I don't think this is anything to do with the Debian packaging, as the problem 
occurs
in Arch Linux too. I'll raise it upstream.

==


On 15/02/2023 00:22, Christopher Cramer wrote:


qt5ct does not work either.



Working fine here, I suggest you raise that as a separate bug.


Cheers,
Peter

Bug#1031347: Additional Information #2

2023-02-15 Thread MoonExiler

 Sorry for frequent disturbing.

I realize that iptables package has iptables-nft and nftlibs to work
normally, and nftables is a dependency recommended to install with
iptables. So my problem is solved, in my case, I need to install *iptables
package* and use *iptables-nft* from this package.

This bug is not actually related with *nftables package*. I want to say
sorry again. I want to express my sincere appreciation for your hard work.

Zhian Chen (galiren)

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

2023-02-15 Thread Jérémy Lal

Le mer. 15 févr. 2023 à 14:39, Thorsten Glaser  a écrit :

> Hi James,
>
> (you might wish to Cc <${bugnumber}-submit...@bugs.debian.org> so they
> actually get the reply…)
>
> >Are you able to determine whether
> https://github.com/nodejs/node/issues/41163
> >(and/or any of the guidance within that thread) seems relevant to this
> bug?
>
> It appears so. I commented there, thank you for finding that link.
>
> I guess there is even a… quick patch… to make from this. I admit
> I’m very confused by that statement:
>
> “if you set it too high, you risk crashes”
>
> That can’t be right.
>
> Searching through the nodejs source for where this stack size is
> set, I see multiple time bombs for all architectures.
>
> deps/v8/src/common/globals.h does set the default stack size to
> 864/984 KiB in order to achieve an about 1 MiB stack for JS plus
> C++ parts combined.
>
> I wonder if this shouldn’t be getrlimit(RLIMIT_STACK) - overhead,
> and then define the per-architecture overhead in a suitable way.
>
> That lower 1 MiB total limit seems to be for Windows. The lower
> arm64 limit is caused by “allocating MacroAssembler takes 120 [KiB]”
> but the total could still be raised I think… at least on unixoid
> platforms other than WebView-on-Android. Since the location of these
> defaults is in v8, it also applies for browsers and whatnot, but
> nodejs could indeed inspect the current ulimit and set a better
> default for at least nōn-Windows systems.
>
> I’m not, unfortunately, in the position to provide a quick patch,
> being a C developer, not CFrustFrust, and all that. I think that
> InitializeNodeWithArgs in src/node.cc, which already has a call
> to V8::SetFlagsFromString(NODE_V8_OPTIONS, …), is the likely place
> for adding code (suitably platform-ifdef’d) that does:
>
> - get the ulimit
> - subtract some arch-specific overhead target
> - check that that’s positive (or >= V8_DEFAULT_STACK_SIZE_KB even,
>   that might be a good idea)
> - if so, pass this as synthetic --stack-size (or --stack_size?) to
>   v8, overriding its default but allowing for a later option given
>   by the user’s argv[] to override _that_, again
>
> Might need to adjust some tests, too :~


While waiting for the proper fix you describe, I propose to set higher
constants
for V8_DEFAULT_STACK_SIZE_KB - especially for arm64.

Jérémy

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

2023-02-15 Thread Thorsten Glaser

Hi James,

(you might wish to Cc <${bugnumber}-submit...@bugs.debian.org> so they
actually get the reply…)

>Are you able to determine whether https://github.com/nodejs/node/issues/41163
>(and/or any of the guidance within that thread) seems relevant to this bug?

It appears so. I commented there, thank you for finding that link.

I guess there is even a… quick patch… to make from this. I admit
I’m very confused by that statement:

“if you set it too high, you risk crashes”

That can’t be right.

Searching through the nodejs source for where this stack size is
set, I see multiple time bombs for all architectures.

deps/v8/src/common/globals.h does set the default stack size to
864/984 KiB in order to achieve an about 1 MiB stack for JS plus
C++ parts combined.

I wonder if this shouldn’t be getrlimit(RLIMIT_STACK) - overhead,
and then define the per-architecture overhead in a suitable way.

That lower 1 MiB total limit seems to be for Windows. The lower
arm64 limit is caused by “allocating MacroAssembler takes 120 [KiB]”
but the total could still be raised I think… at least on unixoid
platforms other than WebView-on-Android. Since the location of these
defaults is in v8, it also applies for browsers and whatnot, but
nodejs could indeed inspect the current ulimit and set a better
default for at least nōn-Windows systems.

I’m not, unfortunately, in the position to provide a quick patch,
being a C developer, not CFrustFrust, and all that. I think that
InitializeNodeWithArgs in src/node.cc, which already has a call
to V8::SetFlagsFromString(NODE_V8_OPTIONS, …), is the likely place
for adding code (suitably platform-ifdef’d) that does:

- get the ulimit
- subtract some arch-specific overhead target
- check that that’s positive (or >= V8_DEFAULT_STACK_SIZE_KB even,
  that might be a good idea)
- if so, pass this as synthetic --stack-size (or --stack_size?) to
  v8, overriding its default but allowing for a later option given
  by the user’s argv[] to override _that_, again

Might need to adjust some tests, too :~


Good luck,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

On Wed, Feb 15, 2023 at 9:23 PM Adrian Bunk  wrote:
> > And regarding make golang-go the first alternative, currently we have:
> > + Build-Depends golang-any | golang-go | gccgo
> > + golang-any Depends golang-go | gccgo-go
> > Is there anything we can improve for aspcud resolver?
>
> The resolver is not to blame for a bug in the build dependencies.
>
> In unstable and experimental only the first alternative is considered,
> therefore
>   Build-Depends: golang-go | ...
> would instruct the resolver to install golang-go.
>
> Safest would be to not offer any alternatives in the build dependencies,
> instead create a profile for bootstrapping golang-go from gccgo.

I now created #1031351, which I think is the underlying problem.
Let's keep discussion there and reduce the noise in this unblock request.

-- 
Shengjing Zhu

Bug#1030753: rust-all: need for rust 1.66.1

2023-02-15 Thread Vincent Lefevre

On 2023-02-07 11:40:54 +0100, Fabian Grünbichler wrote:
> rustc will be updated in experimental once 1.64 builds are done on all
> release architectures. first to 1.65, then to 1.66.1, then to 1.67 and
> so on.
> 
> bookworm will stay on 1.63 (besides any potential backports). note that
> firefox has its own rust toolchain in Debian (old*)stable:
> 
> https://tracker.debian.org/pkg/rustc-mozilla
> 
> for future reference - there is no need to file bugs to get rustc
> updated in unstable (or experimental, during freeze time) - the rust
> team will always pull in updates, but given the fast release schedule
> and the amount of architecture related issues each release requires to
> sort out, combined with the fact that updates have to happen one major
> version after another, we'll likely always lag behind a bit.

Any news? rustc >= 1.65 is now needed for Firefox 110, which includes
security fixes. So this is a bit urgent. See:

  https://buildd.debian.org/status/package.php?p=firefox

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

Bug#1031345: kicad: Please update

2023-02-15 Thread Carsten Schoenert


Control: severity -1 wishlist

Hello Matthias,

Am 15.02.23 um 13:25 schrieb Matthias Urlichs:


KiCAD 7 is out. Please update; it really should be in Bookworm.
unfortunately this will not happen, it's simply to late get KiCad 7.0.0 
into the next stable release.
We will work on providing backported packages as usual once the bookworm 
release is out.


--
Regards
Carsten

Bug#1031351: Make golang-any have determinate Depends

Package: golang-any
Severity: normal
X-Debbugs-Cc: z...@debian.org

While reply https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031330#22
I realize we have similar problem when building Go programs in experimental
and backports. The aspcud resolver for unknown reason that prefers gccgo-go
on arch where golang-go is available. That causes unexpected build failures,
especially annoying for backports.

While it's good to keep packages buildable with gccgo, the reality is only
golang-go is tested on sid. So we can't know the build failures in advance.

So we should remove the alternative Depends in golang-any, to have a determinate
result.

I think we previously use "golang-go | gccgo-go" because it's easies to
write debian/control file. Can we have different Depends for different arch?
Can we reduce the duplication of arch list with golang-go?

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

2023-02-15 Thread Adrian Bunk

On Wed, Feb 15, 2023 at 09:05:28PM +0800, Shengjing Zhu wrote:
> On Wed, Feb 15, 2023 at 8:53 PM Shengjing Zhu  wrote:
> >
> > On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> > >
> > > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > > >...
> > > > The package currently FTBFS on i386/experimental but it won't be 
> > > > problem on
> > > > unstable.
> > > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > > which has a bug https://github.com/golang/go/issues/51850.
> > > > But on unstable the dep-resolver is apt, and will choose old golang-go 
> > > > to
> > > > bootstrap.
> > > >...
> > >
> > > I gave it back on the affected architectures with an extra-depends on
> > > golang-go, which confirmed that the package builds there.
> > >
> > > But relying on resolver behaviour is incredibly fragile, please make
> > > golang-go the only (or at least the first) alternative in the build
> > > dependencies.
> >
> > In theory gccgo should be able to bootstrap golang-go.
> > And we do use gccgo to build golang-go on ppc64, and haven't met any
> > problem so far.
> > The new affected arch is because of lack of exercise, so nobody is
> > aware of this.
> > Now they are tracked at #1031349.
> >
> 
> And regarding make golang-go the first alternative, currently we have:
> + Build-Depends golang-any | golang-go | gccgo
> + golang-any Depends golang-go | gccgo-go
> Is there anything we can improve for aspcud resolver?

The resolver is not to blame for a bug in the build dependencies.

In unstable and experimental only the first alternative is considered,
therefore
  Build-Depends: golang-go | ...
would instruct the resolver to install golang-go.

Safest would be to not offer any alternatives in the build dependencies,
instead create a profile for bootstrapping golang-go from gccgo.

> Shengjing Zhu

cu
Adrian

Bug#1031329: Please disregard this bug report

2023-02-15 Thread Hugh McMaster

Hi Michael,

Thank you for the bug report and for confirming the issue is caused by a
recent change in the Microsoft repository.

On Wed, 15 Feb 2023 at 14:51, Michael Shipper wrote:

> It looks like the bug is in the Microsoft odbc package not the Debian odbc
> package.
>
> Please close this ticket.
>
Microsoft is tracking the issue on Github. [1]

I’ll leave this bug open until the issue is resolved, just in case other
users come across the same problem.

> [1] https://github.com/microsoft/linux-package-repositories/issues/36

Bug#1031236: ifupdown: dns-nameservers with systemd-resolved is broken

2023-02-15 Thread Santiago Ruano Rincón

Control: tags -1 + patch
Control: severity -1 important

El 13/02/23 a las 20:38, Dmytro Kolesnykov escribió:
> Package: ifupdown
> Version: 0.8.41
> Severity: normal
> 
> Dear Maintainer,

Dear ifupdown user,

> 
> I was doing my network setup, which included statically configured
> logical interfaces. So there were dns-nameservers entries in my
> /etc/network/interfaces. My configuration files is below (the actual
> IPs and MACs is wiped).
> 
> I noted that ifup with my setup is producing error messages like this:
> 
> ...
> guessnet: Started tests
> guessnet: 3 candidates
> guessnet: Got ARP reply from 192.168.0.1 XX:XX:XX:XX:XX:XX
> guessnet: ARP reply from 192.168.0.1 XX:XX:XX:XX:XX:XX matches
> guessnet: Notified success of scan peer 192.168.0.1 XX:XX:XX:XX:XX:XX
> guessnet: Removing candidate enp4s0-direct
> guessnet: Keeping candidate enp4s0-router
> guessnet: We had changes, notifying the listener
> guessnet: Got ARP reply from 192.168.0.1 XX:XX:XX:XX:XX:XX
> /etc/network/if-up.d/resolved: 69: DNS: not found
> /etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-enp4s0: 
> DNS=192.168.0.1 192.168.0.12: not found
> Failed to parse DNS server address: DNS
> Failed to set DNS configuration: Invalid argument
> 
> I have found discussion about similar problem there:
> https://unix.stackexchange.com/questions/714901/dns-broken-when-using-ifupdown-and-systemd-resolved-after-upgrade-to-ubuntu-22-0
> 
> Also I had a look into the /etc/network/if-up.d/resolved and I assume
> this is a typo in the line 69:
> https://salsa.debian.org/debian/ifupdown/-/blob/master/debian/if-up.d/resolved#L69
> 

[...]

Thanks for reporting this issue, and for proposing the patch.

Have you had the chance to test an IPv6 configuration?
I'll need to change my setup for testing that. And I'd love add tests to
check this.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

2023-02-15 Thread Adrian Bunk

On Wed, Feb 15, 2023 at 08:53:13PM +0800, Shengjing Zhu wrote:
> On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> >
> > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > >...
> > > The package currently FTBFS on i386/experimental but it won't be problem 
> > > on
> > > unstable.
> > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > which has a bug https://github.com/golang/go/issues/51850.
> > > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > > bootstrap.
> > >...
> >
> > I gave it back on the affected architectures with an extra-depends on
> > golang-go, which confirmed that the package builds there.
> >
> > But relying on resolver behaviour is incredibly fragile, please make
> > golang-go the only (or at least the first) alternative in the build
> > dependencies.
> 
> In theory gccgo should be able to bootstrap golang-go.
>...

That misses my point, which is that when there are several options
the package should define and ensure which one is used.

Every buildd and every QA build and every build elsewhere should use the 
same tools for building the package.

Otherwise people might end up wasting hours and days trying to 
understand why a package that built in unstable failed to build
somewhere else (in experimental or reproducible builds or in
a derivative distribution or elsewhere).

Or even worse, if for some reason the package builds but produces 
different binaries and then someone tries to debug why this happened.
That shouldn't happen, but these are absolutely nasty and time-consuming
bugs.

> Shengjing Zhu

cu
Adrian

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

On Wed, Feb 15, 2023 at 8:53 PM Shengjing Zhu  wrote:
>
> On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> >
> > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > >...
> > > The package currently FTBFS on i386/experimental but it won't be problem 
> > > on
> > > unstable.
> > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > which has a bug https://github.com/golang/go/issues/51850.
> > > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > > bootstrap.
> > >...
> >
> > I gave it back on the affected architectures with an extra-depends on
> > golang-go, which confirmed that the package builds there.
> >
> > But relying on resolver behaviour is incredibly fragile, please make
> > golang-go the only (or at least the first) alternative in the build
> > dependencies.
>
> In theory gccgo should be able to bootstrap golang-go.
> And we do use gccgo to build golang-go on ppc64, and haven't met any
> problem so far.
> The new affected arch is because of lack of exercise, so nobody is
> aware of this.
> Now they are tracked at #1031349.
>

And regarding make golang-go the first alternative, currently we have:
+ Build-Depends golang-any | golang-go | gccgo
+ golang-any Depends golang-go | gccgo-go
Is there anything we can improve for aspcud resolver?

-- 
Shengjing Zhu

Bug#1031347: Additional Information

2023-02-15 Thread MoonExiler

the exact iptables command is in format  `iptables -w 2 -t nat -N TP_OUT
sh`, and seems nftables has different command form. I installed iptables
and everything works well, but I still wonder what's `iptables` package
status now as it is announced be replaced by nftables. For now I think it's
the proxy software's duty to solve this problem.

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
>
> On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> >...
> > The package currently FTBFS on i386/experimental but it won't be problem on
> > unstable.
> > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > which has a bug https://github.com/golang/go/issues/51850.
> > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > bootstrap.
> >...
>
> I gave it back on the affected architectures with an extra-depends on
> golang-go, which confirmed that the package builds there.
>
> But relying on resolver behaviour is incredibly fragile, please make
> golang-go the only (or at least the first) alternative in the build
> dependencies.

In theory gccgo should be able to bootstrap golang-go.
And we do use gccgo to build golang-go on ppc64, and haven't met any
problem so far.
The new affected arch is because of lack of exercise, so nobody is
aware of this.
Now they are tracked at #1031349.

--
Shengjing Zhu

Bug#1016631: libgstreamer-plugins-base1.0-dev cannot be marked Multi-Arch: same

2023-02-15 Thread Simon McVittie

On Sun, 29 Jan 2023 at 18:59:11 +0100, Helmut Grohne wrote:
> There are multiple reports asking libgstreamer-plugins-base1.0-dev to be
> marked Multi-Arch: same. Unfortunately, doing so would make the package
> rc-buggy, because it would cause unpack errors from dpkg on
> /usr/share/gir-1.0/GstAudio-1.0.gir when coinstalling with s390x.

Because nobody has actually said this in as many words yet:

The reason why GstAudio-1.0.gir is not multi-arch co-installable is that
it includes constants like GST_AUDIO_FORMAT_S16 which is defined to be
an alias for either GST_AUDIO_FORMAT_S16LE or GST_AUDIO_FORMAT_S16BE,
whichever is the native endianness. It is not possible for g-ir-scanner
to produce identical GIR XML for this module on little-endian and
big-endian machines, because the correct contents are genuinely different,
and GIR XML does not have any mechanism for architecture conditionals.

The two equivalence classes here are big- and little-endian architectures
(unlike GLib-2.0.gir in #801672, which has considerably more equivalence
classes as a result of describing a lower-level library).

We don't currently have a way to declare that a file varies between LE and
BE architectures, but is co-installable across all LE architectures.

smcv

Bug#1031350: ITP: libkysdk-system -- Kylin System Layer Developer Kit

Package: wnpp
Severity: wishlist
Owner: KevinDuan 
X-Debbugs-Cc: debian-de...@lists.debian.org, duankai...@ubuntukylin.com


* Package name: libkysdk-system
  Version : 1.0.1-1
  Upstream Author : KevinDuan 
* URL : https://gitee.com/openkylin/libkysdk-system
* License : LGPL-3+, GPL-2+, BSL-1.0, BSD-3-clause, BSD-2-clause,
Apache-2.0
  Programming Lang: C++
  Description : Kylin System Layer Developer Kit

 libkysdk-system is system layer kit that provides API and services such as
system information, disk information and system time, etc.
 .
 This package is metapackage.It provides the kysdk shared basic libraries.

Bug#1031349: gccgo fails to bootstrap golang-go on armel/armhf/i386/mips64el/mipsel

Source: golang-1.19
Severity: wishlist
X-Debbugs-Cc: z...@debian.org


https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=armel=1.19.6-1=1676430951=0
https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=armhf=1.19.6-1=1676431493=0
https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=i386=1.19.6-1=1676430343=0
https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=mips64el=1.19.6-1=1676447813=0
https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=mipsel=1.19.6-1=1676447922=0

Bug#1031348: ITP: libkysdk-system -- Kylin System Layer Developer Kit