Bug#845034: marked as done (initramfs-tools: please ensure initrd images are reproducible)

[Trent W. Buck]

Debian Bug Tracking System wrote:
> + LC_ALL=C sort
> [and similar LC_ALL=C elsewhere]

I think you can dial that back from LC_ALL=C to just LC_COLLATE=C.

Informal proof:

bash4$ printf %s\\n README ReadMe readme | LC_COLLATE=en_AU.UTF-8 sort
readme
ReadMe
README

bash4$ printf %s\\n README ReadMe readme | LC_COLLATE=C sort
README
ReadMe
readme

bash4$ printf %s\\n README ReadMe readme | LC_ALL=C sort
README
ReadMe
readme

Bug#879752: http://qe-forge.org is down

[Andrius Merkys]

Hello,

http://qe-forge.org seems to be down. Download page of QE [1] directs to GitHub 
and GitLab-hosted GIT repositories. So debian/watch should point to either one 
of them, preferably, IMO, the GitLab one.

Andrius

[1] http://www.quantum-espresso.org/download

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#903979: Parse::Yapp non-deterministic output problem solved

[Andrius Merkys]

On 07/18/2018 06:11 PM, gregor herrmann wrote:
> No problem; and: you're part of the collective maintainer called
> Debian Perl Group :)

True indeed :)

> Done, and a few notes added to d/changelog, as usual.

Great, I will work on them.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania




signature.asc
Description: OpenPGP digital signature

Bug#904068: Dependency on php-curl is missing

[Kubo Hiroshi]

Package: composer
Source: composer
Version: 1.2.2-1
Severity: normal

When I ran the sub-command create-project of the composer,
an error occured because the PHP curl module was missed.

Because the PHP curl module is provided by the package php-curl,
I guess the composer package needs additional dependency on php-curl.

Indeed, the error can be recovered by installing php-curl package
manually.

The attached files:

 * Output of composer create-project ended with error.


---
Kubo Hiroshi 
 composer create-project drupal-composer/drupal-project drupal_composer_trial1 
--stability dev
Installing drupal-composer/drupal-project (8.x-dev 
24f29be11ebcb2c2e610dcfd348b61e15f0d6d91)
  - Installing drupal-composer/drupal-project (8.x-dev 24f29be)
Cloning 24f29be11ebcb2c2e610dcfd348b61e15f0d6d91 from cache

Created project in drupal_composer_trial1
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
- webflo/drupal-core-require-dev 8.5.3 requires behat/mink-selenium2-driver 
1.3.x-dev -> satisfiable by behat/mink-selenium2-driver[1.3.x-dev].
- webflo/drupal-core-require-dev 8.5.4 requires behat/mink-selenium2-driver 
1.3.x-dev -> satisfiable by behat/mink-selenium2-driver[1.3.x-dev].
- webflo/drupal-core-require-dev 8.5.5 requires behat/mink-selenium2-driver 
1.3.x-dev -> satisfiable by behat/mink-selenium2-driver[1.3.x-dev].
- webflo/drupal-core-require-dev 8.5.x-dev requires 
behat/mink-selenium2-driver 1.3.x-dev -> satisfiable by 
behat/mink-selenium2-driver[1.3.x-dev].
- behat/mink-selenium2-driver 1.3.x-dev requires instaclick/php-webdriver 
~1.1 -> satisfiable by instaclick/php-webdriver[1.1, 1.1.1, 1.2, 1.2.1, 1.2.2, 
1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5].
- instaclick/php-webdriver 1.4.5 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.4.4 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.4.3 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.4.2 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.4.1 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.4.0 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.3.0 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.2.2 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.2.1 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.2 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.1.1 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- instaclick/php-webdriver 1.1 requires ext-curl * -> the requested PHP 
extension curl is missing from your system.
- Installation request for webflo/drupal-core-require-dev ~8.5.3 -> 
satisfiable by webflo/drupal-core-require-dev[8.5.3, 8.5.4, 8.5.5, 8.5.x-dev].

  To enable extensions, verify that they are enabled in those .ini files:
- /etc/php/7.0/cli/php.ini
- /etc/php/7.0/cli/conf.d/10-opcache.ini
- /etc/php/7.0/cli/conf.d/10-pdo.ini
- /etc/php/7.0/cli/conf.d/15-xml.ini
- /etc/php/7.0/cli/conf.d/20-calendar.ini
- /etc/php/7.0/cli/conf.d/20-ctype.ini
- /etc/php/7.0/cli/conf.d/20-dom.ini
- /etc/php/7.0/cli/conf.d/20-exif.ini
- /etc/php/7.0/cli/conf.d/20-fileinfo.ini
- /etc/php/7.0/cli/conf.d/20-ftp.ini
- /etc/php/7.0/cli/conf.d/20-gd.ini
- /etc/php/7.0/cli/conf.d/20-gettext.ini
- /etc/php/7.0/cli/conf.d/20-iconv.ini
- /etc/php/7.0/cli/conf.d/20-json.ini
- /etc/php/7.0/cli/conf.d/20-mbstring.ini
- /etc/php/7.0/cli/conf.d/20-pdo_pgsql.ini
- /etc/php/7.0/cli/conf.d/20-pgsql.ini
- /etc/php/7.0/cli/conf.d/20-phar.ini
- /etc/php/7.0/cli/conf.d/20-posix.ini
- /etc/php/7.0/cli/conf.d/20-readline.ini
- /etc/php/7.0/cli/conf.d/20-shmop.ini
- /etc/php/7.0/cli/conf.d/20-simplexml.ini
- /etc/php/7.0/cli/conf.d/20-sockets.ini
- /etc/php/7.0/cli/conf.d/20-sysvmsg.ini
- /etc/php/7.0/cli/conf.d/20-sysvsem.ini
- /etc/php/7.0/cli/conf.d/20-sysvshm.ini
- /etc/php/7.0/cli/conf.d/20-tokenizer.ini
- /etc/php/7.0/cli/conf.d/20-wddx.ini
- /etc/php/7.0/cli/conf.d/20-xmlreader.ini
- /etc/php/7.0/cli/conf.d/20-xmlwriter.ini
- /etc/php/7.0/cli/conf.d/20-xsl.ini
  You can also run `php --ini` 

Bug#904065: initramfs-tools: stderr reports "rmdir: failed to remove '/var/tmp/mkinitramfs_XXXXXX/var/cache/ldconfig': No such file or directory"

[Boyuan Yang]

Package: initramfs-tools
Severity: important
Version: 0.131

Dear initramfs-tools maintainers,

I installed initramfs-tools 0.131 from http://incoming.debian.org/debian-buildd 
and got the following error messages:

===
正在安装新版本配置文件 /etc/initramfs-tools/initramfs.conf ...
正在设置 initramfs-tools (0.131) ...
update-initramfs: deferring update (trigger activated)
正在设置 firefox-l10n-zh-cn (61.0.1-1) ...
正在处理用于 initramfs-tools (0.131) 的触发器 ...
update-initramfs: Generating /boot/initrd.img-4.17.0-1-amd64
rmdir: 删除 '/var/tmp/mkinitramfs_wEihys/var/cache/ldconfig' 失败: 没有那个文件或目录
===

A manual invocation of update-initramfs got the following output:

===
% LC_ALL=C sudo update-initramfs -u 
update-initramfs: Generating /boot/initrd.img-4.17.0-1-amd64
rmdir: failed to remove '/var/tmp/mkinitramfs_G50d00/var/cache/ldconfig': No 
such file or directory
% echo $?
0


I'm not sure if it is a critical error or not. However, this problem needs to 
be solved anyway.

--
Regards,
Boyuan Yang

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

Bug#904067: ngetty: diff for NMU version 1.1-3.1

[Ben Hutchings]

Package: ngetty
Version: 1.1-3
Severity: normal
Tags: patch

Dear maintainer,

I've prepared an NMU for ngetty (versioned as 1.1-3.1) and
uploaded it.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus
diff -Nru ngetty-1.1/debian/changelog ngetty-1.1/debian/changelog
--- ngetty-1.1/debian/changelog	2012-11-24 07:42:36.0 +
+++ ngetty-1.1/debian/changelog	2018-07-19 04:19:18.0 +0100
@@ -1,3 +1,23 @@
+ngetty (1.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild using a version of dietlibc that does not use vsyscall
+(Closes: #802185)
+  * Add Built-Using relationship to dietlibc (Closes: #847579)
+  * sig_action.h: Define _NSIG_WORDS if necessary (Closes: #829550)
+  * ngetty-helper: Relax permissions check on Conf (Closes: #623264)
+  * Remove explicit use of quilt, which is not needed in a 3.0 (quilt)
+format package
+  * Move dietlibc from Build-Depends to Build-Depends-Arch, as is not
+needed when building the source package
+  * Use debhelper compat level 10
+- Upstream changelog is only installed as changelog.gz, not also as
+  CHANGES
+  * debian/control: Update Standards-Version to 4.1.5
+- Set Rules-Requires-Root: no
+
+ -- Ben Hutchings   Thu, 19 Jul 2018 04:19:18 +0100
+
 ngetty (1.1-3) unstable; urgency=low
 
   * debian/ngetty.lintian-overrides: Remove dot-slash for newer lintian.
diff -Nru ngetty-1.1/debian/compat ngetty-1.1/debian/compat
--- ngetty-1.1/debian/compat	2011-02-15 08:44:34.0 +
+++ ngetty-1.1/debian/compat	2018-07-19 03:37:33.0 +0100
@@ -1 +1 @@
-7
+10
diff -Nru ngetty-1.1/debian/control ngetty-1.1/debian/control
--- ngetty-1.1/debian/control	2011-02-16 02:44:42.0 +
+++ ngetty-1.1/debian/control	2018-07-19 03:55:35.0 +0100
@@ -2,13 +2,16 @@
 Section: comm
 Priority: optional
 Maintainer: NIIBE Yutaka 
-Build-Depends: debhelper (>= 7.0.50~), quilt (>= 0.46-7~), dietlibc-dev
-Standards-Version: 3.9.1
+Build-Depends: debhelper (>= 10~)
+Build-Depends-Arch: dietlibc-dev (>= 0.34~cvs20160209.1)
+Rules-Requires-Root: no
+Standards-Version: 4.1.5
 Homepage: http://riemann.fmi.uni-sofia.bg/ngetty/
 
 Package: ngetty
 Architecture: any
 Depends: lsb-base (>= 3.0-6), ${misc:Depends}
+Built-Using: ${ngetty:Built-Using}
 Description: getty replacement - one single daemon for all consoles
  Ngetty is a daemon that starts login sessions on virtual console
  terminals, on demand.  It is a good replacement for all those getty
diff -Nru ngetty-1.1/debian/patches/ngetty-helper-relax-permissions-check-on-conf.patch ngetty-1.1/debian/patches/ngetty-helper-relax-permissions-check-on-conf.patch
--- ngetty-1.1/debian/patches/ngetty-helper-relax-permissions-check-on-conf.patch	1970-01-01 01:00:00.0 +0100
+++ ngetty-1.1/debian/patches/ngetty-helper-relax-permissions-check-on-conf.patch	2018-07-19 03:10:33.0 +0100
@@ -0,0 +1,23 @@
+From: Ben Hutchings 
+Date: Thu, 19 Jul 2018 03:03:02 +0100
+Subject: ngetty-helper: Relax permissions check on Conf
+Bug-Debian: https://bugs.debian.org/623264
+
+ngetty-helper ignores the contents of the configuration file if any
+permissions outside 0600 (owner read and writable) are set.  But
+debhelper sets the permissions to 0644, so it is ignored by default.
+
+There is nothing secret in the configuration file, so the only
+dangerous permission bits are the group and world writable bits.
+---
+--- a/ngetty-helper.c
 b/ngetty-helper.c
+@@ -232,7 +232,7 @@ int main(int argc,char *argv[]) {
+ /* 40 bytes for Months or Days */
+ if (GLOBAL_fstat_READ(fd,st,s, len,64000, 40)) _exit(1);
+ close(fd);
+-if (st.st_uid || st.st_gid || (st.st_mode & 07177)) len = 0;
++if (st.st_uid || st.st_gid || (st.st_mode & 07022)) len = 0;
+ s[len]=0;
+ 
+ GLOBAL_split(aa,s,'\n', len);
diff -Nru ngetty-1.1/debian/patches/series ngetty-1.1/debian/patches/series
--- ngetty-1.1/debian/patches/series	2011-02-15 08:49:51.0 +
+++ ngetty-1.1/debian/patches/series	2018-07-19 03:48:12.0 +0100
@@ -1,2 +1,4 @@
 01_no_gz_manual_install.diff
 
+sig_action.h-define-_nsig_words-if-necessary.patch
+ngetty-helper-relax-permissions-check-on-conf.patch
diff -Nru ngetty-1.1/debian/patches/sig_action.h-define-_nsig_words-if-necessary.patch ngetty-1.1/debian/patches/sig_action.h-define-_nsig_words-if-necessary.patch
--- ngetty-1.1/debian/patches/sig_action.h-define-_nsig_words-if-necessary.patch	1970-01-01 01:00:00.0 +0100
+++ ngetty-1.1/debian/patches/sig_action.h-define-_nsig_words-if-necessary.patch	2018-07-19 03:10:36.0 +0100
@@ -0,0 +1,25 @@
+From: Ben Hutchings 
+Date: Thu, 19 Jul 2018 02:53:20 +0100
+Subject: sig_action.h: Define _NSIG_WORDS if necessary
+Bug-Debian: https://bugs.debian.org/829550
+
+_NSIG_WORDS is defined in  on Linux, which I assume was
+previously included by dietlibc's  but no longer 

Bug#904066: ITP: python-openidc-client -- A Python OpenID Connect client with token caching and management

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-openidc-client
  Version : 0.6.0
  Upstream Author : Patrick Uiterwijk 
* URL : https://github.com/puiterwijk/python-openidc-client
* License : Expat
  Programming Lang: Python
  Description : A Python OpenID Connect client with token caching and 
management

 This package is a simple Python OpenID Connect client library with
 token caching and management.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#904064: ITP: responder - LLMNR, NBT-NS and MDNS poisoner

[Samuel Henrique]

>
> * URL : https://github.com/SpiderLabs/Responder
>

The correct URL for the upstream is: https://github.com/lgandx/Responder


-- 
Samuel Henrique 

Bug#904064: ITP: responder - LLMNR, NBT-NS and MDNS poisoner

[Samuel Henrique]

Package: wnpp
Owner: "Samuel Henrique" 
Severity: wishlist
User: samuel...@debian.org
Usertags: gsoc2018-portkalipackages

* Package name: responder
* URL : https://github.com/SpiderLabs/Responder

* License : GPL-3+
  Programming Lang: Python
  Description :
Responder an LLMNR, NBT-NS and MDNS poisoner. It will answer to *specific*
NBT-NS (NetBIOS Name Service) queries based on their name suffix. By
default, the tool will only answer to File Server Service request, which is
for SMB.

I intend to maintain this package under the Debian Security Tools Packaging
Team (pkg-security).

-- 
Samuel Henrique 

Bug#904063: solr-tomcat: solr does not start due to NullPointerException

[Michael Welsh Duggan]

Package: solr-tomcat
Version: 3.6.2+dfsg-13
Severity: grave

Dear Maintainer,

According to my logs, tomcat8 is not properly starting solr.  I have
checked, and to the best of my knowledge I have not modified any of the
configuration files.  I tried reverting to java-8, (by modifying
JAVA_HOME in the /etc/default/tomcat8 file), but that did not turn out
to be the problem.  Here are the logs of the failure:

18-Jul-2018 22:01:19.148 INFO [localhost-startStop-1] 
org.apache.catalina.startup.HostConfig.deployDescriptor Deploying configuration 
descriptor [/etc/tomcat8/Catalina/localhost/solr.xml]
18-Jul-2018 22:01:19.505 SEVERE [localhost-startStop-1] 
org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: 
start: 
 org.apache.catalina.LifecycleException: Failed to start component 
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/solr]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:629)
at 
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1839)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.NullPointerException
at 
org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:373)
at 
org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:191)
at 
org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1888)
at 
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1116)
at 
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:765)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:299)
at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5154)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 10 more

18-Jul-2018 22:01:19.506 SEVERE [localhost-startStop-1] 
org.apache.catalina.startup.HostConfig.deployDescriptor Error deploying 
configuration descriptor [/etc/tomcat8/Catalina/localhost/solr.xml]
 java.lang.IllegalStateException: ContainerBase.addChild: start: 
org.apache.catalina.LifecycleException: Failed to start component 
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/solr]]
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:758)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:629)
at 
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1839)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.base/java.lang.Thread.run(Thread.java:844)



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

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

Versions of packages solr-tomcat depends on:
ii  solr-common  3.6.2+dfsg-13
ii  tomcat8  8.5.32-1

solr-tomcat recommends no packages.

solr-tomcat suggests no packages.

-- no debconf information

-- 
Michael Welsh Duggan
(m...@md5i.com)

Bug#904020: libpetsc-real3.9-dev: dependency on libopenmpi-dev not strict enough

[Drew Parsons]

On Thu, 2018-07-19 at 10:18 +0800, Drew Parsons wrote:
> 
> OpenMPI was libopenmpi-dev 3.1.0-7 in the failing deal.ii tests, and 
> libopenmpi-dev 3.1.1.real-3 in the successful tests. Either way
> that's
> still openmpi 3.1, so is supposed to be compatible.  
> 
> So looks like you're right, there may be a PETSc bug when it tests
> for
> mpi compatibility. openmpi 3.1.0 and 3.1.1. are both supposed to be
> fine, they should not be triggering the incompatibility warning.

The actual test (in the subminor version) is 
  (OMPI_RELEASE_VERSION < PETSC_HAVE_OMPI_RELEASE_VERSION)
which means you can't use an older subminor release, which is a
reasonable constraint that we can add to the petsc dependencies (you
can go forwards in subminor version but not backwards).

What it means is that PETSc was built against openmpi 3.1.1.  But you
were using openmpi 3.1.0 in the tests. It is related to the openmpi
transition, which has been all over the shop lately.  openmpi 3.1.1 is
still not in testing.

Drew

Bug#903514: GIMP won't launch

[James Van Zandt]

I note that, according to the strace log, gimp successfully read in 138
plugins, but failed on the very first plug-in that was a Python script.
That can't be a coincidence.

 - Jim Van Zandt

Bug#904037: subversion: Symbol lookup error, Undefined symbol: apr_hash_this_key_len

[James McCoy]

Control: tag -1 = moreinfo

On Wed, Jul 18, 2018 at 12:19:15PM -0400, Mate Lampert wrote:
> I installed subversion on Debian 9.3 with its dependencies and svn is
> not running at all. When I start it, the following error message
> occurs:

Can you show the exact command you're running?

What does “ldd /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1” show?

>   "svn: symbol lookup error: 
> /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1: undefined symbol: 
> apr_hash_this_key_len"

That function has been in libapr1 since 1.5.0, so it should be fine.
The build also ran the entire test suite, so it should have run into the
same problem.

I started a fresh stretch VM, installed subversion and ran “svn co
https://svn.apache.org/repos/asf/subversion/trunk”, which successfully
checked out that tree.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#897902: tweeny: please make the build reproducible

[Hubert Chathi]

Hi Chris,

On Fri, 04 May 2018 16:26:06 +0100, Chris Lamb  said:

> Whilst working on the Reproducible Builds effort [0], we noticed that
> tweeny could not be built reproducibly.

Somehow this bug didn't make it to my inbox, and I didn't notice it
until now.

I'll make a new upload with your patch soon.

Thanks.

Hubert

Bug#904020: libpetsc-real3.9-dev: dependency on libopenmpi-dev not strict enough

[Drew Parsons]

On Wed, 2018-07-18 at 13:52 +0200, Paul Gevers wrote:
> Package: libpetsc-real3.9-dev
> Version: 3.9.3+dfsg1-2
> 
> Dear Drew,
> 
> On 17-07-18 13:20, Graham Inggs wrote:
> > Hi Drew
> > 
> > > On Tue, 17 Jul 2018, Drew Parsons wrote:
> > > > The configuration of ci.debian.org is not consistent.   A
> > > > failing test
> > > > of deal.ii is marked on
> > > > https://ci.debian.net/packages/d/deal.ii/testing/amd64/
> > > > as triggered by petsc/3.9.3+dfsg1-2, but the test log shows
> > > > that in
> > > > fact libpetsc-real3.8-dev is used for the test
> > > > (i.e. petsc/3.8.4+dfsg1-2+b2).  So unsurprisingly the test
> > > > fails, which
> > > > disrupts migration of the new petsc 3.9 (throwing it out to 10
> > > > days
> > > > instead of 5). The failure itself occurs since the different
> > > > petsc were
> > > > built against different openmpi.
> > > From the times in the logs, it appears that the test was run
> > > before
> > 
> > deal.ii's binNMU happened [1].
> > So the delay is only temporary.
> > 
> > As soon as the test is successful, the migration delay will
> > disappear.
> > 
> > I've requested a retry for that test, so it should happen soon.
> 
> Although Graham was right with his timing regarding binNMU of
> deal.ii,
> there is more going on. I really don't want to offend you, but I
> wonder
> if you read the actual error message carefully? (It took Graham and
> me
> quite some time to figure this out and to understand it).
> 
> '''
> PETSc was configured with one OpenMPI mpi.h version but now appears
> to
> be compiling using a different OpenMPI mpi.h version
> '''
> 
> This message comes from petsc, so, whatever header file got installed
> was blessed by petsc.
> 
> Apart from petsc/3.8.4+dfsg1-2+b2 also petsc/3.9.3+dfsg1-2 packages
> were
> installed (so both of them), so I think the trigger did it's job.
> 
> I believe that the current failure is really pointing at a bug in the
> dependencies of libpetsc-real3.9-dev which probably need tighter
> restrictions on libopenmpi-dev looking at the message. If
> libpetsc-real3.9-dev would require libopenmpi-dev from unstable, I
> believe everything would be all right. I'll trigger a test like the
> one
> that currently fails, but with libopenmpi-dev from unstable to prove
> my
> hypothesis.


Thanks for the extra analysis Paul.  You're right, I picked up on the
appearance of petsc 3.8 in the failing tests but actually petsc 3.9 is
installed there too (which is a bit weird).

In regards to the petsc/openmpi dependency, we've already addressed
that. It used to depend on the subminor release version, we've relaxed
it to match major.minor 
https://bitbucket.org/petsc/petsc/commits/ca70f86ee9db8e69523e0e69f12289c6cab9b4cb
 . 

That relationship is expressed in the libpetsc-real3.9-dev dependency,
libopenmpi-dev (>= 3.1), and that's for both libpetsc-real3.8-dev and
libpetsc-real3.9-dev at the moment.


OpenMPI was libopenmpi-dev 3.1.0-7 in the failing deal.ii tests, and 
libopenmpi-dev 3.1.1.real-3 in the successful tests. Either way that's
still openmpi 3.1, so is supposed to be compatible.  

So looks like you're right, there may be a PETSc bug when it tests for
mpi compatibility. openmpi 3.1.0 and 3.1.1. are both supposed to be
fine, they should not be triggering the incompatibility warning.

Drew

Bug#802185: ngetty-helper segfaults after login name is typed in the login prompt

[Ben Hutchings]

On Sun, 18 Oct 2015 15:52:12 +0900 Alexei Andreanov
 wrote:
> Package: ngetty
> Version: 1.1-3
> Severity: important
> 
> Dear Maintainer,
> 
> I switched from getty to ngetty by commenting out the following lines in 
> /etc/inittab:
> 1:2345:respawn:/sbin/getty 38400 tty1
> 2:23:respawn:/sbin/getty 38400 tty2
> 3:23:respawn:/sbin/getty 38400 tty3
> #4:23:respawn:/sbin/getty 38400 tty4
> #5:23:respawn:/sbin/getty 38400 tty5
> #6:23:respawn:/sbin/getty 38400 tty6
> and adding:
> ng:2345:respawn:/sbin/ngetty tty1 tty2
> 
> Now I get the login prompt on tty1 and tty2, however nothing seem to happens 
> upon entering the user name, no password propmt is shown.
> Inspecting the /var/log/syslog, I found the following entries, that I believe 
> are relevant:
> kernel: [ 4015.847046] ngetty-helper[5824]: segfault at ff600400 
> ip ff600400 sp 7ffc6f818380 error 15
> kernel: [ 4015.847620] ngetty-helper[5828]: segfault at ff600400 
> ip ff600400 sp 7ffdc844a340 error 15
> kernel: [ 4020.426987] ngetty-helper[5829]: segfault at ff600400 
> ip ff600400 sp 7fff627e3a40 error 15
> kernel: [ 4020.427565] ngetty-helper[5830]: segfault at ff600400 
> ip ff600400 sp 7ffc7d1bffd0 error 15
> kernel: [ 4201.245888] ngetty-helper[5948]: segfault at ff600400 
> ip ff600400 sp 7ffdcf3745b0 error 15
> kernel: [ 4312.905673] ngetty-helper[6060]: segfault at ff600400 
> ip ff600400 sp 7fffe5fb8600 error 15
> kernel: [ 4312.906285] ngetty-helper[6066]: segfault at ff600400 
> ip ff600400 sp 7ffe69153e70 error 15
> kernel: [ 4316.981373] ngetty-helper[6070]: segfault at ff600400 
> ip ff600400 sp 7ffef812ba70 error 15
> kernel: [ 4316.981906] ngetty-helper[6071]: segfault at ff600400 
> ip ff600400 sp 7ffca85e2360 error 15
> kernel: [ 4345.070415] ngetty-helper[6088]: segfault at ff600400 
> ip ff600400 sp 7ffc38ee6120 error 15
> kernel: [ 4345.070993] ngetty-helper[6089]: segfault at ff600400 
> ip ff600400 sp 7ffeafcb5090 error 15
> kernel: [ 4498.104455] ngetty-helper[6266]: segfault at ff600400 
> ip ff600400 sp 7ffe52b1ecd0 error 15
> kernel: [ 4526.528317] ngetty-helper[6287]: segfault at ff600400 
> ip ff600400 sp 7ffc74c14cb0 error 15
[...]

This is because ngetty was built using a version of dietlibc that uses
the deprecated "vsyscall" entry points to the kernel, and you are using
a kernel with vsyscall disabled.

This will be fixed by rebuilding ngetty.  But the older version should
still work if you rebuild your kernel with
CONFIG_X86_VSYSCALL_EMULATION enabled (or, if it's already enabled,
change the vsyscall kernel parameter).

Ben.
 
-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus


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

Bug#717477: grub-pc: Unable to reconfigure grub using dpkg-reconfigure grub-pc, if initially installed with DEBIAN_FRONTEND=noninteractive

[Daniel Richard G.]

Is this still an issue? I am not able to reproduce it with the current
version of GRUB (2.02).

Bug#904062: Allow concurrent installation of grub-pc and grub-efi-ami64

[Daniel Richard G.]

Package: grub-efi-amd64
Version: 2.02+dfsg1-4
Severity: wishlist

Currently, you can have both grub-{pc,efi-amd64}-bin installed, but you
can only have one or the other of grub-{pc,efi-amd64}, as the packages
conflict with each other. This means that only one grub-install --target
is supported in Debian's configuration framework at any one time.

(It is already possible to install both grub-*-bin packages and invoke
grub-install with the desired --target manually, but this occurs outside
of the Debian framework and so is not a good long-term solution.)

I would like to request making it possible to install both packages
simultaneously, with an appropriate configuration mechanism to
disable one, both, or none. There are at least a couple of use cases
I can see for this:

1. Assembling system images that can support both BIOS and EFI booting
   without needing to install/remove any packages to switch from one
   mode to the other;

2. A Debian install on e.g. a portable USB hard drive with a hybrid
   MBR/GPT partition table that supports *both* the BIOS and EFI
   boot paths.

Bug#898215: may I NMU a repack?

[Adam Borowski]

On 2018-05-08, I wrote:
> I'm afraid my NMU for RC bug #873976 just failed due to autoreject:
> E: db5.3 source: source-contains-prebuilt-ms-help-file 
> docs/csharp/BerkeleyDB.chm
...
> As repacking the upstream tarball is quite an invasive action for a NMU,
> I'm not doing so immediately.  Please advise.

This autoreject blocks fixing the FTBFS, and the FTBFS is one of two(?)
remaining issues that prevent using debootstrap on riscv64.  Thus, would it
be ok to NMU with an .orig repack to eliminate this piece?


Meow.
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#904061: RFS: open-gram/0.1.22+20170109-2 [RC]

[Boyuan Yang]

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

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

As a continuation of dealing with massive RC bugs caused by IME team maintainer
address migration, I have prepared a team upload for package "open-gram" and
I am looking for a sponsor to push it into unstable. This package is the
dependency of all sunpinyin-related packages.

* Package name : open-gram
   Version : 0.1.22+20170109-2
   Upstream Author : Kefu Chai 
 * URL : https://github.com/sunpinyin/open-gram
 * License : CC-BY-SA 3.0
   Section : utils

  It builds those binary packages:

sunpinyin-data - Statistical language model data from open-gram

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

  https://mentors.debian.net/package/open-gram


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

dget -x 
https://mentors.debian.net/debian/pool/main/o/open-gram/open-gram_0.1.22+20170109-2.dsc

  Git packaging repository:

https://salsa.debian.org/input-method-team/open-gram

  Changes since the last upload:

 open-gram (0.1.22+20170109-2) unstable; urgency=medium
 .
   * Team upload.
   * Apply "wrap-and-sort -abst".
   * Bump debhelper compat to v11.
   * debian: Remove unnecessary "debian/\" file.
   * debian/control:
 + Use debian-input-method mailing list as maintainer address.
   Closes: #899622
 + Bump Standards-Version to 4.1.5.
 + Use git repo under Salsa input-method-team group for Vcs fields.
 + Mark sunpinyin-data as M-A: same.
   * debian/rules: Use "dh_missing --fail-missing".

--
Regards,
Boyuan Yang


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

Bug#822730: initramfs-tools: Should we migrate to a "interest-noawait" trigger for update-initramfs -u?

[Ben Hutchings]

On Sun, 2018-02-18 at 07:35 +, Niels Thykier wrote:
> On Sun, 31 Dec 2017 16:29:00 + Niels Thykier  wrote:
> > Control: block 491027 by -1
> > 
> > On Sun, 09 Jul 2017 12:51:00 + Niels Thykier  wrote:
> > > On Tue, 26 Apr 2016 22:10:14 +0200 Niels Thykier  
> > > wrote:
> > > > Package: initramfs-tools
> > > > Version: 0.125
> > > > Severity: wishlist
> > > > Usertags: declarative-packaging 
> > > > 
> > > > Hi,
> > > > 
> > > 
> > > [...]
> > 
> > Ping on this?
> > 
> 
> Hi,
> 
> I have been pinging this bug for nearly two years (admittedly with quite
> some time between some of the pings) without any replies.
> 
> @Ben: Given you appear to be the one doing the actual uploads (i.e. sign
> + upload), could I ask you to review the bug and come with your take on
> this?

I finally had a look at this while preparing a new version.  Sorry for
taking so long, but I hope you understand that wishlist bugs asking a
question are not a high priority.

The dpkg documentation isn't clear (#904060), but it appears to me that
if we use "interest-noawait" then an activating package that really
needs to await will not be able to do so.  If we carry on using
"interest" (or "interest-await") then the activating package can choose
whether to await the trigger or not.

A search for explicit triggers:
https://codesearch.debian.net/search?q=activate.*update-initramfs
shows that there are packages that use "activate-await", and I would
not want to override that without consultation.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus


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

Bug#845034: Updated patch

[Ben Hutchings]

On Thu, 2018-07-19 at 01:37 +0100, Chris Lamb wrote:
> Hi Ben & Kristian,
> 
> Curiously enough I don't remember receiving Kristian's patch. :)
> 
> >   not only unreproducible, but completely useless at boot time since
> >   the device and inode numbers of libraries will be different.
> 
> […] 
> > Since there is no option to explicitly disable creation of the aux-
> > cache file, I propose to delete it ldconfig creates it.
> 
> ^
> 
> Missing "if"? :)

Yes, "... delete it if ldconfig creates it."

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus



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

Bug#856589: marked as done (mkinitramfs fails with MODULES=dep and root on tmpfs)

[Ben Hutchings]

Did you actually mean to close this bug?  The commit you made only
fixes the error message.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus



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

Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?

[Chris Lamb]

Hi Albert,

> Let's see a sample header like ar/messages/kdegraphics/okular_mobi.po
> 
> # Copyright (C) YEAR This_file_is_part_of_KDE
> # This file is distributed under the same license as the PACKAGE package.
> # Zayed Al-Saidi , 2009.
> # Abdalrahim G. Fakhouri , 2014.
> 
> The first one is the one you mentioned, personally i think we can just 
> delete the first line 
[…]
> Opinions?

Works for me.


Regards,

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

Bug#845034: Updated patch

[Chris Lamb]

Hi Ben & Kristian,

Curiously enough I don't remember receiving Kristian's patch. :)

>   not only unreproducible, but completely useless at boot time since
>   the device and inode numbers of libraries will be different.
[…] 
> Since there is no option to explicitly disable creation of the aux-
> cache file, I propose to delete it ldconfig creates it.
^

Missing "if"? :)


Regards,

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

Bug#904058: megatools: megaput hangs at 100% upload

[Ben Caradoc-Davies]

1.10.0-rc1, which includes the fix for this issue, was just released 
upstream:

https://github.com/megous/megatools/issues/362

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#903438: RFA: asciinema -- Record and share your terminal sessions, the right way

[Yaroslav Halchenko]

Fwiw asciinema is quite handy! We use it for our demos (generate them 
automatically from our *cast scripts, along with possible narrated videos, 
actual scripts, or just interactive demonstrations where people get blown away 
at "my" typing speed/stability), see eg those asciinemas at 
http://datalad.org/for/reproducible-science

So I would appreciate if someone takes care about this valuable package... if 
there would be nobody, please buzz me, I will keep it afloat

Cheers

On July 18, 2018 7:48:56 PM EDT, gustavo panizzo  wrote:
>Hi
>On Thu, Jul 19, 2018 at 12:06:58AM +0200, Hilmar Preuße wrote:
>>Am 18.07.2018 um 21:55 teilte gustavo panizzo mit:
>>
>>Hi Gustavo,
>>
>>>Forget screen recording apps and blurry video. Enjoy a lightweight, 
>>>purely text based approach to terminal recording.
>>>This package provides a command line recorder for asciinema.org 
>>>service or other instance of asciinema server.
>>>
>>At first the dumb question: what main features does this application 
>>have, I can't find in script [1]? Well, except the upload feature.
>
>the playback always works, this was my motivation to use (and package)
>asciinema, since it does not depend on what console do you use to play
>it back it always works (and people with windows can play the
>recordings)
>when i started with it, we used asciinema and an internal server to
>record trainings and play them back to students
>
>
>but i changed jobs and stop using it some time ago, that's why RFA
>>
>>Thanks!
>>
>>H.
>>
>>[1] http://man.openbsd.org/script.1
>>-- 
>>#206401 http://counter.li.org

-- 
Sent from a phone which beats iPhone.

Bug#904058: megatools: megaput hangs at 100% upload

[Alberto Garcia]

On Thu, Jul 19, 2018 at 11:10:34AM +1200, Ben Caradoc-Davies wrote:
> Package: megatools
> Version: 1.9.98-1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> megaput hangs when upload is at 100%. Seen twice with 3.0 GiB files. Seems
> fixed upstream on master, likely by reverting upload to not use TLS:
> https://github.com/megous/megatools/issues/360

Ok, it seems like a new version is about to be released:

https://github.com/megous/megatools/issues/362

Berto

Bug#844967: picviz: FTBFS problem and its maintenance in Debian

[Boyuan Yang]

X-Debbugs-CC: Pierre Chifflier 

On Wed, 27 Jun 2018 23:11:56 +0800 Boyuan Yang <073p...@gmail.com> wrote:
> X-Debbugs-CC: Pierre Chifflier 
> 
> On Sat, 19 Nov 2016 08:15:49 +0100 Lucas Nussbaum  
> wrote:
> > Source: picviz
> > Version: 0.5-1
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20161118 qa-ftbfs
> > Justification: FTBFS on amd64
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to 
> build on
> > amd64.
> > 
> > Relevant part (hopefully):
> > >  debian/rules build
> > > dh_testdir
> > > 
> 
> Hi Pierre,
> 
> I noticed that this bug has been around for two years and this 
> package hasn't seen any upload since 2009. Are you planned to fix 
> this bug any time recently? If not, I am willing to provide an NMU 
> based on Ubuntu's patch.
> 
> If you don't feel like continue maintaining picviz anymore, please 
> consider filing RFA bugs or orphaning package so that the package can 
> receive better cares.
> 
> Please feel free to tell me about your opinion torwards picviz in 
> Debian. I might prepare an NMU someday later before Buster freeze if 
> there's no response.

Hi Pierre,

This is a kind reminder about Debian Bug #844967. Are you still going to 
maintain picviz in Debian? Please consider sharing your idea towards picviz so 
that the bug can be solved in a timely manner.

--
Regards,
Boyuan Yang

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

Bug#904058: megatools: megaput hangs at 100% upload

[Ben Caradoc-Davies]

On 19/07/18 12:09, Alberto Garcia wrote:

Ok, it seems like a new version is about to be released:
https://github.com/megous/megatools/issues/362


Yes, very soon. 1.10.0-rc1 includes the fix for the upload hang.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#904060: deb-triggers(5) should explain how await/noawait flags are combined

[Ben Hutchings]

Package: dpkg-dev
Version: 1.19.0.5
Severity: normal

For explicit triggers, both the interested and activated packages can
specify "await" or "noawait".  I could not understand from the current
documentation what is supposed to happen if the two specify the
opposite.

Looking at the source, I think that the triggering package will only
await the trigger if both specify "await" (or don't specify either
way).

Ben.

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

Kernel: Linux 4.17.0-1-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)
LSM: AppArmor: enabled

Versions of packages dpkg-dev depends on:
ii  binutils  2.31-1
ii  bzip2 1.0.6-8.1
ii  libdpkg-perl  1.19.0.5
ii  make  4.2.1-1.1
ii  patch 2.7.6-2
ii  perl  5.26.2-6
ii  tar   1.30+dfsg-2
ii  xz-utils  5.2.2-1.3

Versions of packages dpkg-dev recommends:
ii  build-essential  12.5
ii  clang-4.0 [c-compiler]   1:4.0.1-10+b1
ii  clang-6.0 [c-compiler]   1:6.0.1-2
ii  fakeroot 1.23-1
ii  gcc [c-compiler] 4:7.3.0-3
ii  gcc-4.8 [c-compiler] 4.8.5-4
ii  gcc-7 [c-compiler]   7.3.0-26
ii  gnupg2.2.8-3
ii  gnupg2   2.2.8-3
ii  gpgv 2.2.8-3
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2018.06.24

-- no debconf information

Bug#904059: clang-6.0: default target on armhf is armv8l-unknown-linux-gnueabihf

[Andreas Beckmann]

Package: clang-6.0
Version: 1:6.0.1-2
Severity: serious

Hi,

clang-6.0 and friends advertise their default target on armhf as
armv8l-unknown-linux-gnueabihf, which sounds like nonsense.

(sid_armhf-dchroot)anbe@amdahl:~$ clang-4.0 --version
clang version 4.0.1-10+b1 (tags/RELEASE_401/final)
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
(sid_armhf-dchroot)anbe@amdahl:~$ clang-5.0 --version
clang version 5.0.2-2 (tags/RELEASE_502/final)
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
(sid_armhf-dchroot)anbe@amdahl:~$ clang-6.0 --version
clang version 6.0.1-2 (tags/RELEASE_601/final)
Target: armv8l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /usr/bin

This might depend on the cpu/chroot on the buildd that built the
llvm-toolchain-6.0 package:
* armhf chroot on native armv7 cpu   => sane result  ???
* armhf chroot on 64bit armv8 cpu=> weird result ???


This probably caused this ftbfs in pocl because pocl got confused by
the armv8 on armhf:

https://buildd.debian.org/status/fetch.php?pkg=pocl=armhf=1.1-5%2Bb1=1531819066=0


Andreas

PS: these are the results on arm64:

(sid_arm64-dchroot)anbe@amdahl:~$ clang-4.0 --version
clang version 4.0.1-10+b1 (tags/RELEASE_401/final)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
(sid_arm64-dchroot)anbe@amdahl:~$ clang-5.0 --version
clang version 5.0.2-2 (tags/RELEASE_502/final)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
(sid_arm64-dchroot)anbe@amdahl:~$ clang-6.0 --version
clang version 6.0.1-2 (tags/RELEASE_601/final)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Bug#903438: RFA: asciinema -- Record and share your terminal sessions, the right way

[gustavo panizzo]

Hi
On Thu, Jul 19, 2018 at 12:06:58AM +0200, Hilmar Preuße wrote:

Am 18.07.2018 um 21:55 teilte gustavo panizzo mit:

Hi Gustavo,

Forget screen recording apps and blurry video. Enjoy a lightweight, 
purely text based approach to terminal recording.
This package provides a command line recorder for asciinema.org 
service or other instance of asciinema server.


At first the dumb question: what main features does this application 
have, I can't find in script [1]? Well, except the upload feature.


the playback always works, this was my motivation to use (and package)
asciinema, since it does not depend on what console do you use to play
it back it always works (and people with windows can play the
recordings)
when i started with it, we used asciinema and an internal server to
record trainings and play them back to students


but i changed jobs and stop using it some time ago, that's why RFA


Thanks!

H.

[1] http://man.openbsd.org/script.1
--
#206401 http://counter.li.org


--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Bug#904058: megatools: megaput hangs at 100% upload

[Ben Caradoc-Davies]

Package: megatools
Version: 1.9.98-1+b1
Severity: important

Dear Maintainer,

megaput hangs when upload is at 100%. Seen twice with 3.0 GiB files. Seems
fixed upstream on master, likely by reverting upload to not use TLS:
https://github.com/megous/megatools/issues/360

Kind regards,
Ben.



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

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

Versions of packages megatools depends on:
ii  ca-certificates  20180409
ii  libc62.27-5
ii  libcurl4 7.60.0-2
ii  libglib2.0-0 2.56.1-2
ii  libssl1.11.1.0h-4

megatools recommends no packages.

megatools suggests no packages.

-- no debconf information

Bug#904057: linux-image-4.9.0-7-amd64: DMAR errors at boot and erratic ACPI behavior with suspend-to-RAM

[Erik Martin-Dorel]

Package: src:linux
Version: 4.9.110-1
Severity: normal

Dear Maintainer,

I use Debian stable on my recently-bought Dell Latitude 5580 laptop.

Since day one, I noticed a few issues when connecting my laptop to my Dell
docking station (viz., 1 times over 3, the GNOME desktop freezes and I have to
reboot). But when using the laptop away from the docking station, everything
was OK all the time.

However, I am now experiencing a much more annoying behavior: when suspending-
to-RAM and waking-up, the laptop actually reboots, cleaning orphaned inodes...
implying the shutdown wasn't done properly and may cause data loss.
I reproduced this behavior several times systematically, then I rebooted on
linux-image-4.9.0-6-amd64, where the issue didn't occur.

So I suspect that 4.9.0-7 introduces some ACPI bug.

Later on, I rebooted several times with the two kernel versions to look at the
logs, and even if I wasn't able to trigger again the abnormal shutdown, I
indeed got some ACPI error in the logs.
See below the 4 journalctl excerprts that were generated using the following
commands:

$ sudo journalctl -p err -b 0 > "$(uname -srm)_boot.txt"
# Click on the Suspend-to-RAM button in GNOME
# Close and re-open the lid
$ sudo journalctl -p err -b 0 > "$(uname -srm)_boot+suspend+wakeup.txt"


$ cat Linux\ 4.9.0-6-amd64\ x86_64_boot.txt
-- Logs begin at Thu 2018-07-19 00:26:10 CEST, end at Thu 2018-07-19 00:42:46
CEST. --
juil. 19 00:41:54 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-26.ucode (-2)
juil. 19 00:41:54 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-25.ucode (-2)
juil. 19 00:41:54 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-24.ucode (-2)
juil. 19 00:41:54 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-23.ucode (-2)
juil. 19 00:41:54 vivace kernel: i915 :00:02.0: firmware: failed to load
i915/kbl_dmc_ver1_01.bin (-2)
juil. 19 00:41:55 vivace systemd-udevd[370]: Error calling EVIOCSKEYCODE on
device node '/dev/input/event9' (scan code 0x150, key code 190): Invalid
argument
juil. 19 00:41:55 vivace avahi-daemon[562]: chroot.c: open() failed: No such
file or directory
juil. 19 00:41:55 vivace bluetoothd[549]: Failed to obtain handles for "Service
Changed" characteristic
juil. 19 00:41:55 vivace bluetoothd[549]: Sap driver initialization failed.
juil. 19 00:41:55 vivace bluetoothd[549]: sap-server: Operation not permitted
(1)
juil. 19 00:42:07 vivace bluetoothd[549]: RFCOMM server failed for Headset
Voice gateway: rfcomm_bind: Address already in use (98)

$ cat Linux\ 4.9.0-6-amd64\ x86_64_boot+suspend+wakeup.txt
-- Logs begin at Thu 2018-07-19 00:26:10 CEST, end at Thu 2018-07-19 00:43:41
CEST. --
juil. 19 00:41:54 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-26.ucode (-2)
juil. 19 00:41:54 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-25.ucode (-2)
juil. 19 00:41:54 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-24.ucode (-2)
juil. 19 00:41:54 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-23.ucode (-2)
juil. 19 00:41:54 vivace kernel: i915 :00:02.0: firmware: failed to load
i915/kbl_dmc_ver1_01.bin (-2)
juil. 19 00:41:55 vivace systemd-udevd[370]: Error calling EVIOCSKEYCODE on
device node '/dev/input/event9' (scan code 0x150, key code 190): Invalid
argument
juil. 19 00:41:55 vivace avahi-daemon[562]: chroot.c: open() failed: No such
file or directory
juil. 19 00:41:55 vivace bluetoothd[549]: Failed to obtain handles for "Service
Changed" characteristic
juil. 19 00:41:55 vivace bluetoothd[549]: Sap driver initialization failed.
juil. 19 00:41:55 vivace bluetoothd[549]: sap-server: Operation not permitted
(1)
juil. 19 00:42:07 vivace bluetoothd[549]: RFCOMM server failed for Headset
Voice gateway: rfcomm_bind: Address already in use (98)
juil. 19 00:43:31 vivace bluetoothd[549]: Failed to obtain handles for "Service
Changed" characteristic
juil. 19 00:43:31 vivace bluetoothd[549]: Sap driver initialization failed.
juil. 19 00:43:31 vivace bluetoothd[549]: sap-server: Operation not permitted
(1)
juil. 19 00:43:31 vivace bluetoothd[549]: RFCOMM server failed for Headset
Voice gateway: rfcomm_bind: Address already in use (98)

$ cat Linux\ 4.9.0-7-amd64\ x86_64_boot.txt
-- Logs begin at Thu 2018-07-19 00:26:10 CEST, end at Thu 2018-07-19 00:38:18
CEST. --
juil. 19 00:36:31 vivace kernel: DMAR: DRHD: handling fault status reg 2
juil. 19 00:36:31 vivace kernel: DMAR: [INTR-REMAP] Request device [f0:1f.0]
fault index 0 [fault reason 37] Blocked a compatibility format interrupt
request
juil. 19 00:36:31 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-26.ucode (-2)
juil. 19 00:36:31 vivace kernel: iwlwifi :01:00.0: firmware: failed to load
iwlwifi-8265-25.ucode (-2)
juil. 19 00:36:31 vivace kernel: iwlwifi :01:00.0: firmware: failed to load

Bug#904030: clipit: Copy/Paste is not working

[Dmitry Smirnov]

On Wednesday, 18 July 2018 11:58:41 PM AEST void wrote:
>Tried to copy/paste in leafpad...

I cold not reproduce the problem under Cinnamon DE. Copy/Paste works for me 
in leafpad and everywhere else...

-- 
All the best,
 Dmitry Smirnov.

---

Problems are not stop signs, they are guidelines.
-- Robert H. Schuller


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

Bug#904056: glibc: FTBFS on hppa - nptl/tst-execstack fails

[John David Anglin]

Source: glibc
Version: 2.27-5
Severity: normal
Tags: patch

Dear Maintainer,

As on mips, hppa still requires an executable stack for syscall restarts
and signal returns.  This is BZ #23174.

2.27-5 fails to build because of the following problem:

+-+
| Encountered regressions that don't match expected failures. |
+-+
FAIL: nptl/tst-execstack
make: *** [debian/rules.d/build.mk:115: /<>/stamp-dir/check_libc] 
Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=glibc=hppa=2.27-5=1531930990=0

The attached fix is installed on glibc trunk.

Regards,
Dave Anglin

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.56+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
2018-06-10  John David Anglin  

[BZ #23174]
* sysdeps/unix/sysv/linux/hppa/Makefile: xfail check-execstack.

diff --git a/sysdeps/unix/sysv/linux/hppa/Makefile 
b/sysdeps/unix/sysv/linux/hppa/Makefile
index 68569013fb..e1637f54f5 100644
--- a/sysdeps/unix/sysv/linux/hppa/Makefile
+++ b/sysdeps/unix/sysv/linux/hppa/Makefile
@@ -2,3 +2,10 @@
 ifeq ($(subdir),stdlib)
 gen-as-const-headers += ucontext_i.sym
 endif
+
+# Supporting non-executable stacks on HPPA requires changes to both
+# the Linux kernel and glibc. The kernel currently needs an executable
+# stack for syscall restarts and signal returns.
+ifeq ($(subdir),elf)
+test-xfail-check-execstack = yes
+endif

Bug#904055: ghc: Please backport important fix for unregisterised compiler

[Clint Adams]

Even better would be to registerise those architectures.

Bug#904040: openntpd: Apparmor denies logging

[Dererk]

user pkg-apparmor-t...@lists.alioth.debian.org
usertags #904040 + help-needed
thanks

Dear App Armor Team!

I was reported about a bug on the way an apparmor profile behaves.
It appears to me that this issue might be tightly related to the way 
apparmor is compiled on Ubuntu, since all my attempts to find similar 
reports get isolated to Ubuntu's reports and bug fixes.


Would you be kind in advice on how to proceed with this? Is this 
possible to be hit on Debian installations? If its not, Is it safe to 
apply it on Debian without backfiring?



Thanks in advance


Your #1 fan,

\d


On 18/07/18 14:06, Stefano Rivera wrote:

Package: openntpd
Version: 1:6.2p3-1
Severity: normal
Tags: patch

Can't reproduce this in a quick check in Debian, but I can see it on
Ubuntu 18.04 machines, and this patch does the trick.

AppArmor denies openntpd access to syslog:

[1690592.258663] audit: type=1400 audit(1531921190.778:1052): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - 
disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=2708 comm="ntpd" 
requested_mask="w" denied_mask="w" fsuid=0 ouid=0

This seems to be a known issue with apparmor + systemd
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1373070

And the workaround is a patch like this (which has already been applied
to ntpd).

SR


--
BOFH excuse #154:

You can tune a file system, but you can't tune a fish (from most tunefs man 
pages)

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-05-28 17:43:15 [+0200], Emilio Pozuelo Monfort wrote:
> Let's go with this. I'll schedule the binNMUs soon.

atm we have:

- netsurf (sid only)
  #867694 [G|  |  ] [netsurf-fb] netsurf-fb: Completely unusable due to missing 
dependencies, symlinks and documentation
  #859230 [S|  |  ] [netsurf] netsurf: Please migrate to openssl1.1 in Buster
  #869600 [S|⛺|  ] [src:netsurf] netsurf FTBFS: error: conflicting types for 
'svgtiny_color_lookup' 

  NMU+2d to fix #859230 + #869600. #867694 is still there but…
  
- frobtads (sid only)
  #836934 [S|+|  ] [src:frobtads] frobtads: FTBFS with GCC 6: error: exception 
cleanup for this placement new selects non-placement operator delete
  #871215 [S|+|  ] [src:frobtads] frobtads: FTBFS with GCC-7: error: ISO C++ 
forbids comparison between pointer and integer

  There are patches attached. Maybe NMU?

- gambas3 (sid only)
  #867306 [S|  |  ] [src:gambas3] gambas3: spurious libqtwebkit-dev build 
dependency
  #899515 [S|  |  ] [src:gambas3] gambas3: Invalid maintainer address 
pkg-gambas-de...@lists.alioth.debian.org
  #900998 [S|u|  ] [src:gambas3] gambas3: FTBFS w/SDL2 2.0.7+: 
MIX_INIT_FLUIDSYNTH undeclared
  #867930 [S|  |↝] [src:gambas3] gambas3: Build-Depends on deprecated 
libgnome-keyring-dev

  Hmm. So based on https://hg.libsdl.org/SDL_mixer/rev/92882ef2ab81 it
  seems that MIX_INIT_FLUIDSYNTH -> MIX_INIT_MID would make it build
  again. And Upstream did almost the same thing:
  
https://gitlab.com/gambas/gambas/commit/caf54c5b75d62d3136f12a6e5657df4e2ec555ba
  
  Not sure about the other bugs. Worth fixing that one?

- scilab
  rebuilt everywhere except for i386. Plus
  #891351 [G|  |  ] [scilab] scilab segfaults at startup
  #875790 [S|⛺+|  ] [src:scilab] scilab: depends on openjdk-8
  #884033 [S|  |☣] [scilab] scilab segfaults building 
scilab-{ann,celestlab,plotlib}
  #902826 [S|  |  ] [src:scilab] scilab: FTBFS on i386 - seg. fault during build

  Building currently without all (#902826).  Assuming it works, would it
  make sense to NMU+2d it? We would get rid of one RC bug for curl but…

- xmltooling (sid only)
  #859831 [S|  |♔☣] [xmltooling] xmltooling: Please migrate to openssl1.1 in 
Buster
  Can't be built at the moment. We are waiting for new upstream version.

- freeipa (sid only)
  hardcoded "libcurl3 (>= 7.22.0)" in freeipa-client. There is
  #901430 conflict: freeipa depends upon libcurl3 and (curl --> libcurl4)
  Dropping the build-depend on libcurl3, NMU 4d.
  Maybe I should rise that to 'serious'?

- kcov (sid only)
  #780620 [S|+|  ] [src:kcov] control file not policy compliant and build 
failures almost everywhere
  #790912 [S|⛺|  ] [kcov] FTBFS: ld: CMakeFiles/kcov.dir/capabilities.cc.o .. 
recompile with -fPIC
  #839374 [S|  |  ] [src:kcov] kcov: FTBFS: ld: final link failed: 
Nonrepresentable section on output
  #880344 [S|  |  ] [src:kcov] kcov: FTBFS: Test failures

  Ehm, yes. 

- openalpr (sid only)
  #896793 [S|⛺|  ] [src:openalpr] openalpr: missing build dependency on 
python3-distutils
  Adding B-D, NMU+2d

> Cheers,
> Emilio

Sebastian

Bug#902981: Font-Awesome 5 no build system DFSG compatibility

[Alexis Murzeau]

Hi,

I have a question regarding the font-awesome v5 [0] and the DFSG.

Since version 5, font-awesome upstream repository contains both source
files and generated files but not the build system [1].

So it is not possible to regenerate generated files from source files
without guessing which file are generated and which are sources.
I've asked upstream about that [2] (but no response yet).

It's a bit as if this upstream repository was a tarball containing
binaries and sources but without makefiles used to generated the
binaries, just being a git repo instead of a tarball file.

Considering DFSG #2:
> The program must include source code, and must allow distribution in
> source code as well as compiled form.

is font-awesome 5 upstream repository DFSG compatible ?

Thanks for your help :)



[0]: https://github.com/FortAwesome/Font-Awesome
[1]:
https://github.com/FortAwesome/Font-Awesome/issues/12199#issuecomment-363168281
[2]: https://github.com/FortAwesome/Font-Awesome/issues/13467

Font-awesome 5 licensing is [3]:
> Font Awesome Free is free, open source, and GPL friendly. You can use
> it for commercial projects, open source projects, or really almost
> whatever you want.
>
> Icons — CC BY 4.0 License [4]
> In the Font Awesome Free download, the CC BY 4.0 license applies to
> all icons packaged as .svg and .js files types.
>
> Fonts — SIL OFL 1.1 License [5]
> In the Font Awesome Free download, the SIL OLF license applies to all
> icons packaged as web and desktop font files.
>
> Code — MIT License [6]
> In the Font Awesome Free download, the MIT license applies to all
> non-font and non-icon files.
>
> Attribution
> Attribution is required by MIT, SIL OLF, and CC BY licenses.
> Downloaded Font Awesome Free files already contain embedded comments
> with sufficient attribution, so you shouldn't need to do anything
> additional when using these files normally.
>
> We've kept attribution comments terse, so we ask that you do not
> actively work to remove them from files, especially code. They're a
> great way for folks to learn about Font Awesome.

[3]: https://fontawesome.com/license/free
[4]: https://creativecommons.org/licenses/by/4.0/
[5]: https://scripts.sil.org/OFL
[6]: https://opensource.org/licenses/MIT

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






signature.asc
Description: OpenPGP digital signature

Bug#904055: ghc: Please backport important fix for unregisterised compiler

[John Paul Adrian Glaubitz]

Source: ghc
Version: 8.2.2-4
Severity: normal
Tags: patch upstream
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

I recently reported a GHC bug upstream which resulted in miscompiled
code when using an unregisterised compiler [1]. Upstream has managed
to track down the issue to GHC producing code that the C compiler
doesn't like. The bug was observed on m68k and sh4 in Debian, but
according to upstream, can affect any other target using an unregisterised
compiler.

The patch can be found in [2], I'm also attaching it. It would be
highly appreciated if the patch could be included in the next upload
so that future uploads of GHC 8.2.x will continue to work on the
affected architectures.

Thanks,
Adrian

> [1] https://ghc.haskell.org/trac/ghc/ticket/15338
> [2] 
> https://git.haskell.org/ghc.git/commitdiff/8ec48990fee9e245bb2fe40dc6f65b61b8612157

--
 .''`.  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
Description: driver: skip -Bsymbolic on unregisterised targets
 Trac #15338 is yet another example where -Bsymbolic breaks
 semantics of a C program: global variable duplication happens
 and unsafePerformIO creates two stdout copies.
 .
 When -Bsymbolic is not used both C compiler and linker agree
 on how global variables are handled. In case of sh4 it consists
 on a few assertions:
 .
 1. global variable is exported from shared library
 2. code is referred to this variable via GOT-like mechanism to allow
interposition
 3. global variable is present .bss section on an executable
(as an R_*_COPY relocation: symbol contents is copied at executable
startup time)
 4. and symbol in executable interposes symbol in shared library.
 .
 This way both code in shared library and code in executable refer
 to a copy of global variable in .bss section of an executable.
 .
 Unfortunately -Bsymbolic option breaks assumption [2.] and generates
 direct references to the symbol. This causes mismatch between
 values seen from executable and values seen from shared library code.
 .
 This change disables '-Bsymbolic' for unregisterised targets.

--- ghc-8.2.2.orig/compiler/main/SysTools.hs
+++ ghc-8.2.2/compiler/main/SysTools.hs
@@ -1741,9 +1741,12 @@ linkDynLib dflags0 o_files dep_packages
 ---
 
 let output_fn = case o_file of { Just s -> s; Nothing -> "a.out"; }
+unregisterised = platformUnregisterised (targetPlatform dflags)
 let bsymbolicFlag = -- we need symbolic linking to resolve
--- non-PIC intra-package-relocations
-["-Wl,-Bsymbolic"]
+-- non-PIC intra-package-relocations for
+-- performance (where symbolic linking works)
+-- See Note [-Bsymbolic assumptions by GHC]
+["-Wl,-Bsymbolic" | not unregisterised]
 
 runLink dflags (
 map Option verbFlags
@@ -1800,3 +1803,27 @@ getFrameworkOpts dflags platform
 -- reverse because they're added in reverse order from the cmd line:
 framework_opts = concat [ ["-framework", fw]
 | fw <- reverse frameworks ]
+
+{-
+Note [-Bsymbolic assumptions by GHC]
+
+
+GHC has a few assumptions about interaction of relocations in NCG and linker:
+
+1. -Bsymbolic resolves internal references when the shared library is linked,
+   which is important for performance.
+2. When there is a reference to data in a shared library from the main program,
+   the runtime linker relocates the data object into the main program using an
+   R_*_COPY relocation.
+3. If we used -Bsymbolic, then this results in multiple copies of the data
+   object, because some references have already been resolved to point to the
+   original instance. This is bad!
+
+We work around [3.] for native compiled code by avoiding the generation of
+R_*_COPY relocations.
+
+Unregisterised compiler can't evade R_*_COPY relocations easily thus we disable
+-Bsymbolic linking there.
+
+See related Trac tickets: #4210, #15338
+-}

Bug#903713: plasma-browser-integration: "This_file_is_part_of_KDE" in debian/copyright?

[Albert Astals Cid]

El dissabte, 14 de juliol de 2018, a les 15:04:11 CEST, Luigi Toscano va 
escriure:
> Maximiliano Curia ha scritto:
> > ¡Hola Luigi!
> > 
> > El 2018-07-14 a las 10:37 +0100, Chris Lamb escribió:
> >>> My interpretation of this is that the intention is to assign the copyright
> >>> to the kde project, although it's not a hundred percent clear.
> > 
> >> I should have been clearer, sorry — I understand you are going with
> >> whatever the file says but I am requesting that you make this clearer,
> >> perhaps by getting a statement from upstream or similar.
> > 
> >> "This_file_is_part_of_KDE" is really not suitable as an author,
> >> whatever the file says, after all.
> > 
> > Chris raised the issue of the po files distributed by kde containing some 
> > (not 
> > very clear) template parts, in particular the copyright assignments to 
> > This_file_is_part_of_KDE.
> 
> I'm not sure that's a copyright assignment. Usually we have the FLA for that:
> https://ev.kde.org/rules/fla.php
> 
> I suspect that it was a replacement of the standard copyright assignation to 
> the FSF which was there in the early days but it really did not fit.
> I tracked it back to this change, from 2006 (the string was later changed to 
> used underscores instead of spaces):
> https://websvn.kde.org/?view=revision=505466
> 
> The message is probably incorrect (without copyright is all reserved, not 
> public domain) but it has been like that for a while.
> 
> I'm not sure I'm allowed to decide if it's a copyright assignment or not. I'm 
> probably going to ask the board of the KDE e.V., as it is a legal question.
> I added Albert Astal Cid, who is and has been in charge of in the i18n team 
> more than me, he was part of the board in the past, and maybe we can discuss 
> what to do.

Yes, there is a long standing issue with the translations of the .po files that 
carry not really good copyright information most of the times.

Let's see a sample header like ar/messages/kdegraphics/okular_mobi.po

# Copyright (C) YEAR This_file_is_part_of_KDE
# This file is distributed under the same license as the PACKAGE package.
# Zayed Al-Saidi , 2009.
# Abdalrahim G. Fakhouri , 2014.

The first one is the one you mentioned, personally i think we can just delete 
the first line (or change them to "For Copyright see the individual names 
below"), they are "worthless/wrong" and if people use the "right" tools for 
translation their copyright is added after those lines, i.e. lines 3 and 4.

The second line is also wrong, what is "PACKAGE"? In my opinion now that we 
ship the translations as part of the application tarballs themselves it's 
clear-ish that unless otherwise stated in the file, the files are under the 
copyright stated in the COPYING file so we may as well delete those lines too.

Opinions?

Cheers,
  Albert

> 
> 
> > With your kde i18n team hat on, would you consider it feasible to replace 
> > these strings with something clearer?
> > 
> > If the intention is for the translators to assign the copyright to kde it 
> > should be assigned to KDE.e.V, if the intention is for each translator to 
> > keep 
> > the copyright assignment the This_file_is_part_of_KDE part of the template 
> > needs to be updated to say AUTHOR .
> > 
> > The first case should be "scriptable" the second case, would need to 
> > manually 
> > modifying each po file that contains the "This_file_is_part_of_KDE" text.
> 
> As I said, I don't think it's the first case, but I can ask to the e.V.
> 
> If it's going to be the second case, I don't think that's practical when the 
> list of authors is still in the file. Shouldn't a string like
> Copyright (C) the respective authors (see below)
> work? Or something more legally fitting.
> 
> 
> Finally, a request: please lower the severity of this bug. It's not a 
> regression, and I would assume good faith on something that has been the same 
> for the past 10+ years, without having a "serious" bug in the middle.
> 
> Ciao
> 

Bug#904045: enlightenment: no background image tiling

[Ross Vandegrift]

On Wed, Jul 18, 2018 at 10:22:52PM +0200, enno wrote:
> I like to have my custom images tiled as background.  e17 as of 0.17.6-1.1+b1
> could do it, apparently 0.22.3-2 cannot.  Or I couldn't find it in Settings.

You set this when the picture is imported.

Open Settings -> Wallpaper and click "Picture...".  Choose your image
file and Enlightenment will open a dialog that lets you control setup
the image, including tiling.

Ross

Bug#901430: freeipa: diff for NMU version 4.6.3-1.1

[Sebastian Andrzej Siewior]

Control: tags 901430 + patch
Control: tags 901430 + pending

Dear maintainer,

I've prepared an NMU for freeipa (versioned as 4.6.3-1.1) and
uploaded it to DELAYED/4. Please feel free to tell me if I
should delay it longer.

Regards.
Sebastian
diff -Nru freeipa-4.6.3/debian/changelog freeipa-4.6.3/debian/changelog
--- freeipa-4.6.3/debian/changelog	2018-02-02 16:27:44.0 +0100
+++ freeipa-4.6.3/debian/changelog	2018-07-19 00:03:21.0 +0200
@@ -1,3 +1,10 @@
+freeipa (4.6.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop the libcurl3 dependency (Closes: #901430).
+
+ -- Sebastian Andrzej Siewior   Thu, 19 Jul 2018 00:03:21 +0200
+
 freeipa (4.6.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru freeipa-4.6.3/debian/control freeipa-4.6.3/debian/control
--- freeipa-4.6.3/debian/control	2018-02-01 13:14:03.0 +0100
+++ freeipa-4.6.3/debian/control	2018-07-19 00:00:17.0 +0200
@@ -186,7 +186,6 @@
  dnsutils,
  freeipa-common (= ${source:Version}),
  krb5-user,
- libcurl3 (>= 7.22.0),
  libnss3-tools,
  libnss-sss,
  libpam-sss,

Bug#888898: (no subject)

[Gregor Riepl]

This issue also affects other big endian architectures, like sparc64.

It's interesting to note that a similar problem turned up 5 years ago and was
fixed by simply disabling skia GPU rendering on big endian architectures:
https://bugzilla.mozilla.org/show_bug.cgi?id=849253

Curious that this lack of compatibility came back in FF59+.

Does your patch still work with FF61?

Bug#902981: new upstream (5.1.0)

[Alexis Murzeau]

On 17/07/2018 23:15, Daniel Baumann wrote:
> Hi,
> 
> please remember to CC the submitter explicitly, sending a message only
> to the bug does not notify the submitter.
Ok thanks, I wasn't totally aware of that.

> 
> regarding font-awesome 5: I use the package in my own things as well as
> some (unimportant) packages I maintain.
> 
> How about having fonts-font-awesome5 in parallel to 4.x?

This is the idea to have it as a separate package with "5" suffix.
But since v5 upstream does not chip build system files, only source and
generated files are available on github without a way to rebuild them.
I asked them a first question about which files are actual sources and
which are generated.
I will ask debian-legal about this, if this cause an issue regarding DFSG.

> 
> Regards,
> Daniel
> 


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



signature.asc
Description: OpenPGP digital signature

Bug#903438: RFA: asciinema -- Record and share your terminal sessions, the right way

[Hilmar Preuße]

Am 18.07.2018 um 21:55 teilte gustavo panizzo mit:

Hi Gustavo,

Forget screen recording apps and blurry video. Enjoy a lightweight, 
purely text based approach to terminal recording.
This package provides a command line recorder for asciinema.org service 
or other instance of asciinema server.


At first the dumb question: what main features does this application 
have, I can't find in script [1]? Well, except the upload feature.


Thanks!

H.

[1] http://man.openbsd.org/script.1
--
#206401 http://counter.li.org

Bug#903693: file: Please tech file to recognize the Sketchup 3D model format

[Christoph Biedl]

Control: tags 903693 pending

Petter Reinholdtsen wrote...

> The Sketchup 3D model format is used by the Sketchup modelling tool
> available from https://www.sketchup.com/ >.

Although I didn't find a specification for this file format, a bunch of
files I found in the net show an obvious pattern.

So unless upstream reacts, the next upload will contain the following
magic:

0   string  
\xff\xfe\xff\x0e\x53\x00\x6b\x00\x65\x00\x74\x00\x63\x00\x68\x00\x55\x00\x70\x00\x20\x00\x4d\x00\x6f\x00\x64\x00\x65\x00\x6c\x00
  SketchUp Model
!:mime  application/vnd.sketchup.skp
!:ext   skp

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#896793: openalpr: diff for NMU version 2.3.0-1.1

[Sebastian Andrzej Siewior]

Control: tags 896793 + patch
Control: tags 896793 + pending

Dear maintainer,

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

Regards.
Sebastian
diff -Nru openalpr-2.3.0/debian/changelog openalpr-2.3.0/debian/changelog
--- openalpr-2.3.0/debian/changelog	2016-09-17 18:27:25.0 +0200
+++ openalpr-2.3.0/debian/changelog	2018-07-18 23:52:45.0 +0200
@@ -1,3 +1,10 @@
+openalpr (2.3.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add python3-distutils to Build-depends (Closes: #896793).
+
+ -- Sebastian Andrzej Siewior   Wed, 18 Jul 2018 23:52:45 +0200
+
 openalpr (2.3.0-1) unstable; urgency=low
 
   * Added plate detection mask and prewarp config changes via API
diff -Nru openalpr-2.3.0/debian/control openalpr-2.3.0/debian/control
--- openalpr-2.3.0/debian/control	2016-09-17 17:28:22.0 +0200
+++ openalpr-2.3.0/debian/control	2018-07-18 23:52:07.0 +0200
@@ -5,7 +5,7 @@
 Build-Depends: debhelper (>= 9), cmake, quilt, 
  libtesseract-dev, libleptonica-dev, liblog4cplus-dev,
  libcurl3-dev, libopencv-dev, default-jdk,
- python, python3, dh-python
+ python, python3, dh-python, python3-distutils
 Standards-Version: 3.9.6
 Homepage: https://github.com/openalpr/openalpr
 Vcs-Browser: https://github.com/openalpr/openalpr

Bug#859230: netsurf: diff for NMU version 3.6-3.2

[Sebastian Andrzej Siewior]

control: tags -1 patch pending

Dear maintainer,

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

Regards.
Sebastian
diff -Nru netsurf-3.6/debian/changelog netsurf-3.6/debian/changelog
--- netsurf-3.6/debian/changelog	2017-02-08 21:10:34.0 +0100
+++ netsurf-3.6/debian/changelog	2018-07-18 23:25:47.0 +0200
@@ -1,3 +1,11 @@
+netsurf (3.6-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Depend on libssl-dev (Closes: #859230).
+  * Get it build again new gperf (Closes: #869600).
+
+ -- Sebastian Andrzej Siewior   Wed, 18 Jul 2018 23:25:47 +0200
+
 netsurf (3.6-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru netsurf-3.6/debian/control netsurf-3.6/debian/control
--- netsurf-3.6/debian/control	2017-02-08 21:08:27.0 +0100
+++ netsurf-3.6/debian/control	2017-02-08 21:10:34.0 +0100
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Vincent Sanders 
 Uploaders: Daniel Silverstone 
-Build-Depends: debhelper (>= 9~), libcurl3-dev, libpng-dev, libgtk2.0-dev, flex, bison, libhtml-parser-perl, librsvg2-dev, libjpeg-dev, imagemagick, libfreetype6-dev, libvncserver-dev, libsdl1.2-dev, libxcb1-dev, libxcb-icccm4-dev, libxcb-image0-dev, libxcb-keysyms1-dev, libxcb-util0-dev, libssl1.0-dev | libssl-dev (<< 1.1), gperf
+Build-Depends: debhelper (>= 9~), libcurl3-dev, libpng-dev, libgtk2.0-dev, flex, bison, libhtml-parser-perl, librsvg2-dev, libjpeg-dev, imagemagick, libfreetype6-dev, libvncserver-dev, libsdl1.2-dev, libxcb1-dev, libxcb-icccm4-dev, libxcb-image0-dev, libxcb-keysyms1-dev, libxcb-util0-dev, libssl-dev, gperf
 Standards-Version: 3.9.8
 Homepage: http://www.netsurf-browser.org
 Vcs-Browser: http://source.netsurf-browser.org/packaging/debian.git/
diff -Nru netsurf-3.6/debian/patches/Build-Include-gperf-generated-code-directly.patch netsurf-3.6/debian/patches/Build-Include-gperf-generated-code-directly.patch
--- netsurf-3.6/debian/patches/Build-Include-gperf-generated-code-directly.patch	1970-01-01 01:00:00.0 +0100
+++ netsurf-3.6/debian/patches/Build-Include-gperf-generated-code-directly.patch	2017-02-08 21:10:34.0 +0100
@@ -0,0 +1,92 @@
+From: Michael Drake 
+Date: Thu, 20 Apr 2017 09:51:07 +
+Subject: [PATCH] Build: Include gperf-generated code directly.
+
+Previously we built the generated code separatly and then linked to
+it.  However, this caused problems with certain compilers and gperf
+versions.  This change includes the generated code directly in
+svgtiny.c instead, which is the only place its used.
+
+Source: http://source.netsurf-browser.org/libsvgtiny.git/commit/?id=4390f1c84e8fee51fc22468821e6fc158e783053
+---
+ libsvgtiny/src/Makefile   | 13 +++--
+ libsvgtiny/src/colors.gperf   |  8 
+ libsvgtiny/src/svgtiny.c  |  3 +++
+ libsvgtiny/src/svgtiny_internal.h |  5 -
+ 4 files changed, 10 insertions(+), 19 deletions(-)
+
+diff --git a/libsvgtiny/src/Makefile b/libsvgtiny/src/Makefile
+index a97972023257..fb8a72f9c2ff 100644
+--- a/libsvgtiny/src/Makefile
 b/libsvgtiny/src/Makefile
+@@ -1,13 +1,14 @@
+ # Sources
+ DIR_SOURCES := svgtiny.c svgtiny_gradient.c svgtiny_list.c
+ 
+-SOURCES := $(SOURCES) $(BUILDDIR)/src_colors.c
++SOURCES := $(SOURCES)
+ 
+-$(BUILDDIR)/src_colors.c: src/colors.gperf
++$(DIR)autogenerated_colors.c: src/colors.gperf
+ 	$(VQ)$(ECHO) "   GPERF: $<"
+-	$(Q)gperf --output-file=$@.tmp $<
+-# Hack for GCC 4.2 compatibility (gperf 3.0.4 solves this properly)
+-	$(Q)$(SED) -e 's/#ifdef __GNUC_STDC_INLINE__/#if defined __GNUC_STDC_INLINE__ || defined __GNUC_GNU_INLINE__/' $@.tmp >$@
+-	$(Q)$(RM) $@.tmp
++	$(Q)gperf --output-file=$@ $<
++
++PRE_TARGETS := $(DIR)autogenerated_colors.c
++
++CLEAN_ITEMS := $(DIR)autogenerated_colors.c
+ 
+ include $(NSBUILD)/Makefile.subdir
+diff --git a/libsvgtiny/src/colors.gperf b/libsvgtiny/src/colors.gperf
+index 96d5b9e5debf..a836787bf306 100644
+--- a/libsvgtiny/src/colors.gperf
 b/libsvgtiny/src/colors.gperf
+@@ -17,14 +17,6 @@
+ #include "svgtiny.h"
+ #include "svgtiny_internal.h"
+ 
+-/* This unusual define shennanigan is to try and prevent the gperf
+- * generated function from being inlined.  This is pointless given
+- * it (a) is in a separate .c file and (b) has external linkage.
+- */
+-#ifdef __inline
+-#undef __inline
+-#define __inline
+-#endif
+ %}
+ 
+ struct svgtiny_named_color;
+diff --git a/libsvgtiny/src/svgtiny.c b/libsvgtiny/src/svgtiny.c
+index 4661a58a2dff..bbefb888a263 100644
+--- a/libsvgtiny/src/svgtiny.c
 b/libsvgtiny/src/svgtiny.c
+@@ -20,6 +20,9 @@
+ #include "svgtiny.h"
+ #include "svgtiny_internal.h"
+ 
++/* Source file generated by `gperf`. */
++#include "autogenerated_colors.c"
++
+ #ifndef M_PI
+ #define M_PI		3.14159265358979323846
+ #endif
+diff --git a/libsvgtiny/src/svgtiny_internal.h b/libsvgtiny/src/svgtiny_internal.h
+index 158d23059c60..6bf5d64d9927 100644
+--- 

Bug#904054: ITP: cccolutils -- Python Kerberos Credential Cache Collection Utilities

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: cccolutils
  Version : 1.4
  Upstream Author : https://pagure.io/cccolutils
* URL : Patrick Uiterwijk 
* License : GPL-2+
  Programming Lang: Python
  Description : Python Kerberos Credential Cache Collection Utilities

 This module provides Kerberos 5 credential cache collection utilities
 for Python 2.6+ and 3.
 .
 When a user authenticates to a Kerberos realm (eg. with kinit), the user
 has a short-lived credential in a cache (view it with klist).
 .
 You can use this cccolutils module to easily determine if the user has
 any valid Kerberos credentials, or what the username is for a particular
 Kerberos realm.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#903776: Kernel 4.9.110-1 sit: non-ECT warnings

[Ben Hutchings]

Control: tag -1 - moreinfo

On Wed, 2018-07-18 at 22:31 +0200, Thomas Leuxner wrote:
> * Ben Hutchings  2018.07.17 22:52:
> 
> > > Jul 14 12:46:18 edi kernel: [   29.601249] sit: IPv6, IPv4 and MPLS over 
> > > IPv4 tunneling driver
> > > Jul 14 12:46:24 edi kernel: [   35.920488] sit: non-ECT from 238.163.0.0 
> > > with TOS=0x2
> > > Jul 14 12:46:24 edi kernel: [   35.956189] sit: non-ECT from 238.163.0.0 
> > > with TOS=0x2
> > > Jul 14 12:46:24 edi kernel: [   35.980514] sit: non-ECT from 238.163.0.0 
> > > with TOS=0x2
> > > Jul 14 12:46:25 edi kernel: [   36.207554] sit: non-ECT from 0.12.0.0 
> > > with TOS=0xb
> > > Jul 14 12:46:25 edi kernel: [   36.230568] sit: non-ECT from 0.12.0.0 
> > > with TOS=0x6
> > > Jul 14 12:46:25 edi kernel: [   36.413928] sit: non-ECT from 0.12.0.0 
> > > with TOS=0x6
> > > Jul 14 12:46:25 edi kernel: [   36.437173] sit: non-ECT from 0.12.0.0 
> > > with TOS=0x6#
> > 
> > I con't see any changes in the sit driver's receive path since the
> > previous upstream version (4.9.88), and we don't have any Debian-
> > specific patches for it, so I don't think this is the result of a
> > regression.
> > 
> > Is it possible that the network configuration applied after reboot is
> > not the same as you had applied previously?
> 
> Hi,
> 
> the network configuration hasn't changed.
>  
> > The sit module has a module parameter (log_ecn_error) that controls
> > this log message.  Perhaps that was set to 0/N previously?
> 
> I could mitigate the noise by applying:
> 
> echo N > /sys/module/sit/parameters/log_ecn_error
> 
> So you may be right, maybe the default has changed?

No, I don't believe the default has changed.  I was suggesting that
perhaps that parameter had been changed on this system before the
reboot.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky



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

Bug#904053: janest-core-extended: FTBFS (missing build-dep libbin-prot-camlp4-dev)

[Ralf Treinen]

Source: janest-core-extended
Version: 113.00.00-2
Severity: serious
User: trei...@debian.org
Usertags:edos-uninstallable

Hi, janest-core-extended build-depends on libbin-prot-camlp4-dev which
is no longer build by the sid version of src:bin-prot.

-Ralf.

Bug#904052: ffmpeg: FTBFS on hurd-i386: wrong value for --target-os at configure

[Pino Toscano]

Source: ffmpeg
Version: 7:4.0-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

ffmpeg fails to build on hurd-i386 [1].

Since version 7:4.0-3 (commit d3d378eb963734f2d330754300a63eb440f2d676
in the packaging Git) --target-os is passed in all the cases to
configure, using $DEB_HOST_ARCH_OS as value.  The problem is that
configure expects for --target-os a (lowercase) value among the
possible ones returned by `uname -s`, which is "GNU" for Hurd.  OTOH,
$DEB_HOST_ARCH for hurd-* archs is "hurd", and thus configure fails
with "Unknown OS".

Attached there is a patch to use a custom variable for --target-os,
using the mapping needed (so far for hurd-* only).

[1] 
https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=hurd-i386=7%3A4.0.1-2=1531923258=0

Thanks,
-- 
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,13 @@ DEB_REVISION := $(word 2, $(subst -, ,$(
 # sets DEB_HOST_* variables
 include /usr/share/dpkg/architecture.mk
 
+# Set the right target OS
+ifeq ($(DEB_HOST_ARCH_OS),hurd)
+   TARGET_OS = gnu
+else
+   TARGET_OS = $(DEB_HOST_ARCH_OS)
+endif
+
 # Ubuntu ld adds -Bsymbolic-functions by default, but that prevents FFmpeg 
from building.
 export DEB_LDFLAGS_MAINT_STRIP=-Wl,-Bsymbolic-functions
 
@@ -46,7 +53,7 @@ CONFIG := --prefix=/usr \
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
--incdir=/usr/include/$(DEB_HOST_MULTIARCH) \
--arch=$(DEB_HOST_ARCH_CPU) \
-   --target-os=$(DEB_HOST_ARCH_OS) \
+   --target-os=$(TARGET_OS) \
--enable-gpl \
--disable-stripping \
--enable-avresample --disable-filter=resample \

Bug#885852: [sparc64] klibc-utils (2.0.4-10) regression, sigserv with fstype

[John Paul Adrian Glaubitz]

Hello!

Could we have the current version of the patch applied "as is" even
though it does not meet the quality standards yet?

Currently, klibc-utils is completely b0rked on sparc64 and anyone
dist-upgrading their sparc64 machine will immediately break the
machine upon next reboot.

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#904051: mutt: CVE-2018-14362 CVE-2018-14359 CVE-2018-14358 CVE-2018-14357 CVE-2018-14356 CVE-2018-14355 CVE-2018-14354 CVE-2018-14353 CVE-2018-14352 CVE-2018-14351 CVE-2018-14350 CVE-2018-14349

[Salvatore Bonaccorso]

Source: mutt
Version: 1.7.2-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerabilities were published for mutt.

CVE-2018-14362[0]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. pop.c does not forbid characters that may have unsafe
| interaction with message-cache pathnames, as demonstrated by a '/'
| character.

CVE-2018-14359[1]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. They have a buffer overflow via base64 data.

CVE-2018-14358[2]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. imap/message.c has a stack-based buffer overflow for a
| FETCH response with a long RFC822.SIZE field.

CVE-2018-14357[3]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. They allow remote IMAP servers to execute arbitrary
| commands via backquote characters, related to the mailboxes command
| associated with an automatic subscription.

CVE-2018-14356[4]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. pop.c mishandles a zero-length UID.

CVE-2018-14355[5]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. imap/util.c mishandles ".." directory traversal in a
| mailbox name.

CVE-2018-14354[6]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. They allow remote IMAP servers to execute arbitrary
| commands via backquote characters, related to the mailboxes command
| associated with a manual subscription or unsubscription.

CVE-2018-14353[7]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. imap_quote_string in imap/util.c has an integer underflow.

CVE-2018-14352[8]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. imap_quote_string in imap/util.c does not leave room for
| quote characters, leading to a stack-based buffer overflow.

CVE-2018-14351[9]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. imap/command.c mishandles a long IMAP status mailbox
| literal count size.

CVE-2018-14350[10]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. imap/message.c has a stack-based buffer overflow for a
| FETCH response with a long INTERNALDATE field.

CVE-2018-14349[11]:
| An issue was discovered in Mutt before 1.10.1 and NeoMutt before
| 2018-07-16. imap/command.c mishandles a NO response without a message.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-14362
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14362
[1] https://security-tracker.debian.org/tracker/CVE-2018-14359
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14359
[2] https://security-tracker.debian.org/tracker/CVE-2018-14358
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14358
[3] https://security-tracker.debian.org/tracker/CVE-2018-14357
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14357
[4] https://security-tracker.debian.org/tracker/CVE-2018-14356
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14356
[5] https://security-tracker.debian.org/tracker/CVE-2018-14355
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14355
[6] https://security-tracker.debian.org/tracker/CVE-2018-14354
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14354
[7] https://security-tracker.debian.org/tracker/CVE-2018-14353
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14353
[8] https://security-tracker.debian.org/tracker/CVE-2018-14352
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14352
[9] https://security-tracker.debian.org/tracker/CVE-2018-14351
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14351
[10] https://security-tracker.debian.org/tracker/CVE-2018-14350
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14350
[11] https://security-tracker.debian.org/tracker/CVE-2018-14349
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14349

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#903996: [Pkg-utopia-maintainers] Bug#903996: network-manager-config-connectivity-debian fills up logs

[Michael Biebl]

Am 18.07.2018 um 22:40 schrieb Mark van Rossum:
> Thanks.
> Another work-around is to comment out the uri in the config file.
> I have noticed any negative side-effects so far.

Well, if you do that, you can just as well uninstall the
network-manager-config-connectivity-debian package.
It's an optional package after all (which only ships this particular
configuration file)

Michael


-- 
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#845034: Updated patch

[Ben Hutchings]

On Mon, 29 Jan 2018 09:01:57 + Kristian Klausen  
wrote:
> Hello
> 
> Attached is a updated patch, which disable the ldconfig aux-cache 
> (/var/cache/ldconfig/aux-cache), as it isn't reproducible (at least not 
> on my system).
>
> Can I in anyway help getting this merged?

I've applied Chris's patch, but I think your changes on top of that are
a step too far.

I had a look at the source for ldconfig, and here's what I found:

* The entries in /etc/ld.so.cache are sorted by, so far as I can see,
  attributes that are derived from the contents of libraries.  So this
  cache should be reproducible, and we should include it in the
  initramfs image.

* The entries in /var/cache/ldconfig/aux-cache are organised as an
  associative array, with the keys including file attributes like
  device number, inode number and inode change time.  This means it is
  not only unreproducible, but completely useless at boot time since
  the device and inode numbers of libraries will be different.

* Before writing the aux-cache file, ldconfig will try to create
  /var/cache/ldconfig if it doesn't exist, but not any of the parent
  directories.  Since mkinitramfs does not create /var/cache itself,
  the aux-cache file is only created if a hook script creates that
  directory.  I think that explains why Chris didn't find this
  problem.

Since there is no option to explicitly disable creation of the aux-
cache file, I propose to delete it ldconfig creates it.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky



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

Bug#901847: Bug#901804: autopkgtest: consider using exit status 8 ("no tests found") if every test was ignored

[Paul Gevers]

Control: forwarded -1 
https://salsa.debian.org/release-team/britney2/merge_requests/2
Control: tags -1 patch

On Tue, 19 Jun 2018 14:29:19 +0200 Paul Gevers  wrote:
> On 19-06-18 11:50, Simon McVittie wrote:
> > Is there someone who knows the britney codebase and would be willing
> > to implement that?
> 
> I do.

Done, well, a proposal.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#903765: nmu: tvc_5.0.3+dfsg-2

[Andreas Beckmann]

On 2018-07-15 10:44, Emilio Pozuelo Monfort wrote:
> On 14/07/18 14:25, Andreas Beckmann wrote:
>> nmu tvc_5.0.3+dfsg-2 . ANY . experimental . -m "Rebuild against 
>> libbamtools2.5.1."
> Scheduled.

Several builds failed with:

dpkg-checkbuilddeps: error: Unmet build dependencies: build-essential:native

which sounds like a buildd problem.
They will need a give-back after the buildds are fixed.

I assume other packages will have been affected by that as well,
therefore a bigger number of give-backs may be needed - can this be done
automatically?


Andreas

Bug#896702: lazarus-ide-1.8: Cannot install packages and rebuild the IDE

[Abou Al Montacir]

Control: merge -1 898310

On Tue, 2018-04-24 at 10:45 +0300, Александр Керножицкий wrote:
> >@team: do we know how to trigger the same action as that button from
> >the
> >command line? It would make a good autopktest I guess.
> 
> I think that this can be achieved via lazbuild. Something like `lazbuild --
> build-ide=`. Though I have not tried it.
This issue seems to be caused by Bug#898310, so I'm merging them.
-- 
Cheers,
Abou Al Montacir

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

Bug#902812: wcc FTBFS

[Axel Beckert]

Control: severity -1 serious
Control: retitle -1 wcc: uninstallable in Unstable despite BinNMU

Hi,

Raphael Hertzog wrote:
> > Does the build fail on a buildd host ? Can you confirm it is still
> > failing ? I attach the package buildinfo to this mail in order to
> > compare if needed.
> 
> Axel mentioned failed bin-nmu but it looks like the bin-nmu worked:
> https://buildd.debian.org/status/fetch.php?pkg=wcc=amd64=0.0.2%2Bdfsg-3%2Bb2=1531313043=0

Sorry, I deduced that from "uninstallable + FTBFS".

> I downgraded the bug for now.

Fair enough, but it's still uninstallable, even despite that BinNMU:

The following packages have unmet dependencies:
 wcc : Depends: libbinutils (< 2.30.90.20180711) but 2.31-1 is to be installed
E: Unable to correct problems, you have held broken packages.

So raising to RC again.

>From my point of view this means that either another BinNMU was
necessary since the previous BinNMU, but was not yet triggered, or
something else is broken in the package.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#903996: [Pkg-utopia-maintainers] Bug#903996: network-manager-config-connectivity-debian fills up logs

[Michael Biebl]

Am 18.07.2018 um 20:05 schrieb Mark van Rossum:
> Thank for looking into this.
> 
> 
>> So it is this exact same error message over and over again?
> Yes.

Ok.

>> How many of those messages do you get (per minute)?
> About 8000 per minute.
> 

So, while I can't reproduce this particular issue, there is this
particular upstream commit:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d2b4a6c35b3b2d744dcb311d7d7fd5378e7b21c7
which we might cherry-pick to alleviate the problem.

That said, I'm surprised that this connectivity check is attempted 8000
times per minute. That doesn't look right.



-- 
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#904045: enlightenment: no background image tiling

[enno]

Package: enlightenment
Version: 0.22.3-2
Severity: normal

Dear Maintainer,

I like to have my custom images tiled as background.  e17 as of 0.17.6-1.1+b1
could do it, apparently 0.22.3-2 cannot.  Or I couldn't find it in Settings.

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

Kernel: Linux 4.6.1-tapas (SMP w/4 CPU cores)
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages enlightenment depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.11.20-1
ii  dbus-x11 [dbus-session-bus]   1.11.20-1
ii  enlightenment-data0.22.3-2
ii  libasound21.1.0-1
ii  libbluetooth3 5.43-2
ii  libc6 2.27-3
ii  libecore-con1 1.20.7-6
ii  libecore-evas11.20.7-6
ii  libecore-file11.20.7-6
ii  libecore-input1   1.20.7-6
ii  libecore-ipc1 1.20.7-6
ii  libecore-x1   1.20.7-6
ii  libecore1 1.20.7-6
ii  libedje-bin   1.20.7-6
ii  libedje1  1.20.7-6
ii  libeet1   1.20.7-6
ii  libeeze1  1.20.7-6
ii  libefreet-bin 1.20.7-6
ii  libefreet1a   1.20.7-6
ii  libeina1a 1.20.7-6
ii  libeio1   1.20.7-6
ii  libelementary11.20.7-6
ii  libemile1 1.20.7-6
ii  libemotion1   1.20.7-6
ii  libevas1  1.20.7-6
ii  libevas1-engines-x1.20.7-6
ii  libpam0g  1.1.8-3.2
ii  libpulse0 8.0-2
ii  libxcb-keysyms1   0.4.0-1
ii  libxcb-shape0 1.11.1-1
ii  libxcb1   1.11.1-1

Versions of packages enlightenment recommends:
ii  eterm [x-terminal-emulator]  0.9.6-4
ii  mate-terminal [x-terminal-emulator]  1.12.1-1
pn  pm-utils 
ii  xterm [x-terminal-emulator]  324-1

enlightenment suggests no packages.

-- no debconf information

Bug#904044: RFP: openvpn3 -- Next generation OpenVPN client for Linux

[David Sommerseth]

Package: openvpn3
Version: N/A
Severity: wishlist

* Package name: openvpn3
Upstream Author: David Sommerseth 
* URL: https://github.com/OpenVPN/openvpn3-linux
* License: AGPLv3
Description: OpenVPN 3 Linux Client


I'm working on a brand new OpenVPN client on Linux.  This is a complete
rewrite of OpenVPN (in C++) but maintains backwards compatibility with most of
the OpenVPN 2.x servers which are widely adopted.

This new client uses also a very different approach than the classic OpenVPN
2.x.  It is fully based on D-Bus, which gives the possibility of proper
privilege separation out-of-the-box (no more sudo from the command line).  And
it provides a Python 3 module to easily implement your own front-end
interfaces towards the backend services.

There is still some work needed to be done on this client, it isn't 100%
production ready.  But we're getting closer to a beta release.  The current
state now is that it generally runs fine and stable, even over many days and
weeks.

More information can be found on GitHub (or GitLab, if you prefer that)

I have also provided a functional openvpn3 Copr package (for early testers on
Fedora/RHEL/CentOS) which can be found here:


I would appreciate help in getting this packaged for Debian (and implicitly
Ubuntu) - especially since I have no Debian packaging experience and my hands
are full on reaching a complete release.

Feel free to reach out for more information.  I'm also hanging out on FreeNode
(nick: dazo) and is definitely available on #openvpn and #openvpn-devel.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature

Bug#903438: RFA: asciinema -- Record and share your terminal sessions, the right way

[gustavo panizzo]

Hello Python Applications Packaging team!

I've submitted an RFA for the asciinema package, which is a pure python application, 
maybe someone from the PAP team wants to carry over. I'll be around to answer questions.



Package has no open bugs, latest upstream release has been packaged and
uploaded.  
Packaging is maintained in salsa.debian.org   

Upstream is helpful, I'd recommend to subscribe to https://github.com/asciinema/asciinema/issues/116   
if you plan to maintain the package
 
I no longer use the package, that's why i'm RFAing it



Package description:

Forget screen recording apps and blurry video. Enjoy a lightweight,   
purely text based approach to terminal recording. 

This package provides a command line recorder for asciinema.org service
or other instance of asciinema server.
  


thanks!

PS: i'm not subscribed to this list, please CC me in answers

--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Bug#903318: file misdetects some enigmail.properties s "DIY-Thermocam raw data"

[Christoph Biedl]

Control: tags 903318 pending

Daniel Kahn Gillmor wrote...

> The three attached files are lang/es-ES/enigmail.properties,
> lang/ru/enigmail.properties and lang/zh-CN/enigmail.properties.  They
> are taken from the enigmail 2.0.7 sources.
>
> /usr/bin/file identifies es-ES correctly, but fails to properly
> identify the other two:
>
> lang/es-ES/enigmail.properties: UTF-8 Unicode text, with very long lines
> lang/ru/enigmail.properties:DIY-Thermocam raw data (Lepton 3.x), scale 
> 48848-47648, spot sensor temperature -0.006370, color scheme 209, 
> calibration: offset 0.00, slope 73669913552094350828797689856.00
> lang/zh-CN/enigmail.properties: DIY-Thermocam raw data (Lepton 2.x), scale 
> 44772-48054, spot sensor temperature -6898181851872274356895744.00, color 
> scheme 191, calibration: offset 1549935081339700217447888977920.00, slope 
> 72144590071929851871232.00

Well, "UTF-8 Unicode text, with very long lines" isn't the best
detection but certainly still better than the current output.

Good news: This was fixed upstream after the latest release, in commit
FILE5_33-36-g39e43a66:

| commit 39e43a669d1260f0df36f0b2e78b3012ffd5f086
| Author: Christos Zoulas 
| Date:   Sat Jun 23 16:13:15 2018 +
|
| PR/2: Hugal31: Try to improve thermocam magic

... so this will be fixed once upstream does another release.

Christoph


signature.asc
Description: PGP signature

Bug#904025: tangd-update: Produces invalid advertisement JSON

[Christoph Biedl]

tags 904025 moreinfo upstream
thanks

Roland Reichwein wrote...

> But as you can see (and verify via JSON parser, e.g., jshon), this is invalid 
> JSON.

More precisely: It's in a form of

{
"payload":"(...)",
{
"protected":"(...)",
"signature":"(...)"
}
}

but should possibly rather by

{
  "payload": "(...)",
  "protected": "(...)",
  "signature": "(...)"
}

However, I failed to reproduce the issue, can you provide a simple
example? My approach was to patch tests/adv by adding 
"jq . < $TMP/cache/default.jws" after the tangd-update invocation, but
everything is fine then.

Christoph


signature.asc
Description: PGP signature

Bug#904043: arm: Enable CONFIG_SPI_SPIDEV

[Christian Schlüter]

Package: src:linux
Version: 4.18~rc4-1~exp1
Severity: normal

Please enable CONFIG_SPI_SPIDEV, at least for arm and arm64.

-- Package-specific info:
** Version:
Linux version 4.18.0-rc4-arm64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-24)) #1 SMP Debian 4.18~rc4-1~exp1 (2018-07-12)

** Command line:
bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 
dma.dmachans=0x7f35 bcm2709.boardrev=0xa020d3 bcm2709.serial=0x87e8561a 
bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=29 
bcm2709.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:E8:56:1A 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  console=tty0 
console=ttyS1,115200 root=LABEL=root rw elevator=deadline fsck.repair=yes 
net.ifnames=0 cma=512M rootwait

** Tainted: E (8192)
 * Unsigned module has been loaded.

** Model information
Device Tree model: Raspberry Pi 3 Model B Plus Rev 1.3

** Loaded modules:
rfcomm(E)
cpufreq_userspace(E)
cpufreq_conservative(E)
cpufreq_ondemand(E)
cpufreq_powersave(E)
8021q(E)
garp(E)
mrp(E)
stp(E)
llc(E)
iptable_nat(E)
nf_nat_ipv4(E)
nf_nat(E)
iptable_mangle(E)
iptable_filter(E)
bnep(E)
nls_ascii(E)
nls_cp437(E)
vfat(E)
fat(E)
btsdio(E)
bluetooth(E)
microchip(E)
vc4(E)
snd_soc_core(E)
drbg(E)
ansi_cprng(E)
lan78xx(E)
snd_pcm_dmaengine(E)
snd_pcm(E)
ecdh_generic(E)
of_mdio(E)
snd_timer(E)
brcmfmac(E)
fixed_phy(E)
libphy(E)
brcmutil(E)
sg(E)
snd(E)
cfg80211(E)
soundcore(E)
rfkill(E)
cec(E)
drm_kms_helper(E)
drm(E)
pwm_bcm2835(E)
bcm2835_thermal(E)
bcm2835_rng(E)
rng_core(E)
bcm2835_wdt(E)
leds_gpio(E)
nf_conntrack_ipv6(E)
nf_defrag_ipv6(E)
nf_conntrack_ipv4(E)
nf_defrag_ipv4(E)
nft_reject_inet(E)
nf_reject_ipv4(E)
nf_reject_ipv6(E)
nft_reject(E)
nft_ct(E)
nf_conntrack(E)
nft_counter(E)
nft_set_bitmap(E)
nft_set_hash(E)
nft_set_rbtree(E)
nf_tables(E)
nfnetlink(E)
nfsd(E)
auth_rpcgss(E)
nfs_acl(E)
lockd(E)
grace(E)
sunrpc(E)
ip_tables(E)
x_tables(E)
autofs4(E)
ext4(E)
crc16(E)
mbcache(E)
jbd2(E)
fscrypto(E)
ecb(E)
aes_arm64(E)
sd_mod(E)
uas(E)
usb_storage(E)
scsi_mod(E)
btrfs(E)
xor(E)
zstd_decompress(E)
zstd_compress(E)
xxhash(E)
raid6_pq(E)
libcrc32c(E)
crc32c_generic(E)
dwc2(E)
udc_core(E)
sdhci_iproc(E)
usbcore(E)
sdhci_pltfm(E)
usb_common(E)
sdhci(E)
i2c_bcm2835(E)
bcm2835(E)
phy_generic(E)

** PCI devices:

** USB devices:
Bus 001 Device 004: ID 1a4a:1670 Silicon Image 
Bus 001 Device 006: ID 1058:10a8 Western Digital Technologies, Inc. Elements 
Portable (WDBUZG)
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp. 
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental')
Architecture: arm64 (aarch64)

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

Versions of packages linux-image-4.18.0-rc4-arm64-unsigned depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod25-1
ii  linux-base  4.5

Versions of packages linux-image-4.18.0-rc4-arm64-unsigned recommends:
ii  apparmor 2.12-5
ii  firmware-linux-free  3.4
ii  irqbalance   1.3.0-0.1+b1

Versions of packages linux-image-4.18.0-rc4-arm64-unsigned suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.18  

Versions of packages linux-image-4.18.0-rc4-arm64-unsigned is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120170823-1
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#904034: Finally got qcontrol working in Stretch

[Paul "TBBle" Hampson]

Just in case this bug report was unexpected, I've gotten a local backport
build working.

This was enough to get the watchdog disabled during initramfs.

However, I had to take a couple of extra steps to get it fully operational.

I created /etc/udev/rules.d/70-gpio_keys-for-systemd.rules:
ACTION=="remove", GOTO="gpio_keys_end"
SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="platform",
DRIVERS=="gpio-keys", TAG+="systemd"
LABEL="gpio_keys_end"

so that systemd knew about
dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device. Otherwise it
would timeout waiting for it when the qcontrold service was asked to start.
(This might not be necessary in Buster? I didn't try udev from
stretch-backports.)

This timeout made the install fail, although even in the failed-to-install
state, the initramfs was updated so I stopped getting the 'unexpected 0
from a125' error from the watchdog.

I also had to disable auto-generated serial agetty:

systemctl mask serial-getty@ttyS0.service

as it seemed to want to steal /dev/ttyS0 and interfere with qcontrold
startup. This is probably not a qcontrold problem per-se, but possibly
related to the systemd upgrade (I just came from Wheezy via Jessie).

The latter might be fixed by having qcontrold be required to start before
the serial-getty@ttyS0.service, so that its TS-41x lua script gets a chance
to decide if ttyS0 is for getty or for a125, and can perhaps itself ensure
that getty@ttyS0.service state is correct for the current jumper setting.

I don't know how to express that in systemd, and looking at the
systemd-getty-generator manpage [1], I think the problem is that despite
lack of a `console=` kernel command-line, the kernel log shows it taking
ttyS0 as the kernel console, and system-getty-generator is doing what it's
supposed to do there, drawing from /sys/class/tty/console/active.

Anyway... Now my dhclient exit hooks are happily updating my LCD screen
with my IP address on boot. ^_^

Bug#904042: dovecot-sieve: Failed to initialize script execution: Invalid postmaster_address

[Graham Cobb]

Package: dovecot-sieve
Version: 1:2.3.2.1-1
Severity: normal

I recently upgraded dovecot and it now fails to start sieve processing. syslog 
contains:

Error: sieve: Failed to initialize script execution: Invalid 
postmaster_address: invalid address `postmaster@' specified for the 
postmaster_address setting

The problem appears to be that the default dovecot configuration 
(/etc/dovecot/conf.d/15-lda.conf)
allows the postmaster_address setting to default. The default value is 
postmaster@%d.
Unfortunately in some contexts the domain (%d) is not known and so the 
postmaster_address
ends up with the invalid value 'postmaster@'.

This seems to have been the case for some time but does not seem to have caused 
any noticeable problems (for me, at least).
However, a recent change to dovecot-sieve seems to insist on validating that 
address when initialising sieve processing.
This causes sieve to fail, with the error shown above, even when the 
postmaster_address setting will not actually be used.
No sieve scripts at all are run, whether they rely on that setting or not.

Note: in my case, sieve is being called from dovecot-lda, which is handling 
local delivery.

The workround is to manually configure postmaster_address.

Personally I doubt the wisdom of the new validation, as it never seems to have 
caused a problem before.
I don't know if it can be removed, or if the code can be improved to correctly 
detect the domain in more cases.

But as this breaks all sieve scripts after a debian upgrade to this version 
please consider one or more of the following:

1) Add a NEWS item warning that the postmaster_address setting in 
/etc/dovecot/conf.d/15-lda.conf must be modified to specify
the domain explicitly.

2) Do magic at upgrade time to fix the setting.

3) For new installations, make sure the setting is specified correctly so that 
they will be able to start using sieve.




-- Package-specific info:

dovecot configuration
-
# 2.3.2.1 (0719df592): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.2 ()
# OS: Linux 4.15.0-2-amd64 x86_64 Debian buster/sid 
# Hostname: black.home.cobb.me.uk
protocol lmtp {
  mail_plugins = " sieve"
}
protocol lda {
  mail_plugins = " sieve"
}

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

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

Versions of packages dovecot-sieve depends on:
ii  dovecot-core  1:2.3.2.1-1
ii  libc6 2.27-3
ii  ucf   3.0038

dovecot-sieve recommends no packages.

dovecot-sieve suggests no packages.

Versions of packages dovecot-sieve is related to:
ii  dovecot-core [dovecot-common]  1:2.3.2.1-1
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.3.2.1-1
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
ii  dovecot-sieve  1:2.3.2.1-1
pn  dovecot-sqlite 

-- no debconf information

Bug#904011: tang: Missing dependency on jose

[Christoph Biedl]

tags 904011 confirmed pending
thanks

Roland Reichwein wrote...

> But missing the "jose" tool, this doesn't work. Several scripts in the
> binary package "tang" are directly calling "jose":

Ups, thanks for reporting. Will prepare another release of tang soon-ish.

Christoph


signature.asc
Description: PGP signature

Bug#903977: ITP: sbws -- Simple Bandwidth Scanner

[ju xor]

Philipp Kern:
> On 2018-07-18 18:24, ju xor wrote:
>> Philipp Kern:
>>> Should this live in some kind of tor-* namespace?
>> no
> 
> Without any rationale? :(
> 

i'm not sure what you mean, but in case it helps, here some arguments
why sbws package is not called something like tor-sbws:

- upstream is not using "tor-*" in the name
- i don't think there's a Debian policy to name packages as "tor-*" [0]
- AFAICT, the only package in Debian that is named as "tor-*" is
"tor-geoipbd", and that's a package on which "tor" itself depends on.
- "tor" itself does not depends on sbws, though sbws makes use of "tor"
- python3-stem is a library to control tor on which sbws depends, and
it's not called "tor-*"
- nyx, is a tor monitor, and is not called "tor-*"
- there're several packages called "onion*", which is not "tor-*"

Best,
ju.

[0] https://www.debian.org/doc/debian-policy/#the-package-name

Bug#902812: wcc FTBFS

[Raphael Hertzog]

Control: severity -1 important
Control: tag -1 + unreproducible

Philippe, if you don't put Sylvestre and Axel in copy, they won't get
your mail sent only to 902...@bugs.debian.org.

On Wed, 18 Jul 2018, Philippe Thierry wrote:
> I take a look at the bug you reported and I didn't managed to reproduce
> it. I've rebuilt wcc in a newly updated sid pbuilder env and the package
> was built correctly.

Same here.

> Does the build fail on a buildd host ? Can you confirm it is still
> failing ? I attach the package buildinfo to this mail in order to
> compare if needed.

Axel mentioned failed bin-nmu but it looks like the bin-nmu worked:
https://buildd.debian.org/status/fetch.php?pkg=wcc=amd64=0.0.2%2Bdfsg-3%2Bb2=1531313043=0

I downgraded the bug for now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#903389: valgrind can't read debug info from binaries built with -z separate-code

[Alessandro Ghedini]

On Wed, Jul 18, 2018 at 05:47:58PM +0200, Ansgar Burchardt wrote:
> Hi,
> 
> I can confirm that the patch referenced at [1] seems to fix the problem
> (upstream commit 64aa729bfae71561505a40c12755bd6b55bb3061).
> 
> I'll try to prepare a NMU for valgrind; maybe already this evening if I
> have time. The package isn't usable in the current state.

I'm currently travelling, so I won't be able to look at this until end of week.
NMU would be appreciated, thanks. Feel free to push to the salsa repo [0].

Cheers

[0] https://salsa.debian.org/debian/valgrind


signature.asc
Description: PGP signature

Bug#903996: [Pkg-utopia-maintainers] Bug#903996: network-manager-config-connectivity-debian fills up logs

[Michael Biebl]

Am 18.07.2018 um 00:32 schrieb Mark van Rossum:
> Package: network-manager-config-connectivity-debian
> Version: 1.12.0-5
> Severity: important
> 
> 
> Dear Maintainer,
> 
> Since the update to network-manager-config-connectivity-debian:amd64
> 1.12.0-4, and when I am connected via Wifi
> Networkmanager is rapidly filling syslog  and user.log with error
> messages of the following structure:
> 
>> NetworkManager[1126]:  [1531337424.2758] connectivity: 
> connectivity check failed: 4

So it is this exact same error message over and over again?
How many of those messages do you get (per minute)?

If you try to access http://network-test.debian.org/nm via a browser, do
you get "NetworkManager is online" ?




signature.asc
Description: OpenPGP digital signature

Bug#903931: zcat -t sometimes crashes with heap corruption

[Daniel Baumann]

tag 903931 pending
thanks

I'll remove the divertion of zcat in the next upload shortly, "fixing"
zutils zcat after that.

Regards.
Daniel

Bug#904041: wine64-development: wineserver can no longer create temporary files

[Jack]

Package: wine64-development
Version: 3.12-3
Severity: important

Dear Maintainer,

Using the latest release, wineserver dies with the following error:
wineserver: mkdir /run/user/1000/wine: No such file or directory

I presume this is related to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903622 and the associated 
patch, fixes/temporary-directory.patch

Could you please revert or fix that patch ?

Thank you for your work

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

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

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

Versions of packages wine64-development depends on:
ii  libc62.27-5
ii  libwine-development  3.12-3

Versions of packages wine64-development recommends:
ii  wine-development3.12-3
ii  wine32-development  3.12-3

Versions of packages wine64-development suggests:
pn  libwine-gecko-2.47
pn  wine64-development-preloader  

Versions of packages wine64-development is related to:
pn  fonts-wine  
ii  wine-development3.12-3
ii  wine32-development  3.12-3
ii  wine64-development  3.12-3

-- no debconf information

Bug#676653: Patch attached

[Yuriy M. Kaminskiy]

Control: tags -1 patch

Now that tor uses automatic -dbgsym, too weak dependency is not even tor 
maintainer issue (FWIW, I opened https://bugs.debian.org/903158 with 
solution).
If you install dbgsym for mismatching arch, it is useless, but don't 
break anything.
On other hand, lack of proper M-A directives really breaks things (with 
tor:amd64 on mainly-:i386 system I cannot install any of tor reverse 
dependencies, including tor-geoipdb).

Please fix this bug on tor (packaging) side.

diff -u tor-0.3.3.7/debian/control tor-0.3.3.7/debian/control
--- tor-0.3.3.7/debian/control
+++ tor-0.3.3.7/debian/control
@@ -11,6 +11,7 @@
 
 Package: tor
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, adduser, ${misc:Depends}, lsb-base
 Pre-Depends: ${misc:Pre-Depends}
 Conflicts: libssl0.9.8 (<< 0.9.8g-9)
@@ -49,6 +50,7 @@
 
 Package: tor-geoipdb
 Architecture: all
+Multi-Arch: foreign
 Priority: extra
 Depends: tor (>= ${source:Version}), ${misc:Depends}
 Replaces: tor (<< 0.2.4.8)

Bug#897801: linbox: ftbfs with GCC-8

[Juhani Numminen]

Hi,

On Fri, 04 May 2018 12:22:31 + Matthias Klose  wrote:
> Package: src:linbox
> Version: 1.4.2-5
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-8

> ../../linbox/matrix/densematrix/blas-transposed-matrix.h:74:8: error: too 
> many template-parameter-lists

There is a recent commit that mentions "too many template-parameter-lists"
https://github.com/linbox-team/linbox/commit/1a048eb


Juhani

Bug#904040: openntpd: Apparmor denies logging

[Stefano Rivera]

Package: openntpd
Version: 1:6.2p3-1
Severity: normal
Tags: patch

Can't reproduce this in a quick check in Debian, but I can see it on
Ubuntu 18.04 machines, and this patch does the trick.

AppArmor denies openntpd access to syslog:
> [1690592.258663] audit: type=1400 audit(1531921190.778:1052): 
> apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected 
> path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" 
> pid=2708 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

This seems to be a known issue with apparmor + systemd
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1373070

And the workaround is a patch like this (which has already been applied
to ntpd).

SR
diff -Nru openntpd-6.2p3/debian/apparmor-profile openntpd-6.2p3/debian/apparmor-profile
--- openntpd-6.2p3/debian/apparmor-profile	2017-10-31 17:44:20.0 -0700
+++ openntpd-6.2p3/debian/apparmor-profile	2018-07-18 10:01:06.0 -0700
@@ -1,7 +1,7 @@
 # vim:syntax=apparmor
 #include 
 
-/usr/sbin/ntpd {
+/usr/sbin/ntpd flags=(attach_disconnected) {
   #include 
   #include 
 

Bug#902812: wcc FTBFS

[Philippe Thierry]

Le 18/07/2018 à 11:46, Sylvestre Ledru a écrit :

> On 18/07/2018 10:57, Axel Beckert wrote:
>> Control: severity -1 serious
>> Control: retitle -1 wcc: FTBFS, hence failed BinNMU and now uninstallable 
>> after binutils transition
>>
>> Hi Sylvestre,
>>
>> Sylvestre Ledru wrote on 1st of July 2018:
>>> Package: wcc
>>> Severity: important
>> [...]
>>> Looks like wcc fails to build from source:
>>>
>>>
Hi Sylvestre,

I take a look at the bug you reported and I didn't managed to reproduce
it. I've rebuilt wcc in a newly updated sid pbuilder env and the package
was built correctly.
I took a look on the missing header you reported (diagnostics.h). This
header is a part of the binutils-dev package in sid, which is in the
build depends of  the package.

Does the build fail on a buildd host ? Can you confirm it is still
failing ? I attach the package buildinfo to this mail in order to
compare if needed.

Cheers,

-- 
 OPhilippe Thierry.
/Y\/  Hardened embedded systems
o#o   GPG: F889 D7F7 85CA E380 DBDA D796 99C5 4C59 C22D 06D4

Format: 1.0
Source: wcc
Binary: wcc
Architecture: amd64 source
Version: 0.0.2+dfsg-3
Checksums-Md5:
 09b0e65a612aad5e458c725f2ce6c08c 1234 wcc_0.0.2+dfsg-3.dsc
 bbd03ddeeff91812eb3bfdfb44aee5cb 460172 wcc-dbgsym_0.0.2+dfsg-3_amd64.deb
 179aacb1291d6a23ceed8de7546e12c6 156200 wcc_0.0.2+dfsg-3_amd64.deb
Checksums-Sha1:
 df2d1de2604e8ce9a446bf6672ffae8805ab6e40 1234 wcc_0.0.2+dfsg-3.dsc
 32877cf14c5f95c6702089f91696775b94c25ff6 460172 
wcc-dbgsym_0.0.2+dfsg-3_amd64.deb
 d256b96f695a95eac83e0580a51496c1f1829f86 156200 wcc_0.0.2+dfsg-3_amd64.deb
Checksums-Sha256:
 20562cad642a31f53a18ab0abc583ac5f1055c5ee759d5e243480f82a00d7733 1234 
wcc_0.0.2+dfsg-3.dsc
 14a26d981d62ff7152523f620bafa8378539e8c7c3b8935511f223c3a6cf9810 460172 
wcc-dbgsym_0.0.2+dfsg-3_amd64.deb
 e21d0ba0bdf7dd47bd8567f4980cdb78fbb92983621e7f41a0b2b41703009aa8 156200 
wcc_0.0.2+dfsg-3_amd64.deb
Build-Origin: Debian
Build-Architecture: amd64
Build-Date: Wed, 18 Jul 2018 15:53:58 +
Build-Path: /build/wcc-0.0.2+dfsg
Installed-Build-Depends:
 autoconf (= 2.69-11),
 automake (= 1:1.15.1-3.1),
 autopoint (= 0.19.8.1-6),
 autotools-dev (= 20180224.1),
 base-files (= 10.1),
 base-passwd (= 3.5.45),
 bash (= 4.4.18-3.1),
 binutils (= 2.31-1),
 binutils-common (= 2.31-1),
 binutils-dev (= 2.31-1),
 binutils-x86-64-linux-gnu (= 2.31-1),
 bsdmainutils (= 11.1.2+b1),
 bsdutils (= 1:2.32-0.1),
 build-essential (= 12.5),
 bzip2 (= 1.0.6-8.1),
 clang (= 1:6.0-41),
 clang-6.0 (= 1:6.0.1-2),
 coreutils (= 8.28-1),
 cpp (= 4:7.3.0-3),
 cpp-6 (= 6.4.0-18),
 cpp-7 (= 7.3.0-26),
 dash (= 0.5.8-2.10),
 debconf (= 1.5.67),
 debhelper (= 11.3.5),
 debianutils (= 4.8.6),
 dh-autoreconf (= 19),
 dh-strip-nondeterminism (= 0.042-1),
 diffutils (= 1:3.6-1),
 dpkg (= 1.19.0.5+b1),
 dpkg-dev (= 1.19.0.5),
 dwz (= 0.12-2),
 fdisk (= 2.32-0.1),
 file (= 1:5.33-3),
 findutils (= 4.6.0+git+20171230-2),
 g++ (= 4:7.3.0-3),
 g++-7 (= 7.3.0-26),
 gcc (= 4:7.3.0-3),
 gcc-6 (= 6.4.0-18),
 gcc-6-base (= 6.4.0-18),
 gcc-7 (= 7.3.0-26),
 gcc-7-base (= 7.3.0-26),
 gcc-8-base (= 8.1.0-11),
 gettext (= 0.19.8.1-6+b1),
 gettext-base (= 0.19.8.1-6+b1),
 grep (= 3.1-2),
 groff-base (= 1.22.3-10),
 gzip (= 1.6-5+b1),
 hostname (= 3.20),
 init-system-helpers (= 1.51),
 intltool-debian (= 0.35.0+20060710.4),
 lib32gcc1 (= 1:8.1.0-11),
 lib32stdc++6 (= 8.1.0-11),
 libacl1 (= 2.2.52-3+b1),
 libarchive-zip-perl (= 1.60-1),
 libasan3 (= 6.4.0-18),
 libasan4 (= 7.3.0-26),
 libatomic1 (= 8.1.0-11),
 libattr1 (= 1:2.4.47-2+b2),
 libaudit-common (= 1:2.8.3-1),
 libaudit1 (= 1:2.8.3-1+b1),
 libbinutils (= 2.31-1),
 libblkid1 (= 2.32-0.1),
 libbsd0 (= 0.9.1-1),
 libbz2-1.0 (= 1.0.6-8.1),
 libc-bin (= 2.27-5),
 libc-dev-bin (= 2.27-5),
 libc6 (= 2.27-5),
 libc6-dev (= 2.27-5),
 libc6-i386 (= 2.27-5),
 libcap-ng0 (= 0.7.9-1),
 libcapstone-dev (= 3.0.4-5),
 libcapstone3 (= 3.0.4-5),
 libcc1-0 (= 8.1.0-11),
 libcilkrts5 (= 7.3.0-26),
 libclang-common-6.0-dev (= 1:6.0.1-2),
 libclang1-6.0 (= 1:6.0.1-2),
 libcroco3 (= 0.6.12-2),
 libdb5.3 (= 5.3.28-13.1+b1),
 libdebconfclient0 (= 0.243),
 libdpkg-perl (= 1.19.0.5),
 libedit2 (= 3.1-20180525-1),
 libelf-dev (= 0.170-0.5),
 libelf1 (= 0.170-0.5),
 libfdisk1 (= 2.32-0.1),
 libffi6 (= 3.2.1-8),
 libfile-stripnondeterminism-perl (= 0.042-1),
 libfreetype6 (= 2.8.1-2),
 libgc1c2 (= 1:7.4.2-8.3),
 libgcc-6-dev (= 6.4.0-18),
 libgcc-7-dev (= 7.3.0-26),
 libgcc1 (= 1:8.1.0-11),
 libgcrypt20 (= 1.8.3-1),
 libgdbm-compat4 (= 1.14.1-6+b1),
 libgdbm5 (= 1.14.1-6+b1),
 libglib2.0-0 (= 2.56.1-2),
 libgmp10 (= 2:6.1.2+dfsg-3),
 libgomp1 (= 8.1.0-11),
 libgpg-error0 (= 1.32-1),
 libgraphite2-3 (= 1.3.11-2),
 libgsl-dev (= 2.5+dfsg-4),
 libgsl23 (= 2.5+dfsg-4),
 libgslcblas0 (= 2.5+dfsg-4),
 libharfbuzz0b (= 1.8.3-1),
 libiberty-dev (= 20180614-1),
 libicu-le-hb0 (= 1.0.3+git161113-5),
 libicu60 (= 60.2-6),
 libisl19 (= 0.19-1),
 libitm1 (= 8.1.0-11),
 libjsoncpp1 (= 1.7.4-3),
 libllvm6.0 (= 1:6.0.1-2),
 liblsan0 (= 8.1.0-11),
 liblua5.3-0 (= 5.3.3-1),
 

Bug#903977: ITP: sbws -- Simple Bandwidth Scanner

[Philipp Kern]

On 2018-07-18 18:24, ju xor wrote:

Philipp Kern:

Should this live in some kind of tor-* namespace?

no


Without any rationale? :(

Kind regards
Philipp Kern

Bug#903977: ITP: sbws -- Simple Bandwidth Scanner

[ju xor]

Philipp Kern:

> Should this live in some kind of tor-* namespace? 

no

> But even if not, it
> should clearly talk about Tor in both the short and long description.

ok, i'll change description by "Tor Simple Bandwidth Scanner"

Thanks!,
ju.

Bug#904038: ldns: build-depends on python3-all-dev without using

[Steve Langasek]

Package: ldns
Version: 1.7.0-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Ondrej,

In Ubuntu, we've begun the transition from python3.6 to python3.7, which in
the first stages involves enabling python3.7 as a non-default, supported
python3 version.

The ldns package build-depends on python{,3}-all-dev, but does not build for
any but the default version of python2 and python3.

Attached is the patch I've applied to Ubuntu, to change the
build-dependencies to python{,3}-dev, which avoids this package
unnecessarily being targeted for rebuilds.  You may wish to consider
applying it in Debian.

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 ldns-1.7.0/debian/control ldns-1.7.0/debian/control
--- ldns-1.7.0/debian/control   2018-02-06 07:33:00.0 -0500
+++ ldns-1.7.0/debian/control   2018-07-18 11:45:50.0 -0400
@@ -11,8 +11,8 @@
libpcap-dev,
libssl-dev (>= 1.1.0),
pkg-config,
-   python-all-dev,
-   python3-all-dev,
+   python-dev,
+   python3-dev,
swig
 Standards-Version: 3.9.8
 Section: net

Bug#904037: subversion: Symbol lookup error, Undefined symbol: apr_hash_this_key_len

[Mate Lampert]

Package: subversion
Version: 1.9.5-1+deb9u2
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation? I installed subversion on Debian 9.3 with 
its dependencies and svn is not running at all. When I start it, the following 
error message occurs:
"svn: symbol lookup error: 
/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1: undefined symbol: 
apr_hash_this_key_len"
The same thing happens on two different computers.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I did not modify anything.
   * What was the outcome of this action?
   * What outcome did you expect instead?


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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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 subversion depends on:
ii  libapr11.5.2-5
ii  libaprutil11.5.4-3
ii  libc6  2.24-11+deb9u3
ii  libldap-2.4-2  2.4.44+dfsg-5+deb9u1
ii  libsasl2-2 2.1.27~101-g0780600+dfsg-3
ii  libsvn11.9.5-1+deb9u2

subversion recommends no packages.

Versions of packages subversion suggests:
pn  db5.3-util
ii  patch 2.7.5-1+b2
pn  subversion-tools  

-- no debconf information

Bug#886258: Clarify whether or not the Standards-Version field must be present, or lower Lintian tag severity

[Bill Allombert]

On Wed, Jul 18, 2018 at 03:24:12PM +, Holger Levsen wrote:
> On Wed, Jul 18, 2018 at 08:08:55PM +0800, Sean Whitton wrote:
> > Given that it seems we have a strong project consensus on always
> > including the field, seeking seconds to make Policy reflect that:
> > 
> > > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> > > index 77ff81f..44080c9 100644
> > > --- a/policy/ch-controlfields.rst
> > > +++ b/policy/ch-controlfields.rst
> > > @@ -121,7 +121,7 @@ package) are:
> > >
> > >  -  :ref:`Build-Depends et al `
> > >
> > > --  :ref:`Standards-Version ` (recommended)
> > > +-  :ref:`Standards-Version ` (mandatory)
> > >
> > >  -  :ref:`Homepage `
> > >
> > > @@ -238,7 +238,7 @@ is described above, in :ref:`s-controlsyntax`.
> > >
> > >  -  :ref:`Dgit `
> > >
> > > --  :ref:`Standards-Version ` (recommended)
> > > +-  :ref:`Standards-Version ` (mandatory)
> > >
> > >  -  :ref:`Build-Depends et al `
> 
> seconded.

Seconded.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Bug#904036: Please move /usr/share/bash-completion/completions/vsh to libvirt-clients

[Laurent Bigonville]

Package: libvirt-daemon
Version: 4.5.0-1
Severity: normal
File: /usr/share/bash-completion/completions/vsh

Hi,

The bash completion files are now installed, that's good.

But the file is installed in libvirt-daemon package while the
executables that the completion file is working with are in the
libvirt-clients package.

Could it be possible to move the completion file to libvirt-clients
instead?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.12-5
ii  libaudit1   1:2.8.3-1+b1
ii  libavahi-client30.7-4
ii  libavahi-common30.7-4
ii  libblkid1   2.32-0.1
ii  libc6   2.27-5
ii  libcap-ng0  0.7.9-1
ii  libcurl3-gnutls 7.60.0-2
ii  libdbus-1-3 1.12.8-3
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libfuse22.9.7-1
ii  libgnutls30 3.5.19-1
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.11-2.2
ii  libparted2  3.2-21+b1
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3.1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-1
ii  libudev1239-5
ii  libvirt04.5.0-1
ii  libxen-4.8  4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
ii  libxenstore3.0  4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9
ii  libxml2 2.9.4+dfsg1-7+b1
ii  libyajl22.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b1
ii  netcat-openbsd  1.190-2
ii  qemu-kvm1:2.12+dfsg-3bigon1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-sheepdog  
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   4.5.0-1
pn  numad   

-- no debconf information

Bug#903931: [initramfs-tools-core] unmkinitramfs uses "-t" for zcat like it was a "test integrity" option (it's not and it causes crashes)

[Ben Hutchings]

Control: reassign -1 zutils
Control: severity -1 serious

On Wed, 2018-07-18 at 13:42 +, john terragon wrote:
>  The zcat man page in my system says
> 
> -t equivalent to '-vT' 
> 
> and
> -T, --show-tabs display TAB characters as '^I'
> 
> -v, --show-nonprinting use '^' and 'M-' notation, except for LF and TAB
> 
>   But apparently that zcat is a diversion by zutils and that's the one 
> crashing and causing problems. 
> gzip's zcat does indeed have a -t test option. 
> It seems a bit invasive of zutils to just take over gzip's zcat.

Yes, that's really bad.  Reassigning this again.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


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

Bug#903996: network-manager-config-connectivity-debian fills up logs

[Philipp Marek]

Package: network-manager
Version: 1.12.0-5
Followup-For: Bug #903996

Happened for me too right now.
Network-Manager is so busy that a 

# systemctl restart network-manager.service

doesn't terminate within 15 seconds; manually killing helps.

I got 652M in 4.5 minutes, along with a lot of CPU use (both 
Network-Manager and journald).



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

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

Versions of packages network-manager depends on:
ii  adduser3.117
ii  dbus   1.12.8-3
ii  libaudit1  1:2.8.3-1+b1
ii  libbluetooth3  5.49-4
ii  libc6  2.27-3
ii  libcurl3-gnutls7.60.0-2
ii  libglib2.0-0   2.56.1-2
ii  libgnutls303.5.18-1
ii  libjansson42.11-1
ii  libmm-glib01.7.990-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-5
ii  libnm0 1.12.0-5
ii  libpam-systemd 239-5
ii  libpolkit-agent-1-00.105-21
ii  libpolkit-gobject-1-0  0.105-21
ii  libpsl50.20.2-1
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0239-5
ii  libteamdctl0   1.26-1+b1
ii  libudev1   239-5
ii  libuuid1   2.32-0.1
ii  lsb-base   9.20170808
ii  policykit-10.105-21
ii  udev   239-5
ii  wpasupplicant  2:2.6-17

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.79-1
ii  iptables 1.6.2-1
ii  isc-dhcp-client  4.3.5-4
ii  modemmanager 1.7.990-1
ii  ppp  2.4.7-2+3

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

-- 

-- 

Bug#904035: tmux: segfault at 0 ip 00007f0d188b0d01 sp 00007fffe5bfb9c8 error 4 in libc-2.27.so

[Philipp Marek]

Package: tmux
Version: 2.7-1+b1
Severity: normal

tmux just crashed for me, while editing a file in neovim. About 25 windows, 
only a single one visible, nothing remarkable done at that time.

I hope that it's not reproducible; loosing all the open editors hurts quite 
a bit ;/


The other bug reports have different IPs or are for 2.6, so I'm filing 
a new bug.


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

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

Versions of packages tmux depends on:
ii  libc6   2.27-3
ii  libevent-2.1-6  2.1.8-stable-4
ii  libtinfo6   6.1+20180210-4
ii  libutempter01.1.6-3

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

-- 

Bug#903389: valgrind can't read debug info from binaries built with -z separate-code

[Ansgar Burchardt]

Hi,

I can confirm that the patch referenced at [1] seems to fix the problem
(upstream commit 64aa729bfae71561505a40c12755bd6b55bb3061).

I'll try to prepare a NMU for valgrind; maybe already this evening if I
have time. The package isn't usable in the current state.

Ansgar

  [1] https://bugs.debian.org/903581#15

Bug#903694: maybe a proper fix

[Nicolas Boulenguez]

Please consider the attached changes.

* apply the attached ada-verbose.diff
  I fail to understand why anyone ever silents errors or command lines
  nowadays.

* append the attached howto-test-path-with-cross-build to the README
  of gcc-*-cross, or more experienced advices for beginners like me.

* replace debian/patches/ada-gcc-name.diff with the attached version.
  It ensures in Osint.Program_Name that:
  * arguments breaking implicit assertions trigger an immediate failure.
  * if present in the program name, the suffix repeats the linked libgnat 
version.
  * the executed subcommand *always* carries exactly one suffix.
  It will hopefully close 903694 and friends.

  With gcc-7 in unstable, the reproducer_in_tree script called after a
  patched build works as expected for
  * 903694: all *gnatmake* recursive subcommands carry exactly one -7 suffix.
  * 856274: all *gnatchop* succeed.

I suggest that we leave the bug open as a reminder to forward the
changes once the dust has settled. Also, it would be nice to suggest
that gnatchop should now behaves like the other tools.
Description: simplifiy detection of machine and version in command name
 The previous algorithm wrongly tests "End_Of_Prefix > 1",
 which may happen even if a match has been found.
 .
 This version reports problems, and always add the suffix to ensure
 that the gcc called has the same version than the calling tool.
 .
 Log for bug 903694 carries regression tests for both bugs.
 .
 Note: for historical reasons, gnatchop carries its own version
 of the old algorithm, which seems to work in our case.
Bugs-Debian: https://bugs.debian.org/903694
Bugs-Debian: https://bugs.debian.org/856274
Author: Ludovic Brenta 
Author: Nicolas Boulenguez 

--- a/src/gcc/ada/osint.adb
+++ b/src/gcc/ada/osint.adb
@@ -2199,22 +2199,15 @@
--
 
function Program_Name (Nam : String; Prog : String) return String_Access is
-  End_Of_Prefix   : Natural := 0;
   Start_Of_Prefix : Positive := 1;
-  Start_Of_Suffix : Positive;
+  Suffix  : constant String := '-' & Gnatvsn.Library_Version;
 
begin
   --  Get the name of the current program being executed
 
   Find_Program_Name;
 
-  Start_Of_Suffix := Name_Len + 1;
-
-  --  Find the target prefix if any, for the cross compilation case.
-  --  For instance in "powerpc-elf-gcc" the target prefix is
-  --  "powerpc-elf-"
-  --  Ditto for suffix, e.g. in "gcc-4.1", the suffix is "-4.1"
-
+  --  Find directory part if any, and ignore it from now on.
   for J in reverse 1 .. Name_Len loop
  if Name_Buffer (J) = '/'
or else Name_Buffer (J) = Directory_Separator
@@ -2225,25 +2218,28 @@
  end if;
   end loop;
 
-  --  Find End_Of_Prefix
-
+  --  Find the target prefix if any, for the cross compilation case.
+  --  For instance in "powerpc-elf-gcc" the target prefix is
+  --  "powerpc-elf-"
+  --  Ditto for suffix, e.g. in "gcc-4.1", the suffix is "-4.1"
+  --  In other terms, search and replace Prog with Nam.
   for J in Start_Of_Prefix .. Name_Len - Prog'Length + 1 loop
  if Name_Buffer (J .. J + Prog'Length - 1) = Prog then
-End_Of_Prefix := J - 1;
-exit;
+
+--  If suffix is present, it must match our version.
+if J + Prog'Length < Name_Len
+  and then Name_Buffer (J + Prog'Length .. Name_Len) /= Suffix
+then
+   Fail ("Osint.Program_Name: version mismatch in Debian");
+end if;
+
+--  Require our version, as gcc default may differ.
+return new String'(Name_Buffer (Start_Of_Prefix .. J - 1)
+ & Nam & Suffix);
+
  end if;
   end loop;
-
-  if End_Of_Prefix > 1 then
- Start_Of_Suffix := End_Of_Prefix + Prog'Length + 1;
-  end if;
-
-  --  Create the new program name
-
-  return new String'
-(Name_Buffer (Start_Of_Prefix .. End_Of_Prefix)
- & Nam
- & Name_Buffer (Start_Of_Suffix .. Name_Len));
+  Fail ("Osint.Program_Name: no match. Please report to Debian.");
end Program_Name;
 
--
Description: Display subprocess command lines when building Ada.
 The log can be a page longer if it helps debugging.
Author: Nicolas Boulenguez 

--- a/src/gcc/ada/Make-generated.in
+++ b/src/gcc/ada/Make-generated.in
@@ -28,21 +28,21 @@
 	-$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/treeprs
 	$(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/treeprs/,$(notdir $^))
 	$(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/treeprs
-	(cd $(ADA_GEN_SUBDIR)/bldtools/treeprs; gnatmake -q xtreeprs ; ./xtreeprs treeprs.ads )
+	cd $(ADA_GEN_SUBDIR)/bldtools/treeprs && gnatmake -v xtreeprs && ./xtreeprs treeprs.ads
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/treeprs/treeprs.ads $(ADA_GEN_SUBDIR)/treeprs.ads
 
 $(ADA_GEN_SUBDIR)/einfo.h : $(ADA_GEN_SUBDIR)/einfo.ads 

Bug#904034: qcontrol: Please backport 0.5.5-3 or newer to stretch

[Paul Hampson]

Package: qcontrol
Version: 0.5.5-2
Severity: wishlist

Dear Maintainer,

I've just upgraded my TS-419 to Stretch, and I'm suffering the issues
fixed in #795558 (error opening /sys/class/gpio/export) [1] and
#852127 (qcontrold starts too late due to systemd changes) [2].

There was also a report on the debian-arm mailing list from 2016 [3]
which appeared to be suffering the same problem from the same upgrade,
in the second paragraph.

I'm also seeing the same "SysRq" logs from the third when I press
LCD-down, and I assume that's only because qcontrold got to the GPIO
pin too late to claim it from the watchdog I saw mentioned in the bug
reports.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795558
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852127
[3] https://lists.debian.org/debian-arm/2016/08/msg00049.html

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 4.9.0-7-marvell
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qcontrol depends on:
ii  libc62.24-11+deb9u3
ii  liblua5.1-0  5.1.5-8.1+b2
ii  udev 232-25+deb9u4

qcontrol recommends no packages.

qcontrol suggests no packages.

-- no debconf information

Bug#886398: cryptsetup doesn't correctly unmount encrypted disk

[Guilhem Moulin]

Control: tag -1 - moreinfo
Control: reassign -1 udev
Control: forcemerge 791944 -1

On Wed, 18 Jul 2018 at 16:49:36 +0200, Genomian wrote:
> If you want you can add them as fix for crypttab but idk if the latest
> udev update solves this issue

#791944 is still open, at least.  (And the shutdown process was still
affected when I last checked — about 2 weeks ago — with a clean sid VM.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#900556: owncloud-client: Won't store passwords reporting failed to execute program org.kde.kwalletd

[Sandro Knauß]

Control: reassign -1  src:qtkeychain   0.7.0-3
Control: affects -1 src:owncloud-client

Hey,

the issue is inside qtkeychain and not inside owncloud-client.

sandro

--
On Mittwoch, 13. Juni 2018 14:24:13 CEST Olivier Berger wrote:
> Olivier Berger  writes:
> > It looks like a workaround may lie in the way qtkeychain is built, so
> > that it can use libsecret, as advised in
> > https://github.com/owncloud/client/issues/6455#issuecomment-396895579
> In the meantime, #866308 may be blocking this, AFAICS.
> 
> Just wild guessing, overall.




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

Bug#886258: Clarify whether or not the Standards-Version field must be present, or lower Lintian tag severity

[Holger Levsen]

On Wed, Jul 18, 2018 at 08:08:55PM +0800, Sean Whitton wrote:
> Given that it seems we have a strong project consensus on always
> including the field, seeking seconds to make Policy reflect that:
> 
> > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> > index 77ff81f..44080c9 100644
> > --- a/policy/ch-controlfields.rst
> > +++ b/policy/ch-controlfields.rst
> > @@ -121,7 +121,7 @@ package) are:
> >
> >  -  :ref:`Build-Depends et al `
> >
> > --  :ref:`Standards-Version ` (recommended)
> > +-  :ref:`Standards-Version ` (mandatory)
> >
> >  -  :ref:`Homepage `
> >
> > @@ -238,7 +238,7 @@ is described above, in :ref:`s-controlsyntax`.
> >
> >  -  :ref:`Dgit `
> >
> > --  :ref:`Standards-Version ` (recommended)
> > +-  :ref:`Standards-Version ` (mandatory)
> >
> >  -  :ref:`Build-Depends et al `

seconded.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#904015: RFS: libhinawa/1.0.0-1

[Adam Borowski]

On Wed, Jul 18, 2018 at 10:44:46PM +0900, Kentaro Hayashi wrote:
> On Wed, 18 Jul 2018 14:16:32 +0200
> Adam Borowski  wrote:
> 
> > On Wed, Jul 18, 2018 at 06:32:57PM +0900, Kentaro Hayashi wrote:
> > >  * Package name: libhinawa
> > >Version : 1.0.0-1
> > > 
> > > It builds those binary packages:
> > > 
> > >  gir1.2-hinawa-1.0 - GObjet introspection data for libhinawa1
> >gir1.2-hinawa-2.0 actually
> 
> Oh, I've missed it.
> As you pointed out, it should be -2.0.

What really counts is the actual state, not a bit of documentation.  I
raised this issue only because (a bit too late) noticed this transition
might possibly be not what you intended.  It's good to hear it was.

> > One notable change in the upstream tarball is that usual licensing files
> > have just been removed.  The meson build file describes the license as
> > LGPL-2.1+ and sources have SPDX identifiers, though.
> > 
> > As for change to gir1.2-hinawa-2.0 -- I noticed it when debdiffing binaries,
> > but dismissed it as a part of the package bump (there's a trip through NEW
> > anyway).  Only after uploading, when responding to this bug, I noticed that
> > this mismatches what you wrote in the RFS.  Thus, if the gir bump was not
> > intentional, please request a REJECT on #debian-ftp (or via mail).
> > 
> > The package has been uploaded as-is and is in NEW.
> 
> gir bump was intentional, but I had missed to describe it into d/changelog.

No pressing need to amend the changelog, I'd say.

> I'll fix also license issue as 1.0.0-2 after 1.0.0-1 is accepted.

The license is fine, it's just that the removal of centralized license info
upstream might raise the ftpmasters' eyebrows.


Meow.
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#903979: Parse::Yapp non-deterministic output problem solved

[gregor herrmann]

On Wed, 18 Jul 2018 10:40:43 +0300, Andrius Merkys wrote:

> > Oh, I've never seen that tag in the wild :)
> > (Maybe "pending" what be more typical.)
> my bad; from the definition of "pending" ("an upload will be made
> soon") I got an impression that only maintainers can claim that :)

No problem; and: you're part of the collective maintainer called
Debian Perl Group :)
 
> > I can take a look in the evening, if noone beats me to it.
> Thanks!

Done, and a few notes added to d/changelog, as usual.
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature