date:20230205

Control: retitle -1 mariadb: FTBFS on s390x: crash on munmap(),
free(), aligned_free()

For the record, the latest build
https://buildd.debian.org/status/fetch.php?pkg=mariadb=s390x=1%3A10.11.1-3=1675662468=0
shows other test failures again, but the stack trace seem to have
munmap(), free(), aligned_free() etc in common:

main.bootstrap_innodb 'innodb'   w2 [ fail ]  Found
warnings/errors in server log file!
Test ended at 2023-02-06 05:41:47
line
Attempting backtrace. You can use the following information to find out
^ Found warnings in /<>/builddir/mysql-test/var/2/log/mysqld.1.err
ok

 - found 'core' (0/5)
Core generated by '/<>/builddir/sql/mariadbd'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--
[New LWP 2264728]
[New LWP 2264825]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Core was generated by `/<>/builddir/sql/mariadbd
--defaults-group-su'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x03ffb4448992 in kill () from /lib/s390x-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x3ffb536a820 (LWP 2264728))]
#0  0x03ffb4448992 in kill () from /lib/s390x-linux-gnu/libc.so.6
#1  0x02aa06f107c4 in handle_fatal_signal (sig=) at
./sql/signal_handler.cc:367
#2  
#3  0x02aa073fc26a in my_read (Filedes=, Buffer=0xd
, Count=4096,
MyFlags=) at ./mysys/my_read.c:63
#4  0x02aa06f10266 in output_core_info () at ./sql/signal_handler.cc:90
#5  0x02aa06f10792 in handle_fatal_signal (sig=) at
./sql/signal_handler.cc:351
#6  
#7  0x03ffb450e632 in munmap () from /lib/s390x-linux-gnu/libc.so.6
#8  0x03ffb44a7790 in free () from /lib/s390x-linux-gnu/libc.so.6
#9  0x02aa07140022 in aligned_free (ptr=) at
./include/aligned.h:37
#10 pfs_free (ptr=, size=0, klass=0x2aa086c6900
) at
./storage/perfschema/pfs_global.cc:83
#11 pfs_free (ptr=, size=0, klass=0x2aa086c6900
) at
./storage/perfschema/pfs_global.cc:78
#12 pfs_free_array (klass=0x2aa086c6900
, n=n@entry=256, size=size@entry=32,
ptr=) at ./storage/perfschema/pfs_global.cc:134
#13 0x02aa07135e82 in PFS_thread_allocator::free_array
(this=, array=array@entry=0x2aa08f4fd30) at
./storage/perfschema/pfs_buffer_container.cc:659
#14 0x02aa071425da in PFS_buffer_scalable_container::cleanup
(this=) at
./storage/perfschema/pfs_buffer_container.h:506
#15 PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:491
#16 cleanup_instruments () at ./storage/perfschema/pfs_instr.cc:233
#17 0x02aa0715000c in cleanup_performance_schema () at
./storage/perfschema/pfs_server.cc:296
#18 0x02aa071504f0 in shutdown_performance_schema () at
./storage/perfschema/pfs_server.cc:326
#19 0x02aa06bbf912 in mysqld_exit (exit_code=exit_code@entry=0) at
./sql/mysqld.cc:1943
#20 0x02aa06bca4fe in mysqld_main (argc=,
argv=) at ./sql/mysqld.cc:6040
#21 0x03ffb442b84a in ?? () from /lib/s390x-linux-gnu/libc.so.6
#22 0x03ffb442b932 in __libc_start_main () from
/lib/s390x-linux-gnu/libc.so.6
#23 0x02aa06bbd378 in _start ()


main.host_cache_size_functionality 'innodb' w2 [ fail ]  Found
warnings/errors in server log file!
Test ended at 2023-02-06 05:44:47
line
Attempting backtrace. You can use the following information to find out
^ Found warnings in /<>/builddir/mysql-test/var/2/log/mysqld.1.err
ok

 - found 'core' (2/5)
Core generated by '/<>/builddir/sql/mariadbd'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--
[New LWP 2267523]
[New LWP 2268734]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Core was generated by `/<>/builddir/sql/mariadbd
--defaults-group-su'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x03ffa7e48992 in kill () from /lib/s390x-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x3ffa8d6a820 (LWP 2267523))]
#0  0x03ffa7e48992 in kill () from /lib/s390x-linux-gnu/libc.so.6
#1  0x02aa0f2907c4 in handle_fatal_signal (sig=) at
./sql/signal_handler.cc:367
#2  
#3  0x02aa0f77c26a in my_read (Filedes=, Buffer=0xd
, Count=4096,
MyFlags=) at ./mysys/my_read.c:63
#4  0x02aa0f290266 in output_core_info () at ./sql/signal_handler.cc:90
#5  0x02aa0f290792 in handle_fatal_signal (sig=) at
./sql/signal_handler.cc:351
#6  
#7  0x03ffa7f0e632 in munmap () from /lib/s390x-linux-gnu/libc.so.6
#8  0x03ffa7ea7790 in free () from /lib/s390x-linux-gnu/libc.so.6
#9  0x02aa0f4c0022 in aligned_free (ptr=) at
./include/aligned.h:37
#10 pfs_free (ptr=, size=2841600, klass=0x2aa10a46700
) at
./storage/perfschema/pfs_global.cc:83
#11 pfs_free (ptr=, size=2841600, klass=0x2aa10a46700
) at

Bug#1030604: mariadb breaks mariadb-10.6 autopkgtest: Variable 'innodb_compression_algorithm' can't be set to the value of 'lz4'

Hi!

The error message "Variable 'innodb_compression_algorithm' can't be
set to the value of 'lz4'" is from the first test, and it fails.
Actually all tests fail because in MariaDB 10.11 the compression
methods are packaged in separate packages.

The root cause here is that the test in 10.6 depends on simply
'mariadb-server'. With a new 'mariadb-server' from 10.11 the test of
10.6 will fail. The test would not fail if the autopkgtests originally
had a dependency on 'mariadb-server-10.6'.

It does not seem worth the effort to upload a new src:mariadb-10.6
just to fix this. It is a pure test issue and not a symptom of a real
failure.

Can we have a temporary override to shut down the src:mariadb-10.6
autopkgtests in Debian CI so that 10.11 can enter Debian
testing/Bookworm and I can then file request to remove
src:mariadb-10.6 from testing and unstable?

Bug#1030287: simple-cdd: What if reprepro_retries is reached?

2023-02-05 Thread Arnaud Rebillout




On 06/02/2023 10:07, Vagrant Cascadian wrote:

On 2023-02-06, Arnaud Rebillout wrote:

By the way, as I see that simple-cdd is in Salsa's debian group: are you
Ok if we (Kali Linux developers, that would be Raphael Hertzog or me)
release the package from time to time, or do you prefer to be taking
care of that?

I would be fine with that. I do not actually use simple-cdd ... other
than to test simple-cdd... so someone who actually uses it for something
real would probably keep it in better shape... :)

Feel free to put yourselves in the Uploaders field!


Done, and I just uploaded a new release. Thanks!


--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1030622: tex-common package post-installation script subprocess returned error exit status 1

2023-02-05 Thread Stéphane Glondu


Hello,

Le 05/02/2023 à 20:52, Hilmar Preuße a écrit :

Today the new texlive-base & texlive-extra did migrate to testing and
hence were upgraded on your system. The texlive-lang did not migrate
yet, this will happen soon. Once texlive-lang-japanese is upgraded,
please repeat the test. Is suspect an incompatibility in these packages,
as I'm not able to reproduce the issue using unstable.


Then, a dependency (Breaks and/or Conflicts) is missing somewhere...

I just upgraded texlive-lang-* and indeed the problem seems to have 
disappeared.



Cheers,

--
Stéphane

Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors

2023-02-05 Thread tony mancill

On Sun, Feb 05, 2023 at 08:14:31PM +, James Addison wrote:
> Source: openjfx
> Followup-For: Bug #1026962
> 
> Could the following build-related scripting be something to do with it?
> 
>   - 
> https://salsa.debian.org/java-team/openjfx/-/blob/debian/11.0.11+1-1.1/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm#L494-499

I don't think it's this one, because nproc returns the right value on a
s390x porterbox, as does /proc/cpuinfo.

>   - 
> https://salsa.debian.org/java-team/openjfx/-/blob/debian/11.0.11+1-1.1/modules/javafx.web/src/main/native/Tools/Scripts/build-webkit#L300-305

YES!

> (perhaps something about the way that numberOfCPUs is being evaluated on s390x
> hosts isn't matching the expectations of the build script)

I will try another build on the porterbox defining NUMBER_OF_PROCESSORS.

Thank you for this pointer.


signature.asc
Description: PGP signature

Bug#1006529: Info received (Bug#1006529: Info received (mariadb: FTBFS on hppa: builds, but test suite crashes immediately with "'aio write' returned OS error 0")))

For the record, latest build
https://buildd.debian.org/status/fetch.php?pkg=mariadb=hppa=1%3A10.11.1-3=1675654714=0
passed but testsuite failed with:

main.mysqldump 'innodb'  w25 [ fail ]
Test ended at 2023-02-06 03:25:25
CURRENT_TEST: main.mysqldump
--- /<>/mysql-test/main/mysqldump.result 2022-11-14
18:10:21.0 +
+++ /<>/mysql-test/main/mysqldump.reject 2023-02-06
03:25:24.020036990 +
@@ -5524,7 +5524,7 @@
 proc
 one
 DROP DATABASE bug25717383;
-mariadb-dump: Got error: 2005: "Unknown server host 'unknownhost'"
when trying to connect
+mariadb-dump: Got error: 2002: "Can't connect to server on
'unknownhost'" when trying to connect
 mariadb-dump: Couldn't execute 'SHOW SLAVE STATUS': Server has gone away (2006)
 Usage: mariadb-dump [OPTIONS] database [tables]
 OR mariadb-dump [OPTIONS] --databases DB1 [DB2 DB3...]

Bug#1030652: ITP: libdbix-class-factory-perl -- factory-style fixtures for DBIx::Class

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdbix-class-factory-perl
  Version : 0.04
  Upstream Author : Vadim Pushtaev 
* URL : https://metacpan.org/release/DBIx-Class-Factory
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : factory-style fixtures for DBIx::Class

Ruby has factory_girl, Python has factory_boy. Now Perl has
DBIx::Class::Factory.

Creating big fixture batches may be a pain. This module provides easy way
of creating data in database via DBIx::Class.

To create a factory just derive from DBIx::Class::Factory and apply some
settings. You can also add some data at the moment of creating instance,
redefining factory defaults.

Tests for this module contains a bunch of useful examples.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030651: ITP: libdbix-class-graph-perl -- represent a graph in a relational database using DBIC

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdbix-class-graph-perl
  Version : 1.05
  Upstream Author : Moritz Onken 
* URL : https://metacpan.org/release/DBIx-Class-Graph
* License : BSD-3-clause
  Programming Lang: Perl
  Description : represent a graph in a relational database using DBIC

DBIx::Class::Graph provides a module to create and interact with a directed
graph. It will take care of storing the information in a relational database.
It uses Graph for calculations. This module extends the DBIx::Class::ResultSet.
Some methods are added to the resultset, some to the row objects.

SEE ALSO

 https://metacpan.org/pod/Graph
 https://metacpan.org/pod/DBIx::Class
 https://metacpan.org/pod/DBIx::Class::Tree

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030650: ITP: libdbix-bulkloader-mysql-perl -- Perl extension for mysql bulk loading

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdbix-bulkloader-mysql-perl
  Version : 1.006
  Upstream Author : Michael Shipper
* URL : https://metacpan.org/release/DBIx-BulkLoader-Mysql
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl extension for mysql bulk loading

DBIx::BulkLoader::Mysql provides a simple buffering bulk-loader interface
for mysql.

SEE ALSO
 https://metacpan.org/pod/DBI
 https://metacpan.org/pod/DBD::mysql

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030649: ITP: libchild-perl -- Object oriented simple interface to fork()

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libchild-perl
  Version : 0.013
  Upstream Author : Chad Granum 
* URL : https://metacpan.org/release/Child
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Object oriented simple interface to fork()

Fork is too low level, and difficult to manage. Often people forget to exit
at the end, reap their children, and check exit status. The problem is the
low level functions provided to do these things. Throw in pipes for IPC and
you just have a pile of things nobody wants to think about.

Child is an Object Oriented interface to fork. It provides a clean way to
start a child process, and manage it afterwords. It provides methods for
running, waiting, killing, checking, and even communicating with a child
process.

NOTE: kill() is unpredictable on windows, strawberry perl sends the kill
signal to the parent as well as the child.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#919348: xfce4-screensaver: Accidental upload to unstable while fixing bug #919151

2023-02-05 Thread Konomi

Could this bug be closed and allow xfce4-screensaver to flow to
testing/stable? I know there are concerns about the stability but the
4.16 release has been out for 2 years. And as far as I know
light-locker is still recommended over xfce4-screensaver so this
package would not be a default for everybody. But closing this bug
would allow for those of us who wish to use the package to do so
without resorting to more complicated means of doing so.

Please consider closing the bug. Thank you.

Bug#1030648: ITP: libdbix-class-tree-perl -- manipulate and anaylze tree structured data

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdbix-class-tree-perl
  Version : 0.03003
  Upstream Author : Aran Clary Deltac 
* URL : https://metacpan.org/release/DBIx-Class-Tree
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : manipulate and anaylze tree structured data

DBIx::Class::Tree provides the tools to represent, modify, and analyze trees
of data with DBIx::Class.

COMPONENTS

DBIx::Class::Tree::AdjacencyList
 Manage a tree of data using the common adjacency list model.

DBIx::Class::Tree::AdjacencyList::Ordered
 Glue DBIx::Class::Ordered and DBIx::Class::Tree::AdjacencyList together.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030647: ITP: libpath-class-uri-perl -- Serializes and deserializes Path::Class objects as file:// URI

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpath-class-uri-perl
  Version : 0.08
  Upstream Author : Tatsuhiko Miyagawa 
* URL : https://metacpan.org/release/Path-Class-URI
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Serializes and deserializes Path::Class objects as file:// 
URI

Path::Class::URI is an extension to Path::Class to serialize file path from
and to file:// form URI objects.

Path::Class::URI encodes and decodes non URI-safe characters using its
literal byte encodings. If you call uri methods on Win32 Path::File objects,
you'll get local filename encodings.

If you want to avoid that and always use UTF-8 filename encodings in URI, see
Path::Class::Unicode bundled in this distribution.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030646: ITP: libbiblio-zotero-db-perl -- helper module to access the Zotero SQLite database

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libbiblio-zotero-db-perl
  Version : 0.004
  Upstream Author : Zakariyya Mughal 
* URL : https://metacpan.org/release/Biblio-Zotero-DB
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : helper module to access the Zotero SQLite database

Biblio::Zotero::DB provides a helper module to access a Zotero SQLite database

Example code:

 use Biblio::Zotero::DB;
 use List::UtilsBy qw(min_by);

 # find the most recently modified
 my $newest = min_by { -M } @{Biblio::Zotero::DB->find_profile_directories};
 my $db = Biblio::Zotero::DB->new( profile_directory => $newest  );

 # if there is an issue with the database lock here,
 # see Biblio::Zotero::DB::Role::CopyDB
 $db->schema->resultset('Item')->all;

See also:

 https://metacpan.org/pod/DBIx::Class
 http://www.zotero.org/support/zotero_data

Zotero is a free and open-source reference management software to manage
bibliographic data and related research materials, such as PDF files.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy

2023-02-05 Thread tony mancill

On Thu, Jan 12, 2023 at 08:55:14AM +0100, Alexandre Rossi wrote:
> If I can help providing a build ready to upload for this, do not hesitate to 
> ping me.

Hi Alex,

I'm +1 for the change, but at this point I propose we wait for bookworm
to release.  I'm not sure what could go wrong, but it seems late in the
release cycle for this change.  How about an upload to experimental?

Cheers,
tony

signature.asc
Description: PGP signature

Bug#1029594: Fails to authenticate mit o365

2023-02-05 Thread Harshula


Hi Carsten,

1) Did you use Thunderbird's Release Candidate Build 1 instead of 
Release Candidate Build 2 for the Debian 102.7.1 release [1]? It appears 
you uploaded the Debian package on the "2023-01-24" [2]. Build 2 was 
only released on the 31st of January.


$ diff -rq build1/thunderbird-102.7.1/comm/mailnews/base/src/ 
debian/thunderbird-102.7.1/comm/mailnews/base/src/


$ diff -rq build2/thunderbird-102.7.1/comm/mailnews/base/src/ 
debian/thunderbird-102.7.1/comm/mailnews/base/src/
Files build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm and 
debian/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm differ
Files 
build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm 
and 
debian/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm differ


2) The authentication successfully completed with the upstream build of 
Thunderbird 102.7.1 [3], whereas the authentication was in an infinite 
loop with the Debian build of Thunderbird 102.7.1.


Regards,
Harshula

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1814536
[2] 
https://tracker.debian.org/news/1413005/accepted-thunderbird-110271-1-source-into-unstable/
[3] 
https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/102.7.1/linux-x86_64/en-US/thunderbird-102.7.1.tar.bz2



https://download-origin.cdn.mozilla.net/pub/thunderbird/candidates/102.7.1-candidates/build1/source/

Filethunderbird-102.7.1.source.tar.xz   477M24-Jan-2023 03:33
Filethunderbird-102.7.1.source.tar.xz.asc   833 24-Jan-2023 03:33

$ sha256sum thunderbird-102.7.1.source.tar.xz
74cbf32140cbbd7954093f7adc1a1d0cf8a9b0f77dfd9d344540a111fed9ac20 
thunderbird-102.7.1.source.tar.xz



https://download-origin.cdn.mozilla.net/pub/thunderbird/candidates/102.7.1-candidates/build2/source/

Filethunderbird-102.7.1.source.tar.xz   487M31-Jan-2023 15:46
Filethunderbird-102.7.1.source.tar.xz.asc   833 31-Jan-2023 15:46

$ sha256sum thunderbird-102.7.1.source.tar.xz
00c9a215ec99b4ce1683c8581b5bb44759ad31cb1303bdec173c053fcee27c91 
thunderbird-102.7.1.source.tar.xz



https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/102.7.1/source/

Filethunderbird-102.7.1.source.tar.xz   487M01-Feb-2023 02:10
Filethunderbird-102.7.1.source.tar.xz.asc   833 01-Feb-2023 02:10

$ sha256sum thunderbird-102.7.1.source.tar.xz
00c9a215ec99b4ce1683c8581b5bb44759ad31cb1303bdec173c053fcee27c91 
thunderbird-102.7.1.source.tar.xz

$ diff -rq build1/thunderbird-102.7.1/ build2/thunderbird-102.7.1
Files build1/thunderbird-102.7.1/comm/chat/protocols/xmpp/xmpp-base.jsm and 
build2/thunderbird-102.7.1/comm/chat/protocols/xmpp/xmpp-base.jsm differ
Files build1/thunderbird-102.7.1/comm/mail/base/content/mailContextMenus.js and 
build2/thunderbird-102.7.1/comm/mail/base/content/mailContextMenus.js differ
Files build1/thunderbird-102.7.1/comm/mail/base/content/utilityOverlay.js and 
build2/thunderbird-102.7.1/comm/mail/base/content/utilityOverlay.js differ
Files 
build1/thunderbird-102.7.1/comm/mail/components/compose/content/MsgComposeCommands.js
 and 
build2/thunderbird-102.7.1/comm/mail/components/compose/content/MsgComposeCommands.js
 differ
Only in 
build2/thunderbird-102.7.1/comm/mail/components/extensions/test/browser: 
browser_ext_compose_bug1804796.js
Files 
build1/thunderbird-102.7.1/comm/mail/components/extensions/test/browser/browser.ini
 and 
build2/thunderbird-102.7.1/comm/mail/components/extensions/test/browser/browser.ini
 differ
Files build1/thunderbird-102.7.1/comm/mail/themes/windows/mail/mailWindow1.css 
and build2/thunderbird-102.7.1/comm/mail/themes/windows/mail/mailWindow1.css 
differ
Files build1/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm and 
build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm differ
Files build1/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm and 
build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm differ
Files build1/thunderbird-102.7.1/comm/mailnews/compose/src/nsMsgCompose.cpp and 
build2/thunderbird-102.7.1/comm/mailnews/compose/src/nsMsgCompose.cpp differ
Files 
build1/thunderbird-102.7.1/comm/mailnews/import/modules/AddrBookFileImporter.jsm
 and 
build2/thunderbird-102.7.1/comm/mailnews/import/modules/AddrBookFileImporter.jsm
 differ
Files 
build1/thunderbird-102.7.1/comm/mailnews/import/test/unit/resources/addressbook.json
 and 
build2/thunderbird-102.7.1/comm/mailnews/import/test/unit/resources/addressbook.json
 differ
Only in build2/thunderbird-102.7.1/comm/mailnews/import/test/unit/resources: 
dos_vcard_addressbook.vcf
Files 
build1/thunderbird-102.7.1/comm/mailnews/import/test/unit/test_AddrBookFileImporter.js
 and 
build2/thunderbird-102.7.1/comm/mailnews/import/test/unit/test_AddrBookFileImporter.js
 differ
Files build1/thunderbird-102.7.1/sourcestamp.txt and

Bug#1030632: bugs.debian.org: cannot select picture from a local directory to use as desktop background in kde plasma

2023-02-05 Thread George Olson





On 2/5/23 16:47, Don Armstrong wrote:

Control: reassign -1 kde-plasma-desktop

My guess is that this has something to do with kde-plasma-desktop, but
you're going to need to provide more information about which window
manager you're using, what version it is, and what you've most recently
installed.



Ok, thank you. I am using kwin window manager and light dm for my 
display manager. Here is my system data:


$ neofetch
   _,met$gg.  george@gigatribetrek
    ,g$$$P.   
  ,g$$P" """Y$$.".    OS: Debian GNU/Linux bookworm/sid x86_64
 ,$$P'  `$$$. Host: X570 AORUS ELITE WIFI -CF
',$$P   ,ggs. `$$b:   Kernel: 6.1.0-3-amd64
`d$$' ,$P"'   .    $$$    Uptime: 8 hours, 5 mins
 $$P  d$' ,    $$P    Packages: 3136 (dpkg)
 $$:  $$.   -    ,d$$'    Shell: bash 5.2.15
 $$;  Y$b._   _,d$P'  Resolution: 2560x1440, 1920x1080, 
2560x1440, 1920x1080

 Y$$.    `.`"YP"' DE: Plasma 5.26.5
 `$$b  "-.__  WM: KWin
  `Y$$    WM Theme: plastik
   `Y$$.  Theme: [Plasma], Breeze [GTK2/3]
 `$$b.    Icons: [Plasma], breeze [GTK2/3]
   `Y$$b. Terminal: konsole
  `"Y$b._ Terminal Font: Hack 11
  `"""    CPU: AMD Ryzen 9 5900X (24) @ 3.700GHz
  GPU: AMD ATI Radeon RX 6600/6600 XT/6600M
  Memory: 6367MiB / 32021MiB

$ cat /etc/X11/default-display-manager
/usr/sbin/lightdm

I haven't installed any new software recently, except for reportbug, and 
that was after this problem came up. The only thing I have installed are 
the daily updates with sudo apt update and sudo apt upgrade.


Here is my sources file:
$ cat /etc/apt/sources.list

deb http://deb.debian.org/debian/ bookworm main contrib non-free
deb-src http://deb.debian.org/debian/ bookworm main contrib non-free

deb http://security.debian.org/debian-security bookworm-security main 
contrib non-free
deb-src http://security.debian.org/debian-security bookworm-security 
main contrib non-free


# bullseye-updates, to get updates before a point release is made;
# see 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports

deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free
deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free

# enable the following in order to install the protonmail bridge, but 
then comment it out again

# deb http://deb.debian.org/debian bullseye main

Note that to install bookworm, I first installed bullseye and then 
changed the source names.

Bug#1030287: simple-cdd: What if reprepro_retries is reached?

2023-02-05 Thread Vagrant Cascadian

On 2023-02-06, Arnaud Rebillout wrote:
> On 03/02/2023 03:45, Vagrant Cascadian wrote:
>> Sounds like the default should at least be bumped to a larger value,
>> then.
>>
>> That has been the value since at least 2006, picked by finding the right
>> value at the time for the biggest profile I ever tested and doubling
>> it... there have been quite a few packages added to Debian since then,
>> so it is no surprise that it would need to be updated!
>>
>> Feel free to propose a higher value grounded in a current real world
>> use-case, and double it. :)
>
> I opened a merge request on Salsa:
>
> https://salsa.debian.org/debian/simple-cdd/-/merge_requests/10
>
> I just doubled the value and made it 40.
>
>  From the Kali Linux build logs I can see, the number of attempts goes 
> from 11 to 20. Unfortunately we don't keep daily build logs, only those 
> that fail, so I can't really tell what's the average number of attempts, 
> for example. I just know that "sometimes" we reach 20.

Seems reasonable. It really depends on what is in the profile(s) and how
complicated the dependency graph is...


>> Help is definitely appreciated! I have not really looked at simple-cdd
>> much since the previous release, and simple-cdd surely needs some help
>> now that we are into the early phases of a freeze cycle!
>
> And thanks for the quick feedback!
>
> By the way, as I see that simple-cdd is in Salsa's debian group: are you 
> Ok if we (Kali Linux developers, that would be Raphael Hertzog or me) 
> release the package from time to time, or do you prefer to be taking 
> care of that?

I would be fine with that. I do not actually use simple-cdd ... other
than to test simple-cdd... so someone who actually uses it for something
real would probably keep it in better shape... :)

Feel free to put yourselves in the Uploaders field!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1030645: adr-tools: cannot set PAGER with argument due to quote

2023-02-05 Thread 陳昌倬

Package: adr-tools
Version: 3.0.0-2
Severity: normal

Hi,

adr does not work when set $PAGER with argument (e.g. `/usr/bin/less -s`).
This is caused by quote in adr-help (`"$pager"`). Please help to check
if this quote can be removed.



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

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

-- no debconf information

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1030644: ITP: libbio-biblio-perl -- modules to access bibliographics repositories and handle citation files

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libbio-biblio-perl
  Version : 1.70
  Upstream Author : BioPerl Team 
* URL : https://metacpan.org/release/Bio-Biblio
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : modules to access bibliographics repositories and handle 
citation files

Bio::Biblio provides both methods to access bibliographic repositories, and to
handle citation files in different formats.

The modules comply (with some simplifications) with the specification
described in the OpenBQS project.

See also:
 http://www.ebi.ac.uk/~senger/openbqs

This distribution is part of the BioPerl project.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030643: aptitude: buggy handling of "Provides:" when trying to remove a package

2023-02-05 Thread Vincent Lefevre

Package: aptitude
Version: 0.8.13-5
Severity: normal

When I want to remove the libldap2-dev transitional package from the
command line, I get:

cventin:~> aptitude remove -s libldap2-dev
The following packages will be REMOVED:  
  libldap-dev{u} libldap2-dev 
0 packages upgraded, 0 newly installed, 2 to remove and 27 not upgraded.
Need to get 0 B of archives. After unpacking 1655 kB will be freed.
The following packages have unmet dependencies:
 libaprutil1-dev : Depends: libldap2-dev but it is not going to be installed
The following actions will resolve these dependencies:

 Keep the following packages at their current version: 
1) libldap-dev [2.5.13+dfsg-3 (now, testing, unstable)]

It appears that aptitude wants to remove libldap-dev too soon,
as this will break the dependencies: libaprutil1-dev depends on
libldap2-dev, which is provided by libldap-dev.

The other proposed solutions are not OK as they want to install or
remove other packages.

And from the TUI, if I type '-' on libldap2-dev, I get:

libldap2-dev (remove, 2.5.13+dfsg-3) will be removed.  ▒
   ▒
The following packages depend on libldap2-dev (remove, 2.5.13+dfsg-3) and will ▒
be broken by its removal:  ▒
   ▒
  * libaprutil1-dev (held/unchanged, 1.6.3-1) depends on libldap2-dev (provided▒
by libldap-dev 2.5.13+dfsg-3)  ▒

This is incorrect too, and the message is even buggy, as it correctly
says that libldap2-dev is provided by libldap-dev, but I'm not asking
to remove libldap-dev. So this doesn't make sense.

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20221231
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd371cc000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f6f7b805000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f6f7be2a000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f6f7b7d3000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f6f7be21000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f6f7b6e1000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f6f7b582000)
libboost_iostreams.so.1.74.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7f6f7b56a000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f6f7b20)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f6f7be1a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f6f7ae0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f6f7b48b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f6f7b469000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f6f7b01f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f6f7b44a000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f6f7b437000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f6f7add1000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f6f7adab000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7f6f7acf2000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 
(0x7f6f7acc5000)
libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f6f7abf6000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f6f7aaaf000)
libxxhash.so.0 => /usr/lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7f6f7aa9a000)
/lib64/ld-linux-x86-64.so.2 (0x7f6f7be88000)
libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 
(0x7f6f7aa9)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f6f7aa84000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f6f7aa5c000)

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX,

Bug#1030287: simple-cdd: What if reprepro_retries is reached?

2023-02-05 Thread Arnaud Rebillout


Hello Vagrant,


On 03/02/2023 03:45, Vagrant Cascadian wrote:

There were definitely cases of packages that had alternate dependencies
that will never be satisfyable (e.g. from contrib or non-free when
building only from main, or even ubuntu), so failing to resolve all
dependencies is not technically an error.

But sure, issuing a warning that reprepro_retries was reached and
suggesting to bump the value if later steps fail due to missing
dependencies seems reasonable...

The mirroring here is definitely a best-effort shotgun approach,
grabbing all the dependencies/recommends of any package you actually
expressed interest in (by putting in a .packages or .downloads file in
one of the profiles), and *trying* to pull in anything mentioned in any
Depends or Recommends or Provides field, recursively... and comparing
the previous run to the current run if anything changed.

If it does not pull in enough, I think debian-cd still
fails... maybe... I guess... hope? :)

In some cases, adding more packages to one of the .downloads files is
the appropriate workaround.


Thanks for the detailed explanations, much appreciated!



Sounds like the default should at least be bumped to a larger value,
then.

That has been the value since at least 2006, picked by finding the right
value at the time for the biggest profile I ever tested and doubling
it... there have been quite a few packages added to Debian since then,
so it is no surprise that it would need to be updated!

Feel free to propose a higher value grounded in a current real world
use-case, and double it. :)


I opened a merge request on Salsa:

https://salsa.debian.org/debian/simple-cdd/-/merge_requests/10

I just doubled the value and made it 40.

From the Kali Linux build logs I can see, the number of attempts goes 
from 11 to 20. Unfortunately we don't keep daily build logs, only those 
that fail, so I can't really tell what's the average number of attempts, 
for example. I just know that "sometimes" we reach 20.




Thanks for looking into it!

Help is definitely appreciated! I have not really looked at simple-cdd
much since the previous release, and simple-cdd surely needs some help
now that we are into the early phases of a freeze cycle!


And thanks for the quick feedback!

By the way, as I see that simple-cdd is in Salsa's debian group: are you 
Ok if we (Kali Linux developers, that would be Raphael Hertzog or me) 
release the package from time to time, or do you prefer to be taking 
care of that?


Cheers,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1024040: mariadb-10.6: FTBFS on alpha: relocation truncated to fit: GPREL16 against symbol `wsrep_debug'

2023-02-05 Thread Michael Cree

On Sun, Feb 05, 2023 at 03:35:39PM -0800, Otto Kekäläinen wrote:
> I applied the suggested fix now in
> https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/9e7ac5852d8a0ab96e25c4dd38dbc88354ee1c9e
> and it will be included in next upload. There are so many build
> failures that I don't have time to test each of them. If you have time
> to help, please test this on alpha, 

Yes, I tested a few days ago, and the patch fixes the link error, and
mariadb builds but ultimately failed in the test suite with:

Too many failed: Failed 19/386 tests, 95.08% were successful.

My recollection is that when I first reported this at version 10.6.7-3
only a couple of the tests failed, and were easily worked around, so it
would seem something further has gone wrong in the meantime.  But it
might have been a problem in the host system which had a full system
disk at the time, so I will rerun the test build as it could be quite
some time before the Alpha buildds pick up mariadb for building again
due to the backlog.

Cheers
Michael.

Bug#1030642: ITP: libbiblio-thesaurus-modrewrite-perl -- module to manipulate ontologies

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libbiblio-thesaurus-modrewrite-perl
  Version : 0.03
  Upstream Author : Nuno Carvalho 
* URL : https://metacpan.org/release/Biblio-Thesaurus-ModRewrite
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to manipulate ontologies

Biblio::Thesaurus::ModRewrite implements a compiler to run programs written
in a domain specific language that can be used to manipulate information in
ontologies. This domain specific language is called OML and is described in
the next section.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1028163: sshfs-fuse bug


El 5/2/23 a las 21:54, Steven Robbins escribió:


the test manifestly runs fine on buildds


Actually, that's not really true.

The tests do not even *run* on the buildds, because they are skipped.

Take this one for example:

https://buildd.debian.org/status/fetch.php?pkg=sshfs-fuse=amd64=3.7.3-1=1670232073=0

test/test_sshfs.py::test_sshfs[True-True-0-False] SKIPPED (FUSE kern...) [  6%]
test/test_sshfs.py::test_sshfs[True-True-0-True] SKIPPED (FUSE kerne...) [ 12%]
test/test_sshfs.py::test_sshfs[True-True-1-False] SKIPPED (FUSE kern...) [ 18%]
test/test_sshfs.py::test_sshfs[True-True-1-True] SKIPPED (FUSE kerne...) [ 25%]
test/test_sshfs.py::test_sshfs[True-False-0-False] SKIPPED (FUSE ker...) [ 31%]
test/test_sshfs.py::test_sshfs[True-False-0-True] SKIPPED (FUSE kern...) [ 37%]
test/test_sshfs.py::test_sshfs[True-False-1-False] SKIPPED (FUSE ker...) [ 43%]
test/test_sshfs.py::test_sshfs[True-False-1-True] SKIPPED (FUSE kern...) [ 50%]
test/test_sshfs.py::test_sshfs[False-True-0-False] SKIPPED (FUSE ker...) [ 56%]
test/test_sshfs.py::test_sshfs[False-True-0-True] SKIPPED (FUSE kern...) [ 62%]
test/test_sshfs.py::test_sshfs[False-True-1-False] SKIPPED (FUSE ker...) [ 68%]
test/test_sshfs.py::test_sshfs[False-True-1-True] SKIPPED (FUSE kern...) [ 75%]
test/test_sshfs.py::test_sshfs[False-False-0-False] SKIPPED (FUSE ke...) [ 81%]
test/test_sshfs.py::test_sshfs[False-False-0-True] SKIPPED (FUSE ker...) [ 87%]
test/test_sshfs.py::test_sshfs[False-False-1-False] SKIPPED (FUSE ke...) [ 93%]
test/test_sshfs.py::test_sshfs[False-False-1-True] SKIPPED (FUSE ker...) [100%]

and also:

SKIPPED [16] test/test_sshfs.py:33: FUSE kernel module does not seem to be 
loaded

Those tests are being skipped in the buildds at least since version 
2.10+repack-2.

Thanks.

Bug#1028163: sshfs-fuse: FTBFS (tries to use the ssh service from the host machine)


tags 1028163 + patch
thanks

Hi.

I propose that we make the package compliant with Policy 4.2 by disabling
the tests which blindly assume there is a ssh service running in the host
machine.

(Otherwise, what kind of build-depends should be used for that?)

The attached patch works for me.

To do it right without breaking Policy 4.2, the package should maybe
enable its own ssh service on a non-standard port to avoid conflict
with a more than possible standard ssh service in the host machine,
which may or may not be present.

Thanks.--- a/test/test_sshfs.py
+++ b/test/test_sshfs.py
@@ -30,6 +30,7 @@ def name_generator(__ctr=[0]):
 __ctr[0] += 1
 return 'testfile_%d' % __ctr[0]
 
+@pytest.mark.skip(reason="packages must not require network access to be 
built")
 @pytest.mark.parametrize("debug", (False, True))
 @pytest.mark.parametrize("cache_timeout", (0,1))
 @pytest.mark.parametrize("sync_rd", (True, False))

Bug#1030641: RM: dustmite [mips64el] -- RoQA; no longer builds on mips64el

2023-02-05 Thread Adrian Bunk

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Debian D Language Group 

dustmite no longer builds on mips64el, likely due to some regression
in the gcc D support on that architecture.

Bug#1030640: xraylib FTBFS sometimes.

2023-02-05 Thread Peter Green


Package: xraylib

While working on the python 3.11 transition in raspbian bookworm I ran
into a build failure of xraylib. I went and checked Debian reproducible
builds and found failures there too on armhf and i386 but not on arm64
or amd64. I also looked at the official build logs for Debian armhf
and noticed that it failed on the first attempt, but succeeded on the
second.

In all cases the line indicating the failure on armhf seems to be

FAILED: 
python/xraylib_np.cpython-311-arm-linux-gnueabihf.so.p/meson-generated_.._xraylib_np.c.o

While on i386 it seems to be

FAILED: 
python/xraylib_np.cpython-311-i386-linux-gnu.so.p/meson-generated_.._xraylib_np.c.o

It doesn't seem to fail every time, for example in the reproducible builds 
bookworm test
on i386, "rbuild" succeeded, but "build2" failed.

I'm really not sure what is going on here, but I thought it was at least
worthy of a bug report.

Bug#1030560: Ugly // in symlinks

2023-02-05 Thread David Bremner

Sven Joachim  writes:

>
> I have attached a patch which drops the extra second slash.
>
> Cheers,
>Sven

Thanks Sven, I'll most likely wait until after the freeze to apply that.

d

Bug#1030639: ITP: libperl-critic-toomuchcode-perl -- perlcritic add-ons that generally check for dead code

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libperl-critic-toomuchcode-perl
  Version : 0.18
  Upstream Author : Kang-min Liu 
* URL : https://metacpan.org/release/Perl-Critic-TooMuchCode
* License : Expat
  Programming Lang: Perl
  Description : perlcritic add-ons that generally check for dead code

Perl::Critic::TooMuchCode is an add-on for Perl::Critic is aiming for
identifying trivial dead code.  Either the ones that has no use, or the
one that produce no effect.  Having dead code floating around causes
maintenance burden. Some might prefer not to generate them in the first place.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches

2023-02-05 Thread Johannes Schauer Marin Rodrigues

Package: fakeroot
Version: 1.30.1-1.1
Severity: grave
Control: affects -1 + mmdebstrap

Hi,

since glibc 2.34 and coreutils 9.1, fakeroot fails to preserve ownership
information when running "cp -a" on a file owned by a user other than
root. On armel, armhf and i386 (our 32 bit arches), you can reproduce
this problem by running inside fakeroot:

$ touch foo
$ chown 0:42 foo
$ ls -lha foo
$ cp -a foo bar
$ ls -lha bar"

which will print this:

-rw-r--r-- 1 root shadow 0 Feb  5 23:00 foo
-rw-r--r-- 1 root root 0 Feb  5 23:00 bar

I submitted an improvement to the `cp-a` test which adds a check for the
ownership information in addition to the mode checks as a merge request
for that test here:

https://salsa.debian.org/clint/fakeroot/-/merge_requests/19

Observe how the salsaci pipeline succeds for amd64 but fails on i386.
The reason is that on i386, fakeroot will not retain the ownership
information.

A quick comparison of the strace output on arm64 (which does not have
this problem) and armhf (which does have this problem) shows that arm64
calls fchown() while armhf calls fchown32() which is not wrapped by
fakeroot. Maybe that is the problem?

This breaks my package mmdebstrap in a similar way as #1023286 did.

Since I think that `cp -a` functionality is quite essential, I'm making
this bug RC. Feel free to adjust accordingly.

Thanks!

cheers, josch

Bug#1030622: tex-common package post-installation script subprocess returned error exit status 1

2023-02-05 Thread Norbert Preining

On Sun, 05 Feb 2023, Hilmar Preuße wrote:
> (/usr/share/texlive/texmf-dist/tex/platex/base/plcore.ltx
> ! Argument of \platexNILa has an extra }.
> 
> \par
> l.52 ...ter\expandafter\expandafter{\platexBANNER}

There was one change concerning platex since the release of the new
latex, I guess that is needed

commit 9016960eb053b949ab2b9c73c31fd8d598fd5f13
Author: Karl Berry 
Date:   Thu Dec 15 20:43:14 2022 +

platex (15dec22)

git-svn-id: svn://tug.org/texlive/trunk@65278 
c570f23f-e606-0410-a88d-b1316a301751

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1028388: Splitting 1028388 into separate issues

2023-02-05 Thread Don Armstrong

Control: clone 1028388 -1
Control: summary 1028388 rsyslog init script distributed by 
orphan-sysvinit-scripts doesn't work in some (?) cases.
Control: reassign -1 rsyslog
Control: retitle -1 Please restore the init script for ad-hocery, tests, etc.
Control: tag -1 wontfix
Control: severity -1 wishlist
Control: summary -1 rsyslog no longer distributes an init script; maintainer 
declines to reintroduce the init script.
Control: close -1

With the owner@ hat on:

This looks like two separate issues.

1) rsyslog doesn't provide the init script any more, which is totally up
to the maintainer (Michael Biebl) unless overridden by the TC. That bug
(-1) can be left wontfix, wishlist, and closed. Please do not reopen it
without a TC or RM decision.[1]

2) The init script distributed by orphan-sysvinit-scripts doesn't work
in some (?) cases. This should be fixed (or otherwise handled) by the
maintainer(s) of orphan-sysv-init scripts.

[Further messages sent privately to affected individuals.]

1: Probably didn't need to clone it, but I wanted to be clear for
everyone.
-- 
Don Armstrong  https://www.donarmstrong.com

"Old hypotheses never really die, they're like dormant volcanoes."
 -- John McPhee _Annals of the Former World_ p313

Bug#1024040: mariadb-10.6: FTBFS on alpha: relocation truncated to fit: GPREL16 against symbol `wsrep_debug'

Hi!

I applied the suggested fix now in
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/9e7ac5852d8a0ab96e25c4dd38dbc88354ee1c9e
and it will be included in next upload. There are so many build
failures that I don't have time to test each of them. If you have time
to help, please test this on alpha, or just wait until upload has been
made and we have the result on official builders.

Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included

2023-02-05 Thread Brandon Werner

package: hw-detect
version: 1.154

Hello,
I saw the recent work to the installer surrounding firmware handling and 
thought I would test on my machines to see how this all was working. I used one 
of the daily sid_d-i netinst cds including firmware. I noticed some problems 
around the installer asking for  firmware that was not neded for ath10k. I 
first tried on a laptop that had QCA-6174 hw2.1. I noticed the prompt telling 
me about missing firmware and asking if I wanted to load it from additional 
media, which was puzzling for the firmware image. If I select no, the installer 
continues, however, I thought this  could confuse users, so I dug into it.

Before firmware atheros was loaded, the kernel tried to load versions 6 through 
2 of the firmware files as well as calibration firmware files. After firmware 
atheros was installed, the card was brought up, and this time, only three files 
were missing. The cal and pre-cal files appear to be optional according to the 
driver source, and do not exist in linux-firmware upstream, so I think them 
missing is no problem. Firmware ver 6 doesn't exist yet in the upstream Linux 
repo so maybe this is in the driver for future use? I guess the installer still 
thinks there is missing firmware because of the kernel failing to load these 3 
unnecessary files. After version 5 of the firmware was found, the kernel 
stopped trying to load versions 4 3 2, so there was many fewer missing files on 
the second run of check-missing-firmware.

I have another laptop with hw3.2 of QCA-6174 and on that machine, only pre-cal 
and cal are missing after firmware-atheros is loaded by the installer. I looked 
at hw-detect, and noticed there was a section in check-missing-firmware.sh 
ignoreing intel wifi debugging firmware, but I think trying to ignore all the 
correct files in that location might be a bit tricky, especially if other net 
drivers try to load optional firmware. It also seems possible that the PCI IDs 
searched by the driver could be different for cal and pre-cal for different 
ath10k hardware although I didn't dig into this. I hope the information I 
provided is enough for package maintainers to determine a correct solution. 
Thanks for all the great work on the installer recently to make  firmware 
handling work better.

Below, a bit of text from the installer log, to show the driver is loading, but 
the installer still thinking there is missing firmware.

Feb  5 10:35:26 check-missing-firmware: mainloop iteration #1
Feb  5 10:35:26 check-missing-firmware: lookup with 
/cdrom/firmware/Contents-firmware
Feb  5 10:35:26 check-missing-firmware: installing firmware package 
/cdrom/firmware/firmware-atheros_20221214-5_all.deb (non-free-firmware)
Feb  5 10:35:28 check-missing-firmware: removing and loading kernel module 
ath10k_pci
Feb  5 10:35:28 kernel: [   60.711599] DMAR: DRHD: handling fault status reg 2
Feb  5 10:35:28 kernel: [   60.711605] DMAR: [DMA Write NO_PASID] Request 
device [01:00.0] fault addr 0x7ee0 [fault reason 0x05] PTE Write access is 
not set
Feb  5 10:35:28 kernel: [   60.711661] ath10k_pci :01:00.0: pci irq msi 
oper_irq_mode 2 irq_mode 0 reset_mode 0
Feb  5 10:35:28 kernel: [   60.977712] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2)
Feb  5 10:35:28 kernel: [   60.977724] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2)
Feb  5 10:35:28 kernel: [   60.977735] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/cal-pci-:01:00.0.bin (-2)
Feb  5 10:35:28 kernel: [   60.977744] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/cal-pci-:01:00.0.bin (-2)
Feb  5 10:35:28 kernel: [   60.977755] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2)
Feb  5 10:35:28 kernel: [   60.977762] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2)
Feb  5 10:35:28 kernel: [   60.977973] ath10k_pci :01:00.0: firmware: 
direct-loading firmware ath10k/QCA6174/hw2.1/firmware-5.bin
Feb  5 10:35:28 kernel: [   60.977980] ath10k_pci :01:00.0: qca6174 hw2.1 
target 0x0501 chip_id 0x003405ff sub 144d:4125
Feb  5 10:35:28 kernel: [   60.977986] ath10k_pci :01:00.0: kconfig debug 0 
debugfs 0 tracing 0 dfs 0 testmode 0
Feb  5 10:35:28 kernel: [   60.978697] ath10k_pci :01:00.0: firmware ver 
SW_RM.1.1.1-00157-QCARMSWPZ-1 api 5 features ignore-otp,no-4addr-pad crc32 
10bf8e08
Feb  5 10:35:28 kernel: [   61.040011] ath10k_pci :01:00.0: firmware: 
direct-loading firmware ath10k/QCA6174/hw2.1/board-2.bin
Feb  5 10:35:28 kernel: [   61.040387] ath10k_pci :01:00.0: board_file api 
2 bmi_id N/A crc32 ae2e275a
Feb  5 10:35:29 check-missing-firmware: looking at dmesg again, restarting from 
timestamp: [   57.345819]
Feb  5 10:35:29 check-missing-firmware: timestamp found, truncating dmesg 
accordingly
Feb  5 10:35:29 check-missing-firmware: saving timestamp for a

Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0

2023-02-05 Thread Rogo

Control: tags -1 patch

Hi,

as Adrian indicated, the setuptools issue is now fixed and the 
dt-reorder-cython-setuptools-import.patch is not needed anymore.
However, there are now several unrelated problems causing sagemath to FTBFS.

First of all giac.h can't be compiled, as uchar is not defined.
Workaround: Add '#define uchar u_char' at the beginning of 
/usr/include/giac/giac.h.

Then debian/rules needs to be adapted to Python 3.11:
$ sed -i 's/python3.10/python3.11/' debian/rules

Further backporting some patches from upstream (on top of what is currently in 
git) is necessary:
# Python 3.11
de38bac21e2 src/sage: Apply python-3.11.patch from 
https://github.com/void-linux/void-packages/commit/6229f313450ecae88743b4d5e99da2ed4de44e07
9eb08f3afde inspect.ArgSpec -> inspect.FullArgSpec
8955607c71c dict_del_by_value: move python internal definitions to a separate 
file
76040803c8a dict_del_by_value: add internal definitions for python 3.11
014c2ac9a6f deprecated uu -> base64
dc8e155994a sage.misc.fpickle: fix for python 3.11
fd4d6975790 src/sage/misc/fpickle.pyx: Fix docstring markup
8b0dac2322d Fix FullArgSpec usage after 9eb08f3afde3266bbd667e196513240a0fe245f4
db45aebfd6b warnings: ignore deprecation for 'import cgi' in cython
664fc008ed5 warnings: ignore deprecation for 'import sre_constants' in pyparsing
0f63cce4ed1 src/sage/repl/display/formatter.py: Replace use of SAGE_EXTCODE in 
doctest by importlib.resources
08e1161c23c warnings: ignore deprecation of importlib.resources.path/read_binary
ed9fe6746f9 remove traces of # py3 and some # py2
44480f4827e doctests: fixes due to ArgSpec -> FullArgSpec change
482dd1ac3d2 doctests: AssertionError message changed in python 3.11
7b6fa565f42 doctests: message added more info in python 3.11
c928c2c7978 src/sage/all.py: Filter out imghdr deprecation warnings
ac0105e720d Filter out locale DeprecationWarning

# Sphinx 5.2
3ee509aec95 remove unused, and removed from sphinx 5, imported 
get_module_members
18c92459b33 fix syntax so extlinks stop complaining
c27e4e4c979 migrate from filename_set to record_dependencies as suggested in 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html
c2e610cfba0 Fix build with sphinx 5.2

# Matplotlib 3.6
5501e0de0dc Support matplotlib 3.6
4645a0d0c10 Removing faulty plot
f0a77039bb2 Add back doctest
8371dd75013 Missing part of the fix
a8741d8c60d Edit the doctest
64589686c26 More edis of the doctest

# SymPy 1.10
609dd9deaea sage.manifolds: Update doctests for SymPy 1.10

# SciPy 1.8
9c8235e44ff Fix deprecation warning with scipy 1.8

# Singular 4.3.1p3
42342b90043 Apply 
https://github.com/archlinux/svntogit-community/blob/packages/sagemath/trunk/sagemath-singular-4.3.1.p3.patch
6e03fbe3161 Singular supports larger exponents now, adapt tests
267177af61d Fix one more test
d2b0016b838 Account for different bahavior of pTakeOutComp and pTakeOutComp1

This makes it possible to compile sagemath, but then 138 tests fail, which is 
larger then the threshold of 100.
Many are due to new deprecation warnings that can simply be ignored for now, 
e.g. with the attached dt-ignore-deprecation-warnings.patch.
With that patch only 97 tests fail, so building sagemath works again!

Best regards,
RogoDescription: ignore some deprecation warnings
Author: Rogo 

--- a/sage/src/sage/all.py
+++ b/sage/src/sage/all.py
@@ -126,6 +126,18 @@ warnings.filterwarnings('ignore', category=DeprecationWarning,
 message=r"Use setlocale\(\), getencoding\(\) and getlocale\(\) instead",
 module='docutils.io')
 
+# ignore some deprecation warnings
+warnings.filterwarnings('ignore', category=DeprecationWarning,
+message="msvccompiler is deprecated and slated to be removed in the future. Please discontinue use or file an issue with pypa/distutils describing your use case.")
+warnings.filterwarnings('ignore', category=FutureWarning,
+message=r"In the future `np.(bool|bytes)` will be defined as the corresponding NumPy scalar.  \(This may have returned Python scalars in past versions.")
+warnings.filterwarnings('ignore', category=DeprecationWarning,
+message="'imghdr' is deprecated and slated for removal in Python 3.13")
+warnings.filterwarnings('ignore', category=DeprecationWarning,
+message="'cgi' is deprecated and slated for removal in Python 3.13")
+warnings.filterwarnings('ignore', category=DeprecationWarning,
+message=r"Passing unrecognized arguments to super\(ToggleButtons\).__init__\(style=\{'button_width': 'initial'\}\).")
+
  end setup warnings ###

Bug#1030632: bugs.debian.org: cannot select picture from a local directory to use as desktop background in kde plasma

2023-02-05 Thread Don Armstrong

Control: reassign -1 kde-plasma-desktop

My guess is that this has something to do with kde-plasma-desktop, but
you're going to need to provide more information about which window
manager you're using, what version it is, and what you've most recently
installed.

[You've assigned this bug to bugs.debian.org, which is for bugs in our
bug tracking system, not a general catch-all bug location.]

-- 
Don Armstrong  https://www.donarmstrong.com

"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
 –- Douglas Adams _The Hitchhikers Guide To The Galaxy_

Bug#1030635: rust-isahc: autopkgtest failure on s390x

2023-02-05 Thread Adrian Bunk

Source: rust-isahc
Version: 1.7.2+ds-18
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-isahc/31083641/log.gz

...
running 2 tests
test request_errors_if_read_timeout_is_reached ... FAILED
test timeout_during_response_body_produces_error ... FAILED

failures:

 request_errors_if_read_timeout_is_reached stdout 
thread 'request_errors_if_read_timeout_is_reached' panicked at 'assertion 
failed: `result` matches `Err(e) if e == isahc :: error :: ErrorKind :: Timeout`
  value: `Ok(Response { status: 200, version: HTTP/1.1, headers: {}, body: 
Body(?) })`', tests/timeouts.rs:28:5
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: timeouts::request_errors_if_read_timeout_is_reached
 at ./tests/timeouts.rs:28:5
   3: timeouts::request_errors_if_read_timeout_is_reached::{{closure}}
 at ./tests/timeouts.rs:14:1
   4: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   5: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.

 timeout_during_response_body_produces_error stdout 
thread 'timeout_during_response_body_produces_error' panicked at 'called 
`Result::unwrap_err()` on an `Ok` value: 98304', tests/timeouts.rs:61:43
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
 at /usr/src/rustc-1.63.0/library/core/src/result.rs:1805:5
   3: core::result::Result::unwrap_err
 at /usr/src/rustc-1.63.0/library/core/src/result.rs:1194:22
   4: timeouts::timeout_during_response_body_produces_error
 at ./tests/timeouts.rs:61:9
   5: timeouts::timeout_during_response_body_produces_error::{{closure}}
 at ./tests/timeouts.rs:35:1
   6: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   7: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.


failures:
request_errors_if_read_timeout_is_reached
timeout_during_response_body_produces_error

test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; 
finished in 0.54s

error: test failed, to rerun pass `--test timeouts`
 Running 
`/tmp/tmp.6iU3rvj85w/target/s390x-unknown-linux-gnu/debug/deps/unix-457994c20ca0a0bc
 --skip accept_headers_populated_by_default --skip 
header_can_be_inserted_in_httpclient_builder --skip 
headers_in_request_builder_must_override_headers_in_httpclient_builder --skip 
headers_in_request_builder_must_override_multiple_headers_in_httpclient_builder 
--skip multiple_headers_with_same_key_can_be_inserted_in_httpclient_builder 
--skip deflate_encoded_response_is_decoded_automatically --skip 
gzip_encoded_response_is_decoded_automatically`

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 
finished in 0.00s

error: 3 targets failed:
`--test encoding`
`--test net`
`--test timeouts`
autopkgtest [12:03:05]: test rust-isahc-1:text-decoding: 
---]
autopkgtest [12:03:06]: test rust-isahc-1:text-decoding:  - - - - - - - - - - 
results - - - - - - - - - -
rust-isahc-1:text-decoding FAIL non-zero exit status 101
autopkgtest [12:03:06]:  summary
rust-isahc:@ FAIL non-zero exit status 101
rust-isahc-1:unstable-interceptors FAIL non-zero exit status 101
rust-isahc-1:FAIL non-zero exit status 101
rust-isahc-1:default FAIL non-zero exit status 101
rust-isahc-1:cookies FAIL non-zero exit status 101
rust-isahc-1:http2   FAIL non-zero exit status 101
rust-isahc-1:jsonFAIL non-zero exit status 101
rust-isahc-1:psl FAIL non-zero exit status 101
rust-isahc-1:spnego  FAIL non-zero exit status 101
rust-isahc-1:static-curl FAIL non-zero exit status 101
rust-isahc-1:static-ssl FAIL non-zero exit status 101
rust-isahc-1:text-decoding FAIL non-zero exit status 101

Bug#1030532: thunderbird: allow historic ~/.mozilla-thunderbird in apparmor

2023-02-05 Thread Carsten Schoenert


Hi Matthew,

Am 05.02.23 um 21:04 schrieb Matthew Vernon:
...

Looking at the existing profile data template I think this should do the
trick.




    # per-user thunderbird configuration
    owner @{HOME}/.{icedove,thunderbird}/ rw,
-  owner @{HOME}/.{icedove,thunderbird}/** rw,
+  owner @{HOME}/.{icedove,thunderbird,mozilla-thunderbird}/** rw,
    owner @{HOME}/.{icedove,thunderbird}/**/storage.sdb k,
    owner @{HOME}/.{icedove,thunderbird}/**/*.{db,parentlock,sqlite}* k,
    owner @{HOME}/.{icedove,thunderbird}/plugins/** rm,


This is definitely not sufficient - you need k (lock) permissions inside
.mozilla-thunderbird for e.g. parentlock (otherwise you get the "another
thunderbird process is running" message).

I think the answer is to adjust every line that has "owner
@{HOME}/.{icedove,thunderbird}" to instead have owner
@{HOME}/.{icedove,thunderbird,mozilla-thunderbird}" is the way to go,
but I don't have time to try such a patch right now, sorry!


I'll build a new (test) version of 102.7.1 which has hopefully included 
the fix for the M$ OAuth problem tomorrow, I can add the too the fix for 
the AppArmor profile like you suggested.


--
Regrads
Carsten

Bug#1029594: Fails to authenticate mit o365

2023-02-05 Thread Carsten Schoenert


Am 05.02.23 um 19:56 schrieb Chandler Sobel-Sorenson:

Carsten Schoenert wrote on 2/5/23 3:39 AM:

If you need your laptop or your workstation for mission critical
things than Debian unstable/sid isn't the right choice. If you do so
then you will need some knowledge to handle situations like happen
now.I'm not.  The broken package has been released to testing already.

In an ideal world I would have two separate computers but not everyone
has ideal situations.  testing release is good for my situation and have
now added notifications of important bugs for apt-listbugs config as
well, so thank you for mentioning that.  However, that's not the default
for users.

I don't understand what you want from me.

Is the world going down now? For sure not!

Did such situations did happen in the past? Yes, several times while I 
maintaining Thunderbird.


Do I have a life beside Debian? Yes I have.

Did you use stable for your daily work as Debian is suggesting? I don't 
think so. Would you be affected by this issue if you use stable? No!


Does your emails help preventing others? Also here I don't think so.
You even don't have tried to use some pre-compiled version from Mozilla 
and did give some feedback, you still do nothing more than complaining 
how bad the situation is.


So, live with the situation like I do. We are all volunteers and do the 
work in our free time. Once I got time I will try to look at situation.


--
Regards
Carsten

Bug#1030627: debootstrap: Causes dpkg segfault in "chroot /… dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb" when trying to bootstrap Wheezy or earlier

Control: reassign -1 xen-tools 4.9.1-1
Control: retitle -1 xen-tools: Document configuration needed for older releases 
better 

Hi,

Axel Beckert wrote:
> > I must admit, I currently don't see which system call caused the
> > segfault. Full strace log attached.
> 
> I currently suspect it's none of them, but I was testing on a new host
> which doesn't have the setting vsyscall=emulate mentioned by myself
> (and since then have todally forgotton about) in
> https://github.com/xen-tools/xen-tools/blob/master/debian/NEWS

Yep, that was it. Sorry for the noise.

> If it's the cause, I will close this bug report and write down the
> hint in a more prominent place.

Well, not closing but reassigning to xen-tools. And wondering where I
should put that information better.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1030634: wolfssl: salsa-ci.yml is left

2023-02-05 Thread Bastian Germann


Source: wolfssl
Severity: minor
Version: 5.5.4-1

Vcs-Git and Vcs-Browser are dropped.
Please drop debian/salsa-ci.yml with your next upload as it is now useless.

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

2023-02-05 Thread Gioele Barabucci


Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : fdflush
   Version  : 1.0.1.3+nmu1
 * License  : GPL-2
   Section  : utils

Intent-to-NMU bug report: https://bugs.debian.org/1030631

The source builds the following binary packages:

  fdflush - Flush out-of-date disk buffers

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fdflush/fdflush_1.0.1.3+nmu1.dsc


Changes since the last upload:

 fdflush (1.0.1.3+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * d/rules: Update to debhelper 13 (Closes: #939725, #965520, #999200)
   * d/source: Use 3.0 (native) format
   * d/control: Update standards version to 4.6.2
   * Makefile: Do not force installation with root user
   * d/control: Specify Rules-Requires-Root: no
   * debian/copyright: Update and convert to DEP-5

Regards,

--
Gioele Barabucci

Bug#1030632: bugs.debian.org: cannot select picture from a local directory to use as desktop background in kde plasma

2023-02-05 Thread George Olson

Package: bugs.debian.org
Severity: important

Dear Maintainer,

I am using Debian testing (bookworm). I have a 4 monitor setup and my
graphics

card is this:
0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Navi

23 [Radeon RX 6600/6600 XT/6600M] (rev c7)

I have been running Debian testing for about 6 months and this is the first
time that an update has caused something significant to stop working.

When I ran an update last week and rebooted, all of a sudden the
pictures that

I use for my desktop slideshow would not come up as a desktop background.
Instead all I get is black screen. The default menu bar panel works and my
system is functional, but there is no desktop background. If I select
slideshow

or image and try to set an image from a local directory, it will not set a
desktop background. I only get a blank screen. If I select a picture of
the day
so that it grabs an image from the internet, like Astronomy Picture of
the Day,

it sets the image. But it will not set the image from a local directory.

In addition, the digital clock widget on the menu bar no longer works. If I
click on the spot where the digital clock used to appear, I get this error:
"file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/main.qml:80:34:
Type CalendarView unavailable

file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/CalendarView.qml:604:13:
Cannot assign to non-existent property "eventButton""

I don't know if these 2 items are related, but the failures happened at
the same time. I posted the problem in the Debian

user forms at this url: https://forums.debian.net/viewtopic.php?t=153902

I was told this had to do with libkscreen.

Bug#1030631: fdflush: diff for NMU version 1.0.1.3+nmu1

2023-02-05 Thread Gioele Barabucci


Package: fdflush
Version: 1.0.1.3
Severity: normal
Tags: patch

Dear maintainer,

I've prepared an NMU for fdflush (versioned as 1.0.1.3+nmu1) and 
uploaded it to mentors.debian.net. The diff is attached to this message.


I require a sponsor to have it uploaded.

Regards,

diff -Nru fdflush-1.0.1.3/debian/changelog 
fdflush-1.0.1.3+nmu1/debian/changelog

--- fdflush-1.0.1.3/debian/changelog2008-07-28 23:41:33.0 +0200
+++ fdflush-1.0.1.3+nmu1/debian/changelog	2023-02-05 21:34:40.0 
+0100

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

   * New maintainer. Closes: #429468
diff -Nru fdflush-1.0.1.3/debian/copyright 
fdflush-1.0.1.3+nmu1/debian/copyright

--- fdflush-1.0.1.3/debian/copyright2008-07-28 23:41:33.0 +0200
+++ fdflush-1.0.1.3+nmu1/debian/copyright	2023-02-05 21:34:40.0 
+0100

@@ -1,25 +1,26 @@
-This is the Debian GNU/Linux prepackaged version of the fdflush floppy
-disk buffer-flush program. Fdflush was written by Bruce Perens
-. Wichert Akkerman 
-was the previous Debian maintainer of fdflush; the current maintainer is
-Matthias Urlichs .
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

-This package was put together by Bruce Perens , from
-sources he created.
-
-Fdflush is Copyright (C) 1995 Bruce Perens.
-
-   This program is free software; you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; version 2 dated June, 1991.
-
-   This program is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-On Debian GNU/Linux systems, the complete text of the GNU General
-Public License can be found in `/usr/share/common-licenses/GPL'.
-
-
-See ChangeLog for information on changes.
+Files: *
+Copyright: 1995 Burce Perens
+License: GPL-2
+
+Files: debian/*
+Copyright: 1996-2002 Wichert Akkerman
+   2003-2004 Matthias Urlichs
+   2007 Matej Vela
+   2008 Diego Fernández Durán
+   2023 Gioele Barabucci
+License: GPL-2
+
+License: GPL-2
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 dated June, 1991.
+ .
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+Comment:
+ On Debian systems, the full text of the GNU General Public License
+ version 2 can be found in the file '/usr/share/common-licenses/GPL-2'.

Bug#1029372: Acknowledgement (mariadb: FTBFS on powerpc: Test main.index_merge_innodb runs 150 mins until terminated)

Latest build 
(https://buildd.debian.org/status/fetch.php?pkg=mariadb=powerpc=1%3A10.11.1-2=1675211870=0)
no longer fails on this but test suite runs, and fails on two tests:

1)
main.func_json_notembedded   w2 [ fail ]  timeout after 7200 seconds
Test ended at 2023-02-01 04:01:59
Test case timeout after 7200 seconds
== /<>/builddir/mysql-test/var/2/log/func_json_notembedded.log ==
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
2345678
]
select json_loose(@arr);
json_loose(@arr)
[1234567, 1234567, 1234567, 1234567, 1234567,


This is potentially related to
https://jira.mariadb.org/browse/MDEV-30518 or
https://jira.mariadb.org/browse/MDEV-27955.

2)

main.killw6 [ fail ]
Test ended at 2023-01-31 20:35:53
CURRENT_TEST: main.kill
--- /<>/mysql-test/main/kill.result 2022-11-14
18:10:21.0 +
+++ /<>/mysql-test/main/kill.reject 2023-01-31
20:35:53.302123393 +
@@ -154,7 +154,7 @@
 connection con1;
 connect con5, localhost, u1,,;
 KILL QUERY ID ID;
-ERROR HY000: You are not owner of query ID
+ERROR HY000: You are not owner of query 0
 connection con1;
 KILL QUERY ID @id;
 connection default;

Seems to be 'in review' upstream at https://jira.mariadb.org/browse/MDEV-30558

Bug#1030588: isenkram: Segmentation error: invalid uninstantiatable type '(null)' in cast to 'AsProvided'

2023-02-05 Thread Petter Reinholdtsen

Control: reassign -1 appstream 0.16.0-1
Control: affects -1 isenkram-cli

[Davide Prina]
> I have just installed the package and try to run it:
>
> $ LANG=en_EN isenkram-lookup
> /usr/lib/python3/dist-packages/isenkram/lookup.py:85: Warning: invalid 
> uninstantiatable type '(null)' in cast to 'AsProvided'
>   provided = cpt.get_provided_for_kind(AppStream.ProvidedKind.MODALIAS)
> Errore di segmentazione
>
> it give a Segmentation Error 
>
> I don't know Python, so I don't know how to report you more
> information.

I discovered this too a few days ago, and it is actually a bug in
appstream, according to the appstream maintainer.  The fix has been
found in 
https://github.com/ximion/appstream/commit/631303a8d16c2f608428a89bb94511bc28ae5417
 >
and I eagerly await a fixed version in Debian.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1030627: debootstrap: Causes dpkg segfault in "chroot /… dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb" when trying to bootstrap Wheezy or earlier

Control: tag -1 + moreinfo

Hi,

I think, I found the cause:

Axel Beckert wrote:
> 9440  open("/var/log/dpkg.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 6
> 9440  fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> 9440  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = 0x7fbf3816
> 9440  fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> 9440  lseek(6, 0, SEEK_SET) = 0
> 9440  fcntl(6, F_GETFD) = 0
> 9440  fcntl(6, F_SETFD, FD_CLOEXEC) = 0
> 9440  --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
> si_addr=0xff600400} ---
> 9440  +++ killed by SIGSEGV (core dumped) +++
> 
> I must admit, I currently don't see which system call caused the
> segfault. Full strace log attached.

I currently suspect it's none of them, but I was testing on a new host
which doesn't have the setting vsyscall=emulate mentioned by myself
(and since then have todally forgotton about) in
https://github.com/xen-tools/xen-tools/blob/master/debian/NEWS

Please don't react on this bug report until I've verified if that's
really the cause.

If it's the cause, I will close this bug report and write down the
hint in a more prominent place. If it's not the cause, I'll remove the
"moreinfo" tag.

And sorry for the potential noise.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1028163: sshfs-fuse bug


El 5/2/23 a las 21:54, Steven Robbins escribió:

There are a couple of odd things about this bug.

First: it doesn't seem like an RC bug because the test manifestly runs fine on
buildds -- see https://buildd.debian.org/status/package.php?p=sshfs-fuse


The package is trying to access the network. This is considered RC even if
it works in the official buildds.


Second: the bug log shows python 3.9.2 is used.  That hasn't been the default
python since 2021 -- so it's an unusual test environment.


Maybe I was reporting the failure in bullseye (because packages in stable must
build in stable).

Here is a recent build log from January in bookworm.

Thanks.

sshfs-fuse_3.7.3-1_amd64-20230112T160950.844Z.gz
Description: application/gzip

Bug#1007219: mariadb-10.6: FTBFS on sparc64:

FYI: MariaDB 10.11.1 fails to build on sparc64 now with "/bin/sh: Bad
address" in https://bugs.debian.org/1030630

Bug#1007216: mariadb-10.6: FTBFS on ppc64: unrecognized opcode tbegin/tabort/tend

FYI: MariaDB 10.11.1 now also failing on the same test
main.func_json_notembedded in https://bugs.debian.org/1029374

Bug#1030249: unexpected "prefclean output on ..." emails since bookworm upgrade

2023-02-05 Thread Francesco Poli

On Thu, 02 Feb 2023 20:57:16 -0500 Antoine Beaupré wrote:

> On 2023-02-01 23:35:09, Francesco Poli wrote:
> > On Wed, 01 Feb 2023 10:25:21 -0500 Antoine Beaupre wrote:
> 
> [...]
> 
> > I must admit that I am somewhat surprised that you see all these mail
> > notifications about fixed packages as something new.
> > apt-listbugs has notified root by (local) mail about fixed packages for
> > ages. Through the cron job mechanism and, starting from 2019, through
> > the manually-implemented mailing in the systemd timer.
> >
> > So, I wonder what has changed in your box, when you began to see these
> > mail notifications...
> 
> I am not sure. I recently deployed unattended-upgrades on all my
> machines, and recently upgraded them to bookworm, which might have
> triggered more of those warnings. 2019 is not that long ago though, was
> this part of bullseye?

Yes, the mail notifications have been present for ages.
Before 2019, just because cron/anacron sends the output by (local) mail
by default. Starting from 2019, also because they are manually
implemented in the systemd timer (for systemd-running boxes).
This implementation was done in 2019 and was part of bullseye (which
was released in 2021).

However, what you say made me think about a couple of things.
Under unattended-upgrades, apt-listbugs automatically pins all buggy
packages, see the corresponding [FAQ]
in /usr/share/doc/apt-listbugs/FAQ.md.gz .

[FAQ]: 

But, unfortunately, this automatic pinning was broken in bullseye, due
to a bug introduced by me in 2020 and then fixed in 2022 (see bug
[#1021289]).

[#1021289]: 

In bookworm, this bug is fixed and the automatic pinning should work
correctly.

This should explain why you suddenly began to see the notifications
under unattended-upgrades, after migrating to bookworm.

[...]
> > In the meanwhile, you could try the attached patch as temporary
> > workaround for your specific case (the "I do not want any mail
> > notifications" case).
> > Please let me know whether it works as intended.
> 
> Ah well, I thought I could write something like this on my own of
> course, but I didn't want to diverge from upstream and forget I had that
> patch lying around. I suspect it might just work, indeed, as the caller
> checks to see if there's any output beforing firing off that email...
> 
> Thanks for the patch!

You are welcome.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

pgpPgIPYGCRiD.pgp
Description: PGP signature

Bug#1030630: mariadb: FTBFS on sparc64: /bin/sh: Bad address

Source: mariadb
Version: 1:10.11.1-2
Tags: ftbfs
X-Debbugs-CC: debian-sp...@lists.debian.org
User: debian-sp...@lists.debian.org
Usertags: sparc64

In previous upload of MariaDB 1:10.11.1-1 the sparc64 build compiled
but then failed on test as reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029163

That bug was fixed with in
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/340b190ac8a38dc60e176b136966229d40d14b2b
for multiple architectures.

In latest upload sparc64 no longer builds but build fails on:

[ 54%] Building C object
plugin/auth_ed25519/CMakeFiles/auth_ed25519.dir/ref10/fe_invert.c.o
cd /<>/builddir/plugin/auth_ed25519 && /usr/bin/cc
-DHAVE_CONFIG_H -DMYSQL_DYNAMIC_PLUGIN -D_FILE_OFFSET_BITS=64
-Dauth_ed25519_EXPORTS -I/<>/wsrep-lib/include
-I/<>/wsrep-lib/wsrep-API/v26
-I/<>/builddir/include
-I/<>/include/providers
-I/<>/plugin/auth_ed25519 -I/<>/include
-I/<>/sql -I/<>/unittest/mytap -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
-D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
--param=ssp-buffer-size=4 -O2 -g -static-libgcc
-fno-omit-frame-pointer -fno-strict-aliasing  -Wno-uninitialized
-fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
-Wdeclaration-after-statement -Wenum-compare -Wenum-conversion -Wextra
-Wformat-security -Wmissing-braces -Wno-format-truncation
-Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Wvla
-Wwrite-strings -fPIC   -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -MD
-MT plugin/auth_ed25519/CMakeFiles/auth_ed25519.dir/ref10/fe_invert.c.o
-MF CMakeFiles/auth_ed25519.dir/ref10/fe_invert.c.o.d -o
CMakeFiles/auth_ed25519.dir/ref10/fe_invert.c.o -c
/<>/plugin/auth_ed25519/ref10/fe_invert.c
/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC
-fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc
-fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized
-fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
-Wenum-compare -Wenum-conversion -Wextra -Wformat-security
-Wmissing-braces -Wno-format-truncation -Wno-init-self
-Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual
-Wnon-virtual-dtor -Wvla -Wwrite-strings -Wl,-z,relro -Wl,-z,now
-Wl,-z,relro,-z,now -shared  -o ha_test_sql_discovery.so
CMakeFiles/test_sql_discovery.dir/test_sql_discovery.cc.o
../../libservices/libmysqlservices.a
/usr/bin/make  -f
plugin/auth_examples/CMakeFiles/dialog_examples.dir/build.make
plugin/auth_examples/CMakeFiles/dialog_examples.dir/depend
make[4]: Entering directory '/<>/builddir'
cd /<>/builddir && /usr/bin/cmake -E cmake_depends "Unix
Makefiles" /<> /<>/plugin/auth_examples
/<>/builddir
/<>/builddir/plugin/auth_examples
/<>/builddir/plugin/auth_examples/CMakeFiles/dialog_examples.dir/DependInfo.cmake
--color=
make[4]: Leaving directory '/<>/builddir'
[ 54%] Building C object
plugin/auth_ed25519/CMakeFiles/auth_ed25519.dir/ref10/fe_isnegative.c.o
cd /<>/builddir/plugin/auth_ed25519 && /usr/bin/cc
-DHAVE_CONFIG_H -DMYSQL_DYNAMIC_PLUGIN -D_FILE_OFFSET_BITS=64
-Dauth_ed25519_EXPORTS -I/<>/wsrep-lib/include
-I/<>/wsrep-lib/wsrep-API/v26
-I/<>/builddir/include
-I/<>/include/providers
-I/<>/plugin/auth_ed25519 -I/<>/include
-I/<>/sql -I/<>/unittest/mytap -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
-D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
--param=ssp-buffer-size=4 -O2 -g -static-libgcc
-fno-omit-frame-pointer -fno-strict-aliasing  -Wno-uninitialized
-fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
-Wdeclaration-after-statement -Wenum-compare -Wenum-conversion -Wextra
-Wformat-security -Wmissing-braces -Wno-format-truncation
-Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Wvla
-Wwrite-strings -fPIC   -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -MD
-MT plugin/auth_ed25519/CMakeFiles/auth_ed25519.dir/ref10/fe_isnegative.c.o
-MF CMakeFiles/auth_ed25519.dir/ref10/fe_isnegative.c.o.d -o
CMakeFiles/auth_ed25519.dir/ref10/fe_isnegative.c.o -c
/<>/plugin/auth_ed25519/ref10/fe_isnegative.c
make[4]: /bin/sh: Bad address
make[4]: *** [plugin/auth_ed25519/CMakeFiles/auth_ed25519.dir/build.make:191:
plugin/auth_ed25519/CMakeFiles/auth_ed25519.dir/ref10/fe_isnegative.c.o]
Error 127
make[4]: Leaving directory '/<>/builddir'
make[3]: *** [CMakeFiles/Makefile2:7424:
plugin/auth_ed25519/CMakeFiles/auth_ed25519.dir/all] Error 2
make[3]: *** Waiting for unfinished jobs

Either there is something permanentelly wrong with the builder (I
restarted the build several times with the same result) or the changes
in previous upload fixed other architectures but regressed sparc64.

Bug#1030096: #1030096 dask.distributed autopkgtest fail

2023-02-05 Thread Rebecca N. Palmer

I currently have this in a state where it sometimes succeeds and 
sometimes doesn't:

https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/tree/fix1030096

Tests I've seen to fail multiple times (and don't have a fix for):
test_balance_expensive_tasks[enough work to steal]
https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3902376
(Seems to be the most common problem.  Using @pytest.mark.flaky to try 3 
times doesn't seem to have helped, suggesting that if it fails once it 
keeps failing in that run.  Applying part of upstream pull 7253 seemed 
to make things worse, but I haven't tried applying the whole thing.)

test_popen_timeout
https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3902745

Tests I've seen to fail once:
test_stress_scatter_death
https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3902040
test_tcp_many_listeners[asyncio]
https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3896327

Bug#1030629: RFS: libquazip1-qt5/1.4-1 [RC] -- Qt/C++ wrapper over minizip - Version 1 (Qt5)

2023-02-05 Thread Ben Westover

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: kilob...@angband.pl
Control: block 1028641 by -1

Dear mentors,

I am looking for a sponsor for my package "libquazip1-qt5":

  * Package name : libquazip1-qt5
Version  : 1.4-1
Upstream contact : Sergey A. Tachenov 
  * URL  : https://github.com/stachenov/quazip
  * License  : LGPL-2.1+ with static linking exception, zlib
  * Vcs  : https://salsa.debian.org/BenTheTechGuy/libquazip1-qt5
Section  : libs

Changes since the last upload:

  libquazip1-qt5 (1.4-1) unstable; urgency=medium
  .
* New upstream version
* Add dependencies on Qt5 and zlib1g (Closes: #1028641)

I am the maintainer of this package, and a previous version of it was
successfully uploaded in October of last year. As I am a Debian
Maintainer, I asked my sponsor for upload privileges, but didn't receive
a response. Two months later, there was an RC bug #1028641 that I fixed,
and I emailed again asking him to upload the fixed version, receiving no
response. It has been another two months since then, and there has been
a new upstream release. Since it's unlikely my original sponsor will
respond at this point, I'm asking for a new one to upload this package
and potentially grant me DM upload privileges for it. I'd like to note
that the sister package libquazip1-qt6, with the same sponsor, has DM
upload permissions, and its corresponding RC bug was fixed promptly.

Thanks,
--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1030487: python-trustme: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

2023-02-05 Thread Robie Basak

clone 1030487 -1
reassign -1 python3-service-identity 18.1.0-7
retitle -1 Missing dependency on python3-six makes package unusable
thanks

On Sat, Feb 04, 2023 at 08:58:30AM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

[...]

> > ImportError while importing test module 
> > '/<>/.pybuild/cpython3_3.11/build/tests/test_trustme.py'.
> > Hint: make sure your test modules/packages have valid Python names.
> > Traceback:
> > /usr/lib/python3.11/importlib/__init__.py:126: in import_module
> > return _bootstrap._gcd_import(name[level:], package, level)
> > tests/test_trustme.py:21: in 
> > import service_identity.pyopenssl  # type: ignore[import]
> > /usr/lib/python3/dist-packages/service_identity/__init__.py:7: in 
> > from . import cryptography, pyopenssl
> > /usr/lib/python3/dist-packages/service_identity/pyopenssl.py:9: in 
> > import six
> > E   ModuleNotFoundError: No module named 'six'

Looks like python3-service-identity should have a dependency on
python3-six but it does not.

Steps to reproduce:

apt install python3-service-identity
python3
>>> from service_identity.pyopenssl import verify_hostname
...
ModuleNotFoundError: No module named 'six'

This is expected to work as documented at
https://service-identity.readthedocs.io/en/stable/api.html

I will send a fix for this to Salsa shortly.

Robie


signature.asc
Description: PGP signature

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

2023-02-05 Thread Diederik de Haas

Hi Salvatore,

On Sunday, 5 February 2023 16:17:58 CET Salvatore Bonaccorso wrote:
> > > So I guess we can close this bug here, and the files can be shipped
> > > with a new dedicated source package containing the firmware files,
> > > since the last option of having them merged upstream in
> > > linux-firmware.git seems unrealistic for now?
> > 
> > We could do that, but wouldn't it make more sense to reassign it to wnpp
> > (?) and turn it into a RFP type bug?
> > 
> > That way we would preserve the history (and thus useful info) of this
> > issue.
> Sure, we can do that as well. Drawback is that the initial mail does
> not contain the details for the RFP, but it is a sensible idea.

Please follow your initial idea. If need be, we can always reference this bug 
in the new RFP bug. It's not like closing this bug will make it disappear from 
the face of the earth ;-)

You (seem to) know what can and needs to be done, while I don't.

Regards,
  Diederik

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

Bug#1006529: Info received (mariadb: FTBFS on hppa: builds, but test suite crashes immediately with "'aio write' returned OS error 0"))

Latest build 
(https://buildd.debian.org/status/fetch.php?pkg=mariadb=hppa=1%3A10.11.1-2=1675231483=09
no longer fails on this but test suite runs, and fails on two tests:


1)
main.func_json_notembedded   w2 [ fail ]  timeout after 7200 seconds
Test ended at 2023-02-01 04:01:59
Test case timeout after 7200 seconds
== /<>/builddir/mysql-test/var/2/log/func_json_notembedded.log ==
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
1234567,
2345678
]
select json_loose(@arr);
json_loose(@arr)
[1234567, 1234567, 1234567, 1234567, 1234567,


This is potentially related to
https://jira.mariadb.org/browse/MDEV-30518 or
https://jira.mariadb.org/browse/MDEV-27955.

2)
main.large_pages 'innodb'w2 [ fail ]
Test ended at 2023-02-01 00:35:17
CURRENT_TEST: main.large_pages
Failed to start mysqld.1
mysqltest failed but provided no output
 - found 'core' (0/5)
Trying 'dbx' to get a backtrace
Trying 'lldb' to get a backtrace from coredump
/<>/builddir/mysql-test/var/2/log/main.large_pages-innodb/mysqld.1/data/core
Compressed file
/<>/builddir/mysql-test/var/2/log/main.large_pages-innodb/mysqld.1/data/core
 - saving 
'/<>/builddir/mysql-test/var/2/log/main.large_pages-innodb/'
to '/<>/builddir/mysql-test/var/log/main.large_pages-innodb/'
Retrying test main.large_pages, attempt(2/3)...
***Warnings generated in error logs during shutdown after running
tests: main.large_pages
2023-02-01  0:35:16 0 [Warning] mariadbd: Couldn't allocate 8388608
bytes (Large/HugeTLB memory page size 2097152); errno 22; continuing
to smaller size
2023-02-01  0:35:16 0 [Warning] mariadbd: Couldn't allocate 6291456
bytes (Large/HugeTLB memory page size 2097152); errno 22; continuing
to smaller size
2023-02-01  0:35:16 0 [Warning] mariadbd: Couldn't allocate 6291456
bytes (Large/HugeTLB memory page size 2097152); errno 22; continuing
to smaller size
2023-02-01  0:35:16 0 [Warning] mariadbd: Couldn't allocate 4194304
bytes (Large/HugeTLB memory page size 2097152); errno 22; continuing
to smaller size
2023-02-01  0:35:16 0 [Warning] mariadbd: Couldn't allocate 4194304
bytes (Large/HugeTLB memory page size 2097152); errno 22; continuing
to smaller size
2023-02-01  0:35:16 0 [Warning] InnoDB: Retry attempts for reading
partial data failed.
2023-02-01  0:35:16 0 [ERROR] InnoDB: Operating system error number 14
in a file operation.
2023-02-01  0:35:16 0 [ERROR] InnoDB: Error number 14 means 'Bad address'
2023-02-01  0:35:16 0 [ERROR] InnoDB: File (unknown): 'read' returned
OS error 214. Cannot continue operation
Attempting backtrace. You can use the following information to find out

Filed the latter one as https://jira.mariadb.org/browse/MDEV-30572

Bug#1030593: [Pkg-samba-maint] Bug#1030593: tdb FTCBFS: performs run checks

2023-02-05 Thread Andrew Bartlett

Please submit patches for Samba's wafsamba upstream to Samba.

https://wiki.samba.org/index.php/Contribute

Andrew Bartlett

On Sun, 2023-02-05 at 12:34 +0100, Helmut Grohne wrote:
> Source: tdb
> Version: 1.4.8-2
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> Thank you for having made tdb cross buildable in the presence of
> qemu-user-static! I'd like to get it going without as well as that's
> what cross builders usually do. The distinction here is that you'd pass
> the cross profile for "normal" cross builds (those without qemu) and
> skip this profile for ones supported by qemu. Thus, when the cross
> profile is present, a --cross-answers file is passed. I've also slightly
> updated the build system to avoid unnecessary checks. Consider applying
> the attached patch.
> 
> Helmut
> ___
> Pkg-samba-maint mailing list
> pkg-samba-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-samba-maint

-- 
Andrew Bartlett (he/him) https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba

Bug#1030627: debootstrap: Causes dpkg segfault in "chroot /… dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb" when trying to bootstrap Wheezy or earlier

Package: debootstrap
Version: 1.0.128+nmu2
Severity: normal
Control: affects -1 xen-tools

Running "debootstrap --verbose --arch amd64
--keyring=/usr/share/keyrings/debian-archive-removed-keys.gpg wheezy
/tmp/hH11H2NR4o http://archive.debian.org/debian; (or Debian or Ubuntu
releases older than that) on Sid/Bookworm ends up like this:

[…]
I: Extracting tar...
I: Extracting tzdata...
I: Extracting util-linux...
I: Extracting xz-utils...
I: Extracting zlib1g...
I: Installing core packages...
W: Failure trying to run: chroot "/tmp/hH11H2NR4o" dpkg --force-depends 
--install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /tmp/hH11H2NR4o/debootstrap/debootstrap.log for details

Looking into /tmp/hH11H2NR4o/debootstrap/debootstrap.log I find this
dpkg segfault at the end:

[…]
2023-02-05 21:13:42 (1.72 MB/s) - 
'/tmp/hH11H2NR4o//var/cache/apt/archives/partial/zlib1g_1%3a1.2.7.dfsg-13_amd64.deb'
 saved [87392/87392]

dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing architecture
Segmentation fault (core dumped)

The segfault seems to have beein in the dpkg inside the chroot, not in
debootstrap:

[1395173.551147] dpkg[17643] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffcc14c1118 ax:ff600400 si:428720 
di:7ffcc14c1130
[1395173.551155] dpkg[17643]: segfault at ff600400 ip ff600400 
sp 7ffcc14c1118 error 15 likely on CPU 6 (core 6, socket 0)
[1395173.551160] Code: Unable to access opcode bytes at 0xff6003d6.

/tmp/hH11H2NR4o/var/lib/dpkg/status looks like this afterwards:

Package: dpkg
Status: install ok installed
Maintainer: unknown
Version: 1.16.18

This file seems to have been generated by scripts/debian-common.

Not sure if something changed in the way debootstrap generates initial
files like this, but to me this seems a regression in deboostrap
compared to Bullseye where this still worked. Could have other reasons,
though, too.

Here's end of an "strace -f" of that chrooted dpkg call:

9440  stat("/sbin/start-stop-daemon", {st_mode=S_IFREG|0755, st_size=28152, 
...}) = 0
9440  open("/var/lib/dpkg/info/format", O_RDONLY) = 6
9440  fstat(6, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
9440  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fbf3816
9440  read(6, "1\n", 4096)  = 2
9440  close(6)  = 0
9440  munmap(0x7fbf3816, 4096)  = 0
9440  stat("/var/lib/dpkg/info/format-new", 0x7ffe47838f90) = -1 ENOENT (No 
such file or directory)
9440  open("/var/log/dpkg.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 6
9440  fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
9440  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fbf3816
9440  fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
9440  lseek(6, 0, SEEK_SET) = 0
9440  fcntl(6, F_GETFD) = 0
9440  fcntl(6, F_SETFD, FD_CLOEXEC) = 0
9440  --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
si_addr=0xff600400} ---
9440  +++ killed by SIGSEGV (core dumped) +++

I must admit, I currently don't see which system call caused the
segfault. Full strace log attached.



dpkg-segfault-inside-wheezy-chroot.xz
Description: Result of 'strace -f -o dpkg-segfault-inside-wheezy-chroot -s 65536 chroot /tmp/hH11H2NR4o dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb'

This issue seems to affect these Debian and Ubuntu releases: precise,
oneiric, natty, maverick, lucid, karmic, jaunty, intrepid, hardy, gutsy,
feisty, edgy, dapper, wheezy, squeeze, lenny, etch and sarge.

As wheezy was the most recent Debian release of them, I looked into that
closer as an example to what went wrong.

This issue has been found by running
https://github.com/xen-tools/xen-tools/blob/master/examples/release-testing
on a Bookworm amd64 host with LVM as storage. It bootstraps all releases
listed in
https://github.com/xen-tools/xen-tools/blob/master/etc/distributions.conf
without the "dont-test" tag.

(Bug report written on a different host.)

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

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

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

Versions of packages debootstrap recommends:
ii  arch-test   0.20-1
ii  debian-archive-keyring  2021.1.1
ii  gnupg   2.2.40-1

Versions of

Bug#1030626: evince: Unable to print PDF file with hp printer. But it can be printed with other applications.

2023-02-05 Thread Serkan

Package: evince
Version: 43.1-2+b1
Severity: important
X-Debbugs-Cc: ssser...@yahoo.com

Dear Maintainer,

When I tried to print a PDF document, I got the message "Print job canceled at
printer".

I was able to print the same document to file with a PDF printer.

I was able to print the original document with "Okular" and "LibreOffice Draw"
with physical printer.

I created a very simple document with "LibreOffice Writer" and saved it as a
PDF. I could not print this document either.

I can print "Printer test page" with HP printer.


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

Kernel: Linux 6.1.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=tr_TR.UTF-8, LC_CTYPE=tr_TR.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 evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  evince-common43.1-2
ii  gsettings-desktop-schemas43.0-1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libevdocument3-4 43.1-2+b1
ii  libevview3-3 43.1-2+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.5-1
ii  libgnome-desktop-3-2043.1-1
ii  libgtk-3-0   3.24.36-2
ii  libhandy-1-0 1.8.0-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libsecret-1-00.20.5-3
ii  shared-mime-info 2.2-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.4-1

Versions of packages evince suggests:
ii  gvfs 1.50.3-1
pn  nautilus-sendto  
ii  poppler-data 0.4.11-1
ii  unrar1:6.2.5-1

-- no debconf information

Bug#1030510: mariadb: FTBFS on s390x: timeout

After restarting the build there is no longer a timeout, but a crash:

main.plugin_auth 'innodb'w1 [ fail ]  Found
warnings/errors in server log file!
Test ended at 2023-02-05 09:41:56
line
Attempting backtrace. You can use the following information to find out
^ Found warnings in /<>/builddir/mysql-test/var/1/log/mysqld.1.err
ok

 - found 'core' (0/5)
Core generated by '/<>/builddir/sql/mariadbd'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--
[New LWP 460078]
[New LWP 460124]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Core was generated by `/<>/builddir/sql/mariadbd
--defaults-group-su'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x03ff99c48992 in kill () from /lib/s390x-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x3ff9ab6a820 (LWP 460078))]
#0  0x03ff99c48992 in kill () from /lib/s390x-linux-gnu/libc.so.6
#1  0x02aa226907c4 in handle_fatal_signal (sig=) at
./sql/signal_handler.cc:367
#2  
#3  0x02aa22b7c26a in my_read (Filedes=,
Buffer=0x3ff9ab6a820 "", Count=4096, MyFlags=) at
./mysys/my_read.c:63
#4  0x02aa22690266 in output_core_info () at ./sql/signal_handler.cc:90
#5  0x02aa22690792 in handle_fatal_signal (sig=) at
./sql/signal_handler.cc:351
#6  
#7  0x03ff99d0e632 in munmap () from /lib/s390x-linux-gnu/libc.so.6
#8  0x03ff99ca7790 in free () from /lib/s390x-linux-gnu/libc.so.6
#9  0x02aa228bfe6e in aligned_free (ptr=) at
./include/aligned.h:37
#10 pfs_free (ptr=, size=2048000, klass=0x2aa23e47900
) at
./storage/perfschema/pfs_global.cc:83
#11 pfs_free (klass=0x2aa23e47900
,
size=size@entry=2048000, ptr=) at
./storage/perfschema/pfs_global.cc:78
#12 0x02aa228b5fe6 in PFS_thread_allocator::free_array
(this=, array=array@entry=0x2aa24cf4d30) at
./storage/perfschema/pfs_buffer_container.cc:715
#13 0x02aa228c25da in PFS_buffer_scalable_container::cleanup
(this=) at
./storage/perfschema/pfs_buffer_container.h:506
#14 PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:491
#15 cleanup_instruments () at ./storage/perfschema/pfs_instr.cc:233
#16 0x02aa228d000c in cleanup_performance_schema () at
./storage/perfschema/pfs_server.cc:296
#17 0x02aa228d04f0 in shutdown_performance_schema () at
./storage/perfschema/pfs_server.cc:326
#18 0x02aa2233f912 in mysqld_exit (exit_code=exit_code@entry=0) at
./sql/mysqld.cc:1943
#19 0x02aa2234a4fe in mysqld_main (argc=,
argv=) at ./sql/mysqld.cc:6040
#20 0x03ff99c2b84a in ?? () from /lib/s390x-linux-gnu/libc.so.6
#21 0x03ff99c2b932 in __libc_start_main () from
/lib/s390x-linux-gnu/libc.so.6
#22 0x02aa2233d378 in _start ()



A previous restart also had:

main.mysql_upgrade 'innodb'  w1 [ fail ]  Found
warnings/errors in server log file!

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Core was generated by `/<>/builddir/sql/mariadbd
--defaults-group-su'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x03ffaa0c8992 in kill () from /lib/s390x-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x3ffaafea820 (LWP 1668996))]
#0  0x03ffaa0c8992 in kill () from /lib/s390x-linux-gnu/libc.so.6
#1  0x02aa26c107c4 in handle_fatal_signal (sig=) at
./sql/signal_handler.cc:367
#2  
#3  0x02aa270fc26a in my_read (Filedes=,
Buffer=0x696c646469722f6d , Count=4096, MyFlags=) at
./mysys/my_read.c:63
#4  0x02aa26c10266 in output_core_info () at ./sql/signal_handler.cc:90
#5  0x02aa26c10792 in handle_fatal_signal (sig=) at
./sql/signal_handler.cc:351
#6  
#7  0x03ffaa18e632 in munmap () from /lib/s390x-linux-gnu/libc.so.6
#8  0x03ffaa127790 in free () from /lib/s390x-linux-gnu/libc.so.6
#9  0x02aa26e40022 in aligned_free (ptr=) at
./include/aligned.h:37
#10 pfs_free (ptr=, size=2304000, klass=0x2aa283c8f00
) at ./storage/perfschema/pfs_global.cc:83
#11 pfs_free (ptr=, size=2304000, klass=0x2aa283c8f00
) at ./storage/perfschema/pfs_global.cc:78
#12 pfs_free_array (klass=0x2aa283c8f00 ,
n=n@entry=32000, size=size@entry=72, ptr=) at
./storage/perfschema/pfs_global.cc:134
#13 0x02aa26e36680 in PFS_user_allocator::free_array
(this=, array=array@entry=0x2aa297ac0a0) at
./storage/perfschema/pfs_buffer_container.cc:875
#14 0x02aa26e53786 in PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:506
#15 PFS_buffer_scalable_container::cleanup (this=) at
./storage/perfschema/pfs_buffer_container.h:491
#16 cleanup_user () at ./storage/perfschema/pfs_user.cc:63
#17 0x02aa26e4ffb8 in cleanup_performance_schema () at
./storage/perfschema/pfs_server.cc:275
#18 0x02aa26e504f0 in shutdown_performance_schema () at

Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source

Hi Russ,

Russ Allbery wrote:
> > # -ancient-source (source): unpack-message-for-source tar: 
> > ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59
> > # +ancient-source (source): unpack-message-for-source tar: 
> > ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59
> 
> The exactly one hour difference makes me suspicious something is going on
> with time zone conversions.  That's also consistent with the one hour time
> difference between UTC and Europe/Zurich at New Years.
> 
> Looking at the source of tar, the output timestamp for this error seems to
> be in local time by default, which would certainly explain the problem but
> not why we're not seeing it everywhere.  I would be curious if it went
> away if you added --utc to the flags to tar in
> Lintian::IO::Select::unpack_and_index_piped_tar

Nice idea! Will definitely try.

> or (bigger hammer) just set TZ=UTC when running Lintian.

I tried with TZ=GMT. I also tried TZ=UTC, but that had no effect. I
think you need to use TZ=Etc/UTC there instead.

> Lintian should probably force all output it controls to UTC for
> reproducibility, including tar's, but I'm still mystified as to why it
> works on the other system.  This part of tar doesn't seem to have changed,
> and as you mentioned replacing tar didn't change anything.

Exactly. All of that. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1028163: sshfs-fuse bug

2023-02-05 Thread Steven Robbins

There are a couple of odd things about this bug.

First: it doesn't seem like an RC bug because the test manifestly runs fine on 
buildds -- see https://buildd.debian.org/status/package.php?p=sshfs-fuse

I'd suggest to downgrade the bug on this basis.

Second: the bug log shows python 3.9.2 is used.  That hasn't been the default 
python since 2021 -- so it's an unusual test environment.

-Steve


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

Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source

Hi Vagrant,

Vagrant Cascadian wrote:
> On 2023-02-05, Axel Beckert wrote:
> > While running Lintian's testsuite on a much faster system compared to
> > my Sid amd64 running development workstation, I noticed the following
> > test suite failure when running "private/runtests" or trying to build
> > the package on a more modern and more performant box with Bookworm
> > amd64. (Use "private/runtests -o test:ancient-source" to just run the
> > affected test.)
> >
> > # Hints do not match
> > # 
> > # --- 
> > debian/test-out/eval/checks/unpack/ancient-source/hints.specified.calibrated
> > # +++ debian/test-out/eval/checks/unpack/ancient-source/hints.actual.parsed
> > # -ancient-source (source): unpack-message-for-source tar: 
> > ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59
> > # +ancient-source (source): unpack-message-for-source tar: 
> > ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59
> 
> Wild guess would be timezone differences between the build
> environments?

Yeah, that's what I looked for first, but both boxes have
"Europe/Zurich" as timezone and prepending "env TZ=GMT" didn't make a
difference on either side.

Thanks for caring nevertheless!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1007922: false positive spelling: substract and subtract is both correct

2023-02-05 Thread Brian Thompson

I like the idea of keeping the spelling correction in place.  I've never seen 
"substract" being used.  Keeping the correction reduces ambiguity and keeps 
language consistent.

Motion to close.

Sincerely,

Brian

publickey - brianrobt@pm.me - 0xC8F2EC48.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source

2023-02-05 Thread Vagrant Cascadian

On 2023-02-05, Axel Beckert wrote:
> While running Lintian's testsuite on a much faster system compared to
> my Sid amd64 running development workstation, I noticed the following
> test suite failure when running "private/runtests" or trying to build
> the package on a more modern and more performant box with Bookworm
> amd64. (Use "private/runtests -o test:ancient-source" to just run the
> affected test.)
>
> # Hints do not match
> # 
> # --- 
> debian/test-out/eval/checks/unpack/ancient-source/hints.specified.calibrated
> # +++ debian/test-out/eval/checks/unpack/ancient-source/hints.actual.parsed
> # -ancient-source (source): unpack-message-for-source tar: 
> ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59
> # +ancient-source (source): unpack-message-for-source tar: 
> ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59

Wild guess would be timezone differences between the build environments?

live well,
  vagrant

Bug#1027965: Fix for the RC bug in vtk

2023-02-05 Thread Jochen Sprickerhof


Hi Steven,

* Steven Robbins  [2023-02-05 10:26]:

Was looking yesterday for an RC bug to fix and noticed #1027965 against VTK --
a build failure in gdcm caused by missing dependency.  The fix proposed by
Mathieu seems reasonable to me.


I assume you mean the proposal to add a libvtk9-qt-dev dependency to 
libvtk9-dev?


Note that libvtk9-dev already has a dependency to libvtk9-qt-dev 
resulting in a cyclic dependency between both. Those are known to not 
work well in Debian and should be avoided.


The underlying problem here is that the vtk9 cmake files are not 
separated between libvtk9-dev and libvtk9-qt-dev so the split seems 
artificial to Debian and both packages should probably be merged into 
one or the cmake files need rewriting.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

2023-02-05 Thread Leo Antunes

Hi Reinhard,

It seems I underestimated the work and overestimated by free time: we need some 
bumps for deps (e.g. golang-github-azure-azure-sdk-for-go-dev) and maybe some 
patching to get rid of other deps (e.g. github.com/letsencrypt/boulder), if we 
can manage that.
OTOH, I see you already took care of #1030555 and #1030557! That's great! :)

Cheers
Leo

--- Original Message ---
On Thursday, February 2nd, 2023 at 12:33, Reinhard Tartler  
wrote:

> seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022937 was accepted. 
> Any update on sigstore packaging?

Bug#1030625: autopkgtest: please provide a new restriction for unprivileged unshare/userns

2023-02-05 Thread Helmut Grohne

Package: autopkgtest
Version: 5.28
Severity: wishlist
Control: affects -1 + src:mmdebstrap src:debvm
X-Debbugs-Cc: jo...@debian.org

Hi,

Paul asked me to take this to email and he's probably right. Johannes
Schauer repeatedly tried to test mmdebstrap --mode=unshare in
autopkgtests and reportedly this fails. The most recent failure
reportedly happened three days ago in experimental, but retrieving
experimental logs turns out to be difficult.

What is needed to make this work? mmdebstrap --mode=unshare requires the
following features:
 * unprivileged unsharing of user namespaces
   - This is prohibited on DSA machines via a sysctl
   - It works on most other systems
   - Test case: unshare -U true
 * A subuid allocation in /etc/subuid
   - Allocated by default during user creation
   - Test case: grep -q ^$(id -un): /etc/subuid
 * subuid allocation must be mapped by container technology (if any)
   - I suppose the unshare backend fails this. Likely also unprivileged
 podmand.
 * It must be possible to mount proc in the unshared user+mount+pid
   namespace.
   - This should always work but may be restricted by the container
 technology for some reason.
   - Test case: unshare -U -m -p -f -r --mount-proc true
   - Paul tried this in the operational lxc containers. Successfully.
   - I tried this in a local autopkgtest-unstable lxc container.
 Successfully (unprivileged).
   - Johannes reported that this would be the step that fails.
 * Maybe more, but I don't know what would be missing. Maybe Johannes
   knows.

In this bug, I ask for a new restriction and propose calling it
"needs-userns". It should cover the aspects mentioned above (probably in
more precision).

How does this apply to backends?

 * chroot/schroot: Unsure. Maybe it works, maybe not.
 * docker/podman: If unprivileged, it very likely does not work as the
   user as the user running it would need at least two subuid ranges,
   which is not the default and the container technology would have to
   map the second subuid range to the subuid range of the test user. If
   privileged, it might work (like lxc).
 * lxc/lxd: Our testing indicates that this works.
 * qemu: Any kind of VM-based backend probably just works.
 * unshare: This very much is like unprivileged docker/podman and very
   likely does not work.

What packages would use this beyond mmdebstrap? I see at least
chromium's sandbox using user namespaces for isolation (though with less
required features). Adoption of user namespaces will probably grow.

So initially, it could be as simple as adding this restriction and
statically saying that it is supported by lxc/lxd/qemu and nothing else.

The other part probably is figuring out how to make it work, which may
be either mmdebstrap bugs or missing features on debci, but diagnosing
this is evidently hard.

A number of tests that would benefit from this capability can be run
with needs-root or fakechroot (when it works) instead.

Helmut

Bug#836249: (ITP: cavewhere -- Cave survey processing and visualisation)

2023-02-05 Thread Wookey

Cavewhere has proved problematic to build and package but I think we are nearly 
there.

v1.0 added two new dependencies:
asyncfuture and st3c.

Turned out st3c didn't do anything that libsquish didn't already do,
so it was patched to just use libsquish. Then upstream took that fix.

asyncfuture is now packaged, uploaded and in testing.

qt-qml-models is packaged, but not uploaded as I've never actually got
cavewhere to build against it, so it might be broken.

A serious bug in libsquish packaging was found, which broke the cavewhere build,
but none of the other dependencies. That has been fixed in time for bookworm.

The Cavewhere build now gets further than ever before using system
libraries, but the test library build still fails with a c++
issue. Awaiting comment from upstream. So it's missed bookworm, but I
think we really are nearly there.

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

Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors

2023-02-05 Thread James Addison

Source: openjfx
Followup-For: Bug #1026962

Could the following build-related scripting be something to do with it?

  - 
https://salsa.debian.org/java-team/openjfx/-/blob/debian/11.0.11+1-1.1/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm#L494-499

  - 
https://salsa.debian.org/java-team/openjfx/-/blob/debian/11.0.11+1-1.1/modules/javafx.web/src/main/native/Tools/Scripts/build-webkit#L300-305

(perhaps something about the way that numberOfCPUs is being evaluated on s390x
hosts isn't matching the expectations of the build script)

Bug#1030532: thunderbird: allow historic ~/.mozilla-thunderbird in apparmor

2023-02-05 Thread Matthew Vernon


Hi,

On 05/02/2023 16:40, Carsten Schoenert wrote:

Thanks for the quick reply; apologies, but this isn't going to be a very 
helpful response from me :-/



Am 04.02.23 um 17:50 schrieb Matthew Vernon:



owner @{HOME}/.mozilla-thunderbird/{,**} rwlk,


Looking at the existing profile data template I think this should do the 
trick.





   # per-user thunderbird configuration
   owner @{HOME}/.{icedove,thunderbird}/ rw,
-  owner @{HOME}/.{icedove,thunderbird}/** rw,
+  owner @{HOME}/.{icedove,thunderbird,mozilla-thunderbird}/** rw,
   owner @{HOME}/.{icedove,thunderbird}/**/storage.sdb k,
   owner @{HOME}/.{icedove,thunderbird}/**/*.{db,parentlock,sqlite}* k,
   owner @{HOME}/.{icedove,thunderbird}/plugins/** rm,


This is definitely not sufficient - you need k (lock) permissions inside 
.mozilla-thunderbird for e.g. parentlock (otherwise you get the "another 
thunderbird process is running" message).


I think the answer is to adjust every line that has "owner 
@{HOME}/.{icedove,thunderbird}" to instead have owner 
@{HOME}/.{icedove,thunderbird,mozilla-thunderbird}" is the way to go, 
but I don't have time to try such a patch right now, sorry!


Regards,

Matthew

Bug#1003926: Fix uploaded to "proposed-updates"

2023-02-05 Thread Håvard F . Aasen

Hello,

A fix for this bug has been uploaded to the "proposed-updates"
queue, which will be made available in the next point release
for Bullseye, (11.7). The date for the release is still TBD.


Regards,
Håvard

Bug#1030624: audacious-plugins: I get an a „Server certificate verification failed: bad certificate chain” message, when opened radio M3U/MP3 URL (HTTP or HTTPS). Neon bug?

2023-02-05 Thread Mester Imre

Package: audacious-plugins
Version: 4.0.5-1
Severity: important
X-Debbugs-Cc: mesterimr...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
I opened one URL each. this,
https://archive.tilos.hu/cache/tilos-20230131-090551-101902.mp3
or this.
http://archive.tilos.hu/cache/tilos-20230131-090551-101902.mp3
Looks like a bug to me. I found this:
https://redmine.audacious-media-
player.org/projects/audacious/search?utf8=%E2%9C%93=certificate=_words=1_only==1=1=1=0=0=Elfogad
No problem with other players!
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I compile this,
https://distfiles.audacious-media-player.org/audacious-plugins-4.0.5.tar.bz2
and helped!
Configuration:
https://pastebin.com/fehG18r9
   * What was the outcome of this action?
Problem solved.
   * What outcome did you expect instead?
I would like the developers to fix the DEB package.

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


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

Kernel: Linux 6.1.9-2-liquorix-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.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 audacious-plugins depends on:
ii  audacious-plugins-data 4.0.5-1
ii  libasound2 1.2.4-1.1
ii  libaudcore54.0.5-1
ii  libaudgui5 4.0.5-1
ii  libaudqt2  4.0.5-1
ii  libaudtag3 4.0.5-1
ii  libavcodec-extra58 [libavcodec58]  7:4.3.5-0+deb11u1
ii  libavformat58  7:4.3.5-0+deb11u1
ii  libavutil567:4.3.5-0+deb11u1
ii  libbs2b0   3.1.0+dfsg-2.2+b1
ii  libc6  2.31-13+deb11u5
ii  libcairo2  1.16.0-5
ii  libcddb2   1.3.2-6+b1
ii  libcdio-cdda2  10.2+2.0.0-1+b2
ii  libcdio19  2.1.0-2
ii  libcue22.2.1-3
ii  libcurl3-gnutls7.74.0-1.3+deb11u5
ii  libfaad2   2.10.0-1
ii  libflac8   1.3.3-2+deb11u1
ii  libfluidsynth2 2.1.7-1.1
ii  libgcc-s1  10.2.1-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1+deb11u1
ii  libgl1 1.3.2-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk2.0-02.24.33-2
ii  libjack-jackd2-0 [libjack-0.125]   1.9.17~dfsg-1
ii  liblirc-client00.10.1-6.3
ii  libmms00.6.4-3
ii  libmodplug11:0.8.9.0-3
ii  libmp3lame03.100-3
ii  libmpg123-01.26.4-1
ii  libneon27-gnutls   0.31.2-1
ii  libnotify4 0.7.9-3
ii  libogg01.3.4-0.1
ii  libopenmpt00.4.11-1
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpulse0  14.2-2
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5multimedia5  5.15.2-3
ii  libqt5opengl5  5.15.2+dfsg-9
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libsamplerate0 0.2.1+ds0-1
ii  libsdl2-2.0-0  2.0.14+dfsg2-3+deb11u1
ii  libsidplayfp5  2.0.5-2
ii  libsndfile11.0.31-2
ii  libsndio7.01.5.0-3
ii  libsoxr0   0.1.3-4
ii  libstdc++6 10.2.1-6
ii  libvorbis0a1.3.7-1
ii  libvorbisenc2  1.3.7-1
ii  libvorbisfile3 1.3.7-1
ii  libwavpack15.4.0-1
ii  libx11-6   2:1.7.2-1
ii  libxcomposite1 1:0.4.5-1
ii  libxml22.9.10+dfsg-6.7+deb11u3
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages audacious-plugins recommends:
ii  audacious  4.0.5-1

audacious-plugins suggests no packages.

Bug#1030622: tex-common package post-installation script subprocess returned error exit status 1

2023-02-05 Thread Hilmar Preuße


Am 05.02.2023 um 19:56 teilte Stéphane Glondu mit:

Package: tex-common
Version: 6.18
Severity: serious


Hello,


I got this when upgrading texlive today in testing:

Paramétrage de tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running mtxrun --generate. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.RDPxpv93
Please include this file if you report a bug.


Today the new texlive-base & texlive-extra did migrate to testing and
hence were upgraded on your system. The texlive-lang did not migrate
yet, this will happen soon. Once texlive-lang-japanese is upgraded,
please repeat the test. Is suspect an incompatibility in these packages,
as I'm not able to reproduce the issue using unstable.

For the records: the error message is:

**
*
* making upLaTeX format
*
**
(/usr/share/texlive/texmf-dist/tex/platex/base/plcore.ltx
! Argument of \platexNILa has an extra }.

\par
l.52 ...ter\expandafter\expandafter{\platexBANNER}
  %
?
! Emergency stop.

\par
l.52 ...ter\expandafter\expandafter{\platexBANNER}
  %

Hilmar
--
sigfault

Bug#1030623: deken: broken on Python 3.11, because of hy

2023-02-05 Thread Matthias Geier

Package: deken
Version: 0.9.4-3
Severity: important
X-Debbugs-Cc: matthias.ge...@gmail.com

Dear Maintainer,

I have already reported this at
https://github.com/pure-data/deken/issues/285
and I have been told to report it here.

The problem seems to be that deken doesn't work with Python 3.11.

Here's the error message I got when running any deken command:

This is your first time running deken on this machine.
I'm going to install myself and my dependencies into 
/home/mg/.local/share/deken-debian now.
Feel free to Ctrl-C now if you don't want to do this.
Installing deken.
Fetching Python requirements file: /usr/share/deken/developer/requirements.txt
'/usr/share/deken/developer/requirements.txt' -> 
'/home/mg/.local/share/deken-debian/requirements.txt'
Fetching main hylang file: /usr/share/deken/developer/deken.hy
'/usr/share/deken/developer/deken.hy' -> 
'/home/mg/.local/share/deken-debian/deken.hy'
created virtual environment CPython3.11.1.final.0-64 in 689ms
  creator CPython3Posix(dest=/home/mg/.local/share/deken-debian/virtualenv, 
clear=False, no_vcs_ignore=False, global=True)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, 
wheel=bundle, via=copy, app_data_dir=/home/mg/.local/share/virtualenv)
added seed packages: pip==22.3.1, setuptools==66.1.1, wheel==0.38.4
  activators 
BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator
Installing deken library dependencies.
ERROR: Ignored the following versions that require a different python version: 
0.24.0 Requires-Python >= 3.7, < 3.11; 1.0a4 Requires-Python >= 3.7, < 3.11
ERROR: Could not find a version that satisfies the requirement hy~=1.0a4 (from 
versions: 0.6.0, 0.7.0, 0.7.5, 0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 
0.9.4, 0.9.5, 0.9.6, 0.9.7, 0.9.8, 0.9.9, 0.9.10, 0.9.11, 0.9.12, 0.10.0, 
0.10.1, 0.11.0, 0.11.1, 0.12.0, 0.12.1, 0.13.0, 0.13.1, 0.14.0, 0.15.0, 0.16.0, 
0.17.0, 0.18.0, 0.19.0, 0.20.0, 0.25.0, 1.0a1, 1.0a2, 1.0a3)
ERROR: No matching distribution found for hy~=1.0a4
Installation of requirements failed.
You probably should install the following packages first:
 - 'python3-dev'
 - 'libffi-dev'
 - 'libssl-dev'


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 deken depends on:
ii  curl7.87.0-2
ii  python3-easywebdav  1.2.0-10
ii  python3-gnupg   0.4.9-1
ii  python3-keyring 23.9.3-2
ii  python3-macholib1.16.2+ds0-1
ii  python3-pefile  2022.5.30-1
ii  python3-pyelftools  0.29-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-virtualenv  20.17.1+ds-1

Versions of packages deken recommends:
ii  pd-deken  0.9.4-3

deken suggests no packages.

-- no debconf information

Bug#989705: closing 989705

2023-02-05 Thread Salvatore Bonaccorso

Hi,

On Sun, Feb 05, 2023 at 06:20:54PM +0100, Computer Enthusiastic wrote:
> Hello Salvatore,
> 
> On Tue, 4 Oct 2022 19:39:23 +0200 Computer Enthusiastic
>  wrote:
> > Hello Salvatore,
> > 
> > Il giorno mar 20 set 2022 alle ore 12:32 Salvatore Bonaccorso
> >  ha scritto:
> > >
> > > Hi,
> > [..]
> > > >
> > > > What could be done to make the patch land in the current Debian Stable
> > > > (Bullseye) kernel release ?
> > >
> > > It should land in the 5.10.y stable series which we will then pick up
> > > automatically on next rebases. But what is puzzling is that the commit
> > > has been marked for stable only v5.15+. If you were able to confirm it
> > > is actually present in 5.10.y as well then it needs a followup to be
> > > picked as well for the 5.10.y stable series.
> > >
> > > Regards,
> > > Salvatore
> > 
> > Yes, the patch is marked as only v5.15+, but the issue is still there
> > in kernel 5.10, too.
> > 
> > As you suggested, I have tested the vanilla kernel 5.10.145 with and
> > without kernel patches, as reported here [0].
> > 
> > Thanks.
> > 
> > [0] 
> > https://lists.freedesktop.org/archives/nouveau/2022-September/041182.html
> 
> Thank you for supporting me to explain upstream the request for backporting
> the patch to 5.10.y.
> 
> The patch has been backported to Linux 5.10.166 few days ago [1].
> 
> I suppose it will hopefully be available in the Linux kernel shipped with
> the next Debian point release.

Yes I'm aware. It will be in the update which rebases to at least to
5.10.166 and is currently pending at
https://salsa.debian.org/kernel-team/linux/-/merge_requests/644 .

Regards,
Salvatore

Bug#1012870: dbus-daemon

2023-02-05 Thread Jakob Unterwurzacher

I believe I have fixed the pathological "tmpfs filling up" case via
https://github.com/rfjakob/earlyoom/commit/459d76296d3d0a0b59ee1e2e48ad2271429de916
.

Bug#1030560: Ugly // in symlinks

2023-02-05 Thread Sven Joachim

Control: reassign -1 dh-elpa-helper
Control: tags -1 + patch

On 2023-02-05 08:57 +0800, Dan Jacobson wrote:

> Package: elpa-csv-mode
> Version: 1.21-1
> Severity: minor
>
> We note the ugly double slashes. Yes, cosmetic problem only.
> ls -og ...
> /usr/share/emacs/site-lisp/elpa/csv-mode-1.21:
> -rw-r--r-- 132 01-18 18:15 Install.log.gz
> lrwxrwxrwx 1 72 01-18 18:15 csv-mode-autoloads.el ->
> /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.21//csv-mode-autoloads.el
> lrwxrwxrwx 166 01-18 18:15 csv-mode-pkg.el -> 
> /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.21//csv-mode-pkg.el
> lrwxrwxrwx 168 01-18 18:15 csv-mode-tests.el -> 
> /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.21//csv-mode-tests.el
> -rw-r--r-- 1 15956 01-18 18:15 csv-mode-tests.elc
> lrwxrwxrwx 162 01-18 18:15 csv-mode.el -> 
> /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.21//csv-mode.el
> -rw-r--r-- 1 57160 01-18 18:15 csv-mode.elc

The symlinks are created by the /usr/lib/dh-elpa/helper/install script,
and it does this:

line39:
el_dir=$src_dir/${ELPA_DIR}/

line 53:
(cd ${elc_dir} && ln -sf ${el_dir}/* .)

I have attached a patch which drops the extra second slash.

Cheers,
   Sven

From ae5e65b77517dd2ce8bd2d74099bb9c36529f05b Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Sun, 5 Feb 2023 20:08:27 +0100
Subject: [PATCH] helper scripts: Avoid double slashes in symlinks

Closes: #1030560
---
 helper/install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/helper/install b/helper/install
index 3152cf4..c0679bb 100755
--- a/helper/install
+++ b/helper/install
@@ -50,7 +50,7 @@ echo install/${ELPA_DIR}: byte-compiling for ${FLAVOR}
 # policy).  This makes complation easy, and also allows find-function
 # and find-library to work properly.  Also link all other top level
 # files and directories into the flavor directory
-(cd ${elc_dir} && ln -sf ${el_dir}/* .)
+(cd ${elc_dir} && ln -sf ${el_dir}* .)

 # Byte compile them
 (cd ${elc_dir}
--
2.39.1

Bug#1030622: tex-common package post-installation script subprocess returned error exit status 1

2023-02-05 Thread Stéphane Glondu

Package: tex-common
Version: 6.18
Severity: serious

Dear Maintainer,

I got this when upgrading texlive today in testing:
> Paramétrage de tex-common (6.18) ...
> Running mktexlsr. This may take some time... done.
> Running mtxrun --generate. This may take some time... done.
> Running updmap-sys. This may take some time... done.
> Running mktexlsr /var/lib/texmf ... done.
> Building format(s) --all.
>   This may take some time... 
> fmtutil failed. Output has been stored in
> /tmp/fmtutil.RDPxpv93
> Please include this file if you report a bug.
> 
> dpkg: erreur de traitement du paquet tex-common (--configure) :
>  installed tex-common package post-installation script subprocess returned 
> error exit status 1
> Des erreurs ont été rencontrées pendant l'exécution :
>  tex-common

Attached is the file, as instructed.


Cheers,

-- 
Stéphane

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
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 tex-common depends on:
ii  ucf  3.0043

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  13.11.4

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libpaper-utils 1.1.28+b1
ii  sensible-utils 0.0.17+nmu1
ii  texlive-binaries   2022.20220321.62855-5
ii  ucf3.0043
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
ii  lmodern  2.005-1

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   43.1-2+b1
ii  ghostscript [postscript-viewer]  10.0.0~dfsg-9+b1
ii  perl-tk  1:804.036-1+b1
ii  xpdf [pdf-viewer]3.04+git20220601-1+b2
pn  xzdec

Versions of packages texlive-binaries depends on:
ii  libc6   2.36-8
ii  libcairo2   1.16.0-7
ii  libfontconfig1  2.14.1-3
ii  libfreetype62.12.1+dfsg-4
ii  libgcc-s1   12.2.0-14
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   6.0.0-1
ii  libicu7272.1-3
ii  libkpathsea62022.20220321.62855-5
ii  libmpfr64.2.0-1
ii  libpaper1   1.1.28+b1
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.39-2
ii  libptexenc1 2022.20220321.62855-5
ii  libstdc++6  12.2.0-14
ii  libsynctex2 2022.20220321.62855-5
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2022.20220321.62855-5
ii  libtexluajit2   2022.20220321.62855-5
ii  libx11-62:1.8.3-3
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.12-1.1
ii  libxt6  1:1.2.1-1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-7
ii  t1utils 1.41-4
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages texlive-binaries recommends:
pn  dvisvgm   
ii  texlive-base  2022.20221123-1

-- debconf information excluded


fmtutil.RDPxpv93.xz
Description: application/xz

Bug#1029594: Fails to authenticate mit o365

2023-02-05 Thread Chandler Sobel-Sorenson

Carsten Schoenert wrote on 2/5/23 3:39 AM:
> If you need your laptop or your workstation for mission critical
> things than Debian unstable/sid isn't the right choice. If you do so
> then you will need some knowledge to handle situations like happen
> now.I'm not.  The broken package has been released to testing already.
In an ideal world I would have two separate computers but not everyone
has ideal situations.  testing release is good for my situation and have
now added notifications of important bugs for apt-listbugs config as
well, so thank you for mentioning that.  However, that's not the default
for users.

> Debian doesn't have any really resilient statistics as such
> statistics bases on completely free choice. Debian doesn't collect
> data from users without any confirmation.
Then why are you making assumptions on who the majority of users are?
Such assertions require evidence, such as statistics.

> Most users of Thunderbird are not using M$ products or at least only
> using a small set of features of Exchange or Outlook.com.
Again, how do you know this?  guts or feelings are not valid sources
of statistics.

>> Further, the actual bug in mozilla is #1814536 (OAuth2 authentication
>> | 102.7.1. | Linux - fails) - still Open.  This is an even broader
>> than just o365 as Google uses OAuth2 as well, etc. That bug was
>> reported here in Debian as grave under #1030112 but you closed it as
>> a duplicate of this bug.  That was perhaps mistaken.
> No, it was not.
> Having dozen of issues open that are about the same problem is really
> not helpful to handle the issue.
Okay then, as long as you are certain.

> I don't really understand your problem. What is the problem here?
I'm just voicing my support for keeping the severity at serious while
you keep insisting it should merely be important.

> Even right now the the broken package will not migrate to testing.
Why do you think that?  How do you determine such?  Is your system
configured correct?  It is literally listed in testing on
packages.debian.org and available to be upgraded from 102.6.

> But it will
> also trigger a remove of the version in testing. What do we win?
Maybe less bug reports?  You seem to like that ;)  I'm sure we all do.

> My GMail account is working with the current version in testing means
> to me that Google doesn't has changed something on their side.
> Obviously only MS has changed something.
Okay then, that's good.  Maybe the report on Mozilla is wrong then, I
don't know, I am just putting out there what I've found.

> So finally again as written in other answers: If you need to use
> Thunderbird in a critical environment you shouldn't use unstable/sid
and again as I've said and as you should know, I/we are not, Thunderbird
102.7.1 has already been released to testing.

> as long you don't know how to handle the potential breakage of
> packages. Debian is providing a stable release for productive use, if
> you need newer version of software you can add the backport suite. 
Most of us should already know that.  I too just want to help others not
have to spend time fixing things that can be prevented with a good
severity label.  I have a system with stable, backports, testing,
experimental, unstable, and snapshots repos working fine, for now... ;)

Bug#1030621: pipewire: bad input sample rate result in sound too slow

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

Package: pipewire
Version: 0.3.65-1
Severity: normal

Dear Maintainer,

On a veyron/speedy armhf rockchip laptop which has max98090 sound card,
with gnome-shell and pipewire/wireplumber, I can play sound just fine, but
recording is
somewhat broken - sound is very slow, barely audible.
Before any session, doing
arecord -D hw:0,0 test.raw --rate 48000 -f S16_LE -c2
records sound just fine.
After that, recording using e.g. gnome-sound-recorder works again.


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

Kernel: Linux 6.1.0-3-armmp (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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 pipewire depends on:
ii  adduser  3.130
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.65-1
ii  pipewire-bin 0.3.65-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages

> > This is now solved on
> > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/31
>
> Mangling the maintainers scripts of another package is a delicate issue
> as it's often fragile and can cause hard to debug failures in corner cases.
>
> Personally, I would have turned the versioned packages into empty
> transitional packages. This would have made the upgrade process much
> smoother and avoided this issue altogether (the new empty versioned
> packages would have no maintainer scripts).
> It's also common practice for such use cases.
>
> Any reason why you didn't consider this approach?

I did write the code for empty packages and tested it (as visible in
the merge request above) but it would have created much more moving
parts and failures elsewhere. Fixing the maintainer scripts proved to
be the most elegant solution.

Bug#964540: dropwatch build times out in the testsuite