Bug#838266: Salvaging pylibtiff to Debian Python team or removing it from Debian?

[Maximiliano Curia]

¡Hola Andreas!

El 2016-10-21 a las 09:36 +0200, Andreas Tille escribió:
the former maintainer of pylibtiff inside Debian Med team Mathieu 
Malaterre does not care for the package any more and thus I tried 
my luck to salvage it.  I have no personal interest in this package 
nor does it have any rdepends.  There is no direct connection to 
the Debian Med topic but since there are some users according to 
popcon[1] it might be worth saving.


I won't be able to work on this in the foreseeable future, but I can probably 
help with the mentioned errors.


 File "/usr/lib/python2.7/dist-packages/libtiff/libtiff_ctypes.py", line 36 
   print 'You should add %r to PATH environment variable and reboot.' % (os.path.dirname (lib)) 
^ 
SyntaxError: invalid syntax


This looks valid, but probably fails if using:
from __future__ import print_function
you can probably fix this by adding the parenthesis needed for the function 
invocation:

print('You should add %r to PATH environment variable and reboot.' % 
(os.path.dirname (lib)))

 File "/usr/lib/python2.7/dist-packages/libtiff/optparse_gui.py", line 201 
   print(msg, file=sys.stderr) 
  ^ 
SyntaxError: invalid syntax


This is probably failing because of a missing:
from __future__ import print_function
at the beginning of the file (it needs to be added before any other import).

In python2 print is a statement that you use as print "Hi", in python3 it's a
function that you use as print("Hi"), using the __future__ snippet you can use 
(in python 2.7) print as a function, this is generally a good idea as it eases 
the migration to python3 process.


Happy hacking,
--
"If you have too many special cases, you are doing it wrong." -- Craig Zarouni
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#739402: Info received (Bug#739402: awesome-extra: 2012061101 version is out of date, please upgrade)

[Adam Lee]

How so? Please upgrade, please...

adam@mbp:~$ date
Sat Oct 22 13:07:26 CST 2016

adam@mbp:~$ apt policy awesome-extra
awesome-extra:
  Installed: (none)
  Candidate: 2012061101
  Version table:
 2012061101 500
500 http://ftp.cn.debian.org/debian unstable/main amd64 Packages
500 http://ftp.cn.debian.org/debian unstable/main i386 Packages

Bug#835148: Bug#837420: Bug#835148: please do not make GCC incompatible, we have dpkg-buildflags for this! (was Re: Bug#837420: Processed: PIE FTBFS are now RC)

[Christian Seiler]

On 10/22/2016 01:00 AM, Thorsten Glaser wrote:
> Bálint Réczey dixit:
> 
>> AFAIK the linux package is the only problematic package were the
>> maintainer refused to disable PIE from packaging scripts.
> 
> So, how are you supposed to do that now, instead of filtering
> -fPIE from CFLAGS and -pie from LDFLAGS?
> 
> Christian/zumbi: do you take care of dietlibc, or should I?

Yes, I fully intend to fix that - which is why I tagged the bug
report "confirmed" when it was first reported, even while it
was still of lower severity. I just had a lot of other stuff
come up and didn't get to it yet. I had actually planned to
take some time on Sunday for this, even before the severity of
this bug was bumped.

Also, I'd really appreciate it if you talked to me and zumbi
first before escalating the bug report and asking for a revert
of archive-wide changes in the name of the dietlibc package.
Because from my perspective I'm in favor of the change (hence
the "confirmed" on the bug when it was first reported, and I
did follow the threads on debian-devel related to this) and we
could have had this discussion amongst ourselves without
involving the gcc maintainers, who probably have to deal with
enough things already. Many thanks.

Regards,
Christian

Bug#841548: Processed: Re: Bug#841548: autopkgtest: FTBFS: Tests failures

[Changwoo Ryu]

It happens to me when upgrading imagemagick from 6.8.9.9-7.2+b1 to
6.9.6.2+dfsg-2.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ron]

On Wed, 19 Oct 2016 16:12:51 +0100, Wookey wrote:
> Indeed. The current situation is that the existing version is so old
> that it doesn't work properly with modern code any more, but the
> maintainer has refused to do any of:
> 1) upload a new package, 

I'm not "refusing to upload a new package", I'm asserting that trading
one set of problems for a worse set of problems is not a solution to
a problem.

The crux of the problem is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#131

And I don't think it's contentious to suggest that upstream's proposed
'solution' of using chmod 777 on a privileged directory is not something
that's acceptable for a distro package.

Shigio contacted me privately in 2010, proposing this mechanism as a
replacement for the interface that he and I first worked out in 1999
to do this securely in a way that was suitable for packaged software,
and I gave him a detailed review of that, explaining why that wasn't
a suitable answer, and what we'd need to do one way or another to make
it one.  But he then simply ignored that (and later feigned ignorance
that we'd even discussed it - despite his own upstream changelog
acknowledging that we had), and made a series of incompatible changes
to do this anyway.

At around the same time, Taisuke Yamada had also expressed an interest
in this and tried to reason with him about sane ways to do this, but
his comments were similarly ignored as well.

I'd persisted with trying to find a common understanding that we could
base a real solution on, well past the point where the discussion had
become circular and repetitive, before ultimately becoming resigned to
the horrible stalemate which occurs when what you're arguing against
has devolved to a stubborn insistence that "your suggestion is not
simpler than chmod 777".

Until the discussion can move beyond that to recognise the problem,
our options were always going to be limited.


> 2) allow an upload which removes the offending CGI bit (which users
>don't really care about anyway)

If it was actually true that "users don't care about it", then it
shouldn't be a problem to get upstream to remove it.

But obviously that hasn't happened (or we wouldn't be having this
discussion), and when I last floated that option in one of the
re-runs of this, upstream outright rejected it too:
https://lists.debian.org/debian-project/2013/06/msg00174.html

The only thing he was interested in getting rid of was the option
to actually run this securely, with an audited system-wide script.
Not the parts where his own documentation and code comments say
things like "if you put this on the public internet, you lose", or
the part where he expects the CGI script must be installed in the
same tree as the rest of the generated page content.


It is true (in my opinion) that doxygen now does a much better job
of this than htags does, and that it would be no great loss (again
to me) for htags to just be killed completely if it can't be made
sane and safe.  But I think it's a big stretch to claim that is
some sort of universal consensus, and that if we removed it, then
we wouldn't just end up right back here again with someone seeking
to override the maintainer to put it back, because it is essential
functionality to them, even if the people pleading here now don't
care about it.

htags is essentially useless without the CGI support, since that
is how it accesses the global tags to provide search and indexing.
You really would be far better off just using doxygen and its
search facility that doesn't require a CGI.

But someone cares about this, because doxygen itself got a patch
to let it use htags instead of its own source browser ...  (whether
anyone actually uses that I'll leave as an exercise for someone
to research and report back to us on).

So if what you really want to do is kill htags completely, then
that's a discussion I'm willing to listen to, but it's going to
take some evidence of a genuinely stronger consensus than an
off the cuff "I don't care if we do that" - since you haven't so
far told us which bits you _do_ use and care about, so it's a bit
arbitrary to declare you, or some subset of what global currently
includes, more important than anyone else in a "rob peter to pay
paul" decision scenario.


> 3) write something to change the local behaviour to be satisfactory.

I wrote something to do this in 1999.  The fundamental problem is
itself nearly old enough to drink in pubs.  And I've maintained it for
as long as doing that was possible - but upstream has now gratuitously
broken the interfaces that we added back then (with his agreement and
collaboration and blessing) which enabled this to be done in a sane and
secure way - so the only alternative to nuking htags if upstream is
actively hostile to that now is to fork completely from upstream ...
which is essentially what has happened by sitting on the stable version
we currently have.

Yes, it sucks.  But unless somebody else can convince 

Bug#628843: Casual

[Salomon Polanco]

Hola.

-- 
Atentamente

  Salomón Polanco

Bug#719330: [Debian-science-sagemath] Jmol transition?

[Ximin Luo]

(re-add Andreas and the bug CC address)

OK, here's what I've explored so far:

First you need to svn clone jspecview and jsmol and put them into the parent 
directory of jmol. You need to find the right revisions corresponding to a 
particular Jmol release, it's not too hard but needlessly time-consuming.

Then you can manually call ant in each of these subprojects. JSpecView is quite 
easy to build, but JSmol is very hard because it uses java2script, an eclipse 
plugin. As part of the build process you're supposed to configure your eclipse 
with this plugin, then it will do some stuff. I haven't managed to figure out 
exactly what yet, because eclipse is old in Debian.

java2script is here: https://github.com/zhourenjian/java2script/ and the author 
makes binary releases sometimes on the Google Groups forums: 
https://groups.google.com/forum/#!forum/java2script

I've asked about whether it's possible to run this outside of Eclipse, but I 
think the chances are quite slim for that: 
https://github.com/zhourenjian/java2script/issues/5

X

Ximin Luo:
> I updated libnaga-java to 3.0 in Debian. However Jmol itself is not possible 
> to package.
> 
> I've filed a bug about it here:
> 
> https://sourceforge.net/p/jmol/bugs/587/
> 
> Let's see how they respond...
> 
> Also I was wrong about "it hasn't been updated in years", that was just due 
> to debian/watch being out-of-date and not detecting the new versions. Looks 
> like it's still pretty active.
> 
> X
> 
> François Bissey:
>> That package traditionally gave me a lot of troubles. Because
>> I am not a java guy and none of my occasional helpers is either.
>> As it is jmol has three main elements as I see it 
>> jspecview a separate package
>> jmol proper
>> jsmol a javascript version of jmol produced from jmol.
>> Plus some other smaller java dependencies. jsmol as far as I
>> can see is difficult to produce from source on linux - I think
>> upstream uses a windows program to “compile it”.
>> So lately I just shipped jmol as a binary package. 
>>
>> François
>>


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

Bug#841488: [Pkg-nginx-maintainers] Bug#841488: improve suggested php config

[Michael Lustfield]

> In snippets/fastcgi-php.conf, url:s like /index.php/some/path are 
> correctly split into /index.php and /some/path. But the suggested php 
> config in sites-available/default has the following line that can't 
> match /index.php/some/path:
> 
> location ~ \.php$ {
> 
> Please change that line to:
> 
> location ~ \.php($|/) {

Heh, that's funny. The former is an explicit preference. It was originally put
there in order to prevent the exact character you're trying to insert. This is
because of issues with PATH_INFO if the path information isn't properly split.

This is a topic discussed in depth elsewhere.

> It would also be nice to mention adding index.php to index directive in 
> the FastCGI section. There is comment above the index directive but I 
> didn't see it at first and probably many others are also too focused on 
> the fastcgi section and expect their php application to just work after 
> commenting out the fastcgi directives.
> 
> I think it would be clearer if the following line is removed from 
> sites-available/default:
> 
> # Add index.php to the list if you are using PHP
> 
> And the following lines is added after "# pass PHP scripts to FastCGI 
> server":
> 
> # (usually you also need to add index.php to the index directive above)

I'm not sure how this would provide a less confusing base configuration. If we
move the index directive, it becomes further buried. If we duplicate it, well,
that's just silly.

> And related to #841230, please replace "php5" with "php7.0" also in the 
> comments :-)

I'm more inclined to simply drop the number. It does nothing to help with
understanding that section.

Bug#841676: samba: Samba segfaults for unknown reason

[Jehster]

Package: samba
Version: 2:4.2.10+dfsg-0+deb8u3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   Normal usage from a Windows client. When navigating into a SMB directory,
   client gets error message "permission denied" or similar. Must restart smb
   deamons on server to recover.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 3.16.0-4-686-pae (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/bash
Init: systemd (via /run/systemd/system)

Versions of packages samba depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.17.27
ii  libbsd0  0.7.0-2
ii  libc62.19-18+deb8u6
ii  libhdb9-heimdal [heimdal-hdb-api-8]  1.6~rc2+dfsg-9
ii  libldb1  2:1.1.20-0+deb8u1
ii  libpam-modules   1.1.8-3.1+deb8u1+b1
ii  libpam-runtime   1.1.8-3.1+deb8u1
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.9-2+deb8u1
ii  libtalloc2   2.1.2-0+deb8u1
ii  libtdb1  1.3.6-0+deb8u1
ii  libtevent0   0.9.25-0+deb8u1
ii  lsb-base 4.1+Debian13+nmu1
ii  multiarch-support2.19-18+deb8u6
ii  procps   2:3.3.9-9
ii  python   2.7.9-1
ii  python-dnspython 1.12.0-1
ii  python-ntdb  1.0-5
ii  python-samba 2:4.2.10+dfsg-0+deb8u3
pn  python2.7:any
ii  samba-common 2:4.2.10+dfsg-0+deb8u3
ii  samba-common-bin 2:4.2.10+dfsg-0+deb8u3
ii  samba-dsdb-modules   2:4.2.10+dfsg-0+deb8u3
ii  samba-libs   2:4.2.10+dfsg-0+deb8u3
ii  tdb-tools1.3.6-0+deb8u1
ii  update-inetd 4.43

Versions of packages samba recommends:
ii  attr   1:2.4.47-2
ii  logrotate  3.8.7-1+b1
ii  samba-vfs-modules  2:4.2.10+dfsg-0+deb8u3

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.6.p5+dfsg-7+deb8u2
pn  smbldap-tools  
pn  winbind

-- debconf information:
  samba-common/title:
  samba/run_mode: daemons

Bug#841675: network-manager: A start job is running for Network Manager (x / 1min30sec)

[Saurabh Mishra]

Package: network-manager
Version: 1.4.2-1+b1
Severity: important

Dear Maintainer,

Did a fresh install of debian with Debian desktop environment and standard
system utilities.
Looked up for a solution on many links, but couldn't find the right solution.

Re-installed debian (currently the only OS on my machine) with GNOME desktop
environment, but still getting the same problem.

I am required to wait for 1min 30sec before I can login to the GNOME desktop.
Also updated to the latest packages, but still getting the same message.



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

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

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.12-1
ii  init-system-helpers1.45
ii  libaudit1  1:2.6.7-1
ii  libbluetooth3  5.36-1+b3
ii  libc6  2.24-3
ii  libglib2.0-0   2.50.1-1
ii  libgnutls303.5.5-2
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.6.2-1
ii  libndp01.6-1
ii  libnewt0.520.52.19-1
ii  libnl-3-2003.2.27-1
ii  libnm0 1.4.2-1+b1
ii  libpam-systemd 231-9
ii  libpolkit-agent-1-00.105-16
ii  libpolkit-gobject-1-0  0.105-16
ii  libreadline7   7.0-1
ii  libselinux12.5-3
ii  libsoup2.4-1   2.56.0-1
ii  libsystemd0231-9
ii  libteamdctl0   1.26-1
ii  libuuid1   2.28.2-1
ii  lsb-base   9.20160629
ii  policykit-10.105-16
ii  udev   231-9
ii  wpasupplicant  2.5-2+v2.4-3+b1

Versions of packages network-manager recommends:
ii  crda 3.13-1+b1
ii  dnsmasq-base 2.76-4
ii  iptables 1.6.0-4
ii  iputils-arping   3:20150815-2
ii  isc-dhcp-client  4.3.5~b1-1
ii  modemmanager 1.6.2-1
ii  ppp  2.4.7-1+3

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

Bug#832566: systemd-machined breaks automounting nfs shares

[Michael Biebl]

Am 27.07.2016 um 02:59 schrieb John Pearson:
> Hello Michael,
> 
> After the problem first occurred I reviewed bug #767468 and purged both
> cgmanager and sytemd-shim, but the problem remained.  And, of course,
> /proc shows systemd-machined (and only systemd-machined) still "thought"
> /nfs/home was mounted.

Why is systemd-machined running? Do you have any systemd-nspawn
containers running where /home is symlinked or bind-mounted?

If you stop systemd-machined, is the problem gone?


-- 
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#841665: boinc-client: The boinc-client init script has a badly constructed parameter for xhost

[Preston Maness]

Howdy,

So far as I know, the systemd init system uses the .service file, which
doesn't use the old boinc init script:

/etc/systemd/system/multi-user.target.wants/boinc-client.service

The current method for granting access to the Xserver for boinc is to
drop a file here:

/etc/X11/Xsession.d/36x11-common_xhost-boinc

which does follow the recommended xhost command format:

```
BOINC_USER=boinc

if type xhost >/dev/null 2>&1; then
  id -u $BOINC_USER >/dev/null 2>&1 && xhost +SI:localuser:$BOINC_USER || :
fi
```

That file is sourced and ran whenever a display manager invokes an Xorg
session. On my machine with systemd, this is my xhost output:

```
$ xhost
access control enabled, only authorized clients can connect
SI:localuser:boinc
SI:localuser:preston
$
```

I'm guessing that non-systemd users are probably still using the init
script though, so we should still address this in any case.

Cheers,

Preston Maness

On 10/21/2016 03:42 PM, Mike Brennan wrote:
> Package: boinc-client
> Version: 7.6.33+dfsg-1~bpo8+1
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Dear Maintainers,
> 
> boinc-client shell script is used by init/systemd to start the boinc client 
> daemon (typically running as user=boinc)
> 
> In order for boinc to access GPU hardware -  xhost is used to grant access to 
> boinc.
> 
> At line 109-110
> ---
> # grant the boinc client to perform GPU computing
>xhost local:boinc || echo -n "xhost error ignored, GPU computing may 
> not be possible"
> 
> 
> the correct syntax stould be 
>xhost +si:localuser:boinc
> or more correctly for the this script
>xhost +si:localuser:$BOINC_USER
> 
> The impact of using this incorrect syntax - is not to error, but grant ALL 
> local users access.  
> (This could be a very old or different maybe BSD syntax)
> 
> The intention of the script to grant ONLY user=boinc access, instead all 
> local users have access.
> 
> For example a little test.
> 
> agentb@dejon:/etc/init.d$ xhost
> access control enabled, only authorized clients can connect
> SI:localuser:agentb
> 
> agentb@dejon:/etc/init.d$ xhost local:random-string
> non-network local connections being added to access control list
> 
> agentb@dejon:/etc/init.d$ xhost
> access control enabled, only authorized clients can connect
> LOCAL:
> SI:localuser:boinc
> SI:localuser:agentb
> 
> Hope this is clear, and thank you for maintaining boinc!
> 
> Cheers
> Mike
> 
> 
> -- Package-specific info:
> -- Contents of /etc/default/boinc-client:
> # This file is /etc/default/boinc-client, it is a configuration file for the
> # /etc/init.d/boinc-client init script.
> 
> # Set this to 1 to enable and to 0 to disable the init script.
> ENABLED="1"
> 
> # Set this to 1 to enable advanced scheduling of the BOINC core client and
> # all its sub-processes (reduces the impact of BOINC on the system's
> # performance).
> SCHEDULE="1"
> 
> # The BOINC core client will be started with the permissions of this user.
> BOINC_USER="boinc"
> 
> # This is the data directory of the BOINC core client.
> BOINC_DIR="/var/lib/boinc-client"
> 
> # This is the location of the BOINC core client, that the init script uses.
> # If you do not want to use the client program provided by the boinc-client
> # package, you can specify here an alternative client program.
> #BOINC_CLIENT="/usr/local/bin/boinc"
> BOINC_CLIENT="/usr/bin/boinc"
> 
> # Here you can specify additional options to pass to the BOINC core client.
> # Type 'boinc --help' or 'man boinc' for a full summary of allowed options.
> #BOINC_OPTS="--allow_remote_gui_rpc"
> BOINC_OPTS=""
> 
> # Scheduling options
> 
> # Set SCHEDULE="0" if prefering to run with upstream default priority
> # settings.
> 
> # Nice levels. When systems are truly busy, e.g. because of too many active
> # scientific applications started by the boinc client, there is a chance for
> # the boinc client not to be granted sufficient opportunity to check for
> # scientific applications to be alive and make the (wrong) decision to
> # terminate the scientific app. This is particularly an issue with many
> # apps started in parallel on modern multi-core systems and extra overheads
> # for the download and uploads of files with the project servers. Another
> # concern is the latency for scientific applications to communicate with the
> # graphics card, which should be low. All such values should be set and
> # controled from within the BOINC client. The Debian init script also sets
> # extra constrains via chrt on real time performance and via ionice on 
> # I/O performance, which is beyond the regular BOINC client. It then was
> # too easy to use that code to also constrain minimal nice levels. We still
> # think about how to best distinguish GPU applications from regular apps.
> 

Bug#837642: systemd-journald: "current limit" is wrong, SystemMaxUse and SystemKeepFree is not being respected

[Michael Biebl]

Am 13.09.2016 um 11:21 schrieb Vektor:
> Package: systemd
> Version: 215-17+deb8u4
> Severity: important
> 
> Dear Maintainer,
> 
> systemd-journald is deleting log messages when it shouldn't, it is not 
> respecting SystemMaxUse and SystemKeepFree as configured in 
> /etc/systemd/journald.conf
> 
>* What led up to the situation?
> editing /etc/systemd/journald.conf
> Storage=persistent
> SystemMaxUse=750M
> SystemKeepFree=50M
> 
> This is the current state of disk space:
> $ df -h
> DateisystemGröße Benutzt Verf. Verw% Eingehängt auf
> /dev/sda1   4,6G3,9G  424M   91% /
> 
>* What was the outcome of this action?
> $ systemctl status systemd-journald
> systemd-journal[1086]: Permanent journal is using 504.1M (max allowed 750.0M, 
> trying to leave 50.0M free of 451.2M available → current limit 504.1M)
> 

Can you still reproduce the problem with v231 from unstable? There were
quite a few journald related fixes since v215.

In this case I would forward the issue to upstream.
As for the jessie version, this issue is not important enough for a
stable upload.

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#832010: Please enable LZ4 compression

[Michael Biebl]

Am 22.07.2016 um 00:28 schrieb Yuri D'Elia:
> On Fri, Jul 22 2016, Michael Biebl  wrote:
>> So, this is the main reason I'm worried about enabling lz4 support.
>> Afair, it's not runtime configurable, so each new journal entry would be
>> lz4 compressed, which effectively means we will have to use lz4 forever
>> (which has quite a considerable worse compression).
> 
> Depending on the scenario, the performance of XZ might be inadequate
> though.
> 
> For coredump I had to disable compression to avoid a nosedive in
> performance at each crash. Even though LZ4 is not optimal, it still
> makes a great difference compared to no compression, especially for core
> files, and it's an "accepted" tradeoff for this kind of scenario.
> 
> I initially filed an RFE directly upstream to request LZ4, only to
> discover it was already a new default but not available in debian.

Is it possible to enable lz4 for coredumps only?

Felipe's argument about apt already pulling in libz4 makes me less
concerned, fwiw, as we wouldn't introduce yet another new dependency in
the "base" system.


-- 
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#812215: consider spliting systemd-tmpfiles into separate package

[Michael Biebl]

Am 01.02.2016 um 16:41 schrieb Josh Triplett:
> On Mon, Feb 01, 2016 at 04:24:21PM +0100, Ondřej Surý wrote:
>> Hi Michael,
>>
>> I never bothered to implement more than 'd', but I am happy to
>> contribute my sysvrc shell snippet I use as replacement for systems
>> without systemd-tmpfiles installed. 
..
>> It should be fairly easy to implement the most common stuff used in
>> Debian.
> 
> Implementing the various operation letters makes up half the problem.
> The other half involves handling the various tmpfiles.d directories and
> the precedence between them.  That includes the usual "override files
> with the same filename" mechanism, but also:


Fwiw, I was told that openrc ships a tmpfiles implementation.
I get
# apt-file list openrc | grep tmp
openrc: /lib/rc/sh/tmpfiles.sh

No idea how complete that implementation is, though.

-- 
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#836580: systemd: systemctl status pipes through less with escape sequences not applied

[Michael Biebl]

Control: reassign -1 zsh 5.2-5

Am 26.09.2016 um 23:11 schrieb Martin Steigerwald:
> Am Montag, 26. September 2016, 13:53:21 CEST schrieb Josh Triplett:
>> On Mon, Sep 26, 2016 at 10:27:40PM +0200, Martin Steigerwald wrote:
>>> Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett:
 On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote:
> Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett:
>> On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald
>> 
>
> wrote:
>>> Package: systemd
>>> Version: 231-5
>>> Severity: minor
>>>
>>> Dear Martin, dear Michael, dear Systemd maintainers,
>>>
>>> systemctl status for a long time just printed the status directly
>>> onto
>>> the
>>> terminal (Konsole in my case). But since also quite a while it
>>> uses
>>> less
>>> on
>>> my system, even tough the output is not larger than one page.
>>>
>>> Also the color escape sequences are not executed by less, leavinge
>>> me
>>> with
>>> something like:
>>>
>>> ^[[0;1;32m●^[[0m atopacct.service - Atop process accounting
>>> daemon
>>>
>>>Loaded: loaded (/lib/systemd/system/atopacct.service; enabled;
>>>vendor
>>>preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since
>>>So
>>>2016-09-04 10:48:07 CEST; 1s ago>
>>>
>>>  Docs: man:atopacctd(8)
>>>   
>>>   Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited,
>>>   status=0/SUCCESS)
>>>  
>>>  Main PID: 5034 (atopacctd)
>>>  
>>> Tasks: 1 (limit: 4915)
>>>
>>>CGroup: /system.slice/atopacct.service
>>>
>>>└─5034 /usr/sbin/atopacctd
>>>
>>> Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process
>>> accounting
>>> daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service:
>>> PID
>>> file
>>> /run/atopacctd.pid not readable (yet?) after start: No such file
>>> or
>>> directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3
>>> -
>>> 2015/06/25 11:07:21 […] Sep 04 10:48:07 merkaba systemd[1]:
>>> Started
>>> Atop process accounting daemon. Sep 04 10:48:07 merkaba
>>> atopacctd[5034]:
>>> ^[[0;1;39mreactivate process accounting^[[0m
>>
>> Works fine here with systemd 231-5: "systemctl status" uses less,
>> but it
>> interprets color escape sequences, and exits if the output fits
>> entirely
>> on the screen.  Can you provide your environment (output of "env"),
>> and
>> in particular the values of $LESS and $PAGER?  And can you check if
>> this
>> occurs in another terminal, such as xterm?
>
> Thanks for your answer Josh. I missed it first seems it was sortet
> more
> downwards due to old date:
>
>
> merkaba:~> systemctl status
> merkaba:~> echo $LESS
>
>  -w
>
> merkaba:~> echo $PAGER
>
> I do not know who has put that "-w" into LESS variable.
>
> But removing it doesn´t help:
>
> merkaba:~> unset LESS
> merkaba:~> systemctl status
> ^[[0;1;31m●^[[0m merkaba
>
> State: ^[[0;1;31mdegraded^[[0m
> 
>  Jobs: 0 queued
>
>Failed: 2 units
>
> Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago
>
>CGroup: /
>
> Same in xterm.
>
> merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64
> less:amd64/sid 481-2.1 uptodate
> systemd:amd64/sid 231-7 uptodate

 What happens if you explicitly export LESS=R ?  Does that help?
>>>
>>> No.
>>>
 Try running the following in your terminal:

 /usr/bin/printf '\e[0;1;31mRED\e[0m'

 Does the word "RED" show up in red?
>>>
>>> Yes.
>>>
 Also try this:

 /usr/bin/printf '\e[2J'

 Does that clear your screen?
>>>
>>> Yes.
>>>
>>> Okay, I think I found something:
>>>
>>> martin@merkaba:~> echo $SHELL
>>> /usr/bin/zsh
>>> martin@merkaba:~> systemctl status
>>>
>>> ^[[0;1;31m●^[[0m merkaba
>>>
>>> State: ^[[0;1;31mdegraded^[[0m
>>> 
>>>  Jobs: 0 queued
>>>
>>>Failed: 2 units
>>>
>>> But:
>>>
>>>
>>> martin@merkaba:~> bash
>>> martin@merkaba:~ -> systemctl status
>>>
>>> ● merkaba
>>>
>>> State: degraded
>>> 
>>>  Jobs: 0 queued
>>>
>>>Failed: 2 units
>>>
>>> The red dot and degraded are in red.
>>>
>>>
>>> So seems some interaction with Z-Shell, that leads to broken escape
>>> sequences.
>>>
>>> I use zsh 5.2-5.
>>
>> Ah, interesting.  Perhaps zsh puts the terminal into an unexpected mode
>> somehow?
>>
>> Can you run zsh with whatever options cause it to ignore all your shell
>> configuration and startup files?  Does that fix the problem?
>>
>> If the *default* configuration of zsh causes this bug, I'd suggest
>> reassigning this bug to zsh.
> 
> Hmmm, no 

Bug#830775: systemd: systemctl poweroff ask me twice for user and password.

[Michael Biebl]

Control: tags -1 - moreinfo
Control: forwarded -1 https://github.com/systemd/systemd/issues/4124

Am 11.07.2016 um 14:33 schrieb Pavel Kosina:
> Its ssh, putty,
> 
> dady@linuxbox:~$ systemctl poweroff
>  AUTHENTICATING FOR org.freedesktop.login1.set-wall-message ===
> Authentication is required to set a wall message
> Multiple identities can be used for authentication:
>  1.  ,,, (dady)
>  2.  ,,, (danca)
> Choose identity to authenticate as (1-2): 1
> Password:
>  AUTHENTICATION COMPLETE ===
>  AUTHENTICATING FOR org.freedesktop.login1.power-off ===
> Authentication is required for powering off the system.
> Multiple identities can be used for authentication:
>  1.  ,,, (dady)
>  2.  ,,, (danca)
> Choose identity to authenticate as (1-2): Failed to power off system via
> logind: Spojení bylo přílií
> Failed to start poweroff.target: Spojení bylo příliš dlouho neaktivní
> See system logs and 'systemctl status poweroff.target' for details.

Ok, so it's not a local user. So the password prompt is expected.
It then prompts you for two separate actions:
Setting the wall message and the actual poweroff

This particular issue is already known and tracked upstream. Marking
accordingly.

-- 
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#836412: Give back qtwebchannel on mips, powerpc, hppa

[Sandro Knauß]

Hey,

after the issue is fixed in qtdeclerative, the test for qtwebchannel should now 
run successfully, so please give back.

gb qtdeclarative-opensource-src_5.6.1-1 . mips powerpc hppa

Best regards,

Sandro

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

Bug#840475: systemd-logind: systemd-logind stuck in a restart loop

[Michael Biebl]

Control: forcemerge 839607 -1
Am 11.10.2016 um 23:43 schrieb Keller Fuchs:
> Package: systemd
> Version: 215-17+deb8u4
> Severity: important
> File: systemd-logind
> 
> Dear maintainers,
> 
> On a shell server I co-administer (to1.hashbang.sh), systemd-logind got
> stuck in a restart loop, forcing us to reboot the system.
> 
> logind not working is problematic, both due to the loss of functionality
> and due to pam_systemd having to wait for timeout.
> 
> 
> Here are the journal contents for unit systemd-journald:
> 
>> [seemingly working fine until that point]
>> Oct 11 01:34:27 to1 systemd[1]: systemd-logind.service watchdog timeout 
>> (limit 1min)!

Did someone trigger the systemd-notify bug?
This sounds like it could be a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839607

Any user with shell access could be able to trigger the empty
systemd-notify message.
The result is exactly what you see, systemd-logind being killed by the
watchdog. journald seems to be in a failed state as well.
So I assume this is the same issue and will merge the two bug reports.






-- 
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#835464: udev: Modules no longer loaded

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 26.08.2016 um 02:53 schrieb Jean-Philippe MENGUAL:
> Package: udev
> Version: 231-4
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I updated my testing.

Where there other packages updated as well?
Are you sure this is related to a systemd update?
Can you downgrade to a previous version (from snapshot.debian.org)

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Reboot the system.
> 
>* What was the outcome of this action?
> 
> After boot:
> - not beeper anymore;
> - not soundcard anymore
> - not wifi anymore
> 
> lsmod: no modules loaded, related to them. But others are.
> 

Which modules exactly are not loaded?
Can you attach the output of
lsmod
journalctl -alb



-- 
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#841674: src:cupp: should only provide one application implementation

[Ben Finney]

Package: src:cupp
Version: 0.0+20160624.git07f9b8-1
Severity: minor
Control: tags + patch

The application package ‘cupp’ is for use at the command line; it does
not install a package targeted to Python programmers.

So for users of this package, it does not matter what the
implementation language is; and there is no clear benefit to providing
a Python 2 *and* Python 3 implementation of the application in Debian.

Instead, ‘cupp’ should install exactly one implementation, the Python
3 one; and there is no need to provide a Python 2 implementation also.

My suggested changes to achieve this are in the branch at

(in the repository ).

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\   Brain, but where are we going to find a duck and a hose at this |
_o__)hour?” —_Pinky and The Brain_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#837562: Pending fixes for bugs in the libembperl-perl package

[pkg-perl-maintainers]

tag 837562 + pending
thanks

Some bugs in the libembperl-perl package are closed in revision
541b0e9c6d9f88c7ca1929866d2e7effd13c388f in branch 'master' by
Florian Schlichting

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

Commit message:

Opt out of bindow (closes: #837562)

quoting Niko from the bug:

My understanding is that the Apache module parts (mod_embperl) get
compiled into Embperl.so, but don't get used unless the thing is loaded
by Apache. The 'bindnow' hardening is incompatible with this scheme;
from the ld(1) documentation for '-z now':

  When generating an executable or shared library, mark it to tell the
  dynamic linker to resolve all symbols when the program is started, or
  when the shared library is linked to using dlopen, instead of deferring
  function call resolution to the point when the function is first called.

So when perl dlopens Embperl.so without Apache, the ap_* functions
aren't needed but still get loaded (unsuccessfully).

Bug#841672: Please package latest upstream release

[Michael Biebl]

Source: accountsservice
Version: 0.6.40-3
Severity: normal

Hi Alessio,

the latest upstream release 0.4.43 seems to have a bunch of nice fixes
and improvements. Would be great to have an update to get these into
stretch before the freeze.

Regards,
Michael

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

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

-- no debconf information

Bug#841673: ITP: node-randombytes -- random bytes from browserify stand alone

[Sarath M S]

Package: wnpp
Severity: wishlist
Owner: Sarath M S 

* Package name: node-randombytes
  Version : 2.0.3
  Upstream Author : Calvin Metcalf 
* URL : https://github.com/crypto-browserify/randombytes
* License : Expat
  Programming Lang: JavaScript
  Description : random bytes from browserify stand alone

 randomBytes for the brower. Uses crypto/msCrypto.getRandomValues() in
 the browser. In node, it uses crypto.randomBytes()
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#841671: pbbam: Fix for building with -Wl,--as-needed

[Steve Langasek]

Package: pbbam
Version: 0.5.0-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Hi Afif,

In Ubuntu, pbbam was failing to build because when linking libpbbam.so, the
library arguments were listed on the commandline before the objects being
linked.  Ubuntu uses -Wl,--as-needed in its linker arguments, which causes
libraries that aren't used to be ignored; and so libraries listed before the
objects that use them are not linked against.

You can read more about this behavior here:

  https://wiki.ubuntu.com/ToolChain/CompilerFlags#Flags_passed_to_the_linker

I've applied a small patch in Ubuntu to fix this, with the following
changelog explanation:

  * debian/rules: fix cmake arguments so that library arguments are in the
right order for -Wl,--as-needed.

While Debian does not currently use -Wl,--as-needed by default and this is
not a build issue in Debian, applying this patch will make your package more
portable in general.  Please consider applying it.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pbbam-0.5.0/debian/rules pbbam-0.5.0/debian/rules
--- pbbam-0.5.0/debian/rules	2016-07-05 02:49:29.0 -0700
+++ pbbam-0.5.0/debian/rules	2016-10-21 16:16:40.0 -0700
@@ -16,8 +16,8 @@
 	-DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) \
 	-DCMAKE_SKIP_RPATH=ON \
 	-DHTSLIB_INCLUDE_DIRS=/usr/include \
-	-DHTSLIB_LIBRARIES=/usr/lib \
-	-DCMAKE_SHARED_LINKER_FLAGS="-lssl -lhts $(LDFLAGS)"
+	-DHTSLIB_LIBRARIES="-lssl -lcrypto -lhts" \
+	-DCMAKE_SHARED_LINKER_FLAGS="$(LDFLAGS)"
 #	-DPacBioBAM_wrap_python=ON \
 #	-DPacBioBAM_wrap_r=ON
 

Bug#841438: --enable-default-pie breaks kernel build on amd64

[Bálint Réczey]

Dear Ubuntu Developers,

Have you tried upstreaming the patch? It would be a great help.

Cheers,
Balint


2016-10-20 19:05 GMT+02:00 Gianfranco Costamagna :
> control: severity -1 normal
> control: reassign -1 src:linux
> control: affects -1 gcc-6
>
> Hi Linux Kernel maintainers,
> as you already know, the default PIE flag breaks the kernel build, can I 
> suggest you to apply a similar patch
> to the one that Ubuntu appplied some time ago?
> https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1574982/comments/39
>
> --- a/Makefile
> +++ b/Makefile
> @@ -612,6 +612,12 @@ endif # $(dot-config)
>  # Defaults to vmlinux, but the arch makefile usually adds further targets
>  all: vmlinux
>
> +# force no-pie for distro compilers that enable pie by default
> +KBUILD_CFLAGS += $(call cc-option, -fno-pie)
> +KBUILD_CFLAGS += $(call cc-option, -no-pie)
> +KBUILD_AFLAGS += $(call cc-option, -fno-pie)
> +KBUILD_CPPFLAGS += $(call cc-option, -fno-pie)
> +
>  # The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
>  # values of the respective KBUILD_* variables
>  ARCH_CPPFLAGS :=
>
> thanks
>
> Gianfranco
>

Bug#835148: Bug#837420: Bug#835148: please do not make GCC incompatible, we have dpkg-buildflags for this! (was Re: Bug#837420: Processed: PIE FTBFS are now RC)

[Bálint Réczey]

Hi,

2016-10-22 1:00 GMT+02:00 Thorsten Glaser :
> Bálint Réczey dixit:
>
>>AFAIK the linux package is the only problematic package were the
>>maintainer refused to disable PIE from packaging scripts.
>
> So, how are you supposed to do that now, instead of filtering
> -fPIE from CFLAGS and -pie from LDFLAGS?

This reverts defaulting to no-PIE:
CC = $(CC) -no-pie
LD = $(LD) -no-pie

Very often appending -no-pie works, too, but not when compiling shared
libraries.
See:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464

If you show the FTBFS you are facing I can help more.

Cheers,
Balint

>
> Christian/zumbi: do you take care of dietlibc, or should I?
>
> Thanks,
> //mirabilos
> --
> Stéphane, I actually don’t block Googlemail, they’re just too utterly
> stupid to successfully deliver to me (or anyone else using Greylisting
> and not whitelisting their ranges). Same for a few other providers such
> as Hotmail. Some spammers (Yahoo) I do block.

Bug#780275: pkexec: Synpatic & gParted fails to authenicate

[Thomas McAtee Jr]

On Fri, 21 Oct 2016 05:14:58 +0200 Michael Biebl  wrote:
> Control: tags -1 + moreinfo unreproducible
>
> On Wed, 11 Mar 2015 07:26:11 -0700 Thomas McAtee
>  wrote:
> > Package: pkexec
> > Version: policykit
> > Severity: important
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where 
appropriate ***

> >
> > * What led up to the situation?
> > Found when going to check Synaptic Package manager. Tested gparted 
afterwards
> > with same result. This is in Jessie 32bit on desktop and Wheezy 
32bit on

> > laptop. Wheezy 32bit on desktop seems to be ok for moment. I use XFCE.
> > * What exactly did you do (or not do) that was effective (or
> > ineffective)?
> > Created personal launchers using gksu on the two so I could use them.
> > * What was the outcome of this action?
> > That works for time being but still have issues when trying to sign 
in with

> > regular login screens for the two.
> >
> > * What outcome did you expect instead?
> > Was waiting to see if an upgrade caused this and newer one would 
fix issue.

>
> What is the exact error message(s) you get?
> Do you have anything in /var/log/auth.log?
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

To be honest this appears to have been fixed at the moment. I have just 
gone into the applications/settings/synaptic and was just able to open 
this way now. I then tried again with the gparted. Same results. Before 
every time I would try to log into either one I was getting the login 
screen back to me. I had created a launcher for the two of them so that 
I would be able to login to the Synaptic and gParted and thus bypass 
going to do so the other way. Seems that the issue had been fixed.


Tom McAtee

--
Open Source is wonderful use it.
http://osalt.com/
http://distrowatch.com/
http://openlinuxforums.org/

Desktop:
Debian Testing
Debian Stable

Laptop
LMDE MATE with KDE
Debian Mate

Bug#835148: Bug#837420: Bug#835148: please do not make GCC incompatible, we have dpkg-buildflags for this! (was Re: Bug#837420: Processed: PIE FTBFS are now RC)

[Thorsten Glaser]

Bálint Réczey dixit:

>AFAIK the linux package is the only problematic package were the
>maintainer refused to disable PIE from packaging scripts.

So, how are you supposed to do that now, instead of filtering
-fPIE from CFLAGS and -pie from LDFLAGS?

Christian/zumbi: do you take care of dietlibc, or should I?

Thanks,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#841670: lintian: Check udev rules and AppStream metadata

[Petter Reinholdtsen]

Package: lintian
Version: 2.5.48

Hi.  Isenkram uses information from AppStream to locate packages
relevant for the hardware present on a given computer.  I would like to
have some lintian checks verifying the AppStream metadata and the udev
rules to try to detect if a package providing access for given user
accessible device will work as it should after AppStream install it, and
to make sure AppStream will know the package is relevant for some
specific hardware.

I'm working on a patch for this.  So far my first draft is in
https://github.com/petterreinholdtsen/lintian/tree/appstream-metadata >.

It still need more work before I am confident the checks make sense.  I
just wanted to let you know about my work in case others are also
looking into lintian checks for udev rules and/or AppStream metadata.

--
Happy hacking
Petter Reinholdtsen

Bug#655976: queue-viewer: support binary debdiffs

[Adam D. Barratt]

On Sat, 2016-10-15 at 22:53 +0100, Adam D. Barratt wrote:
> - the output is current plain text, with no formatting

That's now fixed - both HTML and plain text output can be generated.

> - there's no filtering of "interesting" content; all architectures for
> which there are packages have a corresponding binary debdiff link

An initial version of support for this has been deployed.

Currently, "Version:" fields and package dependency fields where the
changes consist purely of switching "old source version" for "new source
version" are automatically removed (with the caveat that only epochless
versions work).

As well as filtering more "boring" content, we also need some way of
indicating that no "interesting" differences were found, in a way that
queue-viewer can detect at runtime.

Adam

Bug#725417: Thanks a lot

[James Cowgill]

Hi,

On 21/10/16 22:36, Santiago Garcia Mantinan wrote:
> Hi!
> 
> I've been preparing a new version of mbr which will change the format and
> not overwrite the disk-id, but I have not finished yet and I don't have time
> lately, so your upload is very welcome.

Great!

If you want, I could reschedule my NMU to skip the delayed queue and go
straight in (I doubt it would make too much difference though).

James



signature.asc
Description: OpenPGP digital signature

Bug#838914: [debian-mysql] Bug#838914: mariadb-10.0: testsuite failures on mips/mipsel

[Kristian Nielsen]

FYI,

James Cowgill  writes:

> mips-machine.patch
> Fix the value of DEFAULT_MACHINE on 32-bit mips platforms.

I've upstreamed this patch, it should appear in MariaDB 10.0.28.

> mips-groonga-atomic.patch
> Link groonga against libatomic as it uses 64-bit atomic operations not
> supported on mips without that helper library.
>
> mips-connect-unaligned.patch
> This is a rather large patch attempting to fix some unaligned memory
> accesses in the CONNECT storage engine which cause bus errors on mips
> (and probably other platforms which prohibit unaligned memory access).

Mroonga and CONNECT are storage engines that I think are developed
independently from MariaDB - ie. MariaDB is not the real upstream. So I've
sent mails on the maria-developers@ list with the patches, asking how these
can be properly upstreamed.

  https://lists.launchpad.net/maria-developers/msg10020.html
  https://lists.launchpad.net/maria-developers/msg10021.html
  
> mips-unstable-tests.patch
> Remove various tests from mysql-test/unstable-tests which now pass on mips.
>
> debian-mips-unstable-tests.patch
> Updates debian/unstable-tests.mips*
> I've added the 'connect.mysql_index' test to the mipsel unstable tests.
> It seems to fail sporadically on mipsel. It usually takes about 5
> retries to fail, but sometimes less. I'm not sure what the cause is here.

I chose not to upstream these two. I'm frankly not too impressed with these
"unstable-tests". Anyway, I think it's fine to carry these patches
separately in Debian for now.

Hope this helps,

 - Kristian.

Bug#782142: systemd: Tries to mount NFS shares twice (?)

[Michael Biebl]

Control: reassign -1 initscripts

On Wed, 8 Apr 2015 13:33:54 +0200 (CEST) Santiago Vila 
wrote:
> Package: systemd
> Version: 215-14
> 
> After a recent upgrade in a lab where I use NFS, I see messages like this:
> 
> ifup[370]: mount.nfs: /home/nfs is busy or already mounted

That hook is shipped by initscripts, thus reassigning.

This hook should be a nop if systemd is active.

-- 
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#837425: deets: FTBFS with bindnow and PIE enabled

[Adrian Bunk]

On Sun, Sep 11, 2016 at 03:50:14PM +0200, Balint Reczey wrote:
> Source: deets
> Version: 0.2.1-4
> Severity: important
> User: bal...@balintreczey.hu
> Usertags: pie-bindnow-20160906
> Justification: FTBFS on amd64 with extra hardening
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64 with patched GCC and dpkg.
> 
> The rebuild tested if packages are ready for a transition
> enabling PIE and bindnow for amd64.
> 
> For more information about the changes to sid's dpkg and GCC please
> visit:
>  https://wiki.debian.org/Hardening/PIEByDefaultTransition
> 
> Relevant part (hopefully):
> ...
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2
> -I/usr/include/lua5.1 -DDEETS_LUADIR=\"
> /usr/share/deets\" -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Wer
> ror=format-security -c -o luau-luau.o `test -f 'luau.c' || echo '../'`luau.c
> ../luau.c: In function 'dpkg_status':
> ../luau.c:88:7: error: 'stat_notinstalled' undeclared (first use in this
> function)
>   case stat_notinstalled:
>...

This works for me in unstable, can you reproduce it?

I have already reproduced that #586572 would cause this kind og build 
failure.

Your log says:
checking for dpkg_set_progname in -ldpkg... no
checking for pkg_status_name in -ldpkg... no

My log says:
checking for dpkg_set_progname in -ldpkg... yes
checking for pkg_status_name in -ldpkg... yes

The part I do not understand is why it works for me since I would
have expected that to fail...

> Thanks,
> Balint

cu
Adrian

-- 

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

Bug#839542: typo: Send/Que command to all matching filters

[Andreas Cadhalpun]

Control: tags -1 fixed-upstream

Hi Mathieu,

On 14.10.2016 08:33, Mathieu Malaterre wrote:
> On Thu, Oct 13, 2016 at 11:29 PM, Andreas Cadhalpun
>  wrote:
>> Thanks for reporting this. I've forwarded the fix upstream together
>> with a couple of other spelling fixes. I hope you don't mind that.
> 
> This is the only way to have it fixed in the long term, so definitely:
> thanks for doing it ! :)

It is now fixed upstream:
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c8a6eb58d7ebc9c1585bc450aa9e0358f6822df0

Best regards,
Andreas

Bug#841669: Acknowledgement (KDE fails to start on kernel 4.7.0-0.bpo.1)

[Alain Knaff]

On 10/21/2016 23:51, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  unknown-pack...@qa.debian.org
> 
> If you wish to submit further information on this problem, please
> send it to 841...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

After googling around for a while I found reports of other people having
similar issues where it was related to multi screen issues.

https://bugs.kde.org/show_bug.cgi?id=367828

I do indeed have 2 screens connected.

However, neither of the 2 screens shows anything.

Moreover, only very few KDE processes are running, so it seems unlikely
that KDE is just being displayed at some non-existant 3rd phantom screen
(much more processes would be running in that case)

Regards,

Alain

Bug#841669: KDE fails to start on kernel 4.7.0-0.bpo.1

[Alain Knaff]

Package: linux-image
Version: 4.7.0-0.bpo.1

Hi,

Just upgraded my kernel from 4.6.0-1 to 4.7.0-1, and after this, KDE
failed to start. It just hung forever at start without even the progress
banner displaying.

After downgrading again to 4.6.0-1, everything was fine (but I have a
suspicion that 4.6.0 will not be patched against dirty cow disease as
4.7.0 is out).

Unfortunately, no meaningful error messages in ~/.xsession-errors

Any ideas?

Thanks,

Alain

Xsession: X session started for alain at Fri Oct 21 23:19:21 CEST 2016
localuser:alain being added to access control list
startkde: Starting up...
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave.
kbuildsycoca4 running...
QThread::start: Thread creation error: Resource temporarily unavailable
QThread::start: Thread creation error: Resource temporarily unavailable
QThread::start: Thread creation error: Resource temporarily unavailable
QThread::start: Thread creation error: Resource temporarily unavailable
QThread::start: Thread creation error: Resource temporarily unavailable

Bug#841660: RFS: budgie-desktop/10.2.8-1

[foss.freedom]

Hi Gianfranco

  quite correct data/icons/* was marked as CC-BY-SA-4.0 in
debian/copyright ... my bad.  Have corrected this to CC-BY-SA-3.0

The "Copyright (C) GNOME Shell Developers (Heavy inspiration, logic
theft)" is the text in wm/keyboard.vala and wm/ibus.vala - both of
these are in the debian/copyright file.  I've now split ikey's
copyright line and "GNOME Shell Developers" onto separate lines in
debian/copyright for both wm/keyboard.vala and wm/ibus.vala

D

On 21 October 2016 at 21:21, Gianfranco Costamagna
 wrote:
> control: tags -1 moreinfo
> control: owner -1 !
>
> Hi,
>
>> dget -x 
>> https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.8-1.dsc
>
>
>>1. I noticed on mentors.debian.net that the watch file failed - this
>>is very strange since nothing has changed for months now - is there a
>>bug on mentors at the moment causing the watch to fail?
>
>
> IIRC yes
>
>
>>2. ran check-all-the-things - this did not find anything new from>previous 
>>uploads
>
>
> ok
>
>>3. ran lintian -i -I on the sources - no new items listed in previous uploads
>
> ok
>
>>- to reiterate - current linitian items are known upstream
>>budgie-desktop.  relnow, bindnow will be resolved once the VALA stuff
>>is recoded to C
>>- rpath is necessary due to upstream GNOME GTK_3.22 private mutter API changes
>>- the patches added are upstream budgie-desktop released since v10.2.8
>>- bugs found after release that are necessary for ibus capability on
>
>>debian/ubuntu
>
> ok
>
>>  Changes since the last upload:
>>
>>  * New upstream release
>>- GTK+3.22 fixes
>>- new places indicator
>>- new ibus indicator
>>- refreshed panel icons
>>- updated translations
>>- general fixes for the desktop
>>  * Packaging changes:
>>- Drop all now obsolete previous patches named 000*
>>- add new build dependency libibus-1.0-dev
>>- Updated debian/copyright with revised info for new source files
>>- add recommendation to install gnome-screensaver; screenlock capability
>>  in budgie-desktop does not work without this package
>>  * add patch upstream patch to allow the ibus applet to compile:
>>  0001-Lower-the-ibus-requirement-to-1.5.11-for-our-Debuntu.patch
>>  * add patch to ensure ibus is connected correctly if already running
>>  0002-wm-ibus-Always-try-to-use-an-existing-ibus-daemon-if.patch
>>
>
>
>
> blockers:
>
> missing licenses (cc-by-sa3.0)
> + * Copyright (C) GNOME Shell Developers (Heavy inspiration, logic theft)
>
> (vala^^)
>
> other stuff seems good
>
> G.

Bug#838557: [debian-mysql] Bug#838557: mariadb-10.0: FTBFS on mips64el

[Kristian Nielsen]

James Cowgill  writes:

>>> Currently mariadb-10.0 FTBFS on mips64el due to various testsuite
>>> failures. The two attached patches should resolve this. I am also

>>> mips-errno-enotempty.patch
>>> On mips* architectures, ENOTEMPTY == 93 which wasn't handled by two test
>>> cases.
>>>
>>> mips64-taocrypt-integer.patch
>>> The previous patch to fix mips64el made the package build, but was
>>> unfortunately completely wrong. I've replaced the code with a generic
>>> implementation using GCC's __int128. It could probably be generalized to
>>> other arches, but I didn't want to break anything.

FYI, I've now upstreamed these two patches. They should appear in 10.0.28.

Thanks!

 - Kristian.

Bug#837659: This bug is actually in ocaml-nox

[Adrian Bunk]

Control: reassign -1 ocaml-nox
Control: affects -1 src:hivex

Relevant part of config.log:

...
configure:30935: checking for function caml_raise_with_args
/usr/bin/ld: /usr/lib/ocaml/libcamlrun.a(stacks.o): relocation 
R_X86_64_32 against `.rodata.str1.8' can not be used when making a 
shared object; recompile with -fPIC
...
/usr/bin/ld: /usr/lib/ocaml/libcamlrun.a(fix_code.o): relocation 
R_X86_64_32 against undefined symbol `caml_code_fragments_table' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
File "_none_", line 1:
Error: Error while building custom runtime system
configure:30949: result: not found
...


cu
Adrian

-- 

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

Bug#725417: Thanks a lot

[Santiago Garcia Mantinan]

Hi!

I've been preparing a new version of mbr which will change the format and
not overwrite the disk-id, but I have not finished yet and I don't have time
lately, so your upload is very welcome.

Thanks again. Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#841668: grok: Fix for wrong pointer aliasing in grok

[Steve Langasek]

Package: grok
Version: 1.20110708.1-4.1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Hi Stig,

While debugging a build failure of syslog-ng-incubator on s390x in Ubuntu,
I've identified a bug in the grok code related to pointer aliasing.  The
regexp_len argument to grok_pattern_find() has been defined as a size_t*,
but this pointer is then passed through to a tokyocabinet API that only
takes an int*, which leaves half of the size_t variable uninitialized on
64-bit architectures.  And on big-endian architectures, crucially, it's the
lower half of the variable that's uninitialized, eventually leading to a
crash.

The attached patch fixes this by explicitly declaring the API to be based on
an int* instead of a size_t*, and fixing the internal callers of
grok_pattern_find().  Note that this is an API change (changing the
prototype of a public function), but is not an ABI change; I'm only changing
the public declaration to match the actual behavior.  Therefore, if there
are other external users of this function which are assuming they can pass
in a size_t* to uninitialized memory and use it afterwards, those callers
will still see buggy behavior.  So you (or upstream) may wish instead to
keep the prototype as-is, and fix up the pointer aliasing within the
function.

Thanks for considering the patch!
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru grok-1.20110708.1/debian/patches/fix_wrong_pointer_alias.patch grok-1.20110708.1/debian/patches/fix_wrong_pointer_alias.patch
--- grok-1.20110708.1/debian/patches/fix_wrong_pointer_alias.patch	1969-12-31 16:00:00.0 -0800
+++ grok-1.20110708.1/debian/patches/fix_wrong_pointer_alias.patch	2016-10-21 14:05:10.0 -0700
@@ -0,0 +1,64 @@
+Description: fix wrong pointer alias
+ size_t * != int *, and casting one to the other without initialization is
+ a good way to get garbage data into your program, leading to crashes such
+ as the one in
+ https://launchpad.net/ubuntu/+source/syslog-ng-incubator/0.5.0-1build1/+build/11039099
+Author: Steve Langasek 
+Forwarded: no
+Last-Update: 2016-10-21
+
+Index: grok-1.20110708.1/grok_pattern.c
+===
+--- grok-1.20110708.1.orig/grok_pattern.c
 grok-1.20110708.1/grok_pattern.c
+@@ -33,9 +33,9 @@
+ }
+ 
+ int grok_pattern_find(const grok_t *grok, const char *name, size_t name_len,
+-  const char **regexp, size_t *regexp_len) {
++  const char **regexp, int *regexp_len) {
+   TCTREE *patterns = grok->patterns;
+-  *regexp = tctreeget(patterns, name, name_len, (int*) regexp_len);
++  *regexp = tctreeget(patterns, name, name_len, regexp_len);
+ 
+   grok_log(grok, LOG_PATTERNS, "Searching for pattern '%s' (%s): %.*s",
+name, *regexp == NULL ? "not found" : "found", *regexp_len, *regexp);
+Index: grok-1.20110708.1/grok_pattern.h
+===
+--- grok-1.20110708.1.orig/grok_pattern.h
 grok-1.20110708.1/grok_pattern.h
+@@ -9,7 +9,7 @@
+ int grok_pattern_add(const grok_t *grok, const char *name, size_t name_len,
+   const char *regexp, size_t regexp_len);
+ int grok_pattern_find(const grok_t *grok, const char *name, size_t name_len,
+-  const char **regexp, size_t *regexp_len);
++  const char **regexp, int *regexp_len);
+ int grok_patterns_import_from_file(const grok_t *grok, const char *filename);
+ int grok_patterns_import_from_string(const grok_t *grok, const char *buffer);
+ 
+Index: grok-1.20110708.1/test/grok_pattern.test.c
+===
+--- grok-1.20110708.1.orig/test/grok_pattern.test.c
 grok-1.20110708.1/test/grok_pattern.test.c
+@@ -4,7 +4,7 @@
+ void test_grok_pattern_add_and_find_work(void) {
+   INIT;
+   const char *regexp = NULL;
+-  size_t len = 0;
++  int len = 0;
+ 
+   grok_pattern_add(, "WORD", 5, "\\w+", 3);
+   grok_pattern_add(, "TEST", 5, "TEST", 4);
+Index: grok-1.20110708.1/grokre.c
+===
+--- grok-1.20110708.1.orig/grokre.c
 grok-1.20110708.1/grokre.c
+@@ -183,7 +183,7 @@
+ int start, end, matchlen;
+ const char *pattern_regex;
+ int patname_len;
+-size_t regexp_len;
++int regexp_len;
+ int pattern_regex_needs_free = 0;
+ 
+ grok_log(grok, LOG_REGEXPAND, "% 20s: %.*s", "start of loop",
diff -Nru grok-1.20110708.1/debian/patches/series grok-1.20110708.1/debian/patches/series
--- grok-1.20110708.1/debian/patches/series	2015-01-26 01:57:27.0 -0800
+++ 

Bug#841252: Pending fixes for bugs in the libtk-filedialog-perl package

[pkg-perl-maintainers]

tag 841252 + pending
thanks

Some bugs in the libtk-filedialog-perl package are closed in revision
5d92d5cb5750e1f90823f69bce0c1eb6219ce945 in branch 'master' by
Florian Schlichting

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libtk-filedialog-perl.git/commit/?id=5d92d5c

Commit message:

Add unrecognized_character_x17.patch (closes: #841252)

Bug#841633: apt-cacher-ng: cron job fails when BindAddress is localhost

[Eduard Bloch]

Hallo,
* Peter Colberg [Fri, Oct 21 2016, 02:48:29PM]:
> > > My acng.conf differs from the default by one line,
> > > 
> > > BindAddress: localhost
> > 
> > In the previous times there was a creepy workaround that fished the
> > hostname from BindAddress strings as a last ressort. Maybe I should
> > recteate this method in acngtool.
> 
> What would speak against querying http://localhost:3142/ by default?

Well, the exact opposite of your problem case. People who enter some IP
addresses there and forget 127.0.0.1 :-).

Regards,
Eduard.

Bug#841086: [Pkg-freeipa-devel] Bug#841086: pki-ca context doesn't start in tomcat

[Michal Kašpar]

On Sat, 2016-10-22 at 00:12 +0300, Timo Aaltonen wrote:
> On 21.10.2016 22:21, Michal Kašpar wrote:
> > OK. It seems the problem might be related with problem described
> > here:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841086
> 
> did you mean 841477 here?

Wrong paste. Should be 
https://www.redhat.com/archives/freeipa-users/2016-September/msg00090.html

Bug#841304: Lowering severity of #841292 related bugs

[Adrian Bunk]

Control: severity -1 important
Control: tags -1 -stretch

I am lowering the severity of these bugs exposed by
#841292 (gcc-6: flexible array support broken).

gcc 6 has the problematic change reverted, so this shouldn't be
a problem for stretch.

This is expected to be a FTBFS with gcc >= 7,
so these will need fixing for buster.

cu
Adrian

-- 

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

Bug#841086: [Pkg-freeipa-devel] Bug#841086: pki-ca context doesn't start in tomcat

[Timo Aaltonen]

On 21.10.2016 22:21, Michal Kašpar wrote:
> OK. It seems the problem might be related with problem described here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841086

did you mean 841477 here?

> The proposed workaround is to run manually "pki-server-upgrade -v".
> I've tried it and it failed on SELinux processing (I don't use SELinux
> at all). After commenting out the SELinux part of upgrade, the upgrade
> finished and the ca contexts starts but fails with the same error
> returned via HTTP. From the /var/log/pki/pki-tomcat/ca/debug I've found
> it's missing /var/log/pki/pki-tomcat/ca/signedAudit directory and after
> created, the debug log shows problem connecting ldap server on port 636
> caused by Bug#841477.

That directory is created at least on new installations.

Would be nice to know what part of the selinux upgrade breaks


-- 
t

Bug#840570: xfce4-power-manager: Attempts to suspend again after opening lid

[Martin Schwenke]

On Thu, 13 Oct 2016 07:35:52 +1100 Martin Schwenke 
wrote:

> I suspend my laptop by closing the lid.  When I resume, by opening the
> lid, I then unlock the screen and I am greeted with a dialog saying:
> 
>   Authentication is required for suspending the system.
> 
> I can cancel this without any issues, except a notification saying:
> 
>   Power manager
> 
>   GDBus.Error.org.freedesktop.DBus.Error.NoReply: Method call timed out
> 
> This is slightly better than the situation before my last reboot,
> where the laptop re-suspended as soon as it had resumed after opening
> the lid.  I then had to press the Fn key to get it to resume again.

Thankfully, this has stopped happening.  Perhaps a useful update to some
related package came through.

Please cancel this bug... sorry for the false alarm...


peace & happiness,
martin

Bug#841667: libconfig-model-dpkg-perl: Dependency calculation gets confused by various versions in a suite

[gregor herrmann]

Package: libconfig-model-dpkg-perl
Version: 2.085
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I tried to update some alternative dependencies (dual-lifed perl
modules) with `cme fix dpkg-control', and was unhappy with the
result, as cme put "perl (>= 5.23.x)" at the end.

Running it with DEBUG turned on shows:

2016/10/21 22:38:20 called on perl
2016/10/21 22:38:20 using cached info for perl
2016/10/21 22:38:20 perl 5.23.9 is not older than perl in sid (5.22.2-5)
2016/10/21 22:38:20 'libversion-perl (>= 1:0.9912) | perl (>= 5.23.9)' done

So cme thinks that perl's version in sid is 5.22.2-5; which seemed
wrong to me but actually cme has a point:

% rmadison perl
perl   | 5.14.2-21+deb7u3  | oldstable| source, 
amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, 
powerpc, s390, s390x, sparc
perl   | 5.20.2-3  | stable-kfreebsd  | source, 
kfreebsd-amd64, kfreebsd-i386
perl   | 5.20.2-3+deb8u3+kbsd1 | stable-kfreebsd-proposed-updates | source, 
kfreebsd-amd64, kfreebsd-i386
perl   | 5.20.2-3+deb8u6   | stable   | source, 
amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
perl   | 5.22.2-3  | unstable | source
perl   | 5.22.2-5  | unstable | source
perl   | 5.24.1~rc3-3  | buildd-unstable  | source
perl   | 5.24.1~rc3-3  | testing  | source, 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, 
s390x
perl   | 5.24.1~rc3-3  | unstable | source, 
amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, 
mips64el, mipsel, powerpc, ppc64el, s390x
perl   | 5.24.1~rc3-3+b1   | buildd-unstable  | 
hurd-i386
perl   | 5.24.1~rc3-3+b1   | unstable | 
hurd-i386


Looks like it gets and uses the first or second hit which is 5.22.2-5
for an old source package still lingering around.


That's

my %perl_version =  $self->get_available_version( 'perl');
my $sid_perl_version = $perl_version{unstable} || $perl_version{sid} ;
my $has_older_perl_in_sid = ( $vs->compare( $v_normal, $sid_perl_version) < 
0 ) ? 1 : 0;
$logger->debug(
"perl $v_normal is",
$has_older_perl_in_sid ? ' ' : ' not ',
"older than perl in sid ($sid_perl_version)"
);


in lib/Config/Model/Dpkg/Dependency.pm.

Maybe get_available_version() or cache_info_from_madison() / or 
extract_madison_info()
could look at binary packages for the current arch instead of the
source version, or for binary instead of source?


Ah, there's an example in the code, and a link to the documentation:

https://ftp-master.debian.org/epydoc/dakweb.queries.madison-module.html

% wget -q -O - 'https://api.ftp-master.debian.org/madison?package=perl'

and

% wget -q -O - 'https://api.ftp-master.debian.org/madison?package=perl=deb'

indeed looks better


Maybe seomthing like this is enough (untested!):

#v+
- --- a/lib/Config/Model/Dpkg/Dependency.pm
+++ b/lib/Config/Model/Dpkg/Dependency.pm
@@ -853,7 +853,7 @@ sub get_available_version {
 return @res;
 }

- -my $url = "$madison_endpoint?package=".uri_escape($pkg_name).'' ;
+my $url = "$madison_endpoint?package=".uri_escape($pkg_name).'=deb' ;
 $self->instance->show_message("Connecting to $madison_host to check 
$pkg_name versions. Please wait...") ;
my $body = get($url);
 my $res ;
@@ -897,7 +897,7 @@ sub cache_info_from_madison {
 return;
 }

- -my $url = "$madison_endpoint?package=".uri_escape(join(' 
',@needed)).'' ;
+my $url = "$madison_endpoint?package=".uri_escape(join(' 
',@needed)).'=deb' ;
 $instance->show_message(
 "Connecting to $madison_host to check ", scalar @needed, " package 
versions. Please wait..."
 );
#v-


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJYCoK0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoG5mcP/2dFl9hwRiBMH+CCs1qb+P7/
layGqVtO+/lyNhRchtQfZVE4LV3IJXQ+54LeRHNZEvjuRv+fEPRX+g8zV9k/MV+w
CaIzpH7SgEfBR2VNSCUMqq9rfBvpGCXuY6E7Qiy6+BXHvV/BG+RHgOnYNATwHZFt
L6tf0uO17LuvtLnpM7R0DyZNGfsihMWJIVb4EMvuu4EtySLDeFVDeiNjeHE4a11i
LGe6yibbOJRanSFtzj0WMu/rUg1eOLCrqCkhSxK44/oPDtZkrn85gK47siUJ+CCs
0Hwr8zgnN7Ak1Gb68AqD9CqRuTAdH7usU76VBrgVUeogCUQjNKUH7OgxdDfkk9ZH
ClHBOfJKyeqx2Zs9IBLo1axuu1N2D45ReQHrBpmUYFul4Ym7FZaBMxgAbN1UH1j5
gDtNdz7gqZ87ixC6kXB45jsVGq/4FM5bcqepzWt+Y6cX3I7NLq4xkOqCEJ6nCW3B
piCCMXryssaQuIeChsELAjSB5dURNWq3WGX9YOEfhQcWrehTkP/pkBMmuT39T849
A/XnZAiP48pbrFCm00+Ac6awkWX9B+i4V/v2EtlO3VW8zSRKmxg3WefleG2uN0cc
f7T+23VC35fiNQ+Z+57d3EsNphO81JQDyzt0zsZDaQDyqGovMavWdPD1sXvw7VOl
bR7BzH6z0X0on4qyMYcD
=oSWu
-END PGP SIGNATURE-

Bug#841146: diffoscope: Failure of test_superblock

[Leo Famulari]

On Fri, Oct 21, 2016 at 04:23:51PM +, Mattia Rizzolo wrote:
> Though I'm using pytest 3.0.3.
> That test is skipped by using pytest.mark.skip(), which I don't see in
> the docs of pytest for 2.7.
> The changelog of pytest tells me pytest.mark.skip() is recognized as a
> skipping marker starting from 2.9¹.  Is there any chance you can instead
> upgrade pytest in your distribution?

We are working on upgrading the core Python packages like pytest and
Setuptools but we can't do it overnight.

> If so I'll add a versioned dependency on setup.py, otherwies I can
> always turn that pytest.mark.skip() into a pytest.mark.skipif(True),
> which is IMHO ugly but quick and effective for solving this bug, I
> think.  Can you also try to convert that marking in
> tests/comparators/utils.py:49 to confirm?

I tried making the following change:

diff --git a/tests/comparators/utils.py b/tests/comparators/utils.py
index f8f6399..acbdc9f 100644
--- a/tests/comparators/utils.py
+++ b/tests/comparators/utils.py
@@ -46,7 +46,7 @@ def skip_unless_tools_exist(*required):
 
 def skip_unless_tool_is_older_than(tool, actual_ver, min_ver, 
vcls=LooseVersion):
 if tools_missing(tool):
-return pytest.mark.skip(reason="requires {}".format(tool))
+return pytest.mark.skipif(True))
 if callable(actual_ver):
 actual_ver = actual_ver()
 return pytest.mark.skipif(

But, that creates a bunch of invalid syntax. Here's one:

___ ERROR collecting tests/comparators/test_utils.py ___
/gnu/store/1n2h8244hw0xvldqdz10lspp60snqw2v-python-pytest-2.7.3/lib/python3.5/site-packages/pytest-2.7.3-py3.5.egg/_pytest/python.py:498:
 in _importtestmodule
mod = self.fspath.pyimport(ensuresyspath=True)
/gnu/store/syf4ac6vw94d5qvaacmjq33wfhbgizcr-python-py-1.4.31/lib/python3.5/site-packages/py-1.4.31-py3.5.egg/py/_path/local.py:650:
 in pyimport
__import__(modname)
:969: in _find_and_load
???
:958: in _find_and_load_unlocked
???
:664: in _load_unlocked
???
:634: in _load_backward_compatible
???
/gnu/store/1n2h8244hw0xvldqdz10lspp60snqw2v-python-pytest-2.7.3/lib/python3.5/site-packages/pytest-2.7.3-py3.5.egg/_pytest/assertion/rewrite.py:171:
 in load_module
py.builtin.exec_(co, mod.__dict__)
tests/comparators/test_utils.py:27: in 
from utils import tools_missing, skip_unless_tools_exist, data, 
load_fixture, \
E File 
"/tmp/guix-build-diffoscope-61.drv-0/diffoscope-61/tests/comparators/utils.py", 
line 49
E   return pytest.mark.skipif(True))
E  ^
E   SyntaxError: invalid syntax

I don't know Python well; it's possible I made the wrong change.


signature.asc
Description: PGP signature

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Ansgar Burchardt]

Package: release-notes
Tags: stretch

debootstrap enables merged-/usr by default since 1.0.85 (when installing
stretch or later only).  To match this on upgrades to stretch, I would
like to recommend installing `usrmerge` at the end of the upgrade.

Ansgar

Bug#821051: Need support for uploading and signing EFI executables

[Helen Koike]

On 2016-10-18 07:34 PM, Ansgar Burchardt wrote:

Ben Hutchings writes:

On Tue, 2016-10-18 at 22:55 +0200, Ansgar Burchardt wrote:

Is there any documentation how this is supposed to work?


Nothing comprehensive as yet.  Where should it go?


It doesn't need to be comprehensive.  I just would like to understand
what needs to happen.


What uses the signatures the archive is planned to write to dists/*?


Scripts for preparing the source packages that build signed binaries.
(Which will probably be included in those source packages, but don't
have to be.)


How does building signed binaries work? That sounds like the signature
gets merged into the binaries dak signed in some way?


It looks wrong to bypass embargoed for the signatures. We avoid showing
which packages will get security updates in the future.


That's a fair point.  But they need to be findable by a maintainer who
doesn't have access to embargoed packages in general.  How about using
a hash of the changelog?


Wouldn't the maintainer need access to the embargoed binaries as well as
the signatures to prepare the signed version?



As we briefly discussed on irc, we could solve all this by making dak to 
publish the -signed packages automatically, is this a good solution? 
Please, let me know your opinion so I can go ahead and implement a first 
version of it.


Thanks
Helen Koike

Bug#841665: boinc-client: The boinc-client init script has a badly constructed parameter for xhost

[Mike Brennan]

Package: boinc-client
Version: 7.6.33+dfsg-1~bpo8+1
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainers,

boinc-client shell script is used by init/systemd to start the boinc client 
daemon (typically running as user=boinc)

In order for boinc to access GPU hardware -  xhost is used to grant access to 
boinc.

At line 109-110
---
# grant the boinc client to perform GPU computing
   xhost local:boinc || echo -n "xhost error ignored, GPU computing may not 
be possible"


the correct syntax stould be 
   xhost +si:localuser:boinc
or more correctly for the this script
   xhost +si:localuser:$BOINC_USER

The impact of using this incorrect syntax - is not to error, but grant ALL 
local users access.  
(This could be a very old or different maybe BSD syntax)

The intention of the script to grant ONLY user=boinc access, instead all local 
users have access.

For example a little test.

agentb@dejon:/etc/init.d$ xhost
access control enabled, only authorized clients can connect
SI:localuser:agentb

agentb@dejon:/etc/init.d$ xhost local:random-string
non-network local connections being added to access control list

agentb@dejon:/etc/init.d$ xhost
access control enabled, only authorized clients can connect
LOCAL:
SI:localuser:boinc
SI:localuser:agentb

Hope this is clear, and thank you for maintaining boinc!

Cheers
Mike


-- Package-specific info:
-- Contents of /etc/default/boinc-client:
# This file is /etc/default/boinc-client, it is a configuration file for the
# /etc/init.d/boinc-client init script.

# Set this to 1 to enable and to 0 to disable the init script.
ENABLED="1"

# Set this to 1 to enable advanced scheduling of the BOINC core client and
# all its sub-processes (reduces the impact of BOINC on the system's
# performance).
SCHEDULE="1"

# The BOINC core client will be started with the permissions of this user.
BOINC_USER="boinc"

# This is the data directory of the BOINC core client.
BOINC_DIR="/var/lib/boinc-client"

# This is the location of the BOINC core client, that the init script uses.
# If you do not want to use the client program provided by the boinc-client
# package, you can specify here an alternative client program.
#BOINC_CLIENT="/usr/local/bin/boinc"
BOINC_CLIENT="/usr/bin/boinc"

# Here you can specify additional options to pass to the BOINC core client.
# Type 'boinc --help' or 'man boinc' for a full summary of allowed options.
#BOINC_OPTS="--allow_remote_gui_rpc"
BOINC_OPTS=""

# Scheduling options

# Set SCHEDULE="0" if prefering to run with upstream default priority
# settings.

# Nice levels. When systems are truly busy, e.g. because of too many active
# scientific applications started by the boinc client, there is a chance for
# the boinc client not to be granted sufficient opportunity to check for
# scientific applications to be alive and make the (wrong) decision to
# terminate the scientific app. This is particularly an issue with many
# apps started in parallel on modern multi-core systems and extra overheads
# for the download and uploads of files with the project servers. Another
# concern is the latency for scientific applications to communicate with the
# graphics card, which should be low. All such values should be set and
# controled from within the BOINC client. The Debian init script also sets
# extra constrains via chrt on real time performance and via ionice on 
# I/O performance, which is beyond the regular BOINC client. It then was
# too easy to use that code to also constrain minimal nice levels. We still
# think about how to best distinguish GPU applications from regular apps.
BOINC_NICE_CLIENT=10
BOINC_NICE_APP_DEFAULT=19
#BOINC_NICE_APP_GPU=5# not yet used

# ionice classes. See manpage of ionice (1) in the util-linux package.
BOINC_IONICE_CLIENT=3# idle
#BOINC_IONICE_APP_DEFAULT=3  # idle, not yet used
#BOINC_IONICE_APP_GPU=2  # best effort, not yet used


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

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

Versions of packages boinc-client depends on:
ii  adduser3.113+nmu3
ii  ca-certificates20141019+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  init-system-helpers1.22
ii  libboinc7  7.6.33+dfsg-1~bpo8+1
ii  libc6  2.19-18+deb8u6
ii  libcurl3   7.38.0-4+deb8u4
ii  libgcc11:4.9.2-10
ii  libstdc++6 4.9.2-10
ii  libx11-6   2:1.6.2-3
ii  libxss11:1.2.2-1
ii  python 2.7.9-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

boinc-client 

Bug#840668: ltsp-build-client should use current mirror as default

[Vagrant Cascadian]

Control: tags 840668 pending

On 2016-10-13, Vagrant Cascadian wrote:
> Another option is deb.debian.org, but it is still considered
> experimental; that is what I've personally been using lately.

Apparently, deb.debian.org is no longer experimental, it's the new
default for debootstrap as of 1.0.85, so I'll switch to that for LTSP.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#841664: qconf generates broken configure containing non-posix substitutions

[Jan Niehusmann]

Package: qconf
Version: 2.1-1
Severity: important

Hi Boris,

with 2.1-1, you "backported remove-bashism-from-configure.patch" to fix
bashisms in the configure script contained in the qconf package.

While this fixes the build of qconf itself, qconf still generates
configure scripts containing these bashisms for other packages.

Therefore, it's necessary to also backport the following patch:
https://github.com/psi-plus/qconf/commit/f84f570dd760b1641dfd8d6eb12d34f48bf90af6

--
commit f84f570dd760b1641dfd8d6eb12d34f48bf90af6
Author: Rion 
Date:   Tue May 31 20:10:40 2016 +0600

Fixed bashism (thanks Pull #9)

diff --git a/src/qconf.cpp b/src/qconf.cpp
index 93f9098..ce6a4f9 100644
--- a/src/qconf.cpp
+++ b/src/qconf.cpp
@@ -767,7 +767,7 @@ private:
{
QString str =
"if [ -z \"$QC_QTSELECT\" ]; then\n"
-   "   QC_QTSELECT=\"${QT_SELECT/qt/}\"\n"
+   "   QC_QTSELECT=\"$(echo $QT_SELECT | tr -d \"qt\")\"\n"
"fi\n"
"\n"
"if [ ! -z \"$QC_QTSELECT\" ]; then\n"
--

This is likely the cause for bugs 841627 and 841557 in psi and psi-plus
packages. ("./configure: Bad substitution")

Best regards,
Jan

PS: At least for the psi package, there are more build failures with
qconf 2.1, probably because of some incompatibilities between qconf 1.5
and qconf 2.1. Didn't try with qconf 2.0, yet.

Bug#841534: ITP: puppet-module-barbican -- Puppet module for OpenStack Barbican

[Tollef Fog Heen]

]] Thomas Goirand 

> * Package name: puppet-module-barbican
>   Version : 9.4.0
>   Upstream Author : OpenStack Foundation 
> * URL : https://github.com/openstack/puppet-barbican
> * License : Apache-2.0
>   Programming Lang: Puppet, Ruby
>   Description : Puppet module for OpenStack Barbican
> 
>  Puppet lets you centrally manage every important aspect of your system using 
> a
>  cross-platform specification language that manages all the separate elements
>  normally aggregated in different files, like users, cron jobs, and hosts,
>  along with obviously discrete elements like packages, services, and files.
>  .
>  This module manages both the installation and configuration of OpenStack
>  Barbican.

It would be useful if this included some description of what OpenStack
Barbican is.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#841663: qcachegrind: Manpage missing

[Andrea Stacchiotti]

Package: qcachegrind
Version: 4:16.08.0-1
Severity: wishlist

Title says it all.
Even putting in `kcachegrind`'s manpage (after a rename) would be more than
enough.

Thanks.



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

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

Versions of packages qcachegrind depends on:
ii  libc6   2.24-5
ii  libqtcore4  4:4.8.7+dfsg-9
ii  libqtgui4   4:4.8.7+dfsg-9
ii  libstdc++6  6.2.0-9

Versions of packages qcachegrind recommends:
ii  graphviz  2.38.0-15+b1
ii  valgrind  1:3.12.0~svn20160714-1+b1

Versions of packages qcachegrind suggests:
pn  kcachegrind-converters  
pn  khelpcenter 

-- no debconf information

Bug#841660: RFS: budgie-desktop/10.2.8-1

[Gianfranco Costamagna]

control: tags -1 moreinfo
control: owner -1 !

Hi,

> dget -x 
> https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.8-1.dsc


>1. I noticed on mentors.debian.net that the watch file failed - this
>is very strange since nothing has changed for months now - is there a
>bug on mentors at the moment causing the watch to fail?


IIRC yes


>2. ran check-all-the-things - this did not find anything new from>previous 
>uploads


ok

>3. ran lintian -i -I on the sources - no new items listed in previous uploads

ok

>- to reiterate - current linitian items are known upstream
>budgie-desktop.  relnow, bindnow will be resolved once the VALA stuff
>is recoded to C
>- rpath is necessary due to upstream GNOME GTK_3.22 private mutter API changes
>- the patches added are upstream budgie-desktop released since v10.2.8
>- bugs found after release that are necessary for ibus capability on

>debian/ubuntu

ok

>  Changes since the last upload:
>
>  * New upstream release
>- GTK+3.22 fixes
>- new places indicator
>- new ibus indicator
>- refreshed panel icons
>- updated translations
>- general fixes for the desktop
>  * Packaging changes:
>- Drop all now obsolete previous patches named 000*
>- add new build dependency libibus-1.0-dev
>- Updated debian/copyright with revised info for new source files
>- add recommendation to install gnome-screensaver; screenlock capability
>  in budgie-desktop does not work without this package
>  * add patch upstream patch to allow the ibus applet to compile:
>  0001-Lower-the-ibus-requirement-to-1.5.11-for-our-Debuntu.patch
>  * add patch to ensure ibus is connected correctly if already running
>  0002-wm-ibus-Always-try-to-use-an-existing-ibus-daemon-if.patch
>



blockers:

missing licenses (cc-by-sa3.0)
+ * Copyright (C) GNOME Shell Developers (Heavy inspiration, logic theft)

(vala^^)

other stuff seems good

G.

Bug#841662: libserver-starter-perl: test suite sometimes times out

[Niko Tyni]

Package: libserver-starter-perl
Version: 0.32-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: autopkgtest

This package occasionally fails its autopkgtest checks on ci.debian.net.

  https://ci.debian.net/packages/libs/libserver-starter-perl/unstable/amd64/

It's not clear to me which test is hanging; it looks like t/04-starter-dir.t
finishes properly but I guess it could also be its cleanup or something.
-- 
Niko Tyni   nt...@debian.org

Bug#841661: release.debian.org: grass not migrating to testing

[Bas Couwenberg]

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

grass (7.0.5-2) is not migrating to testing even though it's a valid
candidate.

Due to the motif issue (#840394) the grass package and its reverse
dependencies (libgdal-grass & qgis) have been removed from the
problematic architectures (#840783, #840784 & #840785), but these
partial removals have not been performed in testing yet.

Please help grass migrate to testing.

Kind Regards,

Bas

Bug#841659: ITP: zzz-to-char -- fancy version of `zap-to-char' command

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: zzz-to-char
  Version : 0.1.1
  Upstream Author : Mark Karpov 
* URL : https://github.com/mrkkrp/zzz-to-char
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : fancy version of `zap-to-char' command

This package provides two new commands `zzz-to-char' and `zzz-up-to-char'
which work like built-ins `zap-to-char' and `zap-up-to-char', but allow you
quickly select exact character you want to “zzz” to.

The commands are minimalistic and often work like built-in ones when there is
only one occurrence of target character (except they automatically work in
backward direction too). You can also specify how many characters to scan from
each side of point.

This package uses avy as a backend.

Bug#840469: dh_sysuser: should add a dependency to "perl-modules" to remove sysuser.

[Niko Tyni]

On Fri, Oct 21, 2016 at 10:37:29AM +0300, Dmitry Bogatov wrote:

> It is unfortunate. I am considering following patch:

>   +   rm -fr --preserve-root --one-file-system -- "$home"

> but I am scared to invoke `rm -fr' with root. I beleive, that deluser would
> handle it better then me.

Seems somewhat scary to me too. I think just not leaving the directory
around would be fine. It's a corner case anyway.

(and if the next bug is 'unowned files after purge', I'd argue that it's
deluser's problem and not yours...)
 
> Ah, and by the way, why `adduser' package, from which `deluser' binary comes
> is still present during post-rm? `adduser' is not Essential, only Important.

No idea. Possibly the piuparts torture test could be even more cruel
(even if I personally think it's already overdoing it.)

> I know that abusing Pre-Depends is frowned upon, but would
> Pre-Depends: perl help?

I don't think so, sorry.
-- 
Niko

Bug#841660: RFS: budgie-desktop/10.2.8-1

[foss.freedom]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "budgie-desktop"

 * Package name: budgie-desktop
   Version : 10.2.8-1
   Upstream Author : i...@solus-project.com
 * URL : https://github.com/solus-project/budgie-desktop
 * License : LGPL-2.1/GPL2.0
   Section : x11

  It builds those binary packages:

budgie-core - Core package for Budgie-Desktop
 budgie-core-dev - Development package for budgie-desktop
 budgie-desktop - Desktop package for budgie-desktop
 budgie-desktop-doc - documentation files for the budgie-desktop
 gir1.2-budgie-desktop-1.0 - GNOME introspection library for budgie-desktop
 libbudgie-plugin0 - Plugin library for budgie-desktop
 libbudgietheme0 - Theme library for budgie-desktop
 libraven0  - Raven library for budgie-desktop

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

  https://mentors.debian.net/package/budgie-desktop


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

dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.8-1.dsc

Notes:
1. I noticed on mentors.debian.net that the watch file failed - this
is very strange since nothing has changed for months now - is there a
bug on mentors at the moment causing the watch to fail?
2. ran check-all-the-things - this did not find anything new from
previous uploads
3. ran lintian -i -I on the sources - no new items listed in previous uploads

 - to reiterate - current linitian items are known upstream
budgie-desktop.  relnow, bindnow will be resolved once the VALA stuff
is recoded to C
- rpath is necessary due to upstream GNOME GTK_3.22 private mutter API changes
- the patches added are upstream budgie-desktop released since v10.2.8
- bugs found after release that are necessary for ibus capability on
debian/ubuntu


  Changes since the last upload:

  * New upstream release
- GTK+3.22 fixes
- new places indicator
- new ibus indicator
- refreshed panel icons
- updated translations
- general fixes for the desktop
  * Packaging changes:
- Drop all now obsolete previous patches named 000*
- add new build dependency libibus-1.0-dev
- Updated debian/copyright with revised info for new source files
- add recommendation to install gnome-screensaver; screenlock capability
  in budgie-desktop does not work without this package
  * add patch upstream patch to allow the ibus applet to compile:
  0001-Lower-the-ibus-requirement-to-1.5.11-for-our-Debuntu.patch
  * add patch to ensure ibus is connected correctly if already running
  0002-wm-ibus-Always-try-to-use-an-existing-ibus-daemon-if.patch


  Regards,
   David Mohammed

Bug#840070: Vagrant libvirt bug

[Emmanuel Kasper]

I assume is on the vagrant-libvirt image on atlas.
The vagrant-libvirt boxes are made with vmdeboostrap.

Most probably the problem here is because vmdebootstrap was run in a
stretch host, and used ext4 tools which are newer than
the ext4 tools of jessie.

So we could rebuild the image on a jessie host or I can investigate how
to build the images with packer for the next minor release.

Bug#826790: Pending fixes for bugs in the libset-scalar-perl package

[pkg-perl-maintainers]

tag 826790 + pending
thanks

Some bugs in the libset-scalar-perl package are closed in revision
4124adb47af6ab1538d1b1257ae22df20f0503b8 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libset-scalar-perl.git/commit/?id=4124adb

Commit message:

Add Multi-Arch: foreign.

Closes: #826790

Bug#841658: alfa: build-depends on libcfitsio3-dev

[Aurelien Jarno]

Package: alfa
Version: 0.98-1
Severity: important

Dear Maintainer,

alfa build-depends on 'libcfitsio3-dev | libcfitsio-dev'. The first part
of the alternative is a transitional package depending on libcfitsio-dev
that has just been removed. Build daemons only consider the first part
of the alternative. Therefore, could you please adjust the
build-dependency to simply 'libcfitsio-dev'? Note that libcfitsio-dev is
already available in Jessie, so that should not make backporting more
difficult.

Sorry for the late notification, given the alternative, dak considered
that libcfitsio3-dev is not used anymore.

Thanks,
Aurelien

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

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

Bug#841086: pki-ca context doesn't start in tomcat

[Michal Kašpar]

OK. It seems the problem might be related with problem described here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841086
The proposed workaround is to run manually "pki-server-upgrade -v".
I've tried it and it failed on SELinux processing (I don't use SELinux
at all). After commenting out the SELinux part of upgrade, the upgrade
finished and the ca contexts starts but fails with the same error
returned via HTTP. From the /var/log/pki/pki-tomcat/ca/debug I've found
it's missing /var/log/pki/pki-tomcat/ca/signedAudit directory and after
created, the debug log shows problem connecting ldap server on port 636
caused by Bug#841477.

-- 
Michal Kašpar

Bug#805154: Please reconsider tagging this bug wontfix

[Sam Hartman]

I do understand that the proposed fix is inadequate.  You'd need to not
include nobarrier on the esp partition.

However, the performance of vmdebootstrap is really fairly bad compared
to other image creation solutions I've used in the past, and it does
significantly impact the test/development cycle.
If you don't want to develop a patch fine, but perhaps help or no tags
would be more appropriate than wontfix.

Bug#520633: xscreensaver: screen does not lock if switched to virtual terminal

[Adrien Grellier]

Version: 4:5.8.1-1

Hi,

I confirmed, the bug is solved in sid at least.

Regards,

Adrien



signature.asc
Description: OpenPGP digital signature

Bug#838932: simliar problem with proxy_balancer / slotmem_shm

[Horst Platz]

Dear Maintainer,

in my further on configuration with prox_balancer. i figured out a
another start/reboot problem with proxy_balancer configuration.

remember

:~# systemctl disable apache2
default apache is disabled -> reboot -> /var/run/apache2/ don't exist


:~# sh /usr/share/doc/apache2/examples/setup-instance proxy-balancer
Setting up /etc/apache2-proxy-balancer ...
Setting up /etc/init.d/apache2-proxy-balancer ...
Setting up symlinks: a2enmod-proxy-balancer a2dismod-proxy-balancer
a2ensite-proxy-balancer a2dissite-proxy-balancer a2enconf-proxy-balancer
a2disconf-proxy-balancer apache2ctl-proxy-balancer
Setting up /etc/logrotate.d/apache2-proxy-balancer and
/var/log/apache2-proxy-balancer ...


:~# systemctl enable apache2-proxy-balancer
apache2-proxy-balancer.service is not a native service, redirecting to
systemd-sysv-install
Executing /lib/systemd/systemd-sysv-install enable apache2-proxy-balancer

:~# cd /etc/apache2-proxy-balancer/

:~# vim sites-enabled/proxy-balancer.conf
[...]

BalancerMember https://192.168.168.10/
BalancerMember https://192.168.168.20/
ProxySet lbmethod=bytraffic

[...]
ProxyPass /site-twoways/   balancer://twoways/
[...]


:~# a2enmod-proxy-balancer proxy_balancer
Considering dependency proxy for proxy_balancer:
Enabling module proxy.
Considering dependency alias for proxy_balancer:
Module alias already enabled
Considering dependency slotmem_shm for proxy_balancer:
Enabling module slotmem_shm.
Enabling module proxy_balancer.
To activate the new configuration, you need to run:
  service apache2-proxy-balancer restart


:~# a2enmod-proxy-balancer lbmethod_bytraffic
Considering dependency proxy_balancer for lbmethod_bytraffic:
Considering dependency proxy for proxy_balancer:
Module proxy already enabled
Considering dependency alias for proxy_balancer:
Module alias already enabled
Considering dependency slotmem_shm for proxy_balancer:
Module slotmem_shm already enabled
Module proxy_balancer already enabled
Enabling module lbmethod_bytraffic.
To activate the new configuration, you need to run:
  service apache2-proxy-balancer restart


:~# apache2ctl-proxy-balancer configtest
Syntax OK


:~# service apache2-proxy-balancer start
Job for apache2-proxy-balancer.service failed because the control
process exited with error code. See "systemctl status
apache2-proxy-balancer.service" and "journalctl -xe" for details.


:~# cat /var/log/apache2-proxy-balancer/error.log
[...]
[Fri Oct 21 20:44:33.15 2016] [slotmem_shm:error] [pid 2120] (2)No
such file or directory: AH02611: create:
apr_shm_create(/var/run/apache2/slotmem-shm-p6c23514b.shm) failed
[Fri Oct 21 20:44:33.144483 2016] [proxy_balancer:emerg] [pid 2120]
(2)No such file or directory: AH01179: balancer slotmem_create failed
[Fri Oct 21 20:44:33.144487 2016] [:emerg] [pid 2120] AH00020:
Configuration Failed, exiting


the module slotmem_shm has only .load files no .conf files

:~# ls -la mods-enabled/
[...]
lrwxrwxrwx 1 root root   34 Okt 21 20:40 slotmem_shm.load ->
../mods-available/slotmem_shm.load


https://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html

in the dokumentation is described that the module writes in the
"DefaultRuntimeDir"


in my opinion that directory is set in the envvars file with the $SUFFIX in
the right way.

:~# cat /etc/apache2-proxy-balancer/envvars
[...]
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
[...]


but see above the module looks like, don't follow that entry

my solution extra set from DefaultRuntimeDir in the multiple apache
.conf file

:~# vim sites-enabled/proxy-balancer.conf
DefaultRuntimeDir /var/run/apache2-proxy-balancer/
[...]


:~# apache2ctl-proxy-balancer configtest
Syntax OK

:~# service apache2-proxy-balancer start

:~# ls -l /var/run/apache2-proxy-balancer/
insgesamt 12
-rw-r--r-- 1 root root 5 Okt 21 20:48 apache2-proxy-balancer.pid
-rw-r--r-- 1 root root 8 Okt 21 20:48 slotmem-shm-p6c23514b.shm
-rw-r--r-- 1 root root 8 Okt 21 20:48 slotmem-shm-p6c23514b_twoways.shm


:~# systemctl status apache2-proxy-balancer
? apache2-proxy-balancer.service - LSB: Start/stop apache2 web server
(config /etc/apache2-proxy-balancer)
   Loaded: loaded (/etc/init.d/apache2-proxy-balancer; bad; vendor
preset: enabled)
   Active: active (running) since Fr 2016-10-21 20:48:45 CEST; 33s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 2203 ExecStart=/etc/init.d/apache2-proxy-balancer start
(code=exited, status=0/SUCCESS)
Tasks: 6
   Memory: 16.2M
  CPU: 63ms
   CGroup: /system.slice/apache2-proxy-balancer.service
   +-2220 /usr/sbin/apache2 -d /etc/apache2-proxy-balancer -k start
   +-2223 /usr/sbin/apache2 -d /etc/apache2-proxy-balancer -k start
   +-2224 /usr/sbin/apache2 -d /etc/apache2-proxy-balancer -k start
   +-2225 /usr/sbin/apache2 -d /etc/apache2-proxy-balancer -k start
   +-2226 /usr/sbin/apache2 -d /etc/apache2-proxy-balancer -k start
   +-2227 /usr/sbin/apache2 -d /etc/apache2-proxy-balancer -k 

Bug#833057: does downgrading e2fsprogs to the jessie version help?

[Sam Hartman]

Does the e2fsprogs in jessie produce an image that works with syslinux
and vmdebootstrap?

Bug#837687: snort builds with --disable-static-daq

[Adrian Bunk]

Adding --disable-static-daq CONFFLAGS fixed the build for me.

Why does snort want to link with the static library by default?
If the shared library is also fine this is a proper fix.
If it is not, libdaq_static.a must be recompiled with -fPIC.

cu
Adrian

-- 

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

Bug#841633: apt-cacher-ng: cron job fails when BindAddress is localhost

[Peter Colberg]

On Fri, Oct 21, 2016 at 08:35:55PM +0200, Eduard Bloch wrote:
> Hallo,
> * Peter Colberg [Fri, Oct 21 2016, 11:01:44AM]:
> > Package: apt-cacher-ng
> > Version: 1-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > After updating to the above version, the cron job fails with
> 
> From which version? That's the real question.

The regression was introduced upgrading from 0.9.3.2-1 to 1-1.

> > /etc/cron.daily/apt-cacher-ng:
> > Error: cannot fetch 
> > http://foo.example.org:3142/acng-report.html?doExpire=Start+Expiration=aOe,
> 
> There is no such hostname anywhere in the source. If you redacted the
> output then you should mention this (and describe the real output),
> otherwise we are hunting ghosts.

Sorry for not being clear; yes, the hostname has been redacted and
belongs to the machine which runs apt-cacher-ng and the cron job.

> As stop-gap solution, you could set HOSTNAME variable as needed in the
> mentioned cron script.

Thanks, I will try that for the next run.

> > My acng.conf differs from the default by one line,
> > 
> > BindAddress: localhost
> 
> In the previous times there was a creepy workaround that fished the
> hostname from BindAddress strings as a last ressort. Maybe I should
> recteate this method in acngtool.

What would speak against querying http://localhost:3142/ by default?

Regards,
Peter

Bug#759904: cl-plplot: FTBFS: The alien function "c_plwid" is undefined.

[Steve Langasek]

Control: reassign -1 ftp.debian.org
Control: affects -1 cl-plplot
Control: retitle -1 RM: cl-plplot -- RoQA; FTBFS

The cl-plplot package has been FTBFS in unstable since 2014.  It was
orphaned that same year, with an upload that apparently was not built
against clean unstable.  There has been no sign of activity since.  Please
remove this package from unstable.

The package is also affected by serious bug #794850.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#793116: systemd-journald exiting with SIGUSR1

[Daniel Povey]

I just want to follow up on this that I believe I have found the reason for
this bug and I have a solution which I am testing out.

In the output of `systemctl status systemd-journald` it says:
   Active: failed (Result: start-limit)
and this is related to the systemd mechanism to stop cycles where services
keep restarting.  It's related to the configs
StartLimitIntervalSec=   [defaults to DefaultStartLimitIntervalSec=10 sec
by default]
StartLimitBurst=  [defaults to DefaultStartLimitBurst=5 by default]

so that if a service is restarted 5 times within 10 seconds, it's not
restarted any more to avoid wasting resources.
What seems to happen is that if systemd-journal-flush.service sends the
signal SIGUSR1 to systemd-journald and systemd-journald wasn't ready to
handle it for some reason (e.g. had just been started, or there was some
hangup), then systemd-journald is restarted, and
systemd-journal-flush.service immediately restarts also.  Again
systemd-journald won't be ready to handle the signal as it hasn't had time
to run the signal handler, and the cycle repeats 5 times until the
systemd-journald service hits the StartLimitBurst and dies.  I verified
using `lastcomm` (we have process accounting enabled) that this did in fact
happen.

The way I am trying to fix it is to introduce a restart delay of 10 seconds
into the systemd-journal-flush service.  See the config file below; the
only new line that differs from the defaults in
 /lib/systemd/system/systemd-journal-flush.service is the line
RestartSec=10.

Dan



==
cat /etc/systemd/system/systemd-journal-flush.service
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Trigger Flushing of Journal to Persistent Storage
Documentation=man:systemd-journald.service(8) man:journald.conf(5)
DefaultDependencies=no
Requires=systemd-journald.service
After=systemd-journald.service local-fs.target remote-fs.target
Before=systemd-user-sessions.service
# Don't re-start this service too often, or we can get into a cycle where
# if this service was run just after systemd-journald was started, it
# fails to handle the signal, causing that service to be restarted
# and this servie to be immediately restarted also, until we hit
# the limit of StartLimitBurst=5 restarts and systemd-journald
# dies.
RestartSec=10

[Service]
ExecStart=/bin/systemctl kill --kill-who=main --signal=SIGUSR1
systemd-journald.service
Type=oneshot


On Sat, Oct 15, 2016 at 9:48 PM, Daniel Povey  wrote:

> Another observation about this bug, which might be helpful.
>
> If the signal is sent to systemd-journald via
> /bin/systemctl kill --kill-who=main --signal=SIGUSR1
> systemd-journald.service
> then messages like the following show up in the kernel messages from
> `dmesg -T`, like:
>
> [Sat Oct 15 21:02:35 2016] systemd-journald[26517]: Received request to
> flush runtime journal from PID 1
>
> but they don't show up in the output of 'journalctl -r'.
> In  /etc/systemd/journald.conf, it says:
>
> #MaxLevelStore=debug
> #MaxLevelSyslog=debug
>
> so I would have thought the same messages would go to both places.
> I don't know if I'm misunderstanding something here..
>
> Dan
>
>
>
>
>
> On Sat, Oct 15, 2016 at 9:07 PM, Daniel Povey  wrote:
>
>> BTW, I attach the output from `systemd-analyze dump`, as dump.txt.
>> It would be great if the debian people could help us look into this.
>> Lennart has a policy that his team will only look into bug reports in the
>> latest two versions of systemd, and obviously we are well behind that.
>>
>> Dan
>>
>>
>> On Sat, Oct 15, 2016 at 8:53 PM, Daniel Povey  wrote:
>>
>>>
>>> I just want to report that we are suffering from this bug, and it is
>>> quite frequent.
>>> This is with version  215-17+deb8u5 .
>>>
>>> root@a12:~# systemctl status systemd-journald
>>>
>>> *** systemd-journald.service - Journal Service
>>>
>>>Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
>>>
>>>Active: *failed* (Result: start-limit) since Sat 2016-10-15 12:01:57
>>> EDT; 8h ago
>>>
>>>  Docs: man:systemd-journald.service(8)
>>>
>>>man:journald.conf(5)
>>>
>>>   Process: 51561 ExecStart=/lib/systemd/systemd-journald *(code=killed,
>>> signal=USR1)*
>>>
>>>  Main PID: 51561 (code=killed, signal=USR1)
>>>
>>>
>>>
>>
>

Bug#841548: autopkgtest: FTBFS: Tests failures

[Martin Pitt]

Control: reassign -1 python3-wand
Control: forcemerge 841653 -1


Martin Pitt [2016-10-21 20:22 +0200]:
> |  File "/tmp/autopkgtest.2SwpBj/build.7IV/real-tree/debian/tests/t", line 2, 
> in 
> | from wand.image import Image
> |   File 
> "/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/image.py", 
> line 21, in 
> | from .color import Color
> |   File 
> "/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/color.py", 
> line 12, in 
> | from .version import QUANTUM_DEPTH
> |   File 
> "/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/version.py", 
> line 95, in 
> | *map(int, MAGICK_RELEASE_DATE_STRING.split('-')))
> | TypeError: Required argument 'month' (pos 2) not found
> 
> So it looks like imagemagic changed recently, so at first sight I'll
> just need to adjust the test case to that.

Turns out this is an actual bug in python3-wand, not a bug in the
tests. I reported this as https://bugs.debian.org/841653 and make this
a duplicate.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#841656: mate-themes: modified menta theme doesn't work with gtk3+

[shirish शिरीष]

Package: mate-themes
Version: 3.22.3-1
Severity: normal

Dear Maintainer,
I used mate-appearance properties to change the look and got to know
that I am/was running a customized theme taking -

Controls - BlueMenta
Window Borders - BlueMenta
Icons - Menta
Pointer - Mate

When running from the CLI terminal, got the following errors -

┌─[shirish@debian] - [~] - [1497]
└─[$] mate-appearance-properties

(mate-appearance-properties:26027): Gtk-WARNING **: Theme parsing
error: gtk.css:63:28: The :prelight pseudo-class is deprecated. Use
:hover instead.

(mate-appearance-properties:26026): Gtk-WARNING **: Theme parsing
error: gtk.css:63:28: The :prelight pseudo-class is deprecated. Use
:hover instead.

(mate-appearance-properties:26027): Gtk-WARNING **: Theme parsing
error: gtk.css:73:35: The :prelight pseudo-class is deprecated. Use
:hover instead.

(mate-appearance-properties:26026): Gtk-WARNING **: Theme parsing
error: gtk.css:73:35: The :prelight pseudo-class is deprecated. Use
:hover instead.

(mate-appearance-properties:26027): Gdk-WARNING **:
/build/gtk+3.0-dN7rjx/gtk+3.0-3.22.1/./gdk/x11/gdkwindow-x11.c:5554
drawable is not a native X11 window

The last line is repeated till now.

Hope to see this fixed soonish.

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

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

Versions of packages mate-themes depends on:
ii  gtk2-engines  1:2.20.2-3
ii  gtk2-engines-murrine  0.98.1.1-6
ii  gtk2-engines-pixbuf   2.24.31-1
ii  librsvg2-common   2.40.16-1
ii  mate-icon-theme   1.16.0-1

Versions of packages mate-themes recommends:
ii  dmz-cursor-theme  0.4.4

mate-themes suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#837581: Move to the correct package

[Adrian Bunk]

Control: reassign -1 xfslibs-dev
Control: retitle -1 xfslibs-dev: Don't put the .so symlink to /lib/*.so
Control: affects -1 src:xfsdump

The root cause of this bug is that /usr/lib/libhandle.a is being used 
instead of /lib/libhandle.so

This was already not right before, but now it became fatal.

The correct solution for this bug is:
- move libhandle.so.1 to /lib//
- move libhandle.so to /usr/lib//

cu
Adrian

-- 

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

Bug#841657: freeipmi: Please use dh_autoreconf instead of dh_autotools-dev

[Steve Langasek]

Package: freeipmi
Version: 1.4.11-1.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Hi folks,

In Ubuntu, we have applied a patch to freeipmi to use dh_autoreconf instead
of dh_autotools-dev.  At one time, this was needed in order to let the
freeipmi package build on ppc64el.  Since I see that freeipmi is built on
ppc64el in Debian unstable now, it's possible that this patch is not
currently needed; nevertheless, dh_autoreconf is the best practice for
updating autotools output at package build time, and will be better
future-proofed for other ports.

Please consider applying the attached patch.

An alternative approach would be to update to debhelper compat level 10,
where I believe dh_autoreconf is run automatically.  This of course impacts
backporting of your package, which may or may not be acceptable to you.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru freeipmi-1.4.11/debian/control freeipmi-1.4.11/debian/control
--- freeipmi-1.4.11/debian/control	2016-09-05 00:55:48.0 -0700
+++ freeipmi-1.4.11/debian/control	2016-10-21 11:36:45.0 -0700
@@ -5,6 +5,7 @@
 Uploaders: Yaroslav Halchenko , Bernd Zeimetz 
 Build-Depends: debhelper (>= 9),
  autotools-dev (>= 20100122.1~),
+ dh-autoreconf,
  libgcrypt11-dev,
  chrpath
 Standards-Version: 3.9.3
diff -Nru freeipmi-1.4.11/debian/rules freeipmi-1.4.11/debian/rules
--- freeipmi-1.4.11/debian/rules	2016-09-05 00:55:48.0 -0700
+++ freeipmi-1.4.11/debian/rules	2016-09-13 10:43:25.0 -0700
@@ -4,7 +4,7 @@
 # --fail-missing for dh_install
 # --link-doc for dh_installdocs
 %:
-	dh $@ --with autotools_dev --fail-missing --link-doc=freeipmi-common
+	dh $@ --with autoreconf --fail-missing --link-doc=freeipmi-common
 
 override_dh_auto_configure:
 	: # suppress multiarch support for now

Bug#841653: Importing wand.image fails

[Martin Pitt]

Package: python3-wand
Severity: serious
Version: 0.3.9-1

Hello,

In current sid, at least in a minimal chroot, this module is broken:

  # apt-get install -y python3-wand
  # python3 -c 'import wand.image'
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/wand/image.py", line 21, in 
  from .color import Color
File "/usr/lib/python3/dist-packages/wand/color.py", line 12, in 
  from .version import QUANTUM_DEPTH
File "/usr/lib/python3/dist-packages/wand/version.py", line 95, in 
  *map(int, MAGICK_RELEASE_DATE_STRING.split('-')))
  TypeError: Required argument 'month' (pos 2) not found

This must have happened relatively recently. This is spotted by
autopkgtest's testsuite, and Lukas just reported that it's now failing
(#841548). It was still working on October 7 when I did the last
upload.

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#841654: uptimed: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: uptimed 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of uptimed 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

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#841652: metaphlan2-data: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: metaphlan2-data 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the Dutch translation of metaphlan2-data 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

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#841633: apt-cacher-ng: cron job fails when BindAddress is localhost

[Eduard Bloch]

Hallo,
* Peter Colberg [Fri, Oct 21 2016, 11:01:44AM]:
> Package: apt-cacher-ng
> Version: 1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After updating to the above version, the cron job fails with

>From which version? That's the real question.

> /etc/cron.daily/apt-cacher-ng:
> Error: cannot fetch 
> http://foo.example.org:3142/acng-report.html?doExpire=Start+Expiration=aOe,

There is no such hostname anywhere in the source. If you redacted the
output then you should mention this (and describe the real output),
otherwise we are hunting ghosts.

As stop-gap solution, you could set HOSTNAME variable as needed in the
mentioned cron script.

> My acng.conf differs from the default by one line,
> 
> BindAddress: localhost

In the previous times there was a creepy workaround that fished the
hostname from BindAddress strings as a last ressort. Maybe I should
recteate this method in acngtool.

Regards,
Eduard.

-- 
Every great idea is worthless without someone to do the work. --Neil Williams

Bug#841651: neutron: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: neutron 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of neutron 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

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#841650: apt-listbugs: [INTL:nl] Dutch po file for the apt-listbugs package

[Frans Spiesschaert]

 

Package: apt-listbugs 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the Dutch po file for the apt-listbugs 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

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#841548: autopkgtest: FTBFS: Tests failures

[Martin Pitt]

Control: tag -1 confirmed

Hello Lucas,


Lucas Nussbaum [2016-10-21 15:09 +0200]:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):

Not quite, the interesting portion is this:

|  File "/tmp/autopkgtest.2SwpBj/build.7IV/real-tree/debian/tests/t", line 2, 
in 
| from wand.image import Image
|   File 
"/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/image.py", 
line 21, in 
| from .color import Color
|   File 
"/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/color.py", 
line 12, in 
| from .version import QUANTUM_DEPTH
|   File 
"/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/version.py", 
line 95, in 
| *map(int, MAGICK_RELEASE_DATE_STRING.split('-')))
| TypeError: Required argument 'month' (pos 2) not found

So it looks like imagemagic changed recently, so at first sight I'll
just need to adjust the test case to that.

I'll look into this ASAP, thanks for the report!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#841437: [pkg-gnupg-maint] Bug#841437: gnupg-agent: --supervised segfaults immediately

[Daniel Kahn Gillmor]

On Thu 2016-10-20 12:46:10 -0400, Jindřich Makovička wrote:

> gnupg-agent --supervised in Debian Sid now crashes immediately on
> startup,

this seems to be true if none of the environment variables are set
(meaning it isn't actually being run under such a supervision proces).

> which makes it unusable with systemd.

I'm actually running it under systemd, so i don't think it makes it
unusable in that scenario.  we should get this fixed, though.

Thanks for catching this!

Regards,

--dkg

Bug#841648: mark distro-info-data Multi-Arch: foreign

[Helmut Grohne]

Package: distro-info-data
Version: 0.31
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:distro-info src:ecryptfs-utils src:lsb

The packages listed above cannot satisfy their cross Build-Depends,
because their (transitive) dependency on distro-info-data cannot be
satisfied. In general, Architecture: all packages cannot satisfy cross
dependencies unless marked Multi-Arch: foreign. In this case, the
marking is correct, because distro-info-data does not have any
maintainer scripts nor dependencies. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru distro-info-data-0.31/debian/changelog 
distro-info-data-0.31+nmu1/debian/changelog
--- distro-info-data-0.31/debian/changelog  2016-10-18 17:22:31.0 
+0200
+++ distro-info-data-0.31+nmu1/debian/changelog 2016-10-21 20:01:54.0 
+0200
@@ -1,3 +1,10 @@
+distro-info-data (0.31+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark distro-info-data Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 21 Oct 2016 20:01:31 +0200
+
 distro-info-data (0.31) unstable; urgency=medium
 
   [ Martin Pitt ]
diff --minimal -Nru distro-info-data-0.31/debian/control 
distro-info-data-0.31+nmu1/debian/control
--- distro-info-data-0.31/debian/control2016-10-18 17:22:31.0 
+0200
+++ distro-info-data-0.31+nmu1/debian/control   2016-10-21 20:01:29.0 
+0200
@@ -10,6 +10,7 @@
 
 Package: distro-info-data
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Breaks: distro-info (<< 0.3~)
 Replaces: distro-info (<< 0.3~)

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

[Thomas Pierson]

Hi Dio,

On 21/10/2016 18:53, Dio Oktarianos Putra wrote:
> Yeah, my clementine has that problem too which clementine need to depend on 
> gstreamer-0.10-ffmpeg.
> 
> But unfortunately, it's only avaliable on debian wheezy 
> (https://packages.debian.org/wheezy/gstreamer0.10-ffmpeg) and if you're using 
> >= jessie, it's only can be solved by deb-multimedia repo and install 
> gstreamer-0.10-ffmpeg manually.

In Stretch/Sid there are no Gstreamer0.10 and there are no Gstreamer
ffmpeg codecs anymore. The equivalent package you are looking for is
probably gstreamer1.0-libav. But this is only a set of optional plugins,
not a depend.

In fact, maybe you have the same gstreamer error message but I think you
have a totally different issue. And you are using unofficial
repositories like www.deb-multimedia.org which are known to be very
buggy and to cause breakages with many official packages.

So, don't hesitate to open a new bug report but please retry first with
a clean system without any unofficial package.

Thanks,
Thomas Pierson

Bug#841533: gcc-6: versions 6.2.0-[7-9] break construction of linux kernel with -fstack-protector-xxxx

[Jindřich Makovička]

Hi,

this is caused by -fPIC by default in latest debian packages. Kernel build
fails because -fPIC is incompatible with -mcmodel=kernel .

Example command line used for -fstack-protector test follows:

gcc -D__KERNEL__  -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -march=core2 -mno-red-zone
-mcmodel=kernel -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1
-DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_SHA1_NI=1
-DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -O2 -fstack-protector -fomit-frame-pointer
-DCC_HAVE_ASM_GOTO  -fstack-protector -c -x c /dev/null -o .18640.tmp

-- 
Jindřich Makovička

Bug#610131: Re; lmarbles: config file corrupted...

[Andrej Mernik]

Dear Maintainers,

this bug is still present in Jessie and will be present in future Debian 
releases unless the package gets updated to the latest upstream version.

Please consider updating to lmarbles version 1.0.8:
http://prdownloads.sourceforge.net/lgames/lmarbles-1.0.8.tar.gz

Best regards,
Andrej Mernik

Bug#841647: libreoffice: Random crashes on libreoffice while editing heavy document

[Dio Oktarianos Putra]

Package: libreoffice
Version: 1:4.3.3-2+deb8u5
Severity: important

Dear Maintainer,

I've problem with libreoffice while editing big file, sometime the document 
contains macro like math formula on .odt file and repeatly using same function 
such as undo too much, but potentially caused by my extensions too.

I saw something like this crash redirect to smartart extension (unfortunalely 
the file has been deleted accidently), but now it's gone after this problem 
reappeared again. I dunno anything what's going wrong here, it's occured on 
file with math formula macro: pastebin.com/68tAp5xi

My extensions on libreoffice are: smartart, chemistry, indonesian misspell 
id_id.oxt, and latest multisave.

Sorry for my bad english and thank you.

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

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

Versions of packages libreoffice depends on:
ii  fonts-dejavu   2.34-1
ii  fonts-sil-gentium-basic1.1-7
ii  libreoffice-avmedia-backend-gstreamer  1:4.3.3-2+deb8u5
ii  libreoffice-avmedia-backend-vlc1:4.3.3-2+deb8u5
ii  libreoffice-base   1:4.3.3-2+deb8u5
ii  libreoffice-calc   1:4.3.3-2+deb8u5
ii  libreoffice-core   1:4.3.3-2+deb8u5
ii  libreoffice-draw   1:4.3.3-2+deb8u5
ii  libreoffice-impress1:4.3.3-2+deb8u5
ii  libreoffice-java-common1:4.3.3-2+deb8u5
ii  libreoffice-math   1:4.3.3-2+deb8u5
ii  libreoffice-report-builder-bin 1:4.3.3-2+deb8u5
ii  libreoffice-writer 1:4.3.3-2+deb8u5
ii  python3-uno1:4.3.3-2+deb8u5

Versions of packages libreoffice recommends:
ii  fonts-liberation   1.07.4-1
ii  libpaper-utils 1.1.24+nmu4
ii  ttf-mscorefonts-installer  3.6

Versions of packages libreoffice suggests:
ii  cups-bsd1.7.5-11+deb8u1
ii  default-jre [java5-runtime] 2:1.7-52
pn  gstreamer1.0-ffmpeg 
pn  gstreamer1.0-plugins-bad
ii  gstreamer1.0-plugins-base   1.4.4-2
ii  gstreamer1.0-plugins-good   1.4.4-2
ii  gstreamer1.0-plugins-ugly   1.4.4-2+b1
ii  hunspell-en-us [hunspell-dictionary]20070829-6
pn  hyphen-hyphenation-patterns 
ii  icedove 1:45.4.0-1~deb8u1
ii  iceweasel   45.4.0esr-1~deb8u2
ii  imagemagick 8:6.8.9.9-5+deb8u5
ii  libgl1-mesa-glx [libgl1]10.3.2-1+deb8u1
pn  libreoffice-gnome | libreoffice-kde 
pn  libreoffice-grammarcheck
pn  libreoffice-help-4.3
ii  libreoffice-l10n-id [libreoffice-l10n-4.3]  1:4.3.3-2+deb8u5
pn  libreoffice-officebean  
ii  libsane 1.0.24-8+deb8u1
ii  libxrender1 1:0.9.8-1+b1
pn  myspell-dictionary  
pn  mythes-thesaurus
pn  openclipart-libreoffice 
ii  openjdk-7-jre [java5-runtime]   7u111-2.6.7-1~deb8u1
pn  pstoedit
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.3+deb8u1
ii  fonts-opensymbol  2:102.6+LibO4.3.3-2+deb8u5
ii  libatk1.0-0   2.14.0-1
ii  libboost-date-time1.55.0  1.55.0+dfsg-3
ii  libc6 2.19-18+deb8u6
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libclucene-contribs1  2.3.3.4-4
ii  libclucene-core1  2.3.3.4-4
ii  libcmis-0.4-4 0.4.1-7
ii  libcups2  1.7.5-11+deb8u1
ii  libcurl3-gnutls   7.38.0-4+deb8u4
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libeot0   0.01-3
ii  libexpat1 2.1.0-6+deb8u3
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglew1.10   1.10.0-3
ii  libglib2.0-0  2.42.1-1+b1
ii  libgltf-0.0-0 0.0.2-2
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgraphite2-31.3.6-1~deb8u1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libharfbuzz-icu0  0.9.35-2
ii  libharfbuzz0b 0.9.35-2
ii  libhunspell-1.3-0 1.3.3-3
ii  

Bug#835148: please do not make GCC incompatible, we have dpkg-buildflags for this! (was Re: Bug#837420: Processed: PIE FTBFS are now RC)

[Bálint Réczey]

Hi Thorsten

2016-10-21 19:11 GMT+02:00 Thorsten Glaser :
> Adrian Bunk dixit:
>
>>gcc-6 6.2.0-7 uploaded to unstable on Tue 18 Oct 2016 defaults to PIE,
>>see #835148 for details.
>
> Oh, thanks.
>
> This is *so* *totally* the wrong approach, especially as we
> have dpkg-buildflags, which was introduced *precisely* for
> this purpose, and to make Debian’s GCC not incompatible even
> more with the rest of the world.

You may have missed them, but there was several lengthy threads [1]
on debian-devel discussing the possible solutions including the
inapplicability of dpkg-buildflags for this problem.

However, if you do have a better _working_ solution for enabling PIE
archive-wide, please share that.

I'm exploring possible options like patching (upstream) GCC to disable
PIE for kernel or patching (upstream) kernel to disable PIE when it can
be disabled.

AFAIK the linux package is the only problematic package were the
maintainer refused to disable PIE from packaging scripts.

Cheers,
Balint

[1] https://lists.debian.org/debian-devel/2016/05/msg00229.html

Bug#841545: Pending fixes for bugs in the liborlite-perl package

[pkg-perl-maintainers]

tag 841545 + pending
thanks

Some bugs in the liborlite-perl package are closed in revision
c3d278d44143a67246910d90a2365edc49b88eee in branch 'master' by gregor
herrmann

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

Commit message:

Add patch to fix SQLite VACUUM usage in test suite.

Thanks: Lucas Nussbaum for the bug report.
Closes: #841545

Bug#841491: Inject A Task for Generating Maven POMs

[Emmanuel Bourg]

Le 21/10/2016 à 12:08, 殷啟聰 a écrit :
> I adjusted the indentation to 4 spaces and sorted the imports.

Thanks, looks better now :)


> A large number of packages builds multiple binary packages, where the
> maintainer need to specify which JARs should be installed to which
> binary packages. For now it is not clear which way is the best to
> handle this situation, so maybe we can think about generating
> $package.pom afterwards.

Ok, sounds fair.


> Finally, I think the `:clean` task simply removes the entire
> $buildDir, so maybe we don't need to declare the removal actions? I
> tested the plugin on various packages and `debuild clean` worked
> perfectly.

Sorry I misunderstood what $buildDir referred to. I thought the .pom
files were generated in the debian directory with the other packaging
files (control, changelog, rules, etc). If that's the build directory of
the Gradle module then that's fine.


It looks ok to me. Feel free to merge the changes and even upload the
new version if you want (that would be 1.4 since there is a new feature).

Emmanuel Bourg

Bug#736188: #736188 libtag1-dev: id3v22-tda.mp3 Considered Non-Free

[Matteo Cypriani]

Now fixed upstream, so the next release won't need repacking:

https://github.com/taglib/taglib/commit/
6a96a6426a4895a529c3bcde52d7cfe290b4d95a


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

Bug#841247: [Calypso-maint] Bug#841247: calypso: UnicodeDecodeError when importing an .ics

[Guido Günther]

control: -1 reassign python-vobject
control: -1 found 0.9.3-3
control: -1 forwarded https://github.com/eventable/vobject/issues/51

On Wed, Oct 19, 2016 at 01:16:16AM +0200, Jens Reyer wrote:
> Package: calypso
> Version: 1.5-3
> Severity: normal
> 
> Hi,
> 
> I tried to import the .ics of my old exported ownCloud calendar,
> but this failed with an UnicodeDecodeError. You may reproduce this
> (note the accent in Café):

This turns out to be in vobject (unfortunately I'm the maintainer of
that too so I've filed an upstream report).

Cheers,
 -- Guido

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

[pkg-go-maintainers]

tag 840311 + pending
thanks

Some bugs in the golang-google-cloud package are closed in revision
52c087cfe9eb28f69c2422ca726c6936701f43c0 in branch 'master' by
Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-google-cloud.git/commit/?id=52c087c

Commit message:

Increase timeouts in tests to avoid build failures. Closes: #840311.

Bug#281201: [bug #45790] wget prints it's progress even when background

[Tim Ruehsen]

Update of bug #45790 (project wget):

  Status:None => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/