Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

2021-06-06 Thread Shengjing Zhu
On Sat, Jun 05, 2021 at 11:58:14PM +0200, Gunnar Hjalmarsson wrote:
> On 2021-06-05 22:51, Shengjing Zhu wrote:
> > Situation has changed since fcitx5 5.0.4, which includes a compatible
> > frontend for fcitx4 module.
> > https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63
> > 
> > The origin purpose is to support property software which only ships
> > with fctix4 modules, as well as snap, flatpak, etc, which can't use
> > the system library.
> 
> Ah, so that's why my trivial Chromium snap test worked with
> GTK_IM_MODULE=fcitx. :)
> 
> What's the conclusion then as regards this bug? Is it time to change to
> "fcitx" in im-config in unstable (and somehow also in bullseye) without
> worrying about users who have both fcitx 4 and fcitx 5 installed?
> 

We eventually need to align with upstream for the IM_MODULE env. But I'm not
sure what should be done before bullseye release.



Bug#893069: new upstream (4.2.4)

2021-06-06 Thread Daniel Baumann
retitle 893069 new upstream (4.4.3)
thanks

Hi Javier,

it has been now 5 years without any upload and the current upstream
release is 4.4.3 from last October.

Are you still interested, do you need help?

Regards,
Daniel



Bug#967972: cifs-utils: fails to mount filesystem when keyutils is not installed

2021-06-06 Thread Jonathon Reinhart
Some sources incorrectly indicate that keyutils is only needed with
DFS, but keyutils is also needed when using CIFS w/ Kerberos
authentication.

When trying to mount a CIFS share using kerberos (sec=krb5), the
kernel invokes /sbin/request-key to request a key from userspace. Then
cifs.upcall (from cifs-utils) is executed to handle the SPNEGO
authentication.

If keyutils is not installed, then /sbin/request-key is absent, and
the kernel is completely silent about this.

[  +0.497021] CIFS VFS: Send error in SessSetup = -2
[  +0.000992] CIFS VFS: cifs_mount failed w/return code = -2

Thus, I strongly agree with the proposal for cifs-utils to *Recommend*
keyutils, rather than merely *Suggesting* it.



Bug#989529: ITP: neochat -- Client for Matrix chat

2021-06-06 Thread Norbert Preining
Hi Andres,

thanks for your message!

> I'm happy to have the KDE team maintaining Neochat - in case it's helpful,
> here's the packaging for Spectral:

Thanks, I will look into it and see what might need updating on our
side. My current packaging is here:
https://salsa.debian.org/qt-kde-team/extras/neochat

I am planning to upload to NEW after a few more of us have made a check
of the current status. If you have any comments, please go ahead!

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



Bug#989529: ITP: neochat -- Client for Matrix chat

2021-06-06 Thread Andres Salomon

Hi,

Just FYI, I maintain Spectral in debian, which is what Neochat is forked 
from.


I'm happy to have the KDE team maintaining Neochat - in case it's 
helpful, here's the packaging for Spectral:


https://sources.debian.org/src/spectral/0.0%7Egit20210114.30028a2-2/debian/

Thanks,

Andres



Bug#987368: Installer fails at first menu "Choose language"

2021-06-06 Thread James Addison
Thanks Cyril, Frédéric - it feels like we're reaching a consensus that
udpkg may not be multi-process safe (although, strictly speaking, I
would say we haven't proven that yet).

The authors of multi-console support could be the best people to
recommend a path forward, as they may have close knowledge of the
level of testing and completion of the change.  I've attempted to add
them as subscribers to the bug although I expect that is opt-in and
I'm not sure whether I added them correctly.

Until any feedback from them, I'll mention a few possible routes that
had occurred to me:

- Backtracking: if we feel this is a problem that would likely affect
and/or annoy a significant number of users, we could disable
multi-console support for bullseye
- Known-issue: if we feel the issue is serious but rare, we could
indicate that it is a known problem (and perhaps prepare and document
workarounds)
- Scripting fix: we could perhaps adjust the installation scripts so
that d-i runs in a single-process condition until after udpkg has
completed, and only begin multiple debian-installer processes after
that
- Process-safety fix: in some sense an 'ideal' fix, we could add
multi-process safety to udpkg, either by using careful rewriting or
perhaps by using a lockfile or other safety mechanism(s)

Some related factors to consider:

- Do we advertise and support multi-process debian-installer support
in our documentation?
- Do we have availability of developer expertise for udpkg, including
review and QA time?
- Could/should the distance to a release date of Debian bullseye be a factor?

Cheers,
James

On Mon, 31 May 2021 at 10:31, Frédéric Bonnard  wrote:
>
> Hi Cyril/all,
> sorry that the process takes long, but that was the only way to
> reproduce that bug (which I think may not be specific to ppc64el)
> without having Power hardware (and a LPAR/HMC setup).
>
> > Looking at that log, one sees two PIDs for main-menu (272 and 278),
> > which could explain a very nice race condition: udpkg racing, one of
> > them making the status file disappear from under the feet of the other
> > one?
>
> My feeling is that this is exactly what's happening.
> I tried touching the missing file and the installer was happy because
> the called process (udpkg from what I remember) does not crash anymore
> (one can try udpkg without status file and it will crash).
>
> > See also two /sbin/debian-installer processes getting started beforehand
> > (one on /dev/hvc0, one on /dev/tty).
>
> Exactly.
>
> > It looks to me this is a clear problem on the debian-installer side (how
> > it deals with multiple consoles, similar to #940028 as you mentioned
> > initially), rather than some possible issues with emulation?
>
> To me, it's clearly not a qemu issue, since I have that issue on
> physical machines too. I just went the emulation way to enable people
> without hardware to reproduce the bug. It's more a race condition of
> running two debian-installers (not sure now who is remove the status
> file, probably udpkg ?).
>
> The point is that some work has already been done by several people on
> those multiple consoles setup according to the git commits , and I guess
> they will clearly get a grasp of what's going on.
>
>
> F.



Bug#989536: RFS: htmldoc/1.9.11-4 -- HTML processor that generates indexed HTML, PS, and PDF

2021-06-06 Thread Håvard Flaget Aasen
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: htmldoc
   Version : 1.9.11-4
   Upstream Author : Michael R Sweet 
 * URL : https://www.msweet.org/htmldoc/
 * License : IJG, zlib, MIT-CMU, BSD-2-Clause, Apache-2.0 with
(L)GPL-2 exception, GPL-2, PNG, GPL-2 with document exception,
bitstream, Apache-2.0
   Section : web

It builds those binary packages:

  htmldoc - HTML processor that generates indexed HTML, PS, and PDF
  htmldoc-common - Common arch-independent files for htmldoc

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/h/htmldoc/htmldoc_1.9.11-4.dsc

Changes since the last upload:

 htmldoc (1.9.11-4) unstable; urgency=medium
 .
   * Add patches to fix many CVE's. Closes: #989437
 Fix: CVE-2021-23158, CVE-2021-23165, CVE-2021-23180, CVE-2021-23191,
 CVE-2021-23206, CVE-2021-26252, CVE-2021-26259, CVE-2021-26948.
   * Switch to DEP-14 layout


Unblock request has been confirmed [0]

Regards,
Håvard

[0] https://bugs.debian.org/989448



Bug#988611: unblock: kodi/2:19.1+dfsg2-1

2021-06-06 Thread Vasyl Gello
Package: release.debian.org
Followup-For: Bug #988611
X-Debbugs-Cc: davebl...@kodi.tv, phunkyf...@kodi.tv

Hi Sebastian,

>Unfortunately your descriptions of the changes in kodi (and all the
>plugins) are very terse and only highlight changes that sound like they
>would fit the freeze policy. The other changes -- like the
>reimplementation of kodi's logging which is a few hundred lines if not
>more or newly added features -- are swept under the rug. We do not have
>the time to dig into upstream's decision to include those changes and the
>associated risks. If you as maintainer think that it's worth having
>these changes in bullseye, please help us reviewing the changes by
>explaining why the changes are needed and the potential regressions
>they could introduce.

Sorry for ponging this late! Let me answer the question as per bullseye FAQ 
([1]),
mentioned in the #debian-multimedia channel.

1. Is this a targeted bug fix release, and how does that show?

Yes, it is a bug fix release that addresses various bugs reported to Kodi
upstream and backported from current development branch (master) to stable
release (Matrix). As per Kodi's release policy, only changes tagged with
'Type: Backport' get merged into stable branches.

The 19.1 bugfix release features 89 commits and 80 PRs are closed in
'19.1-Matrix' milestone [2]:

$ git log --oneline --no-merges 19.0-Matrix..19.1-Matrix | wc -l
89

The total number of commits in the PRs counted by script below is 90:

# ===
#!/bin/sh
TOTAL_COUNT=0
while read _1
do
COMMIT_COUNT=$(gh api "repos/xbmc/xbmc/pulls/$_1/commits" | jq length)
TOTAL_COUNT=$(( TOTAL_COUNT + COMMIT_COUNT ))
#echo "$_1: $COMMIT_COUNT"
gh api "repos/xbmc/xbmc/pulls/$_1/commits" | jq ".[].commit.message" | 
sed 's/\\n.*"$/"/' | while read _2
do
echo "- $_2"
done
done <<.p
$(gh pr list \
--limit 100 \
--search 'milestone:"Matrix 19.1"' \
--state merged -R xbmc/xbmc \
--json number |
jq -r '.[].number')
.p

echo "---"
echo "Total commit count = $TOTAL_COUNT"
# ===

The missing commit is:

"[Subtitles][Plugins] Do not browse plugin directory when browsing for 
subtitles"

which has not been merged due to reasons unknown to me. This proves there are
only bug and code quality fixes in the point release.

2. What are the risks of the changes for the quality of the Debian release?

Given that every upstream change must pass the CI pipeline for every supported
architecture to be merged, and the changes were tested by bug reporters and
Kodi users on the forums, I see no significant risks for Debian release quality.

3. Is there a policy that describes what upstream considers acceptable for this
   upstream release?

Yes, see the Kodi official wiki page [3]. Also, there are unwritten rules that
are considered the rule of thumb in merging the fixes.

4. Does that policy align with our bug severity important or higher?

The perception of bugs cab be clearly mapped from Debian to Kodi and vice versa.

For example, the 18.9 point release (the last bugfix release of now old-stable
18.x "Leia" branch) was caused by Cloudflare's decision to break Kodi's SSL
over HTTP/2 implementation. Such a bug would get an RC status in Debian if 
reported.

5. Does upstream test thoroughly?

Yes. First of all, the fix must build at the committer's machine (see [3]). 
Then.
code owners and other members of Kodi team review the changes and make sure the
fix does not introduce new regressions. Then, the bug reporters download the
build artifacts produced by Jenkins and confirm the issue is resolved. Finally,
once the PR is approved, the final run of Jenkins builds ensures all 
architectures
pass the build smoothly and the change gets merged into master. Another build 
run
is done for stable backports.

6. Has this package seen new upstream version uploads to stable in the past to
   facilitate security support?

Yes, 17.5 fixed two CVEs and was uploaded into stretch, if my memory still 
serves
me.

7. Look at the diff. If it's long, you probably need a targeted fix.
8. Look at the diff. If there's a number of changes not relevant for Debian,
   you probably need a targeted fix.
9. Look at the diff. If there something in there that is difficult to explain,
   but not directly related to the (RC or important) bugs you are fixing,
   you probably need a targeted fix.

The most controversial change here is removal of 'CStaticLoggerBase' class.
The reasoning behind the change is explained at [4]:

"Yes please do, we will be working with log files from Matrix for some time
to come so may as well have any benifits." (c) Dave Blake. I am adding Dave
to the converation in case the question arises whether it is OK to discard
changes approved by upstream.

The rest of changes are targeted fixes that I already tested manually and
via Podman container with (sort of) autopkgtest. This work is done by me to
ensure release quality at Debian, 

Bug#989533: xsysinfo FTCBFS -- uses build compiler

2021-06-06 Thread Helmut Grohne
Control: tags -1 - patch

On Mon, Jun 07, 2021 at 12:36:10AM +0530, Nilesh Patra wrote:
> @@ -15,7 +16,7 @@ build-stamp: patch
>   dh_testdir
>  
>   xmkmf
> - $(MAKE) CDEBUGFLAGS="$(CDEBUGFLAGS)" xsysinfo
> + $(MAKE) CDEBUGFLAGS="$(CDEBUGFLAGS)" CC="$(CC)" xsysinfo
>  
>   touch build-stamp
>  

I'm sorry. This doesn't just work. xmkmf has architecture-behaviour.
Simply swapping out the compiler is not going to fix that. xutils-dev is
wrongly marked Multi-Arch: foreign at present. Our devised solution is
to remove xmkmf from the archive. The right solution here is to replace
the build system with something sane. See #873764 for details. It's not
as easy unfortunately.

Helmut



Bug#989538: unblock: ssl-cert/1.1.0+nmu1

2021-06-06 Thread Timo Röhling
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: roehl...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package ssl-cert

[ Reason ]
Fixes #988310

[ Impact ]
It is impossible to create certificates with make-ssl-cert in manual mode
without clobbering the OpenSSL template file.

[ Tests ]
I verified that the NMU'd version works as intended by manually creating a
local certicate.

[ Risks ]
The risk is very low as it is a one-line change in a code path that is
only exercised for the manual mode. The automated snakeoil certifcate
generation is unaffected.

[ Other info ]
I have attached the nmudiff from the original bugreport for convenience.


unblock ssl-cert/1.1.0+nmu1


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmC9RWAACgkQ+C8H+466
LVkvbAwA0AF/Z2bBU1rfdQS4E85kJ4gF292Z2VLtKI7GM+YFYEkRnPi3zO8fao2n
7+ly8iaHiiPABwidZtgUPglHwVsDWhVGurL7/m2wJzF6c0cLsq93HITCoUfw05EZ
xA1PducdJUb4Hr6VelBZ6YolTDwRUoZf51F5uORBLA+CP9MCAvZDAF8pr1U81sSo
obxvlcOLtS+Eraye6JsYqRNwKT8BdUm2V20sU6jIOdKfwNNAZwLHo0wRSISn+RWd
J27q9pPmkYZg4+Spqy/DKZHyiZUxVhHTOPKdIDRqaMzpvmrO/71vty/sUAfNEJeQ
CrBFgLgE7ileRx5gj0fj6FtZBugDY2509mRQROPmZcHDNLgx47/Myw74uUbWlrww
CP3hD0B+lSU7OO+/DsJKjQ0JtV8yu1g9NOips88szRBHnFKrn3QOLX3xFu+f+Thh
pY6xNrAc1K0a9W2yDoKe3NeoZSV/5U4+aCouMVLESPt0Ej5NreVKEbT2crPFwZKA
28ClgtsI
=qZ7f
-END PGP SIGNATURE-
diff -Nru ssl-cert-1.1.0/debian/changelog ssl-cert-1.1.0+nmu1/debian/changelog
--- ssl-cert-1.1.0/debian/changelog 2020-12-28 15:20:52.0 +0100
+++ ssl-cert-1.1.0+nmu1/debian/changelog2021-06-06 23:02:49.0 
+0200
@@ -1,3 +1,10 @@
+ssl-cert (1.1.0+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use correct argument for output file (Closes: #988310)
+
+ -- Timo Röhling   Sun, 06 Jun 2021 23:02:49 +0200
+
 ssl-cert (1.1.0) unstable; urgency=medium
 
   [ Stefan Fritsch ]
diff -Nru ssl-cert-1.1.0/make-ssl-cert ssl-cert-1.1.0+nmu1/make-ssl-cert
--- ssl-cert-1.1.0/make-ssl-cert2020-12-28 15:20:52.0 +0100
+++ ssl-cert-1.1.0+nmu1/make-ssl-cert   2021-06-06 23:02:49.0 +0200
@@ -173,7 +173,7 @@
 
 # Takes two arguments, the base layout and the output cert.
 if [ "${subcommand}" = "manual" ]; then
-output="${1}"
+output="${2}"
 [ -n "${template}" ] || usage 1
 [ -n "${output}" ]   || usage 1
 


Bug#967582: libgtkdatabox: depends on deprecated GTK 2

2021-06-06 Thread Felipe Castro
Hi, I'm the new upstream maintainer of GtkDatabox and we have released
version 1.0.0 this year, which depends now on GTK3, please update it on
Debian.
The packages which depend on it are klavaro, xoscope and brp-pacu.
>From those, the only upstream which still depends on old gtkdatabox is
brp-pacu, but there is a fork which has done the upgrade to use the new
GTK3 version at GitHub, see: https://github.com/matthew-dews/brp-pacu
The problem is that they have not released this new version yet, but I
could provide another fork and release, if that is the case.
Thanks,
Felipe Castro


Bug#988310: ssl-cert: diff for NMU version 1.1.0+nmu1

2021-06-06 Thread Timo Röhling

Control: tags 988310 + patch
Control: tags 988310 + pending

I've prepared an NMU for ssl-cert (versioned as 1.1.0+nmu1) and
uploaded it to NEW.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff -Nru ssl-cert-1.1.0/debian/changelog ssl-cert-1.1.0+nmu1/debian/changelog
--- ssl-cert-1.1.0/debian/changelog	2020-12-28 15:20:52.0 +0100
+++ ssl-cert-1.1.0+nmu1/debian/changelog	2021-06-06 23:02:49.0 +0200
@@ -1,3 +1,10 @@
+ssl-cert (1.1.0+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use correct argument for output file (Closes: #988310)
+
+ -- Timo Röhling   Sun, 06 Jun 2021 23:02:49 +0200
+
 ssl-cert (1.1.0) unstable; urgency=medium
 
   [ Stefan Fritsch ]
diff -Nru ssl-cert-1.1.0/make-ssl-cert ssl-cert-1.1.0+nmu1/make-ssl-cert
--- ssl-cert-1.1.0/make-ssl-cert	2020-12-28 15:20:52.0 +0100
+++ ssl-cert-1.1.0+nmu1/make-ssl-cert	2021-06-06 23:02:49.0 +0200
@@ -173,7 +173,7 @@
 
 # Takes two arguments, the base layout and the output cert.
 if [ "${subcommand}" = "manual" ]; then
-output="${1}"
+output="${2}"
 [ -n "${template}" ] || usage 1
 [ -n "${output}" ]   || usage 1
 


signature.asc
Description: PGP signature


Bug#988310: ssl-cert: make-ssl-cert uses same filename for template and output

2021-06-06 Thread Timo Röhling

On Sun, 6 Jun 2021 21:55:14 +0200 Stefan Fritsch  wrote:
I won't be able to deal with this for at least 1-2 weeks. It would be 
nice if someone could look at it and downgrade or NMU+unblock.

Consider it done :)


The suggested patch shifts the arguments, like it is done on other parts of the
script.

After looking at the script, I think it's better to replace the
output="${1}" with output="${2}" instead, because shift will have a
non-zero exit code and terminate the script (bash -e) without
notice. In particular, the user will not get the usage message which
tells him that he has to pass *two* arguments.

I'll prepare an NMU and upload it shortly.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature


Bug#989498: unblock: golang-1.15/1.15.9-5

2021-06-06 Thread Paul Gevers
Control: tags -1 - moreinfo
Control: tags -1 confirmed

Hi Shengjing,

On 06-06-2021 08:36, Shengjing Zhu wrote:
> On Sun, Jun 6, 2021 at 11:46 AM Paul Gevers  wrote:
>> On 05-06-2021 13:57, Shengjing Zhu wrote:
>>> Please unblock package golang-1.15

Unblocked.

>> You're well aware that golang builds statically so normally we're not
>> done with just accepting one package. Do we now need to also rebuild
>> everything that build depends on golang (I'd expect so)?
> 
> Yes. That's why the compiler is uploaded in unstable, as rebuilding in
> unstable is much easier before release. We didn't manage to rebuild
> any package in buster for the compiler security update after release.

So let's keep this bug open to keep track of this and only close it when
all rebuilds have migrated. Please know that I expect the golang team to
keep an eye on this too and warn us if anything is going wrong or takes
longer than expected. Please refrain from uploading any of the reverse
dependencies until their rebuild has migrated.

> + one package won't migrate, which is kubernetes, but the
> outdated-built-using rebuild script will not pick it up, as it doesn't
> have built-using field. (This doesn't mean it doesn't need to be
> rebuilt for the compiler security update, but no one cares about this
> package).

I know that last sentence to be untrue. Did you contact the maintainer
to inform him? I'm putting him in CC to make him aware of the CVE's.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#988310: ssl-cert: make-ssl-cert uses same filename for template and output

2021-06-06 Thread Stefan Fritsch
I won't be able to deal with this for at least 1-2 weeks. It would be 
nice if someone could look at it and downgrade or NMU+unblock.


Am 06.06.21 um 13:14 schrieb Stefan Bühler:

Hi,

On Mon, 10 May 2021 11:09:58 +0200 Parodper  wrote:

Package: ssl-cert
Version: 1.1.0
Severity: grave
Tags: patch
Justification: renders package unusable


Given ssl-cert is installed on many systems probably just for the
snakeoil self-signed certificate I think the severity isn't justified,
or at least the Justification is wrong.

"Only" creating other certificates seems to be impacted by this.  Is
there any data which packages are affected by this issue?


I don't know for sure, but I expect that this mode is only used 
manually, not by any postinst script.





The suggested patch shifts the arguments, like it is done on other parts of the
script.


The patch is not in "unified diff" format, which makes it hard to read /
apply in a safe way.

Apart from that it looks like a simple change though.

cheers,
Stefan





Bug#989533: xsysinfo FTCBFS -- uses build compiler

2021-06-06 Thread tony mancill
Hi Nilesh,

On Mon, Jun 07, 2021 at 12:36:10AM +0530, Nilesh Patra wrote:
> Package: xsysinfo
> Version: 1.7-9
> Severity: normal
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org
> 
> Dear Maintainer,
> 
> xsysinfo fails to cross build because it uses build compiler rather than
> the host compiler while cross building.
> Please consider applying the attached patch
> 
> Also, since this package has not been uploaded for ~10 years, which is a
> fairly long time, I'll nmu this package post bullseye release, if
> not uploaded on time.

Thank you for the patch.  Low-threshold NMUs are welcome, but I
appreciate the bug report and the patch.  I will apply and upload along
with the other changes that have accumulated in Salsa.

Cheers, and thanks!
tony

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


signature.asc
Description: PGP signature


Bug#989537: xmille FTCBFS -- uses build compiler

2021-06-06 Thread Nilesh Patra
Package: xmille
Version: 2.0-13
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

xmille fails to cross build because it uses build compiler rather than
the host compiler while cross building.
Please consider applying the attached patch

Also, since this package has not been uploaded for ~10 years, which is a
fairly long time, I'll nmu this package post bullseye release, if
not uploaded on time.

Nilesh

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,7 @@
 
 # Uncomment this to turn on verbose mode.
 export DH_VERBOSE=1
+-include /usr/share/dpkg/buildtools.mk
 
 build: build-stamp
 build-stamp:
@@ -11,7 +12,7 @@
 
xmkmf
$(MAKE) Makefiles
-   $(MAKE)
+   $(MAKE) CC="$(CC)"
 
touch build-stamp
 


Bug#989535: ITP: cmdock -- fit chemical compounds to proteins and nucleotides

2021-06-06 Thread Steffen Möller

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name    : cmdock
  Version : 0.1.3
  Upstream Author : RiboTargets (subsequently Vernalis (R) Ltd)
* URL : https://sidock.si
* License : LGPL-3.0+
  Programming Lang: C
  Description : fit chemical compounds to proteins and nucleotides
 This tool for molecular docking / in silico drug screening is a
 derivatrive of rDock and core to the SiDock@Home project to
 find inhibitors of the SARS-CoV-2 virus.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/cmdock



Bug#947473: ITP: golang-github-masterminds-goutils -- GoUtils is a Go implementation of some string manipulation libraries of Apache Commons.

2021-06-06 Thread louis
Yes, thank you, very much. I unfortunately gave up on learning the
Debian process

louis // systemli.org

Am 06.06.21 um 21:06 schrieb Peymaneh Nejad:
> Hi louis
> 
> Am 27.12.19 um 14:44 schrieb louis:
>> Package: wnpp
>> Severity: wishlist
>> Owner: louis 
>>
>> * Package name    : golang-github-masterminds-goutils
>>    Version : 1.1.0-1
>>    Upstream Author :
>> * URL : https://github.com/Masterminds/goutils
>> * License : Apache-2.0
>>    Programming Lang: Go
>>    Description : GoUtils is a Go implementation of some string
>> manipulation libraries of Apache Commons. This is an open source project
>> aimed at providing Go users with utility functions to manipulate strings
>> in various ways.
>>
>> This package is debianized as a dependency for the Caddy webserver.
> I'll be working on packaging the caddy webserver the next weeks and
> would like pick up this ITP if that's alright.
> 
> Kind regards,
> Peymaneh



OpenPGP_signature
Description: OpenPGP digital signature


Bug#989534: unblock: obs-studio/26.1.2+dfsg1-2

2021-06-06 Thread Sebastian Ramacher
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sramac...@debian.org

Please unblock and age package obs-studio. The version in unstable adds
a missing dependency on libsimde-dev.

[ Reason ]
The headers in libobs-dev include headers from libsimde-dev. Hence, a
dependency is required.

[ Impact ]
Users need to manually install libsimde-dev

[ Tests ]
Compiled a file with an #include  (the only
header that includes headers from libsimde-dev).

[ Risks ]
obs-studio is a leaf package.

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

[ Other info ]
Auto-removal is in 10 days, so please age the package accordingly.


unblock obs-studio/26.1.2+dfsg1-2


diff -Nru obs-studio-26.1.2+dfsg1/debian/changelog 
obs-studio-26.1.2+dfsg1/debian/changelog
--- obs-studio-26.1.2+dfsg1/debian/changelog2021-01-10 19:13:04.0 
+
+++ obs-studio-26.1.2+dfsg1/debian/changelog2021-06-01 20:05:24.0 
+
@@ -1,3 +1,9 @@
+obs-studio (26.1.2+dfsg1-2) unstable; urgency=medium
+
+  * debian/control: Make libobs-dev depend on libsimde-dev (Closes: #980171)
+
+ -- Sebastian Ramacher   Tue, 01 Jun 2021 22:05:24 +0200
+
 obs-studio (26.1.2+dfsg1-1) unstable; urgency=medium
 
   [ gregor herrmann ]
diff -Nru obs-studio-26.1.2+dfsg1/debian/control 
obs-studio-26.1.2+dfsg1/debian/control
--- obs-studio-26.1.2+dfsg1/debian/control  2021-01-10 18:32:08.0 
+
+++ obs-studio-26.1.2+dfsg1/debian/control  2021-01-15 16:31:27.0 
+
@@ -107,6 +107,7 @@
 Architecture: any
 Depends:
  libobs0 (= ${binary:Version}),
+ libsimde-dev,
  ${misc:Depends}
 Description: recorder and streamer for live video content (development files)
  OBS Studio is designed for efficiently recording and streaming live video


Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#989448: unblock: htmldoc/1.9.11-4

2021-06-06 Thread Sebastian Ramacher
Control: tags -1 confirmed moreinfo

On 2021-06-03 23:36:47 +0200, Håvard Flaget Aasen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: haavard_aa...@yahoo.no
> 
> Please unblock package htmldoc
> 
> This release adds patches to fix 8 CVE's and closes: #989437.
> 
> There are two things which is not needed in this release.
> Though the changes is not related to the code. I added the file
> 'debian/gbp.conf' since I changed the repository layout. I also fixed a
> minor error in the previous changelog entry, added a missing '#' in a
> 'close bug' statement.
> 
> [ Reason ]
> CVE-2021-23158, CVE-2021-23165, CVE-2021-23180, CVE-2021-23191,
> CVE-2021-23206, CVE-2021-26252, CVE-2021-26259 and CVE-2021-26948
> 
> [ Impact ]
> 
> [ Tests ]
> I have manually tested CVE-2021-23158, CVE-2021-23165, CVE-2021-23180,
> CVE-2021-23206 and CVE-2021-26252
> The issues in GitHub provided files that failed, before the fix was
> applied, and succeeded with this release.
> 
> [ Risks ]
> I consider this to be of minor risk. Code is coming from upstream, which
> also has released a new version with the changes.
> 
> [ 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 testing
> 
> [ Other info ]
> 
> unblock htmldoc/1.9.11-4

ACK, please remove moreinfo tag once the new version is available in
unstable.

Cheers

> 
> Regards,
> Håvard

> diff -Nru htmldoc-1.9.11/debian/changelog htmldoc-1.9.11/debian/changelog
> --- htmldoc-1.9.11/debian/changelog   2021-05-10 16:10:41.0 +0200
> +++ htmldoc-1.9.11/debian/changelog   2021-06-03 21:29:16.0 +0200
> @@ -1,7 +1,16 @@
> +htmldoc (1.9.11-4) unstable; urgency=medium
> +
> +  * Add patches to fix many CVE's. Closes: #989437
> +Fix: CVE-2021-23158, CVE-2021-23165, CVE-2021-23180, CVE-2021-23191,
> +CVE-2021-23206, CVE-2021-26252, CVE-2021-26259, CVE-2021-26948.
> +  * Switch to DEP-14 layout
> +
> + -- Håvard Flaget Aasen   Thu, 03 Jun 2021 21:29:16 
> +0200
> +
>  htmldoc (1.9.11-3) unstable; urgency=medium
>  
>* Add patch to mitigate buffer-overflow caused by integer-overflow in
> -image_load_gif() Closes: 984765 and fixes CVE-2021-20308
> +image_load_gif() Closes: #984765 and fixes CVE-2021-20308
>  
>   -- Håvard Flaget Aasen   Mon, 10 May 2021 16:10:41 
> +0200
>  
> diff -Nru htmldoc-1.9.11/debian/gbp.conf htmldoc-1.9.11/debian/gbp.conf
> --- htmldoc-1.9.11/debian/gbp.conf1970-01-01 01:00:00.0 +0100
> +++ htmldoc-1.9.11/debian/gbp.conf2021-05-23 08:32:55.0 +0200
> @@ -0,0 +1,3 @@
> +[DEFAULT]
> +debian-branch = debian/latest
> +upstream-branch = upstream/latest
> diff -Nru 
> htmldoc-1.9.11/debian/patches/CVE-2021-23158-CVE-2021-23191-CVE-2021-26252.patch
>  
> htmldoc-1.9.11/debian/patches/CVE-2021-23158-CVE-2021-23191-CVE-2021-26252.patch
> --- 
> htmldoc-1.9.11/debian/patches/CVE-2021-23158-CVE-2021-23191-CVE-2021-26252.patch
>   1970-01-01 01:00:00.0 +0100
> +++ 
> htmldoc-1.9.11/debian/patches/CVE-2021-23158-CVE-2021-23191-CVE-2021-26252.patch
>   2021-06-03 21:29:16.0 +0200
> @@ -0,0 +1,128 @@
> +From: Michael R Sweet 
> +Date: Thu, 1 Apr 2021 09:37:58 -0400
> +Subject: CVE-2021-23158, CVE-2021-23191, CVE-2021-26252
> +
> +Fix JPEG error handling (Issue #415)
> +
> +Origin: upstream, 
> https://github.com/michaelrsweet/htmldoc/commit/369b2ea1fd0d0537ba707f20a2f047b6afd2fbdc
> +Bug: https://github.com/michaelrsweet/htmldoc/issues/412
> +Bug: https://github.com/michaelrsweet/htmldoc/issues/414
> +Bug: https://github.com/michaelrsweet/htmldoc/issues/415
> +Bug-Debian: https://bugs.debian.org/989437
> +---
> + htmldoc/file.c |  9 -
> + htmldoc/image.cxx  | 38 +++---
> + htmldoc/ps-pdf.cxx |  5 +
> + 3 files changed, 44 insertions(+), 8 deletions(-)
> +
> +diff --git a/htmldoc/file.c b/htmldoc/file.c
> +index 20229c1..9f017de 100644
> +--- a/htmldoc/file.c
>  b/htmldoc/file.c
> +@@ -1000,8 +1000,15 @@ file_rlookup(const char *filename)/* I - Filename 
> */
> + 
> + 
> +   for (i = web_files, wc = web_cache; i > 0; i --, wc ++)
> ++  {
> + if (!strcmp(wc->name, filename))
> +-  return (wc->url);
> ++{
> ++  if (!strncmp(wc->url, "data:", 5))
> ++return ("data URL");
> ++  else
> ++return (wc->url);
> ++}
> ++  }
> + 
> +   return (filename);
> + }
> +diff --git a/htmldoc/image.cxx b/htmldoc/image.cxx
> +index 8f53050..74abfac 100644
> +--- a/htmldoc/image.cxx
>  b/htmldoc/image.cxx
> +@@ -1336,6 +1336,15 @@ image_load_gif(image_t *img,  /* I - Image pointer */
> + }
> + 
> + 
> ++typedef struct hd_jpeg_err_s// JPEG error manager extension
> ++{
> ++  struct jpeg_error_mgr jerr;   // JPEG error manager information
> ++  jmp_buf   retbuf; // setjmp() return buffer
> ++  char  

Bug#947473: ITP: golang-github-masterminds-goutils -- GoUtils is a Go implementation of some string manipulation libraries of Apache Commons.

2021-06-06 Thread Peymaneh Nejad

Hi louis

Am 27.12.19 um 14:44 schrieb louis:

Package: wnpp
Severity: wishlist
Owner: louis 

* Package name: golang-github-masterminds-goutils
   Version : 1.1.0-1
   Upstream Author :
* URL : https://github.com/Masterminds/goutils
* License : Apache-2.0
   Programming Lang: Go
   Description : GoUtils is a Go implementation of some string
manipulation libraries of Apache Commons. This is an open source project
aimed at providing Go users with utility functions to manipulate strings
in various ways.

This package is debianized as a dependency for the Caddy webserver.
I'll be working on packaging the caddy webserver the next weeks and would like 
pick up this ITP if that's alright.


Kind regards,
Peymaneh



Bug#989533: xsysinfo FTCBFS -- uses build compiler

2021-06-06 Thread Nilesh Patra
Package: xsysinfo
Version: 1.7-9
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

xsysinfo fails to cross build because it uses build compiler rather than
the host compiler while cross building.
Please consider applying the attached patch

Also, since this package has not been uploaded for ~10 years, which is a
fairly long time, I'll nmu this package post bullseye release, if
not uploaded on time.

Nilesh

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

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

Versions of packages xsysinfo depends on:
ii  libc6 2.31-3
ii  libice6   2:1.0.9-2
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.7.0-2
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxmu6   2:1.1.2-2+b3
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1+b3

xsysinfo recommends no packages.

xsysinfo suggests no packages.
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,7 @@
 # debian/rules for xsysinfo
 
 include /usr/share/dpatch/dpatch.make
+-include /usr/share/dpkg/buildtools.mk
 
 CDEBUGFLAGS = -Wall -g
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -15,7 +16,7 @@ build-stamp: patch
dh_testdir
 
xmkmf
-   $(MAKE) CDEBUGFLAGS="$(CDEBUGFLAGS)" xsysinfo
+   $(MAKE) CDEBUGFLAGS="$(CDEBUGFLAGS)" CC="$(CC)" xsysinfo
 
touch build-stamp
 


Bug#987187: libcurl3-gnutls from debian backports breaks git http operations

2021-06-06 Thread Bernhard Geier
Similar issue here, also with libcurl3-gnutls:amd64 (7.64.0-4+deb10u2,
7.74.0-1.2~bpo10+1):

The library is used by mpd (Music Player Daemon) to play http streams.
Using the libcurl3-gnutls version mentioned above, trying to play the
stream https://orf-live.ors-shoutcast.at/fm4-q2a results in

exception: Failed to decode https://orf-live.ors-shoutcast.at/fm4-q2a
exception: nested: CURL failed: Failed sending HTTP2 data

It works when using any older version of libcurl3-gnutls.



Bug#989423: anki: Anki not displaying any decks after clicking "Study Now"

2021-06-06 Thread Julian Gilbey
Hi Jack,

Well, that's weird: /usr/share/javascript/jquery/jquery.js is included
in the libjs-jquery package, so I have no idea why you didn't have it
on your system.

Anyway, pleased to hear that it's now working!

Best wishes,

   Julian

On Sun, Jun 06, 2021 at 12:04:12PM -0400, Jack Thomson wrote:
> Ahhh that totally fixed it. I had only the minified version of jquery at
> /usr/share/javascript/jquery/jquery.min.js A quick symlink over to
> /usr/share/javascript/jquery/jquery.js and it seems fixed! Really appreciate 
> the
> help!
> On Sun, Jun 6, 2021 at 2:08 AM Julian Gilbey  wrote:
> 
>   Hi Jack,
> 
>   OK, this is weird; these exactly match the versions I have on my
>   system.
> 
>   My best guess is that anki is somehow not detecting the jquery library
>   on your system, but I don't know why that would be the case.  I'm
>   presuming that you do have the file
>   /usr/share/javascript/jquery/jquery.js on your system, and that it's
>   world readable?
> 
>   Best wishes,
> 
>      Julian
> 
>   On Fri, Jun 04, 2021 at 11:23:12AM -0400, Jack Thomson wrote:
>   > Appreciate the response! I totally believe it's one of my packages. Here's
>   my
>   > versions:
>   > Running dpkg-query --show | grep for each package:
>   > python3-pyqt5.qtwebengine 5.15.2-2
>   > python3-pyqt5.qtwebchannel 5.15.2+dfsg-3
>   > libjs-jquery 3.5.1+dfsg+~3.5.5-7
>   > libjs-jquery-flot 4.2.1+dfsg-5
>   > libjs-jquery-ui 1.12.1+dfsg-8
>   > libjs-mathjax 2.7.9+dfsg-1
>   > Are any of those unexpected to you?
>   > On Fri, Jun 4, 2021 at 4:13 AM Julian Gilbey  wrote:
>   >
>   >   tags 989423 +moreinfo
>   >   thanks
>   >
>   >   On Thu, Jun 03, 2021 at 07:37:14AM -0400, Jack Thomson wrote:
>   >   > Package: anki
>   >   > Version: 2.1.15+dfsg-3
>   >   > Severity: important
>   >   >
>   >   > Dear Maintainer,
>   >   >
>   >   >    * What led up to the situation?
>   >   >    - I installed anki via apt, and neither creating decks nor 
> importing
>   >   >      decks seems to work. The terminal constantly prints:
>   >   >
>   >   >      "JS error on line 1: Uncaught ReferenceError: $ is not defined
>   >   >       JS error on line 34: Uncaught ReferenceError: $ is not defined
>   >   >       JS error on line 99: Uncaught ReferenceError: $ is not defined
>   >   >       JS error on line 109: Uncaught ReferenceError: $ is not defined"
>   >   >
>   >   >     All the menus, seem to function well enough. I'm not too educated 
> on
>   >   >     the matter, but could it be something to do with Wayland?
>   >
>   >   Dear Jack,
>   >
>   >   Thanks for reporting this.  I'm a little bit stuck, as I cannot
>   >   reproduce this error on my machine.  The error you have found seems to
>   >   be some sort of issue in jsQuery or some JavaScript that uses jsQuery,
>   >   by the looks of things.  But there do not seem to be any JavaScript
>   >   files in the Anki package which would give the errors you have got.
>   >
>   >   What versions do you have installed of the following packages:
>   >
>   >   python3-pyqt5.qtwebengine, python3-pyqt5.qtwebchannel, libjs-jquery,
>   >   libjs-jquery-ui, libjs-jquery-flot, libjs-mathjax
>   >
>   >   I'm wondering whether it's something in one of those, perhaps?
>   >
>   >   Best wishes,
>   >
>   >      Julian



Bug#989532: unblock: mc/3:4.8.26-1.1

2021-06-06 Thread Thorsten Glaser
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de, only...@debian.org, y...@shurup.com, 
ti...@debian.org, deb...@denis-briand.fr

Please unblock package mc

[ Reason ]
This fixes #987446 which basically made any file that isn’t called
.zip but is a PKZIP container (including both things that are ZIP-like
archives, like *.jar, and those which aren’t, like office documents)
unusable with mc.

[ Impact ]
Quite a regression and limiting use.

[ Tests ]
I’ve manually tested this. It’s a backport of an upstream fix,
so I guess they also tested it, and it’ll be part of the next
upstream release.

[ Risks ]
This changes a conffile only, in a somewhat-leaf (only pulled
in by tasks-like packages) package. If anything should need to
be fixed up later, it can if necessary be done by the end user
changing the file in /etc.

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

[ Other info ]

unblock mc/3:4.8.26-1.1
diff -Nru mc-4.8.26/debian/changelog mc-4.8.26/debian/changelog
--- mc-4.8.26/debian/changelog  2021-02-01 02:44:43.0 +0100
+++ mc-4.8.26/debian/changelog  2021-06-01 15:26:23.0 +0200
@@ -1,3 +1,10 @@
+mc (3:4.8.26-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix PKZIP archive handling, patch backported from upstream
+
+ -- Thorsten Glaser   Tue, 01 Jun 2021 15:26:23 +0200
+
 mc (3:4.8.26-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru mc-4.8.26/debian/patches/fix-987446.patch 
mc-4.8.26/debian/patches/fix-987446.patch
--- mc-4.8.26/debian/patches/fix-987446.patch   1970-01-01 01:00:00.0 
+0100
+++ mc-4.8.26/debian/patches/fix-987446.patch   2021-06-01 15:24:55.0 
+0200
@@ -0,0 +1,263 @@
+Origin: upstream, commit:fa2cbd2a2c7e38ee56d1756eac5899b57f7f4262
+From: Andrew Borodin 
+Description: Ticket #4180: reorgzanize mc.ext.
+ $ file -L image.zip
+ image.zip: Zip archive data, at least v2.0 to extract
+ $ file -L -z image.zip
+ image.zip: JPEG image data, JFIF standard 1.01, resolution (DPI),
+ density 96x96, segment length 16, baseline, precision 8, 1024x768,
+ frames 3 (Zip archive data, at least v2.0 to extract)
+ .
+ Since in mc.ext
+ .
+ type/^JPEG
+ .
+ is evaluated before
+ .
+ type/\(Zip archive
+ .
+ mc assume image.zip is a image not an archive.
+ .
+ To solve this, since we use "file -z", match file name at first
+ (regex/ and shell/), then type/.
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987446
+
+--- a/misc/mc.ext.in
 b/misc/mc.ext.in
+@@ -107,6 +107,7 @@
+ ### Changes ###
+ #
+ # Reorganization: 2012-03-07 Slava Zanko 
++# 2021-03-28 Andrew Borodin 
+ 
+ 
+ ### GIT Repo ###
+@@ -117,6 +118,7 @@ regex/^\[git\]
+ 
+ 
+ ### Archives ###
++# Since we use "file -z", we should use regex/ and shell/ at first, then 
type/.
+ 
+ # .tgz, .tpz, .tar.gz, .tar.z, .tar.Z, .ipk, .gem
+ regex/\.t([gp]?z|ar\.g?[zZ])$|\.ipk$|\.gem$
+@@ -171,16 +173,6 @@ shell/i/.tar
+   Open=%cd %p/utar://
+   View=%view{ascii} @EXTHELPERSDIR@/archive.sh view tar
+ 
+-# lha
+-type/^LHa\ .*archive
+-  Open=%cd %p/ulha://
+-  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lha
+-
+-# PAK
+-type/^PAK\ .*archive
+-  Open=%cd %p/unar://
+-  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view pak
+-
+ # arj
+ regex/i/\.a(rj|[0-9][0-9])$
+   Open=%cd %p/uarj://
+@@ -300,7 +292,6 @@ shell/i/.iso
+   Open=%cd %p/iso9660://
+   View=%view{ascii} @EXTHELPERSDIR@/misc.sh view iso9660
+ 
+-
+ regex/\.(diff|patch)$
+   Open=%cd %p/patchfs://
+   View=%view{ascii} @EXTHELPERSDIR@/misc.sh view cat
+@@ -316,6 +307,102 @@ shell/i/.lib
+   Open=%cd %p/ulib://
+   View=%view{ascii} @EXTHELPERSDIR@/misc.sh view lib
+ 
++# ace
++shell/i/.ace
++  Open=%cd %p/uace://
++  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view ace
++  Extract=unace x %f
++
++# arc
++shell/i/.arc
++  Open=%cd %p/uarc://
++  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view arc
++  Extract=arc x %f '*'
++  Extract (with flags)=I=%{Enter any Arc flags:}; if test -n "$I"; then 
arc x $I %f; fi
++
++# zip
++shell/i/.zip
++  Open=%cd %p/uzip://
++  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zip
++
++# zoo
++shell/i/.zoo
++  Open=%cd %p/uzoo://
++  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zoo
++
++# lz4
++regex/\.lz4$
++  Open=@EXTHELPERSDIR@/archive.sh view lz4 %var{PAGER:more}
++  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lz4
++
++# WIM
++shell/i/\.wim
++  Open=%cd %p/uwim://
++  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view wim
++
++# gzip
++type/\(gzip compressed
++  Open=@EXTHELPERSDIR@/archive.sh view gz %var{PAGER:more}
++  View=%view{ascii} @EXTHELPERSDIR@/archive.sh view gz
++
++# bzip2
++type/\(bzip2 compressed
++  

Bug#989423: anki: Anki not displaying any decks after clicking "Study Now"

2021-06-06 Thread Jack Thomson
Ahhh that totally fixed it. I had only the minified version of jquery at
*/usr/share/javascript/jquery/jquery.min.js* A quick symlink over to
*/usr/share/javascript/jquery/j**query.js* and it seems fixed! Really
appreciate the help!

On Sun, Jun 6, 2021 at 2:08 AM Julian Gilbey  wrote:

> Hi Jack,
>
> OK, this is weird; these exactly match the versions I have on my
> system.
>
> My best guess is that anki is somehow not detecting the jquery library
> on your system, but I don't know why that would be the case.  I'm
> presuming that you do have the file
> /usr/share/javascript/jquery/jquery.js on your system, and that it's
> world readable?
>
> Best wishes,
>
>Julian
>
> On Fri, Jun 04, 2021 at 11:23:12AM -0400, Jack Thomson wrote:
> > Appreciate the response! I totally believe it's one of my packages.
> Here's my
> > versions:
> > Running dpkg-query --show | grep for each package:
> > python3-pyqt5.qtwebengine 5.15.2-2
> > python3-pyqt5.qtwebchannel 5.15.2+dfsg-3
> > libjs-jquery 3.5.1+dfsg+~3.5.5-7
> > libjs-jquery-flot 4.2.1+dfsg-5
> > libjs-jquery-ui 1.12.1+dfsg-8
> > libjs-mathjax 2.7.9+dfsg-1
> > Are any of those unexpected to you?
> > On Fri, Jun 4, 2021 at 4:13 AM Julian Gilbey  wrote:
> >
> >   tags 989423 +moreinfo
> >   thanks
> >
> >   On Thu, Jun 03, 2021 at 07:37:14AM -0400, Jack Thomson wrote:
> >   > Package: anki
> >   > Version: 2.1.15+dfsg-3
> >   > Severity: important
> >   >
> >   > Dear Maintainer,
> >   >
> >   >* What led up to the situation?
> >   >- I installed anki via apt, and neither creating decks nor
> importing
> >   >  decks seems to work. The terminal constantly prints:
> >   >
> >   >  "JS error on line 1: Uncaught ReferenceError: $ is not defined
> >   >   JS error on line 34: Uncaught ReferenceError: $ is not defined
> >   >   JS error on line 99: Uncaught ReferenceError: $ is not defined
> >   >   JS error on line 109: Uncaught ReferenceError: $ is not
> defined"
> >   >
> >   > All the menus, seem to function well enough. I'm not too
> educated on
> >   > the matter, but could it be something to do with Wayland?
> >
> >   Dear Jack,
> >
> >   Thanks for reporting this.  I'm a little bit stuck, as I cannot
> >   reproduce this error on my machine.  The error you have found seems to
> >   be some sort of issue in jsQuery or some JavaScript that uses jsQuery,
> >   by the looks of things.  But there do not seem to be any JavaScript
> >   files in the Anki package which would give the errors you have got.
> >
> >   What versions do you have installed of the following packages:
> >
> >   python3-pyqt5.qtwebengine, python3-pyqt5.qtwebchannel, libjs-jquery,
> >   libjs-jquery-ui, libjs-jquery-flot, libjs-mathjax
> >
> >   I'm wondering whether it's something in one of those, perhaps?
> >
> >   Best wishes,
> >
> >  Julian
>


Bug#989406: wireguard-dkms makes little sense with the bullseye kernel

2021-06-06 Thread Daniel Kahn Gillmor
Control: severity 989406 normal
Control: retitle 989406 wireguard-dkms is unneeded for stock kernels > 5.6

I'm downgrading the severity to keep wireguard-dkms in bullseye -- we
can increase it again once bullseye is released to keep wireguard-dkms
out of bookworm.

Adrian or others, if you would prefer that we handle this differently,
please give a bit more detail about the timeline you'd prefer and why.

Regards,

   --dkg


signature.asc
Description: PGP signature


Bug#989222: marked as done (darktable: crashes with "Floating point exception (core dumped)" after loading some DNG files)

2021-06-06 Thread David Bremner

Hi Jonas;

Can you confirm that the the -4 upload fixes your crashes?

d




signature.asc
Description: PGP signature


Bug#989524: Acknowledgement (RFP - Bugdom - An OpenSource Port of Pangea Software's Bugdom for modern systems)

2021-06-06 Thread Sarah
It’s a 3D Game made in 1999 which originally used apples proprietary 
quickdraw3d library but now works with OpenGL through a fork of the Quesa 
Project.



Bug#989520: plocate: fuse.rclone fs type should be on default prunefs list

2021-06-06 Thread Steinar H. Gunderson
On Sun, Jun 06, 2021 at 07:58:13AM +0200, Stefan Breunig wrote:
> plocate already excludes many FSes that are commonly mounted over the network,
> and thus slow (e.g. fuse.sshfs). I suggest to add "fuse.rclone" to the PRUNEFS
> list in the updatedb.conf, since rclone is also typically used to mount 
> network
> drives.

FWIW, this list comes from mlocate (and was shared with it until recently).
So you may want to file a parallel bug against mlocate.

/* Steinar */



Bug#989524: RFP - Bugdom - An OpenSource Port of Pangea Software's Bugdom for modern systems

2021-06-06 Thread Sarah
Package: Bugdom 

> Project Page: > https://github.com/jorio/Bugdom
>
> License: Creative Commons Attribution-NonCommercial-ShareAlike 4.0 
> International Public License (> 
> https://github.com/jorio/Bugdom/blob/master/LICENSE.md> )
>
> Build Information: > https://github.com/jorio/Bugdom/blob/master/BUILD.md
> (For the Moment Bugdom relies on jorio‘s custom fork of Quesa)
>
>



Bug#989523: RFP - Nanosaur - An OpenSource Port of PangeaSoft‘s MacOS Game for modern systems

2021-06-06 Thread Sarah
Package: Nanosaur
> Project Page: > https://github.com/jorio/nanosaur
>
> Context: Nanosaur is a 1998 Macintosh game by Pangea Software. In it, you’re 
> a cybernetic dinosaur from the future who’s sent back in time 20 minutes 
> before a giant asteroid hits the Earth. And you get to shoot at T-Rexes with 
> nukes. Nanosaur > was bundled with the original iMac and ran on Mac OS 8. 
> It’s also notable for being a prominent showcase of QuickDraw 3D’s 
> capabilities, which was Apple’s high-level 3D graphics API during the 90s. In 
> 1999, Pangea released>  > Nanosaur’s source code 
> >  > to the public. This port 
> is based on that release.
>
> Build Information: > https://github.com/jorio/Nanosaur/blob/master/BUILD.md
>
> (Relies on OpenGL, > libsdl2-dev,…)
> ​
>
>



Bug#983483: Candidate Packaging

2021-06-06 Thread Barak A. Pearlmutter
I've updated the packaging for upstream version 2.4.0, and updated the
debian packaging scripts to the latest-and-greatest in the process.
This involved switching the python build system. The build-time
upstream test suite was failing, because it needs to be able to load
the modules in the package. Rather than deal with that so it can find
them at build time, I migrated the test suite into a DEP-8 test form,
which is a two-line debian/tests/control. This would in theory allow
this to migrate into testing despite the freeze.

I've placed this in a fork of the packaging repo,

https://salsa.debian.org/bap/ssh-audit.git

Please feel free to pick any or all of the changes.

Cheers,

--Barak.

PS I'm a DD, so if you'd like me to upload, either as a once-off or
after adding myself as a co-maintainer, I'd be happy to.



Bug#989531: vcswatch: Error: fatal: dumb http transport does not support shallow capabilities

2021-06-06 Thread Thorsten Glaser
Package: qa.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

https://qa.debian.org/cgi-bin/vcswatch?package=campania and others have:

Error: fatal: dumb http transport does not support shallow capabilities



Bug#988310: ssl-cert: make-ssl-cert uses same filename for template and output

2021-06-06 Thread Parodper

O 06/06/21 ás 13:14, Stefan Bühler escribiu:

Hi,

On Mon, 10 May 2021 11:09:58 +0200 Parodper  
wrote:
Package: ssl-cert Version: 1.1.0 Severity: grave Tags: patch 
Justification: renders package unusable


Given ssl-cert is installed on many systems probably just for the 
snakeoil self-signed certificate I think the severity isn't 
justified, or at least the Justification is wrong.


I only knew of the problem by an user asking in the debian-user-spanish
mailing list, but the man page has that behavior as default. That is the
reason I put it as «grave». Feel free to change the severity.


"Only" creating other certificates seems to be impacted by this.  Is
 there any data which packages are affected by this issue?


I mean, if *I* was the only one to submit a bug report I guess not a lot
of people are affected. I looked around for quite some time because I
couldn't believe that no one else had reported anything.

The suggested patch shifts the arguments, like it is done on other 
parts of the script.


The patch is not in "unified diff" format, which makes it hard to 
read / apply in a safe way.


Sorry, will remember that next time I submit a bug report.


Apart from that it looks like a simple change though.


I though so, but I don't know enough about either the program or bash
scripting to be sure. I saw the option on reportbug and thought «why not?»



Bug#989530: buster-pu: package mupdf/1.14.0+ds1-4+deb10u3

2021-06-06 Thread Bastian Germann

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

Dear Stable Release Team,

At #983104, I have prepared a NMU RFS to fix two CVEs in mupdf for buster that are already fixed in 
bullseye/sid. The security team asked me to hand in a Stable Proposed Updates request for it.


The debdiff for the NMU is attached.

Thanks,
Bastian
diff -Nru mupdf-1.14.0+ds1/debian/changelog mupdf-1.14.0+ds1/debian/changelog
--- mupdf-1.14.0+ds1/debian/changelog   2020-11-07 10:20:45.0 +0100
+++ mupdf-1.14.0+ds1/debian/changelog   2021-02-19 08:55:54.0 +0100
@@ -1,3 +1,13 @@
+mupdf (1.14.0+ds1-4+deb10u3) stable-proposed-updates; urgency=high
+
+  * Non-maintainer upload.
+  * Avoid a use-after-free in fz_drop_band_writer (CVE-2020-16600)
+(Closes: #989526)
+  * Fix double free of object during linearization (CVE-2021-3407)
+(Closes: #983684)
+
+ -- Bastian Germann   Fri, 19 Feb 2021 08:55:54 
+0100
+
 mupdf (1.14.0+ds1-4+deb10u2) buster-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru 
mupdf-1.14.0+ds1/debian/patches/0017-Bug-702253-Avoid-a-use-after-free-in-fz_drop_band_writer.patch
 
mupdf-1.14.0+ds1/debian/patches/0017-Bug-702253-Avoid-a-use-after-free-in-fz_drop_band_writer.patch
--- 
mupdf-1.14.0+ds1/debian/patches/0017-Bug-702253-Avoid-a-use-after-free-in-fz_drop_band_writer.patch
 1970-01-01 01:00:00.0 +0100
+++ 
mupdf-1.14.0+ds1/debian/patches/0017-Bug-702253-Avoid-a-use-after-free-in-fz_drop_band_writer.patch
 2021-02-19 00:54:26.0 +0100
@@ -0,0 +1,34 @@
+From: theshoals 
+Date: Mon, 4 May 2020 03:33:40 -0400
+Origin: 
http://git.ghostscript.com/?p=mupdf.git;h=96751b25462f83d6e16a9afaf8980b0c3f979c8b
+Bug: https://bugs.ghostscript.com/show_bug.cgi?id=702253
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-16600
+Subject: Bug 702253: Avoid a use-after-free in fz_drop_band_writer
+
+A use-after-free would occur when a valid page was followed by
+a page with invalid pixmap dimensions, causing bander --
+a static -- to point to previously freed memory instead of a new
+band_writer.
+---
+ source/tools/mudraw.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/source/tools/mudraw.c b/source/tools/mudraw.c
+index d17506d37..36536bd2c 100644
+--- a/source/tools/mudraw.c
 b/source/tools/mudraw.c
+@@ -920,7 +920,14 @@ static void dodrawpage(fz_context *ctx, fz_page *page, 
fz_display_list *list, in
+   fz_always(ctx)
+   {
+   if (output_format != OUT_PCLM)
++  {
+   fz_drop_band_writer(ctx, bander);
++  /* bander must be set to NULL to avoid 
use-after-frees. A use-after-free
++   * would occur when a valid page was followed 
by a page with invalid
++   * pixmap dimensions, causing bander -- a 
static -- to point to previously
++   * freed memory instead of a new band_writer. */
++  bander = NULL;
++  }
+   fz_drop_bitmap(ctx, bit);
+   bit = NULL;
+   if (num_workers > 0)
diff -Nru 
mupdf-1.14.0+ds1/debian/patches/0018-Bug-703366-Fix-double-free-of-object-during-lineariz.patch
 
mupdf-1.14.0+ds1/debian/patches/0018-Bug-703366-Fix-double-free-of-object-during-lineariz.patch
--- 
mupdf-1.14.0+ds1/debian/patches/0018-Bug-703366-Fix-double-free-of-object-during-lineariz.patch
 1970-01-01 01:00:00.0 +0100
+++ 
mupdf-1.14.0+ds1/debian/patches/0018-Bug-703366-Fix-double-free-of-object-during-lineariz.patch
 2021-02-19 08:55:54.0 +0100
@@ -0,0 +1,51 @@
+From: Robin Watts 
+Date: Fri, 22 Jan 2021 17:05:15 +
+Subject: Bug 703366: Fix double free of object during linearization.
+origin: 
http://git.ghostscript.com/?p=mupdf.git;h=cee7cefc610d42fd383b3c80c12cbc675443176a
+Bug: https://bugs.ghostscript.com/show_bug.cgi?id=703366
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3407
+Bug-Debian: https://bugs.debian.org/983684
+
+This appears to happen because we parse an illegal object from
+a broken file and assign it to object 0, which is defined to
+be free.
+
+Here, we fix the parsing code so this can't happen.
+---
+ source/pdf/pdf-parse.c | 6 ++
+ source/pdf/pdf-xref.c  | 2 ++
+ 2 files changed, 8 insertions(+)
+
+diff --git a/source/pdf/pdf-parse.c b/source/pdf/pdf-parse.c
+index 7abc8c3d41aa..5761c3351773 100644
+--- a/source/pdf/pdf-parse.c
 b/source/pdf/pdf-parse.c
+@@ -749,6 +749,12 @@ pdf_parse_ind_obj(fz_context *ctx, pdf_document *doc,
+   fz_throw(ctx, FZ_ERROR_SYNTAX, "expected generation number (%d 
? obj)", num);
+   }
+   gen = buf->i;
++  if (gen < 0 || gen >= 65536)
++  {
++  if (try_repair)
++  *try_repair = 1;

Bug#989508: xscreensaver: Disconnecting a video output can cause XScreenSaver to crash and unlock

2021-06-06 Thread Tormod Volden
On Sun, Jun 6, 2021 at 12:56 PM Tormod Volden wrote:
>
> I'll take a look at this now. We might want to include this in 5.45+dfsg1-2.
>

I have included the fix from Qubes-OS, pushed to salsa in commit 60304c21.

I did some testing by plugging and unplugging an external monitor
around 19 times.

Tormod


> On Sat, Jun 5, 2021 at 8:51 PM Salvatore Bonaccorso wrote:
> >
> > On oss-security mailinglist an issue with xscreensaver has been
> > published which seems to be specific to the 4.45 version (and not
> > affecting earlier versions, nor 6.00):
> >
> > https://www.openwall.com/lists/oss-security/2021/06/05/1
> >
> > Qubes OS has patched the issue in 5.45:
> >
> > https://www.openwall.com/lists/oss-security/2021/06/05/2
> > https://github.com/QubesOS/qubes-xscreensaver/blob/master/0001-Fix-updating-outputs-info.patch
> >



Bug#989529: ITP: neochat -- Client for Matrix chat

2021-06-06 Thread Norbert Preining
Package: wnpp
Severity: wishlist
Owner: Norbert Preining 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-qt-...@lists.debian.org

* Package name: neochat
  Version : 1.2.0
  Upstream Author : 2020 Carl Schwan 
2020 Noah Davis 
2020 Tobias Fella 
2021 Srevin Saju 
(and others)
* URL : https://invent.kde.org/network/neochat
* License : GPL-2+ etc
  Programming Lang: C++
  Description : Client for Matrix chat

A client for matrix, the decentralized communication protocol.

This package will be maintained in the Qt/KDE group.



Bug#989528: ITP: kquickimageeditor -- Image editing components

2021-06-06 Thread Norbert Preining
Package: wnpp
Severity: wishlist
Owner: Norbert Preining 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-qt-...@lists.debian.org

* Package name: kquickimageeditor
  Version : 0.1.3
  Upstream Author : Carl Schwan 
* URL : https://invent.kde.org/libraries/kquickimageeditor
* License : LGPL-2.1-or-later
  Programming Lang: C++
  Description : Image editing components

A QtQuick plugin providing Image editing components.

This package will me maintained in the Debian Qt/KDE group.



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-06-06 Thread Salvatore Bonaccorso
Hi,

On Sun, Jun 06, 2021 at 12:46:40PM +0200, Andrej Shadura wrote:
> Hi,
> 
> On Sun, 6 Jun 2021, at 12:44, Tormod Volden wrote:
> > Hi Salvatore and Andrew,
> > 
> > I have prepared a xscreensaver 5.45+dfsg1-2 (which removes the setcap)
> > in git. Andrew is my regular sponsor. Andrew, can you please upload
> > this version? Or if you have no time, can Salvatore do it?
> > 
> > Best regards,
> > Tormod
> 
> Sure, I’ll have a look later today when I get a better Internet connection.

Perfect, thank you to both.

Regards,
Salvatore



Bug#989527: ITP: python-markuppy -- module to generate HTML/XML content

2021-06-06 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-markuppy
  Version : 1.14
  Upstream Author : Tyler Bakke 
* URL : https://pypi.org/project/MarkupPy
* License : MIT public-domain
  Programming Lang: Python
  Description : module to generate HTML/XML content

 MarkupPy is a Python module that attempts to make it easier to generate
 HTML/XML from a Python program in an intuitive, lightweight,
 customizable and pythonic way.

MarkupPy is derived from markup.py.
There is a GitHub project for this library, unfortunately it's lagging
far behind the visible data on PyPi.

https://github.com/tylerbakke/MarkupPy

This library is a new build and install dependency for python3-tablib
which I intend updating to the current usptream version.

This package will get maintained within The Python Modules Team.



Bug#989523: RFP - Nanosaur - An OpenSource Port of PangeaSoft‘s MacOS Game for modern systems

2021-06-06 Thread Andrei POPESCU
Control: reassign -1 wnpp
Control: severity -1 wishlist

On Du, 06 iun 21, 10:58:32, Sarah wrote:
> Package: Nanosaur
> > Project Page: > https://github.com/jorio/nanosaur
> >
> > Context: Nanosaur is a 1998 Macintosh game by Pangea Software. In it, 
> > you’re a cybernetic dinosaur from the future who’s sent back in time 20 
> > minutes before a giant asteroid hits the Earth. And you get to shoot at 
> > T-Rexes with nukes. Nanosaur > was bundled with the original iMac and ran 
> > on Mac OS 8. It’s also notable for being a prominent showcase of QuickDraw 
> > 3D’s capabilities, which was Apple’s high-level 3D graphics API during the 
> > 90s. In 1999, Pangea released>  > Nanosaur’s source code 
> > >  > to the public. This 
> > port is based on that release.
> >
> > Build Information: > https://github.com/jorio/Nanosaur/blob/master/BUILD.md
> >
> > (Relies on OpenGL, > libsdl2-dev,…)
> > ​
> >
> >

Reassigning to correct (pseudo)-package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature


Bug#989524: RFP - Bugdom - An OpenSource Port of Pangea Software's Bugdom for modern systems

2021-06-06 Thread Andrei POPESCU
Control: reassign -1 wnpp
Control: severity -1 wishlist

On Du, 06 iun 21, 10:59:03, Sarah wrote:
> Package: Bugdom 
> 
> > Project Page: > https://github.com/jorio/Bugdom
> >
> > License: Creative Commons Attribution-NonCommercial-ShareAlike 4.0 
> > International Public License (> 
> > https://github.com/jorio/Bugdom/blob/master/LICENSE.md> )
> >
> > Build Information: > https://github.com/jorio/Bugdom/blob/master/BUILD.md
> > (For the Moment Bugdom relies on jorio‘s custom fork of Quesa)
> >
> >

Reassigning to correct (pseudo-)package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature


Bug#988310: ssl-cert: make-ssl-cert uses same filename for template and output

2021-06-06 Thread Stefan Bühler
Hi,

On Mon, 10 May 2021 11:09:58 +0200 Parodper  wrote:
> Package: ssl-cert
> Version: 1.1.0
> Severity: grave
> Tags: patch
> Justification: renders package unusable

Given ssl-cert is installed on many systems probably just for the
snakeoil self-signed certificate I think the severity isn't justified,
or at least the Justification is wrong.

"Only" creating other certificates seems to be impacted by this.  Is
there any data which packages are affected by this issue?

> The suggested patch shifts the arguments, like it is done on other parts of 
> the
> script.

The patch is not in "unified diff" format, which makes it hard to read /
apply in a safe way.

Apart from that it looks like a simple change though.

cheers,
Stefan



Bug#987149: xscreensaver: diff for NMU version 5.45+dfsg1-1.1

2021-06-06 Thread Tormod Volden
On Sun, Jun 6, 2021 at 11:57 AM Salvatore Bonaccorso wrote:
>
> I've prepared an NMU for xscreensaver (versioned as 5.45+dfsg1-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>

I saw this now. I would of course prefer to have my 5.45+dfsg1-2
uploaded instead. I'll also look at including a fix for #989508 at the
same time.

BTW, WRT to your comment in your patch, please note that the real
issue is in mesa and xscreensaver 6 simply reverts back to use setuid
instead of using capabilities. So if the libcap removal should be seen
as something temporary, it must be until it gets fixed in mesa, and
not until xscreensaver 6 (in case it would be a permanent removal).

Regards,
Tormod



Bug#989508: xscreensaver: Disconnecting a video output can cause XScreenSaver to crash and unlock

2021-06-06 Thread Tormod Volden
I'll take a look at this now. We might want to include this in 5.45+dfsg1-2.

Tormod

On Sat, Jun 5, 2021 at 8:51 PM Salvatore Bonaccorso wrote:
>
> On oss-security mailinglist an issue with xscreensaver has been
> published which seems to be specific to the 4.45 version (and not
> affecting earlier versions, nor 6.00):
>
> https://www.openwall.com/lists/oss-security/2021/06/05/1
>
> Qubes OS has patched the issue in 5.45:
>
> https://www.openwall.com/lists/oss-security/2021/06/05/2
> https://github.com/QubesOS/qubes-xscreensaver/blob/master/0001-Fix-updating-outputs-info.patch
>



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-06-06 Thread Andrej Shadura
Hi,

On Sun, 6 Jun 2021, at 12:44, Tormod Volden wrote:
> Hi Salvatore and Andrew,
> 
> I have prepared a xscreensaver 5.45+dfsg1-2 (which removes the setcap)
> in git. Andrew is my regular sponsor. Andrew, can you please upload
> this version? Or if you have no time, can Salvatore do it?
> 
> Best regards,
> Tormod

Sure, I’ll have a look later today when I get a better Internet connection.

-- 
Cheers,
  Andrej



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-06-06 Thread Tormod Volden
Hi Salvatore and Andrew,

I have prepared a xscreensaver 5.45+dfsg1-2 (which removes the setcap)
in git. Andrew is my regular sponsor. Andrew, can you please upload
this version? Or if you have no time, can Salvatore do it?

Best regards,
Tormod

On Sat, Jun 5, 2021 at 3:08 PM Salvatore Bonaccorso  wrote:
>
> Hi Tormod,
>
> On Thu, May 06, 2021 at 07:38:34PM +0200, Moritz Mühlenhoff wrote:
> > Am Mon, Apr 19, 2021 at 11:42:54AM +0200 schrieb Moritz Muehlenhoff:
> > > On Sun, Apr 18, 2021 at 07:21:31PM +0200, Tormod Volden wrote:
> > > > Yes, I think dropping the set_cap is the easy way out of here. sonar
> > > > will still be visually pleasing, just not so interesting.
> > >
> > > Let's do that for buster/bullseye? And when xscreensaver gets updated to 
> > > 6.00
> > > after the release, it can be re-enabled?
> >
> > *ping* :-)
>
> Time is starting to get very close to the bullseye release now. Did
> you got a chance to look into preparing the above changes?
>
> Regards,
> Salvatore



Bug#989069: nvidia-driver: Crash when displayport is plugged.

2021-06-06 Thread Christian Marillat
On 06 juin 2021 12:31, Andreas Beckmann  wrote:

> On 05/06/2021 09.14, Christian Marillat wrote:
>> Display driver is working
>
> Which versions? 450.119.03? 450.119.04? 460.84?

As requested in your previous e-mail (tesla-450) 450.119.04

Christian



Bug#989526: mupdf: CVE-2020-16600

2021-06-06 Thread Bastian Germann

Source: mupdf
Version: 1.14.0+ds1-4+deb10u2
Severity: normal
Tags: security buster patch upstream pending
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=702253
X-Debbugs-Cc: t...@security.debian.org

Hi,

The following vulnerability was published for mupdf.
It is already addressed in bullseye and sid.

I have prepared a NMU RFS with the fix for buster at #983104.

CVE-2020-16600[0]:
| A Use After Free vulnerability exists in Artifex Software, Inc. MuPDF library 
1.17.0-rc1
| and earlier when a valid page was followed by a page with invalid pixmap 
dimensions,
| causing bander - a static - to point to previously freed memory instead of a 
newband_writer.

[0] https://security-tracker.debian.org/tracker/CVE-2020-16600
[1] https://bugs.ghostscript.com/show_bug.cgi?id=702253



Bug#989069: nvidia-driver: Crash when displayport is plugged.

2021-06-06 Thread Andreas Beckmann

On 05/06/2021 09.14, Christian Marillat wrote:

Display driver is working


Which versions? 450.119.03? 450.119.04? 460.84?

Andreas



Bug#989525: kbd: resizecons.8 references obsolete disalloc.8

2021-06-06 Thread Nick Black (Public gmail account)
Package: kbd
Version: 2.3.0-3
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

The resizecons.8 man page refers to disalloc.8, which no longer exists. It
ought reference deallocvt.8. I've created a merge request at
https://salsa.debian.org/debian/kbd/-/merge_requests/3 with the correction.

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

Kernel: Linux 5.12.9nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kbd depends on:
ii  libc6  2.31-12

Versions of packages kbd recommends:
ii  console-setup  1.203

kbd suggests no packages.



Bug#987149: xscreensaver: diff for NMU version 5.45+dfsg1-1.1

2021-06-06 Thread Salvatore Bonaccorso
Control: tags 987149 + patch
Control: tags 987149 + pending


Dear maintainer,

I've prepared an NMU for xscreensaver (versioned as 5.45+dfsg1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru xscreensaver-5.45+dfsg1/debian/changelog xscreensaver-5.45+dfsg1/debian/changelog
--- xscreensaver-5.45+dfsg1/debian/changelog	2020-12-23 00:09:44.0 +0100
+++ xscreensaver-5.45+dfsg1/debian/changelog	2021-06-06 10:28:01.0 +0200
@@ -1,3 +1,12 @@
+xscreensaver (5.45+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable setcap call to set cap_net_raw capabilities on sonar binary in
+xscreensaver-gl's postinst maintainer script (CVE-2021-31523)
+(Closes: #987149)
+
+ -- Salvatore Bonaccorso   Sun, 06 Jun 2021 10:28:01 +0200
+
 xscreensaver (5.45+dfsg1-1) unstable; urgency=low
 
   * New upstream release 5.45
diff -Nru xscreensaver-5.45+dfsg1/debian/xscreensaver-gl.postinst xscreensaver-5.45+dfsg1/debian/xscreensaver-gl.postinst
--- xscreensaver-5.45+dfsg1/debian/xscreensaver-gl.postinst	2020-12-23 00:09:44.0 +0100
+++ xscreensaver-5.45+dfsg1/debian/xscreensaver-gl.postinst	2021-06-06 10:28:01.0 +0200
@@ -17,8 +17,9 @@
 fi
 fi
 
-# Apply capabilities to sonar hack so it doesnt need to be setuid root
-which setcap > /dev/null &&
-setcap cap_net_raw=p /usr/libexec/xscreensaver/sonar
+# Disabled call until update to 6.00 (Cf. #987149, CVE-2021-31523)
+## Apply capabilities to sonar hack so it doesnt need to be setuid root
+#which setcap > /dev/null &&
+#setcap cap_net_raw=p /usr/libexec/xscreensaver/sonar
 
 #DEBHELPER#


Bug#989406: wireguard-dkms makes little sense with the bullseye kernel

2021-06-06 Thread Jason A. Donenfeld
Could you close this bug or downgrade its severity, or do whatever it
takes so that this *isn't* removed from bullseye? Removing this
package from the bullseye release would cause large problems.



Bug#989487: mmdebstrap: produces different tarball when building squashfs image

2021-06-06 Thread Johannes Schauer Marin Rodrigues
Quoting Vagrant Cascadian (2021-06-05 19:39:56)
> On 2021-06-05, Johannes Schauer Marin Rodrigues wrote:
> > Quoting Vagrant Cascadian (2021-06-05 03:09:52)
> >> When mmdebstrap produces a tarball directly, it sets different tarball
> >> options:
> >> 
> >> # tar2sqfs and genext2fs do not support extended attributes
> >> if ($format eq "squashfs") {
> >> warning("tar2sqfs does not support extended attributes"
> >>   . " from the 'system' namespace");
> >> push @taropts, '--xattrs', '--xattrs-exclude=system.*';
> >> 
> >> But if you're trying to generate a squashfs image with different default
> >> compression (e.g. zstd), you have to pipe the mmdebstrap output to
> >> tar2sqfs. But in this case, tar is not passed the above options, as it
> >> is generating a tarball...
> >
> > yes. But you can filter the tarball and remove the system.* xattr later:
> >
> > mmdebstrap ... | mmtarfilter --pax-exclude=SCHILY.xattr.system.* | tar2sqfs 
> > ...
> 
> This might be worth mentioning in the mmdebstrap manpage! And updating
> the mmtarfilter manpage with --pax-exclude too... :)

In fact, that functionality only exists in git so far, sorry. I'm waiting for
the freeze to end so that I can upload a new mmdebstrap version to unstable.

> >> Maybe I'm missing something, but it would be very nice to be able to at
> >> least append to options passed to tar2sqfs (presuming it doesn't error
> >> when passing two different --compressor arguments), rather than having to
> >> extract them from the manpage and/or code, especially given that the tar
> >> output changes when you create a regular tarball vs. when mmdebstrap is
> >> aware that the eventual destination is a squashfs...
> >
> > Is that such a common task? Are you running mmdebstrap manually and find
> > yourself piping it to tar2sqfs by hand? Do you maybe suggest that the 
> > default
> > options might need changing? I'm trying to understand your use-case here.
> 
> Well, *mostly* just to build zstd squashfs instead of xz (the
> performance on various hardware I use is considerable better with zstd
> defaults). Being able to set the compression type directly from
> mmdebstrap would be nice!
> 
> I think I also needed to pipe to tar2sqfs manually in the past to
> workaround bugs that I think have since been fixed (e.g. the
> --xattrs-exclude patches).

But are you running mmdebstrap by hand or are you using it as part of a script?

> The current default for tar2sqfs is xz, so passing --compressor xz is
> redundant.

Maybe I should just drop the "--compressor xz" option and use the tar2sqfs
default and then you can post a bugreport about a good default with the
tar2sqfs people instead of here. ;)

> >> I'm also realizing that the squashfs call doesn't pass --num-jobs=0 to
> >> tar2sqfs (similar to when creating a .tar.zst).
> >
> > Indeed that can be fixed.
> 
> Apparently, the default for tar2sqfs is number of cores:
> 
>--num-jobs, -j 
>   If libsquashfs was compiled with a thread pool based,
>   parallel data compressor, this option can be used to set
>   the number of compressor threads. If not set, the default
>   is the number of available CPU cores.
> 
> So I guess that's not needed at all.

Aha, cool. Thanks!

cheers, josch

signature.asc
Description: signature


Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

2021-06-06 Thread Jan Gruber

Hello Samuel,

On Sat, 29 May 2021 14:06:18 +0100 Samuel Henrique wrote:
>
> That's a great catch!
> I'm bumping the severity as this "makes the package in question
> unusable or mostly so".

thanks for getting back to me regarding this bug.

Since there is just an offset in the values used for key identification,
which stems from the `xor_count_256` respectively
`xor_count_128`-variable, the package is still kind of usable, if the
default threshold is raised -- either manually via `-t 50`or via a patch
during compile time. Nevertheless, this should be fixed in a proper way,
I think.

> I believe you accidentally pasted the same link twice when talking
> about two different functions.

Yes, this was a faux pas -- sorry for that! The second suspicious
function, which I mentioned in my previous message, seems to be
`key_core(...)` in `aes.h`. You can find it here [1]. The two referenced
functions basically perform the heavy lifting of aeskeyfind's compuations.

> Could you submit your tests so we can confirm any fix applied (if we
do so)?
> I would like to use your tests with git-bisect to make sure this
> regression wasn't caused by one of our patches.

I am very confident, that the Debian's patches applied during the
packaging are fine, since I checked the results of the unmodified
upstream source also, which I built by myself and got the same erroneous
results. Therefore it looks like to me, that the error stems from some
changes related to glibc 2.31-11 (or maybe even the kernel in Version
5.10.0.6).

The tests, that I created and which led to uncovering this issue can be
found here:

https://salsa.debian.org/jgru/aeskeyfind/-/commit/04c9a6038a047fa97e527cc05346416b98949c4c


You can get and run those tests with the following commands:
```
git clone g...@salsa.debian.org:jgru/aeskeyfind.git
git checkout add-autopkgtests
autopkgtest --debug -- schroot sid-amd64
```
If you remove line 62 of `debian/tests/helpers/ test_aes_extraction.sh`
[3] you can preserve the resulting dump for manual testing.
If you add `-t 50`to line 56 of `debian/tests/helpers/
test_aes_extraction.sh` [4]  the tests will succeed.

>
> It's possible that this bug also affects rsakeyfind, so I would
> appreciate it if you could run your test against that package as well
> (I assume it must be easy since they are so similar).
>

I performed similar tests regarding rsakeyfind and have to say, that
this software is not affected at all. Please refer to my merge request
containing the autopkgtests for rsakeyfind at [5].

If you have any ideas on how to debug this issue in a targeted manner,
please get back to me.

Thanks for tackling this problem!

Best regards,
   Jan
---
[1]
https://salsa.debian.org/pkg-security-team/aeskeyfind/-/blob/debian/master/aes.h#L12
[2]
https://citpsite.s3.amazonaws.com/memory-content/src/aeskeyfind-1.0.tar.gz
[3]
https://salsa.debian.org/jgru/aeskeyfind/-/blob/add-autopkgtests/debian/tests/helpers/test_aes_extraction.sh#L62
[4]
https://salsa.debian.org/jgru/aeskeyfind/-/blob/add-autopkgtests/debian/tests/helpers/test_aes_extraction.sh#L56
[5]
https://salsa.debian.org/pkg-security-team/rsakeyfind/-/merge_requests/2?commit_id=e7d030704f56c84ff48893883af2c5cc46414c4b



Bug#987298: gdm3: Fails to unlock GNOME keyring when multiple attempts were needed to unlock LUKS

2021-06-06 Thread intrigeri
Hi Simon,

Simon McVittie (2021-04-30):
> Sorry, I can't work out how to get a system where the bug you reported
> would even be relevant. At this stage in the release process I am reluctant
> to apply changes that I can't test - please could you describe how I can?

Thanks for having considered my request so seriously.
I feel like I've wasted your time and I'm sorry for this.

I'm afraid this bug report I submitted turned into something vastly
more complicated than I thought initially. I don't have the bandwidth
to spend the time needed to move this forward for Bullseye.

The bugfix will propagate to Debian on its own eventually so perhaps
we can close this bug as "non actionable without extra work that I'm
not in a position to do"?

Cheers!



Bug#989193: [pkg-apparmor] Bug#989193: Bug#989193: breaks apt-cacher-ng by blocking link operation

2021-06-06 Thread intrigeri
Control: severity -1 important

intrigeri (2021-06-02):
> I see you've made this bug RC. I'd like to better understand the
> severity, so I can figure out what I should do for Bullseye.
> I'm wondering because I'm using this AppArmor policy on sid with
> apt-cacher-ng myself, and I can't find traces of such denials in
> my logs.
>
> Could you please help me understand what kind of apt-cacher-ng
> operations (or configuration) trigger these denials and are broken by
> the current AppArmor policy?

I'm downgrading severity until this is clarified: with the information
_currently_ available to me, this bug does not make the package unfit
for Bullseye, so triggering auto-removal seems a bit extreme.
Happy to change my mind once I have more info :)



Bug#900244: This may not be pure smartmon problem but a kernel problem

2021-06-06 Thread borissh1983
Hi, 

I have the same problem with  SAMSUNG MZVLB512HAJQ-000L7 , from my tests this 
will not happen with kernel 4.19-10 but does happen with kernel 5.9 and 5.10. 

The errors on nvme level is using sudo nvme error-log /dev/nvme0: 

. 
Entry[63]
. 
error_count : 0 
sqid: 0 
cmdid   : 0 
status_field: 0(SUCCESS: The command completed successfully) 
parm_err_loc: 0 
lba : 0 
nsid: 0 
vs  : 0 
trtype  : The transport type is not indicated or the error is not 
transport related. 
cs  : 0 
trtype_spec_info: 0 
.

I have also found that at least for Transcend drives they say : 

"Why does the Number of Error Information Log Entries in the SMART values 
increase along with the number of times the computer is turned on and off?"

"Due to the fact that some platforms send non-NVMe command signals to the SSD, 
the Number of Error Information Log Entries in the SMART values of the SSD 
continues to increase. Error notification messages even appear on the screen 
when booting.
The counting of this value will not cause any impact on the use of the SSD. 
Customers may use it with peace of mind. "


Bug#989522: unblock: trscripts/1.18+nmu2 xfonts-bolkhov/1.1.20001007-8.2

2021-06-06 Thread Jochen Sprickerhof
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package trscripts and xfonts-bolkhov

[ Reason ]
The awk script generated by trscripts used a non deterministic for-in
loop resulting in the russian letter 'у' displayed as latin u with the
xfonts-bolkhov-misc font. This was reported as #979599 and #979710.

[ Impact ]
Font rendering would be wrong without the patch.

[ Tests ]
run: xfontsel -sampleUCS у -pattern "-rfx-*" and look at the displayed
symbol.

[ Risks ]
The change in trscripts is minimal, just using a different for loop
style. xfonts-bolkhov is a no change rebuild, just bumping the
dependency on trscripts.

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

unblock trscripts/1.18+nmu2
unblock xfonts-bolkhov/1.1.20001007-8.2
diff -Nru trscripts-1.18+nmu1/debian/changelog 
trscripts-1.18+nmu2/debian/changelog
--- trscripts-1.18+nmu1/debian/changelog2021-01-07 15:01:30.0 
+0100
+++ trscripts-1.18+nmu2/debian/changelog2021-06-05 20:08:15.0 
+0200
@@ -1,3 +1,12 @@
+trscripts (1.18+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make trbdf awk script portable (Closes: #979599).
+POSIX awk does not specify the order in a for(i in array) loop, so
+switching to a for loop with an increment.
+
+ -- Jochen Sprickerhof   Sat, 05 Jun 2021 20:08:15 +0200
+
 trscripts (1.18+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru trscripts-1.18+nmu1/gen_trbdf trscripts-1.18+nmu2/gen_trbdf
--- trscripts-1.18+nmu1/gen_trbdf   2009-05-02 12:43:11.0 +0200
+++ trscripts-1.18+nmu2/gen_trbdf   2021-06-05 20:08:15.0 +0200
@@ -312,15 +312,15 @@
 EOF
 
 if [ "$usefb" = yes ]; then
-printf "   split(tu[i] \" \" alt1[tu[i]] \" \" alt2[tu[i]], a);\n"
+printf "   an = split(tu[i] \" \" alt1[tu[i]] \" \" alt2[tu[i]], a);\n"
 printf "   split(0 \" \" weight1[tu[i]] \" \" weight2[tu[i]], w);\n"
 else
-printf "   split(tu[i] \" \" alt1[tu[i]], a);\n"
+printf "   an = split(tu[i] \" \" alt1[tu[i]], a);\n"
 printf "   split(0 \" \" weight1[tu[i]], w);\n"
 fi
 
 cat <<"EOF"
-   for(j in a)
+   for(j=1; j <= an; ++j)
  {
if(ut[a[j]]!="")
  {
@@ -339,7 +339,7 @@
  }
  }
k=0;
-   for(j in a)
+   for(j=1; j <= an; ++j)
  {
if(ut[a[j]]!="")
  {
@@ -356,7 +356,7 @@
printf "\";\n";
  }
k=0;
-   for(j in a)
+   for(j=1; j <= an; ++j)
  {
if(ut[a[j]]!="")
  {
diff -u xfonts-bolkhov-1.1.20001007/debian/changelog 
xfonts-bolkhov-1.1.20001007/debian/changelog
--- xfonts-bolkhov-1.1.20001007/debian/changelog
+++ xfonts-bolkhov-1.1.20001007/debian/changelog
@@ -1,3 +1,11 @@
+xfonts-bolkhov (1.1.20001007-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump dependency on trscripts to fix generated fonts when using mawk, cf.
+#979599.
+
+ -- Jochen Sprickerhof   Sat, 05 Jun 2021 23:47:31 +0200
+
 xfonts-bolkhov (1.1.20001007-8.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u xfonts-bolkhov-1.1.20001007/debian/control 
xfonts-bolkhov-1.1.20001007/debian/control
--- xfonts-bolkhov-1.1.20001007/debian/control
+++ xfonts-bolkhov-1.1.20001007/debian/control
@@ -3,7 +3,7 @@
 Section: fonts
 Priority: optional
 Standards-Version: 3.6.2
-Build-Depends: debhelper (>=9~), trscripts (>= 1.13), xfonts-utils
+Build-Depends: debhelper (>=9~), trscripts (>= 1.18+nmu2), xfonts-utils
 
 Package: xfonts-bolkhov-75dpi
 Architecture: all


Bug#989498: unblock: golang-1.15/1.15.9-5

2021-06-06 Thread Shengjing Zhu
On Sun, Jun 6, 2021 at 11:46 AM Paul Gevers  wrote:
>
> Control: tags -1 moreinfo
>
> Hi Shengjing,
>
> On 05-06-2021 13:57, Shengjing Zhu wrote:
> > Please unblock package golang-1.15
>
> You're well aware that golang builds statically so normally we're not
> done with just accepting one package. Do we now need to also rebuild
> everything that build depends on golang (I'd expect so)?

Yes. That's why the compiler is uploaded in unstable, as rebuilding in
unstable is much easier before release. We didn't manage to rebuild
any package in buster for the compiler security update after release.

> Did anything in
> the golang community get uploaded to unstable that needs reverting
> before it can migrate?

>From my observation[1], all packages are in good condition, thanks to
the freezone policy this year. Most Go packages are not key packages,
and have non-trivial autopkgtest.
+ one package still has long migration days, which is secsipidx(only 5
of 20 days old), but it will not block the migration of the Go
compiler or other packages.
+ one package won't migrate, which is kubernetes, but the
outdated-built-using rebuild script will not pick it up, as it doesn't
have built-using field. (This doesn't mean it doesn't need to be
rebuilt for the compiler security update, but no one cares about this
package).

[1] https://people.debian.org/~zhsj/out-of-sync.html

-- 
Shengjing Zhu



Bug#988608: RFS: scrollz/2.2.3-2 - advanced ircII-based IRC client

2021-06-06 Thread Tobias Frost
Control: reopen -1

Hi Mike,

just a second after the upload I've realized that the version is wrong…
It would need to be 2.2.3-1+deb10u1.dsc… (otherwise update from buster
to bullseye will not work)

For the reupload, though, I'll need the old package to be rejected first…

Sorry for /me not paying attention to that detail…

-- 
tobi

> https://mentors.debian.net/debian/pool/main/s/scrollz/scrollz_2.2.3-2+deb10u1.dsc



Bug#988608: RFS: scrollz/2.2.3-2 - advanced ircII-based IRC client

2021-06-06 Thread Tobias Frost
Hi Mike,

On Sat, Jun 05, 2021 at 11:37:53AM -0600, Mike Markley wrote:
> I've also uploaded scrollz_2.2.3-2+deb10u1 to mentors.debian.net and stand
> ready to open the necessary bug against release.debian.org justifying the
> buster update. It can be found at:
> 
 
https://mentors.debian.net/debian/pool/main/s/scrollz/scrollz_2.2.3-2+deb10u1.dsc
> 
> I would very much appreciate it if someone could assist by uploading it on
> my behalf.

I've uploaded it with one change: I replaced "stable" with "buster" as targeting
distribution (see devref 5.5.1).

diff of my change:
--- debian/changelog.orig   2021-06-06 08:19:32.170083362 +0200
+++ debian/changelog2021-06-06 08:19:45.946454593 +0200
@@ -1,4 +1,4 @@
-scrollz (2.2.3-2+deb10u1) stable; urgency=high
+scrollz (2.2.3-2+deb10u1) buster; urgency=high
 
   * Rebuild for stable

-- 
Cheers,
tobi



Bug#989423: anki: Anki not displaying any decks after clicking "Study Now"

2021-06-06 Thread Julian Gilbey
Hi Jack,

OK, this is weird; these exactly match the versions I have on my
system.

My best guess is that anki is somehow not detecting the jquery library
on your system, but I don't know why that would be the case.  I'm
presuming that you do have the file
/usr/share/javascript/jquery/jquery.js on your system, and that it's
world readable?

Best wishes,

   Julian

On Fri, Jun 04, 2021 at 11:23:12AM -0400, Jack Thomson wrote:
> Appreciate the response! I totally believe it's one of my packages. Here's my
> versions:
> Running dpkg-query --show | grep for each package:
> python3-pyqt5.qtwebengine 5.15.2-2
> python3-pyqt5.qtwebchannel 5.15.2+dfsg-3
> libjs-jquery 3.5.1+dfsg+~3.5.5-7
> libjs-jquery-flot 4.2.1+dfsg-5
> libjs-jquery-ui 1.12.1+dfsg-8
> libjs-mathjax 2.7.9+dfsg-1
> Are any of those unexpected to you?
> On Fri, Jun 4, 2021 at 4:13 AM Julian Gilbey  wrote:
> 
>   tags 989423 +moreinfo
>   thanks
> 
>   On Thu, Jun 03, 2021 at 07:37:14AM -0400, Jack Thomson wrote:
>   > Package: anki
>   > Version: 2.1.15+dfsg-3
>   > Severity: important
>   >
>   > Dear Maintainer,
>   >
>   >    * What led up to the situation?
>   >    - I installed anki via apt, and neither creating decks nor importing
>   >      decks seems to work. The terminal constantly prints:
>   >
>   >      "JS error on line 1: Uncaught ReferenceError: $ is not defined
>   >       JS error on line 34: Uncaught ReferenceError: $ is not defined
>   >       JS error on line 99: Uncaught ReferenceError: $ is not defined
>   >       JS error on line 109: Uncaught ReferenceError: $ is not defined"
>   >
>   >     All the menus, seem to function well enough. I'm not too educated on
>   >     the matter, but could it be something to do with Wayland?
> 
>   Dear Jack,
> 
>   Thanks for reporting this.  I'm a little bit stuck, as I cannot
>   reproduce this error on my machine.  The error you have found seems to
>   be some sort of issue in jsQuery or some JavaScript that uses jsQuery,
>   by the looks of things.  But there do not seem to be any JavaScript
>   files in the Anki package which would give the errors you have got.
> 
>   What versions do you have installed of the following packages:
> 
>   python3-pyqt5.qtwebengine, python3-pyqt5.qtwebchannel, libjs-jquery,
>   libjs-jquery-ui, libjs-jquery-flot, libjs-mathjax
> 
>   I'm wondering whether it's something in one of those, perhaps?
> 
>   Best wishes,
> 
>      Julian



Bug#989521: gcc-N: make ssp linking work on musl

2021-06-06 Thread Helmut Grohne
Source: gcc-11
Version: 11.1.0-2
Tags: patch
X-Debbugs-Cc: Szabolcs Nagy , Rich Felker 


I was looking into making the Debian packaging of gcc work with musl and
ran into issues with musl. Once enabling -fstack-protector-something,
linking tends to fail with missing symbols.

The reason is that musl enables TARGET_LIBC_PROVIDES_SSP, because its
libc.so provides the relevant ssp functions. No extra library needs to
be linked. What it does not provide though is libssp_nonshared.a. The
upstream gcc does not handle this situation and considers their presence
interlocked.

More background on this can be found at
https://www.openwall.com/lists/musl/2014/11/05/3.

Another issue is that any object compiled with
-fstack-protector-something makes it use a symbol from
libssp_nonshared.a, so the resulting link has to include -lssp_nonshared
regardless of whether a -fstack-protector-something is given.

The solution chosen by Alpine is changing LINK_SSP_SPEC to
unconditionally link "-lssp_nonshared", see
https://git.alpinelinux.org/aports/commit/?id=d307f133de1f8a9993ab0d6fd51176b9373df4c3.
Since Alpine is the largest musl user, following their lead seems
natural.

Once doing so, bootstrapping fails, because libbacktrace is built before
libssp and at that time there is no libssp_nonshared.a. However, it
isn't actually needed during bootstrap, because it's not built with
-fstack-protector-something. An empty libssp_nonshared.a would to to
make -lssp_nonshared happy there. So I propose injecting such an empty
library before the build. When someone enables ssp on gcc libraries,
this approach will break of course, but the breakage is already there
due to the missing ordering. Once the ordering is fixed upstream, my
workaround can be dropped without replacement.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru gcc-11-11.1.0/debian/changelog 
gcc-11-11.1.0/debian/changelog
--- gcc-11-11.1.0/debian/changelog  2021-05-08 13:50:11.0 +0200
+++ gcc-11-11.1.0/debian/changelog  2021-06-04 18:14:22.0 +0200
@@ -1,3 +1,10 @@
+gcc-11 (11.1.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix -fstack-protector on musl. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Jun 2021 18:14:22 +0200
+
 gcc-11 (11.1.0-2) experimental; urgency=medium
 
   * Update to git 20210508 from the gcc-11 branch.
diff --minimal -Nru gcc-11-11.1.0/debian/patches/musl-ssp.diff 
gcc-11-11.1.0/debian/patches/musl-ssp.diff
--- gcc-11-11.1.0/debian/patches/musl-ssp.diff  1970-01-01 01:00:00.0 
+0100
+++ gcc-11-11.1.0/debian/patches/musl-ssp.diff  2021-06-04 18:14:16.0 
+0200
@@ -0,0 +1,21 @@
+See 
https://git.alpinelinux.org/aports/commit/?id=d307f133de1f8a9993ab0d6fd51176b9373df4c3
+and https://www.openwall.com/lists/musl/2014/11/05/3
+
+--- gcc-11-11.1.0.orig/src/gcc/gcc.c
 gcc-11-11.1.0/src/gcc/gcc.c
+@@ -1087,8 +1087,15 @@
+ 
+ #ifndef LINK_SSP_SPEC
+ #ifdef TARGET_LIBC_PROVIDES_SSP
++#if DEFAULT_LIBC == LIBC_MUSL
++/* When linking without -fstack-protector-something but including objects that
++   were built with -fstack-protector-something, calls to 
__stack_chk_fail_local
++   can be emitted. Thus -lssp_nonshared must be linked unconditionally.  */
++#define LINK_SSP_SPEC "-lssp_nonshared"
++#else
+ #define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
+  "|fstack-protector-strong|fstack-protector-explicit:}"
++#endif
+ #else
+ #define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
+  "|fstack-protector-strong|fstack-protector-explicit" \
diff --minimal -Nru gcc-11-11.1.0/debian/rules.patch 
gcc-11-11.1.0/debian/rules.patch
--- gcc-11-11.1.0/debian/rules.patch2021-05-02 09:17:25.0 +0200
+++ gcc-11-11.1.0/debian/rules.patch2021-06-04 18:11:17.0 +0200
@@ -61,6 +61,7 @@
pr87808 \
pr94253 \
gcc-arm-disable-guality-tests \
+   musl-ssp \
 
 ifneq (,$(filter $(distrelease),precise xenial bionic focal groovy hirsute))
   debian_patches += pr100067-revert
diff --minimal -Nru gcc-11-11.1.0/debian/rules2 gcc-11-11.1.0/debian/rules2
--- gcc-11-11.1.0/debian/rules2 2021-05-02 09:26:04.0 +0200
+++ gcc-11-11.1.0/debian/rules2 2021-06-04 18:10:24.0 +0200
@@ -1191,6 +1191,14 @@
rm -rf $(builddir)
mkdir $(builddir)
 
+ifneq (,$(filter musl-%,$(DEB_TARGET_ARCH)))
+   # We have to unconditionally link -lssp_nonshared on musl (see
+   # musl-ssp.diff). While gcc provides it, it comes a little late in the
+   # build for bootstrapping so we provide an empty one.
+   mkdir $(builddir)/gcc
+   ar rcs $(builddir)/gcc/libssp_nonshared.a
+endif
+
: # some tools like gettext are built with a newer libstdc++
mkdir -p bin
for i in msgfmt; do \


Bug#989520: plocate: fuse.rclone fs type should be on default prunefs list

2021-06-06 Thread Stefan Breunig
Package: plocate
Version: 1.1.7-1
Severity: wishlist

Dear Maintainer,

plocate already excludes many FSes that are commonly mounted over the network,
and thus slow (e.g. fuse.sshfs). I suggest to add "fuse.rclone" to the PRUNEFS
list in the updatedb.conf, since rclone is also typically used to mount network
drives.

To verify locally, you can instruct rclone to mount a local directory; rougly:
  apt install rclone
  rclone config create local local
  rclone mount local:/source-dir /target-dir

Cheers
Stefan

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

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

Versions of packages plocate depends on:
ii  libc6   2.31-1
ii  libgcc-s1   10.1.0-6
ii  libstdc++6  10.1.0-6
ii  liburing1   0.7-3
ii  libzstd11.4.5+dfsg-3

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv245.6-2

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

-- no debconf information