Bug#844725: libproj12 should conflict with libproj9

[Gianfranco Costamagna]

control: reopen -1

Hi Sebastiaan,

can we please keep it open for some days, to discuss it? :)
I don't feel confortable in writing to a closed bug ;)



>Sorry to hear you wasted your time. Thank for caring about packages in
>universe though, too few people in Ubuntu do.



not a problem, it wasn't wasted, but a good learning opportunity.
>Transitions ensure that all reverse dependencies are updated for the new
>library thereby making it obsolete and easy to remove with `apt-get
>autoremove`. By having all rdeps depend on the new library package, the
>old one should no longer be installed via (build) dependencies.


you can't force people to uninstall a library on their system, I had this issue
with libpng12, that is probably still installed on some Debian chroots 
(according to
the various binNMU requests in release.d.o, seems that even developers are not 
cleaning
their systems)

>The failure in Ubuntu to do a proj transition does not warrant an RC bug

>in Debian.

this isn't a failure in Ubuntu to transition proj, in fact I did it 
successfully.

>Conflicts are not appropriate because libproj9 and libproj12
>do not contain the same files

they are appropriate for my policy parsing:
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

Conflicts should be used
[...]
in other cases where one must prevent simultaneous installation of two packages 
for reasons that are ongoing (not fixed in a later version of one of the 
packages) or that must prevent both packages from being unpacked at the same 
time, not just configured.

>The fix for this issue is to do a proj transition in Ubuntu as we've
>done in Debian. If Ubuntu does not have the manpower to do transitions
>for packages in universe, they should consider removing those packages
>to acknowledge their lack of maintenance in Ubuntu. Removal of packages
>Ubuntu users rely on should motivate them to become involved in their
>maintenance in a similar fashion as removal from testing in Debian.


please don't blame Ubuntu, I'm discussing a totally different issue here.
Since you can't force people from not having two different incompatible 
libraries, at least
you should enforce python-pyproj in using the correct one, because as you can 
say there,
apt is not preventing usage of libproj9 together with python-pyproj and the 
wrong gdal binding.

this is the issue, the dependencies should have the correct relationships, to 
avoid such issues,
during upgrades or when people selectively picks what to keep and what to 
upgrade.

I hope it is clear now.

G.

Bug#844714: pycparser needs sourceful upload for new python-ply

[Adrian Bunk]

Control: retitle -1 pycparser needs sourceful upload for new python-ply

All that seems needed here is a sourceful upload to automatically get 
the correct dependency.

A binNMU would be sufficient, but binNMUs are not (yet) implemented for 
binary-all packages.

cu
Adrian

-- 

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

Bug#844733: newer (4.10.0) version is available -- addresses incorrect time and avg speed reporting

[Yaroslav Halchenko]

Package: python-tqdm
Version: 4.8.4-1
Severity: normal

Was giving demos of our datalad at a conference and noted that "global"
progress bar summarizing progress of multiple progress bars provided by tqdm
made little sense -- time spent was reset seems after each sub-progress bar
finished, total avg speed was pretty much driven by most recent 
sub-progressbar..

I have tried 4.10.0 from git and it behaved much much better, so I could even
remove custom  settings for mininterval etc -- there were some fixups done
upstream recently.

Thanks in advance!  Let me know if I should help

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

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

Versions of packages python-tqdm depends on:
pn  python:any  

python-tqdm recommends no packages.

python-tqdm suggests no packages.

-- no debconf information

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

[Lluís Vilanova]

I've made a pull request to upstream that makes coz be more informative about
that error:

  https://github.com/plasma-umass/coz/pull/86

Cheers,
  Lluis

Bug#844736: partclone FTBFS on mips and mipsel: libaal need to be recompiled with -fPIC

[Radovan Birdic]

Package: libaal
Version: 1.0.6-2
Severity: important
Tags: sid + patch
Justification: FTBFS
User: debian-m...@lists.debian.org
Usertags: mips-patch


Package partclone_0.2.89-1 FTBFS on mips and mipsel with following error:

> configure:8100: gcc -o conftest -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c -laal  -lpthread  >&5
> /usr/bin/ld: 
> /usr/lib/gcc/mips-linux-gnu/6/../../../mips-linux-gnu/libaal.a(libaal_la-device.o):
>  relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/lib/gcc/mips-linux-gnu/6/../../../mips-linux-gnu/libaal.a: error adding 
> symbols: Bad value
> collect2: error: ld returned 1 exit status

Full build log:
https://buildd.debian.org/status/fetch.php?pkg=partclone=mips=0.2.89-1=1479125695

The problem occurs because -fPIC flag is not used during libaal build.
This flag had been already added in debian rules but in configure.in all 
additional CFLAGS was ignored.

I have created and attached a patch that resolves this issue.
With this patch package builds successfully on mips, mipsel, mips64el and i386 
architectures.

Regards,
Radovan--- libaal-1.0.6_orig/configure.in	2016-11-18 14:40:12.903585244 +
+++ libaal-1.0.6/configure.in	2016-11-18 14:39:29.593384612 +
@@ -126,7 +126,8 @@ else
   ALIGN_FLAGS="-malign-jumps=1 -malign-loops=1 -malign-functions=1"
 fi
 
-CFLAGS=""
+# This disables possibility to specify any additional CFLAGS in configure line
+#CFLAGS=""
 MINIMAL_CFLAGS=""
 GENERIC_CFLAGS=""
 

Bug#843166: kodi: block migration to testing untill all reverse dependencies are ready

[Balint Reczey]

Control: notfound -1 17.0~beta5+dfsg1-1

On Fri, 4 Nov 2016 11:58:21 -0300 Felipe Sateler 
wrote:
> On 4 November 2016 at 11:57, Bálint Réczey  wrote:
> > Hi Felipe,
> >
> > 2016-11-04 15:50 GMT+01:00 Felipe Sateler :
> >> On 4 November 2016 at 11:21, Balint Reczey  wrote:
> >>> Source: kodi
> >>> Version: 17.0~beta5+dfsg1-1
> >>> Severity: grave
> >>>
> >>> To not break testing users' addon configuration I'm blocking kodi's
> >>> migration to testing until all addons are ready to migrate together.
> >>>
> >>> Close this bug when all reverse dependencies are ready.
> >>
> >> It seems to me that then kodi and the plugin should have stricter
> >> dependencies. Maybe kodi should Provides: kodi-plugin-$version and the
> >> plugins should Depend: on that?
> >
> > Yes, this is the plan and Tobias already offered implementing it later.

Tobias implemented providing various API versions in kodi and some
add-ons started using it already.
The rest of the addons will depend on the right API version with their
next upload.

Closing this bug since the kodi addons are ready.

Kodi can't yet migrate to testing due to mips* builds failing probably
because of a toolchain problem (#844227).

Cheers,
Balint

Bug#844735: libusb-1.0: Build fxload package from libusb-1.0 examples

[Stefano Rivera]

Hi Debian (2016.11.18_15:36:47_+0100)
> For flashing the Opsis [3] boards, which the DebConf Video team uses, we
> need to use a libusb version of fxload.

Bah, I don't know where I got that idea from. (Well I do, but it was
confused.)

That said, libusb still has the better maintained fxload :)

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#844739: partclone FTBFS on mips and mipsel: reiser4progs need to be recompiled with -fPIC

[Radovan Birdic]

Package: reiser4progs
Version: 1.1.0-2
Severity: important
Tags: sid + patch
Justification: FTBFS
User: debian-m...@lists.debian.org
Usertags: mips-patch


Package partclone_0.2.89-1 FTBFS on mips and mipsel with following error:

> /usr/bin/ld: 
> /usr/lib/gcc/mipsel-linux-gnu/6/../../../../lib/libreiser4.a(libreiser4_la-bitmap.o):
>  relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/lib/gcc/mipsel-linux-gnu/6/../../../../lib/libreiser4.a: error adding 
> symbols: Bad value
> collect2: error: ld returned 1 exit status
> Makefile:1058: recipe for target 'partclone.reiser4' failed
> make[3]: *** [partclone.reiser4] Error 1

The problem occurs because -fPIC flag is not used during reiser4progs build.

I have created and attached a patch that adds -fPIC flag and resolves this 
issue.
With this patch package builds successfully on mips, mipsel, mips64el and i386 
architectures.

Regards,
Radovan--- reiser4progs-1.1.0_orig/debian/rules	2014-07-19 15:00:54.0 +
+++ reiser4progs-1.1.0/debian/rules	2016-11-18 12:20:29.120912425 +
@@ -25,7 +25,14 @@ ifeq (,$(findstring nostrip,$(DEB_BUILD_
 endif
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=-format
-export DEB_CFLAGS_MAINT_APPEND = -I$(CURDIR)
+
+DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
+ifneq (,$(filter $(DEB_BUILD_ARCH),mips mipsel))
+	export DEB_CFLAGS_MAINT_APPEND = -I$(CURDIR) -fPIC
+else
+	export DEB_CFLAGS_MAINT_APPEND = -I$(CURDIR)
+endif
+
 CFLAGS = `dpkg-buildflags --get CFLAGS`
 CPPFLAGS = `dpkg-buildflags --get CPPFLAGS`
 LDFLAGS = `dpkg-buildflags --get LDFLAGS`

Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: subscribe -1 j.naum...@fu-berlin.de

Hey,

my point was to start packaging the Mailman 3.1 development version
already since this version switches to python3.5 and many bug fixes
are applied there (I currently administrate a 3.0.3 installation,
there are many things not working properly). For the new
django-allauth dependency I have created a new ITP bug (you should be
in CC of the bug).

My GitHub account is JanLuca.

Best regards,
Jan

Am 14.11.2016 um 22:42 schrieb Pierre-Elliott Bécue:
> Le vendredi 11 novembre 2016 à 14:39:18+0100, Jan Luca Naumann a 
> écrit :
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>> 
>> Hey Pierre-Elliott,
>> 
>> my idea is that we package the current development versions and 
>> upload them to Debian experimental since the development time of 
>> 3.1 will last some more time according to the Mailman 
>> developers...
>> 
>> If you have no problem I could submit some changes to your 
>> repository either as pull requests or as direct pushs?
> 
> As said, there is two issues.
> 
> First, HyperKitty deps are missing, second, mailman relies on 
> python3.4.
> 
> If you have some patches to offer let's go for it, what is your 
> github login please?
> 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYLyC+AAoJEH4R1/EZ+XG7FoQP/3XHmbQlxo0kMO4YXLoTQuKW
HvJVW8lwiIyBTRdY7RyY/obtGXjLvNDXpnUPyGULWUX3XUC0O15F2PHXFjbxc3b4
AI/uJEDfpbr88z46fYFRCPov5/A4tUEp+Rn0qBtl6jFI3tU8kcU9dS01tTml0aw8
sexwc8W7Qu/YQ93OjrSQG4p+O95d6V9ksTgf5XihdaieQQCg9Yf+rb97oJ4c3R2A
Y9bixue+NA3fDYdkBEX52okUsVCij2iujdBuDAwOCfrhN9rhVsdtlQB480UST8j+
/a6zzOZRKcHQwbF4+QtKnAdA3KLKgmn8L/oTy+FPFit1Ew+6kb6QInx8if49VWVl
Z25f/EDUNV40xiQAvrnbwIkGqqo3mtIqZPwgak5g4IkMEtRY1kbglZT10evRkTWD
724K+604cP0/GlybDWiZIvFolH/WMyUjopLRFRccFgiJEyo1egeV8G2HBYfYKGAn
dSRpnnDCURUDNlQCEGXBd9pcLXwDK1X04o55aQxN09m8RnUuwAxDpg/bqGktwUCs
ktBoQuSDjPf7XcMjSxXIhBW9hradvQHDD/gXbD9x10kklj68kE2YtkHRuQgTbgyf
Flp8wfYwBT5ff5x8o/uyGSeDa2eedxT1XNihrmJWg4QoSebZbBkII3HNDii6Ysho
xQpjpvTGXub26IQ/WB+/
=sa/A
-END PGP SIGNATURE-

Bug#844744: ITP: javacc4 -- Java Parser Generator

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: javacc4
  Version : 4.0
  Upstream Author : Sun Microsystems, Inc
* URL : http://javacc.org
* License : BSE-3-Clause
  Programming Lang: Java
  Description : Java Parser Generator

Java Compiler Compiler™ (JavaCC™) is a popular parser generator for use
with Java applications. A parser generator is a tool that reads a grammar
specification and converts it to a Java program that can recognize matches
to the grammar. In addition to the parser generator itself, JavaCC provides
other standard capabilities related to parser generation such as tree
building (via a tool called JJTree included with JavaCC), actions,
debugging, etc.

This package was forked from the javacc package. It is required for
building derby which is incompatible with the more recent versions.
This package will be maintained by the Java Team.

Bug#844743: ITP: python-django-allauth -- Django app that allows both local and social authentication

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann 

* Package name: python-django-allauth
  Version : 0.28.0
  Upstream Author : Raymond Penners and contributors
* URL : http://www.intenct.nl/projects/django-allauth/
* License : MIT
  Programming Lang: Python
  Description : Django app that allows both local and social authentication

Integrated set of Django applications addressing authentication,
registration, account management as well as
3rd party (social) account authentication.

Bug#825730: ca-certificates: using --noawait triggers breaks downloader packages

[Michael Shuler]

Stable update requested! Thanks again for the report, Andreas.

https://bugs.debian.org/844746
"jessie-pu: package ca-certificates/20141019+deb8u2"

-- 
Kind regards,
Michael Shuler



signature.asc
Description: OpenPGP digital signature

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Guillem Jover]

Hi!

On Fri, 2016-11-18 at 10:15:45 -0500, Yaroslav Halchenko wrote:
> On Fri, 18 Nov 2016, Guillem Jover wrote:
> > > (The preliminary and perhaps non-working patch can be found for now at
> > > https://www.hadrons.org/~guillem/tmp/0001-Add-preliminary-.buildinfo-support.patch)
> 
> > Ok, Michael Prokop deployed it on jenkins.grml.org and retriggered at
> > least the dpkg jobs and they seem to work now. I've fixed an inversion
> > logic error in the previous patch and I'm including the good one here.
> > Review and more testing would be very appreciated.
> 
> I have built patched version and ran incomingprocessed for new backported
> packages for neurodebian without  tuning up configuration (should have I?).
> unfortunately lead to previous behavior, 

> 'nuitka_0.5.24+ds-1~nd90+1_amd64.changes' contains 
> 'nuitka_0.5.24+ds-1~nd90+1_20161116T225525z-5f997ef0.buildinfo' not matching 
> an valid architecture in any distribution known!

Right this is a buildinfo file generated before dpkg 1.18.15 which
used a buildinfo-id instead of an architecture. I didn't find it worth
it to support them when they have been generated only for around 10
days or so.

> Error: 'nuitka_0.5.24+ds-1~nd+1_amd64.changes' contains unused file 
> 'nuitka_0.5.24+ds-1~nd+1_amd64.buildinfo'!

This one is for a new buildinfo file, and I don't know how reprepo works at
all, but perhaps this just requires the new option ("includebuildinfos") to
include the buildinfo files in the pool? Or maybe there's another option to
ignore those unused files, would need to dig. But actual users are probably
in a better position to know this. ;)

Thanks,
Guillem

Bug#844731: dokuwiki: CVE-2016-7964

[Salvatore Bonaccorso]

Source: dokuwiki
Version: 0.0.20160626.a-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/splitbrain/dokuwiki/issues/1708

Hi,

the following vulnerability was published for dokuwiki. No fix
upstream AFAICS yet.

CVE-2016-7964[0]:
| The sendRequest method in HTTPClient Class in file /inc/HTTPClient.php
| in DokuWiki 2016-06-26a and older, when media file fetching is enabled,
| has no way to restrict access to private networks. This allows users to
| scan ports of internal networks via SSRF, such as 10.0.0.1/8,
| 172.16.0.0/12, and 192.168.0.0/16.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-7964
[1] https://github.com/splitbrain/dokuwiki/issues/1708

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#844734: RFS: dvbcut/0.7.1-1

[Bernhard Übelacker]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: dvbcut
  Version : 0.7.1-1
  Upstream Author : Bernhard Übelacker
* URL : https://github.com/bernhardu/dvbcut-deb
* License : GPL-2+
  Section : graphics

It builds those binary packages:

  dvbcut - Qt application for cutting parts out of DVB streams

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dvbcut/dvbcut_0.7.1-1.dsc


More information about hello can be obtained from 
https://github.com/bernhardu/dvbcut-deb .


Changes since the last upload:

dvbcut (0.7.1-1) unstable; urgency=low

  [ Bernhard Übelacker ]
  * Avoid redraw of intermediate steps while
dragging sliders with the mouse.
  * Remove outdated Recommends mplayer2 and unused mpv.
(Closes: #841183) Thanks to James Cowgill.
  * Add facility to search for duplicate frames (Thanks to Olaf Dietsche).
  * Remove some gcc 6 warnings.

 -- Bernhard Übelacker   Fri, 18 Nov 2016 14:31:12 +0100


Regards,
Bernhard Übelacker

Bug#840211: perlunicook man page does not display utf8 char beyond ascii

[Niko Tyni]

severity 401089 normal
reassign 840211 perl-doc 5.24.1~rc3-3
forcemerge 840211 401089
forwarded 401089 https://rt.cpan.org/Public/Bug/Display.html?id=68741
thanks

On Sun, Oct 09, 2016 at 05:30:23PM +0200, Dominique Dumont wrote:
> Package: perl
> Version: 5.24.1~rc3-3
> Severity: normal
> 
> Dear Maintainer,
> 
> In perlunicook man page, non-ASCII utf-8 char are replaced by 'X'
> (which is a shame on a man page dealing with unicode and utf8 issue):

Indeed. This is also #401089, merging. A workaround is using 'perldoc'
instead of the man pages.

> I guess that this file was generated by pod2man without --utf8 option.

Yes.
 
> Could you please fix the generation of these man pages ?

I think upstream (Russ and iirc others on p5p too) have been stepping
very carefully here due to compatibility issues with older nroff
implementations and the like.

There's [rt.cpan.org #68741] upstream, quoting Russ in 2011: "I'm
currently leaning towards outputing UTF-8 by default, but I'm kicking
around the idea of trying to use the user's locale."

Russ, any thoughts about the current status?
-- 
Niko Tyni   nt...@debian.org

Bug#844740: i965-va-driver: GDM3 black screen, but Plymouth could display after the upgrade about three days ago (16/November).

[Yin-Jen Lin]

Package: i965-va-driver
Version: 1.7.3-1
Severity: normal

Dear Maintainer,

*** 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: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#591717:

[George Pedro]

Obdrželi jste e-mail pošlu pro vás? Dej mi vědět.

S pozdravem,

George.

Bug#844739: partclone FTBFS on mips and mipsel: reiser4progs need to be recompiled with -fPIC

[Felix Zielcke]

Am Freitag, den 18.11.2016, 16:54 +0100 schrieb Felix Zielcke:

> First it applies cleanly and then it complains.
> I don't get why. Quilt push works cleanly and quilt refresh does
> nothing.
> Do you have an idea why this patch makes problems? The other 2 work
> fine.

Ok silly me. I don't need a patch file for this anyway.

> Regards
> Felix

Bug#844729: mirror listing update for ftp.man.poznan.pl

[Fryderyk Raczyk]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: ftp.man.poznan.pl
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-ftp: /pub/linux/debian/
Archive-http: /linux/debian/
IPv6: yes
Archive-upstream: ftp.pl.debian.org
Updates: twice
Maintainer: Fryderyk Raczyk 
Country: PL Poland
Location: Poznan
Sponsor: PSNC http://www.psnc.pl/

Bug#844735: libusb-1.0: Build fxload package from libusb-1.0 examples

[Stefano Rivera]

Source: libusb-1.0
Affects: fxload
Severity: normal
Tags: patch

fxload upstream seems to have stalled [0].

[0]: http://linux-hotplug.cvs.sourceforge.net/viewvc/linux-hotplug/fxload/

I think the best maintained version of fxload these days is in the
libusb examples [1,2].

[1]: https://github.com/libusb/libusb/blob/master/examples/fxload.c
[2]: https://github.com/libusb/libusb/commits/master/examples/fxload.c

For flashing the Opsis [3] boards, which the DebConf Video team uses, we
need to use a libusb version of fxload.

Currently we're using a patchset [4] that I don't see landing in a dead
upstream, any time soon :(

[3]: https://opsis.hdmi2usb.tv/getting-started/jtag.html
[4]: 
https://git.launchpad.net/~timvideos/+git/fxload/tree/debian/patches/multios

So, the best path forward is probably libusb's fxload, in examples. Can
we take over the fxload package with it?

SR

Bug#843402: Re: Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Jan Wagner]

Hi there,

Am 18.11.16 um 12:57 schrieb Guillem Jover:
> I've just prepared a patch supposedly fixing this, but I've never used
> reprepro and don't even know how it works, so it's just built-tested.
> We are now performing some tests, and will update the report once this
> is confirmed to work.
> 
> (The preliminary and perhaps non-working patch can be found for now at
> https://www.hadrons.org/~guillem/tmp/0001-Add-preliminary-.buildinfo-support.patch)

as I was also hit by this bug I did (re)build 4.17.1-1~bpo8+1 and added
the patch. The packages can now processed again by the include command
but buildinfo are ignored.

The packages can be found at:

http://ftp.cyconet.org/pub/debian/archive/bpo/reprepro/4.17.1-1~bpo8+2/

You also can install them staight using[1] my own jessie-backports
repository.

Cheers, Jan.
[1] http://ftp.cyconet.org/instructions
-- 
Jan Wagner
Core Platform Engineer, Debian Developer

TMT GmbH & Co. KG
Nuernberger Str. 42, 95448 Bayreuth, Germany (DE)
Phone: +49 921 507200-0Fax: +49 921 507200-299
E-Mail: jan.wag...@tmt.de  Internet: http://www.tmt.de
GnuPG-ID: 0xDF901724

TMT. Business Solutions.

---
Sitz der Gesellschaft: Bayreuth   Handelsregister Bayreuth HRA 2790
Prokura: Sven Schorer, Frank Doyen
Persoenlich haftende Gesellschafterin: TMT Beteiligungs GmbH
Sitz der Gesellschaft: Bayreuth   Handelsregister Bayreuth HRB 1305
Geschaeftsfuehrung: Peter Maisel



signature.asc
Description: OpenPGP digital signature

Bug#815170: love: New upstream version available

[Bart van Strien]

Dear Maintainers,

Since the last message in this bug, LÖVE version 0.10.2 was released,
yet the version in the repositories is still stuck at 0.9.1.

I noticed tracker.debian.org lists this package as depending on a
package that needs a new maintainer --- DevIL --- so this might be what is
holding you back. Fortunately, in version 0.10.0, the dependency on
DevIL was dropped.

I would also like to note that ever since the release of 0.9.1, every
release is accompanied by a post on an RSS feed, located at [1]. Maybe
this could prove useful for automatic release tracking in the future?

Sincerely,

Bart van Strien

[1]: https://love2d.org/releases.xml

Bug#844742: python-eyed3: new upstream release breaks jack (console cd ripper)

[boffi]

Package: python-eyed3
Version: 0.7.9-2
Severity: normal

Dear Maintainer,

the debian package "jack" (it is a condole cd ripper) depends on
python-eyed3, so much that it executes, as a consistency check,
the statement

from eyeD3 import eyeD3

at a very early stage of its initialization.

Of course the new version (a) has changed the module's name and
(b) has not a eyeD3 symbol in it.

I've reported the problem in a bug report for the jack package
(#844568) but I've receiveed no feedback.

Thank you in advance,
gb

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

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

Versions of packages python-eyed3 depends on:
pn  python:any  

python-eyed3 recommends no packages.

python-eyed3 suggests no packages.

-- no debconf information

Bug#844745: geany-plugin-git-changebar: Git Change Bar plugin stopped working

[Sebastian Wyngaard]

Package: geany-plugin-git-changebar
Version: 1.28+dfsg-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

The git change bar no longer displays in the markers margin.

See upstream issue here: https://github.com/geany/geany-plugins/issues/493

Fix already exists upstream.

Thanks,
Sebastian



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

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

Versions of packages geany-plugin-git-changebar depends on:
ii  geany [geany-abi-71]  1.28-2
ii  geany-plugins-common  1.28+dfsg-1
ii  libc6 2.24-5
ii  libgit2-240.24.2-2
ii  libglib2.0-0  2.50.2-1
ii  libgtk2.0-0   2.24.31-1

geany-plugin-git-changebar recommends no packages.

geany-plugin-git-changebar suggests no packages.

-- no debconf information

Bug#744972: lintian: source-is-missing is too strict/naive for finding files

[Herbert Fortes]

Hi,

I am doing a QA for python-pygresql (new version)
and I believe there are two false positives:

P: pygresql source: insane-line-length-in-source-file 
docs/_build/html/_static/jquery.js line length is 32086 characters (>512)
P: pygresql source: source-contains-prebuilt-javascript-object 
docs/_build/html/_static/jquery.js line length is 32086 characters (>512)
E: pygresql source: source-is-missing docs/_build/html/_static/jquery.js line 
length is 32086 characters (>512)

P: pygresql source: insane-line-length-in-source-file 
docs/_build/html/_static/underscore.js line length is 519 characters (>512)
P: pygresql source: source-contains-prebuilt-javascript-object 
docs/_build/html/_static/underscore.js line length is 519 characters (>512)
E: pygresql source: source-is-missing docs/_build/html/_static/underscore.js 
line length is 519 characters (>512)

I think the files are the source. MIT and Apache 2.0 linceses.

I put the package on Mentors(debian/copyright not edited yet):

 https://mentors.debian.net/package/pygresql
 https://mentors.debian.net/debian/pool/main/p/pygresql/pygresql_5.0.2-1.dsc



Regards,
Herbert

Bug#841183: dvbcut: mplayer2 has gone away

[Bernhard Übelacker]

Hello James,
sorry for the late reply.

I prepared a new version removing mplayer2 and opened a RFS in [1].

Thanks,
Bernhard

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

Bug#833700: about to package voctomix-outcasts

[Holger Levsen]

control: retitle -1 ITP: voctomix-outcasts
control: reassign -1 wnpp
thanks

Hi,

subject says it all, I'm going to package this as a seperate package
now (as discussed at the videoteam sprint in Paris).


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844735: libusb-1.0: Build fxload package from libusb-1.0 examples

[Stefano Rivera]

Almost forgot. I have a patch.

It doesn't include a manpage, as there isn't one upstream :(

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
diff -Nru libusb-1.0-1.0.21/debian/control libusb-1.0-1.0.21/debian/control
--- libusb-1.0-1.0.21/debian/control2016-10-26 17:53:41.0 +0200
+++ libusb-1.0-1.0.21/debian/control2016-11-18 13:33:48.0 +0100
@@ -56,3 +56,12 @@
  of Linux kernel internals.
  .
  This is a minimal package for use in debian-installer.
+
+Package: fxload
+Section: admin
+Architecture: any
+Depends: ${misc:Depends}
+Description: Firmware download to EZ-USB devices
+ This program is conveniently able to download firmware into FX and FX2 ez-usb
+ devices. It is intended to be invoked by hotplug scripts when the unprogrammed
+ device appears on the bus.
diff -Nru libusb-1.0-1.0.21/debian/fxload.install 
libusb-1.0-1.0.21/debian/fxload.install
--- libusb-1.0-1.0.21/debian/fxload.install 1970-01-01 01:00:00.0 
+0100
+++ libusb-1.0-1.0.21/debian/fxload.install 2016-11-18 13:33:49.0 
+0100
@@ -0,0 +1 @@
+/usr/sbin/fxload
diff -Nru libusb-1.0-1.0.21/debian/patches/install-fxload 
libusb-1.0-1.0.21/debian/patches/install-fxload
--- libusb-1.0-1.0.21/debian/patches/install-fxload 1970-01-01 
01:00:00.0 +0100
+++ libusb-1.0-1.0.21/debian/patches/install-fxload 2016-11-18 
13:33:49.0 +0100
@@ -0,0 +1,12 @@
+--- a/examples/Makefile.am
 b/examples/Makefile.am
+@@ -1,7 +1,8 @@
+ AM_CPPFLAGS = -I$(top_srcdir)/libusb
+ LDADD = ../libusb/libusb-1.0.la
+ 
+-noinst_PROGRAMS = listdevs xusb fxload hotplugtest testlibusb
++noinst_PROGRAMS = listdevs xusb hotplugtest testlibusb
++sbin_PROGRAMS = fxload
+ 
+ if HAVE_SIGACTION
+ noinst_PROGRAMS += dpfp
diff -Nru libusb-1.0-1.0.21/debian/patches/series 
libusb-1.0-1.0.21/debian/patches/series
--- libusb-1.0-1.0.21/debian/patches/series 2016-08-25 10:30:40.0 
+0200
+++ libusb-1.0-1.0.21/debian/patches/series 2016-11-18 13:33:49.0 
+0100
@@ -1 +1,2 @@
 gnu-hurd-stub.diff
+install-fxload
diff -Nru libusb-1.0-1.0.21/debian/rules libusb-1.0-1.0.21/debian/rules
--- libusb-1.0-1.0.21/debian/rules  2016-10-26 17:43:38.0 +0200
+++ libusb-1.0-1.0.21/debian/rules  2016-11-18 13:33:49.0 +0100
@@ -20,10 +20,12 @@
 
 override_dh_auto_build-arch:
dh_auto_build --builddirectory build-deb
+   dh_auto_build --builddirectory build-deb/examples
dh_auto_build --builddirectory build-udeb
 
 override_dh_auto_install-arch:
dh_auto_install --builddirectory build-deb 
--destdir=$(CURDIR)/debian/tmp-deb
+   dh_auto_install --builddirectory build-deb/examples 
--destdir=$(CURDIR)/debian/tmp-deb
# Move the library to /lib
mkdir -p $(CURDIR)/debian/tmp-deb/lib/$(DEB_HOST_MULTIARCH)/
mv 
$(CURDIR)/debian/tmp-deb/usr/lib/$(DEB_HOST_MULTIARCH)/libusb-1.0.so.* \

Bug#844741: [ristretto] Segafault when run as root

[Philipp Klaus Krause]

Package: ristretto
Version: 0.8.1-1
Severity: normal

--- Please enter the report below this line. ---

I can run ristretto as a normal user. But when I try to start it from a
terminal where I am root, I get a segfault:

root@notebook4:/tmp# gdb ristretto
GNU gdb (Debian 7.11.1-2+b1) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ristretto...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/ristretto
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_connect_signal: assertion
'DBUS_IS_G_PROXY (proxy)' failed

** (ristretto:8002): CRITICAL **: dbus_g_proxy_connect_signal: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

(ristretto:8002): xfconf-CRITICAL **: xfconf_init() must be called
before attempting to use libxfconf!

** (ristretto:8002): CRITICAL **: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed

(ristretto:8002): GLib-CRITICAL **: g_propagate_error: assertion 'src !=
NULL' failed

Bug#844573: link-grammar, the reason for the failure is src:libedit

[Gianfranco Costamagna]

control: reassign 844573 src:libedit
control: affects 844573 src:link-grammar

Hi Sylvestre, seems that the new libedit to work injects an lncurses link flag
https://sources.debian.net/src/libedit/3.1-20160903-1/libedit.pc.in/

so, I would prefer it being added to libedit-dev runtime dependencies, to
avoid failures to unrelated software such as link-grammar

this is the libedit-dev current pkg-config
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include

Name: libedit
Description: command line editor library provides generic line editing, 
history, and tokenization functions.
Version: 3.1
Requires:
Libs: -L${libdir} -ledit -lncurses  -lbsd
Cflags: -I${includedir} -I${includedir}/editline


cheers,

G.

Bug#827339: Please revert patch for cmd, and fix default pattern

[Patrick Matthäi]

Am 17.11.2016 um 18:52 schrieb Stephan Sürken:
> Hi Patrick,
>
> On Do, 2016-11-17 at 15:40 +0100, Patrick Matthäi wrote:
> (...)
>> Then the question is, why it does not work on Jessies grep?
> did you overlook my comment? Or are my findings wrong?
>
> Thx!
>
> S
Ah now I get it. You have adjusted the C code of apt-dater, to detect
errors without using HTML.
But we have got still the problem, that the default grep syntax (also
your fixed grep syntax) from "typescript" produces a more or less silent
"syntax error", like from the beginning of this report.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Yaroslav Halchenko]

On Fri, 18 Nov 2016, Guillem Jover wrote:

> > (The preliminary and perhaps non-working patch can be found for now at
> > https://www.hadrons.org/~guillem/tmp/0001-Add-preliminary-.buildinfo-support.patch)

> Ok, Michael Prokop deployed it on jenkins.grml.org and retriggered at
> least the dpkg jobs and they seem to work now. I've fixed an inversion
> logic error in the previous patch and I'm including the good one here.
> Review and more testing would be very appreciated.

> Thanks,
> Guillem

> From c059c721863ad0b33ab44417640c37f6f8cfabf1 Mon Sep 17 00:00:00 2001
> ...

FWIW

I have built patched version and ran incomingprocessed for new backported
packages for neurodebian without  tuning up configuration (should have I?).
unfortunately lead to previous behavior, 

'nuitka_0.5.24+ds-1~nd90+1_amd64.changes' contains 
'nuitka_0.5.24+ds-1~nd90+1_20161116T225525z-5f997ef0.buildinfo' not matching an 
valid architecture in any distribution known!
Error: 'nuitka_0.5.24+ds-1~nd+1_amd64.changes' contains unused file 
'nuitka_0.5.24+ds-1~nd+1_amd64.buildinfo'!
(Do Permit: unused_files to conf/incoming to ignore and
 additionally Cleanup: unused_files to delete them)
Not deleting possibly left over files due to previous errors.
(To keep the files in the still existing index files from vanishing)
Use dumpunreferenced/deleteunreferenced to show/delete files without references.
21 files lost their last reference.
(dumpunreferenced lists such files, use deleteunreferenced to delete them.)
Warning: database 'jessie|main|i386' was modified but no index file was 
exported.
Changes will only be visible after the next 'export'!
Warning: database 'jessie|main|amd64' was modified but no index file was 
exported.
Changes will only be visible after the next 'export'!
Warning: database 'jessie|main|sparc' was modified but no index file was 
exported.
Changes will only be visible after the next 'export'!
Warning: database 'jessie|main|source' was modified but no index file was 
exported.
Changes will only be visible after the next 'export'!
...


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#844658: stretch GIT broken

[martin carmichael]

there is no bug as I had a problem in source.list

I am running stretch and  was mixed with stable from multimedia.org


deb http://www.deb-multimedia.org stable main non-free

replaced stable with stretch and it now it works.
sorry to disturb.

now works well.
no bug.





From: Nikos Mavrogiannopoulos 
Sent: November 18, 2016 8:09 AM
To: Daniel Kahn Gillmor; 844...@bugs.debian.org; martin carmichael
Subject: Re: Bug#844658: stretch GIT broken

I think few months ago a similar issue was reported.  The culprit was librtmp 
or some other lib linking to a version of nettle with unversioned symbols. That 
resulted to a symbol clash which caused that issue. The solution was to update 
that lib.

On 18 November 2016 02:50:14 CET, Daniel Kahn Gillmor  
wrote:
>On Fri 2016-11-18 06:03:59 +0900, martin carmichael wrote:
>> Package: gnutls-bin (3.5.5-6)
>>
>>
>> message: fatal: unable to access 'https://github.com :
>gnutls_handshake() failed: Public key signature verification has
>failed.
>>
>>
>>  git --version
>> git version 2.10.2
>>
>> uname -a
>> Linux debian 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64
>GNU/Linux
>>
>> git push
>> fatal: unable to access 'https://github.com...  : gnutls_handshake()
>failed: Public key signature verification has failed.
>
>I'm not seeing this at all:
>
>0 dkg@alice:/tmp/cdtemp.B2ws82$ git clone https://github.com/dkg/s6
>Cloning into 's6'...
>remote: Counting objects: 1899, done.
>remote: Total 1899 (delta 0), reused 0 (delta 0), pack-reused 1899
>  Receiving objects: 100% (1899/1899), 503.91 KiB | 283.00 KiB/s, done.
>Resolving deltas: 100% (1169/1169), done.
>0 dkg@alice:/tmp/cdtemp.B2ws82$
>
>Regards,
>
>--dkg

--
Sent fron my mobile. Please excuse my brevity.

Bug#844728: ipwatchd: find a way to let users edit ipwatchd-script and debsums not complain

[Sandro Tosi]

Package: ipwatchd
Severity: normal

Hello,
ipwatchd ships with a script (ipwatchd-script) which is supposed to be edited to
custome the behavior:

  # This user-defined script is called by IPwatchD daemon when IP conflict 
occurs.
  # Feel free to modify it to suit your needs.

but doing do, will make debsums ipwatchd complain that /usr/sbin/ipwatchd-script
has changed from the file shipped with the package (and rightfully so).

Please find a way to allow ipwatchd users to still customize the ip address
duplicate and debsums not to complain about it.

thanks,
Sandro

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

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

Bug#844727: bash: CVE-2016-9401: popd controlled free

[Salvatore Bonaccorso]

Source: bash
Version: 4.3-11
Severity: normal
Tags: security upstream

Hi Matthias,

the following vulnerability was published for bash. It apparently has
been as well already reported to upstream, but have not found a public
report on the bug-bash mailinglist. AFAIK Chet has not addedd a patch
for this yet.

CVE-2016-9401[0]:
popd controlled free

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9401
[1] http://www.openwall.com/lists/oss-security/2016/11/17/5

Regards,
Salvatore

Bug#844503: [Pkg-salt-team] Bug#844503: Acknowledgement (salt-call fails with libcrypto.so.1.1: undefined symbol: OPENSSL_no_config)

[Benjamin Drung]

tags 844503 upstream
forwarded 844503 https://github.com/saltstack/salt/pull/37772
thanks

Am Donnerstag, den 17.11.2016, 21:50 +0100 schrieb Sebastian Andrzej
Siewior:
> control: tags -1 patch
> 
> On 2016-11-16 12:14:43 [+0100], Filip Pytloun wrote:
> > To reproduce the issue simply install salt-master and run salt-
> > call:
> > 
> > apt-get install salt-master
> > salt-call
> > 
> > Following exception will occur:
> > 
> > Traceback (most recent call last):
> >   File "/usr/bin/salt-call", line 11, in 
> > salt_call()
> 
> …
> >   File "/usr/lib/python2.7/dist-packages/salt/utils/rsax931.py",
> > line 63, in _init_libcrypto
> > libcrypto.OPENSSL_no_config()
> >   File "/usr/lib/python2.7/ctypes/__init__.py", line 375, in
> > __getattr__
> > func = self.__getitem__(name)
> >   File "/usr/lib/python2.7/ctypes/__init__.py", line 380, in
> > __getitem__
> > func = self._FuncPtr((name_or_ordinal, self))
> > AttributeError: /lib/x86_64-linux-gnu/libcrypto.so.1.1: undefined
> > symbol: OPENSSL_no_config
> 
> the problem is that salt/rsax931.py loads the library manually and
> expects certain symbols which are no longer available in OpenSSL
> 1.1.0.
> And it loads the first libcrypto it finds plus has no dependency on
> openssl.

Instead of forcing salt to use OpenSSL 1.0, let's try to make it work
with OpenSSL 1.1. Adjusting the initialization to work with OpenSSL 1.1
was quite easy. I forwarded the patch upstream to
https://github.com/saltstack/salt/pull/37772 to get it reviewed and
accepted.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL: https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss

Bug#844739: partclone FTBFS on mips and mipsel: reiser4progs need to be recompiled with -fPIC

[Felix Zielcke]

Am Freitag, den 18.11.2016, 15:17 + schrieb Radovan Birdic:
> I have created and attached a patch that adds -fPIC flag and resolves
> this issue.
> With this patch package builds successfully on mips, mipsel, mips64el
> and i386 architectures.
> 
> Regards,
> Radovan

Hi Radovan,

thanks for the patches. But unfortunately debuild fails with it:

[...]
dpkg-source: info: applying fix_ldconfig.patch
dpkg-source: info: applying 05_libreiser4~profile.c.patch
dpkg-source: info: applying add-fPIC-for-mips.patch
 fakeroot debian/rules clean
[...]
dpkg-source: info: building reiser4progs using existing
./reiser4progs_1.1.0.orig.tar.gz
patching file debian/rules
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored
dpkg-source: info: the patch has fuzz which is not allowed, or is
malformed
dpkg-source: info: if patch 'add-fPIC-for-mips.patch' is correctly
applied by quilt, use 'quilt refresh' to update it
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B
.pc/add-fPIC-for-mips.patch/ --reject-file=- < reiser4progs-
1.1.0.orig.DC8bmd/debian/patches/add-fPIC-for-mips.patch gave error
exit status 1
dpkg-buildpackage: error: dpkg-source -b reiser4progs-1.1.0 gave error
exit status 2

First it applies cleanly and then it complains.
I don't get why. Quilt push works cleanly and quilt refresh does
nothing.
Do you have an idea why this patch makes problems? The other 2 work
fine.

Regards
Felix

Bug#815170: love: New upstream version available

[Markus Koschany]

Control: tags -1 help

On 18.11.2016 16:37, Bart van Strien wrote:
> Dear Maintainers,
> 
> Since the last message in this bug, LÖVE version 0.10.2 was released,
> yet the version in the repositories is still stuck at 0.9.1.
> 
> I noticed tracker.debian.org lists this package as depending on a
> package that needs a new maintainer --- DevIL --- so this might be what is
> holding you back. Fortunately, in version 0.10.0, the dependency on
> DevIL was dropped.
> 
> I would also like to note that ever since the release of 0.9.1, every
> release is accompanied by a post on an RSS feed, located at [1]. Maybe
> this could prove useful for automatic release tracking in the future?
> 
> Sincerely,
> 
> Bart van Strien

Hello Bart,

thank you for contacting us. To be honest the true reason why nobody is
packaging a new upstream release of love is that we are understaffed.
There are people in this team that will help with reviewing and
uploading the package but someone else must get involved who wants to
maintain love for the foreseeable future.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#844740: i965-va-driver: GDM3 black screen, but Plymouth could display after the upgrade about three days ago (16/November).

[Sebastian Ramacher]

Control: reassign -1 gdm3 3.22.1-1

(The only interesting info is in the subject.)

i965-va-driver only provides support for hardware video decoding and encoding.
So this package is the wrong one for the bug report. So I'm reassigning this to
gdm3 which apparently stays black.

The gdm3 maintainers probably know know best where to start debugging this 
issue.

On 2016-11-18 23:28:07, Yin-Jen Lin wrote:
> Package: i965-va-driver
> Version: 1.7.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** 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: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#844718: kmail: Kmail cannot be synchronized between 2 computers anymore

[Sandro Knauß]

Hey,

> I am using kmail on different computers (in particular: 1 desktop and 1
> laptop) and I need to keep all mail synchronized between these computers.
> That is all :-)

Well it still possible, but yes the data are more cluttered. So if you want to 
sync all data you need to stop akonadi before, so the database is shutdown.
And the default paths have changed, so you will need to update the paths you 
want to synchronize.

akonadictl stop
* ~/.local/share/akonadi/
* ~/.config/akonadi*
  -> all paths, that you defined inside the resoureses 
 ~/.config/akonadi*resource_*rc
* passwords from kwallet5

akonadictl start

for the other machine you need also to stop akonadi first and restart it 
afterwards.

Just for your information, if you only copy the .config files akonadi will 
redownload everything from IMAP.

If you just update the local maildir folder, akonadi should just detect the 
new mails and show this within kmail. akonadi uses inotify, so make sure that 
inotify has not run into a limit of watched directories. The default in debian 
is quite low.

This is for akonadi data, than you also have configuration for the pim apps, 
these are still configfiles, you can simply copy around, but these might also 
moved to .local or .config.

@baloo: baloo is simply the file indexer for KDE and has nothing to do with 
kdepim. (at least for unstable). The pim indexer was split out and renamed to 
akonadisearch. but in both cases the indexer is shut down with akonadi, cause 
it it a resource in akonadi, too.

> o the key problem is the non-sync of the "local" folders since I transfer
> lots of mails from IMAP to "local" folders, and these must stay in sync.
> (hey, syncing IMAP is not a problem ;-)

Try to just sync your local maildir - search for the config file to get the 
correct location of you maildir folder and sync this to the other computer.

> o I have tried 'pimsettingexporter' but this was a major mess - (a) it takes
> a very long time to create the archive, and (2) on unpacking, both the mail
> folders and account settings/names are lost/garbled. This is not a valid
> option :-/

I never tried the 'pimsettingexporter'  :)

Best regards,

sandro

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

Bug#722717: RM: adzapper -- RoQA; not in stable, outdated

[Adrian Bunk]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: adzapper -- RoQA; not in stable, outdated

adzapper is not in stable, and due to the build-dependency on 
libswf-perl (see the RC bugs in src:ming) it is anyway not
likely that it could get released in stretch.

Advertisement zapping is a field that changes very quickly.
The latest adzapper upstream release is from 2011, and the version
in Debian is from 2009 (the package is orphaned since 2013).

cu
Adrian

-- 

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

Bug#829078: Any word?

[Emmanuel Bourg]

Le 18/11/2016 à 20:44, Logan Schmidt a écrit :

> Is there any word on this? We are deploying Elasticsearch servers today
> and are getting the same YAML problem when trying to start the service.
> We are using Ubuntu 16.10 (64 bit). Could we try different distro level
> like 16.04? This is a Debian specific issue not to sure what course of
> action to take here.

Hi Logan,

If you need Elasticsearch on Debian/Ubuntu your best bet for now is to
install the upstream package available on the download page [1]. The
elasticsearch package maintained by Debian isn't ready for prime time
yet and will probably not be part of the Stretch release.

Emmanuel Bourg

[1] https://www.elastic.co/downloads/elasticsearch

Bug#841560: [Debian-med-packaging] Bug#841560: Could anybody please check the issue in python-skbio

[Kevin Murray]

Hi all,

AFAICT I think I should have fixed the issues in skbio. I've filed an ROM bug,
and updated to latest upstream. Could I please get an upload and see if the
test failure goes away?

Cheers,
Kevin

---
Kevin Murray

Bug#844770: xzcmp: SIGPIPE is raised because CMP does exit while the XZ commands are still writing to the pipe

[ViaThinkSoft]

Package: xz-utils
Version: 5.1.1alpha+20120614-2+b3
Severity: important
Tags: newcomer



I noticed that xzcmp returns status code 2 (error) for a few file pairs, 
especially if they differ in size.

After some investigation, I found out that exit status 141 (SIGPIPE) is raised 
by the xz-commands, because cmp seems to have already quit after it found the 
first difference between the two streams. After that, the two xz commands write 
into the broken pipe.

The exit status of the two xz commands is written into $xz_status . At the end 
of the script, if $xz_status is not 0, then xzcmp's exit status will become 2 
(although the actual CMP did work fine in this specific case)


Workaround:

If the following line is added, the signal SIGPIPE (exit status 141) will not 
be raised by the xz commands, and thus, the xzdiff process will return the 
correct exit code:

trap '' PIPE



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

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

Versions of packages xz-utils depends on:
ii  libc6 2.19-18+deb8u6
ii  liblzma5  5.1.1alpha+20120614-2+b3

xz-utils recommends no packages.

xz-utils suggests no packages.

-- no debconf information

Bug#844771: CVE-2016-9427: Integer overflow in GC_MALLOC_ATOMIC

[Markus Koschany]

Package: libgc
Severity: important
Tags: security

Hi,

the following vulnerability was published for libgc.

CVE-2016-9427[0]:
 Integer overflow in GC_MALLOC_ATOMIC

Upstream bug report:
https://github.com/ivmai/bdwgc/issues/135

Patches:
https://github.com/ivmai/bdwgc/commit/4e1a6f9d8f2a49403bbd00b8c8e5324048fb84d4
https://github.com/ivmai/bdwgc/commit/7292c02fac2066d39dd1bcc37d1a7054fd1e32ee
https://github.com/ivmai/bdwgc/commit/552ad0834672fed86ada6430150ef9ebdd3f54d7

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9427
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9427
Please adjust the affected versions in the BTS as needed.




signature.asc
Description: OpenPGP digital signature

Bug#832704: RFS: nixnote2/2.0~beta10+dfsg-1 [ITP] -- Open Source Evernote client

[Gianfranco Costamagna]

Hi


>See license.html.  The project is GPL-2, but some files have GPL-2+ in
>their headers.


rescheduled, thanks :)

and sorry for the useless question
G.

Bug#844774: libvshadow FTBFS: test failure on all architectures

[Adrian Bunk]

Source: libvshadow
Version: 2016-1
Severity: serious

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


FAIL: test_python_functions.sh
==

Testing Python-bindings functions: get_version  (FAIL)
FAIL test_python_functions.sh (exit status: 1)


Testsuite summary for libvshadow 2016

# TOTAL: 4
# PASS:  1
# SKIP:  2
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to joachim.m...@gmail.com

Makefile:1252: recipe for target 'test-suite.log' failed

Bug#832704: RFS: nixnote2/2.0~beta10+dfsg-1 [ITP] -- Open Source Evernote client

[Sean Whitton]

Hello Gianfranco,

On Fri, Nov 18, 2016 at 06:54:01PM +, Gianfranco Costamagna wrote:
> Hi, I put the package in deferred/5, because I'm not sure about the whole 
> license.
> Isn't it something like GPL-2+ instead of GPL-2?
> I agree single files are ok, but the "*" wildcard seems a GPL-2+ to me, even 
> if
> I didn't find a copying file.

See license.html.  The project is GPL-2, but some files have GPL-2+ in
their headers.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844679: [Python-modules-team] Bug#844679: /usr/bin/pip: Should use --disable-pip-version-check by default

[Barry Warsaw]

On Nov 17, 2016, at 11:17 PM, Nelson A. de Oliveira wrote:

>Since we are installing pip from a Debian package, shouldn't we have it
>using "--disable-pip-version-check" by default, to avoid this?

Yes, I think we should.

Bug#608843: Shipment delivery problem #00144524

[FedEx International Ground]

Dear Customer,

This is to confirm that one or more of your parcels has been shipped.
Delivery Label is attached to this email.

Yours sincerely,
Frank Wood,
Sr. Support Agent.



FedEx_00144524.doc
Description: MS-Word document

Bug#844767: RM: liggghts [mips mipsel] -- ROM; FTBFS on mips and mipsel

[Anton Gladky]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

the package liggghts fails to build on mips and mipsel
due to unsifficient RAM. The package will unlikely be
useful on those archs, so please remove it for now.

Thank you

Anton

Bug#844766: rtslib FTBFS in stretch due to missing simpleparse

[Adrian Bunk]

Source: rtslib
Version: 1:3.0~pre4.1~g1b33ceb-3
Severity: serious
Tags: stretch
Control: block -1 by 824738

rtslib build-depends on python-simpleparse, which is not in stretch
due to #824738

Bug#844768: ruby-berkshelf-api-client FTBFS in stretch due to missing berkshelf-api

[Adrian Bunk]

Source: ruby-berkshelf-api-client
Version: 2.0.2-1
Severity: serious
Tags: stretch
Control: block -1 by 841704

ruby-berkshelf-api-client build-depends on berkshelf-api,
which is not in testing due to #841704

Bug#844772: ITP: r-bioc-mergeomics -- Integrative network analysis of omics data

[Dylan]

Package: wnpp
Severity: wishlist
Owner: Dylan Aïssi 

Package name: r-bioc-mergeomics
URL: https://bioconductor.org/packages/Mergeomics/
License: GPL-2+
Description: Integrative network analysis of omics data
 The Mergeomics pipeline serves as a flexible framework for integrating
 multidimensional omics-disease associations, functional genomics,
 canonical pathways and gene-gene interaction networks to generate
 mechanistic hypotheses. It includes two main parts:
 1) Marker set enrichment analysis (MSEA);
 2) Weighted Key Driver Analysis (wKDA).


This package will be maintained by the Debian Med Packaging Team at:
https://anonscm.debian.org/git/debian-med/r-bioc-mergeomics.git/

Bug#844773: RFS: ustr/1.0.4-6

[Václav Ovsík]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: ustr
  Version : 1.0.4-6
  Upstream Author : James Antill 
* URL : http://www.and.org/ustr/
* License : LGPL, BSD, MIT
  Section : libs

It builds those binary packages:

libustr-1.0-1 - Micro string library: shared library
libustr-1.0-1-dbg - Micro string library: debugging symbols
libustr-dev - Micro string library: development stuff
libustr-doc - Micro string library: documentation

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/u/ustr/ustr_1.0.4-6.dsc

Changes since the last upload:

   * Patch fixes/autoconf:
 - Fixed race condition on creation shared library symbolic links when make
   runs parallel. Thanks to Yann E. MORIN .
 - Fixed FTBFS (LDFLAGS with -pie): move LDFLAGS before -shared. Thanks to
   Helmut Grohne .
   Closes: #843459
   * Patch fixes/man-spelling: added corrections.
   * Added fixes/attr-nonnull: to disable nonnull attribute.
   * Added fixes/suppress-warn: to suppress warning about indentation.
   * Added hardening=+all in the debian/rules.
   * Changed Vcs-Git to URL with https.
   * Changed Standards-Version to 3.9.8.
   * Added dependency on quilt and include /usr/share/quilt/quilt.make
 in the debian/rules.
   * For libustr-doc added Multi-Arch: foreign.

Regards
-- 
Václav Ovsík

Bug#809388: evince: evince aborts after a few seconds without an error message

[Jason Crain]

Control: tags -1 - moreinfo unreproducible

On Wed, Nov 16, 2016 at 05:20:52PM +0100, Janusz S. Bień wrote:
> Another crash,  still a not typical one:

I might have found what's causing it.  Try setting environment variable
G_SLICE=always-malloc before evince runs and see if that stops the
crashes.

Bug#844769: RFS: node-resumer/0.0.0-1 [RFP]

[Ross Gammon]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "node-resumer"

 * Package name: node-resumer
   Version : 0.0.0-1
   Upstream Author : James Halliday  (http://substack.net)
 * URL :https://github.com/substack/resumer
 * License : Expat
   Section : web

It builds this binary package:

node-resumer  - a through stream that starts paused and resumes on the
 next tick

Unfortunately, it is not possible for me to upload to mentors at the moment.

But the packaging can be found here:

https://anonscm.debian.org/cgit/pkg-javascript/node-resumer.git/

Changes since the last upload:
|

  * Initial release (Closes: #814286)

|Regards,
Ross Gammon

Bug#844503: [Pkg-salt-team] Bug#844503: Acknowledgement (salt-call fails with libcrypto.so.1.1: undefined symbol: OPENSSL_no_config)

[Sebastian Andrzej Siewior]

On 2016-11-18 15:22:07 [+0100], Benjamin Drung wrote:
> Instead of forcing salt to use OpenSSL 1.0, let's try to make it work
> with OpenSSL 1.1. Adjusting the initialization to work with OpenSSL 1.1
> was quite easy. I forwarded the patch upstream to
> https://github.com/saltstack/salt/pull/37772 to get it reviewed and
> accepted.

so it is just two calls? I was a little afraid once I all those rsa ops
and so on. But if nothing else breaks - good.
A little note: OPENSSL_INIT_ADD_ALL_CIPHERS & friends could change on
the next so.bump. Probably they won't but they could.
A "Depend: libssl-1.0.2 || libssl-1.1.0" would avoid further breakage if
ABI changes.

Sebastian

Bug#844730: gcc-6-source: gdc source is actually gzip compressed despite .xz suffix

[Simon Richter]

Package: gcc-6-source
Version: 6.2.0-13
Severity: minor

Hi,

The gdc source archive has a .xz suffix, but is actually gzip
compressed.

$ file /usr/src/gcc-6/gdc-20160822.tar.xz 
/usr/src/gcc-6/gdc-20160822.tar.xz: gzip compressed data, last modified: Mon 
Aug 22 12:11:49 2016, from Unix

   Simon

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

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

Versions of packages gcc-6-source depends on:
ii  autoconf2.64  2.64+dfsg-0.1
ii  gawk  1:4.1.3+dfsg-0.1+b1
ii  make  4.1-9
ii  patchutils0.3.4-2
ii  quilt 0.63-5
ii  sharutils 1:4.15.2-1

gcc-6-source recommends no packages.

gcc-6-source suggests no packages.

-- no debconf information

Bug#844732: dokuwiki: CVE-2016-7965

[Salvatore Bonaccorso]

Source: dokuwiki
Version: 0.0.20160626.a-1
Severity: normal
Tags: security upstream
Forwarded: https://github.com/splitbrain/dokuwiki/issues/1709

Hi,

the following vulnerability was published for dokuwiki. TTBOMK, it
looks like upstream does not plan to address this/plan to mark it as
wontfix.

CVE-2016-7965[0]:
| DokuWiki 2016-06-26a and older uses $_SERVER[HTTP_HOST] instead of the
| baseurl setting as part of the password-reset URL. This can lead to
| phishing attacks. (A remote unauthenticated attacker can change the
| URL's hostname via the HTTP Host header.) The vulnerability can be
| triggered only if the Host header is not part of the web server routing
| process (e.g., if several domains are served by the same web server).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-7965
[1] https://github.com/splitbrain/dokuwiki/issues/1709

Regards,
Salvatore

Bug#838694: icu: CVE-2016-7415: Stack based buffer overflow in locid.cpp

[Salvatore Bonaccorso]

Hi,

On Tue, Oct 25, 2016 at 11:42:16AM -0400, Roberto C. Sánchez wrote:
> On Tue, Oct 04, 2016 at 10:59:52PM +0200, László Böszörményi (GCS) wrote:
> > I don't know more about this issue - upstream keep such bugreports
> > secret, if any. I don't have a good connection with them (yet), but
> > will try to know more about this.
> > 
> Hi Laszlo,
> 
> Have you been able to contact upstream regarding this issue?  Can I help
> in any way?

According to https://bugzilla.redhat.com/show_bug.cgi?id=1377361#c5
there is now an upstream bug about the issue, but unfortunately for
some reason it is still marked as private.

http://bugs.icu-project.org/trac/ticket/12745

Regards,
Salvatore

Bug#844412: wineconsole crashes if switched to emacs mode and ctrl-y is pressed

[Jens Reyer]

control: reassign -1 src:wine-development
control: found -1 1.9.22-1
control: severity -1 minor
control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=41733


Hi Loreno,

(first off, please use reportbug to report bugs and don't change
Source/Package or Version. A version "development" does not exist.)

I can reproduce this (both in wine-development and in wine 1.8.5-1), but
only as long as the buffer is empty. I forwarded this to upstream, see
URL above.

Can you confirm that it works as soon as you have something in the
buffer to paste?

Did this work for you before?

Greets
jre

Bug#844738: ITP: node-fuzzaldrin-plus -- Fuzzy filtering and string scoring - compatible with fuzzaldrin

[Pirate Praveen]

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

* Package name: node-fuzzaldrin-plus
  Version : 0.3.1
  Upstream Author : Jean Christophe Roy
* URL : https://github.com/jeancroy/fuzzaldrin-plus
* License : Expat
  Programming Lang: JavaScript
  Description : Fuzzy filtering and string scoring - compatible with
fuzzaldrin



signature.asc
Description: OpenPGP digital signature

Bug#844737: ITP: node-grunt-contrib-coffee -- Compile CoffeeScript files to JavaScript

[Pirate Praveen]

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

* Package name: node-grunt-contrib-coffee
  Version : 1.0.0
  Upstream Author : Grunt Team (http://gruntjs.com/)
* URL : https://github.com/gruntjs/grunt-contrib-coffee
* License : Expat
  Programming Lang: JavaScript
  Description : Compile CoffeeScript files to JavaScript



signature.asc
Description: OpenPGP digital signature

Bug#844339: [PATCH v3 2/4] libvirt-daemon-system.{config,templates,postinst,NEWS}: warn if allocated uid/gid is taken

[Mauricio Faria de Oliveira]

If the uid/gid that is allocated for libvirt-qemu (64055)
is already in use by another user/group, stop/ask user if
it is OK to continue (e.g., no plans with guest migration
over NFS) or abort to go fix the problem.

This warning is only displayed on new installations.  The
default value is 'yes'/continue/do not abort, thus not to
disrupt automated installations.

On existing installations, no warning is displayed - just
a NEWS file is provided.

Signed-off-by: Mauricio Faria de Oliveira 
---
 debian/libvirt-daemon-system.NEWS  | 22 ++
 debian/libvirt-daemon-system.config| 26 ++
 debian/libvirt-daemon-system.postinst  |  3 +++
 debian/libvirt-daemon-system.templates | 18 ++
 4 files changed, 69 insertions(+)
 create mode 100755 debian/libvirt-daemon-system.config
 create mode 100644 debian/libvirt-daemon-system.templates

diff --git a/debian/libvirt-daemon-system.NEWS 
b/debian/libvirt-daemon-system.NEWS
index 977abdb..94367e5 100644
--- a/debian/libvirt-daemon-system.NEWS
+++ b/debian/libvirt-daemon-system.NEWS
@@ -1,3 +1,25 @@
+libvirt (2.4.0-2uidgid3) UNRELEASED; urgency=medium
+
+  libvirt-daemon-system now uses the allocated uid and gid 64055
+  for the libvirt-qemu user and group on new installations, when
+  the uid/gid is available (otherwise a debconf warning is shown).
+
+  On existing installations, which have different uid/gid values
+  assigned, the recommended procedure is to reassign the uid/gid
+  (might require considerations for ownership/permission changes).
+  No debconf warning is shown in this case; only this NEWS entry.
+
+  This change is in order to prevent I/O errors during migration
+  of guests with disk image files shared over NFS, caused by the
+  different uid/gid ownership between the source and destination
+  host systems, which leads to access/permission errors with NFS.
+
+  If guest migration over NFS is not a requirement in the system,
+  there should not be any impact to the guests for not using the
+  allocated uid/gid.
+
+ -- Mauricio Faria de Oliveira   Thu, 18 Nov 2016 
13:56:38 -0200
+
 libvirt (1.2.9~rc1-1) experimental; urgency=medium
 
   libvirtd now uses PolicyKit instead of unix socket domain permissions for r/w
diff --git a/debian/libvirt-daemon-system.config 
b/debian/libvirt-daemon-system.config
new file mode 100755
index 000..caf0ac2
--- /dev/null
+++ b/debian/libvirt-daemon-system.config
@@ -0,0 +1,26 @@
+#!/bin/sh -e
+
+# Source debconf library.
+. /usr/share/debconf/confmodule
+
+# Allocated UID and GID for libvirt-qemu
+LIBVIRT_QEMU_UID=64055
+LIBVIRT_QEMU_GID=64055
+
+# Check if allocated UID/GID are assigned to a different user/group.
+UID_TO_NAME="$(getent passwd $LIBVIRT_QEMU_UID | cut -d: -f1)"
+GID_TO_NAME="$(getent group  $LIBVIRT_QEMU_GID | cut -d: -f1)"
+
+if ( [ -n "$UID_TO_NAME" ] && [ "$UID_TO_NAME" != 'libvirt-qemu' ] ) \
+|| ( [ -n "$GID_TO_NAME" ] && [ "$GID_TO_NAME" != 'libvirt-qemu' ] ) \
+then
+   # Ask if the user would like to continue or abort installation.
+   db_input high libvirt-daemon-system/id_warning || true
+   db_go
+   db_get libvirt-daemon-system/id_warning
+   if [ "$RET" = "false" ]; then
+   exit 1
+   fi
+fi
+
+exit 0
diff --git a/debian/libvirt-daemon-system.postinst 
b/debian/libvirt-daemon-system.postinst
index 99e9fec..f36b806 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -17,6 +17,9 @@ set -e
 # for details, see http://www.debian.org/doc/debian-policy/ or
 # the debian-policy package
 
+# Source debconf library.
+. /usr/share/debconf/confmodule
+
 add_users_groups()
 {
 if ! getent group libvirt >/dev/null; then
diff --git a/debian/libvirt-daemon-system.templates 
b/debian/libvirt-daemon-system.templates
new file mode 100644
index 000..7e1594b
--- /dev/null
+++ b/debian/libvirt-daemon-system.templates
@@ -0,0 +1,18 @@
+Template: libvirt-daemon-system/id_warning
+Type: boolean
+Default: true
+Description: Continue with incorrect libvirt-qemu user/group ID(s)?
+  The user/group ID (uid/gid) allocated for libvirt-qemu (64055)
+  seems to be taken by another user/group, thus it is not possible
+  to create the user/group with this numeric ID.
+ .
+  The migration of guests with disk image files shared over NFS
+  requires a static libvirt-qemu user and group ID (uid and gid)
+  between the source and destination host systems.
+ .
+  If guest migration over NFS is not required, you can continue
+  the installation.
+ .
+  In order to resolve this problem, do not continue the installation,
+  release the 64055 uid/gid (which might involve permission changes),
+  then install this package again.
-- 
2.10.2

Bug#844725: libproj12 should conflict with libproj9

[Sebastiaan Couwenberg]

On 11/18/2016 06:02 PM, Gianfranco Costamagna wrote:
>> Why is the old libproj9 still being pulled in via (build) dependencies
>> then? That shows that the transition is not completed yet.
> 
> ok

You have not explained why the old libproj9 is still being pulled in via
the build dependencies on Ubuntu.

>> If you want to prevent both packages from being unpacked at the same
>> time, please add this as an Ubuntu diff to the package. It will fix your
>> issue in Ubuntu (which we don't experience in Debian where the
>> transition was done properly). The Ubuntu diff will have the nice side
>> effect of blocking automatic syncing of new proj revisions from Debian,
>> causing the proj package in Ubuntu to become outdated which hopefully
>> triggers people to start helping maintain the GIS packages in Ubuntu.
> 
> I know how Ubuntu works, the only reason for you not experiencing this issue
> is that autopkgtestsuite isn't run or at least is not a blocker for a testing
> migration.
> I know the situation auto-heals by itself at the end (like it did already),
> but this will become a blocker one day if Debian starts doing autopkgtests.

How are autopkgtests causing the old packages to be pulled in when the
transition has been completed in Ubuntu?

>> I do blame Ubuntu, I'm greatly unhappy about my packages not being
>> maintained in Ubuntu but still being included in their repository.
> 
> they are maintained and they still work completely, I don't understand your 
> point
> and I find it completely invalid, because also debian sid is broken in the 
> middle
> of a transition, I don't really get the point.

You are contradicting yourself. First you claimed that the transition
was completed, now you're implying that it's still ongoing.

My point is that Ubuntu includes all packages from Debian, and most of
them in universe because it cannot support them all. Because there are
no people actively maintaining those package, like coordinating
transitions and handling bugs, the packages are prone to cause issues.
MOTU tries to deal with the many packages in universe, but is unable to
cope with them all.

> Openssl is broken since almost one month, should I say the same about Debian?

Yes, the openssl situation in unstable is good example of fallout caused
by a badly thought out transition. openssl 1.1.0 shouldn't have been
made the default because it was known many packages did not support it yet.

>> I appreciate you trying to coordinate this issue with the maintainers in
>> Debian, this is very uncommon and a source of my displeasure about Ubuntu.
> 
> it is completely common to transition packages, and to coordinate them
> in the same way Debian does, and since there is no "testing" or "sid",
> it is not so important if a transition takes some days more to finish, 
> specially
> when full autopkgtests needs to run to make it migrate, and it works better
> than Debian, since we can spot build or test failures even with a 
> non-completely
> migrated combination of packages (specially when many transitions are 
> entangled,
> the testsuite needs to run against -proposed packages to pick also the 
> ongoing work)
> 
>> python-pyproj (in Debian) has a dependency on libproj12 which is
>> correct, there are other packages in Ubuntu which are still pulling in
>> the old library because the transition has not been completed yet.
> 
> there are none.

Why is libproj9 still being pulled in via the dependencies?

>> The old gdal packages are likely still pulling in the old libproj,
>> because the gdal transition is still ongoing and so only the gdal in
>> proposed depends on libproj12.
> 
> gdal is finished, will migrate when other transitions ends

The transition tracker disagrees, mysql-workbench is still marked as bad.

>> When the proj transition is done properly in Ubuntu, none of its rdeps
>> will pull in libproj9 and resolve your issue.
> 
> it is properly done, and ended already, waiting for other transitions to end

Why is libproj9 still being pulled in via the dependencies?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#842145: usrmerge: fails on nfsroot systems

[Adrian Bunk]

Control: severity -1 serious

On Wed, Oct 26, 2016 at 02:20:15PM +0100, James Cowgill wrote:
> On 26/10/16 14:11, Marco d'Itri wrote:
> > On Oct 26, James Cowgill  wrote:
> >> Can't rename('/sbin/.nfs003efaa00995~~tmp~usrmerge~~', 
> >> '/sbin/.nfs003efaa00995'): Device or resource busy at 
> >> /usr/lib/convert-usrmerge line 98
> > The .nfs* file is case of NFS silly rename, but I am not sure about why 
> > it happens here: did you check what 
> > /sbin/.nfs003efaa00995~~tmp~usrmerge~~ was?
> > Maybe there are possibile workarounds, but right now I do not have an 
> > environment to test this. Since convert-usrmerge can be run in a chroot 
> > on the NFS server maybe it would be easier to just make it fail if the 
> > root is NFS-mounted.
> 
> Yes that's is probably the easiest option
>...

I am raising the severity, since shipping usrmerge without anything like 
that in stretch would cause problems for many users.

cu
Adrian

-- 

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

Bug#842040: Please add https support

[Philipp Kern]

On 12.11.2016 18:16, Josh Triplett wrote:
> On Thu, 10 Nov 2016 01:14:33 -0800 Jose R R  wrote:
>> On Tue, Oct 25, 2016 at 6:17 AM, Marga Manterola  wrote:
>>> Package: debian-installer
>>> Severity: normal
>>>
>>> The installer currently doesn't support downloading packages from https
>>> mirrors, because busybox's wget doesn't support https.
>>
>> In order to add SSL support to BusyBox wget, itself to be used wih
>> ssl_helper, I used matrixssl-3-4-2-open.tgz
>> < http://www.matrixssl.org/ >
>>
>> to build my custom BusyBox udeb for my Reiser4-enabled Debian-Installer
>> < https://sf.net/projects/debian-reiser4/ >
>>
>> No idea if suggestion fulfills bug need - just my 2 cents ;-)
> 
> Can you provide a link for your patches to busybox wget to add SSL
> support?  That sounds like it'd substantially decrease size compared to
> including GNU wget and supporting libraries.

Unfortunately matrixssl isn't even in Debian at this point.

Kind regards
Philipp Kern




signature.asc
Description: OpenPGP digital signature

Bug#842040: Please add https support

[Philipp Kern]

On 10.11.2016 05:45, Martin Michlmayr wrote:
> * Roger Shimizu  [2016-10-26 00:59]:
>>> So, approximately 780k extra for the initrd image (3.5% increase)
>>
>> I'm not sure whether any libs already is included in the d-i image, if
>> not, adding 780k extra would definitely affect armel/orion5x qnap d-i
>> initrd image.
>>
>> So I append Martin, the porter of armel/orion5x qnap, to CC list.
> 
> Thanks for the CC.  I just added wget-udeb and it adds 345 KB,
> which breaks the orion5x-qnap image.  However, this image is really
> quite a special case and I don't want to block https support because
> of it.  I can always exclude wget-udeb from this particular image.

So how do we move forward here? Exclude wget-udeb from the orion5x-qnap
image and otherwise include it by default?

Kind regards and thanks
Philipp Kern




signature.asc
Description: OpenPGP digital signature

Bug#844747: solid-pop3d: [INTL:pt_BR] please rename pl_BR.po to pt_BR.po

[Adriano Rafael Gomes]

Package: solid-pop3d
 
Tags: l10n
Severity: normal

Hi,

Please rename the file debian/po/pl_BR.po to debian/po/pt_BR.po. The
file was introduced in #827325.

Thank you.


signature.asc
Description: Digital signature

Bug#844339: [PATCH v3 1/4] libvirt-daemon-system.post{inst,rm}: quiet output for debconf

[Mauricio Faria de Oliveira]

Add some --quiet arguments and /dev/null redirects
in order to make the scripts safe for debconf.

Signed-off-by: Mauricio Faria de Oliveira 
---
 debian/libvirt-daemon-system.postinst | 8 
 debian/libvirt-daemon-system.postrm   | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/debian/libvirt-daemon-system.postinst 
b/debian/libvirt-daemon-system.postinst
index d0d670d..99e9fec 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -20,7 +20,7 @@ set -e
 add_users_groups()
 {
 if ! getent group libvirt >/dev/null; then
-addgroup --system libvirt
+addgroup --quiet --system libvirt
 fi
 
 if ! getent group kvm >/dev/null; then
@@ -41,7 +41,7 @@ add_users_groups()
 fi
 if ! getent group libvirt-qemu >/dev/null; then
 addgroup --quiet --system libvirt-qemu
-adduser libvirt-qemu libvirt-qemu
+adduser --quiet libvirt-qemu libvirt-qemu
 fi
 }
 
@@ -106,8 +106,8 @@ case "$1" in

 # Force virtlockd to reexec if enabled
 if [ -d /run/systemd/system ]; then
-  ! systemctl is-active -q virtlogd || systemctl reload 
virtlogd.service
-  ! systemctl is-active -q virtlockd || systemctl reload 
virtlockd.service
+  ! systemctl is-active -q virtlogd || systemctl reload 
virtlogd.service >/dev/null
+  ! systemctl is-active -q virtlockd || systemctl reload 
virtlockd.service >/dev/null
 fi
 
 # Force refresh of capabilties (#731815)
diff --git a/debian/libvirt-daemon-system.postrm 
b/debian/libvirt-daemon-system.postrm
index 62d9b4b..179ed93 100644
--- a/debian/libvirt-daemon-system.postrm
+++ b/debian/libvirt-daemon-system.postrm
@@ -22,15 +22,15 @@ set -e
 case "$1" in
 purge)
if getent group libvirt >/dev/null; then
-   delgroup libvirt || true
+   delgroup libvirt >/dev/null || true
fi
 
if getent passwd libvirt-qemu >/dev/null; then
-   deluser libvirt-qemu || true
+   deluser libvirt-qemu >/dev/null || true
fi
 
if getent group libvirt-qemu >/dev/null; then
-   delgroup libvirt-qemu || true
+   delgroup libvirt-qemu >/dev/null || true
fi
 
# Clean up logs and cached capabilities
-- 
2.10.2

Bug#844339: [PATCH v3 3/4] libvirt-daemon-system.postinst: use allocated uid/gid if possible

[Mauricio Faria de Oliveira]

Use the allocated uid/gid for libvirt-qemu
when creating the user/group, if not taken.

In case it's taken, the user has been asked
to continue or abort the installation, thus
if we are here, it is OK to proceed and not
use the allocated uid/gid.

Signed-off-by: Mauricio Faria de Oliveira 
---
 debian/libvirt-daemon-system.postinst | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/debian/libvirt-daemon-system.postinst 
b/debian/libvirt-daemon-system.postinst
index f36b806..3730783 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -20,6 +20,10 @@ set -e
 # Source debconf library.
 . /usr/share/debconf/confmodule
 
+# Allocated UID and GID for libvirt-qemu
+LIBVIRT_QEMU_UID=64055
+LIBVIRT_QEMU_GID=64055
+
 add_users_groups()
 {
 if ! getent group libvirt >/dev/null; then
@@ -31,6 +35,13 @@ add_users_groups()
 fi
 # user and group libvirt runs qemu/kvm instances with
 if ! getent passwd libvirt-qemu >/dev/null; then
+
+# set uid if available (expected); don't fail otherwise.
+PARAMETER_UID=''
+if ! getent passwd $LIBVIRT_QEMU_UID >/dev/null; then
+PARAMETER_UID="--uid $LIBVIRT_QEMU_UID"
+fi
+
 adduser --quiet \
 --system \
 --ingroup kvm \
@@ -40,10 +51,18 @@ add_users_groups()
 --home /var/lib/libvirt \
 --no-create-home \
 --gecos "Libvirt Qemu" \
+$PARAMETER_UID \
 libvirt-qemu
 fi
 if ! getent group libvirt-qemu >/dev/null; then
-addgroup --quiet --system libvirt-qemu
+
+# set gid if available (expected); don't fail otherwise.
+PARAMETER_GID=''
+if ! getent group $LIBVIRT_QEMU_GID >/dev/null; then
+PARAMETER_GID="--gid $LIBVIRT_QEMU_GID"
+fi
+
+addgroup --quiet --system $PARAMETER_GID libvirt-qemu
 adduser --quiet libvirt-qemu libvirt-qemu
 fi
 }
-- 
2.10.2

Bug#844339: [PATCH v3 4/4] update changelog

[Mauricio Faria de Oliveira]

Signed-off-by: Mauricio Faria de Oliveira 
---
 debian/changelog | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 70f3b31..643e29f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libvirt (2.4.0-2uidgid3) UNRELEASED; urgency=medium
+
+  * Use allocated uid/gid for libvirt-qemu if possible (Closes: #844339)
+[...] libvirt-daemon-system.postinst: use allocated uid/gid if possible
+[...] libvirt-daemon-system.{config,templates,postinst,NEWS}: warn if 
allocated uid/gid is taken
+[...] libvirt-daemon-system.post{inst,rm}: quiet output for debconf
+
+ -- Mauricio Faria de Oliveira   Thu, 18 Nov 2016 
13:56:38 -0200
+
 libvirt (2.4.0-2) unstable; urgency=medium
 
   * [f964983] Unbreak rebuilding docs with release tarballs (Closes: #842452)
-- 
2.10.2

Bug#841183: dvbcut: mplayer2 has gone away

[James Cowgill]

On 18/11/16 17:24, Bernhard Übelacker wrote:
> Am 18.11.2016 um 18:08 schrieb James Cowgill:
>> On 18/11/16 14:28, Bernhard Übelacker wrote:
>>> Hello James,
>>> sorry for the late reply.
>>>
>>> I prepared a new version removing mplayer2 and opened a RFS in [1].
>>
>> Why did you remove mpv?
> 
> Hello James,
> because currently dvbcut executes just plain "mplayer".
> And as far as I see mpv does not provide a binary with that name.
> 
> The recommends mpv seems as it was already useless for Jessie (except
> the user manually created a link from mplayer to mpv).

Ok that makes sense.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841183: dvbcut: mplayer2 has gone away

[Bernhard Übelacker]

Am 18.11.2016 um 18:08 schrieb James Cowgill:
> On 18/11/16 14:28, Bernhard Übelacker wrote:
>> Hello James,
>> sorry for the late reply.
>>
>> I prepared a new version removing mplayer2 and opened a RFS in [1].
> 
> Why did you remove mpv?

Hello James,
because currently dvbcut executes just plain "mplayer".
And as far as I see mpv does not provide a binary with that name.

The recommends mpv seems as it was already useless for Jessie (except
the user manually created a link from mplayer to mpv).

Kind regards,
Bernhard

Bug#844242: RFS: terminology/0.9.1-0.1 [RC] [NMU]

[Ross Vandegrift]

On Fri, Nov 18, 2016 at 05:04:02PM +, Gianfranco Costamagna wrote:
> >   [ Ross Vandegrift ]
> 
> >   * Non-maintainer upload.
> 
> Hi Ross, can you please fix and answer if  you want to maintain or not
> the package?

Sorry for the slow response - I'm planning to fix this weekend,
and adopt in pkg-e-devel.

Ross

Bug#840039: Fwd: Bug#840039: ITA: httpbin -- HTTP request and response service

[Daniel Stender]

On Thu, 17 Nov 2016 16:53:16 -0400 Luis Alfredo da Silva 
 wrote:
> Hi guys, can I maintain this package inside the team, and what would I need 
> to proceed and to whom should I report?

Hi,

if you want to take over the maintenance of this package you're welcome. You 
can reach me for sponsorship/upload
when your package is ready to go. Please regard that the bug reporter doesn't 
get copies of emails to this bug
by default.

For your questions on what's the point of the package being in python-apps:

- the package source is maintained in Subversion in the group repository. Until 
there's no particular
reason this ideally would be kept. But that's your decision.

- for submitting your changes on the package, you would need membership to this 
group. You can ask
for that either on debian-python or use the application page on Alioth.

Best,
DS

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
LPIC-1 (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/



signature.asc
Description: OpenPGP digital signature

Bug#815170: love: New upstream version available

[Markus Koschany]

On 18.11.2016 17:11, Alexandre Detiste wrote:
> Hi,
> 
> I'm willing to maintain this package as a depedency of mrrescue.

That's great to hear!

> 
> The one thing I don't want is to learn svn again after so many years;
> so first step would be to move it to git. (while preserving history of course)

Sure, please go ahead. This script might be helpful for you.

https://anonscm.debian.org/cgit/pkg-games/svn-to-git.git

> 
> The upstream changelog for mrrescue is also minimal:
> https://github.com/SimonLarsen/mrrescue/compare/v1.02c...master
> 
> When I'm done I'll just need a sponsor.

Just ask on the list as usual, I can take a look at it then.


> PS: isn't it a bit playing against the "Transition freeze" rules ?

I don't see an issue if the package in question has only one r-dep which
is also controlled by us.

[...]

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#834402: aptitude: search loses column format when redirected or piped

[Yuri D'Elia]

Package: aptitude
Version: 0.8.3-1+b2
Followup-For: Bug #834402

I also consider this a regression. For instance, see this example:

aptitude -s search -F '%c%M %p' '~i' > status.txt

The width doesn't matter, I'm logging the output for archival. I actually
*want* infinite width.

But %M is now expanded to the empty string when missing, causing the output to
be mis-aligned. Fine, but consider the following tweak:

aptitude -s search -F '%c%1M %p' '~i' > status.txt

it *still* expands to empty, even though I'm requesting 1 column of output with
%1M in any condition.

This is broken.

-- Package-specific info:
Terminal: rxvt-unicode-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.3
Compiler: g++ 6.2.0 20161103
Compiled against:
 apt version 5.0.0
 NCurses version 6.0
 libsigc++ version: 2.10.0
 Gtk+ support disabled.
 Qt support disabled.

Current library versions:
 NCurses version: ncurses 6.0.20160917
 cwidget version: 0.5.17
 Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffcd5b67000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7fb2ddf5f000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7fb2ddd2f000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fb2ddb05000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fb2dd8fe000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fb2dd601000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fb2dd2f7000)
libboost_iostreams.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7fb2dd0df000)
libboost_filesystem.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7fb2dcec6000)
libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7fb2dccc2000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fb2dc8b4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fb2dc697000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fb2dc314000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb2dc01)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fb2dbdf9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb2dba5b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb2db857000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fb2db64)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb2db424000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fb2db214000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fb2dafee000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fb2daddc000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fb2dabd4000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fb2da9cd000)
/lib64/ld-linux-x86-64.so.2 (0x55d973091000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.8.3-1
ii  libapt-pkg5.0  1.3.1
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-iostreams1.62.0   1.62.0+dfsg-4
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libc6  2.24-5
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.2.0-13
ii  libncursesw5   6.0+20160917-1
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libsqlite3-0   3.15.1-1
ii  libstdc++6 6.2.0-13
ii  libtinfo5  6.0+20160917-1
ii  libxapian301.4.1-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-11
ii  sensible-utils 0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index0.49
pn  aptitude-doc-en | aptitude-doc  
ii  debtags 2.1.2
pn  tasksel 

Bug#844751: zulucrypt: build-depends on no longer available libqtkeychain0

[Adrian Bunk]

Source: zulucrypt
Version: 4.9.0-2
Severity: serious

zulucrypt build-depends on no longer available libqtkeychain0.

Why does it build-depend on that package, in addition to
build-depending on qtkeychain-dev?

Bug#844752: perl: Configure test stores uninitialized memory in longdblinfbytes

[Niko Tyni]

Package: perl
Version: 5.24.1~rc3-3
Severity: normal
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The Configure test for long double implementation details probes the
contents of "long double inf", and they get stored in the Config module:

 % perl -V:longdblinfbytes
 longdblinfbytes='0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0xff, 0x7f, 
0x40, 0x00, 0x00, 0x00, 0x00, 0x00';

Some of these bytes are currently essentially random and vary between
builds on at least amd64 and i386, because their long doubles are only
80-bit and the remaining six bytes stay uninitialized.

The relevant Configure probe tries to initialize these bytes, but has
several bugs that defeat the purpose. Patch attached.

The randomness seems to only have started to show with GCC-6 for
one reason or another; the bytes are zeroed out on at least GCC-5.
-- 
Niko Tyni   nt...@debian.org
>From 97eaa8936166129d88f778562e587a9151ce15b7 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Fri, 18 Nov 2016 18:36:34 +0200
Subject: [PATCH] Configure: fix garbage filtering with 80-bit long doubles

The test had several problems that resulted in the excess
bytes not getting zeroed out. This caused random contents in
$Config{longdblinfbytes}, observed on Debian with GCC 6.2.0 (but not
5.4.1).
---
 Configure | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/Configure b/Configure
index 6a3d617..f561a87 100755
--- a/Configure
+++ b/Configure
@@ -20661,8 +20661,8 @@ $cat >try.c <

Bug#844755: connman: libxtables.so.11 No such file or directory

[Debianer]

Package: connman
Version: 1.33-1
Severity: important

Dear Maintainer,

with the latest libxtables11 in Debian stretch/sid connmand does not start any 
longer:

/usr/sbin/connmand -n
/usr/sbin/connmand: error while loading shared libraries: libxtables.so.11: 
cannot open shared object file: 1

This is since libxtables11 1.6.0+snapshot20161117-1, which installs 
libxtables.so.12:

/usr/lib/x86_64-linux-gnu# ls -la libxtables*
lrwxrwxrwx 1 root root20 Nov 18 17:55 libxtables.so.12 -> 
libxtables.so.12.0.0
-rw-r--r-- 1 root root 52088 Nov 17 11:46 libxtables.so.12.0.0

I would expect libxtables.so.11 in that path.

Thank you.


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

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

Versions of packages connman depends on:
ii  dbus 1.10.12-1
ii  init-system-helpers  1.46
ii  libc62.24-5
ii  libdbus-1-3  1.10.12-1
ii  libglib2.0-0 2.50.2-1
ii  libgnutls30  3.5.6-4
ii  libreadline7 7.0-1
ii  libxtables11 1.6.0+snapshot20161117-1
ii  lsb-base 9.20161101

Versions of packages connman recommends:
pn  bluez  
pn  ofono  
ii  wpasupplicant  2.5-2+v2.4-3+b1

Versions of packages connman suggests:
pn  indicator-network  

-- no debconf information

Bug#840211: perlunicook man page does not display utf8 char beyond ascii

[Dominique Dumont]

On Friday, 18 November 2016 09:34:03 CET Russ Allbery wrote:
> Guillem did some more investigation, and sadly it turns out that raw UTF-8
> in man pages continues to break even completely current man
> implementations on platforms like macOS.

That's a constraint we do not have on Debian/unstable.

Considering [1], we may want to patch Debian's perl to produce utf8 man pages 
even if upstream cannot, due to portability constraints.  

All the best.

[1] https://wiki.debian.org/ReleaseGoals/utf-8
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#844539: Please revert DN related behaviour change introduced in 3.5.6

[Guido Günther]

Hi,
On Thu, Nov 17, 2016 at 07:57:05PM +0100, Andreas Metzler wrote:
> On 2016-11-16 Guido Günther  wrote:
> > Package: libgnutls30
> > Version: 3.5.6-4
> > Severity: normal
> 
> > Hi,
> > 3.5.6 introduced a behaviour change that breaks libvirt. See
> [...]
> 
> Would you consider this to be a serious issue for libvirt? i.e. should
> we block unfixed gnutls from propagating to testing?

I don't think that would be a good idea.

> 
> Fixed packages just uploaded to experimental. I would appreciate some
> testing. - TIA

Make check works fine with the new version and the rest of the system
didn't break either!
Cheers,
 -- Guido

Bug#844754: xonsh FTBFS in stretch due to missing cloud-sptheme

[Adrian Bunk]

Source: xonsh
Version: 0.4.7+dfsg-1
Severity: serious
Tags: stretch
Control: block -1 by 829230

xonsh build-depends on python3-cloud-sptheme, which is not in stretch
due to #829230

Bug#844560: check for config file existence is wrong

[Ian Jackson]

Hi.  Thanks for your attention to this mostly-cosmetic bug...

Mattia Rizzolo writes ("Re: Bug#844560: check for config file existence is 
wrong"):
> It does a regular
> if [ -f "$RCFILE" ]; then
> . "$RCFILE"

Yes.

> Which fails for non-regular files like /dev/null is.

Indeed.

> Do you mean that probably the message should takr into account that a reason
> for failure of that test could be something different than enonet?

Well, that would be one "fix".  It would stop the message from being
untruthful.  It has the virtue of being very easy.

But what I was suggesting was just to get rid of the separate test.  I
notice now that this is supposed to be a warning rather than an error,
so my suggestion wouldn't work.

> If that the problem it could prably be solved imho in a nicer way by nesting
> another if in the else branch to check for simple existence (by [ -e $file ])
> and print a proper message if the file exists but it's not regular, and keep
> the current message only for the real enoent case.

I think this way lies madness.  We already have a mechanism for
figuring out what went wrong: bash tries to open the file, and the
kernel figures out why it can't be opened, and tells bash an errno
value.  Trying to replicate this logic in your script will result in
an ever-increasing set of cases.

How about

  . "$RCFILE" || echo "W: $RCFILE could not be sourced" >&2

?

That would result in this:

mariner:~> bash -ec 'RCFILE=/dev/enoent; . "$RCFILE" || echo "W:
$RCFILE could not be sourced" >&2'
bash: /dev/enoent: No such file or directory
W: /dev/enoent could not be sourced
mariner:~>

Or you could just leave out the echo and do

  . "$RCFILE" ||:


If you don't like those suggestions, how about simply changing -f to
-e ?  That way /dev/null will just work.  And the existing message
about nonexistence would be truthful.

If the `.' fails for some reason other than nonexistence (eg, the file
exists but has wrong permissions, or it's actually a socket, or
something) then it's probably best to bomb out, anyway.

Regards,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#844749: live-build: Jessie image with backported kernel (linux-image-4.7.0-0.bpo.1-amd64) doesn't boot

[Igor Starkov]

Package: live-build
Version: 4.0.3-1
Severity: important

Dear Maintainer,

   * I'm trying to build live Jessie image with backported kernel. 
 Kernel version: linux-image-4.7.0-0.bpo.1-amd64

   * Steps to reproduce:
   lb config noauto \
--apt-indices false \
--apt-source-archives false \
--architectures amd64 \
--bootstrap debootstrap \
--backports true \
--linux-packages linux-image-4.7.0-0.bpo.1 \
--debian-installer false \
--system live \
--iso-application "x" \
--iso-publisher "x" \
--iso-volume "x" \
--archive-areas "main contrib non-free" \
--source false \
--memtest none \
--verbose \
--debug \
--win32-loader false \
--updates true \
--firmware-chroot true \
--firmware-binary true \
--bootappend-live "boot=live config live-config.utc=no" \
--binary-filesystem fat32 \
--binary-images hdd \
--zsync false 
   
   echo "linux-base/jessie-backports" > 
config/package-lists/jessie-backports.list.chroot
   lb build 2>&1 | tee build.log
   
   Then I was trying to boot kvm from this image.

   * This leads to:
   Image boots, then after a while during booting kernel and initrd I see 
messages like this:
   ---
   [2.971437] cloclsource: Switched to clocksource tsc
   [2.974235] FAT-fs (sda1): IO charset ascii not found
   mount: mounting /dev/sda1 on /live/medium failed: Invalid argument
    skipped similar lines 
   [   63.554664] FAT-fs (sda1): IO charset ascii not found
   mount: mounting /dev/sda1 on /live/medium failed: Invalid argument
   ---
   and boot process exits to initrd's BusyBox prompt.

   * Expected result:
   Normal kernel boot process, leading to bash prompt.

   I've changed /usr/lib/live/build/binary_hdd file, but this was nesessary to 
fix other bug in debian-live:
   
https://lists.debian.org/debian-live/2014/12/msg00122.htmlhttps://lists.debian.org/debian-live/2014/12/msg00122.html

-- Package-specific info:

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages live-build depends on:
ii  debootstrap  1.0.67

Versions of packages live-build recommends:
ii  cpio2.11+dfsg-4.1+deb8u1
ii  live-boot-doc   4.0.2-1
ii  live-config-doc 4.0.4-1
ii  live-manual-html [live-manual]  1:4.0.1-1

live-build suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/live/build/binary_hdd (from live-build package)

Bug#844160: Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2

[Adrian Bunk]

On Fri, Nov 18, 2016 at 06:10:31AM +0100, Stefan Fritsch wrote:
> On Friday, 18 November 2016 01:09:53 CET Adrian Bunk wrote:
> > On Thu, Nov 17, 2016 at 11:18:57PM +0100, Stefan Fritsch wrote:
> > > On Thursday, 17 November 2016 21:39:19 CET Kurt Roeckx wrote:
> > > > > That header was created for mod_ssl_ct which provides support for
> > > > > certificate  transparency. It's quite new and likely that nothing else
> > > > > uses the header. It would probably be acceptable to remove the
> > > > > dependency
> > > > > in apache2-dev on libssl-dev and add a caveat to the README.Debian. I
> > > > > could also not install the header, or put it into a separate new
> > > > > package
> > > > > that depends on libssl-dev.
> > > > 
> > > > So can you confirm that the only reason for the libssl-dev
> > > > depedency is that file?
> > > 
> > > Yes.
> > 
> > What does create the dependency in
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828330#16
> > ?
> 
> By including its own copy of ssl_private.h from the apache source (not 
> installed in apache2-dev). Urgh.
> 
> /*
>  * After 2.0.49, Apache mod_ssl has most of the mod_ssl structures defined
>  * in ssl_private.h, which is not installed along with httpd-devel (eg in
>  * the FC2 RPM.) This include file provides SIMPLIFIED structures for use
>  * by mod_gridsite: for example, pointers to unused structures are replaced
>  * by  void *  and some of the structures are truncated when only the early
>  * members are used.
>  *
>  * CLEARLY, THIS WILL BREAK IF THERE ARE MAJOR CHANGES TO ssl_private.h!!!
>  */

Are there other packages that are doing similar things?

And unrelated to the problem in this bug:
Now that there is a proper header, it should be used in GridSite?

> That's very ugly. So, not installing mod_ssl_openssl.h or a caveat in 
> README.Debian would not help.
> 
> But putting it into a separate apache2-mod_ssl-dev package with the proper 
> mod_ssl dependency would still work. gridsite would then need to build-dep on 
> that package and (AFAICS) php does not do the same ugly tricks and would be 
> unaffected by the dependency on libssl1.0-dev.

This is the build-dependency side.

But this would still allow installing GridSite and Apache compiled with 
different OpenSSL versions.

Creating a dependency on apache-abi-openssl-1-0-2 for every user of the 
affected symbols and providing that (similar to qtbase-abi-5-6-1) would
be the proper solution.

cu
Adrian

-- 

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

Bug#771183: Specific to gdm3

[Andreas Henriksson]

Control: tags -1 + wontfix

Hello "cid " and Brian Quigley.


cid wrote:
> Gnome core sould be a minimal, core package that not blow up unnecesarry our 
> system.

No, gnome-core is a meta-package that's *not* supposed to be a minimal
selection of components but one that matches what GNOME upstream defines
as "GNOME Core Applications".

If you want to have a meta-package that's what you define as minimal
then feel free to create one! gnome-core is not it.
(Also if you don't want to follow the gnome definition then maybe
you're also better of not using the gnome trademark in the name of
your meta-package either.)


On Fri, Nov 18, 2016 at 04:44:58AM -0500, Bryan Quigley wrote:
> Hi Maintainer,
> 
> The gdm3 dependency is a bit different than just including an application.
> Could we move the gdm3 dependency to task-gnome-desktop? or to the
> gnome metapackage?

No, because gdm3 is really a core component and needs to be part
of even a minimal gnome installation. For example gnome-shell depends
on gdm3 to work correctly. Could something not including gnome-shell
be called GNOME? I wouldn't. (But in the end it would be up to
gnome upstream to enforce their trademark, so don't bother with what
I think on the matter.)

Regards,
Andreas Henriksson

Bug#844750: debcheck: pages should link to tracker.d.o instead of packages.qa.d.o

[Adrian Bunk]

Package: qa.debian.org
Severity: wishlist

https://qa.debian.org/dose/debcheck/src_testing_main/1479445206/packages/syslog-ng.html

It would be nice if the PTS link would go to tracker.d.o
instead of packages.qa.d.o

A related nice feature would be tracker.d.o links for the missing
(build) dependencies (in this case libssl1.0-dev) - this is the
first thing I am interested in when looking at such a page.

Thanks in advance!

Bug#815170: love: New upstream version available

[Alexandre Detiste]

Hi,

I'm willing to maintain this package as a depedency of mrrescue.

The one thing I don't want is to learn svn again after so many years;
so first step would be to move it to git. (while preserving history of course)

The upstream changelog for mrrescue is also minimal:
https://github.com/SimonLarsen/mrrescue/compare/v1.02c...master

When I'm done I'll just need a sponsor.

PS: isn't it a bit playing against the "Transition freeze" rules ?

Current mrrescue does mostly work with newer Löve;
changelogs merely says "Fixed pixel font spacing";
but I couldn't find this glitch myself.

Greets,

Alexandre

2016-11-18 16:53 GMT+01:00 Markus Koschany :
> thank you for contacting us. To be honest the true reason why nobody is
> packaging a new upstream release of love is that we are understaffed.
> There are people in this team that will help with reviewing and
> uploading the package but someone else must get involved who wants to
> maintain love for the foreseeable future.

Bug#842422: network-manager: NetworkManager fails to authenticate with old 802.11bg USB devices

[Georg Colle]

Hi, got quite the same issues using network-manager 1.4.2-2,
network-manager-gnome 1.4.2-1, and wpasupplicant 2.5-2+v2.4-3+b1 trying to
connect dongles AVM FRITZ!Wlan N, D-Link DWA-160 B2, and ASUS USB-N53 to
the acces-points of routers Netgear DGND3800b and FRITZ!Box 7490.

Using networking.service together with appropriate /etc/network/interfaces
and wpa_supplicant could be useful as a workaround. At least this worked
for me in 2012 when I bought those dongles.

Greeting, Georg
-- 
... post tenebras spero lucem. (Hiob 17,12 Vul.)

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

Hi,

On Fr, 2016-11-18 at 17:01 +0100, Patrick Matthäi wrote:
> Am 17.11.2016 um 18:52 schrieb Stephan Sürken:
> > 
> > Hi Patrick,
> > 
> > On Do, 2016-11-17 at 15:40 +0100, Patrick Matthäi wrote:
> > (...)
> > > 
> > > Then the question is, why it does not work on Jessies grep?
> > did you overlook my comment? Or are my findings wrong?
> > 
> > Thx!
> > 
> > S
> Ah now I get it. You have adjusted the C code of apt-dater, to detect
> errors without using HTML.

not quite. I rather fixed the default pattern being used when the user
does not configure one.

> But we have got still the problem, that the default grep syntax (also
> your fixed grep syntax) from "typescript" produces a more or less
> silent
> "syntax error", like from the beginning of this report.

afaict, my patch just fixes each and every aspect of this bug report
;).

Hth,

S

Bug#840211: perlunicook man page does not display utf8 char beyond ascii

[Russ Allbery]

Niko Tyni  writes:

> I think upstream (Russ and iirc others on p5p too) have been stepping
> very carefully here due to compatibility issues with older nroff
> implementations and the like.

Guillem did some more investigation, and sadly it turns out that raw UTF-8
in man pages continues to break even completely current man
implementations on platforms like macOS.

> There's [rt.cpan.org #68741] upstream, quoting Russ in 2011: "I'm
> currently leaning towards outputing UTF-8 by default, but I'm kicking
> around the idea of trying to use the user's locale."

> Russ, any thoughts about the current status?

I still haven't done anything.  :(  It looks like any solution will
require generating non-portable man pages.  Maybe that doesn't matter any
more, and I should just default to generating UTF-8 man pages on any Linux
platform.

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

Bug#844139: python-django: FTBFS: Tests failures

[Lucas Nussbaum]

Hi,

On 16/11/16 at 18:44 +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Sat, 12 Nov 2016, Scott Kitterman wrote:
> > > This failure happens on a CPU with TSX extensions available, but is not
> > > reproducible on a machine without them. 
> 
> I can't reproduce this either on my machine. But I have other failures
> (see below).
> 
> Lucas, can you see if you reproduce your problem with this small
> patch:
> --- a/debian/rules
> +++ b/debian/rules
> @@ -23,7 +23,7 @@ override_dh_auto_test:
>  ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
> set -e; cd tests && for python in $$(pyversions -s) $$(py3versions 
> -s); do \
> echo "——— Running tests with $$python ———"; \
> -   LC_ALL=C.UTF-8 PYTHONPATH=.. $$python ./runtests.py 
> --verbosity=2; \
> +   LC_ALL=C.UTF-8 PYTHONPATH=.. $$python ./runtests.py 
> --verbosity=2 --parallel=4; \
> done
>  endif

I can still reproduce the problem today _without_ the patch;
and adding --parallel=4 "fixes" the problem.

Lucas

Bug#838694: icu: CVE-2016-7415: Stack based buffer overflow in locid.cpp

[GCS]

Hi Salvatore,

Thanks for the ping and the actual ICU bug link.

On Fri, Nov 18, 2016 at 3:34 PM, Salvatore Bonaccorso  wrote:
> According to https://bugzilla.redhat.com/show_bug.cgi?id=1377361#c5
> there is now an upstream bug about the issue, but unfortunately for
> some reason it is still marked as private.
>
> http://bugs.icu-project.org/trac/ticket/12745
 That's for two weeks now! I don't see a reason why this vulnerability
takes such long to fix in ICU. :( Hopefully it will be open in time
for Stretch. :-/

Cheers,
Laszlo/GCS

Bug#840186: [Debichem-devel] Bug#840186: Bug#840186: nwchem builds on amd64 with -march=native

[Apra, Edoardo]

Yes,

You are right. I mistakenly sent the -R version.

The new attachment should be the right one.

Could you please update the NWChem Debian source?

We already got a few report of failures from NWChem users.

Thanks, Edo


On 11/18/2016 03:16 AM, Michael Banck wrote:
> Hi,
>
>> On Fri, Nov 18, 2016 at 01:18:23AM +, Apra, Edoardo wrote:
>>> -  FOPTIONS +=  -mtune=native
>>> +  FOPTIONS += -march=native -mtune=native
> By the way, it seems this patch is reversed, as it adds -march=native.
>
>
> Michael
>

--- nwchem-6.6/src/config/makefile.h.orig	2016-11-17 22:26:29.497599135 +
+++ nwchem-6.6/src/config/makefile.h	2016-11-17 22:29:09.794581240 +
@@ -1956,7 +1956,7 @@
   FOPTIONS +=  -ff2c -fno-second-underscore
 endif
 ifeq ($(GNU_GE_4_6),true) 
-  FOPTIONS += -march=native -mtune=native
+  FOPTIONS +=  -mtune=native
   FOPTIONS += -finline-functions
 else
 ifeq ($(_GOT3DNOW),Y) 

Bug#844753: vorbis-java FTBFS in stretch due to missing tika

[Adrian Bunk]

Source: vorbis-java
Version: 0.6-1
Severity: serious
Tags: stretch
Control: block -1 by 825501

vorbis-java build-depends on libtika-java, which is not in testing
due to #825501

Bug#844303: More details on the ncrack build failure

[Adrian Bunk]

Control: block 827061 by -1

The relevant parts of the build log and opensshlib/config.log are:

checking OpenSSL header version... 1010003f (OpenSSL 1.1.0c  10 Nov 2016)
checking OpenSSL library version... 1010003f (OpenSSL 1.1.0c  10 Nov 2016)
checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your
library. Check config.log for details.
...
conftest.c:217:8: warning: implicit declaration of function 'SSLeay' 
[-Wimplicit-function-declaration]
   exit(SSLeay() == OPENSSL_VERSION_NUMBER ? 0 : 1);
^~
/tmp/cc7VXYCF.o: In function `main':
./opensshlib/conftest.c:217: undefined reference to `SSLeay'
collect2: error: ld returned 1 exit status
configure:12201: $? = 1
configure: program exited with status 1
configure: failed program was:
...
|   #include 
|   #include 
| 
| int
| main ()
| {
| 
|   exit(SSLeay() == OPENSSL_VERSION_NUMBER ? 0 : 1);
| 
|   ;
|   return 0;
| }
...



cu
Adrian

-- 

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