Bug#540436: eyed3: divides by zero on some files

[Gaetano Guerriero]

I know this is very old, but,

can I have access to data to reproduce the bugs.

Else, given that the code is completely changed since reporting, I'll close it.


 Gaetano

Bug#882209: [Pkg-zfsonlinux-devel] Bug#882209: zfs-linux: remove manual calls to dpkg-architecture and dpkg-parsechangelog

[Fabian Grünbichler]

On Thu, Nov 23, 2017 at 09:50:40PM +0800, Aron Xu wrote:
> Hi
> 
> On Mon, Nov 20, 2017 at 5:16 PM, Fabian Grünbichler
>  wrote:
> > Source: zfs-linux
> > Severity: wishlist
> > Tags: patch
> >
> > please see attached patches for cleaning up debian/rules a bit. the
> > resulting binary packages are bitwise identical.
> >
> 
> When does DEB_VERSION_UPSTREAM being introduced? Will this change
> affect the package's backportability?
> 

should be available at least back to Jessie:

http://sources.debian.net/src/dpkg/1.17.27/scripts/mk/pkg-info.mk/

(I only actually tried Sid and Stretch though)

Bug#882487: thunderbird: Thunderbird won't start - not even with .thunderbird deleted

[Carsten Schoenert]

On Thu, Nov 23, 2017 at 09:35:41PM +, Nuno Oliveira wrote:
> Hi Carsten,
...
> > Starting Thunderbird with the option '--debug' gives at least some more
> > information if something is already going wrong before Thunderbird will
> > be called itself.
> > 
> 
> No information printed, except:
> 
> nuno@host:~$ thunderbird --debug
> [calBackendLoader] Using Thunderbird's builtin libical backend
> Warning: unrecognized command line flag -debug

sorry, I mean 'thunderbird --verbose'.
The man page helps in such situations.

> >  $ sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird
> 
> That does the trick.. Thunderbird now starts ok.

Naa, that's not a trick. Now AppArmor isn't working for Thunderbird any
longer. So Think it's clearly a issue within the thunderbird profile of
AppArmor.

> > Also I suspect then some messages about denied access by apparmor.
> > 
> >  $ sudo journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"'
> 
> No output here. Thanks,

Now the profile is disabled you want see any denied messages any longer
for thunderbird.

Regards
Carsten

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Vincent Bernat]

 ❦ 24 novembre 2017 02:44 +0100, Nicolas Braud-Santoni 
 :

> I am looking for a sponsor for my package "nq"
>
>  * Package name: nq
>Version : 0.2.1-1
>Upstream Author : Leah Neukirchen 
>  * URL : https://github.com/chneukirchen/nq
>  * License : CC0
>Section : utils

In d/changelog: you forgot to include the ITP bug number.

In d/copyright: you need to include the complete CC0 license.

You override the debian-watch-may-check-gpg-signature, but you also need
to override orig-tarball-missing-upstream-signature. Since the tooling
to check signatures the way you need it is not here, an alternative
would be to not ship upstream GPG signature.

Also, I don't care about the use of short commands like fq, nq, tq (they
are currently free), but that's something others may feel is
inappropriate. You could keep them as is and see if the upload is
accepted by FTP masters.
-- 
Debian package sponsoring guidelines:
 https://vincent.bernat.im/en/debian-package-sponsoring


signature.asc
Description: PGP signature

Bug#882580: ruby-mmap2: please make the build reproducible

[Chris Lamb]

Source: ruby-mmap2
Version: 2.2.7-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because the install target (yes!) builds something using GCC
and then we include the log of that build which contains the absolute
build path.

Patch attached that cleans this log - we have buildd.d.o after all.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2017-11-24 15:19:33.929600214 +0900
--- b/debian/rules  2017-11-24 15:23:58.023131209 +0900
@@ -7,3 +7,7 @@
 
 %:
dh $@ --buildsystem=ruby --with ruby
+
+override_dh_auto_install:
+   dh_auto_install
+   find debian/ -name mkmf.log -delete

Bug#882579: landslide: please make the build reproducible

[Chris Lamb]

Source: landslide
Version: 1.1.3-0.0
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because the tests don't clear up enough after themselves
leaving a "presentation.html" file around which happens to include
the absolute build path.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2017-11-24 15:06:55.279397736 +0900
--- b/debian/rules  2017-11-24 15:17:59.229108616 +0900
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 export PYBUILD_BEFORE_TEST := ln -s $(CURDIR)/src/landslide/test-data 
{build_dir}/landslide
-export PYBUILD_AFTER_TEST := rm {build_dir}/landslide/test-data
+export PYBUILD_AFTER_TEST := rm {build_dir}/landslide/test-data 
{build_dir}/presentation.html
 
 %:
dh $@ --with python2 --buildsystem=pybuild

Bug#864873: dgit-maint-merge man page should expand on debianization of upstreams releasing tarballs

[Johannes Schauer]

Quoting Sean Whitton (2017-11-24 03:39:28)
> > I'd just like to avoid having to maintain a *second* git repository next to
> > the dgit-repos. Isn't there a way to create a new empty upstream branch on
> > the fly at the point where the maintainer wants to import a new upstream
> > release?  [...] Because at that point, the maintainer did "dgit clone" and
> > has the current upstream tarball available which could be used to set up an
> > upstream branch with just the old upstream version in it as a single
> > commit, no?
> I'm not sure whether or not something like this could be done.  It breaks
> assumptions of gbp-import-orig(1), which expects an upstream branch always to
> be present.  I understand your desire to avoid a second git repo, but I don't
> want to incorporate that into the manpage.  I want to keep the usage of
> gbp-import-orig(1) as straightforward as possible, and that requires pushing
> to alioth.
> 
> I think you'll find that you will want to push to alioth anyway, for WIP
> commits between uploads.

Your argument is sound. Thus, lets consider this bug being fixed once the use
of a second git repo is detailed.

Unfortunately we are getting rid of alioth these days so the documentation
might have to change soon. XD

Though it seems this problem will also resolve itself with #848678 at which
point no secondary git repo is necessary anymore and the whole discussion about
the disadvantage of one becomes moot.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#882578: pymongo: please make the build reproducible

[Chris Lamb]

tags 882578 + fixed-upstream
thanks

This was fixed upstream here:

  
https://github.com/mongodb/mongo-python-driver/commit/e95a9ae47826f655f94d72cea91717dce5948cc2


Regards,

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

Bug#882578: pymongo: please make the build reproducible

[Chris Lamb]

Source: pymongo
Version: 3.5.1+dfsg1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/doc/conf.py b/doc/conf.py
index 676e876..b15e49c 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -9,7 +9,7 @@ sys.path[0:0] = [os.path.abspath('..')]
 
 import pymongo
 
-import datetime
+import time, datetime
 
 # -- General configuration 
-
 
@@ -28,9 +28,12 @@ source_suffix = '.rst'
 # The master toctree document.
 master_doc = 'index'
 
+build_date = datetime.datetime.utcfromtimestamp(
+ int(os.environ.get('SOURCE_DATE_EPOCH', time.time(
+
 # General information about the project.
 project = u'PyMongo'
-copyright = u'MongoDB, Inc. 2008-{0}. MongoDB, Mongo, and the leaf logo are 
registered trademarks of MongoDB, Inc'.format(datetime.date.today().year)
+copyright = u'MongoDB, Inc. 2008-{0}. MongoDB, Mongo, and the leaf logo are 
registered trademarks of MongoDB, Inc'.format(build_date.year)
 html_show_sphinx = False
 
 # The version info for the project you're documenting, acts as replacement for

Bug#882538: outguess: missing source for jpeg-6b-steg/configure

[Paul Wise]

On Thu, 23 Nov 2017 19:21:35 -0200 Eriberto wrote:

> It not seems a code without a source code. The code can't be
> regenerated from a configure.ac but it can be modified to work if it
> is necessary. It is similar to a traditional configure file, made by
> hand. I can't see a real problem here. IMO, there is an editable
> source code and is all right.

The file in question is clearly generated from something else:

# Generated automatically using autoconf version 2.12 

Looks like it is generated from a configure.in file:

# Any additions from configure.in:
ac_help="$ac_help
  --enable-shared build shared library using GNU libtool"
ac_help="$ac_help
  --enable-static build static library using GNU libtool"
ac_help="$ac_help
  --enable-maxmem[=N] enable use of temp files, set max mem usage to N 
MB"
ac_help="$ac_help
"

https://sources.debian.net/src/outguess/1:0.2-8/jpeg-6b-steg/configure

Helmut is correct, this is a violation of DFSG item 2 and the
ftp-master policy on generated files.

https://ftp-master.debian.org/REJECT-FAQ.html
https://www.debian.org/social_contract#guidelines

> I think that are several similar packages in Debian.

Please name them so that RC bugs can be filed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#881920: xerces-c: FTBFS on hurd-i386: ThreadTest15 failed

[Bill Blough]

After running the tests in a loop for many hours, I have encountered 2
issues.

The first is an assertion failure in ext2fs that causes the entire
system to freeze (#882507).  Based on the build log, this isn't the
issue in question, but it's definitely a problem (and it made
troubleshooting much more frustrating).

The second is an exception being thrown due to a call to getcwd()
failing.  I believe that this is the issue that caused the test failure
referenced in the build log.  However, getcwd is returning "No such file
or directory" but the directory clearly exists, and as such, I'm not sure how
this is happening.  I'm wondering if this is somehow related to the
ext2fs issues, or maybe load-related.

I've requested a binNMU for xerces-c on hurd to see what happens.

Bug#882577: adjtimex FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Package: adjtimex
Version: 1.29-9
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

adjtimex fails to cross build from source, because its Makefile fails to
use the compiler discovered by ./configure. Instead it uses the make
default "cc". After adding the CC=@CC@ substitution to Makefile.in,
adjtimex cross build successfully. Please consider applying the attached
patch.

Helmut
Index: adjtimex-1.29/Makefile.in
===
--- adjtimex-1.29.orig/Makefile.in
+++ adjtimex-1.29/Makefile.in
@@ -4,6 +4,7 @@
 
 VERSION=1.29
 
+CC = @CC@
 CFLAGS += @CFLAGS@ -Wall
 prefix = @prefix@
 man1dir=@mandir@/man1

Bug#882576: nmu: xerces-c_3.2.0+debian-2

[William Blough]

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

Hi,

xerces-c is in transition (#881127) and has built successfully on all
archs except hurd.  However, based on my research into the failure, I
believe this failure may be transient, and would like to request a
binNMU for hurd arch only.

Thanks,
Bill

nmu xerces-c_3.2.0+debian-2 . hurd . unstable . -m "Rebuild due to suspected 
transient failure"



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

Kernel: Linux 4.9.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)

Bug#882575: dman: support selecting which section to view the manual page from

[Paul Wise]

Package: debian-goodies
Version: 0.76
Severity: wishlist
File: /usr/bin/dman

It would be nice to be able to select which section to view the manual
page from. Currently with `dman crontab` I get the crontab command-line 
manual page but sometimes I want to look up the crontab syntax/format.
I can look that up locally with `man 5 crontab` but `dman 5 crontab`
gives the crontab command-line manual page and prints an error on exit.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#882382: [Debian-med-packaging] Bug#882382: first step to fix the r-cran-epi autopkg tests

[Graham Inggs]

Control: reopen -1

Hmm, now the test just goes into an endless loop, see:
https://ci.debian.net/packages/r/r-cran-epi/unstable/amd64/

Bug#882574: dman: support selecting which section to view the manual page from

[Paul Wise]

Package: debian-goodies
Version: 0.76
Severity: wishlist
File: /usr/bin/dman

It would be nice to be able to select which package to view the manual
page from. Currently with `dman crontab` I get the systemd-cron package
but most of the time I want the cron version of the manual page. Being
able to select the right package would help avoid this.

https://manpages.debian.org/stretch/cron/crontab.1.en.html
https://manpages.debian.org/stretch/systemd-cron/crontab.1.en.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#882573: mutt: displays text/html raw again instead of using mailcap

[Bob Proulx]

Package: mutt
Version: 1.9.1-3
Severity: normal

With the lastest package we now have a regression of Bug#823971
https://bugs.debian.org/823971 where viewing text/html parts is
displayed as the raw html instead of using mailcap.  At the previous
bug report time it was determined to be the loss of
611410-no-implicit_autoview-for-text-html.patch caused this.

There is also Bug#816706 https://bugs.debian.org/816706 which explains
the original rationale for dropping this patch.  In summary because
this was behavior added in a patch and upstream implemented the
functionality in a different way.  With the latest version I read
/usr/share/doc/mutt/NEWS.Debian.gz and see that this reversion to
upstream is considered a necessary change.

It was also noted that there are (at least) two ways of achieving this
behavior in the stock upstream.

1) Use the 'm' key to use the view-mailcap action.

2) Add "auto_view text/html" to the muttrc to force viewing using mailcap.

I am sending this bug report because I it appeared as a bug regression
of Bug#823971 and I am sure will to others but reading the NEWS file I
am swayed toward learning and using the upstream behavior.  Therefore
I am okay with either using 'm' to view the part instead of Return or
configuring the "auto_view text/html" configuration.  However noting
there are other viewpoints I will attempt to CC other recipients that
I know have an interest.

To help users like me surprised by this it would be useful to add to
the NEWS file with specific hints of this change.  Therefore I might
suggest something similar to this added to the NEWS file in the next
upload.

  Due to the switch to upstream mutt some behaviors will have changed.
  This includes the patch implementing implicit autoview of text/html
  parts upon Return.  The upstream behavior makes use of either 'm' to
  explicitly view parts using mailcap or setting "auto_view text/html"
  to enable it explicitly.

Thank you for maintaining mutt in Debian.

Bob

-- Package-specific info:
Mutt 1.9.1 (2017-09-22)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.13.0-1-amd64 (x86_64)
ncurses: ncurses 6.0.20170902 (compiled with 6.0)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-16' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-g
 nu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-16) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-lua' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--enable-notmuch' 
'--disable-fmemopen' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' 
'--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' 
'--without-qdbm' '--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 
'CFLAGS=-g -O2 -fdebug-prefix-map=/build/mutt-3aGhu3/mutt-1.9.1=. 
-fstack-protector-strong -Wformat -Werror=format-security' 
'LDFLAGS=-Wl,-z,relro -W
 l,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-3aGhu3/mutt-1.9.1=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:

Bug#882572: libfreesrp: FTBFS on hurd-i386: semaphore_t does not name a type

[Aaron M. Ucko]

Source: libfreesrp
Version: 0.3.0-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

Thanks for taking care of #882514 quickly!  Alas, the hurd-i386 build
still fails, with a cascade of errors stemming from

  /<>/src/readerwriterqueue/atomicops.h:408:7: error: 
'semaphore_t' does not name a type; did you mean 'Semaphore'?

>From what I gather, the Hurd doesn't yet support POSIX semaphores. :-/

Could you please take a look?

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#881066: Info received (Message for Antoine mojn)

[Antoine Ivy]

Im not sure what this is for ?

Sent from my iPhone

> On Nov 23, 2017, at 5:18 PM, Debian Bug Tracking System 
>  wrote:
> 
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
> Debian Mirrors Team 
> 
> If you wish to submit further information on this problem, please
> send it to 881...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 881066: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881066
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#882571: kactivities-bin: Activities fail to remember associated applications

[MH]

Package: kactivities-bin
Version: 5.37.0-2
Severity: normal

Dear Maintainer,

After logging out of a session then logging back in, some applications will
load across all activities, not just the one they were associated with. This
appears to occur totally randomly. Sometimes applications load correctly,
sometimes not. This happens regularly on two different computers, both 
running Debian Buster.


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

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

Versions of packages kactivities-bin depends on:
ii  libc6  2.24-17
ii  libkf5activities5  5.37.0-2
ii  libqt5core5a   5.9.1+dfsg-9
ii  libstdc++6 8-20170923-1

kactivities-bin recommends no packages.

kactivities-bin suggests no packages.

-- no debconf information

Bug#864873: dgit-maint-merge man page should expand on debianization of upstreams releasing tarballs

[Sean Whitton]

Hello Johannes,

On Fri, Nov 24 2017, Johannes Schauer wrote:

> all the software I maintain indeed has upstream using git. My reason for still
> relying on tarballs is the software that has DFSG-nonfree material in their 
> git
> repositories. I rather not deal with the legal implications and have my git
> repos DFSG-clean.
>
> A second reason is, that just "git rm evil.bin" seems quite error prone.
> Usually the DFSG-nonfree material sits in dozens of files everywhere across 
> the
> project source code. The Files-Excluded in debian/copyright is a nice way to
> declare all paths to exclude from the upstream source. With a git-based
> workflow I'm on my own to store somewhere which files I want to exclude.

Yes, this is reasonable for packages with lots of DFSG problems.

> I'd just like to avoid having to maintain a *second* git repository next to 
> the
> dgit-repos. Isn't there a way to create a new empty upstream branch on the fly
> at the point where the maintainer wants to import a new upstream
> release?
> [...]
> Because at that point, the maintainer did "dgit clone" and has the
> current upstream tarball available which could be used to set up an
> upstream branch with just the old upstream version in it as a single
> commit, no?

I'm not sure whether or not something like this could be done.  It
breaks assumptions of gbp-import-orig(1), which expects an upstream
branch always to be present.  I understand your desire to avoid a second
git repo, but I don't want to incorporate that into the manpage.  I want
to keep the usage of gbp-import-orig(1) as straightforward as possible,
and that requires pushing to alioth.

I think you'll find that you will want to push to alioth anyway, for WIP
commits between uploads.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#882570: bash: Color Prompt is Forced by bashrc color_prompt=yes outside of the force_color_prompt block

[Rob]

Package: bash
Version: 4.4-5
Severity: minor

Dear Maintainer,

The comments in the ~/.bashrc or /etc/skel/.bashrc file have 
force_color_prompt=yes commented 
by default. So as I'm reading it I should not have a color prompt. However, the 
case statement

29  # set a fancy prompt (non-color, unless we know we "want" color)
30  case "$TERM" in
31  xterm-color|*-256color) color_prompt=yes;;
32  esac

defines color_prompt=yes

So I end up with a color prompt as my $TERM matches. (In jessie the case was 
different and did not match).
I'm using the xterm on MacOS via SSH.

I expected to not have a color prompt unless I uncommented:
36  #force_color_prompt=yes

Perhaps lines 30-32 could be commented out by default? Or move that case into 
the force_color_prompt if block.



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

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

Versions of packages bash depends on:
ii  base-files   9.9+deb9u2
ii  dash 0.5.8-2.4
ii  debianutils  4.8.1.1
ii  libc62.24-11+deb9u1
ii  libtinfo56.0+20161126-1+deb9u1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#882569: ITP: extrace -- trace exec() calls system-wide

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: extrace
  Version : 0.4
  Upstream Author : Leah Neukirchen 
* URL : https://github.com/chneukirchen/extrace
* License : BSD
  Programming Lang: C
  Description : trace exec() calls system-wide

extrace traces all program executions occurring on a system.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloXfjkZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z43Q0D/wNxK2UsvJqEN0TXTuXI3Tz
qWh8J/XlZLptZMxX0y1derEy0Gf1oLxrPtOKgdogqWVodi6VcwwnQHqqe6UrjuCW
zGB47Skf9YZVHWP42sji3zYV6EWwrsimZYFqea39k1lbS40KxdN4KNEgGfpzYwaP
Wy6AyfarbpvjwDVaiA96fLtUHGKDbni5vmIJbCcXpgFeaK1sjcLfxrBPTQYAJawy
JDPlHh7O8JSwWrM4Ag/S2yG/mmg+ZR7vicMpTrld56KCNVlGsWpvLKUotjTyERO0
Ds8u7szMf5v8e4Hbk3LTMxvsedbU9IHYWNtLrvmimNXW7ilh6oFbUOq2B8DAoift
Xs/yUBDX/sgesWFsCpbjliUMYmbgRV8PlOOotpN91alV4f8LVF+YCVnX5XysJ0QM
EW55p9Pbgn41gToCmrCk8gVu+TSCavaU5Irc3OvBLzPljAaQ2D5rfwWaFPDT+t6T
ztPE2WVkYrJVAJ2uLxMc+PzvyRBaKXsY3kkDy6127D3syQx6AvHdLgRswvZkp1xZ
t6prjwOYmf/+jsAVBV/keIQiv50/Ghdl8TYQZOkK4qhLIDagmm3HVrciGHl4cLLE
DOb+pJ/Yi1kfAKj8Hdt+fdVBkXq5qA+e25JPv0KdUajM3eCdEXV2hBVcEGyFSKUn
awx1FEXOuGW7eJ5Oei0FTA==
=t0Ta
-END PGP SIGNATURE-

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Nicolas Braud-Santoni]

Package: sponsorship-requests
Severity: wishlist
Control: block 882567 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

I am looking for a sponsor for my package "nq"

 * Package name: nq
   Version : 0.2.1-1
   Upstream Author : Leah Neukirchen 
 * URL : https://github.com/chneukirchen/nq
 * License : CC0
   Section : utils

It builds those binary packages:

  nq- Lightweight queue system

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

  https://mentors.debian.net/package/nq


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

  dget -x https://mentors.debian.net/debian/pool/main/n/nq/nq_0.2.1-1.dsc


Regards,
 Nicolas Braud-Santoni

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

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.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)

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloXeWcZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z41hHEACMlbQ7lpMz29Ye9Ue+JN94
CYns2tLK5gVYWaKVfWd1wyp7v182bulZv6y2+RgToRaDvy8XCZw1H9MAqK3fgT5P
Zbg6dJP64v6qbG0vl6vOl6nQeT6nBKVkgWplXcUrwPOG9sN+eo/O6S3tncnQAZtk
e1oy1WZz503VipIaHkYQf0m2lkyFxR8zzOtDngLTNCQ4JoxR3/ygy7WlqlQtNfdA
tskJM55dJvXhXW4nGce134511baG91ltTBQaVIANBZZtQSOAGrcmwNNySyOdgwjp
liXfEeTKFvCx88xF3vsBZxvqMx7mUZKtADAwMDHvjDwR2MvydvTFDHGQ41QpDK2Q
R9R607EFr57+5kUXwMW4/vJVN0gaIY/39qepUkurC0al3F5saufD8P2lMJ2J8Eu+
W/+ZoUPsgdxFyW+xhQLehPW+75+8zzeaKuddD5Tcs079nnVMw+E0Dj5MRg6ZEW8k
ZycxqqNkOiMS6OL1AFeKbGFx2bfP+kx56LLj4Rm9pzBXhq5X7DiuixfsUUNxmvCK
lcYnhWn69uKvIrphSfK9ejDD0+PE/YQIkT8wiaJTNaSLA/ECBWJ28UmYRcK9yu89
mXPCc/XRT0MNUptMCjnrvCy25tqJXdACaed2uyO/gHqzJZQyVIErVaNti7VdXmR4
TIoaRtJ8tyrq4p9EJcVPDQ==
=2pRn
-END PGP SIGNATURE-

Bug#882567: ITP: nq -- Lightweight queue system

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: nq
  Version : 0.2.1
  Upstream Author : Leah Neukirchen 
* URL : https://github.com/chneukirchen/nq
* License : CC0
  Programming Lang: C
  Description : Lightweight queue system

 These small utilities allow creating very lightweight job queue
 systems which require no setup, maintenance, supervision, or any
 long-running processes.
 .
 `nq` should run on any POSIX.1-2008 compliant system which also
 provides a working flock(2).  Tested on Linux 2.6.37, Linux 4.1,
 OpenBSD 5.7, FreeBSD 10.1, Mac OS X 10.3 and
 SmartOS joyent_20160304T005100Z.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloXd6QZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z4zbmD/9etCkuX7BBKONv5P7WfEbx
yND/XaEIUoQAaZCQaTSJ9mtcprcH8mDTfQCfHcTsec5eALCwuhGvgnKe30e8e1O8
vWEdwebJLOOhJsfC8YUBqJwaFAtvjR/aTgC0OCDVTMim+hbWXj9d1rv2mSlF/MgM
NvE8UugsmihxewEWFfY/uUWiqg+CrQVmtj3XoGQflwB8FgP/np6hi7yX7I8khl1O
CQ0lgaNt1wuk6i5PT86InixktDZ1wdDyzV6fscGhNCMFEA8cPbvf6sHt6XQIT49Y
92YpQK/ygBr5xq6RFIaODrenHwaGlw2NKbaEGCB+hMUbP3T2R1BKMNsI/CnQmFQV
YXeg44O/rvFI7OB4CJQI5Y388wNDQsCnKf2eLnxnrryrZIp29PebKEcfte2jwuOh
vAl4CLJHIk/RlEH2JbOZB7nz7foe0Uss2JY9lfhQGCNplz2V3pxfaVOHKch8JQKc
Sb1r+bOb8fuaPDSH+077pesWGHOYI4Y/iPWAcF1SC7ZRN/c21QhLW/Jx1ZAeJaha
5LMt5/Sm/dRmFGVu1MeyyNn6H7GsNRKuqLBh8fA3DXNeKm7BNVyp7Os5kK6cyDju
uHrL0x9nhQ85gavCsujORYNKZnWYjbQcgmKsR2HBGNDYgbN/MdNHjy7uMmnZVYzj
9jFK1kprPiY6etFoWX7Mgw==
=hjR8
-END PGP SIGNATURE-

Bug#882566: ITP: quickcal -- Quickcal is a Fast and Easy to use Calculator

[Nathan SR]

Package: wnpp
Severity: wishlist
Owner: Nathan SR 

* Package name: quickcal
  Version : 1.0
  Upstream Author :
* URL : https://sourceforge.net/projects/quickcal/
* License : GPL
  Programming Lang: Python
  Description : Quickcal is a Fast and Easy to use Calculator

Quickcal is a Fast and Easy to use Calculator, for performing Arithmetic
and Statistical Calculations, at just the click of a button. It allows
quick pasting of a large set of numbers, seperated with newlines or
spaces or tabs and performs calculations based on the button pressed. As
in other calculators, basic math can be performed too, with the
+,-,*,/,%,^ operators, in between numbers. Setting the Scale allows for
more decimals to be displayed. Also, about 65 Statistical Calculations
can be performed by choosing an option from the More Stats List Box.

Bug#882565: RFS: lr/1.2-1 -- list files, recursively

[Nicolas Braud-Santoni]

Package: sponsorship-requests
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

I am looking for a sponsor for my package "lr"

  * Package name: lr
Version : 1.2-1
Upstream Author : Leah Neukirchen 
  * URL : https://github.com/chneukirchen/lr
  * License : MIT
Section : utils

It builds those binary packages:

  lr- list files, recursively

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

  https://mentors.debian.net/package/lr


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

  dget -x https://mentors.debian.net/debian/pool/main/l/lr/lr_1.2-1.dsc


Changes since the last upload:

  * New upstream version (2017-11-17)
* Performance improvements
* `-U` now supports default width
* New features
  * -B option for breadth-first search
  * New ternary `?:` operator
  * New `skip` action


Regards,

  nicoo


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

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.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)

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloXdnwZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z4+y2D/0ROpPrT/R2PX9P0vG7WKPy
xhqF9PIniwUJdFBRLe7TwW/5UM3pHuj0cyPgNgmxVXWZDpqNdEUOYsOP+XDE3uh0
kC3D+qpkx9cof8ZtX9LmUvOb509AS1oqxi8+vXlSmb+M6KkyX+OUZVr1tFF7Wzb1
x5vUXiIiDQF6rsf7q5YyaEGDcSDFkIszZxqwQNC/iFSTPTd2WHEWqtw03hdKP1UH
WFOfyhha6LZV8nFRiLuE1nw2KpQQg2Um0JoLWBu9/xi3pCnvyAUS5MU8bq77qNoA
u48q0psmUaYqH75Sv5k/q632+Q+445er9TEHKyjHHOZrHcNgK6mYJzkT4mpFuSKu
TnfXqrNd4ZnwmpGOhVP7QOaKOlkWcMO8alZ3zq+J7oIyYQzFAgzk9c9sT5jQiISq
pyJYcblI90sv3iM8PDLlyCG/sXaEqyNn3ZHYbRejYp1p4Rq1GzX/ob7RyHYBQpdN
npsiU6MLHNOYCHbi44Y6+inPP4G3O2NxIh9m10xAO+RAlqTg5Jhg84NEVIBN1nPE
zoMzHJa5q9LoJyNpRQrGRN6otVCsNFHogLMKCV+l2YNa7qD0+fGMl28KTrfGmE57
5BPTRt0M2PoVITJJZ9BeZvjzj8sDnqDheQ5t4z+yOk7gCL8LlEv7+u/v+g0wBCv+
TDVqaWm++zB/ZEXvJgEysQ==
=ycIt
-END PGP SIGNATURE-

Bug#881066: Message for Tim GVY2

[Timothy Merk]

I ain't your Fuk'n dear!!

On Nov 23, 2017 10:32 AM, "Pre Thanksgiving sales" 
wrote:

> Hello Dear!
>
> Welcome to Amazon Final Notice For Amazon Rewards
>
> You've been chosen by Amazon to receive a $50 reward!
>
> Click here to get started
>
>
> 
>
>
> You may unsubscribe at any time here
> 
>
>
> unsubscribehere
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Peter, We are sorry for the incident, have just manually run the sync,
> could you p= lease check if the mirror is up-to-date now? Thanks -- Mak
> Kuen Seng Support Team Lead IP SERVERONE SOLUTIONS SDN BHD A-1-1, Block A,
> Glomac Damansara Jalan Damansara, 6 Kuala Lumpur Tel: 603 2026 1688 |
> Fax: 603 7728 3188 Ticket History 
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Peter Palfrader (Client) Posted On: 07 November 2017 10:48 PM
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Package: mirrors User:
> mirr...@packages.debian.org Usertags: mirror-problem may-auto-close
> Control: submitter -1 mirr...@debian.org Hi! According to
> https://mirror-master.debian.org/status/mirror-info/debian.ipserverone.com=
> .html
> 
> your mirror is out of date by over a week. Please investigate. --=20 |
> .''`. ** Debian ** Peter Palfrader | : :' : The universal
> https://www.palfrader.org/ | `. `' Operating System | `-
> https://www.debian.org/ Ticket Details -
> Ticket ID: QMM-573-27544 Department: Support Type: Issue Status: Replied
> Priority: Normal Helpdesk: https://support.ipserverone.com/index.php?

Bug#882537: biber FTBFS:

[Norbert Preining]

> # -  \\field{sortinithash}{f615fb9c6fba11c6f962fb3fd599810e}
> # +  \\field{sortinithash}{07bbd5a529b5beaa311df5be05b874bc}

Yeah, usual mix up between libunicode-collate-perl as shipped with
perl internally and with extra module.

Did you install libunicode-collate-perl package or used the perl
internal provided?

It is very unfortunate that perl provides a package but is not 100%
compatible with it.

Norbert

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

Bug#882563: golang-go: Please build for s390x

[Philipp Kern]

Hi,

On 11/24/2017 01:14 AM, Jeremy Bicha wrote:
> golang-go was briefly built on s390x a year but was disabled because
> upstream go only supports relatively newer s390x and because it was
> shortly before the release of Debian 9 "Stretch".
> 
> There is conversation on https://bugs.debian.org/844258 about maybe
> bumping the minimum supported baseline for s390x or asking IBM if they
> want to invest in getting Go working on older s390x. That bug was
> closed because the main focus of that bug was fixed. So I'm opening a
> new bug.

I think it's pretty clear that IBM is not interested in supporting these
new workloads on older machines (which for all points and purposes was
Docker). On the other hand there was also more direct investment made by
IBM into making some software perform better on newer s390x machines
rather than "just" paying Linux vendors to do so.

I'm at this point still not sure what the right answer here can be. [0]
suggests that z10 BC/EC could be completely unsupported in two years
time or so, but it is not today. I suppose from IBM's point of view the
whole point of follow-on service is to keep the existing services
running, not to enable new ones.

I suppose there are at least three options:

a) Depend on some sort of architectural support metapackage. This solves
the problem of missing runtime support. It does not yet solve the
problem on the builder side (where one is still a z10[1]). It might also
push us into a dependency hell where packages pick up dependencies on
such a metapackage and then a large part becomes uninstallable. The
relatively unavailability of golang-go across various Debian ports makes
this unlikely, though.

b) Get resources somewhere to port the instruction generator to a
different baseline. I know Aurelien has tried but I also think it's
unfair to expect from him to do this work. Especially when most of the
benefit here is to have it in Debian so that Ubuntu/Canonical has less
work to do.

c) Settle with a GCC-based Go on s390x instead of the reference
implementation and make that work somehow. I'm not sure what the
blockers there would be but that would seem to be theoretically
beneficial to various other ports as well.

Kind regards
Philipp Kern

[0]
https://www-03.ibm.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/74f007db22182c6b86257e06006f7a73/$FILE/IBM%20Mainframe%20Life%20Cycle%20History%20V2.0b%20-%20July%2017,%202017.pdf
[1] Which I'd be willing to retire.



signature.asc
Description: OpenPGP digital signature

Bug#861062: clarify -C on man page

[積丹尼 Dan Jacobson]

Nice.

Bug#882563: golang-go: Please build for s390x

[Jeremy Bicha]

Package: golang-go
Version: 2:1.9~1
Severity: wishlist
X-Debbugs-CC: debian-s...@lists.debian.org

golang-go was briefly built on s390x a year but was disabled because
upstream go only supports relatively newer s390x and because it was
shortly before the release of Debian 9 "Stretch".

There is conversation on https://bugs.debian.org/844258 about maybe
bumping the minimum supported baseline for s390x or asking IBM if they
want to invest in getting Go working on older s390x. That bug was
closed because the main focus of that bug was fixed. So I'm opening a
new bug.

Thanks,
Jeremy Bicha

Bug#738260: xpilot-ng-common: Please replace ttf-freefont by fonts-freefont-ttf in package dependencies

[peter green]

tags 738260 +pending
severity 738260 serious
thanks



The package provides a transitional package but we would like to drop
it and therefore we need packages that depend on ttf-freefont to
switch their dependency to fonts-freefont-ttf.

The transitional package is no longer built by its source package. I have 
uploaded a NMU changing the dependency in this package to delayed/5. Debdiff is 
attatched.

Bug#839008: scribus no longer finds DejaVu fonts

[Hartmut Buhrmester]

Apparently, this is caused by a bug in the FreeType library 
libfreetype6. An upstream bug report says:



This is a bug caused by some FreeType versions which fail when loading
some glyphs outlines and make us consider some fonts as broken. At
least FreeType 2.6.0 to 2.6.3 are affected. FreeType 2.6.5 was
fixed. Unfortunately Debian 9 has FreeType 2.6.3. If you upgrade
FreeType to >= 2.6.5, you will have to clear scribus font cache.


- https://bugs.scribus.net/view.php?id=15042

Bug#882506: [Pkg-fonts-devel] Bug#882506: Bug#882506: fonts-noto-mono: glitch with "fi" and "fl" sequences

[Adam Borowski]

On Thu, Nov 23, 2017 at 11:08:10PM +, Medical Wei wrote:
> Rather than saying it is a bug it is actually a ligature [1] feature to
> squish texts together. There should be the software using the font to
> disable the feature if you need alignment.

If this shows in a font that's supposed to be monospaced, it is a bug.  The
font must not make replacements that change the length of a string (ie,
anything with wcwidth = 0 must not advance, wcwidth = 1 must advance by 1,
wcwidth = 2 must advance by 2[1]).

That is, a font must never squish "fi" and "fl" into one position; a
ligature can be used but only if it is rendered into a width of two
(FiraCode has a lot of ligatures obeying this constraint, although its
implementation causes unrelated problems).  If you want the ligature to be
squished, Unicode provides a way to do so: U+FB01 U+FB02 (fi fl).

The above obviously applies only to monospaced, variable-spaced has no
concept of a character cell, thus anything goes.

> > Package: fonts-noto-mono
> > Version: 20171026-2
> >
> > The sequences "fi" and "fl" are displayed incorrectly with Noto Sans
> > Mono (working with size 11 here, pressed for time, can't remember if so
> > with other sizes).
> >
> > Specifically, "f" followed by either "i" or "l" get squished together,
> > taking the width of a single character. Very annoying, not just
> > visually, but also aligning code to 80 chars.


[1]. There are some normative issues with wcwidth: see the yellow text on
https://www.unicode.org/reports/tr11/tr11-34.html which says current
implementations abuse a property that is not supposed to be used this way.
-- 
< darkling> When all you have is a hammock, every problem looks like a nap.

Bug#872240: python-expyriment NMU is in delayed/5.

[peter green]

tags 872240 +pending
tags 882560 +pending
thanks

I have uploaded a NMU for python-expyriment to delayed/5 adding the missing 
build-dependency and fixing the freefont dependency.


diff -Nru python-expyriment-0.7.0+git34-g55a4e7e/debian/changelog 
python-expyriment-0.7.0+git34-g55a4e7e/debian/changelog
--- python-expyriment-0.7.0+git34-g55a4e7e/debian/changelog 2017-01-13 
19:24:35.0 +
+++ python-expyriment-0.7.0+git34-g55a4e7e/debian/changelog 2017-11-23 
22:52:31.0 +
@@ -1,3 +1,12 @@
+python-expyriment (0.7.0+git34-g55a4e7e-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build-dependency on latexmk for Sphinx 1.6 (Closes: #872240)
+  * Replace dependency on obsolete transitional package ttf-freefont with
+fonts-freefont-ttf (Closes: #882560)
+
+ -- Peter Michael Green   Thu, 23 Nov 2017 22:52:31 +
+
 python-expyriment (0.7.0+git34-g55a4e7e-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-expyriment-0.7.0+git34-g55a4e7e/debian/control 
python-expyriment-0.7.0+git34-g55a4e7e/debian/control
--- python-expyriment-0.7.0+git34-g55a4e7e/debian/control   2017-01-13 
19:24:33.0 +
+++ python-expyriment-0.7.0+git34-g55a4e7e/debian/control   2017-11-23 
22:48:40.0 +
@@ -2,7 +2,7 @@
 Section: science
 Priority: optional
 Maintainer: Oliver Lindemann 
-Build-Depends: debhelper (>= 9.0.0), dh-python, python-all, python-sphinx, 
python-pygame (>= 1.9.1~), python-opengl (>= 3.0.0), texlive-latex-recommended, 
texlive-latex-extra, texlive-fonts-recommended, texlive-generic-extra, help2man
+Build-Depends: debhelper (>= 9.0.0), dh-python, python-all, python-sphinx, 
python-pygame (>= 1.9.1~), python-opengl (>= 3.0.0), texlive-latex-recommended, 
texlive-latex-extra, texlive-fonts-recommended, texlive-generic-extra, 
help2man, latexmk
 Standards-Version: 3.9.5
 Homepage: http://www.expyriment.org
 Vcs-Git: git://anonscm.debian.org/debian-science/packages/python-expyriment.git
@@ -10,7 +10,7 @@
 
 Package: python-expyriment
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, python (>= 2.6), python-pygame 
(>= 1.9.1~), python-opengl (>= 3.0.0), ttf-freefont, libjs-jquery, 
libjs-underscore
+Depends: ${misc:Depends}, ${python:Depends}, python (>= 2.6), python-pygame 
(>= 1.9.1~), python-opengl (>= 3.0.0), fonts-freefont-ttf, libjs-jquery, 
libjs-underscore
 Recommends: python-serial (>= 2.5~), python-numpy (>= 1.3.0~)
 Suggests: python-parallel (>= 0.2), python-pyxid
 Description: Python library for cognitive and neuroscientific experiments

Bug#882561: pyelliptic: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: pyelliptic
Version: 1.5.7-1.1
Severity: serious
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans
Control: block 871056 by -1

Please migrate to libssl-dev in the Buster cycle. I am very sorry for
this late report but this package was never on my list. It slipped
because it never B-D on libssl1.0-dev.

Sebastian

Bug#882562: telepathy-qt: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: telepathy-qt
Version: 0.9.6.1-6.1
Severity: serious
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans
Control: block 871056 by -1

Please migrate to libssl-dev in the Buster cycle. I am very sorry for
this late report but this package was never on my list. It slipped
because it never B-D on libssl1.0-dev.

Sebastian

Bug#877403: stretch-pu: package dbus/1.10.24-0+deb9u1

[Cyril Brulebois]

Simon McVittie  (2017-11-23):
> On Thu, 23 Nov 2017 at 12:18:00 +, Adam D. Barratt wrote:
> > This was uploaded and I was going to accept it, but then our tooling
> > reminded me that dbus produces a udeb.
> 
> dbus-udeb and libdbus-1-3-udeb were requested because there was a plan
> to use AT-SPI in the graphical installer. I don't know whether this ever
> happened. https://wiki.debian.org/DebianInstaller/Accessibility doesn't
> document any features that seem AT-SPI-related (other than hearing Orca
> after installation, which doesn't need udebs), but perhaps it's out
> of date?

We don't have big enough a team to guarantee we have a comprehensive or
up-to-date documentation… anyway, I've just checked that there's nothing
that seems to depend on either udebs in stretch, so feel free to go
ahead with an accept.


KiBi.


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Sebastian Andrzej Siewior]

On 2017-11-23 17:09:09 [+0200], Adrian Bunk wrote:
> On Thu, Nov 23, 2017 at 01:57:58PM +, Ian Jackson wrote:
> > 2. For the reason just mentioned, it might be a good idea to put in a
> >Breaks against old versions of packages using
> >CURLOPT_SSL_CTX_FUNCTION.  However, (a) I am not sure if this is
> >actually necessary
> 
> See #846908 for an example where it is necessary.
#844018 has some history and was the reason for curl to stay with 1.0

> >(b) in any case I don't have a good list of all
> >the appropriate versions
> 
> Kurt did search for affected packages a year ago,
> so the information about affected packages in
> stretch should already be available.
> 
> Note that such Breaks won't work for backported packages.

I did a grep and it seems that all affected users are blocked by
#858398 except for hhvm. All of them seem to touch
CURLOPT_SSL_CTX_FUNCTION and ask for libssl1.0-dev.

I skipped some others (while doing the grep just now) which should not
be an issue (like `cargo' but it depends on libssl-dev and
libcurl4-gnutls-dev or `sx' which uses it only in its configure script
or `cmake', r-cran-rcurl, curlpp  which do not link against libssl,…).

> cu
> Adrian

Sebastian

Bug#864873: dgit-maint-merge man page should expand on debianization of upstreams releasing tarballs

[Johannes Schauer]

Hi Sean,

Quoting Sean Whitton (2017-11-23 22:36:35)
> Heh, sorry, I've not yet used the workflow for a real upstream that
> releases only tarballs; I've only tested gbp-import-orig(1) in
> artificial scenarios.

all the software I maintain indeed has upstream using git. My reason for still
relying on tarballs is the software that has DFSG-nonfree material in their git
repositories. I rather not deal with the legal implications and have my git
repos DFSG-clean.

A second reason is, that just "git rm evil.bin" seems quite error prone.
Usually the DFSG-nonfree material sits in dozens of files everywhere across the
project source code. The Files-Excluded in debian/copyright is a nice way to
declare all paths to exclude from the upstream source. With a git-based
workflow I'm on my own to store somewhere which files I want to exclude.

> I think that what you are hitting is the recent change of
> gbp-import-orig(1)'s default from --merge-mode=merge to --merge-mode=replace.
> 
> For this workflow we want --merge-mode=merge, so that git-merge(1)
> handles the re-application of the Debian changes for us (that's the
> whole point of the workflow, after all).  So I will add
> 
> [import-orig]
> merge-mode = merge
> 
> to the recommended gbp.conf.
> 
> If you want to test, you could just pass --merge-mode=merge to
> gbp-import-orig(1).

I'm afraid I cannot test that because I happened to have thrown away my old
upstream branch. And with that gbp.conf, "gbp import-orig" is not doing the
right thing. I suppose that's because my workaround for the missing upstream
branch was to create it as a duplicate of my master branch (which has the
patches applied).

> > And a related side question (that maybe should also have an answer in the
> > man page): What are the recommendations for the upstream branch?  For "When
> > upstream tags releases in git" you write "here is no need to maintain a
> > separate 'upstream' branch" but does this also hold for "When upstream
> > releases only tarballs"? Because if I don't push the upstream branch to
> > anywhere, then the steps under "NEW UPSTREAM RELEASES" will fail because
> > "gbp import-orig" doesn't see an upstream branch. So maybe the man page
> > could also expand on the need for an upstream branch if upstream releases
> > tarball and recommendations on where and when it should be pushed or how
> > one can do without it. For example maybe the question can be answered
> > whether the upstream branch can be pushed to dgit-repos or whether alioth
> > has to be used for that.
> 
> Yes indeed, you need to maintain an upstream branch if upstream releases
> only tarballs.  The manpage currently suggests that pushing that branch
> to alioth is optional, but as you say, it is actually required in order
> for future gbp-import-orig(1) calls to succeed.
> 
> I will expand that section to say that you must push the upstream branch
> somewhere; eventually dgit-repos, but until that is possible (#848678), to
> alioth.

I'd just like to avoid having to maintain a *second* git repository next to the
dgit-repos. Isn't there a way to create a new empty upstream branch on the fly
at the point where the maintainer wants to import a new upstream release?
Because at that point, the maintainer did "dgit clone" and has the current
upstream tarball available which could be used to set up an upstream branch
with just the old upstream version in it as a single commit, no? That way, the
upstream branch could be thrown away because it could be recreated every time
it is needed (when gbp import-orig is run).


signature.asc
Description: signature

Bug#881066: Message for Antoine mojn

[Antoine Ivy]

?

Sent from my iPhone

> On Nov 7, 2017, at 7:53 PM, Pre Thanksgiving sales  
> wrote:
> 
> Hi Peter,
> 
> We are sorry for the incident, have just manually run the sync, could you 
> please check if the mirror is up-to-date now?
> 
> Thanks
> 
> --
> 
> Mak Kuen Seng
> Support Team Lead
> 
> IP SERVERONE SOLUTIONS SDN BHD
> A-1-1, Block A, Glomac Damansara
> Jalan Damansara, 6 Kuala Lumpur
> 
> Tel: 603 2026 1688 | Fax: 603 7728 3188 
> 
> 
> Ticket History
> Peter Palfrader (Client) Posted On: 07 November 2017 10:48 PM
> 
> Package: mirrors
> User: mirr...@packages.debian.org
> Usertags: mirror-problem may-auto-close
> Control: submitter -1 mirr...@debian.org
> 
> Hi!
> 
> According to
> https://mirror-master.debian.org/status/mirror-info/debian.ipserverone.com.html
> your mirror is out of date by over a week.
> 
> Please investigate.
> --
> | .''`. ** Debian **
> Peter Palfrader | : :' : The universal
> https://www.palfrader.org/ | `. `' Operating System
> | `- https://www.debian.org/
> 
> 
> 
> 
> Ticket Details
> Ticket ID: QMM-573-27544
> Department: Support
> Type: Issue
> Status: Replied
> Priority: Normal
> Remark: Kindly be informed that this ticket will be auto close after 48 hours 
> of inactivity. If you still need assistance, please reopen this ticket by 
> replying to this email. If you encounter with different issues, kindly submit 
> a new ticket for new questions. This helps us track issues better and improve 
> our overall support services.
> 
> Disclaimer: Privileged/confidential information may be contained in this 
> message. If you are not the named recipient or addressee, you are hereby 
> notified that any use review, disclosure or copying of the contents herein is 
> strictly prohibited. In such a case, kindly discard all its contents and 
> notify sender accordingly regarding such unauthorized disclosure or 
> transmission by email. Opinions, conclusions, statements and other 
> information in this message that do not relate to the official business of IP 
> SERVERONE SOLUTIONS SDN BHD shall be understood as neither given or endorsed 
> by it. The contents herein are meant strictly for the use of the named 
> recipient or addressee of IP SERVERONE SOLUTIONS SDN BHD. No assumption of 
> responsibility or liability whatsoever is undertaken by IP SERVERONE 
> SOLUTIONS SDN BHD in respect of prohibited and unauthorized use by any other 
> person.
> 
> 

Bug#882506: [Pkg-fonts-devel] Bug#882506: fonts-noto-mono: glitch with "fi" and "fl" sequences

[Medical Wei]

Rather than saying it is a bug it is actually a ligature [1] feature to
squish texts together. There should be the software using the font to
disable the feature if you need alignment.

By the way, macOS font Monaco have the same behavior as far as I am aware.

[1]: https://en.m.wikipedia.org/wiki/Typographic_ligature
於 2017年11月23日 週四，23:06寫道：

> Package: fonts-noto-mono
> Version: 20171026-2
>
> The sequences "fi" and "fl" are displayed incorrectly with Noto Sans
> Mono (working with size 11 here, pressed for time, can't remember if so
> with other sizes).
>
> Specifically, "f" followed by either "i" or "l" get squished together,
> taking the width of a single character. Very annoying, not just
> visually, but also aligning code to 80 chars.
>
> Screenshot of "fi" sequence attached, since noticed "fl" also, have not
> noticed any other sequences doing this. Have not noticed any other
> fonts doing this. Happens both in gedit and libreoffice.
>
> Working on a 3200x1800 HiDpi display in Gnome with scaling @
> 2.___
> Pkg-fonts-devel mailing list
> pkg-fonts-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-fonts-devel

Bug#882507: ext2fs: assertion error

[Bill Blough]

Apologies for that. I somehow missed the newer image.

I just tried debian-hurd-20171101.img and got the exact same behavior -
same error message, freeze, etc.

Bug#882454: gerbera: FTBFS on hurd-i386: Gerbera was unable to deterimine the host OS.

[James Cowgill]

Control: tags -1 fixed-upstream

Hi,

On 23/11/17 03:53, Aaron M. Ucko wrote:
> Source: gerbera
> Version: 1.1.0+dfsg-2
> Severity: important
> Tags: upstream
> Justification: fails to build from source
> User: debian-h...@lists.debian.org
> Usertags: hurd-i386
> 
> Builds of gerbera for hurd-i386 (admittedly not a release
> architecture) have been failing per the below excerpt from
> https://buildd.debian.org/status/fetch.php?pkg=gerbera=hurd-i386=1.1.0%2Bdfsg-2=1511312309=0:
> 
>   CMake Error at CMakeLists.txt:314 (message):
> Gerbera was unable to deterimine the host OS.  Please report this.  Value
> of CMAKE_SYSTEM_NAME: GNU
> 
> Could you please take a look?  With any luck, the Linux settings will
> make a decent starting point.

Should be fixed upstream in:
https://github.com/gerbera/gerbera/commit/29149374c3684659f73f19cb8c1486ab4258c1be

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#738224: freevial: Please replace ttf-freefont by fonts-freefont-ttf in package dependencies

[peter green]

Given the lack of maintainer response to this bug I have uploaded a NMU. 
Debdiff attatched.


diff -u freevial-1.3/debian/control freevial-1.3/debian/control
--- freevial-1.3/debian/control
+++ freevial-1.3/debian/control
@@ -19,7 +19,7 @@
  python-pygame (>= 1.7),
  python-lxml,
  fonts-unfonts-core | ttf-unfonts-core | ttf-unfonts,
- ttf-freefont
+ fonts-freefont-ttf
 XB-Python-Version: ${python:Versions}
 Description: trivia platform for community events
  Freevial is a platform for trivia-like games, designed to be used on
diff -u freevial-1.3/debian/changelog freevial-1.3/debian/changelog
--- freevial-1.3/debian/changelog
+++ freevial-1.3/debian/changelog
@@ -1,3 +1,10 @@
+freevial (1.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace ttf-freefont dependency with fonts-freefont-ttf (closes: 738224).
+
+ -- Peter Michael Green   Thu, 23 Nov 2017 22:37:37 +
+
 freevial (1.3-2) unstable; urgency=low
 
   * debian/control:

Bug#882560: python-expyriment depends on obsolete transitional package.

[peter green]

package: python-expyriment
severity: serious

python-expyriment still depends on the transitional package ttf-freefont which 
is no longer bulit by it's source package. The dependency needs to be updated 
so it can be decrufted.

I intend to put together a NMU for this issue and for the existing rc bug.

Bug#882559: python-xarray FTBFS - GenericNetCDFDataTest.test_cross_engine_read_write_netcdf3 failed

[Rebecca N. Palmer]

Package: python3-xarray
Version: 0.9.2-1
Severity: serious
Control: tags -1 upstream

Two netcdf tests fail in current sid (see log below).

This is known upstream as https://github.com/pydata/xarray/issues/1721 , 
according to which the actual problem is that scipy has been writing 
netcdf files with invalid padding for some time ( 
https://github.com/scipy/scipy/pull/8170 ), and netcdf 4.5 rejects such 
invalid files ( https://github.com/Unidata/netcdf-c/issues/657 ).


netcdf have since reverted this change, and a patch has been posted for 
the original scipy bug, but given that neither of these are xarray's 
fault it might make most sense to temporarily disable these tests.


=== FAILURES 
===
__ GenericNetCDFDataTest.test_cross_engine_read_write_netcdf3 
__


self = testMethod=test_cross_engine_read_write_netcdf3>


def test_cross_engine_read_write_netcdf3(self):
data = create_test_data()
valid_engines = set()
if has_netCDF4:
valid_engines.add('netcdf4')
if has_scipy:
valid_engines.add('scipy')

for write_engine in valid_engines:
for format in ['NETCDF3_CLASSIC', 'NETCDF3_64BIT']:
with create_tmp_file() as tmp_file:
data.to_netcdf(tmp_file, format=format,
   engine=write_engine)
for read_engine in valid_engines:
with open_dataset(tmp_file,
> engine=read_engine) as actual:

xarray/tests/test_backends.py:977:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

xarray/backends/api.py:291: in open_dataset
autoclose=autoclose)
xarray/backends/netCDF4_.py:210: in __init__
self.ds = opener()
xarray/backends/netCDF4_.py:185: in _open_netcdf4_group
ds = nc4.Dataset(filename, mode=mode, **kwargs)
netCDF4/_netCDF4.pyx:2015: in netCDF4._netCDF4.Dataset.__init__
???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _


>   ???
E   OSError: [Errno -36] NetCDF: Invalid argument: 
b'/tmp/tmpmgjj7gx5/temp-88.nc'


netCDF4/_netCDF4.pyx:1636: OSError
___ 
GenericNetCDFDataTestAutocloseTrue.test_cross_engine_read_write_netcdf3 


self = testMethod=test_cross_engine_read_write_netcdf3>


def test_cross_engine_read_write_netcdf3(self):
data = create_test_data()
valid_engines = set()
if has_netCDF4:
valid_engines.add('netcdf4')
if has_scipy:
valid_engines.add('scipy')

for write_engine in valid_engines:
for format in ['NETCDF3_CLASSIC', 'NETCDF3_64BIT']:
with create_tmp_file() as tmp_file:
data.to_netcdf(tmp_file, format=format,
   engine=write_engine)
for read_engine in valid_engines:
with open_dataset(tmp_file,
> engine=read_engine) as actual:

xarray/tests/test_backends.py:977:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

xarray/backends/api.py:291: in open_dataset
autoclose=autoclose)
xarray/backends/netCDF4_.py:210: in __init__
self.ds = opener()
xarray/backends/netCDF4_.py:185: in _open_netcdf4_group
ds = nc4.Dataset(filename, mode=mode, **kwargs)
netCDF4/_netCDF4.pyx:2015: in netCDF4._netCDF4.Dataset.__init__
???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _


>   ???
E   OSError: [Errno -36] NetCDF: Invalid argument: 
b'/tmp/tmpfc4acgiv/temp-93.nc'


netCDF4/_netCDF4.pyx:1636: OSError

(followed by a few more failures that look like #871208 - see there)

Bug#882064: etherape: [INTL:de] German translation update

[Chris Leick]

Hi Patrick,

only the version number in my translation is wrong. It should be 
9.15+hg20171110-1

Please change this version number.

Kind regards,
Chris



Patrick Matthäi:

tag 882064 + moreinfo
tag 882064 + upstream
thanks

Am 18.11.2017 um 12:39 schrieb Chris Leick:

Package: etherape
Version: 0.9.12
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the updated German translation.

Kind regards,
Chris


Hi Chris,

thanks for it. But 0.9.12 is a six years old release.
Could you please recheck/update your updated po against this release:
http://deb.debian.org/debian/pool/main/e/etherape/etherape_0.9.15+hg20171110-1.dsc

Then I also could send it to upstream
--
/*
Mit freundlichem Gruß / With kind regards,
  Patrick Matthäi
  GNU/Linux Debian Developer

   Blog:http://www.linux-dev.org/
E-Mail:pmatth...@debian.org
 patr...@linux-dev.org
*/

Bug#871208: python-xarray tests failures

[Rebecca N. Palmer]

Control: tags -1 upstream fixed-upstream

This appears to be 2 separate bugs, both triggered by using pandas 0.20 
and fixed upstream.


groupby_bins:
https://github.com/pydata/xarray/issues/1386
https://github.com/pydata/xarray/pull/1390

test_sel: this is really a pandas bug (fixed in 0.21, but this version 
isn't in Debian yet) but has a workaround in xarray:

https://github.com/pandas-dev/pandas/issues/16896
https://github.com/pydata/xarray/pull/1479

Both fixes are in the 0.10 upstream release, but be aware that this is a 
mildly API-breaking release 
(http://xarray.pydata.org/en/latest/whats-new.html#breaking-changes).

Bug#882558: override: kdevplatform-l10n:oldlibs/optional, kdevplatform-dev:oldlibs/optional

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

since kdevelop 5.2, kdevplatform is merged there, and thus
kdevplatform-l10n, and kdevplatform-dev are transitional packages.

Thanks,
-- 
Pino

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Thu, Nov 23, 2017 at 07:10:51PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Proposed (lib)curl switch to openssl 1.1"):
> > What I suggest above would be a transition that should be coordinated
> > with the release team like other transitions.
> 
> I'm not 100% opposed to doing this as a normal library transition with
> a soname change.  I don't feel I understand the tradeoffs well.

Well, one downside is that doing a full blown transition is likely to take
more work and time to see it completed. Unfortunately I don't have the time
required and can't commit to doing this myself.

I do agree it's the correct solution though, and it would be a good opportunity
to finally sync SONAME with upstream (last time a transition of libcurl was
attempted some 10 years or so ago, it was halted for reasons now lost in the
mists of time, so we have been stuck carrying some hacks to pretend we are
still using the old SONAME, see e.g. [0] [1]).

Cheers

[0] 
https://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/patches/03_keep_symbols_compat.patch
[1] 
https://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/libcurl3.links


signature.asc
Description: PGP signature

Bug#882417: mariadb-10.1: FTBFS on arm64 (internal compiler error)

[Sebastiaan Couwenberg]

On 11/23/2017 12:05 AM, Ondřej Surý wrote:
> The fix in -3 was wrong and so was the one in -4 :(, but I finally got
> all the pieces in -5 upload that's coming up.

-5 & -6 are looking much better, thanks!

Kind Regards,

Bas

Bug#882557: signon-ui FTBFS on amd64: SignOnUiTest::testRequestWithIndicator() Received signal 11

[Adrian Bunk]

Source: signon-ui
Version: 0.17+15.10.20150810-2
Severity: serious
Tags: buster sid

Some recent change in unstable makes signon-ui FTBFS on amd64:

https://tests.reproducible-builds.org/debian/history/signon-ui.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/signon-ui.html

...
xvfb-run -a dbus-test-runner -t ./signon-ui-unittest
DBus daemon: 
unix:abstract=/tmp/dbus-ir0GtGjIfq,guid=9df47cbca994084f2c07bdba5c244d8b
task-0: Started with PID: 59957
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-pbuilder1'
task-0: * Start testing of SignOnUiTest *
task-0: Config: Using QtTest library 5.9.2, Qt 5.9.2 (x86_64-little_endian-lp64 
shared (dynamic) release build; by GCC 7.2.1 20171025)
task-0: PASS   : SignOnUiTest::initTestCase()
task-0: PASS   : SignOnUiTest::testRequestObjects()

= Received signal, dumping stack ==
task-0: GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
task-0: Copyright (C) 2016 Free Software Foundation, Inc.
task-0: License GPLv3+: GNU GPL version 3 or later 

task-0: This is free software: you are free to change and redistribute it.
task-0: There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
task-0: and "show warranty" for details.
task-0: This GDB was configured as "x86_64-linux-gnu".
task-0: Type "show configuration" for configuration details.
task-0: For bug reporting instructions, please see:
task-0: .
task-0: Find the GDB manual and other documentation resources online at:
task-0: .
task-0: For help, type "help".
task-0: Type "apropos word" to search for commands related to "word".
task-0: Attaching to process 59957
task-0: [New LWP 59968]
task-0: [New LWP 59976]
task-0: [New LWP 59978]
task-0: [New LWP 59979]
task-0: [New LWP 59980]
task-0: [New LWP 59981]
task-0: [New LWP 59982]
task-0: [Thread debugging using libthread_db enabled]
task-0: Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".
task-0: 0x7f029987d40a in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
task-0: (gdb) 
task-0: Thread 8 (Thread 0x7f0273fff700 (LWP 59982)):
task-0: #0  0x7f02998aab69 in syscall () at /lib/x86_64-linux-gnu/libc.so.6
task-0: #1  0x7f02a013b7fa in g_cond_wait_until ()
task-0: at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #2  0x7f02a00ca2e1 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #3  0x7f02a011dfd4 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #4  0x7f02a011d635 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #5  0x7f029a422517 in start_thread ()
task-0: at /lib/x86_64-linux-gnu/libpthread.so.0
task-0: #6  0x7f02998af82f in clone () at /lib/x86_64-linux-gnu/libc.so.6
task-0: 
task-0: Thread 7 (Thread 0x7f02888c7700 (LWP 59981)):
task-0: #0  0x7f02998a583d in poll () at /lib/x86_64-linux-gnu/libc.so.6
task-0: #1  0x7f02a00f6159 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #2  0x7f02a00f64f2 in g_main_loop_run ()
task-0: at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #3  0x7f02a06e7ad6 in  () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
task-0: #4  0x7f02a011d635 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #5  0x7f029a422517 in start_thread ()
task-0: at /lib/x86_64-linux-gnu/libpthread.so.0
task-0: #6  0x7f02998af82f in clone () at /lib/x86_64-linux-gnu/libc.so.6
task-0: 
task-0: Thread 6 (Thread 0x7f02890c8700 (LWP 59980)):
task-0: #0  0x7f02998a583d in poll () at /lib/x86_64-linux-gnu/libc.so.6
task-0: #1  0x7f02a00f6159 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #2  0x7f02a00f626c in g_main_context_iteration ()
task-0: at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #3  0x7f02a00f62b1 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #4  0x7f02a011d635 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
task-0: #5  0x7f029a422517 in start_thread ()
task-0: at /lib/x86_64-linux-gnu/libpthread.so.0
task-0: #6  0x7f02998af82f in clone () at /lib/x86_64-linux-gnu/libc.so.6
task-0: 
task-0: Thread 5 (Thread 0x7f02898c9700 (LWP 59979)):
task-0: #0  0x7f029a428f33 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
task-0: at /lib/x86_64-linux-gnu/libpthread.so.0
task-0: #1  0x7f029a978438 in QWaitCondition::wait(QMutex*, unsigned long) 
()
task-0: at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
task-0: #2  0x7f029b030802 in  () at 
/usr/lib/x86_64-linux-gnu/libQt5Test.so.5
task-0: #3  0x7f029a97714d in  () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
task-0: #4  0x7f029a422517 in start_thread ()
task-0: at /lib/x86_64-linux-gnu/libpthread.so.0
task-0: #5  0x7f02998af82f in clone () at /lib/x86_64-linux-gnu/libc.so.6
task-0: 
task-0: Thread 4 (Thread 0x7f028a0ca700 (LWP 59978)):
task-0: #0  0x7f02998a583d in poll () at 

Bug#882556: Remnant ntp's Apparmor profile prevents openntpd from working

[Simon Deziel]

Package: openntpd
Version: 1:6.2p3-1
Severity: low

Hi,

When someone purges the ntp package to then install openntpd, it is
possible for ntp's Apparmor profile to remain loaded in the kernel after
the corresponding /etc/apparmor.d/ file was removed. This prevents
openntpd's from working or even detecting the old profile's file. For
all the details, please see the original bug as reported to Ubuntu [1].

Please consider applying the patch from Christian Ehrhardt [2] to ensure
a smoother transition from ntp to openntpd.

Thank you,
Simon

[1] https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1689585
[2] https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1689585/comments/13



signature.asc
Description: OpenPGP digital signature

Bug#882555: r-cran-ddalpha: FTBFS on m68k: no boost::math::Rlog1p

[Aaron M. Ucko]

Source: r-cran-ddalpha
Version: 1.3.1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-m...@lists.debian.org
Usertags: m68k

The build of r-cran-ddalpha for m68k (admittedly not a release
architecture) failed:

  g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG  
-I"/usr/lib/R/site-library/Rcpp/include"-fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-vkBOGA/r-base-3.4.2.20171120=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -c Polynomial.cpp -o Polynomial.o
  In file included from /usr/lib/R/site-library/Rcpp/include/RcppCommon.h:72:0,
   from /usr/lib/R/site-library/Rcpp/include/Rcpp.h:27,
   from stdafx.h:27,
   from Polynomial.cpp:14:
  /usr/include/boost/math/special_functions/log1p.hpp: In static member 
function 'static void boost::math::detail::log1p_initializer::init::do_init(const mpl_::int_<64>&)':
  /usr/share/R/include/Rmath.h:76:15: error: 'Rlog1p' is not a member of 
'boost::math'
   #define log1p Rlog1p
 ^
  /usr/share/R/include/Rmath.h:76:15: note: suggested alternative: 'log1p'
  /usr/lib/R/etc/Makeconf:168: recipe for target 'Polynomial.o' failed
  make[1]: *** [Polynomial.o] Error 1

Could you please take a look?

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#875590: Pending fixes for bugs in the junit4 package

[pkg-java-maintainers]

tag 875590 + pending
thanks

Some bugs in the junit4 package are closed in revision
d34a6a69317d622da7cbb70d4c899ed78f2259ad in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/junit4.git/commit/?id=d34a6a6

Commit message:

Fixed the build failure with Java 9 (Closes: #875590)

Bug#882445: Proposed change of offensive packages to -offensive

[Sean Whitton]

Hello David,

On Thu, Nov 23 2017, David Kalnischkies wrote:

> On Wed, Nov 22, 2017 at 05:18:37PM -0700, Sean Whitton wrote:
>> >   "cowsay-offensive".  In this situation the "-offensive" package can
>> >   be Suggested by the core package(s), but should not be Recommended
>> >   or Depended on, so that it is not installed by default.
>   ^^
>
> While it seems to be a reasonable explanation for why it should be at most
> a suggests, this half-sentence is hardcoding behaviour of a specific
> package manager in its current default configuration into policy.
>
> "Installed by default" is something policy is speaking of in the context of
> priorities only. In the context of dependency relations it is speaking
> only about how reasonable it is for the average user of a package to not
> install this other package [which can, but doesn't need to be the same].
>
> Personally, I would vote for just dropping the half sentence as the use of
> Suggests follows directly from its definition – as the whole point of a
> maintainer introducing an -offensive package is very likely that it is
> "perfectly reasonable" to not install it: Why introducing it otherwise?

Thank you for your feedback.  I see what you mean.

I second the patch revised to exclude this half-sentence.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#882554: golang-google-grpc FTBFS: stringer: checking package: code_string.go:5:8: could not import fmt (can't find import: )

[Adrian Bunk]

Source: golang-google-grpc
Version: 1.6.0-2
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-google-grpc.html

...
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/build/1st/golang-google-grpc-1.6.0'
# grpc_testingv3/testv3.pb.go is not re-generated because it was
# intentionally generated by an older version of protoc-gen-go.
# comments from upstream in code
rm -v -f stress/grpc_testing/metrics.pb.go health/grpc_health_v1/health.pb.go 
interop/grpc_testing/test.pb.go test/codec_perf/perf.pb.go 
test/grpc_testing/test.pb.go reflection/grpc_testing/proto2_ext2.pb.go 
reflection/grpc_testing/proto2.pb.go reflection/grpc_testing/test.pb.go 
reflection/grpc_testing/proto2_ext.pb.go 
reflection/grpc_reflection_v1alpha/reflection.pb.go 
stats/grpc_testing/test.pb.go benchmark/grpc_testing/payloads.pb.go 
benchmark/grpc_testing/messages.pb.go benchmark/grpc_testing/stats.pb.go 
benchmark/grpc_testing/services.pb.go benchmark/grpc_testing/control.pb.go 
examples/helloworld/helloworld/helloworld.pb.go 
examples/route_guide/routeguide/route_guide.pb.go 
grpclb/grpc_lb_v1/messages/messages.pb.go 
grpclb/grpc_lb_v1/service/service.pb.go
removed 'stress/grpc_testing/metrics.pb.go'
removed 'health/grpc_health_v1/health.pb.go'
removed 'interop/grpc_testing/test.pb.go'
removed 'test/codec_perf/perf.pb.go'
removed 'test/grpc_testing/test.pb.go'
removed 'reflection/grpc_testing/proto2_ext2.pb.go'
removed 'reflection/grpc_testing/proto2.pb.go'
removed 'reflection/grpc_testing/test.pb.go'
removed 'reflection/grpc_testing/proto2_ext.pb.go'
removed 'reflection/grpc_reflection_v1alpha/reflection.pb.go'
removed 'stats/grpc_testing/test.pb.go'
removed 'benchmark/grpc_testing/payloads.pb.go'
removed 'benchmark/grpc_testing/messages.pb.go'
removed 'benchmark/grpc_testing/stats.pb.go'
removed 'benchmark/grpc_testing/services.pb.go'
removed 'benchmark/grpc_testing/control.pb.go'
removed 'examples/helloworld/helloworld/helloworld.pb.go'
removed 'examples/route_guide/routeguide/route_guide.pb.go'
removed 'grpclb/grpc_lb_v1/messages/messages.pb.go'
removed 'grpclb/grpc_lb_v1/service/service.pb.go'
go generate ./...
stringer: checking package: code_string.go:5:8: could not import fmt (can't 
find import: )
codes/codes.go:26: running "stringer": exit status 1
debian/rules:16: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 1

Bug#837366: [Aptitude-devel] Bug#837366: aptitude: Crash when typing while saying "Updating ... and quitting" (found in 0.8.10-1)

[Axel Beckert]

Control: found -1 0.8.10-1

Hi,

Axel Beckert wrote:
> I just ran into #837366 with 0.8.4-1, hence reopening it:
> 
> Writing extended state information  10[1]27840 
> segmentation fault (core dumped)  aptitude -u

Today I accidentially typed into the wrong window (probably "!g") and
hit that bug with with 0.8.10-1 on i386:

---8<---
┌──┐
 
│Updating state and quitting...│
 
└──┘
 

 

 

 

 

 

 

 

 

 

 
Ouch!  Got SIGSEGV, dying.. 
 
Segmentation fault
--->8---

Unfortunately I found no according coredump for a backtrace despite
corekeeper is installed on that system.

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

Bug#882487: thunderbird: Thunderbird won't start - not even with .thunderbird deleted

[Nuno Oliveira]

Hi Carsten,

* Carsten Schoenert  [2017-11-23 20:02]:

Hello René,

On Thu, Nov 23, 2017 at 01:44:14PM +0100, René Seindal wrote:

Package: thunderbird
Version: 1:52.4.0-2~exp1
Severity: important

Dear Maintainer,

I cannot get thunderbird to start on a fairly newly instaled debian testing 
laptop.

On a newly booted computer:

rene $ killall -1 thunderbird
thunderbird: no process found
rene $ killall -1 icedove
icedove: no process found
rene $ rm -r .thunderbird
rene $ thunderbird

just gives me a dialog with the message:

"Thunderbird is already running, but is not responding. To open a new window, you 
must first close the existing Thunderbird process, or restart your system."

I have tried using an old profile, a new profile, safe mode, removing 
.thunderbird and .icedove totally, ... to no avail.

Thunderbird won't start.  I have no idea what to do next, and google doesn't 
help much.


Starting Thunderbird with the option '--debug' gives at least some more
information if something is already going wrong before Thunderbird will
be called itself.



No information printed, except:

nuno@host:~$ thunderbird --debug
[calBackendLoader] Using Thunderbird's builtin libical backend
Warning: unrecognized command line flag -debug


I have tried packages from stable, testing and experimental, all the same.

-- System Information:

...

Versions of packages thunderbird suggests:
ii  apparmor  2.11.1-3
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.15.2-2


You have installed apparmor. Have you tried to disable the AppArmor
profile for Thunderbird and check for the further existence of the issue?

 $ sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird


That does the trick.. Thunderbird now starts ok.


Also I suspect then some messages about denied access by apparmor.

 $ sudo journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"'


No output here. Thanks,

Nuno.

Bug#864873: dgit-maint-merge man page should expand on debianization of upstreams releasing tarballs

[Sean Whitton]

Hello Johannes,

On Thu, Nov 23 2017, Johannes Schauer wrote:

> Quoting Sean Whitton (2017-11-23 01:25:19)
>> On Thu, Nov 23 2017, Johannes Schauer wrote:
>> > Another section that could be improved in the dgit-maint-merge man page is
>> > "NEW UPSTREAM RELEASES" "When upstream releases only tarballs".
>> >
>> > After running "gbp import-orig" the master branch will contain the new
>> > upstream version but changes from debian/patches are not applied. The
>> > man page could expand on best practices on how to carry over changes
>> > from the last upstream version to the new upstream version.
>> Right.  It should at least say that this action needs to be taken.
>>
>> What are the best practices you mention?
>
> I was actually hoping that as the master mind behind the maint-merge workflow
> you would tell me that... XD
>
> What I did for my package was to manually collect my commits from the
> earlier upstream version and then re-apply these on top of the new
> upstream. But surely there should be a better way to handle this?

Heh, sorry, I've not yet used the workflow for a real upstream that
releases only tarballs; I've only tested gbp-import-orig(1) in
artificial scenarios.

I think that what you are hitting is the recent change of
gbp-import-orig(1)'s default from --merge-mode=merge to
--merge-mode=replace.

For this workflow we want --merge-mode=merge, so that git-merge(1)
handles the re-application of the Debian changes for us (that's the
whole point of the workflow, after all).  So I will add

[import-orig]
merge-mode = merge

to the recommended gbp.conf.

If you want to test, you could just pass --merge-mode=merge to
gbp-import-orig(1).

> I don't really think I can be of much help here because I'm not familiar 
> enough
> with git. Stuff like git merge-tree and merge-base is something I never used
> before. I'm just reporting this wishlist bug from a user perspective. :)

Yes.  Your feedback is very valuable to me and I hope to incorporate all
of it in order to make the workflow easier for future users -- thank
you!

While /writing/ the workflow might have required moderately advanced git
knowledge on my part, /using/ the workflow should not require this
knowledge.

> Another small question:
>
>| "If you want to maintain a copy of your repository on alioth.debian.org,
>| you should push both the origin and the upstream branches:"
>
> Should that not be "both the master and the upstream branches to origin"?

Thanks, yes, that is the intended meaning (and fortunately the actual
commands given are correct).

> And a related side question (that maybe should also have an answer in
> the man page): What are the recommendations for the upstream branch?
> For "When upstream tags releases in git" you write "here is no need to
> maintain a separate 'upstream' branch" but does this also hold for
> "When upstream releases only tarballs"? Because if I don't push the
> upstream branch to anywhere, then the steps under "NEW UPSTREAM
> RELEASES" will fail because "gbp import-orig" doesn't see an upstream
> branch. So maybe the man page could also expand on the need for an
> upstream branch if upstream releases tarball and recommendations on
> where and when it should be pushed or how one can do without it. For
> example maybe the question can be answered whether the upstream branch
> can be pushed to dgit-repos or whether alioth has to be used for that.

Yes indeed, you need to maintain an upstream branch if upstream releases
only tarballs.  The manpage currently suggests that pushing that branch
to alioth is optional, but as you say, it is actually required in order
for future gbp-import-orig(1) calls to succeed.

I will expand that section to say that you must push the upstream branch
somewhere; eventually dgit-repos, but until that is possible (#848678),
to alioth.

Thanks again.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#882553: cross-toolchain-base-ports: missing build dependency on dwz

[Adrian Bunk]

Source: cross-toolchain-base-ports
Version: 13
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cross-toolchain-base-ports.html

...
: # Strip shared libraries and binaries
set -e; for i in 
debian/binutils-alpha-linux-gnu/usr/lib/x86_64-linux-gnu/libbfd-*so 
debian/binutils-alpha-linux-gnu/usr/lib/x86_64-linux-gnu/libopcodes-*so $(file 
debian/binutils-alpha-linux-gnu/usr/bin/* |awk -F: '$0 !~ /script/ {print 
$1}'); do test ! -h $i || continue; test -f $i || continue; files="$files $i"; 
done; mkdir -p 
debian/binutils-alpha-linux-gnu-dbg/usr/lib/debug/.dwz/x86_64-linux-gnu; 
dwz=usr/lib/debug/.dwz/x86_64-linux-gnu/binutils-alpha-linux-gnu.debug; dwz -m 
debian/binutils-alpha-linux-gnu-dbg/$dwz -M /$dwz $files; objcopy 
--compress-debug-sections debian/binutils-alpha-linux-gnu-dbg/$dwz; for i in 
$files; do b_id=$(LC_ALL=C readelf -n $i | sed -n 's/ *Build ID: 
*\([0-9a-f][0-9a-f]*\)/\1/p'); if [ -z "$b_id" ]; then id=$(echo $i | sed -r 
's,debian/[^/]+,debian/binutils-alpha-linux-gnu-dbg/usr/lib/debug,'); echo 
strip $i; mkdir -p $(dirname $id); objcopy --only-keep-debug $i $id; chmod 644 
$id; strip --remove-section=.comment --remove-section=.note $i; objcopy --a
 dd-gnu-debuglink $id $i; else echo "ID: ${b_id} -> $(echo $i | sed 
's,debian/binutils-alpha-linux-gnu,,')"; d=usr/lib/debug/.build-id/${b_id:0:2}; 
f=${b_id:2}.debug; mkdir -p debian/binutils-alpha-linux-gnu-dbg/$d; objcopy 
--only-keep-debug --compress-debug-sections $i 
debian/binutils-alpha-linux-gnu-dbg/$d/$f; chmod 644 
debian/binutils-alpha-linux-gnu-dbg/$d/$f; strip --remove-section=.comment 
--remove-section=.note $i; fi; done
/bin/bash: dwz: command not found
debian/rules:807: recipe for target 'stamps/install.alpha' failed
make[1]: *** [stamps/install.alpha] Error 127

Bug#882538: outguess: missing source for jpeg-6b-steg/configure

[Eriberto]

2017-11-23 17:23 GMT-02:00 Helmut Grohne :
> Source: outguess
> Version: 1:0.2-8
> Severity: serious
> Justification: missing source
> User: helm...@debian.org
> Usertags: rebootstrap
>
> jpeg-6b-steg/configure claims to be a generated file. I was looking for
> the source and couldn't find it. This seems like a plain DFSG #2
> violation.
>
> Helmut


Hi,

It not seems a code without a source code. The code can't be
regenerated from a configure.ac but it can be modified to work if it
is necessary. It is similar to a traditional configure file, made by
hand. I can't see a real problem here. IMO, there is an editable
source code and is all right.

Please, consider closing this bug. I think that are several similar
packages in Debian. If you disagree, I will submit a question to
debian-legal.

Thanks in advanced.

Regards,

Eriberto

Bug#882552: nautilus: Should depend on (or at least recommend) libgdk-pixbuf2.0-bin: otherwise no image thumbnails

[Andreas Kloeckner]

Package: nautilus
Version: 3.26.0-1
Severity: normal

Dear Maintainer,

There should be some form of dependency from Nautilus on
libgdk-pixbuf2.0-bin: it contains /usr/bin/gdk-pixbuf-thumbnailer
without which most images in nautilus won't get thumbnailed.

Thanks!
Andreas

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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-2
ii  gsettings-desktop-schemas  3.24.1-1
ii  gvfs   1.34.1-1+b1
ii  libatk1.0-02.26.0-2
ii  libc6  2.24-17
ii  libcairo-gobject2  1.15.8-2
ii  libcairo2  1.15.8-2
ii  libexempi3 2.4.3-1
ii  libexif12  0.6.21-4
ii  libgail-3-03.22.24-3
ii  libgdk-pixbuf2.0-0 2.36.11-1
ii  libglib2.0-0   2.54.1-1
ii  libglib2.0-data2.54.1-1
ii  libgnome-autoar-0-00.2.2-1
ii  libgnome-desktop-3-12  3.26.2-1
ii  libgtk-3-0 3.22.24-3
ii  libnautilus-extension1a3.26.0-1
ii  libpango-1.0-0 1.40.12-1
ii  libpangocairo-1.0-01.40.12-1
ii  libselinux12.7-2
ii  libtracker-sparql-2.0-02.0.2-1
ii  libx11-6   2:1.6.4-3
ii  nautilus-data  3.26.0-1
ii  shared-mime-info   1.9-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.24.0-2
ii  gvfs-backends1.34.1-1+b1
ii  librsvg2-common  2.40.18-2

Versions of packages nautilus suggests:
ii  brasero  3.12.2-3
ii  eog  3.26.2-1
ii  evince [pdf-viewer]  3.26.0-1
ii  gv [pdf-viewer]  1:3.7.4-1+b1
ii  nautilus-sendto  3.8.6-1
ii  okular [pdf-viewer]  4:16.08.2-1+b1
ii  totem3.26.0-2
ii  tracker  2.0.2-1
ii  vlc [mp3-decoder]2.2.7-1
ii  xdg-user-dirs0.15-3

-- debconf-show failed

Bug#882551: python-shade FTBFS: test failures

[Adrian Bunk]

Source: python-shade
Version: 1.7.0-2
Severity: serious

Some recent change in unstable makes python-shade FTBFS:

https://tests.reproducible-builds.org/debian/history/python-shade.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-shade.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/python-shade-1.7.0'
python3 setup.py testr --slowest
running testr
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit} --list 
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpmghmb4lk
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpf77ocx6o
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmppui4j8ot
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpf01tpz6c
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpw6myrnsa
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmphos19swg
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpjs_gaxh6
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpx78_8hf8
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpzp6ta7s6
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpu5dcaoel
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpms6zq__2
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmputd3vro4
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmp6qh6hlhn
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpvw3nq656
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./shade/tests/unit}  --load-list /tmp/tmpg4q9igbe
==
FAIL: shade.tests.unit.test_inventory.TestInventory.test_get_host_no_detail
tags: worker-14
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
return func(*args, **keywargs)
  File "shade/tests/unit/test_inventory.py", line 153, in 
test_get_host_no_detail
inv = inventory.OpenStackInventory()
  File "shade/inventory.py", line 41, in __init__
for 

Bug#882382: [Debian-med-packaging] Bug#882382: first step to fix the r-cran-epi autopkg tests

[Andreas Tille]

On Thu, Nov 23, 2017 at 04:30:50PM +0200, Graham Inggs wrote:
> Hi Andreas
> 
> On 22/11/2017 12:51, Andreas Tille wrote:
> > Hi Matthias,
> > 
> > I applied your patch in Git and it works for me.  Could you point
> > to some log where I can see the "still fail" problem?
> > 
> > Thanks for the patch in any case
> > 
> >   Andreas.
> > 
> 
> From one of the Ubuntu autopkgtest logs [1]:
> 
> autopkgtest [20:27:02]: test run-unit-test: [---
> cp: -r not specified; omitting directory
> '/usr/share/doc/r-cran-epi/examples/vignettes'
> 
> I think Matthias missed a '-r' from his patch, but you have a '-a' there
> [2], so it should be fine.

Ahhh, I simply assumed that Matthias had forgotten this in the patch so
this can be considered as fixed ...

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#882450: [pkg-go] Bug#882450: golang-github-alecthomas-chroma: FTBFS w/gccgo: Name undefined

[Aaron M. Ucko]

"Dr. Tobias Quathamer"  writes:

> Hm, unfortunately, the new upload didn't do the trick.

Thanks for trying to address these errors.

I suspect we're looking at a case of using Go 1.9 functionality that
isn't yet in gccgo, which is still at a compatibility level of 1.8 as of
GCC 7.

-- 
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#881295: RFS: rednotebook/2.3-1 [ITP] [ITA] -- A cross-platform journal

[Phil Wyett]

Update of changelog - debianise...

rednotebook (2.3-1) unstable; urgency=medium

  * New upstream release.
  * Update Debian files.
  * ITP: Submission of RedNotebook version 2.x. (Closes: #875264)

 -- Phil Wyett   Wed, 08 Nov 2017 17:04:48 +

Feedback would be appreciated.

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

GitLab: https://gitlab.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A

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

Bug#882504: gnome-shell: apt-helper wait-online bypasses well-known mechanism to wait for the network to be 'online'

[Julian Andres Klode]

Control: reassign -1 apt 1.5~rc2

On Thu, Nov 23, 2017 at 02:26:24PM +, Sam Morris wrote:
> Package: gnome-shell
> Version: 3.26.2-1
> Severity: normal
> 
> apt-daily doesn't work on my system.
> 
> Nov 23 13:53:04 systemd[1]: Starting Daily apt download activities...
> Nov 23 13:53:34 systemd-networkd-wait-online[13512]: Event loop failed: 
> Connection timed out
> Nov 23 13:53:34 apt-helper[13510]: E: Sub-process 
> /lib/systemd/systemd-networkd-wait-online returned an error code (1)
> Nov 23 13:53:34 systemd[1]: apt-daily.service: Control process exited, 
> code=exited status=100
> Nov 23 13:53:34 systemd[1]: apt-daily.service: Failed with result 'exit-code'.
> Nov 23 13:53:34 systemd[1]: Failed to start Daily apt download activities.
> Nov 23 13:53:34 systemd[1]: apt-daily.service: Consumed 59ms CPU time
> 
> I notice that apt-helper.cc has a hard-coded list of network management
> services services which, if running, will be waited on by running a
> service-specific command. Rather than such a cardcoded list, apt could
> make use of the network-online.target, which is the well-known
> integration point provided by systemd for clients to wait for the
> network to be 'online'.
> 
> This is documented at
> . You
> basically unconditionally wait on network-online.target, and then you
> don't need to worry about which of systemd-networkd, NetworkManager,
> connman, ifupdown, netscript, etc., are actually pulled in to satisfy
> the dependency

This unfortunately does not work at resume or when the timer elapses
because the target remains active after the services have exited: In
systemd's world, once your system is online it stays online (and I guess
if it does not get online during boot, it stays offline? No idea.).

> On my system I use NetworkManager for the ethernet and wireless
> interfaces, and systemd-networkd for virtual interfaces used for
> tunneling and bridging. In this case, the systemd-networkd-wait-online
> command will always time out.
> 
> From this users' point of view, I have already disabled
> systemd-networkd-wait-online.service in order to configure the system to
> ignore systemd-networkd when considering if the network is 'online'. So
> it would be handy if apt would make use of network-online.target instead
> of doing its own thing here.

right, instead of checking the services of the network managers in question,
we could just check if their online wait helper services are disabled, I guess.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#882520: parlatype: FTBFS on sparc64: html-build.stamp failed (per #878305)

[Gabor Karsay]

Thanks, I already figured out it has to do with the highlight bug. I 
will see if I can build it only architecture independent.

Bug#882218: thunderbird: Apparmor doesn't allow personal profiles outside of ~/.{thunderbird,icedove}

[Simon Deziel]

On Tue, 21 Nov 2017 14:58:38 + George Dunlap  wrote:
> I'm also affected by this bug.  At the moment my home directory is on
> an NFS share, and my quota isn't big enough to fit my mailboxes (in
> addition to making the NFS server a bottleneck for mailbox
> operations).

Unfortunately, the current profile only supports files inside
~/.{thunderbird,icedove} and Apparmor doesn't consider symlinks. It only
considers the final destination when matching against the profile.

> Not sure how the AppArmor stuff works -- would it be possible to
> restrict the profile directory *after* reading profile.ini, so you
> know where the actual profile lives?

That would certainly be a good idea but would require upstream efforts
to support Apparmor properly.

I'm afraid that for such cases, the easiest solution would be to disable
the Apparmor profile:

  sudo apparmor_parser -R /etc/apparmor.d/usr.bin.thunderbird
  sudo ln -s /etc/apparmor.d/usr.bin.thunderbird
/etc/apparmor.d/disable/thunderbird

Regards,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#882517: parlatype: FTBFS on non-Linux: gdk/gdkwayland.h absent

[Gabor Karsay]

Thanks, I'm aware and I will fix it.

Bug#882550: geogebra: Geogebra crashes

[Nicolas Patrois]

Package: geogebra
Version: 4.0.34.0+dfsg1-4
Severity: important

Dear Maintainer,

Geogebra crashes, here is the end of the strace output:
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260 \0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=112160, ...}) = 0
mmap2(NULL, 115256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb661f000
mmap2(0xb663a000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0xb663a000
close(3)= 0
mprotect(0xb663a000, 4096, PROT_READ)   = 0
mprotect(0xb6696000, 4096, PROT_READ)   = 0
mprotect(0xb680a000, 24576, PROT_READ)  = 0
mprotect(0xb6814000, 13197312, PROT_READ|PROT_WRITE) = 0
mprotect(0xb6814000, 13197312, PROT_READ|PROT_EXEC) = 0
mprotect(0xb74ab000, 356352, PROT_READ) = 0
getpid()= 4970
munmap(0xb775a000, 408917)  = 0
getpid()= 4970
mmap2(NULL, 331776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, 
-1, 0) = 0xb776d000
mprotect(0xb776d000, 4096, PROT_NONE)   = 0
clone(child_stack=0xb77bd424, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0xb77bdba8, tls={entry_number:6, base_addr:0xb77bdb40, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, 
seg_not_present:0, useable:1}0xbfcdda7c, child_tidptr=0xb77bdba8) = 4972
futex(0xb77bdba8, FUTEX_WAIT, 4972, NULLGeoGebra 4.0.34.0 (Debian version 
4.0.34.0+dfsg1-4) 22 June 2012 Java 9.0.1
*** Message from [geogebra.main.Application.setUpLogging]
/tmp/GeoGebraLog_fmmvqmvrxe.txt
) = ?
+++ exited with 10 +++

I suspect an incompatibility with openjdk.

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/3 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages geogebra depends on:
ii  default-jre [java8-runtime] 2:1.8-59
ii  icedtea-netx-common 1.6.2-3.1
ii  libcommons-collections3-java3.2.2-1
ii  libcommons-math-java2.2-6
ii  libfreehep-graphics2d-java  2.1.1-6
ii  libfreehep-graphicsio-emf-java  2.1.1-emfplus+dfsg1-4
ii  libfreehep-graphicsio-java  2.1.1-5
ii  libfreehep-graphicsio-pdf-java  2.1.1+dfsg-3
ii  libfreehep-graphicsio-svg-java  2.1.1-5
ii  libfreehep-io-java  2.0.2-6
ii  libfreehep-util-java2.0.2-7
ii  libfreehep-xml-java 2.1.2+dfsg1-5
ii  libjfugue-java  4.0.3-4
ii  libjlatexmath-java  1.0.6-1
ii  librhino-java   1.7.7.1-1
ii  mathpiper   0.81f+svn4469+dfsg3-3
ii  openjdk-8-jre [java8-runtime]   8u151-b12-1
ii  openjdk-9-jre [java9-runtime]   9.0.1+11-1

geogebra recommends no packages.

Versions of packages geogebra suggests:
ii  cups  2.2.6-2

-- no debconf information

Bug#882549: nim: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: nim
Version: 0.17.2-1
Severity: serious
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans
Control: block 871056 by -1

Please migrate to libssl-dev in the Buster cycle. I am very sorry for
this late report but this package was never on my list. It slipped
because it never B-D on libssl1.0-dev.

I looked at the package and the easy build fix is to add the 1.1 prefix
to the libs it looks (in lib/wrappers/openssl.nim). The way it is now,
the package (nimble binary) should not work if libssl-dev is installed
because it parses the .so versions from left to right and first one is
empty. So there is this which already should affect Stretch.

There are a lot of defines and function names copied from the openssl's
header files. Someone needs to double check those that there still the
same.

Function wise:
SSL_library_init() and a few other macros towards "OPENSSL_init_ssl(0, NULL)"
  so "normal" C will work but if nim is accessing the functions directly
  then it will fail.

SSLv23_client_method() and friends are also macros. If I read this right
  then if it is not available, then it will invoke TLSv1_method(). This
  will work in 1.1 but please don't do this. The problem with
  TLSv1_method() is that it will give you _only_ TLSv1 and _never_
  TLSv1.1, and/or TLSv1.2 like SSLv23_client_method(). The "v23" functions
  should be around (for 1.0.2 and earlier) and for 1.1 you would to use
  TLS_client_method().
  The v2 and v3 (and the TLSv1) could be disabled at build time. If you
  want to exclude a certain TLS version you should use something like 
  SSL_OP_NO_TLSv1 to disable TLSv1 only (and keep other version like
  v1.1 and v1.2 around).

Data strucures. All structures are opaque and you need to tell libssl to
allocate it and free it. This means you can't have them on stack or
dereference them. It seems that md5_* (md5_File) uses them on Stack.

A larger collection of what changed in OpenSSL 1.0.2->1.1 is at
   https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes

Sebastian

Bug#877403: stretch-pu: package dbus/1.10.24-0+deb9u1

[Simon McVittie]

On Thu, 23 Nov 2017 at 12:18:00 +, Adam D. Barratt wrote:
> This was uploaded and I was going to accept it, but then our tooling
> reminded me that dbus produces a udeb.

dbus-udeb and libdbus-1-3-udeb were requested because there was a plan
to use AT-SPI in the graphical installer. I don't know whether this ever
happened. https://wiki.debian.org/DebianInstaller/Accessibility doesn't
document any features that seem AT-SPI-related (other than hearing Orca
after installation, which doesn't need udebs), but perhaps it's out
of date?

smcv

Bug#879960: libqt5sql5-psql: [libqt5sql5-psql] basic support postgresql-10

[Diederik de Haas]

On donderdag 23 november 2017 09:34:40 CET Dmitry Shachnev wrote:
> Thank you. The fix is applied in Git now, will be in the next upload.

\o/


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

Bug#882548: redmine: CVE-2017-15571

[Salvatore Bonaccorso]

Source: redmine
Version: 3.3.1-4
Severity: important
Tags: patch security upstream
Forwarded: https://www.redmine.org/issues/27186

Hi,

the following vulnerability was published for redmine.

CVE-2017-15571[0]:
| In Redmine before 3.2.8, 3.3.x before 3.3.5, and 3.4.x before 3.4.3,
| XSS exists in app/views/issues/_list.html.erb via crafted column data.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-15571
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15571
[1] https://www.redmine.org/issues/27186
[2] 
https://github.com/redmine/redmine/commit/273dd9cb3bcfb1e0a0b90570b3b34eafa07d67aa

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#882545: redmine: CVE-2017-15569

[Salvatore Bonaccorso]

Source: redmine
Version: 3.3.1-4
Severity: important
Tags: patch security upstream
Forwarded: https://www.redmine.org/issues/27186

Hi,

the following vulnerability was published for redmine.

CVE-2017-15569[0]:
| In Redmine before 3.2.8, 3.3.x before 3.3.5, and 3.4.x before 3.4.3,
| XSS exists in app/helpers/queries_helper.rb via a multi-value field
| with a crafted value that is mishandled during rendering of an issue
| list.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-15569
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15569
[1] 
https://github.com/redmine/redmine/commit/56c8ee0440d8555aa7822d947ba9091c8a791508

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#882546: RFP: python-ez-setup -- easy ez_setup.py and distribute_setup.py for python

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: python-ez-setup
  Version : 0.1.dev
  Upstream Author : Sridhar Ratnakumar 
* URL : https://github.com/ActiveState/ez_setup/
* License : ZPF ( see 
https://github.com/ActiveState/ez_setup/blob/master/setup.py )
  Programming Lang: Python
  Description : easy ez_setup.py and distribute_setup.py for python

Problem: setup.py of several Python projects blindly import the setuptools 
bootstrap module ez_setup.py without realizing that it is usually not installed 
in the user's machine. This causes much trouble.

Workaround: Include ez_setup.py (and distribute_setup.py) as an installable 
Python package so users can do easy_install ez_setup troublesome_package as a 
workaround.

Note: The ez_setup.py file being distributed is simply a copy of 
distribute_setup.py from the Distribute project (a setuptools fork); this is to 
remain compatible with several Python distributors opting to use Distribute 
instead of Setuptools -- examples: **Debian**, ActiveState, and so on.

Bug#882547: redmine: CVE-2017-15570

[Salvatore Bonaccorso]

Source: redmine
Version: 3.3.1-4
Severity: important
Tags: patch security upstream
Forwarded: https://www.redmine.org/issues/27186

Hi,

the following vulnerability was published for redmine.

CVE-2017-15570[0]:
| In Redmine before 3.2.8, 3.3.x before 3.3.5, and 3.4.x before 3.4.3,
| XSS exists in app/views/timelog/_list.html.erb via crafted column data.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-15570
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15570
[1] https://www.redmine.org/issues/27186
[2] 
https://github.com/redmine/redmine/commit/1a0976417975a128b0a932ba1552c37e9414953b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#882544: redmine: CVE-2017-15568

[Salvatore Bonaccorso]

Source: redmine
Version: 3.3.1-4
Severity: important
Tags: patch security upstream
Forwarded: https://www.redmine.org/issues/27186

Hi,

the following vulnerability was published for redmine.

CVE-2017-15568[0]:
| In Redmine before 3.2.8, 3.3.x before 3.3.5, and 3.4.x before 3.4.3,
| XSS exists in app/helpers/application_helper.rb via a multi-value field
| with a crafted value that is mishandled during rendering of issue
| history.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-15568
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15568
[1] https://www.redmine.org/issues/27186
[2] 
https://github.com/redmine/redmine/commit/94f7cfbf990028348b9262578acbc53a94fce448

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#882510: reopen

[c.buhtz]

Please explain why you closed?

The error message is still there. No fix.

You just gave a workaround with choosing a View.

Bug#881066: Message for 143myshadow ul

[Mary Hartling]

I have no idea what this is all about or if it is even for me.
Also it was dated Nov 07/17 and I'm just getting this today Nov 23/17.
Please let me know what this is all about.
Thank you.

Sent from my iPad

> On Nov 7, 2017, at 8:53 PM, Pre Thanksgiving sales  
> wrote:
> 
> Hi Peter,
> 
> We are sorry for the incident, have just manually run the sync, could you 
> please check if the mirror is up-to-date now?
> 
> Thanks
> 
> --
> 
> Mak Kuen Seng
> Support Team Lead
> 
> IP SERVERONE SOLUTIONS SDN BHD
> A-1-1, Block A, Glomac Damansara
> Jalan Damansara, 6 Kuala Lumpur
> 
> Tel: 603 2026 1688 | Fax: 603 7728 3188 
> 
> 
> Ticket History
> Peter Palfrader (Client) Posted On: 07 November 2017 10:48 PM
> 
> Package: mirrors
> User: mirr...@packages.debian.org
> Usertags: mirror-problem may-auto-close
> Control: submitter -1 mirr...@debian.org
> 
> Hi!
> 
> According to
> https://mirror-master.debian.org/status/mirror-info/debian.ipserverone.com.html
> your mirror is out of date by over a week.
> 
> Please investigate.
> --
> | .''`. ** Debian **
> Peter Palfrader | : :' : The universal
> https://www.palfrader.org/ | `. `' Operating System
> | `- https://www.debian.org/
> 
> 
> 
> 
> Ticket Details
> Ticket ID: QMM-573-27544
> Department: Support
> Type: Issue
> Status: Replied
> Priority: Normal
> Remark: Kindly be informed that this ticket will be auto close after 48 hours 
> of inactivity. If you still need assistance, please reopen this ticket by 
> replying to this email. If you encounter with different issues, kindly submit 
> a new ticket for new questions. This helps us track issues better and improve 
> our overall support services.
> 
> Disclaimer: Privileged/confidential information may be contained in this 
> message. If you are not the named recipient or addressee, you are hereby 
> notified that any use review, disclosure or copying of the contents herein is 
> strictly prohibited. In such a case, kindly discard all its contents and 
> notify sender accordingly regarding such unauthorized disclosure or 
> transmission by email. Opinions, conclusions, statements and other 
> information in this message that do not relate to the official business of IP 
> SERVERONE SOLUTIONS SDN BHD shall be understood as neither given or endorsed 
> by it. The contents herein are meant strictly for the use of the named 
> recipient or addressee of IP SERVERONE SOLUTIONS SDN BHD. No assumption of 
> responsibility or liability whatsoever is undertaken by IP SERVERONE 
> SOLUTIONS SDN BHD in respect of prohibited and unauthorized use by any other 
> person.
> 
> 

Bug#882487: thunderbird: Thunderbird won't start - not even with .thunderbird deleted

[Carsten Schoenert]

On Thu, Nov 23, 2017 at 09:02:07PM +0100, Carsten Schoenert wrote:
...
> You have installed apparmor. Have you tried to disable the AppArmor
> profile for Thunderbird and check for the further existence of the issue?
> 
>   $ sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird
> 
> Also I suspect then some messages about denied access by apparmor.
> 
>   $ sudo journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"'

I could reproduce the behavior, I get the same issue if I place my
profile outside my home directory and do some linking to that profile.
That would be #882218

https://bugs.debian.org/882218

Regards
Carsten

Bug#882543: tt-rss: CVE-2017-16896: SQL injection in classes/handler/public.php in the forgotpass component via login parameter

[Salvatore Bonaccorso]

Source: tt-rss
Version: 17.1+git20170410+dfsg-2
Severity: important
Tags: patch security upstream

Hi,

the following vulnerability was published for tt-rss.

CVE-2017-16896[0]:
| A SQL injection in classes/handler/public.php in the forgotpass
| component of Tiny Tiny RSS 17.4 exists via the login parameter.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-16896
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16896
[1] https://discourse.tt-rss.org/t/sql-injection-in-forgotpass-fixed/669
[2] 
https://git.tt-rss.org/git/tt-rss/commit/2352c320c2ed34ec7df1ad22f0c55a1b26489815

Regards,
Salvatore

Bug#882427: Actual error

[Andrei Karas]

Hello,
Actual error in log here:
unittests/sdl.cc:238: FAILED:
  REQUIRE( ptr2[0] == 0x44332211 )
with expansion:
  287454020 (0x11223344)
  ==
  1144201745 (0x44332211)

This test checks how SDL can convert surface to inverted format.
For example source pixel format can be RRGGBBAA and after conversion it must be 
AABBGGRR.
But here SDL 1.2 failed to do this. From my previous tests on ppc64le vm, SDL2 
works fine here.

For now manaplus package building with SDL 1.2, because SDL 2 too slow in 
software rendering mode.

Bug#882122: thunderbird: Thunderbird can't connect to X server, fails to start

[Simon Deziel]

On 2017-11-23 03:12 PM, Jack Henschel wrote:
> $ sudo dmesg -T | grep apparmor
> ...
> [Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:8): 
> apparmor="STATUS" operation="profile_load" profile="unconfined" 
> name="thunderbird" pid=498 comm="apparmor_parser"
> [Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:9): 
> apparmor="STATUS" operation="profile_load" profile="unconfined" 
> name="thunderbird//gpg" pid=498 comm="apparmor_parser"
> [Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:10): 
> apparmor="STATUS" operation="profile_load" profile="unconfined" 
> name="thunderbird//lsb_release" pid=498 comm="apparmor_parser"
> [Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:11): 
> apparmor="STATUS" operation="profile_load" profile="unconfined" 
> name="thunderbird//sanitized_helper" pid=498 comm="apparmor_parser"
> 
> I does not seem like apparmor is blocking anything.

Agreed, Apparmor doesn't seem to get in the way. Thanks for checking!

Regards,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#882122: thunderbird: Thunderbird can't connect to X server, fails to start

[Jack Henschel]

Hi Simon,

thanks for the hint concerning apparmor!

On 11/23/2017 07:20 PM, Carsten Schoenert wrote:
> Hello Simon,
> 
> On Thu, Nov 23, 2017 at 01:00:48PM -0500, Simon Deziel wrote:
> -T | grep 'apparmor="DENIED"'

I ran `thunderbird`, then `/usr/lib/thunderbird/thunderbird` and finally 
`/usr/lib/thunderbird/thunderbird-bin`.

The query shown above did not yield any results, however I have the following 
output:

$ sudo dmesg -T | grep apparmor
...
[Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:8): 
apparmor="STATUS" operation="profile_load" profile="unconfined" 
name="thunderbird" pid=498 comm="apparmor_parser"
[Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:9): 
apparmor="STATUS" operation="profile_load" profile="unconfined" 
name="thunderbird//gpg" pid=498 comm="apparmor_parser"
[Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:10): 
apparmor="STATUS" operation="profile_load" profile="unconfined" 
name="thunderbird//lsb_release" pid=498 comm="apparmor_parser"
[Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:11): 
apparmor="STATUS" operation="profile_load" profile="unconfined" 
name="thunderbird//sanitized_helper" pid=498 comm="apparmor_parser"

I does not seem like apparmor is blocking anything.

Greetings
Jack




signature.asc
Description: OpenPGP digital signature

Bug#881424: RFP: ausweisapp2 -- online authentication using German identity document

[Ansgar Burchardt]

"W. Martin Borgert" writes:
> Owner: "W. Martin Borgert" 

A RFP bug with an owner? :-)

> * Package name: ausweisapp2
>   Version : 1.12.4
>   Upstream Author : Governikus GmbH & Co. KG
> * URL : https://github.com/Governikus/AusweisApp2
[...]
> It seems, that all dependencies are already in Debian. master does not
> compile, but I did not investigate further after first error (‘class
> QSslConfiguration’ has no member named ‘setSignatureAndHashAlgorithms’).

README.rst says it needs either a Qt 5.10 (not yet released) or a
patched version of Qt and OpenSSL.

Ansgar

Bug#882480: [Pkg-dpdk-devel] Bug#882480: Bug#882480: Bug#882480: Bug#882480: dpdk: autopkgtest dependencies are bad on s390x / any non-supported arch

[Luca Boccassi]

On Thu, 2017-11-23 at 17:31 +, Luca Boccassi wrote:
> On Thu, 2017-11-23 at 17:28 +0100, Santiago R.R. wrote:
> > El 23/11/17 a las 13:29, Christian Ehrhardt escribió:
> > > Submitted to deb_dpdk as [1], thank Dimitri.
> > > I don't expect pushback on this, so this will likely be in Debian
> > > (and
> > > the Ubuntu sync) on 17.11.x
> > 
> > Do you know what will be the next LTS version, that it would be
> > possible/suitable to upload to unstable?
> > 
> > I'd be happy to push this changes to the current version in
> > unstable.
> 
> Hi,
> 
> 17.11 is an LTS. We just talked about it today, and the plan is to
> upload it to experimental first (will do that shortly) to clear the
> binary-NEW queue, and then to unstable and start a transition for the
> reverse depends (collectd).

It's now in NEW:

https://ftp-master.debian.org/new/dpdk_17.11-1.html

-- 
Kind regards,
Luca Boccassi

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

Bug#879719: libsane-hpaio: Does not recognize OfficeJet Pro 8710

[Brian Potkin]

On Thu 23 Nov 2017 at 20:22:15 +0100, Gedalya wrote:

> On 11/23/2017 05:44 PM, Brian Potkin wrote:
> > On Thu 23 Nov 2017 at 14:05:38 +0100, Gedalya wrote:
> >
> >> On 11/23/2017 01:37 PM, Brian Potkin wrote:
>  Note: In order to produce this, I need to stop cupsd. Somehow, at some
>  point sane started finding the scanner via CUPS, the printer being
>  configured there.
> >>> I take this to mean you configured the printer with something like
> >>> hp-setup and the device_uri for it begins with hp:/. Please post the
> >>> output of
> >>>
> >>>  lpoptions -p 
> >>>
> >>> as confirmation of this.
> >> $ lpoptions -p HP_OfficeJet_Pro_8710
> >> ColorModel=KGray copies=1 
> >> device-uri=hp:/net/HP_OfficeJet_Pro_8710?ip=192.168.9.238
> > This device-uri should also be given by hp-makeuri. Would you confirm
> > this and check printing takes place.
> 
> This in fact works only with the original models.dat, with the hp_ prefix:

That in itself should indicate something to you.

> $ hp-makeuri 192.168.9.238
> 
> HP Linux Imaging and Printing System (ver. 3.17.10)
> Device URI Creation Utility ver. 5.0
> 
> Copyright (c) 2001-15 HP Development Company, LP
> This software comes with ABSOLUTELY NO WARRANTY.
> This is free software, and you are welcome to distribute it
> under certain conditions. See COPYING file for more details.
> 
> CUPS URI: hp:/net/HP_OfficeJet_Pro_8710?ip=192.168.9.238
> SANE URI: hpaio:/net/HP_OfficeJet_Pro_8710?ip=192.168.9.238
> HP Fax URI: hpfax:/net/HP_OfficeJet_Pro_8710?ip=192.168.9.238
> 
> Done.

hpaio:/ and hpfax:/ replace hp:/

> ---
> with the edited file:
> 
> $ hp-makeuri 192.168.9.238
> 
> HP Linux Imaging and Printing System (ver. 3.17.10)
> Device URI Creation Utility ver. 5.0
> 
> Copyright (c) 2001-15 HP Development Company, LP
> This software comes with ABSOLUTELY NO WARRANTY.
> This is free software, and you are welcome to distribute it
> under certain conditions. See COPYING file for more details.
> 
> error: Device not found
> 
> Printing works regardless.

I'll have to think about this. Having two different uris doesn't sound
correct. Except you don't have two different uris. The print queue was
set up with the correct one, hp:/net/HP_OfficeJet_Pro_8710?ip=192.168.9.238.

> > The uri for the scanner is formed by replacing hp:/ with hpaio:/. If
> > cups is stopped, scanimage is unable to get the hpaio:/ uri and would
> > report no scanners found. your observation above fits this.
> >
> > But you clearly show Bonjour broadcasting from the printer, so scanimage
> > can get an hpaio:/ uri from that, whether cups is running or not. That
> > is the way it works here.
> >
> > So where does scanimage get the uri from when cups is running? From the
> > Bonjour broadcasts? What happens when you deactivate broadcasting on the
> > printer?
> 
> I don't know how to do that.

Go to http://192.168.9.238 with a browser. Look under Networking for
bonjour/AirPrint.

I have an Envy 4500. It is used for scanning only. There is no print
queue set up, so the state of cups is immaterial. The scanner is only
detected with AirPrint on.
 
> >>>  Also post what you get for
> >>>
> >>>  avahi-browse -art | grep -i officejet
> >>>
> >>> You might have to install the avahi-utils package. 
> >> $ avahi-browse -art | grep -i officejet
> > [Snipping]
> >> +   eth0 IPv6 HP OfficeJet Pro 8710 [XX]    _scanner._tcp  
> >>   local
> >> +   eth0 IPv4 HP OfficeJet Pro 8710 [XX]    _scanner._tcp  
> >>   local
> >> =   eth0 IPv4 HP OfficeJet Pro 8710 [XX]    _scanner._tcp  
> >>   local
> >>    txt = ["feeder=T" "flatbed=T" "button=T" 
> >> "UUID=1c852a4d-b800-1f08-abcd-" "note=" 
> >> "adminurl=http://HP.local.; "mdl=OfficeJet Pro 8710" "mfg=HP" 
> >> "ty=HP OfficeJet Pro 8710" "txtvers=1"]
> > This is your scanner. Looks good to me.
> >
>  On my laptop, where this printer is not installed in CUPS, there is no
>  need to stop CUPS to get this error.
> >>> Post
> >>>
> >>>  lpoptions -p 
> >>>
> >>> for this machine too.
> >> Ummm, the only printer/queue configured on my laptop is a USB printer
> >> that I left behind on another continent.  What exactly should I do
> >> here?
> > Nothing, if there is no hplip or components of hplip on the laptop.
> 
> There is, the other printer was HP AIO too, but it's a different model.

I'm a little lost here, but if libsane-hpaio and libhpmud are on the
system then the 8710 scanning function should be detectable from its
Bonjour broadcasts wih 'scanimage -L'

Cheers,

Brian.

Bug#882487: thunderbird: Thunderbird won't start - not even with .thunderbird deleted

[Carsten Schoenert]

Hello René,

On Thu, Nov 23, 2017 at 01:44:14PM +0100, René Seindal wrote:
> Package: thunderbird
> Version: 1:52.4.0-2~exp1
> Severity: important
> 
> Dear Maintainer,
> 
> I cannot get thunderbird to start on a fairly newly instaled debian testing 
> laptop.
> 
> On a newly booted computer:
> 
> rene $ killall -1 thunderbird
> thunderbird: no process found
> rene $ killall -1 icedove
> icedove: no process found
> rene $ rm -r .thunderbird
> rene $ thunderbird
> 
> just gives me a dialog with the message:
> 
> "Thunderbird is already running, but is not responding. To open a new window, 
> you must first close the existing Thunderbird process, or restart your 
> system."
>
> I have tried using an old profile, a new profile, safe mode, removing 
> .thunderbird and .icedove totally, ... to no avail.
> 
> Thunderbird won't start.  I have no idea what to do next, and google doesn't 
> help much.

Starting Thunderbird with the option '--debug' gives at least some more
information if something is already going wrong before Thunderbird will
be called itself.

> I have tried packages from stable, testing and experimental, all the same.
> 
> -- System Information:
... 
> Versions of packages thunderbird suggests:
> ii  apparmor  2.11.1-3
> pn  fonts-lyx 
> ii  libgssapi-krb5-2  1.15.2-2

You have installed apparmor. Have you tried to disable the AppArmor
profile for Thunderbird and check for the further existence of the issue?

  $ sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird

Also I suspect then some messages about denied access by apparmor.

  $ sudo journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"'

Regards
Carsten

Bug#882048: apparmor should let thunderbird use signatures from files

[Simon Deziel]

On 2017-11-23 02:14 PM, intrigeri wrote:
> Hi,
> 
> Vincas Dargis:
>> Looks like the culprit is this line in usr.bin.thunderbird [0]:
> 
>> ```
>> deny @{HOME}/.* r,
>> ```
> 
> […]
> 
> Thanks for your detailed analysis!
> 
>> 4. Opening a File dialog to select file to be attached, produces bunch of 
>> DENIED
>> messages in log, when user browses it's $HOME, which contains dot-files and
>> directories. I have experienced this myself, as for some reason file select 
>> dialog
>> tries to read files being displayed (probably for create/modify dates?). To 
>> avoid
>> these noisy DENIED messages, someone have put `deny @{HOME}/.* r,` rule to 
>> silence
>> it. This is my speculation.

Sound logic indeed but...

> I can't reproduce this after commenting out the "deny @{HOME}/.* r" rule.

Me neither and it's not in Firefox profile either so that's a good sign
that we can safely drop it.

> If I do that and then add a new rule:
> 
>   owner @{HOME}/.signature* r,
> 
> … then the use case this bug report is about is fixed.
> Simon, any problem with doing that?

No, that's good, compatibility with existing behaviour is really important!

> If we do that, then we need to document in README.Debian than
> signatures can be loaded only from ~/.signature*. I'm not sure that's
> good enough to avoid creating a "AppArmor breaks basic stuff, let's
> disable it" culture in Debian, which is something I've been trying
> hard to avoid for years.
> 
> I'm very tempted to propose we simply disable this profile by default:
> I have very little hope at this point that we can make it open enough
> to avoid breaking all kinds of corner cases, while keeping it strict
> enough to be meaningful at all. Opinions?

I wish Thunderbird could keep its Apparmor profile however imperfect it
is. Thunderbird is used in very different setups and I guess that like
other big graphical applications it's always going to be tough to strike
the balance between secure and functional.

That said, if the maintenance burden is too much I can't blame you from
wanting to have it opt-in instead of being enabled by default.

Regards,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#882331: mtr: source routing with --address does not work

[Robert Woodcock]

On 11/23/2017 08:07 AM, Tom Hetmer wrote:
> OK, and the results from 0.92? Good too?
> Testing the last working version doesn't help much. :-)

0.92 behaves the same. *Neither* version does what you want. I wrote my
email to show you that it's not a regression because it doesn't work the
way you want in 0.87. It's not a bug either because the documentation
doesn't claim that the -a option does what you're hoping it does.

Any behavior to the contrary is something particular to your system.

0.92 uses bind() if you specify TCP or SCTP, otherwise it just uses
socket() and sendto(). This is done in a separate process (mtr-packet)
so you'd need to use strace's -f option to see it.

Bug#685519: [libc6] /usr/local/lib/x86_64-linux-gnu should be in ldconfig list

[Emmanuel Engelhart]

Anything we can do to help that patch being merged?

Here a few tickets which seems to be directly related to that bug:
* Meson:  https://github.com/mesonbuild/meson/issues/1972
* Libzim: https://github.com/openzim/libzim/issues/26

-- 
Kiwix - Wikipedia Offline & more
* Web: http://www.kiwix.org
* Twitter: https://twitter.com/KiwixOffline
* more: http://www.kiwix.org/wiki/Communication



signature.asc
Description: OpenPGP digital signature

Bug#882431: [Pkg-swan-devel] Bug#882431: Bug#882431: strongswan-starter: counters plugin should be visible to strongswan-swanctl package

[Yves-Alexis Perez]

On Thu, 2017-11-23 at 10:21 -0800, Gerald Turner wrote:
> > The swanctl command is just talking (via vici) to the charon-systemd
> > binary.  And charon-systemd packages already depends on
> > strongswan-libcharon, so it should be fine to move the counters plugin
> > there, I think.
> >
> > Does that make sense to you?
> 
> Sounds perfect.  Want me to recreate a patch?

Don't both, I have a patch already.

On Thu, 2017-11-23 at 10:19 -0800, Gerald Turner wrote:
> On Thu, Nov 23 2017, Yves-Alexis Perez wrote:
> > In any case your later patch is wrong (doesn't move, just copy, and
> > doesn't handle conflicts/replace etc.).
> 
> Do you mean Conflicts, Breaks, etc. in debian/control?  I overlooked
> that completely, figuring the 5.6.1-1 package hasn't migrated out of sid
> yet.

Yes. But people have already installed the package in sid so it's better to
handle that properly.

Regards,
-- 
Yves-Alexis

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

Bug#882542: wily FTCBFS: uses the build architecture compiler and strip

[Helmut Grohne]

Source: wily
Version: 0.13.41-7.3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

wily fails to cross build from source, because it uses the build
architecture compiler and strip. Passing a triplet-prefixed CC to
./configure fixes the first part and letting dh_strip perform the
stripping fixes cross builds, -dbgsym packages and #438263. Please
consider applying the attached patch.

Helmut
diff -u wily-0.13.41/debian/changelog wily-0.13.41/debian/changelog
--- wily-0.13.41/debian/changelog
+++ wily-0.13.41/debian/changelog
@@ -1,3 +1,12 @@
+wily (0.13.41-7.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Pass a cross compiler to ./configure.
++ Defer stripping to dh_strip.
+
+ -- Helmut Grohne   Thu, 23 Nov 2017 20:29:57 +0100
+
 wily (0.13.41-7.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u wily-0.13.41/debian/rules wily-0.13.41/debian/rules
--- wily-0.13.41/debian/rules
+++ wily-0.13.41/debian/rules
@@ -1,6 +1,9 @@
 #!/usr/bin/make -f
 # Derived from dh_make example.
 
+-include /usr/share/dpkg/buildtools.mk
+export CC
+
 #export DH_VERBOSE=1
 
 build: build-stamp
@@ -32,10 +35,10 @@
dh_clean -k
dh_installdirs usr/bin usr/X11R6/lib/X11/wily usr/share/man/man1 
/etc/X11/app-defaults \
usr/share/doc/wily/html
-   install -m755 -s wily/wily debian/wily/usr/bin
-   install -m755 -s tools/win/win debian/wily/usr/bin
-   install -m755 -s tools/win/wgoto debian/wily/usr/bin
-   install -m755 -s tools/win/wreplace debian/wily/usr/bin
+   install -m755 wily/wily debian/wily/usr/bin
+   install -m755 tools/win/win debian/wily/usr/bin
+   install -m755 tools/win/wgoto debian/wily/usr/bin
+   install -m755 tools/win/wreplace debian/wily/usr/bin
install -m644 debian/wily.1x debian/wily/usr/share/man/man1
gzip -9n debian/wily/usr/share/man/man1/wily.1x
install -m644 tools/win/w*.1 debian/wily/usr/share/man/man1

Bug#882461: mutt: out-of-date package description

[Antonio Radici]

On Thu, Nov 23, 2017 at 09:10:56AM +0100, Jakub Wilk wrote:
> Package: mutt
> Version: 1.9.1-2
> 
> The package description says "This package is built with the NeoMutt
> patchset", but this is no longer the case.
> 

I've already fixed this in git, it will be in the next Debian release of this
package.

Bug#879853: netcat-openbsd: support -s with -l

[Uwe Kleine-König]

Hello Guilhem,

On Thu, Nov 23, 2017 at 10:56:49AM +0100, Guilhem Moulin wrote:
> On Thu, 26 Oct 2017 at 15:47:25 +0200, Uwe Kleine-König wrote:
> > with the expectation that nc then bind(2)s passing
> > 
> > .inet_pton(AF_INET6, "::1", _addr),
> > 
> > in the 2nd argument (instead of "::") to limit where the open port is
> > available.
> 
> `nc -l ::1 12345` does exactly that, any reason why you want another
> interface?

Ah, that's an inconsistency in the man page that made me fail to notice
that. Of course I don't care much about the interface, only that the
functionality is available.

The wrong conclusion I made was that if I do

nc -l -p 12345

(i.e. specify 12345 as "source_port" to bind to) it must be "source"
that must be set to ::1 when I want nc to bind to [::1]:12345

Hmm, regarding the above command the man page claims:

It is an error to use [-l] in conjunction with the -p, -s, or -z
options.

which isn't treated as an error but does the same as

nc -l 12345

(which in turn does something else when using netcat-traditional that
needs -p to specify the (more suitable named) "local port number").

Thanks for your reply
Uwe


signature.asc
Description: PGP signature