Bug#858757: new upstream (1.6)

[Daniel Baumann]

Package: netdata

Hi,

it would be nice if you could upgrade to the current upstream version (1.6).

Regards,
Daniel

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Daniel Richard G.]

Hi Rene,

On Sat, 2017 Mar 25 23:54+0100, Rene Engelhard wrote:
>
> Because you install the metapackage which installs those "all
> components". And libreoffice-base (well, its internal database) _is
> written in Java_.

My intention is to install LibreOffice as a whole minus the Java stuff.

As I understand it, some LO stuff is in Java, but not much. The Java
stuff is notorious for being slow, and as I'm not aware of anyone at my
site needing it, I want to not even install it.

> Yes. Note that "libreoffice" DOES NOT depend on the JRE or Java
> libs itself.
>
> That's pulled in by -base and -report-builder.

Of course. I don't care too much which specific components need Java
(unless e.g. Writer one day starts requiring it); I just want to tell
apt-get "no Java!" and let it do its thing.

> > Let's try installing sans what appears to be LibreOffice's main Java-
> > dependency package:
>
> It's the base stuff without which Java stuff inside LO won't work.
> Basically anything needed for Java in LO is inside that one (besides
> those which belong into the UNO runtime environment or have
> specializied packages).

Right. I'd like to be able to say, let's not install that package
(lo-java-common), and end up with a clean install of LO sans Java stuff.

> > This doesn't make much sense to me. I can't decline installation of
> > lo-java-common, but I can decline default-jre, yet some of the
> > resulting
>
> It does make perfect sense.

How are the *.jar files in lo-java-common useful without a Java runtime?
It doesn't make sense to me for the dependencies to say that these files
are required, when the component required to use them does not need to
be installed.

> > installed packages are useless (lo-report-buildir-bin without
> > lo-report-builder?) or at worse broken.
>
> lo-report-builder-bin without -report-builder installed is not
> breaking stuff. It's more or less a noop. It's installed because in a
> standard upstream install it's in "core" packages afaicr (witgh -report-
> builder being in a extra "package" there, too)
>
> In fact, the RB is in report-builder and report-builder-bin is just
> arch-dep support libraries and it appears only then.

Installing a support package that is not used is better than installing
a broken package, but it is still the result of inaccurate package
dependency information. It doesn't make sense to install just lo-r-b-bin
and not lo-r-b.

(This particular issue is more a symptom of the problem, than a real
problem in itself.)

> > Looking through the dependencies in the various LibreOffice
> > packages, one issue I see is that several of them depend directly on
> > default-jre (or more specifically, "default-jre | openjdk-8-jre |
> > openjdk-7-jre | openjdk-6-jre | gcj-jre | sun-java5-jre | sun-java6-jre
> > | java5-runtime | jre") as well as lo-java-common, when the JRE
> > dependency should in fact be redundant alongside lo-java-common.
>
> No, why should simple support libraries (and this is -java-common)
> depend on a JRE? Stuff needing a JRE should depend on a JRE, not some
> "random" package containing just libraries. Doing this causes many
> issues also for normal Java library packages in Debian. Count this
> package as having only many LO-internal Java libraries.

The dependency need not be a Depends:... Recommends: would be fine too.

> > What I would like to see is for all the various LibreOffice packages
> > that can/must make use of Java to Depends:/Recommends:/Suggests:
>
> That is *exactly* what we have right now.

My apologies, I left out an important bit in that paragraph: to also
move all the JRE dependencies to lo-java-common. So when LO as a whole
is being installed, the only package that actually pulls in the JRE is
lo-java-common.

Think of it as a bottleneck in the dependency graph. This then makes it
easy to pull out that dependency.

> libreoffice installs everything you need. Including a JRE.
>
> If you don't want it/want more control, install the various modules
> yourself. The only one where you really do need Java is Base (and
> the script providers mentioned above and the Java-based extensions
> of course)

"libreoffice" already does not have a hard dependency on a JRE, so there
is no need to give up the metapackage abstraction. I can do without Base
if that absolutely requires a Java runtime, and the other stuff isn't
interesting.

(I don't want to start worrying about the list of all the various
LibreOffice components, because that defeats the purpose of having
metapackages.)

> > lo-java-common, and then have lo-java-common Depends: default-jre et
> > al. That way, when installing LibreOffice, I can decline lo-java-
> > common, the JRE won't get pulled in, and no LibreOffice package that
> > requires Java (or is related to one that does) will get installed.
>
> If you install "libreoffice" you install Base.
>
> Which 100% needs Java right now (because of -sdbc-hsqldb). Of course,
> if you disable Recommends:, you won't see it, but it's 

Bug#837893: systemd: Logging from gnome session is passed on to all syslog facilities

[Nathan Dorfman]

I think these messages are being (erroneously) passed specifically to
the KERN facility, not all facilities as the summary states.

For one thing, the superfluous messages don't appear in the user.log
file, as they do in kern.log, despite the fact that rsyslogd is
configured to route all facility=USER messages there, as per the
Debian default:

root@stretch:/var/log# fgrep -c 'Mar 25 21:07:16 stretch NetworkManager[423]: 
  [1490497636.9242] manager: startup complete' kern.log syslog user.log
kern.log:1
syslog:1
user.log:0
root@stretch:/var/log# egrep '(user|kern).log' /etc/rsyslog.conf 
kern.*  -/var/log/kern.log
user.*  -/var/log/user.log
root@stretch:/var/log# 

For another, after configuring rsyslogd with a custom template that
includes the facility (and priority) with each message, the offending
messages consistently have facility=KERN in every file in which they
do appear:

root@stretch:/var/log# fgrep template /etc/rsyslog.conf
$template MyFormat,"%pri-text%: %timegenerated% %HOSTNAME% 
%syslogtag%%msg:::drop-last-lf%\n"
root@stretch:/var/log# fgrep -R 'Mar 25 21:35:19 stretch NetworkManager[423]: 
  [1490499319.1248] device (ens3): Activation: successful, device 
activated.'
messages:kern.info: Mar 25 21:35:19 stretch NetworkManager[423]:  
[1490499319.1248] device (ens3): Activation: successful, device activated.
kern.log:kern.info: Mar 25 21:35:19 stretch NetworkManager[423]:   
[1490499319.1248] device (ens3): Activation: successful, device activated.
syslog:kern.info: Mar 25 21:35:19 stretch NetworkManager[423]:  
[1490499319.1248] device (ens3): Activation: successful, device activated.
root@stretch:/var/log#

I'll go on the record with a prediction that this will turn out to be
directly related to the fact that the numeric value representing the
KERN facility is zero:

root@stretch:/var/log# fgrep KERN /usr/include/*/sys/syslog.h
#define LOG_KERN(0<<3)  /* kernel messages */
{ "kern", LOG_KERN },
root@stretch:/var/log# 

Anyway, this problem also exists on jessie, with systemd 215.
NetworkManager doesn't exhibit the problem there, making it less
noticeable, but gnome-session and pulseaudio can be seen in the
kern.log file.

One acceptable workaround seems to be to just disable the broken
functionality altogether, with ForwardToSyslog=no in
/etc/systemd/journald.conf, and just use journalctl(1) to view those
messages. Note, however, that the journal is only stored under /run by
default and so will be lost on shutdown; to avoid that, you simply
have to create the default directory /var/log/journal, and it will be
persisted there.

-nd.

Bug#175064: DocBook XML conversion is read with this script

[Russ Allbery]

Guillem Jover  writes:

> Oh, I guess I was not clear, I was referring to the XML converted from
> the SGML, which will become the new source from where all output formats
> will be generated, so it would definitely be looked at (I'd hope! :).

> If you run the script, you'll see the resulting converted output, if
> that looks fine, then, good. :)

Oh, I see.  I think we can live with this.

> Sounds good to me. I can probably check several of those over time
> once this is merged in.

> In which case I can rebase, check that everything is fine, and resend
> the scripts to run the conversion to the bug.

Thanks, that sounds great!

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

Bug#806879: xsp: FTBFS when built with dpkg-buildpackage -A (dh_clideps fails)

[tony mancill]

Package: src:xsp
Followup-For: Bug #806879

Hi Debian Mono Group,

The workaround patch works fine.  Is there anything preventing an
upload?  Would the team be okay with an NMU?

Thanks,
tony


signature.asc
Description: PGP signature

Bug#833440: wmweather+: please make the build reproducible

[Martin Stigge]

On Thu, 2017-03-23 at 20:43 +, Chris Lamb wrote:
> > 
> > Would you consider applying this patch and uploading?
> Friendly ping on this :)

Oh, sorry, overlooked this. Sure, will prepare an upload in the next
days.

Regards,
Martin

Bug#175064: DocBook XML conversion is read with this script

[Guillem Jover]

On Mon, 2017-02-20 at 13:16:25 -0800, Russ Allbery wrote:
> Guillem Jover  writes:
> > I've found the problem with the wrong spacing, which was due to tidy(1),
> > I've played now with xmllint(1) and pandoc(1), but disabled the initial
> > cleanup for now (branch updated). So the converted XML is not indented,
> > but I'm not sure if you are fine with that.
> 
> I'm totally fine with that.  I honestly don't care whether the generated
> XML is particularly readable.  It would be minorly nice, but meh, it's an
> output format, and very few people are ever going to look at it.  If it
> makes maintenance easier, let's not worry about it.

Oh, I guess I was not clear, I was referring to the XML converted from
the SGML, which will become the new source from where all output
formats will be generated, so it would definitely be looked at (I'd
hope! :).

If you run the script, you'll see the resulting converted output, if
that looks fine, then, good. :)

> > I'm including a patchset which fixes several things that will make the
> > conversion easier, and I think they are correct independently of the
> > conversion.
> 
> Thanks!  These have all been applied.

Perfect, thanks!

> > The remaining possible output issues/differences are:
> 
> >   * The Abstract and Copyright Notice end up w/o any heading, so it's
> > a bit hard to distinguish.
> >   * The authors are listed at the top of the documents instead of at
> > the bottom.
> >   * The policy version and date are not output.
> >   * The upgrading-checklist.xml output generates a TOC, the new
> > html-notoc.dsl needs to be hooked into the build machinery to
> > avoid that.
> >   * The PDF/PS output for policy.xml probably needs some tuning.
> >   * The build dependencies might need checking for additions or
> > removals.
> >   * The XML is not shipped for some of the converted documents, I'm
> > not sure why the SGML was being shipped before?
> 
> I don't think there's any need to ship the SGML in the installed package.
> 
> Honestly, all of this sounds minor enough that I would be very tempted to
> just pull the trigger and do the conversion.

Sounds good to me. I can probably check several of those over time
once this is merged in.

In which case I can rebase, check that everything is fine, and resend
the scripts to run the conversion to the bug.

> > OTOH, the output seems less cluttered which looks like an improvement
> > to me.
> 
> Yeah, that's been one of the things that's made me unhappy about the text
> output for some time.
> 
> Thank you for working on this!

No problem!

Thanks,
Guillem

Bug#858756: sqlite3: debian/* files are licensed under GPLv2+

[Mohammed Sadiq]

Source: sqlite3
Severity: serious

Dear Maintainer,

  The license file[0] of src:sqlite3 states that the debian/* files
are licensed under GPLv2+. Which means that the debian specific patches
are applied as GPLv2+, which in turn may convert the whole package into 
GNU GPLv2+.

This may make the libraries (libsqlite3, and so on) too to be licensed under
GNU GPLv2+, and thus every library and package linked to it to be too
licensed under GNU GPLv2+ (or even GNU GPLv3+).

Right now, the patches are so small to have any legal issues with it (I hope),
but it would be better to let the patches have the same license as the file
to which it is applied.

It is okay to have debian/* to GPLv2+ license (I myself am happy to see more GNU
GPL packages), but debian/patches/* should follow the package license.

This may cause unintended harms to people who are giving commercial support
to their own application AND the Debian (or Derivatives) installation.

I didn't find such a suggestion in debian policy. Or am I wrong?


Thanks

[0] 
http://metadata.ftp-master.debian.org/changelogs/main/s/sqlite3/unstable_copyright

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

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

-- no debconf information

Bug#856808: error during mount: first meta block group too large

[Sven Hartge]

On Mon, 20 Mar 2017 12:42:32 +0100 Sven Hartge  wrote:

> I'd really like to see this fixed in Debian (and the LTS branch 4.9 in
> general), because after doing some test upgrades in clones of some of my
> older systems this problem shows up in 3 of 12 of them, breaking them
> hard after the upgrade.

The needed patch is in the queue for 4.9.18:

Message-ID: <20170324151226.795130...@linuxfoundation.org>

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#858755: ibus suddenly now needs its own X-window

[積丹尼 Dan Jacobson]

Package: ibus
Version: 1.5.14-2

Starting today (after update of gtk stuff?) suddenly
ibus takes up its own 4th tab at the bottom of the screen,
and no longer shows up in the lower right, but instead has its own
X-window at the upper left. And nothing I can do will fix it.



-- Package-specific info:
default-display-manager: /usr/sbin/nodm
ibus is /usr/bin/ibus
ibus-setup is /usr/bin/ibus-setup

!
!!! im-config is missing.  Please install it. !!!
!!! Please also read usr/share/doc/im-config/README.Debian.gz !!!
!

XMODIFIERS=@im=ibus
GTK_IM_MODULE=ibus
QT4_IM_MODULE=
QT_IM_MODULE=ibus
XDG_DATA_DIRS=
XDG_MENU_PREFIX=
PATH=~/bin:/usr/bin:/bin

ls -l /usr/lib/ibus/
total 556
-rwxr-xr-x 1 root root  18504 12-10 14:26 ibus-dconf
-rwxr-xr-x 1 root root 136144 2016-06-19  ibus-engine-chewing
-rwxr-xr-x 1 root root  14408 12-10 14:26 ibus-engine-simple
-rwxr-xr-x 1 root root  85528 2016-06-19  ibus-setup-chewing
-rwxr-xr-x 1 root root 211080 12-10 14:26 ibus-ui-gtk3
-rwxr-xr-x 1 root root  91848 12-10 14:26 ibus-x11

-- System Information:
Debian Release: 9.0
  APT prefers experimental
  APT policy: (990, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages ibus depends on:
ii  adwaita-icon-theme   3.22.0-1
ii  dconf-cli0.26.0-2+b1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-ibus-1.0  1.5.14-2
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libdconf10.26.0-2+b1
ii  libgdk-pixbuf2.0-0   2.36.5-3
ii  libglib2.0-0 2.52.0-1
ii  libgtk-3-0   3.22.11-1
ii  libibus-1.0-51.5.14-2
ii  libnotify4   0.7.7-1+b1
ii  libpango-1.0-0   1.40.4-1
ii  libpangocairo-1.0-0  1.40.4-1
ii  librsvg2-common  2.40.16-1+b1
ii  libx11-6 2:1.6.4-3
ii  libxi6   2:1.7.9-1
ii  python3-gi   3.22.0-2
pn  python3:any  

Versions of packages ibus recommends:
pn  ibus-gtk | ibus-qt4 | libqt5gui5   
pn  ibus-gtk3 | ibus-qt4 | libqt5gui5  
pn  im-config  

Versions of packages ibus suggests:
pn  ibus-clutter  
pn  ibus-doc  
pn  ibus-qt4  
pn  libqt5gui5

-- no debconf information

Bug#858754: dislocker: Unable to mount dislocker volume in fstab

[mappu]

Package: dislocker
Version: 0.6.1-7
Severity: normal

Hi Maintainer,

I am trying to automatically load a Bitlocker drive via fstab.

My configuration is something like this:
  /dev/sdb2 /media/dislocker/ fuse.dislocker 
recovery-password=xyz-xyz-xyz-xyz-xyz-xyz,nofail 0 0


When running `mount -a`, i immediately get the error message:
  [CRITICAL] No BitLocker volume path given. Abort.

Basically, it's the same as this upstream bug[1] which is fixed in a new 
release.


Is it possible to please package the newer release of dislocker?

Regards,
mappu

1. https://github.com/Aorimn/dislocker/issues/68


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

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

Versions of packages dislocker depends on:
ii  libc62.24-9
ii  libdislocker0.6  0.6.1-7
ii  libfuse2 2.9.7-1
ii  libmbedcrypto0   2.4.2-1
ii  libruby2.3   2.3.3-1
ii  ruby 1:2.3.3

dislocker recommends no packages.

dislocker suggests no packages.

-- no debconf information

Bug#856441: Please restore OpenRD support - works, yay! also on openrd ultimate

[Rick Thomas]

On 03/25/17 17:40, Rick Thomas wrote:



On 03/08/17 17:44, Vagrant Cascadian wrote:

On Feb 28, 2017, at 6:39 PM, Martin Michlmayr  wrote:

Debian introduced OpenRD images and later removed them because the
stopped working (see #837629).

A fix has now been posted upstream:
https://lists.denx.de/pipermail/u-boot/2017-February/282676.html


Grabbed the patch from upstream, included in and built some packages for
you to test:

  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main

Should have a u-boot for armel with the upstream patch applied, and the
openrd* boards enabled.

Please follow-up with how the tests went...



I would like to kindly request that the OpenRD images be restored
for stretch.  The reasons are:

* stretch will be the last release to include support for the armel
  architecture, so it would be good to get support for this device
  as complete as possible.
* While Debian can be installed with the default u-boot shipped on
  the OpenRD, the one provided by Debian is much more modern.

On the other hand, there are few OpenRD users, so this is not high
priority.

I haven't spoken to the release team but in the past they have been
supportive towards changes for hardware support.


If testing goes well, we'll see what the release team thinks...



Rick Thomas has offered to test on the OpenRD Ultimate and (I believe)
Client.


And Phil Hands too. Yay!


live well,
  vagrant



Sorry it took me so long to get to this test.
Real-life's a demanding mistress!

I'm now running
U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +)
on my openrd client test machine.  It boots just fine.

I'm looking forward to seeing this in Jessie!

Thank you very much!

Rick


I just installed it on my openrd ultimate as well.  Works a treat!

Thanks!
Rick

Bug#858731: Please bump CONFIG_NR_CPUS to 256 on s390x

[Ben Hutchings]

Control: found -1 4.9.16-1

On Sat, 2017-03-25 at 18:42 +0100, Philipp Kern wrote:
> Source: linux
> Version: 3.16.39-1
> 
> Currently linux's kconfig in stable/testing/unstable sets
> CONFIG_NR_CPUS=32 on s390x. This is unhelpful when you have more cores
> than that assigned to a VM/LPAR. Reportedly all of SUSE, RedHat, and
> Ubuntu set it to 256 these days. Our amd64 config sets it to 512. I'd
> suggest bumping it at least to 256 in the Debian package.
> 
> (This actually came up as a problem on the LINUX-360 mailing list.)
> 
> Kind regards and thanks for considering the change

This will cause an ABI change so is unlikely to be done in stable.  But
 we should be able to make this change before stretch.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg


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

Bug#856441: Please restore OpenRD support - works, yay!

[Rick Thomas]

On 03/08/17 17:44, Vagrant Cascadian wrote:

On Feb 28, 2017, at 6:39 PM, Martin Michlmayr  wrote:

Debian introduced OpenRD images and later removed them because the
stopped working (see #837629).

A fix has now been posted upstream:
https://lists.denx.de/pipermail/u-boot/2017-February/282676.html


Grabbed the patch from upstream, included in and built some packages for
you to test:

  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main

Should have a u-boot for armel with the upstream patch applied, and the
openrd* boards enabled.

Please follow-up with how the tests went...



I would like to kindly request that the OpenRD images be restored
for stretch.  The reasons are:

* stretch will be the last release to include support for the armel
  architecture, so it would be good to get support for this device
  as complete as possible.
* While Debian can be installed with the default u-boot shipped on
  the OpenRD, the one provided by Debian is much more modern.

On the other hand, there are few OpenRD users, so this is not high
priority.

I haven't spoken to the release team but in the past they have been
supportive towards changes for hardware support.


If testing goes well, we'll see what the release team thinks...



Rick Thomas has offered to test on the OpenRD Ultimate and (I believe)
Client.


And Phil Hands too. Yay!


live well,
  vagrant



Sorry it took me so long to get to this test.
Real-life's a demanding mistress!

I'm now running
U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +)
on my openrd client test machine.  It boots just fine.

I'm looking forward to seeing this in Jessie!

Thank you very much!

Rick

Bug#858556: In case the code is not anywhere...

[Santiago Garcia Mantinan]

> Maybe it was just that the original code had to be at the 
> upgrade|install-upgrade
> block of the case?
> 
> But why is the -d /etc/squid3 checked?

I followed this two questions doing some tests on my system and it looks to
me as we should be happy with this patch:

--- /tmp/squid.preinst  2017-03-26 01:27:31.201012140 +0100
+++ debian/squid.preinst2017-03-26 00:59:34.433577481 +0100
@@ -26,6 +26,8 @@
/etc/squid3/errorpage.css /etc/squid/errorpage.css 3.5.4-1~ 
squid3 -- "$@"
 fi
 
+case "$1" in
+   upgrade|install-upgrade)
 #
 # If the squid (2.7) package was being used previously protect
 # the squid.conf file, which was not tracked as a conffile.
@@ -34,12 +36,9 @@
 # Except when a squid3 package was used, since we do want the
 # debconf questions to appear as the packages get merged.
 #
-if dpkg --compare-versions "$2" lt '2.8' && test -d /etc/squid3; then
+if dpkg --compare-versions "$2" lt '2.8'; then
mv /etc/squid/squid.conf /etc/squid/squid.conf.pre3.5_upgrade
 fi
-
-case "$1" in
-   upgrade|install-upgrade)
;;
abort-upgrade)
exit 0

Which basically means to move the check to the upgrade|install-upgrade
section and remove the check for the squid3 dir.

My tests of both an upgrade from 2.7 and from jessie's squid3 work ok.

Amos, I don't know what your idea with this code was, so I'd like to talk
about it a bit before uploading a new version.

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

Bug#858753: Packages up for review

[Hans van Kranenburg]

Using the ITP bug number, I rebuilt the packages with the Closes: in the
changelog and put them up here:

https://syrinx.knorrie.org/~knorrie/btrfs/debian/

Hans van Kranenburg

Bug#858146: release.debian.org: unblock (pre-approval): augeas/1.7.0-1

[Hilko Bengen]

Control: tags -1 -moreinfo

>> +  * Add Multi-Arch support (Closes: #715554)
>
> Changing that during the freeze is not OK.

Alright, thanks you. I have backed that change out.

> Please go ahead with the first set of changes listed above and remove the
> moreinfo tag from this bug once the package is in unstable and builds on all
> relevant arches.

I have done the upload and the package has been built.

Cheers,
-Hilko

Bug#858753: ITP: python-btrfs -- python module to inspect btrfs filesystems

[Hans van Kranenburg]

Package: wnpp
Severity: wishlist
Owner: Hans van Kranenburg 

* Package name: python-btrfs
  Version : 6
  Upstream Author : Hans van Kranenburg 
* URL : https://github.com/knorrie/python-btrfs/
* License : GPL-2
  Programming Lang: Python 3
  Description : python module to inspect btrfs filesystems

Project Goal

Currently, the primary goal of this module is to be able to inspect the
internals of an existing filesystem for educational purposes.

A second goal is to provide a nicer way for automating administration
tasks and writing monitoring scripts by being able to just
programmatically access the needed information, instead of having to
spend most of the time on parsing human readable output from other btrfs
tools.

The python module acts as a wrapper around the low level kernel calls
and btrfs data structures, presenting them as python objects with
interesting attributes and references to other objects.

Development progress

The module currently gained a quite good coverage of the kernel API and
metadata structures to be useful for many introspection tasks.
Documentation in tutorial form is still lacking, but the git commit
history has a wealth of documentation on all parts of the code.

 >8 

I already found a mentor to help with review and uploading. The debian
packaging files are part of the project itself. I've been keeping
debian packages for the library in our own debian package repository at
work for the last year, but now is the time to finish polishing it and
make it available for Debian itself.

As soon as I get the bug # back from this post, I'll built the proposed
packages again and reply with a link to a location where they are
available for review.

Additionally, I'm preparing a second ITP for a package that will already
be using this library to visualize disk space usage of a btrfs
filesystem: https://github.com/knorrie/btrfs-heatmap

Regards,
Hans van Kranenburg

Bug#858752: w_scan does not find the German DVB-T2 HD channels

[Bruno Haible]

Package: w-scan
Version: 20141122-1

On an Ubuntu 2016.04 LTS system, with a TechnoTrend CT2-4400 TV tuner stick,
I compare the results of different versions of w-scan (in Frankfurt am Main,
Germany, using the command "w_scan -c DE"):

1) Version 20141122-1, included in Ubuntu,
2) Version 20161022-1, downloaded from https://packages.debian.org/sid/w-scan
3) Upstream version 20170107, downloaded from
   http://wirbel.htpc-forum.de/w_scan/index2.html and compiled myself.

Result:
1) finds 41 channels
2) finds 21 channels
3) finds 47 channels

In particular, the most interesting HD (High Definition) channels are only found
by version 3).

Please upgrade to the newer version soon!

w_scan -c DE 
w_scan version 20141122 (compiled for DVB API 5.10)
using settings for GERMANY
DVB aerial
DVB-T Europe
scan type TERRESTRIAL, channellist 4
output format vdr-2.0
output charset 'UTF-8', use -C  to override
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 -> TERRESTRIAL "Silicon Labs Si2168": very 
good :-))

Using TERRESTRIAL frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_ 
Using DVB API 5.10
frontend 'Silicon Labs Si2168' supports
DVB-T2
INVERSION_AUTO
QAM_AUTO
TRANSMISSION_MODE_AUTO
GUARD_INTERVAL_AUTO
HIERARCHY_AUTO
FEC_AUTO
FREQ (55.00MHz ... 862.00MHz)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 
Scanning DVB-T...
Scanning 7MHz frequencies...
177500: (time: 00:00.016) 
184500: (time: 00:02.048) 
191500: (time: 00:04.084) 
198500: (time: 00:06.120) 
205500: (time: 00:08.140) 
212500: (time: 00:10.172) 
219500: (time: 00:12.196) 
226500: (time: 00:14.228) 
Scanning 8MHz frequencies...
474000: (time: 00:16.252) 
482000: (time: 00:18.284) signal ok:QAM_AUTO f = 482000 kHz 
I999B8C999D999T999G999Y999 (0:0:0)
QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating 
transport_stream_id: -> (0:0:514)
QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 (0:0:514) : updating 
network_id -> (0:12290:514)
QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 (0:12290:514) : 
updating original_network_id -> (8468:12290:514)
updating transponder:
   (QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 
(8468:12290:514)) 0x
to (QAM_16   f = 482000 kHz I999B8C23D0T8G4Y0 (8468:12290:514)) 0x405A
49: (time: 00:26.368) 
498000: (time: 00:28.396) 
506000: (time: 00:30.424) 
514000: (time: 00:32.452) 
522000: (time: 00:34.484) 
53: (time: 00:36.512) 
538000: (time: 00:38.528) 
546000: (time: 00:40.564) 
554000: (time: 00:42.588) 
562000: (time: 00:44.616) 
57: (time: 00:46.636) 
578000: (time: 00:48.660) signal ok:QAM_AUTO f = 578000 kHz 
I999B8C999D999T999G999Y999 (0:0:0)
QAM_AUTO f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating 
transport_stream_id: -> (0:0:8706)
QAM_AUTO f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:8706) : 
updating network_id -> (0:12322:8706)
QAM_AUTO f = 578000 kHz I999B8C999D999T999G999Y999 (0:12322:8706) : 
updating original_network_id -> (8468:12322:8706)
updating transponder:
   (QAM_AUTO f = 578000 kHz I999B8C999D999T999G999Y999 
(8468:12322:8706)) 0x
to (QAM_16   f = 578000 kHz I999B8C23D0T8G4Y0 (8468:12322:8706)) 0x405A
586000: (time: 00:55.056) 
594000: (time: 00:59.596) 
602000: (time: 01:04.076) signal ok:QAM_AUTO f = 602000 kHz 
I999B8C999D999T999G999Y999 (0:0:0)
QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating 
transport_stream_id: -> (0:0:38912)
QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 (0:0:38912) : 
updating network_id -> (0:12440:38912)
QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 (0:12440:38912) : 
updating original_network_id -> (8468:12440:38912)
updating transponder:
   (QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 
(8468:12440:38912)) 0x
to (QAM_16   f = 602000 kHz I999B8C23D0T8G4Y0 (8468:12440:38912)) 0x405A
61: (time: 01:10.716) 
618000: (time: 01:12.752) signal ok:QAM_AUTO f = 618000 kHz 
I999B8C999D999T999G999Y999 (0:0:0)
QAM_AUTO f = 618000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating 
transport_stream_id: -> (0:0:17920)
QAM_AUTO f = 618000 kHz I999B8C999D999T999G999Y999 (0:0:17920) : 
updating network_id -> (0:12358:17920)
QAM_AUTO f = 618000 kHz I999B8C999D999T999G999Y999 (0:12358:17920) : 
updating original_network_id -> (8468:12358:17920)
updating transponder:
   (QAM_AUTO f = 618000 kHz I999B8C999D999T999G999Y999 
(8468:12358:17920)) 0x
to (QAM_16   f = 618000 kHz I999B8C23D0T8G4Y0 (8468:12358:17920)) 0x405A
626000: (time: 01:17.648) 
634000: (time: 01:19.676) 
642000: (time: 01:21.692) 
65: (time: 01:23.728) 
658000: (time: 01:25.764) 
666000: (time: 01:27.800) 
674000: (time: 01:29.820) 
682000: (time: 01:34.360) 
69: (time: 01:36.392) 
698000: (time: 01:38.424) 

Bug#858305: [Python-modules-team] Bug#858305: celeryd: celerdy should depend on python-celery-common?

[Brian May]

Nish Aravamudan  writes:

>> I have pushed a change through to git that will fix this on the next
>> release.

I just uploaded this to unstable. Are you able to test this?

(note I did not fix the bashism issue yet)

Thanks
-- 
Brian May 

Bug#858565: [PKG-Openstack-devel] Bug#858565: neutron-l3-agent: IPv6 Stateless Address Auto Configuration (SLAAC) mode fails when radvd is not installed on the host

[Thomas Goirand]

On 03/24/2017 09:58 AM, Alberto Molina Coballes wrote:
> 2017-03-24 1:26 GMT+01:00 Thomas Goirand  >:
> 
> 
> Hi,
> 
> Unfortunately, not everyone wants to use IPv6. For those who don't,
> imposing radvd as a hard dependency is a bad idea. IMO, it's best to let
> every user choose what it wants to do to match its use case, and
> manually install radvd.
> 
> 
> Hi Thomas,
> 
> There's no reference about the need to install radvd to configure
> neutron with IPv6 support in the documentation and IMO is confusing when
> a configuration option fails because a necessary package is not
> installed. radvd is a small package with no additional dependencies, so
> I don't think is bad idea to include it as a dependency.

The problem isn't the size of the package or its eventual dependencies.
The issues is that we want to allow to *not* install or run radvd if a
user doesn't want it. Indeed, it may destroy an already running ipv6
setup, or add a potentially not necessary complexity and security
surface of attack that one may now want.

> We could add radvd as Suggests: though, but that is too late to ask for
> a migration exception, so this change wont be in Stretch.
> 
> Yes, I agree with you, it's too late for Stretch but maybe it could be
> included in the next release.

Will do.

Thomas Goirand (zigo)

Bug#858579: /usr/share/man/man5/deb-changelog.5.gz: please support a comment syntax for Debian changelog files

[G. Branden Robinson]

On Sat, Mar 25, 2017 at 03:07:32PM +0100, Guillem Jover wrote:
> The implementation in dpkg-dev already supports all of this
> (see man Dpkg::Changelog::Debian), including:

Section 3 manpages for Perl modules?  Will wonders never cease?  ;-)

Thanks--I was utterly unaware of this.

> So I guess your request would be to officialize (at least the proper
> comment markers ‘#’) as supported, in the spec. I'll probably mention
> this on the debian-policy mailing list, but I guess I should just do
> it (perhaps all the currently accepted syntax) because if someone wants
> to code an alternative implementation, they will have to replicate the
> logic, or it will be unable to parse existing changelogs.
> 
> Also because dpkg can always be more lax than policy, and this is the
> case right here.

Yes, that's precisely what I'm shooting for.

I urge you to go ahead and do it; it's obviously not a breaking change.

My longer-term objective here is to write (or persuade someone to write)
a Vim syntax highlighter for Debian copyright files, and for that it
would be helpful to have an implementation-independent spec for the file
format.  I was looking to the existing highlighting for deb-control and
deb-changelog files, when I noticed that Vim was highlighting my
existing comment line in xtrs's debian/changelog with ugly white-on-red.

It'll be easier to get that fixed if I can point to it being part of the
sepc, though in the meantime I'm happy to appeal to your authority.  ;-)

-- 
Regards,
Branden

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Rene Engelhard]

On Sun, Mar 26, 2017 at 12:10:35AM +0100, Rene Engelhard wrote:
> [...] *And* it will also tell people to install libreoffice-java-common [...]

Actually that's untrue - the patch is disabled, probably because it didn't apply
anymore and it was forgotten to update.. ;/

Regards,
  
Rene

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Rene Engelhard]

Hi,

On Sun, Mar 26, 2017 at 12:01:53AM +0100, Rene Engelhard wrote:
> On Fri, Mar 24, 2017 at 07:00:22PM -0400, Daniel Richard G. wrote:
> > # apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep 
> > 'jre|jdk|java'
> > Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all])
> > 
> > Hunh, that worked. The lo-java-common package went in, even though it's
> > presumably useless without a Java runtime. So what about those
> > aforementioned components that supposedly required Java?

One could argue -java-common should suggest or recommend a JRE, but I am a bit
wary of that, as said, you don't _need_ it for "normal" LO operation.

If LO notices there's no JRE it will tell people. *And* it will also tell
people to install libreoffice-java-common if people want/need Java suport and 
there's
no JRE.

The necessary mechanism for that is in ure.

> > # apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep 
> > 'nlpsolver|report-builder|wiki-publisher'
> > Inst libreoffice-report-builder-bin (1:5.2.5-2 Debian:testing [amd64])
> > Inst libreoffice-wiki-publisher (1.2.0+LibO5.2.5-2 Debian:testing [all])
> > 
> > So nlpsolver didn't go in (reasonable), only the bin package of
> > report-builder was installed (huh?), and wiki-publisher went in just
> > fine (will that even work in light of its hard dep on lo-java-common?).
> 
> That is interesting, though. They are *extensions* to LO, though, whereas
> -sdbc-hsqldb is a _core_ component. But yeah, probably they should depend
> on default-jre etc, too - as -sdbc-hsqldb does.

-nlpsolver does.

Will add a dependency on the JRE to libreoffice-wiki-publisher. That was indeed
missing.

No idea whether it will make stretch, though.

Regards,
 
Rene

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Rene Engelhard]

Hi,

On Fri, Mar 24, 2017 at 07:00:22PM -0400, Daniel Richard G. wrote:
> # apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep 
> 'jre|jdk|java'
> Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all])
> 
> Hunh, that worked. The lo-java-common package went in, even though it's
> presumably useless without a Java runtime. So what about those
> aforementioned components that supposedly required Java?
> 
> # apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep 
> 'nlpsolver|report-builder|wiki-publisher'
> Inst libreoffice-report-builder-bin (1:5.2.5-2 Debian:testing [amd64])
> Inst libreoffice-wiki-publisher (1.2.0+LibO5.2.5-2 Debian:testing [all])
> 
> So nlpsolver didn't go in (reasonable), only the bin package of
> report-builder was installed (huh?), and wiki-publisher went in just
> fine (will that even work in light of its hard dep on lo-java-common?).

That is interesting, though. They are *extensions* to LO, though, whereas
-sdbc-hsqldb is a _core_ component. But yeah, probably they should depend
on default-jre etc, too - as -sdbc-hsqldb does.

But not -java-common, as outlined in my first reply.

Regards,

Rene

Bug#858655: Please move Java dependencies to libreoffice-java-common

[Rene Engelhard]

severity 858655 wishlist
tag 858655 + wontfix
thanks

Hi,

On Fri, Mar 24, 2017 at 07:00:22PM -0400, Daniel Richard G. wrote:
> A regular LibreOffice install has many Java dependencies:
> 
> # apt-get -s install libreoffice | grep '^Inst' | egrep 'jre|jdk|java'

Description-en: office productivity suite (metapackage)
 LibreOffice is a full-featured office productivity suite that provides
 a near drop-in replacement for Microsoft(R) Office.
 .
 This metapackage installs all components of libreoffice:
  * libreoffice-writer: Word processor
  * libreoffice-calc: Spreadsheet
  * libreoffice-impress: Presentation
  * libreoffice-draw: Drawing
  * libreoffice-base: Database
  * libreoffice-math: Equation editor
 It also recommends additional packages (e.g. fonts) in order to match an
 upstream LibreOffice install as closely as possible.

Because you install the metapackage which installs those "all components".
And libreoffice-base (well, its internal database) _is written in Java_.

> Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all])
> Inst ca-certificates-java (20161107 Debian:testing [all]) []
> Inst java-common (0.58 Debian:testing [all]) []
> Inst openjdk-8-jre-headless (8u121-b13-4 Debian:testing [amd64])
> [long list of Java-related packages elided]

Yes. Note that "libreoffice" DOES NOT depend on the JRE or Java libs itself.

That's pulled in by -base and -report-builder.

> Let's try installing sans what appears to be LibreOffice's main Java-
> dependency package:

It's the base stuff without which Java stuff inside LO won't work. Basically 
anything
needed for Java in LO is inside that one (besides those which belong into the 
UNO runtime
environment or have specializied packages).

> This doesn't make much sense to me. I can't decline installation of
> lo-java-common, but I can decline default-jre, yet some of the resulting

It does make perfect sense.

> installed packages are useless (lo-report-buildir-bin without
> lo-report-builder?) or at worse broken.

lo-report-builder-bin without -report-builder installed is not breaking stuff.
It's more or less a noop. It's installed because in a standard upstream install
it's in "core" packages afaicr (witgh -report-builder being in a extra "package"
there, too)

In fact, the RB is in report-builder and report-builder-bin is just arch-dep
support libraries and it appears only then.

> Looking through the dependencies in the various LibreOffice packages,
> one issue I see is that several of them depend directly on default-jre
> (or more specifically, "default-jre | openjdk-8-jre | openjdk-7-jre |
> openjdk-6-jre | gcj-jre | sun-java5-jre | sun-java6-jre | java5-runtime
> | jre") as well as lo-java-common, when the JRE dependency should in fact
> be redundant alongside lo-java-common.

No, why should simple support libraries (and this is -java-common) depend on a
JRE? Stuff needing a JRE should depend on a JRE, not some "random" package
containing just libraries. Doing this causes many issues also for normal
Java library packages in Debian. Count this package as having only many
LO-internal Java libraries.

> (Interestingly, libreoffice-script-provider-{bsh,js} depend on a JRE
> _without_ depending on lo-java-common. Does that make sense?)

That is probably a bug... I'd assume those ScriptProviders need
/usr/share/libreoffice/program/classes/ScriptFramework.jar which
is in -java-common.

> What I would like to see is for all the various LibreOffice packages
> that can/must make use of Java to Depends:/Recommends:/Suggests:

That is *exactly* what we have right now.

libreoffice installs everything you need. Including a JRE.

If you don't want it/want more control, install the various modules
yourself. The only one where you really do need Java is Base (and the
script providers mentioned above and the Java-based extensions of course)

> lo-java-common, and then have lo-java-common Depends: default-jre et al.
> That way, when installing LibreOffice, I can decline lo-java-common, the
> JRE won't get pulled in, and no LibreOffice package that requires Java
> (or is related to one that does) will get installed.

If you install "libreoffice" you install Base.

Which 100% needs Java right now (because of -sdbc-hsqldb).
Of course, if you disable Recommends:, you won't see it, but it's there.[1]



The current structure is a result of long thinking about it and shuffling around
various times and you need a compromise there. Knowledgeable users can avoid
Java by avoiding the libreoffice metapackage and/or the packages which need 
Java,

-> wontfix (maybe except the -script-provider-* part, but this bug is about a 
greater
wish.)

Regards,

Rene

[1] There's the theoretical possibility to use firebird thus -base recommends 
both,
and firebird might be default engine in a future release.

> 

Bug#858751: matrix-synapse: [INTL:pt] Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: matrix-synapse
Version: 0.19.2+dfsg-5
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for matrix-synapse's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Portuguese translation of matrix-synapse's debconf messages.
# This file is distributed under the same license as the matrix-synapse package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: matrix-synapse\n"
"Report-Msgid-Bugs-To: matrix-syna...@packages.debian.org\n"
"POT-Creation-Date: 2017-02-21 07:51+\n"
"PO-Revision-Date: 2017-03-21 09:43+\n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"X-Generator: Poedit 1.8.11\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: string
#. Description
#: ../templates:1001
msgid "Name of the server:"
msgstr "Nome do servidor:"

#. Type: string
#. Description
#: ../templates:1001
msgid ""
"The name that this homeserver will appear as, to clients and other servers "
"via federation. This name should match the SRV record published in DNS."
msgstr ""
"O nome deste servidor doméstico será visível aos clientes e a outros "
"servidores através de 'federation'. Este nome deverá coincidir com o "
"registo SRV publicado pelo DNS."

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Report anonymous statistics?"
msgstr "Reportar estatísticas anónimas?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Developers of Matrix and Synapse really appreciate helping the project out "
"by reporting anonymized usage statistics from this homeserver. Only very "
"basic aggregate data (e.g. number of users) will be reported, but it helps "
"track the growth of the Matrix community, and helps in making Matrix a "
"success, as well as to convince other networks that they should peer with "
"Matrix."
msgstr ""
"O reporte de estatísticas anónimas a partir deste servidor domestico é "
"realmente apreciado pelos 'developers' do Matrix and Synapse já que ajudam "
"o projecto. Apenas será reportada informação  muito básica (por ex. numero "
"de utilizadores), ajudando a manter o registo da evolução da comunidade "
"Matrix ajudando ao sucesso do Matrix, assim como a convencer outras redes "
"que se deveram emparelhar ao Matrix."

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Thank you."
msgstr "Obrigado."

Bug#858750: openvas-scanner: [INTL:pt] Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: openvas-scanner
Version: 5.0.7-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for openvas-scanner's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Portuguese translation for openvas-scanner debconf messages.
# This file is distributed under the same license as the openvas-scanner package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: openvas-scanner 5.0.7-3\n"
"Report-Msgid-Bugs-To: openvas-scan...@packages.debian.org\n"
"POT-Creation-Date: 2016-09-14 17:49+0800\n"
"PO-Revision-Date: 2017-03-16 16:00+\n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Last-Translator: Rui Branco \n"
"X-Generator: Poedit 1.8.11\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Do you want to enable redis unix socket on /var/run/redis/redis.sock?"
msgstr "Quer activar o socket unix redis em /var/run/redis/redis.sock?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Openvas scanner require redis database to store data. It will connect to the "
"database with a unix socket at /var/run/redis/redis.sock and /etc/redis/"
"redis.conf will be updated."
msgstr ""
"O scanner Openvas necessita de uma base de dados redis para guardar a "
"informação. Este irá ligar-se à base de dados através de um 'socket' unix "
"em /var/run/redis/redis.sock e o ficheiro /etc/redis/redis.conf será "
"actualizado."

Bug#858749: Default of "Apply colors to non-Qt applications" causes invisible text

[Nicholas D Steeves]

Package: libkf5style5
Version: 5.28.0-1
Control: affects -1 kde-style-breeze emacs inkscape x11-apps

Dear KDE Team,

Thank you for your hard work.  I hope that I'm filing this against the
right package...  It might actually be Qt problem.

Steps to reproduce invisible text, from a fresh Stretch installation
where KDE is installed

1. Go to Look and Feel.
2. Select Breeze Dark or Breeze High Contrast (or Breeze light for Inkscape)
3. Black on black text in emacs modeline, even when running in
konsole, without any .emacs.el or .emacs.d/* configuration.
4. Green on green text in tooltips from menubar in Inkscape (This was
tested with Breeze (light, not dark).
5. Almost illegible black on dark grey xclock.

Hypothesis: KDE is using a method similar to Xresources to apply
colour scheme without testing for combinations which will produce
illegible text.

Workaround: go to System Settings -> colors -> uncheck apply colors to
non-Qt applications; then make sure that kde-config-gtk-style and
gtk3-engines-breeze are installed; go to System Settings -> GNOME
Application Style (GTK) and insure that Breeze Dark is selected
wherever possible.

Caveat: With this workaround Tk and other toolkits will look out of place

Conclusion: If it is not possible to fix libkf5style5,
kde-style-breeze, or Qt, please disable "apply colors to non-Qt
applications", and use kde-config-gtk-style and gtk3-engines-breeze
for continuity between GTK and KDE applications.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#858503: diff NMU for libinfinity_0.6.7-1.1

[Anton Gladky]

tags 858503 +pending +patch
thanks

Dear maintainer,

I have prepared an NMU (versioned as 0.6.7-1.1) and
uploaded to DELAYED/5.

Please fell free to tell me if I should delay it longer, cancel
or reschedule.

Diff is attached.

Best regards

Anton


nmu.debdiff
Description: Binary data

Bug#858748: refind: [INTL:pt] Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: refind
Version: 0.10.4-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for refind's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Portuguese translation for refind debconf messages.
# This file is distributed under the same license as the refind package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: refind 0.10.4-1\n"
"Report-Msgid-Bugs-To: ref...@packages.debian.org\n"
"POT-Creation-Date: 2015-12-12 18:35-0500\n"
"PO-Revision-Date: 2017-03-16 15:10+\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 1.8.11\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Automatically install rEFInd to the ESP?"
msgstr "Instalar automaticamente o rEFInd na partição ESP?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"It is necessary to install rEFInd to the EFI System Partition (ESP) for it "
"to control the boot process."
msgstr ""
"É necessário instalar o rEFInd na partição de sistema EFI (ESP) para que o "
"mesmo possa controlar o processo de arranque."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Not installing the new rEFInd binary on the ESP may leave the system in an "
"unbootable state. Alternatives to automatically installing rEFInd include "
"running /usr/sbin/refind-install by hand or installing the rEFInd binaries "
"manually by copying them from subdirectories of /usr/share/refind-{version}."
msgstr ""
"A instalação de um novo binário rEFInd na partição ESP pode deixar o "
"sistema num estado de não arranque. Alternativas à instalação automática do "
"rEFInd são, correr o comando /usr/sbin/refind-install manualmente ou "
"instalar manualmente os binários rEFInd copiando-os a partir das sub-pastas "
"em /usr/share/refind-{version}."

Bug#858747: squid-deb-proxy: [INTL:pt] Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: squid-deb-proxy
Version: 0.8.14
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for squid-deb-proxy's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Portuguese translation for squid-deb-proxy debconf messages.
# This file is distributed under the same license as the squid-deb-proxy package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: squid-deb-proxy 0.8.14\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2016-01-31 14:35+\n"
"PO-Revision-Date: 2017-03-16 14:16+\n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"X-Generator: Poedit 1.8.11\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../squid-deb-proxy.templates:2001
msgid "Allow PPA access?"
msgstr "Permitir acesso PPA?"

#. Type: boolean
#. Description
#: ../squid-deb-proxy.templates:2001
msgid ""
"By default, squid-deb-proxy does not allow access to Personal Package "
"Archive (PPA) repositories on Launchpad."
msgstr ""
"Por omissão o squid-deb-proxy não permite acesso aos repositórios Personal "
"Package Archive (PPA) no Launchpad."

#. Type: boolean
#. Description
#: ../squid-deb-proxy.templates:2001
msgid "Choosing this option will whitelist these repositories."
msgstr ""
"Ao escolher esta opção irá permitir colocar os repositórios em lista "
"autorizada ('whitelist')"

#. Type: boolean
#. Description
#: ../squid-deb-proxy.templates:3001
msgid "Allow unrestricted network access?"
msgstr "Permitir o acesso sem restrições à rede?"

#. Type: boolean
#. Description
#: ../squid-deb-proxy.templates:3001
msgid ""
"By default, squid-deb-proxy allows access to the cache from private networks "
"only (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)."
msgstr ""
"Por omissão o squid-deb-proxy permite apenas o acesso à cache a partir de "
"redes privadas (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)."

#. Type: boolean
#. Description
#: ../squid-deb-proxy.templates:3001
msgid "Choosing this option will allow other IP addresses to access the cache."
msgstr ""
"Ao escolher esta opção irá permitir o acesso à cache por outros endereços IP."

Bug#858746: open-isns: [INTL:pt] Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: open-isns
Version: 0.97-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for open-isns's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Portuguese translation for open-isns debconf messages.
# This file is distributed under the same license as the open-isns package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: open-isns 0.97-1\n"
"Report-Msgid-Bugs-To: open-i...@packages.debian.org\n"
"POT-Creation-Date: 2017-03-14 21:54+\n"
"PO-Revision-Date: 2017-03-14 22:45+\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.8.11\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:1001
msgid "iSNS server name:"
msgstr "Nome do servidor iSNS:"

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:1001
msgid "The iSNS discovery daemon will connect to an iSNS server at startup."
msgstr ""
"O 'daemon' de descoberta iSNS irá ligar-se ao servidor iSNS no arranque."

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:1001
msgid ""
"If left blank, the discovery daemon will not be started after package "
"installation, and you will have an opportunity to modify the configuration "
"file, /etc/isns/isnsdd.conf."
msgstr ""
"Se deixado em branco o 'daemon' de descoberta não será iniciado depois da "
"instalação do pacote e terá oportunidade de modificar o ficheiro de "
"configuração /etc/isns/isnsdd.conf."

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:2001
msgid "iSNS server public key file:"
msgstr "Ficheiro da chave pública do servidor iSNS:"

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:2001
msgid ""
"When authentication is enabled, the iSNS discovery daemon needs to know the "
"public key of the iSNS server. Please provide a file name that contains the "
"public key. It will then be copied to /etc/isns/server_key.pub."
msgstr ""
"Quando a autenticação está activada, o 'daemon' de descoberta iSNS necessita "
"da chave pública do servidor iSNS. Por favor forneça um nome de ficheiro que "
"contenha a chave pública. A mesma será copiada para /etc/isns/server_key.pub."

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:2001
msgid ""
"Alternatively, you may copy the server's public key to that location "
"yourself."
msgstr ""
"Alternativamente poderá copiar você mesmo a chave pública do servidor para o "
"mesmo local."

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:2001
msgid ""
"If left blank and /etc/isns/server_key.pub does not exist, authentication "
"will remain disabled."
msgstr ""
"Se deixado em branco e se /etc/isns/server_key.pub não existir, a "
"autenticação será desactivada."

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:3001
msgid "iSNS discovery daemon private key file:"
msgstr "Ficheiro de chave privada do 'daemon' de descoberta iSNS:"

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:3001
msgid ""
"When authentication is enabled, the iSNS discovery daemon needs to have a "
"private key, where the corresponding public key is enrolled with the iSNS "
"server. Please provide a file name that contains the private key. It will "
"then be copied to /etc/isns/auth_key."
msgstr ""
"Quando a autenticação está activada, o 'daemon' de descoberta iSNS necessita "
"da chave privada, enquanto a correspondente chave pública está em uso pelo "
"servidor iSNS. Por favor forneça um nome de ficheiro que contenha a chave "
"privada. A mesma será copiada para /etc/isns/auth_key."

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:3001
msgid ""
"Alternatively, you may copy the discovery daemon's private key to that "
"location yourself."
msgstr ""
"Alternativamente poderá copiar você mesmo a chave privada do 'daemon' de "
"descoberta para o mesmo local."

#. Type: string
#. Description
#: ../open-isns-discoveryd.templates:3001
msgid ""
"If left blank and /etc/isns/auth_key does not exist, authentication will "
"remain disabled."
msgstr ""
"Se deixado em branco e se /etc/isns/auth_key não existir, a autenticação "
"continuará desactivada."

#. Type: note
#. Description
#: ../open-isns-discoveryd.templates:4001
msgid "iSNS discovery daemon will not be started at installation"
msgstr "O 'daemon' de descoberta iSNS não será iniciado na instalação"

#. Type: note
#. Description
#: ../open-isns-discoveryd.templates:4001
msgid ""
"You have not provided an iSNS server, and the configuration file /etc/isns/"
"isnsdd.conf does not contain a setting either. The discovery daemon will "

Bug#858744: nghttp2-proxy: nghttpx fails to start at boot due to missing dns resolver

[Tomasz Buchert]

Package: nghttp2-proxy
Version: 1.20.0-1
Severity: normal

Dear Maintainer,
when nghttpx starts at boot, the dns resolver may not be available and then the
start fails. More surprisingly, this also happens for explicit ip addresses and
port addresses such as 127.0.0.1:80.

The upstream bug is https://github.com/nghttp2/nghttp2/issues/857

Cheers.



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

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

Versions of packages nghttp2-proxy depends on:
ii  init-system-helpers  1.47
ii  libc-ares2   1.12.0-1
ii  libc62.24-9
ii  libev4   1:4.22-1
ii  libgcc1  1:6.3.0-10
ii  libjansson4  2.9-1
ii  libjemalloc1 3.6.0-9.1
ii  libnghttp2-141.20.0-1
ii  libspdylay7  1.3.2-2.1
ii  libssl1.11.1.0e-1
ii  libstdc++6   6.3.0-10
ii  libsystemd0  232-19
ii  libxml2  2.9.4+dfsg1-2.2
ii  lsb-base 9.20161125
ii  openssl  1.1.0e-1
ii  python   2.7.13-2
ii  zlib1g   1:1.2.8.dfsg-5

nghttp2-proxy recommends no packages.

nghttp2-proxy suggests no packages.

-- Configuration Files:
/etc/nghttpx/nghttpx.conf changed [not included]

-- no debconf information

Bug#858745: makedumpfile: [INTL:pt] Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: makedumpfile
Version: 1-1.6.1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for makedumpfile's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Portuguese translation for makedumpfile debconf messages.
# This file is distributed under the same license as the makedumpfile package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: makedumpfile 1-1.6.1-1\n"
"Report-Msgid-Bugs-To: makedumpf...@packages.debian.org\n"
"POT-Creation-Date: 2016-06-10 12:46+0200\n"
"PO-Revision-Date: 2017-03-14 21:28+\n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"X-Generator: Poedit 1.8.11\n"

#. Type: boolean
#. Description
#: ../kdump-tools.templates:1001
msgid "Should kdump-tools be enabled by default?"
msgstr "Deve o kdump-tools ser activado por omissão?"

#. Type: boolean
#. Description
#: ../kdump-tools.templates:1001
msgid ""
"If you choose this option, the kdump-tools mechanism will be enabled. A reboot "
"is still required in order to enable the crashkernel kernel parameter."
msgstr ""
"Se escolher esta opção, o mecanismo do kdump-tools será activado. Uma "
"reinicialização será no entanto necessária para activar o parâmetro crashkernel "
"do kernel."

Bug#813525: lintian: Please make --no-tag-display-limit configurable

[Nicholas D Steeves]

Hi,

I can confirm that as of 2.5.50 this is not yet fixed.  I'd also like
to be able to set no-tag-display-limit in my lintianrc.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#858743: privoxy: [INTL:pt] Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: privoxy
Version: 3.0.26-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for privoxy's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Portuguese translation for privoxy debconf messages.
# This file is distributed under the same license as the privoxy package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: privoxy\n"
"Report-Msgid-Bugs-To: priv...@packages.debian.org\n"
"POT-Creation-Date: 2016-04-08 17:17+0200\n"
"PO-Revision-Date: 2017-03-14 19:56+\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: string
#. Description
#: ../templates:1001
msgid "Adresses on with Privoxy listens:"
msgstr "Endereços activos em que o Privoxy escuta:"

#. Type: string
#. Description
#: ../templates:1001
msgid ""
"Please enter a space separated list of address:port combinations on which "
"Privoxy will listen for client requests."
msgstr ""
"Por favor introduza uma lista de endereços:portas separada por espaços da "
"qual o Privoxy escutará pedidos de clientes."

Bug#858693: [PKG-Openstack-devel] Bug#858693: Bug#858693: Gerrit branch missing?

[David Rabel]

On 25.03.2017 22:53, David Rabel wrote:
> On 25.03.2017 22:34, Thomas Goirand wrote:
>> On 03/25/2017 12:01 PM, David Rabel wrote:
>>> Hi,
>>>
>>> I have the patch ready, but when I "git review" it, it tries to rebase
>>> the branch to gerrit/master. Is it possible that branch debian/newton is
>>> missing in gerrit?
>>
>> That's unlikely. What maybe is happening, is that the .gitreview file
>> doesn't point to the correct repository / branch.

I found it. .gitreview and .git/config both had a wrong repository and
.gitreview also did not have a defaultbranch.

Thank you.

David



signature.asc
Description: OpenPGP digital signature

Bug#858742: libvirt: [INTL:pt] Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: libvirt
Version: 3.0.0-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for libvirt's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .


-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Portuguese translation for libvirt(debconf)
# This file is distributed under the same license as the libvirt package.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: libvirt 3.0.0-3\n"
"Report-Msgid-Bugs-To: libv...@packages.debian.org\n"
"POT-Creation-Date: 2016-12-22 14:20+0100\n"
"PO-Revision-Date: 2017-03-14 19:44+\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid "Continue with incorrect libvirt-qemu user/group ID(s)?"
msgstr "Continuar com o ID(s) libvirt-qemu user/group incorrecto?"

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid ""
" The user/group ID (uid/gid) allocated for libvirt-qemu (64055)\n"
" seems to be taken by another user/group, thus it is not possible\n"
" to create the user/group with this numeric ID."
msgstr ""
" O ID (uid/gid) do utilizador/grupo alocado para libvirt-qemu \n"
" (64055)  parece ter sido tomado por outro utilizador/grupo, \n"
" tornando impossível  criar o utilizador/grupo com este ID \n"
" numérico."

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid ""
" The migration of guests with disk image files shared over NFS\n"
" requires a static libvirt-qemu user and group ID (uid and gid)\n"
" between the source and destination host systems."
msgstr ""
" A migração de convidados com ficheiros de imagem de disco partilhados\n"
" por NFS requer um ID estático de utilizador e de grupo (uid e gid) do \n"
" libvirt-qemu entre a fonte e o destino dos sistemas anfitriões."

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid ""
" If guest migration over NFS is not required, you can continue\n"
" the installation."
msgstr ""
" Se não for necessária a migração de convidado sobre NFS, pode\n"
" continuar a instalação."

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid ""
" In order to resolve this problem, do not continue the installation,\n"
" release the 64055 uid/gid (which might involve permission changes),\n"
" then install this package again."
msgstr ""
" De modo a resolver este problema, não continue a instalação, largue o\n"
" uid/gid 64055 (pode envolver alterações nas permissões) e volte\n"
" então a instalar este pacote novamente."

Bug#858693: [PKG-Openstack-devel] Bug#858693: Gerrit branch missing?

[David Rabel]

On 25.03.2017 22:34, Thomas Goirand wrote:
> On 03/25/2017 12:01 PM, David Rabel wrote:
>> Hi,
>>
>> I have the patch ready, but when I "git review" it, it tries to rebase
>> the branch to gerrit/master. Is it possible that branch debian/newton is
>> missing in gerrit?
> 
> That's unlikely. What maybe is happening, is that the .gitreview file
> doesn't point to the correct repository / branch.

I added "defaultbranch=debian/newton" to .gitreview, as I found it in
other repositories. Then I tried "git review" again and got the following:

>git review
The branch 'debian/newton' does not exist on the given remote
'gerrit'. If these changes are intended to start a new branch, re-run
with the '-R' option enabled.


Should I run "git review -R"?

Yours
  David



signature.asc
Description: OpenPGP digital signature

Bug#858741: nginx: [INTL:pt] Updated Portuguese translation for debconf messages

[TRADUZ - DebianPT]

Package: nginx
Version: 1.10.3-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for nginx's debconf messages.
Translator: Rui Branco 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .


-- 
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org# Nginx debconf translations
# Copyright (C) 2016 Christos Trochalakis
# This file is distributed under the same license as the nginx package.
# Christos Trochalakis , 2016.
# Rui Branco , initial translation 2017, 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: nginx 1.10.3-1\n"
"Report-Msgid-Bugs-To: ng...@packages.debian.org\n"
"POT-Creation-Date: 2016-10-04 20:03+0300\n"
"PO-Revision-Date: 2017-03-14 13:59+\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: note
#. Description
#: ../nginx-common.templates:1001
msgid "Possible insecure nginx log files"
msgstr "Ficheiros de eventos (log) do nginx possivelmente inseguros"

#. Type: note
#. Description
#: ../nginx-common.templates:1001
msgid ""
"The following log files under /var/log/nginx directory are symlinks owned by "
"www-data:"
msgstr ""
"Os seguintes ficheiros de eventos da pasta /var/log/nginx são ligações "
"simbólicas (symlinks) detidos por www-data:"

#. Type: note
#. Description
#: ../nginx-common.templates:1001
msgid "${logfiles}"
msgstr "${logfiles}"

#. Type: note
#. Description
#: ../nginx-common.templates:1001
msgid ""
"Since nginx 1.4.4-4 /var/log/nginx was owned by www-data. As a result www-"
"data could symlink log files to sensitive locations, which in turn could "
"lead to privilege escalation attacks. Although /var/log/nginx permissions "
"are now fixed it is possible that such insecure links already exist. So, "
"please make sure to check the above locations."
msgstr ""
"Desde a versão 1.4.4-4 do nginx, o ficheiro /var/log/nginx é detido pelo www-"
"data. Como resultado o www-data pode criar ligações simbólicas de ficheiros "
"de eventos para locais sensíveis, o que poderá levar a uma escalada de "
"ataques de privilégios. Apesar das permissões de /var/log/nginx estarem "
"agora seguras, é possível que tais ligações inseguras já existam. Verifique "
"por favor os locais acima mencionados."

Bug#858729: plasma-discover: too many bugs for the next stable

[Matthias Klumpp]

2017-03-25 22:27 GMT+01:00 Rene Engelhard :
> [ I am NOT the plasma-discover maintainer ]
>
> On Sat, Mar 25, 2017 at 12:53:20PM -0400, Leand wrote:
>>There are basic functions that are bugged. For example, the search
>>function returns wrong and unrelated results too many times. If I
>>search for "office" or "writer" it doesn't show LibreOffice packages
>>or LibreOffice Writer at all. Furthermore in some cases it doesn't
>
> Looks it looks at Name and/or GenericName in the .desktop files. Here:
>
> # cat /usr/share/applications/libreoffice-writer.desktop | grep -E 
> '(.*Name=|.*Name\[en.*\]=)'
> Name=LibreOffice Writer
> GenericName=Word Processor
> GenericName[en]=Word Processor
> GenericName[en_GB]=Word Processor
> GenericName[en_ZA]=Word Processor
> [...]
>
> So if it takes GenericName before Name it of course doesn't see "LibreOffice 
> Writer" but
> "Word Processor". And also note "office" and "writer" don't even appear in 
> Name (not the
> case), no idea whether the search is case-sensitive, though.

The explanation is even easier here: LO Writer is not in the metadata,
because it symlinks files in /usr/share/applications, which the
metadata generator doesn't support.
See 
https://appstream.debian.org/sid/main/issues/index.html#debian_libreoffice_maintainers_%3cdebian-openoff...@lists.debian.org%3E
for the issue information.
So, this is not a bug in Discover. Also, all of the issues outlined in
this bug report are minor annoyances which do not at all justify the
severity of "grave" for this bug report.
I am even tempted to close it:
 * The search results are not Discover's fault, or are intended (see below)
 * Discover will not show dependencies or packages - it is not a
package manager. If you want a package manager, use Apper or Muon.
 * Displaying unrelated stuff to be removed when removing Gimp is
definitely a bug, but creating a clean, new one with normal priority
is a better idea here. Also, immediately reporting this upstream will
help.

>>even display the exact name of the packages in any way, for example
>>the package "file-roller" (Gnome's File Roller) is displayed as
>>"Archive manager".
>
> # cat /usr/share/applications/org.gnome.FileRoller.desktop | grep -E 
> '(.*Name=|.*Name\[en.*\]=)'
> Name=Archive Manager
> Name[en@shaw]=ѸђѲѝ ѥѨѯѩѡѼ
> Name[en_CA]=Archive Manager
> Name[en_GB]=Archive Manager
>
> So at least the second one is expected.

Jup, that's the reason. Nothing we can do here - complain to GNOME for
using very generic names.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Bug#858735: thunderbird: After migration Thunderbird fails to start due to AppArmor denials in ~/.icedove

[Viktor Jägersküpper]

Dear Gerald,

Gerald Turner:
> BTW, I'm having a frustrating time post-migration: My profile is 49GB,
> Thunderbird decided it needs to re-download all that mail, and it has
> also fogotten my per-folder "Sort By > Threaded" preference, that I'll
> have to re-click hundreds of times, but only after waiting few days for
> that 49GB to be synchronized so that the UI is less frozen.  I have two
> other installations of Thunderbird that will likely face the same fate.

I tested the Thunderbird packages last year and also experienced
something like this because I also moved .icedove to .thunderbird
manually once, but I don't remember the details. As far as I know, this
is a bug in Thunderbird (upstream).

I recommend you to wait with the upgrade of the icedove packages on your
two other installations until this bug is fixed, so that you won't have
to move .icedove to .thunderbird manually there and you won't suffer
from the Thunderbird bug (re-downloading etc.).

Regards,
Viktor

Bug#858693: Gerrit branch missing?

[Thomas Goirand]

On 03/25/2017 12:01 PM, David Rabel wrote:
> Hi,
> 
> I have the patch ready, but when I "git review" it, it tries to rebase
> the branch to gerrit/master. Is it possible that branch debian/newton is
> missing in gerrit?

That's unlikely. What maybe is happening, is that the .gitreview file
doesn't point to the correct repository / branch.

Cheers,

Thomas Goirand (zigo)

Bug#858729: plasma-discover: too many bugs for the next stable

[Rene Engelhard]

[ I am NOT the plasma-discover maintainer ]

On Sat, Mar 25, 2017 at 12:53:20PM -0400, Leand wrote:
>There are basic functions that are bugged. For example, the search
>function returns wrong and unrelated results too many times. If I
>search for "office" or "writer" it doesn't show LibreOffice packages
>or LibreOffice Writer at all. Furthermore in some cases it doesn't

Looks it looks at Name and/or GenericName in the .desktop files. Here:

# cat /usr/share/applications/libreoffice-writer.desktop | grep -E 
'(.*Name=|.*Name\[en.*\]=)'
Name=LibreOffice Writer
GenericName=Word Processor
GenericName[en]=Word Processor
GenericName[en_GB]=Word Processor
GenericName[en_ZA]=Word Processor
[...]

So if it takes GenericName before Name it of course doesn't see "LibreOffice 
Writer" but
"Word Processor". And also note "office" and "writer" don't even appear in Name 
(not the
case), no idea whether the search is case-sensitive, though.

>even display the exact name of the packages in any way, for example
>the package "file-roller" (Gnome's File Roller) is displayed as
>"Archive manager".

# cat /usr/share/applications/org.gnome.FileRoller.desktop | grep -E 
'(.*Name=|.*Name\[en.*\]=)'
Name=Archive Manager
Name[en@shaw]=ѸђѲѝ ѥѨѯѩѡѼ
Name[en_CA]=Archive Manager
Name[en_GB]=Archive Manager

So at least the second one is expected.

Regards,

Rene

Bug#858740: ITP: node-url -- The core `url` packaged standalone for use with Browserify

[Bastien ROUCARIES]

package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-url
  Version : 0.11.0
  Upstream Author : Roman Shtylman
* URL : https://github.com/defunctzombie/node-url#readme
* License : Expat
  Programming Lang: JavaScript
  Description : The core `url` module packaged standalone for use
with Browserify.

 This module has utilities for URL resolution and parsing meant to
have feature parity with node.js  core url module.
.
The url module provides utilities for URL resolution and parsing.
.
The functions of this module usually create an url object which
contain properties which hold different parts of the url.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#858716: [Pkg-xfce-devel] Bug#858716: xfce4-settings: xfce4-settings-manager do not expand vertically xfce4-notifyd-config dialog

[Antonio Cebrián]

I have found the problem and it is a xfce4-notifyd package related problem
instead of a xfce4-settings package related problem. Sorry for the mistake.

Solution patch attached.

Original and patched notification configuration dialog screen shoots
attached.

Should I open a new reportbug for xfce4-notifyd package or, as you are the
maintainer of both packages will take care of it?

Best regards.


2017-03-25 19:23 GMT+01:00 Antonio Cebrián :

> Package: xfce4-notifyd
> Version: 0.3.4-1
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-2-amd64 (SMP w/1 CPU core)
> Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages xfce4-notifyd depends on:
> ii  libc6   2.24-9
> ii  libcairo2   1.14.8-1
> ii  libgdk-pixbuf2.0-0  2.36.5-2
> ii  libglib2.0-02.50.3-1
> ii  libgtk-3-0  3.22.9-4
> ii  libnotify4  0.7.7-1+b1
> ii  libx11-62:1.6.4-3
> ii  libxfce4ui-2-0  4.12.1-2
> ii  libxfce4util7   4.12.1-3
> ii  libxfconf-0-2   4.12.1-1
>
> Versions of packages xfce4-notifyd recommends:
> ii  libnotify-bin  0.7.7-1+b1
>
> xfce4-notifyd suggests no packages.
>
> -- no debconf information
>
>
> 2017-03-25 16:45 GMT+01:00 Yves-Alexis Perez :
>
>> On Sat, 2017-03-25 at 13:41 +0100, Antonio Cebrian wrote:
>> > xfce4-notifyd-config dialog is not expanded vertically when called from
>> > xfce4-settings-manager.
>> >
>> > xfce4-notifyd-config dialog called alone is correctly expanded
>> vertically so
>> > seem to be a xfce4-settings-manager problem.
>> >
>> > Attached both cases dialog screenshoots.
>>
>> Hi,
>>
>> Which version of xfce4-notifyd do you have?
>>
>> Regards,
>> --
>> Yves-Alexis
>
>
>
--- xfce4-notifyd-0.3.4.orig/xfce4-notifyd-config/main.c	2016-11-09 23:09:01.0 +0100
+++ xfce4-notifyd-0.3.4/xfce4-notifyd-config/main.c	2017-03-25 21:55:14.550102132 +0100
@@ -615,7 +615,7 @@
 /* In the glade file, plug_child has parent, so remove it first */
 gtk_container_remove (GTK_CONTAINER(gtk_widget_get_parent(plug_child)), plug_child);
 gtk_container_add (GTK_CONTAINER(plug), plug_child);
-gtk_widget_set_valign (plug_child, GTK_ALIGN_START);
+gtk_widget_set_valign (plug_child, GTK_ALIGN_FILL);
 
 gdk_notify_startup_complete();
 g_object_unref(G_OBJECT(builder));

Bug#858506: newer version of dns-root-data prevents dnsmasq from starting

[Craig Small]

On Sat, Mar 25, 2017 at 11:31 PM Thilo Six  wrote:

> Does '/usr/share/dnsmasq-base/trust-anchors.conf' also need an update?
>
The dnsmasq init script only uses root.ds so that won't need an update.

dnsmasq starts, the family can get to the Internet so the rioting in the
street has stopped, for now :)

 - Craig

-- 
Craig Small (@smallsees)   http://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#858678: pcre3: CVE-2017-7245

[Salvatore Bonaccorso]

Control: found -1 2:8.39-3

This one is still present in 2:8.39-3.

Regards,
Salvatore

Bug#858679: pcre3: CVE-2017-7246

[Salvatore Bonaccorso]

Control: found -1 2:8.39-3

This one is still present in 2:8.39-3.

Regards,
Salvatore

Bug#858683: pcre3: CVE-2017-7244

[Salvatore Bonaccorso]

Source: pcre3
Source-Version: 2:8.39-3

Hi Matthew,

On Sat, Mar 25, 2017 at 08:45:16AM +0100, Salvatore Bonaccorso wrote:
> Source: pcre3
> Version: 2:8.39-2.1
> Severity: important
> Tags: upstream security
> 
> Hi,
> 
> the following vulnerability was published for pcre3.
> 
> CVE-2017-7244[0]:
> | The _pcre32_xclass function in pcre_xclass.c in libpcre1 in PCRE 8.40
> | allows remote attackers to cause a denial of service (invalid memory
> | read) via a crafted file.

I confirm: this one is fixed by
http://vcs.pcre.org/pcre?view=revision=1688 upstream (so with
the same commit as CVE-2017-7186), at least when I tried to bisect as
well the upstrema VCS, I reached this commit to address the issue from 
https://blogs.gentoo.org/ago/2017/03/20/libpcre-invalid-memory-read-in-_pcre32_xclass-pcre_xclass-c/

Regards,
Salvatore

Bug#857522: libbind-export-dev: broken symlinks: /usr/lib/x86_64-linux-gnu/liblwres-export.so -> /lib/x86_64-linux-gnu/liblwres-export.so.141, /usr/lib/x86_64-linux-gnu/libbind9.so -> libbind9.so.140.

[Michael Gilbert]

control: severity -1 important

On Sun, Mar 12, 2017 at 1:26 AM, Andreas Beckmann wrote:
>   /usr/lib/x86_64-linux-gnu/liblwres-export.so -> 
> /lib/x86_64-linux-gnu/liblwres-export.so.141
>   /usr/lib/x86_64-linux-gnu/libbind9.so -> libbind9.so.140.0.10

These are mistakenly included in libbind-export-dev, but they do no
harm being there.  This is a bug, not an RC bug.

Best wishes,
Mike

Bug#858730: mudlet FTBFS on !amd64: /usr/lib/x86_64-linux-gnu/qt5/bin/qmake: Command not found

[Craig Small]

On Sun, Mar 26, 2017 at 4:30 AM Adrian Bunk  wrote:

> x86_64-linux-gnu is not part of paths that are expected to exist
> on !amd64, the generated src/Makefile should not be used.
>
That makefile is generally not shipped with the upstream rebuilt package.
I'm not sure why it is there now.

 - Craig

-- 
Craig Small (@smallsees)   http://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#741521: spamassassin: DNS resolving should get reloaded

[John Damm Sørensen]

Have you tried adding this:
ConditionDirectoryNotEmpty=/etc/resolv.conf
to the Unit section of:
 /usr/lib/systemd/system/spamassassin.service

Bug#415396: "dh_install --list-missing" should ignore manpages and other installed files

[Michael Stapelberg]

On Thu, Mar 23, 2017 at 9:43 PM, Niels Thykier  wrote:

> Michael Stapelberg:
> > Sorry for the late reply.
> >
>
> Hi again, :)
>
> > On Sat, Oct 1, 2016 at 11:09 AM, Niels Thykier 
> wrote:
> >
> >> [...]
> >>
> >> Hi,
> >>
> >> I am sympathetic to the end goal.
> >>
> >> The log file approach could work, but in that case we could even defer
> >> it to a separate helper (as it is dh_install is larger than I would like
> >> it).
> >>
> >
> > By “defer it”, what exactly do you mean? Checking for files which were
> not
> > installed?
> >
>
> Put the logic into a separate helper, which has - as sole purpose - the
> responsibility for doing "list/fail-on-missing" checks.
>

Thanks for clarifying. Would dh_missing be an okay name?


>
> >
> >>   I am happy to assist with creating a patch for this.
> >>
> >> A few recommendations:
> >>  * If the install log is created under debian/.debhelper it is cleaned
> >>up automatically.  I strongly prefer this for new internal files.
> >>(Feel free to use "generated_file()" for this purpose)
> >>  * Please create a sub in Dh_Lib for registering installed files, so it
> >>becomes standardised.
> >>(Documentation goes in doc/PROGRAMMING)
> >>
> >
> > Looking at dh_installdocs, I see that it shells out to a combination of
> > find+sort+xargs+cp. What’s your recommendation for getting the list of
> > affected files? Would it be best to read the output of find+sort, process
> > it, then shell out to xargs+cp?
> >
>
> To begin with, I think I would just log the original pattern (for source
> files) and let this new helper "re-expand" it.  If performance becomes
> an issue, we can revisit that decision.  The simpler it is to retro-fit
> this new functionality into an existing helper, the easier we can have
> "third-party" tools adopt it. :)
>

Makes sense.

I looked at dh_installdocs and it’s actually way more complicated than I
imagined.

It’s too bad we don’t have a point through which all files must pass (like
install_file), otherwise the change would be simple.

Would it be okay to convert the helpers one-by-one to use the new
mechanism? If not, I don’t think I have enough motivation to actually
update all dh_* programs to log their files.

-- 
Best regards,
Michael

Bug#858739: apt-cacher: HTTP response splitting

[Salvatore Bonaccorso]

Source: apt-cacher
Version: 1.7.13
Severity: important
Tags: security

This is to have a BTS reference, since no CVE has been assigned.

Patch:


diff -Nru apt-cacher-1.7.14/apt-cacher apt-cacher-1.7.15/apt-cacher
--- apt-cacher-1.7.14/apt-cacher2017-01-08 11:29:03.0 +0100
+++ apt-cacher-1.7.15/apt-cacher2017-03-14 17:55:18.0 +0100
@@ -2090,8 +2090,8 @@
$request->protocol($3||'HTTP/1.0');
 
clean_uri($request->uri);
-   if($request->uri =~ m#(?:^|/)\.{2}/#) { # Reject ../ or /../
-   sendrsp(HTTP::Response->new(403, 'Forbidden: Invalid 
URI ' . $request->uri));
+   if($request->uri =~ m#(?:^|/)\.{2}/|%0[ad]#i) { # Reject 
../, /../ or encoded new lines
+   sendrsp(HTTP::Response->new(403, 'Forbidden: Insecure 
URI ' . $request->uri));
return 1; # next REQUEST
}
return $request if $mode && $mode eq 'cgi'; # Not going to 
get anything else
diff -Nru apt-cacher-1.7.14/debian/changelog apt-cacher-1.7.15/debian/changelog
--- apt-cacher-1.7.14/debian/changelog  2017-01-08 11:37:20.0 +0100
+++ apt-cacher-1.7.15/debian/changelog  2017-03-21 10:52:04.0 +0100
@@ -1,3 +1,9 @@
+apt-cacher (1.7.15) unstable; urgency=medium
+
+  * Prevent HTTP response splitting with encoded newlines in request.
+
+ -- Mark Hindley   Tue, 21 Mar 2017 09:52:04 +
+
 apt-cacher (1.7.14) unstable; urgency=medium
 
   * Update to debhelper compatibility 9.

Bug#858726: i3-wm: Mod5 (alias AltGr, ISO_Level3_Shift) in defautlt German keyboard layout not working if used in the i3 config file

[Simon]

Sure, I tried my best:

https://github.com/i3/i3/issues/2717

Am 25.03.2017 um 18:13 schrieb Michael Stapelberg:

As this is not a Debian-specific bug, can you please report it upstream
at https://github.com/i3/i3? Be sure to include your config file and
ideally a log file, as the page will prompt you to.

Bug#858738: libc6: [PATCH] Fix crash in __longjmp on hppa architecture (BZ #21049)

[John David Anglin]

Package: libc6
Version: 2.24-9
Severity: normal

Dear Maintainer,

The build of libsigsegv on hppa fails due failing configuration tests:
checking whether a signal handler can be left through longjmp... no
checking whether a signal handler can be left through longjmp and 
sigaltstack... no
checking whether a signal handler can be left through longjmp and setcontext... 
no
checking whether a signal handler can be left through siglongjmp... no
checking whether a signal handler can be left through siglongjmp and 
sigaltstack... no
checking whether a signal handler can be left through siglongjmp and 
setcontext... no

This results in the expected symbols being incorrect:
--- debian/libsigsegv2.symbols (libsigsegv2_2.10-5_hppa)
+++ dpkg-gensymbolsZE40Az   2017-03-19 06:09:43.426334880 +
@@ -7,7 +7,7 @@
  sigsegv_install_handler@Base 2.9
  sigsegv_leave_handler@Base 2.9
  sigsegv_register@Base 2.9
- (arch=!hurd-i386)sigsegv_reset_onstack_flag@Base 2.9
+#MISSING: 2.10-5# (arch=!hurd-i386)sigsegv_reset_onstack_flag@Base 2.9

The problem is longjmp is broken when -D_FORTIFY_SOURCE=2 is used during
compilation.  The bug is BZ #21049 and a fix was posted here by Helge:
https://sourceware.org/ml/libc-alpha/2017-01/msg00310.html

Regards,
Dave Anglin

-- System Information:
Debian Release: 9.0
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.10.5+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6 depends on:
ii  libgcc4  1:6.3.0-10

libc6 recommends no packages.

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

-- debconf information excluded

Bug#857597: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

[Thomas Schmitt]

Hi,

David Christensen confirmed that above fixed MBR enabled isohybrid
booting on his legacy system.

Time for a summary of findings.


How to reproduce the bug:

Any BIOS which does not announce "Device Access using the packet structure"
by the reply to INT 13 AH 41 will fail to boot by the old MBR, if the numbers
for heads/cylinder and for sectors/head do not happen to be identical.

The drive geometry numbers are handed out by the BIOS on INT 13 AH 8
depending on its perception of the drive. I never saw both being the same.
See also:
  
https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D41h:_Check_Extensions_Present
  
https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D41h:_Check_Extensions_Present


How to work around:

Overwrite the old MBR by the fixed one.

  wget http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324

  iso=debian-8.7.1-i386-xfce-CD-1.iso
or
  iso=/dev/sdc

  dd conv=notrunc bs=1 count=432 if=isohdpfx.bin.170324 of="$iso"

According to
  https://git.kernel.org/pub/scm/boot/syslinux/syslinux.git/log/mbr/isohdpfx.S
the fix should apply to ISOLINUX versions since 3.82.
The most recent touching of the code part in question was on 2009-05-31.


Proposals for debian-cd and syslinux package:

Martin Str|mberg has announced that
  http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324
will exist only a limited time. (I have a copy.)

I propose that Debian gets it too and offers it for download together
with a description what problem it might fix and how to apply it.
If it gets a Debian URL and if i get pointed to an empty wiki page,
i would volunteer to write the description.

Next, one will have to decide whether to use the fixed MBR with future
Debian ISOs and whether to put the patch into Debian's syslinux source
package.

We got no comment by hpa yet. Any review by a skilled assembler
programmer is welcome. Especially one will have to check for any
inadverted side effects caused by changing the stack push sequence
to the expectations of isolinux.bin.



Have a nice day :)

Thomas

Bug#844676: Bits of feedback

[martin f krafft]

also sprach Laura Arjona Reina  [2017-03-25 20:00 +0100]:
> Note that the text is currently the same that was in the website
> untouched since 2001 (16 years, wow).

Oh wow, I hadn't noticed, but then I also didn't really read the
text in the last 10 years… ;)

> We (partners team) still didn't define the new partners program.

Great news. I do feel like some of the stuff on the current page is
— while very Debian-esque — somewhat soft and unprofessional. We're
dealing with businesses, and so I hope we'll appear a lot more
assertive in the future.

Thanks!

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"writing a book is like washing an elephant: there no good place to
 begin or end, and it's hard to keep track of what you've already
 covered."
-- anonymous


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#858736: xul-ext-gcontactsync: Depends on icedove or iceape but not thunderbird

[Brian Vaughan]

Package: xul-ext-gcontactsync
Version: 2.0.5-1
Severity: normal

Dear Maintainer,

icedove is now a transitional package for thunderbird. xul-ext-gcontactsync
works with thunderbird without issue; however the dependency information does
not list thunderbird, so the icedove transitional package must be installed in
order to use xul-ext-gcontactsync with thunderbird.

Provides: gcontactsync, iceape-gcontactsync, icedove-gcontactsync
Depends: icedove (>= 17.0) | iceape (>= 2.14)
Breaks: iceape (>> 2.35+), iceape (<< 2.14), icedove (<< 17.0)
Enhances: iceape, icedove

Also, many of the files for this package are installed under
'/usr/lib/icedove/extensions'.

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

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

Versions of packages xul-ext-gcontactsync depends on:
ii  icedove1:45.8.0-2
ii  thunderbird [icedove]  1:45.8.0-2

xul-ext-gcontactsync recommends no packages.

xul-ext-gcontactsync suggests no packages.

-- no debconf information

Bug#858737: Thunderbird fails to start with enforced AppArmor profile after migration (access to profile directory denied)

[Matthias Geerdsen]

Package: thunderbird
Version: 1:45.8.0-2
Severity: normal

Hi,

thunderbird fails to start after the migration. The AppArmor profile
does not
allow access to $HOME/.icedove. This prohibits thunderbird to start as it is
unable to use .parentlock:

[Sat Mar 25 20:01:33 2017] audit: type=1400 audit(1490468494.230:340):
apparmor="DENIED" operation="file_lock" profile="thunderbird"
name="/home/USERNAME/.icedove/PROFILEFOLDER/.parentlock" pid=9568
comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000

It should be sufficient to use "@{HOME}/.{thunderbird,icedove)" where
"@{HOME}/.thunderbird" is used in the profile currently.

Cheers
Matthias



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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.16-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3+b2
ii  libgcc1   1:6.3.0-10
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-1
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.4-0 1.4.1-2+b2
ii  libicu57  57.1-5
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.4-1
ii  libpangocairo-1.0-0   1.40.4-1
ii  libpangoft2-1.0-0 1.40.4-1
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.16.2-3
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-10
ii  libvpx4   1.6.1-2
ii  libx11-6  2:1.6.4-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b2
ii  x11-utils 7.7+3+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-7
ii  lightning 1:45.8.0-2

Versions of packages thunderbird suggests:
ii  apparmor  2.11.0-2
ii  fonts-lyx 2.2.2-1
ii  libgssapi-krb5-2  1.15-1

-- Configuration Files:
/etc/apparmor.d/usr.bin.thunderbird changed [not included]

-- no debconf information

Bug#858735: thunderbird: After migration Thunderbird fails to start due to AppArmor denials in ~/.icedove

[Gerald Turner]

Package: thunderbird
Version: 1:45.8.0-2
Severity: normal

Dear Maintainer,

On a laptop running Debian stretch, the following sequence of events
occurred:

  * Upgraded icdeove package from 1:45.6.0-2 to 1:45.8.0-2

  * Launched Thunderbird for the first time after package upgrade (log
attached).

  * Migration completed successfully after a few minutes (lot's of disk
I/O from 'find' subprocesses)

  * Then a window poped up saying "Thunderbird is already running, but
is not responding" (screenshot attached).

  * The kernel logged many AppArmor denials, mainly for the lockfile in
~/.icedove (but also some peculiar PCI device access, log attached).

I resolved the problem by executing:

  $ rm .thunderbird
  $ mv .icedove .thunderbird

I suggest appending a message within the migration zenity popup message
or in README.Debian.gz that reads something like:

  Users of AppArmor will need to manually delete the ~/.thunderbird
  symlink and move ~/.icedove to ~/.thunderbird due to the AppArmor
  policy installed by Thunderbird having prohibited access to the old
  directory.

I thought about coming up with little bit of automation, perhaps
conditiionally appending the above message, but there doesn't seem to be
any good way to detect AppArmor, for instance "/usr/sbin/aa-status
--enabled" fails unless run as root.

BTW, I'm having a frustrating time post-migration: My profile is 49GB,
Thunderbird decided it needs to re-download all that mail, and it has
also fogotten my per-folder "Sort By > Threaded" preference, that I'll
have to re-click hundreds of times, but only after waiting few days for
that 49GB to be synchronized so that the UI is less frozen.  I have two
other installations of Thunderbird that will likely face the same fate.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 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 thunderbird depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.16-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3+b2
ii  libgcc1   1:6.3.0-10
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-1
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.4-0 1.4.1-2+b2
ii  libicu57  57.1-5
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.4-1
ii  libpangocairo-1.0-0   1.40.4-1
ii  libpangoft2-1.0-0 1.40.4-1
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.16.2-3
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-10
ii  libvpx4   1.6.1-2
ii  libx11-6  2:1.6.4-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b2
ii  x11-utils 7.7+3+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-7
ii  lightning 1:45.8.0-2

Versions of packages thunderbird suggests:
ii  apparmor  2.11.0-2
ii  fonts-lyx 2.2.2-1
ii  libgssapi-krb5-2  1.15-1

-- no debconf information

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
# Output from running "thunderbird --verbose" for the first time prior to
# .icedove migration

INFO  -> [[ ... using verbose mode ... ]]
DEBUG -> found folder '/home/gturner/.icedove'
DEBUG -> not found folder or symlink '/home/gturner/.thunderbird'
DEBUG -> Start Thunderbird profile adoptions, please be patient!
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
DEBUG -> Try to symlink '/home/gturner/.thunderbird' to '/home/gturner/.icedove'
DEBUG -> Success!

# Migration stalled for several minutes at this point, heavy disk I/O with
# "find" subprocess... 

INFO  -> No fix up for /home/gturner/.thunderbird/default/mimeTypes.rdf needed.
DEBUG -> No migration mark '/home/gturner/.thunderbird/.migrated' found, 
checking mimeapps.list files for possible migration.
DEBUG -> Fixing broken 

Bug#858699: Upgrade from Jessie to Stretch failed

[Karsten]

Hello Michael,

thank you for your support!
Your diagnostic was perfect!

Am 25.03.2017 um 14:48 schrieb Michael Biebl:
> You have a problem with hal, afaics. This software has long been
> obsolete. Purge the hal/libhal1 package. It's not needed anymore.

I purged it.

>
> Then your journal log shows a problem with a /proc/bus/usb mount. Remove
> that from /etc/fstab as well.

This was the main problem.
KDE starts after removing this line.

This bug can be closed.


Best regards
Karsten

Bug#810854: git-buildpackage: port to python3

[Guido Günther]

Hi dkg,
On Tue, Mar 21, 2017 at 02:38:55PM -0400, Daniel Kahn Gillmor wrote:
> Over in https://bugs.debian.org/810854, Guido wrote:
> 
> > Note that there's a WiP/Python3 branch at:
> >
> > https://github.com/agx/git-buildpackage/tree/WiP/python3
> >
> > The main blocker why this hasn't happened yet is that
> > +IGNORE_EXCEPTION_DETAIL makes lots of the tests useless and I need find
> > a proper solution to have doctests working and useful in Python2 and
> > Python3.
> 
> if the blocker is making something portable that works in python2 and
> python3, what about just ripping the band aid off and making
> git-buildpackage python3-only?
> 
> git-buildpackage is the main thing that makes me keep python2 around on
> my leaner development machines, and it would be great to just have it
> make the switch to py3.

I hope to finally get around to handle this during debcamp / debconf.
Cheers,
 -- Guido

Bug#858230: reproducing the recent PCRE issues

[Salvatore Bonaccorso]

Hi Matthew,

On Sat, Mar 25, 2017 at 05:00:35PM +, Matthew Vernon wrote:
> Hi,
> 
> > I've tried to reproduce the PCRE3 issues from CVE-2017-7186.
> > CVE-2017-7244, CVE-2017-7245 and CVE-2017-7246 are similar fuzzing
> > attacks so this probably applies to those as well.
> 
> Thanks for looking at these. I fixed CVE-2017-7186 with upstream's patch in
> sid. It's unfortunate that upstream don't seem keen on referring to CVE
> numbers, but I think they correspond roughly thus:
> 
> CVE-2017-7186 - 2052 https://bugs.exim.org/show_bug.cgi?id=2052
> CVE-2017-7244 - 2054 (upstream thinks duplicate of 2052 or 2044
> CVE-2017-7245 - 2055
> CVE-2017-7246 - 2057
>
> So 2054 is either a duplicate of 2052 which we have fixed or 2044, which is
> in pcretest which we don't ship from PCRE3.
>
I did research those yesterday for the current version in testing and
opened corresponding bugs. I will review that again.
 
> The latter 2 upstream describe as "fixed by recent patches", although it's
> not entirely clear to me which patches upstream means - pcre_get.c hasn't
> changed since r1651 if svn log is to be believed. And there aren't many
> plausible-looking commits since 8.40 was released - so I think upstream
> thinks these issues apply only to pcretest (which has had some patches since
> 8.40, but we don't ship in any case).

I did look at those as well, and I think indeed those two are yet
unfixed, at least the reproducer still show the issues with the
current revision in VCS.

[...]
==7050==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7ffea6199f00 at pc 0x557d501f35bd bp 0x7ffea6199250 sp 0x7ffea6199248
WRITE of size 4 at 0x7ffea6199f00 thread T0
#0 0x557d501f35bc in pcre32_copy_substring /root/pcre/pcre_get.c:358
#1 0x557d50072e1b in main /root/pcre/pcretest.c:5342
#2 0x7f182189a2b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#3 0x557d50060de9 in _start (/root/pcre/pcretest+0x1bde9)

Address 0x7ffea6199f00 is located in stack of thread T0 at offset 2336 in frame
#0 0x557d50066fa5 in main /root/pcre/pcretest.c:2987

  This frame has 35 object(s):
[32, 36) 'erroroffset'
[96, 100) 'first_char'
[160, 164) 'need_char'
[224, 228) 'match_limit'
[288, 292) 'recursion_limit'
[352, 356) 'count'
[416, 420) 'backrefmax'
[480, 484) 'first_char_set'
[544, 548) 'need_char_set'
[608, 612) 'okpartial'
[672, 676) 'jchanged'
[736, 740) 'hascrorlf'
[800, 804) 'maxlookbehind'
[864, 868) 'match_empty'
[928, 932) 'callout_data'
[992, 996) 'count'
[1056, 1060) 'd'
[1120, 1128) 'cn32ptr'
[1184, 1192) 'gn32ptr'
[1248, 1256) 'cn16ptr'
[1312, 1320) 'gn16ptr'
[1376, 1384) 'cn8ptr'
[1440, 1448) 'gn8ptr'
[1504, 1512) 'error'
[1568, 1576) 'markptr'
[1632, 1640) 'get_options'
[1696, 1704) 'size'
[1760, 1768) 'nametable'
[1824, 1832) 'sbuf'
[1888, 1904) 'rlim'
[1952, 1976) 'lockout'
[2016, 2040) 'preg'
[2080, 2336) 'copybuffer' <== Memory access at offset 2336 overflows this 
variable
[2368, 6464) 'copynames'
[6496, 10592) 'getnames'
HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /root/pcre/pcre_get.c:358 in 
pcre32_copy_substring
Shadow bytes around the buggy address:
  0x100054c2b390: 00 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2
  0x100054c2b3a0: 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 f2 f2
  0x100054c2b3b0: 00 00 00 f4 f2 f2 f2 f2 00 00 00 f4 f2 f2 f2 f2
  0x100054c2b3c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100054c2b3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100054c2b3e0:[f2]f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
  0x100054c2b3f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100054c2b400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100054c2b410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100054c2b420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100054c2b430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==7050==ABORTING

*But* we should mix the individual issues here in this bugreport I
think. So I will followup individually on the already 

Bug#858643: Re : Bug#858643: desktop-base: File not found in the post-inst script

[nicolas . patrois]

Le 25/03/2017 19:08:30, Wolfgang Schweer a écrit :
> Hi Nicolas.
> 
> On Sat, Mar 25, 2017 at 06:11:25PM +0100, nicolas.patr...@gmail.com
> wrote:
> > I did not know that I had to run update-debian-edu-artwork-spacefun 
> > configure but I just did it. No output then I suspect that it’s OK.
> 
> It should have run via postinst.
> See 'man update-debian-edu-artwork-spacefun', try to disable and 
> re-enable the theme. Any weird output?

Let’s go:
# update-debian-edu-artwork-spacefun remove
update-alternatives: utilisation de « /usr/share/desktop-base/
softwaves-theme » pour fournir « /usr/share/desktop-base/active-theme » 
theme) en mode automatique
update-alternatives: suppression de l'alternative sélectionnée 
manuellement - bascule de ldm-theme vers le mode automatique
update-alternatives: avertissement: l'alternative /usr/share/desktop-
base/active-theme/wallpaper/contents/images/1920x1080.png (qui fait 
partie du groupe de liens desktop-background) n'a pas été trouvée ; 
suppression de la liste des alternatives
update-alternatives: avertissement: /etc/alternatives/desktop-
background pointe dans le vide ; sera mis à jour avec le choix le plus 
adapté
update-alternatives: utilisation de « /usr/share/desktop-base/
softwaves-theme/wallpaper/contents/images/1024x768.svg » pour fournir « 
usr/share/images/desktop-base/desktop-background » (desktop-background) 
en mode automatique

Then:
# update-debian-edu-artwork-spacefun configure
update-alternatives: utilisation de « /usr/share/desktop-base/debian-
edu-spacefun-theme » pour fournir « /usr/share/desktop-base/active-
theme » (desktop-theme) en mode automatique
update-alternatives: utilisation de « /usr/share/ldm/themes/debian-edu-
spacefun » pour fournir « /usr/share/ldm/themes/default » (ldm-theme) 
en mode automatique
update-alternatives: utilisation de « /usr/share/desktop-base/active-
theme/wallpaper/contents/images/1920x1080.png » pour fournir « /usr/
share/images/desktop-base/desktop-background » (desktop-background) en 
mode automatique

> > Does this package need python-numpy somewhere (in post-inst for 
> > example)?
> As far as I can tell: no. 

Good, I have a weird bug with python-numpy and I suspected that it 
impacted other packages.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des 
humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#858734: After system upgrade the sogo plugin seems to freeze icedove

[Karsten]

Package: xul-ext-sogo-connector
Version: 31.0.3-1
Severity: important

I upgraded from Debian Jessie to Stretch.
One of the things that are not running in KDE is Icedove.
It is hanging after the start.

When i start icedove in a shell i can see the following messages:

$ icedove
[calBackendLoader] Using libical backend at
/usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
messenger.groupdav.overlay.js: failed to include 
'chrome://sogo-connector/content/general/vcards.utils.js'
TypeError: redeclaration of let kPhotoImageCache
File: chrome://sogo-connector/content/general/vcards.utils.js
Line: 22

 Stack:

@chrome://sogo-connector/content/general/vcards.utils.js:22:5
jsInclude@chrome://sogo-connector/content/addressbook/messenger.groupdav.overlay.js:26:13
@chrome://sogo-connector/content/addressbook/messenger.groupdav.overlay.js:37:1
startup from sogo-connector
*** new sync: 1
  1/sync with https://PC7/sabredav/groupwareserver.php/addressbooks/privat/...
*** new sync: 2
  2/sync with 
https://PC7/sabredav/groupwareserver.php/addressbooks/name/privat/...
*** new sync: 3
  3/sync with 
https://PC7/sabredav/groupwareserver.php/addressbooks/myname/share/...
exception getting pref 
'extensions.ca.inverse.addressbook.groupdav.ldap_2.servers.name.url':
[Exception... "Component returned failure code: 0x8000 
(NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]"  nsresult:
"0x8000 (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://sogo-connector/content/general/preference.service.addressbook.groupdav.js
 :: GdPSvc__getPref :: line 126"
data: no] (126)
exception getting pref 
'extensions.ca.inverse.addressbook.groupdav.ldap_2.servers.pab.url':
[Exception... "Component returned failure code: 0x8000 
(NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]"  nsresult:
"0x8000 (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://sogo-connector/content/general/preference.service.addressbook.groupdav.js
 :: GdPSvc__getPref :: line 126"
data: no] (126)
exception getting pref 
'extensions.ca.inverse.addressbook.groupdav.ldap_2.servers.history.url':
[Exception... "Component returned failure code: 0x8000 
(NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]"  nsresult:
"0x8000 (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://sogo-connector/content/general/preference.service.addressbook.groupdav.js
 :: GdPSvc__getPref :: line 126"
data: no] (126)


This seems to be the problem.

Best regards
Karsten



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

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

Versions of packages xul-ext-sogo-connector depends on:
ii  icedove   1:45.6.0-2
ii  iceowl-extension  1:45.6.0-2

xul-ext-sogo-connector recommends no packages.

xul-ext-sogo-connector suggests no packages.

-- no debconf information

Bug#858733: RFS: clickhouse/1.1.54190-1 [ITP]

[Jean Baptiste Favre]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: clickhouse
  Version : 1.1.54190-1
  Upstream Author : Yandex
* URL : https://github.com/yandex/ClickHouse
* License : Apache 2.0
  Section : database

It builds those binary packages:

clickhouse-client - Client binary for clickhouse
clickhouse-common - Common files for clickhouse
clickhouse-server - Base package for clickhouse
clickhouse-utils - Various utilities for clickhouse analytics db
libclickhouse-dev - Clickhouse database library development files
libclickhouse1 - Clickhouse database library

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/c/clickhouse/clickhouse_1.1.54190-1.dsc

More information about Clickhouse can be obtained from
https://clickhouse.yandex/

Regards,
Jean Baptiste Favre



signature.asc
Description: OpenPGP digital signature

Bug#858677: No /etc/rc.local file provided

[Daniel Richard G.]

On Sat, 2017 Mar 25 13:25+0100, Martin Pitt wrote:
>
> Right. This is part of the SysV backwards compatibility stuff, but
> that doesn't mean that rc.local should be created and eternally
> handled by systemd itself.

As far as I'm concerned, rc.local stands on its own merits,
independently of SysV.

If I want to "just" add a small startup task---e.g. call setterm(1) to
disable console blanking---without figuring out the intricacies of the
init system du jour, then that's where I go.

> In fact it very much should not, as the precise semantics of rc.local
> are not well defined and it has caused several bug reports and
> confusion already (e. g. "does it wait for the network to be up?",
> which is a question which itself is not well-defined any more in a
> world of hotplug devices, wifi, and roaming).

If the semantics are not well-defined, then the solution is to flesh
them out. Disappearing the file altogether is a non-sequitur,
especially given that all the systemd machinery to execute rc.local
remains in place.

As concerns networking, I would add a note to the file about it, and
perhaps a pointer to the .service file where the dependency can be
tweaked. Choose a reasonable default, and let the user deal with the
hard cases.

> Therefore I close this. The proper way to add your custom jobs to the
> service manager is through systemd units.

Writing a custom systemd unit, and fully integrating with the init
system, is orders of magnitude harder than just adding a line or three
to an existing shell script. Harder, even, than it was to add a custom
SysV init.d script, which was evidently not good enough a solution to
make rc.local unnecessary.

Please remember that not everyone is as familiar with systemd as you
are, and while rc.local is an imperfect solution, it is one that many
users have found helpful---and that continues to be so regardless of the
underlying init system.

Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Christoph Berg]

Control: tags -1 moreinfo

Re: Antonio Terceiro 2017-03-14 <2017031423.xupt5eddlfw5i...@debian.org>
> At the moment I am automating the installation of postgresql and and the
> debversion extension. The fact that there is no "unversioned" binary
> package makes that harder than necessary: I will have to hardcode
> postgresql-X.Y-debversion, and as soon as that deployment recipe need to
> be applied to a different Debian version, that will break.
> 
> So, please provide an unversioned binary package called
> 'postgresql-debversion' which depends on the actual package for the
> current PostgreSQL version.

Hi,

we can't simply put .so files for an arbitrary PostgreSQL version into
a postgresql-debversion.deb because that will break existing
installations on dist upgrade.

What we can do is to "Provides: postgresql-debversion" from each of
the postgresql-X.Y-debversion packages. That should fix your
deployment problem. (However, it won't make upgrades work, because
it doesn't keep the PostgreSQL and extension versions in sync.)

Does that help for your case?

Christoph

Bug#844676: Bits of feedback

[Laura Arjona Reina]

El 25/03/17 a las 19:40, martin f krafft escribió:
> Hey, looking at
> https://www.debian.org/partners/2017/partners.en.html it's great
> to see all this progress. Thank you guys.
> 
> I noticed a few things while reading through it and would like to
> offer some random feedback. Feel free to ignore. ;)
> 

[...]

Note that the text is currently the same that was in the website
untouched since 2001 (16 years, wow).

https://anonscm.debian.org/viewvc/webwml/webwml/english/partners/partners.wml?view=log

We (partners team) still didn't define the new partners program.

Your suggestions will be taken into account for the 2017 program, and
the ones that refer to better readability etc may be "ported" to the
former years description too.

Thanks for the feedback!

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#858146: release.debian.org: unblock (pre-approval): augeas/1.7.0-1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sat, Mar 18, 2017 at 10:18:32PM +0100, Hilko Bengen wrote:
> I would like to upload augeas/1.7.0-1 (1.7.0-0.1 is in testing) and am
> seeking pre-approval.
> 
> I am not worried about the two bugfix patches I added, but I have also
> added Multi-Arch headers to the binary packages as requested in #715554.

> +  * Adopting package
> +  * Update Maintainer, Uploaders fields, with permission from previous
> +maintainer
> +  * Add fixes to NRPE (Closes: #749919) and krb5 (Closes: #822765) parsers

These changes look OK.

> +  * Add Multi-Arch support (Closes: #715554)

Changing that during the freeze is not OK.


Please go ahead with the first set of changes listed above and remove the
moreinfo tag from this bug once the package is in unstable and builds on all
relevant arches.

Cheers,

Ivo

Bug#844676: Bits of feedback

[martin f krafft]

Hey, looking at
https://www.debian.org/partners/2017/partners.en.html it's great
to see all this progress. Thank you guys.

I noticed a few things while reading through it and would like to
offer some random feedback. Feel free to ignore. ;)

1. The first paragraph feels repetitive. I'd probably
   scratch the third/final sentence, and maybe move sentences 1 and
   2 around: because of X, we can improve Debian, DPP was created to
   recognize these important contributions etc.

2. hardware-based (with hyphen)

3. the fourth point is weird, all the others start with a verb,
   except this one.

4. non-technical (with hyphen)

5. I'd be careful about mentioning revenue sharing programmes as
   ongoing financial support. We want reliable/predictable income
   and so I think companies should be committed to paying a fixed
   sum X each year. Revenue-based can be quite volatile, and some
   companies are notoriously known for taking *months* to pay up for
   the year that's passed.

   I'm all in favour of using e.g. revenue to influence ranking,
   such that a 1m revenue company giving 1.000 a year should be
   recognized the same as a 100m company giving 100.000. This is not
   too hard to do, I think. But once they commit, we should know how
   much money to expect, and dictate when it's payable.

6. Last paragraph under "what are the criteria" — are there no lower
   bounds on meeting criteria? I.e. assume I "assist Debian in
   distribution of releases" by distributing five CDs. Do I get
   listed? Maybe the word "substantial" needs to be included
   somewhere.

7. Which part of "Debian understand the partners needs an concerns"?
   How do we ensure to "remain properly focused within the market
   through partner's feedback"? I feel like this is a huge promise
   we won't be able (or might not want to) keep.

8. Debian partners can also advertise being Debian partners in their
   own PR. That's a benefit, apart from the cooperation we expect
   from our partners under "what do partners do for debian"?

9. Under "how does a vendor become partner", I feel like this sounds
   a bit harsh/hard. Consider maybe something like "If you're
   interested in becoming a partner of Debian, please send us your
   proposal of partnership to partn...@debian.org. We'll review it,
   and engage with you to establish acceptable terms for the
   partnership."

10. I hope that long-term the goal is to integrate DebConf and LTS
   into this centralised effort.

I am so happy to see this moving forward.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#858633: libreoffice-dmaths: DMath isn't installed in Libreoffice 5.2

[Innocent De Marchi]

Hi TheSuperGeek,

Yes, I know this issue. Apparently, it is due to changes in the management
of LibreOffice plug-ins.
I have to investigate how to install the package with the changes.

Regards!

I. De Marchi

2017-03-24 18:20 GMT+01:00 TheSuperGeek :

> Package: libreoffice-dmaths
> Version: 3.7.0.0+dfsg1-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
> I've got a problem with libreoffice 5.2.5.1 and DMath 3.7 : DMath isn't
> installed. I cannot find it into Libreoffice's extention manager too.
> I installed libreoffice-dmath, purged it and re-installed it but it even
> don't
> work.
> The upstream version looks to be in 4.xx but for paying users only.
> So for the moment the package don't work on debian stretch.
> Best regards,
> TheSuperGeek
>
>
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-2-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)
>
> Versions of packages libreoffice-dmaths depends on:
> ii  libreoffice-draw1:5.2.5-2
> ii  libreoffice-writer  1:5.2.5-2
> ii  zenity  3.22.0-1+b1
>
> libreoffice-dmaths recommends no packages.
>
> Versions of packages libreoffice-dmaths suggests:
> pn  dia
> pn  drgeo  
>
> -- no debconf information
>

Bug#854509: Any news

[Bastien ROUCARIES]

Hi,

Any news of packaging datenow ? If not I will become owner
bastien

Bug#840609: First need to clarify zlib relationship

[Bastien ROUCARIES]

Upstream need to clarify zlib relationship.

Licensing issue here:
https://github.com/nodeca/pako/issues/93

Bug#858732: general: Hash Sum mismatch for libgtk-3-doc all 3.22.9-4

[Victor Porton]

Package: general
Severity: important

$ sudo apt dist-upgrade 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  lightning thunderbird
The following packages have been kept back:
  phonon4qt5-backend-vlc vlc vlc-nox xscreensaver-data-extra
The following packages will be upgraded:
  bluez bluez-obexd calendar-google-provider cpp-6 dmsetup evolution 
evolution-common evolution-data-server evolution-data-server-common 
evolution-plugins g++-6 gcc-6 gcc-6-base
  gcc-6-multilib gcj-6-jre-headless gcj-6-jre-lib gir1.2-gtk-3.0 
gir1.2-secret-1 gnat-6 gnome-control-center gnome-control-center-data 
gnome-settings-daemon google-cloud-sdk
  gtk-update-icon-cache icedove iceowl-extension lib64asan3 lib64atomic1 
lib64cilkrts5 lib64gcc-6-dev lib64gcc1 lib64gomp1 lib64itm1 lib64mpx2 
lib64quadmath0 lib64stdc++6 lib64ubsan0
  libasan3 libatomic1 libbluetooth3 libcamel-1.2-59 libcc1-0 libcilkrts5 
libdevmapper-event1.02.1 libdevmapper1.02.1 libebackend-1.2-10 libebook-1.2-16 
libebook-contacts-1.2-2
  libecal-1.2-19 libedata-book-1.2-25 libedata-cal-1.2-28 libedataserver-1.2-22 
libedataserverui-1.2-1 libevolution libgail-3-0 libgcc-6-dev libgcc1 libgcj17 
libgcj17-awt libgfortran3
  libgnat-6 libgnatcoll-gtk1.7 libgnatcoll-iconv1.7 libgnatcoll-python1.7 
libgnatcoll-readline1.7 libgnatcoll-sqlite-bin libgnatcoll-sqlite1.7 
libgnatcoll1.7 libgnatprj6 libgnatvsn6
  libgomp1 libgtk-3-0 libgtk-3-bin libgtk-3-common libgtk-3-dev libgtk-3-doc 
libgtkada-bin libgtkada3.8.3 libgtkada3.8.3-dev libinput-bin libinput10 libitm1 
libllvm3.8 libllvm3.9
  liblvm2app2.2 libmpx2 libobjc4 libpcre2-8-0 libplist3 libquadmath0 libsasl2-2 
libsasl2-modules libsasl2-modules-db libsecret-1-0 libsecret-common 
libstdc++-6-dev libstdc++6
  libubsan0 libx32asan3 libx32atomic1 libx32cilkrts5 libx32gcc-6-dev libx32gcc1 
libx32gomp1 libx32itm1 libx32quadmath0 libx32stdc++6 libx32ubsan0 
libxmlada-dom4.5.2015
  libxmlada-input-sources4.5.2015 libxmlada-sax4.5.2015 
libxmlada-schema4.5.2015 libxmlada-unicode4.5.2015 putty putty-tools spark 
twoftpd
117 upgraded, 2 newly installed, 0 to remove and 4 not upgraded.
Need to get 3,364 kB/186 MB of archives.
After this operation, 2,756 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://mirror.vorboss.net/debian stretch/main i386 libgtk-3-doc all 
3.22.9-4 [3,364 kB]
Err:1 http://mirror.vorboss.net/debian stretch/main i386 libgtk-3-doc all 
3.22.9-4
  
  Hash Sum mismatch
  Hashes of expected file:
   - SHA256:7e9115881a5ec6fd9d4786ee82e32c3faa8932eac4913c6472a64cd86ac72f39
   - MD5Sum:60da130a771ae10005a50bd31510836b [weak]
   - Filesize:3364012 [weak]
  Hashes of received file:
   - SHA256:5e411017f5315f6c8c57414be7046652886024d014e59d5d0adf0c71722bb3f5
   - MD5Sum:b196973d48748cf62594b69cc5bd586a [weak]
   - Filesize:3364012 [weak]
  Last modification reported: Tue, 14 Mar 2017 04:28:20 +
Fetched 3,364 kB in 12s (266 kB/s)  


E: Failed to fetch 
http://mirror.vorboss.net/debian/pool/main/g/gtk+3.0/libgtk-3-doc_3.22.9-4_all.deb
  Hash Sum mismatch
   Hashes of expected file:
- SHA256:7e9115881a5ec6fd9d4786ee82e32c3faa8932eac4913c6472a64cd86ac72f39
- MD5Sum:60da130a771ae10005a50bd31510836b [weak]
- Filesize:3364012 [weak]
   Hashes of received file:
- SHA256:5e411017f5315f6c8c57414be7046652886024d014e59d5d0adf0c71722bb3f5
- MD5Sum:b196973d48748cf62594b69cc5bd586a [weak]
- Filesize:3364012 [weak]
   Last modification reported: Tue, 14 Mar 2017 04:28:20 +
E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: i386 (i686)

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

Bug#858716: [Pkg-xfce-devel] Bug#858716: xfce4-settings: xfce4-settings-manager do not expand vertically xfce4-notifyd-config dialog

[Antonio Cebrián]

Package: xfce4-notifyd
Version: 0.3.4-1

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

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

Versions of packages xfce4-notifyd depends on:
ii  libc6   2.24-9
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.50.3-1
ii  libgtk-3-0  3.22.9-4
ii  libnotify4  0.7.7-1+b1
ii  libx11-62:1.6.4-3
ii  libxfce4ui-2-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1

Versions of packages xfce4-notifyd recommends:
ii  libnotify-bin  0.7.7-1+b1

xfce4-notifyd suggests no packages.

-- no debconf information


2017-03-25 16:45 GMT+01:00 Yves-Alexis Perez :

> On Sat, 2017-03-25 at 13:41 +0100, Antonio Cebrian wrote:
> > xfce4-notifyd-config dialog is not expanded vertically when called from
> > xfce4-settings-manager.
> >
> > xfce4-notifyd-config dialog called alone is correctly expanded
> vertically so
> > seem to be a xfce4-settings-manager problem.
> >
> > Attached both cases dialog screenshoots.
>
> Hi,
>
> Which version of xfce4-notifyd do you have?
>
> Regards,
> --
> Yves-Alexis

Bug#858403: unblock: screen/4.5.0-4 (pre-approval)

[Ivo De Decker]

Control: tags -1 d-i

Hi,

On Wed, Mar 22, 2017 at 11:37:52PM +0100, Axel Beckert wrote:
> Uploaded. Full final debdiff attached.

Unblocked. This needs an unblock-udeb as well. Cc'ing Kibi for that. Full diff
quoted below.

Cheers,

Ivo


> diff -Nru screen-4.5.0/debian/changelog screen-4.5.0/debian/changelog
> --- screen-4.5.0/debian/changelog 2017-01-24 22:57:44.0 +0100
> +++ screen-4.5.0/debian/changelog 2017-03-22 01:13:07.0 +0100
> @@ -1,8 +1,17 @@
> +screen (4.5.0-4) unstable; urgency=low
> +
> +  * Add CVE-ID to previous changelog entry and
> +62-reverse-cherry-pick-5460f5d2-to-fix-privilege-escalation.patch.
> +  * Apply patch by Samuel Thibault to fix terminal garbage in Debian
> +Installer over serial line. (Closes: #857808)
> +
> + -- Axel Beckert   Wed, 22 Mar 2017 01:13:07 +0100
> +
>  screen (4.5.0-3) unstable; urgency=medium
>  
>* Add patch to revert upstream commit 5460f5d2 ("adding permissions
>  check for the logfile name") which caused a privilege escalation.
> -(Closes: #852484)
> +(CVE-2017-5618, Closes: #852484)
>  
>   -- Axel Beckert   Tue, 24 Jan 2017 22:57:44 +0100
>  
> diff -Nru 
> screen-4.5.0/debian/patches/62-reverse-cherry-pick-5460f5d2-to-fix-privilege-escalation.patch
>  
> screen-4.5.0/debian/patches/62-reverse-cherry-pick-5460f5d2-to-fix-privilege-escalation.patch
> --- 
> screen-4.5.0/debian/patches/62-reverse-cherry-pick-5460f5d2-to-fix-privilege-escalation.patch
>  2017-01-24 22:48:04.0 +0100
> +++ 
> screen-4.5.0/debian/patches/62-reverse-cherry-pick-5460f5d2-to-fix-privilege-escalation.patch
>  2017-03-22 01:13:07.0 +0100
> @@ -1,7 +1,7 @@
> -Description: Fix privilege escalation by reverting upstream commit 5460f5d2
> +Description: [CVE-2017-5618] Fix privilege escalation by reverting upstream 
> commit 5460f5d2
>  Author: Axel Beckert 
>  Bug-Debian: https://bugs.debian.org/852484
> -Bug-CVE: http://www.openwall.com/lists/oss-security/2017/01/24/10
> +Bug-CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5618
>  Bug: https://savannah.gnu.org/bugs/?50142
>   https://lists.gnu.org/archive/html/screen-devel/2017-01/msg00025.html
>  
> diff -Nru screen-4.5.0/debian/patches/63-fix-garbage-on-serial-terminal.patch 
> screen-4.5.0/debian/patches/63-fix-garbage-on-serial-terminal.patch
> --- screen-4.5.0/debian/patches/63-fix-garbage-on-serial-terminal.patch   
> 1970-01-01 01:00:00.0 +0100
> +++ screen-4.5.0/debian/patches/63-fix-garbage-on-serial-terminal.patch   
> 2017-03-22 01:13:07.0 +0100
> @@ -0,0 +1,17 @@
> +Description: Fix terminal garbage in Debian Installer over serial line
> +Author: Samuel Thibault 
> +Reviewed-By: John Paul Adrian Glaubitz 
> +Bug-Debian: https://bugs.debian.org/857808
> +Bug: https://savannah.gnu.org/bugs/?50588
> +
> +--- a/termcap.c
>  b/termcap.c
> +@@ -486,6 +486,8 @@
> + 
> +   D_tcinited = 1;
> +   MakeTermcap(0);
> ++  /* Make sure libterm uses external term properties for our tputs() calls. 
>  */
> ++  e_tgetent(tbuf, D_termname);
> + #ifdef MAPKEYS
> +   CheckEscape();
> + #endif
> diff -Nru screen-4.5.0/debian/patches/series 
> screen-4.5.0/debian/patches/series
> --- screen-4.5.0/debian/patches/series2017-01-24 22:46:11.0 
> +0100
> +++ screen-4.5.0/debian/patches/series2017-03-22 01:13:07.0 
> +0100
> @@ -11,6 +11,7 @@
>  60-screen-4.2.1-debian4.1.0-compatibility.patch
>  61-default-PATH_MAX-if-undefined-for-hurd.patch
>  62-reverse-cherry-pick-5460f5d2-to-fix-privilege-escalation.patch
> +63-fix-garbage-on-serial-terminal.patch
>  # 80-99: experimental patches, new features etc.
>  80_session_creation_docs.patch
>  81_session_creation_util.patch

Bug#858643: desktop-base: File not found in the post-inst script

[Wolfgang Schweer]

Hi Nicolas.

On Sat, Mar 25, 2017 at 06:11:25PM +0100, nicolas.patr...@gmail.com wrote:
> I did not know that I had to run update-debian-edu-artwork-spacefun 
> configure but I just did it. No output then I suspect that it’s OK.

It should have run via postinst.
See 'man update-debian-edu-artwork-spacefun', try to disable and 
re-enable the theme. Any weird output?

> > run 'apt install debian-edu-artwork-spacefun' 
> 
> Does this package need python-numpy somewhere (in post-inst for 
> example)?

As far as I can tell: no. 

Wolfgang


signature.asc
Description: PGP signature

Bug#858731: Please bump CONFIG_NR_CPUS to 256 on s390x

[Philipp Kern]

Source: linux
Version: 3.16.39-1

Currently linux's kconfig in stable/testing/unstable sets
CONFIG_NR_CPUS=32 on s390x. This is unhelpful when you have more cores
than that assigned to a VM/LPAR. Reportedly all of SUSE, RedHat, and
Ubuntu set it to 256 these days. Our amd64 config sets it to 512. I'd
suggest bumping it at least to 256 in the Debian package.

(This actually came up as a problem on the LINUX-360 mailing list.)

Kind regards and thanks for considering the change
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#858230: reproducing the recent PCRE issues

[Matthew Vernon]

Hi,


I've tried to reproduce the PCRE3 issues from CVE-2017-7186.
CVE-2017-7244, CVE-2017-7245 and CVE-2017-7246 are similar fuzzing
attacks so this probably applies to those as well.


Thanks for looking at these. I fixed CVE-2017-7186 with upstream's patch 
in sid. It's unfortunate that upstream don't seem keen on referring to 
CVE numbers, but I think they correspond roughly thus:


CVE-2017-7186 - 2052 https://bugs.exim.org/show_bug.cgi?id=2052
CVE-2017-7244 - 2054 (upstream thinks duplicate of 2052 or 2044
CVE-2017-7245 - 2055
CVE-2017-7246 - 2057

So 2054 is either a duplicate of 2052 which we have fixed or 2044, which 
is in pcretest which we don't ship from PCRE3.


The latter 2 upstream describe as "fixed by recent patches", although 
it's not entirely clear to me which patches upstream means - pcre_get.c 
hasn't changed since r1651 if svn log is to be believed. And there 
aren't many plausible-looking commits since 8.40 was released - so I 
think upstream thinks these issues apply only to pcretest (which has had 
some patches since 8.40, but we don't ship in any case).


*If* that's correct, then we don't need to do any more for sid's pcre3, 
I think.


Regards,

Matthew

Bug#858730: mudlet FTBFS on !amd64: /usr/lib/x86_64-linux-gnu/qt5/bin/qmake: Command not found

[Adrian Bunk]

Source: mudlet
Version: 1:3.0.0-1
Severity: serious

https://buildd.debian.org/status/package.php?p=mudlet=sid

...
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/«PKGBUILDDIR»'
[ ! -f src/Makefile ] || /usr/bin/make -C src distclean
make[2]: Entering directory '/«PKGBUILDDIR»/src'
/usr/lib/x86_64-linux-gnu/qt5/bin/qmake -o Makefile src.pro
make[2]: /usr/lib/x86_64-linux-gnu/qt5/bin/qmake: Command not found
Makefile:627: recipe for target 'Makefile' failed
make[2]: *** [Makefile] Error 127


x86_64-linux-gnu is not part of paths that are expected to exist
on !amd64, the generated src/Makefile should not be used.

Bug#858180: unblock: diaspora-installer/0.6.3.0+debian2

[Ivo De Decker]

Hi,

On Fri, Mar 24, 2017 at 10:52:44AM +0530, Pirate Praveen wrote:
> I don't understand why diaspora-installer was removed from testing. #858521 
> was
> only affecting unstable.

There are serious doubts whether this package is suitable for a stable
release. The version that was in testing clearly wasn't (#856720 was the
trigger for the original request in this unblock bug). Previous attempts to
fix the issues weren't successful, and a review of the latest changes,
combined with the filing of #858521 (which was found by piuparts testing),
raises serious concerns about the quality of the package. For it to be allowed
back into testing, a thorough review of the entire packaging would be needed,
and I don't know it that's realistic for stretch.

Cheers,

Ivo

Bug#854228: Libraries not linked with their deps

[Muammar El Khatib]

Dear all,

On Mon, Mar 20, 2017 at 11:03 PM, Drew Parsons  wrote:
> Probably the solution we want is to update our scalapack to 2.0.2, and
> remove this blacs package, at least as a separate source package. That
> won't happen for stretch, obviously.

I am sorry for the delay in replying to this report. I am right now
preparing to upload a Debian revision that adds the patch in #848813
for fixing the FTBFS.

Lately, I have had limited time to take care of ScaLAPACK, and I think
it is time to move it to team maintenance. I was thinking of
Debian-science. I have already sent an email to the mailing list.

Regards,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#858643: desktop-base: File not found in the post-inst script

[nicolas . patrois]

Le 25/03/2017 15:07:56, Wolfgang Schweer a écrit :

> which version of debian-edu-artwork-spacefun is installed on your 
> system? Did you run 'update-debian-edu-artwork-spacefun configure'?

Paquet : debian-edu-artwork-spacefun
Version : 0.902-3
Nouveau: oui
État: installé
I did not know that I had to run update-debian-edu-artwork-spacefun 
configure but I just did it. No output then I suspect that it’s OK.

> run 'apt install debian-edu-artwork-spacefun' 

Does this package need python-numpy somewhere (in post-inst for 
example)?

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des 
humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#858726: i3-wm: Mod5 (alias AltGr, ISO_Level3_Shift) in defautlt German keyboard layout not working if used in the i3 config file

[Michael Stapelberg]

As this is not a Debian-specific bug, can you please report it upstream at
https://github.com/i3/i3? Be sure to include your config file and ideally a
log file, as the page will prompt you to.

On Sat, Mar 25, 2017 at 4:43 PM, Smbw  wrote:

> Package: i3-wm
> Version: 4.13-1
> Severity: normal
> Tags: l10n
>
> Dear Maintainer,
>
>  * What led up to the situation?
> I moved my i3 config file from Jessie (~/.i3/config) to Stretch
> (~/.config/i3/config). I'm using a German keyboard and the default German
> keyboard layout. In the config I make use of Mod1 and Mod5 while on Jessie
> this
> worked fine in Stretch I'm unable to reference to the AltGr key in any way
> in
> the i3 config file.
>
>  * What exactly did you do that was ineffective?
> I checked the output of xmodmap -pm which is identical on both systems
> also the
> keycodes are the same (checked with xev). I verified the problem on another
> machine with a different (German) keyboard.
>
>  * What was the outcome of this action?
> I was not able to use the AltGr key in any way in i3
>
>  * What outcome did you expect instead?
> I would like to set the AltGr key as defautl modifier ($mod) or to use it
> in any
> other way in i3.
>
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages i3-wm depends on:
> ii  libc6 2.24-9
> ii  libcairo2 1.14.8-1
> ii  libev41:4.22-1
> ii  libglib2.0-0  2.50.3-1
> ii  libpango-1.0-01.40.4-1
> ii  libpangocairo-1.0-0   1.40.4-1
> ii  libpcre3  2:8.39-2.1
> ii  libstartup-notification0  0.12-4+b2
> ii  libxcb-cursor00.1.1-3
> ii  libxcb-icccm4 0.4.1-1
> ii  libxcb-keysyms1   0.4.0-1+b2
> ii  libxcb-randr0 1.12-1
> ii  libxcb-util0  0.3.8-3+b2
> ii  libxcb-xinerama0  1.12-1
> ii  libxcb-xkb1   1.12-1
> ii  libxcb-xrm0   1.0-2
> ii  libxcb1   1.12-1
> ii  libxkbcommon-x11-00.7.1-1
> ii  libxkbcommon0 0.7.1-1
> ii  libyajl2  2.1.0-2+b3
> pn  perl:any  
> ii  x11-utils 7.7+3+b1
>
> Versions of packages i3-wm recommends:
> ii  fonts-dejavu-core   2.37-1
> ii  libanyevent-i3-perl 0.16-1
> ii  libjson-xs-perl 3.030-1
> ii  rxvt-unicode [x-terminal-emulator]  9.22-1+b1
> ii  xfonts-base 1:1.0.4+nmu1
>
> i3-wm suggests no packages.
>
> -- no debconf information
>



-- 
Best regards,
Michael

Bug#858729: plasma-discover: too many bugs for the next stable

[Leand]

Package: plasma-discover
Version: 5.8.5-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The version of Discover provided in Stretch is too bugged and
immature, it is not suitable for a stable release. Please remove it or
provide a newer version.

There are basic functions that are bugged. For example, the search
function returns wrong and unrelated results too many times. If I
search for "office" or "writer" it doesn't show LibreOffice packages
or LibreOffice Writer at all. Furthermore in some cases it doesn't
even display the exact name of the packages in any way, for example
the package "file-roller" (Gnome's File Roller) is displayed as
"Archive manager".

Other issues: Discover doesn't display the dependencies of a package
and don't ask for confirmation when installing one; when removing an
application the confirmation dialog may display wrong info (search for
gimp, ask to remove it and the dialog will display xsane, bleachbit
and unrelated packages).

There are also issues with the interface but, simply, this application
is still immature and unreliable. It cannot be used for package
management.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 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 plasma-discover depends on:
ii appstream 0.10.6-1
ii kio 5.28.0-1
ii libappstreamqt2 0.10.6-1
ii libc6 2.24-9
ii libkf5archive5 5.28.0-1+b2
ii libkf5attica5 5.28.0-1
ii libkf5configcore5 5.28.0-1+b2
ii libkf5configgui5 5.28.0-1+b2
ii libkf5configwidgets5 5.28.0-1
ii libkf5coreaddons5 5.28.0-1+b2
ii libkf5crash5 5.28.0-1
ii libkf5dbusaddons5 5.28.0-1
ii libkf5declarative5 5.28.0-1
ii libkf5i18n5 5.28.0-1+b2
ii libkf5kiocore5 5.28.0-1
ii libkf5kiowidgets5 5.28.0-1
ii libkf5newstuff5 5.28.0-1
ii libkf5notifications5 5.28.0-1
ii libkf5service-bin 5.28.0-1
ii libkf5service5 5.28.0-1
ii libkf5widgetsaddons5 5.28.0-1
ii libkf5xmlgui5 5.28.0-1
ii libpackagekitqt5-0 0.9.6-1
ii libqt5core5a 5.7.1+dfsg-3+b1
ii libqt5dbus5 5.7.1+dfsg-3+b1
ii libqt5gui5 5.7.1+dfsg-3+b1
ii libqt5qml5 5.7.1-2+b2
ii libqt5quick5 5.7.1-2+b2
ii libqt5widgets5 5.7.1+dfsg-3+b1
ii libqt5xml5 5.7.1+dfsg-3+b1
ii libstdc++6 6.3.0-10
ii packagekit 1.1.5-2
ii plasma-discover-common 5.8.5-3
ii qml-module-org-kde-kirigami 1.1.0-1

Versions of packages plasma-discover recommends:
ii software-properties-kde 0.96.20.2-1

plasma-discover suggests no packages.

-- no debconf information

Bug#858644: [pkg-firebird-general] Bug#858644: CVE-2017-6369: authenticated remote execution in firebird 2.5 before version 3.0.2

[Damyan Ivanov]

-=| Damyan Ivanov, 24.03.2017 19:22:53 + |=-
> Relevant upstream commits for 3.0:
>  - 
> https://github.com/FirebirdSQL/firebird/commit/8b2a9cb44bf6055e15f016d70a6842b8ada60375

Correction: the commit for 3.0 (branch B3_0_Release) is 
https://github.com/FirebirdSQL/firebird/commit/56e9a73c16803c3544076edb2d6c4ca25815e541

8b2a9cb4 is the commit in the master branch.


-- dam


signature.asc
Description: Digital signature

Bug#858728: unblock: parallax/1.0.1-3

[Valentin Vidic]

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

Please unblock package parallax

The upload fixes a missing depends on openssh-client as reported
in #854722.  Since the library does not function without the openssh
installed it would be good to have this fixed for the stable release.


diff -Nru parallax-1.0.1/debian/changelog parallax-1.0.1/debian/changelog
--- parallax-1.0.1/debian/changelog 2016-12-29 15:09:19.0 +0100
+++ parallax-1.0.1/debian/changelog 2017-03-25 11:09:15.0 +0100
@@ -1,3 +1,9 @@
+parallax (1.0.1-3) unstable; urgency=medium
+
+  * Add openssh-client depends (Closes: #854722)
+
+ -- Valentin Vidic   Sat, 25 Mar 2017 11:09:15 +0100
+
 parallax (1.0.1-2) unstable; urgency=low
 
   * Move internal scripts to /usr/lib/parallax
diff -Nru parallax-1.0.1/debian/control parallax-1.0.1/debian/control
--- parallax-1.0.1/debian/control   2016-12-29 15:09:19.0 +0100
+++ parallax-1.0.1/debian/control   2017-03-25 11:06:16.0 +0100
@@ -11,7 +11,7 @@
 
 Package: python-parallax
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
+Depends: openssh-client, ${misc:Depends}, ${python:Depends}
 Description: Execute commands and copy files over SSH (Python 2)
  Parallax SSH provides an interface to executing commands on multiple nodes at
  once using SSH. It also provides commands for sending and receiving files to
@@ -21,7 +21,7 @@
 
 Package: python3-parallax
 Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}
+Depends: openssh-client, ${misc:Depends}, ${python3:Depends}
 Description: Execute commands and copy files over SSH (Python 3)
  Parallax SSH provides an interface to executing commands on multiple nodes at
  once using SSH. It also provides commands for sending and receiving files to
diff -Nru parallax-1.0.1/debian/tests/control 
parallax-1.0.1/debian/tests/control
--- parallax-1.0.1/debian/tests/control 2016-12-29 15:09:19.0 +0100
+++ parallax-1.0.1/debian/tests/control 2017-03-25 11:06:36.0 +0100
@@ -1,7 +1,7 @@
 Tests: testsuite
-Depends: python-parallax, openssh-server, openssh-client, adduser
+Depends: python-parallax, openssh-server, adduser
 Restrictions: needs-root, isolation-container
 
 Tests: testsuite3
-Depends: python3-parallax, openssh-server, openssh-client, adduser
+Depends: python3-parallax, openssh-server, adduser
 Restrictions: needs-root, isolation-container

unblock parallax/1.0.1-3

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
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)

Bug#856216: please use more if less is gone

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Less wasn't removed, but /usr/bin/less (a symlink!) became
unavailable during the upgrade. After the upgrade from Jessie
to Stretch (including a new "less" package) /usr/bin/less was
back.

Regards
Harri
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEH2V614LbR/u1O+a1Cp4qnmbTgcsFAljWmzMACgkQCp4qnmbT
gctxlQf+IO5REwGg5JI+kf+defQ09CZ8DGtsAr2c8Q74WzYkv/LP9xjLgWMFs+Fy
SFJXr5PsoJYdchWPQdwiSdm59vuSi4NtDvCRe63BsGUoW9oVyfc1sGYpOdq+opXN
uvvtuYJhuj0mbPJuVntrzLldrXB/7r9vi0/ftzs7Sqiu5jOBYR8zJNZlIY1U1MBW
ZVE77ERJjgtE+38bSUYkkLQ0z+uNeDgei0cHLdOxK1XHzHiFpuTuVqIGN/8pOpr+
w0H7OuXPGcnvoEwVzCIp+2Vk5nrATwscQvz8Tgme5aQZkG66OEO7JIQsiPjrWgdI
+4fVOQqdyeJJ+/2xXiFwQxZZbr7QfQ==
=nKMG
-END PGP SIGNATURE-

Bug#857344: exim4-daemon-heavy: segfault in DKIM verification

[Andreas Metzler]

Version: 4.89-1

On 2017-03-10 Michal Čihař  wrote:
> Andreas Metzler píše v Pá 10. 03. 2017 v 18:45 +0100:
>> Looks like https://bugs.exim.org/show_bug.cgi?id=2029 which indeed
>> should be fixed in 4.89.

> I'm running 4.89-1 for six hours now and haven't seen any crashes, so
> indeed it looks good.

Let' mark it as fixed in 4.89.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#856133: shiboken FTBFS on i386/armel/armhf: other_collector_external_operator test failed

[Gilles Filippini]

On Sat, 4 Mar 2017 20:06:36 +0100 gregor herrmann  wrote:
> On Sat, 25 Feb 2017 16:07:03 +0200, Adrian Bunk wrote:
> 
> > Source: shiboken
> > Version: 1.2.2-3
> > Severity: serious
> > 
> > https://buildd.debian.org/status/package.php?p=shiboken=sid
> > 
> 
> FWIW, the package currently builds fine for me in an i386 sid
> cowbuilder chroot (and an amd64 machine).

Strangely it builds fine in an i386 sbuild chroot, but it fails
reproducibly on porter box barriere.debian.org.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#856341: [Freewx-maint] Bug#856341: python-wxgtk3.0: Warning about wxPython is using an older C++ ABI

[Scott Talbert]

On Fri, 24 Mar 2017, Ruben Undheim wrote:


In some programs such as pcbnew (kicad), this is not
just a simple Warning message being written to console,
but actually an annoying message box popping up disturbing
the work-flow.

I honestly think this needs to be release-critical for Stretch.


I requested a binNMU for wxpython.  This should hopefully take care of it.

Scott

Bug#858670: nmu: wxpython3.0_3.0.2.0+dfsg-3

[Adam D. Barratt]

Control: tags -1 - moreinfo

On Sat, 2017-03-25 at 11:39 -0400, Scott Talbert wrote:
> On Sat, 25 Mar 2017, Adam D. Barratt wrote:
> 
> >> wxwidgets3.0 was recently binNMU'd in stretch.  wxpython3.0 needs to be
> >> rebuilt to avoid a C++ ABI mismatch warning when all wxPython
> >> applications are used.
> >
> > It was binNMUed _in unstable_, a month ago. If there's an issue, why
> > wasn't it noticed earlier?
> 
> I wasn't aware of the fact that wxWidgets was binNMUed until someone 
> reported a problem, as there isn't any sort of notification.  In fact, I 
> can't even find a bug report that requested one.

It's part of the process that starts being discussed at
https://lists.debian.org/msgid-search/7507c8e4-870f-d67b-9284-fa4a5908e...@balintreczey.hu

> > More specifically, I can only see one binNMU for wxpython3.0 having been
> > performed in the past, in 2015. If the packages are so tightly coupled,
> > shouldn't there have been far more frequent rebuilds in the past? (and
> > how did the combination of wxwidgets3.0 uploaded on 2016-07-29 and
> > wxpython3.0 uploaded on 2016-07-19 work?)
> 
> The coupling is really only related to C++ ABI changes.  As long as the 
> C++ ABI hasn't change, there isn't any problem.

Ah, ok. So timing related.

> >> nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . stretch . -m "Rebuild due to 
> >> wxWidgets C++ ABI change"
> >
> > That won't work, in any case - unstable and testing have the same binary
> > version of the packages, so the binNMUs would have to be performed in
> > unstable and then migrate (as testing can't have a higher version of the
> > package than unstable).
> 
> My bad, I'm relatively unfamiliar with the binNMU process.  So it should 
> be:
> 
> nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . unstable . -m "Rebuild due to 
> wxWidgets C++ ABI change"

Yes, although the suite name can be omitted in this case. (The
constraint isn't specific to binNMUs, fwiw - no package can have a
higher version in testing than in unstable.)

Scheduled:

adsb@wuiet:~$ wb nmu wxpython3.0 . ANY . -m "Rebuild with gcc 6.3 to match 
wxwidgets3.0's C++ ABI"
W: package wxpython3.0 is not installed on powerpcspe, can't binNMU.
adsb@wuiet:~$ 

(powerpcspe is a ports architecture, so that warning isn't an issue for
stretch.)

> Does it then automatically migrate to testing, or does an unblock have to 
> be filed?

binNMUs are automatically candidates for migration and don't need
unblocking; successful migration still assumes that they don't end up
with any dependency or installability issues.

Regards,

Adam

Bug#858727: h5py: Missing install dependency on numpy-dbg

[Ghislain Antony Vaillant]

Source: h5py
Severity: important

The h5py debug packages are missing an install dependency on their
corresponding numpy-dbg package. This can be verified by running the
as-installed test suite of the package, which yields the following
ImportError:

```
File "/usr/lib/python2.7/dist-packages/numpy/core/__init__.py", line 24,
in 
raise ImportError(msg)
ImportError: 
Importing the multiarray numpy extension module failed.  Most likely you
are trying to import a failed build of numpy. If you're working with a
numpy git repo, try `git clean -xdf` (removes all files not under
version control).  Otherwise reinstall numpy.
```

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
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)

Bug#858670: nmu: wxpython3.0_3.0.2.0+dfsg-3

[Scott Talbert]

On Sat, 25 Mar 2017, Adam D. Barratt wrote:


wxwidgets3.0 was recently binNMU'd in stretch.  wxpython3.0 needs to be
rebuilt to avoid a C++ ABI mismatch warning when all wxPython
applications are used.


It was binNMUed _in unstable_, a month ago. If there's an issue, why
wasn't it noticed earlier?


I wasn't aware of the fact that wxWidgets was binNMUed until someone 
reported a problem, as there isn't any sort of notification.  In fact, I 
can't even find a bug report that requested one.



More specifically, I can only see one binNMU for wxpython3.0 having been
performed in the past, in 2015. If the packages are so tightly coupled,
shouldn't there have been far more frequent rebuilds in the past? (and
how did the combination of wxwidgets3.0 uploaded on 2016-07-29 and
wxpython3.0 uploaded on 2016-07-19 work?)


The coupling is really only related to C++ ABI changes.  As long as the 
C++ ABI hasn't change, there isn't any problem.



nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . stretch . -m "Rebuild due to wxWidgets C++ 
ABI change"


That won't work, in any case - unstable and testing have the same binary
version of the packages, so the binNMUs would have to be performed in
unstable and then migrate (as testing can't have a higher version of the
package than unstable).


My bad, I'm relatively unfamiliar with the binNMU process.  So it should 
be:


nmu wxpython3.0_3.0.2.0+dfsg-3 . ANY . unstable . -m "Rebuild due to wxWidgets C++ 
ABI change"

Does it then automatically migrate to testing, or does an unblock have to 
be filed?

Bug#858726: i3-wm: Mod5 (alias AltGr, ISO_Level3_Shift) in defautlt German keyboard layout not working if used in the i3 config file

[Smbw]

Package: i3-wm
Version: 4.13-1
Severity: normal
Tags: l10n

Dear Maintainer,

 * What led up to the situation?
I moved my i3 config file from Jessie (~/.i3/config) to Stretch 
(~/.config/i3/config). I'm using a German keyboard and the default German 
keyboard layout. In the config I make use of Mod1 and Mod5 while on Jessie this 
worked fine in Stretch I'm unable to reference to the AltGr key in any way in 
the i3 config file.

 * What exactly did you do that was ineffective?
I checked the output of xmodmap -pm which is identical on both systems also the 
keycodes are the same (checked with xev). I verified the problem on another 
machine with a different (German) keyboard.

 * What was the outcome of this action?
I was not able to use the AltGr key in any way in i3

 * What outcome did you expect instead?
I would like to set the AltGr key as defautl modifier ($mod) or to use it in 
any 
other way in i3.


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

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

Versions of packages i3-wm depends on:
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libev41:4.22-1
ii  libglib2.0-0  2.50.3-1
ii  libpango-1.0-01.40.4-1
ii  libpangocairo-1.0-0   1.40.4-1
ii  libpcre3  2:8.39-2.1
ii  libstartup-notification0  0.12-4+b2
ii  libxcb-cursor00.1.1-3
ii  libxcb-icccm4 0.4.1-1
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.12-1
ii  libxcb-util0  0.3.8-3+b2
ii  libxcb-xinerama0  1.12-1
ii  libxcb-xkb1   1.12-1
ii  libxcb-xrm0   1.0-2
ii  libxcb1   1.12-1
ii  libxkbcommon-x11-00.7.1-1
ii  libxkbcommon0 0.7.1-1
ii  libyajl2  2.1.0-2+b3
pn  perl:any  
ii  x11-utils 7.7+3+b1

Versions of packages i3-wm recommends:
ii  fonts-dejavu-core   2.37-1
ii  libanyevent-i3-perl 0.16-1
ii  libjson-xs-perl 3.030-1
ii  rxvt-unicode [x-terminal-emulator]  9.22-1+b1
ii  xfonts-base 1:1.0.4+nmu1

i3-wm suggests no packages.

-- no debconf information

Bug#858716: [Pkg-xfce-devel] Bug#858716: xfce4-settings: xfce4-settings-manager do not expand vertically xfce4-notifyd-config dialog

[Yves-Alexis Perez]

On Sat, 2017-03-25 at 13:41 +0100, Antonio Cebrian wrote:
> xfce4-notifyd-config dialog is not expanded vertically when called from
> xfce4-settings-manager.
> 
> xfce4-notifyd-config dialog called alone is correctly expanded vertically so
> seem to be a xfce4-settings-manager problem.
> 
> Attached both cases dialog screenshoots.

Hi,

Which version of xfce4-notifyd do you have?

Regards,
-- 
Yves-Alexis

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