Bug#1075741: elpa-jedi-core: deprecated warning on jedi server

[Thomas Krichel]

Package: elpa-jedi-core
Version: 0.2.8+git20220410.81c5a42-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

  Edit a python file in emacs with jedi enabled.

archec@tagol:~$ grep jedi .emacs
(add-hook 'python-mode-hook 'jedi:setup)
(setq jedi:complete-on-dot t) ; optional

   The error buffer, when opening *.py is


|Failed to start Jedi EPC server.
|
|
|*** EPC Error ***
|Server may raise an error. Use "M-x epc:pop-to-last-server-process-buffer RET" 
to see full traceback:
|/usr/share/emacs/site-lisp/elpa/jedi-core-0.3.0/jediepcserver.py:37: 
DeprecationWarning: pkg_resources is deprecated as an API. See 
https://setuptools.pypa.io/en/latest/pkg_resources.html
| import pkg_resources
|
|
|*** EPC Server Output (last 10 lines) ***
|/usr/share/emacs/site-lisp/elpa/jedi-core-0.3.0/jediepcserver.py:37: 
DeprecationWarning: pkg_resources is deprecated as an API. See 
https://setuptools.pypa.io/en/latest/pkg_resources.html
| import pkg_resources
|
|
|*** EPC Server Config ***
|Server arguments: ("/usr/bin/python" 
"/usr/share/emacs/site-lisp/elpa/jedi-core-0.3.0/jediepcserver.py")
|Actual command: /usr/bin/python
|VIRTUAL_ENV envvar: nil
|
|*** jedi-mode is disabled in # ***
|Fix the problem and re-enable it.
|
|*** You may need to run "M-x jedi:install-server". ***
|This could solve the problem especially if you haven't run the command yet
|since Jedi.el installation or update and if the server complains about
|Python module imports.
|


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

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


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

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

Versions of packages elpa-jedi-core depends on:
ii  dh-elpa-helper   2.0.17
ii  elpa-epc 0.1.1-6
ii  elpa-python-environment  0.0.2-6
ii  emacsen-common   3.0.5
ii  python3  3.11.8-1
ii  python3-epc  0.0.5-5
ii  python3-jedi 0.19.1+ds1-1
ii  python3-sexpdata 1.0.2-1
ii  virtualenv   20.26.2+ds-1

Versions of packages elpa-jedi-core recommends:
ii  emacs  1:29.4+1-3
ii  emacs-nox [emacs]  1:29.4+1-3

elpa-jedi-core suggests no packages.

-- no debconf information

Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2

[Jérémy Lal]

Le jeu. 4 juil. 2024 à 06:33, Salvatore Bonaccorso  a
écrit :

> Hi,
>
> On Wed, Jul 03, 2024 at 11:36:46PM +0200, Jérémy Lal wrote:
> > Le mer. 3 juil. 2024 à 23:04, Andres Salomon  a
> écrit :
> >
> > >
> > >
> > > On 6/25/24 16:34, Jérémy Lal wrote:
> > > >
> > > >
> > > > Le mar. 25 juin 2024 à 22:22, Salvatore Bonaccorso <
> car...@debian.org
> > > > > a écrit :
> > > [...]
> > > >
> > > > Thanks a lot for your work Adrian. Please note that there is
> > > currently
> > > > a nodejs upload pending for releasing via a DSA, which will
> rebase
> > > > nodejs to 18.20.3+dfsg-1~deb12u1 so this might invalidate those
> > > > changes.
> > > >
> > > > Jérémy, Aron is that something you want to have included in your
> > > > prepared update?
> > > >
> > > >
> > > > Indeed, it's applied to 18.20.3+dfsg-1~deb12u1, along with other
> skipped
> > > > tests.
> > > > I'll resume work on this by the end of the week.
> > > >
> > >
> > > While we wait for this, is there any reason to keep the existing
> > > 18.20.3+dfsg-1~deb12u1 upload in the embargoed security queue? Security
> > > packages are actively building against it, which is a bit of a problem
> > > for reproducibility. Someone actually asked me about oddities in the
> > > chromium package that was originally built for bookworm-security, and
> > > now sits in the 12.6 point release. It turns out that it built against
> > > the embargoed nodejs, but since that nodejs package was never released,
> > > they can't use it to reproduce the chromium in 12.6.
> > >
> > > If there's a new nodejs bookworm-security package being uploaded at
> some
> > > point and the currently embargoed nodejs package will never be
> released,
> > > perhaps we should REJECT it now?
> > >
> >
> > Sorry, probably me being overbooked here.
> > I was supposed to check the regressions against it, and been on another
> job
> > since then.
>
> Aron is taking care of the DSA, so I do not want to interfer here with
> his planning, but sharing an idea: There will be an upcoming release
> for nodejs on Monday, 8th (actually was planned for today):
> https://nodejs.org/en/blog/vulnerability/july-2024-security-releases
>
> Do you think you will be less overbooked, can review the regression
> report and with Aron's help work on fixing the new CVEs for mondays
> release and we base the update upon that?
>

Yes, I'll have more time next week, so it's doable.


>
> Again, I do not mean to interfer here with Aron was thinking about
> releasing the packages.
>
> Regards,
> Salvatore
>

Bug#1075742: RFS: adminer/4.8.1-3 [RC] -- Web-based database administration tool

[Alexandre Rossi]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : adminer
   Version  : 4.8.1-3
 * URL  : https://www.adminer.org/
 * License  : Apache-2.0, MIT
 * Vcs  : https://salsa.debian.org/debian/adminer
   Section  : web

The source builds the following binary packages:

  adminer - Web-based database administration tool

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/adminer/adminer_4.8.1-3.dsc

Changes since the last upload:

 adminer (4.8.1-3) unstable; urgency=medium
 .
   * backport fixes for CVE-2023-45196 CVE-2023-45195 (Closes: #1074430)

Regards,
-- 
  Alexandre Rossi

Bug#1075743: RFS: uwsgi/2.0.26-1 -- fast, self-healing application container server

[Alexandre Rossi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : uwsgi
   Version  : 2.0.26-1
   Upstream contact : https://github.com/unbit/uwsgi/issues
 * URL  : http://projects.unbit.it/uwsgi/
 * License  : GPL-2+, GPL-2, Apache-2.0
 * Vcs  : https://salsa.debian.org/uwsgi-team/uwsgi
   Section  : httpd

The source builds the following binary packages:

  libapache2-mod-ruwsgi - uwsgi module for Apache2 (mod_Ruwsgi)
  libapache2-mod-ruwsgi-dbg - debugging symbols for Apache2 mod_Ruwsgi
  libapache2-mod-uwsgi - uwsgi module for Apache2 (mod_uwsgi)
  libapache2-mod-uwsgi-dbg - debugging symbols for Apache2 mod_uwsgi
  python3-uwsgidecorators - module of decorators for elegant access to uWSGI 
API (Python 3)
  uwsgi - fast, self-healing application container server
  uwsgi-app-integration-plugins - plugins for integration of uWSGI and 
application
  uwsgi-core - fast, self-healing application container server (core)
  uwsgi-dbg - debugging symbols for uWSGI server and it's plugins
  uwsgi-dev - fast, self-healing application container server (headers)
  uwsgi-emperor - fast, self-healing application container server (emperor 
scripts)
  uwsgi-extra - fast, self-healing application container server (extra files)
  uwsgi-infrastructure-plugins - infrastructure plugins for uWSGI
  uwsgi-plugin-alarm-curl - cURL alarm plugin for uWSGI
  uwsgi-plugin-alarm-xmpp - XMPP alarm plugin for uWSGI
  uwsgi-plugin-asyncio-python3 - asyncio plugin for uWSGI (Python 3)
  uwsgi-plugin-curl-cron - cron cURL plugin for uWSGI
  uwsgi-plugin-emperor-pg - Emperor PostgreSQL plugin for uWSGI
  uwsgi-plugin-fiber - Fiber plugin for uWSGI
  uwsgi-plugin-gccgo - GNU Go plugin for uWSGI
  uwsgi-plugin-geoip - GeoIP plugin for uWSGI
  uwsgi-plugin-gevent-python3 - gevent plugin for uWSGI (Python 3)
  uwsgi-plugin-glusterfs - GlusterFS storage plugin for uWSGI
  uwsgi-plugin-graylog2 - graylog2 plugin for uWSGI
  uwsgi-plugin-greenlet-python3 - greenlet plugin for uWSGI (Python 3)
  uwsgi-plugin-jvm-openjdk-17 - Java plugin for uWSGI (OpenJDK 17)
  uwsgi-plugin-jwsgi-openjdk-17 - JWSGI plugin for uWSGI (OpenJDK 17)
  uwsgi-plugin-ldap - LDAP plugin for uWSGI
  uwsgi-plugin-lua5.1 - Lua WSAPI plugin for uWSGI (Lua 5.1)
  uwsgi-plugin-mono - Mono/ASP.NET plugin for uWSGI
  uwsgi-plugin-psgi - Perl PSGI plugin for uWSGI
  uwsgi-plugin-python3 - WSGI plugin for uWSGI (Python 3)
  uwsgi-plugin-rack-ruby3.1 - Rack plugin for uWSGI (${uwsgi:RubyKind})
  uwsgi-plugin-rados - Ceph/RADOS storage plugin for uWSGI
  uwsgi-plugin-rbthreads - Ruby native threads plugin for uWSGI 
(${uwsgi:RubyDefaultkind})
  uwsgi-plugin-ring-openjdk-17 - Closure/Ring plugin for uWSGI (OpenJDK 17)
  uwsgi-plugin-router-access - Access router plugin for uWSGI
  uwsgi-plugin-servlet-openjdk-17 - JWSGI plugin for uWSGI (OpenJDK 17)
  uwsgi-plugin-sqlite3 - SQLite 3 configurations plugin for uWSGI
  uwsgi-plugin-tornado-python3 - tornado plugin for uWSGI (Python 3)
  uwsgi-plugin-xslt - XSLT request plugin for uWSGI
  uwsgi-plugins-all - all available plugins for uWSGI
  uwsgi-src - sources for uWSGI plugins

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/u/uwsgi/uwsgi_2.0.26-1.dsc

Changes since the last upload:

 uwsgi (2.0.26-1) unstable; urgency=medium
 .
   * New upstream version 2.0.26
   * silence lintian on plugins needing linking to libc (uneeded)
   * remove shebang on initscript modules that are only sourced
   * remove obolete Provides/Conflicts of uwsgi-core
   * uwsgi-emperor is arch independant
   * drop useless build dep on libbz2-dev, libdb-dev, libonig-dev
   * drop 1007_purge_lru-restore-fix.patch (already applied in source)
   * unfuzz patches
   * run upstream integration tests as autopkgtest

Regards,
-- 
  Alexandre Rossi

Bug#1074782: sqitch: autopkgtests failing with new MariaDB 11.4

[Otto Kekäläinen]

Hi Christian!

Could you help with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074782?

It might be the same root cause as for pdns in 1074780.

Bug#1071355: In how far are several packages affected by bug #1071355 of maptools

[Graham Inggs]

Hi Andreas

On Thu, 4 Jul 2024 at 05:56, Andreas Tille  wrote:
> However, before doing so I would like to
> understand why packages like r-cran-factominer, r-cran-ggpubr,
> r-cran-vim, r-cran-systemfit, r-cran-survminer and others where I can't
> see any connection to r-cran-maptools were removed from testing.

The tracker pages for those packages provide the clue:

https://tracker.debian.org/pkg/r-cran-factominer
Blocked by: car

https://tracker.debian.org/pkg/r-cran-ggpubr
Blocked by: r-cran-rstatix

https://tracker.debian.org/pkg/r-cran-vim
Blocked by: car

https://tracker.debian.org/pkg/r-cran-systemfit
Blocked by: car

https://tracker.debian.org/pkg/r-cran-survminer
Blocked by: r-cran-ggpubr

Until recently, car had a dependency on r-cran-maptools, which was
dropped in the 3.1-2-3 upload.

Regards
Graham

Bug#1074782: sqitch: autopkgtests failing with new MariaDB 11.4

[gregor herrmann]

On Tue, 02 Jul 2024 18:34:44 -0700, o...@debian.org wrote:

> MariaDB 1:11.4.2-1 was recently uploaded to Debian. MariaDB 11.4 and MySQL 8.4
> are slowly diverging more and more.

That's bad, and might cause (or already causes) issues with
lib{mysql,mariadb}-perl.
 
> As a result of the new version the sqitch autopkgtests are currently failing,
> but the reason is a bit unclear.
> Could you please assist in reading what the actual error in the logs is?
> https://ci.debian.net/packages/s/sqitch/testing/amd64/48409017/

The test fails in t/sqlite.t which runs tests against SQLite so I'm
pretty sure there is no relationship to a new MariaDB or MySQL
version.
 
> All tests seem to say 'ok' and searching for 'not ok' yields zero results.
> 
> Log ends with:
> 
>  Test Summary Report
>  t/sqlite.t(Wstat: 65280 (exited 255) Tests: 127 Failed: 0)
>  Non-zero exit status: 255
>Parse errors: No plan found in TAP output
>  Files=50, Tests=7508, 28 wallclock secs ( 0.50 usr  0.12 sys + 20.46 cusr  
> 5.14 csys = 26.22 CPU)
>  Result: FAIL

Going back up in the log and looking at the start of t/sqlite.t we
see:

 61s t/sqlite.t .. 
…
 61s UNIQUE constraint failed: events.change_id, events.committed_at
 61s DBD::SQLite::db do failed: UNIQUE constraint failed: events.change_id, 
events.committed_at
 61s Trace begun at /usr/share/perl5/App/Sqitch/Role/DBIEngine.pm line 613
 61s 
App::Sqitch::Role::DBIEngine::_log_event('App::Sqitch::Engine::sqlite=HASH(0x55a9edc41988)',
 'deploy', 'App::Sqitch::Plan::Change=HASH(0x55a9ec5d79a8)') called at 
/usr/share/perl5/App/Sqitch/Role/DBIEngine.pm line 582
 61s 
App::Sqitch::Role::DBIEngine::log_deploy_change('App::Sqitch::Engine::sqlite=HASH(0x55a9edc41988)',
 'App::Sqitch::Plan::Change=HASH(0x55a9ec5d79a8)') called at 
t/lib/DBIEngineTest.pm line 1603
 61s DBIEngineTest::__ANON__ at /usr/share/perl/5.38/Test/Builder.pm line 374
 61s eval {...} at /usr/share/perl/5.38/Test/Builder.pm line 374
 61s Test::Builder::subtest('Test::Builder=HASH(0x55a9eaaf0778)', 'live 
database', 'CODE(0x55a9edc2c158)') called at /usr/share/perl/5.38/Test/More.pm 
line 831
 61s Test::More::subtest('live database', 'CODE(0x55a9edc2c158)') called at 
t/lib/DBIEngineTest.pm line 1825
 61s DBIEngineTest::run('DBIEngineTest', 'class', 
'App::Sqitch::Engine::sqlite', 'version_query', 'select \'SQLite \' || 
sqlite_version()', 'target_params', 'ARRAY(0x55a9edb0bc58)', 
'alt_target_params', 'ARRAY(0x55a9edb0c528)', 'skip_unless', 
'CODE(0x55a9ece79ea0)', 'engine_err_regex', 'Regexp=REGEXP(0x55a9edc17ae0)', 
'init_error', 'Sqitch database /tmp/EWQTZjTBKx/sqitchtestk6jkt876.db already 
initialized', 'test_dbh', 'CODE(0x55a9ece82d30)', 'add_second_format', 
'strftime(\'%%Y-%%m-%%d %%H:%%M:%%f\', strftime(\'%%J\', %s) + (1/86400.0))') 
called at t/sqlite.t line 403
 61s # Tests were run but no plan was declared and done_testing() was not seen.
 61s # Looks like your test exited with 255 just after 127.
 61s Dubious, test returned 255 (wstat 65280, 0xff00)
 61s All 127 subtests passed 

Whatever is happening here, the failure is related to DBD::SQLite.

(That this failure isn't propagated up to the test (so no "not ok")
and that t/sqlite.t doesn't even finish (hence the "and done_testing() was not
seen") is not beautiful …)


Cheers,
gregor


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

Bug#1074790: RFS: sqlitestudio/3.4.4-1 [ITP] -- SQLite database manager

[Phil Wyett]

Control: tags -1 + moreinfo

Hi Yangfl,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Issue

I: sqlitestudio: spelling-error-in-binary "GNU Library Public License" "GNU 
Library General Public
License" [usr/lib/x86_64-linux-gnu/libcoreSQLiteStudio.so.1.0.0]

I: sqlitestudio: spelling-error-in-binary "allows to" "allows one to" 
[usr/lib/x86_64-linux-
gnu/libguiSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary bahavior behavior 
[usr/lib/x86_64-linux-
gnu/libguiSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary commited committed 
[usr/lib/x86_64-linux-
gnu/libguiSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary completly completely 
[usr/lib/x86_64-linux-
gnu/libguiSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary faild failed [usr/lib/x86_64-linux-
gnu/libcoreSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary occured occurred 
[usr/lib/x86_64-linux-
gnu/libcoreSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary occured occurred 
[usr/lib/x86_64-linux-
gnu/libguiSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary overriden overridden 
[usr/lib/x86_64-linux-
gnu/libguiSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary problably probably 
[usr/lib/x86_64-linux-
gnu/libguiSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary quering querying 
[usr/lib/x86_64-linux-
gnu/libcoreSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio: spelling-error-in-binary writting writing 
[usr/lib/x86_64-linux-
gnu/libcoreSQLiteStudio.so.1.0.0]
N:
I: sqlitestudio-plugins: spelling-error-in-binary "GNU Public Licence" "GNU 
General Public License"
[usr/lib/x86_64-linux-gnu/sqlitestudio/libDbSqliteCipher.so]
N:
I: sqlitestudio-plugins: spelling-error-in-binary aheared adhered 
[usr/lib/x86_64-linux-
gnu/sqlitestudio/libDbSqliteCipher.so]
N:
I: sqlitestudio-plugins: spelling-error-in-binary attemt attempt 
[usr/lib/x86_64-linux-
gnu/sqlitestudio/libDbSqliteCipher.so]
N:
I: sqlitestudio-plugins: spelling-error-in-binary embeded embedded 
[usr/lib/x86_64-linux-
gnu/sqlitestudio/libDbAndroid.so]
N:
I: sqlitestudio-plugins: spelling-error-in-binary proccess process 
[usr/lib/x86_64-linux-
gnu/sqlitestudio/libScriptingTcl.so]
N:
I: sqlitestudio-plugins: spelling-error-in-binary rouines routines 
[usr/lib/x86_64-linux-
gnu/sqlitestudio/libDbSqliteCipher.so]
N:
I: sqlitestudio-plugins: spelling-error-in-binary writting writing 
[usr/lib/x86_64-linux-
gnu/sqlitestudio/libMultiEditorImage.so]

3. Licenses: Issue

philwyett@ks-windu:~/Development/builder/debian/mentoring/sqlitestudio-3.4.4$ 
lrc
en: Versions: recon 1.11  check 3.3.9-1

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

GPL-3 with OpenSSL exception| OpenSSL  
Plugins/DbSqliteCipher/openssl_lic.txt
Expat   | BSD-3-clause 
SQLiteStudio3/coreSQLiteStudio/chillout/windows/StackWalker.h
Apache-2| Apache-2.0   
SQLiteStudio3/coreSQLiteStudio/diff/diff_match_patch.cpp
Apache-2| Apache-2.0   
SQLiteStudio3/coreSQLiteStudio/diff/diff_match_patch.h
GPL-3 with OpenSSL exception| Apache-
2.0   SQLiteStudio3/coreSQLiteStudio/licenses/diff_match.txt
GPL-3 with OpenSSL exception| GPL-3
SQLiteStudio3/coreSQLiteStudio/licenses/gpl.txt
GPL-3 with OpenSSL exception| Unicode-DFS-2016 
SQLiteStudio3/coreSQLiteStudio/licenses/icu.txt
GPL-3 with OpenSSL exception| LGPL-2.1 
SQLiteStudio3/coreSQLiteStudio/licenses/lgpl.txt
GPL-3 with OpenSSL exception| Expat
SQLiteStudio3/coreSQLiteStudio/licenses/mit.txt
GPL-3 with OpenSSL exception| GPL-
3+   SQLiteStudio3/coreSQLiteStudio/licenses/sqlitestudio_license.txt
GPL-3 with OpenSSL exception| LGPL 
SQLiteStudio3/Tests/TestUtils/hippomocks.h

Link to preserve formatting: https://paste.debian.net/1322257/

4. Build Twice (sudo pbuilder build --twice .dsc): Fail

 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building sqlitestudio using existing 
./sqlitestudio_3.4.4.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: local changes detected, the modified files are:
 sqlitestudio-3.4.4/Plugins/ConfigMigration/qmake_qmake_qm_files.qrc
 sqlitestudio-3.4.4/Plugins/CsvExport/qmake_qmake_qm_files.qrc
 sqlitestudio-3.4.4/Plugins/CsvImport/qmake_qmake_qm_files.qrc
 sqlitestudio-3.4.4/Plugins/DbAndroid/qmake_qmake_qm_files.qrc
 sqlitestudio-3.4.4/Plugins/DbSqliteCipher/qmake_qmake_qm_files.qrc
 sqlitestudio-3.4.4/Plugins

Bug#1074654: skimage: FTBFS: ModuleNotFoundError: No module named 'distutils'

[Ole Streicher]

Control: reassign -1 python3-pythran/0.16.1+ds-3

I *think* this is a bug in Pythran. The relevant extract from the
failure log is:


[9/168] /usr/bin/pythran -E ../skimage/feature/brief_pythran.py -o 
skimage/feature/brief_cy.cpp
FAILED: skimage/feature/brief_cy.cpp 
/usr/bin/pythran -E ../skimage/feature/brief_pythran.py -o skimage/feature/brief_cy.cpp

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pythran/dist.py", line 20, in 
from distutils.command.build_ext import build_ext as LegacyBuildExt
ModuleNotFoundError: No module named 'distutils'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/pythran", line 8, in 
sys.exit(run())
 ^
  File "/usr/lib/python3/dist-packages/pythran/run.py", line 190, in run
pythran.compile_pythranfile(args.input_file,
^^^
  File "/usr/lib/python3/dist-packages/pythran/__init__.py", line 127, in 
__getattr__
import pythran.toolchain
  File "/usr/lib/python3/dist-packages/pythran/toolchain.py", line 11, in 

from pythran.dist import PythranExtension, PythranBuildExt
  File "/usr/lib/python3/dist-packages/pythran/dist.py", line 22, in 
from setuptools.command.build_ext import build_ext as LegacyBuildExt
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 9, in 

import distutils.core
ModuleNotFoundError: No module named 'distutils'


which show that the invocation of the "pythran" executable fails while trying 
to import the build_ext module from either distutils or setuptools.

Could you investigate this?

Bug#1075742: RFS: adminer/4.8.1-3 [RC] -- Web-based database administration tool

[Phil Wyett]

Hi Alexandre,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Issue

I: adminer source: composer-package-without-pkg-php-tools-builddep 
[composer.json]
N: 
N:   The package contains a composer.json file but doesn't build-depend on
N:   pkg-php-tools.
N:   
N:   pkg-php-tools is the recommended tool for building PHP Composer packages.
N:   For more information, install it and read the included README.Composer.
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: languages/php/pear

I: adminer: package-contains-empty-directory [usr/share/adminer/designs/hydra/]
N: 
N:   This package installs an empty directory. This might be intentional but
N:   it's normally a mistake. If it is intentional, add a Lintian override.
N:   
N:   If a package ships with or installs empty directories, you can remove them
N:   in debian/rules by calling:
N:   
N:$ find path/to/base/dir -type d -empty -delete
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: files/empty-directories
N: 
N:
I: adminer: package-contains-empty-directory 
[usr/share/adminer/designs/pepa-linha-dark/]

3. Licenses: Issue

philwyett@ks-windu:~/Development/builder/debian/mentoring/adminer-4.8.1$ lrc
en: Versions: recon 1.11  check 3.3.9-1

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

MIT | Expatdesigns/price/adminer.css
Apache-2.0  | Expatdesigns/rmsoft/adminer.css
Apache-2.0  | Expatdesigns/rmsoft_blue/adminer.css

Debian copyright year should also be updated with any changes.

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Reproducible builds (reporotest)[1]: Good

6. Install (No previous installs): Good

7. Upgrade (Over previous installs if any): Good

Summary...

I believe adminer is ready for sponsorship/upload. Could a Debian Developer 
(DD) with available free
time, please review this package and upload if you feel it is ready.

I would hope the issues raised will be given consideration post this CVE upload.

[1] https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1075744: pyinstall and pyremove choke on empty lines

[Julian Gilbey]

Package: dh-python
Version: 6.20240603
Severity: normal
Tags: patch

The pyinstall and pyremove functions
/usr/share/dh-python/dhpython/tools.py fail if the relevant file in
debian/ has a blank line.  This is because of lines 277 and 321 in
this file, which read:

if not line or line.startswith('#'):

A blank line will have line == "\n", so "not line" is false.  A
correct test would be, for example,

if line.strip() == "" or line.startswith('#'):

Best wishes,

   Julian

Bug#1013958: Context menu prefers Chromium over x-www-browser

[Alexis Huxley]

Package: xfce4-terminal
Version: 1.0.4-1
Followup-For: Bug #1013958

I think this bug is considerably more complicated that the OP suggests:
there are numerous suggestions on the web about how to workaround it,
none of which work for everybody, none of which worked for me, and most
of which don't work for a significant proportion of people.  for me.

This bug is noted upstream as XFCE bug 10314, which is detailed
at https://bugzilla.xfce.org/show_bug.cgi?id=10314.

Amazingly, there is a suggestion there that worked for me, namely the
one detailed by 'runkharr', which I reproduce here in case it helps
fellow Debian users and so we all get on the same page.

1. Create a file `exo-launch.desktop´ in your `~/.local/share/applications´ 
directory wit something like the following content:

[Desktop Entry]
Name=Exo Launcher
Type=Application
Icon=gtk-open
Categories=Desktop;
Comment=A try to force 'xfce4-terminal' to use the preferred application(s)
GenericName=Exo Launcher
Exec=exo-open %u

MimeType=text/html;application/xhtml+xml;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;application/x-mimearchive;
Terminal=false
OnlyShowIn=XFCE;

2. Create (if not already existing) a local `defaults.list´ file, again in your 
`~/.local/share/applications´ directory. This file must start with a "group 
header" of

[Default Applications]

3. Insert the following three lines somewhere below this `[Default 
Applications]´ group header the folowing three lines:

x-scheme-handler/http=exo-launch.desktop;
x-scheme-handler/https=exo-launch.desktop;
x-scheme-handler/ftp=exo-launch.desktop;

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

Kernel: Linux 6.1.0-22-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 xfce4-terminal depends on:
ii  exo-utils4.18.0-1
ii  libc62.36-9+deb12u7
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+deb12u1
ii  libglib2.0-0 2.74.6-2+deb12u3
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libutempter0 1.2.1-3
ii  libvte-2.91-00.70.6-2~deb12u1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libxfce4ui-2-0   4.18.2-2
ii  libxfce4util74.18.1-2
ii  libxfconf-0-34.18.0-2

Versions of packages xfce4-terminal recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-1~deb12u1
ii  dbus-x11 [dbus-session-bus]   1.14.10-1~deb12u1

xfce4-terminal suggests no packages.

-- no debconf information

Bug#1075603: debugpy: incompatible with new pydevd

[Drew Parsons]

Source: debugpy
Followup-For: Bug #1075603

Upstream v1.8.2 builds "cleanly" with upstream's vendored debugpy.

To do this of course all the de-vendoring patches had to be removed, that's
debian/patches
debian/copyright
debian/rules

You've already got the tests set up to try single processing tests
(-n1) if the standard multiprocess test run fails, which indeed it does.

But the -n1 tests pass fine

python3.11 (-n1)
== 1179 passed, 38 skipped, 2 warnings in 5154.06s (1:25:54) ===

python3.12 (-n1)
== 1179 passed, 38 skipped, 2 warnings in 5499.79s (1:31:39) ===



With the multiprocess tests (8 proc), the summary is

python3.11
=== short test summary info 
FAILED tests/debugpy/test_evaluate.py::test_return_values[program-launch-hide]
FAILED 
tests/debugpy/test_breakpoints.py::test_conditional_breakpoint[launch-program-hitCondition->=5]
FAILED 
tests/debugpy/test_exception.py::test_systemexit[1-zero-uncaught-raised-launch(console=internalConsole)-program]
FAILED 
tests/debugpy/test_env.py::test_env_replace_var[program-launch(console=integratedTerminal)-match_case-42]
FAILED 
tests/debugpy/test_exception.py::test_systemexit[0--uncaught--launch(console=externalTerminal)-module]
FAILED 
tests/debugpy/test_exception.py::test_success_exitcodes[-break_on_system_exit_zero-0-launch(console=internalConsole)-module]
FAILED 
tests/debugpy/test_exception.py::test_systemexit[1launch(console=integratedTerminal)-module]
FAILED 
tests/debugpy/test_exception.py::test_systemexit[1-zero---launch(console=internalConsole)-module]
FAILED 
tests/debugpy/test_exception.py::test_systemexit[nan--uncaught--launch(console=integratedTerminal)-program]
FAILED 
tests/debugpy/test_exception.py::test_success_exitcodes[--3-launch(console=internalConsole)-module]
FAILED tests/debugpy/test_output.py::test_with_no_output[program-attach_pid]
FAILED 
tests/debugpy/test_output.py::test_redirect_output[program-enabled-attach_pid]
FAILED 
tests/debugpy/test_run.py::test_custom_python_args[program-python-custompy,-O-None-launch(console=internalConsole)]
FAILED 
tests/debugpy/test_output.py::test_redirect_output[program-disabled-attach_pid]
FAILED tests/debugpy/test_flask.py::test_flask_breakpoint_multiproc[launch]
FAILED tests/tests/test_timeline.py::test_concurrency[mark_then_wait]
FAILED tests/tests/test_timeline.py::test_occurrences
FAILED tests/debugpy/test_gevent.py::test_gevent[program-launch]
FAILED tests/tests/test_timeline.py::test_concurrency[wait_then_mark]
ERROR tests/debugpy/test_output.py::test_with_no_output[program-attach_pid]
ERROR 
tests/debugpy/test_output.py::test_redirect_output[program-enabled-attach_pid]
ERROR 
tests/debugpy/test_output.py::test_redirect_output[program-disabled-attach_pid]
= 19 failed, 1161 passed, 38 skipped, 48 warnings, 3 errors in 3002.37s 
(0:50:02) =

python3.12
=== short test summary info 
FAILED 
tests/debugpy/test_env.py::test_env_replace_var[program-launch(console=externalTerminal)-match_case-42]
FAILED 
tests/debugpy/test_breakpoints.py::test_conditional_breakpoint[attach_connect(cli)-program-hitCondition->5]
FAILED tests/debugpy/test_breakpoints.py::test_break_api[launch-breakpoint-code]
FAILED 
tests/debugpy/test_exception.py::test_systemexit[0-zero-uncaught--launch(console=integratedTerminal)-program]
FAILED tests/debugpy/test_flask.py::test_flask_breakpoint_multiproc[launch]
FAILED 
tests/debugpy/test_output.py::test_redirect_output[program-enabled-attach_pid]
FAILED 
tests/debugpy/test_output.py::test_redirect_output[program-disabled-attach_pid]
FAILED tests/debugpy/test_output.py::test_with_no_output[program-attach_pid]
FAILED 
tests/debugpy/test_run.py::test_custom_python_args[program-python-custompy,-O-None-launch(console=internalConsole)]
FAILED 
tests/debugpy/test_stop_on_entry.py::test_stop_on_entry[program-launch(console=internalConsole)-breakpoint]
FAILED 
tests/debugpy/test_run.py::test_custom_python_args[program-pythonPath-custompy,-O-None-launch(console=integratedTerminal)]
FAILED tests/tests/test_timeline.py::test_occurrences
FAILED tests/tests/test_timeline.py::test_unobserved
FAILED tests/debugpy/test_gevent.py::test_gevent[program-launch]
FAILED 
tests/debugpy/test_stop_on_entry.py::test_stop_on_entry[program-launch(console=internalConsole)-]
FAILED 
tests/debugpy/test_stop_on_entry.py::test_stop_on_entry[program-launch(console=integratedTerminal)-]
FAILED 
tests/debugpy/test_stop_on_entry.py::test_stop_on_entry[program-launch(console=integratedTerminal)-breakpoint]
FAILED 
tests/debugpy/test_stop_on_entry.py::test_stop_on_entry[program-launch(console=externalTerminal)-breakpoint]
FAILED 
tests/debugpy/test_stop_on_entry.py::test_stop_on_entry[program-launch(console=externalTerminal)-]
FAILED 
tests/debugpy/test_stop_on_entry.py::test_stop_on_entry[module-launch(console=internalConsole)-]
FAILED 
tests/debugpy/test_stop_on_entry.py::test_sto

Bug#1075745: sqlalchemy breaks sqlacodegen (autopkgtest only?)

[Paul Gevers]

Source: sqlalchemy
Control: found -1 sqlalchemy/2.0.31+ds1-1
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: breaks

Dear maintainer(s),

With a recent upload of sqlalchemy the autopkgtest of sqlacodegen fails 
in testing when that autopkgtest is run with the binary packages of 
sqlalchemy from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
sqlalchemy from testing2.0.31+ds1-1
sqlacodegenfrom testing3.0.0~rc3-2
all others from testingfrom testing

The package of sqlacodegen in unstable isn't affected and it also has 
this in the changelog: "Require sqlalchemy version 2+". So it seems to 
me that the new version of sqlalchemy Breaks the version of sqlacodegen 
in testing. To avoid surprises during (partial) upgrades, maybe a 
versioned Breaks is appropriate? With the versioned Breaks, britney2 
(the migration software) can also figure out that the packages need to 
go together, schedule the autopkgtest with both packages from unstable, 
so it will not show the regression. If this happens to be a test only 
issue (given the changelog entry and the versioned (Build-)Depends I 
doubt this) and you don't want to add the versioned Breaks, please let 
the Release Team know, such that we can apply the right tricks.


I copied some of the output at the bottom of this report.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=sqlalchemy

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sqlacodegen/48418754/log.gz

=== FAILURES 
===
 61s _ test_cli_declarative 
_

 61s tests/test_cli.py:103: in test_cli_declarative
 61s assert (
 61s E   AssertionError: assert 'from sqlalch...olumn(Text)\n' == 'from 
sqlalch...olumn(Text)\n'

 61s E  61s E   from sqlalchemy import Integer, Text
 61s E +  61s E   from sqlalchemy.orm import DeclarativeBase, 
Mapped, mapped_column

 61s E61s E   class Base(DeclarativeBase):
 61s E   pass...
 61s E  61s E ...Full output truncated (7 lines hidden), use 
'-vv' to show
 61s __ test_cli_dataclass 
__

 61s tests/test_cli.py:159: in test_cli_dataclass
 61s assert (
 61s E   AssertionError: assert 'from sqlalch...olumn(Text)\n' == 'from 
sqlalch...olumn(Text)\n'

 61s E  61s E   from sqlalchemy import Integer, Text
 61s E +  61s E   from sqlalchemy.orm import DeclarativeBase, 
Mapped, MappedAsDataclass, mapped_column

 61s E61s E   class Base(MappedAsDataclass, DeclarativeBase):
 61s E   pass...
 61s E  61s E ...Full output truncated (7 lines hidden), use 
'-vv' to show
 61s ___ test_basic_class 
___

 61s tests/test_generator_dataclass2.py:34: in test_basic_class
 61s validate_code(
 61s tests/conftest.py:38: in validate_code
 61s assert generated_code == expected_code
 61s E   AssertionError: assert 'from sqlalch...String(20))\n' == 'from 
typing ...String(20))\n'

 61s E  61s E - from typing import Optional
 61s E -  61s E   from sqlalchemy import Integer, String
 61s E   from sqlalchemy.orm import DeclarativeBase, Mapped, 
MappedAsDataclass, mapped_column

 61s E + from typing import Optional
 61s E   ...
 61s E  61s E ...Full output truncated (9 lines hidden), use 
'-vv' to show
 61s __ test_mandatory_field_last 
___

 61s tests/test_generator_dataclass2.py:65: in test_mandatory_field_last
 61s validate_code(
 61s tests/conftest.py:38: in validate_code
 61s assert generated_code == expected_code
 61s E   assert "from sqlalch...ext('foo'))\n" == "from typing 
...ext('foo'))\n"

 61s E  61s E - from typing import Optional
 61s E -  61s E   from sqlalchemy import Integer, String, text
 61s E   from sqlalchemy.orm import DeclarativeBase, Mapped, 
MappedAsDataclass, mapped_column

 61s E + from typing import Optional
 61s E   ...
 61s E  61s E ...Full output truncated (10 lines hidden), use 
'-vv' to show
 61s ___ test_onetomany_optional 


 61s tests/test_generator_dataclass2.py:103: in test_onetomany_optional
 61s validate_code(
 61s tests/conftest.py:38: in validate_code
 61s assert generated_code == expected_code
 61s E   assert "from sqlalch...ple_items')\n" == "from typing 
...ple_items')\n"

 61s E  61s E - from typing import List, Optional
 61s E -  61s E   from sqlalchemy import ForeignKey, Integer
 61s E   from sqlalchemy.orm import DeclarativeBase, Mapped, 

Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl

[Tj]

Source: debian-installer
Followup-For: Bug #1075713
X-Debbugs-Cc: tj.iam...@proton.me

I've done some further research via debian-installer repo, build logs,
and inspecting fb-modules-*-amd64-di packages.

Focusing on just 6.8.12-1 and 6.9.7-1 I cannot see any difference in the
ISO builds. That is, for both:

 * linux-image-*-amd64 does include drivers/gpu/drm/qxl/qxl.ko*
 * fb-modules-*-amd64-di.udeb does not
 * kernel-image-*-amd64-di does not
 * d-i Makefile's DRM_MODULES has/does not list/copy qxl.ko

This makes me wonder if the 20240628_0519 daily netinst really did have
this module but as I cannot find a copy of the ISO I cannot check.

If it did not then something must have changed in the qemu/kvm side.

I went on to analyse the ISO package content diff using the attached awk
script. It strips out packages where the only difference is the version
embedded in the package name. The resulting list does not appear to show
anything that would control inclusion of the qxl modulei although it
does seem to indicate a lot of churn:

apt-cdrom-setup -
apt-mirror-setup -
apt-setup-udeb -
base-installer -
bootstrap-base -
btrfs-modules amd64-di - -6.8.12-
btrfs-progs-udeb -
choose-mirror-bin -
clock-setup -
crypto-modules amd64-di - -6.8.12-
debian-archive-keyring-udeb -
debootstrap-udeb -
depthcharge-tools-installer -
di-utils-mapdevfs -
disk-detect -
dmidecode-udeb -
dosfstools-udeb -
e2fsprogs-udeb -
efi-modules amd64-di - -6.8.12-
eject-udeb -
ethdetect -
ext4-modules amd64-di - -6.8.12-
finish-install -
fuse3-udeb -
gpgv-udeb -
grub-installer -
grub-mount-udeb -
jfs-modules amd64-di - -6.8.12-
jfsutils-udeb -
kickseed-common -
libaio1-udeb -
libdevmapper1.02.1-udeb -
libfuse3 udeb - -3-
libgcrypt20-udeb -
libgpg-error0-udeb -
libinih1-udeb -
libisns-udeb -
libiw30-udeb -
liblzo2 udeb - -2-
libmount1-udeb -
libnl-3 udeb - -200-
libnl-genl-3 udeb - -200-
libparted-fs-resize0-udeb -
libparted2-udeb -
liburcu8-udeb -
loop-modules amd64-di - -6.8.12-
lvm2-udeb -
md-modules amd64-di - -6.8.12-
mdadm-udeb -
mtd-core-modules amd64-di - -6.8.12-
ndisc6-udeb -
netcfg -
network-preseed -
nic-modules amd64-di - -6.8.12-
nic-pcmcia-modules amd64-di - -6.8.12-
nic-shared-modules amd64-di - -6.8.12-
nic-usb-modules amd64-di - -6.8.12-
nic-wireless-modules amd64-di - -6.8.12-
nobootloader -
ntfs-3g-udeb -
open-iscsi-udeb -
os-prober-udeb -
partman-auto -
partman-auto-crypto -
partman-auto-lvm -
partman-auto-raid -
partman-base -
partman-basicfilesystems -
partman-basicmethods -
partman-btrfs -
partman-cros -
partman-crypto -
partman-efi -
partman-ext3 -
partman-iscsi -
partman-jfs -
partman-lvm -
partman-md -
partman-partitioning -
partman-target -
partman-utils -
partman-xfs -
pkgsel -
rdate-udeb -
rdnssd-udeb -
systemd-boot-installer -
tzsetup-udeb -
user-setup-udeb -
wide-dhcpv6-client-udeb -
wpasupplicant-udeb -
xfs-modules amd64-di - -6.8.12-
xfsprogs-udeb -
/^(\+|-)/ {
l[NR]=gensub( /^(.)([^\t ]+).*/, "\\2 \\1", "1", $0);
l[NR]=gensub( /^(.+?)(-([[:digit:]]|\.)+-)(.*)/, "\\1 \\4 \\2", "1", 
l[NR] );
}
END {
asort(l);
for(key in l) {
if(key>1) {
if( gensub(/^([^ ]+).*/, "\\1", "g", l[key-1]) == \
gensub(/^([^ ]+).*/, "\\1", "g", 
l[key]) ) {
delete l[key-1];
delete l[key];
}
}
}
for(key in l) {
if( length(l[key]) > 0)
print l[key]
}
}

Bug#1066662: hping3: FTBFS: script.c:1351:29: error: implicit declaration of function ‘asprintf’; did you mean ‘vsprintf’? [-Werror=implicit-function-declaration]

[Michael Prokop]

Hi,

* Michael Prokop [Mon May 06, 2024 at 11:16:47AM +0200]:
> * Lucas Nussbaum [Wed Mar 13, 2024 at 12:51:29PM +0100]:

> > This is most likely caused by a change in dpkg 1.22.6, that enabled
> > -Werror=implicit-function-declaration. For more information, see
> > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> > 
> > Relevant part (hopefully):
> > > gcc -c -g -O2 -Werror=implicit-function-declaration 
> > > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> > > -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -Wall -I/usr/include/pcap 
> > > -I/usr/include/tcl8.6 -DUSE_TCL -g  ars.c
> > > script.c: In function ‘HpingTcl_AppInit’:
> > > script.c:1351:29: error: implicit declaration of function ‘asprintf’; did 
> > > you mean ‘vsprintf’? [-Werror=implicit-function-declaration]
> > >  1351 | if (asprintf(&rcfile, "%s/.hpingrc", 
> > > home) < 0)
> > >   | ^~~~
> > >   | vsprintf
> [...]
> 
> Pending patch / MR available at> 
> https://salsa.debian.org/debian/hping3/-/merge_requests/4

Thanks Marcio de Souza Oliveira for merging
https://salsa.debian.org/debian/hping3/-/merge_requests/4!

Any chance you could take care of the according hping3 upload
towards unstable so we have a chance of getting it back into
Debian/testing and upcoming trixie stable release therefore?

regards
-mika-



signature.asc
Description: PGP signature

Bug#700055: Please support 1366x768 resolution

[Anton Shepelev]

The problem persists eleven years later. Please, add support to this
resolution.

Bug#1075727: lincity: Multi-lingual support is disfunctional

[Kari Pahula]

merge 1075727 1075728
tags 1075727 help confirmed
thanks

Unfortunately my answer's "patches welcome".

I'm keeping lincity in a shape where it builds and will provide simple
bugfixes but this would very likely require more than that.

Bug#1075747: curl: X.509 client certificates not working with curl/8.8.0-2

[Jan Schlien]

Package: curl
Version: 8.8.0-2
Severity: normal

/usr/bin/curl --cert  --key   no longer works with the version
mentioned above. It worked well with the previous version 8.8.0-1. The error
message is:

curl: (35) error reading X.509 key or certificate file

>From the changelog, this bullet point comes to mind:

* Switch curl package/binary to use gnutls, now with HTTP3 support

Looking at strace output, curl does read a lot of certs from /etc/ssl/certs/
(not shown) but it not attempt to read the path given with --cert. It reads the
--key file and then does a bogus sendmsg():

> openat(AT_FDCWD, "path_removed.key", O_RDONLY|O_CLOEXEC) = 6
> newfstatat(6, "", {st_mode=S_IFREG|0600, st_size=1854, ...}, AT_EMPTY_PATH) = > 0
> lseek(6, 0, SEEK_CUR) = 0
> read(6, "-BEGIN ENCRYPTED PRIVATE KEY"..., 1855) = 1854
> read(6, "", 1)   = 0
> close(6) = 0
> openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 6
> newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=2996, ...}, AT_EMPTY_PATH) = > 0
> read(6, "# Locale name alias data base.\n#"..., 4096) = 2996
> read(6, "", 4096) = 0
> close(6) = 0
> openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/gnutls30.mo", O_RDONLY) 
> = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/gnutls30.mo", O_RDONLY) = 
> -1 ENOENT (No such file or dir ectory)
> sendmsg(-1, {msg_name=NULL, msg_namelen=0, 
> msg_iov=[{iov_base="\25\3\3\0\2\1\0", iov_len=7}], msg_iovlen=1, 
> msg_controllen=0, msg_flags=0}, 0) = -1 EBADF (Bad file descriptor)
> close(5) = 0

After that, it prints the error message one character by one and exits. Let me
know if anything else is needed.

Thanks,
Jan



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

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

Versions of packages curl depends on:
ii  libc6   2.38-13
ii  libcurl3t64-gnutls  8.8.0-2
ii  zlib1g  1:1.3.dfsg+really1.3.1-1

curl recommends no packages.

curl suggests no packages.

-- no debconf information

Bug#700055: Please support 1366x768 resolution

[Michael Tokarev]

04.07.2024 11:43, Anton Shepelev wrote:

The problem persists eleven years later. Please, add support to this
resolution.


Patches welcome.  Adding another "me too" isn't exactly helpful.

/mjt

--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Bug#1074654: skimage: FTBFS: ModuleNotFoundError: No module named 'distutils'

[Ole Streicher]

Control: reassign -1 src:skimage 0.23.2-1

Sorry for disturbing; the problem here was a hotfix in d/rules

export SETUPTOOLS_USE_DISTUTILS=stdlib

that ensured working with older distutils version. This affected the 
pythran working. Without this environment variable, pythran works well.


Re-assigning back for a later closing.

Bug#1075743: RFS: uwsgi/2.0.26-1 -- fast, self-healing application container server

[Phil Wyett]

Control: tags -1 + moreinfo

Hi Alexandre,

Don't shoot the messenger. :-)

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Issue

W: uwsgi-plugin-jvm-openjdk-17: bad-jar-name [usr/share/java/uwsgi.jar]
N: 
N:   The package ships the specified "public" Jar file under /usr/share/java/,
N:   but the name does not correspond to Java policy guidelines. This can cause
N:   tools in the Debian Java toolchain to fail.
N: 
N:   Please refer to Java libraries (Section 2.4) in the Debian policy for Java
N:   and Bug#976681 for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: languages/java
N:
N:
W: uwsgi source: no-versioned-debhelper-prerequisite 10
N: 
N:   The package either doesn't declare a versioned build dependency on
N:   debhelper or does not declare a versioned build dependency on a new enough
N:   version of debhelper to satisfy the declared compatibility level.
N:   
N:   The required version of debhelper is not guaranteed to be satisfied in all
N:   supported releases of Debian and therefore this may lead to a build
N:   failure.
N:   
N:   The recommended practice is to always declare an explicit versioned
N:   dependency on debhelper equal to or greater than the compatibility level
N:   used by the package, even if the versioned dependency isn't strictly
N:   necessary. Having a versioned dependency also helps with backports to
N:   older releases and correct builds on partially updated systems.
N:   
N:   Packages not using an experimental or beta compatibility level may
N:   alternatively Build-Depend on the debhelper-compat virtual package, for
N:   example:
N:   
N:Build-Depends: debhelper-compat (= 13)
N:   
N:   Note if you are using a compat level marked as experimental (such as
N:   compat 12 in debhelper 11.4~) please explicitly override this tag.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: debhelper
N:   Renamed from: package-needs-versioned-debhelper-build-depends
N:   package-lacks-versioned-build-depends-on-debhelper
N: 
N:
W: libapache2-mod-ruwsgi: spelling-error-in-changelog independant independent
[usr/share/doc/libapache2-mod-ruwsgi/changelog.Debian.gz]
N: 
N:   Lintian found a spelling error in the latest entry of the Debian
N:   changelog. Lintian has a list of common misspellings that it looks for. It
N:   does not have a dictionary like a spelling checker does.
N:   
N:   When writing a changelog entry for a spelling fix that includes the
N:   misspelling, ensure the word "spelling" is on the same line as the
N:   misspelled word to avoid triggering this warning.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: debian/changelog
N: 
N:
W: libapache2-mod-ruwsgi: spelling-error-in-changelog uneeded unneeded 
[usr/share/doc/libapache2-
mod-ruwsgi/changelog.Debian.gz]
N:
W: libapache2-mod-ruwsgi-dbg: spelling-error-in-changelog independant 
independent
[usr/share/doc/libapache2-mod-ruwsgi-dbg/changelog.Debian.gz]
N:
W: libapache2-mod-ruwsgi-dbg: spelling-error-in-changelog uneeded unneeded
[usr/share/doc/libapache2-mod-ruwsgi-dbg/changelog.Debian.gz]
N:
W: libapache2-mod-uwsgi: spelling-error-in-changelog independant independent
[usr/share/doc/libapache2-mod-uwsgi/changelog.Debian.gz]
N:
W: libapache2-mod-uwsgi: spelling-error-in-changelog uneeded unneeded 
[usr/share/doc/libapache2-mod-
uwsgi/changelog.Debian.gz]
N:
W: libapache2-mod-uwsgi-dbg: spelling-error-in-changelog independant independent
[usr/share/doc/libapache2-mod-uwsgi-dbg/changelog.Debian.gz]
N:
W: libapache2-mod-uwsgi-dbg: spelling-error-in-changelog uneeded unneeded 
[usr/share/doc/libapache2-
mod-uwsgi-dbg/changelog.Debian.gz]
N:
W: python3-uwsgidecorators: spelling-error-in-changelog independant independent
[usr/share/doc/python3-uwsgidecorators/changelog.Debian.gz]
N:
W: python3-uwsgidecorators: spelling-error-in-changelog uneeded unneeded 
[usr/share/doc/python3-
uwsgidecorators/changelog.Debian.gz]
N:
W: uwsgi: spelling-error-in-changelog independant independent
[usr/share/doc/uwsgi/changelog.Debian.gz]
N:
W: uwsgi: spelling-error-in-changelog uneeded unneeded 
[usr/share/doc/uwsgi/changelog.Debian.gz]
N:
W: uwsgi-app-integration-plugins: spelling-error-in-changelog independant 
independent
[usr/share/doc/uwsgi-app-integration-plugins/changelog.Debian.gz]
N:
W: uwsgi-app-integration-plugins: spelling-error-in-changelog uneeded unneeded 
[usr/share/doc/uwsgi-
app-integration-plugins/changelog.Debian.gz]
N:
W: uwsgi-core: spelling-error-in-changelog independant independent 
[usr/share/doc/uwsgi-
core/changelog.Debian.gz]
N:
W: uwsgi-core: spelling-error-in-changelog uneeded unneeded 
[usr/share/doc

Bug#1075603: debugpy: incompatible with new pydevd

[Drew Parsons]

Source: debugpy
Followup-For: Bug #1075603


For what it's worth, two processes (-n2) failed.

=== FAILURES ===
_ tests/tests/test_timeline.py _
[gw0] linux -- Python 3.11.9 /usr/bin/python3.11
worker 'gw0' crashed while running 
'tests/tests/test_timeline.py::test_occurrences'

Bug#1075748: debianutils: installkernel(8) incorrectly named uncompressed Linux image for riscv64 as 'vmlinuz-...'

[WHR]

Package: debianutils
Version: 5.19
Severity: minor
X-Debbugs-Cc: w...@rivoreo.one

Hello.

The Debian-specific installkernel(8) script would install the new Linux image
under /boot/ with name begining with 'vmlinuz', despite the image is
compeltely uncompressed. The Linux riscv build system names uncompressed image
as 'Image', and gzip(1)-compressed image as 'Image.gz'; this can be seen in
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/riscv/Makefile?h=v6.6.36#n169
and
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/riscv/boot/install.sh?h=v6.6.36

By default, the build system will install the uncompressed image (Image) using
installkernel(8). The installed file should be named as 'vmlinux-...' instead.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: riscv64

Kernel: Linux 6.1.83-rivoreo-starfive (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_TW:zh_CN:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debianutils depends on:
ii  libc6  2.38-13

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

Bug#1075749: xonsh: new upstream version 0.17

[Ritesh Raj Sarraf]

Package: xonsh
Version: 0.15.1+dfsg-1
Severity: wishlist
X-Debbugs-Cc: ritesh.sar...@collabora.com

Thank you for maintaining Xonsh in Debian. This bug report is just a
request to update it to the latest version, which today stands at 0.17


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages xonsh depends on:
ii  python3  3.12.2-1
ii  python3-ply [python3-ply-yacc-3.10]  3.11-6

Versions of packages xonsh recommends:
ii  python3-prompt-toolkit  3.0.47-1
ii  python3-pygments2.18.0+dfsg-1
ii  python3-setproctitle1.3.3-1+b2

Versions of packages xonsh suggests:
ii  python3-pyperclip  1.8.2-2
ii  xonsh-doc  0.15.1+dfsg-1

-- no debconf information

Bug#1075747: curl: X.509 client certificates not working with curl/8.8.0-2

[Daniel Stenberg]

On Thu, 4 Jul 2024, Jan Schlien wrote:

curl upstream has fixed a few x509asn.1 bugs since 8.8.0 that will be included 
in the pending 8.9.0 release that ships in three weeks.


I believe this specific bug is fixed by this commit:

 https://github.com/curl/curl/commit/9aa1d412b814a40868558da51a6ab28ce1384a58

 / Daniel


Package: curl
Version: 8.8.0-2
Severity: normal

/usr/bin/curl --cert  --key   no longer works with the version
mentioned above. It worked well with the previous version 8.8.0-1. The error
message is:

   curl: (35) error reading X.509 key or certificate file

From the changelog, this bullet point comes to mind:

   * Switch curl package/binary to use gnutls, now with HTTP3 support

Looking at strace output, curl does read a lot of certs from /etc/ssl/certs/
(not shown) but it not attempt to read the path given with --cert. It reads the
--key file and then does a bogus sendmsg():


openat(AT_FDCWD, "path_removed.key", O_RDONLY|O_CLOEXEC) = 6
newfstatat(6, "", {st_mode=S_IFREG|0600, st_size=1854, ...}, AT_EMPTY_PATH) = 0
lseek(6, 0, SEEK_CUR) = 0
read(6, "-BEGIN ENCRYPTED PRIVATE KEY"..., 1855) = 1854
read(6, "", 1)   = 0
close(6) = 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 6
newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=2996, ...}, AT_EMPTY_PATH) = 0
read(6, "# Locale name alias data base.\n#"..., 4096) = 2996
read(6, "", 4096) = 0
close(6) = 0
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/gnutls30.mo", O_RDONLY) = 
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/gnutls30.mo", O_RDONLY) = -1 
ENOENT (No such file or dir ectory)
sendmsg(-1, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\25\3\3\0\2\1\0", iov_len=7}], msg_iovlen=1, 
msg_controllen=0, msg_flags=0}, 0) = -1 EBADF (Bad file descriptor)
close(5) = 0


After that, it prints the error message one character by one and exits. Let me
know if anything else is needed.

Thanks,
Jan



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

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

Versions of packages curl depends on:
ii  libc6   2.38-13
ii  libcurl3t64-gnutls  8.8.0-2
ii  zlib1g  1:1.3.dfsg+really1.3.1-1

curl recommends no packages.

curl suggests no packages.

-- no debconf information




--

 / daniel.haxx.se

Bug#1069210: dh-elpa: Support nested directory in elpa installation

[Xiyue Deng]

Hi Sean,

Sean Whitton  writes:

> Hello,
>
> Sorry to keep asking for these minor changes, but it does help me
> understand the change better.
>
> Why can't you just use debian/install to install the .nosearch?  Are you
> trying to avoid creating an empty .nosearch in the source package, or is
> there some other reason?

Actually that's pretty much it.  And now I realize there is a downside
of using a custom command to create those empty files during install: I
forgot to implement the clean-up logic.  So to make things simple I now
just put those two files in the source and install them using d/install
in [1].  Please see updated full diff in [2] and attached.

[1] 
https://salsa.debian.org/manphiz/dh-elpa/-/commit/7e2bad6bf74d91f9cd876a4620796fe4eb5f3514
[2] 
https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...nested-directory-support?from_project_id=18920

-- 
Xiyue Deng
From 7e2bad6bf74d91f9cd876a4620796fe4eb5f3514 Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Thu, 4 Jul 2024 02:16:52 -0700
Subject: [PATCH 1/4] Don't recursively add elpa path to match package.el
 behavior

* Add .nosearch to `/usr/share/emacs/site-lisp/elpa{,-src}' using
triggers in dh-elpa, which will disable subdirs.el from processing
those directories.
---
 debian/install | 2 ++
 elpa-src/.nosearch | 0
 elpa/.nosearch | 0
 3 files changed, 2 insertions(+)
 create mode 100644 elpa-src/.nosearch
 create mode 100644 elpa/.nosearch

diff --git a/debian/install b/debian/install
index d6e2470..64fc1fc 100644
--- a/debian/install
+++ b/debian/install
@@ -2,3 +2,5 @@ elpa.pm usr/share/perl5/Debian/Debhelper/Sequence
 emacsen-common usr/share/debhelper/dh_elpa
 autoscripts/prerm-elpa usr/share/debhelper/autoscripts
 usr/bin
+elpa/.nosearch usr/share/emacs/site-lisp/elpa
+elpa-src/.nosearch usr/share/emacs/site-lisp/elpa-src
diff --git a/elpa-src/.nosearch b/elpa-src/.nosearch
new file mode 100644
index 000..e69de29
diff --git a/elpa/.nosearch b/elpa/.nosearch
new file mode 100644
index 000..e69de29
-- 
2.39.2

From b8e71ae56587bbc8ba069b66a882fd7862c25c0a Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Mon, 15 Apr 2024 13:03:16 -0700
Subject: [PATCH 2/4] Byte compile recursively during install to handle nested
 directories

* This handles addons that have source files under nested directories
in ELPA install directories.
---
 helper/install | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/helper/install b/helper/install
index 39db695..eb68ef5 100755
--- a/helper/install
+++ b/helper/install
@@ -58,7 +58,8 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}"
  ${FLAVOR} --quick --batch -l package \
--eval "(setq package-user-dir \"/nonexistent\")" \
--eval "(add-to-list 'package-directory-list \"$src_dir\")" \
-   -f package-initialize -f batch-byte-compile ./*.el > Install.log 2>&1
+   -f package-initialize \
+   --eval "(byte-recompile-directory \".\" 0)" > Install.log 2>&1
  if test $? -ne 0
  then
cat Install.log
-- 
2.39.2

From e68c5e9d4b6cf0509afc402b71464c6dda273fdb Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Wed, 17 Apr 2024 14:06:42 -0700
Subject: [PATCH 3/4] Create symlink from elpa-src to elpa recursively

* Instead of using `ln -s', use `cp -rs' so that directories are
handled recursively.
* In remove we use `rmdir --ignore-fail-on-non-empty' so this was
handled automatically as well.
---
 helper/install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/helper/install b/helper/install
index eb68ef5..8d748c8 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}" && cp -rsf "${el_dir}"* .)
 
 # Byte compile them
 (cd "${elc_dir}"
-- 
2.39.2

From 0a57ca5d4456ed1a41f0646e2ae4ac9fa486a8b8 Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Wed, 17 Apr 2024 14:17:41 -0700
Subject: [PATCH 4/4] Update d/changelog

---
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index c6211de..4b91ec7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -9,6 +9,12 @@ dh-elpa (2.1.2) UNRELEASED; urgency=medium
   * dh_elpa_test: Don't rename files under test/, tests/ (Closes:
 #1069326).
   * Use `pretty' stack frame style in buttercup for full back trace.
+  * Add support for nested directory in elpa installation (Closes:
+#1069210).
+- Don't recursively add elpa path to match package.el behavior.
+- Byte compile recursively during install to handle nested
+  directories.
+- Create symlink from elpa-src to elpa recursively.
 
   [ Aymeric Agon-Rambosson ]
   * Get Package-Requires with lm-header-multiline (some upstream

Bug#1075748: Patch

[WHR]

Control: tags 1075748 + patch

This patch makes installkernel(8) additionally recognizing 'Image' as a name
for uncompressed image file.
--- installkernel.orig	2024-06-09 15:25:40.0 +0800
+++ installkernel	2024-07-04 17:22:48.201433536 +0800
@@ -63,11 +63,14 @@
   fi
 }
 
-if [ "$(basename $img)" = "vmlinux" ] ; then
-  img_dest=vmlinux
-else
-  img_dest=vmlinuz
-fi
+case "$(basename $img)" in
+  "vmlinux"|"Image")
+img_dest=vmlinux
+;;
+  *)
+img_dest=vmlinuz
+;;
+esac
 updatever $img_dest "$img"
 updatever System.map "$map"
 

Bug#1075751: ITP: rust-arboard -- clipboard crate with image support

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org, 
werdah...@riseup.net
Control: block 1051528 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: rust-arboard
  Version : 3.2.0
  Upstream Contact: Artur Kovacs 
* URL : https://github.com/1Password/arboard
* License : MIT/Apache 2.0
  Programming Lang: Rust
  Description : clipboard crate with image support

arboard is a rust clipboard crate with needed as dependency for
magic-wormhole. 

best,

werdahias

-BEGIN PGP SIGNATURE-

iIsEARYIADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCZoZu+xUcd2VyZGFoaWFz
QHJpc2V1cC5uZXQACgkQ7L7btge5sr6rWQEAqZcNkHrpJxuefCT35amDanTGFx1X
SpY2rLZDj/WWNB4A/igGoc643PSMaA4uo/BDefj0+EHxFtn1fdfe+zOUwkQK
=ZuEU
-END PGP SIGNATURE-

Bug#1069365: dietlibc: FTBFS on arm64: E: Build killed with signal TERM after 150 minutes of inactivity

[Thorsten Glaser]

tags 1069365 + confirmed pending
thanks

Lucas Nussbaum dixit:

>> E: Build killed with signal TERM after 150 minutes of inactivity

Indeed, it busy-spins in diet(1):

include/sys/cdefs.h:#define __likely(foo) __expect((foo),1)

29  size_t strlen(const char *s)
30  {
42  register size_t i;
43  for (i=0; __likely(*s); ++s) ++i;
44  return i;

So, something miscompiles this.

While I don’t speak arm64 assembly, my best guess is…

Dump of assembler code for function strlen:
   0x00401800 <+0>: bti c
   0x00401804 <+4>: adrpx1, 0x41 
   0x00401808 <+8>: mov x3, x0
   0x0040180c <+12>:mov x2, x0
   0x00401810 <+16>:ldr w1, [x1, #776]
   0x00401814 <+20>:cbz w1, 0x401830 
   0x00401818 <+24>:b   0x401800 

… that GCC optimises the for loop into a call to strlen,
for which I have multiple ideas.

Thanks,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#1043530: Please ship uasyncio and mip

[Stefane Fermigier]

Package: micropython
Version: 1.22.1+ds-1build2
Followup-For: Bug #1043530

Dear Maintainer,

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


root@trunks3:~# /usr/bin/micropython
MicroPython v1.22.1+ds-1build2 on 2024-04-01; linux [GCC 13.2.0] version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import mip
Traceback (most recent call last):
  File "", line 1, in 
ImportError: no module named 'mip'
>>>

   * What outcome did you expect instead?

I was hoping to be able to use mip.


-- System Information:
Debian Release: trixie/sid
  APT prefers noble-updates
  APT policy: (500, 'noble-updates'), (500, 'noble-security'), (500, 'noble'), 
(100, 'noble-backports')
Architecture: amd64 (x86_64)

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

Versions of packages micropython depends on:
ii  libc6  2.39-0ubuntu8.2
ii  libffi83.4.6-1build1
ii  libmbedcrypto7t64  2.28.8-1
ii  libmbedtls14t642.28.8-1
ii  libmbedx509-1t64   2.28.8-1

micropython recommends no packages.

Versions of packages micropython suggests:
ii  default-jre-headless  2:1.21-75+exp1

-- no debconf information

Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl

[Philip Hands]

Tj  writes:

> Source: debian-installer
> Followup-For: Bug #1075713
> X-Debbugs-Cc: tj.iam...@proton.me
>
> I've done some further research via debian-installer repo, build logs,
> and inspecting fb-modules-*-amd64-di packages.

Thanks :-)

> Focusing on just 6.8.12-1 and 6.9.7-1 I cannot see any difference in the
> ISO builds. That is, for both:
>
>  * linux-image-*-amd64 does include drivers/gpu/drm/qxl/qxl.ko*
>  * fb-modules-*-amd64-di.udeb does not
>  * kernel-image-*-amd64-di does not
>  * d-i Makefile's DRM_MODULES has/does not list/copy qxl.ko
>
> This makes me wonder if the 20240628_0519 daily netinst really did have
> this module but as I cannot find a copy of the ISO I cannot check.

openQA keeps copies for a while (and that is what date-stamps them, as
the filenames are static[1]):

  
https://openqa.debian.net/tests/277189/asset/iso/20240628_0519-debian-testing-amd64-netinst.iso

> If it did not then something must have changed in the qemu/kvm side.

Looking at this again:
  https://openqa.debian.net/tests/278609#investigation
I realise that it's got a "Show more" thing in the
diff_packages_to_last_good which I'd not noticed earlier. :-/

I _had_ thought that it was just a few apt & autoconf tools that had
changed, but actually there's loads of things, including qemu.

Looking at the etckeeper log on the worker, I see that there was an
upgrade from qemu 1:7.2+dfsg-7+deb12u5 to 1:7.2+dfsg-7+deb12u at
2024-06-29 11:12:50, which is just after the last succesful run, so that
does point towards qemu being the problem.

This afternoon I may have time to check if I can demonstrate that this
is actually a regression in qemu, and will reasign the bug if so (I
don't mind at all if someone else does that test for me :-) )

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Luca Boccassi]

On Wed, 03 Jul 2024 23:10:30 +0100 Luca Boccassi 
wrote:
> On Wed, 03 Jul 2024 22:58:33 +0100 Luca Boccassi 
> wrote:
> > On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl 
> > wrote:
> > > Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > > > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > > > 
> > > > connect(5, {sa_family=AF_UNIX,
> > sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
> > ECONNREFUSED (Connection refused)
> > > > 
> > > >> systemd should be listening on this socket
> > > > 
> > > > Well, on no less than four different Debian machines, it does
> not.
> > > > 
> > > >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> > > >> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE
> NAME
> > > >> systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
> > > >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM
(LISTEN)
> > > > 
> > > > Isn't that on a machine where systemd-userdb is installed
maybe?
> > The
> > > > installation of that package triggers the systemd binary to
> listen?
> > > 
> > > No, systemd-userdb is not installed and as you can see from the
> above
> > > output it's actually systemd which listens on that socket.
> > 
> > I can reproduce it by mounting a tmpfs on /run/systemd/userdb/
_and_
> > creating an empty io.systemd.DynamicUser file on it. Maybe it
should
> > not abort like that, however, if you have the directory in /run/
> _and_
> > the socket file exists _but_ nothing is listening on it, then your
> > machine is broken in some way. If the directory/socket are missing
> they
> > are just skipped gracefully.
> 
> I'm not sure what's the alternative here - if consulting NSS fails
for
> some local reasons because the machine is broken/misconfigured, I am
> not sure if it should just ignore it and continue it. If NSS is
> configured and is supposed to work, but doesn't for some
> temporary/local reason, you might end up creating a duplicated
> user/group, and I am not really sure that's better than bailing out
> without touching anything.

Consensus seems to be that in this bad situation it's slightly better
to complain loudly and continue, so the next point release will contain
a fix to this effect. You should still figure out how you ended up with
a dead af_unix socket in the first place, as that's a sign of something
seriously wrong on that machine.

-- 
Kind regards,
Luca Boccassi


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

Bug#1075752: net-tools: Enable autopkgtest for net-tools

[Adithya.Balakumar]

Package: net-tools
Version: 2.10-0.1
Severity: wishlist

Dear Maintainer,

Currently the net-tools package in Debian does not have autopkgtests running in 
Debian CI. However, I noticed that the net-tools package in ubuntu has 
autopkgtests defined.
Is it possible to also include autopkgtests for net-tools in Debian as well.

Autopkgtest in Ubuntu: 
https://git.launchpad.net/ubuntu/+source/net-tools/tree/debian/tests


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to 
default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_IN:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1075753: nm.debian.org: Replace .personbio jQuery toggle with native details and summary elements

[Blair Noctis]

Package: nm.debian.org
Severity: normal
X-Debbugs-Cc: n...@sail.ng

Dear Maintainer,

Currently, the "Short Biography" block on a person's NM page is an old-fashioned
jQuery 2-element toggle. This approach is unfriendly to selection, because when
you select some text with mouse, the element in which the selection resides is
hidden; even when it's back visible, the selection is lost.

It can be improved using the  and  elements, natively
supported since Firefox 49, Chrome 12, Safari 6, i.e. no compatibility issues.

I've proposed a merge request at
https://salsa.debian.org/nm-team/nm.debian.org/-/merge_requests/41.

It also helps to remove jQuery, although that requires another change to remove
the dropdown hover script.

-- 
Sdrager,
Blair Noctis

OpenPGP_0xC21D9AD423A39727.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075754: src:sbcl: fails to migrate to testing for too long: FTBFS on armel/armhf and autopkgtest issues on i386

[Paul Gevers]

Source: sbcl
Version: 2:2.3.7-2
Severity: serious
Control: close -1 2:2.4.5-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1069520

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:sbcl has been trying to migrate for 34 
days [2]. Hence, I am filing this bug. The package in unstable failed to 
build on armhf and armel, as reported in bug 1069520, and causes 
autopkggtest issues on i386 for 2 reverse (test) dependencies.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=sbcl



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl

[Cyril Brulebois]

Tj  (2024-07-04):
> Focusing on just 6.8.12-1 and 6.9.7-1 I cannot see any difference in the
> ISO builds. That is, for both:
> 
>  * linux-image-*-amd64 does include drivers/gpu/drm/qxl/qxl.ko*
>  * fb-modules-*-amd64-di.udeb does not
>  * kernel-image-*-amd64-di does not
>  * d-i Makefile's DRM_MODULES has/does not list/copy qxl.ko

The part I fixed yesterday only covers compressed modules that are
listed there, so that's indeed a no-op for qxl.

It just seems to me that, at least with qemu packages currently found in
Debian 12, earlier versions of the installer (based on 6.8.y) didn't
need that particular module to get X up and running, while newer
versions of the installer (based on 6.9.y) do. At least based on two
spot checks: one with the earliest version available, one with last
night's.

You can play with netboot/gtk/mini.iso under the following directory:
  https://d-i.debian.org/daily-images/amd64/

(Timestamped directories, time-limited, ~15 days.)

The 20240619-00:13 one boots X under -vga qxl just fine, but you might
want to double check its logs (X tries to autoload qxl but finds it
missing).

> I went on to analyse the ISO package content diff using the attached
> awk script. It strips out packages where the only difference is the
> version embedded in the package name. The resulting list does not
> appear to show anything that would control inclusion of the qxl
> modulei although it does seem to indicate a lot of churn:

The timestamped directories mentioned above include manifests which
makes it easy to diff things.

Since all you care about is the very beginning of the installation
process, you don't have to worry about kernel modules mismatch between
the kernel d-i was built against and what's in the archive at runtime,
so I'd suggest concentrating on netboot/gtk/mini.iso, that should make
it easier to pinpoint when the change exactly happened (than going
through probably much less frequent debian-cd-provided netinst images).


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


signature.asc
Description: PGP signature

Bug#1075755: leave: ftbfs due to 'don't have (pseudo-)root!'

[Bo YU]

Source: leave
Version: 1.12-5
Severity: serious
Tags: patch

leave has one ftbfs on all architectures:

```
...
Command: dpkg-buildpackage --sanitize-env -us -uc -mamd64 / i386 Build Daemon 
(x86-ubc-01)  -B -rfakeroot 
--changes-option=-O../leave_1.12-5_amd64-buildd.changes 
--buildinfo-option=-O../leave_1.12-5_amd64-buildd.buildinfo
dpkg-buildpackage: warning: passing -O via --changes-option is not supported; 
please use --changes-file instead
dpkg-buildpackage: warning: passing -O via --buildinfo-option is not supported; 
please use --buildinfo-file instead
dpkg-buildpackage: info: source package leave
dpkg-buildpackage: info: source version 1.12-5
dpkg-buildpackage: info: source distribution unstable
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
test -f leave.c || { echo not in the right dir\!; exit 1; }
test `id -u` -eq 0 || { echo "don't have (pseudo-)root!"; exit 1; }
don't have (pseudo-)root!
make: *** [debian/rules:22: clean] Error 1
```

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

I think the issue was raised by adding `Rules-Requires-Root: no` in
previous upload but checking the root env during build. I am not sure
why to check it so please double check it.


-- 
Regards,
--
  Bo YU

diff -Nru leave-1.12/debian/changelog leave-1.12/debian/changelog
--- leave-1.12/debian/changelog 2024-06-24 20:35:33.0 +0800
+++ leave-1.12/debian/changelog 2024-07-04 18:02:43.0 +0800
@@ -1,3 +1,10 @@
+leave (1.12-6) UNRELEASED; urgency=medium
+
+  * QA upload.
+  * Drop to check root uid when building. (Closes: #-1)
+
+ -- Bo YU   Thu, 04 Jul 2024 18:02:43 +0800
+
 leave (1.12-5) unstable; urgency=medium
 
   * QA upload.
diff -Nru leave-1.12/debian/rules leave-1.12/debian/rules
--- leave-1.12/debian/rules 2024-06-24 20:35:33.0 +0800
+++ leave-1.12/debian/rules 2024-07-04 18:02:43.0 +0800
@@ -19,12 +19,10 @@
 
 clean:
test -f leave.c || { echo not in the right dir\!; exit 1; }
-   test `id -u` -eq 0 || { echo "don't have (pseudo-)root!"; exit 1; }
rm -f build-stamp leave leave.o leave.cat1 debian/files debian/substvars
rm -rf $(tmp)
 
 binary-arch binary: build
-   test `id -u` -eq 0 || { echo "don't have (pseudo-)root!"; exit 1; }
rm -rf $(tmp)
install -d -m 755 $(tmp)/usr/bin $(tmp)/usr/share/man/man1 \
$(tmp)/DEBIAN $(tmp)/usr/share/doc/leave


signature.asc
Description: PGP signature

Bug#1074583: reported upstream too

[Sanjoy Mahajan]

I've also just reported this issue upstream, as it happens with the
latest upstream version.  Link to github issue:

https://github.com/getmail6/getmail6/issues/199

Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl

[Diederik de Haas]

On Thursday, 4 July 2024 13:19:59 CEST Cyril Brulebois wrote:
> It just seems to me that, at least with qemu packages currently found in
> Debian 12, earlier versions of the installer (based on 6.8.y) didn't
> need that particular module to get X up and running, while newer
> versions of the installer (based on 6.9.y) do. At least based on two
> spot checks: one with the earliest version available, one with last
> night's.

There have been commits in ``drivers/gpu/drm/qxl/`` merged in 6.9 (and fwiw 
also in 6.10), so it's possible that plays a factor as well.

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

Bug#1075756: postfix-lmdb: lmdb map module left unloaded after package update, leaving Postfix non-functional.

[Pierre-Francois CARPENTIER]

Package: postfix-lmdb
Version: 3.7.11-0+deb12u1
Severity: important
X-Debbugs-Cc: carpe...@adobe.com

During upgrades of postfix-lmdb, lmdb map module is removed
from /etc/postfix/dynamicmaps.cf by postfix-lmdb.prerm (delmap lmdb).

This removal is taken into account immediately by postfix, and is visible
in logs such as:
postfix/cleanup[3005561]: warning: lmdb:/etc/postfix/vdomains is unavailable. 
unsupported dictionary type: lmdb

It's then re-added in dynamicmaps.cf by postfix-lmdb.postinst. But this
doesn't trigger a module reload, leaving Postfix in a potentially broken
state.

Manually removing & re-adding the line in /etc/postfix/dynamicmaps.cf
also simulates the issue.

To be fair, Postfix automatically unloading but not reloading the map
module seems like an upstream bug. But even if reloading happened, this
would leave Postfix broken during the update. Could we simply not touch
dynamicmaps.cf during upgrades?

Note: 
* if may affect other map modules (ex: postfix-cdb)
* the bug look similar to: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865005

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

Kernel: Linux 6.1.0-10-cloud-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 postfix-lmdb depends on:
ii  libc6 2.36-9+deb12u7
ii  liblmdb0  0.9.24-1
ii  postfix   3.7.11-0+deb12u1

postfix-lmdb recommends no packages.

postfix-lmdb suggests no packages.

-- no debconf information

Bug#1075757: elogind’s conflict with libelogind0 precludes upgrade

[Benjamin Cama]

Package: elogind
Version: 246.10-1debian1
Severity: important

Dear Maintainer,

I tried to upgrade to the latest 255 version of elogind, but I do not 
understand the recent "Conflicts" addition with libelogind0: it renders 
it uninstallable together with latest libelogind0, and thus ask me to 
install libsystemd instead, which I do not want.

>From what I understand, dependency to libelogind0 has been dropped 
because it actually provides exactly the libsystemd ABI now, so elogind 
now depends on just libsystemd. But the addition of the "Conflicts" with 
libelogind0 makes its use as a libsystemd substitute impossible. What 
gives?

Maybe I have gotten something wrong, please tell me if so. Attached is 
my upgrade attempt (not a full/dist-upgrade) for just elogind *with* 
libelogind0 to nail the problem down; this is the output of:

  apt-get install elogind libsystemd0+ 

This issue first appeared when installing/upgrading *any* package, where 
apt wanted to install systemd on my system, because of some reverse 
dependency I suppose.

Thanks for your support of this nice alternative software BTW.

Regards.
-- Benjamin

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

Kernel: Linux 6.5.0-3-amd64 (SMP w/23 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages elogind depends on:
ii  dbus   1.14.10-4+b1
ii  debconf1.5.86
ii  init-system-helpers1.66
ii  libacl12.3.2-2
ii  libc6  2.38-13
ii  libcap21:2.66-5
ii  libelogind0246.10-1debian1
ii  libpam0g   1.5.3-7
ii  libselinux13.5-2+b2
ii  libudev1   256.1-2
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.09-2

Versions of packages elogind recommends:
ii  libpam-elogind  246.10-1debian1
pn  polkitd 

elogind suggests no packages.

-- no debconf information
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 elogind : Conflicts: libelogind0 but 255.5-1debian2 is to be installed
   Recommends: polkitd
E: Unable to correct problems, you have held broken packages.

Bug#1075758: libvirt: enable support for loongarch64

[zhangdandan]

Source: libvirt
Version: 10.4.0-1
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The libvirt source package lacks LoongArch architecture support.
We need to enable support for loongarch64 in d/{arches.mk, control}.

Please consider the patch I have attached.
And the libvirt 10.4.0-1 source package was compiled successfully on my 
local loong64 rootfs environment.

```
..
  dh_builddeb -O--builddirectory=/home/libvirt/libvirt-10.4.0/debian/build
dpkg-deb: building package 'libvirt-clients' in 
'../libvirt-clients_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-clients-qemu' in 
'../libvirt-clients-qemu_10.4.0-1_all.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-qemu-dbgsym' in 
'../libvirt-daemon-driver-qemu-dbgsym_10.4.0-1_loong64dpkg-deb: building 
package 'libvirt-daemon-dbgsym' in 
'../libvirt-daemon-dbgsym_10.4.0-1_loong64.deb'.

.deb'.
dpkg-deb: building package 'libvirt-login-shell-dbgsym' in 
'../libvirt-login-shell-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 
'libvirt-daemon-driver-storage-gluster-dbgsym' in 
'../libvirt-daemon-driver-storage-gluster-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-lxc-dbgsym' in 
'../libvirt-daemon-driver-lxc-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 
'libvirt-daemon-driver-storage-iscsi-direct-dbgsym' in 
'../libvirt-daemon-driver-storage-iscsi-direct-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-storage-rbd-dbgsym' in 
'../libvirt-daemon-driver-storage-rbd-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-storage-zfs-dbgsym' in 
'../libvirt-daemon-driver-storage-zfs-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-config-network' in 
'../libvirt-daemon-config-network_10.4.0-1_all.deb'.
dpkg-deb: building package 'libvirt-daemon-system-systemd' in 
'../libvirt-daemon-system-systemd_10.4.0-1_all.deb'.
dpkg-deb: building package 'libvirt-dev' in 
'../libvirt-dev_10.4.0-1_loong64.deb'.

dpkg-deb: building package 'libvirt0' in '../libvirt0_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-l10n' in 
'../libvirt-l10n_10.4.0-1_all.deb'.
dpkg-deb: building package 'libvirt-wireshark-dbgsym' in 
'../libvirt-wireshark-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-sanlock-dbgsym' in 
'../libvirt-sanlock-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libnss-libvirt-dbgsym' in 
'../libnss-libvirt-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-system-sysv' in 
'../libvirt-daemon-system-sysv_10.4.0-1_all.deb'.
dpkg-deb: building package 'libvirt-daemon' in 
'../libvirt-daemon_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-storage-rbd' in 
'../libvirt-daemon-driver-storage-rbd_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-storage-iscsi-direct' 
in '../libvirt-daemon-driver-storage-iscsi-direcdpkg-deb: building 
package 'libvirt-daemon-config-nwfilter' in 
'../libvirt-daemon-config-nwfilter_10.4.0-1_all.deb'.
dpkg-deb: building package 'libvirt-login-shell' in 
'../libvirt-login-shell_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libnss-libvirt' in 
'../libnss-libvirt_10.4.0-1_loong64.deb'.

..
dpkg-deb: building package 'libvirt-daemon-system' in 
'../libvirt-daemon-system_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-storage-zfs' in 
'../libvirt-daemon-driver-storage-zfs_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-wireshark' in 
'../libvirt-wireshark_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-storage-gluster' in 
'../libvirt-daemon-driver-storage-gluster_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-clients-dbgsym' in 
'../libvirt-clients-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-sanlock' in 
'../libvirt-sanlock_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-lxc' in 
'../libvirt-daemon-driver-lxc_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-daemon-driver-qemu' in 
'../libvirt-daemon-driver-qemu_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt0-dbgsym' in 
'../libvirt0-dbgsym_10.4.0-1_loong64.deb'.
dpkg-deb: building package 'libvirt-doc' in 
'../libvirt-doc_10.4.0-1_all.deb'.

 dpkg-genbuildinfo -O../libvirt_10.4.0-1_loong64.buildinfo
 dpkg-genchanges -O../libvirt_10.4.0-1_loong64.changes

```

Would it be possible to include the support for LoongArch in the next 
upload?

If you have any questions, you can contact me at any time.

thanks
Dandan Zhang

diff -Nru libvirt-10.4.0/debian/arches.mk libvirt-10.4.0/debian/arches.mk
--- libvirt-10.4.0/debian/arches.mk 2024-06-03 22:19:48.0 +
+++ libvirt-10.4.0/debian/arches.mk 2024-06-03 22:19:48.0 +
@@ -1,7 +1,7 @@
-ARCHES_CEPH = amd64 arm64 mips64el ppc64el riscv64 s390x
-ARCHES_GLUSTER = amd

Bug#1075755: leave: ftbfs due to 'don't have (pseudo-)root!'

[Santiago Vila]

El 4/7/24 a las 13:25, Bo YU escribió:

I think the issue was raised by adding `Rules-Requires-Root: no` in
previous upload but checking the root env during build. I am not sure
why to check it so please double check it.


Yes, that was the thing that triggered this problem.

In this case, this package does not use debhelper at all, so in addition
to dropping the root tests in your proposed patch, the trick is to remove
also the chown line from debian/rules and use dpkg-deb --root-owner-group.

Since the package is orphaned, I've made a QA upload to fix this.

(I've also removed the line saying "test -f leave.c" which
I consider noise and unnecessary, it would disappear anyway
when somebody takes the work of really switching to dh).

[ Cc: Manoel Ibere. Please always verify that the package may be
built before uploading ].

Thanks.

Bug#1057255: memkind: add build support for loongarch64

[zhangdandan]

Hi maintainers,

On Sat, 2 Dec 2023 16:49:21 +0800 zhangdandan wrote:

> Source: memkind
> Version: 1.14.0-3
> Severity: wishlist
> Tags: patch
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
>
> Dear maintainers,
>
> The memkind source package lacks LoongArch architecture support.
> We need to add build support for loongarch64 in d/control.
>
> Please consider the patch I have attached.

Please enable build for loongarch64.
Base on the attached patch, I have built memkind successfully on my 
local env.

Could you add loongarch64 support in the next upload?
Any questions, you can contact me at any time.

Sincerely
Dandan

Bug#1075759: isa-support: please add armv8 + crc support package

[Luca Boccassi]

Source: isa-support
Severity: wishlist
X-Debbugs-Cc: pkg-dpdk-de...@lists.alioth.debian.org

Dear Maintainer(s),

For src:dpdk we would like to depend on a higher arm64 baseline, which
includes the crc extension. Would it be possible to add a new package
that matches it?

For reference, we compile with: -march=armv8-a+crc

https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html

Thank you!

-- 
Kind regards,
Luca Boccassi


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

Bug#1071355: In how far are several packages affected by bug #1071355 of maptools

[Joost van Baal-Ilić]

Hi Andreas,

On Thu, Jul 04, 2024 at 07:56:40AM +0200, Andreas Tille wrote:
> 
> there was a series of testing removals due to bug #1071355 of
> r-cran-maptools.  Since maptools was removed from CRAN[1] we intend to
> remove this package.  However, before doing so I would like to
> understand why packages like r-cran-factominer, r-cran-ggpubr,
> r-cran-vim, r-cran-systemfit, r-cran-survminer and others where I can't
> see any connection to r-cran-maptools were removed from testing.

I _think_ it's something like this:

r-cran-ggpubr depends r-cran-rstatix depends r-cran-car depends r-cran-maptools 
.
Therefore a #1071355 in r-cran-maptools which is serious and tagged ftbfs
causes r-cran-ggpubr to get removed.

Bye,

Joost

PS: tnx "apt-rdepends r-cran-ggpubr"

Bug#1075760: hplip-gui breaks with python 3.12

[Adilson dos Santos Dantas]

Package: hplip-gui
Version: 3.22.10+dfsg0-5
Severity: normal

Dear Maintainer,

Updating hplip with the last version from sid pulls python 3.12 as default
python3 version

Then it's breaks hplip leading some messages like this below:

hp-toolbox
Traceback (most recent call last):
 File "/usr/bin/hp-toolbox", line 38, in 
   from base.g import *
 File "/usr/share/hplip/base/g.py", line 239, in 
   sys_conf = SysConfig()
  ^^^
 File "/usr/share/hplip/base/g.py", line 184, in __init__
   ConfigBase.__init__(self, '/etc/hp/hplip.conf')
 File "/usr/share/hplip/base/g.py", line 89, in __init__
   self.read()
 File "/usr/share/hplip/base/g.py", line 130, in read
   self.conf.readfp(fp)
   
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you
mean: '
read'?

Reverting back to the testing version fix these errors since it reverts
python3 package to 3.11.

Probably it is related to this Arch Linux forum report:

https://bbs.archlinux.org/viewtopic.php?id=295303



-- Package-specific info:

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

Kernel: Linux 6.9.7 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:p
t:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hplip-gui depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
ii  dbus-x11 [dbus-session-bus]   1.14.10-4+b1
ii  hplip 3.22.10+dfsg0-5+b1
ii  python3-dbus.mainloop.pyqt5   5.15.10+dfsg-1+b3
ii  python3-pyqt5 5.15.10+dfsg-1+b3

Versions of packages hplip-gui recommends:
ii  python3-notify2  0.3-5
ii  xsane0.999-12+b2

hplip-gui suggests no packages.

-- no debconf information

-- 
Adilson dos Santos Dantas
http://www.adilson.net.br
http://twitter.com/adilsond

Bug#1060121: mdadm: Value "XXXXX:0" cannot be set as name. Reason: Not POSIX compatible. Value ignored.

[Bogdan Voaidas]

I have the same error.
2 identical servers with the same os and configuration but one has
mdadm - v4.2 - 2021-12-30 - 14 which gives this error
the other
mdadm - v4.2 - 2021-12-30 - 8 doesn't give this error

Bug#1075761: Desktop icon not displayed

[asciiwolf]

Package: lazarus
Version: 3.0+dfsg1-8

This happens in GNOME, but will probably also happen in other desktop 
environments. The desktop entry of Lazarus (3.0) has empty icon displayed 
instead of the actual Lazarus icon. This is caused by the "Icon=lazarus-3.0" 
entry (icon name). The problem is caused by the dot ("3.0") in the icon name, 
probably because it usually indicates the file type suffix. Everything works 
fine when I rename the icon to "lazarus-30" or "lazarus".

Bug#1074775:

[Andreas Hasenack]

I have a salsa branch, including a DEP8 test to exercise the new
includedir functionality. I'll propose it soon, I think there is one
or two extra commits from upstream we would want.

Bug#1075743: RFS: uwsgi/2.0.26-1 -- fast, self-healing application container server

[Alexandre Rossi]

Hi,

> A. piuparts problem

[...]

>   The following packages have unmet dependencies:
>libapache2-mod-ruwsgi : Conflicts: libapache2-mod-uwsgi but 2.0.26-1 is to 
> be installed
>libapache2-mod-uwsgi : Conflicts: libapache2-mod-ruwsgi but 2.0.26-1 is to 
> be installed
>   E: Unable to correct problems, you have held broken packages.

This is actually wanted, to modules actually conflict because they use the
same apache2 configuration variables.

Thanks,

Alex

Bug#1074498: RFS: baby/1.0.29-1 [ITP] -- Abbreviate long commands in terminal

[Manuel Guerra]

Hi Phill

Thank you for your valuable volunteer effort.
Based on the error detected, I have made the corresponding corrections, 
particularly in the management of the cache during construction. 
However, I must get to work regarding recommendations [2 to 7] and [a to i].


Source of the package:

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

El 4/7/24 a las 02:25, Phil Wyett escribió:

failed to initialize build cache at/sbuild-nonexistent/.cache/go-build: mkdir 
/sbuild-nonexistent:
permission denied
make[1]: *** [debian/rules:8: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Best regards,

Manuel Guerra-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGZ/ZOUBEADfUBppf12ZZ5l5KKSYeCIFyfukEzhvuhPeZmH5svAIDPng16nd
ADDq9F5zXYRV4ikgreioVTdTgBLyaHGv5zVDA2rpCX6PfMLNGFiT1mV9tH3y1skk
hKZVRkqlODJfc0o8yvbHIS0a60jEO4glpz/f7tqIw/4oKIuUSEKwkxww4S/JwLoD
xrhIFi+SNqYObfa0SzyHcY6IHQFP1/lLmBOGgDGzW837IeWW/9qTwL64iL1vmO0L
FcXrzUHLpiapOtnjHp1NGQBXE/NIZh77x1CcAYFZ4nuDLkTDBa8HnkmOOBFOYqqR
r4mV4clYI3Uy89cjbYg7TMPotu9dPxDd0gY8y/BbCnu45Oj4UfB3xWlygLkjuIhw
/XrBkeAf6dPLagXgcJjpBG9+Bb3qOTJsYSd1DfzvYkOG5k9Nt/60U7nyE092GKED
vuZ6GekuyRz8sKhYugcCobA5jL0GQPLfw1tS1EySTlASA4TWhQR5xnTJrSX4mo7E
yeEU929clLAkP7faimqbUprjLPUmO5+VMQWOzieA/i+ZgXz6BWWFvjTsT/9ToxWo
QMSHVfVRjOk8Tpa4ucRMfm49ZJEiZxlo13j4Fa41WDFrqT7Shuy3RnXGsGMD/1md
21BC4hy2hawsGlc3ZVNrHaCfCI8XA7fd/OLpx/qSGo47JkRk7IzjklfV/QARAQAB
tClNYW51ZWwgR3VlcnJhIDxhci5tYW51ZWxndWVycmFAZ21haWwuY29tPokCVAQT
AQoAPhYhBOylAW2WP4ceWHPPwuVzuX1I8uUgBQJmf2TlAhsDBQkJZgGABQsJCAcC
BhUKCQgLAgQWAgMBAh4BAheAAAoJEOVzuX1I8uUg198QAMUumy2TExTw95yo67Gf
9c7A3XnxwhRSjSosagWXnh+UvquAf01IgDg4oQoZ3rYfmd20AAXT/x4pKhQJObGu
w36sFO+tX1x53HWWvM/IB53qBH7xmNbjol2rXnm0CKpUxU28GjhYUn4Ywayunsqu
x2QjYX1nQSTu1+b0MTsgwGxoNBAzkwONS3uyjFL21IpZzknlnl8/7EhUkavpYy2T
I1J05Qe21djNYdgcKRPUwoYhCPMiGajEbAYHVaH6UhwwB2gWECYlRVE4BeyAUkbq
CNIFYKN5G+z04FVS5LfQEGHl+lPX6hdB1FT6xfFz/5kV3iKlbSD9GY9azVo/3wF3
yGq94xxI2l5F/H1c2M74NvtFJEafvv4yAI2U5KGHDnqjy/0u1qsdyji2Z0rDPXoN
W9edNWfcY8bhI/O6k7hMYrXzz0gD2cMcP9vbsYigdb/2tq8mRL7MWGKYf1MnkaAp
632G8+Cg+yVWGdl58kqG1J8WMsHgtm2gb4J85Sa1OYfzRyb3LMsLgur52YP8PD8p
c4yQV+fqXSDEydKZCuG+5QVfPBW4tLZfvLZlWAQaSsFSmc2YIwQUzDyhQ/AhL3n1
BZIwusrJMpEYJP9OGTBgIYYgIn/B6d7Tgqju7+1h4fx3BFCPOHoWcYA8tJv2pwHQ
Vzsa2xXNmGBI0wQQBCNcVcyEuQINBGZ/ZOUBEADnDj7pqGCU3DbveoGVeFL5rWDD
6/mFU4aS6hY5x9wgPPK2rEgEIJ++vZ2EKCsqb0W0Gr0GVqazizsnPmhyDgqaN3gW
oCei+X1PHSfKlhigJ48vsHlWdn687V0aYQ7kSofQprwCiEhTkaK+JXs7c6xluDlM
fY71NG3jBvWnrRFZo37rIbhToDWT083ce1P4qa+nbmp0wPrk1n6TQC/y5+3RRkyt
hT/S+1kaV/nudnsQg2sT1zCYIdEgT7+1Of6pxNR0gqzq4FbF0ANCpZHSS+ewbrGq
H/Dkgc6EUntNz7jtAm83j2bLTfYW4ja3o1ER9bGCG9h91fRyNKZDy7m2ZxhOgHgv
tfguLIgm9KjYwjiaO6i3M3FH6492sPc+Ib6aygW/kHxC6HwDmk3NF808/Fxl/CLT
oqfEe62P0wC330YSl5SchaLB5DfO/2tthy0ktv3dagkq0lzrbP9SuR6FI24F9JhU
N4J8lZ41MIWyUYbAJxS1vyTEMeyVrI8AhEbVkiLdpjwqy3BQkHehTNdo432HWCww
W6HkSYEvdvbBdYT54tJjhFDRLShWQ8YiwPbhtXfs2fTEmrsZm1cgyAlOOq053V62
127Y4awJcLbAVlhCpmWWLhfNesbGN6Nt7oNN7tuRt7INNbLpzDGiu8Ap+rWu/90q
p6mqHbq4TUi6yxmC8wARAQABiQI8BBgBCgAmFiEE7KUBbZY/hx5Yc8/C5XO5fUjy
5SAFAmZ/ZOUCGwwFCQlmAYAACgkQ5XO5fUjy5SBRxw/9EEMe3masBBEg8AyJ8+4Q
9+2kJDK2NtsKYhPyYtVZaRx/pgQzSRdFJGiFkaP/+cEBy3g3eoXBhNXIQ3hQSrTF
3DxR2B5QrfszrGCA5bRBEzLpfCxuHCHjzyIVefPiuX8C/HAHDgMaO02xWx8Or4IU
fSWbNCAjgSDsngLzAGCruCNEK7d0U/fOPL1n/DjbzY+qA/xDSYjlQ/x/zMtQxUb0
fVuKUJYlczDfTzrzxU8rct0/vxKKoj1qJHXoKn1mUpEZ3nN2JAPxGX7FZwEkaK8B
f65Khchl2Lez7A4lcwzxYkk64r6hQag3r2jNB5DadxnJvPzpr1lom5LpZg05lL6m
EyjECmVFP7mCpwmYBYwgSu3dB4TT9eA5ygPQyOFUuWVGzINaPvanEm4H1ed2OLzu
TAOrBPTUEFJ/SSgwHrqDuQE69uYLmxIXLkewGfl5RzrCfbByPFsDltEXS7ooMmiv
n+/JTVv6tkidHQ135eTig6jUdZekGr48IhGBCCTNEOB9FcJAmfsJYOJusJXY50Yh
43L0VJUbs9J4mQOB9CS8SrSWXROPm+T5ny+pXkQ5+1jr9GX+zM6WyM0gZV/55vsR
WYpAQo1j6BmIUr416UhhQqCwgI5jLIMXAkFlPAMSjHaCdNiDbHMFzFqLEKonOoWj
1JCNGtCjGAp725GguHGsaKQ=
=Nq24
-END PGP PUBLIC KEY BLOCK-

Bug#1070063: Remmina fails to connect with Windows systems: Protocol Security Negotiation Failure (older release works)

[Daniel Leidert]

Hi,

On Thu, 20 Jun 2024 19:58:55 +0900 Kentaro HAYASHI  wrote:
> On Mon, 29 Apr 2024 15:41:02 +0200 Daniel Leidert  wrote:
> > 
> > when I try to connect to a windows (11) system, I get errors saying
> > something like "check security protocol negotiation". When I set it
> > the security protocol negotiation to automatic detection, there is a
> > connection attempt, but the credentials are not accepted. As I
> > haven't changed anything in the RDP setup, I tried downgrading to
> > version 1.4.34, and everything works now as expected again. I'm not
> > quite sure if this issue is related
> > to https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2062177 
> > and/or https://gitlab.com/Remmina/Remmina/-/issues/3090, or if this is a 
> > complete
> > different issue.
> > 
> 
> If the problem was caused
> by https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2062177, it was 
> fixed in 1.4.35+dfsg-2. [1]
> 
> Is this issue reproducible with 1.4.35+dfsg-2?

I just updated, and now I can no longer reproduce the issue. Thus, I
consider it fixed, likely by the mentioned upload.

Regards, Daniel


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

Bug#1075762: Remove deprecated XS-Ruby-Versions: all and XB-Ruby-Versions: ${ruby:Versions}

[Praveen Arimbrathodiyil]

Package: cme
Version: 1.040-1
Control: affects -1 routine-update
Severity: wishlist

XS-Ruby-Versions: all and XB-Ruby-Versions: ${ruby:Versions} are 
deprecated so cme/routine-update should remove those fields.


You can try this with ruby-redis-store with debian/1.9.0-2 tag on 
salsa.debian.org/ruby-team


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075757: elogind???s conflict with libelogind0 precludes upgrade

[Mark Hindley]

On Thu Jul??  4 12:57:00 2024 Benjamin Cama  wrote:
> Package: elogind
> Version: 246.10-1debian1
> Severity: important
> 
> Dear Maintainer,
> 
> I tried to upgrade to the latest 255 version of elogind, but I do not 
> understand the recent "Conflicts" addition with libelogind0: it renders 
> it uninstallable together with latest libelogind0, and thus ask me to 
> install libsystemd instead, which I do not want.

That is the correct solution. Recent versions use libsystemd0 compatible 
cgroups. You need to let libelogind0 be uninstalled.  See changelog and NEWS.

libelogind0 itself will probably disppear or become a transitional package.

(Sorry for the brevity -- we are away atm)

Mark

Bug#1074764: [Pkg-openssl-devel] Bug#1074764: signing with osslsigncode fails with a segmentation fault since latest stable update

[Sébastien Villemot]

Control: tags -1 + patch

Le mercredi 03 juillet 2024 à 22:05 +0200, Sebastian Andrzej Siewior a
écrit :
> On 2024-07-02 16:23:58 [+0200], Sébastien Villemot wrote:
> > Since the last upgrade of openssl on bookworm (version 3.0.13-1~deb12u1), 
> > code
> > signing using osslsigncode (and my Yubikey) now fails with a segmentation
> > fault. It was working properly with version 3.0.11-1~deb12u2 (and note that
> > downgrading solves the problem).
> > 
> > Here is the command:
> > 
> > $ osslsigncode sign -pkcs11module
> > /usr/lib/x86_64-linux-gnu/libykcs11.so.2 -key
> > "pkcs11:id=%01;type=private;pin-value=" -certs
> > ~/code-signing-certificate.pem -n Foo -i https://www.foo.org -t
> > http://timestamp.comodoca.com -in installer.exe -out
> > installer-signed.exe
> …
> > 
> > Note that the segfault occurs in 
> > /usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so
> > (from libengine-pkcs11-openssl), which is itself called by libcrypto.so.3 
> > (from
> > libssl3).
> 
> Can you check if
>   
> https://github.com/openssl/openssl/commit/39ea78379826fa98e8dc8c0d2b07e2c17cd68380
> 
> fixes it? 

Thanks, I confirm it does.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1071098: onboard: failing build tests

[Bo YU]

Control: tags -1 patch

Hi,
On Mon, Jun 24, 2024 at 01:55:39PM -0400, Jeremy Bícha wrote:

Control: retitle -1 onboard: failing build tests
Control: severity -1 serious
Control: tags -1 -patch

This affects all the architectures and is blocking the completion of
the Python 3.12 transition. I'm dropping the patch tag since the
provided patch won't help much.


I attended one patch to try the issue again and it seems it works. So
could you have a look at your free time?

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/onboard/onboard_1.4.1-7.dsc

Changes since the last upload:

 onboard (1.4.1-7) unstable; urgency=medium
 .
   * Team upload.
   * Export LC_ALL when building. (Closes: #1071098)
 




--
Regards,
--
  Bo YU

diff -Nru onboard-1.4.1/debian/changelog onboard-1.4.1/debian/changelog
--- onboard-1.4.1/debian/changelog	2024-04-04 00:11:22.0 +0800
+++ onboard-1.4.1/debian/changelog	2024-07-04 22:41:29.0 +0800
@@ -1,3 +1,10 @@
+onboard (1.4.1-7) unstable; urgency=medium
+
+  * Team upload.
+  * Export LC_ALL when building. (Closes: #1071098)
+
+ -- Bo YU   Thu, 04 Jul 2024 22:41:29 +0800
+
 onboard (1.4.1-6) unstable; urgency=medium
 
   [ Bo YU ]
diff -Nru onboard-1.4.1/debian/rules onboard-1.4.1/debian/rules
--- onboard-1.4.1/debian/rules	2024-04-04 00:07:08.0 +0800
+++ onboard-1.4.1/debian/rules	2024-07-04 22:36:03.0 +0800
@@ -42,6 +42,7 @@
 	  && export HOME=$$(pwd)/debian/home \
 	  && export XDG_CONFIG_HOME=$$HOME/.config \
 	  && export XDG_DATA_HOME=$$HOME/.local/share/ \
+	  && export LC_ALL=en_US.utf8 \
 	  && xvfb-run -a \
 	 dbus-test-runner --max-wait 3600 --keep-env --bus-type=session -t dh_auto_test
 	rm $$(find .pybuild/cpython3_*_onboard -maxdepth 0 | head -n1)/build/onboard


signature.asc
Description: PGP signature

Bug#1074843: Fixed

[Teus Benschop]

Hello,

A new package was uploaded to unstable that fixes this bug.
GCC 14 was installed, and the fixed upstream source now builds without
errors with this compiler.

Bug#1075763: RM: php-facedetect -- ROM; doesn't build anymore with PHP 8

[Ondřej Surý]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

please remove php-facedetect from unstable, it no longer builds with
PHP 8.x and the upstream hasn't been updated in the last 2 years.

Thanks,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmaGtrVfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcIqhxAAkQcg3phykD9fgHoBzI/9ZJCEPlXeS9gE802lZ4EYGPe9FJX5a44Koyn+
hhOB3wGbPAigOed6Lk863IOW7eQtUUUr1EyEbX7I1nWu20r+11CvbfWCmXJIrzAb
kCxQoPYIwseV6gEBNnwN9LTtCr0SPF0iH9/GBD4dkN6WNSBl9Vak5xxHGB4SANNP
9cX7Z69f2ZOPNZIgBES7EXEsKgjmRYOMOyRLMkpIV/MkhmH2KmJscrSu+GwPR4Ob
HMOypkxZuBK/LQNR4Pecg21UK06w/xLyUlfZ+6Rk+XjC3dNCmfMVBbgtEj1ldMeh
Yr50NHAdE2DZebsH6fa33HoFLOrCzg3jObQf0nWQDkIZimxO4zd9SJxJYMSjt6sc
eitOIIaXwvnQPl4lxwOa4HvOBAHShIM607/tmWZKuD9RjlMIxUmGdpyeBhKP+rWt
26N812rF0vCNY0SAcwa1OKma+nYF9muhO7XNXmNJiVmOa+DzRw2MkNIemsbv9dTW
P5P4xHLaEeFHse8aq/fEO9RILBnaU1WTJ4fb79dOPJ0Jo/etXDAsE1hiajLXA33b
xR8aSodU+YyCsb+xbG+SSdsy2I7UM15M4IH4yKTtCTCozY2WG9+gKc/Fw4dZ1sTD
8UaSEA3Kh9XMejv434sWXB6o5bxY34ZkzzMRNJvD+tvBvOonAYQ=
=qGEp
-END PGP SIGNATURE-

Bug#1075764: RM: sassphp -- ROM; dead upstream, ftbfs

[Ondřej Surý]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thank you

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmaGtxRfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKCHg//SckrOAMYBEh7DT517e1fyTA7GxgU0bL0O9T7pMVDdjD6hNV9JnM7Xo2n
twY3nbb9qjMnVfTOQ4LZDdDcX/Vbbj9a25Q3oQTD6hOfy+S8yCUSNcuYkLlAFDMk
Th8du0bTRDlUpiJjeIRMgP9VExVGpAV0GZrfpp12bAf7IGZw7tLyXk1VgAszb0Gj
EcXkQTOe8y5SWmyIPEH/L+p3crr2gyNOb5+ppKLbuEIW7shMg+so4CjjIx5eP4R4
bxWc+JaBYCxjuksFJnDUaFb1cOULATY61ZGWpyg3KP34zJuZWq7SNcMAinIz+xBT
Z5ACUNIu4X6nT6XK9xN7s4DTfkoOT/mCDOLLHy12/R20nZhtPsiINdiybpsi9vTA
NsahWxyM8+hDmO4+Hy+W7Wh8se/9lG1QToe/WktEAPaCmwSbdePatnuxR+Re4xvh
fhhhRHadtX7zNNbMSwGtysrkM8OYOerKYmo8SAPjGocNOihfPCgQHHefKrCUUe9i
Lxb0AfMoIK77CvFx3TcNFO3Ue1AxmQ3MLdxrhJBm8BkRvjkIde2mzXWDGWOQDaE2
ah7Ej0ph2rHT5LWO1m3fgcKT5vt71Ad248N73CvMdTc3fHkS+QCN7pHwOkSoL/y7
vC8tkMnQ59sJfVPEaC+zU2/7DWzOS92dv2e+ABfAuTV9KLM5hV0=
=MzO5
-END PGP SIGNATURE-

Bug#1075765: RM: tideways -- ROM; deprecated by upstream

[Ondřej Surý]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072571, the upstream 
wrote:

[...]

> While we used to maintain https://github.com/tideways/php-xhprof-extension
> in the past our tideways-php extension is not publically available at
> the moment.
> 
> Besides the naming I'd like to point out that the php-tideways-xhprof
> extension will not receive any further updates and might not work with
> future php versions.
>
> Either renaming the package or removing it from future Debian versions
> would be appreciated.

So, we are just doing that.  Enshittification in progress...

Thank you,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmaGu6RfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcLR3A/9EQEzG0s9OPpsbzIeWVShNOHNHCv+pIr63XlYcJRXkCDpVJkHOYvheyxQ
TdyuHRHcyuSIiLR07BMxzL4VYWN3rcNzxQTtfDssH7N1f5Fr0/LhDo5iOTptvYBy
yE9+jxHM0Q8iioqACb6VbhfDRZw+OmtoM5b9WxvUUESqW9GooJ4JdehdtUwh0NYe
eLJnY1hojfZQfu2WlWfxt3f/zFBqY6iue5lXR0TlbY3f7HDg26w4kCrjrGVzsmKt
Y4AuzJLeBCV3RZm/HUSb88kZoXmlfSSRKiQfE1y4VguBcImrjEwXx2CIuCOXT5kj
gXS0LcKRv9jhAy+5ieeUISL2Q7kNi2k61a95ZtnxViWQEPLkLGzI/rakABoPX/q4
2Ic9xpbLMP7NMPZEXaML4M9Q9gFMud/P/AJnyF+h9uLNFMRDkFZT6FOIwf2qqPNQ
IzD7o95DwfZHMzaH/SiVZcrZDwOXI7l+BdONt6cuocVboR9jymmtiYsGD+Fl1fOi
LHM83z3bxQmlvQGHzpAuA596FZCDHWbJWiN6dYiKlVwWYkcfRUNok1nZVa+Y1NDH
srz6OdTht/J1k7PmEMqYj1Rdhoo9hKpIbNvUvKvN+xehCscvfEWf36UD222d/Yh8
D+sLQiQwqIw+ZLBVtF0jKNYKmGdab6pOuv//IKXisx+l4S5+tZE=
=BR8V
-END PGP SIGNATURE-

Bug#1075766: golang-github-henrybear327-go-proton-api: FTBFS: Invalid signature caused by openpgp: key expired

[Mathias Gibbens]

Source: golang-github-henrybear327-go-proton-api
Version: 1.0.0-3
Severity: serious
Justification: FTBFS
Tags: sid ftbfs

  A test is failing due to an expired gpg key:

> === RUN   TestDecrypt
> message_types_test.go:28: 
> Error Trace:
> /<>/_build/src/github.com/henrybear327/go-proton-api/message_types_test.go:28
> Error:  Received unexpected error:
> Signature Verification Error: Invalid 
> signature caused by openpgp: key expired
> Test:   TestDecrypt
> --- FAIL: TestDecrypt (0.01s)


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

Bug#1071098: onboard: failing build tests

[Mike Gabriel]

Hi Bo,

On  Do 04 Jul 2024 16:58:20 CEST, Bo YU wrote:


Control: tags -1 patch

Hi,
On Mon, Jun 24, 2024 at 01:55:39PM -0400, Jeremy Bícha wrote:

Control: retitle -1 onboard: failing build tests
Control: severity -1 serious
Control: tags -1 -patch

This affects all the architectures and is blocking the completion of
the Python 3.12 transition. I'm dropping the patch tag since the
provided patch won't help much.


I attended one patch to try the issue again and it seems it works. So
could you have a look at your free time?

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


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

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

  dget -x  
https://mentors.debian.net/debian/pool/main/o/onboard/onboard_1.4.1-7.dsc


Changes since the last upload:

 onboard (1.4.1-7) unstable; urgency=medium
 .
   * Team upload.
   * Export LC_ALL when building. (Closes: #1071098)


How about using C.UTF-8 rather than en_US.UTF-8?

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpgYu8GPejAk.pgp
Description: Digitale PGP-Signatur

Bug#1071098: onboard: failing build tests

[Bo YU]

Hi,

On Thu, Jul 4, 2024 at 11:46 PM Mike Gabriel
 wrote:
>
> Hi Bo,
>
> On  Do 04 Jul 2024 16:58:20 CEST, Bo YU wrote:
>
...
> >  onboard (1.4.1-7) unstable; urgency=medium
> >  .
> >* Team upload.
> >* Export LC_ALL when building. (Closes: #1071098)
>

```
&& export XDG_DATA_HOME=$$HOME/.local/share/ \
  && export LC_ALL=c.utf8 \

```

and then get:

```
>   self.assertEqual(_output,
task-0:  self._get_model_files(),
"test " + str(i))
task-0: E   AssertionError: Lists differ: [['en_US.lm',
1]] != [['C.lm', 1]]
task-0: E
task-0: E   First differing element 0:
task-0: E   ['en_US.lm', 1]
task-0: E   ['C.lm', 1]
task-0: E
task-0: Onboard/test/test_migration.py:125: AssertionError
task-0: - Captured stderr call
-
task-0:
task-0: (onboard:696530): Gtk-WARNING **: 15:51:31.018: Locale not
supported by C library.
task-0: Using the fallback 'C' locale.

``

My thoughts is here: the default value of local will be C.UTF-8 but it
failed. So to change it as `en_US` maybe works.

I grep it again, there is really lot hardcode for `en_US`:

```
grep -snri "en_US" .
./Onboard/WPEngine.py:579:'en_US.lm.broken-..._001'
./Onboard/WPEngine.py:582:'en_US.lm.broken-..._002'
./Onboard/WPEngine.py:585:'en_US.lm.broken-..._003'
./Onboard/test/test_migration.py:51:['en_US.lm', 1],
./Onboard/test/test_migration.py:61:['en_US.lm', 1],
./Onboard/test/test_migration.py:62:['en_US.lm.bak', 2],
./Onboard/test/test_migration.py:79:['en_US.lm', 3],
./Onboard/test/test_migration.py:80:['en_US.lm.bak', 4],
./Onboard/test/test_migration.py:83:['en_US.lm', 3],
./Onboard/test/test_migration.py:84:['en_US.lm.bak', 4],
./Onboard/test/test_migration.py:94:['en_US.lm.bak', 4],
./Onboard/test/test_migration.py:97:['en_US.lm', 1],
./Onboard/test/test_migration.py:98:['en_US.lm.bak', 4],
./Onboard/test/test_migration.py:107:['en_US.lm', 3],
./Onboard/test/test_migration.py:110:['en_US.lm', 3],
./Onboard/test/test_migration.py:141:env["LANG"] = "en_US.UTF-8"
./Onboard/Config.py:1461:lang_id = "en_US"
./Onboard/WordSuggestions.py:599:>>>
ws._spell_checker.set_dict_ids(["en_US"])
./Onboard/WordSuggestions.py:1183:>>>
wp._spell_checker.set_dict_ids(["en_US"])
./Onboard/WordSuggestions.py:2642:>>> fn = os.path.join(tdir,
"en_US.lm")
./Onboard/WordSuggestions.py:2658:'en_US.lm.broken-..._001'
./Onboard/WordSuggestions.py:2669:'en_US.lm'
./Onboard/WordSuggestions.py:2670:'en_US.lm.bak'
./Onboard/WordSuggestions.py:2671:'en_US.lm.broken-..._001'

```

But I have really little knowledge about the onboard itself.:(

BR,
Bo
> How about using C.UTF-8 rather than en_US.UTF-8?
>
> Mike
> --
>
> DAS-NETZWERKTEAM
> c\o Technik- und Ökologiezentrum Eckernförde
> Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 850 8940
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>

Bug#1055711: Bug#1057469: gcc-13: Please build gcc with -mbranch-protection=standard to fix PAC/BTI support on arm64

[Emanuele Rocca]

On 2024-07-01 03:12, Emanuele Rocca wrote:
> I haven't tested it on cross-builds of the native compiler as that
> currently fails due to unsatisfied dependencies in sid. That case
> should work fine too though.

Double-checked today, cross-builds of the native compiler work as well
both with and without the flag.

Without -mbranch-protection=standard:

  DEB_BUILD_MAINT_OPTIONS=hardening=-branch DEB_BUILD_OPTIONS=nolang=m2 sbuild 
--host=arm64

With -mbranch-protection=standard:

  DEB_BUILD_OPTIONS=nolang=m2 sbuild --host=arm64

Note that sbuild whitelists a set of variables that are passed into the
schroot and all others are dropped, so you'll need the following in
~/.sbuildrc for DEB_BUILD_MAINT_OPTIONS to go through:

 $environment_filter = [Dpkg::BuildInfo::get_build_env_allowed(), 
'DEB_BUILD_MAINT_OPTIONS'];

Alternatively, one can also just take the easy route and pass
hardening=-branch in DEB_BUILD_OPTIONS, which is whitelisted by default:

 DEB_BUILD_OPTIONS='nolang=m2 hardening=-branch' sbuild --host=arm64

Bug#910799: helm PPA

[Paolo Greppi]

According to upstream, you can install helm from apt on Debian:
https://helm.sh/docs/intro/install/#from-apt-debianubuntu

> Members of the Helm community have contributed a Helm package for Apt.

The link points to:
https://helm.baltorepo.com/stable/debian/packages/helm/

The package source apparently is:
https://github.com/BaltoRepo/helm-linux-packages

They package it with fpm: https://fpm.readthedocs.io/en/latest/
which is not (and likely won't ever be) in Debian:
https://bugs.debian.org/688896

P.

Bug#1075767: elpa-debian-el: debian-bug fails with Lisp error for some packages

[Sven Joachim]

Package: elpa-debian-el
Version: 37.13
Severity: important

I wanted to report a bug against the dpkg-dev package, but that resulted
in a Lisp error before even running reportbug.  Below is a backtrace
after loading the debian-bug.el source file.

Downgrading elpa-debian-el to version 37.12 fixes the problem.

,
| Debugger entered--Lisp error: (wrong-number-of-arguments #f(lambda (process 
event package severity subject filename bug-script-temp-file win-config) 
:dynbind "This function is the process sentinel for bug script processes.\nWhen 
called, if the process has terminated, this function cleans\nup the buffer used 
by the process and proceeds to the next step in the\nbug reporting process by 
calling `debian-bug-compose-report'. Note that\nthis process sentinel is 
different from regular process sentinels in\nthat it requires more arguments. 
So, it cannot be assigned to a process\nwith `set-process-sentinel' directly, 
but requires some tweaking instead." (if (memq (process-status process) '(exit 
signal)) (let* ((bug-script-buffer (process-buffer process)) 
(bug-script-buffer-empty (= (buffer-size bug-script-buffer) 0))) (if (fboundp 
'term-sentinel) (term-sentinel process event)) (if (get-buffer-window 
bug-script-buffer) (set-window-configuration win-config)) (if (buffer-name 
bug-script-buffer) (if bug-script-buffer-empty (kill-buffer bug-script-buffer) 
(bury-buffer bug-script-buffer))) (debian-bug-compose-report package severity 
subject filename bug-script-temp-file 9)
|   debian-bug-script-sentinel(# "finished\n" 
"dpkg-dev" "normal" "" "foo" nil "/tmp/debian-bug-2H4mUL" 
#)
|   (lambda (process event) (debian-bug-script-sentinel process event 
"dpkg-dev" "normal" "" "foo" nil "/tmp/debian-bug-2H4mUL" 
#))(# "finished\n")
|   accept-process-output(# 200)
|   (let ((bug-script-buffer (get-buffer-create "*debian-bug-script*")) 
(bug-script-temp-file (cond ((fboundp 'make-temp-file) (make-temp-file 
"debian-bug-")) ((fboundp 'temp-directory) (make-temp-name (expand-file-name 
"debian-bug-" (temp-directory (t (error "Cannot create temporary file" 
(bug-script-process) (coding-system-for-read 'binary)) (message (concat 
"Collecting information about the package." " This may take some time.")) 
(save-current-buffer (set-buffer bug-script-buffer) 'term (erase-buffer) 
(term-mode) (debian-bug--safe-term-exec bug-script-buffer "debian-bug-script" 
handler nil (list bug-script bug-script-temp-file)) (setq bug-script-process 
(get-buffer-process bug-script-buffer)) (if bug-script-process (progn 
(set-process-sentinel bug-script-process (list 'lambda '(process event) (list 
'debian-bug-script-sentinel 'process 'event package severity version subject 
filename bug-script-temp-file (current-window-configuration 
(term-char-mode) (if (fboundp 'set-process-query-on-exit-flag) 
(set-process-query-on-exit-flag bug-script-process nil))) (message (concat 
"Trying to get package related info failed.  " "Generated bug report may be 
missing some " "information." (accept-process-output bug-script-process 
200) (sleep-for 0.05) (if (not (memq (process-status bug-script-process) '(exit 
signal))) (switch-to-buffer-other-window bug-script-buffer)))
|   (if (and bug-script (debian-bug-file-is-executable handler) (if nil (or 
(featurep 'term) (load "term" 'noerror)) (require 'term nil 'noerror))) (let 
((bug-script-buffer (get-buffer-create "*debian-bug-script*")) 
(bug-script-temp-file (cond ((fboundp 'make-temp-file) (make-temp-file 
"debian-bug-")) ((fboundp 'temp-directory) (make-temp-name (expand-file-name 
"debian-bug-" ...))) (t (error "Cannot create temporary file" 
(bug-script-process) (coding-system-for-read 'binary)) (message (concat 
"Collecting information about the package." " This may take some time.")) 
(save-current-buffer (set-buffer bug-script-buffer) 'term (erase-buffer) 
(term-mode) (debian-bug--safe-term-exec bug-script-buffer "debian-bug-script" 
handler nil (list bug-script bug-script-temp-file)) (setq bug-script-process 
(get-buffer-process bug-script-buffer)) (if bug-script-process (progn 
(set-process-sentinel bug-script-process (list 'lambda '... (list ... ... ... 
package severity version subject filename bug-script-temp-file ...))) 
(term-char-mode) (if (fboundp 'set-process-query-on-exit-flag) 
(set-process-query-on-exit-flag bug-script-process nil))) (message (concat 
"Trying to get package related info failed.  " "Generated bug report may be 
missing some " "information." (accept-process-output bug-script-process 
200) (sleep-for 0.05) (if (not (memq (process-status bug-script-process) '(exit 
signal))) (switch-to-buffer-other-window bug-script-buffer))) 
(debian-bug-compose-report package severity version subject filename))
|   (let ((handler "/usr/share/reportbug/handle_bugscript") (bug-script 
(debian-bug-find-bug-script package))) (if (and bug-script 
(debian-bug-file-is-executable handler) (if nil (or (featurep 'term) (load 
"term" 'noerror)) (requir

Bug#1075768: coreutils: ls doesn't honour COLUMNS if writing to a teletype

[наб]

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

Quoth POSIX.1-2024:
103406  ENVIRONMENT VARIABLES
103407  The following environment variables shall affect the execution of ls:
103408  COLUMNS  Override the system-selected horizontal display line size, 
used to determine the
103409   column position width for writing multiple text-column output. 
See XBD Chapter
103410   8 (on page 167) for valid values and results when it is unset 
or null. The ls utility
103411   shall use this value to calculate how many pathname text 
columns to write (see
103412   −C). The column width chosen to write the names of files in 
any given directory
103413   shall be constant. Filenames shall not be truncated to fit 
into the multiple text-
103414   column output.

Quoth UNIX™ System V ‒ Release 2.0 User Reference Manual, DEC™ Processors 
(1984):
  There are three major listing formats.  The default format is to list one 
entry
  per line, the -C and -x options enable multi-column formats, and the -m
  option enables stream output format in which files are listed across the page,
  separated by commas.  In order to determine output formats for the -C, -x,
  and -m options, /s uses an environment variable, COLUMNS, to determine the
  number of character positions available on one output line.  If this variable 
is
  not set, the terminfo database is used to determine the number of columns,
  based on the environment variable TERM.  If this information cannot be
  obtained, 80 columns are assumed.

Compare:
  $ /bin/ls
  ababa.gif  boot.dump  dead.letter  dump1.stty   dump1.worms.c  dump2.stty 
  dump2.worms.c  equivs rustup-init setup.log  tarta.d  worms.c
  awk  bin   code   dump1.cmddump1.worms  dump2.cmd  
dump2.worms  dupa   reportbug.report~  rustup-init.sh  srcworms
  $ COLUMNS=80 /bin/ls
  ababa.gif  boot.dump  dead.letter  dump1.stty   dump1.worms.c  dump2.stty 
  dump2.worms.c  equivs rustup-init setup.log  tarta.d  worms.c
  awk  bin   code   dump1.cmddump1.worms  dump2.cmd  
dump2.worms  dupa   reportbug.report~  rustup-init.sh  srcworms

Best,

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

Kernel: Linux 6.5.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FORCED_MODULE, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1   2.3.2-1
ii  libattr1  1:2.5.2-1
ii  libc6 2.38-13
ii  libgmp10  2:6.3.0+dfsg-2
ii  libselinux1   3.5-2
ii  libssl3t64 [libssl3]  3.1.5-1.1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1075769: dpkg-dev: qa=-bug-implicit-func in DEB_BUILD_OPTIONS should add -Wnoerror=implicit-function-declaration to CFLAGS

[Sven Joachim]

Package: dpkg-dev
Version: 1.22.6

To work around FTBFS bug #1066382 in xserver-xorg-video-nouveau, I set
DEB_BUILD_MAINT_OPTIONS=qa=-bug-implicit-func.  It seems this is no
longer sufficient with gcc-14, because
-Werror=implicit-function-declaration is actually the default, and so
xserver-xorg-video-nouveau FTBFS again.  See #1075682.

Therefore I propose that qa=-bug-implicit-func should add
-Wnoerror=implicit-function-declaration to CFLAGS, otherwise that option
will become useless once gcc-14 is the default compiler.


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

Bug#1073560: Reverting "xshared: Print protocol numbers if --numeric was given" breaks firewalld autopkgtest

[Michael Biebl]

Control: reassign -1 src:firewalld
Control: found -1 2.1.2-1
Control: severity -1 important
Control: forwarded -1 https://github.com/firewalld/firewalld/pull/1360


We will handle this on the firewalld side. So reassigning accordingly.

Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli (wintermute)]

Package: src:linux
Version: 6.9.7-1
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello,
on a laptop where I installed Debian testing some 6 months ago,
I noticed that the logs are continuously filled with call traces
like the attached snippet (taken from /var/log/kern.log ).

It seems to me that it also used to happen with previous versions
of the Linux kernel, but I am under the impression that, with linux/6.9.7-1,
it got worse.

I see 12 of these call traces just after boot, before even starting X
(with 'startx').
More of these call traces are sent to the logs after starting X, or
after invoking 'xrandr', or after locking the X session (with
XScreenSaver), ...

They seem to correspond to no actual issue, as far as I can tell,
but they are filling the logs with a significant flow of text...
which is worrying by itself.

What's wrong?
How can I stop this log-filling flood?


-- Package-specific info:
** Version:
Linux version 6.9.7-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.3.0-1) 13.3.0, GNU ld (GNU Binutils for 
Debian) 2.42.50.20240625) #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1 (2024-06-27)

** Command line:
BOOT_IMAGE=/vmlinuz-6.9.7-amd64 root=/dev/mapper/ol-root ro quiet

** Tainted: W (512)
 * kernel issued warning

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

** Model information
sys_vendor: Notebook
product_name: NLxxPUx
product_version: Not Applicable
chassis_vendor: No Enclosure
chassis_version: N/A
bios_vendor: INSYDE Corp.
bios_version: 1.07.09
board_vendor: Notebook
board_name: NLxxPUx
board_version: Not Applicable

** Loaded modules:
8021q
garp
stp
mrp
llc
iptable_nat
nf_nat
nf_conntrack
cmac
nf_defrag_ipv6
nf_defrag_ipv4
algif_hash
libcrc32c
algif_skcipher
iptable_mangle
af_alg
snd_hda_codec_hdmi
iptable_filter
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
snd_sof_pci_intel_tgl
fat
snd_sof_intel_hda_common
soundwire_intel
snd_sof_intel_hda_mlink
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
snd_soc_hdac_hda
snd_soc_acpi_intel_match
soundwire_generic_allocation
snd_soc_acpi
soundwire_bus
snd_soc_avs
snd_soc_hda_codec
snd_hda_ext_core
btusb
i915
btrtl
snd_soc_core
btintel
btbcm
btmtk
snd_compress
iwlmvm
intel_uncore_frequency
intel_uncore_frequency_common
snd_pcm_dmaengine
bluetooth
x86_pkg_temp_thermal
snd_hda_intel
mac80211
intel_powerclamp
snd_intel_dspcfg
uvcvideo
coretemp
snd_intel_sdw_acpi
snd_usb_audio
processor_thermal_device_pci
videobuf2_vmalloc
kvm_intel
snd_hda_codec
processor_thermal_device
drm_buddy
snd_usbmidi_lib
uvc
processor_thermal_wt_hint
libarc4
sha3_generic
drm_display_helper
snd_hda_core
snd_rawmidi
videobuf2_memops
processor_thermal_rfim
kvm
jitterentropy_rng
snd_hwdep
snd_seq_device
cec
videobuf2_v4l2
iwlwifi
intel_rapl_msr
processor_thermal_rapl
snd_pcm
drbg
rc_core
iTCO_wdt
videodev
intel_rapl_common
rapl
mei_pxp
mei_hdcp
processor_thermal_wt_req
ttm
intel_pmc_bxt
ansi_cprng
snd_timer
cfg80211
jc42
intel_cstate
processor_thermal_power_floor
intel_pmc_core
videobuf2_common
iTCO_vendor_support
drm_kms_helper
mei_me
snd
ecdh_generic
int3403_thermal
processor_thermal_mbox
int3400_thermal
intel_uncore
pmt_telemetry
pcspkr
watchdog
mc
ee1004
i2c_algo_bit
ecc
mei
rfkill
soundcore
intel_vsec
igen6_edac
int340x_thermal_zone
joydev
evdev
acpi_thermal_rel
pmt_class
intel_hid
acpi_pad
sparse_keymap
ac
button
hid_multitouch
serio_raw
efi_pstore
configfs
nfnetlink
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
nvme
nvme_core
usbhid
t10_pi
crc32_pclmul
crc32c_intel
crc64_rocksoft_generic
crc64_rocksoft
hid_generic
ahci
ghash_clmulni_intel
crc_t10dif
sha512_ssse3
xhci_pci
libahci
r8169
crct10dif_generic
i2c_hid_acpi
rtsx_pci_sdmmc
sha512_generic
xhci_hcd
libata
realtek
crct10dif_pclmul
i2c_hid
intel_lpss_pci
mmc_core
sha256_ssse3
mdio_devres
crc64
scsi_mod
i2c_i801
usbcore
intel_lpss
drm
psmouse
sha1_ssse3
libphy
video
rtsx_pci
crct10dif_common
i2c_smbus
scsi_common
idma64
usb_common
battery
hid
wmi
aesni_intel
crypto_simd
cryptd

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Alder Lake-U15 Host and DRAM 
Controller [8086:4601] (rev 04)
Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: igen6_edac
Kernel modules: igen6_edac

00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-UP3 GT2 
[UHD Graphics] [8086:4628] (rev 0c) (prog-if 00 [VGA controller])
Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

Bug#1068076: Patch for bug 1068076

[Nicolas Mora]

Thanks Mattias!

Your patch has been submitted upstream, the PR [1] is now merged so I 
backported it as a debian patch [2]. I'll soon upload the new version if 
everything is fine.


/Nicolas

[1] https://github.com/libssh2/libssh2/pull/1415
[2] 
https://salsa.debian.org/debian/libssh2/-/blob/master/debian/patches/maxpathlen.patch?ref_type=heads

Bug#1073960: RFS: libmobi/0.12+dfsg-1 [RC] -- Tools for handling Mobipocket/Kindle ebook format documents

[Bartek Fabiszewski]

Control: tags -1 - moreinfo

Hi Phil,

Sorry, I did not notice earlier your quick reply.

I patched lintian spelling issues and uploaded new package.

Best,
Bartek

Bug#992131: R8169 CRASH! (rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100))

[Vincas Dargis]

No longer happens in Sid with 6.9.7-1!

Bug#1075771: kanboard: Kanboard is throwing an exception in EventDispatcher while trying to logout

[Kalyani Kenekar]

Package: kanboard
Severity: important
Tags: upstream

Dear Maintainer,

If I am trying to logout from the kanboard UI, I am not able to logout because
I am getting a "HTTP ERROR 500".

When I look into the error log of my webserver (nginx) I see the following
stack trace:

Stack trace:
#0 /usr/share/kanboard/app/Core/Session/SessionManager.php(62): 
Symfony\Component\EventDispatcher\EventDispatcher->dispatch()
#1 /usr/share/kanboard/app/Controller/AuthController.php(61): 
Kanboard\Core\Session\SessionManager->close()
#2 /usr/share/kanboard/app/Core/Controller/Runner.php(77): 
Kanboard\Controller\AuthController->logout()
#3 /usr/share/kanboard/app/Core/Controller/Runner.php(31): 
Kanboard\Core\Controller\Runner->executeController()
#4 /usr/share/kanboard/index.php(9): Kanboard\Core\Controller\Runner->execute()
#5 {main}
  thrown in 
/usr/share/php/Symfony/Component/EventDispatcher/EventDispatcher.php on line 
48" while reading response header from upstream, client: 192.168.122.1, server: 
kanboard, request: "GET /logout HTTP/1.1", upstream: 
"fastcgi://unix:/var/run/php/php-fpm.sock:", host: "kanboard"
2024/07/04 20:22:17 [error] 2890#2890: *59 FastCGI sent in stderr: "PHP 
message: PHP Fatal error:  Uncaught TypeError: 
Symfony\Component\EventDispatcher\EventDispatcher::dispatch(): Argument #1 
($event) must be of type object, string given, called in 
/usr/share/kanboard/app/Core/Session/SessionManager.php on line 62 and defined 
in /usr/share/php/Symfony/Component/EventDispatcher/EventDispatcher.php:48


This is known bug it was fixed in upstream version 1.2.32.
The PR 5309 in detail was fixing this issue: 
https://github.com/kanboard/kanboard/pull/5309/files


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

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

Bug#1065928: python-enigma: Please drop dependencies on python3-distutils

[Emmanuel Arias]

Hi Tomasz,

I'm interested in fix python3-distutils bugs. New upstream release 
seems will fix this issue. For that d/watch, for instance, need to be 
updated.

Can you please update the package? If you don't have any problem I can
create MRs in salsa with the updates/fixes, or make an NMU.

Thanks!

-- 
cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
 
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#1074795: python3-distributed: module version reported as "0+unknown"

[Étienne Mollier]

Hi Julian,

Julian Gilbey, on 2024-07-03:
> Is there any chance that setting SETUPTOOLS_SCM_PRETEND_VERSION would
> help?

Thanks for the hint, it sounded worth a try and I started a
build, including in d/rules:

include /usr/share/dpkg/pkg-info.mk
export SETUPTOOLS_SCM_PRETEND_VERSION = $(DEB_VERSION_UPSTREAM)

but early build steps tripped on 0+unknown anyway:

[…]
UPDATING build/lib/distributed/_version.py
set build/lib/distributed/_version.py to '0+unknown'
[…]

Version handling looks to originate from distributed/_version.py
which in turn is supposed to have been autogenerated somehow by
versionneer.  Worst case scenario, I suppose it could be
possible to hardwire the package version at the following
location:

197 def git_versions_from_keywords(
198 keywords: dict[str, str],
199 tag_prefix: str,
200 verbose: bool,
201 ) -> dict[str, Any]:
[…]
262 return {
263 "version": "0+unknown",
264 "full-revisionid": keywords["full"].strip(),
265 "dirty": False,
266 "error": "no suitable tags",
267 "date": None,
268 }

but I'm not confident how this interferes with the other version
fields normally filled automatically after deriving the git tag.

Hope this gives some inspiration,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: RPWL - Victim Of Desire


signature.asc
Description: PGP signature

Bug#1075772: src:openconnect: unsatisfied build dependency in testing: ocserv

[Paul Gevers]

Source: openconnect
Version: 9.12-2
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065943: pytorch-cuda: Please drop dependencies on python3-distutils

[Emmanuel Arias]

Hi,

Seems this bugs was fixed in #1065941.


-- 
cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
 
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#1075773: src:libosmo-abis: unsatisfied build dependency in testing: dahdi-source

[Paul Gevers]

Source: libosmo-abis
Version: 1.3.0-2.1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075774: src:powder: fails to migrate to testing for too long: no binaries uploaded

[Paul Gevers]

Source: powder
Version: 118+dfsg1-3
Severity: serious
Control: close -1 118+dfsg1-4
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:powder has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. This package is part of non-free, 
so binaries aren't always build automatically [3]. Hence, in the current 
state, somebody needs to upload the binaries associated with the source 
in unstable.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=powder
[3] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074787: libadwaita-1-0: Libadwaita and GTK version mis-match

[Calvin Walton]

Just a note from someone who helped diagnose this issue on the GNOME
matrix channel:

While the libadwaita library doesn't require any new symbols
introduced in Gtk >= 4.13.4 (i.e. Gtk 4.14), it does have a runtime
dependency on that Gtk version because of changes in some
configuration properties and stylesheet related things.

The particular issue that was noticed, which is caused by this
mismatch, is that the visual indicators for "switch" widget position
are permanently visible on Debian unstable, instead of being linked to
the High Contrast accessibility setting as intended.

I urge the Debian package maintainers to add a manual runtime
dependency on the correct Gtk version to the libadwaita-1-0 package,
and keep it updated as new versions of libadwaita are released (each
libadwaita version generally requires the matching just-released new
stable Gtk version).

Thanks,
Calvin.

Bug#1075768: coreutils: ls doesn't honour COLUMNS if writing to a teletype

[Pádraig Brady]

On 04/07/2024 17:29, наб wrote:

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

Quoth POSIX.1-2024:
103406  ENVIRONMENT VARIABLES
103407  The following environment variables shall affect the execution of ls:
103408  COLUMNS  Override the system-selected horizontal display line size, 
used to determine the
103409   column position width for writing multiple text-column output. 
See XBD Chapter
103410   8 (on page 167) for valid values and results when it is unset 
or null. The ls utility
103411   shall use this value to calculate how many pathname text 
columns to write (see
103412   −C). The column width chosen to write the names of files in 
any given directory
103413   shall be constant. Filenames shall not be truncated to fit 
into the multiple text-
103414   column output.

Quoth UNIX™ System V ‒ Release 2.0 User Reference Manual, DEC™ Processors 
(1984):
   There are three major listing formats.  The default format is to list one 
entry
   per line, the -C and -x options enable multi-column formats, and the -m
   option enables stream output format in which files are listed across the 
page,
   separated by commas.  In order to determine output formats for the -C, -x,
   and -m options, /s uses an environment variable, COLUMNS, to determine the
   number of character positions available on one output line.  If this 
variable is
   not set, the terminfo database is used to determine the number of columns,
   based on the environment variable TERM.  If this information cannot be
   obtained, 80 columns are assumed.


Right, both POSIX 2003 and 2008 say that COLUMNS should override any auto width 
determination.
However since the beginning, GNU ls has the -w option to override the width,
and so leaves $COLUMNS as something that is auto set (and usually is by the 
shell).
Since changing this to align with POSIX adds no new functionality,
I'm reluctant to adjust this at this stage, in case COLUMNS is set
incorrectly / inadvertently for some users.
We could safely change this I suppose, gated with the POSIXLY_CORRECT env var.

cheers,
Pádraig.

Bug#1075607: unifrac: autogenerated C code ftbfs with GCC-14

[Étienne Mollier]

Control: tags -1 + confirmed

Hi,

The relevant part of the build log would be:

unifrac/_api.c:27151:32:
error: assignment to ‘_Bool *’
   from incompatible pointer type ‘__pyx_t_7unifrac_4_api_bool *’
   {aka ‘unsigned char *’}
   [-Wincompatible-pointer-types]
27151 |   __pyx_v_sp_bptree->structure = __pyx_v_structure;
  |^

This stems from cythonized C code, so I don't see much knobs to
fix it from unifrac source code.  I suspect other packages may
be similarly affected and would benefit from having cython being
able to produce valid gcc-14 C code.  If I trust gcc-14 porting
guide[1], another option if cython cannot produce such C code
would be for it to emit pragmas described in "Accommodating C
code generators" section; this would still be a change to bring
on cython side.

Worst case scenario if the issue is not addressed in cython, it
would still be possible to reduce the severity of the error by
passing -Wno-error=incompatible-pointer-types.  I suggest
keeping this option for when the bug severity is bumped to
serious.

[1]: https://gcc.gnu.org/gcc-14/porting_to.html

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: The Chronicles Of Father Robin - Ocean Travell…


signature.asc
Description: PGP signature

Bug#1075775: please package new upstream release 2.6.0 or greater to possibly support many new transit providers

[John Scott]

Source: railway-gtk
Version: 2.4.0-4
Severity: wishlist

Hi friends,

New versions of Railway appear to have added support for not only new transit 
routes, but also new services to discover transit routes. The current packaged 
version is geared towards rail travel in Europe, but it appears that the new 
version should be capable of public transportation more broadly, especially in 
the United States. Given that Google Maps alternatives such as OpenStreetMap 
are already uncommon in the US, I think this new upstream release could be a 
giant leap forward in breaking up the monoculture.
At least for the large American bus network around me, it doesn't seem like 
there's any practical way to navigate it using free software. There are plans 
to change it, but for now public transit support in GNOME Maps is basically a 
patchwork that (I think) only covers a single US city. Thus I think that 
letting users get their feet wet with possibilities will also motivate 
discussions for the rest of the ecosystem to improve.

I'm a Debian Maintainer for unrelated packages and have made small merge 
requests to GNOME packages before, so although it would be ambitious, please 
let me know if you'd like me to try this.

Thanks

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

Kernel: Linux 6.8.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
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


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1072899: closed by Debian FTP Masters (reply to Guido Günther ) (Bug#1072899: fixed in whatmaps 0.0.14-1)

[Alexandre Detiste]

Hi,

Thank you already

Please also remove python3-mock from debian/control.

Greetings

https://git.sigxcpu.org/cgit/whatmaps/log/?h=debian/master

Le jeu. 4 juil. 2024 à 12:54, Debian Bug Tracking System
 a écrit :
> Date: Thu, 04 Jul 2024 10:50:41 +
> Subject: Bug#1072899: fixed in whatmaps 0.0.14-1
> Source: whatmaps
> Source-Version: 0.0.14-1
> Done: Guido Günther 
>  whatmaps (0.0.14-1) unstable; urgency=medium
>  .
>* New upstream version
>  (Closes: #1072899, #1074668)

Bug#900928: Dependency update

[Matthias Geiger]

On Sun, 26 Nov 2023 11:34:28 +0100 Matthias Geiger 
 wrote:

> Running cargo debstatus on the 5.x tree yields:
>
> NEW packages that need packaging from scratch:
>
>
> - html5gum
>
> - rqrr
>
> - html2pango
>
> - htmlescape
>
> -geo-uri
>
> - djb_hash
>
> - eyeball-im
>
> Once the ruma stack is in debian I'll update it to the latest release;
> then packaging fractal should be trivial.
>

Well still didn't have time for ruma (I hope to finish this in August).

Good news: sourceview5 just was accepted from NEW. This means all 
GTK-related deps are present and up to date. This leaves ruma plus some 
other crates (haven't checked). I'll file a leaf ITP for ruma soon™.


best,


werdahias

Bug#1072071: gcc-13: Please add libatomic for 32-bit SPARC for Ada

[Nicolas Boulenguez]

Source: gcc-13
Followup-For: Bug #1072071

Hello.

The attached suggestions are just ideas, not real commits. They are
hand-written and not tested at all, so probably contain typos.
Morever, they were written in a gcc-14 source tree.

For the context, commit e08cd8a2 disables Ada on sparc (bug #1072328).

If Adrian can check that 0001, 0002 and 0003 fix #1072071,
then I suggest to merge them into a single commit,
else
  if Matthias confirms that := was not deliberate
  then I suggest to apply 0001.
From: Nicolas Boulenguez 
Subject: [PATCH 1/3] probably fix a typo in e08cd8a2

--- a/debian/control
+++ b/debian/control
@@ -15,11 +15,11 @@ Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.17.14), g++-multilib [amd64 i38
   gperf, bison, flex,
   gettext, nvptx-tools [amd64 arm64 ppc64el], amdgcn-tools-18 [amd64],
   texinfo, locales-all, sharutils,
-  procps, gnat-13:native [!sparc !loong64], g++-13:native [!loong64], gnat-14:native [loong64], g++-14:native [loong64], netbase, gdc-13:native [!arc !ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386], python3:any, cargo [!hppa !ia64 !m68k !sh4 !alpha !hurd-alpha],
+  procps, gnat-13:native [!arc !ia64 !sh3 !sh3eb !sh4eb !sparc !loong64], g++-13:native [!loong64], gnat-14:native [loong64], g++-14:native [loong64], netbase, gdc-13:native [!arc !ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386], python3:any, cargo [!hppa !ia64 !m68k !sh4 !alpha !hurd-alpha],
   libisl-dev (>= 0.20), libmpc-dev (>= 1.0), libmpfr-dev (>= 3.0.0-9~), libgmp-dev (>= 2:5.0.1~), lib32z1-dev [amd64], lib64z1-dev [i386], unzip ,
   dejagnu , coreutils, chrpath, lsb-release, quilt, time,
   pkg-config, libgc-dev,
-  g++-14-for-host , gobjc-14-for-host [!avr] , gfortran-14-for-host , gdc-14-for-host [!arc !ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386] , gccgo-14-for-host [!arc !avr !hppa !loong64 !m68k !sh4] , gnat-14-for-host [!sparc] , gm2-14-for-host [!powerpc !ppc64 !sh4] ,
+  g++-14-for-host , gobjc-14-for-host [!avr] , gfortran-14-for-host , gdc-14-for-host [!arc !ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386] , gccgo-14-for-host [!arc !avr !hppa !loong64 !m68k !sh4] , gnat-14-for-host [!arc !ia64 !sh3 !sh3eb !sh4eb !sparc] , gm2-14-for-host [!powerpc !ppc64 !sh4] ,
 Build-Depends-Indep: doxygen , graphviz , ghostscript , texlive-latex-base , xsltproc , libxml2-utils , docbook-xsl-ns ,
 Homepage: http://gcc.gnu.org/
 Vcs-Browser: https://salsa.debian.org/toolchain-team/gcc
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -872,7 +872,7 @@ ifeq (,$(filter $(DEB_STAGE),stage1 stage2))
 # Ada 
 ada_no_cpus	:= arc ia64 sh3 sh3eb sh4eb
 #ada_no_cpus	+= armel # See Debian #1061370
-ada_no_cpus	:= sparc # See Debian #1072328
+ada_no_cpus	+= sparc # See Debian #1072328
 ada_no_systems	:= 
 ada_no_cross	:= no
 ada_no_snap	:= no
From: Nicolas Boulenguez 
Subject: [PATCH 2/3] untested fix for #1072071

--- a/debian/patches/ada-armel-libatomic.diff
+++ b/debian/patches/ada-armel-libatomic.diff
@@ -1,11 +1,14 @@
-Description: link libgnarl with libatomic on armel
+Description: link libgnarl with libatomic on armel and sparc
  On other architectures, the library is ignored thanks to --as-needed.
  .
- Seen with 14-20240429-1:
+ Seen with 14-20240429-1 on armel:
  cd rts; [bla]/./gcc/xgcc [bla] -shared [bla] -o libgnarl-14.so [bla]
  /usr/bin/arm-linux-gnueabi-ld: libgnat-14.so: undefined reference to `__atomic_compare_exchange_8'
  /usr/bin/arm-linux-gnueabi-ld: libgnat-14.so: undefined reference to `__atomic_load_8'
  .
+ Seen with 13.2.0-25 on sparc:
+ checking fp.h usability... /usr/sparc-linux-gnu/bin/ld: libgnat-13.so: undefined reference to `__atomic_compare_exchange_8'
+ .
  Libatomic becomes an artificial dependency for Ada in Makefile.def,
  so a better solution is welcome.
  .
@@ -22,6 +25,7 @@ Description: link libgnarl with libatomic on armel
  (ada-gnattools-cross.diff adds checking options to LDFLAGS,
   then adds LDFLAGS to the command line).
 Bug-Debian: https://bugs.debian.org/861734
+Bug-Debian: https://bugs.debian.org/1072071
 Author: Matthias Klose 
 Author: Nicolas Boulenguez 
 
@@ -35,6 +39,14 @@ Author: Nicolas Boulenguez 
LIBGNAT_TARGET_PAIRS = \
a-intnam.adsFrom: Nicolas Boulenguez 
Subject: [PATCH 3/3] revert e08cd8a2

--- a/debian/control
+++ b/debian/control
@@ -15,11 +15,11 @@ Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.17.14), g++-multilib [amd64 i38
   gperf, bison, flex,
   gettext, nvptx-tools [amd64 arm64 ppc64el], amdgcn-tools-18 [amd64],
   texinfo, locales-all, sharutils,
-  procps, gnat-13:native [!arc !ia64 !sh3 !sh3eb !sh4eb !sparc !loong64], g++-13:native [!loong64], gnat-14:native [loong64], g++-14:native [loong64], netbase, gdc-13:native [!arc !ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386], python3:any, cargo [!hppa !ia64 !m68k !sh4 !alpha !hurd-alpha],
+  procps, gnat-13:native [!arc !ia64 !sh3 !

Bug#1018664: pytest

[Alexandre Detiste]

Hi again,

The tests run juste fine with pytest (and in color).
We'd like to remove python3-nose when Py3.13 is released.

asyncio: mode=Mode.STRICT
collected 31 items

tests/test_debiandistro.py s[ 16%]
tests/test_debianpkg.py .   [ 19%]
tests/test_distro.py .s...  [ 35%]
tests/test_pkg.py . [ 51%]
tests/test_process.py ...   [ 74%]
tests/test_redhatdistro.py ...  [ 83%]
tests/test_rpmpkg.py .  [ 87%]
tests/test_systemd.py   [100%]

 29 passed, 2 skipped in 0.72s 
tchet@quieter:/tmp/whatmaps$

Bug#1075776: gmp-ecm: New upstream version 7.0.6

[Laurent Fousse]

Package: gmp-ecm
Version: 7.0.5+ds-1
Severity: wishlist

Dear Maintainer,

Please package the new upstream version, available at
https://gitlab.inria.fr/zimmerma/ecm/-/releases/git-7.0.6.

Thanks!

Laurent Fousse

Bug#1075757: elogind's conflict with libelogind0 precludes upgrade

[Benjamin Cama]

Hi Mark,

Le Thu, Jul 04, 2024 at 03:14:10PM +0100, Mark Hindley a écrit :

On Thu Jul??  4 12:57:00 2024 Benjamin Cama  wrote:

Package: elogind
Version: 246.10-1debian1
Severity: important

Dear Maintainer,

I tried to upgrade to the latest 255 version of elogind, but I do not
understand the recent "Conflicts" addition with libelogind0: it renders
it uninstallable together with latest libelogind0, and thus ask me to
install libsystemd instead, which I do not want.


That is the correct solution. Recent versions use libsystemd0 
compatible cgroups. You need to let libelogind0 be uninstalled.  See 
changelog and NEWS.


Ho, OK then, but I could not read the NEWS until the package is getting 
installed, so I did not get it. Installation went well this way.  But:


libelogind0 itself will probably disppear or become a transitional 
package.


So is libelogind0 deprecated then? I could understand that this subset 
of a library may be a bit too much work for the size reduction (I 
witnessed 670kB vs. 930kB, no big deal) and no difference in dependency, 
but I see nowhere that it is abandonned. Did I understand correctly? Or 
is it only Debian that abandon it? May I suggest to put an explaination 
somewhere on the reasons why?



(Sorry for the brevity -- we are away atm)


No problem, thanks for the quick answer.

Regards.
-- Benjamin

Bug#1074374: Fixed upstream

[Apollon Oikonomopoulos]

Control: tags -1 upstream fixed-upstream

This has now been fixed upstream with commit 41275a691 (MEDIUM: init: 
set default for fd_hard_limit via DEFAULT_MAXFD, 2024-07-03).

On a side-note, this was triggered by a recent change in systemd[1], 
which now sets the hard RLIMIT_NOFILE limit to the kernel max value 
(2^30 - 8). HAProxy would then a) bump the soft limit to the hard limit 
and b) in the absence of maxconn/maxsock, use the new (soft) limit to 
calculate how many file descriptors it can possibly hold and size the 
file descriptor table accordingly. This file descriptor table would then 
be allocated and initialized, eating a lot of CPU cycles and GBs of 
memory in the process.

The fix is marked to be backported all the way back to 2.6, so the next 
uploads to unstable will probably be fixed. Until then, as suggested in 
my previous message, users are advised to explicitly set global.maxconn 
to a sane value, especially on testing.

Cheers,
Apollon

[1] https://lists.debian.org/debian-devel/2024/06/msg00041.html

Bug#1075777: RFS: archivemount/1-1 -- mounts an archive or compressed file for access as a filesystem

[наб]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : archivemount
   Version  : 1-1
   Upstream contact : https://lists.sr.ht/~nabijaczleweli/archivemount-ng
 * URL  : https://sr.ht/~nabijaczleweli/archivemount-ng
 * License  : 0BSD, LGPL-2+
 * Vcs  : https://git.sr.ht/~nabijaczleweli/archivemount.deb
   Section  : misc

The source builds the following binary packages:

  archivemount - mounts an archive or compressed file for access as a filesystem

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/archivemount/archivemount_1-1.dsc

Changes since the last upload:

 archivemount (1-1) unstable; urgency=medium
 .
   * New upstream version 1 (+ changelog & NEWS)
 (Closes: #687710, #799563, #832823, #838597, #891749, #974679)
   * New debian/

archivemount is currently maintained by cnanakos@, who agreed to cede it to me.
See attached thread for proof.

The original author and maintainer died irl
(obit 2020-11-27: https://trauer.mt.de/traueranzeigen-suche/andr%C3%A9-landwehr)
and no-one decided to take up regency so far,
so I have decided to fill the power vacuum myself as the new maintainer.
This package is based on my updated upstream.
The old upstream and some other downstreams were also notified of this.

Regards,
-- 
  наб
--- Begin Message ---
Hi!

Currently, both upstream and downstream archivemount are in a sorry state.

Upstream seems to have ended with the death of the maintainer
(presumed around 2020). The TLS in the site in d/watch is broken
(cf. DDPO https://qa.debian.org/developer.php?login=cnanakos%40debian.org 
ERROR),
and there are no commits by him since around 2020. Issues accumulate.

In Debian, #799563 is a grave issue and has a patch from 2015 that
wasn't taken in, I see three "new version" bugs, and most without followups.
It appears you have little interest in this package, so I'd like to
thank you for keeping it in Debian so far and take it off your hands.
This is a package I use (well, will, once I fix it) for my day-to-day work.

For reference, please see my DDPO
  https://qa.debian.org/developer.php?login=nabijaczlew...@nabijaczleweli.xyz
where I've done this exact thing with urlview
(reassembled all known upstreams, all debian patches, some upstream patches
 and fixed all debian bugs, then restructured in-situ to fix more bugs
 and modernise/future-proof the code; the entire debian packaging was
 rederived from scratch).

Best,
наб


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Hi,
yes of course you can. 

Thank you very much for your contribution so far. 

Kind regards. 

> On 14 Jun 2024, at 21:47, наб  wrote:
> 
> Hi!
> 
> Currently, both upstream and downstream archivemount are in a sorry state.
> 
> Upstream seems to have ended with the death of the maintainer
> (presumed around 2020). The TLS in the site in d/watch is broken
> (cf. DDPO https://qa.debian.org/developer.php?login=cnanakos%40debian.org 
> ERROR),
> and there are no commits by him since around 2020. Issues accumulate.
> 
> In Debian, #799563 is a grave issue and has a patch from 2015 that
> wasn't taken in, I see three "new version" bugs, and most without followups.
> It appears you have little interest in this package, so I'd like to
> thank you for keeping it in Debian so far and take it off your hands.
> This is a package I use (well, will, once I fix it) for my day-to-day work.
> 
> For reference, please see my DDPO
>  https://qa.debian.org/developer.php?login=nabijaczlew...@nabijaczleweli.xyz
> where I've done this exact thing with urlview
> (reassembled all known upstreams, all debian patches, some upstream patches
> and fixed all debian bugs, then restructured in-situ to fix more bugs
> and modernise/future-proof the code; the entire debian packaging was
> rederived from scratch).
> 
> Best,
> наб
> 

--- End Message ---
--- Begin Message ---
On Fri, Jun 14, 2024 at 10:14:05PM +0300, Chrysostomos Nanakos wrote:
> yes of course you can. 
Thanks, FYI I uploaded archivemount 1-1
(based on the new archivemount-ng upstream)
to mentors.d.o
  https://mentors.debian.net/package/archivemount/

Best,


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---

Thank you.

On 17/06/2024 04:48, наб wrote:

On Fri, Jun 14, 2024 at 10:14:05PM +0300, Chrysostomos Nanakos wrote:

yes of course you can.

Thanks, FYI I uploaded archivemount 1-1
(based on the new archivemount-ng upstream)
to mentors.d.o
  https://mentors.debian.net/package/archivemount/

Best,
--- End Message ---


signature.asc
Description: PGP signature

Bug#950986: uninstalling cgroupfs-mount wails about sys/fs/cgroup/elogind

[Benjamin Cama]

On Sat, 25 Apr 2020 11:09:14 +0100 Mark Hindley  
wrote:

On Sat, Apr 25, 2020 at 10:09:29AM +0100, Mark Hindley wrote:
> The solution would seem to me for cgroupfs-umount to only try to unmount the
> mountpoints it created, ie those derived from /proc/cgroups.

This patch fixes the issue for me.


Hi, I stumbled on this and this patch fixed it for me too. Thanks Mark.

-- Benjamin

Bug#1066139: podman: Cannot create a network with dns_enabled

[Reinhard Tartler]

Antoine Sirinelli  writes:

> When I create a new custom network, the dns is not enabled:
>
> $ podman network create test
> test
> $ podman network inspect test
> [
>  {
>   "name": "test",
>   "id": 
> "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
>   "driver": "bridge",
>   "network_interface": "cni-podman1",
>   "created": "2024-03-13T00:11:16.769046605+01:00",
>   "subnets": [
>{
> "subnet": "10.89.0.0/24",
> "gateway": "10.89.0.1"
>}
>   ],
>   "ipv6_enabled": false,
>   "internal": false,
>   "dns_enabled": false,
>   "ipam_options": {
>"driver": "host-local"
>   }
>  }
> ]
>
> The outcome should have "dns_enabled" to true.
>
> [...]
>
> podman system reset fixed it.
>
> Thank you for your help,
>

No, thank you for reporting back!

I've added a paragraph to README.Debian pointing to this bug.

Best,
-rt

Bug#1074577: gnat ftbfs with glibc from experimental

[Nicolas Boulenguez]

Source: gcc-13
Followup-For: Bug #1074577

Matthias Klose:
> Simon Chopin came up with a conditional to work with both variants
[before and after glibc introduces __USE_TIME64_REDIRECTS]
> #if defined(__USE_TIME64_REDIRECTS) || (__TIMESIZE == 32 && __USE_TIME_BITS64)

I have forwarded this upstream as version 11.

This changes the libgnat-13 sources (System.OS_Constants).

Most Ada packages will require a bin-NMU after you upload gcc-13,
ideally before people start filling FTBS bug reports.

I take the opportunity to apply some postponed changes.
I do not commit them because I have tested no build,
but the only changes since the (tested) version 10 are
 * the line above, tested by Simon Chopin in Ubuntu
 * unapplying small style changes reviewed by upstream
From: Nicolas Boulenguez 
Subject: [PATCH] Ada: update patches for PR114065 (time_64) to v11

The fix 2bacf86d for #1074577 by Simon Chopin at
https://bugs.launchpad.net/ubuntu/+source/gcc-13/+bug/2071605 requires
a rebuild of all Ada libraries, so we might as well
* update all patches to version 11
* apply the parts fixing bugs, but not the style suggestions
---
 ...ersions-with-C-struct-timeval-from-GN.diff | 143 -
 ...ersions-with-C-struct-timespec-from-A.diff | 167 -
 ...ersions-with-C-time_t-from-System.OS_.diff |  79 ---
 ...imeval-and-timespec-definitions-and-c.diff | 604 ++
 ...-unneeded-x32-variant-of-System.Linux.diff | 146 -
 ...ed-posix2008-variant-of-System.Parame.diff | 229 ---
 ...ed-darwin-solaris-x32-variants-of-Sys.diff | 472 --
 ...sleep-from-System.OS_Primitives.Timed.diff |  74 ---
 ...its-time-functions-from-GNU-libc-when.diff |  74 ++-
 debian/rules.patch|   7 -
 10 files changed, 520 insertions(+), 1475 deletions(-)
 delete mode 100644 debian/patches/0001-Ada-remove-conversions-with-C-struct-timeval-from-GN.diff
 delete mode 100644 debian/patches/0002-Ada-remove-conversions-with-C-struct-timespec-from-A.diff
 delete mode 100644 debian/patches/0003-Ada-remove-conversions-with-C-time_t-from-System.OS_.diff
 delete mode 100644 debian/patches/0005-Ada-drop-unneeded-x32-variant-of-System.Linux.diff
 delete mode 100644 debian/patches/0006-Ada-drop-unneeded-posix2008-variant-of-System.Parame.diff
 delete mode 100644 debian/patches/0007-Ada-drop-unneeded-darwin-solaris-x32-variants-of-Sys.diff
 delete mode 100644 debian/patches/0008-Ada-import-nanosleep-from-System.OS_Primitives.Timed.diff

diff --git a/debian/patches/0001-Ada-remove-conversions-with-C-struct-timeval-from-GN.diff b/debian/patches/0001-Ada-remove-conversions-with-C-struct-timeval-from-GN.diff
deleted file mode 100644
index d57d7ec7..
--- a/debian/patches/0001-Ada-remove-conversions-with-C-struct-timeval-from-GN.diff
+++ /dev/null
@@ -1,143 +0,0 @@
-From bedb7553c420da59938eacb115fd9384e54ceae0 Mon Sep 17 00:00:00 2001
-From: Nicolas Boulenguez 
-Date: Fri, 5 Apr 2024 16:51:54 +0200
-Subject: [PATCH 1/9] Ada: remove conversions with C struct timeval from
- GNAT.Calendar
-

- gcc/ada/doc/gnat_rm/the_gnat_library.rst |  2 -
- gcc/ada/libgnat/g-calend.adb | 58 
- gcc/ada/libgnat/g-calend.ads | 18 
- 3 files changed, 78 deletions(-)
-
-diff --git a/src/gcc/ada/doc/gnat_rm/the_gnat_library.rst b/src/gcc/ada/doc/gnat_rm/the_gnat_library.rst
-index 3aae70a..bcec49f 100644
 a/src/gcc/ada/doc/gnat_rm/the_gnat_library.rst
-+++ b/src/gcc/ada/doc/gnat_rm/the_gnat_library.rst
-@@ -674,8 +674,6 @@ Machine-specific implementations are available in some cases.
- 
- Extends the facilities provided by ``Ada.Calendar`` to include handling
- of days of the week, an extended ``Split`` and ``Time_Of`` capability.
--Also provides conversion of ``Ada.Calendar.Time`` values to and from the
--C ``timeval`` format.
- 
- .. _`GNAT.Calendar.Time_IO_(g-catiio.ads)`:
- 
-diff --git a/src/gcc/ada/libgnat/g-calend.adb b/src/gcc/ada/libgnat/g-calend.adb
-index 0a98eb2..e0d34f5 100644
 a/src/gcc/ada/libgnat/g-calend.adb
-+++ b/src/gcc/ada/libgnat/g-calend.adb
-@@ -29,11 +29,8 @@
- --  --
- --
- 
--with Interfaces.C.Extensions;
--
- package body GNAT.Calendar is
-use Ada.Calendar;
--   use Interfaces;
- 
--
--- Day_In_Year --
-@@ -328,61 +325,6 @@ package body GNAT.Calendar is
-Time_Zone=> 0);
-end Time_Of_At_Locale;
- 
--   -
--   -- To_Duration --
--   -
--
--   function To_Duration (T : not null access timeval) return Duration is
--
--  procedure timeval_to_duration
--(T: not null access timeval;
-- sec  : not null access C.Extensions.long_long;
-- usec : not null access C.long);
--  pragma Import (C, timeval_to_duration, "__gnat_timeval_to_duration");
--
--  Micro : constant := 10**6;
--  sec

Bug#1075778: ITP: python-asv-bench-memray -- Memray benchmark plugin for asv

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, y...@debian.org

* Package name: python-asv-bench-memray
  Version : 0.1.2
  Upstream Contact: Rohit Goswami 
* URL : https://github.com/HaoZeke/asv_bench_memray
* License : Expat
  Programming Lang: Python
  Description : Memray benchmark plugin for asv

This a proof-of-concept externally defined memray benchmark
 plugin for asv. Like all externally defined benchmark plugins
 for asv, this has a strict hierarchy. The package name begins
 with asv_bench. Benchmarks are defined in a benchmarks folder
 under the package module. Each exported new benchmark type has
 the export_as_benchmark = [NAMEBenchmark] attribute. I planned
 to maintain it under DPT.

Bug#894906: linux-cpupower: provide a systemd service and a default config file

[Francesco Poli]

On Sat, 15 Jun 2024 16:48:58 +0200 Francesco Poli wrote:

[...]
> Please find attached the three updated files.
> 
> Tested on one of my systems, where I purged cpufrequtils and installed
> linux-cpupower and then I issued the following commands:
> 
>   # install -m 644 cpupower.default /etc/default/cpupower
>   # install -m 755 cpupower.sh /usr/libexec/cpupower
>   # install -m 644 cpupower.service /usr/lib/systemd/system/
>   # systemctl daemon-reload
>   # systemctl enable cpupower.service
> 
> The systemd service runs at boot and sets everything needed with
> cpupower (as configured in /etc/default/cpupower ).

I am now using these three files on two distinct systems: they work as
intended, with no issues at all.

> 
> Once again, please accept the "patch" and incorporate the files (or
> further enhanced versions of them) into linux-cpupower.

Have you had a chance to take a look at the three files I sent?
Could you test them?

I really hope they can soon be incorporated into the official
linux-cpupower Debian package...

> 
> Thanks for your time and dedication!
> Bye.

Again thanks for reading so far and for your consideration.


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


pgpIz092QQPIk.pgp
Description: PGP signature

Bug#730111: Still present in 2.1.3-1

[Pavel Sanda]

On Thu, 2 Feb 2023 14:08:19 +0100 Pavel Sanda  wrote:
> On Fri, 4 Dec 2020 21:24:23 +0100 Pavel Sanda  wrote:
> > On Wed, 18 Mar 2015 12:28:48 +0100 Alexander Stiebing 
> >  wrote:
> > > Bug still like described in Nov. 2013, none of the proposed actions out
> > > of the comments have been done.
> >
> > The change of the message to be more informative will be fixed in lyx 2.3.7 
> > & 2.4.
> > https://www.lyx.org/trac/changeset/b670990bc12fe1dd1d9d7b5fa8258a32caa7e91a/lyxgit
> >
> > Moving RCS from suggested to Recommends look reasonable to me.
> > After that the bug can be closed.
> 
> Dear Tobias,
> 
> what is your take on this?
> 2.3.7 with fixed error handling is now in bookworm.
> - Either this is enough and we close the bug as wontfix
> - or we add RCS as Recommended and this is the right time to do it.
> 
> I do not have strong opinion, what is your take on this?

As the error message is fixed within 2.4, the dependency
isn't critical anymore and I will close it as wontfix.

Pavel