Bug#956500: ITP: node-bash -- Utilities for using bash from node.js.

[Xavier]

Le 12/04/2020 à 06:06, fancycade a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Harley Swick  >
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> 
> * Package name    : node-bash
>   Version : 0.0.1
>   Upstream Author : Felix Geisendörfer  > (http://debuggable.com/)
> * URL : https://github.com/felixge/node-bash
> * License : MIT
>   Programming Lang: JavaScript
>   Description : Utilities for using bash from node.js.
> 
> This package is meant to be used by node applications
> for CLI tools or servers.
> 
> This is a dependency for shiny-server which is needed by Debian Science.
> 
> I plan to maintain this as part of the Javascript Maintainers team.

Hi,

I don't see you as member of JS Team, are you ?

Bug#956502: docker: Error response from daemon: no status provided on response: unknown.

[John Wong]

Package: docker.io
Version: 19.03.6+dfsg1-3
Severity: important

Dear Maintainer,
 After upgrade docker.io to 19.03.6+dfsg1-3 today, container cannot
 start, and show the error message like below:
 docker: Error response from daemon: no status provided on response: 
unknown.

 Downgrade to 19.03.6+dfsg1-2 solved the issue.
 Thanks.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP
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)
LSM: AppArmor: enabled

Versions of packages docker.io depends on:
ii  adduser 3.118
pn  iptables
ii  libc6   2.30-4
ii  libdevmapper1.02.1  2:1.02.167-1+b1
ii  libltdl72.4.6-14
ii  libnspr42:4.25-1
ii  libnss3 2:3.51-1
ii  libseccomp2 2.4.3-1
ii  libsystemd0 245.4-3
ii  lsb-base11.1.0
pn  runc
pn  tini

Versions of packages docker.io recommends:
ii  ca-certificates  20190110
pn  cgroupfs-mount   
pn  git  
pn  needrestart  
ii  xz-utils 5.2.4-1+b1

Versions of packages docker.io suggests:
pn  aufs-tools   
ii  btrfs-progs  5.6-1
pn  debootstrap  
pn  docker-doc   
ii  e2fsprogs1.45.6-1
pn  rinse
pn  xfsprogs 
pn  zfs-fuse | zfsutils  

Bug#855374: Patch for replaygain plugin

[Bruno Kleinert]

Hi,

I couldn't reproduce the replaygain plugin to fail for quite some time.
In the upstream bug tracker it was found be to unreproducible and got
closed. Therefore, I will close this bug, too.

Cheers,
Bruno


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

Bug#956455: RFS: smart-tools [ITP]

[Andreas Tille]

On Sat, Apr 11, 2020 at 10:02:18PM +0200, Andreas Tille wrote:
> Hi,
> 
> just a short notice.  Somehow the pristine-tar branch is broken.
> The original tarball can not be extracted by `gbp buildpackage`.
> I tried to fix this bit the watch file is not properly crafted.
> If I try
> 
> uscan --verbose --force-download
> 
> I get
> 
> uscan warn: In debian/watch no matching files for watch line

I've fixed the watch file (please compare with Debian Med
package_template in case of trouble) and re-downloaded the source
tarball to include it into pristine-tar branch.  It was just wrongly
named.  For your next package I would recommend to *first* create
the watch file and download your target tarball with uscan.  Than
you can be really sure that it will work. ;-)
 
> May be somebody else can help - but I need some rest now and may
> be the next two days.  Since we have lots of new contributors I
> guess you can get some help here.  Sorry for leaving you alone
> for some time with this issue and thanks for your contribution
> anyway

I just took the needed time and uploaded to new.  Please add it
to

  
https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/NEW-Requests

to make sure ftpmaster will realise it in connection with the
sprint.

Thanks a lot for your work

 Andreas.

>Andreas.
> 
> On Sun, Apr 12, 2020 at 12:51:06AM +0900, Sao I Kuan wrote:
> > Hi,
> > 
> > I'm looking for a sponsor for the package:
> >   * smart-open (#956455)
> > 
> > The packages are on:
> > https://salsa.debian.org/med-team/smart-open
> > 
> > The package is dependency of idseq-bench[1,2].
> > 
> > [1] https://github.com/chanzuckerberg/idseq-bench
> > [2] https://bugs.debian.org/956033
> > 
> > The package does have two issues:
> > * GCS: runtime dependencies are not packaged (google-cloud-storage
> > and its deps).
> > - I disabled the GCS related codes, and all the other tests
> > are works well.
> > - d/patches/exclude-gcs.patch
> > * S3: test dependencies not packaged (moto and its deps).
> > - I disabled the S3 related tests.
> > - d/patches/exclude-moto-s3-test.patch
> > 
> > Because of reverse dependency of this package (specially idseq-bench)
> > is only using the feature for local filesystems, GCS and S3 related
> > codes are unnecessary for now. So I disabled them. I mentioned this
> > issue in d/README.source.
> > 
> > I enabled all the tests not related with GCS and S3, are all passed
> > well. The package was tested on both gbp and sbuild, and
> > lintian-clean.
> > 
> > Please consider to review and sponsor this. Any kind of suggestions
> > are appreciated.
> > 
> > Thank you!
> > 
> > Sincerely,
> > 
> > Sao I Kuan
> > saoik...@gmail.com
> > 
> > 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#956500: ITP: node-bash -- Utilities for using bash from node.js.

[fancycade]

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

* Package name: node-bash
  Version : 0.0.1
  Upstream Author : Felix Geisendörfer  
(http://debuggable.com/)
* URL : https://github.com/felixge/node-bash
* License : MIT
  Programming Lang: JavaScript
  Description : Utilities for using bash from node.js.

This package is meant to be used by node applications
for CLI tools or servers.

This is a dependency for shiny-server which is needed by Debian Science.

I plan to maintain this as part of the Javascript Maintainers team.

Bug#956501: console-setup: keyboard layout in /etc/default/keyboard is not set correctly on startup

[Celejar]

Package: console-setup
Version: 1.195
Severity: normal

Hi,

I'm not sure if this is a problem with console-setup or
keyboard-configuration.

~$ cat /etc/default/keyboard 
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="us,il"
XKBVARIANT="dvorak,"
XKBOPTIONS="terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps"

BACKSPACE="guess"

Until recently, these settings were all correctly set on system startup,
but the keyboard layout settings are currently not set correctly on
startup:

~$ setxkbmap -query
rules:  evdev
model:  pc105
layout: us
variant:dvorak
options:terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps

As per 'man 5 keyboard', this can be corrected by directing the system
to (re)read /etc/default/keyboard:

~# udevadm trigger --subsystem-match=input --action=change

~$ setxkbmap -query
rules:  evdev
model:  pc105
layout: us,il
variant:dvorak,
options:terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps

But why is this not happening correctly on startup, requiring manual
intervention?

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 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 console-setup depends on:
ii  console-setup-linux 1.195
ii  debconf 1.5.73
ii  keyboard-configuration  1.195
ii  xkb-data2.29-2

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.30-4
ii  lsb-base  11.1.0

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.73
ii  liblocale-gettext-perl  1.07-4

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.57
ii  initscripts 2.96-3
ii  kbd 2.0.4-4
ii  keyboard-configuration  1.195

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.4-4
ii  systemd   245.4-3

-- debconf information:
* keyboard-configuration/toggle: Alt+Shift
  debian-installer/console-setup-udeb/title:
  console-setup/fontsize-text47: 8x16
  console-setup/use_system_font:
* keyboard-configuration/layout:
  console-setup/fontsize-fb47: 8x16
  console-setup/framebuffer_only:
  keyboard-configuration/unsupported_config_options: true
* keyboard-configuration/compose: No compose key
* keyboard-configuration/layoutcode: us,il
* keyboard-configuration/switch: No temporary switch
  keyboard-configuration/unsupported_options: true
* keyboard-configuration/model: Generic 105-key PC (intl.)
* keyboard-configuration/variant: English (US) - English (Dvorak)
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/xkb-keymap: us
  console-setup/fontsize: 8x16
  console-setup/store_defaults_in_debconf_db: true
  console-setup/fontface47: Fixed
* keyboard-configuration/optionscode: 
terminate:ctrl_alt_bksp,grp:alt_shift_toggle,ctrl:swapcaps
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/modelcode: pc105
  console-setup/guess_font:
  keyboard-configuration/unsupported_layout: true
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
* keyboard-configuration/other:
  keyboard-configuration/ctrl_alt_bksp: true
  console-setup/codesetcode: Lat15
  console-setup/charmap47: UTF-8
* keyboard-configuration/altgr: The default for the keyboard layout
* keyboard-configuration/variantcode: dvorak,

Bug#859624: [pitivi] Freezes when attempting to load saved projects

[Bruno Kleinert]

Hi,

I can no longer reproduce this bug and therefore will close it.
Unfortunately, I can't tell the version that resolved it.

Cheers,
Bruno


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

Bug#956499: MESA-LOADER: failed to open i915

[積丹尼 Dan Jacobson]

Package: chromium
Version: 81.0.4044.92-1

I'm now seeing

MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to open i915 (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri) failed to load 
driver: i915
MESA-LOADER: failed to open kms_swrast (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri) failed to load 
driver: kms_swrast
MESA-LOADER: failed to open swrast (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri) failed to load 
swrast driver

every time I start chromium. Thankfully it still starts.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  chromium-common81.0.4044.92-1
ii  libasound2 1.2.2-2.1
ii  libatk-bridge2.0-0 2.34.1-3
ii  libatk1.0-02.36.0-2
ii  libatspi2.0-0  2.36.0-2
ii  libavcodec58   7:4.2.2-1+b1
ii  libavformat58  7:4.2.2-1+b1
ii  libavutil567:4.2.2-1+b1
ii  libc6  2.30-4
ii  libcairo2  1.16.0-4
ii  libcups2   2.3.1-11
ii  libdbus-1-31.12.16-2
ii  libdrm22.4.101-1
ii  libevent-2.1-7 2.1.11-stable-1
ii  libexpat1  2.2.9-1
ii  libflac8   1.3.3-1
ii  libfontconfig1 2.13.1-3
ii  libfreetype6   2.10.1-2
ii  libgbm120.0.4-1
ii  libgcc-s1 [libgcc-s1]  10-20200402-1
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-4
ii  libglib2.0-0   2.64.1-1
ii  libgtk-3-0 3.24.18-1
ii  libharfbuzz0b  2.6.4-1
ii  libicu63   63.2-3
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libjsoncpp11.7.4-3.1
ii  liblcms2-2 2.9-4+b1
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.25-1
ii  libnss32:3.51-1
ii  libopenjp2-7   2.3.1-1
ii  libopus0   1.3-1+b1
ii  libpango-1.0-0 1.44.7-3
ii  libpangocairo-1.0-01.44.7-3
ii  libpng16-161.6.37-2
ii  libpulse0  13.0-5
ii  libre2-6   20200401+dfsg-1
ii  libsnappy1v5   1.1.8-1
ii  libstdc++6 10-20200402-1
ii  libvpx61.8.2-1
ii  libwebp6   0.6.1-2+b1
ii  libwebpdemux2  0.6.1-2+b1
ii  libwebpmux30.6.1-2+b1
ii  libx11-6   2:1.6.9-2
ii  libx11-xcb12:1.6.9-2
ii  libxcb-dri3-0  1.14-2
ii  libxcb11.14-2
ii  libxcomposite1 1:0.4.4-2
ii  libxcursor11:1.2.0-2
ii  libxdamage11:1.1.5-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxi6 2:1.7.9-1
ii  libxml22.9.10+dfsg-5
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxslt1.1 1.1.34-4
ii  libxss11:1.2.3-1
ii  libxtst6   2:1.2.3-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  81.0.4044.92-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
ii  chromium-shell   81.0.4044.92-1

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+5
ii  xdg-utils  1.1.3-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox   81.0.4044.92-1
ii  fonts-liberation   1:1.07.4-11
ii  libgl1-mesa-dri20.0.4-1
pn  libu2f-udev
ii  notification-daemon3.20.0-4
pn  system-config-printer  
pn  upower 

Versions of packages chromium-sandbox depends on:
ii  libc6  2.30-4

-- no debconf information

Bug#956498: /usr/bin/dget: [dget] Please support downloading packages over scp:// and sftp://

[Bilal, Muhammad]

Package: devscripts
Version: 2.19.5+deb10u1
Severity: wishlist
File: /usr/bin/dget

Dear Maintainer,

Dear Maintainer,

Please find attached patch that adds supports for downloading packages over the 
'scp' and 'sftp' protocols.
Patch has been tested on both protocols by downloading Debian package


'curl' installation on Debian 10 Linux comes with 'scp' and 'sftp' proptocols 
enabled by default.

Below is installed curl information:
$ curl -V
curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 
libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 li\
brtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL 
libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL


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

Kernel: Linux 5.3.0-46-generic (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



Thanks,

Muhammad Bilal
Mentor, A Siemens Business
muhammad_bi...@mentor.com
www.mentor.comdiff --git a/scripts/dget.pl b/scripts/dget.pl
index 06b98bf6..b876e909 100755
--- a/scripts/dget.pl
+++ b/scripts/dget.pl
@@ -481,7 +481,7 @@ for my $arg (@ARGV) {
 
 # case 1: URL
 if ($arg
-=~ /^((?:copy|file|ftp|gopher|http|rsh|rsync|ssh|www).*)\/([^\/]+\.\w+)$/
+=~ /^((?:copy|file|ftp|gopher|http|rsh|rsync|scp|sftp|ssh|www).*)\/([^\/]+\.\w+)$/
 ) {
 get_file($1, $2, "unlink") or exit 1;
 if ($found_dsc) {

Bug#956189: Upgrade to 2.1.0

[Jörn Heissler]

Hello,

the issue was fixed in release 2.1.0

Cheers


signature.asc
Description: PGP signature

Bug#956497: ristretto: 25 seconds delay when starting under openbox

[Daniel Shahaf]

Package: ristretto
Version: 0.8.3-1
Severity: important

Dear Maintainer,

When I run «ristretto» under Openbox, there is a 25s delay before the
window opens.  That doesn't happen under XFCE.

- I tried to run ristretto with and without command-line arguments.
  That did not affect the outcome.  At the time, the current working
  directory contained one *.png file (sized 1.2MB) and nothing else.

- I timed the delay with a wallclock.  It was approximately 25 seconds.

- I ran «strace ristretto» (without any other arguments).  A delay
  occurs at this point:

  openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 10
  fstat(10, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
  fstat(10, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
  read(10, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"..., 
4096) = 127
  lseek(10, -71, SEEK_CUR)= 56
  read(10, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"..., 
4096) = 71
  close(10)   = 0
  brk(0x55fccb38d000) = 0x55fccb38d000
  brk(0x55fccb38c000) = 0x55fccb38c000
  write(8, "\1\0\0\0\0\0\0\0", 8) = 8
  futex(0x55fccb313320, FUTEX_WAKE_PRIVATE, 1) = 1
  futex(0x55fccb3130b0, FUTEX_WAKE_PRIVATE, 1) = 1
  futex(0x55fccb30a048, FUTEX_WAKE_PRIVATE, 1) = 1
  write(8, "\1\0\0\0\0\0\0\0", 8) = 8
  futex(0x55fccb3130b0, FUTEX_WAKE_PRIVATE, 1) = 1
  write(8, "\1\0\0\0\0\0\0\0", 8) = 8
  futex(0x55fccb30a048, FUTEX_WAKE_PRIVATE, 1) = 1
  eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 10
  write(10, "\1\0\0\0\0\0\0\0", 8)= 8
  write(8, "\1\0\0\0\0\0\0\0", 8) = 8
  futex(0x55fccb313320, FUTEX_WAKE_PRIVATE, 1) = 1
  futex(0x55fccb3130b0, FUTEX_WAKE_PRIVATE, 1) = 1
  futex(0x55fccb30a048, FUTEX_WAKE_PRIVATE, 1) = 1
  poll([{fd=10, events=POLLIN}], 1, 25000) = 1 ([{fd=10, revents=POLLIN}])
  read(10, "\1\0\0\0\0\0\0\0", 16)= 8
  poll([{fd=10, events=POLLIN}], 1, 25000^Cstrace: Process 4556 detached
   

  I captured a backtrace (from a different ristretto run, because lldb
  failed to attached to the strace'd run):

  * thread #1, name = 'ristretto', stop reason = signal SIGSTOP
* frame #0: 0x76ba0819 
libc.so.6`__GI___poll(fds=0x55648720, nfds=1, timeout=25000) at 
poll.c:29   
 
  frame #1: 0x7762b136 
libglib-2.0.so.0`___lldb_unnamed_symbol193$$libglib-2.0.so.0 + 374
  frame #2: 0x7762b4c2 libglib-2.0.so.0`g_main_loop_run + 178
  frame #3: 0x778a1b53 
libgio-2.0.so.0`___lldb_unnamed_symbol2705$$libgio-2.0.so.0 + 243
  frame #4: 0x778118c2 libgio-2.0.so.0`g_initable_new_valist + 146
  frame #5: 0x77811979 libgio-2.0.so.0`g_initable_new + 153
  frame #6: 0x778a34fc 
libgio-2.0.so.0`g_dbus_proxy_new_for_bus_sync + 236
  frame #7: 0x55575ef5 
ristretto`rstto_main_window_init(window=0x555d9260) at 
main_window.c:809   
  
  frame #8: 0x77730107 libgobject-2.0.so.0`g_type_create_instance + 
775
  frame #9: 0x77712548 
libgobject-2.0.so.0`___lldb_unnamed_symbol123$$libgobject-2.0.so.0 + 744
  frame #10: 0x77713cc5 
libgobject-2.0.so.0`g_object_new_with_properties + 757
  frame #11: 0x77714731 libgobject-2.0.so.0`g_object_new + 193
  frame #12: 0x55578f5a 
ristretto`rstto_main_window_new(image_list=0x555a95a0, fullscreen=0) at 
main_window.c:1263  

  frame #13: 0x55566c74 ristretto`main(argc=, 
argv=) at main.c:134
  frame #14: 0x76ad609b 
libc.so.6`__libc_start_main(main=(ristretto`main at main.c:86), argc=1, 
argv=0x7fffe6e8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6d8) at libc-start.c:308
  frame #15: 0x55566e0a ristretto`_start + 42

- The delay occurs when I run ristretto under Openbox (using «startx
  openbox» after logging in on a Ctrl+Alt+F tty, without a login
  manager), but does not occur when I run ristretto under XFCE.

- This used to work fine.  I don't remember when it last worked, but
  that may well have been on stretch.  (I'm currently on buster.)

- I have not tested 0.10.0-1, since I do not have a testing or sid
  headful VM.  However, I did check the bug trackers and changelogs,
  both Debian's and upstream's, and found no relevant matches.

It would seem that the last poll(2) call times out while reading from
the eventfd2() fd.

I would be grateful for a workaround for getting rid of the delay.

Cheers,

Daniel


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: 

Bug#956494: RFS: golang-github-bndr-gotabulate

[Taowa Munene-Tardif]

Hello Go team,

Firstly,
On Sat, Apr 11, 2020 at 06:37:36PM -0400, Taowa Munene-Tardif wrote:
> Hello Go team,
> 
> Despite being @debian.org[0], I am looking for a sponsor for
> golang-github-la5nta-wl2k-go. This package is required for `pat`, ITP
> #9564643.

I meant to say #877030, but managed to mistype #956463. I really ought
to sleep.

Anyway, same thing here. The package is on mentors and salsa.

Thanks,
Taowa

-- 
Taowa Munene-Tardif
taowa.ca
Montréal

Bug#826675: rapid-photo-downloader: Wrong sort order

[anarcat]

Control: tag -1 moreinfo

On Tue, Jun 07, 2016 at 09:40:07PM +0200, Christian von Kietzell wrote:
> Package: rapid-photo-downloader
> Version: 0.4.11-1
> Severity: normal
> 
> Dear Maintainer,
> 
> rpd sorts the files to import incorrectly, resulting in file numbering that
> isn't chronological (with respect to the files to import). Its internally used
> modification time, which files are sorted by, is only accurate to full
> seconds. I checked this by printing the filename and modification time in
> scan.py.
> "touch"-ing all files in (filename) order and sleeping at least one second in
> between calls makes rpd sort them correctly.
> 
> Usually, this isn't really a problem when photos are downloaded from a memory
> card directly. If you bulk-copy them to a different directory first, it's
> easily triggered, though. On the other hand I can see how the same behaviour
> might come about with cameras with high framerates and photos shot in burst
> mode.

Hi!

This bug report is pretty old, could you try again with the latest
release in testing? A lot of changes went in RPD since then, and I
wonder if this is still a problem.

Otherwise, I would also argue that if you copy files before RPD
processes them, you're kind of doing it wrong. :) RPD is the thing
that's designed to copy them...

a.


signature.asc
Description: PGP signature

Bug#956496: ITP: ksnip -- Qt-based cross-platform screenshot tool

[Boyuan Yang]

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

* Package name: ksnip
  Version : 1.6.1
  Upstream Author : Damir Porobic 
* URL : https://github.com/ksnip/ksnip
* License : GPL-2+
  Programming Lang: C++/Qt
  Description : Qt-based cross-platform screenshot tool

 Ksnip is a Qt-based cross-platform screenshot tool that provides many
 annotation features for your screenshots. It provides a traditional
 user interface with experimental GNOME/KDE Wayland support.


I plan to maintain this package myself and the packaging repo is placed under
the Debian group. Co-maintainers are welcome.

It depends on two separate libraries (kcolorpicker and kimageannotator). The
former one is now in Sid while the latter one is being reviewed in the NEW
queue.

-- 
Regards,
Boyuan Yang


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

Bug#956495: htpdate install fails without directory /opt

[Joachim Trinkwitz]

Package: htpdate
Version: 1.2.0-3
Severity: important

Installation of htpdate fails on systems without directory /opt, because
of the directive 'InaccessibleDirectories=/boot /home /media /mnt /root
/opt /srv' in the systemd service file. The post-installation script
fails with the messages
htpdate.service: Failed to set up mount namespacing: No such file or directory
htpdate.service: Failed at step NAMESPACE spawning /usr/sbin/htpdate: No such 
file or directory

Obviously, a workaround is to create the directory /opt.

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

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

Versions of packages htpdate depends on:
ii  libc6 2.28-10
ii  lsb-base  10.2019051400

htpdate recommends no packages.

htpdate suggests no packages.

-- no debconf information

Bug#955193: upstream patch merged

[Paul Wise]

On Sat, 2020-04-11 at 16:47 -0700, Jordan Justen wrote:

> Since it's a warning, I was planning to *not* bother adding an `alot`
> package patch, and just wait for the next upstream release. Or, do
> you think I should cherry-pick the upstream patch into the package?

Looking at the CPython release notes, these constructs work in CPython
but not necessarily in other Python implementations. Since the Debian
alot package depends on CPython, the issue is a minor at best so I
would suggest to just wait for the next alot release.

https://docs.python.org/3/whatsnew/3.8.html#changes-in-python-behavior
https://bugs.python.org/issue34850

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#956494: ITP: golang-github-bndr-gotabulate -- Gotabulate - Easily pretty-print your tabular data with Go

[Taowa Munene-Tardif]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Taowa Munene-Tardif 

* Package name: golang-github-bndr-gotabulate
  Version : 1.1.2-1
  Upstream Author : Vadim Kravcenko
* URL : https://github.com/bndr/gotabulate
* License : Apache-2.0
  Programming Lang: Go
  Description : Gotabulate - Easily pretty-print your tabular data with Go

 Summary Go-Tabulate - Generic Go Library for easy pretty-printing of tabular 
data.

Needed for packaging pat (#877030).

-- 
Taowa Munene-Tardif
taowa.ca
Montréal

Bug#956493: emacs-common: Please remove the DocBook RNC schema as it breaks validation

[Vincent Lefevre]

Package: emacs-common
Version: 1:26.3+1-1
Severity: normal

[This was initially bug 871485 against emacs25-common, which has been
removed from Debian. I'm re-reporting this bug against emacs-common.]

emacs-common contains the DocBook 4.2 schema, which is old. There
are newer 4.x schemas, and now even 5.x, which is largely incompatible
with 4.x. Updating the schema wouldn't be sufficient as several
schemas need to coexist. Such schemas should normally be provided by
separate packages (e.g. docbook-xml for 4.x and docbook5-xml for 5.x).
Only correct location rules need to be added, but this may need
cooperation from the docbook*-xml packages.

Note: This bug is similar to

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335052

against emacs24-common (initially filed in 2005!!!). The issue is much
more important now that DocBook 5 is available.

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

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

Versions of packages emacs-common depends on:
ii  emacsen-common  3.0.4
ii  install-info6.7.0.dfsg.2-5

Versions of packages emacs-common recommends:
ii  emacs-el  1:26.3+1-1

Versions of packages emacs-common suggests:
ii  emacs-common-non-dfsg  1:26.3+1-1
ii  ncurses-term   6.2-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#955193: upstream patch merged

[Jordan Justen]

I got this fixed in upstream:

https://github.com/pazz/alot/commit/916b446317980e9794a02bfb79456da4fc2768a4

Since it's a warning, I was planning to *not* bother adding an `alot`
package patch, and just wait for the next upstream release. Or, do you
think I should cherry-pick the upstream patch into the package?

-Jordan


signature.asc
Description: signature

Bug#956492: ifupdown: hardcodes path to run-parts

[Clint Adams]

Package: ifupdown
Version: 0.8.35

Hello,

I plan to move all binaries in debianutils to /usr .  ifupdown hardcodes
/bin/run-parts .  What is the best way to coordinate this change?

Bug#956207: opendmarc remain in foreground, ie fails to daemonize

[James Cloos]

> "DB" == David Bürgin  writes:

DB> Daemonization is controlled with the ‘-f’ command-line option or the
DB> ‘Background’ parameter in the configuration file. Nothing has changed in
DB> this area since the last version, so not sure what the problem is.

then either -f stoppped working or the init script got broken.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Sebastian Andrzej Siewior]

On 2018-03-11 21:51:05 [+0100], Balint Reczey wrote:
> For the recompressed firefox .deb (Ubuntu's
> firefox_58.0.2+build1-0ubuntu0.17.10.1_amd64.deb) increased ~9% in
> size but decompressed in <20% of the original time:

So you are saying that the decompression speed that is the bottleneck
here? I *assumed* that it is mostly the disk speed since I get around 60
to 80MiB/sec out of xz. 

> $ du -s firefox-*deb
> 43960 firefox-xz.deb
> 47924 firefox-zstd.deb

  48M linux-image-5.5.0-1-amd64_5.5.13-2_amd64.data.tar.xz
  54M linux-image-5.5.0-1-amd64_5.5.13-2_amd64.data.tar.19.zstd

 766M linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar.xz
 901M linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar.19.zstd

zstd -19 -T16
|linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar : Completed in 287.37 
sec  (cpu load : 1533%)
|
|real4m47,416s
|user73m23,825s
|sys 0m2,753s
|

xz -T16
| real4m15,447s
| user66m51,572s
| sys 0m3,201s


> $ rm -rf firefox-xz/* ;time  dpkg-deb -R firefox-xz.deb firefox-xz/
> real 0m4,270s
> user 0m4,220s
> sys 0m0,630s
> $ rm -rf firefox-zstd/* ;time  dpkg-deb -R firefox-zstd.deb firefox-zstd/
> real 0m0,765s
> user 0m0,556s
> sys 0m0,462s

So this looks impressive. Is dpkg-deb also performing sync() on the
output or is the report when the files hit the disk cache? Either way,
should be noticeable on ssd/nvme which write at higher performance.
 
> Tests on the full Ubuntu main archive showed ~6% average increase in
> the size of the binary packages.

I guess the vast majority of packages are small and hardly increase in
size. The bigger packages then increase more.

> The patches are also available on Salsa [2].

While I read the whole thread here, I did not find any consent other
than discuss it d-devel. Is this still the case?

> Cheers,
> Balint

Sebastian

Bug#956491: git-buildpackage: [PATCH] Add info about --git-ignore-branch when not on branch

[Jonathan Rubenstein]

Source: git-buildpackage
Severity: wishlist
Tags: patch

Dear Maintainer,

I noticed that checking out a tag wouldn't let me use gbp buildpackage.
I checked the manual and tried --git-ignore-branch, which allowed me to
build.

The error message comes from the get_branch function, and informs me
that I am not currently on a branch. I figure this could be more
informative, so it now outputs "Use --git-ignore-branch to ignore"
as well.

Should this provide even more info?

Thank you,
Jonathan

---
 gbp/scripts/buildpackage.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gbp/scripts/buildpackage.py b/gbp/scripts/buildpackage.py
index 9b3d67fa..7ce50628 100755
--- a/gbp/scripts/buildpackage.py
+++ b/gbp/scripts/buildpackage.py
@@ -326,10 +326,11 @@ def check_branch(repo, options):
 branch = None
 try:
 branch = repo.get_branch()
-except GitRepositoryError:
+except GitRepositoryError as repo_error:
 # Not being on any branch is o.k. with --git-ignore-branch
 if not options.ignore_branch:
-raise
+gbp.log.err(repo_error)
+raise GbpError("Use --git-ignore-branch to ignore")
  ignore = options.ignore_new or options.ignore_branch
 if branch != options.debian_branch and not ignore:
--
2.25.1

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

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

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

-- no debconf information

Bug#956490: ifupdown: ULA SLAAC addr first gets removed if status will be deprecated when changing to static ULA addr

[Alex Bert]

Package: ifupdown
Version: 0.8.35
Severity: important
Tags: ipv6

Dear Maintainer,

iI have a network where machines get ULA-SLAAC-addresses via router
advertisments (router is a pfsense).
If I want to set an address to a static address after the machine has
acquired an ULA-SLAAC (e. g. during installation), the SLAAC-address
reamains active. It also will be actively used by the system for
communication (e.g. ping, telnet etc.). If I remove the SLAAC-address
with ip addr del  it wil imediately gets re-added to the system and
be used for communication. The static ipv6 address is showing up with ip
addr and can be accessed from outside, but it ist not acitvely used for
outside communication.
I had to manually set the preferred lifetime with ip addr change ...
preferred_lifetime 5 and wait till the address gets deprecated. Then I
was able to remove it permanently.

I don't think this is the correct behaviour, as I have another network 
with valid public ipv6-Addresses which I get from my ISP (also pfsense
is the router). If a machine gets (public) SLAAC during the installation
and I configure the machine to use a static ULA address afterwards, the
(public) SLAAC-addresses immediately gets removed and the static ULA is
used for communication.
The configuration on both machines were the same. I set a static ipv6 in
/etc/network/interfaces with the option autoconf 0.

I expected the same behaviour in both situations.

-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens160
iface ens160 inet dhcp
# This is an autoconfigured IPv6 interface
iface ens160 inet6 static
address fdb3:27fb:4170:20::153
netmask 64
autoconf 0

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rwxr-xr-x 1 root root 256 Apr  1  2016 resolvconf

/etc/network/if-post-down.d:
total 0

/etc/network/if-pre-up.d:
total 0

/etc/network/if-up.d:
total 4
-rwxr-xr-x 1 root root 817 Apr  1  2016 000resolvconf


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

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  lsb-base  10.2019051400

Versions of packages ifupdown recommends:
ii  dhcpcd5 [dhcp-client]  7.1.0-2
ii  isc-dhcp-client [dhcp-client]  4.4.1-2

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- no debconf information

Bug#956463: RFS: golang-github-la5nta-wl2k-go -- winlink framework library for Go

[Taowa Munene-Tardif]

Hello Go team,

Despite being @debian.org[0], I am looking for a sponsor for
golang-github-la5nta-wl2k-go. This package is required for `pat`, ITP
#9564643.

You'll find my package both on salsa at [1] and mentors at [2].

Thanks!

Taowa Munene-Tardif

[0] but being a non-uploading DD and thus effectively a DM for the
purpose of uploading packages.
[1] https://salsa.debian.org/go-team/packages/golang-github-la5nta-wl2k-go
[2] https://mentors.debian.net/package/golang-github-la5nta-wl2k-go
-- 
Taowa Munene-Tardif
taowa.ca
Montréal

Bug#956379: mumble: DBus call to getCurrentUrl responds with empty string

[Chris Knadle]

Florian Snow:
> Hi Chris,
> 
> Let me say first that this is my first time filing a bug with Debian and
> I am not completely familiar with the process yet.  So if I made a
> mistake, please accept my apologies.

Being that this is your first bug report please let me extend my thanks for
taking the time and effort to do that.  It's an important and worthwhile thing
and it gives both users and Debian developers an opportunity to interact and
find opportunities to work together.

> Chris Knadle  writes:
>> I'd like to know what risks and/or problems this bug poses, in order to
>> understand how important this bug is and to figure out how it needs to be
>> handled.
> 
> The bug is not security related; it is just an inconvenience.  Usually,
> you can get the current URL via DBus and use that to script certain
> things.  For example, getting the current URL makes it possible to not
> only switch rooms on screen lock, but also to switch back to the
> previous room on unlock.  So nothing major, but something I noticed
> using the program and I wanted to help getting it fixed.  That's why I
> fixed it upstream and I figured the best way to proceed was to now file
> a bug with Debian.

Okay I think I understand.
Thank you for fixing this upstream -- that's especially good because it means
the fix will [most likely] be in the upcoming 1.3.1 tarball and will get to
Debian unstable when I can upload that.

>> Mumble-server / Murmur defaults to not using DBUS, and does not depend on it
>> either for the package in Debian in order to allow not having DBUS
>> installed.
> 
> True, but this is about the client.  The default configuration on Debian
> uses DBus here to interact with the client from the CLI.

Ahh.  Okay I didn't understand that this was about the client.  In Debian bugs
are organized by "source package", and both mumble-server (the server) and
mumble (the client) are bundled together in the source package named "mumble",
so it wasn't clear which is being referred to.  ;-)

>> Mumble currently only has an "oldstable" backport right now, and no "stable"
>> backport.  For a bugfix to a backport to be allowed, the bug is required to 
>> be
>> fixed in "testing" first, and the only way to get a package to "testing" is 
>> to
>> upload it to "unstable".
> 
> Ok, sure, thanks for letting me know.  That was just an idea because I
> realized that the bug severity was probably not high enough to warrant a
> fix in stable.  That's why I was thinking of stable-updates or
> backports, but again, I am not completely familiar with the internals of
> Debian.  I am willing to learn, though.  The reason I included
> information about the bug also being in testing and sid was because
> reportbug told me to verify if the bug existed there.

Okay.
When there are serious bugs in "stable", fixes targeting those specific bugs are
made and fixed packages are uploaded to the "stable-proposed-updates" repository
pending the next "point" release for "stable".  "stable-updates" is a repository
of packages with fixes pending to be included with the next point release and
made available to users if they choose to include that repository.  In other
words, "stable-updates" are packages that are "staged" for the "stable" 
repository.

References:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

https://wiki.debian.org/StableUpdates



This bug isn't serious enough to try to fix it in "stable".  (Even if I prepared
a package with the fix, the bug isn't serious enough for the release team to
accept the upload.)

This is still a bug for Sid/unstable, and it'll be fixed when I'm able to upload
the 1.3.1 bugfix release that upstream is actively working on.  I'm trying to
consider what to do about the backport package -- another Debian developer has
been doing that but it's been a while since it's been updated.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#938476: shedskin: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Mon, Sep 30, 2019 at 07:24:07PM +0200, Paul Boddie wrote:
> The principal developer has indicated to me that given the policy here, he 
> and 
> I will just have to accept that the package will be removed. However, I won't 
> be tagging or retitling anything. If someone else responsible for this 
> initiative wants to do so then they can press the appropriate buttons.

I just filed a removal bug.

Cheers,
Moritz

Bug#956489: RM: shedskin -- RoQA; Depends on Python 2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove shedskin. It depends on Python 2 (and it's not going to be
ported in the foreseeable future), see #938476.

Cheers,
Moritz

Bug#956488: RM: python-concurrent.futures -- ROM; python2-only; backport of a python3.2 module; no rdeps (except nipype which is already RC buggy)

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#956487: ITP: alcotest -- A lightweight and colourful test framework for OCaml

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 
Control: block 956485 by -1

* Package name: alcotest
  Version : 1.1.0
  Upstream Author : Thomas Gazagnaire 
* URL : https://github.com/mirage/alcotest
* License : ISC
  Programming Lang: OCaml
  Description : A lightweight and colourful test framework for OCaml

Alcotest exposes simple interface to perform unit tests. It
exposes a simple TESTABLE module type, a check function to
assert test predicates and a run function to perform a list
of unit -> unit test callbacks.

Alcotest provides a quiet and colorful output where only
faulty runs are fully displayed at the end of the run (with
the full logs ready to inspect), with a simple (yet
expressive) query language to select the tests to run.

It is a dependency of ocaml-unix-errno and will be maintained under the
OCaml team.

Bug#956486: support control files in root

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.60
Severity: wishlist

Some packages live in a repository with the control files at the root. Examples 
are libreoffice and bash.

lintian-brush currently doesn't handle these packages but should. One possible 
way of supporting these
packages is to construct a temporary directory with a symlink in it for debian/ 
back to the original repository.
This is sufficient to run the various fixers; actual commits would still work 
on the original repository, assuming
the temporary directory is otherwise untouched.


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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.2
ii  python3  3.8.2-3
ii  python3-breezy   3.0.2-5+b1
ii  python3-debian   0.1.36
ii  python3-distro-info  0.23
ii  python3-dulwich  0.19.15-1
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5
ii  python3-pkginfo  1.4.2-3
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.20-1
ii  libdebhelper-perl  12.10
ii  lintian2.65.0
ii  python3-asyncpg0.20.1-1+b1
ii  python3-pyinotify  0.9.6-1.3

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  214

-- no debconf information

Bug#954457: [Pkg-utopia-maintainers] Bug#954457: network-manager: Problems with long wireless names [aborting authentication by local choice (Reason: 3=DEAUTH_LEAVING)]

[Michael Biebl]

Control: reassign -1 wpasupplicant

On Sat, 21 Mar 2020 22:57:46 +0100 Michael Biebl  wrote:
> Am 21.03.20 um 22:44 schrieb Agustin Martin:
> > Package: network-manager
> > Version: 1.22.10-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I have tried to use a wifi dongle in my laptop. Networks were detected, but
> > connection fails with these messages in syslog
> > 
> > kernel: wlx0022b0e3c6b6: aborting authentication with
> > 70:5a:9e:3a:30:18 by local choice (Reason: 3=DEAUTH_LEAVING)
> > wpa_supplicant[671]: wlx0022b0e3c6b6: CTRL-EVENT-SSID-TEMP-DISABLED
> > id=0 ssid="local_wifi" auth_failures=2 duration=20 reason=CONN_FAILED
> > NetworkManager[657]:   [1584653959.9157] device
> > (wlx0022b0e3c6b6): supplicant interface state: authenticating ->
> > disconnected
> 
> Since this error message comes from wpa_supplicant, this might also be
> 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879484#25
> 

Let's assume this is a wpa_supplicant problem



signature.asc
Description: OpenPGP digital signature

Bug#956485: ITP: ocaml-unix-errno -- An errno variant that includes a variety of constructors

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 
Control: block 956479 by -1

* Package name: ocaml-unix-errno
  Version : 0.5.2
  Upstream Author : David Sheets 
* URL : https://github.com/dsheets/ocaml-unix-errno
* License : ISC
  Programming Lang: OCaml
  Description : An errno variant that includes a variety of constructors

An errno variant similar to Unix.error but including POSIX
2008, Linux, OS X, and FreeBSD constructors. A macro
definition type is also provided in order to transport a
specific errno-integer map as is the case with FUSE or
9p2000.u. The types and their functions reside in Errno and
are independent of any Unix bindings. This makes the
library's types usable from MirageOS on top of Xen.

It is a dependency of ocmal-sys-socket and will be maintained as part of
the OCaml team

Bug#956484: dvisvgm: Please, update to newer version 2.9.1

[Emilio J . Padrón]

Package: dvisvgm
Version: 2.9-1
Severity: wishlist

Dear Maintainer,

Version 2.9.1 is available and fixes a bug. It would be great to have it
in experimental as LaTeX-2020.

Regards and thank you for your work!
E

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Noah Meyerhans]

On Sat, Apr 11, 2020 at 10:23:54PM +0200, Florian Weimer wrote:
> Or put differently: If upstream doesn't want to default to
> -moutline-atomics, why should Debian?

Well, ultimately we own our build configurations and the optimizations
we enable therein.  If we don't want to enable -moutline-atomics
globally, then a second, optimized library is also an option.  IMO,
timing data like these should be enough to show that it's worth making a
change somewhere:

# 100 serial invocations of the "a.c" program attached to the bug
# report, linked against libc with -moutline-atomics
real0m1.902s
user0m3.488s
sys 0m25.498s

# 100 invocations of the same program linked against glibc with
# -march=armv8.1-a
real0m1.844s
user0m3.137s
sys 0m24.275s

# 100 invocations of the same program against our current libc build:
real8m15.452s
user130m33.139s
sys 0m1.162s

noah

Bug#956358: openafs-modules-dkms: piuparts failure on package installation

[Benjamin Kaduk]

severity 956358 important
tags 956358 + moreinfo
thanks

On Fri, Apr 10, 2020 at 11:30:10AM +0300, Adrian Bunk wrote:
> 
> https://piuparts.debian.org/sid/source/o/openafs.html
> 
> ...
>   Loading new openafs-1.8.6pre1 DKMS files...
>   It is likely that 4.19.0-8-amd64 belongs to a chroot's host
>   Building for 5.4.0-4-amd64
>   Building initial module for 5.4.0-4-amd64
>   Error! Bad return status for module build on kernel: 5.4.0-4-amd64 (x86_64)
>   Consult /var/lib/dkms/openafs/1.8.6pre1/build/make.log for more information.
>   dpkg: error processing package openafs-modules-dkms (--configure):
>installed openafs-modules-dkms package post-installation script subprocess 
> returned error exit status 10
>   Processing triggers for libc-bin (2.30-4) ...
>   Errors were encountered while processing:
>openafs-modules-dkms
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

The package installs cleanly and successfully builds the kernel module on a
freshly installed sid VM.
Attempting to run piuparts locally in that same VM (without the package
installed, not that it should matter) "succeeds" (but does not seem to
actually build a kernel module.

How can I find out more about the contents of the
/srv/piuparts.debian.org/slave/basetgz/sid_amd64.tar.gz indicated in the
indicated piuparts log?

Thanks,

Ben

Bug#130876: FW

[Est . Ana Belen Jimbo Muñoz]

Sent: Sunday, April 12, 2020 2:07 AM
Subject: Hey

Hey,
I would like to discuss with you.
email: shcott...@hotmail.com
Ms Shannon

Bug#956379: mumble: DBus call to getCurrentUrl responds with empty string

[Florian Snow]

Hi Chris,

Let me say first that this is my first time filing a bug with Debian and
I am not completely familiar with the process yet.  So if I made a
mistake, please accept my apologies.


Chris Knadle  writes:
> I'd like to know what risks and/or problems this bug poses, in order to
> understand how important this bug is and to figure out how it needs to be
> handled.

The bug is not security related; it is just an inconvenience.  Usually,
you can get the current URL via DBus and use that to script certain
things.  For example, getting the current URL makes it possible to not
only switch rooms on screen lock, but also to switch back to the
previous room on unlock.  So nothing major, but something I noticed
using the program and I wanted to help getting it fixed.  That's why I
fixed it upstream and I figured the best way to proceed was to now file
a bug with Debian.


> Mumble-server / Murmur defaults to not using DBUS, and does not depend on it
> either for the package in Debian in order to allow not having DBUS
> installed.

True, but this is about the client.  The default configuration on Debian
uses DBus here to interact with the client from the CLI.


> Mumble currently only has an "oldstable" backport right now, and no "stable"
> backport.  For a bugfix to a backport to be allowed, the bug is required to be
> fixed in "testing" first, and the only way to get a package to "testing" is to
> upload it to "unstable".

Ok, sure, thanks for letting me know.  That was just an idea because I
realized that the bug severity was probably not high enough to warrant a
fix in stable.  That's why I was thinking of stable-updates or
backports, but again, I am not completely familiar with the internals of
Debian.  I am willing to learn, though.  The reason I included
information about the bug also being in testing and sid was because
reportbug told me to verify if the bug existed there.

Happy hacking!
Florian

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Florian Weimer]

* Noah Meyerhans:

> On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote:
>> > At least if I'm reading the code right (which I may very well not be
>> > doing, being generally unfamiliar with gcc internals), -mtune=generic
>> > enables the equivalent of ARMv8 support:
>> >
>> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/common/config/aarch64/aarch64-common.c;h=0bddcc8c3e9282a957c5479b4df7f68058093bab;hb=HEAD#l176
>> >
>> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;h=ea9b98b4b0ad2a578755561bba5b6d5c56115994;hb=HEAD
>> >
>> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.h;h=8f08bad3562c4cbe8acdf5891e84f89d23ea6784;hb=HEAD#l226
>> 
>> Hmm.  I don't see anything that sets TARGET_OUTLINE_ATOMICS by
>> default.
>
> Only -moutline-atomics enables that.  Otherwise, unconditional support
> for atomics is enabled by TARGET_LSE, which itself is enabled by a
> number of options, e.g. -marmv8-a+lse, -marmv8.1-a, etc.
>
> See
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.c;h=4af562a81ea760891fac3cf7101b8bf887fe7a0d;hb=HEAD#l18961

Sorry, I have a feeling that we are discussing different matters.

I believe that ideally, Debian (and Fedora etc.) should follow
upstream GCC defaults.  I don't think we are in this state
(code_for_aarch64_compare_and_swap uses the atomics.md patterns to
call aarch64_split_compare_and_swap, as far as I can see).

Or put differently: If upstream doesn't want to default to
-moutline-atomics, why should Debian?

Bug#956483: ignition-math: FTBFS during binary-indep build

[Andreas Beckmann]

Source: ignition-math
Version: 6.4.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

ignition-math FTBFS during an arch-indep build (dpkg-buildpackage -A),
i.e. the arch:any package libignition-math-eigen3-dev does not get built:

   debian/rules override_dh_install
make[1]: Entering directory '/build/ignition-math-6.4.0+ds'
dh_install
# remove duplicate eigen files from mathx-dev.install regexp
cd debian/libignition-math-eigen3-dev; find . -type f -exec rm -f 
../libignition-math-dev/{} \;
/bin/sh: 1: cd: can't cd to debian/libignition-math-eigen3-dev
find debian/libignition-math-dev -type d -empty -delete
find: 'debian/libignition-math-dev': No such file or directory
make[1]: *** [debian/rules:21: override_dh_install] Error 1
make[1]: Leaving directory '/build/ignition-math-6.4.0+ds'
make: *** [debian/rules:27: binary-indep] Error 2


Andreas


ignition-math_6.4.0+ds-1_indep.log.gz
Description: application/gzip

Bug#955330: iproute2: corrupted output of "altname"

[Stefan Pietsch]

On 2020-04-03 11:16, Luca Boccassi wrote:

On Tue, 31 Mar 2020 04:12:38 +0200 Adam Borowski 
wrote:

Control: tags -1 -moreinfo

On Mon, Mar 30, 2020 at 10:36:03AM +0100, Luca Boccassi wrote:

On Mon, 2020-03-30 at 02:55 +0200, Adam Borowski wrote:

On a system with a bridge "ip a" says:

3: br0:  mtu 1500 qdisc noqueue
state UP group default qlen 1000
 link/ether 76:29:4f:cd:bd:87 brd ff:ff:ff:ff:ff:ff
 altname �
  ��
 altname ��!���



Kernel: Linux 5.6.0-00076-gbbfc4289910d (SMP w/4 CPU cores;

PREEMPT)



Those strings come from the kernel via netlink, and you seem to

have a

custom kernel. Can you reproduce with Debian's kernel?


Yeah, I've just tried.  With 5.5.0-1 it's:

0270  20 20 61 6c 74 6e 61 6d  65 20 c0 4e c2 b0 ff

ff  |  altname .N|

0280  0a 20 20 20 20 61 6c 74  6e 61 6d 65 20 d0 29

be  |.altname .).|

0290  b9 aa aa 0a 20 20 20 20  69 6e 65 74 20 31 30

2e  |inet 10.|




Ok, I'll have a look once the 5.5 kernel hits backports, as it's
necessary to reproduce it.


Reproducible with kernel 5.5.13 from Debian unstable:

root@lt490:~# ip tuntap add mode tap footap1

root@lt490:~# ip link show footap1
8: footap1:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether c2:20:9b:e6:0a:0a brd ff:ff:ff:ff:ff:ff
altname ??M?
altname ??M?

root@lt490:~# uname -a
Linux lt490 5.5.0-1-amd64 #1 SMP Debian 5.5.13-2 (2020-03-30) x86_64 GNU/Linux


Regards,
Stefan

Bug#956482: Avahi support not built-in to samba

[Michael Robinson]

Subject: samba: smbd not built with avahi support. This is possible with the 
version included with Debian 10. As per the samba mailing list, fully Time 
Machine suppo$
Package: samba
Version: 2:4.9.5+dfsg-5+deb10u1
Severity: normal

Apologies if this is a duplicate, I'm new to submitting bugs! 

Avahi support is not built in at compile time to smbd. This is possible with 
samba 4.9, it is possible with a simple compile time switch As per the samba 
mailing list, fully Time Machine support needs to have the arg 
--enable-spotlight in the samba compile configs.

https://lists.samba.org/archive/samba/2019-September/225824.html

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf not present

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

Versions of packages samba depends on:
ii adduser 3.118
ii dpkg 1.19.7
ii libbsd0 0.9.1-2
ii libc6 2.28-10
ii libldb1 2:1.5.1+really1.4.6-3
ii libpam-modules 1.3.1-5
ii libpam-runtime 1.3.1-5
ii libpopt0 1.16-12
ii libpython2.7 2.7.16-2+deb10u1
ii libtalloc2 2.1.14-2
ii libtdb1 1.3.16-2+b1
ii libtevent0 0.9.37-1
ii lsb-base 10.2019051400
ii procps 2:3.3.15-2
ii python 2.7.16-1
ii python-dnspython 1.16.0-1
ii python-samba 2:4.9.5+dfsg-5+deb10u1
ii python2.7 2.7.16-2+deb10u1
ii samba-common 2:4.9.5+dfsg-5+deb10u1
ii samba-common-bin 2:4.9.5+dfsg-5+deb10u1
ii samba-libs 2:4.9.5+dfsg-5+deb10u1
ii tdb-tools 1.3.16-2+b1

Versions of packages samba recommends:
ii attr 1:2.4.48-4
ii logrotate 3.14.0-4
ii samba-dsdb-modules 2:4.9.5+dfsg-5+deb10u1
ii samba-vfs-modules 2:4.9.5+dfsg-5+deb10u1

Versions of packages samba suggests:
pn bind9 
pn bind9utils 
pn ctdb 
pn ldb-tools 
pn ntp | chrony 
pn smbldap-tools 
ii ufw 0.36-1
pn winbind 

-- no debconf information

Bug#936802: kmer: Python2 removal in sid/bullseye

[Andreas Tille]

Hi Liubov,

On Sat, Apr 11, 2020 at 07:41:34PM +0200, Liubov Chuprikova wrote:
> As I mentioned during today's Jitsi meeting, kmer builds and all the tests
> passed in a clean sbuild schroot. Should we close the bug and make a
> release then?

Thanks for checking and confirming - I just did so.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#956455: RFS: smart-tools [ITP]

[Andreas Tille]

Hi,

just a short notice.  Somehow the pristine-tar branch is broken.
The original tarball can not be extracted by `gbp buildpackage`.
I tried to fix this bit the watch file is not properly crafted.
If I try

uscan --verbose --force-download

I get

uscan warn: In debian/watch no matching files for watch line

May be somebody else can help - but I need some rest now and may
be the next two days.  Since we have lots of new contributors I
guess you can get some help here.  Sorry for leaving you alone
for some time with this issue and thanks for your contribution
anyway

   Andreas.

On Sun, Apr 12, 2020 at 12:51:06AM +0900, Sao I Kuan wrote:
> Hi,
> 
> I'm looking for a sponsor for the package:
>   * smart-open (#956455)
> 
> The packages are on:
> https://salsa.debian.org/med-team/smart-open
> 
> The package is dependency of idseq-bench[1,2].
> 
> [1] https://github.com/chanzuckerberg/idseq-bench
> [2] https://bugs.debian.org/956033
> 
> The package does have two issues:
> * GCS: runtime dependencies are not packaged (google-cloud-storage
> and its deps).
> - I disabled the GCS related codes, and all the other tests
> are works well.
> - d/patches/exclude-gcs.patch
> * S3: test dependencies not packaged (moto and its deps).
> - I disabled the S3 related tests.
> - d/patches/exclude-moto-s3-test.patch
> 
> Because of reverse dependency of this package (specially idseq-bench)
> is only using the feature for local filesystems, GCS and S3 related
> codes are unnecessary for now. So I disabled them. I mentioned this
> issue in d/README.source.
> 
> I enabled all the tests not related with GCS and S3, are all passed
> well. The package was tested on both gbp and sbuild, and
> lintian-clean.
> 
> Please consider to review and sponsor this. Any kind of suggestions
> are appreciated.
> 
> Thank you!
> 
> Sincerely,
> 
> Sao I Kuan
> saoik...@gmail.com
> 
> 

-- 
http://fam-tille.de

Bug#956481: samba: smbd not built with avahi support. This is possible with the version included with Debian 10. As per the samba mailing list, fully Time Machine support needs to have the arg --enabl

[mike]

Package: samba
Version: 2:4.9.5+dfsg-5+deb10u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf not present

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

Versions of packages samba depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libbsd0   0.9.1-2
ii  libc6 2.28-10
ii  libldb1   2:1.5.1+really1.4.6-3
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpopt0  1.16-12
ii  libpython2.7  2.7.16-2+deb10u1
ii  libtalloc22.1.14-2
ii  libtdb1   1.3.16-2+b1
ii  libtevent00.9.37-1
ii  lsb-base  10.2019051400
ii  procps2:3.3.15-2
ii  python2.7.16-1
ii  python-dnspython  1.16.0-1
ii  python-samba  2:4.9.5+dfsg-5+deb10u1
ii  python2.7 2.7.16-2+deb10u1
ii  samba-common  2:4.9.5+dfsg-5+deb10u1
ii  samba-common-bin  2:4.9.5+dfsg-5+deb10u1
ii  samba-libs2:4.9.5+dfsg-5+deb10u1
ii  tdb-tools 1.3.16-2+b1

Versions of packages samba recommends:
ii  attr1:2.4.48-4
ii  logrotate   3.14.0-4
ii  samba-dsdb-modules  2:4.9.5+dfsg-5+deb10u1
ii  samba-vfs-modules   2:4.9.5+dfsg-5+deb10u1

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
pn  ntp | chrony   
pn  smbldap-tools  
ii  ufw0.36-1
pn  winbind

-- no debconf information

Bug#913227: (no subject)

[Adrian Heine]

tags 913227 + fixed-upstream
fixed 913227 3.6.4-1~exp1

thanks

Fixed in
https://git.dcmtk.org/?p=dcmtk.git;a=commit;h=dba269a958d9ca44d5af8570e125831d25f63cb3
thanks to your report.



signature.asc
Description: OpenPGP digital signature

Bug#956436: systemd-timesyncd will remove virtualbox-guest-utils

[Michael Biebl]

Am 11.04.20 um 10:02 schrieb luca:
> Package: systemd-timesyncd
> Version: 245.4-3
> Severity: normal
> 
> 
> # apt-get -V dist-upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages were automatically installed and are no longer 
> required:
>libnotify-bin (0.7.9-1)
>libqpdf26 (9.1.1-1)
> Use 'apt autoremove' to remove them.
> The following packages will be REMOVED:
>virtualbox-guest-utils (6.1.4-dfsg-4)
>virtualbox-guest-x11 (6.1.4-dfsg-4)

Balint, I guess we should drop
Conflicts: virtualbox-guest-utils,
   virtualbox-guest-utils-hwe
?





signature.asc
Description: OpenPGP digital signature

Bug#956379: mumble: DBus call to getCurrentUrl responds with empty string

[Chris Knadle]

Florian Snow:
> Package: mumble
> Version: 1.3.0~git20190125.440b173+dfsg-2
> Severity: normal
> Tags: patch upstream
> 
> When calling the DBus method getCurrentUrl, it responds with an empty
> string instead of a Mumble URL, like the call to getTalkingUsers
> responds with a list of talking users.  Here is the call I used:
> 
> dbus-send --print-reply --session --type=method_call \
> --dest=net.sourceforge.mumble.mumble / \
> net.sourceforge.mumble.Mumble.getCurrentUrl
> 
> The bug is also present in testing and sid.  I fixed it upstream and I
> am hoping for a point release so this can hopefully go into stable
> updates or backports.

I'd like to know what risks and/or problems this bug poses, in order to
understand how important this bug is and to figure out how it needs to be
handled.  If this is a security related bug, an upload for that would need to be
coordinated with the Debian Security Team.

Mumble-server / Murmur defaults to not using DBUS, and does not depend on it
either for the package in Debian in order to allow not having DBUS installed.
There shouldn't be an issue for default configurations, as far as I know.

Mumble currently only has an "oldstable" backport right now, and no "stable"
backport.  For a bugfix to a backport to be allowed, the bug is required to be
fixed in "testing" first, and the only way to get a package to "testing" is to
upload it to "unstable".

Any fix to "stable" requires the bug to be fixed in "unstable" first, and the
bug has to be of more than "normal" severity and be a targeted-only fix with the
individual patch provided in the request to the release team, with a detailed
description of the issue and what problems it causes, as well as what testing
the fix has had.

Mumble upstream just released a 1.3.1-rc1 tarball today, so it's clear they're
actively preparing a bugfix release.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#956480: [PATCH] d/control: Depend on mujs

[Bastian Germann]

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index a36186f..f25a312 100644
--- a/debian/control
+++ b/debian/control
@@ -28,6 +28,7 @@ Build-Depends:
  libjpeg-dev,
  liblcms2-dev (>= 2.6~),
  liblua5.2-dev,
+ libmujs-dev,
  libpulse-dev,
  librubberband-dev,
  libsdl2-dev,
-- 
2.26.0

Bug#937784: python-gevent: diff for NMU version 1.4.0-1.2

[Sandro Tosi]

On Sat, Apr 11, 2020 at 3:21 PM László Böszörményi (GCS)  
wrote:
>
> On Sat, Apr 11, 2020 at 2:12 AM Sandro Tosi  wrote:
> > I've prepared an NMU for python-gevent (versioned as 1.4.0-1.2). The diff
> > is attached to this message.
>  You know, I still don't get why immediate NMU was necessary. Why
> don't give some time to the maintainer to respond.

i know, i'm pushing it a bit harder than what Debian is used to, but
there are still 600+ packages to go, and after having addressed
src:uwsgi, there were no more rdeps for the latest batch of NMUs, so i
knocked them down easily as it was a straight-forward upload

> > Please consider maintaining python-gevent with the Debian Python Modules 
> > team
>  Will think about it. You might be right and pushing it to the team
> will solve your concerns.

it's not much of a concern more an increased maintainability: there
are a lot of skilled people in DPMT that could help out keeping a
package up to date with standards, like during this gian py2moreval
process

Cheers,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#956480: mpv: JavaScript backend MuJS available

[Bastian Germann]

Package: mpv
Severity: wishlist

mpv has a JavaScript backend with MuJS available which is documented in
your package's man page. A mujs package is now available in Debian and
you can build-depend on it to enable the feature.

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Noah Meyerhans]

On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote:
> > At least if I'm reading the code right (which I may very well not be
> > doing, being generally unfamiliar with gcc internals), -mtune=generic
> > enables the equivalent of ARMv8 support:
> >
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/common/config/aarch64/aarch64-common.c;h=0bddcc8c3e9282a957c5479b4df7f68058093bab;hb=HEAD#l176
> >
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;h=ea9b98b4b0ad2a578755561bba5b6d5c56115994;hb=HEAD
> >
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.h;h=8f08bad3562c4cbe8acdf5891e84f89d23ea6784;hb=HEAD#l226
> 
> Hmm.  I don't see anything that sets TARGET_OUTLINE_ATOMICS by
> default.

Only -moutline-atomics enables that.  Otherwise, unconditional support
for atomics is enabled by TARGET_LSE, which itself is enabled by a
number of options, e.g. -marmv8-a+lse, -marmv8.1-a, etc.

See
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.c;h=4af562a81ea760891fac3cf7101b8bf887fe7a0d;hb=HEAD#l18961

Bug#934486: Debian Bugs information: detailed logs for Bug#934486

[Marcos Fouces]

Hello Peter

Thanks for pointing this out! As you stated, this was a simple
oversight and i upload a fix in no time.

Greetings, 
Marcos

Bug#956479: ITP: ocaml-sys-socket -- OCaml ctypes bindings to system-specific low-level socket structure and data-types

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 
Control: block 956478 by -1

* Package name: ocaml-sys-socket
  Version : 1.0.0
  Upstream Author : Romain Beauxis 
* URL : https://github.com/toots/ocaml-sys-socket
* License : Expat
  Programming Lang: OCaml
  Description : OCaml ctypes bindings to system-specific low-level socket 
structure and data-types

The interface is implemented using ocaml-ctypes and is intended to
exposed the machine-specific, low-level details of the most important
parts of socket implementations.

Sys_socket provides an API compatible for both Unix and Win32 systems,
while Sys_socket_unix provides the API specific to Unix systems, mostly
the sockaddr_u structure.

This package will be maintained as part of the Debian OCaml Team

Bug#937784: python-gevent: diff for NMU version 1.4.0-1.2

[GCS]

On Sat, Apr 11, 2020 at 2:12 AM Sandro Tosi  wrote:
> I've prepared an NMU for python-gevent (versioned as 1.4.0-1.2). The diff
> is attached to this message.
 You know, I still don't get why immediate NMU was necessary. Why
don't give some time to the maintainer to respond.

> Please consider maintaining python-gevent with the Debian Python Modules team
 Will think about it. You might be right and pushing it to the team
will solve your concerns.

Bug#956260: [Debichem-devel] Bug#956260: bkchem: should this package be removed?

[Sandro Tosi]

> To my opinion, bkchem is the best simple program for drawing chemical
> skeletal formulae.
> As a chemist I use it all the time. It would really be a pity if it
> disappears from Debian.

that's good to know and thanks for sharing this.

The situation is that every major Linux distributions are removing
support for Python2, as it entered its end-of-life status on Jan 1st,
2020. So at some point either someone steps in and port bkchem (and
all the othre required packages) to python3 or it will have to be
removed from Debian (at least from its stable release).

If you are knowledgeable to do the migration, or know someone that is
willing to lend a hand, now it's the time to act.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#931772: [request-tracker-maintainers] Bug#931772: RT: On Create scrip ran but ticket not created

[Sergio Gelato]

I agree that one should avoid forking RT unnecessarily. While I still think 
that the current behaviour is flawed, it hasn't been an urgent concern since 
I've addressed the performance issue that acted as a trigger in my environment. 
If it were, I (as a non-paying customer with correspondingly low support 
expectations) would probably either come up with a fix of my own or migrate to 
different software.

I'd rather not be the one who brings this up in upstream's forum, though, as 
they require prior registration. But anyone else who feels this is worth 
pursuing is welcome to do so (and hopefully improve on my analysis: I didn't 
expend all that much thought on it).

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Florian Weimer]

* Noah Meyerhans:

> On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote:
>> > Gcc provides two ways to enable support for these instructions at build
>> > time.  The simplest, and least disruptive, is to enable -moutline-atomics
>> > globally in the arm64 glibc build.
>> 
>> Shouldn't GCC do this by default, at least for -mtune=generic?
>
> Maybe.  Would you rather pursue that avenue first?

My hope is that GCC upstream defaults reflect current practices for
the architecture.  It doesn't make sense if every distribution ends up
patching in same GCC defaults which are not upstream.

Sure, there might be bare-metal targets which do not want this, but is
this really the primary audience nowadays?

> At least if I'm reading the code right (which I may very well not be
> doing, being generally unfamiliar with gcc internals), -mtune=generic
> enables the equivalent of ARMv8 support:
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/common/config/aarch64/aarch64-common.c;h=0bddcc8c3e9282a957c5479b4df7f68058093bab;hb=HEAD#l176
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;h=ea9b98b4b0ad2a578755561bba5b6d5c56115994;hb=HEAD
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.h;h=8f08bad3562c4cbe8acdf5891e84f89d23ea6784;hb=HEAD#l226

Hmm.  I don't see anything that sets TARGET_OUTLINE_ATOMICS by
default.

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Noah Meyerhans]

On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote:
> > Gcc provides two ways to enable support for these instructions at build
> > time.  The simplest, and least disruptive, is to enable -moutline-atomics
> > globally in the arm64 glibc build.
> 
> Shouldn't GCC do this by default, at least for -mtune=generic?

Maybe.  Would you rather pursue that avenue first?

At least if I'm reading the code right (which I may very well not be
doing, being generally unfamiliar with gcc internals), -mtune=generic
enables the equivalent of ARMv8 support:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/common/config/aarch64/aarch64-common.c;h=0bddcc8c3e9282a957c5479b4df7f68058093bab;hb=HEAD#l176

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;h=ea9b98b4b0ad2a578755561bba5b6d5c56115994;hb=HEAD

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.h;h=8f08bad3562c4cbe8acdf5891e84f89d23ea6784;hb=HEAD#l226

noah

Bug#820060: Debian Bug#820060: python-biom-format: broken on big-endian architectures

[Liubov Chuprikova]

Hi Andreas,

It looks like the upstream fixed the issue in some recent version, as
according to the logs [1], the package builds now for big-endians as well.
Do you agree, that we can close the bug as well as the issue?

Best regards,
Liubov

[1] http://buildd.debian.org/python-biom-format

Bug#956469: SRT support is not enabled

[Kyle Robbertze]

Control: severity -1 normal

Hi,

Thank you for the report. This requires packaging ocaml-srt [1]. I have
filed an ITP blocking this bug to track it.

[1] https://github.com/savonet/ocaml-srt

Cheers
Kyle

On 2020/04/11 19:37, Sébastien Leblanc wrote:
> Package: liquidsoap
> Version: 1.4.1-1
> Severity: important
> 
> Upstream added support for SRT, but the build does not include it.
> 
> --
> % liquidsoap 'output.dummy(input.srt())'
> At line 1, char 13-23:
> Error 4: Undefined variable input.srt
> 
> --
> /usr/share/liquidsoap % grep -cR srt
> bin/extract-replaygain:0
> libs/audio.liq:0
> libs/deprecations.liq:0
> libs/externals.liq:0
> libs/fades.liq:0
> libs/flows.liq:0
> libs/gstreamer.liq:0
> libs/hls.liq:0
> libs/http.liq:0
> libs/http_codes.liq:0
> libs/lastfm.liq:0
> libs/metadata.liq:0
> libs/pervasives.liq:0
> libs/playlist.liq:0
> libs/protocols.liq:0
> libs/ref.liq:0
> libs/resolvers.liq:0
> libs/shoutcast.liq:0
> libs/string.liq:0
> libs/utils.liq:0
> libs/video.liq:0
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-4-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CA:fr (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages liquidsoap depends on:
> ii  adduser   3.118
> ii  curl  7.68.0-1
> ii  libao41.2.2+20180113-1+b1
> ii  libasound21.2.2-2.1
> ii  libavcodec58  7:4.2.2-1+b1
> ii  libavdevice58 7:4.2.2-1+b1
> ii  libavformat58 7:4.2.2-1+b1
> ii  libavutil56   7:4.2.2-1+b1
> ii  libc6 2.30-4
> ii  libcamomile-ocaml-data1.0.2-2
> ii  libexif12 0.6.21-6
> ii  libfaad2  2.9.1-1
> ii  libflac8  1.3.3-1
> ii  libgavl1  1.4.0-5
> ii  libgcc-s1 [libgcc1]   10-20200324-1
> ii  libgcc1   1:10-20200324-1
> ii  libgd32.2.5-5.2
> ii  libgif7   5.1.9-1
> ii  libglib2.0-0  2.64.1-1
> ii  libgstreamer-plugins-base1.0-01.16.2-4
> ii  libgstreamer1.0-0 1.16.2-2
> ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
> ii  libjpeg62-turbo   1:1.5.2-2+b1
> ii  liblo70.30-3
> ii  libmad0   0.15.1b-10
> ii  libmagic1 1:5.38-4
> ii  libmp3lame0   3.100-3
> ii  libogg0   1.3.2-1+b1
> ii  libopus0  1.3-1+b1
> ii  libpcre3  2:8.39-12+b1
> ii  libpng16-16   1.6.37-2
> ii  libportaudio2 19.6.0-1
> ii  libpulse0 13.0-5
> ii  libsamplerate00.1.9-2
> ii  libsdl-image1.2   1.2.12-12
> ii  libsdl-ttf2.0-0   2.0.11-6
> ii  libsdl1.2debian   1.2.15+dfsg2-5
> ii  libshine3 3.1.1-2
> ii  libsoundtouch12.1.2+ds1-1
> ii  libspeex1 1.2~rc1.2-1.1
> ii  libssl1.1 1.1.1f-1
> ii  libstdc++610-20200324-1
> ii  libswresample37:4.2.2-1+b1
> ii  libswscale5   7:4.2.2-1+b1
> ii  libtag1v5 1.11.1+dfsg.1-0.3+b1
> ii  libtheora01.1.1+dfsg.1-15
> ii  libtiff5  4.1.0+git191117-2
> ii  libvorbis0a   1.3.6-2
> ii  libvorbisenc2 1.3.6-2
> ii  libvorbisfile31.3.6-2
> ii  libxpm4   1:3.5.12-1
> ii  ocaml-base-nox4.08.1-8
> ii  sox   14.4.2+git20190427-2
> 
> Versions of packages liquidsoap recommends:
> ii  logrotate 3.16.0-2
> ii  vorbis-tools  1.4.0-11
> ii  vorbisgain0.37-2+b1
> 
> Versions of packages liquidsoap suggests:
> ii  festival1:2.5.0-4
> ii  icecast22.4.4-3
> ii  mplayer 2:1.3.0-8+b5
> ii  youtube-dl  2020.01.24-0.1
> 
> -- no debconf information
> 

Bug#956478: ITP: ocaml-srt -- OCaml bindings for the Secure, Reliable, Transport protocol library

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 
Control: block 956469 by -1

* Package name: ocaml-srt
  Version : 0.1.0
  Upstream Author : Savonet Team 
* URL : https://www.liquidsoap.info
* License : GPL-2
  Programming Lang: OCaml
  Description : OCaml bindings for the Secure, Reliable, Transport protocol 
library

This module provides OCaml bindings for the libsrt library. Secure Reliable
Transport (SRT) is an open source transport technology that optimizes streaming
performance across unpredictable networks, such as the Internet.

This package will be maintained as part of the Debian Ocaml Team

Bug#956477: herbstluftwm: please make the build reproducible

[Chris Lamb]

Source: herbstluftwm
Version: 0.8.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
herbstluftwm could not be built reproducibly.

This is because you did not pass "-u" / "--utc" to date(1), so it
varied depending on the build system's timezone even though the
underlying value was fixed.

Patch attached… which also uses SOURCE_DATE_EPOCH as you do not need
to call out to dpkg-parsechangelog.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2020-04-11 19:34:20.623411284 +0100
--- b/debian/rules  2020-04-11 19:37:43.510924382 +0100
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export BUILD_DATE = $(shell dpkg-parsechangelog -SDate | date -f- +"%Y-%m-%d")
+export BUILD_DATE = $(shell date -u -d@$(SOURCE_DATE_EPOCH) +"%Y-%m-%d")
 PYTEST_VERSION = $(shell python3 -c 'import sys ; print("py" + "".join([str(i) 
for i in sys.version_info[:2]]))')
 
 %:

Bug#956476: libnet-async-ssl-perl: long description contains boilerplate from dh-make-perl

[Jonas Smedegaard]

Package: libnet-async-ssl-perl
Version: 0.22-2
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Long description of libnet-async-ssl-perl contains this:
> This description was automagically extracted from the module
> by dh-make-perl.

That seems pretty useless for Debian's users,
and I guess it should be stripped
(and other parts double-checked - as that's probably why it was there).


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6SDtAACgkQLHwxRsGg
ASEXDQ/+OItQf5V1yHmg0pUWQUiCSR03SP08gAWVhaszVqNlNKlGMDxUFWVtFph3
jepiSqrPb0meFdJtd1RZMV+OGJV/f2cdt5+ACgFXWEDcyC89L5HQbuOLREULuQ21
/AOp3kFX4gfD2k4GeYzIlibZdQEe9SB6FnTw4vGeJrb8E3pQSMBPJ4hej/OURqO2
0DGZUhSu5g7/BrsjInSrO2RiedXTWOc51mPnmUNmvspGPs4b0tAeFG3Sa4UmRDYa
odH/LvLG2jlhXBlL9ht24DoosUpvAku3qlUJeHz0j6Z0pKUB6igih88UoZhEh+yE
+AZVNll0gayfOlVSzY7iLbK55Kfk0zNf0Il+JU0DxWfVPC8VRDm33kT8N8wp221S
6+MXCllq21lbafvrIETR7VbOy/VYzIjEGEz7LRG1tJsV/BJlb2u0FT9QBosjzxvh
CRMH4JVL5Tr1j6btA/h38blo7+65UCaeqUYD/9SOOzrugcBMwYOwgQise92m/7wF
dmnmxP0kCaz+TvPLdCrf5ANsIfV4FpYrxTfwRppSHxMJPex7it/9ne//48KjBn+O
vuUUimMc5FeoKOZFldJNKohKS1MnM/Lha5Uh040wQDKzlBX8d/C5c4oDbktzq/1T
lU9qaAX+WMxdcAKJ3uVjXdVSghuB5MFbL9je+kIX1q5sqVFZag0=
=I82Z
-END PGP SIGNATURE-

Bug#956475: libnet-async-http-perl: should recommend (or at least suggest) libnet-async-ssl-perl

[Jonas Smedegaard]

Package: libnet-async-http-perl
Version: 0.45-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Long description of libnet-async-http-perl includes this:
> Net::Async::HTTP optionally supports SSL connections,
> if IO::Async::SSL is installed.

That seems like a reason for having the package recommend
libnet-async-ssl-perl.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6SDfkACgkQLHwxRsGg
ASHYJA//RnhssRN4ctPZKT1N0IXcyKQ1QNAgbnGr3tHlo0f95/b4k4kNPBA6R9or
9P1tty8LgjdFH0ip2d564k8GZvCOcFB680To+HDcDJesKUC1OZ1r4Eq/MCAbkWQz
TMQ3l44Ij8AmCLyW6EnVJsRBejagvfsLhL6kvGwe+uU8yJdE3eECKZ+vB+jpxYRk
gOUi3VCDN50kYbLZKIrMAj0b8MdiSl9G4UpdCCm3ovquKsR9C+a/+1lGVjfsmo7o
hiNKjxXFbrMZMU4OrnU3TLuS63Bzvp+VChkRkAlVuJZU3id17et3QCtnLuCFqLo4
tTI+BDuWw/geU0fFBTGpbBbF4+8orKLhB6hkmGjjomSDOgT86OE6SheQ+UNGB3GP
OKU5WBMxfDEqo05ztJalJ8eDT+OWuKUnQUhP7zQNaqtinPE7Whh1aloPkZwTQgiw
SNvaIZyrwhmLWu9Tjvux0rbacwPUzTwiGsLY/HjxDLv4hOBpLmkx45gVB6oVJqMM
0qn+8XTorefLCExlBcBMIYdzUgBCtuENB40k5pLDnTXnS9m74bVIckK5HamV13QN
WQWqkyAqSdyVjdII2p7hlPlAZzjub/F9V+cf3Yfm6KPT7+CLNj4l/ta5pUeD+CON
2LRkLacHxFkcr5gNWwnezPaj+7zgbUMDQssGQcfRQM+liS+HN1M=
=gNYN
-END PGP SIGNATURE-

Bug#956473: sprai: please make the build reproducible

[Chris Lamb]

Source: sprai
Version: 0.9.9.23+dfsg-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
sprai could not be built reproducibly.

This is because it embedded the build path in the binary, and the root
cause of this was because the upstream build system was not respecting
dpkg-buildflags.

Patch attached that fixes this.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/cflags.patch   1970-01-01 01:00:00.0 +0100
--- b/debian/patches/cflags.patch   2020-04-11 19:24:35.361790449 +0100
@@ -0,0 +1,27 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2020-04-11
+
+--- sprai-0.9.9.23+dfsg.orig/makefile
 sprai-0.9.9.23+dfsg/makefile
+@@ -38,16 +38,16 @@ check_circularity.pl \
+ all: $(COMPILED)
+ 
+ bfmt72s: bfmt72s.c
+-  $(CC) -Wall -O3 -g -o $@ $<
++  $(CC) -Wall -O3 -g $(CFLAGS) -o $@ $<
+ 
+ nss2v_v3: nss2v_v3.c
+-  $(CC) -Wall -O3 -g -o $@ $<
++  $(CC) -Wall -O3 -g $(CFLAGS) -o $@ $<
+ 
+ myrealigner: myrealigner.c
+-  $(CC) -Wall -O3 -g -o $@ $^
++  $(CC) -Wall -O3 -g $(CFLAGS) -o $@ $^
+ 
+ m52bfmt7: m52bfmt7.c
+-  $(CC) -Wall -O3 -g -o $@ $<
++  $(CC) -Wall -O3 -g $(CFLAGS) -o $@ $<
+ 
+ 
+ install: $(COMPILED) $(SCRIPTS)
--- a/debian/patches/series 2020-04-11 19:13:38.925486011 +0100
--- b/debian/patches/series 2020-04-11 19:24:35.365790510 +0100
@@ -1,3 +1,4 @@
 libexec.patch
 example-specs.patch
 makefile.patch
+cflags.patch
--- a/debian/rules  2020-04-11 19:13:38.925486011 +0100
--- b/debian/rules  2020-04-11 19:23:53.109145637 +0100
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
 %:
dh $@
 

Bug#942404: Tests seem to work again

[Liubov Chuprikova]

Hi Paul,

I tried hard but wasn't able to reproduce the bug (in a clean chroot). Even
for the stable version (2.3.0-2) tests are passing (several times in a
row). Looking at the debci logs [1], tests are passing for quite some time.
Do you think, it makes sense to keep it longer?

Best regards,
Liubov

[1] https://ci.debian.net/packages/d/discosnp/unstable/amd64/

Bug#956425: RM: python-trollius -- RoQA; python2-only; backport of a another project; deprecated upstream; no rdeps

[Scott Kitterman]

Actually nevermind.  Once I decrufted uswgi it was fine.

Scott K

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

Bug#956472: atitvout: Consider removing this package

[Boyuan Yang]

Source: atitvout
Version: 0.4-13
Severity: serious
Tags: sid  bullseye
X-Debbugs-CC: r...@gna.org

Dear Debian atitvout maintainer,

The upstream of atitvout was not active since 2003 (!). Besides, this package
saw no upload in Debian since 2009. It is also an i386-only package currently.

As a result, I believe we should have it removed before Buster release. I will
submit the removal bug 15 days later (on Apr. 26, 2020) if I receive no reply.

If you have any doubts, please let me know *immediately*.

-- 
Best Regards,
Boyuan Yang


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

Bug#956471: snapshot.debian.org: Missing Content-Type for .deb files?

[Chris Lamb]

Package: snapshot.debian.org

Hi,

First, thanks for maintaining snapshot.debian.org. I just accidentally
single-clicked on a ".deb" link in my browser and it attempted to
render the binary file within my browser window, ie:

debian-binary   1564357938  0 0 100644  4 `
2.0
control.tar.xz  1564357938  0 0 100644  1152  `
ý7zXZ��æÖ´FÀ¿€P!
���¶à'ÿ7]�¼}
•ÀJ>yÂÌ&£Y>,¯ï

So, I think this is due to the lack of a Content-Type HTTP header and,
indeed, it seems to be missing when I try with curl:

$ curl -I 
http://snapshot.debian.org/archive/debian/20190729T040647Z/pool/main/a/apktool/apktool_2.4.0-1_all.deb
HTTP/1.1 200 OK
Date: Sat, 11 Apr 2020 17:52:30 GMT
Server: Apache
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
Referrer-Policy: no-referrer
X-Xss-Protection: 1
Last-Modified: Mon, 29 Jul 2019 04:22:26 GMT
ETag: "33644-58eca3d44a480"
Content-Length: 210500
X-Clacks-Overhead: GNU Terry Pratchett
Cache-Control: max-age=31536000, public
X-Varnish: 18584565 20166281
Age: 164
Via: 1.1 varnish (Varnish/5.0)
connection: close
Accept-Ranges: bytes

I believe the correct value should be "application/vnd.debian.binary-
package" but anything generic like "application/x-binary" would work
for me.


Regards,

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

Bug#956465: bash-completion: umount completion requires gawk

[Gabriel F. T. Gomes]

Control: reassign -1 mount
Control: merge -1 933934

Hi, наб,

Thanks for the report.  I'll reassign it to the mount package, because
completions for umount are shipped by it, not by bash-completion.
Also, I'll mark it as a duplicate of bug 933934.


Cheers,
Gabriel

Bug#956470: libtorrent-rasterbar9: Please update libtorrent-rasterbar to v1.2.x

[jim_p]

Package: libtorrent-rasterbar9
Version: 1.1.13-1.1+b2
Severity: wishlist
Tags: upstream

Dear Maintainer,

As the title suggests, please update libtorrent-rasterbar to 1.2.x.
4+ months ago I opened a bug report about updating qbittorrent to v4.2.x. A
couple of weeks ago I discovered that qbittorrent 4.2.x depends on libtorrent-
rasterbar 1.2.x, so I am asking you to update it first.

Thank you in advance.



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

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

Versions of packages libtorrent-rasterbar9 depends on:
ii  libboost-system1.67.0  1.67.0-17
ii  libc6  2.30-4
ii  libgcc-s1  10-20200324-1
ii  libssl1.1  1.1.1f-1
ii  libstdc++6 10-20200324-1

libtorrent-rasterbar9 recommends no packages.

Versions of packages libtorrent-rasterbar9 suggests:
pn  libtorrent-rasterbar-dbg  

-- no debconf information

Bug#936802: kmer: Python2 removal in sid/bullseye

[Liubov Chuprikova]

Hi Andreas,

As I mentioned during today's Jitsi meeting, kmer builds and all the tests
passed in a clean sbuild schroot. Should we close the bug and make a
release then?

Regards,
Liubov

Bug#956469: SRT support is not enabled

[Sébastien Leblanc]

Package: liquidsoap
Version: 1.4.1-1
Severity: important

Upstream added support for SRT, but the build does not include it.

--
% liquidsoap 'output.dummy(input.srt())'
At line 1, char 13-23:
Error 4: Undefined variable input.srt

--
/usr/share/liquidsoap % grep -cR srt
bin/extract-replaygain:0
libs/audio.liq:0
libs/deprecations.liq:0
libs/externals.liq:0
libs/fades.liq:0
libs/flows.liq:0
libs/gstreamer.liq:0
libs/hls.liq:0
libs/http.liq:0
libs/http_codes.liq:0
libs/lastfm.liq:0
libs/metadata.liq:0
libs/pervasives.liq:0
libs/playlist.liq:0
libs/protocols.liq:0
libs/ref.liq:0
libs/resolvers.liq:0
libs/shoutcast.liq:0
libs/string.liq:0
libs/utils.liq:0
libs/video.liq:0



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

Kernel: Linux 5.4.0-4-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA:fr (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages liquidsoap depends on:
ii  adduser   3.118
ii  curl  7.68.0-1
ii  libao41.2.2+20180113-1+b1
ii  libasound21.2.2-2.1
ii  libavcodec58  7:4.2.2-1+b1
ii  libavdevice58 7:4.2.2-1+b1
ii  libavformat58 7:4.2.2-1+b1
ii  libavutil56   7:4.2.2-1+b1
ii  libc6 2.30-4
ii  libcamomile-ocaml-data1.0.2-2
ii  libexif12 0.6.21-6
ii  libfaad2  2.9.1-1
ii  libflac8  1.3.3-1
ii  libgavl1  1.4.0-5
ii  libgcc-s1 [libgcc1]   10-20200324-1
ii  libgcc1   1:10-20200324-1
ii  libgd32.2.5-5.2
ii  libgif7   5.1.9-1
ii  libglib2.0-0  2.64.1-1
ii  libgstreamer-plugins-base1.0-01.16.2-4
ii  libgstreamer1.0-0 1.16.2-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblo70.30-3
ii  libmad0   0.15.1b-10
ii  libmagic1 1:5.38-4
ii  libmp3lame0   3.100-3
ii  libogg0   1.3.2-1+b1
ii  libopus0  1.3-1+b1
ii  libpcre3  2:8.39-12+b1
ii  libpng16-16   1.6.37-2
ii  libportaudio2 19.6.0-1
ii  libpulse0 13.0-5
ii  libsamplerate00.1.9-2
ii  libsdl-image1.2   1.2.12-12
ii  libsdl-ttf2.0-0   2.0.11-6
ii  libsdl1.2debian   1.2.15+dfsg2-5
ii  libshine3 3.1.1-2
ii  libsoundtouch12.1.2+ds1-1
ii  libspeex1 1.2~rc1.2-1.1
ii  libssl1.1 1.1.1f-1
ii  libstdc++610-20200324-1
ii  libswresample37:4.2.2-1+b1
ii  libswscale5   7:4.2.2-1+b1
ii  libtag1v5 1.11.1+dfsg.1-0.3+b1
ii  libtheora01.1.1+dfsg.1-15
ii  libtiff5  4.1.0+git191117-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libvorbisfile31.3.6-2
ii  libxpm4   1:3.5.12-1
ii  ocaml-base-nox4.08.1-8
ii  sox   14.4.2+git20190427-2

Versions of packages liquidsoap recommends:
ii  logrotate 3.16.0-2
ii  vorbis-tools  1.4.0-11
ii  vorbisgain0.37-2+b1

Versions of packages liquidsoap suggests:
ii  festival1:2.5.0-4
ii  icecast22.4.4-3
ii  mplayer 2:1.3.0-8+b5
ii  youtube-dl  2020.01.24-0.1

-- no debconf information

Bug#955812: gedit-latex-plugin does not work anymore

[Maurizio Quadrio]

Dear Pietro,

thanks for your efforts. I fear the issue is related to both gedit-latex
(upstream) *and* gedit. I also have a feeling that the trace I sent
before was there since quite some time, whereas gedit-latex (which I use
daily) broke a couple weeks ago.

Anyway, I'll stay tuned and see what happens...


> Thanks Maurizio.
> 
> I still couldn't try to reproduce, but this reminds of
> https://gitlab.gnome.org/GNOME/gedit/issues/225
> 
> ... which would suggest it is a problem of gedit, not gedit-latex.
> 
> Indeed, a gedit "Document.get_location()" should return a valid
> Gio.File except if the file is not saved:
> https://wiki.gnome.org/Apps/Gedit/PythonPluginHowTo#Gedit.Document
>  - which does not seem to be your case.
> 
> Pietro
> 

Bug#956468: RM: pycassa -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pycassa. It depends on Python 2, the last upstream commit happened
three years ago and the upstream PR for Py3 support (#178) hasn't seen any 
update
since 2014.

Cheers,
Moritz

Bug#956462: pymca: FTBFS with Qhull 2019.1

[PICCA Frederic-Emmanuel]

Do you provide a pkgconfig file with qhull ?

De : debian-science-maintainers 
[debian-science-maintainers-bounces+picca=synchrotron-soleil...@alioth-lists.debian.net]
 de la part de Timo Röhling [t...@gaussglocke.de]
Envoyé : samedi 11 avril 2020 19:08
À : sub...@bugs.debian.org
Objet : Bug#956462: pymca: FTBFS with Qhull 2019.1

Source: pymca
Version: 5.5.4+dfsg-1
Severity: important
Tags: ftbfs, patch

Dear maintainer,

your package uses a deprecated include path for Qhull, which will no
longer build with the latest release. Attached is a patch that will fix
the build with the qhull package in experimental.

Bug#956467: transition: qhull

[Timo Röhling]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 956460 956461 956462

Dear release team,

I would like to transition qhull 2019.1 after some ABI breaking changes
in upstream. API seems mostly unaffected, except for a deprecated
include path that has been removed. This affects three packages (see below).

The ben tracker looks good to me:
https://release.debian.org/transitions/html/auto-qhull.html

I rebuilt all reverse dependencies (on amd64):

3depict: FTBFS (tracked in bug #956460)
gdal: OK
getfem++: OK
meshlab: OK
octave: OK
pcl: OK
plplot: OK
pymca: FTBFS (tracked in #956462)
ros-geometric-shapes: OK
saga: FTBFS (tracked in #956461)

Thank you,
Timo

Bug#956466: RM: django-ratelimit -- RoQA; Depends on Python 2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove django-ratelimit. It depends on Python and is RC-buggy since
2015 (#806355) and consequently missed the last two stable releases. The
last maintainer upload was in 2014.

Cheers,
Moritz

Bug#956465: bash-completion: umount completion requires gawk

[наб]

Package: bash-completion
Version: 1:2.10-1
Severity: normal
Tags: patch

Dear Maintainer,

The umount completion seems to depend on gawk's gensub() [1]
being present in awk, but Debian installs mawk,
which doesn't have it [2], by default.

This has led to this transcript on a new-ish sid system:

root@aqq:~# umount sdawk: line 18: function gensub never defined
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined
awk: line 18: function gensub never defined
^C


The umount completion is the only one with this specific problem:

misio@aqq:~$ grep -r gensub /usr/share/bash-completion/
/u/s/b-c/c/umount:  homeless = gensub(ENVIRON["HOME"], "~", "g", 
homeless)
/u/s/b-c/c/umount:  homeless = gensub(/(\s)/, "\\1", "g", homeless)
/u/s/b-c/c/umount:  reldir = gensub(ENVIRON["PWD"]"/", "", "g", reldir)
/u/s/b-c/c/umount:  reldir = gensub(/(\s)/, "\\1", "g", reldir)


And, having looked through each instance of "awk" in
/usr/share/bash-completion, the only thing that stood out is that
pkgutil uses "nawk" for one invocation (which works, since
it's provided by alias, but is inconsistent).


[1]: https://www.gnu.org/software/gawk/manual/html_node/String-Functions.html
[2]: 
https://invisible-island.net/mawk/manpage/mawk.html#h3-8_-Built-in-functions


Yours,
наб


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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information



signature.asc
Description: PGP signature

Bug#956462: pymca: FTBFS with Qhull 2019.1

[Timo Röhling]

Source: pymca
Version: 5.5.4+dfsg-1
Severity: important
Tags: ftbfs, patch

Dear maintainer,

your package uses a deprecated include path for Qhull, which will no
longer build with the latest release. Attached is a patch that will fix
the build with the qhull package in experimental.

--- a/debian/rules	2020-04-11 18:56:43.639578519 +0200
+++ b/debian/rules	2020-04-11 18:56:18.932267016 +0200
@@ -7,7 +7,7 @@
 export SPECFILE_USE_GNU_SOURCE=1
 export WITH_CYTHON=1
 export WITH_GUI=1
-export QHULL_CFLAGS=-I/usr/include/qhull
+export QHULL_CFLAGS=-I/usr/include/libqhull
 export QHULL_LIBS=-lqhull
 export PYMCA_DATA_DIR=/usr/share/pymca
 export PYMCA_DOC_DIR=$(PYMCA_DATA_DIR)/doc

Bug#956463: ITP: golang-github-la5nta-wl2k-go -- A Winlink framework for Go

[Taowa Munene-Tardif]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Taowa Munene-Tardif 

* Package name: golang-github-la5nta-wl2k-go
  Version : 0.7.0-1
  Upstream Author : Martin Hebnes Pedersen
* URL : https://github.com/la5nta/wl2k-go
* License : Expat
  Programming Lang: Go
  Description : A Winlink framework for Go.

 wl2k-go is a collection of Go packages implementing various parts
 needed to build a Winlink client.

I wish to package wl2k-go so as to be able to package Pat.

Thanks,
Taowa Munene-Tardif

-- 
Taowa Munene-Tardif
taowa.ca
Montréal

Bug#956464: solr-tomcat: Unable to perform replication as slave

[Andy Beverley]

Package: solr-tomcat
Version: 3.6.2+dfsg-20+deb10u1
Severity: normal

Dear Maintainer,

Solr running under Tomcat is unable to perform replication as a slave.
This is because during replication it tries to create a temporary
directory within its configuration directory (normally /etc/solr/conf,
but could also be others if running multiple cores).

The problem is the same as that fixed in #919638, which is that even
if write permissions are temporarily given to that directory (as I have
done on previous systems) the sandbox still does not allow write access.

This is made worse by the poor error message that solr gives (not
specifying the error or full path). A day of debugging and rebuilding
the application was required to work out the cause!

I fixed the problem by adding the path to solr-permissions.conf as
below.


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

Versions of packages solr-tomcat depends on:
ii  solr-common  3.6.2+dfsg-20+deb10u1
ii  tomcat9  9.0.16-4

solr-tomcat recommends no packages.

solr-tomcat suggests no packages.

-- Configuration Files:
/etc/systemd/system/tomcat9.service.d/solr-permissions.conf changed:
[Service]
ReadWritePaths=/var/lib/solr/
ReadWritePaths=/etc/solr


-- no debconf information

Bug#840597: ITP: pyflame -- CPU profiler and flame graph tool for Python

[Manas Kashyap]

Control: retitle -1 RFP: pyflame -- CPU profiler and flame graph tool for
Python .

Bug#956461: saga: FTBFS with Qhull 2019.1

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Timo,

Thanks for the patch and forwarding it upstream. It's included in git
and will be uploaded after qhull 2019.1 is moved to unstable. Please
raise the severity of this issue to serious when you do.

Kind Regards,

Bas

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

Bug#947766: Cannot create mesh from shape

[Tobias Frost]

On Mon, 30 Dec 2019 13:34:38 +0100 (CET) victornem...@free.fr wrote:
> Package: freecad
> Version: 0.18.4+dfsg1-1
> 
> When I try to tesselate a shape, I get an empty mesh.
> In the status part, a red text appears: "name 'MeshPart' is not
defined".
> In the console, the following text appears: "name 'MeshPart' is not
definedname 'MeshPart' is not defined".
> I use debian testing.
> 
> 
Triaging this one, I came accross 
https://forum.freecadweb.org/viewtopic.php?t=16345, the last last post
says

with the introduction of the new SMESH a while ago MeshPart now depends
on the VTK library. This is a somewhat tricky dependency which is not
easy to meet on all Platforms. Hence it seems the OpenSuse guys
disabled all relevant modules like FEM and MeshPart. Currently things
need to be sorted out after this change, this may take a while. But I
think it is a good idea to inform the opensuse freecad maintainers of
the consequences of this disabling of th emodule.

(I did not check yet if the freecad package is using VTK)

Bug#955668: libgaminggear: FTBFS: pango-coverage.h:28:10: fatal error: hb.h: No such file or directory

[Pierre-Elliott Bécue]

Le vendredi 03 avril 2020 à 21:37:34+0200, Lucas Nussbaum a écrit :
> [snip]

libpango1.0-dev should depend on libharfbuzz-dev, but it doesn't. This
bug seems to be in src:pango1.0, and therefore I reassign it.

Dear pango1.0 maintainers, please fix the dependencies of
libpango1.0-dev.

With best regards,

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


signature.asc
Description: PGP signature

Bug#950501:

[Daniele Scasciafratte]

I am on queue for this :-)

Bug#937579: python-apt: Python2 removal in sid/bullseye

[Sandro Tosi]

> Oh yes, let's kill that Python 2 support, woohoo. Then I can move
> all those # type annotations into signatures proper.

Just want to point out that this could be achieved in 2 steps: first
just remove the binary package and all the python2 packaging
infrastructure (so we dont delay the py2removal effort), and then you
can refactor the code to take advantage of a python3-only codebase.

There are no more reverse dependencies of python-apt that need to be
taken care of (the remaining ones are already RC buggy packages and we
dont need to wait for them), so Julian please drop python-apt asap (to
be honest, i would prefer if we can move forward with this very
quickly, and not wait for 20.04 release on April 23).

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#956461: saga: FTBFS with Qhull 2019.1

[Timo Röhling]

Source: saga
Version: 7.3.0+dfsg-3
Severity: important
Tags: ftbfs, patch

Dear maintainer,

your package uses a deprecated include path for Qhull, which will no
longer build with the latest release. I took the liberty to report this
to upstream already.

Attached is a patch that will fix the build with the qhull package in
experimental.

--- a/src/tools/grid/grid_gridding/nn/delaunay.c
+++ b/src/tools/grid/grid_gridding/nn/delaunay.c
@@ -323,7 +323,7 @@
 //-
 #else /* USE_QHULL */
 
-#include 
+#include 
 
 /* returns 1 if a,b,c are clockwise ordered */
 static int cw(delaunay *d, triangle *t)

Bug#955438: grpc: libupb.so.9 is not installed in any binary package

[Pirate Praveen]

On 2020, ഏപ്രിൽ 11 9:44:07 PM IST, "László Böszörményi (GCS)"  
wrote:
>On Mon, Apr 6, 2020 at 2:02 PM Pirate Praveen
> wrote:
>> This patch makes the build successful.
>>
>>
>https://salsa.debian.org/debian/grpc/-/blob/buster-backports/debian/patches/no-link-upb.patch
> I still would be interested why it links with upb in your backport
>when in Sid it doesn't. Something is way different there.

ld (which comes from binutils is different there).

binutils 2.31.1-16 vs binutils 2.34.6

>> I think we can close this bug unless you want to purse removing upb
>> from source tree.
> That's my plan. At least upb is in the archives and will be migrated
>in five days.

OK.

>Regards,
>Laszlo/GCS

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#937579: python-apt: Python2 removal in sid/bullseye

[Sandro Tosi]

On Sat, Apr 11, 2020 at 7:01 AM Moritz Mühlenhoff  wrote:
>
> On Fri, Apr 10, 2020 at 07:00:50PM -0400, Sandro Tosi wrote:
> > > This is scheduled for 2.1.0, which should happen shortly. How fast
> > > do you want it?
> >
> > asap of course :) there are only 2 rdeps of pyflakes: python-apt and
> > autopkgtest, and the latter is gonna get fixed in the coming days.
>
> Why only pyflakes, though?

because pyflakes could be dropped right now if python-apt moves away
from it, which doesnt require any external work

> python-apt can be dropped as well, there are only
> four reverse dependencies of python-apt (ovirt-guest-agent, xdeb,
> mini-buildd and live-wrapper) which are all already RC-buggy and dropped
> from testing. (Plus a fifth, python-cdd, for which I've just filed an
> RM bug)

Yep, i worked last night to get all reverse dependencies of python-apt
addressed (the ones that count as many are not in testing because
already RC and can be ignored): now that python-debian dropped its
python support, Julian you can drop pyhton-apt binary package entirely
right away.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#956460: 3depict: FTBFS with Qhull 2019.1

[Timo Röhling]

Source: 3depict
Version: 0.0.22-1.2
Severity: important
Tags: ftbfs, patch

Dear maintainer,

your package uses a deprecated include path for Qhull, which will no
longer build with the latest release. I took the liberty to report this
to upstream already.

Attached is a patch that will fix the build with the qhull package in
experimental.

--- a/configure.ac
+++ b/configure.ac
@@ -140,8 +140,8 @@
 #Attempt to compile a test program
 CFLAGS_ORIG="$CFLAGS"
 CFLAGS="$CFLAGS $QHULL_CFLAGS"
-AC_CHECK_HEADER([qhull/qhull_a.h],[AC_DEFINE(HAVE_QHULL,[],[Have got libqhull headers])],
-	[AC_MSG_ERROR([Required libqhull headers not found (looking for qhull/qhull_a.h)])])
+AC_CHECK_HEADER([libqhull/qhull_a.h],[AC_DEFINE(HAVE_QHULL,[],[Have got libqhull headers])],
+	[AC_MSG_ERROR([Required libqhull headers not found (looking for libqhull/qhull_a.h)])])
 
 if test x"$with_libqhull_link" != x"" ;
 then
--- a/src/backend/filters/algorithms/convexHull.h
+++ b/src/backend/filters/algorithms/convexHull.h
@@ -40,7 +40,7 @@
 	#endif
 	extern "C"
 	{
-		#include 
+		#include 
 	}
 	#ifdef __POWERPC__
 		#pragma pop_macro("__POWERPC__")
--- a/src/backend/filters/algorithms/spatial.cpp
+++ b/src/backend/filters/algorithms/spatial.cpp
@@ -27,7 +27,7 @@
 #include 
 
 #if defined(__WIN64) && !defined(HAVE_SWEEP_HULL)
-#include 
+#include 
 #endif
 
 using std::vector;

Bug#927787: the new upstream does exist, but not where debian/watch is looking

[Rebecca N. Palmer]

Control: reopen -1

Upstream has moved to https://github.com/DataTables (see the base 
datatables.js package).  As well as the Bootstrap 4 styling option, 
there are two new extensions (RowGroup and SearchPanes), and probably 
other changes.


Each extension is now a separate upstream repository, but packaging them 
together is still an option:

https://wiki.debian.org/Javascript/GroupSourcesTutorial

snakemake uses the Bootstrap 4 version of datatables with 
Buttons,ColReorder,FixedHeader,JSZip,Responsive,Select; it currently 
downloads this at runtime rather than using the packaged versions.

Bug#955438: grpc: libupb.so.9 is not installed in any binary package

[GCS]

On Mon, Apr 6, 2020 at 2:02 PM Pirate Praveen  wrote:
> This patch makes the build successful.
>
> https://salsa.debian.org/debian/grpc/-/blob/buster-backports/debian/patches/no-link-upb.patch
 I still would be interested why it links with upb in your backport
when in Sid it doesn't. Something is way different there.

> I think we can close this bug unless you want to purse removing upb
> from source tree.
 That's my plan. At least upb is in the archives and will be migrated
in five days.

Regards,
Laszlo/GCS

Bug#956457: Enable wired authentication service

[Andreas Henriksson]

Hello Lars Beckers,

Thanks for your bug report.

On Sat, Apr 11, 2020 at 04:58:08PM +0200, Lars Beckers wrote:
> Package: iwd
> Version: 1.6-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> `iwd' provides a separate daemon, called `ead', for authentication on
> wired interfaces. One can use it e.g. with FreeRADIUS to secure access
> to a LAN. `wpa_supplicant' offers similar functionality.

FWIW I'm personally well aware of ead and its functionality.

> 
> Due to the software maintainer's primary focus on wireless,
> this feature was not yet declared a standard part and thus needs a
> special build-time switch to be set. My request is that you enable it.

I personally have no need/use for ead. I expect someone who does
to take care of it. Not only by sending an initial patch, but also
offer to take on the maintenance (as co-maintainer of the package?).

> 
> Because `ead' is a separate daemon, enabling this feature won't affect
> the stability of the wireless daemon for current users of this package.
> The README file of the project advises that the configuration option
> `--enable-wired' enables this feature. It does not advise against
> enabling it, but calls it "optional".

Whoever looks into this should also want to consider the pros and cons
of splitting iwd and ead in separate binary packages or not.

Regards,
Andreas Henriksson

Bug#956384: repository location

[Étienne Mollier]

The repository can be found on Salsa at:

https://salsa.debian.org/med-team/prinseq-lite/

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

Bug#954656: nyx: does not start/work

[Taowa Munene-Tardif]

Sorry for my previous messages, neomutt decided to send those messages
when I clicked "reply" in the BTS web interface :/.

On Sun, Mar 22, 2020 at 12:49:45PM +0100, Gordon Shumway wrote:
> Dear Maintainer,
> 
>* Starting nyx shows the same error as reported related to python3-stem 
> bug   #953863  
>* Installing upstream updates of stem and nyx directly from
>  torproject git does not help
>* Problem probably related to Python3.8-Upgrade

The fix to python3-stem in #953863 seems to have fixed this as well.

I believe this bug should be closed.

Thanks,
Taowa

-- 
Taowa Munene-Tardif
ta...@debian.org
taowa.ca
Montréal

Bug#954422: transition: GNOME 3.36

[David Mohammed]

budgie-desktop has now been transitioned to unstable.

thx

David

On Sat, 11 Apr 2020 at 13:42, Simon McVittie  wrote:
>
> On Fri, 10 Apr 2020 at 12:27:04 +0200, Emilio Pozuelo Monfort wrote:
> > Let's go ahead. The situation looks to be in a good state. Extensions have
> > always been treated this way, on a best effort basis during the 
> > transitions, so
> > we'll keep as many as we can but if any of them aren't compatible and don't 
> > get
> > updated in time we'll drop them from testing until they are fixed.
>
> The packages that trigger this transition (gjs, gnome-desktop3, mutter and
> gnome-shell) have now built on all release architectures (and apparently
> gnome-shell now passes its build-time tests on s390x again, although as
> before it's anyone's guess whether it works or is practically useful).
>
> Sub-transitions involved in this:
>
> https://release.debian.org/transitions/html/auto-mutter.html
> - budgie-desktop needs sourceful changes (#952639, fixed in experimental) -
>   David, please could you upload the changes from experimental into unstable?
> - gnome-shell-xrdesktop needs a new upstream release (#956147)
>
> https://release.debian.org/transitions/html/auto-gnome-desktop3.html
> - Should be ready to start binNMUs
> - Please binNMU xdg-desktop-portal-gtk in experimental too
> - No point in binNMUing budgie-desktop due to the mutter transition
> - No point in binNMUing gnome-shell-xrdesktop due to the mutter transition
>
> https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
> - -appindicator needs sourceful changes (#956451, fixed in experimental)
> - -easyscreencast needs sourceful changes (#956166)
>
> smcv

Bug#956455: RFS: smart-tools [ITP]

[Sao I Kuan]

Hi,

I'm looking for a sponsor for the package:
  * smart-open (#956455)

The packages are on:
https://salsa.debian.org/med-team/smart-open

The package is dependency of idseq-bench[1,2].

[1] https://github.com/chanzuckerberg/idseq-bench
[2] https://bugs.debian.org/956033

The package does have two issues:
* GCS: runtime dependencies are not packaged (google-cloud-storage
and its deps).
- I disabled the GCS related codes, and all the other tests
are works well.
- d/patches/exclude-gcs.patch
* S3: test dependencies not packaged (moto and its deps).
- I disabled the S3 related tests.
- d/patches/exclude-moto-s3-test.patch

Because of reverse dependency of this package (specially idseq-bench)
is only using the feature for local filesystems, GCS and S3 related
codes are unnecessary for now. So I disabled them. I mentioned this
issue in d/README.source.

I enabled all the tests not related with GCS and S3, are all passed
well. The package was tested on both gbp and sbuild, and
lintian-clean.

Please consider to review and sponsor this. Any kind of suggestions
are appreciated.

Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com