Bug#812344: simple-scan: segfault using Canon Lite 100 with simple-scan

[Jörg Frings-Fürst]

severity 812344 normal
tags 812344 - upstream + moreinfo
thanks


Hello Piccoro,

thank you for spending your time helping to make Debian better with
this bug report. 

Some questions:

- Is the bug reproducible?
- Do you have run memtest? With what result?
- Why have you recomplie sane-backends? In what environment 
  and with which changes?

And please test sane-backends from stretch and from experimental.


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-54538 Bausendorf

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#812392: Depends: libperl5.20 (>= 5.20.1) which is a virtual package and is not provided by any available package.

[Kiko Piris]

Package: nagios3-core
Version: 3.5.1.dfsg-2+b1
Severity: normal

Hi,

Since Perl 5.22 transition on SID, nagios3 is not installable due to 
nagios3-core dependency on libperl5.20

Thanks!

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

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

Versions of packages nagios3-core depends on:
ii  libc6   2.21-6
ii  libperl5.20 5.20.2-6
ii  nagios3-common  3.5.1.dfsg-2
ii  perl5.20.2-6

nagios3-core recommends no packages.

Versions of packages nagios3-core suggests:
pn  nagios-nrpe-plugin  

-- no debconf information

Bug#812391: ldc: Please update with upstream

[Денис Феклушкин]

Package: ldc
Version: 1:0.15.1-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

Please update with upstream sources, LDC 0.16.1 release is available



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

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

Versions of packages ldc depends on:
ii  libc6   2.19-18+deb8u1
ii  libconfig9  1.4.9-2
ii  libedit23.1-20150325-1+b1
ii  libffi6 3.1-2+b2
ii  libgcc1 1:5.3.1-6
ii  libphobos2-ldc-dev  1:0.15.1-1
ii  libstdc++6  5.3.1-6
ii  libtinfo5   6.0+20151024-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages ldc recommends:
pn  libphobos2-ldc-debug  

ldc suggests no packages.

-- Configuration Files:
/etc/ldc.conf 097d3f0355a48faae96f09ab55858889 [Errno 2] Нет такого файла
или каталога: u'/etc/ldc.conf 097d3f0355a48faae96f09ab55858889'
/etc/ldc.rebuild.conf 3ca747cf56e03dfcb997e407209a680c [Errno 2] Нет такого
файла или каталога: u'/etc/ldc.rebuild.conf
3ca747cf56e03dfcb997e407209a680c'

-- debconf-show failed

Bug#812390: uim-qt5: startkde hangs with uim-qt5 and uim-mozc installed

[YOSHINO Yoshihito]

Package: uim-qt5
Version: 1:1.8.6-15exp1
Severity: important
Tags: experimental

Dear Maintainer,

After installing uim-qt5 ksplashqml does not finish and KDE does not start.

$ pstree -apl `pidof sddm`
sddm,3481
  ├─Xorg,3781 -nolisten tcp -auth
/var/run/sddm/{b85093b4-e92b-44bf-84f6-faae000c370d} -background none
-noreset -displayfd 17 vt7
  │   └─{Xorg},3813
  └─sddm-helper,3981 --socket
/tmp/sddm-auth2a55ecc6-426f-4a6f-a2ec-7bda0ceb53c2 --id 1 --start
/usr/bin/startkde --user owner
  └─ck-launch-sessi,3982 /usr/bin/dbus-launch --exit-with-session
/usr/bin/im-launch /usr/bin/startkde
  ├─ssh-agent,4054 /usr/bin/ck-launch-session
/usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch
/usr/bin/startkde
  └─startkde,4130 /usr/bin/startkde
  ├─(ksplashqml,4180)
  ├─uim-toolbar,4157
  └─uim-xim,4156

It looks like libuimplatforminputcontextplugin.so launches mozc_server
in uim-mozc and does not finish.

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

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

Versions of packages uim-qt5 depends on:
ii  libc62.21-6
ii  libgcc1  1:5.3.1-7
ii  libgl1-mesa-glx [libgl1] 11.1.1-2
ii  libqt5core5a [qtbase-abi-5-5-1]  5.5.1+dfsg-13
ii  libqt5gui5   5.5.1+dfsg-13
ii  libqt5widgets5   5.5.1+dfsg-13
ii  libqt5x11extras5 5.5.1-3
ii  libstdc++6   5.3.1-7
ii  libuim-custom2   1:1.8.6-15exp1
ii  libuim-data  1:1.8.6-15exp1
ii  libuim-scm0  1:1.8.6-15exp1
ii  libuim8  1:1.8.6-15exp1
ii  libx11-6 2:1.6.3-1
ii  uim-common   1:1.8.6-15exp1
ii  uim-utils1:1.8.6-15exp1

uim-qt5 recommends no packages.

uim-qt5 suggests no packages.

-- no debconf information

Bug#812389: nmu: gst-plugins-good1.0_1.7.1-1

[Andreas Beckmann]

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

nmu gst-plugins-good1.0_1.7.1-1 . ANY . experimental . -m "Rebuild against 
libvpx3."

There was recently a libvpx2 -> libvpx3 transition in sid.


Andreas

Bug#810947: kwin-x11: iceweasel locks up when multiple windows restored

[Arthur Marsh]

Package: kwin-x11
Followup-For: Bug #810947

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

After experiences problems as late as yesterday 23 January and applying some
upgrades today, both my usual session and a test account were able to launch
iceweasel with multiple windows (16) being restored without any lock-up of
kwin_x11.

I'll keep checking to see if they problem stays away.

   * 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 unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kwin-x11 depends on:
ii  kwin-common  4:5.4.3-1.1
ii  libc62.21-6
ii  libkf5i18n5  5.16.0-1
ii  libkf5windowsystem5  5.16.0-1
ii  libqt5core5a 5.5.1+dfsg-13
ii  libqt5gui5   5.5.1+dfsg-13
ii  libqt5widgets5   5.5.1+dfsg-13
ii  libqt5x11extras5 5.5.1-3
ii  libstdc++6   5.3.1-7
ii  libxcb1  1.11.1-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- debconf-show failed

Bug#812208: ITP: python-urwidtrees -- urwid tree container API

[陳昌倬]

On Fri, Jan 22, 2016 at 01:09:25PM +0100, Piotr Ożarowski wrote:
> [ChangZhuo Chen, 2016-01-21]
> > * Package name: python-urwidtrees
> >   Version : 1.0
> >   Upstream Author : Patrick Totzke
> > * URL : http://www.example.org/
> 
> I cannot find urwidtrees on that page ;P

My bad. It shall be https://github.com/pazz/urwidtrees.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D


signature.asc
Description: PGP signature

Bug#812215: consider spliting systemd-tmpfiles into separate package

[Josh Triplett]

On Thu, 21 Jan 2016 17:54:21 +0100 Michael Biebl  wrote:
> Hi Ondřej
> 
> Am 21.01.2016 um 17:28 schrieb Ondřej Surý:
> 
> > please consider spliting systemd-tmpfiles into separate package,
> > perhaps with sysvrc script provided.
> > 
> > The tmpfiles mechanism is quite great and if we can use tmpfiles
> > mechanism in the sysvrc scripts, we could remove a lot of custom shell
> > scripts that do just the same - create a temporary directory in /run
> > (and elsewhere).
> > 
> > Personally I have a shell snippet that can understand most basic stuff
> > in /usr/lib/tmpfiles.d/.conf, but there's a lots of
> > duplication since /run started being tmpfs that gets deleted on every
> > machine reboot.
> > 
> > Also since this utility probably doesn't need anything from the
> > kernel, it might be compilable on non-Linux archs :) (worth trying).
> > 
> 
> We already considered this a while ago. It's not easily possible.
> systemd-tmpfiles links against the internal libshared which basically
> means building half of systemd. This is unlikely to succeed on
> non-linux. Last time I tried it, I've given up on it without success.
> 
> A systemd-tmpfiles compatible implementation outside of the systemd
> sources looks to me like a more maintainable solution. And once we have
> that, splitting out systemd-tmpfiles only on Linux doesn't make sense
> anymore, I guess.
> 
> I agree though, and I think the rest of the team as well, that having
> the systemd-tmpfiles mechanism on non-systemd would be worthwile.

I'd agree that systemd-tmpfiles won't build outside of systemd or on
non-Linux; beyond the systemd libraries, it would need portability
changes around things like selinux, devices, ACLs, and xattrs, and
couldn't support subvolumes at all.

However, since installing the "systemd" package doesn't change the init
system, and systemd-tmpfiles should run without systemd as init, I do
think it might make sense to add a new source and package "tmpfiles",
that Depends on "systemd [linux-any]" (but not on systemd-sysv) and
ships a sysvinit script to run systemd-tmpfiles on sysvinit.  The
tmpfiles package should ship a corresponding .service symlink linked to
/dev/null, since systemd already runs systemd-tmpfiles.  Then, packages
could depend on "tmpfiles" and count on tmpfiles.d support across
multiple init systems, to avoid the need for duplicate logic in their
sysvinit scripts.  (I'd suggest depending on "tmpfiles | systemd-sysv",
except that you can have systemd-sysv installed but boot with sysvinit
as init, and avoiding the installation of one unused script and one
symlink doesn't seem worth breaking that case.)

That same "tmpfiles" package could also potentially provide a subset of
the functionality of systemd-tmpfiles on non-Linux platforms, and
software that supported non-Linux kernels could restrict itself to that
subset and depend on the tmpfiles package.

This would need some coordination among init systems and projects
shipping tmpfiles.d snippets, since some packages (notably systemd
itself) may not expect their tmpfiles.d snippets to run under
non-systemd.  Several existing sysvinit scripts could make use of this;
for instance, right now the rcS script bootmisc.sh creates nologin, but
/usr/lib/tmpfiles.d/systemd-nologin.conf seems like a much simpler way
to do that.

If having tmpfiles.d support across all architectures and init systems
sounds appealing, I'd be willing to construct such a package, though I'd
want to have co-maintainers who actually run sysvinit and/or non-Linux
architectures.  The subset of tmpfiles.d syntax that can easily work on
all POSIX systems seems simple enough to write.

- Josh Triplett

Bug#812388: Debian man page is out of sync with 'mitmproxy --help' documentation

[Carlos Maddela]

Package: mitmproxy
Version: 0.13-1
Severity: normal

In particular, the documentation for -F must be changed to -U.

Cheers

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

Kernel: Linux 4.3.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 mitmproxy depends on:
ii  python 2.7.11-1
ii  python-blinker 1.3.dfsg2-1
ii  python-configargparse  0.10.0-1
ii  python-html2text   2016.1.8-1
ii  python-lxml3.5.0-1
ii  python-netlib  0.13.1-1
ii  python-pil 3.0.0-1
ii  python-pyasn1  0.1.9-1
ii  python-pyparsing   2.0.3+dfsg1-1
ii  python-tornado 4.2.1-1+b1
ii  python-urwid   1.3.1-2
pn  python:any 

Versions of packages mitmproxy recommends:
ii  python-pyperclip  1.5.11-1

mitmproxy suggests no packages.

-- no debconf information

Bug#812387: libunity: FTBFS: error: `ListStore' is an ambiguous reference between `GLib.ListStore' and `Gtk.ListStore'

[Andreas Beckmann]

Package: libunity
Version: 6.12.0-1~experimental1
Severity: serious
Justification: fails to build from source

libunity FTBFS in sid and experimental with

make[3]: Entering directory '/build/libunity-6.12.0/tools'
/usr/bin/glib-compile-resources --sourcedir . --target=unity-tool-res.c 
--generate-source unity-tool-res.gresource.xml
/usr/bin/valac -C --vapidir ../vapi --vapidir=../protocol --vapidir=../src 
--pkg config --pkg gtk+-3.0 --pkg gmodule-2.0 --pkg unity-internal --pkg 
unity-protocol --pkg glib-2.0 --pkg gobject-2.0 --pkg gio-2.0 --pk
g gio-unix-2.0 --pkg gee-0.8 --pkg dee-1.0 --pkg Dbusmenu-0.4  unity-tool.vala 
unity-tool-dbus-util.vala unity-tool-ui.vala preview-renderer.vala 
music-track-model-renderer.vala
unity-tool-ui.vala:782.13-782.21: error: `ListStore' is an ambiguous reference 
between `GLib.ListStore' and `Gtk.ListStore'
private ListStore uimodel = null;
^
unity-tool-ui.vala:783.13-783.21: error: `ListStore' is an ambiguous reference 
between `GLib.ListStore' and `Gtk.ListStore'
private ListStore ui_filter_model = null;
^
unity-tool-ui.vala:784.13-784.21: error: `ListStore' is an ambiguous reference 
between `GLib.ListStore' and `Gtk.ListStore'
private ListStore lens_list_model = null;
^
unity-tool-ui.vala:43.62-43.70: error: `ListStore' is an ambiguous reference 
between `GLib.ListStore' and `Gtk.ListStore'
uimodel = builder.get_object("results_model") as ListStore;
 ^
unity-tool-ui.vala:44.70-44.78: error: `ListStore' is an ambiguous reference 
between `GLib.ListStore' and `Gtk.ListStore'
ui_filter_model = builder.get_object("filters_model") as ListStore;
 ^
unity-tool-ui.vala:157.72-157.80: error: `ListStore' is an ambiguous reference 
between `GLib.ListStore' and `Gtk.ListStore'
lens_list_model = builder.get_object("lens_list_model") as 
ListStore;
   ^
music-track-model-renderer.vala:31.12-31.20: error: `ListStore' is an ambiguous 
reference between `GLib.ListStore' and `Gtk.ListStore'
public ListStore track_view_model { get; construct; }
   ^
music-track-model-renderer.vala:31.12-31.20: error: `ListStore' is an ambiguous 
reference between `GLib.ListStore' and `Gtk.ListStore'
public ListStore track_view_model { get; construct; }
   ^
music-track-model-renderer.vala:31.12-31.20: error: `ListStore' is an ambiguous 
reference between `GLib.ListStore' and `Gtk.ListStore'
public ListStore track_view_model { get; construct; }
   ^
music-track-model-renderer.vala:31.12-31.20: error: `ListStore' is an ambiguous 
reference between `GLib.ListStore' and `Gtk.ListStore'
public ListStore track_view_model { get; construct; }
   ^
Compilation failed: 10 error(s), 0 warning(s)
Makefile:791: recipe for target 'unity_tool_vala.stamp' failed
make[3]: *** [unity_tool_vala.stamp] Error 1
make[3]: Leaving directory '/build/libunity-6.12.0/tools'


Andreas

Bug#812386: Please enable ARCH_QCOM on arm64

[Martin Michlmayr]

Package: linux
Version: 4.4-1~exp1
Severity: wishlist

Please enable ARCH_QCOM on arm64.  I believe the following options
should be enabled:

CONFIG_ARCH_QCOM=y

CONFIG_STMMAC_ETH=m
CONFIG_STMMAC_PLATFORM=m
CONFIG_DWMAC_GENERIC=m
CONFIG_DWMAC_IPQ806X=m

CONFIG_SERIAL_MSM=y
CONFIG_SERIAL_MSM_CONSOLE=y

CONFIG_HW_RANDOM_MSM=m

CONFIG_I2C_QUP=m
CONFIG_SPI_QUP=m

CONFIG_PINCTRL=y

CONFIG_POWER_RESET_MSM=y

CONFIG_QCOM_WDT=m

CONFIG_DRM=m
CONFIG_DRM_MSM=m
CONFIG_DRM_MSM_DSI=y
CONFIG_DRM_MSM_DSI_PLL=y
CONFIG_DRM_MSM_DSI_28NM_PHY=y
CONFIG_DRM_MSM_DSI_20NM_PHY=y

CONFIG_SND_SOC=m
CONFIG_SND_SOC_QCOM=m

CONFIG_USB_PHY=y
CONFIG_USB_MSM_OTG=m
CONFIG_USB_QCOM_8X16_PHY=m
CONFIG_USB_GADGET=m

CONFIG_MMC_QCOM_DML=m

CONFIG_DMADEVICES=y
CONFIG_QCOM_BAM_DMA=m

CONFIG_HWSPINLOCK=m
CONFIG_HWSPINLOCK_QCOM=m

CONFIG_QCOM_GSBI=m
CONFIG_QCOM_SMEM=m
CONFIG_QCOM_SMD=m
CONFIG_QCOM_SMD_RPM=m

CONFIG_EXTCON=m

CONFIG_RESET_CONTROLLER=y

CONFIG_PHY_QCOM_APQ8064_SATA=m
CONFIG_PHY_QCOM_IPQ806X_SATA=m

CONFIG_CRYPTO_DEV_QCE=m

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#812280: newmat: FTBFS with GCC 6: terminate called

[Robert Davies]

I suspect I don't know enough to load g++-6 and possibly it is too 
risky. In any

case it doesn't want to load and there seem to be dependencies that can't
be found.

The section in tmt in newmat that is throwing the exception is 
testing exceptions. These

are thrown and caught and the program checks that the correct one is caught.

I suspect g++-6 is not tracking exceptions correctly but it is possible the
standards committee has changed the rules.

I suggest you check it again in a few weeks and if there is still a 
problem you'll

have to tell me how to load g++6.


At 04:54 PM 22-01-16, Martin Michlmayr wrote:

Package: newmat
Version: 1.10.4-5
Severity: normal
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-6 gcc-6-unknown

This package fails to build with GCC 6.  GCC 6 has not been released
yet, but it's expected that GCC 6 will become the default compiler for
stretch.

Unfortunately, it's not clear from the log why the build failed.
It's possible there's a bug in this package or in GCC.  It's also
possible I reported a non-issue, although I tried to avoid that.
I apologize in advance if this is the case.

If you have some time to look into this issue, that'd be great.  If
not, I can re-test the package with GCC 6 in a few weeks time.

You can find a snapshot of GCC 6 in experimental.  To build with
GCC 6, you can set CC=gcc-6 CXX=g++-6 explicitly.

You may be able to find out more about this issue at
https://gcc.gnu.org/gcc-6/changes.html

> sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
...
> All elements are zero
> terminate called after throwing an instance of 'NEWMAT::ProgramException'
>
>   * Eighteenth test of Matrix package
>   * Matrix test program
> debian/rules:45: recipe for target 'build-stamp' failed
> make: *** [build-stamp] Aborted
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 



--
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#767682: D-I: installer hangs on re-formatting ext4 partition (having grub in the partition boot record).

[John Paul Adrian Glaubitz]

Hello!

> Following is a workaround for this problem in preseed environment that
> worked for me:
>
> d-i partman/early_command string sed -r -e '/^[[:space:]]*mkfs\.
> /s/^([[:space:]]*)(mkfs\.[^[:space:]]+)/\1\2 -F/g' -i /lib/partman
> /commit.d/50format_ext3

Which basically adds the force flag to mkfs.ext3 so it will try to
create the filesystem " even if the specified device is not a partition
on a block special device, or if other parameters do not make sense."
(manpage mkfs.ext3).

Is there a particular reason why we use "-f" in partman-btrfs [1] for
mkfs but not in partman-ext3 for mkfs? It seems that running mkfs.ext3
with -F would make the formatting process more robust for most people
when reading through this bug report. We're also seeing this issue on
sparc64 where mkfs.ext3 is probably choking on the Sun disklabels.

I'd therefore suggest to add -F to mkfs.ext3 in partman-ext3.

Thanks,
Adrian

> [1]
http://anonscm.debian.org/cgit/d-i/partman-btrfs.git/tree/commit.d/format_btrfs#n62

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

Bug#812385: Please enable arm64

[Martin Michlmayr]

FWIW, I successfully compiled the package after adding arm64 to
debian/control (twice).

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#812385: Please enable arm64

[Martin Michlmayr]

Package: xserver-xorg-video-freedreno
Version: 1.3.0-1
Severity: wishlist

Please enable this package on arm64.  The Snapdragon 400 is a CPU that
can do 64 bit and it includes an Adreno 306 GPU.

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#812384: xserver-xorg-video-freedreno: new upstream release

[Martin Michlmayr]

Package: xserver-xorg-video-freedreno
Severity: wishlist

Version 1.4.0 is available from
ftp://mirror.csclub.uwaterloo.ca/x.org/individual/driver/

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#810186: kodi: diff for NMU version 15.2+dfsg1-1.1

[Jonas Smedegaard]

Quoting Balint Reczey (2016-01-22 22:29:30)
> On Fri, 22 Jan 2016 10:21:59 + (UTC) Gianfranco Costamagna
>  wrote:
> ...
>> - libpng12-dev | libpng-dev,
>> + libpng-dev | libpng12-dev,
> I have already prepared the fix in git and I'm waiting for libpng-dev 
> to become a non-virtual package.
>
> From Debian Policy 7.5 Virtual packages - Provides:
>  To specify which of a set of real packages should be the default to 
>  satisfy a particular dependency on a virtual package, list the real 
>  package as an alternative before the virtual one.

That section of policy talks about _dependencies_ whereas the change 
done above is a _build-dependency_.

It is a common pattern in Debian to provide a virtual library 
development package.  Purpose of the section above is to ensure 
deterministic install (non-random install) but that is ensured by the 
maintainer of the library package only having a single package available 
in any suite at a time providing the virtual package.


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#659375: Diff-Menu says line mode

[Manoj Srivastava]

severity 659375 minor
tags 659375 + moreinfo
thanks

Hi,

When displaying the versions side by side, each difference is
 still displayed line by line --  lines with no changes are not
 duplicated. Is the title of the diff  (Unterschiede zwischen den
 Versionen zeilenweise anzeigen) really so confusing?

The idea is to show the differences between the files, one line
 at a time, and the format, lines one above the other or side by side is
 just a visual presentation feature.

manoj
-- 
Quidquid latine dictum sit, altum viditur. [Whatever is said in Latin
sounds profound.]
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature

Bug#812383: fluxbox reports many "Failed to read" errors during startup

[Kynn Jones]

Package: fluxbox
Version: 1.3.7-1~exp1
Severity: normal

Dear Maintainer,

fluxbox reports the following errors at startup:

xmodmap:  unable to open file '/home/jones/.Xmodmap' for reading
xmodmap:  1 error encountered, aborting.
Failed to read: session.ignoreBorder
Setting default value
Failed to read: session.forcePseudoTransparency
Setting default value
Failed to read: session.colorsPerChannel
Setting default value
Failed to read: session.doubleClickInterval
Setting default value
Failed to read: session.tabPadding
Setting default value
Failed to read: session.styleOverlay
Setting default value
Failed to read: session.slitlistFile
Setting default value
Failed to read: session.appsFile
Setting default value
Failed to read: session.tabsAttachArea
Setting default value
Failed to read: session.cacheLife
Setting default value
Failed to read: session.cacheMax
Setting default value
Failed to read: session.autoRaiseDelay
Setting default value
Failed to read: session.ignoreBorder
Setting default value
Failed to read: session.forcePseudoTransparency
Setting default value
Failed to read: session.colorsPerChannel
Setting default value
Failed to read: session.doubleClickInterval
Setting default value
Failed to read: session.tabPadding
Setting default value
Failed to read: session.styleOverlay
Setting default value
Failed to read: session.slitlistFile
Setting default value
Failed to read: session.appsFile
Setting default value
Failed to read: session.tabsAttachArea
Setting default value
Failed to read: session.cacheLife
Setting default value
Failed to read: session.cacheMax
Setting default value
Failed to read: session.autoRaiseDelay
Setting default value
Failed to read: session.screen0.opaqueMove
Setting default value
Failed to read: session.screen0.fullMaximization
Setting default value
Failed to read: session.screen0.maxIgnoreIncrement
Setting default value
Failed to read: session.screen0.maxDisableMove
Setting default value
Failed to read: session.screen0.maxDisableResize
Setting default value
Failed to read: session.screen0.workspacewarping
Setting default value
Failed to read: session.screen0.showwindowposition
Setting default value
Failed to read: session.screen0.autoRaise
Setting default value
Failed to read: session.screen0.clickRaises
Setting default value
Failed to read: session.screen0.defaultDeco
Setting default value
Failed to read: session.screen0.tab.placement
Setting default value
Failed to read: session.screen0.windowMenu
Setting default value
Failed to read: session.screen0.noFocusWhileTypingDelay
Setting default value
Failed to read: session.screen0.workspaces
Setting default value
Failed to read: session.screen0.edgeSnapThreshold
Setting default value
Failed to read: session.screen0.window.focus.alpha
Setting default value
Failed to read: session.screen0.window.unfocus.alpha
Setting default value
Failed to read: session.screen0.menu.alpha
Setting default value
Failed to read: session.screen0.menuDelay
Setting default value
Failed to read: session.screen0.tab.width
Setting default value
Failed to read: session.screen0.tooltipDelay
Setting default value
Failed to read: session.screen0.allowRemoteActions
Setting default value
Failed to read: session.screen0.clientMenu.usePixmap
Setting default value
Failed to read: session.screen0.tabs.usePixmap
Setting default value
Failed to read: session.screen0.tabs.maxOver
Setting default value
Failed to read: session.screen0.tabs.intitlebar
Setting default value
Failed to read: session.screen0.focusModel
Setting default value
Failed to read: session.screen0.tabFocusModel
Setting default value
Failed to read: session.screen0.focusNewWindows
Setting default value
Failed to read: session.screen0.focusSameHead
Setting default value
Failed to read: session.screen0.rowPlacementDirection
Setting default value
Failed to read: session.screen0.colPlacementDirection
Setting default value
Failed to read: session.screen0.windowPlacement
Setting default value
Failed to read: session.ignoreBorder
Setting default value
Failed to read: session.forcePseudoTransparency
Setting default value
Failed to read: session.colorsPerChannel
Setting default value
Failed to read: session.doubleClickInterval
Setting default value
Failed to read: session.tabPadding
Setting default value
Failed to read: session.styleOverlay
Setting default value
Failed to read: session.slitlistFile
Setting default value
Failed to read: session.appsFile
Setting default value
Failed to read

Bug#808277: Fails with filenames which contain spaces

[Manoj Srivastava]

severity 808277 wishlist
thanks

On Fri, Dec 18 2015, Gaudenz Steinlin wrote:

> Package: ucf
> Version: 3.0031
> Severity: normal
>
> UCF fails for files which contain spaces. See the test case below. It
> also fails if only the source  or destination file contain spaces.

Yes. This is too hard to fix, since I haven’t found a way o get
 the underlying shell to not crap out on

 if [ ! -e "$new_file" ]; then
   echo >&2 "$new_file does not exist"
 fi
 if $new_file contains spaces.

Patches happily accepted.

manoj
-- 
He that breaks a thing to find out what it is has left the path of
wisdom. J.R.R. Tolkien
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature

Bug#662522: torcs: diff for NMU version 1.3.3+dfsg-0.2

[Rudy Godoy]

Hi Gianfranco,

On Thu, Jan 21, 2016 at 03:20:07PM +, Gianfranco Costamagna wrote:
> 
> I've prepared an NMU for torcs (versioned as 1.3.3+dfsg-0.2) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
> 

Thanks for your contribution. I'm currently working on 1.3.6 update.

-- 
Rudy Godoy
http://rudygodoy.com

Bug#812382: nikola: ‘image_date’ crashes with “TypeError: must be string, not tuple”

[Ben Finney]

Package: nikola
Version: 7.6.4-1
Severity: normal

When I create a demo site and attempt to build the result, Nikola crashes:

=
$ nikola init --demo --quiet demo/
[2016-01-23T01:39:25Z] INFO: init: A new site with example data has been 
created at demo/.
[2016-01-23T01:39:25Z] INFO: init: See README.txt in that folder for more 
information.

$ (cd demo/ && nikola build)
Scanning postsdone!
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/doit/doit_cmd.py", line 165, in run
return command.parse_execute(args)
  File "/usr/lib/python2.7/dist-packages/doit/cmd_base.py", line 122, in 
parse_execute
return self.execute(params, args)
  File "/usr/lib/python2.7/dist-packages/doit/cmd_base.py", line 380, in execute
self, params, args)
  File "/usr/lib/python2.7/dist-packages/nikola/__main__.py", line 282, in 
load_tasks
self.nikola.gen_tasks('render_site', "Task", 'Group of tasks to render the 
site.'))
  File "/usr/lib/python2.7/dist-packages/doit/loader.py", line 296, in 
generate_tasks
for task_dict, x_doc in flat_generator(gen_result, gen_doc):
  File "/usr/lib/python2.7/dist-packages/doit/loader.py", line 28, in 
flat_generator
for item in gen:
  File "/usr/lib/python2.7/dist-packages/nikola/nikola.py", line 1435, in 
gen_tasks
for task in flatten(pluginInfo.plugin_object.gen_tasks()):
  File "/usr/lib/python2.7/dist-packages/nikola/nikola.py", line 1429, in 
flatten
for t in task:
  File "/usr/lib/python2.7/dist-packages/nikola/plugins/task/galleries.py", 
line 176, in gen_tasks
image_list.sort(key=lambda a: self.image_date(a))
  File "/usr/lib/python2.7/dist-packages/nikola/plugins/task/galleries.py", 
line 176, in 
image_list.sort(key=lambda a: self.image_date(a))
  File "/usr/lib/python2.7/dist-packages/nikola/image_processing.py", line 107, 
in image_date
value, r'%Y:%m:%d %H:%M:%S')
TypeError: must be string, not tuple
=

The demo site should just work on a standard Debian installation of
Nikola.


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

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

Versions of packages nikola depends on:
ii  libjs-bootstrap  3.3.6+dfsg-1
ii  libjs-imagesloaded   3.1.8-1
ii  libjs-jquery 1.11.3+dfsg-4
ii  libjs-jquery-colorbox1.6.3-1
ii  libjs-twitter-bootstrap  2.0.2+dfsg-9
ii  python   2.7.11-1
ii  python-blinker   1.3.dfsg2-1
ii  python-dateutil  2.4.2-1
ii  python-docutils  0.12+dfsg-1
ii  python-doit  0.28.0-1
ii  python-imaging   3.0.0-1
ii  python-logbook   0.12.3-1
ii  python-lxml  3.5.0-1
ii  python-mako  1.0.3+ds1-1
ii  python-natsort   4.0.3-2
ii  python-pkg-resources 18.8-1
ii  python-pygments  2.0.1+dfsg-2
ii  python-pyrss2gen 1.1-1
ii  python-requests  2.9.1-1
ii  python-unidecode 0.04.18-2
ii  python-yapsy 1.11.223-1
pn  python:any   

Versions of packages nikola recommends:
ii  python-livereload  2.4.0-1
ii  python-typogrify   1:2.0.7-1
ii  python-watchdog0.8.3-2
ii  python-webassets   3:0.11.1-1
ii  python-ws4py   0.3.4-2

Versions of packages nikola suggests:
ii  bpython  0.12-1.2
ii  ipython  2.4.1-1
ii  node-less1.6.3~dfsg-2
ii  pandoc   1.15.1.1~dfsg-2+b1
ii  python-creoleparser  0.7.4-1
ii  python-feedparser5.1.3-3
ii  python-jinja22.8-1
ii  python-markdown  2.6.5-1
pn  python-misaka
pn  python-pygal 
ii  python-textile   1:2.2.2-1
pn  txt2tags 

-- no debconf information

-- 
 \ “Try adding “as long as you don't breach the terms of service – |
  `\  according to our sole judgement” to the end of any cloud |
_o__)  computing pitch.” —Simon Phipps, 2010-12-11 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#784523: Bumping severities

[Kartik Mistry]

On Jan 23, 2016 12:27 AM, "Lisandro Damián Nicanor Pérez" <
perezme...@gmail.com> wrote:
> My bad at not being verbose enough, I was referring to Kartik indeed :)

Thanks for patch!

If I can't upload by Monday night, feel free to NMU :)

--
Kartik Mistry | IRC: kart_
kartikm.wordpress.com

Bug#803249: needrestart: Restarts services in debconf noninteractive

[Stephen Dowdy]

Thomas,

Summary:
- using an auxiliary conf.d file seems to mostly work
- 'needrestart' should, however flag 'systemctl restart' notice with
'skipping' in this case?
- 'needrestart' should not prompt to read  on 'consider
rebooting kernel' notification in this case


(hostname)# cat /etc/needrestart/conf.d/debian_frontend_noninteractive.conf
# Switch to list mode if debconf is running noninteractive
# Ref: Bug#803249: needrestart: Restarts services in debconf noninteractive
# Thomas Liske 

$nrconf{restart} = ( ($ENV{DEBIAN_FRONTEND} // '') eq 'noninteractive' ?
'l' : 'i');

1;
(changed it a tiny bit)

I ran an update on a system that hasn't been updated for quite some time,
with :

   19  DEBIAN_FRONTEND=noninteractive aptitude upgrade 2>&1 | tee
/tmp/aptup.log
   20  grep -i -e restart -e systemctl /tmp/aptup.log

and nothing appeared in the log.  :-)

(hostname)# DEBIAN_FRONTEND='noninteractive' needrestart
Scanning processes...
Scanning candidates...
Scanning kernel images...
Services to be restarted:
Skipping dbus.service...
Skipping getty@tty1.service...
Skipping kdm.service...
Skipping NetworkManager.service...
Skipping systemd-journald.service...
systemctl restart acpid.service atd.service autofs.service
console-kit-daemon.service cron.service dirmngr.service gpm.service
inetd.service irqbalance.service mcelog.service mdmonitor.service
nfs-common.service nis.service packagekit.service polkitd.service
rpcbind.service sendmail.service smartd.service ssh.service udisks2.service
upower.service user@0.service user@115.service user@3619.service

Looks like it's in list-only mode (still disconcerting to see the
'systemctl restart' line without a "Skipping"/"DEBUG" or other flagging
prefix, but clearly it's not actually issuing restarts:

pomelo2:~# systemctl status acpid.service
* acpid.service - ACPI event daemon
   Loaded: loaded (/lib/systemd/system/acpid.service; disabled)
   Active: active (running) since Sat 2015-11-28 10:30:26 MST; 1 months 24
days ago
...


(hostname)# needrestart
Scanning processes...
Scanning candidates...
Scanning kernel images...

Graphic (curses) UI comes up, queries if i want to restart various services
(i hit CANCEL)

BUT!
(hostname)# DEBIAN_FRONTEND='noninteractive' needrestart -v
...
Restarting the system to load the new kernel will not be handled
automatically, so you should consider rebooting. [Return]
...

So, it still blocks there on a terminal read -- which it should not do if
we're truly noninteractive (but, it obviously "Does The Right Thing(tm)"if
stdin redirected from /dev/null.   Just would be nice if it did NOT prompt
if it's non-interactive (even in verbose mode).

--stephen

On Fri, Jan 22, 2016 at 4:21 PM, Thomas Liske  wrote:

> Hi Stephen,
>
> On Fri, Jan 22, 2016 at 11:44:30AM -0700, Stephen Dowdy wrote:
> > I believe the Felix is saying that 'needrestart' appears to be unaware of
> > the common explicit DEBIAN_FRONTEND=noninteractive setting used to
> indicate
> > that package management should be non-interactive (and if not, then *I*
> am)
> >
> > I will often use 'pdsh' to run forced package updates like so:
> >
> > $ cut -d: -f1 vulnerable.log | WCOLL=- pdsh -lroot 'aptitude update -q=2;
> > DEBIAN_FRONTEND=noninteractive aptitude -q=2 safe-upgrade --assume-yes -o
> > Dpkg::Options::="--force-confold"  >
> > Unfortunately, 'needrestart's 'isatty' style checks are insufficient for
> my
> > needs here, as STDERR/STDOUT are attached to a pty associated with the
> > 'ssh' hitting all the systems i am updating...  I have no way of then
> > telling 'needrestart' to not restart services
> >
> > So, i unexpectedly got a bunch of systemctl restart invocations, and i
> find
> > that often borks things badly.
> >
> > If 'needrestart' could also check ${DEBIAN_FRONTEND}, that would be
> awesome.
> >
> > Otherwise, i suppose i will have to cfengine out a "Default No"
> > needrestart.conf configuration to all my systems.
>
> you could try to put something like
>
> cat < # Switch to list mode if debconf is running noninteractive
> $nrconf{restart} = (exists($ENV{DEBIAN_FRONTEND}) &&
> $ENV{DEBIAN_FRONTEND} eq 'noninteractive' ? 'l' : 'i');
>
> 1;
> EOF
>
> into /etc/needrestart/conf.d/noninteractive.conf. If it works we might
> should add it upstream...
>
>
> > So, indeed 'unattended-upgrades' runs are also triggering needrestart to
> > believe it is running interactively, and thus it restarts things.
> > 'unattended-upgrade' appears to buy into the "DEBIAN_FRONTEND" notion of
> > noninteractivity as well:
> >
> > # grep -i interactive /usr/bin/unattended-upgrade
> > # set debconf to NON_INTERACTIVE, redirect output
> > os.putenv("DEBIAN_FRONTEND", "noninteractive")
> > env["DEBIAN_FRONTEND"] = "noninteractive"
>
> So the fix should work for unattended-upgrades, too.
>
>
> Thx & HTH,
> Thomas
>
> --
>
> ::  WWW:https://fiasko-nw.net/~thomas/  ::
>:::  Jabber:   xmpp:tho...@jabber.fiasko-

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

El 21/01/16 a las 10:13, Thomas Schmitt escribió:


Now primary means: "First lure" and secondary means "Second lure" by your
definition.


There are normally two lures per firmware-hardware combination.
Depending on the medium, the lures are recognized in El Torito,
or in MBR, or in partition tables.

In general we have theses dimensions
   {Medium: CDROM, HDD} x
   {Firmware: BIOS, EFI, ... exotic others ...} x
   {Hardware: i386, amd64, ... exotic others ...}

Not all tuples chosen from these sets are valid and not all
valid tuples can be combined in one ISO filesystem.
But the 8 main combinations for PC hardware are valid and
combinable.

I would avoid ranking terms like "first" or "primary".
Job descriptions for bootloaders could rather look like
   (CDROM + HDD, BIOS, i386 + amd64)
   (HDD, EFI, i386)
   (HDD, EFI, amd64)

Some of them can hardly be separated from each other.
E.g. (HDD, BIOS, i386) and (HDD, BIOS, amd64) have identical
technical properties.


I was thinking on this. So... what if there is a fourth dimension for 
choosing if the job description goes first or second in the mkisofs command?


E.g.:
xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2
versus
xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1

So you don't like the primary or secondary terms.

How does xorriso name them?

Given that man xorrisofs talks about:

-eltorito-alt-boot

maybe we can just name them as:

"Main bootloader"
and
"Alternate bootloader".

Or maybe even better:

"Main eltorito entry"
and
"Alternate eltorito entry"
?

So that we can force a given bootloader to be used only as a "Main 
eltorito entry" ?



What do you think about this idea?


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#655957: shows unreadable questions

[Manoj Srivastava]

reassign 655957 debconf
thanks

Hi,

Here are some points:
 1. ucf does not do the display of the string directly, whiptail does
 2. ucf just send s a string to debconf to display;
 3. ucf did not select the front end to do the display, debconf selected
the front end
 4. The front end was not invoked by ucf
 5. ucf does not know whether the selected front end would use an xterm,
or create its own window
 6. debconf knows the width  of the lines, since it passes it to
whiptail
 7. Ideally, whiptal would handle the strings itself, by wrapping, or
scrolling he text. If not, it should not just silently runcate the
strings it was  handed, but communicate that back (It was, after
all, given he length as an argument)
 8. ucf can’t mediate in a negotiation between debconf and the selected
front end about what can be displayed, or whether flowing text is
feasible or not. 
 9.  This is not jsut an UCF issue; any client of debconf could send
 overly long lines for the  current width of the terminal window.

The general solution can’t be affected in ucf, and given that
 there is no way of knowing the capabilities and limitations of the
 available front ends, it can;t sensibly craft a solution.

manoj

On Sun, Jan 15 2012, Michael Tokarev wrote:

> Package: ucf
> Version: 3.0025+nmu1
> Severity: important
>
> Today I tried to update nfs-kernel-server, and the update process
> prompted me about overwriting a config file.  But the question as
> shown on the screen was completely unreadable.  Here is how it
> looks like in text (in a 80x25 terminal window):
>
>
> Package configuration
> ──┤ Изменён файл настройки 
> ├
> рсия файла настройки
> common, но версия файла,
> теме, была изменёна
>
>
> с изменённым файлом
> mon?
>
>установить версию из пакета
>сохранить установленную локальную версию
>показать различия между версиями
>показать различия между версиями параллельно
>показать 3-x стороннее различие между доступными версиями
>3-x стороннее слияние доступных версий (эксперимен. режим)
>запустить новую оболочку для прояснения ситуации
>
>
>  
>
> 
>
>
> This is in russian, but it is obvious anyway that only part of the
> text is shown, the rest is somewhere on the left.  I'm also attaching
> a screenshot of this.
>
> The process list of this looks like:
>
> 10443 pts/0Ss 0:00  |   \_ -bash
> 15757 pts/0S+ 0:01  |   \_ apt-get install -ttesting 
> nfs-kernel-server
> 16177 pts/2Ss+0:00  |   \_ /usr/bin/dpkg --status-fd 18 
> --configure libevent-2.0-5 nfs-common nfs-kernel-server
> 16181 pts/2S+ 0:00  |   \_ /bin/sh 
> /var/lib/dpkg/info/nfs-common.postinst configure 1:1.2.2-4
> 16270 pts/2S+ 0:00  |   \_ /usr/bin/perl -w 
> /usr/share/debconf/frontend /usr/bin/ucf --three-way 
> /usr/share/nfs-common/conffiles/nfs-common.default /etc/default/nfs-common
> 16305 pts/2S+ 0:00  |   \_ /bin/bash /usr/bin/ucf 
> --three-way /usr/share/nfs-common/conffiles/nfs-common.default 
> /etc/default/nfs-common
> 16342 pts/2S+ 0:00  |   \_ whiptail --backtitle 
> Package configuration --title Изменён файл настройки --output-fd 11 
> --nocancel --default-item сохранить установленную локальную версию --menu 
> Доступна новая версия файла настройки?/etc/default/nfs-common, но версия 
> файла,?находящаяся в системе, была изменёна?локально.??Что нужно сделать с 
> изменённым файлом?настройки nfs-common? 21 118 7 -- установить версию из 
> пакета  сохранить установленную локальную версию  показать различия между 
> версиями  показать различия между версиями параллельно  показать 3-x 
> стороннее различие между доступными версиями  3
> -x стороннее слияние доступных версий (эксперимен. режим)  запустить новую 
> оболочку для прояснения ситуации
>
> As it can be seen, process #16342 (whiptail) is spawned with
>
>  --menu ..choices.. 21 118 7,
>
> which corresponds to width of 118 characters.  But the window
> only had 80 columns in width, which is too few to display 118
> chars!
>
> The xterm window size is default, I haven't changed it once
> I started this xterm.  Resizing xterm makes no difference since
> whiptail - apparently - does not handle window resize signals
> properly.
>
> The result is that it is impossible to read a question which
> was asked during package install/upgrade, and so impossible
> to answer it, which makes all the efforts done in order to
> ensure good upgrades useless.
>
> For an expirienced user it is possible to recover well from
> this situation, but this needs some thinking still, -- at
> least seeing a process list to understand which file is in
> question.
>
> Tha

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

Despite of being discussing how to implement all of these properly. I 
feel it's right to show you my current work so that you can comment on it.


I attach my updated patches.

1) The main differences from my original patches are:

* I use more additional bootloader functions
* The code ensures that each bootloader can be used in its role, being 
it a primary bootloader o a secondary bootloader. That way we avoid the 
user being able to generate non bootable isos.


2) For the time being I am not maintaining the syslinux-efi branch till 
we manage to get a consensus on this one. Then I will rebase it, change 
the partition type and re-test it.


3) As I have mentioned in another message I plan to work on giving the 
user the ability of creating isos using:

--bootloaders="grub-efi" thus using grub-efi as a primary bootloader.

4) The patches can be found as a git branch (based on live-build master 
branch) here:


https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased_4


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
commit ff8206aea1985760dfea9ec94b93686a242f137e
Author: Adrian Gibanel Lopez 
Date:   Mon Jan 18 03:04:00 2016 +

functions/default.sh : Define LB_PRIMARY_BOOTLOADER at the Set_defaults 
function which it's the right place where to do it

diff --git a/functions/defaults.sh b/functions/defaults.sh
index ddf4b19..334984f 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -537,6 +537,8 @@ Set_defaults ()
esac
fi
 
+   LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 
}')
+
# Setting checksums
case "${LB_MODE}" in
progress-linux)
@@ -845,9 +847,6 @@ Check_defaults ()
fi
fi
 
-
-   LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 
}')
-
if [ "${LB_PRIMARY_BOOTLOADER}" = "syslinux" ]
then
# syslinux + fat or ntfs, or extlinux + ext[234] or btrfs
commit b3ec155600f79b6ac078ae8003e806735044a372
Author: Adrian Gibanel Lopez 
Date:   Wed Jan 20 00:53:53 2016 +0100

Remove repeated LB_PRIMARY_BOOTLOADER definition

diff --git a/scripts/build/binary_hdd b/scripts/build/binary_hdd
index d0db382..0c9c5af 100755
--- a/scripts/build/binary_hdd
+++ b/scripts/build/binary_hdd
@@ -67,8 +67,6 @@ do
esac
 done
 
-LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }')
-
 case ${LB_PRIMARY_BOOTLOADER} in
syslinux)
case ${LB_BINARY_FILESYSTEM} in
diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso
index d8b1553..67dfc85 100755
--- a/scripts/build/binary_iso
+++ b/scripts/build/binary_iso
@@ -107,8 +107,6 @@ then
XORRISO_OPTIONS="${XORRISO_OPTIONS} -V \"${LB_ISO_VOLUME}\""
 fi
 
-LB_PRIMARY_BOOTLOADER=$(echo "${LB_BOOTLOADERS}" | awk -F, '{ print $1 }')
-
 # Handle xorriso architecture specific options
 case "${LB_PRIMARY_BOOTLOADER}" in
grub)
commit e0abb8214b9ff71630220a24564a8770cea8658e
Author: Adrian Gibanel Lopez 
Date:   Mon Jan 18 03:07:48 2016 +

* Added: functions/bootloaders.sh . It has new bootloader functions that 
are heavily used in efi scenarios where a bootloader can act as a primary or a 
secondary bootloader.

Since the introduction of the new switch:

--bootloaders

you can setup it like this:

--bootloaders=syslinux,grub-efi

.

This means that syslinux is the primary bootloader and grub-efi is the 
secondary bootloader.

* Added new bootloader functions: Check_Non_Primary_Bootloader and 
Check_Non_Secondary_Bootloader.

These functions let each one of the bootloaders abort the build because
they cannot perform a role either as a primary bootloader or as a secondary 
bootloader.

* Added bootloader functions: Check_Primary_Bootloader_Role, 
Check_Secondary_Bootloader_Role and Check_Any_Bootloader_Role

These functions let bootloaders to force their default role in a single 
line.

diff --git a/functions/bootloaders.sh b/functions/bootloaders.sh
new file mode 100644
index 000..0829903
--- /dev/null
+++ b/functions/bootloaders.sh
@@ -0,0 +1,128 @@
+#!/bin/sh
+
+## live-build(7) - System Build Scripts
+## Copyright (C) 2016 Adrian Gibanel Lopez 
+##
+## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
+## This is free software, and you are welcome to redistribute it
+## under certain conditions; see COPYING for details.
+
+Is_Primary_Bootloader ()
+{
+   EVAL_PRIMARY_BOOTLOADER="${1}"
+
+   if [ "${LB_PRIMARY_BOOTLOADER}" = "${EVAL_PRIMARY_BOOTLOADER}" ]
+   then
+   return 0
+   else
+   return 1
+   fi
+
+}
+
+Is_Bootloader ()
+{
+   EVAL_BOOTLOADER="${1}"
+   OLDIFS="$IFS"
+   IFS=","
+   for BOOTLOADER in ${

Bug#812381: gedit no longer provides a dialog for configuring editor settings

[Karl-Philipp Richter]

Package: gedit
Version: 3.14.0-3
Severity: normal

Dear maintainer,
gedit no longer provides a dialog to configure editor settings (e.g.
indentation, auto-saving, etc.) like gedit version of Debian 7.x did. This
makes gedit hard to use as editor.

-- Package-specific info:
Active plugins:
  - 'time'
  -  'filebrowser'
  -  'modelines'
  -  'docinfo'
  -  'spell'

No plugin installed in $HOME.

Module versions:
  - glib  2.42.1
  - gtk+  3.14.5
  - gtksourceview 3.14.1
  - pygobject 
  - enchant   1.6.0
  - iso-codes 3.57


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

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

Versions of packages gedit depends on:
ii  gedit-common   3.14.0-3
ii  gir1.2-peas-1.01.12.1-2
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  iso-codes  3.57-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u1
ii  libcairo-gobject2  1.14.0-2.1
ii  libcairo2  1.14.0-2.1
ii  libenchant1c2a 1.6.0-10.1
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u4
ii  libgirepository-1.0-1  1.42.0-2.2
ii  libglib2.0-0   2.42.1-1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libgtksourceview-3.0-1 3.14.1-1
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpeas-1.0-0  1.12.1-2
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-5+deb8u1
ii  python3-gi 3.14.0-1
ii  python3-gi-cairo   3.14.0-1
pn  python3:any

Versions of packages gedit recommends:
ii  yelp3.14.1-1
ii  zenity  3.14.0-1

Versions of packages gedit suggests:
ii  gedit-plugins  3.14.0-2

-- no debconf information

Bug#812380: apt warns about /apt/apt.conf.d/50unattended-upgrades.ucf-dist

[Joey Hess]

Package: unattended-upgrades
Version: 0.86.5+build1
Severity: normal

Since I have the config file modified, every upgrade of
unattended-upgrades drops a .ucf-dist copy, which causes every run of
apt to warn about the file being ignored.

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

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

Versions of packages unattended-upgrades depends on:
ii  apt1.2
ii  apt-utils  1.2
ii  debconf [debconf-2.0]  1.5.58
ii  init-system-helpers1.24
ii  lsb-base   9.20160110
ii  lsb-release9.20160110
ii  python33.5.1-1
ii  python3-apt1.1.0~beta1
ii  ucf3.0031
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-128

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx   8.1.2-0.20150408cvs-1
ii  postfix [mail-transport-agent]  2.11.3-1+b1

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed [not included]

-- debconf information excluded

-- 
see shy jo

Bug#809292: slugimage: FTBFS: Ran out of flash space in - 0x00010 bytes too large.

[Martin Michlmayr]

Sorry, I sent the wrong patch.  Here's the correct one.

-- 
Martin Michlmayr
http://www.cyrius.com/
Index: slugimage
===
--- slugimage	(revision 114)
+++ slugimage	(working copy)
@@ -40,7 +40,7 @@
 use warnings;
 
 use Getopt::Long qw(:config no_ignore_case);
-use POSIX qw(tmpnam);
+use File::Temp qw(tempfile);
 
 my($debug) = 0;
 my($quiet) = 0;
@@ -1005,34 +1005,34 @@
 # don't touch RedBoot and SysConf anyway.  If no Trailer is specified,
 # put in one.
 if (not defined $redboot and not -e "RedBoot") {
-	$redboot = tmpnam();
-	open TMP, ">$redboot" or die "Cannot open file $redboot: $!";
+	my $tmp;
+	($tmp, $redboot) = tempfile();
 	push @cleanup, $redboot;
 	# The RedBoot partition is 256 * 1024 = 262144; the trailer we add
 	# is 70 bytes.
-	print TMP "\0"x(262144-70);
+	print $tmp "\0"x(262144-70);
 	# Upgrade tools check for an appropriate Sercomm trailer.
 	for my $i (@sercomm_redboot_trailer) {
-	print TMP pack "S", $i;
+	print $tmp pack "S", $i;
 	}
-	close TMP;
+	close $tmp;
 }
 if (not defined $sysconf and not -e "SysConf") {
-	$sysconf = tmpnam();
-	open TMP, ">$sysconf" or die "Cannot open file $sysconf: $!";
+	my $tmp;
+	($tmp, $sysconf) = tempfile();
 	push @cleanup, $sysconf;
 	# The SysConf partition is 128 * 1024 = 131072
-	print TMP "\0"x131072;
-	close TMP;
+	print $tmp "\0"x131072;
+	close $tmp;
 }
 if (not defined $trailer and not -e "Trailer") {
-	$trailer = tmpnam();
-	open TMP, ">$trailer" or die "Cannot open file $trailer: $!";
+	my $tmp;
+	($tmp, $trailer) = tempfile();
 	push @cleanup, $trailer;
 	for my $i (@sercomm_flash_trailer) {
-	print TMP pack "S", $i;
+	print $tmp pack "S", $i;
 	}
-	close TMP;
+	close $tmp;
 }
 
 # If the microcode was not specified, then don't complain that it's missing.

Bug#809292: slugimage: FTBFS: Ran out of flash space in - 0x00010 bytes too large.

[Martin Michlmayr]

I also forgot to add: my initial reaction that to suggest we remove
slugimage from Debian (so Debian unstable and the upcoming release),
but since slugimage is useful to pack slug images maybe it makes sense
to keep it around for one more release (and delete it after Debian
stretch is released).

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#809292: slugimage: FTBFS: Ran out of flash space in - 0x00010 bytes too large.

[Martin Michlmayr]

Hi Rod,

slugimage in Debian fails to build (with current Perl):

* Chris Lamb  [2015-12-28 23:56]:
>   Running test ./slugos/large-flashdisk... --- 
> ./slugos/large-flashdisk.expected  2006-12-28 08:41:44.0 +0100
>   +++ /tmp/do-test.3802015-12-29 00:50:02.270030213 +0100
>   @@ -1 +1,4 @@
>   +Calling POSIX::tmpnam() is deprecated at ../slugimage line 996.
>   +Calling POSIX::tmpnam() is deprecated at ../slugimage line 1009.
>   +Calling POSIX::tmpnam() is deprecated at ../slugimage line 1017.
>Ran out of flash space in  - 0x00010 bytes too large.
>   not ok
>   Running test ./slugos/standard... Calling POSIX::tmpnam() is deprecated at 
> ../slugimage line 996.
>   Calling POSIX::tmpnam() is deprecated at ../slugimage line 1009.
>   Calling POSIX::tmpnam() is deprecated at ../slugimage line 1017.
>   ok
>   Makefile:5: recipe for target 'test' failed
>   make[1]: *** [test] Error 1
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20151229004955.DQkH00QubC/slugimage-0.0+r104'
>   dh_auto_test: make -j1 test returned exit code 2
>   debian/rules:12: recipe for target 'build' failed
>   make: *** [build] Error 2

I converted to tempfile (File::Temp) and that also solves the
testsuite failure.

Can you commit this patch to SVN?  I can make an upload (unless Marc
wants to do it).

-- 
Martin Michlmayr
http://www.cyrius.com/

Use tempfile from File::Temp rather tha tmpname from POSIX
which is considered obsolete.

Index: slugimage
===
--- slugimage	(revision 114)
+++ slugimage	(working copy)
@@ -40,7 +40,7 @@
 use warnings;
 
 use Getopt::Long qw(:config no_ignore_case);
-use POSIX qw(tmpnam);
+use File::Temp qw(tempfile);
 
 my($debug) = 0;
 my($quiet) = 0;
@@ -1005,34 +1005,34 @@
 # don't touch RedBoot and SysConf anyway.  If no Trailer is specified,
 # put in one.
 if (not defined $redboot and not -e "RedBoot") {
-	$redboot = tmpnam();
-	open TMP, ">$redboot" or die "Cannot open file $redboot: $!";
+	my $tmp;
+	($tmp, $redboot) = tempfile();
 	push @cleanup, $redboot;
 	# The RedBoot partition is 256 * 1024 = 262144; the trailer we add
 	# is 70 bytes.
-	print TMP "\0"x(262144-70);
+	print $tmp "\0"x(262144-70);
 	# Upgrade tools check for an appropriate Sercomm trailer.
 	for my $i (@sercomm_redboot_trailer) {
-	print TMP pack "S", $i;
+	print $tmp pack "S", $i;
 	}
-	close TMP;
+	close $tmp
 }
 if (not defined $sysconf and not -e "SysConf") {
-	$sysconf = tmpnam();
-	open TMP, ">$sysconf" or die "Cannot open file $sysconf: $!";
+	my $tmp;
+	($tmp, $sysconf) = tempfile();
 	push @cleanup, $sysconf;
 	# The SysConf partition is 128 * 1024 = 131072
-	print TMP "\0"x131072;
-	close TMP;
+	print $tmp "\0"x131072;
+	close $tmp;
 }
 if (not defined $trailer and not -e "Trailer") {
-	$trailer = tmpnam();
-	open TMP, ">$trailer" or die "Cannot open file $trailer: $!";
+	my $tmp;
+	($tmp, $trailer) = tempfile();
 	push @cleanup, $trailer;
 	for my $i (@sercomm_flash_trailer) {
-	print TMP pack "S", $i;
+	print $tmp pack "S", $i;
 	}
-	close TMP;
+	close $tmp;
 }
 
 # If the microcode was not specified, then don't complain that it's missing.

Bug#812379: please package new version 0.6.0

[W. Martin Borgert]

Package: sat-xmpp-core
Version: 0.5.1-2
Severity: wishlist

Please consider updating the salutatoi package, thanks!

(Btw. it would be nice to package the web interface, libervia,
too: https://bugs.debian.org/725761)

Bug#638049: aptitude forgets which packages were installed automatically

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Harald,

2011-08-16 21:07 Harald Dunkel:


(I'd love to have some option in aptitude to mark all
installed packages as automatically installed, except
for those that do not appear on the Depends or Recommends
list of any installed package. This would make the use
of some high level meta packages much more interesting.)


This can be done with patterns.


2013-03-16 18:24 Harald Dunkel:

Hi Daniel,

I found a procedure to reproduce the problem by installing
and removing postgresql. Here is the script:
[...]

After running it I've got 2 new libraries that should have been removed
automatically:

Aptitude doesn't show the automatic flag for these libs.


I tried to reproduce this by installing postgresql and also firebird.
postgresql did not install any libs, but pulled in other deps, all of
which were removed when postgresql was.  firebird pulled other deps,
including libs, which were removed as well.

No other packages that I had marked as auto were modified in the course
of these operations.

I cannot say if other possible operations do not produce the effects
that you describe, but at least it does not happen in all cases.  The
merged bug reports are all from the same period many years ago, with
similar versions from aptitude and for sure apt -- both of which have
seen many fixes and changes in the last few years, and I am fixing other
cases for the next release of cases where the auto-installed flag was
removed from aptitude.

Some of the merged bug reports and their messages are not very specific
or indicate problems with python-aptdaemon and possibly apt-get instead,
some of which have been addressed.

Did you keep an eye on this and saw this happening recently?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#812358: debian-live: Please add gparted

[adrian15]

El 22/01/16 a las 23:47, Don Raikes escribió:

Hi,

I am willing to take the lead on resurrecting debian-live-rescue, but according 
to this webpage:
http://syn.theti.ca/2015/06/23/debian-live-rescue-needs-some-love/comment-page-1/#comment-5665

I should start by trying to build a rescue image from the existing live-image 
sources.

However, when I go to https://github.com/debian-live/live-images.git I cannot 
find a branch that contains the old rescue build configuration.

Is this configuration laying around somewhere I can use as a starting point?


Take a look at:

https://lists.debian.org/debian-live/2014/08/msg00081.html

https://adrian15sgd.wordpress.com/2015/11/13/about-rescue-tools-in-gnulinux-systems-in-2014-draft/ 
(Find the configuration link you want there. ;) )


https://lists.debian.org/debian-live/2015/11/msg00075.html

On one night we discussed in #debian-live irc about this rescue image / 
rescue blend and well. I leave you some bits here:



1) There was some discussion about the original dba plans on submitting 
a tasksel-rescue package versus what it's currently used:


* task-rescue (task-* is official tasks maintained by the d-i team).
* blendname-tasks (Already used in blends for their specific stuff.)

What I mean is that my article begins with me trying to make a 
tasksel-rescue package and it turns out that this package name not even 
exists.


2) Ben Armstrong wanted to reuse some of the packages I used on 
Rescatux. I warned him that Rescatux was graphical oriented and that I 
left out some cli tools from it. Some sysadmins might consider using 
grml instead of Rescatux for cli purposes just for that.



adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#811574: FTBFS with GCC 6: statement indented as if it were guarded by

[Aurelien Jarno]

control: tag -1 + fixed-upstream

On 2016-01-19 15:56, Martin Michlmayr wrote:
> Package: glibc
> Version: 2.21-6
> Severity: minor
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6 gcc-6-misleading-indentation
> 
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
> 
> Note that only the first error is reported; there might be more.  You
> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> you can set CC=gcc-6 CXX=g++-6 explicitly.
> 
> (I'm aware glibc uses GCC 4.x to build, which is why I set the
> severity to minor.  GCC 4.9 was really GCC 6 in my chroot.)

This bug is fixed upstream already, and will be in the 2.23 release.
Anyway we won't switch to GCC 6 without testing it builds and has no
regressions.

Aurelien

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

Bug#812358: debian-live: Please add gparted

[Daniel Reichelt]

Hi Don,

> However, when I go to https://github.com/debian-live/live-images.git I cannot 
> find a branch that contains the old rescue build configuration.

said repository is quite correct, however the files got removed from the
tree by [1].


> Is this configuration laying around somewhere I can use as a starting point?

The package lists are available until [2]

Cheers
Daniel



[1]
https://github.com/debian-live/live-images/commit/4c1911124c2ae128312ae6d256c8322d944d258f

[2]
https://github.com/debian-live/live-images/tree/3de5ad45b9fd2d3a6874bb4757288299a3e3b01a/images/rescue/config/package-lists

Bug#490547: aptitude: safe-upgrade selectively clears 'automatic' flags

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo

(sorry for repeating, re-resending with the correct bug number now)

Hi,

2008-07-11 09:28 Rune Kock:

stavanger:/home/rune# aptitude --version
aptitude 0.4.11.8 compiled at Jul  4 2008 17:26:43
Compiler: g++ 4.3.1
Compiled against:
 apt version 4.6.0
 NCurses version 5.6
 libsigc++ version: 2.0.18
 Ept support enabled.

Current library versions:
 NCurses version: ncurses 5.6.20080621
 cwidget version: 0.5.12
 Apt version: 4.6.0


stavanger:/home/rune# aptitude markauto knewsticker kopete kppp krdc
krfb kscd kscreensaver kscreensaver-xsavers xscreensaver-data
xscreensaver-data-extra libvncserver0 libotr2 ppp

stavanger:/home/rune# aptitude -t experimental safe-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Resolving dependencies...
Resolving dependencies...
[repeated about 50 times]
Resolving dependencies...
Resolving dependencies...
The following packages have been kept back:
 kdeartwork{a} kdemultimedia{a} kdenetwork{a} kdeplasmoids-data
libgtk2.0-bin{a} xserver-xorg-core{a}
0 packages upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Writing extended state information... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done


Result: the packages that I just marked as auto are changed to manual.
And aptitude didn't even do any real work!


Sorry that this report was unattended for so long.

Did you experience this in recent times, with examples of packages that
you can share?

I think that some changes happened in 0.6 series that might have
addressed this when installing new packages.  Otherwise I think that
this might be a manifestation of #613775 or #638049.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

El 21/01/16 a las 12:57, Thomas Schmitt escribió:



adrian15 wrote:

Do you mean if you have:
xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2
you could just re-arrange them as:
xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1
and it would be fine?



From the view of xorriso and El Torito specs this is ok.

You have to keep the modifier options (e.g. -boot-info-table) in
the same -eltorito-alt-boot department as their main options (e.g. -b).

The program isohybrid of SYSLINUX expects BIOS in El Torito catalog
entry 1, EFI in entry 2, and HFS+ in entry 3.
So with genisoimage + isohybrid, you'd have to keep the sequence.

One never knows what firmware does with such changes. Normally
it should accept any sequence. But tradition is: BIOS first, EFI second.


I see. So when using syslinux it's better for it to be the primary 
bootloader. Ok.


And, if I'm not mistaken doing a:

--bootloaders="grub-efi" should be quite easy.

That way people that want EFI only images would be able to make them. In 
order to do that I would just need to implement the primary bootloader 
behaviour of grub-efi and, well, remove the current grub-efi as a 
secondary bootloader role enforcement.


I might finally do that.


I wonder what EFI firmware would hop on an MBR partition of type 0x01.
An EFI System Partition in MBR should have type 0xef to be recognized.

That needs to be asked to Hertzog. I just tried to use his original work.


Did you try whether it boots via EFI if no BIOS boot equipment
is in the ISO ?

Well, I tried: kvm -bios /usr/share/ovmf/OVMF.fd -boot d -cdrom file.iso .

I probably need to do more tests later.


If I'm not mistaken Hertzog removed that option because you suggested to
remove it on:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66
Are you requesting to put this option back ?


Only if you augment the boot equipment by a third boot image that
contains a small HFS+ filesystem. (See Fedora Live CD.)
As long as there is no HFS+, the option -isohybrid-apm-hfsplus
is inappropriate but seems to do no harm. (See Debian amd64 netinst.)


I see. So the Fedora Live CD would seem even better. I wonder why the 
debian-cd team did not consider adding this third boot image with a 
small HFS+ filesystem. I'll probably ask them in the irc.



There are two ways known to me how to get a boot path via HFS+:

The debian-cd method is one of them? Or is it not?


debian-cd has no HFS+ boot image. This makes it different from
Fedora Live CD.

Understood.


The xorriso run could be easily adapted to include a HFS+ image.
But i do not know how Matthew Garrett produced this image.
I was doing some research on SElinux support and I found these set of 
tools for creating the Fedora Live CDs:


https://github.com/rhinstaller/livecd-tools

It's quite nice learning how other build their own live cd systems. 
Anyways, back to the main subject, I have no idea if Matthew Garrett 
used this tool or not.



One would have to investigate its content and find some Mac
filesystem tool to produce such content.

Probably.


The current debian-cd ( debian-8.2.0-amd64-i386-netinst.iso ) xorriso
options are: [well known from file /.disk/mkisofs in the ISO]
where you can see they use:
-isohybrid-apm-hfsplus
So... this is not useful for creating an HFS+ image file?


No. It just announces the EFI boot image in an Apple Partition Map.
This might be of use for GRUB2 if no other partition table points
to that image. But debian-cd has an MBR partition 0xef and a GPT
partition which point to that EFI boot image. (The GPT is to be
ignored by all sane EFI implementations.)

Ok. Did you mean "NOT to be ignored"?




What does this option do instead then?


It is surplus, currently.



Maybe I'm just repeating
what you are going to saying later in this email about how Grub2 handles
boot in Mac systems.


Regreattably i can only forward the rumor that Some (TM) Macs
do not boot without HFS+ and its blessed files.

They are in the time window between Apple Inc. giving up PowerPC
and Apple Inc. adopting EFI.
I have one of them in that window. I'm not sure about the blessing being 
needed though. Maybe I have disabled it. Not sure.




A) Are you complaining about syslinux-efi on:
-append_partition 2 0x01
that should be:
-append_partition 2 0xef
instead?


Yes. UEFI 2.4 5.2.2 says about booting from MBR partitions:
"* 0xEF (i.e., UEFI System Partition) defines a UEFI system partition."

The presence of GPT would have to be announced by a "protective MBR"
partition of type 0xee with start at LBA 1. Any MBR partition type other
than 0x00 and 0xee prevents the recognition of GPT.
Maybe that's why the syslinux-efi does not boot. I could give it a try 
changing the partition type and see what happens.



grub-mkrescue -o output.iso minimal_dir

Last time I checked it did not work ok in Debian because the commit
the grub package was based was too old.


I recently tested on my Sid VM with various combinations of 

Bug#803249: needrestart: Restarts services in debconf noninteractive

[Thomas Liske]

Hi Stephen,

On Fri, Jan 22, 2016 at 11:44:30AM -0700, Stephen Dowdy wrote:
> I believe the Felix is saying that 'needrestart' appears to be unaware of
> the common explicit DEBIAN_FRONTEND=noninteractive setting used to indicate
> that package management should be non-interactive (and if not, then *I* am)
> 
> I will often use 'pdsh' to run forced package updates like so:
> 
> $ cut -d: -f1 vulnerable.log | WCOLL=- pdsh -lroot 'aptitude update -q=2;
> DEBIAN_FRONTEND=noninteractive aptitude -q=2 safe-upgrade --assume-yes -o
> Dpkg::Options::="--force-confold"  
> Unfortunately, 'needrestart's 'isatty' style checks are insufficient for my
> needs here, as STDERR/STDOUT are attached to a pty associated with the
> 'ssh' hitting all the systems i am updating...  I have no way of then
> telling 'needrestart' to not restart services
> 
> So, i unexpectedly got a bunch of systemctl restart invocations, and i find
> that often borks things badly.
> 
> If 'needrestart' could also check ${DEBIAN_FRONTEND}, that would be awesome.
> 
> Otherwise, i suppose i will have to cfengine out a "Default No"
> needrestart.conf configuration to all my systems.

you could try to put something like

cat < So, indeed 'unattended-upgrades' runs are also triggering needrestart to
> believe it is running interactively, and thus it restarts things.
> 'unattended-upgrade' appears to buy into the "DEBIAN_FRONTEND" notion of
> noninteractivity as well:
> 
> # grep -i interactive /usr/bin/unattended-upgrade
> # set debconf to NON_INTERACTIVE, redirect output
> os.putenv("DEBIAN_FRONTEND", "noninteractive")
> env["DEBIAN_FRONTEND"] = "noninteractive"

So the fix should work for unattended-upgrades, too.


Thx & HTH,
Thomas

--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#756292: debian-history: [INTL:pt] Portuguese translation

[Américo Monteiro]

A Sábado, 9 de Janeiro de 2016 22:54:09, você escreveu:
> * Américo Monteiro  [2014-07-28 14:35]:
> > Updated Portuguese translation for debian-history's messages.
> > Translator: Américo Monteiro 
> > Feel free to use it.
> 
> There's also project-history.pt.sgml.  Should this be removed in
> favour of your pt.po, which I guess should be stored as po4a/po/pt.po?
I don't know... i believe there was a call to translators in a i18n mailling 
list before 
this translation was sent in 2014 to BTS, but I don't remember and I didn't 
knew anything 
about that other parallel translation... 

> 
> Can you update pt.po with the recent changes and send me a new version
> to commit?
I can't find that pt.po to upgrade, cant even find the pot template anymore 
If you sent 
it to me, I'll update it... but don't expect if rightaway.

Best regards
Américo

Bug#812337: init-system-helpers: file conflict with openrc: /usr/sbin/update-rc.d

[Michael Prokop]

* Michael Biebl [Fri Jan 22, 2016 at 03:08:32PM +0100]:

> I'm going to clone this bug report for file-rc, since it is equally
> affected.

[...]

I've worked on a patch for file-rc which takes care of diverting the
relevant invoke-rc.d. + update-rc.d files (following instructions as
documented at
https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html), so
file-rc can be co-installed with init-system-helpers >=1.25.

I'd highly appreciate a review and if there are no objections I'd
upload this then.

regards,
-mika-
From 091a11db2ee9be93270d48c67ca413b1bc7e1121 Mon Sep 17 00:00:00 2001
From: Michael Prokop 
Date: Sat, 23 Jan 2016 00:01:20 +0100
Subject: [PATCH] divert update-rc.d + invoke-rc.d files to cooperate with
 init-system-helpers >=1.25

Closes: #285835, #812337
---
 debian/postrm  | 22 +-
 debian/preinst | 16 
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/debian/postrm b/debian/postrm
index 018fd04..ad83e2c 100644
--- a/debian/postrm
+++ b/debian/postrm
@@ -17,12 +17,32 @@ set -e
 # for details, see http://www.debian.org/doc/debian-policy/ or
 # the debian-policy package
 
+# see #812337 + #285835, #805487
+undivert() {
+  dpkg-divert --package file-rc --remove --rename \
+--divert /usr/sbin/update-rc.d.real /usr/sbin/update-rc.d
+
+  dpkg-divert --package file-rc --remove --rename \
+--divert /usr/sbin/invoke-rc.d.real /usr/sbin/invoke-rc.d
+
+  dpkg-divert --package file-rc --remove --rename \
+--divert /usr/share/man/man8/update-rc.d.8.gz.real /usr/share/man/man8/update-rc.d.8.gz
+
+  dpkg-divert --package file-rc --remove --rename \
+--divert /usr/share/man/man8/invoke-rc.d.8.gz.real /usr/share/man/man8/invoke-rc.d.8.gz
+}
 
 case "$1" in
-upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
+upgrade|failed-upgrade|abort-upgrade)
+;;
+
+abort-install|disappear)
+undivert
 ;;
 
 remove)
+undivert
+
 	if [ ! -e /usr/sbin/update-rc.d ] ; then
 		ln -sf /usr/share/sysvinit/update-rc.d /usr/sbin/update-rc.d
 	fi
diff --git a/debian/preinst b/debian/preinst
index 9b3a1f0..0d9e962 100644
--- a/debian/preinst
+++ b/debian/preinst
@@ -14,12 +14,28 @@ set -e
 # for details, see http://www.debian.org/doc/debian-policy/ or
 # the debian-policy package
 
+# see #812337 + #285835, #805487
+divert() {
+  dpkg-divert --package file-rc --add --rename \
+--divert /usr/sbin/update-rc.d.real /usr/sbin/update-rc.d
+
+  dpkg-divert --package file-rc --add --rename \
+--divert /usr/sbin/invoke-rc.d.real /usr/sbin/invoke-rc.d
+
+  dpkg-divert --package file-rc --add --rename \
+--divert /usr/share/man/man8/update-rc.d.8.gz.real /usr/share/man/man8/update-rc.d.8.gz
+
+  dpkg-divert --package file-rc --add --rename \
+--divert /usr/share/man/man8/invoke-rc.d.8.gz.real /usr/share/man/man8/invoke-rc.d.8.gz
+}
 
 case "$1" in
 install)
+  divert
 ;;
 
 upgrade)
+  divert
 ;;
 
 abort-upgrade)
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

El 21/01/16 a las 10:13, Thomas Schmitt escribió:

Hi,

For the nomenclature: "USB" alone is misleading because there are
also optical drives attachable to USB. Better distinguish the boot
media families CDROM (CD, DVD, BD) and HDD (hard disk, USB stick,
memory card, ...).

Sorry. I was refering to USB stick then.



adrian15 wrote:

Grub-pc would be the one installed to be boot but syslinux files would be
there for Multi-USB tools to know how to understand the iso and put it into
an USB.


You mean the capability to boot the ISO via BIOS from USB stick ?
(Known with SYSLINUX as "isohybrid".)

grub-pc is supposed to be bootable that way too. Have a look at the
result of grub-mkrescue.
When running xorriso -as mkisofs, the decisive trick of grub-mkrescue
for BIOS bootability from HDD is:

   --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img

(It is obvious that only one bootloader can put its MBR at the
start of the ISO. So additional -isohybrid-mbr for SYSLINUX
would conflict.)

CDROM bootability via BIOS is caused by

-b boot/grub/i386-pc/eltorito.img \
  -no-emul-boot -boot-load-size 4 -boot-info-table \
  --grub2-boot-info

(Options learned from grub-mkrescue tests on Debian Sid.)
Well, yes, I know that you can use grub-pc to be able to boot a single 
image that boots from either a hard disk / USB stick / CDROM media in a 
BIOS system.


I did use that setup for building earlier versions of Rescatux (which 
included native Super Grub2 Disk in them).


My first will on putting both syslinux and grub-pc in the same media had 
not the purpose of making it bootable with two methods but rather to:

* Default boot into Grub2 (so that Super Grub2 Disk could be used natively).
* Confuse multi usb stick tools such as yumi to think that the iso was 
actually isolinux based. That way they can easily extract iso contents 
and put it into a multi usb stick device.


As I said before this was the original idea that made me add the primary 
and secondary bootloaders concept to live-build.




--bootloaders="syslinux,grub-efi,syslinux-efi"


Here i wonder whether (or how) your syslinux-efi boots out of an
ISO 9660 filesystem. My current knowledge is that SYSLINUX cannot
do this.
Yeah, you are right. You can take a look at what I have left from 
Hertzog patch here:


https://github.com/adrian15/live-build/commit/1397b6fc3dbf7d7f1e6a077a37b9f2e6ee7d7f39

His workaround for syslinux-efi not being able to boot out of an ISO 
9660 filesystem is to put the bootloader files, kernel and initrd on the 
efi image.


That way the efi image should be able to load the initrd in the ram so 
that the rest of the system can be found.


(Back in the day in some old systems you had to do this trick, e.g., add 
these files to the old IDE attached disk because BIOS was unable to boot 
the SATA attached disk. But the initrd, yes, knew how to handle it.)




Now primary means: "First lure" and secondary means "Second lure" by your
definition.


There are normally two lures per firmware-hardware combination.
Depending on the medium, the lures are recognized in El Torito,
or in MBR, or in partition tables.

In general we have theses dimensions
   {Medium: CDROM, HDD} x
   {Firmware: BIOS, EFI, ... exotic others ...} x
   {Hardware: i386, amd64, ... exotic others ...}

Not all tuples chosen from these sets are valid and not all
valid tuples can be combined in one ISO filesystem.
But the 8 main combinations for PC hardware are valid and
combinable.

I would avoid ranking terms like "first" or "primary".
Job descriptions for bootloaders could rather look like
   (CDROM + HDD, BIOS, i386 + amd64)
   (HDD, EFI, i386)
   (HDD, EFI, amd64)

Some of them can hardly be separated from each other.
E.g. (HDD, BIOS, i386) and (HDD, BIOS, amd64) have identical
technical properties.
I am sorry. I agree with you but I'm not going to change my current 
naming without further input. I would need a patch from you or a 
concrete new naming system with examples that replace the current names.


It seems you are proposing to add like three tags: Medium?, Firmware?, 
Architecture? but I don't get how that would transform into options that 
the final user can use.


And, well, how would you go into enabling or not a given bootloader 
given a Medium?, Firmware?, Architecture? combination.


I mean, don't get me wrong, I want to code this right but I'm not sure I 
understand why we need this. I mean, I know that the medium already 
choosing by either binary_hdd or binary_iso . And, the architectures can 
also be choosen if needed (LB_ARCHITECTURES if I'm not mistaken). Not 
sure why you want to question of all that out of a sudden.


Anyway, as I said, maybe giving me concrete examples might make me 
change my mind. If we are going to implement UEFI support into 
live-build let's do it right.



Given the way that both grub-efi and syslinux-efi use:
/efi/boot/bootia32.efi
and
/efi/boot/bootx64.efi
the last one to be run would overwrite the first one efi f

Bug#609013: exiftran: wrong operations with this image

[Stéphane Aulery]

reassign 609013 exiftran
stop

-

Hello Bill,


Le 22/01/2016 23:32, Bill Allombert a écrit :

On Thu, Oct 23, 2014 at 08:32:57PM +0200, Stéphane Aulery wrote:

retitle 609013 Rotate 90 ° clockwise impossible for this photo (exiftran, 
jpegtran, gthumb)
clone 609013 -1
reassign 609013 libjpeg9 1:9a-2
found 609013 8b-1
reassign -1 libjpeg8 8d1-2
found -1 8b-1
stop

This bug is not specific to Exiftran. I can reproduce it with jpegtran,
like you with gthumb :

$ jpegtran -rotate 90 -outfile photo_rotated_of_180_right.jpg 0.3.jpg

That's why I think it relates to the libjpeg(8/9) and I reassigns.


I do think the bug is in exiftran. Let's me explain:

This file is an EXIF image with an Exif Orientation marker that cause most 
Exif-compliant
image viewers to display the underlying jpeg image rotated by 270°.

The command jpegtran -rotate 90 rotates the underlying jpeg image but
also remove the Orientation marker. The result is an apparent rotation
of 180°.

Now, jpegtran need not be aware of the Exif tag, but exiftran should be
able to deal with the Orientation marker correctly.

(Note: libjpeg-progs include a script exifautotran to fix the
orientation, it wokrs fine with this image).


Sorry, yet another false assumption of my part like for bug #435130.

Thank you for the research track and sorry again for the noise and 
forgetfulness CC. I thought the maintainer get all the messages about 
its bugs.


Cheers,

--
Stéphane Aulery

Bug#811583: [Pkg-utopia-maintainers] Bug#811583:

[Michael Biebl]

Am 22.01.2016 um 23:48 schrieb Michael Biebl:

> Dan, could you have a look?

@Dan, for more context, see

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

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



signature.asc
Description: OpenPGP digital signature

Bug#812377: rabbitmq-server: New upstream available

[Heather Ellsworth]

Package: rabbitmq-server
Version: 3.6.0
Severity: wishlist

Dear Maintainer,

Version 3.6.0 is available from
https://github.com/rabbitmq/rabbitmq-common.git

Thanks,
Heather Ellsworth

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/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)

Bug#811583: [Pkg-utopia-maintainers] Bug#811583:

[Michael Biebl]

Hi Dave

Am 22.01.2016 um 17:40 schrieb David Malcolm:
> (I'm the upstream gcc author of -Wmisleading-indentation)
> 
> This issue has been fixed upstream in:
> http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=99ae6777893d0b149cbefac3f290c63c47e29f42
> 
> The code in question is here:
> https://sources.debian.net/src/modemmanager/1.4.12-1/libqcdm/tests/test-qcdm.c/#L46
>  
> https://sources.debian.net/src/modemmanager/1.4.12-1/libqcdm/tests/test-qcdm.c/#L52

There are more GCC 6 related build failures, even after fixing this one:


test-wmc.c: In function 'test_data_new':
test-wmc.c:45:2: error: statement is indented as if it were guarded
by... [-Werror=misleading-indentation]
  return d;
  ^~

test-wmc.c:42:5: note: ...this 'if' clause, but it is not
 if (port)
 ^~

test-wmc.c: In function 'test_data_free':
test-wmc.c:54:2: error: statement is indented as if it were guarded
by... [-Werror=misleading-indentation]
  g_free (d);
  ^~

test-wmc.c:51:5: note: ...this 'if' clause, but it is not
 if (d->com_data)
 ^~

cc1: all warnings being treated as errors
Makefile:554: recipe for target 'test_wmc-test-wmc.o' failed
make[3]: *** [test_wmc-test-wmc.o] Error 1
make[3]: Target 'all' not remade because of errors.
make[3]: Leaving directory '/tmp/modemmanager-1.4.12/libwmc/tests'


=> patch for that is attached. Dan, would be great if you can review and
apply.

==

cinterion/mm-broadband-modem-cinterion.c:86:30: error: 'bands_2g'
defined but not used [-Werror=unused-const-variable]
 static const CinterionBand2G bands_2g[] = {
  ^~~~

cc1: all warnings being treated as errors
Makefile:2205: recipe for target
'cinterion/libmm_plugin_cinterion_la-mm-broadband-modem-cinterion.lo' failed
make[2]: ***
[cinterion/libmm_plugin_cinterion_la-mm-broadband-modem-cinterion.lo]
Error 1

==


novatel/mm-plugin-novatel.c:50:35: error: 'custom_at_probe' defined but
not used [-Werror=unused-const-variable]
 static const MMPortProbeAtCommand custom_at_probe[] = {
   ^~~

cc1: all warnings being treated as errors
Makefile:2478: recipe for target
'novatel/libmm_plugin_novatel_la-mm-plugin-novatel.lo' failed


==

test-wmc-utils.c:114:19: error: 'uml290_encap_outbuf' defined but not
used [-Werror=unused-const-variable]
static const char uml290_encap_outbuf[] = {
^~~

cc1: all warnings being treated as errors
Makefile:526: recipe for target 'test_wmc-test-wmc-utils.o' failed
make[4]: *** [test_wmc-test-wmc-utils.o] Error 1
make[4]: Leaving directory '/tmp/modemmanager-1.4.12/libwmc/tests'

Some of those might be real issues.
E.g. it's not clear to me, why the encapsulated uml290_encap_src is
compared against encap_outbuf and *not* uml290_encap_outbuf.

Dan, could you have a look?

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From 5cd21a0ca4bbdf189494fd4507f16cc6ce9476d9 Mon Sep 17 00:00:00 2001
From: Michael Biebl 
Date: Fri, 22 Jan 2016 23:40:10 +0100
Subject: [PATCH] tests: white space / indentation fixes

---
 libwmc/tests/test-wmc-com.c | 10 +-
 libwmc/tests/test-wmc.c | 16 
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/libwmc/tests/test-wmc-com.c b/libwmc/tests/test-wmc-com.c
index 8b4b01d..4ffc338 100644
--- a/libwmc/tests/test-wmc-com.c
+++ b/libwmc/tests/test-wmc-com.c
@@ -43,13 +43,13 @@ typedef struct {
 gpointer
 test_com_setup (const char *port, wmcbool uml290, wmcbool debug)
 {
-	TestComData *d;
-	int ret;
+TestComData *d;
+int ret;
 
-	d = g_malloc0 (sizeof (TestComData));
-	g_assert (d);
+d = g_malloc0 (sizeof (TestComData));
+g_assert (d);
 d->uml290 = uml290;
-	d->debug = debug;
+d->debug = debug;
 
 if (getenv ("SERIAL_DEBUG"))
 d->debug = TRUE;
diff --git a/libwmc/tests/test-wmc.c b/libwmc/tests/test-wmc.c
index e1027b2..1fc13ab 100644
--- a/libwmc/tests/test-wmc.c
+++ b/libwmc/tests/test-wmc.c
@@ -34,15 +34,15 @@ typedef GTestFixtureFunc TCFunc;
 static TestData *
 test_data_new (const char *port, gboolean uml290, gboolean debug)
 {
-	TestData *d;
+TestData *d;
 
-	d = g_malloc0 (sizeof (TestData));
-	g_assert (d);
+d = g_malloc0 (sizeof (TestData));
+g_assert (d);
 
 if (port)
 d->com_data = test_com_setup (port, uml290, debug);
 
-	return d;
+return d;
 }
 
 static void
@@ -51,7 +51,7 @@ test_data_free (TestData *d)
 if (d->com_data)
 test_com_teardown (d->com_data);
 
-	g_free (d);
+g_free (d);
 }
 
 int main (int argc, char **argv)
@@ -102,9 +102,9 @@ int main (int argc, char **argv)
 g_test_suite_add (suite, TESTCASE (test_com_get_global_mode, data->com_data));
 }
 
-	result 

Bug#812378: snap-aligner: FTBFS: no match for max(unsigned long, _int64)

[Aaron M. Ucko]

Source: snap-aligner
Version: 0.18~1.0~beta.18+dfsg1-1
Severity: important
Justification: fails to build from source

32-bit builds of snap-aligner that get past #812376 still fail:

  SNAPLib/SortedDataWriter.cpp:338:70: error: no matching function for call to 
'max(long unsigned int, _int64)'
   min(1UL << 23, max(1UL << 17, bufferSpace / blocks.size(; // 
128kB to 8MB buffer space per block

So far, this error has only occurred on x32, but I expect *i386
builds will fail the same way.  I'd suggest including  and
substituting UINT64_C(1) for both occurrences of 1UL here.  Could you
please take a look?

Thanks!

Bug#812358: debian-live: Please add gparted

[Don Raikes]

Hi,

I am willing to take the lead on resurrecting debian-live-rescue, but according 
to this webpage:
http://syn.theti.ca/2015/06/23/debian-live-rescue-needs-some-love/comment-page-1/#comment-5665

I should start by trying to build a rescue image from the existing live-image 
sources.

However, when I go to https://github.com/debian-live/live-images.git I cannot 
find a branch that contains the old rescue build configuration.

Is this configuration laying around somewhere I can use as a starting point?

-Original Message-
From: Devin Trotter [mailto:devin.trot...@csiweb.com] 
Sent: Friday, January 22, 2016 12:16 PM
To: Don Raikes; 812...@bugs.debian.org; Ben Armstrong
Subject: RE: Bug#812358: debian-live: Please add gparted

Donald - I will help you with this as I can if you're willing to take the lead.

-Original Message-
From: Don Raikes [mailto:don.rai...@oracle.com]
Sent: Friday, January 22, 2016 11:21 AM
To: Ben Armstrong ; 812...@bugs.debian.org
Subject: Bug#812358: debian-live: Please add gparted

Ben,

I would consider taking on the task of maintaining the necessary files for a 
rescue image.

I haven't looked into what is involved, but if you can point me to some docs I 
will take a look and see if it will fit with my time constraints.

Sincerely,
Donald

-Original Message-
From: Ben Armstrong [mailto:sy...@sanctuary.nslug.ns.ca]
Sent: Friday, January 22, 2016 10:05 AM
To: Christian Hammers; 812...@bugs.debian.org
Subject: Bug#812358: debian-live: Please add gparted

On 22/01/16 12:46 PM, Christian Hammers wrote:
> Package: debian-live
> Version: 8.2.0-amd64-xfce-desktop
> Severity: wishlist
>
> Hello
>
> Please add "gparted" to the Debian Live CD.
>
> Live CDs are greate to rescue broken systems or to shrink/enlarge root 
> file systems etc. In such cases the graphical approach of gparted 
> which automatically resizes the filesystem with the partition is much 
> more error safe than the CLI alternatives fdisk or parted. That's 
> especially the case for GPT and LVM which are still quite new to some 
> people.
>
> The installed size of gparted and its dependency libparted-fs-resize0 
> would just be 7 MB.
>

Our desktop live images only contain the desktop, as it would be installed by 
the Debian Installer. While arguably, many different tools would be useful on a 
live utility disk, those are not things that normally come with a Debian 
desktop, so are not included.

The 'rescue' flavour used to exist and contained a number of tools designed for 
rescuing systems. However, that did not contain any desktop. Many excellent 
rescue images do exist that are produced by third parties and which would 
contain both a desktop and gparted. For Debian to have its own 'official' 
rescue image would require someone to do the work of looking after compiling a 
list of 'essential (possibly with GUI) rescue tools' to go on the image. So 
far, despite my repeated calls for help with this, nobody has stepped forward 
to do the work.

Regards,
Ben




This e-mail and any files transmitted with it are the property of Computer 
Services, Inc. and/or its divisions, are confidential, and are intended solely 
for the use of the individual or entity to whom this e-mail is addressed. The 
sender does not accept any responsibility for any loss, disruption or damage to 
your data or computer systems that may occur from content of any sort contained 
in, transmitted with, or added to this e-mail. If you are not a named recipient 
or otherwise have reason to believe that you have received this message in 
error, please notify the sender and delete this message immediately from your 
computer. Any other use, retention, dissemination, forwarding, printing, or 
copying of this e-mail is strictly prohibited.

Bug#812373: ITP: odhcp6c -- IPv6 DHCP and RA client from OpenWRT

[Bjørn Mork]

Ben Hutchings  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Ben Hutchings 
>
> * Package name: odhcp6c
>   Version : 1.1
>   Upstream Author : Steven Barth 
> * URL : https://github.com/sbyx/odhcp6c
> * License : GPLv2
>   Programming Lang: C
>   Description : IPv6 DHCP and RA client from OpenWRT
>
> odhcp6c is a minimal DHCPv6 and RA-client for use in embedded Linux
> systems especially routers.  It is intended to comply with RFC7084.
> Unlike isc-dhcp-client, it can be used with PPP links.
>
> [I have yet to verify that it does actually work over PPP, but the
> OpenWRT documentation implies that it does.]

For the record: The wide-dhcpv6-client also supports PPP links, and is
already available in Debian. But odhcp6c has the advantage that it is
maintained upstream. It would be great to have it in Debian. Thanks for
doing this!

Not only will it work with PPP. odhcp6c is also one of the few clients
that work with the L2 headerless 'raw-ip' mode I recently added in the
qmi_wwan driver:

 nemi:/tmp# ip -d link show dev wwan0
 110: wwan0:  mtu 1500 qdisc 
pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
 link/none  promiscuity 0 addrgenmode random 

 nemi:/tmp# odhcp6c -evN none wwan0
 odhcp6c[13205]: (re)starting transaction on wwan0
 odhcp6c[13205]: Starting INFOREQ transaction (timeout 4294967295s, max rc 0)
 odhcp6c[13205]: Got a valid reply after 8ms
 odhcp6c[13205]: entering stateless-mode on wwan0
 odhcp6c[13205]: Starting  transaction (timeout 86400s, max rc 0)


Probably not going to be a big demand based on that, but at least it
will make my testing easier :)


Bjørn

Bug#812248: lintian: don't check Homepage field (and similar) against dbgsym packages

[Russ Allbery]

Niels Thykier  writes:

> For those not on IRC: I think dbgsym should warrant as little attention
> at package build time from the average maintainers as entirely possible.
>   Having people override tags in a package they did not build directly
> seems like a waste of their time.  (FTR, not saying that every lintian
> tag in a dbgsym should be silenced in Lintian.  We could certainly want
> to fix debhelper in some cases)

I've never been very happy with how Lintian reported this specific check,
since it emits it for every binary package as a binary metadata field
check.  It would be nicer if it were a source package check so that it
would only be emitted once per source package, but that would require
somewhat more sophistication to ensure that each binary package gets an
appropriate Homepage control field if people are doing complicated things
with putting this field into separate binary package stanzas instead of
just in the source package stanza.

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

Bug#812376: snap-aligner: FTBFS on non-x86: unrecognized command line option '-msse'

[Aaron M. Ucko]

Source: snap-aligner
Version: 0.18~1.0~beta.18+dfsg1-1
Severity: important
Justification: fails to build from source

Builds of snap-aligner for non-x86 architectures all failed:

  g++: error: unrecognized command line option '-msse'

Please remove this option -- it is redundant on *amd64 and x32, limits
portability on *i386, and is unavailable altogether on other
architectures.

Thanks!

Bug#609013: exiftran: wrong operations with this image

[Bill Allombert]

On Thu, Oct 23, 2014 at 08:32:57PM +0200, Stéphane Aulery wrote:
> retitle 609013 Rotate 90 ° clockwise impossible for this photo (exiftran, 
> jpegtran, gthumb)
> clone 609013 -1
> reassign 609013 libjpeg9 1:9a-2
> found 609013 8b-1
> reassign -1 libjpeg8 8d1-2
> found -1 8b-1
> stop
> 
> Hello,
> 
> This bug is not specific to Exiftran. I can reproduce it with jpegtran,
> like you with gthumb :
> 
> $ jpegtran -rotate 90 -outfile photo_rotated_of_180_right.jpg 0.3.jpg
> 
> That's why I think it relates to the libjpeg(8/9) and I reassigns.

I do think the bug is in exiftran. Let's me explain:

This file is an EXIF image with an Exif Orientation marker that cause most 
Exif-compliant 
image viewers to display the underlying jpeg image rotated by 270°.

The command jpegtran -rotate 90 rotates the underlying jpeg image but
also remove the Orientation marker. The result is an apparent rotation
of 180°.

Now, jpegtran need not be aware of the Exif tag, but exiftran should be 
able to deal with the Orientation marker correctly.

(Note: libjpeg-progs include a script exifautotran to fix the
orientation, it wokrs fine with this image).

PS: please always CC the maintainer of the package you are reassigning a
bug to, otherwise they are likely not to notice the bug :)

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#812286: rquantlib: FTBFS with GCC 6: segfault

[Martin Michlmayr]

* Dirk Eddelbuettel  [2016-01-21 22:12]:
> Can you ensure that the other C++ dependencies, notably QuantLib and Rcpp
> with Build-Depends: r-cran-rcpp (>= 0.11.0), libquantlib0-dev (>= 1.7), are
> built under the same compiler?
> 
> We've seen similar breakage with R packages with ABI/API changes.

You were right.  I rebuilt r-cran-rcpp and libquantlib0-dev and now
rquantlib builds fine.

I then did:

apt-get install --reinstall libquantlib0-dev libquantlib0v5

built again and got the segfault again.

Maybe it makes sense to leave this bug report open as a reminder (and
to prevent new bugs to be file when someone does onather archie
rebuild with GCC 6) but change severity to minor.

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#759434: libranlip: diff for NMU version 1.0-4.2

[Wookey]

Control: tags 759434 + pending

Dear maintainer,

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

It needed to set a compat level to build with current autoreconf.  The
package really needs repackaging with dh which would reatly simplify
the packaging.

Regards.
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -u libranlip-1.0/debian/rules libranlip-1.0/debian/rules
--- libranlip-1.0/debian/rules
+++ libranlip-1.0/debian/rules
@@ -6,6 +6,7 @@
 
 build:
 	$(checkdir)
+	dh_autoreconf
 	./configure --prefix=/usr --enable-shared
 	$(MAKE) install prefix=$(CURDIR)/shared
 	[ ! -f Makefile ] || $(MAKE) distclean
@@ -23,6 +24,8 @@
 	-rm -rf shared static
 	-rm -rf debian/tmp debian/files* core debian/substvars
 	-rm -rf debian/libranlip1c2 debian/libranlip-dev
+	dh_autoreconf_clean
+	-rm -rf debian/*debhelper.log
 
 binary-indep: checkroot build
 	$(checkdir)
diff -u libranlip-1.0/debian/control libranlip-1.0/debian/control
--- libranlip-1.0/debian/control
+++ libranlip-1.0/debian/control
@@ -2,7 +2,7 @@
 Section: math
 Priority: optional
 Maintainer: Juan Esteban Monsalve Tobon 
-Build-Depends:
+Build-Depends: dh-autoreconf
 Homepage: http://www.deakin.edu.au/~gleb/ranlip.html
 Standards-Version: 3.7.2
 
diff -u libranlip-1.0/debian/changelog libranlip-1.0/debian/changelog
--- libranlip-1.0/debian/changelog
+++ libranlip-1.0/debian/changelog
@@ -1,3 +1,11 @@
+libranlip (1.0-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh-autoreconf to ensure builds use current autofoo and build
+on new architectures (Closes: #759434 #535999 #758031)
+
+ -- Wookey   Thu, 21 Jan 2016 23:10:42 +
+
 libranlip (1.0-4.1) unstable; urgency=low
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- libranlip-1.0.orig/debian/compat
+++ libranlip-1.0/debian/compat
@@ -0,0 +1 @@
+5


signature.asc
Description: Digital signature

Bug#812371: nis: NIS is started before rpcbind since rpcbind was migrated to systemd

[Nye Liu]

On Fri, Jan 22, 2016 at 09:34:19PM +, Mark Brown wrote:
> > This causes ypbind to NEVER properly start, and the bind_wait
> > obviously cannot ever succeed.
>
> It should eventually figure things out?

No, but I have a patch for nis script, attached...

--- dist/nis2016-01-20 16:18:24.171239577 -0800
+++ nis 2016-01-22 13:08:19.532968676 -0800
@@ -43,24 +43,38 @@

if [ "`ypwhich 2>/dev/null`" = "" ]
then
+   running=""
bound=""
log_action_begin_msg "binding to YP server"
-   for i in 1 2 3 4 5 6 7 8 9 10
+   for i in `seq 10`
do
sleep 1
-   log_action_cont_msg "."
-   if [ "`ypwhich 2>/dev/null`" != "" ]
+   # make sure ypbind started; rpcbind might not be ready 
yet
+   if [ -n "$( pidofproc ${NET}/ypbind )" ]
then
-   echo -n " done] "
-   bound="yes"
-   break
+   log_action_cont_msg "."
+   running="yes"
+   if [ "`ypwhich 2>/dev/null`" != "" ]
+   then
+   echo -n " done] "
+   bound="yes"
+   break
+   fi
+   else
+   running=""
+   # try to start ypbind again
+   log_action_cont_msg "x"
+   ypbind_start
fi
done
# This should potentially be an error
if [ "$bound" ] ; then
log_action_end_msg 0
-   else
+   elif [ "$running" ] ; then
log_action_end_msg 1 "backgrounded"
+   else
+   log_action_end_msg 1 "failed"
+   exit 1
fi
fi
 }
@@ -118,6 +132,14 @@
return 0
 }

+ypbind_start()
+{
+   start-stop-daemon -b --start --quiet \
+   --exec ${NET}/ypbind -- $broadcast ${YPBINDARGS}
+   # takes some time to come up
+   sleep 3
+}
+
 do_start ()
 {
oname=`domainname`
@@ -169,8 +191,7 @@
if want_ypbind
then
log_progress_msg "ypbind"
-   start-stop-daemon -b --start --quiet \
-   --exec ${NET}/ypbind -- $broadcast ${YPBINDARGS}
+   ypbind_start
bind_wait
fi
if [ "$NISSERVER" = "slave" -a "$NISMASTER" != "" ]



--
Nye Liu
n...@mrv.com
(747) 224-2253
(818) 772-0576 fax

"Who would be stupid enough to quote a fictitious character?"
-- Don Quixote


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#810828: flash-kernel: update kernel address for Linkstation LS-WTGL

[Martin Michlmayr]

* Roger Shimizu  [2016-01-13 01:58]:
> For Linkstation LS-WTGL boots fine with linux-image-4.3, but fails with
> linux-image-4.4.
> Here's the fix ported from QNAP TS-109 (Bug #809476), and it's been confirmed
> to boot well on LS-WTGL.

I don't fully grok this stuff either but I think this patch is not the
right solution.

The log you sent shows:

bootcmd=ide reset; ext2load ide 0:1 0x0010 /$(kernel); ext2load ide 0:1 
0x0080 /$(initrd); setenv bootargs $(bootargs_base) $(bootargs_root) 
$(bootargs_debug) $(buffalo_ver); bootm 0x0010 0x0080

So the kernel is loaded to 0x0010 and the ramdisk to 0x0080

Your patch sets the kernel load address to 0x00c08000.  So u-boot will
still load the kernel to 0x0010 but then (I guess) it's
uncompressed at 0x00c08000.  The problem is that 0x00c08000 is only 4
MB after the start of the ramdisk (0x0080), which doesn't leave a
lot of space for the ramdisk.

You can change initramfs-tools from MODULES=dep to MODULES=most,
generate and I suspect it wouldn't boot.

Can you try if something like 0x01a08000 works?

BTW, I assume we need to change this for all Linkstation devices.
-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#759703: Questions about Kea

[Adam Majer]

Hello Tomek,

On Fri, Jan 22, 2016 at 10:45:04PM +0100, Tomek Mrugalski wrote:
> On 22.01.2016 20:58, Adam Majer wrote:
> > Hi Tomasz,
> > 
> > I'm packaging Kea right now, and hopefully I will have it ready by end
> > of the week. But I do have some questions and it would be beneficial
> > if you could answer them.
> Hi Adam!
> 
> Great to hear that! I'll do my best to help.
> 
> >   1. Currently Kea has one combined config file. Since I would like to
> >   split the IPv4, Ipv6 and DDNS services into separate packages, is
> >   there any potential problem in splitting the config file into three
> >   distinct config files?
> That's not necessarily true. You could use one config file for all of
> them or three separate files if you want to. We provided a single config
> file, because it seems to be easier to maintain for users who installed
> from the source. But if you plan to split this into 3 packages, using 3
> separate configs seems perfectly fine.

Sounds good.


> On a related note, we're about to launch a kea-contrib repo on github.
> Let me know if there are any Debian specific files that you'd like us to
> host there. We'll put systemd scripts that were contributed by RedHat
> guys. I recently installed Debian 8 which seems to be using sysvinit.
> That's perfectly fine by me. I just wanted to mention that there are
> systemd scripts if they're of any use for you.


Systemd files are definitely prefererred especially if RedHat took the
time to define CapabilityBoundingSet and other security parameters. If
you can forward them, I'd appreciate it.

Systemd is Debian's default for next release, but I'll try to make
sure that things also work with SysV and Upstart. Debian likes to
support diversity :D

Debian-specific files most likely will end up at git.debian.org, but
kea-contrib could probably work too.


> >   2. Kea seem to be composed of a large number of dynamic
> >   libraries. Is there any particular reason to ship these in separate
> >   packages instead of one? Are there any libraries that are intended
> >   for users and not just internal usage?
> libkea-dhcp++ seems to be the only library that could be useful as a
> standalone package. It provides generic DHCP operations, like open
> sockets, parse and build DHCP options and packets etc. It is currently
> used by DHCPv4 server, DHCPv6 server, dhcp-ddns daemon and perfdhcp
> (which is a performance tool).
> 
> >   Also, some of the libraries do not contain all the symbols that they
> >   use. (you can use c++filt to change mangled names to readable ones)

> Thanks for this. I admit that I didn't know this tool. I will take a
> closer look. Due to family reasons, I won't be able to do this until Monday.
> 
> I'm not sure how you want to proceed with this. Is this an issue that
> blocks the packaging process? Regardless if it does, we as ISC will do
> our best to fix the problem. I see that most all of the issues you
> listed below are in libkea-asiodns. This is a library we have inherited
> from (now dead) bind10 project.

The program runs, so it's not a problem. But if there are symbols that
are then not needed, then it smells like dead-code that can be cleaned
up.

So, initially I will just have all the libraries in a kea-common
package that contains all the libraries, for now. A wishlist type of a
bug from me would be for you guys to combine all the libraries into 1
or 2 .so files, instead of having more than a dozen, especially if
most are just internal. So maybe,

  libdhcp++.so.
  libkea.so.

Is such a thing possible in the future?

Then I could have
  3 program packages (dhcpv4, dhcpv6, ddns)
  admin package with the perf program and database scripts
  2 library packages (4 actually, 2 are -dev)
  documentation package (yes, guide is packaged)

For now, one big happy common library package :D

- Adam

-- 
Adam Majer
ad...@zombino.com

Bug#812327: [Pkg-xen-devel] Bug#812327: xen: initrd booting with xen don't find any harddisks

[Markus Schräder]

Hi Ian,

does

https://www.priv.de/debianbugs/

help?

Regards,
Markus Schraeder


(adding the bug back, please keep it ccd)
On Fri, 2016-01-22 at 13:05 +0100, Markus Schräder wrote:

What is for you a full log? A dmesg?


At least the linux dmesg in both cases, yes.

In the Xen case if you can get the Xen dmesg one too (which you may not
from a initrd) that would be useful as well.

In the Xen case you might find http://wiki.xenproject.org/wiki/XenSerialCon
sole useful (if your hardware has a serial port, which is less common these
days). Failing that a digital photo of all the bits with (XEN) at the front
(a big block near the start of boot and possibly odd bits in the middle of
the dom0 logs later) would be better than nothing.

Ian.

Bug#812375: e17: mouse cursor flashing

[Michal Suchanek]

Package: e17
Version: 0.17.6-1
Severity: normal

Hello,

the default mouse cursor in e17 is ridiculously small.

Looking in mouse settings the preset reads 32 pixels.

Setting the cursor to anything larger than 64 pixels causes the cursor
to flash. It seems worse in some applications than others. eg. in the
mouse settings the flashing tends to be minor but in fullscreen terminal
window the cursor can become nearly invisible for seconds.

Maybe if there is some hardware limitation on sensible cursor size the
control panel should try harder to detect it.

Thanks

Michal

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

Kernel: Linux 3.16.0-4-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 e17 depends on:
ii  dbus-x11   1.10.6-1
ii  e17-data   0.17.6-1
ii  libasound2 1.0.29-1
ii  libc6  2.19-22
ii  libdbus-1-31.10.6-1
ii  libecore-con1  1.8.6-2.3
ii  libecore-evas1 1.8.6-2.3
ii  libecore-file1 1.8.6-2.3
ii  libecore-imf1  1.8.6-2.3
ii  libecore-input11.8.6-2.3
ii  libecore-ipc1  1.8.6-2.3
ii  libecore-x11.8.6-2.3
ii  libecore1  1.8.6-2.3
ii  libedbus1  1.7.10-1
ii  libedje-bin1.8.6-2.3
ii  libedje1   1.8.6-2.3
ii  libeet11.8.6-2.3
ii  libeeze1   1.8.6-2.3
ii  libefreet-bin  1.8.6-2.3
ii  libefreet1a1.8.6-2.3
ii  libeina1   1.8.6-2.3
ii  libeio11.8.6-2.3
ii  libevas1   1.8.6-2.2
ii  libevas1-engines-x [libevas1-engine-software-x11]  1.8.6-2.3
ii  libpam0g   1.1.8-3.2
ii  libxcb-keysyms10.4.0-1
ii  libxcb-shape0  1.11.1-1
ii  libxcb11.11.1-1

Versions of packages e17 recommends:
ii  pm-utils  1.4.1-15

e17 suggests no packages.

-- no debconf information

Bug#759445: unmass: diff for NMU version 0.9-3.1

[Wookey]

Control: tags 759445 + pending

Dear maintainer,

I've prepared an NMU for unmass (versioned as 0.9-3.1) and uploaded it
to DELAYED/07. This fixes the bugs filed in 2014 to let it build on
newer architectures. Diff attached.

Regards.
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -u unmass-0.9/debian/changelog unmass-0.9/debian/changelog
--- unmass-0.9/debian/changelog
+++ unmass-0.9/debian/changelog
@@ -1,3 +1,11 @@
+unmass (0.9-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh-autoreconf to support new architectures
+(Closes: #759445 #735386 #759451)
+
+ -- Wookey   Fri, 22 Jan 2016 15:35:53 +
+
 unmass (0.9-3) unstable; urgency=low
 
   * Small fix, add missing comments. (Closes: #456108)
@@ -5,7 +13,7 @@
   * Update email address.
 
  -- Gürkan Sengün   Mon, 28 Apr 2008 11:01:46 +0200
- 
+
 unmass (0.9-2) unstable; urgency=low
 
   * Fix clean target in debian/rules. (Closes: #442754)
diff -u unmass-0.9/debian/control unmass-0.9/debian/control
--- unmass-0.9/debian/control
+++ unmass-0.9/debian/control
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Gürkan Sengün 
-Build-Depends: debhelper (>= 5)
+Build-Depends: debhelper (>= 5), dh-autoreconf
 Homepage: http://mirex.mypage.sk/index.php?selected=1#Unmass
 Standards-Version: 3.7.3
 
diff -u unmass-0.9/debian/rules unmass-0.9/debian/rules
--- unmass-0.9/debian/rules
+++ unmass-0.9/debian/rules
@@ -13,6 +13,7 @@
 configure: configure-stamp
 configure-stamp:
 	dh_testdir
+	dh_autoreconf
 	cd kdev && ./configure --prefix=/usr
 	touch configure-stamp
 
@@ -29,6 +30,7 @@
 	rm -f build-stamp configure-stamp
 	[ ! -f kdev/Makefile ] || $(MAKE) -C kdev clean
 	-rm -f kdev/config.log kdev/Makefile kdev/src/Makefile kdev/config.status kdev/config.h kdev/libtool
+	dh_autoreconf_clean
 	dh_clean 
 
 install: build
only in patch2:
unchanged:
--- unmass-0.9.orig/debian/autoreconf
+++ unmass-0.9/debian/autoreconf
@@ -0,0 +1 @@
+kdev
\ No newline at end of file


signature.asc
Description: Digital signature

Bug#759703: Questions about Kea

[Tomek Mrugalski]

On 22.01.2016 20:58, Adam Majer wrote:
> Hi Tomasz,
> 
> I'm packaging Kea right now, and hopefully I will have it ready by end
> of the week. But I do have some questions and it would be beneficial
> if you could answer them.
Hi Adam!

Great to hear that! I'll do my best to help.

>   1. Currently Kea has one combined config file. Since I would like to
>   split the IPv4, Ipv6 and DDNS services into separate packages, is
>   there any potential problem in splitting the config file into three
>   distinct config files?
That's not necessarily true. You could use one config file for all of
them or three separate files if you want to. We provided a single config
file, because it seems to be easier to maintain for users who installed
from the source. But if you plan to split this into 3 packages, using 3
separate configs seems perfectly fine.

We did develop keactrl as a simple generic script for init.d-like
management that could work everywhere. It's perfectly fine to not use it
at all and replace it with Debian specific scripts.

On a related note, we're about to launch a kea-contrib repo on github.
Let me know if there are any Debian specific files that you'd like us to
host there. We'll put systemd scripts that were contributed by RedHat
guys. I recently installed Debian 8 which seems to be using sysvinit.
That's perfectly fine by me. I just wanted to mention that there are
systemd scripts if they're of any use for you.

>   2. Kea seem to be composed of a large number of dynamic
>   libraries. Is there any particular reason to ship these in separate
>   packages instead of one? Are there any libraries that are intended
>   for users and not just internal usage?
libkea-dhcp++ seems to be the only library that could be useful as a
standalone package. It provides generic DHCP operations, like open
sockets, parse and build DHCP options and packets etc. It is currently
used by DHCPv4 server, DHCPv6 server, dhcp-ddns daemon and perfdhcp
(which is a performance tool).

>   Also, some of the libraries do not contain all the symbols that they
>   use. (you can use c++filt to change mangled names to readable ones)
Thanks for this. I admit that I didn't know this tool. I will take a
closer look. Due to family reasons, I won't be able to do this until Monday.

I'm not sure how you want to proceed with this. Is this an issue that
blocks the packaging process? Regardless if it does, we as ISC will do
our best to fix the problem. I see that most all of the issues you
listed below are in libkea-asiodns. This is a library we have inherited
from (now dead) bind10 project.

As a final thought on this, I was wondering what should we do with the
changes. We'll commit them to our master branch and will release it
eventually in the next 1.1.0 release, which is planned sometime during
late spring/early summer. Waiting for the release is not a viable
option. You could keep the changes in kea-1.0.0-debian.tar.gz. Our git
repo is public on github, so maybe doing something like
kea-1.0.0+20160125 would be useful? In any case, I don't have any
preference here and will do whatever works best for you.

Speaking of packages, there are two additional packages that could be
possibly taken into consideration. We do have perfdhcp, which is a
DHCPv4 and DHCPv6 server performance testing tool. It's implementation
independent, so could be used without Kea servers. Also, there's Kea
User's Guide, with is extensive and has around 100 pages of text. This
is one of the Kea advantages over the old ISC DHCP - it's well
documented. If you decide to package it - great. If not, it may be
useful to point it out somewhere that it's available at kea website.

Once you have initial packages that you think are ready for broader
testing, let me know. I will ask good people on kea-dev and kea-users to
test them. There's well over 100 people there. I'm sure many of them are
running Debian and will be willing to help. Obviously, I'll test them
thoroughly myself, too.

Thanks again for doing this. As a happy Debian user since 1999, I'm very
happy that I would be able to help make it a bit better :)

Thanks,
Tomek

> dpkg-shlibdeps: warning: symbol _ZN3isc3dns6OpcodeC1Eh used by
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
> found in none of the libraries
> 
> dpkg-shlibdeps: warning: symbol
> _ZN3isc3dns7Message11addQuestionERKNS0_8QuestionE used by
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
> found in none of the libraries
> 
> dpkg-shlibdeps: warning: symbol _ZN3isc3dns7Message6setQidEt used by
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
> found in none of the libraries
> 
> dpkg-shlibdeps: warning: symbol
> _ZN3isc3dns7Message13setHeaderFlagENS1_10HeaderFlagEb used by
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
> found in none of the libraries
> 
> dpkg-shlibdeps: warning: symbol
> _ZN3isc3dns15SectionIteratorIN5boost10shared_ptrINS0_8QuestionD1Ev
> used by

Bug#508428: aptitude: losing automatically installed flag on conflict resolution

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Meelis,

2008-12-11 10:03 Meelis Roos:

Package: aptitude
Version: 0.4.11.11-1
Severity: normal


aptitude has been losing the 'A' flag on several packages recently and I can
see a direct cause for it. The 'A' flag has been lost after aptitudes conflict
resolution. aptitude sees conflicts, I select one solution (like keeping
libgnomefoo-common back) and the the A flag on libgnomefoo-common is lost.


Thanks for the report.

I commited a fix to address this problem, so marking it as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#812374: diaspora-common: Please allow use of another web server like apache2

[James Valleroy]

Package: diaspora-common
Severity: wishlist

Dear Maintainer,

Currently diaspora-common depends on nginx. It should be possible to run it
with apache2 instead (even if it requires some manual configuration).

Please consider changing the dependency to "nginx | httpd".




signature.asc
Description: OpenPGP digital signature

Bug#812373: ITP: odhcp6c -- IPv6 DHCP and RA client from OpenWRT

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings 

* Package name: odhcp6c
  Version : 1.1
  Upstream Author : Steven Barth 
* URL : https://github.com/sbyx/odhcp6c
* License : GPLv2
  Programming Lang: C
  Description : IPv6 DHCP and RA client from OpenWRT

odhcp6c is a minimal DHCPv6 and RA-client for use in embedded Linux
systems especially routers.  It is intended to comply with RFC7084.
Unlike isc-dhcp-client, it can be used with PPP links.

[I have yet to verify that it does actually work over PPP, but the
OpenWRT documentation implies that it does.]

Bug#812371: nis: NIS is started before rpcbind since rpcbind was migrated to systemd

[Mark Brown]

reassign 812371 rpcbind

On Fri, Jan 22, 2016 at 01:03:00PM -0800, Nye Liu wrote:
> Package: nis
> Version: 3.17-34
> Severity: critical
> Justification: breaks the whole system

> For some reason, even though $portmap is mentioned in /etc/init.d/nis as a
> start prereq, ypbind is started BEFORE rpcbind.

That sounds like an issue with the sysetmd conversion there, or possibly
with the systemd/sysvinit integration.  Note that I'm in the middle of
repackaging the nis programs, I just got the core yp-tools package in so
we should get that sometime next month hopefully. 

> This causes ypbind to NEVER properly start, and the bind_wait obviously cannot
> ever succeed.

It should eventually figure things out?


signature.asc
Description: PGP signature

Bug#812372: ITP: vagrant-cachier -- share a common package cache among similar VM instances

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 

* Package name: vagrant-cachier
  Version : 1.2.1
  Upstream Author : Fabio Rehm
* URL : https://github.com/fgrehm/vagrant-cachier
* License : MIT
  Programming Lang: Ruby
  Package source  : https://github.com/eighthave/debian/vagrant-cachier
  Description : share a common package cache among similar VM instances

 A Vagrant plugin that helps you reduce the amount of coffee you drink
 while waiting for boxes to be provisioned by sharing a common package
 cache among similar VM instances. Kinda like vagrant-apt_cache or
 this magical snippet but targeting multiple package managers and
 Linux distros.

Bug#812371: nis: NIS is started before rpcbind since rpcbind was migrated to systemd

[Nye Liu]

Package: nis
Version: 3.17-34
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

For some reason, even though $portmap is mentioned in /etc/init.d/nis as a
start prereq, ypbind is started BEFORE rpcbind.

This causes ypbind to NEVER properly start, and the bind_wait obviously cannot
ever succeed.

> Jan 22 12:51:01 compile1 kernel: [   22.330297] tg3 :02:00.0 eth0: Flow 
> control is on for TX and on for RX
> Jan 22 12:51:01 compile1 kernel: [   22.330416] IPv6: 
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> Jan 22 12:51:01 compile1 nis[461]: Setting NIS domainname to: xxx.xxx.xxx
...
> Jan 22 12:51:06 compile1 ypbind[615]: Unable to register (YPBINDPROG, 
> YPBINDVERS, udp).
...
> Jan 22 12:51:11 compile1 systemd[1]: Starting RPC bind portmap service...
> Jan 22 12:51:11 compile1 rpcbind[640]: rpcbind: xdr_/run/rpcbind/rpcbind.xdr: 
> failed
> Jan 22 12:51:11 compile1 rpcbind[640]: rpcbind: xdr_/run/rpcbind/portmap.xdr: 
> failed
> Jan 22 12:51:11 compile1 systemd[1]: Started RPC bind portmap service.
> Jan 22 12:51:11 compile1 systemd[1]: Reached target RPC Port Mapper.
...
> Jan 22 12:51:15 compile1 nis[461]: Starting NIS services: ypbindbinding to YP 
> server...failed (backgrounded).
> Jan 22 12:51:15 compile1 nis[461]: .
> Jan 22 12:51:15 compile1 systemd[1]: Started LSB: Start NIS client and server 
> daemons..

Note that the "RPC Port Mapper" target is only reached AFTER ypbind is started
(and fails)

This was working fine until somebody migrated /etc/init.d/rpcbind to
/lib/systemd/

-- Package-specific info:
nm-tool is not installed

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

Kernel: Linux 4.3.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/bash
Init: systemd (via /run/systemd/system)

Versions of packages nis depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  hostname   3.16
ii  libc6  2.21-6
ii  libdbus-1-31.10.6-1
ii  libdbus-glib-1-2   0.106-1
ii  libgdbm3   1.8.3-13.1
ii  libglib2.0-0   2.46.2-3
ii  libslp11.2.1-11
ii  lsb-base   9.20160110
ii  make   4.1-1
ii  netbase5.3
ii  rpcbind [portmap]  0.2.3-0.2

nis recommends no packages.

Versions of packages nis suggests:
pn  nscd  

-- debconf information excluded


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#808739: yoshimi: FTBFS: Missing cmGeneratorTarget instance!

[Rob Couto]

In case it helps, here's a patch to apply the same workaround to
1.3.7.1. It's basically the same as the recent commit but with
different line numbers.

-- 
Rob
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index f1cf0d0..c2f82df 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -217,18 +217,6 @@ else(READLINE_FOUND)
 message( FATAL_ERROR "Readline library not found! Please install 
development components (libreadline-dev)" )
 endif(READLINE_FOUND)
 
-set (GuiFluids
-UI/WidgetPDialUI.fl  UI/PresetsUI.fl  UI/EnvelopeUI.fl
-UI/LFOUI.fl  UI/FilterUI.fl  UI/VirKeyboardUI.fl
-UI/ConfigUI.fl  UI/SUBnoteUI.fl  UI/ResonanceUI.fl
-UI/OscilGenUI.fl  UI/ADnoteUI.fl  UI/PADnoteUI.fl
-UI/EffUI.fl  UI/BankUI.fl  UI/PartUI.fl
-UI/MicrotonalUI.fl  UI/MasterUI.flUI/MasterMiscUI.fl
-UI/ParametersUI.fl UI/ConsoleUI.fl
-)
-
-fltk_wrap_ui (yoshimi ${GuiFluids})
-set_source_files_properties (UI/MasterUI.h PROPERTIES GENERATED 1)
 set (YOSHI_INCLUDES ${FLTK_INCLUDE_DIR})
 
 if (BuildForDebug)
@@ -292,6 +280,52 @@ set (MusicIO_sources
 MusicIO/JackAlsaClient.cpp  MusicIO/AlsaJackClient.cpp
 )
 
+set (FlGUI_sources
+WidgetPDialUI.cpp  PresetsUI.cpp  EnvelopeUI.cpp
+LFOUI.cpp  FilterUI.cpp  VirKeyboardUI.cpp
+ConfigUI.cpp  SUBnoteUI.cpp  ResonanceUI.cpp
+OscilGenUI.cpp  ADnoteUI.cpp  PADnoteUI.cpp
+EffUI.cpp  BankUI.cpp  PartUI.cpp
+MicrotonalUI.cpp  MasterUI.cpp MasterMiscUI.cpp
+ParametersUI.cpp ConsoleUI.cpp
+)
+
+# mostly for make clean because cmake doesn't expect 2 files to come from 1 
custom command
+set (FlGUI_headers
+WidgetPDialUI.h  PresetsUI.h  EnvelopeUI.h
+LFOUI.h  FilterUI.h  VirKeyboardUI.h
+ConfigUI.h  SUBnoteUI.h  ResonanceUI.h
+OscilGenUI.h  ADnoteUI.h  PADnoteUI.h
+EffUI.h  BankUI.h  PartUI.h
+MicrotonalUI.h  MasterUI.h MasterMiscUI.h
+ParametersUI.h ConsoleUI.h
+)
+
+# workaround fltk_wrap_ui breakage
+add_custom_command(
+OUTPUT ${FlGUI_sources}
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/WidgetPDialUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/PresetsUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/EnvelopeUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/LFOUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/FilterUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/VirKeyboardUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ConfigUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/SUBnoteUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ResonanceUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/OscilGenUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ADnoteUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/PADnoteUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/EffUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/BankUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/PartUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/MicrotonalUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/MasterUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/MasterMiscUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ParametersUI.fl
+COMMAND ${FLTK_FLUID_EXECUTABLE} ARGS -c -o .cpp 
${CMAKE_CURRENT_SOURCE_DIR}/UI/ConsoleUI.fl
+)
+
 add_definitions (
 -D'YOSHIMI_VERSION="${YOSHIMI_VERSION}"'
 -D'BASE_INSTALL_DIR="${CMAKE_INSTALL_PREFIX}"'
@@ -395,7 +429,7 @@ set (ProgSources
 ${DSP_sources}
 ${Effects_sources}
 ${MusicIO_sources}
-${yoshimi_FLTK_UI_SRCS}
+${FlGUI_sources}
 )
 
 include_directories (AFTER
@@ -486,7 +520,7 @@ install (FILES 
${CMAKE_CURRENT_SOURCE_DIR}/../desktop/yoshimi.appdata.xml
 DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/appdata)
 
 set_directory_properties (PROPERTIES
-ADDITIONAL_MAKE_CLEAN_FILES "${CMAKE_SOURCE_DIR}/*UI.c* 
${CMAKE_SOURCE_DIR}/src/*UI.h"
+ADDITIONAL_MAKE_CLEAN_FILES "${FlGUI_headers}"
 )
 
 add_custom_target (showversion
diff --git a/src/LV2_Plugin/CMakeLists.txt b/src/LV2_Plugin/CMakeLists.txt
index 889f3ce..b512a49 100644
--- a/src/LV2_Plugin/CMakeLists.txt
+++ b/src/LV2_Plugin/CMakeLists.txt
@@ -66,18 +66,52 @@ file (GLOB yoshimi_manifest_ttl
 file (GLOB yoshimi_plugin_ttl
 yoshimi.ttl)
 
-set (GuiFluids
-../UI/WidgetPDialUI.fl  ../UI/PresetsUI.

Bug#812370: RM: qmf -- ROM; unmaintained, no rdeps

[Felix Geyer]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove qmf from unstable.
There is no one looking after the package in Debian and it has no rdeps in the 
archive.

Upstream is still active [1] but we shouldn't carry around the old version.

Thanks,
Felix

[1] https://code.qt.io/cgit/qt-labs/messagingframework.git/

Bug#812369: rpcbind does not properly provide $portmap needed by /etc/init.d/nis

[Nye Liu]

Package: rpcbind
Version: 0.2.3-0.2
Severity: important

Dear Maintainer,

The new /lib/systemd/system/rpcbind is a mess.

First off:

/etc/init.d/nis depends on $portmap, which leads to two problems

1) rpcbind does not provide $portmap (only rpcbind.target) so nis/ypbind may be
   started before rpcbind

2) even if nis/ypbind is started AFTER rpcbind.target, it does not actually
   mean rpcbind is up (since it apparently takes time to start), causing
   /etc/init.d/nis to fail to launch ypbind properly with:

   Unable to register (YPBINDPROG, YPBINDVERS, udp)

   And then the nis script goes in to bind_wait(), which never completes
   since ypbind was never started in the first place.

Secondly, $STATEDIR/rpcbind.xdr and $STATEDIR/portmap.xdr are no longer
created (thanks, systemd!), leading to:

 rpcbind: xdr_/run/rpcbind/rpcbind.xdr: failed
 rpcbind: xdr_/run/rpcbind/portmap.xdr: failed

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

Kernel: Linux 4.3.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/bash
Init: systemd (via /run/systemd/system)

Versions of packages rpcbind depends on:
ii  init-system-helpers  1.24
ii  initscripts  2.88dsf-59.2
ii  insserv  1.14.0-5
ii  libc62.21-6
ii  libsystemd0  228-4
ii  libtirpc10.2.5-1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20160110

rpcbind recommends no packages.

rpcbind suggests no packages.

-- no debconf information


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#812368: openssh-server: sshd thinks PuTTY can't do diffie-hellman-group-exchange-sha256

[Brian Minton]

Package: openssh-server
Version: 1:7.1p2-2
Severity: normal

Dear Maintainer,

I'm trying to connect to my system from a Windows client using PuTTY.
The particular version of PuTTY I'm using is TortoisePlink 0.63.0.
from the Xpra distribution.  It supports the key exchange 
diffie-hellman-group-exchange-sha256, which OpenSSH also supports.
However, it seems to be blocked by OpenSSH's compatibility mode.

The pertinent line from the log:

debug2: Compat: skipping algorithm
"diffie-hellman-group-exchange-sha256" [preauth]

I'm attaching the complete log.  Note that I'm using sslh to forward ssh
traffic arriving on port 443 to localhost port 22.


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

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

Versions of packages openssh-server depends on:
ii  adduser 3.113+nmu3
ii  cdebconf [debconf-2.0]  0.201
ii  debconf [debconf-2.0]   1.5.58
ii  dpkg1.18.4
ii  init-system-helpers 1.24
ii  libaudit1   1:2.4.5-1
ii  libc6   2.21-6
ii  libcomerr2  1.42.13-1
ii  libgssapi-krb5-21.13.2+dfsg-4
ii  libkrb5-3   1.13.2+dfsg-4
ii  libpam-modules  1.1.8-3.2
ii  libpam-runtime  1.1.8-3.2
ii  libpam0g1.1.8-3.2
ii  libselinux1 2.4-3
ii  libssl1.0.2 1.0.2e-1
ii  libsystemd0 228-4
ii  libwrap07.6.q-25
ii  lsb-base9.20160110
ii  openssh-client  1:7.1p2-2
ii  openssh-sftp-server 1:7.1p2-2
ii  procps  2:3.3.11-3
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages openssh-server recommends:
ii  ncurses-term  6.0+20151024-2
ii  xauth 1:1.0.9-1

Versions of packages openssh-server suggests:
ii  molly-guard  0.6.2
ii  monkeysphere 0.37-3
ii  rssh 2.3.4-4+b1
ii  ssh-askpass  1:1.2.4.1-9
ii  ssh-askpass-gnome [ssh-askpass]  1:7.1p2-1
ii  ufw  0.34-2

-- debconf information:
  ssh/new_config: true
  ssh/vulnerable_host_keys:
  ssh/disable_cr_auth: false
* ssh/insecure_telnetd:
  ssh/insecure_rshd:
  ssh/encrypted_host_key_but_no_keygen:
* ssh/use_old_init_script: true
  openssh-server/permit-root-login: false
# /usr/sbin/sshd -dd
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 1235
debug2: parse_server_config: config /etc/ssh/sshd_config len 1235
debug1: sshd version OpenSSH_7.1, OpenSSL 1.0.2e 3 Dec 2015
debug1: private host key #0: ssh-rsa 
SHA256:XXX
debug1: private host key #1: ssh-ed25519 
SHA256:XXX
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-dd'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 127.0.0.1 port 44436 on 127.0.0.1 port 22
debug1: Client protocol version 2.0; client software version 
PuTTY_Local:_Mar_19_2015_19:02:45
debug1: match: PuTTY_Local:_Mar_19_2015_19:02:45 pat 
PuTTY_Local:*,PuTTY-Release-0.5*,PuTTY_Release_0.5*,PuTTY_Release_0.60*,PuTTY_Release_0.61*,PuTTY_Release_0.62*,PuTTY_Release_0.63*,PuTTY_Release_0.64*
 compat 0x4000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1p2 Debian-2
debug2: fd 3 setting O_NONBLOCK
debug2: Network child is on pid 32034
debug1: permanently_set_uid: 101/65534 [preauth]
debug2: compat_kex_proposal: original KEX proposal: 
curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256 [preauth]
debug2: Compat: skipping algorithm "diffie-hellman-group-exchange-sha256" 
[preauth]
debug2: compat_kex_proposal: compat KEX proposal: curve25519-sha...@libssh.org 
[preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: kex_parse_kexinit: curve25519-sha...@libssh.org [preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-ed25519 [preauth]
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes256-...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
 [preauth]
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes256-...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
 [preauth]
debug2: kex_parse_kexinit

Bug#811430: libjsoncpp-dev: Install jsoncppConfig.cmake to dev package.

[Ghislain Vaillant]

There is no need for one if the "jsoncppConfig.cmake" file is installed 
in the appropriate CMake package directory. See the CMake reference [1] 
for "config" mode.


[1] https://cmake.org/cmake/help/v3.0/command/find_package.html

Judging by the content of the root CMakeLists.txt, you will have to 
enable the JSONCPP_WITH_CMAKE_PACKAGE option for it to be generated and 
installed:


IF(JSONCPP_WITH_CMAKE_PACKAGE)
INSTALL(EXPORT jsoncpp
DESTINATION ${PACKAGE_INSTALL_DIR}/jsoncpp
FILEjsoncppConfig.cmake)
ENDIF()

Hope this helps.

Ghis


On 22/01/16 20:15, Peter Spiess-Knafl wrote:

Hi Ghis!

I just looked at the upstream source (current and newest one). I
couldn't find any FindModule for JsonCpp. Do you have a reference to it?

On 01/19/2016 10:51 AM, Ghislain Vaillant wrote:

Hi Peter, thanks for acknowledging the bug.

Feel free to have a look here for a working example:


https://anonscm.debian.org/cgit/debian-science/packages/clblas.git/tree/debian


I have also provided an autopkgtest for building the examples to
verify that the find modules was installed appropriately. You may
also want to check clfft, arrayfire... or any other cmake based
package that I personally maintain if you don't trust my advice.

FYI, I believe the pkgconfig file should also end-up in a multi-arch
path (usr/lib//pkgconfig) since it depends on a
multi-arch enabled variable (libdir). I am happy to file a different
bug for it if you want.


This is a different bug yes. Thank your for recognizing it.

Greetings
Peter

Bug#811802: povray: FTBFS with GCC 6: multiple errors

[Martin Michlmayr]

* Andreas Beckmann  [2016-01-21 03:06]:
> I haven't looked into this, yet, but the most prominent change seems to
> be the default switch to -std=c++14. Have you tried rebuilding the
> failing packages with g++-6 -std=c++11/c++03/c++98/.../gnuXX (not sure
> whether the old ones are correctly spelled) to see if that succeeds
> somewhere? If additionally information is given like "But it builds
> successfully with g++6 -std=c++11" or "And it also fails with g++-6
> -std=c++AA/BB/CC/gnuXX/YY/ZZ" that should narrow the place where to
> start looking for this problem.

Sorry, I haven't done that.  I filed over 500 bugs so I cannot look at
every package in detail.  I could do it for yours but it sounds like
you have a pbuilder with g++-6 ready already (or ready soon) :)

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#811572:

[Antonin Kral]

Hi David,

thanks a lot for the followup. I've forwarded info to upstream.

https://github.com/troglobit/libite/issues/2

Best,

Antonin

* David Malcolm  [2016-01-22 15:40] wrote:
> (I'm the upstream gcc author of -Wmisleading-indentation)
> 
> Looking at,
>   https://github.com/troglobit/libite/blob/master/lite.h#L134
> the code in question seems to be:
> 
> static inline int fisslashdir(char *dir)
> {
>if (!dir) return 0;
>if (strlen (dir) > 0) return dir[strlen (dir) - 1] == '/';
>  return 0;
> }
> 

Bug#811430: libjsoncpp-dev: Install jsoncppConfig.cmake to dev package.

[Peter Spiess-Knafl]

Hi Ghis!

I just looked at the upstream source (current and newest one). I
couldn't find any FindModule for JsonCpp. Do you have a reference to it?

On 01/19/2016 10:51 AM, Ghislain Vaillant wrote:
> Hi Peter, thanks for acknowledging the bug.
> 
> Feel free to have a look here for a working example:
> 
> 
> https://anonscm.debian.org/cgit/debian-science/packages/clblas.git/tree/debian
> 
> 
> I have also provided an autopkgtest for building the examples to
> verify that the find modules was installed appropriately. You may
> also want to check clfft, arrayfire... or any other cmake based
> package that I personally maintain if you don't trust my advice.
> 
> FYI, I believe the pkgconfig file should also end-up in a multi-arch
> path (usr/lib//pkgconfig) since it depends on a
> multi-arch enabled variable (libdir). I am happy to file a different
> bug for it if you want.

This is a different bug yes. Thank your for recognizing it.

Greetings
Peter

Bug#812367: ITP: swift-bench -- benchmarking tool for Swift

[Ondřej Nový]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Nový" 

* Package name: swift-bench
  Version : 1.0
* URL : https://github.com/openstack/swift-bench
* License : Apache-2
  Programming Lang: Python
  Description : benchmarking tool for Swift

Swift Bench is simple tool for benchmarking OpenStack Swift cluster

As part of the pkg-openstack team, I am planning to package it.

Bug#809923: New package proposal: nordlicht

[Peter Spiess-Knafl]

Hi Sebastian!

Thank you very much for your review. Those were really some major flaws.

On 01/19/2016 12:54 PM, Sebastian Ramacher wrote:
> A new upstream version is available.

I managed to get most of this fixed upstream. I am just waiting for
another release, so that we don't need to have unnecessary patches.


> Why is linbpng-dev in Build-Depends? It doesn't seem to be used.

Removed it. Its not required you are right.

> Is there a reason libnordlicht0 and libnordlicht-dev are not
> multi-archified?

I provided some patches to upstream and will multi-archify the package
as soon as the new release is out.

https://github.com/cinemast/nordlicht/commit/4440b64eff581da855140867f6e9a8b0a599eaf0

> The library exports plenty of symbols that are not listed in
> nordlicht.h. Please hide those symbols (for example using
> __attribute__(visibility("hidden"))) and ideally get this fixed
> upstream.
> 

Fixed upstream:
https://github.com/nordlicht/nordlicht/commit/cc86cd362844700fced80ebcf443bb8f8a82c961

> nordlicht is overlinked:
> 
> dpkg-shlibdeps: warning: package could avoid a useless dependency
> if debian/nordlicht/usr/bin/nordlicht was not linked against
> libavcodec-ffmpeg.so.56 (it uses none of the library's symbols) 
> dpkg-shlibdeps: warning: package could avoid a useless dependency
> if debian/nordlicht/usr/bin/nordlicht was not linked against
> libavformat-ffmpeg.so.56 (it use s none of the library's symbols) 
> dpkg-shlibdeps: warning: package could avoid a useless dependency
> if debian/nordlicht/usr/bin/nordlicht was not linked against
> libavutil-ffmpeg.so.54 (it uses none of the library's symbols) 
> dpkg-shlibdeps: warning: package could avoid a useless dependency
> if debian/nordlicht/usr/bin/nordlicht was not linked against
> libswscale-ffmpeg.so.3 (it uses none of the library's symbols)
> 
> libnordlicht.so.0 is underlinked. Please link it against libm:
> 
> dpkg-shlibdeps: warning: symbol log10 used by
> debian/libnordlicht0/usr/lib/libnordlicht.so.0 found in none of the
> libraries

Fixed upstream:
https://github.com/nordlicht/nordlicht/commit/f69acc20599b8bf3edb8dd2986c1026b27af28a9


I will commit the missing changes about multi-arch support and a new
symbols file as soon as the new release is out.

Could you please than give it another chance?

Thank you and Greetings
Peter

Bug#442363: ITP: php-db-dataobject -- SQL Builder, Object Interface to Database Tables

[Bhuvan Krishna]

owner #442363 !
tag moreinfo



signature.asc
Description: OpenPGP digital signature

Bug#759703: Questions about Kea

[Adam Majer]

Hi Tomasz,

I'm packaging Kea right now, and hopefully I will have it ready by end
of the week. But I do have some questions and it would be beneficial
if you could answer them.

  1. Currently Kea has one combined config file. Since I would like to
  split the IPv4, Ipv6 and DDNS services into separate packages, is
  there any potential problem in splitting the config file into three
  distinct config files?


  2. Kea seem to be composed of a large number of dynamic
  libraries. Is there any particular reason to ship these in separate
  packages instead of one? Are there any libraries that are intended
  for users and not just internal usage?

  Also, some of the libraries do not contain all the symbols that they
  use. (you can use c++filt to change mangled names to readable ones)

Thanks,
Adam


dpkg-shlibdeps: warning: symbol _ZN3isc3dns6OpcodeC1Eh used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns7Message11addQuestionERKNS0_8QuestionE used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol _ZN3isc3dns7Message6setQidEt used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns7Message13setHeaderFlagENS1_10HeaderFlagEb used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns15SectionIteratorIN5boost10shared_ptrINS0_8QuestionD1Ev
used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns7Message8setRcodeERKNS0_5RcodeE used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZN3isc3dns7Message9setOpcodeERKNS0_6OpcodeE used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol _ZNK3isc3dns7Message13beginQuestionEv
used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol _ZN3isc3dns7MessageC1ENS1_4ModeE used
by debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: symbol
_ZNK3isc3dns15SectionIteratorIN5boost10shared_ptrINS0_8QuestiondeEv
used by
debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-asiodns.so.0.0.0
found in none of the libraries

dpkg-shlibdeps: warning: 9 other similar warnings have been skipped
(use -v to see them all)


-- 
Adam Majer
ad...@zombino.com

Bug#754478: Enable journald support

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 18 January 2016 03:16:25 Diederik de Haas wrote:
[snip]
> That ML msg references https://codereview.qt-project.org/#/c/89357/ of which
> the current status seems to be 'merged in 5.4'.
> 
> Maybe it's time for the recheck?

That patch was meant for OSX. For what I understand if we enable journald 
support people not using systemd will not get logs, and we need to support 
that use case.

-- 
Q. How did the programmer die in the shower?
A. He read the shampoo bottle instructions: Lather. Rinse. Repeat.
  http://www.devtopics.com/best-programming-jokes/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[KSB]

Seen this behavior on earlier kernels (i.e. 3.14-2-amd64 pkg 3.14.15-2.) 
and seems to be gone at least in 4.3

Bug#759403: lintian: Please publish machine-readable report for all packages

[Niels Thykier]

On Wed, 27 Aug 2014 07:06:11 +0200 Niels Thykier  wrote:
> On 2014-08-27 02:34, intrig...@debian.org wrote:
> > Package: lintian
> > Version: 2.5.25
> > Severity: wishlist
> > 
> > Hi,
> > 
> 
> Hi,
>

Hi,

I believe it is has been easier to hack on html_reports now, in case you
are still interested in working on this.


>> I've given it a try, but was quickly discouraged by the need for
>> a local lab (and mirror?), which I have no experience with.
>> 

These days, you "just" need:

 * a config file
   - /srv/lintian.debian.org/config (will need some modifications)
 * a lintian.log file
   - /srv/lintian.debian.org/logs/lintian.log
 * a harness state cache.
   - /srv/lintian.debian.org/harness-state/state-cache

All three files can be found on lindsay.debian.org at the denoted paths
(I believe you have a log-in there - otherwise let me know and I will
put a copy on people.d.o).

For the given files, you will be needing a lot of RAM (2 GB) without
graphs (even more with graphs).  Memory usage reducing patches will also
be very welcome. :)

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#805762: armory: Click-wrap dialogue appears on first use of package

[Gunnar Wolf]

Riley Baird dijo [Sun, Nov 22, 2015 at 05:53:01PM +1100]:
> Package: armory
> Version: 0.92.3-1+b1
> Severity: normal
> 
> Upon starting armory from the CLI, I get a notice which requires me to tick a
> box saying "I agree to all the terms of the license above" before I can use 
> the
> software. This is annoying, because a wonderful part of using Debian is not
> having to worry about licensing.

It makes you click through (and, I guess, only once). I would not
argue it is too obtrusive, and it does not require "worrying". Debian
has a policy of not deviating whenever possible from upstream for just
"cosmetic" reasons, so if at all, I'd suggest downgrading this bug to
"wishlist" (just shy of closing it :) ).

> However, I think I should point out that (as you can see in the attached
> screenshot), in addition to the AGPLv3, it is stated that "Additionally, as a
> condition of receiving this software for free, you accept all risks associated
> with using it and the developers of Armory will not be held liable for any 
> loss
> of money or bitcoins due to software defects." I am not a lawyer, so I do not
> intend to interpret how the AGPLv3 and this condition interact, and I've
> forwarded this message to debian-legal.

I would see this clause not as an additional condition, but as a
reiteration/emphatization of already existing conditions 15, 16 and 17
of AGPLv3:

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH
YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.

17. Interpretation of Sections 15 and 16.

If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely
approximates an absolute waiver of all civil liability in
connection with the Program, unless a warranty or assumption of
liability accompanies a copy of the Program in return for a fee.

Bug#812358: debian-live: Please add gparted

[Devin Trotter]

Donald - I will help you with this as I can if you're willing to take the lead.

-Original Message-
From: Don Raikes [mailto:don.rai...@oracle.com]
Sent: Friday, January 22, 2016 11:21 AM
To: Ben Armstrong ; 812...@bugs.debian.org
Subject: Bug#812358: debian-live: Please add gparted

Ben,

I would consider taking on the task of maintaining the necessary files for a 
rescue image.

I haven't looked into what is involved, but if you can point me to some docs I 
will take a look and see if it will fit with my time constraints.

Sincerely,
Donald

-Original Message-
From: Ben Armstrong [mailto:sy...@sanctuary.nslug.ns.ca]
Sent: Friday, January 22, 2016 10:05 AM
To: Christian Hammers; 812...@bugs.debian.org
Subject: Bug#812358: debian-live: Please add gparted

On 22/01/16 12:46 PM, Christian Hammers wrote:
> Package: debian-live
> Version: 8.2.0-amd64-xfce-desktop
> Severity: wishlist
>
> Hello
>
> Please add "gparted" to the Debian Live CD.
>
> Live CDs are greate to rescue broken systems or to shrink/enlarge root
> file systems etc. In such cases the graphical approach of gparted
> which automatically resizes the filesystem with the partition is much
> more error safe than the CLI alternatives fdisk or parted. That's
> especially the case for GPT and LVM which are still quite new to some
> people.
>
> The installed size of gparted and its dependency libparted-fs-resize0
> would just be 7 MB.
>

Our desktop live images only contain the desktop, as it would be installed by 
the Debian Installer. While arguably, many different tools would be useful on a 
live utility disk, those are not things that normally come with a Debian 
desktop, so are not included.

The 'rescue' flavour used to exist and contained a number of tools designed for 
rescuing systems. However, that did not contain any desktop. Many excellent 
rescue images do exist that are produced by third parties and which would 
contain both a desktop and gparted. For Debian to have its own 'official' 
rescue image would require someone to do the work of looking after compiling a 
list of 'essential (possibly with GUI) rescue tools' to go on the image. So 
far, despite my repeated calls for help with this, nobody has stepped forward 
to do the work.

Regards,
Ben




This e-mail and any files transmitted with it are the property of Computer 
Services, Inc. and/or its divisions, are confidential, and are intended solely 
for the use of the individual or entity to whom this e-mail is addressed. The 
sender does not accept any responsibility for any loss, disruption or damage to 
your data or computer systems that may occur from content of any sort contained 
in, transmitted with, or added to this e-mail. If you are not a named recipient 
or otherwise have reason to believe that you have received this message in 
error, please notify the sender and delete this message immediately from your 
computer. Any other use, retention, dissemination, forwarding, printing, or 
copying of this e-mail is strictly prohibited.

Bug#741894: libtk-img: FTBFS with libopng16

[Sergei Golovan]

On Fri, Jan 22, 2016 at 10:18 PM, Gianfranco Costamagna
 wrote:
> Hi, so are you saying this version is incompatible with libpng12?

Yes, that libtk-img will be incompatible with libpng12.

-- 
Sergei Golovan

Bug#812287: libetonyek: FTBFS with GCC 6: test suite segfaults

[Martin Michlmayr]

reopen 812287
reassign 812287 gcc-6 6-20160117-1
retitle 812287 test suites segfault / constexpr leaves reference member var 
uninitialized
forwarded 812287 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69327
thanks

* Rene Engelhard  [2016-01-22 13:01]:
> That reminds me of
> https://whatofhow.wordpress.com/2016/01/20/gcc-6/

Thanks for tracking that down!  Let's reassign the bug against gcc-6.

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#812366: linux-image-3.16.0-4-amd64: Kernel panic due to reading /sys/block/bcache?/bcache/writeback_rate_debug (bch_cached_dev_show)

[Dmitry Yu Okunev]

Package: src:linux
Version: 3.16.7-ckt20-1+deb8u1
Severity: normal
Tags: upstream

Hello.

I experienced a bug in module "bcache" of linux kernel (a reduced photo is 
attached, a less reduced photo you can download from [1]).

[1] 
https://devel.mephi.ru/dyokunev/public/raw/master/debian/bugreport/2016/bcache-panic/photo_kernelbug-bch_cached_dev_show.jpg

The server is in production so I have no ability to repeat the bug and I tried 
to recognize a text on the photo (sorry if there're any typos):

[525996.860864] 880c0010 880c84737630 880c84737d40 
880cbdd4a040
[525996.860943] aOSecaeS 0003 0003 
000a
[525996.861023] Call Trace:
{525996.861067] [] ? dump_stack+0x41/0x51
[525996.861108] [] ? panic+0xc8/0x1fc
[525996.861156] [l ? __bch_cached_dev_show+0x505/0x510 
[bcache]
[525996.861225} [] ? __stack_chk_fail+0x17/0x20
[525996.861269) [] ? __bch_cached_dev_show+0x505/0x510 
[bcache]
[525996.861338] [] ? bch_cached_dev_show+0x2c/0x50 [bcache]
[525996.861386] [] ? sysfs_kf_seq_show+0xc4/0x1e0
[525996.861431] [] ? seq_read+0xe2/0x360
[525996.861475] [] ? vfs_read+0x93/0x170
[525996.861514] [] ? SyS_read+0x42/0xa0
[525996.861555] [] ? page_fault+0x28/0x30
[525996.861598] [] ? system_call_fast_compare_end+0x10/0x15
[525996.861686] Kernel Offset: 0x0 from 0x8100 (relocation range: 
0x8000-0x9ff)
[525996.980293] ---[ end Kernel panic - not syncing: stack-protector: Kernel 
stack is corrupted in: a05ec3e5

I googled the issue and found [2]. Indeed I was reading files 
/sys/block/bcache{0,1,2,3}/bcache/writeback_rate_debug every second for 
debugging purposes. I stopped the processes, reading "writeback_rate_debug" and 
the bug didn't appear again.

[2] http://www.spinics.net/lists/linux-bcache/msg03173.html

Seems the bug is related to vanilla kernel code but Debian has own patches on 
the kernel, so I filled this report.

Best regards, Dmitry,
tel. 8 (495) 788-56-99, ext. 8255.

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=UUID=598c2749-c8c2-41ff-ac76-056ea007eb9e ro

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Model information
sys_vendor: Supermicro
product_name: SYS-6028R-WTR
product_version: 0123456789
chassis_vendor: Supermicro
chassis_version: 0123456789
bios_vendor: American Megatrends Inc.
bios_version: 1.0c
board_vendor: Supermicro
board_name: X10DRW-i
board_version: 1.02

** Loaded modules:
fuse
btrfs
xor
raid6_pq
ufs
qnx4
hfsplus
hfs
minix
ntfs
vfat
msdos
fat
jfs
xfs
dm_mod
iscsi_trgt(O)
cpuid
md_mod
drbd
lru_cache
libcrc32c
crc32c_generic
crc32c_intel
nfsd
auth_rpcgss
oid_registry
nfs_acl
lockd
sunrpc
fcoe
libfcoe
libfc
scsi_transport_fc
scsi_tgt
8021q
garp
stp
mrp
llc
mlx4_ib
ib_sa
ib_mad
ib_core
ib_addr
mlx4_en
mlx4_core
vxlan
x86_pkg_temp_thermal
intel_powerclamp
intel_rapl
coretemp
kvm_intel
iTCO_wdt
kvm
iTCO_vendor_support
crc32_pclmul
aesni_intel
aes_x86_64
lrw
gf128mul
glue_helper
ablk_helper
cryptd
joydev
pcspkr
mei_me
lpc_ich
ioatdma
shpchp
mei
i2c_i801
mfd_core
evdev
wmi
tpm_tis
tpm
ipmi_si
ipmi_msghandler
processor
thermal_sys
acpi_power_meter
acpi_pad
button
ext4
crc16
mbcache
jbd2
hid_generic
usbhid
hid
bcache
sg
sd_mod
crc_t10dif
crct10dif_generic
crct10dif_pclmul
crct10dif_common
ahci
libahci
ehci_pci
igb
i2c_algo_bit
xhci_hcd
ehci_hcd
libata
megaraid_sas
i2c_core
dca
usbcore
ptp
scsi_mod
usb_common
pps_core

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Haswell-E DMI2 [8086:2f00] (rev 
02)
Subsystem: Super Micro Computer Inc Device [15d9:0821]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation Haswell-E PCI Express Root Port 1 
[8086:2f02] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 PCI bridge [0604]: Intel Corporation Haswell-E PCI Express Root Port 2 
[8086:2f04] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.2 PCI bridge [0604]: Intel Corporation Haswell-E PCI Express Root Port 2

Bug#741894: libtk-img: FTBFS with libopng16

[Gianfranco Costamagna]

Hi, so are you saying this version is incompatible with libpng12?
Cheers
G.

Sent from Yahoo Mail on Android 
 
  On Fri, 22 Jan, 2016 at 19:15, Sergei Golovan wrote:   tags 
741894 + pending
thanks

Hi again!

On Fri, Jan 22, 2016 at 3:37 PM, Gianfranco Costamagna
 wrote:
>
> wonderful!
> please note that the transition might start soon(TM), maybe in a week or two,
> so this bug might become RC soon.

I've prepared the fixed package, but I won't upload it to experimental
because it requires packages from http://libpng.sviech.de/libpng16 to
build. But as long as libpng16-dev will go to sid and libfreetype6-dev
will not require libpng12-dev (via libpng-dev virtual package) I'll
immediately upload the version compatible with libpng16.

Cheers!
-- 
Sergei Golovan
  

Bug#812364:

[Ivan Borzenkov]

I build pakage from arch PKGBUILD in
https://launchpad.net/~ivan1986/+archive/ubuntu/ppa

https://launchpad.net/~ivan1986/+archive/ubuntu/ppa/+files/co2mon_2.1.0-4~ubuntu16.04.1~ppa1.dsc

it may have some errors, but it's maybe a good start for create debian
package.
This util may be usefull in Rasbery Pi and other AMR controllers for smart
home

Bug#812365: /usr/bin/apt-get: when download of a package list timeouts it is reported as Ign rather than Err

[Michal Suchanek]

Package: apt
Version: 1.0.10.2
Severity: normal
File: /usr/bin/apt-get

Hello,

I was wondering why apt-get update randomly ignores some packages files
and after adding some debug options it turns out that the download times
out and apt reports Ign before the source name.

This is a rather unfortunate way to report download failure.

Timeout should cause Err to be printed just like any other error.

Thanks

Michal

-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


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


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

Kernel: Linux 3.16.0-4-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 apt depends on:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.19-6
ii  libapt-pkg4.16  1.0.10.2
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-23
ii  libstdc++6  5.2.1-23

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.7.4-1
ii  dpkg-dev1.18.3
ii  python-apt  1.0.1

-- no debconf information

Bug#812364: RFP: co2mon - CLI for MasterKit CO2 Monitor

[Ivan Borzenkov]

Package: wnpp
Severity: wishlist

* Package name: co2mon
  Version : 2.1.0
  Upstream Author : Oleg Bulatov 
* URL : https://github.com/dmage/co2mon

* License : GPL
  Programming Lang: C
  Description : CLI for MasterKit CO2 Monitor

Bug#811428: [debian-mysql] Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU

[Lars Tangvald]

Hi Salvatore,

I'll get the wheezy-security package built and tested and send an update as 
soon as it's done.

regards,
Lars Tangvald

- Original Message -
From: car...@debian.org
To: robie.ba...@ubuntu.com
Cc: 811...@bugs.debian.org, t...@security.debian.org
Sent: Thursday, January 21, 2016 8:15:30 PM GMT +01:00 Amsterdam / Berlin / 
Bern / Rome / Stockholm / Vienna
Subject: [debian-mysql] Bug#811428: mysql-5.5: Multiple security fixes from the 
January 2016 CPU

Hi Robie,

On Thu, Jan 21, 2016 at 09:46:13AM +, Robie Basak wrote:
> Dear Security Team,
> 
> You have asked us to be prompt with helping to prepare security updates
> for you, and we have done so. We have kept the bug updated like you
> asked us last time. The sources are tested and ready. We notified the
> bug as requested, but haven't heard from you. Please let us know how you
> want to coordinate uploading this.

Thanks for preparing an update.

We usually would see a debdiff from the resulting built package (in
case of a new upstream import this can get big, so some autogenerated
files can be filtered out).

We have collected important information for us in advisory preparation
in https://wiki.debian.org/DebianSecurity/AdvisoryCreation especially
relevant from the developers point of view preparing the update
https://wiki.debian.org/DebianSecurity/AdvisoryCreation/SecurityDev .

The changelog itself looks good to me from a quick skim trough. It
addresses all the information we would like to have seen there (CVE
references, bug fixed, reference to Oracle CPU). Thank you.

Important question first: What is the status for the wheezy-security
package for those issues?

Plase make sure for the following: Once you have both, built the
jessie-security one with -sa to include the original orig.tar.gz and
the wheezy-security one explicitly without -sa to not include the orig
source tarball.

Then we need a bit of coordination for the upload order, since
mysql-5.5 is a special case with same source orig.tar.gz for both
wheezy and jessie. Someone of your team with GPG key in the DD keyring
might then upload first the jessie-security one to security-master,
and after it gets accepted there, upload the wheezy-security one.

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#812358: debian-live: Please add gparted

[Don Raikes]

Ben,

I would consider taking on the task of maintaining the necessary files for a 
rescue image.

I haven't looked into what is involved, but if you can point me to some docs I 
will take a look and see if it will fit with my time constraints.

Sincerely,
Donald

-Original Message-
From: Ben Armstrong [mailto:sy...@sanctuary.nslug.ns.ca] 
Sent: Friday, January 22, 2016 10:05 AM
To: Christian Hammers; 812...@bugs.debian.org
Subject: Bug#812358: debian-live: Please add gparted

On 22/01/16 12:46 PM, Christian Hammers wrote:
> Package: debian-live
> Version: 8.2.0-amd64-xfce-desktop
> Severity: wishlist
>
> Hello
>
> Please add "gparted" to the Debian Live CD.
>
> Live CDs are greate to rescue broken systems or to shrink/enlarge root 
> file systems etc. In such cases the graphical approach of gparted 
> which automatically resizes the filesystem with the partition is much 
> more error safe than the CLI alternatives fdisk or parted. That's 
> especially the case for GPT and LVM which are still quite new to some 
> people.
>
> The installed size of gparted and its dependency libparted-fs-resize0 
> would just be 7 MB.
>

Our desktop live images only contain the desktop, as it would be installed by 
the Debian Installer. While arguably, many different tools would be useful on a 
live utility disk, those are not things that normally come with a Debian 
desktop, so are not included.

The 'rescue' flavour used to exist and contained a number of tools designed for 
rescuing systems. However, that did not contain any desktop. Many excellent 
rescue images do exist that are produced by third parties and which would 
contain both a desktop and gparted. For Debian to have its own 'official' 
rescue image would require someone to do the work of looking after compiling a 
list of 'essential (possibly with GUI) rescue tools' to go on the image. So 
far, despite my repeated calls for help with this, nobody has stepped forward 
to do the work.

Regards,
Ben

Bug#784523: Bumping severities

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 22 January 2016 19:32:51 Jean-Francois Dockes wrote:
[snip]
> Hi,
> 
> Last week's upload was validated by Kartik Mistry, who is the Debian
> package maintainer. I'm the upstream and I see nothing wrong with the
> patch, but Kartik should probably be in the loop if he is around.

My bad at not being verbose enough, I was referring to Kartik indeed :)

-- 
No hay preguntas tontas, solo tontos que no preguntan.
 personaje, en un mail del LugFi.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#810820: linux-image-4.3.0-1-amd64: XEN fails after 7 domU's are started with linux-image-4.3.0-1-amd64 (version 4.3.3-5)

[KSB]

Can't find 4.3.3-6 anymore, but can confirm that on 4.3.3-7 problem is gone.
Do I need to make any additional tests?

Kaspars

Bug#812363: wheezy-pu: package giflib/4.1.6-10+deb7u1

[Guido Günther]

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

Hi,
I'd like to fix CVE-2015-7555 via wheezy-pu since the bug is fixed in
Squeeze LTS and we try to not introduce new security issues when people
upgrade (the Debian security team marked this CVE as no-dsa).

Please find the debdiff attached.
Cheers,
 -- Guido

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

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 727ea97..f728114 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+giflib (4.1.6-10+deb7u1) oldstable-security; urgency=medium
+
+  * Non-maintainer upload by the LTS Security Team.
+  * CVE-2015-7555: bail out if Width > SWidth.
+Cherry-picked upstream commit 179510be300bf5e37528d79619b53c884a63
+(Closes: #808704)
+
+ -- Guido Günther   Fri, 22 Jan 2016 19:03:38 +0100
+
 giflib (4.1.6-10) unstable; urgency=low
 
   * Fixing fprintf issues by YunQiang Su.
diff --git a/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch b/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch
new file mode 100644
index 000..e660bea
--- /dev/null
+++ b/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch
@@ -0,0 +1,22 @@
+From: "Eric S. Raymond" 
+Date: Tue, 5 Jan 2016 23:01:45 -0500
+Subject: CVE-2015-7555: bail out if Width > SWidth
+
+Cherry-picked upstream commit 179510be300bf5e37528d79619b53c884a63
+---
+ util/giffix.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/util/giffix.c b/util/giffix.c
+index 247305e..408d429 100644
+--- a/util/giffix.c
 b/util/giffix.c
+@@ -137,6 +137,8 @@ int main(int argc, char **argv)
+ 		Height = GifFileIn->Image.Height;
+ 		GifQprintf("\n%s: Image %d at (%d, %d) [%dx%d]: ",
+ 		PROGRAM_NAME, ++ImageNum, Col, Row, Width, Height);
++		if (Width > GifFileIn->SWidth)
++		GIF_EXIT("Image is wider than total");
+ 
+ 		/* Put the image descriptor to out file: */
+ 		if (EGifPutImageDesc(GifFileOut, Col, Row, Width, Height,
diff --git a/debian/patches/series b/debian/patches/series
index 3bcfb21..e297c1f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 02-doc_fixes.patch
 03-spelling_fixes.patch
 04-fprintf_format_error.patch
+CVE-2015-7555-bail-out-if-Width-SWidth.patch

Bug#780530: [calendarserver]

[Ximin Luo]

On 20/01/16 18:29, Rahul Amaram wrote:
>> (d) The git history for the debian/wheezy branch of calendarserver is also 
>> messed up - you have version 3.2 committed on top of 5.2.2. It involves a 
>> bit of git magic to fix, which I can do, if you want to avoid the hassle 
>> yourself and you give me access.
>>
>> I've also asked to be added to the calendarserver group on Alioth, so that I 
>> can make these changes myself.
> Feel free to do the changes. Not sure how it got messed up. Thanks.

OK, I've rewritten the history so things make more sense looking at the logs - 
all the "Imported Upstream version" commits are now in the correct linear 
sequence, as well as the "Imported Debian patch" commits, and debian/wheezy 
branches away from the main history at the correct place.

You'll need to update your own repo to point all your local branches to the new 
rewritten history. If it's too messy, you can just clone it again.

For transparency, I've attached the script I used, which is a combination of 
writing .git/info/grafts and git-filter-branch. You can run it on your own 
local old repo, and in theory you should even get the same commit SHA1 objects 
out. (But be careful! This will drop the gpg signatures on some old tags, so be 
careful not to push these back out.)

For reference, here's what you should expect the script to output, twice, to 
check that I didn't backdoor the source :)


debian/3.2+dfsg-4+deb7u1 fe8398cfe0b68277b4c95e116e8d37e6b88f5061
debian/3.2+dfsg-4+deb7u2 fb51628bb376ea59c7650a213a698b9c913f2f08
debian/3.2+dfsg-4+deb7u3 2254a4d52ff2338cf803e04a68656ae22571a668
debian/5.2.2+dfsg-1 612b68e1fc65c75cff8e23e860cd7e9d4e67db78
debian/5.2.2+dfsg-2 a7c22e20c5ca1d7d117f6130fac65c445b685361
debian/5.2+dfsg-1 9ea1e23624d0f0e8415ee4f248e7328c355c1e44
debian/sid 4e10242c8786ed237654dc3badfcae13742881a4
debian/wheezy 2254a4d52ff2338cf803e04a68656ae22571a668
dfsg/3.2+dfsg 1e54e2ea03c6729ae01f55771d1a62d8583d8d37
dfsg/6.2+dfsg 8792d5025eaf7babc5d7e79aca52d22f16f69acb
dfsg/7.0+dfsg 0b8deb3e9e47d68def2ea19699bb5faf88169e8c
dfsg/sid 0b8deb3e9e47d68def2ea19699bb5faf88169e8c
dfsg/wheezy 1e54e2ea03c6729ae01f55771d1a62d8583d8d37
upstream/5.2.2+dfsg c5f692769be97e5757fe6f8ee6082ef70c2386b0
upstream/5.2+dfsg 45caacfffe16dd80e9052b0797f588014de4008b
upstream/6.2 53592e714f2a8ff81f4bc0a6ac6153f703beec4b
upstream/7.0 d7604402e323a79dd8275c313c5b2377a3b35b7c
upstream/sid d7604402e323a79dd8275c313c5b2377a3b35b7c


X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git


rewrite-calendarserver-history.sh
Description: application/shellscript


signature.asc
Description: OpenPGP digital signature

Bug#812362: jessie-pu: package giflib/4.1.6-11+deb8u1

[Guido Günther]

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

Hi,
I'd like to fix CVE-2015-7555 via jessie-pu since the bug is fixed in
Squeeze LTS and we try to not introduce new security issues when people
upgrade (the Debian security team marked this CVE as no-dsa).

Please find the debdiff attached.
Cheers,
 -- Guido

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

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index d1fa6ba..d35e960 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+giflib (4.1.6-11+deb8u1) stable-proposed-updates; urgency=medium
+
+  * Non-maintainer upload by the LTS Security Team.
+  * CVE-2015-7555: bail out if Width > SWidth.
+Cherry-picked upstream commit 179510be300bf5e37528d79619b53c884a63
+(Closes: #808704)
+
+ -- Guido Günther   Mon, 18 Jan 2016 17:08:39 +0100
+
 giflib (4.1.6-11) unstable; urgency=low
 
   * Remove Provides: libungif4g.
diff --git a/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch b/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch
new file mode 100644
index 000..e660bea
--- /dev/null
+++ b/debian/patches/CVE-2015-7555-bail-out-if-Width-SWidth.patch
@@ -0,0 +1,22 @@
+From: "Eric S. Raymond" 
+Date: Tue, 5 Jan 2016 23:01:45 -0500
+Subject: CVE-2015-7555: bail out if Width > SWidth
+
+Cherry-picked upstream commit 179510be300bf5e37528d79619b53c884a63
+---
+ util/giffix.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/util/giffix.c b/util/giffix.c
+index 247305e..408d429 100644
+--- a/util/giffix.c
 b/util/giffix.c
+@@ -137,6 +137,8 @@ int main(int argc, char **argv)
+ 		Height = GifFileIn->Image.Height;
+ 		GifQprintf("\n%s: Image %d at (%d, %d) [%dx%d]: ",
+ 		PROGRAM_NAME, ++ImageNum, Col, Row, Width, Height);
++		if (Width > GifFileIn->SWidth)
++		GIF_EXIT("Image is wider than total");
+ 
+ 		/* Put the image descriptor to out file: */
+ 		if (EGifPutImageDesc(GifFileOut, Col, Row, Width, Height,
diff --git a/debian/patches/series b/debian/patches/series
index 3bcfb21..e297c1f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 02-doc_fixes.patch
 03-spelling_fixes.patch
 04-fprintf_format_error.patch
+CVE-2015-7555-bail-out-if-Width-SWidth.patch

Bug#803249: needrestart: Restarts services in debconf noninteractive

[Stephen Dowdy]

I believe the Felix is saying that 'needrestart' appears to be unaware of
the common explicit DEBIAN_FRONTEND=noninteractive setting used to indicate
that package management should be non-interactive (and if not, then *I* am)

I will often use 'pdsh' to run forced package updates like so:

$ cut -d: -f1 vulnerable.log | WCOLL=- pdsh -lroot 'aptitude update -q=2;
DEBIAN_FRONTEND=noninteractive aptitude -q=2 safe-upgrade --assume-yes -o
Dpkg::Options::="--force-confold" http://www.ral.ucar.edu/~sdowdy/