Bug#925909: [Help] Re: pbgenomicconsensus: autopkgtest regression

2019-04-06 Thread Andreas Tille
Control: reopen -1

Hi,

it seems my third attempt to fix the autopkgtest failed again. :-(

The nasty thing is that since the last two uploads the test worked in
the pbuilder environment which I'm usually use to build.  Before I
uploaded yesterday the debci log provided some information (missing
dependency from python-h5py) but when I look at

  
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pbgenomicconsensus/2208809/log.gz

now it just has:

autopkgtest [15:40:15]: test command2:  cp -r Makefile tests $AUTOPKGTEST_TMP 
&& cd $AUTOPKGTEST_TMP && make extra-tests
autopkgtest [15:40:15]: test command2: [---
# Tests that need to be run by Jenkins but are slowing
# down the development cycle, so aren't run by "tests"
# target.
PATH=`pwd`:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games cram 
--verbose --xunit-file=gc-extra-cram.xml `ls tests/cram/extra/*.t | grep -v 
arrow`
tests/cram/extra/plurality-fluidigm.t: passed
# Ran 1 tests, 0 skipped, 0 failed.
autopkgtest [15:40:22]: test command2: ---]
autopkgtest [15:40:22]: test command2:  - - - - - - - - - - results - - - - - - 
- - - -
command2 PASS
autopkgtest [15:40:22]:  summary
command1 FAIL non-zero exit status 2
command2 PASS


I have no idea why command1 is failing.  Anybody who can reproduce
this test result and can fix this test?

Kind regards

 Andreas.

-- 
http://fam-tille.de



Bug#924635: Update

2019-04-06 Thread Dominik Stadler
Bug #925533 re-adds the messaging and jms modules in libspring, so this bug
could be merged as duplicate with that one now.


Bug#924634: Update

2019-04-06 Thread Dominik Stadler
Bug #925533 re-adds the messaging and jms modules in libspring, so this bug
could be merged as duplicate with that one now.


Bug#926569: pycsw: please drop the transitional package python-pycsw-doc

2019-04-06 Thread Sebastiaan Couwenberg
Control: tags -1 pending

Fixed in git.

Kind Regards,

Bas

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



Bug#926571: RM: gcc-6-doc -- RoQA; gcc-6 was removed from sid

2019-04-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Without gcc-6, this documentation is no longer needed.


Andreas



Bug#926570: ITP: ruby-sigdump -- Use signal to show stacktrace of a Ruby process without restarting it

2019-04-06 Thread Hideki Yamane
Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: ruby-sigdump
  Version : 0.2.4
  Upstream Author : Sadayuki Furuhashi 
* URL : https://github.com/frsyuki/sigdump
* License : MIT
  Programming Lang: Ruby
  Description : Use signal to show stacktrace of a Ruby process without 
restarting it

 fluentd depends on it.



Bug#926568: gsl-doc: does this package need to be updated to match gsl 2.5?

2019-04-06 Thread Dirk Eddelbuettel


severity 926568 wishlist
thanks

On 7 April 2019 at 06:23, Andreas Beckmann wrote:
| Source: gsl-doc
| Version: 2.3-1
| Severity: serious
| 
| Hi,
| 
| src:gsl is at version 2.5 while src:gsl-doc is at version 2.3.
| Does the documentation need to be updated to match the library?
| 
| Please downgrade the severity to wishlist if the 2.3 documentation
| does not lack anything relevant for 2.5.

I believe this to be the case.

Doc update is manual because of the DFSG concerns.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#926569: pycsw: please drop the transitional package python-pycsw-doc

2019-04-06 Thread Andreas Beckmann
Source: pycsw
Version: 2.2.0+dfsg-6
Severity: important

python-pycsw-doc was already a transitional package in stretch, it is no
longer needed.


Andreas



Bug#924365: www.debian.org: FTBFS in buster: turkish vs. tr_TR locale

2019-04-06 Thread Omer Ozarslan
Hello Laura,

I'm not sure if I missed some steps, but I couldn't reproduce this issue.
Yet, I hit another one:

[snipped]

root@a179023d59e0:/webwml# make -j1 -C turkish STRICT_ERROR_CHECKS=1
USE_SAMPLE_FILES=1
make: Entering directory '/webwml/turkish'
make -C po install
make[1]: Entering directory '/webwml/turkish/po'
make[1]: Leaving directory '/webwml/turkish/po'
make -C CD
make[1]: Entering directory '/webwml/turkish/CD'
make -C http-ftp
make[2]: Entering directory '/webwml/turkish/CD/http-ftp'
make[2]: *** No rule to make target
'../../../english/CD/http-ftp/cdimage_mirrors.list', needed by
'index.tr.html'.  Stop.
make[2]: Leaving directory '/webwml/turkish/CD/http-ftp'
make[1]: *** [../../Makefile.common:79: http-ftp] Error 2
make[1]: Leaving directory '/webwml/turkish/CD'
make: *** [../Makefile.common:79: CD] Error 2
make: Leaving directory '/webwml/turkish'

Here is the verbose part I snipped for convenience:

root@a179023d59e0:/# cd webwml
root@a179023d59e0:/webwml# cat /var/log/apt/history.log | grep Commandline
Commandline: apt-get install -y build-essential vim gettext make perl wml
git wget libxml-rss-perl
root@a179023d59e0:/webwml# git reset --hard
HEAD is now at c28ce7bbd78 (fr) DSA 4223-4225, initial translation
root@a179023d59e0:/webwml# make -j1 -C turkish STRICT_ERROR_CHECKS=1
USE_SAMPLE_FILES=1
make: Entering directory '/webwml/turkish'
make -C po install
make[1]: Entering directory '/webwml/turkish/po'
msgmerge -q templates.tr.po ../../english/po/templates.pot | \
msgfmt --statistics -o templates.mo -
91 translated messages, 16 fuzzy translations, 12 untranslated messages.
'templates.mo' -> '../../locale/tr/LC_MESSAGES/templates.mo'
msgmerge -q bugs.tr.po ../../english/po/bugs.pot | \
msgfmt --statistics -o bugs.mo -
34 translated messages.
'bugs.mo' -> '../../locale/tr/LC_MESSAGES/bugs.mo'
msgmerge -q blends.tr.po ../../english/po/blends.pot | \
msgfmt --statistics -o blends.mo -
0 translated messages, 18 untranslated messages.
'blends.mo' -> '../../locale/tr/LC_MESSAGES/blends.mo'
msgmerge -q cdimage.tr.po ../../english/po/cdimage.pot | \
msgfmt --statistics -o cdimage.mo -
26 translated messages.
'cdimage.mo' -> '../../locale/tr/LC_MESSAGES/cdimage.mo'
msgmerge -q consultants.tr.po ../../english/po/consultants.pot | \
msgfmt --statistics -o consultants.mo -
15 translated messages.
'consultants.mo' -> '../../locale/tr/LC_MESSAGES/consultants.mo'
msgmerge -q countries.tr.po ../../english/po/countries.pot | \
msgfmt --statistics -o countries.mo -
104 translated messages.
'countries.mo' -> '../../locale/tr/LC_MESSAGES/countries.mo'
msgmerge -q date.tr.po ../../english/po/date.pot | \
msgfmt --statistics -o date.mo -
38 translated messages.
'date.mo' -> '../../locale/tr/LC_MESSAGES/date.mo'
msgmerge -q distrib.tr.po ../../english/po/distrib.pot | \
msgfmt --statistics -o distrib.mo -
46 translated messages.
'distrib.mo' -> '../../locale/tr/LC_MESSAGES/distrib.mo'
msgmerge -q doc.tr.po ../../english/po/doc.pot | \
msgfmt --statistics -o doc.mo -
16 translated messages, 2 fuzzy translations, 14 untranslated messages.
'doc.mo' -> '../../locale/tr/LC_MESSAGES/doc.mo'
msgmerge -q l10n.tr.po ../../english/po/l10n.pot | \
msgfmt --statistics -o l10n.mo -
21 translated messages.
'l10n.mo' -> '../../locale/tr/LC_MESSAGES/l10n.mo'
msgmerge -q langs.tr.po ../../english/po/langs.pot | \
msgfmt --statistics -o langs.mo -
86 translated messages.
'langs.mo' -> '../../locale/tr/LC_MESSAGES/langs.mo'
msgmerge -q legal.tr.po ../../english/po/legal.pot | \
msgfmt --statistics -o legal.mo -
25 translated messages.
'legal.mo' -> '../../locale/tr/LC_MESSAGES/legal.mo'
msgmerge -q mailinglists.tr.po ../../english/po/mailinglists.pot | \
msgfmt --statistics -o mailinglists.mo -
20 translated messages.
'mailinglists.mo' -> '../../locale/tr/LC_MESSAGES/mailinglists.mo'
msgmerge -q newsevents.tr.po ../../english/po/newsevents.pot | \
msgfmt --statistics -o newsevents.mo -
24 translated messages, 7 fuzzy translations, 37 untranslated messages.
'newsevents.mo' -> '../../locale/tr/LC_MESSAGES/newsevents.mo'
msgmerge -q organization.tr.po ../../english/po/organization.pot | \
msgfmt --statistics -o organization.mo -
49 translated messages, 17 fuzzy translations, 22 untranslated messages.
'organization.mo' -> '../../locale/tr/LC_MESSAGES/organization.mo'
msgmerge -q partners.tr.po ../../english/po/partners.pot | \
msgfmt --statistics -o partners.mo -
0 translated messages, 62 untranslated messages.
'partners.mo' -> '../../locale/tr/LC_MESSAGES/partners.mo'
msgmerge -q ports.tr.po ../../english/po/ports.pot | \
msgfmt --statistics -o ports.mo -
26 translated messages.
'ports.mo' -> '../../locale/tr/LC_MESSAGES/ports.mo'
msgmerge -q security.tr.po ../../english/po/security.pot | \
msgfmt --statistics -o 

Bug#926568: gsl-doc: does this package need to be updated to match gsl 2.5?

2019-04-06 Thread Andreas Beckmann
Source: gsl-doc
Version: 2.3-1
Severity: serious

Hi,

src:gsl is at version 2.5 while src:gsl-doc is at version 2.3.
Does the documentation need to be updated to match the library?

Please downgrade the severity to wishlist if the 2.3 documentation
does not lack anything relevant for 2.5.


Andreas



Bug#926567: gmp-doc: does this package need to be updated to match gmp 6.1.2?

2019-04-06 Thread Andreas Beckmann
Package: gmp-doc
Version: 6.0.0-1
Severity: serious
Tags: stretch buster sid

Hi,

src:gmp is at version 6.1.2 while src:gmp-doc is at version 6.0.0.
Does the documentation need to be updated to match the library?

Please downgrade the severity to wishlist if the 6.0.0 documentation
does not lack anything relevant for 6.1.2.


Andreas



Bug#926566: RM: 3dldf-doc/2.0.3+ndfsg-3

2019-04-06 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

3dldf is not in testing.


Andreas



Bug#926565: cantor-backend-scilab: scilab is no longer available on armel, mips, mipsel

2019-04-06 Thread Andreas Beckmann
Package: cantor-backend-scilab
Version: 4:18.12.0-1
Severity: serious

Hi,

scilab is no longer built for armel, mips, mipsel (in addition to
mips64el), due to uninstallability of libjogl2-java.
Please drop these architectures from the cantor-backend-scilab
binary package.


Andreas



Bug#925891: AMD/ATI Carrizo driver incorrectly detected

2019-04-06 Thread 積丹尼 Dan Jacobson
unmerge 925891
retitle 925891 AMD/ATI Carrizo driver incorrectly detected?
thanks

Now making the incorrect driver detection a separate issue.

All I know is with that minimal install, it somehow assumes the correct
driver is present, or it is, but it uses it wrong. See also
https://wiki.debian.org/AtiHowTo . Anyway the result is a successful
install, but a black screen upon boot.

I'm delaying completing my installation so I can help somebody fix this.
I can work around it myself.
Just tell me when you don't need my help anymore for testing the
installer on this, so I can proceed with my installation. Thanks.



Bug#926149: AMD: Add nomodeset kernel parameter to avoid black screen

2019-04-06 Thread 積丹尼 Dan Jacobson
clone 926149 -1
retitle -1 [AMD/ATI] Carrizo driver incorrectly detected
retitle 926149 Add nomodeset kernel parameter for recovery boot grub entry
thanks

> "BH" == Ben Hutchings  writes:

BH> However it might be reasonable to add "nomodeset" to the command line
BH> in GRUB's "recovery" boot menu items.



Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10

2019-04-06 Thread Karl O. Pinc
Hi Justin,

Very briefly: the issues.dbk file contains
lots-o-stuff that seemed like it might be
relevant to include in the final text.  A lot
of it is a hodge-podge and not ready to be reviewed.

Of course you're welcome to come up with something
yourself. :-)

On Sun, 7 Apr 2019 02:43:21 +0100
Justin B Rye  wrote:

> > +
> > +printf '0A:30' \
> > +  | perl -e 'while (<>)
> > +   {printf("enp%ss%s\n",
> > +   oct("0x".substr($_,0,2)),
> > +   oct("0x".substr($_,3,2)));};'
> > +  
> 
> This seems an overcomplicated way of converting a number from hex to
> dec, though I may be biassed due to the fact that for my own hardware
> I've never seen a slot or bus number higher than 7.  Couldn't you just
> use a bash function like:
> 
>  $ ethname() { echo "enp$((16#$1))s$((16#$2))"; }
>  $ ethname 0a 30
>  enp10s48

Technically, bash is not a required package.  So it
won't necessarily be on every Debian system.  The
perl-base package is required, so I used perl.
(printf is Posix and in dash, which is also required.)

This may be over-thinking, but I thought it a factor.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein



Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10

2019-04-06 Thread Justin B Rye
Work in progress nitpickings:

Karl O. Pinc wrote:
> diff --git a/en/issues.dbk b/en/issues.dbk
> index 35841ee6..6d831f62 100644
> --- a/en/issues.dbk
> +++ b/en/issues.dbk
> @@ -1,3 +1,4 @@
> +
>  
>  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
> @@ -39,6 +40,196 @@ information mentioned in .
>  
>
>  
> +  
> +Migrating from legacy eth and
> +wlan style network interface names
> +

We should probably start by pointing back at the deprecation stage in
the Stretch release-notes.  Make this "issues" file the primary one
explaining the situation, with just a cross-reference in the
"upgrading" file, and introduce this in terms of "if your system was
upgraded from Jessie without migrating away from the network interface
naming scheme deprecated in the Stretch release, and depends on
/e/u/r/70-persistent-network-blah.txt to maintain these legacy names,
you should be aware that udev on Buster no longer recognises that
file.  To avoid the danger of your machine losing networking after the
upgrade to Buster, it is recommended that you switch to the new naming
scheme in advance, updating any interface names hardcoded in
configuration files."

> +Debian buster requires the new network interface naming
> +scheme.  Legacy network interface names, names beginning with
> +eth or wlan are no longer
> +supported.

That's not quite true; the change isn't that they're unsupported (if
you set up an appropriate .link file or something), it's that the
legacy support for configuring them in /etc/udev/rules.d/ has gone.

> +
> +
> +  This section applies only to systems upgraded to stretch,
> +  Debian 9.  Systems installed as stretch, using the stretch
> +  installer, already use the new naming scheme.
> +

The  element isn't used anywhere else in the release-notes.

I suppose it's also technically not true that the change in udev
behaviour applies only to upgraded systems; it's entirely possible to
set up a freshly installed Stretch box with an /e/u/r/ file.

> +
> +Interface names must be be manually migrated to the new
> +naming scheme before upgrading to Debian 10.  If you rely on the
> +old names in custom ifupdown stanzas, firewall scripts, or other
> +networking configuration, these will also need to be updated to
> +the new names.

(For people with only a single wireless connection, handled by
network-manager, is there in fact any "manual" work that they need to
do?  Or will nm just bring up whatever wireless card it finds?)

> +
> +
> +  This process may render your machine inaccessible through
> +  ssh. Be sure to have physical or console access to the machine,
> +  or a way to revert to your existing configuration.
> +

Again,  isn't currently used in release-notes.

(It seems to me the simplest safety net would be a grub entry using
the kernel net.ifnames=0 option.)

> +
> +First, determine all relevant network interface names: those
> +in /etc/udev/rules.d/70-persistent-net.rules,
> +or if that does not exist (in the case of virtual machines), in
> +ip link or
> +/sys/class/net/.
> +
> +The following command may be helpful
> +
> +
> +# ls /sys/class/net | egrep '^[0-9]+: (eth)|(wlan)[0-9]+'
> +

This looks like a halfway-converted "ip link" recipe - the "ls"
invocation will output some string like "eth0 lo wlan0", and the
"grep" won't match it.  But if you're listing /sys/net for human
consumption there's not much need for filtering anyway - just:

  
   First, determine all relevant network interface names by running:
  
  
   $ echo /sys/class/net/[ew]*
  

I suppose you might want to add here:

  
   In the legacy system, ethernet cards had names like
   eth0; wireless cards had ones like
   wlan0.  The new system uses hardware-based
   names like enp1s0 or wlp2s1,
   where the numbers encode PCI device bus- and slot-numbers.
  

(Apparently USB wifi hardware may use a MAC-based name, so that might
need to be mentioned, though on the plus side I think it's a case that
doesn't require any changes in Buster.)

> +
> +Then for every interface name use a command like
> +
> +
> +# grep -rlF eth0 /etc
> +
> +
> +to find out where it is being used.
> +
> +Then on "real hardware" machines, rename the file to
> +70-persistent-net.rules.old; alternately, if
> +you have multiple interfaces, instead of renaming you may wish to
> +comment out specific lines to convert a single interface at a
> +time.

The stage at which they need to edit that ifupdown stanza or whatever
is also the stage at which they need the information about "how to
predict predictable names", so put that here.

> +
> +On VMs remove the files /etc/systemd/network/99-default.link and
> +/etc/systemd/network/50-virtio-kernel-names.link (the latter only exists on 
> VMs
> +that use virtio network devices).

Should there be extra 

Bug#926564: minetest: New upstream version available

2019-04-06 Thread Linda Lapinlampi
Source: minetest
Severity: wishlist

Dear Maintainer,

Please consider packaging the latest version of this package to Debian.
The 0.4.17 version in Debian is now over a year old.

0.4.17 → 5.0.0 → 5.0.1 (released 2019-03-31).

In case of a Debian freeze, please consider uploading the new version to
experimental.

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

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



Bug#852323: Problem: UUIDs not being used everywhere for disks in stretch

2019-04-06 Thread Ben Hutchings
On Sat, 2019-04-06 at 16:54 +0100, Steve McIntyre wrote:
> Actually...
> 
> On Sat, Apr 06, 2019 at 04:36:59PM +0100, Steve McIntyre wrote:
> > We need to run update-dev *after* the filesystem creation scripts and
> > this fixes things. I've just copiet it to 99update-dev locally while
> > testing and that made all the difference. It could probably also just
> > be moved instead of copied - at this point I'm not sure if anything in
> > the other scripts also depend on the udev updates for their
> > functionality. Fundamentally, it's a fairly harmless thing to run
> > repeatedly so I'm tempted to just run it twice. Thoughts?
> 
> I think we're definitely going to need this, actually - new device
> entries may not show up otherwise.
> 
> I'm also seeing in my testing that I *do* need to force a "udevadm
> trigger" in the second script. Fundametally, it you don't get new
> kernel events when a mkfs happens so udev will never notice.

Closing a block device that is opened for writing should trigger a
change event.  I tested this now with Linux 4.19.28 and it still seems
to happen.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.




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


Bug#926474: [Pkg-samba-maint] Bug#926474: smbclient: Can browse samba shares as root but not as user

2019-04-06 Thread gcab_dzan
a) no, winbind is not installed (and is not installed under Stretch 9.8, where 
the samba connection is working perfectly).
b) for the moment, I just set up a point-to-point ethernet cable connection 
with an old pc running winxp, within the same workgroup, and I just use the 
file \etc\hosts to map the addresses (pinging is ok both ways). 
c) don't get what you mean by command; I use smbtree to check that the shares 
on both pc's are visible, after that (normally) I can browse through a file 
manager, and in fact I can do that through Krusader running with root 
privileges.



> Il 6 aprile 2019 alle 21.58 Mathieu Parent  ha scritto:
> 
> 
> Le sam. 6 avr. 2019 à 16:00,  a écrit :
> >
> > Hi, Mathieu, thanks for your reply.
> >
> > I tried either with the new smb.conf (att. smb.conf.up1)  suggested during 
> > installing samba, and with the version taken from previous releases and 
> > which is working flawlessly in Stretch (att. smb.conf.ucf-old). Does not 
> > change the problem.
> 
> Is Winbind installed? Are you using pam_winbind and nss_winbind? What
> is your complete command?
> 
> Regards
> 
> --
> Mathieu Parent



Bug#926563: usb-modeswitch: no /dev/gsmmodem symlink

2019-04-06 Thread Kevin Ryde
Package: usb-modeswitch
Version: 2.5.2+repack0-2
Severity: normal

In a mostly up-to-date "testing", but a past kernel 4.4, and running
"init", usb-modeswitch no longer creates the /dev/gsmmodem symlink when
a 3G mobile serial modem is plugged in.  Instead it creates an ordinary
empty file there (and possibly /dev/gsmmodem2 sometimes).

With logging enabled, /var/log/usb_modeswitch_ttyUSB_1-5:1.5 contains

Return symlink name "gsmmodem" and exit

which I thought is normal and could suggest usb_modeswitch_dispatcher is
correctly reporting, so blame may lie elsewhere -- but I couldn't tell
where.

The actual mode switch is ok and can point ppp at /dev/ttyUSB4 or
whatever.


-- System Information:
Debian Release: buster/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages usb-modeswitch depends on:
ii  libc62.28-8
ii  libjim0.77   0.77+dfsg0-3
ii  libusb-1.0-0 2:1.0.22-2
ii  usb-modeswitch-data  20170806-2

usb-modeswitch recommends no packages.

Versions of packages usb-modeswitch suggests:
pn  comgt   
pn  wvdial  

-- Configuration Files:
/etc/usb_modeswitch.conf changed:
DisableSwitching=0
DisableMBIMGlobal=0
EnableLogging=1
HuaweiAltModeGlobal=0


-- no debconf information



Bug#926539: rootskel: steal-ctty no longer works on at least sparc64

2019-04-06 Thread Ben Hutchings
On Sat, 2019-04-06 at 21:33 +0200, John Paul Adrian Glaubitz wrote:
> On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> > My suspicion is that the support multiple consoles in parallel [2] 
> > introduced
> > this particular regression. I haven't done any debugging yet though as I'm
> > not sure where to start, I haven't touched the rootskel package before and
> > therefore would be interested in any pointers how to debug this.
> 
> The problem seems to be the fact that the sparc64 kernel uses different names
> for /proc/console and the actual console name:
> 
> root@landau:~# cat /proc/consoles 
> ttyHV0   -W- (EC p  )4:64
> tty0 -WU (E )4:1
> root@landau:~# readlink /sys/dev/char/4:64
> ../../devices/root/f0299a70/f029b788/tty/ttyS0

The inconsistent name seems like a kernel bug...

> root@landau:~#
> 
> And this is what used to make it work [1]:
> 
>   *) # >= 2.6.38
>   console_major_minor="$(get-real-console-linux)"
>   console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
>   console="${console_raw##*/}"
>   ;;

So maybe rootskel should use that again, but applied to each console's
char device number.

(Though directly using the symlinks under /dev/char seems cleaner than
poking in sysfs.)

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.




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


Bug#926559: On man page AUTHOR is blank

2019-04-06 Thread Adrian Mariano
Note that the man page is not the primary manual, but a hacked output
for people that really like a man page.  So we adjusted the hack and I
believe the empty sections are fixed.  See attached.  

On Sun, Apr 07, 2019 at 02:44:24AM +0800, 積丹尼 Dan Jacobson wrote:
> X-Debbugs-Cc: adri...@gnu.org
> Package: units
> Version: 2.18-1
> Severity: minor
> File: /usr/share/man/man1/units.1.gz
> 
> We see AUTHOR and then it is blank, on man page.
.\"Do not edit this file.  It was created from units.texinfo
.\"using texi2man version 1.01w on Tue Apr  2 21:26:50 EDT 2019
.\"This manual is for GNU Units (version 2.18),
.\"which performs units conversions and units calculations.
.\"
.\"Copyright \(co 1996, 1997, 1999, 2000, 2001, 2002, 2004, 2005, 2007,
.\"2011\-2019 Free Software Foundation, Inc.
.\"
.\"Permission is granted to copy, distribute and/or modify this document
.\"under the terms of the GNU Free Documentation License, Version 1.3 or
.\"any later version published by the Free Software Foundation; with no
.\"Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
.\"Texts.
.TH UNITS 1   "19 March 2019"
.\"
.if \n(.g \{\
.  \" ensure that ASCII circumflex U+005E (^) is not remapped
.  tr ^\(ha
.  \" override translation in troffrc
.  ie '\*[.T]'utf8' .tr `\(oq'\(cq
.  \" override mapping of ` to 60h with Tascii; assume
.  \" we don't need a backquote for an example
.  el .if n .tr `'
.\}
.\" ellipsis: space periods with troff but not with nroff
.if n .ds El \&...
.if t .ds El \&.\ .\ .
.if n \{\
.  tr \(bu*
.  \" override translation to MIDDLE DOT
.  if \n(.g .if '\*(.T'utf8' .tr \(bu\(bu
.  if \n(.g .if '\*(.T'cp1252' .tr \(bu\(bu
.  if \n(.g .if '\*(.T'ansi' .tr \(bu\(bu
.\}
.\"
.\" Extensions to man macros
.\"
.\" set handling of single quotes: 0=>straight, >0=>left and right
.nr tQ 0
.\" groff only
.if '\*(.T'utf8' .nr tQ 1
.\" non-standard devices: Windows code page 1252
.if '\*(.T'cp1252' .nr tQ 1
.if '\*(.T'ansi' .nr tQ 1
.\" Constant-width font
.de CW
.hy 0
.\" nroff can't show CW font, so enclose in single quotes
.if n \{\
.  ie \\n(.g \{\
.\" use proper opening and closing single quotes
.ie \\n(tQ>0 \{\
.  ie \\n(.$>2 \&\\$1\(oq\\$2\(cq\\$3
.  el \&\(oq\\$1\(cq\\$2
.\}
.\" ensure neutral single quotes with Tascii
.el \{\
.  ie \\n(.$>2 \&\\$1\(aq\\$2\(aq\\$3
.  el \&\(aq\\$1\(aq\\$2
.\}
.  \}
.  \" legacy nroff doesn't have 'aq', so use ' and hope for the best
.  el \{\
.ie \\n(.$>2 \&\\$1'\\$2'\\$3
.el \&'\\$1'\\$2
.  \}
.\}
.\" troff can change fonts, so no need for quotes
.if t \{\
.  ie \\n(.$>2 \&\\$1\f(CW\\$2\fR\\$3
.  el \&\f(CW\\$1\fR\\$2
.\}
.hy 14
..
.\" Constant-width oblique font
.de CI
.hy 0
.\" nroff can't show CW font, so enclose in single quotes
.if n \{\
.  ie \\n(.g \{\
.\" use proper opening and closing single quotes
.ie \\n(tQ \{\
.  ie \\n(.$>2 \&\\$1\(oq\fI\\$2\fR\(cq\\$3
.  el \&\(oq\fI\\$1\fR\(cq\\$2
.\}
.\" ensure neutral single quotes with Tascii
.el \{\
.  ie \\n(.$>2 \&\\$1\(aq\fI\\$2\fR\(aq\\$3
.  el \&\(aq\fI\\$1\fR\(aq\\$2
.\}
.  \}
.  \" legacy nroff doesn't have 'aq', so use ' and hope for the best
.  el \{
.ie \\n(.$>2 \&\\$1'\fI\\$2\fR'\\$3
.el \&'\fI\\$1\fR'\\$2
.  \}
.\}
.\" troff can change fonts, so no need for quotes
.if t \{\
.  ie \\n(.$>2 \&\\$1\f(CI\\$2\fR\\$3
.  el \&\f(CI\\$1\fR\\$2
.\}
.hy 14
..
.\" Constant-width font with quotes with nroff and troff
.de CQ
.hy 0
.if n \{\
.  ie \\n(.g \{\
.\" use proper opening and closing single quotes
.ie \\n(tQ \{\
.  ie \\n(.$>2 \&\\$1\(oq\\$2\(cq\\$3
.  el \&\(oq\\$1\(cq\\$2
.\}
.\" ensure neutral single quotes with Tascii
.el \{\
.  ie \\n(.$>2 \&\\$1\(aq\\$2\(aq\\$3
.  el \&\(aq\\$1\(aq\\$2
.\}
.  \}
.  \" legacy nroff doesn't have 'aq', so use ' and hope for the best
.  el \{\
.ie \\n(.$>2 \&\\$1'\\$2'\\$3
.el \&'\\$1'\\$2
.  \}
.\}
.if t \{\
.  ie \\n(.g \{\
.ie \\n(.$>2 \&\\$1\(oq\f(CW\\$2\fR\(cq\\$3
.el \&\(oq\f(CW\\$1\fR\(cq\\$2
.  \}
.  \" legacy troff doesn't have 'oq' or 'cq'
.  el \{\
.ie \\n(.$>2 \&\\$1`\f(CW\\$2\fR'\\$3
.el \&`\f(CW\\$1\fR'\\$2
.  \}
.\}
.hy 14
..
.\" equivalent of @set codequoteundirected
.de aQ
.if \\n(.g .tr '\(aq
..
.\" equivalent of @clear codequoteundirected
.de aE
.if \\n(.g \{ .ie \\n(tQ>0 .tr '\(cq
.el .tr '' \}
..
.\" opening and closing double quotes
.\" groff: true opening and closing quotes
.ie \n(.g \{\
.  ds lQ \(lq
.  ds rQ \(rq
.\}
.el \{\
.\" legacy nroff: ASCII neutral double quotes
.  ie n \{\
.ds lQ ""
.ds rQ ""
.  \}
.\" legacy troff: adjacent opening and closing single quotes
.  el \{\
.ds lQ ``
.ds rQ ''
.  \}
.\}
.\" Display start
.de DS
.hy 0
.if t .in +4n
.if n .in +3n
.nf
..
.\" Display end
.de DE
.fi
.in
.hy 14
..
.\" Example start
.de ES
.DS
.if t \{\
.if '\\$1'S' \{\
.nr Ex 1
.ps -1
.\}
.el .nr Ex 0
.nr mE \\n(.f
.ft CW
.\}
..
.\" Example end
.de EE
.if t \{\
.ft 

Bug#926561: RFP: micropython -- Unix/Linux port of MicroPython for board-independent use on the host

2019-04-06 Thread Thorsten Glaser
Package: wnpp
Severity: wishlist

* Package name: micropython
  Version : 1.10
  Upstream Author : Damien George  and others
* URL : https://github.com/micropython/micropython#the-unix-version
* License : MIT
  Programming Lang: C, Assembly, Python
  Description : Unix/Linux port of MicroPython for board-independent use on 
the host

The Unix port of MicroPython allows testing of programs intended
for microcontrollers on the local Debian host machine (except for
hardware-specific parts). It can also be used as another, tiny but
mostly compatible, Python 3 runtime for small scripts (but it
comes with FFI and JNI support). This port uses optimised assembly
code on ARM/Thumb, MIPS, i386 and amd64, and setjmp/longjmp-based
fallback code on all other architectures.


Notes to porters:

• this needs excessie Makefile patching (e.g. to not hardcode the
  path to OpenJDK 7 on AMD64)

• it seems to aggregate submodules for some dependencies (which we
  can do with the multiple-origtgz feature of dpkg), but care MUST
  be taken to use system libraries whereever possible

• licence review of course must take those extra modules into account
  (“MIT” is what the main repo declares); readline support means all
  dependencies likely must be GPLv3-compatible

• enable as many features as we can, but if it’s too hard, start out
  with a reduced set (e.g. no JNI?)

• I fully expect this to work on all architectures, even m68k and x32
  (which is tricky because it’s often autodetected as amd64 but cannot
  use the amd64 JIT code, I just checked asmx64.c to see that)

• if nobody is working on this, I might do it myself, under the
  Teckids Debian Taskforce umbrella, which might mean comaintainers

• this is distinct from firmware-microbit-micropython whose origtgz
  content completely differs (fork of micropython?) but I’ll Cc its
  maintainers anyway

• the same origtgz MIGHT be used to build multiple binary packages;
  perhaps not the microbit one, but definitely the javascript one
  (which uses emscripten) and perhaps {bare,qemu}-arm; the unix port
  also builds a FreeDOS/djgpp binary if desired, but this should be
  considered afterwards, first get the native host unix port done


Bug#926560: Idea: plain English speaking output mode

2019-04-06 Thread Dan Jacobson
X-Debbugs-Cc: adri...@gnu.org
Package: units
Version: 2.18-1
Severity: wishlist

I have an idea.

The units program is great, but it still makes no sense to the man on
the street when talking over the telephone, etc.

Therefore it should also have the ability to output plain English
[Spanish, etc.] sentences like:

"One hectare is equivalent to one hundred million square centimeters."

This would also be great for accessibility for people who need screen
readers, etc.

Not only should units be able to output such sentences, it should also
be able to read them back in and parse them too.

(Anyway, currently I did
$ units ha cm^2
* 1e+08
/ 1e-08

$ units --verbose ha cm^2
ha = 1e+08 cm^2
ha = (1 / 1e-08) cm^2

$ units hundred\ million
Definition: 1e+08

to indeed confirm my above sentence was correct.)



Bug#926559: On man page AUTHOR is blank

2019-04-06 Thread 積丹尼 Dan Jacobson
X-Debbugs-Cc: adri...@gnu.org
Package: units
Version: 2.18-1
Severity: minor
File: /usr/share/man/man1/units.1.gz

We see AUTHOR and then it is blank, on man page.



Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10

2019-04-06 Thread Justin B Rye
Karl O. Pinc wrote:
> I do know that the new names are the default for new
> stretch installs.  But stretch systems upgraded
> from jessie retain old names.  Upgrading them
> to buster without migrating names will break
> networking.  This is what needs to be addressed.

Yes, sorry that I always sound so negative - you're right that this
needs an entry in the release notes, and I'm glad you've made the
effort to get it sorted out!  I'm looking at your patch now but it'll
take me a while to come up with suggestions.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#926558: Cleanup of /doc/ddp

2019-04-06 Thread Laura Arjona Reina
CC'in debian-...@lists.debian.org

I still have no opinion about this bug, I'll try to put time on getting
#92 fixed first

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

so we can see the bigger picture.

Kind regards,

El 6/4/19 a las 23:35, Thomas Lange escribió:
> 
> Package: www.debian.org
> User: debian-...@lists.debian.org
> Usertags: content
> 
> I like to remove very old and outdated content.
> 
> Links -> "Debian Linux Installation & Getting Started article in the Linux 
> Gazette" links to an article from 1997.
> 
> The section "Todo List" has two links which point to the same
> page. The last addition to /doc/todo was in 2005.
> 
> /doc/topics is "DDP current topics". The last change of the content
> was in 2000.
> 
> Any objections about just removing those?
> 
> 
> "Problematic manuals"
> 
> I want to replace the whole section with a link to
> https://salsa.debian.org/ddp-team/attic
> 
> We can then also remove doc/obsolete.wml
> 

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona



Bug#926514: brltty: FTBFS on ia64 because the link check doesn't account for libunwind

2019-04-06 Thread Samuel Thibault
Hello,

John Paul Adrian Glaubitz, le sam. 06 avril 2019 14:04:07 +0200, a ecrit:
> brltty currently FTBFS on ia64 because the link check at the end of 
> debian/rules
> does not account for the fact that binaries on ia64 link against libunwind*:
> 
> # Check that we didn't accidentally link against something outside of
> # d-i world
> grep Depends: debian/brltty-udeb/DEBIAN/control | perl -ne 'map {unless 
> (/-udeb/ or /^ ?preseed-common$/) {print $_; exit 1}} split /,/'
>  libunwind8make: *** [debian/rules:257: brltty-udeb] Error 1
> dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
> returned exit status 2
> 
> Adding a "or /libunwind.*/" should be able to fix the problem though. Will 
> test
> later and attach a tested patch.

Err, but is the libunwind8 package really available in the d-i image?
AIUI we'd need a udeb for it, not just ignore the issue.

Samuel



Bug#852323: Problem: UUIDs not being used everywhere for disks in stretch

2019-04-06 Thread Steve McIntyre
Actually...

On Sat, Apr 06, 2019 at 04:36:59PM +0100, Steve McIntyre wrote:
>
>We need to run update-dev *after* the filesystem creation scripts and
>this fixes things. I've just copiet it to 99update-dev locally while
>testing and that made all the difference. It could probably also just
>be moved instead of copied - at this point I'm not sure if anything in
>the other scripts also depend on the udev updates for their
>functionality. Fundamentally, it's a fairly harmless thing to run
>repeatedly so I'm tempted to just run it twice. Thoughts?

I think we're definitely going to need this, actually - new device
entries may not show up otherwise.

I'm also seeing in my testing that I *do* need to force a "udevadm
trigger" in the second script. Fundametally, it you don't get new
kernel events when a mkfs happens so udev will never notice.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Dance like no one's watching. Encrypt like everyone is.
 - @torproject



Bug#852323: Problem: UUIDs not being used everywhere for disks in stretch

2019-04-06 Thread Steve McIntyre
On Tue, Jan 15, 2019 at 04:29:36PM +, Steve McIntyre wrote:
>I've let this slip off my radar since, and it's not gone away.
>
>I'm seeing this problem really obviously with live installations now,
>as I've just been testing them with Secure Boot.
>
>Hoping to play with this more in the next few days...

OK, I *think* I have worked out the fundamental problem here. I
uploaded an initial fix for #852323 a few weeks back, but it was only
a quick hack (call "udevadm trigger" instead of "udevadm settle")
until I found the time to dig in to the code properly. Now, with a few
hours undisturbed on a long flight, I think I've sussed the root cause
with judicious use of "udevadm monitor", ls and blkid. \o/

It's all down to ordering of events. In /lib/partman/commit.d in d-i,
we have the following ordering at the moment for some of the scripts:

 30parted
 32update-dev <<- triggers the udev update
 45format_swap
 50format_*fs <<- responsible for running mkfs

It's quite simple. 32update-dev is asking for udev updates, and that
will cause the various /dev/disk/by-*/ symlinks to be updated or
refreshed. But that's the wrong point. In particular for
/dev/disk/bu-uuid, the UUID values themselves come from the filesystem
headers. We *then* make the filesystems for each block device, and
anything that changes at this point will never be represented in the
by-uuid symlinks.

We need to run update-dev *after* the filesystem creation scripts and
this fixes things. I've just copiet it to 99update-dev locally while
testing and that made all the difference. It could probably also just
be moved instead of copied - at this point I'm not sure if anything in
the other scripts also depend on the udev updates for their
functionality. Fundamentally, it's a fairly harmless thing to run
repeatedly so I'm tempted to just run it twice. Thoughts?

So, the question is - how did this *ever* work on older versions of
d-i (Jessie and earlier)? I honestly can't see how it could, so I'm
going to hand-wave and say "timing". If the udev update code took
longer to run, *maybe* the first bit of filesystem creation steps
would have already run by the time the by-uuid symlinks were
made. After all, it's only looking at the filesystem headers so it
wouldn't matter if a long, slow mkfs for a big device was still
going. I know that the systemd folks have put a lot of effort into
making udev more streamlined over the last few years and *maybe* this
has just exposed an underlying bug we've had for ages.

[ Hitting send on this mail now on the plane while I have all this
  fresh in my head, even if it's not going to hit network for a few
  hours yet! ]

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden



Bug#926558: Cleanup of /doc/ddp

2019-04-06 Thread Thomas Lange
It would be great if someone can check the link to DDP-BR on
/doc/ddp. For me it seems DDP-BR also is outdated. The wiki lists a
Debian release from 2015.
Looking at "Documentos" it see a lot of links not working. Also
several links under those sections reply with "Server not found":

Documentos feitos em casa
Documentos traduzidos

IMO we can remove this sentense including the link on /doc/ddp:
"Note to Portuguese-speaking users: visit DDP-BR, web pages about localization 
of Debian documentation in Brazilian Portuguese language."
-- 
regards Thomas



Bug#926502: neutron: CVE-2019-10876: Unable to install new flows on compute nodes when having broken security group rules

2019-04-06 Thread Thomas Goirand
On 4/6/19 9:49 AM, Salvatore Bonaccorso wrote:
> Source: neutron
> Version: 2:13.0.2-14
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> Forwarded: https://bugs.launchpad.net/ossa/+bug/1813007
> 
> Hi,
> 
> The following vulnerability was published for neutron.
> 
> CVE-2019-10876[0]:
> | An issue was discovered in OpenStack Neutron 11.x before 11.0.7, 12.x
> | before 12.0.6, and 13.x before 13.0.3. By creating two security groups
> | with separate/overlapping port ranges, an authenticated user may
> | prevent Neutron from being able to configure networks on any compute
> | nodes where those security groups are present, because of an Open
> | vSwitch (OVS) firewall KeyError. All Neutron deployments utilizing
> | neutron-openvswitch-agent are affected.
> 
> 
> 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-10876
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10876
> [1] https://bugs.launchpad.net/ossa/+bug/1813007
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore

Hi Salvatore,

I had a look at the code, and it changed a lot since the version in
Stretch, which doesn't seem to have the issue.

Moreover, if you read closely
https://bugs.launchpad.net/ossa/+bug/1813007, and especially comment
#48, it looks like this issue is only there since OpenStack Pike. The
version of OpenStack that is in Stretch is Newton (so, one year before
that). Therefore, Stretch (and before) isn't affected. Please update the
security tracker.

I have uploaded a fix for Rocky (currently in Sid/Buster), and will ask
for the unblock on Monday.

Cheers,

Thomas Goirand (zigo)



Bug#926102: Removed package(s) from unstable

2019-04-06 Thread Tobias Frost
Control: reopen -1

Hi Scott,

Seems so that there is still the binary package scilab-cli on those
archs (armel, mips, mipsel, mips64el). Can you please remove it as
well? TIA!

-- 
With greetings from the Salzburg BSP,
tobi



Bug#920492: debian-faq: French documentation translation update

2019-04-06 Thread Holger Wansing
Hi,

Jean-Philippe MENGUAL  wrote:
> Hi,
> 
> Here is th up-to-dated tranalsation.

It seems you attached the wrong file. The file attached is exactly what we
have in GIT now, with 29 fuzzy strings and 23 untranslated.
Please send us the correct file :-)


Holger

> Le 15/03/2019 à 23:39, Holger Wansing a écrit :
> > Hi,
> > 
> > Holger Wansing  wrote:
> >>
> >> Jean-Philippe MENGUAL  wrote:
> >>> Please find attached the French translation update, proofread by the
> >>> debian-l10n-french mailing list contributors.
> >>>
> >>> This file should be put as po4a/po/fr.po in your package build tree.
> >>
> >> I have committed the file to GIT.
> >> However the file apparently is not in sync with the English original.
> >>
> >> So there is some more update work needed. But I would recommend to not 
> >> start
> >> with this now, since there seems to be a problem with the process of
> >> updating the po files, which leads to new changings appearing over and over
> >> again. So, to prevent from needless work, I recommend to not work on
> >> translations updates now.
> >> I will keep you informed...
> > 
> > I'm sorry, apparently I made wrong assumptions when it comes to how the
> > tools within the debian-faq package work.
> > So, everything seems fine so far.
> > 
> > That being said:
> > 
> > Jean-Philippe: could you please update the fr.po file from
> > https://salsa.debian.org/ddp-team/debian-faq/tree/master/po4a/po 
> > and sent it to this bug (#920492)?
> > 
> > 
> > Thanks
> > Holger
> > 
> > 


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076



Bug#926558: Cleanup of /doc/ddp

2019-04-06 Thread Thomas Lange


Package: www.debian.org
User: debian-...@lists.debian.org
Usertags: content

I like to remove very old and outdated content.

Links -> "Debian Linux Installation & Getting Started article in the Linux 
Gazette" links to an article from 1997.

The section "Todo List" has two links which point to the same
page. The last addition to /doc/todo was in 2005.

/doc/topics is "DDP current topics". The last change of the content
was in 2000.

Any objections about just removing those?


"Problematic manuals"

I want to replace the whole section with a link to
https://salsa.debian.org/ddp-team/attic

We can then also remove doc/obsolete.wml

-- 
regards Thomas



Bug#926557: ruby-hangouts-chat: diff for NMU version 0.0.5-1.1

2019-04-06 Thread Tobias Frost
Package: ruby-hangouts-chat
Version: 0.0.5-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for ruby-hangouts-chat (versioned as 0.0.5-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ruby-hangouts-chat-0.0.5/debian/changelog ruby-hangouts-chat-0.0.5/debian/changelog
--- ruby-hangouts-chat-0.0.5/debian/changelog	2018-11-04 09:30:15.0 +0100
+++ ruby-hangouts-chat-0.0.5/debian/changelog	2019-04-06 23:26:10.0 +0200
@@ -1,3 +1,10 @@
+ruby-hangouts-chat (0.0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable tests requiring network access. Closing: #926247
+
+ -- Tobias Frost   Sat, 06 Apr 2019 23:26:10 +0200
+
 ruby-hangouts-chat (0.0.5-1) unstable; urgency=medium
 
   * Initial release (Closes: #912769)
diff -Nru ruby-hangouts-chat-0.0.5/debian/patches/disable_network_test.patch ruby-hangouts-chat-0.0.5/debian/patches/disable_network_test.patch
--- ruby-hangouts-chat-0.0.5/debian/patches/disable_network_test.patch	1970-01-01 01:00:00.0 +0100
+++ ruby-hangouts-chat-0.0.5/debian/patches/disable_network_test.patch	2019-04-06 23:16:52.0 +0200
@@ -0,0 +1,105 @@
+--- a/hangouts-chat.gemspec
 b/hangouts-chat.gemspec
+@@ -14,12 +14,12 @@
+   s.date = "2018-03-31"
+   s.description = "Send messages to G Suite Hangouts Chat rooms using incoming webhooks and Net::HTTP::Post".freeze
+   s.email = "vkukovs...@gmail.com".freeze
+-  s.files = ["CHANGELOG.md".freeze, "LICENSE".freeze, "README.md".freeze, "Rakefile".freeze, "lib/hangouts_chat.rb".freeze, "lib/hangouts_chat/exceptions.rb".freeze, "lib/hangouts_chat/http.rb".freeze, "lib/hangouts_chat/version.rb".freeze, "test/hangouts_chat/http_test.rb".freeze, "test/hangouts_chat_test.rb".freeze, "test/test_helper.rb".freeze]
++  s.files = ["CHANGELOG.md".freeze, "LICENSE".freeze, "README.md".freeze, "Rakefile".freeze, "lib/hangouts_chat.rb".freeze, "lib/hangouts_chat/exceptions.rb".freeze, "lib/hangouts_chat/version.rb".freeze, "test/hangouts_chat_test.rb".freeze, "test/test_helper.rb".freeze]
+   s.homepage = "https://github.com/enzinia/hangouts-chat".freeze
+   s.licenses = ["MIT".freeze]
+   s.rubygems_version = "2.7.6".freeze
+   s.summary = "Library for sending messages to Hangouts Chat rooms".freeze
+-  s.test_files = ["test/hangouts_chat/http_test.rb".freeze, "test/hangouts_chat_test.rb".freeze, "test/test_helper.rb".freeze]
++  s.test_files = ["test/test_helper.rb".freeze]
+ 
+   if s.respond_to? :specification_version then
+ s.specification_version = 4
+--- a/test/hangouts_chat_test.rb
 /dev/null
+@@ -1,51 +0,0 @@
+-require 'test_helper'
+-
+-class HangoutsChatTest < Minitest::Test
+-  def setup
+-@webhook_url = 'https://chat.googleapis.com/v1/spaces/space_id/' \
+-   'messages?key=secret_key=secret_token'
+-@sender = HangoutsChat::Sender.new(@webhook_url)
+-  end
+-
+-  def test_initialized_with_valid_variables
+-url = @sender.instance_variable_get(:@url)
+-http = @sender.instance_variable_get(:@http)
+-assert_equal @webhook_url, url
+-assert_equal HangoutsChat::Sender::HTTP, http.class
+-  end
+-
+-  def test_simple_message_request
+-stub_request(:any, /chat\.googleapis\.com/).to_return(status: 200)
+-message = 'Test simple message'
+-
+-@sender.simple(message)
+-
+-assert_requested :post, @webhook_url, times: 1, body:
+-  { text: message }.to_json
+-  end
+-
+-  def test_card_message_request
+-stub_request(:any, /chat\.googleapis\.com/).to_return(status: 200)
+-header = { title: 'Pizza Bot Customer Support',
+-   subtitle: 'pizza...@example.com',
+-   imageUrl: 'https://goo.gl/aeDtrS' }
+-sections = [{ keyValue: { topLabel: 'Order No.', content: '12345' } },
+-{ keyValue: { topLabel: 'Status', content: 'In Delivery' } }]
+-
+-@sender.card(header, sections)
+-
+-assert_requested :post, @webhook_url, times: 1, body:
+-  { cards: [header: header, sections: sections] }.to_json
+-  end
+-
+-  def test_api_error_exception_message
+-stub_request(:any, /chat\.googleapis\.com/)
+-  .to_return(status: [403, 'Forbidden'], body: 'Response body')
+-
+-exception = assert_raises HangoutsChat::Sender::APIError do
+-  @sender.simple('Exception test')
+-end
+-assert_match(/^HTTP 403 Forbidden$/, exception.message)
+-assert_match(/^Body:\nResponse body$/, exception.message)
+-  end
+-end
+--- a/test/hangouts_chat/http_test.rb
 /dev/null
+@@ -1,31 +0,0 @@
+-require 'test_helper'
+-
+-class HTTPTest < Minitest::Test
+-  def setup
+-@url = 'https://example.com'
+-@http = HangoutsChat::Sender::HTTP.new(@url)
+-  end
+-
+-  def test_initialized_with_valid_uri
+-uri = @http.instance_variable_get(:@uri)
+-assert_equal 'https', uri.scheme
+-assert_equal 'example.com', uri.host
+-  end
+-
+-  def test_initialized_with_valid_post_request
+-req = 

Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10

2019-04-06 Thread Karl O. Pinc
On Sat, 6 Apr 2019 21:40:52 +0100
Justin B Rye  wrote:

> Karl O. Pinc wrote:
> > A) Added text in "what's new" section explaining the (sorta-new)
> > interface naming scheme and why it's good.  Mention there  
> 
> I hope you're aware that the last release-notes announced in
>  
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#new-interface-names
> that "predictable"-style nicnames were already the default for
> Stretch unless overridden in /etc/udev/rules.d/.  And they
> referenced the udev README that says this mechanism won't be
> supported in Buster 

Nope.  I'm not aware.  I don't tend to read the "what's new",
just the upgrade instructions and the section that says what
I need to do to get ready for the next release.

Or maybe I did read it and that's
what led me to file this bug report,
because there's no mention in the "what needs
to happen for the next release" section.

I do know that the new names are the default for new
stretch installs.  But stretch systems upgraded
from jessie retain old names.  Upgrading them
to buster without migrating names will break
networking.  This is what needs to be addressed.

Anyway, it is new in buster, and pretty major for anyone with
old interface names, that new names are required.
_Somewhere_ it should say what the rationale is,
and how to parse the new names.  Especially
for those who manage remote systems, for whom
maintaining connectivity throughout the upgrade
process is critical.

Sorry for running-on.  I guess I'm not sure what
your point is.  Is there something specific in
the patch of whats-new.dbk or upgrading.dbk
that you'd like changed?


> > C) Actual upgrade instructions.  This is in-progress.
> > 
> > There are really 2 paths for manual migration of
> > interface names: one for when you have console/physical
> > access and another when you don't.  In the first case,
> > you can try the new names, see what name you get, and
> > migrate /etc/.  Without console access you need to
> > calculate the new interface name, migrate, and hope
> > you got the right name after reboot.  To calculate
> > the right interface name you need additional background
> > information.  I've whacked up a teeny script, with
> > no dependencies, to compute the common case.  But it
> > does require the pciid as input, and I suggest installing
> > pciutils to get lspci to find pciids.  
> 
> Whether I'm accessing it physically or via ssh, can't I use something
> like:
>  udevadm test /sys/class/net/$ETHX 2>/dev/null | grep NET
> or
>  udevadm test-builtin net_id /sys/class/net/$ETHX 2>/dev/null
> ...?  That worked for me even on Jessie machine.

I don't know.  I just tried both the above on a
jessie box running on a VM and it did not show me
an ID_NET_NAME_PATH, which I presume is what
shows me the new-style interface name?

I don't have a stretch box with old-style names to test on.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein



Bug#924365: www.debian.org: FTBFS in buster: turkish vs. tr_TR locale

2019-04-06 Thread Laura Arjona Reina
Dear Turkish Translation team,

While working on rebuilding the Debian website [1] within stretch and
buster, Cyril Brulebois detected that the Turkish subdirectory doesn't
build in buster, apparently due to possible locale issues.

[1] https://salsa.debian.org/webmaster-team/webwml

The .wmlrc file in that folder orders to build the site using the tr_TR
locale:

turkish/.wmlrc:-D CUR_LOCALE=tr_TR

But Perl complains about that:

 wml -q -D CUR_YEAR=2019 -o UNDEFuTR:index.tr.html@g+w   index.wml
 ePerl:Error: Perl runtime error (interpreter rc=0)

  Contents of STDERR channel: -
 Locale 'tr_TR' may not work well.
 The following characters (and maybe others) may not have the same
meaning as the Perl program expects:
 I i
 ; codeset=ISO-8859-9
 --
 ** WML:Break: Error in Pass 3 (rc=1).

More details on bug report #924365

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

I've done a "file" command on all the .po and .wml files in the /turkish
folder of the website and all of them seem to be UTF-8 encoded
(charset=utf-8), so I guess it's safe to change the .wmlrc file to tell
the site to build using tr_TR.UTF-8 locale.

Could you confirm?

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona



Bug#926556: unblock: yubikey-personalization/1.19.3-3

2019-04-06 Thread Nicolas Braud-Santoni
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package yubikey-personalization

In version 1.19.3-1, I introduced a bug w.r.t. udev rules handling,
resulting in users being unable to use the software (see #924787);
as such, I deemed the bug serious, and bumped its severity accordingly.

The latest upload reverses that change, and split the udev rules to a new binary
packages (libyubikey-udev) so other packages may Depend or Recommend it.


Best,

  nicoo

unblock yubikey-personalization/1.19.3-3

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 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) (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
diff -Nru yubikey-personalization-1.19.3/debian/changelog 
yubikey-personalization-1.19.3/debian/changelog
--- yubikey-personalization-1.19.3/debian/changelog 2019-02-28 
13:28:16.0 +0100
+++ yubikey-personalization-1.19.3/debian/changelog 2019-04-06 
21:14:35.0 +0200
@@ -1,3 +1,10 @@
+yubikey-personalization (1.19.3-3) unstable; urgency=high (fixes RC bug)
+
+  * Ship udev rules again, as libyubikey-udev
+Closes: 924787
+
+ -- Nicolas Braud-Santoni   Sat, 06 Apr 2019 21:14:35 +0200
+
 yubikey-personalization (1.19.3-2) unstable; urgency=medium
 
   * debian/control: Mark libykpers-1-dev as Multi-Arch: same.
diff -Nru 
yubikey-personalization-1.19.3/debian/com.yubico.yubikey.udev.metainfo.xml 
yubikey-personalization-1.19.3/debian/com.yubico.yubikey.udev.metainfo.xml
--- yubikey-personalization-1.19.3/debian/com.yubico.yubikey.udev.metainfo.xml  
1970-01-01 01:00:00.0 +0100
+++ yubikey-personalization-1.19.3/debian/com.yubico.yubikey.udev.metainfo.xml  
2019-04-06 21:14:35.0 +0200
@@ -0,0 +1,29 @@
+
+
+  com.yubico.yubikey.udev
+  MIT
+  libyubikey-udev
+  udev rules supporting YubiKeys
+  
+
+  libyubikey-udev allows you to use the YubiKey security hardware
+  as a non-root user.
+
+
+  For support of the U2F (Universal 2nd Factor) functionality,
+  see libu2f-udev.
+
+  
+  
+usb:v1050p0010d*
+usb:v1050p0110d*
+usb:v1050p0111d*
+usb:v1050p0114d*
+usb:v1050p0116d*
+usb:v1050p0401d*
+usb:v1050p0403d*
+usb:v1050p0405d*
+usb:v1050p0407d*
+usb:v1050p0410d*
+  
+
diff -Nru yubikey-personalization-1.19.3/debian/control 
yubikey-personalization-1.19.3/debian/control
--- yubikey-personalization-1.19.3/debian/control   2019-02-28 
13:28:16.0 +0100
+++ yubikey-personalization-1.19.3/debian/control   2019-04-06 
21:14:35.0 +0200
@@ -11,6 +11,7 @@
 Build-Depends:
debhelper-compat (= 12),
pkg-config,
+   udev [linux-any],
libusb-1.0-0-dev [!hurd-i386],
libusb-dev [hurd-i386],
libyubikey-dev(>= 1.5),
@@ -23,7 +24,7 @@
 
 Package: yubikey-personalization
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, libyubikey-udev
 Description: Personalization tool for Yubikey OTP tokens
  YubiKeys are USB tokens that act like keyboards and generate one-time
  or static passwords.
@@ -37,7 +38,7 @@
 Section: libs
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: libu2f-udev
+Recommends: libyubikey-udev
 Replaces: yubikey-personalization (<< 1.12.0-4)
 Breaks: yubikey-personalization (<< 1.12.0-4)
 Description: Library for personalization of YubiKey OTP tokens
@@ -57,3 +58,14 @@
  or static passwords.
  .
  This package contains the development files for the library.
+
+Package: libyubikey-udev
+Architecture: all
+Multi-Arch: foreign
+Section: libs
+Depends: ${misc:Depends}, udev
+Description: udev rules for unprivileged access to YubiKeys
+ YubiKeys are USB tokens that act like keyboards and generate one-time
+ or static passwords.
+ .
+ This package contains the udev rules that enable unprivileged users to access 
them.
diff -Nru yubikey-personalization-1.19.3/debian/libyubikey-udev.install 
yubikey-personalization-1.19.3/debian/libyubikey-udev.install
--- yubikey-personalization-1.19.3/debian/libyubikey-udev.install   
1970-01-01 01:00:00.0 +0100
+++ yubikey-personalization-1.19.3/debian/libyubikey-udev.install   
2019-04-06 21:14:35.0 +0200
@@ -0,0 +1,2 @@
+lib/udev/rules.d/*-yubikey.rules
+debian/com.yubico.yubikey.udev.metainfo.xml /usr/share/metadata/
diff -Nru yubikey-personalization-1.19.3/debian/rules 
yubikey-personalization-1.19.3/debian/rules
--- 

Bug#926555: unblock: yubico-piv-tool/1.7.0-1

2019-04-06 Thread Nicolas Braud-Santoni
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package yubico-piv-tool

The latest upstream release contains security-critical changes (see #926551).

I apologise for the larger-than-necessary diff, which includes some packaging
changes that were pending upload  :(

The debdiff is enclosed; it isn't authoritative, as the package still needs to
be uploaded to sid (I accidentally let my signing key expire while ill, so this
is waiting on a sponsored upload...)


Best,

  nicoo

unblock yubico-piv-tool/1.7.0-1

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 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) (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
diff -Nru yubico-piv-tool-1.6.2/ChangeLog yubico-piv-tool-1.7.0/ChangeLog
--- yubico-piv-tool-1.6.2/ChangeLog 2018-09-14 09:33:28.0 +0200
+++ yubico-piv-tool-1.7.0/ChangeLog 2019-04-03 09:53:53.0 +0200
@@ -1,3 +1,156 @@
+2019-04-03  Klas Lindfors 
+
+   * NEWS, configure.ac: NEWS for 1.7.0
+
+2019-04-03  Klas Lindfors 
+
+   * : commit 7b64528cf7ba87e803a3ed29c8ca877e88796e24 Author: Dave
+   Pate  Date:   Tue Jan 22 13:59:06 2019 -0800
+
+2019-01-22  Dave Pate 
+
+   * lib/internal.h, lib/ykpiv.c: lib: tlv length buffer checks
+
+2019-01-22  Dave Pate 
+
+   * lib/util.c: lib: handle realloc failures safely
+
+2019-01-22  Dave Pate 
+
+   * lib/util.c: lib: clear secrets in set_protected_mgm
+
+2019-01-22  Dave Pate 
+
+   * lib/ykpiv.c: lib: clear secrets in ykpiv_import_private_key
+
+2019-01-21  Dave Pate 
+
+   * lib/internal.h, lib/util.c: lib: correct zero memory defines,
+   correct overflow checks in _write_certificate
+
+2019-01-17  Dave Pate 
+
+   * lib/ykpiv.c: lib: clear secrets in auth api
+
+2019-01-17  Dave Pate 
+
+   * lib/ykpiv.c: lib: check that serial/version checks occur during
+   select
+
+2019-01-07  Dave Pate 
+
+   * lib/internal.c, lib/internal.h, lib/ykpiv.c: lib: define constant
+   for max pin len magic numbers lib: clear pin buffers when no longer
+   used
+
+2019-01-07  Dave Pate 
+
+   * lib/ykpiv.c: lib: check internal authentication crypt errors
+
+2019-01-07  Dave Pate 
+
+   * lib/internal.c, lib/ykpiv.c: lib: clear buffers containing key
+   material
+
+2019-01-07  Dave Pate 
+
+   * lib/internal.h, lib/util.c: lib: use secure zero memory platform
+   functions
+
+2019-01-07  Dave Pate 
+
+   * lib/util.c, lib/ykpiv.c: lib: resolves potential reads of
+   uninitialized data
+
+2019-03-06  pedro martelletto 
+
+   * doc/YubiKey_PIV_introduction.adoc: doc: set LC_CTYPE=C; fixes
+   ef81d164 on MacOS
+
+2019-03-06  Alessio Di Mauro 
+
+   * : Merge pull request #187 from Yubico/pvs_remove_warnings Remove some 
warnings
+
+2019-03-06  Gabriel Kihlman 
+
+   * ykcs11/ykcs11.c: Do not assign variable twice
+
+2019-03-06  Gabriel Kihlman 
+
+   * ykcs11/ykcs11.c: Remove duplicate check on op_info.type !=
+   YKCS11_SIGN
+
+2019-03-05  Klas Lindfors 
+
+   * : commit ef81d1646536d5d9f2056cdc78a4a1052e8851a7 Author: pedro
+   martelletto  Date:   Tue Mar 5 07:58:09 2019 +0100
+
+2019-02-20  Alessio Di Mauro 
+
+   * : Merge PR#184
+
+2019-02-18  Klas Lindfors 
+
+   * windows.mk: bump openssl version and don't include check binaries
+
+2019-02-15  Alessio Di Mauro 
+
+   * : Merge PR#183
+
+2019-02-15  Alessio Di Mauro 
+
+   * : Merge PR #182
+
+2019-01-07  Alessio Di Mauro 
+
+   * ykcs11/ykcs11.c: ykcs11: use a large enough buffer when writing EC
+   signatures
+
+2019-01-02  Klas Lindfors 
+
+   * : commit 811ddbb22d293aea6508d69bb7b98d8386fc8071 Author: Stacey
+   Sheldon  Date:   Tue Jan 1 01:43:51 2019
+   -0500
+
+2019-01-01  Stacey Sheldon 
+
+   * tools/fasc.pl: FASC-N: correct encoding of the packed 4-bit
+   decimal format with odd parity The BCD digits in the FASC-N credential 
are sent lsb first followed
+   by an odd parity.  Since this perl script is simply packing the bits
+   in their expected order, the encodings should exactly match figure 7
+   in "Technical Implementation Guidance: Smart Card Enabled Physical
+   Access Control Systems Version 2.2".
+
+2018-12-18  Klas Lindfors 
+
+   * tools/fasc.pl: fix fasc-n value of 1 relates #177
+
+2018-09-21  Klas Lindfors 
+
+   * : commit 898b85821cbfa2c0b841e46d39a45b42e9891bfd Author: Klas
+   Lindfors  Date:   Tue Sep 18 08:38:57 2018 +0200
+

Bug#924333: FTBFS: missing czech/News/weekly/index.wml

2019-04-06 Thread Laura Arjona Reina
Hello
I have added an index.wml file to /czech/News/weekly/index.wml with
copypage.pl to allow this folder to be built:

https://salsa.debian.org/webmaster-team/webwml/blob/master/czech/News/weekly/index.wml

CC'ing Miroslav Kure and the Debian Czech Translation team mailing list
to see if they can provide a translation for it.

I feel this is a workaround and we should tune the Makefile to use the
English file if the translated file is not present, so I'm leaving this
bug open, for now.

Kind regards,

El 11/3/19 a las 18:49, Cyril Brulebois escribió:
> Package: www.debian.org
> Severity: normal
> User: www.debian@packages.debian.org
> Usertags: scripts
> 
> Hi,
> 
> While working on rebuilding the website within stretch and buster, I've
> noticed the following.
> 
> The build fails both in stretch and in buster due to a missing file
> (czech/News/weekly/index.wml):
> 
> make -C weekly
> make[3]: Entering directory 
> '/home/kibi/debian-www/stretch/webwml/czech/News/weekly'
> make[3]: *** No rule to make target 'index.wml', needed by 
> 'index.cs.html'.  Stop.
> make[3]: Leaving directory 
> '/home/kibi/debian-www/stretch/webwml/czech/News/weekly'
> ../../Makefile.common:79: recipe for target 'weekly' failed
> make[2]: *** [weekly] Error 2
> make[2]: Leaving directory 
> '/home/kibi/debian-www/stretch/webwml/czech/News'
> ../Makefile.common:79: recipe for target 'News' failed
> make[1]: *** [News] Error 2
> make[1]: Leaving directory '/home/kibi/debian-www/stretch/webwml/czech'
> Makefile:28: recipe for target 'czech' failed
> make: *** [czech] Error 2
> 
> This seems to date back to this commit:
>   
> https://salsa.debian.org/webmaster-team/webwml/commit/0cbd1d8ebfa0d33b09d84e495a0c661e8830dabd
> 
> which is from 2007.
> 
> If fixing the missing index file doesn't make sense, the parent Makefile
> should perhaps not recurse into that subdirectory?
> 
> 
> Cheers,
> 

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona



Bug#926554: xbindkeys-config: segfault upon "Get key"

2019-04-06 Thread Adam Borowski
Package: xbindkeys-config
Version: 0.1.3-2+b2
Severity: important

Hi!
There's already a separate bug about "Get key" segfaulting when there's no
default config (#268630) -- but for me, it segfaults a bit later when the
config is there.

Without the config, "Get key" segfaults immediately.
After generating it manually, a window appears, but trying to interact with
it results in:


Program received signal SIGSEGV, Segmentation fault.
middle_get_key (data=, parent=) at middle.c:364

(gdb) bt full
#0  middle_get_key (data=, parent=) at 
middle.c:364
f = 0x6f5c80
buf = "Press combination of keys or/and click under the window.\nYou 
can use one of the two lines after \"NoCommand\"\nin $HOME/.xbindkeysrc to bind 
a key.\n\344\347\255=\246\245\264\300\335\377\377\177\000\000\000|#۷\177", 
'\000' , 
"\344\347\255=\246\245\264@\336\377\377\177\000\000\000\274\251۷\177\000\000\000\060\211"...
buf2 = 
"0\000\000\000\000\000\000\000p\334\377\377\177\000\000\000\060\000\000\000\000\000\000\000P\000\000\000\000\000\000\000\200\333\377\377\177\000\000\000\214\241S\267\177\000\000\000@\000\000\000\000\000\000\000\360\324oUU\000\000\000\000\271qUU\000\000\000\320;pUU\000\000\000Z\000\000\000\000\000\000\000u\000\000\000\000\000\000\000\020\271qU"
pl1 = 0x1 
pl2 = 
buf3 = {0xb4a5a63dade7e400 , 0x7fdba0 "", 0x7fb7abba20 "\307\002@\271\363\003", 
0x6fd508 "c\002", 
  0x7fb7abc6a4 "\352w@\271!\a@\371?\300", , 
0x7fdc00 "\220\334\377\377\177", 
  0x7fb7abc6a4 "\352w@\271!\a@\371?\300", , 
0x71b910 "0", 0x703be0 " 1rUU", 0x71b910 "0", 0x7fb7abb5a8 
"\375{\273\251\177", 
  0x6fd4f8 "\002", 0x75 , 0x6fd4f0 "\004", 0x703bd0 "\340\265qUU", 0x71b900 "c\002", 
  0x7fdda0 "\300\335\377\377\177", 0x7fdc90 "", 0x7fb7abccd8 
 "\341\003\023\252", 0x6fd240 "\300\324oUU", 
0x5c6360 "\020@\\UU", 
  0x6fd6d0 "@\322oUU", 0x5c6360 "\020@\\UU", 0x0, 0x0, 0x0, 
0x5c6480 "\020@\\UU", 0x20 , 
0x7fb763b490 "\002", 
  0x7fdcb0 "`\335\377\377\177", 
  0x7fb7ac7a84 "\367cC\251\371kD\251\350'Fm\275\377\377\027\300v@\371 
\377\377\264\300:@\371\340\376\377\265\351\377\377\027@\033@\371\340O", 
0x7fb7b4c000 "", 
  0x5c6360 "\020@\\UU", 0x6fd6d0 "@\322oUU", 0x5c6360 
"\020@\\UU", 0x0, 0x0, 0x7fb7b4c000 "", 0x5c6360 "\020@\\UU", 
  0x7fdd60 "s after \"NoCommand\"\nin $HOME/.xbindkeysrc to bind a 
key.\n\344\347\255=\246\245\264\300\335\377\377\177", 
  0x7fb7ac7d50 
"\340\003\025\252\327\323\377\227\367\033@\371\333\377\377\027\341#\001\221\340\003\024\252\365\003\001\252\342S\001\221\341C\001\221\377'",
 
  0x7fb7b4c000 "", 0x5c6360 "\020@\\UU", 0x6fd6d0 "@\322oUU", 
0x0, 0x1 , 
  0xa2 , 0x1b , 0x338 , 
  0x20 }
len = 145
i = 
__s1_len = 
__s2_len = 
#1  0x007fb76299f0 in g_closure_invoke () from 
/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#2  0x007fb763e2c4 in ?? () from 
/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#3  0x007fb764660c in g_signal_emit_valist () from 
/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#4  0x007fb7646b78 in g_signal_emit () from 
/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#5  0x007fb7bde9e0 in ?? () from 
/usr/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0
No symbol table info available.
#6  0x007fb7c8e63c in ?? () from 
/usr/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0
No symbol table info available.
#7  0x007fb76299f0 in g_closure_invoke () from 
/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#8  0x007fb763db38 in ?? () from 
/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#9  0x007fb7646030 in g_signal_emit_valist () from 
/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#10 0x007fb7646b78 in g_signal_emit () from 
/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#11 0x007fb7db1ca0 in ?? () from 
/usr/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0
No symbol table info available.
--Type  for more, q to quit, c to continue without paging--
#12 0x007fb7c8c53c in gtk_propagate_event () from 
/usr/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0
No symbol table info available.
#13 0x007fb7c8c9a4 in gtk_main_do_event () from 
/usr/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0
No symbol table info available.
#14 0x007fb7ae559c in ?? () from 
/usr/lib/aarch64-linux-gnu/libgdk-x11-2.0.so.0
No symbol table info available.
#15 0x007fb7534634 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#16 0x007fb75348a8 in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
No symbol table info available.

Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10

2019-04-06 Thread Justin B Rye
Karl O. Pinc wrote:
> A) Added text in "what's new" section explaining the (sorta-new)
> interface naming scheme and why it's good.  Mention there

I hope you're aware that the last release-notes announced in
 
https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#new-interface-names
that "predictable"-style nicnames were already the default for
Stretch unless overridden in /etc/udev/rules.d/.  And they
referenced the udev README that says this mechanism won't be
supported in Buster - the justifications struck me as weak, but
given a full release cycle's advance warning I wasn't going to
object.

> C) Actual upgrade instructions.  This is in-progress.
> 
> There are really 2 paths for manual migration of
> interface names: one for when you have console/physical
> access and another when you don't.  In the first case,
> you can try the new names, see what name you get, and
> migrate /etc/.  Without console access you need to
> calculate the new interface name, migrate, and hope
> you got the right name after reboot.  To calculate
> the right interface name you need additional background
> information.  I've whacked up a teeny script, with
> no dependencies, to compute the common case.  But it
> does require the pciid as input, and I suggest installing
> pciutils to get lspci to find pciids.

Whether I'm accessing it physically or via ssh, can't I use something
like:
 udevadm test /sys/class/net/$ETHX 2>/dev/null | grep NET
or
 udevadm test-builtin net_id /sys/class/net/$ETHX 2>/dev/null
...?  That worked for me even on Jessie machine.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#926553: git-buildpackage: gbp-dch resets the urgency when updating a changelog entry

2019-04-06 Thread Nicolas Braud-Santoni
Package: git-buildpackage
Version: 0.9.14
Severity: minor

Hi,

When running `gbp dch` and the changelog contains an UNRELEASED entry, the entry
is updated but its urgency is reset to `medium`, despite preserving the comment:

  $ git status
  [...]
  nothing to commit, working tree clean

  $ gbp dch --full   
  gbp:info: Changelog last touched at '4b2e728aa5b340bb912d407e0a381a2e70fee792'
  gbp:info: No changes detected from 4b2e728aa5b340bb912d407e0a381a2e70fee792 
to HEAD.

  $ git diff
  diff --git i/debian/changelog w/debian/changelog
  index 91eb7d7..789bd6e 100644
  --- i/debian/changelog
  +++ w/debian/changelog
  @@ -1,4 +1,4 @@
  -yubico-piv-tool (1.7.0-1) UNRELEASED; urgency=high (security fixes)
  +yubico-piv-tool (1.7.0-1) UNRELEASED; urgency=medium (security fixes)
   
 [ Nicolas Braud-Santoni ]
 * New upstream version 1.7.0
  @@ -28,7 +28,7 @@ yubico-piv-tool (1.7.0-1) UNRELEASED; urgency=high 
(security fixes)
 [ Simon Josefsson ]
 * Drop myself from Uploaders.
   
  - -- Nicolas Braud-Santoni   Sat, 06 Apr 2019 22:26:01 +0200
  + -- Nicolas Braud-Santoni   Sat, 06 Apr 2019 22:41:01 +0200
 
 yubico-piv-tool (1.6.2-1) unstable; urgency=high


Best,

  nicoo

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 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) (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 git-buildpackage depends on:
ii  devscripts 2.19.4
ii  git1:2.20.1-2
ii  man-db 2.8.5-2
ii  python33.7.2-1
ii  python3-dateutil   2.7.3-3
ii  python3-pkg-resources  40.8.0-1
ii  sensible-utils 0.0.12

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.46
ii  python3-requests  2.21.0-1
ii  sbuild0.78.1-2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.8.27-1
ii  unzip6.0-22

-- Configuration Files:
/etc/git-buildpackage/gbp.conf changed:
[DEFAULT]
builder = sbuild -v --no-clean-source
[buildpackage]
postbuild = cd /opt/deb/buildarea && apt-ftparchive packages . > Packages
export-dir = /opt/deb/buildarea
dist = DEP14
[import-orig]
[import-dsc]
[dch]
[pq]
[clone]
[pull]
[create-remote-repo]
[remote-config pkg-libvirt]
remote-url-pattern = ssh://git.debian.org/git/pkg-libvirt/%(pkg)s
template-dir = 
/srv/alioth.debian.org/chroot/home/groups/pkg-libvirt/git-template


-- no debconf information



Bug#926549: reference to the MP

2019-04-06 Thread Christian Ehrhardt
Hi I opened an MP that fixes this issue (and a bunch of further minor
issues due to the version 1.5 being in git, but incomplete for now)

=> https://salsa.debian.org/debian-hamradio-team/direwolf/merge_requests/1

--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd



Bug#926552: python3-pil: fails loading some PNGs with AttributeError: 'PngStream' object has no attribute 'chunk_tIME'

2019-04-06 Thread Helmut Grohne
Package: python3-pil
Version: 5.4.1-1
Severity: important
Tags: upstream fixed-upstream
Forwarded: https://github.com/python-pillow/Pillow/issues/3557

PIL.Image fails to load some PNG files. The vast majority of PNGs does
load.

$ dpkg -l antiword
...
ii  antiword   0.37-14  amd64Converts MS Word files to text, 
PS, PDF and XML
$ python3 -c "import PIL.Image; 
PIL.Image.open(open('/usr/share/icons/hicolor/48x48/apps/antiword.png', 
'rb')).load()"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/PIL/ImageFile.py", line 252, in load
self.load_end()
  File "/usr/lib/python3/dist-packages/PIL/PngImagePlugin.py", line 680, in 
load_end
self.png.call(cid, pos, length)
  File "/usr/lib/python3/dist-packages/PIL/PngImagePlugin.py", line 140, in call
return getattr(self, "chunk_" + cid.decode('ascii'))(pos, length)
AttributeError: 'PngStream' object has no attribute 'chunk_tIME'
$

This issue has been reported and fixed upstream. Is it reasonable to
cherry-pick the relevant commit[1] into buster?  Otherwise this bug will
be fixed when updating to 6.0.0.

Helmut

[1] 
https://github.com/python-pillow/Pillow/commit/4e0a73b4faf4c0b16c6b3912b64f4ad7a6c99acf



Bug#917807: libcaca: diff for NMU version 0.99.beta19-2.1

2019-04-06 Thread Tobias Frost
Control: tags 917807 + patch
Control: tags 917807 + pending

Dear maintainer,

I've prepared an NMU for libcaca (versioned as 0.99.beta19-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru libcaca-0.99.beta19/debian/changelog libcaca-0.99.beta19/debian/changelog
--- libcaca-0.99.beta19/debian/changelog	2014-06-02 22:39:11.0 +0200
+++ libcaca-0.99.beta19/debian/changelog	2019-04-06 22:18:41.0 +0200
@@ -1,3 +1,12 @@
+libcaca (0.99.beta19-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-Pick fixes from upstream git repository:
+- CVE-2018-20545, CVE-2018-20546, CVE-2018-20547,CVE-2018-20548 and
+  CVE-2018-20549 (Closes: #917807)
+
+ -- Tobias Frost   Sat, 06 Apr 2019 22:18:41 +0200
+
 libcaca (0.99.beta19-2) unstable; urgency=medium
 
   * debian/patches/100_doxygen.diff: remove deprecated Doxygen variables.
diff -Nru libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch
--- libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch	1970-01-01 01:00:00.0 +0100
+++ libcaca-0.99.beta19/debian/patches/CVE-2018-20544.patch	2019-04-06 21:36:52.0 +0200
@@ -0,0 +1,45 @@
+From 84bd155087b93ab2d8d7cb5b1ac94ecd4cf4f93c Mon Sep 17 00:00:00 2001
+From: Sam Hocevar 
+Date: Sat, 29 Dec 2018 22:13:56 +0100
+Subject: [PATCH] dither: fix integer overflows that were causing a division by
+ zero.
+
+Fixes: #36 (CVE-2018-20544)
+---
+ caca/dither.c | 16 
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/caca/dither.c b/caca/dither.c
+index 04b678e0..c6ebab1b 100644
+--- a/caca/dither.c
 b/caca/dither.c
+@@ -991,10 +991,10 @@ int caca_dither_bitmap(caca_canvas_t *cv, int x, int y, int w, int h,
+ /* First get RGB */
+ if(d->antialias)
+ {
+-fromx = (x - x1) * w / deltax;
+-fromy = (y - y1) * h / deltay;
+-tox = (x - x1 + 1) * w / deltax;
+-toy = (y - y1 + 1) * h / deltay;
++fromx = (uint64_t)(x - x1) * w / deltax;
++fromy = (uint64_t)(y - y1) * h / deltay;
++tox = (uint64_t)(x - x1 + 1) * w / deltax;
++toy = (uint64_t)(y - y1 + 1) * h / deltay;
+ 
+ /* We want at least one pixel */
+ if(tox == fromx) tox++;
+@@ -1017,10 +1017,10 @@ int caca_dither_bitmap(caca_canvas_t *cv, int x, int y, int w, int h,
+ }
+ else
+ {
+-fromx = (x - x1) * w / deltax;
+-fromy = (y - y1) * h / deltay;
+-tox = (x - x1 + 1) * w / deltax;
+-toy = (y - y1 + 1) * h / deltay;
++fromx = (uint64_t)(x - x1) * w / deltax;
++fromy = (uint64_t)(y - y1) * h / deltay;
++tox = (uint64_t)(x - x1 + 1) * w / deltax;
++toy = (uint64_t)(y - y1 + 1) * h / deltay;
+ 
+ /* tox and toy can overflow the canvas, but they cannot overflow
+  * when averaged with fromx and fromy because these are guaranteed
diff -Nru libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch
--- libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch	1970-01-01 01:00:00.0 +0100
+++ libcaca-0.99.beta19/debian/patches/CVE-2018-20545+20547+20549.patch	2019-04-06 22:08:34.0 +0200
@@ -0,0 +1,34 @@
+Description: img2txt: fix an integer overflow in the BMP loader.
+Origin: https://github.com/cacalabs/libcaca/commit/3e52dabe3e64dc50f4422effe364a1457a8a8592
+Forwarded: not-needed
+Applied-Upstream: https://github.com/cacalabs/libcaca/commit/3e52dabe3e64dc50f4422effe364a1457a8a8592
+Last-Update: 2019-04-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/common-image.h
 b/src/common-image.h
+@@ -1,19 +1,19 @@
+ /*
+  *  Imaging tools for cacaview and img2irc
+- *  Copyright (c) 2003-2012 Sam Hocevar 
+- *All Rights Reserved
++ *  Copyright (c) 2003-2018 Sam Hocevar 
++ *  All Rights Reserved
+  *
+  *  This program is free software. It comes without any warranty, to
+  *  the extent permitted by applicable law. You can redistribute it
+  *  and/or modify it under the terms of the Do What the Fuck You Want
+- *  to Public License, Version 2, as published by Sam Hocevar. See
+- *  http://www.wtfpl.net/ for more details.
++ *  to Public License, Version 2, as published by the WTFPL Task Force.
++ *  See http://www.wtfpl.net/ for more details.
+  */
+ 
+ struct image
+ {
+ char *pixels;
+-unsigned int w, h;
++size_t w, h;
+ struct caca_dither *dither;
+ void *priv;
+ };
diff -Nru libcaca-0.99.beta19/debian/patches/CVE-2018-20546+20547.patch libcaca-0.99.beta19/debian/patches/CVE-2018-20546+20547.patch
--- libcaca-0.99.beta19/debian/patches/CVE-2018-20546+20547.patch	1970-01-01 01:00:00.0 +0100
+++ 

Bug#926540: unblock: xorg-server/2:1.20.4-1

2019-04-06 Thread Cyril Brulebois
Hi,

Andreas Boll  (2019-04-06):
> CCing kibi for unblock-udeb review

This is coming a little late for RC1 that should be published very soon.
I've added this to my local todo list but feel free to prod me once RC1
is published.

> On Sat, Apr 06, 2019 at 07:13:34PM +0200, Andreas Boll wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > Please unblock package xorg-server:
> > 
> > This stable release fixes a bunch of important issues including
> > xserver crashes. There are multiple fixes related to xwayland, present
> > and modesetting.
> > 
> > Debian changelog entry:
> > xorg-server (2:1.20.4-1) unstable; urgency=medium
> > 
> >   [ Timo Aaltonen ]
> >   * New upstream release.
> > - present/wnmd: Fix use after free on CRTC removal
> >   (Closes: #920665).
> > - xwayland: Replace xwl_window::present_window with
> >   ::present_flipped (Closes: #921734).
> > 
> >   [ Andreas Boll ]
> >   * Refresh 07_use-modesetting-driver-by-default-on-GeForce.diff.
> > 
> >  -- Andreas Boll   Tue, 05 Mar 2019 21:11:12 +0100
> > 
> > 
> > Further I've attached a git-diff with the following command to exclude
> > uninteresting CI stuff and tests to make the diff more readable:
> > 
> > git diff xorg-server-2_1.20.3-1..xorg-server-2_1.20.4-1 -- . 
> > ':(exclude)test' ':(exclude).gitlab-ci*' ':(exclude).travis.yml' > 
> > ../xorg-server_1.20.4-1.diff
> > 
> > I've also attached the output of git-shortlog to list all commit
> > titles.
> > 
> > unblock xorg-server/2:1.20.4-1
> > 
> > Thanks,
> > Andreas
> 

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


signature.asc
Description: PGP signature


Bug#924926: libgpiod2 should not conflict with libgpiod1

2019-04-06 Thread Ben Harris

On Wed, 3 Apr 2019, SZ Lin (林上智) wrote:


The APIs between libgpiod1 and libgpiod2 are quite different, and thus
the conflict setting was added to avoid any potential problem.


Differences in API (or ABI) shouldn't cause any trouble: programs built 
using the old -dev package will use libgpiod.so.1, and programs built 
using the new -dev package will use libgpiod.so.2.  This is precisely why 
they have different SONAMEs.



Can you make sure that it is harmless to co-install these two versions?


Well, I've tried co-installing them (admittedly on Raspbian, but the 
changes between the Debian and Raspbian versions are minimal) and both old 
and new versions of gpiodetect work, and pick up their correct library 
versions:


bjh21@fugloy:/tmp $ sudo /usr/bin/gpiodetect
gpiochip0 [pinctrl-bcm2835] (54 lines)
bjh21@fugloy:/tmp $ sudo ./gpiod-1.2/usr/bin/gpiodetect
gpiochip0 [pinctrl-bcm2835] (54 lines)
bjh21@fugloy:/tmp $ ldd /usr/bin/gpiodetect
libgpiod.so.1 => /usr/lib/arm-linux-gnueabihf/libgpiod.so.1 (0xb6f18000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6dca000)
/lib/ld-linux-armhf.so.3 (0xb6f2e000)
bjh21@fugloy:/tmp $ ldd ./gpiod-1.2/usr/bin/gpiodetect
libgpiod.so.2 => /usr/lib/arm-linux-gnueabihf/libgpiod.so.2 (0xb6fb8000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e6a000)
/lib/ld-linux-armhf.so.3 (0xb6fce000)

So they appear to be co-installable, and both work properly when they're 
co-installed.  I can't see any reason why they should interact badly.


--
Ben Harris

Bug#926551: libykpiv1: Security issues in versions prior to 1.7.0

2019-04-06 Thread Nicolas Braud-Santoni
Package: libykpiv1
Version: 1.6.2-1
Severity: serious
Tags: security buster sid upstream fixed-upstream pending
Justification: Security issue

Hi,

Yubico released a new version of libykpiv, mentionning “security fixes” in
the NEWS file, but without publishing a new security advisory.

I believe this refers to the following issues (quoting changelog entries):

* Memory unsafety:
* lib/internal.h, lib/ykpiv.c: lib: tlv length buffer checks
* lib/internal.h, lib/util.c: lib: correct overflow checks in 
_write_certificate
* lib/util.c, lib/ykpiv.c: lib: resolves potential reads of
uninitialized data

* Correctly erasing secrets from memory after use:
  * lib/util.c: lib: clear secrets in set_protected_mgm
* lib/ykpiv.c: lib: clear secrets in ykpiv_import_private_key
* lib/ykpiv.c: lib: clear secrets in auth api
* lib/internal.c, lib/ykpiv.c: lib: clear buffers containing key
  material
* lib/internal.h, lib/util.c: lib: use secure zero memory platform
functions

* lib/ykpiv.c: lib: check internal authentication crypt errors


Given the absence of an advisory, I assume those issues are not known to be
exploitable.  However, I believe it would be worth fixing them before the
release of Buster.

Please let me know if a fix should be backported to stretch.


Best,

  nicoo


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 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) (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 libykpiv1 depends on:
ii  libc6 2.28-8
ii  libpcsclite1  1.8.24-1
ii  libssl1.1 1.1.1b-1

Versions of packages libykpiv1 recommends:
ii  pcscd  1.8.24-1

libykpiv1 suggests no packages.

-- no debconf information


Bug#926540: unblock: xorg-server/2:1.20.4-1

2019-04-06 Thread Andreas Boll
CCing kibi for unblock-udeb review

On Sat, Apr 06, 2019 at 07:13:34PM +0200, Andreas Boll wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package xorg-server:
> 
> This stable release fixes a bunch of important issues including
> xserver crashes. There are multiple fixes related to xwayland, present
> and modesetting.
> 
> Debian changelog entry:
> xorg-server (2:1.20.4-1) unstable; urgency=medium
> 
>   [ Timo Aaltonen ]
>   * New upstream release.
> - present/wnmd: Fix use after free on CRTC removal
>   (Closes: #920665).
> - xwayland: Replace xwl_window::present_window with
>   ::present_flipped (Closes: #921734).
> 
>   [ Andreas Boll ]
>   * Refresh 07_use-modesetting-driver-by-default-on-GeForce.diff.
> 
>  -- Andreas Boll   Tue, 05 Mar 2019 21:11:12 +0100
> 
> 
> Further I've attached a git-diff with the following command to exclude
> uninteresting CI stuff and tests to make the diff more readable:
> 
> git diff xorg-server-2_1.20.3-1..xorg-server-2_1.20.4-1 -- . ':(exclude)test' 
> ':(exclude).gitlab-ci*' ':(exclude).travis.yml' > ../xorg-server_1.20.4-1.diff
> 
> I've also attached the output of git-shortlog to list all commit
> titles.
> 
> unblock xorg-server/2:1.20.4-1
> 
> Thanks,
> Andreas



Bug#926474: [Pkg-samba-maint] Bug#926474: smbclient: Can browse samba shares as root but not as user

2019-04-06 Thread Mathieu Parent
Le sam. 6 avr. 2019 à 16:00,  a écrit :
>
> Hi, Mathieu, thanks for your reply.
>
> I tried either with the new smb.conf (att. smb.conf.up1)  suggested during 
> installing samba, and with the version taken from previous releases and which 
> is working flawlessly in Stretch (att. smb.conf.ucf-old). Does not change the 
> problem.

Is Winbind installed? Are you using pam_winbind and nss_winbind? What
is your complete command?

Regards

--
Mathieu Parent



Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk

2019-04-06 Thread Chris Hofstaedtler
* Colin Watson  [190406 19:50]:
> Hmm.  I tried doing that in a virt-manager VM as follows:
> 
>  * started with a buster alpha-5 netinst ISO rather than the full DVD
>image, since my bandwidth is very limited
>  * configured VM to use UEFI
>  * guided partitioning; selected full-disk encryption; deleted /boot
>partition; accepted all other defaults
>  * waited for grub-installer to fail, then appended
>GRUB_ENABLE_CRYPTODISK=y to /target/etc/default/grub and tried again
>  * ran into #918590 and mounted /target/run to work around it

FTR, I've tried this as well, and found it to work.
Now both bug reports hint at upgrading packages, but my reproduction
try did not need any upgrades as it was a fresh install. So maybe
the key lies there...

Cheers,
Chris



Bug#925911: RFS: lopsub-1.0.2 [ITP]

2019-04-06 Thread Andre Noll
On Mon, Apr 01, 00:57, Andre Noll wrote

> > I see a static library installed by the package.  Those shouldn't generally
> > be used unless you're doing something special -- static linking makes
> > security and bugfix updates extremely tedious.  Libraries should also be
> > split into separate binary packages, with lib${name}dev providing
> > development files while lib${name}${so} the runtime lib.
> 
> Yes, I had this concern as well. I'll change the build system to
> create a shared library instead and split the binary package as you
> suggest. I'll follow up with another reply when it's ready.

Meanwhile I've addressed these two issues and fixed the remaining
lintian warnings. Please have a look at the current "pu" branch of
the lopsub repo (pu: proposed updates). This branch merges the various
topic branches, notably the branch which adds the debian/ directory and
the branch which adds support for shared libraries. dpkg-buildpackage
now builds two binary packages called liblopsub1 and liblopsub1-dev.

To create the .deb files, run something like

git clone git://git.tuebingen.mpg.de/lopsub.git
cd lopsub
git checkout origin/pu
git archive --prefix liblopsub1-1.0.2/ @ | xz > 
../liblopsub1_1.0.2.orig.tar.xz
dpkg-buildpackage

This should work on debian-9 and debian-10. I've checked that the
two packages can be installed with dpkg -i and that all projects of
mine which depend on lopsub compile and work as before. ldd shows
that the resulting executables are now linked against the dynamic
library rather than the static one (which still gets installed as
part of the -dev package).

If there are further issues, just let me know.

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#881771: release-notes: No mention of "predictable network interface names" in Debian 10

2019-04-06 Thread Karl O. Pinc
On Sat, 6 Apr 2019 21:31:42 +0300
Andrei POPESCU  wrote:

> On Sb, 06 apr 19, 10:28:15, Karl O. Pinc wrote:
> > C) Actual upgrade instructions.  This is in-progress.
> > 
> > There are really 2 paths for manual migration of
> > interface names: one for when you have console/physical
> > access and another when you don't.  In the first case,
> > you can try the new names, see what name you get, and
> > migrate /etc/.  Without console access you need to
> > calculate the new interface name, migrate, and hope
> > you got the right name after reboot.  To calculate
> > the right interface name you need additional background
> > information.  I've whacked up a teeny script, with
> > no dependencies, to compute the common case.  But it
> > does require the pciid as input, and I suggest installing
> > pciutils to get lspci to find pciids.  
> 
> According to [1] here are two other options:
> 
> 3. assign own names (e.g. internet0, dmz0, lan0, etc.) by creating a 
> .link file in /etc/systemd/network/ and migrate your configuration 
> accordingly.

This I was not thinking of, although I'd skimmed [1].

This is sort of like choice 2, in that it requires digging
into hardware identifiers.  But being able to use, say, a
MAC address instead of digging into the intricacies of the bus
makes this a simpler approach.  It would also be nice
to use this approach to keep the old eth* name and not
have to change the rest of /etc/ at all.

On the other hand, it does
not really help in migrating to the new naming scheme.

> 4. disable the naming policy (via kernel parameter or udev) and 
> optionally migrate later (e.g. when one has console access to the 
> system).
> 
> It should be possible to use the kernel parameter in combination with
> a "boot once" grub entry to both get the new name and test the new 
> configuration for remote systems.

Humm.  Yes.  [2] says this will work.  For some reason I thought
it said this approach was going away, but it does not say that.

This might be simplest when updating remote systems.  Although
it would require an "at" job to reboot after the "boot once".  Right?
At least if trying to migrate remotely.

> Wouldn't it make sense to ask also the udev/systemd maintainers for 
> input?

Absolutely.  But it might be best to wait and let them review something
already written.  From my experience with [3] they don't seem
particularly interested in coming up with specific procedures
when console access is not available.  All that got added
to the udev/systemd instructions was a warning that you'd
better have console access when migrating to the new interface
names.

I am using [2] and [3] as my starting point for the instructions
on migrating to the new network interface naming scheme.

I don't feel I'm an expert here.  But something needs to be done
or a lot of people's networking is going to break on upgrading
to buster.

I'm attaching new_if_names_v1.patch, so you can see what I have.
(The upgrading.dbk file is not even close to valid.)
The patch may also give you URLs to other useful resources.

> [1]
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

[2]
https://sources.debian.org/src/systemd/241-2/debian/udev.README.Debian/
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/udev.README.Debian

[3]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881769

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
diff --git a/en/issues.dbk b/en/issues.dbk
index 35841ee6..6d831f62 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -1,3 +1,4 @@
+
 
 http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
@@ -39,6 +40,196 @@ information mentioned in .
 
   
 
+  
+Migrating from legacy eth and
+wlan style network interface names
+
+Debian buster requires the new network interface naming
+scheme.  Legacy network interface names, names beginning with
+eth or wlan are no longer
+supported.
+
+
+  This section applies only to systems upgraded to stretch,
+  Debian 9.  Systems installed as stretch, using the stretch
+  installer, already use the new naming scheme.
+
+
+Interface names must be be manually migrated to the new
+naming scheme before upgrading to Debian 10.  If you rely on the
+old names in custom ifupdown stanzas, firewall scripts, or other
+networking configuration, these will also need to be updated to
+the new names.
+
+
+  This process may render your machine inaccessible through
+  ssh. Be sure to have physical or console access to the machine,
+  or a way to revert to your existing configuration.
+
+
+First, determine all relevant network interface names: those
+in /etc/udev/rules.d/70-persistent-net.rules,
+or if that does not exist (in the case of virtual machines), in
+ip link or
+/sys/class/net/.
+
+The following command may be helpful
+
+
+# ls /sys/class/net | egrep 

Bug#926549: libgps changed API of gps_read

2019-04-06 Thread Christian Ehrhardt
Package: direwolf
Version: 1.4+dfsg-1

Hi,
libgps changed the gps_read implementation in [0].
To be clear the change in gpsd is currently only in experimental. This
is a heads up for the post buster transition that will come sooner or
later.

Uptream direwolf already fixed that in [1] The change isn't too hard
and will be compatible with older versions. That fix is unfortunately
not yet in the version 1.5 that I found in your repository [2],
therefore I'd appreciate if you could include this change in
when-/whatever the next upload to direwolf will happen. I'll let the
gpsd maintainer know about the bug, so that we can consider it when
kicking off the transition.

[0]: https://git.savannah.gnu.org/cgit/gpsd.git/commit/?id=6bba8b329
[1]: https://github.com/wb2osz/direwolf/commit/a1e2d1c3a
[2]: https://salsa.debian.org/debian-hamradio-team/direwolf

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd



Bug#926539: rootskel: steal-ctty no longer works on at least sparc64

2019-04-06 Thread John Paul Adrian Glaubitz
On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> My suspicion is that the support multiple consoles in parallel [2] introduced
> this particular regression. I haven't done any debugging yet though as I'm
> not sure where to start, I haven't touched the rootskel package before and
> therefore would be interested in any pointers how to debug this.

The problem seems to be the fact that the sparc64 kernel uses different names
for /proc/console and the actual console name:

root@landau:~# cat /proc/consoles 
ttyHV0   -W- (EC p  )4:64
tty0 -WU (E )4:1
root@landau:~# readlink /sys/dev/char/4:64
../../devices/root/f0299a70/f029b788/tty/ttyS0
root@landau:~#

And this is what used to make it work [1]:

*) # >= 2.6.38
console_major_minor="$(get-real-console-linux)"
console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
console="${console_raw##*/}"
;;

Adrian

> [1] 
> https://salsa.debian.org/installer-team/rootskel/blob/cb7db898f58f14c04b9d60351811cbae71b49a07/src/sbin/reopen-console-linux#L21

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



Bug#922153: ncurses-base: for screen and variants, please change smacs and rmacs to \E(0 and \E(B respectively

2019-04-06 Thread Thomas Dickey
On Mon, Feb 25, 2019 at 12:05:58AM +0100, Vincent Lefevre wrote:
...
> This is not what I obtain:
> 
> zira:~> env | grep '^TERM'
> TERM=linux
> zira:~> infocmp
> #   Reconstructed via infocmp from file: /home/vinc17/.terminfo/l/linux
> [...]
...

https://invisible-island.net/ncurses/ncurses.faq.html#home_terminfo

(the file got there by your running infocmp without root-privilege)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature


Bug#924787: yubikey-personalization: Devices unuseable after upgrade (udev rules missing)

2019-04-06 Thread Nicolas Braud-Santoni
Control: retitle -1 yubikey-personalization: Devices unuseable after upgrade 
(udev rules missing)
Control: severity -1 serious
Control: tag -1 + confirmed pending buster sid

On Sun, Mar 17, 2019 at 06:17:41PM +0100, Priv At wrote:
> Package: yubikey-personalization
> Version: 1.19.3-2
> Severity: important
> 
> Dear Maintainer,

Hi,

Thanks a lot for reporting this issue, and sorry for letting it slip
through my testing, and for taking so long to get back to you.  :(
(I was quite ill)

As it is makes the package mostly-unuseable, I'm increasing the bug's
severity to “serious” (which is Release Critical) and will make sure the
fix goes in Buster.

I already prepared a fix, and will get it into Debian ASAP.
(My package signing key expired while I was sick, so I need to get another
 DD to upload on my behalf; no big deal, but it will make things a bit
 slower.)


On Wed, Apr 03, 2019 at 03:31:55PM -0400, Thomas Ross wrote:
> Hi,
>
> I'm having the same issue after upgrading to 1.19.3-2. The problem is in
> the udev rules - in 1.19.3-2, the package switched from providing udev
> rules to using the rules in libu2f-udev (source package libu2f-host). The
> relevant udev rules provided in libu2f-udev are:

Hi Thomas,

Thanks again for troubleshooting this.
Would you be interested in co-maintaining yubikey-personalisation?

The Yubico folks who initially packaged it don't seem too active anymore
(that's why I started maintaining things in the first place) and I've been
myself quite unreliable, due to heath issues.
Moreover, you seem to use the package more than I do ;3


Best,

  nicoo



Bug#925350: unblock: ubuntu-keyring/2018.09.18.1-5

2019-04-06 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Hideki,

On Sat, 23 Mar 2019 23:36:50 +0900 Hideki Yamane  wrote:

> +  # force remove garbage that was created by previous version, oh
moron...
> +  rm -f
/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cloud-archive\,\
ubuntu-cloud-removed-keys.gpg

Policy 10.7.3 [1] says you can't do that if the local administrator has
changed that file.

> +  # once clean up keyrings
> +  rm -f "${TRUSTEDPARTS}ubuntu-keyring-2012-cloud-archive.gpg" \
> +"${TRUSTEDPARTS}ubuntu-keyring-2012-removed-keys.gpg"

Same here. And in most other files. I admit it isn't very likely, but still.

Paul

[1] https://www.debian.org/doc/debian-policy/ch-files.html#behavior



signature.asc
Description: OpenPGP digital signature


Bug#926548: unblock: nfs-utils/1:1.3.4-2.5

2019-04-06 Thread Bernd Zeimetz
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi release-team,

please unblock package nfs-utils.

I've NMUed the package to fix #895381:

  [ Micha Lenk ]
  * [abaa2ab] handle_gssd_upcall: Fix failure to find uid in upcall string 
'mech=krb5'
by adding the suggested upstream commits as
debian/patches/0010-gssd-replace-non-thread-safe-strtok-with-strsep.patch 
and

debian/patches/0011-gssd-Duplicate-the-upcall-string-for-error-messages.patch.
rpc.gssd: WARNING: handle_gssd_upcall: failed to find uid in upcall string 
'mech=krb5'
(Closes: #895381)

Diff is attached.


unblock nfs-utils/1:1.3.4-2.5

Thanks,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
diff --git a/debian/changelog b/debian/changelog
index bd57693..f341ef5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+nfs-utils (1:1.3.4-2.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Micha Lenk ]
+  * [abaa2ab] handle_gssd_upcall: Fix failure to find uid in upcall string 
'mech=krb5'
+by adding the suggested upstream commits as
+debian/patches/0010-gssd-replace-non-thread-safe-strtok-with-strsep.patch 
and
+
debian/patches/0011-gssd-Duplicate-the-upcall-string-for-error-messages.patch.
+rpc.gssd: WARNING: handle_gssd_upcall: failed to find uid in upcall string 
'mech=krb5'
+(Closes: #895381)
+
+ -- Bernd Zeimetz   Sat, 06 Apr 2019 18:30:39 +0200
+
 nfs-utils (1:1.3.4-2.4) unstable; urgency=medium
 
   [ Laurent Bigonville ]
diff --git 
a/debian/patches/0010-gssd-replace-non-thread-safe-strtok-with-strsep.patch 
b/debian/patches/0010-gssd-replace-non-thread-safe-strtok-with-strsep.patch
new file mode 100644
index 000..ee0c376
--- /dev/null
+++ b/debian/patches/0010-gssd-replace-non-thread-safe-strtok-with-strsep.patch
@@ -0,0 +1,41 @@
+From: Frank Sorenson 
+Date: Wed, 15 Feb 2017 10:36:47 -0500
+Subject: gssd: replace non-thread-safe strtok with strsep
+
+gssd uses the non-thread-safe strtok() function, which
+can lead to incorrect program behavior.
+
+Replace strtok() with the thread-safe strsep().
+
+Signed-off-by: Frank Sorenson 
+Signed-off-by: Steve Dickson 
+
+Origin: upstream, 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=5ae8be8
+Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1419280
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895381
+Last-Update: 2019-04-05
+
+---
+ utils/gssd/gssd_proc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
+index d74d3724..30c6aceb 100644
+--- a/utils/gssd/gssd_proc.c
 b/utils/gssd/gssd_proc.c
+@@ -729,10 +729,11 @@ handle_gssd_upcall(struct clnt_upcall_info *info)
+   char*target = NULL;
+   char*service = NULL;
+   char*enctypes = NULL;
++  char*pbuf = info->lbuf;
+ 
+   printerr(2, "\n%s: '%s' (%s)\n", __func__, info->lbuf, clp->relpath);
+ 
+-  for (p = strtok(info->lbuf, " "); p; p = strtok(NULL, " ")) {
++  while ((p = strsep(, " "))) {
+   if (!strncmp(p, "mech=", strlen("mech=")))
+   mech = p + strlen("mech=");
+   else if (!strncmp(p, "uid=", strlen("uid=")))
+-- 
+2.20.1
+
diff --git 
a/debian/patches/0011-gssd-Duplicate-the-upcall-string-for-error-messages.patch 
b/debian/patches/0011-gssd-Duplicate-the-upcall-string-for-error-messages.patch
new file mode 100644
index 000..fa42430
--- /dev/null
+++ 
b/debian/patches/0011-gssd-Duplicate-the-upcall-string-for-error-messages.patch
@@ -0,0 +1,92 @@
+From: Frank Sorenson 
+Date: Wed, 15 Feb 2017 10:38:53 -0500
+Subject: gssd:  Duplicate the upcall string for error messages
+
+strsep() modifies the input string, so error messages
+may output only part of the upcall string.
+
+Make a copy of the upcall string, and use that in any
+error messages.
+
+Signed-off-by: Frank Sorenson 
+Signed-off-by: Steve Dickson 
+
+Origin: upstream, 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=0a4f5e4
+Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1419280
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895381
+Last-Update: 2019-04-05
+
+---
+ utils/gssd/gssd_proc.c | 17 +
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
+index 30c6aceb..4fc81c30 100644
+--- a/utils/gssd/gssd_proc.c
 b/utils/gssd/gssd_proc.c
+@@ -729,10 +729,17 @@ handle_gssd_upcall(struct clnt_upcall_info *info)
+   char*target = NULL;
+   char*service = NULL;
+   char*enctypes = NULL;
++  char*upcall_str;
+   

Bug#926390: sysvinit-utils: /lib/init/init-d-script always fails when VERBOSE=no

2019-04-06 Thread Dmitry Bogatov


control: severity -1 important

[2019-04-04 12:44] Marc Lehmann 
> Package: sysvinit-utils
> Version: 2.88dsf-59.9
> Severity: normal
>
> Dear Maintainer,
>
> I tried to install the snmpd package, but the post-install script always
> failed because invoke-rc.d snm,pd restart failed.
>
> Surprisingly, running it interactively always worked.
>
> It turned out the problem was /lib/init/init-d-script's jandling of
> VERBOSE, in shoprt, if VERBOSE=no, it always fails.
>
> The reason is that "snmpd restart" falls through to the last case
> statement in init-s-script:
>
>  restart)
>call do_restart
>;;
>...
>exit $? # See https://bugs.debian.org/822753#53
>
> do_restart looks like this:
>
> call do_start_cmd
> case "$?" in
> 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
> 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
> esac
>
> and this always has exit status 1, as do_startr_cmd returns either 0, 1
> or 2, and in all cases, [ no != no ] is false, so the exit status becomes
> false, and thuis the whole init script exit status becomes false.
>
> The end result is that the snmpd package always failed postinstall and
> couldn't be removed either, while it's init-scripot works fine when
> running at the shell, because VERBOSE isn't "no".
>
> If this is a bug in snmpd's init script, could you reassign
> it to the correct package?

Thank you for so in-depth research. I believe this issue is resolved as
side-effect of #427889 in commit 26e498959, included in release 2.94-2.
Can you please try upgrading initscripts to 2.94-2 or applying patch,
included in this mail and see, whether it solves problem?

Non-uninstallable package is bad, very bad. I am afraid, we will need
upload to unstable and unblock from release team.

From 26e4989597d0fca9348443721c512f2b6774971c Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sun, 24 Mar 2019 22:18:22 +
Subject: [PATCH] Make init-d-scripts exit with sensible values (Closes:
 #427889)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

According to Policy=4.3.0.3,

The "init.d" scripts must ensure that they will behave sensibly (i.e.,
returning success and not starting multiple copies of a service) if
invoked with "start" when the service is already running, or with
"stop" when it isn’t, and that they don’t kill unfortunately-named
user processes.

This patch ensures, that exit values, returned by start-stop-daemon(8)
are sensible and propagated correctly into do_{start,stop,restart} functions.

Unfortunately, as resolved in #426877, --oknodo option is opt-in, and
default behaviour of start-stop-daemon is non-sensible with regard of
starting/stopping daemon, already running/stopped.
---
 debian/init-d-script | 38 +++---
 1 file changed, 15 insertions(+), 23 deletions(-)

diff --git a/debian/init-d-script b/debian/init-d-script
index 131dbd65..59ae3221 100755
--- a/debian/init-d-script
+++ b/debian/init-d-script
@@ -43,22 +43,10 @@ call() {
 # Function that starts the daemon/service
 #
 
-# Return
-#   0 if daemon has been started
-#   1 if daemon was already running
-#   2 if daemon could not be started
 do_start_cmd() {
-   start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
-   $START_ARGS \
-   --startas $DAEMON --name $NAME --exec $DAEMON --test > /dev/null \
-   || return 1
-   start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
-   $START_ARGS \
-   --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS \
-   || return 2
-   # Add code here, if necessary, that waits for the process to be ready
-   # to handle requests from services started subsequently which depend
-   # on this one.  As a last resort, sleep for some time.
+   start-stop-daemon --start --quiet --oknodo \
+   ${PIDFILE:+--pidfile ${PIDFILE}} $START_ARGS \
+   --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS
 }
 
 do_start()
@@ -68,12 +56,15 @@ do_start()
fi
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
call do_start_cmd
-   case "$?" in
+   retval=$?
+   case ${retval} in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
if is_call_implemented do_start_cleanup ; then
call do_start_cleanup
+   else
+   return ${retval}
fi
 }
 
@@ -81,11 +72,6 @@ do_start()
 # Function that stops the daemon/service
 #
 
-# Return
-#   0 if daemon has been stopped
-#   1 if daemon was already stopped
-#   2 if daemon could not be stopped
-#   other if a failure occurred
 do_stop_cmd() {
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
$STOP_ARGS \
@@ -114,12 +100,15 @@ 

Bug#575204: initscripts: grep complains about invalid back reference in umountfs

2019-04-06 Thread Dmitry Bogatov


[2019-02-19 04:46] Pierre Ynard 
>
> part   text/plain 571
> > Probably we could just pass -F option to grep?
>
> grep -F would seem a lot safer in many places, yes.

Okay, collegues, what do you think about this patch? It solves problem
at hand, but would introduce another false-positive, if mount options
can look like absolute file path. Can they?

From 16e9c7ba09032523c209aab79b3e3f774ce49a9b Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Fri, 5 Apr 2019 19:18:06 +
Subject: [PATCH] Correctly quote arguments to grep in umountfs script (Closes:
 #575204)

---
 debian/src/initscripts/etc/init.d/umountfs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/src/initscripts/etc/init.d/umountfs 
b/debian/src/initscripts/etc/init.d/umountfs
index b75095ee..633a3f6d 100755
--- a/debian/src/initscripts/etc/init.d/umountfs
+++ b/debian/src/initscripts/etc/init.d/umountfs
@@ -23,7 +23,7 @@ do_stop () {
TMPFS_MTPTS=""
while read -r DEV MTPT FSTYPE REST
do
-   echo "$PROTECTED_MOUNTS" | grep -qs "^$DEV $MTPT " && continue
+   echo "$PROTECTED_MOUNTS" | grep -qsF "$DEV $MTPT " && continue
case "$MTPT" in
  
/|/usr|/proc|/dev|/.dev|/dev/pts|/dev/shm|/dev/.static/dev|/proc/*|/sys|/sys/*|/run|/run/lock|/run/shm|/run/rpc_pipefs|/dev/vcs)
continue
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --



Bug#926546: git-buildpackage: gbp-pq: usage of "rediff" term

2019-04-06 Thread Dmitry Bogatov

Package: git-buildpackage
Version: 0.9.14
Severity: wishlist

Dear Maintainer,

gpb pq --export --commit

creates commit with subject "Rediff patches". Can you please consider
renaming it to "Refresh patches" to be consistent with terminology of
"quilt"?

Sorry about raising such bike-shedding topic, but I believe consistency
is good thing.


pgpuyRSg1XLC0.pgp
Description: PGP signature


Bug#926306: RFS: socklog/2.1.0-9

2019-04-06 Thread Dmitry Bogatov


[2019-04-04 13:30] Mathieu Mirmont 
> > * I know, it is pain, but there should be init.d script. You may want to
> >   take a look at bcron=0.11-8.
>
> Sure, no worries. How about systemd service files? It makes little sense
> to run socklog along with systemd I think, but for the principle it may
> be required to profile service files. What do you think?

Up to you. Presence of systemd unit files is not mandated by Policy,
unlike init.d scripts.

> >   I believe there should be separate sysuser for socklog-* services.
> >   Ideally, separate sysuser for /every/ from socklog-* service, but I do
> >   not know, whehter it is possible.
>
> Yeah good point. I tend to think that a single user for all socklog-*
> services would be enough, but if you prefer I can add one user per
> service.

Yes, I'd prefer as much separation, as possible.

> Thanks for the review!

My pleasure. By the way, you seems to forgot to add changelog entry
about new maintainer. Something in lines:

  * Set myself as maintainer (Closes: #)
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --



Bug#919486: osinfo-db: diff for NMU version 0.20181120-1.1

2019-04-06 Thread Chris Hofstaedtler
Hi Guido,

* Guido  [190406 19:37]:
> On Fri, Apr 05, 2019 at 11:50:54PM +0200, Chris Hofstaedtler wrote:
> > * Guido Günther  [190405 22:04]:
> > > If we had stable links for CD images (3813797) this would be different
> > > but I did not get around to look into this yet so help there would be
> > > appreciated and would make this fixable for real.
> > > 
> > > For now it would be cool if you could cancel the NMU.
> > 
> > Right.
> > Cancelled it :)
> 
> Thanks. I do wonder if that bug has the right severity btw.

Same here. It's certainly not -breaking- anything, so I guess this
could even be wishlist. But it's -your- opinion that matters :)

> I'll keep your patch around to so we can hopefully push this out right
> before the release is made.

I do wonder when would be the right time to do it. At no time before
the actual release the links would work. So from that POV, doing it
now is as good as at any later point in time...

Cheers,
Chris (from the Salzburg BSP)



Bug#926547: insserv: tests/run-tests are not used

2019-04-06 Thread Dmitry Bogatov

Package: insserv
Version: 1.18.0-2
Severity: normal

Dear upstream maintainer,

during preparation of debian package of insserv=1.19.0 I discovered
issue with test suite (tests/run-tests), which was imported from
`debian/run-tests'.

Firstly, this test suite is not run by Makefile:

check: insserv
ifeq ($(ISSUSE),-DSUSE)
issuse=true tests/common
#   issuse=true tests/suse
else
tests/common
endif

If I try to execute them myself, I get following error:

$ tests/run-testsuite
[...]
./tests/run-testsuite: line 982: _order: command not found
error: 88 test executed, 3 fatal tests failed, 1 nonfatal test failed.

Looking up line 982 reveals following:

${severity}_order S mountall needlocal

with `severity' variable is not set anywhere in script. If I set it
myself, like

$ severity=check ./tests/run-testsuite
[...]
error: 244 test executed, 3 fatal tests failed, 3 nonfatal test failed.

I get more sensible output, but still 6 tests are failing.

@Jesse, could you please take a look and maybe cut another upstream
release?


pgpx2XamoicJk.pgp
Description: PGP signature


Bug#926544: startpar: why installed in private directory?

2019-04-06 Thread Dmitry Bogatov

Package: startpar
Version: 0.61-1
Severity: normal
User: kact...@debian.org
Usertags: +objections

Hello!

Why is startpar(8) is installed into private directory? As I checked,
/etc/rc script is fine with startpar(8) in either /lib/startpar or in
$PATH.

Actually, I believe startpar(8) should be startpar(1), since it can
useful to non-privilleged user. (GNU Parallel maybe more powerful, but
still).

So I intend to move startpar(8) into /sbin on 0.62-1 upload. Objections?

@Jesse, could you please consider changing section of manpage to 1?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgp_krpVWPBoD.pgp
Description: PGP signature


Bug#923478: initscripts use unsafe `: >` shell command to create files

2019-04-06 Thread Dmitry Bogatov


[2019-04-05 11:11] Cristian Ionescu-Idbohrn 
> Thing is neither the `:' nor the `true' commands are needed.  To 
> truncate a file it's sufficient to redirect _nothing_ to that file.
>
>$ dash -c '>/tmp/dir/; echo $?; echo hello world;' 
>   dash: 1: cannot create /tmp/dir/: Is a directory
>   2
>   hello world

Nice to know. Is this behaviour mandated by posix? If yes, we could
simplify code futher.

> The real problem is that a failing redirection is _not_ error handled 
> (in the /etc/init.d/bootmisc.sh case).

Sorry, failed to parse. You seems to tell, that there is another problem
in 'bootmisc.sh', but I do not understand, which one.


-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --



Bug#926534: reference to MR

2019-04-06 Thread Christian Ehrhardt
FYI an MR for the issue is open at
https://salsa.debian.org/science-team/aweather/merge_requests/1 now

I built this against the gpsd in experimental and with the change it
worked fine.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd



Bug#926545: startpar: option -v is not present in manual

2019-04-06 Thread Dmitry Bogatov

Package: startpar
Version: 0.61-1
Severity: minor
Tags: +upstream

Manual page startpar(8) does not mention `-v' (version) option, while it
is present

$ /lib/startpar/startpar -v
startpar version 0.61

and actually used in /etc/rc script. Please, either remove or document
it.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpQLUolC_WGK.pgp
Description: PGP signature


Bug#926543: lintian: Deadlock in source-copyright check on source:khronos-opencl-man/1.0~svn33624-4

2019-04-06 Thread Niels Thykier
Niels Thykier:
> Package: lintian
> Version: 2.9.1
> Severity: important
> 
> Hi,
> 
> Discovered in the archive-wide run on lindsay.d.o; lintian does not
> terminate when run on khronos-opencl-man/1.0~svn33624-4 (source).
> 
> Thanks,
> ~Niels
> 

For reference, I used the following command line to confirm it on lindsay:

lintian -EvIL +pedantic -j2 -ddd \
  /srv/mirrors/debian/pool/main/k/khronos-opencl-man/*33624*.{deb,dsc}

I.e. I ran it with source and binaries available (didn't check of the
source alone was enough to trigger the issue..

Thanks,
~Niels



Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10

2019-04-06 Thread Andrei POPESCU
On Sb, 06 apr 19, 10:28:15, Karl O. Pinc wrote:
> C) Actual upgrade instructions.  This is in-progress.
> 
> There are really 2 paths for manual migration of
> interface names: one for when you have console/physical
> access and another when you don't.  In the first case,
> you can try the new names, see what name you get, and
> migrate /etc/.  Without console access you need to
> calculate the new interface name, migrate, and hope
> you got the right name after reboot.  To calculate
> the right interface name you need additional background
> information.  I've whacked up a teeny script, with
> no dependencies, to compute the common case.  But it
> does require the pciid as input, and I suggest installing
> pciutils to get lspci to find pciids.

According to [1] here are two other options:

3. assign own names (e.g. internet0, dmz0, lan0, etc.) by creating a 
.link file in /etc/systemd/network/ and migrate your configuration 
accordingly.

4. disable the naming policy (via kernel parameter or udev) and 
optionally migrate later (e.g. when one has console access to the 
system).

It should be possible to use the kernel parameter in combination with a 
"boot once" grub entry to both get the new name and test the new 
configuration for remote systems.

Wouldn't it make sense to ask also the udev/systemd maintainers for 
input?

[1] 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Bug#926543: lintian: Deadlock in source-copyright check on source:khronos-opencl-man/1.0~svn33624-4

2019-04-06 Thread Niels Thykier
Package: lintian
Version: 2.9.1
Severity: important

Hi,

Discovered in the archive-wide run on lindsay.d.o; lintian does not
terminate when run on khronos-opencl-man/1.0~svn33624-4 (source).

Thanks,
~Niels



Bug#926542: jh_build: randomly fails with DH_OPTIONS="-N..."

2019-04-06 Thread Gilles Filippini
Package: javahelper
Version: 0.72.4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'm experiencing random failures while building hdf5 for unstable using
sbuild. Starting with javahelper 0.72.4, the debian/rules clean target
randomly reports:

make[1]: Leaving directory '/<>/hdf5-1.10.5+repack'
   dh_autoreconf_clean
   jh_clean
Unknown option: l
Unknown option: b
Usage: jh_build [options]

  jh_build is a part of debhelper. See debhelper(7)
  and jh_build(1) for complete usage instructions.

This failure occurs about one time in two.

The clean target doesn't fail despite this error, but subsequent calls to
jh_build fail the very same way, causing hdf5 to FTBS.

This behavior occurs only when I use DH_OPTION="-N..." to skip some binary
packages:

$ DH_OPTIONS="-Nlibhdf5-openmpi-103" jh_clean   
  
Unknown option: l
Unknown option: b
Usage: jh_build [options]

  jh_build is a part of debhelper. See debhelper(7)
  and jh_build(1) for complete usage instructions.

I can somewhat reproduce it on another java packages. For example mac-widgets:
(unstable-amd64-sbuild)/<>/mac-widgets-0.10.0+svn416-dfsg1$ 
DH_OPTIONS="-Nlibmac-widgets-java" jh_clean
Unknown option: l
Unknown option: b
jh_build: warning: ignored unknown options in DH_OPTIONS

But in this case jh_build states it ignores DH_OPTIONS content.

Release 0.72.2 of javahelper is OK.

Thanks,

_g.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlyo7C4ACgkQ7+hsbH/+
z4NjkQgAma6UaCbJ/ab+8HPqUUjG5s2u+iXIqVc1B2W+eB4rRx8adcSIsBWQDc88
q5gcAfcNzxnG0YUZimy8lyrE5yoyUKTe+6B2crhT1z10wkYVCJENkP0BQDgZBkhW
XAVtUVXmwS71tJP/wUh84+F0LSRu3OFtKi92augSfxFZXm90j3uAeh9QBKwYpglg
9Tz9Rrsnjb9yu5W95XyWBRGwoOXUqRuD1mjgsX9TVwpN4jMwfd7dBw5VDIH27JWs
ZYX7K9k9lPOJzyzIYF7kXRMdl/h9YPE1WAQIuxfmfjnvpu1AQDowO8mrya4XhJZO
TxpqaSLhhX2geGeGDr/Fi7Mh9J+UjQ==
=jYwS
-END PGP SIGNATURE-



Bug#926209: RM: python-softlayer -- ROM; Low popcon, no human maintainer

2019-04-06 Thread Scott Kitterman
On Mon, 01 Apr 2019 21:22:14 -0400 Scott Kitterman  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> This package has never been widely used.  I'm no longer a Softlayer 
customer,
> so I can't really maintain it properly anymore.  Given the upstream churn,
> this package isn't really suitable for maintenance by QA upload.

Checking reverse dependencies...
# Broken Build-Depends:
lexicon: python3-softlayer

Dependency problem found.



Bug#926541: src:lexicon: Build-Depends on to be removed package

2019-04-06 Thread Scott Kitterman
Package: src:lexicon
Version: 3.0.8-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

I'm filing this as a FTBFS bug, not because the package FTBFS now, but because
it will once python-softlayer is removed (See #926209).  The package is not
difficult to maintain, but I've given up maintaining it because I'm no longer
using Softlayer (IBM).

Please either add yourself to uploaders for python-softlayer (take over
maintenance) and close #926209 or drop python3-softlayer from lexicon
build-depends closing this bug and I'll proceed with the removal.

Thanks,

Scott K



Bug#919484: many dh_missing warnings

2019-04-06 Thread Guido Günther
Hi,
On Wed, Jan 16, 2019 at 04:51:06PM +0200, Christian Ehrhardt wrote:
> Package: libvirt
> Version: 5.0.0-1
> Severity: low
> 
> Hi,
> I was checking libvirt 5.0 - thanks for the fast upload btw!
> 
> We had for quite a while some entries in dh_missing.
> Some are clear like the docs.
> 
> But I wondered if we would want to add some of them e.g.:
> - the storage-backend .la file

I don't think we need to ship any la files.

> - the sysctl conf

This should at least go into examples/ somewhere.

> - logrotate files (I didn't see them in logrotate itself)

We're shipping some of the listed ones already:

-rw-r--r-- root/root   165 2019-03-28 13:03 ./etc/logrotate.d/libvirtd
-rw-r--r-- root/root   143 2019-03-28 13:03 ./etc/logrotate.d/libvirtd.libxl
-rw-r--r-- root/root   141 2019-03-28 13:03 ./etc/logrotate.d/libvirtd.lxc
-rw-r--r-- root/root   142 2019-03-28 13:03 ./etc/logrotate.d/libvirtd.qemu

however it surely wouldn't hurt to ship the ones for the other daemons
as well. Also we're missing some manpages (virkeycode*/virkeyname*)

Thanks a lot for going through the buglist!
 -- Guido



> 
> Kind regards,
> Christian



Bug#919486: osinfo-db: diff for NMU version 0.20181120-1.1

2019-04-06 Thread Guido
Hi Chris,
On Fri, Apr 05, 2019 at 11:50:54PM +0200, Chris Hofstaedtler wrote:
> Control: tags 919486 - pending
> 
> Hi,
> 
> * Guido Günther  [190405 22:04]:
> > If we had stable links for CD images (3813797) this would be different
> > but I did not get around to look into this yet so help there would be
> > appreciated and would make this fixable for real.
> > 
> > For now it would be cool if you could cancel the NMU.
> 
> Right.
> Cancelled it :)

Thanks. I do wonder if that bug has the right severity btw.

I'll keep your patch around to so we can hopefully push this out right
before the release is made.

Cheers,
 -- Guido

> 
> Cheers,
> Chris
>  
> 



Bug#926540: unblock: xorg-server/2:1.20.4-1

2019-04-06 Thread Andreas Boll
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package xorg-server:

This stable release fixes a bunch of important issues including
xserver crashes. There are multiple fixes related to xwayland, present
and modesetting.

Debian changelog entry:
xorg-server (2:1.20.4-1) unstable; urgency=medium

  [ Timo Aaltonen ]
  * New upstream release.
- present/wnmd: Fix use after free on CRTC removal
  (Closes: #920665).
- xwayland: Replace xwl_window::present_window with
  ::present_flipped (Closes: #921734).

  [ Andreas Boll ]
  * Refresh 07_use-modesetting-driver-by-default-on-GeForce.diff.

 -- Andreas Boll   Tue, 05 Mar 2019 21:11:12 +0100


Further I've attached a git-diff with the following command to exclude
uninteresting CI stuff and tests to make the diff more readable:

git diff xorg-server-2_1.20.3-1..xorg-server-2_1.20.4-1 -- . ':(exclude)test' 
':(exclude).gitlab-ci*' ':(exclude).travis.yml' > ../xorg-server_1.20.4-1.diff

I've also attached the output of git-shortlog to list all commit
titles.

unblock xorg-server/2:1.20.4-1

Thanks,
Andreas
diff --git a/Makefile.am b/Makefile.am
index 32d4d21e76..19511f765d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -72,7 +72,7 @@ pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = xorg-server.pc
 endif
 
-EXTRA_DIST = xorg-server.pc.in xorg-server.m4 autogen.sh
+EXTRA_DIST = xorg-server.pc.in xorg-server.m4 autogen.sh README.md
 
 DISTCHECK_CONFIGURE_FLAGS=\
 	--with-xkb-path=$(XKB_BASE_DIRECTORY) \
diff --git a/README b/README.md
similarity index 65%
rename from README
rename to README.md
index 529526d189..bc39f41cd4 100644
--- a/README
+++ b/README.md
@@ -1,4 +1,5 @@
-	X Server
+X Server
+
 
 The X server accepts requests from client applications to create windows,
 which are (normally rectangular) "virtual screens" that the client program
@@ -16,29 +17,19 @@ https://en.wikipedia.org/wiki/X_server
 All questions regarding this software should be directed at the
 Xorg mailing list:
 
-https://lists.freedesktop.org/mailman/listinfo/xorg
-
-Please submit bug reports to the Xorg bugzilla:
-
-https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
+  https://lists.freedesktop.org/mailman/listinfo/xorg
 
 The master development code repository can be found at:
 
-git://anongit.freedesktop.org/git/xorg/xserver
-
-https://cgit.freedesktop.org/xorg/xserver
+  https://gitlab.freedesktop.org/xorg/xserver
 
 For patch submission instructions, see:
 
-	https://www.x.org/wiki/Development/Documentation/SubmittingPatches
-
-For more information on the git code manager, see:
-
-https://wiki.x.org/wiki/GitPage
+  https://www.x.org/wiki/Development/Documentation/SubmittingPatches
 
 As with other projects hosted on freedesktop.org, X.Org follows its
 Code of Conduct, based on the Contributor Covenant. Please conduct
 yourself in a respectful and civilized manner when using the above
 mailing lists, bug trackers, etc:
 
-	https://www.freedesktop.org/wiki/CodeOfConduct
+  https://www.freedesktop.org/wiki/CodeOfConduct
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
index d0be701352..1926762add 100644
--- a/Xi/xibarriers.c
+++ b/Xi/xibarriers.c
@@ -611,7 +611,9 @@ CreatePointerBarrierClient(ClientPtr client,
 }
 pbd->deviceid = dev->id;
 
+input_lock();
 xorg_list_add(>entry, >per_device);
+input_unlock();
 }
 
 ret->id = stuff->barrier;
@@ -626,7 +628,9 @@ CreatePointerBarrierClient(ClientPtr client,
 ret->barrier.directions &= ~(BarrierPositiveX | BarrierNegativeX);
 if (barrier_is_vertical(>barrier))
 ret->barrier.directions &= ~(BarrierPositiveY | BarrierNegativeY);
+input_lock();
 xorg_list_add(>entry, >barriers);
+input_unlock();
 
 *client_out = ret;
 return Success;
@@ -689,7 +693,9 @@ BarrierFreeBarrier(void *data, XID id)
 mieqEnqueue(dev, (InternalEvent *) );
 }
 
+input_lock();
 xorg_list_del(>entry);
+input_unlock();
 
 FreePointerBarrierClient(c);
 return Success;
@@ -709,7 +715,9 @@ static void add_master_func(void *res, XID id, void *devid)
 pbd = AllocBarrierDevice();
 pbd->deviceid = *deviceid;
 
+input_lock();
 xorg_list_add(>entry, >per_device);
+input_unlock();
 }
 
 static void remove_master_func(void *res, XID id, void *devid)
@@ -752,7 +760,9 @@ static void remove_master_func(void *res, XID id, void *devid)
 mieqEnqueue(dev, (InternalEvent *) );
 }
 
+input_lock();
 xorg_list_del(>entry);
+input_unlock();
 free(pbd);
 }
 
diff --git a/configure.ac b/configure.ac
index 80f0ce7853..30544218a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,9 +26,9 @@ dnl
 dnl Process this file with autoconf to create configure.
 
 AC_PREREQ(2.60)
-AC_INIT([xorg-server], 1.20.3, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], xorg-server)

Bug#923851: RFP: ghidra -- Ghidra is a software reverse engineering framework

2019-04-06 Thread Antonio Ospite
On Thu, 21 Mar 2019 11:22:28 +0800
Yangfl  wrote:

> I'm willing to package it, as long as they publish its source!
> 

The source code is public now:
https://github.com/NationalSecurityAgency/ghidra

No idea if it there has been any auditing yet tho.

Ciao,
   Antonio

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

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



Bug#926539: rootskel: steal-ctty no longer works on at least sparc64

2019-04-06 Thread John Paul Adrian Glaubitz
Source: rootskel
Version: 1.128
Severity: important
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

I built updated installation images [1] for Debian Ports today and tested
the sparc64 image on our SPARC T5 in an LDOM.

Unfortunately, it seems that the recent changes to rootskel broke the
serial console on sparc64 in d-i. The kernel boots fine but d-i never
starts, the boot stops with:

steal-ctty: No such file or directory

My suspicion is that the support multiple consoles in parallel [2] introduced
this particular regression. I haven't done any debugging yet though as I'm
not sure where to start, I haven't touched the rootskel package before and
therefore would be interested in any pointers how to debug this.

Thanks,
Adrian

> [1] https://cdimage.debian.org/cdimage/ports/2019-04-06/
> [2] 
> https://salsa.debian.org/installer-team/rootskel/commit/b6048aafed7d73ba42da04d6f7a798710f271384

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



Bug#926538: Package: installation-reports

2019-04-06 Thread Paul Sutton
Package: installation-reports Installer

Hi

I was advised to make a report of this by the debian-users mailing list
and directed to. 

https://www.debian.org/devel/debian-installer/errata

I am installing to a HP mini 10 netbook,  the install seems to have gone
very well.  My report is more of an issue with what is displayed during
the install process:

Package: installation-reports

Boot method: 
USB Flash disk - to create disk I used dd to transfer iso file to disk

dd if=firmware-buster-DI-alpha1-amd64-DVD-1.iso of=/dev/sdf status=progress


Image version: 
Date: 
6/4/2019,  15:30 pm (approx)

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/buster_di_alpha1+nonfree/amd64/iso-dvd/
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/buster_di_alpha1+nonfree/amd64/iso-dvd/firmware-buster-DI-alpha1-amd64-DVD-1.iso
 Machine: 

Processor: Intel Atom CPU N455 1.66 GHZ
 Memory: 1gb
Partitions: 

Output of lspci -knn (or lspci -nn):

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

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

Comments/Problems:




Issue 1
Shows Debian 9 on graphical installer screens. (Screen shot, taken
during install process attached)

Issue 2 more of a question.  When taking screen shots,  during install
process. These are saved to /var/log/installer,  this is fine but
permissions are not set up for normal users to copy over to a usb flash
disk,  which I needed to do, as I am using my main PC to send this
report.  is there a reason for this or could permissions allow files to
be copied by any user on the system.  

Permissions are -rw--- root root


Hope this helps


Paul Sutton

-- Paul Sutton http://www.zleap.net https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893 1E16 F086 5537 D066 302D

-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D



Bug#926537: jabref: depends on unirest-java

2019-04-06 Thread tony mancill
Package: jabref
Version: 3.8.2+ds-12
Severity: wishlist

jabref depends on unirest-java, which has to be patched to use a DFSG
JSON implementation.  Since upstream has declined to migrate to openjson
[1], it seems better in the long run to patch jabref to use something
other than unirest-java.

We can target this for buster+1.

Thanks,
tony

[1] https://github.com/Kong/unirest-java/issues/176#issuecomment-475456557


signature.asc
Description: PGP signature


Bug#926536: RM: pork -- RoQA; package is orphaned since > 1600days, popcon is 29, package has some long lasting open bugs, last upstream release was 2004

2019-04-06 Thread Stefan Schörghofer
Package: ftp.debian.org
Severity: normal

Hello,

Please consider removing the package pork due to the following reasons:
 - the package is orphaned since > 1600days
 - popcon is 29
 - package has some long lasting open bugs
 - last upstream release was 2004
 - many maintained modern alternatives are available

Thanks
best regards,
Stefan



Bug#926379: golang-github-hashicorp-go-cleanhttp: diff for NMU version 0.5.0-1.1

2019-04-06 Thread zeha
Control: tags 926379 + patch
Control: tags 926379 + pending

Dear maintainer,

I've prepared an NMU for golang-github-hashicorp-go-cleanhttp (versioned as 
0.5.0-1.1) and
uploaded it, as well as opened an MR on salsa.d.o.

Cheers,
Chris

diff -Nru golang-github-hashicorp-go-cleanhttp-0.5.0/debian/changelog 
golang-github-hashicorp-go-cleanhttp-0.5.0/debian/changelog
--- golang-github-hashicorp-go-cleanhttp-0.5.0/debian/changelog 2019-01-01 
06:25:09.0 +
+++ golang-github-hashicorp-go-cleanhttp-0.5.0/debian/changelog 2019-04-06 
16:24:28.0 +
@@ -1,3 +1,11 @@
+golang-github-hashicorp-go-cleanhttp (0.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from upstream to fix FTBFS with Go 1.11.6.
+(Closes: #926379)
+
+ -- Chris Hofstaedtler   Sat, 06 Apr 2019 16:24:28 +
+
 golang-github-hashicorp-go-cleanhttp (0.5.0-1) unstable; urgency=medium
 
   * New upstream version 0.5.0
diff -Nru 
golang-github-hashicorp-go-cleanhttp-0.5.0/debian/patches/d3fcbee8e1810ecee4bdbf415f42f84cfd0e3361.patch
 
golang-github-hashicorp-go-cleanhttp-0.5.0/debian/patches/d3fcbee8e1810ecee4bdbf415f42f84cfd0e3361.patch
--- 
golang-github-hashicorp-go-cleanhttp-0.5.0/debian/patches/d3fcbee8e1810ecee4bdbf415f42f84cfd0e3361.patch
1970-01-01 00:00:00.0 +
+++ 
golang-github-hashicorp-go-cleanhttp-0.5.0/debian/patches/d3fcbee8e1810ecee4bdbf415f42f84cfd0e3361.patch
2019-04-06 16:24:02.0 +
@@ -0,0 +1,41 @@
+From d3fcbee8e1810ecee4bdbf415f42f84cfd0e3361 Mon Sep 17 00:00:00 2001
+From: Jeff Mitchell 
+Date: Sat, 6 Apr 2019 12:20:18 -0400
+Subject: [PATCH] Fix tests against newer Go
+
+Fixes #14
+---
+ handlers_test.go | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/handlers_test.go b/handlers_test.go
+index 95ef812..a22e84a 100644
+--- a/handlers_test.go
 b/handlers_test.go
+@@ -30,22 +30,22 @@ func TestPrintablePathCheckHandler(t *testing.T) {
+   },
+ 
+   "invalid newline": {
+-  path:   "/invalid\n",
++  path:   "/invalid%0A",
+   expectCode: http.StatusBadRequest,
+   },
+ 
+   "invalid carriage return": {
+-  path:   "/invalid\r",
++  path:   "/invalid%0D",
+   expectCode: http.StatusBadRequest,
+   },
+ 
+   "invalid null": {
+-  path:   "/invalid\x00",
++  path:   "/invalid%00",
+   expectCode: http.StatusBadRequest,
+   },
+ 
+   "invalid alternate status": {
+-  path:   "/invalid\n",
++  path:   "/invalid%0A",
+   expectCode: http.StatusInternalServerError,
+   input: {
+   ErrStatus: http.StatusInternalServerError,
diff -Nru golang-github-hashicorp-go-cleanhttp-0.5.0/debian/patches/series 
golang-github-hashicorp-go-cleanhttp-0.5.0/debian/patches/series
--- golang-github-hashicorp-go-cleanhttp-0.5.0/debian/patches/series
1970-01-01 00:00:00.0 +
+++ golang-github-hashicorp-go-cleanhttp-0.5.0/debian/patches/series
2019-04-06 16:24:05.0 +
@@ -0,0 +1 @@
+d3fcbee8e1810ecee4bdbf415f42f84cfd0e3361.patch



Bug#926535: gnu-efi: Please enable ia64 architecture in debian/control

2019-04-06 Thread John Paul Adrian Glaubitz
Source: gnu-efi
Version: 3.0.9-1
Severity: normal
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

gnu-efi builds fine on ia64 and is actually required to build elilo
which is currently required for booting Linux although we're working
on switching ia64 over to GRUB.

For the time being, could you (re-)add ia64 to the Architecture field
for the gnu-efi binary package in debian/control? I have already built
gnu-efi manually and uploaded it to the ports mirror.

Thanks,
Adrian

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



Bug#924840: highwayhash: FTBFS: dh_makeshlibs: failing due to earlier errors

2019-04-06 Thread Tobias Frost
Control: tags -1 unreproducible moreinfo
Control: severity -1 important

Hi Lucas,

I've tried to reproduce this on a new buster pbuilder environment and
it builds fine here. Can you retry if you still see this issue?

Cheers from the Salzburg BSP,
tobi



Bug#926533: linux-image-armmp-lpae: Fail to mount cryptsetup device: missing aes-xts-plain64 cipher

2019-04-06 Thread Lars Kruse
Package: linux-image-armmp-lpae
Version: 4.19+104
Severity: normal

Dear Maintainer,

after upgrading from 4.9.144-3 to 4.19+104 I am not able to mount
cryptsetup devices anymore.

  # cryptsetup luksOpen /dev/lvm-foo/crypto foo
  Enter passphrase for /dev/lvm-foo/crypto: 
  device-mapper: reload ioctl on   failed: No such file or directory
  Failed to setup dm-crypt key mapping for device /dev/lvm-foo/crypto.
  Check that kernel supports aes-xts-plain64 cipher (check syslog for more
  info).
  device-mapper: remove ioctl on temporary-cryptsetup-3150  failed: No
  such device or address
  device-mapper: table ioctl on   failed: No such device or address


The output of dmesg is:
  device-mapper: table: 253:8: crypt: Error allocating crypto tfm
  device-mapper: ioctl: error adding target to table


The respective LUKS header of the cryptsetup device looks like this:

  # cryptsetup luksDump /dev/lvm-foo/crypto 
  LUKS header information for /dev/lvm-foo/crypto
  Version:1
  Cipher name:aes
  Cipher mode:xts-plain64
  Hash spec:  sha1
  Payload offset: 4096
  MK bits:256
  ...


Maybe the lack of the "aes-xts-plain64" cipher is related to the following?

  # dpkg -L linux-image-4.9.0-8-armmp-lpae | grep aes
  /lib/modules/4.9.0-8-armmp-lpae/kernel/drivers/crypto/omap-aes.ko
  # dpkg -L linux-image-4.19.0-4-armmp-lpae | grep aes
  [no output]


I am using a BananaPi M1 board.

Thank you for your time!

Cheers,
Lars



Bug#926534: libgps changed API of gps_read

2019-04-06 Thread Christian Ehrhardt
Package: aweather
Version: 0.8.1-1

Hi,
libgps changed the gps_read implementation in [0].
To be clear the change in gpsd is currently only in experimental. This
is a heads up for the post buster transition that will come sooner or
later.

Upstream aweather [1] seems to be rather static or dead. At least
there is no way to report the issue there as [2] is down.

The change isn't too hard and will be compatible with older versions
of gpsd. Therefore I'd appreciate if you could include this change in
when-/whatever the next upload to aweather will happen. I'll let the
gpsd maintainer know about the bug, so that we can consider it when
kicking off the transition.

I'll submit a salsa MP once I have the bug number to reference it.

OTOH - this package wasn't touched in quite some time, upstream seems
dead as well and popcon [3] (if you trust the data) is rather low - so
removal might be an option as well?.


[0]: https://git.savannah.gnu.org/cgit/gpsd.git/commit/?id=6bba8b329
[1]: http://pileus.org/aweather/development
[2]: http://pileus.org/dev/projects/aweather/issues
[3]: https://qa.debian.org/popcon.php?package=aweather

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd



Bug#916145: closure-compiler: Not working with recent JS code

2019-04-06 Thread Chris Hofstaedtler
* Roland Gruber  [190406 16:07]:
> the current version is so old that it got incompatible with recent JS code.
> E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors.
> 
> Please either update the tool or remove it from the archive. This is now
> 5 years in unmaintained state.

I've checked all r-deps of closure-compiler in Debian, and they all
build -- datatables-extensions shows some errors in a prebuilt file,
but it has done so for a long time, so probably not super relevant.

While I agree that having a 5 year old JS compiler in Debian is not
a great situation, its also not threatening to the packages in
Debian using it, so I'd suggest keeping it for now.
Adrian: you raised the severity, care to lower it until buster is
out (or say some words on why)?

Cheers,
Chris (from the Salzburg BSP)



Bug#854743: golang-github-mailru-easyjson: diff for NMU version 0.0~git20161103.0.159cdb8-1.1

2019-04-06 Thread Tobias Frost
Control: tags 854743 + pending

Dear maintainer,

I've prepared an NMU for golang-github-mailru-easyjson (versioned as 
0.0~git20161103.0.159cdb8-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/changelog golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/changelog
--- golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/changelog	2016-11-29 04:11:38.0 +0100
+++ golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/changelog	2019-04-06 17:50:08.0 +0200
@@ -1,3 +1,11 @@
+golang-github-mailru-easyjson (0.0~git20161103.0.159cdb8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS (32-bit): constant 4294967295 overflows int" with patch from
+BTS, thanks to Ritesh Raj Sarraf for providing it. (Closes: #854743)
+
+ -- Tobias Frost   Sat, 06 Apr 2019 17:50:08 +0200
+
 golang-github-mailru-easyjson (0.0~git20161103.0.159cdb8-1) unstable; urgency=medium
 
   * Initial release (Closes: #853811)
diff -Nru golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/patches/fix-ftbfs-32bit-archs.patch golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/patches/fix-ftbfs-32bit-archs.patch
--- golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/patches/fix-ftbfs-32bit-archs.patch	1970-01-01 01:00:00.0 +0100
+++ golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/patches/fix-ftbfs-32bit-archs.patch	2019-04-06 17:50:08.0 +0200
@@ -0,0 +1,63 @@
+Fix picked from: https://github.com/mailru/easyjson/pull/150/files
+Index: golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/benchmark/data.go
+===
+--- golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8.orig/benchmark/data.go
 golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/benchmark/data.go
+@@ -25,12 +25,12 @@ var smallStructData = Entities{
+ type SearchMetadata struct {
+ 	CompletedIn float64 `json:"completed_in"`
+ 	Count   int `json:"count"`
+-	MaxID   int `json:"max_id"`
++	MaxID   int64   `json:"max_id"`
+ 	MaxIDStrstring  `json:"max_id_str"`
+ 	NextResults string  `json:"next_results"`
+ 	Query   string  `json:"query"`
+ 	RefreshURL  string  `json:"refresh_url"`
+-	SinceID int `json:"since_id"`
++	SinceID int64   `json:"since_id"`
+ 	SinceIDStr  string  `json:"since_id_str"`
+ }
+ 
+Index: golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/tests/data.go
+===
+--- golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8.orig/tests/data.go
 golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/tests/data.go
+@@ -88,10 +88,10 @@ var primitiveTypesString = "{" +
+ 	`"Int32":` + fmt.Sprint(math.MinInt32) + `,` +
+ 	`"Int64":` + fmt.Sprint(int64(math.MinInt64)) + `,` +
+ 
+-	`"Uint":` + fmt.Sprint(math.MaxUint32) + `,` +
++	`"Uint":` + fmt.Sprint(uint32(math.MaxUint32)) + `,` +
+ 	`"Uint8":` + fmt.Sprint(math.MaxUint8) + `,` +
+ 	`"Uint16":` + fmt.Sprint(math.MaxUint16) + `,` +
+-	`"Uint32":` + fmt.Sprint(math.MaxUint32) + `,` +
++	`"Uint32":` + fmt.Sprint(uint32(math.MaxUint32)) + `,` +
+ 	`"Uint64":` + fmt.Sprint(uint64(math.MaxUint64)) + `,` +
+ 
+ 	`"IntString":"` + fmt.Sprint(math.MinInt32) + `",` +
+@@ -100,10 +100,10 @@ var primitiveTypesString = "{" +
+ 	`"Int32String":"` + fmt.Sprint(math.MinInt32) + `",` +
+ 	`"Int64String":"` + fmt.Sprint(int64(math.MinInt64)) + `",` +
+ 
+-	`"UintString":"` + fmt.Sprint(math.MaxUint32) + `",` +
++	`"UintString":"` + fmt.Sprint(uint32(math.MaxUint32)) + `",` +
+ 	`"Uint8String":"` + fmt.Sprint(math.MaxUint8) + `",` +
+ 	`"Uint16String":"` + fmt.Sprint(math.MaxUint16) + `",` +
+-	`"Uint32String":"` + fmt.Sprint(math.MaxUint32) + `",` +
++	`"Uint32String":"` + fmt.Sprint(uint32(math.MaxUint32)) + `",` +
+ 	`"Uint64String":"` + fmt.Sprint(uint64(math.MaxUint64)) + `",` +
+ 
+ 	`"Float32":` + fmt.Sprint(1.5) + `,` +
+@@ -191,10 +191,10 @@ var namedPrimitiveTypesString = "{" +
+ 	`"Int32":` + fmt.Sprint(math.MinInt32) + `,` +
+ 	`"Int64":` + fmt.Sprint(int64(math.MinInt64)) + `,` +
+ 
+-	`"Uint":` + fmt.Sprint(math.MaxUint32) + `,` +
++	`"Uint":` + fmt.Sprint(uint32(math.MaxUint32)) + `,` +
+ 	`"Uint8":` + fmt.Sprint(math.MaxUint8) + `,` +
+ 	`"Uint16":` + fmt.Sprint(math.MaxUint16) + `,` +
+-	`"Uint32":` + fmt.Sprint(math.MaxUint32) + `,` +
++	`"Uint32":` + fmt.Sprint(uint32(math.MaxUint32)) + `,` +
+ 	`"Uint64":` + fmt.Sprint(uint64(math.MaxUint64)) + `,` +
+ 
+ 	`"Float32":` + fmt.Sprint(1.5) + `,` +
diff -Nru golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/patches/series golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/patches/series
--- golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/debian/patches/series	2016-11-29 04:11:38.0 +0100
+++ 

Bug#926532: poppler: CVE-2019-10873

2019-04-06 Thread Salvatore Bonaccorso
Source: poppler
Version: 0.71.0-3
Severity: important
Tags: patch security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/748

Hi,

The following vulnerability was published for poppler.

CVE-2019-10873[0]:
| An issue was discovered in Poppler 0.74.0. There is a NULL pointer
| dereference in the function SplashClip::clipAALine at
| splash/SplashClip.cc.


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-10873
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10873
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/748
[2] 
https://gitlab.freedesktop.org/poppler/poppler/commit/8dbe2e6c480405dab9347075cf4be626f90f1d05

Please adjust the affected versions in the BTS as needed, the issue
possibly got introduced only in 0.70, but needs to be checked.

Regards,
Salvatore



Bug#926530: poppler: CVE-2019-10872

2019-04-06 Thread Salvatore Bonaccorso
Source: poppler
Version: 0.71.0-3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/750
Control: found -1 0.48.0-1
Control: found -1 0.48.0-2+deb9u2

Hi,

The following vulnerability was published for poppler.

CVE-2019-10872[0]:
| An issue was discovered in Poppler 0.74.0. There is a heap-based
| buffer over-read in the function Splash::blitTransparent at
| splash/Splash.cc.


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-10872
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10872
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/750
[2] https://bugzilla.novell.com/show_bug.cgi?id=1131722

Regards,
Salvatore



Bug#926531: RM: qtsmbstatus -- RoQA; package orphaned since ~ 2600days, popcon is < 25 for all binary packages related, last upstream aktivity was 3 years ago

2019-04-06 Thread Stefan Schörghofer
Package: ftp.debian.org
Severity: normal

Hello,

Please consider removing the package qtsmbstatus due to the following
reasons:
 - package orphaned since ~ 2600days
 - popcon is < 25 for all binary packages related
 - last upstream aktivity was 3 years ago

Thank you
best regards,
Stefan



Bug#926529: poppler: CVE-2019-10871

2019-04-06 Thread Salvatore Bonaccorso
Source: poppler
Version: 0.71.0-3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/751
Control: found -1 0.48.0-2+deb9u2
Control: found -1 0.48.0-1

Hi,

The following vulnerability was published for poppler.

CVE-2019-10871[0]:
| An issue was discovered in Poppler 0.74.0. There is a heap-based
| buffer over-read in the function PSOutputDev::checkPageSlice at
| PSOutputDev.cc.


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-10871
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10871
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/751
[2] https://bugzilla.novell.com/show_bug.cgi?id=1131696

Regards,
Salvatore



Bug#826556: please give possibility to not file bootstrapped file as ~/.mrconfig

2019-04-06 Thread Antonio Ospite
On Mon, 06 Jun 2016 13:23:08 +0200
Marc Haber  wrote:

> Package: myrepos
> Version: 1.20160123
> Severity: wishlist
> 
> Hi,
>

Hi Marc,

just commenting as I too noticed the same issue.

> when I use mr bootstrap to fetch the initial mr configuration, the
> downloaded file is put in the local file system as ~/.mrconfig. This
> prevents the actual repositories to have a ~/.mrconfig themselves (mr
> refuses to overwrite untracked files), which results in ~/.mrconfig to
> not be under version control on the actual client.
> 
> Additionally, the bootstrapped file needs to be the final .mrconfig
> that is being used in every day use, which causes synchonization
> efforts to keep the .mrconfig and other mr configuration (which is
> likely to come from a vcsh repo) in sync. And, the bootstrapped
> .mrconfig file is likely to need --untrusted since it will most
> probably contain include statements, for example.
>

FWIW the vcsh case can be handled with a pre-merge hook:
https://github.com/RichiH/vcsh/issues/190

> mr bootstrap seems to be a rarely used feature (I wasn't able to get a
> reply to some of my questions on mailing list and IRC channel), so it
> might not be a big issue to change mr bootstrap's behevior in this
> regard. For example. mr could be changed to read an .mrbootstrap
> config file iff .mrconfig does not exist, and mr bootstrap could
> downlaod to .mrbootstrap instead of .mrconfig.
>

Downloading the bootstrap file to a temporary location could also work.

Ciao,
   Antonio

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

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



Bug#926261: closed by Ben Hutchings (Re: Bug#926261: linux-image-4.19.0-4-amd64: fan continiously spinning above 6900 RPM after resume on lenovo carbon x1 thinkpad with isa adap

2019-04-06 Thread Karol Szkudlarek
Thank you, Bjørn. This regression bug is annoying, it happens at least once per 
day. I think that Debian instead of hiding/closing such bug will be push more 
on upstream or try fix by themselves if Debian developers will be Lenovo 
Thinkpad Carbon X1 owners. :)


Karol

‐‐‐ Original Message ‐‐‐
On Thursday, 4 April 2019 14:29, Bjørn Mork  wrote:

> Not going to argue against this being a firmware bug. I'm sure that is
> true. But Linux must deal with buggy firmware. Else it cannot run on
> any real system :-)
>
> And this bug (or at least the bad effect on Linux) is a regression
> introduced by commit c3a696b6e8f8 ("ACPI / EC: Use busy polling mode
> when GPE is not enabled"), which again was an attempt to work around
> firmware bugs in other systems.
>
> This has been reported upstream, but AFAICS it is still only partially
> fixed. Ref the thread ending here:
> https://spinics.net/lists/stable/msg214463.html
>
> Bjørn



Bug#926528: libgps changed API of gps_read

2019-04-06 Thread Christian Ehrhardt
Package: collectd
Version: 5.8.1-1.2

Hi,
libgps changed the gps_read implementation in [0].
To be clear the change in gpsd is currently only in experimental. This
is a heads up for the post buster transition that will come sooner or
later.

Upstream collectd already implemented the change necessary in [1].
So far collectd has had no release that includes this, but due to being
dependent on the GPSD_API_MAJOR_VERSION this can be applied at any
time and will make it (re)build correctly once the new gpsd version
will start the transition.

Therefore I'd appreciate if you could include this change in
when-/whatever the next upload to collectd will happen. I'll let the gpsd
maintainer know about the bug, so that we can consider it when kicking
off the transition.

[0]: https://git.savannah.gnu.org/cgit/gpsd.git/commit/?id=6bba8b329
[1]: 
https://github.com/collectd/collectd/commit/991a6d3fd38c2435d94de3853fda36b3330cf6ab

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd



  1   2   >