Bug#1076663: [pkg-apparmor] Bug#1076663: apparmor-profiles: AppArmor parser error for /etc/apparmor.d/font-manager

[Juan Rafael Fernández García]

On Sun, 21 Jul 2024 at 14:40, Christian Boltz  wrote:
>
> Hello,

Hi again

> Am Sonntag, 21. Juli 2024, 12:45:22 MESZ schrieb Juan-Rafael Fernandez:
> > Package: apparmor-profiles
> > Version: 3.1.7-1
>
> The font-manager profile expects AppArmor >= 4.0, but you have 3.1.7.
> [1] I didn't check which package ships the font-manager profile, but I'm
> quite sure it isn't part of apparmor-profiles.

I did. Font-manager.

> You (or the font-manager package [1]) will need to change the profile to
> use abi/3.0 instead of abi/4.0 (and maybe remove rule types not yet
> supported in 3.x) for distributions that include AppArmor 3.x.

That's easy to do locally, but should I open a file against
font-manager? Any plans to move to AppArmor 4.x anytime soon?
-- 
Juan Rafael Fernández

Bug#1076663: apparmor-profiles: AppArmor parser error for /etc/apparmor.d/font-manager

[Juan-Rafael Fernandez]

Package: apparmor-profiles
Version: 3.1.7-1
Severity: normal

Dear Maintainer,

* What led up to the situation?

This message from `systemctl status apparmor`

> Failed to start apparmor.service - Load AppArmor profiles.

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

I run apparmor_parser

* What was the outcome of this action?

```
$ sudo apparmor_parser -r /etc/apparmor.d/font-manager
AppArmor parser error for /etc/apparmor.d/font-manager in profile
/etc/apparmor.d/font-manager at line 4: Could not open 'abi/4.0': No such file
or director
```

* What outcome did you expect instead?

No errors, obviously, and a working apparmor service.



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

Kernel: Linux 6.9.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apparmor-profiles depends on:
ii  apparmor  3.1.7-1+b1

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- no debconf information

Bug#974924: Plasma 5.19.5.x: Emojis in black and white ( not color and not displayed correctly)

[Juan]

I've recently started seeing this

$ fc-match -s emoji
Symbola_hint.ttf: "Symbola" "Regular"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
opens___.ttf: "OpenSymbol" "Regular"
DejaVuMathTeXGyre.ttf: "DejaVu Math TeX Gyre" "Regular"
DejaVuSerif.ttf: "DejaVu Serif" "Book"
LiberationMono-Regular.ttf: "Liberation Mono" "Regular"
LiberationSerif-Regular.ttf: "Liberation Serif" "Regular"
Lato-Regular.ttf: "Lato" "Regular"
NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular"
D05L.otf: "D05L" "Regular"
DroidSansFallbackFull.ttf: "Droid Sans Fallback" "Regular"
StandardSymbolsPS.pfb: "Standard Symbols PS" "Regular"
DejaVuSerif-Italic.ttf: "DejaVu Serif" "Italic"
LiberationSerif-Italic.ttf: "Liberation Serif" "Italic"

Interestingly I don't see NotoColorEmoji.ttf in that list even though I
have the package installed

$ apt-cache show fonts-noto-color-emoji
Package: fonts-noto-color-emoji
Version: 2.042-1
Installed-Size: 10455
Maintainer: Debian Fonts Task Force 
Architecture: all
Description-en: color emoji font from Google
 Noto is a collection of font families, each visually harmonized across
 scripts.
 .
 The name "Noto" is short for "No Tofu", describing the aim of covering
 all living Unicode scripts.
 .
 Tofu (豆腐) is Japanese jargon for unicode replacement character "�"
 (U+FFFD) often displayed as replacement for unassigned or unknown
 characters.
 .
 This package contains the color emoji font used on "stock" Android devices
 such as the Google Pixel.
Description-md5: a9719702f7fba976902bc66487dd558b
Multi-Arch: foreign
Homepage: https://fonts.google.com/noto/specimen/Noto+Color+Emoji
Section: fonts
Priority: optional
Filename:
pool/main/f/fonts-noto-color-emoji/fonts-noto-color-emoji_2.042-1_all.deb
Size: 9626580
MD5sum: c35046d526cd6f8c3ead08bf6f2077ec
SHA256: 8bac9ea54e9a2781d488571d0ee78cec101ad899e78473b78f575a61529e8ac4

Bug#1057926: 403 Access Denied on some packages on official Debian repo

[Juan J. Fernandez]

Package: linux-image-6.1.0-14-rt-amd64
Version: 6.1.64-1

When I run apt upgrade command it shows Error 403 Access Denied
Here is a transcript:

E: Failed to fetch 
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-rt-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.126.132 80]

I suggest that the file permissions be corrected

I am using Debian GNU/Linux 12 Bookworm, kernel 6.5.11-7-pve


Thanks for fix it,
Cheers
JJ

E: Failed to fetch 
https://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-cloud-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.54.132 443]

E: Failed to fetch 
https://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-cloud-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.54.132 443]

E: Failed to fetch 
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-rt-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.126.132 80]

E: Failed to fetch 
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-rt-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.126.132 80]

Sent from Mail for Windows

Bug#1051196: tex-common half configured after update

[Juan-Rafael Fernandez]

Package: tex-common
Followup-For: Bug #1051196

Today's upgrade of texlive (2023.20230613-2 over 2022.20230122-4) fixes the
problem.

Sorry, noise from Testing - please close the bug.


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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  13.11.6

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libpaper-utils 1.1.29
ii  sensible-utils 0.0.20
ii  texlive-binaries   2023.20230311.66589-3
ii  ucf3.0043+nmu1
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
ii  lmodern  2.005-1

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   45~alpha-2
ii  ghostscript [postscript-viewer]  10.01.2~dfsg-1
ii  gv [postscript-viewer]   1:3.7.4-2+b1
ii  okular [postscript-viewer]   4:22.12.3-1
ii  perl-tk  1:804.036-1+b2
pn  xpdf | pdf-viewer
pn  xzdec

Versions of packages texlive-binaries depends on:
ii  libc6   2.37-7
ii  libcairo2   1.16.0-7
ii  libfontconfig1  2.14.2-4
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-2
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-3
ii  libkpathsea62023.20230311.66589-3
ii  libmpfr64.2.0-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-1
ii  libpotrace0 1.16-2
ii  libptexenc1 2023.20230311.66589-3
ii  libstdc++6  13.2.0-2
ii  libsynctex2 2023.20230311.66589-3
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2023.20230311.66589-3
ii  libtexluajit2   2023.20230311.66589-3
ii  libx11-62:1.8.6-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.12-1.1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-7
ii  t1utils 1.41-4
ii  zlib1g  1:1.2.13.dfsg-3

Versions of packages texlive-binaries recommends:
ii  dvisvgm   3.1-1
ii  texlive-base  2023.20230613-3

-- debconf information:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  texlive-base/texconfig_ignorant:

Bug#1051196: tex-common half configured after update

[Juan Rafael Fernandez]

Package: tex-common
Version: 6.18
Severity: important

   * What led up to the situation?

An update

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

Read the logs. I located the bug in this part:


This is HiTeX, Version 3.141592653-2.6-2.0 (TeX Live 2023) (INITEX)  4 SEP 2023
11:14
...
(hiplainpage.tex
! Missing { inserted.

   p
 p
refer

   e
l.48 prefere
d 0
?
! Emergency stop.

   p
 p
refer

   e
l.48 prefere
d 0
End of file on the terminal!

# actual command line used during this run
# hitex -ini   -jobname=hitex -progname=hitex -etex -ltx hitex.ini 



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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  13.11.6

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libpaper-utils 1.1.29
ii  sensible-utils 0.0.20
ii  texlive-binaries   2023.20230311.66589-3
ii  ucf3.0043+nmu1
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
ii  lmodern  2.005-1

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   45~alpha-2
ii  ghostscript [postscript-viewer]  10.01.2~dfsg-1
ii  gv [postscript-viewer]   1:3.7.4-2+b1
ii  okular [postscript-viewer]   4:22.12.3-1
ii  perl-tk  1:804.036-1+b2
pn  xpdf | pdf-viewer
pn  xzdec

Versions of packages texlive-binaries depends on:
ii  libc6   2.37-7
ii  libcairo2   1.16.0-7
ii  libfontconfig1  2.14.2-4
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-2
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-3
ii  libkpathsea62023.20230311.66589-3
ii  libmpfr64.2.0-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-1
ii  libpotrace0 1.16-2
ii  libptexenc1 2023.20230311.66589-3
ii  libstdc++6  13.2.0-2
ii  libsynctex2 2023.20230311.66589-3
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2023.20230311.66589-3
ii  libtexluajit2   2023.20230311.66589-3
ii  libx11-62:1.8.6-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.12-1.1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-7
ii  t1utils 1.41-4
ii  zlib1g  1:1.2.13.dfsg-3

Versions of packages texlive-binaries recommends:
ii  dvisvgm   3.1-1
ii  texlive-base  2022.20230122-3

-- debconf information:
  texlive-base/texconfig_ignorant:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi

Bug#1036173: nvidia-legacy-340xx-kernel-dkms: dkms module does not build against kernel 6.3

[Juan Mendez]

Package: nvidia-legacy-340xx-kernel-dkms
Version: 340.108-18
Severity: important

Dear Maintainer,

   * What led up to the situation?

 When compiling the module when installing a 6.3.2 linux kernel, the
dkms modules compilation failed with:
 /var/lib/dkms/nvidia-legacy-340xx/340.108/build/nv-mmap.c:315:23:
error: assignment of read-only member ‘vm_flags’


 See the cause explained in:
https://lore.kernel.org/lkml/za7x9y60sfgoa...@kroah.com/T/
 The write access to vm_flags needs to be done now through some
wrappers.

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

   The fix is applying this patch:
https://gist.github.com/vejeta/9078219f082d2bfd62b08b6eada780e6
   by copying it to: /usr/src/nvidia-legacy-340xx-340.108/patches and
adding the file name "nvidia-340xx-fix-linux-6.3.patch"
   to line 12 in /usr/src/nvidia-legacy-340xx-340.108/dkms.conf
   like:
   PATCH=(bashisms.patch 0001-backport-error-on-unknown-conftests.patch
0002-backport-error-on-unknown-conftests-uvm-part.patch
unregister_procfs_on_failure.patch kmem_cache_create_usercopy.patch buil
nvidia-340xx-fix-linux-6.3.patch)

   * What was the outcome of this action?

 The kernel could compile the nvidia 340 module and the system worked
perfectly after it.



-- Package-specific info:
uname -a:
Linux camelot 6.3.2-1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix
6.3-1.1~bookworm (2023-05-13) x86_64 GNU/Linux

/proc/version:
Linux version 6.3.2-1-liquorix-amd64 (ste...@liquorix.net) (gcc (Debian
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 ZEN SMP
PREEMPT liquorix 6.3-1.1~bookworm (2023-05-13)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 11
11:06:58 PST 2019
GCC version:  gcc version 12.2.0 (Debian 12.2.0-14)

lspci 'display controller [030?]':
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G86 [GeForce
8400 GS] [10de:0422] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Point of View BV G86 [GeForce 8400 GS] [1acc:0853]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

/etc/X11/xorg.conf.d/:
total 12
drwxr-xr-x  2 root root 4096 Jan 17 01:14 .
drwxr-xr-x 11 root root 4096 Jan 21 16:51 ..
lrwxrwxrwx  1 root root   53 Jan 17 01:14 20-nvidia-legacy-340xx.conf ->
/etc/alternatives/nvidia--20-nvidia-legacy-340xx.conf
-rw-r--r--  1 root root   79 Oct 28  2019 20-nvidia.conf

/etc/nvidia/:
total 24
drwxr-xr-x   4 root root  4096 Mar 19 21:14 .
drwxr-xr-x 199 root root 12288 May 16 14:46 ..
drwxr-xr-x   2 root root  4096 Jan 17 00:15 current
drwxr-xr-x   2 root root  4096 Mar 19 21:16 legacy-340xx
lrwxrwxrwx   1 root root56 Jan 17 00:15 nvidia-blacklists-nouveau.conf
-> /etc/alternatives/nvidia--nvidia-blacklists-nouveau.conf
lrwxrwxrwx   1 root root53 Jan 17 00:15 nvidia-drm-outputclass.conf ->
/etc/alternatives/nvidia--nvidia-drm-outputclass.conf
lrwxrwxrwx   1 root root12 Mar 17 20:36 nvidia-legacy-340xx-340.108 ->
legacy-340xx
lrwxrwxrwx   1 root root42 Jan 17 00:15 nvidia-load.conf ->
/etc/alternatives/nvidia--nvidia-load.conf
lrwxrwxrwx   1 root root46 Jan 17 00:15 nvidia-modprobe.conf ->
/etc/alternatives/nvidia--nvidia-modprobe.conf

Files from nvidia-installer:

Config and logfiles:

<< /etc/modprobe.d/nvidia-blacklists-nouveau.conf >>
# You need to run "update-initramfs -u" after editing this file.

# see #580894
blacklist nouveau
^^ /etc/modprobe.d/nvidia-blacklists-nouveau.conf ^^

<< /etc/X11/xorg.conf.d/20-nvidia-legacy-340xx.conf >>
# The EoL driver does not get updated to support newer Xserver versions.
Section "ServerFlags"
  Option "IgnoreABI" "1"
EndSection
^^ /etc/X11/xorg.conf.d/20-nvidia-legacy-340xx.conf ^^



Kernel modules: nvidia.ko
/lib/modules/6.2.13-1-liquorix-amd64/updates/dkms/nvidia-legacy-340xx.ko
/lib/modules/6.2.13-1-liquorix-amd64/updates/dkms/nvidia-legacy-340xx-uvm.ko
/lib/modules/6.1.0-9-amd64/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko
/lib/modules/6.1.0-7-amd64/updates/dkms/nvidia-legacy-340xx.ko
/lib/modules/6.1.0-7-amd64/updates/dkms/nvidia-legacy-340xx-uvm.ko
/lib/modules/6.1.0-7-amd64/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (500,
'oldstable'), (100, 'bullseye-fasttrack'), (100,
'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.2-1-liquorix-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nvidia-legacy-340xx-kernel-dkms 

Bug#1032891: nvidia-legacy-340xx-kernel-dkms: dkms module does not build against kernel 6.2

[Juan]

Package: nvidia-legacy-340xx-kernel-dkms
Version: 340.108-17
Severity: important
Tags: patch
X-Debbugs-Cc: vej...@gmail.com

Dear Maintainer,

   * What led up to the situation?

   When compiling the module when installing a 6.2 linux kernel, the dkms 
modules compilation failed with:

nv-acpi.c:84:19: error: initialization of ‘void (*)(struct acpi_device *)’ from 
incompatible pointer type ‘int (*)(struct acpi_device *, int)’ 
[-Werror=incompatible-pointer-types]
  84 | .remove = nv_acpi_remove_two_args,
 |   ^~~

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

   The fix is applying this patch: 
https://gist.github.com/vejeta/86e570b0a431b3f8d26911be506323ae
   by copying it to: /usr/src/nvidia-legacy-340xx-340.108/patches and adding 
the file name "nvidia-340xx-fix-linux-6.2.patch" 
   to line 12 in /usr/src/nvidia-legacy-340xx-340.108/dkms.conf
   like:
   PATCH=(bashisms.patch 0001-backport-error-on-unknown-conftests.patch 
0002-backport-error-on-unknown-conftests-uvm-part.patch 
unregister_procfs_on_failure.patch kmem_cache_create_usercopy.patch buil
nvidia-340xx-fix-linux-6.2.patch)


   * What was the outcome of this action?

   The kernel could compile the nvidia 340 module and the system worked 
perfectly after it.

 


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

Kernel: Linux 6.2.5-x64v3-xanmod1 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to es_ES.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From: Juan Manuel Méndez Rey 
Date: Mon, 13 Mar 2023 15:49:30 +
Subject: [PATCH] Tentative fix for NVIDIA 340.108 DKMS source for Linux 6.2

Credit goes to Joan Bruguera  for the inspiration patch:
"Tentative fix for NVIDIA 470.161.03 driver for Linux 6.2"


---
 nv-acpi.c  | 19 ---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/nv-acpi.c b/nv-acpi.c
index 07501eb..1fdf71c 100644
--- a/nv-acpi.c
+++ b/nv-acpi.c
@@ -8,6 +8,7 @@
  * _NVRM_COPYRIGHT_END_
  */
 
+#include 
 #define  __NO_VERSION__
 
 #include "os-interface.h"
@@ -24,7 +25,10 @@ static NV_STATUS   nv_acpi_extract_object  (const union 
acpi_object *, void *, N
 
 static int nv_acpi_add (struct acpi_device *);
 
-#if !defined(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT) || 
(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT == 2)
+// Rel. commit "ACPI: make remove callback of ACPI driver void" (Dawei Li, 14 
Nov 2022)
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(6, 2, 0))
+static voidnv_acpi_remove_one_arg_void(struct acpi_device *device);
+#elif !defined(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT) || 
(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT == 2)
 static int nv_acpi_remove_two_args(struct acpi_device *device, int 
type);
 #else
 static int nv_acpi_remove_one_arg(struct acpi_device *device);
@@ -80,7 +84,10 @@ static const struct acpi_driver nv_acpi_driver_template = {
 .ids = nv_video_device_ids,
 .ops = {
 .add = nv_acpi_add,
-#if !defined(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT) || 
(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT == 2)
+// Rel. commit "ACPI: make remove callback of ACPI driver void" (Dawei Li, 14 
Nov 2022)
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(6, 2, 0))
+.remove = nv_acpi_remove_one_arg_void,
+#elif !defined(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT) || 
(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT == 2)
 .remove = nv_acpi_remove_two_args,
 #else
 .remove = nv_acpi_remove_one_arg,
@@ -342,7 +349,10 @@ static int nv_acpi_add(struct acpi_device *device)
 return 0;
 }
 
-#if !defined(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT) || 
(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT == 2)
+// Rel. commit "ACPI: make remove callback of ACPI driver void" (Dawei Li, 14 
Nov 2022)
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(6, 2, 0))
+static void nv_acpi_remove_one_arg_void(struct acpi_device *device)
+#elif !defined(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT) || 
(NV_ACPI_DEVICE_OPS_REMOVE_ARGUMENT_COUNT == 2)
 static int nv_acpi_remove_two_args(struct acpi_device *device, int type)
 #else
 static int nv_acpi_remove_one_arg(struct acpi_device *device)
@@ -396,7 +406,10 @@ static int nv_acpi_remove_one_arg(struct acpi_device 
*device)
 device->driver_data = NULL;
 }
 
+// Rel. commit "ACPI: make remove callback of ACPI driver void" (Dawei Li, 14 
Nov 2022)
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(6, 2, 0))
 return status;
+#endif
 }
 
 /*
-- 
2.39.0

Bug#1021354: mouse wheel doesn't work on gnome-remote-desktop when connected remotely

[Juan Francés Rosillo]

Hello

I can confirm you that I have same problem on new fresh debian-testing.

# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:n/a
Codename:   bookworm
# dpkg -l | grep -i remote-desktop
ii  gnome-remote-desktop  43.1-1
   amd64Remote desktop daemon for GNOME
using PipeWire
#

I don't know how i can collect detailed/specific relevant information
related to this issue. I don't know if there is some workaround.

Regards,

On Thu, 6 Oct 2022 22:44:38 +0800 Yiyi Hu  wrote:
> Package: gnome-remote-desktop
> X-Debbugs-Cc: yiy...@gmail.com
> Version: 43.0-2
> Severity: important
>
> Hi, dear Maintainer,
>
> I'm using debian testing, last month, when gnome is not upgraded to
> 43.0-2, The mouse wheel works well when connected remotely.
>
> After upgraded to latest gnome, with gnome-remote-desktop 43.0-2, the
mouse
> wheel doesn't work when we connect remotely.
>
> But in gnome Settings app, the mouse wheel works, When I use
> chrome(106.0.5249.91), firefox(102.3.0esr), telegram, the mouse wheel
> doesn't
> work at all.
>
> in chrome&firefox, up/down scroll don't work, but middle click works fine
> anyway.
>
> This issue causes people have to use mouse like 15 years ago, Which is
very
> inconvenient, So please check this bug,
>
> Thanks.

Bug#990828: mutt can not delete mails due to access rights

[Juan Pedro Vallejo]

Package: mutt
Version: 2.2.9-1
Followup-For: Bug #990828
X-Debbugs-Cc: jn...@ya.com

Yes, you were right.

Architecture: i386 (i686)

-- Package-specific info:
Mutt 2.2.9 (2022-11-12)
Copyright (C) 1996-2022 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

[...]

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (600, 'testing'), (500, 'stable'), (500, 
'oldstable')
Architecture: i386 (i686)

Kernel: Linux 5.18.0-4-686-pae (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

[...]

-- no debconf information

Bug#990828: mutt can not delete mails due to access rights

[Juan Pedro Vallejo]

Package: mutt
Version: 2.2.9-1
Followup-For: Bug #990828
X-Debbugs-Cc: jn...@ya.com

Hi.

"mutt_dotlock" is the one to blame:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root root 13804 Nov 13 18:01 /usr/bin/mutt_dotlock

This works for me:

# chown root:mail /usr/bin/mutt_dotlock
# chmod 2755 /usr/bin/mutt_dotlock

Now:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root mail 13804 Nov 13 18:01 /usr/bin/mutt_dotlock

Bye.

Bug#1021500: rssguard: Crashes randomly after refreshing feeds

[Juan Marín Noguera]

Package: rssguard
Version: 4.0.4+dfsg-1+b1
Severity: important

Dear Maintainer,

I am using RSSGuard as a client for Nextcloud News, but recently (since
some point in time between September 26 and October 7) the program has
started crashing unpredictably after some time using it.  This usually
happens after some action like refreshing the feeds or copying the URL
of some feed, but so far I have been unable to find the root cause, as
it does not happen right after any user input, or even when the window
is focused.

These are the last lines of the log from one of the crashes.  The
failing malloc does not happen immediately after the previous lines.

```
time="   249.327" type="debug" -> database: Message with custom ID '1225' is 
already present in DB and has DB ID '1228'.
time="   249.327" type="debug" -> database: Checking if message with 
service-specific custom ID '1224' is present in DB.
time="   249.327" type="debug" -> database: Message with custom ID '1224' is 
already present in DB and has DB ID '1229'.
time="   249.327" type="debug" -> database: Checking if message with 
service-specific custom ID '1223' is present in DB.
time="   249.327" type="debug" -> database: Message with custom ID '1223' is 
already present in DB and has DB ID '1230'.
time="   249.327" type="debug" -> database: Checking if message with 
service-specific custom ID '1221' is present in DB.
time="   249.327" type="debug" -> database: Message with custom ID '1221' is 
already present in DB and has DB ID '1231'.
time="   249.328" type="debug" -> feed-downloader: Updating messages in DB took 
27394 microseconds.
time="   249.328" type="debug" -> feed-downloader: QPair(0,0) messages for feed 
29 stored in DB.
time="   249.328" type="debug" -> feed-downloader: Made progress in feed 
updates, total feeds count 1/32 (id of feed is 1).
time="   249.328" type="debug" -> feed-downloader: Downloading new messages for 
feed ID '4' URL: 'https://www.debian.org/News/news' title: 'Debian News' in 
thread: '0x7f41f3fff640'.
time="   249.328" type="debug" -> database: SQLite connection 'feed_upd' is 
already active.
time="   249.328" type="debug" -> database: SQLite database connection 
'feed_upd' to file '/home/juan/.config/RSS Guard 4/database/database.db' seems 
to be established.
time="   249.328" type="debug" -> network: Settings of BaseNetworkAccessManager 
loaded.
time="   249.331" type="debug" -> feed-model: There is request to reload feed 
model, reloading the 1 items individually.
time="   249.333" type="debug" -> feed-model: There is request to reload feed 
model, reloading the 1 items individually.
time="   249.775" type="debug" -> network: Destroying Downloader instance.
time="   249.775" type="debug" -> network: Destroying 
SilentNetworkAccessManager instance.
time="   249.775" type="critical" -> nextcloud: Feeds update failed with error 
'QNetworkReply::ContentAccessDenied'.
time="   249.775" type="debug" -> network: Settings of BaseNetworkAccessManager 
loaded.
malloc(): unaligned fastbin chunk detected
Aborted
```

Thank you for supporting Debian and free software.  Please let me know
if you need more details or I can help some other way.


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rssguard depends on:
ii  libc62.35-2
ii  libgcc-s112.2.0-5
ii  libqt5core5a 5.15.6+dfsg-2
ii  libqt5dbus5  5.15.6+dfsg-2
ii  libqt5gui5   5.15.6+dfsg-2
ii  libqt5multimedia55.15.6-2
ii  libqt5network5   5.15.6+dfsg-2
ii  libqt5qml5   5.15.6+dfsg-2
ii  libqt5sql5   5.15.6+dfsg-2
ii  libqt5sql5-sqlite5.15.6+dfsg-2
ii  libqt5webenginecore5 5.15.10+dfsg-7
ii  libqt5webenginewidgets5  5.15.10+dfsg-7
ii  libqt5widgets5   5.15.6+dfsg-2
ii  libqt5xml5   5.15.6+dfsg-2
ii  libstdc++6   12.2.0-5

rssguard recommends no packages.

rssguard suggests no packages.

-- no debconf information

Bug#989384: acpi-call-dkms: new version of linux-call-dkms in https://github.com/nix-community/acpi_call

[Víctor Cuadrado Juan]

In addition, applying the workaround fixed suspend on my
Thinkpad T450s.

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


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

Bug#989384: acpi-call-dkms: new version of linux-call-dkms in https://github.com/nix-community/acpi_call

[Víctor Cuadrado Juan]

severity 989384 critical


Raising severity to critical, as failure to fix this bug makes the
system unbootable.

It starts with system freezes, kernel errors, errors on machine boot
from efivars partition full, and then, failure to boot completely. 


For more info, see:
https://gist.github.com/roadkell/9e98db6656e28fbbf1bf51082040f67f



-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


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

Bug#989384: acpi-call-dkms: new version of linux-call-dkms in https://github.com/nix-community/acpi_call

[Víctor Cuadrado Juan]

I can confirm too that I was affected by this issue,
and bumping to 1.2.2 solved it for me.



-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


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

Bug#1002660: firmware-sof-signed: Sound/Mic does not work on Dell XPS 17 9710

[Juan Francisco Miranda Aguilar]

Package: firmware-sof-signed
Version: 1.9-1
Severity: important

Hi dear maintainer,

I have updated to the latest version, and my kernel is the latest
available for debian sid, 5.15.0-2.
and it's working fine, both, sound and mic, but when I play a video
from youtube, for example, before it
get started, I can hear like a clack sound, and the same when the
video is ended or paused, and it's always on the
same speaker, the left one. Even sometimes, I cannot hear anything on
this speaker for a while, but if I boot
on Windows, it works without any problem.

Best regards,

Juan Francisco.


El lun, 11 oct 2021 a las 19:12, Juan Francisco Miranda Aguilar (<
jfmira...@gmail.com>) escribió:

> Package: firmware-sof-signed
> Version: 1.7-1
> Severity: important
>
> Dear Maintainer,
>
> I installed the firmware-sof-signed package on a Dell XPS 17 9710 and still 
> no sound nor mic was detected.
> Any advise is welcome!
>
> Thanks!
>
> root@dell:/home/jf# lspci | grep audio
> 00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-H HD Audio 
> Controller (rev 11)
> root@dell:/home/jf# dmesg | egrep "audio|sof|snd"
> [0.852738] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [0.852739] software IO TLB: mapped [mem 
> 0x4e601000-0x52601000] (64MB)
> [1.040833] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 
> 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
> [1.040841] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 
> 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
> [2.470636] snd_hda_intel :00:1f.3: DSP detected with PCI 
> class/subclass/prog-if info 0x040100
> [2.470791] snd_hda_intel :00:1f.3: SoundWire enabled on CannonLake+ 
> platform, using SOF driver
> [2.510153] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI 
> class/subclass/prog-if info 0x040100
> [2.510215] sof-audio-pci-intel-tgl :00:1f.3: SoundWire enabled on 
> CannonLake+ platform, using SOF driver
> [2.510247] sof-audio-pci-intel-tgl :00:1f.3: enabling device ( -> 
> 0002)
> [2.510477] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI 
> class/subclass/prog-if 0x040100
> [2.510517] sof-audio-pci-intel-tgl :00:1f.3: bound :00:02.0 (ops 
> i915_audio_component_bind_ops [i915])
> [2.516978] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode
> [2.531676] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 4
> [2.532987] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading 
> firmware intel/sof/sof-tgl-h.ri
> [2.532992] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 
> 1:7:0-47d07
> [2.533026] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:18:1 
> Kernel ABI 3:18:0
> [2.533028] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man 
> header type 3 size 0x30
> [2.614333] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 
> 1:7:0-47d07
> [2.614336] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:18:1 
> Kernel ABI 3:18:0
> [3.691121] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading 
> firmware intel/sof-tplg/sof-tgl-rt711-rt1308-rt715.tplg
> [3.691129] sof-audio-pci-intel-tgl :00:1f.3: Topology: ABI 3:18:1 
> Kernel ABI 3:18:0
> [3.710385] sof-audio-pci-intel-tgl :00:1f.3: ASoC: physical link 
> SDW3-Capture (id 4) not exist
> [3.710389] sof-audio-pci-intel-tgl :00:1f.3: ASoC: topology: could 
> not load header: -22
> [3.710526] sof-audio-pci-intel-tgl :00:1f.3: error: tplg component 
> load failed -22
> [3.710531] sof-audio-pci-intel-tgl :00:1f.3: error: failed to load 
> DSP topology -22
> [3.710532] sof-audio-pci-intel-tgl :00:1f.3: ASoC: error at 
> snd_soc_component_probe on :00:1f.3: -22
> [3.710561] sof_sdw sof_sdw: ASoC: failed to instantiate card -22
> [3.720900] sof_sdw sof_sdw: snd_soc_register_card failed -22
> [3.720901] sof_sdw: probe of sof_sdw failed with error -22
>
>

Bug#1000745: wmnut: Tens digit of load level indicator isn't updated when no tens digit should be shown anymore

[Juan Leseduarte]

Package: wmnut
X-Debbugs-Cc: j.lesedua...@gmail.com 
Version: 0.66-2
Severity: normal

Dear Maintainer,

Once the variable "ups.load" ( as reported, in my case, by the command:
$ upsc cyberpower| grep load ) exceeds 10, the load value displayed by
wmnut never gets again under 10% (unless wmnut is reinitiated): when
ups.load is again under 10 after having been over 10, the tens digit is
still
shown. So, ifups.load is 9, 8, 7... wnut displays, respectively, 19%, 18%,
17%... instea dof 9%, 8%,  7%...
Another instance of wnut launched (in another X display,for example)
after AND while the ups.load value is 9% or less shows theright values.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera)
Release:4
Codename:   chimaera
Architecture: x86_64

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages wmnut depends on:
ii  libc6  2.31-13+deb11u2
ii  libupsclient4  2.7.4-13
ii  libx11-6   2:1.7.2-1
ii  libxext6   2:1.3.3-1.1
ii  libxpm41:3.5.12-1

wmnut recommends no packages.

wmnut suggests no packages.

-- no debconf information


-- 
Juan Leseduarte

Bug#1000332: libopenblas64-openmp-dev: CMAKE cannot find OpenBLAS's files

[Juan Jose Garcia Ripoll]

Package: libopenblas64-openmp-dev
Version: 0.3.13+ds-3
Severity: normal
X-Debbugs-Cc: juanjose.garciarip...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?

I try to use OpenBLAS in various open software developments which are based on 
cmake builds

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

The CMAKE files from OpenBLAS are installed in deep locations that cmake 3.18 
does not
explore. This means that OpenBLAS cannot be used from CMAKE projects. A sample 
project

cmake_minimum_required(VERSION 3.14)
project(test)
find_package(OpenBLAS REQUIRED)
add_library(test "foo.c")
target_link_libraries(test PUBLIC OpenBLAS::BLAS)

will fail at configuration time (cmake -B ./build -S . -G "Unix Makefiles" 
--debug-find)

   * What was the outcome of this action?

CMAKE fails to find OpenBLASConfig.cmake If invoked with --debug find, cmake 
will
show that it searchers for the cmake files in shallower locations

/usr/lib/x86_64-linux-gnu/openblas-pthread/OpenBLASConfig.cmake
/usr/lib/x86_64-linux-gnu/openblas-pthread/openblas-config.cmake
/usr/lib/x86_64-linux-gnu/openblas64-openmp/OpenBLASConfig.cmake
/usr/lib/x86_64-linux-gnu/openblas64-openmp/openblas-config.cmake
/usr/lib/x86_64-linux-gnu/openblas-pthread/cmake/OpenBLASConfig.cmake
/usr/lib/x86_64-linux-gnu/openblas-pthread/cmake/openblas-config.cmake
/usr/lib/x86_64-linux-gnu/openblas64-openmp/cmake/OpenBLASConfig.cmake
/usr/lib/x86_64-linux-gnu/openblas64-openmp/cmake/openblas-config.cmake

   * What outcome did you expect instead?

The OpenBLAS files should have been located in those directories for them to be 
located.
Alternatively, Debian Bullseye should have shipped with a more recent version 
of CMAKE
that searchers for OpenBLASConfig.cmake in deeper locations.

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


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

Kernel: Linux 5.10.60.1-microsoft-standard-WSL2 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libopenblas64-openmp-dev depends on:
ii  libopenblas64-0-openmp  0.3.13+ds-3

libopenblas64-openmp-dev recommends no packages.

libopenblas64-openmp-dev suggests no packages.

-- no debconf information

Bug#996165: Fwd: firmware-sof-signed: Sound/Mic does not work on Dell XPS 17 9710

[Juan Francisco Miranda Aguilar]

Package: firmware-sof-signed
Version: 1.7-1
Severity: important

Dear Maintainer,

I installed the firmware-sof-signed package on a Dell XPS 17 9710 and
still no sound nor mic was detected.
Any advise is welcome!

Thanks!

root@dell:/home/jf# lspci | grep audio
00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-H HD
Audio Controller (rev 11)
root@dell:/home/jf# dmesg | egrep "audio|sof|snd"
[0.852738] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[0.852739] software IO TLB: mapped [mem
0x4e601000-0x52601000] (64MB)
[1.040833] integrity: Loaded X.509 cert 'Microsoft Windows
Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[1.040841] integrity: Loaded X.509 cert 'Microsoft Corporation
UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[2.470636] snd_hda_intel :00:1f.3: DSP detected with PCI
class/subclass/prog-if info 0x040100
[2.470791] snd_hda_intel :00:1f.3: SoundWire enabled on
CannonLake+ platform, using SOF driver
[2.510153] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with
PCI class/subclass/prog-if info 0x040100
[2.510215] sof-audio-pci-intel-tgl :00:1f.3: SoundWire enabled
on CannonLake+ platform, using SOF driver
[2.510247] sof-audio-pci-intel-tgl :00:1f.3: enabling device
( -> 0002)
[2.510477] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with
PCI class/subclass/prog-if 0x040100
[2.510517] sof-audio-pci-intel-tgl :00:1f.3: bound
:00:02.0 (ops i915_audio_component_bind_ops [i915])
[2.516978] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode
[2.531676] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 4
[2.532987] sof-audio-pci-intel-tgl :00:1f.3: firmware:
direct-loading firmware intel/sof/sof-tgl-h.ri
[2.532992] sof-audio-pci-intel-tgl :00:1f.3: Firmware info:
version 1:7:0-47d07
[2.533026] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI
3:18:1 Kernel ABI 3:18:0
[2.533028] sof-audio-pci-intel-tgl :00:1f.3: unknown
sof_ext_man header type 3 size 0x30
[2.614333] sof-audio-pci-intel-tgl :00:1f.3: Firmware info:
version 1:7:0-47d07
[2.614336] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI
3:18:1 Kernel ABI 3:18:0
[3.691121] sof-audio-pci-intel-tgl :00:1f.3: firmware:
direct-loading firmware intel/sof-tplg/sof-tgl-rt711-rt1308-rt715.tplg
[3.691129] sof-audio-pci-intel-tgl :00:1f.3: Topology: ABI
3:18:1 Kernel ABI 3:18:0
[3.710385] sof-audio-pci-intel-tgl :00:1f.3: ASoC: physical
link SDW3-Capture (id 4) not exist
[3.710389] sof-audio-pci-intel-tgl :00:1f.3: ASoC: topology:
could not load header: -22
[3.710526] sof-audio-pci-intel-tgl :00:1f.3: error: tplg
component load failed -22
[3.710531] sof-audio-pci-intel-tgl :00:1f.3: error: failed to
load DSP topology -22
[3.710532] sof-audio-pci-intel-tgl :00:1f.3: ASoC: error at
snd_soc_component_probe on :00:1f.3: -22
[3.710561] sof_sdw sof_sdw: ASoC: failed to instantiate card -22
[3.720900] sof_sdw sof_sdw: snd_soc_register_card failed -22
[3.720901] sof_sdw: probe of sof_sdw failed with error -22

Bug#994944: libgtk-4-bin: gtk4-broadwayd not available

[Juan Pablo Ugarte]

Package: libgtk-4-bin
Version: 4.4.0+ds1-5
Severity: wishlist
X-Debbugs-Cc: juanpablouga...@gmail.com

Hi

Gtk 4 package currently does not build the broadway backend which is needed to
run Cambalache, a new tool to create gtk4 UI files.

I will eventually remove the dependency but not in the near future.

Is there any particular reason why it does not build in Debian?

https://gitlab.gnome.org/jpu/cambalache

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

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

Versions of packages libgtk-4-bin depends on:
ii  gtk-update-icon-cache 3.24.30-3
ii  libc6 2.32-4
ii  libcairo-gobject2 1.16.0-5
ii  libcairo-script-interpreter2  1.16.0-5
ii  libcairo2 1.16.0-5
ii  libepoxy0 1.5.9-1
ii  libfontconfig12.13.1-4.2
ii  libfribidi0   1.0.8-2
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.68.4-1
ii  libgraphene-1.0-0 1.10.4+dfsg1-1
ii  libgtk-4-14.4.0+ds1-5
ii  libgtk-4-common   4.4.0+ds1-5
ii  libharfbuzz0b 2.7.4-1
ii  libpango-1.0-01.48.10+ds1-1
ii  libpangocairo-1.0-0   1.48.10+ds1-1
ii  libpangoft2-1.0-0 1.48.10+ds1-1
ii  libwayland-client01.19.0-2
ii  libwayland-egl1   1.19.0-2
ii  libx11-6  2:1.7.2-2+b1
ii  libxcursor1   1:1.2.0-2
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.4-1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxinerama1  2:1.1.4-2
ii  libxkbcommon0 1.0.3-2
ii  libxrandr22:1.5.1-1

libgtk-4-bin recommends no packages.

libgtk-4-bin suggests no packages.

Bug#804235: carla packaging

[Víctor Cuadrado Juan]

On Wed, 2021-09-08 at 16:08 +0200, Yuri D'Elia wrote:
> Hi everyone, any progress on this?
> 
> I noticed carla is now packaged in ubuntu
> (https://launchpad.net/ubuntu/+source/carla) and I wonder if we could
> reuse that effort to bring carla to debian too.

Hello, On debbug #798490 (ITP bug merged with this one) I noted that
upstream (falkTX) is consciously bundling dependencies, therefore I lost
all will to tackle this RFP.

If one looks at the Ubuntu packages, it seems that they are not taking
care of that. Such a package would not get accepted in the Debian repos
as it violates the policies, and is overall detrimental to the
ecosystem.

I do not expect this situation to change, as it hasn't changed in the
last ~8 years, as Upstream (falkTX) seems to have a vetted interest,
since they receive remuneration for their work on audio-focused
distributions.



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

Bug#989220: solvespace: crashes when starting on Debian stable.

[Zuluaga, Juan P]

Thank you Bernhard,

according to your instructions, here I present:

juan@widgy:~$ gdb solvespace
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from solvespace...Reading symbols from 
/usr/lib/debug/.build-id/08/b34dccc7ada9d003ba80595f1a686a34256288.debug...done.
done.
(gdb) run
Starting program: /usr/bin/solvespace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xaf702b40 (LWP 12876)]
malloc(): invalid size (unsorted)

Thread 1 "solvespace" received signal SIGABRT, Aborted.
0xb7fd4d61 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fd4d61 in __kernel_vsyscall ()
#1  0xb6c23382 in __libc_signal_restore_set (set=0xbfffda5c) at 
../sysdeps/unix/sysv/linux/internal-signals.h:84
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb6c0d2b6 in __GI_abort () at abort.c:79
#4  0xb6c64d2c in __libc_message (action=do_abort, fmt=) at 
../sysdeps/posix/libc_fatal.c:181
#5  0xb6c6baed in malloc_printerr (str=str@entry=0xb6d775e8 "malloc(): invalid 
size (unsorted)") at malloc.c:5341
#6  0xb6c6e80b in _int_malloc (av=av@entry=0xb6dce7a0 , 
bytes=bytes@entry=236) at malloc.c:3732
#7  0xb6c70c34 in __libc_calloc (n=1, elem_size=236) at malloc.c:3428
#8  0xb312b867 in nv50_rasterizer_state_create (pipe=0xb59fa0, cso=0xc82780) at 
../src/gallium/drivers/nouveau/nv50/nv50_state.c:230
#9  0xb2ec0ea9 in cso_set_rasterizer (ctx=0xb8b3e0, templ=0xb76964) at 
../src/gallium/auxiliary/cso_cache/cso_context.c:604
#10 0xb3445465 in st_update_rasterizer (st=) at 
../src/mesa/state_tracker/st_atom_rasterizer.c:317
#11 0xb3442e0f in st_validate_state (st=0xb768c0, pipeline=ST_PIPELINE_RENDER) 
at ../src/util/bitscan.h:103
#12 0xb339fea7 in prepare_draw (ctx=0xb5b460, st=0xb768c0) at 
../src/mesa/state_tracker/st_draw.c:123
#13 st_draw_vbo (ctx=0xb5b460, prims=0xb7800c, nr_prims=1, ib=0x0, 
index_bounds_valid=1 '\001', min_index=, max_index=,
tfb_vertcount=0x0, stream=0, indirect=0x0) at 
../src/mesa/state_tracker/st_draw.c:149
#14 0xb329843e in vbo_exec_vtx_flush (exec=, keepUnmapped=1 
'\001') at ../src/mesa/vbo/vbo_exec_draw.c:393
#15 0xb3297e57 in vbo_exec_FlushVertices_internal (unmap=1 '\001', 
exec=) at ../src/mesa/vbo/vbo_exec_api.c:1255
#16 vbo_exec_FlushVertices (ctx=0xb5b460, flags=1) at 
../src/mesa/vbo/vbo_exec_api.c:1255
#17 0xb334477f in line_width (no_error=false, width=, 
ctx=0xb5b460) at ../src/mesa/main/lines.c:70
#18 _mesa_LineWidth (width=) at ../src/mesa/main/lines.c:95
#19 0x004df59f in SolveSpace::ssglLineWidth (width=) at 
./src/glhelper.cpp:97
#20 0x004b2dc1 in SolveSpace::Entity::Draw (this=0xbdbe90, drawAsHidden=false) 
at ./src/drawentity.cpp:117
#21 0x004b2ece in SolveSpace::Entity::DrawAll (drawAsHidden=false) at 
./src/drawentity.cpp:103
#22 0x0049d4d5 in SolveSpace::GraphicsWindow::Paint (this=) at 
./src/draw.cpp:724
#23 0x0048470e in SolveSpace::GraphicsWidget::on_gl_draw (this=0xb57f00) at 
./src/gtk/gtkmain.cpp:524
#24 0x00486f4f in SolveSpace::GlWidget::on_draw (cr=..., this=0xb57f00) at 
./src/gtk/gtkmain.cpp:334
#25 SolveSpace::GlWidget::on_expose_event (this=) at 
./src/gtk/gtkmain.cpp:350
#26 0xb7c8f579 in Gtk::Widget_Class::expose_event_callback(_GtkWidget*, 
_GdkEventExpose*) () from /lib/i386-linux-gnu/libgtkmm-2.4.so.1
--Type  for more, q to quit, c to continue without paging--c
#27 0xb76396e7 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#28 0xb7273138 in g_closure_invoke () from 
/lib/i386-linux-gnu/libgobject-2.0.so.0
#29 0xb72863fd in ?? () from /lib/i386-linux-gnu/libgobject-2.0.so.0
#30 0xb728f9a1 in g_signal_emit_valist () from 
/lib/i386-linux-gnu/libgobject-2.0.so.0
#31 0xb7290465 in g_signal_emit () from /lib/i386-linux-gnu/libgobject-2.0.so.0
#32 0xb775b4d4 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#33 0xb7637b71 in gtk_main_do_event () from 
/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#34 0xb74400ca in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#35 0xb7440077 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#36 0xb7470f0c in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#37 0xb743c6d4 in ?? () from /lib/i386-linux-gn

Bug#990130: Problems when mounting ZFS datasets in wrong order

[Juan Cespedes]

Package: zfsutils-linux
Version: 2.0.3-8
Severity: important

First of all, I am not really sure if this bug belongs to zfs-dkms or to
zfsutils-linux.

When mounting a parent and a child dataset in the wrong order (first
child, then parent), it is not possible to unmount any of them with
"zfs unmount" anymore:

root@cespedes:~# zfs list
NAME   USED  AVAIL REFER  MOUNTPOINT
tank   104K   832M   24K  /tank
root@cespedes:~# zfs create -p tank/foo/bar
root@cespedes:~# zfs list
NAME   USED  AVAIL REFER  MOUNTPOINT
tank   177K   832M   24K  /tank
tank/foo48K   832M   24K  /tank/foo
tank/foo/bar24K   832M   24K  /tank/foo/bar
root@cespedes:~# zfs mount
tank/tank
tank/foo/tank/foo
tank/foo/bar/tank/foo/bar
root@cespedes:~# zfs unmount tank/foo
root@cespedes:~# zfs mount tank/foo/bar
root@cespedes:~# zfs mount tank/foo
root@cespedes:~# zfs mount
tank/tank
tank/foo/bar/tank/foo/bar
tank/foo/tank/foo
root@cespedes:~# zfs unmount tank/foo/bar
cannot unmount '/tank/foo/bar': unmount failed
root@cespedes:~# zfs unmount tank/foo
cannot unmount '/tank/foo/bar': unmount failed


Best,

Juan Cespedes

Bug#989220: Output of gdb; please reclassify its severity.

[Zuluaga, Juan P]

Bug seems related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887978, 
except that the message is a bit different

cannot load settings: Resource temporarily unavailable
malloc(): invalid size (unsorted)
Aborted

instead of

cannot load settings: Resource temporarily unavailable
  malloc(): memory corruption
  Aborted

Output of gdb follows:
(gdb) run
Starting program: /usr/bin/solvespace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
cannot load settings: Resource temporarily unavailable
[New Thread 0xaf702b40 (LWP 20199)]
malloc(): invalid size (unsorted)

Thread 1 "solvespace" received signal SIGABRT, Aborted.
0xb7fd4d61 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fd4d61 in __kernel_vsyscall ()
#1  0xb6c23382 in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xb6c0d2b6 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0xb6c64d2c in ?? () from /lib/i386-linux-gnu/libc.so.6
#4  0xb6c6baed in ?? () from /lib/i386-linux-gnu/libc.so.6
#5  0xb6c6e80b in ?? () from /lib/i386-linux-gnu/libc.so.6
#6  0xb6c70c34 in calloc () from /lib/i386-linux-gnu/libc.so.6
#7  0xb312b867 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#8  0xb2ec0ea9 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#9  0xb3445465 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#10 0xb3442e0f in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#11 0xb339fea7 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#12 0xb329843e in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#13 0xb3297e57 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#14 0xb334477f in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#15 0x004df59f in SolveSpace::ssglLineWidth (width=) at 
./src/glhelper.cpp:97
#16 0x004b2dc1 in SolveSpace::Entity::Draw (this=0xbd8b20, drawAsHidden=false)
at ./src/drawentity.cpp:117
#17 0x004b2ece in SolveSpace::Entity::DrawAll (drawAsHidden=false) at 
./src/drawentity.cpp:103
#18 0x0049d4d5 in SolveSpace::GraphicsWindow::Paint (this=) at 
./src/draw.cpp:724
#19 0x0048470e in SolveSpace::GraphicsWidget::on_gl_draw (this=0xb4a180) at 
./src/gtk/gtkmain.cpp:524
#20 0x00486f4f in SolveSpace::GlWidget::on_draw (cr=..., this=0xb4a180) at 
./src/gtk/gtkmain.cpp:334
#21 SolveSpace::GlWidget::on_expose_event (this=) at 
./src/gtk/gtkmain.cpp:350
#22 0xb7c8f579 in Gtk::Widget_Class::expose_event_callback(_GtkWidget*, 
_GdkEventExpose*) ()
   from /lib/i386-linux-gnu/libgtkmm-2.4.so.1
#23 0xb76396e7 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#24 0xb7274128 in g_closure_invoke () from 
/lib/i386-linux-gnu/libgobject-2.0.so.0
#25 0xb72873ed in ?? () from /lib/i386-linux-gnu/libgobject-2.0.so.0
#26 0xb7290961 in g_signal_emit_valist () from 
/lib/i386-linux-gnu/libgobject-2.0.so.0
#27 0xb7291425 in g_signal_emit () from /lib/i386-linux-gnu/libgobject-2.0.so.0
#28 0xb775b4d4 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#29 0xb7637b71 in gtk_main_do_event () from 
/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#30 0xb74400ca in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#31 0xb7440077 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#32 0xb7470f0c in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#33 0xb743c6d4 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#34 0xb743d052 in gdk_window_process_all_updates () from 
/lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#35 0xb75b8cc3 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#36 0xb741a8c5 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#37 0xb68a2e65 in g_main_context_dispatch () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
#38 0xb68a3269 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#39 0xb68a3609 in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#40 0xb7636675 in gtk_main () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#41 0xb7c1ec8e in Gtk::Main::run(Gtk::Window&) () from 
/lib/i386-linux-gnu/libgtkmm-2.4.so.1
#42 0x004624bf in main (argc=, argv=)
at /usr/include/c++/8/bits/unique_ptr.h:342
(gdb) quit

---
Please reclassify the severity of bug: it prevents me to use the program 
itself, but as far as I can see, it does not affect other parts of the system.

Bug#989220: solvespace: crashes when starting on Debian stable.

[Juan Zuluaga]

Package: solvespace
Version: 2.3+repack1-3+b1
Severity: normal
Tags: a11y

Dear Maintainer,

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

   * What led up to the situation?
 Starting the program from gui menu produced a flash on screen but
 nothing else. Then I started the program from command line, and error
 message appeared.  Starting program as 
 > solvespace --help
 starts showing some graphs, but when I try to interact, program
 crashes.

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

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


-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages solvespace depends on:
ii  libatkmm-1.6-1v52.28.0-2
ii  libc6   2.28-10
ii  libcairomm-1.0-1v5  1.12.2-4
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.1.0-1
ii  libglew2.1  2.1.0-4
ii  libglib2.0-02.58.3-2+deb10u2
ii  libglibmm-2.4-1v5   2.58.0-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libgtk2.0-0 2.24.32-3
ii  libgtkmm-2.4-1v51:2.24.5-4
ii  libjson-c3  0.12.1+ds-2+deb10u1
ii  libpangomm-1.4-1v5  2.42.0-2
ii  libpng16-16 1.6.36-6
ii  libsigc++-2.0-0v5   2.10.1-2
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1+deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

solvespace recommends no packages.

solvespace suggests no packages.

-- no debconf information

Bug#943703: stremio on the official debian archive

[Juan Mendez]

I will be happy to contribute on this. I will take a look.

Bug#941156: guitarix: Typo in the package description

[Víctor Cuadrado Juan]

Package: guitarix
Followup-For: Bug #941156

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Many thanks for reporting this.

Closing, fixed by commit 8a08da62.
See:
  
https://salsa.debian.org/multimedia-team/guitarix/commit/8a08da62bbc23d70671ad83d96722cce31684ee5


Cheers,

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAl5FMyYACgkQIj8Vylqv
Dni+fgf+PR/Dywgmb7ONfemJrwNEcwQsxmFylU2UqhBOfbJWXsmfX0/CbIU94XHk
MidaCD1XIWYusUeEt025avs9JQlpHoLB3WdIVSiTWsHFQ5/J+jrEPdQu6M4qmHW7
ENL5Vm4SWxZi+IwnAyL3TiF7Do+RDnV+PUNKvO0ZmRr8xbU++ctDax9WEF5F/k4Q
r6UzenPe7gXBJbGI/tuywqmxGXoxkCAPabsMnJr9+L83g8OYBr821gKc3yWmsVdN
aODS8HhNQsRnSlKtceFmEJi2lZ/K7w1/J73Al1dxCO2xBCNs+2pWDYKiaZ14S/7A
7M5ruDwyJwnnHTsXVtZDJSN52vxzbw==
=eGq/
-END PGP SIGNATURE-

Bug#940659: starts editing in wrong line

[Juan Cespedes]

Package: ldapvi
Version: 1.7-10+b3
Severity: normal
Tags: patch

When using "ldapvi" without SASL, ldapvi starts editing the LDAP results
at an undefined line number instead of just below the initial comments.

This patch fixes it:

--- ldapvi-1.7.orig/ldapvi.c
+++ ldapvi-1.7/ldapvi.c
@@ -1465,7 +1465,7 @@ copy_sasl_output(FILE *out, char *sasl)
int line = 0;
int c;
 
-   if (lstat(sasl, &st) == -1) return;
+   if (lstat(sasl, &st) == -1) return line;
if ( !(in = fopen(sasl, "r"))) syserr();
 
if (st.st_size > 0) {

Bug#939094: Please consider shipping python3-firewall

[Víctor Cuadrado Juan]

Package: firewalld
Version: 0.7.1-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

Please consider shipping python3-firewall, included in the sources of firewalld.
With the move to python3, there's other packages that would get enhanced
functionality from python3 bindings to firewalld, for example ansible.


Kind regards,
Víctor Cuadrado Juan


- -- 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)
Foreign Architectures: i386

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

Versions of packages firewalld depends on:
ii  dbus 1.12.16-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  init-system-helpers  1.57
ii  iptables 1.8.3-2
ii  policykit-1  0.105-26
ii  python3  3.7.3-1
ii  python3-dbus 1.2.8-3
ii  python3-gi   3.32.2-1
ii  python3-slip-dbus0.6.5-2

Versions of packages firewalld recommends:
pn  ipset  

firewalld suggests no packages.

- -- Configuration Files:
/etc/firewalld/firewalld.conf [Errno 13] Permission denied: 
'/etc/firewalld/firewalld.conf'
/etc/firewalld/lockdown-whitelist.xml [Errno 13] Permission denied: 
'/etc/firewalld/lockdown-whitelist.xml'

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAl1rkasACgkQIj8Vylqv
DngnUggAw5+lscY8yBClCrENSURzp9M4yblScLBTkjgsxykf1HJMMbblybKtZAoO
TwlD7l0dIX4BweNOhrRktsEi/z1VVSeDa8Gjlb5wm9vqFEiaxtHVjL4uB/W16Bel
GHrzEjWM7/9bAAn8dG34SJDEdibCx8GH4B7AuNod4KSi2D/o/AXy4NZD4DNexVlP
7vcbcG3ivjTjiaK9mqntQxq9VAKsTYbKih95/Z0t9py0A8O9EXiQ+aEIKyb08iKq
EVTjqMn4rS/Yh8P8bEBn4V91O1Kk8u66X1u90ai2bvtaAA++Y/i5RVbq7PRn6AQr
ell8gFuF7b0XftkE0tv9ZPFaFpVKAA==
=bRsX
-END PGP SIGNATURE-

Bug#935374: mate-desktop-environment: recommends the installation of gvfs-fuse

[Juan Picca]

Package: mate-desktop-environment
Severity: normal

With the default instalation of mate desktop using tasksel (package
`task-mate-desktop`) the package `gvfs-fuse` does not install.
`gvfs-fuse` is needed to access the filesystems mounted with gio
from the console.
As an example, when a user mounts a samba shared folder using `gio
mount`, the package is needed to access the files from the console
(accessing to `/run/user/$UID/gvfs`).

The calculation of the reverse dependencies for `gvfs-fuse`
(`apt-cache rdepends gvfs-fuse`) shown that the majority of desktops
installs it (with the exception of kde and lxde):

* gnome-core: depends
* pcmanfm-qt: recommends (pcmanfm-qt is a dependency of lxqt-core)
* pcmanfm: recommends (pcmanfm is a dependency of lxde-core)
* nemo: recommends (nemo is a dependency of cinnamon-core)
* cinnamon-core: recommends

Why i think that the recommends dependency need to be added to the
package mate-desktop-environment instead of
mate-desktop-environment-core?
According to the description of the packages, the package
mate-desktop-environment *recommends* the standard set of applications
of the mate desktop meanwhile the package mate-desktop-environment-core
*depends* on a very basic set of programs in order to start the
desktop session.

Bug#920225: pv: replace ash shell with dash

[Juan Picca]

Hi Andrew!
Thanks for take the time to see it.
Regards,
Juan Picca

On Sun, Feb 10, 2019 at 8:03 PM Andrew Wood  wrote:

> Thanks for this discussion and for the patch.  I have no idea why this
> script uses ash instead of sh.  Digging into its history a little bit I see
> that it has been unchanged since December 2003, so who knows what I was
> thinking.
>
> It will use /bin/sh in the next release.
>
>
> On Tue, Jan 22, 2019 at 09:53:16PM -0500, Antoine Beaupre wrote:
> > On Tue, Jan 22, 2019 at 09:01:21PM -0300, Juan Picca wrote:
> > > Closed as not directly related to debian.
> > > Thanks Antoine for your comments and sorry for the noise.
> >
> > Glad I could be of service.
> >
> > And no problem at all for the noise, I believe it was a fine patch, it's
> > just we don't need it in Debian specifically. I would suggest you
> > contact upstream here:
> >
> > https://www.ivarch.com/personal/contact.shtml
> >
> > They are usually quite supportive and responsive to patches, bug reports
> > and suggestions. Don't expect a response immediately, however, they take
> > their time, which is fine. :)
>
> --
> Andrew Wood
>

Bug#920644: Update

[Juan Picca]

Update for bug 920642 (closed):

gargoyle-free doesn't use the script that use the ash shell.

Bug#920642: gargoyle-free: Replace /bin/ash shell with /bin/sh

[Juan Picca]

Thanks for the info Sylvain!

Regards,
Juan Picca

Bug#920644: ash: consider the removal of the ash package

[Juan Picca]

Package: ash
Severity: wishlist

Dear maintainer,

According the description of the ash package, it is a compatibility
package awaiting that /bin/ash be not longer used for delete it.

With the close of bug 919992, no package depends of ash in sid.

Also, according codesearch, only a fews packages use ash as shell
(https://codesearch.debian.net/search?q=%23!%2Fbin%2Fash):

* dnsmasq: bug 920224 - waiting for maintainer response
* pv: bug 920225 (closed) - according Antoine not related to debian,
  the script is not directly used (autoconf/scripts/index.sh)
* gargoyle-free: bug 920642 - waiting for maintainer response
* qsf: not bug filled - same situation as pv

Regards,
Juan Picca

Bug#920642: gargoyle-free: Replace /bin/ash shell with /bin/sh

[Juan Picca]

Package: gargoyle-free
Version: 2011.1b-1
Severity: wishlist
Tags: upstream patch

Dear maintainer,

Currently the ash shell is not widely used and was superseded by dash
shell in debian.
The attached patch replace it with dash shell.

When ash shell be removed of all scripts using it, the ash package may
be removed from debian.
(Only four packges left according codesearch:
https://codesearch.debian.net/search?q=%23!%2Fbin%2Fash)

Regards,
Juan Picca.

Note: The patch was upstreamed
Description: Replace /bin/ash shell with /bin/sh
 Use /bin/sh as the majority of the scripts does.
 Currently the ash shell is not widely used and was superseded by dash
 shell in many linux distributions.
Author: Juan Picca 
Forwarded: https://github.com/garglk/garglk/pull/342
Last-Update: 2019-01-23
---
--- a/terps/nitfol/nitfol
+++ b/terps/nitfol/nitfol
@@ -1,4 +1,4 @@
-#!/bin/ash
+#!/bin/sh
 # This is a shell wrapper that finds an appropriate nitfol in your path
 # and runs it.  Requires 'which' and sh.  (only tested with bash, so YMMV)
 

Bug#920225: pv: replace ash shell with dash

[Juan Picca]

> I see. But the script is not shipped with the pv binary package and is
> unlikely to be ever called. At least it isn't called during build,
> unless I'm mistaken...

You are right in that, but if has sense that somebody (maybe a
developer) execute `make index` i think that this patch equally apply.
If not, please tell me and I close this bug.

Regards,
Juan Picca

Bug#920225: pv: replace ash shell with dash

[Juan Picca]

Hi Antoine,
Thanks for your fast response.

The ash shell is not installed by default and the package pv (or its
dependencies) don't depend of it.
Due that, the script can fail if executed.
Also, the ash package was supersedeed by dash and this is one of the
few (less than ten) packages that uses it.

Regards,
Juan Picca

On Tue, Jan 22, 2019 at 6:33 PM Antoine Beaupré  wrote:
>
> On 2019-01-22 18:18:00, Juan Picca wrote:
> > Package: pv
> > Version: 1.6.6-1
> > Severity: wishlist
> > Tags: patch
> >
> > Dear maintainer,
> >
> > One script in autoconf directory uses the ash shell, which is replaced
> > in debian with the dash shell.
> >
> > Regards,
> > Juan Picca
> > Description: Replace usage of ash with dash
> >  Replace usage of ash shell with dash (/bin/sh).
> > Author: Juan Picca 
> > Last-Update: 2019-01-22
> > ---
> > --- a/autoconf/scripts/index.sh
> > +++ b/autoconf/scripts/index.sh
> > @@ -1,4 +1,4 @@
> > -#!/bin/ash
> > +#!/bin/sh
> >  #
> >  # Script to generate an HTML index of all C code from the current directory
> >  # downwards (skipping directories ending in ~). The header comment in each
>
> Hi!
>
> Thanks for your bug report.
>
> Could you clarify what problem this patch fixes exactly?
>
> A.
>
> --
> L'adversaire d'une vraie liberté est un désir excessif de sécurité.
> - Jean de la Fontaine

Bug#920225: pv: replace ash shell with dash

[Juan Picca]

Package: pv
Version: 1.6.6-1
Severity: wishlist
Tags: patch

Dear maintainer,

One script in autoconf directory uses the ash shell, which is replaced
in debian with the dash shell.

Regards,
Juan Picca
Description: Replace usage of ash with dash
 Replace usage of ash shell with dash (/bin/sh).
Author: Juan Picca 
Last-Update: 2019-01-22
---
--- a/autoconf/scripts/index.sh
+++ b/autoconf/scripts/index.sh
@@ -1,4 +1,4 @@
-#!/bin/ash
+#!/bin/sh
 #
 # Script to generate an HTML index of all C code from the current directory
 # downwards (skipping directories ending in ~). The header comment in each

Bug#920224: dnsmasq: replace ash shell with dash

[Juan Picca]

Package: dnsmasq
Version: 2.80-1
Severity: wishlist
Tags: patch

Dear maintainer,

One example in contrib directory uses the ash shell, which was
superseeded in debian with the dash shell.

Regards,
Juan Picca
diff -urN dnsmasq-2.80.orig/contrib/reverse-dns/README 
dnsmasq-2.80/contrib/reverse-dns/README
--- dnsmasq-2.80.orig/contrib/reverse-dns/README2018-09-17 
20:11:25.0 -0300
+++ dnsmasq-2.80/contrib/reverse-dns/README 2019-01-22 17:51:20.154630335 
-0300
@@ -14,5 +14,5 @@
 
 in the dnsmasq configuration.
 
-The script runs on debian (with ash installed) and on busybox.
+The script runs on debian (with dash installed) and on busybox.
 
diff -urN dnsmasq-2.80.orig/contrib/reverse-dns/reverse_replace.sh 
dnsmasq-2.80/contrib/reverse-dns/reverse_replace.sh
--- dnsmasq-2.80.orig/contrib/reverse-dns/reverse_replace.sh2018-09-17 
20:11:25.0 -0300
+++ dnsmasq-2.80/contrib/reverse-dns/reverse_replace.sh 2019-01-22 
17:51:28.178673463 -0300
@@ -1,4 +1,4 @@
-#!/bin/ash
+#!/bin/dash
 # $Id: reverse_replace.sh 18 2015-03-01 16:12:35Z jo $
 #
 # Usage e.g.: netstat -n -4 | reverse_replace.sh 

Bug#919992: drbl: Remove/replace ash dependency

[Juan Picca]

Package: drbl
Version: 2.20.11-6
Severity: wishlist

Dear Maintainer,

Your package is the only one that use the package ash as dependency.

If you can change it for the package dash, the functionality remain unchanged
and the dash source package can remove the creation of the ash package.

Also, inspecting the files in drbl package, i can't see the usage of ash/dash
shell; the only one used is bash.

Regards,
Juan Picca

Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree

[Juan Picca]

Hi Reinhard.

I don't know if skopeo works (and how) with the sjoerdsimons fork.
Personally, I prefer using the upstream project
(https://github.com/ostreedev/ostree-go) to minimize divergences and
also due that is the code used and tested with skopeo.

But, through the pull request and the issue from Jul 27, 2017 in
github, I can see the efforts of Sjoerd to work in the upstream
project and the little response obtained, and then understand the
fork.
Due my little experience in this matters, I add Andrej who is
currently working with golang-github-sjoerdsimons-ostree-go and if he
think that the Sjoerd fork is a viable replacement we can use it,
close this ITP and remove the golang-github-ostreedev-ostree-go to
avoid future confusions.

Regards,
JMPC

Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree

[Juan Picca]

Hi Reinhard.

As commented previously, I update the package to the version currently
used by skopeo (56f3a63).
If you can upload the files tell me and i send you the build results.
If not please give me some time to find a sponsor to upload the package.

Regards,
JMPC

Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree

[Juan Picca]

Hi Reinhard.

Currently ostree-go, commit d0388bd (master HEAD today) fails some tests:

```
=== RUN   TestCommitTreeSuccess
--- FAIL: TestCommitTreeSuccess (0.11s)
commit_test.go:108: failed to tar populated dir: read
/tmp/otbuiltin-test-179055475/commit1: is a directory
=== RUN   TestCommitTreeParentSuccess
--- FAIL: TestCommitTreeParentSuccess (0.05s)
commit_test.go:169: failed to tar populated dir: read
/tmp/otbuiltin-test-662857270/commit1: is a directory
```

My first intention was package all skopeo dependencies, then skopeo,
then upload all packages.
Sadly, it showed very ambitious and I can't had the time to do it.

If i remember well, the version from 'Sjoerd Simons' pass all the tests.

About the ITP, if help, i can update the version to the one used by
skopeo (currently 56f3a63,
https://github.com/containers/skopeo/blob/master/vendor.conf) and
exclude the failing tests.
I never had upload a package to debian, maybe you can do it from the
repository if time is pressing.

Regards,
JMPC

On Wed, Jan 9, 2019 at 11:58 AM Alexandre Viau  wrote:
>
> On 2019-01-09 6:54 a.m., Reinhard Tartler wrote:
> > Hi Juan,
> >
> > are you still working on this ITP? I was looking at skopeo as well,
> > and stumpled upon this ITP. I noticed that you created a repository on
> > salsa:
> >
> > https://salsa.debian.org/go-team/packages/golang-github-ostreedev-ostree-go
> >
> > This package never got uploaded.
> >
> > However, I also noticed that there is another packaging repo in salsa,
> > which contains a similar package that did get uploaded:
> >
> > https://salsa.debian.org/go-team/packages/golang-github-sjoerdsimons-ostree-go
> > https://tracker.debian.org/pkg/golang-github-sjoerdsimons-ostree-go
> >
> > I wonder what the relationship between these two are. It seems that the
> > sjoerdsimons
> > version does declare it satisfies the import of the
> > github:ostreedev/ostree-go repo,
> > which makes me believe it is a fork.
>
> Looking at the upstream website will show you that yes it is a fork.
> (forked from ostreedev/ostree).
>
> > If this is the case, can we consider this ITP abandoned and close it?
>
> You need the package for skopeo but you want to close the ITP? I don't
> understand what is your end goal here.
>
> Unless the package is not needed in Debian anymore, we wouldn't close
> ITPs if they were abandoned. Instead, we would change them into RFPs.
>
> If you want to take over the ITP, the thing to do would be to assign it
> to you.
>
> Cheers,
>
> --
> Alexandre Viau
> av...@debian.org
>

Bug#917778: supercat: make supercat reproducible adding debhelper

[Juan Picca]

Package: supercat
Version: 0.5.5-4.3
Severity: normal
Tags: patch
Usertags: fileordering locale umask

Dear Maintainer,

While working on the "reproducible builds" effort [1], we have noticed
that supercat could not be built reproducibly.

The attached patch (make-reproducible-adding-debhelper.patch) adds
debhelper to build the package, removing reproducibility issues.

Also, a second patch (fix-lintian-issues.patch) is added to fix some
lintian issues.

Regards,
JMPC

[1]: https://wiki.debian.org/ReproducibleBuilds
diff -urN supercat-0.5.5.old/debian/compat supercat-0.5.5/debian/compat
--- supercat-0.5.5.old/debian/compat2016-08-02 03:45:06.0 +
+++ supercat-0.5.5/debian/compat2018-12-28 13:59:14.374775078 +
@@ -1 +1 @@
-5
+11
diff -urN supercat-0.5.5.old/debian/control supercat-0.5.5/debian/control
--- supercat-0.5.5.old/debian/control   2016-08-02 16:45:18.0 +
+++ supercat-0.5.5/debian/control   2018-12-28 13:59:41.158359483 +
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Kumar Appaiah 
-Build-Depends: autotools-dev, quilt, autoconf, automake
+Build-Depends: debhelper (>= 11)
 Standards-Version: 3.8.3
 Homepage: http://supercat.nosredna.net/
 Vcs-Browser: http://git.debian.org/?p=users/akumar/supercat.git
diff -urN supercat-0.5.5.old/debian/rules supercat-0.5.5/debian/rules
--- supercat-0.5.5.old/debian/rules 2016-08-02 08:57:31.0 +
+++ supercat-0.5.5/debian/rules 2018-12-28 12:02:39.513188272 +
@@ -1,117 +1,4 @@
 #!/usr/bin/make -f
-# -*- makefile -*-
-
-export SOURCE_DATE_EPOCH = $(shell date -d "$$(dpkg-parsechangelog --count 1 
-SDate)" +%s)
-
-# Package name
-PACKAGE_NAME = supercat
-
-# Install program
-INSTALL = install
-
-INSTALL_FILE= $(INSTALL) -p-o root -g root  -m  644
-INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
-INSTALL_SCRIPT  = $(INSTALL) -p-o root -g root  -m  755
-INSTALL_DIR = $(INSTALL) -p -d -o root -g root  -m  755
-
-
-# The installation directory
-PACKAGE_DIR = debian/$(PACKAGE_NAME)
-
-CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
-LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
-
-ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
-CROSS= --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
-else
-CROSS= --build $(DEB_BUILD_GNU_TYPE)
-endif
-
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-INSTALL_PROGRAM += -s
-endif
-
-configure:
-   cp -f configure.ac configure.ac.bak
-   autoupdate configure.ac
-   autoreconf --force --install --symlink --warnings=all
-   ./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
-
-config.status: configure
-   $(checkdir)
-ifneq "$(wildcard /usr/share/misc/config.sub)" ""
-   cp -f /usr/share/misc/config.sub config.sub
-endif
-ifneq "$(wildcard /usr/share/misc/config.guess)" ""
-   cp -f /usr/share/misc/config.guess config.guess
-endif
-
-
-build: build-stamp
-
-build-stamp: config.status
-   $(checkdir)
-   $(MAKE)
-   touch $@
-
-clean: checkroot
-   $(checkdir)
-   rm -f build-stamp
-   [ ! -f Makefile ] || $(MAKE) distclean
-   rm -f config.sub config.guess config.log
-   rm -rf $(PACKAGE_DIR) debian/files debian/substvars
-   test -e configure.ac.bak && mv -f configure.ac.bak configure.ac || true
-   rm -f Makefile.in */Makefile.in aclocal.m4 config.h.in configure
-   rm -f compile install-sh missing depcomp
-   rm -rf autom4te.cache/
-
-install: checkroot build
-   $(checkdir)
-   $(MAKE) DESTDIR=$(CURDIR)/$(PACKAGE_DIR) install
-
-# Build architecture-independent files here.
-binary-indep: checkroot build install
-# We have nothing to do by default.
-
-# Build architecture-dependent files here.
-binary-arch: checkroot build install
-   $(checkdir)
-   $(INSTALL_DIR) $(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)/
-   for i in doc/spc.txt debian/README.Debian;do \
-   $(INSTALL_FILE) -m 644 $$i 
$(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)/; \
-   done;
-   $(INSTALL_FILE) -m 644 ChangeLog 
$(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)/changelog
-   $(INSTALL_FILE) -m 644 debian/changelog 
$(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)/changelog.Debian
-   for i in $(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)/changelog*;do \
-   gzip -9nv $$i; \
-   done;
-   $(INSTALL_FILE) -m 644 debian/copyright 
$(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)/copyright
-   $(INSTALL_DIR) $(PACKAGE_DIR)/etc/$(PACKAGE_NAME)
-   $(INSTALL_DIR) $(PACKAGE_DIR)/usr/share/man/man1
-   $(INSTALL_FILE) -m 644 doc/spc.1 $(PACKAGE_DIR)/usr/share/man/man1
-   gzip -9nv $(PACKAGE_DIR)/usr/share/man/*/*
-# Strip binaries (including hack by policy wonks)
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   strip -R.note -R.comment $(PACKAGE_DIR)/usr/bin/*
-endif
-   dpkg-shlibdeps $(PACKAGE_DIR)/us

Bug#907199: Should the weboob package stay in Debian?

[Juan Jiménez]

The Anti Harassment Team must be disbanded immediately and without recourse
as its name is offensive. It contains the word "ass."  Unless of course it
is a reference to the intelligence of its members.

On Wed, 26 Sep 2018 01:02:34 +0100 =?UTF-8?Q?Mart=c3=adn_Ferrari?= <
tin...@debian.org> wrote:
> Hi all,
>
> I am writing on behalf of the Anti-Harassment team, as our input has
> been requested on this issue.
>
> Our understanding, after reading the mail threads and bug reports, is
> that the package in its current shape is against the Debian CoC ("be
> respectful") -- while it's not a "flagrant" violation,
>
> As Gregor Herrmann eloquently[1] put it, it's "not ok to use the boobs
> theme for a web scraper or other software unrelated to boobs [sic]
> themselves, where its only function is to make a small group of users
> giggle while objectifying, offending or boring the rest of the world."
>
> We appreciate uploading a new version without the insults (and thank
> Jonathan Dowland for his efforts[2][3] on this front). Please note that
> the insults and homophobic language *is* a flagrant violation of
> Debian's CoC and in our opinion, Debian should not ship new software
> including them.
>
> We believe the next release should not contain the package in question
> in its current state; our recommendation would be to either work with
> upstream on correcting these issues, forking and/or patching it, or just
> removing the package. There is still enough time to find a solution that
> respects our users and our community while keeping a useful piece of
> software in the archive. We would also encourage all parties to be
> respectful, and to observe the community needs for a healthy environment
> where such puerile humour taken at the expense of other people is not
> acceptable any more.
>
> If this dispute cannot be resolved amicably and timely, we believe the
> FTP-master team can -and should- unilaterally remove the package from
> the archive. We think that invoking the CTTE or calling a GR would
> unnecessarily cause more disruption and draw energy from the community.
>
>
> Martín Ferrari, on behalf of the Anti-Harassment team.
>
>
> [1]: https://lists.debian.org/debian-devel/2018/07/msg00428.html
> [2]: https://git.weboob.org/weboob/devel/merge_requests/228
> [3]: https://git.weboob.org/weboob/devel/issues/154
>
> --
> Martín Ferrari (Tincho)
>

Bug#907199: Should the weboob package stay in Debian?

[Juan Jiménez]

Pandering to the monkeys is hardly a way to run your organization. Have you
checked how many OTHER packages are named with the letters "boob" in your
repo? Please. The correct decision is to tell the monkeys to get a life.

On Wed, 26 Sep 2018 01:02:34 +0100 =?UTF-8?Q?Mart=c3=adn_Ferrari?= <
tin...@debian.org> wrote:
> Hi all,
>
> I am writing on behalf of the Anti-Harassment team, as our input has
> been requested on this issue.
>
> Our understanding, after reading the mail threads and bug reports, is
> that the package in its current shape is against the Debian CoC ("be
> respectful") -- while it's not a "flagrant" violation,
>
> As Gregor Herrmann eloquently[1] put it, it's "not ok to use the boobs
> theme for a web scraper or other software unrelated to boobs [sic]
> themselves, where its only function is to make a small group of users
> giggle while objectifying, offending or boring the rest of the world."
>
> We appreciate uploading a new version without the insults (and thank
> Jonathan Dowland for his efforts[2][3] on this front). Please note that
> the insults and homophobic language *is* a flagrant violation of
> Debian's CoC and in our opinion, Debian should not ship new software
> including them.
>
> We believe the next release should not contain the package in question
> in its current state; our recommendation would be to either work with
> upstream on correcting these issues, forking and/or patching it, or just
> removing the package. There is still enough time to find a solution that
> respects our users and our community while keeping a useful piece of
> software in the archive. We would also encourage all parties to be
> respectful, and to observe the community needs for a healthy environment
> where such puerile humour taken at the expense of other people is not
> acceptable any more.
>
> If this dispute cannot be resolved amicably and timely, we believe the
> FTP-master team can -and should- unilaterally remove the package from
> the archive. We think that invoking the CTTE or calling a GR would
> unnecessarily cause more disruption and draw energy from the community.
>
>
> Martín Ferrari, on behalf of the Anti-Harassment team.
>
>
> [1]: https://lists.debian.org/debian-devel/2018/07/msg00428.html
> [2]: https://git.weboob.org/weboob/devel/merge_requests/228
> [3]: https://git.weboob.org/weboob/devel/issues/154
>
> --
> Martín Ferrari (Tincho)
>

Bug#906119: Gratuitous sexual references

[Juan Jiménez]

Ian, you clearly need to get a life. Or an enema.

On Tue, 14 Aug 2018 14:36:29 +0100 Ian Jackson <
ijack...@chiark.greenend.org.uk> wrote:
> Package: weboob
> Version: 1.3-1
> Severity: serious
>
> Hi.
>
> As has been extensively discussed elsewhere (eg [1]), this package has
> some unfortunate sexual references.  These problems include:
>  * Command names which contain sexual references
>  * Sexually suggestive icons etc.
> There are, I suspect, other problems.  The sexualised content is both
> gratuitous and unambiguous.
>
> IMO this is in conflict with with Debian's values, in particular those
> underlying the Diversity Statement.  gregor herrmann explained very
> well why this is unacceptable here [0].  As you know, the matter has
> been discussed with upstream.  It appears that upstream are,
> unfortunately, not willing to change this. [2]
>
> This situation is very unfortunate.  As I understand it the package
> itself is very useful for some otherwise difficult situations.
> However, IMO the problems are sufficiently serious that the package as
> it is is not suitable for Debian, no matter how useful it is.
>
> So, given that upstream have rejected requests for change, IMO the
> available responses for the Debian project are to bowdlerise the
> package (that is, to rename the commands, review the documentation,
> change the icons, and so on), or to remove the package.
>
> It seems to me from reading the thread on -devel that a substantial
> majority of the Debian contributors there agree with that conclusion.
> Accordingly I have marked this bug as "serious".
>
>
> I think I need to make some points about the right process for
> handling this disagreement:
>
> Of course these postings to -devel may not represent a real view of
> the project's consensus.  Mailing list traffic is not a particularly
> good way of judging these matters.  A better guide is the Diversity
> Statement GR, perhaps: although it is not directly on point, the
> majority in favour was overwhelming.  Nevertheless there is probably
> some room for differing assessments of the project's overall view.
>
> While there is no requirement for a package maintainer to abide by the
> project consensus, whether a package is suitable for the release is
> ultimately a matter for the Release Team.  On a matter like this I
> would expect the Release Team to follow what they see as the project's
> rough consensus.
>
> I had hoped that this matter could be brought to a satisfactory
> resolution amicably.  However that does not now appear to be possible.
> The discussion on -devel is becoming a distraction.  IMO we need to
> bring it to a close.
>
> I consider this matter important, and I am convinced that the project
> consensus is with me.  Under the circumstances it would be quite wrong
> to just drop it, and accept the unacceptable status quo.
>
> So that is why I am filing this bug now.  If you as maintainer

Bug#915629: git-buildpackage: Allow --ignore-branch for 'gbp pq'

[Juan Navarro]

On 7/12/18 9:16, Guido Günther wrote:

Hi,
On Fri, Dec 07, 2018 at 12:37:01AM +0100, Juan Navarro wrote:

On 5/12/18 14:18, Guido Günther wrote:

Hi,
On Wed, Dec 05, 2018 at 01:45:59PM +0100, Juan Navarro wrote:

Source: git-buildpackage
Version: 0.9.10
Severity: wishlist

When trying to import the patch-queue from a checked out state that is not on a
branch (e.g. from a previous commit which is not the master HEAD), the command
'gbp pq import' fails with

gbp:error: Currently not on a branch

Which is expected, but it would be nice and useful being able to provide a
'--ignore-branch' arg to just force importing the patch queue from the current
commit.

That makes sense and would be consistent with other commands. A patch
would be welcome.
   -- Guido

I'm not used to discuss code changes with sending patches and corrections
back and forth by email, on the other hand I see you have some Pull Requests
open in Github... is it ok if I open one and discuss changes in there?

Yes.
  -- Guido


Created Pull Request #64 on Github, for review:
https://github.com/agx/git-buildpackage/pull/64

Thanks,
Juan

Bug#915629: git-buildpackage: Allow --ignore-branch for 'gbp pq'

[Juan Navarro]

On 5/12/18 14:18, Guido Günther wrote:

Hi,
On Wed, Dec 05, 2018 at 01:45:59PM +0100, Juan Navarro wrote:

Source: git-buildpackage
Version: 0.9.10
Severity: wishlist

When trying to import the patch-queue from a checked out state that is not on a
branch (e.g. from a previous commit which is not the master HEAD), the command
'gbp pq import' fails with

gbp:error: Currently not on a branch

Which is expected, but it would be nice and useful being able to provide a
'--ignore-branch' arg to just force importing the patch queue from the current
commit.

That makes sense and would be consistent with other commands. A patch
would be welcome.
  -- Guido


I'm not used to discuss code changes with sending patches and 
corrections back and forth by email, on the other hand I see you have 
some Pull Requests open in Github... is it ok if I open one and discuss 
changes in there?

Bug#915629: git-buildpackage: Allow --ignore-branch for 'gbp pq'

[Juan Navarro]

Source: git-buildpackage
Version: 0.9.10
Severity: wishlist

When trying to import the patch-queue from a checked out state that is not on a
branch (e.g. from a previous commit which is not the master HEAD), the command
'gbp pq import' fails with

gbp:error: Currently not on a branch

Which is expected, but it would be nice and useful being able to provide a
'--ignore-branch' arg to just force importing the patch queue from the current
commit.



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

Kernel: Linux 4.13.0-39-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Juan Picca]

About issues: We can't change where the users create bug reports, only
suggest the correct place to do it. The extra work for BTS/salsa
issues (if enabled) for me is inevitable.

About the move from salsa.d.o, the question is: salsa.d.o can be used
for general projects born in debian or is most suited for debian
specific projects?

If salsa.d.o is suited, the next step should be enable the issues in
the repository and handle the work of manage duplicated issues between
the repository and the BTS,  while the users understand the correct
place to create issues.

If as Holger suggests, salsa.d.o is very much Debian centric then has
sense look for a new home for diffoscope and maybe other rb
repositories (eg website).
Personally i expect not.

Regards,
JMPC

Bug#910541: diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Juan Picca]

Hi all.
My way of thinking:

If the program is only for debian, bugs.d.o is a right place to report issues.

If the program aims to a broader audience (multiple distros), the
project repository is the right place to report issues. Also, issues
specific to debian can be filled alternatively in bugs.d.o and later
'sent upstream' the fixes to the project repository.

About the need for create an account in salsa.d.o to report issues, is
the same case in gitlab, github, bitbucket, etc.., the user always
needs to create an account the first time (i don't think that it is
complicated).

Regards,
JMPC.
On Mon, Oct 8, 2018 at 7:21 AM Holger Levsen  wrote:
>
> Dear Chris,
>
> On Sun, Oct 07, 2018 at 10:33:49PM +0100, Chris Lamb wrote:
> > (Adjusting severity only because important severity bugs are treated
> > somewhat different in some interfaces, but agree this is more
> > severe than "just another" wishlist entry.)
>
> I agree, was thinking the same when filing the bug...
>
> > > - the project on salsa has issues disabled (but would require a login on
> > >   salsa anyway), still filing bugs in a webbrowser is something many
> > >   people want to do today, so I think maybe we should enable issues?
> >
> > No strong objection to the principle except that we would then have
> > some duplication between the two trackers.
>
> while I do agree that duplication is a problem, I think having bugs not
> filed because "it's complicated" is worse.
>
> > I'm thinking specifically of those times when I'd like to pick up on a
> > previous issue, but then would need to "mentally merge" two lists of
> > bugs, filtering any potential duplicates, etc.
>
> we could make the habbit to always file a debian bug and set it
> forwarded to the github issue if we'd agree to use github issues...
>
> but...
>
> > > - there is still https://github.com/ReproducibleBuilds but thats empty,
> > >   so noone could file issues there.
> > Well, this one is easily "fixed":
> >   https://i.imgur.com/vXbuKYU.png
>
> sigh. for two reasons:
>
> first, I find the style of explaining an issue by the means of a
> screenshot to be, dunno, passive aggressive, or maybe just annoying? its
> definitly not accessable not stored in the bts, and requires everyone
> reading the bts mail to go to a graphical webbrowser (& be online) to
> see what you have done... so for those who have not followed that link,
> Chris deleted https://github.com/ReproducibleBuilds
>
> second, I was basically suggesting to discuss using the github tracker
> and instead of allowing the discussion you killed it within minutes
> after my report. surely we could recreate the github project again, but
> that would mean everybody again needs to apply to become a member etc.
>
> I actually would have been in favor of allowing people to report issues
> on github, just because it has 40mio users, which includes most people
> working on reproducible builds, while a.) salsa has a few thousand and
> hardly anyone not involved in Debian and b.) filing bugs via mail (while
> I like it a lot) is something many people dislike.
>
> But I guess this discussion is academic now. :(
>
>
> --
> cheers,
> Holger
>
> ---
>holger@(debian|reproducible-builds|layer-acht).org
>PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
> ___
> Reproducible-builds mailing list
> reproducible-bui...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds

Bug#910040: Please consider packaging a new version >= 20180922, with support for gnome 3.30

[Víctor Cuadrado Juan]

Package: materia-gtk-theme
Version: 20180519-1
Severity: wishlist
Tags: upstream

Hello,

As one of your users, many thanks for maintaining materia-gtk-theme, it is nice
to use it every day.

Now that Gnome 3.30 is in Testing, it would be nice if materia-gtk-theme was
bumped to a version supporting it (particularly, supporting the pop-up for
volume).

Kind regards,
Víctor Cuadrado


-- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

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

Versions of packages materia-gtk-theme depends on:
ii  gnome-themes-extra3.28-1
ii  gtk2-engines-murrine  0.98.2-2
ii  libgtk-3-common   3.24.0-3
ii  libgtk2.0-common  2.24.32-3

materia-gtk-theme recommends no packages.

materia-gtk-theme suggests no packages.

-- no debconf information

Bug#907744: Cannot assign static IP on a vagrant libvirt debian/stretch64 9.5.0 box

[Víctor Cuadrado Juan]

Package: cloud.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

On a vagrant libvirt image debian/stretch64 9.5.0, it isn't possible
to assign static IPs with the vagrant-libvirt plugin. This was possible
before.

To reproduce, install vagrant-libvirt package, and try with:

```
Vagrant.configure("2") do |config|
  config.vm.box = "debian/stretch64"
  config.vm.provider "libvirt"
  config.vm.network "private_network", ip: "192.168.50.3"
  config.vm.hostname = "test"
end
```

- From comments in 
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/867,
it seems that it is because debian/stretch64 uses systemd-networkd instead of
the usual /etc/network/interfaces.


Cheers,


- -- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAluKWcYACgkQIj8Vylqv
DngjRwgAxlMHIpMB5ItsggGs/kUS7eFMBnrC1dsY9GInri4kZE/s776oIJIoplE6
YDyGCSfTOyqAbp/DvibB+caVfp6v141qG+A+7+innJLLynMtJWtpCehbvfNd+rzb
WyL5dcvGJ/kTu8hV6b9sWPYX2q69aZCdp7xHvbLNi9LciyXXHaHue2DbBGBS+m6I
nmojdkLZCli3724FpFBl6sOPly39gouLNyrbP4SHukTMVjD0ERlhrMwRUAqEyiYG
fPqC6OQwLFW2vrQ1jHYl6HsGLpA62OJSfwhL7U6xb4h8rP/TQ5JnnBX/fWmmTIll
qulRXe+Bq22298hPRICzzd9tCrCCzg==
=fJUf
-END PGP SIGNATURE-

Bug#907649: clang-6.0: Erroneous loop optimisation with -O2, accessing to wrong std::vector element

[Juan Carlos Garcia Hernandez]

Package: clang-6.0
Version: 1:6.0.1-5
Severity: normal

Dear Maintainer,

When compiling with -O2 the code below, resulting loop is wrongly optimized 
leading
to plainly wrong results (not an approximation), it seems that elements in 
std::vector are not accessed in the right order.


#include 
#include 

class Foo {
private:
std::vector _a;
std::vector _d;

public:
Foo(const std::vector &x, const std::vector &y)
: _a(x.size()), _d(x.size()) {

for (unsigned int i = 0; i < x.size() - 1; i++) {
_a[i] = x[i + 1] - x[i];
_d[i] = (y[i + 1] - y[i]) / _a[i];
}
}

const std::vector &a() const noexcept { return _a; }
};

int main() {

// Read input file
std::vector x, y;
while (std::cin) {
double xi, yi;
if (std::cin >> xi >> yi) {
x.push_back(xi);
y.push_back(yi);
}
}

// Create Foo instance
Foo foo(x, y);

// Print computed data
for (auto a : foo.a()) std::cout << a << '\n';

return 0;
}


When executing the following commands (assuming that file bug.cpp contains code 
above)

$> clang++-6.0 -std=c++11 -O2 -o bug  bug.cpp
$> paste <(seq 1 5) <(seq 1 5) | ./bug

the expected result is:
1
1
1
1
0

But one gets:
1
2
2
0
0

Nevertheless, the expected result is obtained with -O1.

Best regards,

Juan


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

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

Versions of packages clang-6.0 depends on:
ii  binutils 2.31.1-4
ii  libc62.27-5
ii  libc6-dev2.27-5
ii  libclang-common-6.0-dev  1:6.0.1-5
ii  libclang1-6.01:6.0.1-5
ii  libgcc-8-dev 8.2.0-4
ii  libgcc1  1:8.2.0-4
ii  libjsoncpp1  1.7.4-3
ii  libllvm6.0   1:6.0.1-5
ii  libobjc-8-dev8.2.0-4
ii  libstdc++-8-dev  8.2.0-4
ii  libstdc++6   8.2.0-4

Versions of packages clang-6.0 recommends:
ii  libomp-dev6.0.1-1
ii  llvm-6.0-dev  1:6.0.1-5
ii  python2.7.15-3

Versions of packages clang-6.0 suggests:
pn  clang-6.0-doc  
pn  gnustep
pn  gnustep-devel  

-- no debconf information

Bug#905303: `/usr/share/bash-completion/completions/su` is owned by both util-linux and bash-completion

[Víctor Cuadrado Juan]

Package: util-linux
Version: 2.32-0.3
Severity: critical

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello util-linux maintainer,

Looping in the bash-completion maintainer too.

On a Stretch system with:
  util-linux_2.32-0.3
  bash-completion_1:2.1-4.3

I get an error performing a full-upgrade to Testing, as both packages
own `/usr/share/bash-completion/completions/su`:

```
Preparing to unpack .../util-linux_2.32-0.3_amd64.deb ...
Unpacking util-linux (2.32-0.3) over (2.29.2-1+deb9u1) ...
Replacing files in old package login (1:4.4-4.1) ...
dpkg: error processing archive 
/var/cache/apt/archives/util-linux_2.32-0.3_amd64.deb (--unpack):
 trying to overwrite '/usr/share/bash-completion/completions/su', which is 
also in package bash-completion 1:2.1-4.3   
 
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
dpkg: considering deconfiguration of util-linux, which would be broken by 
installation of login ...
dpkg: no, util-linux is essential, will not deconfigure
 it in order to enable installation of login
dpkg: error processing archive 
/var/cache/apt/archives/login_1%3a4.5-1.1_amd64.deb (--unpack):
 installing login would break existing software
Errors were encountered while processing:
 /var/cache/apt/archives/util-linux_2.32-0.3_amd64.deb
 /var/cache/apt/archives/login_1%3a4.5-1.1_amd64.deb
```



After a brief look at both source packages, I can see that meanwhile the last
util-linux doesn't ship that file, bash-completion does. Also, util-linux
declares a Break and Conflicts with specific versions of bash-completion, so I
have assumed that the bug report goes indeed against util-linux.

Please don't hesitate to reassign or reduce severity if needed.


Kind regards,
Víctor Cuadrado



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

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

Versions of packages util-linux depends on:
ii  fdisk  2.32-0.3
ii  libaudit1  1:2.8.3-1+b1
ii  libblkid1  2.32-0.3
ii  libc6  2.27-5
ii  libmount1  2.32-0.3
ii  libpam0g   1.1.8-3.7
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.32-0.3
ii  libsystemd0239-7
ii  libtinfo6  6.1+20180714-1
ii  libudev1   239-7
ii  libuuid1   2.32-0.3
ii  login  1:4.5-1.1
ii  zlib1g 1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-3
ii  util-linux-locales  2.32-0.3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAltjVJEACgkQIj8Vylqv
Dnge/Af7BhE6AP0QyxzqiBHCu9atZkAzIIYp5QImB7A0T6Jdtp75xmFiNaEafbbI
HkHHvp7T373VeEFN+WoGCcv1atsPNrnuixa5WnEVBg5lbgzQWVOQ/HWtBDlHxybg
MdgzDhZJGM/LMR+UZiIfJdy2YpOsVq4i40ezTgZwRqTn6JjZyPtQtBEjQwxTF6rQ
KeK8rZqxVnkSVX19l710AAeLWPiDjglYE+msxUAqPn5/AJbdt52+AV1+NyQm0z7y
lPbcVxv7SP5cxHNJU5co5nHaJbNli21ebEVABoh+fC3kqWtbOunlI0wlYHL+NX7b
nzioou4jaj91PP3gk/DfH33bN7fJug==
=NKh+
-END PGP SIGNATURE-

Bug#867886: (no subject)

[Víctor Cuadrado Juan]

reopen 867886
thanks

There it is again, reopening.


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#903845: RFS: lv2bm/1.0-1 [ITP] -- LV2 audio plugin tester with uses in autopktest

[Víctor Cuadrado Juan]

Package: sponsorship-requests
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

  I am looking for a sponsor for my package "lv2bm":

 * Package name: lv2bm
   Version : 1.0-1
   Upstream Author : 2014-2018 Ricardo Crudo 
 2015 Filipe Coelho 
 * URL : https://github.com/moddevices/lv2bm
 * License : GPL-2+, GPL-3+
   Section : devel

  It builds those binary packages:

lv2bm - friendly greeter

Description: Benchmark CLI tool for LV2 plugins
 Features:
  - Allows one to select which LV2 URIs to test
  - Uses minimum, maximum and default control values to run the plugins
  - Has a full test mode which check all combinations for discrete controls
  - Can be used along with valgrind to detect plugin memory issues

In addition to shipping /usr/bin/lv2bm, the package also ships
/usr/bin/lv2-plugin_autopkgtest, a script that uses lv2bm to smoke-test
installed LV2 plugins.

  I intend to maintain this package under the Debian Multimedia Team umbrella,
  and use it for automating lv2 plugin's autopkgtests.

  I have uploaded the source code under the Multimedia Team in salsa:
  https://salsa.debian.org/multimedia-team/lv2bm


Kind regards,
Víctor Cuadrado Juan


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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAltLj/QACgkQIj8Vylqv
DnhGpAgAj+7XCPqf1zsHohneeh18g/48mDGXI2vnzbWaRB+ZtXIA/4+1qJ/1VVlH
9ahEg7E5ci39ONg2HISJKb8ebqFqY+zCDPdLF425Vg0jK1WAzvlGm9U4k0s+kG+b
RI0vHQQzTHfp7JWzdX7Tx0mmDhoaT5mIu8xJsSb7v/Ss+DGrkJ+HcaVnN0K4iVdp
xgVXYKnobMw56ZLe9NjPPcRIxnydQesUGtq475SeMSPsZhA2aQ3RNZxTeqVzA6Pu
c6j9unPypf9XcA1hm2YybrihmHR9SALPlEpyZeJE2pKFFAdOnLflQYKwgL8i+lQi
Jc4NOcErNgK7KDVxRHPLKbgIll66dQ==
=lF0W
-END PGP SIGNATURE-

Bug#867886: (no subject)

[Víctor Cuadrado Juan]

closes 867886
thanks

Just uploaded a new version, with upstream 0.2.6. With the move to pytest and
the redoing of tests, I have not seen this behavior again.

Closing this bug so the package migrates; I will keep looking at
  https://tests.reproducible-builds.org/debian/history/python-neovim.html
for regressions.


Kind regards,


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#903756: (no subject)

[Víctor Cuadrado Juan]

retitle 903756 Please document need for creating mitmproxy CA certificate and 
running update-ca-alternatives on install

After consideration, I would prefer if a README.Debian is shipped, documenting 
the need to perform:

$ mitmproxy --listen-port 9000 # creates certs in ~/.mitmproxy
$ sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem 
/usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
$ sudo update-ca-certificates

Kind regards,


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#903756: Please create mitmproxy CA certificate and run update-ca-alternatives on install

[Víctor Cuadrado Juan]

Package: mitmproxy
Version: 3.0.3-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

If possible it would be nice if with some preinst and postrm the package created
the needed CA certificate in the correct place, and run update-ca-certificates,
analogous to what manually needs to be done by:

$ mitmproxy --listen-port 9000 # creates certs in ~/.mitmproxy
$ sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem 
/usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
$ sudo update-ca-certificates


Kind regards,
Víctor Cuadrado Juan



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

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

Versions of packages mitmproxy depends on:
ii  dpkg  1.19.0.5+b1
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-1
ii  python3   3.6.5-3
ii  python3-blinker   1.4+dfsg1-0.1
ii  python3-brotli1.0.5-1
ii  python3-certifi   2018.4.16-1
ii  python3-click 6.7-5
ii  python3-cryptography  2.2.2-1
ii  python3-h11   0.8.1-1
ii  python3-h23.0.1-4
ii  python3-hyperframe5.1.0-1
ii  python3-kaitaistruct  0.8-1
ii  python3-ldap3 2.4.1-1
ii  python3-openssl   18.0.0-1
ii  python3-passlib   1.7.1-1
ii  python3-pyasn10.4.2-3
ii  python3-pyparsing 2.2.0+dfsg1-2
ii  python3-pyperclip 1.6.0-2
ii  python3-requests  2.18.4-2
ii  python3-ruamel.yaml   0.15.34-1+b1
ii  python3-sortedcontainers  2.0.4-1
ii  python3-tornado   5.0.2-1+b1
ii  python3-urwid 2.0.1-2+b1
ii  python3-wsproto   0.11.0-2

mitmproxy recommends no packages.

mitmproxy suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAltJyHkACgkQIj8Vylqv
DngvSgf+Mj4fgv0qy9/rYQ/mag0tUrQbq6kAY5JAXFcH5anwBefjc9KoXibfez/m
J4W2wATXKj3Cm0kI+/5W134xNMM3RryGsX9xs+dixR8V9Z8uNdPmDh5JB2wNh5ov
08b8EmaYbRKH0NR2eVxoxb95NsGS0n+yHPh26CbQpRQxNzt6PESwacLayuegHBMO
OQERzQbas3xIMFgehqEFT2V19sPNnvkWBVZtKdSBZhAKkIxqN4ym0kQWq51mfRRS
DcXL9FnyJ8HpXsUoULwc1Hbj5JDJpr6Mir5XNRQYcnVutDJx0S1fP7dpWgaNLmhr
OkYblClwopv8uyp/S10ZIsfDm9mymg==
=cd3Q
-END PGP SIGNATURE-

Bug#901568: Please package new upstream version >= 3.4.0 as python-neovim Build-Depends on it

[Víctor Cuadrado Juan]

Source: pytest
Severity: wishlist
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Hello,

Thanks for maintaining python-pytest. Please consider packaging a new upstream
version >= 3.4.0 as the last python-neovim version Build-Depends on it.

I would gladly package it in a fork of the salsa project and provide it here
to pull from in the next following weeks if that helps.

Cheers,
Víctor Cuadrado



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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAlsixMYACgkQIj8Vylqv
Dnj+zgf/QI7/iEMRyxxoX1kJH2rFJNVlUUZBqXvFQvc+IA0IGYtnzr8IVDnmy3lW
OZTcOadMI4rE5dArIWmMYARfKrSWALY3Ls8GC+d/6ANaxvpebS5UdpSCmMxExLPK
CIE0Yc/0WEc1pBIMXz1IoEJJeXvUcTY0HD07b0Z8TsqC+3R77deHZbbbzij0oSzQ
txI58Pl47gCMxuUER7nNj4+uk0MUgqZF79dZqSETbTkhKg/KiwvFhLJzf8NiYhBD
E2qOySsmrLxT5qLdxAyX++G09DEpLD99GExSk0lM3mhZzQd76z/+k3+qhkxWhPwV
R4U28uK5OBZ7V8A+AHtrs28902lIfQ==
=GkIq
-END PGP SIGNATURE-

Bug#899049: ITP: lv2bm -- Benchmark CLI tool for LV2 plugins

[Víctor Cuadrado Juan]

I have packaged it, ready for a review/sponsor. It lives at:
https://salsa.debian.org/multimedia-team/lv2bm


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#899049: ITP: lv2bm -- Benchmark CLI tool for LV2 plugins

[Víctor Cuadrado Juan]

Package: wnpp
Severity: wishlist
Owner: Víctor Cuadrado Juan 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: lv2bm
  Version : 1.0
  Upstream Author : Ricardo Crudo 
Filipe Coelho 
* URL : https://github.com/moddevices/lv2bm
* License : GPL-2+,GPL-3+,ISC
  Programming Lang: C++
  Description : Benchmark CLI tool for LV2 plugins

Features:
- - Allows one to select which LV2 URIs to test
- - Uses minimum, maximum and default control values to run the plugins
- - Has a full test mode which check all combinations for discrete controls
- - The output shows the JACK load percent
- - Allows one to select the input signal to use on the plugins test
- - Allows one to save the output of the plugins to a FLAC file
- - Can be used along with valgrind to detect plugin memory issues

I intend to use this package for implementing and autopkgtest autodep8 test for
all packages that provide `lv2-plugin`.

I plan to maintain it under the Multimedia-Team umbrella, yet I am only a DM at
the moment, so I'm looking for a sponsor.

Cheers,


- --

Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAlr/DqEACgkQIj8Vylqv
DniGsQf+JZ9/gDuWDJiStVlpuMhJGDJ0QftmdxUa6XfLGmZG3uS89Q4eEdnW1kr2
H5TjJwoyY33A+ZYfZsC9LjK1Brp9T1y6kgngxt9U3QwNoePDNYMpU9hrztYnMnRp
bai28mkTEdntnqlQ4zsa46LpEPXMpGxrSZvl+XgnrK4YdO3lOw9+0Hx9+W+9cj0A
OM94AUokHR2qwyxo3S7JUqELWa9abORrFeMGQ3Ygq2N7U/E1JMUHHknLpMk+x5X+
0gt9d7W6dPlLYRCopvujyYiyajk/hQzcwEBTkYhP/+NT8snK463V5pySw8KtgvV8
ICWOkto0allikapRLf2Oxhnsni8m2Q==
=QZH7
-END PGP SIGNATURE-

Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree

[Juan Picca]

Package: wnpp
Severity: wishlist
Owner: Juan Picca 

* Package name: golang-github-ostreedev-ostree-go
  Version : 0.0~git20171027.cb6250d-1
  Upstream Author : OSTree Project
* URL : https://github.com/ostreedev/ostree-go
* License : ISC
  Programming Lang: Go
  Description : Golang bindings for httt://github.com/ostreedev/ostree

 OSTree-Go Go bindings for OSTree. Find out more about OSTree here
 (https://github.com/ostreedev/ostree)

This package is a dependency for skopeo
(https://github.com/projectatomic/skopeo).

Bug#898426: partx exit status 0 on some errors

[Juan Céspedes]

Package: util-linux
Version: 2.32-0.1

partx has a exit status of 0 when it fails to read the partition table:

root@loopy:~# partx -s - /dev/sda1
partx: /dev/sda1: failed to read partition table
root@loopy:~# echo $?
0

It behaves properly, however, when the disk cannot be read:

root@loopy:~# partx -s - /dev/none
partx: cannot open /dev/none: No such file or directory
root@loopy:~# echo $?
1

Thanks,

-- 
Juan Cespedes

Bug#898326: qttranslations5-l10n: Bad spanish translation files

[Juan José Gómez]

Package: qttranslations5-l10n
Version: 5.7.1~20161021-1
Severity: normal

The Spanish translation files dont work.

If you try to use in a code like this:

locale = QtCore.QLocale.system().name()
qtTranslator = QtCore.QTranslator()
path = QtCore.QLibraryInfo.location(QtCore.QLibraryInfo.TranslationsPath)
if qtTranslator.load("qt_" + locale, path):
app.installTranslator(qtTranslator)

The spanish translation of qt widgets don't show, trying with another locales
work, like japanese or german.

The files in packages reveal different structure for spanish translation:

$ ls /usr/share/qt5/translations/ | grep _de.qm
assistant_de.qm
designer_de.qm
linguist_de.qm
qscintilla_de.qm
qtbase_de.qm
qtconnectivity_de.qm
qtdeclarative_de.qm
qt_de.qm
qt_help_de.qm
qtlocation_de.qm
qtmultimedia_de.qm
qtquick1_de.qm
qtquickcontrols_de.qm
qtscript_de.qm
qtserialport_de.qm
qtwebengine_de.qm
qtwebsockets_de.qm
qtxmlpatterns_de.qm

ls /usr/share/qt5/translations/ | grep _es.qm
qt_es.qm

And the contents are like outdated in this file.

Trying to use the files in arch package:
https://www.archlinux.org/packages/extra/any/qt5-translations/

root@hp:/home/jjgomera/Descargas/qt5-translations-5.10.1-1-any.pkg/usr/share/qt/translations#
mv /usr/share/qt5/translations/qt_es.qm
/usr/share/qt5/translations/qt_es_back.qm
root@hp:/home/jjgomera/Descargas/qt5-translations-5.10.1-1-any.pkg/usr/share/qt/translations#
cp *_es.qm /usr/share/qt5/translations/

This files do the translation and the code above show now qt messages in
correct spanish translation.



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

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

-- no debconf information

Bug#894787: vte: [PATCH] make the build reproducible

[Juan Picca]

Source: vte
Version: 1:0.28.2-5
Severity: whishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that vte generates output that is not reproducible:

│ │ │ ├── ./usr/include/vte-0.0/vte/vtetypebuiltins.h
│ │ │ │ @@ -8,29 +8,29 @@
│ │ │ │  #ifndef VTE_TYPE_BUILTINS_H
│ │ │ │  #define VTE_TYPE_BUILTINS_H
│ │ │ │
│ │ │ │  #include 
│ │ │ │
│ │ │ │  G_BEGIN_DECLS
│ │ │ │
│ │ │ │ -/* enumerations from "/build/1st/vte-0.28.2/./src/vte.h" */
│ │ │ │ +/* enumerations from "/build/vte-0.28.2/2nd/./src/vte.h" */

Patch attached.

 [0] https://reproducible-builds.org/
Description: Reproducible template output
 Allow the output of `glib-mkenums` be reproducible using `@basename` instead of
 `@filename@`.
Author: Juan Picca 
Last-Update: 2018-04-02
---
--- a/src/vtetypebuiltins.c.template
+++ b/src/vtetypebuiltins.c.template
@@ -4,7 +4,7 @@
 /*** END file-header ***/
 
 /*** BEGIN file-production ***/
-/* enumerations from "@filename@" */
+/* enumerations from "@basename@" */
 /*** END file-production ***/
 
 /*** BEGIN value-header ***/
--- a/src/vtetypebuiltins.h.template
+++ b/src/vtetypebuiltins.h.template
@@ -13,7 +13,7 @@ G_BEGIN_DECLS
 
 /*** BEGIN file-production ***/
 
-/* enumerations from "@filename@" */
+/* enumerations from "@basename@" */
 /*** END file-production ***/
 
 /*** BEGIN value-header ***/

Bug#888573: gnome-desktop: insertion & removal of USB thumb drive causes user to be logged out

[Juan Rafael Fernández García]

Fixed: disable gnome-shell-extension-places-menu

See Extension cause Gnome-shell to crash
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/49

By the way, gnome-desktop is no longer a package in Testing. It should
be a gnome-shell-extensions bug.

Bug#888066: grub2: grub.cfg too big, system unable to boot

[Juan]

Package: os-prober
Version: 1.76~deb9u1
Severity: normal
File: grub2

Dear Maintainer,

I have had a hard day tryng to make my systems boot again after what apparently 
was a too big grub.cfg file, of like 7Mb, with many sub menu entrys of 
other grub.cfg files of other partitions.
I have  4 partitions with testing and stable branchs, i386 and amd64.
I was testing each Os and reinstalled grub from almost all of them, in a period 
of months, to make the default system I was testing too boot by default.
After the last automatic update-grub from a kernel update I think, the grub 
boot menu just not appeared anymore.
So i had to use a live dvd to enter the system and delete the big file and 
replace it with a small one, because re running update'grub again give me 
another big file.

.
Also i had to remove all other grub.cfg files, to uodate the grub normally 
again.
an additional difficulty was the fact that the DVD live distro  was old and did 
not let me mount the partitions.
Hope this helps.



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages os-prober depends on:
ii  grub-common  2.02~beta3-5
ii  libc62.24-11+deb9u1

os-prober recommends no packages.

os-prober suggests no packages.

-- no debconf information

Bug#886474: More errors

[Juan Mendez]

After adding libelf-dev and compiling the module for 4.14.0-3-amd64

dkms is failing when compiling for broadcom-sta-dkms with:

# cat /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log

DKMS make.log for broadcom-sta-6.30.223.271 for kernel 4.14.0-3-amd64
(x86_64)
Fri Jan 12 10:49:26 CET 2018
/bin/sh: 1: [: Illegal number:
/bin/sh: 1: [: Illegal number:
Wireless Extension is the only possible API for this kernel version
Using Wireless Extension API
KBUILD_NOPEDANTIC=1 make -C /lib/modules/4.14.0-3-amd64/build M=`pwd`
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make
rule.
make[1]: Entering directory '/usr/src/linux-headers-4.14.0-3-amd64'
CFG80211 API is prefered for this kernel version
Using CFG80211 API
Kernel architecture is X86_64
  AR  /var/lib/dkms/broadcom-sta/6.30.223.271/build/built-in.o
make[4]: *** No rule to make target
'/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.o',
needed by '/var/lib/dkms/broadcom-sta/
6.30.223.271/build/wl.o'.  Stop.
/usr/src/linux-headers-4.14.0-3-common/Makefile:1525: recipe for target
'_module_/var/lib/dkms/broadcom-sta/6.30.223.271/build' failed
make[3]: *** [_module_/var/lib/dkms/broadcom-sta/6.30.223.271/build] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[2]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.14.0-3-amd64'
Makefile:177: recipe for target 'all' failed
make: *** [all] Error 2

Bug#882066: ansible-lint fails with ansible 2.4

[Víctor Cuadrado Juan]

severity 882066 grave
thanks


Bumping severity to RC bug; the package is broken and unusable with the
ansible version both in Testing and Unstable. It could work against Stretch's
ansible package, but ansible-lint isn't available in backports.

Kind regards.

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#881633: Creation of vim-python3 virtual package

[Víctor Cuadrado Juan]

On 16/11/17 00:20, James McCoy wrote:
> On Wed, Nov 15, 2017 at 10:15:31AM -0700, Sean Whitton wrote:
>> On Wed, Nov 15 2017, James McCoy wrote:
>>
>>> One thing I'd like to note is that none of the vim-$lang virtual
>>> packages are currently listed in Policy's set of virtual packages.
>>> That was an oversight on the Vim maintainers side when the package
>>> names were introduced, but maybe now would be a good time to correct
>>> that.
>>
>> The point of listing virtual packages in Policy is to deal with
>> disparate people maintaining packages that Provide the virtual package.
>> If the people using the virtual packages are part of a tightly-knit
>> packaging team, they can maintain the virtual packages themselves,
>> without listing them in Policy.
> 
> Ok.  I had a recollection of that.
> 
>> In light of this, could you confirm that this needs to go into Policy?
>> I am not familiar with you Vim guys, what with being the co-maintainer
>> of a dh_* tool for Emacs addons..
> 
> I don't think so.  Victor?
> 
> Cheers,
>

I'm ok too with it being out of policy. We can close this vim-python3 bug
(#881633) and the vim-python one (#881642), then.

Cheers,

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge

[Víctor Cuadrado Juan]

On 15/11/17 17:00, Guido Günther wrote:
> Hi,
> On Wed, Nov 15, 2017 at 04:21:58PM +0100, Víctor Cuadrado Juan wrote:
>>
>>
>> On 15/11/17 15:53, Guido Günther wrote:
>>> Hi,
>>> On Wed, Nov 15, 2017 at 03:02:33PM +0100, Víctor Cuadrado Juan wrote:
>>>>
>>>>
>>>> On 14/11/17 22:47, Guido Günther wrote:
>>>>> Hi,
>>>>>
>>>>> This wired and I wouldn't expect uncommitted changes but since I don't
>>>>> know about your setup and what you're doing (the upstream repo
>>>>> e.g. already has the version you're trying to import) you'd have to
>>>>> provide better instructions to reproduce and tell me what you actually
>>>>> think is wrong.
>>>> With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up
>>>> until 0.35.6, I can do
>>>>
>>>>   gbp --import-orig --uscan --merge-mode=replace
>>>>
>>>> and it will correctly import the new 0.36.0 upstream version, merge it to 
>>>> master
>>>> and preserve the already existing contents at debian/*.
>>>>
>>>> With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the same
>>>> will overwrite the contents at debian/* with upstream sources, contrary to
>>>> what --merge-mode=replace should do.
>>>
>>> That would be a grave bug. Can you still reproduce it? If so please send
>>> me the refs of the branches (master and upstream) before you run uscn so
>>> I can try to reproduce.
>>>
>>>> Sadly I wanted to keep working on guitarix and submit a new upload, so I
>>>> already committed 0.36.0 to the guitarix repo at
>>>> https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ .
>>>>
>>>>>  Can you reproduce this with other packages?
>>>>
>>>> I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo and
>>>> lv2proc packages, and it worked fine.
>>>>
>>>> So if you see no problem on gbp output as said, feel free to close the bug.
>>>> Maybe it was a fluke caused by several people working in guitarix's
>>>> repo.
>>>
>>> See above. Can you try to pass me the commits (or even better prepare a
>>> repo in the exact state) that I need to run gbp import-orig against? I
>>> tried several variants here but it always worked (as it did with the
>>> test run on the rest of the archive on my last sweep). Even the debian/
>>> tree from your logs (c4a8a211261fc53b556732b1b724f938060d0135) is the
>>> same one that my invocation uses as is the parent commit on upstream.
>>>
>>> If you could provide more information on how to reproduce this that'd be
>>> great. If not let's close this for the moment. Should you hit that again
>>> please tar the _whole_ git repo and send me link so I can infer things
>>> from the reflog.
>>>
>>> Cheers,
>>>  -- Guido
>>>
>>
>> I have taken https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/
>> and do `git reset --hard`, deleted tags and removed the debian remote to have
>> it look as it was before importing upstream's 0.36.0, and I can
>> reproduce
> 
> That's what I did yesterday.
> 
>> the bug in it:
>>
>> git clone https://github.com/viccuad/example-bug-gbp && cd 
>> example-bug-gbp
>> git fetch origin upstream:upstream pristine-tar:pristine-tar
>> gbp import-orig --pristine-tar --uscan --merge-mode=replace # or auto, 
>> is the same
>> # notice that debian/* has changes to be committed
>>
>> I will delete that repo once this bug is closed/fixed.
> 
> Thanks. But then again, same output as in my previous
> attempts. Everything looks fine. Is it possible that you're somehow
> picking old gbp code from a pip install or similar? What's in your
> gbp.conf? Can you make sure with "strace -e file -s2048 " that
> the right gbp and git are being used?
> 
> Cheers,
>  -- Guido
> 

Sadly I keep reproducing it in a fresh Sid VM, with no gbp.conf
(see attached file with strace output).


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.
vagrant@desktop:~$ git clone https://github.com/viccuad/example-bug-gbp && cd 
example-bug-gbp
Cloning into 'example-bug-gbp'...
remote: Counting ob

Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge

[Víctor Cuadrado Juan]

On 15/11/17 15:53, Guido Günther wrote:
> Hi,
> On Wed, Nov 15, 2017 at 03:02:33PM +0100, Víctor Cuadrado Juan wrote:
>>
>>
>> On 14/11/17 22:47, Guido Günther wrote:
>>> Hi,
>>>
>>> This wired and I wouldn't expect uncommitted changes but since I don't
>>> know about your setup and what you're doing (the upstream repo
>>> e.g. already has the version you're trying to import) you'd have to
>>> provide better instructions to reproduce and tell me what you actually
>>> think is wrong.
>> With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up
>> until 0.35.6, I can do
>>
>>   gbp --import-orig --uscan --merge-mode=replace
>>
>> and it will correctly import the new 0.36.0 upstream version, merge it to 
>> master
>> and preserve the already existing contents at debian/*.
>>
>> With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the same
>> will overwrite the contents at debian/* with upstream sources, contrary to
>> what --merge-mode=replace should do.
> 
> That would be a grave bug. Can you still reproduce it? If so please send
> me the refs of the branches (master and upstream) before you run uscn so
> I can try to reproduce.
> 
>> Sadly I wanted to keep working on guitarix and submit a new upload, so I
>> already committed 0.36.0 to the guitarix repo at
>> https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ .
>>
>>>  Can you reproduce this with other packages?
>>
>> I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo and
>> lv2proc packages, and it worked fine.
>>
>> So if you see no problem on gbp output as said, feel free to close the bug.
>> Maybe it was a fluke caused by several people working in guitarix's
>> repo.
> 
> See above. Can you try to pass me the commits (or even better prepare a
> repo in the exact state) that I need to run gbp import-orig against? I
> tried several variants here but it always worked (as it did with the
> test run on the rest of the archive on my last sweep). Even the debian/
> tree from your logs (c4a8a211261fc53b556732b1b724f938060d0135) is the
> same one that my invocation uses as is the parent commit on upstream.
> 
> If you could provide more information on how to reproduce this that'd be
> great. If not let's close this for the moment. Should you hit that again
> please tar the _whole_ git repo and send me link so I can infer things
> from the reflog.
> 
> Cheers,
>  -- Guido
> 

I have taken https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/
and do `git reset --hard`, deleted tags and removed the debian remote to have
it look as it was before importing upstream's 0.36.0, and I can reproduce
the bug in it:

git clone https://github.com/viccuad/example-bug-gbp && cd example-bug-gbp
git fetch origin upstream:upstream pristine-tar:pristine-tar
gbp import-orig --pristine-tar --uscan --merge-mode=replace # or auto, is 
the same
# notice that debian/* has changes to be committed

I will delete that repo once this bug is closed/fixed.

Cheers,

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge

[Víctor Cuadrado Juan]

On 14/11/17 22:47, Guido Günther wrote:
> Hi,
> 
> This wired and I wouldn't expect uncommitted changes but since I don't
> know about your setup and what you're doing (the upstream repo
> e.g. already has the version you're trying to import) you'd have to
> provide better instructions to reproduce and tell me what you actually
> think is wrong.
With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up
until 0.35.6, I can do

  gbp --import-orig --uscan --merge-mode=replace

and it will correctly import the new 0.36.0 upstream version, merge it to master
and preserve the already existing contents at debian/*.

With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the same
will overwrite the contents at debian/* with upstream sources, contrary to
what --merge-mode=replace should do.

Sadly I wanted to keep working on guitarix and submit a new upload, so I
already committed 0.36.0 to the guitarix repo at
https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ .

>  Can you reproduce this with other packages?

I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo and
lv2proc packages, and it worked fine.

So if you see no problem on gbp output as said, feel free to close the bug.
Maybe it was a fluke caused by several people working in guitarix's repo.




-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge

[Víctor Cuadrado Juan]

Package: git-buildpackage
Version: 0.9.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

While importing upstream's version 0.36.0 of package guitarix, I've found that
`gbp --import-orig --merge-mode=replace` and `--merge-mode=auto` behaves as
`--merge-mode=merge`. To reproduce do:

I've reproduced this bug against gbp 0.9.1 and 0.9.2. Please see attached
output on clean unstable machine.

Kind regards,


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

Kernel: Linux 4.13.0-1-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-buildpackage depends on:
ii  devscripts 2.17.11
ii  git1:2.15.0-1
ii  man-db 2.7.6.1-2
ii  python33.6.3-2
ii  python3-dateutil   2.6.1-1
ii  python3-pkg-resources  36.6.0-1

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.85
ii  pbuilder  0.229
ii  pristine-tar  1.42
ii  python3-requests  2.18.1-1
ii  sbuild0.73.0-4

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.8.21p2-2
ii  unzip6.0-21

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAloLPVYACgkQIj8Vylqv
DnjIbwgAwWxoIQTTb4mvkOtk7c2boYolotWByaUxa2wmb1GVUgJIVVidjq3lWIah
7CQRULeD58T5nMSkxZ4Dbx4G1P39OQZgIuTlwejRn55NrAntxSJKsIH8nJVhUc96
yrwtCDlTa0jocMuSJDdhyEvGJOEXYqwvru6gRvBGUZW60vnQqPaXMa0vM48RWOaV
2fZ8rOeH2t8W0sWdsWDOMbWCo0Os4Wj/pbWYf/bJxhalupvS4ZMjdSCKl0o+l9q5
TXJICcv2zkGS7hCECddMtdSzhpTJYH8A4kiV7qbPTBUOTDxm0ya54A3QtWDi6Lpe
caUPdPRhPU7HTtHlcomWGLSEeL0nVw==
=ABdf
-END PGP SIGNATURE-
root@desktop:~# git clone git://anonscm.debian.org/pkg-multimedia/guitarix.git 
guitarix && cd guitarix
Cloning into 'guitarix'...
remote: Counting objects: 11042, done.
remote: Compressing objects: 100% (4054/4054), done.
remote: Total 11042 (delta 7947), reused 9746 (delta 6821)
Receiving objects: 100% (11042/11042), 88.77 MiB | 4.60 MiB/s, done.
Resolving deltas: 100% (7947/7947), done.
root@desktop:~/guitarix# git fetch origin upstream:upstream 
pristine-tar:pristine-tar
>From git://anonscm.debian.org/pkg-multimedia/guitarix
 * [new branch]  upstream -> upstream
 * [new branch]  pristine-tar -> pristine-tar
root@desktop:~/guitarix# gbp import-orig --pristine-tar --uscan --verbose 
--merge-mode=replace
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
gbp:debug: ['git', 'show-ref', 'refs/heads/upstream']
gbp:debug: ['git', 'status', '--porcelain']
gbp:info: Launching uscan...
uscan: Newest version of guitarix on remote site is 0.36.0, local version is 
0.35.6
uscan:=> Newer package available from
  http://qa.debian.org/watch/sf.php/guitarix/guitarix2-0.36.0.tar.xz
gbp:info: Using uscan downloaded tarball ../guitarix_0.36.0.orig.tar.xz
What is the upstream version? [0.36.0]
gbp:debug: ['git', 'tag', '-l', 'upstream/0.36.0']
gbp:debug: tar ['-C', '../tmp2_xslh4t', '-a', '-xf', 
'../guitarix_0.36.0.orig.tar.xz'] []
gbp:debug: Unpacked '../guitarix_0.36.0.orig.tar.xz' to 
'../tmp2_xslh4t/guitarix-0.36.0'
gbp:info: Importing '../guitarix_0.36.0.orig.tar.xz' to branch 'upstream'...
gbp:info: Source package is guitarix
gbp:info: Upstream version is 0.36.0
gbp:debug: ['git', 'show-ref', 'refs/heads/upstream']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream']
gbp:debug: ['git', 'commit-tree', '3e9fc90df9d883cc4ee657c9466ea835336eeb94', 
'-p', 'b71e4eb38c6b8d9a35d1e88d6ff72a095a7cb7b1']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 0.36.0', 
'refs/heads/upstream', '87a3e934062d1ad81c6d9c557afe8b94ffc6a17d', 
'b71e4eb38c6b8d9a35d1e88d6ff72a095a7cb7b1']
gbp:debug: ['git', 'show-ref', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
gbp:debug: ['git', 'ls-tree', '-z', 'upstream', '--']
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: pristine-tar [] ['commit', '../guitarix_0.36.0.orig.tar.xz', 
'3e9fc90df9d883cc4ee657c9466ea835336eeb94']
gbp:debug: ['git', 'tag', '-m', 'Upstream version 0.36.0', 'upstream/0.36.0', 
'87a3e934062d1ad81c6d9c557afe8b94ffc6a17d']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'master']
gbp:info: Replacing upstream source on 'master'
gbp:debug: ['git', 'ls-tree', '-z', 'up

Bug#881672: Please add Suggests: cockpit-machine

[Víctor Cuadrado Juan]

Package: cockpit
Version: 154-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

Please add "Suggests: cockpit-machine" to cockpit binary
package.

Kind regards.



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

Kernel: Linux 4.13.0-1-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cockpit depends on:
ii  cockpit-bridge 154-1
ii  cockpit-dashboard  154-1
ii  cockpit-system 154-1
ii  cockpit-ws 154-1

Versions of packages cockpit recommends:
ii  cockpit-networkmanager  154-1
ii  cockpit-storaged154-1

Versions of packages cockpit suggests:
pn  cockpit-doc 
ii  cockpit-docker  154-1
ii  cockpit-packagekit  154-1
pn  cockpit-pcp 
ii  xdg-utils   1.1.2-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAloKKsMACgkQIj8Vylqv
DnhVsAf+M5nfGXLWb79xqsmDWM92ysmMstu4oTXqIlVKEqnvjWnD8+TotgsP1Xiq
2wj69+17n5iAF0yQVSpteKMaVd6fDOb1yFaseCsrKsSysCLCgZhN12NdaXsgSRHw
JBQPbEvI9QshzL3vwmwD85UdFDulq4K466YpBp8dvExigPrhprqFfzeekWTPUwOA
TsTEfoCxU4nZcb0peg8SV4iIUMSBkTMW0J/zGF3Sj9L7mtdFsZdaj1ZfKpBm8Jqo
9fRB4Nx3ZMYXXFVNNFvI+dj/sXVhyjcA0UOLieMMZyLO8j5Je88qR6UGiemrjpIP
dttEUfV+H3sBfhcOQmsvVEQftQ6vKw==
=aem8
-END PGP SIGNATURE-

Bug#881494: chromium crash on startup

[Juan Mendez]

I could solve it by:

mv ~/.config/chromium/ ~/.config/chromium_old/

so a new set of config files are created, and then recovering the Bookmarks
with

Then cp ~/.config/chromium_old/Default/Bookmarks ~/.config/chromium/Default/

Bug#881633: Creation of vim-python3 virtual package

[Víctor Cuadrado Juan]

On Mon, 13 Nov 2017 19:34:44 +0100 Víctor Cuadrado Juan  wrot> 
It will allow vim python3 plugins to require on it.

Expanding on the rationale:

vim works with python2 and python3 plugins simultaneously. Those vim python
plugins depend on the vim-python virtual package.

In the case of neovim, support for python2 and python3 plugins is achieved
by using python-neovim and python3-neovim respectively.

As the maintainer of python-neovim, if I would do only `Provides: vim-python`
then some vim python plugins would be broken.
Eg: vim-python-jedi, a python3 package, depends on vim-python. vim-python-jedi
would not work with python-neovim that `Provides: vim-python`, buy would need
python3-neovim that `Provides: vim-python3`

This means that packages that currently depend on vim-python need to be checked
to depend on the correct vim-python and/or vim-python3.


Kind regards,

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#872942: Your mail

[Víctor Cuadrado Juan]

block 872942 by 881633 881642
thanks


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#881642: Add already existing `vim-python` virtual package to list of virtual packages

[Víctor Cuadrado Juan]

Package: debian-policy
Version: 4.1.1.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

while opening the debian-policy wishlist bug [1] about creating a vim-python3
package, I've noticed that the existing `vim-python` package is not in the list
of virtual packages maintained at [2]. This was triggered by the desire to
solve
python-neovim bug #872942 [3].

This wishlist bug is merely to update the list at [1], as several packages
already provide the `vim-python` virtual package.

I propose the following description:

Miscellaneous
- -
 vim-python  a compatible vim editor that can run python 2.x addons


Kind regards,


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881633
[2]: https://www.debian.org/doc/packaging-manuals/virtual-package-names-
list.txt
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872942



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

Kernel: Linux 4.13.0-1-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.6.5-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAloJ+zsACgkQIj8Vylqv
DngdTwf+PVcrh4uDr1BWGrf+UXz5dOUuK7o+Id/WFKEo02ZNGKx+l5G4+kFVa28h
x+jSFWhR6JETmV/YqgoxVafsA8vIbRLSQjUE7Jrt8SvriTT/1J9F9LpKUXm0rgdA
/VG5bMTz9SMAKqaNfmoiHOb1KSHfzT1PDCAKX7ZpvhyyHlBlUXYdRzIwddfFiuAJ
f4+MvvprV1ex9/5h95LEM10mYzJHx2WrXl2hO/FSVCdWWKTERrSKA+6SD05VD8I9
ocWliYPWSCYmoXZppeQ5hHvJo0m5NYGKCEWUkoRYSYRWvtG12HD+AQodH10kbEsw
o1+u69AVJtICTC19xy3hk8L/iNWoGw==
=csPI
-END PGP SIGNATURE-

Bug#881633: Creation of vim-python3 virtual package

[Víctor Cuadrado Juan]

Package: debian-policy
Version: 4.1.1.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Following steps in [1], here is the wishlist bug for creating
a `vim-python3` virtual package, homologous to the already present
`vim-python` virtual package.

It will allow vim python3 plugins to require on it.
This solves python-neovim bug #872942 [2].

Cheers.

[1]: https://www.debian.org/doc/packaging-manuals/virtual-package-names-
list.txt
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872942



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

Kernel: Linux 4.13.0-1-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.6.5-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAloJ5cAACgkQIj8Vylqv
DnjQRQgAxApd1WoYBqMX8c0EUzCcBpalo52JXY3ozfU/ERLrRyh7BmHAw5+ycmqy
n0aCszJtpKBImsYSvzvmMTPuqXMsoP7VXrsaxHzNFnjpJhT1No4yI8+WPUCf9hRf
GyFgcrwjt/9/87QfNDaSammBAVhkffZnMIA/nOkR/oGvXjc86RHdmQr2iMdm5Sq+
cIpzRQ5phf6zuCyTAvnDypJ4VLCBUgR3NFhWeZK9/uOAls+R3E9E6eAvERIjLd1x
q5qg9FwdhV5X7cBwOvFZLVHrPxryDY3O+efyaFWJVpSIiHfKcwAXbXqJkckKXQoE
sPBJKOZnDRBqWH75KJ3jqPMoYbHIlw==
=MM9c
-END PGP SIGNATURE-

Bug#872942: (no subject)

[Víctor Cuadrado Juan]

Hello, maintainer of python-neovim here. I agree that it makes sense to have
python-neovim "Provides: vim-python" and "Provides: vim-python3", and
"Recommends: neovim" (this last one should have been there since a while).

I will commit that shortly.




-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#872856: equivs: generates invalid install file when filename contains { or }

[Juan Grigera]

Package: equivs
Version: 2.1.0.1
Severity: normal

Dear Maintainer,

I have found that equivs-build generates a debian/install file that fails to 
escape
characters such as { or } in filenames (e.g. 
{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi).

A really simple patch could be: (but not 100% sure of side effects, I havent 
written
perl in a decade)

--- a/usr/bin/equivs-build
+++ b/usr/bin/equivs-build
@@ -92,6 +92,8 @@ open INSTALL, '>', "$builddir/debian/install" or
   die "Cannot open $builddir/debian/install for writing: $!\n";
 foreach my $target (keys %install_files, keys %create_files, keys 
%create_links) {
   $target =~ s/ +//g;
+  # escape filenames with {, }
+  $target =~ s/({|})/\\$1/g;
   my $dest;
   my $cnt = 0;
   if ($target =~ m/^(preinst|postinst|prerm|postrm)$/) {


Not sure if there are other special chars to be escaped, but I was just hit by 
this
bug.

Many thanks,
Juan


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

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

Versions of packages equivs depends on:
ii  debhelper  10.7.2
ii  dpkg-dev   1.18.24
ii  fakeroot   1.21-3.1
ii  make   4.1-9.1
ii  perl   5.26.0-5

equivs recommends no packages.

equivs suggests no packages.

-- no debconf information

Bug#872566: RM: python-neovim-gui/experimental -- ROM; Upstream dead

[Víctor Cuadrado Juan]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

This package never left experimental, upstream has decided
to stop maintenace of it since 2 months (see [1]),
and there are other neovim GUI implementations
already packaged in Debian (eg: neovim-qt).

So let's remove it.

Many thanks.


[1]: https://github.com/neovim/python-gui/blob/master/README.md




-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAlmXEUUACgkQIj8Vylqv
DnhivwgAgnoh3xvVImlD9LsPMA7lD2OvMZnBpDhx2CfDSq7vMGE7d6+kZhmKQ3RD
aDCi+Hob6SLoTuXco8iCsVQAKknK8hNzjVSHscd3TGDE96SvoOkCFBvxGoHYrtbm
pQtsBSfkDAJAetVw/Y7eB39/uq6HN49TWK82Sku/cd2GMyE+R4GAq/XloM7q5EGb
xjF3275Tfd0A5HS+psudiMm9gZfZe6m89HMyDhm6Na1n0Z6xF7XkUqM7Sns7Mqfm
3YBwZDMfjGjIoL4kVgH5tyRuTJ9929dSa6I4R8ygHc9B1KjHLNbBnp7lZVRSj6q6
JPvZUT9ggKlQgYyd4az6ktwanKIhRA==
=OFDP
-END PGP SIGNATURE-

Bug#867886: (no subject)

[Víctor Cuadrado Juan]

I suspect that the hanging test is `test_client_rpc.test_async_call`,
but I haven't seen it hang locally yet.

I will upload a new version with --vv for the tests for debugging this
better (once my un-expired gpg key is in the keyring or there's a sponsor
upload).


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#871942: firefox-esr: Firefox will not render the YouTube page correctly nor play YT videos rel 8/12/17.

[Juan Rivero]

Package: firefox-esr
Version: 52.3.0esr-1~deb8u1
Severity: serious
Justification: Unknown

Dear Maintainer,

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

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

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



-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Application Update Service Helper
Location: ${PROFILE_EXTENSIONS}/aushel...@mozilla.org.xpi
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled

Name: Garmin Communicator
Location: ${PROFILE_EXTENSIONS}/{195A3098-0BD5-4e90-AE22-BA1C540AFD1E}
Status: user-disabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

Name: YouTube ALL HTML5
Location: ${PROFILE_EXTENSIONS}/jid1-qj0w91o64n7...@jetpack.xpi
Status: enabled

-- Plugins information
Name: Shockwave Flash
Location: /home/juanr/.mozilla/plugins/libflashplayer.so
Status: enabled

Name: Skype Buttons for Kopete
Location: /usr/lib/mozilla/plugins/skypebuttons.so
Package: kopete
Status: enabled


-- Addons package information
ii  firefox-esr52.3.0esr-1~ i386 Mozilla Firefox web browser - Ext
ii  kopete 4:4.14.1-2   i386 instant messaging and chat applic

-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox-esr depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3+deb8u1
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u10
ii  libcairo-gobject2 1.14.0-2.1+deb8u2
ii  libcairo2 1.14.0-2.1+deb8u2
ii  libdbus-1-3   1.8.22-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2+deb8u1
ii  libffi6   3.1-2+deb8u1
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u2
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk-3-03.14.5-1+deb8u1
ii  libgtk2.0-0   2.24.25-3+deb8u2
ii  libhunspell-1.3-0 1.3.3-3
ii  libjsoncpp0   0.6.0~rc2-3.1
ii  libpango-1.0-01.36.8-3
ii  libsqlite3-0  3.8.7.1-1+deb8u2
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libx11-xcb1   2:1.6.2-3
ii  libxcb-shm0   1.10-3+b1
ii  libxcb1   1.10-3+b1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.9-9
ii  zlib1g1:1.2.8.dfsg-2+b1

firefox-esr recommends no packages.

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
pn  mozplugger 

-- no debconf information

Bug#870500: network-manager: Error onnecting to Wifi (wpa) through network-manager after fresh installation.

[juan]

Package: network-manager
Version: 1.6.2-3
Severity: important

Dear Maintainer,

After fresh installation of Debian 9.1.0 (both Gnome and KDE, 
presumably others), it's impossible to connect to a Wifi network (WPA)
with the network manager, which I think it's a important bug given
its function. I found a work a round in a bug from several months ago,
which is why I opened a new bug report (I think that stable should be 
updated?). The workaround was changing NetworkManager.conf
as is sent below.

It's my first bug report so please forgive me I haven't done something
right. 

Also, I'm using aht9k_htc for TP-Link WN422G, not that I think it matters.


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.18-1
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libbluetooth3  5.43-2
ii  libc6  2.24-11+deb9u1
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u2
ii  libgudev-1.0-0 230-3
ii  libjansson42.9-1
ii  libmm-glib01.6.4-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.19-1+b1
ii  libnl-3-2003.2.27-2
ii  libnm0 1.6.2-3
ii  libpam-systemd 232-25+deb9u1
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libreadline7   7.0-3
ii  libselinux12.6-3+b1
ii  libsoup2.4-1   2.56.0-2
ii  libsystemd0232-25+deb9u1
ii  libteamdctl0   1.26-1+b1
ii  libuuid1   2.29.2-1
ii  lsb-base   9.20161125
ii  policykit-10.105-18
ii  udev   232-25+deb9u1
ii  wpasupplicant  2:2.4-1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base 2.76-5+b1
ii  iptables 1.6.0+snapshot20161117-6
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3
ii  modemmanager 1.6.4-1
ii  ppp  2.4.7-1+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no


-- no debconf information

Bug#863101: Uscan uses all available memory of the system when run against guitarix

[Víctor Cuadrado Juan]

On 22/05/17 01:59, Adrian Bunk wrote:
> On Sun, May 21, 2017 at 09:06:21PM +0200, Víctor Cuadrado Juan wrote:
>> ...
>> --- ~/.devscripts ---
>> BTS_INTERACTIVE= yes
>> ...
> 
> Remove the space, this is the source of your problems.
> 
> Looking at the manpage, it is actually documented behaviour.

Well, that was it. Thanks and sorry for the noise.

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#863101: Uscan uses all available memory of the system when run against guitarix

[Víctor Cuadrado Juan]

On 21/05/17 22:05, Adam D. Barratt wrote:
> 
> I've been unable to reproduce this using either jessie or sid's uscan
> (running on a jessie host, admittedly). I'd be interested if anyone else
> can reproduce this or if there's anything unusual about the machine.

Seems that it isn't only present on uscan: while running debsign I get a
segmentation fault.

I've carried out heavy tasks on the machine (compiling,etc), and apart from this
everything looks fine.

I was able to reproduce it again on my workstation configuration deployed
into a fresh lxc container (using https://github.com/viccuad/salt-configs).
There, uscan consumes all the cpu until it gets killed by zsh, and debsign
the same.

> On a side note, looking at the watchfile:
> 
> (?:|.*/)guitarix2(?:[_\-]v?|)(\d[^\s/]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)
>...

Well, that's a slipped leftover from the last maintainer. Thanks for the catch.

Using your d/watch I get the same behavior, both in my machine and the lxc
workstation.


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#863101: Uscan uses all available memory of the system when run against guitarix

[Víctor Cuadrado Juan]

Package: devscripts
Version: 2.17.5
Severity: critical

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When run against guitarix package git repo, at commit 7ff29bd,
for obtaining `guitarix2-0.35.3.tar.xz` that would become the
`guitarix_0.35.3.orig.tar.xz` symlink, `uscan --verbose` uses
all available ram of the system and if lucky it outputs
"Out of memory!".

I'm tagging it as critical because I have had my computer hard
freeze 2 times after executing uscan, needing a power cycle.

I have no configuration enabled for uscan in ~/.devscripts.

Regards,

- --
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


- -- Package-specific info:

- --- /etc/devscripts.conf ---

- --- ~/.devscripts ---
BTS_INTERACTIVE= yes
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBSIGN_KEYID=0xA2591E231E251F36
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i"
DEBUILD_LINTIAN_OPTS="-i -I"

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.23
ii  libc62.24-10
ii  perl 5.24.1-2
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.4.1
ii  at  3.1.20-3
ii  curl7.52.1-5
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.01.20
ii  dput-ng [dput]  1.12
ii  dupload 2.7.0
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-3.1
ii  file1:5.30-1
ii  gnupg   2.1.18-6
ii  gnupg2  2.1.18-6
ii  libdistro-info-perl 0.14
ii  libdpkg-perl1.18.23
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.29-1
ii  lintian 2.5.50.3
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
ii  python3-magic   1:5.30-1
ii  sensible-utils  0.0.9
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.18-5
ii  xz-utils5.2.2-1.2+b1

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  4.4
ii  bls-standalone   0.20151231
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.3
ii  check-all-the-things 2017.01.15.1
pn  cvs-buildpackage 
ii  devscripts-el36.3+nmu1
ii  diffoscope   78
pn  disorderfs   
ii  dose-extra   5.0.1-8
ii  duck 0.12
pn  faketime 
ii  gnuplot  5.0.5+dfsg1-6
ii  gpgv 2.1.18-6
ii  how-can-i-help   15
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
ii  libterm-size-perl0.207-1+b4
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
ii  mutt 1.7.2-1
ii  openssh-client [ssh-client]  1:7.4p1-10
pn  piuparts 
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-34

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEELLKv6mdE0z94m2FAIj8VylqvDngFAlkh5SQACgkQIj8Vylqv
Dnj+SQgAm0una6LSAdQiJ33oxUseyd59jfiivgFRo5yFb6WEqD2TWbqr0k8hsyTu
BnzAekzDpvImPAzEiuZbaETUXzdgpi21s1Xu/YfEahjLUKc/zHK7cqxXaHE9Lk5p
92pU46FOnRdF53w9O1za4xNQSx9ynR2pgaq5V7OE369PuwEamm3OvGIlSjYjktvN
Vdek40WZJXywpxYUKbSwn22tSgyJXcbk4kYRqvs7giX+NIvH/+V6Yo4HpMSge/6j
DVib2/oQmsNkOjEu5wuAfy2KTBnR7Ff41s6thSkyBPdLjP9zwKl08T/VoVBYlRUg
t0vQu/KOSXhaJkPym4GcKl6mpTW3jA==
=Qpp3
-END PGP SIGNATURE-

Bug#850429: ITP docklight

[Juan Gonzalez]

Hello,

I have made a package for debian (1.0-20) Could you please take a look and
provide comments and suggestions, if any?


I am planning to move forward and upload it to the debian repo.
What are the next steps to do ? do i need a mentor?

If anyone has any suggestions feel free to share.

all files are here:
https://github.com/yoosamui/DockLight
Wiki here:
https://github.com/yoosamui/DockLight/wiki


Best Regards
Thanks!

Bug#818905: (no subject)

[Víctor Cuadrado Juan]

Hello,

In its current state, the package doesn't provide the a big chunk of
the functionality that is expected from it (make the Steam controller
work as a controller).

Please, consider raising the severity of this bug to a RC one.

That way, either the package doesn't migrate to Stable, or somebody
with the time or motivation will fix it.

Regards,

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#856048: Missing CSRF parameter in "Manage users" and "Preferences" menu in the web interface

[Juan Carlos Romero]

The bug is debian testing/sid, not in debian stable.

Sorry, but I reported the bug using reportbug from my debian stable laptop.

--
J. Carlos

Bug#856048: ntopng: Missing CSRF parameter in "Manage users" and "Preferences" menu in the web interface

[Juan Carlos Romero]

Source: ntopng
Severity: normal

Dear Maintainer,

It is not possible to use the "Manage users" or "Preferences" menu in
the web interface. I get the following errors:

 Script "/lua/admin/users.lua" returned an error:
 Missing CSRF parameter

 Script "/lua/admin/prefs.lua" returned an error:
 Missing CSRF parameter

Thanks.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#850429: ITP docklight

[Juan Gonzalez]

Hello,

i just want yo know  what i need to do more to contribute with the
docklight package.
The Version 1.0-14 is ready. What are the next steps to do?


Thanks!
Juan Gonzalez
 

Bug#854792: fails when there are two users with the same UID

[Juan Céspedes]

On Thu, Feb 16, 2017 at 12:16 AM, Emilio Pozuelo Monfort 
wrote:

> On 10/02/17 13:38, Juan Cespedes wrote:
> > Summary: accounts-daemon.service fails to work properly when there are
> > two users in the system with the same UID.
>

> I'm not sure that's a system configuration that is supported. If you shoot
> yourself in the foot, you should expect some problems...
>

Neither the Debian Policy nor any other document I am aware of states that
it shouldn't be done.  I do it fairly often for several reasons, and I know
of some other people who do it too.

Furthermore, it has always worked, and suddenly, after upgrading to
stretch, it fails to work *silently*...

-- 
Juan Cespedes

Bug#854792: fails when there are two users with the same UID

[Juan Cespedes]

Package: accountsservice
Version: 0.6.43-1
Severity: serious

Summary: accounts-daemon.service fails to work properly when there are
two users in the system with the same UID.  The service is still
running, but it shows an error message and makes unrelated software
break: gdm3 waits indefinitely and does not start Xorg at boot time.
Removing one of the offending users (or changing its UID) and
restarting accounts-daemon.service makes gdm3 work again.

Details:

After upgrading the system to stretch, gdm3 would not start Xorg
anymore, without giving any error or warning.  After enabling debug
and restarting, its last message was:

Feb 10 13:30:17 petete gdm-launch-environment]: AccountsService: 
ActUserManager: waiting for user manager to load before finding user 
'Debian-gdm'

This made me think there was some problem with accounts-daemon:

8<8<---
# systemctl status accounts-daemon | cat
● accounts-daemon.service - Accounts Service
   Loaded: loaded (/lib/systemd/system/accounts-daemon.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Fri 2017-02-10 13:19:37 CET; 14min ago
 Main PID: 29171 (accounts-daemon)
Tasks: 3 (limit: 4915)
   Memory: 1.4M
  CPU: 81ms
   CGroup: /system.slice/accounts-daemon.service
   └─29171 /usr/lib/accountsservice/accounts-daemon

Feb 10 13:19:36 petete systemd[1]: Stopped Accounts Service.
Feb 10 13:19:36 petete systemd[1]: Starting Accounts Service...
Feb 10 13:19:37 petete accounts-daemon[29171]: error exporting user object: An 
object is already exported for the interface org.freedesktop.Accounts.User at 
/org/freedesktop/Accounts/User1000
Feb 10 13:19:37 petete accounts-daemon[29171]: started daemon version 0.6.43
Feb 10 13:19:37 petete systemd[1]: Started Accounts Service.
8<8<---

As you can see, the service is "loaded" and "active", but it shows an
error about "an object is already exported".  As I said, after
removing the users with duplicate UIDs, accounts-daemon starts without
errors, and gdm3 runs fine and starts Xorg properly.


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

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

Versions of packages accountsservice depends on:
ii  dbus   1.10.14-1
ii  init-system-helpers1.47
ii  libaccountsservice00.6.43-1
ii  libc6  2.24-9
ii  libglib2.0-0   2.50.2-2
ii  libpolkit-gobject-1-0  0.105-17

accountsservice recommends no packages.

Versions of packages accountsservice suggests:
ii  gnome-control-center  1:3.22.1-2

-- no debconf information

Bug#802805: (no subject)

[Víctor Cuadrado Juan]

Upstream project has been decommissioned, perhaps this RFP
should be closed.

Cheers,


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature