Bug#858896: Very fequent crashes

[Paolo Cavallini]

Hi,
unsure whether this is the same problem. I get very frequent crashes (>5
per day), at random interval, not associated with any particular action.
This is serious as I frequently lose the typed messages.
I'm available for further test as directed.
Thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis

Bug#859174: unblock: jmodeltest/2.1.10+dfsg-4

[Andreas Tille]

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

Please unblock package jmodeltest

Applied the patch from Ole Streicher to fix #859107

unblock jmodeltest/2.1.10+dfsg-4

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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)
diff -Nru jmodeltest-2.1.10+dfsg/debian/changelog jmodeltest-2.1.10+dfsg/debian/changelog
--- jmodeltest-2.1.10+dfsg/debian/changelog	2016-08-17 15:43:53.0 +0200
+++ jmodeltest-2.1.10+dfsg/debian/changelog	2017-03-31 08:24:53.0 +0200
@@ -1,3 +1,10 @@
+jmodeltest (2.1.10+dfsg-4) unstable; urgency=medium
+
+  [ Ole Streicher ]
+  * Remove BrowserLauncher dependency. Closes: #859107
+
+ -- Andreas Tille   Fri, 31 Mar 2017 08:24:53 +0200
+
 jmodeltest (2.1.10+dfsg-3) unstable; urgency=medium
 
   * Add missing command line arguments to wrapper
diff -Nru jmodeltest-2.1.10+dfsg/debian/patches/remove_BrowserLauncher_reference.patch jmodeltest-2.1.10+dfsg/debian/patches/remove_BrowserLauncher_reference.patch
--- jmodeltest-2.1.10+dfsg/debian/patches/remove_BrowserLauncher_reference.patch	1970-01-01 01:00:00.0 +0100
+++ jmodeltest-2.1.10+dfsg/debian/patches/remove_BrowserLauncher_reference.patch	2017-03-31 08:24:53.0 +0200
@@ -0,0 +1,53 @@
+Author: Ole Streicher 
+Description: Remove BrowserLauncher references.
+
+They were just a fallback if java.awt.Desktop.getDesktop() is not available.
+
+--- a/src/main/java/es/uvigo/darwin/jmodeltest/gui/FrameMain.java
 b/src/main/java/es/uvigo/darwin/jmodeltest/gui/FrameMain.java
+@@ -56,7 +56,6 @@
+ import javax.swing.text.DefaultCaret;
+ 
+ import pal.tree.Tree;
+-import edu.stanford.ejalbert.BrowserLauncher;
+ import es.uvigo.darwin.jmodeltest.ModelTest;
+ import es.uvigo.darwin.jmodeltest.ModelTestConfiguration;
+ import es.uvigo.darwin.jmodeltest.ModelTestService;
+@@ -1096,9 +1095,6 @@
+ Desktop desktop = Desktop.getDesktop();
+ URI wikiURI = new URI(ModelTest.WIKI);
+ desktop.browse(wikiURI);
+-			} else {
+-BrowserLauncher launcher = new BrowserLauncher();
+-launcher.openURLinBrowser(ModelTest.WIKI);
+ 			}
+ 		} catch (Exception f) {
+ 			JOptionPane.showMessageDialog(new JFrame(), f.getMessage(),
+@@ -1113,9 +1109,6 @@
+ Desktop desktop = Desktop.getDesktop();
+ URI groupURI = new URI(ModelTest.DISCUSSION_GROUP);
+ desktop.browse(groupURI);
+-			} else {
+-BrowserLauncher launcher = new BrowserLauncher();
+-launcher.openURLinBrowser(ModelTest.DISCUSSION_GROUP);
+ 			}
+ 		} catch (Exception f) {
+ 			JOptionPane.showMessageDialog(new JFrame(), f.getMessage(),
+@@ -1129,9 +1122,6 @@
+ Desktop desktop = Desktop.getDesktop();
+ URI jModelTestURI = new URI(ModelTest.URL);
+ desktop.browse(jModelTestURI);
+-			} else {
+-BrowserLauncher launcher = new BrowserLauncher();
+-launcher.openURLinBrowser(ModelTest.URL);
+ 			}
+ 		} catch (Exception f) {
+ 			JOptionPane.showMessageDialog(new JFrame(), f.getMessage(),
+@@ -1145,7 +1135,6 @@
+ 			credits += "Alignment conversion with ALTER by Daniel Glez-Pena et al.\n";
+ 			credits += "Phylogenetic trees management with PAL: Phylogenetic Analysis Library by A. Drummond and K. Strimmer\n";
+ 			credits += "Table utilities by Philip Milne\n";
+-			credits += "BrowserLauncher by Eric Albert and Jeff Chapman\n";
+ 
+ 			JOptionPane.showMessageDialog(new JFrame(), credits,
+ 	"jModelTest - CREDITS", JOptionPane.INFORMATION_MESSAGE,
diff -Nru jmodeltest-2.1.10+dfsg/debian/patches/series jmodeltest-2.1.10+dfsg/debian/patches/series
--- jmodeltest-2.1.10+dfsg/debian/patches/series	2016-08-17 15:43:53.0 +0200
+++ jmodeltest-2.1.10+dfsg/debian/patches/series	2017-03-31 08:24:53.0 +0200
@@ -2,3 +2,4 @@
 do_not_chmod_anything_in_usr_bin.patch
 adapt_config.patch
 replace_natbib_bst_by_plainnat.patch
+remove_BrowserLauncher_reference.patch

Bug#859072: Contribute extended dep8 testing

[Christian Ehrhardt]

On Fri, Mar 31, 2017 at 4:36 AM, Amos Jeffries  wrote:
>
>
[...]


> > > I think a few basic changes to the test logic should be made to avoid
> > > Internet access being required to send traffic to what are bogus URL
> > > domains anyway.
> > >
> >
> > It only goes to localhost/127.0.0.1 in what I sent, could you elaborate
> > where you still see Internet access being required?
>
> I was being fooled by the script documentation. By my reading it says
> what the test is supposed to be checking. If the documentation not
> matching what is actually being done that would still be an issue
> needing a fix, just different.
>
> Taking a closer look I dont actually see squidguard.conf being created
> anywhere, and squidguard is not listed as a test dependency. So maybe
> the SG test is not even happening ?
>

The SG test is only listed int he todo section of the comment.


> I dont see squid.conf being setup anywhere for the tests either. So
> maybe I am missing a major piece of the DEP8 process?
>

It uses no custom conf, in the default configuration after squid being
installed as a test dependency it is already running and can be used e.g.
on 127.0.0.1:3128.
That is what the tests are using.

> The only references I still see are in the the header which would be
> > removed in a cleanup anyway.
>
> FYI: From my perspective what I see with this bug repoort is that you
> submitted a patch requesting it be applied, with statements asserting
> that it was in successful active use as supporting evidence of it being
> useful and trustworthy. I am just auditing a patch proposed for merge.
> If that is not the final patch you want comitted, please clean it up
> before even applying - or make it very clear that further work is needed
> before applying. That is a good practice for submitting patches to any
> project, anywhere (sometimes even a mandatory requirement). You are
> risking a maintainer just taking the patch as-is and applying it without
> any of your intended final changes.
>

I really beg (all) your pardon here, I shouldn't have been so naive when
getting to this task.
I was asked to look into making the tests work on a CI infrastructure, once
that was done I thought it might be a good addition for Debian as well.
I really want to say sorry and state that I didn't want to submit a lot of
bad code, but - by forgetting to review all the bits and licenses around
that are part of it - I did just that.

I think I just did expect to much of the work that was done before me,
without knowing who/when exactly did it.
That was my fault and I'm thankful that you helped me spotting that.

No matter if eventually accepted in squid or carried/packaged otherwise I
hope that the next legally and code-wise cleaned up revision will help to
make things more clear.
But that needs a few days especially for the re-licensing.

 [...]


>
> > It would be nice If you could ack the approach of:
> > - clean .py files to be one file stripped to what is needed
> > - re-licence by original Authors as proper GPLv2+
>
> Well, the re-license is only relevant if the code is going to be applied
> to squid packaging. If it turns out fine to package separately, then the
> problem vanishes enitirely. So I would start with the packaging options.
>
> > - add license to d/t/squid
> > - keep tests themselve as-is (vs localhost)
>
> I am puzzled by the squidguard stuff, what is actually going on there
> (nothing? redirect to fake domains as documented?).


It's my fault to not clean up a lot of cruft that leave you puzzled at this
spot.


> But overall I am
> definitely in favour of at least having the same tests in Debian and
> Ubuntu to reduce the diff. That cannot happen fully in squid-3 due to
> the freeze, but what I have been working on with Robbie Basak is for the
> squid-4 packages to be more identical in features supported. So these
> tests become very relevant there.
>

Thank you, it was actually Robie who asked me to get the tests working
locally in a CI.
As you already said, with the Freeze we have some time.

I'll get back with a cleaned up and relicensed version but OTOH also start
discussions if packaging the QA libs would be an option to reduce
maintenance burden on all derived works.


> > If you would do so I'd start getting in touch with the original Authors
> and
> > once I have their ack start the cleanup/merge of the code.
>
> FY: I'm not the authoritative maintainer for Debian. Just assisting in
> the team. Luigi is quite busy these years, so if you need a formal Ack
> you might be waiting a long while.


I didn't need a formal ack at all, just a check to not be totally off the
wrong direction - what we discussed it more than good enough to go on.

Bug#854025: calendar-exchange-provider: Accepting Event does not work any more in 3.9

[mechtilde]

Package: calendar-exchange-provider
Version: 3.9.0-3
Followup-For: Bug #854025

Hello,

please provide the exact version of the package you use.

This bug tracker doesn't support backports issues.

Mechtilde



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages calendar-exchange-provider depends on:
ii  icedove   1:45.8.0-2
ii  iceowl-extension  1:45.8.0-2
ii  lightning [iceowl-extension]  1:45.8.0-2
ii  thunderbird [icedove] 1:45.8.0-2

calendar-exchange-provider recommends no packages.

calendar-exchange-provider suggests no packages.

-- no debconf information

Bug#857343: closed by Markus Koschany (Bug#857343: fixed in logback 1:1.1.9-2)

[Fabrice Dagorn]

Hi,
I  have made a quick and dirty POC for this issue.
This results in a remote code execution in the JVM that exposes a 
ServerSocketReceiver.


Unfortunately, logback 1:1.1.9-2 is still vulnerable, not 1.2.x.

The POC is available on demand.

Regards,
Fabrice Dagorn

Bug#818360: Any information required

[Tobias Lippert]

Dear maintainer,

do you have any feedback on the patch? Is it working for you?
Should I submit test pictures, so that you can reproduce the behavior?

Kind regards,
Tobias Lippert

Bug#859066: linux-image-*: recommend firmware-ath9k-htc

[Oleksij Rempel]

Hi,

Am 31.03.2017 um 07:15 schrieb Paul Fertser:

On Thu, Mar 30, 2017 at 10:04:24PM +0100, Ben Hutchings wrote:

On Thu, 2017-03-30 at 09:22 +0800, Paul Wise wrote:

Source: linux
Version: 4.10~rc6-1~exp1
Severity: wishlist
X-Debbugs-CC: open-ath9k-htc-firmw...@packages.debian.org

Now that open-ath9k-htc-firmware has been accepted into Debian
unstable, please add "Recommends: firmware-ath9k-htc" to the
metadata for the linux-image-* packages in Debian experimental.


Not many linux-image-* users have ath9k-htc hardware so I do not see
how this recommendation can make sense here.

The package should have provided appropriate AppStream metainformation
so Debian should be able to suggest installing it when the device is
plugged in for the first time.


As this firmware has gone through at least one ABI bump, I think we
need to plan for a future ABI bump.


So far the idea was to upload a package named firmware-ath9k-htc-1.5.0
after the next ABI bump. There's no reason why
firmware-ath9k-htc-1.5.0 shouldn't be able to co-exist on the same
system with e.g. firmware-ath9k-htc-1.6.0, as the user should be able
to choose different kernel versions on boot, and hence different
firmware versions will be appropriate.


Therefore:
- You should not name the files as simply '1.dev.0' versions, but by
  the implemented ABI version (as the driver expects by default).


The code that's currently packaged is definitely not 1.4.0 code, it
got some non-trivial changes (not affecting ABI though) after the
1.4.0 was released. So naming an intermediate version in any way other
than 1.dev.0 would only add to the confusion IMHO.

Probably it would make sense to have the minor number indicate a
subversion of same-ABI firmwares, but for some reasons the kernel
driver maintainers decided against that.

I hope Oleksij will correct me if I'm missing something here.


no. nothing is missing.
thank you

--
Regards,
Oleksij

Bug#859150: installation-guide: leaves many /tmp/tmp* files behind

[Holger Wansing]

Hi,

Am Fr. Mär. 31 00:24:41 2017 GMT+0200 schrieb Samuel Thibault:
> Hello Holger,
> 
> Cyril Brulebois, on ven. 31 mars 2017 00:09:34 +0200, wrote:
> > Maybe to ease hands-on debugging, dblatex is called with the -d flag,
> > which tells it to leave temporary files behind. This ends up filling
> > up dillon's /tmp (in addition to being rather bad style in the first
> > place…).
> 
> Is -d really useful now that we have seen the whole thing working?
> 
> Alternatively,
> 
> >  - or set TMPDIR to a subdirectory of $tempdir, which gets automatically
> >removed after a build.
> 
> would be fine to me, I'm just thinking that we perhaps just not need
> these files at all now.

There is probably a chance, that a new version of dblatex or
another tool breaks something some day.
So I would vote for the second variant.

Holger

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#859152: libsystemd-dev: Dependency error, lib-dev should not depend on systemd

[Martin Pitt]

Michael Biebl [2017-03-31  3:08 +0200]:
> Imo the only clean solution is to split out the tests into a separate
> package systemd-tests, which then can have a strictly versioned
> dependency on systemd (= ${binary:Version})

The systemd dependency is a good reason indeed, so I suppose let's do this at
last for buster.

> Martin wasn't overly happy with adding yet another binary, but another
> benefit would be that the 13M of test executables wouldn't be pulled in
> when installing libsystemd-dev.

For stretch I think ignoring (-X) the tests dir is acceptable, do you agree?

Martin


signature.asc
Description: PGP signature

Bug#859173: ninja-build is unuseable for package cross compilation

[Helmut Grohne]

Package: ninja-build
Severity: wishlist

Michael Biebl (Cced) asked me to look into cross compilation with meson.
meson stands on the shoulders of ninja-build, so looking into
ninja-build is the obvious first step.

ninja-build currently is an `Architecture: any` package which is
implicitly marked `Multi-Arch: no`. Resolution of `Build-Depends`
dictates that dependencies are to be considered for the host
architecture unless an annotation (`Multi-Arch` or architecture
qualifier) says something else. As it happens, a simple `Build-Depends:
ninja-build` will presently end up with the host architecture version.
During cross builds, host architecture code is usually not executable.
Trying to run `ninja-build` will thus produce an error message like the
following.

/usr/bin/ninja-build: cannot execute binary file: Exec format error

Thus `ninja-build` is presently unusable for package[1] cross
compilation.

Now we have a problem and no obvious solution. Let me give some possible
solutions, none of which is readily applicable.

1. Mark ninja-build `Multi-Arch: foreign`. This will result in
   `ninja-build` being picked up for the build architecture and will
   thus be runnable. Other build systems like `cmake` or `make` were
   also marked `Multi-Arch: foreign`, but the devil is in the detail. We
   later noticed that `make` actually isn't fully `foreign`, because it
   considers architecture dependent paths (i.e. its behaviour differs if
   installed for a different architecture). Thus `make` now is
   `Multi-Arch: allowed` to signify that some uses are
   architecture-independent, but not all. An analysis whether
   `ninja-build` can be reasonably marked `Multi-Arch: foreign` (i.e.
   whether its interfaces vary per architecture) is presently missing.

2. As hinted in the `make` case, it could be marked `Multi-Arch:
   allowed`. This option should be considered as a last resort though,
   because it requires updating all reverse dependencies annotating
   their `ninja-build` dependency with `:any` (and checking that this is
   correct in each case), i.e. a lot of work. For `make`, this is not
   much of a problem, because `make` is pulled in by `build-essential`
   and we assume that most uses of `make` are indeed
   architecture-independent. Those rare exceptions need to gain explicit
   `Build-Depends: make` without any qualifier.

3. Not changing `ninja-build` also is an option if all relevant reverse
   dependencies annotate their `ninja-build` dependency with `:native`.
   This is only allowed for `Build-Depends`, so the `meson` binary
   package will have no way to emit a correct dependency. In a sense,
   this is a non-option.

Normally, I only report such issues with a patch. In this case, Michael
asked me to file it right away as a discussion bug to avoid any
unnecessary delay. If someone performs the necessary analysis and Ccs
debian-cr...@lists.debian.org, I bet you'll get instant feedback and
review or just help with performing it.

Hope this helps

Helmut

[1] You can still install `ninja-build` for the build architecture and
most likely have it just work. This bug is mainly about Debian's
dependency resolution.

Bug#859172: telegram-desktop: Segmentfault due to lack of libappindicator3-1 library dep

[Boyuan Yang]

Package: telegram-desktop
Version: 1.0.14-1
Severity: important
Tags: patch upstream

Telegram-desktop build-depends on libappindicator-dev, however build system did
not deduce its corresponding library dependency (libappindicator3-1).

As a result, when telegram-desktop was started on GTK-based DE, it will crash.

% telegram-desktop

(telegram-desktop:4272): GLib-GObject-WARNING **: cannot register existing type
'GdkDisplayManager'

(telegram-desktop:4272): GLib-CRITICAL **: g_once_init_leave: assertion 'result
!= 0' failed

(telegram-desktop:4272): GLib-GObject-CRITICAL **: g_object_new: assertion
'G_TYPE_IS_OBJECT (object_type)' failed

(telegram-desktop:4272): GLib-GObject-WARNING **: invalid (NULL) pointer
instance

(telegram-desktop:4272): GLib-GObject-CRITICAL **: g_signal_connect_data:
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(telegram-desktop:4272): GLib-GObject-WARNING **: invalid (NULL) pointer
instance

(telegram-desktop:4272): GLib-GObject-CRITICAL **: g_signal_connect_data:
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(telegram-desktop:4272): GLib-GObject-WARNING **: cannot register existing type
'GdkDisplay'

(telegram-desktop:4272): GLib-CRITICAL **: g_once_init_leave: assertion 'result
!= 0' failed

(telegram-desktop:4272): GLib-GObject-CRITICAL **: g_type_register_static:
assertion 'parent_type > 0' failed

(telegram-desktop:4272): GLib-CRITICAL **: g_once_init_leave: assertion 'result
!= 0' failed

(telegram-desktop:4272): GLib-GObject-CRITICAL **: g_object_new: assertion
'G_TYPE_IS_OBJECT (object_type)' failed
[1]4272 segmentation fault  telegram-desktop

Possibly related GitHub issue (on Arch Linux):
https://github.com/archlinuxcn/repo/issues/361

I think a workaround patch can be applied for now, but further investigation is
needed.

Thanks!



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

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

Versions of packages telegram-desktop depends on:
ii  libavcodec57 7:3.2.4-1
ii  libavformat577:3.2.4-1
ii  libavutil55  7:3.2.4-1
ii  libc62.24-9
ii  libgcc1  1:6.3.0-11
ii  libglib2.0-0 2.50.3-2
ii  libminizip1  1.1-8+b1
ii  libopenal1   1:1.17.2-4+b2
ii  libqt5core5a [qtbase-abi-5-7-1]  5.7.1+dfsg-3+b1
ii  libqt5gui5   5.7.1+dfsg-3+b1
ii  libqt5network5   5.7.1+dfsg-3+b1
ii  libqt5widgets5   5.7.1+dfsg-3+b1
ii  libssl1.0.2  1.0.2k-1
ii  libstdc++6   6.3.0-11
ii  libswresample2   7:3.2.4-1
ii  libswscale4  7:3.2.4-1
ii  libx11-6 2:1.6.4-3
ii  qt5-image-formats-plugins5.7.1~20161021-2
ii  zlib1g   1:1.2.8.dfsg-5

telegram-desktop recommends no packages.

telegram-desktop suggests no packages.

-- no debconf information

Bug#859066: linux-image-*: recommend firmware-ath9k-htc

[Paul Fertser]

On Thu, Mar 30, 2017 at 10:04:24PM +0100, Ben Hutchings wrote:
> On Thu, 2017-03-30 at 09:22 +0800, Paul Wise wrote:
> > Source: linux
> > Version: 4.10~rc6-1~exp1
> > Severity: wishlist
> > X-Debbugs-CC: open-ath9k-htc-firmw...@packages.debian.org
> > 
> > Now that open-ath9k-htc-firmware has been accepted into Debian
> > unstable, please add "Recommends: firmware-ath9k-htc" to the
> > metadata for the linux-image-* packages in Debian experimental.

Not many linux-image-* users have ath9k-htc hardware so I do not see
how this recommendation can make sense here.

The package should have provided appropriate AppStream metainformation
so Debian should be able to suggest installing it when the device is
plugged in for the first time.

> As this firmware has gone through at least one ABI bump, I think we
> need to plan for a future ABI bump.

So far the idea was to upload a package named firmware-ath9k-htc-1.5.0
after the next ABI bump. There's no reason why
firmware-ath9k-htc-1.5.0 shouldn't be able to co-exist on the same
system with e.g. firmware-ath9k-htc-1.6.0, as the user should be able
to choose different kernel versions on boot, and hence different
firmware versions will be appropriate.

> Therefore:
> - You should not name the files as simply '1.dev.0' versions, but by
>   the implemented ABI version (as the driver expects by default).

The code that's currently packaged is definitely not 1.4.0 code, it
got some non-trivial changes (not affecting ABI though) after the
1.4.0 was released. So naming an intermediate version in any way other
than 1.dev.0 would only add to the confusion IMHO.

Probably it would make sense to have the minor number indicate a
subversion of same-ABI firmwares, but for some reasons the kernel
driver maintainers decided against that.

I hope Oleksij will correct me if I'm missing something here.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#859159: pidgin: CVE-2017-2640

[Salvatore Bonaccorso]

Package: pidgin
Version: 2.10.11-1
X-Debbugs-CC: t...@security.debian.org 
secure-testing-t...@lists.alioth.debian.org
Severity: grave
Tags: security
Control: fixed -1 2.11.0-0+deb8u2

Hi,

the following vulnerability was published for pidgin.
Filling this with RC severity, since it's although fixed in sid and
in stable, and means a regression while updating to stretch.

CVE-2017-2640[0]:
Out-of-bounds write when stripping xml

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-2640
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2640

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#859158: python3-aiohttp: Please package 2.0 for experimental

[Matthias Urlichs]

Package: python3-aiohttp
Version: 1.1.5-1
Severity: wishlist

2.0 has been out for long enough ;-)

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (550, 
'experimental'), (550, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-aiohttp depends on:
ii  libc6  2.24-7
ii  python33.5.3-1
ii  python3-async-timeout  1.1.0-1
ii  python3-chardet2.3.0-1
ii  python3-multidict  2.1.2-1
ii  python3-yarl   0.7.0-1
pn  python3:any

python3-aiohttp recommends no packages.

python3-aiohttp suggests no packages.

-- no debconf information

Bug#859072: Contribute extended dep8 testing

[Amos Jeffries]

FYI: I am just one of a team in Debian, not 'the' maintainer, Luigi is
that. So I am just auditing the patch as presented for inclusion to Debian.


On Thu, 30 Mar 2017 14:26:59 +0200 Christian Ehrhardt wrote:
> On Thu, Mar 30, 2017 at 1:28 PM, Amos Jeffries wrote:
>
> > Thank you.
> >
> > Biggest issue I see is a bunch of License problems - which will affect
> > Ubuntu inclusion in similar ways IMHO:
> >
>
> I agree and thank you as nobody ever spotted (or cared about) that.
> But I know the Authors and can ask about a proper relicensing of those bits.
>
> TL;DR summary of the license todo:
>  * debian/tests/test-squid.py is GPLv2 should be proper GPLv2+
>  * debian/tests/testlib.py bad copy of GPLv2+ should be proper GPLv2+
>- edit hints that authors actually wanted it to be the incompatible?
> * debian/tests/testlib_httpd.py is GPLv3 should be GPLv2+
> * debian/tests/squid add an explicit GPLv2+ License
>
>
> > [...]
> > would make the .deb package and everything inside it a GPLv3-only
> > offering. Even assuming tat is okay, a v3-only .deb makes the above
> > v2-only script issues worse.
> >
>
> I'm not a lawyer, but I think in the python + test case this is even more
> special.
> As there is no classic linking involved, but more important the tests are
> only part of the source, but not part of the .deb being produced.
> Never the less I clearly want to sort that out - thanks for bringing it up!

I think the fact the Debian/Ubuntu ship source tarballs makes that an
issue. I wrote .deb but meant the source package (.debs?). IANAL myself,
just have enough experience to spot collisions. If the technical
packaging rearrangement and authors does not resolve that cleanly it may
be something to pass to the Debian legal team to suggest a solution.

> - this appears to be a large and generic python library. Do we really
> > need to embed it anyway? can it not be pulled from some other package or
> > provided by the QA infrastructure itself?
> >
>
> It is part of a much bigger testsuite, therefore the bigger libraries.
>
> A package would only make sense if it would be packaged but it is not, the
> right way would be to pull from their git or such.
> But then that gets us back into the connectivity issues from DebCI/Ubuntu
> Test infrastructure.
>
> The benefit of taking the libs as-is was to be able to later on update them
> by copying in the newer versions / cherry-picking changes.

IME the opposite is actually true. Synchronising N copies of some
generic code copy-n-pasted across an unknown number of packages is a
major PITA to work with variations - even using VCS tools to do it.
Having one library package with easily identified dependencies that can
be coordinated with API changes is far better. In the short term I find
it better to propose and wait a while to seeif the CI can be fixed.
Debian is in freeze now so no urgency on updating squid yet.

> Changes are needed over time as Distributions change every so slightly.
>
> Yet I agree that it might need only a small subset, would you be ok with me
> trimming that code down to the point that it will be only the test-squid.py
> with just the functions needed moved into it and a proper relicense from
> the original Authors?

Personally, yes. But as mentioned I'm fairly new to Debian processes.

> > I think a few basic changes to the test logic should be made to avoid
> > Internet access being required to send traffic to what are bogus URL
> > domains anyway.
> >
>
> It only goes to localhost/127.0.0.1 in what I sent, could you elaborate
> where you still see Internet access being required?

I was being fooled by the script documentation. By my reading it says
what the test is supposed to be checking. If the documentation not
matching what is actually being done that would still be an issue
needing a fix, just different.

Taking a closer look I dont actually see squidguard.conf being created
anywhere, and squidguard is not listed as a test dependency. So maybe
the SG test is not even happening ?

I dont see squid.conf being setup anywhere for the tests either. So
maybe I am missing a major piece of the DEP8 process?


> The only references I still see are in the the header which would be
> removed in a cleanup anyway.

FYI: From my perspective what I see with this bug repoort is that you
submitted a patch requesting it be applied, with statements asserting
that it was in successful active use as supporting evidence of it being
useful and trustworthy. I am just auditing a patch proposed for merge.
If that is not the final patch you want comitted, please clean it up
before even applying - or make it very clear that further work is needed
before applying. That is a good practice for submitting patches to any
project, anywhere (sometimes even a mandatory requirement). You are
risking a maintainer just taking the patch as-is and applying it without
any of your intended final changes.


> Those headers refer mostly to its use in the wider QA suite and in the
> 

Bug#858671: bugs.debian.org: Handle "source" in {split,join}_status_fields

[Don Armstrong]

On Fri, 24 Mar 2017, James McCoy wrote:
> When I attempted to tag 845066 pending, it failed in check_limit() since
> "source" had not been split into a list.  I'm not sure if there should
> be something preventing things from getting in this state, but the
> attached patch should at least allow limits to be applied.

The actual issue is that source is getting the split version when
get_bug_status is called, instead of the unsplit version.

I've tweaked that, which should fix this issue too. [In
master@7c98c4f499ca].

[I also found another issue while debugging this which I've fixed.]


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

2: There is no out. There is only in.
  -- "The Prisoner (2009 Miniseries)"

Bug#859155: openafs-modules-dkms: Please support kernel 4.10

[Carl Suster]

Package: openafs-modules-dkms
Version: 1.6.20-2
Severity: wishlist
Tags: fixed-upstream patch
Forwarded: 
http://git.openafs.org/?p=openafs.git;a=commitdiff;h=789319bf0f2b26ad67995f8cbe88cee87a1bbdc0;hp=961cee00b8f5c302de5f66beb81caa33242c7971

The openafs module fails to build on kernel 4.10, and the fix upstream (related 
to have_submounts) is in 789319bf0f2b26ad67995f8cbe88cee87a1bbdc0.

Cheers,
Carl

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

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

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.3-3
ii  libc6-dev  2.24-9
pn  perl:any   

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.6.20-2

openafs-modules-dkms suggests no packages.

-- no debconf information

Bug#859043: (no subject)

[Michael Lustfield]

s/saintfish/gogits/ -- actively maintained fork

Bug#859153: openvpn: DNS leaks: /etc/openvpn/update-resolv-conf fails without openresolv installed.

[demure]

Package: openvpn
Version: 2.4.0-4
Severity: important

Dear Maintainer,

In my use of openvpn on debian sid I have found that the following 
settings only work after openresolv is installed, leading to DNS 
leaking.:

#/etc/openvpn/client/client.conf
dhcp-option DNS 8.8.8.8
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

As such, I would suggest that openresolv should be either a dependency, 
or as least listed as a recommends.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (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 openvpn depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  init-system-helpers1.47
ii  iproute2   4.9.0-1
ii  libc6  2.24-9
ii  liblz4-1   0.0~r131-2+b1
ii  liblzo2-2  2.08-1.2+b2
ii  libpam0g   1.1.8-3.5
ii  libpkcs11-helper1  1.21-1
ii  libssl1.0.21.0.2k-1
ii  libsystemd0232-22
ii  lsb-base   9.20161125

Versions of packages openvpn recommends:
ii  easy-rsa  2.2.2-2

Versions of packages openvpn suggests:
ii  openresolv [resolvconf]  3.8.0-1
ii  openssl  1.1.0e-1

-- debconf information:
  openvpn/create_tun: false

Bug#859152: libsystemd-dev: Dependency error, lib-dev should not depend on systemd

[Michael Biebl]

Am 31.03.2017 um 01:16 schrieb Arthur Gautier:
> Package: libsystemd-dev
> Version: 232-22
> Severity: normal
> 
> Dear maintainer,
> 
> One should be able to install libsystemd and libsystemd-dev without having
> systemd.
> 
> When using a build machine with sysvinit instead of systemd, we can't build
> packages depending on libsystemd-dev without installing first systemd.

That shouldn't be a huge issue,fwiw. systemd itself doesn't change your
init system.

> libsystemd-dev is only headers for the library and should not depend
> on the binary itself. I believe this is an error. Would it be possible
> to avoid such dependency?
> 
> I believe it to be caused by files shipped with libsystemd-dev in the
> /usr/lib/x86_64-linux-gnu/systemd/tests/ directory, some of them depends on
> libsystemd-shared.so which is shipped by systemd package.

Your analysis seems correct.

Imo the only clean solution is to split out the tests into a separate
package systemd-tests, which then can have a strictly versioned
dependency on systemd (= ${binary:Version})

Martin wasn't overly happy with adding yet another binary, but another
benefit would be that the 13M of test executables wouldn't be pulled in
when installing libsystemd-dev.

Given that we are in freeze, this probably something for buster though.

Regards,
Michael




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



signature.asc
Description: OpenPGP digital signature

Bug#797613: libosl: diff for NMU version 0.8.0-1.1

[Mattia Rizzolo]

Control: tag -1 patch
Control: tag -1 pending

Dear maintainer,

I've prepared an NMU for libosl (versioned as 0.8.0-1.1). The diff
is attached to this message.

I've directly uploaded it, it's going through NEW (and I intend to ask
for fast-tracking, so the only rdep gets rebuilt right away, given it's
currently sitting in DEFERRED).

Regards.

-- 
regards,
Mattia Rizzolo

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

 changelog |   26 ++
 control   |   12 +++-
 libosl1.install   |1 -
 libosl1v5.install |1 +
 4 files changed, 34 insertions(+), 6 deletions(-)

diff -Nru libosl-0.8.0/debian/changelog libosl-0.8.0/debian/changelog
--- libosl-0.8.0/debian/changelog	2017-01-01 15:13:21.0 +0100
+++ libosl-0.8.0/debian/changelog	2017-03-31 02:28:56.0 +0200
@@ -1,3 +1,13 @@
+libosl (0.8.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Import again previously unincorporated NMUs 0.6.0-3.{2,3,4}.
+  * Complete (again) the library package rename after GCC5 ABI break.
+Closes: #797613 (again)
+  * Use HTTPS in the Vcs-* fields.
+
+ -- Mattia Rizzolo   Fri, 31 Mar 2017 02:28:56 +0200
+
 libosl (0.8.0-1) unstable; urgency=medium
 
   * New upstream release (OSL r4566).
@@ -36,6 +46,22 @@
 
  -- Daigo Moriwaki   Mon, 05 Dec 2016 22:06:36 +0900
 
+libosl (0.6.0-3.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with gcc-6, multiple issues. More remain.
+
+ -- Dimitri John Ledkov   Wed, 17 Aug 2016 14:05:11 +0100
+
+libosl (0.6.0-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Steve Langasek ]
+  * Rename library packages for g++5 ABI transition. (Closes: #797613)
+
+ -- Sebastian Ramacher   Mon, 19 Oct 2015 23:43:57 +0200
+
 libosl (0.6.0-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libosl-0.8.0/debian/control libosl-0.8.0/debian/control
--- libosl-0.8.0/debian/control	2017-01-01 15:13:21.0 +0100
+++ libosl-0.8.0/debian/control	2017-03-31 02:28:56.0 +0200
@@ -5,13 +5,15 @@
 Build-Depends: dpkg-dev (>= 1.16.1~), debhelper (>= 10.2.1), doxygen, quilt, cmake, libcppunit-dev, libboost-all-dev
 Standards-Version: 3.9.8
 Homepage: http://gps.tanaka.ecc.u-tokyo.ac.jp/gpsshogi/pukiwiki.php
-Vcs-Browser: http://git.debian.org/?p=collab-maint/libosl.git;a=summary
-Vcs-Git: git://git.debian.org/git/collab-maint/libosl.git
+Vcs-Git: https://anonscm.debian.org/git/collab-maint/libosl.git
+Vcs-Browser: https://anonscm.debian.org/git/collab-maint/libosl.git
 
-Package: libosl1
+Package: libosl1v5
 Architecture: i386 amd64
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: libosl-doc
+Conflicts: libosl1
+Replaces: libosl1
 Description: library for Shogi playing programs
  OpenShogiLib (OSL) provides following features of Shogi playing programs,
  especially for Shogi programming study. Shogi is a Japanese two-player board
@@ -31,7 +33,7 @@
 Package: libosl-dev
 Section: libdevel
 Architecture: i386 amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, libosl1 (= ${binary:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, libosl1v5 (= ${binary:Version})
 Description: library for Shogi playing programs
  OpenShogiLib (OSL) provides following features of Shogi playing programs,
  especially for Shogi programming study. Shogi is a Japanese two-player board
@@ -50,7 +52,7 @@
 Package: libosl-doc
 Section: doc
 Architecture: all
-Suggests: libosl1
+Suggests: libosl1v5
 Depends: libjs-jquery, ${misc:Depends}
 Description: library for Shogi playing programs
  OpenShogiLib (OSL) provides following features of Shogi playing programs,
diff -Nru libosl-0.8.0/debian/libosl1.install libosl-0.8.0/debian/libosl1.install
--- libosl-0.8.0/debian/libosl1.install	2017-01-01 15:13:21.0 +0100
+++ libosl-0.8.0/debian/libosl1.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-/usr/lib/*/libosl.so.*
diff -Nru libosl-0.8.0/debian/libosl1v5.install libosl-0.8.0/debian/libosl1v5.install
--- libosl-0.8.0/debian/libosl1v5.install	1970-01-01 01:00:00.0 +0100
+++ libosl-0.8.0/debian/libosl1v5.install	2017-03-31 02:28:56.0 +0200
@@ -0,0 +1 @@
+/usr/lib/*/libosl.so.*


signature.asc
Description: PGP signature

Bug#858676: /dev/console is not unmounted in chroot

[Slávek Banko]

Hi, I have some details on this issue. It appears that mounted folder 
remains in the chroot /dev/console. This is a regression - the previous 
version 0.228.5~bpo8+1 worked correctly.

I consider this bug as serious.

Cheers
-- 
Slávek

Bug#859101: [Pkg-samba-maint] Bug#859101: regression: net: security update makes `net ads join` freeze when run a second time

[Paul Wise]

On Thu, 2017-03-30 at 22:36 +0200, Mathieu Parent wrote:

> Can you try this patch:
> https://git.samba.org/?p=samba.git;a=commitdiff;h=38beef2ff63664d7d5805f1032bb9f69d0b965d7

Thanks! This patch fixes the issue, my $work would appreciate it if you
could fold this into the next update to Debian jessie.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#736887: trickle: diff for NMU version 1.07-10.1

[Mattia Rizzolo]

Control: tags 736887 + pending

Dear maintainer,

I've prepared an NMU for trickle (versioned as 1.07-10.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
regards,
Mattia Rizzolo

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

 changelog |8 
 control   |2 +-
 rules |2 ++
 3 files changed, 11 insertions(+), 1 deletion(-)

diff -u trickle-1.07/debian/control trickle-1.07/debian/control
--- trickle-1.07/debian/control
+++ trickle-1.07/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Robert Lemmen 
 Build-Depends: debhelper (>= 7.0.0), libevent-dev (>= 0.7b), autoconf,
- libbsd-dev, autotools-dev
+ libbsd-dev, dh-autoreconf
 Standards-Version: 3.9.4
 
 Package: trickle
diff -u trickle-1.07/debian/changelog trickle-1.07/debian/changelog
--- trickle-1.07/debian/changelog
+++ trickle-1.07/debian/changelog
@@ -1,3 +1,11 @@
+trickle (1.07-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh-autoreconf to fix FTBFS on ppc64el and update config.{sub, guess}
+for new arches.  Closes: #736887
+
+ -- Mattia Rizzolo   Fri, 31 Mar 2017 01:41:27 +0200
+
 trickle (1.07-10) unstable; urgency=low
 
   * Enable hardning flags during build
diff -u trickle-1.07/debian/rules trickle-1.07/debian/rules
--- trickle-1.07/debian/rules
+++ trickle-1.07/debian/rules
@@ -7,6 +7,7 @@
 
 config.status: configure
 	dh_testdir
+	dh_autoreconf
 	CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" \
 LDFLAGS="$(LDFLAGS)" ./configure --prefix=/usr \
 --mandir=/usr/share/man --sysconfdir=/etc --with-pic
@@ -27,6 +28,7 @@
 	dh_testroot
 	rm -f build-arch-stamp 
 	[ ! -f Makefile ] || $(MAKE) distclean
+	dh_autoreconf_clean
 	dh_clean
 
 install: build


signature.asc
Description: PGP signature

Bug#802211: systemd: rescue.service fails if root password is not set, needs sulogin --force

[Nathan Dorfman]

On Fri, Mar 31, 2017 at 12:51:08AM +0200, Michael Biebl wrote:
> Maybe I'm overly paranoid here, but maybe that helps to better
> understand my concerns.

No, your concerns sound reasonable to me, and I agree that demanding
a username from group sudo, along with its password sounds like it
could be even better.

However, I think it might not be necessary. Simply warn the user what
is going to happen if they don't set the root password at install
time: rescue boot will be left unprotected.

Some users might prefer that behavior anyway -- as someone pointed
out, the rescue shell would still work even if passwd/shadow are lost.
Users that are setting up BIOS and grub passwords can be expected to
set the root password as well, IMHO. Obviously, the installer should
make it unmistakably clear.

If that's not acceptable, I hope you'll agree that the installer
should just force you to set a root password. It's not reasonable for
it to quietly leave you with a rescue shell that won't work at all.

However, I honestly think the more lenient solution is better: an
empty root password usable only at rescue boot seems preferable to a
very weak password that could be allowed elsewhere. That said, I just
noticed that we seem to have PermitRootLogin prohibit-password in
sshd_config by default now, so this might be a minor or even moot
point.

-nd.

Bug#859151: thunderbird: Please backport sparc64 support fixes

[John Paul Adrian Glaubitz]

Source: icedove
Version: 1:45.8.0-3
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

Attached is a tested patch with the cherry-picked changes from firefox
upstream to fix the build of xulrunner and thus Thunderbird on sparc64.

Since we are planning to make sparc64 a release architecture after
Stretch has been released, it would be nice to have this patch merged
into Debian's thunderbird package.

The corresponding upstream bug report is 1275204 [1].

Thanks,
Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1275204

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Add sparc64 support to Thunderbird
 This is a squashed commit of the following patches cherry-picked
 from Firefox upstream to add sparc64 support:
  - a73e3b7ea901f648ae7e1c4b41d77c45786bff0b
Bug 1275204 - protobuf: Sync sparc64 pre-processor defines from upstream. 
r=fitzgen
  - 9fd9034ad9de26cc0cb0c70f9307d501823a79d9
Bug 1275204 - media:webrtc: Use better pre-processor defines for sparc64. 
r=jesup
  - 4b76f574940ae88731c1b8774399c2dfaf89618b
Bug 1275204 - mozjemalloc: Use the JS arm64 allocator on Linux/sparc64. 
r=glandium
  - dbf939ff1dadd1c6672b9870034bdb04aaa63b30
Bug 1275204 - mozjemalloc: Use better pre-processor defines for sparc64. 
r=glandium
  - 87f559a4d89164c402d0f22b1ff7b8a686ececfd
Bug 1275204 - js: Use the arm64 allocator on Linux/sparc64. r=ehoogeveen
  - ef8c81a9852551bb4428850687b41f7fb6137a45
Bug 1275204 - js: Use better pre-processor defines for sparc64. r=glandium
  - 120b9c868b2155c29eb5d18603a04f21620328af
Bug 1275204 - ipc:chromium: Use better pre-processor defines for sparc64. 
r=froydnj
  - fde7f4bca8db23193ba04459aef21875f4602aa9
Bug 1275204 - Use OpenBSD/sparc64 xptcall stubs on Linux/sparc64. r=froydnj
Author: John Paul Adrian Glaubitz 
Last-Update: 2017-03-30

Index: icedove-45.8.0/mozilla/ipc/chromium/src/build/build_config.h
===
--- icedove-45.8.0.orig/mozilla/ipc/chromium/src/build/build_config.h
+++ icedove-45.8.0/mozilla/ipc/chromium/src/build/build_config.h
@@ -82,7 +82,7 @@
 #elif defined(__ppc__) || defined(__powerpc__)
 #define ARCH_CPU_PPC 1
 #define ARCH_CPU_32_BITS 1
-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)
 #define ARCH_CPU_SPARC 1
 #define ARCH_CPU_64_BITS 1
 #elif defined(__sparc__)
Index: icedove-45.8.0/mozilla/js/src/gc/Memory.cpp
===
--- icedove-45.8.0.orig/mozilla/js/src/gc/Memory.cpp
+++ icedove-45.8.0/mozilla/js/src/gc/Memory.cpp
@@ -438,8 +438,8 @@ static inline void*
 MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
 int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
-MOZ_ASSERT(0x8000ULL & (uintptr_t(desired) + length - 1) == 0);
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && 
(defined(__NetBSD__) || defined(__linux__)))
+MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) == 
0);
 #endif
 void* region = mmap(desired, length, prot, flags, fd, offset);
 if (region == MAP_FAILED)
@@ -461,7 +461,7 @@ static inline void*
 MapMemory(size_t length, int prot = PROT_READ | PROT_WRITE,
   int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 0)
 {
-#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__))
+#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && 
defined(__NetBSD__))
 /*
  * The JS engine assumes that all allocated pointers have their high 17 
bits clear,
  * which ia64's mmap doesn't support directly. However, we can emulate it 
by passing
@@ -488,6 +488,41 @@ MapMemory(size_t length, int prot = PROT
 return nullptr;
 }
 return region;
+#elif defined(__sparc__) && defined(__arch64__) && defined(__linux__)
+   /*
+* There might be similar virtual address issue on arm64 which depends on
+* hardware and kernel configurations. But the work around is slightly
+* different due to the different mmap behavior.
+*
+* TODO: Merge with the above code block if this implementation works for
+* ia64 and sparc64.
+*/
+const uintptr_t start = UINT64_C(0x0700);
+const uintptr_t end   = UINT64_C(0x8000);
+const uintptr_t step  = ChunkSize;
+   /*
+* Optimization options if there are too many retries in practice:
+* 1. Examine /proc/self/maps to find an available address. This file is
+*not always available, however. In addition, even if we examine
+*/proc/self/maps, we may still need to retry several times due to
+*r

Bug#859152: libsystemd-dev: Dependency error, lib-dev should not depend on systemd

[Arthur Gautier]

Package: libsystemd-dev
Version: 232-22
Severity: normal

Dear maintainer,

One should be able to install libsystemd and libsystemd-dev without having
systemd.

When using a build machine with sysvinit instead of systemd, we can't build
packages depending on libsystemd-dev without installing first systemd.

libsystemd-dev is only headers for the library and should not depend
on the binary itself. I believe this is an error. Would it be possible
to avoid such dependency?

I believe it to be caused by files shipped with libsystemd-dev in the
/usr/lib/x86_64-linux-gnu/systemd/tests/ directory, some of them depends on
libsystemd-shared.so which is shipped by systemd package.

A patch like:
diff --git a/debian/rules b/debian/rules
index aabe69e13401e..f1b76684cc765 100755
--- a/debian/rules
+++ b/debian/rules
@@ -324,6 +324,7 @@ override_dh_installinit:
 # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753589
 override_dh_shlibdeps:
dh_shlibdeps -psystemd -- -dPre-Depends -edebian/systemd/bin/systemctl 
-dDepends
+   dh_shlibdeps -plibsystemd-dev -Xtests
dh_shlibdeps --remaining-packages -Lsystemd
 
 override_dh_makeshlibs:

Would ignore the directory from being scanned by dh_shlibdeps.
One would not be able to launch tests without systemd, I'm
not sure this is okay or not.

Let me know what you think,

Thank you,

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

Kernel: Linux 4.10.0 (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: sysvinit (via /sbin/init)

Bug#848345: gpsshogi: diff for NMU version 0.7.0-1.1

[Mattia Rizzolo]

Control: tags 848345 + patch
Control: tags 848345 + pending

Dear maintainer,

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

Also, all of this is cause by you not incorporating the previous NMU.
And the git repository was quite a mess, with upstream/* and debian/*
tags not in the branch, pristine-tar not committed/pushed, and some
changes done in the tagged git commit not actually uploaded.
I tried to make some order out of it, and if I disrupted something of
yours I'm sorry, but then please try to be more ordered and pay some
more attention to your packages.

Regards.

-- 
regards,
Mattia Rizzolo

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

 changelog|   23 +++
 control  |8 
 patches/0004-Specify-QT_SELECT-qt5.patch |   17 +
 patches/series   |1 +
 rules|2 +-
 5 files changed, 46 insertions(+), 5 deletions(-)

diff -Nru gpsshogi-0.7.0/debian/changelog gpsshogi-0.7.0/debian/changelog
--- gpsshogi-0.7.0/debian/changelog	2016-12-04 02:15:52.0 +0100
+++ gpsshogi-0.7.0/debian/changelog	2017-03-31 00:57:08.0 +0200
@@ -1,3 +1,13 @@
+gpsshogi (0.7.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Import back again un-incorporated NMU  0.6.0-3+nmu2.  Closes: 848345
+  * Use HTTPS in Vcs-* headers.
+  * Apply change in git reposiotry from Daigo Moriwaki: specify QT_SELECT=qt5
+and add a patch to build with qt5.
+
+ -- Mattia Rizzolo   Fri, 31 Mar 2017 00:57:08 +0200
+
 gpsshogi (0.7.0-1) unstable; urgency=medium
 
   * New upstream release (r3043).
@@ -12,6 +22,19 @@
 
  -- Daigo Moriwaki   Sun, 04 Dec 2016 10:15:52 +0900
 
+gpsshogi (0.6.0-3+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Steve Langasek ]
+  * Remove hard-coded dependency on libosl1. (Closes: #795237)
+
+  [ Bas Couwenberg ]
+  * Update build dependencies for GSL 2, change libgsl0-dev to libgsl-dev.
+(Closes: #807204)
+
+ -- Sebastian Ramacher   Sat, 02 Jan 2016 17:16:11 +0100
+
 gpsshogi (0.6.0-3+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gpsshogi-0.7.0/debian/control gpsshogi-0.7.0/debian/control
--- gpsshogi-0.7.0/debian/control	2016-12-04 02:15:52.0 +0100
+++ gpsshogi-0.7.0/debian/control	2017-03-31 00:56:33.0 +0200
@@ -2,15 +2,15 @@
 Section: games
 Priority: optional
 Maintainer: Daigo Moriwaki 
-Build-Depends: debhelper (>= 9), cdbs, quilt, dpkg-dev (>= 1.16.1~), libosl-dev (>= 0.7.0-2), libboost-all-dev, libgoogle-perftools-dev, chrpath, help2man, qtbase5-dev, qt5-default, libpoco-dev, libreadline6-dev, libgsl0-dev
+Build-Depends: debhelper (>= 9), cdbs, quilt, dpkg-dev (>= 1.16.1~), libosl-dev (>= 0.8.0), libboost-all-dev, libgoogle-perftools-dev, chrpath, help2man, qtbase5-dev, qtchooser, qt5-qmake, qtbase5-dev-tools, libpoco-dev, libreadline6-dev, libgsl-dev
 Standards-Version: 3.9.8
 Homepage: http://gps.tanaka.ecc.u-tokyo.ac.jp/gpsshogi/pukiwiki.php
-Vcs-Browser: http://git.debian.org/?p=collab-maint/gpsshogi.git;a=summary
-Vcs-Git: git://git.debian.org/git/collab-maint/gpsshogi.git
+Vcs-Git: https://anonscm.debian.org/git/collab-maint/gpsshogi.git
+Vcs-Browser: https://anonscm.debian.org/git/collab-maint/gpsshogi.git
 
 Package: gpsshogi
 Architecture: i386 amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, libosl1 (>= 0.6.0), gpsshogi-data (= ${source:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, gpsshogi-data (= ${source:Version})
 Description: Shogi playing program based on OpenShogiLib
  GPSShogi is a Shogi playing program based on OpenShogiLib and won the 19th
  World Computer Shogi Championship. This package contains several binaries to
diff -Nru gpsshogi-0.7.0/debian/patches/0004-Specify-QT_SELECT-qt5.patch gpsshogi-0.7.0/debian/patches/0004-Specify-QT_SELECT-qt5.patch
--- gpsshogi-0.7.0/debian/patches/0004-Specify-QT_SELECT-qt5.patch	1970-01-01 01:00:00.0 +0100
+++ gpsshogi-0.7.0/debian/patches/0004-Specify-QT_SELECT-qt5.patch	2017-03-31 00:53:39.0 +0200
@@ -0,0 +1,17 @@
+From: Daigo Moriwaki 
+Date: Mon, 2 Jan 2017 15:17:44 +0900
+Subject: Specify QT_SELECT=qt5
+
+---
+ makefile.local | 2 ++
+ 1 file changed, 2 insertions(+)
+ create mode 100644 makefile.local
+
+diff --git a/makefile.local b/makefile.local
+new file mode 100644
+index 000..3ebd281
+--- /dev/null
 b/makefile.local
+@@ -0,0 +1,2 @@
++QMAKEENV = QT_SELECT=qt5 
++
diff -Nru gpsshogi-0.7.0/debian/patches/series gpsshogi-0.7.0/debian/patches/series

Bug#859150: installation-guide: leaves many /tmp/tmp* files behind

[Cyril Brulebois]

Samuel Thibault  (2017-03-31):
> Hello Holger,
> 
> Cyril Brulebois, on ven. 31 mars 2017 00:09:34 +0200, wrote:
> > Maybe to ease hands-on debugging, dblatex is called with the -d flag,
> > which tells it to leave temporary files behind. This ends up filling
> > up dillon's /tmp (in addition to being rather bad style in the first
> > place…).
> 
> Is -d really useful now that we have seen the whole thing working?
> 
> Alternatively,
> 
> >  - or set TMPDIR to a subdirectory of $tempdir, which gets automatically
> >removed after a build.
> 
> would be fine to me, I'm just thinking that we perhaps just not need
> these files at all now.

I didn't check history (because svn, mainly; and because I'd already
lost track of what I was initially doing), but if that was merely a
debug aid, removing it looks good to me. :)

FWIW dillon currently has an svn checkout with the TMPDIR patch, so no
hurry right now; just needs to be fixed for the release. ;-)


KiBi.


signature.asc
Description: Digital signature

Bug#858601: [Pkg-samba-maint] Bug#858601: Bug#858601: winbind: user authentication using windows domain fails after upgrade to 4.2.14+dfsg-0+deb8u4

[Albert Dengg]

On Fri, Mar 31, 2017 at 12:33:29AM +0200, Mathieu Parent wrote:
> 2017-03-30 23:50 GMT+02:00 Albert Dengg :
> > sorry for the late reply i was a bit busy and re-upgrading the
> > server is a slight problem as it is an activly used producticion
> > server were people need
> 
> Reading your smb.conf, it looks like you're affectected by the
> vfs_shadow_copy2 regression.
> 
> Can you test those packages, signed by me:
> https://people.debian.org/~sathieu/samba/
ah...you guessed right, these packages seem to fix the problem, i
will test a bit but it looks like the problem is fixed
(including the winbindd error messages, for some reason)

thanks for the fast reply and sorry for me jumping to the wrong
conclutions.

regards,
albert


signature.asc
Description: PGP signature

Bug#802211: systemd: rescue.service fails if root password is not set, needs sulogin --force

[Michael Biebl]

Am 31.03.2017 um 00:27 schrieb Nathan Dorfman:
> Hi, this is still an issue with the default stretch install, if the
> option to not set a root password is taken at installation.
> 
> It is quite severe IMO, especially considering how likely it is to be
> discovered only when the rescue shell is actually needed.
> 
> If this really can't be fixed before release, I'd strongly suggest
> that debian-installer force a root password to be set until it can.
> 
> On a secondary note, I personally find it rather ludicrous that this
> trivial fix is being held up by some kiosk considerations. Setting up
> one of those usually requires many other customizations (for example,
> disabling the default window manager), and it makes little sense to
> opt for sudo over a separate root account at installation time for a
> kiosk in the first place.
> 
> On the other hand, the much more common desktop use case shouldn't be
> this broken out of the box. IMHO, of course.
> 

Consider this: You have a laptop with a locked root account. By default
the grub boot loader generates a boot entry for rescue mode.
So, even if you lock down the bios to not allow booting from CD-Rom or
USB, and you password protect grub, someone could easily get root access
if you leave the laptop unattended for a moment.

I know that the only safe solution for this is to fully encrypt your
hard-drive. But there are lot's of existing systems out there which
don't use full-disk encryption.
Imo the only safe solution would be, if sulogin would be changed to
check for "admin" accounts in case root is locked. In this case it would
ask for both username and password in this case.

Admin accounts would be those in group sudo (Debian) or admin(Ubuntu).

Maybe I'm overly paranoid here, but maybe that helps to better
understand my concerns.

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#858591: limesuite: Please update to newer release

[Andreas Bombe]

On Fri, Mar 24, 2017 at 08:27:15AM +0100, Sebastian Reichel wrote:
> I received my LimeSDR yesterday and it comes with a newer FW than
> expected by limesuite resulting in incorrect behaviour in lots of
> places. The following information is printed to standard output:

This is rather unfortunate concerning that we are already in a release
freeze. If it is useless for the batch of boards that reached the
majority of buyers (I had the same problem with my own new LimeSDR) then
I should try to get the newer package into the release.

For now, I will upload to experimental shortly.

Bug#824364: spice-vdagent intentionally doesn't resize, expects gnome to do it

[Nathan Dorfman]

#858549 might be a dupe of this one. As I noted there[1], it turns out
that instead of resizing the display directly, spice-vdagent now just
informs Gnome that the resize is needed. Consequently, resize only
works with Gnome.

(I found that information in a related redhat ticket, [2].)

-nd.

[1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858549#15

[2] - https://bugzilla.redhat.com/show_bug.cgi?id=1290586

Bug#856720: diaspora{, -installer}: fails to install: Errno::EEXIST: File exists @ dir_s_mkdir - /usr/share/diaspora/tmp

[Andreas Beckmann]

Followup-For: Bug #856720
Control: found -1 0.6.3.0+debian4

Hi,

and there we go again ...

[...]
  Precompiling assets...
  W, [2017-03-30T07:12:27.702004 #19736]  WARN -- : You are setting a key that 
conflicts with a built-in method OmniAuth::AuthHash::InfoHash#name defined at 
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/omniauth-1.3.1/lib/omniauth/auth_hash.rb:34.
 This can cause unexpected behavior when accessing the key via as a property. 
You can still access the key via the #[] method.
  Expected string default value for '--serializer'; got true (boolean)
  Rack::SSL is enabled
  rake aborted!
  Errno::EEXIST: File exists @ dir_s_mkdir - /usr/share/diaspora/tmp
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/cache/file_store.rb:25:in
 `[]='
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/caching.rb:34:in
 `cache_set'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/caching.rb:92:in
 `cache_set_hash'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/caching.rb:63:in
 `cache_asset'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/index.rb:93:in
 `build_asset'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/base.rb:287:in
 `find_asset'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/index.rb:61:in
 `find_asset'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/manifest.rb:211:in
 `block in find_asset'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/manifest.rb:257:in
 `benchmark'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/manifest.rb:210:in
 `find_asset'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/manifest.rb:119:in
 `block in compile'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/manifest.rb:118:in
 `each'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/sprockets/manifest.rb:118:in
 `compile'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-rails-2.3.3/lib/sprockets/rails/task.rb:70:in
 `block (3 levels) in define'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-2.12.4/lib/rake/sprocketstask.rb:146:in
 `with_logger'
  
/usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/sprockets-rails-2.3.3/lib/sprockets/rails/task.rb:69:in
 `block (2 levels) in define'
  /usr/share/diaspora/vendor/bundle/ruby/2.3.0/gems/rake-11.3.0/exe/rake:27:in 
`'
  Tasks: TOP => assets:precompile
  (See full trace by running task with --trace)
  dpkg: error processing package diaspora-installer (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   diaspora-installer


Andreas


diaspora-installer_0.6.3.0+debian4.log.gz
Description: application/gzip

Bug#858601: [Pkg-samba-maint] Bug#858601: Bug#858601: winbind: user authentication using windows domain fails after upgrade to 4.2.14+dfsg-0+deb8u4

[Mathieu Parent]

2017-03-30 23:50 GMT+02:00 Albert Dengg :
> sorry for the late reply i was a bit busy and re-upgrading the
> server is a slight problem as it is an activly used producticion
> server were people need

Reading your smb.conf, it looks like you're affectected by the
vfs_shadow_copy2 regression.

Can you test those packages, signed by me:
https://people.debian.org/~sathieu/samba/

Thanks
-- 
Mathieu Parent

Bug#788387: gdebi downgrade bug not fixed

[Glenn Widener]

gdebi 0.9.5.3ubuntu2 still cannot downgrade packages.  Only the underlying 
library was fixed, and even that fix has not shown up as of python-apt  
0.9.3.5ubuntu2.



Please reopen.  I have verified that the fix works, once enabled in gdebi.



This is a blocker, unless someone can explain how to force a fixed apt version 
configuration, given lack of preservation of older versions in Ubuntu package 
archives, without hosting a complete, permanent mirror.

Bug#858590: Test packages fixing samba regressions

[Mathieu Parent]

Hello all,

I've prepared samba packages fixing vfs_shadowcopy2 and "follow symlink = no".

Can you test and report? (I've tested simple cases with those two options only).

Those are, signed with my key, at: https://people.debian.org/~sathieu/samba/

Regards

-- 
Mathieu Parent

Bug#802211: systemd: rescue.service fails if root password is not set, needs sulogin --force

[Nathan Dorfman]

Hi, this is still an issue with the default stretch install, if the
option to not set a root password is taken at installation.

It is quite severe IMO, especially considering how likely it is to be
discovered only when the rescue shell is actually needed.

If this really can't be fixed before release, I'd strongly suggest
that debian-installer force a root password to be set until it can.

On a secondary note, I personally find it rather ludicrous that this
trivial fix is being held up by some kiosk considerations. Setting up
one of those usually requires many other customizations (for example,
disabling the default window manager), and it makes little sense to
opt for sudo over a separate root account at installation time for a
kiosk in the first place.

On the other hand, the much more common desktop use case shouldn't be
this broken out of the box. IMHO, of course.

-nd.

Bug#859150: installation-guide: leaves many /tmp/tmp* files behind

[Samuel Thibault]

Hello Holger,

Cyril Brulebois, on ven. 31 mars 2017 00:09:34 +0200, wrote:
> Maybe to ease hands-on debugging, dblatex is called with the -d flag,
> which tells it to leave temporary files behind. This ends up filling
> up dillon's /tmp (in addition to being rather bad style in the first
> place…).

Is -d really useful now that we have seen the whole thing working?

Alternatively,

>  - or set TMPDIR to a subdirectory of $tempdir, which gets automatically
>removed after a build.

would be fine to me, I'm just thinking that we perhaps just not need
these files at all now.

Samuel

Bug#859049: pixbros: Pixbros is not installable on amd64 system

[Markus Koschany]

Am 29.03.2017 um 21:30 schrieb Andrej Mernik:
> Package: pixbros
> Version: 0.6.3-2
> Severity: important
> 
> Dear Maintainer,
> 
> it appears that the pixbros package is not installable on Stretch amd64,
> because its depends are not installable.
> 
> I am aware that the package itself might be architecture independent, but it
> should not be. The current state creates confusion for the end user, making
> Debian amd64 and its derivatives look broken, which also contributes to the
> overall public perception of GNU/Linux as unsuited for daily use.
> 
> The package should be marked as "i386 only" as soon as possible.
> 
> Best Regards,
> Andrej Mernik

Hi,

the real issue here is that fenix only works on 32bit architectures. [1]

I think that your statement that Debian might be perceived as unsuited
for daily use due to this bugs is an exaggeration but I agree that the
only way to work around this issue is to limit the games to the same
architectures fenix has been built on. (fenix control file is outdated
too but the following list should suffice)

arm armel armhf hppa hurd-i386 i386 kfreebsd-i386 m68k mips mipsel
powerpc s390 sh4

If nobody beats me to it I will update the packages and fenix after the
freeze.

Markus Koschany

[1] https://bugs.debian.org/456037






signature.asc
Description: OpenPGP digital signature

Bug#859147: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart failure on upgrade

[Michael Biebl]

Am 30.03.2017 um 23:50 schrieb ydir...@free.fr:

> Any other information would be useful ?

Can you attach the following information
journalctl -alb
systemd-cgls







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

Bug#859150: installation-guide: leaves many /tmp/tmp* files behind

[Cyril Brulebois]

Source: installation-guide
Severity: serious
Tags: patch
Justification: Fills up /tmp on dillon.debian.org

Hi,

Maybe to ease hands-on debugging, dblatex is called with the -d flag,
which tells it to leave temporary files behind. This ends up filling
up dillon's /tmp (in addition to being rather bad style in the first
place…).

Two possibilities:
 - remove the -d flag entirely (untested);
 - or set TMPDIR to a subdirectory of $tempdir, which gets automatically
   removed after a build.

The attached patch implements the second solution, but comments are
welcome.


KiBi.
Index: build/buildone.sh
===
--- build/buildone.sh	(revision 70645)
+++ build/buildone.sh	(working copy)
@@ -232,7 +232,8 @@
 
 echo "Info: creating .pdf file..."
 
-( dblatex -d -V -T db2latex -b xetex -p ./stylesheets/dblatex.xsl \
+mkdir -p $tempdir/dblatex
+(TMPDIR=$tempdir/dblatex dblatex -d -V -T db2latex -b xetex -p ./stylesheets/dblatex.xsl \
 -o $tempdir/install.${language}.pdf \
 $tempdir/install.${language}.profiled.xml --param=lingua=${language} )
 RET=$?; [ $RET -ne 0 ] && return $RET

Bug#859149: python-sklearn-doc: broken symlink: /usr/share/doc/python-sklearn-doc/html/_static/underscore.js -> ../../../../javascript/jquery/underscore.js

[Andreas Beckmann]

Package: python-sklearn-doc
Version: 0.18-5
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m14.5s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-sklearn-doc/html/_static/underscore.js -> 
../../../../javascript/jquery/underscore.js

 ^^

A possible target is /usr/share/javascript/underscore/underscore.js
   ^^

cheers,

Andreas


python-sklearn-doc_0.18-5.log.gz
Description: application/gzip

Bug#859148: python-paver: broken symlink: /usr/share/doc/python-paver/html/_static/underscore.js -> ../../../../javascript/jquery/underscore.js

[Andreas Beckmann]

Package: python-paver
Version: 1.2.1-1.1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m11.2s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-paver/html/_static/underscore.js -> 
../../../../javascript/jquery/underscore.js

   ^^

A possible target is /usr/share/javascript/underscore/underscore.js
   ^^

You may also need a Depends/Recommends/Suggests: libjs-underscore


cheers,

Andreas


python-paver_1.2.1-1.1.log.gz
Description: application/gzip

Bug#853855: di-utils: Kernel boot options containing a dot are not propagated to the installed system

[Samuel Thibault]

Ben Hutchings, on jeu. 30 mars 2017 15:24:03 +0100, wrote:
> they are likely to be outnumbered by those who do want them set.

Not only that, but the manual does document that such options *are*
propagated to the installed system when placed properly. Not doing so is
really unexpected behavior.

Samuel

Bug#858601: [Pkg-samba-maint] Bug#858601: winbind: user authentication using windows domain fails after upgrade to 4.2.14+dfsg-0+deb8u4

[Albert Dengg]

sorry for the late reply i was a bit busy and re-upgrading the
server is a slight problem as it is an activly used producticion
server were people need 
On Thu, Mar 30, 2017 at 10:34:28PM +0200, Mathieu Parent wrote:
> )Control: tag -1 + moreinfo
> 
> 2017-03-24 15:20 GMT+01:00 Mathieu Parent :
> > 2017-03-24 11:19 GMT+01:00 Albert Dengg :
> >> Package: winbind
> >> Version: 2:4.2.14+dfsg-0+deb8u2
> >> Severity: important
> >>
> >> after upgrading windbind and samba to 4.2.14+dfsg-0+deb8u4, authentication 
> >> of domains users using winbind
> >> does not work anymore:
> >> winbindd[8142]: [2017/03/24 10:20:10.040610,  0] 
> >> ../source3/winbindd/winbindd_group.c:45(fill_grent)
> >> winbindd[8142]:   Failed to find domain ''. Check connection to trusted 
> >> domains!
> >>
> >> (getent did list at least users from winbind)
> >>
> >> the domain ins specified in smbd.conf and it works as expected in 
> >> 4.2.14+dfsg-0+deb8u2
> >
> > Please send us your smb.conf.
see attachment
(i changed the domain name to something neutral, but 
> >
> > What does "net ads testjoin" tells?
Join is OK
(and both 'getent passwd' as well as 'getent group' produces the
desired output)
> 
> Appart from the above. This looks very strange. Nothing was changed on
> the winbind side between those versions.
> 
> Are you able to use gdb and post the backtrae in this function
> (fill_grent) and find why dom_name is empty?
i tried to install samba-dbg and start winbindd using gdb.

however a breakpoint on fill_grent did not trigger for some reason
(i played around with follow-mode and tried both starting without
passing arguments as well as passing -i)

> 
> Is your smb.conf a symlink?
no

side note:
i downgraded initially to work around the problem and upgraded today
to do the test (with the same result), but a downgrade of the
following packages solved it again:
libnss-winbind
libpam-winbind
libsmbclient
libwbclient0
python-samba
samba
samba-common
samba-common-bin
samba-dbg
samba-dsdb-modules
samba-libs
samba-vfs-modules
winbind

regards,
albert
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which 
# are not shown in this example
#
# Some options that are often worth tuning have been included as
# commented-out examples in this file.
#  - When such options are commented with ";", the proposed setting
#differs from the default Samba behaviour
#  - When commented with "#", the proposed setting is the default
#behaviour of Samba but the option is considered important
#enough to be mentioned here
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic 
# errors. 

#=== Global Settings ===

[global]
workgroup = SOMEDOMAIN
server string = Samba Server Version %v
security = ads
realm = SOMEDOMAIN.LOCAL
domain master = no
local master = no
preferred master = no
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 
SO_SNDBUF=131072
use sendfile = true
 
idmap config * : backend = tdb
idmap config * : range = 10-29
idmap config SOMEDOMAIN : backend = rid
idmap config SOMEDOMAIN : range = 1-9
winbind separator = +
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
winbind nested groups = yes
winbind refresh tickets = yes
template homedir = /home/%D/%U
template shell = /bin/false
 
client use spnego = yes
client ntlmv2 auth = yes
encrypt passwords = yes
restrict anonymous = 2
log file = /var/log/samba/log.%m
max log size = 50
loglevel = 0

ea support = yes
acl check permissions = yes
inherit acls =yes
csc policy = disable
store dos attributes = yes
dos filemode = no
 
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes   
 
# Share Definitions ==
 
[Individuell]
comment = "Verzeichnis fuer Datenaustausch"
path = /pools/share/Individuell
read only = no
browseable = yes
guest ok = no
delete readonly = yes
vfs objects = acl_xattr shadow_copy2
map acl inherit = Yes
shadow: snapdir = .zfs/snapshot
shadow: sort = desc
shadow: format = %Y-%m-%d-%H%M
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes

[INSTALL]
comment = "Div. Installer"
path = /pools/share/INSTALL
read only = no
browseable = yes
guest ok = no
delete readonly = yes
vfs objects = acl_xattr shadow_copy2
map acl inherit = Yes
 

Bug#859147: network-manager: restart failure on upgrade

[ydirson]

Package: network-manager
Version: 1.6.2-3

When upgrading from 1.6.2-2:

Setting up network-manager (1.6.2-3) ...
Job for NetworkManager.service failed because a timeout was exceeded.
See "systemctl status NetworkManager.service" and "journalctl -xe" for details.
invoke-rc.d: initscript network-manager, action "restart" failed.
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor 
preset: enabled)
   Active: activating (auto-restart) (Result: timeout) since Thu 2017-03-30 
23:43:52 CEST; 4ms ago
 Docs: man:NetworkManager(8)
  Process: 16706 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=killed, 
signal=TERM)
 Main PID: 16706 (code=killed, signal=TERM)
  CPU: 1min 30.013s

Mar 30 23:43:52 yantop systemd[1]: NetworkManager.service: Unit entered failed 
state.
Mar 30 23:43:52 yantop systemd[1]: NetworkManager.service: Failed with result 
'timeout'.
dpkg: error processing package network-manager (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 network-manager


===
# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

===
# cat /etc/network/interfaces.d/LOCAL-lxc 
auto lxcbr0
iface lxcbr0 inet static
address 10.100.0.1
bridge_ports none
bridge_fd 0
bridge_maxwait 0
up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Any other information would be useful ?

Bug#856590: systemd: Unspecified problems mounting /usr partition

[Michael Biebl]

Am 30.03.2017 um 23:07 schrieb Emmanuel DECAEN:
> Hi,
> 
> I have the same of problem on multiple servers with systemd/232-19.
> 
> You will find journalctl -alb et udevadm info in attachments.

Your journal shows problems with /var, /tmp, /home and swap.

Makes me wonder if your /etc/fstab is actually correct.



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



signature.asc
Description: OpenPGP digital signature

Bug#859143: kup: please update to v0.3.6 due changes on k.o

[Ben Hutchings]

Control: severity -1 serious

On Thu, 2017-03-30 at 23:17 +0200, Sebastian Andrzej Siewior wrote:
> Package: kup
> Version: 0.3.2-1
> Severity: wishlist
> 
> The kup-server on k.o will be probably upgraded / changed around
> kernel's rc6 and rc7 which renders current kup-client version useless /
> not working. Konstantin tagged as of today 0.3.6 which is working /
> contains the required changes on the client side.

I saw that this was coming but didn't see the tag.

Upgrading severity as it would be pointless to release with this
version.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



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

Bug#859144: unblock: celery/3.1.23-7

[Brian May]

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

Please unblock package celery

Fixes bashisms in initd scripts. See #858298. Patch is from upstream.

diff -Nru celery-3.1.23/debian/changelog celery-3.1.23/debian/changelog
--- celery-3.1.23/debian/changelog  2017-03-24 17:00:36.0 +1100
+++ celery-3.1.23/debian/changelog  2017-03-30 07:55:02.0 +1100
@@ -1,3 +1,9 @@
+celery (3.1.23-7) unstable; urgency=medium
+
+  * Fix bashisms in initd scripts. Closes: #858298.
+
+ -- Brian May   Thu, 30 Mar 2017 07:55:02 +1100
+
 celery (3.1.23-6) unstable; urgency=medium
 
   * Change celeryd to depend on python-celery-common instead of python-celery.
diff -Nru celery-3.1.23/debian/.git-dpm celery-3.1.23/debian/.git-dpm
--- celery-3.1.23/debian/.git-dpm   2016-05-25 18:07:35.0 +1000
+++ celery-3.1.23/debian/.git-dpm   2017-03-30 07:20:15.0 +1100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-8af58d646c13cbd52374f855d522f48b580b3089
-8af58d646c13cbd52374f855d522f48b580b3089
+fe0a322f110f182dc98d703815d17663fa5ac893
+fe0a322f110f182dc98d703815d17663fa5ac893
 6753277798b7b79fec667e858b4cbf459c1c277c
 6753277798b7b79fec667e858b4cbf459c1c277c
 celery_3.1.23.orig.tar.gz
diff -Nru 
celery-3.1.23/debian/patches/0008-Remove-bashisms-from-initd-scripts.patch 
celery-3.1.23/debian/patches/0008-Remove-bashisms-from-initd-scripts.patch
--- celery-3.1.23/debian/patches/0008-Remove-bashisms-from-initd-scripts.patch  
1970-01-01 10:00:00.0 +1000
+++ celery-3.1.23/debian/patches/0008-Remove-bashisms-from-initd-scripts.patch  
2017-03-30 07:20:15.0 +1100
@@ -0,0 +1,53 @@
+From fe0a322f110f182dc98d703815d17663fa5ac893 Mon Sep 17 00:00:00 2001
+From: Ask Solem 
+Date: Mon, 23 May 2016 13:45:39 -0700
+Subject: Remove bashisms from initd scripts
+
+Patch from
+https://github.com/celery/celery/commit/44c0ebf9c46406988e5002f8a78aa2dd506451d6
+---
+ extra/generic-init.d/celerybeat | 9 +++--
+ extra/generic-init.d/celeryd| 7 ++-
+ 2 files changed, 13 insertions(+), 3 deletions(-)
+
+diff --git a/extra/generic-init.d/celerybeat b/extra/generic-init.d/celerybeat
+index 78aa25a..a1596a3 100755
+--- a/extra/generic-init.d/celerybeat
 b/extra/generic-init.d/celerybeat
+@@ -33,9 +33,14 @@ if [ $(id -u) -ne 0 ]; then
+ exit 1
+ fi
+ 
++origin_is_runlevel_dir () {
++set +e
++dirname $0 | grep -q "/etc/rc.\.d"
++echo $?
++}
+ 
+-# May be a runlevel symlink (e.g. S02celeryd)
+-if [ -L "$0" ]; then
++# Can be a runlevel symlink (e.g. S02celeryd)
++if [ $(origin_is_runlevel_dir) -eq 0 ]; then
+ SCRIPT_FILE=$(readlink "$0")
+ else
+ SCRIPT_FILE="$0"
+diff --git a/extra/generic-init.d/celeryd b/extra/generic-init.d/celeryd
+index 7ad4599..d88e029 100755
+--- a/extra/generic-init.d/celeryd
 b/extra/generic-init.d/celeryd
+@@ -41,9 +41,14 @@ if [ $(id -u) -ne 0 ]; then
+ exit 1
+ fi
+ 
++origin_is_runlevel_dir () {
++set +e
++dirname $0 | grep -q "/etc/rc.\.d"
++echo $?
++}
+ 
+ # Can be a runlevel symlink (e.g. S02celeryd)
+-if [[ `dirname $0` == /etc/rc*.d ]]; then
++if [ $(origin_is_runlevel_dir) -eq 0 ]; then
+ SCRIPT_FILE=$(readlink "$0")
+ else
+ SCRIPT_FILE="$0"
diff -Nru celery-3.1.23/debian/patches/series 
celery-3.1.23/debian/patches/series
--- celery-3.1.23/debian/patches/series 2016-05-25 18:07:35.0 +1000
+++ celery-3.1.23/debian/patches/series 2017-03-30 07:20:15.0 +1100
@@ -5,3 +5,4 @@
 privacy.patch
 0006-ci-Tests-passing-on-Python-3.5.patch
 0007-Set-shell-in-su-invocation.patch
+0008-Remove-bashisms-from-initd-scripts.patch

unblock celery/3.1.23-7

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

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

Bug#859020: unblock: ruby-bootstrap-sass/3.3.5.1-4

[Antonio Terceiro]

On Thu, Mar 30, 2017 at 07:55:00PM +, Niels Thykier wrote:
> Thanks for the changeset.
> 
> Unfortunately, as a matter of policy I would strongly prefer if the
> compat bump was undone.  They have "actions at a distance" that are hard
> to reason about in general, so it is easier to simply say "no" than
> manually verify it.
> 
> Without the compat bump, I am happy to accept the other changes.

Fair enough. However, I just did a local build with it changed back to 7, and
the produced binaries are bit-by-bit identical (I didn't change anything else,
just to test).

That said, I can do a new upload if you say so.


signature.asc
Description: PGP signature

Bug#859143: kup: please update to v0.3.6 due changes on k.o

[Sebastian Andrzej Siewior]

Package: kup
Version: 0.3.2-1
Severity: wishlist

The kup-server on k.o will be probably upgraded / changed around
kernel's rc6 and rc7 which renders current kup-client version useless /
not working. Konstantin tagged as of today 0.3.6 which is working /
contains the required changes on the client side.

Sebastian

Bug#859066: linux-image-*: recommend firmware-ath9k-htc

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 2017-03-30 at 09:22 +0800, Paul Wise wrote:
> Source: linux
> Version: 4.10~rc6-1~exp1
> Severity: wishlist
> X-Debbugs-CC: open-ath9k-htc-firmw...@packages.debian.org
> 
> Now that open-ath9k-htc-firmware has been accepted into Debian
> unstable, please add "Recommends: firmware-ath9k-htc" to the
> metadata for the linux-image-* packages in Debian experimental.

As this firmware has gone through at least one ABI bump, I think we
need to plan for a future ABI bump.

Therefore:
- You should not name the files as simply '1.dev.0' versions, but by
  the implemented ABI version (as the driver expects by default).
- The recommends relation should only match packages that provide a
  compatible firmware version.  I think that means it should be
  firmware-ath9k-htc (<< 1.5) currently.

Do you agree?

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.


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

Bug#858800: RFS: xtrs/4.9d-1 [ITA]

[Sean Whitton]

Dear Branden,

On Thu, Mar 30, 2017 at 09:29:25AM -0400, G. Branden Robinson wrote:
> It can.  I've uploaded xtrs 4.9c-4 with a far leaner set of changes, and
> am attaching a diff of the diff to this message.  As you can see, it's
> far leaner.
> 
> Thoughts?

Was the Build-Depends change intentional?  It's not in the changelog.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#859048: [pkg-horde] Bug#859048: Attachment check hook prevents IMP smartmobile view to send message with 'attachment' word when there's no attachment

[Leonardo Bruno]

Em 30/03/2017 04:31, "Mathieu Parent"  escreveu:

2017-03-29 21:28 GMT+02:00 Leonardo Bruno :
> Package: php-horde-imp
> Version: 6.2.2-3
> Severity: important
>
> Scenario: Compose a message using the IMP smartmobile view in a Horde
setup
> with the 'attach_body_check' enabled.

>
> Symptoms: When using the IMP smartmobile view, it will not be possible to
> send a message without attachments if in the message body text there is
any
> of the keywords defined in the 'attach_body_check' IMP hook function.
>
> The first attempt to send will show a warning message informing that no
> attachments are indeed present, as it is expected. However, the following
> attempts present the same behavior: a message warns about the absence of
> attachments and the message is not sent. It will only be sent if: 1) you
> remove the keyword(s) from the message, or 2) add some attachment, or 3)
> disable the hook.
>
> Remarks:
> 1. Only the smartmobile view is affected.
> 2. The tests where performed with the default Horde and IMP prefs. The
only
> hooke enabled is 'attach_body_check'.
> 3. This issue affects the upcoming php-horde-imp stable package (version
> 6.2.17-1) in Debian stretch.
> 4. I chose to mark this report as 'important' as the smartmobile view
> actually is a must-have feature, and there is no way to deactivate the
> 'attach_body_check' only for this view.

This is probably related to #749799.

Help on this is appreciated.

Regards


--
Mathieu


Dear Mathieu,

This surely should be related to the jQuery issue.

However, it may be helpful to inform that I updated the jQuery on the Horde
setup I detected the problem with the 'attach_body_check'.

I simply downloaded the jQuery version that is included with Horde code
from the development team, and symlinked it in place of the version shipped
with Debian.

So I can confirm that the smartmobile view seems to work correctly, from
the jQuery point of view. For my users and for me, the main features of
Horde, IMP, Turba, Kronolith and Ingo work well on smart phones.

Additionally, I did a little debugging and detected that, in some way,
the 'IMP_Factory_Compose' class constructor is called as many times as the
users clicks 'Send' button while composing messages on the smartmobile view.

This behavior seems to be incorrect as that constructor is called just once
in the Dynamic view which works correctly.

I could also see that each time the 'IMP_Factory_Compose' constructor is
called, a new 'object' is generated with the _metadata['attach_body_check']
attribute not set. A different value for the _cacheid attribute is
generated every time.

This - I suppose - is causing the attach body verification code to always
detect the currently being composed message as a 'new-still-no-verified'
message, which is consistent white the endless loop behavior while trying
to send the message.

As the smartmobile view is primarily driven by jQuery, this can be related
the the Horde JS code or to the library itself.

Regards,
Leonardo Bruno

Bug#802259: ITP: libntru -- implementation of the public-key encryption

[Ralph Todt]

As of March 27, the patents are no longer an issue:

https://github.com/NTRUOpenSourceProject/NTRUEncrypt/issues/11
> The patents are intended to also be public domain. To be specific, we will 
> not take any enforcement action against anyone for any > use of the indicated 
> patents on or after March 27th, 2017. (And "March 27th, 2017" means "March 
> 27th, 2017 anywhere in the
> world").

Bug#859142: keepalived: if host section in SMPT_CHECK, healthchecker process segfaults

[R. Bencheraiet]

Package: keepalived
Version: 1.2.13-1
Severity: important

Dear Maintainer,

keepalived segfaults on start when trying to load a config with a host{}
section under an SMTP_CHECK block.



This bug was corrected upstream in version 1.2.17 [1] in commit
6756a27c94993bfe92e2e09b702502e5e269487c[2].


[1] http://keepalived.org/changelog.html

[2]
https://github.com/andriyanov/keepalived/commit/6756a27c94993bfe92e2e09b702502e5e269487c



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

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

Versions of packages keepalived depends on:
ii  iproute   1:3.16.0-2
pn  ipvsadm   
ii  libc6 2.19-18+deb8u7
ii  libnl-3-200   3.2.24-2
ii  libnl-genl-3-200  3.2.24-2
ii  libpci3   1:3.2.1-3
ii  libsensors4   1:3.3.5-2
pn  libsnmp30 
ii  libssl1.0.0   1.0.1t-1+deb8u6
ii  libwrap0  7.6.q-25

keepalived recommends no packages.

keepalived suggests no packages.

Bug#858601: [Pkg-samba-maint] Bug#858601: winbind: user authentication using windows domain fails after upgrade to 4.2.14+dfsg-0+deb8u4

[Mathieu Parent]

)Control: tag -1 + moreinfo

2017-03-24 15:20 GMT+01:00 Mathieu Parent :
> 2017-03-24 11:19 GMT+01:00 Albert Dengg :
>> Package: winbind
>> Version: 2:4.2.14+dfsg-0+deb8u2
>> Severity: important
>>
>> after upgrading windbind and samba to 4.2.14+dfsg-0+deb8u4, authentication 
>> of domains users using winbind
>> does not work anymore:
>> winbindd[8142]: [2017/03/24 10:20:10.040610,  0] 
>> ../source3/winbindd/winbindd_group.c:45(fill_grent)
>> winbindd[8142]:   Failed to find domain ''. Check connection to trusted 
>> domains!
>>
>> (getent did list at least users from winbind)
>>
>> the domain ins specified in smbd.conf and it works as expected in 
>> 4.2.14+dfsg-0+deb8u2
>
> Please send us your smb.conf.
>
> What does "net ads testjoin" tells?

Appart from the above. This looks very strange. Nothing was changed on
the winbind side between those versions.

Are you able to use gdb and post the backtrae in this function
(fill_grent) and find why dom_name is empty?

Is your smb.conf a symlink?

Regards

-- 
Mathieu

Bug#859059: keyboard-configuration: many mac keymap in keyboard-configuration are faulty

[raphael truc]

Hi,

Thanks for your quick reply
I understand it may not be easy. Maybe a solution would to be to have more
atomic keyboard description file that could be combined together, but it
may add some strange results, though.
The problem, for now, is that nothing raises a warning or an error saying
it could not work, which is very confusing and frustrating, and painful for
non experienced users and even experienced ones.
And also it could make people think that it's a specifically bad designed
package from Debian which is not.

Have a nice day

Raphael

2017-03-30 20:43 GMT+02:00 Anton Zinoviev :

> forcemerge 535834 859059
> thanks
>
> On Wed, Mar 29, 2017 at 10:28:42PM +0200, raphael wrote:
> >
> > I have a macbook pro with us keymap, I tried different layouts
> > available in keyboard-configuration to get accents, but ended with Can
> > not find "mac" in "macintosh_vndr/us". or Can not find "altgr-intl" in
> > "macintosh_vndr/us". and No Symbols named "altgr-intl" in the include
> > file "macintosh_vndr/us" or No Symbols named "mac" in the include file
> > "macintosh_vndr/us"
> >
> > I ended up copying the altgr part of the pc keyboard (found in
> > /usr/share/X11/xkb/symbols) to the macintosh one. I already had the
> > same kind of problem with mac french azerty keyboard. I think either
> > the /usr/share/X11/xkb/symbols/macintosh_vndr files should be
> > corrected or choices in the keyboard-configuration setup reduced to
> > what's really available (it took me quite a long time to understand
> > why I couldn't get the accents though everything looked fine).
>
> Yes, this is an unfortunate bug which is reported from time to time.
> Unfortunately, it can not be fixed because of
>
> https://bugs.freedesktop.org/show_bug.cgi?id=33670
>
> Anton Zinoviev
>
>

Bug#859101: [Pkg-samba-maint] Bug#859101: regression: net: security update makes `net ads join` freeze when run a second time

[Mathieu Parent]

Hi,

2017-03-30 13:12 GMT+02:00 Paul Wise :
> Control: fixed -1 2:4.5.6+dfsg-1
>
> On Thu, 2017-03-30 at 18:30 +0800, Paul Wise wrote:
>
>> I've confirmed that the freeze does not happen on samba 4.1 using
>> snapshot.d.o. The issue still occurs with 2:4.2.14+dfsg-0+deb8u4.
>
> I've confirmed this issue does not happen with stretch 2:4.5.6+dfsg-1

Can you try this patch:
https://git.samba.org/?p=samba.git;a=commitdiff;h=38beef2ff63664d7d5805f1032bb9f69d0b965d7

(first released in 4.3.0)

Regards

-- 
Mathieu Parent

Bug#848978: Unsuitable to be part of stable release without proper maintainer

[Markus Wanner]

Control: -1 pending

Hi,

I'm attempting to take over the courier packages and maintain them for
stretch. Uploads will follow shortly.

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#858892: unblock: haproxy/1.7.4-1

[Niels Thykier]

Control: tags -1 confirmed moreinfo

Vincent Bernat:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hey!
> 
> We would like to upload HAProxy 1.7.4 to unstable. This is mostly a
> bugfix only release (1.7 is the current stable branch).
> 
> Upstream says:
> 
>> The most important ones concern a regression unveiled by a fix introduced
>> in 1.7.3 (which itself allowed to spot another one), another issue where
>> clients could occasionally get a 503 when compression was enabled, and a
>> risk of memory leak if a redirect is enabled on http-response with 
>> compression
>> enabled. [...]
> 
>> All users of 1.7 should definitely upgrade.
> 
> [...]
> 
> Would it be OK?
> 
> unblock haproxy/1.7.4-1
> 
> [...]

Thanks, please go ahead and remove the moreinfo tag once it has been
uploaded and built on all relevant release architectures.

Thanks,
~Niels

Bug#859008: dvb-tools: dvbv5-scan segfaults with DVB-T2 HD service that just started in Germany

[Mauro Carvalho Chehab]

Hi Gregor,

Em Wed, 29 Mar 2017 20:45:06 +0200
Gregor Jasny  escreveu:

> Hello Mauro & list,
> 
> could you please have a look at the dvbv5-scan crash report below?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008
> 
> Is there anything else you need to debug this?

I'm able to reproduce it on a Debian machine here too, but so far,
I was unable to discover what's causing it. I'll try to find some time
to take a better look on it.

> 
> Thanks,
> Gregor
> 
> On 3/29/17 4:42 PM, Tino Mettler wrote:
> > 
> > $ gdb --args ./utils/dvb/dvbv5-scan ~/tmp/dvb-t2/init2 
> > GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later 
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from ./utils/dvb/dvbv5-scan...done.
> > (gdb) run
> > Starting program: /home/scorpion/build/9643/v4l-utils/utils/dvb/dvbv5-scan 
> > /home/scorpion/tmp/dvb-t2/init2
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > Scanning frequency #1 55400
> > Lock   (0x1f) C/N= 23.75dB
> > Service Das Erste HD, provider BR: reserved
> > Service arte HD, provider BR: reserved
> > Service PHOENIX HD, provider BR: reserved
> > Service tagesschau24 HD, provider BR: reserved
> > Service ONE HD, provider BR: reserved
> > New transponder/channel found: #11: -1776415946
> > New transponder/channel found: #12: 504706590
> > New transponder/channel found: #13: 523640360
> > New transponder/channel found: #14: 907948854
> > New transponder/channel found: #15: -397832490
> > New transponder/channel found: #16: 0
> > New transponder/channel found: #17: 0
> > New transponder/channel found: #18: 0
> > New transponder/channel found: #19: 0
> > New transponder/channel found: #20: 0
> > New transponder/channel found: #21: 0
> > New transponder/channel found: #22: 0
> > New transponder/channel found: #23: 0
> > New transponder/channel found: #24: 0
> > New transponder/channel found: #25: 0
> > New transponder/channel found: #26: 0
> > New transponder/channel found: #27: 0
> > New transponder/channel found: #28: 0
> > New transponder/channel found: #29: 0
> > New transponder/channel found: #30: 0
> > New transponder/channel found: #31: 0
> > New transponder/channel found: #32: 0
> > New transponder/channel found: #33: 0
> > New transponder/channel found: #34: 0
> > New transponder/channel found: #35: 0
> > New transponder/channel found: #36: 0
> > New transponder/channel found: #37: 0
> > New transponder/channel found: #38: 0
> > New transponder/channel found: #39: 0
> > New transponder/channel found: #40: 0
> > New transponder/channel found: #41: 0
> > New transponder/channel found: #42: 0
> > New transponder/channel found: #43: 0
> > New transponder/channel found: #44: 0
> > New transponder/channel found: #45: 0
> > New transponder/channel found: #46: 0
> > New transponder/channel found: #47: 0
> > New transponder/channel found: #48: 0
> > New transponder/channel found: #49: 0
> > New transponder/channel found: #50: 0
> > New transponder/channel found: #51: 0
> > New transponder/channel found: #52: 0
> > New transponder/channel found: #53: 0
> > New transponder/channel found: #54: 0
> > New transponder/channel found: #55: 0
> > New transponder/channel found: #56: 0
> > New transponder/channel found: #57: 0
> > New transponder/channel found: #58: 0
> > New transponder/channel found: #59: 0
> > New transponder/channel found: #60: 0
> > New transponder/channel found: #61: 0
> > New transponder/channel found: #62: 0
> > New transponder/channel found: #63: 0
> > New transponder/channel found: #64: 0
> > New transponder/channel found: #65: 0
> > New transponder/channel found: #66: 0
> > New transponder/channel found: #67: 0
> > New transponder/channel found: #68: 0
> > New transponder/channel found: #69: 0
> > New transponder/channel found: #70: 0
> > New transponder/channel found: #71: 0
> > New transponder/channel found: #72: 0
> > New transponder/channel found: #73: 0
> > New transponder/channel found: #74: 0
> > New transponder/channel found: #75: 0
> > Scanning frequency #2 65000
> >(0x00) Signal= -69.00dBm
> > Scanning frequency #3 73800
> >(0x00) Signal= -76.00dBm
> > Scanning frequency #4 57800
> > Lock   (0x1f) Signal= -76.00dBm C/N= 27.25dB
> > *** Erro

Bug#859141: tigervnc-standalone-server: Wrapper script is unreasonably intolerant of slightly slow or busy systems

[Matthew Gabeler-Lee]

Package: tigervnc-standalone-server
Version: 1.7.0+dfsg-6
Severity: normal

The /usr/bin/tigervncserver wrapper script gives up and kills the server it
just started if it doesn't have its VNC-TCP and X11-unix sockets up and
running within one second.

If a machine is a bit bogged down, this can prevent starting the server at
all, for no good reason.

It seems like 10-60 seconds would be a much more reasonable timeout here.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
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 tigervnc-standalone-server depends on:
ii  libaudit1 1:2.6.7-1
ii  libc6 2.24-9
ii  libgcc1   1:6.3.0-10
ii  libgcrypt20   1.7.6-1
ii  libgl1-mesa-glx [libgl1]  13.0.5-1
ii  libgnutls30   3.5.8-3
ii  libjpeg62-turbo   1:1.5.1-2
ii  libpam0g  1.1.8-3.5
ii  libpixman-1-0 0.34.0-1
ii  libselinux1   2.6-3+b1
ii  libstdc++66.3.0-10
ii  libsystemd0   232-19
ii  libx11-6  2:1.6.4-3
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.2-3
ii  libxfont2 1:2.0.1-3
ii  libxshmfence1 1.2-1+b2
pn  perl:any  
ii  x11-xkb-utils 7.7+3+b1
ii  xauth 1:1.0.9-1+b2
ii  xkb-data  2.19-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages tigervnc-standalone-server recommends:
ii  libgl1-mesa-dri13.0.5-1
pn  tigervnc-common
ii  x11-xserver-utils  7.7+7+b1
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-100dpi1:1.0.4+nmu1
ii  xfonts-75dpi 1:1.0.4+nmu1
ii  xfonts-scalable  1:1.0.3-1.1

-- no debconf information

Bug#858915: unblock: logtool/1.2.8-9

[Niels Thykier]

Control: tags -1 moreinfo

Wouter Verhelst:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package logtool
> 
> logtool hadn't been updated in almost 7 years (upstream hasn't been
> active, and the package seemed to still work), but the recent binNMU
> that was done to rebuild with PIE triggered an RC bug in the upgrade
> path.
> 
> The main fix is a rework of the configuration system to fix the
> above-mentioned RC bug, but while at it, I refreshed the autotools
> build system (which required a few changes to configure.in to make it
> work with modern autotools) and bumped the debhelper compat level as
> well as the Standards-Version.
> 
> wouter@gangtai:~/debian$ debdiff logtool_1.2.8-8.dsc logtool_1.2.8-9.dsc | 
> diffstat
>  Makefile  |1 
>  conf/logtool.conf |   30 -
>  conf/logtool.conf.in  |   30 -
>  config.h  |   96 +++--
>  configure.in  |6 
>  debian/dirs   |6 
>  debian/preinst|   17 
>  install-sh|  704 
> +-
>  logtool-1.2.8/debian/changelog|   23 +
>  logtool-1.2.8/debian/compat   |2 
>  logtool-1.2.8/debian/control  |2 
>  logtool-1.2.8/debian/logtool.dirs |   21 +
>  logtool-1.2.8/debian/postinst |   16 
>  logtool-1.2.8/src/Makefile|   22 -
>  src/Makefile.in   |   19 -
>  15 files changed, 665 insertions(+), 330 deletions(-)
> 
> full debdiff attached
> 
> unblock logtool/1.2.8-9
> 
> [...]

Hi Wouter,

Thanks for fixing this bug.

I got two remarks for this upload:

 1) Please undo the compat bump; it causes actions at a distance that
hard to reason about from a diff and as such we have it as a defacto
policy to reject that kind of change

 2) src/Makefile makes an explicit reference to your build path
(/home).  Given it is autotools, I assume that file replaced during
build and therefore it will "just work(tm)".

Without the compat bump (and you signing off on the src/Makefile thing),
I am happy to accept the change.

Thanks,
~Niels

Bug#859084: unblock: win32-loader/0.8.2

[Cyril Brulebois]

Didier 'OdyX' Raboud  (2017-03-30):
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock-udeb package win32-loader 0.8.2 as it fixes a FTBFS
> in stretch (and is always blocked because of the manual migration to
> be done by ftpmasters):
> 
> >   * Fix dpkg-query calls to use source:* for Version and Package directly
> > - Add Build-Dependency on dpkg (>= 1.16.2) for that support
> > - Fixes the FTBFS revealed by loadlin's binNMU
> > (Closes: #858104)

Fun. :)

> debdiff is attached.
> 
> ftpmaster: please copy debian/tools/win32-loader/unstable into …/testing 
> 
> unblock-udeb win32-loader/0.8.2

ACK.


KiBi.


signature.asc
Description: Digital signature

Bug#858943: unblock: systemd/232-22

[Niels Thykier]

Control: tags -1 confirmed

Michael Biebl:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hello release team,
> 
> since 232-19, a couple of fixes accumulated which we'd like to see enter
> testing/stretch
> 
> As this potentially affects the installer, I've CC debian-boot aka KiBi.
> 
> A complete debdiff is attached.
> 

Ack from here, awaiting KiBi for a d-i ack then.

~Niels

(leaving the rest of the mail for his sake)

> The changelog + annotations follows. Sorry if it's a bit verbose.
> 
>> systemd (232-22) unstable; urgency=medium
>>
>>   [ Martin Pitt ]
>>   * resolved: Disable DNSSEC by default on stretch and zesty.
>> Both Debian stretch and Ubuntu zesty are close to releasing, switch to
>> DNSSEC=off by default for those. Users can still turn it back on with
>> DNSSEC=allow-downgrade (or even "yes").
> 
> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?h=stretch&id=3361c8f55c9fe2d6a4cb232693728845480fb9ac
> 
> (not relevant for the installer)
> 
> According to Martin, the DNSSEC in resolved still triggers too many
> issues so it's not safe to enable by default.
> Do note, that resolved in Debian is not enabled by default though. So
> it's a low risk change which errs on the side of being conservative.
> 
>>   [ Michael Biebl ]
>>   * Add Conflicts against hal.
>> Since v183, udev no longer supports RUN+="socket:". This feature is
>> still used by hal, but now generates vast amounts of errors in the
>> journal. Thus force the removal of hal by adding a Conflicts to the udev
>> package. This is safe, as hal is long dead and no package depends on it
>> anymore.
> 
> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?h=stretch&id=29757891624a73702b1de4b4d5ebd70d721357db
> 
> (not relevant for the installer)
> 
> This is a potentially odd one. hal has been removed in jessie, but
> apparently some users still have it installed after upgrading from
> previous releases. This now leads to massive amounts of error messages
> in the journal (basically on every uevent). So forcing the removal of
> hal seems justified.
> There is a slight catch: the Conflicts could potentially lead to udev
> not being upgraded or udev removed in favour of keeping hal.
> But: since no other package depends on hal anymore and lots of packages
> depend on udev this scenario is rather unlikely. I did several upgrade
> tests and was not able to trigger such a condition. In all cases, hal
> was removed as intended.
> 
>>   [ Dimitri John Ledkov ]
>>   * Adjust pkgconfig files to point at rootlibdir.
>> The .so symlinks got moved to rootlibdir in v232 so the .pc files for
>> libudev and libsystemd need to be adjusted accordingly. Otherwise we
>> break cross compilation. (LP: #1674201)
> 
> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?h=stretch&id=5c41fe140cb0b09cb8e31380538476f500d4921f
> 
> (not relevant for the installer)
> 
> A rather obvious 3 line fix
> 
> 
>>  -- Michael Biebl   Tue, 28 Mar 2017 21:23:30 +0200
>>
>> systemd (232-21) unstable; urgency=medium
>>
>>   * resolved: Downgrade "processing query..." message to debug.
>> It doesn't really add much value in normal operation and just spams the
>> log. (Closes: #858197)
> 
> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?h=stretch&id=3e44b1d677159e91cc5cc105a76469498ef74965
> 
> (not relevant for the installer)
> 
> While resolved is not enabled by default in Debian, if you do it
> manually, it was spamming the journal. It's a low risk one-line change.
> 
>>   * Do not throw a warning in emergency and rescue mode if plymouth is not
>> installed.
>> Ideally, plymouth should only be referenced via dependencies, not
>> ExecStartPre. This at least avoids the confusing error message on
>> minimal installations that do not carry plymouth.
> 
> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?h=stretch&id=78102d62b90d97574ae107799b0dcd2c6483c061
> 
> (not relevant for the installer)
> 
> Lot's of users where confused by error messages in the journal, if
> plymouth is not installed (which is the default in Debian).
> While the error message is harmless, it's better to simply avoid it
> altogether.
> 
>>   * rules: Allow SPARC vdisk devices when identifying CD drives
>> (Closes: #858014)
> 
> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?h=stretch&id=99e1327b3883fcc5632af7aad4c19ce93e2a55b1
> 
> (might be relevant for the installer)
> 
> Requested by a porter, didn't see a good reason not to include it.
> Low-risk change.
> 
> 
>>  -- Michael Biebl   Tue, 21 Mar 2017 19:52:17 +0100
>>
>> systemd (232-20) unstable; urgency=medium
>>
>>   [ Martin Pitt ]
>>   * debian/gbp.conf: Switch to "stretch" branch
> 
> ignore, not relevant
> 
>>   * udev: Fix /dev/disk/by-path aliases for virtio disks. (Closes: #856558)
> 
> https://anonscm.debian.org/git/pk

Bug#858795: RFS: python-zxcvbn/4.4.14-0.1 [ITA]

[sab]

I see that the package at mentors has version 4.4.14-0.1
so I retitle the RFS to match that version.


Hi, thank you for having changed the title, I had forgotten to do it.


probably a lot of stuff still need changes, but I can address it only if you 
fix the above.


Hi Granfranco

I changed various things, what else can I do? Regards, Sab

Bug#856626: Pending fixes for bugs in the lucene-solr package

[pkg-java-maintainers]

tag 856626 + pending
thanks

Some bugs in the lucene-solr package are closed in revision
02a1b0e68a97c67864d7747e045233c2b33a1560 in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/lucene-solr.git/commit/?id=02a1b0e

Commit message:

Remove obsolete Resources className directive as it does not work with 
Tomcat8.

Closes: #856626
Thanks: Matthias Liertzer for the report.

Bug#859020: unblock: ruby-bootstrap-sass/3.3.5.1-4

[Niels Thykier]

Control: tags -1 moreinfo

Antonio Terceiro:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package ruby-bootstrap-sass
> 
> This release fixes the integration with compass.
> 
> the debdiff against the package in testing is attached. You will notice
> that it is mostly removing stuff that was wrong or unecessary.
> 
> There were a few changes that were staged in git for a while and ended
> up not being properly documented in the changelog, by my mistake:
> 
> - debhelper compatibility bumped from 7 to 9
> - Standards-Version bump
> - https:// in Vcs-*
> - removal of commented-out build dependencies
> 
> The only of those that is not cosmetic is the debhelper compatibility
> level, but almost all of the other Ruby packages are at 9 with no bad
> consequences, so there are no real consequences.
> 
> unblock ruby-bootstrap-sass/3.3.5.1-4
> 
> [...]

Hi,

Thanks for the changeset.

Unfortunately, as a matter of policy I would strongly prefer if the
compat bump was undone.  They have "actions at a distance" that are hard
to reason about in general, so it is easier to simply say "no" than
manually verify it.

Without the compat bump, I am happy to accept the other changes.

Thanks,
~Niels

Bug#859138: java.lang.UnsupportedOperationException: The BROWSE action is not supported on the current platform!

[Thorsten Glaser]

On Thu, 30 Mar 2017, Thorsten Glaser wrote:

> tglase@tglase-nb:~ $ java -jar testcase.jar
> java.lang.UnsupportedOperationException: The BROWSE action is not supported 
> on the current platform!

Note that both sensible-browser and xdg-open show the website,
and that this generally works in other applications (e.g. in
MuseScore, selecting the online handbook menu point).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#859008: dvb-tools: dvbv5-scan segfaults with DVB-T2 HD service that just started in Germany

[Gregor Jasny]

Hello Mauro,

could you please take a look?

Thanks,
Gregor

On 3/30/17 9:36 PM, Frank Heckenbach wrote:
> I got the same problem, only on some channels though, e.g. ZDF using
> this input:
> 
> [CH34]
> DELIVERY_SYSTEM = DVBT2
> FREQUENCY = 57800
> BANDWIDTH_HZ = 800
> MODULATION = QAM/16
> 
> *** Error in `dvbv5-scan': malloc(): memory corruption: 0x00fe13c0 ***
> 
> I did some debugging with gdb and valgrind (using the upstream
> version v4l-utils-1.12.3.tar.bz2 since I needed to recompile anyway
> to get debug info).
> 
> I found an invalid access in descriptors/desc_t2_delivery.c:55
> 
>   memcpy(&d->centre_frequency, p, len);
> 
> Before this, dvb_extension_descriptor_init had
> 
>   desc_type == 4 (T2_delivery_system_descriptor)
> 
> and
> 
>   dvb_ext_descriptors[4].size == sizeof(struct dvb_desc_t2_delivery) (23)
> 
> so it allocated only 23 bytes, but didn't change desc_len which was
> still 68, causing the overflow.
> 
> Setting desc_len to 23 didn't help, but just allocating 68 bytes
> did:
> 
> --- v4l-utils-1.12.3/lib/libdvbv5/descriptors/desc_extension.c
> +++ v4l-utils-1.12.3/lib/libdvbv5/descriptors/desc_extension.c
> @@ -149,7 +149,7 @@
>   if (!size)
>   size = desc_len;
>  
> - ext->descriptor = calloc(1, size);
> + ext->descriptor = calloc(1, desc_len);
>  
>   if (init) {
>   if (init(parms, p, ext, ext->descriptor) != 0)
> 
> NOTE: This is probably not a proper fix, just a bandaid. Since
> scanning channels is mostly a one-off job, I'm happy now that I got
> my channels list and don't plan to invest more time resarching the
> issue.
> 

Bug#859108: unblock: mapdamage/2.0.6+dfsg-2

[Andreas Tille]

Hi Niels

On Thu, Mar 30, 2017 at 07:03:00PM +, Niels Thykier wrote:
> @Nadiya: Many thanks for your work! :)

+1
 
> @Andreas: Thanks for reverting the dh 10 change.

:-)
 
> I have unblocked the package; it is clearly in a much better state than
> previously and I only had a minor remark.
> 
> In d/control, I noticed the following Recommends:
> 
> + libopenblas-dev | [...] | libblas.so,
> + libopenblas-dev | [...] | liblapack.so
> 
> There are no packages names like this (the lib*.so) AFAICT, so these are
> redundant.  Please remove them in a future upload.

These are virtual packages provided by every single dependency.

Kind regards and thanks for your release team work

   Andreas.

-- 
http://fam-tille.de

Bug#859135: CVE-2016-10127: XXE attack via crafted SAML XML request or response

[Salvatore Bonaccorso]

On Thu, Mar 30, 2017 at 09:27:56PM +0200, Salvatore Bonaccorso wrote:
> On Thu, Mar 30, 2017 at 02:40:58PM -0400, Antoine Beaupre wrote:
> > Package: python-pysaml2
> > X-Debbugs-CC: t...@security.debian.org 
> > secure-testing-t...@lists.alioth.debian.org
> > Severity: normal
> > Tags: security
> > 
> > Hi,
> > 
> > the following vulnerability was published for python-pysaml2.
> > 
> > CVE-2016-10127[0]:
> > | PySAML2 allows remote attackers to conduct XML external entity (XXE)
> > | attacks via a crafted SAML XML request or response.
> 
> As a side note: It can be mentioned for this issue though that a
> proper fix would be appropriate in the underlying issue in
> src:libxml2. Please though see the whole discussion on oss-security
> around the CVE assignment for details.

And https://bugzilla.redhat.com/show_bug.cgi?id=1411794#c12.

Salvatore

Bug#859140: /usr/bin/xdg-open[938]: : can't execute: Is a directory

[Thorsten Glaser]

Package: xdg-utils
Version: 1.1.1-1
Severity: normal

tglase@tglase-nb:~ $ xdg-open http://www.mirbsd.org/
/usr/bin/xdg-open[938]: : can't execute: Is a directory

It still _works_ as is, but this error message is weird.

This is caused by line 669:
command_exec=`which $command 2>/dev/null`

Watch it:

tglase@tglase-nb:~ $ echo "<$(which /usr/feistermops/380/firefox/firefox)>"; 
echo $?
<>
0

The fix is obvious and trivial:

-command_exec=`which $command 2>/dev/null`
+test -x "$command" && command_exec=$command || command_exec=$(which 
$command 2>/dev/null)

The complete fix is a bit more involved:

--- /usr/bin/xdg-open~  2017-03-30 21:36:19.403450698 +0200
+++ /usr/bin/xdg-open   2017-03-30 21:37:15.100849964 +0200
@@ -664,9 +664,13 @@
   file="$dir/`echo $default | sed -e 's|-|/|'`"
 fi
 
+local command command_exec=""
+
 if [ -r "$file" ] ; then
 command="$(get_key "${file}" "Exec" | first_word)"
-command_exec=`which $command 2>/dev/null`
+test -x "$command" && command_exec=$command || command_exec=$(which 
$command 2>/dev/null)
+fi
+if [ -n "$command_exec" ] && [ -x "$command_exec" ] ; then
 icon="$(get_key "${file}" "Icon")"
 # FIXME: Actually LC_MESSAGES should be used as described in
 # 
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s04.html


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

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
pn  libfile-mimeinfo-perl  
pn  libnet-dbus-perl   
ii  libx11-protocol-perl   0.56-7
ii  x11-utils  7.7+3+b1
ii  x11-xserver-utils  7.7+7+b1

Versions of packages xdg-utils suggests:
pn  gvfs-bin  

-- no debconf information

Bug#859008: dvb-tools: dvbv5-scan segfaults with DVB-T2 HD service that just started in Germany

[Frank Heckenbach]

I got the same problem, only on some channels though, e.g. ZDF using
this input:

[CH34]
DELIVERY_SYSTEM = DVBT2
FREQUENCY = 57800
BANDWIDTH_HZ = 800
MODULATION = QAM/16

*** Error in `dvbv5-scan': malloc(): memory corruption: 0x00fe13c0 ***

I did some debugging with gdb and valgrind (using the upstream
version v4l-utils-1.12.3.tar.bz2 since I needed to recompile anyway
to get debug info).

I found an invalid access in descriptors/desc_t2_delivery.c:55

  memcpy(&d->centre_frequency, p, len);

Before this, dvb_extension_descriptor_init had

  desc_type == 4 (T2_delivery_system_descriptor)

and

  dvb_ext_descriptors[4].size == sizeof(struct dvb_desc_t2_delivery) (23)

so it allocated only 23 bytes, but didn't change desc_len which was
still 68, causing the overflow.

Setting desc_len to 23 didn't help, but just allocating 68 bytes
did:

--- v4l-utils-1.12.3/lib/libdvbv5/descriptors/desc_extension.c
+++ v4l-utils-1.12.3/lib/libdvbv5/descriptors/desc_extension.c
@@ -149,7 +149,7 @@
if (!size)
size = desc_len;
 
-   ext->descriptor = calloc(1, size);
+   ext->descriptor = calloc(1, desc_len);
 
if (init) {
if (init(parms, p, ext, ext->descriptor) != 0)

NOTE: This is probably not a proper fix, just a bandaid. Since
scanning channels is mostly a one-off job, I'm happy now that I got
my channels list and don't plan to invest more time resarching the
issue.

Bug#859139: RFS: synergy/1.4.16-1+deb8u1

[Joshua Honeycutt]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "synergy" to be uploaded for
jessie. This is a proposed update and was approved by the release team
in #857434 ( https://bugs.debian.org/857434 )

   Package name: synergy
   Version : 1.4.16-1+deb8u1
   Upstream Author : Symless
   URL : https://symless.com/synergy/
   License : GPL-2
   Section : x11

It builds the binary package:

   synergy - Share mouse, keyboard and clipboard over the network

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

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

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

   dget -x 
https://mentors.debian.net/debian/pool/main/s/synergy/synergy_1.4.16-1+deb8u1.dsc

More information about synergy can be obtained from
https://symless.com/synergy/

Changes since the last upload:

  * Added ensure_non00_cursor.patch to fix a crash when synergyc starts.  
Closes: #854567

Regards,
Joshua Honeycutt

Bug#859135: CVE-2016-10127: XXE attack via crafted SAML XML request or response

[Salvatore Bonaccorso]

On Thu, Mar 30, 2017 at 02:40:58PM -0400, Antoine Beaupre wrote:
> Package: python-pysaml2
> X-Debbugs-CC: t...@security.debian.org 
> secure-testing-t...@lists.alioth.debian.org
> Severity: normal
> Tags: security
> 
> Hi,
> 
> the following vulnerability was published for python-pysaml2.
> 
> CVE-2016-10127[0]:
> | PySAML2 allows remote attackers to conduct XML external entity (XXE)
> | attacks via a crafted SAML XML request or response.

As a side note: It can be mentioned for this issue though that a
proper fix would be appropriate in the underlying issue in
src:libxml2. Please though see the whole discussion on oss-security
around the CVE assignment for details.

Regards,
Salvatore

Bug#859059: keyboard-configuration: many mac keymap in keyboard-configuration are faulty

[Anton Zinoviev]

forcemerge 535834 859059
thanks

On Wed, Mar 29, 2017 at 10:28:42PM +0200, raphael wrote:
>
> I have a macbook pro with us keymap, I tried different layouts 
> available in keyboard-configuration to get accents, but ended with Can 
> not find "mac" in "macintosh_vndr/us". or Can not find "altgr-intl" in 
> "macintosh_vndr/us". and No Symbols named "altgr-intl" in the include 
> file "macintosh_vndr/us" or No Symbols named "mac" in the include file 
> "macintosh_vndr/us"
> 
> I ended up copying the altgr part of the pc keyboard (found in 
> /usr/share/X11/xkb/symbols) to the macintosh one. I already had the 
> same kind of problem with mac french azerty keyboard. I think either 
> the /usr/share/X11/xkb/symbols/macintosh_vndr files should be 
> corrected or choices in the keyboard-configuration setup reduced to 
> what's really available (it took me quite a long time to understand 
> why I couldn't get the accents though everything looked fine).

Yes, this is an unfortunate bug which is reported from time to time.  
Unfortunately, it can not be fixed because of

https://bugs.freedesktop.org/show_bug.cgi?id=33670

Anton Zinoviev

Bug#859138: java.lang.UnsupportedOperationException: The BROWSE action is not supported on the current platform!

[Thorsten Glaser]

Package: openjdk-8-jre-headless
Version: 8u121-b13-4
Severity: normal

tglase@tglase-nb:~ $ cat >testcase.java <<\EOF
import java.awt.Desktop;
import java.net.URI;

public class testcase {
public static void main(String[] args) {
try {   
Desktop.getDesktop().browse(new 
URI("http://www.mirbsd.org/";));
} catch (Exception e) {
System.out.println(e);
}
}
}
EOF
tglase@tglase-nb:~ $ javac testcase.java
tglase@tglase-nb:~ $ jar -cvfe testcase.jar testcase testcase.class
added manifest
adding: testcase.class(in = 686) (out= 448)(deflated 34%)
tglase@tglase-nb:~ $ java -jar testcase.jar
java.lang.UnsupportedOperationException: The BROWSE action is not supported on 
the current platform!


This works on Windows®, and some upstream author is now
requiring this unfortunately, reporting it also works
on e.g. Debian-derivate-that-cannot-be-named.

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

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

Versions of packages openjdk-8-jre-headless depends on:
ii  ca-bundle [ca-certificates-java]  20170309tarent1
ii  java-common   0.58
ii  libc6 2.24-9
ii  libcups2  2.2.1-8
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3+b2
ii  libgcc1   1:6.3.0-10
ii  libjpeg62-turbo   1:1.5.1-2
ii  liblcms2-22.8-4
ii  libnss3   2:3.26.2-1
ii  libpcsclite1  1.8.20-1
ii  libstdc++66.3.0-10
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxrender1   1:0.9.10-1
ii  libxtst6  2:1.2.3-1
ii  multiarch-support 2.24-9
ii  util-linux2.29.2-1
ii  zlib1g1:1.2.8.dfsg-5

openjdk-8-jre-headless recommends no packages.

Versions of packages openjdk-8-jre-headless suggests:
ii  fonts-dejavu-extra 2.37-1
pn  fonts-indic
ii  fonts-ipafont-gothic   00303-16
ii  fonts-ipafont-mincho   00303-16
pn  libnss-mdns
pn  ttf-wqy-microhei | ttf-wqy-zenhei  

-- no debconf information

Bug#858381: Openvpn inside systemd-nspawn stops shutdown of container

[Daniel Schröter]

On 03/27/2017 10:58 AM, Alberto Gonzalez Iniesta wrote:
> In order to use upstream's systemd unit files, you have to move your
> configuration to /etc/openvpn/server and enable it with:
> systemctl enable openvpn-server@server

*ups* *sorry*
My /etc/openvpn/server.conf is a (soft) link
root@openvpn:~# ll /etc/openvpn/server.conf
lrwxrwxrwx 1 root root 18 Mar 17 20:34 /etc/openvpn/server.conf ->
server/server.conf

Doesn't make sense. Just to confuse you and me ;-)
I have delete it.

Bye

Bug#859133: unblock: pcre3/2:8.39-3

[Niels Thykier]

Control: tags -1 confirmed

Salvatore Bonaccorso:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi
> 
> (Know this is somewhere in a thread already, but wanted to make an
> explicit unblock request, Cyril Brulebois X-Debbugs-CC'ed):
> 
> Please unblock package pcre3
> 
> The upload fixes CVE-2017-7186: invalid Unicode property lookup may
> cause denial of service (Closes: #858238)
> 
> unblock pcre3/2:8.39-3
> 
> Thanks to the whole team for your hard work on the release!
> 
> Regards,
> Salvatore
> 

Ack from here - CC'ing KiBi for a d-i ack.

Thanks,
~Niels

Bug#690942: python-pgmagick: Image.attribute does not set the attribute but instead appends to it

[Juraj Komačka]

Hi all,

this is beahviour described in GM's docs - see 
http://www.graphicsmagick.org/Magick++/Image.html#attribute


Retested with libgraphicsmagick++1 (=1.3.25-8) and python-pgmagick 
(=0.6.4-1) from Stretch.


> If the named attribute already exists, the provided text is appended 
to the existing attribute text.


In this unreleased commit - 
http://hg.code.sf.net/p/graphicsmagick/code/rev/c9067f61966c was 
implemented functionality required to remove image attributes
> Pass NULL to remove an existing text attribute, or to restart the 
text attribute from scratch.
so hopefully will be present in next GM release (after 1.3.25) - all 
this applies to the C++ library.


After that maintainer of python-pgmagick should be made aware of this 
new functionality (by filling an issue at 
https://github.com/hhatto/pgmagick) to make this functionality available 
in Python bindings.

Bug#859087: [Pkg-freeradius-maintainers] Bug#859087: freeradius-mysql.postintst reloads config of not-running-now freeradius

[Michael Stapelberg]

The following patch should address this issue:

--- i/debian/freeradius-mysql.postinst
+++ w/debian/freeradius-mysql.postinst
@@ -5,7 +5,11 @@ set -e

 case "$1" in
   configure)
-invoke-rc.d freeradius force-reload
+# Only reload when FreeRADIUS is running, see #859087
+if invoke-rc.d freeradius status 1>/dev/null 2>&1
+then
+  invoke-rc.d freeradius force-reload
+fi
 ;;
 esac

I’ll add it for the next upload, but that will take a while since Debian is
currently in a freeze.


On Thu, Mar 30, 2017 at 9:52 AM, Mihail Vasilev  wrote:

> Package: freeradius-mysql
> Version: 2.2.5+dfsg-0.2
> Severity: normal
>
> Dear Maintainer,
>
> I am running a master-slave installation of 2 debian servers, on which the
> filesystem with database is mounted only on master node (this is ensured by
> heartbeat). Thus, I have no running mysql on slave host.
> As a result, when I try to update freeradius-mysql package, it tries to
> make freeradius reload it's config without thinking that it's not running
> and
> will cause error, as we are operating on the slave host (and directories
> for log files, for example, are not accessible right now).
>
> The result was in aptitude marking package as broken and tries to rerun
> freeradius-mysql.postinst script on every other package install/update
> operation.
>
> As it's quite annoying, I've just commented out reload line in postinst
> script
> and things became right for me.
>
> But I think it would be wiser for the upstream to add some check in
> .postinst
> scripts, which call force-reload action on service only if it's already
> running.
> If freeradius is not running right now - it may be done on purpose.
>
> I've checked .postinst script in 3.0.12 release of the package - it became
> much shorter, but there is stil no check in this place.
>
>
> -- System Information:
> Debian Release: 8.7
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages freeradius-mysql depends on:
> ii  freeradius2.2.5+dfsg-0.2
> ii  libc6 2.19-18+deb8u7
> ii  libmysqlclient18  5.5.54-0+deb8u1
> ii  zlib1g1:1.2.8.dfsg-2+b1
>
> freeradius-mysql recommends no packages.
>
> freeradius-mysql suggests no packages.
>
> -- debconf-show failed
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-
> freeradius-maintainers
>



-- 
Best regards,
Michael

Bug#859136: CVE-2016-1566: XSS vulnerability in file browser

[Antoine Beaupre]

Package: guacamole-client
X-Debbugs-CC: t...@security.debian.org 
secure-testing-t...@lists.alioth.debian.org
Severity: normal
Tags: security
Version: 0.9.9+dfsg-1

Hi,

the following vulnerability was published for guacamole.

CVE-2016-1566[0]:
| Cross-site scripting (XSS) vulnerability in the file browser in
| Guacamole 0.9.8 and 0.9.9, when file transfer is enabled to a location
| shared by multiple users, allows remote authenticated users to inject
| arbitrary web script or HTML via a crafted filename.  NOTE: this
| vulnerability was fixed in guacamole.war on 2016-01-13, but the
| version number was not changed.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-1566
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1566


signature.asc
Description: PGP signature

Bug#859135: CVE-2016-10127: XXE attack via crafted SAML XML request or response

[Antoine Beaupre]

Package: python-pysaml2
X-Debbugs-CC: t...@security.debian.org 
secure-testing-t...@lists.alioth.debian.org
Severity: normal
Tags: security

Hi,

the following vulnerability was published for python-pysaml2.

CVE-2016-10127[0]:
| PySAML2 allows remote attackers to conduct XML external entity (XXE)
| attacks via a crafted SAML XML request or response.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10127
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10127

Please adjust the affected versions in the BTS as needed.


signature.asc
Description: PGP signature

Bug#859134: unblock: ruby-httpclient/2.7.1-1.1

[Paul Gevers]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package ruby-httpclient

I fixed RC bug #834686 which is about FTBFS due to errors in the test-suite. I
applied similar fixes as are already available in the package for other
instances of the same issue. The package just missed these updates for
additions in new upstream releases.

Debdiff attached.

unblock ruby-httpclient/2.7.1-1.1

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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAljdT3AACgkQnFyZ6wW9
dQrTSwf/aSZZmrWsVaG3Z0+KA7cyA3brQ0UWhBPqA5oiDnSO/luhgMiFiy3B5BAz
YUsc9q9/WlPgtlzGXD+hZkGeIXqdvcxLYUiSs1Lk5mpKtiYWAfqJDRsudNjpVcY3
uNAgkgK1QQT7pcG8u7Axs/uOzVZj4kF6HseKCSL4g4D7mYBUa00dPByBNTrPiOXn
zeS8zMwgd0HmP+/hFdcu0QY7J9ombMC9qlii9M9lLEiienKqSrwfIC1UTD6fdBsN
L+FnUva8CTfk+k+6VwV13JCk1BknwfjERgdcJ2NADE+88zZKTC+f+sF54d45S8Vb
CfuxAVojE1PH1aZrt0L99K0AZ3fb+Q==
=dEFp
-END PGP SIGNATURE-
diff -Nru ruby-httpclient-2.7.1/debian/changelog 
ruby-httpclient-2.7.1/debian/changelog
--- ruby-httpclient-2.7.1/debian/changelog  2016-02-29 21:18:36.0 
+0100
+++ ruby-httpclient-2.7.1/debian/changelog  2017-03-29 20:38:15.0 
+0200
@@ -1,3 +1,12 @@
+ruby-httpclient (2.7.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update 0001-Fix-port-allocation-in-tests.patch and
+0003-Try-to-wait-until-socket-is-free.patch to include missing
+instances of port 0 added in upstream 2.6.0.1-1~exp1 (Closes: #834686)
+
+ -- Paul Gevers   Wed, 29 Mar 2017 20:38:15 +0200
+
 ruby-httpclient (2.7.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
ruby-httpclient-2.7.1/debian/patches/0001-Fix-port-allocation-in-tests.patch 
ruby-httpclient-2.7.1/debian/patches/0001-Fix-port-allocation-in-tests.patch
--- 
ruby-httpclient-2.7.1/debian/patches/0001-Fix-port-allocation-in-tests.patch
2016-02-29 21:18:36.0 +0100
+++ 
ruby-httpclient-2.7.1/debian/patches/0001-Fix-port-allocation-in-tests.patch
2017-03-29 20:38:15.0 +0200
@@ -83,3 +83,23 @@
:AccessLog => [],
:DocumentRoot => DIR,
:SSLEnable => true,
+@@ -293,7 +293,7 @@ private
+ @server = WEBrick::HTTPServer.new(
+   :BindAddress => "localhost",
+   :Logger => logger,
+-  :Port => 0,
++  :Port => 50001,
+   :AccessLog => [],
+   :DocumentRoot => DIR,
+   :SSLEnable => true,
+--- a/test/test_jsonclient.rb
 b/test/test_jsonclient.rb
+@@ -69,7 +69,7 @@ class TestJSONClient < Test::Unit::TestC
+ @server = WEBrick::HTTPServer.new(
+   :BindAddress => "localhost",
+   :Logger => @logger,
+-  :Port => 0,
++  :Port => 5,
+   :AccessLog => [],
+   :DocumentRoot => File.dirname(File.expand_path(__FILE__))
+ )
diff -Nru 
ruby-httpclient-2.7.1/debian/patches/0003-Try-to-wait-until-socket-is-free.patch
 
ruby-httpclient-2.7.1/debian/patches/0003-Try-to-wait-until-socket-is-free.patch
--- 
ruby-httpclient-2.7.1/debian/patches/0003-Try-to-wait-until-socket-is-free.patch
2016-02-29 21:18:36.0 +0100
+++ 
ruby-httpclient-2.7.1/debian/patches/0003-Try-to-wait-until-socket-is-free.patch
2017-03-29 20:38:15.0 +0200
@@ -112,3 +112,24 @@
end
  
def setup_server_with_ssl_version(ssl_version)
+@@ -310,6 +313,9 @@ private
+   )
+ end
+ @server_thread = start_server_thread(@server)
++  rescue Errno::EADDRINUSE
++sleep 1
++retry
+   end
+ 
+   def do_hello(req, res)
+--- a/test/test_jsonclient.rb
 b/test/test_jsonclient.rb
+@@ -76,5 +76,8 @@ class TestJSONClient < Test::Unit::TestC
+ @serverport = @server.config[:Port]
+ @server.mount('/json', JSONServlet.new(@server))
+ @server_thread = start_server_thread(@server)
++  rescue Errno::EADDRINUSE
++sleep 1
++retry
+   end
+ end

Bug#834686: ruby-httpclient: diff for NMU version 2.7.1-1.1

[Paul Gevers]

Hi Antonio,

On 03/30/17 14:40, Antonio Terceiro wrote:
> Are you also going to request the unblock, or do you want me to do it?

I'll do that now (after checking it isn't there yet).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#859133: unblock: pcre3/2:8.39-3

[Salvatore Bonaccorso]

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

Hi

(Know this is somewhere in a thread already, but wanted to make an
explicit unblock request, Cyril Brulebois X-Debbugs-CC'ed):

Please unblock package pcre3

The upload fixes CVE-2017-7186: invalid Unicode property lookup may
cause denial of service (Closes: #858238)

unblock pcre3/2:8.39-3

Thanks to the whole team for your hard work on the release!

Regards,
Salvatore
diff -Nru pcre3-8.39/debian/changelog pcre3-8.39/debian/changelog
--- pcre3-8.39/debian/changelog 2017-02-17 15:56:09.0 +0100
+++ pcre3-8.39/debian/changelog 2017-03-21 23:03:19.0 +0100
@@ -1,3 +1,10 @@
+pcre3 (2:8.39-3) unstable; urgency=high
+
+  * CVE-2017-7186: invalid Unicode property lookup may cause denial of
+service (Closes: #858238)
+
+ -- Matthew Vernon   Tue, 21 Mar 2017 22:03:19 +
+
 pcre3 (2:8.39-2.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru pcre3-8.39/debian/patches/series pcre3-8.39/debian/patches/series
--- pcre3-8.39/debian/patches/series2017-02-17 15:56:09.0 +0100
+++ pcre3-8.39/debian/patches/series2017-03-21 23:04:04.0 +0100
@@ -6,3 +6,4 @@
 no_jit_x32_powerpcspe.patch
 Disable_JIT_on_sparc64.patch
 CVE-2017-6004.patch
+upstream-fix-for-cve-2017-7186-upstream-
diff -Nru pcre3-8.39/debian/patches/upstream-fix-for-cve-2017-7186-upstream- 
pcre3-8.39/debian/patches/upstream-fix-for-cve-2017-7186-upstream-
--- pcre3-8.39/debian/patches/upstream-fix-for-cve-2017-7186-upstream-  
1970-01-01 01:00:00.0 +0100
+++ pcre3-8.39/debian/patches/upstream-fix-for-cve-2017-7186-upstream-  
2017-03-21 23:04:04.0 +0100
@@ -0,0 +1,59 @@
+Description: Upstream fix for CVE-2017-7186 (Upstream rev 1688)
+ Fix Unicode property crash for 32-bit characters greater than 0x10.
+Author: Matthew Vernon 
+X-Dgit-Generated: 2:8.39-3 c4c2c7c4f74d53b263af2471d8e11db88096bd13
+
+---
+
+--- pcre3-8.39.orig/pcre_internal.h
 pcre3-8.39/pcre_internal.h
+@@ -2772,6 +2772,9 @@ extern const pcre_uint8  PRIV(ucd_stage1
+ extern const pcre_uint16 PRIV(ucd_stage2)[];
+ extern const pcre_uint32 PRIV(ucp_gentype)[];
+ extern const pcre_uint32 PRIV(ucp_gbtable)[];
++#ifdef COMPILE_PCRE32
++extern const ucd_record  PRIV(dummy_ucd_record)[];
++#endif
+ #ifdef SUPPORT_JIT
+ extern const int PRIV(ucp_typerange)[];
+ #endif
+@@ -2780,9 +2783,15 @@ extern const int PRIV(ucp_typera
+ /* UCD access macros */
+ 
+ #define UCD_BLOCK_SIZE 128
+-#define GET_UCD(ch) (PRIV(ucd_records) + \
++#define REAL_GET_UCD(ch) (PRIV(ucd_records) + \
+ PRIV(ucd_stage2)[PRIV(ucd_stage1)[(int)(ch) / UCD_BLOCK_SIZE] * \
+ UCD_BLOCK_SIZE + (int)(ch) % UCD_BLOCK_SIZE])
++
++#ifdef COMPILE_PCRE32
++#define GET_UCD(ch) ((ch > 0x10)? PRIV(dummy_ucd_record) : 
REAL_GET_UCD(ch))
++#else
++#define GET_UCD(ch) REAL_GET_UCD(ch)
++#endif 
+ 
+ #define UCD_CHARTYPE(ch)GET_UCD(ch)->chartype
+ #define UCD_SCRIPT(ch)  GET_UCD(ch)->script
+--- pcre3-8.39.orig/pcre_ucd.c
 pcre3-8.39/pcre_ucd.c
+@@ -38,6 +38,20 @@ const pcre_uint16 PRIV(ucd_stage2)[] = {
+ const pcre_uint32 PRIV(ucd_caseless_sets)[] = {0};
+ #else
+ 
++/* If the 32-bit library is run in non-32-bit mode, character values
++greater than 0x10 may be encountered. For these we set up a
++special record. */
++
++#ifdef COMPILE_PCRE32
++const ucd_record PRIV(dummy_ucd_record)[] = {{
++  ucp_Common,/* script */
++  ucp_Cn,/* type unassigned */
++  ucp_gbOther,   /* grapheme break property */
++  0, /* case set */
++  0, /* other case */
++  }};
++#endif
++
+ /* When recompiling tables with a new Unicode version, please check the
+ types in this structure definition from pcre_internal.h (the actual
+ field names will be different):

Bug#859132: unblock: ghostscript/9.20~dfsg-3

[Salvatore Bonaccorso]

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

Hi

Please unblock package ghostscript

The recent upload to unstable of ghostscript fixed CVE-2017-7207, a
NULL pointer dereference vulnerability in mem_get_bits_rectangle
function.

https://security-tracker.debian.org/tracker/CVE-2017-7207

Tracked as #858350 in the BTS (note the changelog did mistyped and
actually referenced the upstream bugzilla bugnumber, but apart the
typo the bug is closed).

unblock ghostscript/9.20~dfsg-3

Regards,
Salvatore
diff -Nru ghostscript-9.20~dfsg/debian/changelog 
ghostscript-9.20~dfsg/debian/changelog
--- ghostscript-9.20~dfsg/debian/changelog  2017-01-25 05:26:10.0 
+0100
+++ ghostscript-9.20~dfsg/debian/changelog  2017-03-21 17:20:00.0 
+0100
@@ -1,3 +1,10 @@
+ghostscript (9.20~dfsg-3) unstable; urgency=medium
+
+  * Fix NULL pointer dereference in mem_get_bits_rectangle().
+Closes: Bug#697676 (CVE-2017-7207). Thanks to Salvatore Bonaccorso.
+
+ -- Jonas Smedegaard   Tue, 21 Mar 2017 17:20:00 +0100
+
 ghostscript (9.20~dfsg-2) unstable; urgency=medium
 
   * Add patch cherry-picked upstream to always print full PWG Raster
diff -Nru ghostscript-9.20~dfsg/debian/patches/020170317~309eca4.patch 
ghostscript-9.20~dfsg/debian/patches/020170317~309eca4.patch
--- ghostscript-9.20~dfsg/debian/patches/020170317~309eca4.patch
1970-01-01 01:00:00.0 +0100
+++ ghostscript-9.20~dfsg/debian/patches/020170317~309eca4.patch
2017-03-21 17:18:22.0 +0100
@@ -0,0 +1,29 @@
+Description: Fix NULL pointer dereference in mem_get_bits_rectangle()
+ Ensure a device has raster memory, before trying to read it.
+ .
+ This is only possible by abusing/mis-using Ghostscript-specific
+ language extensions, so cannot happen in a general PostScript program.
+ .
+ Nevertheless, Ghostscript should not crash. So this commit checks the
+ memory device to see if raster memory has been allocated, before trying
+ to read from it.
+Origin: backport, http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=309eca4
+Author: Ken Sharp 
+Bug: http://bugs.ghostscript.com/show_bug.cgi?id=697676
+Bug-Debian: https://bugs.debian.org/858350
+Bug-CVE: https://security-tracker.debian.org/tracker/CVE-2017-7207
+Bug-CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7207
+Forwarded: yes
+Last-Update: 2017-03-21
+
+--- a/base/gdevmem.c
 b/base/gdevmem.c
+@@ -605,6 +605,8 @@
+ GB_PACKING_CHUNKY | GB_COLORS_NATIVE | GB_ALPHA_NONE;
+ return_error(gs_error_rangecheck);
+ }
++if (mdev->line_ptrs == 0x00)
++return_error(gs_error_rangecheck);
+ if ((w <= 0) | (h <= 0)) {
+ if ((w | h) < 0)
+ return_error(gs_error_rangecheck);
diff -Nru ghostscript-9.20~dfsg/debian/patches/series 
ghostscript-9.20~dfsg/debian/patches/series
--- ghostscript-9.20~dfsg/debian/patches/series 2017-01-25 05:04:25.0 
+0100
+++ ghostscript-9.20~dfsg/debian/patches/series 2017-03-21 17:14:17.0 
+0100
@@ -6,6 +6,7 @@
 020161005~875a009.patch
 020161008~f5c7555.patch
 020161026~0726780.patch
+020170317~309eca4.patch
 1001_fix_openjp2_dynamic_linking.patch
 2001_docdir_fix_for_debian.patch
 2002_gs_man_fix_debian.patch

Bug#858851: debarchiver: [INTL:de] updated German man page translation

[Ola Lundqvist]

Hi

It is an old self signed cert on that site. Just accept and you should have
the source.

/ Ola

Sent from a phone

Den 30 mar 2017 18:09 skrev "Helge Kreutzmann" :

Hello Ola,
On Wed, Mar 29, 2017 at 09:29:29PM +0200, Ola Lundqvist wrote:
> Apparently...
> Uploading to ftp-master (via ftp to ftp.upload.debian.org):
>   Uploading debarchiver_0.11.1.dsc: done.
>   Uploading debarchiver_0.11.1.tar.gz: done.
>   Uploading debarchiver_0.11.1_all.deb: done.
>   Uploading debarchiver_0.11.1_amd64.changes: done.
> Successfully uploaded packages.
>
> So it was uploaded. The question is why it has not been accepted.
>
> I do not follow debian-devel, maybe it is a scheduled stop.
>
> You can find the source code here:
> https://svn.inguza.org/fsp/trunk/debarchiver/
> Do a svn checkout from there.

Seems like your server has some problems:
$ LC_ALL=C svn co https://svn.inguza.org/fsp/trunk/debarchiver/
Error validating server certificate for 'https://svn.inguza.org:443':
 - The certificate hostname does not match.
Certificate information:
 - Hostname: www.inguza.com
 - Valid: from Aug 11 12:03:56 2016 GMT until Aug 11 12:03:56 2017 GMT
 - Issuer: StartCom Class 1 DV Server CA, StartCom Certification Authority,
StartCom Ltd., IL
 - Fingerprint: 5A:CB:76:35:6D:E6:11:AB:A1:04:87:0C:ED:1D:D2:FA:29:E8:DB:E6
(R)eject, accept (t)emporarily or accept (p)ermanently? ^Csvn: E170013:
Unable to connect to a repository at URL 'https://svn.inguza.org/fsp/
trunk/debarchiver'
svn: E200015: The operation was interrupted


> Or here (web interface):
> http://svn.inguza.org/fsp/trunk/debarchiver/

I cannot download the file from there, I can get the logs, or annoted
HTML version but not plain de.po.

If it is so difficult to get the file I'll probably wait until it
appears on the debian pages.

Greetings

  Helge

>
> Cheers
>
> // Ola
>
> On 29 March 2017 at 18:59, Helge Kreutzmann  wrote:
>
> > Hello Ola,
> > On Tue, Mar 28, 2017 at 09:17:22PM +0200, Ola Lundqvist wrote:
> > > It should be in unstable/sid in an hour or so.
> >
> > 1.11.1  has not yet appeared in Unstable. Has there been a problem
> > while uploading?
> >
> > Greetings
> >
> >   Helge
> > --
> >   Dr. Helge Kreutzmann deb...@helgefjell.de
> >Dipl.-Phys.   http://www.helgefjell.de/
> > debian.php
> > 64bit GNU powered gpg signed mail preferred
> >Help keep free software "libre": http://www.ffii.de/
> >
>
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@debian.org   654 68 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---

--
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/

Bug#859131: unblock: openpyxl/2.3.0-3

[Salvatore Bonaccorso]

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

Hi

Not the maintainer here.

Please unblock package openpyxl

Unfortunately it looks an unblock for this update was never requested.
openpyxl/2.3.0-3 fixed CVE-2017-5992, allowing a remote attacker to
conduct XXE attacks via crafted .xlsx document.

This is #854442 in the Debian BTS.

Attached the generated debdiff from the version in testing.

unblock openpyxl/2.3.0-3

Regards,
Salvatore
diff -Nru openpyxl-2.3.0/debian/changelog openpyxl-2.3.0/debian/changelog
--- openpyxl-2.3.0/debian/changelog 2016-04-27 03:51:00.0 +0200
+++ openpyxl-2.3.0/debian/changelog 2017-02-07 15:37:53.0 +0100
@@ -1,3 +1,10 @@
+openpyxl (2.3.0-3) unstable; urgency=medium
+
+  * Do not resolve entities with lxml to avoid XXE vulnerability
+- patch up_no_lxml (Closes: #854442)
+
+ -- Yaroslav Halchenko   Tue, 07 Feb 2017 09:37:53 -0500
+
 openpyxl (2.3.0-2) unstable; urgency=medium
 
   * debian/control
diff -Nru openpyxl-2.3.0/debian/patches/series 
openpyxl-2.3.0/debian/patches/series
--- openpyxl-2.3.0/debian/patches/series2016-04-27 03:51:00.0 
+0200
+++ openpyxl-2.3.0/debian/patches/series2017-02-07 15:37:53.0 
+0100
@@ -1,2 +1,3 @@
+up_no_lxml
 deb_no_et_xml_file
 up_python3_print
diff -Nru openpyxl-2.3.0/debian/patches/up_no_lxml 
openpyxl-2.3.0/debian/patches/up_no_lxml
--- openpyxl-2.3.0/debian/patches/up_no_lxml1970-01-01 01:00:00.0 
+0100
+++ openpyxl-2.3.0/debian/patches/up_no_lxml2017-02-07 15:37:53.0 
+0100
@@ -0,0 +1,84 @@
+From: Yaroslav Halchenko 
+Subject: do not resolve entities 
+
+Adopted from upstream's commit on top of more recent release
+
+Origin: https://bitbucket.org/openpyxl/openpyxl/commits/3b4905f428e1
+Bug-Debian: http://bugs.debian.org/854442
+Applied-Upstream:  2017-01-17
+Last-Update: 2017-02-07
+
+--- a/openpyxl/conftest.py
 b/openpyxl/conftest.py
+@@ -47,4 +47,8 @@ def pytest_runtest_setup(item):
+ from lxml.etree import LIBXML_VERSION
+ if LIBXML_VERSION < (3, 4, 0, 0):
+ pytest.skip("LXML >= 3.4 is required")
++elif item.get_marker("no_lxml"):
++from openpyxl import LXML
++if LXML:
++pytest.skip("LXML has a different interface")
+ 
+--- a/openpyxl/xml/functions.py
 b/openpyxl/xml/functions.py
+@@ -21,11 +21,14 @@ if LXML is True:
+ fromstring,
+ tostring,
+ register_namespace,
+-iterparse,
+ QName,
+-xmlfile
++xmlfile,
++XMLParser,
+ )
+ from xml.etree.cElementTree import iterparse
++# do not resolve entities
++safe_parser = XMLParser(resolve_entities=False)
++fromstring = partial(fromstring, parser=safe_parser)
+ else:
+ try:
+ from xml.etree.cElementTree import (
+--- a/openpyxl/xml/tests/test_functions.py
 b/openpyxl/xml/tests/test_functions.py
+@@ -2,6 +2,7 @@ import pytest
+ 
+ from openpyxl.xml.functions import ConditionalElement
+ 
++import xml
+ 
+ @pytest.fixture
+ def root():
+@@ -50,3 +51,26 @@ def test_localtag(xml, tag):
+ from .. functions import fromstring
+ node = fromstring(xml)
+ assert localname(node) == tag
++
++
++@pytest.mark.lxml_required
++def test_dont_resolve():
++from ..functions import fromstring
++s = b"""
++
++]>
++&xxe;"""
++node = fromstring(s)
++
++
++@pytest.mark.no_lxml
++def test_dont_resolve():
++from ..functions import fromstring
++s = b"""
++
++]>
++&xxe;"""
++with pytest.raises(xml.etree.ElementTree.ParseError):
++node = fromstring(s)
+--- a/pytest.ini
 b/pytest.ini
+@@ -9,3 +9,4 @@ markers =
+ not_py33: Do not run test on Python 3.
+ lxml_required: lxml required to run test
+ lxml_buffering: lxml >= 3.4.0 required
++no_lxml: do not use lxml

Bug#858595: [Pkg-nginx-maintainers] Bug#858595: nginx logrotate doesn't properly switch to new logfiles

[Paul Tötterman]

> # lsof -p $(systemctl show -pMainPID nginx| cut -d= -f2)|grep /var/log

This actually showed no *.log.1 -files being open, but lsof -c nginx
|grep ... does

> # invoke-rc.d nginx rotate
> # lsof -p $(systemctl show -pMainPID nginx| cut -d= -f2)|grep /var/log

Didn't start showing *.log.1 -files open, but lsof -c nginx still does

systemctl reload nginx did close the *.log.1 -files.

> Also note that logrotate runs the postrotate script only when the
> matching log files are not empty (notifempty flag). If those files are
> empty, like in your case, the command isn't triggered.

right

Cheers,
Paul

Bug#704176: xournal: Export to PDF gives very low resolution

[Carlo Segre]

Thanks, I will try to upload the new version soon.

Carlo

On Thu, 30 Mar 2017, Angus Frinc wrote:


Package: xournal
Version: 1:0.4.8-1
Followup-For: Bug #704176

Dear Maintainer,

Regarding upstream bug report https://sourceforge.net/p/xournal/bugs/165/
this issue have been resolved in commits 78d9643 and e03ebdb
I recompiled xournal from upstream source and I can confirm that the
legacy export is now with better quality.

Regards,



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

Kernel: Linux 3.16.0-4-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 xournal depends on:
ii  ghostscript-x9.06~dfsg-2+deb8u4
ii  libart-2.0-2 2.3.21-2
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u7
ii  libcairo21.14.0-2.1+deb8u2
ii  libfontconfig1   2.11.0-6.3+deb8u1
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgnomecanvas2-02.30.3-2
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libpoppler-glib8 0.26.5-2+deb8u1
ii  libx11-6 2:1.6.2-3
ii  zlib1g   1:1.2.8.dfsg-2+b1

xournal recommends no packages.

xournal suggests no packages.

-- no debconf information



--
Carlo U. Segre -- Duchossois Leadership Professor of Physics
Interim Chair, Department of Chemistry
Director, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org

Bug#856971: freetype: diff for NMU version 2.6.3-3.1

[Salvatore Bonaccorso]

Control: tags 856971 + pending

Dear maintainer,

I've prepared an NMU for freetype (versioned as 2.6.3-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I should
delay it longer or if I can reschedule it to upload earlier.

Regards,
Salvatore
diff -u freetype-2.6.3/debian/changelog freetype-2.6.3/debian/changelog
--- freetype-2.6.3/debian/changelog
+++ freetype-2.6.3/debian/changelog
@@ -1,3 +1,12 @@
+freetype (2.6.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2016-10244: Heap-buffer-overflow
+src/type1/t1load.c (parse_charstrings): Reject fonts that don't contain
+glyph names. (Closes: #856971)
+
+ -- Salvatore Bonaccorso   Thu, 30 Mar 2017 19:16:33 +0200
+
 freetype (2.6.3-3) unstable; urgency=medium
 
   * Install the now-available-upstream manpages for freetype-demos.
diff -u freetype-2.6.3/debian/patches-freetype/series freetype-2.6.3/debian/patches-freetype/series
--- freetype-2.6.3/debian/patches-freetype/series
+++ freetype-2.6.3/debian/patches-freetype/series
@@ -5,0 +6 @@
+CVE-2016-10244-type1-Fix-heap-buffer-overflow.patch
only in patch2:
unchanged:
--- freetype-2.6.3.orig/debian/patches-freetype/CVE-2016-10244-type1-Fix-heap-buffer-overflow.patch
+++ freetype-2.6.3/debian/patches-freetype/CVE-2016-10244-type1-Fix-heap-buffer-overflow.patch
@@ -0,0 +1,33 @@
+From a660e3de422731b94d4a134d27555430cbb6fb39 Mon Sep 17 00:00:00 2001
+From: Werner Lemberg 
+Date: Fri, 26 Aug 2016 00:23:27 +0200
+Subject: [PATCH] [type1] Fix heap buffer overflow.
+
+Reported as
+
+  https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36
+
+* src/type1/t1load.c (parse_charstrings): Reject fonts that don't
+contain glyph names.
+---
+
+diff --git a/src/type1/t1load.c b/src/type1/t1load.c
+index c981adcf..f8bf3132 100644
+--- a/src/type1/t1load.c
 b/src/type1/t1load.c
+@@ -1776,6 +1776,12 @@
+   }
+ }
+ 
++if ( !n )
++{
++  error = FT_THROW( Invalid_File_Format );
++  goto Fail;
++}
++
+ loader->num_glyphs = n;
+ 
+ /* if /.notdef is found but does not occupy index 0, do our magic. */
+-- 
+2.11.0
+

Bug#810283: jessie: note that armel/iop32x subarch was removed

[Niels Thykier]

Baptiste Jammet:
> Hi,
> 
> Le 30/03/2017 07:56, Niels Thykier a écrit :
>> Control: reopen -1
> 
>> I saw this commit going to trunk[1] (stretch release notes) but original
>> report requested "jessie release notes".
> Oh, sorry! And thanks for the catch.
> 

Thanks for trying to fix this bug in the first place. :)

>> Are we sure this has been fixed (in the /correct/ release-notes)? :)
> No...
> I think I have to revert the Stretch RN (because it's not new now!) and
> apply the same text to Jessie RN. Would that be OK?
> 
> Baptiste

That sounds fine with me :)

Thanks,
~Niels

Bug#859130: TAG: lina -- iso-compliant Forth interpreter and compiler

[Albert van der Horst]

Package: wntpp
Severity: wishlist

Information:
Homepage: https://github.com/albertvanderhorst/ciforth
lina is a 32 bit classic Forth system, (mostly) compliant to the
ISO Forth94 standard, with a library in source form.
It is small, yet allows to generate elf-executables that can be
shipped to and run by non-Forth-aware users. This is unique among
Forth's available to linux.
It has no dependancies, so it can be used instead of a
c-compilation system or Python scripter, where size matters.
Also simplicity engenders reliability.

Architecture: This package is (for now) limited to i386 and
amd86 architectures.

Background: The system is in use since 2000. It has an extensive
regressiontest and comprehensive documentation. It is part of the
ciforth family with compatible systems for MS-windows, OSX and
MS-DOS (and similar compilers for Dec Alpha, 6809, Renesas 16, ARM)
It has been used to build an assembler/disassembler (ciasdis)
that has some notoriety.

The license is GPL2 for the compiler itself. LPGPL applies to all
library elements, including those contained within the compiler
executable.

Releases:
https://github.com/albertvanderhorst/ciforth/release
contains current releases. Binary releases are at 5.3.0 for
Linux, MS-windows and OSX.

Packaging:
  release/lina_5.3.0_i386.deb
is generated by a script debian.sh from a lina_#.tar.gz release.
A binary release contains the one(!) source file, so a binary release
can serve as an upstream source package.
This should help a prospective sponsor to swiftly go towards RFP.

Maintenance:
I'm the developer and maintainer since 2000 and
I'm planning on continuing to develop and maintain it. Also
I'm willing to adapt the package in order to smoothen the
cooperation with Debian.

Greetings, Albert
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Bug#858975: fixed in linux 4.9.18-1

[Ben Hutchings]

Control: reopen -1

On Thu, 30 Mar 2017 04:20:26 + Ben Hutchings 
wrote:
[...]
>    * w1: Enable W1_MASTER_GPIO as module (Closes: #858975)
[...]

For some reason that change got lost.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.


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

Bug#859029: Acknowledgement (po4a: [INTL:de] updated German man page translation)

[Martin Quinson]

On Thu, Mar 30, 2017 at 06:15:02PM +0200, Helge Kreutzmann wrote:
> 
> Is it ok if I directly push to the alioth git repository (as I did for
> the SVN one)?

Yes, of course! I'd be glad if you could do that.

You will find the gits from the following page:
https://po4a.alioth.debian.org/translations.php

website:
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=po4a/po4a-website.git;a=tree;f=po/www

But please tell me whenever you change it, so that I push the changes
online.

Thanks for your help,

Mt

-- 
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
  --- Isaac Asimov


signature.asc
Description: PGP signature

Bug#858431: strip-nondeterminism does not normalize Unix ownership from zip archives

[Reiner Herrmann]

On Wed, Mar 22, 2017 at 07:29:03PM +, Chris Lamb wrote:
> > > What I expect to see, and believe should happen, is all UIDs and GIDs in
> > > the zip archive become 0, owned by root.
> > 
> > That would be inconsistent with the current behaviour with tarballs,
> > which also contain UIDs and GIDs and AFAIK are kept untouched by
> > strip-nondeterminism.

tarballs are currently not touched/supported at all by strip-nondeterminism.

> Indeed, and given that we would want the behaviour to be consistent across
> archive formats and I think this goes beyond what strip-nondetermism should
> do, I am marking this as wontfix.

I think it would be more consistent to also normalize UID/GID in zip files,
as this is some non-determinism (that should be stripped).
And strip-nondeterminism currently also normalizes permissions to 755/644,
which is a bit related to UID/GID.


signature.asc
Description: Digital signature