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#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#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#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#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#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#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#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#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#841183: dvbcut: mplayer2 has gone away

[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?

Thanks,
James



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#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#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 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#844242: RFS: terminology/0.9.1-0.1 [RC] [NMU]

[Gianfranco Costamagna]

control: reopen -1


>   [ Ross Vandegrift ]

>   * Non-maintainer upload.

Hi Ross, can you please fix and answer if  you want to maintain or not
the package?

thanks,

G.

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#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

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#844748: openocd: Please package upstream snapshot with jtagspi

[Stefano Rivera]

Package: openocd
Version: 0.9.0-1+b1
Severity: normal

Is there any chance of getting an upstream snapshot that includes the
jtagspi driver?

It was added in d25355473da9a925a696183a9947aac292cd2f60 upstream (Jul 2015).

We (DebConf video team) need it to flash our HDMI capture boards. So,
having a package (even in experimental) would be useful.

SR

Bug#843061: radeon/hawaii_k_smc.bin fails to load with 4.8 kernel

[Ferdinand Pöll]

I also have this problem, but with an AMD Radeon R9 270X (Curacao XT, which is 
a Pitcairn refresh). It also happens with any of the 4.9 kernels from 
experimental, and doesn‘t happen on the newest 4.7. I can still ssh on the 
affected PC. 

My journalctl shows me the following messages: 
Nov 18 16:52:57 fp-pc kernel: [drm] radeon: 4096M of VRAM memory ready
Nov 18 16:52:57 fp-pc kernel: [drm] radeon: 2048M of GTT memory ready.
Nov 18 16:52:57 fp-pc kernel: [drm] Loading pitcairn Microcode
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: firmware: direct-loading 
firmware radeon/pitcairn_pfp.bin
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: firmware: direct-loading 
firmware radeon/pitcairn_me.bin
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: firmware: direct-loading 
firmware radeon/pitcairn_ce.bin
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: firmware: direct-loading 
firmware radeon/pitcairn_rlc.bin
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: firmware: direct-loading 
firmware radeon/pitcairn_mc.bin
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: firmware: failed to load 
radeon/pitcairn_k_smc.bin (-2)
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: Direct firmware load for 
radeon/pitcairn_k_smc.bin failed with error -2
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: firmware: direct-loading 
firmware radeon/PITCAIRN_smc.bin
Nov 18 16:52:57 fp-pc kernel: si_fw: mixing new and old firmware!
Nov 18 16:52:57 fp-pc kernel: [drm:si_init [radeon]] *ERROR* Failed to load 
firmware!
Nov 18 16:52:57 fp-pc kernel: radeon :01:00.0: Fatal error during GPU init
Nov 18 16:52:57 fp-pc kernel: [drm] radeon: finishing device.

The last message I see on the connected screen is: 
kernel: fb: switching to radeondrmfb from simple

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

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#826728: percona-toolkit: (CVE-2014-2029) scripts call back home and leak information

[Dario Minnucci]

Hi guys,

On 11/04/16 14:38, Guillem Jover wrote:
> ... 
> This is the relevant strace part for percona-toolkit 2.2.18-1:
> 
> ,---
> connect(3, {sa_family=AF_INET, sin_port=htons(443), 
> sin_addr=inet_addr("74.121.199.234")}, 16) = 0
> `---
> 
> Where 74.121.199.234 is www.percona.com.
> 

I've just discussed this issue with upstream just a minute ago and it seems 
there is a simple
solution for it...

There is a global configuration file to affect every percona-toolkit package 
tools.
(See: https://www.percona.com/doc/percona-toolkit/2.2/configuration_files.html)

The workaround consists in create (or modify) the file 
'/etc/percona-toolkit/percona-toolkit.conf'
an add 'noversion-check' to it.


---%<-
cat << EOF >> /etc/percona-toolkit/percona-toolkit.conf
noversion-check
EOF
---%<-


This global configuration file (/etc/percona-toolkit/percona-toolkit.conf) 
should be read by every
tool in percona-toolkit package disabling the 'call home' functionality.

Can you try this solution and report results?

-- 
 Dario Minnucci 
 Phone: +34 902021030 | Fax: +34 902024417
 Key fingerprint = BAA1 7AAF B21D 6567 D457  D67D A82F BB83 F3D5 7033




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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#591717:

[George Pedro]

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

S pozdravem,

George.

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#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#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#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#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#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#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#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#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#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#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]

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#639910: Packaging sbt

[Frederic Bonnard]

Hello Mehdi/Emmanuel/all,
back on that topic,  I did some work and would need  your feedback on it
before going further.

What Mehdi said in his last comment, inspired me the following :

For sbt source package, I created 4 "sources" tarball :
1. sbt_0.13.13~RC1.orig.tar.gz : this is  the upstream source release of
sbt : https://github.com/sbt/sbt
2. sbt_0.13.13~RC1.orig-bootstrapsbt.tar.xz : this is the binary (mainly
sbt-launch.jar)  of the  previous sbt  version,  in our  case :  0.13.12
previous
3. sbt_0.13.13~RC1.orig-bootstrapdeps.tar.xz  : these  are all  the jars
that sbt 0.13.12 binary would fetch when running against that particular
project.
4.  sbt_0.13.13~RC1.orig-launcher.tar.xz  :  additional source  for  the
launcher : https://github.com/sbt/sbt-launcher-packag  e

1 and 4 are simply the tarballs from upstream projects.
2 and 3 are created from debian/rules get-orig-source target.
2  is the  binary tarball  that upstream  already provides,  but it's  a
"minimal" sbt  without all the  jars needed to  run. At launch  time, it
would detect that and will fetch all them.
For 3, I use the sbt binary of  2, to fetch all the jars it needs online
and I build a tarball from that.
This enables  to build the  source of  the project offline  (forcing it)
with all needed jars.

The point is  that the sbt package  I built is "nude". If  I install the
package built, the  0.13.13~RC1 version of sbt would need  a minimal set
of jars that is  missing (in the same way of 2)  and "sbt" command would
fail.
So I did the  same for all the dependencies needed  by this minimal sbt,
so that running "sbt" from the command line won't complain.
That is, for all dependencies that are  not already in Debian, I built a
package and as most of them (if not all if I remember) are sbt projects,
I  did that  3-tarball-source,  with the  upstream  project, a  prebuild
0.13.12 minimal binary sbt and a tarball of binary jars dependencies for
the latter.
This enabled to build packages for :
  https://github.com/bmc/classutil
  https://github.com/bmc/grizzled-scala
  https://github.com/bmc/scalasti
  https://github.com/foundweekends/giter8
  https://github.com/non/jawn
  https://github.com/json4s/json4s
  https://github.com/sbt/serialization
  https://github.com/sbt/test-interface
  https://github.com/scala/pickling
  https://github.com/harrah/sbinary
  https://github.com/scopt/scopt
and have a working sbt command  line without connecting online but using
Debian's local maven-repo.

There is much  work to finalize this  if that is ok,  but indeed, before
continuing I'd like to know if I'm on the good path.

F.

On Wed, 6 Jan 2016 01:58:13 +0100, Mehdi Dogguy  wrote:
> Hi,
> 
> On 05/01/2016 16:32, Emmanuel Bourg wrote:
> > The "easiest" solution is probably to start with a non-free sbt package
> > containing a prebuilt version of sbt, and then upload in main a sbt
> > package depending on itself with the prebuilt sbt removed. I would use
> > only one sbt package, instead of sbt-bootstrap in non-free and sbt in main.
> > 
> 
> Note that you can very much include a working sbt binary in the source
> package and use it the bootstrap sbt. The only condition that we must
> respect is to not ship that binary in the package, but ship the built
> binary only. This is done for many packages: OCaml for its bootstrap
> and most probably ghc (didn't check tbh). Also, compiling gcc requires
> a gcc. :-P
> 
> My 2 cents,
> 
> -- 
> Mehdi
> 

Bug#844714: [Python-modules-team] Bug#844714: python-pycparser: Not installable

[Scott Kitterman]

It looks like '${python3-ply:Depends},' needs to be removed from Depends in 
debian/control.  We've never supported that construct for python3.  
'${python-ply:Depends},' should go as well, but in that case it's only cleaning 
up a bit of deprecated fluff.  That's not actively harmful.

Scott K

On November 18, 2016 5:44:54 AM CST, "Ondřej Nový"  wrote:
>Package: python-pycparser
>Version: 2.17-1
>Severity: grave
>Justification: renders package unusable
>
>Hi,
>
>this package can't be installed:
>
>The following packages have unmet dependencies:
> python-pycparser : Depends: python-ply-lex-3.5 but it is not
> installable
> Depends: python-ply-yacc-3.5 but it is not
> installable
>
>-- System Information:
>Debian Release: stretch/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (1, 'experimental')
>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)
>
>___
>Python-modules-team mailing list
>python-modules-t...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Bug#844726: w3m: CVE-2016-9439: stack overflow

[Salvatore Bonaccorso]

Source: w3m
Version: 0.5.3-8
Severity: normal
Tags: security upstream patch
Forwarded: https://github.com/tats/w3m/issues/20

Hi,

the following vulnerability was published for w3m, I'm aware that this
is as well already fixed in the upstream git master. This bug is just
to track the issue since unfixed in 0.5.3-30 so that we can record it
as fixed once enters unstable.

CVE-2016-9439[0]:
stack overflow

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-9439

Regards and thanks for your work!
Salvatore

p.s.: all of the recently posted issues which got CVEs, seem to not
  warrant a DSA, but can be fixed via a point release. We have
  marked them already as such in the security-tracker.

Bug#844708: maildir-utils: `--clearlinks' option seems broken

[Norbert Preining]

forwarded 844708 https://github.com/djcb/mu/issues/951
thanks

> Version 0.9.17-1 seems to have broken the `--clearlinks' functionality,
> at least on my system.

Also here. I have created an issue on the github page.

Thanks for your report

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

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

[Guillem Jover]

Control: tags -1 patch

Hi!

On Fri, 2016-11-18 at 12:57:12 +0100, Guillem Jover wrote:
> On Sun, 2016-11-06 at 14:16:14 +0100, Helmut Grohne wrote:
> > Package: reprepro
> > Version: 4.17.1-1
> > Severity: important
> > User: helm...@debian.org
> > Usertags: rebootstrap
> > 
> > Since dpkg 1.18.11, a .buildinfo file is generated as part of package
> > builds and referenced by .changes files. Supplying such a .changes file
> > to "reprepro include" results in an error:
> > 
> > | Unknown file type: '2d3e9992648837b6a4a8a5b819e6da8e 4791 devel optional 
> > binutils_2.27.51.20161105-1_20161106T104833z-2d3e9992.buildinfo', assuming 
> > source format...
> > | .changes put in a
> > | distribution not listed within it!
> > | Ignoring as --ignore=wrongdistribution given.
> > | 'binutils_2.27.51.20161105-1_20161106T104833z-2d3e9992.buildinfo' looks 
> > like part of an source package, but no dsc file listed in the .changes file!
> > | There have been errors!   
> > 
> >   
> > 
> > So any workflow based on importing .changes files from unstable (soon
> > stretch) is now broken.
> 
> 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)

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
From: Guillem Jover 
Date: Fri, 18 Nov 2016 14:11:58 +0100
Subject: [PATCH] Add preliminary .buildinfo support

---
 changes.c   |  5 +++-
 changes.h   |  3 ++-
 checkin.c   | 51 +++--
 distribution.h  |  1 +
 docs/reprepro.1 |  3 +++
 incoming.c  | 78 +
 needbuild.c |  2 +-
 tracking.c  | 10 ++--
 trackingt.h |  1 +
 9 files changed, 141 insertions(+), 13 deletions(-)

diff --git a/changes.c b/changes.c
index 5d01754..2cafca3 100644
--- a/changes.c
+++ b/changes.c
@@ -237,6 +237,9 @@ retvalue changes_parsefileline(const char *fileline, /*@out@*/filetype *result_t
 		} else if (l > 6 && strncmp(p-6, ".build", 6) == 0) {
 			type = fe_LOG;
 			eoi = p - 6;
+		} else if (l > 10 && strncmp(p-10, ".buildinfo", 10) == 0) {
+			type = fe_BUILDINFO;
+			eoi = p - 10;
 		}
 		if (type != fe_UNKNOWN) {
 			/* check for a proper version */
@@ -255,7 +258,7 @@ retvalue changes_parsefileline(const char *fileline, /*@out@*/filetype *result_t
 	return RET_ERROR;
 }
 checkfilename = true;
-			} else if (type == fe_LOG) {
+			} else if (type == fe_LOG || type == fe_BUILDINFO) {
 if (*p == '_') {
 	archstart = p + 1;
 	archend = eoi;
diff --git a/changes.h b/changes.h
index 30ad136..f2b72c3 100644
--- a/changes.h
+++ b/changes.h
@@ -10,7 +10,8 @@ typedef enum {
 	fe_DEB, fe_UDEB,
 	fe_DSC, fe_DIFF, fe_ORIG, fe_TAR,
 	fe_ALTSRC,
-	fe_BYHAND, fe_LOG, fe_CHANGES
+	fe_BYHAND, fe_LOG, fe_CHANGES,
+	fe_BUILDINFO
 } filetype;
 
 #define FE_PACKAGE(ft) ((ft) == fe_DEB || (ft) == fe_UDEB || (ft) == fe_DSC)
diff --git a/checkin.c b/checkin.c
index 3b1ec32..3eb552e 100644
--- a/checkin.c
+++ b/checkin.c
@@ -161,7 +161,7 @@ static void changes_free(/*@only@*/struct changes *changes) {
 }
 
 
-static retvalue newentry(struct fileentry **entry, const char *fileline, const struct atomlist *packagetypes, const struct atomlist *forcearchitectures, const char *sourcename, bool includebyhand, bool includelogs, bool *ignoredlines_p, bool skip_binaries) {
+static retvalue newentry(struct fileentry **entry, const char *fileline, const struct atomlist *packagetypes, const struct atomlist *forcearchitectures, const char *sourcename, bool includebyhand, bool includelogs, bool includebuildinfos, bool *ignoredlines_p, bool skip_binaries) {
 	struct fileentry *e;
 	retvalue r;
 
@@ -207,7 +207,7 @@ static retvalue newentry(struct fileentry **entry, const char *fileline, const s
 		*ignoredlines_p = true;
 		return RET_NOTHING;
 	}
-	if (e->type != fe_LOG &&
+	if (e->type != fe_LOG && e->type != fe_BUILDINFO &&
 			e->architecture_into == architecture_source &&
 			strcmp(e->name, sourcename) != 0) {
 		fprintf(stderr,
@@ -242,6 +242,34 @@ static retvalue newentry(struct fileentry **entry, const char *fileline, const s
 			*ignoredlines_p = true;
 			return RET_NOTHING;
 		}
+	} else if (e->type == fe_BUILDINFO) {
+		if (strcmp(e->name, 

Bug#844724: apt: Does not seem to support new GnuPG keybox keyring format

[Julian Andres Klode]

Control: severity -1 wishlist

On Fri, Nov 18, 2016 at 01:58:18PM +0100, Guillem Jover wrote:
> Package: apt
> Version: 1.3.1
> Severity: important
> 
> [ Setting as important as this is GnuPG default, but if you think this
>   is a new feature or similar please just change it to wishlist. ]
> 
> Hi!
> 
> It seems like apt (and its gpgv method) do not support the new GnuPG
> keybox keyring format? Which is the one currently generated by default
> with newer GnuPG versions. A simple session to demonstrate:
> 
>   ,--- (line-wrapped for easier readability) ---
>   # cd /etc/apt/trusted.gpg.d
>   # file debian-archive-jessie-automatic.gpg
>   debian-archive-jessie-automatic.gpg: GPG key public ring,
>   created Fri Nov 21 21:01:13 2014
>   # mv debian-archive-jessie-automatic.gpg ~
>   # gpg --no-default-keyring --no-options --no-auto-check-trustdb \
> --keyring ./debian-archive-jessie-automatic.gpg --import \
> <~/debian-archive-jessie-automatic.gpg

The format we expect is the one generated by --export (standard concatenated
key packets), not the one used for creating keyrings by importing things.

We require that key files can be concatenated, otherwise we would have
to depend on gnupg to merge the key files for verification purposes.
-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Martin Steigerwald]

Dear Z-Shell developers,

I want to make you aware of the following issue with autocorrection I ran 
into:

autocorrection suggested rm for typing mr without typing "y"
https://bugs.debian.org/844710

Axel analysed this below a bit further an indeed, if I press the space bar, I 
get this:

ms@merkaba:~> cd /tmp   
ms@merkaba:/tmp> LANG=C mr test
zsh: correct 'mr' to 'rm' [nyae]?  
rm: cannot remove 'test': No such file or directory
ms@merkaba:/tmp#1>

So two fixes to consider:

1) Don´t confirm on space, as thats to easy to trigger accidentally. :)

2) Don´t autocorrect to dangerous commands like "rm". Could be a bit 
challenging to make a list of commands which are dangerous and can easily 
trigger unwanted actions. "rm" would IMO definately be one of this, while with 
"dd" it would be harder to trigger an unwanted action by accident due to 
syntax requirements.

Axel made me aware that I tell Z-Shell to ignore dangerous commands with 
CORRECT_IGNORE=rm, but I think it would be good to reconsider the standard 
behavior.

Thank you,
Martin

--  Weitergeleitete Nachricht  --

Betreff: Re: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for 
typing mr without typing "y"
Datum: Freitag, 18. November 2016, 13:59:34 CET
Von: Martin Steigerwald 
An: Axel Beckert 
Kopie: 844...@bugs.debian.org

Am Freitag, 18. November 2016, 13:00:24 CET schrieben Sie:
> Hi Martin,
> 
> Martin Steigerwald wrote:
> > ms@intraws:~/Backup/Mail/Linux> mr kernel-ml_archive.gz
> > kernel-ml_archive_2014-1b.gz zsh: correct 'mr' to 'rm' [nyae]?
> > rm: das Entfernen von „kernel-ml_archive_2014-1b.gz“ ist nicht möglich:
> > Datei oder Verzeichnis nicht gefunden
> > 
> > I didn´t type yes, as when I type "y", it is shown on command line:
> > 
> > ms@intraws:~/Backup/Mail/Linux#1> LANG=C mr test
> > zsh: correct 'mr' to 'rm' [nyae]? y
> > rm: cannot remove 'test': No such file or directory
> > 
> > And I really didn´t type "y" there, I am pretty sure of that, but I may
> > have hit another key by accident.
> 
> Indeed scary.
> 
> From the output it look to as if "Enter" had been pressed on a
> first glance. But if I press "Enter" (on Sid at least) it shows an "n"
> instead afterwards. (Since I have mr installed, I tested it with "rmm"
> which is only available if nmh or mailutils-mh is installed.)
> 
> After some experimenting I noticed that while pressing Enter is
> equivalent to pressing "n" and also prints an "n", pressing the space
> bar is equivalent to "y" _without_ printing a "y".
> 
> So you very likely hit the space bar accidentially.

Yikes! Space bar to confirm? And correction to "rm".

Actually what I tried to type was "mv". I obviously wanted to move the file. 
But I accidentelly typed "mr". And then, yes, likely the space bar.

I think this deserves a fix in the software :)

Thanks.

-

-- 
Martin Steigerwald  | Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: martin.steigerw...@teamix.de | web:  http://www.teamix.de | blog: 
http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller

teamix Support Hotline: +49 911 30999-112
 
 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

Bug#844710: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Martin Steigerwald]

Am Freitag, 18. November 2016, 13:00:24 CET schrieben Sie:
> Hi Martin,
> 
> Martin Steigerwald wrote:
> > ms@intraws:~/Backup/Mail/Linux> mr kernel-ml_archive.gz
> > kernel-ml_archive_2014-1b.gz zsh: correct 'mr' to 'rm' [nyae]?
> > rm: das Entfernen von „kernel-ml_archive_2014-1b.gz“ ist nicht möglich:
> > Datei oder Verzeichnis nicht gefunden
> > 
> > I didn´t type yes, as when I type "y", it is shown on command line:
> > 
> > ms@intraws:~/Backup/Mail/Linux#1> LANG=C mr test
> > zsh: correct 'mr' to 'rm' [nyae]? y
> > rm: cannot remove 'test': No such file or directory
> > 
> > And I really didn´t type "y" there, I am pretty sure of that, but I may
> > have hit another key by accident.
> 
> Indeed scary.
> 
> From the output it look to as if "Enter" had been pressed on a
> first glance. But if I press "Enter" (on Sid at least) it shows an "n"
> instead afterwards. (Since I have mr installed, I tested it with "rmm"
> which is only available if nmh or mailutils-mh is installed.)
> 
> After some experimenting I noticed that while pressing Enter is
> equivalent to pressing "n" and also prints an "n", pressing the space
> bar is equivalent to "y" _without_ printing a "y".
> 
> So you very likely hit the space bar accidentially.

Yikes! Space bar to confirm? And correction to "rm".

Actually what I tried to type was "mv". I obviously wanted to move the file. 
But I accidentelly typed "mr". And then, yes, likely the spacebar.

I think this deserves a fix in the software :)

Thanks.

-- 
Martin Steigerwald  | Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: martin.steigerw...@teamix.de | web:  http://www.teamix.de | blog: 
http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller

teamix Support Hotline: +49 911 30999-112
 
 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

Bug#844725: libproj12 should conflict with libproj9

[Gianfranco Costamagna]

Source: proj
Version 4.9.3-1
Severity: Serious
Justification: breaks unrelated software when both libraries are installed.

Hi, as said, it took me two days to debug to understand this failure
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/m/mipp/20161118_053933_5e50e@/log.gz

the python binding fails and segfaults when both libproj9 and libproj12 are 
installed

(Reading database ... 65663 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [05:39:15]: test python2: [---
=== python2.7 ===
test_tsx (test_xsar.Test) ... Segmentation fault (core dumped)
autopkgtest [05:39:23]: test python2: ---]
autopkgtest [05:39:23]: test python2:  - - - - - - - - - - results - - - - - - 
- - - -
python2  FAIL non-zero exit status 139
autopkgtest [05:39:23]:  summary
python2  FAIL non-zero exit status 139

a no-change rebuild of mipp with both runtime libraries installed triggers the 
failure.

Since you can't force people from autoremoving the old libraries, I think this 
is an RC bug, and some sort
of conflict with previous version should be added to prevent such segfaults 
from happening.

thanks for understanding,

Gianfranco

Bug#844724: apt: Does not seem to support new GnuPG keybox keyring format

[Guillem Jover]

Package: apt
Version: 1.3.1
Severity: important

[ Setting as important as this is GnuPG default, but if you think this
  is a new feature or similar please just change it to wishlist. ]

Hi!

It seems like apt (and its gpgv method) do not support the new GnuPG
keybox keyring format? Which is the one currently generated by default
with newer GnuPG versions. A simple session to demonstrate:

  ,--- (line-wrapped for easier readability) ---
  # cd /etc/apt/trusted.gpg.d
  # file debian-archive-jessie-automatic.gpg
  debian-archive-jessie-automatic.gpg: GPG key public ring,
  created Fri Nov 21 21:01:13 2014
  # mv debian-archive-jessie-automatic.gpg ~
  # gpg --no-default-keyring --no-options --no-auto-check-trustdb \
--keyring ./debian-archive-jessie-automatic.gpg --import \
<~/debian-archive-jessie-automatic.gpg
  gpg: keybox './debian-archive-jessie-automatic.gpg' created
  gpg: key 7638D0442B90D010: public key "Debian Archive Automatic Signing
   Key (8/jessie) " imported
  gpg: Total number processed: 1
  gpg:   imported: 1
  # file debian-archive-jessie-automatic.gpg
  debian-archive-jessie-automatic.gpg: GPG keybox database version 1,
  created-at Fri Nov 18 12:50:26 2016,
  last-maintained Fri Nov 18 12:50:26 2016
  # apt update
  Hit:1 https://cdn-aws.deb.debian.org/debian unstable InRelease
  Err:1 https://cdn-aws.deb.debian.org/debian unstable InRelease
The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  1 package can be upgraded. Run 'apt list --upgradable' to see it.
  W: An error occurred during the signature verification.
The repository is not updated and the previous index files will be used.
GPG error: https://cdn-aws.deb.debian.org/debian unstable InRelease:
The following signatures couldn't be verified because the public key
is not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010
  W: Failed to fetch https://deb.debian.org/debian/dists/unstable/InRelease
The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010
  W: Some index files failed to download. They have been ignored, or
old ones used instead.
  `---

Although I've trimmed it down here, it seems like one single keybox
formatted keyring makes the whole verification fail for all other
keyrings.

Thanks,
Guillem

Bug#844723: ITP: ruby-unicode-display-width -- Unicode character width library

[Michael Moll]

Package: wnpp
Severity: wishlist

I'm packaging this in pkg-ruby-extras

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Dimitri John Ledkov]

On 18 November 2016 at 11:56, Steve McIntyre  wrote:
> On Fri, Nov 18, 2016 at 11:44:25AM +, Dimitri John Ledkov wrote:
>>Package: wnpp
>>Owner: Dimitri John Ledkov 
>>Severity: wishlist
>>
>>* Package name: partman-swapfile
>>  Version : 1
>>  Upstream Author : d-i team
>>* URL or Web page : d-i
>>* License : GPL
>>  Description : add support for creating swapfiles
>>
>>I am working on minimising number of partitions used in the default
>>instalations in Ubuntu.
>
> Might I ask why?

Multiple reasons. Mostly surrounding supportability, and flexibility
for migrations / future changes.

There are a lot of people with dedicated /boot partitions, which are
full, preventing security kernel upgrades to succeed. At the same
time, people who are vulnerable to this, have no idea what a /boot
partition is, or how to run $ sudo apt autoremove to remove old
kernels. Booting off LVM, makes /boot part of the rootfs and hopefully
reduces chances of running out of all the disk space, because even
less sophisticated users tend to notice that.

As a side-effect this makes /boot an ext4 filesystem in more cases.
I'm thinking to move /boot to be ext4 by default in Ubuntu. Such that
it is the same regardless of the autopartitioning method.

Similarly with swap. One can dynamically resize/remove swapfile to add
swap or reclaim disk-space. And I am seeing a lot of systems that have
missized swaps. Having a 512GB swap, on a 1TB NVMe hard drive is
obscene when one has 256GB RAM. Other distributions (e.g. RHEL) have
started to limit swap well below the total amount of RAM. Note, in
Ubuntu, hibernation is disabled by default, therefore swap is only
used for the purpose of extreme memory pressure when things balloon
(e.g. during large process start-up before parts of it can be swapped
out).

Backup & restore / migration is simplified if a single partition
represents all of Ubuntu. This has been the case for a long time, on
e.g. cloud images. (UEFI & PReP partitions notwithstanding Har Har
Har)

Hence, it's just a general simplification, to make sure that default
installations are as sensible and as future proof as possible, and are
easier to modify if one realizes that one has miss-sized things.

Given that grub2 can unlock luks partitions, I wish it had some way to
pass the encryption secret to the kernel, such that /boot can be on
encrypted LVM as well, without needing to type the full disk
encryption passphrase twice on boot.

Note, that Debian supports a lot more architectures and a wider range
of machine configurations. I only have insight in a subset of these,
thus I am aware that above goals are potentially unachievable on the
more exotic machine types & bootloaders.

-- 
Regards,

Dimitri.

Bug#844339: [PATCH v2 2/4] libvirt-daemon-system.{config,templates,postinst}: warn if allocated uid/gid cannot be used

[Mauricio Faria de Oliveira]

On 11/18/2016 06:24 AM, Guido Günther wrote:

Exactly. That's why NEWS.Debian is nicer iff the user libvirt-qemu
exists but with "wrong" (legacy) uid/gid on existing installations and
Debconf is better for new installations where the uid/gid is already
taken.


Thanks for the debconf/NEWS.Debian clarifications; finally got it!
Totally agree w/ your point now. I'll spin the v3 w/ those changes.

cheers,

--
Mauricio Faria de Oliveira
IBM Linux Technology Center

Bug#844700: pbuilder: please support build profiles

[Samuel Thibault]

Hello,

James Clarke, on Fri 18 Nov 2016 10:56:28 +, wrote:
> but setting DEB_BUILD_PROFILES should work and be honoured by all the
> resolvers (except gdebi).

Oh, right, that can work already, indeed.

> --debbuildopts doesn't look inside its argument, hence why the
> resolvers don't know to use certain build profiles.

Sure :)

Samuel

Bug#826862: ipmitool fails with Segmentation fault

[Jörg Frings-Fürst]

Hello,

no answer since 11 weeks. So I close this bug.

If the bug still occurs please reopen[1] this bug or file a new one.

CU
Jörg

[1] https://www.debian.org/Bugs/server-control#reopen

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

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

[Petter Reinholdtsen]

[Lluís Vilanova]
> A possible check could be:
>
>   if [ `/sbin/sysctl kernel.perf_event_paranoid` -gt 2 ]; then
>   echo "ERROR: perf is too paranoid for us"
>   exit 1
>   fi
>
> This would build-depend on procps (which installs sysctl).

This seem like a good approach.  Perhaps explain in the message how to
get the build working too?

I found
http://unix.stackexchange.com/questions/14227/do-i-need-root-admin-permissions-to-run-userspace-perf-tool-perf-events-ar
 >
explaining the values 2 to -1 for perf_event_paraniod.

I'm using kernel 3.16 myself, and here the default value seem to be 1.

I guess coz should be patched too, to explain why it isn't working
instead of returning the fairly incomprehensive message it give today
when the perf call fail

-- 
Happy hacking
Petter Reinholdtsen

Bug#844722: qtwebkit: Please add platform support for m68k

[John Paul Adrian Glaubitz]

Source: qtwebkit
Version: 2.3.4.dfsg-9
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

qtwebkit used to build fine in the past but due to changes in the
upstream WebKit code no longer does. I have therefore created a
small patch which re-adds m68k support to qtwebkit.

This patch is based on the m68k support patch for qtwebkit-
opensource-src [1] and I have verified it to make qtwebkit
build fine on m68k with the patch applied.

It would be great to have both qtwebkit-opensource-src and
qtwebkit patched for m68k support as both packages still have
a lot of reverse dependencies and therefore prevent several
packages from being built on m68k.

I'm aware that qtwebkit* is going away in the future, but until
this has happened, it would be great to just have m68k support
in the package to help Debian's m68k port move forward.

Thanks,
Adrian

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

--
 .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Add support for m68k
Author: John Paul Adrian Glaubitz 

--- qtwebkit-2.3.4.dfsg.orig/Source/WTF/wtf/Platform.h
+++ qtwebkit-2.3.4.dfsg/Source/WTF/wtf/Platform.h
@@ -345,6 +345,12 @@
 #endif
 #endif
 
+/* CPU(M68K) - m68k */
+#if defined(__mc68000__)
+#define WTF_CPU_M68K 1
+#define WTF_CPU_BIG_ENDIAN 1
+#endif
+
 #if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC) || CPU(MIPS64)
 #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1
 #endif
--- qtwebkit-2.3.4.dfsg.orig/Source/WTF/wtf/dtoa/utils.h
+++ qtwebkit-2.3.4.dfsg/Source/WTF/wtf/dtoa/utils.h
@@ -58,6 +58,8 @@ defined(_MIPS_ARCH_MIPS32R2)
 #else
 #undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
 #endif  // _WIN32
+#elif defined(__mc68000__)
+#undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
 #else
 #error Target architecture was not detected as supported by Double-Conversion.
 #endif
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/css/CSSProperty.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/css/CSSProperty.cpp
@@ -39,7 +39,7 @@ struct SameSizeAsCSSProperty {
 void* value;
 };
 
-COMPILE_ASSERT(sizeof(CSSProperty) == sizeof(SameSizeAsCSSProperty), CSSProperty_should_stay_small);
+COMPILE_ASSERT(sizeof(CSSProperty) <= sizeof(SameSizeAsCSSProperty), CSSProperty_should_stay_small);
 
 void CSSProperty::wrapValueInCommaSeparatedList()
 {
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/dom/ShadowRoot.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/dom/ShadowRoot.cpp
@@ -60,7 +60,7 @@ struct SameSizeAsShadowRoot : public Doc
 unsigned countersAndFlags[1];
 };
 
-COMPILE_ASSERT(sizeof(ShadowRoot) == sizeof(SameSizeAsShadowRoot), shadowroot_should_stay_small);
+COMPILE_ASSERT(sizeof(ShadowRoot) <= sizeof(SameSizeAsShadowRoot), shadowroot_should_stay_small);
 
 ShadowRoot::ShadowRoot(Document* document)
 : DocumentFragment(document, CreateShadowRoot)
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/rendering/style/RenderStyle.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/rendering/style/RenderStyle.cpp
@@ -58,7 +58,7 @@ struct SameSizeAsBorderValue {
 unsigned m_width;
 };
 
-COMPILE_ASSERT(sizeof(BorderValue) == sizeof(SameSizeAsBorderValue), BorderValue_should_not_grow);
+COMPILE_ASSERT(sizeof(BorderValue) <= sizeof(SameSizeAsBorderValue), BorderValue_should_not_grow);
 
 struct SameSizeAsRenderStyle : public RefCounted {
 void* dataRefs[7];
@@ -75,7 +75,7 @@ struct SameSizeAsRenderStyle : public Re
 } noninherited_flags;
 };
 
-COMPILE_ASSERT(sizeof(RenderStyle) == sizeof(SameSizeAsRenderStyle), RenderStyle_should_stay_small);
+COMPILE_ASSERT(sizeof(RenderStyle) <= sizeof(SameSizeAsRenderStyle), RenderStyle_should_stay_small);
 
 inline RenderStyle* defaultStyle()
 {
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/rendering/style/StyleBoxData.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/rendering/style/StyleBoxData.cpp
@@ -33,7 +33,7 @@ struct SameSizeAsStyleBoxData : public R
 uint32_t bitfields;
 };
 
-COMPILE_ASSERT(sizeof(StyleBoxData) == sizeof(SameSizeAsStyleBoxData), StyleBoxData_should_not_grow);
+COMPILE_ASSERT(sizeof(StyleBoxData) <= sizeof(SameSizeAsStyleBoxData), StyleBoxData_should_not_grow);
 
 StyleBoxData::StyleBoxData()
 : m_minWidth(RenderStyle::initialMinSize())
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/rendering/style/StyleRareInheritedData.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/rendering/style/StyleRareInheritedData.cpp
@@ -61,7 +61,7 @@ struct SameSizeAsStyleRareInheritedData
 #endif
 };
 
-COMPILE_ASSERT(sizeof(StyleRareInheritedData) == sizeof(SameSizeAsStyleRareInheritedData), StyleRareInheritedData_should_bit_pack);
+COMPILE_ASSERT(sizeof(StyleRareInheritedData) <= sizeof(SameSizeAsStyleRareInheritedData), StyleRareInheritedData_should_bit_pack);
 
 StyleRareInheritedData::StyleRareInheritedData()
 : listStyleImage(RenderStyle::initialListStyleImage())

Bug#828352: ipmitool: FTBFS with openssl 1.1.0

[Jörg Frings-Fürst]

severity 828352 important
thanks

We switched our build dependnecy on libssl-dev to libssl1.0-dev so I'm 
downgrading this bug.

Of course I'm keeping this open because we need to switch to 1.1 as
soons as 
upstream allows us.

CU 
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#844721: libgtest-dev isn't replacing dir with symlink on upgrade

[David Kalnischkies]

Package: libgtest-dev
Version: 1.8.0-1
Severity: serious

Hi,

libgtest-dev contains in 1.8.0-1 a symlink to the new on-disk location.
That works for new installs, but doesn't on upgrades – a user ends up
with an empty /usr/src/gtest in that case.  You need to work with
maintainerscripts here, see "man dpkg-maintscript-helper" and especially
the section about dir_to_symlink for details on how and why.

The justification for 'serious' is a bit of a stretch (pun intended) as
the policy isn't explicitly saying that upgrades must produce a working
package… but I hope you and/or the release team implicitly agree. :)


In all likelyhood its the same with mock, but I am not using it…

You should also update your README.Debian and the descriptions with the
new paths and the transitional package as I guess you want to retire the
old package/path some day and the longer the grace period the better…

btw: Upstream seems to have retired their remark on compiling googletest
on your own as I can't find it any longer on their website and e.g. in
the RPM/BSD worlds you get a binary only.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#844720: Acknowledgement (Enable QR-Code support)

[Martin Pitt]

Hello again,

FTR, Ben's email address in the patch that I sent is wrong. The
current CC: should work better.

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

Bug#841592: [debian-mysql] Bug#841592: Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lucas Nussbaum]

Hi,

On 18/11/16 at 09:52 +0100, Lars Tangvald wrote:
> Could you try setting /proc/sys/fs/aio-max-nr in your build environment
> (64-core machine) to a high number like 40 (I'm guessing it's set to the
> default 65536), then building with my patch and see if that clears up
> everything?

Sorry, I don't have time to try this. Maybe you could post your build
log and diff it with mine to see if something comes up?

I'm suprised that you can't reproduce it.
(or maybe someone else reading that bug log can try? for me it fails
after 324 seconds, so it's easy to try)

Lucas

Bug#844720: Enable QR-Code support

[Martin Pitt]

Package: xfce4-clipman-plugin
Version: 2:1.4.0-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch zesty

Hello,

In https://launchpad.net/bugs/1641802 it was reported that Out of the
box xfce4-clipman-plugin doesn't include QR-Code support. Attached
patch from Ben adds that by building against libqrencode-dev.

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Nru xfce4-clipman-plugin-1.4.0/debian/changelog 
xfce4-clipman-plugin-1.4.0/debian/changelog
--- xfce4-clipman-plugin-1.4.0/debian/changelog 2016-09-15 16:19:53.0 
-0400
+++ xfce4-clipman-plugin-1.4.0/debian/changelog 2016-11-17 20:48:55.0 
-0500
@@ -1,3 +1,9 @@
+xfce4-clipman-plugin (2:1.4.0-2) UNRELEASED; urgency=medium
+
+  * Enable QR-Code support
+
+ -- Ben Swartzlander   Thu, 17 Nov 2016 20:48:34 -0500
+
 xfce4-clipman-plugin (2:1.4.0-1) unstable; urgency=medium
 
   [ Mateusz Łukasik ]
diff -Nru xfce4-clipman-plugin-1.4.0/debian/control 
xfce4-clipman-plugin-1.4.0/debian/control
--- xfce4-clipman-plugin-1.4.0/debian/control   2016-09-15 16:03:36.0 
-0400
+++ xfce4-clipman-plugin-1.4.0/debian/control   2016-11-17 14:50:29.0 
-0500
@@ -9,7 +9,7 @@
  libxfce4panel-2.0-dev, libxml2-dev, libxml-parser-perl, intltool,
  libx11-dev, pkg-config, libgtk-3-dev, libexo-1-dev, libxfce4util-dev,
  libxfconf-0-dev, libglade2-dev, libunique-dev, libxfce4ui-2-dev,
- libxtst-dev
+ libxtst-dev, libqrencode-dev
 Standards-Version: 3.9.8
 Homepage: http://goodies.xfce.org/
 Vcs-Svn: svn://anonscm.debian.org/pkg-xfce/goodies/trunk/xfce4-clipman-plugin/

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Dimitri John Ledkov]

On 18 November 2016 at 12:02, Philipp Kern  wrote:
> On 18.11.2016 12:44, Dimitri John Ledkov wrote:
>> Another thing I am investigating is moving away from swap partitions to
>> swap files, on non-lvm installations. This will involve tweaking the
>> default partman-auto recipes & the no-swap warning.
>
> Note that you should then also check that the memory available to the
> installer is sufficient to proceed without swap. (Especially for locales
> generation and such.)
>

Right so the no-swap warning comes after partitioning scheme is
finalised, but before swapfile is created and activated.

I still want to default to having some swap. But have that provided
via swap partition, or a swapfile. So far my scripts are a bit hackish
as the swapfile does not form part of the parted aware things /
something one cas specify in partman-auto recipes. It really is tucked
on the side, in finish.d, at the moment.

I have no solution yet for e.g. partman-auto automic recipe which uses
swapfile, if the rootfs filesystem is ext4; but creates a swap
partition if the rootfs filesystem is btrfs. And i'm not quite sure
how to express that in the recipe, or decode it.

-- 
Regards,

Dimitri.