Bug#867348: gmime 3.0 done in upstream master but not in release

[Gianfranco Costamagna]

>https://download.opensuse.org/repositories/home:/vegnuli:/gambas/Debian_8.0/gambas3_3.11.3-1.dsc
>https://download.opensuse.org/repositories/home:/vegnuli:/gambas/Debian_8.0/gambas3_3.11.3-1.debian.tar.gz


I don't think anybody is going to review a diff of  878887 lines of patch.

if you want to provide a minimal debdiff of the debian packaging, I'm really 
happy to sponsor it.
and instead of complaining, please help in maintaining it.
I already did too much work for a package I even never used, my work stops here.

my opinion is that we should probably drop this package from unstable because 
nobody is seriously maintaining it.
sad but there is no people willing to help, and a lot of people complaining 
about "hey there somebody fixed stuff".
This is not really how Debian works.

please help,

G.

Bug#900658: Intel HD graphics display rotation broken with 2:1.20.0-2

[Mathieu]

Package: xserver-xorg-core
Version: 2:1.20.0-3
Followup-For: Bug #900658

Dear Maintainer,

As previously reported, on an up-to-date sid system, this is an issue.
What kind of information can I provide to help debug this?

I'm also on an intel chipset and I sadly cannot upgrade to the latest
kernel because the latest firmware aren't available (and don't load when
manually added, but there's already another issue for that).

Hopefully the information provided by reportbug can help figure this one
out.

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:1912] (rev 06)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.15.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-16)) #1 SMP Debian 4.15.17-1 (2018-04-19)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root  5896 Jun 22 07:54 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 45179 Jul  3 13:32 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[940820.971] (--) Log file renamed from "/var/log/Xorg.pid-11446.log" to 
"/var/log/Xorg.0.log"
[940820.972] 
X.Org X Server 1.20.0
X Protocol Version 11, Revision 0
[940820.972] Build Operating System: Linux 4.9.0-6-amd64 x86_64 Debian
[940820.972] Current Operating System: Linux mathieu 4.15.0-3-amd64 #1 SMP 
Debian 4.15.17-1 (2018-04-19) x86_64
[940820.972] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-3-amd64 
root=UUID=147a00a9-d4bc-4493-88e8-edc3a9dd19a9 ro quiet
[940820.972] Build Date: 01 July 2018  05:07:24PM
[940820.972] xorg-server 2:1.20.0-3 (https://www.debian.org/support) 
[940820.972] Current version of pixman: 0.34.0
[940820.972]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[940820.972] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[940820.972] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jul  3 13:32:42 
2018
[940820.972] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[940820.972] (==) No Layout section.  Using the first Screen section.
[940820.972] (==) No screen section available. Using defaults.
[940820.972] (**) |-->Screen "Default Screen Section" (0)
[940820.972] (**) |   |-->Monitor ""
[940820.972] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[940820.972] (==) Automatically adding devices
[940820.972] (==) Automatically enabling devices
[940820.972] (==) Automatically adding GPU devices
[940820.972] (==) Max clients allowed: 256, resource mask: 0x1f
[940820.972] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[940820.972]Entry deleted from font path.
[940820.972] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[940820.972] (==) ModulePath set to "/usr/lib/xorg/modules"
[940820.972] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[940820.972] (II) Loader magic: 0x557c58672de0
[940820.972] (II) Module ABI versions:
[940820.972]X.Org ANSI C Emulation: 0.4
[940820.972]X.Org Video Driver: 24.0
[940820.972]X.Org XInput driver : 24.1
[940820.972]X.Org Server Extension : 10.0
[940820.973] (++) using VT number 7

[940820.973] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[940820.973] (II) xfree86: Adding drm device (/dev/dri/card0)
[940820.991] (--) PCI:*(0@0:2:0) 8086:1912:1028:06b9 rev 6, Mem @ 
0xf600/16777216, 0xe000/268435456, I/O @ 0xf000/64, BIOS @ 
0x/131072
[940820.991] (II) LoadModule: "glx"
[940820.991] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[940820.994] (II) Module glx: vendor="X.Org Foundation"
[940820.994]compiled for 1.20.0, module version = 1.0.0
[940820.994]ABI class: X.Org Server Extension, version 10.0
[940820.994] (==) Matched modesetting as autoconfigured driver 0
[940820.994] (==) Matched fbdev as autoconfigured driver 1
[940820.994] (==) Matched vesa as autoconfigured driver 2
[940820.994] (==) Assigned the driver to the xf86ConfigLayout

Bug#902884: [Pkg-utopia-maintainers] Bug#902884: upowerd fails to start

[Michael Biebl]

Control: forcemerge 902411 -1

Am 02.07.2018 um 22:45 schrieb Eric Valette:
> Package: upower
> Version: 0.99.8-1
> Severity: grave
> Justification: renders package unusable
> 
> I had no upowerd daemon running on all my boxes:
> 
> Jul 02 20:52:00 htpc1 systemd[1]: Starting Daemon for power management...
> Jul 02 20:52:01 htpc1 upowerd[1106]: /usr/lib/upower/upowerd: error
> while loading shared libraries: libffi.so.6: cannot enable executable
> stack as shared object requires: O

Duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902411

-- 
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#902895: ant: Automatically setting the value of the javac --release attribute breaks josm build.

[Bas Couwenberg]

Source: ant
Version: 1.10.3-2
Severity: serious
Justification: makes the package in question unusable or mostly so
Control: affects -1 src:josm

Dear Maintainer,

As mentioned on the list [0], the change in ant (1.10.3-2) to
automatically set the value of the javac --release attribute breaks the
josm build.

Please revent this change which is not included upstream.

IMHO it's perfectly fine to require JRE 9 or later when building with
JDK 9 or later. JDK 8 is EOL for ordinary humans.

[0] https://lists.debian.org/debian-java/2018/07/msg6.html

Kind Regards,

Bas

Bug#902894: RFS: fcitx-qt5/1.2.3-1

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-input-met...@lists.debian.org a...@debian.org
sunwea...@debian.org s...@debian.org

Dear Aron, Mike, debian-input-method members and mentors,

As part of bug fixes and package rebuild in Input Method Team, I prepared a
team upload for package "fcitx-qt5" and am currently looking for a sponsor for
this package.

Levels of rebuild (and bugfix):

Level 1:
  * libmarisa0 (done), libopencc2 (done)

Level 2:
  * libbkc2 (done), libkkc-data (done), librime1 (done)

Level 3:
  * brise (done), fcitx (done)

Level 4:
  * fcitx-qt5, goldendict, ibus-libzhuyin, fcitx-kkc, ibus-kkc, ibus-rime
  ^ we are here

Level 5:
  * fcitx-rime

 * Package name: fcitx-qt5
   Version : 1.2.3-1
   Upstream Author : Weng Xuetian 
 * URL : https://github.com/fcitx/fcitx-qt5
 * License : GPL-2+
   Section : libs


  It builds those binary packages:
 fcitx-frontend-qt5 - Free Chinese Input Toy of X - Qt5 IM Module frontend
 fcitx5-module-quickphrase-editor - Flexible Input Method Framework -
Quick Phrase editor module
 libfcitx-qt5-1 - Free Chinese Input Toy of X - D-Bus client libraries for Qt5
 libfcitx-qt5-data - Free Chinese Input Toy of X - data files for Qt5
integration
 libfcitx-qt5-dev - Free Chinese Input Toy of X - Devel files for libfcitx-qt5

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/fcitx-qt5


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/f/fcitx-qt5/fcitx-qt5_1.2.3-1.dsc


  Git packaging repository:

https://salsa.debian.org/debian/fcitx-qt5

  Changes since the last rebuild:

 fcitx-qt5 (1.2.3-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream release.
 + Fix FTBFS with Qt 5.11.
   * Apply "wrap-and-sort -abst".
   * debian/control: Update YunQiang Su's email address with @debian.org one.
   * Drop backported patches.

--
Regards,
Boyuan Yang

Bug#897416: gcc: Decimal float support is not enabled on kfreebsd-amd64

[Matthias Klose]

On 01.07.2018 00:02, Svante Signell wrote:

reopen 897416
found 897416 7.3.0-24, 8.1.0-9
tags 897416 patch
thanks

Hi, the patch by Matthias was not enough to make gcc-7,8 to build
properly. Three configure files were needed to be recreated from their
corresponding configure.ac. Additionally, this patch use x86_64*-*-gnu*
to also cover the future implementation of 64bit Hurd.


this is not applied upstream. Please test the patch on trunk, forward it 
upstream and make sure it gets applied.

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Ryan Tandy]

Control: found -1 4.9.88-1+deb9u1

Hi,

On Sun, Jul 01, 2018 at 03:42:12AM +0100, Ben Hutchings wrote:

Is this bug still present?


It still reproduces with the current stretch kernel:

debian@debian:~/openldap-2.4.44+dfsg/debian/build/tests$ ./run -b mdb 
test060-mt-hot
Cleaning up test run directory leftover from previous run.
Running ../../../tests/scripts/test060-mt-hot for mdb...
running defines.sh
Running slapadd to build slapd database...
Running slapindex to index slapd database...
Starting slapd on TCP/IP port 9011...
/home/debian/openldap-2.4.44+dfsg/debian/build/tests/../servers/slapd/slapd -s0 
-f /home/debian/openldap-2.4.44+dfsg/debian/build/tests/testrun/slapd.1.conf -h 
ldap://localhost:9011/ -d stats
Testing basic monitor search...
Monitor searches
Testing basic mt-hot search: 1 threads (1 x 5) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com 
-w secret -e cn=Monitor -m 1 -L 1 -l 5
Testing basic mt-hot search: 5 threads (1 x 1) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com 
-w secret -e cn=Monitor -m 5 -L 1 -l 1
Testing basic mt-hot search: 100 threads (5 x 100) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com 
-w secret -e cn=Monitor -m 100 -L 5 -l 100
Random searches
Testing random mt-hot search: 1 threads (1 x 5) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com 
-w secret -e dc=example,dc=com -f (objectclass=*) -m 1 -L 1 -l 5
Testing random mt-hot search: 5 threads (1 x 1) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com 
-w secret -e dc=example,dc=com -f (objectclass=*) -m 5 -L 1 -l 1
slapd-mtread failed (139)!
debian@debian:~/openldap-2.4.44+dfsg/debian/build/tests$ uname -a
Linux debian 4.9.0-6-powerpc64le #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) 
ppc64le GNU/Linux

However it looks like it might be resolved with the kernel in unstable. 
I will run some more iterations and let you know.


a7771176 (4.15) looks interesting - it's specifically tagged as fixing 
the commit I isolated as the broken one (dc16b553), and the message 
sounds relevant. If the unstable kernel survives multiple runs I'll see 
what this does on 4.9.


https://patchwork.ozlabs.org/patch/833190/

Bug#902654: larry6: Add support for SVGA version

[Рома Тенцер]

Does the SVGA version work when run with the command from the .desktop file?

Yes, it works.


lsl6-cd is the "gameid" from larry6.yaml. In the case of the VGA version, 
Alexandre filled in lsl6-cd when he first added support for this game; in the case of the 
SVGA version, I guessed lsl6hires.

Yes, and scummvm's gui uses the same gameid. But it works only if the game was 
found by gui.


--detect finds the engine name as gameid. And it works!

$ scummvm -p /usr/share/games/larry6 --detect
ID DescriptionFull 
Path
-- -- 
-
sciLeisure Suit Larry 6: Shape Up or Slip Out! (CD/DOS/English) 
/usr/share/games/larry6


$ scummvm -p /usr/share/games/larry6 sci
User picked target 'sci' (gameid 'sci')...
  Looking for a plugin supporting this gameid... SCI [SCI0, SCI01, SCI10, 
SCI11, SCI32]
  Starting 'Sierra SCI Game'

The game starts successfully. I think it's a scummvm's bug, but not sure if i 
going to report it.

Bug#902893: x11vnc: Error in `x11vnc': corrupted size vs. prev_size: 0x000055f181552530

[Moritz Both]

Package: x11vnc
Version: 0.9.13-2
Severity: important

Dear Maintainer,

for me x11vnc does not accept any input although I can see the
remove screen. I use tightvnc viewer 2.6 on windows 7 as the client.

Also, x11vnc shows a memory corruption issue. Output of the session follows.

###
#@#
#@   @#
#@  **  WARNING  **  WARNING  **  WARNING  **  WARNING  **   @#
#@   @#
#@YOU ARE RUNNING X11VNC WITHOUT A PASSWORD!!@#
#@   @#
#@  This means anyone with network access to this computer   @#
#@  may be able to view and control your desktop.@#
#@   @#
#@ >>> If you did not mean to do this Press CTRL-C now!! <<< @#
#@   @#
#@#
#@   @#
#@  You can create an x11vnc password file by running:   @#
#@   @#
#@   x11vnc -storepasswd password /path/to/passfile  @#
#@  or   x11vnc -storepasswd /path/to/passfile   @#
#@  or   x11vnc -storepasswd @#
#@   @#
#@  (the last one will use ~/.vnc/passwd)@#
#@   @#
#@  and then starting x11vnc via:@#
#@   @#
#@  x11vnc -rfbauth /path/to/passfile@#
#@   @#
#@  an existing ~/.vnc/passwd file from another VNC  @#
#@  application will work fine too.  @#
#@   @#
#@  You can also use the -passwdfile or -passwd options. @#
#@  (note -passwd is unsafe if local users are not trusted)  @#
#@   @#
#@  Make sure any -rfbauth and -passwdfile password files@#
#@  cannot be read by untrusted users.   @#
#@   @#
#@  Use x11vnc -usepw to automatically use your  @#
#@  ~/.vnc/passwd or ~/.vnc/passwdfile password files.   @#
#@  (and prompt you to create ~/.vnc/passwd if neither   @#
#@  file exists.)  Under -usepw, x11vnc will exit if it  @#
#@  cannot find a password to use.   @#
#@   @#
#@   @#
#@  Even with a password, the subsequent VNC traffic is  @#
#@  sent in the clear.  Consider tunnelling via ssh(1):  @#
#@   @#
#@http://www.karlrunge.com/x11vnc/#tunnelling@#
#@   @#
#@  Or using the x11vnc SSL options: -ssl and -stunnel   @#
#@   @#
#@  Please Read the documention for more info about  @#
#@  passwords, security, and encryption. @#
#@   @#
#@http://www.karlrunge.com/x11vnc/faq.html#faq-passwd@#
#@   @#
#@  To disable this warning use the -nopw option, or put @#
#@  'nopw' on a line in your ~/.x11vncrc file.   @#
#@   @#
#@#
###
03/07/2018 04:58:08 x11vnc version: 0.9.13 lastmod: 2011-08-10  pid: 26307
03/07/2018 04:58:08 XOpenDisplay("") failed.
03/07/2018 04:58:08 Trying again with XAUTHLOCALHOSTNAME=localhost ...
03/07/2018 04:58:08
03/07/2018 04:58:08 *** XOpenDisplay failed. No -display or DISPLAY.
03/07/2018 04:58:08 *** Trying ":0" in 4 seconds.  Press Ctrl-C to abort.
03/07/2018 04:58:08 *** 1 2 3 4
03/07/2018 04:58:12 *** XOpenDisplay of ":0" successful.
03/07/2018 04:58:12
03/07/2018 04:58:12 Using X display :0
03/07/2018 04:58:12 rootwin: 0xd5 reswin: 0xa81 dpy: 0x8118a660
03/07/2018 04:58:12
03/07/2018 04:58:12 -- USEFUL INFORMATION --
03/07/2018 04:58:12 X DAMAGE available on display, using it for polling hints.
03/07/2018 04:58:12   To disable this behavior use: '-noxdamage'
03/07/2018 04:58:12
03/07/2018 04:58:12   Most compositing window managers like 'compiz' or 'beryl'
03/07/2018 04:58:12   cause 

Bug#902788: python3-minimal needs Breaks for software/modules broken by 3.7

[Matthias Klose]

Control: reassign -1 python3.7

On 30.06.2018 22:58, Adrian Bunk wrote:

Package: python3-minimal
Version: 3.6.6-1
Severity: serious
Control: block -1 by 902757 902631 902766 902646 902715 902650
Control: block 902582 by -1

Plenty of packages fail to work or even install with Python 3.7
for reasons like 'async' now being a keyword.

python3-minimal needs Breaks for against all versions of other
packages in stretch or buster that don't work with 3.7.


if at all, python3.7 needs these breaks, not the dependency packages.

Bug#902876: wordpress: CVE-2018-12895

[Craig Small]

Hi,
  I was waiting for a WordPress update but for whatever reason it's not
coming.

The impact is less for Debian packages as most of the files are not
writable by the www-data user. A standard installation has to be writable
for the automatic updates.

However plugin and themes are generally writable, so there is still an
impact.

The HitFix looks okay. I will look into it further and if still ok use that
one.

 - Craig

-- 
Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#899998: nvidia-legacy-340xx-kernel-dkms: Fails to boot on 4.16.0-2

[Phil Miller]

After recent upgrades, to 4.16.0-2-amd64 and driver version 340.107-1, I
now see crashes on boot, with the following kernel output:


Jul  2 20:28:58 itu kernel: [   51.342077] gnome-shell[1422]: segfault at
20 ip 7f6e99b6caed sp 7fff8bec9950 error 4 in
libmutter-2.so.0.0.0[7f6e99a6f000+165000]

Jul  2 20:28:58 itu kernel: [   51.786429] gnome-shell[1511]: segfault at
20 ip 7fd5b0236aed sp 7fffaa6b1bd0 error 4 in
libmutter-2.so.0.0.0[7fd5b0139000+165000]

Jul  2 20:29:00 itu kernel: [   53.629851] resource sanity check:
requesting [mem 0x000c-0x000f], which spans more than PCI Bus
:00 [mem 0x000d-0x000d window]

Jul  2 20:29:00 itu kernel: [   53.630028] caller _nv000788rm+0xe4/0x1c0
[nvidia] mapping multiple BARs

Jul  2 20:29:01 itu kernel: [   54.708315] usercopy: Kernel memory exposure
attempt detected from SLUB object 'nvidia_stack_t' (offset 11864, size 3)!

Jul  2 20:29:01 itu kernel: [   54.708327] [ cut here
]

Jul  2 20:29:01 itu kernel: [   54.708328] kernel BUG at
/build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!

Jul  2 20:29:01 itu kernel: [   54.708335] invalid opcode:  [#1] SMP PTI

Jul  2 20:29:01 itu kernel: [   54.708337] Modules linked in: pci_stub
vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) cpufreq_powersave
cpufreq_userspace cpufreq_conservative binfmt_misc snd_hda_codec_realtek
snd_hda_codec_generic intel_powerclamp snd_hda_intel kvm_intel kvm
snd_hda_codec snd_hda_core irqbypass snd_hwdep snd_pcm_oss snd_mixer_oss
snd_pcm intel_cstate intel_uncore iTCO_wdt iTCO_vendor_support evdev dcdbas
snd_timer mei_me shpchp snd mei dell_smm_hwmon lpc_ich i7core_edac pcspkr
serio_raw sg button soundcore acpi_cpufreq nvidia(PO) drm sunrpc f71882fg
coretemp adt7475 hwmon_vid loop parport_pc ppdev lp parport ip_tables
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb
crypto_simd cryptd glue_helper aes_x86_64 sr_mod cdrom sd_mod uas
usb_storage hid_generic usbhid hid ahci libahci broadcom

Jul  2 20:29:01 itu kernel: [   54.708391]  bcm_phy_lib ehci_pci libata
ehci_hcd crc32c_intel psmouse tg3 scsi_mod i2c_i801 usbcore libphy
usb_common

Jul  2 20:29:01 itu kernel: [   54.708403] CPU: 3 PID: 1554 Comm: Xorg
Tainted: P   O 4.16.0-2-amd64 #1 Debian 4.16.16-2

Jul  2 20:29:01 itu kernel: [   54.708405] Hardware name: Dell Inc.
Precision T1500/0XC7MM, BIOS 2.0.3 03/15/2010

Jul  2 20:29:01 itu kernel: [   54.708411] RIP:
0010:usercopy_abort+0x69/0x80

Jul  2 20:29:01 itu kernel: [   54.708413] RSP: 0018:bd3a82c17ba8
EFLAGS: 00010286

Jul  2 20:29:01 itu kernel: [   54.708416] RAX: 006b RBX:
0003 RCX: 

Jul  2 20:29:01 itu kernel: [   54.708418] RDX:  RSI:
9d9e3fcd6738 RDI: 9d9e3fcd6738

Jul  2 20:29:01 itu kernel: [   54.708420] RBP: 0003 R08:
02d6 R09: 0004

Jul  2 20:29:01 itu kernel: [   54.708422] R10: b1077e48 R11:
b17a8dcd R12: 0001

Jul  2 20:29:01 itu kernel: [   54.708424] R13: 9d9e1537de5b R14:
9d9e1537de58 R15: 9d9e1537dea0

Jul  2 20:29:01 itu kernel: [   54.708427] FS:  7f97a11b06c0()
GS:9d9e3fcc() knlGS:

Jul  2 20:29:01 itu kernel: [   54.708429] CS:  0010 DS:  ES:  CR0:
80050033

Jul  2 20:29:01 itu kernel: [   54.708431] CR2: 5639973ffe30 CR3:
0004160c2000 CR4: 06e0

Jul  2 20:29:01 itu kernel: [   54.708433] Call Trace:

Jul  2 20:29:01 itu kernel: [   54.708442]  __check_heap_object+0xe7/0x120

Jul  2 20:29:01 itu kernel: [   54.708445]  __check_object_size+0x9c/0x1a0

Jul  2 20:29:01 itu kernel: [   54.708566]  os_memcpy_to_user+0x21/0x40
[nvidia]

Jul  2 20:29:01 itu kernel: [   54.708693]  _nv001372rm+0xa5/0x260 [nvidia]

Jul  2 20:29:01 itu kernel: [   54.708784]  ? _nv004784rm+0x4eba/0x5500
[nvidia]

Jul  2 20:29:01 itu kernel: [   54.708870]  ? _nv004331rm+0xec/0xf0 [nvidia]

Jul  2 20:29:01 itu kernel: [   54.708954]  ? _nv004326rm+0xca/0x650
[nvidia]

Jul  2 20:29:01 itu kernel: [   54.709035]  ? _nv015126rm+0x576/0x5c0
[nvidia]

Jul  2 20:29:01 itu kernel: [   54.709119]  ? _nv000694rm+0x2e/0x60 [nvidia]

Jul  2 20:29:01 itu kernel: [   54.709194]  ? _nv000789rm+0x5f5/0x8b0
[nvidia]

Jul  2 20:29:01 itu kernel: [   54.709268]  ? rm_ioctl+0x73/0x100 [nvidia]

Jul  2 20:29:01 itu kernel: [   54.709320]  ? nvidia_ioctl+0x221/0x460
[nvidia]

Jul  2 20:29:01 itu kernel: [   54.709374]  ?
nvidia_frontend_ioctl+0x2d/0x60 [nvidia]

Jul  2 20:29:01 itu kernel: [   54.709427]  ?
nvidia_frontend_unlocked_ioctl+0x19/0x20 [nvidia]

Jul  2 20:29:01 itu kernel: [   54.709430]  ? do_vfs_ioctl+0xa4/0x630

Jul  2 20:29:01 itu kernel: [   54.709434]  ? handle_mm_fault+0xdc/0x210

Jul  2 20:29:01 itu kernel: [   54.709436]  ? SyS_ioctl+0x74/0x80

Jul  2 20:29:01 itu kernel: [   54.709440]  ? do_syscall_64+0x6c/0x130

Jul  2 20:29:01 itu kernel: [   54.709444]  ?

Bug#902716: Acknowledgement (reportbug.debian.org has invalid certificate)

[Sandro Tosi]

Hey Don,

> $  openssl s_client  --starttls smtp -connect reportbug.debian.org:587
> CONNECTED(0003)
> depth=0 C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = Debian SMTP 
> CA, CN = buxtehude.debian.org, emailAddress = hostmas...@buxtehude.debian.org
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = Debian SMTP 
> CA, CN = buxtehude.debian.org, emailAddress = hostmas...@buxtehude.debian.org
> verify error:num=21:unable to verify the first certificate
> verify return:1

so it looks like it's a self-issued local certificate? reportbug.d.o
advertises STARTTLS in its options

morph@zion:~/deb/reportbug$ telnet reportbug.debian.org 587
Trying 2607:f8f0:614:1::1274:39...
Connected to buxtehude.debian.org.
Escape character is '^]'.
he220 buxtehude.debian.org ESMTP Exim 4.89 Tue, 03 Jul 2018 01:12:00 +
ehlo sandrotosi.me
250-buxtehude.debian.org Hello sandrotosi.me
[2604:2000:e902:f100:a2d0:6b79:bba:e2b5]
250-SIZE 104857600
250-8BITMIME
250-STARTTLS
250 HELP

but i'm not sure how it could work if the client cant verify the certs chain.

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

Bug#902892: plinth: Any change to user account will lock out user

[James Valleroy]

Package: plinth
Version: 0.33.0
Severity: grave
Justification: renders package unusable

If plinth has a single admin user account, and any changes are made to
that user account, the user will be locked out of plinth.

More information and logs:
https://salsa.debian.org/freedombox-team/plinth/issues/1314

Bug#902821: Workaround update

[Someone fromjapan]

Found the problem
LC_CTYPE=ja_JP.UTF-8
fixes the input.

Requested solution:
The English UI package should not rewrite LC_CTYPE environment variable.
LC_CTYPE should be linked only to the keyboards/layouts/inputs installed,
not to the UI language.

Bug#902821: conditions update

[Someone fromjapan]

 Seems, changing LANG= value to ja_JP has no effect.
Therefore, probably the culprit is the Gnome English UI package. Something
is changed in IM relations, making UIM incapable of switching to MOZC, when
switched to Japanese layout.

Tried installing ALL and EVERY uim & mozc package. The "conversion mode"
underline appears under the symbols, when "hankaku-zenkaku" button is
switched. But no hiraganam or kanji conversion happens;  just exits
from "conversion mode", instead of offering conversion variants.

Bug#515856: Debian Policy 4.1.4.0 released

[Russ Allbery]

Jonathan Nieder  writes:

> Context: I have run into a few packages that used the +dfsg convention
> without documenting what they removed from the tarball and I was not
> able to locally update them. :(

This is one of the cases that now has a better solution and more standard
tools than the get-orig-source target, specifically Files-Excluded in
debian/copyright.  See the documentation of Files-Excluded in uscan(1).

-- 
Russ Allbery (r...@debian.org)   

Bug#892278: stretch-pu: package reportbug/7.1.7+deb9u1

[Andreas Beckmann]

On Wed, 07 Mar 2018 17:53:39 +0100 Markus Koschany  wrote:
> as requested in #891918 I am hereby filing another stretch-pu update
> for reportbug, so that we can fix #878088 in stable too. Please find
> attached the debdiff.

Please also include the one-line change to disable jessie-pu in the
release.debian.org template: #902379


Andreas

Bug#902883: [Pkg-samba-maint] Bug#902883: FTBFS on arch != amd64 because different libpytalloc-util.*.so name

[Andrew Bartlett]

On Mon, 2018-07-02 at 22:15 +0200, Mathieu Parent wrote:
> Package: src:talloc
> Version: 2.1.13-1
> Severity: serious
> 
> Regression since python3 support:
> 
> [...]
> dh_makeshlibs -ppython-talloc -ppython3-talloc -Xtalloc. -- -c3
> dpkg-gensymbols: warning: new libraries appeared in the symbols file: 
> libpytalloc-util.cpython-36m-aarch64-linux-gnu.so.2
> dpkg-gensymbols: warning: some libraries disappeared in the symbols file: 
> libpytalloc-util.cpython-36m-x86-64-linux-gnu.so.2
> dpkg-gensymbols: warning: debian/python3-talloc/DEBIAN/symbols doesn't match 
> completely debian/python3-talloc.symbols

See also https://github.com/samba-team/samba/pull/110 for BaT trying to
fix this kind of thing on FreeBSD.

Andrew Bartlett
-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba

Bug#902890: Ask users if they are happy with units trying to connect to the network on its own every day

[積丹尼 Dan Jacobson]

Package: units
Version: 2.17-1

Please add a dpkg-reconfigure item that would ask the user:

Units now tries to go on the network every day to get exchange rates.

Do you really want units to do that,

or would you be much more happy if it only did it on demand when needed
and cached it and only got it again or printed error messages when it
was over 24 hours old etc.

As your computer is not networked 24 hours a day, and you don't like
programs making random connections for features you hardly use etc.




> "A" == Anacron   writes:
A> /etc/cron.daily/units:
A> Error connecting to currency server:
A> HTTPConnectionPool(host='finance.yahoo.com', port=80): Max retries exceeded 
with url: /webservice/v1/symbols/allcurrencies/quote?format=json (Caused by 
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary 
failure in name resolution',)).
A> run-parts: /etc/cron.daily/units exited with return code 1

Bug#902889: Incorrect email address in bug report

[John Darrah]

I had not set my exim address mapping correctly and inadvertently gave 
an incorrect address.


My correct email address is: xyl...@gmail.com

-- john

Bug#902889: mutt: The "message_cachedir" variable is unrecognized and cannot be set

[John Darrah]

Package: mutt
Version: 1.10.0-1
Severity: normal

Dear Maintainer,

When setting the "message_cachedir" in ~/.muttrc, the following error is 
elicited:

  Error in /home/john/.muttrc, line 37: set message_cachedir=~/.mutt_cache/: 
unknown command
  source: errors in /home/john/.muttrc
  Press any key to continue...

Since it is well documented in the man page, I assume it is a valid setting.

-- john

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

System: Linux 4.9.0-6-amd64 (x86_64)
ncurses: ncurses 6.1.20180210 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-19' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-19) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-9LDmAX/mutt-1.10.0=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-9LDmAX/mutt-1.10.0=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  -HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  +USE_SIDEBAR  +USE_COMPRESSED  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


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

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

Versions of packages mutt depends on:
ii  libassuan02.4.3-2
ii  libc6 2.24-11+deb9u3
ii  libcom-err2   1.44.2-1
ii  libgnutls30   3.5.8-5+deb9u3
ii  libgpg-error0 1.26-2
ii  libgpgme11

Bug#902888: [lcl-utils-1.8] lazbuild crash when lazarus-src is not installed

[Alexander Kernozhitsky]

Package: lcl-utils-1.8
Version: 1.8.4+dfsg-1
Severity: normal

I was trying to build a project using lazbuild. To do this, I installed the 
following packages: lcl-utils, lcl-units, lcl-nogui (not the entire Lazarus 
IDE). Then I ran

$ lazbuild .lpi

and got a crash at lazbuild startup. The stacktrace is:

An unhandled exception occurred at $009D6060:
EAccessViolation: Access violation
  $009D6060 line 952 of etfpcmsgparser.pas
  $00587F6A line 3053 of compileroptions.pp
  $005DC005 line 1048 of ../packager/packagesystem.pas
  $005E584A line 3544 of ../packager/packagesystem.pas
  $005E52F8 line 3442 of ../packager/packagesystem.pas
  $005E99BB line 4027 of ../packager/packagesystem.pas
  $005E917B line 3871 of ../packager/packagesystem.pas
  $004049B5 line 800 of lazbuild.lpr
  $004043DE line 965 of lazbuild.lpr
  $00402286 line 417 of lazbuild.lpr
  $00408B7E line 1467 of lazbuild.lpr
  $0040BCD6 line 1870 of lazbuild.lpr

(To make this stacktrace, I recompiled lazbuild with debugging symbols)

Nothing else was printed to the console.

After I installed lazarus-src, the problem disappeared. With the entire ide 
(lazarus-ide packages) the bug isn't reproducible also.

The bug doesn't happen on all projects, but on the projects where it happens, 
it is reproducible always (attempts to rebuild >10 times exposes the same 
problem)

--- System information. ---
Architecture: 
Kernel:   Linux 4.16.0-2-amd64

Debian Release: buster/sid
  990 testing ftp.by.debian.org 
  500 unstableftp.by.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-===
fp-compiler| 
debconf  (>= 0.5)  | 1.5.67
 OR debconf-2.0| 
libc6   (>= 2.2.5) | 


Recommends   (Version) | Installed
==-+-===
lazarus-ide-1.8| 1.8.4+dfsg-1
lcl-1.8| 1.8.4+dfsg-1


Package's Suggests field is empty.
-- 
-
Alexander Kernozhitsky

Bug#792205: closed by Guillaume Bougard (Re: fusioninventory-agent: modifies conffiles (policy 10.7.3): /etc/fusioninventory/agent.cfg)

[Andreas Beckmann]

On 2018-07-02 20:10, gregor herrmann wrote:
> On Mon, 02 Jul 2018 09:19:11 +0200, Guillaume Bougard wrote:
> 
>> in fact, and regarding the package history, the bug should have
>> been opened with 2.3.10 and closed with not releases 2.3.15...
>>
>> How to avoid this case becomes blocking for the migration to
>> testing planned in 8 days now ?
> 
> Technically, I suppose that "resetting" the affected versions [0]
> should do it. I'm just a bit reluctant to do or recommend it since
> there must have been a reason why Andreas filed the bug against
> 1:2.3.16-1.

even if 1:2.3.16-1 fixed it for new installations, it didn't clean up
after upgrades from older versions. Not sure whether it exploded with a
dpkg prompt about modified conffiles ...

> OTOH, I guess it's a bit hard to test the complete upgrade path any
> longer [1], and I'm not sure how much it matters at this point.

That's still easily possible - needs 4 -d options for piuparts.

> We could also (temporarily?) lower the severity of the bug; but I'd
> rather wait for Andreas' opinion on the issue.

That's probably OK, or rather remove the fixed version.


Andreas

Bug#902887: [fpc] Add dbgsym packages for packages compiled with FPC

[Alexander Kernozhitsky]

Package: fpc
Version: 3.0.4+dfsg-19
Severity: wishlist

For many packages, there are dbgsym packages. Now it's present mostly for 
packages built with GCC. I think it will be a good idea to provide dbgsym 
packages for programs built with FPC.

--- System information. ---
Architecture: 
Kernel:   Linux 4.16.0-2-amd64

Debian Release: buster/sid
  990 testing ftp.by.debian.org 
  500 unstableftp.by.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-==
fpc-3.0.4  (= 3.0.4+dfsg-19) | 3.0.4+dfsg-19
fp-docs-3.0.4| 3.0.4+dfsg-19
fp-utils-3.0.4   | 3.0.4+dfsg-19


Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
-
Alexander Kernozhitsky

Bug#902716: reportbug.debian.org has invalid certificate

[Don Armstrong]

On Fri, 29 Jun 2018, Sandro Tosi wrote:
> > In the changelog for reportbug, it refers to the SMTP server as
> > reportbug.debian.org.  However, when connecting to reportbug.debian.org
> > port 587, and using STARTTLS, an invalid certificate is presented.
> >
> >   Version: 3 (0x2)
> >   Serial Number: 3836 (0xefc)
> >   Signature Algorithm: sha1WithRSAEncryption
> >   Issuer: C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = Debian 
> > SMTP CA, CN = Debian SMTP CA, emailAddress = hostmas...@puppet.debian.org
> >   Validity
> >   Not Before: Dec 12 00:00:11 2017 GMT
> >   Not After : Dec 12 00:00:11 2018 GMT
> >   Subject: C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = Debian 
> > SMTP CA, CN = buxtehude.debian.org, emailAddress = hostmaster@buxtehu
> >
> > Please use a valid certificate for reportbug.debian.org.

That's a valid certificate. The CN is buxtehude.debian.org, and the MX
for reportbug.debian.org should be buxtehude.debian.org.

> > In addition, on port 443, https://reportbug.debian.org is an invalid
> > certificate.  It's only valid for:
> > * bugs-beach.debian.org
> > * bugs-buxtehude.debian.org
> > * bugs.debian.org
> 
> has something change on the BTS side certificates today?

I haven't changed anything; but as far as I know, there's no https site
for reportbug anyway.

-- 
Don Armstrong  https://www.donarmstrong.com

I shall require that [a scientific system's] logical form shall be
such that it can be singled out, by means of empirical tests, in a
negative sense: it must be possible for an empirical scientific system
to be refuted by experience.
 -- Sir Karl Popper _Logic of Scientific Discovery_ §6

Bug#902886: CVE-2018-0499: HTML escaping bug

[Olly Betts]

Package: libxapian30
Version: 1.4.5-1
Severity: important
Tags: security patch upstream

I spotted an HTML escaping bug in Xapian::MSet::snippet() while working
on the code.  This issue has been assigned CVE-2018-0499 by the security
team.

This bug is fixed by yesterday's upstream release 1.4.6 which I'm
intending to upload to unstable very shortly.  The attached patch should
be suitable for fixing this in older 1.4.x releases (1.2.x isn't
affected).

Cheers,
Olly
diff --git a/xapian-core/queryparser/termgenerator_internal.cc b/xapian-core/queryparser/termgenerator_internal.cc
index 7fa807db6064..fece98554ebb 100644
--- a/xapian-core/queryparser/termgenerator_internal.cc
+++ b/xapian-core/queryparser/termgenerator_internal.cc
@@ -432,6 +432,27 @@ SnipPipe::done()
 }
 }
 
+inline void
+append_escaping_xml(const char* p, const char* end, string& output)
+{
+while (p != end) {
+	char ch = *p++;
+	switch (ch) {
+	case '&':
+		output += "";
+		break;
+	case '<':
+		output += "";
+		break;
+	case '>':
+		output += "";
+		break;
+	default:
+		output += ch;
+	}
+}
+}
+
 inline bool
 SnipPipe::drain(const string & input,
 		const string & hi_start,
@@ -465,7 +486,7 @@ SnipPipe::drain(const string & input,
 
 	if (punc) {
 	// Include end of sentence punctuation.
-	output.append(input.data() + best_end, i.raw());
+	append_escaping_xml(input.data() + best_end, i.raw(), output);
 	} else {
 	// Append "..." or equivalent if this doesn't seem to be the start
 	// of a sentence.
@@ -523,8 +544,7 @@ SnipPipe::drain(const string & input,
 	while (i != Utf8Iterator()) {
 	unsigned ch = *i;
 	if (Unicode::is_wordchar(ch)) {
-		const char * p = input.data() + best_begin;
-		output.append(p, i.raw() - p);
+		append_escaping_xml(input.data() + best_begin, i.raw(), output);
 		best_begin = i.raw() - input.data();
 		break;
 	}
@@ -537,22 +557,9 @@ SnipPipe::drain(const string & input,
 	if (phrase_len) output += hi_start;
 }
 
-while (best_begin != word.term_end) {
-	char ch = input[best_begin++];
-	switch (ch) {
-	case '&':
-		output += "";
-		break;
-	case '<':
-		output += "";
-		break;
-	case '>':
-		output += "";
-		break;
-	default:
-		output += ch;
-	}
-}
+const char* p = input.data();
+append_escaping_xml(p + best_begin, p + word.term_end, output);
+best_begin = word.term_end;
 
 if (phrase_len && --phrase_len == 0) output += hi_end;
 
diff --git a/xapian-core/tests/api_snippets.cc b/xapian-core/tests/api_snippets.cc
index 4c9296f88d84..70f6afac28bf 100644
--- a/xapian-core/tests/api_snippets.cc
+++ b/xapian-core/tests/api_snippets.cc
@@ -313,3 +313,23 @@ DEFINE_TESTCASE(snippet_empty, backend) {
 
 return true;
 }
+
+/// Check snippets escape HTML/XML suitably.
+DEFINE_TESTCASE(snippet_html_escape, backend) {
+Xapian::Enquire enquire(get_database("apitest_simpledata"));
+enquire.set_query(Xapian::Query("foo"));
+
+Xapian::MSet mset = enquire.get_mset(0, 0);
+
+Xapian::Stem stem;
+
+const char *input = "#include  to use libfoo";
+TEST_STRINGS_EQUAL(mset.snippet(input, 12, stem),
+		   "...foo.h to...");
+
+input = " takes the address of foo";
+TEST_STRINGS_EQUAL(mset.snippet(input, strlen(input), stem),
+		   "foo takes the address of foo");
+
+return true;
+}


signature.asc
Description: PGP signature

Bug#902832: stretch-pu: package rustc/1.24.1+dfsg1-1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-07-01 at 22:36 +0200, Moritz Muehlenhoff wrote:
> the second update to allow us to keep up with Firefox ESR60;
> rustc 1.24. See attached debdiff against 1.24.1 from unstable.
> 
> This uses a bootstrap build which I've tested successfully
> on amd64.

rustc appears to have no in-archive dependencies in stretch, so
assuming there's been at least some testing on the resulting package,
please go ahead.

Regards,

Adam

Bug#515856: Debian Policy 4.1.4.0 released

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon, Jul 02 2018, Jonathan Nieder wrote:

>> I'm a bit confused: wasn't it already specified pretty precisely?
>
> Please take a look through the bug's discussion.  It's explained why the
> wording was not thought to be good enough.

Thanks.  This looks like a classic case of letting the perfect be the
enemy of the good (or perhaps, of not understanding the use case for
which the existing practice was good enough).  Some quotes from the
bug:

| According to codesearch.d.n, get-orig-source is implemented by less than
| 3000 source packages. This is not very low, but neither a high adoption
| rate. It certainly makes using get-orig-source somewhat useless on a
| distribution-scale.

Certainly it's even more useful to have a debian/watch file, but this
doesn't make it clear to me what I'm supposed to do with those 3,000
source packages now.

|  * The requirement that get-orig-source may be invoked from any
|directory is difficult to fulfil and often times not implemented. A

This hasn't been an obstacle to my use.  I can even try multiple
directories.  What's helpful for me is that it works from *somewhere*.

|  * It is not clear whether the most recent upstream version or the
|currently packaged version should be downloaded.

Likewise, either works fine for my use.

|  * It is not clear where required tools should be declared.

As long as the command prints an error about the required tool, I can
install it.

| We're just reducing
| the documented interfaces of packages a bit based on current trends,
| which is useful for newcomers to Debian.

What is a newcomer supposed to do now when they encounter a package
that does not provide an explanation of how to generate the upstream
tarball?

Jonathan

Bug#515856: Debian Policy 4.1.4.0 released

[Sean Whitton]

Hello Jonathan,

On Mon, Jul 02 2018, Jonathan Nieder wrote:

> I'm a bit confused: wasn't it already specified pretty precisely?

Please take a look through the bug's discussion.  It's explained why the
wording was not thought to be good enough.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#515856: Debian Policy 4.1.4.0 released

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Wed, Apr 11 2018, Russ Allbery wrote:

>> I'm pretty reluctant to specify this sort of optional target that
>> works differently in every package that uses it back in Policy because
>> it's really not standardized, nor do I think it's possible to
>> standardize.  If we really want to write something down about the
>> target, maybe the Developer's Reference would be a better spot?  There
>> were a whole host of issues with having this in Policy that were
>> resolved by moving it outside the scope of Policy, such as how to
>> document dependencies required for running the get-orig-source target.
>
> The Developer's Reference seems like a more appropriate place for a
> convention that it is not possible to specify precisely.

I'm a bit confused: wasn't it already specified pretty precisely?

I would be in favor of adding the target back, with a description
along the lines of "If you provide a get-orig-source target, it should
satisfy .  If you provide neither a get-orig-source
target nor a debian/watch file and you do not use an archive from
upstream as-is, please include clear instructions in README.source to
allow a human to produce an upstream tarball."

Context: I have run into a few packages that used the +dfsg convention
without documenting what they removed from the tarball and I was not
able to locally update them. :(

Thanks,
Jonathan

Bug#902885: ITP: node-cubic2quad -- Approximate cubic Bezier curve with a number of quadratic ones

[Bastien ROUCARIES]

package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-cubic2quad
  Version : 1.1.1
  Upstream Author : Fontello team
* URL : https://github.com/fontello/cubic2quad#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Approximate cubic Bezier curve with a number of
quadratic ones

This package allows one to create TTF fonts, those support quadratic
curves only,
from cubic bezier path description (like SVG ones).
.
Generated curves have the same tangents angles at the ends, allowing to
keep result visually smooth.
 .
Node.js is an event-based server-side JavaScript engine.

Bug#899221: break up emacs-goodies-el into many elpafied packages

[Nicholas D Steeves]

Hi,

On Sat, Jun 30, 2018 at 07:04:01AM +0100, Sean Whitton wrote:
> Hello,
> 
> Great to see progress on this.

Thanks.  David's bug triaging has been invaluable.

> On Fri, Jun 29 2018, Nicholas D Steeves wrote:
> 
> > Sean, so I guess we're in phase 2 (breaking out those two pkgs was
> > phase 1).  I'll definitely be returning to reread your comments when
> > we hit phase 3—considering becoming upstream for a subset of packages.
> > Thank you :-)
> 
> Well, we've already made ourselves upstream of dpkg-dev-el and
> debian-el...

I'm hoping maintainance of most loved addons is distributed between
multiple people...

> > To Team: At this point the plan seems to be to outright drop anything
> > with a dead upstream.
> >
> > 11. At what point in the future do you think packages should be
> > removed from goodies when a maintainer for the elpa-variant hasn't
> > yet stepped forward?  eg: Let's define this best case scenario:
> > all 90 subpackages have been triaged before DebCamp.  Worst case
> > of: sometime before September.
> >
> > Aug 12th is six months before the "no-rentry into testing"
> > deadline of Feb 2019.
> 
> Well, it's a matter of whether or not we think they should be in buster.
> 
> It seems unlikely that these packages lost their active maintainership
> since stretch was released, so they've already been in one stable
> release in their current state.  So it seems reasonable not to include
> them in buster?  Might not want to cut it too close to the freeze in
> case there are delays.

Ah, I should have clarified that the ones that are being targeted for
removal are ones with old bugs with no resolution in sight, and
definitely cases where the upstream author says a project is
unmaintained because equivalent functionality is now built-in to GNU
Emacs.

I'm going to try for an optimistic removal goal of July 12th, because
that will give potential maintainers of the removed addons time to
realise "oh, this is missing now and I care enough about it to
maintain it".  Maybe that's overly aggressive, but there are still
something like 70/90 packages left to elpafy or drop.

Then there are cases like color-theme vs native deftheme/custom
themes.

> > To Team: Ok, with the work in progress src:emacs-goodies-el is
> > dropping XEmacs support, and this is documented in debian/NEWS.
> 
> Good idea to add debian/NEWS.

Also, the faster moving details and stuff like x was dropped, use
built-in y instead are tracked in README.Debian.

Where z provides the functionality of x, x was dropped from goodies,
but z was never in emacs-goodies-el, do you think a suggests or
recommends would be more appropriate?  Eventually the elpafied
packages will be Depends for the dummy package, but if one is taking
the time to find a suitable replacement and justify x's removal, then
it seems like we might as well profit from the time investment while
making the user's life a bit easier by adding a suggests/recommends.
My gut feeling is a suggests would be most appropriate, even though a
recommends would be more convenient to the user.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#902884: upowerd fails to start

[Eric Valette]

Package: upower
Version: 0.99.8-1
Severity: grave
Justification: renders package unusable

I had no upowerd daemon running on all my boxes:

Jul 02 20:52:00 htpc1 systemd[1]: Starting Daemon for power management...
Jul 02 20:52:01 htpc1 upowerd[1106]: /usr/lib/upower/upowerd: error 
while loading shared libraries: libffi.so.6: cannot enable executable 
stack as shared object requires: O
Jul 02 20:52:01 htpc1 systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jul 02 20:52:01 htpc1 systemd[1]: upower.service: Failed with result 
'exit-code'.
Jul 02 20:52:01 htpc1 systemd[1]: Failed to start Daemon for power 
management.
Jul 02 20:52:01 htpc1 systemd[1]: upower.service: Service 
RestartSec=100ms expired, scheduling restart.
Jul 02 20:52:01 htpc1 systemd[1]: upower.service: Scheduled restart job, 
restart counter is at 1.

Jul 02 20:52:01 htpc1 systemd[1]: Stopped Daemon for power management.
Jul 02 20:52:01 htpc1 systemd[1]: Starting Daemon for power management...
Jul 02 20:52:01 htpc1 upowerd[1109]: /usr/lib/upower/upowerd: error 
while loading shared libraries: libffi.so.6: cannot enable executable 
stack as shared object requires: O
Jul 02 20:52:01 htpc1 systemd[1]: upower.service: Main process exited, 
code=exited, status=127/n/a
Jul 02 20:52:01 htpc1 systemd[1]: upower.service: Failed with result 
'exit-code'.
Jul 02 20:52:01 htpc1 systemd[1]: Failed to start Daemon for power 
management.
Jul 02 20:52:01 htpc1 systemd[1]: upower.service: Service 
RestartSec=100ms expired, scheduling restart.
Jul 02 20:52:01 htpc1 systemd[1]: upower.service: Scheduled restart job, 
restart counter is at 2.

Jul 02 20:52:01 htpc1 systemd[1]: Stopped Daemon for power management.
Jul 02 20:52:01 htpc1 systemd[1]: Starting Daemon for power management...
lines 1249-1287

execstack -c /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 clear the problem.



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

Kernel: Linux 4.14.52 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF8 (charmap=UTF-8)

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

Versions of packages upower depends on:
ii  dbus   1.13.4-3
ii  libc6  2.27-3
ii  libglib2.0-0   2.56.1-2
ii  libgudev-1.0-0 232-2
ii  libimobiledevice6  1.2.1~git20180302.3a37a4e-1
ii  libplist3  2.0.0-3
ii  libupower-glib30.99.8-1
ii  libusb-1.0-0   2:1.0.22-2
ii  udev   239-3

Versions of packages upower recommends:
ii  policykit-1  0.114-1

upower suggests no packages.

-- no debconf information


-- eric

Bug#902851: libc-bin: ldd stopped working with 32-bit binaries on amd64 machine

[Aurelien Jarno]

tag: severity -1 normal
tag: control -1 + moreinfo

On 2018-07-02 12:48, Alexandra N. Kossovsky wrote:
> Package: libc-bin
> Version: 2.27-3
> Severity: important
> 
> ldd stopped from working with 32-bit executables:
> bash$ ./my_binary
> 
> bash$ file ./my_binary
> ./my_binary: ELF 32-bit LSB pie executable Intel 80386, version 1 (SYSV),
> dynamically
> +linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0,
> +BuildID[sha1]=9dd357821ed6cc00f74cb74c06f8430893d742b3, with debug_info,
> not stripped
> bash$ ldd ./my_binary
> not a dynamic executable
> bash$

I am not able to reproduce the issue. That said for it to work you need
to have a 32-bit dynamic linker installed. It can be provided by either
libc6-i386 or libc6:i386. Is it installed on your system?

> We've already reported similar bug to Fedora:
> https://bugzilla.redhat.com/show_bug.cgi?id=1596312
> I.e. it may be an upstream bug.
> 
> It all used to work some time ago on the Debian testing system, and it works
> on
> Debian stable and Debian oldstable systems.

Can you check if you have libc6-i386 or libc6:i386 installed on those
systems?

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#902883: FTBFS on arch != amd64 because different libpytalloc-util.*.so name

[Mathieu Parent]

Package: src:talloc
Version: 2.1.13-1
Severity: serious

Regression since python3 support:

[...]
dh_makeshlibs -ppython-talloc -ppython3-talloc -Xtalloc. -- -c3
dpkg-gensymbols: warning: new libraries appeared in the symbols file: 
libpytalloc-util.cpython-36m-aarch64-linux-gnu.so.2
dpkg-gensymbols: warning: some libraries disappeared in the symbols file: 
libpytalloc-util.cpython-36m-x86-64-linux-gnu.so.2
dpkg-gensymbols: warning: debian/python3-talloc/DEBIAN/symbols doesn't match 
completely debian/python3-talloc.symbols
--- debian/python3-talloc.symbols (python3-talloc_2.1.13-1_arm64)
+++ dpkg-gensymbolsYed6IE   2018-07-02 13:59:00.845850036 +
@@ -1,26 +1,26 @@
-libpytalloc-util.cpython-36m-x86-64-linux-gnu.so.2 python3-talloc #MINVER#
- 
PYTALLOC_UTIL.CPYTHON_36M_X86_64_LINUX_GNU_2.1.13@PYTALLOC_UTIL.CPYTHON_36M_X86_64_LINUX_GNU_2.1.13
 2.1.13
- PYTALLOC_UTIL.PY3_2.1.10@PYTALLOC_UTIL.PY3_2.1.10 2.1.11
- PYTALLOC_UTIL.PY3_2.1.11@PYTALLOC_UTIL.PY3_2.1.11 2.1.11
- PYTALLOC_UTIL.PY3_2.1.12@PYTALLOC_UTIL.PY3_2.1.12 2.1.12
- PYTALLOC_UTIL.PY3_2.1.13@PYTALLOC_UTIL.PY3_2.1.13 2.1.13
- PYTALLOC_UTIL.PY3_2.1.5@PYTALLOC_UTIL.PY3_2.1.5 2.1.11
- PYTALLOC_UTIL.PY3_2.1.6@PYTALLOC_UTIL.PY3_2.1.6 2.1.11
- PYTALLOC_UTIL.PY3_2.1.7@PYTALLOC_UTIL.PY3_2.1.7 2.1.11
- PYTALLOC_UTIL.PY3_2.1.8@PYTALLOC_UTIL.PY3_2.1.8 2.1.11
- PYTALLOC_UTIL.PY3_2.1.9@PYTALLOC_UTIL.PY3_2.1.9 2.1.11
- _pytalloc_check_type@PYTALLOC_UTIL.PY3_2.1.9 2.1.11
- _pytalloc_get_mem_ctx@PYTALLOC_UTIL.PY3_2.1.6 2.1.11
- _pytalloc_get_ptr@PYTALLOC_UTIL.PY3_2.1.6 2.1.11
- _pytalloc_get_type@PYTALLOC_UTIL.PY3_2.1.6 2.1.11
- pytalloc_BaseObject_PyType_Ready@PYTALLOC_UTIL.PY3_2.1.6 2.1.11
- pytalloc_BaseObject_check@PYTALLOC_UTIL.PY3_2.1.6 2.1.11
- pytalloc_BaseObject_size@PYTALLOC_UTIL.PY3_2.1.6 2.1.11
- pytalloc_Check@PYTALLOC_UTIL.PY3_2.1.5 2.1.11
- pytalloc_GenericObject_reference_ex@PYTALLOC_UTIL.PY3_2.1.9 2.1.11
- pytalloc_GenericObject_steal_ex@PYTALLOC_UTIL.PY3_2.1.9 2.1.11
- pytalloc_GetBaseObjectType@PYTALLOC_UTIL.PY3_2.1.6 2.1.11
- pytalloc_GetObjectType@PYTALLOC_UTIL.PY3_2.1.5 2.1.11
- pytalloc_reference_ex@PYTALLOC_UTIL.PY3_2.1.5 2.1.11
- pytalloc_steal@PYTALLOC_UTIL.PY3_2.1.5 2.1.11
- pytalloc_steal_ex@PYTALLOC_UTIL.PY3_2.1.5 2.1.11
+libpytalloc-util.cpython-36m-aarch64-linux-gnu.so.2 python3-talloc #MINVER#
+ 
PYTALLOC_UTIL.CPYTHON_36M_AARCH64_LINUX_GNU_2.1.13@PYTALLOC_UTIL.CPYTHON_36M_AARCH64_LINUX_GNU_2.1.13
 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.10@PYTALLOC_UTIL.PY3_2.1.10 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.11@PYTALLOC_UTIL.PY3_2.1.11 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.12@PYTALLOC_UTIL.PY3_2.1.12 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.13@PYTALLOC_UTIL.PY3_2.1.13 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.5@PYTALLOC_UTIL.PY3_2.1.5 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.6@PYTALLOC_UTIL.PY3_2.1.6 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.7@PYTALLOC_UTIL.PY3_2.1.7 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.8@PYTALLOC_UTIL.PY3_2.1.8 2.1.13-1
+ PYTALLOC_UTIL.PY3_2.1.9@PYTALLOC_UTIL.PY3_2.1.9 2.1.13-1
+ _pytalloc_check_type@PYTALLOC_UTIL.PY3_2.1.9 2.1.13-1
+ _pytalloc_get_mem_ctx@PYTALLOC_UTIL.PY3_2.1.6 2.1.13-1
+ _pytalloc_get_ptr@PYTALLOC_UTIL.PY3_2.1.6 2.1.13-1
+ _pytalloc_get_type@PYTALLOC_UTIL.PY3_2.1.6 2.1.13-1
+ pytalloc_BaseObject_PyType_Ready@PYTALLOC_UTIL.PY3_2.1.6 2.1.13-1
+ pytalloc_BaseObject_check@PYTALLOC_UTIL.PY3_2.1.6 2.1.13-1
+ pytalloc_BaseObject_size@PYTALLOC_UTIL.PY3_2.1.6 2.1.13-1
+ pytalloc_Check@PYTALLOC_UTIL.PY3_2.1.5 2.1.13-1
+ pytalloc_GenericObject_reference_ex@PYTALLOC_UTIL.PY3_2.1.9 2.1.13-1
+ pytalloc_GenericObject_steal_ex@PYTALLOC_UTIL.PY3_2.1.9 2.1.13-1
+ pytalloc_GetBaseObjectType@PYTALLOC_UTIL.PY3_2.1.6 2.1.13-1
+ pytalloc_GetObjectType@PYTALLOC_UTIL.PY3_2.1.5 2.1.13-1
+ pytalloc_reference_ex@PYTALLOC_UTIL.PY3_2.1.5 2.1.13-1
+ pytalloc_steal@PYTALLOC_UTIL.PY3_2.1.5 2.1.13-1
+ pytalloc_steal_ex@PYTALLOC_UTIL.PY3_2.1.5 2.1.13-1
dh_makeshlibs: failing due to earlier errors
debian/rules:72: recipe for target 'override_dh_makeshlibs' failed


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

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

Bug#902633: RFA: php-elisp -- php mode for emacs

[Ola Lundqvist]

Hi

With this I say I can still be co maintainer.

/ Ola

Sent from a phone

Den mån 2 juli 2018 22:07Ola Lundqvist  skrev:

> Hi
>
> I still use it so I can do some limited tests if necessary.
>
> But I only use stable so it must be installable on stable in that case.
>
> Sounds ok?
>
> / Ola
>
> Sent from a phone
>
> Den mån 2 juli 2018 21:51Nicholas D Steeves  skrev:
>
>> On Thu, Jun 28, 2018 at 11:24:03PM +0200, Ola Lundqvist wrote:
>> >Package: php-elisp
>> >I still use the package but I do not have the time to update to newer
>> >releases.
>> >So if anyone would like to help or even better take it over, please
>> do so.
>> >Send me an email so I know
>> >/ Ola
>>
>> I'm willing to update the package to the newest upstream release,
>> current standards, convert the package to use dh-elpa, etc, and keep
>> the package up to date.
>>
>> But as I don't use PHP at all, and consequently won't actually be
>> using this mode, I'd like to share the responsibility of maintaining
>> the package with a comaintainer.
>>
>> Ola, if a more qualified maintainer doesn't volunteer, how does the
>> following sound as a worst-case scenario:  Adopt php-elisp under
>> Debian Emacsen team maintenance and give you permission to commit to
>> the salsa project, set you as the primary uploader, and myself as
>> another uploader.  Do you still use the package?
>>
>> Regards,
>> Nicholas
>>
>

Bug#902633: RFA: php-elisp -- php mode for emacs

[Ola Lundqvist]

Hi

I still use it so I can do some limited tests if necessary.

But I only use stable so it must be installable on stable in that case.

Sounds ok?

/ Ola

Sent from a phone

Den mån 2 juli 2018 21:51Nicholas D Steeves  skrev:

> On Thu, Jun 28, 2018 at 11:24:03PM +0200, Ola Lundqvist wrote:
> >Package: php-elisp
> >I still use the package but I do not have the time to update to newer
> >releases.
> >So if anyone would like to help or even better take it over, please
> do so.
> >Send me an email so I know
> >/ Ola
>
> I'm willing to update the package to the newest upstream release,
> current standards, convert the package to use dh-elpa, etc, and keep
> the package up to date.
>
> But as I don't use PHP at all, and consequently won't actually be
> using this mode, I'd like to share the responsibility of maintaining
> the package with a comaintainer.
>
> Ola, if a more qualified maintainer doesn't volunteer, how does the
> following sound as a worst-case scenario:  Adopt php-elisp under
> Debian Emacsen team maintenance and give you permission to commit to
> the salsa project, set you as the primary uploader, and myself as
> another uploader.  Do you still use the package?
>
> Regards,
> Nicholas
>

Bug#902716: reportbug.debian.org has invalid certificate

[Brian Minton]

On the other hand, https to bugreport.debian.org (port 443) is nearly
correct:

* Server certificate:
*subject: CN=bugs.debian.org
*start date: 2018-05-05 00:09:24 GMT
*expire date: 2018-08-03 00:09:24 GMT
*subjectAltName does not match reportbug.debian.org

Bug#902716: Acknowledgement (reportbug.debian.org has invalid certificate)

[Brian Minton]

​

$  openssl s_client  --starttls smtp -connect reportbug.debian.org:587
CONNECTED(0003)
depth=0 C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU =
Debian SMTP CA, CN = buxtehude.debian.org, emailAddress =
hostmas...@buxtehude.debian.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU =
Debian SMTP CA, CN = buxtehude.debian.org, emailAddress =
hostmas...@buxtehude.debian.org
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=NA/ST=NA/L=Ankh Morpork/O=Debian SMTP/OU=Debian SMTP
CA/CN=buxtehude.debian.org/emailAddress=hostmas...@buxtehude.debian.org
   i:/C=NA/ST=NA/L=Ankh Morpork/O=Debian SMTP/OU=Debian SMTP
CA/CN=Debian SMTP CA/emailAddress=hostmas...@puppet.debian.org
---
Server certificate
-BEGIN CERTIFICATE-
MIIFOjCCBCKgAwIBAgICDvwwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAk5B
MQswCQYDVQQIEwJOQTEVMBMGA1UEBxMMQW5raCBNb3Jwb3JrMRQwEgYDVQQKEwtE
ZWJpYW4gU01UUDEXMBUGA1UECxMORGViaWFuIFNNVFAgQ0ExFzAVBgNVBAMTDkRl
YmlhbiBTTVRQIENBMSswKQYJKoZIhvcNAQkBFhxob3N0bWFzdGVyQHB1cHBldC5k
ZWJpYW4ub3JnMB4XDTE3MTIxMjAwMDAxMVoXDTE4MTIxMjAwMDAxMVowga8xCzAJ
BgNVBAYTAk5BMQswCQYDVQQIEwJOQTEVMBMGA1UEBxMMQW5raCBNb3Jwb3JrMRQw
EgYDVQQKEwtEZWJpYW4gU01UUDEXMBUGA1UECxMORGViaWFuIFNNVFAgQ0ExHTAb
BgNVBAMTFGJ1eHRlaHVkZS5kZWJpYW4ub3JnMS4wLAYJKoZIhvcNAQkBFh9ob3N0
bWFzdGVyQGJ1eHRlaHVkZS5kZWJpYW4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAovy58Ske6mkx4bSCaS34lJ4FCorDU6H6oNEWlgNVTzH1xYA5
3wvMScSqvbRYPK8B0VSPD5/G+4dfj9XBGbHdHsS7nWHutrwyNUL6cTl2CBvUwAzP
EQj5d3JLL0aa8VLZshH3BTKBuWx8TR983zDTb6+yKivvr1HcqSyeqeAZ3H3w4sb1
4SIXUDn65hoyoODgEWZWt8Xs8PTk1T37evp5QnabdX91bmN6UIkRPzJWuVNTPKtY
xMVhIlHmhS+btvI7s8DI2XwOTMt5kLUq58XWr1OmIqpOBjASLn6ExChh1eXnPtcf
vhzoFLKd8L+MVAb21qf1tkMn3ZeYls2345TcaQIDAQABo4IBZTCCAWEwCQYDVR0T
BAIwADARBglghkgBhvhCAQEEBAMCBkAwIgYJYIZIAYb4QgENBBUWE0RlYmlhbiBT
TVRQIENBIGNlcnQwHQYDVR0OBBYEFOCPtMQWehUMfn1FDZ4RoyDKg838MIHbBgNV
HSMEgdMwgdCAFF9qbFIB0eabRXjptXlBG7eAytjGoYGspIGpMIGmMQswCQYDVQQG
EwJOQTELMAkGA1UECBMCTkExFTATBgNVBAcTDEFua2ggTW9ycG9yazEUMBIGA1UE
ChMLRGViaWFuIFNNVFAxFzAVBgNVBAsTDkRlYmlhbiBTTVRQIENBMRcwFQYDVQQD
Ew5EZWJpYW4gU01UUCBDQTErMCkGCSqGSIb3DQEJARYcaG9zdG1hc3RlckBwdXBw
ZXQuZGViaWFuLm9yZ4IJAPYIE0pJ99rTMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAsG
A1UdDwQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAolkEmpsPbJ7uu6noZ0uEZMI2
LnJTEJtFdXxcNFGLmC5XswksXD819v3ZvETVET52tRDD151avY2FqBrqamwEtyVp
1AnGfbmjhPFmjDlJfEtTb5/5s8Rmk75ySYdF/bMnufGb2IedbFdx5/rlNXl7ZQK/
/Nm7sI8MtsNpcdOBg6Sr9efrmk0BUUUrxMPxGhTsegEwYddgdKVqBiQiw6oot1bk
vH5/mVkxtUJmUrdSNoPlVnOWitUJqCXARqA8VA3zOvoOZJ7HMq2M/zPDn72NBJrx
WFX4EkUqvwzloM7JDJ7aH1/xG2+Bgr0JMQ9X4VOE8fdY43gWC/GdrRY1iFhb5g==
-END CERTIFICATE-
subject=/C=NA/ST=NA/L=Ankh Morpork/O=Debian SMTP/OU=Debian SMTP
CA/CN=buxtehude.debian.org/emailAddress=hostmas...@buxtehude.debian.org
issuer=/C=NA/ST=NA/L=Ankh Morpork/O=Debian SMTP/OU=Debian SMTP
CA/CN=Debian SMTP CA/emailAddress=hostmas...@puppet.debian.org
---
Acceptable client certificate CA names
/C=NA/ST=NA/L=Ankh Morpork/O=Debian SMTP/OU=Debian SMTP CA/CN=Debian
SMTP CA/emailAddress=hostmas...@puppet.debian.org
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms:
RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms:
RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2282 bytes and written 347 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 7E3BBFDAE6C0616D76239C40803DB81092DCA2E86842377C3A122A649F47D189
Session-ID-ctx:
Master-Key:
2E1E1A68F43A38EDE8A4B67E82BA3C63D1551E6CF5F78F3F81F8F705418F7B7FF4A223088DF687D219CE12B283FEE0F9
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1530560544
Timeout   : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: yes
---
250 HELP
quit
221 buxtehude.debian.org closing connection
closed

Bug#891590: sbuild: Please signalize autopkgtest failure by exit code, at least optionally

[Johannes Schauer]

Quoting Christoph Biedl (2018-07-02 18:43:52)
> Thanks a lot, I'm fine with this as it's the "at least as an option" way.
> Just a small thing, if I understand correctly, this change will not provide
> command-line options to control the behaviour. Having these was last
> refinement though as I'll use this feature in any automated setup where I
> have to maintain a configuration file anyway.

At least for now I'll not add command line options for this. The number of
command line options sbuild has is already very hard to read and adding six
long options

--lintian-require-success --no-lintian-require-success
--piuparts-require-success --no-piuparts-require-success
--autopkgtest-require-success --no-autopkgtest-require-success

Would increase the mess even more. Plus an entry that documents each of these
six options...

I think we only want command line options for things that the user might want
to change on a build-to-build or package-to-package basis. But for a setting
like this, I expect that a user might want to either have it for everything or
for nothing. If that is the case, then there is no need for a command line
option.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#902633: RFA: php-elisp -- php mode for emacs

[Nicholas D Steeves]

On Thu, Jun 28, 2018 at 11:24:03PM +0200, Ola Lundqvist wrote:
>Package: php-elisp
>I still use the package but I do not have the time to update to newer
>releases.
>So if anyone would like to help or even better take it over, please do so.
>Send me an email so I know
>/ Ola

I'm willing to update the package to the newest upstream release,
current standards, convert the package to use dh-elpa, etc, and keep
the package up to date.

But as I don't use PHP at all, and consequently won't actually be
using this mode, I'd like to share the responsibility of maintaining
the package with a comaintainer.

Ola, if a more qualified maintainer doesn't volunteer, how does the
following sound as a worst-case scenario:  Adopt php-elisp under
Debian Emacsen team maintenance and give you permission to commit to
the salsa project, set you as the primary uploader, and myself as
another uploader.  Do you still use the package?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#902709: diffoscope: test failures everywhere

[Mattia Rizzolo]

On Mon, Jul 02, 2018 at 08:43:04PM +0100, Chris Lamb wrote:
> > This particular error is fixed by d6f1d04 (and I did include the bug
> > number in the commit).
> 
> Are we talking about the right commit? I only ask because I do not see
> the bug number in the commit... :)
> 
>https://salsa.debian.org/reproducible-builds/diffoscope/commit/
>  d6f1d04b3dbc3f350f50a798979e1501a8cb89f3

Oops, copy-paste error.  Indeed, I'm referring to this other commit:
https://salsa.debian.org/reproducible-builds/diffoscope/commit/a6b4effcfb24780d9d2d1b76efa33132381f76eb

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#902709: diffoscope: test failures everywhere

[Mattia Rizzolo]

Control: owner -1 !
Control: tag -1 pending

On Mon, Jul 02, 2018 at 06:52:15PM +0100, Chris Lamb wrote:
> Are we still seeing this on current master? (As-of writing, that is
> a6b4effc).  I ask because, as mentioned previously, I cannot reproduce
> this. :)

This particular error is fixed by d6f1d04 (and I did include the bug
number in the commit).

However, in the process of fixing this I also configure gitlab CI, which
is reporting 4 more errors (look at salsa.d.o, or IRC yesterday).

> Happy to upload if your recent changes (d6f1d04 looks promising?)
> fix it.

I'll take care of it once I can debug the other 4 errors (tbh, I didn't
try to reproduce them locally).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#902709: diffoscope: test failures everywhere

[Chris Lamb]

Hi Mattia,

> This particular error is fixed by d6f1d04 (and I did include the bug
> number in the commit).

Are we talking about the right commit? I only ask because I do not see
the bug number in the commit... :)

   https://salsa.debian.org/reproducible-builds/diffoscope/commit/
 d6f1d04b3dbc3f350f50a798979e1501a8cb89f3


Best wishes,

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

Bug#902882: libarchive-zip-perl: CVE-2018-10860: Directory traversal in Archive::Zip

[Salvatore Bonaccorso]

Source: libarchive-zip-perl
Version: 1.60-1
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/redhotpenguin/perl-Archive-Zip/pull/33

Hi,

The following vulnerability was published for libarchive-zip-perl.

CVE-2018-10860[0]:
| perl-archive-zip is vulnerable to a directory traversal in
| Archive::Zip. It was found that the Archive::Zip module did not
| properly sanitize paths while extracting zip files. An attacker able
| to provide a specially crafted archive for processing could use this
| flaw to write or overwrite arbitrary files in the context of the perl
| interpreter.

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-10860
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10860
[1] https://github.com/redhotpenguin/perl-Archive-Zip/pull/33

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#891410: upstream work is already in progress

[Jochen Hein]

Christoph Biedl  writes:

> Thanks for reminding me, it's on radar - but given the discussion hasn't
> been finished yet I'd prefer to wait until this is part of another
> clevis release. If you'd like to have it cherry-picked so people can
> start playing with it, let me know.

I've no idea when the next upstream release will happen, but my hope is
to have clevis in buster.  So perhaps waiting some more should be fine,
but if the freeze is nearing for buster I'd reconsider cherry picking.
So, let's wait some more for upstream.

Jochen

-- 
This space is intentionally left blank.

Bug#902881: [debian-installer] Cannot partition disk in Testing installer

[Alexander Kernozhitsky]

Package: debian-installer
Version: 20180610
Severity: grave

I tried to install Debian Testing on VirtualBox using a weekly build of Debian 
Installer. Everything went OK until the disk partitioning stage. In this 
stage, installer warned me that the kernel doesn't support LVM and I should 
load lvm-mod. Then, I didn't found an option to format a partition as Ext4 
filesystem. Automatical installation allowed to create an Ext4 root partition, 
but after writing the changes to disk it says something like "cannot mount /".

--- System information. ---
Architecture: 
Kernel:   Linux 4.16.0-2-amd64

Debian Release: buster/sid
  990 testing ftp.by.debian.org 
  500 unstableftp.by.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
-
Alexander Kernozhitsky

Bug#902880: ngspice: move from non-free to main section

[Matsievskiy S.V.]

Package: ngspice
Version: ngspice
Severity: wishlist

Dear Maintainer,

According to COPYING file from ngspice (version 28), its components are
distributed under following licences: GPL, LGPL, CC-BY-SA v4.0, BSD, public
domain. All of these are listed as compatible to DFSG
(https://wiki.debian.org/DFSGLicenses). Therefore I think that it's appropriate
to move ngspice from non-free to main section.



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

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

Copyright (c) 2018 by ngspice maintainers
All rights reserved.

license for this document: CC-BY-SA v4.0

 ngspice license **

The ngspice source code has evolved over time by integrating contributions
from various sources (e.g. Spice3f5, XSPICE, CIDER, numparam, tclspice and
others). Thus a mixture of license statements prevails.

The ngspice license is the `Modified BSD' license. This is adopted for all of
its source code, test and example files except for the files listed below.

** files with licenses different to 'Modified BSD' 

* ngspice/contrib
GPL, Public Domain

* ngspice/m4
unnamed, compatible to DFSG

* ngspice/src/tclspice.c
LGPLv2

* all files in ngspice/src/maths/sparse
unnamed MIT license, compatible to New BSD

ngspice/src/spicelib/devices/adms/admst
LGPLv2.1

ngspice/src/spicelib/devices/ndev
public domain

ngspice/src/xspice
public domain
except for
ngspice/src/xspice/icm/table
GPLv2 or newer

ngspice/src/frontend/numparam
LGPLv2 or newer

ngspice manual
(see https://sourceforge.net/p/ngspice/ngspice-manuals/ci/master/tree/)
Creative Commons Attribution Share-Alike (CC-BY-SA) v4.0

-- ngspice -
-- 'Modified BSD' --

Copyright 1985 - 2018, Regents of the University of California and others

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.



-- Xspice 

THE SOFTWARE PROGRAMS BELOW ARE IN THE PUBLIC DOMAIN AND ARE PROVIDED FREE OF
ANY CHARGE. THE GEORGIA TECH RESEARCH CORPORATION, THE GEORGIA INSTITUTE OF
TECHNOLOGY, AND/OR OTHER PARTIES PROVIDE THIS SOFTWARE "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH THE USER.
SHOULD THE PROGRAM PROVE DEFECTIVE, THE USER ASSUMES THE ENTIRE COST OF ALL
NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT WILL THE GEORGIA TECH
RESEARCH CORPORATION, THE GEORGIA INSTITUTE OF TECHNOLOGY, AND/OR OTHER PARTIES
PROVIDING THE PROGRAMS BELOW BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS).


-- others 

  GNU 

Bug#902447: clevis-udisks2: /usr/lib/x86_64-linux-gnu/clevis-luks-udisks2 is not setuid/setgid

[Christoph Biedl]

tags 902447 confirmed
thanks

Jochen Hein wrote...

> I think we need to install clevis-luks-udisks2 setuid root on
> Debian/Ubuntu too.  Did I miss something else?

This needs to be fixed, although I'm not at all happy to ship setuid
binaries in 2018. I'll try to find another way for this (capabilities
perhaps?) but my hopes are rather low.

Christoph


signature.asc
Description: PGP signature

Bug#902654: larry6: Add support for SVGA version

[Simon McVittie]

On Tue, 03 Jul 2018 at 01:25:04 +0700, Рома Тенцер wrote:
> First. The command from a menu item for vga version doesn't works. I'm not
> sure if it's a g-d-p problem — when i use scummvm's gui to find the game
> manually it works fine and the command starts to work.
> 
> $ scummvm -p /usr/share/games/larry6 lsl6-cd
> scummvm: Unrecognized game target 'lsl6-cd'
> Usage: scummvm [OPTIONS]... [GAME]
> 
> Try 'scummvm --help' for more options.

lsl6-cd is the "gameid" from larry6.yaml. In the case of the VGA version,
Alexandre filled in lsl6-cd when he first added support for this game;
in the case of the SVGA version, I guessed lsl6hires.

Does the SVGA version work when run with the command from the .desktop
file? If it does, them my guess was correct.

Can you find a scummvm command-line option that does work as a replacement
for lsl6-cd? It might help to use

scummvm -p /usr/share/games/larry6 --detect
scummvm -p /usr/share/games/larry6-svga --detect

If I understand scummvm correctly, we want the "ID" column. I don't have
any of the LSL games, but for instance, here's what I get for Loom:

$ scummvm -p /usr/share/games/loom-en --detect
ID DescriptionFull 
Path
-- -- 
-
loom   Loom (VGA/DOS/English) 
/usr/share/games/loom-en

> And second. A menu items for both versions have the same name. I don't think
> it's good.

I think that means we need a different "longname" directive in the YAML
for one or both of them, to add a (VGA) or (SVGA) suffix (see larry1.yaml
for an example of this).

smcv

Bug#891410: upstream work is already in progress

[Christoph Biedl]

tags 891410 -help pending
thanks

Jochen Hein wrote...

> please have a look at https://github.com/latchset/clevis/pull/35
> I've used the scripts from https://github.com/latchset/clevis/pull/18,
> where I added my comments/diff for Debian.
> 
> I guess that the updated pull request is a better start now.
> Hope this helps.

Thanks for reminding me, it's on radar - but given the discussion hasn't
been finished yet I'd prefer to wait until this is part of another
clevis release. If you'd like to have it cherry-picked so people can
start playing with it, let me know.

Christoph



signature.asc
Description: PGP signature

Bug#869939: [Hyper-V] Feature request: pick up PTP Hyper-V timesync source from upstream 4.12

[Ben Hutchings]

Control: tag -1 - patch

On Thu, 27 Jul 2017 20:56:13 + Josh Poulson  wrote:
> Package: linux-image
> Version: 3.16.43-2+deb8u2
> Severity: important
> Tags: patch,fixed-upstream
> 
> This should backport fairly easily to stretch,
[...]

It doesn't.

I would welcome a tested backport of this.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.



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

Bug#887543: libemail-find-perl depends on libemail-address-perl

[gregor herrmann]

On Sun, 01 Jul 2018 01:35:12 +0200, Pali Rohár wrote:

> Module Email::Find was last time updated in year 2007, see:
> 
> https://metacpan.org/pod/Email::Find
> 
> So I'm skeptical that this problem is ever going to be fixed...

% reverse-depends libemail-find-perl
Reverse-Depends
===
* cil
* libhtml-fromtext-perl
* libtemplate-plugin-clickable-email-perl


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#902779: perl-debug: XS code built for perl doesn't work with debugperl

[Niko Tyni]

Control: block 902557 with -1

On Sat, Jun 30, 2018 at 10:06:34PM +0300, Niko Tyni wrote:
> Package: perl-debug
> Version: 5.28.0-1
> Severity: normal
> User: debian-p...@lists.debian.org
> Usertags: perl-5.28-transition
> 
> I noticed that many of our XS module packages are incompatible
> with debugperl after being rebuilt for 5.28. Consider:
> 
>  # debugperl -MDateTime -e 'print DateTime->today'
>  panic: XSUB DateTime::_rd2ymd (DateTime.c) failed to extend arg stack: 
> base=55b63e6b3b48, sp=55b63e6b3b80, hwm=55b63e6b3b68
> 
> This panic is due to a new -DDEBUGGING check that guards the XS function
> argument stack, making sure that XS code extends the stack properly when
> it pushes elements there.
> 
> However, I believe the check isn't currently working properly when
> the XS code is built with a non-DDEBUGGING perl.h and then run with a
> -DDEBUGGING perl build.

So, I see the EXTEND macro in pp.h is instrumented to make a note of
how far the stack is supposed to extend, and this 'high-water mark'
(hwm) is compared to the stack pointer after calling an XSUB. If the
XSUB has pushed more elements than it declared with EXTEND (or didn't
call EXTEND at all), the above panic will result.

The problem is that EXTEND only updates the high-water mark when the
DEBUGGING preprocessor symbol is defined (i.e. the choice is done at
compile time.) If the XS module is built without -DDEBUGGING in ccflags
(as is the case for Debian XS module packages), the high-water mark
doesn't get updated.  If the interpreter side is built with -DDEBUGGING
(as our debugperl is), it will still check the hwm.

I see two obvious avenues for fixing this:

A) move the -DDEBUGGING check in EXTEND to run time, for instance by
   calling a function that's a no-op in non-DEBUGGING interpreters. This
   has a runtime cost, but I'm not sure how significant. We need to ask
   upstream.

B) disable the check on the DEBUGGING side altogether. There's currently
   no facility to do this short of patching the code.

If A) is judged adequate upstream, we should do that before the 5.28
transition so that we don't have to rebuild all the XS modules afterwards.
I'm therefore marking this as a transition blocker for now.

Otherwise we need to do B) and lose some useful debugging checks.
-- 
Niko Tyni   nt...@debian.org

Bug#874526: Keyboard grab doesn't work under Wayland

[Josh Triplett]

On Mon, Jul 02, 2018 at 06:36:54PM +0100, Simon McVittie wrote:
> On Wed, 06 Sep 2017 at 14:58:37 -0700, Josh Triplett wrote:
> > (It might also help to add Ctrl-Alt-Delete to the list of shortcuts
> > provided in the gnome-boxes keyboard menu, alongside Ctrl-Alt-Backspace
> > and similar.)
> 
> This is now provided in the keyboard menu for both gnome-boxes and
> virt-manager.

I appreciate that, thank you. That will help heavily as a workaround.

Bug#874526: Keyboard grab doesn't work under Wayland

[Josh Triplett]

On Mon, Jul 02, 2018 at 06:14:44PM +0100, Simon McVittie wrote:
> On Mon, 02 Jul 2018 at 01:39:24 -0700, Josh Triplett wrote:
> > On Mon, Jul 02, 2018 at 08:14:48AM +0100, Simon McVittie wrote:
> > > This seems to work under GNOME 3.28 (probably also 3.26). I'm prompted
> > > while starting up the VM for whether to allow gnome-boxes to grab the
> > > keyboard. I haven't tried a Windows VM, but if I use the keyboard menu to
> > > switch to a text-mode VT for a Linux VM with Ctrl+Alt+F$n, then either
> > > press Ctrl+Alt+Del or send it via the keyboard menu, the VM reboots
> > > as expected.
> > 
> > I can confirm that I can still reproduce this with current GNOME and
> > gnome-boxes; Ctrl+Alt+Del still goes to GNOME and not to the VM.
> 
> Which versions of gnome-shell, libmutter-2-0, gnome-boxes do you have?

gnome-boxes 3.28.5-1
gnome-shell 3.28.2-1
libmutter-2-0:amd64 3.28.2-2

> Are you prompted for whether to let gnome-boxes inhibit shortcuts? You
> should get a system-modal dialog (the sort that dims the entire screen,
> like the Shut Down dialog you get from Ctrl+Alt+Del itself) something
> like this:
> 
> |--|
> |  Boxes wants to inhibit shortcuts|
> | /!\  |
> |  You can restore shortcuts by pressing Super+Escape. |
> |  |
> |[ Deny ][ Allow ]-|
> 
> (If you don't click Allow then this feature is not expected to work.)

No, I don't get that prompt from gnome-boxes. (I've seen it before from
other applications.)

> Does it help to click inside the virtual machine window before pressing
> Ctrl+Alt+Del?

If I'm in windowed mode, yes.

As far as I can tell, it's possible to end up in a state in which the VM
has the focus but gnome-boxes doesn't have a grab on Ctrl+Alt+Del. This
can happen both in windowed mode and in fullscreen mode. In windowed
mode, if I click in gnome-boxes then a grab takes place and Ctrl+Alt+Del
works.

This may also have something to do with switching windows (via the
overview) away from a VM.

> Does sending Ctrl+Alt+Del via the keyboard menu work?

Yes.

Bug#902654: larry6: Add support for SVGA version

[Рома Тенцер]

Both versions works fine (thanks!) except for two issues.

First. The command from a menu item for vga version doesn't works. I'm 
not sure if it's a g-d-p problem — when i use scummvm's gui to find the 
game manually it works fine and the command starts to work.


$ scummvm -p /usr/share/games/larry6 lsl6-cd
scummvm: Unrecognized game target 'lsl6-cd'
Usage: scummvm [OPTIONS]... [GAME]

Try 'scummvm --help' for more options.


And second. A menu items for both versions have the same name. I don't 
think it's good.



P.S.


Your make-template output has 64 files in AUD/, all of which we package, and no 
HIRES/ or SFX/ directory; so I think GOG have done this already?


GOG uses dosbox to run svga-version.

Bug#902796: /usr/lib/python2.7/dist-packages/magic.py: Aborts; too many arguments to str()

[Christoph Biedl]

tags 902796 -moreinfo
thanks

Christoph Biedl wrote...

> This is certainly stable point release material, so if I can provide a
> fix within a very few days, this problem will go away quite soon.
> However, I'd like to see this with my own eyes first.

Okay, got a reproducer. This happens if the libmagic function returns
NULL (C) aka None (Python) - which isn't str (Python).

While I failed to trigger this using the buffer() and file() methods
without API misuse, see below, calling error() although there wasn't any
does the trick:

#!/usr/bin/python
import magic
ms = magic.open(magic.MAGIC_MIME)
ms.load()
print (ms.buffer(""))
print (ms.error())
ms.close()

Output:

| application/x-empty; charset=binary
| Traceback (most recent call last):
|   File "../example.py", line 6, in 
| print (ms.error())
|   File "/usr/lib/python2.7/dist-packages/magic.py", line 166, in error
| return str(e, 'utf-8')
| TypeError: str() takes at most 1 argument (2 given)

Fix is probably upstream commit FILE5_30-37-g8a942980, not tested yet.

Aside, the following code triggers an exception as well:

#!/usr/bin/python
import magic
ms = magic.open(magic.MAGIC_MIME)
#~ ms.load()
buf = ""
tp = ms.buffer(buf)
print (tp)
ms.close()

But skipping load() is a violation of the API since:

[magic.py, ll.155]

| def load(self, filename=None):
| """
+ Must be called to load entries in the colon separated list of database
+ files passed as argument or the default database file if no argument
+ before any magic queries can be performed.
| 
| Returns 0 on success and -1 on failure.
| """
| return _load(self._magic_t, filename)

And yes, people get this wrong, like in

Which is the only place I found where this message occured in the wild.

Christoph


signature.asc
Description: PGP signature

Bug#792205: closed by Guillaume Bougard (Re: fusioninventory-agent: modifies conffiles (policy 10.7.3): /etc/fusioninventory/agent.cfg)

[gregor herrmann]

On Mon, 02 Jul 2018 09:19:11 +0200, Guillaume Bougard wrote:

> in fact, and regarding the package history, the bug should have
> been opened with 2.3.10 and closed with not releases 2.3.15...
> 
> How to avoid this case becomes blocking for the migration to
> testing planned in 8 days now ?

Technically, I suppose that "resetting" the affected versions [0]
should do it. I'm just a bit reluctant to do or recommend it since
there must have been a reason why Andreas filed the bug against
1:2.3.16-1.

OTOH, I guess it's a bit hard to test the complete upgrade path any
longer [1], and I'm not sure how much it matters at this point.

We could also (temporarily?) lower the severity of the bug; but I'd
rather wait for Andreas' opinion on the issue.

The current piuparts results look good:
https://piuparts.debian.org/sid/source/f/fusioninventory-agent.html
but AFAICS they only test install and removal of the current version
and no upgrades ...


Cheers,
gregor


[0]
notfound 792205 1:2.3.16-1
found 792205 1:2.3.10.1-1

[1]
"This problem was observed after an squeeze -> wheezy -> jessie ->
stretch upgrade."
 

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


signature.asc
Description: Digital Signature

Bug#902879: cryptdisks_start: fails on non-block-devices, "skipped, device $CRYPTTAB_SOURCE does not exist"

[Steve Cotton]

Package: cryptsetup-run
Version: 2:2.0.3-4
Severity: normal

The latest version of cryptdisks_start seems to have dropped support for
regular files containing the data for an encrypted loopback mount.  With
2:2.0.3 it seems that the scripts' sanity checks will only accept block
devices, and give the error "skipped, device $CRYPTTAB_SOURCE does not exist"
for regular files.

I'd normally do
# cryptdisks_start user_clientdev_crypt
# mount /home/clientdev/workspace/

# cryptdisks_start user_clientdev_crypt
[FAIL] Starting crypto disk...user_clientdev_crypt (skipped, device 
/home/.clientdev_crypt does not exist)...failed.

# file -s /home/.clientdev_crypt 
/home/.clientdev_crypt: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] 
UUID: a81e1598-9f69-44be-986a-dde68bdcac54

# ls -l /home/.clientdev_crypt 
-rw-r--r-- 1 root root 536870912000 Jul  2 13:18 /home/.clientdev_crypt

# grep client /etc/crypttab 
user_clientdev_crypt /home/.clientdev_crypt noneluks,discard,noauto

# grep client /etc/fstab 
/dev/mapper/user_clientdev_crypt /home/clientdev/workspace/ ext4noauto  
0   0

Regards,
Steve

-- Package-specific info:

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

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

Versions of packages cryptsetup-run depends on:
ii  cryptsetup-bin 2:2.0.3-4
ii  debconf [debconf-2.0]  1.5.67
ii  dmsetup2:1.02.145-4.1
ii  libc6  2.27-3

cryptsetup-run recommends no packages.

Versions of packages cryptsetup-run suggests:
ii  dosfstools  4.1-2
pn  keyutils
ii  liblocale-gettext-perl  1.07-3+b3

-- debconf information:
* cryptsetup/prerm_active_mappings: false

Bug#902709: diffoscope: test failures everywhere

[Chris Lamb]

Hi Mattia,

> So, autopkgtest is failing
[…]
> The ubuntu build also failed with a very similar error
[…]
> And also the reproducible builds build FTBFS with the same errors.

Are we still seeing this on current master? (As-of writing, that is
a6b4effc).  I ask because, as mentioned previously, I cannot reproduce
this. :)

Happy to upload if your recent changes (d6f1d04 looks promising?)
fix it.


Regards,

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

Bug#902878: pyyaml: CVE-2017-18342

[Salvatore Bonaccorso]

Source: pyyaml
Version: 3.12-1
Severity: normal
Tags: security upstream
Forwarded: https://github.com/yaml/pyyaml/pull/74

Hi,

The following vulnerability was published for pyyaml. Please see the
notes in the security tracker to see why this got a CVE assigned now.
The bug is filled to track the "fixed version" rebased to 4.1 once it
gets uploaded to Debian. There is no action to be taken for older
releases.

CVE-2017-18342[0]:
| In PyYAML before 4.1, the yaml.load() API could execute arbitrary code.
| In other words, yaml.safe_load is not used.

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-2017-18342
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18342

Regards,
Salvatore

Bug#902868: [src:linux] linux-image-4.16.0-2-amd64 fails to start X-Server

[Leo]

Package: src:linux
Version: 4.16.16-2

--- Please enter the report below this line. ---
Ich kann den Fehler bestätigen und weiter eingrenzen. Ich komme bis zum
Start des X-Servers und dann kommt erst der Fehler. Ein neu kompilieren
des NVIDIA Treibers brachte keinen erfolgt. Mein System friert
vollkommen ein (kein "NUM" mehr möglich)
-
I can confirm the error and narrow it down further. I come to the start
of the X server and then comes first the error. A recompilation of the
NVIDIA driver did not take place. My system freezes completely (no "NUM"
possible anymore)

/var/log/kern.log
Jul 2 19:19:22 APC kernel: [ 15.41] [ cut here ]
Jul 2 19:19:22 APC kernel: [ 15.45] Bad or missing usercopy
whitelist? Kernel memory exposure attempt detected from SLUB object
'nvidia_stack_cache' (offset 11440, size 3)!
Jul 2 19:19:22 APC kernel: [ 15.57] WARNING: CPU: 1 PID: 804 at
/build/linux-hny3SU/linux-4.16.5/mm/usercopy.c:81 usercopy_warn+0x7e/0xa0
Jul 2 19:19:22 APC kernel: [ 15.58] Modules linked in: pci_stub
vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) iptable_filter cmac
uinput bnep binfmt_misc fuse xfs snd_hda_codec_hdmi tda18212dd(O)
snd_hda_codec_realtek sn
d_hda_codec_generic joydev snd_hda_intel snd_hda_codec snd_hda_core
iTCO_wdt iTCO_vendor_support intel_powerclamp snd_hwdep kvm_intel kvm
btusb btrtl btbcm btintel bluetooth drbg evdev ansi_cprng serio_raw
pcspkr ecdh_generic rfkill irqb
ypass intel_cstate intel_uncore stv0367dd(O) i7core_edac snd_pcm_oss
ddbridge(O) snd_mixer_oss cxd2099(O) snd_pcm dvb_core(O) snd_timer snd
shpchp soundcore sg lpc_ich button acpi_cpufreq nvidia_drm(PO) sunrpc
drm_kms_helper drm nvidia_m
odeset(PO) nvidia(PO) ipmi_devintf ipmi_msghandler it87 hwmon_vid
coretemp loop parport_pc ppdev lp parport ip_tables x_tables autofs4
Jul 2 19:19:22 APC kernel: [ 15.97] ext4 crc16 mbcache jbd2 fscrypto
ecb crypto_simd cryptd glue_helper aes_x86_64 raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq
libcrc32c crc32c_gene
ric raid0 multipath linear raid1 md_mod sr_mod cdrom sd_mod hid_generic
usbhid hid ahci libahci libata crc32c_intel scsi_mod ehci_pci xhci_pci
i2c_i801 uhci_hcd xhci_hcd ehci_hcd r8169 mii usbcore usb_common
Jul 2 19:19:22 APC kernel: [ 15.222321] CPU: 1 PID: 804 Comm: Xorg
Tainted: P O 4.16.0-1-amd64 #1 Debian 4.16.5-1
Jul 2 19:19:22 APC kernel: [ 15.222322] Hardware name: Gigabyte
Technology Co., Ltd. P55A-UD3/P55A-UD3, BIOS F11 08/10/2010
Jul 2 19:19:22 APC kernel: [ 15.222325] RIP: 0010:usercopy_warn+0x7e/0xa0
Jul 2 19:19:22 APC kernel: [ 15.222326] RSP: 0018:a44f82babb60
EFLAGS: 00010282
Jul 2 19:19:22 APC kernel: [ 15.222328] RAX:  RBX:
988a8a142cb0 RCX: 0006
Jul 2 19:19:22 APC kernel: [ 15.222330] RDX: 0007 RSI:
0096 RDI: 988aafc56730
Jul 2 19:19:22 APC kernel: [ 15.222331] RBP: 0003 R08:
03b6 R09: 0007
Jul 2 19:19:22 APC kernel: [ 15.222333] R10: 89a769d0 R11:
8a1a8dcd R12: 0001
Jul 2 19:19:22 APC kernel: [ 15.222334] R13: 988a8a142cb3 R14:
 R15: 988a8a142cf8
Jul 2 19:19:22 APC kernel: [ 15.222336] FS: 7f64dcc796c0()
GS:988aafc4() knlGS:
Jul 2 19:19:22 APC kernel: [ 15.222338] CS: 0010 DS:  ES:  CR0:
80050033
Jul 2 19:19:22 APC kernel: [ 15.222339] CR2: 7f64d4d65010 CR3:
00020f29 CR4: 06e0
Jul 2 19:19:22 APC kernel: [ 15.222341] Call Trace:
Jul 2 19:19:22 APC kernel: [ 15.222346] __check_object_size+0x9c/0x1a0
Jul 2 19:19:22 APC kernel: [ 15.222581] os_memcpy_to_user+0x21/0x40 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.222759] _nv009377rm+0xbf/0xe0 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.222918] ? _nv028067rm+0x79/0x90 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.223077] ? _nv028067rm+0x55/0x90 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.223227] ? _nv013694rm+0xee/0x100 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.223377] ? _nv015342rm+0x154/0x270 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.223552] ? _nv008310rm+0x134/0x1a0 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.223727] ? _nv008289rm+0x29c/0x2b0 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.223903] ? _nv001072rm+0xe/0x20 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.224080] ? _nv007316rm+0xd8/0x100 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.224236] ? _nv001171rm+0x627/0x830 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.224388] ? rm_ioctl+0x73/0x100 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.224499] ? nvidia_ioctl+0xf0/0x720 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.224609] ? nvidia_ioctl+0x519/0x720 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.224613] ? kmem_cache_free+0x19c/0x1d0
Jul 2 19:19:22 APC kernel: [ 15.224722] ?
nvidia_frontend_unlocked_ioctl+0x3e/0x50 [nvidia]
Jul 2 19:19:22 APC kernel: [ 15.224725] ? do_vfs_ioctl+0xa4/0x630
Jul 2 19:19:22 APC kernel: [ 15.224727] ? __fput+0x164/0x1e0
Jul 2 

Bug#902877: global: Missing source file for gtags.elc in site-lisp dir

[Daniel Gröber]

Package: global
Version: 6.6.2-2+b1
Severity: minor
Tags: patch

Emacs expects the source for byte-compiled files to be in the same
directory. If this is not the case `M-x find-function` is broken and
`M-x describe-function` doesn't display a link to the package source
code.

The `debian/global.emacsen-install` file seems to remove all *.el
files in the aforementioned directory (excerpt): 

# remove the redundant .el files
# presumes that any .el files in the  dir are trash.
rm ${elc_dir}/*.el

If I remove this line the everything works as expected. I do see how
without this line files might accumulate in the $elc_dir if the set of
*.el files shipped by upstream changes.

Thus I suggest just cleaning up $elc_dir before copying/compiling the
*.el files into it (patch attached).

--Daniel

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

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

Versions of packages global depends on:
ii  emacsen-common  2.0.8
ii  libc6   2.27-3
ii  libltdl72.4.6-2.1
ii  libncurses6 6.1+20180210-4
ii  libtinfo6   6.1+20180210-4

Versions of packages global recommends:
ii  python  2.7.15-3

Versions of packages global suggests:
ii  chromium [www-browser]  67.0.3396.79-2
ii  doxygen 1.8.13-10
ii  elinks [www-browser]0.12~pre6-13
ii  exuberant-ctags 1:5.9~svn20110310-12
ii  firefox [www-browser]   60.0.2-1
pn  id-utils
ii  lynx [www-browser]  2.8.9pre.1-1
ii  python-pygments 2.2.0+dfsg-1
ii  w3m [www-browser]   0.5.3-36+b1

-- no debconf information
>From 6be64a2b67fa862afd65eabb5b3f34e10ce36f83 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Gr=C3=B6ber?= 
Date: Mon, 2 Jul 2018 19:32:58 +0200
Subject: [PATCH] emacsen: Don't remove *.el files from site-lisp dir

Emacs expects the source for byte-compiled files to be in the same
directory. If this is not the case `M-x find-function` is broken and
`M-x describe-function` doesn't display a link to the package source
code.
---
 debian/global.emacsen-install | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/global.emacsen-install b/debian/global.emacsen-install
index 09327b3..c7108d6 100644
--- a/debian/global.emacsen-install
+++ b/debian/global.emacsen-install
@@ -14,16 +14,16 @@ if [ ${FLAVOR} != emacs ]
 then
echo install/${PACKAGE}: byte-compiling for ${FLAVOR}
 
-   # Copy the temp .el files
install -m 755 -d ${elc_dir}
+
+# remove the redundant files
+   rm ${elc_dir}/*.el ${elc_dir}/*.elc
+
+   # Copy the temp .el files
cp ${el_path_list} ${elc_dir}
 
# Byte compile them
${FLAVOR} ${byte_compile_options} ${elc_path_list}
-
-   # remove the redundant .el files
-   # presumes that any .el files in the  dir are trash.
-   rm ${elc_dir}/*.el
 fi
 exit 0;
 
-- 
2.17.1

Bug#874526: Keyboard grab doesn't work under Wayland

[Simon McVittie]

On Wed, 06 Sep 2017 at 14:58:37 -0700, Josh Triplett wrote:
> (It might also help to add Ctrl-Alt-Delete to the list of shortcuts
> provided in the gnome-boxes keyboard menu, alongside Ctrl-Alt-Backspace
> and similar.)

This is now provided in the keyboard menu for both gnome-boxes and
virt-manager.

smcv

Bug#902876: wordpress: CVE-2018-12895

[Salvatore Bonaccorso]

Source: wordpress
Version: 4.9.5+dfsg1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for wordpress.

CVE-2018-12895[0]:
| WordPress through 4.9.6 allows Author users to execute arbitrary code
| by leveraging directory traversal in the wp-admin/post.php thumb
| parameter, which is passed to the PHP unlink function and can delete
| the wp-config.php file. This is related to missing filename validation
| in the wp-includes/post.php wp_delete_attachment function. The attacker
| must have capabilities for files and posts that are normally available
| only to the Author, Editor, and Administrator roles. The attack
| methodology is to delete wp-config.php and then launch a new
| installation process to increase the attacker's privileges.

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-12895
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12895
[1] https://blog.ripstech.com/2018/wordpress-file-delete-to-code-execution/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#875728: Patch for multi-arch builds

[Simon McVittie]

On Mon, 02 Jul 2018 at 11:02:40 +, Hugh McMaster wrote:
> As of last weekend, no packages in Debian call `dh_gtkmodules' anymore.
> 
> So, we are free to make libgtk2.0-dev and its dependencies multi-arch 
> installable.
> 
> A patch is attached.

Thanks, trying this out now.

smcv

Bug#902875: postgresql-common: systemd warning message: Line references path below legacy directory /var/run/

[Francois Marier]

Package: postgresql-common
Version: 191
Severity: normal

Once a day, I get the following systemd warning message in my logs:

  Jul  1 20:50:01 hostname systemd-tmpfiles[21472]: 
[/usr/lib/tmpfiles.d/postgresql.conf:2] Line references path below legacy 
directory /var/run/, updating /var/run/postgresql → /run/postgresql; please 
update the tmpfiles.d/ drop-in file accordingly.

Here's the contents of /usr/lib/tmpfiles.d/postgresql.conf:

  # Directory for PostgreSQL sockets, lockfiles and stats tempfiles
  d /var/run/postgresql 2775 postgres postgres - -
  # Log directory
  d /var/log/postgresql 1775 root postgres - -

Francois

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

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

Versions of packages postgresql-common depends on:
ii  adduser   3.117
ii  debconf [debconf-2.0] 1.5.67
ii  lsb-base  9.20170808
ii  postgresql-client-common  191
ii  procps2:3.3.15-2
ii  ssl-cert  1.0.39
ii  ucf   3.0038

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.44.2-1
ii  logrotate  3.11.0-0.1

Versions of packages postgresql-common suggests:
ii  libjson-perl  2.97001-1

-- debconf information:
* postgresql-common/obsolete-major:
  postgresql-common/catversion-bump:
* postgresql-common/ssl: false

Bug#874526: Keyboard grab doesn't work under Wayland

[Simon McVittie]

Control: retitle -1 Keyboard grab doesn't (always?) work under Wayland
Control: reopen -1
Control: tags -1 + moreinfo

On Mon, 02 Jul 2018 at 01:39:24 -0700, Josh Triplett wrote:
> On Mon, Jul 02, 2018 at 08:14:48AM +0100, Simon McVittie wrote:
> > This seems to work under GNOME 3.28 (probably also 3.26). I'm prompted
> > while starting up the VM for whether to allow gnome-boxes to grab the
> > keyboard. I haven't tried a Windows VM, but if I use the keyboard menu to
> > switch to a text-mode VT for a Linux VM with Ctrl+Alt+F$n, then either
> > press Ctrl+Alt+Del or send it via the keyboard menu, the VM reboots
> > as expected.
> 
> I can confirm that I can still reproduce this with current GNOME and
> gnome-boxes; Ctrl+Alt+Del still goes to GNOME and not to the VM.

Which versions of gnome-shell, libmutter-2-0, gnome-boxes do you have?

Are you prompted for whether to let gnome-boxes inhibit shortcuts? You
should get a system-modal dialog (the sort that dims the entire screen,
like the Shut Down dialog you get from Ctrl+Alt+Del itself) something
like this:

|--|
|  Boxes wants to inhibit shortcuts|
| /!\  |
|  You can restore shortcuts by pressing Super+Escape. |
|  |
|[ Deny ][ Allow ]-|

(If you don't click Allow then this feature is not expected to work.)

Does it help to click inside the virtual machine window before pressing
Ctrl+Alt+Del?

If you try using virt-manager instead of gnome-boxes (the same machines
should appear in both), does that work any better?

Does sending Ctrl+Alt+Del via the keyboard menu work?

Thanks,
smcv

Bug#902874: samba: Samba package whithout startup files

[Frank Sell]

Package: samba
Version: 2:4.8.2+dfsg-2
Severity: important

Dear Maintainer,

fresh install Debian Buster.

I installed samba using 'apt install samba' accepting the default.

samba  2:4.8.2+dfsg amd64

Files /etc/init.d/samba and /lib/systemd/system/samba.service are not included.

Here a snippet from dpkg -L samba:

...
/etc/init.d
/etc/init.d/nmbd
/etc/init.d/samba-ad-dc
/etc/init.d/smbd
...
/lib/systemd
/lib/systemd/system
/lib/systemd/system/nmbd.service
/lib/systemd/system/samba-ad-dc.service
/lib/systemd/system/smbd.service
...




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

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

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


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

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

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

Versions of packages samba depends on:
ii  adduser   3.117
ii  dpkg  1.19.0.5+b1
ii  libattr1  1:2.4.47-2+b2
ii  libbsd0   0.9.1-1
ii  libc6 2.27-3
ii  libldb1   2:1.3.3-1
ii  libpam-modules1.1.8-3.7
ii  libpam-runtime1.1.8-3.7
ii  libpopt0  1.16-11
ii  libpython2.7  2.7.15-1
ii  libtalloc22.1.11-2
ii  libtdb1   1.3.15-4
ii  libtevent00.9.36-2
ii  lsb-base  9.20170808
ii  procps2:3.3.15-2
ii  python2.7.15-3
ii  python-dnspython  1.15.0-1
ii  python-samba  2:4.8.2+dfsg-2
ii  python2.7 2.7.15-1
ii  samba-common  2:4.8.2+dfsg-2
ii  samba-common-bin  2:4.8.2+dfsg-2
ii  samba-libs2:4.8.2+dfsg-2
ii  tdb-tools 1.3.15-4

Versions of packages samba recommends:
ii  attr1:2.4.47-2+b2
ii  logrotate   3.11.0-0.1
ii  samba-dsdb-modules  2:4.8.2+dfsg-2
ii  samba-vfs-modules   2:4.8.2+dfsg-2

Versions of packages samba suggests:
ii  bind9  1:9.11.3+dfsg-2
ii  bind9utils 1:9.11.3+dfsg-2
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p11+dfsg-1
pn  smbldap-tools  
pn  ufw
pn  winbind

-- no debconf information

Bug#902853: ldap-utils: Logfile warnings after upgrade to 2.4.40+dfsg-1+deb8u4

[Ryan Tandy]

Hi Stefan,

On Mon, Jul 02, 2018 at 12:26:08PM +0200, Stefan van Lieshout wrote:

The upgrade to 2.4.40+dfsg-1+deb8u4 results in a lot of warnings in the logfile 
/var/log/auth.log

Jul  2 09:27:43 hostname apache2: ldapdb_canonuser_plug_init() failed in 
sasl_canonuser_add_plugin(): invalid parameter supplied
Jul  2 09:27:43 hostname apache2: _sasl_plugin_load failed on 
sasl_canonuser_init for plugin: ldapdb

This is not only for the apache2 process, also sssd_be, sm-mta & php spawn the 
same warnings.

A downgrade to 2.4.40+dfsg-1+deb8u3 did solve the issue.


Thank you for the report. Indeed one thing that changed in this version 
is that libldap now initializes libsasl eagerly, instead on on first 
use, so previously these messages might have only appeared when a 
process invoked SASL via LDAP - or not at all.


You are the first to mention an issue like this, though, so I wonder if 
it's caused by a local configuration on your side.


Is your libsasl2-modules-ldap up-to-date with libsasl2-2? What do you 
use it for?

Bug#901089: dosbox 0.74-4.2+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: dosbox
Version: 0.74-4.2+deb9u1

Explanation: fix crashes with core=dynamic

Bug#894713: apache2 2.4.25-3+deb9u5 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: apache2
Version: 2.4.25-3+deb9u5

Explanation: upgrade mod_http and mod_proxy_http2 to the versions from 2.4.33, 
fixing segfaults, high memory usage and potential crash [CVE-2018-1302]; make 
the apache-htcacheclean init script actually use 
/etc/default/apache-htcacheclean for its config

Bug#891590: sbuild: Please signalize autopkgtest failure by exit code, at least optionally

[Christoph Biedl]

Johannes Schauer wrote...

> So in light of this, I instead opted for introducing three new configuration
> variables. With sbuild from git you can now set:
>
> $lintian_require_success = 1;
> $piuparts_require_success = 1;
> $autopkgtest_require_success = 1;
>
> Sbuild will then exit with a non-zero exit status if any of these three fail.
>
> Does this sound good to you?

Thanks a lot, I'm fine with this as it's the "at least as an option"
way. Just a small thing, if I understand correctly, this change will not
provide command-line options to control the behaviour. Having these was
last refinement though as I'll use this feature in any automated setup
where I have to maintain a configuration file anyway.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#901331: ganeti 2.15.2-7+deb9u2 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ganeti
Version: 2.15.2-7+deb9u2

Explanation: properly verify SSL certificates during VM export

Bug#897923: tclreadline 2.1.0-15+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: tclreadline
Version: 2.1.0-15+deb9u1

Explanation: fix shared library build on ppc64el

Bug#902872: sagemath: sage fails to start with 'undefined symbol acb_calc_integrate error

[Rann Bar-On]

Package: sagemath
Version: 8.2-5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

see sage crash log below.

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

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

Versions of packages sagemath depends on:
ii  cysignals-tools  1.6.7+ds-1
ii  cython   0.28.2-4
ii  ecl  16.1.2-4+b1
ii  eclib-tools  20171002-1+b2
ii  f2c  20160102-1
ii  fflas-ffpack 2.3.2-2
ii  flintqs  1:1.0-1+b1
ii  gap-core 4r8p8-3
ii  gfan 0.5+dfsg-6
ii  gmp-ecm  7.0.4+ds-2
ii  ipython  5.5.0-1
ii  iso-codes3.79-1
ii  jmol 14.6.4+2016.11.05+dfsg1-3.1
ii  lcalc1.23+dfsg-6+b1
ii  less 487-0.1+b1
ii  libatlas3-base [liblapack.so.3]  3.10.3-7
ii  libblas3 [libblas.so.3]  3.8.0-1
ii  libbrial-groebner3   1.2.0-2
ii  libbrial31.2.0-2
ii  libc62.27-3
ii  libcdd-tools 094h-1+b1
ii  libcliquer1  1.21-2
ii  libec3   20171002-1+b2
ii  libecm1  7.0.4+ds-2
ii  libflint-2.5.2   2.5.2-18
ii  libflint-arb22.11.1-2+b1
ii  libgap-sage-44.8.8+3+20160327g69a66f0+dsx-1
ii  libgcc1  1:8.1.0-9
ii  libgd3   2.2.5-4
ii  libgivaro9   4.0.4-2
ii  libglpk404.65-2
ii  libgmp10 2:6.1.2+dfsg-3
ii  libgmpxx4ldbl2:6.1.2+dfsg-3
ii  libgsl23 2.5+dfsg-4
ii  libgslcblas0 2.5+dfsg-4
ii  libiml0  1.0.4-1+b2
ii  libjs-mathjax2.7.4+dfsg-1
ii  libjs-three  80+dfsg2-2
ii  liblapack3 [liblapack.so.3]  3.8.0-1
ii  liblfunction01.23+dfsg-6+b1
ii  liblinbox-1.5.2-01.5.2-1
ii  liblinboxsage-1.5.2-01.5.2-1
ii  liblrcalc1   1.2-2+b1
ii  libm4ri-0.0.20140914 20140914-2+b1
ii  libm4rie-0.0.2015090820150908-1
ii  libmpc3  1.1.0-1
ii  libmpfi0 1.5.3+ds-2
ii  libmpfr6 4.0.1-1
ii  libntl35 10.5.0-2
ii  libpari-gmp-tls5 2.9.5-1
ii  libplanarity03.0.0.5-1+b1
ii  libpng16-16  1.6.34-1
ii  libppl14 1:1.2-3
ii  libpynac17   0.7.19-2
ii  libratpoints-2.1.3   1:2.1.3-1+b2
ii  libreadline7 7.0-5
ii  librw0   0.8+ds-1
ii  libsingular4 1:4.1.0-p3+ds-2+b3
ii  libstdc++6   8.1.0-9
ii  libsymmetrica2   2.0+ds-5
ii  libzn-poly-0.9   0.9-3+b2
ii  maxima-sage  5.39.0+ds-3
ii  maxima-sage-doc  5.39.0+ds-3
ii  maxima-sage-share5.39.0+ds-3
ii  nauty2.6r10+ds-1
ii  octave   4.4.0-3
ii  palp 2.1-4
ii  pari-doc 2.9.5-1
ii  pari-galdata 0.20080411-2
ii  pari-gp  2.9.5-1
ii  pari-seadata   

Bug#902871: xrdp: virtual desktop something with size/tile/too small

[Thorsten Glaser]

Package: xrdp
Version: 0.9.6-1
Severity: important

$ rdesktop -g 1200x900 localhost
Connection established using plain RDP.
NOT IMPLEMENTED: RDPDR pakid 0x554c of component 0x4472

And then I get… see screenshot.

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

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

Versions of packages xrdp depends on:
ii  adduser  3.117
ii  libc62.27-3
ii  libfuse2 2.9.7-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopus0 1.3~beta+20180518-1
ii  libpam0g 1.1.8-3.7
ii  libssl1.11.1.0h-4
ii  libx11-6 2:1.6.5-1
ii  libxfixes3   1:5.0.3-1
ii  libxrandr2   2:1.5.1-1
ii  lsb-base 9.20170808
ii  ssl-cert 1.0.39

Versions of packages xrdp recommends:
ii  fuse  2.9.7-1
ii  xorgxrdp  1:0.2.6-1+b1

Versions of packages xrdp suggests:
pn  guacamole  
pn  xrdp-pulseaudio-installer  

Versions of packages xorgxrdp depends on:
ii  libc6  2.27-3
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.0-2

Versions of packages xorgxrdp recommends:
pn  xorg  

Versions of packages xrdp is related to:
pn  vnc-server   
ii  xserver-xorg-legacy  2:1.20.0-2

-- no debconf information

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 02/07/2018 à 17:52, Thorsten Glaser a écrit :

> How do I reproduce this with Java 8, anyway?

You can't, the --release option appeared in Java 9.

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Mon, 2 Jul 2018, Emmanuel Bourg wrote:

> Someone has a better idea?

OK, since the last one was impracticable:

Revert default-jdk to 8 until these all are fixed.
(Since the internal APIs are, well, internal, they
all ought to be fixed by their respective upstreams
*anyway* AIUI.)

Or, perhaps better: Use --release, and for those
packages that fail with it, use an explicit B-D
on openjdk-8-jdk instead of default-jdk until that
individual package is fixed. But keep the default
at newer JDK plus --release to ensure the amount
of to-be-fixed packages does not grow in the meantime.

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

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Mon, 2 Jul 2018, Emmanuel Bourg wrote:

> Base64 is easy, but sun.misc.Unsafe is another story. It's widely used

OIC. I haven’t run into that one yet.

How do I reproduce this with Java 8, anyway?

tglase@tglase:~ $ javac --release 1.8
javac: invalid flag: --release
Usage: javac  
use -help for a list of possible options

Despite http://openjdk.java.net/jeps/247 indicating
it should be supported.

(If for nothing else, then to see whether there are
any Sun-internal class uses left by breaking the build.)

Thanks,
//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

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 02/07/2018 à 17:32, Thorsten Glaser a écrit :

> Patch code that uses those internal APIs. This is what we do here™
> as well, ever since we could require Java 8 at the customers’ sites.
> It’s been easy so far as most of the time it was just base64.

Base64 is easy, but sun.misc.Unsafe is another story. It's widely used
and its replacement (VarHandle [1]) requires Java 9+. So even if it
builds with OpenJDK 10, it still won't work with Java 8.

[1] http://openjdk.java.net/jeps/193

Bug#902869: cookiecutter binary: Should depend on python-cookiecutter | python3-cookiecutter

[Joel Cross]

Source: cookiecutter
Severity: normal

Dear Maintainer,

Thanks for building a Python 3 version of this package. However, when
attempting to install the cookiecutter binary, I noticed it still depends on
the Python 2 library.
If memory serves correctly, it is possible to change the 'Depends' line to
support either Python 2 or Python 3 version of the package, by changing the
following:

Depends: ... python-cookiecutter (= version) ...

to this:

Depends: ... python-cookiecutter (= version) | python3-cookiecutter (= version)
...



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

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

Bug#902870: installation-report: DI grub-install should use UUIDs instead of plain disk-device-names

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Package: installation-reports
Version: 2.68
Severity: minor

Dear Maintainer,

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

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

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


- -- Package-specific info:

Boot method: USB
Image version:
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
I tried the latest current netinstall-image first from today, which supported
only FAT-filesystems and showed an error-message about LVM-modules, then used
this older one instead:
- -rw-r--r-- 1 andrew andrew 359661568 Jun 18 06:45
debian-testing-amd64-netinst.iso.1
Date:
2018-07-02, about 16.00 h

Machine: DELL optiplex 580 SFF
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   1845144   0   1845144   0% /dev
tmpfs  tmpfs   3782565348372908   2% /run
/dev/sda2  btrfs 27343872 1012164  24294364   4% /
tmpfs  tmpfs  1891280   0   1891280   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs  1891280   0   1891280   0% /sys/fs/cgroup
/dev/sda1  ext4463826   43172392187  10% /boot
tmpfs  tmpfs   378256   0378256   0% /run/user/0
tmpfs  tmpfs   378256   0378256   0% /run/user/1000

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o]
Detect network card:[o]
Configure network:  [o]
Detect CD:  []
Load installer modules: [Eo]
Clock/timezone setup:   [o]
User/password setup:[o]
Detect hard drives: [o]
Partition hard drives:  [Eo]
Install base system:[o]
Install tasks:  [o]
Install boot loader:[e]
Overall install:[O ]

Comments/Problems:

This is a quite compact PC, my former build- and virt-server,  for my
sponsoring family, who enabled me to do what I am interested in myself
_all_of_the_time_, without being too poor and too limited financially. It is
going to run with Ubuntu-Mate 18.04 LTS, should work according to my
estimation, low-profile USB3 controller-card was added (recommended).
First problem I encountered, was that the PC was by default equipped with a
non-linux haddrive, it just would not boot the kernel with GRUB, but simply
blocked and did nothing at all or threw error-messages, a System from the
Vista-era, the original disk was: MDL: WD1600AAJS - 75M0A0, S/N: WD -
WMAV3D340689
The disk was replaced with a smaller Seagate-disk, which resolved the
boot-issue, works just fine now.
Because of the boot-problems I fell back to Debian stable 9.4 and found there
is still the problem of missing flexibility, like in this case, when there is
no harddisk-boot possible, one would like to boot from USB-disk instead, but
this becomes problematic, when you install from USB onto another USB-disk, I
mentioned the problem in an earlier report already.
If you remove the installation-medium, the device-name of the second
USB-disk changes, so GRUB will not boot anymore, one has to work around the
issue by editing the menu-entry manually say change the root-partition from
sdc1 to sdb1, then upon successful boot run update-grub, so the change
becomes permanent (or run update-grub as root before removing the
install-disk).
So it is possible to work around, but too complicated for most people,
please try to fix this for the upcoming Buster-release.
 


- -- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20180614-00:06"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27)
x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro
Devices, Inc. [AMD] RS880 Host Bridge [1022:9601] lspci -knn: Subsystem:
Dell Device [1028:0433] lspci -knn: 00:01.0 PCI bridge [0604]: Dell Device
[1028:9602] lspci -knn: 00:04.0 PCI bridge [0604]: Advanced Micro Devices,
Inc. [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 0) [1022:9604] lspci
- -knn: Kernel driver in use: pcieport lspci -knn: 00:09.0 PCI bridge
[0604]: Advanced Micro Devices, Inc. [AMD] RS780/RS880 

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Mon, 2 Jul 2018, Emmanuel Bourg wrote:

> revert the use of the --release option in Ant/Maven. That would mean the
> packages built with OpenJDK 10/11 are unlikely to run with OpenJDK 8
> (the binary incompatibility in the ByteBuffer class affects quite a lot
> of code).

Ouch, that would hurt. (Especially considering that 8 is still
a candidate for default-jdk in buster.)

> Someone has a better idea?

Patch code that uses those internal APIs. This is what we do here™
as well, ever since we could require Java 8 at the customers’ sites.
It’s been easy so far as most of the time it was just base64.

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

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 13/04/2018 à 17:14, Tiago Stürmer Daitx a écrit :

> plexus-compiler currently will default -source and/or -target to 1.7
> whenever the following occours:
> 1) whenever either has not being set
> 2) whenever either has been set to 1.6 or earlier
> 
> This patch modifies the detection logic in order to be able to set the
> '--release' flag when (and only when):
> - the '--release' is *not* set
> - AND both -source and -target are being set to a default value
> - AND the running jvm is jdk9 or newer
> 
> This prevents errors such as the infamous "Method
> flip()Ljava/nio/ByteBuffer; does not exist in class java.nio.ByteBuffer"
> that is caused by building with openjdk-9 with -source set without
> setting the proper bootclasspath [1,2]. JEP-247 [3] has provided the
> --release to prevent such issues and should be used instead of -source
> whenever the javac being used is jdk9 or higher.

Setting the --release option automatically is now implemented in Maven
(since plexus-compiler/2.8.4-1) and Ant (since ant/1.10.3-2), and it
triggers a new issue unfortunately. When the --release option is set the
internal JDK APIs (com.sun.*, sun.misc.*) are no longer available, and
this breaks several packages (axis for example, see #902861). The same
code compiles fine with '-source  -target ' though.

I'm not sure we can fix all the errors reported and we may have to
revert the use of the --release option in Ant/Maven. That would mean the
packages built with OpenJDK 10/11 are unlikely to run with OpenJDK 8
(the binary incompatibility in the ByteBuffer class affects quite a lot
of code).

Someone has a better idea?

Emmanuel Bourg

Bug#685403: snd_config_expand) Unknown parameters 0

[Bernhard Schmidt]

Am 02.07.2018 um 17:10 schrieb ael via Pkg-voip-maintainers:

Dear ael (?),

> This bug is 6 years old and no reply. Has linphone been abandoned?

We're still waiting for a transition slot to upload the current linphone
into unstable. The linphone in Debian stable/unstable is extremely old.
The current version (3.12) is packaged in experimental.

Bernhard

Bug#685403: snd_config_expand) Unknown parameters 0

[ael]

This bug is 6 years old and no reply. Has linphone been abandoned?

Anyway, exactly the smae thing is still happening:


$ linphonec
ALSA lib conf.c:5001:(snd_config_expand) Unknown parameters 0
ALSA lib control.c:1373:(snd_ctl_open_noupdate) Invalid CTL default:0
ALSA lib conf.c:5001:(snd_config_expand) Unknown parameters 1
ALSA lib control.c:1373:(snd_ctl_open_noupdate) Invalid CTL default:1
ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

Linphone has only worked once on Debian, many years ago. I have always
had to give up and turn to ekiga before.

I had hoped that it might have been fixed meanwhile, but it seems not
:-(

Bug#902868: linux-image-4.16.0-2-amd64 fails to boot

[Andy Wood]

Package: src:linux
Version: 4.16.16-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation?

Up to date Debian testing on 2 July 2018
apt-get update
apt-get upgrade
   linux-image-4.16.0-2-amd64 updated (I think)
reboot

   * What was the outcome of this action?

System did not boot
Re-booted into previous kernel version and reviewed system logs
The following seems to indicate the fault:

Jul  2 09:04:31 kernel: [   15.055880] [ cut here ]
Jul  2 09:04:31 kernel: [   15.055881] kernel BUG at 
/build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!
Jul  2 09:04:31 kernel: [   15.055888] invalid opcode:  [#1] SMP PTI
Jul  2 09:04:31 kernel: [   15.055890] Modules linked in: intel_rapl sb_edac 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm snd_hda_codec_hdmi 
irqbypass iTCO_wdt iTCO_vendor_support crct10dif_pclmul crc32_pclmul mxm_wmi 
evdev ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf pcspkr 
serio_raw snd_hda_codec_realtek snd_hda_codec_generic sg lpc_ich snd_hda_intel 
snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer ioatdma snd mei_me mei 
soundcore shpchp dca wmi button nvidia_drm(PO) drm_kms_helper drm 
nvidia_modeset(PO) nvidia(PO) ipmi_devintf ipmi_msghandler parport_pc ppdev lp 
parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic 
fscrypto ecb sr_mod cdrom sd_mod hid_generic usbhid hid crc32c_intel ahci isci 
aesni_intel libahci libsas aes_x86_64 crypto_simd cryptd glue_helper psmouse
Jul  2 09:04:31 kernel: [   15.055943]  sym53c8xx scsi_transport_spi xhci_pci 
i2c_i801 libata ehci_pci xhci_hcd ehci_hcd scsi_transport_sas e1000e usbcore 
scsi_mod usb_common
Jul  2 09:04:31 kernel: [   15.055954] CPU: 2 PID: 1184 Comm: Xorg Tainted: P   
O 4.16.0-2-amd64 #1 Debian 4.16.16-2
Jul  2 09:04:31 kernel: [   15.055956] Hardware name: Viglen VIG430P/X9DAL, 
BIOS 3.0 01/02/2014
Jul  2 09:04:31 kernel: [   15.055963] RIP: 0010:usercopy_abort+0x69/0x80
Jul  2 09:04:31 kernel: [   15.055965] RSP: 0018:b81543c9bb50 EFLAGS: 
00010282
Jul  2 09:04:31 kernel: [   15.055967] RAX: 006f RBX: 
0003 RCX: 
Jul  2 09:04:31 kernel: [   15.055969] RDX:  RSI: 
8d90ffd16738 RDI: 8d90ffd16738
Jul  2 09:04:31 kernel: [   15.055971] RBP: 0003 R08: 
03ac R09: 0004
Jul  2 09:04:31 kernel: [   15.055972] R10: ad877e48 R11: 
adfa8dcd R12: 0001
Jul  2 09:04:31 kernel: [   15.055974] R13: 8d90d828dcb3 R14: 
 R15: 8d90d828dcf8
Jul  2 09:04:31 kernel: [   15.055977] FS:  7f841b5f96c0() 
GS:8d90ffd0() knlGS:
Jul  2 09:04:31 kernel: [   15.055979] CS:  0010 DS:  ES:  CR0: 
80050033
Jul  2 09:04:31 kernel: [   15.055981] CR2: 7f8413711010 CR3: 
0004583c8005 CR4: 000606e0
Jul  2 09:04:31 kernel: [   15.055982] Call Trace:
Jul  2 09:04:31 kernel: [   15.055992]  __check_heap_object+0xe7/0x120
Jul  2 09:04:31 kernel: [   15.055995]  __check_object_size+0x9c/0x1a0
Jul  2 09:04:31 kernel: [   15.056199]  os_memcpy_to_user+0x21/0x40 [nvidia]
Jul  2 09:04:31 kernel: [   15.056416]  _nv009377rm+0xbf/0xe0 [nvidia]
Jul  2 09:04:31 kernel: [   15.056600]  ? _nv028067rm+0x79/0x90 [nvidia]
Jul  2 09:04:31 kernel: [   15.056780]  ? _nv028067rm+0x55/0x90 [nvidia]
Jul  2 09:04:31 kernel: [   15.056950]  ? _nv013694rm+0xee/0x100 [nvidia]
Jul  2 09:04:31 kernel: [   15.057120]  ? _nv015342rm+0x154/0x270 [nvidia]
Jul  2 09:04:31 kernel: [   15.057336]  ? _nv008310rm+0x134/0x1a0 [nvidia]
Jul  2 09:04:31 kernel: [   15.057548]  ? _nv008289rm+0x29c/0x2b0 [nvidia]
Jul  2 09:04:31 kernel: [   15.057759]  ? _nv001072rm+0xe/0x20 [nvidia]
Jul  2 09:04:31 kernel: [   15.057972]  ? _nv007316rm+0xd8/0x100 [nvidia]
Jul  2 09:04:31 kernel: [   15.058181]  ? _nv001171rm+0x627/0x830 [nvidia]
Jul  2 09:04:31 kernel: [   15.058389]  ? rm_ioctl+0x73/0x100 [nvidia]
Jul  2 09:04:31 kernel: [   15.058507]  ? nvidia_ioctl+0xf0/0x720 [nvidia]
Jul  2 09:04:31 kernel: [   15.058623]  ? nvidia_ioctl+0x519/0x720 [nvidia]
Jul  2 09:04:31 kernel: [   15.058627]  ? kmem_cache_free+0x19c/0x1d0
Jul  2 09:04:31 kernel: [   15.058743]  ? 
nvidia_frontend_unlocked_ioctl+0x3e/0x50 [nvidia]
Jul  2 09:04:31 kernel: [   15.058746]  ? do_vfs_ioctl+0xa4/0x630
Jul  2 09:04:31 kernel: [   15.058750]  ? __audit_syscall_entry+0xbc/0x110
Jul  2 09:04:31 kernel: [   15.058754]  ? syscall_trace_enter+0x1df/0x2e0
Jul  2 09:04:31 kernel: [   15.058757]  ? SyS_ioctl+0x74/0x80
Jul  2 09:04:31 kernel: [   15.058760]  ? do_syscall_64+0x6c/0x130
Jul  2 09:04:31 kernel: [   15.058764]  ? 
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Jul  2 09:04:31 kernel: [   15.058767] Code: 0f 44 d0 53 48 c7 c0 41 de 83 ad 
51 48 c7 c6 dd d3 82 ad 41 53 48 89 f9 48 0f 45 f0 4c 89 d2 48 c7 c7 28 df 83 
ad e8 f1 2e ea ff <0f> 0b 49 c7 c1 ac de 84 ad 4d 89 cb 4d 

Bug#902867: transition: ros-ros-comm

[Jochen Sprickerhof]

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

Dear release team,

I would like to transition ros-ros-comm. I'm maintaining all depending
packages, so I will take care of any problems.

Note that the ben file on the website¹ seems somehow wrong, so I defined
a different set below. Hope that's right.

Context was that I pulled one package (ros-rosconsole) out of
ros-ros-comm and also had one intermediate experimental release in the
meantime, maybe that produced a hickup.

Cheers Jochen

¹: https://release.debian.org/transitions/html/auto-ros-ros-comm.html

Ben file:

title = "ros-ros-comm";
is_affected = .depends ~ /\b(librosbag-storage2d|libroscpp1d|libxmlrpcpp1d)\b/ 
| .depends ~ /\b(librosbag-storage3d|libroscpp2d|libxmlrpcpp2d)\b/;
is_good = .depends ~ /\b(librosbag-storage3d|libroscpp2d|libxmlrpcpp2d)\b/;
is_bad = .depends ~ /\b(librosbag-storage2d|libroscpp1d|libxmlrpcpp1d)\b/;


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

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

Bug#902866: flameshot: Will not run, exits with error "Could not connect to display"

[Prescott]

Package: flameshot
Version: 0.5.1+git20180601-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   Upgraded to testing from stable for help in bugs finding and for
   some newer packages I needed from Buster.

   I originally used my sxhkd keybinding "flameshot gui -p
   ~/path/to/file", and when the usual action of the gui selection
   screen did not appear, I ran flameshot gui through the terminal. The
   following is the error messages in syslog.
   
Jul  2 09:17:12 plaptop dbus-daemon[2082]: [session uid=1000 pid=2082] 
Activating service name='org.dharkael.Flameshot' requested by ':1.1310' 
(uid=1000 pid=22598 comm="flameshot gui ")
Jul  2 09:17:12 plaptop org.dharkael.Flameshot[2082]: qt.qpa.screen: 
QXcbConnection: Could not connect to display
Jul  2 09:17:12 plaptop org.dharkael.Flameshot[2082]: Could not connect to any 
X display.
Jul  2 09:17:12 plaptop dbus-daemon[2082]: [session uid=1000 pid=2082] 
Activated service 'org.dharkael.Flameshot' failed: Process 
org.dharkael.Flameshot exited with status 1
Jul  2 09:17:45 plaptop dbus-daemon[2082]: [session uid=1000 pid=2082] 
Activating service name='org.dharkael.Flameshot' requested by ':1.1315' 
(uid=1000 pid=23133 comm="flameshot gui ")
Jul  2 09:17:45 plaptop org.dharkael.Flameshot[2082]: qt.qpa.screen: 
QXcbConnection: Could not connect to display
Jul  2 09:17:45 plaptop org.dharkael.Flameshot[2082]: Could not connect to any 
X display.
Jul  2 09:17:45 plaptop dbus-daemon[2082]: [session uid=1000 pid=2082] 
Activated service 'org.dharkael.Flameshot' failed: Process 
org.dharkael.Flameshot exited with status 1
cat: m: No such file or directory

   The same QXcbConnection message appears when running a CLI command
   (e.g. flameshot screen -c).

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
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 flameshot depends on:
ii  libc6   2.27-3
ii  libgcc1 1:8.1.0-8
ii  libqt5core5a5.10.1+dfsg-7
ii  libqt5dbus5 5.10.1+dfsg-7
ii  libqt5gui5  5.10.1+dfsg-7
ii  libqt5network5  5.10.1+dfsg-7
ii  libqt5widgets5  5.10.1+dfsg-7
ii  libstdc++6  8.1.0-8

flameshot recommends no packages.

Versions of packages flameshot suggests:
ii  ca-certificates  20170717
ii  openssl  1.1.0h-4

-- no debconf information

Bug#902703: Acknowledgement (RFS: hw-probe/1.4-4-git20180614 [ITP])

[Михаил Новоселов]

I've fixed hw-probe in the same way as pulseeffects: 
https://mentors.debian.net/package/hw-probe


Is the version '1.4-5-git20180614' correct?

In hw-probe, I'd like to keep debian/compat 9 to allow building for 
older Ubuntu and Debian versions.

Bug#878274: linux-image-4.9.0-3-powerpc64le: Kernel hangs

[Nate R]

Ben

The crashes/hangs stopped once we moved our main filesystem off of btrfs to
xfs.

Thanks
--Nate

On Sat, Jun 30, 2018 at 8:18 PM Ben Hutchings  wrote:

> Control: tag -1 mreinfo
>
> On Wed, 11 Oct 2017 17:33:58 -0600 Nate R  wrote:
> > Package: src:linux
> > Version: 4.9.30-2+deb9u5
> > Severity: grave
> > Tags: upstream
> > Justification: renders package unusable
> >
> > Dear Maintainer,
> >
> >* What led up to the situation?
> > Production server. Was doing a large uncompress of a file.
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > Trigger for bug is unclear.
> >* What was the outcome of this action?
> > Had to reboot the node. All commands hung.
> >* What outcome did you expect instead?
> > Not to hang.
> [...]
>
> I'm sorry we didn't respond to this earlier.
>
> Have you seen a similar hang again?  If so, which version are you
> running now ("uname -v" will show this)?  Can you send a fresh log,
> including all the BUG and WARN messages?
>
> > ** Tainted: O (4096)
> >  * Out-of-tree module has been loaded.
> >
> > ** Kernel log:
> > [2335559.671011] WARNING: CPU: 0 PID: 0 at
> > /build/linux-ZRFL9M/linux-4.9.30/net/sched/sch_generic.c:316
> > dev_watchdog+0x380/0x390
> [...]
>
> Based on this warning message, I suspect this may be a bug in the
> Mellanox network drivers you were using, which are not part of this
> package.  But the network hang might be a symptom of an earlier
> failure.
>
> Are you able to use the in-tree drivers for this hardware?
>
> Ben.
>
> --
> Ben Hutchings
> Q.  Which is the greater problem in the world today,
> ignorance or apathy?
> A.  I don't know and I couldn't care less.
>
>

Bug#902865: ITP: libcode-tidyall-plugin-yamlfrontmatter-perl -- module to validate YAML front matter

[Laurent Baillet]

Package: wnpp
Severity: wishlist
Owner: Laurent Baillet 

* Package name: libcode-tidyall-plugin-yamlfrontmatter-perl
  Version : 1.01
  Upstream Author : Mark Fowler 
* URL : 
https://metacpan.org/pod/Code::TidyAll::Plugin::YAMLFrontMatter
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to validate YAML front matter

 Code::TidyAll::Plugin::YAMLFrontMatter acts as a plugin to Code::TidyAll and
 validates front matter in YAML files. It can check its existence, its
 validity, its encoding and its mandatory top level keys.

I will package it within the Debian Perl Team.

Bug#891590: sbuild: Please signalize autopkgtest failure by exit code, at least optionally

[Johannes Schauer]

Control: tag -1 + pending

Hi,

On Mon, 26 Feb 2018 22:04:10 +0100 Christoph Biedl 
 wrote:
> trying to use to autopkgtest feature of sbuild I was somewhat surprised
> to learn there is no way to signalize a failing autopkgtest to the
> sbuild caller. I'd expect to have something like
> 
> --- a/lib/Sbuild/Build.pm
> +++ b/lib/Sbuild/Build.pm
> @@ -1845,6 +1845,7 @@ sub run_autopkgtest {
>  } else {
>   # fail if neither all tests passed nor was the package without tests
>   $self->log_error("Autopkgtest run failed.\n");
> + $self->set_status("failed");
>   return 0;
>  }
>  
> 
> at least as an option like --fail-from-failing-autopkgtest. So it seems
> the only way was to inspect the build log. This doesn't seem right.
> 
> Did I miss something? Else, please take this as a feature request. Also
> likewise for piuparts.

and probably also for lintian?

While I sympathize with the idea of letting sbuild fail when the stuff it runs
fails, I was met with strong opposition when I asked for opinions about this in
#debian-devel and I was convinced that it would not be right for sbuild to fail
if autopkgtest, piuparts or lintian fail. Arguments:

 - people run sbuild for building not for the other stuff it does even though
   it's nice to have that other stuff (lintian, autopkgtest, piuparts) in the
   build log

 - thus, it would be wrong for sbuild to fail for anything other than the
   package build itself failing

 - sbuild is already the wrong layer for running lintian, piuparts and
   autopkgtest. That should instead be done by a tool above sbuild.

So in light of this, I instead opted for introducing three new configuration
variables. With sbuild from git you can now set:

$lintian_require_success = 1;
$piuparts_require_success = 1;
$autopkgtest_require_success = 1;

Sbuild will then exit with a non-zero exit status if any of these three fail.

Does this sound good to you?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#902864: RM: ruby-raphael-rails -- ROM; gitlab can use libjs-raphael now, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
X-debbugs-cc: debian-r...@lists.debian.org

This was packaged as a dependency of gitlab. Newer versions of gitlab
removed this dependency and now uses libjs-raphael directly with
webpack. No reverse dependencies.









signature.asc
Description: OpenPGP digital signature

Bug#902863: RM: ruby-cal-heatmap-rails -- ROM; gitlab no longer depend on it, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
X-debbugs-cc: debian-r...@lists.debian.org

This was packaged as a dependency of gitlab. Newer versions of gitlab
removed this dependency and now uses node module directly with
webpack. No reverse dependencies.









signature.asc
Description: OpenPGP digital signature

Bug#902861: axis: FTBFS with Java 10 due to com.sun.net.ssl removal

[Emmanuel Bourg]

Le 02/07/2018 à 14:51, Emmanuel Bourg a écrit :

> axis fails to build with Java 10 due to the removal of the com.sun.net.ssl 
> API:
> 
>   
> ./axis/src/org/apache/axis/components/net/SunFakeTrustSocketFactory.java:24: 
> error: package com.sun.net.ssl does not exist
>   import com.sun.net.ssl.SSLContext;

It looks like this error has been triggered by the upload of
ant/1.10.3-2 and the added --release parameter on javac invocations. The
same error can be seen on other Ant based packages using the com.sun APIs.

It turns out that using "--release 7" when compiling renders the
com.sun.* packages unavailable, but with "-source 7 -target 7" it works
fine.

Bug#902862: RM: ruby-underscore-rails -- ROM; gitlab can use node-underscore now, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
X-debbugs-cc: debian-r...@lists.debian.org

This was packaged as a dependency of gitlab. Newer versions of gitlab
removed this dependency and now uses node-underscore directly with
webpack. No reverse dependencies.







signature.asc
Description: OpenPGP digital signature