Bug#869810: krita: Crash on startup, missing libgsl.so.19

[Pino Toscano]

reassign 869810 libgsl2 gsl/2.4+dfsg-1
affects 869778 krita
thanks

Hi,

In data mercoledì 26 luglio 2017 17:53:46 CEST, Philipp Wörner ha scritto:
> Package: krita
> Version: 1:3.1.4+dfsg-1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> 
> Recently (I believe due to an update to libgsl2) krita wasn't able to
> start at all on my system, exiting with following message:
> """
> krita: error while loading shared libraries: libgsl.so.19: cannot open
> shared object file: No such file or directory
> """
> 
> I tried reinstalling with 'apt install krita --reinstall' to make sure I
> wasn't missing anything. Didn't help.
> 
> In the end I just linked the current libgsl.so.23 to it:
> """
> ln -s /usr/lib/x86_64-linux-gnu/libgsl.so.23
> /usr/lib/x86_64-linux-gnu/libgsl.so.19
> """
> 
> That seemed to resolve the issue for me and krita starts up now. 
> I haven't encountered additional issues yet but I wasn't extensively
> looking for any.

This looks like bug #869778, i.e. a ABI & SONAME break in the libgsl
package.  Thus reassigning, since it will either be fixed directly in
libgsl with no changes in reverse dependencies (such as krita), or it
will require a transition (handled differently, but still not manually
by us).

Thanks,
-- 
Pino Toscano

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

Bug#869852: Please build-depend on ocamlbuild

[Stéphane Glondu]

Package: src:botch
Version: 0.21-3
Severity: important
User: debian-ocaml-ma...@lists.debian.org
Usertags: ocaml-4.05.0-transition

Dear maintainer,

botch uses ocamlbuild. To ease a future transition to ocaml 4.05.0,
where ocamlbuild is a separate package, please add it to
Build-Depends. The dependency is fullfilled by ocaml-nox 4.02.3-10 at
the moment.

Cheers,

-- 
Stéphane

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

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

Bug#869840: zookeeper: merge zookeeper and zookeeperd packages

[tony mancill]

On Thu, Jul 27, 2017 at 12:58:26AM +0200, Christoph Anton Mitterer wrote:
> Source: zookeeper
> Severity: wishlist
> 
> 
> Hi.
> 
> Is there any bigger reason for having the daemon split from its
> init files?
> 
> Most daemon packages in Debian don't do this, zookeeperd contains
> only few small files so there is no real space benefit.
> 
> 
> I have absolutely nothing against if you don't want to have the
> daemon started just by installing the package, but this can also
> be achieved with the init files in the main package :-)
> 
> 
> At least zookeeperd should suggest zookeeperd.
> 
> 
> Further, zookeeperd has a package description of:
> >This package contains init.d scripts to start and stop zookeeper and starts 
> >zookeeper on installation.
> however it also contains systemd and even still upstart init files
> (the later can probably be dropped, now that upstream is dead).

Hi Chris,

I don't know the history of why zookeeper and zookeeperd were split into
separate packages, but I tend to agree that the separate daemon package
isn't strictly needed.  Maybe the idea was that a user might want to
install the management tools on a system that isn't also a zk server,
and that installing zookeeperd is the differentiating factor?

Thank you for the bug report.  Perhaps we can get some input from other
users or developers.  I will work on cleaning up the description and the
init files in zookeeperd.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#869848: cacti: Cross-site scripting vulnerability in auth_profile.php

[Salvatore Bonaccorso]

Control: retitle -1 cacti: CVE-2017-11691: Cross-site scripting vulnerability 
in auth_profile.php

CVE-2017-11691 has been assigned for this issue.

Regards,
Salvatore

Bug#869851: mupdf: screen tearing (regression?)

[Celejar]

Package: mupdf
Version: 1.9a+ds1-4
Severity: important

I've been a happy user of mupdf in Jessie. I recently upgraded my system
to Stretch, and now mupdf exhibits terrible screen tearing when paging
through or resizing documents. Other pdf readers, such as evince and
qpdfview, do not exhibit any tearing.

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

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

Versions of packages mupdf depends on:
ii  libc62.24-11+deb9u1
ii  libfreetype6 2.6.3-3.2
ii  libharfbuzz0b1.4.2-1
ii  libjbig2dec0 0.13-4.1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libopenjp2-7 2.1.2-1.1
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1+b2
ii  zlib1g   1:1.2.8.dfsg-5

mupdf recommends no packages.

Versions of packages mupdf suggests:
pn  mupdf-tools  

-- no debconf information

Bug#869850: ITP: pdd -- Tiny date, time diff calculator

[林上智]

Package: wnpp

Severity: wishlist

Owner: SZ Lin (林上智) 

X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: pdd

  Version : 1.0

  Upstream Author : Arun Prakash Jana 

* URL : https://github.com/jarun/pdd

* License : GPL-3

  Programming Lang: Python

  Description :  Tiny date, time diff calculator
 pdd (python3 date diff) is a small cmdline utility to calculate date and
time
 difference. If no program arguments are specified it shows the current
date, time
 and timezone.
 .
 Feature
 .
  - calculate date difference
  - calculate time difference
  - calculate diff from today and now
  - add, subtract duration (timeslice) to/from date (time)
  - show current date, time and timezone
  - minimal dependencies
 .
 pdd is under GNU GPLv3.

--

SZ Lin (林上智) , *http://people.debian.org/~szlin
*

*Debian Developer*

4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9

Bug#869849: upgrade-reports: Successful upgrade (Jessie->Stretch) on a W550s

[Celejar]

Package: upgrade-reports
Severity: normal

I just performed a reasonably smooth and successful upgrade from Jessie
to Stretch on a Lenovo W550. The system was previously mostly Jessie,
with some stuff from backports, some packages from unstable, one or two
from third party repositories, and perhaps some still left from
deb-multimedia.

The upgrade went smoothly. Deciding what to do about new configuration
files is always difficult, and one doesn't always have that much
patience during an upgrade, but I haven't seen any problems yet arising
out of my choices (generally keep mine when I know I've made significant
changes, otherwise allow installations of the new one).

My new Stretch system did suffer from a bad bug in the chrony package
that broke the whole ifupdown system:

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

But this was easily fixed by manually downloading and installing the
fixed version from unstable.

I was a bit nonplussed when upon reboot I ended up in lightdm's login
screen, rather than my usual VT - this is apparently because
xfce4-session now recommends light-locker, which depends on lightdm. I
use xscreensaver, but I learned a while ago that for security, I
probably should be logging in via a dm rather than doing startx from a
console (since X crashing or being shutdown could leave an attacker with
a logged in console), so I decided to leave lightdm installed.

The system did lockup shortly after the actual installation (while I was
performing some post-installation housekeeping, purging removed
packages, IIRC), but the problem has not recurred.

I'm probably still in the process of finding kinks in the new system,
and I'll report them here as I do, but on the whole, the upgrade went
quite well. Thank you all for maintaing this great operating system!

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

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

Bug#869848: cacti: Cross-site scripting vulnerability in auth_profile.php

[Salvatore Bonaccorso]

Source: cacti
Version: 1.1.13+ds1-1
Severity: important
Tags: security patch upstream fixed-upstream
Forwarded: https://github.com/Cacti/cacti/issues/867

Hi

There is a XSS vulnerability in auth_profile.php which can be taken
advantage from by authenticated users:

Upstream issue: https://github.com/Cacti/cacti/issues/867
Upstream fix: 
https://github.com/Cacti/cacti/commit/104090aeead4aa433bf1f18cd6d52dcfeb71236c

A CVE has been requested.

Regards,
Salvatore

Bug#869847: don't try building packages with only test files

[Alexandre Viau]

Package: dh-golang
Severity: normal

This is happening during a package build:
>go build github.com/syncthing/syncthing/meta: no buildable Go source
files in
/home/aviau/git/debian-pkg/build-area/syncthing-0.14.33+dfsg1/_build/src/github.com/syncthing/syncthing/meta

the ``meta`` package is not empty:
> -rw-r--r-- 1 aviau aviau 3719 Jul 26 22:02 authors_test.go
> -rw-r--r-- 1 aviau aviau 1533 Jul 26 22:02 copyright_test.go
> -rw-r--r-- 1 aviau aviau 1055 Jul 26 22:02 gofmt_test.go
> -rw-r--r-- 1 aviau aviau 2642 Jul 26 22:02 metalint_test.go

Its just that it contains only tests.

It would be great if whatever command is used to determine what packages
are build could exclude packages that are "empty" because they contain
only tests.

Cheers <3

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#869844: base-installer: debian 9.1.0 live iso - base-installer tar process copying live system failed, no space left on device

[Dhanar Adi Dewandaru]

On Thu, Jul 27, 2017 at 8:12 AM, Steve McIntyre  wrote:

> On Thu, Jul 27, 2017 at 06:55:46AM +0700, Dhanar Adi Dewandaru wrote:
> >Package: base-installer
> >Severity: important
> >
> >Dear Maintainer,
> >
> >I hope i file this bug against the correct package.
> >
> >When installing debian using live iso, base-installer failed while
> copying live system with error message tar no space left on the device.
> This cause the installation to fail.
> >This seems to be similar to #748579. But i think it is not since i am
> using the original iso without netbootin.
> >
> >I am using debian-live-9.1.0-amd64-mate+nonfree.iso (the SHA1SUM has
> been checked OK).
> >When booting the iso, i choose Debian Installer option on the boot menu
> (i did not go the live desktop).
> >This issue did not exist on the previous version of the live iso
> (debian-live-9.0.1-amd64-mate+nonfree.iso).
> >
> >I tested this a couple of times on VirtualBox and I was able to reproduce
> the issue every time (sorry, i do not have any spare PC to test it on real
> hardware).
> >Please see the following screenshot for more details.
> >
> >https://pasteboard.co/GCNcTdW.png
> >https://pasteboard.co/GCNd67b.png
> >
> >Hopefully, this bug can be fixed soon because it makes it impossible to
> install debian from live iso.
>
> There may not be a bug here. What setup did you use for the partitions
> and filesystems on your machine?
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> We don't need no education.
> We don't need no thought control.
>

I choose "Guided - use entire disk" and "All files in one partition"

See the overview here: https://pasteboard.co/GCO8z87.png

Yes, i think it may be a bug in the base-installer or something else
causing base-installer to fail.

Bug#869846: dose-builddebcheck: plural error in error message

[Wookey]

Package: dose-builddebcheck
Version: 5.0.1-8
Severity: minor

A minor nit.

I got this error message due to giving dose-builddebcheck a duff filename:
Fatal error in module common/input.ml: 
 Input file /var/lib/apt/lists/*_main_binary-amd64_Packages does not exists.
dose-builddebcheck failed with error code 64

'does not exists' is wrong. Should be 'does not exist'.

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

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

Bug#868753: slapd: Please include several upstream fixes

[Ryan Tandy]

Control: retitle 868753 slapd: endless replication loop with 3-way delta-MMR
Control: severity 868753 important
Control: severity 860947 important

Sven and I had some private discussion about this ticket, and he was 
able to confirm for me that the patches for ITS#8432 and ITS#8648 
resolved all of the problems he reported here.


We already have #860947 tracking the sasl_client_init issue, so I'm 
re-scoping this one to focus just on the 3-way delta-MMR issue 
(ITS#8432). Also bumping the severity on #860947 since it turns out to 
cause even more symptoms than I had previously realized (memory 
corruption, so not all that surprising). Note that I consider the 
discussion with Sven as confirming that #860947 was in fact a symptom of 
the sasl_client_init bug.

Bug#869148: digikam cannot import photos from iphone

[Steve Robbins]

On Thursday, July 20, 2017 3:39:43 PM CDT Herminio Hernandez Jr wrote:

> I am trying to import my photos from my iphone to my desktop. I plug the
> iphone into the USB port and I see KDE recognizing and asking if I want
> digikam in import. I click on the digikam icon and it the app launches.
> After launch I recieve an error say the device is not recognized. I will
> be attaching a screenshot of the error.

What kind of iPhone is it?  

I see a similar report against OpenSUSE for iPhone 6S that shows the same 
error message; 
seehttp://opensuse.14.x6.nabble.com/Digikam-etc-cannot-upload-from-iPhone-6S-td5078569.html

Of interest is this bit:

[quote]
See also 
https://forums.gentoo.org/viewtopic-t-1057040-start-0-postdays-0-postorder-asc-highlight-.html?sid=4e7f17ebc8ac5da89456e92ee46749c5

Apparently it broke with iOS 10 and you need to make sure that the iPhone 
"trusts" your computer so it exposes its filesystem. 
[/quote]

And, as Simon said: let us know if you try it with a newer version.  [which 
reminds me: we need a newer version for Debian ...]

-Steve


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

Bug#665645: #665645 tack: "xterm -tn xterm-256color" fails (ccc) (initc) (initp)

[Thomas Dickey]

This was fixed outside tack in ncurses last year:

# 2016-04-23
#   + add 'oc' capability to xterm+256color, allowing palette reset for
# xterm -TD

http://lists.gnu.org/archive/html/bug-ncurses/2016-04/msg00011.html

and since that version (and later) is in Debian/testing, this bug will
be closed.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#839155: Patch for #839155

[Greg Dahlman]

Hi, I think this is a regression from 4.3.

Unfortunately pip uses ~/.local/bin for `pip install --user` calls and when 
this is missing people tend to use sudo for packages for all users.

While the previous change unconditionally added the path I did follow the new 
4.4 behavior and tested for the directory before pre-pending the directory to 
the path.

Thanks,

Gregdiff -Nru bash-4.4/debian/changelog bash-4.4/debian/changelog
--- bash-4.4/debian/changelog	2017-05-15 12:45:32.0 -0700
+++ bash-4.4/debian/changelog	2017-07-26 18:02:45.0 -0700
@@ -1,3 +1,11 @@
+bash (4.4-6) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload
+  * Add $HOME/.local/bin to skel.profile
+- Closes: #839155, LP: #1705571
+
+ -- gdahlman   Wed, 26 Jul 2017 18:02:45 -0700
+
 bash (4.4-5) unstable; urgency=medium
 
   * Apply upstream patch 012.
diff -Nru bash-4.4/debian/skel.profile bash-4.4/debian/skel.profile
--- bash-4.4/debian/skel.profile	2013-10-23 05:41:22.0 -0700
+++ bash-4.4/debian/skel.profile	2017-07-26 18:02:45.0 -0700
@@ -20,3 +20,8 @@
 if [ -d "$HOME/bin" ] ; then
 PATH="$HOME/bin:$PATH"
 fi
+
+# set PATH so it includes user's pip private bin if it exists
+if [ -d "$HOME/.local/bin" ] ; then
+PATH="$HOME/.local/bin:$PATH"
+fi

Bug#869844: base-installer: debian 9.1.0 live iso - base-installer tar process copying live system failed, no space left on device

[Steve McIntyre]

On Thu, Jul 27, 2017 at 06:55:46AM +0700, Dhanar Adi Dewandaru wrote:
>Package: base-installer
>Severity: important
>
>Dear Maintainer,
>
>I hope i file this bug against the correct package.
>
>When installing debian using live iso, base-installer failed while copying 
>live system with error message tar no space left on the device. This cause the 
>installation to fail. 
>This seems to be similar to #748579. But i think it is not since i am using 
>the original iso without netbootin.
>
>I am using debian-live-9.1.0-amd64-mate+nonfree.iso (the SHA1SUM has been 
>checked OK). 
>When booting the iso, i choose Debian Installer option on the boot menu (i did 
>not go the live desktop).  
>This issue did not exist on the previous version of the live iso 
>(debian-live-9.0.1-amd64-mate+nonfree.iso).
>
>I tested this a couple of times on VirtualBox and I was able to reproduce the 
>issue every time (sorry, i do not have any spare PC to test it on real 
>hardware).
>Please see the following screenshot for more details.
>
>https://pasteboard.co/GCNcTdW.png
>https://pasteboard.co/GCNd67b.png
>
>Hopefully, this bug can be fixed soon because it makes it impossible to 
>install debian from live iso.

There may not be a bug here. What setup did you use for the partitions
and filesystems on your machine?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.

Bug#869380: limesuite: Please update to newer release

[Andreas Bombe]

On Sat, Jul 22, 2017 at 11:07:26PM +0200, Sebastian Reichel wrote:
> Please update limesuite again. It is required for newer
> firmware. While I do not know the exact changelog for
> the newer firmware it fixes a power management related
> issue. Before the LimeSDR reached high temperatures in
> no time while doing nothing. After updating the firmware
> it only warms up by 5-10° in idle mode.

Like the rest of packages providing SoapySDR modules, I'm waiting for
my SoapySDR upload to be accepted (binary-NEW due to soname change). I
will make uploads of all these packages soon afterwards.

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Ximin Luo]

Russell Sim:
> Hey,
> 
> I'm about to do an upload and I was wondering if you thought it would make
> sense to start shipping this package with a versioned -dev package.  At the
> moment the dev package is un-versioned, and the upstream API can change
> quite significantly with each release.  So I'm a bit worried that this will
> cause package build failures if any rebuilds occur.  Does that make sense
> to do this, or is that over complicating things?  I couldn't find any good
> documentation about when it is appropriate to version a dev package.
> 
> I won't let this stop me uploading 0.25.1.0, but I'm curious about what
> your opinion is?
>

Hey, I'd suggest *not* to have the -dev package be versioned.

Despite the fact that the API changes quite a lot, I would guess that most (say 
ballpark 80%) dependants would still build fine with both 0.25 and 0.26. If you 
start renaming the -dev packages, you would have to edit the source code of all 
of the dependant packages to say Build-Depends: libgit2-26-dev etc. That is 
more work than doing binary-only NMU rebuilds, using the latest version of 
libgit2-dev.

Also there would be extra trips through the NEW queue. Also it does not really 
help build failures - since you are maintaining 1 source package, if you upload 
libgit2-26-dev then the older libgit2-25-dev would go away anyways and be 
unavailable for future builds.

Usually the only appropriate time to do versioned -dev packages is if you are 
going to maintain both those versions separately for a long period of time, and 
usually this would only be because of very major API changes (like GTK 2 vs 3) 
rather than relatively minor changes from 0.25 to 0.26.

If upstream keeps changing API very significantly then yes, one would have to 
make a tradeoff on whether it's more-or-less effort to (a) upgrade packages to 
use the newer API or (b) maintain multiple source packages of these different 
versions. However, having reviewed the 0.26 release notes, I think keeping 1 
source package (and an unversioned -dev package) is the better solution for 
this case.

X

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

Bug#869845: RFP: sanoid -- Policy-driven snapshot management and replication tools.

[raoul]

Package: wnpp
Severity: wishlist

* Package name: sanoid
  Version : 1.4.14
  Upstream Author : Jim Salter
* URL : https://github.com/jimsalterjrs/sanoid
* License : GPL-3
  Programming Lang: Perl
  Description : Policy-driven snapshot management and replication tools. 

Policy-driven snapshot management and replication tools. Currently using ZFS 
for underlying next-gen storage, with explicit plans to support btrfs when 
btrfs becomes more reliable. Primarily intended for Linux, but BSD use is 
supported and reasonably frequently tested.

Bug#790222: [boinc_dev] Bug#790222: wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated

[Olly Betts]

On Wed, Jul 26, 2017 at 11:05:57AM +0200, Emilio Pozuelo Monfort wrote:
> OK I see that porting is already done upstream in the link you quoted. So
> yeah, it'd be a matter of moving to that. This probably needs a library
> transition though.

The problem is that wx's GTK3 support is still much buggier than its
GTK2 support.  Upstream wx seem quick to fix bug reports about GTK3
shortcomings when they can reproduce them, but they've been unable to
reproduce some which I can reproduce in their own sample code, e.g.:

https://trac.wxwidgets.org/ticket/17915

So this transition is going to be a lot more work than tweaking
wxwidgets3.0's debian/control and debian/rules, uploading and then
bin-nmuing 100 or so packages.  It's going to need a lot of testing
of rdeps, and that's likely to uncover a significant number of upstream
bugs which we'll ideally need to find reproducers for.

My plan is to put a build of wxwidgets3.0 using GTK3 in experimental (or
maybe unstable) so maintainers of rdeps can try it and we can gauge how
realistic switching is in this release cycle.

But as I've said already, I don't have a problem with just disabling
webview before buster if it comes to it.  It just seems unhelpful to
boinc users running testing to do that right now, unless you're actually
at the point of removing the old webkitgtk from testing.

Cheers,
Olly

Bug#850417: dpkg: error: dpkg status database is locked by another process

[Vincent Lefevre]

To make things clear in this bug, this bug has been confirmed:

  https://lists.debian.org/debian-dpkg/2017/01/msg00044.html

(as referenced in bug 869546).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#869844: base-installer: debian 9.1.0 live iso - base-installer tar process copying live system failed, no space left on device

[Dhanar Adi Dewandaru]

Package: base-installer
Severity: important

Dear Maintainer,

I hope i file this bug against the correct package.

When installing debian using live iso, base-installer failed while copying live 
system with error message tar no space left on the device. This cause the 
installation to fail. 
This seems to be similar to #748579. But i think it is not since i am using the 
original iso without netbootin.

I am using debian-live-9.1.0-amd64-mate+nonfree.iso (the SHA1SUM has been 
checked OK). 
When booting the iso, i choose Debian Installer option on the boot menu (i did 
not go the live desktop).  
This issue did not exist on the previous version of the live iso 
(debian-live-9.0.1-amd64-mate+nonfree.iso).

I tested this a couple of times on VirtualBox and I was able to reproduce the 
issue every time (sorry, i do not have any spare PC to test it on real 
hardware).
Please see the following screenshot for more details.

https://pasteboard.co/GCNcTdW.png
https://pasteboard.co/GCNd67b.png

Hopefully, this bug can be fixed soon because it makes it impossible to install 
debian from live iso.

Thank you.

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

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

Bug#869843: Jul 26 19:37:49 honeybee dnsmasq[31624]: sed: -e expression #1, char 103: Invalid range end

[Joey Hess]

Source: dnsmasq
Severity: normal
Version: 2.77-2

Noticed the subject message in the journal. It does not seem to break 
basic functionality. Probably caused by the sed in the init script.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#869842: bts: see also += devscripts.conf(5)

[James McCoy]

On Wed, Jul 26, 2017 at 11:22:08PM +, Daniel Shahaf wrote:
> I was skimming bts(1) to see what its dotfile was called, and the SEE
> ALSO section did not have the answer.

+1.  Feel free to commit straight-forward fixes like this.  It's in
collab-maint for a reason. :)

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#853010: FWD: Re: build depends, maintainer interest for package OpenOCD

[Norbert Lange]

Hello,

did you try asking on debian-de...@lists.debian.org?
This package seems orphaned, but usually its up to the maintainer to
declare this.

I am going to need a newer openocd build sometime and would like to
know whether this is going to be maintained.

Kind regards,
Norbert


On Tue, 21 Feb 2017 21:53:13 +0100 Geert Stappers  wrote:
>
> The e-mail that I wrote yesterday went to the wrong bugreport.
>
> This time it should go the intented bugreport.
> And it has a better "From: " address
>
>
> - Forwarded message from Geert Stappers -
>
> Date: Mon, 20 Feb 2017 17:59:07 +0100
> From: Geert Stappers
> To: 853...@bugs.debian.org, lu...@debian.org, u...@debian.org
> Subject: Re: build depends,  maintainer interest for package OpenOCD
> User-Agent: Mutt/1.5.21 (2010-09-15)
>
> On Sat, Jan 28, 2017 at 10:24:57PM +0100, Geert Stappers wrote:
> > Package: openocd
> > Tags: patch
> >
> > --- a/debian/control
> > +++ b/debian/control
>  
> > That removes 'autotools-dev', there is still 'autotools-dev, autoconf,'.
> > And 'libftdi-dev' is now on separate line.
> >
> >
> > Also is this bugreport to show my interrest in co-maintaining
> > the Debian OpenOCD package.
> >
>
> Yes, I still want to work on packaging openocd.
>
> But how think the current maintainers about that?
>
> That is why Uwe and Luca are also in the To: field.
>
>
> Groeten
> Geert Stappers
> DD, Maintainer of package urjtag
> --
> Leven en laten leven
>
>
>
> - End forwarded message -
>
> Groeten
> Geert Stappers
> --
> Leven en laten leven
>
>

Bug#869842: bts: see also += devscripts.conf(5)

[Daniel Shahaf]

Package: devscripts
Version: 2.17.10
Severity: wishlist
Tags: upstream patch

Dear Maintainer,

I was skimming bts(1) to see what its dotfile was called, and the SEE
ALSO section did not have the answer.

Patch attached.

Cheers,

Daniel
>From 9f863a306a358135c9752d3cbd67ab92f5af5b68 Mon Sep 17 00:00:00 2001
From: Daniel Shahaf 
Date: Wed, 26 Jul 2017 23:17:55 +
Subject: [PATCH] bts: docs: Add devscripts.conf(5) to "See also"

---
 scripts/bts.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/bts.pl b/scripts/bts.pl
index d54f38f8..d25ffdfe 100755
--- a/scripts/bts.pl
+++ b/scripts/bts.pl
@@ -4195,7 +4195,7 @@ Please see L 
for
 more details on how to control the BTS using emails and
 L for more information about the BTS.
 
-querybts(1), reportbug(1), pts-subscribe(1)
+querybts(1), reportbug(1), pts-subscribe(1), devscripts.conf(5)
 
 =head1 COPYRIGHT
 

Bug#867822: pbuilder: pdebuild cannot build source-only packages

[Milan Kupcevic]

On Sun, 9 Jul 2017 19:48:41 +0100 James Clarke  wrote:

[...]

> 
> I have yet to hear a convincing argument in favour of supporting
> --debbuildopts -S, but that doesn't mean there isn't one, so I'm open
> to being convinced otherwise (and I'm sure Mattia is too).
> 

Because dpkg-buildpackage and debuild fully support the "-S" option.

Pdebuild used to do it fine, it fails now.


Milan



signature.asc
Description: OpenPGP digital signature

Bug#869841: zookeeper: config file handling

[Christoph Anton Mitterer]

Source: zookeeper
Severity: normal


Hi.

Two thoughts about the config files:
1) Example configuration as in /etc/zookeeper/conf_example
   should typically go to /usr/share/doc//examples
   At least that what's basically all other packages do.

2) If you consider this however default configuration, it should
   either go to /usr/share/zookeper/somewhere or so, and symlinked
   from there... or be directly copied (from there or
   /u/s/d//examples) to /etc/zookeeper in postinst.
   Or altnerative, be handled as conffiles an just directly placed
   in /etc/zookeeper.

3) Using update-alternatives for config is at least uncommon, I think.
   And it doesn't seem to make much sense, does it?
   When should one have different config set *per host* that admins
   want to switch?

   And there is no real documentation about it, or is there? I had
   to look up the postinst file just to fine out the u-a group name
   to be zookeeper-conf.


Cheers,
Chris.

Bug#869840: zookeeper: merge zookeeper and zookeeperd packages

[Christoph Anton Mitterer]

Source: zookeeper
Severity: wishlist


Hi.

Is there any bigger reason for having the daemon split from its
init files?

Most daemon packages in Debian don't do this, zookeeperd contains
only few small files so there is no real space benefit.


I have absolutely nothing against if you don't want to have the
daemon started just by installing the package, but this can also
be achieved with the init files in the main package :-)


At least zookeeperd should suggest zookeeperd.


Further, zookeeperd has a package description of:
>This package contains init.d scripts to start and stop zookeeper and starts 
>zookeeper on installation.
however it also contains systemd and even still upstart init files
(the later can probably be dropped, now that upstream is dead).


Cheers,
Chris.

Bug#869839: ITP: maven-reporting-api -- Maven Reporting API

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: maven-reporting-api
  Version : 3.0
  Upstream Author : The Apache Software Foundation
* URL : http://maven.apache.org/shared/maven-reporting-api/
* License : Apache-2.0
  Programming Lang: Java
  Description : Maven Reporting API

This library contains the base API for Maven plugins generating code reports.
It was originally part of libmaven2-core-java but was spun off in the latest
release. This package is required to upgrade the maven-invoker-plugin to the
latest release.

This package will be maintained by the Java Team.

Bug#865382: Possible solution of #865382

[Steve McIntyre]

On Wed, Jul 26, 2017 at 12:56:17PM +0300, Алексей Шилин wrote:
>Hi,
>
>I've investigated this issue a bit, and it looks like there are actually two 
>things to look at:
>
>  1. Live user doesn't log in automatically.
>
> This is due to autologin not being configured for SDDM by live-config 
> scripts. In fact, there is no script to 
> configure SDDM at all.
>
>  2. When one enters the password ("live" by default), session startup fails.
>
> Looks like this is connected to the previous one. As there is no script 
> which configures SDDM, nothing prevents 
> xinit configuration script (/lib/live/config/0140-xinit) from being run, 
> which installs the following snippet to 
> /etc/profile.d/:
>
>if [ -z "${DISPLAY}" ] && [ $(tty) = /dev/tty1 ]
>then
>while true
>do
>if grep -qs quiet /proc/cmdline
>then
>startx > /dev/null 2>&1
>else
>startx
>fi
>done
>fi
>
> Given that console autologin is enabled by default, this script tries to 
> start the X server in infinite loop. Under 
> certain circumstances this interferes with normal session startup by the 
> display manager, leading to the issue 
> described above.
>
> Indeed, if one starts the system with "nottyautologin" boot option, the 
> issue vanishes, and it becomes possible to 
> successfully log in after typing the default live user password.
>
>I've attached a patch for live-config which adds SDDM configuration script. It 
>*should* solve both issues. However, 
>testing is required.

Thanks very much, this seems to be exactly the fix needed. I've just
tested it now... :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#869802: [Debian-olpc-devel] Bug#869802: sugar-physics-activity: Request to move the package to be maintained by the Sugar team.

[James Cameron]

G'day Rishabh,

I'm not a Debian developer, yet.  ;-)

I've a derivative package of Physics.  Written by Gonzalo Odiard and
Martin Abente Lahaye two years ago, and maintained by me since.  We
use it at OLPC for building our images.

It is non-compliant with current Debian standards, so some work would
be needed to bring it up to date.

https://github.com/quozl/physics/commits/olpc-packaging

In case it is a problem, we can relicense as required.

For more on Debian Derivatives, see
https://wiki.debian.org/Derivatives/

-- 
James Cameron
http://quozl.netrek.org/

Bug#867636: Bug#867634: linux-image-4.9.0-3-amd64: Repeated ESATA softreset failed messages - even after replacing most components.

[Matthew Gillespie]

eSATA cables were replaced, server has been replaced.


On 07/20/2017 08:01 PM, Ben Hutchings wrote:

Control: reopen -1
Control: tag -1 moreinfo

[Retrying this with the other address given]

On Fri, 2017-07-07 at 21:01 -0400, madsara wrote:
[...]

* What exactly did you do (or not do) that was effective (or
  ineffective)?
The following actions have been taken so far, none of which are 
successful:
- Upgraded Dell R210 II's BIOS
- Purchased an entirely new Sandisk TowerRAID TR8M+B
- Replaced the eSATA card - moving from SIL chipset to Marvell
- Replaced all hard drives with brand new 3TB drives.

Did you try replacing the eSATA cables yet?


- Upgraded OS from Debian Jessie to Debian Stretch
- Ensured BIOS was set for maximum performance and not power saving.
- Added noapic, acpi=off, and apm=off kernel parameter options.

These parameters were once useful with old hardware and kernel
versions, but now will usually only make things worse.


- Performed a full on-board health check (part of the Dell on-board 
management abilities), finding no issues.
- Performed an extensive memory test, finding no issues.

[...]

Ben.

Bug#861567: FTBFS with sphinx 1.5

[Diane Trout]

Package: dask
Version: 1.15.1-1
Tags: pending

Hi,

While, I was struggling with a different dask FTBFS problem, I learned
more of how dask's docs are built.

Dask reuses docstrings from pandas, and as a result there's a few
function docstrings in dask.array that use mathjax, for example
corrcoef.

I think the version that's committed to alioth should work.

Currently cleaning up the matched dask.distributed package so I can
release both of them.

Diane

Bug#869838: kdenlive: closing all file descriptors for no reason whatsoever

[Salvo Tomaselli]

Package: kdenlive
Version: 17.04.3-1
Severity: minor
Tags: upstream

Dear Maintainer,
while I was using strace on kdenlive, I noticed that when terminating, it
closes descriptors from 0 to 1023 for no reason.

1. the kernel does that
2. I suppose they have massive file descriptor leaks, if they close files like
   that?

Per se it's not a big issue, but it's an indicator of bad practice.

Best

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

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

Versions of packages kdenlive depends on:
ii  ffmpeg   7:3.2.6-1+b3
ii  kded55.28.0-1
ii  kdenlive-data17.04.3-1
ii  kinit5.28.0-1
ii  kio  5.28.0-2
ii  libc62.24-12
ii  libgcc1  1:7.1.0-10
ii  libgl1-mesa-glx [libgl1] 17.1.4-1
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libkf5archive5   5.28.0-2
ii  libkf5attica55.28.0-1
ii  libkf5auth5  5.28.0-2
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5codecs55.28.0-1+b2
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-2
ii  libkf5configgui5 5.28.0-2
ii  libkf5configwidgets5 5.28.0-2
ii  libkf5coreaddons55.28.0-2
ii  libkf5crash5 5.28.0-1
ii  libkf5dbusaddons55.28.0-1
ii  libkf5filemetadata3  5.28.0-1+b2
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.28.0-2
ii  libkf5iconthemes55.28.0-2
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-2
ii  libkf5kiocore5   5.28.0-2
ii  libkf5kiofilewidgets55.28.0-2
ii  libkf5kiowidgets55.28.0-2
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-4
ii  libkf5sonnetui5  5.28.0-2+b1
ii  libkf5textwidgets5   5.28.0-1
ii  libkf5widgetsaddons5 5.28.0-3
ii  libkf5xmlgui55.28.0-1
ii  libmlt++36.4.1-5+b1
ii  libmlt6  6.4.1-5+b1
ii  libqt5concurrent55.7.1+dfsg-4
ii  libqt5core5a 5.7.1+dfsg-4
ii  libqt5dbus5  5.7.1+dfsg-4
ii  libqt5gui5   5.7.1+dfsg-4
ii  libqt5network5   5.7.1+dfsg-4
ii  libqt5qml5   5.7.1-2+b2
ii  libqt5quick5 5.7.1-2+b2
ii  libqt5script55.7.1~20161021+dfsg-2
ii  libqt5svg5   5.7.1~20161021-2+b2
ii  libqt5widgets5   5.7.1+dfsg-4
ii  libqt5xml5   5.7.1+dfsg-4
ii  libstdc++6   7.1.0-10
ii  libv4l-0 1.12.5-1
ii  melt 6.4.1-5+b1
ii  oxygen-icon-theme5:5.28.0-1
ii  qml-module-qtquick-controls  5.7.1~20161021-2
ii  qml-module-qtquick2  5.7.1-2+b2

Versions of packages kdenlive recommends:
pn  dvdauthor
pn  dvgrab   
pn  frei0r-plugins   
pn  genisoimage  
pn  recordmydesktop  
pn  swh-plugins  

Versions of packages kdenlive suggests:
pn  khelpcenter  

-- no debconf information

Bug#869837: kdenlive: busy loop

[Salvo Tomaselli]

Package: kdenlive
Version: 17.04.3-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
kdenlive does a busy loop, and is basically keeping the CPU too busy doing
that, to actually do anything productive.

When I start it, CPU jumps at 100%.

with strace I get this:

futex(0x4aafe807c4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x4aafe807c0, 
FUTEX_OP_SET<<28|0<<12|FUTEX_OP_CMP_GT<<24|0x1) = 1
writev(3, 
[{iov_base="\n\0\2\0\25\0\340\3\31\0\v\0\347\0\0\0\0\0\30\0\22\\tZ\347\0\0\0\25\0\340\3"...,
 iov_len=52}], 1) = 52
futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 1
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\2\0\4\0\33\0\340\3\0@\0\0\230\1\340\3", iov_len=16}], 1) 
= 16
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\22\0\7\0\33\0\340\3y\1\0\0\6\0\0\0 
\0\0\0\1\0\0\0Sk\316\3\10\0\2\0"..., iov_len=40}], 1) = 40
futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7ffd5a745bd0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7ffd5a745bd4, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource 
temporarily unavailable)
futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 0
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\22\0\7\0\25\0\340\3y\1\0\0\6\0\0\0 
\0\0\0\1\0\0\0Sk\316\3\10\0\2\0"..., iov_len=40}], 1) = 40
futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7ffd5a745f40, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7ffd5a745f44, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource 
temporarily unavailable)
futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 0

Over and over.

Best.


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

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

Versions of packages kdenlive depends on:
ii  ffmpeg   7:3.2.6-1+b3
ii  kded55.28.0-1
ii  kdenlive-data17.04.3-1
ii  kinit5.28.0-1
ii  kio  5.28.0-2
ii  libc62.24-12
ii  libgcc1  1:7.1.0-10
ii  libgl1-mesa-glx [libgl1] 17.1.4-1
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libkf5archive5   5.28.0-2
ii  libkf5attica55.28.0-1
ii  libkf5auth5  5.28.0-2
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5codecs55.28.0-1+b2
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-2
ii  libkf5configgui5 5.28.0-2
ii  libkf5configwidgets5 5.28.0-2
ii  libkf5coreaddons55.28.0-2
ii  libkf5crash5 5.28.0-1
ii  libkf5dbusaddons55.28.0-1
ii  libkf5filemetadata3  5.28.0-1+b2
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.28.0-2
ii  libkf5iconthemes55.28.0-2
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-2
ii  libkf5kiocore5   5.28.0-2
ii  libkf5kiofilewidgets55.28.0-2
ii  libkf5kiowidgets55.28.0-2
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-4
ii  libkf5sonnetui5 

Bug#868905: [htcondor-debian] Bug#868905:

[Michael Hudson-Doyle]

Hi, sorry about that, it's also possible I screwed up somehow. Here it is
again.

On 26 July 2017 at 23:56, Tim Theisen  wrote:

> Hi Michael,
>
> Could you send the patch the me directly? The bug tracking system
> apparently stripped the patch from the message.
>
> Thank you for looking into this. I was about to start working on this
> problem. I'd like to get this resolved soon.
>
> ...Tim
>
> On 07/25/2017 08:48 PM, Michael Hudson-Doyle wrote:
>
> I fixed this in Ubuntu with this patch:
>
>
>
> ___
> htcondor-debian mailing 
> listhtcondor-deb...@cs.wisc.eduhttps://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian
>
>
> --
> Tim Theisen
> Release Manager
> HTCondor & Open Science Grid
> Center for High Throughput Computing
> Department of Computer Sciences
> University of Wisconsin - Madison
> 4261 Computer Sciences and Statistics
> 1210 W Dayton St
> Madison, WI 53706-1685+1 608 265 5736 <(608)%20265-5736>
>
>


fix_linker_script
Description: Binary data

Bug#868267: fai-client: fetch-basefile breaks for hostnames with hyphens

[andrew bezella]

On Wed, 2017-07-26 at 17:34 -0400, Arcady Genkin wrote:
[...]
> # chroot /data/fai-nfsroots/xenial-x64 /bin/bash --version |head -1
> GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)

ah! ok, apparently a change in bash's behavior between 4.3 and 4.4:

% bash --version | head -n1
GNU bash, version 4.4.7(1)-release (x86_64-pc-linux-gnu)
% export classes="vmops0.us.archive.org"
% bash /usr/lib/fai/fetch-basefile
/usr/lib/fai/fetch-basefile: line 59: found_vmops0.us.archive.org: bad 
substitution
No basefile matching a class name was found at [FAI_BASEFILEURL]

vs

% bash --version | head -n1
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
% export classes="vmops0.us.archive.org"
% bash /usr/lib/fai/fetch-basefile
No basefile matching a class name was found at [FAI_BASEFILEURL]


in bash 4.4 it appears that either "." or "-" breaks the indirect
variable usage:

% bash --version | head -n1
GNU bash, version 4.4.7(1)-release (x86_64-pc-linux-gnu)
% export classes="vmops0.us.archive.org"
% bash /usr/lib/fai/fetch-basefile
/usr/lib/fai/fetch-basefile: line 59: found_vmops0.us.archive.org: bad 
substitution
No basefile matching a class name was found at [FAI_BASEFILEURL]
% export classes="vm-ops0"
% bash /usr/lib/fai/fetch-basefile
/usr/lib/fai/fetch-basefile: line 59: found_vm-ops0: bad substitution
No basefile matching a class name was found at [FAI_BASEFILEURL]
% export classes="vmops0"
No basefile matching a class name was found at [FAI_BASEFILEURL]

possibly related to the announcement at https://lists.gnu.org/archive/h
tml/bug-bash/2015-07/msg00027.html which mentions a couple changes to
indirect variable expansion.  unsure if the above is intentional or
collateral damage.  "_" does appear to be ok.


-- 
andrew bezella 
internet archive

Bug#862927: gnat (GCC 7) fails to build on m68k

[John Paul Adrian Glaubitz]

Control: reopen -1

On 07/17/2017 10:55 AM, John Paul Adrian Glaubitz wrote:
> On Fri, Jul 14, 2017 at 06:00:04PM +0200, John Paul Adrian Glaubitz wrote:
>> I had a go at this and came up with the attached patch which
>> fixes the problem for me.  With the patch applied, I can build
>> a gnat cross-compiler for m68k.
> 
> The patch has already been merged upstream, both on trunk [1] and in
> the gcc-7-branch [2], so carrying the patch is not necessary when
> including the next slew of SVN updates.

The current version of gcc-7 in unstable is missing the patch from [1]:

s-maccod.ads:36:15: violation of No_Elaboration_Code_All at line 37
s-maccod.ads:36:15: unit "System" does not have No_Elaboration_Code_All
../gcc-interface/Makefile:299: recipe for target 's-maccod.o' failed

I'll reopen this.

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81446

-- 
 .''`.  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

Bug#869836: stretch-pu: package nvidia-graphics-drivers/375.82-1~deb9u1

[Luca Boccassi]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear Release Team,

The non-free proprietary nvidia-graphics-drivers version 375.66 in
Stretch is affected by CVE-2017-6257 and CVE-2017-6259. Debian bug:

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

Please consider allowing the new upstream version 375.82, which fixes
these CVEs, in proposed-updates. As usual with these proprietary
drivers, we cannot just cherry-pick the fixes for the CVEs as they are
in the binary blobs.

I have tested this new version on a Stretch amd64 desktop and didn't
encounter any issue.

The debdiff from 375.66-2~deb9u1 to 375.82-1 is attached.

Apart from the new upstream version, the other bug fixes are:

- update binary library blobs symbols files reflecting upstream changes
- allow parallel dkms builds if requested (#864639) by a user
- re-allow dkms ccache usage if enabled by a user
- switch watch files protocol to https, as upstream deprecated ftp
(#868815)
- mark the dkms modules as build-tested up to kernel 4.11
- add support for buster in the nvidia-detect script (#866126), that
helps the users choose the correct drivers that support their hardware

Kind regards,
Luca Boccassidiff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/bug-control.mk nvidia-graphics-drivers-375.82/debian/bug-control.mk
--- nvidia-graphics-drivers-375.66/debian/bug-control.mk	2017-02-23 15:37:37.0 +
+++ nvidia-graphics-drivers-375.82/debian/bug-control.mk	2017-07-26 20:22:43.0 +0100
@@ -46,6 +46,7 @@
 	libdrm-nouveau2
 	xserver-xorg-video-nouveau
 	make
+	ccache
 	libopencl1
 	opencl-icd
 	libvulkan1
diff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/changelog nvidia-graphics-drivers-375.82/debian/changelog
--- nvidia-graphics-drivers-375.66/debian/changelog	2017-07-16 13:35:22.0 +0100
+++ nvidia-graphics-drivers-375.82/debian/changelog	2017-07-26 21:42:00.0 +0100
@@ -1,3 +1,43 @@
+nvidia-graphics-drivers (375.82-1) unstable; urgency=high
+
+  * New upstream long lived branch release 375.82 (2017-07-24).
+* Fixed CVE-2017-6257, CVE-2017-6259.  (Closes: #869783)
+- Fix a bug with GLX_EXT_buffer_age where incorrect buffer age values would
+  be reported for SLI AFR configurations. In such configurations buffer age
+  may now be greater than 3, the previous maximum buffer age.
+- Fixed a bug that could cause hanging and Xids when performing RandR
+  transforms with Overlay and SLI enabled.
+- Improved handling of framebuffer console restore on systems booted in
+  UEFI mode.
+- Extended the information reported by the NVIDIA Xinerama X extension to
+  report PRIME displays in addition to directly-connected displays.
+- Fixed a bug that caused HDMI audio devices to appear or disappear
+  inconsistently when HDMI devices were hotplugged or unplugged.
+- Fixed a bug that could cause driver errors when setting modes on X
+  screens running at Depth 8 or Depth 15.
+- Fixed a bug that could cause intermittent kernel panics when running with
+  PRIME Sync.
+- Fixed a bug that caused a kernel panic when hotplugging HDMI displays on
+  some Zotac mini PCs.
+- Updated nvidia-installer to label kernel modules with SELinux file type
+  'modules_object_t'. Some system SELinux policies only permit loading of
+  kernel modules with this SELinux file type.
+- Removed support for checking for and downloading updated driver packages
+  and precompiled kernel interfaces from nvidia-installer. This
+  functionality was limited to unencrypted ftp and http, and was
+  implemented using code that is no longer actively maintained.
+
+  [ Andreas Beckmann ]
+  * nvidia-kernel-dkms: Honor parallel setting from dkms.  (Closes: #864639)
+  * Do not prevent ccache usage. The bug was fixed in ccache 3.0 (in squeeze).
+  * Switch watch URL from ftp:// to https://.  (Closes: #868815)
+
+  [ Luca Boccassi ]
+  * Add support for buster/sid in nvidia-detect.  (Closes: #866126)
+  * Update symbols files.
+
+ -- Luca Boccassi   Wed, 26 Jul 2017 21:42:00 +0100
+
 nvidia-graphics-drivers (375.66-2~deb9u1) stretch; urgency=medium
 
   * Rebuild for stretch. 
diff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/detect/nvidia-detect.in nvidia-graphics-drivers-375.82/debian/detect/nvidia-detect.in
--- nvidia-graphics-drivers-375.66/debian/detect/nvidia-detect.in	2017-07-16 13:35:22.0 +0100
+++ nvidia-graphics-drivers-375.82/debian/detect/nvidia-detect.in	2017-07-26 20:22:43.0 +0100
@@ -139,7 +139,7 @@
 		else
 			echo "Oops. Internal error 8 ($NVGA)"
 		fi
-	elif grep -q "stretch\|^9\|buster\|^10" /etc/debian_version
+	elif grep -q "stretch\|^9" /etc/debian_version
 	then
 		if [[ -n ${VERSIONS[999]} ]]; then
 			if [[ -n ${VERSIONS[340]} ]]; then
@@ -167,6 +167,34 @@
 		else
 			echo "Oops. 

Bug#866354: 866354 - What should maintainers of the affected packages do?

[Alexandre Viau]

On 26/07/17 05:29 PM, Alexandre Viau wrote:
> What should maintainers of the affected packages do? This is preventing
> my package from migrating to testing.

Hmm, now that I am looking at it, my package (ring) was marked as
affected but the error looks unrelated?

> checking for exit in -lrestbed... no
> configure: error: Missing restbed files
> debian/rules:19: recipe for target 'override_dh_auto_configure' failed

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#869835: opensp: Update debian/control with stage1 build profile info

[Daniel Schepler]

Source: opensp
Version: 1.5.2-13
Severity: wishlist

It would be great if the next upload could update Build-Depends to
indicate which are not necessary for the stage1 build profile.  That
would make it easier to do automated bootstrapping.  My guess would
be:

Build-Depends: debhelper (>> 7.0.0), dh-buildinfo, xmlto ,
poppler-utils , openjade , jadetex ,
docbook-dsssl , dh-autoreconf
-- 
Daniel Schepler

Bug#869783: Security - upgrade NVidia driver to 375.82 in stable.

[Moritz Mühlenhoff]

On Wed, Jul 26, 2017 at 10:20:27PM +0100, Luca Boccassi wrote:
> Control: tags -1 pending
> 
> On Wed, 2017-07-26 at 13:48 +0200, Julien Aubin wrote:
> > Package: nvidia-driver
> > Version: 375.66-2
> > Severity: critical
> > 
> > Hi,
> > 
> > NVidia driver is currently targetted by several critical
> > vulnerabilities as
> > disclosed by NVidia. Full description there :
> > https://nvidia.custhelp.com/app/answers/detail/a_id/4525
> > 
> > Some of the vulnerabilities affect Linux users with issues including
> > privilege escalation and denial of service.
> > 
> > Updated package is 375.82.
> > 
> > Could you please release quickly the updated packages ?
> > 
> > Thanks
> 
> Uploaded to unstable.
> 
> Dear Security Team,
> 
> CVE-2017-6257 and CVE-2017-6259 affect Stretch - how would you like to
> see this handled?
> 
> - upload through security
> - upload through p/u
> - ignore

non-free is not covered by security support, so you can choose
between p/u and ignore :-)

Cheers,
Moritz

Bug#869770: tzdata: Incorrect timezone names for Argentina

[Aurelien Jarno]

On 2017-07-26 12:21, nyuszika7h wrote:
> Package: tzdata
> Version: 2017b-1
> Severity: minor
> Tags: upstream
> 
> Dear Maintainer,
> 
> For a while, `date '+%Z'` displayed 'ART' for America/Argentina/* timezones.
> Now it just displays '-03' for some reason. I'm not sure when this issue
> started occurring, it was sometime back with jessie. It seems to be an 
> upstream
> issue, though.

This is indeed an upstream change, but actually not a bug. ART is an
invented timezone name, and upstream started to remove all invented
timezone names from tzdata, as they are not used outside of tzdata and
often conflict with each other.

In the case of South-American timezones, see this commit for more
details:

https://github.com/eggert/tz/commit/c9e6ef07cc6f1062ddd032c96c5172f403c0058f 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#831899: This error persists still in Debian stretch

[Harry Haller]

Hi Volker, Hi Maximiliano !

This error is still in stretch. But I've got it in an i386-environment. I 
don't want to make a new Bug-Report, but document, that it still exists. I 
described it here:
https://bugs.kde.org/show_bug.cgi?id=382635

As I described there, the error occurs always I start kaddressbook. I (can't) 
use kaddressbook 4:16.04.3-3. My Kernel is linux-image-4.9.0-3-686-pae 
(4.9.30-2+deb9u). With a new user it starts - as in Jessie. Here are my error-
messages, when I start it from Konsole (bash):

QDBusObjectPath Akonadi::Server::NotificationManager::subscribe(const QString&, 
bool) Akonadi::Server::NotificationManager(0x80663e78) 
"kaddressbook_9177_mTcCx7" false
QDBusObjectPath Akonadi::Server::NotificationManager::subscribe(const QString&, 
bool) Akonadi::Server::NotificationManager(0x80663e78) 
"kaddressbook_9177_e22nIP" false
QDBusObjectPath Akonadi::Server::NotificationManager::subscribe(const QString&, 
bool) Akonadi::Server::NotificationManager(0x80663e78) 
"kaddressbook_9177_tOmGTd" false
QDBusObjectPath Akonadi::Server::NotificationManager::subscribe(const QString&, 
bool) Akonadi::Server::NotificationManager(0x80663e78) 
"kaddressbook_9177_9QZzTP" false
Database "akonadi" opened using driver "QMYSQL"
Database "akonadi" opened using driver "QMYSQL"
New notification bus: "/subscriber/kaddressbook_9177_mTcCx7"
Database "akonadi" opened using driver "QMYSQL"
New notification bus: "/subscriber/kaddressbook_9177_e22nIP"
org.kde.akonadi.ETM: GEN true false true
org.kde.akonadi.ETM: collection: QVector()
Database "akonadi" opened using driver "QMYSQL"
New notification bus: "/subscriber/kaddressbook_9177_tOmGTd"
Database "akonadi" opened using driver "QMYSQL"
Database "akonadi" opened using driver "QMYSQL"
New notification bus: "/subscriber/kaddressbook_9177_9QZzTP"
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kaddressbook path = /usr/bin pid = 9177
KCrash: Arguments: /usr/bin/kaddressbook 
KCrash: Attempting to start /usr/lib/i386-linux-gnu/libexec/drkonqi from 
kdeinit
sock_file=/run/user/1000/kdeinit5__0
Shutting down "kaddressbook-1186278907" ...
Shutting down "/subscriber/kaddressbook_9177_mTcCx7" ...
Shutting down "/subscriber/kaddressbook_9177_e22nIP" ...
Shutting down "/subscriber/kaddressbook_9177_tOmGTd" ...
Shutting down "KAddressBook::GlobalContactSession" ...
Shutting down "/subscriber/kaddressbook_9177_9QZzTP" ...
void Akonadi::Server::NotificationSource::serviceUnregistered(const QString&) 
Notification source "kaddressbook_9177_9QZzTP" now serving: ()
void Akonadi::Server::NotificationSource::serviceUnregistered(const QString&) 
Notification source "kaddressbook_9177_tOmGTd" now serving: ()
void Akonadi::Server::NotificationSource::serviceUnregistered(const QString&) 
Notification source "kaddressbook_9177_e22nIP" now serving: ()
[1]   Exit 253kaddressbook

Regards
Juwe (alias Harry Haller)

Bug#868267: fai-client: fetch-basefile breaks for hostnames with hyphens

[Arcady Genkin]

> @Arcady - could you check the version of bash that you're using and
> confirm that `/bin/bash` on your system isn't a symlink to `dash` or
> something?  and/or try setting the $classes variable manually to
> exclude the hostname's hyphen and test again?

Hi, Andy,

By "your system" I am taking the NFS root in which the FAI scripts run. The
NFS root is freshly generated from Debian Stretch. There /bin/bash and
/bin/dash are two distinct binaries.  I won't get to trying setting
$classes manually for a few days; I'll report when I get a chance to do
that.

# chroot /data/fai-nfsroots/xenial-x64 /bin/bash --version |head -1
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)

root@ps2:/data/fai-nfsroots/xenial-x64/bin# stat dash bash
  File: `dash'
  Size: 117208  Blocks: 232IO Block: 4096   regular file
Device: 10307h/66311d   Inode: 284706  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2017-07-19 11:39:31.414194403 -0400
Modify: 2017-01-24 00:16:56.0 -0500
Change: 2017-07-12 16:52:56.095031937 -0400
 Birth: -
  File: `bash'
  Size: 1099016 Blocks: 2152   IO Block: 4096   regular file
Device: 10307h/66311d   Inode: 284767  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2017-07-19 11:39:27.522457272 -0400
Modify: 2017-05-15 15:45:32.0 -0400
Change: 2017-07-12 16:52:56.235022488 -0400
 Birth: -

-- 
Arcady Genkin

Bug#866354: 866354 - What should maintainers of the affected packages do?

[Alexandre Viau]

Hello,

What should maintainers of the affected packages do? This is preventing
my package from migrating to testing.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#869783: Security - upgrade NVidia driver to 375.82 in stable.

[Luca Boccassi]

Control: tags -1 pending

On Wed, 2017-07-26 at 13:48 +0200, Julien Aubin wrote:
> Package: nvidia-driver
> Version: 375.66-2
> Severity: critical
> 
> Hi,
> 
> NVidia driver is currently targetted by several critical
> vulnerabilities as
> disclosed by NVidia. Full description there :
> https://nvidia.custhelp.com/app/answers/detail/a_id/4525
> 
> Some of the vulnerabilities affect Linux users with issues including
> privilege escalation and denial of service.
> 
> Updated package is 375.82.
> 
> Could you please release quickly the updated packages ?
> 
> Thanks

Uploaded to unstable.

Dear Security Team,

CVE-2017-6257 and CVE-2017-6259 affect Stretch - how would you like to
see this handled?

- upload through security
- upload through p/u
- ignore

I have tested this new version on a Stretch amd64 desktop and didn't
encounter any issue.

The debdiff from 375.66-2~deb9u1 to 375.82-1 is attached.

Apart from the new upstream version, the other bug fixes are:

- update binary library blobs symbols files reflecting upstream changes
- allow parallel dkms builds if requested (#864639)
- re-allow dkms ccache usage if enabled
- switch watch files protocol to https, upstream deprecated ftp
(#868815)
- mark the dkms modules as build-tested on kernel 4.11
- add support for buster in the nvidia-detect script (#866126)

Kind regards,
Luca Boccassidiff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/bug-control.mk nvidia-graphics-drivers-375.82/debian/bug-control.mk
--- nvidia-graphics-drivers-375.66/debian/bug-control.mk	2017-02-23 15:37:37.0 +
+++ nvidia-graphics-drivers-375.82/debian/bug-control.mk	2017-07-26 20:22:43.0 +0100
@@ -46,6 +46,7 @@
 	libdrm-nouveau2
 	xserver-xorg-video-nouveau
 	make
+	ccache
 	libopencl1
 	opencl-icd
 	libvulkan1
diff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/changelog nvidia-graphics-drivers-375.82/debian/changelog
--- nvidia-graphics-drivers-375.66/debian/changelog	2017-07-16 13:35:22.0 +0100
+++ nvidia-graphics-drivers-375.82/debian/changelog	2017-07-26 21:42:00.0 +0100
@@ -1,3 +1,43 @@
+nvidia-graphics-drivers (375.82-1) unstable; urgency=high
+
+  * New upstream long lived branch release 375.82 (2017-07-24).
+* Fixed CVE-2017-6257, CVE-2017-6259.  (Closes: #869783)
+- Fix a bug with GLX_EXT_buffer_age where incorrect buffer age values would
+  be reported for SLI AFR configurations. In such configurations buffer age
+  may now be greater than 3, the previous maximum buffer age.
+- Fixed a bug that could cause hanging and Xids when performing RandR
+  transforms with Overlay and SLI enabled.
+- Improved handling of framebuffer console restore on systems booted in
+  UEFI mode.
+- Extended the information reported by the NVIDIA Xinerama X extension to
+  report PRIME displays in addition to directly-connected displays.
+- Fixed a bug that caused HDMI audio devices to appear or disappear
+  inconsistently when HDMI devices were hotplugged or unplugged.
+- Fixed a bug that could cause driver errors when setting modes on X
+  screens running at Depth 8 or Depth 15.
+- Fixed a bug that could cause intermittent kernel panics when running with
+  PRIME Sync.
+- Fixed a bug that caused a kernel panic when hotplugging HDMI displays on
+  some Zotac mini PCs.
+- Updated nvidia-installer to label kernel modules with SELinux file type
+  'modules_object_t'. Some system SELinux policies only permit loading of
+  kernel modules with this SELinux file type.
+- Removed support for checking for and downloading updated driver packages
+  and precompiled kernel interfaces from nvidia-installer. This
+  functionality was limited to unencrypted ftp and http, and was
+  implemented using code that is no longer actively maintained.
+
+  [ Andreas Beckmann ]
+  * nvidia-kernel-dkms: Honor parallel setting from dkms.  (Closes: #864639)
+  * Do not prevent ccache usage. The bug was fixed in ccache 3.0 (in squeeze).
+  * Switch watch URL from ftp:// to https://.  (Closes: #868815)
+
+  [ Luca Boccassi ]
+  * Add support for buster/sid in nvidia-detect.  (Closes: #866126)
+  * Update symbols files.
+
+ -- Luca Boccassi   Wed, 26 Jul 2017 21:42:00 +0100
+
 nvidia-graphics-drivers (375.66-2~deb9u1) stretch; urgency=medium
 
   * Rebuild for stretch. 
diff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/detect/nvidia-detect.in nvidia-graphics-drivers-375.82/debian/detect/nvidia-detect.in
--- nvidia-graphics-drivers-375.66/debian/detect/nvidia-detect.in	2017-07-16 13:35:22.0 +0100
+++ nvidia-graphics-drivers-375.82/debian/detect/nvidia-detect.in	2017-07-26 20:22:43.0 +0100
@@ -139,7 +139,7 @@
 		else
 			echo "Oops. Internal error 8 ($NVGA)"
 		fi
-	elif grep -q "stretch\|^9\|buster\|^10" /etc/debian_version
+	elif grep -q "stretch\|^9" /etc/debian_version
 	then
 		if [[ -n ${VERSIONS[999]} 

Bug#859053: trivial compilation fix

[solo-debianbugs]

Control: tags -1 + patch

The attached trivial patch fixes compilation in my sid chroot.

Chris.

diff --git a/libofetion-2.2.2/debian/control b/libofetion-2.2.2/debian/control
index 64a8b55..279cd46 100644
--- a/libofetion-2.2.2/debian/control
+++ b/libofetion-2.2.2/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian Chinese Team 
 DM-Upload-Allowed: yes
 Uploaders: Aron Xu , Asias He  
-Build-Depends: debhelper (>= 7), cmake, libxml2-dev, libssl1.0-dev | libssl-dev (<< 1.1.0~), libsqlite3-dev, pkg-config
+Build-Depends: debhelper (>= 7), cmake, libxml2-dev, libssl-dev, libsqlite3-dev, pkg-config
 Standards-Version: 3.9.2
 Homepage: http://code.google.com/p/ofetion/
 
diff --git a/libofetion-2.2.2/fetion_login.c b/libofetion-2.2.2/fetion_login.c
index 6cdcc1c..457cdc7 100644
--- a/libofetion-2.2.2/fetion_login.c
+++ b/libofetion-2.2.2/fetion_login.c
@@ -85,7 +85,7 @@ char* generate_response(const char *nouce, const char *userid,
 	bne = BN_new();
 	BN_hex2bn(, modulus);
 	BN_hex2bn(, exponent);
-	r->n = bnn;	r->e = bne;	r->d = NULL;
+	RSA_set0_key(r, bnn, bne, NULL);
 //	RSA_print_fp(stdout, r, 5);
 	flen = RSA_size(r);
 	out =  (unsigned char*)malloc(flen);

Bug#869070: apt-listbugs does not honor Acquire::http::TimeOut

[Vincent Lefevre]

On 2017-07-26 19:33:55 +0200, Francesco Poli wrote:
> On Fri, 21 Jul 2017 03:23:13 +0200 Vincent Lefevre wrote:
> > If you meant that these are the only supported options, then "notable"
> > is not the right word (as I understood "notable configuration
> > options", I thought these were the most important options in
> > practice, in the context of apt-listbugs).
> 
> Maybe "relevant" would be clearer: what do you think?

Yes, that's much better.

But the first sentence should be modified too:

  apt-listbugs understands APT configuration file (see apt.conf(5) for
  more details).

is a bit meaningless. One can use / load / read / take into account
a configuration file, but I think that "understands" and
"configuration file" don't go together. It seems that the intent
was to mean the file format:

  apt-listbugs understands the APT configuration file format (see
  apt.conf(5) for more details).

Then, the issue is which configuration files are used. There's the
following option described in the man page:

   -C  apt.conf , --aptconf  apt.conf
  Specifies the APT configuration file to use.

"*the* APT configuration file to use" gives the impression that this
config file is used in place of /etc/apt/apt.conf, but according to
strace, it is read after "/etc/apt/apt.conf". If the current behavior
is the intent, then the above description should be:

  Specifies an additional APT configuration file to use.

Similar issue with the -h help text.

Section "CONFIGURATION FILE" should say which configuration files
are used (this is not clearly documented yet, see above). Moreover,
Section "FILES" mentions

  /etc/apt/apt.conf.d/10apt-listbugs

but /etc/apt/apt.conf and all the files from /etc/apt/apt.conf.d/ are
used too, aren't they? I suppose that /etc/apt/apt.conf.d/10apt-listbugs
is just the one where one should put apt-listbugs related options (those
to invoke apt-listbugs, like DPkg::Pre-Install-Pkgs, and those for
apt-listbugs).

> > > As far as the feature request itself is concerned, it seems to me
> > > that apt.conf(5) man page says:
> > > 
> > > | The option timeout sets the timeout timer used by the method; this
> > > | value applies to the connection as well as the data timeout.
> > > 
> > > It's not too clear to me whether the value is in seconds or in some
> > > other unit of measurement. Where is this documented?
> > 
> > I was wondering the same thing (since I had to use this option for
> > "apt"), and assumed that this was in seconds, as this is the standard
> > time unit (and the man page also mentions "seconds" for other time
> > options). And indeed, this corresponds to the observed behavior.
> 
> OK, maybe you should ask for confirmation to Apt developers and request
> them to properly document that the timeout has to be specified in
> seconds.

Done in this bug report:

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

> > That would be strange that standard modules wouldn't allow a
> > configurable timeout.
> 
> Could you please perform the following test?
> 
> As root, back up one file:
> 
>   # cp -ai /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb /root/
> 
> Then, edit lines 35÷37 of the file itself (using VIM or any other
> editor of your choice):
> 
>   # vim /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb
> 
> Please try to set 10 (in stead of 999) for the three timeout values.
> 
> Does this solve your issue?

I can't test for now, maybe tomorrow.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#844056: hard coded mac address

[Joey Hess]

My cubietruck needs this file for wifi to work. However, the MAC address
hardcoded in the file is not used.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#869833: yudit: Recommends NBS hunspell library

[Jeremy Bicha]

Package: yudit
Version: 2.9.6-6
Severity: serious
Justification: blocks removal of no longer built packages
Tags: buster sid

yudit recommends libhunspell-1.4-0, but the current version built from
the hunspell source is libhunspell-1.6-0

I believe this is a Release Critical bug because as long as something
installed still recommends the package, it will stay installed on
users' computers even though the package is no longer built in Debian
or supported.

Thanks,
Jeremy Bicha

Bug#869834: CVE-2017-11533: heap buffer overflow in uil coder

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-12
Severity: serious
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
forwarded:https://github.com/ImageMagick/ImageMagick/issues/562

When ImageMagick 7.0.6-1 processes a crafted file in convert, it can
lead to a heap-based buffer over-read in the WriteUILImage() function
in coders/uil.c.

Bug#869832: apt.conf(5): the time unit for timeout should be documented

[Vincent Lefevre]

Package: apt
Version: 1.5~beta1
Severity: wishlist

The apt.conf(5) documents the timeout http/https option:

  The option timeout sets the timeout timer used by the method; this
  value applies to the connection as well as the data timeout.

and

  The option timeout sets the timeout timer used by the method; this
  value applies to the connection as well as the data timeout.

but the time unit is not documented. It seems to be "in seconds".

See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869070#27

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/preferences.d/no-adobe-flash-plugin present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/opera-stable.list present, but not submitted) --


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

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

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2017.5
ii  gpgv2.1.18-8
ii  init-system-helpers 1.49
ii  libapt-pkg5.0   1.5~beta1
ii  libc6   2.24-12
ii  libgcc1 1:7.1.0-10
ii  libgnutls30 3.5.14-2
ii  libstdc++6  7.1.0-10

Versions of packages apt recommends:
ii  ca-certificates  20161130+nmu1

Versions of packages apt suggests:
ii  apt-doc 1.5~beta1
ii  aptitude0.8.8-1
ii  dpkg-dev1.18.24
ii  gnupg   2.1.18-8
pn  powermgmt-base  
ii  python-apt  1.4.0~beta3+b1

-- no debconf information

Bug#684407: apt: connection to Debian mirror with both A and AAAA records fails if client has no routable IPv6 address

[Vincent Lefevre]

On 2017-07-19 18:26:30 +0200, Vincent Lefevre wrote:
> On 2017-07-19 18:02:10 +0200, Julian Andres Klode wrote:
> > I don't think 10 seconds timeout for *any* data (one TCP packet)
> > is too low, really.
> 
> Shouldn't the default timeout be lowered, then?

BTW, related to this issue:

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

which is also about "really painful to wait for APT timeout on the
IPv6 address before APT switch to an IPv4".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#869658: Debian 9.1 stretch: command 'sensors' freeze temporarily the whole system

[Aurelien Jarno]

control: tag -1 - moreinfo
control: tag -1 + upstream
control: reassign -1 src:linux
control: retitle -1 linux: system freezes when dell-smm-hwmon reads fan speed

Hi,

On 2017-07-26 10:34, Carmelo C wrote:
> Hi Aurelien,
> 
> I removed the code line "radeon.hw_i2c=1" but the freeze persists. Then I
> ran "strace -o strace_sensors_output -tt sensors", attached the output...

Indeed, the strace shows that the freeze is not related to the radeon
module, but rather to the dell-smm-hwmon module. You can try to unload
it, the issue should then disappear.

[ snip ]

> 10:18:08.029849 write(1, "dell_smm-virtual-0\n", 19) = 19
> 10:18:08.029908 write(1, "Adapter: Virtual device\n", 24) = 24

[ snip ]

> 10:18:08.049666 open("/sys/class/hwmon/hwmon2/fan1_label", O_RDONLY) = 3
> 10:18:08.049718 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:08.049759 read(3, "Processor Fan\n", 4096) = 14
> 10:18:08.049801 read(3, "", 4096)   = 0
> 10:18:08.049838 close(3)= 0
> 10:18:08.049882 open("/sys/class/hwmon/hwmon2/fan1_input", O_RDONLY) = 3
> 10:18:08.049937 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:08.049978 read(3, "2844\n", 4096) = 5
> 10:18:09.956833 close(3)= 0
> 10:18:09.956891 write(1, "Processor Fan: 2844 RPM\n", 24) = 24

Here you can see that reading the fan speed almost take 2 seconds.

> 10:18:09.956950 open("/sys/class/hwmon/hwmon2/fan2_label", O_RDONLY) = 3
> 10:18:09.957009 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:09.957052 read(3, 0xbfdec67c, 4096) = -1 EINVAL (Invalid argument)
> 10:18:09.957093 close(3)= 0
> 10:18:09.957138 open("/sys/class/hwmon/hwmon2/fan2_input", O_RDONLY) = 3
> 10:18:09.957191 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:09.957250 read(3, "2844\n", 4096) = 5
> 10:18:11.860890 close(3)= 0
> 10:18:11.860939 write(1, "fan2:  2844 RPM\n", 24) = 24

Same here.

> 10:18:11.860990 open("/sys/class/hwmon/hwmon2/fan3_label", O_RDONLY) = 3
> 10:18:11.861046 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:11.861088 read(3, 0xbfdec67c, 4096) = -1 EINVAL (Invalid argument)
> 10:18:11.861128 close(3)= 0
> 10:18:11.861172 open("/sys/class/hwmon/hwmon2/fan3_input", O_RDONLY) = 3
> 10:18:11.861237 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:11.861278 read(3, "2840\n", 4096) = 5
> 10:18:13.779559 close(3)= 0
> 10:18:13.779666 write(1, "fan3:  2840 RPM\n", 24) = 24

Same here.

> 10:18:13.779738 open("/sys/class/hwmon/hwmon2/temp1_label", O_RDONLY) = 3
> 10:18:13.779947 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:13.780021 read(3, "CPU\n", 4096)  = 4
> 10:18:13.789029 read(3, "", 4096)   = 0
> 10:18:13.789087 close(3)= 0
> 10:18:13.789148 open("/sys/class/hwmon/hwmon2/temp1_input", O_RDONLY) = 3
> 10:18:13.789228 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:13.789280 read(3, "37000\n", 4096) = 6
> 10:18:13.799076 close(3)= 0

While reading a temperature is done in less than 1 millisecond.


The problem you observe is similar to the following one:
  
  https://bugzilla.kernel.org/show_bug.cgi?id=112021

As it the root of the problem is a BIOS issue, I would first suggest to
upgrade it. If it doesn't work the next step is probably to use the 
blacklist implemented in the dell-smm-hwmon module to disable the fans
when running on a Dell system similar to yours.

In anycase this is definitely a kernel related issue, so I am
reassigning the bug.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#869831: CVE-2017-11536 memory leak in jp2 coder

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-12
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
forwarded:https://github.com/ImageMagick/ImageMagick/issues/567


When ImageMagick 7.0.6-1 processes a crafted file in convert, it
can lead to a Memory Leak in the WriteJP2Image() function in
coders/jp2.c.

Bug#869830: [imagemagick] lack of validation for jp2 format

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-12
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14


Fixed by commit ac23b02ecb741e5de60f5235ea443790c88a0b80
Author: Cristy 
Date:   Sun May 21 11:07:10 2017 -0400

...

commit acee073df34aa4d491bf5cb74d3a15fc80f0a3aa
Author: Cristy 
Date:   Sun May 21 10:54:16 2017 -0400

...

Bug#869828: libgtk-3-common: Systray icons displayed without transparency: JWM/fdpowermon

[Justin J. Reis]

Package: libgtk-3-common
Version: 3.22.11-1
Severity: normal

Dear Maintainer,

Following the upgrade from Jessie to Stretch, the icon for fdpowermon in my 
system tray began to appear with a solid white (rather than transparent) 
background. Transparency worked normally prior to the upgrade. The icon PNG 
itself does have a treansparent base (verified in GIMP), but that transparency 
is not respected when rendered in the tray. I am running Joe's Window Manager 
(JWM) 2.6 over Xserver, no DE is installed. Lastly I should mention that this 
issue is only present on one of my two machines; both of which run Debian 
stable with the same JWM over X setup. fdpowermon behaves as expected on my 
main laptop, but has the transparency issue on my netbook. THe only appreciable 
differnse between the two that I can think of (other than hardware) is that the 
netbook is older. Having originally been installed with Wheezy. The laptop 
(which doesn't exhibit the errant icon behavior) was originally installed with 
Jessie. Again, both are now running Stretch.

None of the following altered the behavior in any way:
-- restart X server (quit to terminal > startx)
-- reboot machine
-- reinstall package via apt install --reinstall
-- purge, autoremove, then install package
-- purge, autoremove, then install using alt fdpowermon-icons package
-- revert to previuos theme.cfg for fdpowermon
-- changing gtk themes with lxappearance
> tried Adwaita, Bluebird, High Contrast, Murrina, others

I contacted the mainter of the fdpowermon package directly and he was of the 
opinion that the issue was likely gtk3 related, since the versions of 
fdpowermon in Jessie and Stretch used gtk2 and gtk3 respectively. He encouraged 
me to file a bug with gtk.


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

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

Versions of packages libgtk-3-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1

Versions of packages libgtk-3-common recommends:
ii  libgtk-3-0  3.22.11-1

libgtk-3-common suggests no packages.

-- no debconf information

Bug#869829: ITP: golang-github-ncw-dropbox-sdk-go-unofficial -- unofficial Dropbox v2 API SDK for Go

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-ncw-dropbox-sdk-go-unofficial
  Version : 1.0.0+git20170530.11.5d9f46f-1
  Upstream Author : Nick Craig-Wood
* URL : https://github.com/ncw/dropbox-sdk-go-unofficial
* License : Expat
  Programming Lang: Go
  Description : unofficial Dropbox v2 API SDK for Go

An unofficial Go SDK for integrating with the Dropbox API v2. Tested
with Go 1.5+
.
WARNING: This SDK is NOT yet official. There is no formal Dropbox
support (https://www.dropbox.com/developers/support) for this SDK
at this point. Not all SDK features may be implemented and
implemented features may be buggy or incorrect.


This package is a dependency of the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#865866: libreoffice-writer crash on startup Debian 9 i386 arch

[Hans]

Hi Rene,

maybe you should know, that libreoffice-writer ran fine since my last update, 
which was 
on 20th july 2017. 

I am running debian/testing, i386. And I do almost any day an upgrade.

No kernel update! So, maybe it helps, when you see, which packages were 
updated. This is 
the list:
Install: firebird3.0-server-core:i386 (3.0.2.32703.ds4-4, automatic), 
libgltf-0.1-1:i386 
(0.1.0-2, automatic), libzmf-0.0-0:i386 (0.0.1-4, auto

After this update, libreoffice won't start any more. As someone pointed me to 
java, I 
downgraded openjdk with no success. 

Maybe this might help to look, what might have changed.

Best regards

Hans

Bug#869827: CVE-2017-11535: heap based overflow in ps.c

[Bastien ROUCARIES]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-12
Severity: important
Tags: security upstream
X-Debbugs-CC: t...@security.debian.org
control: found -1 8:6.8.9.9-5+deb8u8
control: found -1 8:6.8.9.9-5+deb8u9
control: found -1 8:6.7.7.10-5+deb7u14
forwarded:https://github.com/ImageMagick/ImageMagick/issues/561


https://github.com/ImageMagick/ImageMagick/commit/b8647f11ddfd6f85a6cc39654c7e78c2bc6412e4
Imagemagick-6: 
https://github.com/ImageMagick/ImageMagick/commit/bba95cfcc19fa8a261e12692f31279148ad42441


CVE-2017-11535: When ImageMagick 7.0.6-1 processes a crafted file in
convert, it can lead to a heap-based buffer over-read in the
WritePSImage() function in coders/ps.c.

Bug#635964: Newest version is now 3.3.2

[Emmanuel Bourg]

Le 26/07/2017 à 21:10, Wouter Verhelst a écrit :

> this is getting ridiculous.

Do you realize that there is an ongoing effort to upgrade pdfsam and
that this kind of comment is rather demotivating? If you don't help you
are not allowed to complain.

Emmanuel Bourg

Bug#851819:

[Argel Ramírez Reyes]

Is there a reason to have this package still on the repos?
The last item uploaded to people.debian.org/~bartm is there since 2014

-- 
Argel Ramírez R.

Bug#869826: storymaps: Upstream address changed

[Martin Quinson]

Package: storymaps
Version: 1.0+dfsg-2
Severity: minor

Hello,

it seems that the upstream address of the software changed in between. The
given address (http://seanh.sdfeu.org/storymaps/) is now a 404 and I found the
software at https://www.seanh.cc/storymaps/ or
https://github.com/seanh/storymaps/

Thanks, Mt.


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

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

Versions of packages storymaps depends on:
ii  default-jre [java7-runtime]2:1.8-58
ii  jarwrapper 0.59
ii  libfreemarker-java 2.3.23-6
ii  libgoogle-gson-java2.4-1
ii  libpiccolo-java1.2-1
ii  openjdk-8-jre [java7-runtime]  8u131-b11-2

storymaps recommends no packages.

storymaps suggests no packages.

-- no debconf information

-- 
If it isn't straightforward to modify it, it will never be any good.
It will never be fast, it will never be correct. And it will
eventually be replaced by something modifiable. -- Paul Phillips


signature.asc
Description: PGP signature

Bug#868267: fai-client: fetch-basefile breaks for hostnames with hyphens

[andrew bezella]

On Wed, 2017-07-26 at 21:17 +0200, Thomas Lange wrote:
> And we have dots in FQDN, which are currently also not allowed in
> class names. Should we truncate the FQDN before defining the hostname
> as a class or replace  the dots with the underscore?

if this is implemented, i'd say replace the dots w/underscores, similar
to the nis/yp example in the fai-class man page.  subdomains can have
meaning and short hostnames should not be presumed to be unique in an
organization.

however, please bear in mind that making this change is likely to prove
disruptive for anyone expecting the current behavior.  and the current
class-naming rules are documented, even to the hostname-class
exception.  also (see below) i'm not sure hyphens are the problem here.

@Thomas - are you able to reproduce this failure mode?  as i mentioned,
we install a lot of hosts w/hyphens in their name w/o issue.

@Arcady - could you check the version of bash that you're using and
confirm that `/bin/bash` on your system isn't a symlink to `dash` or
something?  and/or try setting the $classes variable manually to
exclude the hostname's hyphen and test again?

i can generate this error by trying to run `dash fetch-basefile`
regardless of whether $classes includes a hyphen or not.  might be a
bash-ism and somehow a non-bash shell is trying to run it?

% export classes="vmops0.us.archive.org"
% dash ./fetch-basefile
./fetch-basefile: 59: ./fetch-basefile: Bad substitution
% export classes="vm-ops0.us.archive.org"
% dash ./fetch-basefile
./fetch-basefile: 59: ./fetch-basefile: Bad substitution
% bash ./fetch-basefile
No basefile matching a class name was found at [FAI_BASEFILEURL]

andy

-- 
andrew bezella 
internet archive

Bug#869825: hfst-ospell FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: hfst-ospell
Version: 0.4.5~r343-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

hfst-ospell fails to cross build from source. It runs the test suite
despite being asked not to do so (DEB_BUILD_OPTIONS=nocheck) and fails
doing so (as host architecture code fails to execute). After honouring
that flag, it cross builds successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru hfst-ospell-0.4.5~r343/debian/changelog 
hfst-ospell-0.4.5~r343/debian/changelog
--- hfst-ospell-0.4.5~r343/debian/changelog 2017-06-28 15:07:50.0 
+0200
+++ hfst-ospell-0.4.5~r343/debian/changelog 2017-07-26 21:41:19.0 
+0200
@@ -1,3 +1,10 @@
+hfst-ospell (0.4.5~r343-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Honour DEB_BUILD_OPTIONS=nocheck (closes: #-1).
+
+ -- Helmut Grohne   Wed, 26 Jul 2017 21:41:19 +0200
+
 hfst-ospell (0.4.5~r343-1) unstable; urgency=medium
 
   [ Tino Didriksen ]
diff --minimal -Nru hfst-ospell-0.4.5~r343/debian/rules 
hfst-ospell-0.4.5~r343/debian/rules
--- hfst-ospell-0.4.5~r343/debian/rules 2017-01-23 14:39:26.0 +0100
+++ hfst-ospell-0.4.5~r343/debian/rules 2017-07-26 21:41:16.0 +0200
@@ -26,5 +26,7 @@
dh_auto_install
find $(CURDIR) -type f -name '*.la' -exec rm -f '{}' \;
 
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
 override_dh_auto_test:
make -j1 check
+endif

Bug#635964: Newest version is now 3.3.2

[Markus Koschany]

Am 26.07.2017 um 21:10 schrieb Wouter Verhelst:
> Package: pdfsam
> Version: 1.1.4-4
> Followup-For: Bug #635964
> 
> Newest version of pdfsam on pdfsam.org is now v3.3.2 (see
> https://github.com/torakiki/pdfsam/releases for the list of known
> releases).
> 
> This version of pdfsam is now 7 years out of date. It should either be
> updated, or removed from the archive; this is getting ridiculous.

Hello Woulter,

I have been working on an update for pdfsam for the last month. It is
almost finished but the last package, fontawesomefx, is still waiting in
the NEW queue. [1]

In total twelve new packages had to be packaged, another package
upgraded to the latest version, reverse-dependencies checked and bug
reports filed. Please be patient a little more, we will help you soon.

Markus


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



signature.asc
Description: OpenPGP digital signature

Bug#809429: gwenview: Sound set at max when playing video

[Giorgos Pallas]

Package: gwenview
Version: 4:16.08.3-3
Followup-For: Bug #809429

Dear Maintainer,

Problem still exists on gwenview, at a fresh debian stretch installation.

Giorgos Pallas

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

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

Versions of packages gwenview depends on:
ii  kinit   5.28.0-1
ii  kio 5.28.0-2
ii  libc6   2.24-11+deb9u1
ii  libexiv2-14 0.25-3.1
ii  libgcc1 1:6.3.0-18
ii  libjpeg62-turbo 1:1.5.1-2
ii  libkf5activities5   5.28.0-1
ii  libkf5baloo55.28.0-2
ii  libkf5completion5   5.28.0-1
ii  libkf5configcore5   5.28.0-2
ii  libkf5configgui55.28.0-2
ii  libkf5configwidgets55.28.0-2
ii  libkf5coreaddons5   5.28.0-2
ii  libkf5filemetadata3 5.28.0-1+b2
ii  libkf5i18n5 5.28.0-2
ii  libkf5iconthemes5   5.28.0-2
ii  libkf5itemmodels5   5.28.0-2
ii  libkf5itemviews55.28.0-1
ii  libkf5jobwidgets5   5.28.0-2
ii  libkf5kdcraw5   16.04.0-2
ii  libkf5kdelibs4support5  5.28.0-1
ii  libkf5kiocore5  5.28.0-2
ii  libkf5kiofilewidgets5   5.28.0-2
ii  libkf5kiowidgets5   5.28.0-2
ii  libkf5kipi31.0.04:16.08.2-1
ii  libkf5notifications55.28.0-1
ii  libkf5parts55.28.0-1
ii  libkf5service-bin   5.28.0-1
ii  libkf5service5  5.28.0-1
ii  libkf5textwidgets5  5.28.0-1
ii  libkf5widgetsaddons55.28.0-3
ii  libkf5xmlgui5   5.28.0-1
ii  liblcms2-2  2.8-4
ii  libphonon4qt5-4 4:4.9.0-4
ii  libpng16-16 1.6.28-1
ii  libqt5core5a5.7.1+dfsg-3+b1
ii  libqt5gui5  5.7.1+dfsg-3+b1
ii  libqt5opengl5   5.7.1+dfsg-3+b1
ii  libqt5printsupport5 5.7.1+dfsg-3+b1
ii  libqt5svg5  5.7.1~20161021-2+b2
ii  libqt5widgets5  5.7.1+dfsg-3+b1
ii  libqt5x11extras55.7.1~20161021-2
ii  libstdc++6  6.3.0-18
ii  libx11-62:1.6.4-3
ii  phonon4qt5  4:4.9.0-4

Versions of packages gwenview recommends:
ii  kamera 4:16.08.3-1
ii  kio-extras 4:16.08.3-1
ii  qt5-image-formats-plugins  5.7.1~20161021-2

gwenview suggests no packages.

-- no debconf information

Bug#869824: missing package

[Rudolf Polzer]

Package: linux-headers-amd64
Version: 4.11.0-2-amd64

this package is missing

Bug#869823: tiff: CVE-2017-11613

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.8-1
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for tiff.

CVE-2017-11613[0]:
| In LibTIFF 4.0.8, there is a denial of service vulnerability in the
| TIFFOpen function. A crafted input will lead to a denial of service
| attack. During the TIFFOpen process, td_imagelength is not checked. The
| value of td_imagelength can be directly controlled by an input file. In
| the ChopUpSingleUncompressedStrip function, the _TIFFCheckMalloc
| function is called based on td_imagelength. If we set the value of
| td_imagelength close to the amount of system memory, it will hang the
| system or trigger the OOM killer.

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-11613
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11613
[1] https://gist.github.com/dazhouzhou/1a3b7400547f23fe316db303ab9b604f

Can you check if that was as well reported upstream
Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#868267: fai-client: fetch-basefile breaks for hostnames with hyphens

[Thomas Lange]

> On Wed, 26 Jul 2017 11:45:20 -0400, Arcady Genkin  
> said:

> I think that the
> approach to replace hyphens and any other illegal characters with 
underscores
> is a very good one.

And we have dots in FQDN, which are currently also not allowed in
class names. Should we truncate the FQDN before defining the hostname
as a class or replace  the dots with the underscore?

-- 
regards Thomas

Bug#635964: Newest version is now 3.3.2

[Wouter Verhelst]

Package: pdfsam
Version: 1.1.4-4
Followup-For: Bug #635964

Newest version of pdfsam on pdfsam.org is now v3.3.2 (see
https://github.com/torakiki/pdfsam/releases for the list of known
releases).

This version of pdfsam is now 7 years out of date. It should either be
updated, or removed from the archive; this is getting ridiculous.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

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

Versions of packages pdfsam depends on:
ii  default-jre [java2-runtime]2:1.8-59
ii  java-wrappers  0.1.28
ii  libcommons-httpclient-java 3.1-12
ii  libdom4j-java  1.6.1+dfsg.3-2
ii  libitext-java  2.1.7-11
ii  libjaxen-java  1.1.6-1
ii  libjgoodies-looks-java 2.7.0-2
ii  liblog4j1.2-java   1.2.17-7
ii  openjdk-8-jre [java2-runtime]  8u131-b11-2
ii  openjdk-9-jre [java2-runtime]  9~b170-2

pdfsam recommends no packages.

pdfsam suggests no packages.

-- no debconf information

Bug#845054: openscenegraph-3.4 FTBFS on armel

[Emilio Pozuelo Monfort]

Control: tags -1 patch

On Sat, 19 Nov 2016 23:27:24 +0200 Adrian Bunk  wrote:
> Source: openscenegraph-3.4
> Version: 3.4.0+dfsg1-4
> Severity: important
> 
> https://buildd.debian.org/status/fetch.php?pkg=openscenegraph-3.4=armel=3.4.0%2Bdfsg1-4=1474679517
> 
> In file included from /usr/include/GL/gl.h:2055:0,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/build/osg/include/osg/GL:113,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osg/GLDefines:25,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osg/GLExtensions:18,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osg/State:18,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osg/GraphicsContext:17,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osgViewer/GraphicsWindow:17,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osgQt/GraphicsWindowQt:19,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/src/osgQt/GraphicsWindowQt.cpp:15:
> /usr/include/GL/glext.h:468:19: error: conflicting declaration 'typedef 
> ptrdiff_t GLsizeiptr'
>  typedef ptrdiff_t GLsizeiptr;
>^~
> In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:95:0,
>  from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:39,
>  from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGLWidget:1,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osgQt/GraphicsWindowQt:17,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/src/osgQt/GraphicsWindowQt.cpp:15:
> /usr/include/GLES3/gl3.h:69:25: note: previous declaration as 'typedef 
> khronos_ssize_t GLsizeiptr'
>  typedef khronos_ssize_t GLsizeiptr;
>  ^~
> In file included from /usr/include/GL/gl.h:2055:0,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/build/osg/include/osg/GL:113,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osg/GLDefines:25,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osg/GLExtensions:18,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osg/State:18,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osg/GraphicsContext:17,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osgViewer/GraphicsWindow:17,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osgQt/GraphicsWindowQt:19,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/src/osgQt/GraphicsWindowQt.cpp:15:
> /usr/include/GL/glext.h:469:19: error: conflicting declaration 'typedef 
> ptrdiff_t GLintptr'
>  typedef ptrdiff_t GLintptr;
>^~~~
> In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:95:0,
>  from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:39,
>  from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGLWidget:1,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/include/osgQt/GraphicsWindowQt:17,
>  from 
> /«BUILDDIR»/openscenegraph-3.4-3.4.0+dfsg1/src/osgQt/GraphicsWindowQt.cpp:15:
> /usr/include/GLES3/gl3.h:70:26: note: previous declaration as 'typedef 
> khronos_intptr_t GLintptr'
>  typedef khronos_intptr_t GLintptr;
>   ^~~~
> src/osgQt/CMakeFiles/osgQt.dir/build.make:66: recipe for target 
> 'src/osgQt/CMakeFiles/osgQt.dir/GraphicsWindowQt.o' failed
> make[3]: *** [src/osgQt/CMakeFiles/osgQt.dir/GraphicsWindowQt.o] Error 1

I believe the attached patch should fix this bug (untested). The problem is that
Qt is using GLES on armel, but you're using big GL, and you can't mix them.

Cheers,
Emilio
diff -ruNp openscenegraph-3.4-3.4.0+dfsg1/debian/control openscenegraph-3.4-3.4.0+dfsg1.new/debian/control
--- openscenegraph-3.4-3.4.0+dfsg1/debian/control	2016-09-21 20:54:06.0 +0200
+++ openscenegraph-3.4-3.4.0+dfsg1.new/debian/control	2017-07-26 20:49:29.962498128 +0200
@@ -19,10 +19,10 @@ Build-Depends: debhelper (>= 7.0.50),
libgdal-dev,
libx11-dev,
libxmu-dev,
-   freeglut3-dev [!armhf],
-   libgl1-mesa-dev [!armhf] | libgl-dev [!armhf],
-   libegl1-mesa-dev [armhf],
-   libgles2-mesa-dev [armhf],
+   freeglut3-dev [!armel !armhf],
+   libgl1-mesa-dev [!armel !armhf] | libgl-dev [!armel !armhf],
+   libegl1-mesa-dev [armel armhf],
+   libgles2-mesa-dev [armel armhf],
libxine2-dev,
libavcodec-dev,
libswscale-dev,
@@ -44,8 +44,8 @@ Section: libdevel
 Architecture: any
 Depends: ${misc:Depends},
  libopenthreads-dev,
-   

Bug#868869: debian-installer should not recommend to change password periodically (and more)

[Brian Potkin]

On Wed 26 Jul 2017 at 17:00:12 +0100, Miguel Figueiredo wrote:

> On 24-07-2017 11:38, Hideki Yamane wrote:
> >Hi,
> >
> >On Sun, 23 Jul 2017 10:49:53 +0200
> >Philipp Kern  wrote:
> >>It seems to me that today at least the guidance of mixed
> >>character classes still makes some sense as a default, to avoid the most
> >>obvious blunder of just using a simple dictionary word and be
> >>compromised over SSH because password authentication is turned on.
> >
> >  Okay, I agree with it.
> >
> >>And change it to make brute force attacks harder.
> >
> >  But it also makes administrator to remember it harder as its trade-off...
> >  (and they maybe choose easy password as a result). It's a not good idea
> >  to suggests to change root password periodically, IMO. It's not a best
> >  practice.
> >
> >  1) Add password check feature whether password has an enough strength
> > like RHEL's anaconda or SUSE's installer.
> >  2) Drop suggestion root password change periodically from message.
> >
> >  is better.
> 
> We have libpam-passwqc on the archive, which it's a "Password
> quality-control PAM module".
> I think it addresses the point of checking the password strength.

It possibly does, but isn't it more suitable as a solution to
#854653 or #364526 rather than this bug (changing a password at
periodic intervals, no matter how strong it is)?

-- 
Brian.

Bug#869822: album-data: Correct invalid Vcs-Git URI.

[Chris Lamb]

Source: album-data
Version: 4.05-7
Severity: normal
Tags: patch

Hi,

Patch attached that corrects a typo in the Vcs-Git URI.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/control b/debian/control
index 91ac165..d19eb79 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Salvo 'LtWorf' Tomaselli 
 Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.7
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/album-data.git
-Vcs-Git: https://anonscm.debian.org/git/collab-maint/album.data.git
+Vcs-Git: https://anonscm.debian.org/git/collab-maint/album-data.git
 Homepage: http://marginalhacks.com/Hacks/album
 
 Package: album-data

Bug#852324: Disable CONFIG_DEBUG_WX in order to avoid this issue.

[Helio Loureiro]

Hi,

I don't owe the server.  Just have a VM that was running flawless with
Debian since Squeeze.

And for the first time Debian became a sour option.

I was going to compile another kernel when I found also kernel-package
isn't released because of unwatched issues.

Best Regards,
Helio

Bug#863568: ..and of course I forgot the attachment

[solo-debianbugs]

diff --git a/cfengine3-3.9.1/cf-key/cf-key-functions.c b/cfengine3-3.9.1/cf-key/cf-key-functions.c
index 7c53ee5..5287b2c 100644
--- a/cfengine3-3.9.1/cf-key/cf-key-functions.c
+++ b/cfengine3-3.9.1/cf-key/cf-key-functions.c
@@ -48,6 +48,7 @@ RSA *LoadPublicKey(const char *filename)
 {
 FILE *fp;
 RSA *key;
+const BIGNUM *n, *e;
 
 fp = safe_fopen(filename, "r");
 if (fp == NULL)
@@ -69,7 +70,9 @@ RSA *LoadPublicKey(const char *filename)
 
 fclose(fp);
 
-if (BN_num_bits(key->e) < 2 || !BN_is_odd(key->e))
+RSA_get0_key(key, , , NULL);
+
+if (BN_num_bits(e) < 2 || !BN_is_odd(e))
 {
 Log(LOG_LEVEL_ERR, "Error while reading public key '%s' - RSA Exponent is too small or not odd. (BN_num_bits: %s)",
 filename, GetErrorStr());
diff --git a/cfengine3-3.9.1/cf-serverd/server_classic.c b/cfengine3-3.9.1/cf-serverd/server_classic.c
index 5e610da..f50dc01 100644
--- a/cfengine3-3.9.1/cf-serverd/server_classic.c
+++ b/cfengine3-3.9.1/cf-serverd/server_classic.c
@@ -569,6 +569,7 @@ static void SetConnectionData(ServerConnectionState *conn, char *buf)
 static int CheckStoreKey(ServerConnectionState *conn, RSA *key)
 {
 RSA *savedkey;
+const BIGNUM *key_n, *key_e, *savedkey_n, *savedkey_e;
 
 const char *udigest = KeyPrintableHash(ConnectionInfoKey(conn->conn_info));
 assert(udigest != NULL);
@@ -579,7 +580,10 @@ static int CheckStoreKey(ServerConnectionState *conn, RSA *key)
 "A public key was already known from %s/%s - no trust required",
 conn->hostname, conn->ipaddr);
 
-if ((BN_cmp(savedkey->e, key->e) == 0) && (BN_cmp(savedkey->n, key->n) == 0))
+RSA_get0_key(key, _n, _e, NULL);
+RSA_get0_key(savedkey, _n, _e, NULL);
+
+if ((BN_cmp(savedkey_e, key_e) == 0) && (BN_cmp(savedkey_n, key_n) == 0))
 {
 Log(LOG_LEVEL_VERBOSE,
 "The public key identity was confirmed as %s@%s",
@@ -772,6 +776,7 @@ char iscrypt, enterprise_field;
 
 /* proposition C2 - Receive client's public key modulus */
 RSA *newkey = RSA_new();
+BIGNUM *newkey_n, *newkey_e;
 {
 
 int len_n = ReceiveTransaction(conn->conn_info, recvbuffer, NULL);
@@ -783,7 +788,7 @@ RSA *newkey = RSA_new();
 return false;
 }
 
-if ((newkey->n = BN_mpi2bn(recvbuffer, len_n, NULL)) == NULL)
+if ((newkey_n = BN_mpi2bn(recvbuffer, len_n, NULL)) == NULL)
 {
 Log(LOG_LEVEL_ERR, "Authentication failure: "
 "private decrypt of received public key modulus failed "
@@ -804,16 +809,19 @@ RSA *newkey = RSA_new();
 return false;
 }
 
-if ((newkey->e = BN_mpi2bn(recvbuffer, len_e, NULL)) == NULL)
+if ((newkey_e = BN_mpi2bn(recvbuffer, len_e, NULL)) == NULL)
 {
 Log(LOG_LEVEL_ERR, "Authentication failure: "
 "private decrypt of received public key exponent failed "
 "(%s)", CryptoLastErrorString());
+BN_free(newkey_n);
 RSA_free(newkey);
 return false;
 }
 }
 
+RSA_set0_key(newkey, newkey_n, newkey_e, NULL);
+
 /* Compute and store hash of the client's public key. */
 {
 Key *key = KeyNew(newkey, CF_DEFAULT_DIGEST);
@@ -891,18 +899,21 @@ RSA *newkey = RSA_new();
 
 /* proposition S4, S5 - If the client doesn't have our public key, send it. */
 {
+const BIGNUM *n, *e;
 if (iscrypt != 'y')
 {
 Log(LOG_LEVEL_DEBUG, "Sending server's public key");
 
 char bignum_buf[CF_BUFSIZE] = { 0 };
 
+RSA_get0_key(PUBKEY, , , NULL);
+
 /* proposition S4  - conditional */
-int len_n = BN_bn2mpi(PUBKEY->n, bignum_buf);
+int len_n = BN_bn2mpi(n, bignum_buf);
 SendTransaction(conn->conn_info, bignum_buf, len_n, CF_DONE);
 
 /* proposition S5  - conditional */
-int len_e = BN_bn2mpi(PUBKEY->e, bignum_buf);
+int len_e = BN_bn2mpi(e, bignum_buf);
 SendTransaction(conn->conn_info, bignum_buf, len_e, CF_DONE);
 }
 }
diff --git a/cfengine3-3.9.1/cf-serverd/server_common.c b/cfengine3-3.9.1/cf-serverd/server_common.c
index 64e04a4..e4e01e2 100644
--- a/cfengine3-3.9.1/cf-serverd/server_common.c
+++ b/cfengine3-3.9.1/cf-serverd/server_common.c
@@ -557,7 +557,7 @@ void CfEncryptGetFile(ServerFileGetState *args)
 unsigned char iv[32] =
 { 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8 };
 int blocksize = CF_BUFSIZE - 4 * CF_INBAND_OFFSET;
-EVP_CIPHER_CTX ctx;
+EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
 char *key, enctype;
 struct stat sb;
 ConnectionInfo *conn_info = args->conn->conn_info;
@@ -581,7 +581,7 @@ void CfEncryptGetFile(ServerFileGetState *args)
 FailedTransfer(conn_info);
 }
 
-EVP_CIPHER_CTX_init();
+EVP_CIPHER_CTX_init(ctx);
 
 if ((fd = safe_open(filename, O_RDONLY)) == -1)
 {
@@ -630,20 +630,20 @@ void CfEncryptGetFile(ServerFileGetState *args)
 
 if (n_read > 0)
   

Bug#869729: apache2: 'service apache2 restart' sometimes stops without restarting

[Stefan Fritsch]

Is there anything relevant in the log files?

In the apache error log?
In the output of "journalctl -u apache2.service"?
For the upgrades, if you still know the date, look into /var/log/apt/term.log* 

Cheers,
Stefan

Bug#852324: Disable CONFIG_DEBUG_WX in order to avoid this issue.

[Ian Campbell]

On Wed, 2017-07-26 at 19:23 +0200, Helio Loureiro wrote:
> Hi,
> 
> I already sent.

Please provide a full serial log when booting with the bad kernel.

Also please let us know what version of Xen you are running and whether
this was running as a guest or as dom0.

> And in the first post in this bug it says:
> 
> "
> When I boot my system with Xen, I get the following section in dmesg:
[   13.588386] WARNING: CPU: 18 PID: 1 at 
/build/linux-zDY19G/linux-4.8.15/arch/x86/mm/dump_pagetables.c:225 
note_page+0x5e8/0x790
> [...]
> [   13.588392] CPU: 18 PID: 1 Comm: swapper/0 Not tainted 4.8.0-2-amd64 #1 
> Debian 4.8.15-2
> [...]
> But when I boot my system 'normally', ie without Xen, the error does
> not
> show up."
> He clearly states it isn't booting.  It is crashing.

The original bug report was running the same kernel as the splat at the
point where reportbug was run, so it is booting at least far enough to
do that. See the "Kernel: Linux 4.8.0-2-amd64" in the original report,
which is also in the warning message.

There is no suggestion anywhere that it isn't booting in the original
report, just that when it does boot this message appears in the logs.
All he says is that this warning (he says "error", but that doesn't
imply a boot failure either) doesn't appear with the normal kernel.

See also the logs at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
852324#25 which show the system continuing to successfully boot after
the splat.

> How could that not be related?

Because you are experiencing some other bug later on, or perhaps the
check which resulting in a WARNING for the original poster has a bug in
it which is causing a hang for you, please provide us with the
information we need in order to diagnose which it is rather than
continuing to assert that it is the same issue, otherwise no progress
is going to happen here.

Ian.

Bug#869821: xournal: Please package newest version 0.4.8.2016 which fixes several bugs

[Hendrik Langer]

Package: xournal
Version: 1:0.4.8-1+b1
Severity: normal

Dear Maintainer,

recently upstream released a bugfix-release: 0.4.8.2016
the current packaged version is now 3 years old and contains several annoying
minor bugs which were fixed in 2016.

Upstream bugreport:https://sourceforge.net/p/xournal/bugs/182/
Commit(Changes):
https://sourceforge.net/p/xournal/code/ci/25b6ffc05f1a68728b69b5c122abc68d660df940/

Please package the new version. Thanks!



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

Kernel: Linux 4.12.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE.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.21~dfsg-1
ii  libart-2.0-2 2.3.21-2
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8-0.2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.52.3-1
ii  libgnomecanvas2-02.30.3-3
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libpangoft2-1.0-01.40.6-1
ii  libpoppler-glib8 0.48.0-2
ii  libx11-6 2:1.6.4-3
ii  zlib1g   1:1.2.8.dfsg-5

xournal recommends no packages.

xournal suggests no packages.

-- no debconf information

Bug#863568: cfengine3 + libssl1.1 patch

[Chris West]

Control: tags -1 + patch

The attached patch fixes the build with OpenSSL 1.1.

I have submitted a very similar patch upstream; against master:
https://github.com/cfengine/core/pull/2890

This mostly involves just a few small changes in how APIs work; using
accessors, or not having stack allocated objects.

The major changes for review are:

 * `tls_generic_test.c` just cannot work anymore. It is reimplementing
   an old version of OpenSSL, relying too heavily on the OpenSSL
   internals, which are no-longer exposed. I have removed it from
   `Makefile.am`, but not deleted the code. I attempted to port it,
   but it's pretty impossible.
 * The `session_key` changes in `libcfnet/client_protocol.c` look like
   they leak a `malloc`, but they don't; the `session_key` is
   eventually freed by normal libc-`free` already; making assumptions
   about old OpenSSL internals. This code is actually arguably more
   correct like this.
 * I have deleted the key type checks in `libcfnet/tls_generic.c`. The
   functions that are called immediately after this are documented to
   safely fail if the key is not of the right format. Checking the
   type directly isn't really supported anymore.

This passes dpkg-buildpackage, which runs the unit tests, in my sid chroot.

Chris.

Bug#868267: fai-client: fetch-basefile breaks for hostnames with hyphens

[andrew bezella]

On Wed, 2017-07-26 at 08:35 -0700, andrew bezella wrote:
> it could perhaps be re-worded along the lines of "All class names are
> restricted to uppercase letters and underscores [A-Z_] (except the
> FAI-
> defined class matching the hostname)" and maybe placed more
> prominently
> in the man page and other documentation (and i just noticed there's a
> typo in there: "execpt" -> "except")

oh, i forgot that digits are also allowed.  so if a documentation
update comes out of this, maybe:
"All class names are restricted to uppercase alphanumeric and
underscores [[:upper:][:digit:]_] (except the FAI-defined class
matching the hostname)"

-- 
andrew bezella 
internet archive

Bug#869820: gcc-7-cross-ports: Please build gnat-7 cross-compiler for m68k

[John Paul Adrian Glaubitz]

Source: gcc-7-cross-ports
Version: 6.3.0-18cross1
Severity: normal

Hi!

Now that #862927 has been resolved, please remember to build the gnat-7
cross-compiler for m68k in the next upload.  It's then easier to cross-build
a native compiler and continue working on the gnat-7 issue on m68k with
the native compiler [1].

Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81495

--
 .''`.  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

Bug#869797: t1disasm: integer overflow in eexec_line()

[Jakub Wilk]

* Niels Thykier , 2017-07-26, 16:57:
For good measure, could you please confirm if this issue persists with 
-D_GNU_SOURCE ?


Yes, it persists.

--
Jakub Wilk

Bug#869792: Can only save either none or all passwords

[Mike Miller]

On Wed, Jul 26, 2017 at 15:34:58 +0200, Sven Bartscher wrote:
> When connecting to a VPN with juniper I get asked for a username and
> password and get the option to "Save passwords". The particular VPN
> I'm connecting to requires me to first enter a username and a password
> and afterwards asks me for a one-time password.
> 
> While it makes sense for me to save the first username and password,
> saving the one-time password doesn't make sense. Unfortunately the
> "Save passwords" option seems to affect all entered passwords at once,
> so I can either save all entered passwords or none of them.
> 
> I can work around this by just saving the one-time password. NM then
> tries to connect using the saved passwords, notices that the one-time
> password got rejected and asks me for it again. This works, but has
> the unfortunate side effect of making an unsuccessful authentication
> attempt on every connect, which causes me to get locked out of the VPN
> temporarily if I connect too often in a short amount of time.
> 
> It would be really great if it were possible to choose whether to save
> or not save for each password individually.

Thanks for your bug report. This has been reported and is being
discussed upstream, take a look at [1].

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=782480

-- 
mike


signature.asc
Description: PGP signature

Bug#866965: dosemu: DPMI unhandled exception instability back again

[Iván Baldo]

Hello. 
Being hit by this on current Stretch, pkzip.exe doesn't work for example. 
Anyone knows of any workaround for this? 
Thanks a lot! 

-- 
Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ 
Freelance C++/PHP programmer and GNU/Linux systems administrator. 
The sky is not the limit! 

Bug#727096: uscan: store signature for upstream tarball in debian/

[Sven Joachim]

On 2016-04-12 09:19 +0200, Ansgar Burchardt wrote:

> Paul Wise  writes:
>> On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote:
>>> uscan would store the signature for the upstream tarball as
>>> obtained via pgpsigurlmangle=... in the debian/ directory
>>
>> ISTR another idea was to place the upstream signature alongside the
>> upstream tarball instead of inside the debian/ directory.
>>
>> foo_0.1.2.orig.tar.gz
>> foo_0.1.2.orig.tar.gz..asc
>>
>> AFAIR, there was some work in dak done already to allow this?
>
> Yes, but there was a bug and I somehow forgot about the patches in
> #759401 that Guillem Jover provided. So dak should now accept upstream
> signatures, dpkg in stable should ignore them (but not throw an error)
> and dpkg in unstable/testing will hopefully start to include them in the
> source package (.dsc) soon.
>
> For a given upstream tarball the upstream signature should go in a file
> with the extension `.asc`. For example, for
>   dune-common_2.4.1.orig.tar.xz
> the signature should be in
>   dune-common_2.4.1.orig.tar.xz.asc

FWIW, lintian 2.5.52 throws an error
("orig-tarball-missing-upstream-signature") if the file is not there.

> It should be safe for uscan to already create this file: older versions
> of dpkg should just ignore it.

Uscan already stores the upstream signature, albeit under a different
filename ending in .pgp.  All it needs to do is to create a link for it
under the name that dpkg-source and lintian expect (unless the upstream
tarball needs to be repacked, that is).

Cheers,
   Sven

Bug#869819: ITP: golang-github-denverdino-aliyungo -- Go SDK for Aliyun (Alibaba Cloud)

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: golang-github-denverdino-aliyungo
  Version : 0.0~git20170721.0.80ceb80-1
  Upstream Author : Li Yi
* URL : https://github.com/denverdino/aliyungo
* License : Apache-2.0
  Programming Lang: Go
  Description : Go SDK for Aliyun (Alibaba Cloud)

 This is an unofficial Go SDK for Aliyun Services.
 .
 Following services are supported:
   * ecs: Elastic Compute Service
   * oss: Open Storage Service
   * slb: Server Load Balancer
   * dns: DNS
   * sls: Logging Service
   * ram: Resource Access Management
   * rds: Relational Database Service
   * cms: Cloud Monitor Service
   * cs: Container Service
   * sts: Security Token Service
   * dm: Direct Mail
   * sms: Short Message Service
   * push: Cloud Mobile Push
   * opensearch: OpenSearch
   * mq: Message Queue
   * nas: Network Attached Storage
   * common: Common libary of Aliyun Go SDK
   * util: Utility helpers

It's the new dependency for packer.

I will package this inside pkg-go team and need sponsor as well.

Regards,
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#869818: git-ftp: git ftp download can remove .git directory

[Ferenc Wágner]

Package: git-ftp
Version: 1.3.1-1
Severity: normal
Tags: patch upstream
Forwarded: https://github.com/git-ftp/git-ftp/issues/377

Dear Maintainer,

Please consider this session:

$ git init
[...]
$ git config git-ftp.user myuser
$ git config git-ftp.url sftp://my.serv.er/~/www/foo
$ echo .git-ftp-ignore >.git-ftp-ignore
$ git add .git-ftp-ignore
$ git commit -m dotfile
[...]
$ git ftp init
[...]
$ git ftp download --dry-run
cd ok, cwd=/www/foo
rm -r file:/home/wferi/ansible/foo/.git
Removed: 1 directory, 0 files, 0 symlinks

Hadn't I used --dry-run, git-ftp would have removed my .git directory.
I understand that download is experimental functionality, but nuking
the .git directory is very serious misbehaviour.

First I reported the issue upstream, and later I created a patch for it
as well, but I think a stable update is worth considering here.

Thanks,
Feri.

Bug#862305: transition: libwebp

[Jeff Breidenbach]

Beginning transition. Uploaded to unstable.

Bug#869817: nvidia-legacy-check_375.66-2~deb9u1 fails: + RET=20 Unsupported command "04:00.0"

[Olivier Crumeyrolle]

Package: nvidia-legacy-check
Version: 375.66-2~deb9u1
Severity: normal

Dear Maintainer,

Apparently a scripting issue prevents installation of package 
nvidia-legacy-check_375.66-2~deb9u1 when two graphics cards are present.

This hypothesis comes from the output of 
 
DEBUG_NVIDIA_LEGACY_CHECK=yes dpkg -i 
nvidia-legacy-check_375.66-2~deb9u1_amd64.deb

which shows  

+ RET=20 Unsupported command "04:00.0" (full line was "04:00.0 VGA compatible 
controller [0300]: NVIDIA Corporation G84GL [Quadro FX 570] [10de:040e] (rev 
a1)") received from confmodule.

as if the script tried to "execute" the second graphic card. 
Full transcript below.
Please note that this bug created significant trouble while 
dist-upgrading from jessie to stretch, as dpkg stops abruptly.

Regards,
Olivier


---output of DEBUG_NVIDIA_LEGACY_CHECK=yes dpkg -i 
nvidia-legacy-check_375.66-2~deb9u1_amd64.deb ---

(Reading database ... 179814 files and directories currently installed.)
Preparing to unpack nvidia-legacy-check_375.66-2~deb9u1_amd64.deb ...
+ [ install = install ]
+ check_for_unsupported_gpus
+ db_get nvidia-driver/check-for-unsupported-gpu
+ _db_cmd GET nvidia-driver/check-for-unsupported-gpu
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n GET nvidia-driver/check-for-unsupported-gpu
+ IFS= 

+ IFS=
 read -r _db_internal_line
+ RET=true
+ return 0
+ test true = true
+ msgpid=14644
+ + sleeppid=14646
find_unsupported_gpus
+ trap kill $sleeppid 2>/dev/null || true TERM
+ + lspci+  --versiontrap
 :sleep EXIT 30

+ wait 14646
+ lspci -mn
+ awk { gsub("\"",""); if ($2 == "0300") { print $1 " " $3$4 } }
+ + readtr dev [:lower:] id [:upper:]

+ [ 10DE0191 = 10DE040E ]
+ [ 10DE0193 = 10DE040E ]
+ [ 10DE0194 = 10DE040E ]
+ [ 10DE0197 = 10DE040E ]
+ [ 10DE019D = 10DE040E ]
+ [ 10DE019E = 10DE040E ]
+ [ 10DE0400 = 10DE040E ]
+ [ 10DE0401 = 10DE040E ]
+ [ 10DE0402 = 10DE040E ]
+ [ 10DE0403 = 10DE040E ]
+ [ 10DE0404 = 10DE040E ]
+ [ 10DE0405 = 10DE040E ]
+ [ 10DE0406 = 10DE040E ]
+ [ 10DE0407 = 10DE040E ]
+ [ 10DE0408 = 10DE040E ]
+ [ 10DE0409 = 10DE040E ]
+ [ 10DE040A = 10DE040E ]
+ [ 10DE040B = 10DE040E ]
+ [ 10DE040C = 10DE040E ]
+ [ 10DE040D = 10DE040E ]
+ [ 10DE040E = 10DE040E ]
+ echo 03:00.0
+ break
+ read dev id
+ [ 10DE0191 = 10DE040E ]
+ [ 10DE0193 = 10DE040E ]
+ [ 10DE0194 = 10DE040E ]
+ [ 10DE0197 = 10DE040E ]
+ [ 10DE019D = 10DE040E ]
+ [ 10DE019E = 10DE040E ]
+ [ 10DE0400 = 10DE040E ]
+ [ 10DE0401 = 10DE040E ]
+ [ 10DE0402 = 10DE040E ]
+ [ 10DE0403 = 10DE040E ]
+ [ 10DE0404 = 10DE040E ]
+ [ 10DE0405 = 10DE040E ]
+ [ 10DE0406 = 10DE040E ]
+ [ 10DE0407 = 10DE040E ]
+ [ 10DE0408 = 10DE040E ]
+ [ 10DE0409 = 10DE040E ]
+ [ 10DE040A = 10DE040E ]
+ [ 10DE040B = 10DE040E ]
+ [ 10DE040C = 10DE040E ]
+ [ 10DE040D = 10DE040E ]
+ [ 10DE040E = 10DE040E ]
+ echo 04:00.0
+ break
+ read dev id
+ UNSUPPORTED_DEVICES=03:00.0
04:00.0
+ lspci -nn -s 03:00.0
+ lspci -nn -s 04:00.0
+ UNSUPPORTED=03:00.0 VGA compatible controller [0300]: NVIDIA Corporation 
G84GL [Quadro FX 570] [10de:040e] (rev a1)
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84GL [Quadro FX 
570] [10de:040e] (rev a1)
+ kill 14644
+ test -n 03:00.0
04:00.0
+ db_subst nvidia-driver/install-even-if-unsupported-gpu-exists vendor NVIDIA
+ _db_cmd SUBST nvidia-driver/install-even-if-unsupported-gpu-exists vendor 
NVIDIA+ 
:
+ _db_internal_IFS= 

+ IFS= 
+ + killprintf 14646 %s\n
 SUBST nvidia-driver/install-even-if-unsupported-gpu-exists vendor NVIDIA
+ IFS= 

+ IFS=
 read -r _db_internal_line
+ RET=0
+ return 0
+ db_subst nvidia-driver/install-even-if-unsupported-gpu-exists driver 
nvidia-driver
+ _db_cmd SUBST nvidia-driver/install-even-if-unsupported-gpu-exists driver 
nvidia-driver
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n SUBST nvidia-driver/install-even-if-unsupported-gpu-exists driver 
nvidia-driver
+ IFS= 

+ IFS=
 read -r _db_internal_line
+ RET=0
+ return 0
+ db_subst nvidia-driver/install-even-if-unsupported-gpu-exists legacy_driver 
nvidia-legacy-340xx-driver
+ _db_cmd SUBST nvidia-driver/install-even-if-unsupported-gpu-exists 
legacy_driver nvidia-legacy-340xx-driver
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n SUBST nvidia-driver/install-even-if-unsupported-gpu-exists 
legacy_driver nvidia-legacy-340xx-driver
+ IFS= 

+ IFS=
 read -r _db_internal_line
+ RET=0
+ return 0
+ db_subst nvidia-driver/install-even-if-unsupported-gpu-exists free_name 
Nouveau
+ _db_cmd SUBST nvidia-driver/install-even-if-unsupported-gpu-exists free_name 
Nouveau
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n SUBST nvidia-driver/install-even-if-unsupported-gpu-exists 
free_name Nouveau
+ IFS= 

+ IFS=
 read -r _db_internal_line
+ RET=0
+ return 0
+ db_subst nvidia-driver/install-even-if-unsupported-gpu-exists free_driver 
xserver-xorg-video-nouveau
+ _db_cmd SUBST nvidia-driver/install-even-if-unsupported-gpu-exists 
free_driver xserver-xorg-video-nouveau
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n SUBST nvidia-driver/install-even-if-unsupported-gpu-exists 
free_driver 

Bug#868925: avrdude: FTBFS: configure.ac:33: error: version mismatch. This is Automake 1.15.1,

[Milan Kupcevic]

https://anonscm.debian.org/cgit/collab-maint/avrdude.git/commit/?id=777cf870879c9d14190dcce0fdd458283e48d5c2

Bug#869816: openjdk-7: several vulnerabilities

[Emilio Pozuelo Monfort]

Source: openjdk-7
Version: 7u131-2.6.9-3
Severity: grave

Hi,

openjdk-7 needs fixing for the recent Oracle CPU.

Thanks,
Emilio

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Bug#869665: libgit2-dev: please update version in Debian unstable and do a library transition

[Russell Sim]

Hey,

I'm about to do an upload and I was wondering if you thought it would make
sense to start shipping this package with a versioned -dev package.  At the
moment the dev package is un-versioned, and the upstream API can change
quite significantly with each release.  So I'm a bit worried that this will
cause package build failures if any rebuilds occur.  Does that make sense
to do this, or is that over complicating things?  I couldn't find any good
documentation about when it is appropriate to version a dev package.

I won't let this stop me uploading 0.25.1.0, but I'm curious about what
your opinion is?


On 25 July 2017 at 15:13, Ximin Luo  wrote:

> Package: libgit2-dev
> Version: 0.25.1.0-1
> Severity: normal
>
> Dear Maintainer,
>
> Now that the stretch freeze is over, please could you update libgit to
> 0.25.1
> (or 0.26 even) and do a library transition?
>
> We'd like to update rustc and cargo soon, without the embedded libraries. I
> took a brief look at the cargo source code and believe it ought to work
> with
> either 0.25.1 or 0.26, there is one breaking change [1] but cargo does not
> use
> that functionality.
>
> If you want to upload 0.25.1, I'd suggest the version "0.25.1.0" so that it
> sorts ahead of the current version "0.25.1+really0.24.6-1".
>
> X
>
> [1] https://github.com/libgit2/libgit2/releases/tag/v0.26.0
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
> 'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100,
> 'experimental'), (1, 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libgit2-dev depends on:
> ii  libcurl4-gnutls-dev7.52.1-5
> ii  libgit2-25 0.25.1.0-1
> ii  libhttp-parser-dev 2.1-2
> ii  libssh2-1-dev  1.8.0-1
> ii  zlib1g-dev [libz-dev]  1:1.2.8.dfsg-5
>
> libgit2-dev recommends no packages.
>
> libgit2-dev suggests no packages.
>
> -- no debconf information
>



-- 
Cheers,
Russell Sim

Bug#869745: bug confirm

[alcalina]

I also confirm the bug with the following enigmail/thunderbird versions:

enigmail: 2:1.8.2-4~deb8u1

thunderbird: 1:52.2.1-4~deb8u1

Bug#869557: apt: please make the output of apt-ftparchive reproducible

[David Kalnischkies]

Hi,

Seems like we perfectly misunderstood each other. :)

On Wed, Jul 26, 2017 at 12:31:39PM +0100, Chris Lamb wrote:
> > I have to say, the moo change was entertaining, but while I see why
> > someone might want that [0], I fail to see how that effects
> > reproducibility of anything.
> 
> I worry that you have misunderstood my bug report and patch. As I
> mention in the initial report, it was actually raised by a user who
> explicitly expressed a need and/or desire for it and they have
> subsequently thanked me for taking the effort to work on fixing their
> issue.

Do'h. hackernews references fail for me as they (as so many sites) are
annoying via tor (and was offline at time of reading), so my feeble
overprotective brain skipped over it… add that it is usertagged as
reproducible-builds and you get someone really confused in return.

Still, I don't see a big issue – or perhaps I see it as the biggest
issue that apt-ftparchive is used as you have yourself noted in the
thread "So many tools to do the same thing" and apt-ftparchive is pretty
old and low-level in this sea of options.

As noted in the P.S. the indexes can always be post-processed with
apt-sortpkgs which gets you reproducible indexes far better than sorting
by filepaths will, as the later can be effected by locale and is
a (probably very small) price maybe not everyone wants to pay.
Especially if an explicit order was already defined by a file list.


> I was also disappointed to read that you — or anyone — might think that
> my position as the current DPL would have any standing whatsoever on
> the applicability of bug reports or technical issues.

That makes two then, as that would indeed be a lousy argument. Hence me
asking why, ignoring that it was already provided, but skipped over.
Still, for most bugs I would prefer if the actual user is reporting them
rather than a proxy (DPL or not) and without external references simple
because it is easier to justify working for a user who went through the
trouble to report a bug.


Perhaps it helps a bit if I explain a bit where I am coming from:
apt-ftparchive is in pretty low-maintenance mode from our side,
basically just ensuring it isn't breaking too hard for the few existing
users. And with users I mainly mean launchpad which seems to use the
libdb part nobody else does, our testcases which use 'generate' and many
homegrown scripts. The later group would usually be better of using
a different tool, but doesn't for various good or less good reasons
(none mentioned in the thread).

At least the first two aren't effected as they use filelists. A good
part of the last group isn't effected either – so I wondered if someone
is actually really benefiting from this or if its just asked for
"because" like https. Henry Ford maybe said "If I had asked what they
wanted, they would have said 'faster horses'". We could be sorting the
output, but a user wanting that could have that already now with
apt-sortpkgs instead of waiting 2+ years for it (= optimism, archive
builders tend to be very slowly updated, which makes the feedback loop
if we break something so tiring). And if a more integrated feeling is
wanted, perhaps apt-ftparchive isn't the tool the user is looking for in
the first place (compare 'faster horses').


So yes, I still wonder why and if its a worthwhile time investment for
us as well as for the user to work on/use apt-ftparchive – and as said
style issues with the patch and the problem that it effects filelist
which it shouldn't.  Lastly, we have basically no test covering this
which conflicts with the no-new-untested code rule we try to enforce
meaning yet more work.

(Then again, in the time I wrote the mails, I could have probably just
written a few alibi tests and fix the patch, … oh well.)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#869070: apt-listbugs does not honor Acquire::http::TimeOut

[Francesco Poli]

Control: tags -1 + moreinfo


On Fri, 21 Jul 2017 03:23:13 +0200 Vincent Lefevre wrote:

> Hi Francesco,
> 
> On 2017-07-20 23:45:54 +0200, Francesco Poli wrote:
> > While it's true that the man page states what you quoted, it also goes
> > on stating:
> > 
> > | The notable configuration options are
> > 
> > followed by a list of the options that are read and used by apt-listbugs.
> > And Acquire::http::TimeOut is _not_ included in the list...
> 
> If you meant that these are the only supported options, then "notable"
> is not the right word (as I understood "notable configuration
> options", I thought these were the most important options in
> practice, in the context of apt-listbugs).

Maybe "relevant" would be clearer: what do you think?

> 
> > As far as the feature request itself is concerned, it seems to me
> > that apt.conf(5) man page says:
> > 
> > | The option timeout sets the timeout timer used by the method; this
> > | value applies to the connection as well as the data timeout.
> > 
> > It's not too clear to me whether the value is in seconds or in some
> > other unit of measurement. Where is this documented?
> 
> I was wondering the same thing (since I had to use this option for
> "apt"), and assumed that this was in seconds, as this is the standard
> time unit (and the man page also mentions "seconds" for other time
> options). And indeed, this corresponds to the observed behavior.

OK, maybe you should ask for confirmation to Apt developers and request
them to properly document that the timeout has to be specified in
seconds.

> 
> > Anyway, I'll try and take a look at some method to set the timeout
> > for ruby-httpclient. Let's hope it's not too difficult to do.
> 
> That would be strange that standard modules wouldn't allow a
> configurable timeout.

Could you please perform the following test?

As root, back up one file:

  # cp -ai /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb /root/

Then, edit lines 35÷37 of the file itself (using VIM or any other
editor of your choice):

  # vim /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb

Please try to set 10 (in stead of 999) for the three timeout values.

Does this solve your issue?

Please take into account that I seem to understand that send_timeout
will be ignored, unless you have the recommended ruby-httpclient
package installed...

After doing the test, in case you want to restore the previous clean
state, please restore the backed up file:

  # cp -a /root/btssoap.rb /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/


Please let me know how it went.
Thanks for your time.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpT47WKnctgS.pgp
Description: PGP signature

Bug#852324: linux-image-3.16.0-4-amd64: Info from `reportbug kernel` but probably useless.

[Helio Loureiro]

Package: src:linux
Followup-For: Bug #852324

Dear Maintainer,

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

   * What led up to the situation?
 Relesed Stretch kernel doesn't boot, crashing the system.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Rollbacked to kernel from Jessie.
   * What was the outcome of this action?
 System is back online but this bug report is probably useless.
   * What outcome did you expect instead?
 To be fixed since this bug was reported in January and no actions were
taken.

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


-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26)

** Command line:
root=/dev/xvda1

** Not tainted

** Kernel log:

** Model information
not available

** Loaded modules:
dm_mod
nfnetlink_log
nfnetlink
binfmt_misc
ip6t_REJECT
xt_hl
ip6t_rt
nf_conntrack_ipv6
nf_defrag_ipv6
ipt_REJECT
xt_comment
xt_LOG
xt_limit
xt_tcpudp
xt_addrtype
thermal_sys
coretemp
crct10dif_pclmul
crct10dif_common
crc32_pclmul
nf_conntrack_ipv4
nf_defrag_ipv4
crc32c_intel
xt_conntrack
aesni_intel
evdev
aes_x86_64
lrw
gf128mul
glue_helper
ablk_helper
xen_netfront
pcspkr
cryptd
ip6table_filter
ip6_tables
nf_conntrack_netbios_ns
nf_conntrack_broadcast
nf_nat_ftp
nf_nat
nf_conntrack_ftp
nf_conntrack
iptable_filter
loop
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
xen_blkfront

** PCI devices:

** USB devices:
not available


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

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

Versions of packages linux-image-3.16.0-4-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.61
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-3.16.0-4-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-3.16.0-4-amd64 suggests:
pn  debian-kernel-handbook 
pn  grub-pc | grub-efi | extlinux  
pn  linux-doc-3.16 

Versions of packages linux-image-3.16.0-4-amd64 is related to:
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
pn  firmware-iwlwifi
pn  firmware-libertas   
pn  firmware-linux  
pn  firmware-linux-nonfree  
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
pn  firmware-ralink 
pn  firmware-realtek
pn  xen-hypervisor  

-- debconf information:
  linux-image-3.16.0-4-amd64/postinst/mips-initrd-3.16.0-4-amd64:
  linux-image-3.16.0-4-amd64/prerm/removing-running-kernel-3.16.0-4-amd64:
true
  linux-image-3.16.0-4-amd64/postinst/depmod-error-initrd-3.16.0-4-amd64:
false

Bug#869815: libvdpau_i965.so: cannot open shared object file: No such file or directory

[kpp]

Package: vdpauinfo
Version: 1.0-1+b2
Severity: important

Dear Maintainer,

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


   * What led up to the situation?
start vdpauinfo on lenovo nettop with integrated video

   * What was the outcome of this action?
$ vdpauinfo display: :0   screen: 0
Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object 
file: No such file or directory

Error creating VDPAU device: 1
$

   * What outcome did you expect instead?
Output without errors

some additional info:
# lspci -vvv
-- CUT --
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core 
processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])

Subsystem: Lenovo 3rd Gen Core processor Graphics Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0
Interrupt: pin A routed to IRQ 30
Region 0: Memory at c000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at b000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 4000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0200c  Data: 4182
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
Kernel modules: i915
-- CUT --

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vdpauinfo depends on:
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libstdc++6  6.3.0-18
ii  libvdpau1   1.1.1-6
ii  libx11-62:1.6.4-3

vdpauinfo recommends no packages.

vdpauinfo suggests no packages.

-- no debconf information