Bug#797874: /bin/machinectl: cannot import images on non-btrfs file system

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2016-12-17 at 00:12 +0100, Michael Biebl wrote:
> > rrs@chutzpah:~$ sudo machinectl import-tar /var/tmp/fedora-container.tar.gz
> fedora-template
> > Failed transfer image: /var/lib/machines is not a btrfs file system.
> Operation is not supported on legacy file systems.
> > 13:58 â™’â™’â™’    ☹  => 1  
> 
> Is that still an issue on an up-to-date sid/stretch system?
> If so, we should take this upstream.

I haven't tried again. These were machined bugs I filed initially, when
exploring systemd for container management. But later, I moved to the btrfs
based loopback setup that systemd prefers.

That said, some of the bugs I'd filed, were fixed by upstream. So, this issue
may be fixed now.

https://github.com/systemd/systemd/issues/1308

and then someone filed this:

https://github.com/systemd/systemd/issues/1559


I think this Debian bug could be marked as done.

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhU68wACgkQpjpYo/Lh
dWl4CBAApoO5WR+M0wN8XZ/11Mmo9F/Dr+wlc8iJRtE3DhPafjbwKJcFnBTlasTQ
50gSuQ3UiRzzdrN6uJ1pX+6A6ePZiqqkhiVPbCS+OmExXsdNyLN3mdAjBQK3EafZ
H2Du8Unzi0EsbzMQHn5xg2OoPOgpw7Rv8/lgBZvz0nA7hKs4dS8hzIaXEm37DaL+
77pYClf0QK5Sf4JIW48Bbit8HKC3YIa4JujRN4kTskiHu/kg9PAV5qPKardeSrnv
9DNpBlLy52QgqTXN3JuwyreBIuUTgNZkZ+Vhj9KVo9hQioiV+89oWePxYJhqV5TH
acCfnlyXUIfRuIl7gOiUSf+riGWgCe+5RON3OG1ShNJIYiRtjis02V/5KkvK/4aT
dp4R2kY+E4HhZiifTB7E+TKKVd0ym0gElgH1pomFwyc0bvAMimuzmTpVCDOdF5fI
6ytLgcc7OFfN5j3+9kVVl/j85VUCzaq4bM6N/zo4306oPnATyUWe7Tw+nABSrRoX
ieuvZIqRdiH9NyIghdrtKCj/mMQhSi/D0yKCzgRDyXY9fXXswioHs4f4lL9ZSGqt
3XNQxVPD77FymkWJb9+aMh07PwwuIjTWHtVgTRHY2TxZtdJLnOSRpH8mxJ1zj7AH
5mgC5qe55rZNpjZQiiHRvYBk+Y9V/seUQqq+afqcbztWOZENIW0=
=tNv6
-END PGP SIGNATURE-

Bug#848312: approx: Approx fails to work at all

[Russel Winder]

Hi,

> # systemctl enable approx.socket
> # systemctl start approx.socket

Aha, splendid. This works fine. I tried tinkering with the approx@
template service but didn't have a clue what I was doing and got
nowhere. I didn't think to start the approx.socket. Silly me. Thanks
for spotting this, I am now back in sensible update business.

Now to find a sensible replacement for the removed approx-gc…

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Bug#848188: python-coverage: jquery.hotkeys.js from upstream is not packaged

[Ben Finney]

On 15-Dec-2016, Loic Dachary wrote:

> On 12/15/2016 11:09 AM, Ben Finney wrote:

> > So we'll need to seek another solution. I think correct solutions
> > would include:
> > 
> > * Remove the dependency. If the state of that code is as bad as
> >   you say, this would be a good option; I hope we'll find that
> >   it's not as dire as you portray above.
> > 
> > * Make the dependency optional. This is recorded in the
> >   Coverage.py issue tracker 
> > https://bitbucket.org/ned/coveragepy/issues/279/>.
> > 
> > * Bring Coverage.py forward to use the latest API for
> >   ‘jquery.hotkeys’.
> > 
> > There may be other options. What are your thoughts?
> 
> The better option would be to have automated tests verifying the
> differences between the upstream files and the dependencies do not
> introduce regressions or behavior changes.

That's a good suggestion.

Even with that, though, we would still have no resolution to the bug
you've reported. Can you speak to what resolution you expect? One of
the ones I listed above, or something else?

-- 
 \  “Holy polar ice sheet, Batman!” —Robin |
  `\   |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#848339: missing fake_dsa symbol makes reverse dependencies FTBFS

[Helmut Grohne]

severity 848339 serious
reassign 848339 libunbound2
affects 848339 + src:gnutls28
user helm...@debian.org
usertags 848339 + rebootstrap
thanks

This bug makes gnutls28 fail to build from source (it detects unbound as
missing and fails installing its dane components). Raising severity to
prevent testing migration and warn others.

Helmut

Bug#840673: pkg_resources: ‘load_entry_point’ crashes without Setuptools

[Ben Finney]

On 15-Dec-2016, Matthias Klose wrote:
> In the past we needed that [split into ‘python-pkg-resources’ and
> ‘python-setuptools’ binary packages] to be able to build packages
> without setuptools but using pkg_resources.

Yes, that's exactly my purpose for depending on
‘python-pkg-resources’. What are you saying has changed? As far as I
can tell there is still the need to have ‘pkg_resources’ available
separately.

The ‘dh-python’ suite is currently detecting dependencies from the
Distutils information; the binary package has only “${python:Depends}”
which is then populated automatically. Is this perhaps a bug in that
detection? What should I describe to the ‘dh-python’ maintainer?

-- 
 \ “If you're a horse, and someone gets on you, and falls off, and |
  `\  then gets right back on you, I think you should buck him off |
_o__)right away.” —Jack Handey |
Ben Finney 


signature.asc
Description: PGP signature

Bug#848392: python-bottle: CVE-2016-9964: redirect() doesn't filter "\r\n" which allows for CRLF attack

[Salvatore Bonaccorso]

Source: python-bottle
Version: 0.12.7-1
Severity: important
Tags: security upstream patch
Forwarded: https://github.com/bottlepy/bottle/issues/913

[apologies if this arrives doubled, will merge the two in case yes]

Hi,

the following vulnerability was published for python-bottle.

CVE-2016-9964[0]:
redirect() doesn't filter "\r\n" which allows for CRLF attack

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9964
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9964
[1] https://github.com/bottlepy/bottle/issues/913
[2] 
https://github.com/bottlepy/bottle/commit/6d7e13da0f998820800ecb3fe9ccee4189aefb54

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#848391: dgit: can't import glibc 2.23-1

[Peter Green]

Package: dgit
version: 2.11

I tried importing glibc 2.23-1 into git using dgit (as part of a project 
to import packages that we modify). Unfortunately it failed. The output 
below is from testing in an amd64 sid chroot


nobody@debian:/nobody$ dget -d 
http://snapshot.debian.org/archive/debian/20160704T045211Z/pool/main/g/glibc/glibc_2.23-1.dsc

<--snip-->
nobody@debian:/nobody$ mkdir testrepo
nobody@debian:/nobody/testrepo$ git init
Initialized empty Git repository in /nobody/testrepo/.git/
nobody@debian:/nobody/testrepo$ dgit import-dsc ../glibc_2.23-1.dsc 
+testbranch

using existing glibc_2.23.orig.tar.xz
using existing glibc_2.23-1.debian.tar.xz
dpkg-source: info: extracting glibc in glibc-2.23
dpkg-source: info: unpacking glibc_2.23.orig.tar.xz
dpkg-source: info: unpacking glibc_2.23-1.debian.tar.xz
dpkg-source: warning: diff 
'glibc-2.23/debian/patches/hurd-i386/cvs-IPV6_PKTINFO.diff' patches file 
glibc-2.23/bits/in.h more than once

warning: gbp pq import failed: subprocess failed with error exit status 1
dgit: trying slow absurd-git-apply...
gbp:warning: Patch 'git-updates.diff' has no authorship information, 
using 'GNU Libc Maintainers '

<--snip-->
gbp:warning: Patch cvs-IPV6_PKTINFO.diff failed to apply, retrying with 
whitespace fixup
gbp:error: Failed to apply 
'/nobody/testrepo/.git/dgit/unpack/glibc-2.23/debian/patches/hurd-i386/cvs-IPV6_PKTINFO.diff': 
Error running git apply: DGIT ABSURD GIT APPLY - NO BYPASS: apply 
--index --whitespace=fix 
/nobody/testrepo/.git/dgit/unpack/glibc-2.23/debian/patches/hurd-i386/cvs-IPV6_PKTINFO.diff
DGIT ABSURD GIT APPLY - FAILED: UNKNOWN OPTION --whitespace=fix (apply 
--index --whitespace=fix 
/nobody/testrepo/.git/dgit/unpack/glibc-2.23/debian/patches/hurd-i386/cvs-IPV6_PKTINFO.diff)


gbp:error: Couldn't apply patches
gbp pq import failed: subprocess failed with error exit status 1
nobody@debian:/nobody/testrepo$

Any thoughts on how to debug this?

Bug#514704: Not a bug

[Jason Downs]

Hi,

This was recently brought to my attention.

I would point out that neither of these are actually bugs.

First, the unconditional fsync() was intentional behavior.  At worst, it's a 
NOP as the file will likely be flushed momentarily anyway.

Secondly, the gdbm_close() function is meant to approximate the behavior of the 
dbm_close() function, which is specified in the standards as a void function.  
Hence, there's no reason to check return values.

Bug#848240: missing documentation: password? shell?

[Dmitry Bogatov]

control: tag -1 +moreinfo

[2016-12-15 09:16] Antoine Beaupré 
>
> part   text/plain1572
> Package: dh-sysuser
> Version: 1.3
> Severity: wishlist
>
> It would be great to have more documentation about how this package
> works. I tried looking at the homepage, which is just the git
> repository and couldn't find anything.
>
> It's only when I installed the package that i noticed the
> dh_sysuser(1) manpage. But then it seems a bit short and only yields
> more questions:
>
>  1. are users created with adduser? are dependencies injected
> properly?
>  2. how are they created? what is the password? '*'? what about the
> shell?
>  3. is a group created? if not, what group is the user part of?
>  4. what are the permissions of the home directory? in my use case, it
> should be 750 - should i be handling this myself? how do i know
> what home directory was used if i don't specify it?

Why all this is significant? User is created by `adduser' with all
defaults, except homepage (optional), because it is only needed for
`su _foo_user /some/scary/programm'.

> For example, I would recommend mentionning that most of the work is
> done by the sysuser-helper binary.

It is implementation detail.

> I would also mention the special way /nonexistent is handled and add
> an EXAMPLES section for quick copy-pasting.

Can you provide snippet? Or, better, patch?

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgp1Uft6njGax.pgp
Description: PGP signature

Bug#848239: deluser on purge

[Dmitry Bogatov]

control: tag -1 +moreinfo

[2016-12-15 09:07] Antoine Beaupré 
>
> part   text/plain1199
> Package: dh-sysuser
> Version: 1.3
> Severity: wishlist
>
> I think that, under certain circumstances, users should be completely
> removed along with their $HOME directory when the package is purged.

See #840469 for discussion, why deleting $HOME is troublesome. If you
can propose principled solution -- it would be great. In short:

 - postrm has access only to essential tools

 - What if there is something valuable is in $HOME? What if sysadmin
   made some obscure thing, link `ln -sf / $HOME'?

 - What do to with files outside of of $HOME?

 - What about uid sharing? I install torrent client, purge it (files
   must stay, you know). Now I install webserver, and it owns my
   downloaded files. Wrong.

For now dh-sysuser does not pretend to do something big.  You just
create user, optionally with home directory and run some server with
this user. Shell, password, ... are irrelevant.

I am okay with making it one-stop solution, but I do not know how to
achive it.

--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpQG4JYQxvrK.pgp
Description: PGP signature

Bug#812613: O: dmalloc -- debug memory allocation library

[Carlos Maddela]

Package: wnpp
Followup-For: Bug #812613

Control: retitle -1 ITA: dmalloc -- debug memory allocation library
Control: owner -1 !

I intend to adopt this package.

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Raphaël Halimi]

Hi Andreas Henriksson,

Le 14/12/2016 à 08:21, Andreas Henriksson a écrit :
> Congrats on completely derailing a thread that for once was about
> proper mainenance and solving a bigger problem into becoming
> about your pet peeve. Please feel free to stop CCing me if you
> don't actually want my feedback.

That wasn't my intention at all. I was sincerely happy to see some
growing activity in the maintenance of NFS packages and I seized this
opportunity to point out a trivial patch rotting for one year in the BTS
that could fix two separate bugs, and allow to effectively close them.
In other words, I was *trying to help*.

On the contrary, it's you who, as usual, treated people who don't use
systemd with utter contempt, by suggesting to close both bugs as
wontfix, and by doing so, transformed part of this thread in a potential
mini-flamewar. Or maybe it is a personal vendetta against me about our
previous quarrel in #773915 ? Frankly, I don't care, but I'd like to say
that I just contribute to Debian in the hope that it (and its
derivatives) will work out-of-the-box for most people, but it seems to
me that you want Debian to work exclusively for systemd and GNOME users,
purposefully brushing aside other people's efforts in the opposite
direction.

Now for the technical side of the problem:

>> Since it's so easy to override
>> these settings with systemd (I'm not ironical here, I really don't know
>> how it's done), what harm would this patch do if it was applied to
>> satisfy sysvinit users ?
> 
> If you think it's about making it easy to do it in multiple separate
> ways, then you don't understand the problem. You want exactly
> *one* way to do it that's supported by all, so we can continue
> keeping that one way working and avoid incompatible upgrades.

Exactly, and AFAIK /etc/default snippets *are* this universal way. How
else would you do it for it to work with both systemd and sysvinit ?

Besides, rpcbind already uses this mechanism through
/lib/systemd/system/rpcbind.service (line
"EnvironmentFile=-/etc/default/rpcbind"). Why would it be such a bad
idea for nfs-utils ?

> You know Debian cares alot about integration and easy upgrades, right?

Please stop being condescending. I use Debian since 1998 so yes, I know
that, but "caring about easy upgrades" does not mean "leave bugs unfixed
just to avoid a conffile prompt during upgrades".

>> They would have at last the possibility of modifying rpcnfsdopts through
>> /etc/default/nfs-kernel-server, and thus reliably disable nfsv4, and
>> systemd users could still do the same through whatever facility systemd
>> provides and that I'm not aware of.
> 
> You already have this option. These files are conffiles. Please read
> up on what that means (in policy for example).

I know what a conffile means in the Debian jargon, and I'm perfectly
fine with modifying them, except for init scripts. When the maintainer
changes an init script, reconciling the differences with local
modifications is both cumbersome and error-prone, and I do my best to
avoid that.

> Maybe also think a bit about why making incompatible changes to
> conffiles and shipping new versions of them in a package is something
> you want to avoid as a maintainer, and why a user don't want a
> maintainer to do that either.

Please explain exactly in what way would my patch introduce
*incompatible* changes. It's *trivial*, it only adds a single option,
and a comment to hint that NFSv4 must be disabled in rpc.nfsd in
addition of rpc.mountd. Why do you deem this change as "incompatible" ?
Just because of a single conffile prompt that would affect a minority of
users ?

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#847482: qt5t not to be expected for stretch

[Lisandro Damián Nicanor Pérez Meyer]

¡Hola Marga!

On viernes, 16 de diciembre de 2016 18:18:09 ART Margarita Manterola wrote:
> Hola Dmitry Shachnev!
> 
> > > With respect to the patch, isn't there a way to use the gtk plugin
> > > instead?
> > 
> > That patch exports QT_QPA_PLATFORMTHEME=qt5ct. Instead of that, export
> > QT_QPA_PLATFORMTHEME=gtk2 (and depend on qt5-style-plugins >=
> > 5.0.0+git16).
> > This would be (almost) identical to Qt 5.6 default experience.
> 
> Cinnamon is a GTK based desktop environment.  Adding a dependency on
> qt5-style-plugins makes no sense to me.
>
> Is there some other way that we can fix the behavior for QT apps, without
> adding dependencies that make no sense for people that don't use QT?

No, there is not. This is the same situation as when a KDE user wants their 
GTK apps looking like Qt ones, they need to install a GTK theme with their GTK 
dependencies, like gtk2-engines-qtcurve.

Simple suggestion: do not depend on qt5-style-plugins but suggest/recommend 
it. If users ask, point them to install it.

Cheers, Lisandro.

-- 
If you realize that you are in a hole... stop digging.
  Anonimous, thanks to ScottK.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#848390: ITP: libmetacpan-client-perl -- MetaCPAN API client

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmetacpan-client-perl
  Version : 2.002000
  Upstream Author : Sawyer X , Mickey Nasriachi 

* URL : https://metacpan.org/release/MetaCPAN-Client
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : MetaCPAN API client

MetaCPAN::Client is a hopefully-complete API-compliant client to MetaCPAN
(https://metacpan.org) with DWIM capabilities, to make your life easier.

This module has three purposes:

 * Provide 100% of the MetaCPAN API
 * Be lightweight, to allow flexible usage
 * DWIM

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Bug#848389: derby: Fails to build from source

[Jeremy Bicha]

Package: derby
Version: 10.13.1.1-1
Severity: serious

derby fails to build from source. It looks to me like it's failing
because it's trying to connect to an external website and fails when
it can't load the URL.

I recommend doing a source-only upload next time to detect these issues sooner.

https://wiki.debian.org/SourceOnlyUpload

Build log excerpt below. You can see the full build log at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/derby.html
Click rbuild on the left sidebar.

install_packagelists:
[mkdir] Created dir: /<>/packageListLoc-se-8
[mkdir] Created dir: /<>/packageListLoc-j2ee-7
  [get] Getting: http://docs.oracle.com/javase/8/docs/api/package-list
  [get] To: /<>/packageListLoc-se-8/package-list
  [get] Error getting
http://docs.oracle.com/javase/8/docs/api/package-list to
/<>/packageListLoc-se-8/package-list

BUILD FAILED
/<>/build.xml:948: The following error occurred while
executing this line:
/<>/build.xml:976: java.net.UnknownHostException: docs.oracle.com
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.(HttpClient.java:211)
at sun.net.www.http.HttpClient.New(HttpClient.java:308)
at 
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1209)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1157)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1032)
at 
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:966)
at org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:728)
at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:641)
at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:631)

Thanks,
Jeremy Bicha

Bug#848181: initramfs-tools-core: support mounting of more complex setups

[Ben Hutchings]

On Sat, 2016-12-17 at 02:06 +0100, Tobias Schlemmer wrote:
> Am 15.12.2016 um 21:03 schrieb Ben Hutchings:
> > On Thu, 2016-12-15 at 20:15 +0100, Tobias Schlemmer wrote:
> > > Hi Ben,
> > > 
> > > Am 14.12.2016 um 23:51 schrieb Ben Hutchings:
> > > > Control: tag -1 wontfix
> > > > 
> > > > This code is broken in several ways,
> > > 
> > > For me it would be interesting to know about them. So I could improve my
> > > skills.
> > 
> > For one, it has dependencies on scripts in /root on the root
> > filesystem.
> 
> Actually, it does not. functions.ts and local.ts are patched copies
> /scripts/functions and /scripts/local, which I keep in /root for
> development purposes, only.

That's what I thought.

> Both patches have been provided.

But not in a state which would ever be suitable for applying to a
package.

> > [...]
> > > Otherwise I expect that there will be many more bug reports and
> > > complaints about initramfs in particular, Debian at medium level and the
> > > unpredictability of Linux configuration in the future.
> > 
> > There has been one other bug report so far (#781656).
> 
> You probably have not noticed #847119. It is not obvious, that the
> problem is caused by initramfs ignoring the mount order of fstab. So you
> are probably not informed about all bug reports regarding this problem.

I think I can rely on the systemd maintainers to reassign such bugs.

> >  The lack of
> > support for bind-mounting /usr (which I hadn't previously considered)
> > was then documented in initramfs-tools NEWS and the release notes for
> > jessie.
> 
> Sorry that does not help when I have to decide whether to install an
> package or not, especially when there are more than 1000 packages to
> upgrade. This information is available only after installing the
> upgrade. This means, when the system is already unbootable.

The release notes are available before a system upgrade.  If you have
apt-listchanges installed (it's installed by default) then NEWS will
be presented at a point when you can still abort the upgrade.

> >> I think the 2nd approach will be the easiest to implement: replace
> >> “mountfs /usr“ by “for fs in $EARLYMOUNTFS ; do mountfs "$fs"; done“ but
> >> it may still lead to confusion while upgrading Debian. I'm using Debian
> >> for more than 15 years, now, and, until recently, I had never a major
> >> Debian release that rendered my system unbootable. People don't expect 
> >> that.
> > 
> > I'm sorry, but you can't claim you weren't warned about this.
>
> I can't remember of beeing warned when I installed the upgrade. In fact
> I was surprised that the init systems depend on having /usr being
> available before mounting the file systems.

I suspect that you missed this during the upgrade to jessie, but things
just happened to work (with systemd mounting /usr later) until now.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.



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

Bug#848312: approx: Approx fails to work at all

[Eric Cooper]

> Approx used to work fine on this server. At some point a few weeks ago it 
> simply stopped working. I am
> guessing it was an upgrade to of approx (5.7 from 5.4?) or some change in the 
> systemd configuration at the
> same time that caused the problem. However I was not able to investigate at 
> the time, I just had to switch
> all the machines to individual working rather than using the approx system.
>
> I have just retried and there is no approx service registered and no access 
> to port  on the server.

Can you try installing the openbsd-inetd package (and if there is no
/etc/inetd.conf, or no entry for approx in that file, please purge and
reinstall the approx package)?  Please let me know if that solves the
problem for you.

I think the problem is that this version no longer depends on
inet-superserver; there was a patch to include systemd support that
was supposed to make it unnecessary, but evidently that doesn't work correctly.

--
Eric Cooper e c c @ c m u . e d u

Bug#848312: approx: Approx fails to work at all

[Eric Cooper]

It looks like openbsd-inetd is not needed and the systemd support does
work, but it's not being enabled and started by default.  I think all
that's required is:

# systemctl enable approx.socket
# systemctl start approx.socket

I don't know why that isn't done automatically, since I don't know
much about systemd, but I'll look into it.

--
Eric Cooper e c c @ c m u . e d u

Bug#848388: /usr/bin/plasmashell: plasmashell - panel freezes, sometimes unstuck by switching to vt1 then vt7

[Arthur Marsh]

Package: plasma-workspace
Version: 4:5.8.4-1
Severity: normal
File: /usr/bin/plasmashell

Dear Maintainer,

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

   * What led up to the situation?

Some unknown upgrade, but this problem has persisted through several upgrades.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Panel time often freezes, and also sometimes windows of applications
(eg firefox, chromium, mpv, konsole). Sometimes they can be unstuck by
switching virtual terminals e.g. to vt1 then back to vt7.

gdb trace when panel clock froze:

am64:/mnt/homes/amarsh04# ps -ef|grep plasma
amarsh04 18237  4363  2 12:51 pts/300:00:05 plasmashell
root 21018 21012  0 12:56 pts/400:00:00 grep plasma
am64:/mnt/homes/amarsh04# gdb -p 18237
GNU gdb (Debian 7.12-3) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 18237
[New LWP 18238]
[New LWP 18239]
[New LWP 18241]
[New LWP 18395]
[New LWP 18418]
[New LWP 18426]
[New LWP 18603]
[New LWP 18604]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f0387f6456d in poll () at ../sysdeps/unix/syscall-template.S:84
84  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x7f0387f6456d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7f038c02b150 in poll (__timeout=-1, __nfds=1, __fds=0x7ffdd3e8d730)
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  0x7f038c02b150 in _xcb_conn_wait (c=c@entry=0x555c596d5370, 
cond=cond@entry=0x7ffdd3e8d850, vector=vector@entry=0x0, count=count@entry=0x0)
at ../../src/xcb_conn.c:479
#3  0x7f038c02cc0f in wait_for_reply (c=c@entry=0x555c596d5370, 
request=request@entry=2821, e=e@entry=0x7ffdd3e8d920) at ../../src/xcb_in.c:516
#4  0x7f038c02cd81 in xcb_wait_for_reply64 (c=0x555c596d5370, request=2821, 
e=0x7ffdd3e8d920) at ../../src/xcb_in.c:560
#5  0x7f038c28a018 in _XReply () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x7f0384ad38da in  () at /usr/lib/x86_64-linux-gnu/libGL.so.1
#7  0x7f0384ad3c37 in  () at /usr/lib/x86_64-linux-gnu/libGL.so.1
#8  0x7f02df5bc54d in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#9  0x7f02df5b6a14 in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#10 0x7f02df4a35d4 in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#11 0x7f02df4a454c in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#12 0x7f02df4501cb in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#13 0x7f02df458e54 in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#14 0x7f038b89a93a in QSGBatchRenderer::Renderer::renderBatches() ()
at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#15 0x7f038b8a0205 in QSGBatchRenderer::Renderer::render() ()
at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#16 0x7f038b8abb2f in QSGRenderer::renderScene(QSGBindable const&) ()
---Type  to continue, or q  to quit---
at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#17 0x7f038b8ac1fb in QSGRenderer::renderScene(unsigned int) ()
at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#18 0x7f038b8bbe9e in QSGRenderContext::renderNextFrame(QSGRenderer*, 
unsigned int) () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#19 0x7f038b90575e in QQuickWindowPrivate::renderSceneGraph(QSize const&) 
() at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#20 0x7f038b8d2995 in  () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#21 0x7f038b910206 in QQuickWindow::event(QEvent*) ()
at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#22 0x555c578869ab in  ()
#23 0x7f0389106b2c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#24 0x7f038910e2e1 in QApplication::notify(QObject*, QEvent*) ()
at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#25 0x7f03888238f0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#26 0x7f0388b7760e in QWindowPrivate::deliverUpdateRequest() ()
at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#27 0x7f0388b77b59 in QWindow::event(QEvent*) ()
at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#28 0x7f038b9101a5 in QQuickWindow::event(QEvent*) ()
at /usr/lib/x86_64-linux-gnu/libQt5Quick

Bug#848246: sympow does not works properly when HOME is non-writable [RESOLVED]

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello SymPow enthusiasts,

this issue can be easily workaround by pointing the environment variable
SYMPOW_CACHEDIR to an existent folder. This feature was hacked in the patch
d/p/upstream-system_wide.patch [1]. Sadly, I documented it only in the patch 
header.
Second, at the time of writing this patch, I guessed that HOME is always 
existent.

I am on my way to see how this patch can be improved (and more visible).

Meanwhile, I am closing this report.

Thanks,
Jerome

[1] 
http://sources.debian.net/src/sympow/1.023-7/debian/patches/upstream-system_wide.patch/
 
- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYVJrVAAoJED+SGaZ/NsaLw+AgAJp8p8eNi8qhMF2b4OUAFv7u
vqWLbCulV3mO2s2yYV0uBAx371/RpyJBJQgJ+A9uGHIzUnBl8CJh1gjZ3Ui9pIwj
FMGs/Pz/mukI+B4ww3Edl5gHirdI9rX39SfwFna0d8AZDzQsDSbBh0AZQ5TG021r
OYt0SRmepNAenrIEt9VTPo0TcCWiWEXahC8Z3Bm1shpaHKU7ebZvmj32zchD5rSs
FaMcrkGVMG8MwuzZZR98Bgxv2S9izgkkJ7N53E35kVIr5O4W7z0LSWFfwa1RhqPM
ZtVl7SrtoeWLUyEAVbDd+Oyt47P3h18j8IslV1VqyLozU4Jxve6x4AMS0rZ7WBZL
1uiLjPCDlQY4NxiGBiTORgj4dCpAPolQTurHYlAITSg5biVPyOV/TpiyyCM7AjHW
EbW0J001FNb98F1uqWcqcvtDnPCdgsxa/NC7oXOhWO8jGQbsA34ENfu5o1J2SCpL
V2knV+tUs353m5TiFqQBe1QiYpQoJWubkYL5AjL9gLVPwPyVuTAakh6Otp7WaFlS
YynDBkTtiT3ayRo5Vj/Ux7KjY4GQ85ECdjPBwB8ejHm554cQCJVu8xpBuGJmOOMJ
lWtz1sArZ4c12+Mi/PYhN6pZ5/8zVEpseglhtj16WwCKICuHBYIHINZ/60/+zuRR
AeyROHMlsGxMF2G2dCkILctUGwhouGeoXgxOTvryXUfnGFyCBD+k6PjXAsKvd16O
l7OueHtVRUdYrqG7ROqq3LF6nKVctdnNnXH2eGVlZHVZ8H+6MrPOkJJlVpD4A4qL
fRS1RYkiSg0aJi8oJm3NPDAekSJk8eMLuvqLHKr9AdnZ5WeSR6cJ/c7mmgmSkQ7o
1vor5honoA79kYX3Ogw9+75nSdxPZaRuxivWIlm9h6EeDHF5pp7CC2QSdPaW4S/+
x8QIVjglUfLZEFSB4Izr6wbAm5EM3R+8vSnBphZh8pzDEzG0vfc0xuw4rLYgSGG8
DSjf8TzuGy9YFjCs4aRGc4b5vEw1Gg1rP9/EunMUNveRvuWAvFMh074a809oPNYt
ckZe8G6ScFR0S/vjdl/KoJFb8JIH6KyVqCWJY80mxILX0V8uLVic463u9CU1rO/I
8JHnfOTP8o2XDaVtOhUPpoPEh0wxzeY/U9GBhz4WmtR/2l3WWHXMBnkqcqF8Xemd
hs29LNkg2v91TQKfMKA3bb3pFz2lBAP5c1bUPLUA/Xjf/JSyeu8NckeoU1P+ctrE
1U9GGo9QtVJnprcx9giCC/MRgSF5rg1Zf5fp+rsi4NRizsP2RJNpm7MERnUQTdfP
SvZNpoUMoxvqk5/c6/R4+ps3sQvx6DA/lEDRoItsBWSJpXKL9p4z04AT2Vsbo4I=
=xeXB
-END PGP SIGNATURE-

Bug#848387: ITP: libsearch-elasticsearch-perl -- Perl client for Elasticsearch

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libsearch-elasticsearch-perl
  Version : 5.01
  Upstream Author : Clinton Gormley 
* URL : https://metacpan.org/release/Search-Elasticsearch
* License : Apache-2.0
  Programming Lang: Perl
  Description : Perl client for Elasticsearch

Search::Elasticsearch is the official Perl client for Elasticsearch,
supported by elasticsearch.com .

Elasticsearch itself is a flexible and powerful open source, distributed
real-time search and analytics engine for the cloud. You can read more
about it on elastic.co .

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Bug#848223: cups-browsed: IPP printer disappears after logrotate is run

[Till Kamppeter]

Note that in current cups-filters cups-browsed needs libcupsfilters, as 
the PPD generator has moved into the library to also cater for the new 
"driverless" utility.


So the instructions change as follows:

sudo apt-get build-dep cups-filters
sudo apt-get install bzr
bzr branch http://bzr.linuxfoundation.org/openprinting/cups-filters
cd cups-filters
./configure
make
sudo systemctl stop cups-browsed
sudo cp .libs/cups-browsed /usr/sbin/
sudo cp .libs/libcupsfilters.so.1.0.0 /usr/lib/x86_64-linux-gnu/
sudo systemctl start cups-browsed

   Till


On 12/16/2016 10:04 PM, Brian Potkin wrote:

On Fri 16 Dec 2016 at 21:02:34 -0200, Till Kamppeter wrote:


I have fixed the problem (at least I hope so) in the upstream BZR repository
of cups-filters (rev 7580, only file util/cups-browsed.c needed a change).

If possible, please test.


I will do so. Probably tomorrow morning.


If you are not familiar with working with source code, please tell me and I
will do the 1.13.1 release so that Didier can package it.


You have previously given instructions on this which I will use.


Do the following commands (relevant source code file is utils/cups-browsed.c
FYI):  
   > sudo apt-get build-dep cups-filters
   > sudo apt-get install bzr   
   > bzr branch 
http://bzr.linuxfoundation.org/openprinting/cups-filters   
> cd cups-filters   
> ./configure   
> make  
> sudo systemctl stop cups-browsed  
> sudo cp cups-browsed /usr/sbin/   
> sudo systemctl start 
cups-browsed


--
Brian.

Bug#843357: Pending fixes for bugs in the libdata-dumpxml-perl package

[pkg-perl-maintainers]

tag 843357 + pending
thanks

Some bugs in the libdata-dumpxml-perl package are closed in revision
a50c7d0ffdbc7fe37cefb397a1b04c3044a39c05 in branch 'master' by
Christoph Biedl

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdata-dumpxml-perl.git/commit/?id=a50c7d0

Commit message:

Take under the pkg-perl umbrella. Closes: #843357

Bug#465981: Pending fixes for bugs in the libdata-dumpxml-perl package

[pkg-perl-maintainers]

tag 817596 + pending
tag 465981 + pending
thanks

Some bugs in the libdata-dumpxml-perl package are closed in revision
b2645fa4732672f2f9dca5a5b0381177b7aedf11 in branch 'master' by
Christoph Biedl

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdata-dumpxml-perl.git/commit/?id=b2645fa

Commit message:

Packaging cleanup

* Declare compliance with policy 3.9.8
* Raise debhelper compat level to 10. Closes: #817596
* Build Architecture: all package. Closes: #465981
* Use dh7-style debian/rules
* Declare source format
* Update package description
* Re-write debian/copyright in format 1.0
* Add watch file

Bug#848386: ITP: libref-util-perl -- set of utility functions for checking references

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libref-util-perl
  Version : 0.101
  Upstream Author : Sawyer X 
* URL : https://metacpan.org/release/Ref-Util
* License : Expat
  Programming Lang: Perl
  Description : set of utility functions for checking references

Ref::Util introduces several functions to help identify references in a
faster and smarter way. In short:

 ref $foo eq 'ARRAY'
 # is now:
 is_arrayref($foo)

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Bug#848121: [Pkg-sysvinit-devel] Bug#848121: File conflict between manpages and initscripts

[Michael Biebl]

Am 16.12.2016 um 22:16 schrieb Dr. Tobias Quathamer:

> I've prepared a patch for the git repository on alioth, please review
> it. The patch should cover all places where tmpfs(5) is mentioned,
> except debian/changelog.
> 
> The package builds in a sid chroot without problems.
> 
> If everybody thinks that this change is acceptable, it would be great to
> get it into Stretch ...

lgtm, thanks Tobias


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



signature.asc
Description: OpenPGP digital signature

Bug#813658: Please enable virgl support

[johnw]

On 12/16/2016 08:05 PM, Michael Tokarev wrote:
> 16.12.2016 04:41, john wrote:
>> Package: qemu-system-x86
>> Version: 1:2.7+dfsg-3+b1
>> Followup-For: Bug #813658
>>
>> Dear Maintainer,
>>
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>>
>>  Hi, Is it possible use virgl/opengl with debian's package?
>>  (No recompile or hand make binary)
>>
>>  When I launch qemu-system-x86_64 -args  -display,gl=on
>>  (which is "man qemu-system-x86_64" say),
>>  It complain "SDL1 display code has no opengl support" issus.
>>
>>  Please make debian's qemu package support virgl/opengl, thanks.
>>
>> *** End of the template - remove these template lines ***
> John, out of curiocity, what is the reason of this your
> follow-up, why you sent it? Do you happen to know how to
> deal with the concerns outlined in this bugreport already?
>
> Thanks,
>
> /mjt
>
Hi Michael,

No, unfortunately I do not have any idea, how to deal with. :(

I send this mail, because I have this problem and want to know people
how to solve it,

So, I want to follow the bugreport, maybe someday developer will solve it.

Thanks.




signature.asc
Description: OpenPGP digital signature

Bug#848139: CVE-2016-8707 ImageMagick Convert Tiff Adobe Deflate Code Execution Vulnerability

[anarcat]

Here's a patch for wheezy, which may be useful for jessie if, like
wheezy, it lacks the ReadYCCKMethod case.


From e5fd9ab1b70b2edd06de8efb606e04482cb9a2f0 Mon Sep 17 00:00:00 2001
From: Cristy 
Date: Thu, 1 Dec 2016 20:06:50 -0500
Subject: [PATCH] Fix possible buffer overflow when writing compressed TIFFS

---
 ChangeLog |  2 ++
 coders/tiff.c | 34 +++---
 2 files changed, 21 insertions(+), 15 deletions(-)

Patch was modified to remove ReadYCCKMethod case because absent from wheezy.

--- a/ChangeLog
+++ b/ChangeLog
@@ -3,6 +3,8 @@
 
 2012-06-26  6.7.7-10 Glenn Randers-Pehrson 
   * Don't attempt to use Z_RLE compression strategy with old zlib (prior to
+  * Fix possible buffer overflow when writing compressed TIFFS (vulnerability
+report from Cisco Talos, CVE-2016-8707).
 zlib-1.2.0) that does not support it.
   * Increase PLTE chunk length to accommodate background color in indexed PNG
 (reference www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=21288).
--- a/coders/tiff.c
+++ b/coders/tiff.c
@@ -866,7 +866,7 @@ static Image *ReadTIFFImage(const ImageI
 width;
 
   unsigned char
-*pixels;
+*tiff_pixels;
 
   /*
 Open image.
@@ -1223,7 +1223,13 @@ static Image *ReadTIFFImage(const ImageI
   method=ReadTileMethod;
 quantum_info->endian=LSBEndian;
 quantum_type=RGBQuantum;
-pixels=GetQuantumPixels(quantum_info);
+tiff_pixels=(unsigned char *) AcquireMagickMemory(TIFFScanlineSize(tiff)+
+  sizeof(uint32));
+if (tiff_pixels == (unsigned char *) NULL)
+  {
+TIFFClose(tiff);
+ThrowReaderException(ResourceLimitError,"MemoryAllocationFailed");
+  }
 switch (method)
 {
   case ReadSingleSampleMethod:
@@ -1294,7 +1300,6 @@ static Image *ReadTIFFImage(const ImageI
 TIFFClose(tiff);
 ThrowReaderException(ResourceLimitError,"MemoryAllocationFailed");
   }
-pixels=GetQuantumPixels(quantum_info);
 for (y=0; y < (ssize_t) image->rows; y++)
 {
   int
@@ -1303,14 +1308,14 @@ static Image *ReadTIFFImage(const ImageI
   register PixelPacket
 *restrict q;
 
-  status=TIFFReadPixels(tiff,bits_per_sample,0,y,(char *) pixels);
+  status=TIFFReadPixels(tiff,bits_per_sample,0,y,(char *) tiff_pixels);
   if (status == -1)
 break;
   q=QueueAuthenticPixels(image,0,y,image->columns,1,exception);
   if (q == (PixelPacket *) NULL)
 break;
   length=ImportQuantumPixels(image,(CacheView *) NULL,quantum_info,
-quantum_type,pixels,exception);
+quantum_type,tiff_pixels,exception);
   (void) length;
   if (SyncAuthenticPixels(image,exception) == MagickFalse)
 break;
@@ -1352,7 +1357,6 @@ static Image *ReadTIFFImage(const ImageI
 TIFFClose(tiff);
 ThrowReaderException(ResourceLimitError,"MemoryAllocationFailed");
   }
-pixels=GetQuantumPixels(quantum_info);
 for (y=0; y < (ssize_t) image->rows; y++)
 {
   int
@@ -1361,14 +1365,14 @@ static Image *ReadTIFFImage(const ImageI
   register PixelPacket
 *restrict q;
 
-  status=TIFFReadPixels(tiff,bits_per_sample,0,y,(char *) pixels);
+  status=TIFFReadPixels(tiff,bits_per_sample,0,y,(char *) tiff_pixels);
   if (status == -1)
 break;
   q=QueueAuthenticPixels(image,0,y,image->columns,1,exception);
   if (q == (PixelPacket *) NULL)
 break;
   length=ImportQuantumPixels(image,(CacheView *) NULL,quantum_info,
-quantum_type,pixels,exception);
+quantum_type,tiff_pixels,exception);
   if (SyncAuthenticPixels(image,exception) == MagickFalse)
 break;
   if (image->previous == (Image *) NULL)
@@ -1397,7 +1401,7 @@ static Image *ReadTIFFImage(const ImageI
   status;
 
 status=TIFFReadPixels(tiff,bits_per_sample,(tsample_t) i,y,(char *)
-  pixels);
+  tiff_pixels);
 if (status == -1)
   break;
 q=GetAuthenticPixels(image,0,y,image->columns,1,exception);
@@ -1423,7 +1427,7 @@ static Image *ReadTIFFImage(const ImageI
 default: quantum_type=UndefinedQuantum; break;
   }
 length=ImportQuantumPixels(image,(CacheView *) NULL,quantum_info,
-  quantum_type,pixels,exception);
+  quantum_type,tiff_pixels,exception);
 if (SyncAuthenticPixels(image,exception) == MagickFalse)
   break;
   }
@@ -1460,13 +1464,13 @@ static Image *ReadTIFFImage(const ImageI
 break;
   if (i == 0)
 {
-  if (TIFFReadRGBAStrip(tiff,(tstrip_t) y,(uint32 *) pixels) == 0)
+  if (TIFFReadRGBAStrip(tiff,(tstrip_t) y,(uint32 *) tiff_pixels) == 0)
 break;
 

Bug#795017: ITA: pyvtk -- module for manipulating VTK files

[Pierre-Elliott Bécue]

Control: retitle -1 ITA: pyvtk -- module for manipulating VTK files

I intend to adopt this package. I did simplify the d/rules and made a new
upstream release.

Link of my repo: https://github.com/P-EB/pyvtk

Will get in touch with DPMT asap.

-- 
PEB

Bug#848181: initramfs-tools-core: support mounting of more complex setups

[Tobias Schlemmer]

Am 15.12.2016 um 21:03 schrieb Ben Hutchings:
> On Thu, 2016-12-15 at 20:15 +0100, Tobias Schlemmer wrote:
>> Hi Ben,
>>
>> Am 14.12.2016 um 23:51 schrieb Ben Hutchings:
>>> Control: tag -1 wontfix
>>>
>>> This code is broken in several ways,
>>
>> For me it would be interesting to know about them. So I could improve my
>> skills.
> 
> For one, it has dependencies on scripts in /root on the root
> filesystem.

Actually, it does not. functions.ts and local.ts are patched copies
/scripts/functions and /scripts/local, which I keep in /root for
development purposes, only. Both patches have been provided.

> [...]
>> Otherwise I expect that there will be many more bug reports and
>> complaints about initramfs in particular, Debian at medium level and the
>> unpredictability of Linux configuration in the future.
> 
> There has been one other bug report so far (#781656).

You probably have not noticed #847119. It is not obvious, that the
problem is caused by initramfs ignoring the mount order of fstab. So you
are probably not informed about all bug reports regarding this problem.

>  The lack of
> support for bind-mounting /usr (which I hadn't previously considered)
> was then documented in initramfs-tools NEWS and the release notes for
> jessie.

Sorry that does not help when I have to decide whether to install an
package or not, especially when there are more than 1000 packages to
upgrade. This information is available only after installing the
upgrade. This means, when the system is already unbootable.

>> I think the 2nd approach will be the easiest to implement: replace
>> “mountfs /usr“ by “for fs in $EARLYMOUNTFS ; do mountfs "$fs"; done“ but
>> it may still lead to confusion while upgrading Debian. I'm using Debian
>> for more than 15 years, now, and, until recently, I had never a major
>> Debian release that rendered my system unbootable. People don't expect that.
> 
> I'm sorry, but you can't claim you weren't warned about this.

I can't remember of beeing warned when I installed the upgrade. In fact
I was surprised that the init systems depend on having /usr being
available before mounting the file systems.

Regards,

Tobias



signature.asc
Description: OpenPGP digital signature

Bug#840342: [ace-of-penguins] Freecell No Longer Runs, Nvidia Legacy-304xx video driver

[Andreas Beckmann]

Hi,

I just uploaded 304.134 to sid, it should appear on the mirrors later
today. Please test it to see whether this bug is now fixed.

Thanks


Andreas

Bug#781457: ada bootstrap failure on mips and mipsel

[James Cowgill]

Control: found -1 6.2.1-6
Control: severity -1 serious
Control: tags -1 patch

Hi,

On Sun, 29 Mar 2015 17:17:03 +0200 Matthias Klose  wrote:
> Package: src:gcc-5
> Version: 5-20150327-1
> Severity: important
> Tags: sid stretch
> Forwarded: https://gcc.gnu.org/PR65618
> 
> seen building trunk 20150328. I'm not entirely sure if this is a regression.
> Apparently all distro builds for mips and mipsel set STAGE3_CFLAGS += -gtoggle
> (same as in stage2) in the past, and maybe were papering over the problem.
> 
> If this workaround is really needed, we should limit the comparision failure 
> to
> exactly the one failing file.
> 
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> Bootstrap comparison failure!
> gcc/ada/a-except.o differs
> Makefile:22697: recipe for target 'compare' failed
> make[4]: *** [compare] Error 1

Given that you reverted the workaround for this, I assume that you
consider this bug RC for stretch? I note that this isn't a recent issue
- the workaround was shipped in both wheezy and jessie.

I attach the patch I posted to the upstream bug report. I am going to
submit it properly once I do a few extra tests (I'm fairly confident
about it, but it won't be done until next week). I'm also planning on
upstreaming ada-mips.diff with a few tweaks simplify it a bit.

Thanks,
James
--- a/gcc/emit-rtl.c	
+++ a/gcc/emit-rtl.c	
@@ -3742,6 +3742,11 @@ try_split (rtx pat, rtx_insn *trial, int last)
 		   next = NEXT_INSN (next))
 		if (NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
 		  {
+		/* Advance after to the next instruction if it is about to
+		   be removed */
+		if (after == next)
+		  after = NEXT_INSN(after);
+
 		remove_insn (next);
 		add_insn_after (next, insn, NULL);
 		break;


signature.asc
Description: OpenPGP digital signature

Bug#848223: cups-browsed: IPP printer disappears after logrotate is run

[Brian Potkin]

On Fri 16 Dec 2016 at 21:02:34 -0200, Till Kamppeter wrote:

> I have fixed the problem (at least I hope so) in the upstream BZR repository
> of cups-filters (rev 7580, only file util/cups-browsed.c needed a change).
> 
> If possible, please test.

I will do so. Probably tomorrow morning.

> If you are not familiar with working with source code, please tell me and I
> will do the 1.13.1 release so that Didier can package it.

You have previously given instructions on this which I will use.

> Do the following commands (relevant source code file is utils/cups-browsed.c
> FYI): 
> > sudo apt-get build-dep cups-filters 
>   
> > sudo apt-get install bzr
>   > bzr branch 
> http://bzr.linuxfoundation.org/openprinting/cups-filters  
>  > cd cups-filters
>> 
> ./configure   
> > make
>   
> > sudo systemctl stop cups-browsed
>   > sudo cp cups-browsed 
> /usr/sbin/
>> sudo systemctl start cups-browsed

--
Brian.

Bug#848384: RFS: xmacro/0.3pre-20000911-7 [ITA]

[Vincent Carluer]

Package: sponsorship-requests
Severity: serious

Dear mentors,

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

* Package name: xmacro
   Version : 0.3pre-2911-7
   Upstream Author : Gabor Keresztfalvi 
 * URL :  https://sourceforge.net/projects/xmacro/
 * License : GPLv2
   Section : utils

It builds those binary packages:

xmacro - Record / Play keystrokes and mouse movements in X displays

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/x/xmacro/xmacro_0.3pre-2911-7.dsc

Changes since the last upload:
  * Fixing build failure with GCC-6 via rearanging the header order
patch by Eduard Bloch
(closes: #831195)
  * Change compat and control to debhelper 9, Standards-Version to 3.9.8
  * Change dh_clean -k to dh-prep
  * Move patch format to full 3.0 (quilt) without global .diff.gz
  * New maintainer for package: Vincent Carluer (closes: #832150)


This is my first packaging :D

Regards,

Vincent Carluer

Bug#848383: Installation: i915 - Oh no! Something has gone wrong

[Lou Poppler]

Package: installation-reports

Boot method:  CD
Image version: 
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/8.6.0+nonfree/i386/bt-cd/firmware-8.6.0-i386-netinst.iso.torrent
Date: Dec 13, 2016  17:00 UTC

Machine: Uniwill 223ii0
Processor: CPU: Intel(R) Pentium(R) M processor 2.00GHz (fam: 06, model: 0d, 
stepping: 06)
Memory:  500 MB
Partitions: 
/dev/sda1  * 2048 115181567 115179520 54.9G 83 Linux
/dev/sda2   115183614 117209087   2025474  989M  5 Extended
/dev/sda5   115183616 117209087   2025472  989M 82 Linux swap / Solaris

Output of lspci -knn (or lspci -nn):
root@hermes:/home/lwp#   lspci -knn
00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to I/O Controller [8086:3580] (rev 02)
Subsystem: Uniwill Computer Corp Device [1584:9022]
Kernel driver in use: agpgart-intel
00:00.1 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to I/O Controller [8086:3584] (rev 02)
Subsystem: Uniwill Computer Corp Device [1584:9022]
00:00.3 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to I/O Controller [8086:3585] (rev 02)
Subsystem: Uniwill Computer Corp Device [1584:9022]
00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM 
Integrated Graphics Device [8086:3582] (rev 02)
Subsystem: Uniwill Computer Corp Device [1584:9500]
00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated 
Graphics Device [8086:3582] (rev 02)
Subsystem: Uniwill Computer Corp Device [1584:9500]
00:1d.0 USB controller [0c03]: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 03)
Subsystem: Uniwill Computer Corp Device [1584:9022]
Kernel driver in use: uhci_hcd
00:1d.1 USB controller [0c03]: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 03)
Subsystem: Uniwill Computer Corp Device [1584:9022]
Kernel driver in use: uhci_hcd
00:1d.2 USB controller [0c03]: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 03)
Subsystem: Uniwill Computer Corp Device [1584:9022]
Kernel driver in use: uhci_hcd
00:1d.7 USB controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 
EHCI Controller [8086:24cd] (rev 03)
Subsystem: Uniwill Computer Corp Device [1584:9022]
Kernel driver in use: ehci-pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge 
[8086:2448] (rev 83)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface 
Bridge [8086:24cc] (rev 03)
Kernel driver in use: lpc_ich
00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE 
Controller [8086:24ca] (rev 03)
Subsystem: Uniwill Computer Corp Device [1584:9022]
Kernel driver in use: ata_piix
00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
SMBus Controller [8086:24c3] (rev 03)
Subsystem: Uniwill Computer Corp Device [1584:9022]
Kernel driver in use: i801_smbus
00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 03)
Subsystem: Uniwill Computer Corp Device [1584:8401]
Kernel driver in use: snd_intel8x0
00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
AC'97 Modem Controller [8086:24c6] (rev 03)
Subsystem: Uniwill Computer Corp Device [1584:4007]
Kernel driver in use: snd_intel8x0m
01:03.0 CardBus bridge [0607]: Texas Instruments PCI1410 PC card Cardbus 
Controller [104c:ac50] (rev 02)
Subsystem: Uniwill Computer Corp Device [1584:3200]
Kernel driver in use: yenta_cardbus
01:07.0 Ethernet controller [0200]: Qualcomm Atheros AR5212/AR5213 Wireless 
Network Adapter [168c:0013] (rev 01)
Subsystem: Askey Computer Corp. Device [144f:7005]
Kernel driver in use: ath5k
01:0a.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22A 
IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] [104c:8023]
Subsystem: Uniwill Computer Corp Device [1584:7000]
Kernel driver in use: firewire_ohci
01:0c.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL-8100/8101L/8139 PCI Fast Ethernet Adapter [10ec:8139] (rev 10)
Subsystem: Uniwill Computer Corp Device [1584:9700]
Kernel driver in use: 8139too

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:   

Bug#834972: [systemd] Long Shutdown Times -- Check File Systems?

[Michael Biebl]

Control: tags -1 + moreinfo

On Sun, 21 Aug 2016 10:42:58 +0300 David Baron  wrote:
> Package: systemd
> Version: 231-1
> Severity: normal
> 
> --- Please enter the report below this line. ---
> Shutdown from KDE session sometimes does not work. Have to manually sudo 
> poweroff and this plays.
> 
> Recently, things seemed to hang up exiting KDE and I sent into a console 
> session and did the sudo poweroff. Got messages "Stopping file system check"  
> before dismounting file system.

So the problem is trying to log off from KDE? Why do you expect a
systemd issue here? What exactly does hang up mean?
Do you have a journalctl -alb log


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



signature.asc
Description: OpenPGP digital signature

Bug#822564: kdump-tools: kdump location (i.e. /var/crash) does not prompt for encrypted LUKS password

[Reiner Herrmann]

Dear maintainer,

I can confirm the behavior that the bug submitter described.
After triggering a crash, it looked to me like the system is NOT
rebooting, but just hanging.
After I saw this bug, I tried it again and entered the encryption
password after the crash. I then saw the usual boot output and it
started dumping.

Kind regards,
  Reiner


signature.asc
Description: Digital signature

Bug#800309: gkrellm-radio: diff for NMU version 2.0.4-1.2

[Christoph Biedl]

Control: tags 800309 + patch
Control: tags 800309 + pending
Control: tags 817339 + patch
Control: tags 817339 + pending

Dear maintainer,

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

Regards,

Christoph

diff -u gkrellm-radio-2.0.4/debian/control gkrellm-radio-2.0.4/debian/control
--- gkrellm-radio-2.0.4/debian/control
+++ gkrellm-radio-2.0.4/debian/control
@@ -2,7 +2,7 @@
 Section: sound
 Priority: optional
 Maintainer: Sjoerd Simons 
-Build-Depends: debhelper (>> 3.0.0), liblircclient-dev, gkrellm (>= 2.0.0), 
libgtk2.0-dev
+Build-Depends: debhelper (>= 10~), liblircclient-dev, gkrellm (>= 2.0.0), 
libgtk2.0-dev
 Standards-Version: 3.5.7
 
 Package: gkrellm-radio
diff -u gkrellm-radio-2.0.4/debian/rules gkrellm-radio-2.0.4/debian/rules
--- gkrellm-radio-2.0.4/debian/rules
+++ gkrellm-radio-2.0.4/debian/rules
@@ -8,7 +8,7 @@
 #export DH_VERBOSE=1
 
 # This is the debhelper compatability version to use.
-export DH_COMPAT=3
+#export DH_COMPAT=3
 
 configure: configure-stamp
 configure-stamp:
diff -u gkrellm-radio-2.0.4/debian/changelog 
gkrellm-radio-2.0.4/debian/changelog
--- gkrellm-radio-2.0.4/debian/changelog
+++ gkrellm-radio-2.0.4/debian/changelog
@@ -1,3 +1,10 @@
+gkrellm-radio (2.0.4-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Declare debhelper compat level, bump to 10. Closes: #800309, #817339
+
+ -- Christoph Biedl   Fri, 16 Dec 2016 
23:18:39 +0100
+
 gkrellm-radio (2.0.4-1.1) unstable; urgency=low
 
   * Non maintainer upload.
only in patch2:
unchanged:
--- gkrellm-radio-2.0.4.orig/debian/compat
+++ gkrellm-radio-2.0.4/debian/compat
@@ -0,0 +1 @@
+10


signature.asc
Description: Digital signature

Bug#800297: gkrellm-mailwatch: diff for NMU version 2.4.3-1.1

[Christoph Biedl]

Control: tags 800297 + patch
Control: tags 800297 + pending

Dear maintainer,

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

Regards,

Christoph

diff -u gkrellm-mailwatch-2.4.3/debian/changelog 
gkrellm-mailwatch-2.4.3/debian/changelog
--- gkrellm-mailwatch-2.4.3/debian/changelog
+++ gkrellm-mailwatch-2.4.3/debian/changelog
@@ -1,3 +1,10 @@
+gkrellm-mailwatch (2.4.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Declare debhelper compat level, bump to 10. Closes: #800297
+
+ -- Christoph Biedl   Fri, 16 Dec 2016 
22:07:15 +0100
+
 gkrellm-mailwatch (2.4.3-1) unstable; urgency=low
 
   * New upstream release
diff -u gkrellm-mailwatch-2.4.3/debian/control 
gkrellm-mailwatch-2.4.3/debian/control
--- gkrellm-mailwatch-2.4.3/debian/control
+++ gkrellm-mailwatch-2.4.3/debian/control
@@ -1,7 +1,7 @@
 Source: gkrellm-mailwatch
 Section: mail
 Priority: optional
-Build-Depends: debhelper, gkrellm (>= 2.0.0), libgtk2.0-dev
+Build-Depends: debhelper (>= 10~), gkrellm (>= 2.0.0), libgtk2.0-dev
 Maintainer: Sjoerd Simons 
 Standards-Version: 3.1.1
 
diff -u gkrellm-mailwatch-2.4.3/debian/rules 
gkrellm-mailwatch-2.4.3/debian/rules
--- gkrellm-mailwatch-2.4.3/debian/rules
+++ gkrellm-mailwatch-2.4.3/debian/rules
@@ -6,7 +6,7 @@
 #export DH_VERBOSE=1
 
 # This is the debhelper compatability version to use.
-export DH_COMPAT=3
+#export DH_COMPAT=3
 
 
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
only in patch2:
unchanged:
--- gkrellm-mailwatch-2.4.3.orig/debian/compat
+++ gkrellm-mailwatch-2.4.3/debian/compat
@@ -0,0 +1 @@
+10


signature.asc
Description: Digital signature

Bug#800297: gkrellm-mailwatch: diff for NMU version 2.4.3-1.1

[Christoph Biedl]

Control: tags 800297 + patch
Control: tags 800297 + pending

Dear maintainer,

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

Regards,

Christoph
diff -u gkrellm-mailwatch-2.4.3/debian/changelog 
gkrellm-mailwatch-2.4.3/debian/changelog
--- gkrellm-mailwatch-2.4.3/debian/changelog
+++ gkrellm-mailwatch-2.4.3/debian/changelog
@@ -1,3 +1,10 @@
+gkrellm-mailwatch (2.4.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Declare debhelper compat level, bump to 10. Closes: #800297
+
+ -- Christoph Biedl   Fri, 16 Dec 2016 
22:07:15 +0100
+
 gkrellm-mailwatch (2.4.3-1) unstable; urgency=low
 
   * New upstream release
diff -u gkrellm-mailwatch-2.4.3/debian/control 
gkrellm-mailwatch-2.4.3/debian/control
--- gkrellm-mailwatch-2.4.3/debian/control
+++ gkrellm-mailwatch-2.4.3/debian/control
@@ -1,7 +1,7 @@
 Source: gkrellm-mailwatch
 Section: mail
 Priority: optional
-Build-Depends: debhelper, gkrellm (>= 2.0.0), libgtk2.0-dev
+Build-Depends: debhelper (>= 10~), gkrellm (>= 2.0.0), libgtk2.0-dev
 Maintainer: Sjoerd Simons 
 Standards-Version: 3.1.1
 
diff -u gkrellm-mailwatch-2.4.3/debian/rules 
gkrellm-mailwatch-2.4.3/debian/rules
--- gkrellm-mailwatch-2.4.3/debian/rules
+++ gkrellm-mailwatch-2.4.3/debian/rules
@@ -6,7 +6,7 @@
 #export DH_VERBOSE=1
 
 # This is the debhelper compatability version to use.
-export DH_COMPAT=3
+#export DH_COMPAT=3
 
 
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
only in patch2:
unchanged:
--- gkrellm-mailwatch-2.4.3.orig/debian/compat
+++ gkrellm-mailwatch-2.4.3/debian/compat
@@ -0,0 +1 @@
+10


signature.asc
Description: Digital signature

Bug#847812: pysolfc: crash on startup

[Markus Koschany]

Control: severity -1 grave
Control: tags -1 - unreproducible

On 15.12.2016 23:36, Markus Koschany wrote:
[...]
> Hello,
> 
> pysolfc works fine in Debian testing. There is no startup error on my
> system.

My apologies. I missed that you are using the i386 version of pysolfc.
Indeed I can reproduce the error on this platform but it is most likely
related to one of pysolfc's dependencies. This needs more investigation.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#797874: /bin/machinectl: cannot import images on non-btrfs file system

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Ritesh!

On Thu, 03 Sep 2015 14:08:02 +0530 Ritesh Raj Sarraf  wrote:
> Package: systemd-container
> Version: 225-1
> Severity: normal
> File: /bin/machinectl
> 
> This one is an odd behavior. I export my container image, and the same
> is not allowed to be imported.
> 
> 
> 
> rrs@chutzpah:/var/lib/lxc$ sudo machinectl export-tar fed-test 
> /var/tmp/fedora-container.tar.gz
> Enqueued transfer job 1. Press C-c to continue download in background.
> Exporting '/var/lib/machines/fed-test', saving to 
> '/var/tmp/fedora-container.tar.gz' with compression 'gzip'.
> Operation completed successfully.
> Exiting.
> 13:51 ♒♒♒   ☺
> 
> 
> 
> 
> rrs@chutzpah:~$ sudo machinectl import-tar /var/tmp/fedora-container.tar.gz 
> fedora-template
> Failed transfer image: /var/lib/machines is not a btrfs file system. 
> Operation is not supported on legacy file systems.
> 13:58 ♒♒♒☹  => 1  

Is that still an issue on an up-to-date sid/stretch system?
If so, we should take this upstream.

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



signature.asc
Description: OpenPGP digital signature

Bug#844789: [Debian-science-sagemath] GAP: issue related to compressed manual.six: PATCHES: reproducing issue

[Ximin Luo]

Jerome BENOIT:
> Hello Again,
> 
> On 14/12/16 23:19, Jerome BENOIT wrote:
>> Thanks for the patch. I am on my way to build the involved package
>> for the repository deb-sci-deb .
> 
>> Jerome
> 
>> On 14/12/16 19:46, Bill Allombert wrote:
>>> On Mon, Dec 12, 2016 at 10:19:18PM +0100, Bill Allombert wrote:
 On Mon, Dec 12, 2016 at 06:06:37PM +0100, Bill Allombert wrote:
> On Sun, Dec 11, 2016 at 11:15:00PM +, Ximin Luo wrote:
>> Did you remove test.w before trying the tests? I think it is still
>> somehow autpgrp-related. Also the "corrupted" messages seem to be
>> separate from the actual failure of "no method found":
>
> I agree with you. But the "corrupted" messages are still a bug even
> if they do not affect Sage.

 I can reproduce this bug using a pristine gap installation without any
 Debian stuff:

 rm -f workspace file file.gz
 echo "abcdefgh" > file
 gzip file
 echo 'SaveWorkspace("workspace");' | bin/*/gap -q -b
 echo 'ReadLine(InputTextFile("file"));' | bin/*/gap -q -b
 echo 'ReadLine(InputTextFile("file"));' | bin/*/gap -q -b -L workspace

 I will report it upstream.
> 
>>> Upstream send me the attached patch which fix this problem.
>>> Please confirm this address the original issue.
> 
> I deposited a patched version of GAP at deb-sci-sage (4r8p6-1+sage23).
> 
> The test
> 
> ( cd sage; ./sage -t --long src/sage/interfaces/gap.py )
> 
> passes now. But, in a previous email, Ximin seems to speak about a work 
> around.
> So, for plain confirmation, Ximin will gives the final answer.
> 

The work-around was just to uninstall gap-autpgrp (and the other packages with 
old manuals) when running sage and its tests.

Thankfully, I can confirm this patch works, even when gap-autpgrp is present.

$ sage -c 'print(gap.help("SymmetricGroup", pager=False)[:100])'
  
  50 Group Libraries
  
  When you start GAP, it already knows several groups. Currently GAP init

$ sudo aptitude install gap-autpgrp 
[..]
$ sage -c 'print(gap.help("SymmetricGroup", pager=False)[:100])'
Traceback (most recent call last):
  File "/usr/share/sage/bin/sage-eval", line 10, in 
eval(compile(s,'','exec'))
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/sage/interfaces/gap.py", line 1334, in 
help
line = Expect.eval(self, "? %s"%s)
  File "/usr/lib/python2.7/dist-packages/sage/interfaces/expect.py", line 1299, 
in eval
for L in code.split('\n') if L != ''])
  File "/usr/lib/python2.7/dist-packages/sage/interfaces/gap.py", line 772, in 
_eval_line
raise RuntimeError(message)
RuntimeError: Gap produced error output
Error, no method found! For debugging hints type ?Recovery from NoMethodFound
Error, no 1st choice method found for `+' on 2 arguments

   executing ? SymmetricGroup
# exit code 1

$ sudo aptitude install -t sid-sage gap gap-core gap-libs gap-online-help
$ sage -c 'print(gap.help("SymmetricGroup", pager=False)[:100])'
  
  50 Group Libraries
  
  When you start GAP, it already knows several groups. Currently GAP init

I also got similar results when running the gap.py doctests.

X

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

Bug#848223: cups-browsed: IPP printer disappears after logrotate is run

[Till Kamppeter]

I have fixed the problem (at least I hope so) in the upstream BZR 
repository of cups-filters (rev 7580, only file util/cups-browsed.c 
needed a change).


If possible, please test.

If you are not familiar with working with source code, please tell me 
and I will do the 1.13.1 release so that Didier can package it.


   Till

Bug#848381: [Pkg-openldap-devel] Bug#848381: openldap: [INTL:nl] Dutch translation of debconf messages

[Ryan Tandy]

Hello Frans and debian-l10n,

Thank you for the translation update and patch. However I'm sorry to say 
there are likely more template updates coming, either reverting the 
additions related to heimdal (a new heimdal release has now been 
uploaded to unstable), or refactoring/combining the handling of ppolicy 
and heimdal during upgrades. Either way the total number of new 
templates compared to jessie should be smaller than it is now.


I plan to send proper requests for review and translations once the plan 
for stretch is determined and things have settled down a bit. Sorry for 
the inconvenience meanwhile and for not communicating this sooner.


thanks,
Ryan

Bug#837162: This is probably a bug in gcc

[Margarita Manterola]

Control: reassign -1 gcc 4:6.1.1-1

Starting with the upload of gcc 4:6.1.1-1, when gcc was moved to gcc-6, quite a
bunch of packages started failing their autopkgtests related to
abi-compliance-checker.

For example, in https://ci.debian.net/packages/c/cjs/unstable/amd64/ it's
possible to see that cjs was passing the autopkgtests until August 3rd, and
started failing on August 4th after the upload that made gcc-6 the default.

To reproduce the bug, install libcjs0 and libcjs-dev, create a /tmp/dummy.h
containing:
#include "/usr/include/cjs-1.0/cjs/gjs-module.h"

And then compile that with:

gcc -fdump-translation-unit -fkeep-inline-functions -c -x c++-header 
-fpermissive -w  -I/usr/include/js "/tmp/dummy.h"  -I/usr/include/cjs-1.0 
-I/usr/include/mozjs-24 -I/usr/include/gobject-introspection-1.0 
-I/usr/include/glib-2.0 -I/tmp/buildd/cjs-3.2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include

This yields the following errors:

In file included from /usr/include/mozjs-24/jsapi.h:32:0,
 from /usr/include/cjs-1.0/cjs/compat.h:37,
 from /usr/include/cjs-1.0/cjs/jsapi-util.h:31,
 from /usr/include/cjs-1.0/cjs/native.h:32,
 from /usr/include/cjs-1.0/cjs/gjs-module.h:28,
 from /tmp/dump.h:2:
/usr/include/mozjs-24/js/Vector.h: In destructor 
'JS::AutoVectorRooter::~AutoVectorRooter()':
/usr/include/mozjs-24/js/Vector.h:589:1: error: inlining failed in call to 
always_inline 'js::Vector::~Vector() 
noexcept [with T = JS::Value; long unsigned int N = 8ul; AllocPolicy = 
js::TempAllocPolicy]': function body not available
 Vector::~Vector()
 ^~
In file included from /usr/include/cjs-1.0/cjs/compat.h:37:0,
 from /usr/include/cjs-1.0/cjs/jsapi-util.h:31,
 from /usr/include/cjs-1.0/cjs/native.h:32,
 from /usr/include/cjs-1.0/cjs/gjs-module.h:28,
 from /tmp/dump.h:2:
/usr/include/mozjs-24/jsapi.h:219:7: note: called from here
 class AutoVectorRooter : protected AutoGCRooter
   ^~~~

I don't know what's going on here, but it sounds like gcc is doing something
wrong, given that it's unable to find a function body which is actually there:

http://sources.debian.net/src/mozjs24/24.2.0-5/js/public/Vector.h#L587

template 
JS_ALWAYS_INLINE
Vector::~Vector()
{
REENTRANCY_GUARD_ET_AL;
Impl::destroy(beginNoCheck(), endNoCheck());
if (!usingInlineStorage())
this->free_(beginNoCheck());
}

Please let me know if you need any additional information.

-- 
Regards,
Marga


signature.asc
Description: Digital signature

Bug#848382: linux-image-4.8.0-2-amd64: 4.8.0-2 freezes frequently under certain conditions

[Jonathan Vollebregt]

Package: linux-image-4.8.0-2-amd64
Severity: important

Dear Maintainer,

After dist-upgrade to linux-image-4.8.0-2-amd64 I experienced
frequent freezes when running games or mpv. On the order of one
every 10 minutes. Since both heavily used my graphics card I
suspected this was due to the nvidia-driver update I installed
but purging everything related to it and reverting to nouveau
didn't solve the issue.

Reverting my kernel to linux-image-4.8.0-1-amd64 fixed the issue.
I suspect it's related to either the graphics or the audio, as
normal web browsing didn't trigger any freezes at all.

The freezes in question would instantly freeze the screen and halt
audio output, and after a few seconds my keyboard would lose power.

There was nothing in the systemd journal to indicate what happened.

After that rebooting was all that was left.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'testing'), (700, 'experimental'), (600, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#801963: Patch and workaround for issue 801963

[Adrien Dorsaz]

Hello,

On Debian Testing/Sid I still have the same issue: Remmina 1.1.2-3 
works well on Gnome 3.22 with X11 but it give segfaults with Wayland 
protocol implemented by Gnome-Shell 3.22.2-1.


Since this bug was reported here, upstream had a patch merged to 
disable wayland backend on issue report #680 [1].

As it's a Github pull request, a patch [2] and a diff [3] are available.

In another related issue report #677 [4], the upstream team gave a 
workaround for current Remmina version: force the use of the X11 
backend by setting the environment variable GDK_BACKEND to x11.


I've tried to apply this workaround by modifying the desktop file with 
such line:

replace "Exec=remmina" by "Exec=env GDK_BACKEND=x11 remmina"

It works well but I think, it's better to apply the upstream patch if 
possible (my .desktop workaround seems a bit hacking for me).


Thanks,
Adrien

PS: Remmina 1.2 has Mir and Wayland support (see [5] and download 
instructions [6]), but I think it's too short time to be ready for next 
Debian release.


PPS: The workaround and patch are also needed for Mir sessions 
according to the patch [2] and upstream issue [7], but I didn't tried 
it.



[1]: upstream pull request #680: 
https://github.com/FreeRDP/Remmina/pull/680
[2]: patch from #690: 
https://patch-diff.githubusercontent.com/raw/FreeRDP/Remmina/pull/680.patch
[3]: diff from #690: 
https://patch-diff.githubusercontent.com/raw/FreeRDP/Remmina/pull/680.diff

[4]: upstream issue #677: https://github.com/FreeRDP/Remmina/issues/677
[5]: Remmina SPICED announce: 
http://www.remmina.org/wp/remmina-spiced-has-been-released/

[6]: Remmina "download" page: https://github.com/FreeRDP/Remmina/wiki
[7]: upstream issue 554: https://github.com/FreeRDP/Remmina/issues/554

Bug#689490: piuparts blocking testing migration

[Dominic Hargreaves]

Hi,

I must have missed the memo, but according to

https://qa.debian.org/excuses.php?package=ircd-hybrid

this package is not migrating because of a piuparts failure.
In fact, the failure is not caused by irc-hybrid directly, but because
of this bug in openssl:

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

It doesn't seem appropriate for this issue to block migration of
a package which uses openssl (I'm not even sure why this behaviour
is in violation of the FHS, although, although I can see why it is 
a problem in the context of maintainer scripts). And there doesn't seem
to be any plan to do anything with that bug before stretch is released.

What to do? It seems that the testing blocker needs to be smarter
about issues which are actually related to the package, or at least
for there to be a way to request an exception. Even better, reverting
to the idea of having manual review of piuparts output and then filing
RC bugs if appropriate seemed better, although maybe it was too much
work for people, which I do understand.

However at the moment people's packages risk being outdated in testing
for completely spurious reasons and maintainers not being told about
them. I only noticed this by chance.

Cheers,
Dominic.

Bug#848380: nvidia-graphics-drivers: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: nvidia-graphics-drivers 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of nvidia-graphics-drivers 
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans



nl.po.gz
Description: application/gzip


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

Bug#848381: openldap: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: openldap 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of openldap debconf 
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans



nl.po.gz
Description: application/gzip


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

Bug#848346: libnet-ssleay-perl: certificate verify fails

[Niko Tyni]

Control: reassign -1 libio-socket-ssl-perl
Control: severity -1 serious

On Fri, Dec 16, 2016 at 02:53:29PM +0100, Aldus wrote:
> Package: libnet-ssleay-perl
> Version: 1.78-1+b1
> Severity: important
 
> libnet-ssleay-perl was broken by the upgrade from 1.78-1 to 1.78-1+b1.
> 
> In order to check for unread mail on remote servers (googlemail and
> others), I use a script including the following lines:
> 
>   my $socket = IO::Socket::SSL->new(
> PeerAddr => 'imap.googlemail.com',
> PeerPort => 993
>)
>or die "socket(): $@";
> 
> This worked until yesterday. After upgrading libnet-ssleay-perl to
> 1.78-1+b1, the script returns the error message:
> 
>   socket(): SSL connect attempt failed error:1416F086:SSL
>   routines:tls_process_server_certificate:certificate verify failed at
>   ./gmail.pl line 13 [the line quoted above]
> 
> To make the script work again, I downgraded libnet-ssleay-perl to 1.78-1, 
> but I hope the bug to be fixed soon.

Thanks for the report. The upgraded package is built against openssl 1.1
instead of 1.0.2, and the regression is related to that.

It looks like IO::Socket::SSL::default_ca() determines the base dir
for finding CA certificates by calling Net::SSLeay::SSLeay_version(5),
which no longer gives OPENSSLDIR with OpenSSL 1.1:

(old)
# perl -MNet::SSLeay -le 'print Net::SSLeay::SSLeay_version(5)' 
OPENSSLDIR: "/usr/lib/ssl" 

(new)
# perl -MNet::SSLeay -le 'print Net::SSLeay::SSLeay_version(5)'
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"

The magic constants apparently have shifted by one with the openssl
change, so OPENSSLDIR is now at 4.

I'm guessing IO::Socket::SSL should use names and not numbers for the
constants; see

 https://www.openssl.org/docs/man1.0.2/crypto/SSLeay_version.html

 https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.html

but I fear Net::SSLeay doesn't currently provide them...

Anyway, reassigning to libio-socket-ssl-perl, which clearly needs to
adapt somehow, and raising the severity to mark this release critical.
-- 
Niko Tyni   nt...@debian.org

Bug#848378: dpkg: [INTL:nl] Dutch po file for the dpkg package

[Frans Spiesschaert]

 

Package: dpkg 
Severity: wishlist 
Tags: l10n patch 
 

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

-- 
Cheers,
Frans



nl.po.gz
Description: application/gzip


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

Bug#846799: Pending fixes for bugs in the golang-google-cloud package

[Dmitry Smirnov]

Hi Martín,

On Friday, 16 December 2016 6:36:18 PM AEDT pkg-go-
maintain...@lists.alioth.debian.org wrote:
> The full diff can be seen at
> https://anonscm.debian.org/cgit/pkg-go/packages/golang-google-cloud.git/com
> mit/?id=2262e13
> 
> Commit message:
> 
> Ensure the transition from symlink to directory is handled correctly.
> Closes: #846799

Thanks for fixing this problem. FYI there is a better way to do that.
Instead of duplicated section in preinst/postinst/postrm you can use one 
"{PKGNAME}.maintscript" file with "symlink_to_dir" line.
See dpkg-maintscript-helper(1) for details.

I hope you'll find it handy.

-- 
All the best,
 Dmitry Smirnov.

---

You have to start with the truth. The truth is the only way that we can
get anywhere. Because any decision-making that is based upon lies or
ignorance can't lead to a good conclusion.
-- Julian Assange, 2010


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

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Santiago Vila]

> > [ I arrived at this bug because it already fails in my autobuilders ]
> 
> Are you behind the x32 builder?  It is the only one failing on
>  https://buildd.debian.org/status/package.php?p=coz-profiler&suite=unstable >

No, I don't run any official buildd, but I have autobuilders running
almost all the time, initially to check for "dpkg-buildpackage -A",
and then just to ensure that packages in stretch are buildable in
stretch.

This package will fail to build in any autobuilder running stretch,
therefore it does not autobuild by definition.

You can't drop the *auto* thing, it's in Release Policy:

https://release.debian.org/stretch/rc_policy.txt

Again, if you do not believe me, please ask in debian-devel.

Thanks.

Bug#848238: [Pkg-mc-devel] Bug#848238: mc: "mc diacritics (locale) problem on Debian 8.6 (Jessie)"

[Dmitry Smirnov]

On Friday, 16 December 2016 6:34:56 PM AEDT Martin Zahradník - crysman wrote:
> OK, I just had done that, it has not helped :/

I was not able to reproduce your problem.
Please try on new/clean system. There is nothing we can do unless you provide 
enough information to reproduce...

-- 
Regards,
 Dmitry Smirnov.


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

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Santiago Vila]

On Fri, Dec 16, 2016 at 10:34:47PM +0100, Petter Reinholdtsen wrote:
> 
> Control: severity -1 important
> 
> [Santiago Vila]
> > Based on the above comment, this bug should really be RC, because
> > Release Policy says that packages in stretch *must* be buildable in
> > stretch (this of course includes a machine running the default kernel
> > for stretch).
> 
> All the dependencies are present, and the build if failing will instruct
> the person supervising the build to change the content of
> /proc/sys/kernel/perf_event_paranoid from 3 to 2.
> 
> To build it, you can for example do like this:
> 
>   sudo sh -c "echo 2 > /proc/sys/kernel/perf_event_paranoid"
>   apt-get build-dep coz-profiler
>   apt-get source -b coz-profiler
> 
> I believe this demonstrate that it is buildable in Stretch.

It is buildable in stretch in an informal sense, but it does not
follow Release Policy.

Release Policy says "Packages must *auto*build".

This means no human intervention should be required. If if needs
human intervention, then it no longer autobuild as required by Release
Policy.

I'm not entering a severity war here, but this is still RC.
If you still do not believe me, please ask in debian-devel.

Thanks.

Bug#848224: [Letsencrypt-devel] Bug#848224: dehydrated-apache2: does not handle .well-known directory hidden by mod_rewrite

[Debian/GNU]

On 12/15/2016 06:03 PM, Mattia Rizzolo wrote:
>> Unfortunately it had no effect on my system: accessing
>> /.well-known/acme-challenge/ via my webserver would just give me a 404 page.
>>
>> Now, my webserver has the following characteristics
>> - multiple VirtualHosts
>> - use of mod_rewrite to do complex routing (in virtually all VirtualHosts).
> 
> umh.
> where do you configure the virtualhosts?  If you have them on
> /etc/apache2/sites-enabled those should not conflict and the conf this
> package ships would be honored (I think?!).

the vhosts are configured via /etc/apache2/sites-enabled, and i don't
think there is a conflict per se.
but i think that the mod_rewrite somehow cancels the conf from
dehydrated-apache2.

i probably should add, that mod_rewrite is rewriting the entire page
(apache2 is the front-end to a plone CMS; for vhost support on the CMS
side, i need complex proxying/rewriting capabilities such as offerend by
mod_rewrite)

> 
> In my systems I have a lot of virtulhosts too (although I don't have
> that many rewrite rules) and everything works.
> 
>> RewriteRule ^/\.well-known/acme-challenge/ - [L]
>>
>> Of course I would prefer a solution that would fix this in a central place
>> (/etc/apache2/conf-available/dehydrated.conf).
>> However, my feeble (and short-lived) attempts did not have any effect.
> 
> Have you tried adding that line to
> /etc/apache2/conf-enabled/dehydrated.conf?
> 

that was precisely my unsatisfying and "feeble attempt" to fix it.



fgmrs
IOhannes



signature.asc
Description: OpenPGP digital signature

Bug#817357: NMU of aspell-ga

[Dr. Tobias Quathamer]

Hi,

I've just uploaded an NMU of aspell-ga, patch attached.

Regards,
Tobias

diff -u aspell-ga-0.50-4/debian/changelog aspell-ga-0.50-4/debian/changelog
--- aspell-ga-0.50-4/debian/changelog
+++ aspell-ga-0.50-4/debian/changelog
@@ -1,3 +1,10 @@
+aspell-ga (0.50-4-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use debhelper v10. Closes: #817357
+
+ -- Dr. Tobias Quathamer   Fri, 16 Dec 2016 22:46:18 +0100
+
 aspell-ga (0.50-4-4) unstable; urgency=low
 
   * Converted to use aspell-autobuildhash to build the dictionary hashes
diff -u aspell-ga-0.50-4/debian/control aspell-ga-0.50-4/debian/control
--- aspell-ga-0.50-4/debian/control
+++ aspell-ga-0.50-4/debian/control
@@ -2,7 +2,7 @@
 Section: text
 Priority: optional
 Maintainer: Brian Nelson 
-Build-Depends: debhelper (>> 4.0.0), cdbs (>= 0.4.0), dictionaries-common-dev (>= 0.9.1)
+Build-Depends: debhelper (>= 10), cdbs (>= 0.4.0), dictionaries-common-dev (>= 0.9.1)
 Standards-Version: 3.6.2
 
 Package: aspell-ga
diff -u aspell-ga-0.50-4/debian/compat aspell-ga-0.50-4/debian/compat
--- aspell-ga-0.50-4/debian/compat
+++ aspell-ga-0.50-4/debian/compat
@@ -1 +1 @@
-4
+10


signature.asc
Description: OpenPGP digital signature

Bug#806629: libkarma: FTBFS when built with dpkg-buildpackage -A (dh_clideps fails)

[Sébastien Villemot]

Control: tags -1 + patch pending

Dear Maintainer,

Le dimanche 29 novembre 2015 à 16:22 +, Santiago Vila a écrit :
> Package: src:libkarma
> Version: 0.1.2-2.3
> User: sanv...@debian.org
> Usertags: binary-indep
> Severity: important
> 
> Dear maintainer:
> 
> I tried to build this package with "dpkg-buildpackage -A"
> (i.e. only architecture-independent packages), and it failed:

I am going to upload an NMU of libkarma fixing this bug. The debdiff is
attached. I am going to upload without a delay, according to usual NMU
rules, and given the very close freeze deadlines.

Best,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

diff -Nru libkarma-0.1.2/debian/changelog libkarma-0.1.2/debian/changelog
--- libkarma-0.1.2/debian/changelog	2015-11-18 13:29:04.0 +0100
+++ libkarma-0.1.2/debian/changelog	2016-12-16 22:36:06.0 +0100
@@ -1,3 +1,13 @@
+libkarma (0.1.2-2.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS when building only arch-indep packages. Implement the
+workaround documented in #830416: when dh_makeshlibs has not been
+called, create a phony shlibs.local so that dh_clideps does not crash.
+(Closes: #806629)
+
+ -- Sébastien Villemot   Fri, 16 Dec 2016 22:36:06 +0100
+
 libkarma (0.1.2-2.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libkarma-0.1.2/debian/rules libkarma-0.1.2/debian/rules
--- libkarma-0.1.2/debian/rules	2012-01-18 23:12:07.0 +0100
+++ libkarma-0.1.2/debian/rules	2016-12-16 22:36:06.0 +0100
@@ -15,3 +15,13 @@
 
 %:
 	dh $@
+
+# dh_clideps expects to see dh_makeshlibs called before it, but dh_makeshlibs
+# is never called when building only arch-indep packages. So we force the issue
+# by making a phony shlibs.local file that dh_clideps will accept, if no others
+# exist. See #806629 for the specific case of libkarma and #830416 for the bug
+# in dh_clideps.
+override_dh_clideps:
+	if ! grep -q . debian/*/DEBIAN/shlibs; then echo libkarma 0 libkarma0 > debian/shlibs.local; fi
+	dh_clideps
+	rm -f debian/shlibs.local


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

Bug#389374: Fixed in JabRef 3.7

[gregor herrmann]

Version: 3.8~pre1+ds-1

On Thu, 08 Dec 2016 19:56:03 +0100, Oliver Kopp wrote:

> This is upstream https://github.com/JabRef/jabref/issues/490 and fixed
> in upstream version 3.7.

Thanks!

Closing the bug with the first version in Debian that contained the
fix.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Cat Power: Willie


signature.asc
Description: Digital Signature

Bug#817355: NMU of aspell-cy

[Dr. Tobias Quathamer]

Hi,

I've just uploaded an NMU of aspell-cy, patch attached.

Regards,
Tobias
diff -u aspell-cy-0.50-3/debian/changelog aspell-cy-0.50-3/debian/changelog
--- aspell-cy-0.50-3/debian/changelog
+++ aspell-cy-0.50-3/debian/changelog
@@ -1,3 +1,10 @@
+aspell-cy (0.50-3-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use debhelper v10. Closes: #817355
+
+ -- Dr. Tobias Quathamer   Fri, 16 Dec 2016 22:38:34 +0100
+
 aspell-cy (0.50-3-6) unstable; urgency=low
 
   * Converted to use aspell-autobuildhash to build the dictionary hashes
@@ -47 +53,0 @@
-
diff -u aspell-cy-0.50-3/debian/control aspell-cy-0.50-3/debian/control
--- aspell-cy-0.50-3/debian/control
+++ aspell-cy-0.50-3/debian/control
@@ -2,7 +2,7 @@
 Section: text
 Priority: optional
 Maintainer: Brian Nelson 
-Build-Depends: debhelper (>> 4.0.0), cdbs (>= 0.4.0), dictionaries-common-dev (>= 0.9.1)
+Build-Depends: debhelper (>= 10), cdbs (>= 0.4.0), dictionaries-common-dev (>= 0.9.1)
 Standards-Version: 3.6.2
 
 Package: aspell-cy
diff -u aspell-cy-0.50-3/debian/compat aspell-cy-0.50-3/debian/compat
--- aspell-cy-0.50-3/debian/compat
+++ aspell-cy-0.50-3/debian/compat
@@ -1 +1 @@
-4
+10


signature.asc
Description: OpenPGP digital signature

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Petter Reinholdtsen]

Control: severity -1 important

[Santiago Vila]
> Based on the above comment, this bug should really be RC, because
> Release Policy says that packages in stretch *must* be buildable in
> stretch (this of course includes a machine running the default kernel
> for stretch).

All the dependencies are present, and the build if failing will instruct
the person supervising the build to change the content of
/proc/sys/kernel/perf_event_paranoid from 3 to 2.

To build it, you can for example do like this:

  sudo sh -c "echo 2 > /proc/sys/kernel/perf_event_paranoid"
  apt-get build-dep coz-profiler
  apt-get source -b coz-profiler

I believe this demonstrate that it is buildable in Stretch.

So to me that is no release critical bug here.  It is at most important.
The severity might change when the autobuilders for the release
architectures are affected, which is not the case at the moment.

> [ I arrived at this bug because it already fails in my autobuilders ]

Are you behind the x32 builder?  It is the only one failing on
https://buildd.debian.org/status/package.php?p=coz-profiler&suite=unstable >

> If you absolutely need to run the tests during the build, maybe a
> workaround would be to add a build-depends on a package which changes
> the kernel value for you in its postinst (as I guess that the ordinary
> user used to build packages would not be able to do that).

Interesting idea.  Not sure if such package will be accepted by the
ftpmasters, given that the sudo command above will do the same for those
privileged enough to change the level.

-- 
Happy hacking
Petter Reinholdtsen

Bug#848377: tiger: Filesystem 'efivarfs' used by 'efivarfs' is not recognised as a valid filesystem

[Francois Marier]

Package: tiger
Version: 1:3.2.3-14.2
Severity: normal

I'm getting this error message on an EFI-enabled laptop running stretch:

  --CONFIG-- [con010c] Filesystem 'efivarfs' used by 'efivarfs' is not 
recognised as a valid filesystem

Francois

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

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

Versions of packages tiger depends on:
ii  binutils   2.27.51.20161201-1
ii  bsdmainutils   9.0.12
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  net-tools  1.60+git20150829.73cef8a-2.2
ii  ucf3.0036

Versions of packages tiger recommends:
ii  chkrootkit  0.50-3.2
pn  john
ii  postfix [mail-transport-agent]  3.1.3-4
pn  tripwire | aide 

Versions of packages tiger suggests:
ii  lsof  4.89+dfsg-0.1

-- debconf information excluded

Bug#848121: [Pkg-sysvinit-devel] Bug#848121: File conflict between manpages and initscripts

[Dr. Tobias Quathamer]

Am 15.12.2016 um 14:10 schrieb Henrique de Moraes Holschuh:

On Wed, 14 Dec 2016, Ian Jackson wrote:

Michael Kerrisk (man-pages) writes:

On 14 December 2016 at 16:45, Ian Jackson
 wrote:

 - rename the manpage about /etc/default/tmpfs to tmnfs-config(5)
   (or something, better name welcome).


FWIW, I think this may be the best option.


I do see that the arguments against changing all the filesystem
manpages are pretty strong.

It's not quite clear to me quite who the maintainers of the sysvinit
package are - ie, who needs to agree.  I have been following the


Consider this a vote for the use of tmpfs-config(5) in initscripts,
since tmpfs(5) will require "apropos tmpfs" anyway to find it.


Hi,

I've prepared a patch for the git repository on alioth, please review 
it. The patch should cover all places where tmpfs(5) is mentioned, 
except debian/changelog.


The package builds in a sid chroot without problems.

If everybody thinks that this change is acceptable, it would be great to 
get it into Stretch ...


Regards,
Tobias

From 4be87bf00cddbb7deb69994182fb227ed39cf0b8 Mon Sep 17 00:00:00 2001
From: "Dr. Tobias Quathamer" 
Date: Fri, 16 Dec 2016 21:42:27 +0100
Subject: [PATCH] Rename manpage tmpfs.5 to tmpfs-config.5.

Closes: #848121
---
 debian/changelog   | 3 +++
 debian/initscripts.NEWS| 2 +-
 debian/initscripts.postinst| 8 
 debian/src/initscripts/etc/default/tmpfs   | 4 ++--
 debian/src/initscripts/man/{tmpfs.5 => tmpfs-config.5} | 9 +
 5 files changed, 15 insertions(+), 11 deletions(-)
 rename debian/src/initscripts/man/{tmpfs.5 => tmpfs-config.5} (97%)

diff --git a/debian/changelog b/debian/changelog
index 25efe99..0e1c857 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -12,6 +12,9 @@ sysvinit (2.88dsf-59.9) UNRELEASED; urgency=medium
 (Closes: #833687).  These file systems are not remountable.  The
 change avoid a warning from mount.  Based on Patch from Jon Boden.
 
+  [ Dr. Tobias Quathamer ]
+  * Rename manpage tmpfs.5 to tmpfs-config.5. Closes: #848121
+
  -- Martin Pitt   Sat, 23 Jul 2016 11:19:23 +0200
 
 sysvinit (2.88dsf-59.8) unstable; urgency=medium
diff --git a/debian/initscripts.NEWS b/debian/initscripts.NEWS
index 7794204..e4b237e 100644
--- a/debian/initscripts.NEWS
+++ b/debian/initscripts.NEWS
@@ -6,7 +6,7 @@ sysvinit (2.88dsf-26) unstable; urgency=low
   setting from /etc/default/tmpfs defaults to "no".  This means that
   a tmpfs will no longer be mounted on /tmp for upgrades or new
   installs.  Set RAMTMP to "yes" to continue to use a tmpfs on /tmp.
-  See tmpfs(5) for further details.
+  See tmpfs-config(5) for further details.
 
  -- Roger Leigh   Wed, 06 Jun 2012 20:55:45 +0100
 
diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index 259ce38..0a39db6 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -73,10 +73,10 @@ fi
 if dpkg --compare-versions "$PREV_VER" lt-nl "2.88dsf-23" ; then
 if [ -f /etc/default/rcS ]; then
 	sed -i \
--e 's:^\(RAMRUN=.*\)$:#\1 # OBSOLETE; see /etc/default/tmpfs and tmpfs(5).:' \
--e 's:^\(RAMLOCK=.*\)$:#\1 # OBSOLETE; see /etc/default/tmpfs and tmpfs(5).:' \
--e ':^RAMSHM=:i# OBSOLETE; see /etc/default/tmpfs and tmpfs(5).' \
--e ':^RAMTMP=:i# OBSOLETE; see /etc/default/tmpfs and tmpfs(5).' \
+-e 's:^\(RAMRUN=.*\)$:#\1 # OBSOLETE; see /etc/default/tmpfs and tmpfs-config(5).:' \
+-e 's:^\(RAMLOCK=.*\)$:#\1 # OBSOLETE; see /etc/default/tmpfs and tmpfs-config(5).:' \
+-e ':^RAMSHM=:i# OBSOLETE; see /etc/default/tmpfs and tmpfs-config(5).' \
+-e ':^RAMTMP=:i# OBSOLETE; see /etc/default/tmpfs and tmpfs-config(5).' \
 -e 's:^\(EDITMOTD=.*\)$:#\1 # OBSOLETE.:' /etc/default/rcS
 fi
 fi
diff --git a/debian/src/initscripts/etc/default/tmpfs b/debian/src/initscripts/etc/default/tmpfs
index 80e60a6..11e2889 100644
--- a/debian/src/initscripts/etc/default/tmpfs
+++ b/debian/src/initscripts/etc/default/tmpfs
@@ -4,7 +4,7 @@
 #
 # Configuration for tmpfs filesystems mounted in early boot, before
 # filesystems from /etc/fstab are mounted.  For information about
-# these variables see the tmpfs(5) manual page.
+# these variables see the tmpfs-config(5) manual page.
 
 # /run is always mounted as a tmpfs on systems which support tmpfs
 # mounts.
@@ -24,7 +24,7 @@
 # configured to be a separate mount in /etc/fstab.
 #RAMTMP=no
 
-# Size limits.  Please see tmpfs(5) for details on how to configure
+# Size limits.  Please see tmpfs-config(5) for details on how to configure
 # tmpfs size limits.
 #TMPFS_SIZE=20%VM
 #RUN_SIZE=10%
diff --git a/debian/src/initscripts/man/tmpfs.5 b/debian/src/initscripts/man/tmpfs-config.5
similarity index 97%
rename from debian/src/initscripts/man/tmpfs.5
rename to debian/src/initscripts/man/tmpfs-config.5
index 99b877d..4df348e 100644
--- a/debian/src/initscripts/man/tmpfs.5
+++ b/debian/src/initscripts/man/tmpfs-config.5
@@ -1,6 +1,6

Bug#847482: qt5t not to be expected for stretch

[Margarita Manterola]

Hola Dmitry Shachnev!

> > With respect to the patch, isn't there a way to use the gtk plugin instead?
> 
> That patch exports QT_QPA_PLATFORMTHEME=qt5ct. Instead of that, export
> QT_QPA_PLATFORMTHEME=gtk2 (and depend on qt5-style-plugins >= 5.0.0+git16).
> This would be (almost) identical to Qt 5.6 default experience.

Cinnamon is a GTK based desktop environment.  Adding a dependency on
qt5-style-plugins makes no sense to me.

Is there some other way that we can fix the behavior for QT apps, without adding
dependencies that make no sense for people that don't use QT?

-- 
Thanks,
Marga

Bug#800215: gkrellkam: diff for NMU version 2.0.0-1.2

[Christoph Biedl]

Control: tags 800215 + patch
Control: tags 800215 + pending
Control: tags 817335 + patch
Control: tags 817335 + pending

Dear maintainer,

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

Regards,
Christoph
diff -u gkrellkam-2.0.0/debian/rules gkrellkam-2.0.0/debian/rules
--- gkrellkam-2.0.0/debian/rules
+++ gkrellkam-2.0.0/debian/rules
@@ -6,7 +6,7 @@
 #export DH_VERBOSE=1
 
 # This is the debhelper compatability version to use.
-export DH_COMPAT=3
+#export DH_COMPAT=3
 
 configure: configure-stamp
 configure-stamp:
diff -u gkrellkam-2.0.0/debian/control gkrellkam-2.0.0/debian/control
--- gkrellkam-2.0.0/debian/control
+++ gkrellkam-2.0.0/debian/control
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: paul cannon 
-Build-Depends: debhelper (>> 3.0.0), gkrellm (>= 2.0.0), libgtk2.0-dev, 
libglib2.0-dev
+Build-Depends: debhelper (>= 10~), gkrellm (>= 2.0.0), libgtk2.0-dev, 
libglib2.0-dev
 Standards-Version: 3.5.8
 
 Package: gkrellkam
diff -u gkrellkam-2.0.0/debian/changelog gkrellkam-2.0.0/debian/changelog
--- gkrellkam-2.0.0/debian/changelog
+++ gkrellkam-2.0.0/debian/changelog
@@ -1,3 +1,10 @@
+gkrellkam (2.0.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Declare debhelper compat level, bump to 10. Closes: #800215, #817335
+
+ -- Christoph Biedl   Fri, 16 Dec 2016 
21:02:51 +0100
+
 gkrellkam (2.0.0-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- gkrellkam-2.0.0.orig/debian/compat
+++ gkrellkam-2.0.0/debian/compat
@@ -0,0 +1 @@
+10


signature.asc
Description: Digital signature

Bug#800308: gkrellmwireless: diff for NMU version 2.0.3-1.1

[Christoph Biedl]

Control: tags 800308 + patch
Control: tags 800308 + pending
Control: tags 817341 + patch
Control: tags 817341 + pending

Dear maintainer,

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

Regards,
Christoph

diff -u gkrellmwireless-2.0.3/debian/changelog 
gkrellmwireless-2.0.3/debian/changelog
--- gkrellmwireless-2.0.3/debian/changelog
+++ gkrellmwireless-2.0.3/debian/changelog
@@ -1,3 +1,11 @@
+gkrellmwireless (2.0.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Declare debhelper compat level, bump to 10. 
+Closes: #800308, #817341
+
+ -- Christoph Biedl   Fri, 16 Dec 2016 
20:56:30 +0100
+
 gkrellmwireless (2.0.3-1) unstable; urgency=low
 
   * New upstream release 
diff -u gkrellmwireless-2.0.3/debian/control 
gkrellmwireless-2.0.3/debian/control
--- gkrellmwireless-2.0.3/debian/control
+++ gkrellmwireless-2.0.3/debian/control
@@ -1,7 +1,7 @@
 Source: gkrellmwireless
 Section: x11
 Priority: optional
-Build-Depends: debhelper (>> 3.0.0), gkrellm (>= 2.0.0), libgtk2.0-dev
+Build-Depends: debhelper (>= 10~), gkrellm (>= 2.0.0), libgtk2.0-dev
 Maintainer: Sjoerd Simons 
 Standards-Version: 3.5.7
 
diff -u gkrellmwireless-2.0.3/debian/rules gkrellmwireless-2.0.3/debian/rules
--- gkrellmwireless-2.0.3/debian/rules
+++ gkrellmwireless-2.0.3/debian/rules
@@ -6,7 +6,7 @@
 #export DH_VERBOSE=1
 
 # This is the debhelper compatability version to use.
-export DH_COMPAT=3
+#export DH_COMPAT=3
 
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
   CFLAGS += -g
only in patch2:
unchanged:
--- gkrellmwireless-2.0.3.orig/debian/compat
+++ gkrellmwireless-2.0.3/debian/compat
@@ -0,0 +1 @@
+10


signature.asc
Description: Digital signature

Bug#817336: gkrellm-leds: diff for NMU version 0.8.0-1.3

[Christoph Biedl]

Control: tags 817336 + patch
Control: tags 817336 + pending
Control: tags 817476 + patch
Control: tags 817476 + pending

Dear maintainer,

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

Regards,

Christoph

diff -u gkrellm-leds-0.8.0/debian/control gkrellm-leds-0.8.0/debian/control
--- gkrellm-leds-0.8.0/debian/control
+++ gkrellm-leds-0.8.0/debian/control
@@ -2,7 +2,7 @@
 Section: x11
 Priority: extra
 Maintainer: Mike Markley 
-Build-Depends: debhelper (>> 3.0.0), gkrellm (>> 2.0) | gkrellm2, libx11-dev, 
libxtst-dev, x11proto-core-dev, libgtk2.0-dev
+Build-Depends: debhelper (>= 10~), gkrellm (>> 2.0) | gkrellm2, libx11-dev, 
libxtst-dev, x11proto-core-dev, libgtk2.0-dev
 Standards-Version: 3.5.8
 
 Package: gkrellm-leds
diff -u gkrellm-leds-0.8.0/debian/changelog gkrellm-leds-0.8.0/debian/changelog
--- gkrellm-leds-0.8.0/debian/changelog
+++ gkrellm-leds-0.8.0/debian/changelog
@@ -1,3 +1,10 @@
+gkrellm-leds (0.8.0-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Declare debhelper compat level, bump to 10. Closes: #817336, #817476
+
+ -- Christoph Biedl   Fri, 16 Dec 2016 
21:17:42 +0100
+
 gkrellm-leds (0.8.0-1.2) unstable; urgency=low
 
   [Jari Aalto]
diff -u gkrellm-leds-0.8.0/debian/rules gkrellm-leds-0.8.0/debian/rules
--- gkrellm-leds-0.8.0/debian/rules
+++ gkrellm-leds-0.8.0/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-export DH_COMPAT=4
+#export DH_COMPAT=4
 
 
 
only in patch2:
unchanged:
--- gkrellm-leds-0.8.0.orig/debian/compat
+++ gkrellm-leds-0.8.0/debian/compat
@@ -0,0 +1 @@
+10


signature.asc
Description: Digital signature

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Santiago Vila]

Hi.

If you absolutely need to run the tests during the build, maybe a
workaround would be to add a build-depends on a package which changes
the kernel value for you in its postinst (as I guess that the ordinary
user used to build packages would not be able to do that).

Yes, it would be a little bit hackish, and I don't know of any package
doing anything similar.

Thanks.

Bug#848376: [INTL:da] Danish translation of the debconf templates dbconfig-common

[Joe Dalton]

Package: dbconfig-common
Severity: wishlist
Tags: l10n patch

Please include the attached Danish dbconfig-common translation

joe@pc:~/over/debian/dbconfig-common$ msgfmt --statistics -c -v -o /dev/null 
da.po
da.po: 107 oversatte tekster.

bye
Joe

da.po.tar.gz
Description: application/gzip

Bug#847051: Question and possibly bugs about string encoding in gtk-perl

[Torsten Schönfeld]

On 16.12.2016 20:02, Dominique Dumont wrote:

On Wednesday, 14 December 2016 10:54:16 CET Boyuan Yang wrote:

The original messy output, as indicated in screenshot in the Ubuntu bug,
looks  like treating a latin-1-encoded binary data as UTF-8-encoded data
and showing them anyway.


In more details, the problematic code boils down to:

  my $wnck_screen = Gnome2::Wnck::Screen->get_default;
  my $win= $wnck_screen->get_windows_stacked; # Gnome2::Wnck object
  my $name = $win->get_name;
  my $window_item = Gtk2::ImageMenuItem->new_with_label( $name );

$name contains window name apparently in octet format instead of an utf8
string. As a consequence, the list of windows shown by shutter contains
mojibake.


Yes, Gnome2::Wnck does not do any decoding at all in get_name.  This is 
probably by accident, not by intention, but if you look at what 
wnck_window_get_name boils down to, 
, you 
see that it returns UTF8-encoded strings in most cases, but sometimes 
also strings in X11's compound text encoding, according to 
.


So it seems like the safest bet would be to try to decode the window 
name from UTF8, and if that fails, try Encode::X11 and its 
'x11-compound-text' (Hi Kevin!).



The hacky patch proposed (by me) is using
Encode::_utf8_on() to turn on the internal flag for string and mark it as
UTF-8.


And I'm worried that shutter may crash if used in a non-utf8 environment.

After some experimentation, I've come up with a safer solution:

  use 5.12.0;
  use Encode::Locale;
  use Encode qw/decode/;
  # ...
  my $name = decode( 'locale' , $win->get_name);

This works in utf8 locale and is safer than turning utf8 flag on.


It seems like this would fail in a non-UTF8 locale, however, as 
gnome_wnck_window_get_name seems to always return UTF8 strings, 
regardless of locale.

Bug#843638: same problem

[folkert]

> > You mean build-essential?
> > That I have installed. Also libtool.
> 
> Nope, I meant "apt-get build-dep " to install a package's
> build-dependencies.

Apparently autogen and intltool were missing and not in the build-dep.

After building the package from the sources from the deb-src, the
program runs fine!

Bug#576606: libparse-debianchangelog-perl: parsechangelog --to and --until fails with non existing versions

[Christoph Biedl]

tags 576606 confirmed
thanks

Simon Paillard wrote...

> When calling parsechangelog with a reference to a version that is not
> present in the NEWS.Debian (or changelog.Debian), issues appear:

Hi there,

at first, I am sorry this was not handled earlier. Bugs with working
reproducers (like yours) are much easier to handle and therefore
deserve priority.

However, it's not easy to fix since parsechangelog has no code to
handle relative version number comparison, something required to
make your use case working as expected. This is upstream's job but
upstream is more or less dead.

For the time being I've documented the behaviour in the manpage of
libparse-debianchangelog-perl 1.2.0-12 - that's not a solution but
at least provides a warning to other people.

Christoph


signature.asc
Description: Digital signature

Bug#837167: RFS: aiscm/0.6.2-2

[Jan Wedekind]

On Wed, 14 Dec 2016, Andrey Rahmatullin wrote:


On Tue, Dec 13, 2016 at 10:48:32PM +, Jan Wedekind wrote:

Other problems:
- the package doesn't build in a clean sid chroot:
not ok 19 - Check a pixel in the first video frame of the video (ERROR: In procedure 
#f: Wrong type (expecting ffmpeg): #)
FAIL: test_ffmpeg.scm 19 - Check a pixel in the first video frame of the video 
(ERROR: In procedure #f: Wrong type (expecting ffmpeg): #)


I have not managed to reproduce the failing test (even using pbuilder). Can
you let me know how you created the chroot environment with the failing
test?

It's an usual sbuild sid-amd64 chroot.



Ok, thanks. I managed to reproduce the failing test. There seems to be a 
new side effect in ffmpeg. The test passes when the pixel is read 
immediately after the image is decoded. I have uploaded the modified 
package here:


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

Regards
Jan

Bug#832613: Trademark issues (Was: kronatools_2.7+dfsg-1_amd64.changes REJECTED)

[Andreas Tille]

Hi Ian,

On Fri, Dec 16, 2016 at 12:43:37AM +, Ian Jackson wrote:
> Andreas Tille writes ("Re: kronatools_2.7+dfsg-1_amd64.changes REJECTED"):
> > 
> > Thanks for your torough checking. As discussed long ago[2]
> > 
> >   "KronaTools" may work, since the actual trademark is just
> >   "Krona". You could also use "Radiant", which was the original name
> >   (and still in SourceForge with a redirect). We avoided Radiant so
> >   our name could be trademarked, but you wouldn't have that problem
> >   I'm guessing.
> 
> The upstream you are dealing with, here, clearly don't really
> understand trademarks very well.

... which makes a perfect match between me and upstream.  I naively
assumed that the argument given by upstream should be valid to combine
two quite generic words is something else than a trademarked word.

> If "krona" is trademarked (and that
> DHS page claims it is) then "kronatools" would clearly be a breach.
> 
> You'll have to call it something without the word "krona" in.

I simply have to trust your insight here.
 
> > It would help to hear other opinions before trying another upload to
> > new: What name do you think is a proper name for this project in Debian.
> 
> I haven't been able to figure out what this program does.  Your links
> don't give your own Description and the upstream say:
> 
>   Krona Tools is a set of scripts to create Krona charts from several
>   Bioinformatics tools as well as from text and XML files.

The ITPed package description reads:

Description: explore hierarchical metagenomic data with zoomable pie charts
 Krona allows hierarchical data to be explored with zoomable pie charts.
 Krona charts include support for several bioinformatics tools and raw
 data formats. The charts can be viewed with a recent version of any
 major web browser.

The Wiki page[1] has some enlightening examples.
 
> Either this is circular, or "Krona chart" was a medical (or
> medico-informatical) term before this software existed and it
> shouldn't have been trademarked (although I doubt anyone wants to
> fight that).

I do not think that there was an older term before that should have
preventing the trademark (and even if I personally would not midn
fighting these horrible law fights).
 
> radiant-diagnostic or something maybe ?  (I see there is also a Ruby
> CMS called "radiant".)

I think radiant-graphs might come closer even if I doubt that there is
much confusion between the CMS and this tool and if its not packaged
there should be no clash.
 
I'd like to hear a word from ftpmaster if I rename the source and binary
package as well as the Git archive - would this be accepted for the next
upload.  Some kind of confirmation in advance would be helpful to do
more negotions right now and not after another round in the new queue.

Kind regards

  Andreas.

[1] https://github.com/marbl/Krona/wiki

-- 
http://fam-tille.de

Bug#848375: gkrellkam: Retrieves image from external server. Potential privacy violation, dead link

[Christoph Biedl]

Package: gkrellkam
Version: 2.0.0-1.1
Severity: normal
Tags: upstream

Dear Maintainer,

the gkrellkam sources contain a hardcoded URL to initially retrieve an
image from the host aggies.usu.edu. Besides the link is dead, users
might see this as a privacy violation.

Please change this to an image in the local file system or something
otherwise appropriate.

Christoph

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

Kernel: Linux 4.9.0 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect



signature.asc
Description: Digital signature

Bug#848374: game-data-packager: ability to skip probing the file system

[Fabian Greffrath]

Package: game-data-packager
Version: 48
Severity: wishlist

Hi there,

please add a command line option to prevent g-d-p from probing my file
system for additional game data files. That is, if I type "g-d-p doom
/path/to/gog-setup.exe" I want g-d-p to create a data package from
this very resource and not have it iterate through my file system and
discover all the other variants of DOOM.WAD that I have installed.

Thanks!

 - Fabian



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

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

Versions of packages game-data-packager depends on:
ii  fakeroot1.21-2
ii  python3-debian  0.1.29
ii  python3-yaml3.12-1
pn  python3:any 

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  47

Versions of packages game-data-packager suggests:
pn  arj   
ii  binutils  2.27.51.20161201-1
ii  cabextract1.6-1
pn  cdparanoia
pn  dynamite  
ii  gcc   4:6.2.1-1
pn  gdebi | gdebi-kde 
ii  gir1.2-gdkpixbuf-2.0  2.36.0-1
ii  innoextract   1.6-1+b2
pn  lgc-pg
pn  lgogdownloader
ii  lhasa [lzh-archiver]  0.3.1-2
ii  make  4.1-9
ii  p7zip-full16.02+dfsg-2
pn  steam 
pn  steamcmd  
pn  unace-nonfree 
ii  unar  1.10.1-1+b1
pn  unrar 
pn  unshield  
ii  unzip 6.0-20
ii  vorbis-tools  1.4.0-10
ii  xdelta1.1.3-9.1

-- no debconf information

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Santiago Vila]

severity 844633 serious
thanks

On Sun, 4 Dec 2016, Petter Reinholdtsen wrote:

> It seem to be by accident that the autobuilders work.  I asked, and it
> is only because they are running Debian stable.  The ones running newer
> kernels do not work.  This will change when they are upgraded, unless
> they are willing to adjust the perf_event_paranoid value on the
> autobuilders, which seem unlikely given that the kernel maintainer in
> Debian recommend against it.

Based on the above comment, this bug should really be RC, because
Release Policy says that packages in stretch *must* be buildable in
stretch (this of course includes a machine running the default kernel
for stretch).

[ I arrived at this bug because it already fails in my autobuilders ]

Thanks.

Bug#846454: NMU of verilator

[Dr. Tobias Quathamer]

Hi,

I've just uploaded an NMU with this simple fix, patch attached.

Regards,
Tobias
diff --git a/debian/changelog b/debian/changelog
index e94769c..21a259e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+verilator (3.874-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add libfl-dev to Build-Depends.
+Thanks to Helmut Grohne  (Closes: #846454)
+  * Use new and secure URL for Vcs-* fields
+
+ -- Dr. Tobias Quathamer   Fri, 16 Dec 2016 20:51:50 +0100
+
 verilator (3.874-1) unstable; urgency=medium
 
   * Upload to unstable.
diff --git a/debian/control b/debian/control
index 79d920f..fef4a2d 100644
--- a/debian/control
+++ b/debian/control
@@ -3,11 +3,11 @@ Section: electronics
 Priority: optional
 Maintainer: Debian Electronics Team 
 Uploaders: أحمد المحمودي (Ahmed El-Mahmoudy) 
-Build-Depends: debhelper (>= 9), autotools-dev, flex, bison
+Build-Depends: debhelper (>= 9), autotools-dev, flex, bison, libfl-dev
 Standards-Version: 3.9.6
 Homepage: http://www.veripool.org/wiki/verilator
-Vcs-Git: git://anonscm.debian.org/pkg-electronics/verilator.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-electronics/verilator.git
+Vcs-Git: https://anonscm.debian.org/git/pkg-electronics/verilator.git
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-electronics/verilator.git
 
 Package: verilator
 Architecture: any


signature.asc
Description: OpenPGP digital signature

Bug#848373: diffoscope: Missing install dependency on colordiff

[Mattia Rizzolo]

control: tag -1 pending

On Fri, Dec 16, 2016 at 08:38:56PM +0100, Christoph Biedl wrote:
> diffoscope requires colordiff to run but does neither depend on the
> package nor check for its presence to perhaps handle the situation
> gracefully.

maybe, but colordiff is not used anymore in git as
dea5a1bf4af893ae657d5c106ea7df6c0bbc78fe as we now do the coloring
directly ourself, so the problem actually doesn't exist anymore.

-- 
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#848373: diffoscope: Missing install dependency on colordiff

[Christoph Biedl]

Package: diffoscope
Version: 63
Severity: important
Tags: newcomer

Dear Maintainer,

diffoscope requires colordiff to run but does neither depend on the
package nor check for its presence to perhaps handle the situation
gracefully. And so I got:

--- v1/gkrellmwireless_2.0.3-1_amd64.changes
+++ v2/gkrellmwireless_2.0.3-1_amd64.changes
├── Files
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 290, in main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 268, in 
run_diffoscope
output_text(difference, print_func=print_func, color=color)
  File "/usr/lib/python3/dist-packages/diffoscope/presenters/text.py", line 60, 
in output_text
print_details(difference, print_func, color)
  File "/usr/lib/python3/dist-packages/diffoscope/presenters/text.py", line 49, 
in print_details
print_difference(detail, print_func, color)
  File "/usr/lib/python3/dist-packages/diffoscope/presenters/text.py", line 34, 
in print_difference
diff_output = color_unified_diff(difference.unified_diff)
  File "/usr/lib/python3/dist-packages/diffoscope/__init__.py", line 69, in 
tool_check
raise RequiredToolNotFound(command)
diffoscope.exc.RequiredToolNotFound: colordiff


Please add colordiff to the Depends: line, thanks.

Christoph

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

Kernel: Linux 4.9.0 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect

Versions of packages diffoscope depends on:
ii  python3-libarchive-c   2.1-3.1
ii  python3-magic  1:5.29-1
ii  python3-pkg-resources  28.7.1-1
pn  python3:any

Versions of packages diffoscope recommends:
ii  acl2.2.52-3
pn  binutils-multiarch 
ii  bzip2  1.0.6-8
pn  caca-utils 
pn  colord 
ii  colordiff  1.0.16-1
pn  cpio   
pn  default-jdk-headless | default-jdk | java-sdk  
pn  enjarify   
pn  fontforge-extras   
pn  fp-utils   
pn  genisoimage
ii  gettext0.19.8.1-1
pn  ghc
pn  ghostscript
ii  gnupg  2.1.16-2
pn  llvm   
pn  mono-utils 
pn  pdftk  
pn  poppler-utils  
pn  python3-argcomplete
ii  python3-debian 0.1.29
pn  python3-guestfs
pn  python3-progressbar
ii  python3-rpm4.12.0.2+dfsg1-1
ii  python3-tlsh   3.4.4+20151206-1+b1
pn  rpm2cpio   
pn  sng
pn  sqlite3
pn  squashfs-tools 
ii  unzip  6.0-20
ii  vim-common 2:8.0.0095-1
ii  xxd2:8.0.0095-1
ii  xz-utils   5.2.2-1.2

Versions of packages diffoscope suggests:
ii  libjs-jquery  3.1.1-1

-- no debconf information



signature.asc
Description: Digital signature

Bug#844479: RE:Bug#844479: zeromq3: zeromq 4.2.0 breaks tango

[PICCA Frederic-Emmanuel]

Yes I work on this with the upstream :))

So don't worry I will tell you when it is ok.

Cheers

Fred

Bug#774164: libocrad-dev: libocrad.a contains non-reallocatable code

[Dmitry Katsubo]

On 2016-12-16 10:16, Alexander Alemayhu wrote:
> On Thu, Dec 15, 2016 at 09:42:08PM +0100, Petter Reinholdtsen wrote:
>>
>> Personally I use tesseract these days for my OCR work, and do not need ocrad.
> 
> I have unfortunately stopped using ocrad in favour of proprietary
> solutions.
> 
> Thanks for adding me to the recipient list, but I don't have the
> motivation to help here.
> 
> Added Jakub Wilk to copy, IIRC he made the package.

I see from the build log [1] that the build policy for .a had changed... I think
that is for good. Relocatable code makes object a bit bigger, but on current
systems that does not matter at all. Briefly:

1. One solution would be to make .a code reallocatable, so that .so library
that refers libocrad.a can compile.

2. Another solution is to provide libocrad.so within libocrad package.

[1] 
https://ci.debian.net/data/packages/unstable/amd64/o/ocrad/20161215_073147.autopkgtest.log.gz

-- 
With best regards,
Dmitry

Bug#778632: AssertionError for no obvious reason

[Rob Browning]

fixed 778632 0.28
thanks

I believe this should have been fixed in 0.28 via:

  commit c6ca14bac1e848d9414841d7181b7c7cdc85caa2
  Author: Rob Browning 
  Date:   Mon Dec 21 13:35:24 2015 -0600

  index: always return at least the root for filter prefixes

  Return at least an entry for the prefix itself for each prefix passed
  to filter.  Otherwise something like "bup save ... x/y" will fail when
  x is up to date because filter will return nothing, save will traverse
  nothing in its main loop, and bup will crash with an assertion
  failure:

File "/home/rlb/src/bup/main/cmd/bup-save", line 440, in 
  assert(len(shalists) == 1)

  Instead "bup save ... x/y" should (and now will) produce a new save
  containing x/y.

  Thanks to Simon Persson for helping formulate a good test case.

  Signed-off-by: Rob Browning 
  Tested-by: Rob Browning 

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#844479: RE:Bug#844479: zeromq3: zeromq 4.2.0 breaks tango

[Luca Boccassi]

On Thu, 24 Nov 2016 09:58:33 + PICCA Frederic-Emmanuel 
 wrote:
> Hello,
> 
> I just opened a bug for tango
> 
> https://github.com/tango-controls/cppTango/issues/312
> 
> 
> what is the deadline where we can take the decision to upload or not zeromq 
> 4.2.0 into Debian testing ?
> 
> This will let also some time in order to check if this 4.2.0 do not have 
> other size effect of dependeings softwares.
> 
> Thanks
> 
> Fred

Hi,

It looks like that bug has been marked as fixed:

https://github.com/tango-controls/cppTango/issues/312

https://github.com/tango-controls/cppTango/commit/707f28e88d8ba9a49394688737bd7d5470695873

Any chance this patch could be backported to the tango package so that
we can get zmq 4.2 unblocked?

Thank you!

Kind regards,
Luca Boccassi


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

Bug#848372: linux-image-4.8.0-2-amd64: Resume from suspend results in unrecoverable kernel panic.

[william l-k]

Package: src:linux
Version: 4.8.11-1
Severity: important


linux-image-4.8.0-2-amd64: Resume from suspend results in unrecoverable kernel
panic.

Dear Maintainer,

I submitted a very similar bug report for the previous image:

Bug#847392: linux-image-4.8.0-1-amd64: Resume from suspend results in
unrecoverable kernel panic.

As in this bug report, resume from suspend doesn't work.

The symptoms are the same:

- flashing caps lock
- unable to resume
- troubleshooting efforts fail to alter the behavior

The only change, is that I'm unable to get the screen to display anything after
the system suspends. With linux-image-4.8.0-1-amd64 I was able to get the
screen to display the kernel panic message. Now I just get the flashing caps
lock.




-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 root=/dev/mapper/lvmpool-root ro panic=5

** Not tainted

** Kernel log:
[   21.432624] radeon :00:01.0: fence driver on ring 5 use gpu addr 
0x00078d30 and cpu addr 0xa45cc2038d30
[   21.432892] radeon :00:01.0: fence driver on ring 6 use gpu addr 
0x4c18 and cpu addr 0x95292af5dc18
[   21.432917] radeon :00:01.0: fence driver on ring 7 use gpu addr 
0x4c1c and cpu addr 0x95292af5dc1c
[   21.432940] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   21.432953] [drm] Driver supports precise vblank timestamp query.
[   21.433043] radeon :00:01.0: radeon: using MSI.
[   21.433107] [drm] radeon: irq initialized.
[   21.437915] [drm] ring test on 0 succeeded in 2 usecs
[   21.438012] [drm] ring test on 1 succeeded in 2 usecs
[   21.438034] [drm] ring test on 2 succeeded in 2 usecs
[   21.438234] [drm] ring test on 3 succeeded in 3 usecs
[   21.438245] [drm] ring test on 4 succeeded in 3 usecs
[   21.464103] [drm] ring test on 5 succeeded in 1 usecs
[   21.464124] [drm] UVD initialized successfully.
[   21.532278] uvcvideo: Found UVC 1.00 device TOSHIBA Web Camera - HD 
(04ca:7046)
[   21.535155] uvcvideo 1-1.4:1.0: Entity type for entity Extension 4 was not 
initialized!
[   21.535170] uvcvideo 1-1.4:1.0: Entity type for entity Processing 2 was not 
initialized!
[   21.535182] uvcvideo 1-1.4:1.0: Entity type for entity Camera 1 was not 
initialized!
[   21.535344] input: TOSHIBA Web Camera - HD as 
/devices/pci:00/:00:12.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input11
[   21.535465] usbcore: registered new interface driver uvcvideo
[   21.535472] USB Video Class driver (1.1.1)
[   21.573381] [drm] ring test on 6 succeeded in 11 usecs
[   21.573406] [drm] ring test on 7 succeeded in 1 usecs
[   21.573419] [drm] VCE initialized successfully.
[   21.576197] [drm] ib test on ring 0 succeeded in 0 usecs
[   22.080189] [drm] ib test on ring 1 succeeded in 0 usecs
[   22.592137] [drm] ib test on ring 2 succeeded in 0 usecs
[   22.592234] [drm] ib test on ring 3 succeeded in 0 usecs
[   22.592303] [drm] ib test on ring 4 succeeded in 0 usecs
[   22.983445] Adding 33202172k swap on /dev/mapper/lvmpool-swap.  Priority:-1 
extents:1 across:33202172k FS
[   23.104244] [drm] ib test on ring 5 succeeded
[   23.104794] [drm] ib test on ring 6 succeeded
[   23.105231] [drm] ib test on ring 7 succeeded
[   23.109396] [drm] radeon atom DIG backlight initialized
[   23.109410] [drm] Radeon Display Connectors
[   23.109420] [drm] Connector 0:
[   23.109428] [drm]   eDP-1
[   23.109436] [drm]   HPD1
[   23.109447] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 
0x653c
[   23.109460] [drm]   Encoders:
[   23.109468] [drm] LCD1: INTERNAL_UNIPHY
[   23.109477] [drm] Connector 1:
[   23.109485] [drm]   HDMI-A-1
[   23.109492] [drm]   HPD2
[   23.109501] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 
0x654c
[   23.109515] [drm]   Encoders:
[   23.109523] [drm] DFP1: INTERNAL_UNIPHY
[   23.109531] [drm] Connector 2:
[   23.109539] [drm]   VGA-1
[   23.109548] [drm]   DDC: 0x65c0 0x65c0 0x65c4 0x65c4 0x65c8 0x65c8 0x65cc 
0x65cc
[   23.109561] [drm]   Encoders:
[   23.109569] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   24.129775] [drm] fb mappable at 0xC0722000
[   24.129795] [drm] vram apper at 0xC000
[   24.129806] [drm] size 4325376
[   24.129816] [drm] fb depth is 24
[   24.129825] [drm]pitch is 5632
[   24.130057] fbcon: radeondrmfb (fb0) is primary device
[   24.173127] ath9k :03:00.0 wlp3s0: renamed from wlan0
[   26.099607] Console: switching to colour frame buffer device 170x48
[   26.109879] radeon :00:01.0: fb0: radeondrmfb frame buffer device
[   26.145212] [drm] Initialized radeon 2.46.0 20080528 for :00:01.0 on 
minor 0
[   27.901436] EXT4-fs (dm-8): mounted filesystem with ordered data mode. Opts: 
errors=remount-ro
[   34.040837] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[   42.271127] IPv6: ADDR

Bug#800215: About to prepare NMUs

[Christoph Biedl]

Hello,

this is to let you know I will fix the packages

Package: src:gkrellkam (debian/main).
  800215 [] [U] gkrellkam: Please migrate a supported debhelper 
compat level
  817335 [] [U] gkrellkam: Mandatory debian/compat for debhelper

Package: src:gkrellm-leds (debian/main).
  817336 [] [U] gkrellm-leds: Mandatory debian/compat for debhelper
  817476 [] [U] gkrellm-leds: Removal of debhelper compat 4

Package: src:gkrellm-mailwatch (debian/main).
  800297 [] [U] gkrellm-mailwatch: Please migrate a supported 
debhelper compat level

Package: src:gkrellm-radio (debian/main).
  800309 [] [U] gkrellm-radio: Please migrate a supported debhelper 
compat level
  817339 [] [U] gkrellm-radio: Mandatory debian/compat for debhelper

Package: src:gkrellmwireless (debian/main).
  800308 [] [U] gkrellmwireless: Please migrate a supported 
debhelper compat level
  817341 [] [U] gkrellmwireless: Mandatory debian/compat for 
debhelper

Package: src:gkremldk (debian/main).
  817480 [] [U] gkremldk: Removal of debhelper compat 4

through a NMU in the next days. This notice is to avoid anybody else
spends time on them, resulting in unncessary duplicate work.


Maintainer: If you still wish to handle the issues on your own, please
let me know ASAP. But keep in mind time's almost up, December 25th is
the deadline.

Users: Fear not, unless things go horribly wrong this package will be in
the stretch release.

Other potential NMUers: Your interest is appreciated, there should be
enough low-hanging fruits around to work on, please pick one. If there's
no further activity on this bug by Mon 19th 00:00 UTC, consider this
advisory lock stale, feel free to take over then.

Christoph


signature.asc
Description: Digital signature

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 16 de diciembre de 2016 15:55:49 ART Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Source: llvm-toolchain-3.9
> Version: 1:3.9.1-1
> Severity: wishlist
> 
> As can be seen in #846410 having no ELF-versioned symbols leads to
> unexpected crashes when two LLVM versions are used in the same process.
> 
> Adding ELF symbols versions would allow avoiding this crashes as long as
> no data is interchanged between both versions of LLVM-related libs.

With ELF symbols I mean this:

https://sourceware.org/binutils/docs/ld/VERSION.html


-- 
~/ sweet ~/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#823169: bup: restore --sparse may corrupt data

[Rob Browning]

fixed 823169 0.28
thanks

This should be fixed in 0.28.

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#848371: ITP: node-external-editor -- Edit a string with the users preferred text editor

[Paolo Greppi]

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

* Package name: node-external-editor
  Version : 2.0.1
  Upstream Author : Kevin Gravier  (https://mrkmg.com)
* URL : https://github.com/mrkmg/node-external-editor#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Edit a string with the users preferred text editor

 Node.js module to edit a string with the users preferred text editor,
 using either $VISUAL or $ENVIRONMENT.
 .
 Node.js is an event-based server-side JavaScript engine.

It is required for node-inquirer (ITP: https://bugs.debian.org/848364)
which in turn is required by node-yarnpkg 0.18 (ITP:
https://bugs.debian.org/843021).

My intention is to package it within the javascript maintainers team.

The repo will be on alioth:
https://anonscm.debian.org/git/pkg-javascript/node-external-editor.git

Paolo

Bug#847051: Question and possibly bugs about string encoding in gtk-perl

[Dominique Dumont]

[ 2nd try ]

On Wednesday, 14 December 2016 10:54:16 CET Boyuan Yang wrote:
> The original messy output, as indicated in screenshot in the Ubuntu bug,
> looks  like treating a latin-1-encoded binary data as UTF-8-encoded data
> and showing them anyway. 

In more details, the problematic code boils down to:
 
 my $wnck_screen = Gnome2::Wnck::Screen->get_default;
 my $win= $wnck_screen->get_windows_stacked; # Gnome2::Wnck object
 my $name = $win->get_name;
 my $window_item = Gtk2::ImageMenuItem->new_with_label( $name );

$name contains window name apparently in octet format instead of an utf8 
string. As a consequence, the list of windows shown by shutter contains 
mojibake. 

> The hacky patch proposed (by me) is using
> Encode::_utf8_on() to turn on the internal flag for string and mark it as
> UTF-8.

And I'm worried that shutter may crash if used in a non-utf8 environment.

After some experimentation, I've come up with a safer solution:

 use 5.12.0;
 use Encode::Locale;
 use Encode qw/decode/;
 # ...
 my $name = decode( 'locale' , $win->get_name);

This works in utf8 locale and is safer than turning utf8 flag on.

That said, shouldn't this decoding work be done in Gnome2::Wnck ?

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#791475: bup: Unable to restore an emacs autosave file #.fetchmailrc#

[Rob Browning]

I suspect this has been fixed by:

  commit 0527f5d46b7d3f3f874d45cd59db01aa48a84046
  Author: Rob Browning 
  Date:   Tue Sep 6 23:34:24 2016 -0500

  Handle ntfs-3g EINVAL for attr save/restore

  It appears that ntfs-3g now returns EINVAL for unsupported ioctls
  including FS_IOC_GET_FLAGS and FS_IOC_SET_FLAGS.

  Treat EINVAL like the existing expected errors for these calls, but
  since there's evidence to suggest that other devices/filesystems use
  EINVAL to indicate more serious trouble and use ENOTTY to indicate
  unsupported ioctls, include a request to report any occurrences of
  EINVAL when ntfs-3g is not involved.

  Thanks to Mark J Hewitt for reporting the problem.

  Signed-off-by: Rob Browning 
  Tested-by: Rob Browning 

(EINVAL is 22) and so should be corrected in the next release.

And as a temporary solution, just adding EINVAL to the set of expected errno
values (as shown in that patch) should work fine.

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#848370: terminology crashes when creating new tab

[Ross Vandegrift]

Package: terminology
Version: 0.9.1-1
Severity: important

When built against efl 1.8 (currently in sid), terminology crashes when
creating a new tab.  This is fixed in newer efl (currently in experimental),
but due to abi changes, will require a rebuild to use the newer libs.

Ross

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

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

Versions of packages terminology depends on:
ii  libc6 2.24-8
ii  libecore-con1 1.8.6-2.5+b1
ii  libecore-evas11.8.6-2.5+b1
ii  libecore-file11.8.6-2.5+b1
ii  libecore-imf1 1.8.6-2.5+b1
ii  libecore-input1   1.8.6-2.5+b1
ii  libecore-ipc1 1.8.6-2.5+b1
ii  libecore1 1.8.6-2.5+b1
ii  libedje1  1.8.6-2.5+b1
ii  libeet1   1.8.6-2.5+b1
ii  libefreet-bin 1.8.6-2.5+b1
ii  libefreet1a   1.8.6-2.5+b1
ii  libeina1  1.8.6-2.5+b1
ii  libeio1   1.8.6-2.5+b1
ii  libelementary21.8.5-2
ii  libemotion1   1.8.6-2.5+b1
ii  libethumb-client-bin  1.8.6-2.5+b1
ii  libethumb-client1 1.8.6-2.5+b1
ii  libevas1  1.8.6-2.5+b1
ii  libevas1-engines-x1.8.6-2.5+b1
ii  liblz4-1  0.0~r131-2
ii  terminology-data  0.9.1-1

terminology recommends no packages.

Versions of packages terminology suggests:
pn  libelementary-bin   
pn  libemotion-players  

-- no debconf information

Bug#846410: Help needed with llvm bug

[Lisandro Damián Nicanor Pérez Meyer]

@pkg-llvm-team: I've sent two compressed files in a previous bug which got 
stuck due to it's size. Please check the bug report for this.

-- 
If you have an apple and I have an apple and we exchange these apples then you
and I will still each have one apple. But if you have an idea and I have an
idea and we exchange these ideas, then each of us will have two ideas.
 George Bernard Shaw

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#848369: ITP: node-exit-hook -- Run some code when the process exits

[Paolo Greppi]

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

* Package name: node-exit-hook
  Version : 1.1.1
  Upstream Author : Sindre Sorhus 
(http://sindresorhus.com)
* URL : https://github.com/sindresorhus/exit-hook
* License : Expat
  Programming Lang: JavaScript
  Description : Run some code when the process exits

 Node-js module to run one or more hooks when the process exits,
 either because the event loop dried up, or because it received
 a signal (SIGINT or SIGTERM).
 .
 Useful for cleaning up.
 .
 Node.js is an event-based server-side JavaScript engine.

It is required for:
- restore-cursor
- which is required for cli-cursor
- which is required for node-inquirer (ITP: https://bugs.debian.org/848364)
- which in turn is required by node-yarnpkg 0.18 (ITP:
https://bugs.debian.org/843021).

My intention is to package it within the javascript maintainers team.

The repo will be on alioth:
https://anonscm.debian.org/git/pkg-javascript/node-exit-hook.git

Paolo

Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

[Lisandro Damián Nicanor Pérez Meyer]

Source: llvm-toolchain-3.9
Version: 1:3.9.1-1
Severity: wishlist

As can be seen in #846410 having no ELF-versioned symbols leads to unexpected
crashes when two LLVM versions are used in the same process.

Adding ELF symbols versions would allow avoiding this crashes as long as
no data is interchanged between both versions of LLVM-related libs.

Thanks for considering, Lisandro.

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

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

Bug#635157: cups: please support Brother HL-2130 laser printer out of the box

[Brian Potkin]

On Mon 19 Mar 2012 at 03:17:57 -0500, Jonathan Nieder wrote:

> This means a goal would be to get a driver included in a simple, free,
> and distro-neutral collection such as openprinting-ppds and listed at
> .
> 
> Michal, does the HL-2130 work as a generic postscript printer?  (I am
> guessing it does, based on a quick glance at the ppd and since the
> HL-2140 can act as one.)
> 
> Brother's PPD for this model is licensed under the GPL.  Their driver
> package also includes some binary-only components to configure the
> printer, unfortunately without an explicit license that would even
> allow us to distribute it, so probably any open source driver is going
> to lack some functionality in the short term.
> 
> The free part of the driver is not listed at
>  as having
> been incorporated into openprinting-ppds yet.  Reassigning to the
> foomatic-db package to pursue that.
> 
> Thanks for some useful pointers.

JFTR and to keep the history of this issue relatively up-to-date:

https://lists.debian.org/debian-printing/2016/12/msg00078.html

https://lists.debian.org/debian-printing/2016/12/msg00082.html

https://lists.debian.org/debian-printing/2016/12/msg00089.html

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/701856

Regards,

-- 
Brian.

Bug#824169: ftp.debian.org: src:chocolate-doom/2.2.1-3 is in both main and contrib

[Fabian Greffrath]

Am Freitag, den 16.12.2016, 19:43 +0100 schrieb Fabian Greffrath:
> Technically, the branch looks fine, especially after the latest
> commit

Oh wait, are you sure we don't need empty dummy packages for a proper
transition?

 - Fabian


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

Bug#824169: ftp.debian.org: src:chocolate-doom/2.2.1-3 is in both main and contrib

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Freitag, den 16.12.2016, 16:07 + schrieb Jonathan Dowland:
> Initial proposal for a combined binary package is now pushed to the
> 'proposed-consolidate' branch.

Thank you for your work on this!

Technically, the branch looks fine, especially after the latest commit
with all the Provides/Breaks/Replaces in place (though, I would still
add the trailing tilde back to take backports into account). However,
it makes me a bit sad to let the fine-crafted package split go. Anyway,
if you suggest this is the most reasonable solution to get Choco into
testing, please go for it!

Cheers,

 - Fabian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlhUNcAACgkQy+qOlwzN
Wd9KaxAAsQGkIIZm+vEONSirurmdUhbJXTNVTrgZaRYwisOKe5q5FbG4EpYoO0Te
QCQREGkltdksej2AB4h3M0YAjA8UjpAwjN13cGzY6FYIpwyX89hNL/mefFKbJfvN
PhZbswzOjzh26186qtphIOc1qX9pXKRmUJGaDdzS3ooYgOchgAfxGc4Ol/pCfJvJ
3EjofpRW7tpkbUXBzCcopIXwEc7vLkL8PekhNeUYekRWhlA7LDp8WIiZfd1J2Fim
iQ63ZF5R1Oc3g1AwXHRfrTFX6Wie+bInmWZ5Ll8U0Q3jnGIwpVB0ktLkDkl65Yf4
K0j3M2RYE4Y8FRFHLyx+VdLc9ksDOcURSgUf1DM65HqjcHE2XIKUzCSMIJUVV8GG
+CsRbkKNeqDTEMrge3waLZfokOELAvyI+JiGaB3IIFHbGxoaZHbYWRkWUMwURAj0
6cmS55FFNTw0GugeodYstWAaerqJ0uhudg4xpM7USgarK698arFpP4jzYmlHUUh9
648a23OB+E6Vi1znzEta0AFv77PdVY5978GEzhYdH4yTMf8nE/iHpdCChzhorCof
JsL5Tv7czdCC0/Hdq9iDBwJ2lxDM39L9VTkZS2kQH2viLXu/ToUsajAiRpqhPvgN
cM7dy+z8X8//+O+j50F2yEWa/eZj1XVBjzDbNbE2VvqUrSTkhUM=
=KHuA
-END PGP SIGNATURE-