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#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#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#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&arch=hurd-i386&ver=0.0.13-1&stamp=1584192605&raw=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#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#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 scanima

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#954049: lintian-brush: combine into one commit the move of name/contact from upstream metadata to debian copyright

[Jelmer Vernooij]

tag 954049 +confirmed
thanks

On Mon, Mar 16, 2020 at 10:17:25AM +0800, Paul Wise wrote:
> When lintian-brush moves the name/contact fields from the upstream
> metadata to the debian copyright file, it generates two commits; one
> for the removal and one for the addition. I think that this is overkill and 
> one commit doing the move should be enough.
> 
> I suggest this as the commit message for the single commit:
> 
> Move some upstream metadata fields to Debian copyright info
Yep, we can definitely do this. The reason why it's two commits at the
moment is more practical than intentional. It's a result of the code
structure in lintian-brush; the code that adds items in
debian/copyright based on debian/upstream/metadata and the code that
removes duplicate items from debian/upstream/metadata are separate
scripts.

jelmer


signature.asc
Description: PGP signature

Bug#954095: [gimp] GIMP fails to boot, with a segmentation fault

[Sergio Costas]

Package: gimp
Version: 2.10.14-2+b1
Severity: grave

--- Please enter the report below this line. ---

When launching GIMP, it fails with a segmentation fault and opens a 
window with this text:



```
GNU Image Manipulation Program version 2.10.14
git-describe: GIMP_2_10_12-511-ga4f55d6c7e
C compiler:
    Using built-in specs.
    COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
    OFFLOAD_TARGET_NAMES=nvptx-none:hsa
    OFFLOAD_TARGET_DEFAULT=1
    Target: x86_64-linux-gnu
    Configured with: ../src/configure -v --with-pkgversion='Debian 
9.2.1-31' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 
--prefix=/usr --with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
--enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-mutex

    Thread model: posix
    gcc version 9.2.1 20200306 (Debian 9.2.1-31)

using babl version 0.1.74 (compiled against version 0.1.74)
using GEGL version 0.4.22 (compiled against version 0.4.22)
using GLib version 2.64.1 (compiled against version 2.64.0)
using GdkPixbuf version 2.40.0 (compiled against version 2.40.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Violación de segmento

Stack trace:
```

# Stack traces obtained from PID 17161 - Thread 17161 #

[New LWP 17162]
[New LWP 17163]
[New LWP 17164]
[New LWP 17165]
[New LWP 17166]
[New LWP 17167]
[New LWP 17168]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffe6551d450, fd=16) at 
../sysdeps/unix/sysv/linux/read.c:26

  Id   Target Id Frame
* 1    Thread 0x7f53f5be3e80 (LWP 17161) "gimp"  __libc_read 
(nbytes=256, buf=0x7ffe6551d450, fd=16) at 
../sysdeps/unix/sysv/linux/read.c:26
  2    Thread 0x7f53f5643700 (LWP 17162) "worker"    syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3    Thread 0x7f53f4e42700 (LWP 17163) "worker"    syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4    Thread 0x7f53e700 (LWP 17164) "worker"    syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5    Thread 0x7f53ee673700 (LWP 17165) "gmain" 0x7f53f77dfb0f in 
__GI___poll (fds=0x560c07512a20, nfds=1, timeout=4482) at 
../sysdeps/unix/sysv/linux/poll.c:29
  6    Thread 0x7f53ede72700 (LWP 17166) "gdbus" 0x7f53f77dfb0f in 
__GI___poll (fds=0x560c0751eac0, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  7    Thread 0x7f53d3fff700 (LWP 17167) "async" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8    Thread 0x7f53d37fe700 (LWP 17168) "pool-gimp" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38


Thread 8 (Thread 0x7f53d37fe700 (LWP 17168)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f53f7ab9ae2 in g_cond_wait_until 
(cond=cond@entry=0x560c074e9128, mutex=mutex@entry=0x560c074e9120, 
end_time=end_time@entry=25537426028) at ../../../glib/gthread-posix.c:1588

    now = {tv_sec = 25522, tv_nsec = 426028438}
    span = {tv_sec = 14, tv_nsec = 99562}
    sampled = 0
    res = 
    success = 
#2  0x7f53f7a3e5d1 in g_async_queue_pop_intern_unlocked 
(queue=queue@entry=0x560c074e9120, wait=wait@entry=1, 
end_time=end_time@entry=25537426028) at ../../../glib/gasyncqueue.c:422

    retval = 
    __func__ = "g_async_queue_pop_intern_unlocked"
#3  0x7f53f7a3ebc2 in g_async_queue_timeout_pop 
(queue=0x560c074e9120, timeout=timeout@entry=1500) at 
../../../glib/gasyncqueue.c:545

    end_time = 25537426028
    retval = 
    __func__ = "g_async_queue_timeout_pop"
#4  0x7f53f7a96e19 in g_thread_pool_wait_for_new_pool () at 
../../../glib/gthreadpool.c:183

    pool = 
    local_max_idle_time = 15000
    local_wakeup_thread_serial = 
    last_wakeup_thread_serial = 0
    have_relayed_thread_marker = 
    free_pool = 

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

[Michael Biebl]

Control: forcemerge 929116 -1


Looks like a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929116 so merging
accordingly.



signature.asc
Description: OpenPGP digital signature

Bug#954057: Script showing insecure default

[Felix Lechner]

Hi,

Here is a script showing the insecure default when using HTTP::Thin.

Kind regards
Felix Lechner

* * *

#!/usr/bin/perl

use 5.12.1;
use HTTP::Request::Common;
use HTTP::Thin;

say HTTP::Thin->new()->request(GET
'https://self-signed.badssl.com/')->as_string;

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

[John David Anglin]

On 2020-03-15 8:16 p.m., John Paul Adrian Glaubitz wrote:
> Source: sbcl
> Severity: normal
> Tags: patch
>
> Hi!
>
> In order to provide some basic level of continuous integration for
> sbcl upstream, it would be great if the sbcl package could be tried
> to build on any of the currently unsupported architectures using
> clisp.
>
With patch, I get following error:

make[2]: Leaving directory '/home/dave/debian/sbcl/sbcl-2.0.2/doc/internals'
//entering make-config.sh
//ensuring the existence of output/ directory
//guessing default target CPU architecture from host architecture
//setting up CPU-architecture-dependent information
sbcl_arch=""
can't guess target SBCL architecture, please specify --arch=
make[1]: *** [debian/rules:29: override_dh_auto_build] Error 1

Dave

-- 
John David Anglin  dave.ang...@bell.net

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

[gregor herrmann]

On Mon, 16 Mar 2020 08:28:07 -0700, Felix Lechner wrote:

> Package: libplack-perl
> Severity: important

(Taking a random instance of the identical mass bug filing.)
 
> Your package uses the Perl module HTTP::Tiny, but it does not force
> the verify_SSL attribute to a true value.

Thanks for raising this issue.

I'm wondering about 2 questions:
- 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.)
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

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#954096: sane: Scanning utilities work only once, or not at all, leave scanning backend in inconsistent state.

[Eduardo Casais]

Package: libsane
Version: 1.0.27-3.2
Severity: important
File: sane

Dear Maintainer,

I have been using an old scanner of type CanoScan N1240U/LiDE 30 without
problems
since Debian 7, connected to a port replicator or directly to a USB port, on a
variety of computers (both 32 and 64 bits).

Since Debian 10, scanning functions have ceased to work properly, but this
seems
to affect only the 64b environment.

1. Context A
Thinkpad L570, fresh installation of Debian 10.3 64b, GNOME, Xorg.
CanoScan LiDE 30.
Xsane 0.999.
SimpleScan 3.30.1.1.


2. Initialization difficulties

a)  Neither SimpleScan nor XSane detect the scanner automatically, despite
the
fact that the command lsusb recognizes and lists it.

b)  Solution : execute first sane-find-scanner, which returns appropriately

found USB scanner (vendor=0x04a9 [Canon], product=0x220e [CanoScan]) at
libusb:001:019

(or equivalent, depending on which port the scanner is attached to).

And then execute scanimage -L, which returns appropriately

Created directory: /var/lib/snmp/mib_indexes
device `plustek:libusb:001:019' is a Canon CanoScan N1240U/LiDE30
flatbed scanner

c)  Whereupon both SimpleScan and Xsane detect the scanner. However, they
still do
not function correctly.


3. SimpleScan can only scan once.

a)  Start SimpleScan and scan a document page. Everything works perfectly.

b)  Either "delete" the page or select "start again", and then "scan";
SimpleScan
enters the scanning loop but
b.i) does not drive the scanner (there is no movement of the scanning
head);
b.ii) it just displays an entirely black preview.

From then on, the only way to scan another page is to exit SimpleScan,
and
re-launch the program. It is impossible to scan a succession of pages
within
a single SimpleScan session.


4. SimpleScan gets into an inconsistent state.

a)  After a while, even that procedure fails. When requested to scan,
SimpleScan
enters the state "contacting scanner" -- which lasts for a minute or
so, then
outputs the error message "failed to scan/cannot start scan". In this
situation,
scanimage -L still lists the scanner.

b)  After a few attempts, SimpleScan quickly returns an error "failed to
scan/no
scanners available". In that situation, repeated invocations of sane-
find-scanner
and scanimage -L produce no result : scanimage -L no longer detects the
(still
attached) scanner, despite lsusb and sane-find-scanner having
identified it.
The only way to restart SimpleScan is to unplug the scanner, reconnect
it, and
redo the whole initialization procedure before invoking SimpleScan.


5. Xsane does not even scan once.

a)  Starting Xsane after an initializatin leads to a very lengthy phase (1
minute or
more) where Xsane remains "scanning for devices".
When scanning e.g. with "acquire preview" results in the following:
a.i) Xsane does not drive the scanner;
a.ii) it just displays an entirely black page.

b)  There is no way to make Xsane work, even for just one scan. Repeating
scans
always leads to a black page. Loading the CanoScan LiDE 30 device
parameters
in the "preferences" menu of Xsane produces the same result.

c)  Exiting and re-launching Xsane then results in a different behaviour:
upon
requesting a scan, Xsane immediately returns an error message
"Failed to start scanner: error during device I-O".
Checking immediately with scanimage -L shows that the scanner is no
longer
detected. Re-executing sane-find-scanner and then scanimage -L does not
help
as long as the scanner has not been unplugged and replugged.


Context B.
Dell I9100, fresh installation of Debian 10.3 32b, XFCE.
CanoScan LiDE 30.
Xsane 0.999.

6. Scanning works.

a)  Invoking Xsane directly, without the initialization with sane-find-
scanner
and scanimage -L, the program recognizes the scanner within seconds and
is
ready to work.

b)  Scanning works flawlessly. "Acquire preview" results in a proper
display of
the document being scanned.


Conclusion.

There seems to be a serious inconsisteny in the scanning environment of the 64b
Debian
implementation that results in a faulty and incoherent behaviour of various
scanning
front-ends. They cannot really scan, and after a while the device drivers /
backend is
left in a perturbated state where the connected scanner is detected by some
utilities
but not by others. The problems occur whether the scanner is connected directly
to a
USB port, or via a port replicator. The problems do not occur in a 32b Debian
system.



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

K

Bug#954097: ublock immediately turns off on chromium

[Olivier Cailloux]

Package: webext-ublock-origin
Version: 1.22.2+dfsg-1~deb10u1
Severity: important

On Debian stable, with current versions of chromium (80.0.3987.132-1~deb10u1)
and webext-ublock-origin (1.22.2+dfsg-1~deb10u1), ublock is not useable in
Chromium. Its icon (next to the address bar) indicates it is turned off (as
indicated by the tooltip and the grey icon). Reloading it (in the
chrome://extensions/ pane) briefly switches it to on (the icon turns red), only
to come back to off about two seconds later.

The console (visible through the background.html file that I can access when
turning Developer mode on in the extensions pane) indicates: “Failed to load
resource: net::ERR_FILE_NOT_FOUND” about chrome-
extension://oaiejdmjbagonijfeleeodihcicadkpm/lib/publicsuffixlist/wasm/publicsuffixlist.wasm,
and indeed this file does not exist: the debian package provides
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net/lib/publicsuffixlist/wasm/publicsuffixlist.wat
instead. But I don’t think this is related: adding a symbolic link from
publicsuffixlist.wasm to publicsuffixlist.wat in that folder and reloading
ublock makes this error disappear in the console, but the behavior persists:
ublock turns off.

Ublock works like a charm under my firefox-esr (68.6.0esr-1~deb10u1) package.



-- 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/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  chromium 80.0.3987.132-1~deb10u1
ii  firefox-esr  68.6.0esr-1~deb10u1

Versions of packages webext-ublock-origin suggests:
pn  ublock-origin-doc  

-- no debconf information

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

[Damyan Ivanov]

-=| Felix Lechner, 16.03.2020 09:56:36 -0700 |=-
> > - 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).

That was my first thought too.

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

Failing tests are bad, meaning they need (trivial) work to be fixed. 
Not being secure by default is worse, IMO.

I guess it finally depends on the amount of patching needed. Any idea 
how many packages are we talking about? Any takers for an archive 
rebuild with patched perl/libhttp-tiny-perl?

-- dam

Bug#954098: RFP: flat-manager -- Manager for flatpak repositories

[Corentin Noël]

Package: wnpp
Severity: wishlist

* Package name: flat-manager
  Version : 0.3.7
  Upstream Author : Alexander Larsson 
* URL : https://github.com/flatpak/flat-manager
* License : MIT/X
  Programming Lang: Rust
  Description : Manager for flatpak repositories

Serves and maintains a Flatpak repository. You point it at an ostree repository
and it will allow Flatpak clients to install apps from the repository over
HTTP. Additionally, it has an HTTP API that lets you upload new builds and
manage the repository.

This package is useful as it is the best way to maintain a Flatpak repository.

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

[Josh Triplett]

On Mon, 16 Mar 2020 07:14:41 -0700 Felix Lechner  
wrote:
> 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?

There's a long discussion and rationale in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484841 , and an even
longer discussion leading to a policy change in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299007 .

Short version: the "staff" group is root-equivalent. See
https://www.debian.org/doc/debian-policy/ch-opersys.html#site-specific-programs
, which says:
> If /etc/staff-group-for-usr-local does not exist, /usr/local and all
> subdirectories created by packages should have permissions 0755 and be
> owned by root:root. If /etc/staff-group-for-usr-local exists,
> /usr/local and subdirectories should have permissions 2775
> (group-writable and set-group-id) and be owned by root:staff.

On Mon, 16 Mar 2020 07:14:41 -0700 Felix Lechner  
wrote:
> Isn't it a common paradigm for daemons?

Not sure what you mean by this.

Bug#954099: Build-Depends needs mesa 0.51.2

[Martin Michlmayr]

Package: wlroots
Version: 0.10.0-3

Building wlroots on Debian stable I get:

> meson.build:1:0: ERROR:  Meson version is 0.49.2 but project requires 
> >=0.51.2.

But:

Build-Depends:
...
 meson (>= 0.43.0),

-- 
Martin Michlmayr
https://www.cyrius.com/

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#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#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#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   
>   A4.B

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#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#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) \
-	BERKELEYDB_INCDIR=/usr/include

Bug#952692: xcffib test timeout on s390x.

[Ivo De Decker]

Control: found -1 0.8.1-0.6
Control: tags -1 ftbfs
Control: retitle -1 xcffib: tests sometimes timeout on s390x

Hi,

On Thu, Feb 27, 2020 at 04:31:38PM +, peter green wrote:
> The last two uploads of xcffib (-0.7 and -0.8) both failed to build on s390x
> because of a testsuite timeout. This is preventing the fix for the broken
> build-depends from migrating to testing.
> 
> 
> test.test_connection.TestConnection.test_KillClient ...
> E: Build killed with signal TERM after 150 minutes of inactivity

A new try succeeded. It seems something in the testsuite is flaky, and it
doesn't seem to be specific to this version. Adjusting to version info to
allow this version to migrate.

Ivo

Bug#883867: bookworm for accessibility

[Paul Gevers]

Hi hjenkins,

On 16-03-2020 19:53, hjenkins wrote:
> Packaging the Bookworm e-reader could significantly improve the
> accessibility of Debian. Bookworm is written by blind developers,
> according to its website.

Thanks for letting us know about this piece of software. Are you aware
of ebook-speaker, already packaged in Debian. Also that has been written
by a blind developer.

That said, for this bug: if anybody is interested to do the initial
work, I think the accessibility team welcomes the package under the team
umbrella.

Paul



signature.asc
Description: OpenPGP digital signature

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

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

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

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

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


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄