Bug#1010196: RM: elog/3.1.3-1-1

2022-04-25 Thread Salvatore Bonaccorso
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: car...@debian.org,t...@security.debian.org
Control: clone -1 -2
Control: retitle -1 RM: elog/3.1.3-1-1 (from bullseye)
Control: retitle -2 RM: elog/3.1.3-1-1 (from buster)

Dear Stable release managers,

Discussing the state of elog with upstream, and the subsequent removal
of elog from unstable, we would like to ask to remove elog as well on
the next buster and bullseye point releases (cloning this bug
accordingly).

https://tracker.debian.org/news/1320035/removed-313-1-1-from-unstable/

The version in Debian has several issues, while they can probably be
continued to be patched for the old version, upstream advised against
continuing to ship the old version, which was almost the same since
back in stretch.

Given the low usage in Debian itself, we can opt for the removal of
elog from buster and bullseye.

Regards,
Salvatore



Bug#1010195: astroquery: autopkgtest regression: No module named 'PIL'

2022-04-25 Thread Paul Gevers

Source: astroquery
Version: 0.4.6+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
astroquery from testing0.4.6+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. To the 
bystander it looks like a new dependency was missed.


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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroquery/21157298/log.gz

__ ERROR collecting hips2fits/tests/test_hips2fits.py 
__
ImportError while importing test module 
'/usr/lib/python3/dist-packages/astroquery/hips2fits/tests/test_hips2fits.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/usr/lib/python3/dist-packages/astroquery/hips2fits/__init__.py:39: in 


from .core import hips2fits, hips2fitsClass
/usr/lib/python3/dist-packages/astroquery/hips2fits/core.py:28: in 
from PIL import Image
E   ModuleNotFoundError: No module named 'PIL'
__ ERROR collecting hips2fits/tests/test_hips2fits_remote.py 
___
ImportError while importing test module 
'/usr/lib/python3/dist-packages/astroquery/hips2fits/tests/test_hips2fits_remote.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/usr/lib/python3/dist-packages/astroquery/hips2fits/__init__.py:39: in 


from .core import hips2fits, hips2fitsClass
/usr/lib/python3/dist-packages/astroquery/hips2fits/core.py:28: in 
from PIL import Image
E   ModuleNotFoundError: No module named 'PIL'


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1009858: linux: please consider building the modules necessary for the MNT Reform laptop

2022-04-25 Thread Johannes Schauer Marin Rodrigues
Hi Vagrant,

Quoting Vagrant Cascadian (2022-04-26 02:07:51)
> On 2022-04-24, Vagrant Cascadian wrote:
> > On 2022-04-19, Johannes Schauer Marin Rodrigues wrote:
> >> currently, we add the following to the arm64 kernel config provided by
> >> the Debian kernel packaging to build a kernel that powers the MNT Reform
> >> 2 open source laptop:
> >
> > Thanks!
> >
> > Merged most of the changes so far except...
> 
> Which I can confirm boots!  Although no output on the LCD, just serial
> console...
> 
> 
> >> CONFIG_DRM_CDNS_HDMI_CEC=m
> >> CONFIG_DRM_IMX_CDNS_MHDP=m
> >
> > These are not yet in upstream 5.17.x, so I left them out.
> 
> Presumably LCD and HDMI don't work due to missing those, and/or other
> not-yet-upstream patches...

amazing!! :D Having serial console work with the stock kernel from Debian will
make it so much easier to test and fix other stuff like debian-installer early
on. Thank you! :)

Yes, LCD support is part of the remaining patches:

https://source.mnt.re/reform/reform-debian-packages/-/tree/main/linux/patches

I also saw your message in #mnt-reform yesterday and you are right, my script
sets console=ttymxc1 instead of console=ttymxc0. This is due to a wrong commit
from my end because my S1 (ttymxc0) port has a non-functional TX pin so I was
always using S2 (ttymxc1) to talk with my reform. Fixed here:

https://source.mnt.re/reform/reform-system-image/-/merge_requests/46

Thanks again!

cheers, josch

signature.asc
Description: signature


Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-04-25 Thread Niko Tyni
On Wed, Apr 20, 2022 at 03:31:13PM +0100, Matthew Vernon wrote:

> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
> 
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
> 
> ===Begin Resolution N
> None of the above
> ===End Resolution N

Sorry for the delay.

I vote: A > N > B

-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature


Bug#1010154: libowasp-antisamy-java: CVE-2022-28366 + CVE-2022-28367

2022-04-25 Thread tony mancill
On Mon, Apr 25, 2022 at 07:22:12PM +0200, Salvatore Bonaccorso wrote:
> Hi!
> 
> On Mon, Apr 25, 2022 at 01:48:43PM +0100, Neil Williams wrote:
> > On Mon, 25 Apr 2022 13:39:49 +0100 Neil Williams  
> > wrote:
> > > Please note, the current homepage for libowasp-antisamy-java appears to
> > > have no commits beyond version 1.5.3 but the change for CVE-2022-29577
> > > does match the source code for libowasp-antisamy-java:
> > > https://sources.debian.org/src/libowasp-antisamy-java/1.5.3+dfsg-1.1/src/main/java/org/owasp/validator/html/scan/AntiSamyDOMScanner.java/?hl=410#L410
> > 
> > Apologies - that paragraph contains a typo - the matching change is for
> > CVE-2022-28367:
> > 
> > The fix in what looks like the new upstream is:
> > https://github.com/nahsra/antisamy/commit/0199e7e194dba5e7d7197703f43ebe22401e61ae
> 
> Could you please make sure to as well include
> https://github.com/nahsra/antisamy/commit/32e273507da0e964b58c50fd8a4c94c9d9363af0
> to make the fix complete.
> 
> Possibly it's best to just update to the new 1.6.7 upstream version.

Hello,

I have started working on the update to the latest upstream (1.6.8).
Updating will require a NEW package for:

  https://github.com/HtmlUnit/htmlunit-neko

(not to be confused with https://tracker.debian.org/pkg/nekohtml)

I believe that's the only missing package, but haven't yet assessed
htmlunit-neko to determine if there are other transitive dependencies.

Cheers,
tony


signature.asc
Description: PGP signature


Bug#1009208: ruby-i18n breaks ruby-faker autopkgtest: FrozenError: can't modify frozen Array

2022-04-25 Thread duck

Quack,

Indeed, I failed to see it was assigned to both, thanks for the fix.

\_o<

--
Marc Dequènes



Bug#826044: Hangs in apt hook with a zombie - problem still exists in debian10

2022-04-25 Thread zm5s-trnc

Poking around I found this, could there be a relationship ?

  ├─sshd,14441
  │   └─sh,14736 -c /usr/bin/python 
/root/.ansible/tmp/ansible-tmp-1650945060.61-15873-131215080055549/AnsiballZ_apt.py 
&& sleep 0
  │   └─python,14737 
/root/.ansible/tmp/ansible-tmp-1650945060.61-15873-131215080055549/AnsiballZ_apt.py
  │   └─aptitude,15251 -y -o Dpkg::Options::=--force-confdef -o 
Dpkg::Options::=--force-confold safe-upgrade
  │   ├─aptitude,21329 -y -o 
Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold 
safe-upgrade
  │   │   └─sh,21330 -c test -x 
/usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
  │   │   └─frontend,21331 -w 
/usr/share/debconf/frontend /usr/sbin/needrestart

  │   │   └─(needrestart,21335)
  │   └─{aptitude},15256


# /usr/sbin/needrestart
debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by 
another process: Resource temporarily unavailable


# lsof /var/cache/debconf/config.dat
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
frontend 21331 root    4uW  REG  254,2    31187 131278 
/var/cache/debconf/config.dat



A needrestart process is spawned but due to 
/var/cache/debconf/config.dat locked by frontend it is unable to process.

Of course may be unrelated.



Bug#944194: dput: Authenticated HTTP request raises AttributeError in Python >= 3.7

2022-04-25 Thread Ben Finney
Control: tags -1 + confirmed pending
Control: retitle -1 dput: Authenticated HTTP request raises AttributeError in 
Python >= 3.7
Control: summary -1 0

The ‘AuthHandlerHackAround’ class has fallen behind recent Python
implementation of ‘urllib.request.Request’ API. This causes users
expecting that API to crash with AttributeError.

On 05-Nov-2019, TQ Hirsch wrote:

> Uploading to hsg (via http to localhost:8123):
>   Uploading thequux-apt-config_2019.11.02.dsc: need authentication.
> Traceback (most recent call last):
>   File "/usr/bin/dput", line 11, in 
>     load_entry_point('dput==1.0.3', 'console_scripts', 'execute-dput')()
>   File "/usr/share/dput/dput/dput.py", line 1156, in main
>     files_to_upload, debug, 0, progress=progress)
>   File "/usr/share/dput/dput/methods/http.py", line 154, in upload
>     url, res.msg, pwman).get_auth_headers()
>   File "/usr/share/dput/dput/methods/http.py", line 82, in get_auth_headers
>     ah.http_error_401(self, None, 401, None, self.resp_headers)
>   File "/usr/lib/python3.7/urllib/request.py", line 1025, in http_error_401
>     url = req.full_url
> AttributeError: 'AuthHandlerHackAround' object has no attribute 'full_url'

The Python ‘urllib.request’ module is attempting to use an API not
implemented on ‘AuthHandlerHackAround’. I have implemented the changed
API on that fake class, and it will be part of the next ‘dput’ release.

Thank you for the report and analysis of the issue.

-- 
 \ “Whatever a man prays for, he prays for a miracle. Every prayer |
  `\   reduces itself to this: “Great God, grant that twice two be not |
_o__)   four.”” —Ivan Turgenev |
Ben Finney 


signature.asc
Description: PGP signature


Bug#976884: UDD: bug report title mangled to mojibake from valid UTF-8

2022-04-25 Thread Ben Finney
Control: retitle -1 UDD: bug report title mangled to mojibake from valid UTF-8

On 08-Dec-2020, Felix Lechner wrote:

> I had a very similar issue in Lintian's database a few weeks ago. It
> was caused by uploading (properly UTF-8 encoded) JSON to Postgres.
> The Perl driver DBD::Pg encoded the data again and picked the 7-bit
> clean escape sequences according to RFC4627, which is what I believe
> you are seeing. They are further described here:
> 
> https://metacpan.org/pod/JSON::PP#ascii
> 
> My solution was to disable the automatic decoding layer in DBD::Pg
> via 'pg_enable_utf8 => 0'. It mirrors how I handle encoding
> elsewhere (i.e. explicitly and without PerlIO, Bug#972878) and works
> great […]

Is the issue within DBD::Pg — should that Perl module default to
expecting UTF-8 text like most of the rest of Debian?


As another example, bug#1009426 has the valid UTF-8 title

 xkcdpass: FTBFS: test case raises “TypeError: … missing 1
 required positional argument: 'self'”

which is rendered correctly in bugs.debian.org web pages. But UDD
renders it as:

RC bug marked as done but still affects unstable: #1009426:
xkcdpass: FTBFS: test case raises �TypeError: � missing 1
required positional argument: 'self'�

-- 
 \ “Injustice is relatively easy to bear; what stings is justice.” |
  `\ —Henry L. Mencken |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature


Bug#977835: Please package the lastest version >= 3.5.2

2022-04-25 Thread Nicholas D Steeves
Hi Thorsten,

Thorsten Glaser  writes:

> John Scott dixit:
>
>>It's been a little while. Do you still plan on working on this?
>
> Yes, as time permits. I’m even keeping my ear on a possible
> inofficial (as the new Muse Group management is disinterested)
> 3.7 which is accumulating over a hundred fixes still. I’m
> still wary of the regressions relative to 3.2 though which
> I fear will require a nōntrivial amount of original work on
> my side.
>

Furthering our discussion on IRC, if necessary, I'm interested in
helping out with updating Musescore3 later this summer.  There is also
notable interest on IRC in #debian-quebec for seeing this package
updated :) and also sadness at being forced to use upstream's AppImage,
in cases where 3.2.3+dfsg2-11 proves insufficient.

In an earlier update you mentioned that there were numerous regressions
and problems with these new releases.  Are these limited to non-dfsg
components (such as instrument samples) that need to be replaced, and
are there too many problems that it would make sense listing them?
Would it be useful to start a Musescore team to divide the workload,
assuming that it's divisible?  I'm guessing it's something painful like
tracking down many non-dfsg things before being able to important the
new upstream orig.tar.

Regards,
Nicholas



signature.asc
Description: PGP signature


Bug#1010194: bullseye-pu: package distro-info-data/0.51+deb11u2

2022-04-25 Thread Stefano Rivera
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

As usual, a distro-info-data update.

[ Reason ]

This one only has Ubuntu changes, but still worth keeping up-to-date in
stable.

  * Update data to 0.53:
- Add Ubuntu 22.10, Kinetic Kudu.

[ Impact ]

Debian stable is unaware of the current Ubuntu development release:

$ ubuntu-distro-info -d
ubuntu-distro-info: Distribution data outdated.
Please check for an update for distro-info-data. See 
/usr/share/doc/distro-info-data/README.Debian for details.

[ Tests ]
Autopkgtests passed.

Manually tested:

$ ubuntu-distro-info -df
Ubuntu 22.10 "Kinetic Kudu"

[ Risks ]
Data-only package, this will bring it up to parity with unstable.

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

[ Changes ]

* Update data to 0.53:
  - Add Ubuntu 22.10, Kinetic Kudu.

[ Other info ]

Bug for the last update: #1001389
diff -Nru distro-info-data-0.51+deb11u1/debian/changelog 
distro-info-data-0.51+deb11u2/debian/changelog
--- distro-info-data-0.51+deb11u1/debian/changelog  2021-12-09 
09:40:48.0 -0400
+++ distro-info-data-0.51+deb11u2/debian/changelog  2022-04-25 
20:32:17.0 -0400
@@ -1,3 +1,10 @@
+distro-info-data (0.51+deb11u2) bullseye; urgency=medium
+
+  * Update data to 0.53:
+- Add Ubuntu 22.10, Kinetic Kudu.
+
+ -- Stefano Rivera   Mon, 25 Apr 2022 20:32:17 -0400
+
 distro-info-data (0.51+deb11u1) bullseye; urgency=medium
 
   * Update data to 0.52:
diff -Nru distro-info-data-0.51+deb11u1/ubuntu.csv 
distro-info-data-0.51+deb11u2/ubuntu.csv
--- distro-info-data-0.51+deb11u1/ubuntu.csv2021-12-09 09:40:48.0 
-0400
+++ distro-info-data-0.51+deb11u2/ubuntu.csv2022-04-25 20:32:17.0 
-0400
@@ -35,3 +35,4 @@
 21.04,Hirsute Hippo,hirsute,2020-10-22,2021-04-22,2022-01-20
 21.10,Impish Indri,impish,2021-04-22,2021-10-14,2022-07-14
 22.04 LTS,Jammy 
Jellyfish,jammy,2021-10-14,2022-04-21,2027-04-21,2027-04-21,2032-04-21
+22.10,Kinetic Kudu,kinetic,2022-04-21,2022-10-20,2023-07-20


Bug#1010193: buster-pu: package distro-info-data/0.41+deb10u5

2022-04-25 Thread Stefano Rivera
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

As usual, a distro-info-data update.

[ Reason ]

This one only has Ubuntu changes, but still worth keeping up-to-date in
stable.

   * Update data to 0.53, without new columns:
 - Add Ubuntu 22.04 LTS, Jammy Jellyfish.
 - Add Ubuntu 22.10, Kinetic Kudu.

[ Impact ]
Debian oldstable doesn't know the current development Ubuntu release:

$ ubuntu-distro-info -d
ubuntu-distro-info: Distribution data outdated.
Please check for an update for distro-info-data. See 
/usr/share/doc/distro-info-data/README.Debian for details.

Or the current LTS release:

$ ubuntu-distro-info -f --lts
Ubuntu 20.04 LTS "Focal Fossa"
$ ubuntu-distro-info -f -s
Ubuntu 21.10 "Impish Indri"

[ Tests ]
It's just a data package. There are automated tests for correctness.
The data was copied from the version uploaded to unstable.

Manually tested, and looks sane.

[ Risks ]
Negligible, it's two new entries in the Ubuntu releases table.

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

[ Changes ]

- Add Ubuntu 22.04 LTS, Jammy Jellyfish.
- Add Ubuntu 22.10, Kinetic Kudu.

[ Other info ]

Last update's bug: #987372
diff -Nru distro-info-data-0.41+deb10u4/debian/changelog 
distro-info-data-0.41+deb10u5/debian/changelog
--- distro-info-data-0.41+deb10u4/debian/changelog  2021-09-17 
18:30:21.0 -0400
+++ distro-info-data-0.41+deb10u5/debian/changelog  2022-04-25 
20:18:22.0 -0400
@@ -1,3 +1,11 @@
+distro-info-data (0.41+deb10u5) buster; urgency=medium
+
+  * Update data to 0.53, without new columns:
+- Add Ubuntu 22.04 LTS, Jammy Jellyfish.
+- Add Ubuntu 22.10, Kinetic Kudu.
+
+ -- Stefano Rivera   Mon, 25 Apr 2022 20:18:22 -0400
+
 distro-info-data (0.41+deb10u4) buster; urgency=medium
 
   * Update data to 0.51, without new columns:
diff -Nru distro-info-data-0.41+deb10u4/ubuntu.csv 
distro-info-data-0.41+deb10u5/ubuntu.csv
--- distro-info-data-0.41+deb10u4/ubuntu.csv2021-09-17 18:30:21.0 
-0400
+++ distro-info-data-0.41+deb10u5/ubuntu.csv2022-04-25 20:18:22.0 
-0400
@@ -34,3 +34,5 @@
 20.10,Groovy Gorilla,groovy,2020-04-23,2020-10-22,2021-07-22
 21.04,Hirsute Hippo,hirsute,2020-10-22,2021-04-22,2022-01-20
 21.10,Impish Indri,impish,2021-04-22,2021-10-14,2022-07-14
+22.04 LTS,Jammy Jellyfish,jammy,2021-10-14,2022-04-21,2027-04-21
+22.10,Kinetic Kudu,kinetic,2022-04-21,2022-10-20,2023-07-20


Bug#1010192: ModuleNotFoundError: No module named 'qrtools'

2022-04-25 Thread Christoph Anton Mitterer
Package: qtqr
Version: 2.1~bzr46-2
Severity: grave
Justification: renders package unusable


Hey.

On a fresh install of the package:
$ qtqr
Traceback (most recent call last):
  File "/usr/bin/qtqr", line 15, in 
from qrtools import QR
ModuleNotFoundError: No module named 'qrtools'


Thanks,
Chris.

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

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

Versions of packages qtqr depends on:
ii  python3-pyqt55.15.6+dfsg-1+b2
ii  python3-qrtools  2.1~bzr46-2

qtqr recommends no packages.

qtqr suggests no packages.

-- no debconf information



Bug#1009858: linux: please consider building the modules necessary for the MNT Reform laptop

2022-04-25 Thread Vagrant Cascadian
On 2022-04-24, Vagrant Cascadian wrote:
> On 2022-04-19, Johannes Schauer Marin Rodrigues wrote:
>> currently, we add the following to the arm64 kernel config provided by
>> the Debian kernel packaging to build a kernel that powers the MNT Reform
>> 2 open source laptop:
>
> Thanks!
>
> Merged most of the changes so far except...

Which I can confirm boots!  Although no output on the LCD, just serial
console...


>> CONFIG_DRM_CDNS_HDMI_CEC=m
>> CONFIG_DRM_IMX_CDNS_MHDP=m
>
> These are not yet in upstream 5.17.x, so I left them out.

Presumably LCD and HDMI don't work due to missing those, and/or other
not-yet-upstream patches...


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1010189: fs-uae-launcher is broken in Sid

2022-04-25 Thread Miguel A. Vallejo
Thank you for the info.

Feel free to close the bug if you think it is a duplicate of 1010048

Greetings



Bug#1010191: xkcdpass: Option ‘--wordlist’ help text fails to mention the wordfile is ignored if missing

2022-04-25 Thread Ben Finney
Control: tags -1 + upstream
Control: forwarded -1 
https://github.com/redacted/XKCD-password-generator/issues/147
Control: severity -1 minor

On 20-Apr-2019, Ben Finney wrote:

> I suspect this is because the program silently skips a specified
> wordfile if it does not exist.

The documentation for ‘--wordlist’ does not describe this behaviour. I
have created an upstream bug report for this.

-- 
 \“I don't accept the currently fashionable assertion that any |
  `\   view is automatically as worthy of respect as any equal and |
_o__)   opposite view.” —Douglas Adams |
Ben Finney 


signature.asc
Description: PGP signature


Bug#926696: xkcdpass: Should notify user when wordlist file not found

2022-04-25 Thread Ben Finney
Control: tags -1 - moreinfo upstream
Control: severity -1 wishlist

On 20-Apr-2019, Ben Finney wrote:

> I suspect this is because the program silently skips a specified
> wordfile if it does not exist. It then has a set of wordfiles that
> includes the defaults, but does not include the one you specified.

Yes, this is definitely how the ‘--wordlist’ behaviour is defined: it
specifies a wordlist file to use, but if the file does not exist it
silently defaults to the built-in wordlist.

(The documentation for the ‘--wordlist’ option does not describe that
behaviour. I have created bug report #1010191 to change the
documentation.)

So this bug report is effectively a “Severity: wishlist” request to
change that behaviour. I am modifying this bug report accordingly.

-- 
 \  “Very few things happen at the right time, and the rest do not |
  `\ happen at all. The conscientious historian will correct these |
_o__)  defects.” —Mark Twain, _A Horse's Tale_ |
Ben Finney 


signature.asc
Description: PGP signature


Bug#1010189: fs-uae-launcher is broken in Sid

2022-04-25 Thread John Paul Adrian Glaubitz
Control: severity -1 normal
Control: forcemerge 1010048 -1

Hello!

On 4/26/22 00:44, Miguel A. Vallejo wrote:
> FS-UAE-Launcher in Debian Sid is now broken. It opens with a totally
> corrupted window and the terminal outputs a ton of errors.

fs-uae-launcher is not part of Debian unstable. It's available in stable only
at the moment. Please see the explanation for the reasons here [1].

Adrian

> [1] http://bugs.debian.org/1010048

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



Bug#1010190: make: manual has broken spacing in jobserver section

2022-04-25 Thread наб
Package: make
Version: 4.3-4.1
Severity: minor

Dear Maintainer,

Please consider the attached patch (based on current Salsa HEAD
(484dd2fed4e19b092719394bc5333b2fc64a1b27)), which fixes the broken
spacing in the PARALLEL MAKE AND THE JOBSERVER section.

Best,
наб

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

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

Versions of packages make depends on:
ii  libc6  2.31-13+deb11u3

make recommends no packages.

Versions of packages make suggests:
pn  make-doc  

-- no debconf information
From a7e11e35c7a89f1d37473f8d88d8c13eb3359cb8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Tue, 26 Apr 2022 00:51:03 +0200
Subject: [PATCH] Fix spacing errors in make.1
X-Mutt-PGP: OS

---
 make.1 | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/make.1 b/make.1
index d4b5fbab..b813f0d3 100644
--- a/make.1
+++ b/make.1
@@ -206,7 +206,7 @@ Internal option
 .BR make
 uses to pass the jobserver pipe read and write file descriptor numbers
 to
-.BR sub-makes;
+.BR sub-makes ;
 see the section
 .B PARALLEL MAKE AND THE JOBSERVER
 for details
@@ -389,8 +389,8 @@ When the build environment is such that a top level
 invokes
 .BR sub-makes
 (for instance, a style in which each sub-directory contains its own
-.I Makefile
-), no individual instance of
+.IR Makefile ),
+no individual instance of
 .BR make
 knows how many tasks are running in parallel, so keeping the number of
 tasks under the upper limit would be impossible without communication
@@ -405,17 +405,18 @@ created, the current implementation uses a simple shared pipe.
 This pipe is created by the top-level
 .BR make
 process, and passed on to all the
-.BR sub-makes.
+.BR sub-makes .
 The top level
-.BR make process writes
+.B make
+process writes
 .B N-1
 one-byte tokens into the pipe (The top level
 .BR make
 is assumed to reserve one token for itself). Whenever any of the
 .BR make
 processes (including the top-level
-.BR make
-) needs to run a new task, it reads a byte from the shared pipe. If
+.BR make )
+needs to run a new task, it reads a byte from the shared pipe. If
 there are no tokens left, it must wait for a token to be written back
 to the pipe. Once the task is completed, the
 .BR make
@@ -434,7 +435,7 @@ then
 .BR make
 will close the jobserver pipe file descriptors before invoking the
 commands, so that the command can not interfere with the
-.I jobserver,
+.IR jobserver ,
 and the command does not find any unusual file descriptors.
 .SH BUGS
 See the chapter ``Problems and Bugs'' in
-- 
2.30.2



signature.asc
Description: PGP signature


Bug#1010189: fs-uae-launcher is broken in Sid

2022-04-25 Thread Miguel A. Vallejo
Package: fs-uae-launcher
Version: 3.0.5+dfsg-1
Severity: grave

FS-UAE-Launcher in Debian Sid is now broken. It opens with a totally
corrupted window and the terminal outputs a ton of errors.

I suspect the problem is now that PYQT5 does not accept floats
anymore. I also noticed the available version of fs-uae-launcher in
Debian is quite outdated.

Thanks in advance.

Error dump running fs-uae-launcher from terminal:

Unhandled exception detected in thread MainThread:
  TypeError:widget.py:set_position_and_size:160

Traceback (most recent call last):
  File "/usr/share/fs-uae-launcher/fsui/qt/Panel.py", line 117, in showEvent
self.owner().on_resize()
  File "/usr/share/fs-uae-launcher/fsui/qt/widget.py", line 203, in on_resize
self.layout.set_size(self.get_size())
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 181, in set_size
self.update()
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 310, in update
child.element.set_position_and_size(position, size)
  File "/usr/share/fs-uae-launcher/fsui/qt/widget.py", line 160, in
set_position_and_size
self.widget().setGeometry(position[0], position[1], size[0], size[1])
TypeError: arguments did not match any overloaded call:
  setGeometry(self, QRect): argument 1 has unexpected type 'int'
  setGeometry(self, int, int, int, int): argument 2 has unexpected type 'float'


Unhandled exception detected in thread MainThread:
  TypeError:widget_mixin.py:set_position_and_size:195

Traceback (most recent call last):
  File "/usr/share/fs-uae-launcher/fsui/qt/Panel.py", line 117, in showEvent
self.owner().on_resize()
  File "/usr/share/fs-uae-launcher/fsui/qt/widget.py", line 203, in on_resize
self.layout.set_size(self.get_size())
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 181, in set_size
self.update()
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 310, in update
child.element.set_position_and_size(position, size)
  File "/usr/share/fs-uae-launcher/fsui/common/group.py", line 52, in
set_position_and_size
self.layout.set_position_and_size(position, size)
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 186,
in set_position_and_size
self.update()
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 310, in update
child.element.set_position_and_size(position, size)
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 186,
in set_position_and_size
self.update()
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 310, in update
child.element.set_position_and_size(position, size)
  File "/usr/share/fs-uae-launcher/fsui/qt/widget_mixin.py", line 195,
in set_position_and_size
widget.move(*position)
TypeError: arguments did not match any overloaded call:
  move(self, QPoint): argument 1 has unexpected type 'int'
  move(self, int, int): argument 2 has unexpected type 'float'


Unhandled exception detected in thread MainThread:
  TypeError:widget.py:set_position_and_size:160

Traceback (most recent call last):
  File "/usr/share/fs-uae-launcher/fsui/qt/Panel.py", line 117, in showEvent
self.owner().on_resize()
  File "/usr/share/fs-uae-launcher/fsui/qt/widget.py", line 203, in on_resize
self.layout.set_size(self.get_size())
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 181, in set_size
self.update()
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 310, in update
child.element.set_position_and_size(position, size)
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 186,
in set_position_and_size
self.update()
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 310, in update
child.element.set_position_and_size(position, size)
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 186,
in set_position_and_size
self.update()
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 310, in update
child.element.set_position_and_size(position, size)
  File "/usr/share/fs-uae-launcher/fsui/qt/widget.py", line 160, in
set_position_and_size
self.widget().setGeometry(position[0], position[1], size[0], size[1])
TypeError: arguments did not match any overloaded call:
  setGeometry(self, QRect): argument 1 has unexpected type 'int'
  setGeometry(self, int, int, int, int): argument 2 has unexpected type 'float'


Unhandled exception detected in thread MainThread:
  TypeError:widget.py:set_position_and_size:160

Traceback (most recent call last):
  File "/usr/share/fs-uae-launcher/fsui/qt/Panel.py", line 120, in resizeEvent
self.owner().on_resize()
  File "/usr/share/fs-uae-launcher/fsui/qt/widget.py", line 203, in on_resize
self.layout.set_size(self.get_size())
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 181, in set_size
self.update()
  File "/usr/share/fs-uae-launcher/fsui/common/layout.py", line 310, in update
child.element.set_position_and_size(position, size)
  File "/usr/share

Bug#1010091: Debian riscv64 unstable dockerhub image - libxml2 depends.

2022-04-25 Thread Tianon Gravi
On Sun, 24 Apr 2022 at 02:24, Radim Kohout  wrote:
> Package: docker

Unfortunately, this isn't really filed in the right place -- this is
the bug tracker for https://tracker.debian.org/pkg/docker which is an
old WindowMaker app.

>From https://hub.docker.com/_/debian, what you're looking for is
https://github.com/debuerreotype/docker-debian-artifacts/issues.

> I am trying to use Debian unstable riscv64 in docker, but while installing 
> libxml2, I am getting the following error:
> libxml2 : Depends: libicu67 (>= 67.1-1~) but it is not installable

If you look at https://tracker.debian.org/pkg/libxml2, you can see
that libxml2 is part of the "icu" transition, which is consistent with
the error message you're getting.  Once that transition is completed,
that issue should resolve itself.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4



Bug#1010188: NIS not actually removed in 1.4.0-12

2022-04-25 Thread Josh Triplett
Source: pam
Version: 1.4.0-11
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

When I upgraded to 1.4.0-12, I noticed that the dependencies didn't seem
to change, and the package still pulled in NIS libraries. As far as I
can tell from the git repository, the only thing that changed in
1.4.0-12 was the changelog. Diffstats:

commit f77e0c7cc0200911ffdc1e95032488072ad2ed15
Author: Steve Langasek 
Date:   Mon Apr 25 11:33:31 2022 -0700

releasing package pam version 1.4.0-12

 debian/changelog | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

commit b36d84ca59e4cf29f12ff37f7f820ce3bc1625d5
Author: Steve Langasek 
Date:   Mon Apr 25 11:33:24 2022 -0700

Don't build with NIS support.  This is only used for password changes on 
NIS systems, and is pulling a large dependency chain into the Essential package 
set which is not justifiable.

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


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

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



Bug#1010187: RFS: opencpn/5.6.2+dfsg-1 -- Open Source Chartplotter and Marine GPS Navigation Software

2022-04-25 Thread Alec Leamas

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opencpn
   Version : 5.6.2+dfsg-1
   Upstream Author : Dave S. Register 
 * URL : https://opencpn.org
 * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, 
GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0

 * Vcs : https://gitlab.com/leamas/opencpn
   Section : misc

The source builds two binary packages:

  opencpn - Open Source Chartplotter and Marine GPS Navigation Software
  opencpn-data - Open Source Chartplotter and Marine GPS Navigation 
Software (data)


More info:  https://mentors.debian.net/package/opencpn/ or using

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1.dsc


This is a bugfix upstream release, basically without any new 
functionality. Changes since the last upload:


 opencpn (5.6.2+dfsg-1) unstable; urgency=medium
 .
   * New upstream release.
   * Remove upstream debian packaging in source tarball.
   * Add patch for wrong desktop filename (tracker.debian.org warning).
   * d/rules: Add explicit CMAKE_BUILD_TYPE setting (upstream
 discussion in https://github.com/OpenCPN/OpenCPN/issues/2612)
   * d/watch: dfsg1 -> dfsg (lintian warning)
   * d/control: Add missing -b branch to Vcs-Git:
   * d/control: Make opencpn-data Multi-arch: foreign
 (tracker.debian.org warning).
   * d/copyright: Remove unused GPL-2 license.

Regards,
--
  Alec Leamas



Bug#1006783: tcpreplay: Please consider compiling with libdumbnet in order to enable the fragroute feature

2022-04-25 Thread Christoph Biedl
Control: tag 1006783 confirmed

Florian Ernst wrote...

(...)
> Please consider whether it's worthwhile to include libdumbnet support
> into tcpreplay, thanks.

Hello, and sorry for taking so long to respond.

Still, you suggestion seems sensible to include, I'll re-visit when it
comes to another upload - which shouldn't too far away.

Regards,

Christoph


signature.asc
Description: PGP signature


Bug#1010048: fs-uae-launcher: GUI is corrupted.

2022-04-25 Thread waxhead

John Paul Adrian Glaubitz wrote:

Control: severity -1 normal

On 4/23/22 09:26, waxhead wrote:

Tried to start fs-uae-launcher, the GUI looks "corrupted" like below...

++
|[start] [][][]  |
||
|+-+ |
|[cfgwindow] |
|| | |
|+-+ |
++

A start button, a config windows and some widgets overlapping [][][].
(...)
-- System Information:
Debian Release: bookworm/sid
   APT prefers testing
   APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386


fs-uae-launcher is currently not part of Debian unstable or testing due to 
insufficient
clarification of the copyright of various files shipped with the source code, 
see [1].

However, the package is part of the stable distribution and works fine there, 
just tested
it on a freshly installed system. Thus, you are using the stable package on 
Debian testing
which may result the bug you described.

But since the package isn't part of testing/unstable anyway, I don't really 
consider this
to be a valid bug report. Therefore downgrading the severity to normal.

Adrian


[1] https://github.com/FrodeSolheim/fs-uae-launcher/issues/143


Allrighty , that is fair enough. Have to cross our fingers that an 
update is near then.




Bug#1010153: nmh: Please replace mime-support with media-types in Depends

2022-04-25 Thread Alexander Zangerl
On Mon, 25 Apr 2022 21:36:40 +0900, Charles Plessy writes:
>May I ask you to replace mime-support with media-types in nmh's Depends ?

sure, i'll update that on the next build.




-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, E-Learning: 
 Feststellung, daß Strom weh tut. -- Oliver Schad


signature.asc
Description: Digital Signature


Bug#995838: [htcondor-debian] Bug#995838: Should condor be removed?

2022-04-25 Thread Moritz Mühlenhoff
Am Fri, Oct 29, 2021 at 01:36:27PM + schrieb Tim Theisen:
> I plan to upload a new version this weekend.

Did you make progress with updating condor?

Cheers,
Moritz



Bug#1008285: Should zorp be removed?

2022-04-25 Thread Moritz Mühlenhoff
severity 1008285 normal
reassign 1008285 ftp.debian.org
retitle 1008285 RM:  -- RoM; Depends on Python 2
thanks

Am Fri, Mar 25, 2022 at 11:30:26PM +0100 schrieb Moritz Muehlenhoff:
> Source: zorp
> Version: 7.0.1~alpha2-3
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> 
> - Last upload in 2019, removed from testing since 2017
> - Still depends on Python 2.7 and thus RC-buggy
> 
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
> 
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
> 
> Otherwise I'll move forward and request it's removal in a month.

Reassigning for removal.



Bug#1008272: Should postnews be removed?

2022-04-25 Thread Moritz Mühlenhoff
severity 1008272 normal
reassign 1008272 ftp.debian.org
retitle 1008272 RM:  -- RoM; depends on Python 2, unmaintained
thanks

Am Fri, Mar 25, 2022 at 08:57:50PM +0100 schrieb Moritz Muehlenhoff:
> Source: postnews
> Version: 0.7-1
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> 
> - Removed from testing for ~ two years, no followup to RC bugs
> - Also no changes upstream since 2017
> 
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
> 
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
> 
> Otherwise I'll move forward and request it's removal in a month.

Reassigning for removal.



Bug#1008852: Please close request

2022-04-25 Thread Kenneth Finnegan
Howdy,

Please close this request to add a new mirror. The ftpsync tool is a
pain to hack into our pipeline, and given the indication of a lack of
need for additional mirrors for Debian we would rather not deal with
the exception in our update scripts.
--
Kenneth Finnegan
Technical Director, FCIX



Bug#814382: RFA: samba -- SMB/CIFS file, print, and login server for Unix

2022-04-25 Thread Michael Tokarev

Control: tag -1 + pending

So, should we add something like "pending" tag to this bug? ;)
I'm in the process of helping with samba package maintenance
for quite some time now... ;))

I come across this bug report because it popped up in tracker.d.o
page for another package I maintain, with a warning "depends on
a package which needs a new maintainer..".. :)

/mjt



Bug#1010186: gnome-text-editor: Segfault when closing

2022-04-25 Thread Jeremy Bicha
On Mon, Apr 25, 2022 at 4:27 PM Michel Le Bihan  wrote:
> Package: gnome-text-editor
> Version: 42.1-1
>
> gnome-text-editor segfaults when closing the app in the GUI

Does that bug happen with gnome-text-editor 42.1-1 ? I'm asking
because that version was supposed to fix a similar issue.

Thank you,
Jeremy Bicha



Bug#1010186: gnome-text-editor: Segfault when closing

2022-04-25 Thread Michel Le Bihan
Package: gnome-text-editor
Version: 42.1-1
Severity: important
X-Debbugs-Cc: mic...@lebihan.pl

Dear Maintainer,

gnome-text-editor segfaults when closing the app in the GUI

#0  0x5558bda7 in editor_session_save_for_shutdown_cb 
(object=, result=, user_data=)
at ../src/editor-session.c:1001
#1  0x77d15e49 in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#2  0x77d15e89 in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#3  0x77b1de94 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77b1e238 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x77b1e2ef in g_main_context_iteration () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x77d4582d in g_application_run () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#7  0x5556ac88 in main (argc=1, argv=0x7fffde38) at ../src/main.c:42


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

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

Versions of packages gnome-text-editor depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libadwaita-1-0   1.1.0-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libenchant-2-2   2.3.2-1
ii  libglib2.0-0 2.72.1-1
ii  libgtk-4-1   4.6.2+ds-1
ii  libgtksourceview-5-0 5.4.1-3
ii  libicu71 71.1-2
ii  libpango-1.0-0   1.50.6+ds-2
ii  libpcre3 2:8.39-14

gnome-text-editor recommends no packages.

gnome-text-editor suggests no packages.

-- no debconf information



Bug#1010185: calibre: FTBFS on mips64el

2022-04-25 Thread Sebastian Ramacher
Source: calibre
Version: 5.41.0+dfsg-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

calibre FTBFS on mips64el:

test_zeroconf (calibre.test_build.BuildTest) ... ok [0.0 s]

==
ERROR: test_dom_load 
(calibre.scraper.simple.find_tests..TestSimpleWebEngineScraper)
--
Traceback (most recent call last):
  File "/<>/src/calibre/scraper/simple.py", line 155, in 
test_dom_load
html = overseer.fetch_url(url, 'test')
  File "/<>/src/calibre/scraper/simple.py", line 87, in fetch_url
raise ValueError(output['err'])
ValueError: Failed to load HTML from: 
file:///<>/resources/templates/new_book.html

--
Ran 313 tests in 431.403s

FAILED (errors=1, skipped=11)
make[3]: *** [debian/rules:48: calibre_auto_test] Error 1

See 
https://buildd.debian.org/status/fetch.php?pkg=calibre&arch=mips64el&ver=5.41.0%2Bdfsg-1&stamp=1650830959&raw=0

Cheers
-- 
Sebastian Ramacher



Bug#1010184: miller: Parse error on token "1e+"

2022-04-25 Thread Kingsley G. Morse Jr.
Package: miller
Version: 6.2.0-1
Severity: normal

Hi Stephen,

Thanks again for maintaining a convenient Debian
package of John Kerl's cool "mlr".

I happened to notice mlr doesn't seem to recognize
numbers in scientific notation with explicitly
positive exponents.

Since awk seems to work with them, I 

thought you and maybe John would want to know,
and 

filed this bug report.

Here are some simple examples that I hope will
also reveal the bug on your computer:

$ echo | mlr put 'print 1e+0'

On my computer, mlr complains with:

mlr: cannot parse DSL expression.
Parse error on token "1e+" at line 1 column 7.
Please check for missing semicolon.
Expected one of:
  $ ; { > >> | ( field_name $[ braced_field_name $[[ $[[[ full_srec 
oosvar_name
  @[ braced_oosvar_name full_oosvar all non_sigil_name float int + - .+ .-
  ! ~ string_literal regex_case_insensitive int_literal float_literal 
boolean_literal
  null_literal inf_literal nan_literal const_M_PI const_M_E panic [ ctx_IPS
  ctx_IFS ctx_IRS ctx_OPS ctx_OFS ctx_ORS ctx_FLATSEP ctx_NF ctx_NR ctx_FNR
  ctx_FILENAME ctx_FILENUM env func

I'm happy to report a workaround is simply
omitting the positive "+" sign before the exponent
like this:

$ echo | mlr put 'print 1e0'

At least on my computer, mlr returns

1e0

For what it's worth, here's an analogous example
with the great grand daddy of csv tools, awk:

$ echo | awk '{ print 1e+0 }

At least on my computer, awk returns

1

If I understand the following link correctly, John
originally implemented scientific notation in DSL
literals back in version 3.0.1:

Allow scientific notation in DSL literals; mlr bar --auto
https://github.com/johnkerl/miller/releases/tag/v3.0.1

Thanks again,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

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

miller recommends no packages.

miller suggests no packages.

-- no debconf information



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

2022-04-25 Thread Salvatore Bonaccorso
Hi Arthur,

On Fri, Feb 18, 2022 at 07:11:24PM -0800, Ryan Tandy wrote:
> Hi Arthur,
> 
> sorry for the long delayed followup.
> 
> On Sun, Nov 14, 2021 at 04:20:03PM +0100, Arthur de Jong wrote:
> > > However the test_pamcmds script fails with the new version. The login
> > > with the correct password fails, the issue seems to be (from
> > > nslcd.log):
> > > 
> > > nslcd: [a88611]  DEBUG: got 
> > > LDAP_CONTROL_PASSWORDPOLICYRESPONSE (Password must be changed)
> > > nslcd: [a88611]  DEBUG: 
> > > myldap_search(base="cn=Veronica 
> > > Sefcovic+uid=vsefcovic,ou=lotsofpeople,dc=test,dc=tld", 
> > > filter="(objectClass=*)")
> > > nslcd: [a88611]  ldap_result() failed: Insufficient 
> > > access: Operations are restricted to bind/unbind/abandon/StartTLS/modify 
> > > password
> > > 
> > > Still looking into it, not sure why the new ppolicy wants the
> > > password changed after it was just reset earlier.
> > 
> > Do you know at which step this failed in the test_pamcmds test? In
> > general I found ppolicy controls during authentication to be somewhat
> > confusing, especially when a password was about to expire or needed to
> > be changed.
> 
> It failed on "testing correct password".
> 
> I think the behaviour change is due to ITS#7084:
> 
> https://bugs.openldap.org/show_bug.cgi?id=7084
> https://git.openldap.org/openldap/openldap/-/commit/376d5d65cb4d622abdd4bba250c80250e56dc4d8
> 
> With OpenLDAP 2.5, when the user's password is changed in reset_password(),
> they get pwdReset: TRUE added, because the policy has pwdMustChange: TRUE
> and the change is done by the administrator. Exactly like you said, the bind
> succeeds but then the search is not permitted. I can't remember whether
> nss-pam-ldapd is supposed to show a "password must be changed now" prompt in
> this case?
> 
> With OpenLDAP 2.4, I think pwdMustChange is consulted only when binding.  I
> think the user is forced to change their password only if pwdMustChange and
> pwdReset are both set.
> 
> I removed "pwdMustChange: TRUE" from the policy and then the tests passed.
> Not sure if this is the correct fix, but at least I don't currently see
> anything in test_pamcmds.expect that would be expecting a forced reset?

Are there any news on this bug? nss-pam-ldapd is currently hinted for
removal from testing due to this bug (not happened yet though).

Regards,
Salvatore



Bug#1010183: freetype: CVE-2022-27404 CVE-2022-27405 CVE-2022-27406

2022-04-25 Thread Salvatore Bonaccorso
Source: freetype
Version: 2.11.1+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for freetype.

CVE-2022-27404[0]:
| FreeType commit 1e2eb65048f75c64b68708efed6ce904c31f3b2f was
| discovered to contain a heap buffer overflow via the function
| sfnt_init_face.


CVE-2022-27405[1]:
| FreeType commit 53dfdcd8198d2b3201a23c4bad9190519ba918db was
| discovered to contain a segmentation violation via the function
| FNT_Size_Request.


CVE-2022-27406[2]:
| FreeType commit 22a0cccb4d9d002f33c1ba7a4b36812c7d4f46b5 was
| discovered to contain a segmentation violation via the function
| FT_Request_Size.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-27404
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27404
[1] https://security-tracker.debian.org/tracker/CVE-2022-27405
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27405
[2] https://security-tracker.debian.org/tracker/CVE-2022-27406
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27406

Regards,
Salvatore



Bug#1010182: kexec-tools FTCBFS for x86: uses the build architecture strip

2022-04-25 Thread Helmut Grohne
Source: kexec-tools
Version: 1:2.0.24-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kexec-tools fails to cross build from source when building on non-x86 to
some x86, because it the builds kexec_tests, which happens to hard code
the build architecture strip. Please consider applying the attached
patch to use the correctly detected strip.

Helmut
--- kexec-tools-2.0.24.orig/kexec_test/Makefile
+++ kexec-tools-2.0.24/kexec_test/Makefile
@@ -36,6 +36,6 @@
 $(KEXEC_TEST): $(KEXEC_TEST_OBJS)
 	mkdir -p $(@D)
 	$(TARGET_LD) $(LDFLAGS) -o $@ $^
-	strip $@
+	$(STRIP) $@
 
 endif


Bug#1010181: xevil FTCBFS: hard codes the build architecture compiler

2022-04-25 Thread Helmut Grohne
Source: xevil
Version: 2.02r2-10.3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xevil fails to cross build from source, because an upstream Makefile
forces the build architecture compiler g++. The attached patch makes the
compiler subtitutable and xevil cross buildable. Please consider
applying it.

Helmut
--- xevil-2.02r2.orig/config.mk
+++ xevil-2.02r2/config.mk
@@ -257,7 +257,7 @@
 
 #For debian-linux
 debian-linux:
-	@$(MAKE) CC="g++" \
+	@$(MAKE) CC="$(CXX)" \
 CFLAGS="-DUSE_RANDOM -DXEVIL_KEYSET=UIlinux -DUSE_UINT_NET_LENGTH" \
 INCL_DIRS="-I/usr/X11R6/include" \
 LIBS_DIRS="-L/usr/X11R6/lib" \


Bug#992108: ansible-pygments: changing from ITP to RFP

2022-04-25 Thread Sakirnth Nagarasa
retitle -1 RFP: ansible-pygments -- tools for building the ansible
distribution
noowner -1
thanks

Hi,

I have not enough time to package this package. Because it is just
relevant for a doc binary package. Therefore I submit it to RFP.

Cheers,
Saki



Bug#1010180: ktexteditor: CVE-2022-23853

2022-04-25 Thread Salvatore Bonaccorso
Source: ktexteditor
Version: 5.90.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ktexteditor.

CVE-2022-23853[0]:
| The LSP (Language Server Protocol) plugin in KDE Kate before 21.12.2
| and KTextEditor before 5.91.0 tries to execute the associated LSP
| server binary when opening a file of a given type. If this binary is
| absent from the PATH, it will try running the LSP server binary in the
| directory of the file that was just opened (due to a misunderstanding
| of the QProcess API, that was never intended). This can be an
| untrusted directory.


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-23853
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23853
[1] https://kde.org/info/security/advisory-20220131-1.txt
[2] https://commits.kde.org/ktexteditor/804e49444c093fe58ec0df2ab436565e50dc147e
[3] https://commits.kde.org/ktexteditor/c80f935c345de2e2fb10635202800839ca9697bf

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#1010179: haskell-devscripts: DEB_ENABLE_TESTS broken

2022-04-25 Thread Scott Talbert
Package: haskell-devscripts
Version: 0.16.11
Severity: normal

After the recent port from shell to Perl, Setting DEB_ENABLE_TESTS=yes 
in debian/rules does not cause the tests to be executed during build.  
This error message is seen during builds:

Use of uninitialized value $ENV{"DEB_ENABLE_TESTS"} in string ne at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 671.
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called 
at -e line 1
DEB_ENABLE_TESTS not set to yes, not running any build-time tests.



Bug#1010178: ruby-dev: pkg-config: -I triggers system header warnings from Clang

2022-04-25 Thread Alejandro Colomar
Package: ruby-dev
Version: 1:2.7+2
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

I'm getting warnings from ruby system headers, and I see that the pkg-config
file included with the package is using `-I` instead of `-isystem`.

$ cat ruby.c
#include 

int
main(void)
 {
static const char *argv[3] = {
"NGINX_Unit", "-rrbconfig",
"-eprint RbConfig::CONFIG['libdir']"
};

RUBY_INIT_STACK;
ruby_init();
return ruby_run_node(ruby_options(3, (char **) argv));
 }


$ pkg-config --cflags ruby
-I/usr/include/x86_64-linux-gnu/ruby-2.7.0 -I/usr/include/ruby-2.7.0


$ clang ruby.c $(pkg-config --cflags --libs ruby)
In file included from ruby.c:1:
In file included from /usr/include/ruby-2.7.0/ruby.h:33:
/usr/include/ruby-2.7.0/ruby/ruby.h:1863:1: warning: unknown attribute 
'__error__' ignored [-Wunknown-attributes]
ERRORFUNC((" argument length doesn't match"), int 
rb_varargs_bad_length(int,int));
^
/usr/include/x86_64-linux-gnu/ruby-2.7.0/ruby/config.h:153:43: note: expanded 
from macro 'ERRORFUNC'
#define ERRORFUNC(mesg,x) __attribute__ ((__error__ mesg)) x
  ^


I suggest using -isystem instead of -I to silence the warnings (and also,
to fix the warnings themselves, but I'll report those upstream directly).


Thanks,

Alex


-- 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.10.0-13-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-dev depends on:
ii  ruby2.7-dev  2.7.4-1+deb11u1

ruby-dev recommends no packages.

ruby-dev suggests no packages.

-- no debconf information



Bug#1010177: r8168-dkms: dkms build failed on kernel 5.17

2022-04-25 Thread Alexey Morsov
Package: r8168-dkms
Version: 8.049.02-1
Severity: grave
Tags: ftbfs
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

update linux-image to 5.17

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

apt full-upgrade

   * What was the outcome of this action?

r8168-dkms does not build for this version of kernel


   * What outcome did you expect instead?

working ethernet driver


dkms log

DKMS make.log for r8168-8.049.02 for kernel 5.17.0-1-amd64 (x86_64)
Пн 25 апр 2022 21:33:59 MSK
make: вход в каталог «/usr/src/linux-headers-5.17.0-1-amd64»
  CC [M]  /var/lib/dkms/r8168/8.049.02/build/r8168_n.o
  CC [M]  /var/lib/dkms/r8168/8.049.02/build/r8168_asf.o
  CC [M]  /var/lib/dkms/r8168/8.049.02/build/rtl_eeprom.o
  CC [M]  /var/lib/dkms/r8168/8.049.02/build/rtltool.o
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c: In function ‘rtl8168_proc_open’:
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:1736:50: error: implicit
declaration of function ‘PDE_DATA’; did you mean ‘NODE_DATA’?
[-Werror=implicit-function-declaration]
 1736 | int (*show)(struct seq_file *, void *) = PDE_DATA(inode);
  |  ^~~~
  |  NODE_DATA
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:1736:50: warning: initialization
of ‘int (*)(struct seq_file *, void *)’ from ‘int’ makes pointer from integer
without a cast [-Wint-conversion]
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c: In function
‘rtl8168_get_mac_address’:
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:24136:34: error: assignment of
read-only location ‘*(dev->dev_addr + (sizetype)i)’
24136 | dev->dev_addr[i] = RTL_R8(tp, MAC0 + i);
  |  ^
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c: In function
‘rtl8168_set_mac_address’:
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:24167:19: warning: passing
argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type
[-Wdiscarded-qualifiers]
24167 | memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
  |~~~^~
In file included from /usr/src/linux-
headers-5.17.0-1-common/include/linux/string.h:253,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/bitmap.h:11,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/cpumask.h:12,
 from /usr/src/linux-
headers-5.17.0-1-common/arch/x86/include/asm/cpumask.h:5,
 from /usr/src/linux-
headers-5.17.0-1-common/arch/x86/include/asm/msr.h:11,
 from /usr/src/linux-
headers-5.17.0-1-common/arch/x86/include/asm/processor.h:22,
 from /usr/src/linux-
headers-5.17.0-1-common/arch/x86/include/asm/timex.h:5,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/timex.h:65,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/time32.h:13,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/time.h:60,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/stat.h:19,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/module.h:13,
 from /var/lib/dkms/r8168/8.049.02/build/r8168_n.c:43:
/usr/src/linux-headers-5.17.0-1-common/include/linux/fortify-string.h:212:37:
note: expected ‘void *’ but argument is of type ‘const unsigned char *’
  212 | __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t
size)
  |   ~~^
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:24169:32: warning: passing
argument 2 of ‘rtl8168_rar_set’ discards ‘const’ qualifier from pointer target
type [-Wdiscarded-qualifiers]
24169 | rtl8168_rar_set(tp, dev->dev_addr);
  | ~~~^~
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:566:59: note: expected ‘uint8_t *’
{aka ‘unsigned char *’} but argument is of type ‘const unsigned char *’
  566 | void rtl8168_rar_set(struct rtl8168_private *tp, uint8_t *addr);
  |  ~^~~~
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c: In function ‘rtl8168_resume’:
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:28654:32: warning: passing
argument 2 of ‘rtl8168_rar_set’ discards ‘const’ qualifier from pointer target
type [-Wdiscarded-qualifiers]
28654 | rtl8168_rar_set(tp, dev->dev_addr);
  | ~~~^~
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:24184:26: note: expected ‘uint8_t
*’ {aka ‘unsigned char *’} but argument is of type ‘const unsigned char *’
24184 | uint8_t *addr)
  | ~^~~~
cc1: some warnings being treated as errors


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

Bug#1010176: node-send: Depends: node-statuses (< 2) but 2.0.1+~2.0.0-3 is to be installed

2022-04-25 Thread Adrian Bunk
Package: node-send
Version: 0.18.0+~cs1.19.1-1
Severity: serious

The following packages have unmet dependencies:
 node-send : Depends: node-statuses (< 2) but 2.0.1+~2.0.0-3 is to be installed



Bug#999672: mutt: license conflict with libsasl2

2022-04-25 Thread Bastian Germann

Control: tags -1 patch
Control: severity -1 serious

Thanks to Kevin for implementing this so quickly!
I have attached a patch to use gsasl with the package.
Raising the severity because this is a Policy violation.From: Bastian Germann 
Date: Mon, 25 Apr 2022 20:35:27 +0200
Subject: Replace cyrus-sasl with gsasl (Closes: #999672)

mutt depends on libsasl2, which is licensed under CMU's BSD-4-clause
license and covered by the RSA-MD and OpenSSL licenses. All of them
have an advertisement clause in place, which is known to be incompatible
with GPL.
---
 debian/changelog | 6 ++
 debian/control   | 4 ++--
 debian/rules | 2 +-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 8198462..341d9bc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+mutt (2.2.3-2) UNRELEASED; urgency=medium
+
+  * Replace cyrus-sasl with gsasl (Closes: #999672)
+
+ -- Bastian Germann   Mon, 25 Apr 2022 20:38:38 +0200
+
 mutt (2.2.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index cc53767..446054f 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends: debhelper-compat (= 12),
  libkrb5-dev,
  libncurses5-dev,
  libncursesw5-dev,
- libsasl2-dev,
+ libgsasl-dev,
  libtokyocabinet-dev,
  pkg-config,
  w3m,
@@ -30,7 +30,7 @@ Homepage: http://www.mutt.org/
 Package: mutt
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: locales, mailcap, libsasl2-modules, sensible-utils
+Recommends: locales, mailcap, sensible-utils
 Suggests: default-mta | mail-transport-agent, urlview, aspell | ispell, gnupg, openssl, ca-certificates
 Provides: mail-reader, imap-client
 Description: text-based mailreader supporting MIME, GPG, PGP and threading
diff --git a/debian/rules b/debian/rules
index 884f7bc..9542942 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,7 @@ override_dh_auto_configure:
 		--with-gss			\
 		--with-idn2			\
 		--with-mixmaster		\
-		--with-sasl			\
+		--with-gsasl			\
 		\
 		--without-gdbm 			\
 		--without-bdb			\


Bug#580980: PLEASE REPLY URGENTLY

2022-04-25 Thread Dr Chan
Hello,
Did you receive my previous message i sent to you.
Greetings.


Bug#1010158: neovim: update to latest upstream release 0.7.*

2022-04-25 Thread James McCoy
On Mon, Apr 25, 2022 at 03:37:10PM +0200, Agathe Porte wrote:
> More and more [0] nvim-related projects are only working on the latest
> nvim release 0.9.* series. It would be nice to have neovim updated
> to the latest upstream version before the freeze comes [1].

I'm sure I'll get to it before 9 months has passed.

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



Bug#1010167: reportbug: Spaces incorrectly inserted into words on final page

2022-04-25 Thread Nis Martensen
control: reassign -1 libgtk-3-0
control: affects -1 reportbug
control: affects -1 reportbug-gtk

> After submitting a bug, the final page ("Thank you for your report") gets
> mangled by the text-justification engine. (See attached image)

Thank you for your report. I can reproduce this on unstable, but not on
stable/bullseye (using the same reportbug code). So this looks like a
regression in one of the underlying libraries.

Reassigning to libgtk-3-0. Not sure if this is the real culprit; please
reassign further if needed.



Bug#1008569: unar: diff for NMU version 1.10.1-3

2022-04-25 Thread Sudip Mukherjee
Hi Boyuan,

On Mon, Apr 11, 2022 at 12:32:19PM -0400, Boyuan Yang wrote:
> Control: tags 1008569 + patch
> Control: tags 1008569 + pending
> X-Debbugs-CC: kr...@debian.org as...@debian.org jul...@debian.org
> 
> Dear maintainer,
> 
> I've prepared an NMU for unar (versioned as 1.10.1-3) and
> uploaded it to DELAYED/14. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> 
> diff -Nru unar-1.10.1/debian/changelog unar-1.10.1/debian/changelog
> --- unar-1.10.1/debian/changelog  2017-03-23 09:45:08.0 -0400
> +++ unar-1.10.1/debian/changelog  2022-04-11 12:27:28.0 -0400
> @@ -1,3 +1,12 @@
> +unar (1.10.1-3) unstable; urgency=medium
> +
> +  * QA upload.
> +  * Orphan the package (take over package maintenance) via
> +ITS process. (Closes: #1008569)

I maybe wrong but I was wondering if this is correct.

Section 5.12 in Debian's Developers Reference [1] clearly says:
Note that the process is only intended for actively taking over
maintainership. Do not start a package salvaging process when you
do not intend to maintain the package for a prolonged time. If you
only want to fix certain things, but not take over the package, you
must use the NMU process, even if the package would be eligible for
salvaging.

And, in this case you salavaged the package with the intention to
orphan it not to maintain it.

[1]. 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging


--
Regards
Sudip



Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-25 Thread Antoine Beaupré
On 2022-04-25 17:16:35, Tino Mettler wrote:
> Hi, Antoine,
>
> I run autopkgtest after the build process with the following result:
>
> # autopkgtest ./ -- qemu autopkgtest-unstable.img
> autopkgtest [15:05:05]: starting date: 2022-04-25
> autopkgtest [15:05:05]: version 5.21
> autopkgtest [15:05:05]: host mac; command line: /usr/bin/autopkgtest ./ -- 
> qemu autopkgtest-unstable.img
> autopkgtest [15:06:00]: testbed dpkg architecture: amd64
> autopkgtest [15:06:06]: testbed running kernel: Linux 5.17.0-1-amd64 #1 SMP 
> PREEMPT Debian 5.17.3-1 (2022-04-18)
> autopkgtest [15:06:07]:  built-tree ./
> autopkgtest [15:06:07]: testing package show-in-file-manager version 1.1.4-1
> *SKIP no tests in this package
> autopkgtest [15:06:07]:  summary
> *SKIP no tests in this package
> qemu-system-x86_64: terminating on signal 15 from pid 527684 
> (/usr/bin/python3)
>
> I'm still unsure what you meant with "You have actually configured it in the 
> package".

As someone else mentioned in the bug report,

> All Python module packages have a minimal automatic autopkgtest that tries
> to import the module. Make sure the module name used by the test is
> correct, and if it isn't you should set the correct one in
> debian/tests/autopkgtest-pkg-python.conf (see e.g. python-xlib and the
> relevant documentation in autodep8(1)).

... in this case, the package name is `python3-showinfilemanager` which
is why it's trying to import that module. We'd need to either rename the
debian package to follow the module name (which could actually be
reasonable, since that's the actual name of the package on pypi) or add
the name to the above configuration file.

Thanks!

-- 
La publicité est la dictature invisible de notre société.
- Jacques Ellul



Bug#1010098: xorriso: please allow -cut-out directly from block devices

2022-04-25 Thread Thomas Schmitt
Hi,

the plan to allow nearly all file types with -cut_out is dwindeling:

- lseek(SEEK_END) on S_IFCHR /dev/zero returns 0, not -1.

- open() on S_IFIFO blocks (and i don't want to know what it will do
  in libisofs). IIRC a successful open() has side effects on the fifo.

- S_IFSOCK fails properly with the lseek test.
  But in this case open() fails with errno 6 "No such device or address"
  although it exists as file /run/user/...userid../pulse/native.
  So i don't know what might happen with other sockets.

So if we exclude S_IFSOCK, S_IFLNK, S_IFDIR, S_IFIFO there remain only
S_IFREG, S_IFBLK, S_IFCHR with the latter on Linux behaving like S_IFREG
with 0 bytes of content. (As said on FreeBSD it could be a lseekable disk
device.)

Now i ponder whether i shall count S_IFCHR with size 0 as non-seekable
or really as empty file.
And whether i shall have a negative list of four types or a positive list
of three types.

Further it turned out that the lseek test in libisofs falls victim to
a bug in fs_local.c and fs_image.c which trick iso_file_source_lseek()
into returning libisofs error codes as positive off_t numbers.
A bug from the very early days of libisofs.

I am still testing but looking forward to committing the changes tomorrow.


Have a nice day :)

Thomas



Bug#1002666: Still experiencing this issue?

2022-04-25 Thread Ulrike Uhlig

Hi Richard,

are you still experiencing this issue?
Or did you solve it differently?

(I was just going through bugs to see what can be cleaned up)

Ulrike



Bug#1008997: ipp-usb

2022-04-25 Thread alain

found this :

https://github.com/OpenPrinting/ipp-usb

tried to compile it from source but didn't managed .

the package does not exists in experimental (only stable and sid) .

installed the golang package but didn't succed to compile ipp-usb .

friendly ,

respectfully ,

alain .



Bug#1008274: Should sandsifter be removed?

2022-04-25 Thread Moritz Mühlenhoff
severity 1008274 normal
reassign 1008274 ftp.debian.org
retitle 1008274 RM:  -- RoM; depends on Python 2, unmaintained
thanks

Am Fri, Mar 25, 2022 at 08:59:21PM +0100 schrieb Moritz Muehlenhoff:
> Source: sandsifter
> Version: 1.04-1
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> 
> - Still uses Python 2.7 and thus RC buggy
> - Last upload in 2019 and not in testing since 2019
> 
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
> 
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
> 
> Otherwise I'll move forward and request it's removal in a month.

Reassigning for removal



Bug#1008271: Should arriero be removed?

2022-04-25 Thread Moritz Mühlenhoff
severity 1008271 normal
reassign 1008271 ftp.debian.org
retitle 1008271 RM: arriero -- RoQA; depends on Python 2, unmaintained
thanks

Am Fri, Mar 25, 2022 at 08:57:10PM +0100 schrieb Moritz Muehlenhoff:
> Source: arriero
> Version: 0.6-1
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> 
> - Last upload in 2017
> - Still uses Python 2.7 and thus RC buggy
> - Missed the last two stable releases and removed from testing since 2018
> 
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
> 
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
> 
> --
> severity $BUGNUM normal
> reassign $BUGNUM ftp.debian.org
> retitle $BUGNUM RM:  -- RoM; 
> thx
> --
> 
> Otherwise I'll move forward and request it's removal in a month.

Reassigning to ftp.debian.org

Cheers,
Moritz



Bug#1010175: ITP: ruby-prawn-templates -- Prawn::Templates allows using PDFs as templates in Prawn

2022-04-25 Thread Keith Packard
Package: wnpp
Severity: wishlist
Owner: Keith Packard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Ruby Extras Maintainers 


* Package name: ruby-prawn-templates
  Version : 0.1.2
  Upstream Author : Gregory Brown 
* URL : https://github.com/prawnpdf/prawn-templates
* License : Ruby or GPL-2 or GPL-3
  Programming Lang: Ruby
  Description : Prawn::Templates allows using PDFs as templates in Prawn

A extension to prawn that allows one to include other pdfs either as
background to write upon or to combine several pdf documents into
one.

This package is required to implement pdf import in ruby-asciidoctor-pdf which
was left out because of a bug in pdf-core. There is a patch for the pdf-core
bug
which is upstream and will be released eventually; it would be good to have
this package ready in debian for when the pdf-core bug is fixed so that a new
version of ruby-asciidoctor-pdf can be released that enables this feature.



Bug#1010174: O: unar -- Unarchiver for a variety of file formats

2022-04-25 Thread Boyuan Yang
Package: wnpp
Severity: normal

According to the ITS request in https://bugs.debian.org/1008569 , I orphan
package unar in Debian. Unar is an important package and lacks packaging of
latest upstream releases. New QA uploads or package adoption is welcome.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly. You do not need others'
permission to adopt this package.

The package description is:
 The Unarchiver is an archive unpacker program with support for the popular
 zip, RAR, 7z, tar, gzip, bzip2, LZMA, XZ, CAB, MSI, NSIS, EXE, ISO, BIN, and
 split file formats, as well as the old Stuffit, Stuffit X, DiskDouble,
Compact
 Pro, Packit, cpio, compress (.Z), ARJ, ARC, PAK, ACE, ZOO, LZH, ADF, DMS,
LZX,
 PowerPacker, LBR, Squeeze, Crunch, and other old formats.
 .
 This package contains the lsar tool which lists the contents of archives and
 the unar tool which extracts those contents.

Some information about this package:

Package: unar
Version: 1.10.1-2+b8
Priority: optional
Section: utils
Source: unar (1.10.1-2)
Maintainer: Matt Kraai 
Installed-Size: 6,137 kB
Provides: theunarchiver
Pre-Depends: dpkg (>= 1.15.6~)
Depends: gnustep-base-runtime (>= 1.28.0), libbz2-1.0, libc6 (>= 2.33),
libgcc-s1 (>= 3.0), libgnustep-base1.28 (>= 1.28.0), libicu71 (>= 71.1-1~),
libobjc4 (>= 4.2.1), libstdc++6 (>= 5), libwavpack1 (>= 4.40.0), zlib1g (>=
1:1.2.0)
Conflicts: theunarchiver
Replaces: theunarchiver
Homepage: http://unarchiver.c3.cx/
Tag: interface::commandline, interface::graphical, interface::x11,
 role::program, scope::utility, suite::gnustep, works-with::archive,
 x11::application
Download-Size: 1,254 kB
APT-Sources: http://deb.debian.org/debian unstable/main amd64 Packages
Description: Unarchiver for a variety of file formats
 The Unarchiver is an archive unpacker program with support for the popular
 zip, RAR, 7z, tar, gzip, bzip2, LZMA, XZ, CAB, MSI, NSIS, EXE, ISO, BIN, and
 split file formats, as well as the old Stuffit, Stuffit X, DiskDouble,
Compact
 Pro, Packit, cpio, compress (.Z), ARJ, ARC, PAK, ACE, ZOO, LZH, ADF, DMS,
LZX,
 PowerPacker, LBR, Squeeze, Crunch, and other old formats.
 .
 This package contains the lsar tool which lists the contents of archives and
 the unar tool which extracts those contents.

-- 
Regards,
Boyuan Yang



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


Bug#980107: python-rioxarray

2022-04-25 Thread Alastair McKinstry

Hi Antonio and Magnus

Thanks, I've uploaded this to the new queue.

Best regards

Alastair

On 25/04/2022 16:20, Magnus HAGDORN wrote:

Hi Antonio,
thanks for updating the package. I have built and uploaded the package
to debian mentors:
https://mentors.debian.net/package/python-rioxarray/
but we will need a sponsor to upload the package to the new queue.

Regards
magnus


On Sat, 2022-04-23 at 16:20 +0200, Antonio Valentino wrote:

This email was sent to you by someone outside the University.
You should only click on links or attachments if you are certain that
the email is genuine and the content is safe.

Dear Magnus and Alastair,
I have recently pushed to the salsa repository a new upstream version
of
the rioxarray package (v0.11.1).
I would really like to have this package in debian.
If you are still interested in this package please go ahead with the
upload into the new queue.

I you are no longer interested or do not have time to dedicate,
please
let me know and I will try to find another sponsor for the first
upload.
Of course I will take in charge also the maintenance.


kind regards
antonio

On Fri, 5 Nov 2021 07:44:10 +0100 Antonio Valentino
 wrote:

Dear Alastair and Magnus,
yesterday I have pushed on the salsa repository an updated version
of
the rioxarray package including the latest upstream version 0.8.0.

Please consider it for your review and upload.

kind regards
antonio

Il 02/10/21 17:08, Antonio Valentino ha scritto:

Thank Magnus,
all branches and tags have been pushed now.
Now the package is ready for a review.

kind regards
antonio

Il 02/10/21 16:34, Magnus HAGDORN ha scritto:

Hi Antionio,
Excellent. I am very happy for you to push directly to the
repo.
magnus

On Sat, 2021-10-02 at 09:48 +0200, Antonio Valentino wrote:

This email was sent to you by someone outside the University.
You should only click on links or attachments if you are
certain that
the email is genuine and the content is safe.

Dear Alastair and Magnus,
I have update the package on my fork [1].
I have temporary removed the -doc package because it not
buildable at
the moment due to #995299 [2].
We can re-add the -doc package in a future version if
necessary.
I have also updated the package to the latest upstream
version 0.7.1.

@Magnus please let me know if you prefer me to push directly
on the
debian-science repository or to submit a merge request.

[1]
https://salsa.debian.org/antonio.valentino/python-rioxarray
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995299

kind regards
Antonio


Il 27/09/21 11:59, Alastair McKinstry ha scritto:

Hi Magnus

I downloaded and reviewed the package.

As it currently stands it needs some work to deal with
privacy
issues
(The lintian tests). Basically sphinxdocs is adding links
to
cloudflare
etc that leak user information.

You can look at "python-xarray" to see some solutions -
some can be
fixed with a patch to the sphinxdocs configuration, some
needs
editing
of the html files in debian/rules to use javascript helpers
that
you

--
Antonio Valentino

The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh 
Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.


--
Alastair McKinstry, mckins...@debian.org matrix: @sceal.ie:mckinstry
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5



Bug#1010173: workaround

2022-04-25 Thread Norbert Kiesel
After running `git config core.commitGraph false`, `git pull` works again.
Thus, priority for this bug could be reduced.


Bug#1010173: git: "git pull" fails with "fatal: commit-graph requires overflow generation data but has none"

2022-04-25 Thread Norbert Kiesel
Package: git
Version: 1:2.36.0-1
Severity: important
X-Debbugs-Cc: n...@iname.com

Dear Maintainer,

after upgrading Git, I cannot pull anymore because I always get the above erro
message.

I run a daily "git show-ref -s | git commit-graph write --stdin-commits
--changed-path --no-progress" in that repo.
For repos where I do not run this command, `git pull` continues to work.  I
tried to "shrink" the commit graph using
`git commit-graph write --stdin-commits --changed-path --no-progress <
/dev/null` but while this did not produce any
error, it also did not fix my problem.


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

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

Versions of packages git depends on:
ii  git-man  1:2.36.0-1
ii  libc62.33-7
ii  libcurl3-gnutls  7.82.0-2
ii  liberror-perl0.17029-1
ii  libexpat12.4.8-1
ii  libpcre2-8-0 10.39-4
ii  perl 5.34.0-4
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages git recommends:
ii  ca-certificates  20211016
ii  less 590-1
ii  openssh-client [ssh-client]  1:9.0p1-1
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-6
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information



Bug#1010154: libowasp-antisamy-java: CVE-2022-28366 + CVE-2022-28367

2022-04-25 Thread Salvatore Bonaccorso
Hi!

On Mon, Apr 25, 2022 at 01:48:43PM +0100, Neil Williams wrote:
> On Mon, 25 Apr 2022 13:39:49 +0100 Neil Williams  wrote:
> > Please note, the current homepage for libowasp-antisamy-java appears to
> > have no commits beyond version 1.5.3 but the change for CVE-2022-29577
> > does match the source code for libowasp-antisamy-java:
> > https://sources.debian.org/src/libowasp-antisamy-java/1.5.3+dfsg-1.1/src/main/java/org/owasp/validator/html/scan/AntiSamyDOMScanner.java/?hl=410#L410
> 
> Apologies - that paragraph contains a typo - the matching change is for
> CVE-2022-28367:
> 
> The fix in what looks like the new upstream is:
> https://github.com/nahsra/antisamy/commit/0199e7e194dba5e7d7197703f43ebe22401e61ae

Could you please make sure to as well include
https://github.com/nahsra/antisamy/commit/32e273507da0e964b58c50fd8a4c94c9d9363af0
to make the fix complete.

Possibly it's best to just update to the new 1.6.7 upstream version.

Regards,
Salvatore



Bug#1010172: macaulay2: autopkgtest regression

2022-04-25 Thread Sebastian Ramacher
Source: macaulay2
Version: 1.19.1+ds-7
Severity: serious

Since the last upload, autopkgtests fail on all architectures:

stdio:1:1:(3): error: test(s) #267, 268, 269 of package Core failed.

 cd /tmp/M2-2816-0/1-rundir/; GC_MAXIMUM_HEAP_SIZE=400M "/usr/bin/M2-binary" 
--int --no-randomize --no-readline --silent --stop --print-width 77 
<"/tmp/M2-2816-0/0.m2" >>"/tmp/M2-2816-0/0.tmp"
/tmp/M2-2816-0/0.tmp:0:1: (output file) error: Macaulay2 exited with status 
code 1
/tmp/M2-2816-0/0.m2:0:1: (input file)
M2: *** Error 1

See
https://ci.debian.net/data/autopkgtest/testing/amd64/m/macaulay2/21150543/log.gz

Cheers
-- 
Sebastian Ramacher



Bug#980107: python-rioxarray

2022-04-25 Thread Antonio Valentino

Dear Magnus,
thanks a lot for uploading on mentors.
Regarding the sponsorship please consider sending a request for 
sponsorship on the Debian Science mailing list.


Another option is https://wiki.debian.org/DebianPureBlends/SoB.
We need to include rioxarray in a blend (I recommend 
tasks/numericalcomputation in g...@salsa.debian.org:blends-team/science.git).

If you prefer I can update the task file myself.

kind regards
antonio

On Mon, 25 Apr 2022 15:20:29 + Magnus HAGDORN 
 wrote:

Hi Antonio,
thanks for updating the package. I have built and uploaded the package
to debian mentors:
https://mentors.debian.net/package/python-rioxarray/
but we will need a sponsor to upload the package to the new queue.

Regards
magnus


On Sat, 2022-04-23 at 16:20 +0200, Antonio Valentino wrote:
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that
> the email is genuine and the content is safe.
>
> Dear Magnus and Alastair,
> I have recently pushed to the salsa repository a new upstream version
> of
> the rioxarray package (v0.11.1).
> I would really like to have this package in debian.
> If you are still interested in this package please go ahead with the
> upload into the new queue.
>
> I you are no longer interested or do not have time to dedicate,
> please
> let me know and I will try to find another sponsor for the first
> upload.
> Of course I will take in charge also the maintenance.


--
Antonio Valentino



Bug#1010171: sbuild's "unshare" test fails with gpg-agent 2.2.34-1

2022-04-25 Thread Daniel Kahn Gillmor
Package: sbuild
Version: 0.83.0
Control: affects -1 + gpg-agent
Control: tags -1 + patch

When trying to upgrade to gnupg2 from version 2.2.27-1 to version
2.2.34-1, we see a failure in the unshare-qemuwrapper test:

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sbuild/21152998/log.gz

+ ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no -i 
/tmp/autopkgtest-lxc.29hmt_yk/downtmp/autopkgtest_tmp/id_rsa -T -p 10022 
root@localhost env --chdir=/build/ AUTOPKGTEST_TMP=/tmp runuser -u user -- 
./debian/tests/unshare
Warning: Permanently added '[localhost]:10022' (ED25519) to the list of known 
hosts.
gpg: keybox '/tmp/gpghome/pubring.kbx' created
gpg: /tmp/gpghome/trustdb.gpg: trustdb created
gpg: key F08FF84541F5A0C0: public key "sbuild fake uploader 
" imported
gpg: key F08FF84541F5A0C0/F08FF84541F5A0C0: error sending to agent: Invalid 
argument
gpg: key F08FF84541F5A0C0/A4179B1DD69E01DD: error sending to agent: Invalid 
argument
gpg: key F08FF84541F5A0C0: secret key imported
gpg: Total number processed: 1
gpg:   imported: 1
gpg:   secret keys read: 1
gpg:   secret keys imported: 1

I traced this error down to the use of "gpg --allow-secret-key-import
--import" in the unshare script.  GnuPG upstream has always maintained
that use of gpg in scripts requires use of the --batch directive, which
avoids the error.  Why this error response was introduced in the change
from GnuPG 2.2.27 to 2.2.34, i don't yet fully understand, but using
--batch does avoid the problem.

The attached patch should hopefully make the sbuild autopkgtest succeed
with either version of GnuPG2.

thanks for maintaining sbuild in debian!

   --dkg

From 4bdf145dd92df9db01fa38e1ab33cf1c36926ce9 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Mon, 25 Apr 2022 12:30:11 -0400
Subject: [PATCH] Use --batch with gpg when importing secret key

The use of gpg here is automated, and should not trigger a prompt to
the user.  GnuPG upstream recommends always using --batch in contexts
like this.

With GnuPG 2.2.34, the import actually fails, with gpg-agent logging
the following failures:

2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- IMPORT_KEY --timestamp=20210125T124832
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] command 'IMPORT_KEY' failed: Invalid argument 
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> ERR 16777261 Invalid argument 
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22sbuild+fake+uploader+%22%0A255-bit+EDDSA+key,+ID+A4179B1DD69E01DD,%
0Acreated+2021-01-25+(main+key+ID+F08FF84541F5A0C0).%0A
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> OK
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- IMPORT_KEY --timestamp=20210125T124832
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] command 'IMPORT_KEY' failed: Invalid argument 
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> ERR 16777261 Invalid argument 
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22sbuild+fake+uploader+%22%0A255-bit+ECDH+key,+ID+52C3581ED0C37392,%0
Acreated+2021-01-25+(main+key+ID+F08FF84541F5A0C0).%0A
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> OK

Using --batch here changes the IMPORT_KEY assuan directive such that
it includes an --unattended flag, which bypasses the failures we're
seeing on upgrading GnuPG in debian unstable.

Having to perform this workaround is unfortunate.  A better approach
would be to rewrite sbuild's tooling to use OpenPGP utilities designed
for operation in a script, but doing so is a larger and more intrusive
patch.
---
 debian/tests/unshare | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/unshare b/debian/tests/unshare
index aa23bb08..272330f5 100755
--- a/debian/tests/unshare
+++ b/debian/tests/unshare
@@ -101,7 +101,7 @@ verify() {
 
 
 # FIXME: generate a key without expiry date
-cat << END | gpg --allow-secret-key-import --import -
+cat << END | gpg --batch --allow-secret-key-import --import -
 -BEGIN PGP PRIVATE KEY BLOCK-
 
 xVgEYA6+IBYJKwYBBAHaRw8BAQdAM1MKmD3Qm9XwkCv40xOUt1KTLL3nQ2NYfl6B
-- 
2.35.1



signature.asc
Description: PGP signature


Bug#1010170: FTBFS: lisp/net/tramp-archive-tests.log contains unexpected results

2022-04-25 Thread Vincent Lefevre
Source: emacs
Version: 1:27.1+1-3.1
Severity: serious
Tags: ftbfs

When rebuilding emacs:

SUMMARY OF TEST RESULTS
---
Files examined: 267
Ran 3883 tests, 3832 results as expected, 1 unexpected, 50 skipped
1 files contained unexpected results:
  lisp/net/tramp-archive-tests.log
make[4]: *** [Makefile:320: check-doit] Error 1
make[4]: Leaving directory 
'/home/vlefevre/tmp/emacs-27.1+1/debian/build-lucid/test'
make[3]: *** [Makefile:289: check] Error 2
make[3]: Leaving directory 
'/home/vlefevre/tmp/emacs-27.1+1/debian/build-lucid/test'
make[2]: *** [Makefile:960: check] Error 2
make[2]: Leaving directory '/home/vlefevre/tmp/emacs-27.1+1/debian/build-lucid'
make[1]: *** [debian/rules:341: override_dh_auto_test] Error 2
make[1]: Leaving directory '/home/vlefevre/tmp/emacs-27.1+1'
make: *** [debian/rules:204: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -b failed

The failed test in lisp/net/tramp-archive-tests.log:

Test tramp-archive-test02-file-name-dissect condition:
(ert-test-failed
 ((should
   (string-equal host
 (url-hexify-string ...)))
  :form
  (string-equal 
"file%3A%2F%2F%2Fhome%2Fvlefevre%2Ftmp%2Femacs-27.1%252B1%2Fdebian%2Fbuild-src%2Ftest%2Flisp%2Fnet%2Ftramp-archive-resources%2Ffoo.tar.gz"
 
"file%3A%2F%2F%2Fhome%2Fvlefevre%2Ftmp%2Femacs-27.1%2B1%2Fdebian%2Fbuild-src%2Ftest%2Flisp%2Fnet%2Ftramp-archive-resources%2Ffoo.tar.gz")
  :value nil))
   FAILED  3/8  tramp-archive-test02-file-name-dissect (0.031675 sec)

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

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



Bug#1010169: ITP: tiny-dnn -- header only deep learning framework in C++

2022-04-25 Thread Andrius Merkys
Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
X-Debbugs-CC: debian...@lists.debian.org

* Package name: tiny-dnn
  Version : 1.0.0a3+ds
  Upstream Author : Taiga Nomi
* URL : https://github.com/tiny-dnn/tiny-dnn
* License : BSD-3-Clause
  Programming Lang: C++
  Description : header only deep learning framework in C++

tiny-dnn is a C++14 implementation of deep learning. It is suitable for
deep learning on limited computational resource, embedded systems and
IoT devices.

I am interested in packaging tiny-dnn due to its usage to train QMEAN
evaluator for protein structure models (see #976981). As per ML-policy,
pre-trained NN models have to be followed by the software used to train
them. However, tiny-dnn does not seem to have much upstream support any
more.

As of now, the package fails to build with tests enabled. I expect
incompatibility with newer C++ compiler or its options to be the cause,
but I did not investigate it much:

cd
/home/andrius/debian-packages/HIDE/tiny-dnn-1.0.0a3+ds/obj-x86_64-linux-gnu/test
&& /usr/bin/cmake -E cmake_link_script
CMakeFiles/tiny_dnn_test.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2
-ffile-prefix-map=/home/andrius/debian-packages/HIDE/tiny-dnn-1.0.0a3+ds=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2  -msse3 -mavx -Wall -Wpedantic -Wno-narrowing
-Wl,-z,relro -rdynamic CMakeFiles/tiny_dnn_test.dir/test.cpp.o
CMakeFiles/tiny_dnn_test.dir/test_no_duplicate_symbols.cpp.o -o
tiny_dnn_test  -ltbb -ltbbmalloc -lgtest -lgmock -lpthread
/usr/bin/ld:
CMakeFiles/tiny_dnn_test.dir/test_no_duplicate_symbols.cpp.o:/usr/include/stb/stb_image_write.h:256:
multiple definition of `stbi_write_tga_with_rle';
CMakeFiles/tiny_dnn_test.dir/test.cpp.o:/usr/include/stb/stb_image_write.h:256:
first defined here
/usr/bin/ld:
CMakeFiles/tiny_dnn_test.dir/test_no_duplicate_symbols.cpp.o: in
function `stbi_failure_reason':
/usr/include/stb/stb_image.h:972: multiple definition of
`stbi_failure_reason';
CMakeFiles/tiny_dnn_test.dir/test.cpp.o:/usr/include/stb/stb_image.h:972: first
defined here

(a lot more follows)

Remark: This package is to be maintained inside Debian Deep Learning Team at
   https://salsa.debian.org/deeplearning-team/tiny-dnn



Bug#980107: python-rioxarray

2022-04-25 Thread Magnus HAGDORN
Hi Antonio,
thanks for updating the package. I have built and uploaded the package
to debian mentors:
https://mentors.debian.net/package/python-rioxarray/
but we will need a sponsor to upload the package to the new queue.

Regards
magnus


On Sat, 2022-04-23 at 16:20 +0200, Antonio Valentino wrote:
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that
> the email is genuine and the content is safe.
>
> Dear Magnus and Alastair,
> I have recently pushed to the salsa repository a new upstream version
> of
> the rioxarray package (v0.11.1).
> I would really like to have this package in debian.
> If you are still interested in this package please go ahead with the
> upload into the new queue.
>
> I you are no longer interested or do not have time to dedicate,
> please
> let me know and I will try to find another sponsor for the first
> upload.
> Of course I will take in charge also the maintenance.
>
>
> kind regards
> antonio
>
> On Fri, 5 Nov 2021 07:44:10 +0100 Antonio Valentino
>  wrote:
> > Dear Alastair and Magnus,
> > yesterday I have pushed on the salsa repository an updated version
> > of
> > the rioxarray package including the latest upstream version 0.8.0.
> >
> > Please consider it for your review and upload.
> >
> > kind regards
> > antonio
> >
> > Il 02/10/21 17:08, Antonio Valentino ha scritto:
> > > Thank Magnus,
> > > all branches and tags have been pushed now.
> > > Now the package is ready for a review.
> > >
> > > kind regards
> > > antonio
> > >
> > > Il 02/10/21 16:34, Magnus HAGDORN ha scritto:
> > > > Hi Antionio,
> > > > Excellent. I am very happy for you to push directly to the
> > > > repo.
> > > > magnus
> > > >
> > > > On Sat, 2021-10-02 at 09:48 +0200, Antonio Valentino wrote:
> > > > > This email was sent to you by someone outside the University.
> > > > > You should only click on links or attachments if you are
> > > > > certain that
> > > > > the email is genuine and the content is safe.
> > > > >
> > > > > Dear Alastair and Magnus,
> > > > > I have update the package on my fork [1].
> > > > > I have temporary removed the -doc package because it not
> > > > > buildable at
> > > > > the moment due to #995299 [2].
> > > > > We can re-add the -doc package in a future version if
> > > > > necessary.
> > > > > I have also updated the package to the latest upstream
> > > > > version 0.7.1.
> > > > >
> > > > > @Magnus please let me know if you prefer me to push directly
> > > > > on the
> > > > > debian-science repository or to submit a merge request.
> > > > >
> > > > > [1]
> > > > > https://salsa.debian.org/antonio.valentino/python-rioxarray
> > > > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995299
> > > > >
> > > > > kind regards
> > > > > Antonio
> > > > >
> > > > >
> > > > > Il 27/09/21 11:59, Alastair McKinstry ha scritto:
> > > > > > Hi Magnus
> > > > > >
> > > > > > I downloaded and reviewed the package.
> > > > > >
> > > > > > As it currently stands it needs some work to deal with
> > > > > > privacy
> > > > > > issues
> > > > > > (The lintian tests). Basically sphinxdocs is adding links
> > > > > > to
> > > > > > cloudflare
> > > > > > etc that leak user information.
> > > > > >
> > > > > > You can look at "python-xarray" to see some solutions -
> > > > > > some can be
> > > > > > fixed with a patch to the sphinxdocs configuration, some
> > > > > > needs
> > > > > > editing
> > > > > > of the html files in debian/rules to use javascript helpers
> > > > > > that
> > > > > > you
>
> --
> Antonio Valentino
The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh 
Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.


Bug#1010168: RFP: python3-pytest-fail-slow -- pytest plugin for making tests fail that take too long to run

2022-04-25 Thread Yaroslav Halchenko
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: python3-pytest-fail-slow
  Version : 0.1.0
  Upstream Author : John Thorvald Wodder II 
* URL : https://github.com/jwodder/pytest-fail-slow/
* License : MIT/X
  Programming Lang: Python
  Description : pytest plugin for making tests fail that take too long to 
run

pytest-fail-slow is a pytest plugin for making tests fail that take too
long to run. It adds a --fail-slow DURATION command-line option to pytest that
causes any & all otherwise-passing tests that run for longer than the given
duration to be marked as failures, and it adds a
@pytest.mark.fail_slow(DURATION) marker for making an individual test fail if
it runs for longer than the given duration. If --fail-slow is given and a test
has the @fail_slow() marker, the duration given by the marker takes precedence
for that test.

It will likely be necessary for testing the next (0.17) release of
DataLad package.



Bug#993670: Screen corruption using radeon kernel driver

2022-04-25 Thread Mikhail Krylov
Here's the link in amd-gfx mail list:

https://lists.freedesktop.org/archives/amd-gfx/2022-April/078134.html


signature.asc
Description: PGP signature


Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-25 Thread Antoine Beaupré
On 2022-04-25 17:16:35, Tino Mettler wrote:
> Hi, Antoine,
>
> I run autopkgtest after the build process with the following result:
>
> # autopkgtest ./ -- qemu autopkgtest-unstable.img
> autopkgtest [15:05:05]: starting date: 2022-04-25
> autopkgtest [15:05:05]: version 5.21
> autopkgtest [15:05:05]: host mac; command line: /usr/bin/autopkgtest ./ -- 
> qemu autopkgtest-unstable.img
> autopkgtest [15:06:00]: testbed dpkg architecture: amd64
> autopkgtest [15:06:06]: testbed running kernel: Linux 5.17.0-1-amd64 #1 SMP 
> PREEMPT Debian 5.17.3-1 (2022-04-18)
> autopkgtest [15:06:07]:  built-tree ./
> autopkgtest [15:06:07]: testing package show-in-file-manager version 1.1.4-1
> *SKIP no tests in this package
> autopkgtest [15:06:07]:  summary
> *SKIP no tests in this package
> qemu-system-x86_64: terminating on signal 15 from pid 527684 
> (/usr/bin/python3)
>
> I'm still unsure what you meant with "You have actually configured it in the 
> package".

You haven't, I was mistaken. See other comments on the bug report.

-- 
The price of reliability is the pursuit of the utmost simplicity.
- C.A.R. Hoare



Bug#1010085: linux: Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)

2022-04-25 Thread Diederik de Haas
On Sunday, 24 April 2022 00:10:01 CEST Diederik de Haas wrote:
> The drives have the exact same same characteristics:
> 
> # fdisk -l /dev/sdb
> Disk /dev/sdb: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors
> Disk model: WDC WD30EFRX-68E
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>
> [ USB connected drive ]
> # sg_vpd -p bl /dev/sdb
> Block limits VPD page (SBC):
>   ...
>   Optimal transfer length granularity: 8 blocks
>   Maximum transfer length: 65535 blocks
>   Optimal transfer length: 65535 blocks
>   Maximum prefetch transfer length: 65535 blocks
>   
> 
> [ SATA connected drive ]
> # sg_vpd -p bl /dev/sdb
> Block limits VPD page (SBC):
>   ...
>   Optimal transfer length granularity: 8 blocks
>   Maximum transfer length: 0 blocks [not reported]
>   Optimal transfer length: 0 blocks [not reported]
>   Maximum prefetch transfer length: 0 blocks [ignored]
>   

Learned some more things:
- partitioning is irrelevant (for this issue)
- physical sector size of 4096 is very relevant; with 512 you don't get a
  warning, only an informational message saying 33553920 bytes is
  optimal transfer size (which is still 512 bytes short of 32MB)
- USB connected drive reports Maximum/Optimum length of 65535 blocks, while
  SATA reports 0

The last item explains the difference I saw and
I missed it as I was focused on the partitioning.

> https://www.spinics.net/lists/linux-scsi/msg139591.html is where I got
> the various `sg_*` commands from.

One of that message follow-ups was titled:
[PATCH] scsi: sd: Optimal I/O size should be a multiple of reported granularity

After a bit of searching that led me to the following:
https://patchwork.kernel.org/project/linux-scsi/patch/20220302053559.32147-9-martin.peter...@oracle.com/
or 
https://lkml.kernel.org/linux-scsi/20220302053559.32147-1-martin.peter...@oracle.com/
 on LKML

I feel a bit more comfortable ignoring the kernel warning, but I'm still
not sure whether it is a harmless msg or an actual bug.
If the maintainers consider this not to be a bug, feel free to close it.

Cheers,
  Diederik

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


Bug#1008997: [OpenPrinting/ipp-usb] ipp-usb is not ready for this device (Issue #48)

2022-04-25 Thread alain


Le 25/04/2022 à 17:33, alain a écrit :



Le 25/04/2022 à 16:10, alain a écrit :


uninstalled apparmor and reboot .

system-config-printer  do not work better and do not recognize my 
printer .


with the 0.9.20-1 ipp-usb package , it seems not to work better than 
with the stable one


(ok for stable version) .

saw this :

https://wiki.debian.org/AppArmor/HowToUse#Enable_AppArmor

and did this before uninstall :

echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' \
   | sudo tee /etc/default/grub.d/apparmor.cfg

now deleted file .cfg

i am reinstalling  apparmor .

do i have to do this  : ?

echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 
security=apparmor"' \
   | sudo tee /etc/default/grub.d/apparmor.cfg

thanks .

friendly ,

respectfully ;

alain .


Le 25/04/2022 à 15:27, Brian Potkin a écrit :


@BELLECalain  A quick way to do as 
@alexpevzner  suggests is to purge 
apparmor and reboot. It is easily reinstalled.


As a separate test, would you try a different USB port?

—
Reply to this email directly, view it on GitHub 
, 
or unsubscribe 
.
You are receiving this because you were mentioned.Message ID: 



Bug#1010167: reportbug: Spaces incorrectly inserted into words on final page

2022-04-25 Thread Kevin
Package: reportbug
Version: 11.4.1
Severity: minor
X-Debbugs-Cc: deb...@kevinsteen.net

Dear Maintainer,

After submitting a bug, the final page ("Thank you for your report") gets
mangled by the text-justification engine. (See attached image)

Resizing the window modifies the spacing and generally fixes the text, but by
that time the user will have already tried to read the text.

-Kevin


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/kevin/.reportbugrc:
reportbug_version "11.4.1"
mode standard
ui gtk
realname "Kevin"
email "deb...@kevinsteen.net"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt2.4.5
ii  python33.10.4-1
ii  python3-reportbug  11.4.1
ii  sensible-utils 0.0.17

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf 1.5.79
pn  debsums 
pn  dlocate 
pn  emacs-bin-common
ii  file1:5.41-2
ii  gnupg   2.2.27-3
ii  postfix [mail-transport-agent]  3.6.4-1+b2
ii  python3-urwid   2.1.2-2+b1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.4.5
ii  file   1:5.41-2
ii  python33.10.4-1
ii  python3-apt2.3.0+b1
ii  python3-debian 0.1.43
ii  python3-debianbts  3.2.0
ii  python3-requests   2.27.1+dfsg-1
ii  sensible-utils 0.0.17

python3-reportbug suggests no packages.

-- no debconf information


Bug#1010166: webkit2gtk: 2.36.1-1 apparent regression seen in devhelp autopkgtest

2022-04-25 Thread Jeremy Bicha
Source: webkit2gtk
Version: 2.36.1-1
Severity: serious

The new release of webkit2gtk won't migrate to Testing because of an
autopkgtest regression in devhelp. I'm filing this bug to make sure
that the maintainer notices the issue.

https://ci.debian.net/packages/d/devhelp/testing/amd64/

Test excerpt
=

(trivial:8073): GLib-GObject-WARNING **: 01:10:59.990: invalid (NULL)
pointer instance

(trivial:8073): GLib-GObject-CRITICAL **: 01:10:59.990:
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)'
failed

(trivial:8073): Gdk-CRITICAL **: 01:10:59.990:
gdk_wayland_display_get_wl_display: assertion 'GDK_IS_WAYLAND_DISPLAY
(display)' failed
EGLDisplay Initialization failed: EGL_NOT_INITIALIZED


Thank you,
Jeremy Bicha



Bug#1010165: grub-customizer: Inappropriate package, modifies other package's (conf) files, should be removed from archive

2022-04-25 Thread Julian Andres Klode
Package: grub-customizer
Severity: important
X-Debbugs-Cc: juli...@ubuntu.com

As documented in 
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1969353/comments/5,
grub-customizer modifies conffileso owned by grub2, thus violating the
recommendations outlined in Policy 10.7.4.

The solution is brittle, not integrated with grub2, and should therefore
not be part of Debian.

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

Kernel: Linux 5.15.0-25-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#1010163: xfce4-taskmanager: Graph fill colour doesn't reach bottom left corner

2022-04-25 Thread Kevin
Package: xfce4-taskmanager
Version: 1.5.2-1
Severity: minor
X-Debbugs-Cc: deb...@kevinsteen.net

Dear Maintainer,

The graph fill colour in this version doesn't include the entire area under the
graph on the left-hand side. The attached image shows the problem clearly for
the Memory graph, but it also occurs for the left-hand CPU graph.

It appears as though the fill is being bounded by a line drawn from the bottom
right corner directly to the left-most value.

-Kevin


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

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

Versions of packages xfce4-taskmanager depends on:
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.1-1
ii  libgtk-3-0   3.24.33-1
ii  libwnck-3-0  40.1-1
ii  libx11-6 2:1.7.5-1
ii  libxfce4ui-2-0   4.16.1-1
ii  libxfconf-0-34.16.0-2
ii  libxmu6  2:1.1.3-3

xfce4-taskmanager recommends no packages.

xfce4-taskmanager suggests no packages.

-- no debconf information


Bug#1010164: fails autopkgtest against Octave 7

2022-04-25 Thread Sébastien Villemot
Package: octave-bart
Version: 0.7.00-2
Severity: serious
Tags: patch
Control: block 1009865 by -1

Dear Maintainer,

The autopkgtest for octave-bart fails against octave 7.1.0-2 recently uploaded
to unstable. See:
https://ci.debian.net/data/autopkgtest/testing/amd64/b/bart/21135046/log.gz

The problem comes from a message that is printed to stderr:

  error: ignoring const execution_exception& while preparing to exit

This message only appears when running the autopkgtest in a dedicated chroot as
done on the DebCI infrastructure. I wasn’t able to reproduce it in other
contexts, and I could not figure out what causes it.

Since this message is essentially harmless, and given that the test passes
otherwise, I would suggest to simply add the “allow-stderr” keyword to
“Restrictions” in the octave-integration stanza of debian/tests/control.

Thanks for your work,

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


Bug#1010160: x11-xkb-utils: setxkbmap -layout cz_qwerty loads layout which fails with a particular dead-key combination

2022-04-25 Thread Pavel Sanda
On Mon, Apr 25, 2022 at 04:25:04PM +0200, Julien Cristau wrote:
> On Mon, Apr 25, 2022 at 03:53:22PM +0200, Pavel Sanda wrote:
> > for keyboard configuration I use the following command on my system:
> > setxkbmap -model pc105 -layout "us,cz_qwerty"  -option 
> > "grp:alt_shift_toggle"
> > 
> > The cz_qwerty layout works mostly fine, except one singular failure:
> > dead-key ˇ (caron) + u (the same for upper-case variant ˇ+U).
> > 
> > I am afraid non-native prepared/"fixed" this layout, because the layout
> > logically ends up with caron+u, which is non-existent in czech while
> > on all czech keyboards you end up with overring+u (ů, see
> > https://en.wikipedia.org/wiki/Ring_(diacritic) ).
> > 
> > It renders this layout unusable for continuous czech writing, can it get 
> > fixed?
> > (Or at leat can you give me a hint where to fix this, I expect this could
> > be two-liner change in some kayboard-layout files...)
> > 
> The cz_qwerty layout is defined here:
> https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/ade97960d7bfc7fde8d08e9fa5584e7c3c51c23b/symbols/cz#L81
> 
> Key combinations including those with dead keys live in Xlib though:
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre
> 
> Reassigning to xkeyboard-config for now, let us know if you end up
> reporting/fixing this upstream.

Thanks. I figured out that this is actually minor problem as I can avoid dead 
caron
altogether, as caps lock works with ů (for some reason I was mislead by
seing the character " on top of the key ů, but of course caps lock is not
identical to the shift key).

So although I still consider this bug in the layout, its fairly minor
and if we close this as wontfix, it's not big deal.

Pavel



Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-25 Thread Tino Mettler
Hi, Antoine,

I run autopkgtest after the build process with the following result:

# autopkgtest ./ -- qemu autopkgtest-unstable.img
autopkgtest [15:05:05]: starting date: 2022-04-25
autopkgtest [15:05:05]: version 5.21
autopkgtest [15:05:05]: host mac; command line: /usr/bin/autopkgtest ./ -- qemu 
autopkgtest-unstable.img
autopkgtest [15:06:00]: testbed dpkg architecture: amd64
autopkgtest [15:06:06]: testbed running kernel: Linux 5.17.0-1-amd64 #1 SMP 
PREEMPT Debian 5.17.3-1 (2022-04-18)
autopkgtest [15:06:07]:  built-tree ./
autopkgtest [15:06:07]: testing package show-in-file-manager version 1.1.4-1
*SKIP no tests in this package
autopkgtest [15:06:07]:  summary
*SKIP no tests in this package
qemu-system-x86_64: terminating on signal 15 from pid 527684 (/usr/bin/python3)

I'm still unsure what you meant with "You have actually configured it in the 
package".

Regards,
Tino



Bug#1010161: x11-xkb-utils-udeb: broken setxkbmap within the installer

2022-04-25 Thread Cyril Brulebois
Julien Cristau  (2022-04-25):
> Control: tag -1 upstream patch
> Control: forwarded -1 
> https://gitlab.freedesktop.org/xorg/app/setxkbmap/-/merge_requests/4
> 
> On Mon, Apr 25, 2022 at 03:44:59PM +0200, Cyril Brulebois wrote:
> > And thanks again for the quick turnaround for the libxrandr2 udeb
> > addition. The next issue is is_xwayland() erroring out at runtime, with
> > BadRROutput on the RRGetOutputInfo call. This breaks setxkbmap in the
> > installer, and prevents the graphical installer from going further than
> > 2 steps.
> > 
> Fixed with the above MR.

Thanks; for those following at home: verified in a d-i context.


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


signature.asc
Description: PGP signature


Bug#1010162: xfce4-taskmanager: Process list slides upwards over time, hiding top entries

2022-04-25 Thread Kevin
Package: xfce4-taskmanager
Version: 1.5.2-1
Severity: normal
X-Debbugs-Cc: deb...@kevinsteen.net

Dear Maintainer,

This version of taskmanager gradually hides the top-most entries in the process
list when taskmanager is not in the foreground. With no scrollbar it is not
possible to see that this has occurred and that the cpu-hogging task you are
interested in is no longer visible at the top of the list.

Switching back to the taskmanager allows you to scroll back to the top of the
list, but this bug reduces the usefulness of taskmanager. (I like to keep the
window open in the background so I can glance across at it when I notice CPU
usage spiking and see which process is causing it.)

-Kevin


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

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

Versions of packages xfce4-taskmanager depends on:
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.1-1
ii  libgtk-3-0   3.24.33-1
ii  libwnck-3-0  40.1-1
ii  libx11-6 2:1.7.5-1
ii  libxfce4ui-2-0   4.16.1-1
ii  libxfconf-0-34.16.0-2
ii  libxmu6  2:1.1.3-3

xfce4-taskmanager recommends no packages.

xfce4-taskmanager suggests no packages.

-- no debconf information



Bug#1010161: x11-xkb-utils-udeb: broken setxkbmap within the installer

2022-04-25 Thread Julien Cristau
Control: tag -1 upstream patch
Control: forwarded -1 
https://gitlab.freedesktop.org/xorg/app/setxkbmap/-/merge_requests/4

On Mon, Apr 25, 2022 at 03:44:59PM +0200, Cyril Brulebois wrote:
> And thanks again for the quick turnaround for the libxrandr2 udeb
> addition. The next issue is is_xwayland() erroring out at runtime, with
> BadRROutput on the RRGetOutputInfo call. This breaks setxkbmap in the
> installer, and prevents the graphical installer from going further than
> 2 steps.
> 
Fixed with the above MR.

Cheers,
Julien



Bug#1010160: x11-xkb-utils: setxkbmap -layout cz_qwerty loads layout which fails with a particular dead-key combination

2022-04-25 Thread Julien Cristau
Control: reassign -1 xkeyboard-config
Control: tag -1 upstream

On Mon, Apr 25, 2022 at 03:53:22PM +0200, Pavel Sanda wrote:
> for keyboard configuration I use the following command on my system:
> setxkbmap -model pc105 -layout "us,cz_qwerty"  -option "grp:alt_shift_toggle"
> 
> The cz_qwerty layout works mostly fine, except one singular failure:
> dead-key ˇ (caron) + u (the same for upper-case variant ˇ+U).
> 
> I am afraid non-native prepared/"fixed" this layout, because the layout
> logically ends up with caron+u, which is non-existent in czech while
> on all czech keyboards you end up with overring+u (ů, see
> https://en.wikipedia.org/wiki/Ring_(diacritic) ).
> 
> It renders this layout unusable for continuous czech writing, can it get 
> fixed?
> (Or at leat can you give me a hint where to fix this, I expect this could
> be two-liner change in some kayboard-layout files...)
> 
The cz_qwerty layout is defined here:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/ade97960d7bfc7fde8d08e9fa5584e7c3c51c23b/symbols/cz#L81

Key combinations including those with dead keys live in Xlib though:
https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre

Reassigning to xkeyboard-config for now, let us know if you end up
reporting/fixing this upstream.

Cheers,
Julien



Bug#1010161: x11-xkb-utils-udeb: broken setxkbmap within the installer

2022-04-25 Thread Cyril Brulebois
Package: x11-xkb-utils-udeb
Version: 7.7+6+b1
Severity: serious
Tags: d-i
Justification: breaks graphical installer
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi X people,

And thanks again for the quick turnaround for the libxrandr2 udeb
addition. The next issue is is_xwayland() erroring out at runtime, with
BadRROutput on the RRGetOutputInfo call. This breaks setxkbmap in the
installer, and prevents the graphical installer from going further than
2 steps.

I think we would be happy to set a specific environment variable for you
to notice and exit early if desired; or we can check if such a variable
exists already for you to use.

Thanks for your help!


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



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

2022-04-25 Thread Geert Stappers


Now it is here (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996240) also.

- Forwarded message from Geert Stappers  -

Date: Mon, 25 Apr 2022 15:59:30 +0200
From: Geert Stappers 
To: Santiago Ruano Rincón , 1009...@bugs.debian.org,
894...@bugs.debian.org
Cc: Christian Göttsche , n...@packages.debian.org
Subject: Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer
User-Agent: NeoMutt/20170113 (1.7.2)

Full quote

On Mon, Apr 25, 2022 at 03:25:02PM +0200, Santiago Ruano Rincón wrote:
> El 22/04/22 a las 11:09, Christian Göttsche escribió:
> > > Is it really urgency=medium? low wouldn't fit?
> > 
> > I never used anything else than the default medium; happy to reduce to
> > low if wished.
> 
> I don't think reducing is really needed. I'd upload to a DELAYED queue
> though, which is a different thing, to give Eugene some time to react.
> 
> > > Eugene tagged #894380 as wontfix: 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10
> > > Why do you have another opinion? Is there anything different on 
> > > upstream's side that has changed since Eugene's comment?
> > 
> > His reasoning from my understanding was to not divert from upstream
> > and set experimental features as default.
> > Now with the cherry-picked commit "Add dark-bg color scheme + enable
> > colors by default if !NO_COLOR"[1] upstream enabled colors by default.
> > Quote from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10:
> > > If you persuade upstream to change the defaults earlier before the next 
> > > release, I'm open to cherry-picking that.
> 
> OK. I'd suggest you to comment this on #894380, to make it easier to
> find your reasoning.
> 
> > 
> > > Have you had any feedback/input from Eugene?
> > 
> > Unfortunately no.
> 
> ACK.
> 
> 
> Sorry for not commenting this before. From d/changelogs:
> 
> +ncdu (1.16-0.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * New upstream version 1.16 (Closes: #996240)
> +  * d/control:
> +- update build dependencies
> 
> 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?
> 
> Thanks for your work,
> 
>  -- Santiago


Reason for the full quote is to add #894380 and #996240
with this discussion about the RFS


URLs for "jumping" to them (and back)
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996240
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009658

Groeten
Geert Stappers
-- 
Silence is hard to parse


- End forwarded message -

-- 
Groeten
Geert Stappers
-- 
Silence is hard to parse



Bug#1010160: x11-xkb-utils: setxkbmap -layout cz_qwerty loads layout which fails with a particular dead-key combination

2022-04-25 Thread Pavel Sanda
Package: x11-xkb-utils
Version: 7.7+5
Severity: normal
X-Debbugs-Cc: sa...@lyx.org

Dear Maintainer,

for keyboard configuration I use the following command on my system:
setxkbmap -model pc105 -layout "us,cz_qwerty"  -option "grp:alt_shift_toggle"

The cz_qwerty layout works mostly fine, except one singular failure:
dead-key ˇ (caron) + u (the same for upper-case variant ˇ+U).

I am afraid non-native prepared/"fixed" this layout, because the layout
logically ends up with caron+u, which is non-existent in czech while
on all czech keyboards you end up with overring+u (ů, see
https://en.wikipedia.org/wiki/Ring_(diacritic) ).

It renders this layout unusable for continuous czech writing, can it get fixed?
(Or at leat can you give me a hint where to fix this, I expect this could
be two-liner change in some kayboard-layout files...)


-- 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.10.0-13-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x11-xkb-utils depends on:
ii  libc62.31-13+deb11u3
ii  libx11-6 2:1.7.2-1
ii  libxaw7  2:1.0.13-1.1
ii  libxkbfile1  1:1.1.0-1
ii  libxt6   1:1.2.0-1

x11-xkb-utils recommends no packages.

x11-xkb-utils suggests no packages.

-- no debconf information


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

2022-04-25 Thread Geert Stappers
Full quote

On Mon, Apr 25, 2022 at 03:25:02PM +0200, Santiago Ruano Rincón wrote:
> El 22/04/22 a las 11:09, Christian Göttsche escribió:
> > > Is it really urgency=medium? low wouldn't fit?
> > 
> > I never used anything else than the default medium; happy to reduce to
> > low if wished.
> 
> I don't think reducing is really needed. I'd upload to a DELAYED queue
> though, which is a different thing, to give Eugene some time to react.
> 
> > > Eugene tagged #894380 as wontfix: 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10
> > > Why do you have another opinion? Is there anything different on 
> > > upstream's side that has changed since Eugene's comment?
> > 
> > His reasoning from my understanding was to not divert from upstream
> > and set experimental features as default.
> > Now with the cherry-picked commit "Add dark-bg color scheme + enable
> > colors by default if !NO_COLOR"[1] upstream enabled colors by default.
> > Quote from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10:
> > > If you persuade upstream to change the defaults earlier before the next 
> > > release, I'm open to cherry-picking that.
> 
> OK. I'd suggest you to comment this on #894380, to make it easier to
> find your reasoning.
> 
> > 
> > > Have you had any feedback/input from Eugene?
> > 
> > Unfortunately no.
> 
> ACK.
> 
> 
> Sorry for not commenting this before. From d/changelogs:
> 
> +ncdu (1.16-0.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * New upstream version 1.16 (Closes: #996240)
> +  * d/control:
> +- update build dependencies
> 
> 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?
> 
> Thanks for your work,
> 
>  -- Santiago


Reason for the full quote is to add #894380 and #996240
with this discussion about the RFS


URLs for "jumping" to them (and back)
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996240
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009658

Groeten
Geert Stappers
-- 
Silence is hard to parse



Bug#1010158: neovim: update to latest upstream release 0.7.*

2022-04-25 Thread Agathe Porte

On Mon, 25 Apr 2022 15:37:10 +0200 Agathe Porte  wrote:

> More and more [0] nvim-related projects are only working on the latest

> nvim release 0.9.* series.

I meant 0.7.* as in the bug title, not 0.9.* as it does not exist at 
this point in time.




Bug#944785: ITP: pufferfish -- An efficient index for the colored, compacted, de Bruijn graph

2022-04-25 Thread Andrius Merkys
Control: block -1 by 1006920

Hello,

Build dependencies for pufferfish 1.8.0+dfsg-1 [1] cannot be satisfied
due to #1006920: twopaco needs older libtbb, while pufferfish needs
newer, and both are not co-installable. I can confirm that applying
patch from #1006920 solves the issue.

However, once #1006920 is out of the way, pufferfish wants to link with
-ltwopaco -lgraphdump -lntcard. However, neither twopaco (seems to be
the source for first two libraries) nor ntcard (source for the last) do
not seem to build shared libraries. Pristine upstream tarball for
pufferfish embeds these projects, thus it is possible they are patched
forks.

[1] salsa git commit 409e6a8dc660a12de6f1239cca106049a7318a3a

Andrius



Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-25 Thread Andrey Rahmatullin
On Sun, Apr 24, 2022 at 10:32:05PM +0200, Tino Mettler wrote:
> > You have actually configured it in the package, so it would be better if
> > it actually works. :) Try just running `autopkgtest` in the source
> > directory..
> > 
> > https://wiki.debian.org/ContinuousIntegration/autopkgtest
> 
> Hi,
> 
> I was not aware that the package defines any test specific bits. Can you 
> point me to the relevant part? I had the impression that a package needs to 
> define the tests in debian/tests/, and the showinfilemanager package does not 
> have a debian/tests directory.
All Python module packages have a minimal automatic autopkgtest that tries
to import the module. Make sure the module name used by the test is
correct, and if it isn't you should set the correct one in
debian/tests/autopkgtest-pkg-python.conf (see e.g. python-xlib and the
relevant documentation in autodep8(1)).


-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-25 Thread gregor herrmann
On Mon, 25 Apr 2022 09:31:50 -0400, Antoine Beaupré wrote:

> On 2022-04-24 22:32:05, Tino Mettler wrote:
> > Am 24.04.2022 um 22:04 schrieb Antoine Beaupré :

> > I was not aware that the package defines any test specific bits. Can you 
> > point me to the relevant part? I had the impression that a package needs to 
> > define the tests in debian/tests/, and the showinfilemanager package does 
> > not have a debian/tests directory.
> Uh. Weird. I guess I can't explain that then and that the package can
> just be uploaded already. :)

Maybe this gives a hint:

| autopkgtest [15:28:00]: test autodep8-python3: [---
   


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   BOFH excuse #447:  According to Microsoft, it's by design 



Bug#1010152: emacs-gtk: tries to read a config file from another user's home dir

2022-04-25 Thread Vincent Lefevre
Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42827

On 2022-04-25 15:37:08 +0200, Vincent Lefevre wrote:
> This is also fixed in upstream's 27.2.

2020-08-17  Robert Pluim  

Fix bug with ~/Emacs file not being read at init

* src/xrdb.c (get_user_app): Put "/" between homedir
and %L or %N (Bug#42827).

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



Bug#1010152: emacs-gtk: tries to read a config file from another user's home dir

2022-04-25 Thread Vincent Lefevre
On 2022-04-25 15:23:43 +0200, Vincent Lefevre wrote:
> I can reproduce the issue with upstream's 27.1 version:
> 
> 11openat(AT_FDCWD, "/home/vlefevrePOSIX/Emacs", O_RDONLY) = -1 ENOENT (No 
> such file or directory)
> 11openat(AT_FDCWD, "/home/vlefevreEmacs", O_RDONLY) = -1 ENOENT (No such 
> file or directory)
> 
> but not with master:
> 
> 481514 openat(AT_FDCWD, "/home/vlefevre/POSIX/Emacs", O_RDONLY) = -1 ENOENT 
> (No such file or directory)
> 481514 openat(AT_FDCWD, "/home/vlefevre/Emacs", O_RDONLY) = -1 ENOENT (No 
> such file or directory)
> 
> (this was actually a missing slash after the home dir).

This is also fixed in upstream's 27.2.

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



Bug#1010158: neovim: update to latest upstream release 0.7.*

2022-04-25 Thread Agathe Porte
Package: neovim
Version: 0.6.1-3
Severity: wishlist
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

More and more [0] nvim-related projects are only working on the latest
nvim release 0.9.* series. It would be nice to have neovim updated
to the latest upstream version before the freeze comes [1].

Kind regards,

Agata.

[0] https://astronvim.github.io/
[1] https://lists.debian.org/debian-devel/2022/03/msg00251.html



Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-25 Thread Antoine Beaupré
Control: owner -1 anar...@debian.org

On 2022-04-24 22:32:05, Tino Mettler wrote:
> Am 24.04.2022 um 22:04 schrieb Antoine Beaupré :
>> 
>> You have actually configured it in the package, so it would be better if
>> it actually works. :) Try just running `autopkgtest` in the source
>> directory..
>> 
>> https://wiki.debian.org/ContinuousIntegration/autopkgtest
>
> Hi,
>
> I was not aware that the package defines any test specific bits. Can you 
> point me to the relevant part? I had the impression that a package needs to 
> define the tests in debian/tests/, and the showinfilemanager package does not 
> have a debian/tests directory.

Uh. Weird. I guess I can't explain that then and that the package can
just be uploaded already. :)

I'll do that now.

A.

-- 
The difference between a democracy and a dictatorship is that in a
democracy you vote first and take orders later; in a dictatorship you
don't have to waste your time voting.
 - Charles Bukowski



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

2022-04-25 Thread Santiago Ruano Rincón
El 22/04/22 a las 11:09, Christian Göttsche escribió:
> > Is it really urgency=medium? low wouldn't fit?
> 
> I never used anything else than the default medium; happy to reduce to
> low if wished.

I don't think reducing is really needed. I'd upload to a DELAYED queue
though, which is a different thing, to give Eugene some time to react.

> > Eugene tagged #894380 as wontfix: 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10
> > Why do you have another opinion? Is there anything different on upstream's 
> > side that has changed since Eugene's comment?
> 
> His reasoning from my understanding was to not divert from upstream
> and set experimental features as default.
> Now with the cherry-picked commit "Add dark-bg color scheme + enable
> colors by default if !NO_COLOR"[1] upstream enabled colors by default.
> Quote from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894380#10:
> > If you persuade upstream to change the defaults earlier before the next 
> > release, I'm open to cherry-picking that.

OK. I'd suggest you to comment this on #894380, to make it easier to
find your reasoning.

> 
> > Have you had any feedback/input from Eugene?
> 
> Unfortunately no.

ACK.


Sorry for not commenting this before. From d/changelogs:

+ncdu (1.16-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream version 1.16 (Closes: #996240)
+  * d/control:
+- update build dependencies

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?

Thanks for your work,

 -- Santiago


signature.asc
Description: PGP signature


Bug#1010152: emacs-gtk: tries to read a config file from another user's home dir

2022-04-25 Thread Vincent Lefevre
Control: tags upstream fixed-upstream

I can reproduce the issue with upstream's 27.1 version:

11openat(AT_FDCWD, "/home/vlefevrePOSIX/Emacs", O_RDONLY) = -1 ENOENT (No 
such file or directory)
11openat(AT_FDCWD, "/home/vlefevreEmacs", O_RDONLY) = -1 ENOENT (No such 
file or directory)

but not with master:

481514 openat(AT_FDCWD, "/home/vlefevre/POSIX/Emacs", O_RDONLY) = -1 ENOENT (No 
such file or directory)
481514 openat(AT_FDCWD, "/home/vlefevre/Emacs", O_RDONLY) = -1 ENOENT (No such 
file or directory)

(this was actually a missing slash after the home dir).

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



Bug#988068: Another case where the current apparmor profile causes problems

2022-04-25 Thread Henrik Christian Grove



Instead of wasting time configuring and running a location service, I 
just had a number of slightly different configuration files for redshift 
(with different manual locations specified) and would just let 
`.config/redshift.conf` be a symlink to the one corresponding to my 
current location. (And do some extra work in new locations)


That didn't work with the discussed restriction (but I could easily put 
all the different configs in `.config/redshift/`.


For now my workaround was simply to replace the symlink with a copy.



Bug#1010156: logiops: systemd incompatibility - mouse mapping does not work

2022-04-25 Thread Hendrik Tews
Package: logiops
Version: 0.2.2-2
Severity: normal
X-Debbugs-Cc: none, Hendrik Tews 

Dear Maintainer,

thanks a lot for packaging this driver!

Unfortunately, the packaged version is incompatible with the
version of systemd currently shipped in testing, see
https://github.com/PixlOne/logiops/commit/911e91eeebf72417d081e2b0f7e3d4c6db83c37b

For me, the symptom is that button remapping of my MX Master 3
mouse does not work, while the invert hiresscroll feature did
work.

The upstream version from github works fine for me.

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

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

Versions of packages logiops depends on:
ii  libc6   2.33-7
ii  libconfig++9v5  1.5-0.4
ii  libevdev2   1.12.1+dfsg-1
ii  libgcc-s1   12-20220319-1
ii  libstdc++6  12-20220319-1
ii  libudev1250.4-1

logiops recommends no packages.

logiops suggests no packages.

-- Configuration Files:
/etc/logid.cfg changed:
devices: ({
  name: "Wireless Mouse MX Master 3";
  # A lower threshold number makes the wheel switch to free-spin mode
  # quicker when scrolling fast.
  smartshift: {
on: false;
threshold: 3;
  };
  hiresscroll: {
hires: true;
invert: false;
target: false;
  };
  # Higher numbers make the mouse more sensitive (cursor moves faster),
  # 4000 max for MX Master 3.
  dpi: 1000;
  buttons: (
# Make thumb button 2.
{ cid: 0xc3;
  action = {
type: "Keypress";
keys: ["BTN_MIDDLE"];
  };
},
# top button
{ cid: 0xc4;
  action = {
type = "ToggleSmartshift";
  };
}
  );
});


-- no debconf information

Bye,

Hendrik



  1   2   >