Bug#973907: sddm 0.19.0-1 doesnt remeber last session

[Hendrik Lehmbruch]

Package: sddm
Version: 0.19.0-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
upgrading sddm

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
reboot and login, now 3 times

   * What was the outcome of this action?
in my case i thought that plasma would pop up, but fluxbox appears

   * What outcome did you expect instead?
i would like to see a plasma-session (last-session) with out choosing it after
every reboot/logout and not the first in the line (fluxbox in my case)



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

Kernel: Linux 5.9.6-towo.1-siduction-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.74
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-16
ii  libpam0g1.3.1-5
ii  libqt5core5a5.15.1+dfsg-2
ii  libqt5dbus5 5.15.1+dfsg-2
ii  libqt5gui5  5.15.1+dfsg-2
ii  libqt5network5  5.15.1+dfsg-2
ii  libqt5qml5  5.15.1+dfsg-3
ii  libqt5quick55.15.1+dfsg-3
ii  libstdc++6  10.2.0-16
ii  libsystemd0 246.6-2
ii  libxcb-xkb1 1.14-2
ii  libxcb1 1.14-2
ii  qml-module-qtquick2 5.15.1+dfsg-3
ii  x11-common  1:7.7+21
ii  xauth   1:1.0.10-1
ii  xserver-xorg [xserver]  1:7.7+21

Versions of packages sddm recommends:
ii  haveged1.9.8-4
ii  libpam-systemd 246.6-2
ii  sddm-theme-2001 [sddm-theme]   1.1
ii  sddm-theme-debian-elarun [sddm-theme]  0.19.0-1
ii  sddm-theme-patience [sddm-theme]   2018.3.0-1

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.20.2-1~np1
pn  qtvirtualkeyboard-plugin  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#973085: pyrandom2: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.8" returned exit code 13

[Juhani Numminen]

Fedora have decided to disable the failing part of that test.[1]
Python docs for the tested function now state "Changed in version 3.9:
This method now accepts zero for k."[2]

[1] 
https://src.fedoraproject.org/rpms/python-random2/blob/master/f/python-random2.spec#_39
[2] https://docs.python.org/3/library/random.html#random.getrandbits

Bug#973906: gevent-websocket's autopkg tests fail

[Matthias Klose]

Package: src:gevent-websocket
Version: 0.10.1-3
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.9

gevent-websocket's autopkg tests fail:

[...]
autopkgtest [12:02:51]: test command1: python3 -c "import geventwebsocket"
autopkgtest [12:02:51]: test command1: [---
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
autopkgtest [12:02:51]: test command1: ---]
command1 FAIL stderr: :219:
RuntimeWarning: greenlet.greenlet size changed, may indicate binary
incompatibility. Expected 144 from C header, got 152 from PyObject
autopkgtest [12:02:52]: test command1:  - - - - - - - - - - results - - - - - -
- - - -
autopkgtest [12:02:52]: test command1:  - - - - - - - - - - stderr - - - - - - -
- - -
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
:219: RuntimeWarning: greenlet.greenlet size
changed, may indicate binary incompatibility. Expected 144 from C header, got
152 from PyObject
autopkgtest [12:02:52]:  summary
command1 FAIL stderr: :219:
RuntimeWarning: greenlet.greenlet size changed, may indicate binary
incompatibility. Expected 144 from C header, got 152 from PyObject

Bug#973905: python-typing-inspect's autopkg test fails

[Matthias Klose]

Package: src:python-typing-inspect
Version: 0.6.0-1
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.9

python-typing-inspect's autopkg test fails:

autopkgtest [14:48:01]: test unittests: [---
=== python3.9 ===
/tmp/autopkgtest-lxc.bhraj9yn/downtmp/build.0gO/src/debian/tests/unittests: 11:
python3.9: not found
autopkgtest [14:48:01]: test unittests: ---]
autopkgtest [14:48:01]: test unittests:  - - - - - - - - - - results - - - - - -
- - - -
unittestsFAIL non-zero exit status 127
autopkgtest [14:48:01]:  summary
unittestsFAIL non-zero exit status 127

Bug#954170: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)

[Andreas Tille]

Dear Diane,
On Fri, Nov 06, 2020 at 02:20:59PM -0800, Diane Trout wrote:
> 
> I pushed the patches...

Thanks a lot.

> Is there anything else anyone wants to do to
> the package or should I submit to NEW?

Considering your involvement I think it would be appropriate
if you would upload to NEW.  (Steffen asked me for peer-review
sponsoring but I did nearly nothing on that package.)

Thanks a lot

 Andreas. 

-- 
http://fam-tille.de

Bug#959815: Implemented

[Jelmer Vernooij]

This is now implemented in the 'deb-scrub-obsolete' command that is
shipped with lintian-brush. By default, it will remove obsolete
maintscripts entries and versioned depends that were unncessary
since oldstable.

I'm considering whether it would be possible to run this as part
of lintian-brush as well, so I'm keeping this bug open for now.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#973270: RFP: qmidiplayer -- feature-rich Qt5 MIDI player

[Wang Gary]

Some additional information that may useful:

Upstream Author : Chris Xiong
Programming Lang: C++ / Qt

The upstream author also has a GitHub mirror [1] for the
project, and also accepts GitHub Issues and Pull Requests
from their GitHub repository. Although I'm not the project
maintainer, I could still help in building the project from
source if needed :)

[1]: https://github.com/chirs241097/QMidiPlayer

Bug#726741: distro-info: Support Ubuntu's devel alias

[stefanor]

Hi Paride (2020.11.05_18:39:08_+)
> This now works:
> 
> $ ubuntu-distro-info --devel
> hirsute

That always worked. The bug is about supporting
$ ubuntu-distro-info --series=devel

> Is it what this bug report was requesting? The bug is >7 years old so I
> wouldn't be surprised if a devel alias got added in the meantime :)

Naah, not much development has happened on these packages in that time.
Once the itch was scratched it went into maintenance...

SR

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

Bug#972861: emacs: please make the generated .el files reproducible

[Rob Browning]

"Chris Lamb"  writes:

> Hi Emacs maintainers,
>
>> emacs: please make the generated .el files reproducible
>
> Would it be possible to apply this patch or otherwise address this
> issue? Since filing this bug I can count 160+ packages that are now
> unreproducible in unstable due to this. Thanks for considering.

Apologies for the slow response, and I'll try to take a look this
weekend.  Happy to help sort it out.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#973904: src:distro-info-data: Provide http interface to distro-info-data

[Stefano Rivera]

Package: src:distro-info-data
Severity: normal

People have been scraping the distro-info-data data from Salsa, which
has caused abuse concerns for Salsa admins. Some known scrapers have
been blocked.

A search of GitHub shows many repos that reference this data:
https://github.com/search?p=3=%22https%3A%2F%2Fsalsa.debian.org%2Fdebian%2Fdistro-info-data%22=Code

Other known bugs:

https://github.com/hobbyquaker/check_os_release/issues/2

We should probably provide this data on a public http interface.

GitHub pages on salsa would probably be the simplest solution for now.
The URLs wouldn't be pretty, though.

SR

Bug#962921: apticron: Use of tempfile(1) produces a warning message

[Rick Thomas]

Package: apticron
Version: 1.2.3+nmu1
Followup-For: Bug #962921

Dear Maintainer,

This produces an email every time apticron runs.  Not useful.  Thanks for your 
attention!
Rick

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

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

Versions of packages apticron depends on:
ii  apt 2.1.11
ii  bzip2   1.0.8-4
ii  cron [cron-daemon]  3.0pl1-136
ii  dpkg1.20.5
ii  mailutils [mailx]   1:3.10-3
ii  ucf 3.0043

Versions of packages apticron recommends:
ii  apt-listchanges  3.22
ii  gpg  2.2.20-1
ii  iproute2 5.9.0-1

apticron suggests no packages.

-- no debconf information

Bug#940361: RFA: golang-github-gobwas-glob

[Anthony Fok]

Control: retitle -1 ITA: golang-github-gobwas-glob

Hi Alexandre,

I intend to adopt this package because its binary
golang-github-gobwas-glob-dev is needed by Hugo the static website
generator.

Thank you for your great work in maintaining this package!

Cheers,

Anthony

Bug#973894: rr: Improve reproducibility

[Bernhard Übelacker]

Package: rr
Version: 5.4.0-1
Severity: wishlist


Dear Maintainer,
I came to the reproducible build page [1] and saw
latest version was not reproducible.

I guess attached patch would at least remove the embedded
build path from the files, which is mentioned in [2] too.
Maybe that is already enough.

Kind regards,
Bernhard

[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rr.html
[2] 
https://salsa.debian.org/reproducible-builds/reproducible-notes/-/commit/925d9e5f6


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 rr depends on:
ii  libc6   2.31-4
ii  libc6-i386  2.31-4
ii  libcapnp-0.7.0  0.7.0-7
ii  libgcc-s1   10.2.0-16
ii  libstdc++6  10.2.0-16
ii  python3 3.8.2-3
Description: Remove embedded build paths

Author: Bernhard Übelacker 
Forwarded: no
Last-Update: 2020-11-06

Index: rr-5.4.0/CMakeLists.txt
===
--- rr-5.4.0.orig/CMakeLists.txt
+++ rr-5.4.0/CMakeLists.txt
@@ -81,7 +81,7 @@ endif()
 # Base settings for debug and release/unspecified builds.
 # Use -Werror for debug builds because we assume a developer is building, not a user.
 set(RR_FLAGS_DEBUG "-Wall -Wextra -DDEBUG -UNDEBUG")
-set(RR_FLAGS_RELEASE "-Wall -Wextra -UDEBUG -DNDEBUG")
+set(RR_FLAGS_RELEASE "-Wall -Wextra -UDEBUG -DNDEBUG -ffile-prefix-map=${CMAKE_SOURCE_DIR}=. -Wa,--debug-prefix-map,${CMAKE_SOURCE_DIR}=.")
 
 # The folowing settings are the defaults for the OTHER build type.
 # Flags used to build the preload library. MUST have debuginfo enabled. SHOULD be optimized.

Bug#973902: RFS: btrfs-progs/5.9-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my continuing backports of "btrfs-progs":

 * Package name: btrfs-progs
   Version : 5.9-1~bpo10+1
   Upstream Author : linux-bt...@vger.kernel.org
 * URL : http://btrfs.wiki.kernel.org/
 * License : GPL-2, TLP-4
 * Vcs : https://salsa.debian.org/debian/btrfs-progs/tree/debian
   Section : admin

It builds those binary packages:

  btrfs-progs - Checksumming Copy on Write Filesystem utilities
  libbtrfs0 - Checksumming Copy on Write Filesystem utilities (runtime library)
  libbtrfs-dev - Checksumming Copy on Write Filesystem utilities (development 
headers)
  libbtrfsutil1 - Checksumming Copy on Write Filesystem utilities (runtime util 
library)
  libbtrfsutil-dev - Checksumming Copy on Write Filesystem utilities (util 
development headers)
  python3-btrfsutil - Checksumming Copy on Write Filesystem utilities (python3 
bindings)
  btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb)

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

  https://mentors.debian.net/package/btrfs-progs/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_5.9-1~bpo10+1.dsc

Changes since the last upload:

 btrfs-progs (5.9-1~bpo10+1) buster-backports; urgency=medium
 .
   * Rebuild for buster-backports.
 .
 btrfs-progs (5.9-1) unstable; urgency=medium
 .
   * New upstream release.

Regards,
Nicholas

Bug#973901: RFS: vorta/0.7.1-1 [ITP] -- Desktop Client for Borg Backup

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vorta", a user-friendly
desktop client for Borg Backup.  Three systems I support are already
using this package to remind the user to do a backup, and to do it.
Two are using a NAS, one is using a USB drive.  It works great.:

 * Package name: vorta
   Version : 0.7.1-1
   Upstream Author : Manuel Riel 
 * URL : https://vorta.borgbase.com
 * License : GPL-3+, CC0-1.0
 * Vcs : https://salsa.debian.org/debian/vorta
   Section : utils

It builds those binary packages:

  vorta - Desktop Client for Borg Backup

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vorta/vorta_0.7.1-1.dsc

Changes for the initial release:

 vorta (0.7.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #922961).


Regards,
Nicholas

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

[Felix Lechner]

Hi Pierre-Elliott,

On Fri, Nov 6, 2020 at 2:59 PM Pierre-Elliott Bécue  wrote:
>
> The infrastructure is just a
> machine and I don't see how it could perform poorly except if it lacks
> physical resources.

That is a misperception. I cannot comment in detail due to allegiance
and gratitude to all the people (and especially past maintainers) who
devoted time and resources to Lintian over 22 years. Please let me
just say that Lintian's pieces no longer worked well together.

The software was the issue. The solution required an upgrade in
hardware infrastructure, which DSA would not discuss without a working
prototype.

As far as I am concerned, I am merely implementing ideas other
maintainers would have tried with more time. The idea of a PostgreSQL
database, for example (which possibly prompted your reaction to this
bug) was not new and predated my arrival. [1]

Like everyone else, I simply have Lintian for a little while and hope
to leave it, one day, in better shape than when it found me. One
cannot spend so much time with a single piece of software without
being profoundly in love with its mission and total belief in the
value it provides for fellow maintainers.

That being said, Lintian users hail from all parts of the Debian
universe. As you probably appreciate from your work on the community
team, not all interactions are positive. I usually do not work on
Lintian for a few days afterwards. I am sorry to count our
correspondence today among those experiences.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776658#40

> I'll be blunt, but you should really review the way you interact with
> people if you see manipulation or aggression in a question raised along
> with concerns. As I see it, your reaction is as much inappropriate as
> you claim my message is.

Obviously, we both perceive the other as passive-aggressive. The
burden of proof, however, rests with you. You wrote to me without
solicitation. Without going in circles, it's best to agree to disagree
here.

> When someone comes and say "It feels to me that you could have the
> intent to move the *production* lintian site out of Debian's machines.",
> which is voluntarily written as hypotheticall, it means that one wonders
> if it is your intention, and, indeed, to avoid accusation, it is turned
> as an hypothesis.

You explained to me what you thought my intentions were. I did the same for you.

> Feeling attacked by someone asking if you intend to do something and if
> so, that they think it could be a bad idea is something that prompts me
> to tell you, as you do downwards, /please get some rest/.

As a strictly religious person, I will, Thanks!

> And it's easy to say why and how someone could see "moving part of an
> infra outside Debian" as a bug. I'm fine with asking it here, but if you
> feel like there'd be a better place, please do tell and I'll be glad to
> forward our discussion there.

No thanks. I think there is too much discussion at Debian already.

> You seem (to me) reluctant to engage with criticism in that very case: I
> came with a simple question and you actually jumped at me, telling that
> I was forcing you to do something and intimidating you. That is not fine
> at all.

My perception is a product of the interaction between both of us. It
is presumptive and biased to blame my side entirely for the effects of
your communication.

> Furthermore, I did not tell that any of your contributions to Lintian
> were bad, but I do tell that if you were willing to have, on the long
> run, the *production* lintian website hosted outside of the Debian
> infrastructure, then I think it would be a bad decision.

I agree with you and hope that insight will motivate DSA to engage in
a positive and constructive way.

> Feel free to ignore me then, but I'm pretty convinced this discussion is
> useful, as I'm clearly trying to understand your thoughts and vision for
> lintian (the tool and the website), which are not written anywhere I
> could find (maybe I did missearch).

I am definitely not ignoring you.

> Yes I did. Assuming one's intentions is not being coercitive, and having
> that person implying that I am trying to coerce them is their own
> interpretation, and scary, because nothing in my message could imply
> that I want to force you doing anything.

I just searched the text in this bug to make sure: I did not allege
that you coerced anyone. You wrote that. I said you are "projecting",
which also happened here. You again claimed I did something that, in
reality, you did. As you saw in the rest of our correspondence, it
makes arguments circular.

The rhetorical question about an offer I could not refuse was a movie quote.

> It's your interpretation, and it is completely wrong. And "lintian is
> linked to core elements and should stay in Debian's infrastructure" is a
> technical point.

You just picked this up out of the blue? Or are other people
complaining behind you?

> This bug is about the website, which is not 

Bug#960158: libemail-mime-contenttype-perl: denial-of-service via OOM

[perl email user]

gregor herrmann  wrote:
> On Sun, 10 May 2020 02:25:42 +, perl email user wrote:
> 
> > It's possible to easily craft a message which triggers
> > out-of-memory error.
> > 
> > Upstream has been notified and working on the issue.
> 
> Mhm. Not a lot of information in this bug report :)

Sorry, I didn't want to provide info that could be used to
aid attackers.

Upstream and secur...@debian.org are aware of the problem
but have not yet acted.

If you have access to secur...@debian.org archives, see
<20201025102450.byceuhbphom4gnkj@pali> for fix + discussion.

> Anyway, 1.024-1 has been uploaded. Do you happen to know if this
> changes anything?

Nope.  Fwiw, I'm burned out from life + pandemic and
p...@cpan.org has been trying to work with upstream on this.

Anyways thanks for your response and all you do for Debian!

Bug#973900: autotools-dev: Move config.guess/config.sub to /usr/bin

[Ben Elliston]

Package: autotools-dev
Severity: wishlist

Dear Maintainer,

Given that these scripts are often used by system users, these scripts
should be somewhere found on the $PATH. I propose /usr/bin as a reasonable
place to put them.

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-9-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_US:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#960158: libemail-mime-contenttype-perl: denial-of-service via OOM

[gregor herrmann]

On Sun, 10 May 2020 02:25:42 +, perl email user wrote:

> It's possible to easily craft a message which triggers
> out-of-memory error.
> 
> Upstream has been notified and working on the issue.

Mhm. Not a lot of information in this bug report :)

Anyway, 1.024-1 has been uploaded. Do you happen to know if this
changes anything?

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Carole King: I Feel The Earth Move


signature.asc
Description: Digital Signature

Bug#973899: autotools-dev: Package config.guess/config.sub man pages

[Ben Elliston]

Package: autotools-dev
Severity: normal

Dear Maintainer,

The upstream config.guess/sub repository includes manual pages. These should be 
included
in the Debian autotools-dev package for completeness.


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-9-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_US:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#973897: Tests fail in autopkgtest environment: NameError: uninitialized constant Minitest::Test::Ahoy

[Daniel Leidert]

Package: ruby-ahoy-email
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The tests fail in autopkgtest. The error reported is constantly

NameError: uninitialized constant Minitest::Test::Ahoy

Regards, Daniel


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

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

Versions of packages ruby-ahoy-email depends on:
hi  bundler2.1.4-2
ii  ruby-actionmailer  2:6.0.3.4+dfsg-1
ii  ruby-activerecord  2:6.0.3.4+dfsg-1
ii  ruby-addressable   2.7.0-1
ii  ruby-minitest  5.13.0-1
ii  ruby-nokogiri  1.10.9+dfsg-1+b1
ii  ruby-railties  2:6.0.3.4+dfsg-1
pn  ruby-safely-block  

ruby-ahoy-email recommends no packages.

ruby-ahoy-email suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl+l7IYACgkQS80FZ8KW
0F29eg/6A5p1SEEJuKRwT58GOJXQBIPKpLEOWEaca+PXQ/Cl3JgkojK6Sq+75Z0t
N9KzDDjBrRHqtSfMk8WmOjkpOukfrNBmjTxm9ozfMQuApt4Ym4/ul827LceGFOVp
+xJXdDXgGgFvoku3CTP10WXwH99f0GbNxcCNEUuSa5ZQ1Y/hKe2blX6U8mu8bgdC
+T8fJb68I7IYhRiJoFlkoa90Q5dYkyAktLhScTyt/e/l1nCiyOAUjFYTUmdTSUNF
YZHPEOhOb9lhhppGdIkKjDCw1oji8JTMCBwXCOzpFcgX8cZd6xw6ngiH4MRZSMrl
xgPid7CJmKuRVd1gRQrd3mb+Qg1d11RD+1Rpkh5L+fQsxdVcANdhOK3wKVGo93uV
9yZeciulyu/WYkCBQ3y5YTToCmJcfM49PRZSGl/hLX29b/l0/1LEp+6UayHi1VZk
Vdz17NU9bQ78r/x+FR051ZPfRwdu1ck6kFhbLTp1mrTWKl8LJmnN1BmNm8E1gvXs
8Loe+9ALxHG+q4tbDbMLxpOZciJv266kByoSyMLG8YWaToRYCvoD2i9tTEFEbNXh
HjFNTyiffBHDGT3A0Q+aa4ZG+nnIH1LnXHUZboEO9Y3mhRW4VeejFoZmxDCUGVb8
tnwmaEQEd7CG+MRjcEZ3e1xbKRCIXSBx9VKtnFoJt9GPfaFBRqg=
=h/oE
-END PGP SIGNATURE-

Bug#973898: add appropriate header to patches not forwarded upstream that are not upstreamable

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.84
Severity: wishlist

Related lintian tag: patch-not-forwarded-upstream

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 lintian-brush depends on:
ii  devscripts   2.20.4
ii  python3  3.8.6-1
ii  python3-breezy   3.1.0-5
ii  python3-debian   0.1.38
ii  python3-debmutate0.12
ii  python3-distro-info  0.24
ii  python3-dulwich  0.20.8-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.12-2

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.4-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.20-1
ii  libdebhelper-perl13.2.1
ii  lintian  2.100.0
ii  python3-asyncpg  0.21.0-1+b1
ii  python3-bs4  4.9.3-1
ii  python3-levenshtein  0.12.0-5+b2
ii  python3-pyinotify0.9.6-1.3
ii  python3-toml 0.10.1-1

Versions of packages lintian-brush suggests:
pn  breezy-debian  
pn  gnome-pkg-tools
ii  po-debconf 1.0.21
ii  postgresql-common  222

-- no debconf information

Bug#973896: dgit: Document practical effects of --damp-run writing tags

[Ian Jackson]

Wookey writes ("Bug#973896: dgit: Document practical effects of --damp-run 
writing tags"):
> Using --damp-run with push (to check it will work) writes the local
> tag for the current version, but does not update the server.

I wonder if it would be better to discourage using --damp-run, or
rather, to encourage people to just go ahead without it.  dgit is
chock full of safety catches and checks and stuff precisely to try to
help its user avoid making messes.

I think people use --damp-run because they are scared that "something
will go wrong" and make a mess.  But dgit very rarely makes any kind
of public mess of the kind that --damp-run would avoid.  I'm not sure
I can remember an occasion when it has done (although I'm a bit
sozzled now so I can't be sure).

The thing you are documenting here is only one of --damp-run's rather
strange aspects.  Eg it can fail when a plain dgit push would have
succeeded.  It's mostly provided for debugging etc., not as a primary
tool for helping user confidence.

If we wanted a thing that helped build user confidence, maybe that
should be something else.

If someone has used --damp-run on a real package, I think it would be
better for them to burn the vwrsion number, than to pass a force
option.  Eg., what if one of the unsigned tags escaped somewhere ?

Alternativley if we want to make --damp-run into a proper thing for
this use case, we should make it work properly: eg, we could have the
subsequent push notice that the tags were unsigned and decide to be
happy to replace them with signed tags provided they referred to the
same commits.  And maybe fix the other issues with --damp-run.  But
the latter might be hard; I would have to UTSL to check for them.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#973896: dgit: Document practical effects of --damp-run writing tags

[Wookey]

Source: dgit
Version: 9.12
Severity: normal
Tags: patch

Using --damp-run with push (to check it will work) writes the local
tag for the current version, but does not update the server.

A subsequent push will fail, because dgit assumes that tag-creation
and pushing to the dgit server is an atomic operation, so interprets
this as a previous push failing. It would be nice if it checked for
this case and just pushed so things get back in sync, but in the
meantime, or if that remains too hard, documenting this foible in the
man page would be helpful.

Attached is a patch for the --damp-run option so that it now says:
 Go through many more of the motions: do everything that doesn't
 involve either signing things, or making changes on the public
 servers. Note that when used with push this writes local tags but 
 not remote ones, which breaks dgit's assumptions about atomic operations, 
 so a subsequent dgit push will need --force-reusing-version to succeed.

It would probably be good to note this usage under --force-reusing-version too

Something like this:
--force-reusing-version
  Carry on even though this involves reusing a version
  number of a previous push or upload.  It is normally
  best to give different versions different
  numbers. However if --damp-run was used with push on
  this version then this option is appropriate to sync the
  local version with the dgit server.  Some servers
  (including, usually, the Debian server) will reject
  attempts to reuse or replace already-pushed versions.

(this latter change not in the patch)

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- dgit.1~ 2020-08-19 16:25:45.0 +
+++ dgit.1  2020-11-06 23:44:48.260816780 +
@@ -504,7 +504,9 @@
 .BR \-\-damp-run " | " \-L
 Go through many more of the motions: do everything that doesn't
 involve either signing things, or making changes on the public
-servers.
+servers. Note that when used with push this writes local tags but 
+not remote ones, which breaks dgit's assumptions about atomic operations, 
+so a subsequent dgit push will need --force-reusing-version to succeed.
 .TP
 .BI \-k keyid
 Use

Bug#973895: clementine: please, don't spam the output with debug info

[Rogério Brito]

Package: clementine
Version: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1
Severity: normal

First of all, thank you for packaging Clementine.

Now, to the proper report: please, make Clementine default to the --quiet
level, since, otherwise, it generates a lot of output info on the console.

Actually, even if you select --quiet, it still produces much more output
than a Unix user would ever expect it to produce.

When needed, users can select some higher level of output to report bugs.
Otherwise, one can end up with an ~/.xsession-errors file that is way too
large for useless reasons.


Thanks in advance,

Rogério Brito.


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.18.1-1
ii  gstreamer1.0-plugins-good   1.18.1-1
ii  gstreamer1.0-plugins-ugly   1.18.1-1
ii  libasound2  1.2.3.2-1
ii  libc6   2.31-4
ii  libcdio19   2.1.0-2
ii  libchromaprint1 1.5.0-1
ii  libcrypto++65.6.4-10
ii  libfftw3-double33.3.8-2
ii  libgcc-s1   10.2.0-15
ii  libglib2.0-02.66.2-1
ii  libgpod40.8.3-15
ii  libgstreamer-plugins-base1.0-0  1.18.1-1
ii  libgstreamer1.0-0   1.18.1-1
ii  libimobiledevice6   1.3.0-5
ii  liblastfm5-11.0.9-1.1
ii  libmtp9 1.1.17-3
ii  libmygpo-qt5-1  1.1.0-4
ii  libprotobuf23   3.12.3-2+b1
ii  libpulse0   13.0-5
ii  libqt5concurrent5   5.15.1+dfsg-2
ii  libqt5core5a5.15.1+dfsg-2
ii  libqt5dbus5 5.15.1+dfsg-2
ii  libqt5gui5  5.15.1+dfsg-2
ii  libqt5network5  5.15.1+dfsg-2
ii  libqt5sql5  5.15.1+dfsg-2
ii  libqt5widgets5  5.15.1+dfsg-2
ii  libqt5x11extras55.15.1-2
ii  libsqlite3-03.33.0-1
ii  libstdc++6  10.2.0-15
ii  libtag1v5   1.11.1+dfsg.1-3
ii  libx11-62:1.6.12-1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages clementine recommends:
ii  gstreamer1.0-alsa1.18.1-1
ii  gstreamer1.0-pulseaudio  1.18.1-1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.18.0-2+b1

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#963509: prospector: Version 1.3.1 now available

[Rogério Brito]

Package: prospector
Version: 1.1.7-2
Followup-For: Bug #963509
X-Debbugs-Cc: team+pyt...@tracker.debian.org, locutusofb...@debian.org, 
mat...@debian.org, czc...@debian.org

Hi.

There is a new version of prospector upstream at

https://pypi.org/project/prospector/

that is supposed to fix all the problems that are currently in debian (read:
prospector doesn't work at all).

I'm including in the CC some of the people that last touched the package (at
least according to changelog.Debian.gz in my system). If anybody could fix
it, that would be awesome.


Thanks,

Rogério Brito.

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages prospector depends on:
ii  dodgy  0.1.9-3
ii  libjs-sphinxdoc3.2.1-2
ii  pylint 2.6.0-1
ii  python33.8.2-3
ii  python3-astroid2.4.2-1
ii  python3-mccabe 0.6.1-3
ii  python3-mypy   0.790-2
ii  python3-pep8-naming0.10.0-1
ii  python3-pycodestyle2.6.0-1
ii  python3-pydocstyle 2.1.1-1
ii  python3-pyflakes   2.2.0-1
ii  python3-pylint-celery  0.3-5
ii  python3-pylint-django  2.0.13-1
ii  python3-pylint-flask   0.5-4
ii  python3-pylint-plugin-utils0.6-1
ii  python3-pyroma 2.6b2-1
ii  python3-requirements-detector  0.6-2
ii  python3-setoptconf 0.2.0-5
ii  python3-typed-ast  1.4.1-1+b2
ii  python3-yaml   5.3.1-3

Versions of packages prospector recommends:
ii  vulture  2.1-1

prospector suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

[Pierre-Elliott Bécue]

Hi Felix,

Le vendredi 06 novembre 2020 à 14:01:22-0800, Felix Lechner a écrit :
> Hi Pierre-Elliott,
> 
> On Fri, Nov 6, 2020 at 5:20 AM Pierre-Elliott Bécue  wrote:
> >
> > A technical project consisting of people who may have opinions, even
> > some based on non-very-technical aspects.
> 
> There are no "non-technical" aspects in my effort to provide the best
> possible service, aside from being a nice person, despite your
> tendency to insert them. This is a bug report.

In my opinion (and I failed to find any Debian resource telling
otherwise), a bug report does not necessarily have to stick to technical
aspects, and is a perfectly valid place to raise such questions. I
thought it'd be better than redirecting this matter on debian-devel or
other without prior discussion, especially to avoid involving a load of
people which would indeed have been aggressive.

> > Because I made an assumption on your intents and tried to tell you
> > something you don't want to hear, which is that it should stay in Debian
> > infra?
> 
> The solution provided on the current Debian infrastructure has
> performed poorly for a long time (and well before my arrival).

The lintian.debian.org website, probably. The infrastructure is just a
machine and I don't see how it could perform poorly except if it lacks
physical resources.

> There is nothing untoward about my intentions. The prominence of your
> suspicions in your reasoning cannot change it. You are either being
> manipulative, or you are trying to provoke a reaction. Either way,
> your accusations have no basis.

I'll be blunt, but you should really review the way you interact with
people if you see manipulation or aggression in a question raised along
with concerns. As I see it, your reaction is as much inappropriate as
you claim my message is.

When someone comes and say "It feels to me that you could have the
intent to move the *production* lintian site out of Debian's machines.",
which is voluntarily written as hypotheticall, it means that one wonders
if it is your intention, and, indeed, to avoid accusation, it is turned
as an hypothesis.

Feeling attacked by someone asking if you intend to do something and if
so, that they think it could be a bad idea is something that prompts me
to tell you, as you do downwards, /please get some rest/.

> 
> > Come on, you should accept the idea that other people has
> > different opinions than yours and have a right to state these. The
> > "it's not technical" argument is not a valid answer.
> 
> Again, this is a bug report. Please be your own judge.

And it's easy to say why and how someone could see "moving part of an
infra outside Debian" as a bug. I'm fine with asking it here, but if you
feel like there'd be a better place, please do tell and I'll be glad to
forward our discussion there.

> > The fact that you are working on a
> > project does not mean others can't express concerns and raise their
> > voice if they think the decisions you seem to be willing to take are
> > bad.
> 
> Please explain which of my contributions to Lintian are "bad". I
> regularly reverse changes that did not deliver the expected benefits.
> Many of Lintian's bug reports are also about changes I made that did
> not work. To the best of my ability, I respond timely. I challenge you
> to prove otherwise. Your suggestion that I am reluctant to engage with
> criticism is unsupported and faise.

You seem (to me) reluctant to engage with criticism in that very case: I
came with a simple question and you actually jumped at me, telling that
I was forcing you to do something and intimidating you. That is not fine
at all.

Furthermore, I did not tell that any of your contributions to Lintian
were bad, but I do tell that if you were willing to have, on the long
run, the *production* lintian website hosted outside of the Debian
infrastructure, then I think it would be a bad decision. I may be wrong,
but that is what I think.

> My point is further bolstered by this letter. Its writing consumed
> valuable time and kept me from contributing in other and probably more
> productive ways.

Feel free to ignore me then, but I'm pretty convinced this discussion is
useful, as I'm clearly trying to understand your thoughts and vision for
lintian (the tool and the website), which are not written anywhere I
could find (maybe I did missearch).

> > I'm not coercing you and the way you represent it is your sole
> > interpretation, which is a bit scary.
> 
> You yourself wrote that you made assumptions about my intentions.

Yes I did. Assuming one's intentions is not being coercitive, and having
that person implying that I am trying to coerce them is their own
interpretation, and scary, because nothing in my message could imply
that I want to force you doing anything. And as I don't, I'd rather you
to avoid telling that.

> (You offer no details, but they are presumably unbecoming.) Plus, you
> raise no technical points. Like it or not, the effect of your messages
> is 

Bug#954170: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)

[Diane Trout]

On Fri, 2020-11-06 at 08:23 +0100, Andreas Tille wrote:
> Dear Diane,
> 
> would you mind pushing your patch to the Git repository?  I mean its
> your ITP and you are Uploader - so I hesitate to push your very own
> patch on behalf of you. ;-)
> 
> Thanks a lot for your helpful hints and contacting upstream


I pushed the patches... Is there anything else anyone wants to do to
the package or should I submit to NEW?

Bug#973893: Traducción: es_AR: Preferencias: "Bloquear ventanas emergentesu"

[rv]

Package: epiphany-browser
Version: 3.38.1-1
Severity: minor
X-Debbugs-Cc: riveravaldezm...@gmail.com

Hi, dear Maintainer,

there's a misspelled word in this Spanish translation:

Preferencias: General: "Bloquear ventanas emergentesu"

That las 'u' shouldn't be there.

Best regards!



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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages epiphany-browser depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  epiphany-browser-data 3.38.1-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  iso-codes 4.5.0-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-8
ii  libcairo2 1.16.0-4
ii  libdazzle-1.0-0   3.38.0-1
ii  libgcr-base-3-1   3.38.0-1
ii  libgcr-ui-3-1 3.38.0-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libglib2.0-0  2.66.2-1
ii  libgmp10  2:6.2.0+dfsg-6
ii  libgtk-3-03.24.23-2
ii  libhandy-1-0  1.0.1-1
ii  libhogweed6   3.6-2
ii  libjavascriptcoregtk-4.0-18   2.30.1-1
ii  libjson-glib-1.0-01.6.0-1
ii  libnettle83.6-2
ii  libpango-1.0-01.46.2-2
ii  libsecret-1-0 0.20.3-1
ii  libsoup2.4-1  2.72.0-2
ii  libsqlite3-0  3.33.0-1
ii  libwebkit2gtk-4.0-37  2.30.1-1
ii  libxml2   2.9.10+dfsg-6.1

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20200601
pn  evince   
ii  yelp 3.38.1-1

epiphany-browser suggests no packages.

-- no debconf information

Bug#973880: krb5: CVE-2020-28196

[Sam Hartman]

Thanks for the note.  I've been meaning to do a much needed krb5 update
and this definitely pushes it up the priority stack.
I'll work on this over the weekend.

Bug#964195: guacamole-client: CVE-2020-9497 and CVE-2020-9498

[Markus Koschany]

Control: tags -1 patch


Hi,

I'm attaching my patch for Stretch to this bug report. Since the 
versions in Stretch and unstable are identical, it should work there 
too. However I don't intend to NMU guacamole-server because I believe a 
new upstream version should be packaged instead.


Regards,

Markus
diff -Nru 
guacamole-server-0.9.9/debian/patches/CVE-2020-9497-and-CVE-2020-9498.patch 
guacamole-server-0.9.9/debian/patches/CVE-2020-9497-and-CVE-2020-9498.patch
--- guacamole-server-0.9.9/debian/patches/CVE-2020-9497-and-CVE-2020-9498.patch 
1970-01-01 01:00:00.0 +0100
+++ guacamole-server-0.9.9/debian/patches/CVE-2020-9497-and-CVE-2020-9498.patch 
2020-11-06 22:44:56.0 +0100
@@ -0,0 +1,355 @@
+From: Markus Koschany 
+Date: Tue, 3 Nov 2020 13:45:20 +0100
+Subject: CVE-2020-9497 and CVE-2020-9498
+
+Bug-Debian: https://bugs.debian.org/964195
+Origin: 
https://github.com/apache/guacamole-server/commit/a0e11dc81727528224d28466903454e1cb0266bb
+---
+ src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c   | 40 ++
+ .../rdp/guac_rdpdr/rdpdr_fs_messages_file_info.c   | 12 +++
+ src/protocols/rdp/guac_rdpdr/rdpdr_messages.c  | 18 ++
+ src/protocols/rdp/guac_rdpdr/rdpdr_printer.c   |  7 
+ src/protocols/rdp/guac_rdpdr/rdpdr_service.c   |  3 ++
+ src/protocols/rdp/guac_rdpsnd/rdpsnd_messages.c| 29 
+ src/protocols/rdp/guac_rdpsnd/rdpsnd_service.c |  5 +++
+ 7 files changed, 114 insertions(+)
+
+diff --git a/src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c 
b/src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c
+index bfd8ead..10d41bb 100644
+--- a/src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c
 b/src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c
+@@ -58,6 +58,10 @@ void guac_rdpdr_fs_process_create(guac_rdpdr_device* device,
+ int create_disposition, create_options, path_length;
+ char path[GUAC_RDP_FS_MAX_PATH];
+ 
++/* Check remaining stream data prior to reading. */
++if (Stream_GetRemainingLength(input_stream) < 32)
++return;
++
+ /* Read "create" information */
+ Stream_Read_UINT32(input_stream, desired_access);
+ Stream_Seek_UINT64(input_stream); /* allocation size */
+@@ -67,6 +71,11 @@ void guac_rdpdr_fs_process_create(guac_rdpdr_device* device,
+ Stream_Read_UINT32(input_stream, create_options);
+ Stream_Read_UINT32(input_stream, path_length);
+ 
++/* Check to make sure the stream contains path_length bytes. */
++if(Stream_GetRemainingLength(input_stream) < path_length) {
++return;
++}
++
+ /* Convert path to UTF-8 */
+ guac_rdp_utf16_to_utf8(Stream_Pointer(input_stream), path_length/2 - 1,
+ path, sizeof(path));
+@@ -133,6 +142,10 @@ void guac_rdpdr_fs_process_read(guac_rdpdr_device* device,
+ 
+ wStream* output_stream;
+ 
++/* Check remaining bytes before reading stream. */
++if (Stream_GetRemainingLength(input_stream) < 12)
++return;
++
+ /* Read packet */
+ Stream_Read_UINT32(input_stream, length);
+ Stream_Read_UINT64(input_stream, offset);
+@@ -181,6 +194,10 @@ void guac_rdpdr_fs_process_write(guac_rdpdr_device* 
device,
+ 
+ wStream* output_stream;
+ 
++/* Check remaining length. */
++if (Stream_GetRemainingLength(input_stream) < 32)
++return;
++
+ /* Read packet */
+ Stream_Read_UINT32(input_stream, length);
+ Stream_Read_UINT64(input_stream, offset);
+@@ -190,6 +207,11 @@ void guac_rdpdr_fs_process_write(guac_rdpdr_device* 
device,
+ "%s: [file_id=%i] length=%i, offset=%" PRIu64,
+  __func__, file_id, length, (uint64_t) offset);
+ 
++/* Check to make sure stream contains at least length bytes */
++if (Stream_GetRemainingLength(input_stream) < length) {
++return;
++}
++
+ /* Attempt write */
+ bytes_written = guac_rdp_fs_write((guac_rdp_fs*) device->data, file_id,
+ offset, Stream_Pointer(input_stream), length);
+@@ -252,6 +274,10 @@ void guac_rdpdr_fs_process_volume_info(guac_rdpdr_device* 
device, wStream* input
+ 
+ int fs_information_class;
+ 
++/* Check remaining length */
++if (Stream_GetRemainingLength(input_stream) < 4)
++return;
++
+ Stream_Read_UINT32(input_stream, fs_information_class);
+ 
+ /* Dispatch to appropriate class-specific handler */
+@@ -294,6 +320,10 @@ void guac_rdpdr_fs_process_file_info(guac_rdpdr_device* 
device, wStream* input_s
+ 
+ int fs_information_class;
+ 
++/* Check remaining length */
++if (Stream_GetRemainingLength(input_stream) < 4)
++return;
++
+ Stream_Read_UINT32(input_stream, fs_information_class);
+ 
+ /* Dispatch to appropriate class-specific handler */
+@@ -341,6 +371,10 @@ void 
guac_rdpdr_fs_process_set_file_info(guac_rdpdr_device* device,
+ int fs_information_class;
+ int length;
+ 
++/* Check remaining length */
++if (Stream_GetRemainingLength(input_stream) < 32)

Bug#973892: consul: CVE-2020-25201

[Salvatore Bonaccorso]

Source: consul
Version: 1.7.4+dfsg1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/hashicorp/consul/pull/9024
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for consul.

I'm not particularly familiar with consul, but just skimmed over the
current sources in unstable.

CVE-2020-25201[0]:
| HashiCorp Consul Enterprise version 1.7.0 up to 1.8.4 includes a
| namespace replication bug which can be triggered to cause denial of
| service via infinite Raft writes. Fixed in 1.7.9 and 1.8.5.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25201
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25201
[1] https://github.com/hashicorp/consul/pull/9024

Regards,
Salvatore

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

[Felix Lechner]

Hi Pierre-Elliott,

On Fri, Nov 6, 2020 at 5:20 AM Pierre-Elliott Bécue  wrote:
>
> A technical project consisting of people who may have opinions, even
> some based on non-very-technical aspects.

There are no "non-technical" aspects in my effort to provide the best
possible service, aside from being a nice person, despite your
tendency to insert them. This is a bug report.

> Because I made an assumption on your intents and tried to tell you
> something you don't want to hear, which is that it should stay in Debian
> infra?

The solution provided on the current Debian infrastructure has
performed poorly for a long time (and well before my arrival). There
is nothing untoward about my intentions. The prominence of your
suspicions in your reasoning cannot change it. You are either being
manipulative, or you are trying to provoke a reaction. Either way,
your accusations have no basis.

> Come on, you should accept the idea that other people has
> different opinions than yours and have a right to state these. The
> "it's not technical" argument is not a valid answer.

Again, this is a bug report. Please be your own judge.

> The fact that you are working on a
> project does not mean others can't express concerns and raise their
> voice if they think the decisions you seem to be willing to take are
> bad.

Please explain which of my contributions to Lintian are "bad". I
regularly reverse changes that did not deliver the expected benefits.
Many of Lintian's bug reports are also about changes I made that did
not work. To the best of my ability, I respond timely. I challenge you
to prove otherwise. Your suggestion that I am reluctant to engage with
criticism is unsupported and faise.

My point is further bolstered by this letter. Its writing consumed
valuable time and kept me from contributing in other and probably more
productive ways.

> I'm not coercing you and the way you represent it is your sole
> interpretation, which is a bit scary.

You yourself wrote that you made assumptions about my intentions. (You
offer no details, but they are presumably unbecoming.) Plus, you raise
no technical points. Like it or not, the effect of your messages is to
malign and intimidate.

> I don't have to mention technical concerns to have a right to feel
> ill-at-ease with the idea of seeing lintian.debian.org disappear in
> favour of an externally hosted service. But actually, "it's
> Debian-centric and used by core components, so it's better having it
> in our infrastructure" also is a technical concern.

I agree with you. Unfortunately, the infrastructure provided by DSA is
presently insufficient for the service people expect. (Just look at
this bug.) Your point is therefore hypothetical.

Eventually, I plan to approach DSA with a wishlist for deployment on
Debian hardware. As I stated previously, I am not ready because I am
still experimenting.

> This is what I call a test version.

What an odd point to make! In my first response to this bug, I called
it an experiment. The words mean the same thing.

> DSA delivers machines, what you do of these is your call. See
> nm.debian.org, which is auto-deployed when we release on master et al.

Thank you for your thoughtful reference. I previously watched Enrico's
talk [1] with great interest and also multiple times. Unfortunately,
the mechanism does not cover the automatic installation of runtime
prerequisites and is probably not helpful for Lintian (although it may
be for the website).

Please also keep in mind that the Lintian maintainers try to produce
data for lintian.d.o with released versions (for easier comparison
with the BTS). Upon reflection, Debian's packaging system is ideally
suited to solve those issues.

[1] https://debconf18.debconf.org/talks/71-autodeploy-from-salsa/

> Surely, that excludes tracker.debian.org, wiki.debian.org,
> nm.debian.org, ddpo.debian.org, udd.debian.org, …

All I can say is, it was the response I got.

> I can't see how and why DSA would forbid you to have a new website set
> in production on lintian.debian.org, and if they do, that's probably
> something worth a discussion on debian-devel to have things explained
> and understood, don't you think?

At this point, I do not think such a broad call for assistance is
necessary. It also would not be helpful for my negotiations. My
counterparties at DSA will assume that I tried to sidestep them. It
embarrasses them and violates their trust. It is an awful way to beg
for understanding and compromise. I hope you understand.

DSA will eventually have to engage in a conversation when I present a
viable alternative. (If not, I will ask for your help.) For the time
being, I am developing both websites in parallel. Most of my work has
gone to the static one. The dynamic website is not even up yet.

> Just because you feel hurt by the fact someone tries to tell you you
> should reconsider an idea doesn't mean their opinion or suggestion is
> moot. I'm sorry if you're feeling hurt, but I stand my 

Bug#973698: g++-10: regresson in 10.2.0-16: internal compiler error: in tsubst_decl, at cp/pt.c:14666

[Michael R. Crusoe]

Thanks for making the issue upstream with the minimal example!

I just built with gcc-snapshot 1:20201023-1 and now I get a build error:
https://github.com/seqan/seqan3/issues/2236#issuecomment-723232918


On Fri, 6 Nov 2020 at 17:13, Matthias Klose  wrote:

> Control: forwarded -1 https://gcc.gnu.org/PR97745
>
> please could you try to build the package with gcc-snapshot to see if you
> get an
> error?
>

Bug#973890: RM: tty-server/0.0~git20201105.50b9367+ds-1

[Francisco Vilmar Cardoso Ruviaro]

Hello Adam,

On 2020-11-06 21:38, Adam D. Barratt wrote:
> That will happen automatically once the package is removed from
> unstable.
> 

Ohh Sorry, I thought I should open a bug to remove from testing as well.

> Is there a reason that testing removal can't / shouldn't just wait for
> that?
> 

There is no reason, I can wait.

> Regards,

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

Bug#963320: libtgvoip: FTBFS: AttributeError: module 'string' has no attribute 'maketrans'

[Xavier]

Le 06/11/2020 à 22:23, Nicholas Guriev a écrit :
> On Fri, 2020-11-06 at 22:06 +0100, Xavier wrote:
>> sorry, I launched a full rebuild in unstable and didn't see this change.
>> However I don't understand this error (I'm not Python dev), code is:
>>
>>  try:
>>    # maketrans moved to str in python3.
>>    _maketrans = string.maketrans
>>  except NameError:
>>    _maketrans = str.maketrans
>>
>> So error should be discarded, isn't it?
> 
> It seems wrong exception is handled here. NameError[1] happens when
> unknown top-level variable is referenced. However, above this line,
> there is importing of string module. So NameError is not possible here.
> I daresay an original author meant AttributeError[2] here that is raised
> when code is trying to get non-existent attribute (a thing after dot).
> 
> I suggest replace NameError with AttributeError:
> 
>try:
>  # maketrans moved to str in python3.
>  _maketrans = string.maketrans
>except AttributeError:
>  _maketrans = str.maketrans
> 
> (not tested)

I tried but now I've a new error:

Traceback (most recent call last):
  File "/usr/bin/gyp", line 11, in 
load_entry_point('gyp==0.1', 'console_scripts', 'gyp')()
  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 552, in
script_main
return main(sys.argv[1:])
  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 545, in main
return gyp_main(args)
  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 530, in
gyp_main
generator.GenerateOutput(flat_list, targets, data, params)
  File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line
1238, in GenerateOutput
GenerateOutputForConfig(target_list, target_dicts, data,
  File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line
1194, in GenerateOutputForConfig
WriteTarget(namer, qualified_target, target_dicts, build_dir,
config_to_use,
  File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line
990, in WriteTarget
for xcode_setting, xcode_value in xcode_settings.viewitems():
AttributeError: 'dict' object has no attribute 'viewitems'

Bug#973889: raptor2: diff for NMU version 2.0.14-1.1

[Salvatore Bonaccorso]

Control: tags 973889 + patch
Control: tags 973889 + pending

Dear maintainer,

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

Regards,
Salvatore
diff -Nru raptor2-2.0.14/debian/changelog raptor2-2.0.14/debian/changelog
--- raptor2-2.0.14/debian/changelog	2014-05-05 20:15:34.0 +0200
+++ raptor2-2.0.14/debian/changelog	2020-11-06 22:08:54.0 +0100
@@ -1,3 +1,11 @@
+raptor2 (2.0.14-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Calcualte max nspace declarations correctly for XML writer
+(CVE-2017-18926) (Closes: #973889)
+
+ -- Salvatore Bonaccorso   Fri, 06 Nov 2020 22:08:54 +0100
+
 raptor2 (2.0.14-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru raptor2-2.0.14/debian/patches/Calcualte-max-nspace-declarations-correctly-for-XML-.patch raptor2-2.0.14/debian/patches/Calcualte-max-nspace-declarations-correctly-for-XML-.patch
--- raptor2-2.0.14/debian/patches/Calcualte-max-nspace-declarations-correctly-for-XML-.patch	1970-01-01 01:00:00.0 +0100
+++ raptor2-2.0.14/debian/patches/Calcualte-max-nspace-declarations-correctly-for-XML-.patch	2020-11-06 22:08:54.0 +0100
@@ -0,0 +1,45 @@
+From: Dave Beckett 
+Date: Sun, 16 Apr 2017 23:15:12 +0100
+Subject: Calcualte max nspace declarations correctly for XML writer
+Origin: https://github.com/dajobe/raptor/commit/590681e546cd9aa18d57dc2ea1858cb734a3863f
+Bug-Debian: https://bugs.debian.org/973889
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-18926
+
+(raptor_xml_writer_start_element_common): Calculate max including for
+each attribute a potential name and value.
+
+Fixes Issues #617 http://bugs.librdf.org/mantis/view.php?id=617
+and #618 http://bugs.librdf.org/mantis/view.php?id=618
+---
+ src/raptor_xml_writer.c | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/raptor_xml_writer.c b/src/raptor_xml_writer.c
+index 693b946863e6..0d3a36a5a21c 100644
+--- a/src/raptor_xml_writer.c
 b/src/raptor_xml_writer.c
+@@ -181,9 +181,10 @@ raptor_xml_writer_start_element_common(raptor_xml_writer* xml_writer,
+   size_t nspace_declarations_count = 0;  
+   unsigned int i;
+ 
+-  /* max is 1 per element and 1 for each attribute + size of declared */
+   if(nstack) {
+-int nspace_max_count = element->attribute_count+1;
++int nspace_max_count = element->attribute_count * 2; /* attr and value */
++if(element->name->nspace)
++  nspace_max_count++;
+ if(element->declared_nspaces)
+   nspace_max_count += raptor_sequence_size(element->declared_nspaces);
+ if(element->xml_language)
+@@ -237,7 +238,7 @@ raptor_xml_writer_start_element_common(raptor_xml_writer* xml_writer,
+ }
+   }
+ 
+-  /* Add the attribute + value */
++  /* Add the attribute's value */
+   nspace_declarations[nspace_declarations_count].declaration=
+ raptor_qname_format_as_xml(element->attributes[i],
+_declarations[nspace_declarations_count].length);
+-- 
+2.29.1
+
diff -Nru raptor2-2.0.14/debian/patches/series raptor2-2.0.14/debian/patches/series
--- raptor2-2.0.14/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ raptor2-2.0.14/debian/patches/series	2020-11-06 22:08:54.0 +0100
@@ -0,0 +1 @@
+Calcualte-max-nspace-declarations-correctly-for-XML-.patch


signature.asc
Description: PGP signature

Bug#973002: Any hint what needs to be done to finalize tensorflow?

[Andreas Tille]

On Thu, Nov 05, 2020 at 03:32:17AM +, Mo Zhou wrote:
> I'm not sure what packages are exactly missing from Debian, but this
> directory is worth being checked, I think:
> https://github.com/tensorflow/tensorflow/tree/master/third_party
> Some of them are meanwhile PyTorch dependencies, so this portion
> is supposed to be in a good shape.

Hmmm, that seems to be a lot.  Strangely enough if I try to build in
pbuilder it downloads several dependencies from the internet - except if
sitting behind a proxy that is unknown to the pbuilder environment.  I
have never observed this before - seems bazel knows "tricks" to
undermine the offlineish nature of the pbuilder environment.  I have
never seen this happening before.
 
> Besides, one of the most valuable reverse dependency of tensorflow is
> tensorboard (feel free to take over this ITP since I feel overloaded):
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973002

I've commited some initial packaging to Salsa[1].  It also needs
some third party software.  The first one is

  
http://mirror.tensorflow.org/github.com/bazelbuild/bazel-skylib/archive/0.7.0.tar.gz

I wonder whether all those dependencies are mandatory or whether
we might be able to exclude something optional.
 
> I'm not able to participate in TF maintenance, but I care about
> tensorboard because it can be used by PyTorch as well. Acceptance of
> tensorboard also unblocks the debianization of my favorate PyTorch
> abstraction layer "pytorch-lightning".

I could *help* with this - but I'm clearly neither qualified
nor does my time limit permit really focussing on this work.

Kind regards

   Andreas.

[1] https://salsa.debian.org/deeplearning-team/tensorboard

-- 
http://fam-tille.de

Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)

[Otto Kekäläinen]

Thanks!

I will update the changelog and upload current
https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/commits/debian/master
unless Boyuan or Jochen have something more to add/review about the packaging.

Bug#973890: RM: tty-server/0.0~git20201105.50b9367+ds-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Fri, 2020-11-06 at 21:26 +, Francisco Vilmar Cardoso Ruviaro
wrote:
> Please, remove the tty-server from testing because it was deprecated
> by tty-proxy.

That will happen automatically once the package is removed from
unstable.

Is there a reason that testing removal can't / shouldn't just wait for
that?

Regards,

Adam

Bug#973890: RM: tty-server/0.0~git20201105.50b9367+ds-1

[Francisco Vilmar Cardoso Ruviaro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Dear Release Team,

Please, remove the tty-server from testing because it was deprecated by 
tty-proxy.

[0]
https://github.com/elisescu/tty-server/blob/50b9367cd19c07017b9578adca5e8d15db2382b0/README.md
[1]
https://github.com/elisescu/tty-server/commit/50b9367cd19c07017b9578adca5e8d15db2382b0
[2]
https://github.com/elisescu/tty-share/blob/93cdfa0e887c210d097c891ffaaf5e3ccd8f35d8/doc/old-version.md
[3] https://github.com/elisescu/tty-proxy

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



signature.asc
Description: OpenPGP digital signature

Bug#973891: RM: tty-server -- ROM; no longer maintained

[Francisco Vilmar Cardoso Ruviaro]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

Please, remove the tty-server from unstable because it was deprecated by 
tty-proxy.

[0]
https://github.com/elisescu/tty-server/blob/50b9367cd19c07017b9578adca5e8d15db2382b0/README.md
[1]
https://github.com/elisescu/tty-server/commit/50b9367cd19c07017b9578adca5e8d15db2382b0
[2]
https://github.com/elisescu/tty-share/blob/93cdfa0e887c210d097c891ffaaf5e3ccd8f35d8/doc/old-version.md
[3] https://github.com/elisescu/tty-proxy

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



signature.asc
Description: OpenPGP digital signature

Bug#973492: abseil: Please consider explicitly enable -latomic with armel build

[Benjamin Barenblat]

On Tuesday, November  3, 2020, at 10:27 AM -0500, Benjamin Barenblat wrote:
> [...] the CMake support files that get installed with libabsl-dev should
> probably specify -latomic on armel [...]. I think a single patch might
> be able to do both of these [...]

It turns out Abseil upstream doesn’t have a great way of specifying
dependencies on external libraries in their CMake support files. So far,
this hasn’t been an issue, probably because most projects using the
CMake support files are happy with the default dynamic linking, where
dependencies are handled by the loader. But I’m now more skeptical that
a single patch will solve both of these issues.

I’ll continue investigation, but in the meantime, I’m going to do an
upload with -latomic in the right places. That should solve the build
problems on armel.


signature.asc
Description: PGP signature

Bug#963320: libtgvoip: FTBFS: AttributeError: module 'string' has no attribute 'maketrans'

[Nicholas Guriev]

On Fri, 2020-11-06 at 22:06 +0100, Xavier wrote:
> sorry, I launched a full rebuild in unstable and didn't see this change.
> However I don't understand this error (I'm not Python dev), code is:
> 
>  try:
>    # maketrans moved to str in python3.
>    _maketrans = string.maketrans
>  except NameError:
>    _maketrans = str.maketrans
> 
> So error should be discarded, isn't it?

It seems wrong exception is handled here. NameError[1] happens when
unknown top-level variable is referenced. However, above this line,
there is importing of string module. So NameError is not possible here.
I daresay an original author meant AttributeError[2] here that is raised
when code is trying to get non-existent attribute (a thing after dot).

I suggest replace NameError with AttributeError:

   try:
 # maketrans moved to str in python3.
 _maketrans = string.maketrans
   except AttributeError:
 _maketrans = str.maketrans

(not tested)

 [1]: https://docs.python.org/3/library/exceptions.html#NameError
 [2]: https://docs.python.org/3/library/exceptions.html#AttributeError



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

Bug#963320: libtgvoip: FTBFS: AttributeError: module 'string' has no attribute 'maketrans'

[Xavier]

Le 06/11/2020 à 19:08, Nicholas Guriev a écrit :
> On Thu, 2020-11-05 at 06:27 +0100, Xavier wrote:
>> I'm unable to reproduce the bug: libtgvoip build works fine here. Could
>> you verify that the bug still exists?
>>
>> Cheers,
>> Xavier
> 
> Xavier, which version of the libtgvoip package did you try to build? The
> bug is reproducible with 2.4.4-2 as stated in the start message in this
> thread. Newer versions do not depend on GYP. But the issue is still
> present. Minimal example needs almost nothing:
> 
>mymedia@barberry:~$ gyp --format=cmake --depth=. - < /dev/null
>Traceback (most recent call last):
>  File "/usr/bin/gyp", line 11, in 
>load_entry_point('gyp==0.1', 'console_scripts', 'gyp')()
>  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 552, in 
> script_main
>return main(sys.argv[1:])
>  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 545, in main
>return gyp_main(args)
>  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 518, in 
> gyp_main
>[generator, flat_list, targets, data] = Load(
>  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 98, in Load
>generator = __import__(generator_name, globals(), locals(), 
> generator_name)
>  File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line 43, 
> in 
>_maketrans = string.maketrans
>AttributeError: module 'string' has no attribute 'maketrans'
>mymedia@barberry:~$ 

Hi,

sorry, I launched a full rebuild in unstable and didn't see this change.
However I don't understand this error (I'm not Python dev), code is:

 try:
   # maketrans moved to str in python3.
   _maketrans = string.maketrans
 except NameError:
   _maketrans = str.maketrans

So error should be discarded, isn't it?

Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)

[Pablo Mestre]

El 11/1/20 a las 3:33 PM, Otto Kekäläinen escribió:
> Hello Pablo!
>
> Please also check that your watchfile is a working one. Now it fails with:
>
> ± gbp import-orig --uscan --no-interactive --verbose
> gbp:debug: ['git', 'rev-parse', '--show-cdup']
> gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> gbp:debug: ['git', 'rev-parse', '--git-dir']
> gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
> gbp:debug: ['git', 'status', '--porcelain']
> gbp:info: Launching uscan...
> uscan warn: In watchfile debian/watch, reading webpage
>   https://github.com/palantir/python-jsonrpc-servers/tags failed: 404 Not 
> Found
> gbp:error: Uscan failed: In watchfile debian/watch, reading webpage
>   https://github.com/palantir/python-jsonrpc-servers/tags failed: 404 Not 
> Found

Done :)

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

Bug#973889: raptor2: CVE-2017-18926

[Salvatore Bonaccorso]

Source: raptor2
Version: 2.0.14-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for raptor2.

CVE-2017-18926[0]:
| raptor_xml_writer_start_element_common in raptor_xml_writer.c in
| Raptor RDF Syntax Library 2.0.15 miscalculates the maximum nspace
| declarations for the XML writer, leading to heap-based buffer
| overflows (sometimes seen in raptor_qname_format_as_xml).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-18926
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18926
[1] 
https://github.com/LibreOffice/core/blob/master/external/redland/raptor/0001-Calcualte-max-nspace-declarations-correctly-for-XML-.patch.1
[2] https://www.openwall.com/lists/oss-security/2017/06/07/1

Regards,
Salvatore

Bug#973884: make-dfsg: fix for extraordinarily-long command lines (#688601) has gone missing

[Mike Crowe]

Source: make-dfsg
Severity: normal

Dear Maintainer,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688601 was fixed back in
2014 by applying a patch (dgit:407e2fb3130d4540482a04987222dead70936122)
and this fix worked well for us for several years.

Unfortunately, this change appears to have been removed as part of:

 commit 0e957340243587eeffb525aff3200b5e143ac274
 Author: Manoj Srivastava 
 Date:   Mon Feb 12 16:26:34 2018 -0800

 [master]: revert debian specific patches that have been integrated 
differently upstream.

 Signed-off-by: Manoj Srivastava 

so this fix is no longer present in Buster, and apparently Bullseye. I've
been unable to find any other information about reverting the fix.

The main part of the original patch still applied and the conflicts in the
configure.ac file appeared to be straightforward to resolve. The resulting
patch is attached. Applying it fixed the problem for me.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (400, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
commit f079489160d620e5eb50dc09e51f09f71a7dcffb
Author: Mike Crowe 
Date:   Fri Nov 6 15:22:37 2020 +

Resurrect fix for large command line

This patch was originally applied by Manoj Srivastava to fix Debian bug
other changes that had apparently been fixed differently upstream. That
turns out not to have been true for this particular fix.

The original patch description follows.

---8<---
[handle_excessive_command_length]: Patch to fix large cmmand line

When presented with a very very long command line (e.g. WebKit's linking
of libWebCore.la in current git), make fails to execute the command as
it doesn't split the command line to fit within the limits.

This patch provides a POSIX specific fix.
--->8---

diff --git a/configure.ac b/configure.ac
index a1d41640..98dd2309 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,7 +75,7 @@ AC_HEADER_STAT
 AC_HEADER_TIME
 AC_CHECK_HEADERS([stdlib.h locale.h unistd.h limits.h fcntl.h string.h \
   memory.h sys/param.h sys/resource.h sys/time.h sys/timeb.h \
-  sys/select.h sys/file.h spawn.h])
+  sys/select.h sys/file.h spawn.h sys/user.h linux/binfmts.h])
 
 AM_PROG_CC_C_O
 AC_C_CONST
diff --git a/src/job.c b/src/job.c
index ae1f18b9..3abba81a 100644
--- a/src/job.c
+++ b/src/job.c
@@ -26,6 +26,14 @@ this program.  If not, see .  */
 #include "variable.h"
 #include "os.h"
 
+#if defined (HAVE_LINUX_BINFMTS_H) && defined (HAVE_SYS_USER_H)
+#include 
+#include 
+#endif
+#ifndef PAGE_SIZE
+# define PAGE_SIZE (sysconf(_SC_PAGESIZE))
+#endif
+
 /* Default shell to use.  */
 #ifdef WINDOWS32
 # ifdef HAVE_STRINGS_H
@@ -3217,6 +3225,7 @@ construct_command_argv_internal (char *line, char **restp, const char *shell,
 #ifdef WINDOWS32
 char *command_ptr = NULL; /* used for batch_mode_shell mode */
 #endif
+char *args_ptr;
 
 # ifdef __EMX__ /* is this necessary? */
 if (!unixy_shell && shellflags)
@@ -3382,8 +3391,17 @@ construct_command_argv_internal (char *line, char **restp, const char *shell,
 return new_argv;
   }
 
+#ifdef MAX_ARG_STRLEN
+static char eval_line[] = "eval\\ \\\"set\\ x\\;\\ shift\\;\\ ";
+#define ARG_NUMBER_DIGITS 5
+#define EVAL_LEN (sizeof(eval_line)-1 + shell_len + 4   \
+  + (7 + ARG_NUMBER_DIGITS) * 2 * line_len / (MAX_ARG_STRLEN - 2))
+#else
+#define EVAL_LEN 0
+#endif
+
 new_line = xmalloc ((shell_len*2) + 1 + sflags_len + 1
-+ (line_len*2) + 1);
++ (line_len*2) + 1 + EVAL_LEN);
 ap = new_line;
 /* Copy SHELL, escaping any characters special to the shell.  If
we don't escape them, construct_command_argv_internal will
@@ -3403,6 +3421,30 @@ construct_command_argv_internal (char *line, char **restp, const char *shell,
 #ifdef WINDOWS32
 command_ptr = ap;
 #endif
+
+#if !defined (WINDOWS32) && defined (MAX_ARG_STRLEN)
+if (unixy_shell && line_len > MAX_ARG_STRLEN)
+  {
+   unsigned j;
+   memcpy (ap, eval_line, sizeof (eval_line) - 1);
+   ap += sizeof (eval_line) - 1;
+   for (j = 1; j <= 2 * line_len / (MAX_ARG_STRLEN - 2); j++)
+ ap += sprintf (ap, "\\$\\{%u\\}", j);
+   *ap++ = '\\';
+   *ap++ = '"';
+   *ap++ = ' ';
+   /* Copy only the first word of SHELL to $0.  */
+   for (p = shell; *p != '\0'; ++p)
+ {
+   if (isspace ((unsigned char)*p))
+ break;
+   *ap++ = *p;
+ }
+   *ap++ = ' ';
+  }
+#endif
+args_ptr = ap;
+
 for 

Bug#944372: Backtrace

[Jochen Betz]

Hi still experience the same issue. To me it seems that it has problems
parsing/handling the mail file in /var/mail/USERNAME. As long as it is
empty, it does not fail.
As soon as it contains something... segfault!

The following is a stack trace I could gather:


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
"/var/mail/jochen": 1 message 1 new

Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or
directory.
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x775e0dae in __GI___strdup (s=0x0) at strdup.c:41
#2  0x77a43b5f in mu_strdup (s=0x0) at alloc.c:77
#3  0x55576818 in util_get_charset () at util.c:1067
#4  0x55576891 in util_rfc2047_decode (value=0x7fffb248) at
util.c:1087
#5  0x555657f9 in hdr_from (args=0x7fffb2e0, data=0x0) at
from.c:273
#6  0x5556518d in format_headline (seg=0x555a39f0,
mspec=0x7fffb370, msg=0x555b0280) at from.c:97
#7  0x555664c3 in mail_from0 (mspec=0x7fffb370,
msg=0x555b0280, data=0x0) at from.c:609
#8  0x5556db95 in page_do (func=0x55566495 ,
data=0x0) at page.c:178
#9  0x55566537 in mail_headers (argc=1, argv=0x555b0c28) at
headers.c:35
#10 0x5557462f in util_do_command (fmt=0x55578eca "headers")
at util.c:143
#11 0x55567d0d in main (argc=0, argv=0x7fffb7b0) at mail.c:654
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
No locals.
#1  0x775e0dae in __GI___strdup (s=0x0) at strdup.c:41
len = 
new = 
#2  0x77a43b5f in mu_strdup (s=0x0) at alloc.c:77
news = 0x0
#3  0x55576818 in util_get_charset () at util.c:1067
lc_all = {flags = 0, language = 0x0, territory = 0x0, charset =
0x0, modifier = 0x0}
tmp = 0x7fffee86 ""
charset = 0x55588b70 "auto"
#4  0x55576891 in util_rfc2047_decode (value=0x7fffb248) at
util.c:1087
charset = 0x7fffb280 "\020\263\377\377\377\177"
tmp = 0x77a5ee63 
"H\213E\370H\211E\360H\203", 
rc = 0
#5  0x555657f9 in hdr_from (args=0x7fffb2e0, data=0x0) at
from.c:273
hdr = 0x555b2140
from = 0x5558fe00 "jochen"
#6  0x5556518d in format_headline (seg=0x555a39f0,
mspec=0x7fffb370, msg=0x555b0280) at from.c:97
width = 1
len = 1
cols_rest = 181
p = 0x55589870 " "
screen_cols = 188
out_cols = 7
args = {mspec = 0x7fffb370, msg = 0x555b0280, cols_rest
= 181, buf = 0x55591660 "1", size = 2}
#7  0x555664c3 in mail_from0 (mspec=0x7fffb370,
msg=0x555b0280, data=0x0) at from.c:609
No locals.
#8  0x5556db95 in page_do (func=0x55566495 ,
data=0x0) at page.c:178
msg = 0x555b0280
set = {next = 0x0, npart = 1, msg_part = 0x555a3250}
i = 0
#9  0x55566537 in mail_headers (argc=1, argv=0x555b0c28) at
headers.c:35
No locals.
#10 0x5557462f in util_do_command (fmt=0x55578eca "headers")
at util.c:143
ws = {ws_wordc = 1, ws_wordv = 0x555b0c20, ws_offs = 1,
ws_wordn = 128, ws_flags = 33558086, ws_options = 1632, ws_delim =
0x77ad6e9e " \t\n", ws_comment = 0x0, ws_escape = {0x77af6360
 "\"\"a\ab\bf\fn\nr\rt\tv\v",
0x77af6360 
"\"\"a\ab\bf\fn\nr\rt\tv\v"}, ws_alloc_die = 0x77ab20d8
<_wsplt_alloc_die>, ws_error = 0x77ab2116 <_wsplt_error>, ws_debug =
0x55585fd8 , ws_env = 0x1, ws_envbuf = 0x555ad430,
ws_envidx = 483314001, ws_envsiz = 0, ws_getvar = 0x1, ws_closure = 0x0,
ws_command = 0x0, ws_input = 0x555b09e0 "@\"[UUU", ws_len = 7,
ws_endp = 7, ws_errno = 0, ws_usererr = 0x555799b6 "header", ws_head
= 0x0, ws_tail = 0x0, ws_lvl = 0}
argc = 1
argv = 0x555b0c28
status = 0
entry = 0x55582500 
cmd = 0x555b09e0 "@\"[UUU"
size = 512
ap = {{gp_offset = 8, fp_offset = 48, overflow_arg_area =
0x7fffb5d0, reg_save_area = 0x7fffb500}}
#11 0x55567d0d in main (argc=0, argv=0x7fffb7b0) at mail.c:654
mode = 0x55589f60 "read"
prompt = 0x0
p = 0x555a35c7 "/home/jochen/.mailrc"
i = 56
rc = 0

Thread 1 (Thread 0x76739980 (LWP 7076)):
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
No locals.
#1  0x775e0dae in __GI___strdup (s=0x0) at strdup.c:41
len = 
new = 
#2  0x77a43b5f in mu_strdup (s=0x0) at alloc.c:77
news = 0x0
#3  0x55576818 in util_get_charset () at util.c:1067
lc_all = {flags = 0, language = 0x0, territory = 0x0, charset =
0x0, modifier = 0x0}
tmp = 0x7fffee86 ""
charset = 0x55588b70 "auto"
#4  

Bug#973877: tcpdump: CVE-2020-8037

[Salvatore Bonaccorso]

Hi Romain,

On Fri, Nov 06, 2020 at 07:01:46PM +0100, Romain Francoise wrote:
> Hi,
> 
> On Fri, Nov 6, 2020 at 1:48 PM Salvatore Bonaccorso  wrote:
> > The following vulnerability was published for tcpdump.
> >
> > CVE-2020-8037[0]:
> > | The ppp decapsulator in tcpdump 4.9.3 can be convinced to allocate a
> > | large amount of memory.
> 
> Thanks for the bug report. I am aware of this CVE and working on a new
> upload to unstable.
> Is this no-dsa?

Yes it does not warrant a DSA, but if you are at it and have capacity
for it, please do include a fix for it in the upcoming point release
(cf. https://lists.debian.org/debian-live/2020/11/msg0.html).

Regards,
Salvatore

Bug#973657: src:rust-onig: autopkgtest uses enormous amount (> 25 GB) of disk space

[Paul Gevers]

Hi Paride,

Thanks for the quick fix.

On 06-11-2020 09:38, Paride Legovini wrote:
> I'm [ ... ] unsure on why the
> autopkgtest started misbehaving, given that 5.0.0-3 was uploaded back in
> April 2020.

That's because I only recently reported the issue. I had blocked your
package already for a while on arm64. Sorry for not filing earlier, but
I try to balance infrastructure issues to issues worth bothering
maintainers. Apparently I balanced weirdly a while ago when I check arm64.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#972905: some more information

[Mahashakti89]

Hi,

Only provisory way out of this: I fetched last version of
sane-backends, compiled and installed in /usr/local and it works now.

Regards

-- 
Lumière de tous les chakras ! ⚡⚡⚡藍 藍藍

Bug#973888: RFS: tinydyndns/0.4.2.debian1-2 [QA] -- pop-before-dyndns service using djbdns

[Baptiste Beauplat]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tinydyndns
   Version : 0.4.2.debian1-2
   Upstream Author : Gerrit Pape 
 * URL : http://smarden.org/tinydyndns/
 * License : BSD-3-Clause, public-domain
 * Vcs : https://salsa.debian.org/debian/tinydyndns
   Section : net

It builds those binary packages:

  tinydyndns - pop-before-dyndns service using djbdns

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tinydyndns/tinydyndns_0.4.2.debian1-2.dsc


Changes since the last upload:

 tinydyndns (0.4.2.debian1-2) unstable; urgency=medium
 .
   * QA upload.
   * Set Maintainer to Debian QA Group (#947703)
   * Bump Standard-Version to 4.5.0
   * Add Homepage url (Closes: #949223)
   * Add VCS url to salsa project
   * Set Rules-Requires-Root to no
   * Convert source format to 3.0 (quilt)
   * Convert copyright to DEP5
   * Add missing license for djbdns files
   * Fix spacing in debian/control
   * Convert rules to dh sequencer (Closes: #911393, #776929, #847032)
   * Add Build-Depends to debhelper-compat (= 13)
   * List binaries to install in d/install
   * List manpages to install in d/manpages
   * Add ${misc:Depends}
   * Fix typo in manpages and docs
   * Add salsa CI pipeline
   * Use recommended branch name from DEP-14
   * Remove unused implicit file in debian packaging
   * Add an explanation to the repacked upstream sources

Regards,
--
Baptiste Beauplat - lyknode



OpenPGP_signature
Description: OpenPGP digital signature

Bug#971704: gnome-shell-pomodoro: diff for NMU version 0.18.0-0.1

[Joseph Herlant]

Thanks for doing that. I unfortunately haven't taken any time for
opensource since the beginning of this COVID madness.

Feel free to push it now. It's totally fine with me.

Thanks
Joseph

Bug#973570: fzf: keybinding files should be installed under /etc

[Jai Flack]

On Sun, 01 Nov 2020 23:56:28 + yacoob  wrote:
> Right now the example keybindings for different shells
> (/usr/share/doc/fzf/examples/key-bindings.*) are placed under
> /usr/share/doc. This is all fine and good, except for cases where you're using
> a slimed down file (eg. debian-slim image from docker) which doesn't have
> /usr/share/doc. Please consider placing those keybindings somewhere under 
> /etc.

/usr/share/doc is the standard location for these in Debian. What would
be the use-case for having these in a docker (or other) image designed
to not include unnecessary files?

-- 
Thanks,
Jai

Bug#973887: alsa-utils: alsamixer default Sound Card hangs (high CPU usage) with `pulseaudio --kill`

[rv]

Package: alsa-utils
Version: 1.2.3-1
Severity: normal
X-Debbugs-Cc: riveravaldezm...@gmail.com

Dear Maintainer,

   * What led up to the situation?

AFAICT, last system update (yesterday).

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

With alsamixer running in a separated terminal [F6: Sound Card : - (default)] I 
did `pulseaudio --kill`.

   * What was the outcome of this action?

CPU starts to work a lot and non-stoping. Going to alsamixer and doing F6: 
select another Card (the '0' one, for instance) stops this hang. But then when 
trying to choose again '- (default)' I have this message:
> Error
> Cannot open mixer device 'default'.
> Connection refused

Which I suppose it's OK since PA is not running.
If I do `pulseaudio --start` and try again alsamixer seems to recover 
('default' appears again).

   * What outcome did you expect instead?

Not high-CPU-hanging, I suppose.

Thanks a lot. Best regards.


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages alsa-utils depends on:
ii  kmod  27+20200310-2
ii  libasound21.2.3.2-1
ii  libatopology2 1.2.3.2-1
ii  libc6 2.30-8
ii  libfftw3-single3  3.3.8-2
ii  libncursesw6  6.2+20200918-1
ii  libsamplerate00.1.9-2
ii  libtinfo6 6.2+20200918-1
ii  lsb-base  11.1.0

alsa-utils recommends no packages.

Versions of packages alsa-utils suggests:
ii  dialog  1.3-20190808-1

-- no debconf information

Bug#973886: xserver-xorg-video-nouveau: Suspend to ram is not working with GeForce 210

[Goran Delcev]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: normal
X-Debbugs-Cc: barney67...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

I have Installed bullseye (clean install).
After installation I have installed firmware for nvidia graphics card. Rebooted 
the
system. Tried to suspend to ram, screen goes black but power is still on.
I cannot rebbot the system or X. I have to use hardware reset.
After this I have installed Nvidia legacy driver from the Debian repository,
rebooted the system, and everything is working fine.
Conclusion: there is a bug in nouveau driver.

*** End of the template - remove these template lines ***


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.1-1 (2020-10-17)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 75393 Nov  6 19:57 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[18.636] (--) Log file renamed from "/var/log/Xorg.pid-545.log" to 
"/var/log/Xorg.0.log"
[18.684] 
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[18.684] Build Operating System: Linux 4.19.0-8-amd64 x86_64 Debian
[18.684] Current Operating System: Linux living 5.9.0-1-amd64 #1 SMP Debian 
5.9.1-1 (2020-10-17) x86_64
[18.684] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-1-amd64 
root=UUID=2e3cbbdf-a1b2-451d-a50b-c0fe04e7b7de ro quiet
[18.684] Build Date: 31 March 2020  10:14:40AM
[18.684] xorg-server 2:1.20.8-2 (https://www.debian.org/support) 
[18.684] Current version of pixman: 0.36.0
[18.684]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[18.684] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[18.684] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Nov  6 19:48:33 
2020
[18.791] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[18.890] (==) No Layout section.  Using the first Screen section.
[18.890] (==) No screen section available. Using defaults.
[18.890] (**) |-->Screen "Default Screen Section" (0)
[18.890] (**) |   |-->Monitor ""
[18.891] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[18.891] (==) Automatically adding devices
[18.891] (==) Automatically enabling devices
[18.891] (==) Automatically adding GPU devices
[18.891] (==) Max clients allowed: 256, resource mask: 0x1f
[18.931] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[18.931]Entry deleted from font path.
[18.948] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[18.948] (==) ModulePath set to "/usr/lib/xorg/modules"
[18.948] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[18.948] (II) Loader magic: 0x55f91fcd6e20
[18.948] (II) Module ABI versions:
[18.948]X.Org ANSI C Emulation: 0.4
[18.948]X.Org Video Driver: 24.1
[18.948]X.Org XInput driver : 24.1
[18.948]X.Org Server Extension : 10.0
[18.949] (++) using VT number 7

[18.949] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[18.950] (II) xfree86: Adding drm device (/dev/dri/card0)
[18.954] (--) PCI:*(1@0:0:0) 10de:0a65:1458:3530 rev 162, Mem @ 
0xf900/16777216, 0xd000/268435456, 0xee00/33554432, I/O @ 
0xef00/128, BIOS @ 0x/131072
[18.954] (II) LoadModule: "glx"
[18.969] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[19.128] (II) Module glx: vendor="X.Org Foundation"
[19.128]compiled for 1.20.8, module version = 1.0.0
[19.128]ABI class: X.Org Server Extension, version 10.0
[19.251] 

Bug#954271: libsys-sigaction-perl: arm64 autopkgtest time out

[Adrian Bunk]

Control: forwarded -1 https://github.com/labaxter/sys-sigaction/issues/2
Control: tags -1 buster bullseye sid

On Thu, Apr 23, 2020 at 10:06:47PM +0300, Niko Tyni wrote:
> On Thu, Mar 19, 2020 at 03:20:34PM +0100, Paul Gevers wrote:
> > Source: libsys-sigaction-perl
> > Version: 0.23-1
> > Severity: important
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: timeout
>  
> > libsys-sigaction-perl fails its autopkgtest on arm64 due to a time out
> > after 2h47. Can you please investigate the situation?
> > 
> > To avoid wasting lots of time on the ci.debian.net infrastructure, I
> > have added your package to the ignore list for arm64.
> 
> Thanks.
> 
> The module has several upstream workarounds for arm platforms, but those
> aren't used for arm64 because its $Config{archname} starts with 'aarch64'
> not 'arm'.
> 
> The comments point to defects in either the arm platform or the base Perl
> implementation there. I don't know if these things have been triaged on
> the Perl side upstream.
> 
> Possibly we should make this arch:any to see if there are other
> problematic architectures. Or just tune the test suite to skip on aarch64
> as well.
>...

In Debian the test hangs since buster, but succeeds in stretch:
https://tests.reproducible-builds.org/debian/rb-pkg/buster/arm64/libsys-sigaction-perl.html

libsys-sigaction-perl hasn't changed since stretch.

Someone else recently reported the same issue elsewhere also for arm64,
see the forwarded URL above.

> Niko

cu
Adrian

Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.

[Ben Hutchings]

On Fri, 2020-11-06 at 17:55 +0100, David Heidelberg wrote:
> Hello Ben,
> 
> I asked about possibility of changing name and the final reply is [1].
> 
> Quoting dreamer:
> Right now, we are fighting to convince users (and developers) to move 
> on from using a myriad of tiny DOSBox forks (link - very incomplete, 
> there are ~50 other dead forks I know of) or maintain their own 
> patchsets based on 10-year old 0.74. We have already certain (hard 
> thought for) recognition and community formed up - changing name at 
> this point will only cause confusion and hurt the project's prospects 
> for future.

Oh well, thanks for asking anyway.  I suggest you make the long
description clearly state that this is independent of the original
DOSBox project.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.




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

Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.

[Patryk Obara]

On 06/11/2020 17:55, David Heidelberg wrote:

Hello Ben,

I asked about possibility of changing name and the final reply is [1].


You managed to quote me before I wrote it myself here :) I will
also add the first sentence from my post:

> No, we are not open for changing the project name *at this time*. We
> might change the name at some point, but only once we'll have a really
> good reason to do so, and pros of the name change will overweight the
> cons of doing so.

We are already packaged by several OSes, universally using
dosbox-staging name [1]. We also have our own downstreams already
and even the first commercial user.

[1]: https://repology.org/project/dosbox-staging/versions

Changing the name would require redesigning logo and icon and
make it much more difficult to merge with other forks, at no
particular benefits to us or our users.

The project started as a staging repo for vanilla DOSBox and we
tried to cooperate with upstream for 6 months (or several years,
if we count the efforts of patch maintainers who were waiting for
their functionalities to be merged and are now maintainers in our
repo or at least finally landed their change).

This attempt at collaboration failed, but despite of that, I hope
the DOSBox team will eventually be open for merging the projects,
as it seems they are not interested in doing another major release
again (0.74 was released 10 years ago (!)). We carefully maintain
our Git history to make it feasible. We also keep the project
features allowing dosbox-staging to be a drop-in replacement.

We will probably change the name when it will be prudent to do so,
e.g. when merging with other DOSBox fork, or if we decide to break
the backwards compatibility with the vanilla DOSBox. I don't see this
happening at least for another year, we still have too long backlog
of community patches to investigate and merge/redesign.

--
| ← Ceci n'est pas une pipe
Patryk Obara

Bug#963320: libtgvoip: FTBFS: AttributeError: module 'string' has no attribute 'maketrans'

[Nicholas Guriev]

On Thu, 2020-11-05 at 06:27 +0100, Xavier wrote:
> I'm unable to reproduce the bug: libtgvoip build works fine here. Could
> you verify that the bug still exists?
> 
> Cheers,
> Xavier

Xavier, which version of the libtgvoip package did you try to build? The
bug is reproducible with 2.4.4-2 as stated in the start message in this
thread. Newer versions do not depend on GYP. But the issue is still
present. Minimal example needs almost nothing:

   mymedia@barberry:~$ gyp --format=cmake --depth=. - < /dev/null
   Traceback (most recent call last):
 File "/usr/bin/gyp", line 11, in 
   load_entry_point('gyp==0.1', 'console_scripts', 'gyp')()
 File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 552, in 
script_main
   return main(sys.argv[1:])
 File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 545, in main
   return gyp_main(args)
 File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 518, in 
gyp_main
   [generator, flat_list, targets, data] = Load(
 File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 98, in Load
   generator = __import__(generator_name, globals(), locals(), 
generator_name)
 File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line 43, in 

   _maketrans = string.maketrans
   AttributeError: module 'string' has no attribute 'maketrans'
   mymedia@barberry:~$ 

-- 

I sent this message yesterday, but it does not seem to have been
delivered. At least, I do not see it on web-pages at bugs.d.o. So I have
to resend the email, sorry if it reaches you twice.



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

Bug#973877: tcpdump: CVE-2020-8037

[Romain Francoise]

Hi,

On Fri, Nov 6, 2020 at 1:48 PM Salvatore Bonaccorso  wrote:
> The following vulnerability was published for tcpdump.
>
> CVE-2020-8037[0]:
> | The ppp decapsulator in tcpdump 4.9.3 can be convinced to allocate a
> | large amount of memory.

Thanks for the bug report. I am aware of this CVE and working on a new
upload to unstable.
Is this no-dsa?

Bug#973767: dolfin FTBFS: The MPI_Comm_rank() function was called before MPI_INIT was invoked.

[Drew Parsons]

Source: dolfin
Followup-For: Bug #973767

Yeah, I'm more certain SLEPc is the problem.  In the new release they
abolishing SLEPc.pc, renaming it slepc.pc.  Since pkg-config is
case-sensitive, the unexpected change is causing problems. 

Notice how the reported error is only with dolfin64. Because the
proper SLEPc is not detected, the 64-bit build is mixing up 32-bit and
64-bit builds of PETSc and SLEPc.

Resolution in progress.

Bug#973875: groupware-install: ERROR: column "increment_by" does not exist

[Mike Gabriel]

Hi Christopher,

On  Fr 06 Nov 2020 12:24:24 CET, Christopher 'm4z' Holm wrote:


Package: php-horde-db
Version: 2.4.0-3

When trying to do the post-install setup of "php-horde-groupware"
(version 5.2.22-3) on Debian 10 (buster) with "postgresql" (version
11+200+deb10u4), /usr/bin/groupware-install fails (this seems to be a
variant of #880380):
-- 8< --
# groupware-install
[…]
Should Horde log all queries. If selected, queries will be logged at
the DEBUG level to your configured logger.
(1) Yes
(0) No

Type your choice [0]: 1

Writing main configuration file... done.

Creating and updating database tables...
  Fatal Error:
  SQLSTATE[42703]: Undefined column: 7 ERROR:  column "increment_by"
does not exist
  LINE 1: ..._seq', (SELECT COALESCE(MAX("share_id") + (SELECT increment_..


could you try the php-horde-db version from testing/unstable and  
report back if the issue you observe is resolved then?


If so, I am happy to provide a buster update upload of the package  
(containing the relevant pgsql patches that have recently been added  
to php-horde-db in testing/unstable).


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpyzQhgF1m4X.pgp
Description: Digitale PGP-Signatur

Bug#973885: manpages-dev: broken symlinks /usr/share/man/man3/LIST_*.3

[Jakub Wilk]

Package: manpages-dev
Version: 5.09-2
User: debian...@lists.debian.org
Usertags: adequate broken-symlink

This package ships broken symlinks:

  $ dpkg -L manpages-dev | xargs -n1 file | grep -w broken
  /usr/share/man/man3/LIST_EMPTY.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_ENTRY.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_FIRST.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_FOREACH.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_HEAD.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_HEAD_INITIALIZER.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_INIT.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_INSERT_AFTER.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_INSERT_BEFORE.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_INSERT_HEAD.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_NEXT.3: broken symbolic link to list.3
  /usr/share/man/man3/LIST_REMOVE.3: broken symbolic link to list.3


-- System Information:
Architecture: i386

Versions of packages manpages-dev depends on:
ii  manpages  5.09-2

--
Jakub Wilk

Bug#973874: [Pkg-utopia-maintainers] Bug#973874: network-manager: The Mobile Broadband connection does not show up in Network-Manager anymore

[Julien Patriarca]

On Fri, Nov 06, 2020 at 04:14:47PM +0100, Michael Biebl wrote:
> Control: reassign -1 gnome-shell
> 
> 
> I suspect with NetworkManager panel you mean the one that is provided
> by gnome-shell. NetworkManager itself doesn't really have any GUI.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971511
> looks like a duplicate. You might want to test if gnome-shell 3.38.1-2
> fixes your issue.


Indeed, you are right, I was speaking about the Gnome one.
I'll look into the link you gave me. Thank you for your swift answer.




signature.asc
Description: PGP signature

Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.

[David Heidelberg]

Hello Ben,

I asked about possibility of changing name and the final reply is [1].

Quoting dreamer:
Right now, we are fighting to convince users (and developers) to move 
on from using a myriad of tiny DOSBox forks (link - very incomplete, 
there are ~50 other dead forks I know of) or maintain their own 
patchsets based on 10-year old 0.74. We have already certain (hard 
thought for) recognition and community formed up - changing name at 
this point will only cause confusion and hurt the project's prospects 
for future.


[1] 
https://github.com/dosbox-staging/dosbox-staging/issues/703#issuecomment-723178233

Best regards
David Heidelberg

On Thu, Nov 5, 2020 at 21:52, Ben Hutchings  wrote:

On Thu, 2020-11-05 at 17:41 +0100, David Heidelberg wrote:
[...]

 Q: why is this package useful/relevant?
 A: Sucessor of DOSBox, which is already inside Debian

[...]

DOSBox seems to be under active development even though it hasn't had 
a

release for a while.  So this is an independent fork, not a successor
to a dead project.  (If DOSBox had become dead upstream, I would have
recommended rebasing the existing dosbox source package on DOSBox
Staging instead.)

I think this name is also misleading.  "DOSBox Staging" sounds like a
development branch of the original DOSBox project, not an independent
project.  Are the upstream developers set on using this name or do you
think they could be persuaded to use something more distinctive?

Ben.

--
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

Bug#972189: sympa: CVE-2020-10936 regression - removal of needed environment variables

[Sylvain Beucler]

Hi,

From what I understand the FCGI wrapper was used as CGI through e.g. 
fcgiwrap, and upstream recommended to switch to fcgi-spawn following 
https://sympa-community.github.io/manual/install/configure-http-server-spawnfcgi.html


Carsten agreed and suggested we add a note about this in the Debian 
documentation, so I plan to add a note in README.Debian or NEWS.Debian.

https://github.com/sympa-community/sympa/issues/1020#issuecomment-710763168

Given there were no other reports I believe this addresses the issue.

Cheers!
Sylvain Beucler
Debian LTS Team

Bug#973698: g++-10: regresson in 10.2.0-16: internal compiler error: in tsubst_decl, at cp/pt.c:14666

[Matthias Klose]

Control: forwarded -1 https://gcc.gnu.org/PR97745

please could you try to build the package with gcc-snapshot to see if you get an
error?

Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)

[Pablo Mestre]

El 11/6/20 a las 4:09 AM, Otto Kekäläinen escribió:
> Hello!
>
> I don't see any new commits or Merge Requests at
> https://salsa.debian.org/python-team/packages/python-jsonrpc-server
>
> Do you plan to do some additional changes still?

I dont upload any commit because I get the same old error.

The upstream release a new version also with the same problem.
Im trying to solve the errors on test before upload new commits

Hope I can solve this in the next two days


-- 

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

Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)

[Pablo Mestre]

El 11/6/20 a las 12:40 PM, Jochen Sprickerhof escribió:
> Hi Pablo,
>
> * Pablo Mestre  [2020-11-05 22:38]:
>>
>> El 11/1/20 a las 2:44 PM, Otto Kekäläinen escribió:
>>> Hello!
>>>
>>>
>>> Pablo Mestre:
>>>
>>> Please check out
>>> https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/pipelines
>>>
>>> and submit MR at
>>> https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/merge_requests
>>>
>>> if you have fixes for the failing CI.
>>>
>>> - Otto
>>
>> It is a bit rare that this error appears again[1].
>>
>> Previously it had been fixed with a patch [2] and the addition of
>> python3-ujson by Jochen Sprickerhof
>
> Well previously we where using python3-ujson 1.35 but in the meantime
> version 4.0.1 was uploaded to unstable.
>
> Looking at
>
> https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/jobs/1126139
>
>
> The error is:
>
> TypeError: datetime.datetime(2019, 1, 1, 1, 1, 1) is not JSON
> serializable
>
> which you can reproduce easily (and sounds right).
>
> On the other hand jsonrpc requers an old ujson:
>
> https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/blob/debian/master/setup.py#L37
>
>
> Consider talking to upstream about the reasoning behind it.
>
> Cheers Jochen


I check the new version 4.0.0 of python-jsonrpc-server is using ujson 3.0.0

https://github.com/palantir/python-jsonrpc-server/blob/develop/setup.py#L17

But still have the same issue...
I will contact the upstream about it

Thanks

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

Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)

[Jochen Sprickerhof]

Hi Pablo,

* Pablo Mestre  [2020-11-05 22:38]:


El 11/1/20 a las 2:44 PM, Otto Kekäläinen escribió:

Hello!


Pablo Mestre:

Please check out
https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/pipelines
and submit MR at
https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/merge_requests
if you have fixes for the failing CI.

- Otto


It is a bit rare that this error appears again[1].

Previously it had been fixed with a patch [2] and the addition of
python3-ujson by Jochen Sprickerhof


Well previously we where using python3-ujson 1.35 but in the meantime 
version 4.0.1 was uploaded to unstable.


Looking at

https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/jobs/1126139

The error is:

TypeError: datetime.datetime(2019, 1, 1, 1, 1, 1) is not JSON serializable

which you can reproduce easily (and sounds right).

On the other hand jsonrpc requers an old ujson:

https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/blob/debian/master/setup.py#L37

Consider talking to upstream about the reasoning behind it.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#973874: [Pkg-utopia-maintainers] Bug#973874: network-manager: The Mobile Broadband connection does not show up in Network-Manager anymore

[Michael Biebl]

Control: reassign -1 gnome-shell

Am Freitag, den 06.11.2020, 12:19 +0100 schrieb Julien Patriarca:
> Package: network-manager
> Version: 1.27.91-1
> Severity: important
> X-Debbugs-Cc: leatherf...@debian.org
> 
> Dear Maintainer,
> 
> I have a mobile broadband connection setup on my laptop, and I used
> to
> configure and activate it through Network-Manager. Since a few days
> the
> connection does not show up in the Network-Manager panel anymore. I
> have
> to open the gnome-control-panel to be able to use my mobile broadband
> connection.
> 

I suspect with NetworkManager panel you mean the one that is provided
by gnome-shell. NetworkManager itself doesn't really have any GUI.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971511
looks like a duplicate. You might want to test if gnome-shell 3.38.1-2
fixes your issue.

Regards,
Michael


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

Bug#972245: openjdk-11-jre-headless: WARNING: tempfile is deprecated; consider using mktemp instead.

[Thorsten Glaser]

Package: openjdk-11-jre-headless
Version: 11.0.9.1+1-1
Followup-For: Bug #972245
X-Debbugs-Cc: t...@mirbsd.de

Just updating the version for this is still present.


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages openjdk-11-jre-headless:amd64 depends on:
ii  ca-bundle [ca-certificates-java]  20190604
ii  java-common   0.72
ii  libasound21.2.3.2-1
ii  libc6 2.31-4
ii  libcups2  2.3.3-3
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.2+dfsg-4
ii  libgcc-s1 10.2.0-16
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  liblcms2-22.9-4+b1
ii  libnss3   2:3.58-1
ii  libpcsclite1  1.9.0-1
ii  libstdc++610.2.0-16
ii  libx11-6  2:1.6.12-1
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.10-1
ii  libxrender1   1:0.9.10-1
ii  libxtst6  2:1.2.3-1
ii  util-linux2.36-3+b2
ii  zlib1g1:1.2.11.dfsg-2

openjdk-11-jre-headless:amd64 recommends no packages.

Versions of packages openjdk-11-jre-headless:amd64 suggests:
ii  fonts-dejavu-extra 2.37-2
pn  fonts-indic
ii  fonts-ipafont-gothic   00303-21
ii  fonts-ipafont-mincho   00303-21
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
pn  libnss-mdns

-- no debconf information

Bug#971644: [elogind/elogind] System crashed on suspend/hibernate failure (#177)

[Thorsten Glaser]

On Fri, 6 Nov 2020, Mark Hindley wrote:

> Can you provide the content of /proc/swaps please.

Sure:

tglase@tglase-nb:~ $ cat /proc/swaps
FilenameTypeSizeUsed
Priority
/dev/sda2   partition   3206140 0   
-2

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

Bug#973883: [apt-cacher-ng] bad exit code (=0) instead (<>0) if Check permissions of /var/log/apt-cacher-ng

[Jean-Marc LACROIX]

Package: apt-cacher-ng
Version: 3.2.1-1
Severity: grave

Dear maintainers,

It seems there is one bad exit code issue (=0) when trying to start 
démon if internal check is bad. (/etc/init.d/apt-cacher-ng start)


ansible@srv-apt-cache-400:~$ dpkg -l |grep apt-cache
ii  apt-cacher-ng 3.2.1-1  amd64 
caching proxy server for software repositories



ansible@srv-apt-cache-400:~$ uname -a
Linux srv-apt-cache-400 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 
(2020-10-18) x86_64 GNU/Linux



ansible@srv-apt-cache-400:~$ cat /etc/debian_version
10.6

ansible@srv-apt-cache-400:~$ pstree -anp
init,1
  |-sshd,682
  |   |-sshd,717
  |   |   `-sshd,719
  |   `-sshd,11014
  |   `-sshd,11016
  |   `-bash,11017
  |   `-pstree,11964 -anp
  |-getty,696 38400 tty2
  |-getty,697 38400 tty3
  |-getty,698 38400 tty4
  |-monit,7389 -c /etc/monit/monitrc
  |   |-{monit},7390
  |   |-{monit},7913
  |   `-(bash,11655)
  |-syslog-ng,9901
  |   `-syslog-ng,9902 -p /var/run/syslog-ng.pid --no-caps
  `-cron,17286


ansible@srv-apt-cache-400:~$ sudo /etc/init.d/apt-cacher-ng start
[] Starting apt-cacher-ng: apt-cacher-ngProblem creating log files. 
Check permissions of the log directory, //var/log/apt-cacher-ng

 failed!
ansible@srv-apt-cache-400:~$ echo $?
0
ansible@srv-apt-cache-400:~$

And, of course, this is true, because ...

ansible@srv-apt-cache-400:~$ sudo ls -altr /var/log/apt-cacher-ng
total 2
drwx-- 2 root root 1024 Nov  6 14:34 .
drwxr-xr-x 8 root root 1024 Nov  6 14:52 ..

Thanks in advance to correct this issue. In my use case, because i am 
using Ansible to make deployment, it is then not possible to detect this 
bug (because exit code = 0) in one automatic way


Best regards

Bug#959016: bazel-bootstrap package now in Debian

[Olek Wojnar]

The initial bazel-bootstrap package is now in Debian and we could really
use a public forum to discuss issues with both further Bazel packaging and
with packaging of software that uses Bazel to build.

Please consider creating this mailing list so that we can have these
technical discussions in a public forum.

Thank you!

-Olek

Bug#973882: RFS: elfio/3.8-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: elfio
   Version : 3.8-1
   Upstream Author : Serge Lamikhov-Center 
 * URL : http://serge1.github.io/ELFIO
 * License : Expat
 * Vcs : https://github.com/serge1/ELFIO
   Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.8-1.dsc

Changes for the initial release:

 elfio (3.8-1) unstable; urgency=medium
 .
   * Initial release (closes: #839382)
   * new upstream version
   * 'copyright' name has been changed to Expat
   * 'watch' file has been updated
   * signing key has been added
   * 'metadata' file added
   * doc-base control file added
   * Passes lintian check with command line:
 lintian -EviIL +pedantic --profile debian --show-overrides \
 elfio_3.8-1_amd64.changes

Initially, the package was requested as a dependency for Apache Mesos (#839382).
The library is used by many processor design companies, academic institutions, 
performance
researchers and other development.

Regards,
--
  Serge Lamikhov-Center

Bug#932081: sogo: Unable to connect to a remote IMAP server.

[Bastian Germann]

On Wed, 05 Feb 2020 13:04:28 -0800 Gerald Turner  wrote:
> FWIW, I rebuilt 4.1.1 sogo and sope packages from bullseye modified
> slightly to link against OpenSSL instead of GnuTLS, installed on a
> production buster system, success!

OpenSSL is considered a system library now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105

This enables building sogo/sope legally with OpenSSL instead of GnuTLS
so that the issue can be addressed without patch on buster.

A newer version should be packaged for sid nevertheless.

Bug#973881: Result of 'git debrebase make-patches' with 'diff.noprefix' git config confuses dgit

[Didier 'OdyX' Raboud]

Package: git-debrebase
Version: 9.12
Severity: normal

Hello there,

after toggling a git diff option globally with:
git config --global diff.noprefix true

I noticed that dgit (at least build-source, but others too) started to fail
comparing patches-applied with patches-unapplied trees.

I'm reporting this against git debrebase, because it seems to me that git
debrebase ought to always format patches in a known-to-work format, no matter
what the user has configured for his personal git usage.

Cheers,
OdyX

Bug#972865: opencfu fails tu start with " Gtk-ERROR **: GTK+ 2.x symbols detected"

[Andreas Tille]

Control: tags -1 moreinfo

Hi Wolf-Dieter,

On Sun, Oct 25, 2020 at 03:02:53PM +0100, Wolf-Dieter Groll wrote:
> Package: opencfu
> Version: 3.9.0-3
> Severity: important
> 
> ...
> Trying to run the program results in the error-message:
> 
> (opencfu:13255): Gtk-ERROR **: 14:25:04.548: GTK+ 2.x symbols detected. Using
> GTK+ 2.x and GTK+ 3 in the same process is not supported
> Trace/Breakpoint ausgelöst
> 
> A Version compiled from the source (https://sourceforge.net/projects/opencfu/)
> showed the same behaviour, so it doesn't seem to be a matter of dependencies.

I've uploaded opencfu_3.9.0-4 supporting OpenCV4.  When I start opencfu
everything looks "normal".  Would you mind having another try with this
package (from unstable) and check whether the issue persists?

> I also looked in the unstable repositories, but the version in Sid seems to be
> exactly the same as in Buster.

This will change (in a couple of hours at least),

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#973829: closed by Debian FTP Masters (reply to Yves-Alexis Perez ) (Bug#973829: fixed in xfwm4 4.15.3-1)

[Laurent Bonnaud]

On 11/5/20 10:39 PM, Debian Bug Tracking System wrote:


#973829: xfwm4: tracker complains about xfce-workspaces-settings.desktop

It has been closed by Debian FTP Masters  (reply to 
Yves-Alexis Perez ).
xfwm4 (4.15.3-1) experimental; urgency=medium
.
  * New upstream version 4.15.3
- Fix empty keyword lines in /u/s/a/xfce4-workspaces-settings.desktop.
Closes: #973829


Thank you for the fix!

--
Laurent.

Bug#972335: i3lock: Cannot read image from pipe

[Cédric Hannotier]

Dear sur5r,

On Sun, 18 Oct 2020 18:53:50 + Jakob Haufe  wrote:
> Seems I completely missed this. Will take care of it in the next few
> days.

Do you have any update regarding this issue?

-- 

Cédric Hannotier

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

[Pierre-Elliott Bécue]

Le vendredi 06 novembre 2020 à 04:22:15-0800, Felix Lechner a écrit :
> Hi Pierre-Elliott,
> 
> On Fri, Nov 6, 2020 at 2:40 AM Pierre-Elliott Bécue  wrote:
> >
> > I could not help but have a concern reading your reply. It feels to me
> > that you could have the intent to move the *production* lintian site out
> > of Debian's machines. Of course I could understand that a *test* version
> > of lintian.debian.org would be hosted somewhere else. But I (and I'm
> > probably not alone) would have a really hard time understanding or
> > accepting that the production version moved outside of debian.org and on
> > a non-controlled Debian machine.
> >
> > Lintian is debian-centric, and its checks have influence on many parts
> > of the infra. To me it needs to stay in Debian for the production part.
> >
> > I hope you understand that.
> 
> I do not.
> 
> Like so many communications in Debian recently, I actually find your
> tone inappropriate for a technical project.

A technical project consisting of people who may have opinions, even
some based on non-very-technical aspects.

> What is the purpose of your message? Do you hope to guilt-trip me into
> using DSA infrastructure? Had we not had friendly interactions in the
> past, I might think your note came out of a mafia movie.

Because I made an assumption on your intents and tried to tell you
something you don't want to hear, which is that it should stay in Debian
infra? Come on, you should accept the idea that other people has
different opinions than yours and have a right to state these. The
"it's not technical" argument is not a valid answer.

> Perhaps you are making me a proposal I cannot refuse?

I'm stating my opinion, and you'll have to deal with the fact that many
people in the project do that. The fact that you are working on a
project does not mean others can't express concerns and raise their
voice if they think the decisions you seem to be willing to take are
bad. I'm not coercing you and the way you represent it is your sole
interpretation, which is a bit scary.

> My planned improvements are driven solely by technical concerns. (Your
> message mentions none.)

I don't have to mention technical concerns to have a right to feel
ill-at-ease with the idea of seeing lintian.debian.org disappear in
favour of an externally hosted service. But actually, "it's
Debian-centric and used by core components, so it's better having it
in our infrastructure" also is a technical concern.

> I am still working on the new website and am not really ready to
> explain my proposed changes.

This is what I call a test version.

> For now, it should be sufficient to say that DSA is unable to deliver
> on several key aspects of my envisioned changes. For example, DSA is
> unable to automatically install newly released versions of Lintian, or
> its prerequisites.

DSA delivers machines, what you do of these is your call. See
nm.debian.org, which is auto-deployed when we release on master et al.

> That alone led to a string of extraordinarily frequent, error-prone
> and entirely unnecessary interactions on rt.debian.org. A prominent
> DSA member's response: "It's easier that way, for you and for us." At
> some point, DSA also told me I made changes to their systems too
> frequently. Nice solution!
>
> At some point, I tried to share my vision of a real-time system that
> can browse tags online. The response: "There is a trend toward static
> pages at Debian." 

Surely, that excludes tracker.debian.org, wiki.debian.org,
nm.debian.org, ddpo.debian.org, udd.debian.org, …

> As far as I can tell, DSA and I live on two
> different planets—which, to be fair, is not an unusual feeling from my
> perspective in California's Silicon Valley.

I can't see how and why DSA would forbid you to have a new website set
in production on lintian.debian.org, and if they do, that's probably
something worth a discussion on debian-devel to have things explained
and understood, don't you think?

> In any event, I do not control the domain lintian.d.o, so whatever I
> am working on will remain a test version unless people decide it works
> better. That should be the goal. I do not understand how your message
> did anything to make Lintian, or Debian, better.

Just because you feel hurt by the fact someone tries to tell you you
should reconsider an idea doesn't mean their opinion or suggestion is
moot. I'm sorry if you're feeling hurt, but I stand my point. As soon as
your new site is working, I'd rather try to have it set in prod on
lintian.debian.org than making central elements point to an external
component. And I'd be happy to help and support you that way.

That'd at least allow others to take care of it if one day you feel
tired of the project, without having to restart everything from scratch.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#973880: krb5: CVE-2020-28196

[Salvatore Bonaccorso]

Source: krb5
Version: 1.17-10
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.17-3

Hi,

The following vulnerability was published for krb5.

CVE-2020-28196[0]:
| MIT Kerberos 5 (aka krb5) before 1.17.2 and 1.18.x before 1.18.3
| allows unbounded recursion via an ASN.1-encoded Kerberos message
| because the lib/krb5/asn.1/asn1_encode.c support for BER indefinite
| lengths lacks a recursion limit.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-28196
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28196
[1] https://github.com/krb5/krb5/commit/57415dda6cf04e73ffc3723be518eddfae599bfd

Regards,
Salvatore

Bug#972769: Still fine in unstable

[Jonathan McDowell]

Control: severity -1 important
Control: tag -1 pending

This is still building fine with the python3-defaults in unstable so
doesn't warrant the serious severity. Upstream has a minor fix to enable
Python3.9 which I will pull in.

J.

-- 
/-\ | 101 things you can't have too much
|@/  Debian GNU/Linux Developer |   of : 18 - Roleplaying.
\-  |

Bug#973878: libmaxminddb: CVE-2020-28241

[Salvatore Bonaccorso]

Source: libmaxminddb
Version: 1.3.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/maxmind/libmaxminddb/issues/236
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libmaxminddb.

CVE-2020-28241[0]:
| libmaxminddb before 1.4.3 has a heap-based buffer over-read in
| dump_entry_data_list in maxminddb.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-28241
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28241
[1] https://github.com/maxmind/libmaxminddb/issues/236
[2] https://github.com/maxmind/libmaxminddb/pull/237

Regards,
Salvatore

Bug#973879: linux: Select SND_SOC_SOF_TIGERLAKE_SUPPORT to support current hardware

[Paul Menzel]

Package: src:linux
Version: 5.9.1-1
Severity: normal

Dear Debian folks,


Debian’s Linux kernel misses the sound drivers for Intel Tiger Lake, 
probably causing issues with the microphone [1].


It’d be awesome, if you configured the Linux kernel with 
`SND_SOC_SOF_TIGERLAKE_SUPPORT` selected.



Kind regards,

Paul


[1]: https://bugzilla.kernel.org/show_bug.cgi?id=210045

Bug#973877: tcpdump: CVE-2020-8037

[Salvatore Bonaccorso]

Source: tcpdump
Version: 4.9.3-6
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 4.9.3-1~deb10u1

Hi,

The following vulnerability was published for tcpdump.

CVE-2020-8037[0]:
| The ppp decapsulator in tcpdump 4.9.3 can be convinced to allocate a
| large amount of memory.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8037
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8037
[1] 
https://github.com/the-tcpdump-group/tcpdump/commit/32027e199368dad9508965aae8cd8de5b6ab5231

Regards,
Salvatore

Bug#973854: debian/patches/i386_loosen_test_tolerances.patch not Multi-Arch safe

[Rebecca N. Palmer]

Control: severity -1 minor
Control: retitle -1 imperfect/non-upstreamable architecture detection

The sys.maxsize check should catch amd64 vs i386; the directory check is 
mostly to catch other-32-bit vs i386.  All this patch does is allow more 
rounding error in some tests (because i386 registers and memory are 
different precisions), so a wrong detection should be mostly harmless.


sysconfig.get_platform() / platform.uname() aren't chroot-safe, which 
for a tests-only patch in Debian infrastructure, is probably a worse 
problem:


(i386 chroot on amd64)
>>> import sys;import sysconfig;import platform
>>> sys.maxsize
2147483647
>>> platform.uname()
uname_result(system='Linux', node='rnpalmer-laptop', 
release='4.19.0-12-amd64', version='#1 SMP Debian 4.19.152-1 
(2020-10-18)', machine='x86_64', processor='')

>>> sys.platform
'linux'
>>> sysconfig.get_platform()
'linux-x86_64'
>>> import struct;struct.calcsize("P")
4

I would welcome better (and preferably upstreamable) ways of determining 
architecture from Python if they actually exist.  pandas/statsmodels 
have several patches that amount to "$feature is broken on $arch - xfail 
its tests and warn on use".

Bug#971644: [elogind/elogind] System crashed on suspend/hibernate failure (#177)

[Mark Hindley]

Thorsten,

On Fri, Nov 06, 2020 at 12:03:36AM -0800, Sven Eden wrote:
>However, the behavior reported when the user hit the Hibernate key is
>absolutely unsuspected.
>"PM: Image not found (code -22)" sounds like the kernel tried to
>hibernate, but whatever was configured, or deemed to be the right place
>to write into was not available.
> 
>The question I have is:
>What is the outcome of cat /proc/swaps ?

Can you provide the content of /proc/swaps please.

Thanks

Mark

Bug#972473: RFS: ipcalc-ng/1.0.0-1 -- parameter calculator for IPv4 and IPv6 addresses

[Fabio Augusto De Muzio Tobich]

Em 06/11/2020 04:34, Adrian Bunk escreveu:
> Control: tags -1 moreinfo
> 
> On Sun, Oct 18, 2020 at 08:25:11PM -0300, Fabio Augusto De Muzio Tobich wrote:
>> ...
>> Changes since the last upload:
>>
>>  ipcalc-ng (1.0.0-1) unstable; urgency=medium
>> ...
>>* debian/manpage/ipcalc-ng.1: added to provide a manpage generated from 
>> the
>>  upstream markdown file with a bug free ronn.
>> ...
>>- 030_do-not-use-upstream-manpage.patch: created to not generate the
>>  manpage from the upstream markdown file.
>> ...
> 
> It would be better to get ronn in Debian fixed.
> Is the problem #964322 or a different issue?
> 

It's #964322 the problem, yes.
Since it was fixed upstream I figure will be fixed in Debian as well in a near
future.

Also the new ipcalc-ng version does not bring anything critical, so I guess this
can wait.
I'll be removing the package from mentors and closing this RFS, will get back
here when this manpage situation is fixed.


>> Regards,
> 
> cu
> Adrian
> 

Thanks.

-- 
⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄  GPG:rsa4096/7EF63B2E

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

[Felix Lechner]

Hi Pierre-Elliott,

On Fri, Nov 6, 2020 at 2:40 AM Pierre-Elliott Bécue  wrote:
>
> I could not help but have a concern reading your reply. It feels to me
> that you could have the intent to move the *production* lintian site out
> of Debian's machines. Of course I could understand that a *test* version
> of lintian.debian.org would be hosted somewhere else. But I (and I'm
> probably not alone) would have a really hard time understanding or
> accepting that the production version moved outside of debian.org and on
> a non-controlled Debian machine.
>
> Lintian is debian-centric, and its checks have influence on many parts
> of the infra. To me it needs to stay in Debian for the production part.
>
> I hope you understand that.

I do not.

Like so many communications in Debian recently, I actually find your
tone inappropriate for a technical project. What is the purpose of
your message? Do you hope to guilt-trip me into using DSA
infrastructure? Had we not had friendly interactions in the past, I
might think your note came out of a mafia movie. Perhaps you are
making me a proposal I cannot refuse?

My planned improvements are driven solely by technical concerns. (Your
message mentions none.) I am still working on the new website and am
not really ready to explain my proposed changes. For now, it should be
sufficient to say that DSA is unable to deliver on several key aspects
of my envisioned changes. For example, DSA is unable to automatically
install newly released versions of Lintian, or its prerequisites.

That alone led to a string of extraordinarily frequent, error-prone
and entirely unnecessary interactions on rt.debian.org. A prominent
DSA member's response: "It's easier that way, for you and for us." At
some point, DSA also told me I made changes to their systems too
frequently. Nice solution!

At some point, I tried to share my vision of a real-time system that
can browse tags online. The response: "There is a trend toward static
pages at Debian." As far as I can tell, DSA and I live on two
different planets—which, to be fair, is not an unusual feeling from my
perspective in California's Silicon Valley.

In any event, I do not control the domain lintian.d.o, so whatever I
am working on will remain a test version unless people decide it works
better. That should be the goal. I do not understand how your message
did anything to make Lintian, or Debian, better.

Kind regards
Felix Lechner

Bug#973844: RFA: tar

[Janos LENART]

Hi Bdale,

Thanks for looking after tar for 25 years :-O

I would like to adopt & maintain tar. I am using some of the 'newer'
features at many sites that the current bugs are about, like remote
archives, zstd and incremental; also well versed in C. I have been a DD
since 2000.

Looking at the list of bugs I am thinking most of them should be forwarded
to upstream. There are some low hanging fruits like #892273, and there are
good few that will be wontfix like #310323 .

Can I fix for example #892273 and upload a new version, or did you have
something else in mind?
Am I assuming correctly that https://salsa.debian.org/debian/tar.git is up
to date? :-)

Regards,
-- 
LÉNÁRT, János

Bug#972250: vienna-rna binaries upload

[Graham Inggs]

Hi Olivier

On Fri, 6 Nov 2020 at 10:06, olivier sallou  wrote:
> andreas, thanks for binaries upload, but I do not see on tracker any 
> upload/change, is it expected?

I believe that is normal.  You can confirm with rmadison that the
binaries are present in unstable.

> Graham, if binaries have been uploaded why do you set bug level back to 
> serious? Should not be an issue anymore (but my action to allow for autobuild 
> for further uploads)

I didn't.  I've always found that message hard to read, the 'to' is
before the 'from'.

Severity set to 'normal' from 'serious' Request was from Graham Inggs

Regards
Graham

Bug#933000: resolv.conf(5): refers to MAXNS in , but it's in res_state.h now

[Michael Kerrisk (man-pages)]

tags 933000 wontfix
thanks

Upstream maintainer here. As I previously explained, this is not a
valid bug report, and should be closed.

Bug#909789: manpages-dev: stat(2) manpage on ENOENT for dangling symbolic links (broken links)

[Michael Kerrisk (man-pages)]

tags 909789 fixed-upstream
thanks



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Bug#973858: chromium: Outdated version, more than 100 open security issues

[Peter Gervai]

Package: chromium
Version: 84.0.4147.105-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Versions in Debian, even that in experimental have 100+ open unfixed CVE listed 
in the tracker.
https://security-tracker.debian.org/tracker/source-package/chromium
Many of those are just a few days old.

This is related to bug#973848 but underlines the security side importance.

Thanks.

Bug#969372: uwsgi-emperor: SysV init script does nothing

[Sam]

Hi there

I encounter the exact same behaviour with:

/etc/debian_version: bullseye/sid

dpkg -l | grep uwsgi:
ii  uwsgi-core2.0.19.1-3+b1  amd64  
  fast, self-healing application container server (core)
ii  uwsgi-emperor 2.0.19.1-3+b1  amd64  
  fast, self-healing application container server (emperor scripts)
ii  uwsgi-plugin-python3  2.0.19.1-3+b1  amd64  
  WSGI plugin for uWSGI (Python 3)

changes in /etc/uwsgi-emperor/emperor.ini:

+ emperor-on-demand-directory = /var/uwsgi

Sam


Quoting Vlastimil Zima (2020-11-06 15:36:47)
> Package: uwsgi-emperor
> Version: 2.0.19.1-3+b1
> Followup-For: Bug #969372
> 
> Hi Thomas,
> 
> indeed, I have a number of vassals configured, actually I use emperor
> for web development for several years now.
> 
> At first, I noticed that the emperor haven't start after reboot.
> I have tried to start it with systemd, but with no success. Systemd
> only reports the process as "started" but it's not running
> (`ps -ef | grep uwsgi`).
> 
> 
> Here's a relevant output of terminal commands:
> 
> $ sudo service uwsgi-emperor start
> $ sudo service uwsgi-emperor status
> ● uwsgi-emperor.service - LSB: Start/stop uWSGI server instance(s)
>  Loaded: loaded (/etc/init.d/uwsgi-emperor; generated)
>  Active: active (exited) since Fri 2020-11-06 09:23:17 CET; 1s ago
>Docs: man:systemd-sysv-generator(8)
> Process: 889151 ExecStart=/etc/init.d/uwsgi-emperor start (code=exited, 
> status=0/SUCCESS)
> 
> Nov 06 09:23:17 queeg-500 systemd[1]: Starting LSB: Start/stop uWSGI server 
> instance(s)...
> Nov 06 09:23:17 queeg-500 systemd[1]: Started LSB: Start/stop uWSGI server 
> instance(s).
> $ ps -ef | grep uwsgi
> vzima 889177  887414  0 09:23 pts/500:00:00 grep uwsgi
> 
> 
> Despite this, I can start the emperor manually using command composed on 
> /etc/init.d/uwsgi-emperor:
> 
> $ sudo /usr/bin/uwsgi --ini /etc/uwsgi-emperor/emperor.ini --die-on-term 
> --pidfile /run/uwsgi-emperor.pid --daemonize /var/log/uwsgi/emperor.log
> 
> I also encounter the PID file bug 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934731,
> so I need to delete PID file manually.
> 
> Regards,
> 
> Vlastimil Zíma
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (90, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages uwsgi-emperor depends on:
> ii  uwsgi-core  2.0.19.1-3+b1
> 
> uwsgi-emperor recommends no packages.
> 
> uwsgi-emperor suggests no packages.
> 
> -- Configuration Files:
> /etc/uwsgi-emperor/emperor.ini changed:
> [uwsgi]
> master = true
> workers = 2
> no-orphans = true
> log-date = true
> uid = www-data
> gid = www-data
> emperor = /etc/uwsgi-emperor/vassals
> emperor-tyrant = true
> cap = setgid,setuid
> 
> 
> -- no debconf information


signature.asc
Description: signature

Bug#973862: Crosslinking

[Geert Stappers]

Subject says all  :-)
https://bugs.debian.org/973862
https://bugs.debian.org/973865