date:20221022

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-socks
  Version : 0.3.4
  Upstream Author : Steven Fackler 
* URL : https://github.com/sfackler/rust-socks
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : SOCKS proxy clients

 SOCKS proxy support for Rust.
 .
 SOCKS is an Internet protocol that exchanges network packets
 between a client and server through a proxy server.
 SOCKS5 optionally provides authentication
 so only authorized users may access a server.
 Practically, a SOCKS server proxies TCP connections
 to an arbitrary IP address,
 and provides a means for UDP packets to be forwarded.

This package will be maintained in the collaborative Debian section of
Salsa, at .

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNUWqIACgkQLHwxRsGg
ASEnzA/9GOgjebaEL0HTr5+YS2NT4Tbs2PajdkWvWemLhpsHSAx+rdfSqL4L6CD7
3BD9njKirPH908XvXIcGm0IyyoQ/RG+OwmH1Ul1uftltwZrwjhnLLZi4v+BM/GDL
fpe5hg1rnp6yyFBjo9sfoxo9URqo6F/ee40OPRhrVzcCwNOQs1GlqYvXEMvSCkel
20YY13RV0VUXnDtDssyDNsG3V8ta01Q1rGAypZkybsch8KiqpY3ZUVZvmcuCb5wu
eFfrVo41ctgbClVryrUeKAslw2MDmZP/wLbSEnoZ9OZ6siFoe5ZYvPp+bd5KmWoC
gkBa8pNiw4XR4VlicccSZCisXmj8GqZ4JH4NJtqmzvlcm2lh2O+J4Mu5hNNs/WCE
iVHnu7/iPjPQdn1gP8HI2nDjkp2jiReG7jkkiZPRC5ntANDpWNn519+s1pLnUJZO
FyP5HVJmN0G//pocfQq5cud37xL9Uc8wIxQFMMaIv8wWE9elAFWBMOwnFO79oRpd
5Lj2uuYpUb6Icc1Zdz4rUUpglqXfSh/rATKE7CaHjLu6bHBcvhausSatKyxSggat
xhw1vgS8xVG8akOqjDyZWVSApZgLYpJxKrhBqVdxGJcnq804d5o6azVO+TbU2aMY
uxyywifDbbLf9Srq9/o9+4ogJsb3Jedz18ak/I0wCQb2w9SkbQI=
=6aIe
-END PGP SIGNATURE-

Bug#1022198: rust-rustyline: please upgrade to v9

Quoting John Goerzen (2022-10-22 20:01:51)
> 
> On Sat, Oct 22 2022, Jonas Smedegaard wrote:
> 
> > In Debian we use ITP bugreports to reduce the risk of such "race
> > conditions".
> 
> Not for packages that are already in unstable as this one was.  Or, for
> Rust libraries, per:
> 
> https://salsa.debian.org/rust-team/debcargo-conf#itps

Ah right, this is not about new packages.

And right, my point was exactly unlike Debian the Rust team plays by its
own rules.  Enjoy!


 - 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#1014460: transition: php8.2

2022-10-22 Thread Ondřej Surý

Hi Paul,

I don’t recall any major changes to the toolchain, but I’ll double check. I 
switched some of the PECL extensions to use separate sources for different PHP 
version, so I don’t have to bundle old versions with new in single tarball, so 
it might be a good time to finish this, so bookworm has a cleaner state of PECL 
extension packages.

Ondrej
--
Ondřej Surý  (He/Him)

> On 22. 10. 2022, at 16:56, Paul Gevers  wrote:
> 
> I also recall php toolchain changes in the last transition. If there are any 
> pending toolchain changes, please make sure that they are deferred or 
> migrated to testing already, before we start the transition.

Bug#1022254: eclib breaks sagemath autopkgtest on i386: Error: 363 tests failed, up to 100 failures are tolerated


Control: retitle 1022254 sagemath autopkgtest regressed
Control: reassign 1022254 src:sagemath 9.5-4

On Sat, 22 Oct 2022 21:35:11 +0200 Paul Gevers  wrote:
With a recent upload of eclib the autopkgtest of sagemath fails in 
testing when that autopkgtest is run with the binary packages of eclib 
from unstable. It passes when run with only packages from testing. In 
tabular form:


Turns out that sagemath regressed on amd64, and arm64 regressed in 
testing. I assume i386 will show the same once the reference run finishes.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022256: upgrade-reports: gnustep-base-common blocks upgrade from bullseye to bookworm because of version dependencies

2022-10-22 Thread Daniel Savi

Package: upgrade-reports
Severity: important
X-Debbugs-Cc: pub...@gaess.ch

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release is: bullseye
I am upgrading to: bookworm
Archive date: unknown
Upgrade date: 10-22-22

- Did any packages fail to upgrade?
gnustep-base-common could not be upgraded due to a versioning conflict. 
Happened on two independent systems. The upgrade to bookworm failed for that 
reason.
Removing gnustep-base-common prior to the upgrade helped.

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-10-22 Thread Ondřej Surý

Hey David,

I'll be uploading the PECL extensions for PHP 8.2 to experimental as I will 
update them
for PHP 8.2 - I haven't started yet, but should be able to do before or around 
the PHP 8.2.0
release.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 22. 10. 2022, at 16:25, David Prévot  wrote:
> 
> Hi Ondřej, Mike and Horde team, PHP PEAR and Composer team, and Release team.
> 
> Le 21/07/2022 à 13:22, David Prévot a écrit :
>> Le 14/07/2022 à 15:23, Paul Gevers a écrit :
>>> Control: forwarded -1 
>>> https://release.debian.org/transitions/html/php8.2.html
>> […]
>> php-defaults was updated in experimental, allowing us to spot some 
>> regressions thanks to autopkgtests.
> 
> There is a new URL/view, thanks Paul for the hint:
> 
> https://qa.debian.org/excuses.php?experimental=1=php-defaults
> 
> There are still over twenty packages that need fixing in the Horde camp, 
> probably most of them could use a “Restrictions: allow-stderr” workaround in 
> debian/tests/control.
> 
>> Thanks in advance if you can try and help fixing those issues. You’re more 
>> than welcome to report bugs against packages in order to document the 
>> problem, and eventual hints to get them fixed.
>> Severity: important
>> Control: block 1014460 by -1
> 
> I’ve filed three bugs like that (for php-nesbot-carbon, shaarli and cacti), 
> am crossing fingers that the latest php-proxy-manager upload will fix its 
> issue, and hope that the recent issue that popped up with phpunit, 
> phpunit-type and php-doctrine-common (that looks similar) will fix itself 
> soon enough too (upstream being usually pretty reactive). php-log is still 
> not in testing, so not a blocker.
> 
> I believe there are no more blockers that could be spotted with debci. Since 
> not all packages have tests, and those tests can’t spot every regressions, 
> there will probably be more issues, but I believe it looks good for now 
> (especially compared to previous transitions). I believe the first (non RC) 
> PHP 8.2 release is expected upstream in a month, so, if that’s the targeted 
> version for Bookworm, I hope this transition could happen as soon as possible.
> 
> Ondřej, there were some missing php8.1-* packages that needed NEW processing 
> last time, have all php8.2-* packages been processed this time?
> 
> Regards
> 
> David



signature.asc
Description: Message signed with OpenPGP

Bug#1022255: python-xarray breaks satpy autopkgtest


Source: python-xarray, satpy
Control: found -1 python-xarray/2022.10.0-1
Control: found -1 satpy/0.37.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
python-xarray  from testing2022.10.0-1
satpy  from testing0.37.1-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of python-xarray to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

[1] https://qa.debian.org/excuses.php?package=python-xarray

https://ci.debian.net/data/autopkgtest/testing/amd64/s/satpy/27389134/log.gz

 TestNIRReflectance.test_no_sunz_no_co2 



self = testMethod=test_no_sunz_no_co2>

calculator = 
apply_modifier_info = id='139765627664464'>

sza = 

@mock.patch('satpy.modifiers.spectral.sun_zenith_angle')
@mock.patch('satpy.modifiers.NIRReflectance.apply_modifier_info')
@mock.patch('satpy.modifiers.spectral.Calculator')
def test_no_sunz_no_co2(self, calculator, apply_modifier_info, sza):
"""Test NIR reflectance compositor with minimal parameters."""
calculator.return_value = mock.MagicMock(
reflectance_from_tbs=self.refl_from_tbs)
sza.return_value = self.da_sunz
from satpy.modifiers.spectral import NIRReflectance
comp = NIRReflectance(name='test')
info = {'modifiers': None}
res = comp([self.nir, self.ir_], optional_datasets=[], **info)
>   self.get_lonlats.assert_called()

/usr/lib/python3/dist-packages/satpy/tests/test_modifiers.py:244: _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 

def assert_called(self):
"""assert that the mock was called at least once
"""
if self.call_count == 0:
msg = ("Expected '%s' to have been called." %
   (self._mock_name or 'mock'))

  raise AssertionError(msg)

E   AssertionError: Expected 'get_lonlats' to have been called.

/usr/lib/python3.10/unittest/mock.py:888: AssertionError
___ TestSceneLoading.test_load_comp4 
___


self = 

def test_load_comp4(self):
"""Test loading a composite that depends on a composite."""
scene = Scene(filenames=['fake1_1.txt'], reader='fake1')
scene.load(['comp4'])
loaded_ids = list(scene._datasets.keys())

  assert len(loaded_ids) == 1

E   AssertionError: assert 2 == 1
E+  where 2 = len([DataID(name='comp2'), DataID(name='ds3', 
modifiers=())])


/usr/lib/python3/dist-packages/satpy/tests/test_scene.py:1059: 
AssertionError
-- Captured log call 
---
WARNING  satpy.scene:scene.py:1275 The following datasets were not 
created and may require resampling to be generated: DataID(name='comp4')
___ TestSceneLoading.test_load_multiple_resolutions 



self = 

def test_load_multiple_resolutions(self):
"""Test loading a dataset has multiple resolutions available 
with different resolutions."""

scene = Scene(filenames=['fake1_1.txt'], reader='fake1')
comp25 = make_cid(name='comp25', resolution=1000)
scene[comp25] = xr.DataArray([], attrs={'name': 'comp25', 
'resolution': 1000})

scene.load(['comp25'], resolution=500)
loaded_ids = list(scene._datasets.keys())

  assert len(loaded_ids) == 2

E   AssertionError: assert 3 == 2
E+  where 3 = len([DataID(name='comp24', resolution=500), 
DataID(name='comp25', resolution=1000), DataID(name='ds5', 
resolution=500, modifiers=())])


/usr/lib/python3/dist-packages/satpy/tests/test_scene.py:1070: 
AssertionError
-- Captured log call 
---
WARNING  satpy.scene:scene.py:1275 The following datasets were not 
created and may require resampling to be generated: DataID(name='comp25')
_ TestSceneLoading.test_load_same_subcomposite 
_


self = 

def test_load_same_subcomposite(self):
"""Test loading a composite and one of it's subcomposites at 
the same time."""

scene = Scene(filenames=['fake1_1.txt'], reader='fake1')
scene.load(['comp24', 'comp25'], resolution=500)

Bug#1004634: A way to include openscenegraph in bookworm?

2022-10-22 Thread Dr. Tobias Quathamer


Hi,

I think it would be a pity to release bookworm without openscenegraph, 
also because there a quite a lot of reverse dependencies.


Unfortunately, there hasn't been much progress yet, and the freeze is 
coming nearer.


I've just spotted how Ubuntu solved this:

https://launchpad.net/ubuntu/+source/openscenegraph/3.6.5+dfsg1-7ubuntu1

They disabled ffmpeg support, so that the package can be included in 
their release, albeit with fewer features.


Would that be a solution for Debian as well?

IMHO, we could drop the support for ffmpeg now, upload the reduced 
version and allow all dependencies to migrate to testing again. *If* 
there is a patch available in time for ffmpeg support, we can still 
upload that version for bookworm.


What do you think?

Regards,
Tobias


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022254: eclib breaks sagemath autopkgtest on i386: Error: 363 tests failed, up to 100 failures are tolerated


Source: eclib, sagemath
Control: found -1 eclib/20221012-1
Control: found -1 sagemath/9.5-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
eclib  from testing20221012-1
sagemath   from testing9.5-4
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

Currently this regression is blocking the migration of eclib to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


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

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
eclib/20221012-1. I.e. due to versioned dependencies or breaks/conflicts.

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

https://ci.debian.net/data/autopkgtest/testing/i386/s/sagemath/27387916/log.gz

**
File "sage/src/sage/tests/cmdline.py", line 292, in 
sage.tests.cmdline.test_executable

Failed example:
print(out)
Expected:
499500
Got:

**
File "sage/src/sage/tests/cmdline.py", line 297, in 
sage.tests.cmdline.test_executable

Failed example:
ret
Expected:
0
Got:
1
**
File "sage/src/sage/tests/cmdline.py", line 300, in 
sage.tests.cmdline.test_executable

Failed example:
print(out)
Expected:
499500
Got:

**
File "sage/src/sage/tests/cmdline.py", line 304, in 
sage.tests.cmdline.test_executable

Failed example:
ret
Expected:
0
Got:
1
**
File "sage/src/sage/tests/cmdline.py", line 467, in 
sage.tests.cmdline.test_executable

Failed example:
out.find("555906056623") >= 0
Expected:
True
Got:
False
**
File "sage/src/sage/tests/cmdline.py", line 469, in 
sage.tests.cmdline.test_executable

Failed example:
err
Expected:
''
Got:
'/usr/bin/sage: line 629: exec: ipython3: not found\n'
**
File "sage/src/sage/tests/cmdline.py", line 471, in 
sage.tests.cmdline.test_executable

Failed example:
ret
Expected:
0
Got:
127
**
File "sage/src/sage/tests/cmdline.py", line 491, in 
sage.tests.cmdline.test_executable

Failed example:
print(err)
Expected:
Cython (http://cython.org) is a compiler for code written in the
Cython language.  Cython is based on Pyrex by Greg Ewing.
...
Got:
/usr/bin/sage: line 643: exec: cython: not found

**
File "sage/src/sage/tests/cmdline.py", line 570, in 
sage.tests.cmdline.test_executable

Failed example:
out.find("Maxima ") >= 0
Expected:
True
Got:
False
**
File "sage/src/sage/tests/cmdline.py", line 572, in 
sage.tests.cmdline.test_executable

Failed example:
err
Expected:
''
Got:
'/usr/bin/sage: line 697: exec: maxima: not found\n'
**
File "sage/src/sage/tests/cmdline.py", line 574, in 
sage.tests.cmdline.test_executable

Failed example:
ret
Expected:
0
Got:
127
**
1 item had failures:
  11 of 207 in sage.tests.cmdline.test_executable
[206 tests, 11 failures, 53.64 s]
sage -t --random-seed=293877373294513721178142072703805930767 
sage/src/sage/tests/gosper-sum.py

[100 tests, 35.58 s]
sage -t --random-seed=293877373294513721178142072703805930767 
sage/src/sage/tests/lazy_imports.py

[5 tests, 4.89 s]
sage -t --random-seed=293877373294513721178142072703805930767 
sage/src/sage/tests/modular_group_cohomology.py

[0 tests, 0.00 s]
sage -t --random-seed=293877373294513721178142072703805930767 
sage/src/sage/tests/numpy.py

[6 tests, 0.01 s]
sage -t

Bug#1022253: swi-prolog breaks logol autopkgtest on s390x


Source: swi-prolog, logol
Control: found -1 swi-prolog/8.4.3+dfsg-2
Control: found -1 logol/1.7.9+dfsg-5
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
swi-prolog from testing8.4.3+dfsg-2
logol  from testing1.7.9+dfsg-5
all others from testingfrom testing

I copied some of the output at the bottom of this report. I note that 
the last changelog for swi-prolog mentions endianness, s390x is our only 
big endian release architecture.


Currently this regression is blocking the migration of swi-prolog to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

[1] https://qa.debian.org/excuses.php?package=swi-prolog

https://ci.debian.net/data/autopkgtest/testing/s390x/l/logol/27384041/log.gz

calling logol with parameters -g 1799.logol -s 1799.fasta -dna
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied)
at java.base/java.io.FileOutputStream.open0(Native Method)
at java.base/java.io.FileOutputStream.open(FileOutputStream.java:298)
at java.base/java.io.FileOutputStream.(FileOutputStream.java:237)
at java.base/java.io.FileOutputStream.(FileOutputStream.java:158)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
at 
org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307)
	at 
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172)
	at 
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104)
	at 
org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842)
	at 
org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768)
	at 
org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672)
	at 
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516)
	at 
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580)
	at 
org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526)

at org.apache.log4j.LogManager.(LogManager.java:127)
at org.apache.log4j.Logger.getLogger(Logger.java:117)
at org.irisa.genouest.logol.Logol.(Unknown Source)
For help, use option -h
INFO org.irisa.genouest.logol.Logol  - Using configuration file: 
/usr/share/logol/prolog/logol.properties

INFO org.irisa.genouest.logol.Logol  - option g called with 1799.logol
INFO org.irisa.genouest.logol.Logol  - option s called with 1799.fasta
INFO org.irisa.genouest.logol.Logol  - No maximum solutions defined, 
using defaults

INFO org.irisa.genouest.logol.Logol  - option dna called
INFO org.irisa.genouest.logol.Logol  - Start analyse to create grammar 
analyser

Executing prolog for pre-analyse
java.io.FileNotFoundException: 
/tmp/1799.logol.f7104ea4-749d-45b1-8375-321313c4c203.pre.res (No such 
file or directory)

at java.base/java.io.FileInputStream.open0(Native Method)
at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
at java.base/java.io.FileInputStream.(FileInputStream.java:157)
at java.base/java.io.FileReader.(FileReader.java:75)
at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown Source)
at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown Source)
at org.irisa.genouest.logol.Logol.analyse(Unknown Source)
at org.irisa.genouest.logol.Logol.execute(Unknown Source)
at org.irisa.genouest.logol.Logol.main(Unknown Source)
INFO org.irisa.genouest.logol.Logol  - Analyse in progress..
WARN org.irisa.genouest.logol.SequenceAnalyser  - Path to suffix search 
tool is not set in system environment. Will try to execute directly but 
may fail if not in PATH of current user
ERROR org.irisa.genouest.logol.SequenceAnalyser  - Program exited with 
wrong status code: 134
Exception in thread "main" org.irisa.genouest.logol.GrammarException: 
ERROR: Coudld not execute program: Program exited with wrong status code

at org.irisa.genouest.logol.Logol.execute(Unknown Source)
at org.irisa.genouest.logol.Logol.main(Unknown Source)
autopkgtest [00:56:16]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

2022-10-22 Thread Vincent Lefevre

On 2022-10-22 17:33:03 +0200, Clément Hermann wrote:
> Le 22/10/2022 à 15:59, Vincent Lefevre a écrit :
> > I agree. There should be at least sufficient documentation when the
> > error occurs. If Debian could automatically provide the key and use
> > it, this would be better, IMHO: less work for the user, and this
> > would ensure (if correctly done) that the key is correct and still
> > valid.
> 
> Thing is, Debian cannot anticipate what modules you want to install via CPAN
> (so outside of Debian), so which developer keys to get, and also cannot
> install keys from all CPAN contributors in the user keyring…

I had to fetch a single key to be able to install 4 modules from
different developers. I hope that this isn't due to a bug.

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

Bug#1019682: [DRE-maint] Bug#1019682: schleuder: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: expect(error).to be_empty

2022-10-22 Thread Georg Faerber

Control: tags -1 + help

Hi Antonio, all,

Thanks for your report. I had a look, and I'm able to reproduce locally if
building the package, although so far I haven't been able to find out what is
causing this. I would be happy if someone is able to support me in debugging
this.

Looking at [1], which fails in the same way, I noticed:

Ignoring bcrypt-3.1.17 because its extensions are not built. Try: gem pristine 
bcrypt --version 3.1.17
Ignoring charlock_holmes-0.7.7 because its extensions are not built. Try: gem 
pristine charlock_holmes --version 0.7.7
Ignoring debug-1.4.0 because its extensions are not built. Try: gem pristine 
debug --version 1.4.0
Ignoring rbs-2.1.0 because its extensions are not built. Try: gem pristine rbs 
--version 2.1.0
Ignoring sdbm-1.0.0 because its extensions are not built. Try: gem pristine 
sdbm --version 1.0.0
Ignoring thin-1.8.0 because its extensions are not built. Try: gem pristine 
thin --version 1.8.0
Ignoring bcrypt-3.1.17 because its extensions are not built. Try: gem pristine 
bcrypt --version 3.1.17
Ignoring charlock_holmes-0.7.7 because its extensions are not built. Try: gem 
pristine charlock_holmes --version 0.7.7
Ignoring debug-1.4.0 because its extensions are not built. Try: gem pristine 
debug --version 1.4.0
Ignoring rbs-2.1.0 because its extensions are not built. Try: gem pristine rbs 
--version 2.1.0
Ignoring sdbm-1.0.0 because its extensions are not built. Try: gem pristine 
sdbm --version 1.0.0
Ignoring thin-1.8.0 because its extensions are not built. Try: gem pristine 
thin --version 1.8.0

Some of these are direct dependencies of Schleuder.

I'm mentioning this, because some days ago, [2] reported different errors:

Failure/Error: require 'thin'
LoadError:
  cannot load such file -- thin

To make all of this even more interesting: [3] reports no errors.

I'm wondering if different build environments are of relevance here.

Any clue, anyone?

Thanks in advance,
all the best,
Georg


[1] 
https://buildd.debian.org/status/fetch.php?pkg=schleuder=all=4.0.3-4.1=1666457954=0
[2] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/schleuder.html
[3] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/schleuder/27432900/log.gz

Bug#1022252: fuse3: update-initramfs fails on fuse hook

2022-10-22 Thread Joe Pfeiffer

Package: fuse3
Version: 3.11.0-1
Severity: important

Dear Maintainer,

Attempting to upgrade my system, I get the following in the output for
every kernel:

E: /usr/share/initramfs-tools/hooks/fuse failed with return 1.

Trying to get a little more information, I ran

update-initramfs -u -v -k all

and after many lines of output, got:

Adding binary /usr/lib/x86_64-linux-gnu/libe2p.so.2.3
Calling hook fuse
Adding binary /sbin/mount.fuse3
E: /usr/share/initramfs-tools/hooks/fuse failed with return 1.

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

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

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


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (550, 
'experimental'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fuse3 depends on:
ii  adduser3.129
ii  libc6  2.35-3
ii  libfuse3-3 3.11.0-1
ii  lsb-base   11.4
ii  mount  2.38.1-1.1+b1
ii  sed4.8-1
ii  sysvinit-utils [lsb-base]  3.05-6

fuse3 recommends no packages.

fuse3 suggests no packages.

-- no debconf information

Bug#1022231: iptables-persistent: Pre-existing /etc/iptables/rules.v4 is overriten when installing

2022-10-22 Thread c.buhtz

But silently overriding isn't a solution.

> if you ask the package to save the rules it will save them, it is the
> expected behaviour

But overriding isn't expected.

Then warn the user about that overriding.

And one other bug is that it tries to "save rules" and ask about that
even if there are not active rules.

> iptables rules are order dependent

I know but the user need to care about it not a package maintainer.

Bug#958036: nut-snmp: SNMPv3 with privacy method "AES" fails to communicate with UPS

2022-10-22 Thread Wilfried Teiken

Confirmed, version 2.8.0 from unstable properly connects to the UPS with AES. I 
see a bunch of new errors ("unhandled ASN 0x81 received”) but the ups 
connection seems working (I get the right output with upsc).

Thanks!


> On Oct 21, 2022, at 3:22 PM, Laurent Bigonville  wrote:
> 
> On Fri, 17 Apr 2020 12:32:15 -0400 Wilfried Teiken  wrote:
> >
> 
> > Dear Maintainer,
> 
> Hello Wilfried,
> 
> >
> > when configuring SNMP as v3 with privacy enabled and "privProtocol = AES" in
> > /etc/nut/ups.conf for the UPS then the communication with the UPS will fail.
> >
> > The sympton is that on startup the driver will report:
> > - "Unknown mibs value: apcc" (with "mibs = apcc")
> > - "No supported device detected" (with "mibs = auto"
> >
> > Communication with "privProtocol = DES" works if the SNMP endpoint is 
> > configured
> > accordingly, so this only affects the "AES" setting.
> >
> > The underlying root cause is a length issue for the 'usmAESPrivProtocol'
> > oid value, causing the wrong privacy string being passed into the net-snmp
> > library caused by a #define that is leading to a sizeof() with a pointer
> > instead of the oid array.
> >
> > See attached patch for a fix.
> 
> Could you please tell me if you are still experiencing this issue with the 
> version 2.8.0 that is currently in debian unstable?
> 
> I can see that the code to detect usmAESPrivProtocol/usmAES128PrivProtocol 
> availability has changed.
> 
> Also, in the build logs of version 2.7.14, I can see the compiler complain 
> about the size of these types, while this warning is not present in version 
> 2.8.0
> 
> I think that this is now fixed.
> 
> Could you please confirm?
> 
> Kind regards,
> 
> Laurent Bigonville
>

Bug#1022251: libsndfile links against libFLAC.so.8, causing linker errors

2022-10-22 Thread Timothy Pearson

Package: libsndfile1
Version: 1.1.0-3
Severity: important
Tags: sid
X-Debbugs-CC: dilin...@queued.net

When attempting to build an application that uses both libsndfile and libFLAC, 
the application fails to link with "/usr/bin/ld: warning: libFLAC.so.8, needed 
by /lib/-linux-gnu/libsndfile.so.1, may conflict with 
libFLAC.so.12"

It appears this issue was introduced in the last libFLAC update on Oct. 14.  
libsndfile probably needs to be (re)built against libFLAC.so.12 to resolve the 
problem.

Bug#1022250: qtox: AppArmor profile breaks qTox under NVIDIA propiertary drivers

2022-10-22 Thread Vincas Dargis


Workaround is to import nvidia abstraction into local include file you can 
create:

```
$ cat /etc/apparmor.d/local/usr.bin.qtox
include 
```

Bug#1022198: rust-rustyline: please upgrade to v9

2022-10-22 Thread John Goerzen



On Sat, Oct 22 2022, Jonas Smedegaard wrote:

> In Debian we use ITP bugreports to reduce the risk of such "race
> conditions".

Not for packages that are already in unstable as this one was.  Or, for
Rust libraries, per:

https://salsa.debian.org/rust-team/debcargo-conf#itps

- John

Bug#1022250: qtox: AppArmor profile breaks qTox under NVIDIA propiertary drivers

2022-10-22 Thread Vincas Dargis

Package: qtox
Version: 1.17.6-0.1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

After upgrading to nvidia-tesla-470-driver, qTox fails to start.

See https://github.com/qTox/qTox/pull/ for more details.

Marked as grave as AppArmor profile for qTox is enabled by default.

Please consider applying patch in referenced pull request.


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

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

Versions of packages qtox depends on:
ii  libavcodec59 7:5.1.2-1
ii  libavdevice597:5.1.2-1
ii  libavformat597:5.1.2-1
ii  libavutil57  7:5.1.2-1
ii  libc62.35-3
ii  libexif120.6.24-1+b1
ii  libkf5sonnetui5  5.98.0-1
ii  libopenal1   1:1.19.1-2
ii  libqrencode4 4.1.1-1
ii  libqt5core5a 5.15.6+dfsg-2
ii  libqt5gui5   5.15.6+dfsg-2
ii  libqt5network5   5.15.6+dfsg-2
ii  libqt5svg5   5.15.6-2
ii  libqt5widgets5   5.15.6+dfsg-2
ii  libqt5xml5   5.15.6+dfsg-2
ii  libsodium23  1.0.18-1
ii  libsqlcipher03.4.1-2+b1
ii  libstdc++6   12.2.0-7
ii  libswscale6  7:5.1.2-1
ii  libtoxcore2  0.2.18-1
ii  libx11-6 2:1.8.1-2
ii  libxss1  1:1.2.3-1

qtox recommends no packages.

qtox suggests no packages.

-- no debconf information

Bug#1019610: ruby-ahoy-email: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: cannot load such file -- net/smtp (LoadError)

2022-10-22 Thread Adrian Bunk

On Fri, Oct 07, 2022 at 02:16:35PM -0300, Antonio Terceiro wrote:
>...
> But nothing in ruby-ahoy-email codebase uses net/smtp explicitly, so
> this is a bit weird. Our version is also quite outated wrt upstream, so
> my first attempt would be to just update the latest upstream (there are
> no reverse dependencies in the archive).

That was also my first attempt, and I would have NMUed if it had worked 
instead of asking you.

Unfortunately it doesn't get very far:
/usr/share/rubygems-integration/all/gems/bundler-2.3.15/lib/bundler/resolver.rb:271:in
 `block in verify_gemfile_dependencies_are_found!': Could not find gem 
'actionmailer (~> 7.0.0)' in locally installed gems. (Bundler::GemNotFound)

cu
Adrian

Bug#1005414: Modules fail to build for Linux 5.11 onward

2022-10-22 Thread Witold Baryluk

Package: cloop-src
Version: 3.14.1.3
Followup-For: Bug #1005414
X-Debbugs-Cc: witold.bary...@gmail.com

Any updates? There is a patch.

https://debian-knoppix.alioth.debian.org/packages/cloop/ doesn't work,
but you can find it in /usr/src on CD images:
http://ftp.uni-kl.de/pub/linux/knoppix/KNOPPIX_V9.1CD-2021-01-25-EN.iso

DEV=$(sudo losetup -P -f --show KNOPPIX_V9.1CD-2021-01-25-DE.iso)
sudo mkdir /mnt/knoppix
sudo mount "${DEV}p2" /mnt/knoppix

(requires reiserfs available in the kernel to mount it).

Maybe migrating from m-i to dkms is also something to think about.

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

Kernel: Linux 6.0.0-rc5 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cloop-src depends on:
ii  debhelper 13.10
ii  module-assistant  0.11.11
ii  xz-utils  5.2.5-2.1

cloop-src recommends no packages.

cloop-src suggests no packages.

-- no debconf information

Bug#1022249: fdisk: --list --output Start does not work

2022-10-22 Thread Witold Baryluk

Package: fdisk
Version: 2.38.1-1.1+b1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

According to fdisk --help this should work, but it does not

user@debian:~$ /sbin/fdisk --list --output Start 
KNOPPIX_V9.1CD-2021-01-25-DE.iso
fdisk: cannot open Start: No such file or directory


Disk KNOPPIX_V9.1CD-2021-01-25-DE.iso: 668 MiB, 700448768 bytes, 1368064 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x11522aa9

DeviceBoot   Start End Sectors  Size Id Type
KNOPPIX_V9.1CD-2021-01-25-DE.iso1 * 64 1359871 1359808  664M  0 Empty
KNOPPIX_V9.1CD-2021-01-25-DE.iso2  1359872 136806381924M 83 Linux
user@debian:~$


Regards,
Witold

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

Kernel: Linux 6.0.0-rc5 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fdisk depends on:
ii  libc6  2.35-3
ii  libfdisk1  2.38.1-1.1+b1
ii  libmount1  2.38.1-1.1+b1
ii  libncursesw6   6.3+20220423-2
ii  libreadline8   8.2-1
ii  libsmartcols1  2.38.1-1.1+b1
ii  libtinfo6  6.3+20220423-2

Versions of packages fdisk recommends:
ii  sensible-utils  0.0.17

fdisk suggests no packages.

-- no debconf information

Bug#1022247: scummvm FTBFS with fonts-mplus 063+git20221017+ds-1

2022-10-22 Thread Adrian Bunk

Source: scummvm
Version: 2.6.0+dfsg-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian Fonts Task Force , Gürkan 
Myczko 

https://buildd.debian.org/status/fetch.php?pkg=scummvm=amd64=2.6.0%2Bdfsg-1%2Bb1=1666456981=0

...
   debian/rules execute_before_dh_auto_build
make[1]: Entering directory '/<>'
for F in gui/themes/*/Free*.ttf; do cp -v 
/usr/share/fonts/truetype/freefont/${F##*/} ${F%/*}; done
'/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf' -> 
'gui/themes/fonts/FreeMonoBold.ttf'
'/usr/share/fonts/truetype/freefont/FreeSans.ttf' -> 
'gui/themes/fonts/FreeSans.ttf'
'/usr/share/fonts/truetype/freefont/FreeSansBold.ttf' -> 
'gui/themes/fonts/FreeSansBold.ttf'
for F in gui/themes/*/mplus*.ttf; do cp -v 
/usr/share/fonts/truetype/mplus/${F##*/} ${F%/*}; done
cp: cannot stat '/usr/share/fonts/truetype/mplus/mplus-2c-regular.ttf': No such 
file or directory
make[1]: *** [debian/rules:44: execute_before_dh_auto_build] Error 1

Bug#1022248: transition: icu

2022-10-22 Thread GCS

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

Hi RMs,

My intention is to release Bookworm with ICU 72.1 which is already
packaged and is in experimental. As Sid has the previous,71.1 release
the transition is plain, I don't expect any breakage. The rebuilds are
ongoing and only level1 and level2 are ready at this time.
Transition is similar to the previous ones, this time boost1.74 needs
to be binNMUed after level1 before other level2 packages and pyicu
will need a sourceful upload (its Git version seems to be ready, but I
wait for its release).

The only FTBFS is from the Sid version of nodejs (18.10.0+dfsg-6) due
to a flaky self-test - its experimental version (18.11.0+dfsg-3)
doesn't suffer from it. I will post more when I build all levels of
the transition.

Regards,
Laszlo/GCS

Bug#1022119: [Tts-project] Bug#1022120: speech-dispatcher-dummy causes pipewire to spin and use battery

Control: reassign 1022120 pipewire

Hello,

Both bugs 1022119 ("Wakes up every 1.5s even with no work to do") and
1022120 ("causes pipewire to spin and use battery") can easily be
reproduce with the attached very simple testcase. It thus doesn't seem
to me it is a bug in speech-dispatcher.

Josh Triplett, le jeu. 20 oct. 2022 13:54:48 +0100, a ecrit:
> I discovered pw-top, and it showed that
> speech-dispatcher-dummy was the only thing interacting with pipewire.
> Killing speech-dispatcher caused pipewire to *stop* waking up and using
> battery.
> 
> To the best of my knowledge, nothing on my system should be *using*
> speech-dispatcher. (Happy to check that if there's a tool to do so.)

firefox & chrome happen to trigger speech-dispatcher for supporting
the Web Speech API.

> So it shouldn't be sending anything to pipewire and causing pipewire
> to wake up.

As the testcase shows, even not sending anything to pipewire triggers
the concern, so the issue doesn't seem to be on the application side.

Samuel

Samuel Thibault, le jeu. 20 oct. 2022 15:24:48 +0200, a ecrit:
> Samuel Thibault, le jeu. 20 oct. 2022 15:02:09 +0200, a ecrit:
> > Josh Triplett, le jeu. 20 oct. 2022 13:45:45 +0100, a ecrit:
> > > sd_dummy seems to be waking up every 1.5s even when it has no work to
> > > do.
> > 
> > I don't see that happening on my system. Could you run strace on it so
> > we get to know what happens in your case? E.g.
> > 
> > strace -p $(pgrep sd_dummy)
> 
> Ah, -f is needed to see the thread started by pulseaudio.
> 
> (gdb) bt
> #0  0x7fb4fdefe32f in __GI___poll (fds=fds@entry=0x7fb4f40071a0, 
> nfds=nfds@entry=2, timeout=timeout@entry=1500) at 
> ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x7fb4fe0652e1 in poll (__timeout=1500, __nfds=2, 
> __fds=0x7fb4f40071a0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
> #2  poll_func (ufds=0x7fb4f40071a0, nfds=2, timeout=1500, 
> userdata=0x56184db546b0) at ../src/pulse/thread-mainloop.c:70
> #3  0x7fb4fe056fa4 in pa_mainloop_poll (m=m@entry=0x56184db545b0) at 
> ../src/pulse/mainloop.c:863
> #4  0x7fb4fe057606 in pa_mainloop_iterate (m=m@entry=0x56184db545b0, 
> block=block@entry=1, retval=retval@entry=0x0) at ../src/pulse/mainloop.c:945
> #5  0x7fb4fe0576b0 in pa_mainloop_run (m=0x56184db545b0, 
> retval=retval@entry=0x0) at ../src/pulse/mainloop.c:963
> #6  0x7fb4fe0653b9 in thread (userdata=0x56184db54560) at 
> ../src/pulse/thread-mainloop.c:101
> #7  0x7fb4fd5d433f in internal_thread_func (userdata=0x56184db5ad20) at 
> ../src/pulsecore/thread-posix.c:81
> #8  0x7fb4fde8784a in start_thread (arg=) at 
> ./nptl/pthread_create.c:442
> #9  0x7fb4fdf0b2cc in clone3 () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> so that's coming from pulseaudio. The 1500 delay is most probably
> coming from
> 
> ./src/pulse/stream.c:#define AUTO_TIMING_INTERVAL_END_USEC 
> (1500*PA_USEC_PER_MSEC)
> 
> I don't know why pulseaudio would be waking up every 1.5s even if the
> speech module doesn't submit any audio.
#include 
#include 
#include 
#include 
int main(void) {
	pa_buffer_attr buffAttr;
	pa_sample_spec ss;
	int error;
	int sample_rate = 44100;
	int num_channels = 1;
	int bytes_per_sample = 2;

	ss.rate = sample_rate;
	ss.channels = num_channels;
	ss.format = PA_SAMPLE_S16LE;

	buffAttr.maxlength = (uint32_t) - 1;
	buffAttr.tlength = 10 * sample_rate * num_channels * bytes_per_sample / 1000;
	buffAttr.prebuf = (uint32_t) - 1;
	buffAttr.minreq = (uint32_t) - 1;
	buffAttr.fragsize = (uint32_t) - 1;
	pa_simple * simple = pa_simple_new(NULL, "test",
			PA_STREAM_PLAYBACK, NULL, "playback",
			, NULL, , );
	if (!simple) {
		fprintf(stderr,"error: %s\n", pa_strerror(error));
	}
	while (1)
		pause();
}

Bug#1022246: device-tree-compiler: FTBFS on hppa - assembler issues

2022-10-22 Thread John David Anglin

Source: device-tree-compiler
Version: 1.6.1-4
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

Build fails here:
 AS tests/trees.o
tests/trees.S: Assembler messages:
tests/trees.S:256: Error: junk at end of line, first unrecognized character is 
`''
tests/trees.S:257: Error: junk at end of line, first unrecognized character is 
`''
tests/trees.S:258: Error: junk at end of line, first unrecognized character is 
`''
tests/trees.S:219: Error: invalid operands (*UND* and .data sections) for `-'

The GNU assembler on hppa differs in a number of ways with the assembler
on other architectures:

1) The end-of-line character is `!'. `;' introduces a comment.
2) The `.string' directive doesn't add a null termination character.
3) It is strict about the format for characters and junk at end of line.

With the attached patch, the device-tree-compiler package builds successfully
on hppa:
https://buildd.debian.org/status/fetch.php?pkg=device-tree-compiler=hppa=1.6.1-4=1666457482=0

Please push upstream and add to debian/patches if okay.

Thanks,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.16+ (SMP w/4 CPU threads)
Locale: LANG=C, 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)
Index: device-tree-compiler-1.6.1/flattree.c
===
--- device-tree-compiler-1.6.1.orig/flattree.c
+++ device-tree-compiler-1.6.1/flattree.c
@@ -124,7 +124,7 @@ static void asm_emit_cell(void *e, cell_
 {
FILE *f = e;
 
-   fprintf(f, "\t.byte 0x%02x; .byte 0x%02x; .byte 0x%02x; .byte 0x%02x\n",
+   fprintf(f, "\t.byte 0x%02x\n\t.byte 0x%02x\n\t.byte 0x%02x\n\t.byte 
0x%02x\n",
(val >> 24) & 0xff, (val >> 16) & 0xff,
(val >> 8) & 0xff, val & 0xff);
 }
@@ -133,10 +133,17 @@ static void asm_emit_string(void *e, con
 {
FILE *f = e;
 
+#if defined(__hppa__)
+   if (len != 0)
+   fprintf(f, "\t.stringz\t\"%.*s\"\n", len, str);
+   else
+   fprintf(f, "\t.stringz\t\"%s\"\n", str);
+#else
if (len != 0)
fprintf(f, "\t.string\t\"%.*s\"\n", len, str);
else
fprintf(f, "\t.string\t\"%s\"\n", str);
+#endif
 }
 
 static void asm_emit_align(void *e, int a)
@@ -438,7 +445,11 @@ static void dump_stringtable_asm(FILE *f
 
while (p < (strbuf.val + strbuf.len)) {
len = strlen(p);
+#if defined(__hppa__)
+   fprintf(f, "\t.stringz \"%s\"\n", p);
+#else
fprintf(f, "\t.string \"%s\"\n", p);
+#endif
p += len+1;
}
 }
Index: device-tree-compiler-1.6.1/tests/trees.S
===
--- device-tree-compiler-1.6.1.orig/tests/trees.S
+++ device-tree-compiler-1.6.1/tests/trees.S
@@ -1,6 +1,78 @@
 #include 
 #include "testdata.h"
 
+#ifdef __hppa__
+#define FDTLONG(val) \
+   .byte   ((val) >> 24) & 0xff ! \
+   .byte   ((val) >> 16) & 0xff ! \
+   .byte   ((val) >> 8) & 0xff ! \
+   .byte   (val) & 0xff!
+
+#define TREE_HDR(tree) \
+   .balign 8   ! \
+   .globl  tree! \
+tree:  \
+   FDTLONG(FDT_MAGIC)  ! \
+   FDTLONG(tree##_end - tree) ! \
+   FDTLONG(tree##_struct - tree) ! \
+   FDTLONG(tree##_strings - tree) ! \
+   FDTLONG(tree##_rsvmap - tree) ! \
+   FDTLONG(0x11)   ! \
+   FDTLONG(0x10)   ! \
+   FDTLONG(0)  ! \
+   FDTLONG(tree##_strings_end - tree##_strings) ! \
+   FDTLONG(tree##_struct_end - tree##_struct) !
+
+#define RSVMAP_ENTRY(addrh, addrl, lenh, lenl) \
+   FDTLONG(addrh)  ! \
+   FDTLONG(addrl)  ! \
+   FDTLONG(lenh)   ! \
+   FDTLONG(lenl)
+
+#define EMPTY_RSVMAP(tree) \
+   .balign 8   ! \
+tree##_rsvmap: ! \
+   RSVMAP_ENTRY(0, 0, 0, 0) \
+tree##_rsvmap_end: !
+
+#define PROPHDR(tree, name, len) \
+   FDTLONG(FDT_PROP)   ! \
+   FDTLONG(len)! \
+   FDTLONG(tree##_##name - tree##_strings) !
+
+#define PROP_EMPTY(tree, name) \
+   PROPHDR(tree, name, 0)  !
+
+#define PROP_INT(tree, name, val) \
+   PROPHDR(tree, name, 4) \
+   FDTLONG(val)!
+
+#define PROP_INT64(tree, name, valh, vall) \
+   PROPHDR(tree, name, 8) \
+   FDTLONG(valh)   ! \
+   FDTLONG(vall)   !
+
+#define PROP_STR(tree, name, str) \
+   PROPHDR(tree, name, 55f - 54f) \
+54:\
+   .stringzstr ! \
+55:\
+   .balign 4   !
+
+#define BEGIN_NODE(name) \
+   FDTLONG(FDT_BEGIN_NODE) ! \
+   .stringzname! \
+   .balign 4   !
+
+#define END_NODE \
+

Bug#1022245: rust-arc-swap: please upgrade to v1

Source: rust-arc-swap
Version: 0.4.8-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream branch v1, preferred by rsass.

Currently, rsass is patched to link against v0.4, but it makes me
nervous to rely on that more than two years old unstable codebase.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNUImQACgkQLHwxRsGg
ASH6BA//V+ayJbhRWIbswu3Yg4phQJW2StfN2ulTLZY+jMprYXX3XVV7J2c4rDNp
9qNAjrer3i4pGYuj8EjE9YFjq22I4SMuqYujuRZMiAZsUBawaKMSFppR7Tn1JhQM
PMJfsCAO3Rcbn9x3zF+bvE8Ui3HKzdH0BK3p0eqpilsCoIbLWxbEsWnu4QeMR852
cih6Nh9SJinfdcqVhH8xU/YOn8k1Le0+9WVM6KCeHCbwJ/ImLaBq1T9O2TK5dGyg
XnamCm59J7iidRvU9KopZiaorZOsyqVz3pXc+Kltftlih65t9gtNnxXnqoM5nJOB
3GcVOjlwgB+IQ8bhCZ1Og8DMAZDGVwqg+QmnoA7QK5xNbeYuHPZbyejI5bd85ExN
Gpt/UyTj9sp3PNnkmf9/t5BEXqOC3bZE7tsjEsMSsyKevNItfdwX7ktOa415qvHI
B86fO8GFjx/Sohq2uNP2ohAcp0BSgZIl/cpIKfJpsDklFw9s422gW0ebu3WfEaR7
VMDIvLpuNUbJZucnT0AwZSZRknd1d678C9RJaHq+EsxwBvB0AUqthiprUykmaF9v
KU6qKl9950YyeAtl66hB+QKLq9hgPZTCdnOkRj782fVJBI2tIF3yzcHLaby23Z15
7BIdUIhXk2SIgPBWZYSyHSAbmMcKEZWehesNX8ZV/hUcXYaZTIo=
=IPU/
-END PGP SIGNATURE-

Bug#1009031: possible workaround for libgit-raw-perl FTBFS with libgit2 1.3.0

2022-10-22 Thread Étienne Mollier

Control: tags -1 patch

Hi,

Taking the approach of refreshing the test suite to match the
output produced by the new libgit2 seems to do the job to
address the test suite failure.  I also checked this has no
adverse effects on reverse dependencies.  Variations between the
reference and the new update are also minimal and seem to make
sense.

It would be welcome if someone else could have a look; maybe
there are breakages I haven't seen.  Also, upstream gave the
impression that changes were maybe not that obvious, in which
case it would be better to wait for an upcoming module version,
compatible with the current libgit2 hopefully.

In hope this helps,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.
Description: update test suite expectations to match libgit2 behavior.
Author: Étienne Mollier 
Bug: https://github.com/jacquesg/p5-Git-Raw/issues/222
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009031
Last-Update: 2022-10-22
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- libgit-raw-perl.orig/t/02-commit.t
+++ libgit-raw-perl/t/02-commit.t
@@ -296,7 +296,7 @@
 $expected_patch = qq{
 From $commit2_id Mon Sep 17 00:00:00 2001
 From: Git::Raw author 
-Subject: second commit
+Subject: [1/2] second commit
 
 ---
  test2 | 1 +
--- libgit-raw-perl.orig/t/15-merge.t
+++ libgit-raw-perl/t/15-merge.t
@@ -238,7 +238,7 @@
 $index -> write;
 
 my $merge_msg = $repo -> message();
-is $merge_msg, "Merge branch 'branch2'\n\nConflicts:\n\ttest1\n";
+is $merge_msg, "Merge branch 'branch2'\n\n#Conflicts:\n#\ttest1\n";
 
 my $target = $master -> target;
 $commit = $repo -> commit("Merge commit!", $me, $me, [$target, $commit2],


signature.asc
Description: PGP signature

Bug#1022244: displaycal: int() base must be >= 2 and <= 36, or 0

2022-10-22 Thread Michael Below

Package: displaycal
Version: 3.9.8-1
Severity: important
X-Debbugs-Cc: be...@judiz.de

Dear Maintainer,

today I reinstalled displaycal after some months (last measured profile
is about one year old), for the first time with python 3. On startup, I
get the above error message. The main menu shows up, but when I choose
any of the main functions (Calibration etc), the message shows again and
none of the functions work.

The error message can't be copy/pasted, but I will send a screen cap
with another message.

I wish to calibrate my two screens with a Spyder X on Gnome/Wayland.

Thanks for your work!

Cheers
Michael

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 displaycal depends on:
ii  argyll   2.3.1+repack-1.1
ii  dbus-x11 1.14.4-1
ii  libc62.35-3
ii  libjs-jquery 3.6.1+dfsg+~3.5.14-1
ii  libsdl2-mixer-2.0-0  2.6.2+dfsg-1
ii  libx11-6 2:1.8.1-2
ii  libxinerama1 2:1.1.4-3
ii  libxrandr2   2:1.5.2-2+b1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  python3  3.10.6-1
ii  python3-distro   1.8.0-1
ii  python3-gi   3.42.2-2
ii  python3-numpy1:1.21.5-1+b1
ii  python3-send2trash   1.8.1~b0-2
ii  python3-wxgtk4.0 4.2.0+dfsg-1

Versions of packages displaycal recommends:
ii  colord1.4.6-1
ii  gir1.2-colordgtk-1.0  0.3.0-3

displaycal suggests no packages.

-- no debconf information

Bug#1022239: [Tts-project] Bug#1022239: festival FTBFS: make[2]: *** [/usr/lib/speech_tools/config/rules/targets.mak:55: src] Error 2

Nilesh Patra, le sam. 22 oct. 2022 21:49:16 +0530, a ecrit:
> I see, yes indeed. I have "$dpkg_buildpackage_user_options = ['-j5'];" set in
> my sbuildrc since atleast a couple of years or so and this is the first time I
> have seen something choke.

Yes, most people relying on automake/cmake/etc. so they have parallel
builds fixed for them already.

> If the makefile does not support parallel building, then it makes sense
> to explicity declare that with a --no-parallel. The custom $(MAKE) call can go
> away. I tried again with -j5 option, and passing a --no-parallel seems to
> mitigate this. I have attached the patch for the same, please consider taking
> a look.

Applied, thanks!

> BTW, if you could do something to not build the festival.info file during the
> build, somehow split build and doc for override_dh_auto_build into -arch and 
> -indep call, that'd make
> festival natively cross-building, and I'd be quite happy on seeing that.

Right, we can just move the info documentation to festival-doc.

Now pushed so on salsa.

Samuel

Bug#1022243: ITP: thefuzz -- Fuzzy string matching in Python (was fuzzywuzzy)

2022-10-22 Thread Edward Betts

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: thefuzz
  Version : 0.19.0
  Upstream Author : Adam Cohen 
* URL : https://github.com/seatgeek/thefuzz
* License : GPL-2
  Programming Lang: Python
  Description : Fuzzy string matching in Python

  Various methods for fuzzy matching of strings in Python, including:
  .
- String similarity: Gives a measure of string similarity between 0 and 100.
- Partial string similarity: Inconsistent substrings are a common problem
  when string matching. To get around it, use a "best partial" heuristic
  when two strings are of noticeably different lengths.
- Token sort: This approach involves tokenizing the string in question,
  sorting the tokens alphabetically, and then joining them back into a
  string.
- Token set: A slightly more flexible approach. Tokenize both strings, but
  instead of immediately sorting and comparing, split the tokens into two
  groups: intersection and remainder.

I plan to maintain this package as part of the Python team.

This Python library was previously known as fuzzywuzzy before being renamed to
thefuzz.

There are five packages in Debian that depend on fuzzywuzzy:

  gnome-pass-search-provider
  python3-fluids
  wajig
  sublime-music
  python3-fluids

Once these packages have switched to using thefuzz I will write to FTP master
and ask for fuzzywuzzy to be deleted from the archive.

Bug#1022239: festival FTBFS: make[2]: *** [/usr/lib/speech_tools/config/rules/targets.mak:55: src] Error 2

2022-10-22 Thread Nilesh Patra

Control: tags -1 patch

On Sat, Oct 22, 2022 at 05:07:54PM +0200, Samuel Thibault wrote:
> Control: severity -1 wishlist
> 
> Samuel Thibault, le sam. 22 oct. 2022 17:06:07 +0200, a ecrit:
> > Nilesh Patra, le sam. 22 oct. 2022 20:09:05 +0530, a ecrit:
> > > Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot -j5
> > 
> > Ok, that's why. festival's makefile does not support parallel builds.
> > That's why we do not pass any -j parameter to the explicit make call.
> > 
> > It seems that dpkg-buildpackage's -j option forcibly passes -j
> > in MAKEFLAGS. Is there a way to prevent it from doing that, or
> > should users just know whether they can use -j, and rather use
> > DEB_BUILD_OPTIONS=parallel=nn if they don't know?
> 
> -J's documentation
> 
> “
>-J, --jobs-try[=jobs|auto]
>This option (since dpkg 1.18.2, long option since dpkg 1.18.8) is
>equivalent to the -j option except that it does not set the
>MAKEFLAGS environment variable, and as such it is safer to use with
>any package including those that are not parallel-build safe.
> 
>auto is the default behavior (since dpkg 1.18.11). Setting the
>number of jobs to 1 will restore a serial behavior.
> ”
> 
> leads me into thinking that this is notabug from festival, and people
> should be just using -J and not -j?


I see, yes indeed. I have "$dpkg_buildpackage_user_options = ['-j5'];" set in
my sbuildrc since atleast a couple of years or so and this is the first time I
have seen something choke.

If the makefile does not support parallel building, then it makes sense
to explicity declare that with a --no-parallel. The custom $(MAKE) call can go
away. I tried again with -j5 option, and passing a --no-parallel seems to
mitigate this. I have attached the patch for the same, please consider taking
a look.

BTW, if you could do something to not build the festival.info file during the
build, somehow split build and doc for override_dh_auto_build into -arch and 
-indep call, that'd make
festival natively cross-building, and I'd be quite happy on seeing that.
Currently, you are installing festival.info.* files in festival binary package 
and
cross-build would choke there if doc call is separated into -indep rule.
One way could be to build this package twice, once natively and once 
cross-build but that'd be a ugly.

-- 
Best,
Nilesh
diff --git a/debian/rules b/debian/rules
index 5b28cca..435e7db 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,11 +10,6 @@ export FORCE_SOURCE_DATE=1
 FAKETIME = TZ=UTC faketime @$(SOURCE_DATE_EPOCH)
 endif
 
-ifeq ($(origin CC),default)
-CC := $(DEB_HOST_GNU_TYPE)-gcc
-CXX := $(DEB_HOST_GNU_TYPE)-g++
-endif
-
 override_dh_auto_configure:
 #Avoid conflicting with upstreams build system
 
@@ -22,7 +17,7 @@ override_dh_auto_test:
 #Upstream states test is only for their local development not a functional test
 
 override_dh_auto_build:
-	$(MAKE) CC='$(CC)' CXX='$(CXX)'
+	dh_auto_build --no-parallel --buildsystem=makefile
 	cd doc && $(FAKETIME) $(MAKE) festival.info festival.html festival.ps
 
 override_dh_auto_clean:


signature.asc
Description: PGP signature

Bug#1022169: llvm-toolchain-15: FTBFS on mips*el: static assertion failed: struct_kernel_stat_sz == sizeof(stat)

2022-10-22 Thread YunQiang Su

Simon McVittie  于2022年10月21日周五 19:36写道：
>
> Source: llvm-toolchain-15
> Version: 1:15.0.2-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source, making mesa unbuildable
> User: debian-m...@lists.debian.org
> Usertags: mipsel mips64el
> X-Debbugs-Cc: debian-m...@lists.debian.org, m...@packages.debian.org
> Control: affects -1 + src:mesa
>
> Quoting from mips64el buildd logs, but mipsel has a similar failure:
>
> > /<>/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_linux.cpp:67:1:
> >  error: static assertion failed due to requirement 'struct_kernel_stat_sz 
> > == sizeof(stat)':
> > COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat));
>

https://reviews.llvm.org/D135553
It is due to large file support is enabled by default for 32bit compiler_rt.

> Strictly speaking this is not a regression because llvm-toolchain-15 was
> never built successfully on mips*el, but I think it should be treated as
> RC anyway, because older llvm-toolchain-* were buildable on mips*el (and
> mesa is already using llvm-toolchain-15, making it a key package).
>
> smcv
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
> 'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
> 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.0.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>


-- 
YunQiang Su

Bug#1019470: git: Bump version to 2.37.3

2022-10-22 Thread Christoph Anton Mitterer

Control: retitle -1 new upstream version
Control: tags -1 + security

Hey.

git 2.38.x would be out, which also contains an important new
workaround (though per default NOT enabled - don't ask me why... I
wouldn't be able to find polite words for explaining this) for a remote
code execution exploit in git, namely (safe.barerepository).

See e.g. https://lwn.net/Articles/892755/ for a starting point about
the RCE.

Cheers,
Chris.

Bug#1022242: RFS: vnstat/2.10-1 -- console-based network traffic monitor

2022-10-22 Thread Christian Göttsche

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : vnstat
   Version  : 2.10-1
   Upstream contact : Teemu Toivola 
 * URL  : https://humdi.net/vnstat/
 * License  : GPL-any, GPL-2
 * Vcs  : https://salsa.debian.org/debian/vnstat
   Section  : net

The source builds the following binary packages:

  vnstat - console-based network traffic monitor
  vnstati - image output support for vnStat

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.10-1.dsc

Changes since the last upload:

 vnstat (2.10-1) unstable; urgency=medium
 .
   * New upstream version 2.10
 .
   * d/watch: update for GitHub API change
   * d/control: bump to std version 4.6.1 (no further changes)
   * d/patches: refresh and drop upstream applied one

Regards,
-- 
  Christian Göttsche

Bug#1022241: ITP: rust-ureq -- simple and safe HTTP client

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-ureq
  Version : 0.1.15
  Upstream Author : Martin Algesten 
* URL : https://github.com/algesten/ureq
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : simple and safe HTTP client

 Ureq is a simple, safe HTTP client.
 .
 Ureq's first priority is being easy for you to use.
 It's great for anyone who wants a low-overhead HTTP client
 that just gets the job done.
 Works very well with HTTP APIs.
 Its features include cookies, JSON, HTTP proxies, HTTPS,
 and charset decoding.
 .
 Ureq is in pure Rust for safety and ease of understanding.
 It avoids using "unsafe" directly.
 It uses blocking I/O instead of async I/O,
 because that keeps the API simple and keeps dependencies to a minimum.
 For TLS, ureq uses rustls or native-tls.

This package will be maintained in the collaborative Debian section at
Salsa, at .

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNUE4MACgkQLHwxRsGg
ASGtxg//SuTXFnoYCuf88RXsXcV51Kdhjc2d5tjGOkfbkQA3BZhHCCIHT+n4nbrv
n+vow0VV/ISVS8Kk5AwIxOMMohZ48tcO3NnqT7PBn+2DNc/d4/U7tzpaeN63i7/u
gNljGHv0MOcm0H2B4F9+2E92JgS8lyM5Mg+HnCDF6TXQWSCfxvhGxYz/K6H8F6CL
SutBxP0ZOVaP951NtwTD2SS3xE/v2xQ/Qjmg86fxTM46ucByf0Q8arPbk6A1iZBX
SdtCGK4DnFBTcX9H3BBfq0MKob9p02/eDcq2LaYRkmyE0DXqNVUB2ipd0mEtqkeN
LmCCqy6hNzKKfL3Zk7wV6na/rFOUFJ6Aj/TSa4bzpRexAAjz9ptSo/pm6kadZOXR
8AWOnP/BHwKj5g0I3MxRO5Ke7qMS9RcVXKR5o0Y2nM726GlXWMbuu4jGwXVEify1
fQy1mC9UbtICKlNfi/W+PjCyhnvcIOvpqGEcxCMoE4iHW+wk2tswOeFoxoMS6lEk
E8FjQCczguINtUlj2GijMdRnYHlFzWwESXXdP09LCoaDzVuJU/FfBHEorcvVEl3O
AyxG6JgWJgi51aSczm5bDMoHqxHzg7Qx9cyVMPPy0D7uTIj59vKRqupqVHW8HsuY
dlSuRgtZM58/2TlinduDSlHNGglOwAIi4WChJMTaYqHr8LDApM4=
=Mz/E
-END PGP SIGNATURE-

Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

2022-10-22 Thread Clément Hermann

Hi,

Le 22/10/2022 à 15:59, Vincent Lefevre a écrit :

Hi,

On 2022-10-22 14:31:24 +0200, Clément Hermann wrote:

I could reproduce your issue if I enable check_sigs option in CPAN
(which is _not_ the default).

OK, I forgot about that (though I think that it should be the default
for security reasons, and IIRC, this was recommended for this reason
in some other thread).

I do think it's a good idea to enable it.

Thing is, it's not a bug, really. Or not quite. It's a result of the
correction of a bug in CPAN < 2.29 who would succeed silently if there is no
signature/no way to check the key.

You can find some context in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and
http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html

I didn't know that. In particular, I had not got any announce,
probably because it is still not fixed in Debian/stable. And
AFAIK, http is also still used by default in Debian/stable, so
that this makes the security even worse.

http or not won't change much, since CPAN uses a mirror network
(arguably with only "safe" mirrors now). Checking the signature of the
hashes is the right way to make sure a downloaded module is really the
one a developer makes available.

I do agree that it's bad UX that CPAN isn't more helpful when the key isn't
available, e.g. asking for it or suggesting a way to get it, but the fact
that it fails if the key isn't available while the Checksums are signed is
the right behavior, and your workaround (getting the key) is the right
solution.

CPAN doesn't have a way to centralize key themself, and probably shouldn't,
either. Not sure how such error can be avoided completely (the Debian method
of having a preconfigured keyring won't do for CPAN IMO), but it should at
least suggest a solution.

I agree. There should be at least sufficient documentation when the
error occurs. If Debian could automatically provide the key and use
it, this would be better, IMHO: less work for the user, and this
would ensure (if correctly done) that the key is correct and still
valid.

Thing is, Debian cannot anticipate what modules you want to install via
CPAN (so outside of Debian), so which developer keys to get, and also
cannot install keys from all CPAN contributors in the user keyring…

A way to fix this would be to make the message in CPAN more helpful and
propose to get the key from a known source (e.g. keyserver), but I think
that really ought to be done upstream.

Note that in my current installation, a more helpful message is
displayed at the end (possibly because I installed
libmodule-signature-perl):

```
Module::Signature verification returned value 0E0

The manual says for this case: Cannot verify the
OpenPGP signature, maybe due to the lack of a network connection to
the key server, or if neither gnupg nor Crypt::OpenPGP exists on the
system. You probably want to analyse the situation and if you cannot
fix it you will have to decide whether you want to stop this session
or you want to turn off signature verification. The latter would be
done with the command 'o conf init check_sigs'
```

I'm guessing the key would be donwloaded with Crypt::OpenPGP installed
(unfortunately not in Debian yet), but I didn't test.

Please report if you test with Crypt::OpenPGP installed via CPAN: if
that makes the behaviour better UX-wise, we should package it (there are
a few deps but I don't see any issue at a glance).

Cheers,

--
nodens

Bug#1022232: libffi8 3.4.3-3 breaks all wayland clients on arm64/aarch64

2022-10-22 Thread Johannes Schauer Marin Rodrigues

Control: severity -1 critical

On Sat, 22 Oct 2022 14:14:32 +0200 "Lukas F. Hartmann"  wrote:
> Since an `apt upgrade` yesterday on Debian unstable on an aarch64 system
> (imx8mq based, cortex-a53), all wayland compositors and clients stopped
> working, including sway, wayfire and weston.

Since this bug in libffi makes unrelated software on the system break, this bug
is of severity critical.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1018754: telegram-cli: Outdated app that is no longer supported

2022-10-22 Thread Axel Beckert

Hi Paul,

Ying-Chun Liu (PaulLiu) wrote:
> Neither szqdong nor kenorb-contrib is working.
> I've tried both.

Meh. I had hope because at least their build CI seems to have been
passed.

Thanks a lot for having a look at it and testing!

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

Bug#1014460: transition: php8.2

2022-10-22 Thread Mike Gabriel


Hi Paul,

On  Sa 22 Okt 2022 16:56:36 CEST, Paul Gevers wrote:


Hi all,

On 22-10-2022 16:25, David Prévot wrote:
There are still over twenty packages that need fixing in the Horde  
camp, probably most of them could use a “Restrictions:  
allow-stderr” workaround in debian/tests/control.


@horde team, do you think you can work on these deprecation warnings  
in time? If not, can we have the allow-stderr restriction uploaded  
soon please? Maybe somebody can help the horde team to get these  
uploaded if that helps (please let us know).


my overall intention is to get Horde ready for bookworm before X-mas.  
On my todo list are more urgent packages atm, though (pam-python,  
gosa). Both will require some effort.


For Horde, getting autopkgtests resolved (and packages migrate to  
testing) is one thing, but getting all of Horde  
deprecation-warnings-free with php8.2 at run time is a completely  
different cup of team. (Horde upstream is slowly working on Horde6,  
but that will not be ready for bookworm, so we have to stay with  
Horde5 for Debian 12).


I am currently trying to get my UDD dashboard beautiful again, but  
this will be an ongoing effort until December (and probably more  
uploads after X-mas).


The allow-stderr flag in debian/tests/control is a viable solution,  
but I'd love to use that as a last ressort. At the moment, it is more  
helpful (to me) to see all those CI failures and not have them mask  
with that flag.


Greets,
Mike
--

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

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



pgpcF9WPAdVkI.pgp
Description: Digitale PGP-Signatur

Bug#1022156: iptables-persistent: This patch allows optional testing of the iptables/ip6tables rules using the --test flag to `iptables-restore` and `ip6tables-restore` prior to loading them.

2022-10-22 Thread gustavo panizzo


Hello

On Fri, Oct 21, 2022 at 04:59:24PM +1100, Phillip Smith wrote:

Source: iptables-persistent
Severity: normal
Tags: patch upstream

Dear Maintainer,

  * What led up to the situation? Errors in the rules file causes a
  * blank set of rules to be loaded to the kernel. This patch means the
  * existing rule set will remain loaded if the test of the new rules
  * fails.


thanks for your patch, I'll include it in my next upload but toggled to
active by default (new installs)



--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#970659: GNU/Hurd patch submitted upstream #1796917

2022-10-22 Thread Svante Signell

Hi,

The attached patch for the build problem on GNU/Hurd (same as the one from 2020)
was submitted upstream. Upstream bug number: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1796917

Thanks!

Index: nspr-4.28/nspr/pr/src/pthreads/ptsynch.c
===
--- nspr-4.28.orig/nspr/pr/src/pthreads/ptsynch.c
+++ nspr-4.28/nspr/pr/src/pthreads/ptsynch.c
@@ -50,7 +50,7 @@ void _PR_InitLocks(void)
 rv = _PT_PTHREAD_MUTEXATTR_INIT(&_pt_mattr);
 PR_ASSERT(0 == rv);
 
-#if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)) || \
+#if (defined(LINUX) && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2))) || \
 (defined(FREEBSD) && __FreeBSD_version > 700055)
 rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP);
 PR_ASSERT(0 == rv);

Bug#1022239: festival FTBFS: make[2]: *** [/usr/lib/speech_tools/config/rules/targets.mak:55: src] Error 2

Control: severity -1 wishlist

Samuel Thibault, le sam. 22 oct. 2022 17:06:07 +0200, a ecrit:
> Nilesh Patra, le sam. 22 oct. 2022 20:09:05 +0530, a ecrit:
> > Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot -j5
> 
> Ok, that's why. festival's makefile does not support parallel builds.
> That's why we do not pass any -j parameter to the explicit make call.
> 
> It seems that dpkg-buildpackage's -j option forcibly passes -j
> in MAKEFLAGS. Is there a way to prevent it from doing that, or
> should users just know whether they can use -j, and rather use
> DEB_BUILD_OPTIONS=parallel=nn if they don't know?

-J's documentation

“
   -J, --jobs-try[=jobs|auto]
   This option (since dpkg 1.18.2, long option since dpkg 1.18.8) is
   equivalent to the -j option except that it does not set the
   MAKEFLAGS environment variable, and as such it is safer to use with
   any package including those that are not parallel-build safe.

   auto is the default behavior (since dpkg 1.18.11). Setting the
   number of jobs to 1 will restore a serial behavior.
”

leads me into thinking that this is notabug from festival, and people
should be just using -J and not -j?

Samuel

Bug#1022239: festival FTBFS: make[2]: *** [/usr/lib/speech_tools/config/rules/targets.mak:55: src] Error 2

Nilesh Patra, le sam. 22 oct. 2022 20:09:05 +0530, a ecrit:
> Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot -j5

Ok, that's why. festival's makefile does not support parallel builds.
That's why we do not pass any -j parameter to the explicit make call.

It seems that dpkg-buildpackage's -j option forcibly passes -j
in MAKEFLAGS. Is there a way to prevent it from doing that, or
should users just know whether they can use -j, and rather use
DEB_BUILD_OPTIONS=parallel=nn if they don't know?

Samuel

Bug#1014460: transition: php8.2


Hi all,

On 22-10-2022 16:25, David Prévot wrote:
There are still over twenty packages that need fixing in the Horde camp, 
probably most of them could use a “Restrictions: allow-stderr” 
workaround in debian/tests/control.


@horde team, do you think you can work on these deprecation warnings in 
time? If not, can we have the allow-stderr restriction uploaded soon 
please? Maybe somebody can help the horde team to get these uploaded if 
that helps (please let us know).


I’ve filed three bugs like that (for php-nesbot-carbon, shaarli and 
cacti),


Ack. "I" am affected as cacti maintainer. I'll make sure cacti isn't in 
the way. Upstream already acked the bug report.


I believe 
the first (non RC) PHP 8.2 release is expected upstream in a month, so, 
if that’s the targeted version for Bookworm, I hope this transition 
could happen as soon as possible.


For the transition, do we agree it's smart to wait until the non-RC php 
8.2 arrives, or should try and transition earlier to some RC candidate 
to find issues earlier? Where can I find the timeline of php 8.2?


Ondřej, there were some missing php8.1-* packages that needed NEW 
processing last time, have all php8.2-* packages been processed this time?


It would indeed be good to make sure that these are in the archive 
before we start. I also recall php toolchain changes in the last 
transition. If there are any pending toolchain changes, please make sure 
that they are deferred or migrated to testing already, before we start 
the transition.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-10-22 Thread Sebastiaan Couwenberg


On 10/22/22 16:25, David Prévot wrote:
I believe there are no more blockers that could be spotted with debci. 
Since not all packages have tests, and those tests can’t spot every 
regressions, there will probably be more issues, but I believe it looks 
good for now (especially compared to previous transitions). I believe 
the first (non RC) PHP 8.2 release is expected upstream in a month, so, 
if that’s the targeted version for Bookworm, I hope this transition 
could happen as soon as possible.


icingaweb2 explicitly doesn't support php8.2 upstream yet, their php8.1 
support took many months to land, getting php8.2 into unstable before 
the bookworm freeze will most likely result in not shipping icingaweb2.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#962464: Remove ICU dependency

2022-10-22 Thread Bastian Germann

Hi,

On Thu, 21 Oct 2021 11:04:04 +0200 Bastian Germann  wrote:

Control: tags -1 patch

On Wed, 17 Mar 2021 17:30:59 +0100 Bastian Germann wrote:>
> I second this request. Alternatively, it would be great to have a build 
> profile that excludes ICU.

A patch with noi18n profile is enclosed.

I would like to see this resolved with bookworm.
As you are probably uploading CVE fixes soon I want to remind you of this 
request.
It would very much help with creating tiny root file systems that have libxml2 
in them.

My request to join the team has not been answered, so I have to rely on you to 
make the change.

Thanks,
Bastian

Bug#1022240: ipmiutil: Issue with /etc/cron.d/wdt

2022-10-22 Thread Olivier Allard-Jacquin

Package: ipmiutil
Version: 3.1.8-2+b1
Severity: important
X-Debbugs-Cc: olivie...@free.fr

Dear Maintainer,

issue root cause is /etc/cron.d/wdt :


MAILTO=''
* * * * *  root  /usr/bin/ipmiutil wdt -r > /usr/bin/ipmiutil wdt.lastrun 2&>1


As you seen, this command is run every minute, and re-write /usr/bin/ipmiutil, 
who is binary.
On 2nd run, /usr/bin/ipmiutil size become 0 byte.

"/usr/bin/ipmiutil" is the main program of "ipmiutil" package, so it's no more 
usable.

Workaround: Comment this line with a "#":

#MAILTO=''
#* * * * *  root  /usr/bin/ipmiutil wdt -r > /usr/bin/ipmiutil wdt.lastrun 2&>1


For information, here "/usr/bin/ipmiutil wdt -r" output :

ipmiutil wdt ver 3.18
-- BMC version 2.40, IPMI version 2.0 
wdt data: 04 01 00 00 dc 05 00 00 
Watchdog timer is stopped for use with SMS/OS. Logging
   pretimeout is 0 seconds, pre-action is None
   timeout is 150 seconds, counter is 0 seconds
   action is Hard Reset
Resetting watchdog timer ...
reset_wdt: ret = 0
wdt data: 44 01 00 00 dc 05 dc 05 
Watchdog timer is started for use with SMS/OS. Logging
   pretimeout is 0 seconds, pre-action is None
   timeout is 150 seconds, counter is 150 seconds
   action is Hard Reset

ipmiutil wdt, completed successfully


Finally, "/usr/bin/ipmiutil wdt.lastrun" has no effect (unsupported option).

In order to fix this issue, "/etc/cron.d/wdt" should be modified (I'm not sure 
of this cron's file goal).

Thanks for you help.

Best regards,
 Olivier


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

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

Versions of packages ipmiutil depends on:
ii  anacron2.3-35+b1
ii  dpkg   1.21.9+b1
ii  init-system-helpers1.65.2
ii  libc6  2.35-3
ii  libssl33.0.5-4
ii  lsb-base   11.4
ii  rpcbind1.2.6-6+b1
ii  sysvinit-utils [lsb-base]  3.05-6

ipmiutil recommends no packages.

ipmiutil suggests no packages.

-- no debconf information

Bug#1017098: decopy: may overturn the hierarchy of files w.r.t. the base debian/copyright file

2022-10-22 Thread Francesco Poli

On Tue, 18 Oct 2022 00:03:33 +0200 Francesco Poli wrote:

[...]
> On Thu, 29 Sep 2022 12:22:15 +0200 Jochen Sprickerhof wrote:
> 
> > * Francesco Poli  [2022-09-29 00:11]:
> [...]
> > >Well, I suspect the heuristics should be improved a bit...
> > >I think that, when a preexisting debian/copyright file is used as a
> > >base for processing, decopy should not change which copyright block is
> > >used as the top one, unless there is a really strong reason to do so.
> > >
> > >Do you agree?
> > 
> > Sounds like yeah.
> 
> Good, I am changing the bug report title accordingly.

This bug is still biting me.

After some changes in my package (see my latest [commit]), decopy
overturns the hierarchy of files, even when run just after a debclean.

[commit]: 

In other words, if I run decopy, I have to fix it by hand. Each and
every time. Even if nothing relevant has changed in the source tree and
the base debian/copyright file is perfectly consistent with the source
tree content!

If enhancing the heuristics is too complicated, I think that a possible
interim fix could be the following: when decopy reads a preexisting
debian/copyright file and uses it as a base for processing, it should
*not* change which copyright block is used as the top one (unless that
top copyright block has to disappear, for instance because no file is
anymore under that license...).

Please fix this bug soon.
Thank you for maintaining and developing this useful tool!

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

pgpVcKnzZgJQO.pgp
Description: PGP signature

Bug#872816: radicale wsgi example not usable

Quoting Borden (2022-10-22 16:16:12)
> 22 Oct 2022, 03:23 by jo...@jones.dk:
> > I doubt I am able to contribute much to this bugreport.  If/when you
> > guys figure out something you'd like to get added to the radicale
> > package (and it isn't too involving or exotic) then tell me and I will
> > sure consider adopting it into the package.  Other than that, I will
> > leave you to it...
> >
> Fair, I understand that this is an off-documented use of Radicale. And I 
> suspect there are some upstream bugs beyond your scope, as the WSGI configs 
> aren't working as advertised.
> 
> A couple of questions which I think you can answer and will help me:
> 1. "secure" permissions for the Radicale store are 660, uid=radicale ; 
> gid=radicale, correct? Can they be more restrictive or should they be more 
> permissive? Should 600 work in the "recommended" setup?

600 could work - not convinced that it should, however: I see no
security risk in allowing write access to a group which has only one
user - except if the sysadmin lets anyone else into that group.


> 2. /etc/default/radicale only gets read when radicale runs in standalone, 
> correct?

Correct.

> 3. The wiki.debian.org/Radicale needs to be overhauled since it doesn't 
> recommend best practices, yes?

Probably - it is a _wiki_ page that I don't care about ;-)


 - 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#1022239: festival FTBFS: make[2]: *** [/usr/lib/speech_tools/config/rules/targets.mak:55: src] Error 2

Control: severity -1 important
Control: tags -1 + moreinfo

Hello,

Nilesh Patra, le sam. 22 oct. 2022 19:40:52 +0530, a ecrit:
> Festival fails to build from source with:

[no actual error message]

Please post the whole log, otherwise we can't see anything.

I have tried to build festival both with plain bookworm and sid
chroots, without any problem. So we need more information on your build
environment: how it is different from a plain build environment.

Samuel

Bug#1022198: rust-rustyline: please upgrade to v9

Quoting John Goerzen (2022-10-22 16:03:12)
> On Sat, Oct 22 2022, Jonas Smedegaard wrote:
> 
> >> rust-fd-lock has no reverse dependencies, but it's first (and only) upload 
> >> was
> >> only 7 months ago. So I would like to give dkg a heads-up in case a major
> >> version bump interferes with his plans.
> >>
> >> I also notice that jgorzen has been working on fd-lock 3 packaging in
> >> debcargo-conf, however he has packaged 3.0.6 which depends on rustix which 
> >> is
> >> not yet in Debian (currently waiting in new).
> >>
> >> So my plan would be
> >>
> >> upload fd-lock 3.0.2 and rustyline 9.1.2 now
> >>
> >> upload fd-lock 3.0.6 if/when rustix passes NEW
> >>
> >> jgorzen, dkg do you have any objections to this plan?
> >
> > Seems you can jump straight to second phase, as librust-rustix-dev has
> > just now entered unstable. :-)
> >
> >  - Jonas
> 
> Race condition here!  I had visited with dkg about this and just
> uploaded fd-lock 3.0.6 (which is needed by filespooler, which I'm also
> about to upload)

In Debian we use ITP bugreports to reduce the risk of such "race
conditions".


 - 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#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

Hi Ondřej, Mike and Horde team, PHP PEAR and Composer team, and Release 
team.


Le 21/07/2022 à 13:22, David Prévot a écrit :

Le 14/07/2022 à 15:23, Paul Gevers a écrit :
Control: forwarded -1 
https://release.debian.org/transitions/html/php8.2.html

[…]
php-defaults was updated in experimental, allowing us to spot some 
regressions thanks to autopkgtests.


There is a new URL/view, thanks Paul for the hint:

https://qa.debian.org/excuses.php?experimental=1=php-defaults

There are still over twenty packages that need fixing in the Horde camp, 
probably most of them could use a “Restrictions: allow-stderr” 
workaround in debian/tests/control.


Thanks in advance if you can try and help fixing those issues. You’re 
more than welcome to report bugs against packages in order to document 
the problem, and eventual hints to get them fixed.


Severity: important
Control: block 1014460 by -1


I’ve filed three bugs like that (for php-nesbot-carbon, shaarli and 
cacti), am crossing fingers that the latest php-proxy-manager upload 
will fix its issue, and hope that the recent issue that popped up with 
phpunit, phpunit-type and php-doctrine-common (that looks similar) will 
fix itself soon enough too (upstream being usually pretty reactive). 
php-log is still not in testing, so not a blocker.


I believe there are no more blockers that could be spotted with debci. 
Since not all packages have tests, and those tests can’t spot every 
regressions, there will probably be more issues, but I believe it looks 
good for now (especially compared to previous transitions). I believe 
the first (non RC) PHP 8.2 release is expected upstream in a month, so, 
if that’s the targeted version for Bookworm, I hope this transition 
could happen as soon as possible.


Ondřej, there were some missing php8.1-* packages that needed NEW 
processing last time, have all php8.2-* packages been processed this time?


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022231: iptables-persistent: Pre-existing /etc/iptables/rules.v4 is overriten when installing

2022-10-22 Thread gustavo panizzo


Hello

On Sat, Oct 22, 2022 at 11:11:41AM +, Christian Buhtz wrote:

Package: iptables-persistent
Severity: normal

I had an existing /etc/iptables/rules.v4 file on my system.
In the next step I installed "iptables-persistent" and said yes to both
questions about saving current existing rules.



if you ask the package to save the rules it will save them, it is the
expected behaviour


Then the file and my rules in it where gone.
That shouldn't happen.


If you want your previous saved rules to be kept, just don't save the
current ruleset



When you want to touch that file that add content to it but not overwrite it.



No, I don't want to add content; I want to "atomically" save the current
ruleset, if content is added on top of the previously saved ruleset I
don't know what the result can be.

iptables rules are order dependent so just appending them will not work
as desired most of the time.




-- System Information:
Debian Release: 11.5
 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-18-amd64 (SMP w/4 CPU threads)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iptables-persistent depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  iptables   1.8.7-1
pn  netfilter-persistent   


--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#872816: radicale wsgi example not usable

2022-10-22 Thread Borden

22 Oct 2022, 03:23 by jo...@jones.dk:
> I doubt I am able to contribute much to this bugreport.  If/when you
> guys figure out something you'd like to get added to the radicale
> package (and it isn't too involving or exotic) then tell me and I will
> sure consider adopting it into the package.  Other than that, I will
> leave you to it...
>
Fair, I understand that this is an off-documented use of Radicale. And I 
suspect there are some upstream bugs beyond your scope, as the WSGI configs 
aren't working as advertised.

A couple of questions which I think you can answer and will help me:
1. "secure" permissions for the Radicale store are 660, uid=radicale ; 
gid=radicale, correct? Can they be more restrictive or should they be more 
permissive? Should 600 work in the "recommended" setup?
2. /etc/default/radicale only gets read when radicale runs in standalone, 
correct?
3. The wiki.debian.org/Radicale needs to be overhauled since it doesn't 
recommend best practices, yes?

Bug#1022239: festival FTBFS: make[2]: *** [/usr/lib/speech_tools/config/rules/targets.mak:55: src] Error 2

2022-10-22 Thread Nilesh Patra

Source: festival
Version: 1:2.5.0-8
Severity: serious
X-Debbugs-Cc: sthiba...@debian.org

Hi,

Festival fails to build from source with:

look at library Festival UniSyn.o us_prosody.o us_unit.o ps_synthesis.o 
us_mapping.o us_features.o
Update library Festival UniSyn.o us_prosody.o us_unit.o ps_synthesis.o 
us_mapping.o us_features.o
ar: `u' modifier ignored since `D' is the default (see `U')
a - UniSyn.o
a - us_prosody.o
a - us_unit.o
a - ps_synthesis.o
a - us_mapping.o
a - us_features.o
us_diphone_unit.cc: In function ‘void load_full_diphone(int)’:
us_diphone_unit.cc:243:9: warning: variable ‘pm_start’ set but not used 
[-Wunused-but-set-variable]
  243 | int pm_start, pm_end, pm_middle;
  | ^~~~
us_diphone_unit.cc:243:19: warning: variable ‘pm_end’ set but not used 
[-Wunused-but-set-variable]
  243 | int pm_start, pm_end, pm_middle;
  |   ^~
us_diphone_unit.cc:243:27: warning: variable ‘pm_middle’ set but not used 
[-Wunused-but-set-variable]
  243 | int pm_start, pm_end, pm_middle;
  |   ^
look at library Festival init_modules.o
Update library Festival init_modules.o
ar: `u' modifier ignored since `D' is the default (see `U')
a - init_modules.o
look at library Festival UniSyn_diphone.o us_diphone_unit.o us_diphone_index.o
Update library Festival UniSyn_diphone.o us_diphone_unit.o us_diphone_index.o
ar: `u' modifier ignored since `D' is the default (see `U')
a - UniSyn_diphone.o
a - us_diphone_unit.o
a - us_diphone_index.o
rm init_modules.o
make[2]: *** [/usr/lib/speech_tools/config/rules/targets.mak:55: src] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:25: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:50: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

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

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

Bug#998088: Same issue when moving from kernel 5.17 to 5.18

2022-10-22 Thread Paul Leiber

On Wed, 29 Jun 2022 15:03:31 +0200 =?UTF-8?B?RnLDqWTDqXJpYyBNQVNTT1Q=?= 
 wrote:

> Hi,
>
> I have a local server that uses Debian testing. I updated the server, it
> went from a kernel 5.17 to 5.18. After the reboot, the network was no
> longer active. The network interfaces were down.
>
> In the logs I had these error messages:
>
> systemd-udevd[396]: :01:00.0: Worker [425] processing SEQNUM=2140 is
> taking a long time
> systemd[1]: systemd-udev-settle.service: Main process exited,
> code=exited, status=1/FAILURE
> systemd[1]: systemd-udev-settle.service: Failed with result 'exit-code'.
> systemd[1]: Failed to start Wait for udev To Complete Device 
Initialization.

> systemd[1]: systemd-udev-settle.service: Consumed 4.055s CPU time.
> [...]
> systemd[1]: ifupdown-pre.service: Main process exited, code=exited,
> status=1/FAILURE
> systemd[1]: ifupdown-pre.service: Failed with result 'exit-code'.
> systemd[1]: Failed to start Helper to synchronize boot up for ifupdown.
> systemd[1]: Dependency failed for Raise network interfaces.
> systemd[1]: networking.service: Job networking.service/start failed with
> result 'dependency'.
> ithaqua systemd[1]: ifupdown-pre.service: Consumed 3.807s CPU time.
>
>
> I found this bug report and replaced the line
> "Requires=ifupdown-pre.service" with "Wants=ifupdown-pre.service" in
> "/lib/systemd/system/networking.service".
>
> During boot there is a delay, but the network interfaces were up and the
> network is active.
>
>
> Regards.
> --
> ==
> | FRÉDÉRIC MASSOT |
> | http://www.juliana-multimedia.com |
> | mailto:frede...@juliana-multimedia.com |
> | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 |
> ===Debian=GNU/Linux===
>
>

I have the same issue as described by Frédéric in an up-to-date Debian 
Bullseye 11.5, kernel 5.10.0-19-amd64. Manually starting the network via 
ifconfig works. The workaround described by Ron mitigates the error. 
However, the delay during boot exists also in my system.


Paul

Bug#1022198: rust-rustyline: please upgrade to v9

2022-10-22 Thread John Goerzen

On Sat, Oct 22 2022, Jonas Smedegaard wrote:

>> rust-fd-lock has no reverse dependencies, but it's first (and only) upload 
>> was
>> only 7 months ago. So I would like to give dkg a heads-up in case a major
>> version bump interferes with his plans.
>>
>> I also notice that jgorzen has been working on fd-lock 3 packaging in
>> debcargo-conf, however he has packaged 3.0.6 which depends on rustix which is
>> not yet in Debian (currently waiting in new).
>>
>> So my plan would be
>>
>> upload fd-lock 3.0.2 and rustyline 9.1.2 now
>>
>> upload fd-lock 3.0.6 if/when rustix passes NEW
>>
>> jgorzen, dkg do you have any objections to this plan?
>
> Seems you can jump straight to second phase, as librust-rustix-dev has
> just now entered unstable. :-)
>
>  - Jonas

Race condition here!  I had visited with dkg about this and just
uploaded fd-lock 3.0.6 (which is needed by filespooler, which I'm also
about to upload)

- John

Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

2022-10-22 Thread Vincent Lefevre

Hi,

On 2022-10-22 14:31:24 +0200, Clément Hermann wrote:
> I could reproduce your issue if I enable check_sigs option in CPAN
> (which is _not_ the default).

OK, I forgot about that (though I think that it should be the default
for security reasons, and IIRC, this was recommended for this reason
in some other thread).

> Thing is, it's not a bug, really. Or not quite. It's a result of the
> correction of a bug in CPAN < 2.29 who would succeed silently if there is no
> signature/no way to check the key.
> 
> You can find some context in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and
> http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html

I didn't know that. In particular, I had not got any announce,
probably because it is still not fixed in Debian/stable. And
AFAIK, http is also still used by default in Debian/stable, so
that this makes the security even worse.

> I do agree that it's bad UX that CPAN isn't more helpful when the key isn't
> available, e.g. asking for it or suggesting a way to get it, but the fact
> that it fails if the key isn't available while the Checksums are signed is
> the right behavior, and your workaround (getting the key) is the right
> solution.
> 
> CPAN doesn't have a way to centralize key themself, and probably shouldn't,
> either. Not sure how such error can be avoided completely (the Debian method
> of having a preconfigured keyring won't do for CPAN IMO), but it should at
> least suggest a solution.

I agree. There should be at least sufficient documentation when the
error occurs. If Debian could automatically provide the key and use
it, this would be better, IMHO: less work for the user, and this
would ensure (if correctly done) that the key is correct and still
valid.

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

Bug#989550: SuiteSparse 64-bit

2022-10-22 Thread Tim Davis

I'm working on a major update to the SuiteSparse build system, which uses
cmake exclusively.  See the dev2 branch
on the SuiteSparse github.  I have a very slightly modified version of
metis, and I compile it
under the name libsuitesparse_metis.so.  It compiles metis with
IDXTYPEWIDTH of 64.

I no longer use SuiteSparse_long, but just int64_t in its place.  That
makes the build more predictable.

This change might resolve this bug.  The dev2 branch is still in progress
but it's getting close.

Bug#1022234: prusa-slicer: Another instant segmentation fault…

2022-10-22 Thread Tobias Frost

A local rebuild with wx-widgets 3.0 makes the crash go away.

Upstream states [1] that prusa-slicer is not ready for wxwidgets 3.2 -- maybe 
#1019825 should be reverted?

As the crash happens in imgui:
I did not check, if the embedded imgui library is the culprit. Embedded version 
is at 1.83, while we have 
in Debian 1.86.

[1] From 
https://github.com/prusa3d/PrusaSlicer/issues/8299#issuecomment-1236874810 
"But that is quite off-topic. Short version: if you link PrusaSlicer 2.5.x with 
wxWidgets 3.2, you will most likely break it."

-- 
tobi

Bug#1022237: man/deb-src-control.pod: Clarify Build-Profiles syntax

2022-10-22 Thread Christoph Berg

Package: dpkg
Version: 1.21.9+b1
Severity: minor

Minor doc improvement.

Christoph
>From bcd4745460ebcfb23d7e10bb0261b68a89d6bc2f Mon Sep 17 00:00:00 2001
From: Christoph Berg 
Date: Sat, 22 Oct 2022 15:32:50 +0200
Subject: [PATCH] man/deb-src-control.pod: Clarify Build-Profiles syntax

Make it clear that "same syntax" for Build-Profiles includes the angle
brackets.
---
 man/deb-src-control.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/deb-src-control.pod b/man/deb-src-control.pod
index 7ca7ffb51..d3a593573 100644
--- a/man/deb-src-control.pod
+++ b/man/deb-src-control.pod
@@ -362,7 +362,7 @@ for more information about them).
 This field specifies the conditions for which this binary package does or
 does not build.
 To express that condition, the same restriction formula syntax from the
-B field is used.
+B field is used (including the angle brackets).
 
 If a binary package paragraph does not contain this field, then it implicitly
 means that it builds with all build profiles (including none at all).
-- 
2.35.1

Bug#1022232: libffi8 3.4.3-3 breaks all wayland clients on arm64/aarch64

2022-10-22 Thread Lukas F. Hartmann

I have identified the breaking patch, it is:
https://github.com/libffi/libffi/pull/739/files

Reverting debian/patches/739.diff and rebuilding the library fixes the
issue.

If possible, please drop this patch until the issue is addressed by
upstream.

Bug#1022187: upgrade-reports: Watching videos on the web doesn't work.


Hi Mario,

On 21-10-2022 19:30, Mario Luppi wrote:

Package: upgrade-reports


I may be missing something, but how is this an upgrade-report? Which 
version of Debian are you running now? Did this work on your system 
before you upgraded to that version of Debian?



As per object trying to watch videos on any site that publishes videos 
(youtube, twitch, etc., etc.) the same hangs and is not displayed.

I tried with both Firefox and Chromium but the result is the same.
Firefox 102.3.0esr (64-bit)
Chromium 106.0.5249.119 (Official Build)


I have the feeling you tried to submit a generic bug against Debian, 
however upgrade-reports is not the right pseudo-package to do that. 
Also, generic bugs tend to not work well. You (we) should try to find 
out a reasonable candidate of a buggy package and reassign this bug 
there, as having it as an upgrade-reports bug isn't going to have any 
result.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022232: libffi8 3.4.3-3 breaks all wayland clients on arm64/aarch64

2022-10-22 Thread Lukas F. Hartmann

I've tried all recent versions from snapshots. libffi8_3.4.3-2_arm64.deb
still works, while libffi8_3.4.3-3_arm64.deb breaks.

Bug#1022236: ITP: mint-x-icons -- Mint-X icon theme

2022-10-22 Thread Fabio Fantoni


Package: wnpp
Severity: wishlist
Owner: Fabio Fantoni 
X-Debbugs-Cc: debian-de...@lists.debian.org, fantonifa...@tiscali.it

* Package name    : mint-x-icons
  Version : 1.6.4
* URL : https://github.com/linuxmint/mint-x-icons
* License : GPL-3+
  Description : Mint-X icon theme
A mint/metal theme based on mintified versions of
Clearlooks Revamp, Elementary and Faenza.


Together with mint-y-icons (recently added in debian) is required by 
mint-themes.


Requested by some users over the years.
Some users already use them installing the packages from mint repository 
or from sources.
I therefore thought it would be better to add them in the debian repo as 
well to make them installable in a simpler and faster way to those who 
want them.


I'll package it under the debian cinnamon team:
https://salsa.debian.org/cinnamon-team/mint-x-icons



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

2022-10-22 Thread Salvatore Bonaccorso

Hi Clément,

On Sat, Oct 22, 2022 at 02:50:53PM +0200, Clément Hermann wrote:
> Hi Salvatore,
> 
> Le 22/10/2022 à 13:49, Salvatore Bonaccorso a écrit :
> > 
> > > For further information see:
> > > 
> > > [0] https://security-tracker.debian.org/tracker/CVE-2021-41867
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41867
> > > [1] https://security-tracker.debian.org/tracker/CVE-2021-41868
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41868
> > > [2] https://security-tracker.debian.org/tracker/CVE-2022-21688
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21688
> > > [3] https://security-tracker.debian.org/tracker/CVE-2022-21689
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21689
> > > [4] https://security-tracker.debian.org/tracker/CVE-2022-21690
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21690
> > > [5] https://security-tracker.debian.org/tracker/CVE-2022-21691
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21691
> > > [6] https://security-tracker.debian.org/tracker/CVE-2022-21692
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21692
> > > [7] https://security-tracker.debian.org/tracker/CVE-2022-21693
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21693
> > > [8] https://security-tracker.debian.org/tracker/CVE-2022-21694
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21694
> > > [9] https://security-tracker.debian.org/tracker/CVE-2022-21695
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21695
> > > [10] https://security-tracker.debian.org/tracker/CVE-2022-21696
> > >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21696
> >  From the reported list CVE-2021-41867 and CVE-2021-41868 were
> > addressed in 2.4 upstream. But the other seem yet unfixed in 2.5, even
> > though likely as well those who contain "has been patched in 2.5". I
> > have not found any indication that this there is really the case.
> > 
> > Any more insights OTOH from you on those?
> According to onionshare 2.5 release notes [1], and to the vulnerabilities
> list on the github project [2], I'd say they were fixed.
> All vulnerabilities are marked as affecting <2.4 since 2.5 release, and for
> instance for the username impersonation, it's been specified in the release
> notes that the security have been tightened on this front.
> 
> That said, I didn't check the code for every vuln individually, and I
> definitely could ask upstream for clarification/confirmation if you think
> it's necessary.

Thanks for the quick reply! (much appreciated). I think it would be
good to get a confirmation from upstream and if possible to have
those advisories updates. E.g.
https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v
while mentioning "affected versions < 2.4" the patched version remains
"none". this might be that the < 2.4 just reflects the point in time
when the advisory was filled. OTOH you have arguments with the v2.5
release information that they might all be fixed.

To be on safe side, explicitly confirming by upstream would be great.

Regards,
Salvatore

Bug#1022235: src:zeroinstall-injector: fails to migrate to testing for too long: FTBFS on armel, mips64el and mipsel


Source: zeroinstall-injector
Version: 2.16-2
Severity: serious
Control: close -1 2.18-1
Tags: sid bookworm ftbfs
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:zeroinstall-injector has been trying to 
migrate for 62 days [2]. Hence, I am filing this bug. Your last version 
failed to build from source on armel, mips64el and mipsel while it built 
there successfully in the past.


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=zeroinstall-injector



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022234: prusa-slicer: Another instant segmentation fault…

2022-10-22 Thread Tobias Frost

Package: prusa-slicer
Version: 2.5.0+dfsg-2
Severity: grave
Justification: renders package unusable

prusa-slicer SEGV at start. (in the last stackframe, in imgui, this is a 
nullptr…)

backtrace:
Thread 1 "slic3r_main" received signal SIGSEGV, Segmentation fault.
0x568b12d3 in ImFont::CalcTextSizeA (this=0x0, size=0, 
max_width=max_width@entry=3.40282347e+38, wrap_width=-1, 
text_begin=text_begin@entry=0x569c42bd "A", text_end=0x569c42be "", 
remaining=remaining@entry=0x0) at ./src/imgui/imgui_draw.cpp:3408
Download failed: Invalid argument.  Continuing without source file 
./obj-x86_64-linux-gnu/src/imgui/./src/imgui/imgui_draw.cpp.
3408./src/imgui/imgui_draw.cpp: No such file or directory.
(gdb) bt
#0  0x568b12d3 in ImFont::CalcTextSizeA (this=0x0, size=0, 
max_width=max_width@entry=3.40282347e+38, wrap_width=-1, 
text_begin=text_begin@entry=0x569c42bd "A", text_end=0x569c42be "", 
remaining=remaining@entry=0x0) at ./src/imgui/imgui_draw.cpp:3408
#1  0x568655c3 in ImGui::CalcTextSize (text=text@entry=0x569c42bd 
"A", text_end=text_end@entry=0x0, 
hide_text_after_double_hash=hide_text_after_double_hash@entry=false, 
wrap_width=wrap_width@entry=-1) at ./src/imgui/imgui.cpp:4538
#2  0x56390716 in 
Slic3r::GUI::NotificationManager::HintNotification::count_spaces 
(this=0x59378dc0) at ./src/slic3r/GUI/HintNotification.cpp:564
#3  0x56390828 in 
Slic3r::GUI::NotificationManager::HintNotification::init (this=0x59378dc0) 
at ./src/slic3r/GUI/HintNotification.cpp:722
#4  0x5639db02 in 
Slic3r::GUI::NotificationManager::HintNotification::retrieve_data 
(this=0x59378dc0, new_hint=) at 
./src/slic3r/GUI/HintNotification.cpp:1061
#5  0x5635ec45 in 
Slic3r::GUI::NotificationManager::HintNotification::HintNotification 
(new_hint=true, evt_handler=, id_provider=..., n=..., 
this=0x59378dc0) at ./src/slic3r/GUI/HintNotification.hpp:75
#6  std::make_unique () at /usr/include/c++/12/bits/unique_ptr.h:1065
#7  Slic3r::GUI::NotificationManager::push_hint_notification 
(this=0x588b3400, open_next=) at 
./src/slic3r/GUI/NotificationManager.cpp:1848
#8  0x560ce7bf in Slic3r::GUI::GUI_App::post_init (this=0x56eb39b0) 
at ./src/slic3r/GUI/GUI_App.cpp:765
#9  0x560cee6c in operator() (event=..., __closure=) at 
./src/slic3r/GUI/GUI_App.cpp:1324
#10 wxEventFunctorFunctor, 
Slic3r::GUI::GUI_App::on_init_inner():: 
>::operator()(wxEvtHandler *, wxEvent &) (this=0x58b569a0, event=...) at 
/usr/include/wx-3.2/wx/event.h:547
#11 0x76a07df2 in wxEvtHandler::ProcessEventIfMatchesId (entry=..., 
handler=, event=...) at ./src/common/event.cpp:1431
#12 0x76a0824e in wxEvtHandler::SearchDynamicEventTable 
(this=this@entry=0x56eb39b0, event=...) at ./src/common/event.cpp:1901
#13 0x76a085a0 in wxEvtHandler::TryHereOnly 
(this=this@entry=0x56eb39b0, event=...) at ./src/common/event.cpp:1624
#14 0x76a0864a in wxEvtHandler::TryBeforeAndHere (event=..., 
this=0x56eb39b0) at ./include/wx/event.h:4007
#15 wxEvtHandler::ProcessEventLocally (this=0x56eb39b0, event=...) at 
./src/common/event.cpp:1561
#16 0x76a08751 in wxEvtHandler::ProcessEvent (this=0x56eb39b0, 
event=...) at ./src/common/event.cpp:1534
#17 0x768a08f2 in wxAppConsoleBase::ProcessIdle (this=0x56eb39b0) 
at ./src/common/appbase.cpp:435
#18 0x76246b34 in wxAppBase::ProcessIdle() () from 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#19 0x76150f99 in wxApp::DoIdle() () from 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#20 0x761510d3 in ?? () from 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#21 0x75d1e60f in g_main_dispatch (context=0x56eea320) at 
../../../glib/gmain.c:3444
#22 g_main_context_dispatch (context=context@entry=0x56eea320) at 
../../../glib/gmain.c:4162
#23 0x75d1e9c8 in g_main_context_iterate (context=0x56eea320, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4238
#24 0x75d1ec7f in g_main_loop_run (loop=loop@entry=0x58b562f0) at 
../../../glib/gmain.c:4438
#25 0x7564a265 in gtk_main () at ../../../../gtk/gtkmain.c:1329
#26 0x7616da45 in wxGUIEventLoop::DoRun() () from 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#27 0x768d7f9d in wxEventLoopBase::Run (this=0x58b562b0) at 
./src/common/evtloopcmn.cpp:87
#28 0x768a2a6b in wxAppConsoleBase::MainLoop (this=0x56eb39b0) at 
./src/common/appbase.cpp:381
#29 0x7691feb7 in wxEntry (argc=, argv=) 
at ./src/common/init.cpp:503
#30 0x560af7b9 in Slic3r::GUI::GUI_Run (params=...) at 
./src/slic3r/GUI/GUI_Init.cpp:54
#31 0x558705de in Slic3r::CLI::run (this=, 
argc=, argv=) at ./src/PrusaSlicer.cpp:618
#32 0x55845bf4 in main (argc=, argv=) at 
./src/PrusaSlicer.cpp:844




-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

2022-10-22 Thread Clément Hermann


Hi Salvatore,

Le 22/10/2022 à 13:49, Salvatore Bonaccorso a écrit :



For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-41867
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41867
[1] https://security-tracker.debian.org/tracker/CVE-2021-41868
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41868
[2] https://security-tracker.debian.org/tracker/CVE-2022-21688
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21688
[3] https://security-tracker.debian.org/tracker/CVE-2022-21689
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21689
[4] https://security-tracker.debian.org/tracker/CVE-2022-21690
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21690
[5] https://security-tracker.debian.org/tracker/CVE-2022-21691
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21691
[6] https://security-tracker.debian.org/tracker/CVE-2022-21692
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21692
[7] https://security-tracker.debian.org/tracker/CVE-2022-21693
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21693
[8] https://security-tracker.debian.org/tracker/CVE-2022-21694
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21694
[9] https://security-tracker.debian.org/tracker/CVE-2022-21695
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21695
[10] https://security-tracker.debian.org/tracker/CVE-2022-21696
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21696

 From the reported list CVE-2021-41867 and CVE-2021-41868 were
addressed in 2.4 upstream. But the other seem yet unfixed in 2.5, even
though likely as well those who contain "has been patched in 2.5". I
have not found any indication that this there is really the case.

Any more insights OTOH from you on those?
According to onionshare 2.5 release notes [1], and to the 
vulnerabilities list on the github project [2], I'd say they were fixed.
All vulnerabilities are marked as affecting <2.4 since 2.5 release, and 
for instance for the username impersonation, it's been specified in the 
release notes that the security have been tightened on this front.


That said, I didn't check the code for every vuln individually, and I 
definitely could ask upstream for clarification/confirmation if you 
think it's necessary.




[1] https://github.com/onionshare/onionshare/releases/tag/v2.5
[2] https://github.com/onionshare/onionshare/security/advisories

Cheers,

--
nodens

Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

2022-10-22 Thread Clément Hermann


Hi!

Thanks for your report.

I could reproduce your issue if I enable check_sigs option in CPAN 
(which is _not_ the default).


Thing is, it's not a bug, really. Or not quite. It's a result of the 
correction of a bug in CPAN < 2.29 who would succeed silently if there 
is no signature/no way to check the key.


You can find some context in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and
http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html

I do agree that it's bad UX that CPAN isn't more helpful when the key 
isn't available, e.g. asking for it or suggesting a way to get it, but 
the fact that it fails if the key isn't available while the Checksums 
are signed is the right behavior, and your workaround (getting the key) 
is the right solution.


CPAN doesn't have a way to centralize key themself, and probably 
shouldn't, either. Not sure how such error can be avoided completely 
(the Debian method of having a preconfigured keyring won't do for CPAN 
IMO), but it should at least suggest a solution.


So setting the severity back to normal, but still leaving the bug open, 
since it's confusing for the user, and it could be done better (upstream).


Cheers,

--
nodens

Bug#970659: nspr: FTBFS on hurd-i386 and tests fails to run.

2022-10-22 Thread Svante Signell

found 970659 2:4.35-1
found 970673 2:4.35-1
thanks

Hello again,
(bug reports first filed on 20+21 september 2020 against 4.28-1)

nspr still FTBFS on GNU/Hurd due to a one-line error in the file 
nspr/pr/src/pthreads/ptsynch.c, see #970659. Additionally tests in runtest.sh
are not run due to a bug in debian/rules, see #970673.

The first problem is solved by adding a condition on __GNU__ in the ptsynch.c
file. Secondly, the missing tests are run by replacing sh - with sh -s in
debian/rules for all tests.

Note that tests for gethost\|getproto\|nblayer\|socket\|vercheck are already
commented out in runtests.sh and not needed. Additionally sema tests needs to be
excluded for GNU/Hurd.

The patches debian/rules.patch and nspr_pr_src_pthreads_ptsynch.c.diff, somewhat
modified with respect to earlier patches, are attached for convenience.

Built and tests run successfully on both GNH/Hurd i386 and GNU/Linux amd64.

Thanks!
--- a/debian/rules	2022-10-17 23:15:00.0 +0200
+++ b/debian/rules	2022-10-17 23:19:20.0 +0200
@@ -84,7 +84,12 @@
 	# Skip socket because it freezes.
 	# Skip getproto because it fails on some buildds.
 	# Skip nblayer because it freezes on armel.
-	cd nspr/pr/tests && grep -v '^\(fdcach\|gethost\|getproto\|nblayer\|peek\|socket\|vercheck\)$$' ./runtests.sh | sh - $(CURDIR)/nspr/dist
+ifneq (hurd,$(shell dpkg-architecture -qDEB_HOST_ARCH_OS))
+	cd nspr/pr/tests && grep -v '^\(fdcach\|peek\)$$' ./runtests.sh | sh -s $(CURDIR)/nspr/dist
+else
+ 	# Skip semaphore tests: not implemented on GNU/Hurd.
+	cd nspr/pr/tests && grep -v '^\(sema\|semaerr\|semaping\)$$' ./runtests.sh | sh -s $(CURDIR)/nspr/dist
+endif
 	cd nspr/lib/tests && LD_LIBRARY_PATH=$(CURDIR)/nspr/dist/bin$(addprefix :,$(LD_LIBRARY_PATH)) ./base64t
 	cd nspr/lib/tests && LD_LIBRARY_PATH=$(CURDIR)/nspr/dist/bin$(addprefix :,$(LD_LIBRARY_PATH)) ./string
 endif
Index: nspr-4.35/nspr/pr/src/pthreads/ptsynch.c
===
--- nspr-4.35.orig/nspr/pr/src/pthreads/ptsynch.c
+++ nspr-4.35/nspr/pr/src/pthreads/ptsynch.c
@@ -50,7 +50,8 @@ void _PR_InitLocks(void)
 rv = _PT_PTHREAD_MUTEXATTR_INIT(&_pt_mattr);
 PR_ASSERT(0 == rv);
 
-#if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)) || \
+#if (defined(LINUX) && (__GLIBC__ > 2) || \
+(__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2))  && !defined(__GNU__) || \
 (defined(FREEBSD) && __FreeBSD_version > 700055)
 rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP);
 PR_ASSERT(0 == rv);

Bug#1022232: libffi8 3.4.3-3 breaks all wayland clients on arm64/aarch64

2022-10-22 Thread Lukas F. Hartmann

Package: libffi8
Version: 3.4.3-3
Severity: important

Dear Maintainer,

Since an `apt upgrade` yesterday on Debian unstable on an aarch64 system 
(imx8mq based, cortex-a53), all wayland compositors and clients stopped 
working, including sway, wayfire and weston. I narrowed it down to garbage data 
in the wayland client/server communication (or a data alignment issue). The 
most common failure was clients reporting "wl_shm@4: error 1: invalid size (0)" 
after the first wl_commit. `weston-info` shows bizarre data like negative 
screen sizes.

Copying in libffi.so.8.1.0 (instead of libffi.so.8.1.1) from a rescue system 
made everything work again, and copying libffi.so.8.1.1 to the good system made 
things break there.

Thanks,
Lukas F. Hartmann

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: arm64 (aarch64)
Foreign Architectures: i386, armhf, amd64

Kernel: Linux 5.19.0-reform2-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libffi8 depends on:
ii  libc6  2.35-3

libffi8 recommends no packages.

libffi8 suggests no packages.

-- no debconf information

Bug#932047: lightdm: greeter session support for elogind

2022-10-22 Thread Yves-Alexis Perez

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2022-10-16 at 11:49 +0100, Mark Hindley wrote:
> > My suspicion is that since this appears to be working for other display
> > managers, it's all fine.
> 
> It seems that way to me as well.

I'm not sure other display managers handle the greeters the same way (running
under their own uid and stuff like that), so I'm unsure if we can really
compare that.

But if it seems that there is no breakage (and hopefully no bad side effects
we don't see yet) I guess we'll be able to update the pam configuration to
uses includes as well at some point.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmNT2yYACgkQ3rYcyPpX
RFtntAf+PrX+vI64PMhmD05GD1A07Y438fJRf5aMkYIPa8n5X1Yc53//SktpHaow
lK07jJurXvyjxQRY3GviHP14ZQfqAgOhln7pDqqIkr+9QKxkNxAZKAJ4W6lKZrGo
VAqas/Qxat+ImO694snxyYDUWnCNgZA7DL+3kxtaHsN9GbTbfDj1h2ghQRKUOA6K
+yQWPq7owks1YzGgcLgLch0Mj7T9XI82J88tJ04iZXBsl3SMVe7/Xr2aSt2HmzRq
sUNAlWlgGJ3RlK7DUPcue3SnSRYc8Y8xChEuAQC3HWS3SmVBCeqQPmOrke1ipk3I
HCcdh98sBi44tSAW65/B+jBGTDyGlw==
=Rw/9
-END PGP SIGNATURE-

Bug#1021735: libffi upgrade breaks Wayland on aarch64

2022-10-22 Thread Daniel Stone

Hi,
This libffi upgrade also completely breaks all use of Wayland on
aarch64. We use libffi to dispatch protocol messages (requests
received by the server and events received by the client) to
native-code handlers, and we are now getting completely nonsensical
values from it.

Can this upgrade please be rolled back until it can be root-caused and fixed?

Cheers,
Daniel

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

2022-10-22 Thread Salvatore Bonaccorso

Hi,

On Fri, Jul 15, 2022 at 02:04:38PM +0200, Moritz Mühlenhoff wrote:
> Source: onionshare
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for onionshare.
> 
> CVE-2021-41867[0]:
> | An information disclosure vulnerability in OnionShare 2.3 before 2.4
> | allows remote unauthenticated attackers to retrieve the full list of
> | participants of a non-public OnionShare node via the --chat feature.
> 
> https://github.com/onionshare/onionshare/compare/v2.3.3...v2.4
> https://www.ihteam.net/advisory/onionshare/
> 
> CVE-2021-41868[1]:
> | OnionShare 2.3 before 2.4 allows remote unauthenticated attackers to
> | upload files on a non-public node when using the --receive
> | functionality.
> 
> https://github.com/onionshare/onionshare/compare/v2.3.3...v2.4
> https://www.ihteam.net/advisory/onionshare/
> 
> CVE-2022-21688[2]:
> | OnionShare is an open source tool that lets you securely and
> | anonymously share files, host websites, and chat with friends using
> | the Tor network. Affected versions of the desktop application were
> | found to be vulnerable to denial of service via an undisclosed
> | vulnerability in the QT image parsing. Roughly 20 bytes lead to 2GB
> | memory consumption and this can be triggered multiple times. To be
> | abused, this vulnerability requires rendering in the history tab, so
> | some user interaction is required. An adversary with knowledge of the
> | Onion service address in public mode or with authentication in private
> | mode can perform a Denial of Service attack, which quickly results in
> | out-of-memory for the server. This requires the desktop application
> | with rendered history, therefore the impact is only elevated. This
> | issue has been patched in version 2.5.
> 
> https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v
> 
> CVE-2022-21689[3]:
> | OnionShare is an open source tool that lets you securely and
> | anonymously share files, host websites, and chat with friends using
> | the Tor network. In affected versions the receive mode limits
> | concurrent uploads to 100 per second and blocks other uploads in the
> | same second, which can be triggered by a simple script. An adversary
> | with access to the receive mode can block file upload for others.
> | There is no way to block this attack in public mode due to the
> | anonymity properties of the tor network.
> 
> https://github.com/onionshare/onionshare/security/advisories/GHSA-jh82-c5jw-pxpc
> 
> CVE-2022-21690[4]:
> | OnionShare is an open source tool that lets you securely and
> | anonymously share files, host websites, and chat with friends using
> | the Tor network. In affected versions The path parameter of the
> | requested URL is not sanitized before being passed to the QT frontend.
> | This path is used in all components for displaying the server access
> | history. This leads to a rendered HTML4 Subset (QT RichText editor) in
> | the Onionshare frontend.
> 
> https://github.com/onionshare/onionshare/security/advisories/GHSA-ch22-x2v3-v6vq
> 
> CVE-2022-21691[5]:
> | OnionShare is an open source tool that lets you securely and
> | anonymously share files, host websites, and chat with friends using
> | the Tor network. In affected versions chat participants can spoof
> | their channel leave message, tricking others into assuming they left
> | the chatroom.
> 
> https://github.com/onionshare/onionshare/security/advisories/GHSA-w9m4-7w72-r766
> 
> CVE-2022-21692[6]:
> | OnionShare is an open source tool that lets you securely and
> | anonymously share files, host websites, and chat with friends using
> | the Tor network. In affected versions anyone with access to the chat
> | environment can write messages disguised as another chat participant.
> 
> https://github.com/onionshare/onionshare/security/advisories/GHSA-gjj5-998g-v36v
> 
> CVE-2022-21693[7]:
> | OnionShare is an open source tool that lets you securely and
> | anonymously share files, host websites, and chat with friends using
> | the Tor network. In affected versions an adversary with a primitive
> | that allows for filesystem access from the context of the Onionshare
> | process can access sensitive files in the entire user home folder.
> | This could lead to the leaking of sensitive data. Due to the automatic
> | exclusion of hidden folders, the impact is reduced. This can be
> | mitigated by usage of the flatpak release.
> 
> https://github.com/onionshare/onionshare/security/advisories/GHSA-jgm9-xpfj-4fq6
> 
> CVE-2022-21694[8]:
> | OnionShare is an open source tool that lets you securely and
> | anonymously share files, host websites, and chat with friends using
> | the Tor network. The website mode of the onionshare allows to use a
> | hardened CSP, which will block any scripts and external resources. It
> | is not possible to configure this CSP for individual pages and
> | therefore the security enhancement cannot be used for

Bug#1022207: ITP: pysocks -- Lets you send traffic through SOCKS proxy servers

2022-10-22 Thread Nilson Silva

Thanks!


Nilson F. Silva

81-3036-0200

81-991616348

81-98546-9553


De: Carsten Schoenert 
Enviado: sábado, 22 de outubro de 2022 01:56
Para: Josenilson Ferreira da Silva ; 
1022...@bugs.debian.org <1022...@bugs.debian.org>
Assunto: Re: Bug#1022207: ITP: pysocks -- Lets you send traffic through SOCKS 
proxy servers

Hi,

Am 22.10.22 um 01:44 schrieb Josenilson Ferreira da Silva:
> Package: wnpp
> Severity: wishlist
> Owner: Josenilson Ferreira da Silva 
> X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com
>
>   It is a modern fork of SocksiPy with bug fixes and extra
>   features. Acts as a drop-in replacement to the socket module.
>   Seamlessly configure SOCKS proxies for any socket object by
>   calling socket_object.set_proxy().
>   .
>   Features:
>- SOCKS proxy client for Python 2.7 and 3.4+
>- TCP supported, UDP mostly supported (issues may occur in
>  some edge cases).
>- HTTP proxy client included but not supported or recommended
>  (you should use requests', or your HTTP client's, own HTTP
>  proxy interface).
> * Package name: pysocks
>Version : 1.7.0
>Upstream Author :  Anorov 
> * URL : https://github.com/Anorov/PySocks
> * License : BSD-3-clause
>Programming Lang: Python
>Description : Lets you send traffic through SOCKS proxy servers
>
>   Note:
>   package is a required dependency for packaging from
>   https://github.com/sherlock-project/sherlock

a quick check on the CLI shows me that this seems to be already packaged.
Did you have checked this before writing the ITP?

> $ apt show python3-socks
> Package: python3-socks
> Version: 1.7.1+dfsg-1
> Priority: optional
> Section: python
> Source: python-socksipy
> Maintainer: Debian Python Team 
> Installed-Size: 78,8 kB
> Depends: python3:any
> Breaks: python3-pysocks, python3-socksipy
> Replaces: python3-pysocks, python3-socksipy
> Homepage: https://github.com/Anorov/PySocks
> Download-Size: 23,3 kB
> APT-Sources: http://ftp.de.debian.org/debian testing/main amd64 Packages
> Description: Python 3 SOCKS client module
>  This module was designed to allow developers of Python
>  software that uses the Internet or another TCP/IP-based
>  network to add support for connection through a SOCKS proxy
>  server with as much ease as possible.
>  .
>  The module is also knowns as SocksiPy or PySocks.
>  .
>  This is the Python 3 version.


--
Regards
Carsten

Bug#1021773: libconfig-model-dpkg-perl: tweak example in docs for fix.(scanned.)copyright does not work

2022-10-22 Thread Andreas Metzler

On 2022-10-22 Dominique Dumont  wrote:
> On Saturday, 22 October 2022 12:09:30 CEST you wrote:
> > Thank you. This does not throw an error, but does not work as expected
> > either:
> > (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ cat
> > debian/fix.scanned.copyright ! Files:"*" Copyright=~"s/, Free Software$/,
> > Free Software Foundation, Inc./"
> > (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ >
> > debian/copyright && cme update dpkg-copyright > /dev/null 2>&1
> > (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ grep ', Free
> > Software$' debian/copyright Copyright: 2007-2012, 2014-2016, 2019, 2021,
> > 2022, Free Software
> > Copyright: 2004, 2005, 2007-2009, 2011-2015, Free Software

> Hmm, Looking at guile-gnutls copyright file [1],  I see that this entry is 
> correct:

> Files: *
> Copyright: 1985, 1986, 1988, 1990-2021, Free Software Foundation, Inc.
> License: GPL-3+

> whereas the following entry is not:

> Files: guile/modules/gnutls.in
> Copyright: 2007-2012, 2014-2016, 2019, 2021, 2022, Free Software
> License: LGPL-2.1+

> So, I assume you want to apply the instruction specified in 
> fix.scanned.copyright to change all copyright entries.

> Which is not the case because 

> "! Files:"*"Copyright=~"s/, Free Software$/, Free Software Foundation, Inc./"

> applies *only* on:

> Files: *
[ Way to do it snipped]

I see. :-) Thank you very much for the handholding.

cu Andreas

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

Bug#1022231: iptables-persistent: Pre-existing /etc/iptables/rules.v4 is overriten when installing

2022-10-22 Thread Christian Buhtz

Package: iptables-persistent
Severity: normal

I had an existing /etc/iptables/rules.v4 file on my system.
In the next step I installed "iptables-persistent" and said yes to both
questions about saving current existing rules.

Then the file and my rules in it where gone.
That shouldn't happen.

When you want to touch that file that add content to it but not overwrite it.


-- System Information:
Debian Release: 11.5
  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-18-amd64 (SMP w/4 CPU threads)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iptables-persistent depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  iptables   1.8.7-1
pn  netfilter-persistent

Bug#1021773: libconfig-model-dpkg-perl: tweak example in docs for fix.(scanned.)copyright does not work

2022-10-22 Thread Dominique Dumont

On Saturday, 22 October 2022 12:09:30 CEST you wrote:
> Thank you. This does not throw an error, but does not work as expected
> either:
> (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ cat
> debian/fix.scanned.copyright ! Files:"*" Copyright=~"s/, Free Software$/,
> Free Software Foundation, Inc./"
> (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ >
> debian/copyright && cme update dpkg-copyright > /dev/null 2>&1
> (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ grep ', Free
> Software$' debian/copyright Copyright: 2007-2012, 2014-2016, 2019, 2021,
> 2022, Free Software
> Copyright: 2004, 2005, 2007-2009, 2011-2015, Free Software

Hmm, Looking at guile-gnutls copyright file [1],  I see that this entry is 
correct:

Files: *
Copyright: 1985, 1986, 1988, 1990-2021, Free Software Foundation, Inc.
License: GPL-3+

whereas the following entry is not:

Files: guile/modules/gnutls.in
Copyright: 2007-2012, 2014-2016, 2019, 2021, 2022, Free Software
License: LGPL-2.1+

So, I assume you want to apply the instruction specified in 
fix.scanned.copyright to change all copyright entries.

Which is not the case because 

"! Files:"*"Copyright=~"s/, Free Software$/, Free Software Foundation, Inc./"

applies *only* on:

Files: *
Copyright: 1985, 1986, 1988, 1990-2021, Free Software Foundation, Inc.
License: GPL-3+

If you want to fix all copyright entries, you should use the foreach_match 
instruction [2].

For instance, starting from [1], I can fix the wrong copyright entries with 
(note the Files argument is different):

$ cme modify dpkg-copyright '! Files:~/.*/ Copyright=~"s/, Free Software$/, 
Free Software Foundation, Inc./"'
Warning in 'Files:"build-aux/ltmain.sh" License short_name': licensecheck found 
an ambiguous license statement. Please:
- check the source code to find the actual license association
- override this value using "override-license" parameter in 
"debian/fill.copyright.blanks.yml" file.
See "Filling the blanks" section in Dpkg::Copyright::Scanner(3pm) man page for 
details  (this cannot be fixed with 'cme fix' command)
Offending value: '(GPL-2+ and/or GPL-3+) with Libtool exception'

Changes applied to dpkg-copyright configuration:
- Files:"guile/modules/gnutls.in" Copyright: '2007-2012, 2014-2016, 2019, 2021, 
2022, Free Software' -> '2007-2012, 2014-2016, 2019, 2021, 2022, Free Software 
Founda[...]'
- Files:"m4/ltoptions.m4
 m4/ltsugar.m4
 m4/lt~obsolete.m4" Copyright: '2004, 2005, 2007-2009, 2011-2015, Free 
Software' -> '2004, 2005, 2007-2009, 2011-2015, Free Software Foundation, [...]'

$ git diff
diff --git a/debian/copyright b/debian/copyright
index 17dcb21..9660ba5 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -78,7 +78,7 @@ Copyright: 1985, 1986, 1988, 1990-2018, Free Software 
Foundation, Inc.
 License: GPL-3+
 
 Files: guile/modules/gnutls.in
-Copyright: 2007-2012, 2014-2016, 2019, 2021, 2022, Free Software
+Copyright: 2007-2012, 2014-2016, 2019, 2021, 2022, Free Software Foundation, 
Inc.
 License: LGPL-2.1+
 
 Files: guile/modules/gnutls/build/*
@@ -108,7 +108,7 @@ License: LGPL-3+
 Files: m4/ltoptions.m4
   m4/ltsugar.m4
   m4/lt~obsolete.m4
-Copyright: 2004, 2005, 2007-2009, 2011-2015, Free Software
+Copyright: 2004, 2005, 2007-2009, 2011-2015, Free Software Foundation, Inc.
 License: FSFULLR
 

The following command also works fine if you want a more readable version:

$ cme modify dpkg-copyright '! Files:.foreach_match(.*) Copyright=~"s/, Free 
Software$/, Free Software Foundation, Inc./"'

.foreach_match(/.*/) also works.

You can use the instruction passed to cme modify command in 
debian/fix.scanned.copyright

HTH

[1] 
https://salsa.debian.org/gnutls-team/guile-gnutls/-/blob/main/debian/copyright
[2] 
https://metacpan.org/pod/Config::Model::Loader#xxx:.foreach_match(yy)-or-xxx:~yy

Bug#1022230: maliit-keyboard has a broken dependency

2022-10-22 Thread Nils Jacobs

Package: maliit-keyboard
Version: 2.2.1.1-1
Severity: important
X-Debbugs-Cc: oj002...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   updating to the newest version of maliit-keyboard in sid
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   jus trying to upgrade
   * What was the outcome of this action?
   apt failed to upgrade the package
   * What outcome did you expect instead?
   a successfull upgrade

the newest version of maliit-keyboard depends on 
qml-module-qtquick-qtgraphicaleffects which does not exist.
I think the correct package name would be qml-module-qtgraphicaleffects which 
does exist

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

Kernel: Linux 5.19.0-2-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

Versions of packages maliit-keyboard depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.35-3
ii  libchewing3  0.5.1-4
ii  libgcc-s112.2.0-7
ii  libglib2.0-0 2.74.0-3
ii  libhunspell-1.7-01.7.1-1
ii  libmaliit-plugins2   2.3.0-2
ii  libpinyin13  2.6.2-2
ii  libpresage1v50.9.1-2.3
ii  libqt5core5a 5.15.6+dfsg-2
ii  libqt5dbus5  5.15.6+dfsg-2
ii  libqt5feedback5  5.0~git20180903.a14bd0b-5
ii  libqt5gui5   5.15.6+dfsg-2
ii  libqt5multimedia55.15.6-2
ii  libqt5qml5   5.15.6+dfsg-2
ii  libqt5quick5 5.15.6+dfsg-2
ii  libstdc++6   12.2.0-7
ii  maliit-framework 2.3.0-2

maliit-keyboard recommends no packages.

maliit-keyboard suggests no packages.

-- no debconf information

Bug#1022229: Failing tests with PHP 8.2

Package: cacti
Version: 1.2.22+ds1-1
Severity: important
Control: block 1014460 by -1

Hi Paul,

There are some tests failure under PHP 8.2.

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults

A quick look shows some deprecation messages, but no activity upstream
on the related files.

Regards

David


signature.asc
Description: PGP signature

Bug#1022228: Failing tests with PHP 8.2

Package: shaarli
Version: 0.12.1+dfsg-5
Severity: important
Control: block 1014460 by -1

Hi James,

There are some tests failure under PHP 8.2.

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults

Even if there have been no updated version upstream for two years, it
looks like the repository is still active, so hopefully “just”
cherry-picking the needed fixes will be enough.

Regards

David


signature.asc
Description: PGP signature

Bug#1022227: Failing tests with PHP 8.2

Package: php-nesbot-carbon
Version: 2.59.1-2
Severity: important
Control: block 1014460 by -1

Hi Robin,

There are some tests failure under PHP 8.2.

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults

Hopefully “just” updating the package to the latest version will make
those go away.

Regards

David


signature.asc
Description: PGP signature

Bug#1022198: rust-rustyline: please upgrade to v9