date:20220901

On 2022-09-02 00:03:22 +0200, Drew Parsons wrote:
> On 2022-09-01 23:32, Sebastian Ramacher wrote:
> > > 
> > > Lower level libraries are uploaded.  We'll want mumps level 2 built to
> > > prepare trilinos for the petsc build.
> > 
> > Scheduled mumps level 2 (except trilinos)
>^^^
> 
> Wait no, it's trilinos that I'm waiting for! petsc needs it.

Scheduled

Cheers
-- 
Sebastian Ramacher

Bug#1010961: reverse dependency

2022-09-01 Thread Antonio Valentino


Dear Thorsten,

On Sat, 25 Jun 2022 11:30:47 +0200 Thorsten Alteholz 
 wrote:

Hi Antonio,

there is a reverse dependency that needs to be taken care of:

Checking reverse dependencies...
# Broken Depends:
pysph: pysph-viewer


This needs to be addressed first. Please remove the moreinfo tag once 
that is done.


   Thorsten

pysph-viewer needs to be removed form unstable [ppc64 s390x] as well.
There is another ticker open for that: #1015009.

Sorry probably I messed a bit with this issue.

regards
--
Antonio Valentino

Bug#1018930: pcs: CVE-2022-2735: Obtaining an authentication token for hacluster user leads to privilege escalation

2022-09-01 Thread Salvatore Bonaccorso

Source: pcs
Version: 0.11.3-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.10.8-1

Hi,

The following vulnerability was published for pcs.

CVE-2022-2735[0]:
| Obtaining an authentication token for hacluster user leads to
| privilege escalation

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-2735
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2735
[1] https://www.openwall.com/lists/oss-security/2022/09/01/4

Regards,
Salvatore

Bug#1018928: libretro-snes9x: src:libretro-snes9x New upstream version 1.60 available.

Control: tags 1018928 -patch
Control: close 1018927 

Bug # confused me, so I was looking at the wrong homepage all the time.
So I'm correcting this now:
- the watch file is not valid. removing patch tag
- the new version is not there, closing this bug.


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1018929: libretro-snes9x: Hompage field points to snesn9x, not to libretro-snes9x

Source: libretro-snes9x
Version: 1.53+git20160522-1
Severity: normal

It seems that this should be in the Homepage field:
https://github.com/libretro/snes9x



-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#643595: ITP: snes9x -- Cross-platform SNES emulator

Control: close -1
Conrtol: archive -1


As this bug is only attracting spam and there is no activity on the topic, I 
close that bug
It can be reopened if needed.

Bug#1018928: src:libretro-snes9x: Please add a watch file

Source: libretro-snes9x
Version: 1.53+git20160522-1
Severity: wishlist
Tags: patch newcomer

As the title says.

The attached watch file at least now finds 1.60 correcty.



-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
version=4

https://sites.google.com/site/bearoso 
bearoso/snes9x/snes9x-(.+)\.(?:tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))).*

Bug#1018927: libretro-snes9x: src:libretro-snes9x New upstream version 1.60 available.

Source: libretro-snes9x
Version: 1.53+git20160522-1
Severity: normal

Dear maintainer

https://sites.google.com/site/bearoso/ has 1.60

Please consider packaging it.

Thanks!

1

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#919697: arcanist: file conflict with arc

2022-09-01 Thread Sylvestre Ledru


Le 02/09/2022 à 01:10, Guillem Jover a écrit :

Hi!

On Wed, 2022-08-10 at 01:29:27 +0200, Guillem Jover wrote:

[ The bug has been (correctly) bumped back to serious. Sorry that I
   have not engaged about this bug in the past, but the reply to simply
   ignore policy looked rather off-putting, I just noticed the reply
   below, which seemed encouraging! :) ]

On Sat, 2019-01-26 at 11:20:13 +0100, Sylvestre Ledru wrote:

As we shipped the previous release with this bug, we are close to
the freeze and there is not easy fix,
I propose that we fix this issue for the next stable release.


Could you please rename the archanist /usr/bin/arc into
/usr/bin/arcanist? Or if that's not feasible, then stop installing the
symlink in PATH, and document that users might want to add the /usr/share
/arcanist/bin/ into their own PATH? Or do both?

Renaming the binary from the arc package, which matches the package
name itself, seems unfair, as it has existed upstream and has been in
the Debian archive for way way longer, and in addition the idea of
potentially having a binary package arc with a non-arc program, and
arcanist providing an arc program seems rather confusing and just
wrong. :)

Otherwise, all these package will get removed in the coming days. So I'd
also appreciate if you could reassign these bugs to arcanist.


So we have reached the point at which arc is getting autoremoved from
testing as the RC is still filed against it too. :(

Could some arcanist maintainer please check this, and ideally agree to
reassign this bug to arcanist? If necessary I'm willing to prepare a
patch for arcanist to stop installing as bin/arc, as described above,
if this would expedite things.


I don't think renaming is the right approach against an MS-DOS software (and I 
still think
that Debian's policy is too binary for this).

However, as:
* phabricator is dying
* Richard, Christoph and myself didn't show a strong interest to keep it alive 
(it is currently broken in unstable).

Please do what you want. ;)

Cheers
Sylvestre

Bug#1018926: src:meson: fails to migrate to testing for too long: unresolved RC bug

2022-09-01 Thread Paul Gevers


Source: meson
Version: 0.62.2-1
Severity: serious
Control: close -1 0.63.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1017087

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018925: src:hslogger: fails to migrate to testing for too long: part of unfinshed ghc transition?

2022-09-01 Thread Paul Gevers


Source: hslogger
Version: 1.3.1.0-1
Severity: serious
Control: close -1 1.3.1.0+dfsg-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018881: glibc: iconv not working properly on m68k and sh4

2022-09-01 Thread John Paul Adrian Glaubitz


Hi!

On 9/1/22 23:59, Aurelien Jarno wrote:

The problem is that the
/usr/lib/m68k-linux-gnu/gconv/gconv-modules.cache file is somehow
truncated for the glibc 2.34 build. Running iconvconfig by hand to
generate it fixes the issue.

It seems to be the right size for the glibc 2.35 build.


Yes, running iconvconfig manually fixes the problem indeed. Now I just
need to figure out why the file is truncated in the first place.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1018924: libgc FTBFS: architecture-specific symbol handling removed

2022-09-01 Thread Helmut Grohne

Source: libgc
Version: 1:8.2.2-1
Severity: serious
Tags: ftbfs

Hi,

what happend to libgc? It ftbfs on all 32bit architectures and its
symbol handling is essentially stripped of all the architecture-specific
patterns that we have accumulated over the years.

The general quality of the upload seems questionable as well:
 * A possibly breaking change for a core package is often done to
   experimental first to reduce disruption of development on unstable.
   Doing so would have prevented major pain here.
 * The debian/changelog entry contains duplicates.
 * Lots of symbols were dropped from the symbols file without bumping
   soname. Possibly, this may lead to incorrect dependencies on libgc in
   downstream builds.
 * debian/changelog says that you removed libatomic_ops handling, but
   for every new architecture libatomic_ops is still opted in leading to
   unnecessary porting work even though built-in atomics generally work
   well.

I am also wondering whether this actually is a package hijack as there
is no visible acknowledgement from any existing maintainers to adding
Ian to uploaders.

I am quite disappointed by this upload and the downstream pain it causes
to QA.

Helmut

Bug#1018923: libcrypto++ FTCBFS: rebuilds with the build architecture compiler during make install

2022-09-01 Thread Helmut Grohne

Source: libcrypto++
Version: 8.7.0+git220824-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libcrypto++ fails to cross build from source, because it uses the build
architecture compiler. This happens during dh_auto_install after
successfully building the entire thing successfully with dh_auto_build.
Unlike dh_auto_build, dh_auto_install does not pass cross tools to make,
but libcrypto++ needs to build things there for some reason. The easy
way is to have dpkg's buildtools.mk export cross tools for all targets.
Please consider applying the attached patch to make libcrypto++ cross
buildable.

Helmut
--- libcrypto++-8.7.0+git220824/debian/changelog
+++ libcrypto++-8.7.0+git220824/debian/changelog
@@ -1,3 +1,10 @@
+libcrypto++ (8.7.0+git220824-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Export build tools for all targets. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 01 Sep 2022 18:01:18 +0200
+
 libcrypto++ (8.7.0+git220824-1) unstable; urgency=medium
 
   * New git snapshot release.
--- libcrypto++-8.7.0+git220824/debian/rules
+++ libcrypto++-8.7.0+git220824/debian/rules
@@ -4,11 +4,12 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 DOC_PKG_DIR = $(CURDIR)/debian/libcrypto++-doc/
 
 
+DPKG_EXPORT_BUILDTOOLS=1
 include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
 
 ifneq ($(filter $(DEB_HOST_ARCH),armel powerpc),)
 export DEB_LDFLAGS_MAINT_APPEND= -latomic

Bug#1018369: git-cola: build-depends on python3-nose or uses it for autopkgtest

2022-09-01 Thread David Aguilar

Hi Dmitriy,

We don't depend on nose these days. We dropped that dependency
upstream a while back in favor of pytest.

The debian packaging probably needs to drop the dependency.

Thanks!


On Sun, Aug 28, 2022 at 11:41 AM Dmitry Shachnev  wrote:
>
> Source: git-cola
> Version: 3.12.0-1
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: nose-rm
>
> Dear Maintainer,
>
> Your package still uses nose [1], which is an obsolete testing framework for
> Python, dead and unmaintained since 2015 [2][3].
>
> If you received this bug report, it means that your package either has a
> build-dependency on python3-nose or uses that package in debian/tests/control.
> If that is not the case, please reply and CC me explicitly.
>
> Please port your package to one of the alternatives: nose2 [4], pytest [5]
> or unittest from Python standard library [6].
>
> There is a script called nose2pytest [7] which can assist with migrating from
> nose to pytest.
>
> This mass bug filing was discussed on debian-devel in [8].
>
> [1]: https://tracker.debian.org/pkg/nose
> [2]: https://github.com/nose-devs/nose/commit/0f40fa995384afad
> [3]: https://pypi.org/project/nose/#history
> [4]: https://docs.nose2.io/en/latest/
> [5]: https://docs.pytest.org/en/latest/
> [6]: https://docs.python.org/3/library/unittest.html
> [7]: https://github.com/pytest-dev/nose2pytest
> [8]: https://lists.debian.org/debian-devel/2022/08/msg00184.html
>
> --
> Dmitry Shachnev
>


--
David

Bug#1018922: kbibtex crashes on startup

2022-09-01 Thread Arnout Boelens

Package: kbibtex
Version: 0.9.90-1+b1
Severity: grave
Justification: renders package unusable

Backtrace

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe5fff640 (LWP 150852)]
[New Thread 0x7fffe563b640 (LWP 150853)]
[New Thread 0x7fffdcdff640 (LWP 150855)]
[New Thread 0x7fffd15ff640 (LWP 150856)]
[New Thread 0x7fffd0dfe640 (LWP 150857)]
[New Thread 0x7fffcbfff640 (LWP 150858)]
[New Thread 0x7fffcb7fe640 (LWP 150859)]
[New Thread 0x7fffb7473640 (LWP 150860)]
[New Thread 0x7fffb6c72640 (LWP 150861)]
[New Thread 0x7fffb6471640 (LWP 150862)]
[New Thread 0x7fffb5c70640 (LWP 150863)]
[New Thread 0x7fffb546f640 (LWP 150865)]

Thread 1 "kbibtex" received signal SIGSEGV, Segmentation fault.
0x77bbfbac in FileModel::element (this=0x0, row=0) at 
./src/data/models/filemodel.cpp:388
#0  0x77bbfbac in FileModel::element (this=0x0, row=0) at 
./src/data/models/filemodel.cpp:388
#1  0x77f1dafd in SortFilterFileModel::filterAcceptsRow 
(this=0x573c4560, source_row=, source_parent=...) at 
./src/gui/file/sortfilterfilemodel.cpp:147
#2  0x7607e6d6 in QSortFilterProxyModelPrivate::create_mapping 
(this=this@entry=0x573c58b0, source_parent=...) at 
itemmodels/qsortfilterproxymodel.cpp:504
#3  0x76088504 in QSortFilterProxyModel::setSourceModel 
(this=0x573c4560, sourceModel=) at 
itemmodels/qsortfilterproxymodel.cpp:2152
#4  0x77f1efe1 in SortFilterFileModel::setSourceModel 
(this=this@entry=0x573c4560, model=0x573c5620) at 
./src/gui/file/sortfilterfilemodel.cpp:39
#5  0x7fffc802cc04 in KBibTeXPart::KBibTeXPartPrivate::openFile 
(this=this@entry=0x57339c70, url=..., localFilePath=...) at 
./src/parts/part.cpp:385
#6  0x7fffc80247d0 in KBibTeXPart::openFile (this=0x572f0790) at 
./src/parts/part.cpp:956
#7  0x77b23355 in KParts::ReadOnlyPartPrivate::openLocalFile 
(this=this@entry=0x5733f470) at ./src/readonlypart.cpp:180
#8  0x77b2441e in KParts::ReadOnlyPart::openUrl (this=0x572f0790, 
url=...) at ./src/readonlypart.cpp:141
#9  0x555ac42f in OpenFileInfo::OpenFileInfoPrivate::createPart 
(this=0x55a42550, newWidgetParent=0x558fe280, newServicePtr=...) at 
./src/program/openfileinfo.cpp:138
#10 0x555aae64 in OpenFileInfo::part (this=this@entry=0x55d78d90, 
parent=parent@entry=0x558fe280, servicePtr=...) at 
./src/program/openfileinfo.cpp:262
#11 0x555840ee in MDIWidget::setFile (this=0x558fe280, 
openFileInfo=0x55d78d90, servicePtr=...) at ./src/program/mdiwidget.cpp:255
#12 0x5557deab in QtPrivate::FunctorCall, 
QtPrivate::List >, void, 
void (MDIWidget::*)(OpenFileInfo*, 
QExplicitlySharedDataPointer)>::call (arg=, 
o=, f=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:152
#13 QtPrivate::FunctionPointer)>::call >, void> (arg=, 
o=, f=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:185
#14 QtPrivate::QSlotObject), QtPrivate::List >, void>::impl (which=, 
this_=, r=, a=, ret=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:418
#15 0x760e89af in QtPrivate::QSlotObjectBase::call (a=0x7fffd630, 
r=0x558fe280, this=0x572ce050) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#16 doActivate (sender=0x55d889e0, signal_index=3, 
argv=0x7fffd630) at kernel/qobject.cpp:3886
#17 0x760e1d6f in QMetaObject::activate 
(sender=sender@entry=0x55d889e0, m=m@entry=0x555c5fe0 
, 
local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fffd630) 
at kernel/qobject.cpp:3946
#18 0x555772a4 in OpenFileInfoManager::currentChanged 
(this=this@entry=0x55d889e0, _t1=, _t1@entry=0x55d78d90, 
_t2=...) at 
./obj-x86_64-linux-gnu/src/program/kbibtex_autogen/EWIEGA46WW/moc_openfileinfo.cpp:280
#19 0x555a904c in OpenFileInfoManager::setCurrentFile 
(this=0x55d889e0, openFileInfo=openFileInfo@entry=0x55d78d90, 
servicePtr=...) at ./src/program/openfileinfo.cpp:713
#20 0x555a929b in operator() (__closure=0x55d76be0) at 
./src/program/openfileinfo.cpp:522
#21 QtPrivate::FunctorCall, QtPrivate::List<>, void, 
OpenFileInfoManager::OpenFileInfoManager(QObject*):: >::call 
(arg=, f=...) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:146
#22 
QtPrivate::Functor,
 0>::call, void> (arg=, f=...) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:256
#23 
QtPrivate::QFunctorSlotObject,
 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject 
*, void **, bool *) (which=, this_=0x55d76bd0, r=, a=, ret=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:443
#24 0x760ec852 in QtPrivate::QSlotObjectBase::call (a=0x7fffd710, 
r=, this=) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#25 QSingleShotTimer::timerEvent (this=0x55a423d0) at ke

Bug#1006682: /usr/lib/cmake/mathgl2/MathGL2Config.cmake: Could NOT find OpenMP_CXX

2022-09-01 Thread Rafael Laboissière


Control: tags -1 - moreinfo
Control: tags -1 + wontfix

* Sylvain Joubert  [2022-08-31 10:17]:

Ok, I just figured out why you probably can't reproduce the issue: you need 
to use clang as a compiler. 
If you use `CXX=clang++-14 cmake [...]` as a configure command line you'll 
likely trigger the error.


Thanks for this additional information. I can now reproduce the bug, 
which is not triggered when using CXX=g++.


And the required package providing OpenMP for clang must match the clang 
version used: if I install libomp-13-dev while using clang++-14 for example 
I'll still get the error.


With this additional info I get that the issue is triggered with a 
non-default setup, so I'm not sure how or even if it can be fixed 
correctly. Especially given that the proper dependency is heavily dependent 
on the clang version used/installed. 
Given that understanding I'd be fine with leaving things as is. And maybe 
it's the upstream MathGL2Config.cmake that needs a rework to deal more 
easily with various setups.


I am not sure whether the issue can be fixed in a trivial way. I am 
hereby tagging this bug report "wontfix", for now.


Best,

Rafael Laboissière

Bug#1018881: glibc: iconv not working properly on m68k and sh4

2022-09-01 Thread Stefan Reinauer

Only the japanese locales are not working? Are they missing?

On Thu, Sep 1, 2022 at 6:45 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Source: glibc
> Version: 2.34-7
> Severity: normal
> User: debian-sup...@lists.debian.org
> Usertags: m68k sh4
> X-Debbugs-Cc: debian-...@lists.debian.org,debian-sup...@lists.debian.org
>
> Hello!
>
> iconv stopped working on m68k and sh4 starting with glibc 2.34 and
> I have no clue why. The issue can be reproduced on real hardware
> qemu-user and qemu-system.
>
> The problem becomes visible when the configure script of the gettext
> package is being run on the affected architectures:
>
> checking for iconv... yes
> checking for working iconv... no
> checking for iconv declaration...
>  extern size_t iconv (iconv_t cd, char * *inbuf, size_t
> *inbytesleft, char * *outbuf, size_t *outbytesleft);
> checking for inttypes.h... (cached) yes
> checking for limits.h... (cached) yes
>
> The configure script runs a small program which I have extracted and
> attached to this bug report as iconv.c.
>
> Running it on amd64 returns a zero exit code:
>
> (sid-amd64-sbuild)root@nofan:/# gcc -o iconv iconv.c -lc
> (sid-amd64-sbuild)root@nofan:/# ./iconv
> (sid-amd64-sbuild)root@nofan:/# echo $?
> 0
> (sid-amd64-sbuild)root@nofan:/#
>
> On m68k and sh4, the exit code is 16 which is why the above configure
> check fails:
>
> glaubitz@tirpitz:~$ uname -a
> Linux tirpitz 5.11.0-rc4-00012-g10c03c5bf422 #161 PREEMPT Mon Jan 18
> 21:10:17 CET 2021 sh4a GNU/Linux
> glaubitz@tirpitz:~$ gcc -o iconv iconv.c -lc
> glaubitz@tirpitz:~$ ./iconv
> glaubitz@tirpitz:~$ echo $?
> 16
> glaubitz@tirpitz:~$
>
> I have run out of ideas why iconv fails, so I was wondering whether this
> might
> be a packaging issue. I have found a similar iconv issue being discussed
> on a
> Fedora mailing list where the cause was iconv data being moved out of the
> main
> glibc packages [1].
>
> Maybe we have a similar problem in Debian which manifests on m68k and sh4
> only
> due to some reverse dependencies being out of date?
>
> Thanks,
> Adrian
>
> > [1]
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/IWAOAD6XXXAPBQZ364OKVBZZXDDHG2KS/
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Bug#1018920: zsh: default bindings set to vi if "vi" appears in a directory name from $VISUAL or $EDITOR

2022-09-01 Thread Vincent Lefevre

Package: zsh
Version: 5.9-1
Severity: normal
Tags: upstream patch
Forwarded: https://www.zsh.org/mla/workers/2022/msg00888.html

On some of my machines, I have $VISUAL and $EDITOR set to
"/home/vinc17/bin/eclient", and because the "vi" sequence
appears in this string (here, in my username), zsh thinks
that I use vi and selects the vi bindings.

I've attached Bart Schaefer's patch from

  https://www.zsh.org/mla/workers/2022/msg00889.html

so that only the part after the last "/" is considered (this
is better than the current code and probably OK in practice,
though it could still match command options if any).

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++--===--===
ii  bubblewrap   0.6.2-1 amd64utility for unprivileged 
chroot and namespace manipulation
ii  curl 7.84.0-2amd64command line tool for 
transferring data with URL syntax
ii  dpkg-dev 1.21.9  all  Debian package 
development tools
ii  git-extras   6.4.0-1 all  Extra commands for git
ii  mercurial-common 6.2-1   all  easy-to-use, scalable 
distributed version control system (common files)
ii  meson0.63.1-1all  high-productivity build 
system
ii  ninja-build  1.11.0-1amd64small build system 
closest in spirit to Make
ii  pass 1.7.4-5 all  lightweight 
directory-based password manager
ii  pulseaudio-utils 15.0+dfsg1-4+local1 amd64Command line tools for 
the PulseAudio sound server
ii  qpdf 10.6.3-1amd64tools for transforming 
and inspecting PDF files
ii  systemd  251.4-1 amd64system and service manager
ii  udev 251.4-1 amd64/dev/ and hotplug 
management daemon
ii  vlc-bin  3.0.17.4-3  amd64binaries from VLC
ii  youtube-dl   2021.12.17-1all  downloader of videos from 
YouTube and other sites
ii  zathura  0.4.9-1 amd64document viewer with a 
minimalistic interface

The following files were modified:

/etc/systemd/logind.conf
/etc/systemd/system.conf
/etc/systemd/journald.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh depends on:
ii  libc6   2.34-7
ii  libcap2 1:2.44-1
ii  libtinfo6   6.3+20220423-2
ii  zsh-common  5.9-1

Versions of packages zsh recommends:
ii  libncursesw6  6.3+20220423-2
ii  libpcre3  2:8.39-14

Versions of packages zsh suggests:
ii  zsh-doc  5.9-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff --git a/Src/Zle/zle_keymap.c b/Src/Zle/zle_keymap.c
index d90838f03..8e5ad3fa2 100644
--- a/Src/Zle/zle_keymap.c
+++ b/Src/Zle/zle_keymap.c
@@ -1454,8 +1454,8 @@ default_bindings(void)
 linkkeymap(oppmap, "viopp", 0);
 linkkeymap(vismap, "visual", 0);
 linkkeymap(smap, ".safe", 1);
-if (((ed = zgetenv("VISUAL")) && strstr(ed, "vi")) ||
-	((ed = zgetenv("EDITOR")) && strstr(ed, "vi")))
+if (((ed = zgetenv("VISUAL")) && strstr(ed, "vi") > rindex(ed, '/')) ||
+	((ed = zgetenv("EDITOR")) && strstr(ed, "vi") > rindex(ed, '/')))
 	linkkeymap(vmap, "main", 0);
 else
 	linkkeymap(emap, "main", 0);

Bug#1018919: coreutils: stty: default/-a output for characters wrong for disabled ones

2022-09-01 Thread наб

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

Dear Maintainer,

Quoth POSIX Issue 7, XCU, stty, STDOUT, last paragraph:
-- >8 --
If control characters are written as part of the default output,
or if the -a option is specified,
control characters shall be written as:

"%s = %s;", , 

where  is either the character,
or some visual representation of the character if it is non-printable,
or the string undef if the character is disabled.
-- >8 --
(crucially, i.a., "undef" is italicised, and "the string I[undef]"
 matches the rest of the page,
 cf. OPERANDS, Special Control Character Assignments).

This unequivocally means
"if stty kill undef, then stty -a must have »kill = undef;«" (&c.),
but:
-- >8 --
$ stty -a | grep =
speed 38400 baud; rows 54; columns 172; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-- >8 --

What's worse, stty eol '' doesn't recognise  as an alias
for undef.

Best,
наб

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

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

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

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#964008: heimdal-kdc: kadmind unusable in default configuration, looks for m-key in the wrong path

> Debian places the key in /var/lib/heimdal-kdc/heimdal.mkey, and the
> comments in /etc/heimdal-kdc/kdc.conf state that this is the default
> location. Adding the path explicitly in the config file had no effect,
> so I suspect kadmind has the path hardcoded somewhere.


See #868638, where it was found that we had to use
/var/lib/heimdal-kdc/heimdal.mkey not /var/lib/heimdal-kdc/m-key

I am guessing that the default must have changed somewhere.
-- 
Brian May

Bug#1018918: Please Consider Building the stub_status module

2022-09-01 Thread Matt Corallo


Package: src:nginx
Version: 1.22.0-3

The http_stub_status module is not built by default but is useful to monitor a running server. In 
fact, another package (prometheus-nginx-exporter) relies on stub_status to operate. Please consider 
building it as an optional package as with other nginx modules.

Bug#1018894: rescue-mode: mounts wrong btrfs subvolume

2022-09-01 Thread Steve McIntyre

On Thu, Sep 01, 2022 at 06:04:08PM +0200, Ansgar wrote:
>Source: rescue
>Version: 1.85
>Severity: important
>
>I've installed a system using btrfs for the root filesystem with d-i
>(with disk encryption as well). As grub wasn't properly installed
>(not registered with EFI), I tried to use the rescue mode to reinstall
>grub.
>
>However, mounting the root filesystem failed: /target contained only a
>"@rootfs" subdirectory. So running a shell in the target fs failed.
>Manually mounting the filesystem with `-o subvol=@rootfs` worked.
>
>This was with Debian 11.4.

Argh. btrfs is a total PITA with all the extra options like
subvolumes. To support this everywhere in the installer, we need the
help of people who care about btrfs, use it themselves and understand
all the options. I don't count on any of those, and I'm not sure KiBi
does either.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden

Bug#1018917: gnss-sdr ftbfs on riscv64

2022-09-01 Thread Steve Langasek

Package: gnss-sdr
Version: 0.0.17-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Carles,

The gnss-sdr source package is failing to build from source in Debian and
Ubuntu due to a failure to detect lapack support:

[...]
-- Found BLAS: /usr/lib/riscv64-linux-gnu/libblas.so  
-- Looking for cheev_
-- Looking for cheev_ - not found
-- Could NOT find LAPACK (missing: LAPACK_LIBRARIES) 
 The LAPACK library has not been found.
 You can try to install it by typing:
 sudo apt-get install liblapack-dev
CMake Error at CMakeLists.txt:1850 (message):
  LAPACK is required to build gnss-sdr
[...]

  
(https://buildd.debian.org/status/fetch.php?pkg=gnss-sdr&arch=riscv64&ver=0.0.17-1%2Bb4&stamp=1661681286&raw=0)

The cause of this build failure is subtle; I believe ultimately there is a
toolchain bug here on riscv64, but the problem can be worked around by
adding a Build-Conflict with libopenblas-dev, as in the attached patch. 
libopenblas-dev is being pulled in as a preferred alternative by
libsuperlu-dev, but it's not the version of blas that any of the dependent
packages are built against, and avoiding it fixes this build failure.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gnss-sdr-0.0.17/debian/control gnss-sdr-0.0.17/debian/control
--- gnss-sdr-0.0.17/debian/control  2022-06-12 23:16:19.0 -0700
+++ gnss-sdr-0.0.17/debian/control  2022-09-01 16:32:05.0 -0700
@@ -32,6 +32,7 @@
pkg-config,
protobuf-compiler,
python3-mako
+Build-Conflicts: libopenblas-dev
 Standards-Version: 4.6.0
 Homepage: https://gnss-sdr.org
 Vcs-Browser: https://salsa.debian.org/debian-hamradio-team/gnss-sdr

Bug#1018916: xdp-tools: FTBFS with libbpf 1.0.0

Package: xdp-tools
Version: 1.2.6-2
Severity: important
Tags: ftbfs
X-Debbugs-Cc: sudipm.mukher...@gmail.com
Usertags: libbpf1

Dear Maintainer,

xdp-tools FTBFS with libbpf 1.0.0 (available in experimental).
This is the first error from the build log:

   dh_auto_configure
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking
Found clang binary 'clang' with version 14 (from 'Debian clang version 
14.0.6-2')
libbpf support: FORCE_SYSTEM_LIBBPF is set, but no usable libbpf found on system
error: In file included from config.TN0geB/libbpftest.c:3:
/usr/include/bpf/btf.h: In function 'btf_enum64_value':
/usr/include/bpf/btf.h:496:25: error: invalid use of undefined type 'const 
struct btf_enum64'
  496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
  | ^~
/usr/include/bpf/btf.h:496:46: error: invalid use of undefined type 'const 
struct btf_enum64'
  496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
  |  ^~
dh_auto_configure: error: ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking returned exit code 1


-- 
Regards
Sudip

Bug#1018915: v4l-utils: FTBFS with libbpf 1.0.0

Package: v4l-utils
Version: 1.22.1-4
Severity: important
Tags: ftbfs
X-Debbugs-Cc: sudipm.mukher...@gmail.com
Usertags: libbpf1

Dear Maintainer,

v4l-utils FTBFS with libbpf 1.0.0 (available in experimental).
This is the first error from the build log:

bpf_load.c: In function 'load_and_attach':
bpf_load.c:66:38: error: storage size of 'load_attr' isn't known
   66 | struct bpf_load_program_attr load_attr;
  |  ^
bpf_load.c:69:38: error: invalid application of 'sizeof' to incomplete type 
'struct bpf_load_program_attr'
   69 | memset(&load_attr, 0, sizeof(struct bpf_load_program_attr));
  |  ^~
bpf_load.c:78:14: warning: implicit declaration of function 
'bpf_load_program_xattr' [-Wimplicit-function-declaration]
   78 | fd = bpf_load_program_xattr(&load_attr, bpf_log_buf, 
LOG_BUF_SIZE);
  |  ^~
bpf_load.c:66:38: warning: unused variable 'load_attr' [-Wunused-variable]
   66 | struct bpf_load_program_attr load_attr;
  |  ^
bpf_load.c: In function 'build_raw_map':
bpf_load.c:113:14: warning: implicit declaration of function 
'bpf_create_map_node' [-Wimplicit-function-declaration]
  113 | fd = bpf_create_map_node(map->def.type,
  |  ^~~
bpf_load.c: In function 'load_maps':
bpf_load.c:179:47: warning: implicit declaration of function 
'bpf_create_map_in_map_node' [-Wimplicit-function-declaration]
  179 | bpf_file->map_fd[i] = 
bpf_create_map_in_map_node(
  |   ^~

-- 
Regards
Sudip

Bug#919697: arcanist: file conflict with arc

2022-09-01 Thread Guillem Jover

Hi!

On Wed, 2022-08-10 at 01:29:27 +0200, Guillem Jover wrote:
> [ The bug has been (correctly) bumped back to serious. Sorry that I
>   have not engaged about this bug in the past, but the reply to simply
>   ignore policy looked rather off-putting, I just noticed the reply
>   below, which seemed encouraging! :) ]
> 
> On Sat, 2019-01-26 at 11:20:13 +0100, Sylvestre Ledru wrote:
> > As we shipped the previous release with this bug, we are close to
> > the freeze and there is not easy fix,
> > I propose that we fix this issue for the next stable release.
> 
> Could you please rename the archanist /usr/bin/arc into
> /usr/bin/arcanist? Or if that's not feasible, then stop installing the
> symlink in PATH, and document that users might want to add the /usr/share
> /arcanist/bin/ into their own PATH? Or do both?
> 
> Renaming the binary from the arc package, which matches the package
> name itself, seems unfair, as it has existed upstream and has been in
> the Debian archive for way way longer, and in addition the idea of
> potentially having a binary package arc with a non-arc program, and
> arcanist providing an arc program seems rather confusing and just
> wrong. :)
> 
> Otherwise, all these package will get removed in the coming days. So I'd
> also appreciate if you could reassign these bugs to arcanist.

So we have reached the point at which arc is getting autoremoved from
testing as the RC is still filed against it too. :(

Could some arcanist maintainer please check this, and ideally agree to
reassign this bug to arcanist? If necessary I'm willing to prepare a
patch for arcanist to stop installing as bin/arc, as described above,
if this would expedite things.

Thanks,
Guillem

Bug#1018914: suricata: FTBFS with libbpf 1.0.0

Package: suricata
Version: 1:6.0.6-1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: sudipm.mukher...@gmail.com
Usertags: libbpf1

Dear Maintainer,

suricata FTBFS with libbpf 1.0.0 (available in experimental).
This is the first error from the build log:

util-ebpf.c: In function 'EBPFLoadFile':
util-ebpf.c:375:17: error: implicit declaration of function 
'bpf_program__set_socket_filter'; did you mean 'bpf_program__set_log_level'? 
[-Werror=implicit-function-declaration]
  375 | bpf_program__set_socket_filter(bpfprog);
  | ^~
  | bpf_program__set_log_level
util-ebpf.c:377:17: error: implicit declaration of function 
'bpf_program__set_xdp'; did you mean 'bpf_program__set_type'? 
[-Werror=implicit-function-declaration]
  377 | bpf_program__set_xdp(bpfprog);
  | ^~~~
  | bpf_program__set_type


-- 
Regards
Sudip

Bug#1018913: qemu: FTBFS with libbpf 1.0.0

Package: qemu
Version: 1:7.0+dfsg-7
Severity: important
Tags: ftbfs
X-Debbugs-Cc: sudipm.mukher...@gmail.com
Usertags: libbpf1

Dear Maintainer,

qemu FTBFS with libbpf 1.0.0 (available in experimental).
This is the first error from the build log:

FAILED: qemu-system-aarch64 
c++ -m64 -mcx16 @qemu-system-aarch64.rsp
/usr/bin/ld: libcommon.fa.p/ebpf_ebpf_rss.c.o: in function `ebpf_rss_load':
./b/qemu/../../ebpf/ebpf_rss.c:52: undefined reference to 
`bpf_program__set_socket_filter'
collect2: error: ld returned 1 exit status


-- 
Regards
Sudip

Bug#519666: Heimdal with Samba - sambaPwdMustChange is depreciated

On Sat, Mar 14, 2009 at 05:35:55AM -0300, Eduardo Sachs wrote:
> When using Heimdal with Samba, the Heimdal beginning to use the attribute
> sambaPwdMustChange, however, the sambaPwdMustChange changed to 
> sambaPwdLastSet, 
> in Samba 3.2.x and 3.3.x.
> 
> I find the code in heimdal-1.2.dfsg.1/lib/hdb/hdb-ldap.c.
> 
> Its now calculated dynamically. sambaPwdLastSet + sambaMaxPwdAge

This was forwarded upstream, but probably lost many years ago.

Do we need to open a new upstream bug report?
-- 
Brian May

Bug#950993: orage: calendar window doesn't work anymore

2022-09-01 Thread Bzzzz

On Fri, 02 Sep 2022 05:50:06 +0800
Paul Wise  wrote:

> On Thu, 2022-09-01 at 11:26 +0200, B wrote:
>
> > I followed this HOWTO to the letter, however I meet a compilation
> > error, it seems it is the dbus part of the backport that conflict
> > with the regular installation (? my interpretation, I'm not tough
> > enough to be sure about that).
>
> Looks like the source package is a bit buggy, this should fix it:
>
>echo usr/share/dbus-1 >> debian/orage.install

Worked like a charm :)
Popup is present and sound also works, it seems everything's all right

I'll open a new bug if it happens to fail/crash.

Thanks for your help Paul.

Jean-Yves

Bug#579573: no longer gets forwardable tickets

On Sat, Jul 03, 2010 at 01:23:36PM +0200, Per Olofsson wrote:
> This bug still exists in the latest version.

Over 10 years later, is this still an issue?

If so we need to create a new upstream report.

If not we need to close this bug report.
-- 
Brian May

Bug#761933: Using libroken through heimdal-multidev

2022-09-01 Thread Jelmer Vernooĳ

On Fri, Sep 02, 2022 at 08:12:10AM +1000, Brian May wrote:
> On Sat, Apr 25, 2015 at 04:23:14PM +, Jelmer Vernooij wrote:
> > I think a separate pkg-config file for libroken would be reasonable.
> > Ideally this would be upstream rather than Debian-specific. Let's take
> > this to the upstream bug tracker.
> 
> Splitting up libroken into a shared package would probably be good.
> 
> But I don't see this happening anytime spoon. There simply isn't anyone
> willing to do the work. Plus there has to be people willing to use it if
> the work was done, not convinced that will happen either.
> 
> As this is outside the scope of what I can do as a package maintainer I
> have tagged this "wontfix".

Yeah, that seems reasonable.

The main motivator here was Samba, but it has also gone into the other
direction on this - basically just vendoring in a copy of Heimdal,
rather than linking against system Heimdal.

(I'm personally also no longer involved in either Samba or Heimdal
development)


signature.asc
Description: PGP signature

Bug#574774: Bisected problem commit

On Thu, Aug 04, 2011 at 12:29:30PM -0400, Chris Chiappa wrote:
> I tracked the problem down to this commit:
> 
> commit 6df0783c7eef0984b712792a25dd2f5a39f8f337
> Author: Love Hornquist Astrand 
> Date:   Wed Sep 23 00:14:57 2009 -0700
> 
> Redo client key handling for AS
> 
> Pick the replykey to be the same as the preauth key, this allows
> us to delay the picking of client key to when its needed, this
> means that we can have a reply keys for PKINIT that is independant
> of what keys the client have.
> 
> The attached dif (which is probably totally wrong and shouldn't be
> applied anywhere outside of a test instance) to Heimdal 1.5 makes the
> kdc work again with no error.

Over 10 years later, anyone know if this is still an issue?

If no response, will assume fixed and close this bug report.

Otherwise we should open a new upstream bug report.
-- 
Brian May

Bug#761933: Using libroken through heimdal-multidev

On Sat, Apr 25, 2015 at 04:23:14PM +, Jelmer Vernooij wrote:
> I think a separate pkg-config file for libroken would be reasonable.
> Ideally this would be upstream rather than Debian-specific. Let's take
> this to the upstream bug tracker.

Splitting up libroken into a shared package would probably be good.

But I don't see this happening anytime spoon. There simply isn't anyone
willing to do the work. Plus there has to be people willing to use it if
the work was done, not convinced that will happen either.

As this is outside the scope of what I can do as a package maintainer I
have tagged this "wontfix".
-- 
Brian May

Bug#1016084: transition: petsc

2022-09-01 Thread Drew Parsons


On 2022-09-01 23:32, Sebastian Ramacher wrote:


Lower level libraries are uploaded.  We'll want mumps level 2 built to
prepare trilinos for the petsc build.


Scheduled mumps level 2 (except trilinos)

   ^^^

Wait no, it's trilinos that I'm waiting for! petsc needs it.

Bug#1018881: glibc: iconv not working properly on m68k and sh4

2022-09-01 Thread Aurelien Jarno

Hi,

On 2022-09-01 12:41, John Paul Adrian Glaubitz wrote:
> Source: glibc
> Version: 2.34-7
> Severity: normal
> User: debian-sup...@lists.debian.org
> Usertags: m68k sh4
> X-Debbugs-Cc: debian-...@lists.debian.org,debian-sup...@lists.debian.org
> 
> Hello!
> 
> iconv stopped working on m68k and sh4 starting with glibc 2.34 and
> I have no clue why. The issue can be reproduced on real hardware
> qemu-user and qemu-system.
> 
> The problem becomes visible when the configure script of the gettext
> package is being run on the affected architectures:
> 
> checking for iconv... yes
> checking for working iconv... no
> checking for iconv declaration... 
>  extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, 
> char * *outbuf, size_t *outbytesleft);
> checking for inttypes.h... (cached) yes
> checking for limits.h... (cached) yes
> 
> The configure script runs a small program which I have extracted and
> attached to this bug report as iconv.c.
> 
> Running it on amd64 returns a zero exit code:
> 
> (sid-amd64-sbuild)root@nofan:/# gcc -o iconv iconv.c -lc
> (sid-amd64-sbuild)root@nofan:/# ./iconv
> (sid-amd64-sbuild)root@nofan:/# echo $?
> 0
> (sid-amd64-sbuild)root@nofan:/#
> 
> On m68k and sh4, the exit code is 16 which is why the above configure
> check fails:
> 
> glaubitz@tirpitz:~$ uname -a
> Linux tirpitz 5.11.0-rc4-00012-g10c03c5bf422 #161 PREEMPT Mon Jan 18 21:10:17 
> CET 2021 sh4a GNU/Linux
> glaubitz@tirpitz:~$ gcc -o iconv iconv.c -lc
> glaubitz@tirpitz:~$ ./iconv 
> glaubitz@tirpitz:~$ echo $?
> 16
> glaubitz@tirpitz:~$

The problem is that the
/usr/lib/m68k-linux-gnu/gconv/gconv-modules.cache file is somehow
truncated for the glibc 2.34 build. Running iconvconfig by hand to
generate it fixes the issue.

It seems to be the right size for the glibc 2.35 build.

> I have run out of ideas why iconv fails, so I was wondering whether this might
> be a packaging issue. I have found a similar iconv issue being discussed on a
> Fedora mailing list where the cause was iconv data being moved out of the main
> glibc packages [1].
> 
> Maybe we have a similar problem in Debian which manifests on m68k and sh4 only
> due to some reverse dependencies being out of date?

Not his is unrelated, we haven't changed that part of the packaging.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#950993: orage: calendar window doesn't work anymore

2022-09-01 Thread Paul Wise

On Thu, 2022-09-01 at 11:26 +0200, B wrote:

> I followed this HOWTO to the letter, however I meet a compilation error,
> it seems it is the dbus part of the backport that conflict with the
> regular installation (? my interpretation, I'm not tough enough to be
> sure about that).

Looks like the source package is a bit buggy, this should fix it:

   echo usr/share/dbus-1 >> debian/orage.install

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1018912: transition: bamtools

Control: tags -1 confirmed

On 2022-09-01 23:01:04 +0200, Étienne Mollier wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> bamtools recently cleared New processing after an soversion bump
> from 2.5.1 to 2.5.2 and is now available in experimental.  I
> verified the package builds properly on all architectures in
> testing.  Pseudo-excuses are looking good[1], the ben tracker[2]
> too.  Please kindly consider providing a transition slot when
> deemed appropriate.

Please go ahead

Cheers

> 
> [1]: 
> https://release.debian.org/britney/pseudo-excuses-experimental.html#bamtools
> [2]: https://release.debian.org/transitions/html/auto-bamtools.html
> 
> Ben file:
> 
> title = "bamtools";
> is_affected = .depends ~ "libbamtools2.5.1" | .depends ~ "libbamtools2.5.2";
> is_good = .depends ~ "libbamtools2.5.2";
> is_bad = .depends ~ "libbamtools2.5.1";
> 
> Have a nice day,  :)
> -- 
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/5, please excuse my verbosity.
> On air: Saga - Hot To Cold



-- 
Sebastian Ramacher

Bug#1018876: transition: ace

Control: tags -1 confirmed

On 2022-09-01 10:53:10 +0100, Sudip Mukherjee wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: sudipm.mukher...@gmail.com
> 
> Hi,
> 
> Small transition with only two affected packages: diagnostics, ivtools.
> 
> diagnostics already has a FTBFS due to #1012912, so could not test it.
> ivtools builds fine with ace 7.0.8+dfsg-1 version in experimental.
> 
> The autogenerated ben tracker looks good. Please consider 'ace' for
> transition.
> Thanks in advance.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1018888: nmu: elastix_5.0.1-3+b1

Control: tags -1 moreinfo

On 2022-09-01 08:37:55 -0500, Steve M. Robbins wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu elastix_5.0.1-3+b1 . ANY . unstable . -m "Rebuild against updated
> insighttoolkit5"

Why is this rebuild needed?

Cheers
-- 
Sebastian Ramacher

Bug#1016084: transition: petsc

On 2022-09-01 22:05:20 +0200, Drew Parsons wrote:
> On 2022-08-31 11:57, Drew Parsons wrote:
> > 
> > The pmix problem is now worked around by reverting back to the earlier
> > version. I'll proceed with the transition of the numerical stack now.
> 
> Lower level libraries are uploaded.  We'll want mumps level 2 built to
> prepare trilinos for the petsc build.

Scheduled mumps level 2 (except trilinos)

Cheers
-- 
Sebastian Ramacher

Bug#1018871: ibus-tests:armel: depends on gnome-shell:armel which is likely to be removed

On Thu, 01 Sep 2022 at 22:27:46 +0200, Gunnar Hjalmarsson wrote:
> P.S. Doesn't this mean that ibus-tests needs to be removed from the archive
> for armel, ppc64 and sh4?

I think NBS (Not Built by Source) binary packages get cleaned up
automatically or semi-automatically, but I'll make sure any remaining
gjs-dependent packages get removed from armel as part of the transition
to mozjs102, when that goes ahead.

smcv

Bug#1018911: knot: FTBFS with libbpf 1.0.0

Package: knot
Version: 3.2.0-1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: sudipm.mukher...@gmail.com
Usertags: libbpf1

Dear Maintainer,

knot FTBFS with libbpf 1.0.0 (available in experimental).
Hopefully this is the error from the build log:

In file included from libknot/xdp/bpf-user.c:27:
./libknot/xdp/bpf-user.h:28:10: fatal error: bpf/xsk.h: No such file or 
directory
   28 | #include 
  |  ^~~
libknot/xdp/eth.c: In function 'knot_eth_xdp_mode':
libknot/xdp/eth.c:213:30: error: storage size of 'info' isn't known
  213 | struct xdp_link_info info;
  |  ^~~~
libknot/xdp/eth.c:214:19: error: implicit declaration of function 
'bpf_get_link_xdp_info' [-Werror=implicit-function-declaration]
  214 | int ret = bpf_get_link_xdp_info(if_index, &info, sizeof(info), 
0);
  |   ^
libknot/xdp/eth.c:213:30: warning: unused variable 'info' [-Wunused-variable]
  213 | struct xdp_link_info info;
  |  ^~~~
libknot/xdp/eth.c:228:1: warning: control reaches end of non-void function 
[-Wreturn-type]
  228 | }
  | ^


-- 
Regards
Sudip

Bug#1016600: siconos: vtk[6,7] removal

2022-09-01 Thread Adrian Bunk

On Wed, Aug 03, 2022 at 10:42:08PM +0200, Sebastian Ramacher wrote:
> Source: siconos
> Version: 4.3.1+dfsg-2
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> Tags: sid bookworm
> Control: block 1016597 by -1
> User: gl...@debian.org
> Usertags: vtk6_vtk7_removal
> 
> Based on #1013156 and similar bugs:
> 
> Dear maintainer,
> 
> Debian archive has now three major versions of the VTK (The
> Visualization Toolkit) package: vtk6, vtk7 and vtk9. Old vesions
> (vtk6 and vtk7) are not supported by upstream and the package itself
> is not easy for the mainance.
> 
> We aim to drop old and deprecated version vtk6 and vtk7 packages before
> the freeze of the Debian 12 Bookworm. Your package depends on vtk6 or
> vtk7. Thus we ask you to migrate it to the latest vtk9 package.

Two observations regarding the usage of VTK in siconos:

There is WITH_VTK in siconos that does not seem to build with VTK 9,
but it's anyway not enabled.

The only current usage of VTK is python3-vtk7 in siconos-mechanics-tools.
This might need upstrream fixes like
  https://github.com/siconos/siconos/pull/437

> Cheers

cu
Adrian

Bug#1018910: ROM: ruby-rack-mount; abandoned upstream

2022-09-01 Thread Lucas Kanashiro

Package: ftp.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-CC: debian-r...@lists.debian.org

Hi,

Please remove ruby-rack-mount from the archive. The last activity in the
upstream git repository was 14 years ago [1], and its features are
mostly covered but newer versions of ruby-rack. There is no reverse
dependency.

[1] https://github.com/jm/rack-mount

TIA!

-- 
Lucas Kanashiro

Bug#1018909: libkf5wallet-bin: Cannot disable Freedesktop Secret Service

2022-09-01 Thread Jan Klötzke

Package: libkf5wallet-bin
Version: 5.97.0-1
Severity: important
Tags: patch upstream

Hi,

starting with upstream version 5.97.0 the kwalled5 daemon will provide
the org.freedesktop.secrets D-Bus service. Unfortunately it's not
possible to disable this API [1] which prevents using other providers
such as keepassxc. Essentially this breaks my current setup.

I've attached a patch for the Debian package that cherry-picks the fix
from upstream git. Note that until kwalletmanager5 is updated to 22.08.0
there is no GUI and one has to manually edit .config/kwalletrc. But
without the fix this is all in vain.

[1] https://bugs.kde.org/show_bug.cgi?id=458069

Regards,
Jan

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru kwallet-kf5-5.97.0/debian/changelog 
kwallet-kf5-5.97.0/debian/changelog
--- kwallet-kf5-5.97.0/debian/changelog 2022-08-14 18:55:38.0 +0200
+++ kwallet-kf5-5.97.0/debian/changelog 2022-09-01 18:03:30.0 +0200
@@ -1,3 +1,10 @@
+kwallet-kf5 (5.97.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch to optionally disable Freedesktop Secret Service 
+
+ -- Jan Klötzke   Thu, 01 Sep 2022 18:03:30 +0200
+
 kwallet-kf5 (5.97.0-1) unstable; urgency=medium
 
   [ Aurélien COUDERC ]
diff -Nru 
kwallet-kf5-5.97.0/debian/patches/Dont-register-dummy-org.freedesktop.secrets-service-when-api-is-disabled.patch
 
kwallet-kf5-5.97.0/debian/patches/Dont-register-dummy-org.freedesktop.secrets-service-when-api-is-disabled.patch
--- 
kwallet-kf5-5.97.0/debian/patches/Dont-register-dummy-org.freedesktop.secrets-service-when-api-is-disabled.patch
1970-01-01 01:00:00.0 +0100
+++ 
kwallet-kf5-5.97.0/debian/patches/Dont-register-dummy-org.freedesktop.secrets-service-when-api-is-disabled.patch
2022-09-01 18:03:30.0 +0200
@@ -0,0 +1,30 @@
+From db1d2ecd610212f3a6b68d8e602148cfef43688c Mon Sep 17 00:00:00 2001
+From: Nicolas Fella 
+Date: Fri, 19 Aug 2022 16:34:07 +0200
+Subject: [PATCH] Don't register dummy org.freedesktop.secrets service when api
+ is disabled
+
+It prevents other programs from claiming that service
+
+BUG: 458069
+---
+ src/runtime/kwalletd/kwalletd.cpp | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/src/runtime/kwalletd/kwalletd.cpp 
b/src/runtime/kwalletd/kwalletd.cpp
+index 5de735bd..d10ce59e 100644
+--- a/src/runtime/kwalletd/kwalletd.cpp
 b/src/runtime/kwalletd/kwalletd.cpp
+@@ -168,9 +168,6 @@ KWalletD::KWalletD()
+ 
+ if (cfgSecrets.readEntry("apiEnabled", true)) {
+ _fdoService.reset(new KWalletFreedesktopService(this));
+-} else {
+-/* Do not keep dbus-daemon waiting for the org.freedesktop.secrets by 
registering the dummy-service */
+-KWalletFreedesktopService(nullptr);
+ }
+ }
+ 
+-- 
+GitLab
+
diff -Nru kwallet-kf5-5.97.0/debian/patches/series 
kwallet-kf5-5.97.0/debian/patches/series
--- kwallet-kf5-5.97.0/debian/patches/series2022-07-28 00:31:31.0 
+0200
+++ kwallet-kf5-5.97.0/debian/patches/series2022-09-01 18:03:30.0 
+0200
@@ -1 +1,2 @@
 blowfish_endianess.diff
+Dont-register-dummy-org.freedesktop.secrets-service-when-api-is-disabled.patch

Bug#1018871: ibus-tests:armel: depends on gnome-shell:armel which is likely to be removed

2022-09-01 Thread Gunnar Hjalmarsson


Ok, points taken. I'm about to upload your proposal.

Thanks!

P.S. Doesn't this mean that ibus-tests needs to be removed from the 
archive for armel, ppc64 and sh4?

Bug#1018908: ITP: cairomm1.16 -- C++ wrappers for Cairo

Package: wnpp
Severity: wishlist
Owner: jeremy.bi...@canonical.com
Control: block 1006728 by -1
X-Debbugs-CC: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org

Package Name: libcairomm-1.16-1
Version: 1.16.1
Upstream Author: The cairomm Development Team
License: LGPL-2+
Programming Lang: C++

Description: C++ wrappers for Cairo
 cairomm provides C++ bindings for the Cairo graphics library,
 a multi-platform library providing anti-aliased vector-based
 rendering for multiple target backends.

Other Info
--
This library will be maintained by the Debian GNOME team. Packaging is at
https://salsa.debian.org/gnome-team/cairomm1.16

The existing cairomm source package tracks releases from the cairomm
1.14.x series (1.0 ABI)
and is intended for use with gtkmm3.0 (which uses GTK 3).

The new cairomm1.16 ABI is intended for use with gtkmm4.0 (which uses GTK 4).

The cairomm1.16 source package naming has been adopted by other distros:
https://repology.org/project/cairomm/versions

Thanks,
Jeremy Bicha

Bug#1016084: transition: petsc

2022-09-01 Thread Drew Parsons


On 2022-08-31 11:57, Drew Parsons wrote:


The pmix problem is now worked around by reverting back to the earlier
version. I'll proceed with the transition of the numerical stack now.


Lower level libraries are uploaded.  We'll want mumps level 2 built to 
prepare trilinos for the petsc build.


Drew

Bug#1018907: RM: havp -- ROM; No longer works

2022-09-01 Thread Sebastian Andrzej Siewior

Package: ftp.debian.org
X-Debbugs-Cc: sebast...@breakpoint.cc
Severity: normal

havp is no longer work as of linux-image-* v5.15. This is not a Debian
thing but actually the relevant code has been removed from the linux
kernel. The whole explanation is in
https://bugs.debian.org/1017637

It took "long" to notice, popcon is dropping/low and it has been on life
support in Debian for quite some time. Please let it rest and remove it
from unstable.

Sebastian

Bug#1018906: dwarves: FTBFS with libbpf 1.0.0

Package: dwarves
Version: 1.23-2
Severity: important
Tags: ftbfs
X-Debbugs-Cc: sudipm.mukher...@gmail.com
Usertags: libbpf1

Dear Maintainer,

dwarves FTBFS with libbpf 1.0.0 (available in experimental).
Hopefully this is the error from the build log:

In file included from /home/sudip/test/dwarves-1.23/btf_encoder.c:18:
/usr/include/bpf/btf.h: In function 'btf_enum64_value':
/usr/include/bpf/btf.h:496:25: error: invalid use of undefined type 'const 
struct btf_enum64'
  496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
  | ^~
/usr/include/bpf/btf.h:496:46: error: invalid use of undefined type 'const 
struct btf_enum64'
  496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
  |  ^~
/home/sudip/test/dwarves-1.23/btf_encoder.c: In function 'btf__log_err':
/home/sudip/test/dwarves-1.23/btf_encoder.c:175:39: warning: implicit 
declaration of function 'btf__get_nr_types' [-Wimplicit-function-declaration]
  175 | fprintf(stderr, "[%u] %s %s", btf__get_nr_types(btf) + 1,
  |   ^
/home/sudip/test/dwarves-1.23/btf_encoder.c: In function 'btf_encoder__encode':
/home/sudip/test/dwarves-1.23/btf_encoder.c:1049:13: error: too many arguments 
to function 'btf__dedup'
 1049 | if (btf__dedup(encoder->btf, NULL, NULL)) {
  | ^~
/usr/include/bpf/btf.h:232:16: note: declared here
  232 | LIBBPF_API int btf__dedup(struct btf *btf, const struct btf_dedup_opts 
*opts);
  |^~


-- 
Regards
Sudip

Bug#1018905: buster-pu: package clamav/0.103.7+dfsg-0+deb10u1

2022-09-01 Thread Sebastian Andrzej Siewior

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: normal

This is an long overdue update to the clamav package. It is a stable
update provided by upstream. From their changelog:

- Fix logical signature "Intermediates" feature.

- Relax constraints on slightly malformed zip archives that contain overlapping
  file entries.

0.103.7 is the current LTS release.
The code diff is eual vs the bullseye package and did deploy it on one
of my servers with no side effects so far :)

It would be nice if this could become part of -updates.

Sebastian
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8d42d3c..b910470 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -15,7 +15,7 @@ string(TIMESTAMP TODAY "%Y%m%d")
 set(VERSION_SUFFIX "")
 
 project( ClamAV
- VERSION "0.103.6"
+ VERSION "0.103.7"
  DESCRIPTION "ClamAV open source email, web, and end-point anti-virus toolkit." )
 
 set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
diff --git a/NEWS.md b/NEWS.md
index 66570e7..4595141 100644
--- a/NEWS.md
+++ b/NEWS.md
@@ -3,6 +3,17 @@
 Note: This file refers to the source tarball. Things described here may differ
  slightly from the binary packages.
 
+## 0.103.7
+
+ClamAV 0.103.7 is a critical patch release with the following fixes:
+
+- Upgrade the vendored UnRAR library to version 6.1.7.
+
+- Fix logical signature "Intermediates" feature.
+
+- Relax constraints on slightly malformed zip archives that contain overlapping
+  file entries.
+
 ## 0.103.6
 
 ClamAV 0.103.6 is a critical patch release with the following fixes:
diff --git a/configure b/configure
index 59bf5dd..9f9a4f5 100755
--- a/configure
+++ b/configure
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for ClamAV 0.103.6.
+# Generated by GNU Autoconf 2.69 for ClamAV 0.103.7.
 #
 # Report bugs to .
 #
@@ -592,8 +592,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='ClamAV'
 PACKAGE_TARNAME='clamav'
-PACKAGE_VERSION='0.103.6'
-PACKAGE_STRING='ClamAV 0.103.6'
+PACKAGE_VERSION='0.103.7'
+PACKAGE_STRING='ClamAV 0.103.7'
 PACKAGE_BUGREPORT='https://github.com/Cisco-Talos/clamav/issues'
 PACKAGE_URL='https://www.clamav.net/'
 
@@ -1606,7 +1606,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ClamAV 0.103.6 to adapt to many kinds of systems.
+\`configure' configures ClamAV 0.103.7 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1687,7 +1687,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ClamAV 0.103.6:";;
+ short | recursive ) echo "Configuration of ClamAV 0.103.7:";;
esac
   cat <<\_ACEOF
   --enable-dependency-tracking
@@ -1922,7 +1922,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ClamAV configure 0.103.6
+ClamAV configure 0.103.7
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2550,7 +2550,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ClamAV $as_me 0.103.6, which was
+It was created by ClamAV $as_me 0.103.7, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4308,7 +4308,7 @@ fi
 
 # Define the identity of the package.
  PACKAGE='clamav'
- VERSION='0.103.6'
+ VERSION='0.103.7'
 
 
 # Some tools Automake needs.
@@ -6036,7 +6036,7 @@ esac
 $as_echo "#define PACKAGE PACKAGE_NAME" >>confdefs.h
 
 
-VERSION="0.103.6"
+VERSION="0.103.7"
 
 major=`echo $PACKAGE_VERSION |cut -d. -f1 | sed -e "s/^0-9//g"`
 minor=`echo $PACKAGE_VERSION |cut -d. -f2 | sed -e "s/^0-9//g"`
@@ -31896,7 +31896,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.103.6, which was
+This file was extended by ClamAV $as_me 0.103.7, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -31963,7 +31963,7 @@ _ACEOF
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.103.6
+ClamAV config.status 0.103.7
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
@@ -34813,7 +34813,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-T

Bug#1018904: bullseye-pu: package clamav/0.103.7+dfsg-0+deb11u1

2022-09-01 Thread Sebastian Andrzej Siewior

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
Severity: normal

This is an long overdue update to the clamav package. It is a stable
update provided by upstream. From their changelog:

- Fix logical signature "Intermediates" feature.

- Relax constraints on slightly malformed zip archives that contain overlapping
  file entries.

0.103.7 is the current LTS release.
The code diff is eual vs the buster package.

It would be nice if this could become part of -updates.

Sebastian
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8d42d3c..b910470 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -15,7 +15,7 @@ string(TIMESTAMP TODAY "%Y%m%d")
 set(VERSION_SUFFIX "")
 
 project( ClamAV
- VERSION "0.103.6"
+ VERSION "0.103.7"
  DESCRIPTION "ClamAV open source email, web, and end-point anti-virus toolkit." )
 
 set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
diff --git a/NEWS.md b/NEWS.md
index 66570e7..4595141 100644
--- a/NEWS.md
+++ b/NEWS.md
@@ -3,6 +3,17 @@
 Note: This file refers to the source tarball. Things described here may differ
  slightly from the binary packages.
 
+## 0.103.7
+
+ClamAV 0.103.7 is a critical patch release with the following fixes:
+
+- Upgrade the vendored UnRAR library to version 6.1.7.
+
+- Fix logical signature "Intermediates" feature.
+
+- Relax constraints on slightly malformed zip archives that contain overlapping
+  file entries.
+
 ## 0.103.6
 
 ClamAV 0.103.6 is a critical patch release with the following fixes:
diff --git a/configure b/configure
index 59bf5dd..9f9a4f5 100755
--- a/configure
+++ b/configure
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for ClamAV 0.103.6.
+# Generated by GNU Autoconf 2.69 for ClamAV 0.103.7.
 #
 # Report bugs to .
 #
@@ -592,8 +592,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='ClamAV'
 PACKAGE_TARNAME='clamav'
-PACKAGE_VERSION='0.103.6'
-PACKAGE_STRING='ClamAV 0.103.6'
+PACKAGE_VERSION='0.103.7'
+PACKAGE_STRING='ClamAV 0.103.7'
 PACKAGE_BUGREPORT='https://github.com/Cisco-Talos/clamav/issues'
 PACKAGE_URL='https://www.clamav.net/'
 
@@ -1606,7 +1606,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ClamAV 0.103.6 to adapt to many kinds of systems.
+\`configure' configures ClamAV 0.103.7 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1687,7 +1687,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ClamAV 0.103.6:";;
+ short | recursive ) echo "Configuration of ClamAV 0.103.7:";;
esac
   cat <<\_ACEOF
   --enable-dependency-tracking
@@ -1922,7 +1922,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ClamAV configure 0.103.6
+ClamAV configure 0.103.7
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2550,7 +2550,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ClamAV $as_me 0.103.6, which was
+It was created by ClamAV $as_me 0.103.7, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4308,7 +4308,7 @@ fi
 
 # Define the identity of the package.
  PACKAGE='clamav'
- VERSION='0.103.6'
+ VERSION='0.103.7'
 
 
 # Some tools Automake needs.
@@ -6036,7 +6036,7 @@ esac
 $as_echo "#define PACKAGE PACKAGE_NAME" >>confdefs.h
 
 
-VERSION="0.103.6"
+VERSION="0.103.7"
 
 major=`echo $PACKAGE_VERSION |cut -d. -f1 | sed -e "s/^0-9//g"`
 minor=`echo $PACKAGE_VERSION |cut -d. -f2 | sed -e "s/^0-9//g"`
@@ -31896,7 +31896,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.103.6, which was
+This file was extended by ClamAV $as_me 0.103.7, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -31963,7 +31963,7 @@ _ACEOF
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.103.6
+ClamAV config.status 0.103.7
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
@@ -34813,7 +34813,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.103.6, which was
+This file

Bug#1018872: systemd.service COMMAND LINE misses command search, if starting with "+".

2022-09-01 Thread Michael Biebl


[please always CC the bug number]

You are all over the place now.
So, what is this bug report about actually?


Am 01.09.22 um 21:06 schrieb Harald Bergmann:

Hello Michael,

after some testing things have cleared up much, but there is still a bug 
in systemd, but only related to error message selection.

First some facts by testing:

  * Now I agree that neither
  o ExecStartPre=+mkdir -p /run/foo ; +chown michael /run/foo - nor
  o distributing on multiple ExecStartPre commands have a problem on
command access.
  o Assuming that there would have been a workaround like using
„/bin/mkdir“ was an illusion.
  * Service start manually always operated - preparing the illusion,
that the workaround helped.
  * Service autostart on boot always failed independent of workaround or
command distribution.
  * Main error by me was a wrong [Install] statement:
  o WantedBy=multi*.*user.target
  + Correcting this to "WantedBy=multi*-*user.target“ results to
a well auto-starting service.
  * Still existing error on systemd operation is the result of command:
  o sudo systemd-analyze verify calendarserver.service
  + calendarserver.service: Command mkdir is not executable:
Datei oder Verzeichnis nicht gefunden
  + This happens always, even if manual- and auto-start operate
well, and even if folder does not exists and „mkdir“ really
need to act.
  + Hence the error detection and message is simply wrong.
  o Even worse is the fact, that this wrong message prevents telling
the real error position, probably by dropping further
examination after this first error-misinterpretation appears.
  o Hence I like to ask you for looking after the error generation
method.


Finally here is the now operating service configuration for being 
complete regarding your demands:


# Adaptation of some automatically generated configuration by
systemd-sysv-generator.

[Unit]
Documentation=man:caldavd
Description=LSB: Calendar and Contacts Server
Before=multi-user.target
Before=graphical.target
After=network-online.target
After=remote-fs.target
Wants=network-online.target
Requires=postgresql.service

[Service]
Type=forking
PIDFile=/run/caldavd/caldavd.pid
WorkingDirectory=/var/lib/caldavd
User=caldavd
Group=caldavd
Restart=always
TimeoutSec=10min
IgnoreSIGPIPE=no
SuccessExitStatus=5 6
ExecStartPre=+mkdir -p /run/caldavd ; +chown -R caldavd:caldavd
/run/caldavd
ExecStart=/usr/local/bin/caldavd -u caldavd -g caldavd


[Install]
WantedBy=multi-user.target

Many thanks for your patience and support!

Best regards,
Harald

Am 01.09.2022 um 12:27 schrieb Michael Biebl >:



Am 01.09.22 um 12:08 schrieb Harald Bergmann:

Hello Michael,
thanks for your teaching!
Please open a bug report for updating „man systemd.service“ 
accordingly regarding section „COMMAND LINES“ starting from line 963.

Many thanks for your support!


I stand corrected. That said, I still can't reproduce the bug report:

# cat test.service
[Unit]
Description=test

[Service]
Type=oneshot
User=michael
ExecStartPre=echo foo ; echo bar
ExecStartPre=+mkdir -p /run/foo ; +chown michael /run/foo
ExecStart=/bin/true


# systemctl status test.service
● test.service - test
Loaded: loaded (/etc/systemd/system/test.service; static)
Active: inactive (dead)

Sep 01 10:56:05 raspberrypi-ka systemd[1]: Starting Test...
Sep 01 10:56:05 raspberrypi-ka echo[2432]: Hello World
Sep 01 10:56:05 raspberrypi-ka systemd[1]: test.service: Succeeded.
Sep 01 10:56:05 raspberrypi-ka systemd[1]: Finished Test.
Sep 01 12:25:12 raspberrypi-ka systemd[1]: Starting test...
Sep 01 12:25:12 raspberrypi-ka echo[3675]: foo
Sep 01 12:25:12 raspberrypi-ka echo[3676]: bar
Sep 01 12:25:13 raspberrypi-ka systemd[1]: test.service: Succeeded.
Sep 01 12:25:13 raspberrypi-ka systemd[1]: Finished test.

# ls -ld /run/foo/
drwxr-xr-x 2 michael root 40  1. Sep 10:56 /run/foo/

Maybe it would help if you posted a complete service file and complete 
error messages.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018903: RM: flowcanvas -- RoQA; unmaintained, dead upstream, depends on Python 2

2022-09-01 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal

Please remove flowcanvas. Removal has already suggested back in 2018 (#888656),
there are no reverse dependencies left, the package is unmaintained (last
maintainer upload in 2009) and it depends on Python 2.

Cheers,
 Moritz

Bug#1018897: policykit-1: should use upstream version >= 121 in Debian 12

2022-09-01 Thread Moritz Mühlenhoff

Am Thu, Sep 01, 2022 at 06:30:42PM +0100 schrieb Simon McVittie:
> Remaining things to do
> --
> 
> Security team and duktape maintainers: do you have any strong objections?

Sounds great, no objections at all!

Cheers,
Moritz

Bug#1018902: atkmm1.6: Don't package atkmm 2.36

Source: atkmm1.6
Version: 2.28.2-1
Severity: wishlist
Tags: wontfix
Forwarded: https://gitlab.gnome.org/GNOME/atkmm/-/issues/4

The atkmm 2.36 series is a new incompatible ABI series. It is
unnecessary for gtkmm 4 and is believed to not have any users.
Therefore, it's not worth packaging.

I am adjusting the debian/watch for atkmm1.6 to only watch for 2.28.x
releases which is the recommended stable branch for gtkmm 3.

Thank you,
Jeremy Bicha

Bug#1018901: /bin/nc.traditional: nc -U: Add support for Unix sockets

2022-09-01 Thread Alejandro Colomar

Package: netcat-traditional
Version: 1.10-47
Severity: wishlist
File: /bin/nc.traditional
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

It would be nice if nc(1) could support Unix sockets (including
abstract ones).  OpenBSD's nc(1), which is based on the same
original Hobbit's source has support for them.

Cheers,

Alex


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_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 netcat-traditional depends on:
ii  libc6  2.34-7

netcat-traditional recommends no packages.

netcat-traditional suggests no packages.

-- no debconf information

Bug#1017915: btrfs: space cache corruption and potential double allocations

2022-09-01 Thread Christoph Anton Mitterer

On Thu, 2022-09-01 at 16:40 +0200, Salvatore Bonaccorso wrote:
> 5.19.6-1 has been uploaded earlier today.

Ah,... okay... I had only seen the UNRELEASED commit in salsa.


Cheers,
Chris.

Bug#1017397:

2022-09-01 Thread Thiago Bellini Ribeiro

I too am seeing a very high CPU usage (basically 100% of one of my CPU
cores), but with my bluetooth headphones turned on.

At the issue that was mentioned here (
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/152), there's
a patch available that fixes this. Arch has patched its wireplumber package
to include that patch, which people there are reporting to have solved the
issue. Could we include the patch in the debian package as well?

-- 
Thiago Bellini Ribeiro | https://bellini.dev

Bug#1007000: thin FTBFS on IPV6-only buildds

2022-09-01 Thread Lucas Kanashiro

This is a consequence of this bug filed against ruby-eventmachine:

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

-- 
Lucas Kanashiro

Bug#1018900: mini-httpd: maxage option documented but not implemented

2022-09-01 Thread Marc Lehmann

Package: mini-httpd
Version: 1.30-2+b1
Severity: normal

Dear Maintainer,

the manpage documents the "maxage" option, but if you add:

   maxage=0

to the config file, mini_httpd no longer starts:

   Sep 01 20:17:25 acer mini-httpd[6312]: /usr/sbin/mini_httpd: unknown config 
option 'maxage'
   Sep 01 20:17:25 acer systemd[1]: mini-httpd.service: Control process exited, 
code=exited, status=1/FAILURE

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 5.19.5-schmorp (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 mini-httpd depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u3
ii  libcrypt11:4.4.18-4
ii  libssl1.11.1.1n-0+deb11u3
ii  lsb-base 11.1.0

Versions of packages mini-httpd recommends:
ii  apache2-utils  2.4.54-1~deb11u1

mini-httpd suggests no packages.

-- no debconf information

Bug#1018893: support for unshare in some form

2022-09-01 Thread Helmut Grohne

Hi Jelmer,

On Thu, Sep 01, 2022 at 03:51:19PM +, Jelmer Vernooij wrote:
> It would be great if piuparts supported root-less operation, ideally in a less
> complicated way than via podman+docker.
> 
> Conversation in #debian-qa suggests the are various options for building on
> top of infrastructure that's provided by other packages, e.g. sbuild,
> autopkgtest or mmdebootstrap.
> 
>  Jelmer, h01ger: I'd second what helmut said. With mmdebstrap you get 
> the equivalent of "lxc-usernsexec -- lxc-unshare -s 'MOUNT|PID|UTSNAME|IPC' 
> -- /usr/sbin/chroot ./debian-rootfs /bin/bash" but without having to depend 
> on lxc -- You can see a variant of this in the mmdebstrap man page where 
> mmdebstrap is used as a wrapper of debootstrap to fix #829134. That way you 
> can run debootstrap without 
> needing root: mmdebstrap --variant=custom --mode=unshare --setup-hook='env 
> container=lxc debootstrap unstable "$1"' - debian-debootstrap.tar

Yeah, I think we're 99% there.

piuparts has a --existing-chroot option. Unfortunately, it doesn't
exactly do what we need here. It uses the given directory as a template
and tries to copy it. That is bound to fail as mmdebstrap has kindly
mounted /sys and /proc and such. It would be nice if piuparts got some
--use-existing option that would make it just use that chroot directly.

--use-existing is relatively easy to implement. I'm attaching a patch
for your convenience. I'm not sure whether this is acceptable in
piuparts. I do find the flag, its semantics and its implementation quite
suboptimal. I'd prefer if you use it as inspiration rather than
solution.

So we're doing something like piuparts --existing-chroot=...
--use-existing and this is going to be our --customize-hook for
mmdebstrap. The whole thing is not entirely trivial to assemble, but
this is how it looks:

mmdebstrap \
--verbose \
--mode=unshare \
--variant=apt \
--customize-hook='mv $1/sbin/start-stop-daemon.REAL 
$1/sbin/start-stop-daemon && ./piuparts --use-existing --existing-chroot=$1 
.../somepackage.changes' \
sid \
/dev/null \
http://deb.debian.org/debian

I suppose the most tricky part is the one about start-stop-daemon. It's
mangled by mmdebstrap for historical reasons. It's a problem, because
piuparts runs debsums and debsums doesn't like that.

So I tried this with a simple package (e.g. buffer) and it passed
completely in an entirely unprivileged way without podman.

Helmut
--- /usr/sbin/piuparts	2021-10-14 15:23:26.0 +0200
+++ ./piuparts	2022-09-01 20:09:26.195314473 +0200
@@ -199,6 +199,7 @@
 self.debfoster_options = None
 self.docker_image = None
 self.merged_usr = False
+self.use_existing = False
 # tests and checks
 self.no_install_purge_test = False
 self.no_upgrade_test = False
@@ -782,7 +783,8 @@
 def create(self, temp_tgz=None):
 """Create a chroot according to user's wishes."""
 self.panic_handler_id = do_on_panic(self.remove)
-if not settings.schroot and not settings.docker_image:
+if (not settings.schroot and not settings.docker_image and
+not (settings.existing_chroot and settings.use_existing)):
 self.create_temp_dir()
 
 if temp_tgz:
@@ -792,7 +794,10 @@
 elif settings.lvm_volume:
 self.setup_from_lvm(settings.lvm_volume)
 elif settings.existing_chroot:
-self.setup_from_dir(settings.existing_chroot)
+if settings.use_existing:
+self.name = settings.existing_chroot
+else:
+self.setup_from_dir(settings.existing_chroot)
 elif settings.schroot:
 self.setup_from_schroot(settings.schroot)
 elif settings.docker_image:
@@ -800,7 +805,8 @@
 else:
 self.setup_minimal_chroot()
 
-if not settings.schroot and not settings.docker_image:
+if (not settings.schroot and not settings.docker_image and
+not (settings.existing_chroot and settings.use_existing)):
 self.mount_proc()
 self.configure_chroot()
 
@@ -851,7 +857,8 @@
 if settings.docker_image:
 logging.debug("Destroy docker container '%s'" % self.docker_container)
 run(['docker', 'rm', '-f', self.docker_container])
-if not settings.schroot and not settings.docker_image:
+if (not settings.schroot and not settings.docker_image and
+not (settings.existing_chroot and settings.use_existing)):
 run(['rm', '-rf', '--one-file-system', self.name])
 if os.path.exists(self.name):
 create_file(os.path.join(self.name, ".piuparts.tmpdir"), "removal failed")
@@ -2761,6 +2768,8 @@
   help="Use DIR as the contents of the initial " +
"chroot, instead of building a new one with " +

Bug#1007133: php-dapphp-radius: debian/watch cannot detect new upstream tags


This is now fixed in the salsa repository. Please, upload a new version.

--
Athos Ribeiro

Bug#1007132: php-dapphp-radius: Enable OpenSSL legacy providers during tests


This is now fixed in the salsa repository. Please, upload a new version.

--
Athos Ribeiro

Bug#1011881: php-dapphp-radius: FTBFS: tests fail


This is now fixed in the salsa repository. Please, upload a new version.

--
Athos Ribeiro

Bug#1018899: gcr-prompter dumps secrets in syslog/journald

2022-09-01 Thread Antoine Beaupre

Package: gcr
Version: 3.41.1-1
Severity: important

It looks like some secrets are leaking from the gcr program into my
system logs. I see this when GnuPG triggers a password prompt:

sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: received BeginPrompting call from 
callback /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: preparing a prompt for callback 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: creating new GcrPromptDialog 
prompt
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: automatically selecting secret 
exchange protocol
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: generating public key
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: beginning the secret exchange: 
[sx-aes-1]\npublic=[REDACTED]\n
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: calling the PromptReady method on 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: returned from the PromptReady 
method on /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: received PerformPrompt call from 
callback /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: closing the prompt
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p0@:1.40
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: calling the PromptDone method on 
/org/gnome/keyring/Prompt/p0@:1.40, and ignoring reply
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: received BeginPrompting call from 
callback /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: preparing a prompt for callback 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: creating new GcrPromptDialog 
prompt
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: automatically selecting secret 
exchange protocol
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: generating public key
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: beginning the secret exchange: 
[sx-aes-1]\npublic=[REDACTED]\n
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: calling the PromptReady method on 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: returned from the PromptReady 
method on /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: received PerformPrompt call from 
callback /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: receiving secret exchange: 
[sx-aes-1]\npublic=[REDACTED]\n
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: deriving shared transport key
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: deriving transport key
sep 01 13:45:47 emma gcr-prompter[7681]: Gcr: starting password prompt for 
callback /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: completed password prompt for 
callback :1.42@/org/gnome/keyring/Prompt/p1
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: encrypting data
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: sending the secret exchange: 
[sx-aes-1]\npublic=[REDACTED]\n
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: calling the PromptReady method on 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: returned from the PromptReady 
method on /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: received PerformPrompt call from 
callback /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: closing the prompt
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: couldn't find the callback for 
prompting operation /org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-prompter[7681]: Gcr: stopping prompting for operation 
/org/gnome/keyring/Prompt/p1@:1.42
sep 01 13:45:49 emma gcr-

Bug#1018897: policykit-1: should use upstream version >= 121 in Debian 12

Control: reassign -1 src:policykit-1

Sorry, wrong source package name; forwarding this to make sure other
maintainers see it.

On Thu, 01 Sep 2022 at 18:30:42 +0100, Simon McVittie wrote:
> Source: polkitd
> Version: 0.105-33
> Severity: important
> Tags: patch
> X-Debbugs-Cc: t...@security.debian.org, dukt...@packages.debian.org
> 
> We have effectively been maintaining a fork of polkit 0.105 in unstable
> since 2013, and it's unsustainable. The reason why we were stuck on
> 0.105 for so long is that maintainers didn't want to move from .pkla to
> JavaScript as a format for authorization rules, for these reasons:
> 
> 1. philosophical: .pkla is declarative, the JavaScript rules are
>imperative (and indeed Turing-complete)
> 2. practical: mozjs is not an easy project to have as a dependency
> 3. practical: the migration path from .pkla to JavaScript for sysadmins'
>local configuration is not obvious
> 
> I believe we now have consensus among the maintainers that (1.) is not a
> blocker for updating to a new upstream release.
> 
> (2.) has been solved in experimental by upstream support for using duktape
> instead of mozjs. If mozjs is like nodejs or Python, then duktape is
> more like Lua: it's a smaller and more limited JavaScript implementation,
> optimized for small size rather than features and speed.
> 
> Now that the use of JavaScript is not a barrier, (3.) has been solved
> in experimental by converting the polkitd-pkla package into an optional
> addon, which hooks into the JavaScript implementation of polkitd and calls
> out to a helper executable which implements the old .pkla configuration
> format. I have also reported bugs tagged in
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-utopia-maintainers%40lists.alioth.debian.org&tag=pkla-without-js
> for all the packages that include .pkla configuration with no JavaScript
> equivalent, which will not work as intended when users install
> polkitd-javascript but do not install the suggested package polkitd-pkla.
> 
> I think this means the pieces are all in place for merging the
> version from experimental into testing/unstable, and we have consensus
> among the package's maintainers that we want the polkitd-javascript
> implementation to be the only one, with polkitd-pkla as an optional
> addon for backwards-compat (this would put us in the same situation
> as Fedora and RHEL). I've cc'd the security team and the duktape
> maintainers in case they are aware of any showstoppers with this plan.
> 
> Previous discussion is in
> https://salsa.debian.org/utopia-team/polkit/-/merge_requests/6 and
> https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1972654.
> 
> Security implications
> -
> 
> Not using a 9 year old fork of polkit would make the maintainers a lot
> more comfortable about not having implementation errors in the C code.
> I have tried to backport fixes from upstream polkit, but 9 years is a long
> time to be doing that across and not all patches can be applied.
> 
> The JavaScript that is interpreted to carry out policy checks is totally
> trusted (the whole point of it is that it lets the sysadmin choose who can
> do what with elevated privileges), so it is not a problem if duktape can be
> made to do bad things by using attacker-controlled JavaScript: if there is
> attacker-controlled JavaScript in use, we have already lost.
> 
> The JavaScript rules can interact with objects provided by polkit, which
> can have metadata provided by the service that is querying the policy.
> This metadata might be attacker-controlled in some cases, so duktape's
> string processing is potentially security-senstive here.
> 
> If users upgrade polkitd without installing the optional package
> polkitd-pkla, then any local .pkla customization will not run, which
> might mean that restrictive non-default policies get reset to being
> less restrictive.
> 
> Remaining things to do
> --
> 
> Security team and duktape maintainers: do you have any strong objections?
> 
> We need to decide: do we ship polkitd-pkla in Debian 12, or remove
> it? There was no consensus among maintainers on this: Martin Pitt and
> Iain Lane thought we should ship it, Michael Biebl thought we should not.
> 
> We need to decide: if we ship it, how strongly does polkitd depend on
> it? A hard Depends is too strong, and would be circular. Recommends might
> be justifiable, and would pull it in during 11 -> 12 upgrades, at the cost
> of keeping this legacy code around (polkit-pkla-compat has essentially not
> been touched since 2013 either). For the moment I've gone with Suggests.
> I think we should definitely relax it to Suggests, or no dependency at all,
> in the Debian 13 cycle.
> 
> Another thing we could do, if we want to, would be to give polkitd a
> weak dependency on polkitd-pkla (Suggests or nothing at all), but give
> the transitional package policykit-1 a stronger dependency (perhaps
> Recommends) so that polkitd-pk

Bug#1018898: gconf-editor: Intent to request removal from Debian

Source: gconf-editor
Version: 3.0.1-6
Severity: serious
Tags: bookworm sid

gconf-editor was removed from Testing two and a half years ago.

Its only purpose is to enable editing gconf settings which are only
used by a very small number of packages and are functionally obsolete.

I remember that the last time I tried to remove this package years
ago, the current maintainer had strong feelings against it so I
figured it was best for me to file this bug first.

Thank you,
Jeremy Bicha

Bug#1018897: policykit-1: should use upstream version >= 121 in Debian 12

Source: polkitd
Version: 0.105-33
Severity: important
Tags: patch
X-Debbugs-Cc: t...@security.debian.org, dukt...@packages.debian.org

We have effectively been maintaining a fork of polkit 0.105 in unstable
since 2013, and it's unsustainable. The reason why we were stuck on
0.105 for so long is that maintainers didn't want to move from .pkla to
JavaScript as a format for authorization rules, for these reasons:

1. philosophical: .pkla is declarative, the JavaScript rules are
imperative (and indeed Turing-complete)
2. practical: mozjs is not an easy project to have as a dependency
3. practical: the migration path from .pkla to JavaScript for sysadmins'
local configuration is not obvious

I believe we now have consensus among the maintainers that (1.) is not a
blocker for updating to a new upstream release.

(2.) has been solved in experimental by upstream support for using duktape
instead of mozjs. If mozjs is like nodejs or Python, then duktape is
more like Lua: it's a smaller and more limited JavaScript implementation,
optimized for small size rather than features and speed.

Now that the use of JavaScript is not a barrier, (3.) has been solved
in experimental by converting the polkitd-pkla package into an optional
addon, which hooks into the JavaScript implementation of polkitd and calls
out to a helper executable which implements the old .pkla configuration
format. I have also reported bugs tagged in
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-utopia-maintainers%40lists.alioth.debian.org&tag=pkla-without-js
for all the packages that include .pkla configuration with no JavaScript
equivalent, which will not work as intended when users install
polkitd-javascript but do not install the suggested package polkitd-pkla.

I think this means the pieces are all in place for merging the
version from experimental into testing/unstable, and we have consensus
among the package's maintainers that we want the polkitd-javascript
implementation to be the only one, with polkitd-pkla as an optional
addon for backwards-compat (this would put us in the same situation
as Fedora and RHEL). I've cc'd the security team and the duktape
maintainers in case they are aware of any showstoppers with this plan.

Previous discussion is in
https://salsa.debian.org/utopia-team/polkit/-/merge_requests/6 and
https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1972654.

Security implications
-

Not using a 9 year old fork of polkit would make the maintainers a lot
more comfortable about not having implementation errors in the C code.
I have tried to backport fixes from upstream polkit, but 9 years is a long
time to be doing that across and not all patches can be applied.

The JavaScript that is interpreted to carry out policy checks is totally
trusted (the whole point of it is that it lets the sysadmin choose who can
do what with elevated privileges), so it is not a problem if duktape can be
made to do bad things by using attacker-controlled JavaScript: if there is
attacker-controlled JavaScript in use, we have already lost.

The JavaScript rules can interact with objects provided by polkit, which
can have metadata provided by the service that is querying the policy.
This metadata might be attacker-controlled in some cases, so duktape's
string processing is potentially security-senstive here.

If users upgrade polkitd without installing the optional package
polkitd-pkla, then any local .pkla customization will not run, which
might mean that restrictive non-default policies get reset to being
less restrictive.

Remaining things to do
--

Security team and duktape maintainers: do you have any strong objections?

We need to decide: do we ship polkitd-pkla in Debian 12, or remove
it? There was no consensus among maintainers on this: Martin Pitt and
Iain Lane thought we should ship it, Michael Biebl thought we should not.

We need to decide: if we ship it, how strongly does polkitd depend on
it? A hard Depends is too strong, and would be circular. Recommends might
be justifiable, and would pull it in during 11 -> 12 upgrades, at the cost
of keeping this legacy code around (polkit-pkla-compat has essentially not
been touched since 2013 either). For the moment I've gone with Suggests.
I think we should definitely relax it to Suggests, or no dependency at all,
in the Debian 13 cycle.

Another thing we could do, if we want to, would be to give polkitd a
weak dependency on polkitd-pkla (Suggests or nothing at all), but give
the transitional package policykit-1 a stronger dependency (perhaps
Recommends) so that polkitd-pkla gets pulled in during upgrades from
Debian 11.

We should have a NEWS entry, but that's blocked by deciding what shape
the final packaging is going to be.

We should probably merge the polkitd and polkitd-javascript packages
back together at some point, but for now I've kept them separate, so
that if someone vetoes the use of JavaScript we won't have to go back
throug

Bug#1018896: grcompiler: FTBFS on big endian

2022-09-01 Thread Bastian Germann


Source: grcompiler
Version: 5.2.1-0.1
Severity: serious
Tags: ftbfs
Control: forwarded -1

grcompiler fails to build from scratch on big endian systems, including s390x, 
because of test fails:
https://buildd.debian.org/status/fetch.php?pkg=grcompiler&arch=s390x&ver=5.2.1-0.1&stamp=1661942327

test 1
  Start  1: compile_SchTest

1: Test command: /<>/obj-s390x-linux-gnu/compiler/grcompiler "-D" "-v4" "-e" 
"/<>/obj-s390x-linux-gnu/test/GrcRegressionTest/SchTest.gdlerr.txt" 
"/<>/test/GrcRegressionTest/fonts/SchMain.gdl" "/<>/test/GrcRegressionTest/fonts/SchInput.ttf" 
"SchTest.ttf"

1: Working Directory: 
/<>/obj-s390x-linux-gnu/test/GrcRegressionTest
1: Environment variables:
1:  GDLPP=/<>/obj-s390x-linux-gnu/preprocessor/gdlpp
1:  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/include/../lib
1: Test timeout computed to be: 1500
test 4
  Start  4: compile_CharisTest

4: Test command: /<>/obj-s390x-linux-gnu/compiler/grcompiler "-D" "-v2" "-e" 
"/<>/obj-s390x-linux-gnu/test/GrcRegressionTest/CharisTest.gdlerr.txt" 
"/<>/test/GrcRegressionTest/fonts/CharisMain.gdl" 
"/<>/test/GrcRegressionTest/fonts/CharisInput.ttf" "CharisTest.ttf"

4: Working Directory: 
/<>/obj-s390x-linux-gnu/test/GrcRegressionTest
4: Environment variables:
4:  GDLPP=/<>/obj-s390x-linux-gnu/preprocessor/gdlpp
4:  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/include/../lib
4: Test timeout computed to be: 1500
1: Frexx C Preprocessor v1.5 Copyright (C) by FrexxWare 1993 - 1997.
1: Revised by SIL International for Graphite Description Language, Aug 23 2022
1: Graphite Compiler Version 5.2.1  [release build]
1: Copyright (c) 2002-2021, by SIL International.  All rights reserved.
1: Reading input font...
1:
1: GDL file: /<>/test/GrcRegressionTest/fonts/SchMain.gdl
1: PreProcessor: /<>/obj-s390x-linux-gnu/preprocessor/gdlpp
1: Input TT file: /<>/test/GrcRegressionTest/fonts/SchInput.ttf
1: Output TT file: SchTest.ttf
1: Output font name: Scheherazade GrcRegTest (unchanged)
1: Silf table version requested: 4.0
1:
1: Parsing file /<>/test/GrcRegressionTest/fonts/SchMain.gdl...
1: Initial processing...
1: Checking for errors...
1: Compiling...
1: [Generating FSMs:  table 0 pass 0 1 (mc 4 fsm 5 5) 2 (mc 4 fsm 45 19) 3 (mc 2 fsm 3 3) 4 (mc 13 fsm 120 57) 5 (mc 15 
fsm 41 15) 6 (mc 8 fsm 46 36);  table 1 pass 0 1 (mc 21 fsm 235 64) 2 (mc 9 fsm 52 16) 3 (mc 32 fsm 1623 368); ]

1: Debug files generated.
1: Debugger XML file generated.
1: Compilation successful!
1: 1 warning has been output to /<>/obj-s390x-linux-gnu/test/GrcRegressionTest/SchTest.gdlerr.txt (121 
warnings ignored).

 1/15 Test  #1: compile_SchTest .   Passed0.22 sec
test 7
  Start  7: compile_PigLatinTest_v2

7: Test command: /<>/obj-s390x-linux-gnu/compiler/grcompiler "-D" "-v2" "-p" "-e" 
"/<>/obj-s390x-linux-gnu/test/GrcRegressionTest/PigLatinTest_v2.gdlerr.txt" 
"/<>/test/GrcRegressionTest/fonts/PigLatinMain.gdl" 
"/<>/test/GrcRegressionTest/fonts/PigLatinInput.ttf" "PigLatinTest_v2.ttf" "PigLatin GrRegTest V2"

7: Working Directory: 
/<>/obj-s390x-linux-gnu/test/GrcRegressionTest
7: Environment variables:
7:  GDLPP=/<>/obj-s390x-linux-gnu/preprocessor/gdlpp
7:  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/include/../lib
7: Test timeout computed to be: 1500
7: Frexx C Preprocessor v1.5 Copyright (C) by FrexxWare 1993 - 1997.
7: Revised by SIL International for Graphite Description Language, Aug 23 2022
4: Frexx C Preprocessor v1.5 Copyright (C) by FrexxWare 1993 - 1997.
4: Revised by SIL International for Graphite Description Language, Aug 23 2022
4: Graphite Compiler Version 5.2.1  [release build]
4: Copyright (c) 2002-2021, by SIL International.  All rights reserved.
4: Reading input font...
4:
4: GDL file: /<>/test/GrcRegressionTest/fonts/CharisMain.gdl
4: PreProcessor: /<>/obj-s390x-linux-gnu/preprocessor/gdlpp
4: Input TT file: /<>/test/GrcRegressionTest/fonts/CharisInput.ttf
4: Output TT file: CharisTest.ttf
4: Output font name: Charis GrcRegTest (unchanged)
4: Silf table version requested: 2.0
4:
4: Parsing file /<>/test/GrcRegressionTest/fonts/CharisMain.gdl...
4: Initial processing...
4: Checking for errors...
4: Compiling...
4: [Generating FSMs:  table 0 pass 0 1 (mc 138 fsm 3349 279) 2 (mc 39 fsm 363 92);  table 1 pass 0 1 (mc 25 fsm 3493 
474) 2 (mc 5 fsm 1080 493) 3 (mc 6 fsm 1927 733); ]

4: Debug files generated.
4: Debugger XML file generated.
4: Compilation successful!
4: 1 warning has been output to /<>/obj-s390x-linux-gnu/test/GrcRegressionTest/CharisTest.gdlerr.txt (128 
warnings ignored).

 2/15 Test  #4: compile_CharisTest ..   Passed2.33 sec
test 10
  Start 10: compile_PigLatinTest_v3

10: Test command: /<>/obj-s390x-linux-gnu/compiler/grcompiler "-D" "-v3" "-e" 
"/<>/obj-s390x-linux-gnu/test/GrcRegressionTest/PigLatinTest_v3.gdlerr.txt" 
"/<>/test/GrcRegressionTest/fonts/PigLatinMain.gdl" 
"/<>/test/GrcRegressionTest/fonts/PigLatinInput.ttf" "PigLatinTest_v3.ttf"

10: Working Directory: 
/<>/obj-s390x-linux-gnu/test/Gr

Bug#1018895: gcolor3: color picking fails due to No such interface “org.freedesktop.portal.Screenshot”

2022-09-01 Thread Stefan Breunig

Package: gcolor3
Version: 2.4.0-2
Severity: normal
X-Debbugs-Cc: stefan-deb...@yrden.de

Dear Maintainer,

it seems that gcolor3's ability to pick colors broke at some point. I am fairly 
certain it
worked a while ago. When run from a terminal and trying to pick a color, it 
prints:

   Failed to pick color: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: 
No such
   interface “org.freedesktop.portal.Screenshot” on object at path 
/org/freedesktop/portal/desktop

I run X11. I'm guessing I am missing a dependency, but not sure which.

Thanks
Stefan

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


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 gcolor3 depends on:
ii  libatk1.0-0  2.38.0-1
ii  libc62.34-4
ii  libcairo21.16.0-6
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.72.3-1+b1
ii  libgtk-3-0   3.24.34-3
ii  libportal-gtk3-1 0.6-2
ii  libportal1   0.6-2

gcolor3 recommends no packages.

gcolor3 suggests no packages.

-- no debconf information

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

2022-09-01 Thread Thorsten Glaser

Hi Helge,

[…]
> Yes, that would be the best option. A few days ago I informed all
> translation teams about the transfer of translations to sysvinit, so 
> if the French team could integrate the translation of bootlogd there, 
> that'll be great.

ok, great!

> For Debian, as stated above, I can do another upload removing this
> file as well.

Thanks. Feel free to reassign/close this bug at will then… or do we
need another sysvinit upload with updated Replaces/Breaks/… as well,
Andreas?

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

2022-09-01 Thread Helge Kreutzmann

Hello Thorsten,
On Thu, Sep 01, 2022 at 06:39:18PM +0200, Thorsten Glaser wrote:
> […]
> > Yes, that would be the best option. A few days ago I informed all
> > translation teams about the transfer of translations to sysvinit, so 
> > if the French team could integrate the translation of bootlogd there, 
> > that'll be great.
> 
> ok, great!
> 
> > For Debian, as stated above, I can do another upload removing this
> > file as well.
> 
> Thanks. Feel free to reassign/close this bug at will then… or do we
> need another sysvinit upload with updated Replaces/Breaks/… as well,
> Andreas?

I'll do the upload on the weekend. I guess the best is that you close
it afterwards? Or reassign it to manpages-l10n?

Greetings

Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

2022-09-01 Thread Helge Kreutzmann

Hello Torsten et al,
On Wed, Aug 31, 2022 at 11:04:25PM +0200, Thorsten Glaser wrote:
> On Wed, 31 Aug 2022, Mark Hindley wrote:
> 
> > > there seems to be one manpage (in bootlogd) missing conflict handling:
> > > 
> > > /usr/share/man/fr/man8/bootlogd.8.gz
> > 
> > Thanks. I was under the impression that manpages-i10n had changed to
> > systemd versions (which doesn't have bootlogd.8) but apparently not. I
> > think we should continue to use the manpages-i10n version and not have
> > any more dpkg diversions than are absolutely necessary.

No. This is not the intention, quite the contrary. This file probably
escaped me, because I did not realize that the package bootlogd
originates from sysvinit. 

I can do another upload removing this file as well.

> > I am away for a week, but will resolve this once I am back.
> 
> Perhaps in this time a french speaker can compare the two versions,
> from sysvinit and manpages-l10n, and see which one is “better”, then
> contribute that to sysvinit so manpages-l10n can remove theirs as
> bootlogd isn’t provided with systemd?

Yes, that would be the best option. A few days ago I informed all
translation teams about the transfer of translations to sysvinit, so 
if the French team could integrate the translation of bootlogd there, 
that'll be great.

I suggest we keep this source file in the manpage l10n upstream repository 
for a few more weeks and then I ask upstream (Mario Blättermann) to move
it to the archive. (Best if the French team would indicate a good
time).

For Debian, as stated above, I can do another upload removing this
file as well.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/

signature.asc
Description: PGP signature

Bug#1018894: rescue-mode: mounts wrong btrfs subvolume

2022-09-01 Thread Ansgar

Source: rescue
Version: 1.85
Severity: important

I've installed a system using btrfs for the root filesystem with d-i
(with disk encryption as well). As grub wasn't properly installed
(not registered with EFI), I tried to use the rescue mode to reinstall
grub.

However, mounting the root filesystem failed: /target contained only a
"@rootfs" subdirectory. So running a shell in the target fs failed.
Manually mounting the filesystem with `-o subvol=@rootfs` worked.

This was with Debian 11.4.

Ansgar

Bug#1017425: closed by Debian FTP Masters (reply to Salvatore Bonaccorso ) (Bug#1017425: fixed in linux 5.19.6-1)

2022-09-01 Thread Salvatore Bonaccorso

Hi,

On Thu, Sep 01, 2022 at 06:03:41PM +0300, Martin-Éric Racine wrote:
> This bug was reported against Stable. It cannot be considered as
> closed for as long as a new 5.10 kernel including the fix hasn't been
> published.

it very well can. The BTS can close a bug in multiple versions which
will be done here. A second time with the version for 5.10.y when it
hits stable.

Regards,
Salvatore

Bug#1018890: uploaded to NEW

2022-09-01 Thread Antoine Beaupré

Control: tags -1 +pending

Uploaded to experimental, should end up in NEW soon.

Bug#1018893: support for unshare in some form

2022-09-01 Thread Jelmer Vernooij

Package: piuparts
Severity: wishlist

It would be great if piuparts supported root-less operation, ideally in a less
complicated way than via podman+docker.

Conversation in #debian-qa suggests the are various options for building on
top of infrastructure that's provided by other packages, e.g. sbuild,
autopkgtest or mmdebootstrap.

 Jelmer, h01ger: I'd second what helmut said. With mmdebstrap you get 
the equivalent of "lxc-usernsexec -- lxc-unshare -s 'MOUNT|PID|UTSNAME|IPC' -- 
/usr/sbin/chroot ./debian-rootfs /bin/bash" but without having to depend on lxc 
-- You can see a variant of this in the mmdebstrap man page where mmdebstrap is 
used as a wrapper of debootstrap to fix #829134. That way you can run 
debootstrap without 
needing root: mmdebstrap --variant=custom --mode=unshare --setup-hook='env 
container=lxc debootstrap unstable "$1"' - debian-debootstrap.tar

Alternatively, if you want to depend on neither lxc nor mmdebstrap, a number of 
tools implemented a simple unshare backend already using code like this:

https://salsa.debian.org/debian/sbuild/-/blob/main/lib/Sbuild/Utility.pm#L382

or this: 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/virt/autopkgtest-virt-unshare#L131

re-using the unshare functionality of either mmdebstrap, sbuild or autopkgtest 
would probably be best

there was some discussion whether those three tools could share some code here: 
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/138#note_306768
unfortunately i don't see how

if somebody wants to work on unshare support for piuparts, feel free to ask me 
questions about unshare or its implementation in mmdebstrap, sbuild or 
autopkgtest

the other people in the know are smcv and jochensp

oh and there is this as a standalone replacement: 
https://gitlab.mister-muffin.de/josch/user-unshare/src/branch/main/user-unshare

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

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

Versions of packages piuparts depends on:
ii  debootstrap  1.0.127
pn  debsums  
ii  libjs-sphinxdoc  4.5.0-4
ii  lsb-release  11.2
ii  lsof 4.95.0-1
ii  mount2.38.1-1
pn  piuparts-common  
ii  python3  3.10.6-1
ii  python3-debian   0.1.47

Versions of packages piuparts recommends:
pn  adequate  

Versions of packages piuparts suggests:
pn  docker.io  
pn  schroot

Bug#1018892: RFS: atomes [ITP] -- friendly greeter

2022-09-01 Thread Sébastien Le Roux


Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : atomes
Version : 1.1.0
Upstream Author : Sébastien Le Roux [sebastien.ler...@ipcms.unistra.fr]
* URL : https://atomes.ipcms.unistra.fr
* License : Affero GPL v3
* Vcs : https://github.com/Slookeur/Atomes-deb-build
Section : physics, chemistry, education

The sources build the following binary package:

Atomes: a toolbox to analyze, to visualize and to edit/create 
three-dimensional atomistic models.
It oﬀers a workspace that allows to have many projects opened 
simultaneously.
The different projects in the workspace can exchange data: analysis 
results, atomic coordinates ...
Atomes also provides an advanced input preparation system for further 
calculations using well known molecular dynamics codes:


 * Classical MD : DLPOLY
    and LAMMPS
   
 * ab-initio MD : CPMD  and CP2K
   
 * QM-MM MD : CPMD  and CP2K 

To prepare the input ﬁlles for these calculations is likely to be the 
key, and most complicated step towards MD simulations.
Atomes offers a user-friendly assistant to help and guide the user step 
by step to achieve this crucial step.


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


https://atomes.ipcms.unistra.fr

You can access the sources of the program here:

https://github.com/Slookeur/Atomes

For the deb packages here:

https://github.com/Slookeur/Atomes-deb-build

This is the first official release of the Atomes program.

Best regards and thank you for the time you will spend with that review.

Sébastien

--
===
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail:sebastien.ler...@ipcms.unistra.fr
Webpage:https://www.ipcms.fr/sebastien-le-roux/
RINGS project:http://rings-code.sourceforge.net/
ISAACS project:http://isaacs.sourceforge.net/
Fax:   +33 3 88 10 72 46
Phone: +33 3 88 10 71 58
===

Bug#1018891: general: Can't install fans on msi laptop due to missing ec_sys kernel. Command prompt modprobe ec_sys write_support=1, I get error: FATAL: Module ec_sys not found in directory /lib/modul

2022-09-01 Thread Psyho786

Package: general
Severity: normal
X-Debbugs-Cc: velmory...@gmail.com

Dear Maintainer,

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

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

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

Bug#1018890: ITP: pubpaste -- publish files and clipboard online easily

2022-09-01 Thread Antoine Beaupre

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

* Package name: pubpaste
  Version : 0.6
  Upstream Author : Antoine Beaupré 
* URL : https://gitlab.com/anarcat/pubpaste/
* License : AGPL
  Programming Lang: Python
  Description : publish files and clipboard online easily

This tool makes it easy to publish files, clipboards, screenshots, and
photo galleries online with a single command. It's somewhat messy but
it does its job well.

pubpaste is not for novice users: it assumes you have access to an SSH
server and know how to configure a YAML file. It has been written by
and for its author in a fit of egoistical mania (unfortunately typical
for hackers), apologies normal humans out there reading this.

Bug#1017425: closed by Debian FTP Masters (reply to Salvatore Bonaccorso ) (Bug#1017425: fixed in linux 5.19.6-1)

2022-09-01 Thread Martin-Éric Racine

This bug was reported against Stable. It cannot be considered as
closed for as long as a new 5.10 kernel including the fix hasn't been
published.

Martin-Éric

On Thu, Sep 1, 2022 at 5:15 PM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the src:linux package:
>
> #1017425: [i386] Unconditional LFENCE instructions in FILL_RETURN_BUFFER
>
> It has been closed by Debian FTP Masters  
> (reply to Salvatore Bonaccorso ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Salvatore Bonaccorso 
> ) by
> replying to this email.
>
>
> --
> 1017425: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017425
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 1017425-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 01 Sep 2022 14:10:11 +
> Subject: Bug#1017425: fixed in linux 5.19.6-1
> Source: linux
> Source-Version: 5.19.6-1
> Done: Salvatore Bonaccorso 
>
> We believe that the bug you reported is fixed in the latest version of
> linux, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1017...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Salvatore Bonaccorso  (supplier of updated linux package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Thu, 01 Sep 2022 09:04:35 +0200
> Source: linux
> Architecture: source
> Version: 5.19.6-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Kernel Team 
> Changed-By: Salvatore Bonaccorso 
> Closes: 1016807 1017425 1017894 1017972 1018752
> Changes:
>  linux (5.19.6-1) unstable; urgency=medium
>  .
>* New upstream stable update:
>  https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.1
>  https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
>  - Revert "net: usb: ax88179_178a needs FLAG_SEND_ZLP" (Closes: #1017894)
>  https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.3
>  https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.4
>  https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.5
>  https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6
>  - mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW
>(CVE-2022-2590)
>  - af_key: Do not call xfrm_probe_algs in parallel (CVE-2022-3028)
>  - [x86] nospec: Unwreck the RSB stuffing
>  - [x86] nospec: Fix i386 RSB stuffing (Closes: #1017425)
>  - bpf: Don't use tnum_range on array range checking for poke descriptors
>(CVE-2022-2905)
>  .
>[ Ben Hutchings ]
>* d/tests/kbuild: Fix default-flavour lookup for arches with no featuresets
>* d/tests/kbuild: Make flavour lookup verbose
>* d/lib/python/debian_linux, d/templates: Use variable for binary package
>  name
>* lintian: Update overrides in linux-image-*-dbg for lintian 2.115
>* d/{signing_templates/,}rules.real: Run dh_lintian for all packages
>* [hppa,mips,mipsel,powerpc] lintian: Override error for 64-bit kernels
>* [mips64el,mipsel,ppc64el] lintian: Override error for unstripped vmlinux
>* [arm64] lintian: Override errors for vdso32.so in linux-image-*-dbg
>* android: Remove CONFIG_ANDROID:
>  - Drop "wireguard: Clear keys after suspend despite CONFIG_ANDROID=y"
>  - pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
>  - remove CONFIG_ANDROID
>  - Enable/disable ANDROID_BINDER_IPC to match previous configuration
>  .
>[ Vincent Blut ]
>* [x86] drivers/hwmon: Enable SENSORS_ASUS_WMI and SENSORS_ASUS_EC as
>  modules
>* [x86] drivers/platform/x86: Enable NVIDIA_WMI_EC_BACKLIGHT as module
>  (Closes: #1017972)
>* [arm64] drivers/spi: Enable SPI_GPIO and SPI_SUN6I as modules
>  (Closes: #1016807)
>  .
>[ Diederik de Haas ]
>* [arm64] drivers/gpu/drm/rockchip: Explicitly enable ROCKCHIP_VOP
>  .
>[ Helge Deller ]
>* [hppa] Drop CONFIG_PATA_LEGACY for hppa architecture
>  .
>[ Salvatore Bonaccorso ]
>* [rt] Refresh "rcutorture: Also force sched priority to timersd on 
> boosting
>  test."
>* Drop setting of CRYPTO_BLAKE2S
>  crypto: blake2s shash module was removed upstream.
>* [arm] arch/arm/crypto: Enable CRYPTO_BLAKE2S_ARM
>* certs: Rotate to use

Bug#1015888: pypi2deb: py2dsp fails with "KeyError: 'releases'"

2022-09-01 Thread Antoine Beaupre

Package: pypi2deb
Version: 2.20180804+nmu1
Followup-For: Bug #1015888

I confirm I also see the problem in bullseye right now, with:

py2dsp pubpaste

The patch suggested here:

https://lists.debian.org/debian-python/2022/07/msg00076.html

does not work either, the program instead fails with:


anarcat@curie:~$ py2dsp -v --application pubpaste
D: py2dsp py2dsp:141: version: 2.20180804
D: py2dsp py2dsp:142: ['/usr/bin/py2dsp', '-v', '--application', 'pubpaste']
D: py2dsp py2dsp:42: args: Namespace(verbose=True, quiet=False, 
root='/home/anarcat/result', clean=False, build=False, application=True, 
distribution='UNRELEASED', revision='0~py2deb', message='converte0~py2deb', 
profile=None, name='pubpaste')
E: py2dsp py2dsp:148: source package not available on PyPI
Traceback (most recent call last):
  File "/usr/bin/py2dsp", line 146, in 
loop.run_until_complete(main(args))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in 
run_until_complete
return future.result()
  File "/usr/bin/py2dsp", line 64, in main
fname = yield from download(name, version=version, destdir=args.root)
  File "/usr/share/pypi2deb/pypi2deb/pypi.py", line 136, in download
raise Exception('source package not available on PyPI')
Exception: source package not available on PyPI

If i first make a `python setup.py sdist` and then run py2dsp on that,
it kind of succeeds (in the sense that it creates a result/ directory
that i can use) but fails to build the source package:

anarcat@curie:pubpaste$ py2dsp dist/pubpaste-0.6.tar.gz
dpkg-buildpackage: info: paquet source pubpaste
dpkg-buildpackage: info: version source 0.5-0~pypi2deb
dpkg-buildpackage: info: distribution source UNRELEASED
dpkg-buildpackage: info: source changé par Antoine Beaupré 
 dpkg-source -I.git -i.git --before-build .
dpkg-source: info: utilisation des options depuis 
pubpaste-0.6/debian/source/options : --extend-diff-ignore=^[^/]+.egg-info/
dpkg-buildpackage: avertissement: création d'un paquet source sans le nettoyer 
préalablement comme demandé ; il peut contenir des fichiers non souhaités
 dpkg-source -I.git -i.git -b .
dpkg-source: info: utilisation des options depuis 
pubpaste-0.6/debian/source/options : --extend-diff-ignore=^[^/]+.egg-info/
dpkg-source: erreur: impossible de construire avec le format source « 3.0 
(quilt) » : pas de tarball de sources amont à 
../pubpaste_0.5.orig.tar.{bz2,gz,lzma,xz}
dpkg-buildpackage: erreur: dpkg-source -I.git -i.git -b . subprocess returned 
exit status 2

Not sure why it thinks I'm on 0.5 there... 

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

Kernel: Linux 5.10.0-17-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 pypi2deb depends on:
ii  build-essential  12.9
ii  devscripts   2.21.3+deb11u1
ii  dh-python4.20201102+nmu1
ii  python3  3.9.2-3
ii  python3-aiohttp  3.7.4-1
ii  python3-debian   0.1.39
ii  python3-jinja2   2.11.3-1
ii  python3-redis3.5.3-2

Versions of packages pypi2deb recommends:
ii  python3-msgpack  1.0.0-6+b1

Versions of packages pypi2deb suggests:
pn  cython  
ii  cython3 0.29.21-3+b1
ii  pypy7.3.3+dfsg-2
pn  python-all-dev  
pn  python-nose 
pn  python-pytest   
pn  python-setuptools   
pn  python3-all-dev 
ii  python3-nose1.3.7-7
ii  python3-pytest  7.1.2-2
ii  python3-setuptools  52.0.0-4
ii  python3-sphinx  3.4.3-2

-- debconf-show failed

Bug#898400: ITP: sccache - compiler cache for fast recompilation of C/C++/Rust code

2022-09-01 Thread Jonas Smedegaard

Quoting Blair Noctis (2022-09-01 16:25:46)
> On 2022/9/1 22:01, Jonas Smedegaard wrote:
> > Speaking of write access: You should now have access to the repo in
> > Salsa: https://salsa.debian.org/debian/sccache
> 
> Received the notification email, thanks. I'll fisrt try to apply the
> uuid patch when uuid 1.1 is up in the archive.

Sounds good :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1018871: ibus-tests:armel: depends on gnome-shell:armel which is likely to be removed

On Thu, 01 Sep 2022 at 14:25:29 +0200, Gunnar Hjalmarsson wrote:
> given the
> current ibus packaging, maybe these lines in debian/rules would be more
> suitable:
> 
> ifeq ($(DEB_HOST_ARCH), armel)
>skip_packages = -Nibus-tests
> endif

That assumes that all other architectures that we care about have a
working mozjs/gjs, which is broadly true if you are not interested
in retrocomputing, but is an assumption that might need more future
maintenance, for example if it regresses on s390x or mips64el. It's up
to you whether you prefer to assume that unknown architectures do or
don't have a working mozjs/gjs.

To avoid this change's migration being blocked, you'll also need to set
Architecture: !armel in debian/tests/control. Otherwise, ci.debian.net
will interpret "the test needs ibus-tests, but I can't install that"
as a test failure on armel.

The reason I suggested assuming that unknown architectures don't have
mozjs/gjs is that mozjs usually requires per-architecture code to be
written (it's a complicated JIT implementation). It looks like bookworm
is likely to have a working gjs on

amd64 arm64 armhf i386 mips64el ppc64el s390x
(riscv64)

but not on

armel
(alpha arc hppa hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k powerpc 
ppc64 sh4 sparc64 x32)

where the architectures in parentheses are currently -ports architectures,
and the others are currently release candidates.

smcv

Bug#1018889: network-manager: After upgrade, PolicyKit-1 agent needs to share network settings.

2022-09-01 Thread Andreas Günther

Package: network-manager
Version: 1.30.6-1+deb11u1
Severity: normal

Dear Maintainer,

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

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

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

I upgraded my laptop with Debian Bookworm these days. And then after each 
reboot I had to log in as a user via the root password in the PolicyKit-1 agent 
share the network settings.
So the PolicyKit 1 agent popped up with the following message: "System policies 
prevent editing network settings for all users." 
My working solution so far is to give the user the “netdev” group to assign: 
usermod -G netdev andreas

This solution works, but the network manager should take care of that, not die 
group assignment "netdev" to all users.his solution works, but the network 
manager should take care of that, not die group assignment "netdev" to all 
users.


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

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

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-2
ii  libaudit11:3.0-2
ii  libbluetooth35.55-3.1
ii  libc62.31-13+deb11u3
ii  libcurl3-gnutls  7.74.0-1.3+deb11u2
ii  libglib2.0-0 2.66.8-1
ii  libgnutls30  3.7.1-5+deb11u2
ii  libjansson4  2.13.1-1.1
ii  libmm-glib0  1.14.12-0.2
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b3
ii  libnm0   1.30.6-1+deb11u1
ii  libpsl5  0.21.0-1.2
ii  libreadline8 8.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.3-7
ii  libteamdctl0 1.31-1
ii  libudev1 247.3-7
ii  libuuid1 2.36.1-8+deb11u1
ii  policykit-1  0.105-31+deb11u1
ii  udev 247.3-7
ii  wpasupplicant2:2.9.0-21

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iptables 1.8.7-1
ii  libpam-systemd   247.3-7
ii  modemmanager 1.14.12-0.2
ii  ppp  2.4.9-1+1
ii  wireless-regdb   2022.04.08-2~deb11u1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.3
pn  libteam-utils

-- no debconf information

Bug#1015027: php-dragonmantank-cron-expression: Fix FTBFS salsa MR


I have proposed a salsa MR to skip the offending tests at
https://salsa.debian.org/php-team/pear/php-dragonmantank-cron-expression/-/merge_requests/1.

I also forwarded the patch upstream with an explanation on why the tests
should be skipped at the moment [1].

[1] https://github.com/dragonmantank/cron-expression/issues/133

--
Athos Ribeiro

Bug#1017450: eom: Viewing webp images

There are 3 things needed for eom to fully support these formats.

- They ought to have a gdk-pixbuf loader
- They ought to have a thumbnailer
- The mimetypes needs to be listed in the .desktop

I'll add webp-pixbuf-loader to the Depends. That binary package has
both the gdk-pixbuf-loader and the thumbnailer (sometimes, there would
be a separate Debian package for one).

But neither avif or heif are listed in the MimeTypes currently. You
may want to report that upstream or submit a merge proposal there.

Thank you,
Jeremy Bicha

Bug#1012860: eom: Should recommend libgdk-pixbuf2.0-bin

Control: severity -1 minor

eom already Depends on libgdk-pixbuf-2.0-0 which Recommends libgdk-pixbuf2.0-bin

Please keep the Debian default of installing Recommends and you won't
get subtle bugs like this where things don't 100% work for you but
work for everyone else.

Thank you,
Jeremy Bicha

Bug#898400: ITP: sccache - compiler cache for fast recompilation of C/C++/Rust code

2022-09-01 Thread Blair Noctis


On 2022/9/1 22:01, Jonas Smedegaard wrote:

Quoting Blair Noctis (2022-09-01 14:52:42)

I see that you've removed some dependencies of dist-* feature and for
Windows, which I didn't realize could be done. However I'm not sure
why the redis, memcached, gcs, azure, s3 features are removed.

They are removed to get sccache into Debian sooner: When additional
dependencies are in Debian we can link against those as well.


Progressive approach, a lesson learned.


uuid is 0.8.1 in unstable, 1.1 on crates.io. Patching it is fairly
easy:

Nice that patching is easy.  Better would be to upgrade rust-uuid, but
until that is done I am ok carrying a patch with sccache.  Thanks!


My wording was a bit off - it's patching sccache to use uuid 1.1, not
to patch uuid itself. I do plan to update uuid to 1.1.


zstd is 0.5.1 in unstable, 0.11 on crates.io. I tried 0.11 on it with
no errors. But there's #969609 [1], not sure if I should push it.

I don't understand what you mean by "push it". What needs doing
regarding bug#969609 is (as I see it, but the bug belongs in the Rust
team so I contradict anything said in that team then listen to them!) to
package rust-zstd-safe - as indicated in the subject of that bugreport.

counted-array, local-encoding, pulldown-cmark, skeptic, tokio-serde,
tower, tower-layer are packaged locally, with local-encoding patched
to use skeptic 0.13 instead of 0.4, removing the dependency on
tempdir. I'll push them later on.

Again, not sure what you mean by "push them" - perhaps you are talking
Rust-team lingo of pushing to the all-crates-in-one-giant-git repo -
which I in Debian lingo would call packaging officially for Debian.


Oh, the lingo systems ;) I meant pushing the changes to the git repo(s),
not necessarily the Rust team's all-in-one repo, and not necessarily
packaging the updates. I just didn't find a word good enough to describe
"push to a git repo" in the broader context.


Btw, do you mind using salsa's issues and merge requests, or prefer
emails?

I prefer not having to use Salsa - but I am not a hardcore
do-it-all-with-mail either: I prefer pushing to git and then share in
email an URI to wherever you pushed it - e.g. a git clone or (when you
have write access) a temporary branch (I like the naming scheme wip/*
for such throwaway branches).


Just another way to collaboration, totally understand ;)


Speaking of write access: You should now have access to the repo in
Salsa: https://salsa.debian.org/debian/sccache


Received the notification email, thanks. I'll fisrt try to apply the
uuid patch when uuid 1.1 is up in the archive.

--
Regards,
Blair Noctis



OpenPGP_signature
Description: OpenPGP digital signature

Bug#898400: ITP: sccache - compiler cache for fast recompilation of C/C++/Rust code

2022-09-01 Thread Jonas Smedegaard

Quoting Blair Noctis (2022-09-01 14:52:42)
> I see that you've removed some dependencies of dist-* feature and for
> Windows, which I didn't realize could be done. However I'm not sure
> why the redis, memcached, gcs, azure, s3 features are removed.

They are removed to get sccache into Debian sooner: When additional
dependencies are in Debian we can link against those as well.


> zstd is 0.5.1 in unstable, 0.11 on crates.io. I tried 0.11 on it with
> no errors. But there's #969609 [1], not sure if I should push it.

I don't understand what you mean by "push it". What needs doing
regarding bug#969609 is (as I see it, but the bug belongs in the Rust
team so I contradict anything said in that team then listen to them!) to
package rust-zstd-safe - as indicated in the subject of that bugreport.


> uuid is 0.8.1 in unstable, 1.1 on crates.io. Patching it is fairly
> easy:

Nice that patching is easy.  Better would be to upgrade rust-uuid, but
until that is done I am ok carrying a patch with sccache.  Thanks!


> counted-array, local-encoding, pulldown-cmark, skeptic, tokio-serde,
> tower, tower-layer are packaged locally, with local-encoding patched
> to use skeptic 0.13 instead of 0.4, removing the dependency on
> tempdir. I'll push them later on.

Again, not sure what you mean by "push them" - perhaps you are talking
Rust-team lingo of pushing to the all-crates-in-one-giant-git repo -
which I in Debian lingo would call packaging officially for Debian.

NB! I don't mean to say that you are saying it wrong - only genuinely
that I am uncertain what you mean: As I understand it, Rust team
deliberately is "more Rust-like than Debian-like" to lower the bar for
newcomers - where I consider it important for Debian packaging to be
"more Debian-like" to ease the long-term maintenance.  I certainly don't
want to discourage newcomers in Debian - just tell you up front whenever
your lingo confuses me and I hope you will do the same :-)


> Btw, do you mind using salsa's issues and merge requests, or prefer
> emails?

I prefer not having to use Salsa - but I am not a hardcore
do-it-all-with-mail either: I prefer pushing to git and then share in
email an URI to wherever you pushed it - e.g. a git clone or (when you
have write access) a temporary branch (I like the naming scheme wip/*
for such throwaway branches).

Speaking of write access: You should now have access to the repo in
Salsa: https://salsa.debian.org/debian/sccache


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1017915: btrfs: space cache corruption and potential double allocations

2022-09-01 Thread Christoph Anton Mitterer

Control: tags -1 + patch

Hey.

The patch for this has been merged in the stable kernels... could you
please cherry pick respectively update the sid kernel ASAP?

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6

commit: a2e54eb64229f07f917b05d0c323604fda9b89f7
btrfs: fix space cache corruption and potential double allocations


Thanks,
Chris.

Bug#1018888: nmu: elastix_5.0.1-3+b1

2022-09-01 Thread Steve M. Robbins

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

nmu elastix_5.0.1-3+b1 . ANY . unstable . -m "Rebuild against updated
insighttoolkit5"

Bug#1018887: ITP: cwl-utils -- Python Utilities and Autogenerated Classes for CWL v1.0 - v1.2

2022-09-01 Thread Michael R. Crusoe

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: cwl-utils -- Python Utilities and Autogenerated Classes for CWL 
v1.0 - v1.2
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: cwl-utils
  Version : 0.16
  Upstream Author : Copyright: Common workflow language working group 

* URL : https://github.com/common-workflow-language/cwl-utils
* License : Apache-2.0
  Programming Lang: Python
  Description : Python Utilities and Autogenerated Classes for CWL v1.0 - 
v1.2
 The autogenerated classes can create, load, and save objects based upon CWL
 (the Common Workflow Language open standards for executable descriptions of
 comandline tools and workflows made from them).
 .
 See the 'cwl-utils' package for command line utilities that use these classes.

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/cwl-utils

Bug#950687: ITP: depthcharge-tools -- Tools to manage the Chrome OS bootloader

2022-09-01 Thread Alper Nebi Yasak

On 29/08/2022 16:35, Jérémy Lal wrote:
> Hi,
> now that I have three c201 chromebooks running debian/bookworm
> thanks to depthcharge-tools, I might be a good candidate to sponsor that 
> package.
> 
> Do you still care for it ?

Yes, and I actually had a talk on this at DebConf22 [1]!

But first let me work on it for a few days to undo some decisions I
realized was wrong in retrospect, update the boards database, test that
it'll play nice with the d-i integration, tag a minor release... Then,
I'll send a RFS.

My current packaging attempt is on salsa [2] by the way.

[1] Solving "How Can I Run Debian on My Chromebook?" For Good
https://debconf22.debconf.org/talks/87-solving-how-can-i-run-debian-on-my-chromebook-for-good/

[2] alpernebbi/depthcharge-tools repository on salsa.d.o
https://salsa.debian.org/alpernebbi/depthcharge-tools

Bug#898400: ITP: sccache - compiler cache for fast recompilation of C/C++/Rust code

2022-09-01 Thread Blair Noctis


Hi Jonas,

I see that you've removed some dependencies of dist-* feature and for
Windows, which I didn't realize could be done. However I'm not sure
why the redis, memcached, gcs, azure, s3 features are removed.

zstd is 0.5.1 in unstable, 0.11 on crates.io. I tried 0.11 on it with
no errors. But there's #969609 [1], not sure if I should push it.

uuid is 0.8.1 in unstable, 1.1 on crates.io. Patching it is fairly
easy:


--- a/Cargo.toml
+++ b/Cargo.toml
@@ -268,7 +268,7 @@
 optional = true

 [dependencies.uuid]
-version = "0.8"
+version = "1.1"
 features = ["v4"]

 [dependencies.version-compare]
--- a/src/dist/client_auth.rs
+++ b/src/dist/client_auth.rs
@@ -513,7 +513,7 @@
 let port = server.local_addr().port();

 let redirect_uri = format!("http://localhost:{}/redirect";, port);
-    let auth_state_value = Uuid::new_v4().to_simple_ref().to_string();
+    let auth_state_value = Uuid::new_v4().as_simple().to_string();
 let (verifier, challenge) = 
code_grant_pkce::generate_verifier_and_challenge()?;

 code_grant_pkce::finish_url(
 client_id,
@@ -567,7 +567,7 @@
 let port = server.local_addr().port();

 let redirect_uri = format!("http://localhost:{}/redirect";, port);
-    let auth_state_value = Uuid::new_v4().to_simple_ref().to_string();
+    let auth_state_value = Uuid::new_v4().as_simple().to_string();
 implicit::finish_url(client_id, &mut auth_url, &redirect_uri, 
&auth_state_value);


 info!("Listening on http://localhost:{} with 1 thread.", port);
--- a/tests/harness/mod.rs
+++ b/tests/harness/mod.rs
@@ -633,7 +633,7 @@
 "{}_{}_{}",
 CONTAINER_NAME_PREFIX,
 tag,
-    Uuid::new_v4().to_hyphenated_ref()
+    Uuid::new_v4().as_hyphenated()
 )
 }


counted-array, local-encoding, pulldown-cmark, skeptic, tokio-serde,
tower, tower-layer are packaged locally, with local-encoding patched
to use skeptic 0.13 instead of 0.4, removing the dependency on
tempdir. I'll push them later on.

Btw, do you mind using salsa's issues and merge requests, or prefer
emails?

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

--
Regards,
Blair Noctis



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018884: nautilus-kdeconnect: Needs to be updated for Nautilus 43