Bug#972250: autobuild request sent

[olivier sallou]

I just asked to allow for package autobuild, waiting for answer

If accepted will check for builds, else upload with binaries

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#966416: Bug#973714: Depends on argyll which is going away

[Moritz Muehlenhoff]

reopen 966416
thx

On Fri, Nov 06, 2020 at 08:03:37AM +0100, Christian Marillat wrote:
> On 03 nov. 2020 19:34, Moritz Muehlenhoff  wrote:
> 
> > Package: displaycal
> > Severity: serious
> >
> > argyll is filed for removal from the archive (#966416), but displaycal
> > depends on it.
> 
> I'm closing this bug and #966416 as bug #957008 as been fixed in argyll
> 2.0.1+repack-1.1

966416 was a RoM (Request of maintainer), if the current maintainer wants to
get argyll removed, then you should adopt it instead or make a QA upload, but
you can't simply do an NMU and override the maintainer's request.

Reopening until Jörg has had a chance to comment.

Cheers,
Moritz

Bug#972250: vienna-rna binaries upload

[olivier sallou]

Hi,
andreas, thanks for binaries upload, but I do not see on tracker any
upload/change, is it expected?

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)

thanks

Olivier

Bug#973472: fetchmail: Fails to connect using SSL

[Michal Palenik]

On Mon, 2 Nov 2020 10:34:35 +0100 Timo van Roermund  
wrote:
> On Sun, 01 Nov 2020 14:25:03 -0800 Bill Wohler  wrote:
> 
>  > Thanks for explaining the situation. Sounds like just some bad luck.
>  > Even so, it would still be good if a mechanism could be created that
>  > would prevent this from happening in the future.
> 
> Yes, some mechanism to prevent this would be good. I only noticed this 
> issue after approximately two days and therefore received some e-mails 
> (too) late.
> 
>  > I appreciate your sending the link to the prior package. It made it much
>  > easier to go back, and now my mail is flowing again.. I've also held the
>  > package until I see an OpenSSL update.
> 
> I took a different approach and upgraded the openssl and libssl1.1 
> packages to version 1.1.1h-1 (from unstable). I did so because I am not 
> affected by any of the regressions listed at the oppenssl package 
> tracker (https://tracker.debian.org/pkg/openssl). With this approach, I 
> don't need to take any further manual actions later on (to unhold the 
> package).

for those stumbling on this via searching, the workaround mentioned
above is:

create priority for testing:
/etc/apt/apt.conf.d/default-release
with
APT::Default-Release "testing";

add into sources (with your favourite mirror):
deb http://ftp.debian.sk/debian/ unstable main contrib non-free

apt update

and reinstall 
apt -t unstable install libssl1.1:amd64


-- 
Michal Páleník

Bug#971171: MP up

[Christian Ehrhardt]

To help integrating these I have opened
https://salsa.debian.org/libvirt-team/libvirt-dbus/-/merge_requests/4

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#973860: ITP: callaudiod -- Call audio routing daemon

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: Guido Günther 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-on-mobile-maintain...@alioth-lists.debian.net

* Package name: callaudiod
  Version : 0.0.4
  Upstream Author : Arnaud Ferraris 
* URL : https://gitlab.com/mobian1/callaudiod/
* License : LGPL-2.1-or-later (lib) , GPL-3.0-or-later (daemon)
  Programming Lang: C
  Description : Call audio routing daemon

callaudiod is a daemon for dealing with audio routing during phone calls.
It provides a D-Bus interface allowing other programs to:
   * switch audio profiles
   * output audio to the speaker or back to its original port
   * mute the microphone

Besides the daemon it also ships a shared library to ease interaction
with the daemon.

Bug#973861: apt: http acquire method still failing with "Undetermined error" or "Data left in the buffer"

[Raphaël Hertzog]

Package: apt
Version: 2.1.11
Severity: important
User: de...@kali.org
Usertags: origin-kali

Hello,

while the frequence of the error has really decreased since the last set
of fixes, we still have occasional failures where apt ends
up with "Undetermined error" or "Data left in the buffer".

It's pretty annoying for APT to be unreliable in that way.

The last case that triggered this bug for us in Kali was within a net-install
in d-i:

[...]
Nov  5 23:15:48 in-target: Err:2130 http://kali.download/kali kali-rolling/main 
amd64 llvm-10 amd64 1:10.0.1-6
Nov  5 23:15:48 in-target:   Undetermined Error [IP: 104.18.102.100 80]
[...]
Nov  5 23:16:14 in-target: Fetched 2,651 MB in 5min 20s (8,274 kB/s)
Nov  5 23:16:14 in-target: E: Failed to fetch 
http://kali.download/kali/pool/main/l/llvm-toolchain-10/llvm-10_10.0.1-6_amd64.deb
  Undetermined Error [IP: 104.18.102.100 80]
Nov  5 23:16:14 in-target: E: Unable to fetch some archives, maybe run apt-get 
update or try with --fix-missing?
Nov  5 23:16:14 in-target: tasksel: apt-get failed (100)

To try to reproduce it I invite you to configure a sources.lists with
kali.download as mirror. Do this on a server with a very good connection.

deb http://kali.download/kali kali-rolling main contrib non-free

And try to run this in a loop until you reproduce it:
# apt --download-only install kali-linux-large
# apt clean

It took me two tries to reproduce it... I had a download rate of more than
50MB/s.

I tried to reproduce it with debugging options enabled:
# while true; do apt -y --download-only install kali-linux-large -o 
Debug::Acquire::http=true -o Debug::pkgAcquire::Worker=true 2>log || break; apt 
clean; done

And I managed to reproduce it too but after a dozen of tries this time.
The log file is huge but it failed with this:
E: Failed to fetch 
http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb
  Undetermined Error [IP: 104.18.102.100 80]

And here are the lines that seem relevant for that specific file:

 -> 
http:600%20URI%20Acquire%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aFilename:%20/var/cache/apt/archives/partial/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aExpected-SHA256:%202347b5fd2bb741cf87f01b4243e591d094445227bea63de5d53555752b322a45%0aExpected-SHA1:%20c465af27c6a567320661436f509043587735f996%0aExpected-MD5Sum:%206d11858477ba16d6b2ffb2d518dd2735%0aExpected-Checksum-FileSize:%20300172%0aTarget-Repo-URI:%20http://kali.download/kali/%0aTarget-Site:%20http://kali.download/kali%0aTarget-Release:%20kali-rolling%0aTarget-Base-URI:%20http://kali.download/kali/%0aTarget-Component:%20main%0aTarget-Codename:%20kali-rolling%0aTarget-Suite:%20kali-rolling%0aTarget-Architecture:%20all%0aTarget-Type:%20deb%0a%0a
 <- 
http:102%20Status%0aURI:%20http://kali.download/kali/pool/main/x/xorg-sgml-doctools/xorg-sgml-doctools_1.11-1_all.deb%0aMessage:%20Waiting%20for%20headers
GET /kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0%2bdfsg1-5_all.deb 
HTTP/1.1^M
Host: kali.download^M
User-Agent: Debian APT-HTTP/1.3 (2.1.11)^M
^M
[...]
 <- 
http:102%20Status%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aMessage:%20Waiting%20for%20headers
GET 
/kali/pool/main/i/imagemagick/libmagickcore-6.q16-6-extra_6.9.11.24%2bdfsg-1%2bb1_amd64.deb
 HTTP/1.1^M
Host: kali.download^M
User-Agent: Debian APT-HTTP/1.3 (2.1.11)^M
^M

Answer for: 
http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb
HTTP/1.1 200 OK^M
Date: Fri, 06 Nov 2020 08:10:09 GMT^M
Content-Type: application/octet-stream^M
Content-Length: 300172^M
Connection: close^M
Set-Cookie: __cfduid=dcd44a60d11f41fb354d70f7609be4f1a1604650209; expires=Sun, 
06-Dec-20 08:10:09 GMT; path=/; domain=.kali.download; HttpOnly; SameSite=Lax^M
Last-Modified: Sun, 29 Dec 2019 15:40:32 GMT^M
ETag: "5e08c8f0-4948c"^M
Expires: Mon, 04 Nov 2030 08:10:09 GMT^M
Cache-Control: public, max-age=31536^M
CF-Cache-Status: HIT^M
Age: 264899^M
Accept-Ranges: bytes^M
cf-request-id: 063e342a5da30f222e81^M
Server: cloudflare^M
CF-RAY: 5edd5623cfbda30f-ORD^M
^M
 <- 
http:200%20URI%20Start%0aLast-Modified:%20Sun,%2029%20Dec%202019%2015:40:32%20+%0aSize:%20300172%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb
 <- 
http:400%20URI%20Failure%0aTransient-Failure:%20true%0aMessage:%20Undetermined%20Error%20[IP:%20104.18.102.100%2080]%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb
 -> 
http:600%20URI%20Acquire%0aURI:%20http://kali.download/kali/pool/main/libn/libnet-smtp-ssl-perl/libnet-smtp-ssl-perl_1.04-1_all.deb%0aFilename:%20/var/cache/apt/archives/partial/libnet-smtp-ssl-perl_1.04-1_all.deb%0aExpected-SHA256:%20cf23f2c340b048177ef3060644ec759a9002932f8c97889089d741723f8ada6c%0aExpected-SHA1:%20b02e232125c7a35b665bfeeacc2691646aeda44d%0aExp

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

[Vlastimil Zima]

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

Bug#973860: ITP: callaudiod -- Call audio routing daemon

[Holger Levsen]

Hi Guido,

On Fri, Nov 06, 2020 at 09:13:40AM +0100, Guido Günther wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Guido Günther 
> * Package name: callaudiod
>   Version : 0.0.4
>   Upstream Author : Arnaud Ferraris 

this seems to be a duplicate of #973841 filed by Arnaud (cc:ed) himself...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


signature.asc
Description: PGP signature

Bug#973862: RFS: dhcpdump/1.8-2.2 [ITA] -- Parse DHCP packets from tcpdump

[Peter Ji]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: dhcpdump
   Version : 1.8-3
   Upstream Author : Edwin Groothuis 
 * URL : https://github.com/huiji12321/dhcpdump
 * License: BSD-4-Clause-UC
 * Vcs : https://github.com/huiji12321/dhcpdump
   Section : admin

It builds those binary packages:

  dhcpdump - Capture dhcp-packets and show for easier checking and debugging

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dhcpdump/dhcpdump_1.8-3.dsc

Changes since the last upload:

 dhcpdump (1.8-3) unstable; urgency=low
 .
   * New-maintainer upload. (Closes: #934419)
   * Fix the manpage,dhcpdump does not parse the output of tcpdump
 but analyze and display it. (Closes:647228)

Regards,
--
  Peter_Ji

Bug#973860: ITP: callaudiod -- Call audio routing daemon

[Guido Günther]

Hi,
On Fri, Nov 06, 2020 at 08:47:01AM +, Holger Levsen wrote:
> Hi Guido,
> 
> On Fri, Nov 06, 2020 at 09:13:40AM +0100, Guido Günther wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Guido Günther 
> > * Package name: callaudiod
> >   Version : 0.0.4
> >   Upstream Author : Arnaud Ferraris 
> 
> this seems to be a duplicate of #973841 filed by Arnaud (cc:ed)
> himself...

Thanks, already spotted and merged.
 -- Guido
> 
> 
> -- 
> cheers,
>   Holger
> 
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
>  ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
>  ⠈⠳⣄
> 
> In Europe there are people prosecuted by courts because they saved other 
> people
> from drowning in the  Mediterranean Sea.  That is almost as absurd  as if 
> there
> were people being prosecuted because they save humans from drowning in the 
> sea.

Bug#973863: ITP: transit-java -- data format and a libraries for conveying values between applications

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: transit-java
  Version : 0.8.332
  Upstream Author : Tim Ewald 
* URL : https://github.com/cognitect/transit-java
* License : Apache-2.0
  Programming Lang: Java
  Description : data format and a libraries for conveying values between 
applications

 Transit is a data format and a set of libraries for conveying values between
 applications written in different languages. This library provides support
 for marshalling Transit data to/from Java.

Note: This is part of the long chain of dependencies for Pupppet 6

Bug#961534: Please "Recommend: stress-ng/stress"

[Axel Beckert]

Control: severity -1 serious
Control: found -1 1.0.2-1
Control: retitle -1 s-tui: Missing package relation with stress/stress-ng 
(Suggests or Recommends)

Hi,

Lee Garrett wrote:
> Please "Recommend: stress-ng/stress", as it enhances the features of
> s-tui.

Ran into that missing package relation, too. Missing package relations
are actually of RC severity as they are a policy violation. Hence
bumping the severity to serious.

> I'm also fine with a "Suggest" instead to avoid dragging in deps on
> standard systems.

In that case I'd definitely prefer Suggests, too, as I think nearly
nobody wants to have stress installed by default.

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

Bug#966416: Bug#973714: Depends on argyll which is going away

[Christian Marillat]

On 06 nov. 2020 09:02, Moritz Muehlenhoff  wrote:

[...]

> 966416 was a RoM (Request of maintainer), if the current maintainer wants to
> get argyll removed, then you should adopt it instead or make a QA upload, but
> you can't simply do an NMU and override the maintainer's request.
>
> Reopening until Jörg has had a chance to comment.

[I forgot to put a Cc to the bug report.]

I'm sorry I din't see the RoM and I don't want to adopt argyll again :

,
| argyll (1.5.1-5) unstable; urgency=low
| 
|   * Package orphaned. I don't intent to support the work of an agressive
| upstream author more longer and realy good luck for the next maintainer.
| 
|  -- Christian Marillat   Mon, 19 Aug 2013 14:18:29 +0200
`

Jörg why a RoM ? Why to not simply orphan this package ? Others people
are still using it.

Chirstian

Bug#973865: RFS: dhcpdump/1.8-3 [ITA] -- Capture dhcp-packets and show for easier checking and debugging

[Peter Ji]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: dhcpdump
   Version  : 1.8-3
   Upstream Author : Edwin Groothuis 
 * URL  : https://github.com/huiji12321/dhcpdump
 * License : BSD-4-Clause-UC
 * Vcs: https://github.com/huiji12321/dhcpdump
   Section  : admin

It builds those binary packages:

  dhcpdump - Capture dhcp-packets and show for easier checking and debugging

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dhcpdump/dhcpdump_1.8-3.dsc

Changes since the last upload:

 dhcpdump (1.8-3) unstable; urgency=low
 .
   * New-maintainer upload. (Closes: #934419)
   * Fix the manpage,dhcpdump does not parse the output of tcpdump
 but analyze and display it. (Closes: #647228)

Regards,
--
  Peter_Ji

Bug#973864: ITP: ruby-cose -- RFC 8152 CBOR Object Signing and Encryption (COSE)

[Pirate Praveen]

Package: wnpp
sevrrity: wishlist
owner: Pirate Praveen 

Packaging of https://rubygems.org/gems/cose

Dependency on gitlab 13.4.x

Bug#968045: golang-gonum-v1-plot: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> Source: golang-gonum-v1-plot
> Version: 0.7.0-2
> Tags: patch

Gentle ping on the above?


Regards,

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

Bug#973865: RFS: dhcpdump/1.8-3 [ITA] -- Capture dhcp-packets and show for easier checking and debugging

[Baptiste Beauplat]

Hi Peter,

On 11/6/20 10:09 AM, Peter Ji wrote:

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



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




Changes since the last upload:

  dhcpdump (1.8-3) unstable; urgency=low
  .
* New-maintainer upload. (Closes: #934419)
* Fix the manpage,dhcpdump does not parse the output of tcpdump
  but analyze and display it. (Closes: #647228)


Disclaimer, I am not a DD, this is just a quick review.

You have a number of easy to fix lintian tags. I'd recommend to fix them.

- I missing-vcs-browser-field
- I out-of-date-standards-version
- X debian-rules-uses-as-needed-linker-flag
- X upstream-metadata-file-is-missing
  You can use lintian-brush for that, it will generate a nice metadata
  file for you.
- P package-uses-old-debhelper-compat-version
- P silent-on-rules-requiring-root
- P trailing-whitespace
- P uses-debhelper-compat-file

--
Baptiste Beauplat - lyknode



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973654: TLS: start_SSL fails to set SSL_verifycn_name

[Sven Bartscher]

Hi,

Control: forwarded -1 https://gitlab.com/amavis/amavis/-/issues/72

Regards
Sven

Am 05.11.20 um 21:48 schrieb Brian May:
> Hello,
> 
> I received this bug report against amavisd-new in Debian.
> 
> For full details please see http://bugs.debian.org/

thank you, for forwarding the report to us! We copied it to our issue
tracker at Gitlab[1].

[1]: https://gitlab.com/amavis/amavis/-/issues

In the future, feel free to report bugs there instead of the mailing
list. This helps us to keep track of outstanding bugs and other issues.

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Bug#973654: TLS: start_SSL fails to set SSL_verifycn_name

[Brian May]

Sven Bartscher  writes:

> In the future, feel free to report bugs there instead of the mailing
> list. This helps us to keep track of outstanding bugs and other
> issues.

Thanks.

I looked here: https://www.ijs.si/software/amavisd/ but did not see any
reference to the gitlab page. I will keep a note of it for future.
-- 
Brian May 

Bug#973866: ITP: ruby-omniauth-atlassian-oauth2 -- Atlassian OAuth2 strategy for OmniAuth 1.x

[Pirate Praveen]

Package: wnpp
sevrrity: wishlist
owner: Pirate Praveen 

Packaging of https://rubygems.org/gems/omniauth-atlassian-oauth2

Dependency on gitlab 13.4.x

Bug#973867: pyresample: autopkgtest failure with pyproj 3.0.0

[Bas Couwenberg]

Source: pyresample
Version: 1.16.0+ds-2
Severity: serious
Tags: ftbfs
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The autopkgtest of your package fail with python-pyproj 3.0.0,
the log shows many issues like this:

 E   ModuleNotFoundError: No module named 'pyproj._proj'

https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pyresample/7973930/log.gz

Kind Regards,

Bas

Bug#972321: lttng-modules-dkms fails to build since 10.6

[daichi1.fukui]

Hi,

> The instrumentation of a writeback probe was modified in newer 4.19 kernels, a
> patch [1] to lttng-modules will be required to fix the build. I'll
> push a stable update
> but it might take a while to land in buster-updates.
Thanks for pushing a stable update.

> In the meantime, you can apply the patch locally or build the modules from the
> latest 2.10 release tarball which already includes the patch.
Yes, that will work as a workaround.

Best,
Fukui

Bug#973868: satpy: autopkgtest failure with pyproj 3.0.0

[Bas Couwenberg]

Source: satpy
Version: 0.23.0-1
Severity: serious
Tags: ftbfs
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The autopkgtest of your package fail with pyproj 3.0.0:

 === python3.9 ===
 satpy (unittest.loader._FailedTest) ... ERROR
 
 ==
 ERROR: satpy (unittest.loader._FailedTest)
 --
 ImportError: Failed to import test module: satpy
 Traceback (most recent call last):
   File "pyresample/ewa/_ll2cr.pyx", line 27, in pyresample.ewa._ll2cr
 ModuleNotFoundError: No module named 'pyproj._proj'
 
 During handling of the above exception, another exception occurred:
 
 Traceback (most recent call last):
   File "/usr/lib/python3.9/unittest/loader.py", line 154, in loadTestsFromName
 module = __import__(module_name)
   File "/usr/lib/python3/dist-packages/satpy/__init__.py", line 33, in 
 from satpy.readers import (find_files_and_readers,  # noqa
   File "/usr/lib/python3/dist-packages/satpy/readers/__init__.py", line 34, in 

 from .yaml_reader import (AbstractYAMLReader,
   File "/usr/lib/python3/dist-packages/satpy/readers/yaml_reader.py", line 41, 
in 
 from satpy.resample import get_area_def
   File "/usr/lib/python3/dist-packages/satpy/resample.py", line 144, in 

 from pyresample.ewa import fornav, ll2cr
   File "/usr/lib/python3/dist-packages/pyresample/ewa/__init__.py", line 72, 
in 
 from pyresample.ewa import _ll2cr, _fornav
   File "pyresample/ewa/_ll2cr.pyx", line 30, in init pyresample.ewa._ll2cr
 ModuleNotFoundError: No module named 'pyproj._proj'
 
 
 --
 Ran 1 test in 0.000s
 
 FAILED (errors=1)

https://ci.debian.net/data/autopkgtest/unstable/amd64/s/satpy/7973931/log.gz

Kind Regards,

Bas

Bug#973869: ark: Ark does not finish deferring links as unzip does when extracting zip files

[Iker Salmón San Millán]

Package: ark
Version: 4:20.08.1-1
Severity: important
X-Debbugs-Cc: iker...@gmail.com

Dear Maintainer,


Extracting zip files with ark I noticed this bug.

Steps to reproduce it:

Create a folder with any file and a link pointing to that file

Compress de folder with zip -y -r folder.zip foldername

Delete de folder

Extract de folder with unzip -> the link works

Delete de folder

Extract de folder with ark -> the link is not refered to the file


Thank you for your work.

P.D. I can provide a zip file if necessary.


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

Kernel: Linux 5.8.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=sh: 0: getcwd() failed: 
No such file or directory
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 ark depends on:
ii  kinit  5.74.0-2
ii  kio5.74.0-2
ii  libarchive13   3.4.3-2
ii  libc6  2.31-4
ii  libgcc-s1  10.2.0-15
ii  libkf5archive5 5.74.0-2
ii  libkf5completion5  5.74.0-2
ii  libkf5configcore5  5.74.0-2
ii  libkf5configgui5   5.74.0-2
ii  libkf5configwidgets5   5.74.0-2
ii  libkf5coreaddons5  5.74.0-2
ii  libkf5crash5   5.74.0-2
ii  libkf5dbusaddons5  5.74.0-2
ii  libkf5i18n55.74.0-3
ii  libkf5jobwidgets5  5.74.0-2
ii  libkf5kiocore5 5.74.0-2
ii  libkf5kiofilewidgets5  5.74.0-2
ii  libkf5kiogui5  5.74.0-2
ii  libkf5kiowidgets5  5.74.0-2
ii  libkf5parts5   5.74.0-2
ii  libkf5pty5 5.74.0-2
ii  libkf5service-bin  5.74.0-2
ii  libkf5service5 5.74.0-2
ii  libkf5widgetsaddons5   5.74.0-3
ii  libkf5xmlgui5  5.74.0-2
ii  libqt5core5a   5.14.2+dfsg-6
ii  libqt5dbus55.14.2+dfsg-6
ii  libqt5gui5 5.14.2+dfsg-6
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libstdc++6 10.2.0-15
ii  libzip41.7.3-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages ark recommends:
ii  bzip2   1.0.8-4
ii  p7zip-full  16.02+dfsg-8
ii  unar1.10.1-2+b6
ii  unzip   6.0-25
ii  zip 3.0-11+b1

Versions of packages ark suggests:
pn  rar 
pn  unrar | unrar-free  

-- no debconf information

Bug#973870: linux: Please consider enabling CONFIG_DEBUG_INFO_BTF

[Michael Prokop]

Package: linux
Version: 5.9.1-1
Severity: wishlist

Hi,

it would be great if Debian kernels could also enable the
CONFIG_DEBUG_INFO_BTF option, quoting from
http://www.brendangregg.com/blog/2020-11-04/bpf-co-re-btf-libbpf.html:

| CONFIG_DEBUG_INFO_BTF=y
|
| These new BPF binaries are only possible if this kernel config
| option is set. It adds about 1.5 Mbytes to the kernel image (this is
| tiny in comparison to DWARF debuginfo, which can be hundreds of
| Mbytes). Ubuntu 20.10 has already made this config option the
| default, and all other distros should follow. Note to distro
| maintainers: it requires pahole >= 1.16.

regards
-mika-

Bug#973871: gnustep-icons: invalid maintainer address

[Ansgar]

Source: gnustep-icons
Version: 1.0-8
Severity: serious
X-Debbugs-Cc: Gürkan Myczko , ba...@debian.org

The maintainer address is invalid, see bounce message below.

Three other packages also have the same invalid address: chess.app,
fontmanager.app and price.app.

Ansgar

On Wed, 2020-11-04 at 18:16 +, Mail Delivery System wrote:
> This message was created automatically by mail delivery software.
> 
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
> 
>   pkg-gnustep-maintain...@lists.debian.org
> host bendel.debian.org [2001:41b8:202:deb:216:36ff:fe40:4002]
> SMTP error from remote mail server after RCPT 
> TO::
> 550 5.1.1 :
> Recipient address rejected: User unknown in virtual alias table

Bug#973489: libvirt-daemon-system: upgrade overwrites generated file /etc/libvirt/qemu/networks/default.xml

[Guido Günther]

Hi,
On Sat, Oct 31, 2020 at 05:50:23PM +0100, Thorsten Glaser wrote:
> Package: libvirt-daemon-system
> Version: 6.8.0-1
> Severity: normal
> X-Debbugs-Cc: t...@mirbsd.de
> 
> I suspect this file should not have been a conffile, i.e. not
> shipped in /etc (but somewhere under /usr and copied to /etc
> during postinst).
> 
> NOTE: Migrating to _that_ setup is dangerous as well, see #971683
> for what can happen when done naïvely.
> 
> […]
> Preparing to unpack .../23-libvirt-daemon-system_6.8.0-1_amd64.deb ...
> Unpacking libvirt-daemon-system (6.8.0-1) over (6.6.0-2) ...
> […]
> Setting up libvirt-daemon (6.8.0-1) ...
> Setting up libvirt-daemon-driver-qemu (6.8.0-1) ...
> Setting up libvirt-daemon-system (6.8.0-1) ...
> Installing new version of config file 
> /etc/apparmor.d/abstractions/libvirt-qemu ...
> Installing new version of config file /etc/apparmor.d/usr.sbin.libvirtd ...
> Installing new version of config file /etc/libvirt/libvirtd.conf ...
> 
> Configuration file '/etc/libvirt/qemu/networks/default.xml'
>  ==> Modified (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
>   Z : start a shell to examine the situation
>  The default action is to keep your current version.
> *** default.xml (Y/I/N/O/D/Z) [default=N] ? d
> --- /etc/libvirt/qemu/networks/default.xml  2015-06-03 22:04:56.021794155 
> +0200
> +++ /etc/libvirt/qemu/networks/default.xml.dpkg-new 2020-10-01 
> 09:50:39.0 +0200
> @@ -1,16 +1,7 @@
> -
> -
>  
>default
> -  aaf572f9-67bf-4d32-9d39-ffca92ff9784
> -  
> -  
> -  
> +  
> +  
>
>  
>
> 
> Configuration file '/etc/libvirt/qemu/networks/default.xml'
>  ==> Modified (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
>   Z : start a shell to examine the situation
>  The default action is to keep your current version.
> *** default.xml (Y/I/N/O/D/Z) [default=N] ? _

Hmmm...it used to be in /etc since it was *not* autogenerated. Andrea
do you know if anything changed in that regard?
Cheers,
 -- Guido

Bug#973872: ITP: r-cran-bipartite -- GNU R visualising bipartite networks and calculating some (ecological)

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-bipartite -- GNU R visualising bipartite networks and 
calculating some (ecological)
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-bipartite
  Version : 2.15
  Upstream Author : Copyright: FIXME-2020 Carsten F. Dormann, Jochen Fruend and 
Bernd Gruber, with additional code from Stephen Beckett, Mariano Devoto, 
Gabriel Felix, Jose Iriondo, Tove Opsahl, Rafael Pinheiro, Rouven Strauss and 
Diego Vazquez, also based on C-code developed by Nils Bluethgen, Aaron 
Clauset/Rouven Strauss and Miguel Rodriguez-Girones
* URL : https://cran.r-project.org/package=bipartite
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R visualising bipartite networks and calculating some 
(ecological)
 Indices Functions to visualise webs and calculate a series of indices
 commonly used to describe pattern in (ecological) webs. It focuses on
 webs consisting of only two levels (bipartite), e.g. pollination webs or
 predator-prey-webs. Visualisation is important to get an idea of what
 users are actually looking at, while the indices summarise different
 aspects of the web's topology.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-bipartite

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

[Pierre-Elliott Bécue]

Le mercredi 28 octobre 2020 à 20:17:11-0700, Felix Lechner a écrit :
> Hi Paul,
> 
> On Wed, Oct 28, 2020 at 7:39 PM Paul Wise  wrote:
> >
> > Since most folks would only be interested in the lintian results for
> > the latest version in unstable, it would be nice if the middle click
> > could be eliminated using a symlink or redirect. An "all versions" link
> > could be added for folks who are interested in that.
> 
> We just found a hosting provider for our new dynamic web site. It will
> be an experiment for the time being, but is expected to bring this
> feature, as well as many others, based on queries in a Postgres
> database that is already installed there.

Hi Felix,

First of all, thanks for your work in lintian!

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.

Cheers!

-- 
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#973854: debian/patches/i386_loosen_test_tolerances.patch not Multi-Arch safe

[Matthias Klose]

On 11/6/20 9:35 AM, Rebecca N. Palmer wrote:
> 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:

no, you are using chroots in a wrong way.  You'll never see that e.g. on the
Debian porter boxes. Use linux32/setarch to enter the chroot.

schroot has the personality configuration for that.

> (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#960941: ofono-phonesim: Re-add ofono-phonesim as it is updated to use qt5

[Detlev Zundel]

Hi,

so I would also need this package to get my headset working on Debian
bullseye, but obviously the installation fails:

dzu@krikkit:~$ sudo apt install ofono-phonesim
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libqt5core5a : Breaks: libqtcore4 (< 4:4.8.7+dfsg-20~) but 
4:4.8.7+dfsg-18+deb10u1 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.
dzu@krikkit:~$

So I would really also like to see an updated package to get this
working.

Thanks in advance
  Detlev

-- 
Quantum physicists can either know how fast they do it, or where they
do it, but not both.

Bug#973873: Readd manpages-fr to task-french?

[Laurent Bigonville]

Package: task-french
Version: 3.59
Severity: normal

Hello,

The manpages-fr dependency was removed from task-french following bug #905634

Since then manpages-fr is now built from a new source package with a new
upstream. Last upload in debian is from the 1st of July 2020.

Maybe the dependency should be readded?

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages task-french depends on:
ii  tasksel  3.59

Versions of packages task-french recommends:
ii  aspell-fr   0.50-3-8
ii  ifrench-gut 1:1.0-32+b1
ii  util-linux-locales  2.36-3
ii  wfrench 1.2.6-1

task-french suggests no packages.

-- no debconf information

Bug#973874: network-manager: The Mobile Broadband connection does not show up in Network-Manager anymore

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

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

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

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-1
ii  libaudit11:2.8.5-3.1
ii  libbluetooth35.55-1
ii  libc62.31-4
ii  libcurl3-gnutls  7.72.0-1
ii  libglib2.0-0 2.66.2-1
ii  libgnutls30  3.6.15-4
ii  libjansson4  2.13.1-1
ii  libmm-glib0  1.14.6-0.1
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b2
ii  libnm0   1.27.91-1
ii  libpam-systemd   246.6-2
ii  libpsl5  0.21.0-1.1
ii  libreadline8 8.0-4
ii  libselinux1  3.1-2+b1
ii  libsystemd0  246.6-2
ii  libteamdctl0 1.31-1
ii  libudev1 246.6-2
ii  libuuid1 2.36-3+b2
ii  policykit-1  0.105-29
ii  udev 246.6-2
ii  wpasupplicant2:2.9.0-15

Versions of packages network-manager recommends:
ii  crda 4.14+git20191112.9856751-1
ii  dnsmasq-base [dnsmasq-base]  2.82-1
ii  iptables 1.8.5-3
ii  modemmanager 1.14.6-0.1
ii  ppp  2.4.7-2+4.1+deb10u1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1+b2
pn  libteam-utils

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no


-- no debconf information

Bug#973862: RFS: dhcpdump/1.8-2.2 [ITA] -- Parse DHCP packets from tcpdump

[Geert Stappers]

On Fri, Nov 06, 2020 at 04:16:12PM +0800, Peter Ji wrote:
> I am looking for a sponsor for package "dhcpdump":
> 
>  * URL : https://github.com/huiji12321/dhcpdump
> 
> Changes since the last upload:
> 
>  dhcpdump (1.8-3) unstable; urgency=low
>  .
>* New-maintainer upload. (Closes: #934419)
>* Fix the manpage,dhcpdump does not parse the output of tcpdump
>  but analyze and display it. (Closes:647228)
> 


In case it remains silence, contact me upcoming thursday.


Regards
Geert Stappers
Has another RFS queued
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

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

[Christopher 'm4z' Holm]

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_...
   ^
  In /usr/share/php/Horde/Db/Adapter/Pdo/Base.php on line 233

   1. Horde_Core_Bundle->migrateDb() /usr/bin/groupware-install:32
   2. Horde_Db_Migration_Migrator->up() /usr/share/php/Horde/Core/Bundle.php:107
   3. Horde_Db_Migration_Migrator->_doMigrate()
/usr/share/php/Horde/Db/Migration/Migrator.php:102
   4. Horde_Db_Migration_Base->migrate()
/usr/share/php/Horde/Db/Migration/Migrator.php:182
   5. KronolithUpgradeAutoIncrement->up()
/usr/share/php/Horde/Db/Migration/Base.php:121
   6. Horde_Db_Migration_Base->__call()
/usr/share/horde/kronolith/migration/2_kronolith_upgrade_autoincrement.php:22
   7. Horde_Db_Adapter_Base->__call()
/usr/share/php/Horde/Db/Migration/Base.php:86
   8. Horde_Db_Adapter_Postgresql_Schema->changeColumn()
/usr/share/php/Horde/Db/Adapter/Base.php:274
   9. Horde_Db_Adapter_Postgresql_Schema->resetPkSequence()
/usr/share/php/Horde/Db/Adapter/Postgresql/Schema.php:563
  10. Horde_Db_Adapter_Base_Schema->__call()
/usr/share/php/Horde/Db/Adapter/Postgresql/Schema.php:1067
  11. Horde_Db_Adapter_Pdo_Base->selectValue()
/usr/share/php/Horde/Db/Adapter/Base/Schema.php:166
  12. Horde_Db_Adapter_Pdo_Base->execute()
/usr/share/php/Horde/Db/Adapter/Pdo/Base.php:151
  13. Horde_Core_Bundle->migrateDb() /usr/bin/groupware-install:32
  14. Horde_Db_Migration_Migrator->up() /usr/share/php/Horde/Core/Bundle.php:107
  15. Horde_Db_Migration_Migrator->_doMigrate()
/usr/share/php/Horde/Db/Migration/Migrator.php:102
  16. Horde_Db_Migration_Base->migrate()
/usr/share/php/Horde/Db/Migration/Migrator.php:182
  17. KronolithUpgradeAutoIncrement->up()
/usr/share/php/Horde/Db/Migration/Base.php:121
  18. Horde_Db_Migration_Base->__call()
/usr/share/horde/kronolith/migration/2_kronolith_upgrade_autoincrement.php:22
  19. Horde_Db_Adapter_Base->__call()
/usr/share/php/Horde/Db/Migration/Base.php:86
  20. Horde_Db_Adapter_Postgresql_Schema->changeColumn()
/usr/share/php/Horde/Db/Adapter/Base.php:274
  21. Horde_Db_Adapter_Postgresql_Schema->resetPkSequence()
/usr/share/php/Horde/Db/Adapter/Postgresql/Schema.php:563
  22. Horde_Db_Adapter_Base_Schema->__call()
/usr/share/php/Horde/Db/Adapter/Postgresql/Schema.php:1067
  23. Horde_Db_Adapter_Pdo_Base->selectValue()
/usr/share/php/Horde/Db/Adapter/Base/Schema.php:166
  24. Horde_Db_Adapter_Pdo_Base->execute()
/usr/share/php/Horde/Db/Adapter/Pdo/Base.php:151
  25. PDO->query() /usr/share/php/Horde/Db/Adapter/Pdo/Base.php:233
-- >8 --

After applying the patch from https://github.com/horde/Db/pull/3/files
to /usr/share/php/Horde/Db/Adapter/Postgresql/Schema.php (belonging to
the package "php-horde-db", hence this bugreport), groupware-install
succeeds.


How to reproduce:

1. Prepare postgresql:
-- 8< --
# apt install postgresql postgresql-client
# su - postgres
> createuser --pwprompt horde
> createdb -O horde horde
(Test with:)
> psql -h localhost -d horde -U horde
-- >8 --

2. Install horde packages:
-- 8< --
# aptitude install php-horde-groupware php-pgsql
-- >8 --

3. Run groupware-install (as described in https://wiki.debian.org/Horde)
-- 8< --
# groupware-install

Installing Horde Groupware

Configuring database settings

What database backend should we use?
(false) [None]
(mysql) MySQL / PDO
(mysqli) MySQL (mysqli)
(oci8) Oracle
(pgsql) PostgreSQL
(sqlite) SQLite

Type your choice []: pgsql

Username to connect to the database as* [] horde
Password to connect with
How should we connect to the database?
(unix) UNIX Sockets
(tcp) TCP/IP

Type your choice [unix]: tcp

Database server/host* [] localhost

Port the DB is running on, if non-standard

Database name to use* [] horde

Internally used charset* [utf-8]
Split reads to a different server?
(false) Disabled
(true) Enabled

Type your choice [false]:
Should Horde log all queries. If selected, queries will 

Bug#973862: Crosslinking

[Geert Stappers]

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

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

[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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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  0x5

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

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#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#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#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#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#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#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#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#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#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#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],
+&nspace_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