Bug#954070: fdroidserver: Incorrect Litecoin address validation

[Pierre Rudloff]

Package: fdroidserver
Version: 1.1.4-1~deb10u1
Severity: normal

Hello,

When using fdroid on the latest fdroiddata repository, I get this error:
CRITICAL: 'MTuf45ZvxhMWWo4v8YBbFDTLsFcGtpcPNT' is not a valid Litecoin address
in com.readrops.app. Regex pattern: ^L[a-zA-Z0-9]{33}$

But this Litecoin address is valid.

This has already been fixed upstream:
https://gitlab.com/fdroid/fdroidserver/-/merge_requests/644

Regards,



-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fdroidserver depends on:
ii  androguard   3.3.3-1
ii  default-jdk-headless 2:1.11-71
ii  openjdk-11-jdk-headless  11.0.6+10-1~deb10u1
ii  python3  3.7.3-1
ii  python3-clint0.5.1-1
ii  python3-defusedxml   0.5.0-2
ii  python3-git  2.1.11-1
ii  python3-libcloud 2.4.0-1
ii  python3-mwclient 0.8.7-1
ii  python3-paramiko 2.6.0-1~bpo10+1
ii  python3-pil  5.4.1-2+deb10u1
ii  python3-pyasn1   0.4.2-3
ii  python3-pyasn1-modules   0.2.1-0.2
ii  python3-qrcode   6.1-1
ii  python3-requests 2.21.0-1
ii  python3-ruamel.yaml  0.15.34-1+b1
ii  python3-vagrant  0.5.15-2
ii  python3-yaml 3.13-2
ii  rsync3.1.3-6

Versions of packages fdroidserver recommends:
ii  android-sdk 25.0.0+11+deb10u1
ii  apksigner   0.8-2
ii  git 1:2.20.1-2+deb10u1
ii  gnupg   2.2.12-1+deb10u1
ii  opensc  0.19.0-1
ii  openssh-client  1:7.9p1-10+deb10u2
pn  s3cmd   
ii  wget1.20.1-1.1
ii  zipalign1:8.1.0+r23-2

Versions of packages fdroidserver suggests:
ii  gradle   4.4.1-6
pn  qemu-kvm 
ii  vagrant  2.2.3+dfsg-1
pn  vagrant-cachier  
ii  vagrant-libvirt  0.0.45-2

-- no debconf information

Bug#953989: NMU debdiff (borgbackup reports installed python3-msgpack is incompatible)

[Scott Kitterman]

The attached solves the problem for now.  Please let me know if you would 
prefer I not upload this.  I realize it's not ideal, but it is the only 
immediate solution I can see (and avoiding embedded libs is a policy should, 
not a must, so I think it's OK in this case).

Scott Kdiff -Nru borgbackup-1.1.11/debian/changelog borgbackup-1.1.11/debian/changelog
--- borgbackup-1.1.11/debian/changelog	2020-03-14 03:51:19.0 -0400
+++ borgbackup-1.1.11/debian/changelog	2020-03-16 06:25:57.0 -0400
@@ -1,3 +1,11 @@
+borgbackup (1.1.11-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Temporarily use internal msgpack to fix FTBFS and fix borgbackup to work
+again (Closes: #953989)
+
+ -- Scott Kitterman   Mon, 16 Mar 2020 06:25:57 -0400
+
 borgbackup (1.1.11-2) unstable; urgency=medium
 
   [ Andrej Shadura ]
diff -Nru borgbackup-1.1.11/debian/patches/series borgbackup-1.1.11/debian/patches/series
--- borgbackup-1.1.11/debian/patches/series	2020-03-14 03:51:19.0 -0400
+++ borgbackup-1.1.11/debian/patches/series	2020-03-16 06:25:53.0 -0400
@@ -1,3 +1,3 @@
 privacy/0001-Remove-codecov.io-and-travis-ci.org-badges.patch
 privacy/0002-README.rst-Replace-img-src-with-text-link.patch
-system-msgpack.patch
+#system-msgpack.patch


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

Bug#954021: Please detect use of staff group (and 2775 permissions) in maintainer scripts without checking staff-group-for-usr-local

[Josh Triplett]

On Sun, Mar 15, 2020 at 03:28:41PM -0700, Felix Lechner wrote:
> On Sun, Mar 15, 2020 at 1:18 PM Josh Triplett  wrote:
> > Policy version 4.1.4, in April 2018, states that /usr/local and 
> > subdirectories
> > should only have group "staff" if /etc/staff-group-for-usr-local exists,
> > and otherwise they should have group "root". Many packages still
> > unconditionally chown directories to root:staff, or chmod directories to
> > 2755.
> 
> What is an acceptable way to identify such scripts? Would it be a
> successful 'grep root[:.]staff', followed by an unsuccessful 'grep
> staff-group-for-usr-local'?

Yes, that would suffice. (Note that you *don't* need to check for
mentions of "/usr/local", since this should affect any use of the staff
group.)

I would also suggest looking for mentions of "dh_usrlocal" without a
mention of staff-group-for-usr-local, which would indicate a need to
rebuild with a newer debhelper (11.2 or newer). (This is an issue in
real packages, not a theoretical issue.)

All of those checks should only be applied to postinst, preinst, or I
suppose config; prerm may *correctly* mention dh_usrlocal without
mentioning staff-group-for-usr-local, as they just have snippets to run
rmdir.

On Sun, Mar 15, 2020 at 10:36:05PM +, Chris Lamb wrote:
> Josh, another way to help answer this might be to link to some
> offending packages if you have them handy.

$ grep -l -e 'root[:.]staff' -e dh_usrlocal 
/var/lib/dpkg/info/*.{postinst,preinst,config} | xargs grep -L 
staff-group-for-usr-local
/var/lib/dpkg/info/angband.postinst
/var/lib/dpkg/info/flex.postinst
/var/lib/dpkg/info/fontconfig-config.postinst
/var/lib/dpkg/info/python2.7-minimal.postinst
/var/lib/dpkg/info/python2.7.postinst
/var/lib/dpkg/info/python3.7-minimal.postinst
/var/lib/dpkg/info/python3.8-minimal.postinst
/var/lib/dpkg/info/tex-common.postinst
/var/lib/dpkg/info/ucf.postinst
/var/lib/dpkg/info/vim-latexsuite.postinst

angband, flex, and ucf seem to mention root:staff only in commented-out
code, but I don't think it's worth taking any effort to not flag those;
that commented-out code is still wrong and should be removed as
irrelevant to the package.

The rest all have this bug.

Hope that helps,
Josh Triplett

Bug#954068: ITP: metview-python -- Python(3) wrapper to the Metview package

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: metview-python
  Version : 1.1.2
  Upstream Author : European Centre for Medium-Range Weather Forecasts (ECMWF)
* URL : https://github.com/ecmwf/metview-python
* License : Apache-2
  Programming Lang: Python, C
  Description : Python(3) wrapper to the Metview package

This is a Python interface to the Metview Meteorological Visualisation package.
Metview is already part of Debian.

Bug#954067: Suggestion: run certbot plugins --prepare in postinst

[Martin Habovstiak]

Package: certbot
Version: 0.31.0-1
Severity: wishlist

Dear Maintainer,

as discussed in https://github.com/certbot/certbot/issues/7584 Debian packages
don't run `certbot plugins --prepare` in postinst, thus some important
configuration files are missing in /etc/letsencrypt. This is not a problem when
the user uses built-in nginx/apache plugin directly, as that one handles the
situation itself, but becomes problematic, if the user generates configuration
from templates (the upstream tools have no way of configuring that) or does some
other special thing.

>From the discussion I learned that the content of those files depends on
versions of installed packages. Thus, I propose to run the command in postinst
of certbot and add triggers to re-run it when nginx, apache,
python3-certbot-nginx, python3-certbot-apache or openssl updates. I'm not sure
if it's better to use activates update-certbot directive in those five packages
or add file-based triggers to certbot. I think you're more experienced in
deciding that and I don't care about this detail at all.

People could implement monitoring by themselves, but it might be useful having
it in Debian directly in order to avoid duplication.

For the record, I've previously sent an e-mail wit similar wording to the Debian
Letsencrypt team. Harlan Lieberman-Berg replied saying it's a good idea
and asked me to file this bug. Notable change between that e-mail and
this report is addition of the plugins to the list of triggering
packages as I expect them to be important too and forgot to mention them
previously.

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

Kernel: Linux 4.19.100-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

Versions of packages certbot depends on:
ii  python3  3.7.3-1
ii  python3-certbot  0.31.0-1

certbot recommends no packages.

Versions of packages certbot suggests:
pn  python-certbot-doc  
pn  python3-certbot-apache  
ii  python3-certbot-nginx   0.31.0-1

-- no debconf information

Bug#954065: gnome-shell: Could not allocate offscreen buffer storage

[Harald Dunkel]

Hi Simon,

On 2020-03-16 09:20, Simon McVittie wrote:


Do you use chromium, Chrome, Electron or qtwebengine?



I am just the messenger, but AFAICT its Google Chrome. However, the process
id 3434 (mentioned in syslog) belongs to gnome-shell. I think its unwise to
generate appr 12000 syslog messages per minute, so I still think thats a bug
in gnome-shell. There is no indication that Chrome cannot be used to browse
the web.


Recent versions of GNOME Shell are meant to give each launched app its own
connection to the systemd journal so that log messages are correctly
attributed to the app, but apparently that isn't working here and the
messages end up output to a logging file descriptor that is inherited from
GNOME Shell. How do you launch the chromium-based app?



Parent process of Chrome is gnome-shell, package version 3.30.2-11~deb10u1.


Regards
Harri

Bug#953942: jack: should this package be removed?

[Michael Banck]

Hi,

On Sun, Mar 15, 2020 at 11:56:00AM -0400, Sandro Tosi wrote:
> On Sun, Mar 15, 2020 at 3:01 AM Michael Banck  wrote:
> > On Sat, Mar 14, 2020 at 03:33:34PM -0400, Sandro Tosi wrote:
> > > I believe this package should be removed:
> > >
> > > * python2-only
> > > * no upstream release since 2004 (!) or svn update since  2005 (!)
> > > * it's keeping several python2 modules in debian that could be dropped if 
> > > jack
> > >   is removed too
> > > * several alternatives exist that are much more populare than jack
> > >
> > > if i dont hear back within a week with a good reason to keep this 
> > > package, i'll
> > > file for its removal.
> >
> > I find a week way too short for these kind of things, especially in the
> > current conditions.
> 
> I set a week of time for an *answer*, not to do the actual work.
> 
> i think i did not see what you think about the removal of jack: is it
> worth to keep a 15 years old application in debian (which transitively
> keeps in the archive several python2 packages, that could be dropped
> as soon as jack is removed)? are you planning on porting it to python3
> (i googled if a port was already available but i couldnt find any)? if
> so, did you start already? where can we track progress?

Dude, I'm trying to keep my family alive right now. If you think
removing jack will save the world, by all means, go for it.


Michael

Bug#954065: gnome-shell: Could not allocate offscreen buffer storage

[Phil Wyett]

On Mon, 2020-03-16 at 08:21 +0100, Harald Dunkel wrote:
> Package: gnome-shell
> Version: 3.30.2-11~deb10u1
> 
> Within a few hours gnome-shell wrote >20 GByte into
> /var/log/{messages,syslog,user.log}:
> 
> :
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.705821:ERROR:gles2_cmd_decoder.cc(4007)]
> ContextResult::kFatalFailure: Could not allocate offscreen buffer
> storage.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.708524:ERROR:gles2_cmd_decoder.cc(5815)]
> GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen
> FBO was incomplete.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.708882:ERROR:gles2_cmd_decoder.cc(4007)]
> ContextResult::kFatalFailure: Could not allocate offscreen buffer
> storage.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.711468:ERROR:gles2_cmd_decoder.cc(5815)]
> GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen
> FBO was incomplete.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.711779:ERROR:gles2_cmd_decoder.cc(4007)]
> ContextResult::kFatalFailure: Could not allocate offscreen buffer
> storage.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.714068:ERROR:gles2_cmd_decoder.cc(5815)]
> GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen
> FBO was incomplete.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.714382:ERROR:gles2_cmd_decoder.cc(4007)]
> ContextResult::kFatalFailure: Could not allocate offscreen buffer
> storage.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.716740:ERROR:gles2_cmd_decoder.cc(5815)]
> GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen
> FBO was incomplete.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.717090:ERROR:gles2_cmd_decoder.cc(4007)]
> ContextResult::kFatalFailure: Could not allocate offscreen buffer
> storage.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.719380:ERROR:gles2_cmd_decoder.cc(5815)]
> GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen
> FBO was incomplete.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.719664:ERROR:gles2_cmd_decoder.cc(4007)]
> ContextResult::kFatalFailure: Could not allocate offscreen buffer
> storage.
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]:
> [8045:8045:0315/020158.722410:ERROR:gles2_cmd_decoder.cc(5815)]
> GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen
> FBO was incomplete.
> :
> 
> Then the partition was full and logrotate failed.
> 
> 
> Regards
> Harri
> 

Hi,

Could you add a little more information regarding how this issue came
about and the software you are generally running?

Is this a long standing buster install?

Issues of this type via google search seem to often come back to
chrome/chromium. Is one of these your default browser?

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#939983: closed by Thorsten Glaser (Re: [Pkg-libvirt-maintainers] Bug#939983: error: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers')

[Guido Günther]

Hi,
On Mon, Mar 16, 2020 at 12:45:05AM +, Debian Bug Tracking System wrote:
[..snip..]

> Now in sid, thanks! (The NEWS entry comes too late btw — after apt
> first had tried to remove elogind entirely, until one things of just
> running a-g i libvirt0… might wish to add to the release notes for
> bullseye…)

yes, this needs to go into the release notes too.
Cheers,
 -- Guido

Bug#954071: matplotlib: Circular dependency chain with python3-sphinx-gallery

[John Paul Adrian Glaubitz]

Source: matplotlib
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

It's no longer possible to bootstrap matplotlib using the stage1 profile
since python3-sphinx-gallery depends on python3-matplotlib itself.

Can you mark python3-sphinx-gallery also as "" if possible?

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#953795: unicode-data: Missing emoji*.txt after upgrading to 13.0.0

[Changwoo Ryu]

Control: severity -1 normal

It seems that ibus is the only FTBFS package by this issue.  So I
decided to include emoji-test.txt in the ibus source (at least for
now).

I'm lowering the severity.

Bug#954065: gnome-shell: Could not allocate offscreen buffer storage

[Simon McVittie]

On Mon, 16 Mar 2020 at 11:00:09 +0100, Harald Dunkel wrote:
> On 2020-03-16 09:20, Simon McVittie wrote:
> > Do you use chromium, Chrome, Electron or qtwebengine?
> 
> I am just the messenger, but AFAICT its Google Chrome. However, the process
> id 3434 (mentioned in syslog) belongs to gnome-shell.

I'm fairly sure that's because Chrome has inherited a logging file
descriptor from GNOME Shell. The PID is recorded at the time the file
descriptor is opened, not at the time the message is actually logged.

> I think its unwise to
> generate appr 12000 syslog messages per minute, so I still think thats a bug
> in gnome-shell.

I don't think it is gnome-shell that is generating these messages.

If you run Chrome from a terminal (gnome-terminal or xterm or similar),
or ask the user to do so if you are reporting this bug on behalf of
someone else, then I suspect you will find that the warnings stop appearing
in the system log, and start appearing in the terminal instead.

Another way to check whether I'm correct would be to edit Chrome's .desktop
file(s) and change all the Exec= lines (there might be more than one) to use
systemd-cat, something like this:

 [Desktop Entry]
 ...
-Exec=/path/to/chrome-binary %U
+Exec=systemd-cat -t chrome /path/to/chrome-binary %U

> > How do you launch the chromium-based app?
> 
> Parent process of Chrome is gnome-shell, package version 3.30.2-11~deb10u1.

That's consistent with my theory, but doesn't fully answer my question.

There are several ways to launch an app from GNOME Shell, which end up in
different code paths, including:

- open overview ("Activities"), click on an app
- open overview, click-and-hold or right-click on an app, "New Window"

Some Shell extensions might also influence how apps are launched. Are you
(or the user, if you are passing on a bug report from someone else) using
any Shell extensions? If so, which ones?

I think the current situation is that just clicking on an app will usually
result in its stdout/stderr being logged as though they came from that
app, but "New Window" will often result in its stdout/stderr being
logged as though they came from GNOME Shell. I've opened an upstream
issue about that, but it will not be straightforward to fix (it's likely
to require new API in GLib).

I don't know whether that's the case you're hitting here, though.

smcv

Bug#954069: please move to hourly cron jobs and and set maxsize

[Harald Dunkel]

Package: rsyslog
Version: 8.1901.0-1
Severity: wishlist

Using syslog it is easy to write a few GBytes/hour logfiles, e.g. via
#954065, so I would suggest to run the logrotate for rsyslog hourly
and to set

maxsize 1G

per default. In the new configuration the "daily" and "weekly" in
/etc/logrotate.d/rsyslog still provides daily and weekly log file
roration for 99.9% of all cases, but for the remaining 0.1% the
maxsize is essential to not end up in a full partition for /var/log.


Regards
Harri

Bug#954072: fdroidserver: --server option not working

[Pierre Rudloff]

Package: fdroidserver
Version: 1.1.4-1~deb10u1
Severity: normal

Hello,

Running "fdroid build" with the "--server" option fails with this error:
  File "/usr/lib/python3/dist-packages/fdroidserver/build.py", line 1078, in
main
options.onserver, options.refresh):
  File "/usr/lib/python3/dist-packages/fdroidserver/build.py", line 849, in
trybuild
build_server(app, build, vcs, build_dir, output_dir, log_dir, force)
  File "/usr/lib/python3/dist-packages/fdroidserver/build.py", line 135, in
build_server
ftp.put(os.path.join(serverpath, '..', 'fdroid'), 'fdroid')
  File "/usr/lib/python3/dist-packages/paramiko/sftp_client.py", line 757, in
put
file_size = os.stat(localpath).st_size
FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/python3/dist-
packages/fdroidserver/../fdroid'

It is because it tries to copy fdroidserver to the build VM, but when using the
Debian package, the fdroid executable is not where expected.
There is some discussion about this upstream:
https://gitlab.com/fdroid/fdroidserver/-/issues/415

Regards,



-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fdroidserver depends on:
ii  androguard   3.3.3-1
ii  default-jdk-headless 2:1.11-71
ii  openjdk-11-jdk-headless  11.0.6+10-1~deb10u1
ii  python3  3.7.3-1
ii  python3-clint0.5.1-1
ii  python3-defusedxml   0.5.0-2
ii  python3-git  2.1.11-1
ii  python3-libcloud 2.4.0-1
ii  python3-mwclient 0.8.7-1
ii  python3-paramiko 2.6.0-1~bpo10+1
ii  python3-pil  5.4.1-2+deb10u1
ii  python3-pyasn1   0.4.2-3
ii  python3-pyasn1-modules   0.2.1-0.2
ii  python3-qrcode   6.1-1
ii  python3-requests 2.21.0-1
ii  python3-ruamel.yaml  0.15.34-1+b1
ii  python3-vagrant  0.5.15-2
ii  python3-yaml 3.13-2
ii  rsync3.1.3-6

Versions of packages fdroidserver recommends:
ii  android-sdk 25.0.0+11+deb10u1
ii  apksigner   0.8-2
ii  git 1:2.20.1-2+deb10u1
ii  gnupg   2.2.12-1+deb10u1
ii  opensc  0.19.0-1
ii  openssh-client  1:7.9p1-10+deb10u2
pn  s3cmd   
ii  wget1.20.1-1.1
ii  zipalign1:8.1.0+r23-2

Versions of packages fdroidserver suggests:
ii  gradle   4.4.1-6
pn  qemu-kvm 
ii  vagrant  2.2.3+dfsg-1
ii  vagrant-cachier  1.2.1-3
ii  vagrant-libvirt  0.0.45-2

-- no debconf information

Bug#953894: [Pkg-libvirt-maintainers] Bug#953894: libvirt-daemon: hangs on update, file conflicts

[Guido Günther]

Hi,
On Mon, Mar 16, 2020 at 04:54:22PM +0900, Norbert Preining wrote:
> Hi Guido,
> 
> thanks for your answer.
> 
> On Mon, 16 Mar 2020, Guido Günther wrote:
> > There should be somethin in the journal about the above error, could you
> > add that to the bug report?
> 
> Looking at the logs it looks like the missing replace/conflicts are the
> problem:
> 
> libvirtd[1429970]: internal error: Failed to load module 
> '/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_libxl.so':
>  /usr/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_5.6.0' not 
> found (required by 
> /usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_libxl.so)
> Failed to start Virtualization daemon.

Seems it tries to pick up the old .so due to the upgrade failure. Thanks
for following up!
 -- Guido

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

Bug#954073: buster-pu: package postfix/3.4.9-0+10debu1

[Scott Kitterman]

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

This is the next in the normal series of postfix bugfix updates.  This
update has a single fix for a long standing milter processing error.  It
should be low risk and is in Testing already.

Bugfix (introduced: Postfix 2.3): panic with Postfix
multi-Milter configuration during MAIL FROM. Milter client
state was not properly reset after one of the Milters failed.
Reported by WeiYu Wu.

As usual, I have this version running on several machines of my own with
no issues noted.  Debdiff attached.  Please approve so I can upload.

Thanks,

Scott K
diff -Nru postfix-3.4.9/debian/changelog postfix-3.4.10/debian/changelog
--- postfix-3.4.9/debian/changelog  2020-02-16 01:30:10.0 -0500
+++ postfix-3.4.10/debian/changelog 2020-03-16 06:37:22.0 -0400
@@ -1,3 +1,15 @@
+postfix (3.4.10-0deb10u1) UNRELEASED; urgency=medium
+
+  [Wietse Venema]
+
+  * 3.4.10
+- Bugfix (introduced: Postfix 2.3): panic with Postfix
+  multi-Milter configuration during MAIL FROM. Milter client
+  state was not properly reset after one of the Milters failed.
+  Reported by WeiYu Wu.
+
+ -- Scott Kitterman   Mon, 16 Mar 2020 06:37:22 -0400
+
 postfix (3.4.9-0+10debu1) buster; urgency=medium
 
   [Scott Kitterman]
diff -Nru postfix-3.4.9/HISTORY postfix-3.4.10/HISTORY
--- postfix-3.4.9/HISTORY   2020-02-02 12:51:46.0 -0500
+++ postfix-3.4.10/HISTORY  2020-03-12 10:58:26.0 -0400
@@ -24339,3 +24339,10 @@
macros were evaluated before the Milter connection itself
had been negotiated. Problem reported by David Bürgin.
Files: milter/milter.h, milter/milter.c, milter/milter8.c
+
+20200312
+
+   Bugfix (introduced: Postfix 2.3): panic with Postfix
+   multi-Milter configuration during MAIL FROM. Milter client
+   state was not properly reset after one of the Milters failed.
+   Reported by WeiYu Wu.
diff -Nru postfix-3.4.9/src/global/mail_version.h 
postfix-3.4.10/src/global/mail_version.h
--- postfix-3.4.9/src/global/mail_version.h 2020-02-02 15:13:52.0 
-0500
+++ postfix-3.4.10/src/global/mail_version.h2020-03-12 10:52:04.0 
-0400
@@ -20,8 +20,8 @@
   * Patches change both the patchlevel and the release date. Snapshots have no
   * patchlevel; they change the release date only.
   */
-#define MAIL_RELEASE_DATE  "20200203"
-#define MAIL_VERSION_NUMBER"3.4.9"
+#define MAIL_RELEASE_DATE  "20200312"
+#define MAIL_VERSION_NUMBER"3.4.10"
 
 #ifdef SNAPSHOT
 #define MAIL_VERSION_DATE  "-" MAIL_RELEASE_DATE
diff -Nru postfix-3.4.9/src/smtpd/smtpd.c postfix-3.4.10/src/smtpd/smtpd.c
--- postfix-3.4.9/src/smtpd/smtpd.c 2019-06-29 09:33:39.0 -0400
+++ postfix-3.4.10/src/smtpd/smtpd.c2020-03-12 10:43:18.0 -0400
@@ -2605,6 +2605,7 @@
 }
 if (state->milters != 0
&& (state->saved_flags & MILTER_SKIP_FLAGS) == 0) {
+   state->flags |= SMTPD_FLAG_NEED_MILTER_ABORT;
PUSH_STRING(saved_sender, state->sender, STR(state->addr_buf));
err = milter_mail_event(state->milters,
milter_argv(state, argc - 2, argv + 2));
@@ -2720,11 +2721,14 @@
state->queue_id = 0;
 }
 if (state->sender) {
-   if (state->milters != 0)
-   milter_abort(state->milters);
myfree(state->sender);
state->sender = 0;
 }
+/* WeiYu Wu: need to undo milter_mail_event() state change. */
+if (state->flags & SMTPD_FLAG_NEED_MILTER_ABORT) {
+   milter_abort(state->milters);
+   state->flags &= ~SMTPD_FLAG_NEED_MILTER_ABORT;
+}
 if (state->verp_delims) {
myfree(state->verp_delims);
state->verp_delims = 0;
diff -Nru postfix-3.4.9/src/smtpd/smtpd.h postfix-3.4.10/src/smtpd/smtpd.h
--- postfix-3.4.9/src/smtpd/smtpd.h 2018-08-23 08:51:53.0 -0400
+++ postfix-3.4.10/src/smtpd/smtpd.h2020-03-12 10:43:18.0 -0400
@@ -206,6 +206,7 @@
 #define SMTPD_FLAG_ILL_PIPELINING  (1<<1)  /* inappropriate pipelining */
 #define SMTPD_FLAG_AUTH_USED  (1<<2)   /* don't reuse SASL state */
 #define SMTPD_FLAG_SMTPUTF8   (1<<3)   /* RFC 6531/2 transaction */
+#define SMTPD_FLAG_NEED_MILTER_ABORT (1<<4)/* undo milter_mail_event() */
 
  /* Security: don't reset SMTPD_FLAG_AUTH_USED. */
 #define SMTPD_MASK_MAIL_KEEP \

Bug#954074: Fn key for Bluetooth Apple Magic Keyboard - simple patch

[DVE - Gabriele Brugnoni]

Package: linux-image-4.19.0-8-amd64
Version: 4.19.98-1


Hello.

I'm using Debian Buster with kernel 4.19.0-8.

I would like to signal a very small patch that sould be applyied in
kernel 4.19 and future versions, to fix a problem with Apple magic
keyboard when connected via Bluetooth.

This keyboard works well when connected via USB, but when connected via
Bluethoot, the FN key is not recognised.

This bugs has been fixed in 2015, as reported here:

https://bugzilla.kernel.org/show_bug.cgi?id=99881#c41

but has you can see at the end of the page, the problem is still
present in new kernels 4.xx.

There is a little patch that fix the problem, the link is reported at
the end of the same page, this is the link:

https://lkml.org/lkml/2020/1/29/61


I've build the kernel 2.4.19 from source with that patch and after
installation the "fn" key of the keyboard works perfectly.


I hope this may be helpfull to fix this problem.

Thank you very mutch for your time and support.

Regards.


-- 
Gabriele Brugnoni

DVE Progettazione Elettronica
Via Solferino, 8 - 21020 Casciago (VA)
Tel (+39) 0332 229091
email: i...@developembedded.com
web:   http://www.developembedded.com



CONFIDENZIALE: Questa email ed i relativi allegati contengono 
informazioni confidenziali e riservate esclusivamente ai DESTINATARI 
specificati in indirizzo.
Se l'avete ricevuta per errore Vi chiediamo di informarci via e-mail 
o al numero +39 0332 229091 e di distruggere l'originale.
Qualunque utilizzazione, divulgazione o copia non autorizzata
di questa comunicazione è rigorosamente vietata e comporta violazione
delle disposizioni di legge sulla tutela dei dati personali
(D.Lgs.196/2003).
Grazie per la collaborazione.


CONFIDENTIAL: This  e-mail  and  any attachments are confidential and
may contain reserved information.
If you are not one of the named recipients, please notify the 
sender immediately. Moreover, you should not disclose the contents 
to any other person, nor should the information contained be used 
for any purpose or stored or copied in any form.
Thank you.

Bug#953971: Please add at-spi2-core to the build-dependencies so the tests on hurd-i386 can succeed

[Guido Günther]

Dear hurd maintainers,
On Sun, Mar 15, 2020 at 09:05:54AM +0100, Laurent Bigonville wrote:
> Source: libhandy
> Version: 0.0.12-1
> Severity: normal
> 
> Hi,
> 
> It seems that currently libhandy FTBFS on hurd-i386.
> 
> Adding "at-spi2-core [hurd-i386] " to the build-dependencies
> fixes the problem

Do you have an idea why this does not happen on other platforms? We
don't pull in at-spi2-core there either. Build log is here:

  
https://buildd.debian.org/status/fetch.php?pkg=libhandy=hurd-i386=0.0.13-1=1584192605=0

Cheers,
 -- Guido

> 
> Kind regards,
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
> 

Bug#954019: /lib/systemd/system/systemd-ask-password-console.service:20: Executable "systemd-tty-ask-password-agent" not found in path

[Michael Biebl]

Am 16.03.20 um 08:19 schrieb Michael Biebl:

> Just installed dracut inside a clean bullseye test VM.
> The generated initrd did not contain the binary.
> 
> 

Running dracut --debug I get
/usr/lib/dracut/modules.d/90crypt/module-setup.sh@9(check): [[ -n -h ]]
/usr/lib/dracut/modules.d/90crypt/module-setup.sh@10(check): for fs in
"${host_fs_types[@]}"
/usr/lib/dracut/modules.d/90crypt/module-setup.sh@11(check): [[ vfat =
\c\r\y\p\t\o\_\L\U\K\S ]]
/usr/lib/dracut/modules.d/90crypt/module-setup.sh@10(check): for fs in
"${host_fs_types[@]}"
/usr/lib/dracut/modules.d/90crypt/module-setup.sh@11(check): [[ ext4 =
\c\r\y\p\t\o\_\L\U\K\S ]]
/usr/lib/dracut/modules.d/90crypt/module-setup.sh@10(check): for fs in
"${host_fs_types[@]}"
/usr/lib/dracut/modules.d/90crypt/module-setup.sh@11(check): [[ swap =
\c\r\y\p\t\o\_\L\U\K\S ]]
/usr/lib/dracut/modules.d/90crypt/module-setup.sh@13(check): return 255


So it seems to exit early because I don't have any crypto partitions (my
/etc/crypttab is empty)



signature.asc
Description: OpenPGP digital signature

Bug#954019: /lib/systemd/system/systemd-ask-password-console.service:20: Executable "systemd-tty-ask-password-agent" not found in path

[intrigeri]

Hi,

Michael Biebl (2020-03-15):
> This file seems to be missing indeed in the initramfs:
>
> $ lsinitrd /boot/initrd.img-5.4.0-4-amd64 | grep 
> systemd-tty-ask-password-agent
> 

FWIW: my initramfs, generated by dracut 048+80-2 on sid 2 days ago,
includes that file.

Cheers!

Bug#954019: /lib/systemd/system/systemd-ask-password-console.service:20: Executable "systemd-tty-ask-password-agent" not found in path

[Michael Biebl]

Am 16.03.20 um 07:53 schrieb intrigeri:
> Hi,
> 
> Michael Biebl (2020-03-15):
>> This file seems to be missing indeed in the initramfs:
>>
>> $ lsinitrd /boot/initrd.img-5.4.0-4-amd64 | grep 
>> systemd-tty-ask-password-agent
>> 
> 
> FWIW: my initramfs, generated by dracut 048+80-2 on sid 2 days ago,
> includes that file.

Just installed dracut inside a clean bullseye test VM.
The generated initrd did not contain the binary.




signature.asc
Description: OpenPGP digital signature

Bug#953561: closed by Debian FTP Masters (reply to Kan-Ru Chen (陳侃如) ) (Bug#953561: fixed in mupdf 1.16.1+ds1-2)

[Sebastian Rasmussen]

> >Their explanation is attached below along with your original report.
> >>   * Backport fix for upstream bug 701402 allow smart scroll to advance to 
> >> last page
> https://webcache.googleusercontent.com/search?q=cache:tp3ygt-jMzsJ:https://bugs.ghostscript.com/show_bug.cgi%3Fid%3D701402+=1=la=clnk=ba
> (bugs.ghostscript.com is currently unreachable)

bugs.ghostscript.com had a temporary unexpected glitch and should
now be back up, sorry for the inconvenience.

> What is this “smart scrolling”?

When you are zoomed in on a page in the document, smart scroll
means that instead of advancing to the next page when you press
space, MuPDF will scroll to the parts of the page outside the
zoomed in area, stepping throught them all before advancing to the
next page. This ensures that you get to see the entire page before
advancing to the next one. This was developed for mupdf-gl and
then backported to mupdf-x11 to keep the UI of the two viewers
as similar as possible.

> It’s not documented in the manual page (which documents that…
>
>. pgdn space
>   Go to the next page.
>
>, pgup b backspace
>   Go to the previous page.
>
> … these are identical).

The differences between ./, and space/b should be documented.
I'll update the man pages.

> Can we please have an option to disable “smart scrolling” if it
> breaks things like this?

MuPDF has never had any options to configure key bindings, and
I don't believe that Tor plans to add any at this time.

> I don’t want anything smart, I just want to read PDFs.

Pressing . or , lets you go to the previous/next pages without any
smart scrolling.

 / Sebastian

Bug#954065: gnome-shell: Could not allocate offscreen buffer storage

[Harald Dunkel]

Package: gnome-shell
Version: 3.30.2-11~deb10u1

Within a few hours gnome-shell wrote >20 GByte into 
/var/log/{messages,syslog,user.log}:

:
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.705821:ERROR:gles2_cmd_decoder.cc(4007)] 
ContextResult::kFatalFailure: Could not allocate offscreen buffer storage.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.708524:ERROR:gles2_cmd_decoder.cc(5815)] 
GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen FBO was 
incomplete.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.708882:ERROR:gles2_cmd_decoder.cc(4007)] 
ContextResult::kFatalFailure: Could not allocate offscreen buffer storage.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.711468:ERROR:gles2_cmd_decoder.cc(5815)] 
GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen FBO was 
incomplete.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.711779:ERROR:gles2_cmd_decoder.cc(4007)] 
ContextResult::kFatalFailure: Could not allocate offscreen buffer storage.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.714068:ERROR:gles2_cmd_decoder.cc(5815)] 
GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen FBO was 
incomplete.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.714382:ERROR:gles2_cmd_decoder.cc(4007)] 
ContextResult::kFatalFailure: Could not allocate offscreen buffer storage.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.716740:ERROR:gles2_cmd_decoder.cc(5815)] 
GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen FBO was 
incomplete.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.717090:ERROR:gles2_cmd_decoder.cc(4007)] 
ContextResult::kFatalFailure: Could not allocate offscreen buffer storage.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.719380:ERROR:gles2_cmd_decoder.cc(5815)] 
GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen FBO was 
incomplete.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.719664:ERROR:gles2_cmd_decoder.cc(4007)] 
ContextResult::kFatalFailure: Could not allocate offscreen buffer storage.
Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
[8045:8045:0315/020158.722410:ERROR:gles2_cmd_decoder.cc(5815)] 
GLES2DecoderImpl::ResizeOffscreenFramebuffer failed because offscreen FBO was 
incomplete.
:

Then the partition was full and logrotate failed.


Regards
Harri

Bug#954063: empathy: No longer works with Google Hangouts/Talk

[Bill Wohler]

Package: empathy
Version: 3.25.90+really3.12.14-2
Severity: normal

Since my upgrade from stretch to buster (and subsequently bullseye), I
can't connect to Google Hangouts/Talk with empathy. Instead, I see a
dialog with "This connection is untrusted" and the Certificate Details
list invalid2.invalid.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/3 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages empathy depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]   0.34.0-2
ii  empathy-common3.25.90+really3.12.14-2
ii  geoclue-2.0   2.5.6-1
ii  gsettings-desktop-schemas 3.34.0-2
ii  gstreamer1.0-pulseaudio   1.16.2-2
ii  libc6 2.29-10
ii  libcairo2 1.16.0-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libchamplain-0.12-0   0.12.20-1
ii  libchamplain-gtk-0.12-0   0.12.20-1
ii  libcheese-gtk25   3.34.0-1+b1
ii  libclutter-1.0-0  1.26.2+dfsg-13
ii  libclutter-gst-3.0-0  3.0.27-1
ii  libclutter-gtk-1.0-0  1.8.4-4
ii  libcogl-path201.22.4-4
ii  libcogl20 1.22.4-4
ii  libdbus-glib-1-2  0.110-5
ii  libenchant-2-22.2.8-1
ii  libfarstream-0.2-50.2.8-5
ii  libfolks-telepathy25  0.13.2-1
ii  libfolks250.13.2-1
ii  libgcr-base-3-1   3.34.0-1
ii  libgcr-ui-3-1 3.34.0-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-3
ii  libgee-0.8-2  0.20.3-1
ii  libgeocode-glib0  3.26.1-1
ii  libglib2.0-0  2.62.5-1
ii  libgoa-1.0-0b 3.34.1-1
ii  libgstreamer-plugins-base1.0-01.16.2-2
ii  libgstreamer1.0-0 1.16.2-2
ii  libgtk-3-03.24.13-1
ii  libgudev-1.0-0233-1
ii  libmission-control-plugins0   1:5.16.5-1
ii  libnotify40.7.9-1
ii  libpango-1.0-01.42.4-8
ii  libpulse-mainloop-glib0   13.0-5
ii  libpulse0 13.0-5
ii  libsecret-1-0 0.19.1-1
ii  libsoup2.4-1  2.70.0-1
ii  libtelepathy-farstream3   0.6.2-1+b2
ii  libtelepathy-glib00.24.1-2+b1
ii  libtelepathy-logger3  0.8.2-4
ii  libwebkit2gtk-4.0-37  2.26.4-1
ii  libx11-6  2:1.6.9-2
ii  libxml2   2.9.10+dfsg-4
ii  telepathy-logger  0.8.2-4
ii  telepathy-mission-control-5   1:5.16.5-1

Versions of packages empathy recommends:
ii  gnome-contacts   3.34-2
ii  gvfs-backends1.44.0-1
ii  sound-theme-freedesktop  0.8-2
ii  telepathy-gabble 0.18.4-1+b1
ii  telepathy-haze   0.8.0-2.1
ii  telepathy-salut  0.8.1-5.1

Versions of packages empathy suggests:
ii  telepathy-idle  0.2.0-2+b1
ii  vino3.22.0-5

Versions of packages empathy is related to:
ii  telepathy-gabble [telepathy-connection-manager]  0.18.4-1+b1
ii  telepathy-haze [telepathy-connection-manager]0.8.0-2.1
ii  telepathy-idle [telepathy-connection-manager]0.2.0-2+b1
ii  telepathy-rakia [telepathy-connection-manager]   0.8.0-3+b1
ii  telepathy-salut [telepathy-connection-manager]   0.8.1-5.1

-- no debconf information

-- 
Bill Wohler  aka 
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Bug#953894: [Pkg-libvirt-maintainers] Bug#953894: libvirt-daemon: hangs on update, file conflicts

[Norbert Preining]

Hi Guido,

thanks for your answer.

On Mon, 16 Mar 2020, Guido Günther wrote:
> There should be somethin in the journal about the above error, could you
> add that to the bug report?

Looking at the logs it looks like the missing replace/conflicts are the
problem:

libvirtd[1429970]: internal error: Failed to load module 
'/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_libxl.so': 
/usr/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_5.6.0' not 
found (required by 
/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_libxl.so)
Failed to start Virtualization daemon.

Best

Norbert

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

Bug#954066: hplip: Printer HP LaserJet CP 1025 no longer works after upgrade to version 3.20.3+dfsg0-1

[Jose M Perez-Jorda]

Package: hplip
Version: 3.20.3+dfsg0-1
Severity: normal

Dear Maintainer,

  After an upgrade of my debian unstable computer, my HP LaserJet CP
  1025 printer stopped working, and jobs hanged in the queue without
  being sent to the printer.  Then I tried to reinstall the printer by
  running:

 hp-setup -i -a -x

  but I got the error:

 No device selected/specified or that supports this functionality

  Running hp-check gives the error:

 Unsupported model: HP_LaserJet_CP_1025

  Thanks!


-- Package-specific info:
Saving output in log file: /home/josema/hp-check.log

HP Linux Imaging and Printing System (ver. 3.20.3)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling the
HPLIP supplied tarball (.tar.gz or .run) to determine if the proper dependencies
are installed to successfully compile HPLIP.
2. Run-time check mode (-r or --run): Use this mode to determine if a distro
supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball   
has the proper dependencies installed to successfully run.  
3. Both compile- and run-time check mode (-b or --both) (Default): This mode
will check both of the above cases (both compile- and run-time dependencies).   

Check types:
a. EXTERNALDEP - External Dependencies  
b. GENERALDEP - General Dependencies (required both at compile and run time)
c. COMPILEDEP - Compile time Dependencies   
d. [All are run-time checks]
PYEXT SCANCONF QUEUES PERMISSION

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

/usr/bin/hp-check:685: SyntaxWarning: "is not" with a literal. Did you mean 
"!="?
  if 'getfacl' not in g and '' is not g and 'file' not in g:
warning: debian gnu/linux distro is not found in AUTH_TYPES
warning: debian-unstable version is not supported. Using debian-10.2 versions 
dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) GNU/Linux
 Host: obila
 Proc: 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) GNU/Linux
 Distribution: debian unstable
 Bitness: 64 bit


---
| HPLIP CONFIGURATION |
---

HPLIP-Version: HPLIP 3.20.3
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian 
distro  unstable version 

Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.20.3

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip
html=/usr/share/doc/hplip-doc
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=no
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=no
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.20.3
restricted-build=no
ui-toolkit=qt5
qt3=no
qt4=no
qt5=yes
policy-kit=yes
lite-build=no
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no
apparmor_build=no
class-driver=no


Current contents of '/var/lib/hp/hplip.state' file:
[plugin]
installed = 1
eula = 1
version = 3.18.12



Current contents of '~/.hplip/hplip.conf' file:
[last_used]
device_uri = hp:/usb/HP_LaserJet_CP_1025?serial=0W042K3RPR1a

[installation]
date_time = 03/16/20 08:40:50
version = 3.20.3


 


-
| External Dependencies |
-

 error: cups  CUPS - Common Unix Printing System
   REQUIRED1.1 -   INCOMPAT   'CUPS may not be 
installed or not running'
 gs   GhostScript - PostScript and PDF language interpreter and 
previewer REQUIRED7.059.51OK -
 error: xsane xsane - Graphical scanner frontend for SANE   
   OPTIONAL0.9 -   MISSING'xsane needs to 
be installed'
 error: scanimage 

Bug#954065: gnome-shell: Could not allocate offscreen buffer storage

[Simon McVittie]

On Mon, 16 Mar 2020 at 08:21:36 +0100, Harald Dunkel wrote:
> Within a few hours gnome-shell wrote >20 GByte into 
> /var/log/{messages,syslog,user.log}:
>
> Mar 15 02:01:58 dpcl071 org.gnome.Shell.desktop[3434]: 
> [8045:8045:0315/020158.705821:ERROR:gles2_cmd_decoder.cc(4007)] 
> ContextResult::kFatalFailure: Could not allocate offscreen buffer storage.

GNOME Shell doesn't have a source file of that name. From
codesearch.debian.net, it looks like this is most likely to be coming from
chromium (or perhaps Google Chrome or an Electron app) or qtwebengine. It
might be a bug in whichever chromium-derived renderer is in use, or a bug
in your GLES2 graphics driver.

Do you use chromium, Chrome, Electron or qtwebengine?

Recent versions of GNOME Shell are meant to give each launched app its own
connection to the systemd journal so that log messages are correctly
attributed to the app, but apparently that isn't working here and the
messages end up output to a logging file descriptor that is inherited from
GNOME Shell. How do you launch the chromium-based app?

smcv

Bug#953894: [Pkg-libvirt-maintainers] Bug#953894: libvirt-daemon: hangs on update, file conflicts

[Guido Günther]

Hi,
On Sun, Mar 15, 2020 at 12:41:26AM +0900, Norbert Preining wrote:
> Package: libvirt-daemon
> Version: 6.0.0-2
> Severity: grave
> Justification: renders package unusable
> 
> Updating to 6.0.0-2 hangs indefinitely:
> ...
> Setting up libvirt-daemon-system (6.0.0-2) ...
> Installing new version of config file 
> /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper ...
> Installing new version of config file /etc/libvirt/libvirtd.conf ...
> Installing new version of config file /etc/libvirt/qemu.conf ...
> Installing new version of config file /etc/libvirt/virtlockd.conf ...
> Installing new version of config file /etc/libvirt/virtlogd.conf ...
> Job failed. See "journalctl -xe" for details.
> Job for libvirtd.service failed because the control process exited
> with error code.

There should be somethin in the journal about the above error, could you
add that to the bug report?

> See "systemctl status libvirtd.service" and "journalctl -xe" for details.
> virtlockd.service is a disabled or a static unit not running, not starting it.
> virtlogd.service is a disabled or a static unit not running, not starting it.
> 
> 
> 
> no reaction after this for long time. 
> 
> It seems that
>   virsh connect
> is running but never actually succeeds.
> 
> No further updates or configuration is done.
> 
> 
> Furthermore, during update, you have some missing file
> replace/breaks/...
> 
> Unpacking libvirt-daemon-driver-lxc (6.0.0-2) over (5.6.0-3) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-nxkUMr/10-libvirt-daemon-driver-lxc_6.0.0-2_amd64.deb 
> (--unpack):
>  trying to overwrite '/usr/share/augeas/lenses/libvirtd_lxc.aug', which is 
> also in package libvirt-daemon 5.6.0-3
> Preparing to unpack .../11-libvirt-daemon-driver-xen_6.0.0-2_amd64.deb ...
> Unpacking libvirt-daemon-driver-xen (6.0.0-2) over (5.6.0-3) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-nxkUMr/11-libvirt-daemon-driver-xen_6.0.0-2_amd64.deb 
> (--unpack):
>  trying to overwrite '/usr/share/augeas/lenses/libvirtd_libxl.aug', which is 
> also in package libvirt-daemon 5.6.0-3
> Preparing to unpack .../12-libvirt-daemon-driver-vbox_6.0.0-2_amd64.deb ...
> Unpacking libvirt-daemon-driver-vbox (6.0.0-2) over (5.6.0-3) ...
> Preparing to unpack .../13-libvirt-daemon-driver-qemu_6.0.0-2_amd64.deb ...
> Unpacking libvirt-daemon-driver-qemu (6.0.0-2) over (5.6.0-3) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-nxkUMr/13-libvirt-daemon-driver-qemu_6.0.0-2_amd64.deb 
> (--unpack):
>  trying to overwrite '/usr/share/augeas/lenses/libvirtd_qemu.aug', which is 
> also in package libvirt-daemon 5.6.0-3
> Preparing to unpack .../14-libvirt-daemon-system_6.0.0-2_amd64.deb ...
> 
> 
> Best
> 
> Norbert
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (200, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.5.9 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> 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 /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages libvirt-daemon depends on:
> ii  libblkid1   2.34-0.1
> ii  libc6   2.30-2
> ii  libcap-ng0  0.7.9-2.1+b2
> ii  libdbus-1-3 1.12.16-2
> ii  libdevmapper1.02.1  2:1.02.167-1+b1
> ii  libfuse22.9.9-3
> ii  libgcc-s1   10-20200304-1
> ii  libglib2.0-02.64.0-2
> ii  libnetcf1   1:0.2.8-1+b3
> ii  libparted2  3.3-4
> ii  libpcap0.8  1.9.1-2
> ii  libpciaccess0   0.14-1
> ii  libselinux1 3.0-1+b1
> ii  libudev1245-2
> ii  libvirt-daemon-driver-qemu  5.6.0-3
> iu  libvirt06.0.0-2
> ii  libxml2 2.9.10+dfsg-4
> 
> Versions of packages libvirt-daemon recommends:
> ii  libvirt-daemon-driver-lxc   5.6.0-3
> iu  libvirt-daemon-driver-vbox  6.0.0-2
> ii  libvirt-daemon-driver-xen   5.6.0-3
> ii  libxml2-utils   2.9.10+dfsg-4
> ii  netcat-openbsd  1.206-1
> ii  qemu-kvm1:4.2-3
> 
> Versions of packages libvirt-daemon suggests:
> pn  libvirt-daemon-driver-storage-gluster  
> pn  libvirt-daemon-driver-storage-rbd  
> pn  libvirt-daemon-driver-storage-zfs  
> iu  libvirt-daemon-system  6.0.0-2
> pn  numad  
> 
> -- no debconf information
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Bug#954062: RM: hibernate -- RoQA; Dead upstream, unmaintained

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Hi,

please consider removing hibernate from the archive.

It's dead upstream and unmaintained in Debian (for about 7 years).
See the relevant O bug report [1].
The primary interface nowadays to suspend/hibernate your system is
provided by systemd (via systemctl suspend/hibernate).


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

Bug#954064: obsolete: no longer used to build sugar-artwork

[Jonas Smedegaard]

Package: icon-slicer
Version: 0.3-8
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

icon-slicer is no longer used anywhere in Debian:
Its only reverse dependency - src:sugar-artwork

This is a reminder to drop this package from testing/unstable
when src:sugar-artwork 0.116-1 has entered testing.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl5vGtkACgkQLHwxRsGg
ASEd+w/9EPXcXkSQp4YWTu54fItM8fzhlayoa8pI7HhNHOp+jGnfqrkNrZD/Xxfe
H9d2xGF+k/Tux76o+hsi2eYg6m4cpqDG8RIeGPIyMX4rRxEvpNqBpRLMGLYj/6uQ
6PS9kgnVfQPcqk7E8GEwXUjDmi1HqmOlJiS01mMYAbdDvjdNmxlOpgGTTylhLpqx
vVp6lGL+vr3nBS0x8BwCmyJqfWxgR7MRphSZnEZf83mhx6rUxSCCLKu3eRgmRfZO
+dZCzNg6eOzZhbyxb4EsoFYfKc6ShcDJZms7vj38VMbHHgcq5C5T2tx1sR2smvqt
fMcdFz92/wh19dOvLmzoi/gS6aZROh40TtGopCMfiLi6M9czghInSzKeHbIPrQfl
t/o7C6qO1o+gK6+zhPvsiDDgeuB9pJ6QdJSYI1iqkWVQaj5KiFAw8Jpma3RD1t4l
9sLDrlE+6IgftWKaWRDlj2t5ptpLWKosxUtt+N0sMgGdXcDJ1yKNOborQkv1qNKi
Jl8j00XiMsS5Galn52m/ycsmpPTtc2uExWfBz7hcvE1CiSltkIFW4/OkXOZzbH/t
jxPyvYD9ZebmE9xO5z5Z9FJ+I6kcKwrvrR6zaGuZe673YMI7ZJOaQoHOXGQgEzlc
e4ETOs5drGvATwcZfqw6wQQbWm1eQT6ztfD/0cl6uBcj8FO7E2Y=
=T0oe
-END PGP SIGNATURE-

Bug#954075: busybox: provide a low-priority alternative for vi, view, editor

[Simon McVittie]

Package: busybox
Version: 1:1.30.1-4
Severity: wishlist

Steps to reproduce:

- Install a chroot/container
- Install busybox

Expected results:

- If a more fully-featured vi is installed (vim, vim-*, nvi, etc.) then it
  provides the vi and view commands in PATH
- Otherwise, "vi foo.txt" runs busybox vi
- Ideally, "view foo.txt" would be equivalent to "busybox vi -R foo.txt"
  (but this might require a two-line shell script wrapper or busybox code
  changes to recognise view as a command, rather than just a symlink)

- If a more fully-featured editor is installed (one of the above, or a non-vi
  editor like nano, emacs etc.) then it provides the editor command in PATH
- Otherwise, "editor foo.txt" runs busybox vi

Actual result:

- If a more fully-featured editor is installed, we get the expected result
- Otherwise, vi, view and editor are unimplemented, even though busybox could
  implement them

For editor, busybox vi should probably be a higher priority than ed, but
a lower priority than any non-minimal editor.

For vi, busybox vi should probably be a lower priority than any
separately-installed vi implementation, on the basis that if you installed
nvi or elvis-tiny or something, it's probably because you wanted to use it.

See also 
(in which I thought busybox also implemented ex, but it appears I was wrong
about that).

smcv

Bug#954077: libseccomp now available on riscv64

[Laurent Bigonville]

Source: systemd
Version: 245-2
Severity: wishlist

Hello,

libseccomp is now available on riscv64 architecture

systemd should probably enable support for it on that architecture as
well

Kind regards,

Laurent Bigonville

-- Package-specific info:

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

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

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.136
ii  libnss-systemd   245-2
ii  libpam-systemd   245-2
ii  udev 245-2

-- no debconf information

Bug#952607: transition: php (soft transition)

[Ondřej Surý]

Hi Emilio,

It certainly won’t hurt, at least I can check what FTBFS and either fix it or 
fill
a bug.

I am bit confused about php-raphf and php-propro though - I guess a manual
check will be needed.

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 16 Mar 2020, at 12:33, Emilio Pozuelo Monfort  wrote:
> 
> Hi Ondřej,
> 
> On 11/03/2020 09:57, Emilio Pozuelo Monfort wrote:
>> Ack, keep us updated on the progress here and let us know if you need 
>> anything.
>> I have added a ben tracker now, but it will take a bit to show up on the 
>> webserver.
> 
> Should I binNMU the remaining bad packages in the tracker? Or do those need
> source updates?
> 
> Cheers,
> Emilio



signature.asc
Description: Message signed with OpenPGP

Bug#953795: unicode-data: Missing emoji*.txt after upgrading to 13.0.0

[Alastair McKinstry]

The updated package ships emjoi-*.txt in debian/emoji and installs into
/usr/share/unicode/emjoi/*

Its fragile and I need to look out in future releases, but any other
solution is almost as bad, as the files are scattered across multiple
locations; UCD.zip no longer

contains all thats needed.

Regards

Alastair


On 13/03/2020 14:14, Changwoo Ryu wrote:
> Package: unicode-data
> Version: 13.0.0-1
> Severity: important
> Control: block 953775 by -1
> Control: block 953793 by -1
>
> Hello,
>
> The ibus and node-unicode-tr51 (and possibly others I have not found yet) 
> packages have 
> FTBFS with unicode-data 13.0.0-1.
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953775
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953793
>
> They are because the upstream UCD.zip doesn't ship emoji-sequences.txt, 
> emoji-test.txt 
> and emoji-zwj-sequences.txt files anymore since version 13.
>
> Possible solutions would be shipping additional emoji files in unicode-data, 
> or creating a new source package for unicode emoji files like Fedora does 
> (https://src.fedoraproject.org/rpms/unicode-emoji)
>
> Any opinions?
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> -- no debconf information

-- 
Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, 
phone: 087-6847928
Green Party Councillor, Galway County Council 

Bug#954080: tbsync: broken by new thunderbird, please prepare new version for stable-updates

[Martin]

Source: tbsync
Version: 1.7-1
Severity: important

Hi Mechthilde,

it looks like the current tbsync in buster is not directly
usable anymore, after thunderbird has been upgraded from 60.x to
68.x. I assume, that just using a newer version in stable might
work, but I didn't try yet.

First, I just downgraded thunderbird, lightning, and enigmail
to their original buster versions:

thunderbird 60.9.0-1~deb10u1
lightning 60.9.0-1~deb10u1
enigmail 2.0.12+ds1-1~deb10u1

This works and might be a good workaround for most users.

Second, I did an adhoc, local backport of tbsync. This works
with the latest thunderbird in buster, as expected.

Cheers & stay healthy!

Bug#952607: transition: php (soft transition)

[Emilio Pozuelo Monfort]

Hi Ondřej,

On 11/03/2020 09:57, Emilio Pozuelo Monfort wrote:
> Ack, keep us updated on the progress here and let us know if you need 
> anything.
> I have added a ben tracker now, but it will take a bit to show up on the 
> webserver.

Should I binNMU the remaining bad packages in the tracker? Or do those need
source updates?

Cheers,
Emilio

Bug#954076: RFS: libxtrxdsp/0.0.1+git20190830.eec2864-1 [ITP] -- Library of DSP functions, developed for XTRX SDR: development

[Sepi Gair]

Package: sponsorship-requests
Severity: wishlist

Dear mentors, Hamradio Maintainers,

I am looking for a sponsor for my package "libxtrxdsp"

 * Package name: libxtrxdsp
   Version : 0.0.1+git20190830.eec2864-1
   Upstream Author : Sergey Kostanbaev 
 * URL : https://github.com/xtrx-sdr/libxtrxdsp
 * License : LGPL-2.1+
 * Vcs : 
https://salsa.debian.org/debian-hamradio-team/libxtrxdsp
   Section : libs

It builds those binary packages:

  libxtrxdsp-dev - Library of DSP functions, developed for XTRX SDR:
development
  libxtrxdsp0 - Library of DSP functions, developed for XTRX SDR

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libx/libxtrxdsp/libxtrxdsp_0.0.1+git20190830.eec2864-1.dsc

Changes since the last upload:

   * Initial release (Closes: #945154)

Regards,

--
  Sepi Gair

Bug#937431: [Discussion Needed] Upstream version for pyode?

[Andreas Tille]

On Mon, Mar 16, 2020 at 04:37:06PM +0530, Nilesh Patra wrote:
> Hi,
> pyode is a package of Neuro-debian team, with a RC bug filed; since we are
> in the process of taking in a few packages(mostly with RC bugs) from
> neuro-debian into debian med+science, I wanted a clarification on this
> package.
> The package seems to be dead upstream with latest version being '1.2'; and
> as pointed out by Sandro on its RC bug[1], it has a fork available here[2].
> However, the new fork doesn't seem to have any release yet. I have opened
> the issue[3] for the same, but not really sure about the time it would take
> for an agreement.
> 
> So I had this question - what should be the new release version for pyode
> in this case?

I moved pyode to

https://salsa.debian.org/med-team/pyode

If there is a promising fork that would solve our porting problem use
git mode in d/watch (example for instance in libsmithwaterman)
 
> Also, another option can be to file RM request on the package; it has only
> one reverse(build) dependency, pyepl(whch has a RC  bug against it, as
> well):
> 
> [~]$ reverse-depends python-pyode
> Reverse-Depends
> ===
> * python-pyepl
> 
> Packages without architectures listed are reverse-dependencies in: amd64,
> arm64, armel, armhf, i386, mipsel, ppc64el, s390x
> [~]$ reverse-depends -b python-pyode
> Reverse-Build-Depends
> =
> * pyepl
> 
> And pyepl has no reverse-dependencies.
> So we can probably file RM requests for both: pyode and pyepl?
> 
> I would like knowing what should be the best thing to do here.

I moved pyepl to

   https://salsa.debian.org/med-team/pyepl/

Please do with these whatever you consider sensible to do.  Having long
standing RC bugs in packages of Neurodebian packages does not
necessarily mean that the issues are really hard to fix.  Its just a
lack of manpower which we try to fix now.  Currently (next 24-48 hours)
please do not count on me for this kind of work.  Please decide yourself
whether upgrading solves Python3 issues.  I'm also doing nothing else
than this.

Thank you for your contribution

   Andreas.

> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937495#18
> [2]: https://github.com/filipeabperes/Py3ODE
> [3]: https://github.com/filipeabperes/Py3ODE/issues/6
> 
> Thanks and regards,
> Nilesh

-- 
http://fam-tille.de

Bug#952607: transition: php (soft transition)

[Sebastiaan Couwenberg]

On 3/16/20 12:33 PM, Emilio Pozuelo Monfort wrote:
> Hi Ondřej,
> 
> On 11/03/2020 09:57, Emilio Pozuelo Monfort wrote:
>> Ack, keep us updated on the progress here and let us know if you need 
>> anything.
>> I have added a ben tracker now, but it will take a bit to show up on the 
>> webserver.
> 
> Should I binNMU the remaining bad packages in the tracker? Or do those need
> source updates?

php-geos can be binNMUed.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#932692: Sid installation problems in packer

[Emmanuel Kasper]

Hi Andrew
That you for your interest in Debian and Vagrant Boxes.
I read you mail it details, and it seems that you have rather a problem
with the debian installer, rather than with the existing Debian boxes.

If you want to have a debian sid system in Vagrant, you should use one
of the testing boxes available here:
https://app.vagrantup.com/debian/boxes/testing64
https://app.vagrantup.com/debian/boxes/contrib-testing64
and update the system to debian sid with apt.

AFAIK sid is a quick moving target and is never guaranteed to have a
working installer.

Emmanuel

Bug#954081: debian-live-10.3.0-amd64-gnome.iso fails to load desktop on Acer A515-43-R19L laptop

[Mike Haag]

Package: debian-live
Severity: important

I first updated the BIOS using the supplied Windows 10, then replaced the
supplied 128GB SSD with a new 500GB SSD.

Verified the iso file with SHA512, and tried running as both DVD and USB thumb
drive:

Grub starts as expected.

1. Attempted to start the live desktop environment from the first Grub menu
item, "Debian GNU/Linux Live (kernel 4.19.0-8-amd64)".
2. Multiple status messages are displayed. Then, a Debian splash screen is
briefly displayed, followed immediately by a blank screen with a blinking
cursor, and the system freezes.
3. Ctrl-Alt-Del will reboot the laptop into the Grub menu.

The graphical installer (third Grub menu item) runs, and appears to complete
successfully. But, the installed system exhibits the same problem: Multiple
startup messages, and the system freezes before the desktop environment starts,
just displaying a blank screen and blinking cursor.

For what it's worth, I also tried several other Debian-based and RPM
distributions. Could only get a working system with the RPMs:

1. Debian: The following produce the same results as above.

 debian-live-10.3.0-amd64-gnome+nonfree.iso
 debian-live-testing-amd64-gnome.iso
 debian-10.3.0-amd64-netinst.iso

2. Ubuntu 19.10 and LinuxMint 19.3: The live distributions work as
   expected. Installed systems begin to boot but then both fail with
   unspecified watchdog soft lock errors before their respective desktop
   environments start.

3. Fedora 31: Live runs as expected. Installed system boots and runs as
expected.

4. OpenSUSE Leap 15.1: Live runs as expected. Installed system boots and runs
as expected.

The only recommendation I could find using the Acer user forum and other
internet searches, was to try editing the Grub menu line to "nomodeset", but
that doesn't work. There was also some theorizing that the kernel needed to be
updated to 5.0, but openSUSE 15.1 is kernel 4.12, and that is working.

Looking for advice and suggestions: I do not know how to proceed with further
trouble-shooting.

Thanks, Mike



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

Kernel: Linux 4.19.0-8-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

Bug#954073: buster-pu: package postfix/3.4.9-0+10debu1

[Emilio Pozuelo Monfort]

Hi Scott,

On 16/03/2020 12:00, Scott Kitterman wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> This is the next in the normal series of postfix bugfix updates.  This
> update has a single fix for a long standing milter processing error.  It
> should be low risk and is in Testing already.
> 
> Bugfix (introduced: Postfix 2.3): panic with Postfix
> multi-Milter configuration during MAIL FROM. Milter client
> state was not properly reset after one of the Milters failed.
> Reported by WeiYu Wu.
> 
> As usual, I have this version running on several machines of my own with
> no issues noted.  Debdiff attached.  Please approve so I can upload.

Subject seems wrong, this is 3.4.10.

Also your version is 3.4.10-0deb10u1, but it should rather be 3.4.10-0+deb10u1
(i.e. an extra plus sign).

With those changes I'd ack the upload, but let's wait for an SRM to confirm.

Cheers,
Emilio

Bug#954073: buster-pu: package postfix/3.4.9-0+10debu1

[Scott Kitterman]

On Monday, March 16, 2020 7:25:09 AM EDT Emilio Pozuelo Monfort wrote:
> Hi Scott,
> 
> On 16/03/2020 12:00, Scott Kitterman wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: buster
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > This is the next in the normal series of postfix bugfix updates.  This
> > update has a single fix for a long standing milter processing error.  It
> > should be low risk and is in Testing already.
> > 
> > Bugfix (introduced: Postfix 2.3): panic with Postfix
> > multi-Milter configuration during MAIL FROM. Milter client
> > state was not properly reset after one of the Milters failed.
> > Reported by WeiYu Wu.
> > 
> > As usual, I have this version running on several machines of my own with
> > no issues noted.  Debdiff attached.  Please approve so I can upload.
> 
> Subject seems wrong, this is 3.4.10.
> 
> Also your version is 3.4.10-0deb10u1, but it should rather be
> 3.4.10-0+deb10u1 (i.e. an extra plus sign).
> 
> With those changes I'd ack the upload, but let's wait for an SRM to confirm.

Thanks.  Fixed the revision.  The reportbug template pulls up the current 
version of the package, which I always thought was odd.

Scott K

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

Bug#923908: new upstream version available (9.2)

[Sebastien Delafond]

On 15/03 22:45, Nicholas D Steeves wrote:
> While triaging bugs I just noticed this one is marked fixed but is
> still open.  Was it left open as a reminder to backport bullseye's
> org-mode?

I believe that was the rationale at the time.

> Does arch:all elpa-org-mode need a formal bpo, or will adding testing
> or sid apt source in combination with pinning work well enough?

Package pinning should work fine, but if enough users request a proper
stable backport I guess it could also be maintained.

Cheers,

-- 
Seb

Bug#954078: vulkan-loader: consider using multiple .orig tarball to simplify packaging

[Simon McVittie]

Source: vulkan-loader
Version: 1.2.131.2-1
Severity: wishlist

I notice that vulkan-loader contains a vendored copy of vulkan-headers,
in order to keep the library and headers in sync, with the "upstream"
tarball actually being composed by repacking the combination of
vulkan-loader and vulkan-headers.

Since it's a 3.0 (quilt) package already, and the vendored vulkan-headers
is in the top-level directory, this seems like a perfect fit for multiple
.orig tarballs:

- download 
https://github.com/KhronosGroup/Vulkan-Loader/archive/sdk-1.2.131.2.tar.gz
  and rename it to vulkan-loader_1.2.131.2.orig.tar.gz
- download 
https://github.com/KhronosGroup/Vulkan-Headers/archive/sdk-1.2.131.1.tar.gz
  and rename it to vulkan-loader_1.2.131.2.orig-vulkan-headers.tar.gz
  (note the version number mismatch - sorry, I think this is unavoidable
  with current tools, if your upstream doesn't always keep the version
  numbers in sync)
- put both in ../ or wherever else you keep your upstream tarballs, or
  commit them to pristine-tar with gbp import-orig if you use that
- import them both into your upstream-unstable git branch, perhaps with
  gbp import-orig --upstream-vcs-tag=... --component=vulkan-headers
  to keep it as a descendant of the upstream git history

This would avoid needing to repack the upstream tarball, which seems likely
to be problematic if more than one developer imports it independently.

The yquake2 source package in contrib is an example of this technique.
I use DEP-14 branch names rather than the xorg-team's conventions, but
I think the difference is mostly just labelling? In particular,
"component=ctf" in debian/gbp.conf and debian/watch (in your case it
would be "component=vulkan-headers") activates the support for multiple
.orig tarballs in gbp and uscan.

I'm involved in the maintenance of a derivative (the Steam Runtime) that
has an interest in having the latest Vulkan library, and it's looking like
I might need to package the latest release (a development version "v...",
rather than the stable "sdk-..." versions that you package). Would you
be interested in receiving a merge request with that version, targeting
experimental?

Thanks,
smcv

Bug#932815: snapd: "snap remove" broken with AppArmor 2.13.2+

[Jamie Strandboge]

On Mon, 02 Mar 2020, Алексей Шилин wrote:

> On Tue, 23 Jul 2019 14:09:52 -0500 Jamie Strandboge <
> ja...@canonical.com> wrote:
> > The 'core' snap is one such runtime that is on all systems with snaps
> > installed and the 'core' snap contains 'snapd'.
> >
> > [...]
> >
> > Since snapd is not installed by default, apt-getting it and then
> > installing a snap will pull in the latest core snap so in practice no
> > new snaps users of Buster should be affected.
> 
> This doesn't seem to always be the case:

Since I wrote this, it has been confirmed that under certain
circumstances reexec will not work correctly. What is happening is that
snapd on the system is 2.37.4-1+b1, and that version knows how to
re-exec into the core snap. acestreamplayer uses 'base: core18' and
while snapd will pull down core18, it will not re-exec into it. If you
'snap install core', you can workaround this issue (as you mentioned).

snapd needs an update so that it can pull down what it needs to reexec
(newer releases know about the 'snapd' snap and will pull that down
instead). I discussed this just now with the snapd team and they plan to
update snapd to have a newer version.

-- 
Jamie Strandboge | http://www.canonical.com

Bug#954079: magic-wormhole: Fails to send with a type error

[Guillem Jover]

Package: magic-wormhole
Version: 0.11.2-1
Severity: serious

Hi!

This package does not work anymore in unstable. I guess due to the new
python-3.8 transition? Had to use a buster schroot to be able to send
some stuff today. :)

  ,---
  $ wormhole send somedir/
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/wormhole/cli/cli.py", line 255, in 

  return react(_dispatch_command, (cfg, lambda: f(cfg)))
File "/usr/lib/python3/dist-packages/wormhole/cli/cmd_send.py", line 36, in 
send
  return Sender(args, reactor).go()
File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1613, 
in unwindGenerator
  return _cancellableInlineCallbacks(gen)
File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1529, 
in _cancellableInlineCallbacks
  _inlineCallbacks(None, g, status)
  ---  ---
File "/usr/lib/python3/dist-packages/wormhole/cli/cli.py", line 122, in 
_dispatch_command
  yield maybeDeferred(command)
File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1418, 
in _inlineCallbacks
  result = g.send(result)
File "/usr/lib/python3/dist-packages/wormhole/cli/cmd_send.py", line 64, in 
go
  w = create(
File "/usr/lib/python3/dist-packages/wormhole/wormhole.py", line 271, in 
create
  b = Boss(w, side, relay_url, appid, wormhole_versions, client_version,
File "", line 21, in __init__
  self.__attrs_post_init__()
File "/usr/lib/python3/dist-packages/wormhole/_boss.py", line 49, in 
__attrs_post_init__
  self._build_workers()
File "/usr/lib/python3/dist-packages/wormhole/_boss.py", line 59, in 
_build_workers
  self._RC = RendezvousConnector(self._url, self._appid, self._side,
File "", 
line 18, in __init__
  self.__attrs_post_init__()
File "/usr/lib/python3/dist-packages/wormhole/_rendezvous.py", line 88, in 
__attrs_post_init__
  d = self._connector.whenConnected(failAfterFailures=faf)
File "/usr/lib/python3/dist-packages/twisted/application/internet.py", line 
1121, in whenConnected
  return self._machine.whenConnected(failAfterFailures)
File "/usr/lib/python3/dist-packages/automat/_methodical.py", line 126, in 
__get__
  def doInput(*args, **kwargs):
File "/usr/lib/python3/dist-packages/automat/_introspection.py", line 39, 
in decorator
  return copyfunction(decorated,
File "/usr/lib/python3/dist-packages/automat/_introspection.py", line 31, 
in copyfunction
  return function(copycode(template.__code__, codechanges), *values)
File "/usr/lib/python3/dist-packages/automat/_introspection.py", line 19, 
in copycode
  return code(*values)
  builtins.TypeError: an integer is required (got type bytes)
  ERROR: an integer is required (got type bytes)
  `---

Thanks,
Guillem

Bug#954082: ITP: python3-fluent-logger -- A structured logger for Fluentd (Python)

[Michal Arbet]

Package: wnpp
Severity: wishlist
Owner: Michal Arbet 

* Package name: python3-fluent-logger
  Version : 0.96.0
  Upstream Author : FURUHASHI Sadayuki
* URL : https://github.com/fluent/fluent-logger-python.git
* License : Apache-2.0
  Programming Lang: Python
  Description : A structured logger for Fluentd (Python)

Many web/mobile applications generate huge amount of event logs (c,f.
login, logout, purchase, follow, etc). To analyze these event logs could be
really valuable for improving the service. However, the challenge is
collecting these logs easily and reliably.
Fluentd solves that problem by having: easy installation, small footprint,
plugins, reliable buffering, log forwarding, etc.
fluent-logger-python is a Python library, to record the events from Python
application.

Bug#952607: transition: php (soft transition)

[Emilio Pozuelo Monfort]

On 16/03/2020 13:37, Ondřej Surý wrote:
> Hi Emilio,
> 
> It certainly won’t hurt, at least I can check what FTBFS and either fix it or 
> fill
> a bug.
> 
> I am bit confused about php-raphf and php-propro though - I guess a manual
> check will be needed.

There was a bug in the ben file, I have fixed it and there are no "partial"
packages anymore.

I have binNMU the remaining bad packages. Let's see how that goes.

Cheers,
Emilio

Bug#954080: tbsync: broken by new thunderbird, please prepare new version for stable-updates

[Martin]

Btw. if you are currently busy, I'ld be glad to help out.

Bug#953534: SyntaxWarning: "is" with a literal. Did you mean "=="? after having upgraded python to 3.8.2-1

[Freeman, Stuart]

This appears to be fixed upstream in version 0.9.5 of jmespath, see:  
https://github.com/jmespath/jmespath.py/commit/56263b84cdb0feb7c8d54e426ec472f4dd0de44f

Bug#954069: please move to hourly cron jobs and and set maxsize

[Michael Biebl]

Control: tags -1 + moreinfo

Am 16.03.20 um 10:43 schrieb Harald Dunkel:
> Package: rsyslog
> Version: 8.1901.0-1
> Severity: wishlist
> 
> Using syslog it is easy to write a few GBytes/hour logfiles, e.g. via
> #954065, so I would suggest to run the logrotate for rsyslog hourly

logrotate is run daily, so I don't see how I can make the logs rotated
hourly.
Also, maxsize doesn't really help either in case of a rogue application
as you can easily fill a /var/log partition within one day (or even one
hour) before logrotate is actually run.

logrotate would have to constantly monitor the log file sizes, which it
doesn't do.

In summary, what you propose will not actually help against something
like #954065

Michael



signature.asc
Description: OpenPGP digital signature

Bug#954086: vulkan-loader: consider adding a superficial autopkgtest for the library

[Simon McVittie]

Source: vulkan-loader
Version: 1.2.131.2-1
Severity: wishlist
Tags: patch

Compiling and linking what is essentially "hello, world" against a library
is not a thorough test, but can detect surprisingly many library packaging
mistakes, so I've started writing a superficial test like this for every
library I backport or otherwise work on.

Patch available here:
https://salsa.debian.org/xorg-team/vulkan/vulkan-loader/-/merge_requests/2

smcv

Bug#954087: vulkan-loader: consider adding a .symbols file

[Simon McVittie]

Source: vulkan-loader
Version: 1.2.131.2-1
Severity: wishlist
Tags: patch

Adding a symbols file for dpkg-gensymbols helps to detect many forms of
ABI break. libvulkan seems to have a simple C ABI with explicit control
over what's exported, so it's a good candidate for adding this.

Patch:
https://salsa.debian.org/xorg-team/vulkan/vulkan-loader/-/merge_requests/3

smcv

Bug#954090: override: tasksel:admin/optional

[Raphaël Hertzog]

Package: ftp.debian.org
Severity: normal
User: de...@kali.org
Usertags: origin-kali

tasksel 3.57 changed its priority to optional and d-i is now installing it
when it needs it so it doesn't matter that it's no longer installed after
a debootstrap.

Please update the override accordingly.

Thank you.

Bug#907020: fixed in vnstat 1.18-2.1

[Christian Göttsche]

Control: severity -1 normal

Allow bug to archive.
The autpkgtest run failed because of a autpkgtest misconfiguration and
not caused by a defect in the actual package.

Uploading 1.18-2.1 to stable now, just for a non-user visible change
does not seem right.

Bug#954085: libpandoc-wrapper-perl: Please verify server identity via SSL

[Felix Lechner]

Package: libpandoc-wrapper-perl
Severity: important

Dear maintainer,

Your package uses the Perl module HTTP::Tiny to access the secure URL

https://api.github.com/repos/jgm/pandoc/releases/tags/$version

but it does not set the verify_SSL attribute to a true value.

By default, the module HTTP::Tiny does not validate the identity of
server certificates. The documentation states that "Server identity
verification is controversial and potentially tricky..." [1]

As late as 2015, upstream has been doubling up: "we're not going to be
responsible for the user's trust model" [2]

I believe, on the other hand, that the encryption of a transmission
has no value when talking to the wrong person. You can easily see the
useless and dangerous default by running the script at the end of this
message.

Will you please turn on the verify_SSL attribute in HTTP::Tiny?

Kind regards
Felix Lechner

[1] https://metacpan.org/pod/HTTP::Tiny#SSL-SUPPORT
[2] https://github.com/chansen/p5-http-tiny/issues/68

* * *

#!/usr/bin/perl

use HTTP::Tiny;

my $response = HTTP::Tiny->new->get('https://self-signed.badssl.com/');
 die "Failed!\n"
unless $response->{success};

print "$response->{status} $response->{reason}\n";

while (my ($k, $v) = each %{$response->{headers}}) {
for (ref $v eq 'ARRAY' ? @$v : $v) {
print "$k: $_\n";
}
}

print $response->{content}
if length $response->{content};

Bug#954088: Please enable GVT-g support

[Lee Garrett]

Package: linux-image-amd64
Version: 5.4.19-1
Severity: wishlist

Hi Ben,

please consider enabling the following settings in the Debian kernel:

(mediated devices, needed to enable the lower settings)
CONFIG_VFIO_MDEV=m
CONFIG_VFIO_MDEV_DEVICE=m

(enable kvm/xen support for gvt)
CONFIG_DRM_I915_GVT=y
CONFIG_DRM_I915_GVT_KVMGT=m
CONFIG_DRM_I915_GVT_XENGT=m


This will allow people to create a virtual GPU with mdevctl to pass through to
VMs, allowing them to use hw acceleration in guests.

Thank you for your work!

Lee


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

Kernel: Linux 5.5.9+ (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_USER, 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 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.4.0-4-amd64  5.4.19-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#954030: pulseaudio: Pulseaudio does not start in xrdp session. Error in startup script.

[Felipe Sateler]

Control: tags -1 moreinfo

On Sun, Mar 15, 2020 at 9:15 PM Bob Hauck  wrote:

> Package: pulseaudio
> Version: 13.0-5
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> I run KDE in a virtual machine using XRDP. For sound support I installed
> pulseaudio-module-xrdp from github:
>
> https://github.com/neutrinolabs/pulseaudio-module-xrdp
>
> But pulseaudio does not start. There is an error in .xsession-errors
> regarding"illegal number" on line 27 of /usr/bin/start-pulseaudio-x11.
>

That should not prevent pulseaudio from starting


> The script attempts to parse $DESKTOP_SESSION.desktop, but the CWD is
> not correct. The fix is to add the correct path to the desktop session
> files.
>

Does that fix the pulseaudio startup? I wouldn't expect it to.


-- 

Saludos,
Felipe Sateler

Bug#952597: Two gdcm bugs fixed in Git

[Laurent Bigonville]

On Wed, 11 Mar 2020 00:25:25 + peter green  wrote:
> > ...
> > The following packages have unmet dependencies:
> > python3-vtk7 : Depends: python3 (< 3.8) but 3.8.2-1 is to be installed
> > Unable to resolve dependencies! Giving up...
> > ...
> This was a result of the python 3.8 transition, vtk7 has now been 
rebuilt on most architectures (mips is still building) and so it is now 
possible to satisfy the build-dependencies of gdcm.

>
> I just did a test build, but unfortunately it failed.

There is a new (3.0.5) upstream release, maybe that will help?


> > cd /gdcm/obj-x86_64-linux-gnu/Utilities/VTK && /usr/bin/cmake -E 
make_directory /gdcm/obj-x86_64-linux-gnu/Utilities/VTK 
/gdcm/obj-x86_64-linux-gnu/Utilities/VTK/CMakeFiles/vtkgdcmsharpglue.dir 
&& /usr/bin/cmake -E env SWIG_LIB=/usr/share/swig4.0 /usr/bin/swig4.0 
-csharp -namespace vtkgdcm -dllimport vtkgdcmsharpglue -outdir 
/gdcm/obj-x86_64-linux-gnu/Utilities/VTK -c++ -I/usr/include 
-I/usr/include/vtk-7.1 -I/usr/include/freetype2 
-I/usr/include/x86_64-linux-gnu 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
-I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/include/python3.8 
-I/usr/include/hdf5/openmpi -I/usr/include/jsoncpp 
-I/usr/include/libxml2 -I/usr/include/tcl 
-I/gdcm/obj-x86_64-linux-gnu/Source/Common -I/gdcm/Source/Common 
-I/gdcm/Source/DataStructureAndEncodingDefinition 
-I/gdcm/Source/MediaStorageAndFileFormat -I/gdcm/Source/DataDictionary 
-I/gdcm/Utilities/VTK -o 
/gdcm/obj-x86_64-linux-gnu/Utilities/VTK/CMakeFiles/vtkgdcmsharpglue.dir/vtkgdcmCSHARP_wrap.cxx 


> > /gdcm/Utilities/VTK/vtkgdcm.i
> > /usr/include/vtk-7.1/vtkStringArray.h:36: Warning 402: Base class 
'vtkAbstractArray' is incomplete.
> > /usr/include/vtk-7.1/vtkAlgorithm.h:38: Warning 402: Only forward 
declaration 'vtkAbstractArray' was found.
> > /gdcm/Utilities/VTK/vtkgdcm.i:354: Error: A deprecated 
csdestruct_derived typemap was found for vtkGDCMTesting, please remove 
it and replace all csdestruct, csdestruct_derived and csfinalize 
typemaps by the csdispose, csdispose_derived, csdisposing and 
csdisposing_derived typemaps.
> > /gdcm/Utilities/VTK/vtkgdcm.i:365: Error: A deprecated 
csdestruct_derived typemap was found for vtkGDCMImageReader, please 
remove it and replace all csdestruct, csdestruct_derived and csfinalize 
typemaps by the csdispose, csdispose_derived, csdisposing and 
csdisposing_derived typemaps.
> > /gdcm/Utilities/VTK/vtkgdcm.i:376: Error: A deprecated 
csdestruct_derived typemap was found for vtkGDCMImageWriter, please 
remove it and replace all csdestruct, csdestruct_derived and csfinalize 
typemaps by the csdispose, csdispose_derived, csdisposing and 
csdisposing_derived typemaps.

> > ninja: build stopped: subcommand failed.
> > dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 
ninja -j1 -v returned exit code 1

> > make[1]: *** [debian/rules:110: override_dh_auto_build-arch] Error 25
> > make[1]: Leaving directory '/gdcm'
> > make: *** [debian/rules:54: build] Error 2
>
>

Bug#954021: Please detect use of staff group (and 2775 permissions) in maintainer scripts without checking staff-group-for-usr-local

[Felix Lechner]

Hi Josh,

On Sun, Mar 15, 2020 at 1:18 PM Josh Triplett  wrote:
>
> Many packages still
> unconditionally chown directories to root:staff, or chmod directories to
> 2755.

What is the issue with setting the group id, please? Isn't it a common
paradigm for daemons?

Kind regards
Felix Lechner

Bug#954084: libnanomsg-raw-perl: Please verify server identity via SSL

[Felix Lechner]

Package: libnanomsg-raw-perl
Severity: important

Dear maintainer,

Your package uses the Perl module HTTP::Tiny to access an insecure URL
(http://cpanidx.org/cpanidx/json/mod/$pkg). Your package could use the
secure version.

Please remember to set HTTP::Tiny's verify_SSL attribute to a true
value. By default, that module does not validate the identity of
server certificates. The documentation states that "Server identity
verification is controversial and potentially tricky..." [1]

Will you please use the secure URL for https://cpanidx.org and turn on
the verify_SSL attribute in HTTP::Tiny?

Kind regards
Felix Lechner

[1] https://metacpan.org/pod/HTTP::Tiny#SSL-SUPPORT

Bug#886580: meshlab crashes on empty .stl

[Ryan Pavlik]

Control: tags -1 + fixed-upstream pending

Looks like this is fixed upstream in the newest release, which I have
sitting on Mentors ready for review and upload:
https://mentors.debian.net/package/meshlab


On Sun, 7 Jan 2018 19:52:55 + Ian Jackson
 wrote:
> Package: meshlab
> Version: 1.3.2+dfsg1-3
> Severity: minor
> 
> This silly file causes it to crash.  It ought to print an error
> message, but not actually crash.
> 
> (FAOD the fact that the file is empty is almost certainly not admesh's
> fault - it'll be my fault.)
> 
> zealot:play> cat t.stl 
> solid  Processed by ADMesh version 0.98.2
> endsolid  Processed by ADMesh version 0.98.2
> zealot:play> meshlab t.stl 
> Current Plugins Dir is: /usr/lib/meshlab/plugins 
> Reading Param with name MeshLab::Appearance::backgroundBotColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::backgroundTopColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::baseLightAmbientColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::baseLightDiffuseColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::baseLightSpecularColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::fancyBLightDiffuseColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::fancyFLightDiffuseColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::logAreaColor : RichColor
> Reading Param with name MeshLab::Appearance::pointDistanceAttenuation : 
> RichBool
> Reading Param with name MeshLab::Appearance::pointSize : RichFloat
> Reading Param with name MeshLab::Appearance::pointSmooth : RichBool
> Reading Param with name MeshLab::Appearance::textureMagFilter : RichEnum
> Reading Param with name MeshLab::Appearance::textureMinFilter : RichEnum
> Reading Param with name MeshLab::Decoration::AreaHistParam : RichBool
> Reading Param with name MeshLab::Decoration::BoxRatio : RichFloat
> Reading Param with name MeshLab::Decoration::CameraFixedScaleParam : 
> RichFloat
> Reading Param with name MeshLab::Decoration::CameraInfoType : RichEnum
> Reading Param with name MeshLab::Decoration::CameraRenderScaleType : 
> RichEnum
> Reading Param with name MeshLab::Decoration::CameraShowCameraDetails : 
> RichBool
> Reading Param with name MeshLab::Decoration::CameraShowFrustum : RichBool
> Reading Param with name MeshLab::Decoration::CubeMapPath : RichString
> Reading Param with name MeshLab::Decoration::FixedHistMaxParam : RichFloat
> Reading Param with name MeshLab::Decoration::FixedHistMinParam : RichFloat
> Reading Param with name MeshLab::Decoration::FixedHistWidthParam : 
> RichFloat
> Reading Param with name MeshLab::Decoration::GridBack : RichBool
> Reading Param with name MeshLab::Decoration::GridColorBack : RichColor
> Reading Param with name MeshLab::Decoration::GridColorFront : RichColor
> Reading Param with name MeshLab::Decoration::GridMajor : RichFloat
> Reading Param with name MeshLab::Decoration::GridMinor : RichFloat
> Reading Param with name MeshLab::Decoration::GridSnap : RichBool
> Reading Param with name MeshLab::Decoration::HistBinNumParam : RichInt
> Reading Param with name MeshLab::Decoration::NormalLength : RichFloat
> Reading Param with name MeshLab::Decoration::ProjRasterAlpha : 
> RichDynamicFloat
> Reading Param with name MeshLab::Decoration::ProjRasterLighting : RichBool
> Reading Param with name MeshLab::Decoration::ProjRasterOnAllMeshes : 
> RichBool
> Reading Param with name MeshLab::Decoration::ProjRasterUseVBO : RichBool
> Reading Param with name MeshLab::Decoration::SSAORadius : RichFloat
> Reading Param with name MeshLab::Decoration::ShadowIntensityVal : 
> RichDynamicFloat
> Reading Param with name MeshLab::Decoration::ShadowMethod : RichEnum
> Reading Param with name MeshLab::Decoration::ShowBorderFlag : RichBool
> Reading Param with name MeshLab::Decoration::ShowMeshCameras : RichBool
> Reading Param with name MeshLab::Decoration::ShowNonRegular : RichBool
> Reading Param with name MeshLab::Decoration::ShowRasterCameras : RichBool
> Reading Param with name MeshLab::Decoration::ShowSeparatrix : RichBool
> Reading Param with name MeshLab::Decoration::ShowShadow : RichBool

Bug#954091: mypaint: Please honour "nocheck" in DEB_BUILD_OPTIONS

[John Paul Adrian Glaubitz]

Source: mypaint
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

mypaint overrides the dh_auto_test target in debian/rules without checking
for "nocheck" being set in DEB_BUILD_OPTIONS. This results in the testsuite
being run even though "nocheck" is passed in DEB_BUILD_OPTIONS.

Being able to disable the testsuite is necessary when building packages in
emulated environments where the testsuite might not pass due to emulation
issues or for cross-builds where the testsuite cannot be run due to the
build and target architectures being different.

In order to fix this, the code inside the override_dh_auto_test target should
be guarded with an if conditional which tests for "nocheck" being present
in DEB_BUILD_OPTIONS:

ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
endif

See also #908373 [1] for reference.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908373

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#954092: meshlab: none

[Ryan Pavlik]

Package: src:meshlab
Version: 2020.02+git200217-1
Severity: serious
Justification: Policy 2.3
Tags: pending
Owner: ryan.pav...@gmail.com

Dear Maintainer,

The recently uploaded 2020.02+git200217-1 package has some DFSG
violations - some of which are file-exclusions that got lost in the new
package, while others are newly found. The "newly found" one I'll
consider key for this bug is use of GPL-incompatible source (ISC license
with a "do not sell it" clause added) in a GPL package: three files in
the "filter_screened_poisson" plugin.

I have forwarded this particular issue upstream since it affects their
binaries as well (they might be essentially not redistributable):
 Subsequently I
fixed that by removing the files in question and applying modifications
based on another, compatible source (the issue is in a vendored
project's vendored project, neither of which are packaged in Debian or
intended for anything other than standalone usage or source integration
by upstreams.) This patch was applied upstream.

I have inspected the source and restored the list of "Files-Excluded" in
debian/copyright (including all the previously-listed files that their
exclusion is still applicable, and adding additional new files that
should be excluded for DFSG or source-missing reasons), and added a
script that can generate the dfsg-cleaned repacked upstream tarball.
(They're using Git with a submodule).

My repacked version, which removes problematic files and patches a
number of issues (including a version of the patch applied upstream to
fix the filter_screened_poisson filter) is ready for review and uploaded
to https://mentors.debian.net/package/meshlab . The source is up at
https://salsa.debian.org/rpavlik-guest/meshlab - I have not pushed it to
the science team repo out of courtesy since it hasn't been reviewed yet.
However, I think it's ready to go.  (The system information below
reflects my installation of my own package on Buster, but I have set the
version entry in the header correctly.)

Ryan

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500,
'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages meshlab depends on:
ii  lib3ds-1-3  1.3.0-9+b1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libglew2.1  2.1.0-4
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libglx0 1.1.0-1
ii  libgmp102:6.1.2+dfsg-4
ii  libgomp18.3.0-6
ii  libmuparser2v5  2.2.6.1+dfsg-1
ii  libopenctm1 1.0.3+dfsg1-2+b1
ii  libopengl0  1.1.0-1
ii  libqhull7   2015.2-4
ii  libqt5core5a5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5  5.11.3+dfsg1-1+deb10u3
ii  libqt5network5  5.11.3+dfsg1-1+deb10u3
ii  libqt5opengl5   5.11.3+dfsg1-1+deb10u3
ii  libqt5script5   5.11.3+dfsg-3
ii  libqt5widgets5  5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5  5.11.3+dfsg1-1+deb10u3
ii  libqt5xmlpatterns5  5.11.3-2
ii  libstdc++6  8.3.0-6

Versions of packages meshlab recommends:
pn  chemical-mime-data  

meshlab suggests no packages.

-- no debconf information

Bug#954093: desktop-base: Integration with KDE plasma on debian testing no longer works

[daniel]

Package: desktop-base
Version: 10.0.3
Severity: important

When KDE plasma desktop is installed on Debian testing (currently 
plasma 5.17.5)
the wallpaper you get is not the one set by desktop-base but KDE's 
default. So,

it seems like the integration provided by the script
/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/desktop-base.js
is not properly working and would need an update for the newer 
plasma-desktop

versions.

$ cat 
/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/desktop-base.js

...
// This script is provided by desktop-base
// It is run by Plasma 5 on upgrade.
// Plasma checks that the script is only run once for each version.
d = desktops()

for (i in d) {
   // Only set up the wallpaper if the plugin is the default.
   // Otherwise it means the user chose another plugin and we don’t 
want to override that.

   if (d[i].wallpaperPlugin == 'org.kde.image') {
   d[i].currentConfigGroup = Array('Wallpaper', 'org.kde.image', 
'General')

   if (!d[i].readConfig('Image')) {
   // Only set up the wallpaper if the wallpaper image is 
empty (=default).
   // Otherwise it means the user selected a picture and we 
don’t want to override that.

   d[i].writeConfig('Image', 'DebianTheme');
   }
   }
}

Apparently the condition inside `if (!d[i].readConfig('Image')) {` is 
always false.

Removing that if solves the issue.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

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

Versions of packages desktop-base depends on:
ii  fonts-quicksand  0.2016-2
ii  librsvg2-common  2.46.4-1

Versions of packages desktop-base recommends:
ii  plymouth-label  0.9.4-2

Versions of packages desktop-base suggests:
ii  kde-standard  5:104

-- no debconf information

--
Daniel Ruiz de Alegría
drasite.com

Bug#954094: /bin/systemd: Running startx in X session switches to VC, input duplicated to X, login at getty exfiltrates creds

[Justus Winter]

Package: systemd
Version: 241-7~deb10u3
Severity: critical
File: /bin/systemd
Tags: security
Justification: root security hole

Dear Maintainer,

I was trying to spawn an Xephyr server using startx, but messed up the
arguments (I can reproduce it by simply running 'startx').  My X
session seemingly died, i.e. I was switched back to Linux' virtual
consoles.  I tried to switch back to X by cycling through all of the
VCs, but it didn't bring back the session, so I was convinced that it
had died.  I noticed that I could still see my graphical mouse
pointer, but was thinking nothing of it.

Convinced that my X session had died I logged in at a virtual console
to investigate and restart the display manager.  The login succeeded,
and I was able to restart the display manager.

To my surprise, I discovered that my login credentials were not only
sent to the getty, but also to the still running X session, where it
was sent to an instant messenger, and were exfiltrated to a third
party.  It doesn't help that getty interactions are quite distinct.

I expect that my keyboard inputs are never sent to both an X session
and a virtual console.

I can reliably reproduce it in a virtual machine with a fresh
installation.

Steps to reproduce:

 - Start slim, login as user, start Xmonad session
 - Start an xterm, run 'cat > x'
 - Start (Alt-p) startx
 - Watch your x session being replaced by an empty VC
 - Alt-F1, login as user
 - Run 'cat x':

 user@debian:~$ cat x
 user
 password
 cat x
 user@debian:~$

You can find a video of me reproducing it on my laptop here:

https://teythoon.avior.uberspace.de/tmp/linux-xorg-exfiltrates-credentials.x264.avi

(For dramatic effect, I exfiltrated to my desktop in the video).

I don't know if that matters, but:

# grep allowed_users /etc/X11/Xwrapper.config
allowed_users=anybody

I previously reported this to the security team, but they asked me to
refile it as a normal bug against systemd, because the fix likely
requires coordination between packages.

-- Package-specific info:

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), 
(500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), 
(500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4+deb10u2
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-7~deb10u3
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-7~deb10u3

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  udev 241-7~deb10u3

-- no debconf information

Bug#954083: libmetacpan-client-perl: Please verify server identity via SSL

[Felix Lechner]

Package: libmetacpan-client-perl
Severity: important

Dear maintainer,

Your package uses the Perl module HTTP::Tiny (and refers to the secure
URL https://metacpan.org) but does not set the verify_SSL attribute to
a true value.

By default, that module does not validate the identity of server
certificates. The documentation states that "Server identity
verification is controversial and potentially tricky..." [1]

As late as 2015, upstream has been doubling up: "we're not going to be
responsible for the user's trust model" [2]

I believe, on the other hand, that the encryption of a transmission
has no value when talking to the wrong person. You can easily see the
useless and dangerous default by running the script at the end of this
message.

Will you please turn on the verify_SSL attribute in HTTP::Tiny?

Kind regards
Felix Lechner

[1] https://metacpan.org/pod/HTTP::Tiny#SSL-SUPPORT
[2] https://github.com/chansen/p5-http-tiny/issues/68

* * *

#!/usr/bin/perl

use HTTP::Tiny;

my $response = HTTP::Tiny->new->get('https://self-signed.badssl.com/');
 die "Failed!\n"
unless $response->{success};

print "$response->{status} $response->{reason}\n";

while (my ($k, $v) = each %{$response->{headers}}) {
for (ref $v eq 'ARRAY' ? @$v : $v) {
print "$k: $_\n";
}
}

print $response->{content}
if length $response->{content};

Bug#954089: libplack-perl: Please verify server identity via SSL

[Felix Lechner]

Package: libplack-perl
Severity: important

Dear maintainer,

Your package uses the Perl module HTTP::Tiny, but it does not force
the verify_SSL attribute to a true value.

By default, HTTP::Tiny does not validate the identity of server
certificates. The documentation states that "Server identity
verification is controversial and potentially tricky..." [1]

As late as 2015, upstream has been doubling up: "we're not going to be
responsible for the user's trust model" [2]

I believe, on the other hand, that the encryption of a transmission
has no value when talking to the wrong person. You can easily see
HTTP::Tiny's useless and dangerous default in Plack::LWPish by running
the script at the end of this message.

Will you please turn on the verify_SSL attribute in HTTP::Tiny?
Alternatively, please alert your users so they do not rely on standard
HTTPS security guarantees when using your module.

Kind regards
Felix Lechner

[1] https://metacpan.org/pod/HTTP::Tiny#SSL-SUPPORT
[2] https://github.com/chansen/p5-http-tiny/issues/68

* * *

#!/usr/bin/perl

use HTTP::Request;
use Plack::LWPish;

my $request = HTTP::Request->new(GET => 'https://self-signed.badssl.com/');

my $ua = Plack::LWPish->new;
my $response = $ua->request($request); # returns HTTP::Response

if ($response->is_success) {
print $response->decoded_content;

} else {
print STDERR $response->status_line, "\n";
}

Bug#954102: ITP: starlette -- little ASGI library that shines

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ożarowski 

* Package name: starlette
  Version : 0.13.2
  Upstream Author : Tom Christie 
* URL : https://github.com/encode/starlette
* License : BSD
  Programming Lang: Python
  Description : little ASGI library that shines

Binary package names: python3-starlette

 Starlette is a lightweight ASGI (https://asgi.readthedocs.io/en/latest/)
 framework/toolkit, which is ideal for building high performance asyncio
 services.
 .
 It is production-ready, and gives you the following:
 .
  * Seriously impressive performance.
  * WebSocket support.
  * GraphQL support.
  * In-process background tasks.
  * Startup and shutdown events.
  * Test client built on `requests`.
  * CORS, GZip, Static Files, Streaming responses.
  * Session and Cookie support.
  * 100% test coverage.
  * 100% type annotated codebase.
  * Zero hard dependencies.

Bug#954100: Error: A deprecated csdestruct_derived typemap was found for vtkGDCMTesting

[Mathieu Malaterre]

Control: tags -1 patch fixed-upstream

commit e9b1d198771200dbf1f7cdbf3986cd6ccf311c94 (HEAD -> release)
Author: Mathieu Malaterre <>
Date:   Mon Mar 16 19:16:49 2020 +0100

Implement CA1063 Implement IDisposable correctly

See: https://github.com/swig/swig/issues/421#issuecomment-481125057

Bug#953760: check-service autopkgtest fails while parsing systemctl output

[Michael Biebl]

On Fri, 13 Mar 2020 03:03:25 +0100 Michael Biebl  wrote:
> Source: gpsd
> Version: 3.20-5
> Severity: serious
> 
> Hi,
> 
> the autopkgtest shipped by gpsd fails with the latest systemd v245
> version:
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/g/gpsd/4543825/log.gz
> 
> One immediate problem is, that check-service tries to parse the
> systemctl list-unit-files output, which gained a "VENDOR PRESET" column
> in v245.
> 

This only affects the autopkgtest, not the gpsd binary package itself.



signature.asc
Description: OpenPGP digital signature

Bug#948312: Licensing questions Bug#948312: obfs4proxy: New upstream releasse

[Ulrike Uhlig]

Hi Cecylia!

On 16.03.20 18:24, Cecylia Bocovich wrote:
> On Tue, 7 Jan 2020 10:36:20 +0100 Ulrike Uhlig  wrote:
>> On 07.01.20 10:14, Ulrike Uhlig wrote:
>>> On 07.01.20 00:57, Chris Lamb wrote:

 There is a new upstream release of obfs4proxy available (at the time
 of writing, 0.0.11):>> However, this will require the packaging of
> at least https://gitlab.com/yawning/utls.
>>>
>>> Quoting Ana Custura:
>>>
>>> "
>>> We have 2 options going forward: we can package yawning's fork of uTLS
>>> or we can drop meek-lite support from the obfs4proxy package. We need to
>>> carefully consider this, as it is the only meek client currently
>>> packaged in Debian. I have built a package that drops meek-lite support
>>> (which is easily disabled) of version 0.0.11.

→ actually that package was uploaded to mentors.debian.org and could go
to experimental.

>>> There are some licensing issues that need to be resolved with yawning's
>>> fork of uTLS [3] before we consider looking at packaging it.

>> Tor seems to have had plans to help with the maintenance apparently:
>> https://trac.torproject.org/projects/tor/ticket/29286

> Hey, I'm new to the debian packaging space but am happy to help out here.

Yay! That is very nice, welcome.

> FWIW, there is active interest in a meek client package for Debian [1].

To this I would add the link to the Debian Request For Package (RFP)
bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764007. I haven't
looked at it in detail yet and I don't know if it adds up-to-date
supplementary info to the Torproject bug report.

> Before going forward with dropping it from the obfs4proxy package, we
> should probably have a meek package to take it's place. I've no idea how
> many tools rely on this feature of obfs4proxy but don't want to assume none.
> 
> If I understand correctly, the main blocker on this is licensing
> concerns around Yawning's fork of utls? Perhaps it's better to resolve
> this as the path forward. I'll take a look and see what we can do about
> this.

If I understand correctly from a quick look, Yawning distributes his
changes under GNU GPL, while uTLS upstream has a BSD 3-Clause license
[https://github.com/refraction-networking/utls/blob/master/LICENSE].

The BSD 3-Clause is in line with the Debian Free Software Guidelines
(DFSG)[https://wiki.debian.org/DFSGLicenses#The_BSD-3-clause_License].

>From my understanding, in Debian packaging, licenses generally apply to
files but it also seems possible (I never encountered such a case) to
have several licenses for one file
[https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax].
Maybe someone could confirm that this is accepted.

I'm now unsure to what we referred to previously when saying that there
might be licensing issues with Yawning's fork. It does not look like
there are. Or am I missing something crucial here?

If I don't, then to move forward, one would need to open an RFP or ITP
(Intent to Package) bug on the Debian bugtracker and then package this
fork of uTLS.

best,
ulrike

> [1] https://trac.torproject.org/projects/tor/ticket/13160

Bug#954089: libplack-perl: Please verify server identity via SSL

[Felix Lechner]

Hi Damyan,

On Mon, Mar 16, 2020 at 10:29 AM Damyan Ivanov  wrote:
>
> Any idea how many packages are we talking about?

Below is my working list for filing bugs. It is based on a full text
search from codesearch.d.n.

My designations may not be entirely consistent, but in general 'good'
means that verify_SSL was turned on (or SSL_verify_mode was set in
SSL_options) while 'fpos' means it was a false positive that mentioned
HTTP::Tiny but did not use it.

As a side note, the POD for HTTP::Tiny is ambiguous whether to use
'verify_SSL' or 'SSL_verify'.

If we fix the issue on the consumer side, as suggested by the security
team, we should also include the consumers of many libraries on this
list, such as HTTP::Thin. Please see #954057 for details.

Kind regards
Felix Lechner

#954040 cpanminus
#954041 cpanoutdated
 [good] devscripts
#954042 inxi
 [fpos] libalien-gnuplot-perl
#954043 libcpan-common-index-perl
#954044 libcpan-perl-releases-perl
#954045 libcpanplus-perl
#954046 libcpan-sqlite-perl
 [http] libdancer2-perl
 [http] libdancer-perl
 [fpos] libdbix-class-schema-loader-perl
#954054 libdist-inkt-role-test-perl
 [fpos] libfile-slurp-perl
#954051 libgitlab-api-v4-perl
 [fpos] libhijk-perl
#954056 libhtml-html5-parser-perl
 [fpos] libhttp-lite-perl
#954057 libhttp-thin-perl
#954058 libhttp-tinyish-perl
libhttp-tiny-multipart-perl
libhttp-tiny-perl
 [] libio-socket-ssl-perl
 [fpos] liblexical-accessor-perl
 [good] libmenlo-legacy-perl
#954059 libmenlo-perl
#954083 libmetacpan-client-perl
 [fpos] libmodule-corelist-perl
 [fpos] libmongodb-perl
 [test] libmoo-perl
#954084 libnanomsg-raw-perl
 [fpos] libnet-ssleay-perl
#954085 libpandoc-wrapper-perl
 [fpos] libparallel-forkmanager-perl
#954089 libplack-perl
 [good] libprotocol-acme-perl
librole-rest-client-perl
libsearch-elasticsearch-perl
libspreadsheet-readsxc-perl
libtask-kensho-perl
liburi-encode-perl
#954048 libwww-oauth-perl
 [fpos] libyahc-perl
 [good] ntp
 [fpos] percona-toolkit
perl
 [fpos] pinto
#954038 pkg-perl-tools
#954047 pmuninstall

Bug#952748: closed by Debian FTP Masters (reply to Alastair McKinstry ) (Bug#952748: fixed in cfgrib 0.9.7.7-2)

[Brian Potkin]

On Mon 16 Mar 2020 at 11:06:04 +, Debian Bug Tracking System wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the libreoffice package:
> 
> #952748: libreoffice: Printer and queue attributes not available
> 
> It has been closed by Debian FTP Masters  
> (reply to Alastair McKinstry ).
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Alastair McKinstry 
> ) by
> replying to this email.
> 
> 
> -- 
> 952748: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952748
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Mon, 16 Mar 2020 11:04:14 +
> From: Debian FTP Masters 
> To: 952748-cl...@bugs.debian.org
> Subject: Bug#952748: fixed in cfgrib 0.9.7.7-2
> Reply-To: Alastair McKinstry 
> 
> Source: cfgrib
> Source-Version: 0.9.7.7-2
> Done: Alastair McKinstry 
> 
> We believe that the bug you reported is fixed in the latest version of
> cfgrib, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 952...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Alastair McKinstry  (supplier of updated cfgrib package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Mon, 16 Mar 2020 10:15:28 +
> Source: cfgrib
> Architecture: source
> Version: 0.9.7.7-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Alastair McKinstry 
> Changed-By: Alastair McKinstry 
> Closes: 952748
> Changes:
>  cfgrib (0.9.7.7-2) unstable; urgency=medium
>  .
>* Add python3-cfgrib to test depends. Add simple load test
>* Add depends on python3-cffi
>  Closes: #952748
> Checksums-Sha1:
>  d7759a6dee75b9ac662e059ee7986f2b48b7e483 2082 cfgrib_0.9.7.7-2.dsc
>  1c1fb94bd899a015ffb7bc72fda600734ddc0223 2260 cfgrib_0.9.7.7-2.debian.tar.xz
> Checksums-Sha256:
>  cf51ec2101ecf3431e47a0f3d776990198c4402631814a07a9861e54001d7523 2082 
> cfgrib_0.9.7.7-2.dsc
>  f783f6769ba015312d6d7fe930f2446d994869ed1e82625399076415a56cf2e5 2260 
> cfgrib_0.9.7.7-2.debian.tar.xz
> Files:
>  6a031c9520ae5579b86a762c40a18c14 2082 python optional cfgrib_0.9.7.7-2.dsc
>  a5f7f87024565a2c1119a7f818bf1628 2260 python optional 
> cfgrib_0.9.7.7-2.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAl5vV7wACgkQy+a7Tl2a
> 06WxSw//ePK13tysQW11q4eShwCWKvggt6qc1+4O+QNYk/k7SZcphbp688sM3bq0
> zyEBliGu3t7Sbovi8FoQI/Ysnb/bNeGFNWstRhYqjtBg06BRHNyNtzxvsF3FD8Fe
> J+3sqhBmLl//j5FyLd2v6g+txbxghhjEgDTa8tEyIEWqRuTuE8Dz3n32a8jfcdDy
> sSavjVJcYJLjdx5UYP4l1UVAeH0lzt06HuQOZbvKngbGZHahZU/+D6SwUd+ZbCUM
> y9cx9iOpxHszq2DbZjiVun0OWazzg8CZzC7iDsJd/zV/+XCTyNm7w9jZ6xwF/py2
> SNspXwGakLnjc9f3+foSKCVRrchKxkIj5MrNmAFnRBa1NbaNgah5FNiFQ5rfII9G
> D8vVin99ZOM9V/ffuAk5jb9/jsr9rw6AyB2Cj25u6MTecVQPUuEn4dGkcV6a0pVS
> Jpn1AqUkaiSvIkTjAvJWH7a01XoIPg34YGI6pYdITxw/p7j3WBt6f8YLg2r0wfHd
> z+AJs1xeqpKif3CVM7T+ExHAlC6JltN1nAUfhhQljEB9W+pl34qEUKABlhTXK5Co
> jnm2m46kV8XbgCXVXkGgS9awqLu4KYdOXSIcEQEsz1zY886B5k8BOhr1TEPtIIM4
> DUzw7bPQONmZ1+mgG48rOCc6wEYp974Q2hIJDloB8SfoMUEEGA8=
> =A1uO
> -END PGP SIGNATURE-

> Date: Fri, 28 Feb 2020 13:55:28 +
> From: Brian Potkin 
> To: Debian Bug Tracking System 
> Subject: libreoffice: Printer and queue attributes not available
> User-Agent: Mutt/1.10.1 (2018-07-13)
> 
> Package: libreoffice
> Version: 1:6.4.1~rc1-2
> Severity: important
> 
> 
> I have an up-to-date unstable system with CUPS and cups-filters
> installed. cups-browsed is not installed.
> 
> The print dialog has two entries: ENVY4500 and LaserJet_300_desktop.
> The ENVY is an IPP printer on the network and the LaserJet is an
> advertised queue on a remote CUPS server. The enumeration is done via
> DNS-SD from the printer and the server and both devices are capable of
> two-sided printing. All ok up to there.
> 
> Looking under Properties/Device the only option is "Manual feed". This
> means that a user cannot set values for Media Type, Color Model
> and Print Quality when these attributes are available on printer or
> queue. Here is an output from querying the printer:
> 
> brian@cupstest:~$ lpoptions -p envy4500 -l
> PageSize/Media Size: 100x150mm 111.76x152.4mm 3.5x5 3.5x5.Borderless 3x5  
>  4x6 4x6.Borderless 5x7 
> 5x7.Borderless 5x8 8x10 8x10.Borderless *A4   
>   

Bug#883867: bookworm for accessibility

[hjenkins]

Packaging the Bookworm e-reader could significantly improve the 
accessibility of Debian. Bookworm is written by blind developers, 
according to its website.


E-book readers are important if you are vision-impaired. Many e-book 
programs don't work well with screenreaders. Bookworm has and interface 
and documentation that is accessible to the vision-impaired, and it also 
has good independent reviews from sighted users.


FBreader seems to have been proprietized (formerly GPL2 or later)! I'm 
not sure if it's been forked or what; there do not seem to be new 
updates.

Bug#954089: libplack-perl: Please verify server identity via SSL

[Felix Lechner]

Hi Gregor,

On Mon, Mar 16, 2020 at 9:35 AM gregor herrmann  wrote:
>
> (Taking a random instance of the identical mass bug filing.)

Many are very similar, but not all are identical.

> - Is is realistic to patch dozens of upstream files?
> - Should the default be changed in HTTP::Tiny? (In src:perl and in
>   libhttp-tiny-perl) In Debian (or better upstream though the latter
>   might be difficult given the texts you quote.)

I pursued that route originally (although not exhaustively).
HTTP::Tiny is apparently used in a lot of tests, which would have to
be modified. Also, the module ships as part of Perl core.

In October of last year, I raised the issue with Debian's security
team and received the following reply from Moritz Mühlenhoff, whom I
copied (to avoid talking about people not present). Paul Wise was also
party to the original exchange; he was likewise copied:

> It's not an acceptable default if one would create it from scratch today,
> but I can see their point wrt avoiding to change the default in retrospect
> on a widely installed base. Python made a similar change in 3.x which was
> backported to 2.7 with notable fallout.

> But that doesn't mean that we shouldn't review/change the setting
> as used by reverse dependencies in the archive, I suggest to file
> bugs with severity important for any reverse dependency of the module
> which doesn't have it enabled.

> The maintainers can then assess impact for their respective packages
> and adjust it for bullseye as they see fit (and add a NEWS for high
> profile cases.

As you can see, I am implementing a recommendation I received some
time ago from Debian's security team.

Sorry about all the filings. Another five may follow.

Kind regards
Felix Lechner

Bug#953021: libhdf5-mpi-dev: provide links to default mpi (hdf5-mpi.pc)

[Gilles Filippini]

Hi Drew,

Drew Parsons a écrit le 03/03/2020 à 19:43 :
> Thinking about it, if possible it would be best to have hdf5-mpi.pc
> managed by update-alternatives, but tracking the mpi alternative.
> 
> i.e. set up as a slave alternative depending on mpi, that updates if the
> local system switches mpi from openmpi to mpich.
> 
> I'm not sure if this can be done cross-package, but good if it can.
> 
> If it can be done, then the control logic would go in the postinst/prerm
> of libhdf5-openmpi-dev and libhdf5-mpich-dev rather than libhdf5-mpi-dev.

I'm not sure what you have in mind here. I've just uploaded a new
release to experimental which should fix #953020. It may covers #953021
as well. Please let me know...

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures

[John Paul Adrian Glaubitz]

On 3/16/20 5:34 PM, John David Anglin wrote:
> With patch, I get following error:

See [1], the build system is not very smart, unfortunately.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939453

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#950762: ksh,ksh93: both ship /etc/skel/.kshrc with insufficient Conflicts/Breaks/Replaces

[Andreas Beckmann]

On 01/03/2020 02.28, Anuradha Weeraman wrote:
> On Thu, Feb 06, 2020 at 03:44:51PM +, Thorsten Glaser wrote:
>> I had considered that, but creating a ksh-common package for just
>> one file, which in addition to that is a skeleton file that is not
>> used during normal operation, just adduser, seems overkill. The
>> sequence of installing both then removing one is also expected to
>> occur only rarely, most users would either install one, or both,
>> and then keep that. I had thought that that with the Replaces on
>> the other packages would be sufficient.
>>
>> Is it possible to make an exception here, considering the file in
>> question and that it is documented?
> 
> Hi Andreas
> 
> I would agree on Thorsten's point above that it would be somewhat
> overkill in this given scenario.
> 
> Please suggest if you would be okay with an exception in this regard, or
> if you still feel that this needs to be addressed?

I'm not really happy with this, since it may result in some weird
behavior (spurious disappearance of .kshrc looking non-deterministic) at
some point in the future.

Both ksh and ksh93 ship the same .kshrc. I assume, ksh93 will go away at
some point in the future even if its alternative currently has higher
priority. Would it be possible to have ksh93 depend on ksh? That might
also help encourage migration from ksh93. Then only ksh ships .kshrc
(with B+R: ksh93 (<< 93u+20120801-8~) to properly claim ownership of
.kshrc again) while ksh93 either drops the unversioned
R: ksh or makes it versioned to match the existing Breaks.

Andreas

Bug#954090: override: tasksel:admin/optional

[Sean Whitton]

Hello Raphaël,

On Mon 16 Mar 2020 at 04:34PM +01, Raphaël Hertzog wrote:

> Package: ftp.debian.org
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
>
> tasksel 3.57 changed its priority to optional and d-i is now installing it
> when it needs it so it doesn't matter that it's no longer installed after
> a debootstrap.
>
> Please update the override accordingly.

Can you point to the relevant changelog entries so I can look through
what's going on before changing the override?  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#948312: [Pkg-privacy-maintainers] Bug#948312: obfs4proxy: New upstream releasse

[Cecylia Bocovich]

On Tue, 7 Jan 2020 10:36:20 +0100 Ulrike Uhlig  wrote:
> On 07.01.20 10:14, Ulrike Uhlig wrote:
> > On 07.01.20 00:57, Chris Lamb wrote:
>
> >> There is a new upstream release of obfs4proxy available (at the time
> >> of writing, 0.0.11):>> However, this will require the packaging of
at least https://
> >> gitlab.com/yawning/utls.
> >
> > Quoting Ana Custura:
> >
> > "
> > We have 2 options going forward: we can package yawning's fork of uTLS
> > or we can drop meek-lite support from the obfs4proxy package. We need to
> > carefully consider this, as it is the only meek client currently
> > packaged in Debian. I have built a package that drops meek-lite support
> > (which is easily disabled) of version 0.0.11.
> >
> > There are some licensing issues that need to be resolved with yawning's
> > fork of uTLS [3] before we consider looking at packaging it.
>
> Thinking about this a bit more I think it might also be worth asking Tor
> (for example via irl@d.o or Philipp Winter, the lead of the censorship
> team at Tor, https://nymity.ch/contact.txt) if they have a preferred way
> of moving forward.
>
> Tor seems to have had plans to help with the maintenance apparently:
> https://trac.torproject.org/projects/tor/ticket/29286
>
> -- ulrike
>
>

Hey, I'm new to the debian packaging space but am happy to help out here.

FWIW, there is active interest in a meek client package for Debian [1].
Before going forward with dropping it from the obfs4proxy package, we
should probably have a meek package to take it's place. I've no idea how
many tools rely on this feature of obfs4proxy but don't want to assume none.

If I understand correctly, the main blocker on this is licensing
concerns around Yawning's fork of utls? Perhaps it's better to resolve
this as the path forward. I'll take a look and see what we can do about
this.

[1] https://trac.torproject.org/projects/tor/ticket/13160

- cecylia

Bug#954100: Error: A deprecated csdestruct_derived typemap was found for vtkGDCMTesting

[Mathieu Malaterre]

Source: gdcm
Version: 3.0.4
Severity: serious
Tags: upstream ftbfs

Using SWIG 4.0, gdcm ftbfs

> cd /gdcm/obj-x86_64-linux-gnu/Utilities/VTK && /usr/bin/cmake -E 
> make_directory /gdcm/obj-x86_64-linux-gnu/Utilities/VTK 
> /gdcm/obj-x86_64-linux-gnu/Utilities/VTK/CMakeFiles/vtkgdcmsharpglue.dir && 
> /usr/bin/cmake -E env SWIG_LIB=/usr/share/swig4.0 /usr/bin/swig4.0 -csharp 
> -namespace vtkgdcm -dllimport vtkgdcmsharpglue -outdir 
> /gdcm/obj-x86_64-linux-gnu/Utilities/VTK -c++ -I/usr/include 
> -I/usr/include/vtk-7.1 -I/usr/include/freetype2 
> -I/usr/include/x86_64-linux-gnu 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/include/python3.8 
> -I/usr/include/hdf5/openmpi -I/usr/include/jsoncpp -I/usr/include/libxml2 
> -I/usr/include/tcl -I/gdcm/obj-x86_64-linux-gnu/Source/Common 
> -I/gdcm/Source/Common -I/gdcm/Source/DataStructureAndEncodingDefinition 
> -I/gdcm/Source/MediaStorageAndFileFormat -I/gdcm/Source/DataDictionary 
> -I/gdcm/Utilities/VTK -o 
> /gdcm/obj-x86_64-linux-gnu/Utilities/VTK/CMakeFiles/vtkgdcmsharpglue.dir/vtkgdcmCSHARP_wrap.cxx
> /gdcm/Utilities/VTK/vtkgdcm.i
> /usr/include/vtk-7.1/vtkStringArray.h:36: Warning 402: Base class 
> 'vtkAbstractArray' is incomplete.
> /usr/include/vtk-7.1/vtkAlgorithm.h:38: Warning 402: Only forward declaration 
> 'vtkAbstractArray' was found.
> /gdcm/Utilities/VTK/vtkgdcm.i:354: Error: A deprecated csdestruct_derived 
> typemap was found for vtkGDCMTesting, please remove it and replace all 
> csdestruct, csdestruct_derived and csfinalize typemaps by the csdispose, 
> csdispose_derived, csdisposing and csdisposing_derived typemaps.
> /gdcm/Utilities/VTK/vtkgdcm.i:365: Error: A deprecated csdestruct_derived 
> typemap was found for vtkGDCMImageReader, please remove it and replace all 
> csdestruct, csdestruct_derived and csfinalize typemaps by the csdispose, 
> csdispose_derived, csdisposing and csdisposing_derived typemaps.
> /gdcm/Utilities/VTK/vtkgdcm.i:376: Error: A deprecated csdestruct_derived 
> typemap was found for vtkGDCMImageWriter, please remove it and replace all 
> csdestruct, csdestruct_derived and csfinalize typemaps by the csdispose, 
> csdispose_derived, csdisposing and csdisposing_derived typemaps.
> ninja: build stopped: subcommand failed.
> dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v 
> returned exit code 1
> make[1]: *** [debian/rules:110: override_dh_auto_build-arch] Error 25
> make[1]: Leaving directory '/gdcm'
> make: *** [debian/rules:54: build] Error 2

Bug#954101: ITP: python-databases -- async database support for Python's asyncio

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ożarowski 

* Package name: python-databases
  Version : 0.3.0
  Upstream Author : Tom Christie 
* URL : https://github.com/encode/databases
* License : BSD
  Programming Lang: Python
  Description : async database support for Python's asyncio

Binary package names: python3-databases

 Databases gives you simple asyncio support for a range of databases.
 .
 It allows you to make queries using the powerful SQLAlchemy Core
 expression language, and provides support for PostgreSQL, MySQL, and SQLite.
 .
 Databases is suitable for integrating against any async Web framework, such as
 Starlette, Sanic, Responder, Quart, aiohttp, Tornado, FastAPI or Bocadillo.

Bug#477498: 10 das suas mensagens recebidas foram suspensas

[Vasilka Tabakova]

MEMORANDO DE NOTIFICAÇÃO DA MICROSOFT

10 das suas mensagens recebidas foram suspensas e sua conta da caixa de e-mail 
também será suspensa em breve agora porque sua conta da caixa de e-mail não foi 
confirmada para este ano. clique em verificar agora abaixo para verificar sua 
conta da caixa de e-mail


VERIFIQUE AGORA



Obrigado pela sua compreensão



Equipe de verificação da Microsoft



Microsoft Outlook Copyright © 2020 .Inc. Todos os direitos reservados.

Bug#954081: debian-live-10.3.0-amd64-gnome.iso fails to load desktop on Acer A515-43-R19L laptop

[Lou Poppler]

This is possibly a "non-free" firmware problem.  I suggest you try with one of
the "unofficial" "non-free" live images or installer images.

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/

On Mon, 2020-03-16 at 09:25 -0400, Mike Haag wrote:
> Package: debian-live
> Severity: important
> 
> I first updated the BIOS using the supplied Windows 10, then replaced the
> supplied 128GB SSD with a new 500GB SSD.
> 
> Verified the iso file with SHA512, and tried running as both DVD and USB thumb
> drive:
> 
> Grub starts as expected.
> 
> 1. Attempted to start the live desktop environment from the first Grub menu
> item, "Debian GNU/Linux Live (kernel 4.19.0-8-amd64)".
> 2. Multiple status messages are displayed. Then, a Debian splash screen is
> briefly displayed, followed immediately by a blank screen with a blinking
> cursor, and the system freezes.
> 3. Ctrl-Alt-Del will reboot the laptop into the Grub menu.
> 
> The graphical installer (third Grub menu item) runs, and appears to complete
> successfully. But, the installed system exhibits the same problem: Multiple
> startup messages, and the system freezes before the desktop environment 
> starts,
> just displaying a blank screen and blinking cursor.
> 
> For what it's worth, I also tried several other Debian-based and RPM
> distributions. Could only get a working system with the RPMs:
> 
> 1. Debian: The following produce the same results as above.
> 
>  debian-live-10.3.0-amd64-gnome+nonfree.iso
>  debian-live-testing-amd64-gnome.iso
>  debian-10.3.0-amd64-netinst.iso
> 
> 2. Ubuntu 19.10 and LinuxMint 19.3: The live distributions work as
>expected. Installed systems begin to boot but then both fail with
>unspecified watchdog soft lock errors before their respective desktop
>environments start.
> 
> 3. Fedora 31: Live runs as expected. Installed system boots and runs as
> expected.
> 
> 4. OpenSUSE Leap 15.1: Live runs as expected. Installed system boots and runs
> as expected.
> 
> The only recommendation I could find using the Acer user forum and other
> internet searches, was to try editing the Grub menu line to "nomodeset", but
> that doesn't work. There was also some theorizing that the kernel needed to be
> updated to 5.0, but openSUSE 15.1 is kernel 4.12, and that is working.
> 
> Looking for advice and suggestions: I do not know how to proceed with further
> trouble-shooting.
> 
> Thanks, Mike
> 
> 
> 
> -- System Information:
> Debian Release: 10.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-8-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
> 

Bug#950762: ksh,ksh93: both ship /etc/skel/.kshrc with insufficient Conflicts/Breaks/Replaces

[Thorsten Glaser]

Andreas Beckmann dixit:

>Both ksh and ksh93 ship the same .kshrc. I assume, ksh93 will go away at
>some point in the future even if its alternative currently has higher

No, we deliberately brought it back, as ksh2020 development goes
into different directions and has different goals, e.g. causing
a 300% performance regression, since the users complained, so it’s
probably going to stay.

>That might also help encourage migration from ksh93.

We don’t want to do that for the foreseeable future. In fact, we
expect some conservative development on top of ksh93, and migrating
back to it, to happen.

But if it makes things better, we can move the file to ksh-common.
Just seems to be a waste of resources, especially given it’s in
/etc/skel…

bye,
//mirabilos
-- 
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing

Bug#954073: buster-pu: package postfix/3.4.9-0+10debu1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2020-03-16 at 08:00 -0400, Scott Kitterman wrote:
> On Monday, March 16, 2020 7:25:09 AM EDT Emilio Pozuelo Monfort
> wrote:
> > Hi Scott,
> > 
> > On 16/03/2020 12:00, Scott Kitterman wrote:
[...]
> > > This is the next in the normal series of postfix bugfix
> > > updates.  This
> > > update has a single fix for a long standing milter processing
> > > error.  It
> > > should be low risk and is in Testing already.
> > > 
> > > Bugfix (introduced: Postfix 2.3): panic with Postfix
> > > multi-Milter configuration during MAIL FROM. Milter
> > > client
> > > state was not properly reset after one of the Milters
> > > failed.
> > > Reported by WeiYu Wu.
> > > 
> > > As usual, I have this version running on several machines of my
> > > own with
> > > no issues noted.  Debdiff attached.  Please approve so I can
> > > upload.
> > 
> > Subject seems wrong, this is 3.4.10.
> > 
> > Also your version is 3.4.10-0deb10u1, but it should rather be
> > 3.4.10-0+deb10u1 (i.e. an extra plus sign).
> > 
> > With those changes I'd ack the upload, but let's wait for an SRM to
> > confirm.
> 
> Thanks.  Fixed the revision.  The reportbug template pulls up the
> current version of the package, which I always thought was odd.

I think the intent was "this is an update to version X". To be entirely
honest I personally don't really pay that much attention to the version
number in the subject.

Please go ahead.

Regards,

Adam

Bug#953880: gimp: segmentation fault on startup

[Sophoklis Goumas]

Package: gimp
Version: 2.10.14-2+b1
Followup-For: Bug #953880

I also had to remove gimp-gap (2.6.0+dfsg-5+b2).

Sophoklis

Bug#937622: python-bsddb3: diff for NMU version 6.2.7-1.1

[Sandro Tosi]

Control: tags 937622 + patch


Dear maintainer,

I've prepared an NMU for python-bsddb3 (versioned as 6.2.7-1.1). The diff
is attached to this message.

Regards.

diff -Nru python-bsddb3-6.2.7/debian/changelog python-bsddb3-6.2.7/debian/changelog
--- python-bsddb3-6.2.7/debian/changelog	2020-02-18 11:12:56.0 -0500
+++ python-bsddb3-6.2.7/debian/changelog	2020-03-16 15:06:57.0 -0400
@@ -1,3 +1,10 @@
+python-bsddb3 (6.2.7-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937622
+
+ -- Sandro Tosi   Mon, 16 Mar 2020 15:06:57 -0400
+
 python-bsddb3 (6.2.7-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-bsddb3-6.2.7/debian/control python-bsddb3-6.2.7/debian/control
--- python-bsddb3-6.2.7/debian/control	2020-02-18 11:12:56.0 -0500
+++ python-bsddb3-6.2.7/debian/control	2020-03-16 15:05:02.0 -0400
@@ -5,45 +5,12 @@
 Build-Depends: debhelper (>= 9),
   dh-python,
   libdb5.3-dev,
-  python2.7-dev (>= 2.7.8-4),
-  python-all-dev (>= 2.6.6-1~),
-  python-all-dbg,
   python3-all-dev (>= 3.2.3-7~),
   python3-all-dbg
 Build-Depends-Indep: python3-sphinx
 Standards-Version: 4.5.0
 Homepage: http://pypi.python.org/pypi/bsddb3/
 
-Package: python-bsddb3
-Architecture: any
-Depends: ${shlibs:Depends}, ${python:Depends}, ${misc:Depends}
-Suggests: python-bsddb3-dbg
-Provides: ${python:Provides}
-Description: Python interface for Berkeley DB
- This module provides a nearly complete wrapping of the Oracle/Sleepycat C API
- for the Database Environment, Database, Cursor, Sequence and Transaction
- objects, and each of these is exposed as a Python Type in the bsddb3.db
- module.  The database objects can use various access methods: btree, hash,
- recno and queue.  Complete support of Berkeley DB distributed transactions.
- Complete support for Berkeley DB Replication Manager. Complete support for
- Berkeley DB Base Replication. Support for RPC.
-
-Package: python-bsddb3-dbg
-Architecture: any
-Section: debug
-Depends: python-bsddb3 (= ${binary:Version}), python2-dbg, ${shlibs:Depends}, ${misc:Depends}
-Provides: ${python:Provides}
-Description: Python interface for Berkeley DB (debug extension)
- This module provides a nearly complete wrapping of the Oracle/Sleepycat C API
- for the Database Environment, Database, Cursor, Sequence and Transaction
- objects, and each of these is exposed as a Python Type in the bsddb3.db
- module.  The database objects can use various access methods: btree, hash,
- recno and queue.  Complete support of Berkeley DB distributed transactions.
- Complete support for Berkeley DB Replication Manager. Complete support for
- Berkeley DB Base Replication. Support for RPC.
- .
- This package contains the extension built for the python debug interpreter.
-
 Package: python3-bsddb3
 Architecture: any
 Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
diff -Nru python-bsddb3-6.2.7/debian/rules python-bsddb3-6.2.7/debian/rules
--- python-bsddb3-6.2.7/debian/rules	2019-01-21 17:25:17.0 -0500
+++ python-bsddb3-6.2.7/debian/rules	2020-03-16 15:06:52.0 -0400
@@ -3,8 +3,6 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-PYVERS  := $(shell pyversions -vs)
-PYVER   := $(shell pyversions -vd)
 PY3VERS   := $(shell py3versions -vs)
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
@@ -17,19 +15,7 @@
 build: build-stamp
 build-arch: build-stamp
 build-indep: build-stamp
-build-stamp: $(PYVERS:%=build-python%) $(PYVERS:%=dbg-build-python%) $(PY3VERS:%=build3-python%) $(PY3VERS:%=dbg-build3-python%)
-	touch $@
-
-build-python%:
-	BERKELEYDB_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
-	BERKELEYDB_INCDIR=/usr/include \
-	python$* setup2.py build $(build_args)
-	touch $@
-
-dbg-build-python%:
-	BERKELEYDB_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
-	BERKELEYDB_INCDIR=/usr/include \
-	python$*-dbg setup2.py build $(build_args)
+build-stamp: $(PY3VERS:%=build3-python%) $(PY3VERS:%=dbg-build3-python%)
 	touch $@
 
 build3-python%:
@@ -57,7 +43,7 @@
 	find -name '*.py[co]' | xargs -r rm -f
 	dh_clean
 
-install: build install-prereq $(PYVERS:%=install-python%) $(PYVERS:%=dbg-install-python%) $(PY3VERS:%=install3-python%) $(PY3VERS:%=dbg-install3-python%)
+install: build install-prereq $(PY3VERS:%=install3-python%) $(PY3VERS:%=dbg-install3-python%)
 	find debian -name '*.py[co]' | xargs -r rm -f
 
 install-prereq:
@@ -65,29 +51,6 @@
 	dh_testroot
 	dh_prep
 
-install-python%:
-	mkdir -p $(d)/usr/bin
-#	mkdir -p $(d)/usr/lib/python$*/site-packages
-	BERKELEYDB_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
-	BERKELEYDB_INCDIR=/usr/include \
-	python$* setup2.py install \
-		--root=$(CURDIR)/$(d) --install-layout=deb $(build_args)
-	rm -rf $(d)/usr/lib/python$*/*-packages/bsddb3/tests
-
-dbg-install-python%:
-	mkdir -p $(d)/usr/bin
-#	mkdir -p $(d)-dbg/usr/lib/python$*/site-packages
-	BERKELEYDB_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
-	

Bug#954006: release.debian.org: Please allow postfix to migrate despite autopkgtest failures, they are unrelated

[Scott Kitterman]

On Monday, March 16, 2020 5:03:52 PM EDT Paul Gevers wrote:
> Hi Scott,
> 
> On 16-03-2020 21:51, Scott Kitterman wrote:
> > Thanks for the clarification.  I guess I need a better understanding of
> > when manual intervention is required.  Is there something I can read that
> > would explain that?
> 
> Unfortunately it's not totally up-to-date, but this wiki probably has
> some of the missing pieces for you (especially the Delta to Ubuntu section).
> 
> https://wiki.debian.org/ContinuousIntegration/DebianSetup
> 
> I'll update that wiki shortly.

Thanks.  It would be useful to have some guidance on how long to wait before 
contacting the release team for regressions that aren't and how you prefer to 
be contacted (I only knew to file a bug because I asked you previously).

Scott K

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

Bug#933177: network-manager-openvpn: unable to connect after upgrade to buster due to new OpenSSL minimum TLS version

[Tarik Graba]

Shouldn't version 1.8.12 added to Debian backports?

Bug#954109: librole-rest-client-perl: Please verify server identity via SSL

[Felix Lechner]

Package: librole-rest-client-perl
Severity: important

Dear maintainer,

Your package uses the Perl module HTTP::Tiny, but it does not force
the verify_SSL attribute to a true value.

By default, HTTP::Tiny does not validate the identity of server
certificates. The documentation states that "Server identity
verification is controversial and potentially tricky..." [1]

As late as 2015, upstream has been doubling up: "we're not going to be
responsible for the user's trust model" [2]

I believe, on the other hand, that the encryption of a transmission
has no value when talking to the wrong person. You can easily see
HTTP::Tiny's useless and dangerous default in Role::REST::Client by
running the script at the end of this message.

Will you please turn on the verify_SSL attribute in HTTP::Tiny?
Alternatively, please alert your users so they do not rely on standard
HTTPS security guarantees when using your module.

Kind regards
Felix Lechner

[1] https://metacpan.org/pod/HTTP::Tiny#SSL-SUPPORT
[2] https://github.com/chansen/p5-http-tiny/issues/68

* * *

#!/usr/bin/perl

{
package RESTExample;

use Moo;
with 'Role::REST::Client';

sub access {
my ($self) = @_;

my $response = $self->get('/');

return $response->data
  if $response->code == 200;
}
}

my $badssl = RESTExample->new(server => 'https://self-signed.badssl.com/');
print $badssl->access;

Bug#954113: vim-runtime: tap.vim: Don't clobber global settings of fold.* options

[Daniel Shahaf]

Package: vim
Version: 2:8.2.0368-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

syntax/tap.vim uses «:set foo» to set window-local options.

That changes the default setting of those options for new buffers.

Here is a patch to fix that:

[[[
diff --git a/runtime/syntax/tap.vim b/runtime/syntax/tap.vim
index db37bb8..b2f00ad 100644
--- a/runtime/syntax/tap.vim
+++ b/runtime/syntax/tap.vim
@@ -51,17 +51,17 @@ syn region tapTestResultsSummaryNotOK start=/TODO passed:/ 
end=/$/ contained
 
 syn region tapTestInstructionsRegion start=/\%1l/ end=/^$/
 
-set foldtext=TAPTestLine_foldtext()
+setl foldtext=TAPTestLine_foldtext()
 function! TAPTestLine_foldtext()
 let line = getline(v:foldstart)
 let sub = substitute(line, '/\*\|\*/\|{{{\d\=', '', 'g')
 return sub
 endfunction
 
-set foldminlines=5
-set foldcolumn=2
-set foldenable
-set foldmethod=syntax
+setl foldminlines=5
+setl foldcolumn=2
+setl foldenable
+setl foldmethod=syntax
 syn sync fromstart
 
 if !exists("did_tapverboseoutput_syntax_inits")
]]]

Cheers,

Daniel

Bug#953127: RFS: fonts-jetbrains-mono/1.0.3-2 [ITP] -- free and open-source typeface for developers

[Romain Porte]

Hi Adam,

2020-03-16 20:52 CET, Adam Borowski:
> On Mon, Mar 16, 2020 at 01:02:38PM +0100, Romain Porte wrote:
> > I am requiring your mentorsip help to publish this package.
> > I have received some feedback from Adam, but not much since then.
>
> Sorry for not responding sooner, my TODO list is bursting at seams.
> It seems to one else responded as well...

No problem, I understand that everyone can be busy, myself uncluded. ;)

I shouted out to debian-devel also because I have been observing the
ongoing threads and one newcomer has been greatly helped in proposing
her/his first contribution to the project. But if you can continue the
sponsoring then thanks!

> > Our discussion about the package can be followed on the ITP bug:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952954
>
> The main obstacle being the FontLab format problem, and I'm not very
> knowledgeable about it.  Unless there's some free tool that can read that
> format and convert it (possibly in multiple hops) to TrueType, the font
> can't enter the main archive.
>
> It would be greatly preferred to find a solution, but if one can't be
> found, the "contrib" archive can be used.  For that, you'd change
> "Section: fonts" to "Section: contrib/fonts".

So that was it! It was really unclear for me what the options we had, as
I am very new to the ecosystem I did not think about changing the
Section to contrib/fonts in order to "fix" this issue.

As we do not find a compromise for main inclusion, I am fine for this
package to go to contrib. I can explain the why in the debian/copyright
file as suggested by Lintian when I have changed the section.

> > The package has been released to -2 Debian release with some
> > improvements.
> >
> > Changes since the last upload:
>
> But... there was no previous upload.  Unless you know of any actual users
> who rely on your -1 packaging, the Debian scheme is to avoid bumping the
> version for any of WIP versions that did not enter the distribution.
>
> Thus, unless there's a good reason, it would be nice if you could mark
> the changelog entry as -1.

So my problem was that after first publication on mentors, the "dput"
call to the same -1 revision was refused because the file was already
existing on the server.

I have just retried now after updating the section and copyright file
and dput went fine:

> Successfully uploaded fonts-jetbrains-mono_1.0.3-1.dsc to mentors.debian.net 
> for mentors.
> Successfully uploaded fonts-jetbrains-mono_1.0.3.orig.tar.xz to 
> mentors.debian.net for mentors.
> Successfully uploaded fonts-jetbrains-mono_1.0.3-1.debian.tar.xz to 
> mentors.debian.net for mentors.
> Successfully uploaded fonts-jetbrains-mono_1.0.3-1_all.deb to 
> mentors.debian.net for mentors.
> Successfully uploaded fonts-jetbrains-mono_1.0.3-1_amd64.buildinfo to 
> mentors.debian.net for mentors.
> Successfully uploaded fonts-jetbrains-mono_1.0.3-1_amd64.changes to 
> mentors.debian.net for mentors.

But just after that I received an email saying that the package could
not be updated:

> Hello,
>
> Unfortunately your package "fonts-jetbrains-mono" was rejected because
> of the following reason:
>
> An upload with the same version but different distribution exists on
> mentors.  If you wish to upload this version for an other
> distribution, delete the old one.
>
> Please try to fix it and re-upload. Thanks,

So I deleted the whole package (all revisions) in the mentors web
interface (cannot be done directly on command line? I think --force on
dput would not help here as it is mentors-specific).

But now when I am retrying to republish the package in mentors I get the
following:

> $ dput mentors fonts-jetbrains-mono_1.0.3-1_amd64.changes
> Package has already been uploaded to mentors on mentors.debian.net
> Nothing more to do for fonts-jetbrains-mono_1.0.3-1_amd64.changes

And… basically reproduced it! This is why I have bumped the debian
revision between -1 and -2 in the first place in my first uploads.

I am quite lost in the steps to overcome this situation properly right
now.

> But it's the buildable-from-source -or- contrib issue that's the blocker.

I think we should go the contrib-way. I have fixed the package locally
and need some place to upload this fixed -1 release.

Thanks again for your support.

Ciao,

Romain.


signature.asc
Description: PGP signature

Bug#954114: wine-development: build-dependencies unsatisfiable.

[peter green]

Source: wine-development
Version: 5.2-3
Severity: serious

wine-development build-depends on unicode-data (<< 13) but the version of 
unicode-data in testing is 13.0.0-1 and the version in unstable is 13.0.0-2

Bug#954016: vim-runtime: tap.vim: Make "TODO" and "SKIP" case-insensitive

[Daniel Shahaf]

Daniel Shahaf wrote on Sun, Mar 15, 2020 at 18:59:29 +:
> P.S. I think there are at least two other bugs in tap.vim: (1) As
> mentioned above, TAP syntax is not highlighted unless there is an empty
> line above the plan line; (2) syntax/tap.vim sets various fold.* options
> globally, rather than locally and via an ftplugin.  However, let's keep
> this ticket about the skip case-sensitivity thing only.

For the curious, I worked around this by adding «autocmd FileType tap
syn clear tapTestInstructionsRegion tapTestRegion» to my .vimrc and
locally applying the patch from #954113.

> Please find attached a patch that lets those keywords be matched case
> insensitively:

That's still applicable.

Cheers,

Daniel

Bug#954001: timeshift 19.01+ds-2+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: timeshift
Version: 19.01+ds-2+deb10u1

Explanation: fix predictable temporary directory use [CVE-2020-10174]

Bug#943889: hbci4java 3.1.29+dfsg-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: hbci4java
Version: 3.1.29+dfsg-1+deb10u1

Explanation: support EU directive on payment services (PSD2)

Bug#943889: hibiscus 2.8.21+dfsg-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: hibiscus
Version: 2.8.21+dfsg-1+deb10u1

Explanation: support EU directive on payment services (PSD2)