date:20220527

Bug#1011970: nrepl-clojure: autopkgtest regression on armhf and i386

2022-05-27 Thread Paul Gevers


Source: nrepl-clojure
Version: 0.9.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
nrepl-clojure  from testing0.9.0-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 to testing [1]. Can 
you please investigate the situation and fix it?


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=nrepl-clojure

https://ci.debian.net/data/autopkgtest/testing/armhf/n/nrepl-clojure/22173980/log.gz

#'user/all-tests
(nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
nil)


Testing nrepl.util.completion-test

Testing nrepl.misc-test
ERROR:

Testing nrepl.middleware.dynamic-loader-test

Testing nrepl.edn-test
java.io.FileNotFoundException: Could not locate 
unknown_middleware__init.class, unknown_middleware.clj or 
unknown_middleware.cljc on classpath. Please check that namespaces with 
dashes use underscores in the Clojure file name.

at clojure.lang.RT.load(RT.java:462)
at clojure.lang.RT.load(RT.java:424)
at clojure.core$load$fn__6856.invoke(core.clj:6115)
at clojure.core$load.invokeStatic(core.clj:6114)
at clojure.core$load.doInvoke(core.clj:6098)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invokeStatic(core.clj:5897)
at clojure.core$load_one.invoke(core.clj:5892)
at clojure.core$load_lib$fn__6796.invoke(core.clj:5937)
at clojure.core$load_lib.invokeStatic(core.clj:5936)
at clojure.core$load_lib.doInvoke(core.clj:5917)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:669)
at clojure.core$load_libs.invokeStatic(core.clj:5974)
at clojure.core$load_libs.doInvoke(core.clj:5958)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:669)
at clojure.core$require.invokeStatic(core.clj:5996)
at clojure.core$require.doInvoke(core.clj:5996)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at nrepl.misc$requiring_resolve.invokeStatic(misc.clj:73)
at nrepl.misc$requiring_resolve.doInvoke(misc.clj:66)
at clojure.lang.RestFn.invoke(RestFn.java:423)
	at 
nrepl.middleware.dynamic_loader$update_stack_BANG_$fn__2290$fn__2291.invoke(dynamic_loader.clj:36)

at clojure.core$map$fn__5884.invoke(core.clj:2757)
at clojure.lang.LazySeq.sval(LazySeq.java:42)
at clojure.lang.LazySeq.seq(LazySeq.java:51)
at clojure.lang.RT.seq(RT.java:535)
at clojure.core$seq__5419.invokeStatic(core.clj:139)
at clojure.core$map$fn__5884.invoke(core.clj:2750)
at clojure.lang.LazySeq.sval(LazySeq.java:42)
at clojure.lang.LazySeq.seq(LazySeq.java:51)
at clojure.lang.RT.seq(RT.java:535)
at clojure.core$seq__5419.invokeStatic(core.clj:139)
at clojure.core$map$fn__5884.invoke(core.clj:2750)
at clojure.lang.LazySeq.sval(LazySeq.java:42)
at clojure.lang.LazySeq.seq(LazySeq.java:51)
at clojure.lang.RT.seq(RT.java:535)
at clojure.core$seq__5419.invokeStatic(core.clj:139)
at clojure.core$apply.invokeStatic(core.clj:662)
at clojure.core$mapcat.invokeStatic(core.clj:2787)
at clojure.core$mapcat.doInvoke(core.clj:2787)
at clojure.lang.RestFn.invoke(RestFn.java:423)
at nrepl.middleware$extend_deps.invokeStatic(middleware.clj:113)
at nrepl.middleware$extend_deps.invoke(middleware.clj:108)
	at 
nrepl.middleware$linearize_middleware_stack.invokeStatic(middleware.clj:183)

at 
nrepl.middleware$linearize_middleware_stack.invoke(middleware.clj:179)
	at 
nrepl.middleware.dynamic_loader$update_stack_BANG_$fn__2290.invoke(dynamic_loader.clj:38)

at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:667)
at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1977)
at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1977)
at clojure.lang.RestFn.invoke(RestFn.java:425)
	at 
nrepl.middleware.dynamic_loader$update_stack_BANG_.invokeStatic(dynamic_loader.clj:29)
	at 
nrepl.middleware.dynamic_loader$update_stack_BANG_.invoke(dynamic_loader.clj:27)
	at 
nrepl.middleware.dynamic_loader$wrap_dynamic_loader$fn__2333.invoke(dynamic_loader.clj:77)

at

Bug#1011969: cljx-clojure: autopkgtest needs update for new version of nrepl-clojure

2022-05-27 Thread Paul Gevers


Source: cljx-clojure
Version: 0.6.0-3
Severity: serious
X-Debbugs-CC: nrepl-cloj...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:nrepl-clojure

Dear maintainer(s),

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


   passfail
nrepl-clojure  from testing0.9.0-1
cljx-clojure   from testing0.6.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. I *think* the 
 error says that the package needs to be updated to accept a newer 
nrepl-clojure. I'm not familiar with clojure so I might have interpreted 
things wrongly.


Currently this regression is blocking the migration of nrepl-clojure to 
testing [1]. Of course, nrepl-clojure shouldn't just break your 
autopkgtest (or even worse, your package), but it seems to me that the 
change in nrepl-clojure was intended and your package needs to update to 
the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from nrepl-clojure should 
really add a versioned Breaks on the unfixed version of (one of your) 
package(s). Note: the Breaks is nice even if the issue is only in the 
autopkgtest as it helps the migration software to figure out the right 
versions to combine in the tests.


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=nrepl-clojure

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cljx-clojure/22174960/log.gz

Rewriting test to target/test-output (clj) with features #{clj} and 0 
transformations.
Rewriting test to target/test-output (cljs) with features #{cljs} and 1 
transformations.
Cannot access central (https://repo1.maven.org/maven2/) in offline mode 
and the artifact nrepl:nrepl:jar:0.6.0 has not been downloaded from it 
before.
Cannot access clojars (https://repo.clojars.org/) in offline mode and 
the artifact nrepl:nrepl:jar:0.6.0 has not been downloaded from it before.
This could be due to a typo in :dependencies, file system permissions, 
or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment 
variable.

autopkgtest [18:11:53]: test unittests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011962: rust-serde source package waiting in NEW queue

2022-05-27 Thread Wolfgang Silbermayr

Both packages were uploaded in sync by James McCoy, but the rust-serde 1.0.136
source package landed in the NEW queue (possibly due to new binary package[s]
built from it), so it's awaiting approval or rejection there.

Bug#1011968: spades: autopkgtest regression

2022-05-27 Thread Paul Gevers


Source: spades
Version: 3.15.4+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
spades from testing3.15.4+dfsg-2
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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

https://ci.debian.net/data/autopkgtest/testing/amd64/s/spades/22180185/log.gz



== Warning ==  No assembly mode was specified! If you intend to assemble 
high-coverage multi-cell/isolate data, use '--isolate' option.



Command line: /usr/libexec/spades/spades.py --test  

System information:
  SPAdes version: 3.15.4
  Python version: 3.10.4
  OS: Linux-5.10.0-14-amd64-x86_64-with-glibc2.33

Output dir: /tmp/tmp.Kw3upbPyKH/spades_test
Mode: read error correction and assembling
Debug mode is turned OFF

Dataset parameters:
  Standard mode
  For multi-cell/isolate data we recommend to use '--isolate' option; 
for single-cell MDA data use '--sc'; for metagenomic data use '--meta'; 
for RNA-Seq use '--rna'.

  Reads:
Library number: 1, library type: paired-end
  orientation: fr
  left reads: ['/usr/share/spades/test_dataset/ecoli_1K_1.fq.gz']
  right reads: ['/usr/share/spades/test_dataset/ecoli_1K_2.fq.gz']
  interlaced reads: not specified
  single reads: not specified
  merged reads: not specified
Read error correction parameters:
  Iterations: 1
  PHRED offset will be auto-detected
  Corrected reads will be compressed
Assembly parameters:
  k: automatic selection based on read length
  Repeat resolution is enabled
  Mismatch careful mode is turned OFF
  MismatchCorrector will be SKIPPED
  Coverage cutoff is turned OFF
Other parameters:
  Dir for temp files: /tmp/tmp.Kw3upbPyKH/spades_test/tmp
  Threads: 16
  Memory limit (in Gb): 250


=== SPAdes pipeline started. Log can be found here: 
/tmp/tmp.Kw3upbPyKH/spades_test/spades.log


/usr/share/spades/test_dataset/ecoli_1K_1.fq.gz: max reads length: 100
/usr/share/spades/test_dataset/ecoli_1K_2.fq.gz: max reads length: 100

Reads length: 100


= Before start started.

= Read error correction started.

= Read error correction started.

== Running: /usr/libexec/spades/spades-hammer 
/tmp/tmp.Kw3upbPyKH/spades_test/corrected/configs/config.info


  0:00:00.000 1M / 16M   INFOGeneral (main.cpp 
 :  75)   Starting BayesHammer, built from N/A, git 
revision N/A
  0:00:00.034 1M / 16M   INFOGeneral (main.cpp 
 :  76)   Loading config from 
/tmp/tmp.Kw3upbPyKH/spades_test/corrected/configs/config.info
  0:00:00.066 1M / 16M   INFOGeneral (main.cpp 
 :  78)   Maximum # of threads to use (adjusted due to 
OMP capabilities): 16
  0:00:00.082 1M / 16M   INFOGeneral 
(memory_limit.cpp  :  54)   Memory limit set to 250 Gb
  0:00:00.082 1M / 16M   INFOGeneral (main.cpp 
 :  86)   Trying to determine PHRED offset
  0:00:00.083 1M / 16M   INFOGeneral (main.cpp 
 :  92)   Determined value is 33
  0:00:00.083 1M / 16M   INFOGeneral 
(hammer_tools.cpp  :  38)   Hamming graph threshold tau=1, k=21, 
subkmer positions = [ 0 10 ]
  0:00:00.083 1M / 16M   INFOGeneral (main.cpp 
 : 113)   Size of aux. kmer data 24 bytes

 === ITERATION 0 begins ===
  0:00:00.083 1M / 16M   INFOGeneral 
(kmer_index_builder.hpp: 243)   Splitting kmer instances into 16 
files using 16 threads. This might take a while.
  0:00:00.083 1M / 16M   INFOGeneral 
(file_limit.hpp:  42)   Open file limit set to 1024
  0:00:00.083 1M / 16M   INFOGeneral 
(kmer_splitter.hpp :  93)   Memory available for splitting 
buffers: 5.20833 Gb
  0:00:00.083 1M / 16M   INFOGeneral 
(kmer_splitter.hpp : 101)   Using cell size of 4194304
  0:00:00.222  9217M / 9217M INFO   K-mer Splitting 
(kmer_data.cpp :  97)   Processing 
/usr/share/spades/test_dataset/ecoli_1K_1.fq.gz
  0:00:00.238  9217M / 9217M INFO   K-mer Splitting 
(kmer_data.cpp :  97)   Processing 
/usr/share/spades/test_dataset/ecoli_1K_2.fq.gz
  0:00:00.250  9217M / 9217M INFO   K-mer Splitting 
(kmer_data.cpp : 112)   Total 4108 reads processed
  0:00:00.250

Bug#1011967: trapperkeeper-clojure: autopkgtest regression: FileNotFoundException

2022-05-27 Thread Paul Gevers


Source: trapperkeeper-clojure
Version: 3.1.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
trapperkeeper-clojure  from testing3.1.0-3
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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=trapperkeeper-clojure

https://ci.debian.net/data/autopkgtest/testing/amd64/t/trapperkeeper-clojure/21710139/log.gz

#'user/all-tests
Syntax error (FileNotFoundException) compiling at 
(clojure/core/async/impl/ioc_macros.clj:1:1).
Could not locate clojure/tools/analyzer__init.class, 
clojure/tools/analyzer.clj or clojure/tools/analyzer.cljc on classpath.


Full report at:
/tmp/clojure-14644010619048898901.edn
autopkgtest [08:00:50]: test unittests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011966: alt-ergo: autopkgtest regression: /usr/share/doc/alt-ergo/examples/valid/*.why: No such file or directory

2022-05-27 Thread Paul Gevers


Source: alt-ergo
Version: 2.4.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
alt-ergo   from testing2.4.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 to testing [1]. Can 
you please investigate the situation and fix it?


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=alt-ergo

https://ci.debian.net/data/autopkgtest/testing/amd64/a/alt-ergo/22180660/log.gz

Fatal error: exception 
Sys_error("/usr/share/doc/alt-ergo/examples/valid/*.why: No such file or 
directory")

autopkgtest [23:11:40]: test valid



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011965: node-deep-equal breaks node-debbundle-es-to-primitive autopkgtest: Cannot find module 'functions-have-names'

2022-05-27 Thread Paul Gevers


Source: node-deep-equal, node-debbundle-es-to-primitive
Control: found -1 node-deep-equal/2.0.5+~cs32.12.77-1
Control: found -1 node-debbundle-es-to-primitive/1.2.1+~cs9.7.25-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of node-deep-equal the autopkgtest of 
node-debbundle-es-to-primitive fails in testing when that autopkgtest is 
run with the binary packages of node-deep-equal from unstable. It passes 
when run with only packages from testing. In tabular form:


   passfail
node-deep-equalfrom testing2.0.5+~cs32.12.77-1
node-debbundle-es-to-primitive from testing1.2.1+~cs9.7.25-2
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 node-deep-equal 
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=node-deep-equal

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-debbundle-es-to-primitive/22158618/log.gz

# Using ./package.(json|yaml)
# Node module name is es-to-primitive
# Build files found: Makefile
# Test files found: test
# Files/dir to be installed from source: test Makefile
# Copy test files
# Copy debian/tests/pkg-js content
'debian/tests/pkg-js' -> 
'/tmp/autopkgtest-lxc.8wigdf4l/downtmp/autopkgtest_tmp/smokeizZQSa/debian/tests/pkg-js'
'debian/tests/pkg-js/test' -> 
'/tmp/autopkgtest-lxc.8wigdf4l/downtmp/autopkgtest_tmp/smokeizZQSa/debian/tests/pkg-js/test'

Found debian/tests/test_modules
# let's copy it
'@types/es-to-primitive' linked into node_modules
'has-symbols' linked into node_modules
'is-callable' linked into node_modules
'is-date-object' linked into node_modules
'is-symbol' linked into node_modules
'make-arrow-function' linked into node_modules
'make-generator-function' linked into node_modules
'object-is' linked into node_modules
# Searching module in /usr/lib/nodejs/es-to-primitive
# Searching module in /usr/lib/*/nodejs/es-to-primitive
# Searching module in /usr/share/nodejs/es-to-primitive
# Found /usr/share/nodejs/es-to-primitive
# Searching files to link in /usr/share/nodejs/es-to-primitive
'./es2015.js' -> '/usr/share/nodejs/es-to-primitive/es2015.js'
'./es5.js' -> '/usr/share/nodejs/es-to-primitive/es5.js'
'./es6.js' -> '/usr/share/nodejs/es-to-primitive/es6.js'
'./helpers' -> '/usr/share/nodejs/es-to-primitive/helpers'
'./index.js' -> '/usr/share/nodejs/es-to-primitive/index.js'
'./package.json' -> '/usr/share/nodejs/es-to-primitive/package.json'
# Launch debian/tests/pkg-js/test with sh -ex
+ tap -R spec --no-cov test

node:internal/modules/cjs/loader:936
  throw err;
  ^

Error: Cannot find module 'functions-have-names'
Require stack:
- /usr/share/nodejs/regexp.prototype.flags/implementation.js
- /usr/share/nodejs/regexp.prototype.flags/index.js
- /usr/share/nodejs/deep-equal/index.js
- /usr/share/nodejs/tape/lib/test.js
- /usr/share/nodejs/tape/index.js
- 
/tmp/autopkgtest-lxc.8wigdf4l/downtmp/autopkgtest_tmp/smokeizZQSa/test/es2015.js
at Function.Module._resolveFilename 
(node:internal/modules/cjs/loader:933:15)

at Function.Module._load (node:internal/modules/cjs/loader:778:27)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at Object. 
(/usr/share/nodejs/regexp.prototype.flags/implementation.js:3:38)

at Module._compile (node:internal/modules/cjs/loader:1103:14)
at Object.Module._extensions..js 
(node:internal/modules/cjs/loader:1157:10)

at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/usr/share/nodejs/regexp.prototype.flags/implementation.js',
'/usr/share/nodejs/regexp.prototype.flags/index.js',
'/usr/share/nodejs/deep-equal/index.js',
'/usr/share/nodejs/tape/lib/test.js',
'/usr/share/nodejs/tape/index.js',

'/tmp/autopkgtest-lxc.8wigdf4l/downtmp/autopkgtest_tmp/smokeizZQSa/test/es2015.js'
  ]
}
node:internal/modules/cjs/loader:936
  throw err;
  ^

Error: Cannot find module 'functions-have-names'
Require stack:
- /usr/share/nodejs/regexp.prototype.flags/implementation.js
- /usr/share/nodejs/regexp.prototype.flags/index.js
- /usr/share/nodejs/deep-equal/index.js
- /usr/share/nodejs/tape/lib/test.js
- /usr/share/nodejs/tape/index.js
- 
/tmp/autopkgtest-lxc.8wigdf4l/downtmp/autopkgtest_tmp/smokeizZQSa/test/es5.js
at

Bug#1011964: ipykernel: autopkgtest regression: ERROR at setup of test_asyncio_interrupt

2022-05-27 Thread Paul Gevers


Source: ipykernel
Version: 6.13.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
ipykernel  from testing6.13.0-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 to testing [1]. Can 
you please investigate the situation and fix it?


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

https://ci.debian.net/data/autopkgtest/testing/amd64/i/ipykernel/22160991/log.gz

[31m[1m___ ERROR at setup of test_asyncio_interrupt 
___[0m


cls = 
func = . at 0x7fdd6d273b50>
when = 'setup'
reraise = (, )

[37m@classmethod[39;49;00m
[94mdef[39;49;00m [92mfrom_call[39;49;00m(
[96mcls[39;49;00m,
func: [33m"[39;49;00m[33mCallable[[], 
TResult][39;49;00m[33m"[39;49;00m,
when: 
[33m"[39;49;00m[33mLiteral[[39;49;00m[33m'[39;49;00m[33mcollect[39;49;00m[33m'[39;49;00m[33m, 
[39;49;00m[33m'[39;49;00m[33msetup[39;49;00m[33m'[39;49;00m[33m, [39;49;00m[33m'[39;49;00m[33mcall[39;49;00m[33m'[39;49;00m[33m, 
[39;49;00m[33m'[39;49;00m[33mteardown[39;49;00m[33m'[39;49;00m[33m][39;49;00m[33m"[39;49;00m,

reraise: Optional[
Union[Type[[96mBaseException[39;49;00m], 
Tuple[Type[[96mBaseException[39;49;00m], ...]]

] = [94mNone[39;49;00m,
) -> 
[33m"[39;49;00m[33mCallInfo[TResult][39;49;00m[33m"[39;49;00m:

excinfo = [94mNone[39;49;00m
start = timing.time()
precise_start = timing.perf_counter()
[94mtry[39;49;00m:

  result: Optional[TResult] = func()


[1m[31m/usr/lib/python3/dist-packages/_pytest/runner.py[0m:311: _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ 
[1m[31m/usr/lib/python3/dist-packages/_pytest/runner.py[0m:255: in 

[94mlambda[39;49;00m: ihook(item=item, **kwds), when=when, 
reraise=reraise
[1m[31m/usr/lib/python3/dist-packages/pluggy/_hooks.py[0m:265: in 
__call__
[94mreturn[39;49;00m 
[96mself[39;49;00m._hookexec([96mself[39;49;00m.name, 
[96mself[39;49;00m.get_hookimpls(), kwargs, firstresult)
[1m[31m/usr/lib/python3/dist-packages/pluggy/_manager.py[0m:80: in 
_hookexec
[94mreturn[39;49;00m 
[96mself[39;49;00m._inner_hookexec(hook_name, methods, kwargs, 
firstresult)
[1m[31m/usr/lib/python3/dist-packages/_pytest/unraisableexception.py[0m:83: 
in pytest_runtest_setup

[94myield from[39;49;00m unraisable_exception_runtest_hook()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _
[94mdef[39;49;00m 
[92munraisable_exception_runtest_hook[39;49;00m() -> 
Generator[[94mNone[39;49;00m, [94mNone[39;49;00m, [94mNone[39;49;00m]:
[94mwith[39;49;00m catch_unraisable_exception() 
[94mas[39;49;00m cm:

[94myield[39;49;00m
[94mif[39;49;00m cm.unraisable:
[94mif[39;49;00m cm.unraisable.err_msg 
[95mis[39;49;00m [95mnot[39;49;00m [94mNone[39;49;00m:

err_msg = cm.unraisable.err_msg
[94melse[39;49;00m:
err_msg = [33m"[39;49;00m[33mException 
ignored in[39;49;00m[33m"[39;49;00m
msg = 
[33mf[39;49;00m[33m"[39;49;00m[33m{[39;49;00merr_msg[33m}[39;49;00m[33m: 
[39;49;00m[33m{[39;49;00mcm.unraisable.object[33m!r}[39;49;00m[33m\n[39;49;00m[33m\n[39;49;00m[33m"[39;49;00m

msg += [33m"[39;49;00m[33m"[39;49;00m.join(
traceback.format_exception(
cm.unraisable.exc_type,
cm.unraisable.exc_value,
cm.unraisable.exc_traceback,
)
)

  warnings.warn(pytest.PytestUnraisableExceptionWarning(msg))
[1m[31mE   pytest.PytestUnraisableExceptionWarning: 
Exception ignored in: [0m

[1m[31mE   [0m
[1m[31mE   Traceback (most recent call last):[0m
[1m[31mE File 
"/usr/lib/python3/dist-packages/zmq/sugar/context.py", line 65, in 
__del__[0m

[1m[31mE   warnings.warn([0m
[1m[31mE   ResourceWarning: unclosed context 
[0m


[1m[31m/usr/lib/python3/dist-packages/_pytest/unraisableexception.py[0m:78: 
PytestUnraisableExceptionWarning
 Captured stdout setup 
-

Bug#1011594: Please import new upstream snapshot (currently at 0.0~git20220518.60ebf56)

2022-05-27 Thread Nicholas D Steeves

Hi Joshua,

Joshua Peisach  writes:

> Hi Nicholas,
>
> I just ran a gbp update. One of the tests is failing; since a PR just opened 
> 8 hours ago as of writing, I'm thinking of waiting as the project gets its 
> maintenance
>
[snip test log]
> (syntax-table ... syntax-multiline t))
>  first-mismatch-at 4)))
>FAILED  4/6  kotlin-mode--sample-test (0.044641 sec)

Please import the latest upstream snapshot, run the tests again, then
attempt to build.  If the build fails at the same point, then run the
tests interactively.

  
https://www.gnu.org/software/emacs/manual/html_node/ert/Running-Tests-Interactively.html

If you want to fix it when you find free time, that would be great, but
in any case, this seems like like a bug that upstream should be made
aware of.

For extra points, use the "Control: forwarded -1
paste-the-URL-to-upstream-issue-here" (without quotes, all on one line,
and as the first line) in your next reply to this bug.  This will set up
a watcher that will notify everyone following this bug when the issue is
fixed upstream.

[snip]
> I honestly do not know anything about the kotlin-mode package's code itself, 
> just that it's for Kotlin. I'm willing to still QA and make small fixes if I 
> have to.
>
> I also get accepted into a magnet school, so I will continue to be busy but 
> will get good classes in computer science 
>

:D Congratulations!

Don't forget to apply the following and push your work to salsa:

>> Also, your package doesn't yet declare a team maintainer.  To make it
>> officially team maintained, please apply the following diff:
>>
>> diff --git a/debian/control b/debian/control
>> index 41ade1f..ad10a0b 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -1,7 +1,8 @@
>>  Source: kotlin-mode
>>  Section: editors
>>  Priority: optional
>> -Maintainer: Joshua Peisach 
>> +Maintainer: Debian Emacsen team 
>> +Uploaders: Joshua Peisach 
>>  Build-Depends: debhelper-compat (= 13),
>>   dh-elpa
>>  Standards-Version: 4.6.0
>>
>> Sorry I forgot to ask if you intended for this package to be team-maintained 
>> during the initial sponsorship process.
>>
>> Don't forget to close this bug from the changelog, and please let me know 
>> when you're ready for me to sponsor.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1011963: open-invaders FTBFS on riscv64

2022-05-27 Thread Alan Beadle

Package: open-invaders
Version: 0.3-7
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source
X-Debbugs-Cc: ab.bea...@gmail.com

Dear Maintainer,

open-invaders has a ftbfs issue on riscv64.

Full buildd log here:
https://buildd.debian.org/status/fetch.php?pkg=open-invaders=riscv64=0.3-7=1651106683=0

At compile time it tries to detect the architecture to determine
datatype sizes, and it is missing the check for riscv64, so it
defaults to an incorrect value.

I am including a patch which fixes the problem.
Please consider applying it in the next upload. Thank you.

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

Kernel: Linux 5.18.0-starfive-5.18 (SMP w/2 CPU threads)
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 open-invaders depends on:
ii  libaldmb1   1:0.9.3-6
ii  liballegro4.4   2:4.4.3.1-2
ii  libc6   2.33-7
ii  libdumb11:0.9.3-6
ii  libgcc-s1   12.1.0-2
ii  libstdc++6  12.1.0-2
ii  open-invaders-data  0.3-7

open-invaders recommends no packages.

open-invaders suggests no packages.

-- no debconf information
From: Alan Beadle 
Date: Fri 27 May 2022 09:36:54 PM EDT
Subject: Fix ftbfs on riscv

 Fix failing compile-time detection of dataype size

--- open-invaders-0.3.orig/headers/pmask.h
+++ open-invaders-0.3/headers/pmask.h
@@ -37,7 +37,7 @@ confusing.
 //don't worry about setting it incorrectly
 //you'll get a compile error if you do, not a run-time error
 #if defined(__alpha__) || defined(__ia64__) || (defined(__x86_64__) && 
defined(__LP64__)) || defined(__s390x__) || (defined(__sparc__) && 
defined(__arch64__)) \
-  || defined(__powerpc64__) || defined(__aarch64__) || (defined(__mips64) 
&& defined(__LP64__))
+  || defined(__powerpc64__) || defined(__aarch64__) || (defined(__mips64) 
&& defined(__LP64__)) || (defined(__riscv) && defined(__LP64__))
#define MASK_WORD_BITBITS 6
 #else
#define MASK_WORD_BITBITS 5

Bug#1011078: chromium: arm64 package not available in bullseye-security

2022-05-27 Thread Andres Salomon

I uploaded chromium-102 to bullseye-security, and I don't see armhf 
binary packages. Salvatore, can you please tell me if that build failed?

I'm aware that it failed on i386, but that's for a different, new 
reason (and also failed in sid). I need to deal with that separately.

On Tue, May 17, 2022 at 17:27, Salvatore Bonaccorso  
wrote:

Hi,

On Mon, May 16, 2022 at 03:53:25PM -0400, Andres Salomon wrote:

 clone 1011078 -1
 retitle -1 chromium: i386 and armhf packages FTBFS in bullseye
 tags -1 bullseye ftbfs
 severity -1 serious
 thanks

 On Mon, 16 May 2022 20:33:46 +0200
 Salvatore Bonaccorso mailto:car...@debian.org>> 
wrote:

 [...]
 > Hi Andres,
 >
 > On Mon, May 16, 2022 at 12:36:38PM -0400, Andres Salomon wrote:
 > > On 5/16/22 11:35, Ben Steinberg wrote:
 > >
 > > Security Team, is there a way for me to get access to the logs 
for
 > > chromium's security builds by ssh'ing into a machine? Or some 
other

 > > way for me to view them?
 >
 > The build logs are not public but we can retrieve them. But in 
this

 > case from #debian-buildd:
 >
 > [17:58] < carnil> Hi, can someone double check if chromium/arm64
 > build for bullseye-security is still really in building state?
 > [18:07] < jcristau> carnil: it is not [18:07] < jcristau> guessing
 > the host crashed a few days ago and it got a power cycle
 >
 > Which I did and the package is not back in building state for 
arm64.

 >
 > Regards,
 > Salvatore
 >

 Okay, so arm64 should be building now (thanks Salvatore!). Assuming 
no

 build failures, they should show up in the archive in a day or two.
 Chromium is a slow build. :)

They where built now!

Regards,
Salvatore

Bug#1010977: Fix for ubuntu

2022-05-27 Thread Satadru Pramanik

I've modified the aforementioned patch for ubuntu 22.04 at
https://launchpad.net/~satadru-umich/+archive/ubuntu/updates/+sourcepub/13645941/+listing-archive-extra

The relevant patch as _modified_ for ubuntu 22.04 is attached.
From d17508960a65408dc733cc9f20925768b06289e0 Mon Sep 17 00:00:00 2001
From: Nicolas Schodet 
Date: Sun, 5 Dec 2021 15:24:35 +0100
Subject: [PATCH] Use Py_ssize_t when parsing buffer length, fix #426

From python 3.9 documentation:

> For all # variants of formats (s#, y#, etc.), the macro
> PY_SSIZE_T_CLEAN must be defined before including Python.h. On Python
> 3.9 and older, the type of the length argument is Py_ssize_t if the
> PY_SSIZE_T_CLEAN macro is defined, or int otherwise.

From python 3.8 changes:

> Use of # variants of formats in parsing or building value (e.g.
> PyArg_ParseTuple(), Py_BuildValue(), PyObject_CallFunction(), etc.)
> without PY_SSIZE_T_CLEAN defined raises DeprecationWarning now. It
> will be removed in 3.10 or 4.0. Read Parsing arguments and building
> values for detail. (Contributed by Inada Naoki in bpo-36381.)

Fixes https://github.com/pybluez/pybluez/issues/426
---
 bluez/btmodule.c | 19 ---
 msbt/_msbt.c |  6 --
 2 files changed, 16 insertions(+), 9 deletions(-)

--- a/bluez/btmodule.c
+++ b/bluez/btmodule.c
@@ -17,6 +17,8 @@
 
 */
 
+#define PY_SSIZE_T_CLEAN 1
+#include "Python.h"
 #include "btmodule.h"
 #include "structmember.h"
 
@@ -732,7 +734,7 @@
 int optname;
 int res;
 void *buf;
-int buflen;
+Py_ssize_t buflen;
 int flag;
 
 if (PyArg_ParseTuple(args, "iii:setsockopt", , , )) {
@@ -2001,7 +2003,8 @@
 bt_hci_send_cmd(PyObject *self, PyObject *args)
 {
 PySocketSockObject *socko = NULL;
-int err, plen = 0;
+int err;
+Py_ssize_t plen = 0;
 uint16_t ogf, ocf;
 char *param = NULL;
 int dd = 0;
@@ -2036,6 +2039,7 @@
 int err;
 int to=0;
 char rparam[256];
+Py_ssize_t req_clen;
 struct hci_request req = { 0 };
 int dd = 0;
 
@@ -2044,8 +2048,9 @@
 
 if( !PyArg_ParseTupleAndKeywords(args, kwds, "OHHii|s#i", keywords,
 , , , , , 
-, , ) )
+, _clen, ) )
 return 0;
+req.clen = req_clen;
 
 req.rparam = rparam;
 dd = socko->sock_fd;
@@ -2274,7 +2279,8 @@
 static PyObject * bt_hci_filter_ ## name (PyObject *self, PyObject *args )\
 { \
 char *param; \
-int len, arg; \
+Py_ssize_t len; \
+int arg; \
 if( !PyArg_ParseTuple(args,"s#i", , , ) ) \
 return 0; \
 if( len != sizeof(struct hci_filter) ) { \
@@ -2303,7 +2309,7 @@
 static PyObject * bt_hci_filter_ ## name (PyObject *self, PyObject *args )\
 { \
 char *param; \
-int len; \
+Py_ssize_t len; \
 if( !PyArg_ParseTuple(args,"s#", , ) ) \
 return 0; \
 if( len != sizeof(struct hci_filter) ) { \
@@ -2364,7 +2370,7 @@
 bt_ba2str(PyObject *self, PyObject *args)
 {
 char *data=NULL;
-int len=0;
+Py_ssize_t len=0;
 char ba_str[19] = {0};
 if (!PyArg_ParseTuple(args, "s#", , )) return 0;
 ba2str((bdaddr_t*)data, ba_str);
@@ -2579,7 +2585,7 @@
  *provider = NULL, 
  *description = NULL;
 PyObject *service_classes, *profiles, *protocols;
-int namelen = 0, provlen = 0, desclen = 0;
+Py_ssize_t namelen = 0, provlen = 0, desclen = 0;
 uuid_t svc_uuid = { 0 };
 int i;
 char addrbuf[256] = { 0 };
--- a/msbt/_msbt.c
+++ b/msbt/_msbt.c
@@ -2,6 +2,8 @@
 #define UNICODE
 #endif
 
+#define PY_SSIZE_T_CLEAN 1
+
 #include 
 #include 
 #include 
@@ -155,7 +157,7 @@
 msbt_bind(PyObject *self, PyObject *args)
 {
 wchar_t *addrstr = NULL;
-int addrstrlen = -1;
+Py_ssize_t addrstrlen = -1;
 int sockfd = -1;
 int port = -1;
 char buf[100] = { 0 };
@@ -765,7 +767,7 @@
 WSAESETSERVICEOP op;
 
 char *record = NULL;
-int reclen = -1;
+Py_ssize_t reclen = -1;
 BTH_SET_SERVICE *si = NULL;
 int silen = -1;
 ULONG sdpVersion = BTH_SDP_VERSION;

Bug#1006276: wireguard-go: Please rename bin/wireguard to bin/wireguard-go

2022-05-27 Thread Matthew Gabeler-Lee

Package: wireguard-go
Version: 0.0.20220117-2+b1
Followup-For: Bug #1006276

This probably merits Severity: grave, as the main use for this would be to
work with wg-quick on systems that don't have the kernel module available,
such as ChromeOS Crostini containers, and this package is unusable for that
in its current state & default configuration.

The wg-quick script expects the binary to be called wireguard-go, and
produces confusing errors if neither that binary nor the kernel module is
available.

It _is_ possible to work around this by setting
WG_QUICK_USERSPACE_IMPLEMENTATION=wireguard (in the environment), but that
requires quite a bit of spelunking to find.

Bug#1011961: Installation of bookworm/sid succesfully on Dell Vostro 5490

2022-05-27 Thread Eder Gross Cichelero

Package: installation-reports
Severity: wishlist
X-Debbugs-Cc: hacerf...@gmail.com

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

Boot method: network
Image version: bookworm netinstall snapshot 20-05-2022
Date: 

Machine: Dell Vostro 5490
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:




Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20220520-00:00:55"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux Debian 5.17.0-2-amd64 #1 SMP PREEMPT Debian 5.17.6-1 
(2022-05-14) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:9b61] 
(rev 0c)
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD 
Graphics [8086:9b41] (rev 02)
lspci -knn: DeviceName: To Be Filled by O.E.M.
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon 
E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 
0c)
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 
v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model 
[8086:1911]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation 
Comet Lake Thermal Subsytem [8086:02f9]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:13.0 Serial controller [0700]: Intel Corporation Comet Lake 
Integrated Sensor Solution [8086:02fc]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: Kernel driver in use: intel_ish_ipc
lspci -knn: Kernel modules: intel_ish_ipc
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:02ed]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Device [8086:02ef]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 
9462 [8086:02f0]
lspci -knn: Subsystem: Intel Corporation Device [8086:42a4]
lspci -knn: Kernel modules: iwlwifi
lspci -knn: 00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO 
I2C Host Controller [8086:02e8]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Comet 
Lake Management Engine Interface [8086:02e0]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Comet Lake SATA 
AHCI Controller [8086:02d3]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:02bc] 
(rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:02b0] 
(rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.4 PCI bridge [0604]: Intel Corporation Device [8086:02b4] 
(rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:0284]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:1f.3 Multimedia audio controller [0401]: Intel Corporation 
Device [8086:02c8]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:02a3]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake 
SPI (flash) Controller [8086:02a4]
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 01:00.0 3D controller [0302]: NVIDIA Corporation GP108M [GeForce 
MX230] [10de:1d11] (rev a1)
lspci -knn: Subsystem: Dell Device [1028:0959]
lspci -knn: 02:00.0 Ethernet

Bug#1011666: groff 1.23.0 build dependencies will change

2022-05-27 Thread G. Branden Robinson

At 2022-05-26T13:13:44+0100, Colin Watson wrote:
> On Wed, May 25, 2022 at 07:55:10PM -0500, G. Branden Robinson wrote:
> > I apologize for filing this bug report a bit prematurely, but I've
> > been working on building groff in a bullseye chroot lately to
> > prepare for groff 1.23.0.rc2, and I wanted to document some findings
> > while they were fresh in my mind.
> 
> Thanks for this research!

My pleasure!

> > * Add a dependency on m4.
> > 
> >   o m4 is now required to build.  Any m4 that implements the
> >   features documented in the Version 7 Unix m4(1) man page, and the
> >   `-D` option, should suffice.
> 
> It'll be there anyway due to debhelper → dh-autoreconf → autoconf →
> m4, but I generally approve of directly specifying direct
> (build-)dependencies.

Agreed.  To do otherwise discards important advantages of modularity and
a dependency resolution system that copes with transitive relationships.

> > * Add a dependency on "cups-client | cups-bsd | lpr".
> > 
> >   This is not due to new development.  I confess to being puzzled
> >   why this build dependency isn't already present.  groff's
> >   configure script has for years looked for an installed "lpr"
> >   command, then fallen back to "lp".  Only "groff -l" uses the
> >   detected spooler command, however, and maybe people just don't do
> >   that very often.  I think it is possible that for chroot-built
> >   groff packages in Debian--for those done by the buildds, for
> >   instance--the compiled groff command is silently ignoring the
> >   flag.
> > 
> > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/groff.cpp#n408
> 
> Isn't this handled by passing PSPRINT=lpr to configure, as we do in
> debian/rules?  I generally prefer this approach over
> build-dependencies in cases where the build-dependency would just be
> for path detection and isn't actually used during the build.
> 
> The fact that /usr/share/groff/1.22.4/font/devps/DESC ends with "print
> lpr" suggests that this is working.

You are quite right.  I withdraw that suggestion.  I guess if someone
doesn't want a BSD-style print spooler installed but does have an lp(1)
command and still wants to use 'groff -l', they'll have to edit the DESC
files for the output devices...which aren't conffiles.  Yuck.

Maybe grops(1), grodvi(1), grolbp(1), and grolj4(1) (and gropdf(1)?)
should grow an option to override the "print" directive in their DESC
files.

This is probably not urgent.  The lack of bug reports from people
satisfying the demographic sector I characterized above suggests that
their numbers are few.

> > Please let me know if I can be of assistance.
> 
> Would you like to co-maintain the package?  You're already much more
> active upstream than I am and you've been doing lots of bug
> maintenance; I'd be happy for you to do that with a maintainer hat.

Thank you for this gracious invitation!  I've been looking for a way
back into measurable Debian development activity.  I accept.

> (My only conditions are that I'd like to keep using git-dpm for patch
> maintenance and dgit for uploads.)

Certainly.  I have no revolutionary aspirations there.  Nor, I'm ashamed
to admit, a basic level of competence with git-gpm.  I seem to remember
using dgit and git-buildpackage the last time I uploaded a package,
which was quite some time ago thanks to my upstream slowing WAY down.

I would ask that you to take the decision about the man/mdoc/UTF-8 glyph
contretemps[1] (which boils down to: patch {man,mdoc}.local or not?); as
the upstream instigator of the controversial change, I'm afraid I'm
conflicted out on the issue.

Unless you agree with me but would prefer I wore the blame for it.  3;-)

Thank you again.  It will be strange to have responsibility for a
package in main again.  I might feel duty-bound to cast DPL election
ballots...

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff/2022-05/msg00050.html et seq.

signature.asc
Description: PGP signature

Bug#1011960: "ata_piix.prefer_ms_hyperv=0" prevents successful kdump on some Hyper-V hosts

2022-05-27 Thread Kellen Renshaw

Package: kdump-tools
Version: 1:1.6.10

When the "ata_piix.prefer_ms_hyperv=0"  parameter is present, the
kdump kernel uses the legacy ata_piix IDE driver rather than the
hv_storvsc driver to access the disk. Some Hyper-V hosts do not work
with the ata_piix driver and the VM is unable to write out the vmcore.

"ata_piix.prefer_ms_hyperv=0" was originally added in Oct 2016
(https://salsa.debian.org/debian/kdump-tools/-/commit/4e7997bcd953a9c2a1c473fb20a549d3db8cae44):
at that time this kernel parameter was needed to work around a kdump
issue with old Linux kernels on old Hyper-V (e.g. Windows Server 2012
R2): see 
https://docs.microsoft.com/en-US/troubleshoot/windows-client/virtualization/cant-use-kdump-kexec-linux-virtual-machines-hyper-v.

Proposed solution:
The string "ata_piix.prefer_ms_hyperv=0" should be removed from debian/rules.

Thanks,
Kellen
-- 
Kellen Renshaw
Associate Software Engineer (SEG)
Canonical Ltd.
kellen.rens...@canonical.com
www.canonical.com | www.ubuntu.com

Bug#1010026: qemu-system-x86: fails to start VM with "host" cpu missing features

2022-05-27 Thread Bob Weber

I have this same problem when I upgraded a testing system on May 24.  I also 
installed:


linux-image-5.17.0-2-amd64 from unstable

This is the error from a (all) VM:

vm: error: failed to set MSR 0xc104 to 0x1

kvm: ../../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs: Assertion `ret == 
cpu->kvm_msr_buf->nmsrs' failed.




libvirt-daemon-driver-qemu/testing,unstable,now 8.3.0-1 amd64
qemu-system-x86/testing,unstable,now 1:7.0+dfsg-7 amd64

When I downgraded the kernel to:

 linux-image-5.15.0-3-amd64/now 5.15.15-2 amd64   (my previous kernel)

All OK!

...bob

Bug#1011959: ITP: ros2-osrf-testing-tools-cpp -- OSRF testing tools for ROS 2

2022-05-27 Thread Timo Röhling

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Subject: ITP: ros2-osrf-testing-tools-cpp -- OSRF testing tools for ROS 2
Package: wnpp
Owner: Timo Röhling 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ros2-osrf-testing-tools-cpp
  Version : 1.5.1
  Upstream Author : Open Source Robotics Foundation, Inc
* URL : https://github.com/osrf/osrf_testing_tools_cpp
* License : Apache-2
  Programming Lang: C++
  Description : OSRF testing tools for ROS 2

This package is part of ROS 2, the Robot Operating System.
The Open Source Robotics Foundation testing tools provide a framework for
testing C++ code.

The package will be team-maintained under the umbrella of
Debian Robotics Team 
at https://salsa.debian.org/robotics-team/ros2-osrf-testing-tools-cpp


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmKRUVEACgkQ+C8H+466
LVmP0Qv/WFC248RTy+hOAIWGoAQq4L3g6YjHfh9rAvtqrYeQddGk0WbFxIe0FD0+
EwEt2sUvou7EmhN4zMlLHIM8fj9YeX2I4DMkOCUASc4CBraKfuoyeEOYbfuf6XRs
FrrXsTIExlT5XZr5FjhcSzwrFCgZuX/YaSJGJNHzJwAvMF4zbiJJAaCsIde98t1I
qUj16GZN/YoBaoVnH+ZoXUTyhviNOkXMLGp9pa3giRG8Ew23WNCsHq922B9HLojx
jYpvw+q4ncbqodkFw/m3VMqcGite1iSYfDLMGXov6Et4/xEYsUGyVGFNJ8FTGhUt
Pta1s7/Kv9jH36uowOdZkqSgffagIvcXuw5ILjMiYkKwp6Q4eCW2MEoObiEN4gr8
o9Z7cicOVJ2+UfsaBx4bCMxffX6cEpVama7uXvS+OkKK+ReUOrpcJBjnHJ32SLBN
c76ugYOQnms6HOGisikr/QdxhjSQZpWOJNj+vovLKpe3vH1Hz8tS+gAn/qu7iqZ8
J1z5NzWD
=Xqnp
-END PGP SIGNATURE-

Bug#1011958: /usr/bin/cat: not found

2022-05-27 Thread Jean Louis

Package: courier-webadmin
Version: 1.0.6-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Setting up locally hosted domains over web interface and trying to install 
configuration.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Clicked to install configuration.

   * What was the outcome of this action?

courier 1.0.6 - Installing new configuration

Installing new configuration...

Executing makehosteddomains...
/usr/bin/makedat: 120: /usr/bin/makedat: /usr/bin/cat: not found
find: cat terminated by signal 13

Main Menu 

   * What outcome did you expect instead?

Correct installation



-- System Information:
Debian Release: 10.12
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-9-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages courier-webadmin depends on:
ii  courier-base   1.0.6-1
ii  debconf [debconf-2.0]  1.5.71+deb10u1
ii  libc6  2.28-10+deb10u1
ii  libcgi-pm-perl 4.40-1
ii  nginx-full [httpd] 1.14.2-2+deb10u4

courier-webadmin recommends no packages.

Versions of packages courier-webadmin suggests:
pn  courier-doc  

-- debconf information:
* courier-webadmin/install-cgi: true

Bug#1011957: aideinit fails in amanda-server processing

2022-05-27 Thread Barry Trent

Package: aide
Version: 0.17.3-4+deb11u1
Severity: important
X-Debbugs-Cc: barry.tr...@atcorp.com

Dear Maintainer,

I upgraded two hosts which function as amanda backup servers from buster to 
bullseye and ran into issues running aideinit. It failed:

root@archive:~# aideinit
Overwrite existing /var/lib/aide/aide.db.new [Yn]?
Running aide --init...
  ERROR: /etc/aide/aide.conf.d/31_aide_amanda-server (stdout):15:25: error in 
rule '/etc/amanda/atc-hq/index///2022[0-9]{4}_[0123]\.gz$': invalid double 
slash (line: '!/@@{AMANDA_INDEXDIR}///@@{YEAR4D}[0-9]{4}_[0123]\.gz$ f')
AIDE --init return code 17

I worked around the problem by commenting out a small section of 
31_aide_amanda-server starting at line 65:

  AMANDA_INDEXDIR="$(amgetconf "${CONF}" indexdir)"
  AMANDA_INDEXDIR="${AMANDA_INDEXDIR#/}"
#
# Commented out by bat May 2022 at bullseye upgrade to
# prevent errors
#
#  if [ -n "${AMANDA_INDEXDIR}" ]; then
#printf "@@define AMANDA_INDEXDIR %s\\n" "${AMANDA_INDEXDIR}"
#if [ -f "disklist" ]; then
#  while read -r host dev rest; do
#if echo "${host}" | grep -q '^\\(#.*\\)\\?$'; then continue; fi
#dev="$(echo "${dev}" | sed 's|[/:]|_|g;s|\\"||g')"
#   if ! skip_multiline_dle; then
#printf 
"!/@@{AMANDA_INDEXDIR}/%s/%s/@@{YEAR4D}[0-9]{4}_[0123]\\.gz$ f\\n" "${host}" 
"${dev}"
#printf "/@@{AMANDA_INDEXDIR}/%s/%s$ d VarDir\\n" "${host}" "${dev}"
#   fi
#  done < disklist
#  MULTILINEDLE=0
#fi
#  fi
  AMANDA_CHANGERFILE="$(amgetconf "${CONF}" changerfile)"
  AMANDA_CHANGERDIR="${AMANDA_CHANGERFILE%changer}"

I've included my amanda.conf and disklist from one of the machines in this bug 
report:


*** disklist
zmoby.atcorp.com/   comp-root-tar

symposium.atcorp.com/   comp-root-tar
symposium.atcorp.com/bbbcomp-root-tar
moby.atcorp.com /   comp-root-tar
coelacanth.atcorp.com   /   comp-root-tar
sawfish.atcorp.com  /   comp-root-tar
sawfish.atcorp.com  /varcomp-root-tar


*** amanda.conf
# amanda.conf - sample Amanda configuration file. See amanda.conf(5) for 
# details

org  "ATC-HQ"   # your organization name for reports
mailto   "root" # space separated list of operators at your site
mailer  "/usr/bin/mail"
dumpuser "backup"   # the user to run dumps under

inparallel 4# maximum dumpers that will run in parallel
dumporder "sssS"# specify the priority order of each dumper
#   s -> smallest size
#   S -> biggest size
#   t -> smallest time
#   T -> biggest time
#   b -> smallest bandwitdh
#   B -> biggest bandwitdh
# try "BTBTBTBTBTBT" if you are not holding
# disk constrained

taperalgo first # The algorithm used to choose which dump image to send
# to the taper.
# Possible values: 
# [first|firstfit|largest|largestfit|smallest|last]
# Default: first. 
# first First in - first out.
# firstfit  The first dump image that will fit 
#   on the current tape.
# largest   The largest dump image.
# largestfitThe largest dump image that will fit 
#   on the current tape.
# smallest  The smallest dump image.
# last  Last in - first out.

displayunit "k" # Possible values: "k|m|g|t"
# Default: k. 
# The unit used to print many numbers.
# k=kilo, m=mega, g=giga, t=tera

netusage  8000 Kbps # maximum net bandwidth for Amanda, in KB per sec

dumpcycle 1 weeks   # the number of days in the normal dump cycle
runspercycle 5 # the number of amdump runs in dumpcycle days
# (4 weeks * 5 amdump runs per week -- just weekdays)
tapecycle 80 tapes  # the number of tapes in rotation
# 4 weeks (dumpcycle) times 5 tapes per week (just
# the weekdays) plus a few to handle errors that
# need amflush and so we do not overwrite the full
# backups performed at the beginning of the previous
# cycle

bumpsize 20 Mb  # minimum savings (threshold) to bump level 1 -> 2
bumppercent 20  # minimum savings (threshold) to bump level 1 -> 2
bumpdays 1  # minimum days at each level
bumpmult 4  # threshold =

Bug#1011956: ITP: fonts-nunito -- Well balanced Sans Serif with rounded terminals

2022-05-27 Thread Dr. Tobias Quathamer


Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-fo...@lists.debian.org

* Package name: fonts-nunito
  Version : 0.0~20220527
  Upstream Author : Vernon Adams 
Manvel Shmavonyan 
Jacques Le Bailly

* URL : https://fonts.google.com/specimen/Nunito
* License : SIL Open Font License, Version 1.1
  Programming Lang: None
  Description : Well balanced Sans Serif with rounded
terminals

Nunito is a well balanced sans serif typeface superfamily, with 2 
versions: The project began with Nunito, created by Vernon Adams as a 
rounded terminal sans serif for display typography. Jacques Le Bailly 
extended it to a full set of weights, and an accompanying regular 
non-rounded terminal version, Nunito Sans.



I'll maintain this font within the Debian Fonts Task Force.

Regards,
Tobias


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000110: leafnode: depends on obsolete pcre3 library

2022-05-27 Thread Matthias Andree


Control: tags -1 +upstream +fixed-upstream +confirmed
Control: fixed -1 1.12.0


Please note that I have very recently released leafnode 1.12.0 which now
uses PCRE2 instead of PCRE1.

Also note that there is no longer a .bz2 package, only .xz and .gz.

https://sourceforge.net/projects/leafnode/files/leafnode/1.12.0/

Changelog (high-level, edited):
https://gitlab.com/leafnode-2/leafnode-1/-/raw/1.12.0/NEWS

Changelog (low-level, semiautomated):
https://gitlab.com/leafnode-2/leafnode-1/-/raw/1.12.0/ChangeLog

Bug#987324: rust-hashbrown: missing ahash feature makes building hashlink crate impossible

2022-05-27 Thread Jonas Smedegaard

Package rust-ahash is now in Debian, which should help fix this bug.

 - 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#1011955: RFS: swaykbdd/1.1-1 [ITP] -- Per-window keyboard layout switching daemon for Sway

2022-05-27 Thread Sepi Gair

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: swaykbdd
   Version : 1.1-1
   Upstream Author : Artem Senichev 
 * URL : https://github.com/artemsen/swaykbdd
 * License : Expat
 * Vcs : https://salsa.debian.org/spg/swaykbdd
   Section : x11

The source builds the following binary packages:

  swaykbdd - Per-window keyboard layout switching daemon for Sway

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/swaykbdd/swaykbdd_1.1-1.dsc

Changes for the initial release:

 swaykbdd (1.1-1) unstable; urgency=low
 .
   * Initial release (Closes: #1010976)

Regards,
-- 
  Sepi Gair

Bug#982653: ansible-lint: Switch dependency from ansible to ansible-base?

2022-05-27 Thread Samuel Henrique

> Even after the blocking bug gets addressed I want to consider the
> implications of defaulting to ansible-core, it might be better to
> stick with ansible to cover for the majority of our users while
> allowing them to install ansible-core instead if they want (current
> behavior).

I'm gonna switch the dependency to ansible-core in the next upload,
which is currently pending on python-ansible-compat going through NEW.

-- 
Samuel Henrique

Bug#1009643: Acknowledgement (Puppet: Fails to work with Ruby 3.0)

2022-05-27 Thread Mike Jonkmans

On Wed, 13 Apr 2022 17:31:59 +0200 Sven Mueller  
wrote:
> Just a quick update:
> 
> The problem of this particular one is:
> 
> in puppet/file_system.rb
> 
>   def self.symlink(path, dest, options = {})
> @impl.symlink(assert_path(path), dest, options)
>   end
> 
> Changing this to:
> 
>   def self.symlink(path, dest, **options)
> @impl.symlink(assert_path(path), dest, **options)
>   end
> 
> Works.
> 
> I suspect the fix to https://bugs.debian.org/1006231 to look very similar,
> but there are lots of code locations that use the same "hash as vararg"
> mechanism.

Using 'recurse => remote',
whilst the source directory at the puppetmaster contains symlinks,
i got the same errors:
  Error: Could not set 'link' on ensure: wrong number of arguments (given 3,
expected 2)

I could solve these using the same method as above.

In /usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb
replace

  def symlink(path, dest, options = {})
FileUtils.symlink(path, dest, options)
  end

with:

  def symlink(path, dest, **options)
FileUtils.symlink(path, dest, **options)
  end

After applying both these changes, i saw no errors anymore.

Thanks for putting me on the right track.

--
Sent from Linux.
Regards, Mike Jonkmans

Bug#1011954: CVE-2022-1586 CVE-2022-1587

2022-05-27 Thread Matthew Vernon


Hi,

Would you like me to prepare an upload for these, or are you working on 
this?


[sorry, it's not clear from the bug report]

Thanks,

Matthew

Bug#1011954: CVE-2022-1586 CVE-2022-1587

2022-05-27 Thread Moritz Muehlenhoff

Source: pcre2
Version: 10.36-2
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2022-1587
https://github.com/PCRE2Project/pcre2/commit/03654e751e7f0700693526b67dfcadda6b42c9d0

CVE-2022-1586
https://github.com/PCRE2Project/pcre2/commit/50a51cb7e67268e6ad417eb07c9de9bfea5cc55a
https://github.com/PCRE2Project/pcre2/commit/d4fa336fbcc388f89095b184ba6d99422cfc676c

Cheers,
Moritz

Bug#1011505: transition: gpgme1.0

2022-05-27 Thread Sebastian Ramacher

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-gpgme1.0.html

On 2022-05-23 23:10:21 -0400, Daniel Kahn Gillmor wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: d...@fifthhorseman.net, delta...@debian.org
> 
> The only packages that need to be rebuilt against this soname bump are
> part of KDE, specifically these binary packages:
> 
>  accountwizard
>  kdepim-addons
>  kget
>  kleopatra
>  kmail
>  libkf5libkleo5
>  libkf5mailcommon5abi2
>  libkf5messagecomposer5abi1
>  libkf5messagecore5abi1
>  libkf5messageviewer5abi1
>  libkf5mimetreeparser5abi1
> 
> These come from the following sources:
> 
>  kdepim-addons
>  kf5-messagelib
>  kget
>  kleopatra
>  kmail
>  kmail-account-wizard
>  libkf5libkleo
>  libkf5mailcommon
> 
> Patrick Franz (in Cc) from the KDE team tested them and reported that
> they build cleanly with an NMU (see attached message).
> 
> Release team, please ACK so i can proceed with the upload to unstable.

Please go ahead

Cheers

> 
> Regards,
> 
> --dkg
> 
> 
> Ben file:
> 
> title = "gpgme1.0";
> is_affected = .depends ~ "libqgpgme7" | .depends ~ "libqgpgme15";
> is_good = .depends ~ "libqgpgme15";
> is_bad = .depends ~ "libqgpgme7";

> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=1e100.net; s=20210112;
> h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to
>  :references:mime-version:content-transfer-encoding;
> bh=oeVrgfF5zWr7ctjic7dVLveRG26Sy0vaKyFu8vQ1Xpo=;
> b=g4a5KhJl1Z86Zo5WyqUkuDiZzLvD2ag98UswCzkP/nG8i0tFIglylY0HD1SVg7N+2y
>  r+vYb3xuRohGxwSPPZTBWEERpIzMXVwg0qVHdwjvpHWLV21T2OmEwB1r3iLcYHURIOZX
>  0aIcaZwSFn7fXBhjYdXRllAi4UzBT87wgo5aTNbrgveYkmuETd2fWnlWt+rdXUnLZtWb
>  yNFjOePrrp+2yAQl5vVLno5ljNwvoK3wkJNtPNqX3opWRJRvTKMod2tHXNa1lCVZ86rn
>  LXGtxd7EWsVYfTPfJEHFac2ApJpF8PDR1qII9qxXVsKzMrUG0g1RmfCg+D4fCPWgSPlU
>  VTuw==
> X-Gm-Message-State: AOAM5316WPFtNxI4QQZw4IxqiNBw7n9VbWHLp6yREKH7KwRzmsmJgmWp
>   gJPDL3BGOlXPpHuJIBOiJQc=
> X-Google-Smtp-Source: 
> ABdhPJxtTiLSLkyyEU6xbiBlvNXUhN9FH1qGtHs3aTU30OPqODvCX44FW7qW+5V2/w40TEvQxue0Tw==
> X-Received: by 2002:a2e:a5ca:0:b0:253:c604:647c with SMTP id 
> n10-20020a2ea5ca00b00253c604647cmr11071204ljp.403.1653237143884;
> Sun, 22 May 2022 09:32:23 -0700 (PDT)
> Received: from delta-one.localnet (217-210-33-15-no2104.tbcn.telia.com. 
> [217.210.33.15])
> by smtp.gmail.com with ESMTPSA id 
> bi23-20020a05651c231700b00253dfbe2522sm1080181ljb.100.2022.05.22.09.32.22
> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
> Sun, 22 May 2022 09:32:23 -0700 (PDT)
> From: Patrick Franz 
> To: debian-qt-...@lists.debian.org, Daniel Kahn Gillmor 
> 
> Subject: Re: rebuilding against libqgpgme-dev (soname bump from libqgpgme7 to 
> libqgpgme15)
> Date: Sun, 22 May 2022 18:32:21 +0200
> Message-ID: <1831765.tdWV9SEqCh@delta-one>
> In-Reply-To: <87zgjbficl@fifthhorseman.net>
> References: <87zgjbficl@fifthhorseman.net>
> MIME-Version: 1.0
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; charset="UTF-8"
> Received-SPF: pass (srs.pair.com ... _spfmailwash.pair.com: 209.68.5.116 is 
> authorized to use 'SRS0=GHde=V6=gmail.com=deltaone.deb...@srs.pair.com' in 
> 'mfrom' identity (mechanism 'ip4:209.68.0.0/18' matched)) 
> receiver=mailwash52.pair.com; identity=mailfrom; 
> envelope-from="SRS0=GHde=V6=gmail.com=deltaone.deb...@srs.pair.com"; 
> helo=itihasa.pair.com; client-ip=209.68.5.116
> X-Virus-Check-By: mailwash52.pair.com
> X-Scanned-By: mailmunge 3.07 on 66.39.2.52
> Delivered-To: d...@fifthhorseman.net
> X-Scanned-By: mailmunge 3.07 on 66.39.2.52
> Delivered-To: daniel_gill...@fifthhorseman.net
> X-Envelope-To: daniel_gill...@fifthhorseman.net
> 
> Hi Daniel,
> 
> Am Samstag, 21. Mai 2022, 09:35:54 CEST schrieb Daniel Kahn Gillmor:
> > I think the following 8 source packages will need a rebuild:
> >=20
> > kdepim-addons
> > kf5-messagelib
> > kget
> > kleopatra
> > kmail
> > kmail-account-wizard
> > libkf5libkleo
> > libkf5mailcommon
> >=20
> > Let me know what you think is a good plan here,
> 
> I rebuilt those packages against gpgme 1.17 in experimental and all of=20
> them built successfully without the need of adjusting anything.
> 
> So I'd suggest you simply request a transition and state that all these=20
> packages build against gpgme 1.17 and only need NMUs.
> 
> 
> =2D-=20
> Med v=C3=A4nliga h=C3=A4lsningar
> 
> Patrick Franz
> 
> 


-- 
Sebastian Ramacher

Bug#1011630: transition: jimtcl

2022-05-27 Thread Sebastian Ramacher

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-jimtcl.html
Control: tags -1 confirmed

On 2022-05-25 22:17:38 +0800, Bo YU wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Please provide me permission to upload Jimtcl to sid. I have
> verified the build of the reverse dependencies and haven't run into
> issues.

Please go ahead

Cheers

> 
> If you need any other information, please let me know.
> Ben file:
> 
> title = "jimtcl";
> is_affected = .depends ~ "libjim0.79" | .depends ~ "libjim0.81";
> is_good = .depends ~ "libjim0.81";
> is_bad = .depends ~ "libjim0.79";
> 
> -- 
> Best Regards,
> 



-- 
Sebastian Ramacher

Bug#1011935: (no subject)

2022-05-27 Thread tsteven4

Why do many qt6 packages have a dependency on qtchooser if you are not 
supporting Qt6 with qtchooser?


  qt6-webengine-dev-tools
  qt6-l10n-tools
  qt6-documentation-tools
  qt6-declarative-dev-tools
  qt6-base-dev-tools
  qmlscene-qt6
  qml-qt6
  assistant-qt6
  linguist-qt6
  designer-qt6

Bug#1010994: transition: trace-cmd

2022-05-27 Thread Sudip Mukherjee

Hi Sebastian,

On Sun, May 15, 2022 at 11:48:00AM +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2022-05-14 22:09:10 +0100, Sudip Mukherjee wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: sudipm.mukher...@gmail.com
> > 
> > Hi,
> > 
> > Small transition with only one affected package: kernelshark.
> > It builds fine and works properly with the trace-cmd/libtracecmd1
> > from experimental.
> 
> Please go ahead

This has been uploaded and transition to testing also complete.

Thanks for your help.

--
Regards
Sudip

Bug#976118: Bug fixed

2022-05-27 Thread Philippe SWARTVAGHER


Control: fixed -1 1.6.2-1

Hello,

> The latest upstream tag is v1.6.2 which is available in Testing/Unstable.
> Is the issue still present or is it fixed with that version?

I just encountered the same problem with a Debian bullseye. When using
the package from testing, the bug doesn't appear anymore.

Could you consider backporting the package currently in testing into
bullseye-backports?

Philippe.

Bug#961021: ITP: python-easysnmp -- A blazingly fast and Pythonic SNMP library based on the official Net-SNMP bindings

2022-05-27 Thread Bernhard Schmidt


Control: tags -1 pending

Hi,


Note that the upstream project is looking for a new maintainer and
appears to be quite dormant. There are issues with Python 3.7+, but a pull
request is available and has been verified to work. I don't intend to
upload to Debian until these issues have been resolved.

SNMP projects seem to be hard to maintain. It's a fiddly protocol for sure.

Anyway, if you need any help with the net-snmp library or just someone
to bounce ideas off, I'm here. I don't want to maintain easysnmp but
willing to help when it's needed.

Hopefully, the upstream issues get sorted! Until we have more snmp
libraries than IRC clients I say more the merrier!


Pretty exactly two years later upstream has resumed 
development/maintainership and merged a couple of fixes, among others it 
is not necessary anymore to carry a 10+ patches patchset to support 
Python 3.7+


Also two years later I still haven't found a better pythonic SNMP module 
than this, so I'm going to polish it and upload it within the next weeks.


Bernhard

Bug#1011635: Diff between {,sticky} Debian binary package fails

2022-05-27 Thread Chris Lamb

tags 1011635 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/c6153ea88374864082f0a71c45a17887dd18a199

Thanks for the helpful report.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1011953: thinkfan FTBFS on riscv

2022-05-27 Thread Alan Beadle

Package: thinkfan
Version: 1.3.1-1
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: ab.bea...@gmail.com

Dear Maintainer,

The thinkfan package has a ftbfs issue on riscv64.

Full buildd log here: 
https://buildd.debian.org/status/fetch.php?pkg=thinkfan=riscv64=1.3.1-1=1649865911=0

I am including a patch which fixes the problem. Please consider applying it in 
the next upload. Thank you.

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

Kernel: Linux 5.18.0-starfive-5.18 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thinkfan depends on:
ii  init-system-helpers  1.63
ii  libatasmart4 0.19-5
ii  libatomic1   12.1.0-2
ii  libc62.33-7
ii  libgcc-s112.1.0-2
ii  libstdc++6   12.1.0-2
ii  libyaml-cpp0.7   0.7.0+dfsg-8

thinkfan recommends no packages.

thinkfan suggests no packages.

-- no debconf information
fix ftbfs on riscv64

Alan Beadle 
--- thinkfan-1.3.1.orig/CMakeLists.txt
+++ thinkfan-1.3.1/CMakeLists.txt
@@ -8,6 +8,8 @@ cmake_minimum_required(VERSION 3.0)
 # Generate absolute paths or something
 cmake_policy(SET CMP0015 NEW)
 
+set(THREADS_PREFER_PTHREAD_FLAG ON)
+
 find_package(PkgConfig)
 find_package(Threads)
 pkg_check_modules(SYSTEMD "systemd")

Bug#1011952: mesa: FTBFS on kfreebsd

2022-05-27 Thread Laurent Bigonville

Source: mesa
Version: 22.1.0~rc5-1
Severity: important
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081

Hello,

mesa currently FTBFS on kfreebsd

The attached patch seems to fix this

The patch has been propsed upstream

Could you please apply that patch?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -u mesa-22.1.0/debian/patches/series mesa-22.1.0/debian/patches/series
--- mesa-22.1.0/debian/patches/series
+++ mesa-22.1.0/debian/patches/series
@@ -2,3 +2,4 @@
 path_max.diff
 src_glx_dri_common.h.diff
 revert-enabling-tlsdesc-support.diff
+fix_ftbfs_kfreebsd.patch
diff -u mesa-22.1.0/debian/rules mesa-22.1.0/debian/rules
--- mesa-22.1.0/debian/rules
+++ mesa-22.1.0/debian/rules
@@ -56,7 +56,6 @@
 
confflags_DIRECT_RENDERING = -Dglx-direct=true
confflags_GBM = -Dgbm=enabled
-   confflags_GALLIUM += -Dgallium-extra-hud=true
confflags_GALLIUM += -Dgallium-vdpau=enabled
confflags_GALLIUM += -Dlmsensors=enabled
 
@@ -68,6 +67,7 @@
 
   ifeq ($(DEB_HOST_ARCH_OS), linux)
confflags_DRI3 = -Ddri3=enabled
+   confflags_GALLIUM += -Dgallium-extra-hud=true
# Gallium drivers which require kernel support, not yet ported to 
non-Linux
GALLIUM_DRIVERS += nouveau virgl
 
only in patch2:
unchanged:
--- mesa-22.1.0.orig/debian/patches/fix_ftbfs_kfreebsd.patch
+++ mesa-22.1.0/debian/patches/fix_ftbfs_kfreebsd.patch
@@ -0,0 +1,53 @@
+From 809fc7ef474a6010f2eafc853d8d1322f97a539c Mon Sep 17 00:00:00 2001
+From: Laurent Bigonville 
+Date: Thu, 17 Feb 2022 14:49:27 +0100
+Subject: [PATCH] Try to fix FTBFS on kfreebsd architecture
+
+Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081
+---
+ include/drm-uapi/sync_file.h | 1 +
+ src/util/u_qsort.h   | 2 +-
+ src/util/u_thread.h  | 2 +-
+ 3 files changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/include/drm-uapi/sync_file.h b/include/drm-uapi/sync_file.h
+index 11d86db53e4..7ede34e12de 100644
+--- a/include/drm-uapi/sync_file.h
 b/include/drm-uapi/sync_file.h
+@@ -19,6 +19,7 @@
+ 
+ #else /* One of the BSDs */
+ 
++#include 
+ #include 
+ #include 
+ 
+diff --git a/src/util/u_qsort.h b/src/util/u_qsort.h
+index 34fff94dba4..ac3dfebaa6b 100644
+--- a/src/util/u_qsort.h
 b/src/util/u_qsort.h
+@@ -57,7 +57,7 @@ util_qsort_r(void *base, size_t nmemb, size_t size,
+  void *arg)
+ {
+ #if HAVE_QSORT_R
+-#  if DETECT_OS_APPLE || DETECT_OS_BSD
++#  if (DETECT_OS_APPLE || DETECT_OS_BSD) && ! defined(__GLIBC__)
+/* BSD/macOS qsort_r takes "arg" before the comparison function and it
+ * pass the "arg" before the elements.
+ */
+diff --git a/src/util/u_thread.h b/src/util/u_thread.h
+index d06ff6beddb..70c02bf938c 100644
+--- a/src/util/u_thread.h
 b/src/util/u_thread.h
+@@ -125,7 +125,7 @@ static inline thrd_t u_thread_create(int (*routine)(void 
*), void *param)
+ static inline void u_thread_setname( const char *name )
+ {
+ #if defined(HAVE_PTHREAD)
+-#if DETECT_OS_LINUX || DETECT_OS_CYGWIN || DETECT_OS_SOLARIS
++#if DETECT_OS_LINUX || DETECT_OS_CYGWIN || DETECT_OS_SOLARIS || 
defined(__GLIBC__)
+int ret = pthread_setname_np(pthread_self(), name);
+if (ret == ERANGE) {
+   char buf[16];
+-- 
+GitLab
+

Bug#996594: bug #996594

2022-05-27 Thread b. i. blonchk

This error also affected me for Ardour AND guitarix, and I just had to
uninstall naspro-bridges to solve it

Kind regards

blonchk

Bug#1011948: plocate: updatedb error with CIFS

2022-05-27 Thread Steinar H. Gunderson

On Fri, May 27, 2022 at 04:35:27PM +0200, rollopack wrote:
> close(50)   = 0
> newfstatat(51, "", 0x7ffd0628d900, AT_EMPTY_PATH) = -1 EACCES (Permesso 
> negato)

So basically, there is a directory that we can open, but not stat
once open? That's a bit weird, but I guess the server can deny pretty much
anything it would like.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1011646: libthrust: autopkgtest: please be more gentle on ci.d.n infrastructure

2022-05-27 Thread Paul Gevers


Hi

On 27-05-2022 17:17, Andreas Beckmann wrote:
Hmm, a first test for -4 on amd64 has already finished (so the 
blacklisting did not work?),


I triggered that.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011646: libthrust: autopkgtest: please be more gentle on ci.d.n infrastructure

2022-05-27 Thread Andreas Beckmann


On 25/05/2022 22.54, Paul Gevers wrote:

Please consider making your test suite much less intense. Looking at


Upstream comes with a rather exhaustive test matrix ...
I'm now running a smaller subset of it and in a more fine grained way to 
make it easier to decide which parts to skip as well.
The OpenMP parts were even slower than on my machine ... so far I hadn't 
seen invididual tests time out in ctest. Synchronizing between 56 
threads seems to be a hard job ;-)



On arm64 and ppc64el your tests seem to tmpfail. I am *suspecting*
that is because they run out of diskspace. All our arm64 and ppc64el


With the more fine grained testing I've tried to free disk space at the 
end of the smaller test chinks, not sure it that was successful.



For now, I have put libthrust on our rejectlist for those three
architectures and I just flushed the amd64 queue because there were


Once the backlog is cleared, it would be nice to reenable libthrust, 
probably starting with amd64, to see whether I managed to get it down to 
an acceptable size.


Hmm, a first test for -4 on amd64 has already finished (so the 
blacklisting did not work?), mostly telling me 'SKIP test name may not 
contain / character' (that should be checked by lintian). Preparing -5 
now ...


The tests are temporarily all on flaky to avoid introducing regressions 
while testing the tests ;-)


The tests are all superficial, since we can't run (but only compile) the 
most relevant part of the testsuite: the cuda tests.


Andreas

PS: src:cub needs to be trimmed down as well, that has done some 12 h 
runs on ci-worker13, too ... not touching that before we have resolved 
src:libthrust

Bug#1011951: python-gevent: Build-Depends: libpython3.9-testsuite

2022-05-27 Thread Graham Inggs

Source: python-gevent
Version: 21.8.0-1
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

Hi Maintainer

python-gevent has a hardcoded build-dependency on
libpython3.9-testsuite and will
FTBFS once Python 3.9 is removed from the archive.

I'm marking this bug important for now, and will raise severity once
the Python 3.9 removal transition is in progress.

Regards
Graham

Bug#1011950: pympress: Build-Depends: python3.9-doc

2022-05-27 Thread Graham Inggs

Source: pympress
Version: 1.7.1-1
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

Hi Maintainer

pympress has a hardcoded build-dependency on python3.9-doc and will
FTBFS once Python 3.9 is removed from the archive.

Is it possible to change this to the generic python3-doc package from
src:python3-defaults?

Regards
Graham

Bug#1011948: plocate: updatedb error with CIFS

2022-05-27 Thread rollopack

Package: plocate
Version: 1.1.15-2
Followup-For: Bug #1011948
X-Debbugs-Cc: rollop...@gmail.com

strace output:

getdents64(27, 0x55b372dc1a10 /* 0 entries */, 1048576) = 0
close(27)   = 0
close(7)= 0
close(49)   = 0
newfstatat(50, "", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_EMPTY_PATH) = 0
fcntl(50, F_GETFL)  = 0x58000 (flags
O_RDONLY|O_LARGEFILE|O_NOATIME|O_DIRECTORY)
fcntl(50, F_SETFD, FD_CLOEXEC)  = 0
getdents64(50, 0x55b372dc1a10 /* 3 entries */, 1048576) = 88
write(1, "/mnt/server/gate svil/Acquedotto"..., 37/mnt/server/gate
svil/Acquedotto.zip
) = 37
getdents64(50, 0x55b372dc1a10 /* 0 entries */, 1048576) = 0
close(50)   = 0
newfstatat(51, "", 0x7ffd0628d900, AT_EMPTY_PATH) = -1 EACCES (Permesso negato)
write(2, "fdopendir: Permission denied\n", 29fdopendir: Permission denied
) = 29
write(5,
"\321y\217\344\263\t\221\4/\354\300\223b\306!`\23@Q2K\340\273N\236\307\226F\3\251\325\223"...,
2846) = 2846
exit_group(1)   = ?
+++ exited with 1 +++


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

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

Versions of packages plocate depends on:
ii  libc6   2.34-0experimental2
ii  libgcc-s1   12.1.0-2
ii  libstdc++6  12.1.0-2
ii  liburing2   2.1-2
ii  libzstd11.5.2+dfsg-1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv250.4-1

-- Configuration Files:
/etc/updatedb.conf changed [not included]

-- no debconf information

Bug#1011949: linux-libc-dev: missing drm/ headers

2022-05-27 Thread Rémi Denis-Courmont

Package: linux-libc-dev
Version: 5.18-1~exp1
Severity: normal

Dear Maintainer,

The drm/ user-space API headers are missing in linux-libc-dev (at least
on x86-64). They are present in the cross-compilation packages though,
and FWIW, they are also shipped in Ubuntu's versions of linux-libc-dev.

Br,

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

Kernel: Linux 5.17.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fi_FI.UTF-8), LANGUAGE=fr:en_GB:fi
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#1010883: dkms breaks nvidia-graphics-drivers autopkgtest on arm64: unmet dependencies

2022-05-27 Thread Andreas Beckmann


On 27/05/2022 10.59, Paul Gevers wrote:

My guess is that apt pinning comes into play here, installing


That aligns with my suspicion that it's related to the mixing of 
unstable and testing.


Uploaded a first attempt on the fix. Works for me, let's see how ci.d.o 
likes it. There are probably still corner cases to be handled ...


Andreas

Bug#1011948: plocate: updatedb error with CIFS

2022-05-27 Thread rollopack

Package: plocate
Version: 1.1.15-2
Severity: normal
X-Debbugs-Cc: rollop...@gmail.com

Dear Maintainer,
removing CIFS from the list from the PRUNEFS returns the "fdopendir:
Permission denied" at the end of the scan and the database is not updated.
Putting CIFS back into the list the update is successful and the plocate.db
file is updated.


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

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

Versions of packages plocate depends on:
ii  libc6   2.34-0experimental2
ii  libgcc-s1   12.1.0-2
ii  libstdc++6  12.1.0-2
ii  liburing2   2.1-2
ii  libzstd11.5.2+dfsg-1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv250.4-1

-- Configuration Files:
/etc/updatedb.conf changed:
PRUNE_BIND_MOUNTS="yes"
PRUNEPATHS="/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph 
/home/.ecryptfs /var/lib/schroot /mnt/nas /mnt/nas_cifs"
PRUNEFS="NFS afs autofs binfmt_misc ceph cgroup cgroup2 coda configfs curlftpfs 
debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fuse.cryfs fuse.encfs 
fuse.glusterfs fuse.gvfsd-fuse fuse.mfs fuse.rclone fuse.rozofs fuse.sshfs 
fusectl fusesmb hugetlbfs iso9660 lustre lustre_lite mfs mqueue ncpfs nfs nfs4 
ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs sysfs tmpfs tracefs 
udev udf usbfs"


-- no debconf information

Bug#1010663: RFS: strawberry/1.0.4-1 [ITP] -- Audio player and music collection organizer

2022-05-27 Thread Peter


Regarding the latest Salsa CI fails;

Its not clear to me why changing the copyright file causes crossbuild & 
reprotest to fail,
https://salsa.debian.org/debian/strawberry/-/pipelines/382967

when they both passed on the first upload   ??
https://salsa.debian.org/debian/strawberry/-/pipelines/382861


reprotest passes when I run it locally

===
Reproduction successful
===
No differences in ./../*.deb
359c55b631de43ae319787bbacfb65fccafee48be9799b402505e08301fbb763 
./../strawberry-dbgsym_1.0.4-1_amd64.deb
3483b1d23b0d0f6ede8f1219c132a3de45afc9a649ef1712d09cce7387f6ad51 
./../strawberry_1.0.4-1_amd64.deb



Cheers,
Peter

Bug#995636: transition: openssl

2022-05-27 Thread Kurt Roeckx

On Thu, May 26, 2022 at 06:26:57PM +0200, Sebastian Ramacher wrote:
> 
> That leaves #1011051. What's your view on that bug?

So my understanding is that 1.1.1 doesn't understand the new
configuration file and tries to load an engine (instead of a
provider).

We could ship a file that's comptabile with 1.1.1. That would make it
a little bit harder to load some providers by default, but maybe that's
something you want to do per application anyway.

Kurt

Bug#1011947: undionly.kpxe doesn't handle IPv6 NDP

2022-05-27 Thread Marc Haber

Package: ipxe
Version: 1.0.0+git-20190125.36a4c85-5.1
Severity: normal
Tags: ipv6

Hi,

My infrastructure has IPv6 and is announcing IPv6-only DNS servers over
Router Announcements in addition to having regular DHCPv4. The Router
Announcements have the Managed Bit set, but the DHCPv6 server doesn't
answer if there is no host-specific data in the DHCP configuration.

I have a certain machine that doesn't boot in this environment. A trace
shows the following.

- machine is turned on, link up
- Intel Boot Agent does DHCPv4, gets next-server and boot file name
  undionly.kpxe
- Intel Boot Agent does tftp, downloading undionly.kpxe.
- undionly.kpxe does DHCPv4, gets next server and URL to an ipxe menu.
- undionly.kpxe does Router Solicitation and receives a Router
  Announcement
- undionly.kpxe tries to reach a DHCPv6 server multiple times, no reply
- I do NOT see the system doing IPv6 DAD, nor do I see the system
  joining any multicast groups. According to RFC4861 7.2.1, the node
  MUST join at least the all-nodes multicast group and the
  solicited-node multicast group belonging to the MAC address of the
  Interface.
- undionly.kpxe sends out an  query for the host name part of the
  URL via IPv6 to one of the name servers given in the Router
  Announcements (the DNS server is on a different network, so the packet
  gets actually sent to the default gateway).
- The default gateway sends a neighbor solicitation for the IPv6 address
  that the DNS query was sent from, using the correct solicited-node
  multicast IPv6 and MAC addresses
- the system doesn't react to this neighbor solicitation
- the system re-sends the DNS query and ignores the neighbor
  solicitation again.
- this repeats a couple of times until ipxe gives up

The IPXE feature list given on the console while running also does not
contain any reference to IPv6 being enabled.

What kind of confuses me is that a Thinkpad X121e connected to the same
switch port with the same cable boots off this network just fine. It
doesn't join the multicast groups either, but it looks like it is able
to make sense out of the neighbor solicitation, responds properly, gets
its DNS queries answered and is able to continue the boot process
despite the RFC violation of not joining those multicast groups.

Turning off the RDNSS option in the router announcements made the system
use the IPv4 name servers from the DHCPv4 assignment, which eventuelly
allowed the machine to boot.

So I think we're having three bug reports here:

- the IPv6 RFC violation of not doing IPv6 DAD and not joining required
  multicast groups
- not being able to properly receive the multicasted neighbor
  solicitation of the gateway on one particular type of hardware
- not trying one of the other DNS servers after the queries to the first
  one were unsuccessful

I am not reporting this upstream since upstream has advanced
considerably since this package was uploaded to Debian. Do you need help
packaging a current version of ipxe?

Can I do anything else to help with this bug report and/or ipxe?

Greetings
Marc

Bug#1010242: RFS: opengnb/1.2.8.7-1 [ITP] -- via P2P to setup de-centralized layer3 network VPN

2022-05-27 Thread 肖盛文


Hi Bastian,

在 2022/5/27 16:55, Bastian Germann 写道:

Hi Xiao,

Please remove the debian/links file. We do not need the README in /etc.

Ok, removed.


What about those public gnb index nodes? Is the list published 
somewhere except for this package?


These public gnb index nodes is published in upstream github repo,

https://github.com/gnbdev/opengnb/blob/master/README_EN.md

The IP  of public index nodes perhaps will change in the further, the 
upstream author also will update them.


If the upstream new version release and public index nodes update, I'll 
also update them when I do new package.


Let I added some notes for it in debian/etc/opengnb/default/address.conf

# These public gnb index nodes may change, please visit
# https://github.com/gnbdev/opengnb/blob/master/README_EN.md to get the 
newest

# public gnb index nodes infos.
# OpenGNB will take affect at lease one of these nodes exist when you don't
# setup your own public index node.

Is this OK?


Uploaded the package to mentors.d.n

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


Thanks!

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011942: [pkg-php-pear] Bug#1011942: bullseye-pu: package php-guzzlehttp-psr7/1.7.0-1+deb11u1

2022-05-27 Thread David Prévot


Hi,

Le 27/05/2022 à 14:19, David Prévot a écrit :
[…]

   [x] attach debdiff against the package in (old)stable


lalaladiff --git a/debian/changelog b/debian/changelog
index f3eb5e4..8635876 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+php-guzzlehttp-psr7 (1.7.0-1+deb11u1) bullseye; urgency=medium
+
+  * Track Bullseye
+  * Backport fixes for improper header parsing [CVE-2022-24775]
+(Closes: #1008236)
+
+ -- David Prévot   Fri, 27 May 2022 13:29:47 +0200
+
 php-guzzlehttp-psr7 (1.7.0-1) unstable; urgency=medium
 
   * Revert "Bundle php-getallheaders being processed in NEW"
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 915477f..aed5a6c 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,7 +1,7 @@
 [DEFAULT]
 pristine-tar = True
 pristine-tar-commit = True
-debian-branch = debian/latest
+debian-branch = debian/bullseye
 
 ## Once --filter support gets added to gbp import-ref, we should be able
 ## to simplify the workflow and ignore the upstream branch.
diff --git a/debian/patches/0002-Release-1.8.4-486.patch b/debian/patches/0002-Release-1.8.4-486.patch
new file mode 100644
index 000..1d08392
--- /dev/null
+++ b/debian/patches/0002-Release-1.8.4-486.patch
@@ -0,0 +1,188 @@
+From: Graham Campbell 
+Date: Sun, 20 Mar 2022 13:44:44 +
+Subject: Release 1.8.4 (#486)
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Co-authored-by: Tim Düsterhus 
+
+Origin: backport, https://github.com/guzzle/psr7/commit/902db15a551a4a415e732b622282e21ce1b508b4
+---
+ src/MessageTrait.php  | 66 +++
+ tests/RequestTest.php | 50 ++
+ 2 files changed, 111 insertions(+), 5 deletions(-)
+
+diff --git a/src/MessageTrait.php b/src/MessageTrait.php
+index 99203bb..459b104 100644
+--- a/src/MessageTrait.php
 b/src/MessageTrait.php
+@@ -157,17 +157,22 @@ trait MessageTrait
+ }
+ }
+ 
++/**
++ * @param mixed $value
++ *
++ * @return string[]
++ */
+ private function normalizeHeaderValue($value)
+ {
+ if (!is_array($value)) {
+-return $this->trimHeaderValues([$value]);
++return $this->trimAndValidateHeaderValues([$value]);
+ }
+ 
+ if (count($value) === 0) {
+ throw new \InvalidArgumentException('Header value can not be an empty array.');
+ }
+ 
+-return $this->trimHeaderValues($value);
++return $this->trimAndValidateHeaderValues($value);
+ }
+ 
+ /**
+@@ -178,13 +183,13 @@ trait MessageTrait
+  * header-field = field-name ":" OWS field-value OWS
+  * OWS  = *( SP / HTAB )
+  *
+- * @param string[] $values Header values
++ * @param mixed[] $values Header values
+  *
+  * @return string[] Trimmed header values
+  *
+  * @see https://tools.ietf.org/html/rfc7230#section-3.2.4
+  */
+-private function trimHeaderValues(array $values)
++private function trimAndValidateHeaderValues(array $values)
+ {
+ return array_map(function ($value) {
+ if (!is_scalar($value) && null !== $value) {
+@@ -194,10 +199,20 @@ trait MessageTrait
+ ));
+ }
+ 
+-return trim((string) $value, " \t");
++$trimmed = trim((string) $value, " \t");
++$this->assertValue($trimmed);
++
++return $trimmed;
+ }, array_values($values));
+ }
+ 
++/**
++ * @see https://tools.ietf.org/html/rfc7230#section-3.2
++ *
++ * @param mixed $header
++ *
++ * @return void
++ */
+ private function assertHeader($header)
+ {
+ if (!is_string($header)) {
+@@ -210,5 +225,46 @@ trait MessageTrait
+ if ($header === '') {
+ throw new \InvalidArgumentException('Header name can not be empty.');
+ }
++
++if (! preg_match('/^[a-zA-Z0-9\'`#$%&*+.^_|~!-]+$/', $header)) {
++throw new \InvalidArgumentException(
++sprintf(
++'"%s" is not valid header name',
++$header
++)
++);
++}
++}
++
++/**
++ * @param string $value
++ *
++ * @return void
++ *
++ * @see https://tools.ietf.org/html/rfc7230#section-3.2
++ *
++ * field-value= *( field-content / obs-fold )
++ * field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
++ * field-vchar= VCHAR / obs-text
++ * VCHAR  = %x21-7E
++ * obs-text   = %x80-FF
++ * obs-fold   = CRLF 1*( SP / HTAB )
++ */
++private function assertValue($value)
++{
++// The regular expression intentionally does not support the obs-fold production, because as
++// per RFC 7230#3.2.4:
++//
++// A sender MUST NOT generate a message that includes
++// line folding (i.e., that has any field-value that

Bug#1011945: w3m: Updated message catalogue

2022-05-27 Thread Markus Hiereth

Package: w3m
Version: 0.5.3-37
Severity: normal

Dear Tatsuya,

with this bugreport, I pass the updated po-file proofread by the German 
language team.

Best regards
Markus
# German translation of w3m
# Copyright (C) 2014 THE w3m'S COPYRIGHT HOLDER
# This file is distributed under the same license as the w3m package.
# Markus Hiereth , 2014,2022.
msgid ""
msgstr ""
"Project-Id-Version: w3m 0.5.3\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-07-03 15:24+0900\n"
"PO-Revision-Date: 2022-05-27 09:00+0100\n"
"Last-Translator: Markus Hiereth \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#: menu.c:269
msgid " Back (b) "
msgstr " Zurück (b) "

#: menu.c:270
msgid " Select Buffer(s) "
msgstr " Puffer auswählen   (s) "

#: menu.c:272
msgid " Select Tab   (t) "
msgstr " Reiter auswählen   (t) "

#: menu.c:274
msgid " View Source  (v) "
msgstr " Codeansicht(v) "

#: menu.c:275
msgid " Edit Source  (e) "
msgstr " Code bearbeiten(e) "

#: menu.c:276
msgid " Save Source  (S) "
msgstr " Code speichern (S) "

#: menu.c:277
msgid " Reload   (r) "
msgstr " Erneut laden   (r) "

#: menu.c:278 menu.c:285 menu.c:289
msgid "  "
msgstr " -- "

#: menu.c:279
msgid " Go Link  (a) "
msgstr " Ziel öffnen..  (a) "

#: menu.c:280
msgid "   on New Tab (n) "
msgstr "  ..in neuem Reiter (n) "

#: menu.c:281
msgid " Save Link(A) "
msgstr " Ziel speichern (A) "

#: menu.c:282
msgid " View Image   (i) "
msgstr " Bild anzeigen  (i) "

#: menu.c:283
msgid " Save Image   (I) "
msgstr " Bild speichern (I) "

#: menu.c:284
msgid " View Frame   (f) "
msgstr " Frames zeigen  (f) "

#: menu.c:286
msgid " Bookmark (B) "
msgstr " Lesezeichen(B) "

#: menu.c:287
msgid " Help (h) "
msgstr " Hilfe  (h) "

#: menu.c:288
msgid " Option   (o) "
msgstr " Einstellungen  (o) "

#: menu.c:290
msgid " Quit (q) "
msgstr " Programm verlassen (q) "

#: rc.c:62
msgid "External Viewer Setup"
msgstr "Konfiguration für externe Anzeigeprogramme"

#: rc.c:63
msgid "Tab width in characters"
msgstr "Tabulatorbreite in Zeichen"

#: rc.c:64
msgid "Indent for HTML rendering"
msgstr "Einzug bei HTML-Darstellung"

#: rc.c:65
msgid "Number of pixels per character (4.0...32.0)"
msgstr "Anzahl von Pixeln pro Zeichen (4.0 bis 32.0)"

#: rc.c:66
msgid "Number of pixels per line (4.0...64.0)"
msgstr "Anzahl von Pixeln pro Zeile (4.0 bis 64.0)"

# entsprechend Bescheibung aus MANUAL.html, mh 14.10.2014
#: rc.c:67
msgid "Number of remembered lines when used as a pager"
msgstr "Anzahl gemerkter, über die Standardeingabe erhaltener Zeilen"

#: rc.c:68
msgid "Use URL history"
msgstr "URL-Chronik verwenden"

#: rc.c:69
msgid "Number of remembered URL"
msgstr "Anzahl von URLs in Chronik"

#: rc.c:70
msgid "Save URL history"
msgstr "URL-Chronik speichern"

#: rc.c:71
msgid "Render frames automatically"
msgstr "Frames selbstständig darstellen"

#: rc.c:72
msgid "Treat argument without scheme as URL"
msgstr "Eingabe ohne Protokoll-Präfix als URL auffassen"

#: rc.c:73
msgid "Use _self as default target"
msgstr "_self als Standard-Zielfenster verwenden"

#: rc.c:74
msgid "Open link on new tab if target is _blank or _new"
msgstr ""
"Link in neuem Reiter öffnen, falls für Zielfenster _blank oder _new "
"definiert ist"

#: rc.c:75
msgid "Open download list panel on new tab"
msgstr "Downloadliste in neuem Reiter öffnen"

#: rc.c:76
msgid "Display link URL automatically"
msgstr "URL der Links selbstständig anzeigen"

#: rc.c:77
msgid "Display link numbers"
msgstr "Linknummern anzeigen"

#: rc.c:78
msgid "Display decoded URL"
msgstr "URL entschlüsselt anzeigen"

#: rc.c:79
msgid "Display current line number"
msgstr "Aktuelle Zeilennummer anzeigen"

#: rc.c:80
msgid "Display inline images"
msgstr "Eingebettete Bilder anzeigen"

#: rc.c:81
msgid "Display pseudo-ALTs for inline images with no ALT or TITLE string"
msgstr "Pseudo-ALTs zu eingebetteten Bildern ohne ALT oder TITLE anzeigen"

#: rc.c:83
msgid "Load inline images automatically"
msgstr "Eingebettete Bilder selbstständig laden"

#: rc.c:84
msgid "Maximum processes for parallel image loading"
msgstr "Anzahl zulässiger Prozesse zum gleichzeitigen Laden von Bildern"

#: rc.c:85
msgid "Use external image viewer"
msgstr "Externen Bildbetrachter verwenden"

#: rc.c:86
msgid "Scale of image (%)"
msgstr "Bilder prozentual skalieren"

#: rc.c:87
msgid "External command to display image"
msgstr "Befehl für externen Bildbetrachter"

#: rc.c:88
msgid "Use link list of image map"
msgstr "Bei Grafiken mit eingebetteten Links Ziele auflisten"

#: rc.c:89
msgid "Inline image display method"
msgstr "Eingebettete Bilder protokoll"

#: rc.c:91
msgid "Display file names in multi-column format"
msgstr "Dateinamen auf

Bug#1010399: RFS: davegnukem/1.0.1-1 [ITP] -- Retro-style 2D scrolling platform shooter

2022-05-27 Thread Adam Borowski

On Sat, Apr 30, 2022 at 01:29:44PM +, Matteo Bini wrote:
>  * Package name: davegnukem
>Version : 1.0.1-1
>  * URL : https://djoffe.com/gnukem/

>   davegnukem - Retro-style 2D scrolling platform shooter

>  davegnukem (1.0.1-1) unstable; urgency=low
>  .
>* Initial release (Closes: #1009780)

Hi!
I'm afraid the package fails to build:

In file included from src/sys_log.cpp:22:
src/m_aliases.h:19:17: error: unnamed scoped enum is not allowed
   19 | #define byteunsigned char
  | ^~~~
src/m_aliases.h:19:17: error: expected identifier before ‘unsigned’
In file included from /usr/include/c++/11/cmath:42,
 from /usr/include/c++/11/math.h:36,
 from src/sys_defs.h:37,
 from src/sys_log.cpp:25:
/usr/include/c++/11/bits/cpp_type_traits.h:404:19: error: expected 
unqualified-id before ‘:’ token
  404 |   enum class byte : unsigned char
... and so on

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a
⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur.
⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted
⠈⠳⣄ from full hp in RL, please nerf!

Bug#993339: reprotest Salsa CI failure due to different creation times

2022-05-27 Thread Christoph Berg

Re: Rock Storm
> Christoph, I'm CCing you here both because you created the salsa CI
> configuration file back in the day and because you are the latest
> sponsor for this package, in case you feel this should be a blocker for
> Printrun updates.

Since this seems to be a toolchain issue rather than in the package,
don't treat it as a problem. (And even then, it's "only"
reproducibility which should be fixed, but doesn't have to.)

If it's getting too annoying, you could also make failures non-fatal:

reprotest:
  allow_failure: true

Christoph

Bug#1011944: opensnoop-perf: warning: regexp escape sequence `\"' is not a known regexp operator

2022-05-27 Thread Jakub Wilk


Package: perf-tools-unstable
Version: 1.0.1~20200130+git49b8cdf-1

I'm getting this warning:

  # opensnoop-perf
  Tracing open()s. Ctrl-C to end.
  COMM PID  FD FILE
  gawk: cmd. line:19: warning: regexp escape sequence `\"' is not a known 
regexp operator
  ...

--
Jakub Wilk

Bug#1011943: buster-pu: package php-guzzlehttp-psr7/1.4.2-0.1+deb10u1

2022-05-27 Thread David Prévot

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-php-p...@lists.alioth.debian.org


[ Reason ]
The security team asked me to address #1008236 [CVE-2022-24775] via a
point release, so here I am.

[ Tests ]
I did not test the package extensively, sorry about that. The patches
were pretty straightforward, but contrarily to Bullseye, the version
currently in Buster was pushed via NMU that removed the testsuite… It is
only used by the movim ecosystem in Buster.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

Regards

David
diff --git a/debian/changelog b/debian/changelog
index cb9f8a1..3fe276d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+php-guzzlehttp-psr7 (1.4.2-0.1+deb10u1) buster; urgency=medium
+
+  * Track Buster
+  * Backport fixes for improper header parsing [CVE-2022-24775]
+(Closes: #1008236)
+
+ -- David Prévot   Fri, 27 May 2022 13:33:28 +0200
+
 php-guzzlehttp-psr7 (1.4.2-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..6b83341
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,9 @@
+[DEFAULT]
+pristine-tar = True
+pristine-tar-commit = True
+debian-branch = debian/buster
+
+## Once --filter support gets added to gbp import-ref, we should be able
+## to simplify the workflow and ignore the upstream branch.
+# filter = [ '.gitattributes' ]
+# upstream-tag = %(version%~%-)s
diff --git a/debian/patches/0001-Release-1.8.4-486.patch b/debian/patches/0001-Release-1.8.4-486.patch
new file mode 100644
index 000..9f72423
--- /dev/null
+++ b/debian/patches/0001-Release-1.8.4-486.patch
@@ -0,0 +1,108 @@
+From: Graham Campbell 
+Date: Sun, 20 Mar 2022 13:44:44 +
+Subject: Release 1.8.4 (#486)
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Co-authored-by: Tim Düsterhus 
+
+Origin: backport, https://github.com/guzzle/psr7/commit/902db15a551a4a415e732b622282e21ce1b508b4
+---
+ src/MessageTrait.php | 56 +---
+ 1 file changed, 49 insertions(+), 7 deletions(-)
+
+diff --git a/src/MessageTrait.php b/src/MessageTrait.php
+index 1e4da64..f5f61db 100644
+--- a/src/MessageTrait.php
 b/src/MessageTrait.php
+@@ -70,7 +70,7 @@ trait MessageTrait
+ $value = [$value];
+ }
+ 
+-$value = $this->trimHeaderValues($value);
++$value = $this->trimAndValidateHeaderValues($value);
+ $normalized = strtolower($header);
+ 
+ $new = clone $this;
+@@ -89,7 +89,7 @@ trait MessageTrait
+ $value = [$value];
+ }
+ 
+-$value = $this->trimHeaderValues($value);
++$value = $this->trimAndValidateHeaderValues($value);
+ $normalized = strtolower($header);
+ 
+ $new = clone $this;
+@@ -148,7 +148,7 @@ trait MessageTrait
+ $value = [$value];
+ }
+ 
+-$value = $this->trimHeaderValues($value);
++$value = $this->trimAndValidateHeaderValues($value);
+ $normalized = strtolower($header);
+ if (isset($this->headerNames[$normalized])) {
+ $header = $this->headerNames[$normalized];
+@@ -168,16 +168,58 @@ trait MessageTrait
+  * header-field = field-name ":" OWS field-value OWS
+  * OWS  = *( SP / HTAB )
+  *
+- * @param string[] $values Header values
++ * @param mixed[] $values Header values
+  *
+  * @return string[] Trimmed header values
+  *
+  * @see https://tools.ietf.org/html/rfc7230#section-3.2.4
+  */
+-private function trimHeaderValues(array $values)
++private function trimAndValidateHeaderValues(array $values)
+ {
+ return array_map(function ($value) {
+-return trim($value, " \t");
+-}, $values);
++if (!is_scalar($value) && null !== $value) {
++throw new \InvalidArgumentException(sprintf(
++'Header value must be scalar or null but %s provided.',
++is_object($value) ? get_class($value) : gettype($value)
++));
++}
++
++$trimmed = trim((string) $value, " \t");
++$this->assertValue($trimmed);
++
++return $trimmed;
++}, array_values($values));
++}
++
++/**
++ * @param string $value
++ *
++ * @return void
++ *
++ * @see https://tools.ietf.org/html/rfc7230#section-3.2
++ *
++ * field-value= *( field-content / obs-fold )
++ * field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
++ * field-vchar= VCHAR / obs-text
++ * VCHAR  = %x21-7E
++ * obs-text   = %x80-FF
++ * obs-fold

Bug#1011942: bullseye-pu: package php-guzzlehttp-psr7/1.7.0-1+deb11u1

2022-05-27 Thread David Prévot

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-php-p...@lists.alioth.debian.org

[ Reason ]
The security team asked me to address #1008236 [CVE-2022-24775] via a
point release, so here I am.

[ Tests ]
I did not test the package extensively, sorry about that. The patches
were pretty straightforward and the version has a testsuite run during
build and CI (they both pass) so it should be OK. 

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

Regards

David


signature.asc
Description: PGP signature

Bug#1011941: rails: CVE-2022-22577 - XSS Vulnerability in Action Pack

2022-05-27 Thread Neil Williams

Source: rails
Version: 2:6.1.4.6+dfsg-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for rails.

CVE-2022-22577[0]:
| An XSS Vulnerability in Action Pack = 5.2.0 and  5.2.0 that
| could allow an attacker to bypass CSP for non HTML like responses.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-22577
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22577

Please adjust the affected versions in the BTS as needed.


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

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

Bug#1011940: rails: CVE-2022-21831 code injection vulnerability exists in Active Storage

2022-05-27 Thread Neil Williams

Source: rails
Version: 2:6.1.4.6+dfsg-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for rails.

CVE-2022-21831[0]:
| A code injection vulnerability exists in the Active Storage =
| v5.2.0 that could allow an attacker to execute code via
| image_processing arguments.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-21831
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21831

Please adjust the affected versions in the BTS as needed.


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

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

Bug#1010663: RFS: strawberry/1.0.4-1 [ITP] -- Audio player and music collection organizer

2022-05-27 Thread Peter


On 27/05/2022 11:11, Paul R. Tagliamonte wrote:
I searched my records and found the rejection. Looks like it's fixable. Quoted here and I've cc'd the ftpteam if 
anyone has questions


+--+
|   REJECT reasoning   |
+--+

A trainee points out:

ext\libstrawberry-common\core\scoped_nsautorelease_pool.mm 
 has a different
license and copyright holders

src\engine\enginebase.cpp and others not accounted for by d/copyright.

src\widgets\qsearchfield_mac.mm  and 
src\widgets\qsearchfield_nonmac.cpp not
accounted for by d/copyright.

+--+
|    Other comments    |
+--+

d/copyright does not account for ext\libstrawberry-common\core\logging.cpp.

src/dbus/*.xml are from a different project so presumably different copyright
holders?

+--+
|         N.B.         |
+--+

This review may not be exhaustive.  Please check your source package
against your d/copyright and the ftpmaster REJECT-FAQ, throughly,
before uploading to NEW again.

Thank you for your time and contribution!



Cheers,
 paultag



Thanks for that Paul,

Some of these have been fixed already.
I've added missing files to the Chromium Authors paragraph
and added a src/dbus/*.xml paragraph.

Updated debian/copyright and uploaded to Mentors & Salsa

Cheers,
Peter

Bug#1011939: bullseye-pu: package hdmi2usb-mode-switch/0.0.1-2+deb11u1

2022-05-27 Thread Stefano Rivera

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debconf-vi...@lists.debian.org

[ Reason ]
Linux started to have multiple /dev/video device nodes in
linux-image-4.19.0-5-amd64 (#1011938).

This broke hdmi2usb-udev because we wouldn't know which /dev/video
device to capture video from.

The DebConf Video team has known about this problem since buster, but
has only recently figured out the (fairly straightforward) solution.
Blame COVID-19 for us not meeting in person again, and dealing with it.

[ Impact ]
hdmi2usb-udev doesn't give you an unambiguous device to capture video
from, for your hdmi2usb hardware.

There is very little of this hardware in the wild, so the DebConf video
team are almost the only affected people.

[ Tests ]
Manually tested at the Hamburg Debian Reunion 2022.

[ Risks ]
Pretty trivial changes. Extremely low popcon :)
Rare, out of production hardware.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
1. Add a suffix to the device node, from information provided by
   60-persistent-v4l.rules
2. Sort the udev rule *after* 60-persistent-v4l.rules.
diff -Nru hdmi2usb-mode-switch-0.0.1/debian/changelog 
hdmi2usb-mode-switch-0.0.1/debian/changelog
--- hdmi2usb-mode-switch-0.0.1/debian/changelog 2018-01-19 09:28:58.0 
+0200
+++ hdmi2usb-mode-switch-0.0.1/debian/changelog 2022-05-27 12:22:19.0 
+0200
@@ -1,3 +1,11 @@
+hdmi2usb-mode-switch (0.0.1-2+deb11u1) bullseye; urgency=low
+
+  * Patch: Udev: Add a suffix to /dev/video device nodes to disambiguate them.
+(Closes: #1011938)
+  * Move udev rules to priority 70, to come after 60-persistent-v4l.rules.
+
+ -- Stefano Rivera   Fri, 27 May 2022 12:22:19 +0200
+
 hdmi2usb-mode-switch (0.0.1-2) unstable; urgency=medium
 
   * Update symlinks for ixo-usb-jtag 0.0.1.
diff -Nru 
hdmi2usb-mode-switch-0.0.1/debian/patches/disambiguate-video-device-nodes 
hdmi2usb-mode-switch-0.0.1/debian/patches/disambiguate-video-device-nodes
--- hdmi2usb-mode-switch-0.0.1/debian/patches/disambiguate-video-device-nodes   
1970-01-01 02:00:00.0 +0200
+++ hdmi2usb-mode-switch-0.0.1/debian/patches/disambiguate-video-device-nodes   
2022-05-27 12:22:19.0 +0200
@@ -0,0 +1,52 @@
+From: Nicolas Dandrimont 
+Date: Thu, 26 May 2022 22:17:33 +0200
+Subject: Add a suffix to the video device name when no capture capability is
+ detected
+
+Recent versions of the linux kernel generate multiple device nodes for
+each uvcvideo capture card. The HDMI2USB-generated video symlinks end up
+stomping on one another until the last one wins.
+
+Recent versions of udev's id_v4l script add a ID_V4L_CAPABILITIES
+variable that we can use to distinguish both devices. We give the
+metadata device a `-metadata` suffix to distinguish it from the capture
+node.
+
+Origin: https://github.com/litex-hub/litex-buildenv-udev/pull/9
+Bug-Debian: https://bugs.debian.org/1011938
+---
+ udev/99-hdmi2usb-aliases.rules | 15 ++-
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/udev/99-hdmi2usb-aliases.rules b/udev/99-hdmi2usb-aliases.rules
+index 8ae7f48..e0863ca 100644
+--- a/udev/99-hdmi2usb-aliases.rules
 b/udev/99-hdmi2usb-aliases.rules
+@@ -119,17 +119,22 @@ SUBSYSTEM=="tty", ENV{ID_HDMI2USB}=="1", 
ENV{NUM_HDMI2USB_TTY}!="", ENV{NUM_HDMI
+   
SYMLINK+="hdmi2usb/by-num/$env{ID_HDMI2USB_BOARD}$env{NUM_HDMI2USB_BOARD}/tty$env{NUM_HDMI2USB_TTY}"
+ 
+ # Video capture device
++SUBSYSTEM=="video4linux", ENV{ID_HDMI2USB}=="1", 
ENV{ID_V4L_CAPABILITIES}=="*:capture:*" \
++ENV{HDMI2USB_VIDEO_SUFFIX}:=""
++SUBSYSTEM=="video4linux", ENV{ID_HDMI2USB}=="1", 
ENV{ID_V4L_CAPABILITIES}!="*:capture:*" \
++ENV{HDMI2USB_VIDEO_SUFFIX}:="-metadata"
++
+ SUBSYSTEM=="video4linux", ENV{ID_HDMI2USB}=="1", ENV{ID_SERIAL_SHORT}!="" \
+-  SYMLINK+="hdmi2usb/by-serial/$env{ID_SERIAL_SHORT}/video"
++  
SYMLINK+="hdmi2usb/by-serial/$env{ID_SERIAL_SHORT}/video$env{HDMI2USB_VIDEO_SUFFIX}"
+ 
+ SUBSYSTEM=="video4linux", ENV{ID_HDMI2USB}=="1", ENV{ID_PATH}!="" \
+-  SYMLINK+="hdmi2usb/by-path/$env{ID_PATH}/video"
++  
SYMLINK+="hdmi2usb/by-path/$env{ID_PATH}/video$env{HDMI2USB_VIDEO_SUFFIX}"
+ 
+ SUBSYSTEM=="video4linux", ENV{ID_HDMI2USB}=="1", ENV{ID_PATH_HUMAN}!="" \
+-  SYMLINK+="hdmi2usb/by-path/$env{ID_PATH_HUMAN}/video"
++  
SYMLINK+="hdmi2usb/by-path/$env{ID_PATH_HUMAN}/video$env{HDMI2USB_VIDEO_SUFFIX}"
+ 
+ SUBSYSTEM=="video4linux", ENV{ID_HDMI2USB}=="1", ENV{NUM_HDMI2USB}!="" \
+-  SYMLINK+="hdmi2usb/by-num/all$env{NUM_HDMI2USB}/video"
++  
SYMLINK+="hdmi2usb/by-num/all$env{NUM_HDMI2USB}/video$env{HDMI2USB_VIDEO_SUFFIX}"
+ 
+ SUBSYSTEM=="video4linux", ENV{ID_HDMI2USB}=="1", ENV{ID_HDMI2USB_BOARD}!="", 
ENV{NUM_HDMI2USB_BOARD}!="" \
+-

Bug#1011937: python-debian: Please consider moving deb822 to a standalone distro-independent Python package

2022-05-27 Thread Jelmer Vernooĳ

On Fri, May 27, 2022 at 12:01:17PM +0200, Stephan Lachnit wrote:
> I'm not an expert on python-debian and I don't use other distros than
> Debian, so I can only forward you some bug reports from
> https://github.com/fsfe/reuse-tool/issues/466:
> - https://github.com/fsfe/reuse-tool/issues/311 (fixed now)
> - https://github.com/fsfe/reuse-tool/issues/425: `apt_pkg.Error:
> W:Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such
> file or directory), E:Unable to determine a suitable packaging system
> type`
>   This one is probably tricky to solve, maybe python-debian can check
> if it is in a Debian env by checking /etc/os-release?
> 
> Ofc if python-debian would ensure cross-platform operability, that
> would be great, then there would be no need for a package split. I
> guess it depends a bit on the policy: is it tested on non-Debian
> platforms or just an afterthought where bugs get fixed when reported
> in version? If it is the latter, REUSE will probably still try to
> replace it. If it is the former, I think there is little reason to
> move away from python-debian. cc/ Max Mehl?

It looks like reuse doesn't juse use deb822, but the copyright module
as well - so just extracting deb822 would not be sufficient:

https://github.com/fsfe/reuse-tool/issues/454

> Looking quickly at the CI though, it does not seem that this is
> currently the case. Maybe you could add a `unit-tests-alpine` and
> `unit-tests-windows` job based on the official Python Docker images
> [1] (w/ dependencies pulled via pip)? IMHO this should give enough
> confidence in the cross-platform operability of this package (again
> cc/ Max Mehl, I'm not a developer of REUSE).

I'd prefer that avenue; we could potentially disable some of
the functionality on windows (e.g. stuff that relies on python3-apt,
which AFAIK is already optional).

>From what I can tell, the testsuite runs fine on other Linux platforms
- we haven't had many bugreports from packagers on those platforms.

I wouldn't be surprised if people came along in the future that e.g.
needed watch file parsing on Windows or copyright file parsing, and I
wouldn't want to have to split out all of those as separate modules as
well.

Cheers,

Jelmer


> On Fri, May 27, 2022 at 11:15 AM Jelmer Vernooĳ  wrote:
> >
> > Hi Stephan,
> >
> > On Fri, May 27, 2022 at 10:05:47AM +0200, Stephan Lachnit wrote:
> > > I'm working on a project that aims to use REUSE [1] to automate the
> > > process of creating and maintaing the d/copyright file.
> > >
> > > tl;dr: REUSE is a specification to annote license and copyright holder
> > > in a machine-readable way in the source files itself. Since Debian has a
> > > similar per-file copyright concept, using information from source
> > > packages that follow this specification can in principle be automated to
> > > reduce the work maintainers have to do.
> > >
> > >
> > > For several reasons it would be nice to have a d/copyright parser at
> > > hand, and since python-debian provides this with the deb822 module, it
> > > would be unneccessary work to write this again. REUSE already uses
> > > python-debian for this, but wants to get rit of it because there are
> > > some issue with this module on non-Debian OSes [2].
> > >
> > >
> > > To come to the topic of this wishlist-bugreport: would it be possible to
> > > factor the deb822 parser out in a completetly separate Python package
> > > (on PyPi), e.g. python3-deb822, that explicitly does not depend on a
> > > Debian environment?
> >
> > What are the portability issues that exist in non-Debian environments? I'd
> > prefer to address those if possible rather than factoring out the deb822
> > module, since that complicates on an ongoing basis in the future.
> >
> > FWIW python-debian is packaged in other Linux distributions, so my guess
> > is that the issue is non-Linux rather than non-Debian environments?
> > https://repology.org/project/python:debian/versions
> >
> > Jelmer
> 
> -- 
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-python-debian-maint

Bug#1010663: RFS: strawberry/1.0.4-1 [ITP] -- Audio player and music collection organizer

2022-05-27 Thread Paul R. Tagliamonte

I searched my records and found the rejection. Looks like it's fixable.
Quoted here and I've cc'd the ftpteam if anyone has questions

+--+
|   REJECT reasoning   |
+--+

A trainee points out:

ext\libstrawberry-common\core\scoped_nsautorelease_pool.mm has a different
license and copyright holders

src\engine\enginebase.cpp and others not accounted for by d/copyright.

src\widgets\qsearchfield_mac.mm and src\widgets\qsearchfield_nonmac.cpp not
accounted for by d/copyright.

+--+
|Other comments|
+--+

d/copyright does not account for ext\libstrawberry-common\core\logging.cpp.

src/dbus/*.xml are from a different project so presumably different
copyright
holders?

+--+
| N.B. |
+--+

This review may not be exhaustive.  Please check your source package
against your d/copyright and the ftpmaster REJECT-FAQ, throughly,
before uploading to NEW again.

Thank you for your time and contribution!



Cheers,
 paultag


On Wed, May 18, 2022, 12:18 PM Jeroen Ploemen  wrote:

> Control: tags -1 moreinfo
>
> On Fri, 6 May 2022 13:11:37 +0100
> Peter  wrote:
>
> > I am looking for a sponsor for my package "strawberry":
>
> hi Peter,
>
> like pollo, I'm puzzled by the mention on the ITP bug of the package
> being in NEW at some point, only to vanish into thin air? Would be
> nice to know what happened to it, if only to avoid running into the
> same problems. Maybe Thomas would like to chime in on this?
>
>
> That said, I took a look anyway. Some comments and observations:
> - There's an unused manpage in the debian dir, an apparent leftover
>   from the earlier packaging effort
> - Copyright:
>   * missing copyright holder "Pascal Below" (for various
> scrobbler-related files)
>   * missing info for 3rdparty/macdeployqt
>   * wrong license for 3rdparty/SPMediaKeyTap
>   * is upstream the sole contributor to the debian packaging?
>   * MIT and Expat license definitions appear identical, please use
> Expat as the license name throughout and remove the duplicate
>   * the content of the license paragraphs for GPL-3 and GPL-3+ is
> identical (but obviously shouldn't be)
>   * be careful to exclude copyright claims, comments, etc. from the
> license paragraphs; i.e. make the definitions for the BSD-style
> licenses start at "Redistribution and use..." so they're generic
> and re-usable; everything else belongs in the Files paragraphs
> - Control:
>   * short description shouldn't start with caps
>   * hardcoded libsqlite3-0 library dependency should be handled by
> ${shlibs:Depends} (libqt5sql5-sqlite is only recommended by the
> qt sql lib so that one might actually be justified)
>   * a slightly newer standards-version out has come out recently
>   * VCS: consider setting up a git repo on salsa.debian.org for your
> packaging work and enabling the CI there: it's a great quality
> control and collaboration tool, and a real timesaver for reviewers
> too
> - Docs: upstream changelog installed as doc rather than as changelog
>   (via dh_installchangelogs)
> - Rules: better list those files in d/clean instead of using an
>   override
> - Upstream/metadata: is a github user page -even that of the lead
>   developer- really the best place to contact the upstream project?
> - Watch: unused dversionmangling
>
> - Build: why -fpermissive?
>
> - FHS: according to its manpage, the tagreader binary "is not meant to
>   be run on its own"; is /usr/bin really where it should be installed?
>   See https://www.debian.org/doc/packaging-manuals/fhs/ (libexec?)
>
> - Lintian:
>   * I: strawberry: desktop-entry-lacks-keywords-entry
> usr/share/applications/org.strawberrymusicplayer.strawberry.desktop
>
> - Tests: upstream ships a testsuite; if possible, please run it on
>   build and/or deploy it as an autopkgtest
>
>
> Please remove the moreinfo tag (and CC me directly) once you have an
> updated package ready.
>

Bug#1011937: python-debian: Please consider moving deb822 to a standalone distro-independent Python package

2022-05-27 Thread Stephan Lachnit

Hi Jelmer,

Thanks for the quick response!

I'm not an expert on python-debian and I don't use other distros than
Debian, so I can only forward you some bug reports from
https://github.com/fsfe/reuse-tool/issues/466:
- https://github.com/fsfe/reuse-tool/issues/311 (fixed now)
- https://github.com/fsfe/reuse-tool/issues/425: `apt_pkg.Error:
W:Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such
file or directory), E:Unable to determine a suitable packaging system
type`
  This one is probably tricky to solve, maybe python-debian can check
if it is in a Debian env by checking /etc/os-release?

Ofc if python-debian would ensure cross-platform operability, that
would be great, then there would be no need for a package split. I
guess it depends a bit on the policy: is it tested on non-Debian
platforms or just an afterthought where bugs get fixed when reported
in version? If it is the latter, REUSE will probably still try to
replace it. If it is the former, I think there is little reason to
move away from python-debian. cc/ Max Mehl?

Looking quickly at the CI though, it does not seem that this is
currently the case. Maybe you could add a `unit-tests-alpine` and
`unit-tests-windows` job based on the official Python Docker images
[1] (w/ dependencies pulled via pip)? IMHO this should give enough
confidence in the cross-platform operability of this package (again
cc/ Max Mehl, I'm not a developer of REUSE).

Best,
Stephan

[1]: https://hub.docker.com/_/python


On Fri, May 27, 2022 at 11:15 AM Jelmer Vernooĳ  wrote:
>
> Hi Stephan,
>
> On Fri, May 27, 2022 at 10:05:47AM +0200, Stephan Lachnit wrote:
> > I'm working on a project that aims to use REUSE [1] to automate the
> > process of creating and maintaing the d/copyright file.
> >
> > tl;dr: REUSE is a specification to annote license and copyright holder
> > in a machine-readable way in the source files itself. Since Debian has a
> > similar per-file copyright concept, using information from source
> > packages that follow this specification can in principle be automated to
> > reduce the work maintainers have to do.
> >
> >
> > For several reasons it would be nice to have a d/copyright parser at
> > hand, and since python-debian provides this with the deb822 module, it
> > would be unneccessary work to write this again. REUSE already uses
> > python-debian for this, but wants to get rit of it because there are
> > some issue with this module on non-Debian OSes [2].
> >
> >
> > To come to the topic of this wishlist-bugreport: would it be possible to
> > factor the deb822 parser out in a completetly separate Python package
> > (on PyPi), e.g. python3-deb822, that explicitly does not depend on a
> > Debian environment?
>
> What are the portability issues that exist in non-Debian environments? I'd
> prefer to address those if possible rather than factoring out the deb822
> module, since that complicates on an ongoing basis in the future.
>
> FWIW python-debian is packaged in other Linux distributions, so my guess
> is that the issue is non-Linux rather than non-Debian environments?
> https://repology.org/project/python:debian/versions
>
> Jelmer

Bug#930860: linux-image-4.19.0-5-amd64: USB Camera seen as multiple devices

2022-05-27 Thread Stefano Rivera

Control: clone -1 -2
Control: reassign -2 hdmi2usb-udev
Control: found -2 hdmi2usb-udev/0.0.1-2

This seems to be expected behaviour, at this point.

hdmi2usb-udev doesn't handle it in buster, and it needs to to be useful.

SR

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

Bug#1010663: RFS: strawberry/1.0.4-1 [ITP] -- Audio player and music collection organizer

2022-05-27 Thread Peter





I've just created https://salsa.debian.org/debian/strawberry and
granted your account maintainer level access.

Once you got that up and running with the CI I'll take another look
at the package.


Hi Jeroen,

Strawberry has passed all CI tests.
https://salsa.debian.org/debian/strawberry/-/jobs

Cheers,
Peter

Bug#1011935: QtChooser is dead by choice upstream, no Qt6 Support

2022-05-27 Thread Dmitry Shachnev

Hi Thomas!

On Thu, May 26, 2022 at 09:58:36PM -0400, Thomas Ward wrote:
> Source: qtchooser
> Severity: wishlist
>
> It was determined from
> https://salsa.debian.org/qt-kde-team/qt/qtchooser/-/merge_requests/2 and a
> downstream Ubuntu bug on Qt6 not working that QtChooser is dead upstream on
> purpose.
>
> If it is dead upstream on purpose and should NOT work with Qt6, could we add
> a Breaks on qt6 and higher, since it is only kept around for Qt5 support and
> not breaking Qt5 applications that rely on it?  Therefore indicating that
> Qt6 is not and *will* not be supported on the now-dead-upstream project?

qtchooser is perfectly co-installable with Qt 6 libraries, and I don't see why
we should disallow people to use qtchooser (for Qt 5) while also having Qt 6
installed.

Eventually qtchooser will be removed, but the majority of Qt software is still
using Qt 5 and not Qt 6, so it's still useful and it's very likely that users
will have both Qt 5 and Qt 6 installed.

--
Dmitry Shachnev

signature.asc
Description: PGP signature

Bug#1011937: python-debian: Please consider moving deb822 to a standalone distro-independent Python package

2022-05-27 Thread Jelmer Vernooĳ

Hi Stephan,

On Fri, May 27, 2022 at 10:05:47AM +0200, Stephan Lachnit wrote:
> I'm working on a project that aims to use REUSE [1] to automate the
> process of creating and maintaing the d/copyright file.
> 
> tl;dr: REUSE is a specification to annote license and copyright holder
> in a machine-readable way in the source files itself. Since Debian has a
> similar per-file copyright concept, using information from source
> packages that follow this specification can in principle be automated to
> reduce the work maintainers have to do.
> 
> 
> For several reasons it would be nice to have a d/copyright parser at
> hand, and since python-debian provides this with the deb822 module, it
> would be unneccessary work to write this again. REUSE already uses
> python-debian for this, but wants to get rit of it because there are
> some issue with this module on non-Debian OSes [2].
> 
> 
> To come to the topic of this wishlist-bugreport: would it be possible to
> factor the deb822 parser out in a completetly separate Python package
> (on PyPi), e.g. python3-deb822, that explicitly does not depend on a
> Debian environment?

What are the portability issues that exist in non-Debian environments? I'd
prefer to address those if possible rather than factoring out the deb822
module, since that complicates on an ongoing basis in the future.

FWIW python-debian is packaged in other Linux distributions, so my guess
is that the issue is non-Linux rather than non-Debian environments?
https://repology.org/project/python:debian/versions

Jelmer

Bug#1010883: dkms breaks nvidia-graphics-drivers autopkgtest on arm64: unmet dependencies

2022-05-27 Thread Paul Gevers


Hi Andreas,

On 26-05-2022 10:58, Andreas Beckmann wrote:

Control: reopen -1
Control: reassign -1 dkms 3.0.3-1
Control: retitle -1 dkms: autopkgtest mixes headers from sid and testing


Thanks. I agree with this action.


My guess is that apt pinning comes into play here, installing


That aligns with my suspicion that it's related to the mixing of 
unstable and testing.


OK, adding --apt-default-release=bookworm makes it work and reproduces 
the error :-) Why is that not needed with the ci chroots?


I *suspect* that's because ci.d.o and salsa.d.o don't use chroots but lxc.


(add_apt_releases) has two issues I needed to work around in my chroot:
* it expects /etc/apt/sources.list to exist (I only had 
sources.list.d/bookworm.list)


That may be a bug in the autopkgtest chroot backend. Nearly all my 
experience is with the lxc backend, so it would need investigation.



* it does not cope with tabs instead of spaces as separators


Same, feel free to report the bug.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010242: RFS: opengnb/1.2.8.7-1 [ITP] -- via P2P to setup de-centralized layer3 network VPN

2022-05-27 Thread Bastian Germann


Hi Xiao,

Please remove the debian/links file. We do not need the README in /etc.

What about those public gnb index nodes? Is the list published somewhere except 
for this package?

Thanks,
Bastian

Bug#983085: [git-buildpackage/master] clone: Allow to skip alias expansion

2022-05-27 Thread Guido Günther

tag 983085 pending
thanks

Date:   Thu May 26 20:59:08 2022 +0200
Author: Guido GÃ¼nther 
Commit ID: 42a140686674741827820e2ca7eede886c56d3cd
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=42a140686674741827820e2ca7eede886c56d3cd
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=42a140686674741827820e2ca7eede886c56d3cd

clone: Allow to skip alias expansion

Add an option that allow to skip exansion of aliases like salsa:
by gbp so that git can do that.

Closes: #983085

Bug#1008531: 0ad: assertion failure if hyperthreading (SMT) is supported but disabled

2022-05-27 Thread Stanislas Dolcini

Hello,

My name is Stan` I'm the 0 A.D: Empires Ascendant project leader. We were
recently made aware of the issue, and no one seems to have experienced it
before.

Does it do the same if you disable hyperthreading in the BIOS rather than
with a kernel flag?

We have a potential fix at: https://code.wildfiregames.com/D4669
As mentioned there an ideal fix might be to use the SDL instead, to do that
stuff.

And the discussion thread is here:
https://wildfiregames.com/forum/topic/81402-from-debian-assertion-failure-if-hyperthreading-smt-is-supported-but-disabled/

Best regards,

*Stanislas DOLCINI*

*Twitter*: @stanislasdolcin 
*Mail* : stanislas.dolc...@gmail.com

Bug#1010685: dpkg-buildflags: Please enable -ftrivial-auto-var-init=zero

2022-05-27 Thread Guillem Jover

Hi!

On Fri, 2022-05-06 at 20:50:08 -0700, Kees Cook wrote:
> Package: dpkg-dev
> Version: 1.21.7
> Severity: normal

> Please add "-ftrivial-auto-var-init=zero" for GCC 12 (which is the first
> release of GCC to provide this flag).
> 
> It goes well with the other important security flaw mitigation flags
> already enabled in Debian:
> https://wiki.debian.org/Hardening#dpkg-buildflags
> 
> While many variables are initialized (due to -Wuninitialized), there is
> a blind spot for variables passed by reference, padding, and cases where
> -Wuninitialized just fails to track it. Universally wiping the variables
> eliminates nearly the entire class of uninitialized stack variable use
> (https://cwe.mitre.org/data/definitions/457.html) with nearly no overhead
> (e.g. any duplicate assignments will already be squashed during dead
> store elimination, etc).

Ah, this flag is great, it's a pity the C standard would not declare
this the default behavior though. :/

Checking https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/1972043
that covers my main concerns I think.

The clang position on =zero seems concerning though. I also hope no
security related project is using the uninitialized memory (UB) to
seed something like an PRNG or similar. :/

(Enabling this by default means that developers might fail to notice
issue shadowed by this feature, and this could then affect builds on
systems where this is not the default. This is less concerning when
enabling it in dpkg-dev than in gcc I guess.)

The usual procedure to add new default flags (in case of hardening
even adding a new flag disabled by default implies more or less being
enabled by default as many packages simply do hardening=+all), would be
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F,
but in this case I'm not sure how useful an archive rebuild would be
given that the effect would most probably be seen at run-time, but
only on unexpected conditions. Still bringing this up on debian-devel
would be a first.

Thanks,
Guillem

Bug#1010623: new version 056-3 available

2022-05-27 Thread Thomas Lange

I have iput the deb files on my projects repository in
http://fai-project.org/download/beta-testing/

You can use this line in sources.list:

   deb https://fai-project.org/download beta-testing koeln

-- 
regards Thomas

Bug#1011937: python-debian: Please consider moving deb822 to a standalone distro-independent Python package

2022-05-27 Thread Stephan Lachnit

Source: python-debian
Version: 0.1.43
Severity: wishlist
X-Debbugs-Cc: stephanlach...@debian.org, max.m...@fsfe.org

I'm working on a project that aims to use REUSE [1] to automate the
process of creating and maintaing the d/copyright file.

tl;dr: REUSE is a specification to annote license and copyright holder
in a machine-readable way in the source files itself. Since Debian has a
similar per-file copyright concept, using information from source
packages that follow this specification can in principle be automated to
reduce the work maintainers have to do.


For several reasons it would be nice to have a d/copyright parser at
hand, and since python-debian provides this with the deb822 module, it
would be unneccessary work to write this again. REUSE already uses
python-debian for this, but wants to get rit of it because there are
some issue with this module on non-Debian OSes [2].


To come to the topic of this wishlist-bugreport: would it be possible to
factor the deb822 parser out in a completetly separate Python package
(on PyPi), e.g. python3-deb822, that explicitly does not depend on a
Debian environment?


Cheers,
Stephan


[1]: https://reuse.software/
[2]: https://github.com/fsfe/reuse-tool/issues/466


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

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

Bug#1011717: Patch

2022-05-27 Thread Wolfgang Silbermayr

Tags: +patch

The problem appear to be two occurrences of uninitialized variables which gets
reported by `cppcheck` 2.8 during build. Older versions of `cppcheck` didn't
report that problem, this is why the package built without problems initially.

Reported upstream to https://github.com/vasi/pixz/issues/103
Submitted MR: https://github.com/vasi/pixz/pull/104

Attached the patch exported such that it can be added to the package with quilt.

Wolfgang.
>From 2f4db115586bd3d98c1f05eb64c125495bf0331a Mon Sep 17 00:00:00 2001
From: Wolfgang Silbermayr 
Date: Fri, 27 May 2022 09:19:02 +0200
Subject: [PATCH] Fix cppcheck 2.8 uninitialized variables warnings
Forwarded: https://github.com/vasi/pixz/pull/104
Author: Wolfgang Silbermayr 

---
 src/write.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/write.c b/src/write.c
index c84ec55..7ecfb19 100644
--- a/src/write.c
+++ b/src/write.c
@@ -448,7 +448,7 @@ static void write_block(pipeline_item_t *pi) {
 static void encode_index(void) {
 if (lzma_index_encoder(, gIndex) != LZMA_OK)
 die("Error creating index encoder");
-uint8_t obuf[CHUNKSIZE];
+uint8_t obuf[CHUNKSIZE] = {};
 lzma_ret err = LZMA_OK;
 while (err != LZMA_STREAM_END) {
 gStream.next_out = obuf;
@@ -513,7 +513,7 @@ static void write_file_index_bytes(size_t size, uint8_t *buf) {
 }
 
 static void write_file_index_buf(lzma_action action) {
-uint8_t obuf[CHUNKSIZE];
+uint8_t obuf[CHUNKSIZE] = {};
 gStream.avail_in = gFileIndexBufPos;
 gStream.next_in = gFileIndexBuf;
 lzma_ret err = LZMA_OK;
-- 
2.35.1

Bug#918914: add -fstack-clash-protection to default buildflags

2022-05-27 Thread Guillem Jover

Hi!

On Thu, 2020-09-03 at 21:00:09 +0200, Moritz Mühlenhoff wrote:
> On Thu, Jan 10, 2019 at 09:42:10AM -0500, Harlan Lieberman-Berg wrote:
> > Package: dpkg-dev
> > Version: 1.19.2
> > Severity: wishlist
> > Tags: security

> > It would be Really Awesome (TM) if we could add the
> > -fstack-clash-protection flag to our default hardening posture.  This
> > would have provided protection against the recent System Down
> > vulnerability (CVE-2018-16864, CVE-2018-16865, CVE-2018-16866, aka
> > #918841 and #918848).
> > 
> > I'd reay love it if it would make it into buster, but I know
> > that's an awfully aggressive timeline considering the upcoming freeze.
> > Still, there are an awfully high number of vulnerabilities that are
> > lurking that this might be able to help patch up.
> > 
> > Happy to discuss more, and if we need to do a test archive-rebuild
> > with that change made, I can probably do that in the upcoming weekend.
> 
> Has there been progress? Did anyone run archive rebuilds? Or given
> that Ubuntu enables it by default these days, do we actually still
> need them?

I don't think the issues presented by Florian were ever resolved, so
my concerns in https://bugs.debian.org/918914#15 would still apply,
even though Ubuntu has enabled this, but they have a different set of
architectures.

In addition adding support for this but disabled by default can be
problematic now that many packages just set hardening=+all. :/ I guess
I'll need to add the dpkg-compat level support sooner than later.

In any case, someone would need to propose this on debian-devel at least.

Thanks,
Guillem

Bug#989085: Description suggestion

2022-05-27 Thread Stephan Lachnit

Thanks for the description! Once I have time again to package this, I
will use it.

Best,
Stephan

On Fri, May 20, 2022 at 9:21 PM Joseph Carter
 wrote:
>
> Suggest something like…
>
> Description: Micro-compositor for game scaling
>  Gamescope wraps your games to give them scaling and fullscreen options. It
>  provides a Wayland compositor to your games, but gamescope runs under both
>  Wayland and X.org.
>  .
>  Your game sees a virtual display at the resolution you specified. You see a
>  scaled view in a window or fullscreen. This is useful when either the game or
>  your system do not permit running the game at native window/screen sizes. You
>  can also use integer scaling to keep your pixels sharp and pixelated.
>
> I think this should resolve any confusion as to whether or not a person wants 
> to install this.
>
> Joseph

Bug#1010623: new version 056-3 available

2022-05-27 Thread Dick Middleton


On 5/25/22 4:16 PM, Thomas Lange wrote:

There's a new dracut version 056-3 available, which creates on my
machine an initrd which much more crypto kernel modules included. ecb
is in there, ccm not.

Please try this version, which is only available for bookworm yet. It
will not work on bullseye, but I have backports version for bullseye.


I don't have bookworm and it's not yet in bullseye-backports.  Where do I get 
it?

Dick

--
Dick Middleton  d...@lingbrae.com

Bug#1011756: cloud.debian.org: Vagrant debian/testing64: sshd rejects default insecure ssh-rsa key, hangs waiting for SSH

2022-05-27 Thread Emmanuel Kasper

We have now that documented in the Debian Wiki:
https://wiki.debian.org/Vagrant#Vagrant_from_Debian_11_or_previous_versions_hang_on_.22default:_Waiting_for_SSH_to_become_available22


-- 
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Bug#989409: nss-pam-ldapd's autopkgtest fails with OpenLDAP 2.5

2022-05-27 Thread Petter Reinholdtsen

[Salvatore Bonaccorso 2022-04-25]
> Are there any news on this bug? nss-pam-ldapd is currently hinted for
> removal from testing due to this bug (not happened yet though).

Today the debian-fbx and kwartz-client packages was removed from testing
because they depend on nss-pam-ldapd, due to the latters RC issue.  Any
hope to have a fixed version of nss-pam-ldapd in unstable soon?
-- 
Happy hacking
Petter Reinholdtsen

82 matches

Mail list logo