Bug#962509: Not always boot arguments must include a root= parameter

[Richard Laager]

On Tue, 9 Jun 2020 01:25:58 +0200 kvaps  wrote:
> Package: initramfs-tools
> Version: 0.133+deb10u1
> 
> Hi, after the change introduced in f8ceeb90 both zfs and http booting
> methods are not working anymore, it stops on the message:
> 
> No root device specified. Boot arguments must include a root= parameter.

Please add "debug" to your kernel command line*, reboot, and send me a
copy of /run/initramfs/initramfs.debug.

* If you're not sure how to do this: When you see GRUB, hit "e" to stop
the timer and go into edit mode. Use the arrow keys to find the line
starting with "linux" and navigate to the end of it. Add "debug" (no
quotes). Press Ctrl-x or F10 to boot.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Bug#839382: RFS: elfio/3.7-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.7-1
  Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* 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.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Initially, the package was requested as a dependency of Apache Mesos.


Regards,
--
  Serge Lamikhov-Center

Bug#969357: squid-4.6: segfault for unknown reason

[Amos Jeffries]

Control: retitle -1 squid-4.6: segfault for unknown reason
Control: tags -1 + moreinfo

On Mon, 31 Aug 2020 23:45:28 -0400 js1 wrote:
> Package: squid
> Version: 4.6-1+deb10u4
> Severity: normal
> 
> Dear Maintainer,
> 
> Squid segfaults but seems usable.  No segfaults until this current version 
> (4.6-1+deb10u4). 
> 

Please install the debug symbols package (squid-dbgsym) and provide a
backtrace from your segfault if it occurs again.

Upstream provide details on how to obtain backtraces without downtime
from a running Squid proxy at
.


Amos

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

[Aurelien DESBRIERES]

I have not copied anything nor pip stuff from another environment.

On Mon, Sep 7, 2020 at 7:00 AM Florian Weimer  wrote:

> * Aurelien DESBRIERES:
>
> > This is emacs and jedi-mode and much more elisp stuff to works with
> > emacs as python3 ide.
> >
> > Please update this glibc it seems to be outdated!
>
> That's simply not going to happen for the buster release.
>
> You will have to change the way you set up your pip environment.
>

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

[Florian Weimer]

* Aurelien DESBRIERES:

> This is emacs and jedi-mode and much more elisp stuff to works with
> emacs as python3 ide.
>
> Please update this glibc it seems to be outdated!

That's simply not going to happen for the buster release.

You will have to change the way you set up your pip environment.

Bug#969527: dh-make: prepare for team maintenance

[Craig Small]

On Fri, 4 Sep 2020 at 20:18, Steffen Moeller  wrote:
> For team-maintained packages, my NAME  goes to the Uploaders line and 
> the team's mailing list is the maintainer.
>
> This is something I keep forgetting to adjust.
>
> Could dh_make please cater for team maintenance? Secondary to the maintenance 
> is that the path on salsa can be preset to
> https://salsa.debian.org/TEAMNAME-team/SOURCEPACKAGE
> which is something else that dh_make could do for me.
>
> I suggest to add a "-t TEAMNAME" argument.
As was already said, we cannot use -t as it is used for the templating option.

So let's look at the situations.
For a standard setup, the control file has a Maintainer line, there is
no Uploaders line and the changelog has the same maintainer address as
the control file.

For a team maintainership, it's the same except we need to make two
changes to the control file:
1) Maintainer line needs to be some "team email" or similar
2) Add Uploaders: line, by default the uploader would be whatever used
to be on the Maintainers line
That should be reasonably ok to add.

I don't think it's useful to be able to add multiple uploaders within
dh_make, for places that want to do that a lot you are better off with
overlay templates.

For the salsa URL, I can see that being a problem. For example, you
would need to specify both the teamname and the team email address and
possibly the team fullname for the email address.
That also assumes that team maintenance means a team salsa URL, which
often they are not. net-snmp uses a repository under debian. python is
close but you can also have:

Maintainer: Craig Small 
Uploaders: Debian Python Modules Team

Vcs-Browser: https://salsa.debian.org/python-team/modules/mastodon

Which is hard to do programmatically. You might notice that the
Maintainer and Uploader are flipped here. This happens in python
programs[1]

I think the only thing we could do here would be to add a maintainer
line on the command line.  To me for your specific needs an overlay
file would be better for you.

 - Craig

1: 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

[Aurelien DESBRIERES]

This is emacs and jedi-mode and much more elisp stuff to works with emacs
as python3 ide.

Please update this glibc it seems to be outdated!

Kind regards

Aurélien DESBRIÈRES

On Sun, Sep 6, 2020 at 9:43 PM Florian Weimer  wrote:

> * aurelien desbrieres:
>
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> >* What led up to the situation?
> >try to use jedi-mode on emacs
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >M-x jedi:install-server
> >* What was the outcome of this action?
> >deferred error : (error "Deferred process exited abnormally:
> >   command: /home/aurelien/.emacs.d/.python-environments/default/bin/pip
> >   exit status: exit 1
> >   event: exited abnormally with code 1
> >   buffer contents:
> \"/home/aurelien/.emacs.d/.python-environments/default/bin/python3:
> /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required
> by /home/aurelien/.emacs.d/.python-e\
> > nvironments/default/bin/python3)
> > \"")
>
> Have you copied the pip environment from another system?  You need to
> regenerate on this host.
>

Bug#969620: ITP: metakernel -- Jupyter kernel base class

[Joseph Nahmias]

Hi Gordon,

On Sun, Sep 06, 2020 at 06:23:09PM +, Gordon Ball wrote:
> > Happy to have co-maintainers and/or place it under the rubric of the Debian 
> > Python team.
> > 
> Glad to have more bits of the jupyter ecosystem available. I'd be
> willing to be listed as a co-maintainer/uploader for this package
> (context: I [co-]maintain some of the jupyter core libraries and
> notebook). I experimented with a personal build of this library (+
> octave_kernel) in the past, but my octave knowledge wasn't good enough
> to actually use it enough to be confident it was useful.
> 
> The core libraries are all team-maintained with the debian-python team;
> the R kernel (r-cran-irkernel) is also available, under pkg-r-team.

Great! I just finished my first draft of the first part of this --
packaging ipyparallel (dep of metakernel). I was wondering whether it was
more appropriate to have it under DPMT or PAPT, any suggestions on how to
classify one way or the other?

Also, I requested to join the debian-python team [DPMT/PAPT] so that I can
host the packaging on salsa. Is that something you can assist with?

Finally, would you be willing to review/sponsor at least my first few
packages?

Thanks in advance,
--Joe


signature.asc
Description: PGP signature

Bug#920065: O: dyndns -- dynamic DNS (DDNS) update client implemented in Perl

[Kaio Rafael]

just an update on this package.

DynDNS removed the free dynamic DNS service. To use the service now, one might 
need to create a new account and pay for the  DynDNS Pro as states below:

"
DynDNS Pro: Connect remotely to your DVR, webcam, computer and plenty of other 
devices for just $55.00 USD per year.
"

However, it seems they are still supporting legacy API requests such as Update 
[1] as it is made on the code.  Note that few parameters on the API are 
deprecated and ignored. 

Moreover, functionality to other services are not working:

"
NOTE: as of 2010, the support for sites of hnorg, noip is probably
non-working due to changes in the interfaces. Please use only dyndns
at this time.
"

Finally, Dyn recommends to use their own dynamic update client [2] or to use 
another Perl script for that matter: `ddclient` [3,4].  It seems `ddclient` is 
covering a wide range of Free/Non-free domains services and it is actively 
getting updates.

`ddclient` is already packaged in Debian and it supports legacy API updates as 
well called ‘dyndns1’ protocol.

IMHO, making efforts on `ddclient` package seems to make more sense than 
`dyndns`
Hope that helps.

Kaio,

[1] - https://help.dyn.com/remote-access-api/perform-update/
[2] - https://help.dyn.com/update-clients/
[3] - https://help.dyn.com/ddclient/
[4] - https://github.com/ddclient/ddclient
[5] - https://ddclient.net/protocols.html


On Mon, 21 Jan 2019 23:30:34 +0100 Tobias Frost  wrote:
> Package: wnpp
> 
> The current maintainer of dyndns, Jari Aalto ,
> is apparently not active anymore.  Therefore, I orphan this package now.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
> 
> If you want to be the new maintainer, please see
> https://www.debian.org/devel/wnpp/#howto-o for detailed
> instructions how to adopt a package properly.
> 
> Some information about this package:
> 
> Package: dyndns
> Binary: dyndns
> Version: 2016.1021-2
> Maintainer: Jari Aalto 
> Build-Depends: debhelper (>= 9)
> Architecture: all
> Standards-Version: 3.9.8
> Format: 3.0 (quilt)
> Files:
>  adcbbe3696b9253bec4f19661a0cab95 1833 dyndns_2016.1021-2.dsc
>  cb04dfca30f3ef2583602aa976f4f716 113458 dyndns_2016.1021.orig.tar.gz
>  ecc1cd183f5b1943868fa04a3fd69ec1 2412 dyndns_2016.1021-2.debian.tar.xz
> Vcs-Browser: https://anonscm.debian.org/gitweb/?p=collab-maint/dyndns.git
> Vcs-Git: https://anonscm.debian.org/git/collab-maint/dyndns.git
> Checksums-Sha256:
>  5440b5a70ace379b3ac96b6e42aeb2558814aae793d5ea0d2882012839f15762 1833 
> dyndns_2016.1021-2.dsc
>  a96c654ce6e4b2b548689908b6ef8862b824b3b91c61b2c727fba14c5c7a1f3f 113458 
> dyndns_2016.1021.orig.tar.gz
>  723077366e8ec5d12eaf0dd0da6239f98fd0c53e645e1e4cb5d905ebf8fb42b6 2412 
> dyndns_2016.1021-2.debian.tar.xz
> Homepage: https://github.com/jaalto/project--perl-dyndns
> Package-List: 
>  dyndns deb web optional arch=all
> Directory: pool/main/d/dyndns
> Priority: source
> Section: net
> 
> Package: dyndns
> Binary: dyndns
> Version: 2016.1021-2
> Maintainer: Jari Aalto 
> Build-Depends: debhelper (>= 9)
> Architecture: all
> Standards-Version: 3.9.8
> Format: 3.0 (quilt)
> Files:
>  adcbbe3696b9253bec4f19661a0cab95 1833 dyndns_2016.1021-2.dsc
>  cb04dfca30f3ef2583602aa976f4f716 113458 dyndns_2016.1021.orig.tar.gz
>  ecc1cd183f5b1943868fa04a3fd69ec1 2412 dyndns_2016.1021-2.debian.tar.xz
> Vcs-Browser: https://anonscm.debian.org/gitweb/?p=collab-maint/dyndns.git
> Vcs-Git: https://anonscm.debian.org/git/collab-maint/dyndns.git
> Checksums-Sha256:
>  5440b5a70ace379b3ac96b6e42aeb2558814aae793d5ea0d2882012839f15762 1833 
> dyndns_2016.1021-2.dsc
>  a96c654ce6e4b2b548689908b6ef8862b824b3b91c61b2c727fba14c5c7a1f3f 113458 
> dyndns_2016.1021.orig.tar.gz
>  723077366e8ec5d12eaf0dd0da6239f98fd0c53e645e1e4cb5d905ebf8fb42b6 2412 
> dyndns_2016.1021-2.debian.tar.xz
> Homepage: https://github.com/jaalto/project--perl-dyndns
> Package-List: 
>  dyndns deb web optional arch=all

Bug#964257: Correctly handle apostophes in English dictionaries

[Reuben Thomas]

Package: hunspell-en-us
Version: 1:2019.10.06-1
Followup-For: Bug #964257

It is worth noting that quotation marks are correctly handled by
hunspell-en-gb, which has a different source package
(libreoffice-dictionaries).

(I declare an interest as the upstream maintainer of the meta-spellchecker
Enchant, and as a contributor to Emacs’s ispell.el—as a result, I am getting
grief about this problem! :) )

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-42-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hunspell-en-us depends on:
ii  dictionaries-common  1.28.1

hunspell-en-us recommends no packages.

Versions of packages hunspell-en-us suggests:
ii  hunspell   1.7.0-2build2
pn  openoffice.org-hunspell | openoffice.org-core  

-- no debconf information

Bug#941712: hfs partitions corrupted when removing lots of files over network

[Graham Coster]

Hi Salvatore,

Thank you for following up on this.  Unfortunately I can no longer test
this out.  The hardware is no longer unavailable and since "upgrading" to
Catalina I can't get virtualbox running on my mac :(.

Given I can't test this out, would you like me to close the bug report?

Apologies, Graham.

On Sun, 6 Sep 2020 at 19:30, Salvatore Bonaccorso  wrote:

> Hi
>
> I assume the issue might be fixed with 25efb2ffdf99 ("hfsplus: fix
> crash and filesystem corruption when deleting files") which was
> included upstream in 5.7-rc1 and was backported to 4.19.116 as well.
>
> Can you please do check if the issue is still prsent in up to date
> buster?
>
> Regards,
> Salvatore
>

Bug#780123: CGI TimeOut issue fixed

[dcook]

This bug has been reported to the Apache httpd team and fixed as documented
at https://bz.apache.org/bugzilla/show_bug.cgi?id=64709. 

 

While it isn't part of an official release yet, I think that it will just be
a matter of time.

 

It's a fairly straightforward change to backport, although it does change
the behaviour of CGI scripts (ie it terminates them at TimeOut time rather
than leaving them for 2x the TimeOut time before terminating), so you may
not want to backport that change. 

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

Bug#602396: Long fixed

[Dylan Thurston]

close 602396
thanks

This bug has long since been fixed, in both stable and unstable
versions of okular.

Bug#969709: nvidia-modprobe: Notebook screen does not come up as nvidia-drm is removed

[ganomi]

Package: nvidia-modprobe
Version: 450.66-1
Severity: normal

Dear Maintainer,

Environment:
Thinkpad X1 Extreme Gen
GeForce GTX 1650 Mobile / Max-Q
4K OLED
Debian Sid

Issue:
My screen does not light up while sddm is loaded and running. This was always
working fine before. The issue was introduced with recent upgrade.
It seems that nvidia-drm is no longer loaded. Unfortunately X does not come up
on my notebook screen without having the nvidia-drm loaded.

X works on external monitor without nvidia-drm.

Workaround:
switch to console
modprobe nvdia-drm modeset=Y
systemctl restart sddm

sddm setting:
xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
xrandr --dpi 144

Observation:
/etc/nvidia-modprobe.conf unloads the nvidia-drm

Thanks,
Jiri





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

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

Versions of packages nvidia-modprobe depends on:
ii  libc6  2.31-3

nvidia-modprobe recommends no packages.

nvidia-modprobe suggests no packages.

-- no debconf information

Bug#969705: postgresql-common: package fails to install

[Nick]

Package: postgresql-common
Version: 200+deb10u3
Severity: normal

On a freshly installed system (an hour or so earlier), my attempt to
install postgresql-11 failed, apparently because postgresql-common
failed to install.  It went like so:

>>>
# apt-get install postgresql-11
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libpq5 libxslt1.1 postgresql-client-11 postgresql-client-common 
postgresql-common
  ssl-cert sysstat
Suggested packages:
  postgresql-doc-11 libjson-perl openssl-blacklist isag
The following NEW packages will be installed:
  libpq5 libxslt1.1 postgresql-11 postgresql-client-11 postgresql-client-common
  postgresql-common ssl-cert sysstat
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 16.8 MB of archives.
After this operation, 56.0 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian buster/main amd64 libpq5 amd64 
11.7-0+deb10u1 [166 kB]
Get:2 http://deb.debian.org/debian buster/main amd64 libxslt1.1 amd64 
1.1.32-2.2~deb10u1 [237 kB]
Get:3 http://deb.debian.org/debian buster/main amd64 postgresql-client-common 
all 200+deb10u3 [84.9 kB]
Get:4 http://deb.debian.org/debian buster/main amd64 postgresql-client-11 amd64 
11.7-0+deb10u1 [1,390 kB]
Get:5 http://deb.debian.org/debian buster/main amd64 ssl-cert all 1.0.39 [20.8 
kB]
Get:6 http://deb.debian.org/debian buster/main amd64 postgresql-common all 
200+deb10u3 [225 kB]
Get:7 http://deb.debian.org/debian buster/main amd64 postgresql-11 amd64 
11.7-0+deb10u1 [14.1 MB]
Get:8 http://deb.debian.org/debian buster/main amd64 sysstat amd64 12.0.3-2 
[562 kB]
Fetched 16.8 MB in 1min 4s (261 kB/s)
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
Preconfiguring packages ...
Selecting previously unselected package libpq5:amd64.
(Reading database ... 72864 files and directories currently installed.)
Preparing to unpack .../0-libpq5_11.7-0+deb10u1_amd64.deb ...
Unpacking libpq5:amd64 (11.7-0+deb10u1) ...
Selecting previously unselected package libxslt1.1:amd64.
Preparing to unpack .../1-libxslt1.1_1.1.32-2.2~deb10u1_amd64.deb ...
Unpacking libxslt1.1:amd64 (1.1.32-2.2~deb10u1) ...
Selecting previously unselected package postgresql-client-common.
Preparing to unpack .../2-postgresql-client-common_200+deb10u3_all.deb ...
Unpacking postgresql-client-common (200+deb10u3) ...
Selecting previously unselected package postgresql-client-11.
Preparing to unpack .../3-postgresql-client-11_11.7-0+deb10u1_amd64.deb ...
Unpacking postgresql-client-11 (11.7-0+deb10u1) ...
Selecting previously unselected package ssl-cert.
Preparing to unpack .../4-ssl-cert_1.0.39_all.deb ...
Unpacking ssl-cert (1.0.39) ...
Selecting previously unselected package postgresql-common.
Preparing to unpack .../5-postgresql-common_200+deb10u3_all.deb ...
Adding 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by 
postgresql-common'
Unpacking postgresql-common (200+deb10u3) ...
Selecting previously unselected package postgresql-11.
Preparing to unpack .../6-postgresql-11_11.7-0+deb10u1_amd64.deb ...
Unpacking postgresql-11 (11.7-0+deb10u1) ...
Selecting previously unselected package sysstat.
Preparing to unpack .../7-sysstat_12.0.3-2_amd64.deb ...
Unpacking sysstat (12.0.3-2) ...
Setting up postgresql-client-common (200+deb10u3) ...
Setting up libpq5:amd64 (11.7-0+deb10u1) ...
Setting up ssl-cert (1.0.39) ...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
Setting up postgresql-client-11 (11.7-0+deb10u1) ...
update-alternatives: using /usr/share/postgresql/11/man/man1/psql.1.gz to 
provide /usr/share/man/man1/psql.1.gz (psql.1.gz) in auto mode
Setting up postgresql-common (200+deb10u3) ...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
Adding user postgres to group ssl-cert
dpkg: error processing package postgresql-common (--configure):
 installed postgresql-common package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of postgresql-11:
 postgresql-11 depends on postgresql-common (>= 194~); however:
  Package postgresql-common is not configured yet.

dpkg: error processing package postgresql-11 (--configure):
 dependency problems - leaving unconfigured
Setting up libxslt1.1:amd64 (1.1.32-2.2~deb10u1) ...
Setting up sysstat (12.0.3-2) ...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs 

Bug#894786: RFP: python-pytest-flake8 -- pytest plugin to check FLAKE8 requirements

[Sergio Durigan Junior]

Control: retitle -1 ITP: python-pytest-flake8 -- pytest plugin to check FLAKE8 
requirements
Control: owner -1 !
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

On Wednesday, April 04 2018, Julien Puydt wrote:

> * Package name: python-pytest-flake8
>   Version : 1.0.0
>   Upstream Author : Thorsten Lockert
> * URL : https://github.com/tholo/pytest-flake8
> * License : BSD
>   Programming Lang: Python
>   Description : pytest plugin to check FLAKE8 requirements
>
> This pytest plugin makes it possible to check source code for Flake8
> style guide enforcement.
>
> The newest path.py versions use that to check the sources ; I have a
> patch to disable that for now.

I will package this.  The current version is 1.0.6.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#800824: Fingerprint checker on newnm.html should warn if the fingerprint is already known

[Phil Morrell]

Hi, I believe this is old, fixed and can be closed.

As a DM, I went to login via Salsa and claim the account, but entering
my fingerprint showed a message that my account already existed via SSO.


signature.asc
Description: PGP signature

Bug#969708: ITP: ipyparallel -- Interactive Parallel Computing with IPython

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 

* Package name: ipyparallel
  Version : 6.3.0
  Upstream Author : The IPython Development Team
* URL : https://github.com/ipython/ipyparallel
* License : BSD
  Programming Lang: Python
  Description : Interactive Parallel Computing with IPython

 ipyparallel is a Python package and collection of CLI scripts
 for controlling clusters for Jupyter. ipyparallel is the new home
 of IPython.parallel.
 .
 ipyparallel contains the following CLI scripts:
 .
ipcluster - start/stop a cluster
ipcontroller - start a scheduler
ipengine - start an engine

ipyparallel is a dependancy for the Jupyter metakernel.

As with metakernel, looking to maintain this within the DPMT.

Bug#969594: can't install nvidia legacy 304xx driver because it conflicts with xserver-xorg-core

[Andreas Beckmann]

Control: tag -1 wontfix
Control: close -1

On 9/5/20 6:47 PM, Antonio wrote:
> Dear Maintainer,
> I have a server with an nvidia gt 610 card on debian/sid, but I cannot
> install the legacy-304xx driver because it conflicts with the current
> version of xserver-xorg-core, nor can I downgrade the version of
> xserver-xorg.
> Is it possible to recompile this package with the current version 2:
> 1.20.9-1 of xorg-server?
> Thank you,
> Antonio

NVIDIA has ended support for the 304 driver series end of 2017.
Therefore no support for newer Xorg releases can be added.

See https://bugs.debian.org/900787


Andreas

Bug#965354: bcolz: FTBFS with newer python3-numpydoc

[Christian Kastner]

Control: retitle -1 bcolz: FTBFS with newer python3-sphinx

On Mon, 20 Jul 2020 09:51:26 +0200 Christian Kastner wrote:
> Source: bcolz
> Version: 1.2.1+ds2-5
> Severity: serious
> Justification: FTBFS

Bug#950597: git-gui "Show History Context" raises "Application Error"

[Benjamin Poirier]

On 2020-09-06 15:43 +0200, Bernhard Übelacker wrote:
> Control: fixed -1 1:2.26.0-1
> 
> 
> Dear Maintainer,
> I tried to have a look and found that it
> showed the message: Error: can't read "::main_status": no such variable
> 
> But starting with version 1:2.26.0-1 I could not see
> this message anymore.
> 
> Therefore I guess this bug could be closed?
> 

Thanks for looking into it. The issue was resolved by upstream commit
5eb9397e88df ("git-gui: fix error popup when doing blame -> "Show
History Context"")

Bug#969612: pipewire 0.3 now in experimental, please prep for transition

[Andreas Henriksson]

Hello,

The new version 0.3 of pipewire has now landed in experimental.

Please prepare your package for the new version and upload it
to experimental once ready so we can make progress on #966535.
Thanks!

Regards,
Andreas Henriksson

Bug#969707: guile-3.0: FTBFS in test suite "FAIL: test-out-of-memory" fails

[Vagrant Cascadian]

Source: guile-3.0
Version: 3.0.4-1.2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Tags: fbtfs


Guile fails to build with a test suite failure with a local build:

wrote
`/tmp/reprotest.OM2aDd/const_build_path/cache/guile/ccache/3.0-LE-8-4.3/tmp/reprotest.OM2aDd/const_build_path/test-suite/standalon
e/test-out-of-memory.go'
GC Warning: Failed to expand heap by 134348800 bytes
GC Warning: Failed to expand heap by 134217728 bytes
GC Warning: Out of Memory! Heap size: 1 MiB. Returning NULL!
error creating finalization thread: Cannot allocate memory
GC Warning: Failed to expand heap by 1000132608 bytes
GC Warning: Failed to expand heap by 101536 bytes
GC Warning: Out of Memory! Heap size: 1 MiB. Returning NULL!
mmap(PROT_NONE) failed
/bin/bash: line 5: 30685 Aborted top_srcdir="../.."
srcdir="." builddir="." CHARSETALIASDIR="/tmp/reprotest.OM2aDd/cons$
_build_path/lib" GUILE_AUTO_COMPILE=0 "../../meta/build-env" ${dir}$tst
FAIL: test-out-of-memory
==
1 of 39 tests failed
Please report to bug-gu...@gnu.org
==


It also fails in the same way on the tests.reproducible-builds.org
infrastructure on amd64, arm64 and armhf:

  
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/guile-3.0_3.0.4-1.2.rbuild.log.gz
  
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/guile-3.0_3.0.4-1.2.rbuild.log.gz
  
https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/guile-3.0_3.0.4-1.2.rbuild.log.gz


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#969706: buster-pu: package grunt/1.0.1-8+deb10u1

[Xavier Guimard]

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

[ Reason ]
grunt is vulnerable to a medium CVE (CVE-2020-7729, #969668)

[ Impact ]
The package grunt before 1.3.0 are vulnerable to Arbitrary Code
Execution due to the default usage of the function load() instead of
its secure replacement safeLoad() of the package js-yaml inside
grunt.file.readYAML.

[ Tests ]
Patch contains new upstream test. autopkgtest is OK

[ Risks ]
Low risk: the patch just adds some checks

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

[ Changes ]
Upstream patch is imported without changes. It adds some checks during
YAML file read and a little test.

[ Other info ]
Thanks for your work!
diff --git a/debian/changelog b/debian/changelog
index eaf56cc..f15438c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+grunt (1.0.1-8+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Use `safeLoad` for loading YML files via `file.readYAML`
+(Closes: #969668, CVE-2020-7729)
+
+ -- Xavier Guimard   Sun, 06 Sep 2020 23:41:10 +0200
+
 grunt (1.0.1-8) unstable; urgency=medium
 
   [ Harish K ]
diff --git a/debian/patches/CVE-2020-7729.patch 
b/debian/patches/CVE-2020-7729.patch
new file mode 100644
index 000..64bed12
--- /dev/null
+++ b/debian/patches/CVE-2020-7729.patch
@@ -0,0 +1,53 @@
+Description: Switch to use `safeLoad` for loading YML files via 
`file.readYAML`.
+Author: Vlad Filippov 
+Origin: upstream, https://github.com/gruntjs/grunt/commit/e350cea1
+Bug: https://snyk.io/vuln/SNYK-JS-GRUNT-597546
+Bug-Debian: https://bugs.debian.org/969668
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-09-06
+
+--- a/lib/grunt/file.js
 b/lib/grunt/file.js
+@@ -252,12 +252,21 @@
+ };
+ 
+ // Read a YAML file, parse its contents, return an object.
+-file.readYAML = function(filepath, options) {
++file.readYAML = function(filepath, options, yamlOptions) {
++  if (!options) { options = {}; }
++  if (!yamlOptions) { yamlOptions = {}; }
++
+   var src = file.read(filepath, options);
+   var result;
+   grunt.verbose.write('Parsing ' + filepath + '...');
+   try {
+-result = YAML.load(src);
++// use the recommended way of reading YAML files
++// https://github.com/nodeca/js-yaml#safeload-string---options-
++if (yamlOptions.unsafeLoad) {
++  result = YAML.load(src);
++} else {
++  result = YAML.safeLoad(src);
++}
+ grunt.verbose.ok();
+ return result;
+   } catch (e) {
+--- a/test/grunt/file_test.js
 b/test/grunt/file_test.js
+@@ -452,10 +452,13 @@
+ test.done();
+   },
+   'readYAML': function(test) {
+-test.expect(3);
++test.expect(4);
+ var obj;
+ obj = grunt.file.readYAML('test/fixtures/utf8.yaml');
+-test.deepEqual(obj, this.object, 'file should be read as utf8 by default 
and parsed correctly.');
++test.deepEqual(obj, this.object, 'file should be safely read as utf8 by 
default and parsed correctly.');
++
++obj = grunt.file.readYAML('test/fixtures/utf8.yaml', null, {unsafeLoad: 
true});
++test.deepEqual(obj, this.object, 'file should be unsafely read as utf8 by 
default and parsed correctly.');
+ 
+ obj = grunt.file.readYAML('test/fixtures/iso-8859-1.yaml', {encoding: 
'iso-8859-1'});
+ test.deepEqual(obj, this.object, 'file should be read using the specified 
encoding.');
diff --git a/debian/patches/series b/debian/patches/series
index fcd76bd..a874060 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 add-root-variable.patch
 reproducible-build.patch
 adapt-gruntfile.patch
+CVE-2020-7729.patch

Bug#969704: mes: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: forwarded 969704 
https://lists.gnu.org/archive/html/bug-mes/2020-07/msg3.html

On 2020-09-06, Rob Browning wrote:
> Source: mes
> Severity: wishlist
>
> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
> like to have the option to drop guile-2.2 from bullseye, so that we
> won't have to maintain two versions throughout that release.

This still needs some work; tested building with guile-3.0 back in July
and forwarded the issue upstream.

Upstream is freindly to the idea, just probably needs to carve out some
time for it.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#961511: [PATCH] d/xen-utils-common.xen.init: disable oom killer for xenstored

[Hans van Kranenburg]

In case of oom killer terminating some process, we'd rather not see
xenstored go. Xenstored has an in-memory database, and when starting the
process again, it would be empty, which is very inconvenient. Xenstored
should already score quite low and have a fairly low memory footprint,
but according to the user report, it happened.

Closes: #961511
Suggested-by: Samuel Thibault 
Signed-off-by: Hans van Kranenburg 
---
Cc: Ian Jackson 
---
This is in my knorrie/4.14-extra branch now. I think we should do this.
---
 debian/xen-utils-common.xen.init | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/xen-utils-common.xen.init b/debian/xen-utils-common.xen.init
index 54aaba89d320..2a4c09fa3f71 100644
--- a/debian/xen-utils-common.xen.init
+++ b/debian/xen-utils-common.xen.init
@@ -226,7 +226,8 @@ xenstored_start()
eval "try_xenstored=\$$try_xenstored_var"
if [ -x $try_xenstored ]; then
if start-stop-daemon --start --quiet \
-   --pidfile "$XENSTORED_PIDFILE" --exec 
"$try_xenstored" -- \
+   --pidfile "$XENSTORED_PIDFILE" \
+   --exec /usr/bin/choom -- -n -1000 
"$try_xenstored" -- \
$XENSTORED_ARGS --pid-file 
"$XENSTORED_PIDFILE"; then
started_xenstored=$try_xenstored
break
-- 
2.20.1

Bug#961511: [Pkg-xen-devel] Bug#961511: xen-utils-common: Protect xenstored/xenconsoled against OOM

[Hans van Kranenburg]

Hi,

On 5/25/20 3:18 PM, Samuel Thibault wrote:
> Samuel Thibault, le lun. 25 mai 2020 15:11:44 +0200, a ecrit:
>> I'm currently using a hack such as
>>
>> for i in $(pgrep xenconsoled) ; do
>> echo -1000 > /proc/$i/oom_score_adj
>> done
>>
>> in /etc/init.d/xen, but there are cleaner ways to do this :)
> 
> For instance, using choom:
> 
>   start-stop-daemon --start --quiet --pidfile "$XENCONSOLED_PIDFILE" 
> --exec /usr/bin/choom -- \
>   -n -1000 "$XENCONSOLED" $XENCONSOLED_ARGS --pid-file 
> "$XENCONSOLED_PIDFILE" \

That's a nice idea! Especially for xenstored, because it only keeps
state in memory.

xenconsoled can be started again if it's ever oom killed. so, I'd like
to limit this to xenstored only.

E.g. in my situation at work, it's mostly openvswitch that gets killed
first, if there's really a situation in which something has to go. If I
can choose between that (which disrupts vm traffic) or xenconsoled
(which does not impact customer stuff directly), then I'd rather see the
last one go temporarily.

I had to insert another -- before $XENCONSOLED_ARGS to actually make it
work.

After reboot:

-# grep . /proc/$(pidof /usr/lib/xen-4.14/bin/oxenstored)/oom_*
/proc/7478/oom_adj:-17
/proc/7478/oom_score:0
/proc/7478/oom_score_adj:-1000

Hans

Bug#969653: libreoffice-common: dlopen(…/libmergedlo.so): Bootstrapping exception 'cannot find /org.openoffice.TypeDetection.Types/Types

[Guilhem Moulin]

Control: forwarded -1 https://bugs.documentfoundation.org/show_bug.cgi?id=136526

On Sun, 06 Sep 2020 at 22:20:41 +0200, Rene Engelhard wrote:
> You mean
> 
> /usr/lib/libreoffice/share/registry *to*  /etc/libreoffice/registry ...

Yup sorry for the confusing report, I filed it in a hurry.  My actual
workaround was `ln -st /usr/lib/libreoffice/share/registry
/etc/libreoffice/registry/*.xcd` to limit namespace pollution, but of
course a fleet of symlinks is perhaps not ideal from packaging/
maintainer perspective.
 
> Two reasons
> 
> a) There is CONFIGURATION_LAYERS and I didn't deem it necessary
> b) I wanted to have a README in   /usr/lib/libreoffice/share/registry for 
> people somehow looking there.

Fair enough, forwarded upstream.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

El dg 06 de 09 de 2020 a les 11:59 +0200, Ansgar va escriure:
> I didn't say that,

Yes, Ansgar literally did:[1] If I were anyone else, "I would recommend
to discuss on debian-devel@." Filing a bug against general was the
right way; submitter's identity is irrelevant.

> This
> includes filing bugs that end up forwarded to said mailing lists.

My reports to the BTS do not end up forwarded to mailing lists, which
is known by their administrators. Ansgar's "recommendation" comes from
intolerance and her closing of this report is out of place.

> Please don't send me further mails.

I will send messages to Ansgar if it is required to solve a Debian
issue like this one.

BTS managers: Please clarify whether I am banned from the BTS.
Otherwise, I will reopen this report.

--
[1] https://bugs.debian.org/966371#10

smime.p7s
Description: S/MIME cryptographic signature

Bug#964536: mutrace should not depend on the shared binutils libraries

[Sudip Mukherjee]

Control: severity -1 important
--

I am reducing the severity as there has been no reply from 'doko'
about why the bug has been reopened.


-- 
Regards
Sudip

Bug#969653: libreoffice-common: dlopen(…/libmergedlo.so): Bootstrapping exception 'cannot find /org.openoffice.TypeDetection.Types/Types

[Rene Engelhard]

found 969653 1:7.0.0~alpha1-1

retitle 969653 dlopen(…/libmergedlo.so): Bootstrapping exception 'cannot
find /org.openoffice.TypeDetection.Types/Types in loolwsd (not finding
the config)

thanks


Hi,

Am 06.09.20 um 18:33 schrieb Guilhem Moulin:

> Version: 1:7.0.1-1~bpo10+2

Please always file against the "base version" (here:  1:7.0.1-1) at least since 
the BTS does not know bpo versions (correctly so!) and the version tracking 
gets confused.

> LibreOffice itself appears to work fine and I dunno if loolwsd's 
> dlopen(…/libmergedlo.so)
> not honoring ${CONFIGURATION_LAYERS} is an upstream bug or not.  

I'd say it is. It is a configuration option in a official rc file, so... Do you 
want to file one?

> The quick fix is
> to symlink /usr/lib/libreoffice/share/registry from /etc/libreoffice/registry,
> was there any reason not do that?

You mean

/usr/lib/libreoffice/share/registry *to*  /etc/libreoffice/registry ...

Two reasons

a) There is CONFIGURATION_LAYERS and I didn't deem it necessary
b) I wanted to have a README in   /usr/lib/libreoffice/share/registry for 
people somehow looking there.
And I *did not* want to have that README in /etc:

$ dpkg -L libreoffice-common | grep READ
/usr/lib/libreoffice/share/registry/README
/usr/share/doc/libreoffice-common/README.gz

A symlink would require that README either going away or also be in /etc which 
would make it moot...

Regards,

Rene

Bug#969669: node-node-forge: CVE-2020-7720

[Salvatore Bonaccorso]

Source: node-node-forge
Version: 0.9.1~dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1  0.8.1~dfsg-1

Hi,

The following vulnerability was published for node-node-forge.

CVE-2020-7720[0]:
| The package node-forge before 0.10.0 is vulnerable to Prototype
| Pollution via the util.setPath function. Note: Version 0.10.0 is a
| breaking change removing the vulnerable functions.

As noted the fix consists removing the function as whole, so might
break users of the module accordingly.


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-7720
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7720
[1] https://snyk.io/vuln/SNYK-JS-NODEFORGE-598677
[2] 
https://github.com/digitalbazaar/forge/commit/6a1e3ef74f6eb345bcff1b82184201d1e28b6756

Regards,
Salvatore

Bug#969668: grunt: CVE-2020-7729

[Salvatore Bonaccorso]

Source: grunt
Version: 1.0.4-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.0.1-8

Hi,

The following vulnerability was published for grunt.

CVE-2020-7729[0]:
| The package grunt before 1.3.0 are vulnerable to Arbitrary Code
| Execution due to the default usage of the function load() instead of
| its secure replacement safeLoad() of the package js-yaml inside
| grunt.file.readYAML.


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-7729
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7729
[1] 
https://github.com/gruntjs/grunt/commit/e350cea1724eb3476464561a380fb6a64e61e4e7
[2] https://snyk.io/vuln/SNYK-JS-GRUNT-597546

Regards,
Salvatore

Bug#969618: getopt: optarg is NULL outside of loop

[Aurelien Jarno]

Hi,

On 2020-09-06 09:25, Florian Weimer wrote:
> * John Scott:
> 
> > #define _POSIX_C_SOURCE 200809L
> > #include 
> > #include 
> > #include 
> > #include 
> > int main(int argc, char *argv[]) {
> > int opt;
> > while((opt = getopt(argc, argv, "a:")) != -1) {}
> > assert(optarg != NULL);
> > }
> >
> > If this is invoked as './a.out -afoo', the inner assertion will
> > the last assertion will fail with glibc.
> 
> POSIX leaves it unspecified if optarg is changed if getopt returns -1.
> Only optind must be left unchanged.  I do not think this is a glibc
> bug (or a musl bug).

Thanks Florian for the explanations. This can be confirmed that optarg
is not NULL by moving the assert in the while loop. So it doesn't seems
like a bug to me.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

[Florian Weimer]

* aurelien desbrieres:

> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>try to use jedi-mode on emacs
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>M-x jedi:install-server
>* What was the outcome of this action?
>deferred error : (error "Deferred process exited abnormally:
>   command: /home/aurelien/.emacs.d/.python-environments/default/bin/pip
>   exit status: exit 1
>   event: exited abnormally with code 1
>   buffer contents: 
> \"/home/aurelien/.emacs.d/.python-environments/default/bin/python3: 
> /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by 
> /home/aurelien/.emacs.d/.python-e\
> nvironments/default/bin/python3)
> \"")

Have you copied the pip environment from another system?  You need to
regenerate on this host.

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

[Aurelien Jarno]

Hi,

On 2020-09-06 16:34, aurelien desbrieres wrote:
> Source: glibc
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>try to use jedi-mode on emacs
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>M-x jedi:install-server
>* What was the outcome of this action?
>deferred error : (error "Deferred process exited abnormally:
>   command: /home/aurelien/.emacs.d/.python-environments/default/bin/pip
>   exit status: exit 1
>   event: exited abnormally with code 1
>   buffer contents: 
> \"/home/aurelien/.emacs.d/.python-environments/default/bin/python3: 
> /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by 
> /home/aurelien/.emacs.d/.python-e\
> nvironments/default/bin/python3)
> \"")

The python3 binary installed (by jedi-mode?) as 
/home/aurelien/.emacs.d/.python-environments/default/bin/python3
requires glibc 2.29. Debian buster comes with glibc 2.28, that's why it
fail to start.

This binary is clearly not installed from a package, and I have no idea
how you installed it. Please try to install a version that works on
glibc 2.28 or older.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#969667: smartd-runner: WARNING: tempfile is deprecated; consider using mktemp instead.

[Bob Proulx]

Package: smartmontools
Version: 7.1-1
Severity: normal
Tags: patch

Since the recent updates to debianutils 4.10 the tempfile program now
emits a run time deprecation warning.  This is now printed by the
smartmontools smartd-runner program whenever it is invoked.

Attached is the trivial and obvious patch.  Simply change tempfile to
mktemp.

[[ Although of course I want to improve the script with proper trap
handling for the temporary file and proper shell variable quoting too.
And it doesn't use any bash-isms so using portable shell would be
better.  But I will restrain myself. :-) ]]

Bob

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

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
--- smartd-runner.original  2019-10-09 04:11:03.0 -0600
+++ smartd-runner   2020-09-06 13:21:50.344560573 -0600
@@ -1,6 +1,6 @@
 #!/bin/bash -e
 
-tmp=$(tempfile)
+tmp=$(mktemp)
 cat >$tmp
 
 run-parts --report --lsbsysinit --arg=$tmp --arg="$1" \

Bug#969666: cwltool: autopkgtest regression: No module named 'arcp'

[Paul Gevers]

Source: cwltool
Version: 3.0.20200807132242-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
cwltoolfrom testing3.0.20200807132242-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

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

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
cwltool/3.0.20200807132242-1. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=cwltool

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cwltool/6927667/log.gz
 ERRORS

__ ERROR collecting tests/test_provenance.py
___
ImportError while importing test module
'/usr/lib/python3/dist-packages/cwltool/tests/test_provenance.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/cwltool/tests/test_provenance.py:11: in

import arcp
E   ModuleNotFoundError: No module named 'arcp'




signature.asc
Description: OpenPGP digital signature

Bug#969446: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth).

[Boyuan Yang]

Hi Nick,

在 2020-09-04星期五的 12:51 +，Nick Strauss写道：
> Hi Boyuan Yang,
> 
> I have added my source architecture to repo
> 
> 
> apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AB406C34
> add to /etc/apt/sources.list.d
> deb-src http://apt.nick-strauss.com/apt/debian jessie main
> apt-get source vguitar

I have reviewed your source package. The current problem is that
literally every packaging file in debian/ directory comes directly from
the template files and the template information are not removed. This
indicates a lack of manual review after generating those files.

Please review each of those files and make sure that unnecessary
template placeholders are not included in your packaging debian/ dir.
Please pay special attention to the debian/copyright file since it was
obviously the result of some automatic scan and can be greatly
simplified. If you have doubts in packaging, please make sure you
follow the instructions in 
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html
 and https://www.debian.org/doc/debian-policy/ch-source.html .

Thanks,
Boyuan Yang


> On Thursday, September 3, 2020, 09:44:37 AM CDT, Boyuan Yang <
> by...@debian.org> wrote: 
> Control: close 969445
> Control: tags -1 +moreinfo
> 
> Hi Nick,
> 
> Thanks for your interest in getting software into Debian. Some
> comments:
> 
> * Since you submitted two duplicated RFS requests, I am closing one
> of
> them to make sure that there are no duplications.
> 
> * I reviewed the package you provided and found that you only
> provided
> the binary package (.deb) for amd64 architecture, which is not
> acceptable at this moment. In order to make the software into Debian,
> you will have to provide the source package (.dsc file and related
> source tarballs) so that Debian can review the source code of such
> software as well as build the binary packages for other officially-
> supported architectures (i386, arm* etc.). Please follow the
> instruction texts in https://mentors.debian.net/intro-maintainers/
> and
> prepare your Debian source package properly.
> 
> Please fix the problems mentioned above and let people know when it's
> ready again by replying your RFS report at 
> https://bugs.debian.org/969446 .
> 

Bug#969665: breezy-debian breaks silver-platter autopkgtest: cannot import name 'MissingUpstreamTarball'

[Paul Gevers]

Source: breezy-debian, silver-platter
Control: found -1 breezy-debian/2.8.41
Control: found -1 silver-platter/0.3.0+git20200611.b4292bf-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
breezy-debian  from testing2.8.41
silver-platter from testing0.3.0+git20200611.b4292bf-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of breezy-debian to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silver-platter/6927426/log.gz

autopkgtest [05:09:59]: test testsuite: [---
EEEfailed to open trace file: [Errno 13] Permission denied:
'/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py:585:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-vqrhbhdy.tmp/silver_platter.tests.test_proposal.CheckProposalDiffGitTests.test_changes/work/proposal/.git/objects/pack/pack-a944217260120cc487bb613d97f39d7dd043d40d.idx'>
  self.data_access = _DirectPackAccess(self.index_to_pack,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py:585:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-vqrhbhdy.tmp/silver_platter.tests.test_proposal.CheckProposalDiffGitTests.test_indep/work/proposal/.git/objects/pack/pack-a944217260120cc487bb613d97f39d7dd043d40d.idx'>
  self.data_access = _DirectPackAccess(self.index_to_pack,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py:585:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-vqrhbhdy.tmp/silver_platter.tests.test_proposal.CheckProposalDiffGitTests.test_indep/work/proposal/.git/objects/pack/pack-cf8e733fc2cf0053b75a6dd2db57ab071e1bbb2b.idx'>
  self.data_access = _DirectPackAccess(self.index_to_pack,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py:585:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-vqrhbhdy.tmp/silver_platter.tests.test_proposal.CheckProposalDiffGitTests.test_no_new_commits/work/proposal/.git/objects/pack/pack-a944217260120cc487bb613d97f39d7dd043d40d.idx'>
  self.data_access = _DirectPackAccess(self.index_to_pack,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py:585:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-vqrhbhdy.tmp/silver_platter.tests.test_proposal.CheckProposalDiffGitTests.test_no_op_commits/work/proposal/.git/objects/pack/pack-a944217260120cc487bb613d97f39d7dd043d40d.idx'>
  self.data_access = _DirectPackAccess(self.index_to_pack,
ResourceWarning: Enable tracemalloc to get the object allocation traceback

==
ERROR: test_debian (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_debian
Traceback (most recent call last):
  File "/usr/lib/python3.8/unittest/loader.py", line 154, in
loadTestsFromName
module = __import__(module_name)
  File
"/tmp/autopkgtest-lxc.7k9x643b/downtmp/build.Yn5/src/silver_platter/tests/test_debian.py",
line 26, in 
from ..debian import (
  File
"/tmp/autopkgtest-lxc.7k9x643b/downtmp/build.Yn5/src/silver_platter/debian/__init__.py",
line 43, in 
from breezy.plugins.debian.errors import (
ImportError: cannot import name 'MissingUpstreamTarball' from
'breezy.plugins.debian.errors'
(/usr/lib/python3/dist-packages/breezy/plugins/debian/errors.py)


==
ERROR: test_debian_lintian (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_debian_lintian
Traceback (most recent call last):
  File "/usr/lib/python3.8/unittest/loader.py", line 154, in
loadTestsFromName

Bug#969643: previsat FTCBFS: missing Build-Depends: qt5-qmake:native for running lrelease

[Helmut Grohne]

Hi Georges,

On Sun, Sep 06, 2020 at 05:55:48PM +0200, Georges Khaznadar wrote:
> By the way, please can you tell me some pointer, to help me to understand
> the difference between dependencies like:
> - foo
> - foo, foo:native

When you perform a cross build, any build dependency is interpreted as a
host architecture dependency. The :native annotation says that it should
be build architecture instead. If you cross build on amd64 for armhf
(most common case I guess), "foo, foo:native" becomes "foo:armhf,
foo:amd64".

In a native build, build architecture and host architecture equal.  Thus
you can ignore any :native annotations for that case. "foo, foo:native"
simply becomes "foo, foo", which becomes "foo".

I think the most detailed documentation on this lives on the ubuntu
wiki: https://wiki.ubuntu.com/MultiarchCross

Please follow up in case this doesn't help.

Helmut

Bug#969664: coreutils: IF_LINT is defined to nothing, so free is never called

[Davide Prina]

Package: coreutils
Version: 8.30-3+b1
Severity: normal

Dear Maintainer,

IF_LINT is defined to nothing, so free is never called.

$ apt source coreutils

In file coreutils-8.30/src/system.h I see:
-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
/* Use this to suppress gcc's '...may be used before initialized' 
warnings. */

#ifdef lint
# define IF_LINT(Code) Code
#else
# define IF_LINT(Code) /* empty */
#endif
-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--

For example in seq.c file I see:
$ grep IF_LINT coreutils-8.30/src/seq.c
  IF_LINT (free (buf));
  IF_LINT (free (s1));
  IF_LINT (free (s2));


If I runt seq with valgrind I get the following lost memory block:
# apt install coreutils-dbgsym

$ valgrind --leak-check=yes --leak-check=full --show-leak-kinds=all seq 10
==103500== Memcheck, a memory error detector
==103500== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==103500== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright 
info

==103500== Command: seq 10
==103500==
1
2
3
4
5
6
7
8
9
10
==103500==
==103500== HEAP SUMMARY:
==103500== in use at exit: 8,192 bytes in 1 blocks
==103500==   total heap usage: 34 allocs, 33 frees, 13,331 bytes allocated
==103500==
==103500== 8,192 bytes in 1 blocks are definitely lost in loss record 1 of 1
==103500==at 0x483877F: malloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)

==103500==by 0x10E178: xmalloc (xmalloc.c:41)
==103500==by 0x10B336: seq_fast (seq.c:485)
==103500==by 0x10AB7D: main (seq.c:647)
==103500==
==103500== LEAK SUMMARY:
==103500==definitely lost: 8,192 bytes in 1 blocks
==103500==indirectly lost: 0 bytes in 0 blocks
==103500==  possibly lost: 0 bytes in 0 blocks
==103500==still reachable: 0 bytes in 0 blocks
==103500== suppressed: 0 bytes in 0 blocks
==103500==
==103500== For lists of detected and suppressed errors, rerun with: -s
==103500== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


If add the following line of code, recompile and execute again:
$ sed '533 i  if( buf ) {free(buf);}' coreutils-8.30/src/seq.c > 
coreutils-8.30/src/seq1.c

$ mv coreutils-8.30/src/seq.c coreutils-8.30/src/seq.c.bak
$ mv coreutils-8.30/src/seq1.c coreutils-8.30/src/seq.c
# apt build-dep coreutils
$ ./debian/rules build

$ valgrind --leak-check=yes --leak-check=full --show-leak-kinds=all 
./coreutils-8.30/src/seq 10

==122470== Memcheck, a memory error detector
==122470== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==122470== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright 
info

==122470== Command: /tmp/2/coreutils-8.30/src/seq 10
==122470==
1
2
3
4
5
6
7
8
9
10
==122470==
==122470== HEAP SUMMARY:
==122470== in use at exit: 0 bytes in 0 blocks
==122470==   total heap usage: 34 allocs, 34 frees, 13,331 bytes allocated
==122470==
==122470== All heap blocks were freed -- no leaks are possible
==122470==
==122470== For lists of detected and suppressed errors, rerun with: -s
==122470== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


The error is gone.


I try the following: restore the original seq.c file, define IF_LINT in 
seq.c, rebuild and execute again

$ cp coreutils-8.30/src/seq.c.bak coreutils-8.30/src/seq.c
$ sed '44 i #define IF_LINT(Code) Code' coreutils-8.30/src/seq.c > 
coreutils-8.30/src/seq1.c

$ mv coreutils-8.30/src/seq1.c coreutils-8.30/src/seq.c
$ ./debian/rules clean
$ ./debian/rules build

$ valgrind --leak-check=yes --leak-check=full --show-leak-kinds=all 
coreutils-8.30/src/seq 10

==141237== Memcheck, a memory error detector
==141237== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==141237== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright 
info

==141237== Command: /tmp/2/coreutils-8.30/src/seq 10
==141237==
1
2
3
4
5
6
7
8
9
10
==141237==
==141237== HEAP SUMMARY:
==141237== in use at exit: 0 bytes in 0 blocks
==141237==   total heap usage: 34 allocs, 34 frees, 13,331 bytes allocated
==141237==
==141237== All heap blocks were freed -- no leaks are possible
==141237==
==141237== For lists of detected and suppressed errors, rerun with: -s
==141237== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


Please define correctly IF_LINT, note that the #define is in more than 
one file (I execute a simple search):

getndelim2.c
inet_ntop.c
trim.c
vasnprintf.c
system.h

Ciao
Davide


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

Kernel: Linux 5.7.17-dp-20200831 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#969650: transition: pandas 1.0 -> 1.1

[Rebecca N. Palmer]

Package: python3-pandas
Version: 1.0.5+dfsg-3
Severity: wishlist
Control: block -1 by 969648 969649

pandas 1.1.x is currently in experimental.  The upstream description 
suggests this is not supposed to be an API break, but does have new 
warnings.


Packages tested with it (build + autopkgtest):
augur azure-kusto-python caffe changeo cnvkit dask dask.distributed 
debian-astro debian-science drms glueviz hdmf igdiscover influxdb-python 
intake jsonpickle keras lmfit-py matplotlib metaphlan2 metview-python 
mirtop mlpack nanofilt nbsphinx osmnx partd patsy poliastro poretools 
presto psychopy pybel pychopper pycoqc pynwb pyrle pysal 
python-aioinflux python-airr python-altair python-apptools 
python-biom-format python-cobra python-cogent python-cooler 
python-feather-format python-fluids python-geopandas python-geotiepoints 
python-loompy python-nanoget python-nanomath python-ncls 
python-numpy-groupies python-pauvre python-peakutils python-pomegranate 
python-pyani python-pybedtools python-pymeasure python-skbio 
python-streamz python-tablib python-treetime python-ulmo 
python-vega-datasets python-xarray pyxnat q2-cutadapt q2-demux 
q2-metadata q2-quality-filter q2-types q2templates qiime r-bioc-mofa 
rdkit recan ricks-amdgpu-utils scikit-learn seaborn sentineldl skimage 
sklearn-pandas snakemake sorted-nearest sphinx-gallery spyder-kernels 
statsmodels stimfit sunpy topplot tpot tqdm umis yanagiba


*Regressions* with pandas 1.1.x:
dask (#969648) python-skbio (#969649)

Already broken with pandas 1.0.x, but not obviously worse with 1.1.x:
dask.distributed intake matplotlib mlpack nbsphinx osmnx 
python-biom-format python-cogent python-cooler python-nanoget q2-* qiime 
rdkit sklearn-pandas sunpy yanagiba


(Note that 
https://release.debian.org/britney/pseudo-excuses-experimental.html#pandas 
does not require the reference (unstable) test to be up to date: the 
other "regressions" it lists are where the reference was old enough to 
be 0.25.x.)

Bug#969649: skbio: FTBFS/test fail with pandas 1.1

[Rebecca N. Palmer]

Package: python3-skbio
Version: 0.5.6-2

With pandas 1.1 from experimental, python-skbio fails 3 of its tests.

Log: 
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-skbio/6900486/log.gz

Bug#969648: dask: autopkgtest fail with pandas 1.1 - datetime issues

[Rebecca N. Palmer]

Package: python3-dask
Version: 2.11.0+dfsg-1
Tags: fixed-upstream

With pandas 1.1.x from experimental, dask fails 8 of its tests, at least 
mostly datetime-related.


Log: 
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask/6900447/log.gz


Upstream fix (untested): https://github.com/dask/dask/pull/6429
Note that this also includes some "xfail on numpy 1.20" parts, which we 
probably don't want.

Bug#957920: vpcs: diff for NMU version 0.5b2-2.2

[Sudip Mukherjee]

Control: tags 957920 + patch
Control: tags 957920 + pending
--

Dear maintainer,

I've prepared an NMU for vpcs (versioned as 0.5b2-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru vpcs-0.5b2/debian/changelog vpcs-0.5b2/debian/changelog
--- vpcs-0.5b2/debian/changelog 2018-06-23 14:14:38.0 +0100
+++ vpcs-0.5b2/debian/changelog 2020-09-06 20:00:57.0 +0100
@@ -1,3 +1,10 @@
+vpcs (0.5b2-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957920)
+
+ -- Sudip Mukherjee   Sun, 06 Sep 2020 20:00:57 
+0100
+
 vpcs (0.5b2-2.1) unstable; urgency=medium
 
   [ Daniel Lintott ]
diff -Nru vpcs-0.5b2/debian/patches/gcc-10.patch 
vpcs-0.5b2/debian/patches/gcc-10.patch
--- vpcs-0.5b2/debian/patches/gcc-10.patch  1970-01-01 01:00:00.0 
+0100
+++ vpcs-0.5b2/debian/patches/gcc-10.patch  2020-09-06 20:00:23.0 
+0100
@@ -0,0 +1,29 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957920
+Forwarded: no
+
+---
+
+--- vpcs-0.5b2.orig/src/command6.c
 vpcs-0.5b2/src/command6.c
+@@ -50,6 +50,7 @@ extern u_int time_tick;
+ extern int num_pths;
+ 
+ int run_net6(char *cmdstr);
++pcs vpc[MAX_NUM_PTHS];
+ 
+ #include "inet6.h"
+ extern int vinet_pton6(int af, const char * __restrict src, void * __restrict 
dst);
+--- vpcs-0.5b2.orig/src/vpcs.h
 vpcs-0.5b2/src/vpcs.h
+@@ -114,7 +114,7 @@ typedef struct {
+   hipv6 link6;
+ } pcs;
+ 
+-pcs vpc[MAX_NUM_PTHS];
++extern pcs vpc[MAX_NUM_PTHS];
+ 
+ #define delay_ms(s) usleep(s * 1000)
+ 
diff -Nru vpcs-0.5b2/debian/patches/series vpcs-0.5b2/debian/patches/series
--- vpcs-0.5b2/debian/patches/series2018-06-23 14:14:38.0 +0100
+++ vpcs-0.5b2/debian/patches/series2020-09-06 19:30:53.0 +0100
@@ -2,3 +2,4 @@
 LinuxMakefilePatch
 CreateTopLevelMakefile
 hurd_path_max
+gcc-10.patch

Bug#969663: wolfssl: CVE-2020-12457 CVE-2020-15309 CVE-2020-24585 CVE-2020-24613

[Salvatore Bonaccorso]

Source: wolfssl
Version: 4.4.0+dfsg-7
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for wolfssl.

CVE-2020-12457[0]:
| An issue was discovered in wolfSSL before 4.5.0. It mishandles the
| change_cipher_spec (CCS) message processing logic for TLS 1.3. If an
| attacker sends ChangeCipherSpec messages in a crafted way involving
| more than one in a row, the server becomes stuck in the ProcessReply()
| loop, i.e., a denial of service.


CVE-2020-15309[1]:
| An issue was discovered in wolfSSL before 4.5.0, when single precision
| is not employed. Local attackers can conduct a cache-timing attack
| against public key operations. These attackers may already have
| obtained sensitive information if the affected system has been used
| for private key operations (e.g., signing with a private key).


CVE-2020-24585[2]:
| An issue was discovered in the DTLS handshake implementation in
| wolfSSL before 4.5.0. Clear DTLS application_data messages in epoch 0
| do not produce an out-of-order error. Instead, these messages are
| returned to the application.


CVE-2020-24613[3]:
| wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the
| WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in tls13.c.
| This is an incorrect implementation of the TLS 1.3 client state
| machine. This allows attackers in a privileged network position to
| completely impersonate any TLS 1.3 servers, and read or modify
| potentially sensitive information between clients using the wolfSSL
| library and these TLS servers.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-12457
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12457
[1] https://security-tracker.debian.org/tracker/CVE-2020-15309
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15309
[2] https://security-tracker.debian.org/tracker/CVE-2020-24585
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24585
[3] https://security-tracker.debian.org/tracker/CVE-2020-24613
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24613

Regards,
Salvatore

Bug#958179: My setup

[Francois Marier]

Not a solution to the issue you raised, but in case that helps, I've
documented my own setup here:

  https://feeding.cloud.geek.nz/posts/home-music-server-with-mpd/

Francois

-- 
https://fmarier.org/

Bug#969660: src:cpio: fails to migrate to testing for too long: maintainer built arch:all binaries

[Paul Gevers]

Source: cpio
Version: 2.13+dfsg-2
Severity: serious
Control: close -1 2.13+dfsg-3
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:cpio in its
current version in unstable has been trying to migrate for 60 days [2].
Hence, I am filing this bug.

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

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

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

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Normally, I
would do a no-changes source-only upload to DELAYED/15, closing this
bug, however I'm currently on very limited Internet.

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#969661: golang-1.15: CVE-2020-24553

[Salvatore Bonaccorso]

Source: golang-1.15
Version: 1.15-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/golang/go/issues/40928
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:golang-1.14 1.14.7-2
Control: retitle -2 golang-1.14: CVE-2020-24553

Hi,

The following vulnerability was published for golang.

CVE-2020-24553[0]:
| Go before 1.14.8 and 1.15.x before 1.15.1 allows XSS because text/html
| is the default for CGI/FCGI handlers that lack a Content-Type header.


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-24553
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24553
[1] https://github.com/golang/go/issues/40928
[2] https://groups.google.com/forum/#!topic/golang-announce/8wqlSbkLdPs

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#969659: whipper: truncated short package description

[Daniele Forsi]

Package: whipper
Severity: normal

Dear Maintainer,

the short package description says: "CD-DA ripper based" while the long package 
description says "...CD-DA ripper based on the morituri project..." (no need to 
repeat identical words)

thanks,
Daniele

Bug#968567: linux-image-4.19.0-10-amd64: kernel failure when writing on a GFS2 partition

[Salvatore Bonaccorso]

Hi Nicolas,

Not a direct help, but some comments:

On Mon, Aug 17, 2020 at 07:12:32PM +0200, Nicolas Courtel wrote:
> Package: src:linux
> Version: 4.19.132-1
> Severity: normal
> 
> Dear maintainer,
> 
> After upgrading to kernel 4.19.0-10, writing to a GFS2 volume makes the kernel
> output a series of messages, and the server quickly becomes unusable. Before
> trying to write, mounting the volume and reading its content works as 
> expected.
> 
> The problem is reproductible on 2 different servers, using FC and iSCSI. They
> both work well otherwise, the normal behavior is restored after switching to
> previous kernel 4.19.0-9 
> 
> The kernel messages are the following:
> 
> Aug 12 16:31:26 ertok kernel: [   90.951413] BUG: unable to handle kernel 
> NULL pointer dereference at 0008
> Aug 12 16:31:26 ertok kernel: [   90.951415] PGD 0 P4D 0 
> Aug 12 16:31:26 ertok kernel: [   90.951418] Oops: 0002 [#1] SMP PTI
> Aug 12 16:31:26 ertok kernel: [   90.951420] CPU: 2 PID: 2140 Comm: libvirtd 
> Not tainted 4.19.0-10-amd64 #1 Debian 4.19.132-1
> Aug 12 16:31:26 ertok kernel: [   90.951420] Hardware name: HP ProLiant 
> DL360p Gen8, BIOS P71 02/25/2012
> Aug 12 16:31:26 ertok kernel: [   90.951433] RIP: 
> 0010:gfs2_log_commit+0x104/0x400 [gfs2]
> Aug 12 16:31:26 ertok kernel: [   90.951435] Code: 60 4c 8d b3 dc 08 00 00 4c 
> 89 f7 e8 f6 90 d2 dd 48 8b 55 70 48 8d 45 70 48 39 d0 74 29 49 8b 4c 24 78 48 
> 8b 75 70 48 8b 55 78 <48> 89 4e 08 48 89 31 49 8d 4c 24 70 48 89 0a 49 89 54 
> 24 78 48 89
> Aug 12 16:31:26 ertok kernel: [   90.951435] RSP: 0018:ad46c24dfba8 
> EFLAGS: 00010282
> Aug 12 16:31:26 ertok kernel: [   90.951437] RAX: 9caba6487b70 RBX: 
> 9cab8bc32000 RCX: 
> Aug 12 16:31:26 ertok kernel: [   90.951437] RDX:  RSI: 
>  RDI: 9cab8bc328dc
> Aug 12 16:31:26 ertok kernel: [   90.951438] RBP: 9caba6487b00 R08: 
> 9caba6487b58 R09: 9caba33fe4d0
> Aug 12 16:31:26 ertok kernel: [   90.951439] R10: 9cab54d8b000 R11: 
>  R12: 9caba94f9200
> Aug 12 16:31:26 ertok kernel: [   90.951440] R13: 9cab8bc327c8 R14: 
> 9cab8bc328dc R15: d40b0f4b1740
> Aug 12 16:31:26 ertok kernel: [   90.951441] FS:  7f6a7cff9700() 
> GS:9cabaea8() knlGS:
> Aug 12 16:31:26 ertok kernel: [   90.951442] CS:  0010 DS:  ES:  CR0: 
> 80050033
> Aug 12 16:31:26 ertok kernel: [   90.951443] CR2: 0008 CR3: 
> 0003ebfd6005 CR4: 000606e0
> Aug 12 16:31:26 ertok kernel: [   90.951443] Call Trace:
> Aug 12 16:31:26 ertok kernel: [   90.951481]  gfs2_trans_end+0x7d/0x160 [gfs2]
> Aug 12 16:31:26 ertok kernel: [   90.951492]  gfs2_dirty_inode+0x1bc/0x240 
> [gfs2]
> Aug 12 16:31:26 ertok kernel: [   90.951497]  ? iomap_readpage+0x85/0x110
> Aug 12 16:31:26 ertok kernel: [   90.951506]  ? gfs2_dirty_inode+0x144/0x240 
> [gfs2]
> Aug 12 16:31:26 ertok kernel: [   90.951511]  __mark_inode_dirty+0x1ba/0x380
> Aug 12 16:31:26 ertok kernel: [   90.951515]  generic_update_time+0xb6/0xd0
> Aug 12 16:31:26 ertok kernel: [   90.951518]  touch_atime+0xbe/0xe0
> Aug 12 16:31:26 ertok kernel: [   90.951522]  
> generic_file_read_iter+0x8ca/0xbc0
> Aug 12 16:31:26 ertok kernel: [   90.951531]  ? 
> gfs2_glock_add_to_lru.part.41+0x7c/0xd0 [gfs2]
> Aug 12 16:31:26 ertok kernel: [   90.951540]  gfs2_file_read_iter+0xe3/0xf0 
> [gfs2]
> Aug 12 16:31:26 ertok kernel: [   90.951544]  new_sync_read+0xf8/0x160
> Aug 12 16:31:26 ertok kernel: [   90.951547]  vfs_read+0x91/0x140
> Aug 12 16:31:26 ertok kernel: [   90.951549]  ksys_read+0x57/0xd0
> Aug 12 16:31:26 ertok kernel: [   90.951552]  do_syscall_64+0x53/0x110
> Aug 12 16:31:26 ertok kernel: [   90.951556]  
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> Aug 12 16:31:26 ertok kernel: [   90.951558] RIP: 0033:0x7f6a91a43544
> Aug 12 16:31:26 ertok kernel: [   90.951560] Code: 84 00 00 00 00 00 41 54 49 
> 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 5b fc ff ff 4c 89 e2 48 89 ee 89 df 
> 41 89 c0 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 38 44 89 c7 48 89 44 24 08 e8 97 
> fc ff ff 48
> Aug 12 16:31:26 ertok kernel: [   90.951561] RSP: 002b:7f6a7cff84e0 
> EFLAGS: 0246 ORIG_RAX: 
> Aug 12 16:31:26 ertok kernel: [   90.951562] RAX: ffda RBX: 
> 0016 RCX: 7f6a91a43544
> Aug 12 16:31:26 ertok kernel: [   90.951564] RDX: 2000 RSI: 
> 7f6a40104ed0 RDI: 0016
> Aug 12 16:31:26 ertok kernel: [   90.951564] RBP: 7f6a40104ed0 R08: 
>  R09: 7f6a4560
> Aug 12 16:31:26 ertok kernel: [   90.951565] R10: 7f6a48d0 R11: 
> 0246 R12: 2000
> Aug 12 16:31:26 ertok kernel: [   90.951566] R13:  R14: 
> 0016 R15: 2001
> Aug 12 16:31:26 ertok kernel: [   90.951568] Modules linked in: gfs2 dlm ses 
> enclosure sctp ip_gre ip_tunnel gre openvswitch nsh nf_nat_ipv6 

Bug#969646: [Pkg-phototools-devel] Bug#969646: Bug#969646: darktable-cli segfaults directly after start

[Jan van de W]

Ah yes, I should have tried that. This is on a headless server, so X is
piped over SSH.

$ darktable &
[1] 905062
jan@paranoidandroid:~$ darktable: symbol lookup error:
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so: undefined
symbol: _ZN5Exiv210ExifParser6decodeERNS_8ExifDataEPKhj

[1]+  Exit 127darktable

Which leads me to the right cause. An ldd darktable shows me that libexiv
points to a directory in /usr/local. Probably an old experiment coming back
to haunt me :(
My apologies for the noise. Nothing to see here.


Op zo 6 sep. 2020 om 20:01 schreef David Bremner :

>
> Control: tag -1 unreproducible.
>
> David Bremner  writes:
>
> > Jan van de Wijdeven  writes:
> >
> >> Package: darktable
> >> Version: 3.2.1-3
> >> Severity: grave
> >> Justification: renders package unusable
> >>
> >> I run darktable-cli and it immediately segfaults
> >>
> >
> > What about regular darktable, and not on a jpeg?
>
> My mistake, I thought you were exporting from a jpeg. In any case I
> can't reproduce it with the Olympus raws I have lying around. The
> question of whether you the same problem with non-cli darktable stands.
>
> d
>

Bug#969377: Bug reopen

[Philip Hands]

Camaleón  writes:

...
> The mass-block changes made by Javier make it difficult to see what
> has been going on with the original file:

I had a quick look at some of these changes, and thought that there
ought to be a way of extracting the sense from the noise.  So I've had a
play with git diff textconv's and come up with something that may help a
bit.

Attached you'll find a hacky perl script (sloppy_po.pl) which strips out
CR-LFs and trailing spaces, and to joins msg* chunks together so that
the changes in line-breaks go away.

If you configure git to use that for .po diffs, then the real
differences are revealed. One does that by adding the following to
.git/info/attributes:

=-=-=-=-
*.po diff=po
=-=-=-=-

and this to .git/config:

=-=-=-=-
[diff "po"]
textconv = ./sloppy_po.pl
=-=-=-=-

(assuming you're putting the script in the repo)

Having done that you'll get a much shorter diff:

$ git diff efa9821ab..5878a44af  | wc -l
182

rather than what it's like wthout the textconv stuff:
$ git diff efa9821ab..5878a44af --no-textconv | wc -l
9674

The output of git diff --color-words is then very revealing.

Of course the resulting patch is not directly applicable to the code,
becuase the mutli-line msg blocks have been glued into single, long,
lines but it does reveal what really changed ... which is basically a
few 'BIOS' to 'BIOS/UEFI' replacements, some whitespace fixes, and the
end of the file being trimmed off.

HTH

Cheers, Phil.


signature.asc
Description: PGP signature
#!/usr/bin/perl

my $scratch = "";

while(<>) {
   s/\s*\r?\n$// ;
   if (/^(msg\w* .*)"$/) {
  $scratch .= $1 ;
  next ;
   }
   if ("$scratch" && /"(.*)"$/) {
  $scratch .= $1 ;
  next ;
   }
   if ("$scratch") {
  print $scratch . "\"\n" ;
  $scratch = "" ;
   }
   print $_ . "\n" ;
}
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#969620: ITP: metakernel -- Jupyter kernel base class

[Gordon Ball]

On Sat, Sep 05, 2020 at 11:04:37PM -0400, Joseph Nahmias wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Joseph Nahmias 
> 
> * Package name: metakernel
>   Version : 0.27.0
>   Upstream Author : Metakernel Development Team
> * URL : https://github.com/Calysto/metakernel
> * License : BSD
>   Programming Lang: Python
>   Description : Jupyter kernel base class
> 
> Metakernel is a Jupyter kernel base class in Python which includes core magic
> functions (including help, command and file path completion, parallel and
> distributed processing, downloads, and much more).
> 
> It is used by numerous other kernels for Jupyter, including for my purposes 
> the
> octave kernel.
> 
> Happy to have co-maintainers and/or place it under the rubric of the Debian 
> Python team.
> 
Glad to have more bits of the jupyter ecosystem available. I'd be
willing to be listed as a co-maintainer/uploader for this package
(context: I [co-]maintain some of the jupyter core libraries and
notebook). I experimented with a personal build of this library (+
octave_kernel) in the past, but my octave knowledge wasn't good enough
to actually use it enough to be confident it was useful.

The core libraries are all team-maintained with the debian-python team;
the R kernel (r-cran-irkernel) is also available, under pkg-r-team.

> --Joe
> 

Gordon

Bug#969360: Qt seccomp failure patch works

[Dmitry Shachnev]

Control: notforwarded -1

Hi John!

On Thu, Sep 03, 2020 at 07:37:56PM -0400, John Scott wrote:
> On Wednesday, September 2, 2020 8:02:42 AM EDT Dmitry Shachnev wrote:
> > My guess is that we need this patch (not applied upstream yet)
>
> Thanks for the pointer, that patch applies cleanly and fixes the issue.

Thanks for testing!

> > But that bug (QTBUG-81313) is already fixed in Qt 5.14.2. So we are
> > probably seeing something else.
>
> I saw that and figured it might've been a mistake on their part. It's even the
> same syscalls that are failing the issue's so similar, but perhaps their fix
> was incomplete.

The syscalls are not the same. The new ones are using 64-bit time instead of
32-bit: clock_nanosleep vs. clock_nanosleep_time64.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#957133: dia2code: diff for NMU version 0.8.3-4.1

[Sudip Mukherjee]

Control: tags 957133 + patch
Control: tags 957133 + pending
--

Dear maintainer,

I've prepared an NMU for dia2code (versioned as 0.8.3-4.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -u dia2code-0.8.3/debian/changelog dia2code-0.8.3/debian/changelog
--- dia2code-0.8.3/debian/changelog
+++ dia2code-0.8.3/debian/changelog
@@ -1,3 +1,10 @@
+dia2code (0.8.3-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957133)
+
+ -- Sudip Mukherjee   Sun, 06 Sep 2020 18:53:21 
+0100
+
 dia2code (0.8.3-4) unstable; urgency=low
 
   * debian/patches/fix_Segfault.patch: fixed segfault (Closes: #550092).
only in patch2:
unchanged:
--- dia2code-0.8.3.orig/debian/patches/gcc-10.patch
+++ dia2code-0.8.3/debian/patches/gcc-10.patch
@@ -0,0 +1,24 @@
+--- a/dia2code/dia2code.h
 b/dia2code/dia2code.h
+@@ -264,8 +264,8 @@ param_list * d2c_parameter_set(char *name, char *value);
+ char * d2c_parameter_value(char *name);
+ param_list *d2c_parameter_find(char *name);
+ 
+-int indent_count;
+-int indent_open_brace_on_newline;
+-int generate_backup;
++extern int indent_count;
++extern int indent_open_brace_on_newline;
++extern int generate_backup;
+ 
+ #endif
+--- a/dia2code/main.c
 b/dia2code/main.c
+@@ -19,6 +19,7 @@
+ #include "code_generators.h"
+ #include "parse_diagram.h"
+ 
++int generate_backup;
+ int process_initialization_file(char *filename, int exit_if_not_found);
+ 
+ #define DEFAULT_TARGET 0

Bug#969658: ITP: lookatme -- interactive command-line presentation tool

[Reiner Herrmann]

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

* Package name: lookatme
  Version : 1.2.0
  Upstream Author : James Johnson
* URL : https://github.com/d0c-s4vage/lookatme
* License : MIT
  Programming Lang: Python3
  Description : interactive command-line presentation tool

lookatme is an extensible terminal-based presentation tool that renders
Markdown documents and supports themes, syntax highlighting, live and manual
source reloading and can embed external files and live terminals into slides.

Bug#969657: pcmanfm: relies on xfce4-panel, while LXDE uses lxpanel

[Michele Nalli]

Package: pcmanfm
Version: 1.3.1-1
Severity: important

Dear Maintainer,

I'm having the same error message in 2 different situations.

The error message is:
Failed to add a plugin to the pane
No running instance of xfce4-panel was found

The situations are:
* When I double click on a readable, executable file (e.g. shellscript) 
pcmanfm asks me if
  i want to:
  * Execute
  * Execute in terminal
  * Open
  * Cancel
  
  If I click on "Open" the error message pops up and no editor is 
opened.
  If I right click and open with the editor there is no error.

* When I right click on a .desktop file and select "Create Launcher on 
the panel"
  This last issues looks the same as this one on Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/pcmanfm/+bug/1431414

I installed Debian buster from the live install with LXDE already on, and I've 
never had the xfce panel (LXDE of course has lxpanel) or any other Desktop 
environment installed than LXDE.
I didn't find any option that allowed me to specify a preference on which panel 
to use either.

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

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pcmanfm depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfm-gtk4   1.3.1-1
ii  libfm4   1.3.1-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk2.0-0  2.24.32-3
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libx11-6 2:1.6.7-1
ii  shared-mime-info 1.10-1

Versions of packages pcmanfm recommends:
ii  gnome-icon-theme 3.12.0-3
ii  gvfs-backends1.38.1-5
ii  gvfs-fuse1.38.1-5
ii  lxde-icon-theme  0.5.1-2
ii  lxpolkit [polkit-1-auth-agent]   0.5.4-1
ii  policykit-1-gnome [polkit-1-auth-agent]  0.105-7

pcmanfm suggests no packages.

-- no debconf information

Bug#969646: [Pkg-phototools-devel] Bug#969646: Bug#969646: darktable-cli segfaults directly after start

[David Bremner]

Control: tag -1 unreproducible.

David Bremner  writes:

> Jan van de Wijdeven  writes:
>
>> Package: darktable
>> Version: 3.2.1-3
>> Severity: grave
>> Justification: renders package unusable
>>
>> I run darktable-cli and it immediately segfaults
>>
>
> What about regular darktable, and not on a jpeg?

My mistake, I thought you were exporting from a jpeg. In any case I
can't reproduce it with the Olympus raws I have lying around. The
question of whether you the same problem with non-cli darktable stands.

d

Bug#578859: No sound output from Rosegarden via timidity ALSA ports

[Nick Daly]

Package: timidity
Version: 2.14.0-8
Followup-For: Bug #578859

Dear Maintainer,

As an addendum to the last email, I realized some of the (working)
behavior I experienced disappeared when I restarted my computer.
The attached Rosegarden-alsa startup script seems to work after a
fresh restart, while pulseaudio is running.

Thanks for your time,
Nick



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages timidity depends on:
ii  libao41.2.2+20180113-1
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libflac8  1.3.2-3
ii  libice6   2:1.0.9-2
ii  libjack0 [libjack-0.125]  1:0.125.0-3
ii  libncurses6   6.1+20181013-2+deb10u2
ii  libogg0   1.3.2-1+b1
ii  libpng16-16   1.6.36-6
ii  libsm62:1.2.3-1
ii  libspeex1 1.2~rc1.2-1+b2
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libx11-6  2:1.6.7-1
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.1.5-1+b3
ii  lsb-base  10.2019051400
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages timidity recommends:
ii  fluid-soundfont-gm  3.1-5.1

Versions of packages timidity suggests:
pn  fluid-soundfont-gs  
ii  freepats20060219-1
pn  pmidi   
pn  timidity-daemon 

-- no debconf information
#! /usr/bin/env bash

#systemctl --user stop pulseaudio.socket
#systemctl --user stop pulseaudio.service

timidity -iA -Os &
tim=$!
sleep 5

rosegarden
sleep 5

kill $tim

#systemctl --user start pulseaudio.service
#systemctl --user start pulseaudio.socket

Bug#968589: PPP name resolver service not restarted upon upgrade

[積丹尼 Dan Jacobson]

This bug still affects PPP connections' name resolver service.
DHCP connections name service restarts fine.
Full dump attached at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968589#36

Bug#969656: util-linux: man page for zramctl is outdated about max_comp_streams' "default is one stream"

[Marcel Partap]

Package: util-linux
Version: 2.36-3
Severity: normal

Since Kernel 4.7, it defaults to one stream per CPU:

> Regardless of the value passed to this attribute, ZRAM will always
> allocate multiple compression streams - one per online CPU - thus
> allowing several concurrent compression operations. The number of
> allocated compression streams goes down when some of the CPUs
> become offline. There is no single-compression-stream mode anymore,
> unless you are running a UP system or have only 1 CPU online.

.. Best Regards! : )



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

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

Versions of packages util-linux depends on:
ii  libaudit1  1:2.8.5-2
ii  libblkid1  2.34-0.1
ii  libc6  2.30-4
ii  libcap-ng0 0.7.9-2.2
ii  libcrypt1  1:4.4.16-1
ii  libmount1  2.36-3
ii  libpam0g   1.3.1-5
ii  libselinux13.1-2
ii  libsmartcols1  2.34-0.1
ii  libsystemd0246.4-1
ii  libtinfo6  6.2-1
ii  libudev1   246.4-1
ii  libuuid1   2.34-0.1
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-1+b1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-4
pn  util-linux-locales  

-- debconf-show failed

Bug#964812: closed by Debian FTP Masters (reply to Ben Hutchings ) (Bug#964812: fixed in linux 5.8.3-1~exp1)

[Ben Hutchings]

On Tue, 2020-09-01 at 11:19 -0700, David Awogbemila wrote:
[...]
> Thank you for the update! Just to confirm, does this mean the driver
> will be available to future versions on Debian
> (i.e. have the config options set so that the driver is available in
> Debian Images)?
> If so, what versions of Debian will this affect? (I'm guessing the
> ones starting with linux 5.8?)

Right, any change in stable will need to be done separately.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou




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

Bug#969646: [Pkg-phototools-devel] Bug#969646: darktable-cli segfaults directly after start

[David Bremner]

Jan van de Wijdeven  writes:

> Package: darktable
> Version: 3.2.1-3
> Severity: grave
> Justification: renders package unusable
>
> I run darktable-cli and it immediately segfaults
>

What about regular darktable, and not on a jpeg?

d

Bug#969655: akonadi: depends on libqt5gui5 and 170 MB of gui libraries

[Jonas Smedegaard]

Source: akonadi
Version: 4:20.04.1-2+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

akonadi is a server, yet it links with libqt5gui5 which pulls in 170 MB
of GUI-related libraries.

Please try avoid that, to ease its goal of being usable not only in KDE.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl9VFKQACgkQLHwxRsGg
ASGpGRAApT+0df8PeGUBjhJwdB6IKNFgrDEU4I/TDkNxGKDSrK+wA6hoMH+s+4mp
xkQ2uKywZKGkguPhg9kS3/DCKqoanpkIgOdtqGJP7KcaKoucP5Y4yVDakypCgGKH
EvHXAF+6+PqH54AREKwR8DPTxhE9qhmwktaZ7NyfadzIugmFoEM4c26KGYXdqIUs
NgeUY0OE2EOLgWptWDH0ciLvtQNS0Zm+3UEiYmaIv8fLhI8MVHj/gONo6Af+zXBn
jJrVrLtvJtuhbio1xBLJRNj3bvNHcG3HG9xMkU98qxoqMm5ldo1zOWT73LlZ/3Ar
Yrdp5BNG5HJrwjpu50P97Fg8wYY2KQUXY64M7ChQXO9ChBpCejrCrViVWGRYHzza
uX4HCo2yOrCakZDqmCyK13GlEkY9LlQR4TTUMHUMpdKHqS7QQHfum4fQndgrkJkf
FEfkuItHeXtfGOEbvFqvYDaall5RI8Q6DHbC8gyyunhP0/GyD4XnX3fMmNsqs4Qz
RdGBfGNV+EzwIxapEIOYEPw7JxYHaOK0ECXonVL4F8HIwuCkxiirz0/lR9/56HJB
KGp5+X3cPJrP/dwGi0ZUTByCnGK3J6MzRazgGqT15ueMOQmLnPeKJbzp6WKByoVp
eYE+5ZctVf+NtPfhkHZ5H4pMmtD3nkSd4KOCHGxS5pWeoQ6keWA=
=o2gL
-END PGP SIGNATURE-

Bug#968545: This is an ITP now

[Joachim Zobel]

Since I have started to package this myself I should explain what it does.

The HAP package can compute Homolgy and persistent Homology. See
https://www.gap-system.org/Manuals/pkg/hap-1.25/www/SideLinks/About/twoTutorials.html

Another tool that might be able to do that is singular. I do however
find HAP easier to use.

Sincerely,

Joachim

-- 
Papier ist gebundenes CO2. Bitte drucken Sie diese EMail aus und archivieren 
Sie sie.

Bug#578859: No sound output from Rosegarden via timidity ALSA ports

[Nick Daly]

Package: timidity
Version: 2.14.0-8
Followup-For: Bug #578859

Dear Maintainer,

Attached is a patch that allows timidity to play via JACK output in
v2.14.0-8.  This feature was lost at some point in the last few years
(at least as far back as 2014).  When timidity is broken, attempting to
use it produces error messages as noted below.  After the attached patch
is applied, Rosegarden makes noise as expected.  Oddly, this patch seems
to fix output for both JACK and ALSA outputs, but it's not clear why,
and further investigation or confirmation would be appreciated.

This patch was copied from ArchLinux and this repository:

- [https://bugs.archlinux.org/task/40906]
- [https://github.com/archlinux/svntogit-
community/blob/6078ccb4fcb32cb2c6b50dd6b79bbce49b173435/trunk/timidity-
jack.patch]

I have not investigated why it works or how it was identified, the
original blog is dead and not stored on the Wayback Machine:

[http://blog.163.com/jiams_wang/blog/static/3033914920138120746567]

Test Case:

1. Install the packages qjackctl, timidity, rosegarden, and
   fluid-soundfont-gm.

2. Run the attached rosegarden-with-jack script to start each of the
   tools needed to play music via Rosegarden over JACK.

3. Verify that when Rosegarden tries to connect to timidity, that the
   timidity process starts printing output containing the line "Couldn't
   start JACK device (`j')".

   ,
   | $ timidity -Oj -iA
   | jack_client_new: deprecated
   | TiMidity starting in ALSA server mode
   | Opening sequencer port: 129:0 129:1 129:2 129:3
   | Couldn't start JACK device (`j')
   `

4. Play the attached demo file, and verify that no sounds are played.

5. Run the attached rosegarden-with-alsa script that starts each of the
   tools needed to play music via Rosegarden over ALSA.

6. Play the attached demo file, and verify that sounds are played only
   after quitting Rosegarden.

7. Apply the patch.

8. Verify that Rosegarden can play sounds when playing the demo file and
   when adding notes to a track.



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages timidity depends on:
ii  libao41.2.2+20180113-1
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libflac8  1.3.2-3
ii  libice6   2:1.0.9-2
ii  libjack0 [libjack-0.125]  1:0.125.0-3
ii  libncurses6   6.1+20181013-2+deb10u2
ii  libogg0   1.3.2-1+b1
ii  libpng16-16   1.6.36-6
ii  libsm62:1.2.3-1
ii  libspeex1 1.2~rc1.2-1+b2
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libx11-6  2:1.6.7-1
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.1.5-1+b3
ii  lsb-base  10.2019051400
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages timidity recommends:
ii  fluid-soundfont-gm  3.1-5.1

Versions of packages timidity suggests:
pn  fluid-soundfont-gs  
pn  freepats
pn  pmidi   
pn  timidity-daemon 
--- timidity-2.14.0.orig/timidity/jack_a.c  2020-09-05 11:47:43.562415021 
-0500
+++ timidity-2.14.0/timidity/jack_a.c   2020-09-05 11:45:38.642526757 -0500
@@ -267,6 +267,7 @@
 {
jack_client_t *client;
-   client = jack_client_new(TIMIDITY_JACK_CLIENT_NAME);
+   client = jack_client_open(TIMIDITY_JACK_CLIENT_NAME,
+ (jack_options_t)0, NULL);
if (! client)
return 0;
jack_client_close(client);
@@ -283,7 +284,8 @@
 
memset(ctx, 0, sizeof(*ctx));
 
-   ctx->client = jack_client_new(TIMIDITY_JACK_CLIENT_NAME);
+   ctx->client = jack_client_open(TIMIDITY_JACK_CLIENT_NAME,
+  (jack_options_t)0, NULL);
if (! ctx->client)
return -1;
 
@@ -509,6 +511,7 @@
pthread_cond_wait(>cond, >lock);
}
/* fallthrough */
+   case PM_REQ_PLAY_START:
case PM_REQ_DISCARD:
ctx->running = 0;
ringbuf_clear(>rbuf);
#! /usr/bin/env bash
#
# Start Rosegarden with sound support.
#

systemctl --user stop pulseaudio.socket
systemctl --user stop pulseaudio.service

qjackctl --start &
qj=$!
sleep 5

timidity -iA -Oj &
tim=$!
sleep 5

rosegarden

kill $tim
sleep 1
kill $qj

systemctl --user start pulseaudio.service
systemctl --user start 

Bug#969654: ITP: gap-nq -- provides the ANU nilpotent quotient program for computing nilpotent factor groups of finitely presented groups and makes it available as part of the gap ecosystem.

[Joachim Zobel]

Package: wnpp
Severity: wishlist
Owner: Joachim Zobel 

* Package name: gap-nq
  Version : 2.5.4
  Upstream Author : Werner Nickel 
* URL : https://www.gap-system.org/Packages/nq.html
* License : GPL-2+
  Programming Lang: C, GAP 4
  Description : provides the ANU nilpotent quotient program for computing
nilpotent factor groups of finitely presented groups and makes it available as
part of the gap ecosystem.

What the package actually does is best described by the upstream author:
https://gap-packages.github.io/nq/README.html

I am packaging this because it is a dependency for #968545.

Bug#969653: libreoffice-common: dlopen(…/libmergedlo.so): Bootstrapping exception 'cannot find /org.openoffice.TypeDetection.Types/Types

[Guilhem Moulin]

Package: libreoffice-common
Version: 1:7.0.1-1~bpo10+2
Severity: wishlist

Dear Maintainer,

Since /usr/lib/libreoffice/share/registry moved to /etc/libreoffice/registry
loolwsd (not in Debian at the moment) fails during bootstrapping:

[ forkit ] TRC  dlopen(/usr/lib/libreoffice/program/libmergedlo.so, 
RTLD_GLOBAL|RTLD_NOW)| kit/Kit.cpp:2833
[ forkit ] TRC  Invoking lok_preinit(/usr/lib/libreoffice/program", 
"file:///user")| kit/Kit.cpp:2887
Init vcl
Bootstrapping exception 'cannot find 
/org.openoffice.TypeDetection.Types/Types …/configmgr/source/rootaccess.cxx:213'
[ forkit ] TRC  Finished lok_preinit(/usr/lib/libreoffice/program", 
"file:///user") in 25 ms.| kit/Kit.cpp:2897
[…]
Bootstrapping exception 'cannot find /org.openoffice.Setup/L10N 
…/configmgr/source/rootaccess.cxx:213'

LibreOffice itself appears to work fine and I dunno if loolwsd's 
dlopen(…/libmergedlo.so)
not honoring ${CONFIGURATION_LAYERS} is an upstream bug or not.  The quick fix 
is
to symlink /usr/lib/libreoffice/share/registry from /etc/libreoffice/registry,
was there any reason not do that?  Setting Severity: wishlist anyway since it
AFAICT only affects software outside Debian.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#953948: marked as pending in net-snmp

[Diederik de Haas]

On Sun, 06 Sep 2020 12:27:42 + Craig Small  
wrote:
> Control: tag -1 pending
> 
> Moved snmptrapd library into its own package to not pull in mysql 
dependencies for snmp/snmpd Closes: #953948
> 

Awesome, thank you.

Diederik

Bug#969652: ITP: xbrzscale -- Intelligent graphics file upscaling tool

[Peter]

Package: wnpp
Severity: wishlist
Owner: Peter Blackman 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: xbrzscale
  Version : 1.8
  Upstream Author : Przemysław Grzywacz  Zenju 

* URL : https://github.com/atheros/xbrzscale 
https://sourceforge.net/projects/xbrz/
* License : GPL-3+
  Programming Lang: C++
  Description : Intelligent graphics file upscaling tool

 Scale graphics files with the xBRZ algorithm.
 .
 xBRZ by Zenju is a modified version of xBR.
 It uses the same basic idea as xBR's pattern recognition and interpolation,
 but with a different rule set designed to preserve fine image details
 as small as a few pixels.
 This makes it useful for scaling the details in faces, and in particular eyes.
 xBRZ is optimized for multi-core CPUs and 64-bit architectures and shows
 40–60% better performance than HQx even when running on a single CPU core only.
 It supports scaling images with an alpha channel,
 and scaling by integer factors from 2× up to 6×.

Bug#969651: coreutils: du don't free all the memory it allocate

[Davide Prina]

Package: coreutils
Version: 8.30-3+b1
Severity: normal

Dear Maintainer,


I was looking what I can do with valgrind, so I tested it with a simple 
command: du.
It seem I have found two points in which allocated memory is not free. 
For the first I have found a solution, but not for the second one (it is 
a lot of time that I don't do C/C++ programming).



Those are the steps I have done:


1) installing debug symbols
# apt install coreutils-dbgsym


2) executing valgrind for memory leak
$ valgrind --leak-check=yes --leak-check=full --show-leak-kinds=all du -s .
==13844== Memcheck, a memory error detector
==13844== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13844== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==13844== Command: du -s .
==13844==
236735652   .
==13844==
==13844== HEAP SUMMARY:
==13844== in use at exit: 720 bytes in 2 blocks
==13844==   total heap usage: 1,325 allocs, 1,323 frees, 638,869 bytes 
allocated

==13844==
==13844== 16 bytes in 1 blocks are still reachable in loss record 1 of 2
==13844==at 0x483877F: malloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)

==13844==by 0x115558: xmalloc (xmalloc.c:41)
==13844==by 0x115708: xzalloc (xmalloc.c:86)
==13844==by 0x10B752: main (du.c:750)
==13844==
==13844== 704 bytes in 1 blocks are still reachable in loss record 2 of 2
==13844==at 0x483AB65: calloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)

==13844==by 0x11573E: xcalloc (xmalloc.c:101)
==13844==by 0x10C203: process_file (du.c:602)
==13844==by 0x10C203: du_files (du.c:708)
==13844==by 0x10C203: main (du.c:1122)
==13844==
==13844== LEAK SUMMARY:
==13844==definitely lost: 0 bytes in 0 blocks
==13844==indirectly lost: 0 bytes in 0 blocks
==13844==  possibly lost: 0 bytes in 0 blocks
==13844==still reachable: 720 bytes in 2 blocks
==13844== suppressed: 0 bytes in 0 blocks
==13844==
==13844== For lists of detected and suppressed errors, rerun with: -s
==13844== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


3) installing du source
$ apt source coreutils


4) look what there are at the du error lines
$ cd coreutils-8.30/
$ head -n 750 src/du.c | tail -n 1
  exclude = new_exclude ();

$ head -n 1122 src/du.c | tail -n 1
  ok &= du_files (temp_argv, bit_flags);


5) analyze the 1st error: exclude = new_exclude ();
I see that in the exclude.h/exclude.c there is also a free_exclude() 
that is not called


5.1) adding the missing line
$ sed '925 i  free_exclude( exclude );' src/du.c > src/du1.c
$ mv src/du.c src/du.c.bak
$ mv src/du1.c src/du.c

5.2) compile
# apt build-dep coreutils
$ ./debian/rules build

5.3) test to see if the memory leak is already here
$ valgrind --leak-check=yes --leak-check=full --show-leak-kinds=all 
/tmp/2/coreutils-8.30/src/du -s .

236735652   .
==62961==
==62961== HEAP SUMMARY:
==62961== in use at exit: 704 bytes in 1 blocks
==62961==   total heap usage: 1,325 allocs, 1,324 frees, 638,869 bytes 
allocated

==62961==
==62961== 704 bytes in 1 blocks are still reachable in loss record 1 of 1
==62961==at 0x483AB65: calloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)

==62961==by 0x118ADE: xcalloc (xmalloc.c:101)
==62961==by 0x10C47A: process_file (du.c:602)
==62961==by 0x10C47A: du_files (du.c:708)
==62961==by 0x10C47A: main (du.c:1123)
==62961==
==62961== LEAK SUMMARY:
==62961==definitely lost: 0 bytes in 0 blocks
==62961==indirectly lost: 0 bytes in 0 blocks
==62961==  possibly lost: 0 bytes in 0 blocks
==62961==still reachable: 704 bytes in 1 blocks
==62961== suppressed: 0 bytes in 0 blocks
==62961==
==62961== For lists of detected and suppressed errors, rerun with: -s
==62961== ERROR SUMMARY: 1209 errors from 1 contexts (suppressed: 0 from 0)


6) analyze the 2nd error
$ head -n 1123 src/du.c | tail -n 1
  ok &= du_files (temp_argv, bit_flags);
$ head -n 708 src/du.c | tail -n 1
  ok &= process_file (fts, ent);
$ head -n 602 src/du.c | tail -n 1
  dulvl = xcalloc (n_alloc, sizeof *dulvl);

6.1) I try to adding the missing free line, but it don't work, probably 
for the simil cast used with xnrealloc

$ sed '668 i  if( dulvl ) {free( dulvl );}' src/du.c > src/du1.c
$ mv src/du1.c src/du.c

6.2) compile
$ ./debian/rules clean
$ ./debian/rules build

6.3) test to see if the memory leak is already here, but I have a lot of 
errors
$ valgrind --leak-check=yes --leak-check=full --show-leak-kinds=all 
/tmp/2/coreutils-8.30/src/du -s .

==101211== Memcheck, a memory error detector
==101211== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==101211== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright 
info

==101211== Command: /tmp/2/coreutils-8.30/src/du -s .
==101211==
==101211== Invalid read of size 8
==101211==at 0x10E82E: excluded_file_name 

Bug#969643: previsat FTCBFS: missing Build-Depends: qt5-qmake:native for running lrelease

[Georges Khaznadar]

Dear Helmut,

thank you for the bugreport and for the patch. I shall upload the fixed
package.

By the way, please can you tell me some pointer, to help me to understand
the difference between dependencies like:
- foo
- foo, foo:native

Best regards,   Georges.

Helmut Grohne a écrit :
> Source: previsat
> Version: 3.5.1.7+dfsg1-3
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> previsat fails to cross build from source, because it fails running
> lrelease on a .pro file due to a missing build dependency on
> qt5-qmake:native. Please consider applying the attached patch.
> 
> Helmut

> diff --minimal -Nru previsat-3.5.1.7+dfsg1/debian/changelog 
> previsat-3.5.1.7+dfsg1/debian/changelog
> --- previsat-3.5.1.7+dfsg1/debian/changelog   2018-12-03 19:19:06.0 
> +0100
> +++ previsat-3.5.1.7+dfsg1/debian/changelog   2020-09-06 14:14:16.0 
> +0200
> @@ -1,3 +1,11 @@
> +previsat (3.5.1.7+dfsg1-3.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix FTCBFS: Add qt5-qmake:native to Build-Depends for running lrelease.
> +(Closes: #-1)
> +
> + -- Helmut Grohne   Sun, 06 Sep 2020 14:14:16 +0200
> +
>  previsat (3.5.1.7+dfsg1-3) unstable; urgency=medium
>  
>* created VCS stuff in d/control
> diff --minimal -Nru previsat-3.5.1.7+dfsg1/debian/control 
> previsat-3.5.1.7+dfsg1/debian/control
> --- previsat-3.5.1.7+dfsg1/debian/control 2018-12-03 19:19:06.0 
> +0100
> +++ previsat-3.5.1.7+dfsg1/debian/control 2020-09-06 14:14:15.0 
> +0200
> @@ -3,7 +3,7 @@
>  Priority: optional
>  Maintainer: Georges Khaznadar 
>  Build-Depends: debhelper (>= 11.0.0),
> - qtbase5-dev, qt5-qmake, libqt5webkit5-dev, qtmultimedia5-dev,
> + qtbase5-dev, qt5-qmake, qt5-qmake:native, libqt5webkit5-dev, 
> qtmultimedia5-dev,
>   qttools5-dev-tools,
>   libvlc-dev, zlib1g-dev
>  Standards-Version: 4.2.1


-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#936268: caldav-tester: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Wed, Sep 02, 2020 at 09:00:43PM +0200, Petter Reinholdtsen wrote:
> [Moritz Mühlenhoff]
> > Let's remove?
> 
> I agree.  I tried to notify other caldav interested people to see if
> there was any interest in taking over.  No response so far, so I believe
> it is time to give in. :)

Ack, I've filed a RM bug.

Cheers,
Moritz

Bug#969647: Fix package name

[Pirate Praveen]

Control: retitle -1 ITP: ruby-ecma-re-validator -- validate regular 
expressions

Bug#969647: ITP: ruby-ecma-re-validate -- Validate a regular expression string against ECMA-262

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

This library can be used to validate a regular expression string 
against what

ECMA-262 (Javascript) can actually do.
.
The information for what is valid and what isn't comes from
http://www.regular-expressions.info/javascript.html.

Bug#839382: RFS: elfio/3.7-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.7-1
   Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* 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.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Regards,
--
  Serge Lamikhov-Center

Bug#969646: darktable-cli segfaults directly after start

[Jan van de Wijdeven]

Package: darktable
Version: 3.2.1-3
Severity: grave
Justification: renders package unusable

I run darktable-cli and it immediately segfaults

Output:

$ darktable-cli DSC06384.ARW DSC06384.jpg --verbose
[New LWP 806704]
[New LWP 806705]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f38336ec2c7 in wait4 () from /lib/x86_64-linux-gnu/libc.so.6
warning: Currently logging to /tmp/darktable_bt_1LJUQ0.txt.  Turn the logging 
off and on to make the new setting effective.
#0  0x7f38336ec2c7 in wait4 () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f3834204b90 in  () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#2  0x7f383365ce30 in  () at 
/lib/x86_64-linux-gnu/libc.so.6
#3  0x7f3831c347f0 in typeinfo name for Exiv2::StringValueBase () at 
/usr/local/lib/libexiv2.so.27
#4  0x7f3834187e6d in dt_exif_read () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#5  0x7f38341b6f0c in  () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#6  0x5599f9194717 in  ()
#7  0x7f3833647cca in __libc_start_main () at 
/lib/x86_64-linux-gnu/libc.so.6
#8  0x5599f919547a in  ()

=

  Id   Target IdFrame 
* 1Thread 0x7f382d00b0c0 (LWP 806701) "darktable-cli"   0x7f38336ec2c7 
in wait4 () from /lib/x86_64-linux-gnu/libc.so.6
  2Thread 0x7f382c28c700 (LWP 806704) "lua thread"  0x7f38337144bf 
in poll () from /lib/x86_64-linux-gnu/libc.so.6
  3Thread 0x7f382ba8b700 (LWP 806705) "pool-darktable-" 0x7f3833719a79 
in syscall () from /lib/x86_64-linux-gnu/libc.so.6

=

Thread 3 (Thread 0x7f382ba8b700 (LWP 806705)):
#0  0x7f3833719a79 in syscall () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f3834035a12 in g_cond_wait_until () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f3833fba5c1 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f3834012eda in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f383401251d in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f3833607ea7 in start_thread () at 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f383371eeaf in clone () at /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7f382c28c700 (LWP 806704)):
#0  0x7f38337144bf in poll () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f3833fe97ee in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f3833fe9b53 in g_main_loop_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f38343687d4 in  () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#4  0x7f383401251d in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f3833607ea7 in start_thread () at 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f383371eeaf in clone () at /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f382d00b0c0 (LWP 806701)):
#0  0x7f38336ec2c7 in wait4 () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f3834204b90 in  () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#2  0x7f383365ce30 in  () at 
/lib/x86_64-linux-gnu/libc.so.6
#3  0x7f3831c347f0 in typeinfo name for Exiv2::StringValueBase () at 
/usr/local/lib/libexiv2.so.27
#4  0x7f3834187e6d in dt_exif_read () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#5  0x7f38341b6f0c in  () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#6  0x5599f9194717 in  ()
#7  0x7f3833647cca in __libc_start_main () at 
/lib/x86_64-linux-gnu/libc.so.6
#8  0x5599f919547a in  ()
[Inferior 1 (process 806701) detached]
backtrace written to /tmp/darktable_bt_1LJUQ0.txt
Segmentation fault


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

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

Versions of packages darktable depends on:
ii  libc62.31-3
ii  libcairo21.16.0-4
ii  libcolord-gtk1   0.1.26-2
ii  libcolord2   1.4.4-2
ii  libcups2 2.3.3-3
ii  libcurl3-gnutls  7.72.0-1
ii  libexiv2-27  0.27.3-3
ii  libgcc-s110.2.0-6
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgomp1 10.2.0-6
ii  libgphoto2-6 2.5.25-3
ii  libgphoto2-port122.5.25-3
ii  libgraphicsmagick-q16-3  1.4+really1.3.35+hg16297-1
ii  libgtk-3-0   3.24.22-1
ii  libilmbase25 2.5.3-2
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libjson-glib-1.0-0   1.4.4-2
ii  liblcms2-2 

Bug#839382: RFS: elfio/1.0-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.7-1
   Upstream Author : Serge Lamikhov-Center 
* URL : http://serge1.github.io/ELFIO
* License : MIT
* 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.7-1.dsc

Changes for the initial release:

elfio (3.7-1) unstable; urgency=medium
.
   * Initial release (Closes: #839382)


Regards,
--
  Serge Lamikhov-Center

Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

[aurelien desbrieres]

Source: glibc
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   try to use jedi-mode on emacs
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   M-x jedi:install-server
   * What was the outcome of this action?
   deferred error : (error "Deferred process exited abnormally:
  command: /home/aurelien/.emacs.d/.python-environments/default/bin/pip
  exit status: exit 1
  event: exited abnormally with code 1
  buffer contents: 
\"/home/aurelien/.emacs.d/.python-environments/default/bin/python3: 
/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by 
/home/aurelien/.emacs.d/.python-e\
nvironments/default/bin/python3)
\"")

   * What outcome did you expect instead?
   something that works!

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


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

Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#969572: ITP: python-duniterpy - Duniter Python API

[Jonas Smedegaard]

Quoting moul (2020-09-06 15:13:07)
> Here is the setup.py that I generated with dephell:

Thanks - got the package building now, and refining smaller nits...

For future sake, it is easier if you attach files like that instead of 
pasting it inline.

Also, please consider writing comments below quoted parts - quoting only 
stuff necessary for your comments.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#968093: See also

[積丹尼 Dan Jacobson]

See also https://forums.gentoo.org/viewtopic-t-1117556-start-0.html .

Bug#891414: enable qt5 front-end

[Philip Rinn]

Am 06.09.20 um 13:59 schrieb Alexander Volkov:
> Looks like merge requests are disabled for
> https://salsa.debian.org/debian/gimagereader

True, I enabled them now (I tend to do taht as it seems to be the easiest way to
disable the debian-janitor)

Thanks for your contribution, I'll upload a new version with your changes.

Thanks & best regards
Philip

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Sun, 7 Jun 2020 17:12:17 +0200 Francesco Poli wrote:

> On Thu, 4 Jun 2020 17:35:20 +0900 Mike Hommey wrote:
> 
> [...]
> > Can you test 68.9.0esr-1?
> 
> I've just tried, after installing it from unstable.
> 
> No luck!
> The microphone fails to work with firefox-esr/68.9.0esr-1

Hello again,
I've just tested firefox-esr/68.12.0esr-1 from unstable.

The microphone still fails to work, unfortunately.

I had to downgrade back to 68.7.0esr-1 in order to get it working
correctly.

Is there any progress on this bug?
It's preventing me from upgrading firefox-esr to the latest versions...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpVmGyMG7rRV.pgp
Description: PGP signature

Bug#950597: git-gui "Show History Context" raises "Application Error"

[Bernhard Übelacker]

Control: fixed -1 1:2.26.0-1


Dear Maintainer,
I tried to have a look and found that it
showed the message: Error: can't read "::main_status": no such variable

But starting with version 1:2.26.0-1 I could not see
this message anymore.

Therefore I guess this bug could be closed?

Kind regards,
Bernhard

Bug#969377: Spanish translators

[Camaleón]

El 2020-09-05 a las 21:01 +0200, Holger Wansing escribió:

> Camaleón  wrote:
> > El 2020-09-05 a las 17:02 +0200, Holger Wansing escribió:
> > > Which program did you use to edit the po file?
> > > poedit, Lokalize, gtranslator?
> > 
> > I use Virtaal, and minor edits are done with Mousepad.
> 
> I tried editing po files with Virtaal today, but I cannot reproduce this
> behaviour of the Windows-style line-endings (see 
> https://es.wikipedia.org/wiki/Nueva_l%C3%ADnea for details on this topic).
> Don't what happened to those files.

Me neither. I've been traslating PO files since (9-10) years and this is
the first time I've been warned about line ending formatting.

I will have to run additional tests to avoid this kind of errors.

(...)

> > > I just want to help with this conflict, please accept this help.
> > 
> > I do know, and I appreciate it. So you can keep the files as they are 
> > now at the GIT repository and discard the ones I uploaded in BTS (bugs 
> > id #969377, #969378, #969379, #969380 and #969381). 
> > 
> > Bugs can be closed.
> > 
> > P.S. As I already told Javier, this is the last time I translate these 
> > files because I don't like to see my job being blatantly hijacked.
> 
> I perfectly understand this. I already work as translator for German, and
> I had similar situations as well, so I know what you are talking about.
> I feel sad to read your above comments, I was hoping to get the Spanish
> translation 100% up-to-date again.
> To be honest, Spanish was lying far behind with its translation statistic
> for years!
> When reading the above, I also read
> https://lists.debian.org/debian-l10n-spanish/2020/08/msg00058.html
> (via Google Translator), and now I realize the whole problem.
> 
> Javier is working as translator for Spanish for a long time, but since
> several years there are only minor contributions by him. The last bigger
> update was in 2013.
> Because of this, I have added a hint 
> "This translation of the installation guide is not up-to-date and
> currently there is noone actively working on updating it. ..."
> to Spanish (and other languages).
> See
> https://salsa.debian.org/installer-team/installation-guide/-/commit/268eaec764f8fb0e230c0c3ec3aac10ffde9c5a9
> Thus, Javier was not in the position of telling himself the current or
> active translator for Spanish!

Thanks for your understanding. 

I deeply respect Javier's job and his long-standing role inside Debian 
community. I also think he has very strong feelings on Debian's 
Installation Manual and wants to keep the control of the translation 
files; this is something I can ultimately understand and it does not 
pose a problem on my side as the are tons of unstranslated files that 
also need love.

> Therefore, I was happy to see major contributions to Spanish by you!!!
> 
> If you decided to no longer contribute to this manual, I accept this,
> of course.

To be sincere, I'm better dealing with computer bugs than people's 
human behavior. Let's apply common sense and keep things as they are 
now, so if Javier wants to care about those files I'm fine with that.

> However:
> At least I would like to add a notice to the manual, to mention your 
> translation
> update work in chapter E.1:
> https://d-i.debian.org/doc/installation-guide/es.amd64/apes01.html
> I think about adding something like 
> "Camaleón  contributed a major translation update in 
> 2020".
> or similar, as you like.
> What do you think?
> Could you translate such sentence into Spanish for me?

I sincerely thank your proposal but I prefer not adding it: the main 
goal of Debian's Installation Guide is to be conceptually universal, 
useful and understandable for users, not focusing on who, where or when 
was translated. Computers and ideas first, human last.

Cheers,

-- 
Camaleón 

Bug#969572: ITP: python-duniterpy - Duniter Python API

[moul]

Here is the setup.py that I generated with dephell:

cat setup.py

# -*- coding: utf-8 -*-

# DO NOT EDIT THIS FILE!
# This file has been autogenerated by dephell <3
# 

try:
   from setuptools import setup
except ImportError:
   from distutils.core import setup


import os.path

readme = ''
here = os.path.abspath(os.path.dirname(__file__))
readme_path = os.path.join(here, 'README.rst')
if os.path.exists(readme_path):
   with open(readme_path, 'rb') as stream:
   readme = stream.read().decode('utf8')


setup(
   long_description=readme,
   name='duniterpy',
   version='0.57.0',
   description='Python library for developers of Duniter clients',
   python_requires='==3.*,>=3.5.3',
   project_urls={"documentation": 
"", "homepage": 
"", "repository": ""},

   author='inso',
   author_email='insomniak...@gmail.com',
   maintainer='canercandan',
   license='GPL-3.0-or-later',
   keywords='g1 duniter cryptocurrency librecurrency library',
   classifiers=['Development Status :: 5 - Production/Stable', 
'Natural Language :: English', 'Operating System :: OS Independent', 
'Topic :: Software Development :: Libraries', 'Intended Audience :: 
Developers'],
   packages=['duniterpy', 'duniterpy.api', 'duniterpy.api.bma', 
'duniterpy.api.elasticsearch', 'duniterpy.api.ws2p', 
'duniterpy.documents', 'duniterpy.documents.ws2p', 
'duniterpy.grammars', 'duniterpy.helpers', 'duniterpy.key'],

   package_dir={"": "."},
   package_data={"duniterpy": ["*.typed"]},
   install_requires=['aiohttp==3.*,>=3.6.1', 'attrs==19.*,>=19.3.0', 
'base58==2.*,>=2.0.0', 'jsonschema==3.*,>=3.0.2', 
'libnacl==1.*,>=1.6.1', 'pyaes==1.*,>=1.6.1', 
'pylibscrypt==1.*,>=1.8.0', 'pypeg2==2.*,>=2.15.2'],
   extras_require={"dev": ["black==19.*,>=19.3.0.b0; python_version == 
\"3.*\" and python_version >= \"3.6.0\"", "mypy==0.*,>=0.730.0", 
"pylint==2.*,>=2.4.2", "sphinx==3.*,>=3.0.2", 
"sphinx-rtd-theme==0.*,>=0.4.3"]},

)


On So, Sep 6, 2020 at 15:08, Jonas Smedegaard  wrote:

Quoting moul (2020-09-06 14:41:46)

 What I can easily do is generate a setup.py from the pyproject.toml.
 There is dephell which does that:
 <>


That would be helpdul if you cold provide such pre-generated file.

Then I could include that as a patch for the Debian package - as
workaround until Poetry is in Debian.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: 

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#969572: ITP: python-duniterpy - Duniter Python API

[Jonas Smedegaard]

Quoting moul (2020-09-06 14:41:46)
> What I can easily do is generate a setup.py from the pyproject.toml.
> There is dephell which does that:
> 

That would be helpdul if you cold provide such pre-generated file.

Then I could include that as a patch for the Debian package - as 
workaround until Poetry is in Debian.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#891414: enable qt5 front-end

[Alexander Volkov]

Hi,

Looks like merge requests are disabled for 
https://salsa.debian.org/debian/gimagereader
I can't create a merge request from 
https://salsa.debian.org/avolkov-guest/gimagereader/-/commits/qt5

Bug#959232: linux-image-5.5.0-2-amd64: system freeze after suspend-to-ram: potentially IRQ-related issue

[Salvatore Bonaccorso]

Hi Maximilian,

On Fri, May 01, 2020 at 11:56:00AM +0200, Maximilian Stein wrote:
> Package: src:linux
> Version: 5.5.17-1
> Severity: normal
> 
> Dear maintainer,
> 
> Occasionally my system freezes after waking up from suspend-to-ram.
> More precisely, the KDE lock screen appears, I can type my passphrase,
> but then the screen just stays black leaving me movable mouse. I
> neither can switch to a virtual terminal (Strg+Alt+F1 etc.) nor kill
> the session with SysRq+K. Rebooting with SysRqs still works though.
> 
> Investigating the issues in the kernel logs reveals a message
> indicating a NULL ptr derefererence in the kernel that is related to
> IRQ (see below).
> 
> My device was in suspend-to-ram since yesterday so the attached log
> includes all messages since I opened the laptop lid. It was generated
> using:
> 
>   journalctl -b-1 --dmesg --since today --quiet --no-hostname --grep 
> '^(?!iptables:)'
> 
> Such freezes happen about once a week and since I got the device (so
> it also happened with older kernels).
> 
> The device is a Lenovo X1 Carbon 6th Generation with an Intel
> i7-8650U with up-to-date BIOS running Debian Testing.
> 
> Any help is highly appreciated.

A similar report was done in SuSE 
https://bugzilla.suse.com/show_bug.cgi?id=1129258

Can you check if hte issue ist still present with a more recent
kernel, ideally test up to 5.8.7-1 in unstable.

If the issue is still present, it might be woth reporting it directly
upstream to the linux-...@vger.kernel.org list.

Regards,
Salvatore

Bug#969572: ITP: python-duniterpy - Duniter Python API

[moul]

What I can easily do is generate a setup.py from the pyproject.toml.
There is dephell which does that:


On So, Sep 6, 2020 at 14:32, Jonas Smedegaard  wrote:

Quoting moul (2020-09-06 14:14:01)

 Ok, then most likely Poetry needs to be integrated into this Python
 build system.


If by "this Python build system" you mean Pybuild, then it does not
really change the concrete issue that Poetry is not yet in Debian.

For the initial release to Debian of package python-duniterpy, I see 
two

options: a) wait for Poetry to get packaged _and_ usable in Debian, or
b) patch duniterpy to not use Poetry.

It seems (if you are talking about Pybuild gaining support for Poetry)
that you are talking about a variant of a) which involves not only
packaging Poetry but then also developing Pybuild further to cover it.
I am not familiar with Poetry, but I suspect that Pybuild is flexible
enough that we need not wait for such integration to happen, but can
(for now) pass explicit commands for how to Poetry should be executed.

To get python-duniterpy accepted into Debian fastest possible, I
recommend to _not_ wait for Poetry, but explore b) instead.  Either 
have

upstream project duniterpy re-add support for "archaic" build
frameworks, or help provide a patch to apply specifically for the 
Debian

package.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: 

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#969559: curl segmentation fauls on any https URL

[Bernhard Übelacker]

Hello Bruce Momjian,
thanks for the details and confirmation.


Am 05.09.20 um 17:32 schrieb Bruce Momjian,,,:
>   (gdb) print pmeth->init
>   $1 = (int (*)(EVP_PKEY_CTX *)) 0xf0e0d0c0b0a0908

>   gdb) print *pmeth
>   $8 = {pkey_id = 50462976, flags = 117835012, init = 0xf0e0d0c0b0a0908, 
> copy = 0x1716151413121110, cleanup = 0x1f1e1d1c1b1a1918, paramgen_init = 
> 0x98c476a19fc273a5, paramgen = 0x9cc072a593ce7fa9,

The pointer init copy and cleanup are really not looking like usual
pointers or random ...

> I am using a pkcs11 hardware crypto device, and perhaps it is
> misconfigured, but it probably shouldn't crash.  This might be a library
> bug, not sure.  I will check the pkcs11's configuration now, but it used
> to work.

But I have no knowledge about such crypto hardware, therefore
I am not sure if I can be of any more help. Maybe you could
provide the needed packages, libraries and configuration steps
that are needed to use such a device of yours when starting with
a fresh debian installation?

Kind regards,
Bernhard

Bug#964839: Still happens on 5.7.17

[Salvatore Bonaccorso]

Hi Felix,

On Sat, Sep 05, 2020 at 10:53:59AM +0200, Felix Dörre wrote:
> The behavior on:
> Linux chinchilla 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) x86_64
> GNU/Linux
> is still the same: for the first suspend you need to enable the graphics
> card manually. On any subsequent suspend the mechanic works.
> 
> Could someone please look into this bug? It lies around since nearly a month
> now with no reaction at all.

There was an update for 5.8.7-1 yesterday to unstable (although the
signed packages are not yet there). Could you test that one as well?

Now if the issue is still present in 5.8.7 then if I understand you
correctly then it is okay with 5.6.14-2, but is an issue first with
5.7.6-1. 

What you can try to do is, check if to bisect between the two stable
upstream versions 5.6.14 and 5.7.6 and try to find the commit
introducing the issue. If it is convicable enough that it introduced a
bug we are probably on the lucky side (saying that because if you see
the issue only with bbswitch, and a tainted kernel upstream might ask
to reproduce the issue with an untainted kernel, or it is convicable a
bug otherwise).

Can you try those two things? So first check if 5.8.7 has the issue,
if possible then confirm as well for the current mainline, and
secondly if the issue is still present in 5.8.7, try to isolate the
commit introducing the issue beween 5.6.14 and 5.7.6.

Some help on how to do the bisect can be found in
https://wiki.debian.org/DebianKernelReportingBugs
https://wiki.debian.org/DebianKernel/GitBisect

Regards,
Salvatore

Bug#969641: [Pkg-javascript-devel] Bug#969641: node-entities: should depend on nodejs

[Pirate Praveen]

Control: severity -1 wishlist

On Sun, Sep 6, 2020 at 13:59, Jonas Smedegaard  wrote:

Package: node-entities
Version: 2.0.2-2
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

node-* packages must depend on nodejs -
libjs-* need not (when _only_ targeting browser use).

* Libraries written in a language should generally not depend on that 
language's interpreter


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54

Changelog for release 2.0.2-2 includes "Drop runtime dependency on 
nodejs

(to avoid installing nodejs with l ibjs-markdown-it" -
but libjs-markdown-it does _not_ depend on nodejs,
neither directly nor transitively.

Perhaps there was no issue to fix, and you simply confused
libjs-markdown-it and node-markdown-it?



No, node-markdown-it provides libjs-markdown-it now and node-entities 
is a dependency of node-markdown-it


From the CTTE bug referenced above,


3. For the specific case of src:ruby-task-list, which provides both a 
Ruby

  library and a JavaScript library, we suggest:

* shipping both Ruby and JavaScript libraries in a single binary package
* removing the dependency on the Ruby interpreter, unless there is a
 reason why it is required
* asking the maintainers of the Ruby libraries that ruby-task-list
 recursively depends on (such as ruby-rack) to remove *their* 
dependencies

 on the Ruby interpreter, unless there is a reason why it is required

So we need to recursively remove the dependency on the interpreter.


Please revert the change, to have node-* package depend on nodejs.

If you disagree that nodejs libraries must depend on nodejs,
then please let's discuss that general change in the team first.


Already replied there.

Bug#969572: ITP: python-duniterpy - Duniter Python API

[Jonas Smedegaard]

Quoting moul (2020-09-06 14:14:01)
> Ok, then most likely Poetry needs to be integrated into this Python 
> build system.

If by "this Python build system" you mean Pybuild, then it does not 
really change the concrete issue that Poetry is not yet in Debian.

For the initial release to Debian of package python-duniterpy, I see two 
options: a) wait for Poetry to get packaged _and_ usable in Debian, or 
b) patch duniterpy to not use Poetry.

It seems (if you are talking about Pybuild gaining support for Poetry) 
that you are talking about a variant of a) which involves not only 
packaging Poetry but then also developing Pybuild further to cover it.  
I am not familiar with Poetry, but I suspect that Pybuild is flexible 
enough that we need not wait for such integration to happen, but can 
(for now) pass explicit commands for how to Poetry should be executed.

To get python-duniterpy accepted into Debian fastest possible, I 
recommend to _not_ wait for Poetry, but explore b) instead.  Either have 
upstream project duniterpy re-add support for "archaic" build 
frameworks, or help provide a patch to apply specifically for the Debian 
package.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#969644: kcc FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: kcc
Version: 2.3-12.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kcc fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - does
not entirely fix the cross build, because it strips with the build
architecture strip via install -s. Doing so also breaks generation of
-dbgsym packages as well as DEB_BUILD_OPTIONS=nostrip. The attached
patch also disables any install-time stripping and solves all mentioned
problems. Please consider applying it.

Helmut
diff -u kcc-2.3/debian/changelog kcc-2.3/debian/changelog
--- kcc-2.3/debian/changelog
+++ kcc-2.3/debian/changelog
@@ -1,3 +1,12 @@
+kcc (2.3-12.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Defer all stripping to dh_strip.
+
+ -- Helmut Grohne   Sun, 06 Sep 2020 14:16:37 +0200
+
 kcc (2.3-12.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u kcc-2.3/debian/rules kcc-2.3/debian/rules
--- kcc-2.3/debian/rules
+++ kcc-2.3/debian/rules
@@ -8,7 +8,7 @@
 #export DH_VERBOSE=1
 
 CFLAGS = -O2 -Wall
-INSTALL = install
+INSTALL = install --strip-program=true
 INSTALL_FILE= $(INSTALL) -p-o root -g root  -m  644
 INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
 INSTALL_SCRIPT  = $(INSTALL) -p-o root -g root  -m  755
@@ -24,10 +24,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE) CFLAGS="$(CFLAGS)"
-
+   dh_auto_build -- CFLAGS="$(CFLAGS)"
touch build-stamp
 
 clean:

Bug#969643: previsat FTCBFS: missing Build-Depends: qt5-qmake:native for running lrelease

[Helmut Grohne]

Source: previsat
Version: 3.5.1.7+dfsg1-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

previsat fails to cross build from source, because it fails running
lrelease on a .pro file due to a missing build dependency on
qt5-qmake:native. Please consider applying the attached patch.

Helmut
diff --minimal -Nru previsat-3.5.1.7+dfsg1/debian/changelog 
previsat-3.5.1.7+dfsg1/debian/changelog
--- previsat-3.5.1.7+dfsg1/debian/changelog 2018-12-03 19:19:06.0 
+0100
+++ previsat-3.5.1.7+dfsg1/debian/changelog 2020-09-06 14:14:16.0 
+0200
@@ -1,3 +1,11 @@
+previsat (3.5.1.7+dfsg1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add qt5-qmake:native to Build-Depends for running lrelease.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sun, 06 Sep 2020 14:14:16 +0200
+
 previsat (3.5.1.7+dfsg1-3) unstable; urgency=medium
 
   * created VCS stuff in d/control
diff --minimal -Nru previsat-3.5.1.7+dfsg1/debian/control 
previsat-3.5.1.7+dfsg1/debian/control
--- previsat-3.5.1.7+dfsg1/debian/control   2018-12-03 19:19:06.0 
+0100
+++ previsat-3.5.1.7+dfsg1/debian/control   2020-09-06 14:14:15.0 
+0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Georges Khaznadar 
 Build-Depends: debhelper (>= 11.0.0),
- qtbase5-dev, qt5-qmake, libqt5webkit5-dev, qtmultimedia5-dev,
+ qtbase5-dev, qt5-qmake, qt5-qmake:native, libqt5webkit5-dev, 
qtmultimedia5-dev,
  qttools5-dev-tools,
  libvlc-dev, zlib1g-dev
 Standards-Version: 4.2.1

Bug#969642: libibtk FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: libibtk
Version: 0.0.14-12.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libibtk fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes libibtk cross buildable. Please consider
applying the attached patch.

Helmut
diff -u libibtk-0.0.14/debian/changelog libibtk-0.0.14/debian/changelog
--- libibtk-0.0.14/debian/changelog
+++ libibtk-0.0.14/debian/changelog
@@ -1,3 +1,10 @@
+libibtk (0.0.14-12.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 06 Sep 2020 14:25:05 +0200
+
 libibtk (0.0.14-12.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libibtk-0.0.14/debian/rules libibtk-0.0.14/debian/rules
--- libibtk-0.0.14/debian/rules
+++ libibtk-0.0.14/debian/rules
@@ -23,9 +23,7 @@
 configure-stamp:
dh_testdir
dh_update_autotools_config
-   # Add here commands to configure the package.
-   ./configure --enable-shared --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info 
--sysconfdir=/etc
-
+   dh_auto_configure -- --enable-shared
touch configure-stamp
 
 build: build-stamp

Bug#969572: ITP: python-duniterpy - Duniter Python API

[moul]

Ok, then most likely Poetry needs to be integrated into this Python 
build system.


On So, Sep 6, 2020 at 12:17, Jonas Smedegaard  wrote:

Quoting moul (2020-09-06 11:51:03)

 I do not think Poetry is required for the packaging.
 This this the software used for the development environment.
 The only interesting things to take are the runtime dependencies 
from

 the pyproject.toml.
 And may be some description out of this file.


It seems to me that Poetry replaces setup.py with pyproject.toml, and
therefore changes how build is bootstrapped.

Debian packaging uses a set of wrappers called "pybuild":


With pybuild defaults, build fails with "cannot detect build system".

With "export PYBUILD_SYSTEM=distutils", build fails with "can't open
file 'setup.py'".

If Peotry is not needed, then how to initiate a build?


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: 

 [x] quote me freely  [ ] ask before reusing  [ ] keep private