Bug#927925: lepton: CVE-2018-20820

[Salvatore Bonaccorso]

Source: lepton
Version: 1.2.1+20170405-3
Severity: important
Forwarded: https://github.com/dropbox/lepton/issues/111

Hi,

The following vulnerability was published for lepton.

CVE-2018-20820[0]:
| read_ujpg in jpgcoder.cc in Dropbox Lepton 1.2.1 allows attackers to
| cause a denial-of-service (application runtime crash because of an
| integer overflow) via a crafted file.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20820
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20820
[1]  https://github.com/dropbox/lepton/issues/111

Regards,
Salvatore

Bug#927926: packer: please package packer 1.4.0

[Corey Hickey]

Package: packer
Version: 1.3.4+dfsg-4
Severity: wishlist

Dear Maintainer,

Thank you for packaging packer. Can you please update the Debian package
for the upstream 1.4.0 release?

https://www.hashicorp.com/blog/announcing-packer-v-1-4-0

Thank you,
Corey

Bug#927924: new upstream (4.0)

[Daniel Baumann]

Package: qemu
Severity: wishlist

Hi,

qemu 4 has been released with significant improvements, it would be nice
if you could upload it to experimental.

Regards,
Daniel

Bug#927919: sway: FTBFS, pkg-config gets variable for scdoc incorrect

[Linda Lapinlampi]

Control: reassign -1 scdoc 1.9.4-1
Control: affects -1 + sway
Severity: serious

On Thu, Apr 25, 2019 at 03:07:14AM +, Linda Lapinlampi wrote:
> Dear Maintainer,
> 
> My attempt to build Salsa VCS checkout with `dpkg-buildpackage -us -uc`
> will fail there:
> 
> ```
> Dependency scdoc found: YES 1.9.4
> Called `/usr/bin/pkg-config --variable=scdoc scdoc` -> 0
> /usr/local/bin/scdoc
> Got pkgconfig variable scdoc : /usr/local/bin/scdoc
> Program /usr/local/bin/scdoc found: NO
> 
> meson.build:100:1: ERROR:  Program(s) ['/usr/local/bin/scdoc'] not found or 
> not executable
> ```

For whatever the reason, /usr/share/pkgconfig/scdoc.pc has an unintended
prefix=/usr/local. scdoc 1.9.4's debian/rules hsa PREFIX=/usr, but this
may not be working.

Bug#927923: unhtml FTCBFS: Uses the build architecture compiler

[Nguyen Van. Hieu]

Source: unhtml
Version: 2.3.9-4
Severity: normal
Tags: patch
User:helm...@debian.org
Usertags: rebootstrap

Hi,

unhtml fails to cross build from source, because it uses the build
architecture compiler.
Using "dh_auto_build" instead of "$(MAKE)" can solve this problem.
Please consider applying the attached patch.

Hieu.

diff -Nru unhtml-2.3.9/debian/rules unhtml-2.3.9/debian/rules
--- unhtml-2.3.9/debian/rules   2012-06-24 01:42:50.0 +0700
+++ unhtml-2.3.9/debian/rules   2017-01-21 23:35:10.0 +0700
@@ -10,7 +10,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 override_dh_auto_build:
-   $(MAKE) CFLAGS="$(FLAGS)"
+   dh_auto_build -- CFLAGS="$(FLAGS)"
 
 override_dh_auto_install:
install -m 755 -D $(PACKAGE) debian/$(PACKAGE)/usr/bin/$(PACKAGE)
-- 
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com

Bug#927922: SSL error: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol

[積丹尼 Dan Jacobson]

Package: w3m
Version: 0.5.3-37

Lynx, chromium work fine.
$ w3m 
https://branch.taipower.com.tw/content/Messagess/Contents.aspx?SiteID=564732602442427467=564732602561157543=564734220745242356
SSL error: error:1425F102:SSL routines:ssl_choose_client_version:unsupported 
protocol

-- System Information:
Debian Release: 10.0
  APT prefers experimental
  APT policy: (990, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages w3m depends on:
ii  libc6  2.28-8
ii  libgc1c2   1:7.6.4-0.4
ii  libgpm21.20.7-5
ii  libssl1.1  1.1.1b-2
ii  libtinfo6  6.1+20181013-2
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages w3m recommends:
ii  ca-certificates  20190110

Versions of packages w3m suggests:
pn  cmigemo   
ii  curl  7.64.0-2
ii  dict  1.12.1+dfsg-8
pn  dict-wn   
ii  dictd 1.12.1+dfsg-8
pn  libsixel-bin  
ii  man-db2.8.5-2
ii  mime-support  3.62
pn  mpv   
ii  sensible-utils0.0.12
ii  w3m-el-snapshot [w3m-el]  1.4.632+0.20190419-1
pn  w3m-img   
ii  wget  1.20.1-1.1
ii  xdg-utils 1.1.3-1
pn  xsel  

-- no debconf information

Bug#927919: sway: FTBFS, pkg-config gets variable for scdoc incorrect

[Linda Lapinlampi]

Control: notfound -1 1.0~rc3-1

On Thu, Apr 25, 2019 at 03:07:14AM +, Linda Lapinlampi wrote:
> ```
> Dependency scdoc found: YES 1.9.4
> Called `/usr/bin/pkg-config --variable=scdoc scdoc` -> 0
> /usr/local/bin/scdoc
> Got pkgconfig variable scdoc : /usr/local/bin/scdoc
> Program /usr/local/bin/scdoc found: NO
> 
> meson.build:100:1: ERROR:  Program(s) ['/usr/local/bin/scdoc'] not found or 
> not executable
> ```

Possibly relevant change at upstream. Not found from upstream's 1.0~rc5
release, I'd guess.

https://github.com/swaywm/sway/pull/3856

> meson: use pkg-config var for scdoc path

Bug#903635: This is RC; breaks unrelated software

[Arnaud Rebillout]

Looks like a fix was proposed at:
https://github.com/docker/libnetwork/pull/2339/files

However this fix didn't receive any feedback from upstream so far, and
I'm not familiar with the docker codebase myself. So I'm a bit reluctant
to import this patch. And on the other hand, after a quick look the
patch looks pretty straightforward and harmless.

Maybe someone else wants to have a look at this patch and give some
feedback?


On Wed, 24 Apr 2019 20:04:43 +0100 Jonathan Dowland  wrote:

> severity 903635 critical
> thanks
>
> Justification: "makes unrelated software on the system (or the whole
system) break"
>
> Installing docker.io changed my FORWARD chain policy to DROP, breaking
> networking for unrelated virsh-based VMs that I had installed on the
machine at
> the time. This matches exactly the text for severity: serious.
>
> --
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
> ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
> ⠈⠳⣄
>
>

Bug#927921: Modeset: Invalid argument. No GUI.

[thefoo]

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

Dear maintainer,

I have two kernels installed: 4.19.0-2 and 4.19.0-4 (both amd64 from buster). 
The described problems happen only when 4.19.0-4 is booted.

Basically, any (Xorg) GUI start fails, and /var/log/Xorg.0.log contains eg. 
this line:
(EE) modeset(0): Failed to set mode: Invalid argument

I have not much ideas what additional information could help, please tell me 
anything you'd like to know.

Note that I have installed bumblebee and nvidia driver, but run intel driver 
usually. Completely removing bumblebee and anything nvidia-related doesn't 
change the situation.

Thank you



-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-4-amd64 root=/dev/mapper/sda4_crypt ro 
rootflags=subvol=main quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Precision 7520
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: 1.13.0
board_vendor: Dell Inc.
board_name: 09Y5WW
board_version: A00

** Loaded modules:
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
fuse
i2c_dev
cmac
bnep
bbswitch(OE)
snd_hda_codec_hdmi
snd_hda_codec_realtek
snd_hda_codec_generic
nls_ascii
nls_cp437
vfat
fat
ext4
mbcache
jbd2
fscrypto
ecb
ip6t_REJECT
nf_reject_ipv6
cdc_mbim
arc4
cdc_wdm
cdc_ncm
usbnet
qcserial
usb_wwan
mii
usbserial
xt_hl
ip6_tables
ip6t_rt
ipt_REJECT
nf_reject_ipv4
dell_rbtn
mei_wdt
dell_wmi
wmi_bmof
mxm_wmi
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
ppdev
coretemp
nft_limit
dell_laptop
dell_smbios
kvm_intel
dell_wmi_descriptor
iwlmvm
btusb
btrtl
dcdbas
btbcm
kvm
btintel
dell_smm_hwmon
irqbypass
mac80211
sg
bluetooth
intel_cstate
xt_limit
drbg
joydev
evdev
ansi_cprng
serio_raw
xt_addrtype
xt_tcpudp
ecdh_generic
efi_pstore
snd_hda_intel
iwlwifi
intel_uncore
crc16
intel_rapl_perf
snd_hda_codec
i915
xt_conntrack
snd_hda_core
nft_compat
rtsx_pci_ms
efivars
snd_hwdep
cfg80211
snd_pcm
iTCO_wdt
memstick
iTCO_vendor_support
snd_timer
snd
soundcore
rfkill
drm_kms_helper
idma64
nft_counter
drm
mei_me
mei
processor_thermal_device
parport_pc
ie31200_edac
i2c_algo_bit
intel_soc_dts_iosf
parport
intel_pch_thermal
battery
int3403_thermal
dell_smo8800
wmi
intel_hid
int3400_thermal
int3402_thermal
video
sparse_keymap
acpi_thermal_rel
int340x_thermal_zone
pcc_cpufreq
acpi_pad
ac
button
nf_conntrack_netbios_ns
nf_conntrack_broadcast
nf_nat_ftp
nf_nat
nf_conntrack_ftp
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
nfnetlink
efivarfs
ip_tables
x_tables
autofs4
btrfs
xor
zstd_decompress
zstd_compress
xxhash
raid6_pq
libcrc32c
crc32c_generic
algif_skcipher
af_alg
sr_mod
cdrom
uas
usb_storage
usbhid
dm_crypt
dm_mod
sd_mod
hid_alps
hid_generic
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
rtsx_pci_sdmmc
mmc_core
ahci
xhci_pci
libahci
xhci_hcd
aesni_intel
aes_x86_64
libata
crypto_simd
psmouse
cryptd
e1000e
glue_helper
usbcore
scsi_mod
i2c_hid
i2c_i801
rtsx_pci
hid
intel_lpss_pci
intel_lpss
usb_common
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core 
Processor Host Bridge/DRAM Registers [8086:5918] (rev 05)
Subsystem: Dell Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM 
Registers [1028:07b0]
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: ie31200_edac
Kernel modules: ie31200_edac

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor PCIe Controller (x16) [8086:1901] (rev 05) (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics P630 
[8086:591d] (rev 04) (prog-if 00 [VGA controller])
Subsystem: Dell HD Graphics P630 [1028:07b0]
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: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 05)
Subsystem: Dell Xeon 

Bug#927920: Plymouth 0.9.4-1.1 Prevents Login Under Kernel 4.19.0-4 on ASUS ET2322

[Kurt Meyer]

Package: plymouth
Version: 0.9.4-1.1
Severity: important

Dear Maintainer,

On 04/17/2019, package desktop-base was to be upgraded from 10.0.0 to 10.0.2, 
also requiring the installation of package plymouth 0.9.4-1.1. Upon rebooting 
my computer, I got a few ACPI errors, which I always get, and then just a black 
screen.

I attempted to view syslog covering the time of reboot, but couldn't locate 
anything that looked suspect.

Eventually, I was able to get to a login screen (lightdm) by using kernel 
4.19.0-3.

This evening I downgraded desktop-base from 10.0.2 to 10.0.0 and rebooted my 
computer using kernel 4.19.0-4 and again got no login screen.

I then removed the following plymouth packages, rebooted my computer, and I got 
a login screen under kernel 4.19.0-4:

libplymouth4 0.9.4-1.1
plymouth 0.9.4-1.1
plymouth-label 0.9.4-1.1

-- inxi output for my system:

Machine:
 Type: Laptop System: ASUSTeK product: ET2321I v: 0801 serial: 
 Mobo: ASUSTeK model: ET2321I v: Rev 1.xx serial: 
 BIOS: American Megatrends v: 0801 date: 11/18/2014
CPU:
 Topology: Dual Core model: Intel Core i7-4500U bits: 64 type: MT MCP
 L2 cache: 4096 KiB
 Speed: 822 MHz min/max: 800/3000 MHz Core speeds (MHz): 1: 798 2: 798 3: 798
 4: 798
Graphics:
 Device-1: Intel Haswell-ULT Integrated Graphics driver: i915 v: kernel
 Device-2: NVIDIA GK208M [GeForce GT 740M] driver: nouveau v: kernel
 Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa
 resolution: 1920x1080~60Hz
 OpenGL: renderer: Mesa DRI Intel Haswell Mobile v: 4.5 Mesa 18.3.6
Audio:
 Device-1: Intel Haswell-ULT HD Audio driver: snd_hda_intel
 Device-2: Intel 8 Series HD Audio driver: snd_hda_intel
 Sound Server: ALSA v: k4.19.0-4-amd64
Network:
 Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
 IF: enp2s0 state: down
 Device-2: Broadcom and subsidiaries BCM4352 802.11ac Wireless Network Adapter
 driver: wl
 IF: wlp3s0 state: up

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

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

Versions of packages plymouth depends on:
ii init-system-helpers 1.56+nmu1
ii initramfs-tools 0.133
ii libc6 2.28-8
ii libdrm2 2.4.97-1
pn libplymouth4 
ii lsb-base 10.2019031300
ii systemd 241-3
ii udev 241-3

plymouth recommends no packages.

Versions of packages plymouth suggests:
hi desktop-base 10.0.0
pn plymouth-themes 

Bug#919231: Salt-master unable to access directories

[Felipe Sateler]

On Wed, Apr 24, 2019 at 7:13 AM Michael Biebl  wrote:

> Hi Felipe
>
> On Wed, 3 Apr 2019 15:29:44 -0300 Felipe Sateler 
> wrote:
> > Unfortunately the fix seems to have been merged with some other
> > refactorings and the diff is not as small[1]. I'll try to check if some
> of
> > the patches are not necessary.
> >
> >
> > [1] https://github.com/systemd/systemd/pull/12005/files
>
>
> Were you able to make some progress here?
>
> I'm considering making another upload for buster to fix #927008 (without
> that upstream patch, systemd-journal-remote/upload is pretty much
> useless in buster)
>

Sorry, I have been buried with $work, so I haven't been able to look at
this. I don't think I'll have time in the short term either



>

-- 

Saludos,
Felipe Sateler

Bug#927919: sway: FTBFS, pkg-config gets variable for scdoc incorrect

[Linda Lapinlampi]

Source: sway
Version: 1.0-1
Severity: important
Tags: experimental, ftbfs, upstream

Dear Maintainer,

My attempt to build Salsa VCS checkout with `dpkg-buildpackage -us -uc`
will fail there:

```
Dependency scdoc found: YES 1.9.4
Called `/usr/bin/pkg-config --variable=scdoc scdoc` -> 0
/usr/local/bin/scdoc
Got pkgconfig variable scdoc : /usr/local/bin/scdoc
Program /usr/local/bin/scdoc found: NO

meson.build:100:1: ERROR:  Program(s) ['/usr/local/bin/scdoc'] not found or not 
executable
```

It looks like it finds /usr/bin/scdoc, but then pkg-config changes to
look for /usr/local/bin/scdoc and subsequently fails.

The relevant part of upstream's meson.build is:

```
scdoc = dependency('scdoc', version: '>=1.9.2', native: true, required: 
get_option('man-pages'))
if scdoc.found()
scdoc_prog = find_program(scdoc.get_pkgconfig_variable('scdoc'), 
native: true)
[...]
endif
```

I'm attaching Meson build logs. Thanks.

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

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

$ apt policy scdoc
scdoc:
  Installed: 1.9.4-1
  Candidate: 1.9.4-1
  Version table:
 *** 1.9.4-1 500
500 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
Build started at 2019-04-25T02:45:02.424601
Main binary: /usr/bin/python3
Python system: Linux
The Meson build system
Version: 0.49.2
Source dir: /home/wub/.local/src/sway/sway
Build dir: /home/wub/.local/src/sway/sway/obj-x86_64-linux-gnu
Build type: native build
Project name: sway
Project version: 1.0
Sanity testing C compiler: cc
Is cross compiler: False.
Sanity check compiler command line: cc /home/wub/.local/src/sway/sway/obj-x86_64-linux-gnu/meson-private/sanitycheckc.c -o /home/wub/.local/src/sway/sway/obj-x86_64-linux-gnu/meson-private/sanitycheckc.exe
Sanity check compile stdout:

-
Sanity check compile stderr:

-
Running test binary command: /home/wub/.local/src/sway/sway/obj-x86_64-linux-gnu/meson-private/sanitycheckc.exe
Appending CFLAGS from environment: '-g -O2 -fdebug-prefix-map=/home/wub/.local/src/sway/sway=. -fstack-protector-strong -Wformat -Werror=format-security'
Appending LDFLAGS from environment: '-Wl,-z,relro -Wl,-z,now'
Appending CPPFLAGS from environment: '-Wdate-time -D_FORTIFY_SOURCE=2'
Native C compiler: cc (gcc 8.3.0 "cc (Debian 8.3.0-6) 8.3.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.6.0)
Determining dependency 'json-c' with pkg-config executable '/usr/bin/pkg-config'
Called `/usr/bin/pkg-config --modversion json-c` -> 0
0.13.1
Called `/usr/bin/pkg-config --cflags json-c` -> 0
-I/usr/include/json-c
Called `/usr/bin/pkg-config json-c --libs` -> 0
-L/usr/lib/x86_64-linux-gnu -ljson-c
Called `/usr/bin/pkg-config json-c --libs` -> 0
-ljson-c
Running compile:
Working directory:  /tmp/tmp7u9sl240
Command line:  cc /tmp/tmp7u9sl240/testfile.c -pipe -D_FILE_OFFSET_BITS=64 -o /tmp/tmp7u9sl240/output.exe -g -O2 -fdebug-prefix-map=/home/wub/.local/src/sway/sway=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -O0 

Code:
 #include

int main(int argc, char **argv) {
printf("%ld\n", (long)(sizeof(void *)));
return 0;
};
Compiler stdout:
 
Compiler stderr:
 
Program stdout:

8

Program stderr:


Running compile:
Working directory:  /tmp/tmp0zuflusu
Command line:  cc /tmp/tmp0zuflusu/testfile.c -pipe -D_FILE_OFFSET_BITS=64 -c -o /tmp/tmp0zuflusu/output.obj -g -O2 -fdebug-prefix-map=/home/wub/.local/src/sway/sway=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O0 --print-search-dirs 

Code:
 
Compiler stdout:
 install: /usr/lib/gcc/x86_64-linux-gnu/8/
programs: =/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin/
libraries: 

Bug#927918: sway: ambiguous version dependency on wlroots

[Linda Lapinlampi]

Source: sway
Version: 1.0-1
Severity: normal
Tags: upstream

Dear Maintainer,

debian/control has Build-Depends on libwlroots-dev (>= 0.5). Upstream's
release notes for tag 1.0 says the release depends on wlroots 0.5.
meson.build depends on wlroots_version = '>=0.4.1'. meson.build also
remains at >=0.4.1 in upstream master branch (post-1.0 release).

As you can see, there's two conflicting informations for for the
required wlroots version from upstream sources.

https://github.com/swaywm/sway/releases/tag/1.0

Which wlroots dependency version is really required for Debian?

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

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

Bug#927917: firmware-atheros: missing ath10k/QCA9377/hw1.0/firmware-6.bin

[Antonio Terceiro]

Package: firmware-atheros
Version: 20190114-1
Severity: normal
Tags: patch

While installing a Samgung laptop using the Buster RC1 Debian Installer,
the installer kept asking for ath10k/QCA9377/hw1.0/firmware-6.bin. I
inspected the firmware-atheros*.deb in the firmware partition that I
prepared in the USB drive, and indeed there was no such file. I
downloaded the source for firmware-nonfree, and noticed that file was
there, it was just not included in the binary.

The attached patch makes sure that the file is included in the binary
package. The version number to use in the defines file was obtained by
looking at the commit that introduced firmware-6.bin:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/ath10k/QCA9377/hw1.0/firmware-6.bin

To get it to build locally, I also had to update debian/rules.defs, but
I assume that is already part of your workflow.

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

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

firmware-atheros depends on no packages.

firmware-atheros recommends no packages.

Versions of packages firmware-atheros suggests:
ii  initramfs-tools  0.133
From b8ac831929a6d684b647162c3831e1950644cd5e Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Wed, 24 Apr 2019 23:06:50 -0300
Subject: [PATCH] firmware-atheros: ship ath10k/QCA9377/hw1.0/firmware-6.bin

---
 debian/config/atheros/defines | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/config/atheros/defines b/debian/config/atheros/defines
index ebc5c3c..2864a29 100644
--- a/debian/config/atheros/defines
+++ b/debian/config/atheros/defines
@@ -35,6 +35,7 @@ files:
  ath10k/QCA9377/hw1.0/board.bin
  ath10k/QCA9377/hw1.0/board-2.bin
  ath10k/QCA9377/hw1.0/firmware-5.bin
+ ath10k/QCA9377/hw1.0/firmware-6.bin
  ath10k/QCA9887/hw1.0/board.bin
  ath10k/QCA9887/hw1.0/firmware-5.bin
  ath10k/QCA9888/hw2.0/board-2.bin
@@ -213,6 +214,10 @@ version: 2
 desc: Qualcomm Atheros QCA9377 rev 1.0 firmware
 version: WLAN.TF.1.0-2-QCATFSWPZ-5
 
+[ath10k/QCA9377/hw1.0/firmware-6.bin_base]
+desc: Qualcomm Atheros QCA9377 rev 1.0 firmware
+version: WLAN.TF.2.1-00021-QCARMSWP-1
+
 [ath10k/QCA9887/hw1.0/board.bin_base]
 desc: Qualcomm Atheros QCA9887 rev 1.0 board configuration
 version: 1
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#927915: sway: build-adep has no version >= 0.48.0 on meson

[Linda Lapinlampi]

Source: sway
Version: 1.0-1
Severity: normal
Tags: stretch, jessie
Control: notfound -1 1.0~beta.2-3
Control: found -1 1.0~rc1-1

Dear Maintainer,

meson.build declares project(meson_version: '>=0.48.0') in the source,
but debian/control file omits this version number from Build-Depends.
Please consider adding the dependent version number to debian/control,
thanks.

(I am using the Salsa VCS checkout, prior to NEW queue upload.)

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

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

Bug#924445: pulseaudio crashes randomly, no diagnostic on terminal, possibly associated with Wesnoth

[Joshua Hudson]

Unfortunately there will never be a coredump because it's not crashing
in any usual sense. It just stops.

joshua@nova:~ϟ gdb pulseaudio
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from pulseaudio...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/pulseaudio
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
W: [pulseaudio] authkey.c: Failed to open cookie file
'/home/joshua/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key
'/home/joshua/.config/pulse/cookie': No such file or directory
[New Thread 0x7fffeb8c1700 (LWP 3287)]
[New Thread 0x7fffeb069700 (LWP 3288)]
W: [pulseaudio] authkey.c: Failed to open cookie file
'/home/joshua/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key
'/home/joshua/.config/pulse/cookie': No such file or directory
E: [pulseaudio] module-console-kit.c: GetSessionsForUnixUser() call
failed: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.ConsoleKit was not provided by any .service files
E: [pulseaudio] module.c: Failed to load module "module-console-kit"
(argument: ""): initialization failed.
[Thread 0x7fffeb8c1700 (LWP 3287) exited]
[Thread 0x7fffeb069700 (LWP 3288) exited]
[Inferior 1 (process 3282) exited normally]
(gdb)

Long time between the E: lines mostly referencing a module that's in
the config file but not actually installed anymore and the failure.

Bug#926935: arpack: FTBFS (does not honor parallel=n in DEB_BUILD_OPTIONS)

[Emmanuel Arias]

Hello,

> The safe/conservative thing to do would be to use 1 job for the test
suite.

IMHO the use of nproc it's a good option, because this way we will be
closer to the original idea of upstream.



signature.asc
Description: OpenPGP digital signature

Bug#927914: gblic: deal with Japanese new era "令和 (Reiwa)"

[Hideki Yamane]

package: glibc
tags: l10n, patch

Hi,

 To deal with Japanese new era "令和 (Reiwa)" (from 1st May), please
 add attached patch that is taken from upstream(*)

 It should be applied to stretch as well.

 (*) 
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=7423da211d1490d9fc76c2f0ce49e5dd90ea9bcc;hp=4aeff335ca19286ee2382d8eba794ae5fd49281a


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
>From 3a660291290fd6e65db1f17fbfff67fa4ef2bc99 Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Thu, 25 Apr 2019 10:33:00 +0900
Subject: [PATCH] add localedata/locale-ja_JP-reiwa_era.diff

---
 .../localedata/locale-ja_JP-reiwa_era.diff| 30 +++
 debian/patches/series |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 debian/patches/localedata/locale-ja_JP-reiwa_era.diff

diff --git a/debian/patches/localedata/locale-ja_JP-reiwa_era.diff b/debian/patches/localedata/locale-ja_JP-reiwa_era.diff
new file mode 100644
index ..141ee8a4
--- /dev/null
+++ b/debian/patches/localedata/locale-ja_JP-reiwa_era.diff
@@ -0,0 +1,30 @@
+Index: glibc/NEWS
+===
+--- glibc.orig/NEWS
 glibc/NEWS
+@@ -7,6 +7,10 @@ using `glibc' in the "product" field.
+ 
+ Version 2.28.1
+ 
++Major new features:
++
++* The entry for the new Japanese era has been added for ja_JP locale.
++
+ Deprecated and removed features, and other changes affecting compatibility:
+ 
+ * For powercp64le ABI, Transactional Lock Elision is now enabled iff kernel
+Index: glibc/localedata/locales/ja_JP
+===
+--- glibc.orig/localedata/locales/ja_JP
 glibc/localedata/locales/ja_JP
+@@ -14946,7 +14946,9 @@ am_pm	"";""
+ 
+ t_fmt_ampm "%p%I%M%S"
+ 
+-era	"+:2:1990//01//01:+*::%EC%Ey";/
++era	"+:2:2020//01//01:+*::%EC%Ey";/
++	"+:1:2019//05//01:2019//12//31::%EC";/
++	"+:2:1990//01//01:2019//04//30::%EC%Ey";/
+ 	"+:1:1989//01//08:1989//12//31::%EC";/
+ 	"+:2:1927//01//01:1989//01//07::%EC%Ey";/
+ 	"+:1:1926//12//25:1926//12//31::%EC";/
diff --git a/debian/patches/series b/debian/patches/series
index 461d8245..d75630cb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -20,6 +20,7 @@ localedata/submitted-en_AU-date_fmt.diff
 localedata/submitted-es_MX-decimal_point.diff
 localedata/submitted-it_IT-thousands_sep.diff
 localedata/git-en_US-date_fmt.diff
+localedata/locale-ja_JP-reiwa_era.diff
 
 alpha/local-gcc4.1.diff
 alpha/submitted-dl-support.diff
-- 
2.20.1

Bug#924253: [Pkg-privacy-maintainers] Bug#924253: mat2: Please update backport provided via stretch-backports

[Georg Faerber]

Hi u,

Thanks for your fast reply, and sorry for the delay on my side:

On 19-04-16 13:35:18, Ulrike Uhlig wrote:
> I don't think there is a policy issue with uploading this backport
> yourself (so no toe-stepping involved), but by uploading that backport
> you commit to keep it alive during the lifetime of stretch-backports.

Alright and sure (regarding the future maintenance).

> The question would rather be if there might be technical issues
> resulting from that upload for users of packages that use
> nautilus-python.

I've read the changelog between the version in stable and the one in
testing, and didn't spot any breaking changes, mostly bug fixes.

Still, proper testing before doing the actual upload would be in order,
I guess? For example, ensuring that other extensions still work with
this new version?

Thanks again,
cheers,
Georg


signature.asc
Description: PGP signature

Bug#919058: itstool maintainer's help needed

[Lars Skovlund]

Hi Mike,

I've just noticed this bug report:

https://github.com/mate-desktop/mate-applets/issues/388

It's been closed, so apparently the problem can be worked around by
manipulating the XML. Of course, itstool still needs to be fixed.

So far, there is no response on either the RedHat bug or on the
respective GitHub issues. There is a new itstool version available,
but it only includes the fixes that we've had available as long as this
bug has been open.

Best regards,

Lars

Bug#925464: new upstream release (1.3rc1)

[Chris Knadle]

Update on the bug:

Chris Knadle:
[..]
> I doubt this package is going to get accepted by the Release Team, because
> upload after the freeze is meant for only small targeted fixes.  I'll make the
> request to see if it's possible, but I expect that the chances of this being
> accepted to be very low.

The release team has rejected the change in #927266 (which is not unexpected,
and I agree with their decision).

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

So Debian Buster will release with mumble 1.3.0~git20190125.440b173+dfsg-2

   -- Chris

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

Bug#927913: Second chromium kills the first one, and we see "Restore pages?"

[積丹尼 Dan Jacobson]

Package: chromium
Version: 74.0.3729.108-1
Severity: important

$ chromium &
$ sleep 22
$ chromium &

The second one kills the first one, and we see "Restore pages?"

Bug#927912: unblock: gcalcli/4.0.4-2 (pre-approval)

[Unit 193]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Howdy,

Pending approval, I'm uploading a version of gcalcli which contains an upstream 
patch to fix the reliance on the Google shortening service.

If a user invokes one of the subcommands with '--details url', the application 
hits traceback issues as the service has been shut down.

See https://github.com/insanum/gcalcli/issues/440 for more details of the 
problem.


The changelog reads:

gcalcli (4.0.4-2) unstable; urgency=medium

  * d/p/remove_url_shortening.patch: Remove the deprecated goo.gl service.

 -- Unit 193   Wed, 24 Apr 2019 19:46:16 -0400


And debdiff:

diff --git a/debian/changelog b/debian/changelog
index 868a5db..f6bd57b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+gcalcli (4.0.4-2) unstable; urgency=medium
+
+  * d/p/remove_url_shortening.patch: Remove the deprecated goo.gl service.
+
+ -- Unit 193   Wed, 24 Apr 2019 19:46:16 -0400
+
 gcalcli (4.0.4-1) unstable; urgency=medium
 
   * New upstream version 4.0.4
diff --git a/debian/patches/remove_url_shortening.patch 
b/debian/patches/remove_url_shortening.patch
new file mode 100644
index 000..74a3c44
--- /dev/null
+++ b/debian/patches/remove_url_shortening.patch
@@ -0,0 +1,225 @@
+From 428378a88f89d154c8d4046deb9bdb5eb4e81019 Mon Sep 17 00:00:00 2001
+From: Joshua Crowgey 
+Date: Mon, 15 Apr 2019 21:07:49 -0700
+Subject: [PATCH] Remove URL Shortening [fixes #440] (#443)
+
+Google has removed the urlshortening service.  After some discussion,
+it was decided to remove the shortening facilities instead of trying to
+integrate with a separate provider.  This makes our code simpler and
+folks who need url shortening can hopefully layer on what they need.
+---
+ ChangeLog|3 +++
+ gcalcli/argparsers.py|   16 +---
+ gcalcli/gcal.py  |   39 +--
+ setup.py |2 +-
+ tests/test_argparsers.py |9 ++---
+ 5 files changed, 20 insertions(+), 49 deletions(-)
+
+Index: gcalcli/ChangeLog
+===
+--- gcalcli.orig/ChangeLog
 gcalcli/ChangeLog
+@@ -1,3 +1,6 @@
++v4.1.0
++  * Removed url shortening due to Google deprecation #440
++
+ v4.0.4
+   * Minor bugfixes: conky colors, issues with setup.py
+ 
+Index: gcalcli/gcalcli/argparsers.py
+===
+--- gcalcli.orig/gcalcli/argparsers.py
 gcalcli/gcalcli/argparsers.py
+@@ -7,11 +7,9 @@ from gcalcli.printer import valid_color_
+ from oauth2client import tools
+ import copy as _copy
+ 
+-DETAILS = ['all', 'calendar', 'location', 'length', 'reminders', 
'description',
+-   'longurl', 'shorturl', 'url', 'attendees', 'email', 'attachments']
++DETAILS = ['calendar', 'location', 'length', 'reminders', 'description',
++   'url', 'attendees', 'email', 'attachments']
+ 
+-BOOL_DETAILS = ['calendar', 'location', 'length', 'reminders', 'description',
+-'attendees', 'email', 'attachments']
+ 
+ PROGRAM_OPTIONS = {
+ '--client-id': {'default': gcalcli.__API_CLIENT_ID__,
+@@ -60,13 +58,9 @@ class DetailsAction(argparse._AppendActi
+ details = _copy.copy(getattr(namespace, self.dest, {}))
+ 
+ if value == 'all':
+-details = {d: True for d in BOOL_DETAILS}
+-elif value in BOOL_DETAILS:
++details = {d: True for d in DETAILS}
++else:
+ details[value] = True
+-elif value in ['shorturl', 'url']:
+-details['url'] = 'short'
+-elif value == 'longurl':
+-details['url'] = 'long'
+ 
+ setattr(namespace, self.dest, details)
+ 
+@@ -90,7 +84,7 @@ def get_details_parser():
+ details_parser = argparse.ArgumentParser(add_help=False)
+ details_parser.add_argument(
+ '--details', default={}, action=DetailsAction,
+-choices=DETAILS,
++choices=DETAILS + ['all'],
+ help='Which parts to display, can be: ' + ', '.join(DETAILS))
+ return details_parser
+ 
+Index: gcalcli/gcalcli/gcal.py
+===
+--- gcalcli.orig/gcalcli/gcal.py
 gcalcli/gcalcli/gcal.py
+@@ -47,7 +47,6 @@ class GoogleCalendarInterface:
+ max_retries = 5
+ auth_http = None
+ cal_service = None
+-url_service = None
+ 
+ ACCESS_OWNER = 'owner'
+ ACCESS_WRITER = 'writer'
+@@ -140,8 +139,7 @@ class GoogleCalendarInterface:
+ OAuth2WebServerFlow(
+ client_id=self.options['client_id'],
+ client_secret=self.options['client_secret'],
+-scope=['https://www.googleapis.com/auth/calendar',
+-   
'https://www.googleapis.com/auth/urlshortener'],
++

Bug#927911: systemd: Does not expand %h identifier in ExecStart

[Norbert Preining]

Package: systemd
Version: 241-3
Severity: important

Hi

it seems that the documentation of systemd is incorrect, or incomplete,
as it states that
suffix. In the unit file itself, the instance parameter may be referred 
to using "%i" and other
specifiers, see below.
(man page of systemd.unit)
and down there %h is listed as home directory of the user.

We use a systemd unit file that has onedrive@.service
ExecStart=/usr/bin/onedrive --monitor 
--confdir=/home/%i/.config/onedrive
which works as expected. But the moment I change it to
ExecStart=/usr/bin/onedrive --monitor --confdir=%h/.config/onedrive
it breaks because %h is not expanded.

Best

Norbert


-- Package-specific info:

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

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

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

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  241-3

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

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 241-3

-- no debconf information

Bug#897993: random black flickering

[Eduard Bloch]

On Mon, 7 May 2018 12:15:37 +0200 =?UTF-8?Q?Michel_D=c3=a4nzer?= 
 wrote:
> On 2018-05-05 04:20 PM, Eduard Bloch wrote:
> > Package: xserver-xorg-video-amdgpu
> > Version: 18.0.1-1
> > Severity: normal
> >
> > Hello,
> >
> > my card (cheaper version of Rx560) has been working quite well for months.
> > But I made a dist-upgrade a few weeks ago and since then I see strange
> > flickering happening every few minutes, sometimes even multiple times
> > per minute. Feels like a quick insertion of a black frame. Maybe a
> > silent GPU reset or something?
> >
> > It seems to happen more often when mouse is moving and/or Firefox is
> > active. First I suspected the application where I saw it most in the
> > first days (another web browser) but now I see this happen from time to
> > time with other applications, like the gvim window I see in front of me
> > right now.
> >
> > First I attribute this to the amdgpu.dc=1 kernel option which I have set
> > for testing purposes before, but removing it did not change the
> > behavior.
>
> That's because DC is enabled by default for you, you need amdgpu.dc=0 to
> disable it. This is a DC issue which is fixed in current 4.16.y upstream.

Hi,

not sure this was the issue or maybe the root cause is somewhere else.
I got my graphics card replaced in the meantime (now a RX580) and the
problem still appears, although less frequent. I can reproduce it well
when screen config is set to 2560x1440 and 75Hz, latest Sid version of
xserver-xorg-video-amdgpu.

Example: for a still image, there are no issues, but when I open Firefox in
background (maximized) and I start moving the gvim window (mail editor)
around the screen in circles then it flickers at least once per second,
often even faster. And the temporarily visible overlay looks more like
garbage (i.e. it feels like a quick GPU restart). The flickering is much
less disturbing if the moved window is a simple one, like xterm, so it
might have some connection to the drawing performance?

60Hz mode is okay, though. And there are no such issues with Windows.
Also, I have had a 4K monitor here once (60Hz device) and there were no
such problems IIRC.

Best regards,
Eduard.

--
error compiling committee.c: too many arguments to function

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: Bug#927896: Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Samuel Thibault]

Michael Biebl, le jeu. 25 avril 2019 01:02:44 +0200, a ecrit:
> Am 25.04.19 um 00:54 schrieb Samuel Thibault:
> > Michael Biebl, le jeu. 25 avril 2019 00:27:58 +0200, a ecrit:
> 
> >> Keep in mind that I only proposed to change policykit-1 to linux-any.
> >> The libpolkit-*-dev packages would still be any.
> > 
> > Ah!  I thought you meant the whole source package...
> 
> source packages can't be linux-any, only binary packages (but I guess
> you know that).

Yes, but people very often just mark all binary packages of a source
package as linux-any, to just avoid having to care about !linux.

Samuel

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: Bug#927896: Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Michael Biebl]

Am 25.04.19 um 00:54 schrieb Samuel Thibault:
> Michael Biebl, le jeu. 25 avril 2019 00:27:58 +0200, a ecrit:

>> Keep in mind that I only proposed to change policykit-1 to linux-any.
>> The libpolkit-*-dev packages would still be any.
> 
> Ah!  I thought you meant the whole source package...

source packages can't be linux-any, only binary packages (but I guess
you know that).



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#927879: ca-certificates should not hardcode QuoVadis certificate authorities in /etc/ca-certificates.conf

[Michael Shuler]

On 4/24/19 5:22 PM, Soppy bear wrote:


1. This is a Debian problem because the end user should be able to
use TLS without having to import/use certificates without any
practical use for normal operations.


Users *can* configure the ca-certificate package and set CA trust for 
each and every CA, as well as configure new-CA trust however they wish. 
Users can preseed debconf at installation time to trust no CAs, if they 
so desire. I'm not going to get into the details of preseeding 
installations, but runtime configuration is done with:


  dpkg-reconfigure ca-certificates

Please, describe the problem better, if there is a concrete bug. The 
description here and previously make little sense to me, other than a 
personal preference and misunderstanding of how to configure CA trust.


If there is a CA in the current Mozilla bundle that is problematic for 
you and the Internet, please contact Mozilla with this information, if 
there is evidence of evil doings, Mozilla is the correct project to 
inform. If you don't trust a particular CA that is in the current 
Mozilla bundle, disable it. You can automate this, if you maintain a 
large number of systems.



2. I have removed Firefox from my systems permanently because of this
reason and upgraded my research laptop to debian unstable for this
specific reason.


OK. What does this have to do with the ca-certificates package?

--
Kind regards,
Michael

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: Bug#927896: Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Samuel Thibault]

Michael Biebl, le jeu. 25 avril 2019 00:27:58 +0200, a ecrit:
> Am 25.04.19 um 00:06 schrieb Samuel Thibault:
> > Michael Biebl, le mer. 24 avril 2019 23:44:57 +0200, a ecrit:
> >> It's quite simple really: If policykit-1 is not functional on !linux,
> >> there should be no policykit-1 package on !linux.
> > 
> > That's a principle I can understand, yes.  But then the principle meets
> > the rest of what Debian is: a clench of dependencies, policykit-1 being
> > relatively central in it. Having to spend time to disable almost a
> > hundred of dependencies is really not a good use of volunteer time.
> 
> You don't have to disable almost a hundred of dependencies, you just
> need to acknowledge that some packages are not fully functional on !linux.

Sure, I completely agree with that, cf the rest of my previous mail.

> Keep in mind that I only proposed to change policykit-1 to linux-any.
> The libpolkit-*-dev packages would still be any.

Ah!  I thought you meant the whole source package...

> The effect would be, that packages which declare a hard Depends on
> policykit-1 would be not installable on !linux. And I think that's a
> good thing. If they really need policykit-1, we should not pretend
> that a functional policykit-1 exists when it doesn't.

That part looks good enough to me indeed.

Samuel

Bug#918535: Any action?

[Dan Mick]

Hi; is anything in progress about this update?  Should I go figure out
how to do an NMU?

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: Bug#927896: Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Michael Biebl]

Am 25.04.19 um 00:06 schrieb Samuel Thibault:
> Michael Biebl, le mer. 24 avril 2019 23:44:57 +0200, a ecrit:
>> It's quite simple really: If policykit-1 is not functional on !linux,
>> there should be no policykit-1 package on !linux.
> 
> That's a principle I can understand, yes.  But then the principle meets
> the rest of what Debian is: a clench of dependencies, policykit-1 being
> relatively central in it. Having to spend time to disable almost a
> hundred of dependencies is really not a good use of volunteer time.

You don't have to disable almost a hundred of dependencies, you just
need to acknowledge that some packages are not fully functional on !linux.

Keep in mind that I only proposed to change policykit-1 to linux-any.
The libpolkit-*-dev packages would still be any.
The effect would be, that packages which declare a hard Depends on
policykit-1 would be not installable on !linux. And I think that's a
good thing. If they really need policykit-1, we should not pretend that
a functional policykit-1 exists when it doesn't.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature

Bug#927879: ca-certificates should not hardcode QuoVadis certificate authorities in /etc/ca-certificates.conf

[Soppy bear]

omg... i cant believe u just closed that ticket... :u

pls let me explain.

1. This is a Debian problem because the end user should be able to use TLS 
without having
to import/use certificates without any practical use for normal operations. 

2. I have removed Firefox from my systems permanently because of this reason 
and upgraded my research laptop to debian unstable
for this specific reason.

Thank you.

tk

==
tkad...@yandex.com | Twitter: @wise_project
https://www.isotoperesearch.ca/
Not everyone who wander are lost.

On Wed, 24 Apr 2019 13:45:42 -0500
Michael Shuler  wrote:

> Control: tags -1 + wontfix
> 
> Won't fix and done, only because there is no bug to fix. Please, read 
> on. (For further discussion on this specific topic, I highly recommend 
> reading and/or posting to Mozilla dev-security-policy[0], not the Debian 
> BTS. The Mozilla project would be the correct place to, for instance, 
> submit concrete evidence on the topic, not the BTS.)
> 
> On 4/24/19 9:47 AM, Soppy bear wrote:
> > 1. The configuration file /etc/ca-certificates.conf is hard coding 
> > potentially
> > insecure mozilla/QuoVadis certificate authorities into the base system. This
> > change might unintentionally affect TLS security in future releases of 
> > Debian
> > and is not necessary or recommended.
> > 
> > 2. We also need to make sure debconf will no trust and import new 
> > certificate authorities by default when doing package upgrades or there 
> > should be way for the user to remove any unwanted ca entries.
> 
> /etc/ca-certificates.conf is a user-controlled configuration file. It is 
> not hardcoded. The ca-certificates configuration can be updated by users 
> at any time. For instance, (1.) users may wish to disable particular 
> CAs, or (2.) users may configure all updates to ask for approval or deny 
> all updates.
> 
>dpkg-reconfigure ca-certificates
> 
> > 1. https://isotopesoftware.ca/wiki/DarkMatter
> > 2. https://twitter.com/wise_project/status/1102931776954089474
> > 3. https://twitter.com/wise_project/status/1120920928915947520
> 
> I'm well aware of this topic. I appreciate the random twitter links, but 
> this topic is already under extensive discussion on the Mozilla 
> dev-security-policy mailing list[0], which I read closely. No decisions 
> have been made as of yet by the Mozilla project on this topic. I will 
> not make arbitrary decisions defaulting something for users that users 
> may make on their own, based on their own opinions, if they are 
> different than the experts in the field.
> 
> Please, by all means, disable their CA, if you don't trust it - that is 
> why you have the ability to do so.
> 
> I get it, I really do, it is an interesting story, but the story is 
> still playing out. Is it politics? Is the true? I've read the news 
> stories. The CA trust story is still being discussed and evidence is 
> still being gathered, but I do not have the definitive answer for all 
> users. The Mozilla project is *the* definitive source for this area of 
> technology, and a lot of people are watching, myself included. If 
> Mozilla decides to pull the CA, it will get pulled from ca-certificates.
> 
> Do what you feel is right for you on your systems. The configuration 
> options are there for you to customize as you see fit.
> 
> [0] https://groups.google.com/forum/#!forum/mozilla.dev.security.policy
> 
> -- 
> Kind regards,
> Michael

Bug#914109: xscreensaver-data: looks for image files to display even though it is told not to

[Jamie Zawinski]

To be clear: my intention is to ignore this trivial problem.

Bug#499795: SSL Fax - HylaFAX+ 7.0.0

[Lee Howard]

With the HylaFAX+ 7.0.0 release earlier this month there is now another
significant feature missing from the Debian HylaFAX package.

Debian users who wish to use SSL Fax or any of the other myriad fax
features features found in HylaFAX+ that have been listed here before
continue to be forced to either install HylaFAX+ from source or to
switch distributions.  My observations are that users are doing both of
those in roughly equal measures.

It would take very little effort to simply change the source tarball in
the package build and make whatever needed modifications are required
(probably very few) to the patches.

Bug#927910: screenfetch: error printed if /proc/fb doesn't exist

[Matti Viljanen]

Package: screenfetch
Version: 3.8.0-8
Severity: minor

Dear Maintainer,

I am running Debian Buster on my Fujitsu Q703 aka. QNap TS-221, details 
of which you can find below. I installed screenfetch via apt and ran the 
command, and it printed out a warning before the actual output:


awk: cannot open /proc/fb (No such file or directory)

This is because my NAS box does not have a framebuffer device, and the 
Debian version of the screenfetch is rather old. This happens in 
DetectIntelGPU() function, which does not test if file /proc/fb exists.


This was fixed in upstream in 20 Apr 2017:

https://github.com/KittyKatt/screenFetch/commit/dc72b5932e86ba9c4e36110408690abeb2004070

Please consider updating the source. Thank you.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 4.19.0-4-marvell
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8)

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

Versions of packages screenfetch depends on:
ii  bc  1.07.1-2+b1
ii  procps  2:3.3.15-2

Versions of packages screenfetch recommends:
ii  scrot  0.9-1

screenfetch suggests no packages.

-- no debconf information

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: Bug#927896: Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Samuel Thibault]

Michael Biebl, le mer. 24 avril 2019 23:44:57 +0200, a ecrit:
> It's quite simple really: If policykit-1 is not functional on !linux,
> there should be no policykit-1 package on !linux.

That's a principle I can understand, yes.  But then the principle meets
the rest of what Debian is: a clench of dependencies, policykit-1 being
relatively central in it. Having to spend time to disable almost a
hundred of dependencies is really not a good use of volunteer time.

Really, this has been discussed several times in the past for various
packages: for all people's use of time, it's really better to just leave
an implementation that just returns errors, than having to bug each
and every of a hundred of maintainers just to disable the dependency
because the non-functional implementation was removed. Only to bug them
_*again*_ once the implementation has been made to work, to re-enable
the features that would probably just have been disabled automatically
on getting the error from the non-functional implementation! This is
really exactly the case for the package I know about, brltty.

Samuel

Bug#927767: e2fsck: Needs to clear *all* MMP flags in one pass

[Elliott Mitchell]

On Tue, Apr 23, 2019 at 03:49:50PM -0400, Theodore Ts'o wrote:
> 
> If this is not satisfactory for you then you shouldn't be using
> MMP, and need to be doing something else, like solving this problem at
> the hypervisor layer.  I'd love to be able to offer something better,
> but I'd also like to have faster of light travel and anti-gravity
> technology.  The laws of physics are very hard to work around, alas

Paying that penalty one or twice is okay by me.  Paying that penalty 3,
4, 5 or more times on boot is unsatisfactory for me.

I've been creating VMs where all filesystems have MMP in order to be
careful.  I'm okay with paying the penalty one time when `e2fsck` is run
on the filesystem runs by an initial ramdisk.  My hope is to at worst pay
that penalty *one* more time when all the other filesystems mounted by
the VM get checked.

Simply needs a program which scans /etc/fstab and does the flag clearing
process in parallel for all non-root ext4 filesystems.


> So if these are real block devices in Domain 0 (as opposed to
> something made up by the hypervisor and presented to its guest VM's),
> then the O_EXCL/EBUSY mount protections should protect you.  I suspect
> this might mean changing the Xen hypervisor so that it is passing
> knowledge to whether some VM has a block device opened with O_EXCL is
> passed down to the Xen layer --- and the Xen layer informing the guest
> VM if some other VM has the block device opened with O_EXCL.  That's
> what I mean by making it be the hypervisor's problem.
> 
> You'll be able to solve the problem much more efficiently (with less
> overhead) and much more robustly, if you solve the problem at the
> hypervisor control plane level.

Yes, this would be superior.  I currently believe Xen's protection for
this is imperfect and thus I'm using a backup plan which *should* work,
even if imperfect.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#924523: unblock: plinth/19.2

[Sunil Mohan Adapa]

On 24/04/19 3:30 am, Sam Hartman wrote:
>> "Sunil" == Sunil Mohan Adapa  writes:
> 
> Sunil> On 23/04/19 3:44 am, Ivo De Decker wrote:
> >> Hi,
> 
> 
> Sunil> However, there were still issues that we felt needed fixing
> Sunil> for a stable release. Some of these fixes are workarounds for
> Sunil> issues that were not fixed in other packages (such as #919517
> Sunil> and smooth upgrade failures in other packages).
> 
> Sunil> Pretty much all the changes between 19.1 and 19.2 (version
> Sunil> increment is because freedombox is a native package) were
> Sunil> focused on Buster release during which we were not adding
> Sunil> extra features.
> 
> I'm speaking as an individual who has been following freedombox in the
> background for years and who has had to make decisions like what the
> release team does in other projects.  I'm *not* speaking as the DPL even
> a little bit.  And even if you follow my recommendations here, the RT
> might be more conservative than you hope for.
>  
> 
> In order to maximize the number of changes that can get in between 19.1
> and 19.2, I recommend that you spend some time to make the release
> team's job easier.
> 
> 
> I'd recommend going through each commit, explaining why it meets the
> release guidelines.
> 
> If it doesn't and you want to argue for an exception, be clear about why
> that specific change is safe.  As an example, if one of your functional
> tests covers it, say that.
> 
> Your job is to make sure that the release team can easily see in one
> place why the change is worth the risk and that you've thought about it
> explicitly and considered the option of dropping that change.
> 
> And you probably will find changes that it's better to drop.
> Regardless of whether you missed the deadline by hours or whatever,
> we're talking about  this issue now not then.  There's less time between
> now and the buster release than there was back in March, and that means
> the risks are higher.  And so in arguing for a change you need to
> account for that increased risk.
> 
> And because the RT has a lot of work to do you need to make it easy for
> them.  They are going to have to review each change, so you'd better do
> that first:-)
> 
> As an example, from your original bug:
> 
>   - Upgrade changes: Complementary to unattened-upgrades, assist
> non-technical  
> FreedomBox users to automatically upgrade from older versions of
> bind,  
> tt-rss, firewalld, libpam-modules, and openvpn. This helps users
> migrating  
> from Stretch. Another change was to avoid a conffile prompt within
>   
> FreedomBox itself to ease future upgrades.
>   
> 
> This sounds like an important bug: you ran upgrade testing from stretch
> and ran into an issue that impacted users.
> If there's not a bug number, you want one probably.  If there is, make
> sure it's marked important and it's clear why.
> 

Thank you for taking the time to explain how to assist release team with
the process. I didn't do a good job of justifying the changes first time.

No matter the outcome, I regret putting extra burden on release team at
a time when every is working hard for and anticipating Buster.

Below I attempt to review and explain each change between 19.1 and 19.2
so that it may become easier for release team to review each change
individually.

https://salsa.debian.org/freedombox-team/plinth/commits/v19.2

Changes to documentation


- These changes can be considered during full freeze as per freeze policy.

- FreedomBox documentation appears to users directly in the web interface.

- List includes changes to copyright messages and the machine readable
copyright files. These changes have extremely slim chances to break the
functionality and have been tested well.

8ae99fad doc: Fetch manual from wiki
7c01585f debian/copyright: Fix filename for tahoe-lafs logo
0a1a0cd1 debian/copyright: Update copyright for logos
06d1b167 debian/copyright: Add license text for CC-BY-SA-3.0
1e48a64d debian/copyright: Add license text for GPL-2 and GPL-3
f5c85471 debian/copyright: Add license text for public-domain
a4fdf3f7 debian/copyright: Add full text for AGPL-3+
130102e1 debian/copyright: Minor fixes
e4e37992 debian/copyright: Move some more app icons from LICENSES
a1d13029 debian/copyright: Include some URLs dropped from LICENSES
2297defe debian/copyright: Move more app icons from LICENSES
990c2446 debian/copyright: Fix typo in year
f2b45ea1 debian/copyright: Move some app icons from LICENSES
7b0957d7 debian/copyright: Remove unnecessary fields for native package
d4b4d1e2 debian/copyright: Move all license texts to end
4e5b1f34 debian: Add copyright info for theme images
44dd3c0e LICENSES: Remove files that are same license as rest of the source
354b0ca7 LICENSES: Add reference to debian/copyright
2202439a debian: Add copyright info for individual logo files
5b9b1cbf debian: Add 

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: Bug#927896: Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Michael Biebl]

Am 24.04.19 um 23:37 schrieb Samuel Thibault:
> Michael Biebl, le mer. 24 avril 2019 22:56:11 +0200, a ecrit:
>> Am 24.04.19 um 22:31 schrieb Samuel Thibault:
>>> Michael Biebl, le mer. 24 avril 2019 22:21:03 +0200, a ecrit:
 Am 24.04.19 um 21:58 schrieb Samuel Thibault:
> Michael Biebl, le mer. 24 avril 2019 21:40:04 +0200, a ecrit:
>> Am 24.04.19 um 21:24 schrieb Samuel Thibault:
>>> consolekit has been removed, please drop the dependency from the
>>> policykit-1 package, as the attached patch does.
>>
>> I guess we should make policykit-1 linux-any, given that we don't have a
>> working backend on !linux.
>
> That'd notably mean having to make the libpolkit-gobject-1-dev
> dependency [linux-any] on apparently 69 packages.

 How so? It would just mean those packages become unbuildable on !linux
>>>
>>> Yes, while a lot of them would just build and work fine on !linux
>>> without any change anywhere but keep policykit-1 build find on
>>> !linux.
>>>
>>> For instance brltty's dependency on policykit is just a convenience, it
>>> can fully work without it. That's probably the same for a lot of these
>>> 69 packages. I don't personally plan to take the time to have a look at
>>> these 69 packages. I don't think anybody will happily plan to.
>>
>> Well, I don't think the alternative is better, i.e. pretend policykit-1
>> is workable on !linux, even if that means it is less convenient.
> 
> What do you mean by "better" exactly?
> 
> Providing a -dev package doesn't mean pretending that it'll work. A lot
> of packages only have a Recommends: policykit-1, i.e. AIUI they don't
> expect the library to be always working.
> 
> Really, is that really a lot of work to just drop that line and be done
> with the discussion?
> 
> I'm not even asking to do it for Buster, since there won't be any !linux
> released arch.

It's quite simple really: If policykit-1 is not functional on !linux,
there should be no policykit-1 package on !linux.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#914109: xscreensaver-data: looks for image files to display even though it is told not to

[Francesco Potortì]

>> From a user point of view, if I say that you should not look for image
>> files to display, you should just not do that.  This is a bug in
>> Xscreensaver.  There is no good reason why it should give an error.
>
>With your settings, the only option is to change the failure mode from
>"print an error message as text", to "don't print any text and just
>display colorbars or black instead".

As a user, I would expect that if I say "don't look fo images on my
disk" nobody would say "hey, you know? I cannot find images on your
disk".  Maybe I am naive, but this sounds obvious to me.

This means that this is a bug.

As a programmer, knowing the above I can see at least two ways out.  For
a start, Xscreensaver should avoid calling a program which needs image
files when it is told that disk files should not be read.  As far as the
specific program is concerned, it could convert the display image to
JPEG, if that's really what it needs.

Maybe none of these is simple or maybe no one is willing to do that.
But this is different from ignoring the problem.

As a maintainer, I could say that the problem is real and that it will
be pushed upstream.  Which again is different from not spending time on
it.

>Doesn't seem like much of an improvement to me. So I'm not gonna spend
>time on that.

It is certainly would be an improvement from a user point of view to not
seeing an error which is meant for a programmer.

That said, thank you for helping maintaining Xscreensaver.

-- 
IPIN'19 http://ipin2019.isti.cnr.itVoice:  +39.050.621.3058
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - Area della ricerca CNR  Skype:  wnlabisti
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Samuel Thibault]

Michael Biebl, le mer. 24 avril 2019 22:56:11 +0200, a ecrit:
> Am 24.04.19 um 22:31 schrieb Samuel Thibault:
> > Michael Biebl, le mer. 24 avril 2019 22:21:03 +0200, a ecrit:
> >> Am 24.04.19 um 21:58 schrieb Samuel Thibault:
> >>> Michael Biebl, le mer. 24 avril 2019 21:40:04 +0200, a ecrit:
>  Am 24.04.19 um 21:24 schrieb Samuel Thibault:
> > consolekit has been removed, please drop the dependency from the
> > policykit-1 package, as the attached patch does.
> 
>  I guess we should make policykit-1 linux-any, given that we don't have a
>  working backend on !linux.
> >>>
> >>> That'd notably mean having to make the libpolkit-gobject-1-dev
> >>> dependency [linux-any] on apparently 69 packages.
> >>
> >> How so? It would just mean those packages become unbuildable on !linux
> > 
> > Yes, while a lot of them would just build and work fine on !linux
> > without any change anywhere but keep policykit-1 build find on
> > !linux.
> > 
> > For instance brltty's dependency on policykit is just a convenience, it
> > can fully work without it. That's probably the same for a lot of these
> > 69 packages. I don't personally plan to take the time to have a look at
> > these 69 packages. I don't think anybody will happily plan to.
> 
> Well, I don't think the alternative is better, i.e. pretend policykit-1
> is workable on !linux, even if that means it is less convenient.

What do you mean by "better" exactly?

Providing a -dev package doesn't mean pretending that it'll work. A lot
of packages only have a Recommends: policykit-1, i.e. AIUI they don't
expect the library to be always working.

Really, is that really a lot of work to just drop that line and be done
with the discussion?

I'm not even asking to do it for Buster, since there won't be any !linux
released arch.

Samuel

Bug#927827: Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian

[Bernhard Schmidt]

Control: found -1 1:9.11.5.P4+dfsg-1
Control: tags -1 + pending

On Tue, Apr 23, 2019 at 10:24:54PM +0200, Mathieu Parent wrote:

> +/var/lib/samba/bind-dns/** rwk,
> 
> But we may do better with something like this (to be tested and improved):
> 
>/var/lib/samba/private/dns.keytab r,
>/var/lib/samba/private/named.conf r,
> -  /var/lib/samba/private/dns/** rwk,
> + /var/lib/samba/bind-dns/*.conf r,
> + /var/lib/samba/bind-dns/dns/** rwk,
> -  /etc/smb.conf r,
> +  /etc/samba/smb.conf r,

The filename has already been fixed in -2 and I've staged the
bind-dns/dns/** part in git. A CVE for bind9 is expected for later
today, I'll include it in the next upload.

I've marked the version in testing to be affected (which it is), so -2
and -3 can at least migrate.

Bernhard

Bug#927909: ITP: golang-github-gcla-deep -- Golang deep variable equality test that returns human-readable differences

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-gcla-deep
  Version : 1.0.2-1
  Upstream Author : Graham Clark, Daniel Nichter
* URL : https://github.com/gcla/deep
* License : Expat
  Programming Lang: Go
  Description : Golang deep variable equality test that returns 
human-readable differences

 Deep Variable Equality for Humans.
 .
 This package provides a single function: deep.Equal. It's like
 reflect.DeepEqual (http://golang.org/pkg/reflect/#DeepEqual) but
 much friendlier to humans (or any sentient being) for two reason:
  • deep.Equal returns a list of differences
  • deep.Equal does not compare unexported fields (by default)
 .
 This is a fork of go-test/deep package with an additional feature.
 .
 Message from author about changes made in fork:
 Some packages may require Equal()'s parameters to be set in a
 particular way that is incompatible with other users within
 the same program. The global configuration parameters can be
 changed and restored, but this could lead to bugs due to race
 conditions. This commit makes the parameters that control
 Equal()'s operation part of a structure, Comparer, for which
 Equal() is now a method. Users can configure their own
 Comparer struct if desired. To preserve the existing package
 interface, the package-level Equals() method will use a
 default Comparer object that relies on pointers to the current
 global configuration parameters (pointers so that the
 operation of the global Equals() function will change
 immediately upon changing the value of any global
 configuration setting).

This package in the dependency tree of upcoming "termshark" package (#927799).

Bug#926935: arpack: FTBFS (does not honor parallel=n in DEB_BUILD_OPTIONS)

[Ghislain Vaillant]

Le mer. 24 avr. 2019 à 17:02, Santiago Vila  a écrit :

> On Wed, Apr 24, 2019 at 04:47:16PM +0200, Sylvestre Ledru wrote:
> > Le 24/04/2019 à 16:45, Santiago Vila a écrit :
> > > On Wed, Apr 24, 2019 at 04:24:59PM +0200, ghisv...@gmail.com wrote:
> > > > Anyone objecting on applying Santiago's patch to src:arpack to fix
> the
> > > > occasionnal FTBFS on single-core builders?
> > > >
> > > > If not, then I am happy to prepare a release.
> > >
> > > Thanks a lot.
> > >
> > > One minor clarification: The failure happens always on single-cpu
> systems,
> > > not just occassionally.
> > >
> > Don't hesitate to forward that upstream if you find a fix
> > https://github.com/opencollab/arpack-ng
>
> A general fix (i.e. one that upstream accept) would probably involve
> using "nproc" command inside the Makefiles, but then we would have to
> override that anyway to avoid using so many simultaneous jobs if the
> user explicitly ask for less jobs via DEB_BUILD_OPTIONS.
>
> The safe/conservative thing to do would be to use 1 job for the test suite.
>
> I can put an issue in github if you confirm there is not one yet.
>
> Thanks.
>

I did not find one, but glanced very quickly through the issue tracker.

>

Bug#927908: xpdf: Italic text is shown as a regular one

[Bjarni Ingi Gislason]

Package: xpdf
Version: 3.04-13
Severity: normal

  This can be fixed by adding the following to the ~/.xpdrc file

fontFile Times-Italic /usr/share/fonts/type1/gsfonts/n021023l.pfb
fontFile Times-Roman  /usr/share/fonts/type1/gsfonts/n021003l.pfb

N.B.

  The URL for new versions is wrong.

  A new version of the software is avilable.

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

Kernel: Linux 4.19.28-2 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xpdf depends on:
ii  libc6 2.28-8
ii  libgcc1   1:8.3.0-6
ii  libpaper1 1.1.26
ii  libpoppler82  0.71.0-3
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxm42.3.8-2
ii  libxt61:1.1.5-1+b3

Versions of packages xpdf recommends:
pn  cups-bsd
ii  gsfonts-x11 0.26
ii  poppler-data0.4.9-2
ii  poppler-utils   0.71.0-3
ii  sensible-utils  0.0.12

xpdf suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#927886: Reassign bug 927886

[Boyuan Yang]

Control: reassign -1 src:librsvg
Control: found -1 2.44.10-2
Control: forwarded -1 https://gitlab.gnome.org/GNOME/librsvg/issues/395
Control: severity -1 important
Control: affects -1 deepin-image-viewer
Control: tags -1 + fixed-upstream
X-Debbugs-CC: libr...@packages.debian.org jbi...@debian.org

Reassigning the bug report accordingly. This bug in librsvg was fixed
in 2.44.11. Maybe we should cherry-pick the patch?

--
Thanks,
Boyuan Yang

Bug#926958: Proposed security upload for FreeRADIUS

[Bernhard Schmidt]

Am 24.04.19 um 21:23 schrieb Salvatore Bonaccorso:

Hi Salvatore,

>> I've gained access to the FreeRADIUS salsa repo and have pushed a new
>> debian/stretch branch containing last years security upload and the
>> cherry-picked fixes for #926958
>>
>> It applies and builds cleanly, I'm currently waiting for a colleague who
>> runs our Radius proxies to test it.
> 
> Looking closer now again at the issue, if I understand correctly, the
> module would not be enabled by default and to exploit the issue one
> would actually as well need to have access to the authentication
> server.

It's not enabled by default, that's correct. I think universities are
pushing for it because it is a secure-with-default configuration to
authenticate eduroam users, compared to EAP-TTLS or MSCHAPv2 where
security relies on a proper TLS verification no user is configuring
manually.

I have no idea whatsoever about the inner workings of the EAP-PWD
algorithm and I don't even try to understand EC cryptography, but as far
as I understand both FreeRADIUS CVEs are not about timing attacks, but
missing validation of user-supplied parameters.

---
Implementation-Specific Flaws

While investigating 4 different EAP-pwd implementations, we discovered
that all 4 were vulnerable to invalid curve and reflection attacks.
Although these are implementation-specific flaws, this indicates both
vulnerabilities might be present in other implementations of EAP-pwd as
well. We therefore recommend to audit EAP-pwd implementations for these
two vulnerabilities.
Invalid Curve Attack

The first implementation-specific vulnerability is an invalid curve
attack, and would allow an attacker to authenticate as any user (without
knowing the password). The problem is that on the reception of an
EAP-PWD Commit frame, a vulnerable EAP-pwd implementation does not
verify whether the received elliptic curve point is valid. To fix this
vulnerability, it must be checked that the received point is on the
elliptic curve, and that it is not the point at infinity (e.g. using the
function EC_POINT_is_on_curve and EC_POINT_is_at_infinity).
Additionally, EAP-pwd implementations must check that the received
scalar s is within the range 1 < s < r, where r is the order of the
elliptic curve being used. If the scalar is not within this range, or
the curve point is not valid, the handshake should be aborted.

An adversary can exploit the above vulnerability by sending a scalar
equal to zero (or equal to the order of the elliptic curve), and by
sending a specially crafted (invalid) elliptic curve point. This
combination causes the negotiated session key to have a very small range
of possible values. The adversary can then test each possible key until
the correct session key is found. We successfully confirmed this attack
against both vulnerable client-side and server-side implementations.
Reflection Attack

The second implementation-specific vulnerability might allow “fake”
authentications. More precisely, an attacker can reflect the received
scalar and element (i.e. elliptic curve point) that was sent by the
server, in its own commit message, and subsequently reflect the confirm
value as well. This causes the adversary to successfully authenticate as
the victim. Fortunately, the adversary will not learn the negotiated
session key, meaning the adversary cannot actually perform any actions
as the victim.

This vulnerability can be patched by comparing the received scalar and
curve point to the one generated by the server (i.e. by comparing it to
the element and scalar that was sent to the client). If either of them
are the same, the handshake should be aborted.

We successfully tested this attack against vulnerable client-side
implementations of EAP-pwd.
---

I think the timing-based attack was the one in src:wpa (Dragonblood)
CVE-2019-9494, CVE-2019-9495

The two redhat bug tracker entries you linked say

CVE-2019-11234 freeradius: eap-pwd: fake authentication using reflection

A vulnerability was found in FreeRadius. An attacker can reflect the
received scalar and element from the server in it's own commit message,
and subsequently reflect the confirm value as well. This causes the
adversary to successfully authenticate as the victim. Fortunately, the
adversary will not posses the negotiated session key, meaning the
adversary cannot actually perform any actions as this user.


CVE-2019-11235 freeradius: eap-pwd: authentication bypass via an invalid
curve attack

A vulnerability was found in FreeRadius. An invalid curve attack allows
an attacker to authenticate as any user (without knowing the password).
The problem is that on the reception of an EAP-PWD Commit frame,
FreeRADIUS doesn't verify whether the received elliptic curve point is
valid.

> Unless I miss something in the picture, I would say this could be
> fixed via the next point release for stretch, and does not warrant a
> DSA on its own.
> 
> Do I miss something?

I'm fine with that as well, I'm not keen on doing a 

Bug#927886:

[Felix Yan]

Should be a librsvg bug that was fixed in 2.44.11.

Ref: https://gitlab.gnome.org/GNOME/librsvg/issues/395

-- 
Regards,
Felix Yan



signature.asc
Description: OpenPGP digital signature

Bug#927907: flatpak directories are not in the search path set by the XDG_DATA_DIRS

[Ioan Eugen Stan]

Package: flatpak
Version: 1.2.4-1
Severity: normal

Dear Maintainer,

I tried to `flatpak --user update` and I got this message.
I think flatpak should be added by default to the XDG_DATA_DIRS env.

I think flatpak is a very nice piece of technology.

```sh
▶ flatpak --user update

Note that the directories

'/var/lib/flatpak/exports/share'
'/home/ieugen/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

Looking for updates…
Nothing to do.
```
My XDG_DATA_DIRS looks like this:
```
▶ env | grep XDG_DATA_DIRS
XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
```

I switched to Plasma under Wayland recently, don't know if it is important. I'm
running Debian Buster (mostly) with some third party packages and some from
sid.




-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing')
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=ro_RO.UTF8, LC_CTYPE=ro_RO.UTF8 (charmap=UTF-8), LANGUAGE=ro:en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flatpak depends on:
ii  bubblewrap 0.3.1-4
ii  libappstream-glib8 0.7.14-1
ii  libarchive13   3.3.3-4
ii  libc6  2.28-8
ii  libdconf1  0.30.1-2
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-1
ii  libgpgme11 1.12.0-6
ii  libjson-glib-1.0-0 1.4.4-2
ii  libostree-1-1  2019.1-1
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libseccomp22.3.3-4
ii  libsoup2.4-1   2.64.2-2
ii  libsystemd0241-3
ii  libxau61:1.0.8-1+b2
ii  libxml22.9.4+dfsg1-7+b3
ii  xdg-dbus-proxy 0.1.1-1
ii  xdg-desktop-portal 1.2.0-1

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.23-4
ii  gtk-update-icon-cache3.24.5-1
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   241-3
ii  p11-kit  0.23.15-2
ii  policykit-1  0.105-25
ii  shared-mime-info 1.10-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.2.0-1

Versions of packages flatpak suggests:
ii  avahi-daemon  0.7-4+b1

-- no debconf information

Bug#927901: unblock: lucene-solr/3.6.2+dfsg-19

[Niels Thykier]

Control: tags -1 moreinfo

Markus Koschany:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package lucene-solr
> 
> I made a mistake when I installed solr-permissions.conf into the wrong
> /etc/systemd/system/ directory. This makes solr unusable because
> tomcat can't write to /var/lib/solr. A user spotted the error and reported
> it here:
> 
> https://salsa.debian.org/java-team/lucene-solr/commit/ae53f09f37b18aa836640b256137a3a9e26e186f
> 
> The only change is installing this file to
> /etc/systemd/system/tomcat9.service.d now which makes it work again.
> 
> Regards,
> 
> Markus
> 
> 
> unblock lucene-solr/3.6.2+dfsg-19
> 
> [...]
> 

Hi,

Thanks for working to improve buster.

I suspect this change is missing an "rm_conffile" for this misplaced
configuration file (everything in /etc is by default tagged as a
conffile for anything built with debhelper).  Could you please have a
look at that and ensure this part is handled correctly?

(otherwise, I think the changes look good)

Thanks,
~Niels

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Michael Biebl]

Am 24.04.19 um 22:31 schrieb Samuel Thibault:
> Michael Biebl, le mer. 24 avril 2019 22:21:03 +0200, a ecrit:
>> Am 24.04.19 um 21:58 schrieb Samuel Thibault:
>>> Michael Biebl, le mer. 24 avril 2019 21:40:04 +0200, a ecrit:
 Am 24.04.19 um 21:24 schrieb Samuel Thibault:
> consolekit has been removed, please drop the dependency from the
> policykit-1 package, as the attached patch does.

 I guess we should make policykit-1 linux-any, given that we don't have a
 working backend on !linux.
>>>
>>> That'd notably mean having to make the libpolkit-gobject-1-dev
>>> dependency [linux-any] on apparently 69 packages.
>>
>> How so? It would just mean those packages become unbuildable on !linux
> 
> Yes, while a lot of them would just build and work fine on !linux
> without any change anywhere but keep policykit-1 build find on
> !linux.
> 
> For instance brltty's dependency on policykit is just a convenience, it
> can fully work without it. That's probably the same for a lot of these
> 69 packages. I don't personally plan to take the time to have a look at
> these 69 packages. I don't think anybody will happily plan to.
> 

Well, I don't think the alternative is better, i.e. pretend policykit-1
is workable on !linux, even if that means it is less convenient.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#927906: CVE-2019-8354 CVE-2019-8355 CVE-2019-8356 CVE-2019-8357

[Moritz Muehlenhoff]

Source: sox
Severity: grave
Tags: security

Please see these links for descriptions and patches:
https://security-tracker.debian.org/tracker/CVE-2019-8354
https://security-tracker.debian.org/tracker/CVE-2019-8355
https://security-tracker.debian.org/tracker/CVE-2019-8356
https://security-tracker.debian.org/tracker/CVE-2019-8357

Cheers,
Moritz

Bug#927905: lxqt-qtplugin try to load the wrong version of libfm-qt

[Alf Gaida]

Package: lxqt-qtplugin
Version: 0.14.1~1-gc122cbd-1
Severity: important
Tags: patch

Dear Maintainer,

lxqt-qtplugin try to load libfm-qt.so which is strictly a dev symlink - the 
right choice would be libfm-qt.so.6.
This brings up the poor Qt file dialog instead of the LXQt one when opening a 
file. 

For Buster a sufficient solution would be hard wiring the needed so-version.

--- lxqt-qtplugin-0.14.0.orig/src/lxqtplatformtheme.cpp
+++ lxqt-qtplugin-0.14.0/src/lxqtplatformtheme.cpp
@@ -239,7 +239,7 @@ QPlatformDialogHelper *LXQtPlatformTheme
 // The createFileDialogHelper() method is dynamically loaded from 
libfm-qt on demand
 if(createFileDialogHelper == nullptr) {
 // try to dynamically load libfm-qt.so
-QLibrary libfmQtLibrary{QLatin1String("libfm-qt")};
+QLibrary libfmQtLibrary{QLatin1String("libfm-qt.so.6")};
 libfmQtLibrary.load();
 if(!libfmQtLibrary.isLoaded()) {
 return nullptr;

Thanks to @wxl (Lubuntu Team) for spotting this.

Cheers Alf


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

Kernel: Linux 5.0.9-towo.4-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxqt-qtplugin depends on:
ii  libc6 2.28-8
ii  libdbusmenu-qt5-2 0.9.3+16.04.20160218-1
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg1-1
ii  libqt5dbus5   5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5xdgiconloader3  3.4.0~11-g91100ee-1
ii  libstdc++68.3.0-6

Versions of packages lxqt-qtplugin recommends:
ii  libfm-qt6 0.14.2~36-g06d8d31-2
ii  lxqt-config   0.14.2~42-g0f43068-1
ii  lxqt-session  0.14.2~12-g292c281-1

Versions of packages lxqt-qtplugin suggests:
pn  lxqt | lxqt-core  

-- no debconf information

Bug#927904: claws-mail: filtering option does not work as excepted

[Pierre]

Package: claws-mail
Version: 3.17.1-1~bpo9+1
Severity: normal

Dear Maintainer,

I am using Claws-Mail with a POP account with two differents computers, with a 
setup
in order to have sent mail on both computers.
The first computer runs Debian, the second OpenIndiana (with Claws-Mail 3.16).

When I am sending a mail, Claws-Mail automatically adds my email address in the 
Bcc field,
Thank to the option given in "Account preferences" -> "Compose".

Then, I use two filters (1 and 2) to move automatically these sent mails :
Condition 1:
header "X-Mailer" matchcase "linux" & from matchcase "X@X.X"
Action 1:
mark_as_read move "#mh/Mail-XXX/Trash"

Condition 2:
header "X-Mailer" matchcase "solaris" & from matchcase "X@X.X"
Action 2:
move "#mh/Mail-XXX/sent"

For the OpenIndiana computer, "solaris" and "linux" are just reversed.

The Debian computer is ignoring these rules, and the OpenIndiana machine is 
running fine.
For example, if I send a mail from this address to another mail address, the 
Debian machine
will ignore the filtering action and the mail will stay in the inbox folder.

I tried to change the configuration files and mails, the Debian computer still 
have this issue,
but not the OpenIndiana computer.

Could you help me please ?

Thank you in advance,
Pierre



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

Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages claws-mail depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libcompfaceg11:1.5.2-5+b2
ii  libdb5.3 5.3.28-12+deb9u1
ii  libenchant1c2a   1.6.0-11+b1
ii  libetpan17   1.6-3
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u4
ii  libgtk2.0-0  2.24.31-2
ii  libice6  2:1.0.9-2
ii  libldap-2.4-22.4.44+dfsg-5+deb9u2
ii  liblockfile1 1.14-1+b1
ii  libnettle6   3.3-1+b2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  librsvg2-2   2.40.16-1+b1
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3
ii  libsm6   2:1.2.2-1+b3
ii  xdg-utils1.1.1-1+deb9u1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2016.11.20-0-0.1
ii  aspell-fr [aspell-dictionary]  0.50-3-8
ii  claws-mail-i18n3.14.1-3
ii  xfonts-100dpi  1:1.0.4+nmu1
ii  xfonts-75dpi   1:1.0.4+nmu1

Versions of packages claws-mail suggests:
ii  chromium [www-browser] 73.0.3683.75-1~deb9u1
pn  claws-mail-doc 
pn  claws-mail-tools   
ii  firefox-esr [www-browser]  60.6.1esr-1~deb9u1
pn  gedit | kwrite | mousepad | nedit  

-- no debconf information

Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

[Mark Cave-Ayland]

On 24/04/2019 21:30, Frank Scheiner wrote:

> On 4/24/19 22:07, John Paul Adrian Glaubitz wrote:
>> On 4/24/19 9:46 PM, Mark Cave-Ayland wrote:
>>> For reference the CHRP bootinfo.txt isn't a configuration file, but is 
>>> actually
>>> parsed by CHRP-compliant open firmwares directly - SPARC firmwares, 
>>> including
>>> OpenBIOS don't support them. Can you explain why grub on SPARC is trying to 
>>> access
>>> this file?
>>
>> Good point, I didn't notice that there is a CHRP header and assumed that we 
>> need
>> this file on sparc and sparc64 as well.
>>
>> I haven't actually done any runtime tests yet, I replaced the configuration 
>> files
>> from ppc64el for grub-ieee1275 and adapted them for sparc64. debian-installer
>> builds fine with those changes, but as I said, I haven't tested anything yet.
>>
>> I am very welcome for any pointers though for what else is needed to use GRUB
>> for CD boot on sparc64.
> 
> `grub-mkimage` has a (target) format named "sparc64-ieee1275-cdcore".
> But I'm unsure if this is of any use for us, or needed at all, because
> if GRUB can load kernel and initramfs from disc, it should also be able
> to load its modules from disc, so a small GRUB image and separate
> modules (like for on-disk or diskless installations) could also work.
> 
> OTOH: if a "sparc64-ieee1275-cdcore" image and a corresponding grub.cfg
> works for disc booting, we could just exchange the SILO image and config
> for these.

Is it possible to see the source for sparc64-ieee1275-cdcore anywhere? A quick 
search
doesn't return anything obvious. And from memory grub is working when installed 
onto
the disk? If so, where is the source of the disk image for comparison?


ATB,

Mark.

Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470)

[-]

Am Mittwoch, den 24.04.2019, 17:05 +0200 schrieb Michel Dänzer:
> On 2019-04-24 4:25 p.m., - wrote:
> > This seems to be a serious bug, because now GNOME Shell also has
> > crashed when disconnecting the thunderbolt device.
> 
> Does it still happen with xwayland 2:1.20.4-1 from sid? If yes:
> 
> 
> > I also added a journalctl log.
> > 
> > [...]
> > 
> > Apr 24 16:08:24 debian-t470 org.gnome.Shell.desktop[1387]: (EE) 2:
> > /usr/bin/Xwayland (present_extension_init+0xcd2) [0x560ec4ee0542]
> > Apr 24 16:08:24 debian-t470 org.gnome.Shell.desktop[1387]: (EE) 3:
> > /usr/bin/Xwayland (present_extension_init+0xf14) [0x560ec4ee0b04]
> > Apr 24 16:08:24 debian-t470 org.gnome.Shell.desktop[1387]: (EE) 4:
> > /usr/bin/Xwayland (glamor_egl_fd_from_pixmap+0x637)
> > [0x560ec4e22a67]
> FWIW, these symbols are probably bogus, as glamor_egl_fd_from_pixmap
> in
> Xwayland is a stub which just returns -1, no way it ends up calling
> present_* functions.
> 
> 

Interestingly, I was not able to break it anymore, even with the
version in testing. I have tried it again at home and at work (both
sides same dock, but each site different monitor setup).
After a reboot and then multiple times connecting and disconneting the
dock, I was not able to reproduce it and crash GNOME Shell. I also
opened the programms I used while it crashed, even with the same
websites open. Also going to suspend with the dock connected,
disconnect the dock and wake the laptop up (or vice versa, disconnect
-> suspend -> connect the dock -> resume laptop) do not break GNOME
Shell at the moment.
Maybe it was a rare combination of circumstances which does not occur
often. I will try to reproduce it and continue using suspend and the
docks and hopefully I can trigger it again and sent another logfile to
narrow it down.

In the logs where GNOME Shell crashed, around the crash there are a lot
of chromium errors:

Apr 24 07:13:40 debian-t470 chromium.desktop[1357]:
[4373:4373:0424/071340.656718:ERROR:zygote_communication_linux.cc(276)]
Failed to send GetTerminationStatus message to zygote

and

Apr 24 16:08:22 debian-t470 chromium.desktop[1387]:
[2268:2268:0424/160822.454621:ERROR:gl_surface_presentation_helper.cc(2
37)] GetVSyncParametersIfAvailable() failed!

Might this trigger crashing (in combination with the thunderbolt
authentification process (boltd) and adding new displays etc.) by
interupting or keeping a ressource busy so that they freeze/crash?
(Just not sure, if Chromium still uses xWayland or nowadays Wayland
natively.)

best regards

Christian Höffer

Bug#926218: range-v3: FTBFS with gcc 8.3

[Alexis Murzeau]

On Wed, 3 Apr 2019 10:18:35 +0200 Santiago Vila  wrote:
> On Tue, Apr 02, 2019 at 10:57:39PM +0300, Коля Гурьев wrote:
> > Control: forwarded -1 https://github.com/ericniebler/range-v3/issues/856
>
> Hi. I believe this one (failure with GCC 9) could be a bit closer:
>
> https://github.com/ericniebler/range-v3/issues/1033
>
> Thanks.
>

Hi,

This issue doesn't seem related to that github issue.

I've investigated the cause of the warning inside gcc.
(I'm not accustomed to gcc internals so some of my sentences might be
imprecise :))

While debugging cc1plus, I found that the warning is caused for this
GIMPLE instruction:
```
[../include/range/v3/utility/counted_iterator.hpp:291:18] # VUSE <.MEM_335>
  _293 = MEM[(long int *)[../test/container_conversion.cpp:48:4]
 + 8B];
```
(note that D.184479 number changes every-time I run gcc)

The GIMPLE dump can be generated using `-fdump-tree-uninit-vops-lineno`.

The dump is somewhat complicated to read but here is my analysis.

The warning is triggered by the first statement in
container_conversion.hpp [0].
`view::ints | view::take(10)` has the type take_really.

It is converted to a std::vector via `operator std::vector` which
is implemented as a template inside view_interface [1].
That operator call to_ which end up calling to_container_fn::impl [2]
which will itself call std::vector::assign [3] and
std::vector::_M_assign_aux [4].

When calling std::vector::assign, to_container_fn::impl create begin and
end iterators with range_common_iterator_t [5]. This will create
`common_iterator`s which is really a variant with the real underlying
iterator (of type counted_iterator) and the sentinel type.

Then, when gcc search for uninitialized cases, it find a case when:
- the __last iterator is the sentinel
- there is a use of the __last iterator as a counted_iterator with an
access to its cnt_ field

In that case, gcc think the underlying storage of the variant is not
initialized as the sentinel is an empty structure which is true. But
then the of the cnt_ field is not used later.

See here for the GIMPLE dump: [6].
The codepath leading to the uninitialized use of D.184248 imply that
iftmp.47_15 != 0.
But the codepath leading to a use of the uninitialized value D.184248
require iftmp.47_15 == 0.
Indeed, MEM[(long int *) + 8B] is used via _293 and _279 in if
conditions in blocks bb 13 and bb 18 which are executed only if
iftmp.47_15 == 0.
If that's the case, bb 3 would be executed at the start of the function
and bb 3 initialize MEM[(struct Head *)] (so including
initialization of MEM[(long int *) + 8B]).

Thus, this maybe-uninitialized warning is a false positive. By search
for bugs in gcc about false positive, I found that this is not a rare case.

I suggest to make this warning not trigger an error for the build.
We could use `-Wno-error=maybe-uninitialized` but cc1plus does not
recognize some of the command line arguments and as soon as it print a
diagnostic message (the maybe-uninitialized warning), it also print
errors about unrecognized arguments.
This make the build still fail.

Maybe there is a -Wno-error=XXX to make unrecognized command line
arguments not an error too.

Or we can use `-Wno-maybe-uninitialized` which works but is maybe too
much radical.


[0]
https://sources.debian.org/src/range-v3/0.4.0-1/test/container_conversion.cpp/#L39

[1]
https://sources.debian.org/src/range-v3/0.4.0-1/include/range/v3/view_interface.hpp/#L370
[2]
https://sources.debian.org/src/range-v3/0.4.0-1/include/range/v3/to_container.hpp/#L147
[3]
https://sources.debian.org/src/range-v3/0.4.0-1/include/range/v3/to_container.hpp/#L84
[4]
https://github.com/gcc-mirror/gcc/blob/gcc-8_3_0-release/libstdc++-v3/include/bits/vector.tcc#L271

[5]
https://sources.debian.org/src/range-v3/0.4.0-1/include/range/v3/to_container.hpp/#L83

[6]
https://gist.github.com/amurzeau/ca58f3ebe890371a295d8f2537fa09cc#file-container_conversion-cpp-197t-uninit1-cpp-L230

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

[Mark Cave-Ayland]

On 24/04/2019 18:26, John Paul Adrian Glaubitz wrote:

> Source: grub2
> Version: 2.02+dfsg1-17
> Severity: normal
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> 
> Hello!
> 
> I have started working on switching the bootloader for debian-installer from
> silo to grub-ieee1275 on sparc and sparc64.
> 
> For that, I have looked at the corresponding code in debian-installer for
> ppc64el and noticed that the configuration file build/config/ppc64el.cfg
> requires a "bootinfo.txt" configuration file which is part of the
> grub-ieee1275-bin package.
> 
> Thus, in order to switch to grub-ieee1275 on sparc and sparc64, we need
> to add the bootinfo.txt there as well. Could you install the bootinfo.txt
> file for sparc and sparc64 as well?
> 
> Plus, it might be a good idea to adjust the GRUB version number as well
> as the name of the boot script to be a generic name like debian-installer.elf
> and not powerpc.elf.
> 
> Currently, the header of bootinfo.txt looks like this:
> 
> 
> grub 2.02~beta3
> grub 2.02~beta3
> boot :\boot\grub\powerpc.elf
> 
> 
> Thanks,
> Adrian

Hi Adrian,

For reference the CHRP bootinfo.txt isn't a configuration file, but is actually
parsed by CHRP-compliant open firmwares directly - SPARC firmwares, including
OpenBIOS don't support them. Can you explain why grub on SPARC is trying to 
access
this file?



ATB,

Mark.

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Samuel Thibault]

Michael Biebl, le mer. 24 avril 2019 22:21:03 +0200, a ecrit:
> Am 24.04.19 um 21:58 schrieb Samuel Thibault:
> > Michael Biebl, le mer. 24 avril 2019 21:40:04 +0200, a ecrit:
> >> Am 24.04.19 um 21:24 schrieb Samuel Thibault:
> >>> consolekit has been removed, please drop the dependency from the
> >>> policykit-1 package, as the attached patch does.
> >>
> >> I guess we should make policykit-1 linux-any, given that we don't have a
> >> working backend on !linux.
> > 
> > That'd notably mean having to make the libpolkit-gobject-1-dev
> > dependency [linux-any] on apparently 69 packages.
> 
> How so? It would just mean those packages become unbuildable on !linux

Yes, while a lot of them would just build and work fine on !linux
without any change anywhere but keep policykit-1 build find on
!linux.

For instance brltty's dependency on policykit is just a convenience, it
can fully work without it. That's probably the same for a lot of these
69 packages. I don't personally plan to take the time to have a look at
these 69 packages. I don't think anybody will happily plan to.

Samuel

Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

[Frank Scheiner]

On 4/24/19 22:07, John Paul Adrian Glaubitz wrote:
> On 4/24/19 9:46 PM, Mark Cave-Ayland wrote:
>> For reference the CHRP bootinfo.txt isn't a configuration file, but is 
>> actually
>> parsed by CHRP-compliant open firmwares directly - SPARC firmwares, including
>> OpenBIOS don't support them. Can you explain why grub on SPARC is trying to 
>> access
>> this file?
>
> Good point, I didn't notice that there is a CHRP header and assumed that we 
> need
> this file on sparc and sparc64 as well.
>
> I haven't actually done any runtime tests yet, I replaced the configuration 
> files
> from ppc64el for grub-ieee1275 and adapted them for sparc64. debian-installer
> builds fine with those changes, but as I said, I haven't tested anything yet.
>
> I am very welcome for any pointers though for what else is needed to use GRUB
> for CD boot on sparc64.

`grub-mkimage` has a (target) format named "sparc64-ieee1275-cdcore".
But I'm unsure if this is of any use for us, or needed at all, because
if GRUB can load kernel and initramfs from disc, it should also be able
to load its modules from disc, so a small GRUB image and separate
modules (like for on-disk or diskless installations) could also work.

OTOH: if a "sparc64-ieee1275-cdcore" image and a corresponding grub.cfg
works for disc booting, we could just exchange the SILO image and config
for these.

Cheers,
Frank

Bug#927903: wavpack: CVE-2019-11498: Uninitialized Read in WavpackSetConfiguration64()

[Salvatore Bonaccorso]

Source: wavpack
Version: 5.1.0-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/dbry/WavPack/issues/67

Hi,

The following vulnerability was published for wavpack.

CVE-2019-11498[0]:
| WavpackSetConfiguration64 in pack_utils.c in libwavpack.a in WavPack
| through 5.1.0 has a "Conditional jump or move depends on uninitialised
| value" condition, which might allow attackers to cause a denial of
| service (application crash) via a DFF file that lacks valid sample-
| rate data.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11498
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11498
[1] https://github.com/dbry/WavPack/issues/67
[2] 
https://github.com/dbry/WavPack/commit/bc6cba3f552c44565f7f1e66dc1580189addb2b4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Michael Biebl]

Am 24.04.19 um 21:58 schrieb Samuel Thibault:
> Michael Biebl, le mer. 24 avril 2019 21:40:04 +0200, a ecrit:
>> Am 24.04.19 um 21:24 schrieb Samuel Thibault:
>>> consolekit has been removed, please drop the dependency from the
>>> policykit-1 package, as the attached patch does.
>>
>> I guess we should make policykit-1 linux-any, given that we don't have a
>> working backend on !linux.
> 
> That'd notably mean having to make the libpolkit-gobject-1-dev
> dependency [linux-any] on apparently 69 packages.

How so? It would just mean those packages become unbuildable on !linux



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#927461: [Pkg-openssl-devel] Bug#927461: release-notes: Document how to handle openssls new defaults

[Paul Gevers]

Hi Sebastian,

On 24-04-2019 22:00, Sebastian Andrzej Siewior wrote:
> On 2019-04-21 16:52:30 [+0200], Paul Gevers wrote:

[...]

> The system default is valid for package that links against libssl1.1.
> Some packages (like wpa_supplicant) override the limit so they may use
> TLSv1 even if it is disabled.
> Is the text above more or less what you asked for?

It's a bit long, and in the current state it is a bit out of context,
but I think we'll be able to manage that, thanks.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#927902: unblock: blender/2.79.b+dfsg0-7

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package blender

At the end of March, on Blender Bug Tracker a serious issue was reported
where all distributions based on Debian package 2.79.b+dfsg0-6 were
affected by a catastrophic problem deleting .psd file contents (zero-ing
all files with that extension) on simple file opening.

A month later, due to the issue importance, the concern was raised to
Debian BTS, where upstream developers opened [1].

This is a real problem (tested myself directly) and -7 revision of the
blender package aims to fix the situation.

Ubuntu SRU updates[2] for 18.{04,10} and 19.{04,10} are already
requested, thanks to Gianfranco taking care of them.

unblock blender/2.79.b+dfsg0-7


[1] https://bugs.debian.org/927809
[2] https://bugs.launchpad.net/ubuntu/+source/blender/+bug/1826180


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

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

diff -Nru blender-2.79.b+dfsg0/debian/changelog blender-2.79.b+dfsg0/debian/changelog
--- blender-2.79.b+dfsg0/debian/changelog	2019-01-01 22:04:18.0 +0100
+++ blender-2.79.b+dfsg0/debian/changelog	2019-04-23 21:43:18.0 +0200
@@ -1,3 +1,10 @@
+blender (2.79.b+dfsg0-7) unstable; urgency=medium
+
+  * debian/patches/0007-fix_OpenJPEG2_build.patch:
+fix disruptive change (Closes: #927809)
+
+ -- Matteo F. Vescovi   Tue, 23 Apr 2019 21:43:18 +0200
+
 blender (2.79.b+dfsg0-6) unstable; urgency=medium
 
   * debian/patches/: patchset updated
diff -Nru blender-2.79.b+dfsg0/debian/patches/0007-fix_OpenJPEG2_build.patch blender-2.79.b+dfsg0/debian/patches/0007-fix_OpenJPEG2_build.patch
--- blender-2.79.b+dfsg0/debian/patches/0007-fix_OpenJPEG2_build.patch	2018-12-28 11:27:16.0 +0100
+++ blender-2.79.b+dfsg0/debian/patches/0007-fix_OpenJPEG2_build.patch	2019-04-23 20:44:26.0 +0200
@@ -41683,7 +41683,7 @@
 +{
 +	FILE *p_file = NULL;
 +	unsigned char mem[JP2_FILEHEADER_SIZE];
-+	opj_stream_t *stream = opj_stream_create_from_file(filepath, OPJ_J2K_STREAM_CHUNK_SIZE, false, _file);
++	opj_stream_t *stream = opj_stream_create_from_file(filepath, OPJ_J2K_STREAM_CHUNK_SIZE, true, _file);
 +	if (stream) {
 +		return NULL;
 +	}


signature.asc
Description: PGP signature

Bug#927901: unblock: lucene-solr/3.6.2+dfsg-19

[Markus Koschany]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lucene-solr

I made a mistake when I installed solr-permissions.conf into the wrong
/etc/systemd/system/ directory. This makes solr unusable because
tomcat can't write to /var/lib/solr. A user spotted the error and reported
it here:

https://salsa.debian.org/java-team/lucene-solr/commit/ae53f09f37b18aa836640b256137a3a9e26e186f

The only change is installing this file to
/etc/systemd/system/tomcat9.service.d now which makes it work again.

Regards,

Markus


unblock lucene-solr/3.6.2+dfsg-19

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru lucene-solr-3.6.2+dfsg/debian/changelog 
lucene-solr-3.6.2+dfsg/debian/changelog
--- lucene-solr-3.6.2+dfsg/debian/changelog 2019-03-02 23:02:16.0 
+0100
+++ lucene-solr-3.6.2+dfsg/debian/changelog 2019-04-19 00:39:36.0 
+0200
@@ -1,3 +1,10 @@
+lucene-solr (3.6.2+dfsg-19) unstable; urgency=medium
+
+  * Team upload.
+  * Install solr-permissions.conf into the correct directory.
+
+ -- Markus Koschany   Fri, 19 Apr 2019 00:39:36 +0200
+
 lucene-solr (3.6.2+dfsg-18) unstable; urgency=medium
 
   * Team upload.
diff -Nru lucene-solr-3.6.2+dfsg/debian/solr-tomcat.install 
lucene-solr-3.6.2+dfsg/debian/solr-tomcat.install
--- lucene-solr-3.6.2+dfsg/debian/solr-tomcat.install   2019-03-02 
23:02:16.0 +0100
+++ lucene-solr-3.6.2+dfsg/debian/solr-tomcat.install   2019-04-19 
00:39:36.0 +0200
@@ -1,3 +1,3 @@
 debian/solr-tomcat.xml /etc/solr/
 debian/tomcat.policy /etc/solr/
-debian/solr-permissions.conf /etc/systemd/system/tomcat9.d/
+debian/solr-permissions.conf /etc/systemd/system/tomcat9.service.d/

Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

[John Paul Adrian Glaubitz]

On 4/24/19 9:46 PM, Mark Cave-Ayland wrote:
> For reference the CHRP bootinfo.txt isn't a configuration file, but is 
> actually
> parsed by CHRP-compliant open firmwares directly - SPARC firmwares, including
> OpenBIOS don't support them. Can you explain why grub on SPARC is trying to 
> access
> this file?

Good point, I didn't notice that there is a CHRP header and assumed that we need
this file on sparc and sparc64 as well.

I haven't actually done any runtime tests yet, I replaced the configuration 
files
from ppc64el for grub-ieee1275 and adapted them for sparc64. debian-installer
builds fine with those changes, but as I said, I haven't tested anything yet.

I am very welcome for any pointers though for what else is needed to use GRUB
for CD boot on sparc64.

Adrian

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

Bug#926043: CVE-2019-0816

[Salvatore Bonaccorso]

Hi Thomas,

On Tue, Apr 02, 2019 at 10:29:33PM +0200, Moritz Mühlenhoff wrote:
> severity 926043 important
> thanks
> 
> On Tue, Apr 02, 2019 at 01:56:35PM +0200, Thomas Goirand wrote:
> > On 4/2/19 12:46 PM, Moritz Muehlenhoff wrote:
> > > On Tue, Apr 02, 2019 at 12:33:10PM +0200, Thomas Goirand wrote:
> > >> On 4/1/19 11:44 PM, Moritz Mühlenhoff wrote:
> > >>> Instead of arguing over bug severities, can't we rather fix the bug?
> > >>
> > >> Sure.
> > >>
> > >>> Ubuntu fixed this already and their versions seems fairly close.
> > >>
> > >> That's the thing. I went into the launchpad bug report, and it's full of
> > >> small, incremental commits, from which it is very hard to figure out
> > >> which one is really fixing the issue. Also, the Ubuntu package is just
> > >> getting a snapshot from upstream, it's not integrating any patch. If
> > >> someone can point at the correct patch, I'll do the update work.
> > > 
> > > Actually, given Bastian's reply, we can just close the bug, or am I 
> > > missing
> > > something?
> > > 
> > > Cheers,
> > > Moritz
> > 
> > Well, not 100%. "we" don't support cloud-init provisioning yet. Though
> > someone running Debian, building their own image, cloud be affected by
> > the bug. Which is why I'd suggest downgrading the bug to important, as
> > it would only affect, only potentially, a very small subset of users.
> 
> OK, I see! Downgrading makes total sense, then. Doing that now.
>  
> > I still believe we should try to get this fixed in time for Buster, and
> > backport it to Stretch.
> 
> Ack.

Did you had a chance to look into this specifically for unstable and
possibly buster (still agreeing on the reasoning, but was looking
trough some pending mails and spotted the intend above).

Regards,
Salvatore

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Samuel Thibault]

Michael Biebl, le mer. 24 avril 2019 21:40:04 +0200, a ecrit:
> Am 24.04.19 um 21:24 schrieb Samuel Thibault:
> > consolekit has been removed, please drop the dependency from the
> > policykit-1 package, as the attached patch does.
> 
> I guess we should make policykit-1 linux-any, given that we don't have a
> working backend on !linux.

That'd notably mean having to make the libpolkit-gobject-1-dev
dependency [linux-any] on apparently 69 packages.

I'd be much less work for everybody to just have a policykit without a
backend than no policykit.

Samuel

Bug#927461: [Pkg-openssl-devel] Bug#927461: release-notes: Document how to handle openssls new defaults

[Sebastian Andrzej Siewior]

On 2019-04-21 16:52:30 [+0200], Paul Gevers wrote:
> Hi Kurt, Christoph, Sebastian, others,
Hi Paul,

> Could somebody of the openssl team propose a text that can be added to
> the release-notes about the new defaults? I am not asking for package
> specific text (although that is welcome of course), but rather a generic
> description of the change, what it means, how it can be circumvented and
> what the drawbacks of that are.

We have this [0]:
|   Following various security recommendations, the default minimum TLS version
|   has been changed from TLSv1 to TLSv1.2. Mozilla, Microsoft, Google and Apple
|   plan to do same around March 2020.
|
|   The default security level for TLS connections has also be increased from
|   level 1 to level 2. This moves from the 80 bit security level to the 112 bit
|   security level and will require 2048 bit or larger RSA and DHE keys, 224 bit
|   or larger ECC keys, and SHA-2.
|
|   The system wide settings can be changed in /etc/ssl/openssl.cnf. 
Applications
|   might also have a way to override the defaults.
|
|   In the default /etc/ssl/openssl.cnf there is a MinProtocol and CipherString
|   line. The CipherString can also sets the security level. Information about 
the
|   security levels can be found in the SSL_CTX_set_security_level(3ssl) 
manpage.
|   The list of valid strings for the minimum protocol version can be found in
|   SSL_CONF_cmd(3ssl). Other information can be found in ciphers(1ssl) and
|   config(5ssl).
|
|   Changing back the defaults in /etc/ssl/openssl.cnf to previous system wide
|   defaults can be done using:
|   MinProtocol = None
|   CipherString = DEFAULT
|
|   It's recommended that you contact the remote site in case the defaults cause
|   problems.

The system default is valid for package that links against libssl1.1.
Some packages (like wpa_supplicant) override the limit so they may use
TLSv1 even if it is disabled.
Is the text above more or less what you asked for?

[0] /usr/share/doc/libssl1.1/NEWS.Debian.gz

> Paul

Sebastian

Bug#914068: freelan FTBFS with boost 1.67

[Dimitri John Ledkov]

On Wed, 24 Apr 2019 14:42:24 +0100 Dimitri John Ledkov
 wrote:
>
> Possibly solved by
> https://github.com/freelan-developers/freelan/commit/573a2d38feafec1256ab97b712e963278e4b3fb0.patch
> ?
>

Actually a bit more than that:

573a2d38feafec1256ab97b712e963278e4b3fb0
89627112f66979b5918f7c4d8b7dd63d0e2e83cc
0dd37d7a9f175f390c58cf7d57314a3a41b1d541
eb6722529666523139663866200e23299bc619f6
533759501c361c13f256f207ddbe00bca693518b
f57b03d0f6503dffcdf8dbab3229876dfdad58cb
diff -Nru freelan-2.0/debian/control freelan-2.0/debian/control
--- freelan-2.0/debian/control	2018-09-19 11:43:51.0 +
+++ freelan-2.0/debian/control	2019-04-24 13:43:08.0 +
@@ -5,10 +5,10 @@
 Build-Depends:
  debhelper (>= 11),
- libboost-filesystem1.65-dev,
- libboost-iostreams1.65-dev,
- libboost-program-options1.65-dev,
- libboost-system1.65-dev,
- libboost-thread1.65-dev,
+ libboost-filesystem-dev,
+ libboost-iostreams-dev,
+ libboost-program-options-dev,
+ libboost-system-dev,
+ libboost-thread-dev,
  libcurl4-openssl-dev,
  libssl-dev,
  scons,
diff -Nru freelan-2.0/debian/patches/0dd37d7a9f175f390c58cf7d57314a3a41b1d541.patch freelan-2.0/debian/patches/0dd37d7a9f175f390c58cf7d57314a3a41b1d541.patch
--- freelan-2.0/debian/patches/0dd37d7a9f175f390c58cf7d57314a3a41b1d541.patch	1970-01-01 00:00:00.0 +
+++ freelan-2.0/debian/patches/0dd37d7a9f175f390c58cf7d57314a3a41b1d541.patch	2019-04-24 13:43:19.0 +
@@ -0,0 +1,44 @@
+From 0dd37d7a9f175f390c58cf7d57314a3a41b1d541 Mon Sep 17 00:00:00 2001
+From: Sebastien Vincent 
+Date: Fri, 4 May 2018 14:26:36 +0200
+Subject: [PATCH] Fixes compilation issues with Boost 1.67 on Windows and link
+ to this library version.
+
+---
+ apps/freelan/freelan.vcxproj| 16 
+ libs/asiotap/libasiotap.vcxproj |  8 
+ libs/cryptoplus/libcryptoplus.vcxproj   |  8 
+ libs/executeplus/libexecuteplus.vcxproj |  8 
+ libs/freelan/libfreelan.vcxproj |  8 
+ libs/freelan/src/core.cpp   |  6 --
+ libs/fscp/libfscp.vcxproj   |  8 
+ libs/iconvplus/libiconvplus.vcxproj |  8 
+ libs/kfather/libkfather.vcxproj |  8 
+ libs/miniupnpcplus/libminiupnpcplus.vcxproj |  8 
+ libs/mongooseplus/libmongooseplus.vcxproj   |  8 
+ 11 files changed, 48 insertions(+), 46 deletions(-)
+
+Index: freelan-2.0/libs/freelan/src/core.cpp
+===
+--- freelan-2.0.orig/libs/freelan/src/core.cpp
 freelan-2.0/libs/freelan/src/core.cpp
+@@ -1766,7 +1766,8 @@ namespace freelan
+ 			{
+ m_logger(fscp::log_level::information) << "IPv4 address: " << m_configuration.tap_adapter.ipv4_address_prefix_length;
+ 
+-tap_config.ipv4.network_address = { m_configuration.tap_adapter.ipv4_address_prefix_length.address(), m_configuration.tap_adapter.ipv4_address_prefix_length.prefix_length() };
++asiotap::ipv4_network_address address = { m_configuration.tap_adapter.ipv4_address_prefix_length.address(), m_configuration.tap_adapter.ipv4_address_prefix_length.prefix_length() };
++tap_config.ipv4.network_address = address;
+ 			}
+ 			else
+ 			{
+@@ -1778,7 +1779,8 @@ namespace freelan
+ 			{
+ m_logger(fscp::log_level::information) << "IPv6 address: " << m_configuration.tap_adapter.ipv6_address_prefix_length;
+ 
+-tap_config.ipv6.network_address = { m_configuration.tap_adapter.ipv6_address_prefix_length.address(), m_configuration.tap_adapter.ipv6_address_prefix_length.prefix_length() };
++asiotap::ipv6_network_address address = { m_configuration.tap_adapter.ipv6_address_prefix_length.address(), m_configuration.tap_adapter.ipv6_address_prefix_length.prefix_length() };
++tap_config.ipv6.network_address = address;
+ 			}
+ 			else
+ 			{
diff -Nru freelan-2.0/debian/patches/533759501c361c13f256f207ddbe00bca693518b.patch freelan-2.0/debian/patches/533759501c361c13f256f207ddbe00bca693518b.patch
--- freelan-2.0/debian/patches/533759501c361c13f256f207ddbe00bca693518b.patch	1970-01-01 00:00:00.0 +
+++ freelan-2.0/debian/patches/533759501c361c13f256f207ddbe00bca693518b.patch	2019-04-24 13:43:19.0 +
@@ -0,0 +1,25 @@
+From 533759501c361c13f256f207ddbe00bca693518b Mon Sep 17 00:00:00 2001
+From: Sebastien Vincent 
+Date: Sun, 15 Apr 2018 12:51:01 +0200
+Subject: [PATCH] Fixes other compilation errors with recent Boost version.
+
+Boost socket native() method was deprecated for a long time and is
+replaced by native_handle() ones. Other part of the code is correctly
+using the native_handle() so it just a miss for this one."
+---
+ libs/freelan/src/core.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libs/freelan/src/core.cpp b/libs/freelan/src/core.cpp
+index 76463cdf..6148bf3e 100644
+--- a/libs/freelan/src/core.cpp
 b/libs/freelan/src/core.cpp
+@@ -683,7 +683,7 @@ namespace freelan
+ #ifdef LINUX

Bug#927900: qemu-system-x86_64 crashes when using GStreamer

[Francois Gouget]

Package: qemu-system-x86
Version: 1:3.1+dfsg-7
Severity: normal

Dear Maintainer,

To reproduce:
* Create a VM using Spice.
* Tell QEmu to stream all videos by using virsh to add the streaming
  mode setting like so:

  
  

* Start the VM and play a video in the guest. For instance:
  mplayer big_buck_bunny_1080p_h264.mov
  
As soon as QEmu switches the video to streaming mode it will crash. In
the log the last lines are:

(qemu-system-x86_64:6140): GStreamer-WARNING **: 16:13:21.872: External plugin 
loader failed. This most likely means that the plugin loader helper binary was 
not found or could not be run. You might need to set the GST_PLUGIN_SCANNER 
environment variable if your setup is unusual. This should normally not be 
required though.
2019-04-24 14:13:22.569+: shutting down, reason=crashed


Notes:
* This happens with and without apparmor installed so this is not an
  issue caused by apparmor preventing GStreamer from finding the files
  it needs.
* I can use video streaming just fine in Xspice so the bug is most
  likely not in the libspice-server libraries.


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

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

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-1
ii  libaio1   0.3.112-3
ii  libasound21.1.8-1
ii  libbluetooth3 5.50-1
ii  libbrlapi0.6  5.6-10
ii  libc6 2.28-8
ii  libcacard01:2.6.1-1
ii  libcapstone3  4.0.1+really+3.0.5-1
ii  libepoxy0 1.5.3-0.1
ii  libfdt1   1.4.7-3
ii  libgbm1   18.3.4-2
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-1
ii  libgnutls30   3.6.6-2
ii  libibverbs1   22.1-1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libncursesw6  6.1+20181013-2
ii  libnettle63.4.1-1
ii  libnuma1  2.0.12-1
ii  libpixman-1-0 0.36.0-1
ii  libpng16-16   1.6.36-5
ii  librdmacm122.1-1
ii  libsasl2-22.1.27+dfsg-1
ii  libseccomp2   2.3.3-4
ii  libspice-server1  0.14.0-1.3
ii  libtinfo6 6.1+20181013-2
ii  libusb-1.0-0  2:1.0.22-2
ii  libusbredirparser10.8.0-1
ii  libvdeplug2   2.3.2+r586-2.2
ii  libvirglrenderer0 0.7.0-2
ii  libxendevicemodel14.11.1+26-g87f51bf366-3
ii  libxenevtchn1 4.11.1+26-g87f51bf366-3
ii  libxenforeignmemory1  4.11.1+26-g87f51bf366-3
ii  libxengnttab1 4.11.1+26-g87f51bf366-3
ii  libxenmisc4.114.11.1+26-g87f51bf366-3
ii  libxenstore3.04.11.1+26-g87f51bf366-3
ii  libxentoolcore1   4.11.1+26-g87f51bf366-3
ii  qemu-system-common1:3.1+dfsg-7
ii  qemu-system-data  1:3.1+dfsg-7
ii  seabios   1.12.0-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages qemu-system-x86 recommends:
ii  ovmf 0~20181115.85588389-3
ii  qemu-system-gui  1:3.1+dfsg-7
ii  qemu-utils   1:3.1+dfsg-7

Versions of packages qemu-system-x86 suggests:
pn  qemu-block-extra  
ii  samba 2:4.9.5+dfsg-3
ii  sgabios   0.0~svn8-4
ii  vde2  2.3.2+r586-2.2

-- no debconf information

Bug#927899: ITP: cage -- A Wayland kiosk

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: cage
  Version : 0.1
  Upstream Author : Jente Hidskes
* URL : https://www.hjdskes.nl/projects/cage/
* License : MIT
  Programming Lang: C
  Description : A Wayland kiosk

Cage is a kiosk compositor for Wayland. A kiosk is a window manager (in
the X11 world) or compositor (in the Wayland world) that is designed for
a user experience wherein user interaction and activities outside the
scope of the running application are prevented. That is, a kiosk
compositor displays a single maximized application at a time and
prevents the user from interacting with anything but this application.

Bug#927896: [Pkg-utopia-maintainers] Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Michael Biebl]

Hi

Am 24.04.19 um 21:24 schrieb Samuel Thibault:
> Package: policykit-1
> Version: 0.105-25
> Severity: important
> 
> Hello,
> 
> consolekit has been removed, please drop the dependency from the
> policykit-1 package, as the attached patch does.

I guess we should make policykit-1 linux-any, given that we don't have a
working backend on !linux.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#926326: elpa-elpy: configuration issues

[Faheem Mitha]

Hi Nicholas,

On Sun, 14 Apr 2019, Nicholas D Steeves wrote:


Dear Faheem,

Thank you for filing an excellent bug report that includes all
relevant information.  Reply follows in-line, but please take care to
reply to the appropriate sub-bugs that will be momentarily created:
 https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=elpa-elpy


Thank you for the kind words. I've noted the bug split. I'm not sure 
exactly what you want me to do regarding replying to the bugs, so I've 
CCed the original bug, as well as the three new sub-bugs that you created.


I could have split up my reply across the three different bugs, but that 
would be quite a lot of work, and might be confusing. I suggest followups 
for the relevant points from here on should just go to the relevant bugs.



 elpa-elpy: README.Debian misleads users into enabling nonexistent Python 2 
support
   * Concerning points: #1, #5, #6, #7
 elpa-elpy: Please provide a QuickStart page
   * Concerning point #4
 elpa-elpy: Please enable Python 2 support
   * Concerning points: #1, #5, #6, #7


It would be more accurate to write

README.Debian misleads users into assuming nonexistent Python 2 support

Since it does not say anything to the contrary.

The only really important thing is to make it clear to users that Buster's 
elpy does not support usage with Python 2, as mentioned later.



Bug#926326: elpa-elpy: configuration issues is now
 * Concerning points: #2, #3

I've split the aggregate into discrete bugs, because some of these
issues will not receive an unblock for buster.

On Wed, Apr 03, 2019 at 08:39:35PM +0530, Faheem Mitha wrote:

Package: elpa-elpy
Version: 1.28.0-1
Severity: normal

Dear Maintainer,

I've been struggling with getting elpy to work on Debian stable.



Thank you for letting me know, and sorry it wasn't easy.  Let's fix
this! :-)


For right now, some comments and suggestions about README.Debian.

1) There's a typo in your code:

(setq python-shell-interpreter "python"
  python-shell-interpreter-args "-i")
  elpy-rpc-python-command "python")

It should be:

(setq python-shell-interpreter "python"
  python-shell-interpreter-args "-i"
  elpy-rpc-python-command "python")



Good catch, thanks!


2) You should mention that elpy isn't loaded by default, and indicate
how to load it. Historically, Debian packages autoload modes once
installed, and personally I find that more convenient. But I
understand if you don't load it to preserce compatibility with
upstream EPLA.



Yes, for simple packages this is absolutely the way to go.  I chose to
leave (elpa-enable) up to the user because on my system it doubles
Emacs startup time, because elpa-enable is unconditionally executed.
Also, a user may choose to enable Elpy using an alternative
(conditional) method.


Fine, just document it in the README.Debian. And (preferably) tell users 
what to add to enable it. If they don't want to use it, they don't have 
to. But at least then they won't have to go looking for a method that will 
work.



The elpy manual mentions in
https://elpy.readthedocs.io/en/latest/introduction.html that elpy
should be enabled with

(package-initialize)
(elpy-enable)

Just the second line works for me here. I'm not sure what the first
part does. Some sort of global enable, apparently.



For info about package-initialize, see the Emacs manual §48.2 "Package
Installation".  Also, your init file may have already had the following
automatically added to the top of it:



 ;; Added by Package.el.  This must come before configurations of
 ;; installed packages.  Don't delete this line.  If you don't want it,
 ;; just comment it out by adding a semicolon to the start of the line.
 ;; You may delete these explanatory comments.
 (package-initialize)


Yes, it does indeed have exactly that on top.


3) I suggest mentioning the upstream manual in README.Debian. Namely,
https://elpy.readthedocs.io/en/latest/



Unfortunately this will not provide accurate documentation for users
of Debian buster in the coming months, because that URL will document
a newer version of Elpy, and buster is shipping with 1.28.0.  Also, a
link is useless for users who are offline.



Would you please comment on your experience with "info elpy" or "man
elpy"?  P.S. The sphinx-generated info page is much nicer than the
the man page it generates, and the following is nicer still:

 emacs --eval '(info "elpy")'
 # or M-x info, C-s elpy


It didn't occur to me that either of those exists. Thank you for the 
pointers. I think that's also something that could usefully be mentioned 
in README.Debian. Most Python packages don't have either of those, I 
think. So it will probably not occur to people to look for them.



4) And if I were writing the README.Debian, I'd also mention that C-c
C-c runs the buffer, and that you need C-c C-z to open up a Python
interpreter buffer. This would help people to get going quickly,
instead of flailing 

Bug#924609: Ports of CVE patches from Debian LTS for libsdl1.2

[Salvatore Bonaccorso]

Hi Kari,

On Wed, Apr 24, 2019 at 07:15:44PM +0300, Kari Pahula wrote:
> Hi.
> 
> I've ported the CVE patches from Debian LTS for libsdl1.2 in unstable.

First thanks for working on the issues!

I have not reviewed your patches, but just a remark. Never just
forward-port a patchset from an older suite to newer (although the
version is identical here).

Furthermore as Moritz pointed out, at time of writing the bugreport,
only some of the bugs got patches, but not all were merged upstream,
several of the CVEs got later on upstream patches rather then
previously linked ones from the bugzilla.  We should base the upload
based on the current upstream patches which by now should be complete
(but double check the updated references in the security-tracker).

Regards,
Salvatore

Bug#927789: [pre-upload-approval] unblock: x2gobroker/0.0.4.1-1

[Mike Gabriel]

Control: tags -1 - moreinfo

Hi Niels,

On  Mi 24 Apr 2019 20:21:00 CEST, Niels Thykier wrote:


Control: tags -1 moreinfo confirmed

Mike Gabriel:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package x2gobroker

[...]

light+love,
Mike

unblock x2gobroker/0.0.4.1-1

[...]

Please go ahead with the upload and remove the moreinfo tag when it is
in unstable and ready to be unblocked.

Thanks,
~Niels


Many thanks. Package has arrived in unstable.

Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpSZMLqUWCVk.pgp
Description: Digitale PGP-Signatur

Bug#927898: ITP: rsendmail -- safer sendmail command to send email without passwords, over SSH

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 

* Package name: rsendmail
  Version : 1.0.1
  Upstream Author : Antoine Beaupré 
* URL : https://gitlab.com/anarcat/rsendmail/
* License : AGPLv3
  Programming Lang: Python
  Description : safer sendmail command to send email without passwords, 
over SSH

This command aims at replacing the builtin sendmail command which
gives too much privileges to the caller. For example, Postfix's
sendmail(1) command can list the mail queue (-bp), rehash the alias
database (-bi), start a daemon (-bl, -bd), or flush the queue (-q);
all remnants of the old Sendmail binary, which probably is
turing-complete on its own.

It's a mess. All I want to do is to easily queue up mails on a remote
system without giving any extra privileges to the remote system. In
turns, this makes configuring a satellite system like a laptop or a
workstaiton as simple as adding an SSH key to be added to an
authorized_keys file. That key can then send email, but only send
email: no shell access or server management.

This can of course be accomplished by a regular SMTP client, but that
requires passwords, and passwords are weak.



So I built the above already. I didn't think of packaging it for
Debian until someone said "oh i'm not going to use this because it's
not in Debian", so here we are.

This is what I like to describe as "modern UUCP", more or
less. Instead of relying on SMTP for transport, I rely on SSH, which
brings a bunch of interesting properties. I am not aware of anything
like that currently in the archive.

I would be happy to co-maintain it with the relevant Python team but
maybe it's better if I just maintain my own stuff too. :)

Bug#927897: ITP: golang-github-gcla-gowid -- Compositional widgets for terminal user interfaces, inspired by urwid

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-gcla-gowid
  Version : 1.0.0-1
  Upstream Author : Graham Clark
* URL : https://github.com/gcla/gowid
* License : Expat
  Programming Lang: Go
  Description : Compositional widgets for terminal user interfaces, 
inspired by urwid

 Gowid provides widgets and a framework for making terminal user
 interfaces. It's written in Go and inspired by urwid (http://urwid.org).
 .
 Widgets out-of-the-box include:
  • input components like button,
checkbox and an editable text field with support for passwords
  • layout components for arranging widgets in columns, rows and a grid
  • structured components - a tree, an infinite list and a table
  • pre-canned widgets - a progress bar, a modal dialog, a bar graph and a menu
  • a VT220-compatible terminal widget, heavily cribbed from urwid
 .
 All widgets support interaction with the mouse when the terminal allows.
 .
 Gowid is built on top of the fantastic tcell
 (https://github.com/gdamore/tcell) package.
 
This package in the dependency tree of upcoming "termshark" package (#927799).

Bug#926958: Proposed security upload for FreeRADIUS

[Salvatore Bonaccorso]

Hi Berni,

On Wed, Apr 24, 2019 at 05:42:31PM +0200, Bernhard Schmidt wrote:
> Hi,
> 
> I've gained access to the FreeRADIUS salsa repo and have pushed a new
> debian/stretch branch containing last years security upload and the
> cherry-picked fixes for #926958
> 
> It applies and builds cleanly, I'm currently waiting for a colleague who
> runs our Radius proxies to test it.

Looking closer now again at the issue, if I understand correctly, the
module would not be enabled by default and to exploit the issue one
would actually as well need to have access to the authentication
server.

Unless I miss something in the picture, I would say this could be
fixed via the next point release for stretch, and does not warrant a
DSA on its own.

Do I miss something?

Regards,
Salvatore

Bug#903635: This is RC; breaks unrelated software

[Jonathan Dowland]

severity 903635 critical
thanks

Justification: "makes unrelated software on the system (or the whole system) 
break"

Installing docker.io changed my FORWARD chain policy to DROP, breaking
networking for unrelated virsh-based VMs that I had installed on the machine at
the time. This matches exactly the text for severity: serious.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#927896: policykit-1: Please drop consolekit dependency on !linux

[Samuel Thibault]

Package: policykit-1
Version: 0.105-25
Severity: important

Hello,

consolekit has been removed, please drop the dependency from the
policykit-1 package, as the attached patch does.

Samuel

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

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

Versions of packages policykit-1 depends on:
ii  dbus   1.12.12-1
ii  libc6  2.28-8
ii  libglib2.0-0   2.58.3-1
ii  libpam-systemd 241-3
ii  libpam0g   1.3.1-5
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-backend-1-0  0.105-25
ii  libpolkit-gobject-1-0  0.105-25

policykit-1 recommends no packages.

policykit-1 suggests no packages.

-- no debconf information

-- 
Samuel
 Créer une hiérarchie supplementaire pour remedier à un problème (?) de
 dispersion est d'une logique digne des Shadocks.
 * BT in: Guide du Cabaliste Usenet - La Cabale vote oui (les Shadocks aussi) *
diff -ur policykit-1-0.105/debian/control policykit-1-0.105.new/debian/control
--- policykit-1-0.105/debian/control2019-01-15 16:11:58.0 +
+++ policykit-1-0.105.new/debian/control2019-04-24 18:40:09.0 
+
@@ -31,7 +31,6 @@
 Package: policykit-1
 Architecture: any
 Depends:
- consolekit [!linux-any],
  dbus,
  libpam-systemd [linux-any],
  ${misc:Depends},

Bug#927895: ITP: golang-github-go-test-deep -- Golang deep variable equality test that returns human-readable differences

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-go-test-deep
  Version : 1.0.1-1
  Upstream Author : Daniel Nichter
* URL : https://github.com/go-test/deep
* License : Expat
  Programming Lang: Go
  Description : Golang deep variable equality test that returns 
human-readable differences

 Deep Variable Equality for Humans.
 .
 This package provides a single function: deep.Equal. It's like
 reflect.DeepEqual (http://golang.org/pkg/reflect/#DeepEqual) but
 much friendlier to humans (or any sentient being) for two reason:
  • deep.Equal returns a list of differences
  • deep.Equal does not compare unexported fields (by default)
  
This package in the dependency tree of upcoming "termshark" package (#927799).

Bug#924616: RFT and RFC: Updates for evolution{,-data-server}

[Mike Gabriel]

Hi Jonas,

On  Mi 24 Apr 2019 12:56:18 CEST, Jonas Meurer wrote:


Jonas Meurer:

With evolution-data-server, the situation is slightly more complicated.
I'm still debugging issues with the patches[5] that are supposed to fix
the "[GPG] Mails that are not encrypted look encrypted" issue.

[5] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/93306a29
and https://gitlab.gnome.org/GNOME/evolution-data-server/commit/accb0e24

My question: do you agree that these fixes are within the scope of
CVE-2018-15587? If so, then I will continue working on the issue and
upload both of evolution and evolution-data-server in a batch once I got
the issues sorted out.

Another option would be to upload evolution to jessie-security right now
and decide that evolution-data-server is not affected by CVE-2018-15587,
since it's only prone to "encrypted message spoofing", not to "signature
spoofing". But in my eyes, that would be a sham.


Looking more into the core issue[1] of "[GPG] Mails that are not
encrypted look encrypted", it became clear that a lot of applications
(GnuPG[2], Enigmail[3], Mutt[4]) are affected and it's not tracked as
security issue for any of them.


Is it required to coordinate an according update of those CVEs in  
data/CVE/list with the security team? Sounds like it.



In fact it's tracked for evolution{,-data-server} in the debian security
tracker only because the issue is mentioned in the CVE-2018-15587
bugreport[5].

Besides, I agree with the bug author that "this bug is certainly not in
the same category as a serious security vulnerability, such as a
plaintext leak or a signature spoof"[1].

So I changed my mind and decided to ignore the "encryption spoofing" bug
and only care about "signature spoofing". This means that
evolution-data-server is unaffected and only evolution needs to be fixed.


Your choice of priority sounds good to me.

Mike


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpnNavXgCU4k.pgp
Description: Digitale PGP-Signatur

Bug#927894: ITP: golang-github-guptarohit-asciigraph -- Make lightweight ASCII line graph in CLI apps with no other dependencies

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-guptarohit-asciigraph
  Version : 0.4.1-1
  Upstream Author : Rohit Gupta
* URL : https://github.com/guptarohit/asciigraph
* License : BSD-3-clause
  Programming Lang: Go
  Description : Make lightweight ASCII line graph in CLI apps with no other 
dependencies

 This package is a Golang port of library asciichart
 written by @kroitor (https://github.com/kroitor).
 .
 Console ASCII line charts in pure Golang with no dependencies.
 
This package in the dependency tree of upcoming "termshark" package (#927799).

Bug#914109: xscreensaver-data: looks for image files to display even though it is told not to

[Jamie Zawinski]

> From a user point of view, if I say that you should not look for image
> files to display, you should just not do that.  This is a bug in
> Xscreensaver.  There is no good reason why it should give an error.

With your settings, the only option is to change the failure mode from "print 
an error message as text", to "don't print any text and just display colorbars 
or black instead".

Doesn't seem like much of an improvement to me. So I'm not gonna spend time on 
that.

Bug#927822: libhighlight-perl: provide API to map shebangs and extensions to language

[Andre Simon]

On 24.04.19 19:29, Eric Wong wrote:

David Bremner  wrote:

Is there an appropriate underlying highlight C++ api? libhighlight-perl
is really just a thin wrapper on that.

AFAIK, not yet, but the CLI does it internally.  So this
wishlist item would also include providing the API for C++
users, too (I don't know C++, though).
There are two functions which need to be moved to a core class, like 
Platform or DataDir.

Will address it in the next release.

André

Bug#927893: mesa: please enable lima and panfrost drivers

[Jonas Smedegaard]

Source: mesa
Version: 19.0.2-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream and added two new drivers recently: panfrost and lima.

Please enable those.  Probably only for armhf and arm64, but not sure.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlzAq9MACgkQLHwxRsGg
ASHLFxAAq+V9z+yxd5XyTE984UDTRL55MPZDlKh/866S+K4/Q7gAbC49MVuder4S
+Hd892ePwvyiA1vtYryf8NL75TDzEaQzuBkPNLSfbi95qR1EIMy8ItUY7FK/S3ZO
3kzCy5U3JF4aQ2S+uOzLFX2wN8zudZ9YCZVYuJGd94ixx2VX2E9B8Y+2QGDF1FWi
AiazSCR/Qib2N0V+OlM3SR/r7ceHBIGHC1TusobSWcJxgKqKhf3PeuUAP88YbfBl
FfuWZFJmhDP+dM38nJ+kUmOsCrMr9wwbzH4v5gjikIDnZeFRuFvKLugv/tm15GJm
IsSm8n/uGhTbBRNYlgXzkMvg8SRBKChqDFeipvjuZ25examW+TKQ9NrpDe+iMesf
41DgfFi9l4pF3alAAak/LkTma2RfZNJBB9y28+Vr11R7bMAwncxE13m6S5ykLvrf
7QFXpCwgEzH9mTyZH+I0yI2Y5MKBx7JGUNiqKjbZmkVtOImjE1YiG0RRMZs/0pdS
JdEPG1ayZpNeG2D+/aHUrXlZbKMp/wb54u8mjKub9jmfwGwPVEEefu8g/2LqAhOU
j4z7AP2UYwuWdHwYJaHrfhshM8wySVPJIpf3eTBIq342Bn4O5xsCGGz7UoPzwZK6
dYEXhI0pPhyL+VGKPedCdN+aou3QAyGH4IxJEDxuOdEXkwPiVB0=
=I6KX
-END PGP SIGNATURE-

Bug#927808: gmsh: FTBFS in buster (c++: error: unrecognized command line option '-Wint-to-void-pointer-cast')

[Juhani Numminen]

Control: retitle -1 gmsh: FTBFS in buster 
("/usr/include/occt/Standard_Version.hxx" cannot be read)


Hi,

I believe the relevant error message is actually this:

CMake Error at CMakeLists.txt:1161 (file):
  file STRINGS file "/usr/include/occt/Standard_Version.hxx" cannot be read.

It seems that /usr/include/occt was changed to /usr/include/opencascade.
https://salsa.debian.org/science-team/opencascade/commit/05357f551748a6842bf2788e2bbc604daa0dfc16

Kurt, will you be able to make gmsh 4.1.3+ds1-1 buildable in ‘testing’?

Regards,
Juhani

Bug#927789: [pre-upload-approval] unblock: x2gobroker/0.0.4.1-1

[Niels Thykier]

Control: tags -1 moreinfo confirmed

Mike Gabriel:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package x2gobroker
> 
> [...]
> 
> light+love,
> Mike
> 
> unblock x2gobroker/0.0.4.1-1
> 
> [...]
Please go ahead with the upload and remove the moreinfo tag when it is
in unstable and ready to be unblocked.

Thanks,
~Niels

Bug#927887: Race condition on boot between cups and sssd

[Luc Giguère]

Coule you please rénové me from your email stream.

Le mer. 24 avr. 2019 12:27 PM, Victor Tapia  a
écrit :

> Package: cups
> Version: 2.2.10-6
>
> Problem description:
>
> When cups has set the "SystemGroup" directive to an external group
> provided through sss and cups starts before sssd has finished booting,
> cups will crash because the group does not exist. For instance, with a
> group named lpadmins@tests.local served from Active Directory through
> sssd, if the sssd service hasn't booted before cups:
>
> Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
> Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
> Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers
> available locally.
> Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup
> "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.
> Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read
> "/etc/cups/cups-files.conf" due to errors.
> Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited,
> code=exited, status=1/FAILURE
> Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result
> 'exit-code'.
> Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off
> time over, scheduling restart.
> Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart
> job, restart counter is at 2.
> Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers
> available locally...
> Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers
> available locally.
> Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler.
>
> If sssd is running before cups starts, everything works as expected.
>
> Test Case:
>
>  * Configure an external authentication service (LDAP, AD...) and create
> a group, for instance "lpadmins@tests.local"
>
>  * Set SystemGroup to match that group in /etc/cups/cups-files.conf:
> SystemGroup lpadmins@tests.local
>
>  * Reboot
>
>  * If cups has started before sssd has finished booting, cups will crash:
> Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup
> "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.
>
>  * If cups starts after sssd, it will work fine.
>
> ---
>
> This bug has been fixed upstream in 2.2.12 with this commit:
>
>
> https://github.com/apple/cups/commit/aaebca5660fdd7f7b6f30461f0788d91ef6e2fee
>
>
> Kind regards,
>
> Victor
>
>

Bug#927822: libhighlight-perl: provide API to map shebangs and extensions to language

[Eric Wong]

David Bremner  wrote:
> Eric Wong  writes:
> 
> > It would be nice if the highlight API provided a way to reliably
> > map filename extensions and shebangs to the language I'm
> > highlighting.  I'm currently parsing the filetypes.conf directly
> > and it's a bit fragile:
> >
> >   
> > https://public-inbox.org/meta/36e311060dcf52bb41eed5f6a2cff38bbb2de006/s/?b=lib/PublicInbox/HlMod.pm#n31
> >
> > ikiwiki has similar code to map filename extensions (but not shebangs).
> >
> > I know this is an upstream issue, but the GitLab.com CAPTCHA is
> > an accessibility problem which prevents me from reporting
> > directly to upstream.  Thanks in advance for forwarding.
> 
> Is there an appropriate underlying highlight C++ api? libhighlight-perl
> is really just a thin wrapper on that.

AFAIK, not yet, but the CLI does it internally.  So this
wishlist item would also include providing the API for C++
users, too (I don't know C++, though).

Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

[John Paul Adrian Glaubitz]

Source: grub2
Version: 2.02+dfsg1-17
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

I have started working on switching the bootloader for debian-installer from
silo to grub-ieee1275 on sparc and sparc64.

For that, I have looked at the corresponding code in debian-installer for
ppc64el and noticed that the configuration file build/config/ppc64el.cfg
requires a "bootinfo.txt" configuration file which is part of the
grub-ieee1275-bin package.

Thus, in order to switch to grub-ieee1275 on sparc and sparc64, we need
to add the bootinfo.txt there as well. Could you install the bootinfo.txt
file for sparc and sparc64 as well?

Plus, it might be a good idea to adjust the GRUB version number as well
as the name of the boot script to be a generic name like debian-installer.elf
and not powerpc.elf.

Currently, the header of bootinfo.txt looks like this:


grub 2.02~beta3
grub 2.02~beta3
boot :\boot\grub\powerpc.elf


Thanks,
Adrian

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

Bug#925967: Solved

[leandroembu]

I solved the problem by copying the file /usr/share/doc/xserver-xorg-
video-intel/xorg.conf to the directory /etc/X11/

Some Xorg logs:
LightDM Log: https://paste.debian.net/1079159/
Xorg log before: https://paste.debian.net/1079164/
Xorg Log after: https://paste.debian.net/1079167/

Bug#927891: CastXML 0.2 Update

[Kyle Edwards]

Package: castxml
Version: 0.1+git20180702-3
Severity: wishlist

CastXML upstream here. We recently released version 0.2 of CastXML (
https://github.com/CastXML/CastXML/releases/tag/v0.2.0 ), and I was
wondering if you guys could upgrade the Debian package. Thanks in
advance!

Kyle

Bug#921552: sddm-theme-debian-maui: Maui decorations are missing after recent upgrades

[Vincas Dargis]

On 2019-04-24 00:50, Aurélien COUDERC wrote:

Took a bit of time but you may have seen that the fix did land in buster by 
now. :)


I did noticed this, thanks!

Bug#927890: xorg: X crashed with log message client 1814[0:0] has disconnected

[Faheem Mitha]

Package: xorg
Version: 1:7.7+19
Severity: normal

Dear Maintainer,

My computer was idling, and when I came back to it, when I tried to
log in, I just got a black screen. Clearly X had crashed.

I was not able to get X to respond, and rebooted.

I'm currently on Buster, which is currently still in testing. It's
possible some recent package upgrade caused this instability, but
that's purely speculation. And I have no plausible candidates for such
packages.

This appears to correspond to the following lines in
`journalctl. These entries all appeared around the time of the crash,
and I rebooted shortly afterwards.

Apr 24 18:12:04 orwell acpid[1060]: client 1814[0:0] has disconnected
Apr 24 18:12:24 orwell acpid[1060]: client connected from 1814[0:0]
Apr 24 18:12:24 orwell acpid[1060]: 1 client rule loaded
Apr 24 18:12:43 orwell acpid[1060]: client 1814[0:0] has disconnected

Apr 24 18:13:34 orwell acpid[1060]: client connected from 1814[0:0]
Apr 24 18:13:34 orwell acpid[1060]: 1 client rule loaded
Apr 24 18:13:45 orwell acpid[1060]: client 1814[0:0] has disconnected

Apr 24 18:13:51 orwell acpid[1060]: client connected from 1814[0:0]
Apr 24 18:13:51 orwell acpid[1060]: 1 client rule loaded
Apr 24 18:13:56 orwell acpid[1060]: client 1814[0:0] has disconnected

Apr 24 18:18:12 orwell acpid[1060]: client connected from 1814[0:0]
Apr 24 18:18:12 orwell acpid[1060]: 1 client rule loaded
Apr 24 18:18:18 orwell acpid[1060]: client 1814[0:0] has disconnected
Apr 24 18:18:29 orwell systemd-logind[1075]: System is rebooting.

Also, lines like the following appear in the current xorg.0.log, and
also appear in the information collected by the Debian template,
below. They may be related.

[   112.253] (--) NVIDIA(GPU-0): DFP-0: disconnected
[   112.253] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS
[   112.253] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock

I could not find anything relating to the crash in earlier X logs.

Regards, Faheem Mitha

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jul 31  2013 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Oct 25 23:45 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
sdiversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by 

Bug#926851: firefox-esr: [GFX1-]: Failed to lock new back buffer.

[Thorsten Glaser]

On Thu, 11 Apr 2019, Thorsten Glaser wrote:

> This worked before some upgrade.

It also works on my laptop, which has amd64 natively,
but not in an amd64 chroot on another system (with the
very same amd64 kernel).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#927888: Need to disable the devicetree command in Secure Boot mode

[Steve McIntyre]

On Wed, Apr 24, 2019 at 05:26:00PM +0100, Steve McIntyre wrote:
>Source: grub2
>Version: 2.02+dfsg1-16
>Severity: serious
>Tags: security
>
>In discussion with upstream EFI and arm64 folks, it's become clear
>that in SB mode we should also be disabling the devicetree command in
>Secure Boot mode. I'm testing a patch right now, coming shortly.

We should also blacklist any of our old grub-efi-arm64-signed binaries
signed with our production key - this is a real hole that can totally
undermine SB. I'll work out how to do that for the next shim upload,
due in the next couple of days.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Bug#927889: libgit2: Specify certificate locations

[Dan Nicholson]

Source: libgit2
Version: 0.27.7+dfsg.1-0.1
Severity: important
Tags: patch

When libgit2 is built with mbedTLS, it tries to determine the trusted
certificate location at build time. Unless openssl and ca-certificates are
installed, then it won't find the appropriate path and it will set the CA
chain to NULL when using mbedTLS. This means that using libgit2 with an
https remote immediately fails with the message "The certificate is not
correctly signed by the trusted CA".

Instead of relying on detection, pass in the standard ca-certificates path
via CERT_LOCATION. While here, pass in USE_HTTPS=mbedTLS for the release
build so it doesn't try to use a different TLS implementation. This was
only being done for the static build.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
diff -Nru libgit2-0.27.7+dfsg.1/debian/changelog libgit2-0.27.7+dfsg.1/debian/changelog
--- libgit2-0.27.7+dfsg.1/debian/changelog	2018-12-26 11:29:30.0 -0600
+++ libgit2-0.27.7+dfsg.1/debian/changelog	2019-04-24 10:52:15.0 -0500
@@ -1,3 +1,11 @@
+libgit2 (0.27.7+dfsg.1-0.1endless1) master; urgency=medium
+
+  * Specify mbedTLS for https for both builds and pass in the standard
+certificate location since it otherwise fails to set a certificate
+path if openssl and ca-certificates are not installed at build time.
+
+ -- Dan Nicholson   Wed, 24 Apr 2019 10:52:15 -0500
+
 libgit2 (0.27.7+dfsg.1-0.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru libgit2-0.27.7+dfsg.1/debian/rules libgit2-0.27.7+dfsg.1/debian/rules
--- libgit2-0.27.7+dfsg.1/debian/rules	2018-12-26 11:29:30.0 -0600
+++ libgit2-0.27.7+dfsg.1/debian/rules	2019-04-24 10:47:18.0 -0500
@@ -18,6 +18,8 @@
 	dh_auto_configure --builddirectory=build-debian-release -- \
 		-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \
 		-DUSE_OPENSSL:BOOL=OFF \
+		-DUSE_HTTPS=mbedTLS \
+		-DCERT_LOCATION=/etc/ssl/certs/ca-certificates.crt \
 		-DUSE_CURL_SSL:BOOL=ON \
 		-DUSE_GSSAPI:BOOL=ON \
 		-DTHREADSAFE:BOOL=ON \
@@ -28,6 +30,7 @@
 		-DCMAKE_BUILD_TYPE:STRING=Release \
 		-DTHREADSAFE:BOOL=ON \
 		-DUSE_HTTPS=mbedTLS \
+		-DCERT_LOCATION=/etc/ssl/certs/ca-certificates.crt \
 		-DUSE_CURL_SSL:BOOL=ON \
 		-DUSE_GSSAPI:BOOL=ON \
 		-DBUILD_CLAR:BOOL=OFF \

Bug#927888: Need to disable the devicetree command in Secure Boot mode

[Steve McIntyre]

Source: grub2
Version: 2.02+dfsg1-16
Severity: serious
Tags: security

In discussion with upstream EFI and arm64 folks, it's become clear
that in SB mode we should also be disabling the devicetree command in
Secure Boot mode. I'm testing a patch right now, coming shortly.

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

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