Bug#996869: mail.debian.org: https://postgrey.schweikert.ch/help/bugs.debian.org.html contact email broken

[Thomas Groman]

Package: buxtehude.debian.org
Severity: normal
Tags: a11y

Dear Maintainer,

Upon sending to b...@debian.org I encountered the following message in my log 
files:
"relay="[2607:f8f0:614:1::1274:39] (buxtehude.debian.org)" delay=5s 
result="TempFail" stat="451 Greylisted, see 
http://postgrey.schweikert.ch/help/bugs.debian.org.html;

Upon going to the URL listed it has a friendly webpage Postgrey help with 
information on who to contact for help. The email listed for contact is "[email 
protected]". 
[email protected] is not a valid email address and should anyone attempt to 
email [email protected] mail would not go through and help would not be 
recieved.

I expect the postgrey help contact to be a valid email address that goes to the 
maintainer of the system where the error occured, in this case 
buxtehude.debian.org. Preferably using the mailto: URL schema inside of an 
XHTML anchored hyperlink.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera)
Release:4
Codename:   chimaera
Architecture: x86_64

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#996874: RM: theme-d-gnome -- ROM; Not compatible with Guile 3.0

[Tommi Höynälänmaa]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: tommi.hoynalan...@iki.fi

Theme-D-Gnome is not compatible with Guile 3.0 and conflicts with theme-d
4.0.3-1.

Bug#617856: New version of apt-show-versions fixes 617856

[Paul Wise]

On Fri, 8 Oct 2021 11:31:39 +0200 Christoph Martin wrote:

> tags 617856 + pending
> thanks
> 
> Upload of new version is pending.

Could you upload the package?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#983505: doas: persist option still does not work

[Thomas Groman]

I am writing to inform that this bug still persists

Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera)
Release:4
Codename:   chimaera
Kernel: Linux 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64
GNU/Linux
Package: doas
Version: 6.8.1-2
Priority: optional
Section: admin
Maintainer: Scupake 
Installed-Size: 69.6 kB
Depends: libc6 (>= 2.26), libpam0g (>= 0.99.7.1)
Homepage: https://github.com/Duncaen/OpenDoas
Download-Size: 21.1 kB
APT-Manual-Installed: yes
APT-Sources: http://pkgmaster.devuan.org/merged chimaera/main amd64
Packages


pgplyikUbPRNx.pgp
Description: OpenPGP digital signature

Bug#996873: Add link to emails: "this reply contains spam"

[積丹尼 Dan Jacobson]

Package: bugs.debian.org

Got a mail (I chopped it):

From: "Elizab
Subject: Bug#
To: "476519-s
Date: Wed, 20
Reply-To: "el
Resent-From:
Attachment: [

1.  ( ) text/

Hallo, ich bi
USD anbieten.

Elizabeth Liu

Wouldn't it be great if at the bottom there was a link "Report ... spam".

Bug#821063: signal SIGPIPE, Broken pipe

[Paul Wise]

On Fri, 15 Apr 2016 06:59:14 +0200 Jörg Frings-Fürst wrote:

>  Starting program: /usr/bin/owncloud
...
> Program received signal SIGPIPE, Broken pipe.

Please test the new version of owncloud-client available in Debian
experimental and reply to the bug whether this issue is fixed yet.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#996744: kde-config-gtk-style: Version mismatch segfaults kded5 repeatedly

[Patrick Häcker]

Hello Bernhard,

yes, thanks, it probably is the same, although in my journal I have traps from
kded5 and not from kde5, but this is probably a copy-paste issue in #996726.
Unfortunately, it's not mentioned, what the fix was, but when I look at the
diffoscope of 4:5.23.0-2 and 4:5.23.0-3 it looks like 4:5.23.0-3 would solve
this issue, too, as the main change is to tighten the breaks
>Breaks: kwin-common (<< 4:5.22.90), kwin-decoration-oxygen (<< 4:5.22.90),
kwin-style-breeze (<< 4:5.22.90), kwin-wayland (<< 4:5.22.90), kwin-wayland-
backend-drm (<< 4:5.22.90), kwin-wayland-backend-fbdev (<< 4:5.22.90), kwin-
wayland-backend-virtual (<< 4:5.22.90), kwin-wayland-backend-wayland (<<
4:5.22.90), kwin-wayland-backend-x11 (<< 4:5.22.90), kwin-x11 (<< 4:5.22.90)

So the specific problem is solved. The question is, whether the implicitly
mentioned general problem should be solved, too. Even with this change you'd
get a mix of 5.21 and 5.23 when installing a specific kde-plasma-desktop
package (see my list above in 996744). In this case this mix seems to work,
however, do we really have the man-power to support these mixes in the future?
And do we think that's what the user wants? Even in #996726 it's mentioned,
that you should always upgrade the entire stack. Why don't we set the package
metadata to guarantee that for the user and use our time for fixing real
problems instead of package version mismatches?

Kind regards
Patrick


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

Bug#996867: openjdk-17-jre-headless: Update to version "17+35"

[anna]

Package: openjdk-17-jre-headless
Version: 17~19-1
Severity: normal

Dear Maintainer,

As the bullseye version is still ea "17+19" but "17+35" is the final
release and already in bookworm, it would be nice if the package would
be updated.
If it is not possible, please, provide an update through backports.

Thanks for packaging openjdk for Debian.

Regards Anna


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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 openjdk-17-jre-headless depends on:
ii  ca-certificates-java  20190909
ii  java-common   0.72
ii  libasound21.2.4-1.1
ii  libc6 2.31-13+deb11u2
ii  libcups2  2.3.3op2-3+deb11u1
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libharfbuzz0b 2.7.4-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblcms2-22.12~rc1-2
ii  libnss3   2:3.61-1
ii  libpcsclite1  1.9.1-1
ii  libstdc++610.2.1-6
ii  util-linux2.36.1-8
ii  zlib1g1:1.2.11.dfsg-2

openjdk-17-jre-headless recommends no packages.

Versions of packages openjdk-17-jre-headless suggests:
ii  fonts-dejavu-extra 2.37-2
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
ii  libnss-mdns0.14.1-2

-- no debconf information

Bug#996872: librsvg2-bin: stroke-dasharray rendered wrong

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal

% cat a.svg



% rsvg-convert -f pdf -o a.pdf a.svg
%

The resulting PDF (attached) contains a thin line across the part of
the path that should not be drawn.

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

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librsvg2-bin depends on:
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  librsvg2-22.50.3+dfsg-1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information


a.pdf
Description: Adobe PDF document

Bug#996870: libapache2-mod-php7.4: Unable to Load Apache2 Service

[Bite Gao]

Package: libapache2-mod-php7.4
Version: 7.4.21-1+deb11u1
Severity: important
Tags: a11y
X-Debbugs-Cc: t...@security.debian.org

Maintainers,
  Hello! I am unable to start apache2 server due to a moudle that is unable to 
load.
I believe that this moudle has some programming issues. I sincerly hopes
that you can fix this moudle so that such problem would not occur again.

Best Wishes,
refrog2000
Oct 20th, 2021

Attachments:
-- Package-specific info:
 Additional PHP 7.4 information 

 PHP 7.4 SAPI (php7.4query -S): 

 PHP 7.4 Extensions (php7.4query -M -v): 

 Configuration files: 
[PHP]
engine = On
short_open_tag = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = -1
disable_functions = 
pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare,
disable_classes =
zend.enable_gc = On
zend.exception_ignore_args = On
expose_php = Off
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
default_charset = "UTF-8"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
[CLI Server]
cli_server.color = On
[Date]
[filter]
[iconv]
[imap]
[intl]
[sqlite3]
[Pcre]
[Pdo]
[Pdo_mysql]
pdo_mysql.default_socket=
[Phar]
[mail function]
SMTP = localhost
smtp_port = 25
mail.add_x_header = Off
[ODBC]
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
[MySQLi]
mysqli.max_persistent = -1
mysqli.allow_persistent = On
mysqli.max_links = -1
mysqli.default_port = 3306
mysqli.default_socket =
mysqli.default_host =
mysqli.default_user =
mysqli.default_pw =
mysqli.reconnect = Off
[mysqlnd]
mysqlnd.collect_statistics = On
mysqlnd.collect_memory_statistics = Off
[OCI8]
[PostgreSQL]
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
[bcmath]
bcmath.scale = 0
[browscap]
[Session]
session.save_handler = files
session.use_strict_mode = 0
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.cookie_samesite =
session.serialize_handler = php
session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 1440
session.referer_check =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.sid_length = 26
session.trans_sid_tags = "a=href,area=href,frame=src,form="
session.sid_bits_per_character = 5
[Assertion]
zend.assertions = -1
[COM]
[mbstring]
[gd]
[exif]
[Tidy]
tidy.clean_output = Off
[soap]
soap.wsdl_cache_enabled=1
soap.wsdl_cache_dir="/tmp"
soap.wsdl_cache_ttl=86400
soap.wsdl_cache_limit = 5
[sysvshm]
[ldap]
ldap.max_links = -1
[dba]
[opcache]
[curl]
[openssl]
[ffi]

 /etc/php/7.4/apache2/conf.d/20-sysvmsg.ini 
extension=sysvmsg.so

 /etc/php/7.4/apache2/conf.d/20-gettext.ini 
extension=gettext.so

 /etc/php/7.4/apache2/conf.d/20-shmop.ini 
extension=shmop.so

 /etc/php/7.4/apache2/conf.d/20-tokenizer.ini 
extension=tokenizer.so

 /etc/php/7.4/apache2/conf.d/20-mysqli.ini 
extension=mysqli.so

 /etc/php/7.4/apache2/conf.d/20-iconv.ini 
extension=iconv.so

 /etc/php/7.4/apache2/conf.d/20-exif.ini 
extension=exif.so

 /etc/php/7.4/apache2/conf.d/20-fileinfo.ini 
extension=fileinfo.so

 /etc/php/7.4/apache2/conf.d/20-posix.ini 
extension=posix.so

 /etc/php/7.4/apache2/conf.d/20-ftp.ini 
extension=ftp.so

 /etc/php/7.4/apache2/conf.d/10-pdo.ini 
extension=pdo.so

 /etc/php/7.4/apache2/conf.d/20-json.ini 
extension=json.so

 /etc/php/7.4/apache2/conf.d/20-sysvshm.ini 
extension=sysvshm.so

 /etc/php/7.4/apache2/conf.d/20-sysvsem.ini 
extension=sysvsem.so

 /etc/php/7.4/apache2/conf.d/20-calendar.ini 
extension=calendar.so

 /etc/php/7.4/apache2/conf.d/10-opcache.ini 
zend_extension=opcache.so

 /etc/php/7.4/apache2/conf.d/20-ffi.ini 

Bug#958334: bruteforce-luks: is not valid luks volume or you don`t have permission to access it

[kretcheu]

Should you describe the problem?

What did you do?
What happened?
What do you expect to occur?

Thanks.
[]'s
kretcheu
:x


On Mon, 20 Apr 2020 18:14:53 +0200 strunz  wrote:
> Package: bruteforce-luks
> Version: 1.3.1-1+b1
> Followup-For: Bug #958334
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where
appropriate ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
>
> -- System Information:
> Debian Release: 10.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages bruteforce-luks depends on:
> ii  libc62.28-10
> ii  libcryptsetup12  2:2.1.0-5+deb10u2
>
> bruteforce-luks recommends no packages.
>
> bruteforce-luks suggests no packages.
>
> -- no debconf information
>
>

Bug#996858: libllvm12:i386 uninstallable and uninstall my desktop

[Antoine Le Gonidec]

Your issue (libllvm12:amd64 and libllvm12:i386 not co-installable) is most 
probably due to the i386 build of libllvm12 1:12.0.1-10 failing, leading to its 
absence from Debian Sid repositories. You can see more details about this build 
failure here: https://bugs.debian.org/996796

I expect libllvm12:i386 1:12.0.1-10 to be available as soon as #996796 is 
fixed. In the meantime, if you need this package in both architecture you would 
need to stay on 1:12.0.1-9 even for the amd64 build. You can download this 
package from snapshot.debian.org: 
https://snapshot.debian.org/package/llvm-toolchain-12/1%3A12.0.1-9/#libllvm12_1:3a:12.0.1-9



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996794: ncbi-acc-download: autopkgtest failure with python-biopython 1.79+dfsg-1~0exp0 in experimental

[Étienne Mollier]

Hi Aaron, Hi Andreas,

Andreas Tille, on 2021-10-19:
> Am Tue, Oct 19, 2021 at 07:55:07AM -0400 schrieb Aaron M. Ucko:
> > Étienne Mollier  writes:
> > 
> > >   E - LOCUS   NC_007194 60 bpDNA 
> > > linear   CON 03-APR-2018
> > >   E ?  ^^^
> > > ^^ ^^^   ^^
> > >   E + LOCUS   NC_0071944918979 bpDNA 
> > > linear   CON 11-NOV-2009
> > >   E ?  ^^^
> > > ^^ ^^^   ^^
> > 
> > It looks like this test is intended to work offline (as required) and
> > yield short mock records, but for some reason winds up fetching
> > full-length live data instead.

As always, thanks for your analysis!  I confirm the test suite
works offline, so withdraw my suspicion.

> Strangely enough this issue seems to depend from the biopython version.
> Any idea what might be wrong here?

After some digging, I found one possible cause of breakage.
Since biopython 1.79, Bio.Seq.UnknownSeq is deprecated [1], so
it might be possible that ncbi-acc-download does not parse the
instanciation of that class very well.

[1]: 
https://github.com/biopython/biopython/blob/master/DEPRECATED.rst#biosequnknownseq

Looks like I would want to take the issue upstream.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#996868: ITP: python-connection-pool -- thread-safe connection pool for python

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: python-connection-pool -- thread-safe connection pool for python
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-connection-pool
  Version : 0.0.3
  Upstream Author : ZhouYL <81438...@qq.com>
* URL : https://github.com/zhouyl/ConnectionPool
* License : Expat
  Programming Lang: Python
  Description : thread-safe connection pool for python
 This package provides a thread-safe connection pool for Python 3.
 These are sets database connections that are readily available 
 for anticipated repeated requests to the same database.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/python-team/packages/python-connection-pool

Bug#900287: owncloud-client-cmd requires /etc/owncloud-client/sync-exclude.lst and ~/.local/share/data/ownCloud/

[Paul Wise]

On Tue, 2021-10-19 at 13:31 -0600, Charles Curley wrote:

> Really?

owncloud-client was removed from Debian and then reintroduced back into
Debian, I was just doing reopening and triage of the bugs closed by the
removal of the package from Debian.

> After adding experimental to a stable (Bullseye) system, I ran:
...
> Even if the code is fine, the list of dependencies is unacceptable.

That is to be expected when mixing packages from different suites,
if it reaches backports then the deps should be more appropriate.

> This is running against a server Nextcloud 22.2.0. So it is possible
> that divergence between the server and client have made it impossible
> for me to test.

I see, thanks for trying anyway.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#996860: kded5: crash during init

[Bernhard Übelacker]

Control: merge -1 996859


Hello Achim,
I hope it is ok to try to merge those two bugs #996859 and #996860,
BTS takes some time to confirm creating a bug ...

Have you updated lately libkdecorations2-5v5 to 4:5.23.0-2 ?
Then you probably hit this bug #996726,
where a workaround is described by downgrading
to the package version before.

If you see a different issue, maybe you
could install systemd-coredump and provide the
output of "journalctl -e --no-pager" related to the crash.

Kind regards,
Bernhard


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996726

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

[Tianon Gravi]

(s/grub-efi/gnu-efi/ -- brain fart)

Looks like 
https://sourceforge.net/p/gnu-efi/code/ci/ce0bd62f5c420f0457c58c120497dc16d2e606dd/
is the relevant gnu-efi commit which introduced the new typedef, in
case that helps.

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

On Tue, 19 Oct 2021 at 17:07, Tianon Gravi  wrote:
>
> Hey Rod, this is an interesting one -- looking at the definitions of
> the "EFI_DEVICE_PATH_UTILITIES_PROTOCOL" typedef in both refind's code
> and grub-efi's, they appear to be compatible to me (which makes sense,
> probably from the same original source?)
>
> Is this something you plan to resolve in upstream refind source, or
> something we should patch around downstream in Debian?
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
>
> On Sun, 3 Oct 2021 at 04:15, Helmut Grohne  wrote:
> > Source: refind
> > Version: 0.12.0-1
> > Severity: serious
> > Tags: ftbfs
> >
> > refind fails to build from source in unstable on amd64 and it also fails
> > to cross build for arm64 for the same reason. A build ends as follows:
> >
> > | make[3]: Entering directory '/<>/EfiLib'
> > | /usr/bin/gcc -Os -fno-strict-aliasing -fno-tree-loop-distribute-patterns 
> > -fno-stack-protector -fshort-wchar -Wall -DEFIX64 -DEFI_FUNCTION_WRAPPER 
> > -m64 -mno-red-zone  -fpic -I/usr/include/efi -I/usr/include/efi/x86_64 
> > -I/usr/include/efi/protocol -I../include -I../refind -I../libeg -I../mok 
> > -I. -I./../include \
> > |   -D__MAKEWITH_GNUEFI -c gnuefi-helper.c -o gnuefi-helper.o
> > | In file included from gnuefi-helper.c:19:
> > | DevicePathUtilities.h:229:3: error: conflicting types for 
> > ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’
> > |   229 | } EFI_DEVICE_PATH_UTILITIES_PROTOCOL;
> > |   |   ^~
> > | In file included from /usr/include/efi/efi.h:61,
> > |  from gnuefi-helper.h:24,
> > |  from gnuefi-helper.c:18:
> > | /usr/include/efi/efidevp.h:648:3: note: previous declaration of 
> > ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’ was here
> > |   648 | } EFI_DEVICE_PATH_UTILITIES_PROTOCOL;
> > |   |   ^~
> > | make[3]: *** [../Make.common:164: gnuefi-helper.o] Error 1
> > | make[3]: Leaving directory '/<>/EfiLib'
> > | make[2]: *** [Makefile:86: gnuefi] Error 2
> > | make[2]: Leaving directory '/<>'
> > | dh_auto_build: error: make -j1 gnuefi ARCH=x86_64 returned exit code 2
> > | make[1]: *** [debian/rules:33: override_dh_auto_build] Error 25
> > | make[1]: Leaving directory '/<>'
> > | make: *** [debian/rules:26: build] Error 2
> > | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> > status 2
> >
> > Also seen by crossqa:
> > http://crossqa.debian.net
> >
> > Reproduced natively on arm64 by reproducible builds:
> > https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/refind_0.12.0-1.rbuild.log.gz
> >
> > Helmut
> >

Bug#996863: src:python-novaclient: fails to migrate to testing for too long: unresolved RC bug

[Thomas Goirand]

On 10/19/21 10:07 PM, Paul Gevers wrote:
> Source: python-novaclient
> Version: 2:17.2.1-3
> Severity: serious
> Control: close -1 2:17.6.0-2
> Tags: sid bookworm
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> Control: block -1 by 986143
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing
> and unstable for more than 60 days as having a Release Critical bug in
> testing [1]. Your package src:python-novaclient has been trying to
> migrate for 66 days [2]. Hence, I am filing this bug.

The link you're pointing to says 22 days, not 66 !!!

> I'm not sure if the blocking bug is even a bug in bookworm. If I
> understand it correctly, the issue reported there was purely for buster
> to bullseye upgrades and can be ignored afterwards. FYI, the BTS
> considers the bug affecting unstable because the version of the package
> in unstable is not a descendant of the fixed version (judged by parsing
> the changelog).

This looks like a correct analysis. So in fact, the only thing that
should be done is fix the BTS entry no? I'm not sure how...

> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.

IMO, that's not what's needed here. What's needed, is to tell the BTS
the package is working as expected, and should be migrating. IMO, the
bug you're opening is:
1/ not following the rules (because 22 days instead of 60)
2/ unfortunately not very helpful ...

But maybe I'm mistaking?!? :)

> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and bookworm, so
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to
> issues beyond your control, don't hesitate to contact the Release Team.

I do not think adding a:

Breaks: python3-django-horizon (<< 3:18.6.2)

in the current unstable version is the way to go at this point, as this
was addressed in Bullseye, as you wrote, which provides the upgrade path
already. So what should be done then?

Cheers,

Thomas Goirand (zigo)

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

[Tianon Gravi]

Hey Rod, this is an interesting one -- looking at the definitions of
the "EFI_DEVICE_PATH_UTILITIES_PROTOCOL" typedef in both refind's code
and grub-efi's, they appear to be compatible to me (which makes sense,
probably from the same original source?)

Is this something you plan to resolve in upstream refind source, or
something we should patch around downstream in Debian?

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

On Sun, 3 Oct 2021 at 04:15, Helmut Grohne  wrote:
> Source: refind
> Version: 0.12.0-1
> Severity: serious
> Tags: ftbfs
>
> refind fails to build from source in unstable on amd64 and it also fails
> to cross build for arm64 for the same reason. A build ends as follows:
>
> | make[3]: Entering directory '/<>/EfiLib'
> | /usr/bin/gcc -Os -fno-strict-aliasing -fno-tree-loop-distribute-patterns 
> -fno-stack-protector -fshort-wchar -Wall -DEFIX64 -DEFI_FUNCTION_WRAPPER -m64 
> -mno-red-zone  -fpic -I/usr/include/efi -I/usr/include/efi/x86_64 
> -I/usr/include/efi/protocol -I../include -I../refind -I../libeg -I../mok -I. 
> -I./../include \
> |   -D__MAKEWITH_GNUEFI -c gnuefi-helper.c -o gnuefi-helper.o
> | In file included from gnuefi-helper.c:19:
> | DevicePathUtilities.h:229:3: error: conflicting types for 
> ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’
> |   229 | } EFI_DEVICE_PATH_UTILITIES_PROTOCOL;
> |   |   ^~
> | In file included from /usr/include/efi/efi.h:61,
> |  from gnuefi-helper.h:24,
> |  from gnuefi-helper.c:18:
> | /usr/include/efi/efidevp.h:648:3: note: previous declaration of 
> ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’ was here
> |   648 | } EFI_DEVICE_PATH_UTILITIES_PROTOCOL;
> |   |   ^~
> | make[3]: *** [../Make.common:164: gnuefi-helper.o] Error 1
> | make[3]: Leaving directory '/<>/EfiLib'
> | make[2]: *** [Makefile:86: gnuefi] Error 2
> | make[2]: Leaving directory '/<>'
> | dh_auto_build: error: make -j1 gnuefi ARCH=x86_64 returned exit code 2
> | make[1]: *** [debian/rules:33: override_dh_auto_build] Error 25
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:26: build] Error 2
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2
>
> Also seen by crossqa:
> http://crossqa.debian.net
>
> Reproduced natively on arm64 by reproducible builds:
> https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/refind_0.12.0-1.rbuild.log.gz
>
> Helmut
>

Bug#926896: sysvinit-utils: pidof is unreliable

[Tim Connors]

Package: sysvinit-utils
Version: 2.96-7
Followup-For: Bug #926896

The broken behaviour introduced by the fix to #719273 is the
assumption that all D state processes are stuck.  D is indeed
"uninterruptable sleep", but uninterruptable in the sense that the
process can't respond to a signal until the system call returns.  It
might still be very responsive, but just doing a lot of IO.  For the
one limited use-case of pidof at system shutdown (that apparently
isn't even the case anymore according to[1]), you can be reasonably
sure that D state processes at system shutdown time are indeed stuck
(or just flushing a lot of data out to cache).  But pidof is used
elsewhere.

Some processes don't do anything *but* IO - such as find and dd.  I
wasn't excited to find this morning that I couldn't `pidof find`
anymore.

Now except for pidof being owned by the sysvinit-utils package, I'd
say the behaviour is entirely flipped around from what I'd expect by
the principle of least surprise - pidof should do the sane default of
checking all processes, and only in the limited shutdown case should
there be a flag to invert that behaviour and ignore D state processes
(I mean, I know when my NFS mounts go bad, a lot more goes wrong than
just pidof - do we really want to patch every sar cron.minute job to
ignore D state mounts too?  No, let's not special case everything, and
fix the root problem of a mount being stuck instead).  But sysvinit's
purpose is process management, so perhaps the redhat solution of
having that binary owned by another package, eg procps, is the correct
solution.


[1] "Also, at the current time (and IIRC this wasn't the case when we
submitted the original patch), start-stop-daemon is a binary not a
script, and it doesn't call pidof or killall.  Instead it uses its own
code, and that code is subject to the same issue where it hangs on
stuck NFS partitions.  Therefore, as it stands, applying this patch to
'pidof' will no longer resolve the issue; similar changes would have
to be made to 'killall'." -
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719273#42


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sysvinit-utils depends on:
ii  libc6 2.31-13+deb11u2
ii  lsb-base  11.1.0

sysvinit-utils recommends no packages.

sysvinit-utils suggests no packages.

-- no debconf information

Bug#996857: giara: does not start

[Kona Arctic]

Package: giara
Version: 0.3-2+b1
Severity: important
X-Debbugs-Cc: jjl7odcmdef3z4utn3ajdsmukzoko...@kona.anonaddy.com

Dear Maintainer,

giara does not start from gnome or command-line

```
kona@kona:~$ giara
Traceback (most recent call last):
  File "/usr/bin/giara", line 69, in 
gi.require_version('Handy', '1')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in
require_version
raise ValueError('Namespace %s not available for version %s' %
ValueError: Namespace Handy not available for version 1
kona@kona:~$
```

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

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

Versions of packages giara depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-gtksource-4   4.8.0-1
ii  gir1.2-webkit2-4.0   2.32.4-1~deb11u1
ii  python3  3.9.2-3
ii  python3-bs4  4.9.3-1
ii  python3-dateutil 2.8.1-6
ii  python3-mistune  0.8.4-4
ii  python3-praw 7.1.4-1
ii  python3-requests 2.25.1+dfsg-2

giara recommends no packages.

giara suggests no packages.

Bug#996866: cyrus-sasl2: Reconsider package license

[Bastian Germann]

Source: cyrus-sasl2
Priority: important

Hi,

Considering helping you with the package (you RFHed it), I had a look at it.
Please reconsider the package license, at least for the patches. Currently you have 
debian/* licensed under GPL-3+, which means that all the debian/patches/* files are 
GPL-3+. This has two problems:


1) cyrus-sasl2 is a basic package that is used by many packages that might not expect to 
have GPL-3+ in their dependency trees. Especially GPL-2-only licensed packages are not 
compatible with GPL-3+.


2) Supposedly, GPL (any version) itself is incompatible with the advertisement clause in 
BSD-4-clause. While the University of California has issued an official statement that 
this clause can be ignored for their software, I do not know of any such statement from 
Carnegie Mellon University. So it should be fairly controversial if Debian's patched 
cyrus-sasl2 binaries are legally distributable.


Maybe, some of the patches are not copyrightable, but a clarification would be very 
appreciated. I am also copying Dima as he is not listed on the current Uploaders list but 
is one of the copyright holders.


Thanks,
Bastian

Bug#996738: tinyproxy: Invalid fix for bug #968322 (issue still occurs): tinyproxy exits 2 on standard systemd stop signal SIGTERM

[Timo Sigurdsson]

Hi again,

RDS schrieb am 18.10.2021 18:42 (GMT +02:00):

> Doing the dishes just now, I thought of a possible relatively simple and
> "reasonable" tinyproxy-only deterministic solution:
> 
> Add a Boolean key-pair to tinyproxy's config, call it something like
> 'letHostManageStops', setting it to 'false' by default, so that the new 
> default
> behavior is tinyproxy's current behavoir.
> 
> If set to 'true', then tinyrpoxy's parent process does something like this 
> when
> it gets external kill sigs from the host: It does NOT send kill sigs to its
> childern. Instead, for some fixed period of time, it continusously loops over
> it's childern process IDs, each time checking if it's dead yet. I.E. Has the
> "host" (aka, in our case, systemd) killed it yet? If all its childern are dead
> before the fixed time elapses, it kills itself and exits 0. If one or more
> childern are still alive after the kill-time, it kills them itself, then 
> kill's
> itself. What exit status it reports in this case would need to be determined.

It sounds like a reasonable option to me. I'm still wondering, however, how 
other daemons that spawn multiple forks do this. At least I've never 
encountered an application with such a behavior under systemd. But then again, 
I'm not really a developer and much more of a user. 


Regards,

Timo

Bug#996738: tinyproxy: Invalid fix for bug #968322 (issue still occurs): tinyproxy exits 2 on standard systemd stop signal SIGTERM

[Timo Sigurdsson]

P.S. Somehow the bug tracker was lost in conversation, so adding it back.


Hi,

thanks for taking the time to reply on this old issue. Let me respond to a 
couple of your remarks and statements:

RDS schrieb am 18.10.2021 18:03 (GMT +02:00):

> [...}
> At some point in my convo with Mike I said I was going to dig into the systemd
> code to find the root cause on that side of the issue (i.e. in a sense systemd
> and tinyproxy "work together" to create the bug, but only in a sense). I did
> not follow through on this. I apologize. I might be willing to do this (but 
> I'm
> not promising) if this issue's a big deal for Timo, as my guess is that the
> better (only reasonalbe?) deterministic solution to bug #968322 is in systemd
> rather than tinyproxy.

First off, it's not a big deal for me. I only marked this issue with the 
severity important because that was the severity of the original issue. But 
since there seems to be no real fallout from this issue, I'm absolutely fine to 
edit the systemd unit locally adding the SuccessExitStatus=2 directive.

> On Monday, October 18th, 2021 at 9:32 AM, RDS  wrote:
>> [...]
>> (1) The fix pushed to prod by the tinyproxy Debain package team for #968322
>> was a statistical fix. I reported to them that it improved the false negative
>> rate for me, I don't remember by how much, but I think quite a bit. But, yes,
>> it's not deteministic.

I see. Maybe I should have read the original report more thoroughly, as I 
assumed the fix is supposed to fix the issue under all circumstances.

>> [...]
>> (2) I'm not clear which state systemd is reporting for tinyproxy's stop 
>> status
>> from this description:
>>
>> > I still found out one thing of note, though. I tried specifying an ExecStop
>> command like so:
>>
>> >
>>
>> > ExecStop=/usr/bin/kill -TERM $MAINPID
>>
>> >
>>
>> > With this, after stopping the service, `systemctl status tinyproxy'
>> showed that the kill command returned 0, but the main process 
>> returned
>> 2. It seems to me that this contradicts the following statement in 
>> the
>> original bug report which was:
>>
>> >
>>
>> > > The issue is more likely caused by systemd paying attention to 
>> the
>> return value of its SIGTERM send calls [...]
>>
>> >
>>
>> > I don't know whether that is helpful in terms of solving the cause
>> for the issue. But I thought, I'd at least mention it.
>>
>>
>> In this case is systemd reporting tinyproxy in a failed stopped state or
>> "good" one? If "failed", then it does seem a bit of a contradiction. If it's
>> reporting tinyproxy in a good stopped state, then it might not be a
>> contradiction, as it's reporting what the ExecStop command told it.

It reports the unit as failed. So, systemctl reports the state (or exit code) 
of the main process, not the kill command or SIGTERM call.


Regards,

Timo

Bug#996858: libllvm12 amd64 / i386 version ?

[alain]

perhaps a version problem : ?


alain@sid:~$ apt policy libllvm12:amd64 libllvm12:i386
libllvm12:
  Installé : 1:12.0.1-10
  Candidat : 1:12.0.1-10
 Table de version :
 *** 1:12.0.1-10 500
    500 https://deb.debian.org/debian unstable/main amd64 Packages
    100 /var/lib/dpkg/status
libllvm12:i386:
  Installé : (aucun)
  Candidat : 1:12.0.1-9
 Table de version :
 1:12.0.1-9 500
    500 https://deb.debian.org/debian unstable/main i386 Packages

Bug#996851: firefox: The New Tab search bar loses the first word of text pasted with the mouse

[Mike Hommey]

On Tue, Oct 19, 2021 at 05:59:18PM +0200, Vincent Lefevre wrote:
> Package: firefox
> Version: 93.0-1
> Severity: normal
> 
> Steps to reproduce:
> 
> 1. Open a new tab.
> 
> 2. Paste some text (e.g. "ab cd ef gh") in the search bar (saying
>"Search the web") with the middle button or via the contextual
>menu (right click over the search bar, then click on the "Paste"
>item).
> 
> A Google button appears in the address bar, followed by the text,
> but without the first word, e.g. I get "cd ef gh" without "ab".
> 
> There is no such issue when pasting directly in the address bar or
> when pasting with Ctrl-V.
> 
> This bug seems specific to Debian: I cannot reproduce this issue
> with upstream's Firefox 93.
> 
> FYI, the bug I had reported upstream:
> 
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1733731
> 
> (but no-one can reproduce it on non-Debian machines).

I can't reproduce either.

Mike

Bug#996865: ITP: jheaps -- Java library with various heap implementations

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-java team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org

* Package name: jheaps
  Version : 0.14
  Upstream Author : Dimitrios Michail
* URL : https://github.com/d-michail/jheaps
* License : Apache-2.0
  Programming Lang: Java
  Description : Java library with various heap implementations

This library contains various heap implementations written in Java.
A heap is a priority queue data type which contains elements with keys
(duplicate keys are permitted) from a totally-ordered universe.
The library is easy to use, its data structures have a well defined interface,
it is fast and well documented, and the heaps are written in a similar way as
in the JDK.

jheaps is needed as a dependency of JGraphT, which will also soon be packaged
as a dependency of biojava5-live, needed in Debian-med activities. JGraphtT
will also be a nice addition to scientific software in Debian-science.

The package will be team-maintained in the Debian-java team.

Bug#996864: src:python-elasticsearch: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: python-elasticsearch
Version: 7.1.0-3
Severity: serious
Control: close -1 7.1.0-4
X-Debbugs-CC: jel...@debian.org
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:python-elasticsearch has been trying to
migrate for 66 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-elasticsearch




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996858: installation of steam

[alain]

alain@sid:~$ sudo apt install --reinstall steam
[sudo] Mot de passe de alain :
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :

Les paquets suivants contiennent des dépendances non satisfaites :
 libgl1-mesa-dri:i386 : Dépend: libllvm12:i386 mais ne sera pas installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en 
mode « garder en l'état ».



alain@sid:~$ sudo apt -s install libllvm12:i386
[sudo] Mot de passe de alain :
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus 
nécessaires :

  bogofilter bogofilter-bdb bogofilter-common cheese-common docbook-xml
  evolution-common folks-common fonts-dejavu gir1.2-caribou-1.0
  gir1.2-dazzle-1.0 gir1.2-evince-3.0 gir1.2-gck-1 gir1.2-gcr-3
  gir1.2-gdata-0.0 gir1.2-gdm-1.0 gir1.2-geocodeglib-1.0 
gir1.2-gfbgraph-0.2

  gir1.2-gnomebluetooth-1.0 gir1.2-goa-1.0 gir1.2-graphene-1.0
  gir1.2-grilo-0.3 gir1.2-gtk-4.0 gir1.2-ibus-1.0 gir1.2-mediaart-2.0
  gir1.2-nma-1.0 gir1.2-rest-0.7 gir1.2-rsvg-2.0 gir1.2-totemplparser-1.0
  gir1.2-tracker-3.0 gir1.2-upowerglib-1.0 gir1.2-zpj-0.0
  gnome-control-center-data gnome-session-common gnome-shell-common
  gnome-todo-common gstreamer1.0-pipewire ibus ibus-data ibus-gtk ibus-gtk3
  im-config libbotan-2-18 libcaribou-common libcaribou0 
libclutter-1.0-common

  libcogl-common libdazzle-1.0-0 libdazzle-common libebackend-1.2-10
  libebook-1.2-20 libebook-contacts-1.2-3 libecal-2.0-1 
libedata-book-1.2-26

  libedata-cal-2.0-1 libfolks26 libfreerdp-client2-2 libfreerdp-server2-2
  libgdm1 libgnome-autoar-gtk-0-0 libgnome-todo libgpod-common libgpod4
  libgsoap-2.8.117 libgstreamer-plugins-bad1.0-0 libgupnp-igd-1.0-4 
libltc11

  libmjpegutils-2.1-0 libmpeg2encpp-2.1-0 libmplex2-2.1-0 libnice10
  libnss-myhostname libofa0 libopenni2-0 libphonenumber8 libprotobuf23 
libpst4

  libqt5printsupport5 librygel-core-2.6-2 librygel-db-2.6-2
  librygel-renderer-2.6-2 librygel-renderer-gst-2.6-2 librygel-server-2.6-2
  libsgutils2-2 libsoundtouch1 libspandsp2 libsrtp2-1 libtspi1 
libvncserver1

  libvo-aacenc0 libvo-amrwbenc0 libwildmidi2 libwpe-1.0-1
  libwpebackend-fdo-1.0-1 libxcb-glx0 libxcb-res0 libxcb-xv0 libxfont2
  libxvmc1 libxxf86dga1 libytnef0 libzbar0 mutter-common python3-ibus-1.0
  realmd sgml-base sgml-data shotwell-common switcheroo-control 
totem-common

  unoconv xfonts-100dpi xfonts-75dpi xfonts-base xfonts-scalable xml-core
  xserver-common xserver-xorg-legacy yelp-xsl zenity-common
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les paquets supplémentaires suivants seront installés :
  libqt5gui5-gles
Paquets suggérés :
  qt5-image-formats-plugins qtwayland5
Paquets recommandés :
  qt5-gtk-platformtheme
Les paquets suivants seront ENLEVÉS :
  caribou cheese chrome-gnome-shell evolution evolution-data-server
  evolution-plugin-bogofilter evolution-plugin-pstimport evolution-plugins
  gdm3 gir1.2-champlain-0.12 gir1.2-clutter-1.0 gir1.2-cogl-1.0
  gir1.2-coglpango-1.0 gir1.2-gst-plugins-bad-1.0 
gir1.2-gst-plugins-base-1.0
  gir1.2-gtkchamplain-0.12 gir1.2-gtkclutter-1.0 gir1.2-mutter-9 
gir1.2-rb-3.0

  gir1.2-totem-1.0 gir1.2-webkit2-4.0 gnome gnome-2048 gnome-calendar
  gnome-contacts gnome-control-center gnome-core gnome-documents 
gnome-games

  gnome-maps gnome-music gnome-nibbles gnome-online-accounts
  gnome-remote-desktop gnome-session gnome-session-bin gnome-shell
  gnome-shell-extension-prefs gnome-shell-extensions gnome-sound-recorder
  gnome-sushi gnome-todo gnome-tweaks gnome-user-docs gnome-video-effects
  gstreamer1.0-clutter-3.0 gstreamer1.0-gl gstreamer1.0-gtk3
  gstreamer1.0-plugins-bad libchamplain-0.12-0 libchamplain-gtk-0.12-0
  libcheese-gtk25 libcheese8 libclutter-1.0-0 libclutter-gst-3.0-0
  libclutter-gtk-1.0-0 libcogl-pango20 libcogl-path20 libcogl20
  libedataserverui-1.2-3 libevolution libfolks-eds26 libges-1.0-0 libgl1
  libgl1-mesa-dri libglx-mesa0 libglx0 libgoa-backend-1.0-1
  libgstreamer-gl1.0-0 libllvm12 libmutter-9-0 libqt5gui5 libqt5opengl5
  libtotem0 libwebkit2gtk-4.0-37 libxatracker2 libyelp0 
qt5-gtk-platformtheme

  quadrapassel rhythmbox-plugins rygel rygel-playbin rygel-tracker shotwell
  swell-foop thunderbird thunderbird-l10n-fr totem totem-plugins virtualbox
  virtualbox-qt x11-utils xserver-xephyr xserver-xorg xserver-xorg-core
  xserver-xorg-input-all xserver-xorg-input-libinput 
xserver-xorg-input-wacom

  xserver-xorg-video-all xserver-xorg-video-amdgpu xserver-xorg-video-ati
  xserver-xorg-video-fbdev 

Bug#987755: Mips build failure in new rpf 1.0.9 (Was: Bug#987755: r-cran-rpf: FTBFS on mips due to a variable called 'mips')

[Joshua N Pritikin]

On Tue, Oct 19, 2021 at 06:00:35PM +0530, Nilesh Patra wrote:
> There is still a failure in the latest version as well (1.0.9)
> a minor change fixes it, please consider applying attached patch.

Gah! Will do

Bug#996863: src:python-novaclient: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: python-novaclient
Version: 2:17.2.1-3
Severity: serious
Control: close -1 2:17.6.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 986143

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:python-novaclient has been trying to
migrate for 66 days [2]. Hence, I am filing this bug.

I'm not sure if the blocking bug is even a bug in bookworm. If I
understand it correctly, the issue reported there was purely for buster
to bullseye upgrades and can be ignored afterwards. FYI, the BTS
considers the bug affecting unstable because the version of the package
in unstable is not a descendant of the fixed version (judged by parsing
the changelog).

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-novaclient




OpenPGP_signature
Description: OpenPGP digital signature

Bug#900958: ITP: barebox-host-tools -- useful development tools from the barebox source tree

[Uwe Kleine-König]

Hello,

I somehow missed your reply, sorry, just found it by chance now.

On Tue, Mar 30, 2021 at 12:55:58AM +0530, deepak varma wrote:
> Are you looking for any further assistance with this ITP? I am willing to
> assist if required.

My plan is to first convert barebox to use SPDX to simplify (and only do
once) the copyright stuff. If you want to help here, that would be
great. I can share my scripting if you want. As you might have noticed
it's not top-priority on my side, but occationally I send a conversion
patch, the last one is


https://git.pengutronix.de/cgit/barebox/commit/?id=e88ac96a532fbe056bf45cfa0fa1ebf28c193c41

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#996852: "Error: failed to load BTF from ./fat: Invalid argument"

[Philipp Marek]

Package: bpftool
Version: 5.14.12-1
Severity: minor
X-Debbugs-Cc: phil...@marek.priv.at

Using an absolute path, I get output:

[/sys/kernel/btf]$ bpftool btf dump file $PWD/fat | head -2
[85705] STRUCT 'fat_mount_options' size=48 vlen=27
'fs_uid' type_id=506 bits_offset=0
[/sys/kernel/btf]$ bpftool btf dump file $PWD/fat | wc
6852274   25834

Using a relative path, "bpftool btf dump" doesn't work:

[/sys/kernel/btf]$ bpftool btf dump file ./fat
Error: failed to load BTF from ./fat: Invalid argument


"strace" shows that with a full path "bpftool" reads
"/sys/kernel/btf/vmlinux", but doesn't even try to find that in the
second case.

Dumping "vmlinux" works with a relative path,
I guess because it's self-contained.


Copying "fat" and "vmlinux" to /tmp/ and using a relative or absolute
path works for "vmlinux", but not "fat".

I think it would be great if a relative path would just be translated
to absolute when needed, or that required files would be searched via
some path list (configurable via environment, like $PATH or
$LD_LIBRARY_PATH etc.?).


Thanks a lot!


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de

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

Versions of packages bpftool depends on:
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libelf1  0.185-2
ii  zlib1g   1:1.2.11.dfsg-2

bpftool recommends no packages.

bpftool suggests no packages.

-- no debconf information

Bug#996862: Still depends on mime-support instead of mailcap and/or media-types

[Thomas Viehweger]

Package: dwww
Version: 1.14
Severity: normal


I wanted to remove all obsolete packages in section oldlibs. This gave 
dependency problems.

mime-support is a transitional package which depends on mailcap and media-types.

This package should depend on one (or both) of these packages instead.

Bug#996861: src:grepmail: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: grepmail
Version: 5.3104-1
Severity: serious
Control: close -1 5.3104-2
X-Debbugs-CC: jel...@debian.org
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:grepmail has been trying to migrate for 66
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=grepmail




OpenPGP_signature
Description: OpenPGP digital signature

Bug#900287: owncloud-client-cmd requires /etc/owncloud-client/sync-exclude.lst and ~/.local/share/data/ownCloud/

[Charles Curley]

On Tue, 19 Oct 2021 16:27:37 +0800
Paul Wise  wrote:

> Please test the new version of owncloud-client available in Debian
> experimental and reply to the bug whether this issue is fixed yet.

Really?

After adding experimental to a stable (Bullseye) system, I ran:

--
root@amanda:~# apt-get -t experimental install owncloud-client-cmd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libdouble-conversion3 libmd4c0 libowncloudsync0 libqt5core5a
  libqt5dbus5 libqt5gui5 libqt5keychain1 libqt5network5 libqt5sql5
  libqt5sql5-sqlite libqt5svg5 libqt5widgets5 libxcb-icccm4
  libxcb-image0 libxcb-keysyms1 libxcb-render-util0 libxcb-xinerama0
  libxcb-xinput0 libxcb-xkb1 libxkbcommon-x11-0 libxkbcommon0
  owncloud-client-l10n qt5-gtk-platformtheme qttranslations5-l10n
Suggested packages:
  qt5-image-formats-plugins qtwayland5

...

--

Even if the code is fine, the list of dependencies is unacceptable.

After installing anyway, I ran:

--
charles@amanda:~$ /usr/bin/owncloudcmd --user charles --password  
/home/charles/nextcloud https://nextcloud.localdomain/nextcloud
10-19 13:05:38:749 [ info sync.accessmanager ]: 2 "" 
"https://nextcloud.localdomain/nextcloud/ocs/v1.php/cloud/capabilities?format=json;
 has X-Request-ID "76ed3f60-4492-4794-acd3-ac18e7e5aa19"
10-19 13:05:38:749 [ info sync.networkjob ]:OCC::JsonApiJob created for 
"https://nextcloud.localdomain/nextcloud; + "ocs/v1.php/cloud/capabilities" ""



10-19 13:05:41:679 [ fatal default ]:   Cannot load system exclude list or list 
supplied via --exclude
Aborted
charles@amanda:~$
--

So I copied in an old copy of ~/.local/share/data/ownCloud. Then ran the same 
command line again.

--
charles@amanda:~$ /usr/bin/owncloudcmd --user charles --password  
/home/charles/nextcloud https://nextcloud.localdomain/nextcloud
10-19 13:20:32:638 [ info sync.accessmanager ]: 2 "" 
"https://nextcloud.localdomain/nextcloud/ocs/v1.php/cloud/capabilities?format=json;
 has X-Request-ID "5a051192-0f74-40e6-accc-f065b233bd00"
10-19 13:20:32:639 [ info sync.networkjob ]:OCC::JsonApiJob created for 
"https://nextcloud.localdomain/nextcloud; + "ocs/v1.php/cloud/capabilities" ""
10-19 13:20:32:641 [ warning sync.networkjob ]: 
QNetworkReply::ConnectionRefusedError "Connection refused" QVariant(Invalid)
10-19 13:20:32:641 [ info sync.networkjob.jsonapi ]:JsonApiJob of 
QUrl("https://nextcloud.localdomain/nextcloud/ocs/v1.php/cloud/capabilities?format=json;)
 FINISHED WITH STATUS "ConnectionRefusedError Connection refused"
10-19 13:20:32:641 [ warning sync.networkjob.jsonapi ]: Network error:  
"ocs/v1.php/cloud/capabilities" "Connection refused" QVariant(Invalid)
10-19 13:20:32:641 [ debug default ][ main(int, char**)::https://charlescurley.com
https://charlescurley.com/blog/


pgpxpuZ33l0mN.pgp
Description: OpenPGP digital signature

Bug#996858: addendum

[alain]

also steam has been uninstalled automatically .

now it is impossible to install steam since libllvm12:i386 is needed and 
not instalable .


conflict with the amd64 version ?

Bug#995735: dask.distributed: autopkgtest sometimes times out on ci.d.n worker since dask migrated

[Paul Gevers]

Hi Diane,

On 18-10-2021 20:53, Diane Trout wrote:
> I also glanced at the current CI build results and all the runs with
> 2021.09.1+ds.1-1 seem to be finishing in about 25 minutes both passing
> and faild tests. I do see the 2h runs with version 2021.08.1+ds.1-1
> https://ci.debian.net/packages/d/dask.distributed/
> 
> Do you think that's a good enough test to close this bug?

Well, the part about it timing out seems to be gone indeed, but the test
is still flaky as it fails on ci-worker13, but not on the others.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996860: kded5: crash during init

[Achim Schaefer]

Package: kded5
Version: 5.86.0-1
Severity: important

Dear Maintainer,

kded5 crashes during the initialtisatiopn of KDE.

Even creating a new user (without any config) does not work.

Thanks


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_LU.UTF-8, LC_CTYPE=de_LU.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_LU:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kded5 depends on:
ii  libc6  2.32-4
ii  libkf5configcore5  5.86.0-1
ii  libkf5coreaddons5  5.86.0-1
ii  libkf5crash5   5.86.0-1
ii  libkf5dbusaddons5  5.86.0-1
ii  libkf5service-bin  5.86.0-1
ii  libkf5service5 5.86.0-1
ii  libqt5core5a   5.15.2+dfsg-12
ii  libqt5dbus55.15.2+dfsg-12
ii  libqt5gui5 5.15.2+dfsg-12
ii  libqt5widgets5 5.15.2+dfsg-12
ii  libstdc++6 11.2.0-9

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information

Bug#996859: kded5: crash during init

[Achim Schaefer]

Package: kded5
Version: 5.86.0-1
Severity: important

Dear Maintainer,

kded5 crashes during the initialtisatiopn of KDE.

Even creating a new user (without any config) does not work.

Thanks

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_LU.UTF-8, LC_CTYPE=de_LU.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_LU:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kded5 depends on:
ii  libc6  2.32-4
ii  libkf5configcore5  5.86.0-1
ii  libkf5coreaddons5  5.86.0-1
ii  libkf5crash5   5.86.0-1
ii  libkf5dbusaddons5  5.86.0-1
ii  libkf5service-bin  5.86.0-1
ii  libkf5service5 5.86.0-1
ii  libqt5core5a   5.15.2+dfsg-12
ii  libqt5dbus55.15.2+dfsg-12
ii  libqt5gui5 5.15.2+dfsg-12
ii  libqt5widgets5 5.15.2+dfsg-12
ii  libstdc++6 11.2.0-9

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information

Bug#996858: libllvm12:i386 uninstallable and uninstall my desktop

[Sylvestre Ledru]

Hello

Please provide more information and steps to reproduce.

It might come from steam.

S


Le 19/10/2021 à 21:21, alain a écrit :
> Package: libllvm12
> Version: 1:12.0.1-10
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> X-Debbugs-Cc: compte.perso.de-al...@bbox.fr
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
> installation of libllvm12:i386
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> set the multiarch to i386 (from amd64)
> tried to install libllvm12:i386
>
>* What was the outcome of this action?
> uninstall of gnome and Xorg
>
>* What outcome did you expect instead?
> installation of libllvm12:i386 and reinstallation of steam
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (100, 'testing'), 
> (100, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.14.0-3-amd64 (SMP w/24 CPU threads)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libllvm12 depends on:
> ii  libc6   2.32-4
> ii  libedit23.1-20210910-1
> ii  libffi8 3.4.2-3
> ii  libgcc-s1   11.2.0-9
> ii  libstdc++6  11.2.0-9
> ii  libtinfo6   6.2+20210905-1
> ii  libxml2 2.9.12+dfsg-5
> ii  libz3-4 4.8.12-1+b1
> ii  zlib1g  1:1.2.11.dfsg-2
>
> libllvm12 recommends no packages.
>
> libllvm12 suggests no packages.
>
> -- debconf-show failed
>
> ___
> Pkg-llvm-team mailing list
> pkg-llvm-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team

Bug#994964: r-cran-gargle_1.2.0-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sun, Oct 10, 2021 at 05:00:08PM + schrieb Thorsten Alteholz:
> according to LICENSE only Google and RStudio are the copyright holder ...

Fixed in new upload, thanks for thorough checking

 Andreas. 

-- 
http://fam-tille.de

Bug#996858: libllvm12:i386 uninstallable and uninstall my desktop

[alain]

Package: libllvm12
Version: 1:12.0.1-10
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: compte.perso.de-al...@bbox.fr

Dear Maintainer,

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

   * What led up to the situation?
installation of libllvm12:i386

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
set the multiarch to i386 (from amd64)
tried to install libllvm12:i386

   * What was the outcome of this action?
uninstall of gnome and Xorg

   * What outcome did you expect instead?
installation of libllvm12:i386 and reinstallation of steam

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


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

Kernel: Linux 5.14.0-3-amd64 (SMP w/24 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libllvm12 depends on:
ii  libc6   2.32-4
ii  libedit23.1-20210910-1
ii  libffi8 3.4.2-3
ii  libgcc-s1   11.2.0-9
ii  libstdc++6  11.2.0-9
ii  libtinfo6   6.2+20210905-1
ii  libxml2 2.9.12+dfsg-5
ii  libz3-4 4.8.12-1+b1
ii  zlib1g  1:1.2.11.dfsg-2

libllvm12 recommends no packages.

libllvm12 suggests no packages.

-- debconf-show failed

Bug#996839: "Flame Graph template /usr/share/d3-flame-graph/d3-flamegraph-base.html does not exist."

[Philipp Marek]

Package: linux-perf-5.14
Version: 5.14.9-2
Severity: minor

"perf" can't show flamegraphs:

$ perf script report flamegraph
Flame Graph template 
/usr/share/d3-flame-graph/d3-flamegraph-base.html does not exist. Please 
install the js-d3-flame-graph (RPM) or libjs-d3-flame-graph (deb) 
package, specify an existing flame graph template (--template PATH) or 
another output format (--format FORMAT).


The given package name doesn't exist:

$ apt-get install libjs-d3-flame-graph
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package libjs-d3-flame-graph

And there's no other package for that:

$ LC_ALL=C apt-cache search flame.*graph

same when looking at 
https://packages.debian.org/search?searchon=contents=d3-flamegraph-base=filename=unstable=any, 
sadly.


Would be great if flamegraphs would work OOTB!



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de

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

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.77

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information:
  linux-base/removing-title:
* linux-base/removing-running-kernel: true

Bug#996838: RFP: obmenu2 -- obmenu2 is a graphical menu editor for the Openbox menu.xml file and is meant as a replacement for the old obmenu

[Scorpion2185]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: scorpion2...@protonmail.com

* Package name: obmenu2
  Version : 0.1.1
  Upstream Author : Name https://github.com/0x10
* URL : https://github.com/0x10/obmenu2
* License : MIT LICENSE
  Programming Lang: Python
  Description : obmenu2 is a graphical menu editor for the Openbox menu.xml
file and is meant as a replacement for the old obmenu

obmenu2 is a graphical menu editor for the Openbox menu.xml file.

It is written in Python 3 and GTK3 and is meant as a replacement for the old
obmenu (http://obmenu.sourceforge.net/) tool which is based on the deprecated
versions Python 2.7 and pygtk and pyglade.

It was written from scratch and does not share any code with the old obmenu
tool.

I am using this package not sure if there is a better replacement for obmenu,
but I am sure that users need a replacement.
Think about Openbox users experience.

Bug#996856: libcamera: Update package to a more recent version

[Carsten Schoenert]

Package: libcamera
Severity: wishlist

Hi,

it would be helpful and nice if the current version of libcamera could 
be updated within Debian to a recent version.


Within the Librem5 development, that uses the Debian derivatives PureOS 
[1], Dorota Dorota Czaplejewicz (CCd] is trying to work on libcamera to 
improve the basically functionality of the library and to get the camera 
of the Librem 5 phone better usable.
But the currently a bit outdated version of libcamera in Debian makes 
this difficult. So to make working and using/developing of libcamera 
more easy it would be great if the version in Debian can get an update.


Dorota started a MR [2] to update the packaging which will currently not 
fit the requirements to get accepted I guess.


I offered Dorota some help about the steps to get hopefully an update 
for libcamera prepared and into the archive.
So I started to imported a new upstream version and worked a bit on 
stuff and issues lintian was pointing out.


The RC bug #962650 Simon did open about the ongoing API / ABI breakage 
isn't something we can solve now and will require some statement and 
feedback from upstream. I assume that Dorota can talk about this with 
upstream once patches for upstream will get baked out any way.


Currently lintian shows these interesting tags after a package build:


$ lintian -IE
E: libcamera-dev: lacks-ldconfig-trigger usr/lib/x86_64-linux-gnu/v4l2-compat.so


I think this error isn't a real error lintian is thinking about, the .so 
file is within the -dev package is a real file and not a symlink as 
usual in a -dev package.
OTOH I don't know enough about libcamera currently, is this file then 
within the correct binary package? Or needs upstream to change the way 
this library is built?



W: libcamera-tools: no-manual-page usr/bin/qcam
W: libcamera-dev: package-name-doesnt-match-sonames v4l2-compat


Can be probably overridden or upstream should add some prefixing (if 
possible) and versioning?



W: libcamera-dev: shared-library-lacks-version 
usr/lib/x86_64-linux-gnu/v4l2-compat.so v4l2-compat.so
I: libcamera-dev: hardening-no-fortify-functions 
usr/lib/x86_64-linux-gnu/v4l2-compat.so
I: libcamera-dev: no-symbols-control-file 
usr/lib/x86_64-linux-gnu/v4l2-compat.so
I: libcamera0: no-symbols-control-file 
usr/lib/x86_64-linux-gnu/libcamera-base.so.0.0.0
I: libcamera0: no-symbols-control-file 
usr/lib/x86_64-linux-gnu/libcamera.so.0.1.0
I: libcamera source: out-of-date-standards-version 4.5.0 (released 2020-01-20) 
(current is 4.6.0.1)


I currently have postponed this modification as this is easy to "fix".


I: libcamera0: spelling-error-in-binary 
usr/lib/x86_64-linux-gnu/libcamera/ipa_rpi.so boun bound



Please let me know if it's possible to proceed and if you are interested 
to pull in my current work.
If there are things we need to address upstream I think that this 
partially can be done by Dorota at one point, I'm sure she will also 
figure out things that need to get fixed, discussed or changed upstream.



I pushed my current WIP to https://salsa.debian.org/tijuca/libcamera


[1] https://wiki.debian.org/Derivatives/Census/Purism
[2] https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/3

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/6 CPU threads)
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

--
Regards
Carsten Schoenert

Bug#994973: r-cran-googledrive_2.0.0-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sun, Oct 10, 2021 at 05:00:08PM + schrieb Thorsten Alteholz:
> according to LICENSE only Rstudio is the copyright holder.

Fixed in new upload, thanks for thorough checking

 Andreas. 

-- 
http://fam-tille.de

Bug#995154: r-cran-collapse_1.6.5-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sun, Oct 10, 2021 at 05:00:08PM + schrieb Thorsten Alteholz:
> according to LICENSE some files are licensed under MPL ..

This is fixed in new upload.

Thanks for thorough checking

 Andreas.

-- 
http://fam-tille.de

Bug#996050: extension compatibility with GNOME Shell 41

[Christian Lauinger]

On Sun, 17 Oct 2021 12:54:28 +0100 Simon McVittie 
wrote:
> Control: severity -1 serious
> 
> On Sun, 10 Oct 2021 at 21:33:02 +0100, Simon McVittie wrote:
> > The metadata.json for this extension doesn't declare compatibility
with
> > GNOME 41. I don't know whether the actual code will need changes or
not:
> > the conservative assumption is that it probably will (so please
test).
> 
> gnome-shell 41 is now in unstable, so incompatibilities with that
version
> are now RC. Please upload an updated extension if one is available.
> 
> smcv
> 
> 

There is already a pull request for gnome 41 compatibility:
https://github.com/micheleg/dash-to-dock/pull/1531

Bug#988597: trash-cli version too old

[Andrea Francia]

Il giorno lun 18 ott 2021 alle ore 20:02 Andrea Francia <
and...@andreafrancia.it> ha scritto:

> Now I have other problems: the tests what to use "python" instead of
> "python3", I'll try to fix that upstream.
>

Upstream [1] you can find a new version
(1412d3d8748585f422eb946a06bfe903160d3b01) of trash-cli that should use
python3 on Debian.

diff --git a/tests/run_command.py b/tests/run_command.py
index 2e31e11..18fd7b6 100644
--- a/tests/run_command.py
+++ b/tests/run_command.py
@@ -1,5 +1,6 @@
 import os
 import subprocess
+import sys

 from trashcli import base_dir

@@ -17,7 +18,7 @@ def run_command(cwd, command, args=None, input='',
env=None):
 if args == None:
 args = []
 command_full_path = os.path.join(base_dir, command)
-process = subprocess.Popen(["python", command_full_path] + args,
+process = subprocess.Popen([sys.executable, command_full_path] + args,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,


The next problem that needs to be solved is about the new `psutil`
dependency.

[1] https://github.com/andreafrancia/trash-cli
-- 
Andrea Francia http://andreafrancia.it

Bug#995443: appears to be fixed in linux-image-5.14.0-3-amd64 (5.14.12-1)

[Dov Feldstern]

Hi!

This appears to be fixed in linux-image-5.14.0-3-amd64 (5.14.12-1) --
I had downgraded the kernel back to stable (5.10) until now; now I
just upgraded back to the latest kernel image (though I upgraded the
full system, so possibly the issue was somewhere else rather than the
kernel) and hibernate is now working as expected!

So I think the issue can be closed.

Thanks!
Dov

Bug#996835: mirror submission for mirrors.xtom.jp

[xTom]

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

Submission-Type: new
Site: mirrors.xtom.jp
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: xTom 
Country: JP Japan
Location: Osaka
Sponsor: xTom https://xtom.com/




Trace Url: http://mirrors.xtom.jp/debian/project/trace/
Trace Url: http://mirrors.xtom.jp/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.xtom.jp/debian/project/trace/mirrors.xtom.jp

Bug#994967: r-cran-googlesheets4_1.0.0-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sun, Oct 10, 2021 at 05:00:08PM + schrieb Thorsten Alteholz:
> do you have an idea which package contains roxygen2, which is used to create 
> googlesheets4-package.Rd?

The term "package" in CRAN terminology is usually what we have as a 
r-cran-CRANPACKAGE so this
is r-cran-roxygen2.

> Anyway, upstream has different ideas about the copyright holder in 
> googlesheets4-package.Rd and LICENSE.
> There seems to be room for improvement.

On what string is your statement based?  The copyright holder of the
automatically generated file should be the same as the source, shouldn't
it.  Please be more verbose what you consider in need of improvement.
For the moment I've added a separate

   Files: man/googlesheets4-package.Rd

paragraph even if I do not see any actual reason for it.

Please find my new upload in new.

Kind regards and thanks for checking

  Andreas.

-- 
http://fam-tille.de

Bug#996822: ensurepip throws an AssertionError on pypy3

[stefanor]

Hi Ophir (2021.10.19_17:13:16_+)

> 
> > Again, not sure what you're expecting there.
> 
> If python3-pip is supposed to work with pypy, I would expect `apt install 
> pypy3 python3-pip && pypy3 -m ensurepip --version` to return “pip 20.3.4-4”. 
> Instead, it returns the long error message you mentioned above that suggests 
> installing another package.

Nope, I get:
$ pypy3 -m ensurepip --version
pip 20.3.4

> > No, that should be working. That's why we have ensurepip.
> 
> Can you try it in a docker image ? Starting from Debian slim, "apt install 
> pypy3 && pypy3 -m venv venv” fails for me.

With an error message that says:

> The virtual environment was not created successfully because ensurepip
> is not available.  On Debian/Ubuntu systems, you need to install the
> python-pip-whl package using the following command.
>
>apt-get install python-pip-whl
>
> You may need to use sudo with that command.  After installing the
> python-pip-whl package, recreate your virtual environment.

If you read that error message, does that help?

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996855: gnome-recipes: no french version

[txodom]

Package: gnome-recipes 
Version: 2.0.2-5+b2 
Severity: normal 
X-Debbugs-Cc: none 

Dear Maintainer, 

The sid version of gnome-recipes does not have a French version although the 
.po files have been translated. 

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

Kernel: Linux 5.14.0-3-amd64 (SMP w/4 CPU threads) 
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 
Shell: /bin/sh linked to /bin/dash 
Init: systemd (via /run/systemd/system) 
LSM: AppArmor: enabled 

Versions of packages gnome-recipes depends on: 
ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 
ii dbus-x11 [dbus-session-bus] 1.12.20-2 
ii gnome-recipes-data 2.0.2-5 
ii libc6 2.32-4 
ii libcairo2 1.16.0-5 
ii libcanberra0 0.30-8 
ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 
ii libglib2.0-0 2.70.0-1+b1 
ii libgnome-autoar-0-0 0.4.0-1 
ii libgoa-1.0-0b 3.40.0-2 
ii libgspell-1-2 1.9.1-2 
ii libgtk-3-0 3.24.30-3 
ii libjson-glib-1.0-0 1.6.6-1 
ii libpango-1.0-0 1.48.10+ds1-1 
ii libpangocairo-1.0-0 1.48.10+ds1-1 
ii librest-0.7-0 0.8.1-1.1 
ii libsoup2.4-1 2.74.0-2 

gnome-recipes recommends no packages. 

gnome-recipes suggests no packages. 

-- no debconf information 

Bug#996822: ensurepip throws an AssertionError on pypy3

[Ophir Lojkine]

> Again, not sure what you're expecting there.

If python3-pip is supposed to work with pypy, I would expect `apt install pypy3 
python3-pip && pypy3 -m ensurepip --version` to return “pip 20.3.4-4”. Instead, 
it returns the long error message you mentioned above that suggests installing 
another package.

> No, that should be working. That's why we have ensurepip.

Can you try it in a docker image ? Starting from Debian slim, "apt install 
pypy3 && pypy3 -m venv venv” fails for me.

Bug#996794: ncbi-acc-download: autopkgtest failure with python-biopython 1.79+dfsg-1~0exp0 in experimental

[Andreas Tille]

Am Tue, Oct 19, 2021 at 07:55:07AM -0400 schrieb Aaron M. Ucko:
> Étienne Mollier  writes:
> 
> > E - LOCUS   NC_007194 60 bpDNA 
> > linear   CON 03-APR-2018
> > E ?  ^^^
> > ^^ ^^^   ^^
> > E + LOCUS   NC_0071944918979 bpDNA 
> > linear   CON 11-NOV-2009
> > E ?  ^^^
> > ^^ ^^^   ^^
> 
> It looks like this test is intended to work offline (as required) and
> yield short mock records, but for some reason winds up fetching
> full-length live data instead.

Strangely enough this issue seems to depend from the biopython version.
Any idea what might be wrong here?

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Bug#996823: libunwind-13: Missing symlink libunwind.so to libunwind.so.1 causes -lc++ to fail since it links to -lunwind

[Sylvestre Ledru]

Le 19/10/2021 à 18:19, darkdragon a écrit :

On Tue, Oct 19, 2021 at 2:47 PM Simon McVittie  wrote:

Are you sure you found this bug in that version?


Yes, I manually downloaded libunwind from the Debian archive and
installed it in Ubuntu to verify it still exists in the latest
version.

Please don't do that.
it isn't designed to work and it is very hard for us to debug.

Instead, please use https://apt.llvm.org/
(this is the same packages)


S

Bug#996822: ensurepip throws an AssertionError on pypy3

[stefanor]

Hi Ophir (2021.10.19_16:58:38_+)
> Of course ! But shouldn't ensurepip detect pip when it is installed,
> instead of returning an AssertionError ?

Yeah, possibly.

And as I said before, it shouldn't be returning an AssertionError,
that's a bug. You should be getting a friendly error explaining why
using ensurepip in a Debian packaged python doesn't make any sense.

> ensurepip being broken means that `pypy3 -m venv venv` is broken too, which
> is annoying.

No, that should be working. That's why we have ensurepip.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996822: ensurepip throws an AssertionError on pypy3

[Ophir Lojkine]

>
>
>
> If you want to *use* pip, use "pypy3 -m pip", ensurepip is not a pip
> wrapper.


Of course ! But shouldn't ensurepip detect pip when it is installed,
instead of returning an AssertionError ?

ensurepip being broken means that `pypy3 -m venv venv` is broken too, which
is annoying.

Bug#996401: gnome-shell-extension-prefs: Gnome extensions app fails to open in Wayland but opens in X11

[Justin Searle]

Thanks for the response Simon.

Yes, each time I've tried over the last month has been after fully
updating all packages in Sid.

I just fully upgraded again but still is not running on Wayland.  It
works fine in X11, just not Wayland.

Here are my current package versions, including the new packages you asked for:

chrome-gnome-shell   10.1-5 all [installed,automatic]
gir1.2-gtk-4.0   4.4.0+ds1-5 amd64 [installed,automatic]
gnome-shell-common   41.0-2 all [installed,automatic]
gnome-shell   41.0-2 amd64 [installed]
libffi7   3.3-6 amd64 [installed,automatic]
libffi8   3.4.2-3 amd64 [installed,automatic]
libgirepository-1.0-1   1.70.0-2 amd64 [installed,automatic]
libgjs0g   1.70.0-3 amd64 [installed,automatic]

When I run `gnome-extensions-app` from the command line, there is no output.

Here are the events generated in /var/log/syslog when I run it from
the command line:

Oct 19 10:38:16 gtfo systemd[5180]: Started VTE child process 48402
launched by gnome-terminal-server process 8706.
Oct 19 10:38:23 gtfo dbus-daemon[5211]: [session uid=1000 pid=5211]
Activating service name='org.gnome.Shell.Extensions' requested by
':1.160' (uid=1000 pid=48740 comm="/usr/bin/gjs
/usr/share/gnome-shell/org.gnome.Exte")
Oct 19 10:38:23 gtfo dbus-daemon[5211]: [session uid=1000 pid=5211]
Successfully activated service 'org.gnome.Shell.Extensions'

And here is the output of while running it in strace:

strace gnome-extensions-app   ─╯
execve("/usr/bin/gnome-extensions-app", ["gnome-extensions-app"],
0x7ffea08405f0 /* 68 vars */) = 0
brk(NULL)   = 0x55a9c39c3000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=173953, ...}) = 0
mmap(NULL, 173953, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffb7b5a7000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\177\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1839168, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7ffb7b5a5000
mmap(NULL, 1852480, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffb7b3e
mprotect(0x7ffb7b406000, 1658880, PROT_NONE) = 0
mmap(0x7ffb7b406000, 1347584, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7ffb7b406000
mmap(0x7ffb7b54f000, 307200, PROT_READ,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16f000) = 0x7ffb7b54f000
mmap(0x7ffb7b59b000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ba000) = 0x7ffb7b59b000
mmap(0x7ffb7b5a1000, 13376, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffb7b5a1000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7ffb7b3de000
arch_prctl(ARCH_SET_FS, 0x7ffb7b5a65c0) = 0
mprotect(0x7ffb7b59b000, 12288, PROT_READ) = 0
mprotect(0x55a9c37ff000, 8192, PROT_READ) = 0
mprotect(0x7ffb7b5fc000, 4096, PROT_READ) = 0
munmap(0x7ffb7b5a7000, 173953)  = 0
getuid()= 1000
getgid()= 1000
getpid()= 67846
rt_sigaction(SIGCHLD, {sa_handler=0x55a9c37f4ae0, sa_mask=~[RTMIN
RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7ffb7b41cef0}, NULL, 8) = 0
geteuid()   = 1000
brk(NULL)   = 0x55a9c39c3000
brk(0x55a9c39e4000) = 0x55a9c39e4000
getppid()   = 67843
stat("/home/meeas", {st_mode=S_IFDIR|0755, st_size=115, ...}) = 0
stat(".", {st_mode=S_IFDIR|0755, st_size=115, ...}) = 0
openat(AT_FDCWD, "/usr/bin/gnome-extensions-app", O_RDONLY) = 3
fcntl(3, F_DUPFD, 10)   = 10
close(3)= 0
fcntl(10, F_SETFD, FD_CLOEXEC)  = 0
geteuid()   = 1000
getegid()   = 1000
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x55a9c37f4ae0, sa_mask=~[RTMIN
RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7ffb7b41cef0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER, sa_restorer=0x7ffb7b41cef0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER, sa_restorer=0x7ffb7b41cef0}, NULL, 8) = 0
read(10, "#!/bin/sh\n/usr/bin/gjs /usr/shar"..., 8192) = 72
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0
vfork() = 67847
rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0
wait4(-1, 

Bug#996822: ensurepip throws an AssertionError on pypy3

[stefanor]

Hi Ophir (2021.10.19_16:45:43_+)
> Should it encourage the user to install python3-pip ?  I thought this
> package was specific to cpython. 

It is not specific to cpython.
All python3 implementations on Debian can use it.

However, when it comes to C extensions, those tend to be specific to
cpython (yes, this is a bit of a mess)

> Installing it does not seem to make ensurepip work in pypy, at least.

Again, not sure what you're expecting there.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996822: ensurepip throws an AssertionError on pypy3

[stefanor]

Hi Ophir (2021.10.19_16:32:18_+)
> RUN apt-get update && apt-get -y install pypy3 wget
> 
> RUN wget https://bootstrap.pypa.io/get-pip.py && pypy3 get-pip.py
> 
> RUN pypy3 -m ensurepip

The same error. get-pip.py will do nothing to make ensurepip behave any
differently.

If you want to *use* pip, use "pypy3 -m pip", ensurepip is not a pip
wrapper.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996730: Certain menus don't work right when chrome is in the Normal Layer

[Eduard Bloch]

Control: severity 996730 important
Control: tags 996730 +notreproducible +upstream

Hallo,
* 積丹尼 Dan Jacobson [Mon, Oct 18 2021, 03:42:00AM]:
> Package: icewm
> Version: 2.8.0-1
> Severity: grave
>
> Are there any other users who can confirm
> https://github.com/ice-wm/icewm/issues/62 ?

I have no idea what you mean and this is definitively not "grave". Tried
to reproduce with different settings and chromium 93.0.4577.82-1 and it
just works.

Maybe some issue with other software on your system which is
manipulating properties?

Maybe gijsbers finds something. Does it work if you downgrade icewm (and
icewm-common) to the Testing version?

Best regards,
Eduard.

Bug#994836: exim: dpkg fatal error due to Debian-exim in statoverride

[Andreas Metzler]

On 2021-09-21 Wookey  wrote:
> Package: exim
> Severity: important

> whilst trying to install build-deps for therion in an unstable chroot
> i.e
> apt source therion (6.0.2ds1-3 is downloaded)
> cd therion-6.0.2ds1
> sudo apt --no-install-recommends build-dep .

> I got (after downloading 887MB of stuff, (304MB, 270 packages)):

> debconf: delaying package configuration, since apt-utils is not installed
> dpkg: unrecoverable fatal error, aborting:
>  unknown system group 'Debian-exim' in statoverride file; the system group 
> got removed
> before the override, which is most probably a packaging bug, to recover you
> can remove the override manually with dpkg-statoverride
> E: Sub-process /usr/bin/dpkg returned an error code (2)
> E: Failed to process build dependencies

> That's quite bad. Debian-exim is indeed mentionned in the override file.
> $ cat /var/lib/statoverride:
> root crontab 2755 /usr/bin/crontab
> root Debian-exim 640 /etc/exim4/passwd.client
> root messagebus 4754 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
[...]
> Turns out that the install list doesn't matter. any use of dpkg will hit this 
> statoverride issue.

> /etc/exim4/passwd.client does exist but is owned by an unknown group.
> $ll /etc/exim4/passwd.client
> -rw-r- 1 root 132 204 Nov  4  2020 /etc/exim4/passwd.client
[...]
> So it does indeed look like the Debian-exim group was removed, but at least 
> one file owned by it, and the statoverride remain.

> Is that expected? - I presume not.
[...]

Hello Wookey,

no, it is not expected. Both -base and -config will add a Debian-exim
system user with its own private group in postinst if it does not exist.
But none of the exim packages ever remove the user.

So it looks like random system breakage to me. - Isn't user removal
logged usually?

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

Bug#996822: ensurepip throws an AssertionError on pypy3

[Ophir Lojkine]

> What should happen is that it prints the error message:
> 
>> […]
>> Install the python3-pip package to use pip itself.  […]

Should it encourage the user to install python3-pip ?  I thought this package 
was specific to cpython. 
Installing it does not seem to make ensurepip work in pypy, at least. 

Bug#996833: Please include information whether system is usrmerged or not

[Michael Biebl]

Hi Sandro

Am 19.10.21 um 16:35 schrieb Sandro Tosi:

control: tags -1 +moreinfo


given the decisions by the CTTE to go with a merged-/usr file system
layout, I think it would be useful (at least during the transition
phase), if reportbug included the information whether a system is
already using such a file system layout or not.

reportbug already includes:

Shell: /bin/sh linked to /bin/dash

One can sort of deduce this information from the above line (on a
merged-/usr system /bin/sh typically points to /usr/bin/dash), and most
shells are typically installed in /bin, so I could understand if you
reject this bug report.


we'd be happy to add this, but (as for other "recent" additions to the
system info section, such as what init system is in use) the burden of
coming up with a good/valid heuristics is on the requestor (simply
because we may not be in a good position to know all the intricacies).

While a MR implementing this is of course welcome, you can also simply
give us a good way to determine if it's usrmerged or not and we can
add that information; an reference implementation (still using the
init system example from above) is
https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/utils.py#L1220-1241


I'd make this pretty straighforward and simply check if
/lib is a symlink to /usr/lib and
/bin a symlink to /usr/bin

I don't think there is a need to check all other /lib* variantions and 
/sbin as well to reliably detect a merged system.


Marco, if you disagree, please chime in here.



Since we also try to keep that section of the bug report contained in
size, do we need to add a new line for all bug reports? do we want to
start first with only adding a line if a system is usr-merged (which
is the least common case)? can we merge this information with another
sys-info line already present in every bug report?



Given that since two stable releases, we are defaulting to merged-/usr 
for new installations, it's hard to tell, what the more common case is.
It might already be the case that we have more merged-/usr systems out 
there then unmerged.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#914315: libwebp-dev: New versions fix disclosed heap use-after-free

[Anthony Fok]

On Sat, Aug 7, 2021 at 3:00 PM Jeff Breidenbach  wrote:

> Maintainer is "less active" but still in good contact with upstream.
> I was going to package the latest version several months ago, but
> there was a soname bump and transitions were not allowed due to
> Debian's release cycle. Happy to work with anyone on updating webp.

Hi Jeff,

I am happy to work with you on updating webp, especially now Hugo the
static website generator (>= 0.83) now depends on libwebp for WebP
support.  Please let me know the best way to collaborate.

Cheers,
Anthony

Bug#996836: [Pkg-javascript-devel] Bug#996836: node-webpack: webpack embeds binary files in es-module-lexer component

[Bastien ROUCARIES]

Le mar. 19 oct. 2021 à 16:12, Yadd  a écrit :

> Source: node-webpack
> Version: 5.58.2+~cs5.11.7-1
> Severity: serious
> Justification: DFSG
>
> webpack 5.58 uses es-module-lexer. For now, this component is downloaded
> including some binary files (WASM,...). This should be fixed before
> going to unstable.
>

I really hate wasm...

What is the source language ? Rust ?

>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>

Bug#996822: ensurepip throws an AssertionError on pypy3

[Ophir Lojkine]

> 
> I can't reproduce that, get-pip.py works for me, and leaves me with a
> functional pip.

Interesting ! What does the following script return for you ?

cat < Dockerfile
FROM debian:stable-slim

RUN apt-get update && apt-get -y install pypy3 wget

RUN wget https://bootstrap.pypa.io/get-pip.py && pypy3 get-pip.py

RUN pypy3 -m ensurepip
EOF

docker build .

Bug#996854: Mention that "install" indeed does accept filenames after all

[積丹尼 Dan Jacobson]

Package: apt
Version: 2.3.10
File: /usr/share/man/man8/apt-get.8.gz

man apt-get says:
   install
   install is followed by one or more packages desired for
   installation or upgrading. Each package is a package name, not a
   fully qualified filename

All I know is
apt-get install ./Webex.deb
apt-get install $PWD/Webex.deb
worked fine.

Bug#996822: ensurepip throws an AssertionError on pypy3

[stefanor]

Hi Ophir (2021.10.19_10:59:43_+)
> Running pypy3 -m ensurepip on Debian returns an AssertionError. 

Thanks for the bug, that shouldn't happen.

What should happen is that it prints the error message:

> ensurepip is disabled in Debian/Ubuntu for the system python.
>
> Python modules for the system python are usually handled by dpkg and apt-get.
>
>apt-get install python3-
>
> Install the python3-pip package to use pip itself.  Using pip together
> with the system python might have unexpected results for any system
> installed module, so use it on your own risk, or make sure to only use
> it in virtual environments.

However:

> Running get-pip.py  does not
> change the error.

I can't reproduce that, get-pip.py works for me, and leaves me with a
functional pip.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996853: gnome-session-common: oldconfig: /etc/X11/Xsession.d/55gnome-session_gnomerc

[Martin-Éric Racine]

Package: gnome-session-common
Version: 40.1.1-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

$ dpkg-query --search $(dpkg-query --show --showformat='${Conffiles}\n' | grep 
obsolete | awk '{print $1}')
gnome-session-common: /etc/X11/Xsession.d/55gnome-session_gnomerc

- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing')
Architecture: i386 (i586)

Kernel: Linux 5.14.0-2-686 (SMP w/1 CPU thread)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmFu8MYACgkQrh+Cd8S0
17bkLw/9EQNfamdD0wBkMJnKWg4FaeXvu8Rc9n6VCh4kZVrUMhCtD0NnMN7mfFEX
K37wrvFwrlIJf3Ds4JuoB4aWDVTvPXH+PkWCMvzgFw6mjkMK+f2uWYaC9KfwmseT
ejLowObGnR0mvbD52N31quCGQI7NgzrVt0g9sX0aRLBYCc25TZnewi67RQkt6PeD
/e49Dxs/9K5VWxcXJqX6n/pu3WB+r6XieS+9/nQOV3r1P7KDs9DISjEy1q6XaBb9
V6mirZtt1M3O5VTHJdgbCBKbNdeKlDwgQv8tMzUVo/x6OKfJMYmtNMOHQTnjvL1u
iTCpXGspDSQ+IK+WCu57yy0yKMixp5xiUgBCAnAk7PEu3gIfaH/XaKtYJON2DkWG
2ToOA4NFUDK0SJuLq8am5EAaVRU6/EEnC38WG/sEE0+Sxs3OxcGvc/CPNhWpZFx2
QBnlaITorSwT3xDd5F6395B4CLmecu9lhJuh3J/JRC+tvErEL2SO/2lVtB7S79W+
vqB+OrvzdZh5NSr3lCoQbXL1jKcMnSXab6RHwMy0UeT44pXABSQu1ZjLXwF7kbdF
steCEQuwZFo+KXpgxlD0pUwOAfEqROgsXPs3loOFGmUMA0EP41g15NUCXCsJCro5
oX/xpoy2XuDUb+FfDLJwx+fX3i7ROXgOzafc+uKGdPLWkJ4Tbr4=
=GwaQ
-END PGP SIGNATURE-

Bug#996823: libunwind-13: Missing symlink libunwind.so to libunwind.so.1 causes -lc++ to fail since it links to -lunwind

[darkdragon]

On Tue, Oct 19, 2021 at 2:47 PM Simon McVittie  wrote:
> Are you sure you found this bug in that version?

Yes, I manually downloaded libunwind from the Debian archive and
installed it in Ubuntu to verify it still exists in the latest
version.

> It is correct that files and symlinks that are not required at runtime,
> only for development, are only shipped in -dev packages.

I wasn't aware that symlinks to the binaries are shipped in the -dev
packages. Thanks for pointing this out.

Can be closed as a duplicate of the above mentioned issue.

Bug#976334: libgtk-3-0: File choser does not display the list of folders on NFS access

[Ian Campbell]

Control: tag -1 patch

Hello,

I can confirm that upstream commit aca83684ed4c ("searchenginemodel:
finalize search results") from the upstream MR!4030[0] for GTK3 cherry-
picks cleanly onto the dgit/dgit/bullseye branch (commit dd04b9476f67,
AKA archive/debian/3.24.24-4 tag).

I've installed the resulting package on my bullseye machine and
searching in the open dialog in evince works again.

Since the libgtk-3-0 maintainers appear to be using dgit I hope that
this is sufficient to warrant adding the patch tag. I'm more than happy
to provide a more literal patch if desired.

Thanks,
Ian.

[0] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4030

Bug#992686: pipewire-pulse: Please have pipewire-pulse Provide pulseaudio

[Michael Biebl]

On Thu, 26 Aug 2021 11:56:05 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?=
 wrote:

> Pulseaudio and pipewire-pulse are not fully compatible (pipewire-pulse
> can't load pulse modules, doesn't have /usr/bin/pulseaudio or other
> Pulse executable interfaces, ...).
> 
> The best way to deal with that issue is to update all packages that
> Depends, Recommends or Suggests pulseaudio to depend either on
> pulseaudio or pipewire-pulse (i.e. pulseaudio | pipewire-pulse).
> 

I think I agree here. 

I also would like to add, that there aren't *that* many rdeps of pulseaudio.
I'm counting 26, 7 of those are packages built from src:pulseaudio, remain
19.

Some of them, like libcanberra-pulse already have a pulseaudio | pipewire-
pulse dependency. 

On this particular system (running GNOME), I have successfully uninstalled
pulseaudio and replaced it with pipewire-pulse.

I do have to add, that I don't have the gnome-core meta package installed.
meta packages like gnome-core should imho make an informed choice, which
software they want. I guess once the GNOME team thinks pipewire is ready to
replace pulseaudio, they are going to update their package dependencies
accordingly. As long as they depend on pulseaudio, they should actually get
pulseaudio, not pipewire-pulse.

Regards,
Michael


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

Bug#996851: firefox: The New Tab search bar loses the first word of text pasted with the mouse

[Vincent Lefevre]

Package: firefox
Version: 93.0-1
Severity: normal

Steps to reproduce:

1. Open a new tab.

2. Paste some text (e.g. "ab cd ef gh") in the search bar (saying
   "Search the web") with the middle button or via the contextual
   menu (right click over the search bar, then click on the "Paste"
   item).

A Google button appears in the address bar, followed by the text,
but without the first word, e.g. I get "cd ef gh" without "ab".

There is no such issue when pasting directly in the address bar or
when pasting with Ctrl-V.

This bug seems specific to Debian: I cannot reproduce this issue
with upstream's Firefox 93.

FYI, the bug I had reported upstream:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1733731

(but no-one can reproduce it on non-Debian machines).

This bug was already present in firefox 92.0-1.

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils  5.5-1
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.11.0+dfsg-1
ii  libgcc-s111.2.0-9
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libgtk-3-0   3.24.30-3
ii  libnspr4 2:4.32-1
ii  libnss3  2:3.70-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-9
ii  libvpx6  1.10.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.4-6+b2

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-6.1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-8
ii  libgssapi-krb5-2   1.18.3-7
ii  pulseaudio 15.0+dfsg1-2

-- no debconf information

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

Bug#962293: Test results, recommends

[Ryan Pavlik]

I have tried the package here:
https://salsa.debian.org/libvirt-team/virt-v2v and it seems to work
well. In combination with that package, I have filed
https://bugs.debian.org/996850 for the two tools used when processing a
Windows guest: so, probably a "recommends".



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996716: pyopencl: autopkgtest regression: test-depends on removed package

[Andreas Beckmann]

Followup-For: Bug #996716
Control: forwarded -1 https://github.com/inducer/pyopencl/issues/519
Control: retitle -1 pyopencl: FTBFS on 32-bit arches; autopkgtest regression: 
test-depends on removed package

> [...] The package
> python3-pyopencl-dbg was dropped in the latest upload but the test still
> depends on it.

Oops, -dbg autopkgtest stanza dropped, too.

> On top of that, the package also FTBFS on armel, armhf
> and i386 (all 32-bits archs).

=== FAILURES ===
__ test_mempool_32bit_issues ___

def test_mempool_32bit_issues():
# https://github.com/inducer/pycuda/issues/282
from pyopencl._cl import _TestMemoryPool
pool = _TestMemoryPool()

for i in [30, 31, 32, 33, 34]:
for offs in range(-5, 5):
>   pool.allocate(2**i + offs)
E   TypeError: allocate(): incompatible function arguments. The 
following argument types are supported:
E   1. (self: pyopencl._cl._TestMemoryPool, arg0: int) -> None
E
E   Invoked with: , 4294967296

test_wrapper.py:592: TypeError

Reported upstream:
https://github.com/inducer/pyopencl/issues/519
I don't think it is an error not being able to allocate ~4 GB or
more on a platform with 32-bit address space.

The fix will come with a new upstream (2021.2.8 or later) now that
pytools has been updated, but waiting for upstream's comment on the
test failure first.


Andreas

Bug#996337: upgrade python-click-threading to 0.5.0

[Yuri D'Elia]

Package: python3-click-threading
Version: 0.4.4-2
Followup-For: Bug #996337

The priority should probably be changed to important or above, since the
functionality of this package is broken currently and breaks software
which depends on it.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-click-threading depends on:
ii  python33.9.2-3
ii  python3-click  8.0.2-1

python3-click-threading recommends no packages.

python3-click-threading suggests no packages.

Bug#996850: ITP: rhsrvany -- Windows tools used by virt-v2v

[Ryan Pavlik]

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

* Package name: rhsrvany
  Version : 0.20210127
  Upstream Author : Richard W.M. Jones, Red Hat Inc.
* URL : https://github.com/rwmjones/rhsrvany
* License : GPL-2+
  Programming Lang: C
  Description : Windows tools used by virt-v2v

 This package contains open-source replacements for
 proprietary Windows tools, SrvAny (RHSrvAny) and pnp_wait.
 They are used by the virt-v2v tool when converting
 Windows virtual machines.

This is required for virt-v2v (see https://bugs.debian.org/962293)
which was formerly part of libguestfs in Buster and now the
subject of its own RFP bug linked above.
The draft of that package is in the libvirt team,
and if this package is accepted, I'd anticipate joining that team
for team maintenance and sponsorship. The code itself is quite stable,
with a limited purpose and having seen little need for changes in
the past several years, so I anticipate
packaging maintenance load to be low.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#375275: #375275: getty: cursor state not reset

[Michael Biebl]

Hi Chris

Am 19.10.21 um 17:27 schrieb Chris Hofstaedtler:

Control: reassign -1 systemd

Hi,

this bug is about various terminal settings not being reset on tty1
(usually a Linux VC). Maybe also about other things, please see the
original bug message.

I am reassigning this to systemd based on:

1) util-linux agetty nowadays allows --init-string also on Linux
Virtual Consoles. That appears to be a valid option to have a
"reproducible" console. See [1] for slightly more info.

2) systemd provides getty@.service, which controls agetty startup.
This unit also specifies --noclear, which might be related.

Considering this, I believe util-linux agetty is not in the position
to make the requested change, and probably also SHOULD not (it is
not setting up the console in the first place).

If this change should happen, it can (and IMO should) by shipping
a modified getty@.service.


Would you mind filing this upstream at
https://github.com/systemd/systemd/issues

I think you are in a better position to argue why this change should be 
done in systemd and not agetty.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996849: RM: dlz-ldap-enum -- RoQA, unmaintained, dead-upstream, low popcon

[Tobias Frost]

Package: dlz-ldap-enum
Severity: serious

Dear Maintainer,

The package is unmaintained, outdated in terms of packaging standard, very low
(as in single digit) popcon and it has no reverse dependencies.

I therefore propose to RM the package.

If you disagree, just close this bug, but please show the package some love.
Especially, it is in need of an human maintainer (refering to Policy 5.6.3)

If you agree, reassign the bug to ftp.debian.org

If there is no answer, I will reassing the bug in exactly 3 months
to ftp.debian.org to make the RM happen.

-- 
tobi

Bug#375275: #375275: getty: cursor state not reset

[Chris Hofstaedtler]

Control: reassign -1 systemd

Hi,

this bug is about various terminal settings not being reset on tty1
(usually a Linux VC). Maybe also about other things, please see the
original bug message.

I am reassigning this to systemd based on:

1) util-linux agetty nowadays allows --init-string also on Linux
Virtual Consoles. That appears to be a valid option to have a
"reproducible" console. See [1] for slightly more info.

2) systemd provides getty@.service, which controls agetty startup.
This unit also specifies --noclear, which might be related.

Considering this, I believe util-linux agetty is not in the position
to make the requested change, and probably also SHOULD not (it is
not setting up the console in the first place).

If this change should happen, it can (and IMO should) by shipping
a modified getty@.service. Or, users can locally override it if they
desire the change, but if Debian does not.

BR,
Chris

Bug#996848: bs1770gain FTBFS: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]

[Helmut Grohne]

Source: bs1770gain
Version: 0.8.3-2
Severity: serious
Tags: ftbfs

bs1770gain fails to build from source (probably due to gcc-11). A
non-parallel build now ends as follows:

| gcc -DHAVE_CONFIG_H -I. -I..  -I../libpbutil -I../libff -I../lib1770-2 
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include  -Wstrict-prototypes -Wextra 
-Wreturn-type -Wcast-qual -Wcast-align -Wpointer-arith -Wformat -Wall -Werror 
-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o bg_analyzer.o bg_analyzer.c
| bg_analyzer.c: In function ‘bg_analyzer_album_suffix’:
| bg_analyzer.c:435:11: error: this ‘if’ clause does not guard... 
[-Werror=misleading-indentation]
|   435 |   if (_print_xml_vmt==param->print.vmt)
|   |   ^~
| In file included from ../libpbutil/pbutil_priv.h:22,
|  from ./bg.h:43,
|  from bg_analyzer.c:22:
| ../libpbutil/pbutil.h:107:33: note: ...this statement, but the latter is 
misleadingly indented as if it were guarded by the ‘if’
|   107 | #define _FPRINTFV(f,format,...) fprintf(f,format,__VA_ARGS__)
|   | ^~~
| bg_analyzer.c:437:13: note: in expansion of macro ‘_FPRINTFV’
|   437 | _FPRINTFV(stdout,"\"%" PBU_PRIs "\"",tree->source.path);
|   | ^
| cc1: all warnings being treated as errors
| make[4]: *** [Makefile:516: bg_analyzer.o] Error 1
| make[4]: Leaving directory '/<>/libbg'
| make[3]: *** [Makefile:372: all] Error 2
| make[3]: Leaving directory '/<>/libbg'
| make[2]: *** [Makefile:390: all-recursive] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:331: all] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:7: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut

Bug#996847: sysrepo-plugind fails to start

[Nicholas Brown]

Package: sysrepo-plugind
Version: 1.4.70-4
Severity: grave

Appears to be due to this error when the error starts:

sysrepo-plugind error: Creating plugins dir
"/usr/lib/x86_64-linux-gnu/sysrepo/plugins" failed (Read-only file system).

Should this directory be created as part of the debian package installed?
(or if the plugin directory contains runtime generated data, should
-DPLUGINS_PATH be set to something under /var/ instead of default?
Somewhat related; should -DREPO_PATH be set to be under /var instead of
it's default under /etc as again it might contain runtime generated
content?)

-

$ sudo apt install sysrepo-plugind
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libsysrepo5 libyang1
The following NEW packages will be installed:
  libsysrepo5 libyang1 sysrepo-plugind
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 605 kB of archives.
After this operation, 1,757 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian bullseye/main amd64 libyang1 amd64
1.0.225-1.1 [452 kB]
Get:2 http://deb.debian.org/debian bullseye/main amd64 libsysrepo5 amd64
1.4.70-4 [143 kB]
Get:3 http://deb.debian.org/debian bullseye/main amd64 sysrepo-plugind
amd64 1.4.70-4 [10.8 kB]
Fetched 605 kB in 0s (2,654 kB/s)
Selecting previously unselected package libyang1.
(Reading database ... 70421 files and directories currently installed.)
Preparing to unpack .../libyang1_1.0.225-1.1_amd64.deb ...
Unpacking libyang1 (1.0.225-1.1) ...
Selecting previously unselected package libsysrepo5:amd64.
Preparing to unpack .../libsysrepo5_1.4.70-4_amd64.deb ...
Unpacking libsysrepo5:amd64 (1.4.70-4) ...
Selecting previously unselected package sysrepo-plugind.
Preparing to unpack .../sysrepo-plugind_1.4.70-4_amd64.deb ...
Unpacking sysrepo-plugind (1.4.70-4) ...
Setting up libyang1 (1.0.225-1.1) ...
Setting up libsysrepo5:amd64 (1.4.70-4) ...
Setting up sysrepo-plugind (1.4.70-4) ...
Created symlink
/etc/systemd/system/multi-user.target.wants/sysrepo-plugind.service →
/lib/systemd/system/sysrepo-plugind.service.
Processing triggers for libc-bin (2.31-13+deb11u2) ...

$ sudo systemctl status sysrepo-plugind
● sysrepo-plugind.service - YANG-based configuration and operational state
data store
 Loaded: loaded (/lib/systemd/system/sysrepo-plugind.service; enabled;
vendor preset: enabled)
 Active: failed (Result: exit-code) since Tue 2021-10-19 16:05:51 BST;
2s ago
Process: 1234109 ExecStart=/usr/bin/sysrepo-plugind -d -v 2
(code=exited, status=1/FAILURE)
   Main PID: 1234109 (code=exited, status=1/FAILURE)
CPU: 9ms

Oct 19 16:05:51 dev systemd[1]: sysrepo-plugind.service: Scheduled restart
job, restart counter is at 5.
Oct 19 16:05:51 dev systemd[1]: Stopped YANG-based configuration and
operational state data store.
Oct 19 16:05:51 dev systemd[1]: sysrepo-plugind.service: Start request
repeated too quickly.
Oct 19 16:05:51 dev systemd[1]: sysrepo-plugind.service: Failed with result
'exit-code'.
Oct 19 16:05:51 dev systemd[1]: Failed to start YANG-based configuration
and operational state data store.

$ sudo journalctl -u sysrepo-plugind.service --no-pager
Oct 19 16:05:50 dev systemd[1]: Started YANG-based configuration and
operational state data store.
Oct 19 16:05:50 dev sysrepo-plugind[1234016]: sysrepo-plugind error:
Creating plugins dir "/usr/lib/x86_64-linux-gnu/sysrepo/plugins" failed
(Read-only file system).
Oct 19 16:05:50 dev systemd[1]: sysrepo-plugind.service: Main process
exited, code=exited, status=1/FAILURE
Oct 19 16:05:50 dev systemd[1]: sysrepo-plugind.service: Failed with result
'exit-code'.
Oct 19 16:05:50 dev systemd[1]: sysrepo-plugind.service: Scheduled restart
job, restart counter is at 1.
Oct 19 16:05:50 dev systemd[1]: Stopped YANG-based configuration and
operational state data store.
Oct 19 16:05:50 dev systemd[1]: Started YANG-based configuration and
operational state data store.
Oct 19 16:05:50 dev sysrepo-plugind[1234099]: sysrepo-plugind error:
Creating plugins dir "/usr/lib/x86_64-linux-gnu/sysrepo/plugins" failed
(Read-only file system).
Oct 19 16:05:50 dev systemd[1]: sysrepo-plugind.service: Main process
exited, code=exited, status=1/FAILURE
Oct 19 16:05:50 dev systemd[1]: sysrepo-plugind.service: Failed with result
'exit-code'.
Oct 19 16:05:51 dev systemd[1]: sysrepo-plugind.service: Scheduled restart
job, restart counter is at 2.
Oct 19 16:05:51 dev systemd[1]: Stopped YANG-based configuration and
operational state data store.
Oct 19 16:05:51 dev systemd[1]: Started YANG-based configuration and
operational state data store.
Oct 19 16:05:51 dev sysrepo-plugind[1234102]: sysrepo-plugind error:
Creating plugins dir "/usr/lib/x86_64-linux-gnu/sysrepo/plugins" failed
(Read-only file system).
Oct 19 16:05:51 dev systemd[1]: sysrepo-plugind.service: Main process
exited, code=exited, status=1/FAILURE
Oct 19 

Bug#996846: RM: pythia8 -- RoQA, unmaintained, low popcon

[Tobias Frost]

Source: pythia8
Severity: serious

Control: block -1 by 996845
Control: block 996845 by -1

Dear Maintainer,

pythia8 is unmaintained (see MIA bug #925039) and was left barely floating
by NMUs since 2015.
It has no reverse dependencies in Debian, beside hepmc, which is a circular
dependency (and also a candidate for RM)

It was never part of any Debian release.

I therefore propose to RM the package, after rivet has been RMed.

If you disagree, just close this bug, but please show the package some love.
Especially, it is in need of an human maintainer (refering to Policy 5.6.3)

If you agree, reassign the bug to ftp.debian.org

If there is no answer, I will reassing the bug in exactly 3 months
to ftp.debian.org to make the RM happen.

--
tobi

Bug#996845: RM: hepmc -- RoQA, unmaintained, RC-buggy, low-popcon

[Tobias Frost]

Source: hepmc
Severity: normal
Control: block -1 by 996843

Dear Maintainer,

hepmc is unmaintained (see MIA bug #925104).
It has no reverse dependencies in Debian, beside rivet and pythia8,
both packages are in the same unmaintained state.
It was never part of any Debian release.

It is currently RC buggy with this bug:
#916132 [S|⛺|  ] [src:hepmc] hepmc FTBFS: FAIL testWeights

I therefore propose to RM the package, after rivet has been RMed.

If you disagree, just close this bug, but please show the package some love.
Especially, it is in need of an human maintainer (refering to Policy 5.6.3)

If you agree, reassign the bug to ftp.debian.org

If there is no answer, I will reassing the bug in exactly 3 months
to ftp.debian.org to make the RM happen.

--
tobi

Bug#996843: RM: rivet -- RoQA, unmaintained, python2, lowpopcon, RC-buggy

[Tobias Frost]

Package: rivet
Severity: serious

rivet is unmaintained (see MIA bug #925075) and lacking serverily behing 
upsteam.
It has no reverse dependencies in Debian.
It was never part of any Debian release.

It is currently RC buggy with those bugs:
#966790 [S|  |  ] [src:rivet] rivet: Unversioned Python removal in sid/bullseye
#954648 [S|  |↝] [rivet] FTBFS with Boost 1.71

I therefore propose to RM the package, and afterwards pythia8 and hepmc, which
has basically the same state of being de-facto orphaned.

If you disagree, just close this bug, but please show the package some love.
Especially, it is in need of an human maintainer (refering to Policy 5.6.3)

If you agree, reassign the bug to ftp.debian.org

If there is no answer, I will reassing the bug in exactly 3 months
to ftp.debian.org to make the RM happen.

--
tobi

Bug#996842: fs-uae FTCBFS: build vs host confusion

[Helmut Grohne]

Source: fs-uae
Version: 3.1.35-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fs-uae fails to cross build from source, because debian/rules confuses
the terms build and host. For an explanation refer to man
dpkg-architecture. In effect, it enables jit for architectures that
don't support it. Please consider applying the attached patch.

Unfortunately, this is not sufficient to make fs-uae cross buildable. It
contains a few tools that need to be run during build and fails doing so
with an "Exec format error". This kind of issue needs upstream support.
Very likely, fs-uae needs to start using AX_CC_FOR_BUILD and friends.
This is not implemented in the patch. Please close this bug when you
address just the build vs host confusion anyway.

Helmut
diff --minimal -Nru fs-uae-3.1.35/debian/changelog 
fs-uae-3.1.35/debian/changelog
--- fs-uae-3.1.35/debian/changelog  2021-10-17 14:27:52.0 +0200
+++ fs-uae-3.1.35/debian/changelog  2021-10-18 17:33:11.0 +0200
@@ -1,3 +1,10 @@
+fs-uae (3.1.35-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Fix build vs host confusion. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Oct 2021 17:33:11 +0200
+
 fs-uae (3.1.35-1) unstable; urgency=medium
 
   * New upstream release (Closes: #984138)
diff --minimal -Nru fs-uae-3.1.35/debian/rules fs-uae-3.1.35/debian/rules
--- fs-uae-3.1.35/debian/rules  2021-10-17 14:26:55.0 +0200
+++ fs-uae-3.1.35/debian/rules  2021-10-18 17:33:09.0 +0200
@@ -5,7 +5,7 @@
 #export DH_VERBOSE=1
 
 override_dh_auto_configure:
-ifneq ($(filter $(DEB_BUILD_ARCH), amd64 i386 kfreebsd-amd64 kfreebsd-i386 
x32),)
+ifneq ($(filter $(DEB_HOST_ARCH), amd64 i386 kfreebsd-amd64 kfreebsd-i386 
x32),)
dh_auto_configure -- --enable-jit
 else
dh_auto_configure -- --disable-jit

Bug#996840: libcache-memcached-fast-perl FTCBFS: missing Build-Depends: perl-xs-dev

[Helmut Grohne]

Source: libcache-memcached-fast-perl
Version: 0.27-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libcache-memcached-fast-perl fails to cross build from source, because
it misses a build dependency on perl-xs-dev. All perl extensions must
build-depend on this package, but they happen to successfully build
natively without. Please consider applying the attached patch.

Helmut
diff --minimal -Nru libcache-memcached-fast-perl-0.27/debian/changelog 
libcache-memcached-fast-perl-0.27/debian/changelog
--- libcache-memcached-fast-perl-0.27/debian/changelog  2021-09-22 
09:40:08.0 +0200
+++ libcache-memcached-fast-perl-0.27/debian/changelog  2021-10-19 
16:27:39.0 +0200
@@ -1,3 +1,10 @@
+libcache-memcached-fast-perl (0.27-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add missing Build-Depends: perl-xs-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Oct 2021 16:27:39 +0200
+
 libcache-memcached-fast-perl (0.27-2) unstable; urgency=medium
 
   * avoid parallel build;
diff --minimal -Nru libcache-memcached-fast-perl-0.27/debian/control 
libcache-memcached-fast-perl-0.27/debian/control
--- libcache-memcached-fast-perl-0.27/debian/control2021-09-12 
16:24:40.0 +0200
+++ libcache-memcached-fast-perl-0.27/debian/control2021-10-19 
16:27:38.0 +0200
@@ -4,6 +4,7 @@
 Build-Depends:
  debhelper-compat (= 13),
  memcached ,
+ perl-xs-dev,
 Maintainer: Debian Perl Group 
 Uploaders:
  Jonas Smedegaard ,

Bug#996841: openclonk FTCBFS: needs a native build pass

[Helmut Grohne]

Source: openclonk
Version: 8.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: block -1 by 984274

openclonk fails to cross build from source, because it needs a native
build pass to build c4group and import it during a cross build pass. The
attached patch implements that, by running cmake in a separate build
directory with reduced dependencies. The remaining required dependencies
are duplicated with :native. With this patch, a cross build fails like
#984274. Please consider applying the attached patch.

Helmut
diff --minimal -Nru openclonk-8.1/debian/changelog 
openclonk-8.1/debian/changelog
--- openclonk-8.1/debian/changelog  2021-01-03 22:24:57.0 +0100
+++ openclonk-8.1/debian/changelog  2021-10-18 19:19:59.0 +0200
@@ -1,3 +1,9 @@
+openclonk (8.1-3) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Pass -DIMPORT_NATIVE_TOOLS=path-to-native-build. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Oct 2021 19:19:59 +0200
+
 openclonk (8.1-2) unstable; urgency=medium
 
   * Remove myself from Uploaders and orphan the package.
diff --minimal -Nru openclonk-8.1/debian/clean openclonk-8.1/debian/clean
--- openclonk-8.1/debian/clean  1970-01-01 01:00:00.0 +0100
+++ openclonk-8.1/debian/clean  2021-10-18 19:19:07.0 +0200
@@ -0,0 +1 @@
+build-native
diff --minimal -Nru openclonk-8.1/debian/control openclonk-8.1/debian/control
--- openclonk-8.1/debian/control2021-01-03 22:24:57.0 +0100
+++ openclonk-8.1/debian/control2021-10-18 19:19:59.0 +0200
@@ -2,7 +2,7 @@
 Section: games
 Priority: optional
 Maintainer: Debian QA Group 
-Build-Depends: debhelper (>= 10), cmake (>= 3.0.2), libx11-dev, 
libxxf86vm-dev, libxrandr-dev, libxpm-dev, libglew-dev (>= 1.5.6), 
libgl1-mesa-dev, libpng-dev, libsdl2-dev, libsdl2-mixer-dev, libgtk-3-dev, 
qtbase5-dev, libjpeg-dev, zlib1g-dev, libupnp-dev, libfreetype6-dev, 
libboost-regex-dev, imagemagick, libtinyxml-dev, libopenal-dev, libalut-dev, 
libgtest-dev, libb2-dev
+Build-Depends: debhelper (>= 10), cmake (>= 3.0.2), libx11-dev, 
libxxf86vm-dev, libxrandr-dev, libxpm-dev, libglew-dev (>= 1.5.6), 
libgl1-mesa-dev, libpng-dev, libpng-dev:native, libsdl2-dev, libsdl2-mixer-dev, 
libgtk-3-dev, qtbase5-dev, libjpeg-dev, libjpeg-dev:native, zlib1g-dev, 
zlib1g-dev:native, libupnp-dev, libfreetype6-dev, libboost-regex-dev, 
imagemagick, libtinyxml-dev, libopenal-dev, libalut-dev, libgtest-dev, libb2-dev
 Standards-Version: 4.1.3
 Rules-Requires-Root: no
 Homepage: https://www.openclonk.org
diff --minimal -Nru openclonk-8.1/debian/rules openclonk-8.1/debian/rules
--- openclonk-8.1/debian/rules  2021-01-03 22:24:57.0 +0100
+++ openclonk-8.1/debian/rules  2021-10-18 19:19:59.0 +0200
@@ -12,7 +12,13 @@
 endif
 
 override_dh_auto_configure:
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_configure 
--builddirectory=build-native -- -DHEADLESS_ONLY=ON
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build 
--builddirectory=build-native -- c4group
+   dh_auto_configure -- $(CONFIG_ARGS) 
-DIMPORT_NATIVE_TOOLS=../build-native/NativeToolsExport.cmake
+else
dh_auto_configure -- $(CONFIG_ARGS)
+endif
 
 override_dh_strip:
dh_strip --dbgsym-migration='openclonk-dbg (<< 8.0-1~)'

Bug#996753: systemd: After bullseye upgrade: DNS does not work after changing wireless networks or suspending laptop

[Joel Cross]

Thanks for the clarification, and I will try those steps. I have never 
reconfigured my networking beyond the default settings, so could this be an 
upgrade issue?

-- 
  Joel Cross
  j...@kazbak.co.uk

On Mon, 18 Oct 2021, at 11:18 PM, Michael Biebl wrote:
> Am 18.10.2021 um 19:51 schrieb Joel Cross:
>> $ cat /etc/network/interfaces
>> source-directory /etc/network/interfaces.d
>> $ ls /etc/network/interfaces.d
>> setup
>> $ cat /etc/network/interfaces.d/setup
>> auto lo
>> iface lo inet loopback
>> 
>> auto eth0
>> iface eth0 inet dhcp
>
> So, you have eth0 configured by ifupdown, at the same time you use 
> NetworkManager to configure your network. So they stomp upon each other 
> and depending on the order in which they are started, it's likely they 
> mess up each others configuration
>
> If you want to use NetworkManager, please remove 
> /etc/network/interfaces.d/setup
>
> If you want to use ifupdown, my advice would be to either uninstall the 
> network-manager package or disable the NetworkManager.service
>
>> $ cat /etc/resolv.conf
>> 
>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
>> resolvconf(8)
>> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
>> # 127.0.0.53 is the systemd-resolved stub resolver.
>> # run "resolvectl status" to see details about the actual nameservers.
>> 
>> nameserver 127.0.0.1
>
> So, you apparently use resolvconf as well, adding another tool to the 
> mix and a local (caching) dns server. Another moving part.
>
>> $ ls -la /etc/resolv.conf
>> lrwxrwxrwx 1 root root 29 Sep 29 16:34 /etc/resolv.conf -> 
>> ../run/resolvconf/resolv.conf
>
>> $ cat /run/NetworkManager/resolv.conf
>> # Generated by NetworkManager
>> nameserver 192.168.1.1
>> 
>
> That looks ok.
>
>
> All in all, this looks like a local configuration issue and neither an 
> issue in systemd, ifupdown or NetworkManager.
>
>
> Attachments:
> * OpenPGP_signature

Bug#996837: lintian displays errors when checking webpack 5.58

[Yadd]

Package: lintian
Version: 2.109.0
Severity: normal

Hi,

when checking webpack 5.58, lintian produces some:

  Warning in processable ../node-webpack_5.58.2+dfsg+~cs5.11.7-1.dsc: Complex 
regular subexpression recursion limit (65534) exceeded at 
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 771

You can see it using https://salsa.debian.org/js-team/node-webpack

Thanks for maintaiing lintian !

Cheers,
Yadd

Bug#996833: Please include information whether system is usrmerged or not

[Sandro Tosi]

control: tags -1 +moreinfo

> given the decisions by the CTTE to go with a merged-/usr file system
> layout, I think it would be useful (at least during the transition
> phase), if reportbug included the information whether a system is
> already using such a file system layout or not.
>
> reportbug already includes:
>
> Shell: /bin/sh linked to /bin/dash
>
> One can sort of deduce this information from the above line (on a
> merged-/usr system /bin/sh typically points to /usr/bin/dash), and most
> shells are typically installed in /bin, so I could understand if you
> reject this bug report.

we'd be happy to add this, but (as for other "recent" additions to the
system info section, such as what init system is in use) the burden of
coming up with a good/valid heuristics is on the requestor (simply
because we may not be in a good position to know all the intricacies).

While a MR implementing this is of course welcome, you can also simply
give us a good way to determine if it's usrmerged or not and we can
add that information; an reference implementation (still using the
init system example from above) is
https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/utils.py#L1220-1241

Since we also try to keep that section of the bug report contained in
size, do we need to add a new line for all bug reports? do we want to
start first with only adding a line if a system is usr-merged (which
is the least common case)? can we merge this information with another
sys-info line already present in every bug report?

thanks!

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

Bug#992132: [Pkg-utopia-maintainers] Bug#992132: firewalld: ipv6_rpfilter blocks wireguard traffic

[Michael Biebl]

Am 12.08.21 um 21:18 schrieb Lego:

Package: firewalld
Version: 0.9.3-2
Severity: important
Tags: ipv6
X-Debbugs-Cc: legog...@protonmail.com

Dear Maintainer,

The current version of firewalld breaks outbound ipv6 networking for wireguard
tunnels. More specifically, rp_filter gets applied too early, resulting
in fwmarked packets getting dropped. Reported and fixed in upstream (as
of 1.0.0).

Upstream issue: https://github.com/firewalld/firewalld/issues/603
Patch: 
https://github.com/firewalld/firewalld/commit/f250c2c507d63419a2c263f3adb47cef93613a5f


I've marked the issue as fixed in 1.0.1-1 and I'm now considering 
whether to fix this issue for stable/bullseye as well.


Would you be willing to test a backport of the above fix?
If so, I could provide test packages.

Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996836: node-webpack: webpack embeds binary files in es-module-lexer component

[Yadd]

Source: node-webpack
Version: 5.58.2+~cs5.11.7-1
Severity: serious
Justification: DFSG

webpack 5.58 uses es-module-lexer. For now, this component is downloaded
including some binary files (WASM,...). This should be fixed before
going to unstable.

Bug#990067: Copyright file has license inconsistencies under 'BSD-2-Clause'

[Chris Hofstaedtler]

Hi Ayan Mahapatra,

* Ayan Mahapatra  [211019 14:07]:
> 1. The copyright file has a License paragraph with `License: BSD-2-Clause`
[..]
> These should be reported correctly in the copyright file. I'm interested in
> creating a patch for the same.

Do you have a patch ready for this?

Thanks,
Chris

Bug#996834: pytools: please make the build reproducible

[Chris Lamb]

Source: pytools
Version: 2021.2.8-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
pytools could not be built reproducibly.

This is because it calculates the project name from the directory it is
built from (in the patched doc/conf.py) so the documentation varies
depending on the buildpath.

A patch is attached that hardcodes the project name to 'pytools'. This is
not ideal, but this patch is essentially a code copy of a larger problem
so the special-casing is not as bad as it might initially appear.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-documentation.patch   2021-10-19 
14:29:58.545257259 +0100
--- b/debian/patches/reproducible-documentation.patch   2021-10-19 
14:30:24.053348504 +0100
@@ -3,8 +3,6 @@
 Forwarded: not-needed
 Author: Tomasz Rybak 
 Last-Update: 2021-10-16
-Index: pytools-2021.2.8/doc/conf.py
-===
 --- pytools-2021.2.8.orig/doc/conf.py
 +++ pytools-2021.2.8/doc/conf.py
 @@ -1,9 +1,86 @@
@@ -20,7 +18,7 @@
 +
 +html_show_sourcelink = True
 +
-+project = _basename(_dirname(_dirname(__file__)))
++project = "pytools"
 +
 +autoclass_content = "class"
 +
--- a/doc/conf.py   2021-10-19 14:29:58.545257259 +0100
--- b/doc/conf.py   2021-10-19 14:31:11.949512864 +0100
@@ -6,7 +6,7 @@
 
 html_show_sourcelink = True
 
-project = _basename(_dirname(_dirname(__file__)))
+project = "pytools"
 
 autoclass_content = "class"
 

Bug#996833: Please include information whether system is usrmerged or not

[Michael Biebl]

Package: reportbug
Version: 11.1.0
Severity: wishlist
X-Debbugs-Cc: m...@linux.it

Hi,

given the decisions by the CTTE to go with a merged-/usr file system
layout, I think it would be useful (at least during the transition
phase), if reportbug included the information whether a system is
already using such a file system layout or not.

reportbug already includes:

Shell: /bin/sh linked to /bin/dash

One can sort of deduce this information from the above line (on a
merged-/usr system /bin/sh typically points to /usr/bin/dash), and most
shells are typically installed in /bin, so I could understand if you
reject this bug report.

Michael