Bug#939716: debian-gis: replace/remove all python2 modules dependencies

[Sebastiaan Couwenberg]

Control: tags -1 pending
Control: severity -1 normal

On 9/8/19 5:37 AM, Sandro Tosi wrote:
> There's an on-going effort to remove Python 2 from Bullseye,
> https://wiki.debian.org/Python/2Removal, so it would be useful if you could
> remove all python2 modules dependencies from your tasks and/or migrate them to
> their relative python3 modules.

Already fixed in git for all packages that have a python3 variant, only
python-cf & python-geohash don't have one yet.

> This will help by removing reverse dependencies of those packages, easying 
> their
> removal from the distribution.

The metapackages don't have hard dependencies, so they don't block removal.

> Priority set to important as it's (possibly) preventing part of the progess on
> the py2removal effort.

Severity decreased because the metapackages don't prevent removal of
python2 packages.

Kind Regards,

Bas

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

Bug#836500: O: flask-principal -- identity management for Flask

[Scott Kitterman]

Still has users:

Checking reverse dependencies...
# Broken Depends:
flask-security: python3-flask-security

# Broken Build-Depends:
flask-security: python3-flask-principal

Dependency problem found.

Needs to be fixed before this can be removed.

Scott K

Bug#813246: Lib still has users

[Scott Kitterman]

Checking reverse dependencies...
# Broken Build-Depends:
freecad: libkdtree++-dev

Dependency problem found.

Needs to be fixed first.

Scott K

Bug#936552: freecad: Python2 removal in sid/bullseye

[Scott Kitterman]

Bumping to serious since freecad is build-depending on packages requested for 
removal.

Scott K

Bug#939718: gnome-shell: Crashes

[lucy]

Package: gnome-shell
Version: 3.30.2-9
Severity: normal

Dear Maintainer,


When I move any app icon from the panel to the bottom of the panel more than
once, the gnome-shell session is crashed, and returns me to gdm login.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-4~deb10u1
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4
ii  gir1.2-mutter-3  3.30.2-7
ii  gir1.2-nm-1.01.14.6-2
ii  gir1.2-nma-1.0   1.8.20-1.1
ii  gir1.2-pango-1.0 1.42.4-7~deb10u1
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-9
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1
ii  libedataserver-1.2-233.30.5-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-2+deb10u1
ii  libglib2.0-bin   2.58.3-2+deb10u1
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-7
ii  libnm0   1.14.6-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4+deb10u1
ii  libpulse012.2-4+deb10u1
ii  libsecret-1-00.18.7-1
ii  libstartup-notification0 0.12-6
ii  libsystemd0  241-7~deb10u1
ii  libx11-6 2:1.6.7-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.2-7
ii  python3  3.7.3-1

Versions of packages gnome-shell recommends:
ii  bolt  0.7-2
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.30.2-3
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.30.3-2~deb10u1
ii  gnome-user-docs   3.30.2-1
ii  iio-sensor-proxy  2.4-2
ii  switcheroo-control1.2-2
ii  unzip 6.0-23+deb10u1

Versions of packages gnome-shell suggests:
pn  gir1.2-telepathyglib-0.12   
pn  gir1.2-telepathylogger-0.2  

Bug#939717: Failure to install tjener if the first username is not full ASCII

[David Prévot]

Package: debian-edu-config
Version: 2.10.65
Severity: normal

Hi,

Providing non-ASCII characters in the first user name during d-i makes
the installation fail to set up correctly ldap and thus breaks all
usability of tjener (krb5, isc-dhcp and samba fail to start after the
installation, GOsa is not set up, one can’t login with the initial
credentials…).

Looking at /var/log/installer/syslog, it looks like the
ldap-debian-edu-install fails:

> cf-agent[…]: CFEngine(agent)  Executing 'no timeout' ... 
> '/usr/bin/ldap-debian-edu-install'
> cf-agent[…]: CFEngine(agent)  Finished command related to promiser 
> '/usr/bin/ldap-debian-edu-install' -- an error occurred, returned 1
> cf-agent[…]: CFEngine(agent)  Q: "...du-install": iconv: illegal input 
> sequence at position 1
> cf-agent[…]: CFEngine(agent)  Last 1 quoted lines were generated by promiser 
> '/usr/bin/ldap-debian-edu-install'
> cf-agent[…]: CFEngine(agent)  Completed execution of 
> '/usr/bin/ldap-debian-edu-install'

(the not failing log split more than two hundred lines, the first ones
starting with slapadd:).

Reproducing is easy, just using e.g., “tété” as user full name (the
preseed-like passwd/user-fullname string) makes a broken system.

Regards

David


signature.asc
Description: PGP signature

Bug#939716: debian-gis: replace/remove all python2 modules dependencies

[Sandro Tosi]

Source: debian-gis
Severity: important

Hello,
There's an on-going effort to remove Python 2 from Bullseye,
https://wiki.debian.org/Python/2Removal, so it would be useful if you could
remove all python2 modules dependencies from your tasks and/or migrate them to
their relative python3 modules.

This will help by removing reverse dependencies of those packages, easying their
removal from the distribution.

Priority set to important as it's (possibly) preventing part of the progess on
the py2removal effort.

Thanks,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#939505: bumblebee fails to disable discrete graphics card after upgrade nvidia driver to 430.40-2

[Mo Zhou]

same here.
reflink:
https://devtalk.nvidia.com/default/topic/1050786/linux/nvidia-drivers-430-09-causes-xorg-segfault-at-start-

Bug#939315: ITS: ledmon maintenance

[Jared.Dominguez]

ACK. Thanks Woodrow for taking this on.


From: Woodrow Shen (Shye-Tzeng Shen) 
Sent: Tuesday, September 3, 2019 04:59
To: Debian Bug Tracking System
Subject: Bug#939315: ITS: ledmon maintenance

[EXTERNAL EMAIL]

Package: ledmon
Followup-For: Bug #939315

Loop maintainer and related

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

Kernel: Linux 4.15.0-58-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to zh_TW.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#939715: manual upgrades prevented

[Karsten]

Package: plasma-discover
Version: 5.14.5.1-1
Severity: normal

Hello,

this process seems to prevent manual upgrades in a console.
How can this be deactivated?

# aptitude update
E: Konnte Sperre /var/lib/dpkg/lock nicht bekommen - open (11: Die Ressource 
ist zur Zeit nicht verfügbar)
E: Sperren des Administrationsverzeichnisses (/var/lib/dpkg/) nicht möglich, 
wird es von einem anderen Prozess verwendet?
W: Zwischenspeicher-Datei konnte nicht gesperrt werden. Das bedeutet in der 
Regel, dass dpkg oder ein anderes
APT-Werkzeug bereits Pakete installiert. Öffnen im Nur-Lesen-Modus. Alle 
Änderungen, die Sie am Status von Paketen
durchführen, werden VERLOREN gehen!
Treffer http://security.debian.org/debian-security buster/updates InRelease
Treffer http://ftp.debian.org/debian buster-backports InRelease
Treffer http://www.deb-multimedia.org buster InRelease
Treffer http://www.deb-multimedia.org buster-backports InRelease

Treffer http://ftp.de.debian.org/debian buster InRelease
Treffer http://ftp.de.debian.org/debian buster-updates InRelease
Treffer http://ftp.de.debian.org/debian buster-proposed-updates InRelease
100% [Arbeite]
Aktueller Status: 0 (-83) upgradable, 0 (-84953) new.
E: Konnte Sperre /var/lib/dpkg/lock nicht bekommen - open (11: Die Ressource 
ist zur Zeit nicht verfügbar)
E: Sperren des Administrationsverzeichnisses (/var/lib/dpkg/) nicht möglich, 
wird es von einem anderen Prozess verwendet?
E: Paket-Zwischenspeicher konnte nicht neu erzeugt werden


Cheers
karsten


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

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

Versions of packages plasma-discover depends on:
ii  appstream    0.12.5-1
ii  apt-config-icons 0.12.5-1
ii  kio  5.54.1-1
ii  libappstreamqt2  0.12.5-1
ii  libc6    2.28-10
ii  libkf5attica5    5.54.0-1
ii  libkf5configcore5    5.54.0-1+deb10u1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5coreaddons5    5.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons5    5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5itemmodels5    5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiowidgets5    5.54.1-1
ii  libkf5newstuffcore5  5.54.0-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5service-bin    5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5xmlgui5    5.54.0-1
ii  libpackagekitqt5-1   1.0.1-1
ii  libqt5core5a 5.11.3+dfsg1-1
...

Versions of packages plasma-discover recommends:
ii  apt-config-icons-large   0.12.5-1
ii  software-properties-kde  0.96.20.2-2

Versions of packages plasma-discover suggests:
pn  apt-config-icons-hidpi   
pn  plasma-discover-backend-flatpak  

-- no debconf information

Bug#918754: bash: $PATH in bash does not include /sbin and /usr/sbin

[Karsten]

Am 06.09.19 um 00:41 schrieb Markus Koschany:
> This is a new behavior because the util-linux implementation of su is
> used now. See also /usr/share/doc/util-linux/NEWS.Debian.gz for more
> information.
>
> "If you want to restore behaviour more similar to
>   the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs."
>
> Markus

Thanks.
My /etc/login.defs is now

#
# *REQUIRED*  The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH  
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH    PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
ALWAYS_SET_PATH yes


This seems to work.
But to solve the problem this should be added by default.
Then this bug can be closed.

Cheers
karsten

Bug#939662: 回复: Bug#939662 closed by Stephen Kitt (Re: Bug#939662: sys/mman.h not found)

[Zhang Hao]

Dear

Even though I use the parameter "--host=x86_64-w64-32", the gperftools makefile 
dos not passed.
And The gperftools support "mingw-w64" to cross compile on linux.
You can find it on "https://github.com/gperftools/gperftools/issues/878;.
And I have report this issue in 
"https://github.com/gperftools/gperftools/issues/1108;.
The developer told me this is a "#include ." issue, not gperftools' 
problem.




发件人: Debian Bug Tracking System 
发送时间: 2019年9月7日 23:48
收件人: Zhang Hao 
主题: Bug#939662 closed by Stephen Kitt  (Re: Bug#939662: 
sys/mman.h not found)

This is an automatic notification regarding your Bug report
which was filed against the mingw-w64 package:

#939662: sys/mman.h not found

It has been closed by Stephen Kitt .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Stephen Kitt 
 by
replying to this email.


--
939662: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939662
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#939714: linux-image-5.2.0-2-amd64: USB mouse stops working shortly after boot

[Constantin Makshin]

Package: src:linux
Version: 5.2.9-2
Severity: important

Sortly after starting the system and X Window the kernel reports a DMA
error (two messages at 70.5s) and USB mouse stops working despite its
light being turned on. Booting into 4.19.37-6 kernel on the same system
solves the problem.

-- Package-specific info:
** Version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 
root=UUID=712abf8f-4999-41af-b98e-caed36815485 ro rd.driver.blacklist=nouveau 
video=vesa:off nvidia-drm.modeset=1 quiet

** Tainted: PWOE (12801)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   11.415562] usbcore: registered new interface driver uas
[   11.445791] input: Microsoft X-Box 360 pad as 
/devices/pci:00/:00:1c.4/:03:00.0/usb3/3-1/3-1.1/3-1.1:1.0/input/input3
[   11.445904] usbcore: registered new interface driver xpad
[   11.534188] hidraw: raw HID events driver (C) Jiri Kosina
[   11.768811] systemd-udevd[450]: Process '/usr/sbin/alsactl -E HOME=/run/alsa 
restore 0' failed with exit code 99.
[   11.784133] usbcore: registered new interface driver usbhid
[   11.784134] usbhid: USB HID core driver
[   11.825219] input: Logitech USB Optical Mouse as 
/devices/pci:00/:00:1c.4/:03:00.0/usb3/3-1/3-1.4/3-1.4:1.0/0003:046D:C05B.0001/input/input4
[   11.825470] hid-generic 0003:046D:C05B.0001: input,hidraw0: USB HID v1.11 
Mouse [Logitech USB Optical Mouse] on usb-:03:00.0-1.4/input0
[   12.389644] scsi 8:0:0:0: Direct-Access Generic- SD/MMC/MS/MSPRO  1.00 
PQ: 0 ANSI: 4
[   12.390023] sd 8:0:0:0: Attached scsi generic sg3 type 0
[   12.395234] sd 8:0:0:0: [sdc] Attached SCSI removable disk
[   14.014309] r8169 :06:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168e-3.fw
[   14.014505] RTL8211E Gigabit Ethernet r8169-600:00: attached PHY driver 
[RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-600:00, irq=IGNORE)
[   14.199937] r8169 :06:00.0 eth0: Link is Down
[   14.761314] EXT4-fs (sda4): re-mounted. Opts: data=ordered,errors=remount-ro
[   15.138147] device-mapper: uevent: version 1.0.3
[   15.138208] device-mapper: ioctl: 4.40.0-ioctl (2019-01-18) initialised: 
dm-de...@redhat.com
[   16.340369] r8169 :06:00.0 eth0: Link is Up - 1Gbps/Full - flow control 
off
[   16.340379] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   16.882224] loop: module loaded
[   16.932114] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for 
UNIX platforms  430.40  Sun Jul 21 04:57:42 CDT 2019
[   17.032375] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver
[   17.656301] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   17.656302] [drm] No driver support for vblank timestamp query.
[   17.688572] [drm] Initialized nvidia-drm 0.0.0 20160202 for :01:00.0 on 
minor 0
[   17.963952] EXT4-fs (sdb5): mounted filesystem with ordered data mode. Opts: 
data=ordered
[   18.008420] EXT4-fs (sdb6): mounted filesystem with ordered data mode. Opts: 
data=ordered
[   18.069835] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: 
data=ordered
[   60.518396] [ cut here ]
[   60.518398] refcount_t: underflow; use-after-free.
[   60.518413] WARNING: CPU: 2 PID: 2199 at lib/refcount.c:190 
refcount_sub_and_test_checked+0x61/0x80
[   60.518413] Modules linked in: cpufreq_conservative cpufreq_powersave 
cpufreq_userspace binfmt_misc ip6t_REJECT nf_reject_ipv6 nft_counter xt_tcpudp 
ipt_REJECT nf_reject_ipv4 xt_comment xt_conntrack nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 libcrc32c nft_compat x_tables nf_tables nfnetlink nls_ascii 
nls_cp437 vfat fat nvidia_drm(POE) drm_kms_helper drm nvidia_modeset(POE) loop 
dm_crypt dm_mod hid_generic usbhid joydev hid xpad uas usb_storage ff_memless 
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp snd_ctxfi kvm_intel 
kvm snd_pcm nvidia(POE) r8169 snd_timer irqbypass crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel snd realtek aesni_intel sr_mod soundcore ehci_pci iTCO_wdt 
xhci_pci libphy ehci_hcd iTCO_vendor_support xhci_hcd cdrom mei_me usbcore 
aes_x86_64 i2c_i801 sg ipmi_devintf crypto_simd watchdog mei ipmi_msghandler 
cryptd usb_common lpc_ich glue_helper pcc_cpufreq mfd_core ie31200_edac 
intel_cstate intel_uncore video mxm_wmi wmi intel_rapl_perf efi_pstore efivars
[   60.518453]  button ext4 crc16 mbcache jbd2 crc32c_generic sd_mod ahci 
libahci libata scsi_mod crc32c_intel evdev serio_raw fan
[   60.518462] CPU: 2 PID: 2199 Comm: Xorg Tainted: P   OE 
5.2.0-2-amd64 #1 Debian 5.2.9-2
[   60.518463] Hardware name: Gigabyte Technology Co., Ltd. To be filled by 
O.E.M./Z77X-UD4H, BIOS F1 11/02/2012
[   60.518467] RIP: 0010:refcount_sub_and_test_checked+0x61/0x80
[   60.518469] Code: 92 c1 29 fa 85 c9 74 db 0f b6 05 d4 43 

Bug#939698: [pkg-php-pear] Bug#939698: lintian: warning about pkg-php-tools versioned dependency conflicts with cme suggestion

[David Prévot]

Le 07/09/2019 à 11:00, Antonio Ospite a écrit :
> Package: lintian
[…]
> one of my packages build-depends on pkg-php-tools, and I used to have
> that as a versioned dependency, as suggested by this lintian warning:
> 
> W: tweeper source: pear-package-feature-requires-newer-pkg-php-tools (>= 
> 1.7~) for Composer package support
> 
> However I found out that running `cme check dpkg` on said package
> suggests to remove the versioned dependency because it has become
> unnecessary:

It has become unnecessary since at least oldoldstable, so full ack. I’m
not the pkg-php-tools maintainer, just a member of the PHP PEAR (and
Composer) team taking care of ~100 of PHP library packages.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#939713: ifupdown: brctl dependency

[sergio]

Package: ifupdown
Version: 0.8.35+b1
Severity: normal

Dear Maintainer,

ifupdown depends on brctl, but should use ip instead

Bug#939712: performous-composer: missing Depends on libqt5multimedia5-plugins

[Thorsten Glaser]

Package: performous-composer
Version: 2.0+20181009-gitbeeea23-1
Severity: serious
Justification: dependencies incorrect

https://github.com/performous/composer/issues/36

↓

https://stackoverflow.com/a/22046880/2171120

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages performous-composer depends on:
ii  libavcodec58   7:4.1.4-1+b2
ii  libavformat58  7:4.1.4-1+b2
ii  libavutil567:4.1.4-1+b2
ii  libc6  2.28-10
ii  libgcc11:9.2.1-7
ii  libqt5core5a   5.11.3+dfsg1-4
ii  libqt5gui5 5.11.3+dfsg1-4
ii  libqt5multimedia5  5.11.3-2
ii  libqt5network5 5.11.3+dfsg1-4
ii  libqt5widgets5 5.11.3+dfsg1-4
ii  libqt5xml5 5.11.3+dfsg1-4
ii  libstdc++6 9.2.1-7
ii  libswresample3 7:4.1.4-1+b2
ii  libswscale57:4.1.4-1+b2

performous-composer recommends no packages.

performous-composer suggests no packages.

-- no debconf information

Bug#939711: phonon-backend-gstreamer-common: The package does not need to break the older (Qt4) version

[Luigi Toscano]

Package: phonon-backend-gstreamer-common
Version: 4:4.9.1-2
Severity: minor

Dear Maintainer,
as reported also by upstream, the two versions of phonon (Qt4 and Qt5)
can be installed at the same time.
https://mail.kde.org/pipermail/kde-distro-packagers/2019-August/000383.html

The current Break statement makes it impossible to install the old
version from stable, while it would be nice if it could very nice
if it would be allowed.

It may be argued that a change in the content of the the -common 
package

still may break the co-installability, but that package only contains
a few icons, so it should really not break the old package.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (850, 'testing'), (800, 'unstable'), (750, 
'experimental'), (750, 'stable'), (500, 'unstable-debug'), (500, 
'stable-debug'), (500, 'oldstable-debug'), (500, 'buildd-unstable'), 
(500, 'oldstable'), (1, 'experimental-debug')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

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

phonon-backend-gstreamer-common depends on no packages.

phonon-backend-gstreamer-common recommends no packages.

Versions of packages phonon-backend-gstreamer-common suggests:
ii  phonon-backend-gstreamer  4:4.9.1-1
ii  phonon4qt5-backend-gstreamer  4:4.9.1-1

-- no debconf information

--


Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a 
soli 7,99€ al mese. L'attivazione è gratis e disdici quando vuoi. 
http://tisca.li/smart30

Bug#875160: [qthid-fcd-controller] Future Qt4 removal from Buster

[A. Maitland Bottoms]

On Sat, 7 Sep 2019 22:44:00 +0200
Moritz Mühlenhoff  wrote: 
> Hi Maitland,
> we're moving forward with the Qt4 removal.
> 
> qthid-fcd-controller seems dead upstream, are you planning to port it
> yourself or shall we remove it from the archive?
> 
> Cheers,
> Moritz

Yeah, I have tried to get other people to do it.
Thanks to your email, I am starting to port it myself.
(I have gotten other Qt4 code to build under Qt5, so I can no longer
claim ignorance.)

Give me until the end of the month? If I cannot do it myself this
weekend, I might get someone at the GNU Radio conference to do it the
week after next. (Some folk there got gnuradio from qt4 to qt5.)

How hard can it be?

Thanks for the prompting,
-Maitland

Bug#939710: RM: slides -- RoQA; 15 years old release; python2-only; orphaned; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#939559: x86_64-w64-mingw32-g++-win32: program compiled with -march=native crashes on same CPU

[Bernhard Übelacker]

Hello Stephen, hello Claude,
following that previous idea of just replacing the aligned
instruction with the unaligned one the hacky patch below got
created, just replacing vmovapd by vmovupd.
Not considering any side effects and maybe other
instructions with alignment requirements.
At least a mingw-w64 built with it builds an executable that
would not crash in that situation.
(Currentyl just meant as a proof of concept.)
Maybe at least better than disabling AVX2 entirely?

Kind regards,
Bernhard
--- a/src/gcc/config/i386/i386.md	2019-09-07 15:04:12.391156632 +0200
+++ b/src/gcc/config/i386/i386.md	2019-09-07 15:07:17.316822891 +0200
@@ -3521,9 +3521,9 @@
 	case MODE_V4SF:
 	  return "%vmovaps\t{%1, %0|%0, %1}";
 	case MODE_V8DF:
-	  return "vmovapd\t{%g1, %g0|%g0, %g1}";
+	  return "vmovupd\t{%g1, %g0|%g0, %g1}";
 	case MODE_V2DF:
-	  return "%vmovapd\t{%1, %0|%0, %1}";
+	  return "%vmovupd\t{%1, %0|%0, %1}";
 
 	case MODE_V2SF:
 	  gcc_assert (!TARGET_AVX);
--- a/src/gcc/config/i386/sse.md	2019-09-07 15:04:12.399156531 +0200
+++ b/src/gcc/config/i386/sse.md	2019-09-07 15:07:09.420922575 +0200
@@ -1004,7 +1004,7 @@
 		return "vmovaps\t{%g1, %g0|%g0, %g1}";
 	  case MODE_V4DF:
 	  case MODE_V2DF:
-		return "vmovapd\t{%g1, %g0|%g0, %g1}";
+		return "vmovupd\t{%g1, %g0|%g0, %g1}";
 	  case MODE_OI:
 	  case MODE_TI:
 		return "vmovdqa64\t{%g1, %g0|%g0, %g1}";
@@ -1031,7 +1031,7 @@
 	  || misaligned_operand (operands[1], mode))
 	return "%vmovupd\t{%1, %0|%0, %1}";
 	  else
-	return "%vmovapd\t{%1, %0|%0, %1}";
+	return "%vmovupd\t{%1, %0|%0, %1}";
 
 	case MODE_OI:
 	case MODE_TI:
@@ -18952,11 +18952,11 @@
 	case MODE_V16SF:
 	  return "vmovaps\t{%1, %t0|%t0, %1}";
 	case MODE_V8DF:
-	  return "vmovapd\t{%1, %t0|%t0, %1}";
+	  return "vmovupd\t{%1, %t0|%t0, %1}";
 	case MODE_V8SF:
 	  return "vmovaps\t{%1, %x0|%x0, %1}";
 	case MODE_V4DF:
-	  return "vmovapd\t{%1, %x0|%x0, %1}";
+	  return "vmovupd\t{%1, %x0|%x0, %1}";
 	case MODE_XI:
 	  if (which_alternative == 2)
 	return "vmovdqa\t{%1, %t0|%t0, %1}";

Bug#935753: FATAL:memory_linux.cc Out of memory

[Michael Gilbert]

control: tag -1 moreinfo

> #4  0x58e64e4d in base::(anonymous 
> namespace)::OnNoMemorySize(unsigned long) [clone .constprop.237] ()
> #5  0x58ef0c85 in calloc ()
> #6  0x7fffaa96c7e9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> #7  0x7fffaa45f4b9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> #8  0x7fffaa4cd4b4 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> #9  0x7fffd87ca1b5 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
> #10 0x7fffd87b6ec9 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
> #11 0x7fffd87b2a64 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
> #12 0x7fffd87b2fde in ?? () from 
> /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
> #13 0x5981d413 in 
> gl::RealGLXApi::glXQueryExtensionsStringFn(_XDisplay*, int) ()
[...]
>  ii  libgl1-mesa-dri19.2.0~rc1-1

I wasn't able to reproduce your problem by upgrading packages to
experimental.  However, given
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so is involved in the
backtrace, mesa 19.2.0~rc1 from experimental is most likely the cause.

Since I couldn't reproduce it on my system, it is probably specific to
your hardware.  Could you try updating all of your mesa packages back
to experimental and try again?

Please also install libgl1-mesa-dri-dbgsym beforehand so we can see
what is going on in the ?? parts of the backtrace.

Best wishes,
Mike

Bug#939673: lintian: test failure with new gzip?

[Felix Lechner]

Control: tag -1 + pending

Hi Gianfranco,

On Sat, Sep 7, 2019 at 8:39 AM Gianfranco Costamagna
 wrote:
>
> Hello, somebody in ubuntu uploaded the new gzip 1.10 and now we have this 
> test failure:
>
> # Missing tags:
> #   package-contains-timestamped-gzip

According to the changelog for gzip, the timestamps are no longer issued.

> * Noteworthy changes in release 1.10 (2018-12-29) [stable]
>
>   Compressed gzip output no longer contains the current time as a
>   timestamp when the input is not a regular file.  Instead, the output
>   contains a null (zero) timestamp.  This makes gzip's behavior more
>   reproducible when used as part of a pipeline.  (As a reminder, even
>   regular files will use null timestamps after the year 2106, due to a
>   limitation in the gzip format.)

I moved the relevant functionality from the test 'files-general' to a
new test 'timestamp-in-piped-gzip' and limited the latter to gzip <<
1.10.

> This started with 2.20.0 with commit 
> ea2fac33c4c21d185430c48e387ad198cc0c1436, the first release with the new 
> timestamped-gzip test...

The problem no longer occurs past commit 74137cac. I tested it by
installing gzip 1.10 from Ubuntu.

Thank you for reporting the issue so early. That version of 'gzip' is
not even in Debian yet.

Kind regards,
Felix Lechner

Bug#939709: RM: archipel-agent-xmppserver -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939707: RM: archipel-agent-virtualmachine-oomkiller -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939706: RM: archipel-agent-virtualmachine-snapshoting -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939708: RM: archipel-agent-iphone-notification -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939705: RM: archipel-agent-vmcasting -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939704: faust: libOSCFaust.a is missing?

[Lukas Degener]

Package: faust
Version: 2.15.11~ds1-1
Severity: normal

Dear Maintainer,

When I tried to build a stand-alone Faust application with OSC-Support, I
encountered the following issue:

I created a trivial Faust-program:

import("stdfaust.lib");
declare options "[osc:on]";
process = _;

When I try to compile this program with OSC support, I get an error:

lukas@rumburak:~/src/faustxp$ faust2jaqt -osc trivial.dsp
/usr/bin/ld: cannot find -lOSCFaust
collect2: error: ld returned 1 exit status
make: *** [Makefile:148: trivial] Fehler 1

I tried the same after building the latest upstream release from source
(taken from here: https://github.com/grame-cncm/faust/releases).
In both cases, its the same release 2.15.11.
With the upstream version the above works as expected.

I noted that the file $PREFIX/lib/libOSCFaust.a does exist when I build from
source, but is not present when installing the Debian package. Maybe something
missing in some build script?

There is a related issue in the upstream bug tracker:
https://github.com/grame-cncm/faust/issues/324

Please let me know if you need further information.

TIA + Kind regards,

Lukas Degener



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages faust depends on:
ii  faust-common  2.15.11~ds1-1
ii  libc6 2.28-10
ii  libgcc1   1:9.2.1-6
ii  libllvm7  1:7.0.1-9+b1
ii  libstdc++69.2.1-6

Versions of packages faust recommends:
ii  clang 1:8.0-48
ii  g++   4:9.2.1-3
ii  libc6-dev [libc-dev]  2.28-10
ii  libgtk2.0-dev 2.24.32-3
ii  libjack-jackd2-dev [libjack-dev]  1.9.12~dfsg-2+b1
ii  make  4.2.1-1.2
ii  python2.7.16-1
ii  ruby  1:2.5.1

Versions of packages faust suggests:
pn  kate  

-- no debconf information

Bug#827314: note for future readers

[Jeffrey Cliff]

that 'feather' client they are recommending instead appears to be a
fork/branch of parity ( #890550 )

Bug#939703: sh4: cmake: "Detecting CXX compile features - failed"

[Hilmar Preusse]

Package: g++-9
Version: 9.2.1-7
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Recently I uploaded a new package of texworks to unstable. I noticed that
the new package fails to build on sh4 [1], meanwhile it built fine in the
past [2]. The relevant error message is (AFAICT):


-- Detecting CXX compile features
CMake Error: Generator: execution of make failed. Make command was: 
"/usr/bin/make" "cmTC_bf641/fast"
-- Detecting CXX compile features - failed
-- Git commit info updated
CMake Warning (dev) at CMakeLists.txt:139 (OPTION):
  Policy CMP0077 is not set: option() honors normal variables.  Run "cmake
  --help-policy CMP0077" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  For compatibility with older versions of CMake, option is clearing the
  normal variable 'BUILD_SHARED_LIBS'.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:146 (OPTION):
  Policy CMP0077 is not set: option() honors normal variables.  Run "cmake
  --help-policy CMP0077" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  For compatibility with older versions of CMake, option is clearing the
  normal variable 'BUILD_SHARED_PLUGINS'.
This warning is for project developers.  Use -Wno-dev to suppress it.


The only change in the new package is the python3 adaption, which should be
not relevant for that error message. The only significant change in the build
tools is that we now use g++-9 instead of g++-8.

I suspect this is a regression in g++-9.

Hilmar

[1] 
https://buildd.debian.org/status/fetch.php?pkg=texworks=sh4=0.6.3-3=1567811521=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=texworks=sh4=0.6.3-2=1562792310=0
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-2-amd64 (SMP w/1 CPU core)
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 g++-9 depends on:
ii  gcc-99.2.1-7
ii  gcc-9-base   9.2.1-7
ii  libc62.28-10
ii  libgmp10 2:6.1.2+dfsg-4
ii  libisl19 0.20-2
ii  libmpc3  1.1.0-1
ii  libmpfr6 4.0.2-1
ii  libstdc++-9-dev  9.2.1-7
ii  zlib1g   1:1.2.11.dfsg-1+b1

g++-9 recommends no packages.

Versions of packages g++-9 suggests:
pn  g++-9-multilib
pn  gcc-9-doc 
pn  libstdc++6-9-dbg  

-- no debconf information

Bug#939701: RM: archipel-agent-vmparking -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939700: RM: archipel-agent-virtualmachine-vnc -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939699: RM: archipel-core -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#925624: [Debichem-devel] Bug#925624: Bug#925624: abinit: ftbfs with GCC-9

[Michael Banck]

Hi,

On Sat, Sep 07, 2019 at 10:50:34PM +0200, Michael Banck wrote:
> > Program received signal SIGSEGV: Segmentation fault - invalid memory 
> > reference.
> > 
> > Backtrace for this error:
> > #0  0x7f063149eb40 in ???
> > #1  0x7f063149dd75 in ???
> > #2  0x7f063115893f in ???
> > #3  0x5612b98bb243 in forces_
> > at /<>/src/67_common/forces.F90:462
> 
> So at that line we have:
> 
> | if (usefock==1 .and. associated(fock).and.fock%fock_common%optfor) then
> 
> and if I step through that function with gdb, usefock is 0 (while fock
> is pointing to 0x0).
> 
> If I comment out the above if block (plus two more pretty much identical
> ones in m_forstr.F90 and m_stress.F90) most of the tests run fine (I
> guess the other ones really do need fock).
> 
> I am a bit baffled why gfortran compiles this in such a way (at -g
> without any -O as well) that we get a segfault here. I now tried with
> FCFLAGS='-g -O2' and then the test suite runs fine, so reassigning to
> gfortran-9 for now, do you have an idea what's going on?
> 
> (I filed this one upstream as well:
> https://github.com/abinit/abinit/issues/25)

So it appears that fock%fock_common%optstr cannot be guaranteed not to
be evaluated after associated(fock) is false as the Fortran language
apparently does not define short-circuit beahviour, see
https://www.scivision.dev/fortran-short-circuit-logic/

That explains why it works fine at -O2 (and would as well at -O1 in
gfortran), but crashed in -O0. I wonder why it built fine at -O0 in
stable though, it might be that the gfortran behaviour has been changed
recently.

I guess the fix would be to have two ifs here, like:

| if (usefock==1 .and. associated(fock)) then
|   if (fock%fock_common%optfor) then
| grtn(:,:)=grtn(:,:)+fock%fock_common%forces(:,:)
|   end if
| end if

I've uploaded abinit with FCFLAGS=-O2 now, should we close this bug and
leave it to the abinit maintainers to fix it properly, or do you want to
reassign it back?

Thanks to juliank for pointing me to the potential short-circuit logic
issue.


Michael

Bug#939698: lintian: warning about pkg-php-tools versioned dependency conflicts with cme suggestion

[Antonio Ospite]

Package: lintian
Version: 2.20.0
Severity: wishlist

Dear Maintainer,

one of my packages build-depends on pkg-php-tools, and I used to have
that as a versioned dependency, as suggested by this lintian warning:

W: tweeper source: pear-package-feature-requires-newer-pkg-php-tools (>= 1.7~) 
for Composer package support

However I found out that running `cme check dpkg` on said package
suggests to remove the versioned dependency because it has become
unnecessary:

---
Warning in 'control source Build-Depends:1': unnecessary greater-than versioned 
dependency: pkg-php-tools (>= 1.7~). Debian has oldoldstable -> 1.28; oldstable 
-> 1.35; stable -> 1.37; unstable -> 1.37; testing -> 1.37;
Offending value: 'pkg-php-tools (>= 1.7~)'
---

So maybe the lintian warning has become outdated?

A comment from the Debian PHP maintainer would be useful to sort this
out and decide whether to drop the warning from lintian.

CCing: Debian PHP PEAR Maintainers 

Thanks,
   Antonio

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.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 depends on:
ii  binutils 2.32.51.20190821-2
ii  bzip21.0.8-2
ii  diffstat 1.62-1+b1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b1
ii  libarchive-zip-perl  1.64-1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-1
ii  man-db   2.8.7-3
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#939697: "b44: swiotlb buffer is full" kernel log spam on Dell Inspiron 6400 wired NIC with kernel 5.2

[Tom Maneiro]

Package: src:linux
Version: 5.2.9-2~bpo10+1
Severity: normal

Recently I checked out the latest kernel packages from Backports for my Dell
Inspiron 6400 laptop, which ships with the following Broadcom wired NIC:

03:00.0 Ethernet controller: Broadcom Inc. and subsidiaries BCM4401-B0 100Base-
TX (rev 02)

I've never had problems with this NIC, been using it with kernels as old as
2.6.9. It works just fine with the default Debian Stable kernel (which is 4.19
on Buster). But with 5.2, I get my kernel log spammed with this every time
there is network traffic on the wired NIC (I don't use wireless on this
system):

[   67.862996] swiotlb_tbl_map_single: 20 callbacks suppressed
[   67.863001] b44 :03:00.0: swiotlb buffer is full (sz: 233 bytes), total
0 (slots), used 0 (slots)
[   67.863101] b44 :03:00.0: swiotlb buffer is full (sz: 213 bytes), total
0 (slots), used 0 (slots)
[   68.114649] b44 :03:00.0: swiotlb buffer is full (sz: 233 bytes), total
0 (slots), used 0 (slots)
[   68.114767] b44 :03:00.0: swiotlb buffer is full (sz: 213 bytes), total
0 (slots), used 0 (slots)
[   68.274933] b44 :03:00.0: swiotlb buffer is full (sz: 65 bytes), total 0
(slots), used 0 (slots)
[   68.366103] b44 :03:00.0: swiotlb buffer is full (sz: 324 bytes), total
0 (slots), used 0 (slots)
[   68.366261] b44 :03:00.0: swiotlb buffer is full (sz: 328 bytes), total
0 (slots), used 0 (slots)
[   69.390771] b44 :03:00.0: swiotlb buffer is full (sz: 324 bytes), total
0 (slots), used 0 (slots)
[   69.390953] b44 :03:00.0: swiotlb buffer is full (sz: 328 bytes), total
0 (slots), used 0 (slots)
[   70.682433] b44 :03:00.0: swiotlb buffer is full (sz: 93 bytes), total 0
(slots), used 0 (slots)

I even get a stacktrace during boot (most likely during DHCP negotiation?)
[   51.467502] swiotlb_tbl_map_single: 2 callbacks suppressed
[   51.467507] b44 :03:00.0: swiotlb buffer is full (sz: 1566 bytes), total
0 (slots), used 0 (slots)
[   51.467526] WARNING: CPU: 1 PID: 552 at kernel/dma/direct.c:43
report_addr+0x33/0x60
[   51.467527] Modules linked in: bnep binfmt_misc fuse btusb btrtl btbcm
btintel bluetooth arc4 rt2800pci rt2800mmio drbg rt2800lib rt2x00pci ansi_cprng
rt2x00mmio ecdh_generic rt2x00lib ecc mac80211 snd_hda_codec_hdmi cfg80211
snd_hda_codec_idt snd_hda_codec_generic eeprom_93cx6 r852 crc_ccitt sm_common
nand snd_hda_intel pktcdvd snd_hda_codec nand_ecc bch nandcore snd_hda_core mtd
snd_hwdep snd_pcm_oss dell_laptop r592 ledtrig_audio coretemp snd_mixer_oss
rfkill memstick iTCO_wdt kvm_intel iTCO_vendor_support snd_pcm kvm watchdog
irqbypass sg dell_wmi pcc_cpufreq snd_timer dell_smbios snd dcdbas acpi_cpufreq
soundcore rng_core evdev joydev sparse_keymap dell_wmi_descriptor wmi_bmof
pcspkr serio_raw battery ac uinput vhba(OE) nfsd dell_smm_hwmon auth_rpcgss
loop nfs_acl lockd parport_pc ppdev grace lp sunrpc parport ip_tables x_tables
autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_generic usbhid hid sr_mod
cdrom sd_mod ata_generic ata_piix libata b44 ehci_pci uhci_hcd ehci_hcd ssb
[   51.467587]  scsi_mod sdhci_pci cqhci mii usbcore sdhci libphy psmouse
mmc_core radeon i2c_i801 firewire_ohci firewire_core crc_itu_t pcmcia lpc_ich
mfd_core pcmcia_core i2c_algo_bit ttm drm_kms_helper drm usb_common wmi button
video
[   51.467609] CPU: 1 PID: 552 Comm: NetworkManager Tainted: G   OE
5.2.0-0.bpo.2-amd64 #1 Debian 5.2.9-2~bpo10+1
[   51.467611] Hardware name: Dell Inc. MM061
/0XD720, BIOS A17 06/13/2007
[   51.467614] RIP: 0010:report_addr+0x33/0x60
[   51.467617] Code: 48 8b 87 28 02 00 00 48 89 34 24 48 85 c0 74 2d 4c 8b 00
b8 fe ff ff ff 49 39 c0 76 14 80 3d cf 03 02 01 00 0f 84 59 05 00 00 <0f> 0b 48
83 c4 08 c3 48 83 bf 38 02 00 00 00 74 ef eb e0 80 3d b0
[   51.467620] RSP: 0018:b3208112f518 EFLAGS: 00010246
[   51.467622] RAX: fffe RBX: 9e10fbb2e0b0 RCX:

[   51.467624] RDX: 061e RSI: b8497880 RDI:
9e10fbb2e0b0
[   51.467626] RBP: 061e R08: 3fff R09:
0069
[   51.467628] R10:  R11: b3208112f1d0 R12:

[   51.467630] R13:  R14: 9e10743f28c0 R15:
9e10746e7a00
[   51.467633] FS:  7fb32de70b80() GS:9e10fc90()
knlGS:
[   51.467635] CS:  0010 DS:  ES:  CR0: 80050033
[   51.467637] CR2: 55b08e607928 CR3: b5e42000 CR4:
06e0
[   51.467639] Call Trace:
[   51.467647]  dma_direct_map_page+0xd6/0xf0
[   51.467654]  b44_alloc_rx_skb+0x279/0x3d0 [b44]
[   51.467659]  b44_init_rings+0xad/0x180 [b44]
[   51.467662]  b44_open+0xf7/0x3e0 [b44]
[   51.467667]  __dev_open+0xcd/0x160
[   51.467670]  __dev_change_flags+0x1ad/0x220
[   51.467673]  dev_change_flags+0x21/0x60
[   51.467677]  do_setlink+0x322/0xe90
[   51.467697]  ? ata_bmdma_qc_issue+0x7e/0x120 [libata]
[   51.467708]  ? ata_qc_issue+0x103/0x240 [libata]
[   51.467712]  ? cpumask_next+0x16/0x20
[   

Bug#875494: connectomeviewer: Qt4 removal form Buster

[Moritz Mühlenhoff]

On Sat, Aug 24, 2019 at 08:19:02PM -0400, Scott Kitterman wrote:
> On Mon, 11 Sep 2017 16:33:30 -0300 =?utf-8?q?
> Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=  wrote:
> > Source: connectomeviewer
> > Version: 2.1.0-1.1
> > Severity: minor
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> > 
> > Note: this bug is being filled because your package recommends python-
> qscintilla2.
> > 
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as announced in:
> > 
> > [announced]
> > 
> 
> This is now in progress.  Upstream for this package seems dead (no commits in 
> upstream git in nearly two years).  It seems likely the right answer is 
> probably to remove the package.
> 
> This is the last package left in the archive that needs python-qscintilla2.
> 
> If no one indicates they are going to upload this without the python-
> qscintilla2 Recommends (I have no idea if that even makes sense), then I'll 
> file an QoRA rm bug soon.

Given that there was no further feedback, 
https://github.com/LTS5/connectomeviewer/
has no signs of Qt5 porting activity and the last maintainer upload was in 2012
I just filed a removal bug so that we can move forward with qscintilla2.

There's still ample time to re-introduced it before bullseye if someone steps
up and ports it.

Cheers,
Moritz

Bug#939695: RM: archipel-agent-hypervisor-network -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939692: RM: archipel-agent-action-scheduler -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939693: RM: archipel-agent-hypervisor-geolocalization -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939694: RM: archipel-agent-hypervisor-health -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939696: RM: archipel-agent-hypervisor-platformrequest -- ROM; python2-only; dead upstream; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Hello,
please remove this packages, part of the archipel ecosystem.
Its mantainer agrees with the removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939628#10

Thanks,
Sandro

Bug#939691: RM: connectomeviewer -- RoQA; depends on qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Pleasr remove connectomeviewer. It depends on Qt4 which is going
away and there's no activity to port it by upstream.

Cheers,
Moritz

Bug#939628: should archipel-* packages be removed from Debian?

[Sandro Tosi]

>  I'm in a rush now but will try to file the RM bug(s) today or if you
> may have more time please do it yourself.

no worries, i'm gonna file the RM bugs now -- thanks!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#939690: libasound2-plugins:amd64: HDMI plugin missing

[Simon Richter]

Package: libasound2-plugins
Version: 1.1.8-1
Severity: normal

Hi,

aplay -L reports that I have two HDMI audio channels:

hdmi:CARD=PCH,DEV=0
HDA Intel PCH, HDMI 0
HDMI Audio Output
hdmi:CARD=PCH,DEV=1
HDA Intel PCH, HDMI 1
HDMI Audio Output

That is indeed correct, but trying to use them I end up with

alsa-lib: dlmisc.c:287:(snd1_dlobj_cache_get) Cannot open shared library
  /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_hdmi.so ((null):
  /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_hdmi.so: cannot
  open shared object file: No such file or directory)

It seems the plugin is missing here. The normal audio device works in some
configurations, but has no information on the capabilities of the connected
device.

   Simon

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libasound2-plugins:amd64 depends on:
ii  libasound21.1.8-1
ii  libavcodec58  7:4.1.4-1~deb10u1
ii  libavresample47:4.1.4-1~deb10u1
ii  libavutil56   7:4.1.4-1~deb10u1
ii  libc6 2.28-10
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libpulse0 12.2-4
ii  libsamplerate00.1.9-2

libasound2-plugins:amd64 recommends no packages.

libasound2-plugins:amd64 suggests no packages.

-- no debconf information

Bug#875184: [sofa-framework] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:10:03PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: sofa-framework
> Version: 1.0~beta4-12
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

The current releases on https://github.com/sofa-framework claim to be Qt5
compatible. Is anyone working on updating the package or should it be removed?

sofa-framework is one of the three remaining reverse dependencies of
libqwt5-qt4-dev at this point.

Cheers,
Moritz

Bug#875160: [qthid-fcd-controller] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:07:58PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: qthid-fcd-controller
> Version: 4.1-3
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

Hi Maitland,
we're moving forward with the Qt4 removal.

qthid-fcd-controller seems dead upstream, are you planning to port it yourself
or shall we remove it from the archive?

Cheers,
Moritz

Bug#925624: [Debichem-devel] Bug#925624: abinit: ftbfs with GCC-9

[Michael Banck]

reassign 925624 gfortran-9
thanks

Hi Matthias,

On Wed, Mar 27, 2019 at 07:43:54PM +, Matthias Klose wrote:
> Command   /<>/src/98_main/abinit <
> /<>/tests/Test_suite/fast_t30/t30.stdin >
> /<>/tests/Test_suite/fast_t30/t30.stdout 2>
> /<>/tests/Test_suite/fast_t30/t30.stderr returned
> exit_code: 139
> 
> [fast][t30][np=1]: fldiff.pl fatal error:
> The diff analysis cannot be done: the number of lines to be analysed differ.
> File /<>/tests/fast/Refs/t30.out: 399 lines, 44 ignored
> File /<>/tests/Test_suite/fast_t30/t30.out: 397 lines, 43 
> ignored [file=t30.out]
> [fast][t30][np=1]Test was not expected to fail but subprocesses returned 
> 139
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
> 
> Backtrace for this error:
> #0  0x7f063149eb40 in ???
> #1  0x7f063149dd75 in ???
> #2  0x7f063115893f in ???
> #3  0x5612b98bb243 in forces_
>   at /<>/src/67_common/forces.F90:462

So at that line we have:

| if (usefock==1 .and. associated(fock).and.fock%fock_common%optfor) then

and if I step through that function with gdb, usefock is 0 (while fock
is pointing to 0x0).

If I comment out the above if block (plus two more pretty much identical
ones in m_forstr.F90 and m_stress.F90) most of the tests run fine (I
guess the other ones really do need fock).

I am a bit baffled why gfortran compiles this in such a way (at -g
without any -O as well) that we get a segfault here. I now tried with
FCFLAGS='-g -O2' and then the test suite runs fine, so reassigning to
gfortran-9 for now, do you have an idea what's going on?

(I filed this one upstream as well:
https://github.com/abinit/abinit/issues/25)


Michael

Bug#939387: Please provide a way to rebuild the package with debian/changelog-only changes

[Chris Lamb]

Hi Mattia,

> > FYI I had to do something similar recently in src:xtrlock:
> > 
> > https://salsa.debian.org/debian/xtrlock/commit/eb0b4174c81fdb1b81926203af3bb8c7c34fdac9
> > 
> > Mattia, fancy implementing this? I believe you wrote the current
> > version check code.
> 
> i.e. just making sure the d/changelog version starts with the same
> string in diffoscope/__init__.py?

My change to xtrlock actually plays it safer than this and splits around
"+" on the basis that one is either doing a "+b1" or a "+localsuffix".

The danger of not doing this and taking the naive approach is that,
after all, "1" is a string prefix of "10"...


Regards,

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

Bug#901398: Acknowledgement (bbdb: remove this package?)

[David Bremner]

I've upload version 3.0 to experimental/7. This changes the maintainer (to
the debian emacsen addons team), converts to a a dependency package.

Assuming this doesn't explode too badly, I'll work with bap to merge the
bbdb3 source package into this one, and presumably switch to dh-elpa.

NMU diff (with git diff -D) follows

diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index 8fb91c4..000
diff --git a/.gitmodules b/.gitmodules
deleted file mode 100644
index 16fe08e..000
diff --git a/ChangeLog b/ChangeLog
deleted file mode 100644
index 740f47c..000
diff --git a/INSTALL b/INSTALL
deleted file mode 100644
index 9cba073..000
diff --git a/Makefile.in b/Makefile.in
deleted file mode 100644
index 920aa4c..000
diff --git a/README b/README
deleted file mode 100644
index 293205e..000
diff --git a/aclocal.m4 b/aclocal.m4
deleted file mode 100644
index c403f9d..000
diff --git a/bits/README b/bits/README
deleted file mode 100644
index cc941db..000
diff --git a/bits/bbdb-adapt-ispell.el b/bits/bbdb-adapt-ispell.el
deleted file mode 100644
index e374537..000
diff --git a/bits/bbdb-anniv.el b/bits/bbdb-anniv.el
deleted file mode 100644
index 9e6205d..000
diff --git a/bits/bbdb-canonicalize-lt.el b/bits/bbdb-canonicalize-lt.el
deleted file mode 100644
index bb3d9c0..000
diff --git a/bits/bbdb-edit.el b/bits/bbdb-edit.el
deleted file mode 100644
index b22f308..000
diff --git a/bits/bbdb-filters/COPYING.LIB b/bits/bbdb-filters/COPYING.LIB
deleted file mode 100644
index eb685a5..000
diff --git a/bits/bbdb-filters/README b/bits/bbdb-filters/README
deleted file mode 100644
index a88c2fc..000
diff --git a/bits/bbdb-filters/bbdb-ccmail.el b/bits/bbdb-filters/bbdb-ccmail.el
deleted file mode 100644
index d8ce4d9..000
diff --git a/bits/bbdb-filters/bbdb-eudora.el b/bits/bbdb-filters/bbdb-eudora.el
deleted file mode 100644
index 2c2f848..000
diff --git a/bits/bbdb-filters/bbdb-export.el b/bits/bbdb-filters/bbdb-export.el
deleted file mode 100644
index 279238a..000
diff --git a/bits/bbdb-filters/bbdb-hp200lx.el 
b/bits/bbdb-filters/bbdb-hp200lx.el
deleted file mode 100644
index fe3f00a..000
diff --git a/bits/bbdb-filters/bbdb-passwd.el b/bits/bbdb-filters/bbdb-passwd.el
deleted file mode 100644
index 74dc8fd..000
diff --git a/bits/bbdb-filters/bbdb-ph.el b/bits/bbdb-filters/bbdb-ph.el
deleted file mode 100644
index fc21502..000
diff --git a/bits/bbdb-filters/doc/formatted/bbdb-filters.info 
b/bits/bbdb-filters/doc/formatted/bbdb-filters.info
deleted file mode 100644
index c66edef..000
diff --git a/bits/bbdb-filters/doc/lgpl.tex b/bits/bbdb-filters/doc/lgpl.tex
deleted file mode 100644
index 7427570..000
diff --git a/bits/bbdb-filters/doc/main.texinfo 
b/bits/bbdb-filters/doc/main.texinfo
deleted file mode 100644
index 7edb948..000
diff --git a/bits/bbdb-filters/doc/makefile b/bits/bbdb-filters/doc/makefile
deleted file mode 100644
index 3feac99..000
diff --git a/bits/bbdb-filters/makefile b/bits/bbdb-filters/makefile
deleted file mode 100644
index 9959f0e..000
diff --git a/bits/bbdb-funcs.txt b/bits/bbdb-funcs.txt
deleted file mode 100644
index 14a8180..000
diff --git a/bits/bbdb-gnokii.el b/bits/bbdb-gnokii.el
deleted file mode 100644
index 46f6911..000
diff --git a/bits/bbdb-ldif.el b/bits/bbdb-ldif.el
deleted file mode 100644
index fd54ac7..000
diff --git a/bits/bbdb-mail-folders.el b/bits/bbdb-mail-folders.el
deleted file mode 100644
index 4173ca7..000
diff --git a/bits/bbdb-mew.el b/bits/bbdb-mew.el
deleted file mode 100644
index 190e72e..000
diff --git a/bits/bbdb-obsolete.el b/bits/bbdb-obsolete.el
deleted file mode 100644
index 1dac1c3..000
diff --git a/bits/bbdb-pgp.el b/bits/bbdb-pgp.el
deleted file mode 100644
index 3599138..000
diff --git a/bits/bbdb-signature.el b/bits/bbdb-signature.el
deleted file mode 100644
index e44e8e6..000
diff --git a/bits/bbdb-sort-mailrc.el b/bits/bbdb-sort-mailrc.el
deleted file mode 100644
index 1a1710d..000
diff --git a/bits/bbdb-to-outlook.el b/bits/bbdb-to-outlook.el
deleted file mode 100644
index a8dd6bf..000
diff --git a/bits/bbdb-vcard-export.el b/bits/bbdb-vcard-export.el
deleted file mode 100644
index afb7191..000
diff --git a/bits/bbdb-vcard-import.el b/bits/bbdb-vcard-import.el
deleted file mode 100644
index adbdd5a..000
diff --git a/bits/bbdbpalm.el b/bits/bbdbpalm.el
deleted file mode 100644
index 3852b0d..000
diff --git a/bits/make.bat b/bits/make.bat
deleted file mode 100644
index 0e5248d..000
diff --git a/bits/vcard.el b/bits/vcard.el
deleted file mode 100644
index c7bfad3..000
diff --git a/configure.ac b/configure.ac
deleted file mode 100644
index 795fd0f..000
diff --git a/debian/README.Debian b/debian/README.Debian
deleted file mode 100644
index 06ae927..000
diff --git a/debian/README.source b/debian/README.source
deleted file mode 100644
index 717bdcc..000
diff --git 

Bug#939650: libvdpau: please make the build reproducible

[Chris Lamb]

Hi Luca,

> I am not sure I follow though - I do not see those files that the repro
> build is complaining about in the latest upload? Do they appear because
> of a new version of tex or something like that?

Hm that is indeed rather likely. Now that I think of it more explicitly,
I have seen other misc LaTeX things recently in a Reproducible Builds
context.


Regards,

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

Bug#934814: libdballe7: built with libmariadbclient18, which doesn't exist any longer

[Enrico Zini]

On Sat, Aug 24, 2019 at 05:11:22PM +0200, Otto Kekäläinen wrote:

> Increasing severity to 'serious' since this is one of the 5 packages
> what still depend on libmariadbclient18, which will soon be removed
> from unstable and then render this package uninstallable. Please
> rebuild and upload, so that the package will automatically be built
> and depend on newest libraries (including libmariadb3 which has
> replaced libmariadbclient18).

I've done a new upload, I took advantage to upload a new upstream
release, as the current one in Debian had become rather obsolete.

Unfortunately, it's still stuck in binary-NEW since a week.

This issue should be fixed once the package passes binary-NEW.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#939689: ITP: golang-github-maruel-panicparse -- Crash your app in style (Golang)

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-maruel-panicparse
  Version : 1.3.0-1
  Upstream Author : Marc-Antoine Ruel
* URL : https://github.com/maruel/panicparse
* License : Apache-2.0
  Programming Lang: Go
  Description : Crash your app in style (Golang)
 Parses panic stack traces, densifies and deduplicates goroutines with
 similar stack traces. Helps debugging crashes and deadlocks in
 heavily parallelized processes.

This package is a dependency of the new upstream version of syncthing.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#938964: please don't install runit-helper on everyone's system

[Dmitry Bogatov]

[2019-09-04 07:10] Noah Meyerhans 
> On Sun, Sep 01, 2019 at 09:38:36PM +0800, Shengjing Zhu wrote:
> > > Just for my curiosity (not going to happen in my watch), would you be
> > > happier if `runit-helper` script was part of init-system-helpers (which
> > > is essential, anyway).
> > 
> > I'm not sure why you didn't chose this at first. As it calls itself
> > "helper tools for all init systems".
> > I'm not saying I'm happy with init-system-helpers, but this already
> > exists for long and looks better.

> I think unifying the functionality of this package with
> init-system-helpers would be preferable.

Only if you (or someone else) volonteer to be the ambassador.

> But beyond just polluting the package namespace, I'm a bit annoyed by
> the stuff that this package leaves around the filesystem as well. In
> particular, /var/log/runit shouldn't exist on systems that don't even
> have runit installed.  /etc/runit is similarly annoying.

If it does not clean after purge -- please report. It is important bug.

But otherwise, sorry, Debian is not Gentoo. We do have useless
files, packages, directories and even shared libraries around. This is
how things always were. E.g:

 * /etc/init.d/*
 * /etc/systemd
 * /var/lib/systemd
 * udev
 * libsystemd0
 * libselinux
 * apparmor
 * libblkid
 * doc-base

Well, maybe you are using some (or even most) of these, but it is not
the point. Wait, you can't use both apparmor and selinux.

> I think it'd be worthwhile to come up with a slightly more
> sophisticated mechanism for populating runit configuration on systems
> that actually need such configuration, while also eliminating noise on
> systems that don't need it.

This configuration system already exists, and is not tied to runit in
any way. It is called `dpkg --exclude`. So much on unwanted /etc/*
files.

But on package dependencies, you can't just remove `runit-helper` due
hard dependency, that is true. I find it (unlike files in /etc) real
problem. But I do not know solution.

I can relax relation to recommends, and change maintainer script to use
`runit-helper` only if it is installed. In such case, everything will be
fine as long as you do not try to boot with init=/lib/runit/runit-init
(or install runit-init).

And if you do, whether things will work out-of-box or you will end only
with tty1-6 depends on whether `runit-helper` was present when you
installed your services. Actually, it can be something in between.

I hope to reduce amount of code in `runit-helper`, so eventually it can
be reasonably embedded directly into maintainer script. But not today.

> I'm happy to create a separate bug for the filesystem issues if you'd
> like to track them separately from the package name issues.

I am fine discussing it here.

By the way, initially I wanted to ship runscripts for services in
separate packages. This approach was reject by both FTP masters and
discussion on `debian-devel'. Somewhy there is strong opposition to tiny
packages.

Given this and establilished practice of including both systemd service
files and sysvinit init scripts (mandated by Policy) into main package,
I was given no choice.

In ideal world, there would be {foo}-bin, {foo}-systemd, {foo}-sysvinit,
{foo}-run and metapackage {foo}, that depends on everything mentioned
before. Unlikely to happen.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#929040: Blocked on an upstream issue

[Marcin Owsiany]

FTR, the upload is blocked on
https://github.com/mpereira/tty-solitaire/issues/14

Bug#913978: (no subject)

[Mika Hanhijärvi]

Hi


Has there been any progress in fixing this bug?Atleast I have not heard
about any progress at all. Looks like Gnome developers do not care about
accessibility at all...

Bug#817713: vdk2-tutorial: diff for NMU version 1.1-3.1

[Boyuan Yang]

Control: tags 817713 + patch
Control: tags 817713 + pending

Dear maintainer,

I've prepared an NMU for vdk2-tutorial (versioned as 1.1-3.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru vdk2-tutorial-1.1/debian/changelog vdk2-tutorial-
1.1/debian/changelog
--- vdk2-tutorial-1.1/debian/changelog  2019-09-07 15:39:45.0 -0400
+++ vdk2-tutorial-1.1/debian/changelog  2019-09-07 15:25:32.0 -0400
@@ -1,3 +1,20 @@
+vdk2-tutorial (1.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
++ Bump debhelper compat version to v12. (Closes: #817713)
++ Bump Standards-Version to 4.4.0.
++ Mark package vdk2-tutorial as Multi-Arch: foreign.
++ Mark the section for source package as doc. (lintian warning)
++ Let the binary package depends on ${misc:Depends}
+  (lintian warning)
+  * debian/rules: Use dh sequencer accordingly.
+  * debian/source/format: Use "3.0 (quilt)" format.
+  * debian/lintian-overrides: Add override for
+copyright-should-refer-to-common-license-file-for-gfdl.
+
+ -- Boyuan Yang   Sat, 07 Sep 2019 15:25:32 -0400
+
 vdk2-tutorial (1.1-3) unstable; urgency=low
 
   * rebuild to finish /usr/doc transition (closes: #359599)
diff -Nru vdk2-tutorial-1.1/debian/compat vdk2-tutorial-1.1/debian/compat
--- vdk2-tutorial-1.1/debian/compat 2019-09-07 15:39:45.0 -0400
+++ vdk2-tutorial-1.1/debian/compat 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-4
\ No newline at end of file
diff -Nru vdk2-tutorial-1.1/debian/control vdk2-tutorial-1.1/debian/control
--- vdk2-tutorial-1.1/debian/control2019-09-07 15:39:45.0 -0400
+++ vdk2-tutorial-1.1/debian/control2019-09-07 15:19:26.0 -0400
@@ -1,12 +1,14 @@
 Source: vdk2-tutorial
+Section: doc
 Priority: optional
 Maintainer: Michael Vogt 
-Build-Depends: debhelper (>> 3.0.0)
-Standards-Version: 3.5.6
+Build-Depends: debhelper-compat (= 12)
+Standards-Version: 4.4.0
 
 Package: vdk2-tutorial
-Section: doc
 Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}
 Suggests: libvdk2-dev
 Description: Tutorial for the Visual Development Kit C++ library 2 
  The Visual Development Kit2 (VDK2) is a C++ library
diff -Nru vdk2-tutorial-1.1/debian/copyright vdk2-tutorial-
1.1/debian/copyright
--- vdk2-tutorial-1.1/debian/copyright  2019-09-07 15:39:45.0 -0400
+++ vdk2-tutorial-1.1/debian/copyright  2019-09-07 15:24:20.0 -0400
@@ -7,4 +7,4 @@
 
 Copyright: 
 GFDL 1.1 (GNU Free Documentation License), see
-http://www.gnu.org/copyleft/fdl.html
\ No newline at end of file
+https://www.gnu.org/licenses/fdl-1.1.html
diff -Nru vdk2-tutorial-1.1/debian/lintian-overrides vdk2-tutorial-
1.1/debian/lintian-overrides
--- vdk2-tutorial-1.1/debian/lintian-overrides  1969-12-31 19:00:00.0
-0500
+++ vdk2-tutorial-1.1/debian/lintian-overrides  2019-09-07 15:25:29.0
-0400
@@ -0,0 +1,2 @@
+# GFDL 1.1 not present in /usr/share/common-licenses/ directory
+vdk2-tutorial: copyright-should-refer-to-common-license-file-for-gfdl
diff -Nru vdk2-tutorial-1.1/debian/rules vdk2-tutorial-1.1/debian/rules
--- vdk2-tutorial-1.1/debian/rules  2019-09-07 15:39:45.0 -0400
+++ vdk2-tutorial-1.1/debian/rules  2019-09-07 15:25:32.0 -0400
@@ -1,52 +1,4 @@
 #!/usr/bin/make -f
 
-# debian/rules file for gtk+ Debian package
-# written Feb 1999 by Ionutz Borcoman 
-# used script written  April 1998 by Ben Gertzfield 
-
-build: build-stamp
-build-stamp:
-   dh_testdir
-   touch build-stamp
-
-clean:
-   dh_testdir
-   dh_testroot
-   rm -f build-stamp install-stamp 
-   # Add here commands to clean up after the build process.
-   dh_clean
-
-install: install-stamp
-install-stamp: build
-   dh_testdir
-   dh_testroot
-   dh_clean
-   touch install-stamp
-
-# Build architecture-independent files here.
-binary-indep: build install vdk-doc
-
-# Build architecture-dependent files here.
-binary-arch: 
-
-vdk-doc: build
-   dh_testdir
-   dh_testroot
-   dh_installdirs
-   dh_installdocs
-   dh_installchangelogs
-   dh_strip
-   dh_compress
-   dh_fixperms
-   dh_installdeb
-   dh_shlibdeps
-   dh_gencontrol
-   dh_makeshlibs
-   dh_md5sums
-   dh_builddeb
-
-source
diff:  
-   @echo >&2 'source and diff are obsolete - use dpkg-source -b'; false
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary
+%:
+   dh $@
diff -Nru vdk2-tutorial-1.1/debian/source/format vdk2-tutorial-
1.1/debian/source/format
--- vdk2-tutorial-1.1/debian/source/format  1969-12-31 19:00:00.0
-0500
+++ vdk2-tutorial-1.1/debian/source/format  2019-09-07 15:08:39.0
-0400
@@ -0,0 +1 @@
+3.0 (quilt)


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

Bug#938429: sagetex: Python2 removal in sid/bullseye

[Jerome BENOIT]

Hello,

thanks for your worry.

On 07/09/2019 22:46, Hilmar Preuße wrote:
> Control: block 938429 by 938426
> 
> On 30.08.19 09:51, Matthias Klose wrote:
>> Package: src:sagetex
>> Version: 3.2+ds-2
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
>>
>> Python2 becomes end-of-live upstream, and Debian aims to remove
>> Python2 from the distribution, as discussed in
>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>>
> Our sagetex package declares a BD on sagemath, which in turn has a BD on
> python2. Hence I guess our bug can only be fixed, when the bug in
> sagemath has been solved. Therefore I add a block statement.
> 
> Let me know in case my assumption is wrong.

Not totally. SageTeX already support Python 3.
I had waited until a working Sage in Sid to upload my last sagetex package 
yesterday.
I will bring the Python 3 variant next week-end or the one after 
(Friday/Satuday at the place I live).

Jerome

> 
> Hilmar
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

Bug#875250: Bug#875258: [scim] Future Qt4 removal from Buster

[Tz-Huan Huang]

On Fri, Aug 30, 2019 at 4:39 AM Moritz Mühlenhoff  wrote:

> On Sat, Sep 09, 2017 at 11:09:36PM +0200, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > Source: scim
> >
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> >
> > [announced] <
> https://lists.debian.org/debian-devel-announce/2017/08/msg6.html>
> >
> > Currently Qt4 has been dead upstream and we are starting to have problems
> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> >
> > [OpenSSL 1.1 support] <
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522>
> >
> > In order to make this move, all packages directly or indirectly
> depending on
> > the Qt4 libraries have to either get ported to Qt5 or eventually get
> > removed from the Debian repositories.
> >
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether
> there are
> > suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
>
> Given upstream's comments on https://github.com/scim-im/scim/issues/21,
> let's
> move forward by dropping the scim-qt-immodule binary package? It can still
> be re-added if a Qt5 port appears at a later time.
>

Sure. I have made the update and been waiting for maintainer's review.

  https://github.com/leggewie-DM/scim/pull/1

Thanks,
Tz-Huan

Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups

[Nicolas Schier]

> On 2019-09-05 18:38:09, Nicolas Schier wrote:
> > Dear Antoine,
> >
> >> > Antoine, could you create a repository in salsa's 'debian' 
> >> > namespace?
> >> > (My salsa account is 'nsc-guest').
> >> 
> >> Done: https://salsa.debian.org/debian/git-revise
> >
> > thanks for your fast reaction!
> > Right now, I do not have any permissions than to create merge requests 
> > for debian/git-revise.
> 
> Really? You seem to have created one here:
> 
> https://salsa.debian.org/debian/git-revise/merge_requests/1
> 
> I merged it after review.
> 
> > I'd like to have the CI stuff enabled (with 'debian/gitlab.yml'
> > instead of '.gitlab.yml'), that the usual test suites can also run on
> > the new official repo.  Can you please enable that (or give me the
> > permissions for doing that)?
> 
> I added you as a developer.

Thanks!

> >> > Would you be available as a sponsor (as soon as I have got rid of all
> >> > lintian issues)?
> >> 
> >> Sure!
> >
> > great!  I uploaded the package to mentors:
> >
> > https://mentors.debian.net/package/git-revise
> >
> > (same state as in the Pull-Request).
> >
> > Could you have a look at it?
> > (I am not sure, if I did the doc-base stuff correctly...)
> 
> Could you hook up the test suite in autopkgtest somehow?
> 
> The docbase stuff is usually in HTML, and to make it work you'd need to
> build it with the Sphinx package, I think. It would be better to split
> that out in a separate -doc package.
> 
> Why did you mark the FHS patch as not needing forward? It would seem
> like a useful contribution for upstream...
> 
> All this can be done in a future incantation though.
> 
> The stuff on mentors still has an empty postrm script, so it looks like
> it's not exactly the same state as the merge request...
> 
> python-git-revise-doc.docs refers to two non-existent files, so that
> should definitely be fixed. It would be strange to have README.source
> shipped, btw. And README.Debian doesn't need to be in the -doc package.
> 
> For the (build-)depends, you might want to split lines on commas to make
> future diffs smaller. You can also build-dep on debhelper-compat to pin
> an exact version, which also removes the need for the extra
> debian/compat file.
> 
> Did you audit or review the upstream source?

Thanks a lot for your detailed and criticial review.  It seems I have 
been a bit too sloppily ...  give me some days to handle your points.

Kind regards,
Nicolas


-- 
epost: nico...@fjasle.eu   irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature

Bug#939686: import-orig handles a .tar.gz that's actually a tar without warning, but git-pbuilder is then unable to read it

[Taowa Munene-Tardif]

On 2019-09-07 15:04, Guido Günther wrote:
> you didn't send the full log but since git-pbuilder doesn't do this
> itself i'd assume this should be filed against pbuilder.
>  -- Guido

IMO either pbuilder should be able to handle a .tar that's a tar.gz
(which probably isn't great) or git-pbuilder import-orig shouldn't.

Taowa

-- 
   ,''`.  Taowa Munene-Tardif
  : :'  : taowa@deb{ian,conf}.org
  `. `'`  taowa.ca
`-Montréal

Bug#939688: libvirt-daemon-system: loses VMs on upgrade

[Thorsten Glaser]

Package: libvirt-daemon-system
Version: 5.6.0-2
Severity: normal

Upgrading a system with one VM running:

[…]
Setting up libvirt-daemon-system (5.6.0-2) ...
Restarting libvirt logging daemon: /usr/sbin/virtlogd.
Restarting libvirt management daemon: /usr/sbin/libvirtd.

Running guests on default URI: MirBSD
Shutting down guests on default URI...
Starting shutdown on guest: MirBSD
error: Failed to shutdown domain b0994f54-15e8-bb58-2f8f-1460fc81ec6b
error: Requested operation is not valid: domain is not running
libvirt-guests is configured not to start any guests on boot
invoke-rc.d: initscript libvirt-guests, action "restart" failed.
dpkg: error processing package libvirt-daemon-system (--configure):
 installed libvirt-daemon-system package post-installation script subprocess 
returned error exit status 1
[…]
Errors were encountered while processing:
 libvirt-daemon-system


This was “fixed” by a “sudo dpkg -a --configure”, however,
afterwards, “virsh list --all” shows the VM as off, while
it was still running (ssh’ing into it and shutting it down
from inside worked).


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.73
ii  gettext-base   0.19.8.1-9
ii  init-system-helpers1.57
ii  iptables   1.8.3-2
ii  libc6  2.28-10
ii  libvirt-clients5.6.0-2
ii  libvirt-daemon 5.6.0-2
ii  libvirt0   5.6.0-2
ii  libxml22.9.4+dfsg1-7+b3tarent1
ii  logrotate  3.15.1-1
ii  lsb-base   11.1.0
ii  policykit-10.105-26

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode 3.2-2
pn  dnsmasq-base  
ii  iproute2  5.2.0-1
ii  parted3.2-26

Versions of packages libvirt-daemon-system suggests:
pn  apparmor
pn  auditd  
pn  nfs-common  
pn  open-iscsi  
ii  pm-utils1.4.1-18
pn  radvd   
pn  systemd 
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-ipv4.xml'
/etc/libvirt/nwfilter/clean-traffic-gateway.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic-gateway.xml'
/etc/libvirt/nwfilter/clean-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic.xml'
/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-spoofing.xml'
/etc/libvirt/nwfilter/no-ip-multicast.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-ip-multicast.xml'
/etc/libvirt/nwfilter/no-ip-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-mac-broadcast.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-mac-broadcast.xml'
/etc/libvirt/nwfilter/no-mac-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-other-l2-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-other-l2-traffic.xml'
/etc/libvirt/nwfilter/no-other-rarp-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-other-rarp-traffic.xml'
/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml'
/etc/libvirt/nwfilter/qemu-announce-self.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/qemu-announce-self.xml'
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'
/etc/libvirt/qemu/networks/default.xml [Errno 13] Permission denied: 
'/etc/libvirt/qemu/networks/default.xml'

-- debconf information:
  libvirt-daemon-system/id_warning: true

Bug#939686: import-orig handles a .tar.gz that's actually a tar without warning, but git-pbuilder is then unable to read it

[Guido Günther]

Hi,
On Sat, Sep 07, 2019 at 02:21:36PM -0400, Taowa Munene-Tardif wrote:
> Package: git-buildpackage
> Version: 0.8.12.2
> 
> On importing a file ending in .tar.gz that is actually just a badly-named 
> tar, gbp import-orig believes it's a .tar.gz (as tar doesn't mind the
> archive being misnamed) and treats it as one. When git-pbuilder then
> goes to extract it later, it uses gunzip and fails as gunzip can't
> unzip a .tar.
> 
> To reproduce:
> - create an archive using `tar -cf [name].orig.tar.gz [something]`
> - import it using gbp import-orig
> - run `gbp buildpackage --git-pbuilder`
> 
> It will fail with:
> 
> ```
> dpkg-source: info: building yubioath-desktop using existing 
> ./yubioath-desktop_4.3.4.orig.tar.gz
> 
> gzip: stdin: not in gzip format
> tar: This does not look like a tar archive
> ```
> despite being able to run `tar xf yubioath-desktop_4.3.4.orig.tar.gz`.

you didn't send the full log but since git-pbuilder doesn't do this
itself i'd assume this should be filed against pbuilder.
 -- Guido

Bug#939606: linux-image-5.2.0-2-amd64: Fails to shutdown/reboot/suspend

[Ben Hutchings]

Control: tag -1 moreinfo

Does this still happen if you remove the bbswitch module?

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg




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

Bug#939687: clazy: FTBFS on armel: undefined reference to symbol '__atomic_load_4@@LIBATOMIC_1.0'

[Paul Gevers]

Source: clazy
Version: 1.5-1
Severity: serious
Tags: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

During a binNMU of clazy during the llvm-defaults transition, you package FTBFS
on armel. Can you please check and fix the situation?

The last part of the log message as currently shown on 
https://buildd.debian.org/status/fetch.php?pkg=clazy=armel=1.5-1%2Bb1=1567623182=0
 reads:

[100%] Linking CXX executable bin/clazy-standalone
/usr/bin/cmake -E cmake_link_script CMakeFiles/clazy-standalone.dir/link.txt 
--verbose=1
/usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wno-class-memaccess 
-Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -fno-common -Woverloaded-virtual 
-Wcast-qual -fno-strict-aliasing -pedantic -Wno-long-long -Wall -W 
-Wno-unused-parameter -Wwrite-strings -fno-exceptions -fno-rtti -fPIC  
-Wl,-z,relro -Wl,-z,now -latomic -rdynamic 
CMakeFiles/clazy-standalone.dir/src/ClazyStandaloneMain.cpp.o  -o 
bin/clazy-standalone  -L/usr/lib/llvm-8/lib 
-Wl,-rpath,/usr/lib/llvm-8/lib:/<>/obj-arm-linux-gnueabi/lib: 
lib/ClazyPlugin.so /usr/lib/llvm-8/lib/libclangFrontend.a 
/usr/lib/llvm-8/lib/libclangDriver.a /usr/lib/llvm-8/lib/libclangCodeGen.a 
/usr/lib/llvm-8/lib/libclangSema.a /usr/lib/llvm-8/lib/libclangAnalysis.a 
/usr/lib/llvm-8/lib/libclangRewriteFrontend.a 
/usr/lib/llvm-8/lib/libclangRewrite.a /usr/lib/llvm-8/lib/libclangAST.a 
/usr/lib/llvm-8/lib/libclangASTMatchers.a /usr/lib/llvm-8/lib/libclangParse.a 
/usr/lib/llvm-8/lib/libclangLex.a /usr/lib/llvm-8/lib/libclangBasic.a 
/usr/lib/llvm-8/lib/libclangARCMigrate.a /usr/lib/llvm-8/lib/libclangEdit.a 
/usr/lib/llvm-8/lib/libclangFrontendTool.a 
/usr/lib/llvm-8/lib/libclangRewrite.a 
/usr/lib/llvm-8/lib/libclangSerialization.a 
/usr/lib/llvm-8/lib/libclangTooling.a 
/usr/lib/llvm-8/lib/libclangStaticAnalyzerCheckers.a 
/usr/lib/llvm-8/lib/libclangStaticAnalyzerCore.a 
/usr/lib/llvm-8/lib/libclangStaticAnalyzerFrontend.a 
/usr/lib/llvm-8/lib/libclangSema.a /usr/lib/llvm-8/lib/libLLVM-8.so 
/usr/lib/llvm-8/lib/libclangAnalysis.a 
/usr/lib/llvm-8/lib/libclangRewriteFrontend.a 
/usr/lib/llvm-8/lib/libclangRewrite.a /usr/lib/llvm-8/lib/libclangAST.a 
/usr/lib/llvm-8/lib/libclangASTMatchers.a /usr/lib/llvm-8/lib/libclangParse.a 
/usr/lib/llvm-8/lib/libclangLex.a /usr/lib/llvm-8/lib/libclangBasic.a 
/usr/lib/llvm-8/lib/libclangARCMigrate.a /usr/lib/llvm-8/lib/libclangEdit.a 
/usr/lib/llvm-8/lib/libclangFrontendTool.a 
/usr/lib/llvm-8/lib/libclangSerialization.a 
/usr/lib/llvm-8/lib/libclangTooling.a 
/usr/lib/llvm-8/lib/libclangStaticAnalyzerCheckers.a 
/usr/lib/llvm-8/lib/libclangStaticAnalyzerCore.a 
/usr/lib/llvm-8/lib/libclangStaticAnalyzerFrontend.a 
/usr/lib/llvm-8/lib/libLLVM-8.so 
/usr/bin/ld: lib/ClazyPlugin.so: undefined reference to symbol 
'__atomic_load_4@@LIBATOMIC_1.0'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libatomic.so: error adding 
symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/clazy-standalone.dir/build.make:128: 
bin/clazy-standalone] Error 1
make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[2]: *** [CMakeFiles/Makefile2:76: CMakeFiles/clazy-standalone.dir/all] 
Error 2
make[2]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[1]: *** [Makefile:155: all] Error 2
make[1]: Leaving directory '/<>/obj-arm-linux-gnueabi'
dh_auto_build: cd obj-arm-linux-gnueabi && make -j4 "INSTALL=install 
--strip-program=true" returned exit code 2
make: *** [debian/rules:19: build-arch] Error 255

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

Kernel: Linux 5.2.0-2-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)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl1z/eoACgkQnFyZ6wW9
dQob6Qf+IBuxWmNSd6kwO4kHCm16SInrB4a3Rs2/PIcFopnGiQKY7UNza6iLcw2f
dd+uaLJkKQzYRq6IMHAfEQe7vjF3lB1oITyJNKx4VRpxQ8fMBkwVQsNsErs2ACBu
GFmFNoJaEWlaC0rZcpoHIZU2x98jhQheGv/hfQ2L8FaoKUqwo2PRGgFKoR0kGLvN
N6KZottKecx8M0BiIdyTHi1YC/c5VWqXue5vWRLmLpOPqs40+xZQClcutfhD/F0U
nSYRQPuYW+I0cdFObARzY80kqGqg6lwGGEb3SczUHSAuTPfLMFvaVCNL1FZN7TCg
FgGro3JPdiKOclpK9OL+KHI3JJMgUQ==
=Tiwf
-END PGP SIGNATURE-

Bug#938429: sagetex: Python2 removal in sid/bullseye

[Hilmar Preuße]

Control: block 938429 by 938426

On 30.08.19 09:51, Matthias Klose wrote:
> Package: src:sagetex
> Version: 3.2+ds-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
Our sagetex package declares a BD on sagemath, which in turn has a BD on
python2. Hence I guess our bug can only be fixed, when the bug in
sagemath has been solved. Therefore I add a block statement.

Let me know in case my assumption is wrong.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#870066:

[Sascha Steinbiss]

FYI, to address #937761 I have just uploaded a python3 version of this package. 
I’ll keep this bug open to track the other requests.

Bug#935325: Regression patchset

[Eric Desrochers]

Rectification from my previous update:

https://github.com/net-snmp/net-snmp/commit/71e487212bd65839e7454df9701524d08cf0d74f

https://github.com/net-snmp/net-snmp/commit/bcb1a6b8afc444bbcd099a195e08f0b01cbc8f6b

References:
https://bugs.launchpad.net/ubuntu/bionic/+source/net-snmp/+bug/1843036
https://sourceforge.net/p/net-snmp/patches/1350/

Regards,
Eric

Bug#451535: debian-installer: allow to 'reuse' encrypted volumes

[Ben Hutchings]

On Sat, 2019-09-07 at 13:48 +0300, M Santala wrote:
[...]
> This bug has persisted for a long time and it bites long-term Debian
> users who are upgrading their systems, causing loss of time and
> data. This makes upgrade a challenge and encourages to keep obsolete
> systems in operation.

What makes you think the installer is intended to be used for upgrades?

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg




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

Bug#939388: postgresql-9.6: package update crashes with: new pre-removal script returned error exit status 1

[Christoph Berg]

Control: tags -1 moreinfo

Re: Matthias Weiss 2019-09-04 

>     when updating the "postgresql-9.6" package from version
> "9.6.13-0+deb9u1" to "9.6.15-0+deb9u1" the installation crashes with
> 
> 
> subprocess new pre-removal script returned error exit status 1
> 
> 
> Here is the full log:
> 
> > aptitude install postgresql-9.6
> Preparing to unpack .../postgresql-9.6_9.6.15-0+deb9u1_amd64.deb ...
> Job for postgresql@9.6-main.service canceled.

Hi Matthias,

it looks like the 9.6/main cluster failed to stop/restart here.
Could you check the postgresql-9.6-main.log file to see if there's any
errors in there?

If you still think this is a packaging fault, please attach the
postgresql-9.6-main.log file here.

Christoph

Bug#939686: import-orig handles a .tar.gz that's actually a tar without warning, but git-pbuilder is then unable to read it

[Taowa Munene-Tardif]

Package: git-buildpackage
Version: 0.8.12.2

On importing a file ending in .tar.gz that is actually just a badly-named 
tar, gbp import-orig believes it's a .tar.gz (as tar doesn't mind the
archive being misnamed) and treats it as one. When git-pbuilder then
goes to extract it later, it uses gunzip and fails as gunzip can't
unzip a .tar.

To reproduce:
- create an archive using `tar -cf [name].orig.tar.gz [something]`
- import it using gbp import-orig
- run `gbp buildpackage --git-pbuilder`

It will fail with:

```
dpkg-source: info: building yubioath-desktop using existing 
./yubioath-desktop_4.3.4.orig.tar.gz

gzip: stdin: not in gzip format
tar: This does not look like a tar archive
```
despite being able to run `tar xf yubioath-desktop_4.3.4.orig.tar.gz`.

-- 
   ,''`.  Taowa Munene-Tardif
  : :'  : taowa@deb{ian,conf}.org
  `. `'`  taowa.ca
`-Montréal

Bug#939685: pulseaudio: Upgrade pulseaudio:amd64 12.2-4 -> 12.2-4+deb10u1 results in no audio output

[Boyd Stephen Smith Jr.]

Source: pulseaudio
Version: 12.2-4+deb10u1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

   * What led up to the situation?

Last night (2019-09-06) I had great audio (Gaming, Streaming, Video, etc.).
This morning I did a safe-upgrade, which included pulseaudio (but no other
sound related packages), and since the upgrade completed by desktop has been
silent.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I'v tried muting and unmuting in to alsamixer and pavucontrol.  I also adjusted
the volume down and then up in both.  I tried multiple applications; Chromium,
aplay, and KDE system-settings all *think* they are playing, and all show up if
I watch the PA playback monitor.  I use aplay as my primary test application,
trying to play the standard Front_Right.wav each time I made some settings
changes.

I tried changing the default ("fallback") PA device for both input and output.
I tried a reboot.  I looked through syslog for errors from pulsa, alsa, or
regarding dsp devices.  There are some warning messages, but I confirmed those
also existed before the upgrade.  (USB Headset advertises 8 channels: 5.1 out
and stereo in, and ALSA sometimes complains, but played in the past; one of my
alsa devices sometimes spuriously wakes up PA.)

I tried changing the PA channel configuration for my USB Headset, none worked.
(Tried at least: Analog Stereo out, no in; Digital Stereo out, no in, Analong
5.1 out, no in; Digital 5.1 out, no in; and the one that should work: Digital
5.1 out and Digital mono in.)

I tried using the mixer "puck" that goes to the USB headphones, adjusting each
of the volume controls down and up, and muting and unmoting both the in and
out.

   * What was the outcome of this action?

No audio from the speakers, no even a hint.

   * What outcome did you expect instead?

I'd prefer the same audio I had last night, but any output coming from the
headphones would be good.

The most relevant upgrades that applied this morning are:

[UPGRADE] pulseaudio:amd64 12.2-4 -> 12.2-4+deb10u1
[UPGRADE] pulseaudio-utils:amd64 12.2-4 -> 12.2-4+deb10u1
[UPGRADE] libpulse-mainloop-glib0:amd64 12.2-4 -> 12.2-4+deb10u1
[UPGRADE] libpulse0:amd64 12.2-4 -> 12.2-4+deb10u1
[UPGRADE] libpulse0:i386 12.2-4 -> 12.2-4+deb10u1
[UPGRADE] libpulsedsp:amd64 12.2-4 -> 12.2-4+deb10u1

The rest of the upgrades are:

Aptitude 0.8.11: log report
Sat, Sep  7 2019 11:11:41 -0500

  IMPORTANT: this log only lists intended actions; actions which fail
due to dpkg problems may not be completed.

Will install 124 packages, and remove 0 packages.
326 MB of disk space will be used

[INSTALL, DEPENDENCIES] linux-headers-4.19.0-6-amd64:amd64 4.19.67-2
[INSTALL, DEPENDENCIES] linux-headers-4.19.0-6-common:amd64 4.19.67-2
[INSTALL, DEPENDENCIES] linux-image-4.19.0-6-amd64:amd64 4.19.67-2
[UPGRADE] android-sdk-platform-tools:amd64 27.0.0+10 -> 27.0.0+11+deb10u1
[UPGRADE] android-sdk-platform-tools-common:amd64 27.0.0+10 -> 
27.0.0+11+deb10u1
[UPGRADE] base-files:amd64 10.3 -> 10.3+deb10u1
[UPGRADE] bzip2:amd64 1.0.6-9.1 -> 1.0.6-9.2~deb10u1
[UPGRADE] bzip2-doc:amd64 1.0.6-9.1 -> 1.0.6-9.2~deb10u1
[UPGRADE] cups:amd64 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] cups-bsd:amd64 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] cups-client:amd64 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] cups-common:amd64 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] cups-core-drivers:amd64 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] cups-daemon:amd64 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] cups-ipp-utils:i386 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] cups-ppdc:amd64 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] cups-server-common:amd64 2.2.10-6 -> 2.2.10-6+deb10u1
[UPGRADE] devscripts:amd64 2.19.5 -> 2.19.5+deb10u1
[UPGRADE] dirmngr:amd64 2.2.12-1 -> 2.2.12-1+deb10u1
[UPGRADE] e2fsprogs:amd64 1.44.5-1 -> 1.44.5-1+deb10u1
[UPGRADE] e2fsprogs-l10n:amd64 1.44.5-1 -> 1.44.5-1+deb10u1
[UPGRADE] fig2dev:amd64 1:3.2.7a-5 -> 1:3.2.7a-5+deb10u1
[UPGRADE] firmware-amd-graphics:amd64 20190114-1 -> 20190114-2
[UPGRADE] firmware-iwlwifi:amd64 20190114-1 -> 20190114-2
[UPGRADE] firmware-linux:amd64 20190114-1 -> 20190114-2
[UPGRADE] firmware-linux-nonfree:amd64 20190114-1 -> 20190114-2
[UPGRADE] firmware-misc-nonfree:amd64 20190114-1 -> 20190114-2
[UPGRADE] gdb:amd64 8.2.1-2 -> 8.2.1-2+b1
[UPGRADE] gdbserver:amd64 8.2.1-2 -> 8.2.1-2+b1
[UPGRADE] ghostscript:amd64 9.27~dfsg-2+deb10u1 -> 9.27~dfsg-2+deb10u2
[UPGRADE] gnupg:amd64 2.2.12-1 -> 2.2.12-1+deb10u1
[UPGRADE] gnupg-agent:amd64 2.2.12-1 -> 2.2.12-1+deb10u1
[UPGRADE] gnupg-l10n:amd64 2.2.12-1 -> 2.2.12-1+deb10u1
[UPGRADE] gnupg-utils:amd64 2.2.12-1 -> 2.2.12-1+deb10u1
[UPGRADE] gnupg2:amd64 2.2.12-1 -> 2.2.12-1+deb10u1
[UPGRADE] gnuplot:amd64 5.2.6+dfsg1-1 -> 

Bug#939684: traverso FTCBFS: detects compiler flags from the current cpu

[Helmut Grohne]

Source: traverso
Version: 0.49.5-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

traverso fails to cross build from source from amd64 to non-amd64,
because it tries to detect compiler flags from the current cpu. That
makes it pass e.g. -msse to an arm compiler. The attached patch disables
the detection and adds back some flags for amd64 explicitly. Doing so
also fixes #916286. It also improves reproducibility of the package.
Further flags can be added to debian/rules by checking DEB_HOST_*
variables without compromising base lines or reproducibility as needed.
Please consider using or extending the attached patch.

Helmut
diff --minimal -Nru traverso-0.49.5/debian/changelog 
traverso-0.49.5/debian/changelog
--- traverso-0.49.5/debian/changelog2018-05-18 17:49:06.0 +0200
+++ traverso-0.49.5/debian/changelog2019-09-07 19:45:59.0 +0200
@@ -1,3 +1,11 @@
+traverso (0.49.5-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't let the build system detect optimization flags based on the current
+cpu. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 07 Sep 2019 19:45:59 +0200
+
 traverso (0.49.5-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru traverso-0.49.5/debian/rules traverso-0.49.5/debian/rules
--- traverso-0.49.5/debian/rules2017-10-11 09:03:09.0 +0200
+++ traverso-0.49.5/debian/rules2019-09-07 19:45:59.0 +0200
@@ -1,9 +1,13 @@
 #!/usr/bin/make -f
 
-DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
+include /usr/share/dpkg/architecture.mk
 ifneq ($(DEB_HOST_ARCH_OS),linux)
 cmake_extra_args += -DWANT_ALSA=OFF
 endif
+ifeq ($(DEB_HOST_ARCH_CPU),amd64)
+export DEB_CPPFLAGS_MAINT_APPEND=-DSSE_OPTIMIZATIONS -DUSE_X86_64_ASM
+export DEB_CXXFLAGS_MAINT_APPEND=-msse -mfpmath=sse
+endif
 
 export DEB_LDFLAGS_MAINT_APPEND=-Wl,--no-undefined -Wl,--as-needed
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
@@ -18,6 +22,7 @@
dh_auto_configure -- \
-DUSE_SYSTEM_SLV2_LIBRARY=ON \
-DWANT_MP3_ENCODE=ON \
+   -DDETECT_HOST_CPU_FEATURES=OFF \
$(cmake_extra_args)
 
 override_dh_install:

Bug#939639: lintian: autopkgtest failure on 32-bit architectures

[Graham Inggs]

Hi Felix

On Sat, 7 Sep 2019 at 16:46, Graham Inggs  wrote:
> We'll cherry-pick both of these and provide feedback.

Both worked well for us, across all architectures, thanks!

Regards
Graham

Bug#939683: rheolef: library has invalid mpi default path: fails to compile some examples

[Pierre Saramito]

Package: rheolef 
Version: 7.0-2+b1 
Severity: important 
Tags: patch 

Dear Maintainer, 

The "mpi.h" header has been moved from /usr/include/openmpi/ to another 
location. 
The configuration file of the Rheolef library has not been updated yet: 
thus applications do not compile cleanly. 
Example: 
cp -a /usr/share/doc/rheolef-doc/examples . 
cd example 
make dirichlet 
fatal error: mpi.h: No such file or directory 

This issue concerns the following Debian versions: sid, bullseye, buster. 

I have patched the debianization files of the Rheolef package. 
The patch solves this issue and will transmit it to the maintainers via git 
for uploading in Debian. 
The upstream version will be unchanged (7.0). 

Thanks for considering this bug. 

Pierre 


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

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

Versions of packages rheolef depends on: 
ii libamd2 1:5.4.0+dfsg-1 
ii libarmadillo9 1:9.200.7+dfsg-1 
ii libboost-iostreams1.67.0 1.67.0-13 
ii libboost-mpi1.67.0 1.67.0-13 
ii libc6 2.28-10 
ii libcgal13 4.13-1+b2 
ii libgcc1 1:8.3.0-2 
ii libgmp10 2:6.1.2+dfsg-4 
ii libmumps-ptscotch-5.1.2 5.1.2-4+b2 
ii libopenmpi3 3.1.3-11 
ii libptscotch-6.0 6.0.6-2 
ii librheolef-dev 7.0-2+b1 
ii librheolef1 7.0-2+b1 
ii libstdc++6 8.3.0-2 
ii libumfpack5 1:5.4.0+dfsg-1 
ii rheolef-doc 7.0-2 

Versions of packages rheolef recommends: 
ii gmsh 4.1.5+really4.1.3+ds1-1 
ii gnuplot-x11 5.2.6+dfsg1-1 
ii mayavi2 4.5.0-1 
ii paraview 5.4.1+dfsg4-3.1+b2 
ii paraview-python 5.4.1+dfsg4-3.1+b2 
-- 
pierre.saram...@imag.fr 
Directeur de Recherche CNRS 
Laboratoire Jean Kuntzmann, Grenoble, France 
http://ljk.imag.fr/membres/Pierre.Saramito 

Bug#939648: git-buildpackage: FTBFS in unstable: flake8: E117 over-indented

[Guido Günther]

Hi,
On Sat, Sep 07, 2019 at 10:29:08AM +0100, Simon McVittie wrote:
> Package: git-buildpackage
> Version: 0.9.14
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> 
> During test-builds to evaluate whether the new version of gtk-doc-tools is
> ready for upload to unstable, git-buildpackage failed to build. I can
> reproduce the build failure in a pure unstable sbuild environment:
> 
> >debian/rules override_dh_auto_test
> > make[1]: Entering directory '/<>'
> > make
> > make[2]: Entering directory '/<>'
> > flake8
> > ./gbp/patch_series.py:148:17: E117 over-indented
> > ./gbp/scripts/buildpackage.py:333:13: E117 over-indented
> > ./gbp/scripts/import_orig.py:82:17: E117 over-indented
> > ./gbp/scripts/common/import_orig.py:71:13: E117 over-indented
> > ./.pybuild/cpython3_3.7/build/gbp/patch_series.py:148:17: E117 over-indented
> > ./.pybuild/cpython3_3.7/build/gbp/scripts/buildpackage.py:333:13: E117 
> > over-indented
> > ./.pybuild/cpython3_3.7/build/gbp/scripts/import_orig.py:82:17: E117 
> > over-indented
> > ./.pybuild/cpython3_3.7/build/gbp/scripts/common/import_orig.py:71:13: E117 
> > over-indented
> > make[2]: *** [Makefile:20: syntax-check] Error 1

Fixed in git 78f8759a3d8e52e63aa3ec4dc2212989ae836494 since some time,
i'll roll that into a release.

> 
> Full build log attached.
> 
> I would recommend skipping stylistic/non-functional checks like this one,
> or making them only produce warnings, when "official" packages are built
> in a Debian environment (the style checks can still be fatal when run as
> part of `make check` during development, of course). Perhaps something
> like this:
> 
> # in debian/rules
> export IGNORE_STYLE_CHECKS = 1
> 
> # in the tests, replacing the flake8 invocation
> flake8 || [ -n "$IGNORE_STYLE_CHECKS" ]

I somewhat fear that they will slip then but i'll give it some
consideration.
thanks!
 -- Guido

> 
> Regards,
> smcv

Bug#939629: links2: Problem displaying a websit

[Mikulas Patocka]

On Sat, 7 Sep 2019, Axel Beckert wrote:

> Control: found -1 2.18-2
> Control: found -1 2.14-2
> Control: tag -1 + upstream confirmed
> Control: severity -1 minor
> Control: forwarded -1 mailto:miku...@twibright.com
> 
> Hi Jean-Philippe,
> 
> thanks for the bug report.
> 
> Jean-Philippe MENGUAL wrote:
> > Latest release of links2 in Sid
> 
> Not only. I can also reproduce this with Links 2 in Debian 10 Buster
> and Debian 9 Stretch.
> 
> > Visit 
> > "http://www.eurofly.stefankiss.sk/modules.php?name=pilots=pilot=5874;
> > 
> >* What was the outcome of this action?
> > 
> > A full blank page
> 
> Can confirm.
> 
> > On Firfox, I see a page, with info about Texou pilot
> 
> Firefox can use JavaScript, so many pages which work in Firefox won't
> work in Links 2 anyway.
> 
> But I can also confirm that the mentioned page works fine in Lynx
> (which doesn't have JavaScript support either) on Debian Unstable
> (2.9.0dev.4-1).

The server detects that the browser is Links (based on user-agent) and 
returns an empty page.

To fix this - go to "Setup" -> "Network options" -> "HTTP options" -> 
"Header Options" and select the checkbox "Fake Firefox". Then, Links will 
send firefox user agent and the server will return a valid page.

Mikulas

> I also have an idea what might have caused this:
> 
> * No opening  tag (but a closing one). This is probably the
>   cause for this issue.
> 
>   Lowering the severity to minor because of this, as this is clearly
>   very broken HTML and it is pure luck if a browser renders this
>   properly.
> 
> * Wrongly nested tags, e.g.:
> 
>   Our pilot Texou
>   About pilot
> 
> * Not closed  tags.
> 
> * Closing ,  and  tags, but no according opening
>   tags, i.e. neither ,  nor  tags.
> 
> So you might also want to contact the owner of that page and send them
> a bug report, too.
> 
>   Regards, Axel
> -- 
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
> 

Bug#939682: ITP: python3-django-phone-field -- Lightweight model and form field for phone numbers in Django

[Priyanka Saggu]

Package: wnpp
Severity: wishlist
Owner: Priyanka Saggu 

* Package name: python3-django-phone-field
  Version : 1.8.0
  Upstream Author : Andrew Mackowski
* URL : https://github.com/VeryApt/django-phone-field/
* License : GPL-3.0+
  Programming Lang: Python
  Description : Lightweight model and form field for phone numbers in Django

It is used to view and edit phone numbers in forms and the Django
 admin in pretty format.
 .
It stores all phone numbers canonically in the database for easy
searching & uniqueness.


Best,
Priyanka Saggu

Bug#939681: linux-image-5.2.0-2-armmp-lpae: Enable serial console on Raspberry Pi 3 Model B Plus Rev 1.3

[Heinrich Schuchardt]

Package: src:linux
Version: 5.2.9-2
Severity: normal

Dear Maintainer,

with the 32bit kernel I do not have a serial console on my RPi 3B+.
The serial console works fine with the 64bit kernel.

Please, add the missing configuration items to enable the console:

SERIAL_8250_EXTENDED=y
SERIAL_8250_SHARE_IRQ=y
SERIAL_8250_BCM2835AUX=y

Best regards

Heinrich

-- Package-specific info:
** Version:
Linux version 5.2.0-2-armmp-lpae (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

Bug#939680: ITP: golang-github-disintegration-gift -- Go Image Filtering Toolkit

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-disintegration-gift
  Version : 1.2.1-1
  Upstream Author : Grigory Dryapak
* URL : https://github.com/disintegration/gift
* License : Expat
  Programming Lang: Go
  Description : Go Image Filtering Toolkit
 Package gift provides a set of useful image processing filters.


This package is a dependency for the new upstream version of hugo.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#939505: Cannot access secondary GPU - error: [XORG] (EE)

[wglxy]

more information:


After I install package xserver-xorg-input-mouse, I got another error message.


If I run optirun, the error message is:






$ optirun glxgears
[  502.952517] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)

[  502.952549] [ERROR]Aborting because fallback start is disabled.







if I run primusrun, the error message is:




$ primusrun glxgears
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
in input
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)










Best regards,
Gulfstream

Bug#939489: Cannot access secondary GPU - error: [XORG] (EE)

[wglxy]

more information:


After I install package xserver-xorg-input-mouse, I got another error message.


If I run optirun, the error message is:






$ optirun glxgears
[  502.952517] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)

[  502.952549] [ERROR]Aborting because fallback start is disabled.







if I run primusrun, the error message is:




$ primusrun glxgears
/usr/bin/primusrun: line 41: warning: command substitution: ignored null byte 
in input
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE)










Best regards,
Gulfstream

Bug#848816: dgit: detect gbp export-dir configuration, and prefill build-products-dir

[Sean Whitton]

Hello,

On Fri 06 Sep 2019 at 11:20AM +01, Ian Jackson wrote:

> I have been thinking about this bug.
>
> Sean:
>> Ian suggests that maybe this should be the other way around: when
>> you set --build-products-dir foo, dgit will pass
>> --git-export-dir=foo to invocations of gbp.
>
> The problem with this is that this won't affect the user's own
> invocations of gbp.
>
> There is a converse problem with the original idea of dgit asking gbp:
> this is all very well for `dgit gbp-build' but what about (say) `dgit
> push-source' where dgit doesn't know you're using gbp.
>
> dgit could ask gbp iff gbp is installed but that would mean that if
> you have a ~/.gbp.config specifying export-dir, the behaviour of dgit
> would depend on whether gbp was actually installed.  Not nice.
>
> The goal surely is for the user to have to configure the bpd in only
> one place.  That should affect dgit, gbp, pbuilder, sbuild,
> origtargz/git-deborig, etc.  (In each case if and when the user users
> each of these commands.)
>
> This ought to work without depending on any of these utilities, and
> without depending on git, etc.
>
> I think this means we need a Debian-wide env var or a config file.

I think you're right, but I think we've discussed this before.  I was in
favour of having that config namespace be controlled by src:devscripts,
but the devscripts maintainers are not yet on board with that idea, right?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#935443: [PATCH] dgit-maint-bpo(7): Mention occasional need for --new

[Sean Whitton]

Hello,

On Thu 05 Sep 2019 at 04:50PM +01, Ian Jackson wrote:

> +=head1 GENERAL TIPS
> +
> +The first time a package is backported
> +for any particular Debian release,
> +you will have to pass the --new option to dgit.
> +
>  =head1 CHOOSING BETWEEN THE TWO WORKFLOWS
>
>  If backporting involves making no (additional) changes to the upstream
> @@ -59,8 +65,6 @@ work on machines running Debian stable, it is advisable to 
> choose a
>  rebasing workflow.  This ensures that dgit can automatically update
>  the debian/patches directory without any manual intervention.
>
> -=head1 TIPS FOR A MERGING WORKFLOW
> -

Dropping the =head1 here looks to be an error?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#939678: prosody-modules: Please add mod_bookmarks

[Elena ``of Valhalla'']

Package: prosody-modules
Version: 0.0~hg20190203.b54e98d5c4a1+dfsg-1
Severity: wishlist

Dear Maintainer,

Please consider adding mod_bookmarks_ which helps upgrading from Private
XML to PEP bookmarks and is recommended by
https://compliance.conversations.im

.. _mod_bookmarks: https://modules.prosody.im/mod_bookmarks

Bug#939679: dgit-maint-{merge,debrebase}(7): Use git fetch --tags upstream

[Sean Whitton]

Package: dgit
Version: 9.8
Severity: minor
Tags: patch

Hello,

On Thu 05 Sep 2019 at 05:37PM +01, Ian Jackson wrote:

> But, now that we are not using
>   git remote update
> which scans all remotes (and can therefore be slow or annoying or
> may need extra config) why not suggest
>   git fetch --tags upstream
> ?  That's not much more typing than --all.
>
> If you like this idea please send another patch.

Yes, sure, since we already recommend having a remote named 'upstream'.

-- 
Sean Whitton
From 1477e7907521322bc0b7ac2fa315124066b75d5a Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sat, 7 Sep 2019 09:32:21 -0700
Subject: [PATCH] dgit-maint-{merge,debrebase}(7): Use git fetch --tags
 upstream

We recommend using a remote called 'upstream' and so we can recommend
a command which will be faster and less likely to error out.

Suggested-by: Ian Jackson 
Signed-off-by: Sean Whitton 
---
 dgit-maint-debrebase.7.pod | 2 +-
 dgit-maint-merge.7.pod | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 27c97aa3..4a0b5a52 100644
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -353,7 +353,7 @@ release, and importing that release using git-debrebase(1).
 
 =over 4
 
-% git fetch --all --tags
+% git fetch --tags upstream
 
 =back
 
diff --git a/dgit-maint-merge.7.pod b/dgit-maint-merge.7.pod
index 37a02613..19950d4e 100644
--- a/dgit-maint-merge.7.pod
+++ b/dgit-maint-merge.7.pod
@@ -362,7 +362,7 @@ to git), you can just run dpkg-buildpackage(1) or debuild(1) instead.
 
 =over 4
 
-% git fetch --all --tags
+% git fetch --tags upstream
 
 =back
 
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#939677: mark libflint-2.5.2 Multi-Arch: same

[Helmut Grohne]

Package: libflint-2.5.2
Version: 2.5.2-19
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:sagemath src:singular

The affected packages fail to satisfy their cross Build-Depends, because
they need both the build architecture libflint-2.5.2 and the host
architecture libflint-2.5.2, but these conflict. Marking libflint-2.5.2
Multi-Arch: same would be needed here. Doing so requires moving the
library files to a multiarch libdir. The attached patch implements that.
Please consider applying it.

Helmut
diff --minimal -Nru flint-2.5.2/debian/changelog flint-2.5.2/debian/changelog
--- flint-2.5.2/debian/changelog2018-11-04 00:44:41.0 +0100
+++ flint-2.5.2/debian/changelog2019-09-07 13:06:37.0 +0200
@@ -1,3 +1,11 @@
+flint (2.5.2-19.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libraries to a multiarch libdir.
+  * Mark libflint-2.5.2 Multi-Arch: same. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 07 Sep 2019 13:06:37 +0200
+
 flint (2.5.2-19) unstable; urgency=medium
 
   * Apply patch from H.Grohne to fix cross build (Closes: #912686)
diff --minimal -Nru flint-2.5.2/debian/control flint-2.5.2/debian/control
--- flint-2.5.2/debian/control  2018-11-04 00:44:41.0 +0100
+++ flint-2.5.2/debian/control  2019-09-07 13:06:37.0 +0200
@@ -12,6 +12,7 @@
 Package: libflint-2.5.2
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Replaces: libflint-1.06, libflint-2.4.4, libflint-2.4.5
 Description: C library for number theory, shared library
diff --minimal -Nru flint-2.5.2/debian/libflint-2.5.2.install 
flint-2.5.2/debian/libflint-2.5.2.install
--- flint-2.5.2/debian/libflint-2.5.2.install   2018-11-04 00:44:41.0 
+0100
+++ flint-2.5.2/debian/libflint-2.5.2.install   2019-09-07 13:06:27.0 
+0200
@@ -1,2 +1,2 @@
-/usr/lib/libflint-*.so.*
-/usr/lib/libflint-*.so
+/usr/lib/*/libflint-*.so.*
+/usr/lib/*/libflint-*.so
diff --minimal -Nru flint-2.5.2/debian/libflint-dev.install 
flint-2.5.2/debian/libflint-dev.install
--- flint-2.5.2/debian/libflint-dev.install 2018-11-04 00:44:41.0 
+0100
+++ flint-2.5.2/debian/libflint-dev.install 2019-09-07 13:06:35.0 
+0200
@@ -1,3 +1,3 @@
 /usr/include/flint
-/usr/lib/libflint.so
-/usr/lib/libflint.a
+/usr/lib/*/libflint.so
+/usr/lib/*/libflint.a
diff --minimal -Nru flint-2.5.2/debian/rules flint-2.5.2/debian/rules
--- flint-2.5.2/debian/rules2018-11-04 00:44:41.0 +0100
+++ flint-2.5.2/debian/rules2019-09-07 13:06:37.0 +0200
@@ -39,8 +39,8 @@
$(MAKE) -C doc/latex
 
 override_dh_auto_install:
-   dh_auto_install
-   cd debian/tmp/usr/lib ; ln -sf libflint-$(DEB_VERSION_UPSTREAM).so.* 
libflint-$(DEB_VERSION_UPSTREAM).so
+   dh_auto_install -- LIBDIR=lib/${DEB_HOST_MULTIARCH}
+   cd debian/tmp/usr/lib/${DEB_HOST_MULTIARCH} ; ln -sf 
libflint-$(DEB_VERSION_UPSTREAM).so.* libflint-$(DEB_VERSION_UPSTREAM).so
 
 override_dh_auto_test:
dh_auto_test -- $(MAKE_OVERRIDE)

Bug#939676: xttitle FTCBFS: does not pass CC to ./configure

[Helmut Grohne]

Source: xttitle
Version: 1.0-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xttitle fails to cross build from source, because it configures for the
build architecture. The ./configure script is too old to understand
--host and needs an exported CC instead. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru xttitle-1.0/debian/changelog xttitle-1.0/debian/changelog
--- xttitle-1.0/debian/changelog2015-07-20 19:48:28.0 +0200
+++ xttitle-1.0/debian/changelog2019-09-07 15:59:46.0 +0200
@@ -1,3 +1,10 @@
+xttitle (1.0-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Export CC for an old ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 07 Sep 2019 15:59:46 +0200
+
 xttitle (1.0-7) unstable; urgency=medium
 
   * New maintainer. (Closes: #792561)
diff --minimal -Nru xttitle-1.0/debian/rules xttitle-1.0/debian/rules
--- xttitle-1.0/debian/rules2015-07-20 16:18:37.0 +0200
+++ xttitle-1.0/debian/rules2019-09-07 15:59:44.0 +0200
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE=1
 
+-include /usr/share/dpkg/buildtools.mk
+export CC
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:

Bug#935890: Rename "dgit push-source" to "dgit push"

[Sean Whitton]

Hello,

On Thu 05 Sep 2019 at 04:54PM +01, Ian Jackson wrote:

> Fair enough.  Maybe we should close this bug then.

We might just leave it open to see if any users think this is a good
idea.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#939675: ITP: python3-django-phonenumber-field -- Full-featured phone number package in Django

[Priyanka Saggu]

Package: wnpp
Severity: wishlist
Owner: Priyanka Saggu 

* Package name: python3-django-phonenumber-field
  Version : 2.4.0
  Upstream Author : Stefan Foulis and contributors
* URL : https://github.com/stefanfoulis/django-phonenumber-field
* License : Expat
  Programming Lang: Python
  Description : Full-featured phone number package in Django

 A Django library which interfaces with python-phonenumbers to
 validate, pretty print and convert phone numbers.
 .
 This package installs the library for Python 3.


Best,
Priyanka Saggu

Bug#939640:

[Fabiano Mastrolorito]

Do you mean headers of kernel linux?

I've controlled it and seem i've installed it already

Bug#895787: Fwd: RFS: pcapy/0.11.3-1 [ITA]

[Emmanuel Arias]

Hello Arnaud,

Thanks for contact me.

Yes I am still interested in adopt the package. :)

El Emma
Desde mi celular

El sáb., 7 de sept. de 2019 05:45, Arnaud Fontaine 
escribió:

> Hi,
>
> Do you still intend to take over maintenance of this package? (last time
> I suggested to  sponsor your upload if needed but  I'm unfortunately not
> going to have time to do that anymore, sorry)
>
> Regards,
> --
> Arnaud Fontaine
>

Bug#918644: Vice doesn't find ROM files

[Stefan Champailler]

After a strace session, I see this :

brk(0x55fa07e7f000) = 0x55fa07e7f000
brk(0x55fa07ea) = 0x55fa07ea
brk(0x55fa07ec2000) = 0x55fa07ec2000
futex(0x7fd578933c40, FUTEX_WAKE_PRIVATE, 1) = 1
access("/usr/lib/vice/C64/kernal", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/vice/DRIVES/kernal", R_OK) = -1 ENOENT (No such file or 
directory)
access("/usr/lib/vice/PRINTER/kernal", R_OK) = -1 ENOENT (No such file or 
directory)
access("/usr/bin/C64/kernal", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/bin/DRIVES/kernal", R_OK)  = -1 ENOENT (No such file or directory)
access("/usr/bin/PRINTER/kernal", R_OK) = -1 ENOENT (No such file or directory)
access("/home/stefan/.config/vice/C64/kernal", R_OK) = -1 ENOENT (No such file 
or directory)
access("/home/stefan/.config/vice/DRIVES/kernal", R_OK) = -1 ENOENT (No such 
file or directory)
access("/home/stefan/.config/vice/PRINTER/kernal", R_OK) = -1 ENOENT (No such 
file or directory)
getcwd("/home/stefan", 3968)= 13
openat(AT_FDCWD, "/home/stefan/kernal", O_RDONLY) = -1 ENOENT (No such
file or directory)


So it looks like vice doesn't go to the ~/.vice directory. However, on the 
documentation page here :

http://vice-emu.sourceforge.net/vice_4.html#SEC26

It is said : 

 The place where they will be searched for depends on the value of the 
Directory resource, which is a colon (:)-separated search path list, like the 
UNIX PATH environment variable. The default value is

PREFIX/lib/vice/EMU:$HOME/.vice/EMU:BOOTPATH/EMU


Notice that $HOME/.config/vice/EMU is not shown...

So dunno if it's a bug with vice or debian but well, not clear to me.

When I move the files under the .config directory, vice starts as expected.

stF

Bug#939674: lintian: FTBFS in a directory whose name contains a '+'

[Graham Inggs]

Source: lintian
Version: 2.20.0

Hi Maintainer

While mucking about with lintian earlier, I noticed that it FTBFS when
built in a directory whose name contains a '+', e.g. 'test+that', with
the error below.

Regards
Graham


#   Failed test 'Lintian passes for contains-build-path'
#   at /home/ginggs/test+that/lib/Test/Lintian/Run.pm line 299.
# Tags do not match
#
# --- 
debian/test-out/tags/checks/files/contains-build-path/tags.specified.calibrated
# +++ debian/test-out/tags/checks/files/contains-build-path/tags.actual.parsed
# -contains-build-path (binary): file-references-package-build-path
usr/share/doc/contains-build-path/build-path
# +
#
# Missing tags:
#   file-references-package-build-path
#
# Looks like you failed 1 test of 1.

Bug#939673: lintian: test failure with new gzip?

[Gianfranco Costamagna]

Source: lintian
Version: 2.21.0
Severity: important

Hello, somebody in ubuntu uploaded the new gzip 1.10 and now we have this test 
failure:

#   Failed test 'Lintian passes for files-general'
#   at /<>/lib/Test/Lintian/Run.pm line 300.
# Tags do not match
# 
# --- debian/test-out/tags/checks/files/files-general/tags.specified.calibrated
# +++ debian/test-out/tags/checks/files/files-general/tags.actual.parsed
# -files-general (binary): package-contains-timestamped-gzip 
usr/share/foo/bar.doctree.gz
# 
# Missing tags:
#   package-contains-timestamped-gzip
# 
# Looks like you failed 1 test of 1.
debian/test-out/tags/checks/files/files-general/generic.t 
. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 


gzip version is gzip_1.10-0ubuntu3

This started with 2.20.0 with commit ea2fac33c4c21d185430c48e387ad198cc0c1436, 
the first release with the new timestamped-gzip test...

I'm ccing Felix, since the commit comes from him!

thanks for having a look,

Gianfranco

Bug#934785: does not include lis.so driver

[Adam Di Carlo]

Dominique Dumont  writes:

> That said, this requires people willing to create a PR and having the HW to 
> test. So far, nobody volunteered. Could you have a look there ?

Yes, I will.  I'd prefer not to have to maintain a fork.

Pardon my slowness in response, deadlines make me tardy on following up
on things.

-- 
...Adam Di Carlo...

Bug#939672: tmate: does not work at all; fails saying '[lost server]'

[Antonio Terceiro]

Package: tmate
Version: 2.2.1-1+b2
Severity: grave
Justification: renders package unusable
Tags: bullseye sid

When I try to start tmate, it just aborts and says '[lost server]'.
After that the terminal is broken, and I have to reset it. I tried it on
a Debian 10 VM and it just works, so this is not a server-side problem.
I guess that some dependency changed under tmate in an incompatible way,
and maybe just upgrading to the new upstream version fixes this.

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

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

Versions of packages tmate depends on:
ii  libc6   2.28-10
ii  libevent-2.1-6  2.1.8-stable-4
ii  libmsgpackc23.0.1-3
ii  libssh-40.9.0-1
ii  libtinfo6   6.1+20190803-1

tmate recommends no packages.

tmate suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#918644: vice: Vice doesn't find kernal rom file

[Stefan Champailler]

Package: vice
Version: 3.3.0.dfsg-2
Followup-For: Bug #918644

Dear Maintainer,

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

   * What led up to the situation?

Running x64

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Nothing effectice so far. The system rom files seems ok, they are under 
~/.vice/C64.
My vicerc file doesn't point to wrong directories.
Tried : x64 -config /home/stefan/.vice/vicerc

   * What was the outcome of this action?

Always:

ffmpeg avformat lib has version 3a1464, VICE expects 3a1464: full match
ffmpeg  avcodec lib has version 3a2364, VICE expects 3a2364: full match
ffmpeg   avutil lib has version 381664, VICE expects 381664: full match
ffmpeg  swscale lib has version 050364, VICE expects 050364: full match
ffmpeg swresample lib has version 030364, VICE expects 030364: full match
Detecting ISA HardSID boards.
Could not open '/dev/port'.
Cannot get permission to access $300.
Detecting PCI HardSID boards.
No PCI HardSID boards found.
Detecting PCI CatWeasel boards.
No PCI CatWeasel found.
Detecting direct I/O ISA SSI2001.
Could not open '/dev/port'.
Cannot get permission to access $280.
Reading configuration file `/home/stefan/.vice/vicerc'.
*** VICE Version 3.3 ***
Welcome to x64, the free portable C64 Emulator.
Current VICE team members:
Marco van den Heuvel, Fabrizio Gennari, Groepaz, Olaf Seibert, Marcus Sutton,
Kajtar Zsolt, AreaScout, Bas Wassink, Michael C. Martin.
This is free software with ABSOLUTELY NO WARRANTY.
See the "About VICE" command for more info.
C64MEM: Error - Couldn't load kernal ROM `kernal'.
Error - Machine initialization failed.
Exiting...



   * What outcome did you expect instead?

running emulator :-)

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


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

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

Versions of packages vice depends on:
ii  dpkg 1.19.7
ii  install-info 6.5.0.dfsg.1-4+b1
ii  libasound2   1.1.8-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgl1   1.1.0-1
ii  libglew2.1   2.1.0-4
ii  libglib2.0-0 2.58.3-2
ii  libgtk-3-0   3.24.5-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4
ii  libreadline7 7.0-5
ii  libstdc++6   8.3.0-6
ii  zlib1g   1:1.2.11.dfsg-1

vice recommends no packages.

vice suggests no packages.

-- no debconf information

Bug#938962: user-mode-linux needs update for new linux

[Romain Francoise]

Hi,

On Tue, Sep 3, 2019 at 3:21 PM Ritesh Raj Sarraf  wrote:
[...]
> In file included from /usr/include/pcap.h:43,
>  from arch/um/drivers/pcap_user.c:7:
> /usr/include/pcap/pcap.h:835:18: note: previous declaration of ‘pcap_open’ 
> was here
>  PCAP_API pcap_t *pcap_open(const char *source, int snaplen, int flags,
>   ^
> make[2]: *** [scripts/Makefile.build:309: arch/um/drivers/pcap_user.o] Error 1

libpcap 1.9 includes support for remote capture, which was originally
a part of WinPcap extensions. The `pcap_open()' symbol is part of that
API and that's why it's defined in the header file even though remote
support is not enabled in Debian. I suggest you rename the function
defined in your program so that it doesn't conflict with libpcap.

Bug#939671: 5.3.6 "gnome-disk-utility fails to change LUKS password causing permanent data loss" has been fixed

[Michael Biebl]

Package: release-notes
Severity: normal


Hi,

the underlying issue resulting in 5.3.6 "gnome-disk-utility fails to
change LUKS password causing permanent data loss" has been fixed being
documented in the release notes has been fixed in 10.1.

It would probably be a good idea to amend the section in the release
notes accordingly.


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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