Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Salvatore Bonaccorso]

Hi Simon,

On Sun, Sep 17, 2023 at 09:24:19PM +0100, Simon McVittie wrote:
> On Sun, 17 Sep 2023 at 20:57:36 +0200, Salvatore Bonaccorso wrote:
> > On Sun, Sep 17, 2023 at 07:09:45PM +0100, Simon McVittie wrote:
> > > As far as I can tell, oldstable is not affected by this, because it
> > > doesn't appear to have the new screenshot UI in js/ui/screenshot.js that
> > > has the vulnerability.
> > 
> > Do you think it's safe to say that the issue is introduced around the
> > commits which introduce in the screenshot-ui the screenshot/screencast
> > toggles, e.g. 497d9f32eb02 ("screenshot-ui: Add screenshot/screencast
> > toggle") and eb60fa290882 ("screenshot-ui: Bind button to shot/cast")
> > which are in 42.beta upstream?
> 
> Perhaps a little earlier than that, but I can't see how versions earlier
> than 8ebc478f "Add scaffolding for the new screenshot UI" could be
> vulnerable, and that commit was also first released in 42.beta.

Thank you, I have updated the security-tracker accordingly. 

Moritz is taking care of releasing the DSA.

Regards,
Salvatore

Bug#1052139: dead upstream, popcon <10

[Johannes Schauer Marin Rodrigues]

Source: morty
Severity: serious

Hi,

last upstream commit was in April 2021. This package was mainly useful
together with searx (from the same developer) but that project got
abandoned in favour of searxng by different people which does not need
morty anymore. Additionally, morty has a very low popcon.

Lets make sure that this package does not make it into the next stable
release by accident.

Thanks!

cheers, josch

Bug#1052133: apt: E: Removing essential system-critical packages is not permitted. This might break the system.

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Thorsten Glaser (2023-09-17 23:03:50)
> E: Removing essential system-critical packages is not permitted. This might 
> break the system.
> 
> Used to be that it asks for “Yes, do as I say!”, and this is missing
> in sid now‽ I kinda need that…

it's documented in "man apt-get" if you search for "essential" you find:

> --allow-remove-essential
> Force yes; this is a dangerous option that will cause apt to continue 
> without
> prompting if it is removing essentials. It should not be used except in 
> very
> special situations. Using it can potentially destroy your system! 
> Configuration
> Item: APT::Get::allow-remove-essential. Introduced in APT 1.1.

It appears that there are people who will assume that when their computer tells
them to type “Yes, do as I say!” then that's just what they will do without
switching their brain on first: https://youtu.be/0506yDSgU7M?t=633

To prevent this from happening in the future, this was changed to become even
more difficult and now one has to read the manual and pass the option above
instead.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library

[Mouse Zhang]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ukui-kwin":

* Package name : ukui-kwin
   Version  : 5.27.5-1
   Upstream contact : plasma-de...@kde.org
* URL  : https://gitee.com/openkylin/ukui-kwin
* License  : LGPL-2+, GPL-2+, BSD-3-clause, GFDL-NIV-1.2+, 
LGPL-2.1+3+KDEeV, GPL-2+3+KDEeV, LGPL-2.1+3+KDEeV-translations
* Vcs  : https://gitee.com/openkylin/ukui-kwin
   Section  : kde

The source builds the following binary packages:

  ukui-kwin-common - UKUI window manager, common files
  ukui-kwin-data - UKUI window manager data files
  ukui-kwin-dev - UKUI window manager - devel files
  ukui-kwin-wayland - UKUI window manager, wayland version, PREVIEW release
  ukui-kwin-x11 - UKUI window manager, X11 version
  libukui-kwineffects14 - UKUI window manager effects library
  libukui-kwinglutils14 - UKUI window manager gl utils library

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

  https://mentors.debian.net/package/ukui-kwin/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/ukui-kwin/ukui-kwin_5.27.5-1.dsc

Changes for the initial release:

ukui-kwin (5.27.5-1) unstable; urgency=medium
.
   * Initial release. (Closes: #1050847)

Regards,

Bug#1051979: Do not suggest APT::Default-Release setting

[Max Nikulin]

On 16/09/2023 15:37, Osamu Aoki wrote:

So my first thought was replace it with:

- Release definition in "/etc/apt/apt.conf" configuration file started with
"APT::Default-Release"

But As I read complicationa it causes from your messages, let's drop it.  I
don't use it anyway.


Since the "APT::Default-Release" option is present in the document for 
years, I would prefer to see a warning close to the current place where 
it is mentioned. Consider somebody is asked about this setting and their 
opens the reference to provide a link. Completely disappeared mention 
may make them thinking that it was seen in another document.


I do not insist however. I admit that removing obsolete material 
completely is widely used practice, so I am OK with your plan to just 
drop it.


From my point of view, it is worst variant when "APT::Default-Release" 
is described without the not so trivial regexp or without a warning 
concerning complications. This feature evolved into a kind of pitfall.


Thank you for your work on debian-reference.

Bug#1052125: nala cannot install the debreate package

[Blake Lee]

I was able to reproduce this on my system. First this is the error that happens 
when installing. This is what crashes Nala because of the formatter.

```
Traceback (most recent call last): 
 File "/usr/bin/debreate", line 230, in  
   main() 
 File "/usr/bin/debreate", line 27, in main 
   import globals.paths 
 File "/usr/share/debreate/globals/paths.py", line 16, in  
   import libdbr.paths 
 File "/usr/share/debreate/lib/libdbr/paths.py", line 18, in  
   from . import sysinfo 
 File "/usr/share/debreate/lib/libdbr/sysinfo.py", line 37, in  
   if not __os_name: 
  ^ 
NameError: name '__os_name' is not defined
```

This portion happens with apt as well, although apt doesn't crash. If you use 
--raw-dpkg switch with Nala it will complete. I have already fixed this crash 
upstream but haven't released yet.

I would say you should likely report this to the debreate devs, even getting 
the install to complete with apt, the same error is thrown when I try to run 
the program.

Bug#1052137: run-mailcap.1: some remarks and editorial changes for this man page

[Bjarni Ingi Gislason]

Package: mailcap
Version: 3.70+nmu1
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint run-mailcap.1":

mandoc: run-mailcap.1:7:83: STYLE: input text line longer than 80 bytes: 
run-mailcap, view, s...
mandoc: run-mailcap.1:25:2: WARNING: skipping paragraph macro: PP after SH
mandoc: run-mailcap.1:83:81: STYLE: input text line longer than 80 bytes: A 
temporary symbolic...

-.-.

Use the correct macro for the font change of a single argument or
split the argument into two.

64:.IR cat
74:.BI \-\-debug
77:.BI \-\-nopager
80:.BI \-\-norun

-.-.

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

46:(.Z).  A filename of "-" can be used to mean "standard input", but

-.-.

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.

run-mailcap.1: line 7   length 83
run-mailcap, view, see, edit, compose, print \- execute programs via entries in 
the

run-mailcap.1: line 83  length 81
A temporary symbolic link to the file is opened if the file name matches the 
Perl

-.-.

Translate the character "~" (tilde) to "\(ti" to make it more visible
in the output of "troff".

51: Both the user's files (~/.mailcap; ~/.mime.types) and the system files

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

Kernel: Linux 6.4.13-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mailcap depends on:
ii  media-types  10.1.0
ii  perl 5.36.0-7

Versions of packages mailcap recommends:
ii  bzip2 1.0.8-5+b1
ii  file  1:5.45-2
ii  xz-utils  5.4.4-0.1

mailcap suggests no packages.

-- no debconf information
The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint run-mailcap.1":

mandoc: run-mailcap.1:7:83: STYLE: input text line longer than 80 bytes: 
run-mailcap, view, s...
mandoc: run-mailcap.1:25:2: WARNING: skipping paragraph macro: PP after SH
mandoc: run-mailcap.1:83:81: STYLE: input text line longer than 80 bytes: A 
temporary symbolic...

-.-.

Use the correct macro for the font change of a single argument or
split the argument into two.

64:.IR cat
74:.BI \-\-debug
77:.BI \-\-nopager
80:.BI \-\-norun

-.-.

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

46:(.Z).  A filename of "-" can be used to mean "standard input", but

-.-.

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.

run-mailcap.1: line 7   length 83
run-mailcap, view, see, edit, compose, print \- execute programs via entries in 
the

run-mailcap.1: line 83  length 81
A temporary symbolic link to the file is opened if the file name matches the 
Perl

-.-.

Translate the character "~" (tilde) to "\(ti" to make it more visible
in the output of "troff".

51: Both the user's files (~/.mailcap; ~/.mime.types) and the system files

Bug#1051563: Backporting mutt patches to Debian Buster

[Chris Frey]

On Sun, Sep 17, 2023 at 08:34:57PM +0300, Santiago Ruano Rincón wrote:
> Chris, thanks for preparing the patches. Much appreciated. I have a
> question though: Why are you placing those two patches in
> debian-specific, and not in upstream/? They come from the upstream repo.

I only put them there because I had to modify them for a clean patch.
I changed the headers to make it clear that I edited them, but kept
the original wording as well.

I didn't think it was right to modify the patch contents without
changing the name of who did it.

- Chris

Bug#1052136: libcdb1: tries to overwrite /usr/share/man/man5/cdb.5.gz in tinycdb 0.78+b1

[Vincent Lefevre]

Package: libcdb1
Version: 0.80-1
Severity: serious

When upgrading, I got:

Unpacking libcdb1:amd64 (0.80-1) over (0.78+b1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-DmVfNl/25-libcdb1_0.80-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man5/cdb.5.gz', which is also in package 
tinycdb 0.78+b1

Missing Breaks+Replaces?

-- System Information:
Debian Release: trixie/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.5.0-1-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 libcdb1 depends on:
ii  libc6  2.37-10

libcdb1 recommends no packages.

libcdb1 suggests no packages.

-- no debconf information

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

Bug#749646: x11-xserver-utils depends on cpp

[Dmitry Katsubo]

Dear community,

Would be great to improve the dependency. What about marking cpp as optional 
package for x11-xserver-utils? Or maybe there could be another additional 
package x11-xserver-utils-nocpp which does not
depend on cpp ?

-- 
With best regards,
Dmitry

Bug#1043549: Valid also for my bluetooth ID 05ac:821a on my 3 x MBP 9,1 mid 2012

[José Silva]

Hello,

I also have 3 Macbook Pro 9,1 mid 2012 but my bluetooth ID is 05ac:821a 
instead od 821d, can't explain why.


I too felt that BT was working with kernels 5.10 and 6.1 but doesn't 
work with 6.4.


So I replicated the proceeding reported here and it started working, 
just as in the report.

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

[Russ Allbery]

Niels Thykier  writes:

> I had a look at the introduction section of Policy to check who the
> target audience is.  I cannot find an explicit mention of the target
> audience. I suspect there is a conflict here on the content because we
> have different audiences in mind for the Policy and the Policy does not
> seem to be explicit here.

> If the target audience is package maintainers, then 100% of all debian
> contributors should read it. Then we need "simple and easy to
> understand" language and examples, because we want *everybody* to
> understand this.  I agree with Russ that long winded sections of "here
> is how you do this manually but really just use debhelper" is directly
> counter productive to this audience.

> If it is cross-package integration, are we targeting the ones
> integrating or the ones providing the integration points?  If it is
> both, then for more complex topics, it would make sense to split the
> topic into two. One for consumer and one for the provider of the
> integration, because for the consumer it will probably boil down to
> "install path at $X in your deb and run tool $Y" and then the consumer
> can skip the provider section as "not relevant".

> If the target audience is tool-chain maintainers, then only 5-10 people
> need to read the policy and the entire document + related process seems
> completely over-engineered.  But then, for the same reason, I suspect
> this is an unlikely target audience for the Policy.

Ooo, this is a great framing of the problem.  I have a lot of thoughts
about this.  Unfortunately, I'm not sure if they're actionable thoughts
since my grand vision requires someone to sit down and do some serious
Policy restructuring and produce a radically different document.  But
maybe if I write them all down and enough people feel similarly, it would
be worth doing.  I would love to work on this, I am just afraid that it is
the sort of project that I would start and never finish and thus never
accomplish anything of use.

I think that ideally Policy targets all three of your audiences, but not
at the same time, and not with the same priority.

I have a lot of problems with the current structure of Policy, to the
extent that it sometimes interferes with my motivation for working on it,
and one of the big ones is that it doesn't follow any structured design
pattern for documentation, such as Divio [1].  It may have at one point,
but iteratively over the years, and due to some decisions like trying to
retain section numbering, we've diverged from that.  Even if it were
trying to be only one type of documentation, it doesn't consistently stay
in that lane.

[1] https://documentation.divio.com/

I think my ideal structure of Policy would have three major parts.

First, there would be Policy for Debian packagers.  This would focus on
the things someone packaging for Debian needs to know, and would be
organized roughly around task.  Example sections here would be:

* Choosing an archive area
* Files on the file system (FHS, ownership, permissions, etc.)
* Writing a debian/control file
* Writing a changelog
* Writing a copyright file
* Packaging a shared library
* Packaging a system service
* Using maintainer scripts

In other words, this section would consist primarily of Divio how-to
guides, with some intermixed Divio explanations.  (Tutorials I think are
outside the scope of Policy and are better handled elsewhere, such as in
debhelper documentation.)

(This is very rough, this is not the right order, etc.  This is just to
provide a feel of the nature of this section.)

This section would assume that you're using a packaging helper and not
tell you how to do things that the packaging helper is going to do for
you.  There's an awkward line here between describing what to do and being
debhelper documentation, but the basic idea is that this would tell you
what you are aiming for, and then your packaging helper documentation will
tell you where to put configuration files to achieve that.

Second section would be Policy the reference manual for interfaces in the
distribution.  Sections here would be:

* Complete list of control fields and their meanings.
* Specifications for the .dsc and .changes files (which packagers mostly
  never need to care about, but tool maintainers do).
* The detailed reference documentation on all the ways maintainer scripts
  can be called.
* Specification for the symbols and shlibs files.

This is all Divio reference stuff.  Whenever we have a comprehensive
explanation of the details of something, it goes here, and then we
liberally link to the reference section from the packaging-focused how-to
section for more details.

Finally, there is the reference manual for toolchain maintainers.  My
position on this is that it's best-effort documentation and should
probably be a non-normative appendix where toolchain maintainers are
relatively free to just make changes without going through a very formal
process as long as those changes reflect 

Bug#1052135: ITP: check-build -- Check whether some example programs can be compiled and built

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team 
, r...@debian.org

* Package name: check-build
  Version : 0.1.0
  Upstream Contact: Peter Pentchev 
* URL : https://gitlab.com/ppentchev/check-build
* License : BSD-2-clause
  Programming Lang: Python
  Description : Check whether some example programs can be compiled and 
built

  The `check-build` tool can be used to build and test different
  programs in a temporary build directory. The programs are listed in
  a TOML configuration file, along with the commands to build and
  test them.

A bundled copy of the check-build library is used in the libzstd
autopkgtest to make sure that the C library's -dev package contains
enough files so that a program that uses the library can be built.
It will be removed in the next libzstd upload as soon as this package
hits the archive.

I will maintain this package as part of the Debian Python Team.


signature.asc
Description: PGP signature

Bug#1051251: /usr/sbin/grub-mkconfig: 300: /etc/grub.d/25_bli: not found due to wrong shell location

[gregor herrmann]

On Sun, 17 Sep 2023 13:14:04 +0200, Julian Andres Klode wrote:

> I admit that my choice of words was suboptimal, and I'd like to
> apologise for it.

Thank you!
 

gregor

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


signature.asc
Description: Digital Signature

Bug#1052134: error 400 when logging in via OAth2 in yandex mail.

[Nikolay Sabelnikov]

Package: thunderbird
Version: 1:102.15.1-1~deb12u1Package: thunderbird
Version: 1:102.15.1-1~deb12u1


  ПРЕДУПРЕЖДЕНИЕ:
  Это содержит секретную информацию, 
которую не следует пересылать или 
публиковать без получения на то разрешения.

  Сведения о приложении

Имя: Thunderbird
Версия: 102.15.1
ID сборки: 20230912052514
ID дистрибутива:
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 
Thunderbird/102.15.1
ОС: Linux 6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1 
(2023-09-07)
Тема ОС: Windows-10-Basic / Adwaita

Многопроцессные окна: 0/0
Окна Fission: 0/0
  Включены по умолчанию
Удалённые процессы: 1
Корпоративные политики: Неактивны
Ключ Службы определения местоположения 
от Google: Отсутствует
Ключ Google Safebrowsing: Отсутствует
Ключ Службы определения местоположения 
от Mozilla: Отсутствует
Безопасный Режим: false
Объём памяти (ОЗУ): 15,0 ГБ
Доступное место на накопителе: 371 ГБ

  Учётные записи почты и новостей

  Библиотеки

  Библиотека
  Состояние
  Ожидаемая минимальная версия
  Используемая версия
  Путь

  RNP (OpenPGP)
  OK
  0.16.3
  0.16.3-1
  librnp.so.0

  Настройки календаря

Мой календарь

  Имя
  Значение

  Имя: Мой календарь
  Тип: storage
  Отключён: true
  Имя пользователя:
  URI: moz-storage-calendar://
  Интервал обновления:
  Только для чтения:
  Подавление уведомлений:
  Кэш включён:
  Идентификатор iMIP:
  iMIP отключён:
  Учётная запись iMIP:
  Идентификатор организатора:
  Принудительное планирование 
электронной почты:
  Всплывающие уведомления 
поддерживаются:
  Уведомления по приглашению 
поддерживаются:
  Максимальное число уведомлений на 
событие:
  Вложения поддерживаются:
  Максимальное число категорий:
  Состояние приватности поддерживается:
  Приоритет поддерживается: true
  События поддерживаются:
  Задачи поддерживаются:
  Местное время поддерживается:
  UTC/GMT поддерживается:
  Автоматическое планирование 
поддерживается:

  Сообщения о падениях за последние 3 дня

  Удалённые процессы

Тип: Количество

Веб-содержимое: 1 / 8

  Дополнения

  Имя
  Тип
  Версия
  Включено
  ID

Википедия (ru)
extension
1.0
true
wikipe...@search.mozilla.org

DuckDuckGo
extension
1.0
true
d...@search.mozilla.org

Google
extension
1.0
true
goo...@search.mozilla.org

OZON.ru
extension
1.2
true
ozo...@search.mozilla.org

Price.ru
extension
1.0
true
pric...@search.mozilla.org

Russian (RU) Language Pack
locale
102.15.1buildid20230912.052514
true
langpack...@thunderbird.mozilla.org

  Программы обеспечения безопасности

Тип: Наименование

  Антивирус:
  Антишпион:
  Межсетевой экран:

  Графика

  Возможности
  Композитинг: WebRender
  Асинхронное панорамирование/зум: 
включён ввод колесиком; перетаскивание 
полосы прокрутки включено; клавиатура 
включена; автопрокрутка включена; плавное 
масштабирование жестами включено
  WebGL 1 - Информация WSI драйвера: EGL_VENDOR: Mesa 
Project
EGL_VERSION: 1.5
EGL_EXTENSIONS: EGL_ANDROID_blob_cache 

Bug#1052133: apt: E: Removing essential system-critical packages is not permitted. This might break the system.

[Thorsten Glaser]

Package: apt
Version: 2.7.3
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

E: Removing essential system-critical packages is not permitted. This might 
break the system.

Used to be that it asks for “Yes, do as I say!”, and this is missing
in sid now‽ I kinda need that…


-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/preferences.d/dash-mksh.pref present, but not submitted) --


-- (/etc/apt/preferences.d/ncurses-term-considered-harmful present, but not 
submitted) --


-- (/etc/apt/preferences.d/prevent-apparmor present, but not submitted) --


-- (/etc/apt/preferences.d/prevent-aptitude present, but not submitted) --


-- (/etc/apt/preferences.d/prevent-drexim present, but not submitted) --


-- (/etc/apt/preferences.d/prevent-networkmanager present, but not submitted) --


-- (/etc/apt/preferences.d/prevent-packagekit present, but not submitted) --


-- (/etc/apt/preferences.d/prevent-puppet present, but not submitted) --


-- (/etc/apt/preferences.d/prevent-ruby present, but not submitted) --


-- (/etc/apt/preferences.d/prevent-systemd-completely present, but not 
submitted) --


-- (/etc/apt/preferences.d/prevent-unattended-upgrades present, but not 
submitted) --


-- (/etc/apt/preferences.d/usrmove-done-considered-harmful present, but not 
submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/local.list present, but not submitted) --


-- (/etc/apt/sources.list.d/tarent-sid.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/wtf-sid.sources present, but not submitted) --


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

Kernel: Linux 5.10.0-25-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages apt depends on:
ii  adduser3.137
ii  base-passwd3.6.1
ii  debian-archive-keyring 2023.4
ii  gpgv   2.2.40-1.1
ii  libapt-pkg6.0  2.7.3
ii  libc6  2.37-7
ii  libelogind0 [libsystemd0]  246.10-1debian1
ii  libgcc-s1  13.2.0-2
ii  libgnutls303.8.1-4
ii  libseccomp22.5.4-1+b3
ii  libstdc++6 13.2.0-2

Versions of packages apt recommends:
ii  ca-bundle [ca-certificates]  20190604tarent1

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.22.0
ii  gnupg2.2.40-1.1
ii  gnupg1   1.4.23-1.1+b1
pn  powermgmt-base   

-- no debconf information

Bug#967592: libwnck: depends on deprecated GTK 2

[Bastian Germann]

All reverse libwnck reverse dependencies are gone.
So the package should be removed.

Bug#1037374: giggle: build-depends on transitional package libgdk-pixbuf2.0-dev

[Bastian Germann]

Version: 0.7-6

Bug#1052132: proc(5): Missing documentation of drops in /proc/net/udp

[Viru Gajanayake]

Package: manpages
Version: 6.03-2
Severity: normal
X-Debbugs-Cc: viru.gajanay...@yahoo.com

Dear Maintainer,

The manual page for proc "man proc" provides some documentation of
/proc/net/udp but it does not document everything.  In particular it
does not document the last column "drops".  Specifically I was looking
for confirmation of whether the value is the number of packets or bytes.
Please add documentation for the missing columns.


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

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

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.11.2-2

-- no debconf information

Bug#981594: neomutt: Please use openssl

[Julian Andres Klode]

Package: neomutt
Followup-For: Bug #981594
X-Debbugs-Cc: j...@debian.org

OpenSSL is now also licensed under the Apache license, and GnuTLS
does not support Let's encrypt certificates as used on gmane.io,
complaining about the expired DST Root CA X3.

OpenSSL supports this Let's encrypt root CA change just fine, so
please just build with it.

I can also file a separate bug about gmane.io, but arguably the
solution here should be clear.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Simon McVittie]

On Sun, 17 Sep 2023 at 20:57:36 +0200, Salvatore Bonaccorso wrote:
> On Sun, Sep 17, 2023 at 07:09:45PM +0100, Simon McVittie wrote:
> > As far as I can tell, oldstable is not affected by this, because it
> > doesn't appear to have the new screenshot UI in js/ui/screenshot.js that
> > has the vulnerability.
> 
> Do you think it's safe to say that the issue is introduced around the
> commits which introduce in the screenshot-ui the screenshot/screencast
> toggles, e.g. 497d9f32eb02 ("screenshot-ui: Add screenshot/screencast
> toggle") and eb60fa290882 ("screenshot-ui: Bind button to shot/cast")
> which are in 42.beta upstream?

Perhaps a little earlier than that, but I can't see how versions earlier
than 8ebc478f "Add scaffolding for the new screenshot UI" could be
vulnerable, and that commit was also first released in 42.beta.

smcv

Bug#1037373: geany-plugins: NMU 1.38+dfsg-2.1

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is attached.diff -Nru geany-plugins-1.38+dfsg/debian/changelog 
geany-plugins-1.38+dfsg/debian/changelog
--- geany-plugins-1.38+dfsg/debian/changelog2022-12-15 03:11:13.0 
+
+++ geany-plugins-1.38+dfsg/debian/changelog2023-09-17 19:58:30.0 
+
@@ -1,3 +1,11 @@
+geany-plugins (1.38+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Drop unused Build-Depends: libwnck-dev (Closes: #1041807)
+  * Move to Build-Depends: libgdk-pixbuf-2.0-dev (Closes: #1037373)
+
+ -- Bastian Germann   Sun, 17 Sep 2023 19:58:30 +
+
 geany-plugins (1.38+dfsg-2) unstable; urgency=medium
 
   * [386780f] Refresh patches and add patch to drop bundled gpgme.m4.
diff -Nru geany-plugins-1.38+dfsg/debian/control 
geany-plugins-1.38+dfsg/debian/control
--- geany-plugins-1.38+dfsg/debian/control  2022-12-15 03:11:13.0 
+
+++ geany-plugins-1.38+dfsg/debian/control  2023-09-17 19:57:28.0 
+
@@ -18,11 +18,10 @@
python3-docutils,
libxml2-dev (>= 2.6.27),
libsoup2.4-dev (>= 2.4.0),
-   libgdk-pixbuf2.0-dev (>= 2.0),
+   libgdk-pixbuf-2.0-dev (>= 2.0),
libgpgme11-dev,
libvte-2.91-dev,
libwebkit2gtk-4.0-dev,
-   libwnck-dev (>= 2.10.0),
libmarkdown2-dev,
libgit2-dev,
valac (>= 0.7.0),

Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool

[Daniel Gröber]

Hi Nicholas,

On Sun, Sep 17, 2023 at 02:56:47PM -0400, Nicholas D Steeves wrote:
> Thank you for working on this!  One note: where is it documented how
> ipupdown and ipupdown-ng interact?

You just install the ifupdown-ng package and it kicks ifupdown out the door :)

More seriously: ifupdown-ng now Recommends:ifupdown-ng-compat (the bit that
conflicts with ifupdown) so for testing I can do --no-install-recommends
and get both at once but the old package in stable just straight up
conflicts with traditional ifupdown.

I'm intending to do a good amount of testing/integration work to make sure
ifupdown-ng can handle an upgrade without breaking the network but that
hasn't happened yet. Though I keep switching back and forth between them
and haven't noticed any severe breakage yet so maybe it's already fine :3

Testers welcome. I'd also appreciate people send me weird stuff they have
in /etc/network/interfaces I can try out.


A bit of background: The way I see it ifupdown-ng's integration into Debian
isn't complete yet. Unfortunately the very first (pretty incomplete) upload
landed in stable. Part of the reason being that Thomas seems to have lost
interest and I was peeved by his essentially snatching the package out from
under me, re-doing my packaging work with some weirdly broken openstack-pkg
specific git packaging scripts I didn't want to deal with. So I neglected
the package for a while.

> For example using the alternatives system, or a different config file
> location, or some sort of tagging mechanism in network/interfaces.  I
> would appreciate it if this was in the changelog, at a minimum, and maybe
> other people would too?  A brief "...by using $method" seems like it
> would be enough.

Since the interaction amounts to "one replaces the other" I think this is
mild overkill. The package description already covers how it's supposed to
be a drop-in replacement, maybe you missed that. Though ATM this still seems
a bit more aspirational than practical[1], but maybe I'm just pedantic about
compatibility.

[1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/216

For a high-level overview of the project goals and how it compares to
ifupdown2 etc have a look at Maximilian's DebConf-21 talk:


https://debconf21.debconf.org/talks/52-contemporary-networking-configuration-with-ifupdown-ng/

--Daniel

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Alexandre Detiste  writes:

> The ugly magic behind the curtain:

> ls /usr/libexec/cruft/ -1
>   LOGROTATE -> that parses these for path
>   SERVICES -> added today reading this discussion, it reads
>  CacheDirectory= & StateDirectory= from *.service
>   TMPFILES  -> that parses these for path

> This whole thing, while being already usefull & used,
> is more like a mockup of what could be a "perfect" dpkg.

> These tiny shell scripts could be converted into something else
> that plugs into dpkg ... for example tiny .so plugins that answer
> which package own which dynamic file ?

> (for runtime evaluation, other possibility is debhelper magic at
> compile-time that generate a list of possible files)

Based on previous discussion with Guillem, I think the direction Guillem
is headed is something like adding a new member (or field in another
member) to the deb format that holds a list of volatile files that the
package considers itself responsible for.  I think I agree with Guillem's
position (at least as I understand it) that it doesn't make sense for dpkg
to parse other files to populate that list.  That can very easily be
handled outside of dpkg.

So the idea would be that the package would install tmpfiles.d files,
service units, and similar files as normal, and then debhelper would parse
those files, extract the list of paths that they manage, and use that to
write a control file or the like that dpkg consumes to register those
files.

If I'm correct about that design, an intermediate step in that direction
from where cruft is today would be to add that logic to debhelper and then
have debhelper ship that database in the package in
/usr/share/cruft/ or some similar directory, and then cruft could
just consume that database of registered paths to get attribution
information until such time as that can move into dpkg.

This design is just off the top of my head, and I'm probably missing some
problems and some details.

-- 
Russ Allbery (r...@debian.org)  

Bug#1052130: linux-image-6.5.0-1-amd64: kernel complains about general protection fault several times before host goes down

[Paul Gevers]

Package: linux-image-6.5.0-1-amd64
Version: 6.5.3-1
Severity: normal

Dear linux maintainers,

We recently switched the main amd64 worker for ci.d.n to the backports
kernel due to bug 1050256. However, I had the host become unaccessible
twice, so I upgraded to the unstable kernel (not totally my intention
but due to wrong apt pinning). Since I ran the unstable kernel (about
three days ago, the host has become non responsive several times.

Just before the journal stops logging things, the kernel logs about a
"general protection fault" several times. See the attached log for
more details.

I'm sending this from my laptop, if I should collect information from
the host, please let me know.

Paul
Sep 17 07:43:48 ci-worker13 kernel: general protection fault, probably for 
non-canonical address 0xcb9d265a04e18934:  [#1] PREEMPT SMP NOPTI
Sep 17 07:43:48 ci-worker13 kernel: CPU: 18 PID: 3374089 Comm: rsync Not 
tainted 6.5.0-1-amd64 #1  Debian 6.5.3-1
Sep 17 07:43:48 ci-worker13 kernel: Hardware name: Dell Inc. PowerEdge 
R6515/07PXPY, BIOS 2.2.4 04/12/2021
Sep 17 07:43:48 ci-worker13 kernel: RIP: 0010:kmem_cache_alloc_node+0x1cf/0x380
Sep 17 07:43:48 ci-worker13 kernel: Code: d8 5b 41 5c 41 5d 41 5e 41 5f 5d e9 
5b ca 82 00 41 8b 44 24 28 4d 8b 14 24 49 89 f8 49 89 d1 49 8b 9c 24 b8 00 00 
00 48 01 f8 <48> 33 18 48 89 c1 48 89 f8 48 0f c9 48 31 cb 48 8d 8a 00 20 00 00
Sep 17 07:43:48 ci-worker13 kernel: RSP: 0018:962a8ee33af0 EFLAGS: 00010282
Sep 17 07:43:48 ci-worker13 kernel: RAX: cb9d265a04e18934 RBX: bb883960d76814e0 
RCX: 
Sep 17 07:43:48 ci-worker13 kernel: RDX: 000172e38012 RSI: 9e44f718 
RDI: cb9d265a04e188c4
Sep 17 07:43:48 ci-worker13 kernel: RBP: 962a8ee33b40 R08: cb9d265a04e188c4 
R09: 000172e38012
Sep 17 07:43:48 ci-worker13 kernel: R10: 0003b4d0 R11:  
R12: 89fcd6251800
Sep 17 07:43:48 ci-worker13 kernel: R13: 89ca134f3d80 R14: 00400cc0 
R15: 
Sep 17 07:43:48 ci-worker13 kernel: FS:  7f9416f7fb80() 
GS:8a087e88() knlGS:
Sep 17 07:43:48 ci-worker13 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Sep 17 07:43:48 ci-worker13 kernel: CR2: 7f94167e9fe8 CR3: 000e13f3c000 
CR4: 00350ee0
Sep 17 07:43:48 ci-worker13 kernel: Call Trace:
Sep 17 07:43:48 ci-worker13 kernel:  
Sep 17 07:43:48 ci-worker13 kernel:  ? die_addr+0x36/0x90
Sep 17 07:43:48 ci-worker13 kernel:  ? exc_general_protection+0x1c5/0x430
Sep 17 07:43:48 ci-worker13 kernel:  ? asm_exc_general_protection+0x26/0x30
Sep 17 07:43:48 ci-worker13 kernel:  ? kmem_cache_alloc_node+0x1cf/0x380
Sep 17 07:43:48 ci-worker13 kernel:  ? __alloc_skb+0x161/0x1a0
Sep 17 07:43:48 ci-worker13 kernel:  __alloc_skb+0x161/0x1a0
Sep 17 07:43:48 ci-worker13 kernel:  alloc_skb_with_frags+0x50/0x200
Sep 17 07:43:48 ci-worker13 kernel:  sock_alloc_send_pskb+0x1fa/0x240
Sep 17 07:43:48 ci-worker13 kernel:  ? srso_return_thunk+0x5/0x10
Sep 17 07:43:48 ci-worker13 kernel:  unix_stream_sendmsg+0x19d/0x690
Sep 17 07:43:48 ci-worker13 kernel:  sock_write_iter+0x175/0x180
Sep 17 07:43:48 ci-worker13 kernel:  vfs_write+0x39a/0x440
Sep 17 07:43:48 ci-worker13 kernel:  ksys_write+0xbb/0xf0
Sep 17 07:43:48 ci-worker13 kernel:  do_syscall_64+0x60/0xc0
Sep 17 07:43:48 ci-worker13 kernel:  ? do_pselect.constprop.0+0xfd/0x180
Sep 17 07:43:48 ci-worker13 kernel:  ? srso_return_thunk+0x5/0x10
Sep 17 07:43:48 ci-worker13 kernel:  ? fpregs_assert_state_consistent+0x26/0x50
Sep 17 07:43:48 ci-worker13 kernel:  ? srso_return_thunk+0x5/0x10
Sep 17 07:43:48 ci-worker13 kernel:  ? exit_to_user_mode_prepare+0x40/0x1d0
Sep 17 07:43:48 ci-worker13 kernel:  ? srso_return_thunk+0x5/0x10
Sep 17 07:43:48 ci-worker13 kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
Sep 17 07:43:48 ci-worker13 kernel:  ? srso_return_thunk+0x5/0x10
Sep 17 07:43:48 ci-worker13 kernel:  ? do_syscall_64+0x6c/0xc0
Sep 17 07:43:48 ci-worker13 kernel:  ? srso_return_thunk+0x5/0x10
Sep 17 07:43:48 ci-worker13 kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
Sep 17 07:43:48 ci-worker13 kernel:  ? srso_return_thunk+0x5/0x10
Sep 17 07:43:48 ci-worker13 kernel:  ? do_syscall_64+0x6c/0xc0
Sep 17 07:43:48 ci-worker13 kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
Sep 17 07:43:48 ci-worker13 kernel:  ? srso_return_thunk+0x5/0x10
Sep 17 07:43:48 ci-worker13 kernel:  ? do_syscall_64+0x6c/0xc0
Sep 17 07:43:48 ci-worker13 kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Sep 17 07:43:48 ci-worker13 kernel: RIP: 0033:0x7f9416917120
Sep 17 07:43:48 ci-worker13 kernel: Code: 40 00 48 8b 15 e1 9c 0d 00 f7 d8 64 
89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d c1 24 0e 00 00 74 17 b8 01 00 
00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
Sep 17 07:43:48 ci-worker13 kernel: RSP: 002b:7fffad5a6d68 EFLAGS: 0202 
ORIG_RAX: 0001
Sep 17 07:43:48 ci-worker13 kernel: RAX: ffda RBX: 0005 
RCX: 7f9416917120
Sep 17 

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Bill Allombert  writes:

> As I said, filling the caches in /var/cache. For that they need to exist
> with correct ownership and permissions.

Sorry, I think I saw that and then edited my message more and lost it
again.

That use case makes sense to me, and without the directory already
present, you have to know what directory to create and you have to get the
ownership and permissions correct.  But there's a couple of reasons why I
don't think that's a problem:

1. Installing the package creates the directories since it invokes
   systemd-tmpfiles via postinst, so the directory will normally be there
   with correct ownership and permissions.  The only case where it
   wouldn't be is in cases where the packages were installed without
   running postinst, which feels like an unusual use case.

2. Presumably you would be copying these caches from another system, which
   will normally have the directory with correct ownership and
   permissions.  This isn't necessarily true if you're mixing versions of
   Debian, of course, but in that case it's not clear the cache format
   will be correct either.  Also, you need to get the ownership and
   permissions of the files right, which the directory structure doesn't
   necessarily help you with, and if you're copying that over already, the
   same mechanism can handle the ownership and permissions of the parent
   directory.

So, by definition any directory that's shipped in the deb cannot have
dynamic ownership, which also limits the range of permissions it could
have.

> even populate /var/www with your website, etc.

/var/www is a whole separate problem that I agree has not yet been
addressed and would need to be.  We've known that /var/www is weird for a
while (we have a special exception in the FHS for it because it's breaking
the FHS file system layout rules), and there have been a few attempts to
handle it some other way, but none of them so far have been successful.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051219: ITA: gumbo-parser -- pure-C HTML5 parser

[Bastian Germann]

Am 16.09.23 um 18:20 schrieb Aymeric Agon-Rambosson:

After the experimental version is uploaded, you will have to request
a transition slot from the release team.


I'm currently reviewing https://wiki.debian.org/Teams/ReleaseTeam/Transitions. I am reading that I will have to test 
build the reverse dependencies (stage 4), and report about it in the release.debian.org bug. This part should be fine.


You can find the transition tracker at 
https://release.debian.org/transitions/html/auto-gumbo-parser.html
All of the listed packages build fine with the experimental gubo-parser.

But it also says that I will maybe have to make uploads to reverse dependencies (stage 10). I will probably need your 
help for this, since I'm not authorised to.


That will not be needed. Next step for you is to file the transition bug. 
Youcan see already filed ones at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org

In the bug you should tell them that there are no build failures with the 
experimental version in the reverse dependencies.

Bug#1052129: acpica-unix: Failed to migrate to Testing; missing s390x build not properly handled

[Adam D. Barratt]

On Sun, 2023-09-17 at 14:58 -0400, Boyuan Yang wrote:
> If you are clear that upstream is completely not supporting big-
> endian build anymore, please
> submit a package removal request to Debian Release Team (using
> reportbug tool) to remove
> the current s390x package in Debian Testing.

No. Architecture-specific removals happen in unstable, so the request
needs to be made to the FTP Team.

Regards,

Adam

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Bill Allombert]

On Sun, Sep 17, 2023 at 08:28:56AM -0700, Russ Allbery wrote:
> Bill Allombert  writes:
> > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
> >> On Sep 17, Russ Allbery  wrote:
> 
> >>> (I am a little confused by this wording, but I think what you're
> >>> saying is that /usr is encrypted and read-only, and /var is recreated
> >>> on each boot.  That at least is my understanding of the pattern that
> >>> you're trying to enable.)
> 
> >> The general idea is to be able to create /var on the first boot.
> 
> > Does not that would break users expectation that the system image
> > contains /var before the first boot ?
> 
> > A lot of things in /var are caches that are mostly instance-independent
> > and can be prefilled, but for that, users expect a minimal directory
> > hierarchy to be present before first boot.
> 
> Not that I think we're particularly close to achieving this design
> currently (and to be clear we haven't decided we're working towards this
> yet), but while I understand why a user would have that expectation today,
> I'm not sure why it would practically matter.  If all of that directory
> structure appears on first boot, and no static data is stored in /var,
> what use case requires the directory structure already exist in /var
> before the first boot?

As I said, filling the caches in /var/cache. For that they need to
exist with correct ownership and permissions.

Most of the cache in /var/cache/ (some are in /var/lib actually) 
do not depend on the host configuration, and can be regenerated/redownloaded as
needed, but not for free.

For example you might want to populate
/var/cache/apt/archives/ with the debs you need install later on (for example
for a pbuilder-like system), populate /var/lib/texmf/fonts/ with your fonts, or
even populate /var/www with your website, etc.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)

[Manphiz]

Manphiz  writes:

> Another finding is that in 28.x, if the term buffer have any further
> questions to ask, debian-bug seems to consider the process stuck and
> would just ignore everything and proceed.  In 29.x however, the term
> buffer seems to be able to accept user input and can process the output
> accordingly - even if the script requires sudo and prompt for password,
> and debian-bug can properly include the output in the generated email
> for bug report.  So with the merge request[4] it would instead skip all
> potential additional information unfortunately.
>

Actually 28.x also works for user inputs if running term-exec without my
problematic hooks so yeah!

> As we do want to handle process termination better, while trying to keep
> process from failing, I think temporarily disable term-exec-hook when
> processing the output and restore after the report is generated should
> probably work in most cases.  Just wondering whether this is acceptable
> in the process of debian-bug?
>

Forgot to mention that this is implemented as the 2nd commit in the
MR[4] and tested on bookworm and trixie to be working.

> [4] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/11

-- 
Manphiz

Bug#1052129: acpica-unix: Failed to migrate to Testing; missing s390x build not properly handled

[Boyuan Yang]

Source: acpica-unix
Version: 20230628-1
Severity: serious
X-Debbugs-CC: ivan...@canonical.com
Tags: sid

Hi Ivan Hu,

In the latest Debian package upload of acpica-unix/20230628-1, you removed 
big-endian support
for this package. However, you did not request to sync such changes with Debian 
Testing to
have existing big-endian packages (notably the s390x in Debian Testing). As a 
result, your
new upload cannot migrate to Debian Testing. It is likely that your package 
also stuck in
Ubuntu's -proposed repo for the same reason. You can check the package's 
condition at [1]
(and [2] for Ubuntu).

If you are clear that upstream is completely not supporting big-endian build 
anymore, please
submit a package removal request to Debian Release Team (using reportbug tool) 
to remove
the current s390x package in Debian Testing. If you don't know how to do it, 
please let me
know via email asap and I can help to make the report. Some similar effort may 
also be
necessary on the Ubuntu side.

Thanks, and please let me know if you have further questions.

[1] https://tracker.debian.org/pkg/acpica-unix
[2] https://launchpad.net/ubuntu/+source/acpica-unix

Regards,
Boyuan Yang


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

Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool

[Nicholas D Steeves]

Thank you for working on this!  One note: where is it documented how
ipupdown and ipupdown-ng interact?  For example using the alternatives
system, or a different config file location, or some sort of tagging
mechanism in network/interfaces.  I would appreciate it if this was in the
changelog, at a minimum, and maybe other people would too?  A brief "...by
using $method" seems like it would be enough.

Kind regards,
Nicholas

P.s. sorry for the html part, I'm on my phone

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Salvatore Bonaccorso]

Hi Simon,

On Sun, Sep 17, 2023 at 07:09:45PM +0100, Simon McVittie wrote:
> On Sun, 17 Sep 2023 at 19:39:24 +0200, Moritz Mühlenhoff wrote:
> > Does this also affect oldstable?
> 
> As far as I can tell, oldstable is not affected by this, because it
> doesn't appear to have the new screenshot UI in js/ui/screenshot.js that
> has the vulnerability. Pressing Print Screen in the lock screen in an
> oldstable GNOME VM just opens the password prompt, the same as if I had
> pressed Escape or Backspace.

Do you think it's safe to say that the issue is introduced around the
commits which introduce in the screenshot-ui the screenshot/screencast
toggles, e.g. 497d9f32eb02 ("screenshot-ui: Add screenshot/screencast
toggle") and eb60fa290882 ("screenshot-ui: Bind button to shot/cast")
which are in 42.beta upstream?

Regards,
Salvatore

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Alexandre Detiste]

So there are 3 distinct interlinked goals:

- tmpfiles.d itself
  - recovering from missing /var (+ later /etc)
  - volatile file tracking

Just finishing the first step without going to far in either
other tracks would be so great already.


Le dim. 17 sept. 2023 à 19:57, Russ Allbery  a écrit :
> Luca Boccassi  writes:
> > We are working on that. This means that tmpfiles.d would be able to both
> > create the files/dirs when needed, and remove them when unneeded, ie on
> > purge - as far as I can tell, that would be the only useful thing that a
> > dpkg integration would provide.
>
> dpkg -S is the most useful feature this supports for me personally (and
> some related things, such as cruft-finding).

I agree.

And when "dpkg -S file" fail,
just try "cruft /path/file".

It is slow, the implementation *is* bad - more like a unit test -
but should know about most files, and it still faster
than starting googling for the filename and getting distracted:

$ LANG=C dpkg -S  /var/log/dpkg.log
dpkg-query: no path found matching pattern /var/log/dpkg.log
$ time cruft /var/log/dpkg.log
dpkg
real0m7,129s

The ugly magic behind the curtain:

ls /usr/libexec/cruft/ -1
  LOGROTATE -> that parses these for path
  SERVICES -> added today reading this discussion, it reads
 CacheDirectory= & StateDirectory= from *.service
  TMPFILES  -> that parses these for path


This whole thing, while being already usefull & used,
is more like a mockup of what could be a "perfect" dpkg.

These tiny shell scripts could be converted into something else
that plugs into dpkg ... for example tiny .so plugins that answer
which package own which dynamic file ?

(for runtime evaluation, other possibility is debhelper magic at compile-time
that generate a list of possible files)

> More generally, dropping directories that are currently registered with
> dpkg from dpkg's database is a regression.

I agree.


I've mounted /var/cache/apt/archives everywhere on a tmpfs since forever,
apt will now how/when to recreate /partial subdir,
but yet it's nice to have it in dpkg register.

> Specifics!  Specifics!  My kingdom for specifics!  :)

There's indeed not so much remaining in the way for /var,
some files could be replaced by tmpfiles.d generated symlinks

$ cat /var/lib/dpkg/info/*.list | grep ^/var | sort -u | while read f;
do test -f $f && echo $f; done | wc -l
256

$ dpkg -S $(cat /var/lib/dpkg/info/*.list | grep ^/var | sort -u |
while read f; do test -f $f && echo $f; done) | cut -d: -f1 | sort -u
aspell-en
dictionaries-common
ifrench: /var/lib/dictionaries-common/ispell/ifrench -> generated metadata
plocate:   CACHEDIR.TAG
poppler-data:only transitional symlinks to /usr/share/poppler ?
ttf-mscorefonts-installer: only one file that could be symlinked from /usr
xserver-common:   /var/lib/xkb/README.compiled, could be a
symlink from /usr/share/doc

Maybe /etc in a later track.

Greetings,

(I find this thread greatly inspirational)

Bug#1050239: linux-image-6.1.0-11-amd64 breaks usermode networking for Windows VM in Gnome Boxes

[Salvatore Bonaccorso]

Source: linux
Source-Version: 6.1.52-1

Hi Stijn

On Sun, Sep 17, 2023 at 08:23:02PM +0200, Stijn Segers wrote:
> Hi Salvatore,
> 
> 
> Op woensdag 30 augustus 2023 om 15:03:37 +02:00:00 schreef Salvatore
> Bonaccorso :
> > Control: tags -1 + moreinfo
> > 
> > On Tue, Aug 22, 2023 at 03:45:08PM +0200, Stijn Segers wrote:
> > >  Package: linux-image-6.1.0-11-amd64
> > >  Version: 6.1.38-4
> > > 
> > >  Using kernel linux-image-6.1.0-11-amd64, my Windows 10 VM loses
> > > network
> > >  connectivity. Linux VMs still work (tested with an Xubuntu 23.04
> > > and 22.04
> > >  LTS VM). Rolling back to linux-image-6.1.0-10-amd64 makes the
> > > Windows VM
> > >  connect to the network again.
> > > 
> > >  Tested in Gnome Boxes on Debian Bookworm; used virt-manager as well
> > > to start
> > >  the Windows VM to make sure it was not a Gnome Boxes issue.
> > > 
> > >  Network configuration snippet of the Windows 10 VM:
> > > 
> > > 
> > >  
> > >  
> > >
> > >
> > > > >  function='0x0'/>
> > >  
> > >  
> > 
> > You are not giving information on the underlying host, but can you
> > specificy is this a regression from 6.1.38-2?
> > 
> 
> Apologies, host is a AMD Ryzen 7 5800X 8-Core Processor. It is indeed a
> regression from 6.1.38-2.
> 
> 
> > While not exactly the same, there were regression from the AMD
> > Inception fixes, can you verify if #1043585 is the same and the
> > upstream changes fixes your issue?
> 
> I installed 6.1.52-1 and the Windows VM has network again, so this seems
> solved.
> 
> Grazie mille!

And thanks a lot for confirming. I'm closing thus the bug with the
6.1.52-1 version.

Regards,
Salvatore

Bug#1052128: bnxt: BCM57416 NetXtreme-E Dual-Media 10Gb NIC not working after resume

[4porte]

Package: src:linux
Version: 6.1.52-1
Severity: normal
File: bnxt
X-Debbugs-Cc: 4po...@tutanota.com

Dear Maintainer,

   * What led up to the situation?

NIC does not come up after a system suspend.

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

A workaround involving PCI device reset suggested on the Debian forums was 
effective.
https://forums.debian.net/viewtopic.php?t=156049

   * What was the outcome of this action?

NIC comes up working fine.




-- Package-specific info:
** Version:
Linux version 6.1.0-12-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.52-1 (2023-09-07)

** Command line:
root=zfs:zroot/ROOT/debian quiet loglevel=4 spl.spl_hostid=0x00bab10c

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[ 7872.281089] CPU5 is up
[ 7872.281123] smpboot: Booting Node 0 Processor 6 APIC 0x12
[ 7872.295591] CPU6 is up
[ 7872.295625] smpboot: Booting Node 0 Processor 7 APIC 0x14
[ 7872.309874] CPU7 is up
[ 7872.309909] smpboot: Booting Node 0 Processor 8 APIC 0x16
[ 7872.324942] CPU8 is up
[ 7872.324977] smpboot: Booting Node 0 Processor 9 APIC 0x20
[ 7872.339452] CPU9 is up
[ 7872.339486] smpboot: Booting Node 0 Processor 10 APIC 0x22
[ 7872.354492] CPU10 is up
[ 7872.354530] smpboot: Booting Node 0 Processor 11 APIC 0x24
[ 7872.369212] CPU11 is up
[ 7872.369246] smpboot: Booting Node 0 Processor 12 APIC 0x26
[ 7872.384625] CPU12 is up
[ 7872.384661] smpboot: Booting Node 0 Processor 13 APIC 0x28
[ 7872.399652] CPU13 is up
[ 7872.399686] smpboot: Booting Node 0 Processor 14 APIC 0x30
[ 7872.415373] CPU14 is up
[ 7872.415409] smpboot: Booting Node 0 Processor 15 APIC 0x32
[ 7872.430380] CPU15 is up
[ 7872.430414] smpboot: Booting Node 0 Processor 16 APIC 0x34
[ 7872.446133] CPU16 is up
[ 7872.446169] smpboot: Booting Node 0 Processor 17 APIC 0x36
[ 7872.461468] CPU17 is up
[ 7872.468417] ACPI: PM: Waking up from system sleep state S3
[ 7872.592238] pci :16:05.0: disabled boot interrupts on device [8086:2034]
[ 7872.592324] pci :64:05.0: disabled boot interrupts on device [8086:2034]
[ 7872.592380] pci :b2:05.0: disabled boot interrupts on device [8086:2034]
[ 7872.592489] xhci_hcd :00:14.0: xHC error in resume, USBSTS 0x411, Reinit
[ 7872.592492] usb usb1: root hub lost power or was reset
[ 7872.592494] usb usb2: root hub lost power or was reset
[ 7872.597835] nvme nvme0: 18/0/0 default/read/poll queues
[ 7872.600693] nvme nvme1: Shutdown timeout set to 8 seconds
[ 7872.601086] nvme nvme2: Shutdown timeout set to 8 seconds
[ 7872.615100] nvme nvme2: 18/0/0 default/read/poll queues
[ 7872.617521] nvme nvme1: 18/0/0 default/read/poll queues
[ 7873.156856] usb 1-3: reset low-speed USB device number 3 using xhci_hcd
[ 7873.324536] ata8: SATA link down (SStatus 4 SControl 300)
[ 7873.325569] ata3: SATA link down (SStatus 4 SControl 300)
[ 7873.325974] ata1: SATA link down (SStatus 4 SControl 300)
[ 7873.326065] ata4: SATA link down (SStatus 4 SControl 300)
[ 7873.326099] ata5: SATA link down (SStatus 4 SControl 300)
[ 7873.326139] ata7: SATA link down (SStatus 4 SControl 300)
[ 7873.326167] ata6: SATA link down (SStatus 4 SControl 300)
[ 7873.328694] ata2: SATA link down (SStatus 4 SControl 300)
[ 7873.468458] bnxt_en :17:00.0 enp23s0f0np0: Error (timeout: 500015) msg 
{0x0 0xe0} len:0
[ 7873.468480] bnxt_en :17:00.0: PM: dpm_run_callback(): 
pci_pm_resume+0x0/0xe0 returns -19
[ 7873.468498] bnxt_en :17:00.0: PM: failed to resume async: error -19
[ 7873.572859] usb 1-13: reset high-speed USB device number 5 using xhci_hcd
[ 7873.988866] usb 1-8: reset low-speed USB device number 4 using xhci_hcd
[ 7874.394843] bnxt_en :17:00.1 enp23s0f1np1: Error (timeout: 500015) msg 
{0x0 0x11b1} len:0
[ 7874.394858] bnxt_en :17:00.1: PM: dpm_run_callback(): 
pci_pm_resume+0x0/0xe0 returns -19
[ 7874.394873] bnxt_en :17:00.1: PM: failed to resume async: error -19
[ 7874.404593] usb 1-1: reset full-speed USB device number 2 using xhci_hcd
[ 7874.680896] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd
[ 7874.708525] OOM killer enabled.
[ 7874.708529] Restarting tasks ... done.
[ 7874.714224] random: crng reseeded on system resumption
[ 7874.714296] PM: suspend exit
[ 7874.719157] rfkill: input handler enabled
[ 7874.914804] rfkill: input handler disabled
[ 7874.997737] e1000e :00:1f.6 eno1: NIC Link is Down
[ 7876.060125] bnxt_en :17:00.0 enp23s0f0np0: Error (timeout: 500015) msg 
{0xb0 0xe1} len:0
[ 7876.060144] bnxt_en :17:00.0 enp23s0f0np0: hwrm stat ctx alloc failure 
rc: fff0
[ 7876.060166] bnxt_en :17:00.0 enp23s0f0np0: bnxt_init_nic err: fff0
[ 7877.011762] bnxt_en :17:00.1 enp23s0f1np1: Error (timeout: 500015) msg 
{0xb0 0x11b2} len:0
[ 7877.011782] bnxt_en :17:00.1 enp23s0f1np1: hwrm stat 

Bug#1051883: marked as pending in qttools-opensource-src

[Dmitry Shachnev]

Hi Sebastian!

On Sun, Sep 17, 2023 at 08:14:44PM +0200, Sebastian Ramacher wrote:
> Control: reopen -1
> 
> On 2023-09-17 14:13:08 +, Dmitry Shachnev wrote:
> > Control: tag -1 pending
> > 
> > Hello,
> > 
> > Bug #1051883 in qttools-opensource-src reported by you has been fixed in the
> > Git repository and is awaiting an upload. You can see the commit
> > message below and you can check the diff of the fix at:
> > 
> > https://salsa.debian.org/qt-kde-team/qt/qttools/-/commit/c29ff951dc40dd804542a6dbbb9a32854e3087d8
> > 
> > 
> > Build with LLVM 15 for now.
> > 
> > Closes: #1051883.
> 
> The build fails with llvm-toolchain-15 in the same way. Looks like llvm
> is not the cause of the FTBFS.

No, it fails not in the same way.

With llvm-toolchain-16 the failed tests were qdoc tests:
tst_generatedOutput::webXmlFromCpp() and tst_generatedOutput::preparePhase(),
which are directly related to LLVM (qdoc uses it to parse C++ code). I spent
some time searching for an upstream fix, but with no luck (upstream does not
support 5.15 branch officially anymore, and with 6.4.2 I get different
failures in this test).

Now, these two tests passed, but tst_QHelpEngineCore::setCollectionFile()
failed, which is something new (it did not fail in my local build).

I will investigate.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1050239: linux-image-6.1.0-11-amd64 breaks usermode networking for Windows VM in Gnome Boxes

[Stijn Segers]

Hi Salvatore,


Op woensdag 30 augustus 2023 om 15:03:37 +02:00:00 schreef Salvatore 
Bonaccorso :

Control: tags -1 + moreinfo

On Tue, Aug 22, 2023 at 03:45:08PM +0200, Stijn Segers wrote:

 Package: linux-image-6.1.0-11-amd64
 Version: 6.1.38-4

 Using kernel linux-image-6.1.0-11-amd64, my Windows 10 VM loses 
network
 connectivity. Linux VMs still work (tested with an Xubuntu 23.04 
and 22.04
 LTS VM). Rolling back to linux-image-6.1.0-10-amd64 makes the 
Windows VM

 connect to the network again.

 Tested in Gnome Boxes on Debian Bookworm; used virt-manager as well 
to start

 the Windows VM to make sure it was not a Gnome Boxes issue.

 Network configuration snippet of the Windows 10 VM:


 
 
   
   
   
 
 


You are not giving information on the underlying host, but can you
specificy is this a regression from 6.1.38-2?



Apologies, host is a AMD Ryzen 7 5800X 8-Core Processor. It is indeed a 
regression from 6.1.38-2.




While not exactly the same, there were regression from the AMD
Inception fixes, can you verify if #1043585 is the same and the
upstream changes fixes your issue?


I installed 6.1.52-1 and the Windows VM has network again, so this 
seems solved.


Grazie mille!

Stijn



Regards,
Salvatore

Bug#1052039: okular: Okular cannot open PDF files: Solved !

[Aurélien COUDERC]

Le 17 septembre 2023 09:35:27 GMT+02:00, "Frédéric Tronel" 
 a écrit :
>Dear maintainer,
>
>
>I have found the reason why 
>/usr/lib/x86_64-linux-gnu/qt5/plugins/okular/generators/okularGenerator_poppler.so
>was linked against libtiff.so.5 on my system.
>This was due to a local recompilation of libpoppler on my bulleyes 
>installation (that I have just migrated to
>bookworm). The faulty library (libpoppler.so) was still installed in 
>/usr/local/lib ...
>Removing it solves the problem.

Good to hear, thanks for the feedback.


--
Aurélien

Bug#1051883: marked as pending in qttools-opensource-src

[Sebastian Ramacher]

Control: reopen -1

On 2023-09-17 14:13:08 +, Dmitry Shachnev wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #1051883 in qttools-opensource-src reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/qt-kde-team/qt/qttools/-/commit/c29ff951dc40dd804542a6dbbb9a32854e3087d8
> 
> 
> Build with LLVM 15 for now.
> 
> Closes: #1051883.

The build fails with llvm-toolchain-15 in the same way. Looks like llvm
is not the cause of the FTBFS.

Cheers
-- 
Sebastian Ramacher

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Simon McVittie]

On Sun, 17 Sep 2023 at 19:39:24 +0200, Moritz Mühlenhoff wrote:
> Does this also affect oldstable?

As far as I can tell, oldstable is not affected by this, because it
doesn't appear to have the new screenshot UI in js/ui/screenshot.js that
has the vulnerability. Pressing Print Screen in the lock screen in an
oldstable GNOME VM just opens the password prompt, the same as if I had
pressed Escape or Backspace.

(But don't necessarily trust me 100% on this - I'm sorry, I'm making more
mistakes than I should today.)

smcv

Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool

[Daniel Gröber]

Package: sponsorship-requests
Severity: normal

Hello mentors,

I am looking for a sponsor for my package ifupdown-ng, it's a promising
modern alternative for ifupdown with support for dependencies and a lot
more interface types.

The headline change in this revision is that I've split a new binpkg from
the package to support co-installability with traditional ifupdown. This
will enable easier migration and compatibility testing. Full changelog below.

 * Package name : ifupdown-ng
   Version  : 0.12.1-1
 * URL  : https://github.com/ifupdown-ng/ifupdown-ng
 * Vcs  : https://salsa.debian.org/debian/ifupdown-ng
 * License  : MIT-like
   Section  : admin

The source builds the binpkgs:

  ifupdown-ng - network interface configuration tool
  ifupdown-ng-compat - network interface configuration tool -- ifupdown compat

The gbp source repo lives at

  https://salsa.debian.org/debian/ifupdown-ng.git

please use the git repo for uploading but the package is also on mentors
for linting results:

  https://mentors.debian.net/package/ifupdown-ng/

Changes since the last upload:

 ifupdown-ng (0.12.1-1) UNRELEASED; urgency=medium
 .
   [ Debian Janitor ]
   * Bump debhelper from old 12 to 13.
   * Set upstream metadata fields: Repository-Browse.
   * Update standards version to 4.6.1, no changes needed.
   * Set upstream metadata fields: Repository.
 .
   [ Daniel Gröber ]
   * New upstream release
   * Fix nonsense janitor commits
   * Fix d/watch
   * Add patch to support ifupdown compatible 'source' include patterns
   * Fix bogus ExecRestart systemd unit stanza (Closes: #1006817)
   * Align systemd service dependencies with ifupdown
   * Drop support for kfreebsd/hurd
   * Remove deprecated lsb-base dependency
   * Promote rdnssd to recommends for IPv6-only support by default
   * Fix co-installability with ifupdown
   * Ensure all make targets run under the same environment
   * Fix conflicting files in /usr/share/man
   * Fix networking script perms
   * Add autopkgtest for coinstallability with traditional ifupdown
   * Fix some pedantic lintian complaints
   * Fix upgrade path from stable not installing ifupdown compat

Thanks,
--Daniel


signature.asc
Description: PGP signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Luca Boccassi  writes:

> Let me clarify, here I meant something much simpler - the image
> installed is a 'normal' one, with r/w root and managed by apt as usual
> (ie: not immutable image-based) but with a repart.d snippet that causes
> a new /var to be created on-the-fly on first boot if missing, with
> tpm-bound encryption (and similar treatment for /home, although
> unrelated here). This is a very low-hanging fruit of a pattern that
> would allow to achieve decent local data protection on an otherwise
> pretty much vanilla setup. But if you need to ship /var from packages,
> then it goes out of the window.

I don't see how shipping empty directories in a deb package affects this
in any way.  You're going to have to be considerably more specific about
what invariant is being violated or what error you're expecting.

One of the key things that I'm stuck on, and which you haven't addressed
that I've seen, is that you're talking here about a system managed with a
normal package manager, and therefore running all maintainer scripts.  The
maintainer scripts under this tmpfiles.d proposal will create directories
and files in /var, because the whole point is that systemd-tmpfiles is run
from postinst.  But you are saying that creating directories and files in
/var with the package manager will break this configuration.  I'm missing
something here.  There's nothing special about dpkg creating the directory
versus postinst creating the directory.  So far as I can tell, the only
important part is that the directory be registered in tmpfiles.d (or a
service unit) so that it can be recreated when needed.

> I don't think it is particularly useful, and mixing package content
> with variable data smells like trouble to me.

I understand that you don't like the idea.  You've made that very clear.
However, we are *currently* doing this, so obviously nothing that we
currently support is going to break from continuing to do this.

I understand that you are trying to do something new, and you are worried
that this will interfere with it, but so far you have not been able to
explain any way in which this *would* cause you problems.  You just don't
like the vibes.  And I hear that, and sometimes that sort of bad feeling
is a valuable architectural clue, but in this case you're really going to
have to be more specific because I'm not seeing it.

Also, we clearly cannot ship a system without /var *now* because oodles of
other packages put things there, so a lot of work is left to do before
this is a technical vision that Debian can implement, if we do indeed
decide to implement it.  Policy can always change later; perhaps by the
time that we're ready to implement this vision, dpkg will have a way of
registering files managed by tmpfiles.d and there's no reason to ship the
empty directories in the package.  So theoretical future problems are not
very persuasive to me at this stage, particularly if you can't be specific
about what those problems would be.

> I'd much rather finish the factory reset workstream for lifetime
> management, so that tmpfiles can handle tmpfiles purges, without needing
> to involve dpkg.

I understand that you would like to finish this, but Debian so far has not
even decided to *start* this, so while I'm willing to take this into
account when writing Policy, it's not a controlling design principle.  If
you get an agreement in Debian that this is something we're going to work
towards, then it will become a significant factor in evaluating Policy
changes.

I'm really trying to meet you halfway here by adopting and fleshing out
proposals that you're putting forward primarily for a project that Debian
isn't currently doing, but which have clear other benefits regardless of
whether we do the factory reset project.  I don't want to argue over end
goals when we can agree on intermediate steps regardless of the end goal.
But I really want to emphasize here that we are not *currently* writing
Policy to support factory reset because there is no decision in Debian yet
that we are supporting factory reset.

This is not directly relevant to this bug, but for the record, if you want
Debian to support factory reset, one good way to make that more likely is
to write a DEP with the details of precisely what that would mean, roughly
what sorts of things would need to change in packaging, and a list of what
the benefits would be.  I personally think a lot of the benefits are
rather compelling, but no one has yet made a proper case for it in Debian.
You and Marco and a few other people just write email messages on other
topics that treat the desirability of factory reset as a foregone
conclusion, or mention a few benefits in passing and without specifics,
which of course is fine for casual discussion but which is not a real
attempt at persuasion and doesn't get us closer to making a real decision.

In other words, this is advice that I constantly give myself because I am
very bad at this and have to be reminded 

Bug#1052126: Please, drop me from uploaders (and copyright owners)

[David Prévot]

Source: sphinxcontrib-phpdomain
Version: 0.11.2-2
Severity: wishlist

Hi,

I introduced this package more than ten years ago, and got it removed a
few years after that, so I’m not in a position to actually maintain this
package (I don’t even have write access to the currently declared VCS).
Please, drop me from the Uploaders, and drop me also from the copyright
owner (nothing of the few lines I’ve actually edited that still remain
in debian/ are worth any copyright).

Regards,

taffit


signature.asc
Description: PGP signature

Bug#1052125: nala cannot install the debreate package

[Nikolay Sabelnikov]

Package: nala

Version: 0.12.2

saber716rus@BOM-WXX9 ~/Загрузки> sudo nala install 
debreate_0.8-dev9_all.deb
Уведломение: The following will be installed to satisfy debreate:
  python3-pip

 Installing 

  Пакет:Версия:  
  Размер:  
  debreate  0.8-dev9  2 KB  
  python3-pip   23.0.1+dfsg-1   1.3 MB  
  python3-wheel 0.38.4-2 31 KB  


 Summary

 Install 3 Пакеты 
  

 Disk space required  7.0 MB   
   
Do you want to continue? [Д/н] y
╭─ Установка пакетов 
──────────────────────────────────────────────────────────╮
│Unpacking:  python3-wheel (0.38.4-2) 
 │
│Unpacking:  python3-pip (23.0.1+dfsg-1)  
 │
│Setting up: python3-wheel (0.38.4-2) 
 │
│Setting up: python3-pip (23.0.1+dfsg-1)  
 │
│Processing: triggers for man-db (2.11.2-2)   
 │
│Unpacking:  debreate (0.8-dev9)  
 │
│Setting up: debreate (0.8-dev9)  
 │
│An unhandled exception occurred and Debreate shut down:  
 │
│Traceback (most recent call last):   
 │
│File "/usr/bin/debreate", line 230, in   
 │
│╭────────────────────────────────────────────────────────────────────────────╮│
││⠦ Running dpkg … 
━━━━━━━━━━━━━━━━━━━━━━━━━━━╸━━━━━━━━━
 75.0% • 0:00:02 • 6/8││
│╰────────────────────────────────────────────────────────────────────────────╯│
╰──────────────────────────────────────────────────────────────────────────────╯
╭───────────────────── Traceback 
(most recent call last) 
──────────────────────╮
│ /usr/lib/python3/dist-packages/nala/nala.py:364 in install  
 │
│ 
 │
│   361 │   man_help: bool = MAN_HELP,  
   │
│   362 ) -> None:
 │
│   363 │   """Install packages.""" 
   │
│ ❱ 364 │   _install(pkg_names, ctx)  
 │
│   365   
 │
│   366   
 │
│   367 @nala.command(help=_("Remove packages.")) 
 │
│ 
 │
│ 
╭──────────────────────────────
 locals 
──────────────────────────────╮
   │
│ │ assume_yes = None  │  
 │
│ │auto_remove = None  │  
 │
│ │ctx =  │  
 │
│ │  debug = None  │  
 │
│ │  download_only = None  

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Simon McVittie]

On Sun, 17 Sep 2023 at 19:39:24 +0200, Moritz Mühlenhoff wrote:
> please build with -sa (ftp.d.o and security.d.o don't share tarballs)

I'm sorry, I should have checked more carefully.

> Does this also affect oldstable?

I'm sorry, I haven't checked that yet.

> If so, can you please also prepare a backport?

I'm sorry, I will try to do that next but I cannot guarantee any
particular timeline.

smcv

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Moritz Mühlenhoff]

Am Sun, Sep 17, 2023 at 06:22:00PM +0100 schrieb Simon McVittie:
> On Sun, 17 Sep 2023 at 18:17:56 +0100, Simon McVittie wrote:
> > I can upload this to security-master if wanted, or the security
> > team or other GNOME team members are welcome to sponsor it
> > or upload their own version if they would like to take my
> > response time off the critical path. Unsigned packages are in
> > https://people.debian.org/~smcv/bug1052067/, diff attached.
> 
> Sigh, diff really attached now. I'm sorry, I should be more careful not
> to waste your time.

Thanks! I think we should fix this via a DSA.

The debdiff looks fine, please build with -sa (ftp.d.o and security.d.o
don't share tarballs) and upload to security-master.

Does this also affect oldstable? If so, can you please also prepare
a backport?

Cheers,
Moritz

Bug#1051780: focus-follows-mouse doesn't work with gnome-shell/mutter 45-rc

[Simon McVittie]

Control: tags -1 + fixed-upstream

On Sun, 17 Sep 2023 at 18:54:30 +0200, Roderich Schupp wrote:
> The problem has been fixed in upstream release 45.0.
> You may close this bug.

mutter 45.0 isn't in Debian (or Ubuntu) yet, so this bug should not
be closed just yet; but it can be closed when 45.0 is uploaded to
experimental, which I assume the developers working on GNOME Shell 45
will want to do next week.

Sorry, I'm not yet working on GNOME Shell 45 myself, so I haven't done
that upload: I've spent all of today on updates to versions 43 and 44,
trying to keep those versions working until 45 is ready. Version 45
cannot go to testing/unstable until the GNOME team has coordinated a
suitable upload timeline with the release team and the maintainers of
other affected packages like budgie-desktop.

Please try to keep a descriptive subject line like the bug title when
replying to bug reports: I realise it's appealing to change the subject
line to something like "more info" or "fixed upstream" if the bug is the
only one you are communicating with, but maintainers will often receive
a message like this one completely out of context, and will not know
which bug it is, or even which package it refers to, until they look up
the bug number.

Thanks,
smcv

Bug#1051563: Backporting mutt patches to Debian Buster

[Santiago Ruano Rincón]

hi!

El 16/09/23 a las 15:44, Utkarsh Gupta escribió:
> Hi Chris,
> 
> On Fri, Sep 15, 2023 at 8:09 PM Chris Frey  wrote:
> > Attached is a patch that applies to the unpackaged sources of Debian 
> > Buster's
> > version of mutt 1.10.
> >
> > It includes 3 patches:
> >
> > upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch
> > debian-specific/Check-for-NULL-userhdrs.patch
> > debian-specific/Fix-write_one_header-illegal-header-check.patch
> >
> > First one applied from Bullseye.  The other two I modified slightly
> > to match the older sources.
> 
> Many thanks, as usual. I'll look into it and let you know if we hit a
> bump backporting it.

Utkarsh, I have claimed mutt in both {d,e}la-needed, and started to work
preparing the repo. I am also OK if you want to finish the work.

Chris, thanks for preparing the patches. Much appreciated. I have a
question though: Why are you placing those two patches in
debian-specific, and not in upstream/? They come from the upstream repo.

Cheers!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1043124: [Pkg-zfsonlinux-devel] Bug#1043124: consider skipping trying to build on affected kernels?

[M. Zhou]

On Sun, 2023-09-17 at 14:12 +0200, Ari wrote:
> Have you, maintainers of zfs, considered configuring the packages so
> that it skips trying to build of affected kernels?
> This would at least reduce the time of installing any packages
> drastically - currently my system tries to build it for two kernels
> every time I install any package, because the kernel packages fail
> the configuration stage.
> Maybe with this approach it would be even feasible that the kernels'
> installation state would not be failed for which compilation failed?
> After all, the kernel installed correctly, but it's rather the zfs
> package that is broken.

While it indeed increases the speed of dpkg configuration steps,
skipping the build or silently leave the kernel installation without
failure is seriously wrong for many use cases, I believe.

Bug#1052124: RM: consulfs -- RoQA; unmaintained, related to consul which is to be removed

[Moritz Muehlenhoff]

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

Please remove consulfs. It hasn't seen update for 2.5 years, missed Bookworm
and depends on Consul, which is about to be removed.

Cheers,
Moritz

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Simon McVittie]

On Sun, 17 Sep 2023 at 18:17:56 +0100, Simon McVittie wrote:
> I can upload this to security-master if wanted, or the security
> team or other GNOME team members are welcome to sponsor it
> or upload their own version if they would like to take my
> response time off the critical path. Unsigned packages are in
> https://people.debian.org/~smcv/bug1052067/, diff attached.

Sigh, diff really attached now. I'm sorry, I should be more careful not
to waste your time.

smcv
diffstat for gnome-shell-43.6 gnome-shell-43.6

 debian/changelog   |8 +
 debian/patches/screenshot-Do-not-wrongly-enable-window-button.patch|   71 ++
 debian/patches/screenshot-Only-handle-mode-switch-shortcut-when-supporte.patch |   35 
 debian/patches/series  |2 
 js/ui/screenshot.js|   22 +--
 5 files changed, 130 insertions(+), 8 deletions(-)

diff -Nru gnome-shell-43.6/debian/changelog gnome-shell-43.6/debian/changelog
--- gnome-shell-43.6/debian/changelog	2023-06-11 00:08:43.0 +0100
+++ gnome-shell-43.6/debian/changelog	2023-09-17 17:18:49.0 +0100
@@ -1,3 +1,11 @@
+gnome-shell (43.6-1~deb12u2) bookworm-security; urgency=high
+
+  * Team upload
+  * Avoid exposing window previews on lock screen via keyboard shortcuts
+(Closes: #1052067, CVE-2023-43090, gnome-shell#6990)
+
+ -- Simon McVittie   Sun, 17 Sep 2023 17:18:49 +0100
+
 gnome-shell (43.6-1~deb12u1) bookworm; urgency=medium
 
   * Rebuild for bookworm
diff -Nru gnome-shell-43.6/debian/patches/screenshot-Do-not-wrongly-enable-window-button.patch gnome-shell-43.6/debian/patches/screenshot-Do-not-wrongly-enable-window-button.patch
--- gnome-shell-43.6/debian/patches/screenshot-Do-not-wrongly-enable-window-button.patch	1970-01-01 01:00:00.0 +0100
+++ gnome-shell-43.6/debian/patches/screenshot-Do-not-wrongly-enable-window-button.patch	2023-09-17 17:18:49.0 +0100
@@ -0,0 +1,71 @@
+From: =?utf-8?q?Florian_M=C3=BCllner?= 
+Date: Thu, 7 Sep 2023 17:59:03 +0200
+Subject: screenshot: Do not wrongly enable window button
+
+The window button is disabled when
+ - there are no windows
+ - we are in screen-recording mode
+ - the session mode doesn't allow windows
+
+However the last condition is only taken into account when
+opening the dialog, but not when switching from recording-
+to screenshot mode.
+
+Address this by updating the button's sensitivity in a separate
+function, so the different conditions are considered consistently.
+
+(cherry picked from commit 521525948eed85cc27c0796a0b9569d161df81ba)
+
+Bug: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6990
+CVE: CVE-2023-43090
+Origin: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2944
+Applied-upstream: 43.9, commit:9d81bbb8b60aa11082a8e7017995e0bc4745e506
+Bug-Debian: https://bugs.debian.org/1052067
+---
+ js/ui/screenshot.js | 19 ---
+ 1 file changed, 12 insertions(+), 7 deletions(-)
+
+diff --git a/js/ui/screenshot.js b/js/ui/screenshot.js
+index 4d9e42e..84830b2 100644
+--- a/js/ui/screenshot.js
 b/js/ui/screenshot.js
+@@ -1370,6 +1370,16 @@ var ScreenshotUI = GObject.registerClass({
+ this._castButton.reactive = Main.sessionMode.allowScreencast;
+ }
+ 
++_syncWindowButtonSensitivity() {
++const windows =
++this._windowSelectors.flatMap(selector => selector.windows());
++
++this._windowButton.reactive =
++Main.sessionMode.hasWindows &&
++windows.length > 0 &&
++!this._castButton.checked;
++}
++
+ _refreshButtonLayout() {
+ const buttonLayout = Meta.prefs_get_button_layout();
+ 
+@@ -1486,10 +1496,7 @@ var ScreenshotUI = GObject.registerClass({
+ });
+ }
+ 
+-this._windowButton.reactive =
+-Main.sessionMode.hasWindows &&
+-windows.length > 0 &&
+-!this._castButton.checked;
++this._syncWindowButtonSensitivity();
+ if (!this._windowButton.reactive)
+ this._selectionButton.checked = true;
+ 
+@@ -1732,9 +1739,7 @@ var ScreenshotUI = GObject.registerClass({
+ 
+ this._captureButton.remove_style_pseudo_class('cast');
+ 
+-const windows =
+-this._windowSelectors.flatMap(selector => selector.windows());
+-this._windowButton.reactive = windows.length > 0;
++this._syncWindowButtonSensitivity();
+ }
+ }
+ 
diff -Nru gnome-shell-43.6/debian/patches/screenshot-Only-handle-mode-switch-shortcut-when-supporte.patch gnome-shell-43.6/debian/patches/screenshot-Only-handle-mode-switch-shortcut-when-supporte.patch
--- gnome-shell-43.6/debian/patches/screenshot-Only-handle-mode-switch-shortcut-when-supporte.patch	1970-01-01 01:00:00.0 +0100
+++ 

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Simon McVittie]

On Sun, 17 Sep 2023 at 16:49:59 +0200, Salvatore Bonaccorso wrote:
> In this case we even not have yet decided if it's warranted or not,
> but I just aimed to make an unstable report to get it for sure fixed
> there already.
> 
> Lets decide on it and either me or another team member will come back
> to you.

If the security team would like to issue a DSA for
this, I've prepared a proposed minimal security update in
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/75
and tested it in a VM. I confirm that I can reproduce
the issue with current bookworm by following the steps in
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6990#note_1840101,
and in the proposed version I can no longer reproduce the issue.

I can upload this to security-master if wanted, or the security
team or other GNOME team members are welcome to sponsor it
or upload their own version if they would like to take my
response time off the critical path. Unsigned packages are in
https://people.debian.org/~smcv/bug1052067/, diff attached.

My understanding is that I am not permitted to upload signed packages
anywhere until the security team has given approval to upload to
security-master, because if I did, someone else would be able to upload
them to security-master in a way that would cause extra work for the
security team; so I have not uploaded any signed packages. I apologise
if this is wrong or has caused inconvenience.

If the security team declines to issue a DSA for this, then we will need
to retarget this to stable-proposed-updates. Please let me know which
route should be taken, because I'm aware that the deadline for 12.2 is
next weekend, and I will probably be unable to carry out any Debian work
next weekend due to other commitments.

Unrelated to this CVE, I have been trying to prepare a stable bugfix
update for mutter and gnome-shell incorporating upstream releases 43.7
and 43.8, and now gnome-shell 43.9 as well. The diff for these now cannot
be finalized until we know which route will be taken to fix this CVE.

smcv

Bug#1021341: autopkgtest-build-qemu: add dependency on zerofree

[Michael Tokarev]

Control: retitle -1 please stop using zerofree
Control: severity -1 important

Please do not add dependency on zerofree.

Instead, pleas DROP zerofree usage entirely in todays world.

It gave me multiple headaches already.

First I tried to experiment with autopkgtest (which uses vmdb2)
on a tmpfs.  It all went fine until vmdb2 decided to helpfully
zerofree the image, - which expanded it to whole RAM and immediately
caused an OOM.  I had to clean up from this for quite some time.

Another case is an SSD which gets filled with zeros, having to
allocate else unused blocks in the image file.

And yet another - on a regular rotating HDD, it has to turn a
sparse file into complete file, - in a typical autopkgtest-build-qemu
use case this means writing 25Gb of data, it is insanely slow.

If anything, one can use fstrim to achieve the desired result.

Thanks!

/mjt

Bug#1051780: more info

[Roderich Schupp]

The problem has been fixed in upstream release 45.0.
You may close this bug.

Cheers, Roderich

Bug#1052123: please drop usage of qemu-debootstrap

[Michael Tokarev]

Package: vmdb2
Version: 0.27+really.0.26-1
Severity: important
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org

qemu-debootstrap was a wrapper provided by qemu-user-static
package to assist creating foreign chroots using debootstrap,
before qemu-user binfmt-misc subsystem has been enabled.

For a few debian releases already, qemu-debootstrap has been
just a trivial wrapper around debootstrap, which prints a
warning about the tool being deprecated and run debootstrap
with all the same arguments.

Please drop qemu-debootstrap usage from vmdb2.

It has 2 plugins, qemudebootstrap_plugin.py and debootstrap_plugin.py -
the two should've been the same (besides the command to run), but
for some unknown reason they divirged from each other (most likely
because whomever edited one forgot to edit another).  I'd say
qemudebootstrap should be made synonym for debootstrap.

There's one more issue with current qemu-debootstrap: for cases
where qemu emulation isn't needed at all (like i386 image on
amd64 system, with i386 being just another native CPU arch),
this qemu-debootstrap dropping will eliminate qemu-user-static
dependency entirely.

Thanks,

/mjt

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Sun, 17 Sept 2023 at 00:12, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > Aside from more practical considerations, shipping /var content in
> > packages is problematic because it's supposed to be local variable data,
> > that can be removed without breaking a system.
>
> Unless I'm missing something, including the directory in the deb won't
> make any difference here.  dpkg won't break if a directory that was
> included in the package is deleted.  It would show as an inconsistency if
> someone checked the file system against the dpkg database, but as soon as
> systemd-tmpfiles runs, it will create the directory again and fix the
> inconsistency, so I don't see what problems that would create.

That was a remark about the concept itself, independently of tmpfiles
- variable data is variable data, and static data is static data.
Having variable data among static package content sounds conceptually
wrong to me, simply from a high-level design perspective.

> > More practically, one of the purposes of the hermetic-usr pattern is to
> > allow several modernizations. The easiest one to achieve is to create
> > /var/ on firstboot, and encrypt it against the tpm, so that it can be
> > enabled by default, always, so we can't have packages ship and expect
> > content in /var from their packages.
>
> (I am a little confused by this wording, but I think what you're saying is
> that /usr is encrypted and read-only, and /var is recreated on each boot.
> That at least is my understanding of the pattern that you're trying to
> enable.)

Let me clarify, here I meant something much simpler - the image
installed is a 'normal' one, with r/w root and managed by apt as usual
(ie: not immutable image-based) but with a repart.d snippet that
causes a new /var to be created on-the-fly on first boot if missing,
with tpm-bound encryption (and similar treatment for /home, although
unrelated here). This is a very low-hanging fruit of a pattern that
would allow to achieve decent local data protection on an otherwise
pretty much vanilla setup. But if you need to ship /var from packages,
then it goes out of the window.

In a sense, for the immutable /usr case it gets easier - you just
don't ship a package manager at all, and then you can do all the
mangling you want when building the image, as consistency no longer
matters, and you don't install/upgrade by definition. But I strongly
believe we need to do some serious steps forward in the
security-by-default aspects of all flavours, including the 'vanilla'
ones, where this consistency matters a lot, for obvious reasons - you
do upgrades/installs on those.

And yes, I would hope to have a concrete proposal for encrypting by
default to submit to the project for at least something like this for
Trixie, once more pieces have fallen into place. All mainstream
distributions are looking into some variation of this. It is way past
time Linux caught up with OSX and Windows on these aspects, and it
would be great if for once Debian wasn't left behind as usual.

> > On top of that, as you mentioned already things will inevitably get out
> > of sync, and one will have to duplicate everything.
>
> One would need to duplicate empty directories in /var (that don't have
> dynamic ownership).  I'm dubious that's a significant burden (it's two or
> three lines in debian/rules), but if it is, one could even automate this
> in debhelper by parsing tmpfiles.d if one really wanted to.  The main
> thing that could get out of sync is the ownership, which is indeed not
> ideal, but I'm also not sure it's going to cause major problems even if
> people do get it wrong.  I was trying to remember if dpkg changes
> directory (as opposed to file) ownership if it sees a directory owned by
> an unexpected user.  I kind of think it doesn't, but I'm not sure about
> that.
>
> The benefit we gain from this is attribution of the directories in the
> dpkg database, which is useful (although I understand that one can argue
> about how useful).

I don't think it is particularly useful, and mixing package content
with variable data smells like trouble to me. I'd much rather finish
the factory reset workstream for lifetime management, so that tmpfiles
can handle tmpfiles purges, without needing to involve dpkg. We are
working on that. This means that tmpfiles.d would be able to both
create the files/dirs when needed, and remove them when unneeded, ie
on purge - as far as I can tell, that would be the only useful thing
that a dpkg integration would provide. I am pretty sure running
checksums on local variable data would be a pretty useless exercise
given, well, it's variable. Or was there anything else aside from
these two aspects?

To do the tmpfiles purge/reset I have two WIP PRs, one against
sd-tmpfiles, and one against debhelper. I need to pick them up again
and finish that, and I am aiming to do so within the next couple of
months.

> So... I think the answer to my question of whether this will interfere
> with 

Bug#1038826: please drop usage of (deprecated in bullseye, removed in trixie) qemu-debootstrap

[Michael Tokarev]

autopkgtest-build-qemu uses vmdb2 >= 0.22 to build at least qemu-system images.
This means at least bullseye, since older debian had older vmdb2.
And in bullseye and up, qemu-debootstrap is just a trivial wrapper
for debootstrap command, the only extra action it does is to print
a deprecation warning, that's all.

Here, debootstrap (and qemu-debootstrap) are used on the "build" system,
not on the target system where the actual autopkgtests will be run.
So it's fine to assume the image-build-tools are to be from more
recent distributions than the test-target images are.

It is perfectly okay to drop usage of qemu-debootstrap now and run
debootstrap directly.

But this is not only in autopkgtest but in vmdb2 too (filing a bug
against it now).

Meanwhile, I re-introduced qemu-debootstrap wrapper in 8.1.0+ds-5
qemu, to unbreak at least some things.

Thanks,

/mjt

Bug#1052122: RFS: asunder/3.0.1+ds-1 -- Graphical audio CD ripper and encoder

[Peter B]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "asunder":
(Andreas R who kindly sponsored my adoption of this package,
is sadly locked out from his gpg key.)


 * Package name : asunder
   Version  : 3.0.1+ds-1
   Upstream contact : Andrew Smith 

 * URL  : http://www.littlesvr.ca/asunder
 * License  : GPL-2
 * Vcs  : https://salsa.debian.org/debian/asunder
   Section  : sound

The source builds the following binary packages:

  asunder - Graphical audio CD ripper and encoder

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/asunder/asunder_3.0.1+ds-1.dsc

Changes since the last upload:

 asunder (3.0.1+ds-1) unstable; urgency=medium
 .
   * New upstream release 3.0.1 (Fixes CDDB upload)
   * Add missing docs to binary package

Regards,
--
  Peter Blackman

Bug#1051910: (no subject)

[OSSMirror@OnboardCloud]

Hi,

May we enquire on the status of this request please?

Thanks and best regards,

Bug#1052121: RFS: yubioath-desktop/5.1.0-1.1 [NMU] [RC] -- Graphical interface for displaying OATH codes with a Yubikey

[Bo YU]

Package: sponsorship-requests
Severity: important


Dear mentors,

I am looking for a sponsor for my package "yubioath-desktop":

 * Package name : yubioath-desktop
   Version  : 5.1.0-1.1
   Upstream contact : d...@yubico.com
 * URL  : https://developers.yubico.com/yubioath-desktop/
 * License  : Apache-2.0, BSD-2-clause, Expat
 * Vcs  : https://salsa.debian.org/auth-team/yubioath-desktop
   Section  : utils

The source builds the following binary packages:

  yubioath-desktop - Graphical interface for displaying OATH codes with a 
Yubikey

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

  https://mentors.debian.net/package/yubioath-desktop/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/y/yubioath-desktop/yubioath-desktop_5.1.0-1.1.dsc

Changes since the last upload:

 yubioath-desktop (5.1.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add 02-fix-gcc-13 patch to fix gcc-13 build issue, thanks
 Jonathan Bergh  also. (Closes: #1037909)

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Marco d'Itri]

On Sep 17, Bill Allombert  wrote:

> Does not that would break users expectation that the system image contains 
> /var
> before the first boot ?
I am not aware of such expectations.

> A lot of things in /var are caches that are mostly instance-independent and 
> can
> be prefilled, but for that, users expect a minimal directory hierarchy to be
> present before first boot.
Can you show some examples of how this would work in practice?

> It seems your scheme favors some usecase over some others.
There are always tradeoffs, but my use case does not forbid the other 
one: worst case it requires one more mkdir while copying that data.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1051371: Post-/usr-merge paths for script interpreters

[Russ Allbery]

Ansgar  writes:

> But the subject of this issue talks about "script interpreters", not
> just `/bin/sh` (which I guess is safe to assume would be one of the
> "handful").

> It is unclear what files the Jackson symlink farm proposal would leave
> in /bin.  Would /bin/python3 stay?  Or would it stay first, but dropped
> at some later point?  What about /bin/perl, /bin/zsh, /bin/env, ...?

Oh, okay, I see what you're syaing now.  This is a bit beyond the scope of
the areas of Policy touched by Luca's proposal, but I can see why it would
indeed arise under Ian's proposal.  We've introduced new /bin interfaces
for every binary in /usr/bin, and if we went down that path we'd remove
most of those interfaces again.  That is indeed an argument for (c) for
*most* things, just not the areas touched by this diff (with the possible
exception of /bin/csh; I'm not sure if that would qualify for an exception
or not, these days).

So yes, I agree that the resolution of this bug would significantly affect
what we want to say in Policy about /usr-merge in general, even if not
what we say about /bin/sh.

I still don't feel like we need to wait for the TC bug to be resolved,
since there is a standing TC decision to make /bin a symlink to /usr/bin
and we can always change our wording later if that decision changes, but
we need to wait for the buildd /usr-merge anyway, so either way I don't
think we're ready to merge patches for this bug right now.

-- 
Russ Allbery (r...@debian.org)  

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Bill Allombert  writes:
> On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
>> On Sep 17, Russ Allbery  wrote:

>>> (I am a little confused by this wording, but I think what you're
>>> saying is that /usr is encrypted and read-only, and /var is recreated
>>> on each boot.  That at least is my understanding of the pattern that
>>> you're trying to enable.)

>> The general idea is to be able to create /var on the first boot.

> Does not that would break users expectation that the system image
> contains /var before the first boot ?

> A lot of things in /var are caches that are mostly instance-independent
> and can be prefilled, but for that, users expect a minimal directory
> hierarchy to be present before first boot.

Not that I think we're particularly close to achieving this design
currently (and to be clear we haven't decided we're working towards this
yet), but while I understand why a user would have that expectation today,
I'm not sure why it would practically matter.  If all of that directory
structure appears on first boot, and no static data is stored in /var,
what use case requires the directory structure already exist in /var
before the first boot?

I think you're thinking of cases where the user puts data into /var and
expects it to be used by the system after boot, but configuration data
would go into /etc, so I'm not sure what data that would be.

Also, I think that scenario would still work.  My understanding of the
design is that /var isn't tmpfs; while there's no precreated directory
structure, the user could still make one if they wanted.  There wouldn't
be the guide of existing empty directories, but this is a fairly
sophisticated use case, IMO.

-- 
Russ Allbery (r...@debian.org)  

Bug#1052120: mirror submission for mirror.timkevin.us

[Tim Kevin]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.timkevin.us
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Maintainer: Tim Kevin 
Country: US United States
Location: San Jose, CA
Comment: https://mirror.timkevin.us/debian
 http://mirror.timkevin.us/debian




Trace Url: http://mirror.timkevin.us/debian/project/trace/
Trace Url: http://mirror.timkevin.us/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.timkevin.us/debian/project/trace/mirror.timkevin.us

Bug#1050515: gtk-sharp3: Move to GtkSharp upstream

[Bastian Germann]

On Thu, 07 Sep 2023 09:26:48 +0200 Jordi Mallach wrote:

Is anyone working on this? I can devote some time to it.


Please do so. I do not have the impression that the Mono team is active in any 
way.

Bug#1052119: autopkgtest in experimental: sometimes just fails for rust libraries with "crate directory not found"

[Matthias Geiger]

Package: autopkgtest
Version: 5.28
Severity: normal
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainers,

I ran into this issue for the second time now. When I uploaded the gtk-rs
crates to experimental the CI passes for most crates. But some just fail with
"crate directory not found" :



208s Removing autopkgtest-satdep (0) ...
208s autopkgtest [19:41:32]: test librust-rustix-dev:: 
/usr/share/cargo/bin/cargo-auto-test rustix 0.38.9 --all-targets 
--no-default-features
208s autopkgtest [19:41:32]: test librust-rustix-dev:: [---
208s crate directory not found: /usr/share/cargo/registry/rustix-0.38.9
208s autopkgtest [19:41:32]: test librust-rustix-dev:: ---]
208s autopkgtest [19:41:32]: test librust-rustix-dev::  - - - - - - - - - - 
results - - - - - - - - - -
208s librust-rustix-dev:  FLAKY non-zero exit status 1
208s autopkgtest [19:41:32]:  summary
208s rust-rustix:@FLAKY non-zero exit status 1
208s librust-rustix-dev:all-apis FLAKY non-zero exit status 1
208s librust-rustix-dev:cc FLAKY non-zero exit status 1
208s librust-rustix-dev:compiler_builtins FLAKY non-zero exit status 1
208s librust-rustix-dev:core FLAKY non-zero exit status 1
208s librust-rustix-dev:default FAIL non-zero exit status 1




111s autopkgtest [09:47:48]: test librust-pango-dev:: 
/usr/share/cargo/bin/cargo-auto-test pango 0.18.0 --all-targets 
--no-default-features
111s autopkgtest [09:47:48]: test librust-pango-dev:: [---
111s crate directory not found: /usr/share/cargo/registry/pango-0.18.0
111s autopkgtest [09:47:48]: test librust-pango-dev:: ---]
111s autopkgtest [09:47:48]: test librust-pango-dev::  - - - - - - - - - - 
results - - - - - - - - - -
111s librust-pango-dev:   FAIL non-zero exit status 1



- From my limited observation this only happens in experimental for rust
crates. I don't know what causes this. The autopkgtest ran fine when I
built the packages before uploading.

best,

Matthias


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

Kernel: Linux 6.4.12-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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 autopkgtest depends on:
ii  apt-utils   2.6.1
ii  libdpkg-perl1.21.22
ii  procps  2:4.0.2-3
ii  python3 3.11.4-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.31-1.2

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  lxc  
pn  lxd  
ii  ovmf 2022.11-6
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.5
ii  qemu-efi-aarch64 2022.11-6
ii  qemu-efi-arm 2022.11-6
pn  qemu-system  
ii  qemu-utils   1:7.2+dfsg-7+deb12u1
ii  schroot  1.6.13-3+b2
ii  util-linux   2.38.1-5+b1
ii  vmdb20.27+really.0.26-1
pn  zerofree 

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmUHGVcVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1plkQAJP5UBtfVDut8goSUToOd7fP7yP6
pJ62nOzrpYaQG0RkfZ5eHg7GQrR7xtaeM3ASZCLKBH67Z9x0CxnRDP8rmvgyqkhq
udyi8TCyblg37aZZvXG4c8MmiKioaXvMVar3HMpzLpgC323l74O5i+D+oAiZVGvO
7zWntNJAxKRupKOuxHUxKiHMNchxXSghEQlusCbNOazGm/I/EOD1WKFsh2QsC8bX
RKcifAGtuZeUcdZTaEpK5wA2VB/lb5kq9vQQgnIWpjy3Y2uDCHWOow+kL7xVaNex
W5+Nu+MSNLM9heqRCVprf/YaeUVAUF4IoKm8p8PSDFusNCz4U4sexUxd92luSg11
X9dBm1LNS5NcQJcCaQq/nJmIS24x+pvqGlsTHUQ3VolMXycqqfyiWWd0FFKnv5a7
d8a6l9oK8in8cV3qzN9upAVBIX81BJm1srQgJfjRDjm4uoNebQSktqPyPBamoTQB
Uw4g9yg4xQcA/Tayg6XGR6741YbnNf7ecaJEtgYp76U4+owilyariQa9Jld0qzOI
USM2D/iWiF6Ygknk4xqcd8tWJLZvY5UuCulPx6ycHVTAk9ZddxmHbeKs5VKj1RhV
ApZVjnDLrFGjK5Ed4RJ5QgwgbCmwiVUwV/VihnODeMiT/y8Xgy1vA/WjJoowHbAD
uSCj6Mrw+HiUAW5w
=EqvW
-END PGP SIGNATURE-

Bug#1052082: bullseye-pu: package rust-cbindgen/0.24.3-2~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-09-17 at 11:36 +0200, Emilio Pozuelo Monfort wrote:
> This updates rust-cbindgen to 0.24, as required by Firefox ESR 115.
> The risk is low as the only (build)rdep of cbindgen are firefox-esr
> and thunderbird.
> 
> Attached is a debian/ diff of the update.
> 

-  * Only build the cbindgen binary.

afaict that's still true, so maybe the changelog entry should still be
present?

In any case, please go ahead.

Regards,

Adam

Bug#967259: asunder depends on gtk2

[Peter B]

Hi Matthias, Bastian,

I'd prefer to retain asunder for the time being.
If bugs are reported in grimripper that I can't reproduce,
it would be very helpful to ask the reporter if the same problem happens with 
asunder.
That will be problematic if its been removed from the archive.


I'd also like to see a much wider take-up, freedom from bugs, and more upstream 
support,
before burning the boats with respect to asunder.

Currently, there are no other official grimripper packages in the 'nix world.
https://repology.org/project/grimripper/versions

This CTD bug reported in May, is still not fixed upstream.
https://gitlab.gnome.org/Salamandar/GrimRipper/-/issues/8
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040980


Asunder is seeing some upstream activity now,
so there is still a possibility of a switch to gtk3, before gtk2 is removed 
from Debian


Cheers,
Peter

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Salvatore Bonaccorso]

Hi Simon,

On Sun, Sep 17, 2023 at 03:12:00PM +0100, Simon McVittie wrote:
> On Sat, 16 Sep 2023 at 22:53:55 +0200, Salvatore Bonaccorso wrote:
> > The following vulnerability was published for gnome-shell.
> > 
> > CVE-2023-43090[0]:
> > | Screenshot tool allows viewing open windows when session is locked
> 
> Thank you for reporting this. I'm preparing a 44.5 upload for unstable now,
> after which I will look at fixes for older suites.

Thanks!

> Does the security team intend to issue a DSA for this? It would be really
> helpful if CVE reports from the security team could explicitly mention the
> DSA status (wanted / not planned / undecided) so that maintainers can do
> the right thing (preparing a security upload or a stable-proposed-updates
> upload), without always needing an extra email round-trip to ask what the
> right thing is going to be.

I can understand the desire; usually our triaging process for things
which are unfixed yet in the topmost unstable suite, are first
reported (to make maintainers aware in case they do not know yet),
then an orthogonal step might be to assess the package.

In case it is already decided to not handle it via a DSA then a no-dsa
tagged entry would be found in the security-tracker.

In this case we even not have yet decided if it's warranted or not,
but I just aimed to make an unstable report to get it for sure fixed
there already.

Lets decide on it and either me or another team member will come back
to you.

Regards,
Salvatore

Bug#1013436: autopkgtest: Building of qemu images fails

[David Bremner]

David Bremner  writes:


>
> This is still happening with 5.30.

FWIW, my command line was

sudo autopkgtest-build-qemu sid autopkgtest-sid-i386 
https://deb.debian.org/debian i386

Bug#1052029: c-evo-dh: depends on deprecated GTK 2

[Peter B]

On 16/09/2023 11:31, Bastian Germann wrote:

Please consider switching to lcl=qt5 to build with qt5 interface.
Please rename c-evo-dh-gtk2 to c-evo-dh when implementing this. We really
do not need to know the toolkit that it uses by looking at the pkg name.


Hi Bastian,

Lazarus can build packages against various toolkits, and if more than one is 
viable,
building those gives users some choice, as they all have various quirks.
The toolkit in the package name allows that differentiation.

C-evo-dh will build against all supported Lazarus toolkits, however,
gtk3 & fpgui builds crash on startup, and qt5 & qt6 have corrupted graphics.
gtk2 is the only Linux toolkit version that currently runs OK.

C-evo-dh has been intentionally packaged to allow co-installation of multiple 
front-ends.
I will certainly include others when they become viable.
I tested the Qt6 build today with Lazarus 3.0RC1, but have the same display 
issues as with Qt5.
gtk3 is being worked on upstream. That may become a possibility.

Cheers,
Peter

Bug#1052118: strace: please upgrade to 6.5

[Bo YU]

Package: strace
Version: 6.4-0.1
Severity: wishlist

Dear Maintainer,

as promise for #1043393, I've been watching to see if I could enable
test cases fatal on riscv64 again. But it seems the kernel was not ready
fot it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cd479d9c72681606cbfaf1b77629187fe904cbee
https://lore.kernel.org/lkml/169228562477.20811.12846984495723558384.git-patchwork-not...@kernel.org/T/

But I would like to upgrade strace to 6.5 first as bonus.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1013436: autopkgtest: Building of qemu images fails

[David Bremner]

"Roberto C. Sanchez"  writes:
>
> Attempting to build qemu images fails as follows:
>
> roberto@debian:~$ sudo autopkgtest-build-qemu buster ./autopkgtest-buster.img
> Load spec file /tmp/user/0/tmph19aaviw/vmdb2.yaml
> Exec: ['dpkg', '--print-architecture']
> Exec: ['qemu-img', 'create', '-f', 'raw', './autopkgtest-buster.img.raw', 
> '25G']
> Exec: ['parted', '-s', './autopkgtest-buster.img.raw', 'mklabel', 'msdos']
> Exec: ['parted', '-m', '/home/roberto/autopkgtest-buster.img.raw', 'print']
> Exec: ['parted', '-s', '/home/roberto/autopkgtest-buster.img.raw', '--', 
> 'mkpart', 'primary', 'ext2', '0%', '100%']
> Exec: ['parted', '-m', '/home/roberto/autopkgtest-buster.img.raw', 'print']
> Exec: ['kpartx', '-asv', './autopkgtest-buster.img.raw']
> remembering /dev/mapper/loop0p1 as root
> Exec: ['/sbin/mkfs', '-t', 'ext4', '/dev/mapper/loop0p1']
> Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/user/0/tmpllucvne5']
> Exec: ['debootstrap', '--variant', '-', 'buster', '/tmp/user/0/tmpllucvne5', 
> 'http://deb.debian.org/debian']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'apt-get', 'update']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'apt-get', 'update']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'apt-get', '-y', 
> '--no-show-progress', 'install', 'eatmydata']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'eatmydata', 'apt-get', 'update']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'eatmydata', 'apt-get', '-y', 
> '--no-show-progress', 'install', 'linux-image-amd64', 'ifupdown']
> ERROR:root:Program failed: 100
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/vmdb/app.py", line 220, in 
> run_steps_helper
> method(values, settings, state)
>   File "/usr/lib/python3/dist-packages/vmdb/plugins/apt_plugin.py", line 47, 
> in run
> self.install_packages(mount_point, ["eatmydata"], packages)
>   File "/usr/lib/python3/dist-packages/vmdb/plugins/apt_plugin.py", line 61, 
> in install_packages
> vmdb.runcmd_chroot(
>   File "/usr/lib/python3/dist-packages/vmdb/runcmd.py", line 64, in 
> runcmd_chroot
> return runcmd(full_argv, *argvs, **kwargs)
>   File "/usr/lib/python3/dist-packages/vmdb/runcmd.py", line 58, in runcmd
> raise RuncmdError("Program failed: {}".format(p.returncode))
> vmdb.runcmd.RuncmdError: Program failed: 100

This is still happening with 5.30.

Load spec file /tmp/tmp9w769cua/vmdb2.yaml
Exec: ['dpkg', '--print-architecture']
Exec: ['qemu-img', 'create', '-f', 'raw', 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', '25G']
Exec: ['parted', '-s', '/home/bremner/var/images/autopkgtest-sid-i386.raw', 
'mklabel', 'msdos']
Exec: ['parted', '-m', '/home/bremner/var/images/autopkgtest-sid-i386.raw', 
'print']
Exec: ['parted', '-s', '/home/bremner/var/images/autopkgtest-sid-i386.raw', 
'--', 'mkpart', 'primary', 'ext2', '0%', '100%']
Exec: ['parted', '-m', '/home/bremner/var/images/autopkgtest-sid-i386.raw', 
'print']
Exec: ['kpartx', '-asv', '/home/bremner/var/images/autopkgtest-sid-i386.raw']
remembering /dev/mapper/loop0p1 as root
Exec: ['/sbin/mkfs', '-t', 'ext4', '-O', '^large_dir', '-O', 
'^metadata_csum_seed', '/dev/mapper/loop0p1']
Exec: ['blkid', '-c/dev/null', '-ovalue', '-sUUID', '/dev/mapper/loop0p1']
Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmppt5v6frz']
Exec: ['qemu-debootstrap', '--arch', 'i386', '--variant', '-', '--components', 
'main', 'sid', '/tmp/tmppt5v6frz', 'https://deb.debian.org/debian']
ERROR: [Errno 2] No such file or directory: 'qemu-debootstrap'
ERROR: FileNotFoundError(2, 'No such file or directory')
Something went wrong, cleaning up!
Exec: ['zerofree', '-v', '/dev/mapper/loop0p1']
ERROR: [Errno 2] No such file or directory: 'zerofree'
ERROR: FileNotFoundError(2, 'No such file or directory')
Exec: ['kpartx', '-dsv', '/home/bremner/var/images/autopkgtest-sid-i386.raw']
Exec: ['losetup', '--json', '-l', '/dev/loop0']
2023-09-17 11:32:21 INFO Starting vmdb2 version 0.26
2023-09-17 11:32:21 INFO Load spec file /tmp/tmp9w769cua/vmdb2.yaml
2023-09-17 11:32:21 INFO Exec: ['dpkg', '--print-architecture']
2023-09-17 11:32:21 DEBUG STDOUT: amd64

2023-09-17 11:32:21 DEBUG STDERR: 
2023-09-17 11:32:21 INFO Running step: {'mkimg': 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', 'size': '25G'}
2023-09-17 11:32:21 INFO Calling >
2023-09-17 11:32:21 INFO Exec: ['qemu-img', 'create', '-f', 'raw', 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', '25G']
2023-09-17 11:32:21 DEBUG STDOUT: Formatting 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', fmt=raw size=26843545600

2023-09-17 11:32:21 DEBUG STDERR: 
2023-09-17 11:32:21 INFO Calling >
2023-09-17 11:32:21 INFO Running step: {'mklabel': 'msdos', 'device': 
'/home/bremner/var/images/autopkgtest-sid-i386.raw'}
2023-09-17 11:32:21 INFO Calling >
2023-09-17 11:32:21 INFO Exec: ['parted', '-s', 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', 'mklabel', 'msdos']
2023-09-17 11:32:21 DEBUG STDOUT: 
2023-09-17 11:32:21 DEBUG STDERR: 
2023-09-17 11:32:21 INFO 

Bug#1041982: [pkg-php-pear] Upcoming transitions (Symfony, PHPUnit, etc.)

[David Prévot]

Hi,

> Le 24/06/2023 à 01:29, William Desportes a écrit :
[…]
> Great, #1041982 does not have much blockers anymore, maybe we can schedule
> the transition then.

FYI, we had a workshop during DebConf with Athos in order to try and
determine what other packages (and relevant blockers) need to be
uploaded from experimental to unstable in order to perform this
transition.

So far, only the four following versioned packages have been determined
as needed in sync with Symfony.

php-symfony-contracts (>= 3)
php-psr-cache (>= 3)
php-psr-container (>= 2)
php-psr-log (>=3)

That led us to notice other packages will become uninstallable (due to
the version constraints), or simply broken. A few more bugs have been
open in this regard (blocking this transition bug), but roughly, the
following end user packages (families) are not yet ready.

civicrm (#1051988)
kanboard (#1051989 and php-pimple)
Laravel (#1051985 and #1039731, and php-faker)
shaarli (#1039733 and php-slim, php-pimple)

civicrm is not in stable (only recently migrated again to testing after
a php-log fix, Dmitry CCed anyway). Laravel was removed from testing
during the previous symfony 5 transition, Robin already explicitly
agreed that can be Laravel can be removed again from testing until a new
upstream version is packaged.

I don’t know if there are strong opinions about kanboard and shaarli,
Joseph and James CCed.

Some bugs are still to be filled (e.g., php-faker, php-slim, and
php-pimple), but it may already be time to raise the severity of the
blocking bugs.

Regards,

taffit

P.-S.: Pad used to track issues during DebConf.

https://pad.dc23.debconf.org/p/symfony6

Athos may try to rebuild packages also depending on recent version of
php-symfony-contracts, php-psr-cache, php-psr-container and php-psr-log
in order to figure out if more package are affected by this transition.


signature.asc
Description: PGP signature

Bug#1052067: gnome-shell: CVE-2023-43090: screenshot tool allows viewing open windows when session is locked

[Simon McVittie]

On Sat, 16 Sep 2023 at 22:53:55 +0200, Salvatore Bonaccorso wrote:
> The following vulnerability was published for gnome-shell.
> 
> CVE-2023-43090[0]:
> | Screenshot tool allows viewing open windows when session is locked

Thank you for reporting this. I'm preparing a 44.5 upload for unstable now,
after which I will look at fixes for older suites.

Does the security team intend to issue a DSA for this? It would be really
helpful if CVE reports from the security team could explicitly mention the
DSA status (wanted / not planned / undecided) so that maintainers can do
the right thing (preparing a security upload or a stable-proposed-updates
upload), without always needing an extra email round-trip to ask what the
right thing is going to be.

smcv

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Harlan Lieberman-Berg]

On Sun, Sep 17, 2023 at 12:13 PM Simon McVittie  wrote:
> If you run as root
>
> update-alternatives --set gdm-smartcard 
> /etc/pam.d/gdm-smartcard-sssd-or-password
>
> does that restore previous functionality?

Sort of!  It doesn't fix the changes to the UI (i.e., there is no
longer a list of users to select from; it is a username box where the
"go back" button does nothing), but you can login by putting the
username in by hand.  That part is, obviously, the most important one.

Is the issue here one of defaults (e.g., the wrong PAM profile being
set), or one of detection (are smartcards a valid choice at all)?

Potentially unrelated sidenote: setting
`/org/gnome/login-screen/enable-smartcard-authentication` to `false`
has no effect on the ability to login; it still refuses to allow
password auth.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1052117: ITP: frappe-bench -- CLI to manage Multi-tenant deployments for Frappe apps

[Arun Mathai]

Package: wnpp
Severity: wishlist
Owner: Arun Mathai 
X-Debbugs-Cc: debian-de...@lists.debian.org, m...@arunmathaisk.in

* Package name: frappe-bench
  Version : 5.17.2
* URL : https://github.com/frappe/bench
* License : GPL-3
  Programming Lang: Python
  Description : CLI to manage Multi-tenant deployments for Frappe apps

Bench is a command-line utility that helps you to install, update, and manage 
multiple sites for Frappe/ERPNext applications on *nix systems for development 
and production.

Bug#1052116: Removing the udev init script breaks sysv bootup.

[pthfdr]

Package: udev
Version: 254.3-1

The 254.3-1 update of udev removed the init script "/etc/init.d/udev".
On systems with "sysvinit-core" as init, removing the script causes udev 
no longer starting on boot, which makes the system inoperable since 
important device drivers (like GPUs and keyboards/mice) are no longer 
loaded.

Bug#1052115: workrave-gnome: needs update for GNOME Shell 45

[Simon McVittie]

Package: workrave-gnome
Version: 1.10.51.1-3
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052114: gnome-shell-pomodoro: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-pomodoro
Version: 0.23.1-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052113: gnome-shell-mailnag: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 40.0-4
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052112: gnome-shell-extensions-extra: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extensions-extra
Version: 20230618-3
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developers might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052111: gnome-shell-extension-weather: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-weather
Version: 121-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052110: gnome-shell-extension-vertical-overview: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-vertical-overview
Version: 10-2
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052107: gnome-shell-extension-shortcuts: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-shortcuts
Version: 1.3.7-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052109: gnome-shell-extension-tiling-assistant: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-tiling-assistant
Version: 41-3
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052108: gnome-shell-extension-system-monitor: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-system-monitor
Version: 40-6
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052106: gnome-shell-extension-runcat: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-runcat
Version: 23-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052105: gnome-shell-extension-no-annoyance: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-no-annoyance
Version: 0+20220925-c6804a4-3.1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052104: gnome-shell-extension-impatience: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-impatience
Version: 0.4.8-3
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052103: gnome-shell-extension-hide-activities: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-hide-activities
Version: 44-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052102: gnome-shell-extension-hard-disk-led: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-hard-disk-led
Version: 34-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052101: gnome-shell-extension-hamster: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-hamster
Version: 0.10.0+git20230901-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052100: gnome-shell-extension-gsconnect: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-gsconnect
Version: 55-3
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052099: gnome-shell-extension-gpaste: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-gpaste
Version: 44.1-2
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052098: gnome-shell-extension-gamemode: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-gamemode
Version: 8-3
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052097: gnome-shell-extension-freon: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-freon
Version: 52+dfsg-2
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1052095: gnome-shell-extension-espresso: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-espresso
Version: 8-2
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

There does not seem to have been any work upstream yet on GNOME 45 support.

This particular extension is redundant with g-s-e-caffeine. I originally
uploaded it because g-s-e-caffeine seemed to be unmaintained, but actually
g-s-e-caffeine seems to be updating to new GNOME releases faster than
g-s-e-espresso, so it might make more sense to remove -espresso and only
keep -caffeine.

smcv

Bug#1052096: gnome-shell-extension-flypie: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-extension-flypie
Version: 22-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv