Bug#841386: libc6: perror() changes orientation of non-oriented stderr when it is redirected

[Igor Liferenko]

Package: libc6
Version: 2.24-3
Severity: important
Tags: patch

Dear Maintainer,

This bug can be seen by compiling the following program and then running

$ ./a.out 2>/dev/null

The output is

initial fwide: 0
fwide: -1

The attached patch fixes this, so that the output becomes

initial fwide: 0
fwide: 0


#include 
#include 
#include 
int main(void)
{
  printf("initial fwide: %d\n", fwide(stderr, 0));
  errno = EINVAL;
  perror(""); /* note, that prior to this call stderr was not oriented */
  printf("fwide: %d\n", fwide(stderr, 0));
  return 0;
}

Cheers,
Igor

P.S. I posted a https://sourceware.org/bugzilla/show_bug.cgi?id=20677;>bugreport to 
upstream
I can only guess why this 100% *small* bug has not been fixed ...

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

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

Versions of packages libc6 depends on:
ii  libgcc1  1:6.2.0-6

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.59
pn  glibc-doc  
ii  libc-l10n  2.24-3
ii  locales2.24-3

-- debconf information excluded
diff -ur glibc-2.24.orig/stdio-common/perror.c glibc-2.24/stdio-common/perror.c
--- glibc-2.24.orig/stdio-common/perror.c	2016-08-02 09:01:36.0 +0700
+++ glibc-2.24/stdio-common/perror.c	2016-10-18 08:59:48.996440346 +0700
@@ -22,9 +22,15 @@
 #include 
 #include "libioP.h"
 
-static void
-perror_internal (FILE *fp, const char *s, int errnum)
+/* Print a line on stderr consisting of the text in S, a colon, a space,
+   a message describing the meaning of the contents of `errno' and a newline.
+   If S is NULL or "", the colon and space are omitted.  */
+void
+perror (const char *s)
 {
+  int errnum = errno;
+  int fd = -1;
+
   char buf[1024];
   const char *colon;
   const char *errstring;
@@ -36,48 +42,30 @@
 
   errstring = __strerror_r (errnum, buf, sizeof buf);
 
-  (void) __fxprintf (fp, "%s%s%s\n", s, colon, errstring);
-}
-
-
-/* Print a line on stderr consisting of the text in S, a colon, a space,
-   a message describing the meaning of the contents of `errno' and a newline.
-   If S is NULL or "", the colon and space are omitted.  */
-void
-perror (const char *s)
-{
-  int errnum = errno;
-  FILE *fp;
-  int fd = -1;
-
-
   /* The standard says that 'perror' must not change the orientation
  of the stream.  What is supposed to happen when the stream isn't
- oriented yet?  In this case we'll create a new stream which is
- using the same underlying file descriptor.  */
-  if (__builtin_expect (_IO_fwide (stderr, 0) != 0, 1)
-  || (fd = __fileno (stderr)) == -1
-  || (fd = __dup (fd)) == -1
-  || (fp = fdopen (fd, "w+")) == NULL)
-{
-  if (__glibc_unlikely (fd != -1))
-	__close (fd);
+ oriented yet?  In this case we'll write directly to the same
+ underlying file descriptor.
 
-  /* Use standard error as is.  */
-  perror_internal (stderr, s, errnum);
-}
+ TODO: implement this feature for streams which are not backed by a POSIX
+ file descriptor (e.g., fopencookie and fmemopen).  */
+
+  if (__builtin_expect (_IO_fwide (stderr, 0) != 0, 1)
+  || (fd = __fileno (stderr)) == -1)
+/* Use standard error as is.  */
+(void) __fxprintf (stderr, "%s%s%s\n", s, colon, errstring);
   else
 {
-  /* We don't have to do any special hacks regarding the file
-	 position.  Since the stderr stream wasn't used so far we just
-	 write to the descriptor.  */
-  perror_internal (fp, s, errnum);
-
-  if (_IO_ferror_unlocked (fp))
-	stderr->_flags |= _IO_ERR_SEEN;
-
-  /* Close the stream.  */
-  fclose (fp);
+  /* Streams without orientation have never had any output directed at
+ them, so they are definitely still in the initial shift state with an
+ empty buffer (if the stream is buffered). Thus, in the case when
+ stderr has no orientation, we may safely use "__write", considering
+ the fact that "__write" has no internal buffer.  */
+
+  __write(fd, s, strlen(s));
+  __write(fd, colon, strlen(colon));
+  __write(fd, errstring, strlen(errstring));
+  __write(fd, "\n", 1);
 }
 }
 libc_hidden_def (perror)

Bug#841385: golang-go does not participate in alternatives, gccgo-6 stomps /usr/bin/go

[Dustin L. Howett]

Package: golang-go
Version: 2:1.7~1
Severity: important

Installing gccgo-6=6.2.0-6 after golang-go=2:1.7~1 triggers an
update-alternatives that replaces /usr/bin/go with a symbolic link to
/etc/alternatives/go.

It looks like the fix for #840190 did not coordinate with an update to
golang-go that integrates with the alternatives system.

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

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

Versions of packages golang-go depends on:
ii  golang-1.7-go  1.7.3-1
ii  golang-src 2:1.7~1

golang-go recommends no packages.

golang-go suggests no packages.

-- no debconf information

Bug#841375: [pkg-go] Bug#841375: RFS: golang-gopkg-square-go-jose.v1/1.1.0-1~bpo8+1

[Potter, Tim (HPE Linux Support)]

On 20 Oct 2016, at 2:33 PM, Peter Colberg  wrote:
> 
> Hi Tim,
> 
> On Thu, Oct 20, 2016 at 03:25:12AM +, Potter, Tim (HPE Linux Support) 
> wrote:
>> Hi Peter.  I can sponsor the uploads for this and the other packages to 
>> jessie-backports
>> for you.  I'm in the middle of doing a large batch of uploads of this type 
>> am happy to
>> bundle them up with mine.
> 
> That would be great!

I just read the message a bit more closely, and you mention you have the 
backport ACL
already.  I just checked the PTS and you have the DM bit set for that package.  
Feel free to
upload it yourself to backports without having to go through anyone else.

I don't think that any special sponsorship should be required in this case, 
especially if you are
already an uploader (and primary author) for the package.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#841274: [Pkg-javascript-devel] Bug#841274: node-define-property: FTBFS: Error: Cannot find module 'wrappy'

[Sruthi Chandran]

control: reassign -1 node-once

Its caused by node-once missing dependency on node-wrappy
>   make[1]: Entering directory 
> '/home/lamby/temp/cdt.20161019103506.HYMipgpTLB.db.node-define-property/node-define-property-0.2.5'
>   mocha
>   module.js:327
>   throw err;
>   ^
>   
>   Error: Cannot find module 'wrappy'
>   at Function.Module._resolveFilename (module.js:325:15)
>   at Function.Module._load (module.js:276:25)
>   at Module.require (module.js:353:17)
>   at require (internal/module.js:12:17)
>   at Object. (/usr/lib/nodejs/once.js:1:76)
>   at Module._compile (module.js:409:26)
>   at Object.Module._extensions..js (module.js:416:10)
>   at Module.load (module.js:343:32)
>   at Function.Module._load (module.js:300:12)
>   at Module.require (module.js:353:17)
>   debian/rules:13: recipe for target 'override_dh_auto_test' failed
>   make[1]: *** [override_dh_auto_test] Error 1
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20161019103506.HYMipgpTLB.db.node-define-property/node-define-property-0.2.5'
>   debian/rules:8: recipe for target 'build' failed
>   make: *** [build] Error 2
>
>   […]
>

Bug#841383: dgit: splitbrain push fails if package was previously pushed without splitbrain

[Sean Whitton]

Package: dgit
Version: 2.3
Severity: normal

classic-theme-restorer is maintained in a team gbp repository.  It
didn't have any quilt patches before, so I'd made an upload using dgit.
I just added a new quilt patch, and now I can't upload with --quilt=gbp.

hephaestus ~/src/classic-theme-restorer % dgit --quilt=gbp push
canonical suite name for unstable is sid
warning: git fetch 
+refs/tags/archive/debian/*:refs/dgit-fetch/sid/tags/archive/debian/* 
+refs/tags/debian/*:refs/dgit-fetch/sid/tags/debian/* 
+refs/dgit/sid:refs/dgit-fetch/sid/dgit/sid created 
refs/dgit-fetch/sid/heads/master; this is silly, deleting it.
downloading 
http://ftp.debian.org/debian//pool/main/c/classic-theme-restorer/classic-theme-restorer_1.5.7-1.dsc...
last upload to archive specified git hash
using existing classic-theme-restorer_1.5.7.orig.tar.xz
Format `3.0 (quilt)', need to check/update patch stack
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
Use of uninitialized value $_ in pattern match (m//) at /usr/bin/dgit line 
4364.
! Push failed, while preparing your push.
! You can retry the push, after fixing the problem, if you like.

On a second try, I get slightly different output:

hephaestus ~/src/classic-theme-restorer % dgit --quilt=gbp push
canonical suite name for unstable is sid
downloading 
http://ftp.debian.org/debian//pool/main/c/classic-theme-restorer/classic-theme-restorer_1.5.7-1.dsc...
last upload to archive specified git hash
using existing classic-theme-restorer_1.5.7.orig.tar.xz
Format `3.0 (quilt)', need to check/update patch stack
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
Use of uninitialized value $_ in pattern match (m//) at /usr/bin/dgit line 
4364.
! Push failed, while preparing your push.
! You can retry the push, after fixing the problem, if you like.

`debcheckout classic-theme-restorer` will get you what I'm trying to
push, if that helps, including a pristine-tar branch.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dgit depends on:
ii  ca-certificates   20160104
ii  coreutils 8.25-2
ii  curl  7.50.1-1
ii  devscripts2.16.8
ii  dpkg-dev  1.18.10
ii  dput  0.10.3
ii  git [git-core]1:2.9.3-1
ii  git-buildpackage  0.8.4
ii  libdpkg-perl  1.18.10
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc3-3
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1~rc3-3

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.3p1-1

Versions of packages dgit suggests:
ii  sbuild  0.71.0-2

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841384: libxslt FTCBFS: unsatisfiable cross Build-Depends, forces build architecture compiler

[Helmut Grohne]

Source: libxslt
Version: 1.1.29-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libxslt fails to cross build from source, because a number of its
Build-Depends are not satisfiable or wrongly satisfied during cross
building (e.g. executing tools installed for the host architecture). It
also forces the use of the build architecture compiler leading to
failures in finding required dependencies. The attached patch fixes all
of those problems and makes a cross build succeed. Please consider
applying it.

Helmut
diff --minimal -Nru libxslt-1.1.29/debian/changelog 
libxslt-1.1.29/debian/changelog
--- libxslt-1.1.29/debian/changelog
+++ libxslt-1.1.29/debian/changelog
@@ -1,3 +1,15 @@
+libxslt (1.1.29-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Drop unsatisfiable binutils dependency: Always satisfied natively even
+  in wheezy.
++ Use cross-compatible python Build-Depends.
++ Annotate Build-Depends: perl with :any.
++ Do not pass CC=cc to configure.
+
+ -- Helmut Grohne   Tue, 20 Oct 2016 06:25:50 +0200
+
 libxslt (1.1.29-1) unstable; urgency=medium
 
   * Imported Upstream version 1.1.29 (Closes: #826446)
diff --minimal -Nru libxslt-1.1.29/debian/control libxslt-1.1.29/debian/control
--- libxslt-1.1.29/debian/control
+++ libxslt-1.1.29/debian/control
@@ -7,15 +7,15 @@
  YunQiang Su ,
 Standards-Version: 3.9.8
 Build-Depends:
- binutils (>= 2.14.90.0.7),
  debhelper (>= 9),
  dh-autoreconf,
  dh-python,
  libgcrypt11-dev,
  libxml2-dev (>= 2.6.27),
- perl,
- python-all-dbg,
- python-all-dev (>= 2.6.6-3~),
+ perl:any,
+ libpython-all-dbg,
+ python-all-dev:any (>= 2.6.6-3~),
+ libpython-all-dev (>= 2.6.6-3~),
 Homepage: http://xmlsoft.org/xslt/
 Vcs-Git: https://anonscm.debian.org/git/debian-xml-sgml/libxslt.git
 Vcs-Browser: https://anonscm.debian.org/git/debian-xml-sgml/libxslt.git
diff --minimal -Nru libxslt-1.1.29/debian/rules libxslt-1.1.29/debian/rules
--- libxslt-1.1.29/debian/rules
+++ libxslt-1.1.29/debian/rules
@@ -12,7 +12,7 @@
 LDFLAGS = `dpkg-buildflags --get LDFLAGS` -Wl,--as-needed
 CPPFLAGS = `dpkg-buildflags --get CPPFLAGS`
 
-CONFIGURE_FLAGS := --with-history CC="$(CC)" CFLAGS="$(CFLAGS)" 
CPPFLAGS="$(CPPFLAGS)"   LDFLAGS="$(LDFLAGS)" 
--cache-file="$(CURDIR)/builddir/config.cache"
+CONFIGURE_FLAGS := --with-history CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)"
   LDFLAGS="$(LDFLAGS)" --cache-file="$(CURDIR)/builddir/config.cache"
 
 TARGETS := main $(PYVERS) $(PYVERS:%=%-dbg)
 

Bug#840368: gnome-software: should depend on software-properties-gtk

[vrishab]

Package: gnome-software
Version: 3.22.0-1
Followup-For: Bug #840368

I would bump this to serious, as this a tricky problem for an end user to
figure out. Spent some time trying to figure out why 'Software sources' window
was empty ( until I bumped into
https://bugzilla.gnome.org/show_bug.cgi?id=772714 )



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

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

Versions of packages gnome-software depends on:
ii  appstream0.10.2-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gnome-software-common3.22.0-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libappstream-glib8   0.6.3-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libenchant1c2a   1.6.0-11+b1
ii  libfwupd10.7.4-2
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgnome-desktop-3-123.22.1-1
ii  libgtk-3-0   3.22.1-1
ii  libgtkspell3-3-0 3.0.9-1
ii  libgudev-1.0-0   230-3
ii  libjson-glib-1.0-0   1.2.2-1
ii  libpackagekit-glib2-18   1.1.4-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpolkit-gobject-1-00.105-16
ii  libsecret-1-00.18.5-2
ii  libsoup2.4-1 2.56.0-1
ii  libsqlite3-0 3.15.0-1
ii  packagekit   1.1.4-1

gnome-software recommends no packages.

Versions of packages gnome-software suggests:
pn  fwupd  
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-limba

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/gnome-software (from gnome-software package)

Bug#832570: Info received (Bug#832570: tex-common fails to install with fmtutil error)

[Wookey]

On 2016-10-20 03:21 +, Debian Bug Tracking System wrote:

Bit more info trying to get it installed (so I can do the work I'm supposed to 
be doing!)

sudo fmtutil --sys --no-error-if-no-engine=luajittex --all
results in:

fmtutil [INFO]: /var/lib/texmf/web2c/pdftex/mptopdf.fmt installed.
fmtutil [ERROR]: running `luatex -ini   -jobname=luatex -progname=luatex 
luatex.ini http://wookware.org/


signature.asc
Description: Digital signature

Bug#841375: [pkg-go] Bug#841375: RFS: golang-gopkg-square-go-jose.v1/1.1.0-1~bpo8+1

[Potter, Tim (HPE Linux Support)]

Hi Peter.
> On 20 Oct 2016, at 1:15 PM, Peter Colberg  wrote:
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for the initial upload of the package
> "golang-gopkg-square-go-jose.v1" to jessie-backports. The package
> is a prerequisite for acmetool, a client for Let’s Encrypt. I have
> been added to the backports ACL for subsequent maintenance.
> 
> gbp clone --debian-branch=debian/jessie-backports 
> https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-square-go-jose.v1.git

Hi Peter.  I can sponsor the uploads for this and the other packages to 
jessie-backports
for you.  I'm in the middle of doing a large batch of uploads of this type am 
happy to
bundle them up with mine.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#841375: [pkg-go] Bug#841375: RFS: golang-gopkg-square-go-jose.v1/1.1.0-1~bpo8+1

[Peter Colberg]

Hi Tim,

On Thu, Oct 20, 2016 at 03:25:12AM +, Potter, Tim (HPE Linux Support) wrote:
> Hi Peter.  I can sponsor the uploads for this and the other packages to 
> jessie-backports
> for you.  I'm in the middle of doing a large batch of uploads of this type am 
> happy to
> bundle them up with mine.

That would be great!

Peter

Bug#841372: Kerberos config update for CS.CMU.EDU

[Jeffrey Hutzelman]

On October 19, 2016 10:40:59 PM EDT, Sam Hartman  wrote:
>Your timing is dreadful.:-)

Yes.  Then again, I should have done this years ago.


>I just uploaded a new krb5-config and am not 100% sure I'll have time
>to
>get in another one for stretch before the freeze.
>I considered dropping the kdc lines and depending on SRV records for
>cs.cmu.edu, but decided that you were picky enough that you would have
>sent in an update request if you wanted one:-(

That would work, too.  The SRV records aren't going anywhere.


>I'll see what I can do.
>
>I need to wait for 2.5 to get into testing before uploading a 2.6
>because 2.5 is really needed.

Understood.  If it doesn't get done before the freeze, we'll live.  probably.  
:-)

-- Jeff

Bug#832570: tex-common fails to install with fmtutil error

[Wookey]

Date: Sat, 6 Aug 2016 22:41:55 +0900

[sorry I missed this message at the time (off on expedition, and it
doesn't seem like the BTS delivered me a mail)]

> I have again looked into this topic and couldn't find a
> reasonable explanation for now.

Well, I just went back to a clean build chroot and hit this issue
again, so an update...

> I have uploaded a new set of packages today, where several
> internal files concerning pdftexconfig.tex as weell have been
> reworked.

> Can you please do the following:
> * remove /var/lib/texmf/tex/generic/config/pdftexconfig.tex
> * install the new packages
> and then tell me what happens?

It still breaks.

I curently have installed:
(unstable-amd64)wookey@kh:~/packages$ dpkg -l | grep texlive
ii  texlive-base   2016.20160819-2  all 
 TeX Live: Essential programs and files
ii  texlive-binaries   2016.20160513.41080-6amd64   
 Binaries for TeX Live
ii  texlive-latex-base 2016.20160819-2  all 
 TeX Live: LaTeX fundamental packages
ii  texlive-latex-base-doc 2016.20160819-2  all 
 TeX Live: Documentation files for texlive-latex-base
ii  texlive-luatex 2016.20160819-2  all 
 TeX Live: LuaTeX packages

--
(unstable-amd64)wookey@kh:~/packages$ sudo apt-get install tex-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
tex-common is already the newest version (6.05).
tex-common set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 275 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up tex-common (6.05) ...
debconf: unable to initialize frontend: Dialogdebconf: (No usable dialog-like 
program is installed, so the dialog based frontend cannot be used. at 
/usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
 This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.vKSJnfzq
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):


---/tmp/fmtutil.vKSJnfzq--
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil:   /etc/texmf/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
fmtutil [INFO]: --- remaking luatex with luatex
fmtutil: running `luatex -ini   -jobname=luatex -progname=luatex luatex.ini' ...
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)  (INITEX)
 restricted system commands enabled.
(/usr/share/texlive/texmf-dist/tex/plain/config/luatex.ini
(/usr/share/texlive/texmf-dist/tex/generic/config/luatexiniconfig.tex)
(/usr/share/texlive/texmf-dist/tex/generic/config/luatex-unicode-letters.tex
loading Unicode properties)
(/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdftexconfig.tex
! Undefined control sequence.
l.6 \pdfoutput
   = 1
? 
! Emergency stop.
l.6 \pdfoutput
   = 1
!  ==> Fatal error occurred, bad output DVI file produced!
No pages of output.
Transcript written on luatex.log.
fmtutil [INFO]: --- remaking pdftex with pdftex
fmtutil: running `pdftex -ini   -jobname=pdftex -progname=pdftex 
-translate-file=cp227.tcx *pdfetex.ini' ...
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (INITEX)
 restricted \write18 enabled.
 (/usr/share/texlive/texmf-dist/web2c/cp227.tcx)
entering extended mode
(/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdftexconfig.tex)
(/usr/share/texlive/texmf-dist/tex/plain/etex/etex.src
(/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex
Preloading the plain format: codes, registers, parameters, fonts, more fonts,
macros, math definitions, output routines, hyphenation
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex
[skipping from \patterns to end-of-file...]))
(/usr/share/texlive/texmf-dist/tex/plain/etex/etexdefs.lib
Skipping module "grouptypes"; Loading module "interactionmodes";
Skipping module "nodetypes"; Skipping module "iftypes";)
(/var/lib/texmf/tex/generic/config/language.def
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex))
Augmenting the Plain TeX definitions: \tracingall;
Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone,
register allocation; extended 

Bug#840153: Should have various tutorial manpages

[Sean Whitton]

Hello Ian,

On Thu, Oct 20, 2016 at 01:37:46AM +0100, Ian Jackson wrote:
> Sean Whitton writes ("Re: Bug#840153: Should have various tutorial manpages"):
> > On Wed, Oct 19, 2016 at 09:31:28PM +0100, Ian Jackson wrote:
> > I'll ensure that I don't commit stuff that doesn't build, now that I
> > know I can submit patches by publishing a branch somewhere.  The patches
> > were ordered the way they were so that I could easily --amend the patch
> > that adds the manpage.
> 
> Aha.  Are you aware of
>   git rebase -i --autosquash
> ?

Ah, cool.  So that's what those Magit[1] options are for.

> > I don't understand the two non-trivial changes you've made to the
> > text of the manpage.  I hope you can explain further.
> 
> I think you may mean you don't agree :-).

At least (2) was a lack of understanding!

> Sure.  Would you care to add that as a commit on top of my branch ?  I
> don't really mind flail in the git history if the intervening commits
> pass the tests and don't contain garbage.
> 
> You might want to mention that if you do this check, you might as well
> use the upstream tarball rather than `git-archive'.

Done: https://git.spwhitton.name/dgit -b wip.manpages

> > (2) the removal of the advice to use --squash:
> > 
> > Could you explain why you think this was bad advice?  It ensures that
> > the bad refs are *not* pushed to dgit-repos.  I agree with your addition
> > of contact details for the relevant archive administrators.
> 
> I don't think this is a sufficiently robust way of responding to the
> discovery of harmful and/or legally dangerous objects in a public git
> history.

Yes, you're right.  Even if someone wanted to use --squash, the
blacklisting would need to be in place to prevent accidents later, so
they might as well just contact the relevant administrators.

[1] http://magit.vc/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841382: RFS: golang-github-mitchellh-go-wordwrap/0.0~git20150314.0.ad45545-2~bpo8+1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-mitchellh-go-wordwrap" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-mitchellh-go-wordwrap.git

Regards,
Peter

Bug#841381: RFS: golang-github-jmhodges-clock/1.0-2~bpo8+1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-jmhodges-clock" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-jmhodges-clock.git

Regards,
Peter

Bug#841372: Kerberos config update for CS.CMU.EDU

[Sam Hartman]

Your timing is dreadful.:-)
I just uploaded a new krb5-config and am not 100% sure I'll have time to
get in another one for stretch before the freeze.
I considered dropping the kdc lines and depending on SRV records for
cs.cmu.edu, but decided that you were picky enough that you would have
sent in an update request if you wanted one:-(

I'll see what I can do.

I need to wait for 2.5 to get into testing before uploading a 2.6
because 2.5 is really needed.

Bug#841380: RFS: golang-github-erikdubbelboer-gspt/0.0~git20160520.0.9055324-2~bpo8+1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-erikdubbelboer-gspt" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-erikdubbelboer-gspt.git

Regards,
Peter

Bug#841379: RFS: golang-github-alecthomas-units/0.0~git20151022.0.2efee85-2~bpo8+1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-alecthomas-units" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-alecthomas-units.git

Regards,
Peter

Bug#841378: RFS: golang-github-ogier-pflag/0.0~git20160129.0.45c278a-2~bpo8+1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-ogier-pflag" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-ogier-pflag.git

Regards,
Peter

Bug#841377: RFS: golang-github-peterhellberg-link/1.0.0-2~bpo8+1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-peterhellberg-link" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-peterhellberg-link.git

Regards,
Peter

Bug#841376: RFS: golang-github-satori-go.uuid/1.1.0-2~bpo8+1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-github-satori-go.uuid" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-satori-go.uuid.git

Regards,
Peter

Bug#839725: uptimed: 0.4.0+git20150923.6b22106-1 [ITA]

[gustavo panizzo]

On Wed, Oct 19, 2016 at 08:43:31PM +0200, Tobias Frost wrote:
> Hi Gustavo,
> 
> Am Mittwoch, den 19.10.2016, 14:15 +0800 schrieb gustavo panizzo:
> > On Sun, Oct 16, 2016 at 10:35:42AM +0200, Tobias Frost wrote:
> > > 
> > > Please fix the lintian error, the d/copyright and then I'll upload.
> > > The *.la can be fixed in a subsequent upload, but maybe you can
> > > include
> > > it already in the revised packages.
> > 
> > 
> > I've pushed to alioth, please take a look
> > 
> 
> Please recheck, I can't see the changes here.

sorry about that. Can you try again?

thanks!

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa


signature.asc
Description: PGP signature

Bug#841375: RFS: golang-gopkg-square-go-jose.v1/1.1.0-1~bpo8+1

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the initial upload of the package
"golang-gopkg-square-go-jose.v1" to jessie-backports. The package
is a prerequisite for acmetool, a client for Let’s Encrypt. I have
been added to the backports ACL for subsequent maintenance.

gbp clone --debian-branch=debian/jessie-backports 
https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-square-go-jose.v1.git

Regards,
Peter

Bug#841374: cf-python: FTBFS: dh: unable to load addon sphinxdoc

[Aaron M. Ucko]

Source: cf-python
Version: 1.3.2+dfsg1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of cf-python in minimal environments geared towards building
only its architecture-dependent python-cf binary package (as on the
autobuilders) have been failing:

   fakeroot debian/rules clean
  dh clean  --with python2,sphinxdoc --buildsystem=pybuild
  dh: unable to load addon sphinxdoc: Can't locate 
Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains: [...]) at (eval 
12) line 2.
  BEGIN failed--compilation aborted at (eval 12) line 2.
  
  debian/rules:11: recipe for target 'clean' failed
  make: *** [clean] Error 2

Please either conditionalize the usage of --with-sphinxdoc
appropriately or move python-sphinx from Build-Depends-Indep to
Build-Depends.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#841366: RFS: task-spooler/1.0-1

[Sean Whitton]

Dear Alexander,

Some minor comments on your changelog entries.

On Wed, Oct 19, 2016 at 11:59:31PM +0300, Alexander Inyukhin wrote:
>* New upstream version 1.0

It's superfluous to say "1.0" since the version number is two lines above.

>
>* Update patches

What do you mean?  Do you mean refresh them so they apply to the new
upstream version?  It's conventional to write "Refresh patches" in that
case.

>* Change homepage to http://viric.name/soft/ts/

Why?  Did the upstream site move?

If you write "Update homepage" it's implied that they moved it.

HTH :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841341: bd "Bad substitution" if /bin/sh is not bash

[Paulo Henrique de Lima Santana]

Hi Gerardo,

Thanks! I'm fixing it.

Best regards,

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

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

Bug#841361: bd: Typo in the package description

[Paulo Henrique de Lima Santana]

Hi Thomas,

Thanks! I'm fixing it.

Best regards,

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

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

Bug#835146: dpkg: please enable bindow hardening flag by default

[Bálint Réczey]

Hi Guillem,

For the record gcc-6/6.2.0-7 enabled bindnow for the architectures where
PIE is enabled by default. I think enabling bindnow from dpkg would be
better through the hardening flags because packages could disable it
in a nicer and already established way.

Cheers,
Balint

2016-10-10 14:06 GMT+02:00 Balint Reczey :
> Dear Guillem,
>
> On Tue, 23 Aug 2016 00:14:25 +0200 Balint Reczey  
> wrote:
> ...
>> Dear Guillem,
>>
>> As a continuation of the discussions [1][2] on debian-devel I'm
>> attaching the simple patch that implements enabling the bindnow
>> hardening flags.
>>
>> I'm continuing with the rebuild/autopkgtest tests according to
>> the Dpkg FAQ, hence the moreinfo tag.
>
> The rebuild (with PIE and bindnow enabled) resulted ~1000 FTBFS
> cases from which all seem to be related to enabling PIE by
> default [3].
>
> ~70 of the filed related bugs [4] are still open.
>
> Since the rebuild was run with tests enabled this seems to be a
> good indication that we can expect very few breakages from
> enabling bindnow by default.
>
> Running autopkgtest would need more work as AFAIK there is no
> automated method for doing it like rebuilds [5].
>
> I'm wondering if you find the autopkgtest round necessary for
> this change.
>
> Cheers,
> Balint
>
>>
>> Cheers,
>> Balint
>>
>> [1] https://lists.debian.org/debian-devel/2016/05/msg00228.html
>> [2] https://lists.debian.org/debian-devel/2016/08/msg00324.html
>
> [3] https://wiki.debian.org/Hardening/PIEByDefaultTransition
> [4] 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906=balint%40balintreczey.hu;dist=unstable
> [5] https://wiki.debian.org/qa.debian.org/ArchiveTesting

Bug#825589: nemo: flashes (desktop icons disappears/appears) on every app start

[Norbert Preining]

tag 825589 + fixed-upstream
thanks

> https://github.com/linuxmint/nemo/issues/1177

Fixed yesterday in upstream's git

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#841373: mv: cannot stat 'unpackchrome/opt/google/chrome/PepperFlash/libpepflashplayer.so': No such file or directory

[Trent W. Buck]

Package: pepperflashplugin-nonfree
Version: 1.8.1+deb8u1
Severity: critical

Install is currently failing.
Maybe the paths within the upstream deb have changed?

Here's what the postinst said:

Setting up pepperflashplugin-nonfree (1.8.1+deb8u1) ...
converted 
'http://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_54.0.2840.59-1_amd64.deb'
 (ANSI_X3.4-1968) -> 
'http://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_54.0.2840.59-1_amd64.deb'
 (UTF-8)
--2016-10-20 11:49:21--  
http://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_54.0.2840.59-1_amd64.deb
Resolving proxy (proxy)... 203.7.155.12
Connecting to proxy (proxy)|203.7.155.12|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 45527232 (43M) [application/x-debian-package]
Saving to: 
'/tmp/pepperflashplugin-nonfree.LdNEpJHj9m/google-chrome-stable_54.0.2840.59-1_amd64.deb'

 0K .. .. .. .. ..  0%  156K 
4m44s
[...]
 44400K .. .. .. .. .. 99%  444K 0s
 44450K ..100% 38.8M=60s

2016-10-20 11:50:22 (739 KB/s) - 
'/tmp/pepperflashplugin-nonfree.LdNEpJHj9m/google-chrome-stable_54.0.2840.59-1_amd64.deb'
 saved [45527232/45527232]

mv: cannot stat 
'unpackchrome/opt/google/chrome/PepperFlash/libpepflashplayer.so': No such file 
or directory
Setting up plymouth (0.9.0-9) ...


Because errors in the postinst's call to update-pepperflashplugin-nonfree 
aren't fatal,
my build scripts explicitly rerun it.  Here's the same problem:

# Work around https://bugs.debian.org/823005; also #31001
[[ -e $t/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so ]] ||
(   wget -O $t/usr/lib/pepperflashplugin-nonfree/pubkey-google.txt 
https://dl.google.com/linux/linux_signing_key.pub
chroot $t update-pepperflashplugin-nonfree -ifq )

+ [[ -e live/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so ]]
+ wget -O live/usr/lib/pepperflashplugin-nonfree/pubkey-google.txt 
https://dl.google.com/linux/linux_signing_key.pub
converted 'https://dl.google.com/linux/linux_signing_key.pub' 
(ANSI_X3.4-1968) -> 'https://dl.google.com/linux/linux_signing_key.pub' (UTF-8)
--2016-10-20 11:51:10--  https://dl.google.com/linux/linux_signing_key.pub
Resolving dl.google.com (dl.google.com)... 172.217.25.46, 
2404:6800:4006:807::200e
Connecting to dl.google.com (dl.google.com)|172.217.25.46|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5840 (5.7K) [application/octet-stream]
Saving to: 'live/usr/lib/pepperflashplugin-nonfree/pubkey-google.txt'

 0K . 100% 
1.02M=0.005s

2016-10-20 11:51:12 (1.02 MB/s) - 
'live/usr/lib/pepperflashplugin-nonfree/pubkey-google.txt' saved [5840/5840]

+ chroot live update-pepperflashplugin-nonfree -ifq
mv: cannot stat 
'unpackchrome/opt/google/chrome/PepperFlash/libpepflashplayer.so': No such file 
or directory

When I look inside the deb myself, I don't see libpepflashplayer.so:

$ dpkg -c google-chrome-stable_54.0.2840.59-1_amd64.deb | grep -F .so
-rw-r--r-- root/root   7964784 2016-10-12 15:41 
./opt/google/chrome/libwidevinecdm.so
-rw-r--r-- root/root 71984 2016-10-12 15:41 
./opt/google/chrome/libwidevinecdmadapter.so

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Control: tag -1 + confirmed

Hi Michael,

Michael Biebl wrote:
> >> Is this not happening for you?
> > 
> > Seems not, no. But then again, I'm using aptitude most of the time and
> > apt only in a few percent of all cases.
> 
> It's safe to assume that you have a /var/lib/aptitude/pkgstates.
> Can you try install a package via apt which you don't have installed yet
> and pulls in other dependencies. Say libclang-4.0-dev (which pulls in
> libclang-common-4.0-dev)

Thanks for making up a nice example which is easier for me to test.

> $ apt install libclang-4.0-dev
> $ apt-mark showauto | grep libclang-common-4.0-dev
> libclang-common-4.0-dev
> $ aptitude show libclang-common-4.0-dev | grep Auto
> Automatically installed: no
> 
> I'd be surprised if you get a different result.

I indeed get the same result. Can also be seen in my view on that
issue:

# colordiff -u <(aptitude search '~M' | awk '{print $3}') <(apt-mark showauto)
--- /proc/self/fd/112016-10-20 02:45:05.543824588 +0200
+++ /proc/self/fd/122016-10-20 02:45:05.543824588 +0200
@@ -1990,9 +1990,11 @@
 libclang-common-3.6-dev
 libclang-common-3.8-dev
 libclang-common-3.9-dev
+libclang-common-4.0-dev
 libclang1-3.6
 libclang1-3.8
 libclang1-3.9
+libclang1-4.0
 libclass-accessor-chained-perl
 libclass-accessor-classy-perl
 libclass-accessor-grouped-perl
@@ -3645,6 +3647,7 @@
 libllvm3.6v5
 libllvm3.8
 libllvm3.9
+libllvm4.0
 liblmdb0
 liblnk1
 liblo7
@@ -7254,7 +7257,7 @@
 texlive-htmlxml
 texlive-lang-african
 texlive-lang-all
--
+texlive-lang-arabic
 texlive-lang-chinese
 texlive-lang-cjk
 texlive-lang-cyrillic

(I know also know where the latter and already previously present diff
comes from: I have texlive-lang-arabic marked with "forbid-version" in
aptitude due to an RC bug in the most recent version.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://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#790803: ITP: amp -- atomistic machine-learning potentials

[Muammar El Khatib]

Hi Graham,

On Tue, Oct 18, 2016 at 05:33:42PM +0200, Graham Inggs wrote:
> Hi Muammar
>
> Sadly, this fell off my radar. :(


It's ok :).

>
> On 18 October 2016 at 17:00, Muammar El Khatib  wrote:
> > I am interested in participating in the packaging of amp. I recently
> > joined Prof. Peterson's group as postdoctoral research associate at
> > Brown, and thus I will be involved in amp (use/development). I would
> > be glad if you let me know how I can help you with.
>
> I did have a problem with relative imports when running the tests.  I
> ended up repacking the tarball and moving some of the files and
> directories into a directory named amp which seemed to improve things.

I think there are some problems related to those imports, I will take a look at
that as well from here.

>
> Is v0.4.1 the version we should be working on, or can you tag
> something more recent?
>

I discussed with Peterson and Alireza, and there is a new version on the go
(v0.5.0, maybe in a month or something). What we could do is to work on
snapshots from master (that is the development branch). What do you think?.

Are you working on a git repo available in the debian platform?, if so, could 
you
point me out to it?. I will be playing around with amp in the following days and
I could help with the packaging.

Regards,
--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 02:21 schrieb Axel Beckert:
> According to your description, I'd expect tons of differences.
> 
>> The first time /var/lib/aptitude/pkgstates is created, it inherits the
>> autobit state from the apt db, but after that, any changes apt makes are
>> no longer applied to aptitude.
>>
>> Is this not happening for you?
> 
> Seems not, no. But then again, I'm using aptitude most of the time and
> apt only in a few percent of all cases.

It's safe to assume that you have a /var/lib/aptitude/pkgstates.
Can you try install a package via apt which you don't have installed yet
and pulls in other dependencies. Say libclang-4.0-dev (which pulls in
libclang-common-4.0-dev)

$ apt install libclang-4.0-dev
$ apt-mark showauto | grep libclang-common-4.0-dev
libclang-common-4.0-dev
$ aptitude show libclang-common-4.0-dev | grep Auto
Automatically installed: no

I'd be surprised if you get a different result.


-- 
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#840153: Should have various tutorial manpages

[Ian Jackson]

Sean Whitton writes ("Re: Bug#840153: Should have various tutorial manpages"):
> On Wed, Oct 19, 2016 at 09:31:28PM +0100, Ian Jackson wrote:
> I'll ensure that I don't commit stuff that doesn't build, now that I
> know I can submit patches by publishing a branch somewhere.  The patches
> were ordered the way they were so that I could easily --amend the patch
> that adds the manpage.

Aha.  Are you aware of
  git rebase -i --autosquash
?

> I don't understand the two non-trivial changes you've made to the text
> of the manpage.  I hope you can explain further.

I think you may mean you don't agree :-).

> (1) the addition to the "initial debianisation" section:
> 
> I don't think this workflow should explicitly recommend going anywhere
> near upstream's tarballs, except in the case where upstream doesn't use
> git.
> 
> A package maintainer might have a good reason to do a consistency check
> that upstream's released tarballs match their signed tags.  To my mind,
> this is akin to all the other testing that a package maintainer
> performs, such as installing it and seeing if it segfaults.
> 
> However, the way that you have written the text suggests that that check
> is an integral part of using the merge workflow.  I don't think it
> should be.  Although it's true that you _can_ use upstream's tarball if
> it is identical to the tag, there is absolutely no need to do so.  This
> is the kind of busywork we're trying to avoid.  Just `git archive` and
> forget about it.  The gbp documentation, too, discusses the case where
> you "don't care" about the tarballs upstream releases.
> 
> I like the pointer to "When upstream releases only tarballs" for the
> purposes of performing this consistency check, though.  So I'd like to
> suggest deleting your "When upstream tags releases in git and releases
> identical tarballs" section, and instead appending the following text to
> the "When upstream tags releases in git" section:
> 
> (It is often a good idea to confirm that upstream's released
> tarballs match the release tags.  A convenient way to do this is to
> import the tarball as described in "When upstream releases only
> tarballs", using a different value for 'upstream-tag', and then use
> git-diff(1).)

Sure.  Would you care to add that as a commit on top of my branch ?  I
don't really mind flail in the git history if the intervening commits
pass the tests and don't contain garbage.

You might want to mention that if you do this check, you might as well
use the upstream tarball rather than `git-archive'.

> (2) the removal of the advice to use --squash:
> 
> Could you explain why you think this was bad advice?  It ensures that
> the bad refs are *not* pushed to dgit-repos.  I agree with your addition
> of contact details for the relevant archive administrators.

I don't think this is a sufficiently robust way of responding to the
discovery of harmful and/or legally dangerous objects in a public git
history.

If the discoverer takes your approach, these objects will remain on
their own computer, which is itself dangerous.

The objects are very likely to make their way onto the dgit git server
at some point, if only because someone binds the upstream history into
the dgit history (which one might well do without looking at it
particularly closely).  Or because someone doesn't notice some time
when they are preparing a new upstream version.

To prevent this, at the very least, the dgit git server should be
configured to reject the bad objects.  This requires administrator
intervention.

The same objects are probably already on alioth.  So someone needs to
talk to the alioth admins perhaps.

Furthermore, if there _are_ such legally dangerous in a project's git
history, then the project's upstream will probably want to know about
it too!  Ideally the whole project's git history would be rewritten by
everyone in a coordinated way, and everyone would know to wipe the bad
data from their computers.

Done properly, this all gets quite complicated, and perhaps political,
and the problem might need to not be broadcasted widely, as well.  It
might involve taking urgent legal advice.

I really don't think we as a project could leave one of our individual
contributors to deal with such a problem by themselves, as best they
can.  That would be a doing them, and everyone else, a gross
disservice.

Note that by "legally dangerous", "harmful", or whatever we are
talking about data that might get you locked up or harassed or
something.  Examples would be child sexual abuse images, bomb-making
manuals, military or diplomatic secrets, etc.

We don't mean things where the copyright licence is unclear, missing,
or widely breached, unless the copyrightholder is pursuing it or
likely to do so.  (Examples of the cases where the copyrightholder is
likely to pursue it include are proprietary commercial music
recordings - and films and TV programmes, although those are typically
much larger than you could hide in a 

Bug#840669: 181.214.51.85 dany11_01 K4VJ

[tcaruthers92]

Sent from my iPhone

> On Oct 18, 2016, at 3:43 PM, Daniel Kahn Gillmor  
> wrote:
> 
> mkuq  
>  
> Opt Out
> gthy

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi,

Michael Biebl wrote:
> > I somehow doubt that. As I see it, this either this broke only very
> > recently (after the 0.8.3 upload) or it's only happening under some
> > circumstances.
> 
> Just curious, can you reproduce the issue with the steps I outlined?

Haven't tried it yet admittedly.

> From what I can see, once /var/lib/aptitude/pkgstates exists, there is a
> complete disconnect between the autobit state of aptitude and apt.

Not in my case. A Sid amd64 desktop machine with close to 1
packages installed show nearly no difference between apt's and
aptitude's view on the autoinstalled flag:

# colordiff -u <(aptitude search '~M' | awk '{print $3}') <(apt-mark showauto)
--- /proc/self/fd/112016-10-20 02:17:28.622307073 +0200
+++ /proc/self/fd/122016-10-20 02:17:28.622307073 +0200
@@ -7254,7 +7254,7 @@
 texlive-htmlxml
 texlive-lang-african
 texlive-lang-all
--
+texlive-lang-arabic
 texlive-lang-chinese
 texlive-lang-cjk
 texlive-lang-cyrillic

According to your description, I'd expect tons of differences.

> The first time /var/lib/aptitude/pkgstates is created, it inherits the
> autobit state from the apt db, but after that, any changes apt makes are
> no longer applied to aptitude.
> 
> Is this not happening for you?

Seems not, no. But then again, I'm using aptitude most of the time and
apt only in a few percent of all cases.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://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#841311: mk-build-deps: Please mark dependencies as auto-installed

[James McCoy]

On Wed, Oct 19, 2016 at 04:30:00PM +0200, Michael Biebl wrote:
> when installing build-dependencies of a package, I usually use
> (sudo) mk-build-depends -i
> 
> All the dependencies that are installed by that command are marked as
> manually installed.

They shouldn't be.  That didn't happen with any of my recent uses of
mk-build-deps.

> As a result, removing the foo-build-deps package again, will not
> autoremove the pulled in dependencies.
> It would be nice if those were marked as auto so a
> apt autoremove can clean those up.

Just to test, I removed one of the build-deps packages I had installed
and apt told me all the dependencies could be removed.

Have you changed the install command used by mk-build-deps?

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

Bug#841143: [pkg-gnupg-maint] Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#841143: Suspected race 
in gpg1 to gpg2 conversion or agent startup"):
> can you clarify the race?  i'm afraid we've been arguing about the gnupg
> upgrade in several places and i'm happy to re-focus this particular
> ticket.

Sorry about that.  I guess I must be coming across as quite grumpy.
Please don't be discouraged.  Yes, let's refocus this bug.

> i think you're saying that if two different instances of 2.1
> concurrently try to upgrade a given 1.4.x homedir, one of them may
> intermittently fail.
> 
> Is that correct?  Do you have a narrower replication example than
> running dgit repeatedly?

I haven't tried to narrow the test case.  I'm not 100% sure that
concurrent execution of different gnupg instances is necessary.
My replication is with the dgit test suite, which does run dgit but
only in a self-contained way.

> > Can you at least make the migration work every time ?
> 
> can you help me to replicate the migration failure?  from stretch, you
> can create a GNUPGHOME with gpg1 and try to trigger parallel upgrades.
> 
> I've done:
> 
> export GNUPGHOME=$(mktemp -d)
> gpg1 --gen-key
> for x in 1 2 3 4 ; do
>echo test $x | gpg --output test$x.gpg --clearsign &
> done
> wait %1 %2 %3 %4
> 
> and it seems to work fine on my 4-core machine.
> 
> Is there a better way to replicate?

I don't know.  You could try

   sudo apt-get install dgit dgit-infrastructure devscripts debhelper
   dgit clone dgit sid
   cd dgit
   tests/using-intree tests/run-all

and then look in

   test/tmp/NAME-OF-FAILED-TEST.log

Or you could give me a version of gnupg2 which prints a better error
message or instructions for making it produce debugging output.
Currently I see, when it fails:

  gpg: starting migration from earlier GnuPG versions
  gpg: can't connect to the agent: IPC connect call failed

This doesn't say what the errno was.  (And is "IPC connect call" a
reference to connect(2) ?)

> > This is a very broad definition of "co-installable".  In practice an
> > admonition not to use gnupg1 and gnupg2 with the same ~ is going to be
> > impractical to comply with.
> 
> That's why i'm trying to help consolidate debian to only use a single
> gpg, and to support 1.4.x only for people with unusual/antique use
> cases.

In fact the other things in your mail were much more reassuring.  For
example, given the behaviour you describe, I can convert the test
suite's $GNUPGHOME once and it will work just fine with both gnupg1
and gnupg2.  If I add private keys later with gnupg2 then those won't
be visible to gnupg1, but for me that's kind of expected.

But I would like to nail the intermittent failure before I cover it up
by making the conversion happen much less often (and probably covered
by some kind of outer lock of my own)...

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 01:42 schrieb Axel Beckert:
> Hi,
> 
> Michael Biebl wrote:
>> Afaics, once /var/lib/aptitude/pkgstates exists, which it will after any
>> non-trivial use of aptitude, the sync between apt and aptitude is
>> completely broken.
> 
> I somehow doubt that. As I see it, this either this broke only very
> recently (after the 0.8.3 upload) or it's only happening under some
> circumstances.
> 

Just curious, can you reproduce the issue with the steps I outlined?

From what I can see, once /var/lib/aptitude/pkgstates exists, there is a
complete disconnect between the autobit state of aptitude and apt.

The first time /var/lib/aptitude/pkgstates is created, it inherits the
autobit state from the apt db, but after that, any changes apt makes are
no longer applied to aptitude.

Is this not happening for you?



-- 
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#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 02:12 schrieb Michael Biebl:
> Am 20.10.2016 um 01:42 schrieb Axel Beckert:
>> Hi,
>>
>> Michael Biebl wrote:
>>> Afaics, once /var/lib/aptitude/pkgstates exists, which it will after any
>>> non-trivial use of aptitude, the sync between apt and aptitude is
>>> completely broken.
>>
>> I somehow doubt that. As I see it, this either this broke only very
>> recently (after the 0.8.3 upload) or it's only happening under some
>> circumstances.
>>
> 
> Just curious, can you reproduce the issue with the steps I outlined?
> 
> From what I can see, once /var/lib/aptitude/pkgstates exists, there is a
> complete disconnect between the autobit state of aptitude and apt.
> 
> The first time /var/lib/aptitude/pkgstates is created, it inherits the
> autobit state from the apt db, but after that, any changes apt makes are
> no longer applied to aptitude.
> 
> Is this not happening for you?

In any case: thanks for your quick replies!


-- 
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#840153: Should have various tutorial manpages

[Sean Whitton]

Hello Ian,

On Wed, Oct 19, 2016 at 09:31:28PM +0100, Ian Jackson wrote:
> Sean Whitton writes ("Bug#840153: Should have various tutorial manpages"):
> > control: tag -1 +patch
> > 
> > Please find attached git-am(1)-amenable patches adding some pod2man
> > infrastructure, and dgit-maint-merge(7).
> 
> Thanks!  I really like your new manpage.

Thanks for responding to my patch submission!

> And you should add it to the Makefile in the same commit as you add
> the file, or you create a commit that doesn't build.

> BTW I'm just as happy with git branch on a server as I am with git-am
> patches.

I'll ensure that I don't commit stuff that doesn't build, now that I
know I can submit patches by publishing a branch somewhere.  The patches
were ordered the way they were so that I could easily --amend the patch
that adds the manpage.

> I have also made a few changes to the manpage, which I hope you will
> approve of.

I don't understand the two non-trivial changes you've made to the text
of the manpage.  I hope you can explain further.

(1) the addition to the "initial debianisation" section:

I don't think this workflow should explicitly recommend going anywhere
near upstream's tarballs, except in the case where upstream doesn't use
git.

A package maintainer might have a good reason to do a consistency check
that upstream's released tarballs match their signed tags.  To my mind,
this is akin to all the other testing that a package maintainer
performs, such as installing it and seeing if it segfaults.

However, the way that you have written the text suggests that that check
is an integral part of using the merge workflow.  I don't think it
should be.  Although it's true that you _can_ use upstream's tarball if
it is identical to the tag, there is absolutely no need to do so.  This
is the kind of busywork we're trying to avoid.  Just `git archive` and
forget about it.  The gbp documentation, too, discusses the case where
you "don't care" about the tarballs upstream releases.

I like the pointer to "When upstream releases only tarballs" for the
purposes of performing this consistency check, though.  So I'd like to
suggest deleting your "When upstream tags releases in git and releases
identical tarballs" section, and instead appending the following text to
the "When upstream tags releases in git" section:

(It is often a good idea to confirm that upstream's released
tarballs match the release tags.  A convenient way to do this is to
import the tarball as described in "When upstream releases only
tarballs", using a different value for 'upstream-tag', and then use
git-diff(1).)

(2) the removal of the advice to use --squash:

Could you explain why you think this was bad advice?  It ensures that
the bad refs are *not* pushed to dgit-repos.  I agree with your addition
of contact details for the relevant archive administrators.

> > (I'm keen to retain the authorship information in the actual
> > manpage, but you might not like how I've edited d/copyright, so I
> > made that a separate patch.)
> 
> Right.  I have changed this a bit.  I hope you like it.

All fine.

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#841372: Kerberos config update for CS.CMU.EDU

[Jeffrey Hutzelman]

Package: kerberos-configs
Version: 2.3
Severity: wishlist

The CS.CMU.EDU realm stanza included in krb5-config is a bit out of
date, and actually has been for some time.  We're trying to stamp out
client configuration that uses kerberos.cs.cmu.edu other than for admin
services, and it would help to get the following update applied:

OLD:
        CS.CMU.EDU = {
kdc = kerberos.cs.cmu.edu
kdc = kerberos-2.srv.cs.cmu.edu
admin_server = kerberos.cs.cmu.edu
}


NEW:
        CS.CMU.EDU = {
kdc = kerberos-1.srv.cs.cmu.edu
kdc = kerberos-2.srv.cs.cmu.edu
kdc = kerberos-3.srv.cs.cmu.edu
admin_server = kerberos.cs.cmu.edu
}

Thanks...

-- Jeff

Bug#814959: Keyboard mapping broken with Qt5 apps in TightVNC, possibly due to missing XKEYBOARD extension

[Linus Lüssing]

I stumbled over this issue with various Qt5 applications on Debian
Sid, too, and had initially reported my issue here:

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

Switching the VNC viewer does not seem to help, I tried
xtightvncviewer and krdc.

Not only the TightVNC server, but also the RealVNC one
(vnc4server package) seem to be affected. TigerVNC on the other
hand works like a charm (which is my current workaround for this
issue for now).

Noticeably, on TightVNC and RealVNC, I get this error message,
while on TigerVNC I don't:

"Qt: XKEYBOARD extension not present on the X server."

So looks like James initial investigations lead to the right
direction.

Unfortunately, this report on the Qt bugtracker indicates that it
was closed and deemed "out of scope" and that VNC servers should
implement this XKEYBOARD extension :-( :

https://bugreports.qt.io/browse/QTBUG-44938

This ticket also has some nice explanations why Qt5 has this issue
and Qt4 doesn't (e.g. the preference of libxkbcommon over xlib in
Qt5).

Regards, Linus

Bug#841081: [pkg-go] Bug#841081: RFP: golang-gopkg-dancannon-gorethink.v1 -- RethinkDB driver for Go

[Potter, Tim (HPE Linux Support)]

On 19 Oct 2016, at 7:02 PM, Guillem Jover  wrote:
> 
> Hi!
> 
> On Wed, 2016-10-19 at 01:40:02 +, Potter, Tim (HPE Linux Support) wrote:
>> On 18 Oct 2016, at 1:21 AM, Guillem Jover  wrote:
>>> Attached a working and tested packaging, where only the ITP bug number
>>> needs to be filled in the debian/changelog. The other patch is required
>>> to get the git repository back to a proper upstream version, because it
>>> was at v2 now.
>> 
>> Which repo were you looking at for the first patch?  The one at 
>> golang-gopkg-dancannon-gorethink.v1
>> was never at v2.  Maybe there was a split into v1 and v2 but that could have
>> happened before my time.
> 
> The repo I was working against was:
> 
> https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-dancannon-gorethink.v1.git
> 
> which does contain an import of the v2 branch version v2.0.1 into the
> v1.4.1 tag. Take a look at commit 1ec608b3e9473da10b35ddfa5afc40a137df6f32
> and you'll see.

Gah - I didn't look to closely at the contents and believed the tags and 
contents
of the changelog.  (-:

I ended up importing the v1.4.1 tarball rather than applying the patch so that 
the
pristine-tar and upstream branches are up to date.

>> The second patch applies just fine.  I pushed it but the remark about
>> changing the build directory to _build that Martin Ferrari made about
>> golang-dns applies here as well.  Technically it could mess up
>> multi-platform builds but I'm not aware of packages that do this.
> 
> My same reply applies here as well, I find it more pleasing to have
> the same directory regardless of the host system, because it makes it
> easier to debug, or instruct people to do so. It certainly should have
> no visible effect to the build machinery, as long as there's no need
> to explicitly point to files underneath the build directory, but I
> think it's still better. But do as you prefer, or your group policies
> dictate, I don't really mind. ;)

I left it as is.

>> I added a missing build-dependency (why does v1 of the package require v2?
>> that's weird) and added a few tweaks.
> 
> It does not depend on v2, the problem is that it *is* v2, but the
> package gets installed as v1 due to the "unmatched" XS-Go-Import-Path
> field, so go cannot find the real module and complains that it's
> missing. The reversion patch really needs to be applied. :) I guess
> having the tag point to the incorrect contents will be confusing, but
> fixing that would require rewriting history. Perhaps in this case it's
> worth it, and instead of the patch, just rebasing and force pushing
> might be better, up to you.

Fixed and uploaded to the NEW queue.


Tim.

> 
> Thanks,
> Guillem



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi,

Michael Biebl wrote:
> Afaics, once /var/lib/aptitude/pkgstates exists, which it will after any
> non-trivial use of aptitude, the sync between apt and aptitude is
> completely broken.

I somehow doubt that. As I see it, this either this broke only very
recently (after the 0.8.3 upload) or it's only happening under some
circumstances.

I'll definitely keep an eye on this during daily usage in the next
weeks...

> So I suspect basically everyone will be affected by
> this, who uses both apt and aptitude.

That's my point: I do that not that seldom. And I haven't noticed any
such issues for quite a while.

> But maybe I'm just a bit weird that I use both apt and aptitude at
> the same time :-)

It was not recommended in the past because of known syncing issues.
But they are or at least were gone for quite a while, so I'm surprised
that such an isssue is either still present or surfaced again, maybe
due to some subtle changes in apt.

(The only co-operation "issue" between apt and aptitude I see nowadays
are aptitude's scheduled actions which AFAIK work as intended, but
often confuse users which don't know about them, but use them
unintentionally, usually in aptitude's TUI.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://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#841251: gdm3: Both Nautilas & Nemo Want to Manage Desktop

[Stephen Allen]

On Wed, Oct 19, 2016 at 06:20:07PM +0200, Michael Biebl wrote:
>  Am 19.10.2016 um 01:52 schrieb Stephen Allen:
> 
> > I have both Gnome 3.22.x and Cinnamon installed. When logging in using
> > GDM3 with Gnome specifically enabled, both Nautilas and Nemo are
> > activated to manage my desktop, resulting in double overlapping icons.
> > Once I forcequit Nemo, all is well.
> 
> 
> Btw, are you sure you were starting a GNOME session?
> GNOME by default does no longer draw any icons on the desktop.

Correct, I enabled icons via Gnome-Tweak-Tool. Thank-you for reassigning
to the Cinnamon Team.

So, yes I'm sure Yours Truly is running Gnome. :-)

Bug#841143: [pkg-gnupg-maint] Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup

[Daniel Kahn Gillmor]

On Wed 2016-10-19 09:39:28 -0400, Ian Jackson wrote:
> I think this bug #841143 is about a race in this upgrade path.  Do you
> intend to investigate or fix this race ?

can you clarify the race?  i'm afraid we've been arguing about the gnupg
upgrade in several places and i'm happy to re-focus this particular
ticket.

i think you're saying that if two different instances of 2.1
concurrently try to upgrade a given 1.4.x homedir, one of them may
intermittently fail.

Is that correct?  Do you have a narrower replication example than
running dgit repeatedly?

> No, I think you misunderstand.
>
> An schroot typically shares its /home with the "outside" system.
> People often use such chroots for running newer versions of things on
> an older system, or vice versa, whenever that's needed.
>
> If I have a jessie system with a stretch chroot, and I run `gnupg' in
> the stretch chroot, gnupg's conversion will mess up my ~/.gnupg so
> that my main system does not work any more.

That's not actually the case, fwiw.  gpg in the sid chroot will import
the keys from your secring.gpg into private-keys-v1.d/, and it will
create .gpg-v21-migrated, but it will not delete secring.gpg.

however, if you subsequently create new secret keys in secring.gpg from
jessie, those keys will not be visible to 2.1.x in future connections
(since it will think the migration is already done because of
.gpg-v21-migrated -- i've filed https://bugs.gnupg.org/gnupg/issue2811
as a minor improvement on this).

if you use gpg 2.1 to modify ~/.gnupg/gpg.conf to include options that
1.4.x doesn't know about or can't handle, then all bets are off.  but
the same is true for ~/.ssh/known_hosts and any other comparable
software-maintained file, right?

Would you consider it a bug in ssh if an ecdsa entry added to
~/.ssh/known_hosts by a newer version of ssh wouldn't be read
successfully by an older version of ssh?

> Can you at least make the migration work every time ?

can you help me to replicate the migration failure?  from stretch, you
can create a GNUPGHOME with gpg1 and try to trigger parallel upgrades.

I've done:

export GNUPGHOME=$(mktemp -d)
gpg1 --gen-key
for x in 1 2 3 4 ; do
   echo test $x | gpg --output test$x.gpg --clearsign &
done
wait %1 %2 %3 %4

and it seems to work fine on my 4-core machine.

Is there a better way to replicate?

> This is a very broad definition of "co-installable".  In practice an
> admonition not to use gnupg1 and gnupg2 with the same ~ is going to be
> impractical to comply with.

That's why i'm trying to help consolidate debian to only use a single
gpg, and to support 1.4.x only for people with unusual/antique use
cases.

Thanks for helping make this change happen.

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#818232: Info received (Bug#818232: Not really a Qt5 bug it seems)

[Linus Lüssing]

Did some further tests and it seems to me that it is this issue:

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

I'll continue watching and commenting on that one then.

Spoiler: Switching to TigerVNC is a workaround for me for now (vnc4server / 
"RealVNC" seems to have the same issue as TightVNC).

Bug#841371: /usr/bin/install: should use fchown, fchmod

[Paul Szabo]

Package: coreutils
Version: 8.23-4
Severity: important
File: /usr/bin/install


The install command is vulnerable to a race condition.

If used by root to create a file in a directory writable to users or
groups other than root, then after install creates the file, the file
just created could be replaced by a symlink: then lchown() would act on
the symlink itself, and chmod() would act on the target of the symlink.

Seems it would be better for install to use fchown() and fchmod():
safer, more robust, and maybe more efficient.


Using strace shows that install does:

open("target", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
 [write content with write(4,...)] ...
fchmod(4, 0600) = 0
close(4)= 0

lchown32("target", UID, GID)= 0
chmod("target", MODE)   = 0


The last two commands should be changed into fchown() and fchmod(),
and moved to be prior to the close().


Would it help it I submitted patches?

Thanks, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.7-ckt20-pk07.18-amd64 (SMP w/32 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-2
ii  libattr1 1:2.4.47-2
ii  libc62.19-18+deb8u6
ii  libselinux1  2.3-2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#841370: nomacs: FTBFS; error with opencv 3.1

[Nobuhiro Iwamatsu]

Source: nomacs
Version: 3.4.1+dfsg-4
Severity: important
Justification: fails to build from source
Tags: patch

Dear Maintainer,

I am scheduled to transition of opencv.
This package is target to transition. I tested build with opencv 3.1.
As a result, this FTBFS with opencv 3.1.

Because from opencv 3.1,  libcvaux-dev, libhighgui-dev and libopencv-ocl-dev
are removed, we must specify the libopencv-dev instead.

Could you remove  libcvaux-dev, libhighgui-dev and libopencv-ocl-dev from B-D?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
--- a/debian/control	2016-09-28 00:14:36.0 +0900
+++ b/debian/control	2016-10-20 00:20:45.361830666 +0900
@@ -7,12 +7,9 @@
 Priority: optional
 Build-Depends: debhelper (>= 10),
cmake (>= 3.0.2),
-   libcvaux-dev,
libexiv2-dev,
-   libhighgui-dev,
liblcms2-dev,
libopencv-dev,
-   libopencv-ocl-dev,
libqt5svg5-dev,
libquazip-dev,
libraw-dev,

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 01:03 schrieb Axel Beckert:
> Hi Michael,
> 
> Michael Biebl wrote:
>> Am 20.10.2016 um 00:44 schrieb Michael Biebl:
>>> So, the complete steps to reproduce the issue:
>>> - create a fresh chroot via debootstrap
>>> - start aptitude in interactive mode, select a random, non-related
>>> package, say netbase, mark it as auto-installed via "M"

fwiw, this step can be replaced by
$ aptitude markauto netbase
or actually any other aptitude action which creates
/var/lib/aptitude/pkgstates, like installing a package via aptitude.

>> At this point, you should have /var/lib/aptitude/pkgstates
>>
>>> - exit aptitude and install the example deb via apt install ./...
>>> - then check the auto state of gobject-introspection. It will now differ
>>> between aptitude and apt.
>>>
>>> The key here is, that you need to have a /var/lib/aptitude/pkgstates
>>
>> Removing that file again:
>>
>> $ aptitude show gobject-introspection | grep Auto
>> Automatically installed: yes
>>
>> Once the pkgstates file exists, aptitude seems to no longer read the
>> autobit state from apt.
> 
> Thanks for all these details! Seems as if there are still some corner
> cases where aptitude doesn't sync the autoinstalled bit properly --
> changing an autoinstalled bit manually without any install/remove
> action seems to such a case according to your description.

Afaics, once /var/lib/aptitude/pkgstates exists, which it will after any
non-trivial use of aptitude, the sync between apt and aptitude is
completely broken. So I suspect basically everyone will be affected by
this, who uses both apt and aptitude. I wouldn't call that a corner
case. But maybe I'm just a bit weird that I use both apt and aptitude at
the same time :-)

Regards,
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#836433: [Pkg-samba-maint] Bug#836433: samba: install "hangs", synaptic more details reveals pager prompt

[Jelmer Vernooij]

On Sat, Sep 03, 2016 at 12:05:48AM -0400, F. Eugene Aumson wrote:
> Subject: samba: install "hangs", synaptic more details reveals pager prompt
> Source: samba
> Version: 2:4.2.10+dfsg-0+deb8u1
> Severity: important
> 
> Dear Maintainer,
> 
> in synaptic package manager, i did "reload", then "mark all upgrades", then
> "apply".
> 
> then i waited.  and waited.  and waited.  synaptic was taking forever to
> "apply changes".  i waited at least 20 minutes, probably 30.
> 
> then i thought "surely something is wrong," so i clicked the "show more
> details" thing in the dialog box, and the install was clearly just sitting
> still.
> 
> eventually i noticed the ":" prompt at the bottom of the "screen", and
> realized that it was sitting in a pager.  i hit 'q' and the install marched
> onward.
> 
> i expected that the install of the package could proceed withouth manual
> intervention

Samba uses debconf for any configuration questions; its maintainer
scripts are not interactive. What suggested this was caused by the
Samba package?


signature.asc
Description: PGP signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi Michael,

Michael Biebl wrote:
> Am 20.10.2016 um 00:44 schrieb Michael Biebl:
> > So, the complete steps to reproduce the issue:
> > - create a fresh chroot via debootstrap
> > - start aptitude in interactive mode, select a random, non-related
> > package, say netbase, mark it as auto-installed via "M"
> 
> At this point, you should have /var/lib/aptitude/pkgstates
> 
> > - exit aptitude and install the example deb via apt install ./...
> > - then check the auto state of gobject-introspection. It will now differ
> > between aptitude and apt.
> > 
> > The key here is, that you need to have a /var/lib/aptitude/pkgstates
> 
> Removing that file again:
> 
> $ aptitude show gobject-introspection | grep Auto
> Automatically installed: yes
> 
> Once the pkgstates file exists, aptitude seems to no longer read the
> autobit state from apt.

Thanks for all these details! Seems as if there are still some corner
cases where aptitude doesn't sync the autoinstalled bit properly --
changing an autoinstalled bit manually without any install/remove
action seems to such a case according to your description.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://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#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 00:44 schrieb Michael Biebl:
> So, the complete steps to reproduce the issue:
> - create a fresh chroot via debootstrap
> - start aptitude in interactive mode, select a random, non-related
> package, say netbase, mark it as auto-installed via "M"

At this point, you should have /var/lib/aptitude/pkgstates

> - exit aptitude and install the example deb via apt install ./...
> - then check the auto state of gobject-introspection. It will now differ
> between aptitude and apt.
> 
> The key here is, that you need to have a /var/lib/aptitude/pkgstates

Removing that file again:

$ aptitude show gobject-introspection | grep Auto
Automatically installed: yes

Once the pkgstates file exists, aptitude seems to no longer read the
autobit state from apt.

I hope with this information you are able to reproduce the issue now.

Regards,
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#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 00:23 schrieb Axel Beckert:
> I have a slight suspicion that aptitude and apt might refer to
> different architectures of gobject-introspection in this case (in
> which both might be correct, just not displaying the expected or
> multiple packages).

I don't think this is the problem. I did some further debugging, and
tried with a freshly debootstrapped sid.

Running apt install ./gtk+3.0-build-deps_3.22.1-4_amd64.deb inside that
fresh chroot did lead to

Automatically installed: yes for gobject-introspection.

I went looking what the difference between the chroot and my real system is.
Turns out I have a /var/lib/aptitude/pkgstates. This file/db was created
in the past, when I manually changed the autostate with aptitude
interactive mode.

So, the complete steps to reproduce the issue:
- create a fresh chroot via debootstrap
- start aptitude in interactive mode, select a random, non-related
package, say netbase, mark it as auto-installed via "M"
- exit aptitude and install the example deb via apt install ./...
- then check the auto state of gobject-introspection. It will now differ
between aptitude and apt.

The key here is, that you need to have a /var/lib/aptitude/pkgstates


-- 
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#841369: Wishlist: Change icon image for CQRLOG

[FanJun Kong]

Package: cqrlog
Version: 2.0.1-1
Severity: wishlist

icon file was too small 32*32, gnome-software will not display. so we
need to change size at least 64*64.

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 00:23 schrieb Axel Beckert:
> Hi Michael,
> 
> Michael Biebl wrote earlier:
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
> 
> Michael Biebl wrote:
>> As an example, after installing the example deb I attached earlier, it
>> pulls in dependencies like gobject-introspection.
>>
>> $ apt-mark showauto  | grep gobject-introspection
>> gobject-introspection
>>
>> $ aptitude show gobject-introspection  | grep Automatically
>> Automatically installed: no
> 
> Can you please send the full output of "aptitude show
> gobject-introspection" and "apt-cache policy gobject-introspection"?
> 
> I have a slight suspicion that aptitude and apt might refer to
> different architectures of gobject-introspection in this case (in
> which both might be correct, just not displaying the expected or
> multiple packages).


$ apt-cache policy gobject-introspection
gobject-introspection:
  Installed: 1.50.0-1
  Candidate: 1.50.0-1
  Version table:
 *** 1.50.0-1 500
500 http://ftp.de.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

$ aptitude show gobject-introspection
Package: gobject-introspection   
Version: 1.50.0-1
State: installed
Automatically installed: no
Priority: optional
Section: devel
Maintainer: Debian GNOME Maintainers 

Architecture: amd64
Uncompressed Size: 1448 k
Depends: libc6 (>= 2.14), libffi6 (>= 3.0.4), libgirepository-1.0-1 (= 
1.50.0-1), libglib2.0-0 (>= 2.50.0),
 python3:any, build-essential, python3-mako
Conflicts: gobject-introspection:i386
Description: Generate interface introspection data for GObject libraries
 GObject Introspection is a project for providing machine readable 
introspection data of the API of C libraries.
 This introspection data can be used in several different use cases, for 
example automatic code generation for
 bindings, API verification and documentation generation. 
 
 GObject Introspection contains tools to generate and handle the introspection 
data. 
 
 This package contains tools for extracting introspection data from libraries 
and transforming it to different
 formats.
Homepage: https://wiki.gnome.org/GObjectIntrospection



-- 
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#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi Michael,

Michael Biebl wrote earlier:
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

Michael Biebl wrote:
> As an example, after installing the example deb I attached earlier, it
> pulls in dependencies like gobject-introspection.
> 
> $ apt-mark showauto  | grep gobject-introspection
> gobject-introspection
> 
> $ aptitude show gobject-introspection  | grep Automatically
> Automatically installed: no

Can you please send the full output of "aptitude show
gobject-introspection" and "apt-cache policy gobject-introspection"?

I have a slight suspicion that aptitude and apt might refer to
different architectures of gobject-introspection in this case (in
which both might be correct, just not displaying the expected or
multiple packages).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://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#841362: activemq-protobuf: FTBFS (Plugin org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies could not be resolved)

[Emmanuel Bourg]

Le 20/10/2016 à 00:06, Santiago Vila a écrit :

> You are absolutely right. Sorry for the duplicates.

No need to be sorry. Your reports and the reproducible build
notifications help us greatly to detect and fix the build issues
quickly, thanks a lot for your time.

Emmanuel Bourg

Bug#841354: Fix for hanging epoll_wait on arm64

[Tobias Leich]

Hi,

attached is a fix for the mips-epoll_pwait.diff patch file.
The exiting patch file removes zeroing sigmask, but does not zero 
sigset, the replacement of sigmask.


This causes sigset to hold bogus data and causes a hang.

The attached patch fixes this by moving the zeroing of sigset to before 
the condition, so it runs always.

Tested on arm64 chroot successfully.

Cheers, Tobias

diff --git a/debian/patches/mips-epoll_pwait.diff b/debian/patches/mips-epoll_pwait.diff
index 5b6bdb1..161f72e 100644
--- a/debian/patches/mips-epoll_pwait.diff
+++ b/debian/patches/mips-epoll_pwait.diff
@@ -48,8 +48,9 @@ Index: libuv1/src/unix/linux-core.c
  
 -  sigmask = 0;
 +  is_sigmasked = 0;
++  sigemptyset();
if (loop->flags & UV_LOOP_BLOCK_SIGPROF) {
- sigemptyset();
+-sigemptyset();
  sigaddset(, SIGPROF);
 -sigmask |= 1 << (SIGPROF - 1);
 +is_sigmasked = 1;

Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled

[S R Wright]

Package: gcc-6
Version: 6.2.0-7

Kernel building with stack protection enabled breaks with 6.2.0-7, whereas 
identical .config works using 6.2.0-6:

output:

make[2]: Leaving directory '/usr/src/linux-4.8.1'
makeARCH=x86_64 prepare
make[2]: Entering directory '/usr/src/linux-4.8.1'
scripts/kconfig/conf  --silentoldconfig Kconfig
  SYSTBL  arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/asm/unistd_32_ia32.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/asm/unistd_64_x32.h
  SYSTBL  arch/x86/entry/syscalls/../../include/generated/asm/syscalls_64.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h
  HOSTCC  arch/x86/tools/relocs_32.o
  HOSTCC  arch/x86/tools/relocs_64.o
  HOSTCC  arch/x86/tools/relocs_common.o
  HOSTLD  arch/x86/tools/relocs
  CHK include/config/kernel.release
  UPD include/config/kernel.release
Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by 
compiler
Makefile:1048: recipe for target 'prepare-compiler-check' failed
make[2]: *** [prepare-compiler-check] Error 1
make[2]: Leaving directory '/usr/src/linux-4.8.1'
debian/ruleset/targets/common.mk:194: recipe for target 
'debian/stamp/conf/kernel-conf' failed
make[1]: *** [debian/stamp/conf/kernel-conf] Error 2
make[1]: Leaving directory '/usr/src/linux-4.8.1'
/usr/share/kernel-package/ruleset/minimal.mk:93: recipe for target 
'debian/stamp/conf/minimal_debian' failed
make: *** [debian/stamp/conf/minimal_debian] Error 2
Failed to create a ./debian directory: No such file or directory at 
/usr/bin/make-kpkg line 970.

relevant .config section:

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
CONFIG_CC_STACKPROTECTOR_REGULAR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set

-- sRw

Bug#818484: thunar: Crashing on file/folder rename for me, too

[J. R. Schmid]

Package: thunar
Version: 1.6.10-4
Followup-For: Bug #818484

I second what is being reported by the original reporter as well as what is
described in 804816, 804819, 805574, 815017, and 818484.
I'm unsure about 823578 which says to patch "frequent crashes in Thunar".
Happy to provide any additional information asked for!



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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-3
ii  libcairo2   1.14.6-1+b1
ii  libdbus-1-3 1.10.12-1
ii  libdbus-glib-1-20.108-1
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.1-1
ii  libgtk2.0-0 2.24.31-1
ii  libgudev-1.0-0  230-3
ii  libice6 2:1.0.9-1+b1
ii  libnotify4  0.7.7-1
ii  libpango-1.0-0  1.40.3-2
ii  libsm6  2:1.2.2-1+b1
ii  libthunarx-2-0  1.6.10-4
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-2
ii  libxfconf-0-2   4.12.0-3
ii  shared-mime-info1.7-1
ii  thunar-data 1.6.10-4

Versions of packages thunar recommends:
ii  dbus-x11 1.10.12-1
ii  gvfs 1.30.1-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpangoft2-1.0-01.40.3-2
ii  thunar-volman0.8.1-2
ii  tumbler  0.1.31-2+b3
ii  xdg-user-dirs0.15-2
ii  xfce4-panel  4.12.0-4

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#841364: partial workaround: purging config files

[Adam Borowski]

It appears that there are two parts to this bug:

1. failure to deal with config files written by older versions.  Nuking
~/.config/Clementine then manually redoing all of your config makes
Clementine at least continue and put its sound _somewhere_.  Whether you'll
actually hear something depends on whether the first device is something
good or some crap like "HDA-Intel - HDA NVidia".  I guess that, had I
connected some HDMI TV or maybe a monitor with built-in speakers, I would
hear something.

2. routing regression gone further -- 1.3.1 merely didn't provide GUI
controls to select an audio sink but it still worked if set by an earlier
version or by manually by editing the config file


-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#841362: activemq-protobuf: FTBFS (Plugin org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies could not be resolved)

[Santiago Vila]

On Wed, Oct 19, 2016 at 10:50:33PM +0200, Emmanuel Bourg wrote:
> Le 19/10/2016 à 22:31, Santiago Vila a écrit :
> 
> > I have already reported a bug like this in other packages.
> > See Bug #841197 for a likely fix.
> 
> ...and you'll get the same issue with all reverse dependencies of
> maven-enforcer. These bugs are duplicates of the same issue, they should
> be assigned to maven-enforcer, merged, and marked as affecting the
> reverse dependencies:
> [...]

You are absolutely right. Sorry for the duplicates.

I read a message from Markus yesterday, but I read it too fast and
didn't realize he already said this was a bug in maven-enforcer.

I see that he already did the merge and the reassign.

I'm going to make the "affects" with the list of reverse depends you
have provided. This definitely helps me to avoid duplicate bugs.

Thanks a lot.

Bug#841233: marble: Does not follow symlinks

[Marcos Dione]

On Wed, Oct 19, 2016 at 09:24:45AM +0200, Maximiliano Curia wrote:
> ¡Hola Marcos!

Hey chango

> El 2016-10-18 a las 20:25 +0200, Marcos Dione escribió:
> >marble has for ages disabled symlinks traversal in a great part of
> > the local cache code. I know for certain that developers have decided to
> > do so to avoid user reports related to dangling symlinks (sorry, I can't
> > find a reference now).
> 
> This also avoids the "recursion too deep" problems.
> 
> > This bug report is to see if the Debian maintainers agree this is wrong.
> 
> What's the benefit that you seek by enabling symlinks?
> 
> As package maintainers we prefer to avoid diverging too much from upstream.
> 
> In particular, this patch is simple enough, but it creates a vector for the
> kind of bugs that upstream wants to avoid. How would we avoid dangling
> symlinks problems?

I'm using symlinks to cache tiles in a particular storage
device/filesystem. I could bind-mount directories, but that complicates
the setup a little. I think that those who are using symlinks (which
involves investigating how marble stores the caches and other data) are
clever enough to dig themselves out of the holes they dug... but I could
be mistaken.

> > Attached you'll find a patch that removes all the references to
> > QDir::NoSymLinks from the code. I tested it and it works fine now. I
> > will keep having this patch around, but I hope you find it useful too,
> > so everyone else can profit from it, and I don't have to recompile
> > marble from time to time :)
> 
> How about trying to send this upstream, maybe making this an option?

I think I did a couple of years ago, and I got the answer I mentioned
in the bug report. Yes, I could do it again. I'll try; if I don't
succeed, I think I'll go the bind-mount way... or keep compiling with my
patch.

Thanks for your time. Cheers,

-- Marcos.

-- 
(Not so) Random fortune:
Terrorism isn't a crime against people or property. It's a crime against
our minds, using the death of innocents and destruction of property to
make us fearful.
-- Bruce Schneier

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Hi

Am 19.10.2016 um 23:48 schrieb Axel Beckert:
> Michael Biebl wrote:
>> So if I install via apt, the auto state is not properly set for
>> aptitude. I have no idea how apt and aptitude interact and if the
>> autobit is something which is supposed to be shared between both?
> 
> It is.
> 
>> Do they access the same database
> 
> Nowadays they do.
> 
>> or is aptitude tracking this information on its own?
> 
> It did it before apt did and hence used its own database in the past.
> But that was fixed IIRC years ago.

Ok, good to know that this should work in theory.

I'm using aptitude 0.8.3-1+b1 here and as I showed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841347#36

apt and aptitude have a different view regarding the autobit.

I'm happy to provide more information if you tell me what you need.

Regards,
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#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi Michael,

Michael Biebl wrote:
> So if I install via apt, the auto state is not properly set for
> aptitude. I have no idea how apt and aptitude interact and if the
> autobit is something which is supposed to be shared between both?

It is.

> Do they access the same database

Nowadays they do.

> or is aptitude tracking this information on its own?

It did it before apt did and hence used its own database in the past.
But that was fixed IIRC years ago.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://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#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 19.10.2016 um 23:35 schrieb Michael Biebl:
> apt-mark showauto correctly lists the installed dependencies.
> When running aptitude interactively, it shows the installed dependencies
> as "i" and not "i A" though, which means installed manually and not
> automatically.
> 
> So if I install via apt, the auto state is not properly set for
> aptitude. I have no idea how apt and aptitude interact and if the
> autobit is something which is supposed to be shared between both?
> Do they access the same database or is aptitude tracking this
> information on its own?

As an example, after installing the example deb I attached earlier, it
pulls in dependencies like gobject-introspection.

$ apt-mark showauto  | grep gobject-introspection
gobject-introspection

$ aptitude show gobject-introspection  | grep Automatically
Automatically installed: no


-- 
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#732797: PKG_CHECK_MODULES should report the module name, not variable prefix

[Guillem Jover]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=98334

Hi!

On Wed, 2016-10-19 at 12:28:55 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> > I noticed this bug report some time ago, but I've got bothered enough
> > now to try to move it forward. And I've turned the above description
> > and the below "patch"…
> 
> [...]
> 
> > …into a git formatted patch (against current master). But because
> > I've actually reworded things a bit, and I feel like I've actually put
> > words in Russ' mouth, I'd rather you'd take a look before considering
> > forwarding it upstream! I'll also very happily defer if you'd want to
> > do that yourself!
> 
> Thanks for doing this!  As the other bug reporter, very happy to have you
> forward this upstream.  I haven't had a lot of time recently to chase
> things like this, and have a huge backlog, so happy to encourage others to
> push such things forward.  Everything in the patch looked good to me.

Perfect thanks! I've now submitted it upstream, let' see what they
say. :)

Regards,
Guillem

Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Thanks for you quick reply, David

Am 19.10.2016 um 21:32 schrieb David Kalnischkies:

> As far as I can see in the reproduce steps apt tools are working as
> expected, it is aptitude which isn't working to your liking, hence
> reassigning as I have no (real) idea about aptitude.
> 
> Given that apt autoremoves the dependencies I guess they are correctly
> marked as automatic on installation (you can check with 'apt-mark
> showauto' to be sure), but somehow aptitude looses the autobit on
> removal. aptitude would usually by default remove the autoremoveable
> packages together with the -build-deps package, wouldn't it?

apt-mark showauto correctly lists the installed dependencies.
When running aptitude interactively, it shows the installed dependencies
as "i" and not "i A" though, which means installed manually and not
automatically.

So if I install via apt, the auto state is not properly set for
aptitude. I have no idea how apt and aptitude interact and if the
autobit is something which is supposed to be shared between both?
Do they access the same database or is aptitude tracking this
information on its own?


-- 
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#841068: hurd: system() is broken if exe/lib which links to pthread calls dlclose() of SO which links to curl-gnutls

[Samuel Thibault]

Samuel Thibault, on Wed 19 Oct 2016 18:15:03 +0200, wrote:
> Eugene V. Lyubimkin, on Mon 17 Oct 2016 13:26:58 +0200, wrote:
> > Unfortunately, it was not enough for Cupt test suite on Hurd, since the
> > bug still happens under another circumstances - namely, if the
> > caller itself (executable or shared library) links to pthread.
> 
> A fix has been uploaded in libc0.3 2.24-5. We however now need to wait
> for p11-kit to be rebuilt with that libc in order to get the fix in (you
> don't want to know why).

Yep, cupt now built fine!

Thanks,
Samuel

Bug#841288: tigervnc-common: amd64 has dep libgnutls-deb0-28

[Axel Beckert]

Control: severity -1 serious

Hi,

Jacek Szafarkiewicz wrote:
> tigervnc-common needs libgnutls-deb0-28 on amd64 architecture.
> I think this dep should be for arm64.

Nope, the amd64 package has been built on Debian Stable instead of
Debian Unstable and then uploaded to Debian Unstable anyways.

See https://packages.debian.org/search?keywords=libgnutls-deb0-28

(arm64 from debports doesn't count anymore, it's already in Debian
proper for multiple years.)

Nevertheless, this is definitely a serious issue and tigervnc on
amd64 needs to be rebuilt in a clean chroot, e.g. by requesting a
BinNMU for it. (Which the maintainer of the package should do.

Without that, the package won't migrate to testing.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://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#840771: segfaults on valid certificate

[Dmitry Eremin-Solenikov]

Package: dumpasn1
Followup-For: Bug #840771

I belive the patch you have provided is not full/correct. You pass a
pointer to a wide character, when the code expects to have a valid wide
string (ending with L'\0'). Please consider the attached patch instead.

-- 
With best wishes
Dmitry


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages dumpasn1 depends on:
ii  libc6  2.24-3

dumpasn1 recommends no packages.

dumpasn1 suggests no packages.

-- no debconf information
Description: Fix bug 840771
Author: Mathieu Malaterre 
Bug-Debian: https://bugs.debian.org/840771

Index: dumpasn1-20150808/dumpasn1.c
===
--- dumpasn1-20150808.orig/dumpasn1.c
+++ dumpasn1-20150808/dumpasn1.c
@@ -1362,7 +1362,7 @@ static int displayUnicode( const wchar_t
 #elif 1
 		/* This (and the "%ls" variant below) seem to be the least broken 
 		   options */
-		fprintf( output, "%lc", wCh );
+		fprintf( output, "%lc", wCh[0] );
 #elif 0
 		wchar_t wChString[ 2 ];
 
@@ -1885,13 +1885,13 @@ static void displayString( FILE *inFile,
 		if( strOption == STR_UTF8 && ( ch & 0x80 ) )
 			{
 			const int secondCh = getc( inFile );
-			wchar_t wCh;
+			wchar_t wCh[2] = { 0, 0 };
 
 			/* It's a multibyte UTF8 character, read it as a widechar */
 			if( ( ch & 0xE0 ) == 0xC0 )		/* 111x -> 110x */
 {
 /* 2-byte character in the range 0x80...0x7FF */
-wCh = ( ( ch & 0x1F ) << 6 ) | ( secondCh & 0x3F );
+wCh[0] = ( ( ch & 0x1F ) << 6 ) | ( secondCh & 0x3F );
 i++;		/* We've read 2 characters */
 fPos += 2;
 }
@@ -1902,12 +1902,12 @@ static void displayString( FILE *inFile,
 	const int thirdCh = getc( inFile );
 
 	/* 3-byte character in the range 0x800...0x */
-	wCh = ( ( ch & 0x1F ) << 12 ) | \
+	wCh[0] = ( ( ch & 0x1F ) << 12 ) | \
 		  ( ( secondCh & 0x3F ) << 6 ) | \
 		  ( thirdCh & 0x3F );
 	}
 else
-	wCh = '.';
+	wCh[0] = '.';
 i += 2;		/* We've read 3 characters */
 fPos += 3;
 }

Bug#837597: Forwarded

[Michael Biebl]

On Mon, 3 Oct 2016 03:05:11 +0500 "Alexander E. Patrakov"
 wrote:
> forwarded 837597 https://github.com/systemd/systemd/issues/4271
> thanks
> 
> Of course the above forwarding is insufficient, because of 
> non-systemd-based systems.

The relevant Ubuntu bug report is
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1622893

This issue is apparently triggered by a change in gnutls which now uses
getrandom() instead of reading from /dev/urandom directly. This makes it
less suitable for early boot.

-- 
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#841240: similar issue on 4.9-rc1

[Adam Borowski]

Lemme add: there's a similar, more serious issue on 4.9-rc1.  x32 processes
fail not just on preadv but on apparently any startup of something linked
with glibc (although at least _exit() and write() do work).

I haven't yet had the tuits to bisect or debug what's the cause.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#841366: RFS: task-spooler/1.0-1

[Alexander Inyukhin]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "task-spooler"

 * Package name: task-spooler
   Version : 1.0-1
   Upstream Author : Lluís Batlle i Rossel 
 * URL : http://viric.name/soft/ts/
 * License : GPLv2+
   Section : misc

It builds those binary packages:

  task-spooler - personal job scheduler

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

  http://mentors.debian.net/package/task-spooler

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

  dget -x 
http://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_1.0-1.dsc

Changes since the last upload:

   * New upstream version 1.0
   * Update patches
   * Change homepage to http://viric.name/soft/ts/
   * Bump standards version to 3.9.8 (no changes)


Regards,
   Alexander Inyukhin

Bug#841287: saga: FTBFS: error with opencv 3.1

[Nobuhiro Iwamatsu]

Hi!

Thanks for your reply.
2016-10-20 3:30 GMT+09:00 Sebastiaan Couwenberg :
> Hi Nobuhiro,
>
> Thanks for your work on OpenCV and reporting this issue.
>
> On 10/19/2016 01:21 PM, Nobuhiro Iwamatsu wrote:
>> I am scheduled to transition of opencv, and this package is target to
>> transition.
>> So I tested build with opencv 3.1.As a result, this FTBFS with opencv 3.1.
>> Because libcv-dev, ibopencv-contrib-dev and libopencv-legacy-dev has been
>> removed from opencv 3.1 package.
>>
>> [...]
>>
>> I attached a patch that revice this problem.
>> Could you check this patch and apply?
>
> The patch is incomplete as it removes libcv-dev from the build
> dependencies, but doesn't add libopencv-dev to which opencv/cv.h has
> been moved.

Oh, sorry. I send other patch.
As you say, we need to add libopencv-dev to B-D.

>
> Since we cannot adapt the saga package for 3.1 until the transition
> starts, we'll need to apply the changes when the transition starts and
> do a new upload.

no problem.

>
> Have you considered transitional packages for the removed -dev packages
> to not require changes to the opencv reverse dependencies and have
> binNMUs suffice for the transition?
>

I am working about that.
I finished the investigation of the packages that depend on opencv, I
will make it
easier to migrate, and bug reports to the package there is a problem.

> Kind Regards,
>
Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#841365: ITP: gnuastro -- Programs and libraries for astronomical data analysis and manipulation

[Mohammad Akhlaghi]

Package: wnpp
Owner: Mohammad Akhlaghi 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org

* Package name: GNU Astronomy Utilities (Gnuastro)
  Version : 0.2
  Upstream Author : Mohammad Akhlaghi 
* URL : https://www.gnu.org/software/gnuastro/
* License : GNU GPL3+
  Programming Lang: C
  Description : Programs and libraries for astronomical data 
analysis and manipulation


The GNU Astronomy Utilities (Gnuastro) is an official GNU package 
consisting of various programs and library functions for the 
manipulation and analysis of astronomical data. All the programs share 
the same basic command-line user interface for the comfort of both the 
users and developers. Gnuastro is written to comply fully with the GNU 
coding standards so it integrates finely with the GNU/Linux operating 
system. This also enables astronomers to expect a fully familiar 
experience in the source code, building, installing and command-line 
user interaction that they have seen in all the other GNU software that 
they use.


For a list of Gnuastro programs see [1] and for the libraries, please 
see [2]. Ole Streicher Kindly recommended adding Gnuastro as a package 
in Debian, so I am making the official announcement here.


Cheers,
Mohammad

[1] 
https://www.gnu.org/software/gnuastro/manual/html_node/Gnuastro-programs-list.html
[2] 
https://www.gnu.org/software/gnuastro/manual/html_node/Gnuastro-library.html

Bug#832838: eclipse-xsd: FTBFS: Duplicate methods named spliterator with the parameters () and () are inherited from the types List and Collection

[Emmanuel Bourg]

Control: notfound -1 2.9.0-1
Control: close -1

This issue was a side effect of #757536. It went away with the upload of
eclipse/3.8.1-9

Bug#838790: [l10n] Updated Czech translation of aptitude

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


2016-09-24 22:44 Miroslav Kure:

Package: aptitude
Severity: wishlist
Tags: l10n, patch

Hi,

as the Stretch release is getting closer, please find attached updated
Czech (cs.po) translation of aptitude together with the help file
(help-cs.txt).


Applied, thanks!


--
Manuel A. Fernandez Montecelo 

Bug#841116: aptitude: [INTL:nl] Dutch po file for the aptitude package

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


2016-10-17 20:46 Frans Spiesschaert:



Package: aptitude
Severity: wishlist
Tags: l10n patch


Dear Maintainer,

==
Please find attached the updated Dutch po file for the aptitude package.
It has been submitted for review to the debian-l10n-dutch mailing list.
Please add it to your next package revision.
It should be put as "po/nl.po" in your package build tree.
===


Thanks, applied!


--
Manuel A. Fernandez Montecelo 

Bug#841364: clementine: no sound at all, "GStreamer encountered a general stream error."

[Adam Borowski]

Package: clementine
Version: 1.3.1+git240-g1a2f6e2+dfsg-1
Severity: grave
Justification: renders package unusable


Since today's upload, Clementine fails to produce any sound at all, instead
popping up a window with endlessly repeating:

GStreamer encountered a general stream error.
---
GStreamer encountered a general stream error.
---
GStreamer encountered a general stream error.
---
GStreamer encountered a general stream error.


No amount of messing with user-available settings (which have been dumbed
down to just "Output device" with "Choose automatically" and a handful of
"Default device on ") seems to help.  Settings that are apparently
not meant to be adjusted by the user (~/.config/Clementine/Clementine.conf)
are undocumented at all, with nary a comment; what I remember from past
versions (cf #823301) doesn't seem to work anymore.

This is reproducible on different hardware, even of different architectures
(I just happen to have exactly one non-remote amd64 box but plenty of arms),
all using plain ALSA.



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

Kernel: Linux 4.9.0-rc1-debug-pp2+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.8.3-1
ii  gstreamer1.0-plugins-good   1.8.3-1+b1
ii  gstreamer1.0-plugins-ugly   1.8.3-1
ii  libc6   2.24-5
ii  libcdio13   0.83-4.2+b1
ii  libchromaprint1 1.3.2-2
ii  libcrypto++65.6.4-1
ii  libfftw3-double33.3.5-1
ii  libgcc1 1:6.2.0-7
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.1-1
ii  libgpod40.8.3-8
ii  libgstreamer-plugins-base1.0-0  1.8.3-1
ii  libgstreamer1.0-0   1.8.3-1
ii  libimobiledevice6   1.2.0+dfsg-3
ii  liblastfm1  1.0.9-1
ii  libmtp9 1.1.12-1
ii  libmygpo-qt11.0.9~git20151122-1
ii  libplist3   1.12-3.1
ii  libprojectm2v5  2.1.0+dfsg-4+b1
ii  libprotobuf10   3.0.0-7
ii  libpulse0   9.0-4.0nosystemd1
ii  libqjson0   0.8.1-3
ii  libqt4-dbus 4:4.8.7+dfsg-9
ii  libqt4-network  4:4.8.7+dfsg-9
ii  libqt4-opengl   4:4.8.7+dfsg-9
ii  libqt4-sql  4:4.8.7+dfsg-9
ii  libqt4-sql-sqlite   4:4.8.7+dfsg-9
ii  libqt4-xml  4:4.8.7+dfsg-9
ii  libqtcore4  4:4.8.7+dfsg-9
ii  libqtgui4   4:4.8.7+dfsg-9
ii  libqxt-gui0 0.6.2-3
ii  libsqlite3-03.15.0-1
ii  libstdc++6  6.2.0-7
ii  libtag1v5   1.11+dfsg.1-0.3
ii  libx11-62:1.6.3-1
ii  projectm-data   2.1.0+dfsg-4
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages clementine recommends:
ii  gstreamer1.0-alsa  1.8.3-1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.8.3-1+b3

-- no debconf information

Bug#841362: activemq-protobuf: FTBFS (Plugin org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies could not be resolved)

[Emmanuel Bourg]

Le 19/10/2016 à 22:31, Santiago Vila a écrit :

> I have already reported a bug like this in other packages.
> See Bug #841197 for a likely fix.

...and you'll get the same issue with all reverse dependencies of
maven-enforcer. These bugs are duplicates of the same issue, they should
be assigned to maven-enforcer, merged, and marked as affecting the
reverse dependencies:

  activemq
  activemq-activeio
  activemq-protobuf
  animal-sniffer
  annotation-indexer
  async-http-client
  checkstyle
  jacoco
  jboss-logmanager
  jboss-modules
  junit4
  libhibernate3-java
  maven-jar-plugin
  openjpa
  wagon

Emmanuel Bourg

Bug#823460: closed by Yves-Alexis Perez <cor...@debian.org> (Bug#823460: fixed in lightdm 1.18.2-3)

[Ian Jackson]

Debian Bug Tracking System writes ("Bug#823460 closed by Yves-Alexis Perez 
 (Bug#823460: fixed in lightdm 1.18.2-3)"):
> This is an automatic notification regarding your Bug report
> which was filed against the lightdm package:
> 
> #823460: lightdm: SIGPIPE ignored in session
> 
> It has been closed by Yves-Alexis Perez .

Yay!  Thank you.

Regards,
Ian.

Bug#827061: transition: openssl

[Kurt Roeckx]

On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote:
> 
> I'm sorry but I'm going to have to nack this for Stretch, as much as I like to
> approve transitions and get new stuff in. I have looked at the opened bugs and
> I'm afraid this still is too disruptive. I have noticed that you have 
> forwarded
> some of them and sent patches, and I appreciate that. We can do this early in
> the Buster cycle, so let's look at the status of this and prepare for the
> transition when Stretch gets released.

Is having 2 version of OpenSSL in Stretch an option?

I could upload an openssl102 source package that provides an
libssl1.0.2-dev package, so that packages that aren't ready to
move to the 1.1.0 version can build-depend on that instead.


Kurt

Bug#841197: maven-enforcer: Missing dependency version causes FTBFS

[Markus Koschany]

Control: reassign 841197 maven-enforcer
Control: reassign 841296 maven-enforcer
Control: reassign 841362 maven-enforcer
Control: reassign 841363 maven-enforcer
Control: forcemerge 841197 841296 841362 841363
Control: tags 841197 patch pending

I am going to reassign this issue to maven-enforcer and patch the pom file.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#841289: [drm/i915] GPU HANG: ecode 9:0:0xfffffffe, in Xorg [2507], reason: Engine(s) hung, action: reset

[Jonas Meurer]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=98332

Am 19.10.2016 um 14:35 schrieb Ben Hutchings:
> On Wed, 2016-10-19 at 13:53 +0200, Jonas Meurer wrote:
>> Package: src:linux
>> Version: 4.7.6-1
>> Severity: grave
>> Justification: renders package unusable
>>
>> Hello,
>>
>> recently, something on my system related to drm/i915 broke. Since no
>> xserver/drm packages have been upgraded, I strongly suspect the
>> latest
>> linux kernel upgrade to be the culprit.
> 
> Please open a bug upstream as recommended:

Thanks for the prompt reply.

> Then let us know the bug number or URL.

It can be found here: https://bugs.freedesktop.org/show_bug.cgi?id=98332

Cheers,
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#837565: liblpsolve55-dev: Please build liblpsolve55.a with -fPIC

[Rene Engelhard]

Hi,

On Tue, Oct 11, 2016 at 04:38:51PM +0200, Bálint Réczey wrote:
> I added the affects tag based on this log:
> https://people.debian.org/~rbalint/build-logs/pie-bindnow-20160906/libreoffice_5.2.0-2_amd64.build.gz
> :
> ...
> checking for make_lp in -llpsolve55... no
> configure: error: lpsolve library not found or too old.
> Error running configure at ./autogen.sh line 281.
> /<>/debian/rules:1972: recipe for target
> 'debian/stampdir/build-arch' failed
> make[1]: *** [debian/stampdir/build-arch] Error 25
> make[1]: Leaving directory '/<>'
> debian/rules:1965: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> Build finished at 2016-09-06T12:46:09Z
> ...
> 
> This may have been solved since then, I have to re-check with latest
> patched GCC.

Nah, it definitely was a bug. The path in configure was wrong so that the 
configure
check actually _did_ check with the .a. The actual linkage was correct and used 
the
shared lib with a RPATH..

Guess this started now with gcc 6 6.2.0-7, so...

Regards,

Rene

Bug#841363: junit4: FTBFS (Plugin org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies could not be resolved)

[Santiago Vila]

Package: src:junit4
Version: 4.12-4
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --buildsystem=maven
   dh_testdir -i -O--parallel -O--buildsystem=maven
   dh_update_autotools_config -i -O--parallel -O--buildsystem=maven
   dh_auto_configure -i -O--parallel -O--buildsystem=maven
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar': No 
such file or directory
mh_patchpoms -pjunit4 --debian-build --keep-pom-version 
--maven-repo=/<>/debian/maven-repo
   dh_auto_build -i -O--parallel -O--buildsystem=maven
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
-Dmaven.repo.local=/<>/debian/maven-repo package javadoc:jar 
javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US
[INFO] Scanning for projects...
[WARNING] The POM for org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1 
is invalid, transitive dependencies (if any) will not be available, enable 
debug logging for more details
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1: Plugin 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies 
could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1
[WARNING] The POM for org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1 
is invalid, transitive dependencies (if any) will not be available, enable 
debug logging for more details
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1: Plugin 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies 
could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1
[INFO] 
[INFO] 
[INFO] Building JUnit 4.12
[INFO] 
[WARNING] The POM for org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1 
is invalid, transitive dependencies (if any) will not be available, enable 
debug logging for more details
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1: Plugin 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies 
could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1
[WARNING] The POM for org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1 
is invalid, transitive dependencies (if any) will not be available, enable 
debug logging for more details
[INFO] 
[INFO] 
[INFO] Skipping JUnit
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 0.345 s
[INFO] Finished at: 2016-10-19T20:46:35+02:00
[INFO] Final Memory: 8M/90M
[INFO] 
[ERROR] Plugin org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of 
its dependencies could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1: 1 problem was 
encountered while building the effective model for 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
[ERROR] [ERROR] 'dependencies.dependency.version' for 
org.apache.maven.plugin-tools:maven-plugin-annotations:jar is missing. @
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 

Bug#840153: Should have various tutorial manpages

[Ian Jackson]

Sean Whitton writes ("Bug#840153: Should have various tutorial manpages"):
> control: tag -1 +patch
> 
> Please find attached git-am(1)-amenable patches adding some pod2man
> infrastructure, and dgit-maint-merge(7).

Thanks!  I really like your new manpage.

I have fixed up a few things with the build - notably, I thought "make
all" should build the manpage.  And you should add it to the Makefile
in the same commit as you add the file, or you create a commit that
doesn't build.

I have also made a few changes to the manpage, which I hope you will
approve of.

> (I'm keen to retain the authorship information in the actual manpage,
> but you might not like how I've edited d/copyright, so I made that a
> separate patch.)

Right.  I have changed this a bit.  I hope you like it.

Can you take a look at
  
http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=shortlog;h=refs/heads/wip.manpages
aka
  git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git#wip.manpages
and let me know if you approve ?  If so I will push it to master,
assuming it passes whatever tests I choose to run on it.

(NB that "wip.*" branches in my repos are rewinding and might
disappear.)

BTW I'm just as happy with git branch on a server as I am with git-am
patches.

Regards,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841362: activemq-protobuf: FTBFS (Plugin org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies could not be resolved)

[Santiago Vila]

Package: src:activemq-protobuf
Version: 1.1-4
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --buildsystem=maven
   dh_testdir -i -O--parallel -O--buildsystem=maven
   dh_update_autotools_config -i -O--parallel -O--buildsystem=maven
   dh_auto_configure -i -O--parallel -O--buildsystem=maven
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar': No 
such file or directory
mh_patchpoms -plibactivemq-protobuf-java --debian-build 
--keep-pom-version --maven-repo=/<>/debian/maven-repo
   dh_auto_build -i -O--parallel -O--buildsystem=maven
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/<>/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
-Dmaven.repo.local=/<>/debian/maven-repo package javadoc:jar 
javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US
[INFO] Scanning for projects...
[WARNING] 

[... snipped ...]

[WARNING] The POM for org.apache.maven.plugins:maven-release-plugin:jar:2.3.2 
is missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-release-plugin:2.3.2: Plugin 
org.apache.maven.plugins:maven-release-plugin:2.3.2 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-release-plugin:jar:2.3.2 has not been downloaded 
from it before.
[INFO] 
[INFO] 
[INFO] Building ActiveMQ Protocol Buffers POM 1.1
[INFO] 
[WARNING] The POM for org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1 
is invalid, transitive dependencies (if any) will not be available, enable 
debug logging for more details
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1: Plugin 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1 or one of its dependencies 
could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4.1
[WARNING] The POM for org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-deploy-plugin:2.7: Plugin 
org.apache.maven.plugins:maven-deploy-plugin:2.7 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 has not been downloaded 
from it before.
[WARNING] The POM for org.apache.maven.plugins:maven-site-plugin:jar:3.3 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-site-plugin:3.3: Plugin 
org.apache.maven.plugins:maven-site-plugin:3.3 or one of its dependencies could 
not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) 
in offline mode and the artifact 
org.apache.maven.plugins:maven-site-plugin:jar:3.3 has not been downloaded from 
it before.
[WARNING] The POM for org.apache.maven.plugins:maven-antrun-plugin:jar:1.7 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-antrun-plugin:1.7: Plugin 
org.apache.maven.plugins:maven-antrun-plugin:1.7 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-antrun-plugin:jar:1.7 has not been downloaded 
from it before.
[WARNING] The POM for 
org.apache.maven.plugins:maven-assembly-plugin:jar:2.2-beta-4 is missing, no 
dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-4: Plugin 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-4 or one of its 
dependencies could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline 

Bug#822792: marked as pending

[Michael Lustfield]

awe... I bumped send a bit early. :(

>> Ordering could be relevant if packages want to handle more
>> specific URLs than others?
>> For example letsencrypt wants to handle
>> /.well-known/acme-challenge while maybe something else
>> wants to handle /.well-known?
>
> In this case, the existing static block is sufficient.

location / { try_files $uri $uri/ =404; } would cover the files that
get created in that directory.

Additionally, for letsencrypt, I would highly recommend acmetool. It's
saved me a lot of headache due to its simplicity and insistence that
it'll work no matter what.

Bug#837658: libfl-dev: Please build libfl_pic.a with -fPIC

[Graham Inggs]

binNMU against gcc-6 6.2.0-7 requested in #841203.

Bug#841361: bd: Typo in the package description

[Thomas Vincent]

Package: bd
Severity: minor

Dear Maintainer,

I found a typo while translating bd's description. Indeed, in the first 
sentence, "parente directory" should be spelled "parent directory".

Thanks for your work on bd,
Thomas


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

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

Bug#841360: libmotif-common stuck at 2.3.4-10 in sid (src:motif is 2.3.4-11)

[Graham Inggs]

Hi Daniel

On 19 October 2016 at 21:59, Daniel Reichelt  wrote:
> So I assume this is just an upload-related issue...

Yes, the recent upload of motif 2.3.4-11 FTBFS on some architectures
[1], including on amd64 where the arch:all libmotif-common package is
built.

It will be fixed soon, see #840394 for details.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=motif=unstable

Bug#831857: libupnp: CVE-2016-6255: write files via POST

[James Cowgill]

Control: tags -1 patch pending

Hi,

I am about to upload the attached NMU to finally fix this bug. I've also
attached a patch suitable for jessie-security, and a test script I used
to create a libupnp server for testing the fix with.

Thanks,
James
/*
 * Upnp CVE-2016-6255 test program
 *
 * This program runs the webserver from libupnp serving files from the current
 * directory. If libupnp is vulnerable to CVE-2016-6255, it will allow uploading
 * files.
 *
 * Example:
 *
 * $ gcc -I/usr/include/upnp cve-2016-6255-test.c -lupnp -ocve-2016-6255-test
 * $ cat testfile
 * cat: testfile: No such file or directory
 * $ ./cve-2016-6255-test > /dev/null &
 * [2] 32309
 * $ curl -i --data $'FAIL\n' http://localhost:49152/testfile
 * $ cat testfile
 * FAIL
 */

#define _GNU_SOURCE
#include 
#include 
#include 

int main(void)
{
	char* wd = get_current_dir_name();

	// Setup upnp
	printf("Init = %d\n", UpnpInit("127.0.0.1", 0));
	printf("SetRoot = %d\n", UpnpSetWebServerRootDir(wd));
	free(wd);

	// Hang
	for (;;)
		pause();
}
diff -Nru libupnp-1.6.19+git20141001/debian/changelog 
libupnp-1.6.19+git20141001/debian/changelog
--- libupnp-1.6.19+git20141001/debian/changelog 2014-10-23 21:48:01.0 
+0100
+++ libupnp-1.6.19+git20141001/debian/changelog 2016-10-19 21:02:05.0 
+0100
@@ -1,3 +1,12 @@
+libupnp (1:1.6.19+git20141001-1+deb8u1) jessie-security; urgency=high
+
+  * Non-maintainer upload.
+  * Don't allow unhandled POSTs to write to the filesystem by
+default (Closes: #831857) (CVE-2016-6255)
+Thanks to Matthew Garrett for the patch.
+
+ -- James Cowgill   Wed, 19 Oct 2016 21:02:05 +0100
+
 libupnp (1:1.6.19+git20141001-1) unstable; urgency=low
 
   * Ack both NMUs, thankyou for your care of this package.
diff -Nru libupnp-1.6.19+git20141001/debian/patches/CVE-2016-6255.patch 
libupnp-1.6.19+git20141001/debian/patches/CVE-2016-6255.patch
--- libupnp-1.6.19+git20141001/debian/patches/CVE-2016-6255.patch   
1970-01-01 01:00:00.0 +0100
+++ libupnp-1.6.19+git20141001/debian/patches/CVE-2016-6255.patch   
2016-10-19 21:00:38.0 +0100
@@ -0,0 +1,61 @@
+From c91a8a3903367e1163765b73eb4d43be7d7927fa Mon Sep 17 00:00:00 2001
+From: Matthew Garrett 
+Date: Tue, 23 Feb 2016 13:53:20 -0800
+Subject: [PATCH] Don't allow unhandled POSTs to write to the filesystem by
+ default
+
+If there's no registered handler for a POST request, the default behaviour
+is to write it to the filesystem. Several million deployed devices appear
+to have this behaviour, making it possible to (at least) store arbitrary
+data on them. Add a configure option that enables this behaviour, and change
+the default to just drop POSTs that aren't directly handled.
+
+Signed-off-by: Marcelo Roberto Jimenez 
+---
+ configure.ac | 4 
+ upnp/inc/upnpconfig.h.in | 5 +
+ upnp/src/genlib/net/http/webserver.c | 4 
+ 3 files changed, 13 insertions(+)
+
+--- a/configure.ac
 b/configure.ac
+@@ -495,6 +495,10 @@ if test "x$enable_blocking_tcp_connectio
+ AC_DEFINE(UPNP_ENABLE_BLOCKING_TCP_CONNECTIONS, 1, [see upnpconfig.h])
+ fi
+ 
++RT_BOOL_ARG_ENABLE([postwrite], [no], [write to the filesystem on otherwise 
unhandled POST requests])
++if test "x$enable_postwrite" = xyes ; then
++AC_DEFINE(UPNP_ENABLE_POST_WRITE, 1, [see upnpconfig.h])
++fi
+ 
+ RT_BOOL_ARG_ENABLE([samples], [yes], [compilation of upnp/sample/ code])
+ 
+--- a/upnp/inc/upnpconfig.h.in
 b/upnp/inc/upnpconfig.h.in
+@@ -131,5 +131,10 @@
+  * header (i.e. configure --enable-unspecified_server) */
+ #undef UPNP_ENABLE_UNSPECIFIED_SERVER
+ 
++/** Defined to 1 if the library has been compiled to support filesystem 
writes on POST
++ *  (i.e. configure --enable-postwrite) */
++#undef UPNP_ENABLE_POST_WRITE
++
++
+ #endif /* UPNP_CONFIG_H */
+ 
+--- a/upnp/src/genlib/net/http/webserver.c
 b/upnp/src/genlib/net/http/webserver.c
+@@ -1366,9 +1366,13 @@ static int http_RecvPostMessage(
+   if (Fp == NULL)
+   return HTTP_INTERNAL_SERVER_ERROR;
+   } else {
++#ifdef UPNP_ENABLE_POST_WRITE
+   Fp = fopen(filename, "wb");
+   if (Fp == NULL)
+   return HTTP_UNAUTHORIZED;
++#else
++  return HTTP_NOT_FOUND;
++#endif
+   }
+   parser->position = POS_ENTITY;
+   do {
diff -Nru libupnp-1.6.19+git20141001/debian/patches/series 
libupnp-1.6.19+git20141001/debian/patches/series
--- libupnp-1.6.19+git20141001/debian/patches/series2014-10-04 
05:26:29.0 +0100
+++ libupnp-1.6.19+git20141001/debian/patches/series2016-10-19 
21:00:43.0 +0100
@@ -5,3 +5,4 @@
 18-url-upnpstrings.patch
 19_fix_tests.patch
 21_fix-1.6.19+git.patch
+CVE-2016-6255.patch
diff -Nru libupnp-1.6.19+git20160116/debian/changelog 
libupnp-1.6.19+git20160116/debian/changelog
--- libupnp-1.6.19+git20160116/debian/changelog 2016-01-17 

Bug#822792: marked as pending

[Michael Lustfield]

On Wed, Oct 19, 2016 at 11:48 AM, Elrond
 wrote:
> Hi,
>
>
> On Wed, Oct 19, 2016 at 07:19:58 +, Michael Lustfield wrote:
> [...]
>> http://git.debian.org/?p=collab-maint/nginx.git;a=commitdiff;h=5d09382
> [...]
>
> That looks very cool!
>
> I have one question: The current naming convention
> pkg_*.conf doesn't look like it allows ordering. Is

My intention is to make it *VERY* clear that packages only get to play
within their own namespace.

This means that the "pkg_drupal7.conf" should have *EVERYTHING* in
that file wrapped inside of "location ^~ /drupal7 { ... }".

Doing anything else immediately brings us back to my original
apprehension against introducing this change in the first place. The
sites/default file is *NOT* a framework and should absolutely not be
treated like it.

> Ordering could be relevant if packages want to handle more
> specific URLs than others?
> For example letsencrypt wants to handle
> /.well-known/acme-challenge while maybe something else
> wants to handle /.well-known?

In this case, the existing static block is sufficient.

Bug#840902: install debtags; purge debtags leaves behind residue

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix
Control: close -1


Hi,

2016-10-16 00:36 積丹尼 Dan Jacobson:

Package: aptitude
Version: 0.8.3-1+b1
Severity: wishlist

# aptitude install debtags
# aptitude purge debtags #but that leaves behind junk, so must then do:
# aptitude purge python3-debian python3-six python3-chardet 
python3-pkg-resources python3-apt
using
#cat /etc/apt/apt.conf.d/10jidanni
APT::Default-Release "experimental";
APT::Cache::AllVersions false;
APT::Clean-Installed false;
APT::Get::Fix-Missing true;
APT::Get::Purge true;
APT::Install-Recommends false;
Binary::apt::APT::Keep-Downloaded-Packages true;
APT::Keep-Downloaded-Packages true;
Aptitude::CmdLine::Always-Prompt true;
Aptitude::Purge-Unused true;
Aptitude::CmdLine::Show-Why true;
Aptitude::CmdLine::Show-Deps true;
Aptitude::CmdLine::Verbose 1;
Acquire::http::No-Cache true;
Acquire::PDiffs true;


I think that we discussed this many times already... debtags depends on
python3-debian and python3-apt for example, which in turn might be
recommended by other packages, depending on the state of the system.

If a recommended package is installed by any means, it doesn't get
auto-removed -- aptitude doesn't know if it was installed on purpose or
not, or if the user started to depend on it since it was installed, so
conservatively it's not removed.  Otherwise, the removal of any package
could trigger removals of any other packages kept only for being
recommended packages -- and many people rely on this behaviour to keep
packages installed untill all rev-depends that recommend it are removed.

So this is not going to be changed, it's a characteristic (or undesired
behaviour, depending on how one sees it) of Debian and the system of
dependencies.

Another reason can be mishandled auto-flags, in which case there are
lots of bugs about this already.

If you can provide more info which is not any of this cases please
reopen, but in the meantime I'm closing it because it's almost surely a
dupe of one of the cases above.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#841313: latex-cjk-japanese-wadalab: FTBFS: Create .afm and .pfa fonts from dg. \n Segmentation fault (core dumped)

[Hilmar Preuße]

Am 19.10.2016 um 17:20 schrieb Danai SAE-HAN (韓達耐):

Hi all,


It looks like a problem with the wftodm binary.  This is an important piece
in the creation of the fonts.
I will only have access to my PC next week Thursday (27 October 2016) to
check the C source code and replicate it on amd64.  Please bear with me for
a while.


I *think* I can reproduce the bug.

Here is the gdb backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x2ba08dfdbda3 in _IO_vfprintf_internal (s=s@entry=0x7ffd926eb3f0,
format=, format@entry=0x5643d866b22e "/StdHW [ %s ] 
|-\n",

ap=ap@entry=0x7ffd926eb518) at vfprintf.c:1637
#2  0x2ba08dffcacb in __IO_vsprintf (
string=0x7ffd926eb620 "/StdHW [ re{16 16} |-\n",
format=0x5643d866b22e "/StdHW [ %s ] |-\n", 
args=args@entry=0x7ffd926eb518)

at iovsprintf.c:42
#3  0x2ba08dfe2327 in __sprintf (s=, 
format=)

at sprintf.c:32
#4  0x5643d866a8e2 in e_printf (form=, i0=out>,

i1=, i2=, i3=,
i4=, i5=1936353124, i6=-1838284703, i7=0, 
i8=-1909291776,

i9=0) at wftodm.c:306
#5  0x5643d866aa77 in output_pfa (file=1) at wftodm.c:255
#6  0x5643d8669d3a in main (ac=, ag=)
at wftodm.c:158

And here is the function e_printf() in question:

e_printf(form,i0,i1,i2,i3,i4,i5,i6,i7,i8,i9)
char *form;
{
  int len,i;
  unsigned char buf[4096];
  sprintf(buf,form,i0,i1,i2,i3,i4,i5,i6,i7,i8,i9);
  len=strlen(buf);
  for(i=0;i

Bug#839923: [phpmyadmin] Failed opening required '/usr/share/php/php-gettext/gettext.inc

[James Stricherz]

Package: phpmyadmin
Version: 4:4.6.4+dfsg1-1
Followup-For: Bug #839923

Dear Maintainer,

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

Hi, this is what I did to "fix" the problem locally.

cd /usr/share/php
mv php-gettext php-gettext.orig
ln -s php-php-gettext php-gettext

symbolic linking within the original php-gettext/gettext.inc doesn't
work and generates the error, but linking directory to directory does
work. Of course, it will break things once the problem is fixed
formally, so before updating you may want to reverse those changes.

Additionally this was also in my /var/log/apache2/error.log:

 open_basedir restriction in
 effect. File(/usr/share/php/php-php-gettext/gettext.inc) is not
 within the allowed path(s):
 
(/usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/)
 in /usr/share/phpmyadmin/libraries/common.inc.php on line 77

Hope that helps.

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


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.6.0-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages phpmyadmin depends on:
ii  dbconfig-common 2.0.6
ii  dbconfig-mysql  2.0.6
ii  debconf [debconf-2.0]   1.5.59
ii  libjs-sphinxdoc 1.4.6-1
ii  perl5.24.1~rc3-3
ii  php 1:7.0+45
ii  php-cli 1:7.0+45
pn  php-gettext 
ii  php-mbstring1:7.0+45
ii  php-mysql   1:7.0+45
ii  php-phpseclib   2.0.3-1
ii  php-xml 1:7.0+45
ii  php7.0 [php]7.0.11-1
ii  php7.0-cli [php-cli]7.0.11-1
ii  php7.0-json [php-json]  7.0.11-1
ii  php7.0-mbstring [php-mbstring]  7.0.11-1
ii  php7.0-xml [php-xml]7.0.11-1
ii  ucf 3.0036

Versions of packages phpmyadmin recommends:
ii  apache2 [httpd]   2.4.23-5
ii  php-bz2   1:7.0+45
ii  php-gd1:7.0+45
ii  php-tcpdf 6.2.12+dfsg2-1
ii  php-zip   1:7.0+45
ii  php7.0-bz2 [php-bz2]  7.0.11-1
ii  php7.0-gd [php-gd]7.0.11-1
ii  php7.0-zip [php-zip]  7.0.11-1

Versions of packages phpmyadmin suggests:
ii  chromium [www-browser]   53.0.2785.143-1
ii  elinks [www-browser] 0.12~pre6-11+b3
ii  lynx [www-browser]   2.8.9dev9-1
ii  mysql-server-5.6 [virtual-mysql-server]  5.6.30-1
ii  w3m [www-browser]0.5.3-29

-- Configuration Files:
/etc/phpmyadmin/config.inc.php changed [not included]

-- debconf information excluded