Bug#972326: thunderbird extensions no longer work

[Carsten Schoenert]

Hello Brett,

Am 17.10.20 um 00:57 schrieb Brett Gilio:
> Could you specify what the behavior is? Something like toggling word
> wrap doesn't appear to be an extension, but is a built in behavior. If
> this is the case, then perhaps our build of Thunderbird is improper.

can we please stop this useless discussion.

There isn't something that the Thunderbird package needs to wait on.
There are the control fields Depends and Breaks that declare the
relation of packages. If the user is installing Add-ons then he is doing
this on his own and needs to in specific case talk to upstream if
something isn't working well.

This all isn't a Debian specific issue, it is also happen with the
upstream packages of Thunderbird.

-- 
Regards
Carsten Schoenert

Bug#972371: debian-reference: Add CI to ensure that git is buildable

[Stuart Prescott]

Source: debian-reference
Version: 2.76
Severity: important

Dear Maintainer,

While looking at #942942, I needed to be able to build the debian-reference
package to check that my changes made sense. Unfortunately, the git 'master'
branch is not currently buildable as many po syntax errors have been
committed to git.

The repo currently contains committed git conflict markers which are not
valid .po syntax:

#. type: Content of: 
#, no-wrap
msgid ""
"$ zcat \"/usr/share/doc/base-passwd/users-and-groups.txt.gz\" | 
sensible-pager\n"
"$ sensible-browser \"/usr/share/doc/base-passwd/users-and-groups.html\"\n"
"$ sensible-browser \"https://www.debian.org\";
msgstr ""
<<< HEAD
"$ zcat \"/usr/share/doc/base-passwd/users-and-groups.txt.gz\" | 
sensible-pager\n"
===
"$ zcat \"/usr/share/doc/base-passwd/users-and-groups.txt.gz\" | sensible-"
"pager\n"
>>> weblate
"$ sensible-browser \"/usr/share/doc/base-passwd/users-and-groups.html\"\n"
"$ sensible-browser \"https://www.debian.org\";


At present:

$ grep -c -e '<<< HEAD' po/{es,ja}.po
po/es.po:6
po/ja.po:13

Of course there are other sorts of syntax errors beyond git conflict markers
that could be added to git. The gitlab repo on salsa.debian.org could perform
CI builds of the debian-reference package (or even just run a checker over the
.po files) to ensure that the repo is in good shape, and to flag when
mistakes have crept in.

regards
Stuart

Bug#972370: RM: rclone [mipsel] -- ROM; FTBFS on mipsel

[Drew Parsons]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 971...@bugs.debian.org, debian...@lists.debian.org, 
debian-m...@lists.debian.org

Dear ftpmaster,

rclone has been consistently FTBFS on mipsel (see Bug#971932).

Could you therefore remove rclone for mipsel on unstable (and
testing), so that mipsel does not continue to hold up rclone package
migration to testing for other arches?

Thanks,
Drew

Bug#959407: support PEP 581 now!

[Drew Parsons]

forcemerge 959407 972368
retitle 959407 dh-python: support pyproject.toml builds (PEP 518) 
without setup.py

thanks

Activating the flit plugin is not sufficient to enable pyproject.toml 
builds.


As the pybuild man page says, "These can be identified by the presence 
of a

build-backend = "flit_core.buildapi" element in pyproject.toml."

flit doesn't support pyproject.toml builds in general.

If you place
  Build-Depends: python3-toml, flit
in debian/control, and
  export PYBUILD_SYSTEM=flit
in debian/rules, then if pyproject.toml does not support flit
you get the build error

 dh_auto_build -O--buildsystem=pybuild
  E: pybuild pybuild:352: build: plugin flit failed with: TOML file 
missing [tool.flit] table.
  dh_auto_build: error: pybuild --build -i python{version} -p "3.9 3.8" 
returned exit code 13

  make: *** [debian/rules:7: build] Error 13
  dpkg-buildpackage: error: debian/rules build subprocess returned exit 
status 2

Bug#955335: tracker.debian.org: add versions/packages links to Repology project-by tool

[Paul Wise]

On Mon, 30 Mar 2020 12:07:35 +0800 Paul Wise wrote:

> In the links panel please add at the end an "Other distros" or "Other
> distro packages" link (with title "provided by Repology") pointing at
> the packages list for the Repology project corresponding to the current
> Debian source package.
> 
> https://repology.org/tools/project-by?repo=debian_$suite_type=srcname_page=project_packages=$srcpkg

This part is now implemented and deployed:

https://salsa.debian.org/qa/distro-tracker/commit/894cb4fe7364579fde3b8005215421a1ecab6c82

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#972369: ITP: mdview -- Markdown View - Command line utility to format markdown and launch it in a browser.

[Mark Pitman]

Package: wnpp
Owner: Mark Pitman 
Severity: wishlist

* Package name: mdview
  Version : 1.4.0
  Upstream Author : Mark Pitman 
* URL : https://github.com/mapitman/mdview/
* License : MIT
  Programming Lang: Go
  Description : Markdown View - Command line utility to format markdown and 
launch it in a browser.

This is a commandline utility that I wrote. I've packaged it as a snap
and had some feedback from a few people
who use it. Because of the limitations of snap packages, it makes
more sense to package it as a native package.

I'm not aware of any other packages that offer the same functionality.

I'm not looking for co-maintainers, but I wouldn't turn them away either!

I would need a sponsor in order to get the package into a Debian repository.

Bug#969067: HELP (New User - Resolved by Professional Help)

[The Mike Jenkins]

>
>
> Leading up to situation: I am 3 years newbie to IT in general and have been 
> learning to install linux on pc hardware to replace windows. I have only 
> worked with Ubuntu and OpenSUSE and was not knowledgeable enough to complete 
> a custom Debian Install.
>
> Debug remote automatic email: I used my email and inadvertently authorized it 
> to send information that may cause security vu;nerabilities, otherwise I am 
> ok with my computer information being used if helpful.
>
> Acquired Professional Help Reinstalling as VM.
>
> I hope to have any information removed that may jeopardize my computer 
> security, or request that my personal information is removed from google 
> search.
>
> "I was advised that I shared important information in my bug report that is a 
> security risk, I would like to request that the bug report be removed from 
> the public search domain or deleted if possible. I will respond to the 
> appropriate bug report with what information I have. I have made an 
> additional donation to the cause in good faith for your assistance with 
> removing my report from the public search domain."
>
>
> Best Regards,
>
> Mike J.
>
> [image: image.png]
>
>
>>

Bug#969067: Acknowledgement (installation-reports: installation report)

[The Mike Jenkins]

Leading up to situation: I am 3 years newbie to IT in general and have
been learning to install linux on pc hardware to replace windows. I
have only worked with Ubuntu and OpenSUSE and was not knowledgeable
enough to complete a custom Debian Install.

Debug remote automatic email: I used my email and inadvertently
authorized it to send information that may cause security
vu;nerabilities, otherwise I am ok with my computer information being
used if helpful.

Acquired Professional Help Reinstalling as VM.

I hope to have any information removed that may jeopardize my computer
security, or request that my personal information is removed from
google search.

"I was advised that I shared important information in my bug report
that is a security risk, I would like to request that the bug report
be removed from the public search domain or deleted if possible. I
will respond to the appropriate bug report with what information I
have. I have made an additional donation to the cause in good faith
for your assistance with removing my report from the public search
domain."


Best Regards,

Mike J.

[image: image.png]



On Wed, Aug 26, 2020 at 5:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 969067:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969067.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   themikej...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian Install Team 
>
> If you wish to submit further information on this problem, please
> send it to 969...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 969067: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969067
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#972368: dh-python: support pyproject.toml builds (PEP 518) without setup.py

[Drew Parsons]

Package: dh-python
Version: 4.20200925
Severity: normal

pyproject.toml (PEP 518) is the New Thing for python module builds.
Many projects have switched to it, deleting setup.py and introducing a
pyproject.toml file.

pybuild currently does not support pyproject.toml. When
upstream switches to PEP 518, the package build suddenly starts to fail
e.g. dmsh

   fakeroot debian/rules clean
  dh clean --with python3 --buildsystem=pybuild
 dh_auto_clean -O--buildsystem=pybuild
  I: pybuild base:217: python3.9 setup.py clean 
  python3.9: can't open file '/projects/build/python-dmsh/setup.py': [Errno 2] 
No such file or directory
  E: pybuild pybuild:352: clean: plugin distutils failed with: exit code=2: 
python3.9 setup.py clean 
  dh_auto_clean: error: pybuild --clean -i python{version} -p "3.9 3.8" 
returned exit code 13
  make: *** [debian/rules:5: clean] Error 13
  dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned 
exit status 2


There is partial support for pyproject.toml builds using flit (PEP 517
builds). But as the pybuild man page says, "These can be identified by the 
presence of a
build-backend = "flit_core.buildapi" element in pyproject.toml."
flit doesn't support pyproject.toml builds in general.

Filing this bug to request more general support for pyproject.toml
builds.



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

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

Versions of packages dh-python depends on:
ii  python33.8.6-1
ii  python3-distutils  3.8.6-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.20.5
ii  libdpkg-perl  1.20.5

-- no debconf information

Bug#972367: ITP: nemo-image-converter -- nemo extension to mass resize or rotate images

[Joshua Peisach]

Package: wnpp
Severity: wishlist
Owner: Joshua Peisach 

* Package name: nemo-image-converter
  Version : 4.6.0
  Upstream Author : Julien Lavergne 
* URL : https://github.com/linuxmint/nemo-
extensions/tree/master/nemo-image-converter
* License : GPL-2+
  Programming Lang: C
  Description : nemo extension to mass resize or rotate images

This package adds a "Resize Images..." menu item to
the context menu of all images. This opens a dialog
where you set the desired image size and file name.
A click on "Resize" finally resizes the image(s)
using ImageMagick's convert tool.

I will maintain this by myself and then hopefully move it into cinnamon-team

Bug#970896: lintian times out while analyzing package

[Inaki Malerba]

Hey there!

Even though I couldn't reproduce it locally ( :/ ) it was 100%
reproducible on salsa ci.

Just retried a job with lintian==2.98.0 and it seems to be fixed :)

Same job from the original report:
https://salsa.debian.org/ina/mediawiki/-/jobs/1079414

Another failing job:
https://salsa.debian.org/ina/svxlink/-/jobs/1079386


Thanks a lot !

-- 
- ina



signature.asc
Description: OpenPGP digital signature

Bug#966638: gkrellm-cpufreq: Error: /usr/lib/gkrellm2/plugins/cpufreq.so: undefined symbol: cpufreq_cpu_exists

[Bernhard Übelacker]

Dear Maintainer,
it seems like previous versions just optimized the call to
cpufreq_cpu_exists away? The current build relies to have the
symbol external defined.
Attached patch tries to query the number of CPUs from another
function and (kind of ugly) avoids a later crash if frequencies
could not be queried.
Therefore and because the last upstream version is from 2006
one might ask if this package is really still useful?
(At least on amd64?)

Kind regards,
Bernhard
Description: Get number of CPUs

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/966638
Forwarded: no
Last-Update: 2020-10-16

Index: gkrellm2-cpufreq-0.6.4/cpufreq.c
===
--- gkrellm2-cpufreq-0.6.4.orig/cpufreq.c
+++ gkrellm2-cpufreq-0.6.4/cpufreq.c
@@ -49,6 +49,7 @@
 
 #include 
 #include 
+#include 
 
 /* version number */
 #define  VERSION"0.6.4"
@@ -616,8 +617,7 @@ GkrellmMonitor* gkrellm_init_plugin(void
   monitor = _mon;
 
   /* determine number of cpus */
-  for( ncpu = 0; cpufreq_cpu_exists(ncpu)==0; ++ncpu )
-;
+  ncpu = get_nprocs();
   ncpu = ncpu > NCPU_MAX ? NCPU_MAX : ncpu;
 
   /* determine maximal frequency */
@@ -625,7 +625,10 @@ GkrellmMonitor* gkrellm_init_plugin(void
   for ( cpu = 0; cpu

Bug#964791: [Pkg-opencl-devel] Bug#964791: Bug#964791: libclc-amdgcn: OpenCL fails to start

[Rebecca N. Palmer]

The error message has gone for me as well, but I don't have the hardware 
to tell whether mesa-opencl-icd actually works.  Have you checked this?


I agree that this is probably the same bug as #964973, which is marked 
as fixed.

Bug#972366: debian-installer: It may be illegal not to set wireless regulatory domain

[Ryutaroh Matsumoto]

Package: debian-installer
Version: 20200314
Severity: important

Dear Maintainer,

According to
https://wireless.wiki.kernel.org/en/developers/regulatory

when a wireless interface is used by Linux, wireless regulatory
domain must be set to comply the laws.
But current installer does not seem to set it.

As far as I know, it can be set by
REGDOMAIN in /etc/default/crda of crda package, or
country in /etc/wpa_cupplicant/wpa_supplicant.conf

There seems no way to set wireless reg. domain by ifupdown.

Worse, NetworkManager seems to overwrite it, as
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1232928
https://bugzilla.gnome.org/show_bug.cgi?id=720331

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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

-- no debconf information

Bug#969941: ITP: golang-github-elisescu-pty -- Golang package for using Unix pseudo-terminals

[Francisco Vilmar Cardoso Ruviaro]

Hi,

as an informational, golang-github-elisescu-pty-dev is one of the Build-Depends
for tty-share.


Debian Bug report logs - #969942
ITP: tty-share -- Terminal sharing over the Internet
https://bugs.debian.org/969942

Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#969942: ITP: tty-share -- Terminal sharing over the Internet

[Francisco Vilmar Cardoso Ruviaro]

Hi,

as an informational, golang-github-elisescu-pty-dev is one of the Build-Depends
for tty-share.


Debian Bug report logs - #969941
ITP: golang-github-elisescu-pty -- Golang package for using Unix 
pseudo-terminals
https://bugs.debian.org/969941

Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#937184: Python 3 port of offlineimap underway

[Brett Gilio]

Sudip Mukherjee  writes:
>
> upstream is asking to treat offlineimap and offlineimap3 as separate
> package. https://github.com/OfflineIMAP/offlineimap3/issues/10

I think we should preserve offlineimap until offlineimap3 is released,
and then we can probably rename offlineimap3 once offlineimap is
considered unsupported by the maintainers.

Thoughts?

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Bug#896458: RFH: SWI-Prolog in Debian

[Brett Gilio]

Lev Lamberov  writes:

> Hi Brett,
>
>> Hello all. If there is still interest in needing co-maintenance on this
>> package, I would be willing to help.
>
> yes, there is still an interest in help with swi-prolog in Debian.
>
> What do you plan to do? If you're not quite sure for now, you can start
> by triaging bugs reported to Debian BTS. But honestly, there are not so
> much of them.
>
> Cheers!
> Lev

Hi Lev,

I was hoping to help keep it upto date, and triage any bugs against it.
Additionally, I was able to get SWIPL to build reproducibly when I
packaged it for GNU Guix (where I also maintain SWIPL), and was wanting
to be able to do the same for Debian.


-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Bug#972335: i3lock: Cannot read image from pipe

[Brett Gilio]

Cédric Hannotier  writes:

> Package: i3lock
> Version: 2.11.1-1
> Severity: normal
>
> Dear Maintainer,
>
> Reading image from stdin throws OOM.
> It has been reported in [1].
> It is solved using option --raw introduced in [2].
> It is included in last release [3].
>
> Could you please upgrade i3lock to v2.12?
> It was release more than 1 year ago.
>

It looks as though this package needs to be marked as orphaned. Would you report
it as such to WNPP?

https://www.debian.org/devel/wnpp/

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Bug#972326: thunderbird extensions no longer work

[Brett Gilio]

Alain Knaff  writes:
> Extensions no longer work since recent update.
>
> Examples: QuickFolders, Toggle Word Wrap, DOM Instepctor Plus!, Dorando
> keyconfig, ...
>
> Please only push new thunderbird versions once it is clear that they work.

Could you specify what the behavior is? Something like toggling word
wrap doesn't appear to be an extension, but is a built in behavior. If
this is the case, then perhaps our build of Thunderbird is improper.

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Bug#972033: Bug#969650: Bug#972033: python3.9, dask, pandas 1.1

[Rebecca N. Palmer]

Control: tags -1 - pending

The package currently in Salsa doesn't work.  test_statsmodels is 
probably a circular dependency that should be ignored for now; 
TestHDFStore is under investigation.


=== FAILURES 
===
 TestHDFStore.test_append_frame_column_oriented 



self = 0x7f753e5ba2e0>

setup_path = 'tmp.__PxTZkyR5w5__.h5'


@pytest.mark.xfail(condition=is_crashing_arch,reason="https://bugs.debian.org/790925",strict=False,run=False)
def test_append_frame_column_oriented(self, setup_path):
with ensure_clean_store(setup_path) as store:

# column oriented
df = tm.makeTimeDataFrame()
df.index = df.index._with_freq(None)  # freq doesnt round-trip

_maybe_remove(store, "df1")
store.append("df1", df.iloc[:, :2], axes=["columns"])
store.append("df1", df.iloc[:, 2:])
tm.assert_frame_equal(store["df1"], df)

result = store.select("df1", "columns=A")
expected = df.reindex(columns=["A"])
tm.assert_frame_equal(expected, result)

# selection on the non-indexable
result = store.select("df1", ("columns=A", 
"index=df.index[0:4]"))

expected = df.reindex(columns=["A"], index=df.index[0:4])
tm.assert_frame_equal(expected, result)

# this isn't supported
with pytest.raises(TypeError):
>   store.select("df1", "columns=A and index>df.index[4]")

pandas/tests/io/pytables/test_store.py:1336:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

pandas/io/pytables.py:876: in select
return it.get_result()
pandas/io/pytables.py:1930: in get_result
results = self.func(self.start, self.stop, where)
pandas/io/pytables.py:860: in func
return s.read(start=_start, stop=_stop, where=_where, columns=columns)
pandas/io/pytables.py:4483: in read
result = self._read_axes(where=where, start=start, stop=stop)
pandas/io/pytables.py:3682: in _read_axes
selection = Selection(self, where=where, start=start, stop=stop)
pandas/io/pytables.py:5167: in __init__
self.terms = self.generate(where)
pandas/io/pytables.py:5180: in generate
return PyTablesExpr(where, queryables=q, encoding=self.table.encoding)
pandas/core/computation/pytables.py:573: in __init__
self.terms = self.parse()
pandas/core/computation/expr.py:806: in parse
return self._visitor.visit(self.expr)
pandas/core/computation/expr.py:398: in visit
return visitor(node, **kwargs)
pandas/core/computation/expr.py:404: in visit_Module
return self.visit(expr, **kwargs)
pandas/core/computation/expr.py:398: in visit
return visitor(node, **kwargs)
pandas/core/computation/expr.py:407: in visit_Expr
return self.visit(node.value, **kwargs)
pandas/core/computation/expr.py:398: in visit
return visitor(node, **kwargs)
pandas/core/computation/expr.py:726: in visit_BoolOp
return reduce(visitor, operands)
pandas/core/computation/expr.py:720: in visitor
rhs = self._try_visit_binop(y)
pandas/core/computation/expr.py:715: in _try_visit_binop
return self.visit(bop)
pandas/core/computation/expr.py:398: in visit
return visitor(node, **kwargs)
pandas/core/computation/expr.py:699: in visit_Compare
return self.visit(binop)
pandas/core/computation/expr.py:398: in visit
return visitor(node, **kwargs)
pandas/core/computation/expr.py:520: in visit_BinOp
op, op_class, left, right = self._maybe_transform_eq_ne(node)
pandas/core/computation/expr.py:441: in _maybe_transform_eq_ne
right = self.visit(node.right, side="right")
pandas/core/computation/expr.py:398: in visit
return visitor(node, **kwargs)
pandas/core/computation/pytables.py:430: in visit_Subscript
return self.const_type(value[slobj], self.env)
pandas/core/indexes/extension.py:215: in __getitem__
result = self._data[key]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _


self = 
['2000-01-03 00:00:00', '2000-01-04 00:00:00', '2000-01-05 00:00:00',
 '2000-01-06 00:00:00', '2000-01...2-08 00:00:00',
 '2000-02-09 00:00:00', '2000-02-10 00:00:00', '2000-02-11 00:00:00']
Length: 30, dtype: datetime64[ns]
key = 4

def __getitem__(self, key):
"""
This getitem defers to the underlying array, which 
by-definition can

only handle list-likes, slices, and integer scalars
"""

if lib.is_integer(key):
# fast-path
result = self._data[key]
if self.ndim == 1:
return self._box_func(result)
return self._simple_new(result, dtype=self.dtype)

if com.is_bool_indexer(key):
# first convert to boolean, because check_array_indexer doesn't
# allow object dtype
if is_object_dtype(key):
key = np.asarray(key, dtype=bool)

key = 

Bug#968104: openafs-client: Upgrade of openfs-client break until reboot

[Jose M Calhariz]

Hi,

I think I found the problem for this bug.  I made an apt-get upgrade
of a machine running kernel 4.19.0-8-amd64 with many pending updates.

I found this squence of events:
  - the script that cleans the old dkms modules is run,
  - openafs-client is restarted,
  - the new dkms modules are built.

This means that when openafs-client is restart there is no openafs
module.  After I run "systemctl stop openafs-client ; systemctl start
openafs-client", the OpenAFS is OK again.

If you need more details to chase down this bug I can provide the full
output of the "apt-get upgrade"


Kind regards
Jose M Calhariz

-- 
--

As palavras enchem o espaço. Eu prefiro encher a carteira

--Andy Warhol


signature.asc
Description: PGP signature

Bug#972246: numba ftbfs in unstable with python3.9 as supported python3 version

[Stefano Rivera]

Looks like it's going to take a while to get Python 3.9 support in the
numba stack:
https://github.com/numba/numba/issues/6345#issuecomment-706722002

This isn't just a little python library, it's a Python JIT for Python,
so I'd believe that supporting 3.9 is non-trivial.

SR

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

Bug#972364: ITP: osk-sdl -- Onscreen keyboard for unlocking LUKS devices

[undef]

Package: wnpp
Severity: wishlist
Owner: undef 

* Package name    : osk-sdl
  Version : 0.58
  Upstream Author : Oliver Smith 
* URL : https://gitlab.com/postmarketOS/osk-sdl
* License : GPLv3
  Programming Lang: C++
  Description : Onscreen keyboard for unlocking LUKS devices

An on-screen keyboard used to unlock the encrypted root partition on
mobile devices.

This package is a dependency for full disk encryption with user held
passwords
on devices which do not have a non-touchscreen input device. It
implements the
same functionality as cryptsetup-initramfs, but also includes the input
device.

The package will be maintained inside the Debian on Mobile team.

Bug#972357: [INTL:sv] Swedish debconf template, fixing charset (no strings update)

[Felix Lechner]

Hi Laura,

On Fri, Oct 16, 2020 at 1:43 PM Laura Arjona Reina  wrote:
>
> https://i18n.debian.org/l10n-pkg-status/m/mdadm.html

I updated several translations recently, but not Swedish. That means I
should check the encoding before requesting new translations, right?

Kind regards
Felix Lechner

Bug#972363: etesync-dav: unsatisfiable build dependencies: python3-radicale (<< 2.1.12)

[Andreas Beckmann]

Source: etesync-dav
Version: 0.17.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

etesync-dav/experimental cannot be built any more since it build-depends on
python3-radicale (<< 2.1.12) while sid already has 2.1.12-1.

Andreas

Bug#972357: [INTL:sv] Swedish debconf template, fixing charset (no strings update)

[Laura Arjona Reina]

Hi Felix

The data in unstable is parsed in several ways, for a particular package
I guess the URL to see the status of the po-debconf templates is:
https://i18n.debian.org/l10n-pkg-status/X/name_of_package.html
X being the initial of the name of the package. For example, for mdadm:

https://i18n.debian.org/l10n-pkg-status/m/mdadm.html

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#967079: gimp: After completing a batch conversion with David's Batch Processor, pressed Close button and got Crash message for the batch program and shortly after for GIMP itself.

[Bernhard Übelacker]

> #6  0x7f3e13f61730 in  () at 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #7  0x7f3e1424ceba in g_type_check_value_holds () at 
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #8  0x7f3e142526f9 in g_value_get_int () at 
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #9  0x5604fd828b2b in plug_in_params_to_args ()
> #10 0x5604fd81d003 in gimp_plug_in_handle_message ()
> #11 0x5604fd81baa1 in  ()
> #12 0x7f3e14145dd8 in g_main_context_dispatch () at 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #13 0x7f3e141461c8 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #14 0x7f3e141464c2 in g_main_loop_run () at 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #15 0x5604fd584cb7 in app_run ()
> #16 0x5604fd5845b5 in main ()


Dear Maintainer,
the given backtrace might point to this upstream [1] and
another similar downstream [2] issue.

[1] https://gitlab.gnome.org/GNOME/gimp/-/issues/4064
[2] https://bugs.archlinux.org/task/60769

Kind regards,
Bernhard

Bug#972171: MR created to fix this bug

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 + patch

Hi! I have just created a MR in order to solve this bug:

https://salsa.debian.org/georgesk/turing/-/merge_requests/1

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#968005: gimp: install the application well, it did not give any error but when executing it gave a serious error

[Bernhard Übelacker]

Dear Maintainer,
from the submitters attached log I guess
the part in [2] is relevant.

This led to the upstream bug in [1].

Downstream there seem to be also some duplicates:
  #953880, #953854, #953794, #954095, #954739

This seems to be fixed in testing since gimp 2.10.14-3,
but due to this report also stable seems to be affected.

Kind regards,
Bernhard


[1] https://gitlab.gnome.org/GNOME/gimp/-/issues/4392

[2] ...
#5  
#6  0x55d6ef753e3b in gimp_param_spec_layer_id ()
#7  0x55d6ef6777ed in gimp_pdb_compat_param_spec ()
#8  0x55d6ef684077 in gimp_plug_in_handle_message ()
#9  0x55d6ef692501 in gimp_plug_in_manager_call_query ()
#10 0x55d6ef68a5b8 in gimp_plug_in_manager_restore ()
...

Bug#972166: Adding patch

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 + patch

Hi! I'm attaching a patch to solve this issue.

Note that this patch applies over the latest NMU, not yet in salsa.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
diff --git a/debian/changelog b/debian/changelog
index f8251b4..96bea2c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+odin (2.0.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove qt5-default from build depends (Closes: #972166).
+- Export QT_SELECT := qt5 in order to let qtchooser use the right Qt version.
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Fri, 16 Oct 2020 17:31:44 -0300
+
 odin (2.0.3-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 00de06d..92d7f99 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,6 @@ Build-Depends: debhelper-compat (= 12),
libismrmrd-dev [!armhf],
libnifti-dev,
libpng-dev,
-   qt5-default,
qtbase5-dev,
libqwt-qt5-dev,
libvtk6-dev,
diff --git a/debian/rules b/debian/rules
index f5343ff..064d8a0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,8 @@ include /usr/share/dpkg/buildflags.mk
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+export QT_SELECT := qt5
+
 DCMMAJOR := $(shell readlink -f /usr/lib/libdcmimgle.so | cut -f3 -d.)
 
 %:
From 9a8a220167002ffd9a7874619b7ae3a9324d2f27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lisandro=20Dami=C3=A1n=20Nicanor=20P=C3=A9rez=20Meyer?=
 
Date: Fri, 16 Oct 2020 17:47:55 -0300
Subject: [PATCH] Remove qt5-default from build depends (Closes: #972166).

---
 debian/changelog | 8 
 debian/control   | 1 -
 debian/rules | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index c6ffa14..e463c36 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+odin (2.0.4-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove qt5-default from build depends (Closes: #972166).
+- Export QT_SELECT := qt5 in order to let qtchooser use the right Qt version.
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Fri, 16 Oct 2020 17:47:32 -0300
+
 odin (2.0.4-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index 00de06d..92d7f99 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,6 @@ Build-Depends: debhelper-compat (= 12),
libismrmrd-dev [!armhf],
libnifti-dev,
libpng-dev,
-   qt5-default,
qtbase5-dev,
libqwt-qt5-dev,
libvtk6-dev,
diff --git a/debian/rules b/debian/rules
index f5343ff..064d8a0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,8 @@ include /usr/share/dpkg/buildflags.mk
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+export QT_SELECT := qt5
+
 DCMMAJOR := $(shell readlink -f /usr/lib/libdcmimgle.so | cut -f3 -d.)
 
 %:
-- 
2.28.0

Bug#707750: Info received (Help with mariadb-10.3 cross-building)

[Helmut Grohne]

Control: reopen -1
Control: affects -1 - src:mariadb-10.3

Hi,

On Sat, Aug 22, 2020 at 12:49:50PM +0300, Otto Kekäläinen wrote:
> In MariaDB 10.4 and onwards, the server itself (but in 10.5 and
> onwards not in ColumnStore) the libreadline has been replaced with
> libedit, so this issue can be closed when 10.4 or 10.5 lands in Debian
> unstable.

No. The coinstallability issue in libreadline-gplv2-dev remains. It
merely stopped affecting mariadb.

Helmut

Bug#972362: efl FTCBFS: version check too strict for binNMUs

[Helmut Grohne]

Source: efl
Version: 1.24.3-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

efl fails to cross build from source since it was binNMUed. Now the
cross tool version check fails. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru efl-1.24.3/debian/changelog efl-1.24.3/debian/changelog
--- efl-1.24.3/debian/changelog 2020-08-11 06:56:02.0 +0200
+++ efl-1.24.3/debian/changelog 2020-10-16 21:32:00.0 +0200
@@ -1,3 +1,10 @@
+efl (1.24.3-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix cross tool version check to cope with binNMUs. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 16 Oct 2020 21:32:00 +0200
+
 efl (1.24.3-5) unstable; urgency=medium
 
   * Upload to unstable, no further changes.
diff --minimal -Nru efl-1.24.3/debian/rules efl-1.24.3/debian/rules
--- efl-1.24.3/debian/rules 2020-08-11 06:54:29.0 +0200
+++ efl-1.24.3/debian/rules 2020-10-16 21:29:25.0 +0200
@@ -32,10 +32,10 @@
 override_dh_auto_configure:
 # cross-builds need host eolian_gen, but ensure the versions match
 ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
-   test "`dpkg-query -f '$${Version}' -W libedje-bin`" = "$(DEB_VERSION)"
-   test "`dpkg-query -f '$${Version}' -W libeet-bin`" = "$(DEB_VERSION)"
-   test "`dpkg-query -f '$${Version}' -W libelementary-bin`" = 
"$(DEB_VERSION)"
-   test "`dpkg-query -f '$${Version}' -W libeolian-bin`" = "$(DEB_VERSION)"
+   test "`dpkg-query -f '$${Version}' -W libedje-bin | sed 
's/+b[0-9]*$$//'`" = "$(DEB_VERSION)"
+   test "`dpkg-query -f '$${Version}' -W libeet-bin | sed 
's/+b[0-9]*$$//'`" = "$(DEB_VERSION)"
+   test "`dpkg-query -f '$${Version}' -W libelementary-bin | sed 
's/+b[0-9]*$$//'`" = "$(DEB_VERSION)"
+   test "`dpkg-query -f '$${Version}' -W libeolian-bin | sed 
's/+b[0-9]*$$//'`" = "$(DEB_VERSION)"
 endif
 
$(CURDIR)/debian/validate_symvers.sh

Bug#969590: sqop: Cannot use certificates for signature verification?

[Daniel Kahn Gillmor]

Control: forwarded https://gitlab.com/sequoia-pgp/sequoia/-/issues/590

Hi Guillem--

On Sat 2020-09-05 17:20:26 +0200, Guillem Jover wrote:
> I was trying out sqop, to potentially add native support for it into
> dpkg-dev

This is great to hear!  I think that you were running into (at least)
three different things:

 - the upstream signing keys (OpenPGP certificates) shipped in libbsd
   0.10.0 appear to be expired

 - you're shipping two upstream signing keys there, but sqop verify is
   buggy when a stream has two certificates in it:

 https://gitlab.com/sequoia-pgp/sequoia/-/issues/590

 - you've included the two certificates as separate ASCII-armored blobs,
   rather than a single ASCII-armored keyring that contains two
   certificates.  We probably need to clarify whether "sop" can accept a
   CERTS stream shaped like that:

 https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/28

In the meantime, here's a patch to libbsd 0.10.0 that at least resolves
the out-of-date certificates and the single-keyring-blob issue.

--dkg

From 6bde48deb1d35cbb010b55e6fb8cb92037378b5b Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Fri, 16 Oct 2020 15:22:22 -0400
Subject: [PATCH] refresh keys for Guillem Jover

This should help with resolving #969590
---
 debian/upstream/signing-key.asc | 187 +++-
 1 file changed, 85 insertions(+), 102 deletions(-)

diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
index 2f18626..d7d6d85 100644
--- a/debian/upstream/signing-key.asc
+++ b/debian/upstream/signing-key.asc
@@ -1,5 +1,4 @@
 -BEGIN PGP PUBLIC KEY BLOCK-
-Version: GnuPG v1
 
 mQGiBDfw+1oRBADQWbb/dnJBnw6s/c9LSU5ORjiKrYMF/EhFQGgKgz90IOvdl4kk
 DlSaqFUruQo2IheUp6eN61JpH5ygCKoFZfH9l+BTG4L0yv276nXq+wY2iQlgBjwy
@@ -10,105 +9,89 @@ OYitNVhEL2Z3yi0JMrgzYPXGEukn/HhWKgiwX/sjrpY81ZihFp3kiZ1GSbRBcsEO
 ZVWyA/9DJc1VcOpsQMMXkvMnxj1YqtcJzlXDby44V4onuWsTNKsHGP0IFkL1LKlm
 7WAiKOqZ/zabtiWF3jjZOZt6wLdpvAsiixO6WWgGk2wobLeNKqLie5h16tNMens4
 LRDhEVRCupncftBHDOd+V2h10dsC96nLL89lST1NpUfnf9ShA7QjR3VpbGxlbSBK
-b3ZlciA8Z3VpbGxlbUBoYWRyb25zLm9yZz6IXAQTEQIAHAUCPh+9gQIbAwQLBwMC
-AxUCAwMWAgECHgECF4AACgkQuW9ciZ2SjJvhowCeNsfqtYXEZQKb0yG7HFb84lIk
-aL4AoLttFVmbTlY2GKspXAM6W4Fzb+YGiGQEExECACQCGwMCHgECF4ACGQEFAkoC
-LSEFCwkIBwMFFQoJCAsFFgIDAQAACgkQuW9ciZ2SjJsFbACfcIoqZgGLO/ZlX8O2
-LKMU2iZ2UlkAoMI/syljpxraeWH5to5XbMuVcWMHiF8EExECAB8CGwMECwcDAgMV
-AgMDFgIBAh4BAheABQJBAHlGAhkBAAoJELlvXImdkoybUH4AnRSa8eHRtmdfKmbm
-EBKcajGXjFeiAKCsR+rn4GCDo1Q+uBKSft5EfHWdaLQnR3VpbGxlbSBKb3ZlciA8
-Z3VpbGxlbS5qb3ZlckBtZW50YS5uZXQ+iEkEMBEIAAkFAlBRap0CHSAACgkQuW9c
-iZ2SjJt5YgCfVhqeBekwiY/vD2GejXaCeT0JTF4AnROHyYPP5Dqzw3+dx+f6kQff
-Rgb8iGIEExECABoFCwcKAwQDFQMCAxYCAQIXgAIZAQUCPAbwvAASB2VHUEcAAQEJ
-ELlvXImdkoybKFEAn3DgGW1hKTuD3o7gzTiiIGY2Bo/wAJ95EeXvOVPTFDazesNU
-rCIq2CaFcohmBBMRAgAeAheABQJKAi0pBQsJCAcDBRUKCQgLBRYCAwEAAh4BABIH
-ZUdQRwABAQkQuW9ciZ2SjJt4EQCdGQBpCgbIg+V+LNdps8TfgYfYhg8An0CgCUH8
-CtyLeG99sZOCkBJlnr/hiF8EExECABcFCwcKAwQDFQMCAxYCAQIXgAUCQQB5PAAS
-B2VHUEcAAQEJELlvXImdkoybxswAoL8pYhJI010VXUzsYWeS8ezYWcD3AJ9/szPM
-bQvJb/2RwKTzgYmQH1hbI7QpR3VpbGxlbSBKb3ZlciA8Z3VpbGxlbWpvdmVyQGFt
-YnR1LmJjbi5lcz6ISQQwEQgACQUCUlDecgIdIAAKCRC5b1yJnZKMmwpoAJ93SP16
-gbLZG98572ygKG98Q6YwpACcDm0h0X999XI48NgFA+o2KFx13C+IZgQTEQIAHgIX
-gAUCSgItKQULCQgHAwUVCgkICwUWAgMBAAIeAQASB2VHUEcAAQEJELlvXImdkoyb
-4BwAoNKPxf67yivAMhLHIgDvIjR1uxUEAKCLgCz30A1+pRVXbO7RL0mxdkOvlIhX
-BBMRAgAXBQI8BvArBQsHCgMEAxUDAgMWAgECF4AACgkQuW9ciZ2SjJs83wCfUpRF
-hacPD51+ftZ45fkaS5t0xKMAoPt8+fomtgxPZw2tHtbpHJgfaJ+rtCtHdWlsbGVt
-IEpvdmVyIDxndWlsbGVtLmpvdmVyQGNhbXB1cy51YWIuZXM+iEkEMBEIAAkFAlJQ
-3pACHSAACgkQuW9ciZ2SjJts0gCfXdSHsStoZ4xP6GuVMnwwQqCZoEoAnRYNAgQa
-wUMDYnXB4o3pN4M0Ge8aiGYEExECAB4CF4AFAkoCLSkFCwkIBwMFFQoJCAsFFgID
-AQACHgEAEgdlR1BHAAEBCRC5b1yJnZKMm6lGAKCqjCRUI6G3KDQahmUhfFgXaIFr
-+ACg3yaE5/xBXq0vGo/Z/Pwpj8/71pqIVwQTEQIAFwUCPAbwbwULBwoDBAMVAwID
-FgIBAheAAAoJELlvXImdkoyb+rgAn3f3ojXxeXNHo2Df55H8iReHgtuGAKCnMO9b
-E5upP4xiLUdqwc7CShVQdbQrR3VpbGxlbSBKb3ZlciA8Z3VpbGxlbS5qb3ZlckBs
-ZXB0b24uaG4ub3JnPohfBBMRAgAXBQI8BvCaBQsHCgMEAxUDAgMWAgECF4AAEgkQ
-uW9ciZ2SjJsHZUdQRwABAYOrAKDH8m8CfFqjJENjmDqadQKkk5KDAgCg7EkvWOSt
-n6THjMX0OVFsL9iUZVeISQQwEQIACQUCQQGRfgIdIAAKCRC5b1yJnZKMm4R5AKDa
-O41ZaQmZVfxjEEpzzNZYZn72pQCfapLHJFPClhl0+i+Du2YgpGlGmBu0Lkd1aWxs
-ZW0gSm92ZXIgPGd1aWxsZW0uam92ZXJAc2lsaWNvbnRvd2VyLm5ldD6IXAQTEQIA
-HAUCPXdG1wIbAwQLBwMCAxUCAwMWAgECHgECF4AACgkQuW9ciZ2SjJuqIwCeKKhX
-PQYr9wHOO93mLUN1kOAGsVIAn3sRwB0IjY1Xom/cn/oxs8cIIQHAiEgEMBECAAkF
-AkEAeZMCHSAACgkQuW9ciZ2SjJuXlgCgoYXA7VcuBZOvdxWgoCzxaYWg7twAmM6I
-9puPp0Dt8JcbQb/vUYFlDUq0L0d1aWxsZW0gSm92ZXIgPGd1aWxsZW0uam92ZXJA
-c2lsaWNvbnRvd2VyLmluZm8+iFwEExECABwFAj13R5ACGwMECwcDAgMVAgMDFgIB
-Ah4BAheAAAoJELlvXImdkoybyd0AmwWXWQD7t7dydSEK50ssKrRYTI6oAJ9ISga0
-5Fvhpa+4cBcstdayi2eeYIhJBDARAgAJBQJBAHnWAh0gAAoJELlvXImdkoybNbkA
-njqUds0y0/pvxchTAt4GD/HL6EELAJ9yw5dz9KArvosuzmYfC0oZuDgNirQlR3Vp
-bGxlbSBKb3ZlciA8Z3VpbGxlbUBsZXB0b24uaG4ub3JnPohcBBMRAgAcBQI9gXRL
-AhsDBAsHAwIDFQIDAxYCAQIeAQIXgAAKCRC5b1yJnZKMmyZtAJ9Hg6g8PfvZLb/T

Bug#972174: s3fs segfault

[Noah Meyerhans]

On Fri, Oct 16, 2020 at 01:44:15PM +0200, Mattia Rizzolo wrote:
> > I'll work on testing a backport of the bullseye
> > version on buster to test this.
> 
> If you'd like, I can provide you with a .deb of the backport, for easier
> testing.

The backport was trivial to build, and I've been running it for >24
hours with no issues so far.  So things look promising for this being
fixed upstream by now.

> > Given the amount of code churn, I'm
> > skeptical that we'll be able to isolate an easily backportable fix, but
> > we'll see.
> 
> Indeed, and I'm not really _that_ interested in doing that work myself,
> so if you see that 1.87 doesn't segfaults at most I'd probably upload
> 1.87 to buster-backports rather than figuring out the proper fix for the
> "main" buster release.   Unless somebody can isolate the fix :)
> Probably going through the upstream git repository might help with that,
> fwiw.

It looks like there are enough enhancements (performance improvements,
new features, etc) in newer versions that a backport makes some sense.
AIUI, though I don't see where this is documented, a backports upload is
not intended to take the place of a proper stable update when it comes
to fixing bugs in stable versions.  However, I'm also not particularly
interested in investing a bunch of time to isolate and backport the
relevant upstream change.  Another option might be to try and convince
the stable release managers to allow a new upstream version.  Given the
risk of data loss presented by this bug, it might not be too difficult.

noah

Bug#969588: sqv: Cannot use ASCII armored key as keyring?

[Daniel Kahn Gillmor]

On Fri 2020-10-16 12:05:48 +0200, Justus Winter wrote:
> And in general, the expectation that you can join two files does not
> hold.  Concatenating two photos doesn't yield a slideshow, etc.  So my
> position on the matter is that concatenating two binary certificates
> yielding a keyring is a happy accident of an implementational detail,
> but shouldn't be relied upon, and certainly does not extend to other
> representations of certificates.

I understand your reasoning, but text files *do* concatenate to a longer
textfile, and textual-representations of a keyring are text files.

and, we have (i think) a pretty solid understanding of what a
concatenated ASCII-armored keyring would look like.  So i'm proposing
that sop (at least) should be able to handle concatenated ASCII-armored
certificates:

   https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/28

Please weigh in over there!

   --dkg


signature.asc
Description: PGP signature

Bug#972361: zlib-ng feature non-functional due to stripped-out sources

[Josh Triplett]

Package: librust-libz-sys+zlib-ng-dev
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

librust-libz-sys-dev strips out the zlib-ng sources, but
the librust-libz-sys+zlib-ng-dev package still exists. If you're going
to exclude the sources, please consider excluding the feature-package as
well.

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

Kernel: Linux 5.8.0-2-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librust-libz-sys+zlib-ng-dev depends on:
pn  librust-cmake-0.1+default-dev  
pn  librust-libc-0.2+default-dev   
pn  librust-libz-sys-dev   

librust-libz-sys+zlib-ng-dev recommends no packages.

librust-libz-sys+zlib-ng-dev suggests no packages.

Bug#768816: This bug is a Qt 4 bug

[Sylvestre Ledru]

Thanks

Have you been able to build it ?

I just try to do it for upload and I am getting:

autoheader: warning: missing template: WORDS_LITTLEENDIAN
autoreconf: /usr/bin/autoheader failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1

Disabling this leads to:

Running qmake: /usr/bin/qmake -recursive
Cannot find file: .
make[1]: *** [debian/rules:9 : override_dh_auto_configure] Erreur 2

Thanks again for the patch!

Sylvestre

Le 16/10/2020 à 20:50, Lisandro Damián Nicanor Pérez Meyer a écrit :

And Qt 4 is no longer available in testing/unstable. I don't know if
fwbuilder uses Qt 4 in unstable. I guess this can be closed.

Bug#972360: src:zeromq3: Wrong dependency on libpgm-5.2-0 for hppa and x32

[Vasyl Gello]

Package: src:zeromq3
Version: 4.3.3-2+b1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: jrt...@debian.org, mat...@debian.org

Dear colleagues,

building kodi on x32 breaks on the following unsatisfiable dependency:

libpgm-5.2-0 (>= 5.1.116~dfsg) [hppa, x32].

There is libpgm-5.3-0 already built for x32 but control file for zeromq3
still lists that old pinned version.

Regards, Vasyl

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

Kernel: Linux 4.15.0-121-generic (SMP w/6 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#972357: [INTL:sv] Swedish debconf template, fixing charset (no strings update)

[Felix Lechner]

Hi Laura,

On Fri, Oct 16, 2020 at 12:21 PM Laura Arjona Reina  wrote:
>
> the issue appears
> because the text is written as UTF-8, but the .po file declares another
> charset (ISO-8859-1).

Thank you for pointing this out! Is there an overview with all
languages provided by a particular package?

Kind regards
Felix Lechner

Bug#937184: Python 3 port of offlineimap underway

[Sudip Mukherjee]

On Thu, Sep 17, 2020 at 10:01:40PM +0200, Gaudenz Steinlin wrote:
> 
> There is now a Python 3 port of offlineimap underway:
> https://github.com/OfflineIMAP/offlineimap/issues/670
> 
> AFAICS it looks promising. Please wait with removing from unstable.

upstream is asking to treat offlineimap and offlineimap3 as separate
package. https://github.com/OfflineIMAP/offlineimap3/issues/10


--
Regards
Sudip

Bug#954681: [gnat-9] CONSTRAINT_ERROR : uintp.adb:1959 overflow check failed

[Torrance, Douglas]

On 9/27/20 7:46 AM, Nicolas Boulenguez wrote:
> Package: src:gcc-9
> Followup-For: Bug #954681
> Control: reassign -1 gnat-10
> Control: retitle -1 CONSTRAINT_ERROR : uintp.adb:2002 overflow check failed
> 
> Since version 10-20200410-1, the SOURCE_DATE_EPOCH patch should not
> trigger this bug anymore.  However, this bug is most probably not
> fixed, and a reproducer unrelated with GCC sources would really help
> the investigation.
> 
> If your message (#69) was based on a more recent version, please tell
> us. Else, please try again with a recent one (in experimental for
> example). Thanks in advance.

Thanks for the note!  I finally got around to trying another build of 
phcpack.  With the latest version of gnat-10 installed (10.2.0-15) in a 
sid schroot, I still get this bug, provided that the SOURCE_DATE_EPOCH 
environment variable is set.

To reproduce:

git clone https://github.com/janverschelde/PHCpack
cd PHCpack
make -C src/Objects SOURCE_DATE_EPOCH=0

The build eventually ends with:

 GNAT 10.2.0
 Copyright 1992-2020, Free Software Foundation, Inc.

 Compiling: /build/phcpack-2.4.80/src/Ada/Math_Lib/Vector
 /standard_integer64_vecvecs.ads
 Source file time stamp: 1970-01-01 00:00:00
 Compiled at: 2020-10-16 19:34:11
  10 lines: No errors
 gnatbind phctop use_c2phc pieri_solver

 raised CONSTRAINT_ERROR : uintp.adb:2002 overflow check failed
 make[1]: *** [makefile_unix:106: phc] Error 1
 make[1]: Leaving directory '/build/phcpack-2.4.80/src/Objects'
 make: *** [makefile:15: phc] Error 2
 make: Leaving directory '/build/phcpack-2.4.80/src/Objects'

If I build without setting SOURCE_DATE_EPOCH, then everything runs as 
expected.

Doug

Bug#963667: [Aptitude-devel] Bug#963667: aptitude: Aptitude segmentation fault

[Axel Beckert]

Control: tag -1 + confirmed
Control: retitle -1 aptitude: segmentation fault if a file under 
/etc/apt/preferences.d is not readable for the user running aptitude

Hi,

Bardot Jerome wrote:
>  As user i did :
>  aptitude search nouveau

This is not really much information and looking through the backtrace
is a bit like searching for a needle in the haystack.

Nevertheless, thanks to the hint by Gert, it helped to also pinpoint
the issue in your case (see below), so thanks for including it!

Gert Robben wrote:
> I have the same outcome, but I don't know if it's the same cause.
> Anyway, I found aptitude segfaults, when the active uid cannot read some
> file.

Thanks for that hint! That seems to be the cause of Jerome's segfault,
too, namely the file /etc/apt/preferences.d/99my-custom-repository:

stat("/etc/apt/preferences.d/99my-custom-repository", {st_mode=S_IFREG|0640, 
st_size=317, ...}) = 0
openat(AT_FDCWD, "/etc/apt/preferences.d/99my-custom-repository", 
O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES (Permission non accordée)

> $ su -c 'touch /etc/apt/preferences.d/test'
> $ aptitude search nouveau
> (works fine)
> $ su -c 'chmod -r /etc/apt/preferences.d/test'

I assume there is a "600" or "640" missing in that last line.

> Maybe you have the same problem?

It is.

> But I use stable, not testing.

Chances are high that this issue is in there for quite a while,
probably related to some API extensions of libapt* to expose better
error handling.

Anyway, I can now reproduce this here:

$ aptitude search nouveau
[1]16941 segmentation fault (core dumped)  aptitude search nouveau
$

apt itself seems to catch this case and throws a warning:

$ apt search nouveau
Sorting... Done
Full Text Search... Done
bumblebee/unstable,testing 3.2.1-26 amd64
  NVIDIA Optimus support for Linux

[…]

W: Unable to read /etc/apt/preferences.d/foobar - open (13: Permission denied)
$

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

Bug#972323: libllvm11 and libllvm11:i386 aren't coinstallable

[Brett Gilio]

Shmerl  writes:

> they have a version mismatch:
>
> libllvm11:amd64 - 1:11.0.0-2
> libllvm11:i386 - 1:11.0.0-2+b1
>
> That makes it impossible to install latest Mesa with both 64 and 32-bit.

Is it possible to just remove the binNMU? I'm not sure.

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Bug#972137: SSL certificate problem (Was: Bug#972137: r-bioc-tcgabiolinks: autopkgtest regression)

[Tiago Chedraoui Silva]

Hi Andreas,

The software access an external database to retrieve the genome
information. The database has experienced problems in the last days and it
has not been fixed yet.

I am trying to save the genome information inside the package so it does
not depends on the database anymore. I'll let you know when I fix it.

Best regards,
Tiago Chedraoui Silva


On Tue, Oct 13, 2020 at 6:04 AM Andreas Tille  wrote:

> Control: tags -1 upstream
> Control: tags -1 help
> Control: forwarded -1 Antonio Colaprico , Tiago
> Chedraoui Silva 
>
>
> Hi Antonio and Tiago,
>
> the Debian packaged version of TCGAbiolinks received a bug report about
> a failure in its test suite.  I have the impression that the SSL
> certificate of a site where data are downloaded from is not correct.
> Could you please verify the test suite and let me know whether you
> might also get
>
>  ── 1. Error: Preparing HT_HG-U133A as SE works
> (@test-prepare-download.R#193)  ─
>
>  failed to get URL after 3 tries:
>
>
>error: SSL certificate problem: unable to get local issuer certificate
>
>
>
> Kind regards
>
>Andreas.
>
> On Tue, Oct 13, 2020 at 08:36:21AM +0200, Graham Inggs wrote:
> > Source: r-bioc-tcgabiolinks
> > Version: 2.16.4+dfsg-1
> > Severity: serious
> > Tags: sid bullseye
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: regression
> >
> > Hi Maintainer
> >
> > Since 2020-10-08, the autopkgtest of r-bioc-tcgabiolinks has been
> failing [1].
> >
> > I've copied what I hope is the relevant part of the log below.
> >
> > Does this autopkgtest download data?  If so, please add the
> > 'needs-internet' [2] restriction to debian/tests/control, or even skip
> > that particular test.
> >
> > Regards
> > Graham
> >
> >
> > [1] https://ci.debian.net/packages/r/r-bioc-tcgabiolinks/testing/amd64/
> > [2]
> https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
> >
> >
> > ── 1. Error: Preparing HT_HG-U133A as SE works
> (@test-prepare-download.R#193)  ─
> > failed to get URL after 3 tries:
> >   error: SSL certificate problem: unable to get local issuer certificate
> > Backtrace:
> >  1. TCGAbiolinks::GDCprepare(query, summarizedExperiment = TRUE)
> >  2. TCGAbiolinks:::readGeneExpressionQuantification(...)
> >  3. TCGAbiolinks:::makeSEfromGeneExpressionQuantification(...)
> >  4. TCGAbiolinks::get.GRCh.bioMart(genome)
> >
> > ___
> > R-pkg-team mailing list
> > r-pkg-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team
>
> --
> http://fam-tille.de
>

Bug#972358: ITP: python-django-postgres-extra -- Extended PostgreSQL for Django

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-postgres-extra
  Version : 2.0
  Upstream Author : Sector Labs 
* URL : https://github.com/SectorLabs/django-postgres-extra/
* License : Expat
  Programming Lang: Python
  Description : Extended PostgreSQL for Django

 This provides extended functionality for PostgreSQL databases to Django.
 Currently supported are:
  * Native upserts (single query, concurrency safe and bulk support)
  * Extended support for HStoreField (unique or null constraints, selecting
individual keys)
  * Extra signals for updates
  * MIN and MAX expressions for multiple value fields such as hstore and array
  * Custom indexes with conditions.

I intend to maintain this as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl+J83cRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrpSAgAmw1/z7k7ttxLryQwH52KlN5UeoLtEhHA
epudQZl7YEhT9pzr3gnxHGZusBSGIbpkO6+OjM7OZh980PVbPHszIK6LzlYKSFcF
/NmlKGdIsHU+sL3jEloE9WBYC1dGiem0jXc5FJGgGoBcXBvIGC2nieGifUntXldJ
kbzccpEJVPlIfEWXb4XZ/gP8spx0jNS8cBshSzmysCf7U9i1qSNYC5iMx61lpbnO
RKaJmsKhnbogV1g7cntsBtojJxQebx4h/SFiU+3vz+rm+myCqoXvftdmVjE28iEQ
/MCzu0gRs/zUMRftNPY8lV0YzRicFtVrmT/T7ZRmDKclq6OBzNyQ4A==
=lgD+
-END PGP SIGNATURE-

Bug#972164: MR for this bug

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 + patch

Hi! I've opened a MR to fix this bug in
https://salsa.debian.org/debian-gps-team/pkg-gpsbabel/-/merge_requests/1

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#964791: [Pkg-opencl-devel] Bug#964791: libclc-amdgcn: OpenCL fails to start

[Diederik de Haas]

Does this error still occur?

It seems to me the same problem as in https://bugs.debian.org/cgi-bin/
bugreport.cgi?bug=964973 and that has been fixed for me.
With me, 'clinfo' didn't work before, but it does now.

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

Bug#971415: transition: ocaml

[Brett Gilio]

Sebastian Ramacher  writes:

> autopkgtest for cudf/0.9-1: amd64: Pass, arm64: Pass, armhf: Regression ♻ 
> (reference ♻), i386: Pass
> autopkgtest for dose3/5.0.1-15: amd64: Pass, arm64: Pass, armhf: Test in 
> progress, i386: Pass
> autopkgtest for mcl/1:14-137+ds-9: amd64: Pass, arm64: Pass, armhf: 
> Regression ♻ (reference ♻), i386: Pass
> autopkgtest for morbig/0.10.4-4: amd64: Pass, arm64: Pass, armhf: Regression 
> ♻ (reference ♻), i386: Not a regression
> autopkgtest for morsmall/0.3.0-3: amd64: Pass, arm64: Pass, armhf: Regression 
> ♻ (reference ♻), i386: Pass
> autopkgtest for ocaml-visitors/20200210-2: armhf: Regression ♻ (reference ♻)
> autopkgtest for ppx-deriving-yojson/3.5.3-1: amd64: Pass, arm64: Pass, armhf: 
> Regression ♻ (reference ♻), i386: Pass
> autopkgtest for sks/1.1.6+git20200620.9e9d504-1: amd64: Pass, arm64: Pass, 
> armhf: Regression ♻ (reference ♻), i386: Pass
> autopkgtest for why3/1.3.3-1: amd64: Pass, arm64: Pass, armhf: Test in 
> progress, i386: Pass
>

Hi, new OCaml team member. Are these regressions introduced on the
4.11.x switch? Thanks!

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Bug#972357: [INTL:sv] Swedish debconf template, fixing charset (no strings update)

[Laura Arjona Reina]

Package: mdadm
Version: 4.1-6
Severity: wishlist
Tags: l10n patch
X-Debbugs-CC: debian-l10n-swed...@lists.debian.org

Hi, at the website team we're receiving tidy validation errors in this page:

https://www.debian.org/international/l10n/po-debconf/sv.en.html
(and translations)

It seems it's due to a bad encoding of the last translator name in mdadm
package:

mdadm   80% (8t;0f;2u)  sv.po   Martin Ã…gren

I've had a look at the corresponding file and I think the issue appears
because the text is written as UTF-8, but the .po file declares another
charset (ISO-8859-1).

(If I open the .po file with a "normal" editor it's shown correctly, but
if opened with POEdit it shows many character issues).

I'm attaching a new sv.po files where I change the line declaring the
charset of the file, to be UTF-8. With this change, the strings are
correctly shown in POEdit and I guess the Debian website will be happy, too.

CC'ing the debian-l10n-swedish mailing list for the case anybody is
working on updating the translation, so they take this issue into account.

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
# translation of mdadm_2.6.7-3_sv.po to Swedish
# Translators, if you are not familiar with the PO format, gettext
# documentation is worth reading, especially sections dedicated to
# this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
# Some information specific to po-debconf are available at
# /usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
# Developers do not need to manually edit POT or PO files.
#
# Martin Ågren , 2008.
msgid ""
msgstr ""
"Project-Id-Version: mdadm_2.6.7-3_sv\n"
"Report-Msgid-Bugs-To: md...@packages.debian.org\n"
"POT-Creation-Date: 2019-02-09 08:48+0100\n"
"PO-Revision-Date: 2008-07-23 18:34+0200\n"
"Last-Translator: Martin Ågren \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../mdadm.templates:2001
msgid "Should mdadm run monthly redundancy checks of the MD arrays?"
msgstr "Ska mdadm köra månatliga redundanskontroller av MD-kedjorna?"

#. Type: boolean
#. Description
#: ../mdadm.templates:2001
msgid ""
"If the kernel supports it (versions greater than 2.6.14), mdadm can "
"periodically check the redundancy of MD arrays (RAIDs). This may be a "
"resource-intensive process, depending on the local setup, but it could help "
"prevent rare cases of data loss. Note that this is a read-only check unless "
"errors are found; if errors are found, mdadm will try to correct them, which "
"may result in write access to the media."
msgstr ""
"Om din kärna har stöd för det (versioner senare än 2.6.14), kan mdadm "
"periodvis kontrollera redundansen för dina MD-kedjor (RAID). Det här kan "
"vara en resurskrävande process, beroende på din konfiguration, men den kan "
"hjälpa till att förhindra ovanliga fall av dataförluster. Observera att det "
"är en skrivskyddad kontroll såvida inte fel påträffas; om fel hittas kommer "
"mdadm försöka att rätta till dem, vilket kan leda till skrivåtkomst till "
"mediet."

#. Type: boolean
#. Description
#: ../mdadm.templates:2001
msgid ""
"The default, if turned on, is to check on the first Sunday of every month at "
"01:06."
msgstr ""
"Standardvärdet, om påslagen, är att kontrollera på den första söndagen i "
"varje månad klockan 01.06."

#. Type: boolean
#. Description
#: ../mdadm.templates:3001
msgid "Should mdadm check once a day for degraded arrays?"
msgstr ""

#. Type: boolean
#. Description
#: ../mdadm.templates:3001
msgid ""
"mdadm can check once a day for degraded arrays and missing spares to ensure "
"that such events don't go unnoticed."
msgstr ""

#. Type: boolean
#. Description
#: ../mdadm.templates:4001
msgid "Do you want to start the MD monitoring daemon?"
msgstr "Vill du starta MD-övervakningsdemonen?"

#. Type: boolean
#. Description
#: ../mdadm.templates:4001
msgid ""
"The MD (RAID) monitor daemon sends email notifications in response to "
"important MD events (such as a disk failure)."
msgstr ""
"MD-övervakningsdemonen (RAID) skickar e-postnotifieringar för viktiga MD-"
"händelser (såsom ett diskfel)."

#. Type: boolean
#. Description
#: ../mdadm.templates:4001
msgid "Enabling this option is recommended."
msgstr "Att aktivera denna funktion rekommenderas."

#. Type: string
#. Description
#: ../mdadm.templates:5001
msgid "Recipient for email notifications:"
msgstr "Mottagare av e-postnotifieringar:"

#. Type: string
#. Description
#: ../mdadm.templates:5001
msgid ""
"Please enter the email address of the user who should get the email "
"notifications for important MD events."
msgstr ""
"Ange e-postadressen till den användare som ska ta emot e-postnotifieringar "
"för dessa viktiga MD-händelser."

#~ msgid "MD arrays 

Bug#972163: MR for fixing this bug

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 + patch

Merge request available in
https://salsa.debian.org/debian/fwbuilder/-/merge_requests/1

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#768816: This bug is a Qt 4 bug

[Lisandro Damián Nicanor Pérez Meyer]

And Qt 4 is no longer available in testing/unstable. I don't know if
fwbuilder uses Qt 4 in unstable. I guess this can be closed.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#972228: CVE-2020-13991

[Philippe Coval]

‌Hi,

I've updated to current upstream snapshot that fixes the issue,
please upload:

 https://mentors.debian.net/package/iotjs/; 
target="https://mentors.debian.net/package/iotjs/;>https://mentors.debian.net/package/iotjs/

The respective dsc file can be found at:

 https://mentors.debian.net/debian/pool/main/i/iotjs/iotjs_1.0+715-1.dsc; 
target="https://mentors.debian.net/debian/pool/main/i/iotjs/iotjs_1.0+715-1.dsc;>https://mentors.debian.net/debian/pool/main/i/iotjs/iotjs_1.0+715-1.dsc


--
https://purl.org/rzr/;>https://purl.org/rzr/





De : "Moritz 
Muehlenhoff"
A : "Debian Bug Tracking System"
Envoyé: mercredi 14 Octobre 2020 23:01
Objet : Bug#972228: CVE-2020-13991

Package: iotjs
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13991 is for
JerryScript, which iotjs appears to included.

Cheers,
Moritz

Bug#972162: MR for 972162

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 + patch

Hi! I have just created a MR with the fix for this bug in
https://salsa.debian.org/science-team/enki-aseba/-/merge_requests/1

Thanks, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#971944: espeak 1.48.04+dfsg-7+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971944 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: espeak
Version: 1.48.04+dfsg-7+deb10u1

Explanation: fix using espeak with mbrola-fr4 when mbrola-fr1 is not installed

Bug#971398: Update to new version (0.11.X)

[Louis-Philippe Véronneau]

On Thu, 1 Oct 2020 02:21:34 -0400
=?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?=  wrote:
> Work towards this can be found in the "debian/waiting_on_NEW" branch on
> Salsa [1].
> 
> I still have some work to do (re-enable the testsuite+autopkgtests,
> install the logo, etc.) but hopefully that shouldn't be too hard.
> 
> [1]:
> https://salsa.debian.org/python-team/packages/sublime-music/-/tree/debian/waiting_on_NEW

FWIW, I'm happy with the current state of sublime-music in the
debian/waiting_on_NEW branch and will upload when blocking packages have
passed NEW.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#938322: Python 2 support for Bullseye

[Dmitry Shachnev]

Hi Moritz!

On Fri, Oct 16, 2020 at 08:04:56PM +0200, Moritz Mühlenhoff wrote:
> There will be few core packages build-depending on Python 2 (for tests
> or building) which won't be ready for Python 3 for Bullseye (Chromium,
> qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very
> small set of support packages like setuptools/jinja) to build and
> run their tests.

Small correction: s/qtwebkit/qtwebengine/.

QtWebEngine bundles Chromium whose upstream is actively working on
Python 3 port [1]. Most probably it won't be ready in time for Bullseye,
but for Bookworm it should be ready (or rather, Qt WebEngine 6 will
use Python 3, and we will remove Qt WebEngine 5).

There are also patches from the FreeBSD maintainer [2], but they are huge
(2200 lines in total) and the author reports that they cause some JS errors,
so I would better not apply them and wait for an official port.

Qt WebEngine in Debian is not supported from security point of view anyway,
so I think it should be fine to let it use Python 2 in Bullseye.

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=1112471
[2]: https://mail.kde.org/pipermail/distributions/2020-September/000860.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#972356: src:haskell-hoogle: fails to migrate to testing for too long: armhf autopkgtest regression

[Paul Gevers]

Source: haskell-hoogle
Version: 5.0.17.15+dfsg1-2
Severity: serious
Control: close -1 5.0.18+dfsg1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 971832
Control: affects -1 src:ghc src:haskell-byte-order src:haskell-resolv

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:haskell-hoogle in its current version in unstable has been trying to
migrate for 55 days [2]. But worse, it blocks several packages from
migrating to testing, blocking the ghc transition. Hence, I am filing
this bug.

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

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

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

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

Paul

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



signature.asc
Description: OpenPGP digital signature

Bug#972355: qtav: FTBFS with Qt 5.15: error: field 'clip_path' has incomplete type 'QPainterPath'

[Dmitry Shachnev]

Source: qtav
Version: 1.13.0+ds-2
Severity: important
Tags: ftbfs
User: debian-qt-...@lists.debian.org
Usertags: qt5.15
Control: block 972278 by -1

Dear Maintainer,

qtav fails to build with Qt 5.15, currently available in experimental:

  In file included from filter/X11FilterContext.cpp:22:
  ./QtAV/FilterContext.h:75:18: error: field 'clip_path' has incomplete type 
'QPainterPath'
 75 | QPainterPath clip_path;
|  ^

The full build log is attached.

--
Dmitry Shachnev
I: pbuilder: network access will be disabled during build
I: Current time: Fri Oct 16 21:08:59 MSK 2020
I: pbuilder-time-stamp: 1602871739
I: Building the build Environment
I: extracting base tarball [/home/dmitry/pbuilder/experimental-base.tgz]
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [qtav_1.13.0+ds-2.dsc]
I: copying [./qtav_1.13.0+ds.orig.tar.xz]
I: copying [./qtav_1.13.0+ds-2.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.EWvCpGdP/trustedkeys.kbx': 
General error
gpgv: Signature made Fri Oct 16 18:07:13 2020 UTC
gpgv:using RSA key E7AF3C82A7B83D2BAC51970B6646265B586B83CB
gpgv:issuer "mity...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./qtav_1.13.0+ds-2.dsc
dpkg-source: info: extracting qtav in qtav-1.13.0+ds
dpkg-source: info: unpacking qtav_1.13.0+ds.orig.tar.xz
dpkg-source: info: unpacking qtav_1.13.0+ds-2.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Create-install-files-with-soversion.patch
dpkg-source: info: applying 0002-QMLPlayer-should-be-QApplication.patch
dpkg-source: info: applying 
0003-Rename-the-qtav_dev-and-qtav_dev_links-target-as-lib.patch
dpkg-source: info: applying 
0004-Rename-qtav-private-dev.install-libqtav-private-dev..patch
dpkg-source: info: applying 
0005-Disable-warnings-with-Wno-expansion-to-defined-Wno-u.patch
dpkg-source: info: applying 0006-Load-the-libva-libraries-with-SONAME-2.patch
dpkg-source: info: applying 0007-Add-include-for-Qt-5.14.patch
I: using fakeroot in build.
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 11~), qt5-qmake, libqt5opengl5-dev, libqt5svg5-dev, 
qtdeclarative5-dev (>= 5.15), libqt5x11extras5-dev, libass-dev, libavutil-dev, 
libavresample-dev, libavcodec-dev, libavformat-dev, libavdevice-dev, 
libavfilter-dev, libswscale-dev, libopenal-dev, libpulse-dev, libxv-dev, 
libva-dev, libegl1-mesa-dev, libuchardet-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 15467 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper (>= 11~); however:
  Package debhelper is not installed.
 pbuilder-satisfydepends-dummy depends on qt5-qmake; however:
  Package qt5-qmake is not installed.
 pbuilder-satisfydepends-dummy depends on libqt5opengl5-dev; however:
  Package libqt5opengl5-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqt5svg5-dev; however:
  Package libqt5svg5-dev is not installed.
 pbuilder-satisfydepends-dummy depends on qtdeclarative5-dev (>= 5.15); however:
  Package qtdeclarative5-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqt5x11extras5-dev; however:
  Package libqt5x11extras5-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libass-dev; however:
  Package libass-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libavutil-dev; however:
  Package libavutil-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libavresample-dev; however:
  Package libavresample-dev is not installed.
 pbuilder-satisfydepends-dummy depends 

Bug#972354: deepin-screenshot: FTBFS with Qt 5.15: error: aggregate ‘QPainterPath rectPath ’ has incomplete type and cannot be defined

[Diederik de Haas]

On Fri, 16 Oct 2020 20:49:38 +0300 Dmitry Shachnev  wrote:
> Source: deepin-screenshot

Upstream's repo (https://github.com/linuxdeepin/deepin-screenshot) has been 
archived/deprecated with the message "migrated into deepin-screen-recorder 
after v20"

That repo has a PR which fixes the issue:
https://github.com/linuxdeepin/deepin-screen-recorder/pull/45

But since it's technically another repo, I'll not mark it as 'forwarded'.

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

Bug#972223: [Pkg-samba-maint] Bug#972223: Acknowledgement (samba: NT4-style domain member doesn't work without winbind, but even with it, doesn't work)

[Andrew Bartlett]

On Thu, 2020-10-15 at 15:37 +0200, Josip Rodin wrote:
> On Thu, Oct 15, 2020 at 10:06:12AM +0200, Josip Rodin wrote:
> > Further down the line, I also enabled more debugging, and observed
> > messages like these:
> > 
> > [2020/10/15 08:00:57.669098,  3, pid=29639, effective(0, 0),
> > real(0, 0)] ../libcli/security/dom_sid.c:210(dom_sid_parse_endp)
> >   string_to_sid: SID root is not in a valid format
> > 
> > [2020/10/15 08:00:57.669313,  3, pid=29639, effective(0, 0),
> > real(0, 0)] ../libcli/security/dom_sid.c:210(dom_sid_parse_endp)
> >   string_to_sid: SID @users is not in a valid format
> > 
> > I guess I'm gonna have to UTSL to figure that one out
> 
> Err, I must be missing something, but I've been trying to add a few
> changes
> to libcli/security/dom_sid.c in the unpacked source, and then build
> and
> install that, and restart all daemons, but nothing changes in the
> logs.
> 
> How do I debug this?

I wouldn't automatically assume this is catastrophic, it could just as
easily be code that wants to parse something as a SID if it is a SID
(avoiding a remote name lookup for a SID).

Andrew Bartlett

-- 
Andrew Bartlett   https://samba.org/~abartlet/
Authentication Developer, Samba Team  https://samba.org
Samba Developer, Catalyst IT  
https://catalyst.net.nz/services/samba

Bug#972354: deepin-screenshot: FTBFS with Qt 5.15: error: aggregate ‘QPainterPath rectPath’ has incomplete type and cannot be defined

[Dmitry Shachnev]

Source: deepin-screenshot
Version: 5.0.0-1
Severity: important
Tags: ftbfs
User: debian-qt-...@lists.debian.org
Usertags: qt5.15
Control: block 972278 by -1

Dear Maintainer,

deepin-screenshot fails to build with Qt 5.15, currently available in
experimental.

After building a fixed version of dtkwidget (see #972155), I get this error:

  /<>/src/widgets/shapeswidget.cpp: In member function ‘void 
ShapesWidget::paintRect(QPainter&, FourPoints, int, 
ShapesWidget::ShapeBlurStatus, bool, bool)’:
  /<>/src/widgets/shapeswidget.cpp:1262:18: error: aggregate 
‘QPainterPath rectPath’ has incomplete type and cannot be defined
   1262 | QPainterPath rectPath;
|  ^~~~
  /<>/src/widgets/shapeswidget.cpp: In member function ‘void 
ShapesWidget::paintEllipse(QPainter&, FourPoints, int, 
ShapesWidget::ShapeBlurStatus, bool, bool)’:
  /<>/src/widgets/shapeswidget.cpp:1300:18: error: aggregate 
‘QPainterPath ellipsePath’ has incomplete type and cannot be defined
   1300 | QPainterPath ellipsePath;
|  ^~~
  /<>/src/widgets/shapeswidget.cpp: In member function ‘void 
ShapesWidget::paintArrow(QPainter&, QList, int, bool)’:
  /<>/src/widgets/shapeswidget.cpp:1328:26: error: aggregate 
‘QPainterPath path’ has incomplete type and cannot be defined
   1328 | QPainterPath path;
|  ^~~~
  /<>/src/widgets/shapeswidget.cpp: In member function ‘void 
ShapesWidget::paintLine(QPainter&, QList)’:
  /<>/src/widgets/shapeswidget.cpp:1346:18: error: aggregate 
‘QPainterPath linePaths’ has incomplete type and cannot be defined
   1346 | QPainterPath linePaths;
|  ^

Adding #include  should fix it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#876626: Xastir loose TCP/IP data afer 12 hours of use

[Benoit Panizzon]

Package: xastir
Followup-For: Bug #876626

Dear Maintainer,

I probably stumbled over the same issue, but this happens much quicker here.
After maybe 30minutes. No new stations are received.

I first made sure it's not an IPv6 issue by connecting to a specific IPv4 
address from the euro.aprs2.net list, but the issue still happens.

I watched with tpcdump -X port 14580 to see the ASCII output of the 
conversation and found that the APRS-IS server was
still sending data and that was normaly acked, so the TCP connection was fully 
functional.
xastir als show the connection as 'up' but it looks like it is not able to 
parse the input anymore, nor to send it's own packets.

73
Benoit / HB9EUE

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

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

Versions of packages xastir depends on:
ii  debconf [debconf-2.0]1.5.74
ii  libax25  0.0.12-rc5+git20190411+b17ff36-3
ii  libc62.31-3
ii  libcurl3-gnutls  7.72.0-1
ii  libdb5.3 5.3.28+dfsg1-0.6
ii  libgeotiff5  1.6.0-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.35+hg16344-1
ii  libpcre3 2:8.39-13
ii  libshp2  1.5.0-2
ii  libtiff5 4.1.0+git191117-2
ii  libx11-6 2:1.6.12-1
ii  libxm4   2.3.8-3
ii  libxt6   1:1.2.0-1
ii  xastir-data  2.1.6-2

Versions of packages xastir recommends:
ii  festival  1:2.5.0-4

Versions of packages xastir suggests:
pn  direwolf | soundmodem  

-- debconf information:
* xastir/install-setuid: true

Bug#972280: Libreoffice: when adwaita-dark controls used, buttons are not visible anymore

[Rene Engelhard]

forwarded 972280
https://bugs.documentfoundation.org/show_bug.cgi?id=126933


tag 972280 + upstream

thanks


Hi,

On 15.10.20 20:48, Pavlos Ponos wrote:
> Package: libreoffice
> Version: 1:7.0.2-2
> Severity: important

Oh my.

My humble opinion but this only happens when

a) using something not default

b) using buttons for something which should be done by styles..

and one can live with this and this not "important". But anyways, won't
argue.

> When using adwaita-dark controls, buttons for text formatting are not visible 
> anymore. When switching back to debian's default, everyt

.. hing works?

> Please consider adjusting buttons when black themes used, otherwise it's 
> almost impossible to find the button you are looking for.
>
> Screenshot to follow.

This is upstreams job, and actually there is
https://bugs.documentfoundation.org/show_bug.cgi?id=126933
 ... Follow
any status there.

Regards,


Rene

Bug#971944: buster-pu: package espeak/1.48.04+dfsg-7+deb10u1

[Cyril Brulebois]

Samuel Thibault  (2020-10-16):
> Ah, I didn't think about it because these files are not actually
> shipped in the udeb :)
> 
> $ ar p espeak-data-udeb_1.48.04+dfsg-7_amd64.udeb data.tar.xz | tar tJ | grep 
> mb
> $ ar p espeak-data-udeb_1.48.04+dfsg-7+deb10u1_amd64.udeb data.tar.xz | tar 
> tJ | grep mb
> $ 

No objections, thanks.


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


signature.asc
Description: PGP signature

Bug#971807: buster-pu: package webext-tbsync

[Adam D. Barratt]

On Wed, 2020-10-07 at 20:45 +0100, Adam D. Barratt wrote:
[snip discussion of metadata]
> The package might well have an RC bug. The release process does not.
> :-)

One other thing I just noticed - please don't close p-u bugs in your
changelog. The release.d.o bug gets closed once the package has been
added to stable in a point release, as that's the end of the process.

Regards,

Adam

Bug#972353: ITP: python-click-didyoumean -- enables git-like did-you-mean feature in click

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-click-didyoumean
  Version : 0.0.3
  Upstream Author : Timo Furrer 
* URL : https://github.com/click-contrib/click-didyoumean
* License : Expat
  Programming Lang: Python
  Description : enables git-like did-you-mean feature in click

 Click is a Python package for creating beautiful command line interfaces
 in a composable way with as little code as necessary.  It's the "Command
 Line Interface Creation Kit".  It's highly configurable but comes with
 sensible defaults out of the box.
 .
 It aims to make the process of writing command line tools quick and fun
 while also preventing any frustration caused by the inability to implement
 an intended CLI API.
 .
 This package add the feature to do git-like did-you-mean feature in click.

Note: This is a new dependency for Celery.

Bug#971954: libdatetime-timezone-perl 2.23-1+2020b flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971954 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libdatetime-timezone-perl
Version: 2.23-1+2020b

Explanation: update included data

Bug#972001: tzdata 2020b-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972001 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: tzdata
Version: 2020b-0+deb10u1

Explanation: new upstream release

Bug#971866: okular 17.12.2-2.2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971866 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: okular
Version: 17.12.2-2.2+deb10u1

Explanation: fix code execution via action link [CVE-2020-9359]

Bug#971915: transmission 2.94-2+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971915 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: transmission
Version: 2.94-2+deb10u2

Explanation: fix memory leak

Bug#971062: plinth 19.1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971062 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: plinth
Version: 19.1+deb10u1

Explanation: apache: Disable mod_status [CVE-2020-25073]

Bug#972310: puma 3.12.0-2+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972310 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: puma
Version: 3.12.0-2+deb10u2

Explanation: fix HTTP injection and HTTP smuggling issues [CVE-2020-5247 
CVE-2020-5249 CVE-2020-11076 CVE-2020-11077]

Bug#970518: edk2 0~20181115.85588389-3+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 970518 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: edk2
Version: 0~20181115.85588389-3+deb10u2

Explanation: fix integer overflow in DxeImageVerificationHandler 
[CVE-2019-14562]

Bug#971869: freecol 0.11.6+dfsg2-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971869 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: freecol
Version: 0.11.6+dfsg2-2+deb10u1

Explanation: fix XML External Entity vulnerability [CVE-2018-1000825]

Bug#972161: ruby2.5 2.5.5-3+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 972161 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: ruby2.5
Version: 2.5.5-3+deb10u3

Explanation: fix potential HTTP request smuggling vulnerability in WEBrick 
[CVE-2020-25613]

Bug#971277: dpdk 18.11.10-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 971277 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: dpdk
Version: 18.11.10-1~deb10u1

Explanation: new upstream stable release; fix remote code execution issue 
[CVE-2020-14374], TOCTOU issues [CVE-2020-14375], buffer overflow 
[CVE-2020-14376], buffer over read [CVE-2020-14377] and integer underflow 
[CVE-2020-14377]

Bug#970655: sleuthkit 4.6.5-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 970655 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: sleuthkit
Version: 4.6.5-1+deb10u1

Explanation: fix stack buffer overflow in yaffsfs_istat [CVE-2020-10232]

Bug#972352: ITP: python-click-repl -- REPL plugin for Click

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-click-repl
  Version : 0.1.6
  Upstream Author : Markus Unterwaditzer 
* URL : https://github.com/untitaker/click-repl
* License : Expat
  Programming Lang: Python
  Description : REPL plugin for Click

 Click is a Python package for creating beautiful command line interfaces
 in a composable way with as little code as necessary.  It's the "Command
 Line Interface Creation Kit".  It's highly configurable but comes with
 sensible defaults out of the box.
 .
 It aims to make the process of writing command line tools quick and fun
 while also preventing any frustration caused by the inability to implement
 an intended CLI API.
 .
 This package provides a REPL plugin for click.

Note: This is a new dependency for Celery.

Bug#970816: libimobiledevice 1.2.1~git20181030.92c5462-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 970816 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libimobiledevice
Version: 1.2.1~git20181030.92c5462-2+deb10u1

Explanation: add partial support for iOS 14

Bug#972346: sagemath-common: Sagemath does not work with Cantor, sage-env binary is needed

[Jan Kriho]

Thank you for the detailed analysis.

On Fri, 16 Oct 2020 12:25:53 -0400 John Scott  wrote:
> On Friday, October 16, 2020 11:29:14 AM EDT Jan Kriho wrote:
> > The launcher scripts is dependent on sage-env binary which sets env for
> > executing further commands
> Note that even if sage-env were to be available, I don't think Cantor would be
> able to find it. It appears to invoke `sage --root` to figure out where to 
> look,
> but the output is empty.

I see, so the sage-env binary won't be called anyway.

> Cantor could be doing things in a more clean way regardless though. Instead of
> fiddling with $SAGE_ROOT in a shell script, it could use the one-liner
> sage --ipython3 -i --simple-prompt
>
> or use /usr/bin/sage --sh for the shebang in the script and call sage-ipython

This actually looks like a way better option. I have made a quick test
with it, and it looks like it works like it's supposed to. Should the
bug be reassigned to Cantor upstream?

Bug#971944: buster-pu: package espeak/1.48.04+dfsg-7+deb10u1

[Samuel Thibault]

Adam D. Barratt, le ven. 16 oct. 2020 17:44:29 +0100, a ecrit:
> On Sat, 2020-10-10 at 12:07 +0200, Samuel Thibault wrote:
> > Espeak cannot drive the mbrola-fr4 speech synthesis voice if the
> > mbrola-fr1 package is not installed. This is because some of the mb-
> > fr4 espeak rules refer to the fr1 voice while they should be
> > referring to the fr4 voice. This was fixed some time ago in the newer
> > espeak-ng package, but the fix was not backported yet to espeak.
> [...]
> > Yes, the remaining reference to fr1_phtrans is on purpose, it is part
> > of the confusion between mbrola-fr1 and mbrola-fr4: fr1_phtrans is
> > provided by espeak-data for both mbrola-fr1 and mbrola-fr4, it was
> > actually renamed to fr_phtrans in espeak-ng-data.
> 
> This looks fine to me, but will need a KiBi-ack as espeak produces a
> udeb.

Ah, I didn't think about it because these files are not actually shipped
in the udeb :)

$ ar p espeak-data-udeb_1.48.04+dfsg-7_amd64.udeb data.tar.xz | tar tJ | grep mb
$ ar p espeak-data-udeb_1.48.04+dfsg-7+deb10u1_amd64.udeb data.tar.xz | tar tJ 
| grep mb
$ 

Samuel

Bug#972351: buster-pu: package ros-ros-comm/1.14.3+ds1-5+deb10u1

[Jochen Sprickerhof]

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

[ Reason ]
CVE-2020-16124 was published with a number of integer overflow in the
XML RPC layer of ros-ros-comm.

[ Impact ]
The impact is rather low as the ROS middleware has no authentication nor
security features implemented and should only be used behind a firewall.
Still would be good to get it fixed in stable.

[ Tests ]
The patch adds a unit test and I ran manual tests using the relay
command from the topic-tools package.

[ Risks ]
I see the code as rather trivial, and the risk as low.

[ 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 ]
The patch adds size checks and unit tests.

[ Other info ]
I left the patches as they where merged upstream but can squash them if
that would be easier for you.
diff --git a/debian/changelog b/debian/changelog
index 2f80bb1..420c997 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ros-ros-comm (1.14.3+ds1-5+deb10u2) buster; urgency=high
+
+  * Add https://github.com/ros/ros_comm/pull/2065 (Fix CVE-2020-16124)
+
+ -- Jochen Sprickerhof   Fri, 16 Oct 2020 17:48:57 +0200
+
 ros-ros-comm (1.14.3+ds1-5+deb10u1) stable; urgency=high
 
   * Add https://github.com/ros/ros_comm/pull/1771 (Fix CVE-2019-13566, 
CVE-2019-13465)
diff --git a/debian/patches/0007-Build-Python-3-version-of-roslz4.patch 
b/debian/patches/0007-Build-Python-3-version-of-roslz4.patch
index 9487775..ab177c6 100644
--- a/debian/patches/0007-Build-Python-3-version-of-roslz4.patch
+++ b/debian/patches/0007-Build-Python-3-version-of-roslz4.patch
@@ -6,6 +6,8 @@ Subject: Build Python 3 version of roslz4
  CMakeLists.txt | 9 +
  1 file changed, 9 insertions(+)
 
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 169420f..eb45865 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
 @@ -20,3 +20,12 @@ add_subdirectory(tools/rosout)
diff --git 
a/debian/patches/0010-Trap-for-overly-large-input-to-XmlRPCPP-which-could-.patch
 
b/debian/patches/0010-Trap-for-overly-large-input-to-XmlRPCPP-which-could-.patch
new file mode 100644
index 000..e26a0d1
--- /dev/null
+++ 
b/debian/patches/0010-Trap-for-overly-large-input-to-XmlRPCPP-which-could-.patch
@@ -0,0 +1,351 @@
+From: Sid Faber 
+Date: Tue, 15 Sep 2020 19:48:40 +
+Subject: Trap for overly large input to XmlRPCPP which could cause problems
+ with int <-> size_t conversions.
+
+ - In XmlRpcClient, XmlRpcServerConnection and XmlRpcSocket, recognize when 
incoming or outgoing data is too large, generate an error and discard the data 
when practical.
+ - Use the safe strtol() rather than atoi() to decode an incoming 
content-length header, and generate an error if the length is invalid or too 
large.
+ - In XmlRpcUtil, prevent attempts to parse overly large XML input.
+ - Add tests where they can reasonably be inserted into existing test routines.
+
+Although this fix could be cleaner the update is written to make the update 
ABI compatible.
+
+This fix addresses CVE-2020-16124 / Integer overflow in ros_comm.
+
+Signed-off-by: Sid Faber 
+---
+ utilities/xmlrpcpp/src/XmlRpcClient.cpp   | 25 +++--
+ utilities/xmlrpcpp/src/XmlRpcServerConnection.cpp | 28 --
+ utilities/xmlrpcpp/src/XmlRpcSocket.cpp   | 13 +
+ utilities/xmlrpcpp/src/XmlRpcUtil.cpp |  5 ++
+ utilities/xmlrpcpp/test/TestValues.cpp| 27 +-
+ utilities/xmlrpcpp/test/test_client.cpp   | 65 +++
+ 6 files changed, 153 insertions(+), 10 deletions(-)
+
+diff --git a/utilities/xmlrpcpp/src/XmlRpcClient.cpp 
b/utilities/xmlrpcpp/src/XmlRpcClient.cpp
+index 2d42bb8..d53214e 100644
+--- a/utilities/xmlrpcpp/src/XmlRpcClient.cpp
 b/utilities/xmlrpcpp/src/XmlRpcClient.cpp
+@@ -312,6 +312,13 @@ XmlRpcClient::generateRequest(const char* methodName, 
XmlRpcValue const& params)
+   header.length(), body.length());
+ 
+   _request = header + body;
++  // Limit the size of the request to avoid integer overruns
++  if (_request.length() > size_t(__INT_MAX__)) {
++XmlRpcUtil::error("XmlRpcClient::generateRequest: request length (%u) 
exceeds maximum allowed size (%u).",
++  _request.length(), __INT_MAX__);
++_request.clear();
++return false;
++  }
+   return true;
+ }
+ 
+@@ -431,13 +438,16 @@ XmlRpcClient::readHeader()
+ return false;   // We could try to figure it out by parsing as we read, 
but for now...
+   }
+ 
+-  _contentLength = atoi(lp);
+-  if (_contentLength <= 0) {
+-XmlRpcUtil::error("Error in XmlRpcClient::readHeader: Invalid 
Content-length specified (%d).", _contentLength);
++  // avoid overly large or improperly formatted content-length
++  long int clength = 0;
++  clength = strtol(lp, nullptr, 10);
++  if ((clength <= 0) || 

Bug#971944: buster-pu: package espeak/1.48.04+dfsg-7+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Sat, 2020-10-10 at 12:07 +0200, Samuel Thibault wrote:
> Espeak cannot drive the mbrola-fr4 speech synthesis voice if the
> mbrola-fr1 package is not installed. This is because some of the mb-
> fr4 espeak rules refer to the fr1 voice while they should be
> referring to the fr4 voice. This was fixed some time ago in the newer
> espeak-ng package, but the fix was not backported yet to espeak.
[...]
> Yes, the remaining reference to fr1_phtrans is on purpose, it is part
> of the confusion between mbrola-fr1 and mbrola-fr4: fr1_phtrans is
> provided by espeak-data for both mbrola-fr1 and mbrola-fr4, it was
> actually renamed to fr_phtrans in espeak-ng-data.

This looks fine to me, but will need a KiBi-ack as espeak produces a
udeb.

Regards,

Adam

Bug#972092: gnocchi-common: Creation of default gnocchi.conf should set resource_id

[Russell Coker]

On Friday, 16 October 2020 1:39:04 AM AEDT Thomas Goirand wrote:
> Though I do understand your point of view, if you don't know anything
> about OpenStack, Ceph, Zookeeper, etc. Truth is, Gnocchi should be
> working better if setup with at least keystone for auth (though Keystone
> is probably the most easy component of OpenStack to setup).

I filed some bug reports with issues that I think would make Gnocchi much 
easier for beginners to get started.

> > Attempts to use it in other ways fail
> 
> I don't agree. You just happened to fail using it, but that doesn't mean
> it can't be used.

One thing is that I didn't find one of the systemd service files because it 
was in a different package to the daemon.  I think that they should be in the 
same package if it's strongly recommended that the daemon in question only be 
started by systemd.  It's only if running the daemon without systemd (as I 
tried to do and as is recommended by upstream documentation) that it makes 
sense to have them in separate packages.

> > the upstream documentation is no good,
> > and there isn't Debian specific documentation for it.
> 
> Though there's puppet-module-gnocchi that you could use, and which I
> package in Debian, if you're a puppet person. This definitively helps.
> At least by just reading what it does.

I'm not a puppet person.  There are several systems doing similar things 
(puppet and ansible are the ones that seem most common).  So if I use one then 
I'll end up missing out on the benefits (such as the example files you refer 
to) for the other ones.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#972346: sagemath-common: Sagemath does not work with Cantor, sage-env binary is needed

[John Scott]

Control: affects -1 cantor-backend-sage
Control: summary -1 SAGE_ROOT unset + sage-env removal inhibits Cantor backend

On Friday, October 16, 2020 11:29:14 AM EDT Jan Kriho wrote:
> The launcher scripts is dependent on sage-env binary which sets env for
> executing further commands
Note that even if sage-env were to be available, I don't think Cantor would be 
able to find it. It appears to invoke `sage --root` to figure out where to 
look, 
but the output is empty. Also with sage --sh:
> sage --sh
> 
> Starting subshell with Sage environment variables set.  Don't forget to exit 
> when you are done.  Beware:
>  * Do not do anything with other copies of Sage on your system.
>  * Do not use this for installing Sage packages using "sage -i" or for
>  running "make" at Sage's root directory.  These should be done
>  outside the Sage shell.
> 
> Bypassing shell configuration files...
> 
> Note: SAGE_ROOT=

Cantor could be doing things in a more clean way regardless though. Instead of 
fiddling with $SAGE_ROOT in a shell script, it could use the one-liner
sage --ipython3 -i --simple-prompt

or use  /usr/bin/sage --sh for the shebang in the script and call sage-ipython

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

Bug#972350: mariadb-10.5: FTBFS on powerpc: test main.flush_block_commit_notembedded failed

[Otto Kekäläinen]

Source: mariadb-10.5
Version: 1:10.5.6-1
Forwarded: https://jira.mariadb.org/browse/MDEV-23974
Tags: upstream, confirmed, help, ftbfs
Severity: normal
Justification: source does build, and tests pass when this test is skipped
User: debian-powe...@lists.debian.org
Usertags: powerpc

The test main.flush_block_commit_notembedded failed when I uploaded
10.5.6. The previous 10.5.5 build did not fail on this.

This bug is filed mainly to keep track of this exception in Debian builds.

If there are any powerpc experts in Debian who could look into this,
and report their findings directly upstream at jira.mariadb.org so
that an improved test (or underlying code fix) can be produced, it
would be appreciated.

If you have a patch:
- Universal fixes are welcome directly upstream at
https://github.com/mariadb/server
- Debian-only fixes are welcome as Merge Requests at
https://salsa.debian.org/mariadb-team/mariadb-10.5

Bug#972215: [Pkg-xmpp-devel] Bug#972215: gajim: Cannot connect to host with untrusted certificate

[Martin]

On 2020-10-15 23:42, Colomban Wendling wrote:
> Anyway, the cert has now been updated to present the proper CN for the
> domains I use, so I can connect again to my accounts with Gajim (after
> validating the self-signed cert twice for some reason).

Good! More or less...

> But I hardly
> think a missing CN/SAN is a good reason to prevent any encrypted
> communication.  Any encryption is better than none in all cases -- even
> if encrypting for a MiM.  I'm saddened by this whole misconception that
> encryption and signatures are the same thing and that the former is
> useless without the latter.

I agree. That's a general trend, which I gave up to fight.

> And in any case, regardless of the above, the UI should be fixed not to
> lead to a infinite loop of dialogs, and to properly reflect what the
> actual problem is.

True. Maybe there should be a separate bug report?

Bug#966707: debhelper: dh not keeping command log results in package rebuild

[Alex]

Hi,

Samuel is not alone in this issue. As I frequently rebuild packages with
small changes, I fully recognise the reported problem occurring since
compat 10. I would very welcome a solution to get the behaviour of
compat<10 back as waiting half an hour per build, just to find an error
in some final step is not fun...

On Sat, 12 Sep 2020 18:09:57 +0200 Samuel Thibault
 wrote:
> DH_REBUILD=dh_auto_build dpkg-buildpackage -B -nc
> or
> DH_REBUILD=dh_auto_configure dpkg-buildpackage -B -nc

Or using a command-line parameter to specify the step at which dh should
restart:

dpkg-buildpackage -B --no-pre-clean=dh_auto_build

Or if reusing --no-pre-clean is a no-go:

dpkg-buildpackage -B --continue=dh_auto_build

--
mvg,

Alex Hermann

Bug#896458: RFH: SWI-Prolog in Debian

[Lev Lamberov]

Hi Brett,

> Hello all. If there is still interest in needing co-maintenance on this
> package, I would be willing to help.

yes, there is still an interest in help with swi-prolog in Debian.

What do you plan to do? If you're not quite sure for now, you can start
by triaging bugs reported to Debian BTS. But honestly, there are not so
much of them.

Cheers!
Lev

Bug#972349: b-d's on python3-all-dev, but only builds for the default python3

[Matthias Klose]

Package: src:getfem++
Version: 5.3+dfsg1-3

getfem++ b-d's on python3-all-dev, but only builds for the default python3
version.

Either b-d on python3-dev, or build for all supported python3 versions.

Bug#972348: procps: [sysctl] /etc/sysctl.d should supersede /lib and /usr/lib

[Matthew Gabeler-Lee]

Package: procps
Version: 2:3.3.16-5
Severity: normal

My normal expectation with most things unix/linux is that
administrator-controlled files in /etc supersede package-shipped files in
/lib and /usr/lib.

However, the documented (and AFAICT actual) order of loading sysctl .conf
files is:

/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf

This makes it super annoying/frustrating to ensure proper configuration as
the settings in the files in /etc/sysctl.d/ can be overridden by almost
everything else.

It seems from the documentation that the intent is to allow the
/etc/sysctl.d/ _files_ to override files of the same name in later
directories, but this is rather confusing and frustrating. If I want to
ensure some limit-style setting is raised to a high enough level, I have to
make sure I know every package-provided file that might adjust that setting,
and manually maintain a copy of every other setting that package provides,
except the limit I want to raise.

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.58
ii  libc62.31-3
ii  libncurses6  6.2+20200918-1
ii  libncursesw6 6.2+20200918-1
ii  libprocps8   2:3.3.16-5
ii  libtinfo66.2+20200918-1
ii  lsb-base 11.1.0

Versions of packages procps recommends:
ii  psmisc  23.3-1

procps suggests no packages.

-- no debconf information

Bug#623336: rdiff-backup: --max-file-size breaks --exclude instructions

[Pablo Mestre]

Hi,

Thanks for take time to check and test the issue.

I will proced to close the bug them.

Pablo

El 10/16/20 a las 12:12 PM, Celejar escribió:
> On Wed, 14 Oct 2020 15:24:52 -0300
> Pablo Mestre  wrote:
>
>> Hi
>>
>> Thank you very much for reporting this error.
>>
>> I would like to ask you if this error is still present in the most
>> recent versions of rdiff-backup. Currently after a series of
>> improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]
>>
>> It would be very helpful if you checked again if this bug is still present. 
>> Otherwise we can agree to close the bug,
>>
>> [1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5
> Hi,
>
> I haven't used rdiff-backup in years, but I just did a quick check using
> Zachary's test example, and the behavior now seems to be correct: with
> or without --max-file-size, only the 'a' directory is created.
>
> Celejar

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#623336: (no subject)

[Pablo Mestre]

Version: 2.0.5

Bug#972347: pyferret ftbfs with python3.9 as supported python3 version

[Matthias Klose]

Package: src:pyferret
Version: 5.3+dfsg1-3
Severity: serious
Tags: sid bullseye ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.9

pyferret ftbfs with python3.9 as supported python3 version, packaging issue:

[...]
   dh_python3 -a
D: dh_python3 dh_python3:161: version: 4.20200925
D: dh_python3 dh_python3:162: argv: ['/usr/bin/dh_python3', '-a']
D: dh_python3 dh_python3:163: options: {'guess_deps': True, 'skip_private':
False, 'verbose': False, 'arch': True, 'package': None, 'no_package': None,
'compile_all': False, 'vrange': None, 'regexpr': None,
'accept_upstream_versions': False, 'depends': None, 'depends_section': None,
'recommends': None, 'recommends_section': None, 'suggests': None,
'suggests_section': None, 'requires': None, 'shebang': None, 'ignore_shebangs':
False, 'clean_dbg_pkg': True, 'no_ext_rename': False, 'no_shebang_rewrite':
False, 'O': None}
D: dh_python3 dh_python3:164: args: []
D: dh_python3 dh_python3:165: supported Python versions: 3.8,3.9 (default=3.8)
D: dh_python3 debhelper:152: source=pyferret, binary packages=['python3-ferret']
D: dh_python3 dh_python3:183: processing package python3-ferret...
D: dh_python3 tools:102: fix_shebang (debian/python3-ferret/usr/bin/pyferret3):
doesn't look like a shebang: #! /bin/sh
I: dh_python3 fs:420: renaming gcircle-7.63-py3.8.egg-info to 
gcircle-7.63.egg-info
I: dh_python3 fs:416: removing gcircle-7.63-py3.9.egg-info
(gcircle-7.63.egg-info is already available)
I: dh_python3 fs:420: renaming pipedviewer-7.63-py3.8.egg-info to
pipedviewer-7.63.egg-info
I: dh_python3 fs:416: removing pipedviewer-7.63-py3.9.egg-info
(pipedviewer-7.63.egg-info is already available)
I: dh_python3 fs:420: renaming pyferret-7.63-py3.8.egg-info to
pyferret-7.63.egg-info
I: dh_python3 fs:416: removing pyferret-7.63-py3.9.egg-info
(pyferret-7.63.egg-info is already available)
D: dh_python3 fs:260: package python3-ferret details = {'requires.txt': set(),
'egg-info':
{'debian/python3-ferret/usr/lib/python3/dist-packages/pipedviewer-7.63.egg-info',
'debian/python3-ferret/usr/lib/python3/dist-packages/gcircle-7.63.egg-info',
'debian/python3-ferret/usr/lib/python3/dist-packages/pyferret-7.63.egg-info'},
'nsp.txt': set(), 'shebangs': set(), 'public_vers': {Version('3')},
'private_dirs': {}, 'compile': True, 'ext_vers': {Version('3.8'),
Version('3.9')}, 'ext_no_version': set()}
D: dh_python3 depends:117: generating dependencies for package python3-ferret
D: dh_python3 pydist:142: trying to find dependency for multiprocessing
(python=None)
D: dh_python3 pydist:210: invoking dpkg -S
*python3/*/[Mm][Uu][Ll][Tt][Ii][Pp][Rr][Oo][Cc][Ee][Ss][Ss][Ii][Nn][Gg]-?*\.egg-info
D: dh_python3 pydist:226: dpkg -S did not find package for multiprocessing:
b'dpkg-query: no path found matching pattern
*python3/*/[Mm][Uu][Ll][Tt][Ii][Pp][Rr][Oo][Cc][Ee][Ss][Ss][Ii][Nn][Gg]-?*.egg-info\n'
I: dh_python3 pydist:229: Cannot find package that provides multiprocessing.
Please add package that provides it to Build-Depends or add "multiprocessing
python3-multiprocessing" line to debian/py3dist-overrides or add proper
dependency to Depends by hand and ignore this info.
D: dh_python3 pydist:142: trying to find dependency for numpy (python=None)
D: dh_python3 pydist:142: trying to find dependency for numpy (python=None)
D: dh_python3 depends:275: D={'python3 (<< 3.10)', 'python3 (>= 3.8~)',
'python3:any', 'python3:any (>= 3.6~)', 'python3-numpy'}; R=[]; S=[]; E=[],
B=[]; RT=[]
   dh_lintian -a
install -d debian/python3-ferret/usr/share/lintian/overrides
install -p -m0644 debian/python3-ferret.lintian-overrides
debian/python3-ferret/usr/share/lintian/overrides/python3-ferret
   dh_perl -a
   dh_link -a
   dh_strip_nondeterminism -a
   dh_compress -a
cd debian/python3-ferret
chmod a-x usr/share/doc/python3-ferret/changelog.Debian
usr/share/doc/python3-ferret/changelog.Debian.amd64
gzip -9nf usr/share/doc/python3-ferret/changelog.Debian
usr/share/doc/python3-ferret/changelog.Debian.amd64
cd '/<>'
   dh_fixperms -a
find debian/python3-ferret -true -print0 2>/dev/null | xargs -0r chown
--no-dereference 0:0
find debian/python3-ferret ! -type l -a -true -a -true -print0 
2>/dev/null |
xargs -0r chmod go=rX,u+rw,a-s
find debian/python3-ferret/usr/share/doc -type f -a -true -a ! -regex
'debian/python3-ferret/usr/share/doc/[^/]*/examples/.*' -print0 2>/dev/null |
xargs -0r chmod 0644
find debian/python3-ferret/usr/share/doc -type d -a -true -a -true 
-print0
2>/dev/null | xargs -0r chmod 0755
find debian/python3-ferret/usr/share/lintian/overrides -type f -a -true 
-a
-true -print0 2>/dev/null | xargs -0r chmod 0644
find debian/python3-ferret -type f \( -name '*.so.*' -o -name '*.so' -o 
-name
'*.la' -o -name '*.a' -o -name '*.js' -o -name '*.css' -o -name '*.scss' -o
-name '*.sass' -o -name '*.jpeg' -o -name '*.jpg' -o -name '*.png' -o -name
'*.gif' -o -name '*.cmxs' -o -name '*.node' \) -a -true -a -true 

Bug#968536: Transfer cherrytree from DPT to Debian group

[Andrius Merkys]

Hello,

Recently cherrytree [1] has been rewritten from Python to C++, thus it
no longer belongs in DPT. Could someone with adequate permissions
transfer it from DPT to generic Debian group on salsa.d.o?
Alternatively, one could grant me permission to manage cherrytree so as
I could transfer it myself.

[1] https://salsa.debian.org/python-team/packages/cherrytree

Thanks,
Andrius

Bug#972346: sagemath-common: Sagemath does not work with Cantor, sage-env binary is needed

[Jan Kriho]

Package: sagemath-common
Version: 9.2~beta12-1
Severity: normal
X-Debbugs-Cc: erbur...@gmail.com

Dear Maintainer,

Cantor is a front-end for several math SW. However recently it stopped working
for Sage with following error in the terminal:

out:  "/usr/share/cantor/sagebackend/cantor-execsage: line 13: exec: sage-
ipython: not found\r\n"

The launcher scripts is dependent on sage-env binary which sets env for
executing further commands:

```
#!/usr/bin/env bash

export SAGE_ROOT="$($1 --root)"

if [[ -f $SAGE_ROOT"/bin/sage-env" ]]; then
. "$SAGE_ROOT/bin/sage-env" >&2
elif [[ -f $SAGE_ROOT"/local/bin/sage-env" ]]; then
. "$SAGE_ROOT/local/bin/sage-env" >&2
elif [[ -f $SAGE_ROOT"/src/bin/sage-env" ]]; then
. "$SAGE_ROOT/src/bin/sage-env" >&2
fi

exec sage-ipython -i --simple-prompt
```

Please consider re-adding the binary back to the package.

Regards,

Jan Kriho



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (950, 'testing'), (900, 'unstable'), (850, 'experimental'), (800, 
'stable'), (775, 'oldstable'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 sagemath-common depends on:
ii  python3  3.8.2-3

sagemath-common recommends no packages.

sagemath-common suggests no packages.

-- no debconf information

Bug#623336: rdiff-backup: --max-file-size breaks --exclude instructions

[Celejar]

On Wed, 14 Oct 2020 15:24:52 -0300
Pablo Mestre  wrote:

> Hi
> 
> Thank you very much for reporting this error.
> 
> I would like to ask you if this error is still present in the most
> recent versions of rdiff-backup. Currently after a series of
> improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]
> 
> It would be very helpful if you checked again if this bug is still present. 
> Otherwise we can agree to close the bug,
> 
> [1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5

Hi,

I haven't used rdiff-backup in years, but I just did a quick check using
Zachary's test example, and the behavior now seems to be correct: with
or without --max-file-size, only the 'a' directory is created.

Celejar

Bug#972345: linux: Please enable CONFIG_RTC_DRV_PCF85063 on arm64

[Cyril Brulebois]

Source: linux
Version: 4.19.146-1
Severity: normal
Tags: patch

Hi,

While preparing a product based on a Raspberry Pi Compute Module 3+
embedded on a carrier board, I've stumbled upon an RTC module that's not
enabled in the current arm64 kernel on buster, that's required for the
PCF85063* family:
  https://www.nxp.com/search?keyword=PCF85063=0

I've tested two approaches:
 - Hackingly building it as a module (rebuilding only the drivers/rtc
   directory, shipping the resulting .ko and calling depmod myself);
 - and having it built-in instead, this time going for a full build of
   the linux source package, cross-building it for arm64 on amd64.

In both cases, some actions are required to activate the RTC:

modprobe i2c-dev
modprobe rtc-pcf85063
echo pcf85063 0x51 > /sys/class/i2c-adapter/i2c-1/new_device

This means that the kernel initialization happens too early for the
kernel itself reading the RTC time and using it to define system time:

[3.889684] hctosys: unable to open rtc device (rtc0)
[   10.577352] rtc-pcf85063 1-0051: rtc core: registered rtc-pcf85063 as 
rtc0

But after the write to “…/new_device”, one can set system time from the
RTC manually with:

hwclock -s # aka. --hctosys

I've also verified that systemd-timesyncd manages to update the RTC
upon successful NTP synchronization.


For now, I've only tested this with a buster userspace, on top of the
buster branch of linux.git; please let me know if you require applying
it on top of unstable and testing the resulting linux-image package
before considering applying this patch to buster (I would understand,
but I'd be rather happy to skip an extra build).

Because of the required I²C dance, I don't think it makes much of a
difference to enable it with =y or =m (I've learned about some
interesting facts in #855203); my most recent attempt was a full
(cross-)build with =y, hence the proposed patch.


Thanks for considering,
Cyril.
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
From b187f0b521c18f65e077c99dd464290b125b47e5 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Fri, 16 Oct 2020 13:22:39 +0200
Subject: [PATCH] Set CONFIG_RTC_DRV_PCF85063=y on arm64.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Tested successfully with PCF85063TP/PCF85063A on a carrier board with
Raspberry Pi Compute Module 3+, via I²C, on top of Linux 4.19.146, with
a buster userspace:

modprobe i2c-dev
modprobe rtc-pcf85063
echo pcf85063 0x51 > /sys/class/i2c-adapter/i2c-1/new_device

which results in:

[   10.577352] rtc-pcf85063 1-0051: rtc core: registered rtc-pcf85063 as 
rtc0

Tested-by: Cyril Brulebois 
Signed-off-by: Cyril Brulebois 
---
 debian/changelog   | 6 ++
 debian/config/arm64/config | 1 +
 2 files changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9de6cef68fb2..087e48b0843f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+linux (4.19.146-2) UNRELEASED; urgency=medium
+
+  * Set CONFIG_RTC_DRV_PCF85063=y on arm64.
+
+ -- Cyril Brulebois   Fri, 16 Oct 2020 12:42:59 +0200
+
 linux (4.19.146-1) buster; urgency=medium
 
   * New upstream stable update:
diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index b9d806a3cbbf..dd9002e40de7 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -994,6 +994,7 @@ CONFIG_RTC_DRV_DS1307=y
 CONFIG_RTC_DRV_MAX77686=y
 CONFIG_RTC_DRV_RK808=y
 CONFIG_RTC_DRV_PCF8563=y
+CONFIG_RTC_DRV_PCF85063=y
 CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_CROS_EC=m
 CONFIG_RTC_DRV_PL031=y
-- 
2.20.1

Bug#972344: bash automatically selects the copied text

[Antonio]

Package: bash
Version: 5.1~rc1-2
Severity: normal

Dear Maintainer,
after updating bash to version 5.1 ~ rc1-2 I noticed a new behavior: when
you paste a text it is automatically selected.
This however creates confusion as on plasma / konsole as the text is
confused with the cursor (block), placed at the end of the word.
How can I disable this new feature?
Thank you,
Antonio De Lorenzi