Bug#867562: jessie-pu: package cqrlog/1.8.2-1.1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-07-15 at 11:37 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2017-07-07 at 14:18 +0200, Andreas Beckmann wrote:
> > cqrlog in jessie fails to remove if mysql-server is installed, but
> > apparmor is not. Which does not happen in the default piuparts tests
> > (but with --install-recommends)
> > So let's check for apparmor before restarting it in postrm. And let's
> > do the same for installation.
> > 
> > This was discovered during upgrades to stretch that force the removal of
> > cqrlog (which is not in stretch). (And piuparts currently ignores some
> > failures to remove packages, will be fixed soon. Otherwise we would have
> > found this in jessie with --install-recommends already).
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#864267: jessie-pu: package libterralib/4.3.0+dfsg.1-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-07-15 at 11:34 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2017-06-05 at 23:46 +0200, Andreas Beckmann wrote:
> > libterralib in jessie has Conflicts+Replaces against libterralib3, but
> > that package name has never been used before stretch. This causes
> > upgrade problems since apt does not consider libterralib3 from stretch
> > as a valid installation candidate. This does not seem to be solvable
> > within stretch.
> > A similar case was fixed in the previous jessie point release: openmpi.
> > Proposed patch attached.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#866864: Merging node-umask ITPs

[Adrian Bunk]

Control: forcemerge -1 868444

Hi,

both of you submitted ITPs for node-umask.

Please coordinate on who will actually package this.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#868537: File conflict between abiword-dbgsym and abiword-plugin-grammar-dbgsym

[Adrian Bunk]

Source: abiword
Version: 3.0.2-2
Severity: serious
Control: affects -1 abiword-dbgsym abiword-plugin-grammar-dbgsym

# apt-get install abiword-dbgsym abiword-plugin-grammar-dbgsym
...
dpkg: error processing archive 
/var/cache/apt/archives/abiword-plugin-grammar-dbgsym_3.0.2-2_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/30/e90eef3ab895a8c526b88940ee8d1f6ff47710.debug', 
which is also in package abiword-dbgsym 3.0.2-2


The problem is the following in debian/rules:

override_dh_makeshlibs:
$(RM) -v 
debian/abiword/usr/lib/$(DEB_HOST_MULTIARCH)/abiword-*/plugins/grammar.*
dh_makeshlibs -V


When grammar.so is removed from the abiword package,
dh_strip already ran and added its debug information
to abiword-dbgsym.

Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution

[brian m. carlson]

On Sun, Jul 16, 2017 at 12:34:05AM +0100, Brian Potkin wrote:
> On Sat 15 Jul 2017 at 19:40:04 +, brian m. carlson wrote:
> > * Validate data.  Nobody is going to print a two-pixel raster image, and
> >   cups should not accept it as a valid (and in this case, the only
> >   valid) option.
> 
> cups and cupsfilters have both accepted and fixed past bugs in their
> implementation of driverless printing. In some cases cups has made
> allowances for deficiencies in a manufacturer's implementaion of IPP
> Everywhere. But where does it end?
> 
> Assuming this is a firmware bug, doesn't the vendor (who after all is
> using a well defined standard) have the reponsibility, especially if
> the issue is drawn to their attention by an affected user? If AirPrint
> was involved you could well imagine they would jump to it.

I have put in a support request with them.  However, I have no way to
prove that this actually affects AirPrint, as I don't have any modern
Apple devices.  I'm pretty sure my alternative is going to be returning
the printer.

I will say that cups is clearly accepting invalid data.  How can a
printer have a resolution of 600 dpi and only accept 600x2 raster
images?  If the printer returned 600x-1 resolution, would cups accept
that as well?

> > * Use the printer resolution instead of the PWG resolution when
> >   generating raster images.  At the very least, these should be
> >   resolution options for configuration in addition to the PWG
> >   resolution.
> 
> Surely the printer resolution is what is returned by an IPP query?
> Either that, or it is in a supplied PPD.

The printer resolution is indeed returned in an IPP query, as you'll see
in the data provided.  However, cups only accepts the PWG raster format
resolution and ignores the printer resolution.  If the driverless
printing option provided all three resolution options (600 dpi, 600x2400
dpi, and 600x2 dpi), it would be easy to simply configure the printer to
use one of the other options as a default.

I do view this aspect as a bug in cups.  I should be able to pick any
resolution that the printer supports.

The vendor does not supply a plain PPD for Linux.  They provide a
proprietary driver.  While that may work for my x86 machines, that will
not work for my ARM, MIPS, or PowerPC machines.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#868555: O: devilspie2 -- Lua-based window matching utility

[Andreas Ronnquist]

Package: wnpp
Severity: normal

I intend to orphan the devilspie2 package.

Why fool anybody - I don't use it any longer, but it was fun while it
lasted.

I abandon it upstream too - so, if you take over the Debian package,
you should probably take over the upstream project at Savannah too.

The package description is:
 Devilspie2 is a window matching utility, allowing the user to perform
 scripted actions on windows as they are created. For example, you can
 script a terminal program to always be positioned at a specific screen
 position, or automatically position a window on a specific workspace.
 .
 It is a continuation of Ross Burton's project Devilspie, with the most


-- Andreas Rönnquist
gus...@debian.org

Bug#868379: calibre breaks with recent python-dateutil

[Guido Günther]

control: reassign -1 calibre

Hi,
On Sun, Jul 16, 2017 at 05:33:53PM +0200, Manolo Díaz wrote:
> On Sunday, 16 Jul 2017 at 15:24 UTC
> Guido Günther wrote:
  > 
> > Hi,
> > On Sun, Jul 16, 2017 at 05:12:28PM +0200, Manolo Díaz wrote:
> > > On Sunday, 16 Jul 2017 at 11:27 UTC
> > > Guido Günther wrote:
> > >   
> > > > Hi,
> > > > On Sun, Jul 16, 2017 at 11:22:47AM +0200, Manolo Díaz wrote:  
> > > > > On Sunday, 16 Jul 2017 at 09:05 UTC
> > > > > Guido Günther wrote:
> > > > > 
> > > > > > Hi,
> > > > > > control: affects -1 calibre
> > > > > 
> > > > >   [...]
> > > > > 
> > > > > > Starts here without problems. Does
> > > > > > 
> > > > > >  python -c "from six.moves import _thread"
> > > > > > 
> > > > > > work for you? If it does not work your python-six is broken. Maybe 
> > > > > > you
> > > > > > have a local version of six lying around?
> > > > > > Cheers,
> > > > > >  -- Guido
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > python -c "from six.moves import _thread" does apparently nothing and
> > > > > exits with 0. Is this expected?
> > > > >
> > > > 
> > > > Yept. That's how it should be.
> > > >   
> > > > > The version of python-six on my system is 1.10.0-4 (current testing)
> > > > > and if it was broken I think calibre wouldn't start with only
> > > > > downgrading python-dateutil.
> > > > 
> > > > It might because the old python-dateutil version might not have used it.
> > > > Can you do a
> > > > 
> > > >strace -f -s2048 /usr/bin/calibre
> > > > 
> > > > and attach this to the bugreport please.
> > > > Cheers,
> > > >  -- Guido  
> > > 
> > > Of course. It's attached.  
> > 
> > You have six.pyc in the calibre directory that's tripping up things:
> > 
> > open("/usr/lib/calibre/six.pyc", O_RDONLY) = 9
> > 
> > can you remove that and try again?
> > Cheers,
> >  -- Guido
> 
> It works. After removing /usr/lib/calibre/six.pyc calibre works again.
> So you are right, it's not a python-datetime bug.

So calibre should clean up *.pyc files (probably from ancient
installations) in /usr/lib/calibre.
Cheers,
 -- Guido

Bug#868379: calibre breaks with recent python-dateutil

[Manolo Díaz]

On Sunday, 16 Jul 2017 at 15:59 UTC
Guido Günther wrote:

> control: reassign -1 calibre
> 
> Hi,
> On Sun, Jul 16, 2017 at 05:33:53PM +0200, Manolo Díaz wrote:
> > On Sunday, 16 Jul 2017 at 15:24 UTC
> > Guido Günther wrote:
>   >   
> > > Hi,
> > > On Sun, Jul 16, 2017 at 05:12:28PM +0200, Manolo Díaz wrote:  
> > > > On Sunday, 16 Jul 2017 at 11:27 UTC
> > > > Guido Günther wrote:
> > > > 
> > > > > Hi,
> > > > > On Sun, Jul 16, 2017 at 11:22:47AM +0200, Manolo Díaz wrote:
> > > > > > On Sunday, 16 Jul 2017 at 09:05 UTC
> > > > > > Guido Günther wrote:
> > > > > >   
> > > > > > > Hi,
> > > > > > > control: affects -1 calibre  
> > > > > > 
> > > > > > [...]
> > > > > >   
> > > > > > > Starts here without problems. Does
> > > > > > > 
> > > > > > >  python -c "from six.moves import _thread"
> > > > > > > 
> > > > > > > work for you? If it does not work your python-six is broken. 
> > > > > > > Maybe you
> > > > > > > have a local version of six lying around?
> > > > > > > Cheers,
> > > > > > >  -- Guido  
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > python -c "from six.moves import _thread" does apparently nothing 
> > > > > > and
> > > > > > exits with 0. Is this expected?
> > > > > >  
> > > > > 
> > > > > Yept. That's how it should be.
> > > > > 
> > > > > > The version of python-six on my system is 1.10.0-4 (current testing)
> > > > > > and if it was broken I think calibre wouldn't start with only
> > > > > > downgrading python-dateutil.  
> > > > > 
> > > > > It might because the old python-dateutil version might not have used 
> > > > > it.
> > > > > Can you do a
> > > > > 
> > > > >strace -f -s2048 /usr/bin/calibre
> > > > > 
> > > > > and attach this to the bugreport please.
> > > > > Cheers,
> > > > >  -- Guido
> > > > 
> > > > Of course. It's attached.
> > > 
> > > You have six.pyc in the calibre directory that's tripping up things:
> > > 
> > > open("/usr/lib/calibre/six.pyc", O_RDONLY) = 9
> > > 
> > > can you remove that and try again?
> > > Cheers,
> > >  -- Guido  
> > 
> > It works. After removing /usr/lib/calibre/six.pyc calibre works again.
> > So you are right, it's not a python-datetime bug.  
> 
> So calibre should clean up *.pyc files (probably from ancient
> installations) in /usr/lib/calibre.
> Cheers,
>  -- Guido

It would help, but I think it isn't enough. Given the following
sequence calibre would have failed to start.

- upgrade or reinstall calibre (all *.pyc are cleaned up)
- run calibre as root (they are created again)
- upgrade python-dateutil.

Thanks again.

Regards,
-- 
Manolo Díaz

Bug#868525: guile-2.0: New upstream version available

[Rob Browning]

Adrian Bunk  writes:

> That's guile-2.2
>
> I'd just need guile-2.0 updated to 2.0.14 for a QA upload
> of the latest upstream version of guile-gnome-platform that
> depends on >= 2.0.14

Oops.  My apologies, I obviously had 2.2 on the brain.  I should be able
to get to it in the next few weeks -- likely sooner.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#868497: debian-policy: Signed .dsc Files

[Russ Allbery]

Paul Hardy  writes:

> Package: debian-policy
> Version: 4.0.0.4
> Severity: wishlist

> Debian Policy Manual, Section 5.4, "Debian source control files - .dsc",
> states in the first sentence:

> "This file consists of a single paragraph, possibly surrounded by a PGP
> signature."

> This does not state whether someone who is creating a package to be
> uploaded by a sponsor can clearsign their own .dsc file, or if only the
> sponsor is able to do that without causing upload problems.

> What is permissible?  Can you clarify that in a future update to this
> section?

(I'm pretty sure the actual answer to this question is that nothing
cares.)

I assume you're talking about sponsorship via mentors.debian.org?  If so,
that's out of scope for Policy and one should refer to the local
documentation for how that system works (it's not the same as the regular
Debian archive).

All of the concepts you refer to in this bug report (sponsorship,
sponsors, someone else uploading a package for someone) are outside the
scope of Policy currently, so we'd have to define a whole bunch of terms
to even talk about this.

-- 
Russ Allbery (r...@debian.org)   

Bug#868505: FTBFS: downloads hardcoded and missing MUMPS source

[Drew Parsons]

On Sun, 16 Jul 2017 16:51:48 +0800 Drew Parsons 
wrote:

In fact inspecting configure.in suggests the correct solution is to add
--with-mumps-include and --with-mumps-libs to
DEB_CONFIGURE_EXTRA_FLAGS in debian/rules, pointing to libdmumps
provided by the Debian mumps packages.

Bug#863278: RFS: usbguard/0.7.0-1

[Muri Nicanor]

i've uploaded another version that removes an unused build-dependency



signature.asc
Description: OpenPGP digital signature

Bug#868534: diffoscope: autopkgtest failure

[Mattia Rizzolo]

Source: diffoscope
Version: 84
Severity: important

Starting with version 84 a new test started to fail in autopkgtest, the
one running the tests without recommends installed

https://ci.debian.net/data/autopkgtest/unstable/amd64/d/diffoscope/20170715_175521/log.gz

It seems to be caused by commit 037c92388ef75d5ace2d26dd85bcf7693ccf7cf6

comparators/directory: raise warning for getfacl and remove a
redundant try-clause


The important bit of the failure is

E - --- Logging error ---
E - Traceback (most recent call last):
E -   File "/build/diffoscope-84/diffoscope/comparators/directory.py", 
line 124, in compare_meta
E - differences.append(Difference.from_command(Getfacl, path1, 
path2))
E -   File "/build/diffoscope-84/diffoscope/difference.py", line 222, 
in from_command
E - feeder1, command1 = command_and_feeder(path1)
E -   File "/build/diffoscope-84/diffoscope/difference.py", line 217, 
in command_and_feeder
E - if command_excluded(command.shell_cmdline()):
E -   File 
"/build/diffoscope-84/diffoscope/comparators/utils/command.py", line 64, in 
shell_cmdline
E - return ' '.join(map(lambda x: '{}' if x == self.path else 
shlex.quote(x), self.cmdline()))
E -   File "/build/diffoscope-84/diffoscope/tools.py", line 71, in 
tool_check
E - raise RequiredToolNotFound(command)
E - diffoscope.exc.RequiredToolNotFound: getfacl
E - 
E - During handling of the above exception, another exception occurred:
E - 
E - Traceback (most recent call last):
E -   File "/usr/lib/python3.5/logging/__init__.py", line 988, in emit
E - stream.write(msg)
E - ValueError: I/O operation on closed file.


so my feeling is that it has to do with something like
https://github.com/pytest-dev/pytest/issues/14 (but there are countless
other examples on the net)

needless to say, we need to workaround this somehow.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#868507: Aw: Re : Bug#868507: libreoffice-writer: Crash after the last upgrade

[Rene Engelhard]

Hi,

This was a strace of the bash, not of LO..
You would have needed -f or -ff...

But I asked about a backtrace from gdb, not about a strace..

Regards,

Rene

> Gesendet: Sonntag, 16. Juli 2017 um 15:24 Uhr
> Von: nicolas.patr...@gmail.com
> An: "Rene Engelhard" 
> Cc: 868...@bugs.debian.org, cont...@bugs.debian.org
> Betreff: Re : Bug#868507: libreoffice-writer: Crash after the last upgrade
>
> Le 16/07/2017 10:47:16, Rene Engelhard a écrit :
> 
> > On Sun, Jul 16, 2017 at 10:33:22AM +0200, Nicolas Patrois wrote:
> > > LO crashes after the last upgrade:
> 
> > You you mean after the 5.2.7->5.3.4-4 update?
> 
> Yes.
> 
> > Interesting, I would have assumed it crashing with Java issues (Stack
> > Clash) directly. Do you have the stack clash security fixes enabled?
> 
> I don’t know.
> 
> > When does it crash?
> 
> On startup.
> 
> > Do you have a backtrace of this crash?
> 
> Here you are.
> 
> > Sigh. Any reason you use this obsolee arch instead of amd64 (if you
> > use -pae ways)?
> 
> Because my Debian was installed since Potato and I still did not installed 
> the 64bit thingies.
> 
> 
> nicolas patrois : pts noir asocial
> -- 
> RÉALISME
> 
> M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains 
> ? Un cerveau plus gros ?
> P : Non... Une carte bleue suffirait...
>

Bug#868544: RFS: dtksettings/0.1.7-1 [ITP]

[Boyuan Yang]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org

Dear mentors and chinese-developers folks,

I am looking for a sponsor for my package "dtksettings".

This source package provides libraries and a simple tool to deal with json 
configurations files used by softwares from Deepin Linux. This is the 
dependency 
of many Deepin softwares and DDE (Deepin Desktop Environment).

Note that the missing man page for /usr/bin/dtk-settings-tool: upstream does 
not provide any man pages for this simple wrapper tool. I intent to open a 
Debian bug and forward it to upstream after the initial upload.

* Package name: dtksettings
  Version : 0.1.7-1
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://github.com/linuxdeepin/dtksettings
   Section : devel

  It builds those binary packages:

libdtksettings-bin - Deepin Tool Kit Settings tool
 libdtksettings-dev - Deepin Tool Kit Settings library (development files)
 libdtksettings1 - Deepin Tool Kit Settings library
 libdtksettingsview-dev - Deepin Tool Kit Settings UI library (development 
files)
 libdtksettingsview1 - Deepin Tool Kit Settings UI library

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/d/dtksettings/
dtksettings_0.1.7-1.dsc

  Alternatively, one can retrieve more information from debomatic-amd64:

http://debomatic-amd64.debian.net/distribution#unstable/dtksettings/
0.1.7-1/

  Alioth packaging repository:

https://anonscm.debian.org/git/collab-maint/dtksettings.git

   More information about hello can be obtained from https://github.com/
linuxdeepin/dtksettings .

  Changes since the last upload:

 dtksettings (0.1.7-1) unstable; urgency=medium
 .
   * Initial release (Closes: #868494)

Regards,
Boyuan Yang

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

Bug#867652: jruby: FTBFS: Error creating shaded jar: Error in ASM processing class module-info.class: RemappingClassAdapter is deprecated, use ClassRemapper instead

[Miguel Landaeta]

Hi,

Quick FYI note for anybody interested in fixing bugs in jruby 1.7.x:

Right now I'm working to upload all the jruby 9.x B-D to sid, so it's
unlikely I'll spend any effort on fixing bugs on this version unless
they are also present in stable.

I'll close/fix this bug when I get jruby 9.x building in sid.

Cheers,
Miguel.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#868547: File conflict between inventor-clients-dbgsym and inventor-demo-dbgsym

[Adrian Bunk]

Source: inventor
Version: 2.1.5-10-19
Severity: serious
Control: affects -1 inventor-clients-dbgsym inventor-demo-dbgsym

# apt-get install inventor-clients-dbgsym inventor-demo-dbgsym
...
dpkg: error processing archive 
/tmp/apt-dpkg-install-6zLCzh/12-inventor-demo-dbgsym_2.1.5-10-19+b1_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/89/84bb7685c900ff00107e54f77d536d866cf8d5.debug', 
which is also in package inventor-clients-dbgsym 2.1.5-10-19+b1


The problem is that inventor-demo ships /usr/lib/inventor/SceneViewer
and inventor-clients ships /usr/bin/SceneViewer, both are the same binary.

Bug#868551: File conflict between redis-server-dbgsym and redis-tools-dbgsym

[Adrian Bunk]

Source: redis
Version: 3:3.2.6-1
Severity: serious
Control: affects -1 redis-server-dbgsym redis-tools-dbgsym

# apt-get install redis-server-dbgsym redis-tools-dbgsym 
...
dpkg: error processing archive 
/var/cache/apt/archives/redis-tools-dbgsym_3%3a3.2.6-1_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/28/5c12acf6bb346f94ffac33f4fe5f5bb9fbd88b.debug', 
which is also in package redis-server-dbgsym 3:3.2.6-1


The problem is that /usr/bin/redis-server in redis-server and
/usr/bin/redis-check-rdb in redis-tools are the same binary.

If this is intentional, one possible solution would be to make
redis-server a symlink to redis-check-rdb.

Bug#868550: still some remaining agent startup race (probability 10^-3 ?)

[Ian Jackson]

Package: gnupg2
Version: 2.1.18-6

I just had an invocation of the dgit test suite fail in one of the
tests because this happened:
  gpg: can't connect to the agent: IPC connect call failed

Unfortunately the failure is nonreproducible.  gpg didn't quote the
errno value.  A longer log excerpt is below.  (The W: messages from
apt about apt.conf.d/ are expected and normal.)

I haven't calculated the failure probability exactly, but this failure
occurred after about 10 test runs each consisting of 70 individual
test cases, most of which contains many (at a guess, 10?) gnupg
invocations (which may or may not share agent startup).  So probably
between 1/100 and 1/5, say.

(The dgit commit was 242ba73109ae30e7d8849b01f0c668b87d4f4d63; the
environment was stretch, last updated a few days ago.)

Thanks for your attention.

Regards,
Ian.

+ export 
APT_CONFIG=/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/conf
+ 
APT_CONFIG=/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/conf
+ gpg --export Hannibal
gpg: WARNING: unsafe permissions on homedir 
'/home/ian/things/Dgit/2dgit/tests/tmp/gnupg/gnupg'
+ fakeroot apt-key add
W: Unable to read 
/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
Warning: apt-key output should not be parsed (stdout is not a terminal)
W: Unable to read 
/home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
gpg: can't connect to the agent: IPC connect call failed
+ test 2 = 0
+ t-report-failure
+ set +x
TEST FAILED
cwd: /home/ian/things/Dgit/2dgit/tests/tmp/downstream-gitless
funcs: t-report-failure t-reprepro-cfg main
lines: 1 55 0
files: tests/lib /home/ian/things/Dgit/2dgit/tests/lib-reprepro 
tests/tests/downstream-gitless


-- 
Ian Jackson    These opinions are my own.

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

Bug#868379: calibre breaks with recent python-dateutil

[Manolo Díaz]

On Sunday, 16 Jul 2017 at 15:24 UTC
Guido Günther wrote:

> Hi,
> On Sun, Jul 16, 2017 at 05:12:28PM +0200, Manolo Díaz wrote:
> > On Sunday, 16 Jul 2017 at 11:27 UTC
> > Guido Günther wrote:
> >   
> > > Hi,
> > > On Sun, Jul 16, 2017 at 11:22:47AM +0200, Manolo Díaz wrote:  
> > > > On Sunday, 16 Jul 2017 at 09:05 UTC
> > > > Guido Günther wrote:
> > > > 
> > > > > Hi,
> > > > > control: affects -1 calibre
> > > > 
> > > > [...]
> > > > 
> > > > > Starts here without problems. Does
> > > > > 
> > > > >  python -c "from six.moves import _thread"
> > > > > 
> > > > > work for you? If it does not work your python-six is broken. Maybe you
> > > > > have a local version of six lying around?
> > > > > Cheers,
> > > > >  -- Guido
> > > > 
> > > > Hi,
> > > > 
> > > > python -c "from six.moves import _thread" does apparently nothing and
> > > > exits with 0. Is this expected?
> > > >
> > > 
> > > Yept. That's how it should be.
> > >   
> > > > The version of python-six on my system is 1.10.0-4 (current testing)
> > > > and if it was broken I think calibre wouldn't start with only
> > > > downgrading python-dateutil.
> > > 
> > > It might because the old python-dateutil version might not have used it.
> > > Can you do a
> > > 
> > >strace -f -s2048 /usr/bin/calibre
> > > 
> > > and attach this to the bugreport please.
> > > Cheers,
> > >  -- Guido  
> > 
> > Of course. It's attached.  
> 
> You have six.pyc in the calibre directory that's tripping up things:
> 
> open("/usr/lib/calibre/six.pyc", O_RDONLY) = 9
> 
> can you remove that and try again?
> Cheers,
>  -- Guido

It works. After removing /usr/lib/calibre/six.pyc calibre works again.
So you are right, it's not a python-datetime bug.

Thank you.

Regards,
-- 
Manolo Díaz

Bug#868556: linux-image-4.9.0-3-amd64: xHCI host not responding to stop endpoint command

[Lukas Fisch]

Package: src:linux
Version: 4.9.30-2+deb9u2
Severity: important

Dear Maintainer,

Having an external USB3 drive connected (/dev/sdd1) and copying data from it 
over an USB3 slot to an internal drive. Transfer rates are approx. 110MBytes/s.
Transfer fails after some minutes with "xHCI host not responding to stop 
endpoint command"
Excerpt from 'dmesg':
[  571.719939] xhci_hcd :03:00.0: xHCI host not responding to stop endpoint 
command.
[  571.719942] xhci_hcd :03:00.0: Assuming host is dying, halting host.
[  571.719973] xhci_hcd :03:00.0: HC died; cleaning up
[  571.720994] usb 3-4: USB disconnect, device number 2
[  571.736125] sd 5:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT 
driverbyte=DRIVER_OK
[  571.736130] sd 5:0:0:0: [sdd] tag#0 CDB: Read(10) 28 00 06 23 bb f0 00 02 00 
00
Only reboot recovers USB3 functionality. However, the issue is reproducible.

Transferring the data via USB2 slot instead works flawlessly.


-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 
root=UUID=5f4f17ee-e761-438f-9db6-17733a191579 ro quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[8.231250] ata4: SATA link down (SStatus 0 SControl 300)
[8.231289] ata3: SATA link down (SStatus 0 SControl 300)
[8.231678] ata2.00: ATA-10: WDC WD40EFRX-68N32N0, 82.00A82, max UDMA/133
[8.231680] ata2.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), 
AA
[8.231849] ata1.00: ATA-10: WDC WD40EFRX-68N32N0, 82.00A82, max UDMA/133
[8.231851] ata1.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), 
AA
[8.232544] ata2.00: configured for UDMA/133
[8.232592] ata1.00: configured for UDMA/133
[8.232986] scsi 1:0:0:0: Direct-Access ATA  WDC WD40EFRX-68N 0A82 
PQ: 0 ANSI: 5
[8.274909] Console: switching to colour frame buffer device 128x48
[8.300909] ast :02:00.0: fb0: astdrmfb frame buffer device
[8.336224] [drm] Initialized ast 0.1.0 20120228 for :02:00.0 on minor 0
[8.336564] sd 1:0:0:0: Attached scsi generic sg1 type 0
[8.336999] scsi 2:0:0:0: Direct-Access ATA  WDC WD40EFRX-68N 0A82 
PQ: 0 ANSI: 5
[8.337270] sd 1:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 
TB/3.64 TiB)
[8.337273] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[8.337363] sd 1:0:0:0: [sdb] Write Protect is off
[8.337366] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[8.337404] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[8.360424] igb :00:14.0: added PHC on eth0
[8.360427] igb :00:14.0: Intel(R) Gigabit Ethernet Network Connection
[8.360500] igb :00:14.0: eth0: PBA No: 010A00-000
[8.360503] igb :00:14.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx 
queue(s)
[8.386453] random: crng init done
[8.397646]  sdb: sdb1 sdb9
[8.398721] sd 1:0:0:0: [sdb] Attached SCSI removable disk
[8.400459] sd 2:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 
TB/3.64 TiB)
[8.400462] sd 2:0:0:0: [sdc] 4096-byte physical blocks
[8.400530] sd 2:0:0:0: Attached scsi generic sg2 type 0
[8.400588] sd 2:0:0:0: [sdc] Write Protect is off
[8.400591] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[8.400633] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[8.445692]  sdc: sdc1 sdc9
[8.446616] sd 2:0:0:0: [sdc] Attached SCSI removable disk
[8.553136] usb 3-4: new SuperSpeed USB device number 2 using xhci_hcd
[8.578510] usb 3-4: New USB device found, idVendor=0bc2, idProduct=a013
[8.578513] usb 3-4: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[8.578515] usb 3-4: Product: Backup+ BK
[8.578517] usb 3-4: Manufacturer: Seagate
[8.578519] usb 3-4: SerialNumber: NA51994Z
[8.580472] usb-storage 3-4:1.0: USB Mass Storage device detected
[8.580587] usb-storage 3-4:1.0: Quirks match for vid 0bc2 pid a013: 200
[8.580620] scsi host5: usb-storage 3-4:1.0
[8.593144] spl: loading out-of-tree module taints kernel.
[8.598606] SPL: Loaded module v0.6.5.9-1
[8.606700] znvpair: module license 'CDDL' taints kernel.
[8.606702] Disabling lock debugging due to kernel taint
[8.737196] igb :00:14.1: added PHC on eth1
[8.737200] igb :00:14.1: Intel(R) Gigabit Ethernet Network Connection
[8.737273] igb :00:14.1: eth1: PBA No: 010A00-000
[8.737275] igb :00:14.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx 
queue(s)
[8.830651] ZFS: Loaded module v0.6.5.9-5, ZFS pool version 5000, ZFS 
filesystem version 5
[9.121108] igb :00:14.2: added PHC on eth2
[9.12] igb :00:14.2: Intel(R) Gigabit Ethernet Network Connection
[9.121184] igb :00:14.2: eth2: 

Bug#868525: guile-2.0: New upstream version available

[Rob Browning]

Adrian Bunk  writes:

> Package: guile-2.0
> Version: 2.0.13+1-4
> Severity: wishlist
>
> Version 2.0.14 is available at
>   https://ftp.gnu.org/gnu/guile/
>
> Could you package this version?

It's already packaged, and waiting in the NEW queue:
https://ftp-master.debian.org/new.html

I assume the ftpmasters have just been busy with the stretch release.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#868564: File conflict between python-llvmlite-dbgsym and python3-llvmlite-dbgsym

[Adrian Bunk]

Source: llvmlite
Version: 0.16.0-1
Severity: serious
Control: affects -1 python-llvmlite-dbgsym python3-llvmlite-dbgsym

# apt-get install python-llvmlite-dbgsym python3-llvmlite-dbgsym 
...
dpkg: error processing archive 
/var/cache/apt/archives/python3-llvmlite-dbgsym_0.16.0-1_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/d1/1e181bd6228ccc8be91726416eb19cef0c11b3.debug', 
which is also in package python-llvmlite-dbgsym 0.16.0-1


The problem is that
/usr/lib/python{2.7,3}/dist-packages/llvmlite/binding/libllvmlite.so
is the same binary in two different packages.

The proper fix for this bug is to create a -common package for
libllvmlite.so that both python-llvmlite and python3-llvmlite
depend on.

Bug#867295: npm2deb: please automatically exclude certain files from debian/install

[Pirate Praveen]

Control: severity -1 grave

On Wed, 05 Jul 2017 17:12:32 +0200 Johannes Schauer 
wrote:
> Currently, npm2deb puts lots of files into debian/install including
> files which definitely do not belong into /usr/lib/nodejs/*/ like:
> 
> Hidden files like .travis.yml, .gitattribute, .npmignore, .jshintrc as
> well as files that clearly belong to /usr/share/doc/*/ like
> changelog.md, license.md or readme.md. Also certain buildsystem specific
> files could be excluded like gulpfile.js, karma.conf.js, Gruntfile.js or
> bower.json.
> 
> There are probably many more files that always have the same name but
> should never be shipped inside /usr/share/doc/*/ or at all.
> 
> 

This is a regression introduced in 0.2.7, previous versions did not have
this behavior. I think only *.js and *.json files should be included by
default.



signature.asc
Description: OpenPGP digital signature

Bug#868539: The BTS does not know that -dbgsym packages exist

[Don Armstrong]

Control: clone -1 -2
Control: retitle -2 please mirror debian-debug metadata onto buxtehude
Control: reassign -2 mirrors
Control: block -1 by -2

On Sun, 16 Jul 2017, Adrian Bunk wrote:
> The BTS does not know that these are from src:abiword
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=abiword-dbgsym
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=abiword-plugin-grammar-dbgsym

Thanks for the report; this requires some more mirroring of package
information to the BTS first, and then some more work on my end. I've
pinged people to get that started.

-- 
Don Armstrong  https://www.donarmstrong.com

Given that the odds of a miracle are one in one million, and events
which could be a miracle happen every second, the odds of not seeing a
miracle in a month are less than 8 in 100. Clearly miracles are not
all that miraculous.

Bug#868029: stretch-pu: package gnats/4.1.0-3+deb9u1

[Adam D. Barratt]

clone 868029 -1
tags -1 -stretch +jessie
user release.debian@packages.debian.org
usertags -1 pu
retitle -1 jessie-pu: package gnats/4.1.0-3+deb8u1
thanks

On Sat, 2017-07-15 at 21:19 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2017-07-11 at 12:08 +0200, Andreas Beckmann wrote:
> > gnats-user fails to purge if gnats was installed but has not been
> > purged, yet. This is triggered by several piuparts tests (currently
> > ignored, but I want to promote that to a proper failure without working
> > around it in piuparts).
> > This will add NEW -dbgsym packages to stretch, I hope that is no
> > problem.
> 
> Apparently dak should dtrt, so please go ahead.

I will note that I didn't explicitly ack an upload for jessie. As it's
happened anyway, cloning this report.

Regards,

Adam

Bug#868507: Re : Bug#868507: libreoffice-writer: Crash after the last upgrade

[Rene Engelhard]

Hi,

On Sun, Jul 16, 2017 at 04:04:00PM +0200, Rene Engelhard wrote:
> This was a strace of the bash, not of LO..
> You would have needed -f or -ff...
> 
> But I asked about a backtrace from gdb, not about a strace..

Thinking about it, maybe both would be helpful. But as said, you need -f
for strace.

a i386 stretch somehow doesn't want to install in my virt-manager so I
can't test myself (yet)...

Regards,
 
Rene
> 
> > Gesendet: Sonntag, 16. Juli 2017 um 15:24 Uhr
> > Von: nicolas.patr...@gmail.com
> > An: "Rene Engelhard" 
> > Cc: 868...@bugs.debian.org, cont...@bugs.debian.org
> > Betreff: Re : Bug#868507: libreoffice-writer: Crash after the last upgrade
> >
> > Le 16/07/2017 10:47:16, Rene Engelhard a écrit :
> > 
> > > On Sun, Jul 16, 2017 at 10:33:22AM +0200, Nicolas Patrois wrote:
> > > > LO crashes after the last upgrade:
> > 
> > > You you mean after the 5.2.7->5.3.4-4 update?
> > 
> > Yes.
> > 
> > > Interesting, I would have assumed it crashing with Java issues (Stack
> > > Clash) directly. Do you have the stack clash security fixes enabled?
> > 
> > I don’t know.
> > 
> > > When does it crash?
> > 
> > On startup.
> > 
> > > Do you have a backtrace of this crash?
> > 
> > Here you are.
> > 
> > > Sigh. Any reason you use this obsolee arch instead of amd64 (if you
> > > use -pae ways)?
> > 
> > Because my Debian was installed since Potato and I still did not installed 
> > the 64bit thingies.
> > 
> > 
> > nicolas patrois : pts noir asocial
> > -- 
> > RÉALISME
> > 
> > M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des 
> > humains ? Un cerveau plus gros ?
> > P : Non... Une carte bleue suffirait...
> >

Bug#845526: [PATCH] Allow users to specify the boot directory path

[Anisse Astier]

Hi Martin,

On Sun, Jun 18, 2017 at 11:08 PM, martin schitter  wrote:
> the suggested vmdebootstrap patch by Michael doesn't set the customized
boot
> mount point in /etc/fstab of the generated images.
>
> i also think, the '--bootdirfmt' and its unusual "%s..." syntax doesn't
look
> very handy. therefore i used a simple '--bootdir' option in my fix.
>
> working patch attached.

I've tried your patch to build an image, it's simpler and works well.

Regards,

Anisse

Bug#860325: [libbyte-buddy-java] branch master created (now e33e1ab)

[Felix Natter]

Emmanuel Bourg  writes:
> Hi Felix,

hello Emmanuel,
hello Paul,

> Thank you for packaging Byte Buddy, that one was on my todo list. If it
> isn't too late do you think it could be possible to rename the source
> package to byte-buddy instead of libbyte-buddy-java please?

@Emmanuel: I could not immediately make sense of the maven structure,
so it was on hold for some time. Paul (CC:) kindly offered to take over,
and of course I will help if he wants me to.

I have created a new repo "byte-buddy", and imported the 1.7.1 source
into it:
https://anonscm.debian.org/cgit/pkg-java/byte-buddy.git

@Paul: Could you please use this repo for packaging?

@Emmanuel: Can I just remove the old libbyte-buddy-java repo with
$ ssh fnatter-gu...@git.debian.org
$ cd /git/pkg-java
$ mv libbyte-buddy-java /tmp
?

Cheers and Best Regards,
-- 
Felix Natter

Bug#868554: pehash: segmentation fault

[Jakub Wilk]

Control: tags -1 + patch

The attached patch fixes it for me.

The const annotation is bogus, because this variable is going to be modified in 
the next line.


* Adrian Bunk , 2017-07-16, 19:10:

$ pescan test.exe
file entropy:5.924796 (normal)
fpu anti-disassembly:no
imagebase:   normal
entrypoint:  normal
DOS stub:normal
TLS directory:   found - 1 function(s)
timestamp:   normal
section count:   15 (high)
Segmentation fault


Good catch. My patch seems to fix this, too.

--
Jakub Wilk
--- a/src/output.c
+++ b/src/output.c
@@ -288,7 +288,7 @@
 	scope->depth = scope_depth + 1;
 
 	if (scope_depth > 0) {
-		output_scope_t * const parent_scope = NULL;
+		output_scope_t * parent_scope = NULL;
 		STACK_PEEK(g_scope_stack, (void *)_scope);
 		scope->parent_type = parent_scope->type;
 	}

Bug#868220: ifupdown should support vlan-aware bridges

[Guus Sliepen]

reassign 868220 bridge-utils
thanks

On Thu, Jul 13, 2017 at 09:48:49AM +0200, Joerg Dorchain wrote:

> Hello,
> 
> th elinux kernel support vlan aware bridges for a while now.
> (cfr. 
> http://events.linuxfoundation.org/sites/events/files/slides/LinuxConJapan2014_makita_0.pdf)
> 
> it would be great to have support in ifupdown for them, with
> config stanzas like bridge-vlan-aware, bridge-vid, bridge-pvid,
> etc. (cfr. package ifupdown2)

Ifupdown itself supports VLANs for any interface, but I think that's not
what you want. You want to assign VLANs to individual bridge ports. It
looks to me this functionality should be added to bridge-utils'
if-pre-up/down.d scripts, therefore I'm reassigning this bug to the
bridge-utils package.

On the other hand, it seems brctl itself is quite limited and doesn't
support any VLAN configuration, you'd have to use the "bridge" command
from iproute2.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

[Graham Inggs]

On 16 July 2017 at 13:12, Drew Parsons  wrote:
> Testing trilinos build on a porterbox for the mumps 5.1.1 transition.
>
> The following tests FAILED:
> 617 - ML_MLP_NonSym_MPI_4 (Failed)
> 668 - Phalanx_dag_manager_MPI_1 (Failed)
>
> Not sure if it's the new mumps, new openmpi 2.1.1 or something else.
> Full build log attached.

Reproducible build history shows FTBFS since 2017-07-02:
https://tests.reproducible-builds.org/debian/history/amd64/trilinos.html

Although with only one test failure:

The following tests FAILED:
668 - Phalanx_dag_manager_MPI_1 (Failed)

Bug#868477: jenkins: propose: use apt's Acquire:Retries options to limit the number of failures?

[Holger Levsen]

On Sat, Jul 15, 2017 at 10:53:56PM +0200, Mattia Rizzolo wrote:
> Therefore I propose injecting the apt option
> Acquire:Retries
> to a value of 3 to as many APTs as possible (reproducible pbuilder and
> schroot chroots, chroot-run chroots, more?)

great idea & patches much welcome! :-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature
___
Qa-jenkins-dev mailing list
qa-jenkins-...@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/qa-jenkins-dev

Bug#868531: swig: does not support Octave 4.2; please update

[Ole Streicher]

Package: src:swig
Version: 3.0.10-1.1
Affects: plplot
Severity: important
Tags: patch upstream
Control: forwarded -1 https://github.com/swig/swig/issues/847

The current version of swig does not support Octave 4.2. Since octave
4.2.1 is currently in Debian sid, swig is currently rather useless for
octave bindings.

The problem is solved with swig-3.0.12, so upgrading would fix this
problem. The current status however prevents from re-intoduction of the
octave-plplot package, hence the severity. There is however also a patch
available

https://github.com/swig/swig/pull/875

which is used by Fedora to fix the problem there.

Best regards

Ole

Bug#868530: ITP: ruby-geocoder -- complete geocoding solution for Ruby

[icyfire]

Package: wnpp Severity: wishlist Owner: Rajeev R Menon  X-Debbugs-CC: 
debian-de...@lists.debian.org (mailto:debian-de...@lists.debian.org) * Package 
name : ruby-geocoder Version : 1.4.4 Upstream Author : Alex Reisner  
(http://www.rubygeocoder.com) * URL : http://www.rubygeocoder.com 
(http://www.rubygeocoder.com) * License : Expat Programming Lang: Ruby 
Description : complete geocoding solution for Ruby Geocoder is a complete 
geocoding solution for Ruby. With Rails, it adds geocoding (by street or IP 
address), reverse geocoding (finding street address based on given 
coordinates), and distance queries. It's as simple as calling `geocode` on your 
objects, and then using a scope like `Venue.near ("Billings, MT")`. . Designed 
for Rails but works with Sinatra and other Rack frameworks too.

Bug#867295: [Pkg-javascript-devel] Bug#867295: npm2deb: please automatically exclude certain files from debian/install

[Shanavas]

On July 16, 2017 7:54:03 PM GMT+03:00, Pirate Praveen  
wrote:
>Control: severity -1 grave from wishlist
>
>This is a regression introduced in 0.2.7, previous versions did not
>have
>this behavior. 

Yes, the idea was to include all files that npm includes in tarball.

> I think only *.js and *.json files should be included by
>default.

Thats not enough. Executables mostly doesn't have an extension. *.js does 
include build configuration files.

Excluding a set of specific files would be better
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#868121: libgssapi-krb5-2: obsolete conffile left behind

[Benjamin Kaduk]

On Sun, Jul 16, 2017 at 12:53:18PM +1000, Paul Wise wrote:
> On Wed, 12 Jul 2017 04:53:35 -0400 Sam Hartman wrote:
> 
> > I'm not actually sure I particularly want it removed from the system.
> 
> Policy indicates that old conffiles should be removed on upgrade:

It's not really clear that this file constitutes either a conffile
or a configuration file -- it contains information that is globally
true (not site- or host-specific), does not affect the operation of
a program, and is not intended to be modified by the system administrator.

-Ben


signature.asc
Description: PGP signature

Bug#868569: New armhf/arm64 nodes (Jetson-tx1, Jetson-tk1)

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal
Tags: patch
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

I've made a jenkins.debian.net branch "new-armhf-jtk1b-jtx1b" that adds
the recently announced boards:

  https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git/

  
https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git/commit/?h=new-armhf-jtk1b-jtx1b

Hopefully it's everything needed to deploy to the new machines.

Thanks for working on Debian's jenkins infrastructure!

live well,
  vagrant

On 2017-07-13, Vagrant Cascadian wrote:
> Two new machines ready for incorporation into the armhf build network.
>
> Thanks to Nvidia, Debian and Freegeek for the donations that
> made this expansion phase possible!
>
> jtk1b-armhf-rb.debian.net:
> Jetson-TK1, nvidia tegra-k1 (cortex-a15) quad-core, 2GB ram
> ssh port: 2252
> ssh fingerprints:
> 256 MD5:67:0f:2e:8c:c7:4e:00:cd:70:67:5b:0e:b9:cd:6a:03 root@jtk1b (ECDSA)
> 256 SHA256:kbhhukXo+8XvSE6UXX84aoz8Ho1UkHjl8cD1TZEQWPk root@jtk1b (ECDSA)
> 256 SHA256:4KN325sMN5Xqs7xrZsMtsa4/fNJ/QLp0bGAGJ7a+gPI root@jtk1b (ED25519)
> 256 MD5:1f:26:49:7d:64:f5:21:ff:61:0f:96:74:10:20:09:88 root@jtk1b (ED25519)
> 2048 MD5:eb:f9:e2:18:d3:fe:5d:2f:eb:dd:56:5d:f3:ba:8c:d1 root@jtk1b (RSA)
> 2048 SHA256:j+qyOQOqKUhTsmmPxPqBAyvIKnlSfLgzj8h0hi7jVo8 root@jtk1b (RSA)
>
> jtx1b-armhf-rb.debian.net:
> Jetson-tx1, quad-core (big.LITTLE Cortex-A53/A57), ~3.5GB ram,
>   native sata ~500GB disk
> ssh port: 2253
> ssh fingerprints:
> 256 MD5:72:92:55:e9:81:b4:be:fa:f8:94:3a:f6:80:1c:e2:0e root@jtx1b (ECDSA)
> 256 SHA256:1Z99Rvm4USICiWUWy75tIVbV02eIMyNRW7gkZS5BE3Y root@jtx1b (ECDSA)
> 256 MD5:85:90:14:70:6b:d3:5c:ab:9a:b2:23:c0:c2:fc:6d:95 root@jtx1b (ED25519) 
> 256 SHA256:4sKcNcBtgHaVCP/BDN3Ke60JD7SuVglEvdRI2IKLg3o root@jtx1b (ED25519)
> 2048 MD5:64:e5:d0:dd:fc:24:10:54:b4:54:4c:55:ae:86:08:cf root@jtx1b (RSA)
> 2048 SHA256:uih3N0O1BOaRNdayWyTTb7iXFTV24vj7zG6Eunmu1Ak root@jtx1b (RSA)
>
>
> live well,
>   vagrant


signature.asc
Description: PGP signature

Bug#868524: libmtp9: Regresssion : Browse the folder of my smartphone take several minutes.

[joshua claveau]

Package: libmtp9
Version: 1.1.12-1~bpo8+1
Severity: important

Dear Maintainer,

I connect my smartphone (samsung galaxy A3 2017) with usb cable, and open it
with nautilus.
Nautilus take several minutes (more of 5 min) befor displaying the content of
the smartphone (sd card and phone itself).
When I can see the content, I can browse every files normaly, except the folder
named DCIM/Camera in the sdcard which take also several minute befor opening.

If I connect my smartphone without the sdcard everything work as espected.
This bug occur only when my smartphone have a sdcard.

This bug occur with the version of libmtp9 : 1.1.13-1.
I downgrade libmtp9 to version 1.1.12-1~bpo8+1 from jessie backports and with
this version, everything work as espected.

I use a debian stable/testing with gnome shell 3.22.2



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

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

Versions of packages libmtp9 depends on:
ii  dpkg   1.18.24
ii  libc6  2.24-12
ii  libgcrypt201.7.6-2
ii  libmtp-common  1.1.12-1~bpo8+1
ii  libusb-1.0-0   2:1.0.21-1
ii  multiarch-support  2.24-12

Versions of packages libmtp9 recommends:
ii  libmtp-runtime  1.1.12-1~bpo8+1
ii  udev232-25

libmtp9 suggests no packages.

-- no debconf information

Bug#868507: Re : Bug#868507: libreoffice-writer: Crash after the last upgrade

[nicolas . patrois]

Le 16/07/2017 10:47:16, Rene Engelhard a écrit :

> On Sun, Jul 16, 2017 at 10:33:22AM +0200, Nicolas Patrois wrote:
> > LO crashes after the last upgrade:

> You you mean after the 5.2.7->5.3.4-4 update?

Yes.

> Interesting, I would have assumed it crashing with Java issues (Stack
> Clash) directly. Do you have the stack clash security fixes enabled?

I don’t know.

> When does it crash?

On startup.

> Do you have a backtrace of this crash?

Here you are.

> Sigh. Any reason you use this obsolee arch instead of amd64 (if you
> use -pae ways)?

Because my Debian was installed since Potato and I still did not installed the 
64bit thingies.


nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...
execve("/usr/bin/lowriter", ["lowriter"], [/* 38 vars */]) = 0
brk(NULL)   = 0x808e1000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb76e6000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=406438, ...}) = 0
mmap2(NULL, 406438, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7682000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\203\1\0004\0\0\0"..., 512) 
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1787812, ...}) = 0
mmap2(NULL, 1796636, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb74cb000
mmap2(0xb767c000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b) = 0xb767c000
mmap2(0xb767f000, 10780, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb767f000
close(3)= 0
set_thread_area({entry_number:-1, base_addr:0xb76e8840, limit:1048575, 
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, 
useable:1}) = 0 (entry_number:6)
mprotect(0xb767c000, 8192, PROT_READ)   = 0
mprotect(0x8003b000, 4096, PROT_READ)   = 0
mprotect(0xb770f000, 4096, PROT_READ)   = 0
munmap(0xb7682000, 406438)  = 0
getpid()= 6095
rt_sigaction(SIGCHLD, {sa_handler=0x8002da30, sa_mask=~[RTMIN RT_1], 
sa_flags=0}, NULL, 8) = 0
geteuid32() = 1000
brk(NULL)   = 0x808e1000
brk(0x80902000) = 0x80902000
getppid()   = 6093
stat64("/home/nicolas", {st_mode=S_IFDIR|0750, st_size=20480, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0750, st_size=20480, ...}) = 0
open("/usr/bin/lowriter", O_RDONLY) = 3
fcntl64(3, F_DUPFD, 10) = 10
close(3)= 0
fcntl64(10, F_SETFD, FD_CLOEXEC)= 0
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x8002da30, sa_mask=~[RTMIN RT_1], 
sa_flags=0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=0}, 
NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=0}, 
NULL, 8) = 0
read(10, "#!/bin/sh\n/usr/lib/libreoffice/p"..., 8192) = 61
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0xb76e88a8) = 6096
wait4(-1, X-Error: BadMatch (invalid parameter attributes)
Major opcode: 154
Minor opcode: 5
Resource ID:  0x5a00013
Serial No:227 (227)
These errors are reported asynchronously,
set environment variable SAL_SYNCHRONIZE to 1 to help debugging
Application Error
[{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 6096
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6096, si_uid=1000, 
si_status=1, si_utime=0, si_stime=0} ---
sigreturn({mask=[]})= 6096
read(10, "", 8192)  = 0
exit_group(1)   = ?
+++ exited with 1 +++

Bug#868549: File conflict between libtext-ocaml-dbgsym and libtext-ocaml-dev-dbgsym

[Adrian Bunk]

Source: ocaml-text
Version: 0.6-3
Severity: serious
Control: affects -1 libtext-ocaml-dbgsym libtext-ocaml-dev-dbgsym

# apt-get install libtext-ocaml-dbgsym libtext-ocaml-dev-dbgsym
...
dpkg: error processing archive 
/tmp/apt-dpkg-install-HOOTgn/15-libtext-ocaml-dev-dbgsym_0.6-3+b2_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/28/31e5a712e95e39d2fe709c5a60d6de070131fb.debug', 
which is also in package libtext-ocaml-dbgsym 0.6-3+b2


4 copies of the same binary, in 2 different packages:

libtext-ocaml:
/usr/lib/ocaml/text/text-bigarray.cmxs
/usr/lib/ocaml/text/text-pcre.cmxs
/usr/lib/ocaml/text/text.cmxs

libtext-ocaml-dev:
/usr/lib/ocaml/text/text-pcre-syntax.cmxs

Bug#868557: mirror submission for mirrors.ges.net.pk

[Imran Qazi]

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

Submission-Type: new
Site: mirrors.ges.net.pk
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
CDImage-http: /debian-cd/
Archive-upstream: debian.inode.at
CDImage-upstream: debian.inode.at
Updates: four
Maintainer: Imran Qazi 
Country: PK Pakistan
Location: Pakistan [PK]
Sponsor: Gemnet Enterprise Solutions http://www.ges.net.pk




Trace Url: http://mirrors.ges.net.pk/debian/project/trace/
Trace Url: http://mirrors.ges.net.pk/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.ges.net.pk/debian/project/trace/mirrors.ges.net.pk

Trace Url: http://mirrors.ges.net.pk/debian-cd/project/trace/
Trace Url: http://mirrors.ges.net.pk/debian-cd/project/trace/cdimage.debian.org
Trace Url: http://mirrors.ges.net.pk/debian-cd/project/trace/mirrors.ges.net.pk

Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution

[Brian Potkin]

On Sun 16 Jul 2017 at 14:38:44 +, brian m. carlson wrote:

> On Sun, Jul 16, 2017 at 12:34:05AM +0100, Brian Potkin wrote:
> > On Sat 15 Jul 2017 at 19:40:04 +, brian m. carlson wrote:
> > > * Validate data.  Nobody is going to print a two-pixel raster image, and
> > >   cups should not accept it as a valid (and in this case, the only
> > >   valid) option.
> > 
> > cups and cupsfilters have both accepted and fixed past bugs in their
> > implementation of driverless printing. In some cases cups has made
> > allowances for deficiencies in a manufacturer's implementaion of IPP
> > Everywhere. But where does it end?
> > 
> > Assuming this is a firmware bug, doesn't the vendor (who after all is
> > using a well defined standard) have the reponsibility, especially if
> > the issue is drawn to their attention by an affected user? If AirPrint
> > was involved you could well imagine they would jump to it.
> 
> I have put in a support request with them.  However, I have no way to
> prove that this actually affects AirPrint, as I don't have any modern
> Apple devices.  I'm pretty sure my alternative is going to be returning
> the printer.
> 
> I will say that cups is clearly accepting invalid data.  How can a
> printer have a resolution of 600 dpi and only accept 600x2 raster
> images?  If the printer returned 600x-1 resolution, would cups accept
> that as well?

It would interesting to know Brother's response.
 
> > > * Use the printer resolution instead of the PWG resolution when
> > >   generating raster images.  At the very least, these should be
> > >   resolution options for configuration in addition to the PWG
> > >   resolution.
> > 
> > Surely the printer resolution is what is returned by an IPP query?
> > Either that, or it is in a supplied PPD.
> 
> The printer resolution is indeed returned in an IPP query, as you'll see
> in the data provided.  However, cups only accepts the PWG raster format
> resolution and ignores the printer resolution.  If the driverless
> printing option provided all three resolution options (600 dpi, 600x2400
> dpi, and 600x2 dpi), it would be easy to simply configure the printer to
> use one of the other options as a default.
> 
> I do view this aspect as a bug in cups.  I should be able to pick any
> resolution that the printer supports.

When it generates a PPD cups-browsed does fill in missing essential
options with defaults. Whether it corrects values for attributes (or
whether it is seen as desirable to do so) I do not know.
 
> The vendor does not supply a plain PPD for Linux.  They provide a
> proprietary driver.  While that may work for my x86 machines, that will
> not work for my ARM, MIPS, or PowerPC machines.

 > I made a suggestion on -user a week or two ago about this issue but no
 > response came back. I will repeat it here:
 >
 > The PPD in /etc/cups/ppd has a line beginning *cupsFilter:. .
 > Alter the line to read
 >
 >*cupsFilter: "application/vnd.cups-raster 50 rastertohp"
 >
 > Restart cups and do
 >
 >lp -d  /etc/nsswitch
 >
 > That file prints out perfectly on my PCL/PCLX capable LaserJet. (I
 > used a Brother PPD, with the altered line, for your printer).
 >
 >I am unsure about "50" in the *cupsFilter: line. "0" might be better.

-- 
Brian.

Bug#868562: ITP: sddm-config-editor -- Graphical editor for SDDM

[Alf Gaida]

Package: wnpp
Severity: wishlist
Owner: Alf Gaida 

* Package name: sddm-config-editor
  Version : 0.1
  Upstream Author : Yaohan Chen 
* URL : https://github.com/hagabaka/sddm-config-editor
* License : ASL
  Programming Lang: C++
  Description : Graphical editor for SDDM

Qt implementation of an graphical editor for SDDM. KDE has a KCM for
SDDM configuration. Other environments have no such things - vi and nano 
excluded.

Bug#868525: guile-2.0: New upstream version available

[Adrian Bunk]

On Sun, Jul 16, 2017 at 11:02:03AM -0500, Rob Browning wrote:
> Adrian Bunk  writes:
> 
> > Package: guile-2.0
> > Version: 2.0.13+1-4
> > Severity: wishlist
> >
> > Version 2.0.14 is available at
> >   https://ftp.gnu.org/gnu/guile/
> >
> > Could you package this version?
> 
> It's already packaged, and waiting in the NEW queue:
> https://ftp-master.debian.org/new.html
>...

That's guile-2.2

I'd just need guile-2.0 updated to 2.0.14 for a QA upload
of the latest upstream version of guile-gnome-platform that
depends on >= 2.0.14

Thanks
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#861333: r-base: R packages uploaded to Debian before 14 April 2017 that use .C or .Fortran fail to find objects

[Dirk Eddelbuettel]

Just a quick follow-up to say that I finally had some time to go over this
again (twice, in fact) and to also include BioC and 'other' packages.

A full write-up in the (GitHub) sources of package RcppAPT and also available
as a rendered vignette at

   http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

I have used the information therein to file the required binnmu request as
bug report #868558.

Cheers,  Dirk

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

Bug#868493: ifupdown: no match using mac/XXX/=foo

[Guus Sliepen]

On Sun, Jul 16, 2017 at 05:21:15AM +0200, Adam Borowski wrote:

> allow-hotplug mac/00:e0:4c:11:7f:4e/=wl0
> iface wl0 inet static
> wpa-ssid mial
> wpa-psk 
> address 192.168.8.6
> netmask 255.255.255.0
> 
> upgraded ifupdown to 0.8.20, and plugged the WiFi card back in.
> 
> It's sitting there under its old name and unconfigured as:
> 
> 5: wlan0:  mtu 1500 qdisc noop state DOWN group default 
> qlen 1000
> link/ether 00:e0:4c:11:7f:4e brd ff:ff:ff:ff:ff:ff

Fix is uploaded. However, note that ifupdown still doesn't rename
interfaces. After the fix your wlan0 interface will be configured
according to the info in the wl0 stanza, as if you'd typed:

ifup wlan0=wl0

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#868525: guile-2.0: New upstream version available

[Adrian Bunk]

Package: guile-2.0
Version: 2.0.13+1-4
Severity: wishlist

Version 2.0.14 is available at
  https://ftp.gnu.org/gnu/guile/

Could you package this version?


Thanks in advance

Bug#865443: broken bug gardening somewhere

[Ian Jackson]

Control: retitle -1 problem with --quilt=gbp, maybe .gitignore .pc

Sean Whitton writes ("broken bug gardening somewhere"):
> On Wed, Jun 21, 2017 at 01:51:06PM +, Debian Bug Tracking System wrote:
> > > submitter -2 Felipe Sateler 
> > Bug #865443 [dgit] problem with --quilt=gbp, maybe .gitignore .pc
> > Changed Bug submitter to 'Felipe Sateler ' from 'Sean 
> > Whitton '.
> 
> I haven't finished catching up on the thread, but this is definitely
> wrong.  Open , and compare the bug title
> and what I write in the first message :)

Yes.  Putting this back, which seems to have been done by mistake in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865443#61

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#868220: ifupdown should support vlan-aware bridges

[Guus Sliepen]

On Sun, Jul 16, 2017 at 01:54:54PM +0200, Joerg Dorchain wrote:

> > [...] I'm reassigning this bug to the bridge-utils package.
[...]
> But them again, vlan interface setup that originally started with
> the vconfig tool, is meanwhile part of the iproute2 toolset and
> supported directly by ifupdown. Maybe this is also the way for
> bridges?

It looks to me like iproute2 now provides a superset of vconfig and
brctl, so yes, perhaps it should all be configured using iproute2.
However, the bridge support for ifupdown currently lives in the
bridge-utils package, so that's why I've reassigned the bug there. But
if there is a desire to move the ifupdown integration scripts to the
ifupdown package, I'd not be opposed to that.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#868499: osmose-emulator: No sound

[James Cowgill]

Control: tags -1 patch upstream

Hi,

On 16/07/17 07:14, Diogo Martins Silva wrote:
> Package: osmose-emulator
> Version: 1.0-4
> Severity: important
> 
> Dear Maintainer,
> 
> Emulator correctly plays games, except with no sound.
> 
> Relevant Log entry:
> 
> cannot open audio device : plughw:0,0No such file or
> directory
> 
> I don't use plugged in sound card, just a regular laptop hardware sound card.

The attached patch might work by switching the ALSA device to "default".
Could you rebuild osmose-emulator and test it?

In this context "plughw:0,0" refers to passing the sound to the first
soundcard on the first device, after doing any necessary rate
conversion. This is bad because:
- It hardcodes the device (which as you found, may not even exist)
- It is incompatible with PulseAudio

Thanks,
James
diff -ur a/osmose/OsmoseCore.cpp b/osmose/OsmoseCore.cpp
--- a/osmose/OsmoseCore.cpp	2016-08-12 05:56:04.0 +0100
+++ b/osmose/OsmoseCore.cpp	2017-07-16 12:54:16.178464325 +0100
@@ -111,7 +111,7 @@
 {
 		try
 		{
-			sndThread = new SoundThread("plughw:0,0", p->getFIFOSoundBuffer());
+			sndThread = new SoundThread("default", p->getFIFOSoundBuffer());
 			sndThread->start(); 	// Start thread, not playing !		
 			string msg = "Creating SoundThread";
 			QLogWindow::getInstance()->appendLog(msg);


signature.asc
Description: OpenPGP digital signature

Bug#858673: Incorrect example of bind-mount /etc/fstab entries in README.Debian.gz

[Rainer Dorsch]

Package: zoneminder
Version: 1.30.0+dfsg-2
Followup-For: Bug #858673

Dear Maintainer,

I confirm this issue and the solution proposed in the bugreport works for me as 
well. Looks like an easy fix.

Thanks
Rainer



-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (300, 'unstable')
Architecture: armhf (armv7l)

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

Versions of packages zoneminder depends on:
ii  cakephp  2.8.5-1
ii  init-system-helpers  1.48
ii  javascript-common11
ii  libarchive-zip-perl  1.59-1
ii  libavcodec57 7:3.2.5-1
ii  libavformat577:3.2.5-1
ii  libavutil55  7:3.2.5-1
ii  libc62.24-11+deb9u1
ii  libclass-std-fast-perl   0.0.8-2
ii  libcurl3-gnutls  7.52.1-5
ii  libdata-dump-perl1.23-1
ii  libdate-manip-perl   6.57-1
ii  libdbd-mysql-perl4.041-2
ii  libdevice-serialport-perl1.04-3+b3
ii  libgcc1  1:6.3.0-18
ii  libgcrypt20  1.7.6-2+deb9u1
ii  libgnutls-openssl27  3.5.8-5+deb9u1
ii  libimage-info-perl   1.39-1
ii  libio-socket-multicast-perl  1.12-2+b3
ii  libjpeg62-turbo  1:1.5.1-2
ii  libjs-mootools   1.4.5~debian1-2.1
ii  libjson-any-perl 1.39-1
ii  libmariadbclient18   10.1.23-9+deb9u1
ii  libmime-lite-perl3.030-2
ii  libmime-tools-perl   5.508-1
ii  libnet-sftp-foreign-perl 1.86+dfsg-1
ii  libossp-uuid-perl [libdata-uuid-perl]1.6.2-1.5+b4
ii  libpcre3 2:8.39-3
ii  libperl5.24 [libdigest-sha-perl] 5.24.1-3
ii  libphp-serialization-perl0.34-1
ii  libsoap-wsdl-perl3.003-2
ii  libstdc++6   6.3.0-18
ii  libswscale4  7:3.2.5-1
ii  libsys-cpu-perl  0.61-2+b1
ii  libsys-meminfo-perl  0.99-1
ii  libsys-mmap-perl 0.17-1+b2
ii  liburi-encode-perl   1.1.1-1
ii  libvlc5  2.2.6-1~deb9u1
ii  libwww-perl  6.15-1
ii  mariadb-client-10.1 [virtual-mysql-client]   10.1.23-9+deb9u1
ii  perl 5.24.1-3
ii  perl-modules-5.24 [libmodule-load-conditional-perl]  5.24.1-3
ii  php-mysql1:7.0+49
ii  policykit-1  0.105-18
ii  rsyslog [system-log-daemon]  8.24.0-1
ii  zip  3.0-11+b1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages zoneminder recommends:
ii  apache2 [httpd] 2.4.25-3+deb9u1
ii  ffmpeg  7:3.2.5-1
ii  libapache2-mod-php  1:7.0+49
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.19-1
ii  mariadb-server-10.1 [virtual-mysql-server]  10.1.23-9+deb9u1
ii  mysql-server5.5.+default
ii  zoneminder-doc  1.30.0+dfsg-2

Versions of packages zoneminder suggests:
pn  fcgiwrap   
ii  logrotate  3.11.0-0.1

-- Configuration Files:
/etc/zm/zm.conf [Errno 13] Permission denied: '/etc/zm/zm.conf'

-- no debconf information

Bug#868536: ITP: ruby-geocoder -- complete geocoding solution for Ruby

[icyfire]

Package: wnpp Severity: 
wishlist Owner: Rajeev R Menon  
X-Debbugs-CC: debian-de...@lists.debian.org 

* Package name : ruby-geocoder Version : 1.4.4 
  Upstream Author : Alex Reisner  
(http://www.rubygeocoder.com) 
* URL : http://www.rubygeocoder.com 
* License : Expat 
  Programming Lang: Ruby 
  Description : complete geocoding solution for Ruby

 Geocoder is a complete geocoding solution for Ruby. With Rails, it adds 
 geocoding (by street or IP address), reverse geocoding (finding street address 
 based on given coordinates), and distance queries. It's as simple as calling 
 `geocode` on your objects, and then using a scope like `Venue.near 
 ("Billings, MT")`. 
 . 
 Designed for Rails but works with Sinatra and other Rack frameworks too.

Bug#868553: new upstream (2.3.1.0)

[Daniel Baumann]

Package: ansible

Hi,

it would be nice if you could upload ansible 2.3.

Regards,
Daniel

Bug#863970: jessie-pu: package debian-security-support/2016.06.02~deb8u1

[Guido Günther]

Hi,
On Sat, Jul 15, 2017 at 11:33:25AM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2017-06-02 at 14:55 +0200, Guido Günther wrote:
> > I'd like to update debian-security-support among the supported suites so
> > users get up to date information from check-security-support. Since the
> > last update to Jessie was almost a year ago I've rebuilt the current
> > version for Jessie.
> > 
> > The debdiff looks huge due to translation improvements but if you filter
> > these out (2016.06.02+deb8u1-withou-po.diff) it doesn't look that bad.
> > 
> > O.k. to upload to stable-p-u?
> 
> Well, not stable-p-u now. :-)
> 
> +debian-security-support (2017.06.02+deb8u1) jessie; urgency=medium
> 
> That wants to be 2017.06.02~deb8u1, as you need the version to be
> smaller than unstable.
> 
> With that change, please go ahead.

Uploaded. Thanks!
 -- Guido

Bug#868563: apparmor-profiles: Apparmor profiles for postfix programs have incorrect path

[debian-bugs]

Package: apparmor-profiles
Version: 2.11.0-3
Severity: important

Dear Maintainer,

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

After upgrading from jessie to stretch I noticed that postfix was no longer 
constrained by apparmor profiles (using aa-unconfined, ps auxZ etc).

The cause of this issue seems to be that the profiles in this package use paths 
like /usr/lib/postfix/master but this has moved to /usr/lib/postfix/sbin/master.
This applies to all /usr/lib/postfix/* profiles. Thus the profiles do not 
properly apply to the correct process. The profiles will need to be updated to 
point
to the right executables.

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


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

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

Versions of packages apparmor-profiles depends on:
ii  apparmor  2.11.0-3

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- Configuration Files:

-- no debconf information

Bug#868491: eth0 missing from /run/network/ifstate

[Vincent Blut]

On Sun, Jul 16, 2017 at 01:04:33PM +0200, Vincent Blut wrote:

On Sat, Jul 15, 2017 at 05:02:57PM -0700, John Eikenberry wrote:

Package: chrony
Version: 3.0-4
Severity: normal

Dear Maintainer,


Hello John,

After upgrading to stretch I noticed my network was not registering 
correctly.

By this I mean that even though the network (eth0) came up and worked, it
didn't have an entry in /run/network/ifstate (the ifstate file was empty).

This is using ifupdown + ifplugd in a setup that worked fine on jessie and
works fine now after removing chrony.


I’m sad to hear that upgrading to Stretch caused you some troubles!


It took me a while to nail down the problem, but I finally noticed this kept
showing up in my log.

  run-parts: /etc/network/if-up.d/chrony exited with return code 1

When I put an 'exit 0' at the top of that script my networking came up fine
and was added to /run/network/ifstate. So by exiting with an error that script
was preventing ifup from completing the ifstate registration.


I will try to reproduce this issue by setting up a similar network 
environment.


Before digging through that issue, that would be awesome if you could 
reinstall chrony and edit the line where “chronyc” is called by:


chronyc online > /dev/null 2>&1  (i.e. removing “-m” and “'burst 4/10'”)

Could you please report back if you are willing to test that of course?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#868568: adduser - deluser command says user has running processes when user has a custom UID assigned

[Niels Hendriks]

Package: adduser
Version: 3.115
OS: Debian 9 amd64

Linux debian 4.9.15-x86_64-linode81 #1 SMP Fri Mar 17 09:47:36 EDT 2017
x86_64 GNU/Linux

dpkg -s libc6 | grep ^Version
Version: 2.24-11

Hello,

On a clean Debian 9 amd64 install the deluser command detects running
processes from the user I am trying to delete, while no processes are
running under that user. This is only the case when the user has a special
UID assigned.

Steps to reproduce on a clean Debian 9 install. I did this on a Linode upon
the first login with SSH as root:

adduser foo
adduser foo1234 --uid 101234
adduser foo1234 sudo
su - foo1234
sudo su -
# enter sudo password
deluser foo

This gives the following output:

root@debian:~# adduser foo
Adding user `foo' ...
Adding new group `foo' (1000) ...
Adding new user `foo' (1000) with group `foo' ...
Creating home directory `/home/foo' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for foo
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
root@debian:~# adduser foo1234 --uid 101234
Adding user `foo1234' ...
Adding new group `foo1234' (101234) ...
Adding new user `foo1234' (101234) with group `foo1234' ...
Creating home directory `/home/foo1234' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for foo1234
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
root@debian:~# adduser foo1234 sudo
Adding user `foo1234' to group `sudo' ...
Adding user foo1234 to group sudo
Done.
root@debian:~# su - foo1234
foo1234@debian:~$ sudo su -
[sudo] password for foo1234:
root@debian:~# deluser foo
Removing user `foo' ...
Warning: group `foo' has no more members.
userdel: user foo is currently used by process 4892
/usr/sbin/deluser: `/usr/sbin/userdel foo' returned error code 8. Exiting.
root@debian:~#
root@debian:~# ps aux | grep 4892
foo1234   4892  0.0  0.4  20936  4740 pts/0S17:54   0:00 -su
root  4917  0.0  0.0  12788   940 pts/0S+   17:55   0:00 grep 4892


As you can see I am unable to delete the user foo because of the running
process with pid 4892, which is actually the process from user foo1234

When I do not assign a specific UID to the user foo1234 it works correctly
and as expected.

I also used specific UIDs in debian 8, and this issue did not pop up there.
It seems to be new in debian 9.

This is my first bug report to Debian so I hope all required information is
present and that you are able to reproduce it with the above steps.

Thanks,
Niels Hendriks

Bug#867175: [Pkg-tigervnc-devel] Bug#867175: Supplied Patch for tigervncserver wrapper does not handle rfbport

[Ola Lundqvist]

Hi

Thank you.

// Ola

On 14 July 2017 at 15:57,  wrote:

> Did crawl through the code and kind of figured out how it is supposed to
> work.
> Turns out rfbport was passed through as misc option and not used in the
> wrapper at all.
>
> Attached a debdiff Patch for tigervncserver to include rfbport.
> Not a Perl programmer mind you...
>
> Hopefully the attachment works, never tried this from shell before.
> 
> 
> 
>  Philipp Wolski - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
> Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns
> Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers
> Phone: +49 441 93602 -158 | Fax: +49 441 93602 -222 | E-Mail:
> philipp.wol...@kisters.de | WWW: http://www.kisters.de
> 
> 
> 
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>



-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#868459: stretch-pu: package libquicktime/2:1.2.4-10+deb9u1

[Adam D. Barratt]

On Sun, 2017-07-16 at 18:41 +0200, Moritz Mühlenhoff wrote:
> On Sat, Jul 15, 2017 at 09:19:08PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Sat, 2017-07-15 at 19:12 +0200, Moritz Muehlenhoff wrote:
> > > some minor security fixes for libquicktime, identical to what's
> > > already in unstable and also tested with reverse deps on stretch.
> > > 
> > > If it's too late for 9.1, 9.2 is also just fine.
> > 
> > Feel free to upload, we'll see if it makes it in time.
> 
> Thanks, uploaded.

Unfortunately, I've had to flag the upload for rejection - it's somehow
picked up a new dependency on "libschroedinger-1.0-0 (>= 1.0.0)", but
that binary package is not in stretch.

Regards,

Adam

Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

[Nico Schlömer]

I've disabled the phalanx tests in master, and also fixed two other things.
Perhaps it's time for an upload?

Cheers,
Nico


On Sun, Jul 16, 2017 at 2:16 PM Nico Schlömer 
wrote:

> The issue was reported to upstream in May [1]. I think until we get a fix,
> it's best to disable that specific test.
>
> Cheers,
> Nico
>
>
> [1] https://github.com/trilinos/Trilinos/issues/1332
>
> On Sun, Jul 16, 2017 at 1:51 PM Graham Inggs  wrote:
>
>> On 16 July 2017 at 13:12, Drew Parsons  wrote:
>> > Testing trilinos build on a porterbox for the mumps 5.1.1 transition.
>> >
>> > The following tests FAILED:
>> > 617 - ML_MLP_NonSym_MPI_4 (Failed)
>> > 668 - Phalanx_dag_manager_MPI_1 (Failed)
>> >
>> > Not sure if it's the new mumps, new openmpi 2.1.1 or something else.
>> > Full build log attached.
>>
>> Reproducible build history shows FTBFS since 2017-07-02:
>> https://tests.reproducible-builds.org/debian/history/amd64/trilinos.html
>>
>> Although with only one test failure:
>>
>> The following tests FAILED:
>> 668 - Phalanx_dag_manager_MPI_1 (Failed)
>>
>>

Bug#868570: python-klein: Fails to upgrade: "async def leaf(request): SyntaxError: invalid syntax"

[Axel Beckert]

Package: python-klein
Version: 17.2.0-1
Severity: serious

Upgrading python-klein from 16.12.0-1 to 17.2.0-1 fails for me as
follows:

[…]
Setting up python-klein (17.2.0-1) ...
  File "/usr/lib/python2.7/dist-packages/klein/test/py3_test_resource.py", line 
26
async def leaf(request):
^
SyntaxError: invalid syntax

dpkg: error processing package python-klein (--configure):
 subprocess installed post-installation script returned error exit status 101
[…]

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

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

Versions of packages python-klein depends on:
ii  python   2.7.13-2
ii  python-incremental   16.10.1-3
ii  python-six   1.10.0-4
ii  python-twisted-core  16.6.0-2
ii  python-werkzeug  0.12.2+dfsg1-2

python-klein recommends no packages.

python-klein suggests no packages.

-- no debconf information

Bug#868507: Re : Re : Bug#868507: libreoffice-writer: Crash after the last upgrade

[Rene Engelhard]

On Sun, Jul 16, 2017 at 08:02:18PM +0200, nicolas.patr...@gmail.com wrote:
> Le 16/07/2017 16:04:00, Rene Engelhard a écrit :
> 
> > This was a strace of the bash, not of LO..
> > You would have needed -f or -ff...
> 
> > But I asked about a backtrace from gdb, not about a strace..
> 
> Sorry.
> Here is the strace -f output (nearly 2Mo).

OK; thanks.

> I never used gbd but the binary seems to be 
> /usr/lib/libreoffice/program/oosplash, not lowriter that is a shell script.

No, the actual binary is soffice.bin. Yes, lowriter is (as is soffice what
it calls, that one "only" calls soffice.bin) one. That's why you need -f.

> [pid  1905] execve("/usr/lib/libreoffice/program/soffice.bin", 
> ["/usr/lib/libreoffice/program/sof"..., "--writer", "--splash-pipe=5"], [/* 
> 42 vars */] 

So here the actual LO gets ran.

[ snip ]

Oh, no. nvidia. Does it also happen with drivers actually in Debian?

(If you had Java enabled, you probably would run in to the Java Stack
clash segfault, so don't remove .config/libreoffice as that would reset
it to Defauls, which would crash.)

Regards,

Rene

Bug#868379: Processed (with 4 errors): python-dateutil: makes calibre fail to start

[Guido Günther]

Hi,
On Sun, Jul 16, 2017 at 11:22:47AM +0200, Manolo Díaz wrote:
> On Sunday, 16 Jul 2017 at 09:05 UTC
> Guido Günther wrote:
> 
> > Hi,
> > control: affects -1 calibre
> 
>   [...]
> 
> > Starts here without problems. Does
> > 
> >  python -c "from six.moves import _thread"
> > 
> > work for you? If it does not work your python-six is broken. Maybe you
> > have a local version of six lying around?
> > Cheers,
> >  -- Guido
> 
> Hi,
> 
> python -c "from six.moves import _thread" does apparently nothing and
> exits with 0. Is this expected?
>

Yept. That's how it should be.

> The version of python-six on my system is 1.10.0-4 (current testing)
> and if it was broken I think calibre wouldn't start with only
> downgrading python-dateutil.

It might because the old python-dateutil version might not have used it.
Can you do a

   strace -f -s2048 /usr/bin/calibre

and attach this to the bugreport please.
Cheers,
 -- Guido

Bug#868468: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u2

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-07-15 at 22:57 +0100, James Cowgill wrote:
> On 15/07/17 20:50, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Sat, 2017-07-15 at 20:37 +0100, James Cowgill wrote:
> >> Some more security issues were discovered in libopenmpt so it will need
> >> another stretch update. One of the issues looked potentially serious so
> >> I had CVE-2017-11311 allocated for it. That CVE has been marked as
> >> no-dsa by the security team.
> >>
> >> Also, sorry this is pretty late for 9.1.
> > 
> > It is, but if it's uploaded in time then it still might make it.
> 
> Thankyou! Uploaded.

Flagged for acceptance into p-u.

Regards,

Adam

Bug#867335: stretch-pu: package systemd/232-25

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-07-16 at 00:16 +0200, Michael Biebl wrote:
> Am 15.07.2017 um 23:28 schrieb Cyril Brulebois:
> > Adam D. Barratt  (2017-07-13):
> >> On Wed, 2017-07-05 at 23:25 +0200, Michael Biebl wrote:
> > […]
> >> I'm okay with the diff, but as mentioned:
> >>
> >>> The changes shouldn't affect the installer. CCed debian-boot
> >>> nonetheless for a KiBi ack.
> > 
> > Testing looks good, fine with me.
> 
> Thank you both. Just uploaded 232-25+deb9u1 a few minutes ago.

Flagged for acceptance.

Regards,

Adam

Bug#868106: jessie-pu: package rkhunter/1.4.2-0.4

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-07-15 at 11:44 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2017-07-11 at 20:20 -0700, Francois Marier wrote:
> > This is an update for a security issue that is not going to get a DSA:
> > 
> > https://security-tracker.debian.org/tracker/CVE-2017-7480
> > 
> > Attached is the debdiff against the version in stable.
> 
> This also didn't make it to debian-release for some reason.
> 
> A changelog distribution of "jessie" would be preferred over
> "oldstable".
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#755544: notmuch-emacs: doesn't check gpg/pgp signatures by default

[David Bremner]

David Bremner  writes:

> Vagrant Cascadian  writes:
>
>> Package: notmuch-emacs
>> Version: 0.18.1-1
>> Severity: important
>>
>> Thanks for notmuch-emacs, it's great!

this bug is fixed in master / release 

Bug#868379: calibre breaks with recent python-dateutil

[Guido Günther]

Hi,
On Sun, Jul 16, 2017 at 05:12:28PM +0200, Manolo Díaz wrote:
> On Sunday, 16 Jul 2017 at 11:27 UTC
> Guido Günther wrote:
> 
> > Hi,
> > On Sun, Jul 16, 2017 at 11:22:47AM +0200, Manolo Díaz wrote:
> > > On Sunday, 16 Jul 2017 at 09:05 UTC
> > > Guido Günther wrote:
> > >   
> > > > Hi,
> > > > control: affects -1 calibre  
> > > 
> > >   [...]
> > >   
> > > > Starts here without problems. Does
> > > > 
> > > >  python -c "from six.moves import _thread"
> > > > 
> > > > work for you? If it does not work your python-six is broken. Maybe you
> > > > have a local version of six lying around?
> > > > Cheers,
> > > >  -- Guido  
> > > 
> > > Hi,
> > > 
> > > python -c "from six.moves import _thread" does apparently nothing and
> > > exits with 0. Is this expected?
> > >  
> > 
> > Yept. That's how it should be.
> > 
> > > The version of python-six on my system is 1.10.0-4 (current testing)
> > > and if it was broken I think calibre wouldn't start with only
> > > downgrading python-dateutil.  
> > 
> > It might because the old python-dateutil version might not have used it.
> > Can you do a
> > 
> >strace -f -s2048 /usr/bin/calibre
> > 
> > and attach this to the bugreport please.
> > Cheers,
> >  -- Guido
> 
> Of course. It's attached.

You have six.pyc in the calibre directory that's tripping up things:

open("/usr/lib/calibre/six.pyc", O_RDONLY) = 9

can you remove that and try again?
Cheers,
 -- Guido

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

R 3.4.0, which was released in April, made one subtle breaking change
affecting how (optional) compiled code in contributed package is loaded,
affecting the older two of the three (plus one internal) available
mechanisms:  .C() and .Fortran().  Packages still load and run parts of
their code, they just can no longer access this compiled code---unless
rebuilt. 

This has been discussed in #86133 at https://bugs.debian.org/861333

I have now prepared a fine-grained set of packages requiring a NMU, narrowing
the actual set of required rebuilds down from an unconditional 514 packages
(all reverse depends of r-base-core) to 92 packages meeting all requirements.

  nmu r-bioc-makecdfenv_1.50.0-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-bioc-multtest_2.30.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-edger_3.14.0+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-boolnet_2.1.3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-tikzdevice_0.10-1-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-logspline_2.1.9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-genabel_1.8-0-1+b1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-lhs_0.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-limma_3.30.8+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-coin_1.1-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-other-iwrlars_0.9-5-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-mnp_2.6-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-msm_1.6.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-fields_8.10-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-desolve_1.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-adephylo_1.1-10-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-dosefinding_0.9-15-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-deldir_0.1-12-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-rniftilib_0.0-35.r79-2 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-data.table_1.10.0-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-qtl_1.40-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-preprocesscore_1.36.0-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-contfrac_1.1-10-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-glmnet_2.0-5-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-bitops_1.0-6-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-sp_1:1.2-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-spc_1:0.5.3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-snpstats_1.24.0+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-tgp_2.4-14-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-brglm_0.5-9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-cmprsk_2.2-7-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-affy_1.52.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-ncdf4_1.15-1+b2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-treescape_1.10.18-6 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-bioc-rbgl_1.50.0+dfsg1-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-bioc-rtracklayer_1.34.1-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-hexbin_1.27.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-princurve_1.1-12-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-mapproj_1.2-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-blockmodeling_0.1.8-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-hdf5_1.6.10-4+b1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-pscl_1.4.9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-ade4_1.7-5-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-vgam_1.0-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-adegenet_2.0.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-mixtools_1.0.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-phylobase_0.8.2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-amelia_1.7.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-spam_1.4-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-medadherence_1.03-2 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-bioc-biobase_2.34.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-surveillance_1.13.0-1 . ANY . -m 'Rebuild against R 3.4.*, see 
#861333'
  nmu r-cran-randomfieldsutils_0.3.15-1 . ANY . -m 

Bug#867701: Radeon HD 6450, black screen, cursor, no console

[Michel Dänzer]

On 15/07/17 07:24 AM, Ivan Sergio Borgonovo wrote:

On 07/15/2017 05:29 AM, Michel Dänzer wrote:

On 15/07/17 07:10 AM, Ivan Sergio Borgonovo wrote:

On 07/10/2017 04:03 AM, Michel Dänzer wrote:

On 09/07/17 03:06 AM, Ivan Sergio Borgonovo wrote:



Please provide the output of the following:

apt-cache policy libegl1-mesa

ldconfig -p|grep libEGL


See attachments.


Hmm, the string "EGL search path is" and the corresponding code was 
removed upstream for Mesa 10.6. Look for instances of libEGL.so.1* other 
than /usr/lib/x86_64-linux-gnu/libEGL.so.1* on your system and see if 
removing those helps.




Does the same problem happen with 1:7.8.0-1+b1 with

 Option "AccelMethod" "glamor"

in /etc/X11/xorg.conf ?


Older xserver-xorg-video-radeon with that option DOESN'T WORK.
Black screen, text cursor at the top right corner ( _ ).


Right, as expected the problem is specific to glamor, which is the
default for your GPU in 7.9.0 but wasn't yet in 7.8.0. This means in the
worst case you can work around the problem with

Option"AccelMethod" "EXA"

in /etc/X11/xorg.conf.


Thanks, this solved the problem.

Could I suggest to add some notes in the changelog before closing the bug?


It's just a workaround. We don't know yet what the problem is, though 
it's likely specific to your system.



--
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

Bug#868459: stretch-pu: package libquicktime/2:1.2.4-10+deb9u1

[Moritz Mühlenhoff]

On Sat, Jul 15, 2017 at 09:19:08PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-07-15 at 19:12 +0200, Moritz Muehlenhoff wrote:
> > some minor security fixes for libquicktime, identical to what's
> > already in unstable and also tested with reverse deps on stretch.
> > 
> > If it's too late for 9.1, 9.2 is also just fine.
> 
> Feel free to upload, we'll see if it makes it in time.

Thanks, uploaded.

Cheers,
Moritz

Bug#858797: fp-docs-3.0.0: strutils (RTL) content missing from fp-docs

[Paul Gevers]

On Sun, 26 Mar 2017 22:12:10 +0100 peter  wrote:
> I observe that for strutils RTL documentation, most of the content is missing.
> 2.6.4 was OK, 3.0.2 is also missing content.
> The upstream on-line version is OK
> http://www.freepascal.org/docs-html/current/rtl/strutils/index-5.html
> 
> Content for all other units I have checked so far is present. It just seems to
> be strutils.

I did look around a bit today, but I can't find anything special about
strutils in the documentation. I did try and run¹
LC_ALL=C.UTF-8 $(MAKE) -C fpcdocs updatexml $(CONVERTER)
instead of
LC_ALL=C.UTF-8 $(MAKE) -C fpcdocs $(CONVERTER)
which didn't help.

There are two errors in the build log close by, but I don't think they
are related.

/<>/fpc-3.0.2+dfsg/fpcsrc/rtl/inc/typshrdh.inc(122,18): Syntax
error in type at token "constructor" in file
/<>/fpc-3.0.2+dfsg/fpcsrc/rtl/inc/typshrdh.inc at line 122
column 18

and

/<>/fpc-3.0.2+dfsg/fpcsrc/rtl/objpas/sysutils/syshelph.inc(4,27):
Expected "class" at token "array" in file
/<>/fpc-3.0.2+dfsg/fpcsrc/rtl/objpas/sysutils/syshelph.inc at
line 4 column 27

Apart from consulting upstream, I have no idea how to debug this issue.

Paul

¹ debomatic-amd64.debian.net/distribution#unstable/fpc/3.0.2+dfsg-5



signature.asc
Description: OpenPGP digital signature

Bug#868220: ifupdown should support vlan-aware bridges

[Joerg Dorchain]

On Sun, Jul 16, 2017 at 01:35:43PM +0200, Guus Sliepen wrote:
> 
> Ifupdown itself supports VLANs for any interface, but I think that's not
> what you want. You want to assign VLANs to individual bridge ports. It
> looks to me this functionality should be added to bridge-utils'
> if-pre-up/down.d scripts, therefore I'm reassigning this bug to the
> bridge-utils package.

Well, ok with that.

> On the other hand, it seems brctl itself is quite limited and doesn't
> support any VLAN configuration, you'd have to use the "bridge" command
> from iproute2.

Yes, that is my current way of setting up a vlan aware bride.

But them again, vlan interface setup that originally started with
the vconfig tool, is meanwhile part of the iproute2 toolset and
supported directly by ifupdown. Maybe this is also the way for
bridges?

Bye,

Joerg


signature.asc
Description: PGP signature

Bug#868526: dgit-user(7) should say how to use sbuild

[Ian Jackson]

Package: dgit
Version: 3.11

This is not trivial, because sbuild wants to work from a source
package, and the purely git-based workflow here does not produce a
tree that can be represented by dpkg-source.

For now it appears likely that
  sbuild --dpkg-source-opts='--format=1.0 -sn'
will generate a 1.0 native source package and should work.

However, I think it will leave the "source package" lying around in
the user's .. .  This is a hazard, because that "source package" is a
bear trap: it cannot be extracted and re-packed !

Also it will probably apply unnecessarily-vigorous compression to the
package.

Some testing is needed.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

[Nico Schlömer]

The issue was reported to upstream in May [1]. I think until we get a fix,
it's best to disable that specific test.

Cheers,
Nico


[1] https://github.com/trilinos/Trilinos/issues/1332

On Sun, Jul 16, 2017 at 1:51 PM Graham Inggs  wrote:

> On 16 July 2017 at 13:12, Drew Parsons  wrote:
> > Testing trilinos build on a porterbox for the mumps 5.1.1 transition.
> >
> > The following tests FAILED:
> > 617 - ML_MLP_NonSym_MPI_4 (Failed)
> > 668 - Phalanx_dag_manager_MPI_1 (Failed)
> >
> > Not sure if it's the new mumps, new openmpi 2.1.1 or something else.
> > Full build log attached.
>
> Reproducible build history shows FTBFS since 2017-07-02:
> https://tests.reproducible-builds.org/debian/history/amd64/trilinos.html
>
> Although with only one test failure:
>
> The following tests FAILED:
> 668 - Phalanx_dag_manager_MPI_1 (Failed)
>
>

Bug#868527: want sbuild --no-source or something

[Ian Jackson]

Package: sbuild
Version: 0.73.0-4
Severity: wishlist

It would be nice if it were easier to use sbuild with a gitish
downstream workflow which does not produce "3.0 (quilt)" source
packages.

For example, consider this scenario:

   dgit clone foo stretch
   cd foo
   hack hack hack
   git commit
   git merge upstream/stable
   hack hack hack
   git commit
   gbp dch
   sbuild -A
   dpkg -iGOEB ../*.deb

This is similar to the recommendatioms in dgit-user(7), except that we
are trying to use sbuild.

The above attempt will probably fail.

This is because the package "foo" is probably "3.0 (quilt)", according
to debian/source/format.  sbuild will try to build a source package,
and dpkg-source will want the user's changes to be "committed" as
patches in debian/patches.  The user won't have done that and probably
doesn't want to.  Worse, in the general case, changes might be made to
the git tree which dpkg-source cannot represent.

The solution is to not build a source package.  The user who adopts a
gitish workflow probably doesn't want one.  However, sbuild needs a
source package because that's how it transfers the package into the
chroot.

I suggest that sbuild grow an option which generates a dummy source
package in some hidden or temporary place.  I think the actual source
package generation can be done with something like this rune (and that
this will always succeed):
  dpkg-source -Zgzip -z0 --format=1.0 -sn
(but I have not yet tested this myself).

I don't have much of an opinion what the sbuild option should be
called.  --no-source is a possibility.  Or maybe it should be inferred
from the other options and the fact that sbuild is working from a
directory tree - although that would be an incompatible change.

In the meantime, I think users can use
  sbuild -A --dpkg-source-opts='-Zgzip -z0 --format=1.0 -sn'
However, that sets up a hazard: it produces a dummy 1.0 native tarball
package as if it were a build product.  But that native tarball
package is broken: it can be extracted and built, but it cannot be
re-packed, without again providing special optionsn to dpkg-source.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#868532: RM: docbook-xsl-saxon-gcj -- NBS; The docbook-xsl-saxon-gcj binary is no longer built by docbook-xsl-saxon

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal


docbook-xsl-saxon (1.00.dfsg.1-7) unstable; urgency=low

  * QA upload.
  * GCJ is gone in GCC >= 7, stop building docbook-xsl-saxon-gcj.
(Closes: #865119)

 -- Adrian Bunk   Wed, 05 Jul 2017 17:12:01 +0300

Bug#868541: File conflict between canna-dbgsym and canna-utils-dbgsym

[Adrian Bunk]

Source: canna
Version: 3.7p3-13.1
Severity: serious
Control: affects -1 canna-dbgsym canna-utils-dbgsym

# apt-get install canna-dbgsym canna-utils-dbgsym 
...
dpkg: error processing archive 
/var/cache/apt/archives/canna-utils-dbgsym_3.7p3-13.1+b1_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/f2/eaf1c24857f1ff846231444c5ce28379c5896d.debug', 
which is also in package canna-dbgsym 3.7p3-13.1+b1


The problem is that /usr/bin/cannakill and /usr/bin/catdic
are the same binary.

Bug#868542: File conflict between pypy-dulwich-dbgsym and python-dulwich-dbgsym

[Adrian Bunk]

Package: python-dulwich
Version: 0.17.3-1
Severity: serious
Control: affects -1 pypy-dulwich-dbgsym python-dulwich-dbgsym

# apt-get install pypy-dulwich-dbgsym python-dulwich-dbgsym
...
Unpacking python-dulwich-dbgsym (0.17.3-1+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/python-dulwich-dbgsym_0.17.3-1+b1_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/2d/2a908b1dd3051039a4955ae7a91f692487ab66.debug', 
which is also in package pypy-dulwich-dbgsym 0.17.3-1+b1


This is caused by a bug in the python-dulwich package:
/usr/lib/python2.7/dist-packages/dulwich/_diff_tree.pypy-41-x86_64-linux-gnu.so
/usr/lib/python2.7/dist-packages/dulwich/_diff_tree.x86_64-linux-gnu.so
/usr/lib/python2.7/dist-packages/dulwich/_objects.pypy-41-x86_64-linux-gnu.so
/usr/lib/python2.7/dist-packages/dulwich/_objects.x86_64-linux-gnu.so
/usr/lib/python2.7/dist-packages/dulwich/_pack.pypy-41-x86_64-linux-gnu.so
/usr/lib/python2.7/dist-packages/dulwich/_pack.x86_64-linux-gnu.so

AFAIK the pypy versions belong neither into this path nor into this package.

Bug#868543: ITP: shutit -- automation framework

[Ian Miell]

Package: wnpp
Severity: ITP

Source is available here:
https://github.com/ianmiell/shutit

Licence: MIT
https://github.com/ianmiell/shutit#licence

The package is currently maintained as a pip (and pip3) install:

https://pypi.python.org/pypi/shutit

Ian Miell

Bug#868545: File conflict between gnu-smalltalk-browser-dbgsym and gnu-smalltalk-dbgsym

[Adrian Bunk]

Source: gnu-smalltalk
Version: 3.2.5-1
Severity: serious
Control: affects -1 gnu-smalltalk-browser-dbgsym gnu-smalltalk-dbgsym

# apt-get install gnu-smalltalk-browser-dbgsym gnu-smalltalk-dbgsym
...
dpkg: error processing archive 
/var/cache/apt/archives/gnu-smalltalk-dbgsym_3.2.5-1+b3_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/debug/.build-id/85/c53be87b9b72cd4c1f4d651fac4e9e55377211.debug', 
which is also in package gnu-smalltalk-browser-dbgsym 3.2.5-1+b3


The problem is that the same binary is shipped (with 9 different names)
in different packages:
$ file /usr/bin/gst*|grep c53be87b9b72cd4c1f4d651fac4e9e55377211
/usr/bin/gst-browser:ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped
/usr/bin/gst-convert:ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped
/usr/bin/gst-doc:ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped
/usr/bin/gst-load:   ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped
/usr/bin/gst-package:ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped
/usr/bin/gst-profile:ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped
/usr/bin/gst-reload: ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped
/usr/bin/gst-remote: ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped
/usr/bin/gst-sunit:  ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, BuildID[sha1]=85c53be87b9b72cd4c1f4d651fac4e9e55377211, 
stripped

Bug#868548: ITP: ruby-cocaine -- library for running command line commands in Ruby

[Amruth Lal]

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

* Package name: ruby-cocaine
  Version : 0.5.8
  Upstream Author : Jon Yurek 
* URL : https://github.com/thoughtbot/cocaine
* License : Expat
  Programming Lang: Ruby
  Description : library for running command line commands in Ruby
 cocaine is used to run command line commands in Ruby. Commands are run
 using backticks(Ruby 1.8) or Process.spawn(Ruby 1.9).
 .
 This library supports interpolated arguments and prevents attempts
 to break system. This library throws exception if the command returns
 errors.
 .
 Performance can be increased by installing posix-spawn gem.
 ---

Bug#868537: I'll work on this

[Simon Quigley]

Control: owner -1 tsimo...@ubuntu.com

I can take care of this when I do the next QA upload for this package.

Thanks!

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

Bug#868559: live-boot: httpfs does not work due to util-linux's mount being used

[Daniel Reichelt]

Package: live-boot
Version: 1:20170623
Severity: normal

Hi,

when building a stretch live image which includes httpfs/buster for the created
live-image's initramfs to support live-boot's httpfs switch, the boot process
fails in a way similar to what has been reported in #823856.

Special handling for ${FUSE_MOUNT}s (httpfs, curlftps) was added to use
util-linux's mount instead of the klibc's in such cases. I tested the use of a
FUSE-based rootfs in conjunction with klibc's mount, and it seems, nowadays the
both of them work together.

So, the conditional incorporation and replacement of the mount command is both
no longer necessary, and has become harmful. The attached patch against
live-boot's current tag 1%20170623 removes it.


Cheers

Daniel
>From 3891e35f1df321e44e51347df95938346c108ef4 Mon Sep 17 00:00:00 2001
From: Daniel Reichelt 
Date: Sun, 16 Jul 2017 17:15:46 +0200
Subject: [PATCH] use klibc's mount again for ${FUSE_MOUNT}s

---
 backend/initramfs-tools/live.hook | 4 
 components/9990-mount-http.sh | 6 --
 2 files changed, 10 deletions(-)

diff --git a/backend/initramfs-tools/live.hook b/backend/initramfs-tools/live.hook
index 1ce922d..c5d7266 100755
--- a/backend/initramfs-tools/live.hook
+++ b/backend/initramfs-tools/live.hook
@@ -149,10 +149,6 @@ then
 	copy_exec /usr/bin/eject /bin
 fi
 
-# Program: mount
-# fuse does not work with klibc mount
-copy_exec /bin/mount /bin/mount.util-linux
-
 [ "${QUIET}" ] || echo -n " utils"
 
 # Feature: Verify Checksums
diff --git a/components/9990-mount-http.sh b/components/9990-mount-http.sh
index 2e68fe6..f58c3a3 100755
--- a/components/9990-mount-http.sh
+++ b/components/9990-mount-http.sh
@@ -54,12 +54,6 @@ do_httpmount ()
 			FUSE_MOUNT="httpfs"
 		fi
 
-		if [ -n "${FUSE_MOUNT}" ] && [ -x /bin/mount.util-linux ]
-		then
-			# fuse does not work with klibc mount
-			ln -f /bin/mount.util-linux /bin/mount
-		fi
-
 		modprobe fuse
 		$FUSE_MOUNT "${url}" "${dest}"
 		ROOT_PID="$(minips h -C "$FUSE_MOUNT" | { read x y ; echo "$x" ; } )"
-- 
2.1.4

Bug#868554: pehash: segmentation fault

[Petter Reinholdtsen]

[Jakub Wilk]
> I've forwarded the patch upstream.

Thank you.  I've uploaded a fixed version to unstable.

-- 
Happy hacking
Petter Reinholdtsen

Bug#864028: stretch-pu: package flatpak, maybe want debdiff against security?

[Simon McVittie]

On Sun, 16 Jul 2017 at 10:24:36 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: stretch-pu: package flatpak, maybe want debdiff 
> against security?"):
> > gtk-doc.make is copied in from gtk-doc-tools by gtkdocize during the
> > upstream autogen.sh run. It isn't currently replaced by dh_autoreconf.
> > I could re-run gtkdocize with Debian's gtk-doc-tools at dh_autoreconf
> > time if the release team want, but my assumption had been that this
> > non-minimal change would be rejected.
> 
> It seems to me that this means that the source code for your proposed
> updated package is not entirely within Debian.  That is, your source
> code includes the source in gtk-doc-tools which produces gtk-doc.make.

The source code for gtk-doc.make is itself. The canonical copy is in
gtk-doc (Debian package gtk-doc-tools) and is copied into packages that
consume it by gtkdocize, but it isn't compiled or machine-edited: the
version in gtk-doc is no more or less the preferred form for editing
than the version in flatpak_*.orig.tar.xz.

Before you object on the grounds of embedded code copies, gtk-doc.make
is a convenience copy specifically intended to be used in this way
(Policy §4.13). If it wasn't intended to be used in this way, then the
Autotools integration recommended by the gtk-doc maintainers (a large
part of which *is* gtk-doc.make) wouldn't arrange for gtk-doc.make to
be copied into distributed tarballs.

> But the
> relevant gtk-doc-tools is not in Debian, because it's the one upstream
> used to prepare their flatpak "source" package.
> 
> So this is, technically, a violation of the licence and of policy.

If this is something you feel strongly about, I would suggest that bugs
filed against either release.debian.org or individual Autotools packages
like Flatpak are not a suitable place to arrive at a solution; and there
seems to be consensus that Autotools "make dist" tarballs are something
we want to use as our source code.

If we want to treat upstream's tarball releases as privileged and use them
wherever possible (Devref §6.7.8.1) then upstreams will have a limited
supply of patience and goodwill if we start to insist on those tarball
releases being prepared in a specific way or on a specific distribution. I
think we should avoid expending that goodwill unnecessarily, particularly
if we want upstreams to pay attention when we ask them to remove non-Free
files. Flatpak upstream uses Autotools and gtk-doc according to their
documentation on some arbitrary non-Debian distribution (I think Alex
uses Fedora, and in practice he makes all the releases).

For anything built with Autotools, if we want "orig" tarballs to contain
exactly those files that upstream prefers to modify (all files in the
upstream VCS and no files not in the upstream VCS) then we cannot obey
Devref §6.7.8.1 in its current form. We have to pick one, and obeying
Devref is the common practice.

codesearch.debian.net says Flatpak is one of around 3234 source packages
using something resembling Automake's "make dist" (search terms:
"path:configure M4sh\ Initialization"). If it is preferable to recommend
some derivative of git-archive output (in Flatpak's case it would have
to be a submodule-aware variation of git-archive) then that is a rather
extensive change, and one that contradicts what we have traditionally
asked our upstreams to do. A number of upstreams that produce tarballs
specifically because Debian has asked them to would likely be rather
upset to be told that their tarballs are in fact unacceptable to Debian,
so this is not something I am willing to do without clear project
consensus, and in particular not something I am going to mess with in
a stable-update.

> > Yes. Blame Autotools.
> 
> I think that's unfair on autotools...

It is primarily Autotools from which we get this convention that upstream
source releases contain additional files beyond what was written by the
upstream of this particular package (in this case Flatpak). gtk-doc.make
is, if anything, more source-like than aclocal.m4, which we seem to be
willing to tolerate in thousands of packages (aclocal.m4 is not source
in the strictest possible sense, but it is a trivial concatenation of
files that are source).

S

Bug#868526: dgit-user(7) should say how to use sbuild

[Sean Whitton]

Could you explain why you think it is desirable to have anything about
sbuild in dgit-user(7)?  Don't we have `apt-get build-dep` for precisely
this use-case -- a user wanting to make modifications to a package from
the suite they are running?

sbuild-createchroot(1) is pretty good, but I'm not sure why users
wanting to apply patches to packages in their suite would want to use
it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#868057: [ftpmas...@ftp-master.debian.org: davmail_4.8.0.2479-2_amd64.changes REJECTED]

[Geert Stappers]

- Forwarded message from Debian FTP Masters 
 -

Date: Sun, 16 Jul 2017 21:35:27 +
From: Debian FTP Masters 
To: Alexandre Rossi , stapp...@debian.org
Subject: davmail_4.8.0.2479-2_amd64.changes REJECTED

davmail_4.8.0.2479-2_all.deb: trying to install to unstable, but could not find 
source

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

- End forwarded message -

Seen it.
Will be fixed after some sleep.

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#867124: Not a kernel bug

[Ben Hutchings]

Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=191201
Control: severity -1 important
Control: tag -1 wontfix

On Tue, 4 Jul 2017 06:23:35 -0400 Mini Trader  wrote:
> This seems to be an ESXi bug.
> 
> Exact same error being reported here.  I've followed their suggested
> settings and was no longer able to produce the kernel panic.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=191201

Thanks for investigating this.  I agree this seems to be the same bug. 
As VMware seems to have decided to fix this only in the hypervisor and
not to work around it in the vmxnet3 driver, there is probably nothing
for us to do here.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.



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

Bug#868600: python-glanceclient FTBFS with python 3.6 as supported version

[Adrian Bunk]

Source: python-glanceclient
Version: 1:2.5.0-3
Severity: serious
Tags: buster sid

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

...
===> Testing with python (python3)
+ rm -rf .testrepository
+ testr-python3 init
+ mktemp -t
+ TEMP_REZ=/tmp/tmp.PibLfS1VGx
+ + tee /tmp/tmp.PibLfS1VGx
subunit2pyunit
+ pwd
+ PYTHONPATH=/build/1st/python-glanceclient-2.5.0 PYTHON=python3.6 
testr-python3 run --subunit 
glanceclient\.tests\.unit\.(?!(.*v2.test_client_requests.ClientTestRequests.test_show_bad_image_schema.*|.*test_ssl.TestHTTPSVerifyCert.test_v1_requests_cert_verification.*|.*test_ssl.TestHTTPSVerifyCert.test_v2_requests_cert_verification.*|.*test_get_schema.*))
Non-zero exit code (2) from test listing.
running=${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./glanceclient/tests/unit} --list 
--- import errors ---
Failed to import test module: glanceclient.tests.unit.test_client
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File 
"/build/1st/python-glanceclient-2.5.0/glanceclient/tests/unit/test_client.py", 
line 20, in 
from glanceclient import v2
  File "/build/1st/python-glanceclient-2.5.0/glanceclient/v2/__init__.py", line 
15, in 
from glanceclient.v2.client import Client  # noqa
  File "/build/1st/python-glanceclient-2.5.0/glanceclient/v2/client.py", line 
19, in 
from glanceclient.v2 import image_members
  File "/build/1st/python-glanceclient-2.5.0/glanceclient/v2/image_members.py", 
line 16, in 
import warlock
  File "/usr/lib/python3/dist-packages/warlock/__init__.py", line 18, in 

from warlock.core import model_factory
  File "/usr/lib/python3/dist-packages/warlock/core.py", line 19, in 
from . import model
  File "/usr/lib/python3/dist-packages/warlock/model.py", line 20, in 
import jsonpatch
  File "/usr/lib/python3/dist-packages/jsonpatch.py", line 114, in 
json.load = get_loadjson()
  File "/usr/lib/python3/dist-packages/jsonpatch.py", line 108, in get_loadjson
argspec = inspect.getargspec(json.load)
  File "/usr/lib/python3.6/inspect.py", line 1072, in getargspec
raise ValueError("Function has keyword-only parameters or annotations"
ValueError: Function has keyword-only parameters or annotations, use 
getfullargspec() API which can support them
...
Ran 0 tests in 1.867s

OK
+ cat /tmp/tmp.PibLfS1VGx
+ + subunit-filtersubunit-stats -s
 --no-passthrough
Total tests:   0
Passed tests:  0
Failed tests:  0
Skipped tests: 0
Seen tags: 
+ rm -f /tmp/tmp.PibLfS1VGx
+ testr-python3 slowest
debian/rules:26: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 3

Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts

[Paul Hardy]

Control: severity 868496 wishlist

On Sun, Jul 16, 2017 at 1:01 PM, Sean Whitton  wrote:
> Hello Paul,
>
> On Sun, Jul 16, 2017 at 02:56:24AM -0700, Paul Hardy wrote:
>> Then would you consider it acceptable to make some mention in a
>> footnote to the effect that with the latest "dh" build tools, it isn't
>> necessary to have postinst and postrm scripts in the debian directory
>> for this purpose?  Because otherwise, someone who did not already know
>> about this could misunderstand the implications of this requirement
>> and create redundant postinst and postrm scripts.
>
> The problem is that if we think there should be footnotes explaining
> that there is a dh_* tool that takes care of the requirement, we would
> then need new footnotes to almost every section of Policy.  That would
> be a bad idea.

Yes, I could see that spiraling out of control.

My intention was to point someone new to packaging fonts in Debian in
the direction of an easy path, rather than leaving it up to that
person to find things out the hard way--or worse yet, doing things the
hard way.

How about a footnote pointing to
https://wiki.debian.org/Fonts/PackagingPolicy?  That document is not
formal policy, but it would make life easier for someone if they are
new to packaging fonts.

Alternatively, do you think this bug report should get reassigned to
the New Maintainer's Guide and be addressed as a request there?  The
scope of that guide is mainly to walk someone through creating a
simple binary package.

I have downgraded this bug to "wishlist" because it is not an actual
issue with Debian Policy.

Thanks,


Paul Hardy

Bug#868603: json-smart FTBFS: ASM based accessors helper used by json-smart FAILURE

[Adrian Bunk]

Source: json-smart
Version: 2.2-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes json-smart FTBFS:

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

...
dh_auto_build -- --file parent/pom.xml package
/usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/1st/json-smart-2.2 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/build/1st/json-smart-2.2/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/build/1st/json-smart-2.2/debian 
-Dmaven.repo.local=/build/1st/json-smart-2.2/debian/maven-repo --file 
parent/pom.xml package -DskipTests -Dnotimestamp=true -Dlocale=en_US
[INFO] Scanning for projects...
[INFO] 

[INFO] Reactor Build Order:
[INFO] 
[INFO] Minidev super pom
[INFO] ASM based accessors helper used by json-smart
[INFO] JSON Small and Fast Parser
[INFO] 
[INFO] 

[INFO] Building Minidev super pom 2.2
[INFO] 

[INFO] 
[INFO] 

[INFO] Building ASM based accessors helper used by json-smart 
1.1
[INFO] 

[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources 
(default-resources) @ accessors-smart ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/build/1st/json-smart-2.2/accessors-smart/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.6.1:compile 
(default-compile) @ accessors-smart ---
[WARNING] The POM for org.codehaus.plexus:plexus-compiler-api:jar:2.x 
is invalid, transitive dependencies (if any) will not be available, enable 
debug logging for more details
[WARNING] The POM for 
org.codehaus.plexus:plexus-compiler-javac:jar:2.x is invalid, transitive 
dependencies (if any) will not be available, enable debug logging for more 
details
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 12 source files to 
/build/1st/json-smart-2.2/accessors-smart/target/classes
[INFO] 
/build/1st/json-smart-2.2/accessors-smart/src/main/java/net/minidev/asm/ASMUtil.java:
 Some input files use or override a deprecated API.
[INFO] 
/build/1st/json-smart-2.2/accessors-smart/src/main/java/net/minidev/asm/ASMUtil.java:
 Recompile with -Xlint:deprecation for details.
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources 
(default-testResources) @ accessors-smart ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/build/1st/json-smart-2.2/accessors-smart/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.6.1:testCompile 
(default-testCompile) @ accessors-smart ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 24 source files to 
/build/1st/json-smart-2.2/accessors-smart/target/test-classes
[INFO] 
[INFO] --- maven-surefire-plugin:2.17:test 
(default-test) @ accessors-smart ---
[INFO] Tests are skipped.
[INFO] 
[INFO] --- maven-bundle-plugin:2.5.4:bundle 
(default-bundle) @ accessors-smart ---
[WARNING] Bundle net.minidev:accessors-smart:bundle:1.1 : Export 
net.minidev.asm,  has 1,  private references [org.objectweb.asm], 
[ERROR] Bundle net.minidev:accessors-smart:bundle:1.1 : Classes found 
in the wrong directory: {module-info.class=org.objectweb.asm.module-info}
[ERROR] Error(s) found in bundle configuration
[INFO] 

[INFO] Reactor Summary:
[INFO] 
[INFO] Minidev super pom .. 
SUCCESS [  0.003 s]
[INFO] ASM based accessors helper used by json-smart .. 
FAILURE [  2.829 s]
[INFO] JSON Small and Fast Parser 

Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[Dmitry Smirnov]

On Monday, 5 June 2017 9:38:13 AM AEST Colin Watson wrote:
> Would you like to look into why that didn't work on your system?

Probably due to failure of (non essential) mount point or unrelated service...

It happened again today:


Jul 17 09:14:00 deblab systemd[1]: Starting OpenBSD Secure Shell server...
Jul 17 09:14:00 deblab sshd[153531]: Missing privilege separation directory: 
/run/sshd
Jul 17 09:14:00 deblab systemd[1]: ssh.service: Main process exited, 
code=exited, status=255/n/a
Jul 17 09:14:00 deblab systemd[1]: Failed to start OpenBSD Secure Shell server.
Jul 17 09:14:00 deblab systemd[1]: ssh.service: Unit entered failed state.
Jul 17 09:14:00 deblab systemd[1]: ssh.service: Failed with result 'exit-code'.


So I had a chance to try another fix to the problem: I was able to start
"ssh.service" again after adding the following line:

RuntimeDirectory=sshd

Perhaps that would be a reliable way to fix the problem...

See [1] for details.

[1]: 
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory=

-- 
Regards,
 Dmitry Smirnov.


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

Bug#868604: apertium-nno FTBFS: Error: Position on line 6990 near `O inf)␊;␊#sjeldent i` - stand-alone o or O doesn't make sense - maybe you meant 0?

[Adrian Bunk]

Source: apertium-nno
Version: 0.9.0~r69513-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes apertium-nno FTBFS:

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

...
make -j1
make[1]: Entering directory '/build/1st/apertium-nno-0.9.0~r69513'
apertium-validate-dictionary apertium-nno.nno.dix
apertium-nno.nno.dix validates
lt-comp lr apertium-nno.nno.dix nno.automorf.bin
final@inconditional 42 218
main@standard 88076 227631
apertium-validate-dictionary apertium-nno.nno.dix
apertium-nno.nno.dix validates
lt-comp --alt nno_a rl apertium-nno.nno.dix nno.autogen.bin
final@inconditional 42 218
main@standard 87248 216119
apertium-validate-dictionary apertium-nno.nno.dix
apertium-nno.nno.dix validates
lt-comp --alt nno_e rl apertium-nno.nno.dix nno_e.autogen.bin
final@inconditional 42 218
main@standard 87089 215960
lt-print nno.automorf.bin | gzip -9 -c -n > nno.automorf.att.gz
lt-print nno.autogen.bin | gzip -9 -c -n > nno.autogen.att.gz
/usr/bin/cg-comp apertium-nno.nno.rlx nno.rlx.bin
apertium-nno.nno.rlx: Error: Position on line 6990 near `O inf)␊;␊#sjeldent i` 
- stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-nno.nno.rlx: Warning: Expected closing ; on line 52066 after previous 
rule!
Error: Grammar could not be parsed - exiting!
Makefile:752: recipe for target 'nno.rlx.bin' failed
make[1]: *** [nno.rlx.bin] Error 1
make[1]: Leaving directory '/build/1st/apertium-nno-0.9.0~r69513'
dh_auto_build: make -j1 returned exit code 2
debian/rules:9: recipe for target 'build' failed
make: *** [build] Error 2

Bug#868608: apertium-hbs-mkd FTBFS: Error: Position on line 323 near `O A) (-1 BOS) (0 Gen` - stand-alone o or O doesn't make sense - maybe you meant 0?

[Adrian Bunk]

Source: apertium-hbs-mkd
Version: 0.1.0~r57554-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes apertium-hbs-mkd FTBFS:

https://tests.reproducible-builds.org/debian/history/apertium-hbs-mkd.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apertium-hbs-mkd.html

...
lt-comp rl apertium-hbs-mkd.hbs-mkd.dix mkd-hbs.autobil.bin
cent@standard 1284 1540
common@standard 4081 5532
east@standard 1468 1766
main@standard 14592 22575
west@standard 1405 1663
apertium-validate-dictionary apertium-hbs-mkd.mkd.dix
apertium-hbs-mkd.mkd.dix:2484: element pardef: Schemas validity error : Element 
'pardef': Duplicate key-sequence ['зн/ае__vblex'] in unique identity-constraint 
'pardef-unique'.
apertium-hbs-mkd.mkd.dix fails to validate
lt-comp rl apertium-hbs-mkd.mkd.dix hbs-mkd.autogen.bin
final@inconditional 161 792
main@standard 12630 25786
prefixes@standard 9 9
cg-comp apertium-hbs-mkd.hbs-mkd.rlx hbs-mkd.rlx.bin
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 191 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 194 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 214 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 216 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '+' on line 216 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '+' on line 216 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '+' on line 216 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '+' on line 216 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 218 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '+' on line 241 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '+' on line 241 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '+' on line 241 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 255 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 258 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 260 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 319 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Error: Position on line 323 near `O A) (-1 BOS) 
(0 Gen` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 354 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 355 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 356 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 358 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 359 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 361 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 362 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 365 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 386 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 415 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '-' on line 424 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Tag '-' on line 425 looks like a set 
operator. Maybe you meant to do SET instead of LIST?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 454 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Error: Position on line 496 near `O 
PassiveParticiple)` - stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 592 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 593 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 594 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 597 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 598 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 599 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 600 after 
previous rule!
apertium-hbs-mkd.hbs-mkd.rlx: Warning: Expected closing ; on line 601 after 
previous 

Bug#868621: haskell-hashable-extras FTBFS: Ambiguous occurrence `Hashed'

[Adrian Bunk]

Source: haskell-hashable-extras
Version: 0.2.3-3
Severity: serious
Tags: buster sid

https://buildd.debian.org/status/package.php?p=haskell-hashable-extras=sid

...
Preprocessing library hashable-extras-0.2.3...
[1 of 1] Compiling Data.Hashable.Extras ( src/Data/Hashable/Extras.hs, 
dist-ghc/build/Data/Hashable/Extras.o )

src/Data/Hashable/Extras.hs:30:19: error:
Ambiguous occurrence `Hashed'
It could refer to either `Data.Hashable.Hashed',
 imported from `Data.Hashable' at 
src/Data/Hashable/Extras.hs:26:1-20
 (and originally defined in 
`hashable-1.2.6.1:Data.Hashable.Class')
  or `Data.Hashable.Extras.Hashed',
 defined at src/Data/Hashable/Extras.hs:28:1

src/Data/Hashable/Extras.hs:31:22: error:
Ambiguous occurrence `unhashed'
It could refer to either `Data.Hashable.unhashed',
 imported from `Data.Hashable' at 
src/Data/Hashable/Extras.hs:26:1-20
 (and originally defined in 
`hashable-1.2.6.1:Data.Hashable.Class')
  or `Data.Hashable.Extras.unhashed',
 defined at src/Data/Hashable/Extras.hs:28:24
/usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc-stamp' 
failed
make: *** [build-ghc-stamp] Error 1

Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts

[Sean Whitton]

Hello Paul,

On Sun, Jul 16, 2017 at 04:28:03PM -0700, Paul Hardy wrote:
> My intention was to point someone new to packaging fonts in Debian in
> the direction of an easy path, rather than leaving it up to that
> person to find things out the hard way--or worse yet, doing things the
> hard way.

Right.  It would be good to have that somewhere ...

> How about a footnote pointing to
> https://wiki.debian.org/Fonts/PackagingPolicy?  That document is not
> formal policy, but it would make life easier for someone if they are
> new to packaging fonts.
> 
> Alternatively, do you think this bug report should get reassigned to
> the New Maintainer's Guide and be addressed as a request there?  The
> scope of that guide is mainly to walk someone through creating a
> simple binary package.

... and the new maintainer's guide seems like a decent place.

How about adding a section to that guide listing links to packaging
guides for specific types of packages, such as fonts?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#868459: stretch-pu: package libquicktime/2:1.2.4-10+deb9u1

[Salvatore Bonaccorso]

Hi!

On Sun, Jul 16, 2017 at 07:16:56PM +0100, Adam D. Barratt wrote:
> On Sun, 2017-07-16 at 18:41 +0200, Moritz Mühlenhoff wrote:
> > On Sat, Jul 15, 2017 at 09:19:08PM +0100, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On Sat, 2017-07-15 at 19:12 +0200, Moritz Muehlenhoff wrote:
> > > > some minor security fixes for libquicktime, identical to what's
> > > > already in unstable and also tested with reverse deps on stretch.
> > > > 
> > > > If it's too late for 9.1, 9.2 is also just fine.
> > > 
> > > Feel free to upload, we'll see if it makes it in time.
> > 
> > Thanks, uploaded.
> 
> Unfortunately, I've had to flag the upload for rejection - it's somehow
> picked up a new dependency on "libschroedinger-1.0-0 (>= 1.0.0)", but
> that binary package is not in stretch.

Hmm, could it be the building chroot was unclean (contained jessie
packages? Because I see libschroedinger-1.0-0 only in
jessie/oldstable). I took jmm's debdiff, and rebuilded in stretch and
as well the debdiff against the resulting binary packages and those in
the archive looked okay. I thus just re-uploaded Moritz's package.

Hope that was fine (and in the interest of the fixes getting into
9.1).

Regards,
Salvatore

Bug#867694: netsurf-fb: Completely unusable

[Axel Beckert]

Control: retitle -1 netsurf-fb: Completely unusable due to missing 
dependencies, symlinks and documentation

Hi Salvo,

[another user who ran into that is writing here, not the package maintainer]

thanks for that bug report. That explains why I never got netsurf-fb
working for me either. Always thought it might have been some exotic
graphics card issue or so.

Salvo Tomaselli wrote:
> Severity: grave
> Justification: renders package unusable

While I slightly disagree with the justification, I agree with the
RC severity. I also allowed myself to make the subject a little bit
more verbose for the sake of clarity.

> https://askubuntu.com/questions/817937/how-to-run-netsurf-fb-fails-with-unable-to-set-video-could-not-set-console-s

Thanks for that link!

> But the 3rd solution did not work and my screen just gets completely black and
> I need to hard reset the machine.

I proactively symlinked /usr/share/fonts/truetype/dejavu/DejaVu*.ttf
to /usr/share/netsurf as it might depend on the website which font is
searched for.

Worked for me that way (on an Odroid XU4 running Stretch on the armhf
architecture).

> Fix these issues, or at least document how to make this thing work, add the
> necessary dependencies,

My suggestions:

* Depend on what's necessary (the link above suggests
  xserver-xorg-video-fbdev, fbset and implicitly fonts-dejavu-core)

* Add symlinks to all /usr/share/fonts/truetype/dejavu/DejaVu*.ttf
  files in fonts-dejavu-core to the netsurf-fb package.

* Document the required user groups in either
  /usr/share/doc/netsurf-fb/README.Debian (not yet existing) or maybe
  even (in addition to README.Debian) also in the package description.

> or remove this package.

Please don't. It fills a rather unique niche.

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