Bug#447935: openssh-client: please provide a way for ssh-agent to send a notification when used

2019-06-04 Thread Marc Haber
On Thu, Oct 25, 2007 at 12:20:54AM +0300, Ratiu Petru wrote:
> I'm currently concerned with possible attacks when forwarding the agent
> to shared hosts. I believe that having ssh-agent logging key uses would
> be a step to at least identifying misbehaving root users along the way.
> Notifications via libnotify would be real sweet, as well.
> 
> I haven't noticed any way of obtaining this info from ssh-agent's
> manpage, so if it exists, pardon me and consider this a bug against the
> documentation.

Would the -c option to ssh-add, which asks for confirmation before a key
is used, help with your concern?

Greetings
Marc



Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x

2019-06-04 Thread Mike Hommey
On Wed, Jun 05, 2019 at 02:32:10PM +0900, Mike Hommey wrote:
> Package: gcc-8
> Version: 8.3.0-7
> Severity: normal
> 
> See 
> https://buildd.debian.org/status/fetch.php?pkg=firefox&arch=s390x&ver=68.0%7Eb6-2&stamp=1559711675&raw=0
> 
> /<>/gfx/skia/skia/third_party/skcms/src/Transform_inl.h: In 
> function 'void baseline::exec_ops(const Op*, const void**, const char*, 
> char*, int)':
> /<>/gfx/skia/skia/third_party/skcms/src/Transform_inl.h:640:13: 
> internal compiler error: in convert_move, at expr.c:218
>  static void exec_ops(const Op* ops, const void** args,
>  ^~~~
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> Preprocessed source stored into /tmp/ccqWUX5y.out file, please attach this to 
> your bugreport.

It also happens on i386:
https://buildd.debian.org/status/fetch.php?pkg=firefox&arch=i386&ver=68.0%7Eb6-2&stamp=1559712011&raw=0

Mike



Bug#928185: unblock: openjdk-11/11.0.3+7-4

2019-06-04 Thread tony mancill
On Tue, Jun 04, 2019 at 09:36:56PM +0200, Paul Gevers wrote:
> Ping... [fixed borked address of doko and added Tony]
> 
> On 29-05-2019 20:22, Paul Gevers wrote:
> > Control: tags -1 928185 moreinfo
> > Control: reopen -1
> > 
> > Hi,
> > 
> > On 28-05-2019 23:50, Emmanuel Bourg wrote:
> >> Tony Mancill has prepared the tpu upload yesterday and Matthias was ok
> >> with 11.0.3+7 in testing [1].
> > 
> > Can I see a debdiff please?
> > 
> >> Unless Buster is expected at the end of July I'd advise against having
> >> 11.0.4+2 in testing. This version is an early access release, the final
> >> 11.0.4 release is expected on July 16th [2]. Debian is currently being
> >> criticized [3] for allowing EA versions of OpenJDK in Debian stable, I
> >> think it's important to ship Buster with a GA release.
> > 
> > Then please refrain from uploading the wrong version to unstable, we
> > have experimental for that. TPU doesn't get much testing, and for sure
> > isn't covered well by our QA yet. So having such a high profile package
> > with so much changes going through tpu is awkward.

Hi Paul!

Thank you for copying me on this as I missed this bug, despite being
part of a related thread on debian-java [1] (that probably mentions it
somewhere).  Also, aside from sponsoring an upload of openjdk-8 to
experimental for Tiago last year, I haven't worked much with the openjdk
packaging and so am trying to come up to speed.  However, I do think
it's important that Buster ship with a "GA" version of openjdk-11 (if
possible), which is why I have volunteered to help.

I've looked at a couple different approaches, both of which result in
large debdiffs.

The first is to take Matthias' upload of 11.0.3+7-4 to unstable [2] and
then revert the jdk11u-dev updates patch as per a suggestion made by
Emmanuel in IRC.  The resulting debdiff against the current package in
buster is about 310k [3].

The second approach was to go back to the 11.0.3+1-1 package in buster
and then import upstream 11.0.3+7, resulting in a debdiff of 270k [4].
(I am numbered this 11.0.3+7-1 for my local build, since that's still
less than the version in unable, but let's ignore the package revision
for now.)  My hope was that the second approach would result in a smaller
diff to make it more palatable to the Release Team, but 270k is big. 

Note that the second approach is essentially the one Emmanuel took with
openjdk-11 backport for stretch [5].  The reason the debdiff is smaller
is because debian/patches/changes-from-11.0.3+1-to-11.0.3+7.patch
doesn't prunes the changes to upstream tests that changed between those
releases.  Or to put it another way, most of the large debdiff is due to
tests, not changes to the runtime.

All that said, I'm not well-versed in all of the packaging changes made
since the freeze and haven't formed a strong opinion on which approach
is better for Buster.  At a minimum we need to address the CVEs present
in 11.0.3+1, so the idea with jumping to 11.0.3+7 is that we address the
security issues and are building from an upstream GA tag instead of an
early-access tag.

Sorry for the book - I know all you asked for was the debdiff...

Thanks,
tony

[1] https://lists.debian.org/debian-java/2019/05/msg7.html
[2] 
https://tracker.debian.org/news/1038802/accepted-openjdk-11-11037-4-source-into-unstable/
[3] 
https://people.debian.org/~tmancill/openjdk-11/11.0.3+1-1.dsc_vs_11.0.3+7-5.dsc.debdiff
[4] 
https://people.debian.org/~tmancill/openjdk-11/buster_minimal_11.0.3+1-1_11.0.3+7-1_dsc.debdiff
[5] 
https://tracker.debian.org/news/1040268/accepted-openjdk-11-11031-1bpo92-source-amd64-all-into-stretch-backports-backports-policy-stretch-backports/


signature.asc
Description: PGP signature


Bug#920610: Please include http mod to grubnetx64.efi

2019-06-04 Thread Steven Clarkson
This would also help our setup. This change has already been made in Ubuntu.

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1787630



Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x

2019-06-04 Thread Mike Hommey
Package: gcc-8
Version: 8.3.0-7
Severity: normal

See 
https://buildd.debian.org/status/fetch.php?pkg=firefox&arch=s390x&ver=68.0%7Eb6-2&stamp=1559711675&raw=0

/<>/gfx/skia/skia/third_party/skcms/src/Transform_inl.h: In 
function 'void baseline::exec_ops(const Op*, const void**, const char*, char*, 
int)':
/<>/gfx/skia/skia/third_party/skcms/src/Transform_inl.h:640:13: 
internal compiler error: in convert_move, at expr.c:218
 static void exec_ops(const Op* ops, const void** args,
 ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccqWUX5y.out file, please attach this to 
your bugreport.



Bug#929283: zookeeper: CVE-2019-0201: information disclosure vulnerability

2019-06-04 Thread tony mancill
On Fri, May 31, 2019 at 09:01:12AM +0200, Salvatore Bonaccorso wrote:
> Hi Tony,
> 
> On Thu, May 30, 2019 at 06:47:33AM -0700, tony mancill wrote:
> > On Mon, May 27, 2019 at 10:07:38PM -0700, tony mancill wrote:
> > > On Sun, May 26, 2019 at 08:58:29PM +0200, Moritz Mühlenhoff wrote:
> > > > Looks fine, but can you please also include the test case upstream 
> > > > added?
> > > > Given that it's quite complex to reconstruct the specific affected ZK 
> > > > setup,
> > > > we should at least ship/run the test case.
> > > 
> > > I will prepare an upload for 3.4.13 in testing/unstable soon - should be
> > > in the next day or so.
> > 
> > As an update...
> > 
> > Regarding the upload of a patched 3.4.13 for buster and unstable,
> > cherry-picking and adapting the upstream patch from the 3.4.14 branch is
> > straight-forward and complete [1].  The package is building, etc.
> > 
> > The delay is that the tests for the Debian package aren't in a state
> > where they are easy to run.  This predates this issue, going back to the
> > changes made when netty 3.9 was removed from Debian.  Since the changes
> > to the packaging and patches to re-enable tests would be extensive (I am
> > still working through them), I'm not certain that they will be suitable
> > for an upload during the freeze.  At a minimum, I intend to get them
> > working locally and push a branch so that others can verify, as well as
> > run the updated ZK through some local smoke-testing that validates the
> > ACL change.
> 
> Thanks for giving an update on the state!

Hi Salvatore - 

Apologies again for the delay.  The zookeeper package tests are in rough
shape and I wasn't able to get all tests passing even after installing
libjetty-3.9-java in a local chroot and some hacking.  The
work-in-progress 3.4.13-2+test branch is on Salsa [1], but getting the
tests into good working order will be a goal for buster.

However, I did verify the following before uploading:

- the test results between 3.4.13-1 and 3.4.13-2 are the same, meaning
  no regressions
- the newly added FinalRequestProcessorTest in 3.4.13-2 passes
- I could reproduce the ACL information disclosure on 3.4.13-1
- 3.4.13-2 no longer freely shares ACLs on nodes with ACLs that prevent
  unauthorized reading

I have just uploaded to unstable [2] and will request an unblock for
buster.

Thank you,
tony

[1] https://salsa.debian.org/java-team/zookeeper/tree/3.4.13-2+test


signature.asc
Description: PGP signature


Bug#930011: xserver-xorg-video-radeon: Can not login to X

2019-06-04 Thread Costas Ganis
Package: xserver-xorg-video-radeon
Version: 1:19.0.1-1
Severity: important

Dear Maintainer,

Couldn't login to X after buster apt upgrade.

Solution was to log in as root and do:
#nano /etc/X11/Xwrapper.config

Replace:
needs_root_rights=yesallowed_users=anybody

With:
needs_root_rights=yes
allowed_users=anybody

And press CTRL+ O to save.

After rebooting all was fine.



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

lrwxrwxrwx 1 root root 13 Jul 24  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Mar  5 22:11 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Kabini [Radeon HD 8210] [1002:9834]

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

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 66 Jun 19  2017 20-fglrx.conf

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 81280 Aug 10  2014 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 36449 Jun  5 07:47 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[62.151] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[62.151] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[62.151] Current Operating System: Linux kozidaware 4.19.0-5-amd64 #1 SMP 
Debian 4.19.37-3 (2019-05-15) x86_64
[62.152] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=8a914cf3-ceb4-4516-8b12-3a8e26416737 ro quiet acpi_osi=Linux 
acpi_backlight=video
[62.152] Build Date: 05 March 2019  08:11:12PM
[62.152] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[62.152] Current version of pixman: 0.36.0
[62.152]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[62.152] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[62.152] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun  5 07:46:51 
2019
[62.478] (==) Using config directory: "/etc/X11/xorg.conf.d"
[62.478] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[65.610] (==) No Layout section.  Using the first Screen section.
[66.294] (==) No screen section available. Using defaults.
[66.294] (**) |-->Screen "Default Screen Section" (0)
[66.294] (**) |   |-->Monitor ""
[66.973] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[66.973] (**) |   |-->Device "My GPU"
[66.973] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[66.973] (==) Automatically adding devices
[66.973] (==) Automatically enabling devices
[66.973] (==) Automatically adding GPU devices
[66.973] (==) Max clients allowed: 256, resource mask: 0x1f
[69.069] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[69.069]Entry deleted from font path.
[70.014] (==) 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
[70.014] (==) ModulePath set to "/usr/lib/xorg/modules"
[70.014] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[70.014] (II) Loader magic: 0x55653f741e20
[70.014] (II) Module ABI versions:
[70.014]X.Org ANSI C Emulation: 0.4
[70.014]X.Org Video Driver: 24.0
[70.014]X.Org XInput driver : 24.1
[70.014]X.Org Server Extension : 10.0
[70.017] (++) using VT number 7

[70.017] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[70.020] (II) xfree86: Adding drm device (/dev/dri/card0)
[70.046] (--) PCI:*(0@0:1:0) 1002:9834:103c:21f7 rev 0, Mem @ 
0xe000/268435456, 0xf000/8388608, 0xf0c0/262144, I/O @ 
0x3000/256, BIOS @ 0x/131072
[70.047] (II) LoadModule: "glx"
[70.457] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[71.385] (II) Module glx: vendor="X.Org Foundation"
[71.385]compiled for 1.20.4, module version = 1.0.0
[   

Bug#930010: warnings with postgresql 11

2019-06-04 Thread Daniel Baumann
Package: pgcli
Version: 1.9.0-1

Hi Lennart,

when using pgcli in buster which has postgresql 11, I'll get the
following ugly warnings on start:

---snip---
$ sudo -u postgres pgcli
Version: 1.9.1
Chat: https://gitter.im/dbcli/pgcli
Mail: https://groups.google.com/forum/#!forum/pgcli
Home: http://pgcli.com
postgres> Exception in thread completion_refresh:
Traceback (most recent call last):
  File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.7/threading.py", line 865, in runs-mode
Refreshing completions...
self._target(*self._args, **self._kwargs)
  File "/usr/share/pgcli/pgcli/completion_refresher.py", line 68, in
_bg_refresh
refresher(completer, executor)
  File "/usr/share/pgcli/pgcli/completion_refresher.py", line 146, in
refresh_functions
completer.extend_functions(executor.functions())
  File "/usr/share/pgcli/pgcli/pgcompleter.py", line 224, in
extend_functions
for f in func_data:
  File "/usr/share/pgcli/pgcli/pgexecute.py", line 612, in functions
cur.execute(query)
psycopg2.ProgrammingError: column p.proisagg does not exist
LINE 8: p.proisagg is_aggregate,
^
HINT:  Perhaps you meant to reference the column "p.prolang".


postgres>

Time: 0.000s
postgres>
---snap---

Regards,
Daniel



Bug#929609: different fix upstream

2019-06-04 Thread Bernhard M. Wiedemann
This was solved with a different patch
that is already merged upstream:
https://github.com/ntop/nDPI/pull/662
-- 
Bernhard M. Wiedemann
openSUSE Developer and Cloud Software Developer and Sysadmin
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)



Bug#930009: clisp: add support of MIPS r6

2019-06-04 Thread YunQiang Su
Package: src:clisp
Version: 1:2.49.20180218+really2.49.92-3
Control: forward -1 https://sourceforge.net/p/clisp/patches/56/

MIPS r6 removes the mult/mflo/mfhi, and replace them with
   mul/muh.



-- 
YunQiang Su


mips-r6.diff
Description: Binary data


Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items

2019-06-04 Thread scott092707
GLib bug on GitLab (https://gitlab.gnome.org/GNOME/glib/issues/1271
"fstab binds appear as mounts (x-gvfs-hide is being ignored)")

shows two commits, the second of which 
https://gitlab.gnome.org/GNOME/glib/merge_requests/366
(and the bug itself) appear to have been fixed in GLib version 2.59.0
(only debian Experimental has a version that meets/exceeds this version)

https://gitlab.gnome.org/GNOME/glib/blob/master/NEWS :

Line# / Line
---
416 Overview of changes in GLib 2.59.0
...
431 * Hide bind mounts from GIO mount listings. (#1271)
...
490 * Bugs fixed:
...
503  - #1271 fstab binds appear as mounts (x-gvfs-hide is being ignored)
...
594  - !366 gunixmounts: Mark mounts as system internal instead of filtering out

(!365 gunixmounts: Filter out mounts with device path that was repeated
was also listed as a commit for #1271, and as merged, but I don't see it
listed anywhere - don't know if that was an oversight and it was fixed,
or got un-merged. 
https://gitlab.gnome.org/GNOME/glib/merge_requests/365)

---
I assume that if one wanted to try out the version in Experimental (2.60.3-1),
that one would have to grab all GLib packages that in testing/sid are at version
2.58.3-1 (three on my system - libglib2.0-0, -bin, -data) 
(and hope that none of the higher versions conflicts with anything...)



Bug#930008: clang-8: --target=arm-linux-gnueabihf should target armv7 instead of armv6

2019-06-04 Thread Mike Hommey
Package: clang-8
Version: 1:8-3
Severity: wishlist

Dear Maintainer,

The target that one gives to clang needs, to some extent, to match what
the toolchain prefix is for binutils. For armhf, that is
arm-linux-gnueabihf. When using clang --target=arm-linux-gnueabihf,
clang still targets armv6, when the baseline for the armhf Debian
architecture is armv7. It should arguably target armv7.

```
$ clang --target=arm-linux-gnueabihf -dM -E -xc - < /dev/null | grep ARM_ARCH
#define __ARM_ARCH 6
#define __ARM_ARCH_6KZ__ 1
#define __ARM_ARCH_ISA_ARM 1
#define __ARM_ARCH_ISA_THUMB 1
```

One can use --target=armv7-linux-gnueabihf, but then clang doesn't find
the arm-linux-gnueabihf-prefixed binutils tools.

Mike



Bug#930007: dtrx does not support password encrypted zip files

2019-06-04 Thread Benjamin Mako Hill
Package: dtrx
Version: 7.1-2
Severity: wishlist

Since this package is currently orphaned... Thank you for to whoever takes on
the maintainership of dtrx.

This is a very simple feature request. There is currently no way to extract
password protected zip files with dtrx. I'd love it it there was. A more
general solution might simply be a way to pass options onto the programs
(unzip, tar, etc) that are doing the extraction.

That's it! I'm happy to provide a broken password protected zip file if that's
helpful. :)

Regards,
Mako

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

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

Versions of packages dtrx depends on:
ii  binutils 2.31.1-16
ii  bzip21.0.6-9
ii  cabextract   1.9-1
ii  cpio 2.12+dfsg-9
ii  p7zip-full   16.02+dfsg-6
ii  python   2.7.16-1
ii  rpm  4.14.2.1+dfsg1-1
ii  unshield 1.4.2-1
ii  unzip6.0-22
ii  xz-utils [lzma]  5.2.4-1

dtrx recommends no packages.

dtrx suggests no packages.

-- no debconf information



Bug#908329: lightdm: LightDM shuts down the screen on lock and won't turn it on

2019-06-04 Thread Thomas McAtee Jr
Sounds like this thing is still  being a thorn in everyones side doesn't
it?

On 06/04/2019 06:49 PM, Brian Clemens wrote:
> Package: lightdm > Version: 1.26.0-4 > Followup-For: Bug #908329 >
> I'm having similar issues.  After using either `dm-tool lock` or
> `light-locker-command -l`, the screen turns off.  I can unlock the
> screen by typing my password and hitting enter, so the lock screen is
> functional, just not visible.
> Also, if I switch to a different VT the screen turns on.  After doing
> this and switching back to VT8, the screen remains on and lightlocker is
> visible / functional.
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages lightdm depends on:
> ii  adduser    3.118
> ii  dbus   1.12.14-1
> ii  debconf [debconf-2.0]  1.5.71
> ii  libaudit1  1:2.8.4-3
> ii  libc6  2.28-10
> ii  libgcrypt20    1.8.4-5
> ii  libglib2.0-0   2.58.3-1
> ii  libpam0g   1.3.1-5
> ii  libxcb1    1.13.1-2
> ii  libxdmcp6  1:1.1.2-3
> ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
> pn  logind | consolekit    
> ii  lsb-base   10.2019051400
>
> Versions of packages lightdm recommends:
> ii  xserver-xorg  1:7.7+19
>
> Versions of packages lightdm suggests:
> pn  accountsservice  
> pn  upower   
> ii  xserver-xephyr   2:1.20.3-1
>
> -- debconf information:
>   lightdm/daemon_name: /usr/sbin/lightdm
> * shared/default-x-display-manager: lightdm
>
>



signature.asc
Description: OpenPGP digital signature


Bug#929482: Info received (Bug#929482: cacti: After apt-get install cacti, the installation stated something old version DB(?) and does not proceed.)

2019-06-04 Thread ISHIKAWA,chiaki

This is not a strictly speaking bug report.

But I noticed that when I try to access the mail archive of 
pkg-cacti-maint via the web interface,
my norton anti-virus's safe browser feature shuts the access off 
initially stating

that the web site is a dangerous site, etc.

What on earth is going on? I checked that Norton anti-virus regard the 
mail archive due to the

following two infected attachments in the archive.
It would be great if someone can remove the said
mails so that Norton no longer regards the archive access dangerous.


   Threat Report

small-warning
Viruses
Threats found: *2*
Here is a complete list: (for more information about a specific threat, 
click on the Threat Name below)


Threat Name:
JS.Nemucod!g1 


Location:
https://alioth-lists.debian.net/pipermail/pkg-salt-team/attachments/20150615/3ed58d65/attachment.zip 



Threat Name:
Direct Link To JS.Nemucod!g1 


Location:
http://alioth-lists.debian.net/pipermail/pkg-salt-team/attachments/20150615/3ed58d65/attachment.zip 





Just FYI.



On 2019/06/05 1:27, Debian Bug Tracking System wrote:

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Cacti Maintainer 

If you wish to submit further information on this problem, please
send it to 929...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.





Bug#908329: lightdm: LightDM shuts down the screen on lock and won't turn it on

2019-06-04 Thread Brian Clemens
Package: lightdm
Version: 1.26.0-4
Followup-For: Bug #908329

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm having similar issues.  After using either `dm-tool lock` or
`light-locker-command -l`, the screen turns off.  I can unlock the
screen by typing my password and hitting enter, so the lock screen is
functional, just not visible.
Also, if I switch to a different VT the screen turns on.  After doing
this and switching back to VT8, the screen remains on and lightlocker is
visible / functional.

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

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

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.14-1
ii  debconf [debconf-2.0]  1.5.71
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libglib2.0-0   2.58.3-1
ii  libpam0g   1.3.1-5
ii  libxcb11.13.1-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
pn  logind | consolekit
ii  lsb-base   10.2019051400

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
pn  accountsservice  
pn  upower   
ii  xserver-xephyr   2:1.20.3-1

- -- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR8ihmfyvGqv6V8ZdYrjgIDYDqDygUCXPcfsgAKCRArjgIDYDqD
ym/3AQC6z6CNnUV6iCU+0dTYRFrWG69u3w28vUy7WRQG0lGwdQD/WygaY41bKOLH
S5jaPC1oW2uLBuVmUnyhZ+5xDRmisgg=
=nR0T
-END PGP SIGNATURE-



Bug#893327: gandi-cli: command without manual page, ‘gandi’

2019-06-04 Thread Ben Finney
Control: found -1 gandi-cli/1.4-2
Control: found -1 gandi-cli/1.5-1
Control: forwarded -1 https://github.com/Gandi/gandi.cli/issues/283

On 18-Mar-2018, Ben Finney wrote:
> This is because the upstream source release omits the source for the
> manual page. I have reported an issue upstream for this.

That upstream issue is now resolved: The upstream source now includes
the source document for the manual page.

That document results in a manual page with errors; I have reported
this upstream at https://github.com/Gandi/gandi.cli/issues/283>.

While those errors remain, the manual page should not be installed by
the Debian package.

-- 
 \ “I object to doing things that computers can do.” —Olin Shivers |
  `\   |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature


Bug#892264: Hy 0.17.0

2019-06-04 Thread Tianon Gravi
I've updated Git with what I think is finally successful packaging of
a newer Hy version (0.17.0 ATM).  It requires updated "python-astor"
(I tested 0.8.0) and "python-rply" (I tested 0.7.7), which I don't
have time to chase down properly right now.

"dh_auto_test" is passing but the autopkgtests are failing and I
haven't been able to dig in yet to figure out why (although I did
update them to switch from "nose" to "pytest" which does work to some
degree -- there's just more needed to figure out why some are still
failing).

Any help getting this further would be very much appreciated! :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4



Bug#929067: reopen

2019-06-04 Thread Vincent Tondellier
Hi,

The patch enable-md-clear.patch in the deb9u6 update for stretch is wrong.
It defines md-clear to the 26th bit of FEAT_6_EAX instead of the 10th bit 
of FEAT_7_0_EDX because the offset is wrong in the patch and the first line 
does not match.

Result: the guest does not see the cpu flag:

# dmesg | grep -i mds
[0.131153] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
# grep md_clear /proc/cpuinfo
# cat /sys/devices/system/cpu/vulnerabilities/mds
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown


Please find a fixed patch attached. With my patch:

# dmesg | grep -i mds
[0.132439] MDS: Mitigation: Clear CPU buffers
# grep md_clear /proc/cpuinfo
flags   : [...] md_clear
# cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT Host state unknown


A correctly patched target-i386/cpu.c should look like this around line 452:
[FEAT_7_0_EDX] = {
.feat_names = {
NULL, NULL, "avx512-4vnniw", "avx512-4fmaps",
NULL, NULL, NULL, NULL,
NULL, NULL, "md-clear", NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
NULL, NULL, "spec-ctrl", NULL,
NULL, NULL, NULL, "ssbd",
},
.cpuid_eax = 7,
.cpuid_needs_ecx = true, .cpuid_ecx = 0,
.cpuid_reg = R_EDX,
.tcg_features = TCG_7_0_EDX_FEATURES,
},


How to test:

With libvirt, you have to patch /usr/share/libvirt/cpu_map.xml to add the 
feature:

 
  


Add the feature to the virtual machine xml:

  
...

  

qemu will now start with the flag (or will not start if the microcode is not 
patched):

qemu-system-x86_64 ... -cpu ...,+md-clear ...

Then, check for the presence of the cpu flag and mds status in an up to date 
virtual machine.



Thanks.From: Paolo Bonzini 
Date: Fri, 1 Mar 2019 21:40:52 +0100
Subject: target/i386: define md-clear bit
Bug-Debian: http://bugs.debian.org/929067

md-clear is a new CPUID bit which is set when microcode provides the
mechanism to invoke a flush of various exploitable CPU buffers by invoking
the VERW instruction.  Add the new feature, and pass it down to
Hypervisor.framework guests.

Signed-off-by: Paolo Bonzini 

[Backported to qemu 2.8 mjt]

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
---
 target-i386/cpu.c | 2 +-
 target-i386/cpu.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index de1f30eeda6..bbb4526a043 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -449,7 +449,7 @@ static FeatureWordInfo feature_word_info
 .feat_names = {
 NULL, NULL, "avx512-4vnniw", "avx512-4fmaps",
 NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
+NULL, NULL, "md-clear", NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index c6057240227..c9c7f60a54d 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -632,6 +632,7 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];

 #define CPUID_7_0_EDX_AVX512_4VNNIW (1U << 2) /* AVX512 Neural Network Instructions */
 #define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply Accumulation Single Precision */
+#define CPUID_7_0_EDX_MD_CLEAR  (1U << 10) /* Microarchitectural Data Clear */
 #define CPUID_7_0_EDX_SPEC_CTRL (1U << 26) /* Speculation Control */
 #define CPUID_7_0_EDX_SPEC_CTRL_SSBD  (1U << 31) /* Speculative Store Bypass Disable */

--
2.11.0


Bug#929467: RFS: tfortune-1.0.0 [ITP]

2019-06-04 Thread Adam Borowski
On Tue, Jun 04, 2019 at 05:06:00PM +0200, Andre Noll wrote:
> v3 is pushed out now and contains
> a simple debian/rules file which fully relies on dh. Besides
> dh_auto_configure I also had to override dh_autoreconf for reasons
> explained in the commit message.

The package looks almost good now.  You do close a completely unrelated ITP
bug though: "ITP: eazel-engine".

On the other hand, the package neither ships any data files, nor can't
handle their lack gracefully: it crashes with:
regfile_iter_new: opendir /home/kilobyte/.tfortune/epigrams: No such file or 
directory


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Sometimes you benefit from delegating stuff.  For example,
⢿⡄⠘⠷⠚⠋⠀ this way I get to be a vegetarian.
⠈⠳⣄



Bug#929983: ipxe-qemu: virtio booting no longer works after upgrade to buster

2019-06-04 Thread Thorsten Glaser
On Tue, 4 Jun 2019, Vagrant Cascadian wrote:

> Works for me using a virt-manager configured with virtio or the
> hypervisor default for netoworking with the same seabios and ipxe

Hmm.

> versions. My system was recently upgraded from stretch to buster.

This one was a fair bit older, I think it was originally a wheezy,
but I upgraded it step by step as usual.

> Could you provide more detail about your configured virtual machine?

I’ll attach the virsh dumpxml output below; I had reinstalled Debian
using an e1000 NIC and netboot in the meantime and reverted to virtio
afterwards, but I’m pretty sure this is reproducible even on other
virtualisation hosts, I will try that tomorrow.



  veraweb-mit
  52e965be-c1b7-72b7-0286-6a7bad8a014d
  1048576
  1048576
  1
  
hvm

  
  



  
  
Nehalem-IBRS
Intel










  
  
  destroy
  restart
  restart
  
/usr/bin/kvm

  
  
  
  
  
  
  


  
  


  


  
  
  
  
  
  
  


  
  

  
  


  
  
  


  
  


  


  


  


  
  
  


  
  

  
  
+109:+117
+109:+117
  





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

**

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

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

**



Bug#930006: flashrom: "nicintel" programmer does not access more than 128K

2019-06-04 Thread F Clancy
Package: flashrom
Version: 1.0.1-1
Severity: normal
Tags: upstream

Dear Maintainer,

I tried to read an Eon EN29F002NT 256K EEPROM in an Intel Ethernet Pro 100
network card using the -f option. 262144 bytes were stored but instead of
reading the whole EEPROM, the first half was read twice.

When I edited nicintel.c in the source code and changed line 40 from
#define NICINTEL_MEMMAP_SIZE (128 * 1024)
to
#define NICINTEL_MEMMAP_SIZE (256 * 1024)
the whole EEPROM could be read, written and erased succesfully without using
the -f option.


Output of lspci:
05:09.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100
(rev 02)


Output of "flashrom -p nicintel -r test.rom" (original version):
flashrom  on Linux 4.19.0-5-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Eon flash chip "EN29F002(A)(N)T" (256 kB, Parallel) on nicintel.
This flash chip is too big for this programmer (--verbose/-V gives details).
Use --force/-f to override at your own risk.


Output of "flashrom -p nicintel -r test.rom" (modified version):
flashrom v1.0.1 on Linux 4.19.0-5-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Eon flash chip "EN29F002(A)(N)T" (256 kB, Parallel) on nicintel.
Reading flash... done.



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

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

Versions of packages flashrom depends on:
ii  libc6 2.28-10
ii  libftdi1-21.4-1+b2
ii  libpci3   1:3.5.2-1
ii  libusb-0.1-4  2:0.1.12-32
ii  libusb-1.0-0  2:1.0.22-2

flashrom recommends no packages.

flashrom suggests no packages.

-- no debconf information



Bug#929903: openssl: m2crypto test case regression

2019-06-04 Thread Sebastian Andrzej Siewior
On 2019-06-04 14:24:12 [+0200], Matěj Cepl wrote:
> Sebastian Andrzej Siewior píše v Út 04. 06. 2019 v 14:15 +0200:
> > Let me ping upstream: Matěj, could you please take a look at
> > https://bugs.debian.org/929903
> > 
> > and check if it is okay the test no longer fails or if openssl suddenly
> > eats up the error code. Afterall:
> 
> OK, I have this commit now in the master 
> https://gitlab.com/m2crypto/m2crypto/commit/f287d7145b5f but I am
> still not certain that sslv23_padding and especially no_padding
> should lead to error, shouldn't it?
> 
> Why did the test passed before otherwise?

It did not if I understand the python correctly:
|with self.assertRaises(RSA.RSAError):
|priv.private_decrypt(ctxt, RSA.sslv23_padding)

you expect that `priv.private_decrypt()' raised an RSA.RSAError
exception which it did before c (due to that bug) and did not since c.

> Best,
> 
> Matěj

Sebastian



Bug#929283: zookeeper: CVE-2019-0201: information disclosure vulnerability

2019-06-04 Thread Chris Lamb
Hi Moritz,

> > Thanks. Here is my diff:
> 
> Looks fine, but can you please also include the test case upstream added?
> Given that it's quite complex to reconstruct the specific affected ZK setup,
> we should at least ship/run the test case.

Sure. Here's my updated patch:

diffstat for zookeeper-3.4.9 zookeeper-3.4.9

 changelog|8 +
 patches/CVE-2019-11579.patch |  290 +++
 patches/series   |1 
 3 files changed, 299 insertions(+)

diff -Nru zookeeper-3.4.9/debian/changelog zookeeper-3.4.9/debian/changelog
--- zookeeper-3.4.9/debian/changelog2018-05-23 21:34:43.0 +0100
+++ zookeeper-3.4.9/debian/changelog2019-05-24 08:57:53.0 +0100
@@ -1,3 +1,11 @@
+zookeeper (3.4.9-3+deb9u2) stretch-security; urgency=high
+
+  * CVE-2019-0201: Prevent an information disclosure vulnerability where users
+who were not authorised to read data were able to view the access control
+list. (Closes: #929283)
+
+ -- Chris Lamb   Fri, 24 May 2019 08:57:53 +0100
+
 zookeeper (3.4.9-3+deb9u1) stretch-security; urgency=high
 
   * Team upload.
diff -Nru zookeeper-3.4.9/debian/patches/CVE-2019-11579.patch 
zookeeper-3.4.9/debian/patches/CVE-2019-11579.patch
--- zookeeper-3.4.9/debian/patches/CVE-2019-11579.patch 1970-01-01 
01:00:00.0 +0100
+++ zookeeper-3.4.9/debian/patches/CVE-2019-11579.patch 2019-05-24 
08:57:53.0 +0100
@@ -0,0 +1,290 @@
+--- 
zookeeper-3.4.9.orig/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java
 
zookeeper-3.4.9/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java
+@@ -20,6 +20,7 @@ package org.apache.zookeeper.server;
+ 
+ import java.io.IOException;
+ import java.nio.ByteBuffer;
++import java.util.ArrayList;
+ import java.util.List;
+ 
+ import org.apache.jute.Record;
+@@ -32,6 +33,7 @@ import org.apache.zookeeper.KeeperExcept
+ import org.apache.zookeeper.KeeperException.SessionMovedException;
+ import org.apache.zookeeper.ZooDefs.OpCode;
+ import org.apache.zookeeper.data.ACL;
++import org.apache.zookeeper.data.Id;
+ import org.apache.zookeeper.data.Stat;
+ import org.apache.zookeeper.proto.CreateResponse;
+ import org.apache.zookeeper.proto.ExistsRequest;
+@@ -308,10 +310,35 @@ public class FinalRequestProcessor imple
+ GetACLRequest getACLRequest = new GetACLRequest();
+ ByteBufferInputStream.byteBuffer2Record(request.request,
+ getACLRequest);
++DataNode n = 
zks.getZKDatabase().getNode(getACLRequest.getPath());
++if (n == null) {
++throw new KeeperException.NoNodeException();
++}
++PrepRequestProcessor.checkACL(zks, 
zks.getZKDatabase().aclForNode(n),
++ZooDefs.Perms.READ | ZooDefs.Perms.ADMIN,
++request.authInfo);
++
+ Stat stat = new Stat();
+-List acl = 
+-zks.getZKDatabase().getACL(getACLRequest.getPath(), stat);
+-rsp = new GetACLResponse(acl, stat);
++List acl =
++zks.getZKDatabase().getACL(getACLRequest.getPath(), 
stat);
++try {
++PrepRequestProcessor.checkACL(zks, 
zks.getZKDatabase().aclForNode(n),
++ZooDefs.Perms.ADMIN,
++request.authInfo);
++rsp = new GetACLResponse(acl, stat);
++} catch (KeeperException.NoAuthException e) {
++List acl1 = new ArrayList(acl.size());
++for (ACL a : acl) {
++if ("digest".equals(a.getId().getScheme())) {
++Id id = a.getId();
++Id id1 = new Id(id.getScheme(), 
id.getId().replaceAll(":.*", ":x"));
++acl1.add(new ACL(a.getPerms(), id1));
++} else {
++acl1.add(a);
++}
++}
++rsp = new GetACLResponse(acl1, stat);
++}
+ break;
+ }
+ case OpCode.getChildren: {
+--- /dev/null
 
zookeeper-3.4.9/src/java/test/org/apache/zookeeper/test/FinalRequestProcessorTest.java
+@@ -0,0 +1,230 @@
++/**
++ * Licensed to the Apache Software Foundation (ASF) under one
++ * or more contributor license agreements.  See the NOTICE file
++ * distributed with this work for additional information
++ * regarding copyright ownership.  The ASF licenses this file
++ * to you under the Apache License, Version 2.0 (the
++ * "License"); you may not use this file except in compliance
++ * with the License.  You may obtain a copy of the License at
++ *
++ * http://www.apache.org/licenses/LICENSE-2.0
++ *
++ * Unless required by applicable law or agreed to in writing, software
++ * distributed under the

Bug#930005: regina-rexx: rexxutil error

2019-06-04 Thread Douglas A. Tutty
Package: regina-rexx
Version: 3.6-2.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When try to run any of my programs that use RexxUtil, got an error,
so ran 

   $ regina /usr/share/doc/regina-rexx/examples/regutil.rexx

and received the error:
regina: symbol lookup error: /usr/lib/regina-rexx/3.6/libregutil.so:
undefined symbol: tgetent

which I've included in the attached file.

None of the scripts I've written to simplify my life which rely on
RexxUtil wil work without error until this is fixed.



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

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

Versions of packages regina-rexx depends on:
ii  libc6   2.24-11+deb9u4
ii  libregina3  3.6-2.1

regina-rexx recommends no packages.

regina-rexx suggests no packages.

-- debconf-show failed
SysWINVer Linux #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13).4.9.0-9-amd64
SysUtilVersion 3.6
Press Enter key when ready . . .
regina: symbol lookup error: /usr/lib/regina-rexx/3.6/libregutil.so: undefined 
symbol: tgetent


Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-04 Thread Holger Wansing

Am Sonntag, 2. Juni 2019 schrieb Holger Wansing:
> 
> Hi,
> 
> Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault:
> > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit:
> > > >> "لاحقاً"
> > > 
> > > This word means "later" and can be replaced by "لاحقا".
> > 
> > That avoids the issue here indeed. I however see it used in various
> 
> Hmm.
> There has been no changing in the ar.po of partman-auto
> for 3 years now (JFTR), thus the real problem seems to be
> sitting somewhere else ...

How should we proceed here?
Since we are late in the freeze, and it's most probably not that
easy to find out what happened and what the real issue is:
should we go with the "work-around" proposed by 
Butterflyoffire and confirmed to fix the issue by Samuel? 


Holger

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#927856: [Pkg-freeipa-devel] unblock: python-jwcrypto/0.6.0-1

2019-06-04 Thread Timo Aaltonen
On 4.6.2019 22.40, Paul Gevers wrote:
> Ping... [adding the team]
> 
> On 30-05-2019 22:18, Paul Gevers wrote:
>> Hi Timo,
>>
>> On 30-05-2019 13:18, Timo Aaltonen wrote:
>>> Hi, I don't know how much would have to be backported, but it's probably
>>> better to just unblock freeipa 4.7.2-3 instead, because python-jwcrypto
>>> is a dep of freeipa-server (which isn't built on sid/buster).
>>
>> Do I understand correctly that the code is present to build it, you just
>> don't do that in Debian? Do you suggest to change this bug to "unblock:
>> freeipa/4.7.2-3" instead then? (I would be willing to unblock it, but
>> then python-jwcrypto would go).
>>
>>> That way
>>> current client-only freeipa would remain on buster. Custodia is another
>>> package which depends on -jwcrypto, but it's again a server thing so can
>>> be removed from buster.
>>
>> These package are all from the same team, I guess the team agrees?
>>
>> Paul
>>

The team (me) agrees ;)

That said, fixing the python-jwcrypto test is a trivial commit, so maybe
this could be pushed too.

diff --git a/jwcrypto/jwa.py b/jwcrypto/jwa.py
index a6554b5..bbcd24c 100644
--- a/jwcrypto/jwa.py
+++ b/jwcrypto/jwa.py
@@ -141,7 +141,7 @@ class _RawEC(_RawJWS):
 def sign(self, key, payload):
 skey = key.get_op_key('sign', self._curve)
 signature = skey.sign(payload, ec.ECDSA(self.hashfn))
-r, s = ec_utils.decode_rfc6979_signature(signature)
+r, s = ec_utils.decode_dss_signature(signature)
 size = key.get_curve(self._curve).key_size
 return _encode_int(r, size) + _encode_int(s, size)

@@ -149,7 +149,7 @@ class _RawEC(_RawJWS):
 pkey = key.get_op_key('verify', self._curve)
 r = signature[:len(signature) // 2]
 s = signature[len(signature) // 2:]
-enc_signature = ec_utils.encode_rfc6979_signature(
+enc_signature = ec_utils.encode_dss_signature(
 int(hexlify(r), 16), int(hexlify(s), 16))
 pkey.verify(enc_signature, payload, ec.ECDSA(self.hashfn))


-- 
t



Bug#929597: CVE-2019-12211 CVE-2019-12212 CVE-2019-12213 CVE-2019-12214

2019-06-04 Thread Moritz Muehlenhoff
On Tue, Jun 04, 2019 at 08:20:33PM +0200, Anton Gladky wrote:
> severity 929597 important
> thanks
> 
> The fix from upstream is still not available. I am not feeling
> confident enough to provide a fix for this complex peace
> of code without breaking it.
> 
> Also reducing the severity. If the security team decides to
> keep it "grave" - feel free to revert it.

Fine, but we still need to fix it once properly fixed upstream.

Cheers,
Moritz



Bug#928807: unblock: mesa/18.3.6-2

2019-06-04 Thread Sam Hartman
Hi.  It would be great to get as many mesa fixes into buster as
possible, so I decided to review all your git commits.  I have no idea
if the release team will find this useful or not, but there's no way I
could construct a useful argument in favor of the inclusion without the
review.

I am *not* a member of the release team; I do not speak for anyone but
myself.

I got a chance to review all the 18.3.6 commits and started on 18.3.5.
Release team, if this is useful, I'm happy to finish off reviewing the
remainder of the commits.  Please explicitly let me know if that would
be valuable to you.


Based on the review so far, I find that the maintainer is probably
right.  Namely, the upstream is very conservative in what they accept
with one exception I'll call out below.  Unfortunately, mesa has a lot
of interdependencies, and the changes are inter-related.  If upstream
actually does have a good CI infrastructure across a lot of hardware,
then cherry-picking changes is likely to be significantly less stable
than pulling in a full upstream release.

We can do nothing.  We know we'll at least be suffering from a number of
crashes and graphics corruption issues if we do that.

We can take targeted fixes.
I think that's better than doing nothing.
However given upstream's conservative appropach, I actually think the
risk is lower if we take advantage of their test coverage and take all
or most of their release.

There's one area where upstream is not as conservative as we might like.
They have introduced a number of cases where additional linker or
compiler errors are added to shaders.
In general, they have turned cases where programs would previously build
but crash or produce bad graphics when run into build time errors.
>From our standpoint they have turned illegal input that would produce
graphical corruption or worse into ftbfs bugs or runtime compilation
failures depending on when the shader code is compiled.
Personally I think that's acceptable, but it's the thing  I most want to
flag here.  I've flagged such commits as linker (or compiler) change. I
think these commits could be reverted with less risk of interdependency
problem than other commits.




Changes I know we don't want:

97de8f48894844361d6d5e69137154741e114b74

Does not meet the freeze policy.  I've seen the release team reject
packages for making similarly large changes to packaging at this
stage in the process.

Comments on commits:


600f314d63ad3d916f1eaa46953f86846668685e
Fixes use-after-free

d29dca6d
Must include in buster if 7536af is included in buster to fix
segfault

eac9b87
linker change

76719ecb
This is a crash so  would probably be useful to get

96a01a5
I suspect that the bug this fixes  will result in graphical
corruption

0f976b
linker change

208fd66
linker change

db517e
linker change

2c163bfe
fix for bug definitely causing graphics corruption


2a1e743e
Fixes segfault



Bug#930004: gitlab: CVE-2019-12428 CVE-2019-12431 CVE-2019-12432 CVE-2019-12433 CVE-2019-12434 CVE-2019-12441 CVE-2019-12442 CVE-2019-12443 CVE-2019-12444 CVE-2019-12445 CVE-2019-12446

2019-06-04 Thread Salvatore Bonaccorso
Source: gitlab
Version: 11.8.10+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerabilities were published for gitlab, see [11] for
a complete listing.

CVE-2019-12428[0]:
Mandatory External Authentication Provider Sign-In Restrictions Bypass

CVE-2019-12431[1]:
Disclosure of Milestone Metadata through the Search API

CVE-2019-12432[2]:
Confidential Issue Titles Revealed to Restricted Users on Unsubscribe

CVE-2019-12433[3]:
Internal Projects Allowed to Be Created on in Private Groups

CVE-2019-12434[4]:
Private Project Discovery via Comment Links

CVE-2019-12441[5]:
Protected Branches Restriction Rules Bypass

CVE-2019-12442[6]:
Stored Cross-Site Scripting Vulnerability on Child Epics

CVE-2019-12443[7]:
Server-Side Request Forgery Through DNS Rebinding

CVE-2019-12444[8]:
Stored Cross-Site Scripting on Wiki Pages

CVE-2019-12445[9]:
Stored Cross-Site Scripting on Notes

CVE-2019-12446[10]:
Repository Password Disclosed on Import Error Page

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-12428
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12428
[1] https://security-tracker.debian.org/tracker/CVE-2019-12431
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12431
[2] https://security-tracker.debian.org/tracker/CVE-2019-12432
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12432
[3] https://security-tracker.debian.org/tracker/CVE-2019-12433
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12433
[4] https://security-tracker.debian.org/tracker/CVE-2019-12434
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12434
[5] https://security-tracker.debian.org/tracker/CVE-2019-12441
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12441
[6] https://security-tracker.debian.org/tracker/CVE-2019-12442
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12442
[7] https://security-tracker.debian.org/tracker/CVE-2019-12443
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12443
[8] https://security-tracker.debian.org/tracker/CVE-2019-12444
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12444
[9] https://security-tracker.debian.org/tracker/CVE-2019-12445
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12445
[10] https://security-tracker.debian.org/tracker/CVE-2019-12446
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12446
[11] 
https://about.gitlab.com/2019/06/03/security-release-gitlab-11-dot-11-dot-1-released/

Regards,
Salvatore



Bug#919759: Downgrade bug severity

2019-06-04 Thread Dr. Tobias Quathamer
control: severity -1 normal

Hi,

in order to re-sync the golang package versions in unstable and testing
(see [1] and [2] for more details), gokey has been uploaded with the
previous version, which does not FTBFS.

I'm therefore downgrading this bug to enable the migration of gokey to
testing. In a couple of days, after the testing migration, I'll adjust
the package version of gokey in this bug report, upgrade the severity
again to serious and tag the bug with "sid".

Regards,
Tobias

[1] https://wiki.debian.org/Teams/DebianGoTeam/AlignUnstableWithBuster
[2] https://bugs.debian.org/928227



signature.asc
Description: OpenPGP digital signature


Bug#930003: php7.3 breaks symfony autopkgtest (maybe only deprecation warnings?)

2019-06-04 Thread David Prévot
Hi,

Le 04/06/2019 à 09:56, Paul Gevers a écrit :

> Normally I copy some of the output at the bottom of this report, but in
> this case I couldn't spot the real failure

Here it is (the trick is to grep for the “KO” string).

> Testing src/Symfony/Component/Validator
> 
> […]
> 
> There were 2 errors:
> 
> 1) 
> Symfony\Component\Validator\Tests\Constraints\EmailValidatorTest::testStrictWithInvalidEmails
>  with data set #26 ('�@iana.org')
> Invalid argument supplied for foreach()
> 
> /usr/share/php/Doctrine/Common/Lexer/AbstractLexer.php:261
> /usr/share/php/Doctrine/Common/Lexer/AbstractLexer.php:96
> /usr/share/php/Egulias/EmailValidator/EmailParser.php:41
> /usr/share/php/Egulias/EmailValidator/Validation/RFCValidation.php:30
> /usr/share/php/Egulias/EmailValidator/Validation/NoRFCWarningsValidation.php:21
> /usr/share/php/Egulias/EmailValidator/EmailValidator.php:37
> /usr/share/php/Symfony/Component/Validator/Constraints/EmailValidator.php:66
> /tmp/autopkgtest-lxc.ass2zlnj/downtmp/build.22F/src/src/Symfony/Component/Validator/Tests/Constraints/EmailValidatorTest.php:116
> 
> 2) 
> Symfony\Component\Validator\Tests\Constraints\EmailValidatorTest::testStrictWithInvalidEmails
>  with data set #27 ('test@�.org')
> Invalid argument supplied for foreach()
> 
> /usr/share/php/Doctrine/Common/Lexer/AbstractLexer.php:261
> /usr/share/php/Doctrine/Common/Lexer/AbstractLexer.php:96
> /usr/share/php/Egulias/EmailValidator/EmailParser.php:41
> /usr/share/php/Egulias/EmailValidator/Validation/RFCValidation.php:30
> /usr/share/php/Egulias/EmailValidator/Validation/NoRFCWarningsValidation.php:21
> /usr/share/php/Egulias/EmailValidator/EmailValidator.php:37
> /usr/share/php/Symfony/Component/Validator/Constraints/EmailValidator.php:66
> /tmp/autopkgtest-lxc.ass2zlnj/downtmp/build.22F/src/src/Symfony/Component/Validator/Tests/Constraints/EmailValidatorTest.php:116

Regards

David



signature.asc
Description: OpenPGP digital signature


Bug#918475: mercurial fails to fetch clone bundles from bitbucket.org (SSL error)

2019-06-04 Thread Brian Minton
Package: mercurial
Version: 4.9-2
Followup-For: Bug #918475

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I've opened a but report with bitbucket.org regarding this issue:
https://bitbucket.org/site/master/issues/18846/bitbucket-servers-require-rsa_pkcs1_sha1

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 mercurial depends on:
ii  libc6 2.28-10
ii  mercurial-common  4.9-2
ii  python2.7.16-1
ii  ucf   3.0038+nmu1

Versions of packages mercurial recommends:
ii  openssh-client  1:7.9p1-10

Versions of packages mercurial suggests:
ii  meld  3.20.0-2
pn  qct   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQT5xLt2Dng/DewQpoprjrOgZc+6qQUCXPbQrQAKCRBrjrOgZc+6
qcmbAP9ZcHtZXp+6tfVcIdiT3EpYq6O0yXH/JLcy338+zFfhawD+I0Mbfdof+1jy
e/YcJR8zF/qYYw2Qde/XJCq8bXce2Y2IdQQBFggAHRYhBO7QFYAT3C5tbgAepDe5
UHrP8gFuBQJc9tCtAAoJEDe5UHrP8gFuS2EA/Rt6EfXqnIUVoXXlRevYWwmsNmE+
azFFivbuQ3HwdBx8AQDI5dv0GqDZS/U7rVvr+v+4kz+72XU+XVb9+wqkBvxPCA==
=Q1Cd
-END PGP SIGNATURE-



Bug#930003: php7.3 breaks symfony autopkgtest (maybe only deprecation warnings?)

2019-06-04 Thread Paul Gevers
Source: php7.3, symfony
Control: found -1 php7.3/7.3.6-1
Control: found -1 symfony/3.4.22+dfsg-2
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of php7.3 the autopkgtest of symfony fails in
testing when that autopkgtest is run with the binary packages of php7.3
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
php7.3 from testing7.3.6-1
symfonyfrom testing3.4.22+dfsg-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

Normally I copy some of the output at the bottom of this report, but in
this case I couldn't spot the real failure, unless it is all these
deprecation warnings that are fatal. @symfony maintainers, if that is
the case, then please disable failure on deprecation warnings. Testing
for that is good, but not in autopkgtests.

Apart from the freeze, this regression is blocking the migration of
php7.3 to testing [1]. Due to the nature of this issue, I filed this bug
report against both packages. Can you please investigate the situation
and reassign the bug to the right package? If needed, please change the
bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
php7.3/7.3.6-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=php7.3

https://ci.debian.net/data/autopkgtest/testing/amd64/s/symfony/2455342/log.gz




signature.asc
Description: OpenPGP digital signature


Bug#930002: capstone: CVE-2016-7151

2019-06-04 Thread Salvatore Bonaccorso
Source: capstone
Version: 4.0.1+really+3.0.5-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/aquynh/capstone/pull/725
Control: found -1 3.0.4-1

Hi,

The following vulnerability was published for capstone.

CVE-2016-7151[0]:
| Capstone 3.0.4 has an out-of-bounds vulnerability (SEGV caused by a
| read memory access) in X86_insn_reg_intel in arch/X86/X86Mapping.c.


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-2016-7151
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7151
[1] https://github.com/aquynh/capstone/pull/725

Please adjust the affected versions in the BTS as needed, can you
double-check for the affected versions?

Regards,
Salvatore



Bug#930000: debarchiver: [INTL:de] updated German man page translation

2019-06-04 Thread Helge Kreutzmann
Package: debarchiver
Version: 0.11.3
Severity: wishlist
Tags: patch l10n

Please find the updated German man page translation for debarchiver
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# German translation of the debarchiver program messages
# This file is distributed under the same license as the debarchiver package.
# (C) Helge Kreutzmann , 2011, 2017-2019.
msgid ""
msgstr ""
"Project-Id-Version: debarchiver 0.11.3\n"
"POT-Creation-Date: 2018-12-28 22:12+0100\n"
"PO-Revision-Date: 2019-06-04 21:42+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: debian-l10n-ger...@lists.debian.org\n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. type: =head1
#: debarchiver.pod:1
msgid "NAME"
msgstr "NAME"

#. type: textblock
#: debarchiver.pod:3
msgid "debarchiver - Tool to sort debian packages into a package archive."
msgstr ""
"debarchiver - Werkzeug zum Sortieren von Debian-Paketen in ein Paketarchiv"

#. type: =head1
#: debarchiver.pod:5
msgid "SYNOPSIS"
msgstr "ÜBERSICHT"

#. type: textblock
#: debarchiver.pod:7
msgid "debarchiver [options]"
msgstr "debarchiver [Optionen]"

#. type: =head1
#: debarchiver.pod:9
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

#. type: textblock
#: debarchiver.pod:11
msgid ""
"The debian archiver is a tool that installs debian packages into a file "
"structure suitable for apt-get, aptitude, dselect and similar tools. This "
"can be used for updating the Debian system. It is meant to be used by local "
"administrators that need special packages, or tweaked versions to ease "
"administration."
msgstr ""
"Der Debian-Archivar ist ein Werkzeug, um Debian-Pakete in eine Dateistruktur "
"zu installieren, die für Apt-get, Aptitude, Dselect und ähnliche Werkzeuge "
"geeignet ist. Dies kann zur Aktualisierung des Debian-Systems verwandt "
"werden. Es ist für lokale Administratoren zur Erleichterung gedacht, die "
"besondere Pakete oder angepasste Versionen benötigen."

#. type: textblock
#: debarchiver.pod:13
msgid ""
"The file structure is based on the potato file structure and does not "
"support package pools."
msgstr ""
"Die Dateistruktur basiert auf der Dateistruktur von Potato und untertützt "
"keine Paket-Pools."

#. type: =head1
#: debarchiver.pod:15
msgid "OPTIONS"
msgstr "OPIONEN"

#. type: =item
#: debarchiver.pod:19
msgid "B<-a | --autoscan>"
msgstr "B<-a | --autoscan>"

#. type: textblock
#: debarchiver.pod:21
msgid "Does both --autoscanpackages and --autoscansources."
msgstr "Kombiniert --autoscanpackages und --autoscansources"

#. type: =item
#: debarchiver.pod:23
msgid "B<--autoscanall>"
msgstr "B<--autoscanall>"

#. type: textblock
#: debarchiver.pod:25
msgid "Same as --scanall --autoscan."
msgstr "Identisch zu --scanall --autoscan"

#. type: =item
#: debarchiver.pod:27
msgid "B<--autoscanpackages>"
msgstr "B<--autoscanpackages>"

#. type: textblock
#: debarchiver.pod:29
msgid ""
"Automatically run dpkg-scanpackages after all new packages are installed."
msgstr "Automatisch Dpkg-scanpackages nach Installation aller Pakete aufrufen"

#. type: =item
#: debarchiver.pod:31
msgid "B<--autoscansources>"
msgstr "B<--autoscansources>"

#. type: textblock
#: debarchiver.pod:33
msgid ""
"Automatically run dpkg-scansources after all new packages are installed."
msgstr "Automatisch Dpkg-scansources nach Installation aller Pakete aufrufen"

#. type: =item
#: debarchiver.pod:35
msgid "B<-b | --bzip>"
msgstr "B<-b | --bzip>"

#. type: textblock
#: debarchiver.pod:37
msgid "Create bzip2 compressed Packages.bz2 and Sources.bz2 files."
msgstr "Mit Bzip2 komprimierte Packages.bz2- und Sources.bz2-Dateien erstellen"

#. type: =item
#: debarchiver.pod:39
msgid "B<--cachedir> dir"
msgstr "B<--cachedir> Verz"

#. type: textblock
#: debarchiver.pod:41
msgid ""
"The apt-ftparchive package cache directory, if --index is used. The default "
"is $cachedir."
msgstr ""
"Das Paketzwischenspeicherverzeichnis von Apt-ftparchive, falls --index "
"verwandt wird. Standardmäßig $cachedir."

#. type: =item
#: debarchiver.pod:43
msgid "B<--cinstall> dir"
msgstr "B<--cinstall> Verz"

#. type: textblock
#: debarchiver.pod:45
msgid ""
"Where the .changes file will be installed to. Use the empty string to remove "
"the .changes file instead. The default is $cinstall."
msgstr ""
"Installationsort der Datei .changes. Verwenden Sie die leere Zeichenkette, "
"um die .changes-Datei stattdessen zu entfernen. Standardmäßig $cinstall."

#. type: =item
#: debarchiver.pod:47
msgid "B<--configfile> file"
msgstr "B<--configfile> Datei"

#. type: textblock
#: debarchiver.pod:49
msgid ""
"Specifies an extra configuration file to read. Will be read after etc "
"configuration and after user configuration

Bug#930001: xen: XSA-287: x86: steal_page violates page_struct access discipline

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-287.html

Please adjust affected versions as needed.

Regards,
Salvatore

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

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



Bug#929999: xen: XSA-293: x86: PV kernel context switch corruption

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-293.html

Please adjust affected versions as needed.

Regards,
Salvatore

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

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



Bug#929998: xen: XSA-285: race with pass-through device hotplug

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-285.html

Please adjust affected versions as needed.

Regards,
Salvatore

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

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



Bug#929996: xen: XSA-290: missing preemption in x86 PV page table unvalidation

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-290.html

Please adjust affected versions as needed.

Regards,
Salvatore

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

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



Bug#929995: xen: XSA-291: x86/PV: page type reference counting issue with failed IOMMU update

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-291.html

Please adjust affected versions as needed.

Regards,
Salvatore

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

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



Bug#923070: eom: can't handle wrong file extensions

2019-06-04 Thread Witold Baryluk
Package: eom
Version: 1.20.2-2
Followup-For: Bug #923070

I do expirience the same issue. With JPEG file with .png extension, the
eom displays an error about inability to open a file. Eom should ignore
the file extension, or only use it as a hint if at all. GIMP opens this
file without any issue. If I change the extension to anything else like
".bzium", eom properly detects it is jpeg file, and displays it without
any issue.

What is even more interesting is that caja has no issues showing thumbnails
of JPEG images, even if they have .png extension, or any other extension.
Caja basically doesn't care much about file extensions.

Similarly eom built in functionality of showing other images in the same
directory 'View -> Image Collection (F9)' also works fine with .png or
any other extension, and shows image thumbnails, without any issue.

Best regards,
Witold


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

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

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  eom-common   1.20.2-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.12-1
ii  libdbus-glib-1-2 0.110-4
ii  libexempi8   2.5.0-2
ii  libexif120.6.21-5.1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgl1   1.1.0-1
ii  libgl1-mesa-glx  18.3.4-2
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  libmate-desktop-2-17 1.20.4-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpeas-1.0-01.22.0-4
ii  librsvg2-2   2.44.10-2.1
ii  librsvg2-common  2.44.10-2.1
ii  libstartup-notification0 0.12-6
ii  libx11-6 2:1.6.7-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  mate-desktop-common  1.20.4-2
ii  shared-mime-info 1.10-1
ii  zlib1g   1:1.2.11.dfsg-1

eom recommends no packages.

eom suggests no packages.

-- no debconf information



Bug#927856: unblock: python-jwcrypto/0.6.0-1

2019-06-04 Thread Paul Gevers
Ping... [adding the team]

On 30-05-2019 22:18, Paul Gevers wrote:
> Hi Timo,
> 
> On 30-05-2019 13:18, Timo Aaltonen wrote:
>> Hi, I don't know how much would have to be backported, but it's probably
>> better to just unblock freeipa 4.7.2-3 instead, because python-jwcrypto
>> is a dep of freeipa-server (which isn't built on sid/buster).
> 
> Do I understand correctly that the code is present to build it, you just
> don't do that in Debian? Do you suggest to change this bug to "unblock:
> freeipa/4.7.2-3" instead then? (I would be willing to unblock it, but
> then python-jwcrypto would go).
> 
>> That way
>> current client-only freeipa would remain on buster. Custodia is another
>> package which depends on -jwcrypto, but it's again a server thing so can
>> be removed from buster.
> 
> These package are all from the same team, I guess the team agrees?
> 
> Paul
> 



Bug#929997: gnome-menus: [INTL:de] updated German po file translation

2019-06-04 Thread Helge Kreutzmann
Package: gnome-menus
Version: 3.32.0-1
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for gnome-menus
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Menu section translation
# Copyright (C) 2003
# This file is distributed under the same license as the gnome-menus package.
# Bill Allombert , 2003.
# German translation:
#   Sebastian Rittau , 2003, 2004.
#   Helge Kreutzmann , 2007, 2013, 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: menu-section 3.32.0-1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-01-21 18:53-0500\n"
"PO-Revision-Date: 2019-06-04 21:34+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=iso-8859-1\n"
"Content-Transfer-Encoding: 8bit\n"

#: debian/desktop-files/ActionGames.directory.desktop.in:3
msgid "Action"
msgstr "Action"

#: debian/desktop-files/ActionGames.directory.desktop.in:4
msgid "Action games"
msgstr "Action-Spiele"

#. Translators: Do NOT translate or transliterate this text (this is an icon 
file name)!
#: debian/desktop-files/ActionGames.directory.desktop.in:6
msgid "weather-storm"
msgstr "weather-storm"

#: debian/desktop-files/Settings-System.directory.desktop.in:4
msgid "Administration"
msgstr "Systemverwaltung"

#: debian/desktop-files/Settings-System.directory.desktop.in:5
msgid "Change system-wide settings (affects all users)"
msgstr "Systemweite Einstellungen �ndern (dies betrifft alle Benutzer)"

#. Translators: Do NOT translate or transliterate this text (this is an icon 
file name)!
#: debian/desktop-files/Settings-System.directory.desktop.in:7
msgid "preferences-system"
msgstr "preferences-system"

#: debian/desktop-files/KidsGames.directory.desktop.in:3
msgid "Kids"
msgstr "Kinder"

#: debian/desktop-files/KidsGames.directory.desktop.in:4
msgid "Games for kids"
msgstr "Spiele f�r Kinder"

#. Translators: Do NOT translate or transliterate this text (this is an icon 
file name)!
#: debian/desktop-files/KidsGames.directory.desktop.in:6
msgid "gnome-amusements"
msgstr "gnome-amusements"

#: debian/desktop-files/CardGames.directory.desktop.in:3
msgid "Cards"
msgstr "Karten"

#: debian/desktop-files/CardGames.directory.desktop.in:4
msgid "Card games"
msgstr "Kartenspiele"

#. Translators: Do NOT translate or transliterate this text (this is an icon 
file name)!
#: debian/desktop-files/CardGames.directory.desktop.in:6
msgid "gnome-aisleriot"
msgstr "gnome-aisleriot"

#: debian/desktop-files/Debian.directory.desktop.in:3
msgid "Debian"
msgstr "Debian"

#: debian/desktop-files/Debian.directory.desktop.in:4
msgid "The Debian menu"
msgstr "Das Debian-Men�"

#. Translators: Do NOT translate or transliterate this text (this is an icon 
file name)!
#: debian/desktop-files/Debian.directory.desktop.in:6
msgid "debian-logo"
msgstr "debian-logo"

#: debian/desktop-files/SimulationGames.directory.desktop.in:3
msgid "Simulation"
msgstr "Simulation"

#: debian/desktop-files/SimulationGames.directory.desktop.in:4
msgid "Simulation games"
msgstr "Simulationsspiele"

#: debian/desktop-files/BoardGames.directory.desktop.in:3
msgid "Board"
msgstr "Brett"

#: debian/desktop-files/BoardGames.directory.desktop.in:4
msgid "Board games"
msgstr "Brettspiele"

#. Translators: Do NOT translate or transliterate this text (this is an icon 
file name)!
#: debian/desktop-files/BoardGames.directory.desktop.in:6
msgid "desktop"
msgstr "desktop"

#: debian/desktop-files/GnomeScience.directory.desktop.in:3
msgid "Science"
msgstr "Wissenschaft"

#: debian/desktop-files/GnomeScience.directory.desktop.in:4
msgid "Scientific applications"
msgstr "Wissenschaftliche Anwendungen"

#. Translators: Do NOT translate or transliterate this text (this is an icon 
file name)!
#: debian/desktop-files/GnomeScience.directory.desktop.in:6
msgid "applications-science"
msgstr "applications-science"

#: debian/desktop-files/StrategyGames.directory.desktop.in:3
msgid "Strategy"
msgstr "Strategie"

#: debian/desktop-files/StrategyGames.directory.desktop.in:4
msgid "Strategy games"
msgstr "Strategiespiele"

#: debian/desktop-files/ArcadeGames.directory.desktop.in:3
msgid "Arcade"
msgstr "Arcade"

#: debian/desktop-files/ArcadeGames.directory.desktop.in:4
msgid "Arcade style games"
msgstr "Arcade-artige Spiele"

#. Translators: Do NOT translate or transliterate this text (this is an icon 
file name)!
#: debian/desktop-files/ArcadeGames.directory.desktop.in:6
msgid "gnome-joystick"
msgstr "gnome-joystick"

#: debian/desktop-files/Settings.directory.desktop.in:3
msgid "Preferences"
msgstr "Einstellungen"

#: debian/desktop-files/Settings.directory.desktop.in:4
msgid "Personal preferences"
msgstr "Pers�nliche Einstellungen"

#. Translators: Do NOT translate or transliterate this text (th

Bug#929991: xen: XSA-284: grant table transfer issues on large hosts

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-284.html

Please adjust affected versions as needed.

Regards,
Salvatore



Bug#929993: xen: XSA-292: x86: insufficient TLB flushing when using PCID

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-292.html

Please adjust affected versions as needed.

Regards,
Salvatore

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

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



Bug#929992: xen: XSA-294: x86 shadow: Insufficient TLB flushing when using PCID

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-294.html

Please adjust affected versions as needed.

Regards,
Salvatore

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

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



Bug#928185: unblock: openjdk-11/11.0.3+7-4

2019-06-04 Thread Paul Gevers
Ping... [fixed borked address of doko and added Tony]

On 29-05-2019 20:22, Paul Gevers wrote:
> Control: tags -1 928185 moreinfo
> Control: reopen -1
> 
> Hi,
> 
> On 28-05-2019 23:50, Emmanuel Bourg wrote:
>> Tony Mancill has prepared the tpu upload yesterday and Matthias was ok
>> with 11.0.3+7 in testing [1].
> 
> Can I see a debdiff please?
> 
>> Unless Buster is expected at the end of July I'd advise against having
>> 11.0.4+2 in testing. This version is an early access release, the final
>> 11.0.4 release is expected on July 16th [2]. Debian is currently being
>> criticized [3] for allowing EA versions of OpenJDK in Debian stable, I
>> think it's important to ship Buster with a GA release.
> 
> Then please refrain from uploading the wrong version to unstable, we
> have experimental for that. TPU doesn't get much testing, and for sure
> isn't covered well by our QA yet. So having such a high profile package
> with so much changes going through tpu is awkward.
> 
> Paul



signature.asc
Description: OpenPGP digital signature


Bug#929994: xen: XSA-288: x86: Inconsistent PV IOMMU discipline

2019-06-04 Thread Salvatore Bonaccorso
Source: xen
Version: 4.11.1+26-g87f51bf366-3
Severity: important
Tags: security upstream

Hi

As there are no CVE assigned for the recent XSAs to get a unique
identifier inside Debian for tracking I'm filling an individual bug for
this XSA. Please see

https://xenbits.xen.org/xsa/advisory-288.html

Please adjust affected versions as needed.

Regards,
Salvatore

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

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



Bug#928451: linux: riscv64 updates (change kernel image type to flat image and enable vdso)

2019-06-04 Thread Vagrant Cascadian
Control: tags 928451 pending

On 2019-05-05, Karsten Merker wrote:
> the riscv64 architecture is changing its standard kernel image
> format from ELF to a flat kernel image with a PE/COFF-compatible
> header (similar to arm64) to make EFI stub support possible, so
> we need to ship arch/riscv/boot/Image instead of an ELF vmlinux. 
> This also enables us to get rid of BBL (the RISC-V Berkeley
> BootLoader) and make the move to U-Boot/GRUB on riscv64.

This was just merged to master:

  
https://salsa.debian.org/kernel-team/linux/commit/05218aa3a21b7dff4e8741bafec411ef07f63bf8


> With kernel 5.0 we can now also enable the vdso config option in
> the package for riscv64 as the necessary infrastructure is now in
> the upstream kernel (this wasn't the case when riscv64 support
> was originally added to the Debian kernel package).

This was added in 4.19.x already.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#929990: apparmor: CVE-2016-1585: mount rules grant excessive permissions

2019-06-04 Thread Salvatore Bonaccorso
Source: apparmor
Version: 2.13.2-10
Severity: normal
Tags: security upstream
Forwarded: https://bugs.launchpad.net/apparmor/+bug/1597017
Control: found -1 2.11.0-3+deb9u2
Control: found -1 2.11.0-1 

Hi,

The following vulnerability was published for apparmor. This is
already siscussed in the upstream bug, so this bug is really to track
the 'downstream' status for us in the Debian  BTS. Would technically
not be needed but opted to fill a bug still in the Debian BTS for it.
intrigeri has already explained the siutation in the upstream bug.

CVE-2016-1585[0]:
| In all versions of AppArmor mount rules are accidentally widened when
| compiled.


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-2016-1585
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1585
[1] https://bugs.launchpad.net/apparmor/+bug/1597017

Regards,
Salvatore



Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)

2019-06-04 Thread Paul Gevers
Hi Michael, Jonathan,

On Tue, 4 Jun 2019 14:11:23 +0100 Jonathan Wiltshire  wrote:
> On Mon, May 27, 2019 at 08:23:09AM +0300, Michael Tokarev wrote:
> > I've prepared next release of the qemu debian package, with
> > a few bugfixes, and am asking if it's okay to upload these
> > changes to unstable (targetting buster). The change includes
> > 3 security fixes which should go anyway, and 2 "other" fixes
> > which are questionable, hence the pre-approval bugreport/question.
> 
> Unblocked; thanks.

qemus migration is blocked by gcc-8, which nobody unblocked so far, so
that is probably not going to happen. I think this should be fixed via tpu.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#929989: unblock: hugo/0.55.6+really0.54.0-1

2019-06-04 Thread Dr. Tobias Quathamer
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package hugo

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock hugo/0.55.6+really0.54.0-1

Regards,
Tobias
diff -Nru hugo-0.54.0/debian/changelog hugo-0.55.6+really0.54.0/debian/changelog
--- hugo-0.54.0/debian/changelog	2019-02-01 19:13:18.0 +0100
+++ hugo-0.55.6+really0.54.0/debian/changelog	2019-06-04 21:16:36.0 +0200
@@ -1,3 +1,65 @@
+hugo (0.55.6+really0.54.0-1) unstable; urgency=medium
+
+  * Revert all changes between 0.54.0-1 and 0.55.6-2.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Tue, 04 Jun 2019 21:16:36 +0200
+
+hugo (0.55.6-2) unstable; urgency=medium
+
+  * Increase "go test" timeout to 60m to accommodate slow mips builders,
+namely mips-aql-04 and mips-aql-05.
+
+ -- Anthony Fok   Thu, 23 May 2019 14:51:17 -0600
+
+hugo (0.55.6-1) unstable; urgency=medium
+
+  * New upstream version 0.55.6
+
+ -- Anthony Fok   Thu, 23 May 2019 11:25:31 -0600
+
+hugo (0.55.5-1) unstable; urgency=medium
+
+  * New upstream version 0.55.5
+  * Update dependency on blackfriday to >= 1.5.2~
+
+ -- Anthony Fok   Sat, 11 May 2019 06:38:20 -0600
+
+hugo (0.55.4-1) unstable; urgency=medium
+
+  * New upstream version 0.55.4
+
+ -- Anthony Fok   Thu, 25 Apr 2019 14:34:37 -0600
+
+hugo (0.55.3-1) unstable; urgency=medium
+
+  * New upstream version 0.55.3
+
+ -- Anthony Fok   Thu, 25 Apr 2019 14:27:20 -0600
+
+hugo (0.55.2-1) unstable; urgency=medium
+
+  * New upstream version 0.55.2
+  * Add debian/missing-sources for app.bundle.js
+
+ -- Anthony Fok   Thu, 25 Apr 2019 13:48:05 -0600
+
+hugo (0.55.1-1) unstable; urgency=medium
+
+  * New upstream version 0.55.1
+  * Update files list in debian/copyright
+
+ -- Anthony Fok   Sun, 14 Apr 2019 13:36:44 -0600
+
+hugo (0.55.0-1) unstable; urgency=medium
+
+  * New upstream version 0.55.0
+  * Update dependencies as per upstream go.mod
+  * Update files list and copyright years in debian/copyright
+  * Refresh 004-increase-timeout-in-TestPageBundlerSiteRegular.patch
+
+ -- Anthony Fok   Sun, 14 Apr 2019 04:46:30 -0600
+
 hugo (0.54.0-1) unstable; urgency=medium
 
   * New upstream version 0.54.0


signature.asc
Description: OpenPGP digital signature


Bug#929988: unblock: gokey/0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-1

2019-06-04 Thread Dr. Tobias Quathamer
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gokey

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock gokey/0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-1

Regards,
Tobias
diff -Nru gokey-0.0~git20181023.b4e2780/debian/changelog gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
--- gokey-0.0~git20181023.b4e2780/debian/changelog	2019-01-01 06:27:28.0 +0100
+++ gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog	2019-06-04 20:53:29.0 +0200
@@ -1,3 +1,25 @@
+gokey (0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 0.0~git20181023.b4e2780-1
+and 0.0~git20190103.40eba7e-1.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Tue, 04 Jun 2019 20:53:29 +0200
+
+gokey (0.0~git20190103.40eba7e-1) unstable; urgency=medium
+
+  * New upstream version 0.0~git20190103.40eba7e
+ - Import deterministic RSA key generation code from Go 1.10
+   crypto/rsa package
+ - Add a test-case which tracks changes to the stdlib RSA key
+   generation algorithm
+  * Revert "Disable TestGetKey tests for RSA2048 and RSA4096"
+because these tests now pass with Go 1.11
+  * Remove unneeded "Depends: golang-go" in -dev package
+
+ -- Anthony Fok   Mon, 07 Jan 2019 23:12:50 -0700
+
 gokey (0.0~git20181023.b4e2780-1) unstable; urgency=medium
 
   * New upstream version 0.0~git20181023.b4e2780


signature.asc
Description: OpenPGP digital signature


Bug#929634: easy-rsa: Program name mismatch in manpage

2019-06-04 Thread Michele Orru

On 5/27/19 6:35 PM, Christoph Biedl wrote:


Hi Cristoph!

Sorry for the late reply; I fixed the bug on salsa, and will upload a 
new version for it soon.


Thanks,
--
μ.



Bug#929956: unblock: glib2.0/2.58.3-2

2019-06-04 Thread Cyril Brulebois
Simon McVittie  (2019-06-04):
> Please unblock package glib2.0 to fix CVE-2019-12450.
> 
> glib2.0 builds a udeb (for the graphical installer) so this will need
> a d-i ack.
> 
> unblock glib2.0/2.58.3-2
> unblock-udeb glib2.0/2.58.3-2

Tests look good, no objections from the d-i side.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#929983: ipxe-qemu: virtio booting no longer works after upgrade to buster

2019-06-04 Thread Vagrant Cascadian
On 2019-06-04, Thorsten Glaser wrote:
> On this virtualisation system I’ve upgraded to buster (using libvirt and
> Linux-kvm), netbooting VMs no longer works:
>
>
> -BEGIN cutting here may damage your screen surface-
> SeaBIOS (version 1.12.0-1)
> Machine UUID …
>
> Press ESC for boot menu.
>
> Booting from Hard disk...
> Boot failed: not a bootable disk
>
> No bootable device.
> _
> -END cutting here may damage your screen surface-

Works for me using a virt-manager configured with virtio or the
hypervisor default for netoworking with the same seabios and ipxe
versions. My system was recently upgraded from stretch to buster.

Could you provide more detail about your configured virtual machine?


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#929987: ycmd: Node.js code completion not working

2019-06-04 Thread fvonbergen
Package: ycmd
Version: 0+20181101+git600f54d-0.1+b2
Severity: normal
Tags: upstream

Dear Maintainer,

I think that the bug should be filled in ycmd, but I found the bug using vim-
youcompleteme.

While trying to use vim-youcompleteme for Node.js code completion it didn't
work. For example, doing:


import * as os from 'os';

os.


and trying to autocomplete os. is not possible.

After reading the youcompleteme/ycmd source code and the debian installation
files, I've found that ycmd uses tsserver (3.3.) for code completion.
Currently in debian buster that version is packaged as node-typescript. I think
that the node-typescript should be a dependency and not recommended for ycmd.
Afterwards in order for ycmd to use the tsserver, I propose to add a tsserver
folder to /usr/lib/ycmd/thirdparty/tsserver with folders bin, etc and lib with
the corresponding links to the node-typescript files (replicate the usage of
youcompleteme, but using symlinks to the node-typescript files). That way
ycm_extra_conf.py from ycmd will be able to find the tsserver.
Finally the file
/usr/lib/ycmd/ycmd/completers/typescript/typescript_completer.py in line 208
contains an error. Instead of self._tsserver_command it should be
self._tsserver_executable.

I'm not able to perform the changes because I don't have the know how, but I
tried them and after the changes it worked for me. In my case instead of using
the node-typescript, I copied the tsserver in the third_party folder directly.



PD: Considering this changes the vim-youcompleteme installation for the user
space (using vim-addons) should add a symlink to the ycm_extra_conf.py inside
~/.vim/.ycm_extra_conf.py.



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

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

Versions of packages ycmd depends on:
ii  libboost-filesystem1.67.0  1.67.0-13
ii  libboost-regex1.67.0   1.67.0-13
ii  libboost-system1.67.0  1.67.0-13
ii  libc6  2.28-10
ii  libclang1-71:7.0.1-8
ii  libgcc11:8.3.0-6
ii  libpython3.7   3.7.3-2
ii  libstdc++6 8.3.0-6
ii  python33.7.3-1
ii  python3-bottle 0.12.15-2
ii  python3-frozendict 1.2-1
ii  python3-future 0.16.0-1
ii  python3-jedi   0.13.2-1
ii  python3-requests   2.21.0-1
ii  python3-waitress   1.2.0~b2-2

Versions of packages ycmd recommends:
ii  libclang-common-7-dev  1:7.0.1-8
ii  node-typescript3.3.-1
ii  vim-youcompleteme  0+20190211+gitcbaf813-0.1

ycmd suggests no packages.

-- no debconf information



Bug#929986: flash-kernel: configfile wrongly handled by both debconf and ucf

2019-06-04 Thread Jonas Smedegaard
Package: flash-kernel
Version: 3.99
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Editing by hand the configfile /etc/default/flash-kernel
and then running "dpkg-reconfigure flash-kernel" bogusly presents string
"quiet" regardless of actual content in the configfile.
Pressing enter without editing does _not_ apply "quiet" but does nothing.
Editing and pressing enter triggers a ucf tristate dialogue.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlz2uAwACgkQLHwxRsGg
ASH78A/+J4cGGKOqlTJEMLSFFbJb9eDB+eiCDrnMYwnUilwuTXZHtZXn0XQJPVMR
em5Qk617rC4hyBy0kR8MI/sCRzSlNBo02BF8TRuuFTDyk6frrA/iFC/oyCSmfyL7
Kn4AuL+g9fwPZJllS0GL/aL3tyK16qx1hKss1lnoq57GCRmdtNpKuREEykObIWeZ
ndjvJyzWB7TLrW7b4SA3eUzxfpZSX/R3ZveJPaudCTTuehefMFPp+04ECcA9+xxt
l2vyYz3FjdXDTJwNkwfBKzzobUAFUEponap0MCYNZcmB8Dk7pJ8rEKET/r6fJH5o
Euab3YpcoFoIdOzhVrbJpOXnEv9mbZZWT/CpYKE1KFvnPiSy/+UoX2egaqxI7qJG
D0oiHZzhJlVf/KZNaFPgkvXcvqgSCo6uk8LbgFH45w0iQqpsYofOj0HanTLrwto/
G1n9zISGwUqJ9bjXlek4O1hyj/UenGu1UiwnKdbMdZ6sh447c3cZTF9A+8fVs+F5
T7SHScd82+Hic6qWNuD5VDZS0jFUDPI6LOGcSnvHfxLOidJcoHxT/N+yFeM2Bw23
H5XU38aIx3OfnLjK7BhwBGAkUHoKcwBgtcjvkh7036q9p3mCWWOpFra7FdB74GuQ
6sDkdT27yrUK2Q50s8RdmgwWYf3RYy78Pe4Q7o4skM7Y8A5a5yE=
=yXrk
-END PGP SIGNATURE-



Bug#929907: libgnutls30: Connections to older GnUTLS servers break

2019-06-04 Thread Andreas Metzler
On 2019-06-03 Dominik George  wrote:
> Hi,

>> Is this reproducile with gnutls-cli or is the respective server
>> publically accessible? 

> It is reproducible.

> 1. Create a buster chroot for the server, or something
>similar.
> 2. Install gnutls-bin 3.6.6-3 and ssl-cert.
> 3. Start something like:
>gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key 
> --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem
> 4. Create a buster chroot for the client.
> 5. Install gnutls-bin 3.6.7-2 and pwgen (I used that to generate
>random blobs of printable data).
> 6. Try:
>pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost

> From a size of 16383 bytes onwards, I get:

> |<1>| Received packet with illegal length: 16385
> |<1>| Discarded message[1] due to invalid decryption
> *** Fatal error: A TLS record packet with invalid length was received.
> *** Server has terminated the connection abnormally.

Hello,

with server at 3.6.6 (and .4 and .5) , client version 3.6.7 breaks, while
both earlier versions and 3.6.8 connect successfully.

server 3.6.8/3.6.7 does not break with client 3.6.7.

Will try a bisect to check why .8 works, but might not have time before
weekend.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Bug#929597: CVE-2019-12211 CVE-2019-12212 CVE-2019-12213 CVE-2019-12214

2019-06-04 Thread Anton Gladky
severity 929597 important
thanks

The fix from upstream is still not available. I am not feeling
confident enough to provide a fix for this complex peace
of code without breaking it.

Also reducing the severity. If the security team decides to
keep it "grave" - feel free to revert it.

Regards


Anton

Am Mo., 3. Juni 2019 um 20:23 Uhr schrieb Anton Gladky :
>
> There is no upstream fix still available.
>
> I am planning to decrease the severity of
> the ticket to normal and track it as a simple
> security issue.
>
> Anton
>
> Am Mo., 27. Mai 2019 um 23:01 Uhr schrieb Anton Gladky :
> >
> > CVE-2019-12214 does not affect buster and stretch.
> > Jessie should be double checked because an older
> > version is used there.
> >
> > Anton
> >
> > Am So., 26. Mai 2019 um 22:01 Uhr schrieb Anton Gladky :
> > >
> > > Hi Moritz,
> > >
> > > thanks for the reporting. As far as I see, there is still
> > > no available fix from upstream.
> > >
> > > Cheers
> > >
> > > Anton
> > >
> > > Am So., 26. Mai 2019 um 21:27 Uhr schrieb Moritz Muehlenhoff 
> > > :
> > > >
> > > > Source: freeimage
> > > > Severity: grave
> > > > Tags: security
> > > >
> > > > Please see
> > > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12211
> > > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12212
> > > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12213
> > > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12214
> > > >
> > > > Cheers,
> > > > Moritz
> > > >
> > > > --
> > > > debian-science-maintainers mailing list
> > > > debian-science-maintain...@alioth-lists.debian.net
> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers



Bug#929985: ftp.debian.org: Not maintained for years; low popcon

2019-06-04 Thread Paul van Tilburg
Package: ftp.debian.org
Severity: normal

Dear FTP masters,

Please remove the mcrl2 from unstable (and thereby Buster).
It has not been maintained in Debian for years and the popcon is very
low. It might return later if upstream packaging work is pushed
towards Debian again?

Kind regards,
Paul



Bug#929984: lspci: please make -nn the default

2019-06-04 Thread Greg Wooledge
Package: pciutils
Version: 1:3.5.2-1
Severity: wishlist

Very frequently, people ask for help with their devices (video, network,
etc.) and someone asks them to show the output of lspci.  Which they
eventually do.  But it would be *so* much more helpful if they would
show the output of "lspci -nn" instead.  Unfortunately, educating the
entire helper community to ask for lspci -nn instead of plain lspci is
an extremely slow process.

It would be great if -nn were the default.  People requesting help could
get that help much more quickly and with less wasted effort, if we didn't
have to go through an extra round of asking for information.

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

Kernel: Linux 4.19.0-4-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 pciutils depends on:
ii  libc6 2.28-10
ii  libkmod2  26-1
ii  libpci3   1:3.5.2-1

pciutils recommends no packages.

Versions of packages pciutils suggests:
ii  bzip2  1.0.6-9
ii  curl   7.64.0-3
ii  wget   1.20.1-1.1

-- debconf-show failed



Bug#929983: ipxe-qemu: virtio booting no longer works after upgrade to buster

2019-06-04 Thread Thorsten Glaser
Package: ipxe-qemu
Version: 1.0.0+git-20190125.36a4c85-1
Severity: serious
Justification: makes package unusable

On this virtualisation system I’ve upgraded to buster (using libvirt and
Linux-kvm), netbooting VMs no longer works:


-BEGIN cutting here may damage your screen surface-
SeaBIOS (version 1.12.0-1)
Machine UUID …

Press ESC for boot menu.

Booting from Hard disk...
Boot failed: not a bootable disk

No bootable device.
_
-END cutting here may damage your screen surface-


If I, however, change the NIC to pcnet, it works:

-BEGIN cutting here may damage your screen surface-
SeaBIOS (version 1.12.0-1)
Machine UUID …


iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+…




Press ESC for boot menu.

Booting from Hard disk...
Boot failed: not a bootable disk

Booting from ROM...
iPXE (PCI 00:03.0) starting execution... ok
iPXE initialising devices...ok


iPXE 1.0.0+git-20190125.36a4c85-1 -- Open Source […]
-END cutting here may damage your screen surface-


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

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

-- no debconf information


Bug#929982: chromium: stretch/updates security version won't display google's Oswald font.

2019-06-04 Thread Jaimos Skriletz
Package: chromium
Version: 73.0.3683.75-1~deb9u1
Severity: normal

The version of chromium in stretch no longer displays fonts on
webpages I use regularly. The font in question is googles' Oswald font
at the following link:

https://fonts.google.com/specimen/Oswald

Those fonts all vanish after the page is loaded (except for a few
symbols). The fonts should look like

https://i.imgur.com/2ZwgcIA.png

The font does display in google-chrome, firefox, and the previous
version of chromium.

Members of #debian have tested that the fonts also display on
73.0.3684.75-1 version in buster and verified that the fonts are not
displaying for them in the stretch/updates version. So there is
something with either the build of the security package (or a library
in stretch) causing the fonts to not work in the stable version.

jaimos

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/8 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 chromium depends on:
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libatomic1   6.3.0-18+deb9u1
ii  libatspi2.0-02.22.0-6+deb9u1
ii  libavcodec57 7:3.2.14-1~deb9u1
ii  libavformat577:3.2.14-1~deb9u1
ii  libavutil55  7:3.2.14-1~deb9u1
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8+deb9u3
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdrm2  2.4.74-1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.0-2+deb9u1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libicu57 57.1-6+deb9u2
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1.1+deb9u1
ii  libopenjp2-7 2.1.2-1.1+deb9u3
ii  libopus0 1.2~alpha2-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.28-1+deb9u1
ii  libpulse010.0-1+deb9u1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.3.0-18+deb9u1
ii  libvpx4  1.6.1-3+deb9u1
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libwebpmux2  0.5.2-1
ii  libx11-6 2:1.6.4-3+deb9u1
ii  libx11-xcb1  2:1.6.4-3+deb9u1
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+deb9u2
ii  libxdamage1  1:1.1.4-2+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2.1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3+b1
ii  xdg-utils1.1.1-1+deb9u1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2
ii  libgl1-mesa-dri   13.0.6-1+b2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information



Bug#929912: unblock: ltsp/5.18.12-3

2019-06-04 Thread Cyril Brulebois
Niels Thykier  (2019-06-04):
> Control: tags -1 confirmed d-i
> 
> Vagrant Cascadian:
> > Please unblock package ltsp
> > 
> > unblock ltsp/5.18.12-3
> 
> Looks good to me, CC'ing KiBi for a d-i ack before completing the unblock.

No objections, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#929913: unblock: simple-cdd/0.6.7

2019-06-04 Thread Cyril Brulebois
Niels Thykier  (2019-06-04):
> Vagrant Cascadian:
> > unblock simple-cdd/0.6.7
> 
> Looks good to me, CC'ing KiBi for a d-i ack before completing the unblock.

No objections, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#929913: unblock: simple-cdd/0.6.7

2019-06-04 Thread Niels Thykier
Vagrant Cascadian:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: vagr...@debian.org, debian-b...@lists.debian.org
> 
> Please unblock package simple-cdd
> 
> This update fixes several release-critical and important bugs, as well
> as documentation updates.
> 
> Several issues were reported with expired keys in the archive keyring
> breaking builds with simple-cdd, even when the expired key was not
> used to verify the repositories being checked. This was fixed by
> allowing expired keys to be present in the keyring used by reprepro
> (though are not treated as valid for verifying Release files).
> 
> A typo was fixed that caused a traceback in gpg verification, and now
> reports the failing command.
> 
> The --batch argument was added to gpg calls, which are all
> non-interactive, which allows it to work in docker environments.
> 
> Contact information in the README was no longer valid, and so it was removed.
> 
> Fix a number of issues with changes in qemu arguments, and re-add the
> missing support to pass arbitrary qemu options.
> 
> Update example configuration files, removing obsolete options and
> adjusting a syntax change in some options which no longer support
> variables.
> 
> The ltsp profile was updated to use the defaults for
> ltsp-client-builder, with commented examples for using the non-default
> values. NFS is no longer used in LTSP by default, so is no longer
> configured, and the example to configure DHCP was updated to use
> dnsmasq.
> 
> The test profile was updated with new and changed preseeding options,
> as well as options passed to qemu.
> 
> The default profile updated the example to avoid asking to set up
> another CD.
> 
> The router profile example ethernet interface name was updated to be
> consistant with current naming conventions.
> 
> [...]
> 
> 
> unblock simple-cdd/0.6.7
> 
> 
> Thanks for all your work towards releasing Debian!
> 
> live well,
>   vagrant
> 

Looks good to me, CC'ing KiBi for a d-i ack before completing the unblock.

Thanks,
~Niels



Bug#929980: kwallet-kf5 FTCBFS: missing Build-Depends: qttools5-dev

2019-06-04 Thread Helmut Grohne
Source: kwallet-kf5
Version: 5.54.0-1
Tags: pending

kwallet-kf5 fails to cross build from source. This is fixed in git:
https://salsa.debian.org/qt-kde-team/kde/kwallet/commit/d825523fe88c40b64f5052da048aa60326064c56
Please close this bug with the next upload to trigger a qa rebuild.

Helmut



Bug#929912: unblock: ltsp/5.18.12-3

2019-06-04 Thread Niels Thykier
Control: tags -1 confirmed d-i

Vagrant Cascadian:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: vagr...@debian.org, debian-b...@lists.debian.org
> 
> Please unblock package ltsp
> 
> This fixes two release-critical bugs, an important bug, and updates
> the debconf translation for Dutch.
> 
> Builds from unsigned CDs failed due to changes in apt being more
> strict regarding unsigned repositories. This is fixed by passing the
> --trust-file-mirror option introduced in ltsp-build-client upstream,
> but not added to the default arguments for the ltsp-client-builder
> .udeb. This .udeb is not used in the default debian-installer images,
> and thus should have no impact on them.
> 
> The tool to build an LTSP chroot environment failed to detect the
> codename in buster now that /etc/debian_version contains a version,
> instead passing the version of Debian "10" to debootstrap, resulting
> in a failure to build. The upstream fix was to switch back to using
> lsb_release, and the patch applied to this version.
> 
> An important issue in the arguments for mounting loopback images was
> discovered and fixed upstream, ensuring read-only mounts which might
> otherwise lead to filesystem inconsistancies with ext4 or other
> writeable filesystems, and fixing a typo in the loop argument passed
> to mount. The upstream patch is included in this version.
> 
> Additionally, the Dutch debconf message translation was included in
> this version.
> 
> [...]
> 
> unblock ltsp/5.18.12-3
> 
> 
> Thanks for all your work on releasing Debian!
> 
> 
> live well,
>   vagrant
> 

Looks good to me, CC'ing KiBi for a d-i ack before completing the unblock.

Thanks,
~Niels



Bug#929977: move vanessa-logger.pc to a multiarch location

2019-06-04 Thread Helmut Grohne
Package: libvanessa-logger-dev
Version: 0.0.10-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:perdition

perdition fails to cross build from source, because it cannot find
vanessa-logger.pc. During cross compilation, pkg-config only searches
/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig and /usr/share/pkgconfig. It
doesn't search /usr/lib/pkgconfig. Thus vanessa-logger.pc needs to be
moved. Please consider applying the attached patch.

Helmut
diff -u vanessa-logger-0.0.10/debian/changelog 
vanessa-logger-0.0.10/debian/changelog
--- vanessa-logger-0.0.10/debian/changelog
+++ vanessa-logger-0.0.10/debian/changelog
@@ -1,3 +1,10 @@
+vanessa-logger (0.0.10-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move pkg-config file to a multiarch location. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 04 Jun 2019 18:17:12 +0200
+
 vanessa-logger (0.0.10-3) unstable; urgency=medium
 
   * Build verbosely (make V=1) so that compiler flags are not hidden
diff -u vanessa-logger-0.0.10/debian/rules vanessa-logger-0.0.10/debian/rules
--- vanessa-logger-0.0.10/debian/rules
+++ vanessa-logger-0.0.10/debian/rules
@@ -2,8 +2,10 @@
 # Sample debian/rules that uses debhelper.
 # GNU copyright 1997 to 1999 by Joey Hess.
 
+include /usr/share/dpkg/architecture.mk
+
 pwd:=$(shell pwd)
-cfg:=--prefix=/usr --mandir=/usr/share/man
+cfg:=--prefix=/usr --mandir=/usr/share/man 
--libdir='$${prefix}/lib/$(DEB_HOST_MULTIARCH)'
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
only in patch2:
unchanged:
--- vanessa-logger-0.0.10.orig/debian/libvanessa-logger-dev.files
+++ vanessa-logger-0.0.10/debian/libvanessa-logger-dev.files
@@ -1,8 +1,8 @@
 usr/include/vanessa_logger.h
-usr/lib/libvanessa_logger.so
-usr/lib/libvanessa_logger.a
-usr/lib/libvanessa_logger.la
-usr/lib/pkgconfig/vanessa-logger.pc
+usr/lib/*/libvanessa_logger.so
+usr/lib/*/libvanessa_logger.a
+usr/lib/*/libvanessa_logger.la
+usr/lib/*/pkgconfig/vanessa-logger.pc
 usr/share/doc/libvanessa-logger-dev/changelog.gz
 usr/share/doc/libvanessa-logger-dev/README
 
only in patch2:
unchanged:
--- vanessa-logger-0.0.10.orig/debian/libvanessa-logger0.files
+++ vanessa-logger-0.0.10/debian/libvanessa-logger0.files
@@ -1,2 +1,2 @@
-usr/lib/libvanessa_logger.so.0
-usr/lib/libvanessa_logger.so.0.0.5
+usr/lib/*/libvanessa_logger.so.0
+usr/lib/*/libvanessa_logger.so.0.0.5


Bug#929978: perdition FTCBFS: does not pass --host to ./configure

2019-06-04 Thread Helmut Grohne
Source: perdition
Version: 2.2-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

perdition fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - is not sufficient to make perdition cross buildable
as it also fails finding vanessa-logger.pc. I'm filing a separate patch
against libvanessa-logger-dev about that. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru perdition-2.2/debian/changelog 
perdition-2.2/debian/changelog
--- perdition-2.2/debian/changelog  2016-12-06 17:08:39.0 +0100
+++ perdition-2.2/debian/changelog  2019-06-04 18:14:01.0 +0200
@@ -1,3 +1,10 @@
+perdition (2.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Address FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: 
#-1)
+
+ -- Helmut Grohne   Tue, 04 Jun 2019 18:14:01 +0200
+
 perdition (2.2-3) unstable; urgency=high
 
   * Correct syntax of ldconfig trigger
diff --minimal -Nru perdition-2.2/debian/rules perdition-2.2/debian/rules
--- perdition-2.2/debian/rules  2016-05-11 08:34:19.0 +0200
+++ perdition-2.2/debian/rules  2019-06-04 18:14:00.0 +0200
@@ -6,7 +6,7 @@
 include /usr/share/dpkg/buildflags.mk
 
 pwd:=$(shell pwd)
-cfg:=--prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-group=nogroup 
--mandir=/usr/share/man --with-ldap-schema-directory=no --disable-ldap-doc 
--enable-shared
+cfg:= --with-group=nogroup --with-ldap-schema-directory=no --disable-ldap-doc 
--enable-shared
 
 build: build-arch build-indep
 
@@ -17,7 +17,7 @@
 build-stamp:
dh_testdir
dh_autoreconf
-   ./configure $(shell dpkg-buildflags --export=configure) $(cfg)
+   dh_auto_configure -- $(shell dpkg-buildflags --export=configure) $(cfg)
# Lame libtool workaround that lintian seems keen on
sed < libtool > libtool-2 \
-e 
's/^hardcode_libdir_flag_spec.*$$/hardcode_libdir_flag_spec=" 
-D__LIBTOOL_IS_A_FOOL__ "/' \


Bug#929979: courier-authlib FTCBFS: fails finding mysql library

2019-06-04 Thread Helmut Grohne
Source: courier-authlib
Version: 0.69.0-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: rebootstrap

courier-authlib fails to cross build from source, because it fails
finding mysql libraries. It tries doing so using mysql_config, but
that's unusable during cross compilation. A better approach is using
pkg-config. The attached patch makes courier-authlib try pkg-config
before mysql_config and makes courier-authlib cross buildable. Please
consider applying it.

Helmut
--- courier-authlib-0.69.0.orig/configure.ac
+++ courier-authlib-0.69.0/configure.ac
@@ -555,6 +555,7 @@
 	MYSQL_CFLAGS="-I$withval"
 )
 
+PKG_CHECK_MODULES([MYSQL],[mysqlclient],[],[
 AC_PATH_PROGS(MYSQL_CONFIG, mysql_config, mysql_config, $LPATH)
 
 if test -x "$MYSQL_CONFIG"
@@ -565,6 +566,7 @@
 	eval "MYSQL_CFLAGS=\"\`echo $MYSQL_CFLAGS\`\""
 	eval "MYSQL_LIBS=\"\`echo $MYSQL_LIBS\`\""
 fi
+])
 
 if test "$doauthmysql" = ""
 then


Bug#929793: liblopsub: please make the build reproducible

2019-06-04 Thread Chris Lamb
Andre Noll wrote:

> Then I don't grok the purpose of the
> 
>   LC_ALL=C date -u -r '$(SOURCE_DATE_EPOCH)' '$(DATE_FMT)'
> 
> command. After all, at least GNU date(1) expects a filename as the
> argument to -r.

I do not have access to such a system but I believe this is for BSD
variants of date(1), hence the waterfall of ||'s.

Your patch looks great, thanks. :)


Best wishes,

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



Bug#929613: stretch-pu: package minissdpd/1.2.20130907-4.1+deb9u1

2019-06-04 Thread Chris Lamb
Hi Adam,

> On Mon, 2019-05-27 at 10:17 +0100, Chris Lamb wrote:
> >   minissdpd (1.2.20130907-4.1+deb9u1) stretch; urgency=medium
> >   
> > * CVE-2019-12106: Prevent a use-after-free vulnerability that
> >   would allow a remote attacker to crash the process. (Closes: #929297)
> 
> Please go ahead.

minissdpd_1.2.20130907-4.1+deb9u1_amd64.changes uploaded.


Best wishes,

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



Bug#929976: /usr/sbin/xtables-nft-multi: ebtables-nft-restore errors with -o option on chains which ebtables-legacy-restore accepts

2019-06-04 Thread Thomas Lamprecht
Package: iptables
Version: 1.8.2-4
Severity: important
File: /usr/sbin/xtables-nft-multi

Dear Maintainer,

When using the '-o' / '--out-interface' option I get a regression
between legacy ebtables and new nft backed ebtables.

E.g., using the following rules:

# cat ebtables-fwd-no-o-options-allowed.rules
*filter
:PVEFW-FORWARD ACCEPT
:PVEFW-FWBR-OUT ACCEPT
-A PVEFW-FORWARD -p IPv4 -j ACCEPT
-A PVEFW-FORWARD -p IPv6 -j ACCEPT
-A PVEFW-FORWARD -o fwln+ -j PVEFW-FWBR-OUT
-A FORWARD -j PVEFW-FORWARD

Which are as is looking a bit useless, so it should be stated that this
is only the boilerplate for triggering this regression, we insert rules
for vitrual machine and Linux containers here, those are omitted to keep
the trigger more minimal.

I can successfully restoring those ebtables under Stretch or using the
legacy ebtables, e.g., by doing:
# cat ebtables-fwd-no-o-options-allowed.rules |  ebtables-legacy-restore

But using the new nft backed command I get the following error:
# cat ebtables-fwd-no-o-options-allowed.rules |  ebtables-nft-restore
Use -o only in OUTPUT, FORWARD and POSTROUTING chains.

While the man page talks about the option being useful in combination
with the by the errorr mentioned chains, it does not states that it's
forbidden to use it with others, also the behaviour the legacy tool
shows supports this:

> -o, --out-interface [!] name
>   The interface (bridge port) via which a frame  is  going  to  be
>   sent (this option is useful in the OUTPUT, FORWARD and POSTROUT‐
>   ING chains). If the interface name ends with '+', then  any  in‐
>   terface  name that begins with this name (disregarding '+') will
>   match.  The flag --out-if is an alias for this option.
-- man ebtables-legacy

I tested also with the 1.8.3-1~exp1 release of iptables currently in
experimental, same behaviour here.

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

Kernel: Linux 5.0.8-050008-generic (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iptables depends on:
ii  libc62.28-10
ii  libip4tc01.8.2-4
ii  libip6tc01.8.2-4
ii  libiptc0 1.8.2-4
ii  libmnl0  1.0.4-2
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.2-2
ii  libxtables12 1.8.2-4

Versions of packages iptables recommends:
ii  nftables  0.9.0-2

Versions of packages iptables suggests:
ii  kmod  26-1

-- no debconf information


Bug#929903: openssl: m2crypto test case regression

2019-06-04 Thread Kurt Roeckx
On Tue, Jun 04, 2019 at 02:24:12PM +0200, Matěj Cepl wrote:
> Sebastian Andrzej Siewior píše v Út 04. 06. 2019 v 14:15 +0200:
> > Let me ping upstream: Matěj, could you please take a look at
> > https://bugs.debian.org/929903
> > 
> > and check if it is okay the test no longer fails or if openssl suddenly
> > eats up the error code. Afterall:
> 
> OK, I have this commit now in the master 
> https://gitlab.com/m2crypto/m2crypto/commit/f287d7145b5f but I am
> still not certain that sslv23_padding and especially no_padding
> should lead to error, shouldn't it?

Did something change related to a no padding test? If there is no
padding, as far as I know decryption should always work.

The sslv23_padding code in OpenSSL that checks the padding
was broken, it returned an error in the case it should return ok.


Kurt



Bug#929482: cacti: After apt-get install cacti, the installation stated something old version DB(?) and does not proceed.

2019-06-04 Thread ISHIKAWA,chiaki

On Sat, 25 May 2019 10:18:06 +0200 Paul Gevers  wrote:
> Control: tags -1 moreinfo
>
> Hi ISHIKAWA,
>
> Thanks for reporting issues you encounter.
>
> On 24-05-2019 13:00, ISHIKAWA,chiaki wrote:
>
> dbconfig-generate-include is part of dbconfig-common. Can you check that
> you have a file
> /usr/sbin/dbconfig-generate-include?
>
> Are you by any chance running a usr-merged setup?
>
> Paul
>


Hi,

Sorry I missed reading this earlier.

I checked and I did have dbconfi-geneate-include:


env LANG=C ls -l /usr/sbin/db*
-rwxr-xr-x 1 root root 12663 Dec 13 18:32 
/usr/sbin/dbconfig-generate-include

-rwxr-xr-x 1 root root  5707 Dec 13 18:32 /usr/sbin/dbconfig-load-include



> Are you by any chance running a usr-merged setup?

I was not sure what you mean by "usr-merged".

I searched and came up with this web page.

https://wiki.debian.org/UsrMerge

usr-merged: I don't think so...

env LANG=C ls -ld /bin /sbin /lib
drwxr-xr-x  2 root root  4096 May 10 10:18 /bin
drwxr-xr-x 19 root root  4096 May 20 06:20 /lib
drwxr-xr-x  2 root root 12288 May 10 10:18 /sbin

I checked that /bin and /usr/sbin, /lib and /usr/lib and /sbin and 
/usr/sbin contained

different number of files under them.

TIA



Bug#929927: python-django: CVE-2019-12308: AdminURLFieldWidget XSS

2019-06-04 Thread Luke Faraone
Yep, planning on tackling this evening. (PDT)

Per discussion with Security Team a DSA isn't warranted for this issue.

On Tue, 4 Jun 2019 at 10:11, Chris Lamb  wrote:

> [Adding lfara...@debian.org to CC]
>
> Salvatore Bonaccorso wrote
>
> > CVE-2019-12308[0]:
> > AdminURLFieldWidget XSS
> >
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> >
> > For further information see:
> >
> > [0] https://security-tracker.debian.org/tracker/CVE-2019-12308
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12308
> > [1] https://www.djangoproject.com/weblog/2019/jun/03/security-releases/
>
> Luke, do you still plan to take this as discussed during the embargo? I
> might have some bandwidth the next day or so if not, but let me know.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
>`-
>


-- 

Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs; MIT SIPB
lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello
PGP fprint: 8C82 3DED 10AA 8041 639E  1210 5ACE 8D6E 0C14 A470


Bug#929975: python-numpy: move python3-matplotlib dependency to depend-indep

2019-06-04 Thread Jason Duerstock
Package: python-numpy
Version: 1:1.16.2-1
Severity: normal
Tags: patch

Dear Maintainer,

The build dependency on python3-matplotlib creates an unnecessary build
dependency loop.  I believe the attached patch fixes the packaging so
that python3-matplotlib is only required when building the
documentation.

-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

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

Versions of packages python-numpy depends on:
ii  libblas3 [libblas.so.3]  3.8.0-2
ii  libc6.1  2.28-2
ii  liblapack3 [liblapack.so.3]  3.8.0-2
ii  libunwind8   1.2.1-9
ii  python   2.7.15-4
ii  python-pkg-resources 40.8.0-1
ii  python2.72.7.16-2

python-numpy recommends no packages.

Versions of packages python-numpy suggests:
ii  gcc   4:8.3.0-1
ii  gfortran  4:8.3.0-1
ii  python-dev2.7.15-4
ii  python-numpy-dbg  1:1.16.2-1
pn  python-numpy-doc  
ii  python-pytest 3.10.1-2

-- no debconf information
--- a/debian/control2019-03-02 11:30:12.0 -0500
+++ b/debian/control2019-06-04 00:44:33.681266367 -0400
@@ -3,6 +3,7 @@
 Priority: optional
 Maintainer: Sandro Tosi 
 Uploaders: Debian Python Modules Team 

+Build-Depends-Indep: python3-matplotlib
 Build-Depends: cython (>= 0.26-2.1),
debhelper (>= 11),
dh-python,
@@ -15,7 +16,6 @@
python-all-dev,
python3-all-dev,
python-docutils,
-   python3-matplotlib,
python-pytest,
python3-pytest,
python-setuptools,
--- a/debian/rules  2019-03-02 11:30:12.0 -0500
+++ b/debian/rules  2019-06-04 00:39:11.123434195 -0400
@@ -25,6 +25,7 @@
python$$v-dbg setup.py build; \
done
 
+override_dh_auto_build-indep:
# build doc only for default python version
(export MPLCONFIGDIR=. ; make -C doc html PYTHON=python3 
PYTHONPATH=../$(PY3LIBPATH))
 


Bug#928026: release-notes: document the state of security support for golang packages in Buster

2019-06-04 Thread Justin B Rye
Paul Gevers wrote:
> +  
> +Go based packages
> +
> +  The Debian infrastructure currently doesn't properly enable rebuilding
> +  packages that statically link parts of other packages on a large
> +  scale. Until buster that hasn't been a problem in practice, but with 
> the

(I'm adding a stretch-to-buster tag, since if this is still true for
buster-to-bullseye then it'll at least need a change from "hasn't
been" to "wasn't".)

> +  growth of the Go ecosystems it means that Go based packages won't be

That should probably be "ecosystem", singular.

> +  covered by regular security support until the infrastructure is 
> improved
> +  to cope with these kind of packages in a maintainable manner.

"These kind of" is normal in spoken English, but formal written
English prefers either "this kind of package" or "these kinds of
packages".  Or maybe we just want:

 to deal with them maintainably.

> +
> +
> +  If updates are warranted, they can only come via regular point releases
> +  and thus may be deployed late.

To avoid implying "too late" we might phrase this as:

 If updates are warranted, they can only come via regular point 
releases,
 which may be slow in arriving.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index af7ca5c2..6ead1ec6 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -508,18 +508,19 @@ $ sudo update-initramfs -u
   
 
   
+
 Go based packages
 
   The Debian infrastructure currently doesn't properly enable rebuilding
   packages that statically link parts of other packages on a large
   scale. Until buster that hasn't been a problem in practice, but with the
-  growth of the Go ecosystems it means that Go based packages won't be
+  growth of the Go ecosystem it means that Go based packages won't be
   covered by regular security support until the infrastructure is improved
-  to cope with these kind of packages in a maintainable manner.
+  to deal with them maintainably.
 
 
-  If updates are warranted, they can only come via regular point releases
-  and thus may be deployed late.
+  If updates are warranted, they can only come via regular point releases,
+  which may be slow in arriving.
 
   
 


Bug#928716: mediawiki: File uploads broken (UploadStashBadPathException)

2019-06-04 Thread Kunal Mehta
Hi,

On 5/9/19 10:11 AM, Chris Boot wrote:
> This will apparently be fixed in MediaWiki 1.31.2 when that's released,
> but given that file uploads appear to be non-functional it may be worth
> carrying a patch locally for the Buster release or soon after.

1.31.2 should be coming out later this week so I'll wait a little more
for it and upload once it's out.

And, thank you for testing :)

-- Kunal



signature.asc
Description: OpenPGP digital signature


Bug#929467: RFS: tfortune-1.0.0 [ITP]

2019-06-04 Thread Andre Noll
On Sun, Jun 02, 22:57, Adam Borowski wrote
> On Sat, Jun 01, 2019 at 11:17:53PM +0200, Andre Noll wrote:
> > Adam, do you want me to provide v3 with debian/rules changed to
> > something like the above?
> 
> v2 still suffers from the non-standard perms on usr/ and so on, thus I guess
> it'd be simpler to move to the dh workflow rather than to fix what you
> currently have.
> 
> It's by no means mandatory, but our newly elected Dear Leader is waging a
> campaign to make it strongly recommended, especially for new packages.  I
> quite see why.  And I for one prefer packages where a reviewer doesn't have
> to fire up the brain to comprehend what's being done. :)

This is a compelling argument. v3 is pushed out now and contains
a simple debian/rules file which fully relies on dh. Besides
dh_auto_configure I also had to override dh_autoreconf for reasons
explained in the commit message.

Please review.

Thanks
Andre
-- 
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature


Bug#929969: marked as done (Warning 4: Failed to open /usr/share/qgis/resources/data/world_map.shp: Permission denied.)

2019-06-04 Thread Jürgen E . Fischer
See also https://github.com/qgis/QGIS/issues/25876


-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/


Bug#929974: debian-installer: netinstall on buster set link down for ethernet with r8169 module

2019-06-04 Thread Leonid Balioshenko
Package: debian-installer
Severity: normal

Dear Maintainer,

   * What led up to the situation?
We use netinstall on buster with this kernel image: 
https://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/linux
And after boot installer shows message "Network device not found"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
When I started built-in into installer shell I was able able to bring up link 
with command:
 ip l set eth0 up 
and after that I've exit from shel, press option to detect network and 
installation was completed after that succsessfully
We did another test and put contain of this package 
https://packages.debian.org/buster/all/firmware-realtek/filelist into 
/lib/firmware folder with cookinitrd scripts
After this installer became work as expected.


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

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



Bug#929973: Missing dependency on libhdf5-100

2019-06-04 Thread 積丹尼 Dan Jacobson
Package: qgis
Version: 3.4.8+dfsg-1

With these exact versions appended,

$ qgis --help
/usr/bin/qgis.bin: error while loading shared libraries: 
libhdf5_serial_hl.so.100: cannot open shared object file: No such file or 
directory

One must install
libhdf5-100
to clear the error.

Versions of packages qgis depends on:
ii  libc62.28-10
ii  libexpat12.2.6-1
ii  libgcc1  1:9.1.0-2
ii  libgdal20 [gdal-abi-2-4-0]   2.4.1+dfsg-1~exp1
ii  libgeos-c1v5 3.7.1-1
ii  libgsl23 2.5+dfsg-6
ii  libgslcblas0 2.5+dfsg-6
ii  libpq5   11.3-1
ii  libproj135.2.0-1
ii  libqca-qt5-2 2.1.3-2
ii  libqgis-3d3.4.8  3.4.8+dfsg-1
ii  libqgis-analysis3.4.83.4.8+dfsg-1
ii  libqgis-app3.4.8 3.4.8+dfsg-1
ii  libqgis-core3.4.83.4.8+dfsg-1
ii  libqgis-gui3.4.8 3.4.8+dfsg-1
ii  libqgis-native3.4.8  3.4.8+dfsg-1
ii  libqscintilla2-qt5-132.10.4+dfsg-2
ii  libqt53dcore55.11.3+dfsg-2
ii  libqt53dextras5  5.11.3+dfsg-2
ii  libqt53dinput5   5.11.3+dfsg-2
ii  libqt53dlogic5   5.11.3+dfsg-2
ii  libqt53drender5  5.11.3+dfsg-2
ii  libqt5concurrent55.11.3+dfsg1-1
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5keychain1  0.9.1-2
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5positioning5   5.11.3+dfsg-2
ii  libqt5printsupport5  5.11.3+dfsg1-1
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5quickwidgets5  5.11.3-4
ii  libqt5serialport55.11.3-2
ii  libqt5sql5   5.11.3+dfsg1-1
ii  libqt5svg5   5.11.3-2
ii  libqt5webkit55.212.0~alpha2-21
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libqt5xml5   5.11.3+dfsg1-1
ii  libqwt-qt5-6 6.1.4-1
ii  libspatialindex5 1.9.0-1
ii  libspatialite7   5.0.0~beta0-1~exp2
ii  libsqlite3-0 3.27.2-2
ii  libstdc++6   9.1.0-2
ii  libzip4  1.5.1-4
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2
ii  python3-qgis 3.4.8+dfsg-1
ii  qgis-common  3.4.8+dfsg-1
ii  qgis-providers   3.4.8+dfsg-1

Versions of packages qgis recommends:
pn  qgis-plugin-grass  

Versions of packages qgis suggests:
pn  gpsbabel  

-- no debconf information



Bug#929972: Add HHMMSS to temporary filenames

2019-06-04 Thread 積丹尼 Dan Jacobson
Package: reportbug
Version: 7.5.2
Severity: wishlist

Which is newer?
/tmp/reportbug-qgis-backup-20190604-12819-kidsf7go
/tmp/reportbug-qgis-backup-20190604-5996-5qs5kihp

Well we could tell if instead of using what perhaps is the PID,
you used also HHMMSS .



Bug#881692: command-not-found: I re-wrote command-not-found

2019-06-04 Thread Shawn Landden
Package: command-not-found
Version: 18
Followup-For: Bug #881692

Dear Maintainer,

Dear Maintainer,

A snap hook was just merged https://github.com/snapcore/snapd/pull/6734

My package now supports the Commands hook that Ubuntu servers export
(as well as apt-file). As Debian does not yet ship this file,
apt-file should be recommended and not suggested on Debian, but I am hesitant to
have differn't packaging as this is a native package.


-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

Kernel: Linux 4.15.11-mainline-rev1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages command-not-found depends on:
ii  adduser  3.118
ii  apt  1.8.2
ii  libc62.28-10

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
ii  apt-file  3.2.2

-- no debconf information



Bug#929957: autodep8: allow customization of python module name

2019-06-04 Thread Alexandre Rossi
Thanks for you response.

> This has nothing to do with Django packages. It will fail for any
> package where the main module does not match the (upstream) package
> name.
> 
> This import test is also the very minimal testing that can be done in a
> python package. If you care enough about testing to not just delete the
> `Testsuite: autopkgtest-pkg-python` field in debian/control, you might
> as well enable real tests on the package instead.

I'm sorry but I do not understand, debian/control does not have a Testsuite
field.

Anyway I managed to workaround the autopkgtest failure in sbuild by adding
a fixed debian/tests/source file to my source package. I had not tried that
because the manual page of autodep8 says it prepends that file with its
own output and I thought the failure due to the module naming would not go
away. However, it seems my fixed tests replaced the generated ones. Maybe
the manual page can be improved in this regard.

Thanks,

Alex



Bug#929970: speaker test: mention how to produce an continuous sound on a particular speaker

2019-06-04 Thread 積丹尼 Dan Jacobson
Package: alsa-utils
Version: 1.1.8-2
Severity: wishlist
File: /usr/share/man/man1/speaker-test.1.gz

Document how to make continuous sound on the front left speaker (while I check 
the
cords to find out where the break is.)

Best I could do:
while :; do speaker-test -c 2 -s 2; done
(To end: do ^Z then kill %)

Because: -p, -P documentation not clear and don't seem to affect much.
And -l says it can't be used with -s.



Bug#929971: speaker test: be sure to mention to use -c when using -s.

2019-06-04 Thread 積丹尼 Dan Jacobson
Package: alsa-utils
Version: 1.1.8-2
Severity: wishlist
File: /usr/share/man/man1/speaker-test.1.gz

At

   -s | --speaker CHANNEL
  Do a single-shot speaker test for the given channel.  The channel 
number starts from 1.  The channel number corresponds to left, right, 
rear-left, rear-right, center, LFE, side-
  left, side-right, and so on.

  For example, when 1 is passed, it tests the left channel only 
once rather than both channels with looping.

be sure to mention to also use -c , otherwise all -s values 
over 1 will be invalid!

P.S.,
$ speaker-test -c -s
should be caught as an error.



Bug#929969: Warning 4: Failed to open /usr/share/qgis/resources/data/world_map.shp: Permission denied.

2019-06-04 Thread 積丹尼 Dan Jacobson
Package: qgis
Version: 3.4.8+dfsg-1
Severity: minor

Start Qgis for the first time and hit CTRL+SHIFT+P.
We see the message
Warning 4: Failed to open /usr/share/qgis/resources/data/world_map.shp: 
Permission denied.
in the calling shell.
However
$ ls -l /usr/share/qgis/resources/data/world_map.shp
-rw-r--r-- 1 root root 528032 05-17 19:00 
/usr/share/qgis/resources/data/world_map.shp
Maybe it was trying to open it read-write.

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

Versions of packages qgis depends on:
ii  libc62.28-10
ii  libexpat12.2.6-1
ii  libgcc1  1:9.1.0-2
ii  libgdal20 [gdal-abi-2-4-0]   2.4.0+dfsg-1+b1
ii  libgeos-c1v5 3.7.1-1
ii  libgsl23 2.5+dfsg-6
ii  libgslcblas0 2.5+dfsg-6
ii  libpq5   11.3-1
ii  libproj135.2.0-1
ii  libqca-qt5-2 2.1.3-2
ii  libqgis-3d3.4.8  3.4.8+dfsg-1
ii  libqgis-analysis3.4.83.4.8+dfsg-1
ii  libqgis-app3.4.8 3.4.8+dfsg-1
ii  libqgis-core3.4.83.4.8+dfsg-1
ii  libqgis-gui3.4.8 3.4.8+dfsg-1
ii  libqgis-native3.4.8  3.4.8+dfsg-1
ii  libqscintilla2-qt5-132.10.4+dfsg-2
ii  libqt53dcore55.11.3+dfsg-2
ii  libqt53dextras5  5.11.3+dfsg-2
ii  libqt53dinput5   5.11.3+dfsg-2
ii  libqt53dlogic5   5.11.3+dfsg-2
ii  libqt53drender5  5.11.3+dfsg-2
ii  libqt5concurrent55.11.3+dfsg1-1
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5keychain1  0.9.1-2
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5positioning5   5.11.3+dfsg-2
ii  libqt5printsupport5  5.11.3+dfsg1-1
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5quickwidgets5  5.11.3-4
ii  libqt5serialport55.11.3-2
ii  libqt5sql5   5.11.3+dfsg1-1
ii  libqt5svg5   5.11.3-2
ii  libqt5webkit55.212.0~alpha2-21
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libqt5xml5   5.11.3+dfsg1-1
ii  libqwt-qt5-6 6.1.4-1
ii  libspatialindex5 1.9.0-1
ii  libspatialite7   4.3.0a-5+b2
ii  libsqlite3-0 3.27.2-2
ii  libstdc++6   9.1.0-2
ii  libzip4  1.5.1-4
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2
ii  python3-qgis 3.4.8+dfsg-1
ii  qgis-common  3.4.8+dfsg-1
ii  qgis-providers   3.4.8+dfsg-1

Versions of packages qgis recommends:
pn  qgis-plugin-grass  

Versions of packages qgis suggests:
pn  gpsbabel  

-- no debconf information



Bug#929968: linux: Missing C_CAN module

2019-06-04 Thread Bastian Germann
Source: linux
Severity: normal

Dear Maintainer,

All Debian kernel configurations are missing the C_CAN drivers. This
device is available on TI am335x chips, which run, e.g., BeagleBone
Black. It would be great to have at least the armmp flavour set the
following configuration options:

CONFIG_CAN_C_CAN=m
CONFIG_CAN_C_CAN_PLATFORM=m



Bug#929957: autodep8: allow customization of python module name

2019-06-04 Thread Antonio Terceiro
Hi,

On Tue, Jun 04, 2019 at 11:46:52AM +0200, Alexandre Rossi wrote:
> Package: autodep8
> Version: 0.18
> Severity: normal
> 
> Dear Maintainer,
> 
> For django packages, autodep8 fails to determine the proper python module
> name:
> 
> $ autodep8
> Test-Command: set -e ; for py in $(pyversions -r 2>/dev/null) ; do cd 
> "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import 
> django_constance; print django_constance" ; done
> Depends: python-all, python-django-constance
> Restrictions: allow-stderr, superficial
> Features: test-name=autodep8-python2
> 
> Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd 
> "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import 
> django_constance; print(django_constance)" ; done
> Depends: python3-all, python3-django-constance
> Restrictions: allow-stderr, superficial
> Features: test-name=autodep8-python3
> 
> The proper tests:
> 
> $ python -c 'import constance'
> $ python3 -c 'import constance'
> 
> Maybe autodep8 should allow the package maintainer to customize the python
> module name. Something has been proposed to fix this:
> https://salsa.debian.org/ci-team/autodep8/merge_requests/6
> 
> Or maybe support/python/generate should handle the special django module case.

This has nothing to do with Django packages. It will fail for any
package where the main module does not match the (upstream) package
name.

This import test is also the very minimal testing that can be done in a
python package. If you care enough about testing to not just delete the
`Testsuite: autopkgtest-pkg-python` field in debian/control, you might
as well enable real tests on the package instead.


signature.asc
Description: PGP signature


Bug#929964: debian-edu-config: sudo fails on LTSP clients

2019-06-04 Thread Dominik George
>Perhaps it is time to switch all clients to sssd?

Oh yes, please... Happy to put that on my list of all the tests to do in 
Hamburg ;).

-nik



Bug#929965: unblock: buildbot/2.0.1-2

2019-06-04 Thread Jonathan Wiltshire
On Tue, Jun 04, 2019 at 02:30:19PM +0200, Robin Jarry wrote:
> Please unblock package buildbot.
> 
> Version 2.0.1-2 resolves a grave security bug in buildbot (#929849).

Unblocked; thanks.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



Bug#929964: debian-edu-config: sudo fails on LTSP clients

2019-06-04 Thread Petter Reinholdtsen
[Wolfgang Schweer]
> During a recent test I noticed that sudo is unusable on LTSP clients.
> The LDAP server connection can't be established.
>
> While the related configuration (/etc/sudo-ldap.conf) is ok on the 
> server, the LDAP URI needs to be set explicitly for clients.

Why do the LTSP clients need this, if the non-LTSP clients do not?

Perhaps it is time to switch all clients to sssd?

-- 
Vennlig hilsen
Petter Reinholdtsen



Bug#929967: CMake: use TBBConfig instead of FindTBB

2019-06-04 Thread Alexey Veprev
Package: libtbb-dev
Version: 2018~U6-4
X-Debbugs-CC: ti...@debian.org

TBB provides a TBBInstallConfig CMake module to generate TBBConfig files
for packages:
see description here
https://github.com/intel/tbb/blob/tbb_2019/cmake/README.rst#tbbinstallconfig

TBBConfig files are automatically invoked by CMake when you use
"find_package(TBB <...>)" (just like FindTBB.cmake module).

Some advantages of TBBConfig in comparison with FindTBB.cmake:
1. TBBConfig provides imported targets which can be used in modern CMake
style (while current FindTBB.cmake provides variables).
2. TBBConfig works for the exact package, it won't look for TBB stuff in
other places except the specific one.
3. Generator of TBBConfig files is maintained on TBB side that allows to
align usage model across different distributions.

TBBInstallConfig is already used
- in Homebrew tbb formula:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/tbb.rb#L35..L38
- in TBB packaging script (which is used in conda-forge, for example):
https://github.com/intel/tbb/blob/tbb_2019/build/build.py#L157..L167


Bug#929966: g++-8: ICE (SIGILL in collect2) building musescore-snapshot on riscv64

2019-06-04 Thread Thorsten Glaser
Package: g++-8
Version: 8.3.0-7

https://buildd.debian.org/status/fetch.php?pkg=musescore-snapshot&arch=riscv64&ver=3.1%2Bdfsg1-1&stamp=1559616036&raw=0

Excerpt:

[…]
make[4]: Entering directory '/<>/obj-riscv64-linux-gnu'
[ 86%] Building CXX object 
mtest/zerberus/inputControls/CMakeFiles/tst_sfzinputcontrols.dir/tst_sfzinputcontrols.cpp.o
cd /<>/obj-riscv64-linux-gnu/mtest/zerberus/inputControls && 
/usr/bin/c++  -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_HELP_LIB 
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB 
-DQT_QML_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SQL_LIB -DQT_SVG_LIB 
-DQT_TESTCASE_BUILDDIR=\"/<>/obj-riscv64-linux-gnu\" 
-DQT_TESTLIB_LIB -DQT_WIDGETS_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB 
-I/<>/obj-riscv64-linux-gnu/mtest/zerberus/inputControls 
-I/<>/mtest/zerberus/inputControls 
-I/<>/obj-riscv64-linux-gnu/mtest/zerberus/inputControls/tst_sfzinputcontrols_autogen/include
 -I/<>/obj-riscv64-linux-gnu -I/<> 
-I/usr/include/freetype2 -isystem /usr/include/riscv64-linux-gnu/qt5 -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/riscv64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtGui -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtTest -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtQml -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtQuick -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtQuickWidgets -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtXml -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtXmlPatterns -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtSvg -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtSql -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtPrintSupport -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtConcurrent -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtOpenGL -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtHelp  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wdate-time -D_FORTIFY_SOURCE=2  -DQT_NO_DEBUG 
-DNDEBUG -DMSCORE_NO_UPDATE_CHECKER -std=gnu++11 -fPIC-include all.h -D 
QT_GUI_LIB -D TESTROOT=\"/<>\" -g -Wall -Wextra -fPIC -std=gnu++11 
-o CMakeFiles/tst_sfzinputcontrols.dir/tst_sfzinputcontrols.cpp.o -c 
/<>/mtest/zerberus/inputControls/tst_sfzinputcontrols.cpp
c++: internal compiler error: Illegal instruction signal terminated program 
collect2
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** 
[mtest/zerberus/global/CMakeFiles/tst_sfzglobal.dir/build.make:126: 
mtest/zerberus/global/tst_sfzglobal] Error 4
[…]



Bug#929965: unblock: buildbot/2.0.1-2

2019-06-04 Thread Robin Jarry
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Tags: security
Control: affects -1 src:buildbot

Please unblock package buildbot.

Version 2.0.1-2 resolves a grave security bug in buildbot (#929849).

A source debdiff against 2.0.1-1 follows.

Thank you!

Robin

diff -Nru buildbot-2.0.1/debian/changelog buildbot-2.0.1/debian/changelog
--- buildbot-2.0.1/debian/changelog 2019-02-11 21:26:20.0 +0100
+++ buildbot-2.0.1/debian/changelog 2019-06-03 14:47:25.0 +0200
@@ -1,3 +1,9 @@
+buildbot (2.0.1-2) unstable; urgency=high
+
+  * Fix OAuth module security bypass [CVE-2019-12300] (Closes: #929849)
+
+ -- Robin Jarry   Mon, 03 Jun 2019 14:47:25 +0200
+
 buildbot (2.0.1-1) unstable; urgency=medium
 
   * Use scdoc for man pages
diff -Nru 
buildbot-2.0.1/debian/patches/0005-Revert-master-Accept-GitHub-access_token-directly-fr.patch
 
buildbot-2.0.1/debian/patches/0005-Revert-master-Accept-GitHub-access_token-directly-fr.patch
--- 
buildbot-2.0.1/debian/patches/0005-Revert-master-Accept-GitHub-access_token-directly-fr.patch
   1970-01-01 01:00:00.0 +0100
+++ 
buildbot-2.0.1/debian/patches/0005-Revert-master-Accept-GitHub-access_token-directly-fr.patch
   2019-06-03 14:47:25.0 +0200
@@ -0,0 +1,153 @@
+From: Robin Jarry 
+Date: Mon, 3 Jun 2019 14:43:12 +0200
+Subject: Revert "master: Accept GitHub `access_token` directly from user"
+
+This is a backport of upstream commit e1dcfce4388bfb: ("Revert "master:
+Accept GitHub `access_token` directly from user"").
+
+Fixes: CVE-2019-12300
+Signed-off-by: Pierre Tardy 
+Signed-off-by: Robin Jarry 
+---
+ master/buildbot/test/unit/test_www_oauth.py | 37 +-
+ master/buildbot/www/oauth2.py   | 41 +++--
+ 2 files changed, 21 insertions(+), 57 deletions(-)
+
+diff --git a/master/buildbot/test/unit/test_www_oauth.py 
b/master/buildbot/test/unit/test_www_oauth.py
+index 551f221..fd3b0de 100644
+--- a/master/buildbot/test/unit/test_www_oauth.py
 b/master/buildbot/test/unit/test_www_oauth.py
+@@ -191,30 +191,7 @@ class OAuth2Auth(www.WwwTestMixin, ConfigErrorsMixin, 
unittest.TestCase):
+   'full_name': 'foo bar'}, res)
+ 
+ @defer.inlineCallbacks
+-def test_GithubAcceptToken(self):
+-requests.get.side_effect = []
+-requests.post.side_effect = [
+-FakeResponse(dict(access_token="TOK3N"))]
+-self.githubAuth.get = mock.Mock(side_effect=[
+-dict(  # /user
+-login="bar",
+-name="foo bar",
+-email="buzz@bar"),
+-[  # /user/emails
+-{'email': 'buzz@bar', 'verified': True, 'primary': False},
+-{'email': 'bar@foo', 'verified': True, 'primary': True}],
+-[  # /user/orgs
+-dict(login="hello"),
+-dict(login="grp"),
+-]])
+-res = yield self.githubAuth.acceptToken("TOK3N")
+-self.assertEqual({'email': 'bar@foo',
+-  'username': 'bar',
+-  'groups': ["hello", "grp"],
+-  'full_name': 'foo bar'}, res)
+-
+-@defer.inlineCallbacks
+-def test_GithubAcceptToken_v4(self):
++def test_GithubVerifyCode_v4(self):
+ requests.get.side_effect = []
+ requests.post.side_effect = [
+ FakeResponse(dict(access_token="TOK3N"))]
+@@ -243,14 +220,14 @@ class OAuth2Auth(www.WwwTestMixin, ConfigErrorsMixin, 
unittest.TestCase):
+ }
+ }
+ ])
+-res = yield self.githubAuth_v4.acceptToken("TOK3N")
++res = yield self.githubAuth_v4.verifyCode("code!")
+ self.assertEqual({'email': 'bar@foo',
+   'username': 'bar',
+   'groups': ["hello", "grp"],
+   'full_name': 'foo bar'}, res)
+ 
+ @defer.inlineCallbacks
+-def test_GithubAcceptToken_v4_teams(self):
++def test_GithubVerifyCode_v4_teams(self):
+ requests.get.side_effect = []
+ requests.post.side_effect = [
+ FakeResponse(dict(access_token="TOK3N"))]
+@@ -331,7 +308,7 @@ class OAuth2Auth(www.WwwTestMixin, ConfigErrorsMixin, 
unittest.TestCase):
+ }
+ }
+ ])
+-res = yield self.githubAuth_v4_teams.acceptToken("TOK3N")
++res = yield self.githubAuth_v4_teams.verifyCode("code!")
+ self.assertEqual({'email': 'bar@foo',
+   'username': 'bar',
+   'groups': [
+@@ -434,11 +411,9 @@ class OAuth2Auth(www.WwwTestMixin, ConfigErrorsMixin, 
unittest.TestCase):
+ rsrc.auth.verifyCode.assert_called_once_with(b"code!")
+ self.assertEqual(self.master.session.user_info, {'username': 'bar'})
+ self.assertEqual(res, {'redirected': b'://me'})
++# token not supported anymore
+ 

  1   2   >