Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Hi,

> On 02/09/16 06:31, Salvatore Bonaccorso wrote:
> > On Thu, Sep 01, 2016 at 12:14:02PM +0100, Robert Shearman wrote:
> >> Alternatively, I'm pretty sure that adding the resulting changes to skel.c
> >> in 0006-CVE-2016-6354.patch would work too.
> >
> > I uploaded new varaiants of the builds and the corresponding source
> > package to the same location. Still subject to testing/review before
> > doing any other steps.
> 
> FWIW, I've tested the new packages you've uploaded and can confirm that 
> they fix the reported compile warning.

Me too.

Will this fix be pushed by security.debian.org as well now, or will
I have to install it manually?

I'm asking because I'm involved with a number of machines that
probably all have gotten the bad update by now, if I have to patch
them all myself now. (I'm also asking because I found another bug in
a security update of another package, incidentally on the same day
as this one?!) What's the usual procedure for non-security bugs
introduced by security updates? (Couldn't find anything about it on
the web site.)

Frank

Bug#835650: Imagemagick regression pin point patch

[Frank Heckenbach]

> I suppose 
> https://github.com/ImageMagick/ImageMagick/commit/f6242e725c819a69bee2a444f8e4a3c7718b2b3f
> 
> Fix it. If so plezse merge  this bug with the other one régression about pdf

Yes, this seems to fix my problem, thanks.

Frank

Bug#835650: Imagemagick regression pin point patch

[Frank Heckenbach]

> On Wed, Aug 31, 2016 at 8:42 AM, Bastien ROUCARIES
> <roucaries.bast...@gmail.com> wrote:
>
> > Patches are needed for a security point of view but it is likely a
> > problem of backport intereaction.
> >
> > Could you help by pin point the problem.
> >
> > as root install a few package needed for imagemagick compilation:
> > apt-get install git
> > apt-get build-dep imagemagick

Just for my reference:
libbz2-dev libdjvulibre-dev libexif-dev libharfbuzz-dev libharfbuzz-gobject0 
libilmbase-dev libjasper-dev libjbig-dev liblcms2-dev liblqr-1-0-dev 
liblzma-dev libopenexr-dev libpango1.0-dev libperl-dev libtiff5-dev libtiffxx5 
libwmf-dev pkg-kde-tools xsltproc

> > as a user
> >  git clone   git://git.debian.org/git/collab-maint/imagemagick.git
> > cd imagemagick
>
> HERE run
> git checkout debian-patches/6.8.9.9-5+deb8u3
> 
> > git checkout debian-patches/6.8.9.9-5+deb8u4

So I ran both (first +deb8u3, then +deb8u4), right?
(Otherwise, +deb8u3 would be the same as in "good" below.)

> > git bisect start
> > git bisect bad
> > git bissect good debian-patches/6.8.9.9-5+deb8u3
> >
> >   Once you have specified at least one bad and one good commit, git
> > bisect selects a commit in the middle of that range of history, checks
> > it out, and outputs something similar to the following:
> >
> >Bisecting: 675 revisions left to test after this (roughly 10 
> > steps)
> >
> >  You should now compile the checked-out version and test it. If that
> > version works correctly, type. Compiling is done by typing
> > ./configure
> > make check

That already gave an error (see test-suite.log). (I first ran make
with "-j16", then reran "make check" (but didn't rebuild) without
"-j", same result.) I'll be ignoring this (and further test-suite
errors I got while bisecting).

> > you could run the command without installing by runing the convert.sh 
> > wrapper
> > ./magick.sh convert geometry 40% tux.png tux-scaled-old.ppm
> >
> > if bad run
> > git bisect bad
> > and rerun compile and testing
> > if good run
> > git bisect good
> >
> > Some pointer could be found in man git bisect

26d910675e0cd1b62e988139dba8eb11931260ac is the first bad commit
commit 26d910675e0cd1b62e988139dba8eb11931260ac
Author: Cristy <urban-warr...@imagemagick.org>
Date:   Sat Jan 30 09:37:10 2016 -0500

Fix out of bound in quantum handling

Bug: https://github.com/ImageMagick/ImageMagick/issues/105
bug-ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1539053
origin: upstream, 
https://github.com/ImageMagick/ImageMagick/commit/c4e63ad30bc42da691f2b5f82a24516dd6b4dc70
bug-debian: https://bugs.debian.org/832506

:04 04 41e16d89455879892777d50135af38993b5be722 
e841bf15b62dee866b54eab729a93163d85aee68 M  magick

git diff 3e07cd10a9a2215c9edcc0c0e1541c125371cfbc 
26d910675e0cd1b62e988139dba8eb11931260ac
shows that the change essentially replaced image->columns by
MagickMax(image->columns,image->rows) in several places. This might
explain why the bug only occurs with portrait. I see that some
callers of GetQuantumExtent() use its result as the length parameter
to ReadBlob and similar, so it seems strange to use the max of width
and height here. Others callers might use it for a work buffer where
this might be correct (and probably what the change was meant to
fix), but it might be necessary to separate those two cases.

Frank


test-suite.log.bz2
Description: Binary data

Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found.

[Frank Fegert]

Hello Christian,

On Tue, Aug 30, 2016 at 10:24:22PM +0200, Christian Seiler wrote:
> While not having tested this, from just looking at the code with
> your explanation in mind, yes, you're right about that.

thanks for your confirmation!

> Your fix is also correct, but I'm not sure I like the endless
> list of -o -n repeats... I'll think about it for a while and if
> I can't find a better solution, I'll commit your fix to git.
> (And if I find a better solution, I'll commit that. ;-))

By all means, please do! I'm also not particularly happy with this
temporary fix, but "it did get the job done"[TM] ;-)

> Speaking of: you appear to be interested in a backport of
> open-iscsi into Jessie because you want to use offloading via
> iscsiuio. I've been thinking about uploading open-isns and
> open-iscsi to jessie-backports myself (precisely to have iscsiuio
> support available for Jessie users), but was unsure whether
> there's enough people who'd be interested in that. Would that be
> something you'd use yourself? Or would you want to continue to
> use your special backported version instead? Since you're
> actively using iscsiuio, I'd like to hear your opinion on that
> first.

No, i'd definitely prefer an "official" backported version of the
package, provided it's based on reasonably recent open-iscsi upstream
sources - there are several important fixes as of late not covered by
the current Jessie package sources. I particularly like your idea of
putting iscsiuio into its own package.
What's a real pain though, is the whole hassle with "_netdev", "LVM-
GROUPS", and still having to tweak the multipath init script. Well,
that's at least what i ended up with to get the order of things at
boot time at least almost right :-( Compared to the straightforward
use of targets through full iSOEs like e.g. the QME8262 cards, this
just feels awkward. Maybe it's just me doing something terribly wrong
;-)

Thanks & best regards,

Frank

Bug#836137: mate-panel: On startup, mate-panel spews hundreds of errors into .xsession-errors.

[Frank McCormick]

Package: mate-panel
Version: 1.14.2-1
Severity: normal




Like this:

(mate-panel:26256): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed



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

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.23-5
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libdbus-1-3  1.10.10-1
ii  libdbus-glib-1-2 0.106-1
ii  libdconf10.26.0-1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-3
ii  libgtk-3-0   3.20.9-1
ii  libice6  2:1.0.9-1+b1
ii  libmate-desktop-2-17 1.14.1-1
ii  libmate-menu21.14.0-1
ii  libmate-panel-applet-4-1 1.14.2-1
ii  libmateweather1  1.14.1-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  librsvg2-2   2.40.16-1
ii  libsm6   2:1.2.2-1+b1
ii  libstartup-notification0 0.12-4
ii  libwnck-3-0  3.20.1-1
ii  libx11-6 2:1.6.3-1
ii  libxau6  1:1.0.8-1
ii  libxrandr2   2:1.5.0-1
ii  mate-desktop 1.14.1-1
ii  mate-menus   1.14.0-1
ii  mate-panel-common1.14.2-1
ii  mate-polkit  1.14.0-1
ii  menu-xdg 0.5

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found.

[Frank Fegert]

Package: open-iscsi
Version: 2.0.873+git1.4c1f2d90-2

Dear open-iscsi maintainers,

probably just an odd corner case, but it seems that umountiscsi.sh
indiscriminately tries to umount *all* LVM based filesystems - even
those on local disks - when no iSCSI sessions are found by the code
in function "enumerate_iscsi_devices()". I've tried to explain the
experienced issue in greater detail here:
  http://www.bityard.org/blog/2016/08/28/backporting_open-iscsi_debian_jessie

A quick'n'dirty solution which worked for me can be found here:
  
https://github.com/frank-fegert/debian_open-iscsi/commit/5118af7fb23ed90281c7a5db3fde0e09bc61b225

Can you please take a look at this and possibly confirm this issue?

Thanks & best regards,

Frank Fegert

Bug#836006: mate-terminal: Mate-terminal on Mate desktop does not show transparency and ignores setting of window size

[Frank McCormick]

Package: mate-terminal
Version: 1.14.1-1
Severity: minor


It appears this edeveloped over the last several weeks. Mate-terminal could be 
set to
transparency and obeyed window sizes set in the profile.
The version now on my machine cannot be made transparent and ignores window 
size settings.



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

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

Versions of packages mate-terminal depends on:
ii  gsettings-desktop-schemas  3.20.0-3
ii  libatk1.0-02.20.0-1
ii  libc6  2.23-5
ii  libcairo-gobject2  1.14.6-1+b1
ii  libcairo2  1.14.6-1+b1
ii  libgdk-pixbuf2.0-0 2.34.0-1
ii  libglib2.0-0   2.48.1-2
ii  libgnutls303.5.3-2
ii  libgtk-3-0 3.20.9-1
ii  libice62:1.0.9-1+b1
ii  libmate-desktop-2-17   1.14.1-1
ii  libpango-1.0-0 1.40.1-1
ii  libpangocairo-1.0-01.40.1-1
ii  libsm6 2:1.2.2-1+b1
ii  libstartup-notification0   0.12-4
ii  libvte-2.91-0  0.44.2-1
ii  libx11-6   2:1.6.3-1
ii  mate-desktop-common1.14.1-1
ii  mate-terminal-common   1.14.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

mate-terminal recommends no packages.

mate-terminal suggests no packages.

-- no debconf information

Bug#835652: Error: Timeout was reached occurring in apt-get

[Frank Solomon]

Package:  apt-get

 

Version:

apt 1.0.9.8.3 for armhf compiled on Apr  2 2016 16:38:14

Supported modules:

*Ver: Standard .deb

Pkg:  Debian APT solver interface (Priority -1000)

*Pkg:  Debian dpkg interface (Priority 30)

S.L: 'deb' Standard Debian binary tree

S.L: 'deb-src' Standard Debian source tree

Idx: EDSP scenario file

Idx: Debian Source Index

Idx: Debian Package Index

Idx: Debian Translation Index

Idx: Debian dpkg status file

 

OS Version:

Linux  4.4.13+ #894 Mon Jun 13 12:43:26 BST 2016 armv6l GNU/Linux

 

Almost everything I try to install using apt-get has started giving the
message:  "Error:  Timeout was reached"

 

For example:  

$ sudo apt-get install reportbug

 

Gives:

 

Reading package lists... Done

Building dependency tree

Reading state information... Done

The following extra packages will be installed:

  docutils-common docutils-doc libpaper-utils libpaper1 python-apt
python-debian python-debianbts python-defusedxml

  python-docutils python-pygments python-reportbug python-roman
python-soappy python-wstools

Suggested packages:

  python-apt-dbg python-vte python-apt-doc texlive-latex-recommended
texlive-latex-base texlive-lang-french fonts-linuxlibertine

  ttf-linux-libertine ttf-bitstream-vera debsums dlocate python-urwid
python-gtkspell emacs23-bin-common emacs24-bin-common

The following NEW packages will be installed:

  docutils-common docutils-doc libpaper-utils libpaper1 python-apt
python-debian python-debianbts python-defusedxml

  python-docutils python-pygments python-reportbug python-roman
python-soappy python-wstools reportbug

0 upgraded, 15 newly installed, 0 to remove and 0 not upgraded.

Need to get 2,701 kB of archives.

After this operation, 11.4 MB of additional disk space will be used.

Do you want to continue? [Y/n] Y

Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main libpaper1
armhf 1.1.24+nmu4 [21.4 kB]

Get:2 http://mirrordirector.raspbian.org/raspbian/ jessie/main python-apt
armhf 0.9.3.12 [156 kB]

Get:3 http://mirrordirector.raspbian.org/raspbian/ jessie/main python-debian
all 0.1.27 [71.5 kB]

Get:4 http://mirrordirector.raspbian.org/raspbian/ jessie/main
python-defusedxml all 0.4.1-2 [35.5 kB]

Get:5 http://mirrordirector.raspbian.org/raspbian/ jessie/main python-roman
all 2.0.0-1 [7,898 B]

Get:6 http://mirrordirector.raspbian.org/raspbian/ jessie/main
docutils-common all 0.12+dfsg-1 [185 kB]

Get:7 http://mirrordirector.raspbian.org/raspbian/ jessie/main
python-docutils all 0.12+dfsg-1 [361 kB]

Get:8 http://mirrordirector.raspbian.org/raspbian/ jessie/main
python-wstools all 0.4.3-2 [141 kB]

Get:9 http://mirrordirector.raspbian.org/raspbian/ jessie/main python-soappy
all 0.12.22-1 [69.0 kB]

Get:10 http://mirrordirector.raspbian.org/raspbian/ jessie/main
python-debianbts all 1.12 [8,144 B]

Get:11 http://mirrordirector.raspbian.org/raspbian/ jessie/main
python-reportbug all 6.6.3 [126 kB]

Get:12 http://mirrordirector.raspbian.org/raspbian/ jessie/main reportbug
all 6.6.3 [123 kB]

Get:13 http://mirrordirector.raspbian.org/raspbian/ jessie/main docutils-doc
all 0.12+dfsg-1 [896 kB]

Get:14 http://mirrordirector.raspbian.org/raspbian/ jessie/main
libpaper-utils armhf 1.1.24+nmu4 [17.2 kB]

Get:15 http://mirrordirector.raspbian.org/raspbian/ jessie/main
python-pygments all 2.0.1+dfsg-1.1+deb8u1 [482 kB]

Fetched 2,701 kB in 11s (228 kB/s)

Preconfiguring packages ...

dpkg-deb: error while loading shared libraries: Libz.sm.1: cannot open
shared object file: No such file or directory

dpkg: error processing archive
/var/cache/apt/archives/libpaper1_1.1.24+nmu4_armhf.deb (--unpack):

subprocess dpkg-deb --control returned error exit status 127

dpkg-deb: error while loading shared libraries: Libz.sm.1: cannot open
shared object file: No such file or directory

dpkg: error processing archive
/var/cache/apt/archives/python-apt_0.9.3.12_armhf.deb (--unpack):

subprocess dpkg-deb --control returned error exit status 127

dpkg-deb: error while loading shared libraries: Libz.sm.1: cannot open
shared object file: No such file or directory

dpkg: error processing archive
/var/cache/apt/archives/python-debian_0.1.27_all.deb (--unpack):

subprocess dpkg-deb --control returned error exit status 127

dpkg-deb: error while loading shared libraries: Libz.sm.1: cannot open
shared object file: No such file or directory

dpkg: error processing archive
/var/cache/apt/archives/python-defusedxml_0.4.1-2_all.deb (--unpack):

subprocess dpkg-deb --control returned error exit status 127

dpkg-deb: error while loading shared libraries: Libz.sm.1: cannot open
shared object file: No such file or directory

dpkg: error processing archive
/var/cache/apt/archives/python-roman_2.0.0-1_all.deb (--unpack):

subprocess dpkg-deb --control returned error exit status 127

dpkg-deb: error while loading shared libraries: Libz.sm.1: cannot open
shared object file: No such file or directory

dpkg: error processing archive

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Package: flex
Version: 2.5.39-8+deb8u1
Severity: normal

After this update, I get the following warning when compiling the
flex generated code with gcc, which I didn't get before:

scan.cpp: In function ‘int yy_get_next_buffer(yyscan_t)’:
scan.cpp:758:18: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
scan.cpp:1384:3: note: in expansion of macro ‘YY_INPUT’

Looking at the code:

#define YY_INPUT(buf,result,max_size) \
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
size_t n; \
for ( n = 0; n < max_size && \

Invoked as:

int num_to_read = ...
YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
yyg->yy_n_chars, num_to_read );

So indeed an unsigned value (n) is compared with a signed one
(num_to_read). If this is correct, the warning can be silenced with
a cast of the appropriate one of them.

flex hasn't exactly been known for generating warning-free code,
but what really worries me is that this is a security update. Fixing
a security problem by introducing a sign-problem seems fishy to me.

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

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

Versions of packages flex depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  install-info   5.2.0.dfsg.1-6
ii  libc6  2.19-18+deb8u5
ii  libfl-dev  2.5.39-8+deb8u1
ii  m4 1.4.17-4

Versions of packages flex recommends:
ii  clang-3.5 [c-compiler]  1:3.5-10
ii  gcc [c-compiler]4:4.9.2-2
ii  gcc-4.8 [c-compiler]4.8.4-1
ii  gcc-4.9 [c-compiler]4.9.2-10

Versions of packages flex suggests:
ii  bison2:3.0.2.dfsg-2
ii  build-essential  11.7

-- no debconf information

Bug#832807: mate-accountsdialog: Mate-accountsdialog won't run on my updated AMD64 machine

[Frank McCormick]

Package: mate-accountsdialog
Version: 1.8.1-1
Severity: normal

Dear Maintainer,

I am running Debian Stretch/Sid on my 64 bit machine and
discovered a few days ago that mate-accountssdialog crashes
on startup. it complains about mixed GTK 2.0 and 3.0.

It seems the developer at Github has declared the package Obselete ???





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

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

Versions of packages mate-accountsdialog depends on:
ii  accountsservice 0.6.40-3
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.23-2
ii  libcairo2   1.14.6-1+b1
ii  libdbus-1-3 1.10.8-1
ii  libdbus-glib-1-20.106-1
ii  libfontconfig1  2.11.0-6.4
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.1-2
ii  libgtk2.0-0 2.24.30-4
ii  libmate-desktop-2-171.14.1-1
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1
ii  libpangoft2-1.0-0   1.40.1-1
ii  libpolkit-gobject-1-0   0.105-15
ii  libpolkit-gtk-mate-1-0  1.14.0-1
ii  libstartup-notification00.12-4
ii  libsystemd0 230-7
ii  libunique-1.0-0 1.1.6-5
ii  mate-accountsdialog-common  1.8.1-1

mate-accountsdialog recommends no packages.

mate-accountsdialog suggests no packages.

-- no debconf information

Bug#831594: nsupdate: key invalid after update to 1:9.9.5.dfsg-9+deb8u6: TSIG error with server

[frank]

Package: dnsutils
Version: 1:9.9.5.dfsg-9+deb8u6
Severity: normal

Dear Maintainer,


I have a dynamic dns setup as described here:

http://linux.yyz.us/dns/ddns-server.html

One client stopped working. As the DNS update only occurs if the IP
addresses are changing, it is not fully clear to what exactly caused
this. I tried to analyze the problem:

Client A running dnsutils 1:9.9.5.dfsg-9+deb8u6 cannot update bind9.
Client B running dnsutils 1:9.9.5.dfsg-9+deb8u5 can update bind9.

The bind9 server has the following versions installed:

bind9 1:9.9.5.dfsg-4~bpo70+1 
dnsutils 1:9.8.4.dfsg.P1-6+nmu2+deb7u10

The update script looks as follows:

#!/bin/sh

# ...

/usr/bin/nsupdate -k $KEY -v << EOF
server $NS
zone $ZONE
update delete $DOMAIN A
update add $DOMAIN 30 A $IPV4
send
EOF

The key was created with:

$ dnssec-keygen -a HMAC-SHA512 -b 512 -n USER host

and look like:


Private-key-format: v1.3
Algorithm: 165 (HMAC_SHA512)
Key: k...==
Created: 20160708155217
Publish: 20160708155217
Activate: 20160708155217


If I transfer copy script and key to client B it works ok.
On client A the script fails with:


; TSIG error with server: expected a TSIG or SIG(0)
update failed: NOTAUTH

I tried to look into the bind9 git

git://git.debian.org/~lamont/bind9.git,

but was not able to find the corresponding git hashes

Is this expected behaviour? Howto resolve the situation? 

kind regards
  Frank



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


-- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (990, '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)

Versions of packages dnsutils depends on:
ii  bind9-host [host]  1:9.9.5.dfsg-9+deb8u6
ii  libbind9-901:9.9.5.dfsg-9+deb8u6
ii  libc6  2.19-18+deb8u4
ii  libcap21:2.24-8
ii  libcomerr2 1.42.12-1.1
ii  libdns100  1:9.9.5.dfsg-9+deb8u6
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
ii  libisc95   1:9.9.5.dfsg-9+deb8u6
ii  libisccfg901:9.9.5.dfsg-9+deb8u6
ii  libk5crypto3   1.12.1+dfsg-19+deb8u2
ii  libkrb5-3  1.12.1+dfsg-19+deb8u2
ii  liblwres90 1:9.9.5.dfsg-9+deb8u6
ii  libssl1.0.01.0.1k-3+deb8u4
ii  libxml22.9.1+dfsg1-5+deb8u1

dnsutils recommends no packages.

Versions of packages dnsutils suggests:
pn  rblcheck  

-- no debconf information

Bug#828180: zsh: $RANDOM number generator is not reset for subshells

[Frank Terbeck]

Ben Longbons wrote:
> Dear Maintainer,

Hi Ben,

> Zsh just repeats the same number when $RANDOM is requested in fresh
> subshells. In general, this sort of bug is a security vulnerability,
> though I'm not aware of anyone doing security-sensitive stuff in zsh.

This works exactly as documented and is therefore not a bug:

RANDOM 
A  pseudo-random  integer  from 0 to 32767, newly generated each
time this parameter is referenced.  The random number  generator
can be seeded by assigning a numeric value to RANDOM.

The   values   of   RANDOM   form   an  intentionally-repeatable
pseudo-random sequence; subshells  that  reference  RANDOM  will
result  in  identical  pseudo-random  values unless the value of
RANDOM is referenced or seeded in the parent  shell  in  between
subshell invocations.

This comes up on zsh's mailing list every once in a while. Here is a
recent-ish thread: http://www.zsh.org/mla/workers/2015/msg00549.html

> bash handles this correctly in variables.c by checking
> `subshell_environment && seeded_subshell != pid` on every call and
> reseeding then; it would also be possible to use `pthread_atfork` (or,
> since the forking is entirely within the main executable, just the
> manual equivalent at the call site).

There is no standard that mandates how $RANDOM should behave. So this
boils down to "zsh is no bash".


Regards, Frank

Bug#824466: RFS: setop/0.1-1 [ITP]

[Frank Stähr]

control: tags -1 - moreinfo


Hello again!


Am 20.06.2016 um 13:08 schrieb Gianfranco Costamagna:

you gave me a good answer here, so, please add it again then (libboost-dev is 
fine
in this case!)


Ok.



There is a good reason, but I see that it is unnecessarily tortuous to
do so. That’s why everything under GPL-2+ now.



if you provide an explanation I can accept it, this is not about you being wrong
and me being right, it is about discussion and accept a common point of view :)


as I did above, I accepted your explanation and asked to restore your solution


Don’t worry, I didn’t feel urged to do so. As I said, I recently came to 
the conclusion that several copyrights instead of only one are 
unnecessarily tortuous.
(If you are interested: I originally wanted my Makefile not to be GPL so 
that others could use it absolutly free for their project. But in fact 
this Makefile is not so “brilliant” and that’s why it’s not worth the 
effort.)




we are talking about copyright in upstream tarball.
I can understand a symlink in debian/copyright, but shouldn't the upstream 
tarball
have a LICENSE file explaining the license text?


Ok.



I guess we are mostly ready now!


I hope everything is ok now.
Review is waiting for you!

Bug#824466: RFS: setop/0.1-1 [ITP]

[Frank Stähr]

Hello Gianfranco,

I think we are nearly ready, don’t give up.


Am 20.05.2016 um 21:59 schrieb Gianfranco Costamagna:

I deleted the dependence libboost-dev as suggested, ALTHOUGH I am not
sure if that is correct.
The documentation just says “This package provides headers.” Besides
regex and program-options I indeed need some other headers and now I
don’t know if these are installed for sure.



each sublibrary has its headers and its libraries, so you need just the minimum 
set
needed.


Nevertheless, I don’t see why e. g. boost/algorithm/string/trim.hpp is 
guaranteed to be installed. It might be a coincidence that it is 
included by regex or program-options. In my case e. g. libboost1.58-dev 
was automatically installed together with regex/program-options.

(But you do not need to explain. I just wanted to exclude an error.)



Changed the text according to the examples.



I still don't get why having two licenses.


There is a good reason, but I see that it is unnecessarily tortuous to 
do so. That’s why everything under GPL-2+ now.




you need a LICENSE file inside your tarball, with the license text inside,
otherwise the package will be probably rejected.


Really?
 says, 
common licenses may just be refered.




(BTW std-version is 3.9.8 now)


Ok.


Thx for all the work and your patience,
Frank

Bug#826572: Follow up on my earlier bug-report

[Frank B. Brokken]

Dear Anonio,

I'm somewhat confused. Earlier this week I noticed that mutt's pgp handling
stopped working given that my .muttrc contained configuration lines like 

set pgp_decrypt_command ="/usr/bin/gpg   --passphrase-fd 0 --no-verbose 
--quiet  --batch  --output - %f"

PGP could again be used after replacing those lines by 

set crypt_use_gpgme

But then I noticed that that line conflicted with mutt's S/MIME handling (for
which my .muttrc has comparable configuration lines). After commenting out the
'set crypt_use_gpgme' line S/MIME handling was working again. But I just
noticed that gpg-handling *also* seems to be working fine.

So:

Without 'set crypt_use_gpgme' and without explicit gpg-handling settings but
with S/MIME settings both S/MIME and GPG are apparently working fine. Maybe
the gpg-configuration lines are no longer required? I don't know, and this is
what somewhat confuses me. But since both appear to be working fine, I think
there's no real need for keeping bug report #826572 open. Assuming that I'm
not overlooking something trivial, then as far as I'm concerned it can be
closed: apologies for the confusion.

If you need any additional info from me, please let me know.

Cheers,
 
-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#826572: S/MIME: secret key not found when using gpgme

[Frank Brokken]

Package: mutt
Version: 1.6.0-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

After a mutt update the gpg configuration in .muttrc stopped working. Looking
for a solution I found the advice to specify 

set crypt_use_gpgme

instead. Although that did solve the gpg-problem, it also interfered with
S/MIME encryption. When trying to S/MIME sign a message I got the message

secret key 'xxx.f' not found: Invalid crypto engine?

Simply commenting out the 'set crypt_use_gpgme' configuration line re-allowed
me to use S/MIME signing again.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

1. removed the previous (now defunct) gpg-configuration in ~/.muttrc
2. inserted the line 'set crypt_use_gpgme'
3. in order to use S/MIME signing: comment out the 'set crypt_use_gpgme' line

   * What was the outcome of this action?

With the commented-out 'set crypt_use_gpgme' line S/MIME can be used, when
activating the coniguration line S/MIME can't be used; without the
coniguration line (and with the previously working PGP configuration lines)
GPG can't be used anymore.

   * What outcome did you expect instead?

I expected that replacing the PGP configuration lines by 'set crypt_use_gpgme'
would only affect GPG use, without interfering with using S/MIME. 

If you need any additional information, please let me know.


-- Package-specific info:
Mutt 1.6.0 (2016-04-01)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.5.0-2-amd64 (x86_64)
ncurses: ncurses 6.0.20160319 (compiled with 6.0)
libidn: 1.32 (compiled with 1.32)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-15' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with!
 -abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160421 (Debian 5.3.1-15) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch

Bug#826171: (no subject)

[Frank McCormick]

Subject: mate-panel:  todays updates break clock and weather 
Package: mate-panel
Version: 1.12.2-1
Severity: normal

Dear Maintainer,


Todays updates on Debian Stretch of mate-panel-applets removed the clock and 
weather
applets from mate-panel. Syslog reports some sort of conflict between
gtk2 and gtk3

Jun 2 14:57:32 peanut org.mate.panel.applet.ClockAppletFactory[3701]: 
(clock-applet:5614): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x 
and GTK+ 3 in the same process is not supported
Jun 2 14:57:32 peanut kernel: [ 1804.275974] traps: clock-applet[5614] trap 
int3 ip:7f93b48e2a6b sp:7ffea7fb4bb0 error:0
Jun 2 14:57:42 peanut org.mate.panel.applet.MateWeatherAppletFactory[3701]: 
(mateweather-applet:5627): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 
2.x and GTK+ 3 in the same process is not supported
Jun 2 14:57:42 peanut kernel: [ 1813.657936] traps: mateweather-app[5627] trap 
int3 ip:7f40eb831a6b sp:7ffee25833d0 error:0




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

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-9
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk0 0.30-3
ii  libcanberra0 0.30-3
ii  libdbus-1-3  1.10.8-1
ii  libdbus-glib-1-2 0.106-1
ii  libdconf10.26.0-1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgtk2.0-0  2.24.30-2
ii  libice6  2:1.0.9-1+b1
ii  libmate-desktop-2-17 1.12.1-1
ii  libmate-menu21.12.0-1
ii  libmate-panel-applet-4-1 1.12.2-1
ii  libmateweather1  1.14.0-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpangoft2-1.0-01.40.1-1
ii  librsvg2-2   2.40.15-1
ii  libsm6   2:1.2.2-1+b1
ii  libstartup-notification0 0.12-4
ii  libwnck222.30.7-5
ii  libx11-6 2:1.6.3-1
ii  libxau6  1:1.0.8-1
ii  libxrandr2   2:1.5.0-1
ii  mate-desktop 1.12.1-1
ii  mate-menus   1.12.0-1
ii  mate-panel-common1.12.2-1
ii  mate-polkit  1.14.0-1
ii  menu-xdg 0.5
ii  python   2.7.11-1

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#826072: alevt: Program table overflow

[Frank Heckenbach]

Package: dvb-apps
Version: 1.1.1+rev1500-1+fh1
Severity: normal
File: /usr/bin/alevt
Tags: patch

progtbl has a size of 16 (actually, only 15 are used due to the
check "progcnt >= sizeof(progtbl)/sizeof(progtbl[0])"; maybe this
should be ">", unless the last entry is needed as a terminator).

Anyway, one channel I receive (DE-Nuremberg, DVB-T, 78600 Hz,
Eurosport etc.) has a size of 17, so it's too small either way and
alevt aborts with the message given in the subject.

I don't know if there are official size limits, or whether there are
side-effects to my change, but for now, just increasing the size
seems to work for me.

The same code exists in the alevt package, may need to be patched
there, too.

--- util/alevt/vbi.c
+++ util/alevt/vbi.c
@@ -628,7 +628,7 @@
u_int8_t txttype;
u_int8_t txtmagazine;
u_int8_t txtpage;
-   } progtbl[16], *progp;
+   } progtbl[32], *progp;
u_int8_t tbl[4096];
u_int8_t * ppname, * psname, pncode, sncode, pnlen, snlen;
int r;

Bug#824466: RFS: setop/0.1-1 [ITP]

[Frank Stähr]

Package: sponsorship-requests
Severity: wishlist


Dear mentors,


I am looking for a sponsor for my package "setop":

 * Package name: setop
   Version : 0.1-1
   Upstream Author : Frank Stähr
 * URL : <http://github.com/phisigma/setop>
 * License : GPL-2+
   Section : utils


This mail is just for administration, as my last try didn’t open an RFS bug.

Bug#814438: stealth: FTBFS when built with dpkg-buildpackage -A (binary build with no binary artifacts)

[Frank B. Brokken]

Dear Santiago Vila, you wrote:
> tags 814438 + patch
> thanks
> 
> The following patch switches debian/rules to "dh" and also fixes this
> bug as a side effect.
> 
> Thanks.

Hi Santiago,

Muchas gracias por `el patch' ;-) 

I just applied your patch and fixed some typos in the upstream sources,
resulting in Stealth 4.01.05 and Debian version 4.01.05-1: the new version
closing 814438 should arrive shortly.

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#750138: scap-workbench

[Frank lin Piat]

[Sorry for the late response]

On mar., 2016-05-03 at 22:59 -0400, Greg Elin wrote:
> What is the difference between the collab-maint repo and the Alioth
> group?


An Alioth project is meant for a group of people to collaborate. Each
project has one or more repository (GIT/SVN/HG...), mailing list,
homepage...

On the other hand, collab-maint [Quoting https://wiki.debian.org/Glossa
ry ]
> Short for "collaborative maintenance"; [..] packages that don't
> belong to any particular team but would benefit from being team-
> maintained can just be added to the "collab-maint" project. 

Collab-maint provides no mailing list, no homepage, no group
membership, but's it's easier to setup.

Regards

Bug#823043: zsh FTBFS since yodl 3.08.00-1 in the same way that c++-annotations FTBFSed with 3.07.00-1 (was: Re: Bug#823043 closed by f.b.brok...@rug.nl (Frank B. Brokken) (Bug#823043: fixed in yodl 3

[Frank B. Brokken]

Dear Axel Beckert, you wrote:

> Hi Frank,

Hi Axel,

You wrote:

> I'm not 100% sure what's going on, but it seems to me that while
> c++-annotations indeed FTBFS with 3.07.00-1 and builds fine again with
> 3.08.00-1 (verified it :-), it's the opposite way round with zsh:
> 
> It builds fine with yodl 3.07.00-1, but FTBFS with 3.08.00-1 as
> follows:
> 
> ...Zsh Yodl-to-man converter
> Including file Zsh/zftpsys.yo
> yodl -k -L -o ../../Doc/zshzle.1 -I../../Doc:. -w zman.yo version.yo
> ../../Doc/zshzle.yo
> Zsh Yodl-to-man converter
> Including file Zsh/zle.yo
> yodl -k -L -o ../../Doc/zshall.1 -I../../Doc -DZSHALL -w zman.yo version.yo 
> zsh.yo
> `ZSHALL' (symbol) multiply defined
> `ZSHALL' (symbol) multiply defined
> `ZSHALL' (symbol) multiply defined
> Error(s) in command line arguments. Terminating
> ...

Thanks for reporting this bug: I just downloaded the zsh source package and
can reproduce the error. I'll have a look at what's going, and report back to
you once I know more.

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#750138: scap-workbench

[Frank lin Piat]

[CC'ing Pierre]

On sam., 2016-04-30 at 11:52 -0400, Klee Dienes wrote:
> I'd be happy to sponsor the package.  I noticed you have Pierre
> Chifflier  listed in the Uploaders: field ... is
> he already sponsoring the package?  If so I'll gladly defer.

Your offer is welcome and accepted, Pierre never had time to upload.

I suppose we could decide where to host the git repository before
uploading.
Do you think it's better to first use a "collab-maint" repo, or create
an Alioth group to collaborate on SCAP related stuff ?


> I took a quick look and came up with a few minor nits:
> [..]
> I pushed updates [..] to a fork on
> https://anonscm.debian.org/git/users/klee/scap-workbench.git

Thanks, merged

> I'm happy to collaborate on this and other similar projects.

I'll be happy to work on this with you,

Franklin

Bug#823093: zsh-common: Zsh config files are stored in /etc/zsh instead of /etc/zsh.d, which is more expected by users

[Frank Terbeck]

Hi,

Christopher Slojkowski wrote:
> Zsh files are stored in /etc/zsh, they should be stored in /etc/zsh.d instead.
> This is more consitant with other directories. I included a patch which makes
> the new folder, moves, and creates a symlink. There is proabably a better
> solution, but I just created a quick hack.

I disagree. Usually, the use of .d directories signifies that all files
from such a directory are being loaded by an application. That is not at
all the case with /etc/zsh.

Also, this is longstanding behaviour with the debian package and, as
far as I am concerned, this is not going to change.


Regards, Frank

Bug#823043: c++-annotations: FTBFS: `APATH' (symbol) multiply defined

[Frank B. Brokken]

Dear Chris Lamb, you wrote:
> Source: c++-annotations
> Version: 10.5.0-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> c++-annotations fails to build from source in unstable/amd64:

Hi Chris,

Thanks for your bug report. It looks like you encountered a real bug, and I'm
still somewhat in the dark as to why it never has been observed
before. Because of that (i.e., me satisfying my own curiosity) I'll need a bit
more time to submit a fix, but at least I think I've located the cause of the
problem. I'll probably have a fix ready by Monday or a bit earlier.

One minor thing: it's not an Annotations issue, but a bug in the Yodl
package. I suggest you (or Tony, or George, who receive CCs) reassign this
bug to yodl, since that's where the fix is required.

Thanks again,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#822519: bobcat: FTBFS: /usr/bin/yodl indicates failure

[Frank B. Brokken]

Dear Martin Michlmayr, you wrote:
> 
> Package: bobcat
> Version: 4.01.04-1
> Severity: serious
> 
> Hi Frank, here's a build failure of bobcat.  I don't know if it's a
> regression in yodl or if something has to change in bobcat, but in any
> case, bobcat fails to build from source in unstable (FTBFS):

Thanks again! I overlooked your e-mail, but I was informed by Tony about
it. It's the same issue as with bisonc++, and right now I'm preparing a fix,
which should be ready within the hour. 

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...

[Frank B. Brokken]

Dear Martin Michlmayr, you wrote:

> Yeah, that's the whole point of these archive rebuilds of unstable
> that various people in Debian do -- to rebuild everything in unstable
> and to catch build failures because of something changed in unstable
> (e.g. toolchain, libraries, other tools).

Agree 100%. And the fix is on its way :-)

Thanks again!

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...

[Frank B. Brokken]

Dear Martin Michlmayr, you wrote:

> Looks like Tony can reproduce it.  I just wanted to add briefly that
> this has nothing to do with HPE Helion.  It's a normal Debian
> installation and a normal Debian sid chroot using sbuild.

Oops, guys: OK, hold your fire: the flaw is at my side: I missed that Martin
already used yodl 3.07.01, and while reading Tony's mail I noticed that Tony
*did* use the latest Yodl version. When I do that too, I also reproduced the
error. So I think the bug can safely be reassigned to yodl, and I also think
it can quickly be fixed. 

Thanks for the quick reply, guys: I'll do my best to come up with the fix
equallly quick :-)

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...

[Frank B. Brokken]

Dear Martin Michlmayr, you wrote:
> 
> Package: bisonc++
> Version: 5.00.00-1
> Severity: serious
> 
> This package fails to build in unstable:
> 
> > sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
> ...
> > Yodl: including file algorithm/ruleprec.yo
> > Yodl: including file algorithm/condep.yo
> > Yodl: including file algorithm/reduce.yo
> > usage: [-a] [-N] [-n] [-s] [-t] [-S] [-T] marker file
> > See also: `man yodlverbinsert'
> > Yodl: including file algorithm/mysterious.yo
...
> > Fatal: system - failure of system call (status 256)
> > debian/rules:41: recipe for target 'build-indep' failed
> > make: *** [build-indep] Error 1
> 
> -- 
> Martin Michlmayr
> Linux for HPE Helion, Hewlett Packard Enterprise

Hi Martin,

Thanks for the bug report. Ususally a bug report provides me with clear hints
about its causes, but this time I'm at a loss. Building the manual on amd64
archs works OK, and I have no access to a HPE Helion machine, so it's hard to
reproduce the bug. 

I'm also wondering why the bug appears when yodl processes
algorithm/reduce.yo, and not earlier. E.g., the macro 'verbinsert' is called 
in documentation/manual/algorithm/reduce.yo, but before that in

examples/rpndecl.yo:verbinsert(//DECL)(rpn/parser/grammar)
examples/rpngram.yo:verbinsert(//RULES)(rpn/parser/grammar)
examples/errors.yo: verbinsert(//LINE)(errorcalc/parser/grammar)

and only then:

algorithm/reduce.yo:verbinsert(-as4)(examples/rr1)

But when used in reduce.yo another type of argument (-as4) is passed to
yodlverbinsert than in the other three cases, where a //XXX marker is used
(the short usage info displayed by yodlverbinsert suggests that a marker is
required, but that's not actually true, cf. yodlverbinsert's man-page).

There is of course a poor-man's solution: I build the documents and provide
the pre-built documents with the debian package. But it would be nice to know
why we get the FTBFS problem on the Helions. Maybe I could ask you to replace
line 7 ofdocumentation/manual/algorithm/reduce.yo

verbinsert(-as4)(examples/rr1)

by 

VERBOSITY()(0x4)
verbinsert(-as4)(examples/rr1)
VERBOSITY()(NONE)
 
and then run ./build manual in bisonc++'s base directory (where you also find
a file named CLASSES) and send me the output? That might provide a little
more info about what went wrong. 

For now, lacking access to a Helion machine, I'm afraid I have to ask you for
some help

Cheers,

[Cc: Tony/George]

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#822317: appstreamcli: double free or corruption

[Frank Green, Jr.]

Package: appstream
Version: 0.9.4-1
Followup-For: Bug #822317

I'm also getting similar issues as of recently. This is what happens when I run
aptitude update (also affects apt-get update):

root@frankjr-desktop:/home/frankjr# aptitude update
Ign http://dl.google.com/linux/chrome/deb stable InRelease
Hit http://dl.google.com/linux/chrome/deb stable Release
Hit http://repo.steampowered.com/steam precise InRelease
Hit http://ppa.launchpad.net/kxstudio-debian/ubuntus/ubuntu wily InRelease
Hit http://ftp.debian.org/debian sid InRelease
Hit http://ppa.launchpad.net/kxstudio-debian/ubuntus/ubuntu xenial InRelease
Ign http://kxstudio.linuxaudio.org/repo stable InRelease
Ign http://kxstudio.linuxaudio.org/repo gcc5 InRelease
Ign http://ppa.launchpad.net/kxstudio-debian/libs/ubuntu lucid InRelease
Hit http://kxstudio.linuxaudio.org/repo stable Release
Ign http://ppa.launchpad.net/kxstudio-debian/music/ubuntu lucid InRelease
Hit http://kxstudio.linuxaudio.org/repo gcc5 Release
Hit http://ppa.launchpad.net/kxstudio-debian/plugins/ubuntu lucid InRelease
Hit http://www.deb-multimedia.org sid InRelease
Ign http://ppa.launchpad.net/kxstudio-debian/apps/ubuntu lucid InRelease
Ign http://ppa.launchpad.net/kxstudio-debian/kxstudio/ubuntu lucid InRelease
Hit http://ppa.launchpad.net/kxstudio-debian/libs/ubuntu trusty InRelease
Ign http://ppa.launchpad.net/kxstudio-debian/music/ubuntu trusty InRelease
Hit http://ppa.launchpad.net/kxstudio-debian/plugins/ubuntu trusty InRelease
Hit http://ppa.launchpad.net/kxstudio-debian/apps/ubuntu trusty InRelease
Hit http://ppa.launchpad.net/kxstudio-debian/kxstudio/ubuntu trusty InRelease
Hit http://ppa.launchpad.net/kxstudio-debian/libs/ubuntu lucid Release
Hit http://ppa.launchpad.net/kxstudio-debian/music/ubuntu lucid Release
Hit http://ppa.launchpad.net/kxstudio-debian/apps/ubuntu lucid Release
Hit http://ppa.launchpad.net/kxstudio-debian/kxstudio/ubuntu lucid Release
Hit http://ppa.launchpad.net/kxstudio-debian/music/ubuntu trusty Release
99% [Working]*** Error in `appstreamcli': double free or corruption (fasttop):
0x0305cf10 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x71fe5)[0x7f49fcee1fe5]
/lib/x86_64-linux-gnu/libc.so.6(+0x77936)[0x7f49fcee7936]
/lib/x86_64-linux-gnu/libc.so.6(+0x7811e)[0x7f49fcee811e]
/usr/lib/x86_64-linux-
gnu/libappstream.so.3(as_component_complete+0x439)[0x7f49fde6d599]
/usr/lib/x86_64-linux-
gnu/libappstream.so.3(as_data_pool_update+0x44a)[0x7f49fde6e78a]
/usr/lib/x86_64-linux-
gnu/libappstream.so.3(as_cache_builder_refresh+0x1c2)[0x7f49fde63af2]
appstreamcli(ascli_refresh_cache+0x12e)[0x404a1e]
appstreamcli(as_client_run+0x6fb)[0x403d2b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f49fce90610]
appstreamcli(_start+0x29)[0x403559]
=== Memory map: 
0040-00408000 r-xp  08:22 1576759
/usr/bin/appstreamcli
00607000-00608000 r--p 7000 08:22 1576759
/usr/bin/appstreamcli
00608000-00609000 rw-p 8000 08:22 1576759
/usr/bin/appstreamcli
025e3000-0357c000 rw-p  00:00 0  [heap]
7f49e800-7f49e8021000 rw-p  00:00 0
7f49e8021000-7f49ec00 ---p  00:00 0
7f49ec00-7f49ec021000 rw-p  00:00 0
7f49ec021000-7f49f000 ---p  00:00 0
7f49f000-7f49f0021000 rw-p  00:00 0
7f49f0021000-7f49f400 ---p  00:00 0
7f49f7a16000-7f49f7a17000 ---p  00:00 0
7f49f7a17000-7f49f8217000 rw-p  00:00 0
7f49f8217000-7f49f8218000 ---p  00:00 0
7f49f8218000-7f49f8a18000 rw-p  00:00 0
7f49f8a18000-7f49f8a1a000 r-xp  08:22 4196623
/lib/x86_64-linux-gnu/libutil-2.22.so
7f49f8a1a000-7f49f8c19000 ---p 2000 08:22 4196623
/lib/x86_64-linux-gnu/libutil-2.22.so
7f49f8c19000-7f49f8c1a000 r--p 1000 08:22 4196623
/lib/x86_64-linux-gnu/libutil-2.22.so
7f49f8c1a000-7f49f8c1b000 rw-p 2000 08:22 4196623
/lib/x86_64-linux-gnu/libutil-2.22.so
7f49f8c68000-7f49f8c9f000 r-xp  08:22 1704900
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so
7f49f8c9f000-7f49f8e9f000 ---p 00037000 08:22 1704900
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so
7f49f8e9f000-7f49f8ea4000 r--p 00037000 08:22 1704900
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so
7f49f8ea4000-7f49f8ea5000 rw-p 0003c000 08:22 1704900
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so
7f49f8ea8000-7f49f8ed8000 r-xp  08:22 1835925
/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
7f49f8ed8000-7f49f90d8000 ---p 0003 08:22 1835925
/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
7f49f90d8000-7f49f90d9000 r--p 0003 08:22 1835925
/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
7f49f90d9000-7f49f90db000 rw-p 00031000 08:22 1835925
/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
7f49f90e-7f49f90e4000 r-xp  08:22 4194493
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f49f90e4000-7f49f92e3000 ---p 4000 08:22 4194493
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f49f92e3000-7f49f92e4000 r--p 3000 

Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes

[Frank Heckenbach]

Hi Martin,

> Thank you for your bug report!
> 
> Judging from the code that reproduces the bug (two subsequent seeks to 
> 0) and from the related vorbis code you are mentioning, this sounds a 
> lot like #782831, which was fixed in 1.3.4-3. Could you confirm or 
> refute that theory by testing your code (I guess you have further 
> examples apart from the one you posted) with 1.3.4-3?

1.3.4-3 isn't on the main server anymore, but luckily I recently
learned about snapshot.debian.org. It may be old news for you, but
for anyone else who may be reading this report and doesn't know
about it, I fetched the following two files and rebuilt them
(together with the origial libvorbis_1.3.4.orig.tar.gz from jessie).
I didn't try 1.3.5 yet as I want to change as little as possible in
the system.

http://snapshot.debian.org/archive/debian/20151001T033412Z/pool/main/libv/libvorbis/libvorbis_1.3.4-3.dsc
http://snapshot.debian.org/archive/debian/20151001T033412Z/pool/main/libv/libvorbis/libvorbis_1.3.4-3.debian.tar.xz

It did indeed fix the test case, and also my real case where I found
the problem. I'll do some more tests soon and report if I find more
problems, but I hope not.

Thanks,
Frank

Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes

[Frank Heckenbach]

Package: libvorbisfile3
Version: 1.3.4-2
Severity: important

ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes. I've
observed it in some situations, below is a very simple one to
reproduce. It's an important problem to me, because (unless fixed or
you can tell me exactly when seeking will work), I'd have to treat
all Ogg/Vorbis files as unseekable in my code, which would be a huge
performance penalty (decoding sequentially and buffering all in
memory).

% cat test.c
#include 
#include 

int main ()
{
  OggVorbis_File vf;
  fprintf (stderr, "%i\n", ov_fopen ("foo.ogg", ));
  fprintf (stderr, "%i\n", ov_pcm_seek (, 0));
  fprintf (stderr, "%i\n", ov_pcm_seek (, 0));
  return 0;
}
% head -c 10 /dev/zero|oggenc -Q -r - -o foo.ogg&& gcc -g test.c 
-lvorbisfile && ./a.out

On i386:
0
0
-2

On amd64:
0
0
Segmentation fault

I tried to debug it and found: The 2nd time ov_pcm_seek_is_called
(from the 2nd ov_pcm_seek call), at line 1461

  if(bisect!=vf->offset){
result=_seek_helper(vf,bisect);
if(result) goto seek_error;
  }

begin == 3997 and vf->offset == 3997, so the call to _seek_helper is
skipped. However, ftell((FILE*)vf->datasource) == 4076, so it goes
on with a wrong file position, so _get_next_page fails and og
remains unintialized and ogg_page_serialno() (line 1554) results
in UB.

I don't really understand the code: Telling from this line,
vf->offset should reflect the actual position of the data source.
But if so, I'd expect it to be adjusted after each successfull call
of seek_func (that's correctly done) and read_func. read_func is
only called from _get_data, but it doesn't adjust vf->offset.
Instead it puts the data into an internal buffer AFAIUI, so the
users of the data from the buffer are probably responsible for
adjusting vf->offset, but apparently something goes wrong there.

If I just set vf->offset to 4076 before line 1461 (2nd time), it
continues correctly. That's of course, not a fix, just an indication
that the wrong value of vf->offset is the real problem here.

Maybe vf->offset just needs to be revalidated before line 1461, but
it's used in many places, and I don't know how many of them might be
affected too.

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

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

Versions of packages libvorbisfile3:amd64 depends on:
ii  libc6  2.19-18+deb8u4
ii  libogg01.3.2-1
ii  libvorbis0a1.3.4-2
ii  multiarch-support  2.19-18+deb8u4

libvorbisfile3:amd64 recommends no packages.

libvorbisfile3:amd64 suggests no packages.

-- no debconf information

Bug#820592: fritzing-data: Fails to start parts editor

[Frank]

Package: fritzing-data
Version: 0.9.2b+dfsg-3
Severity: normal

Dear Maintainer,

if I select a part, e.g. a capacitor, and click on "Edit (new parts editor)" I
get the error message: "Unable to load fzp from
/usr/share/fritzing/pdb/core/capacitor_electrolytic_small.fzp".
If I download the same version of Fritzing from fritzing.org and try to do the
same again the parts editor starts without complaining.



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

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

-- no debconf information

Bug#820119: tidy reports valid NCR as invalid

[Frank Lichtenheld]

2016-04-06 18:52 GMT+02:00 victory <victory@gmail.com>:
> On Tue, 5 Apr 2016 20:16:53 +0200
> Frank Lichtenheld wrote:
>
>> I assume you wanted to report this against tidy, not www.debian.org?
>
> if so, I always report to the upstream, not the debian's one
>
> see https://www-master.debian.org/build-logs/tidy/
> files w/ 142bytes are caused by the issue
> (other langs do not have the page [international/l10n/po/pl])

Okay, that paragraph would have been helpful in the original mail to
understand the contexts of your statement.

Regards,
  Frank

-- 
Frank Lichtenheld <dj...@debian.org>

Bug#820119: tidy reports valid NCR as invalid

[Frank Lichtenheld]

2016-04-05 18:12 GMT+02:00 victory <victory@gmail.com>:
>
> Package: www.debian.org

I assume you wanted to report this against tidy, not www.debian.org?

> Severity: wishlist
>
> https://www.w3.org/International/questions/qa-controls#support
> HTML, XHTML and XML 1.0 do not support the C0 range,
> except for HT (Horizontal Tabulation) U+0009, LF (Line Feed) U+000A,
> and CR (Carriage Return) U+000D.
> The C1 range is supported, i.e. you can encode the controls directly
> or represent them as NCRs (Numeric Character References).
>
> *
> https://www.w3.org/International/questions/qa-controls#background
> The control codes in the range U+0080-U+009F are known as the "C1" range.
>
> unfortunately no option seems to eliminate this :(
> latest source use the same code (line 1165-)
> https://github.com/htacg/tidy-html5/blob/master/src/lexer.c
>
>
> --
> victory
> no need to CC me :-)
>


-- 
Frank Lichtenheld <dj...@debian.org>

Bug#762255: "collect DLAs on www.d.o"

[Frank Lichtenheld]

Package: www.debian.org
Followup-For: Bug #762255

Attached is a partial patch to implement DLAs.

As mentioned, I found the recent_list.wml code incomprehensible. So
I decided to refactor it completely. The result of this refactoring are
the attached files recent_list_security.wml and recent_list_common.wml.
As the filenames indicate, this is not a complete replacement, yet. So
far this only covers security, not News or events. But I think it already
demonstrates the value of the excercise.

Also attached is a dla parser script.

Feedback welcome.

Regards,
 Frank


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=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)
? 762255.patch
? crossreferences.en.html
? cve-compatibility.en.html
? dsa-long.en.rdf
? dsa.en.rdf
? faq.en.html
? index.en.html
? pam-auth.en.html
? parse-dla.pl
? ref-table.inc
Index: Makefile
===
RCS file: /cvs/webwml/webwml/english/security/Makefile,v
retrieving revision 1.70
diff -u -r1.70 Makefile
--- Makefile	10 Nov 2012 15:44:04 -	1.70
+++ Makefile	4 Apr 2016 20:45:25 -
@@ -12,10 +12,13 @@
 
 
 index.$(LANGUAGE).html: index.wml $(wildcard $(CUR_YEAR)/dsa-*.wml) \
+  $(wildcard $(CUR_YEAR)/dla-*.wml) \
   $(wildcard $(ENGLISHSRCDIR)/security/$(CUR_YEAR)/dsa-*.wml) \
   $(wildcard $(ENGLISHSRCDIR)/security/$(CUR_YEAR)/dsa-*.data) \
+  $(wildcard $(ENGLISHSRCDIR)/security/$(CUR_YEAR)/dla-*.wml) \
+  $(wildcard $(ENGLISHSRCDIR)/security/$(CUR_YEAR)/dla-*.data) \
   $(TEMPLDIR)/release_info.wml \
-  $(TEMPLDIR)/template.wml $(TEMPLDIR)/recent_list.wml $(GETTEXTDEP)
+  $(TEMPLDIR)/template.wml $(TEMPLDIR)/recent_list_security.wml $(GETTEXTDEP)
 
 pam-auth.$(LANGUAGE).html: pam-auth.wml \
   $(ENGLISHSRCDIR)/security/pam-auth.wml
@@ -52,7 +55,10 @@
   $(wildcard $(CUR_YEAR)/dsa-*.wml) \
   $(wildcard $(ENGLISHDIR)/security/$(CUR_YEAR)/dsa-*.wml) \
   $(wildcard $(ENGLISHDIR)/security/$(CUR_YEAR)/dsa-*.data) \
-  $(TEMPLDIR)/recent_list.wml $(GETTEXTDEP)
+  $(wildcard $(CUR_YEAR)/dla-*.wml) \
+  $(wildcard $(ENGLISHDIR)/security/$(CUR_YEAR)/dla-*.wml) \
+  $(wildcard $(ENGLISHDIR)/security/$(CUR_YEAR)/dla-*.data) \
+  $(TEMPLDIR)/recent_list_security.wml $(GETTEXTDEP)
 ifeq "$(LANGUAGE)" "zh"
 	@echo -n "Processing $(<F): "
 	$(shell echo $(WML) | perl -pe 's,:.zh-(..)\.html,:dsa.zh-$$1.rdf,g') \
@@ -68,7 +74,10 @@
   $(wildcard $(CUR_YEAR)/dsa-*.wml) \
   $(wildcard $(ENGLISHDIR)/security/$(CUR_YEAR)/dsa-*.wml) \
   $(wildcard $(ENGLISHDIR)/security/$(CUR_YEAR)/dsa-*.data) \
-  $(TEMPLDIR)/recent_list.wml $(GETTEXTDEP)
+  $(wildcard $(CUR_YEAR)/dla-*.wml) \
+  $(wildcard $(ENGLISHDIR)/security/$(CUR_YEAR)/dla-*.wml) \
+  $(wildcard $(ENGLISHDIR)/security/$(CUR_YEAR)/dla-*.data) \
+  $(TEMPLDIR)/recent_list_security.wml $(GETTEXTDEP)
 ifeq "$(LANGUAGE)" "zh"
 	@echo -n "Processing $(<F): "
 	$(shell echo $(WML) | perl -pe 's,:.zh-(..)\.html,:dsa-long.zh-$$1.rdf,g') \
Index: dsa-long.rdf.in
===
RCS file: /cvs/webwml/webwml/english/security/dsa-long.rdf.in,v
retrieving revision 1.6
diff -u -r1.6 dsa-long.rdf.in
--- dsa-long.rdf.in	30 Apr 2014 09:22:52 -	1.6
+++ dsa-long.rdf.in	4 Apr 2016 20:45:25 -
@@ -1,4 +1,4 @@
-#use wml::debian::recent_list
+#use wml::debian::recent_list_security
 
 
 
@@ -21,11 +21,11 @@
   <:= rdf_ctime(); :>
   
 
-<:= get_recent_list ( '1m', '6', '$(ENGLISHDIR)/security', 'rdfseq bydate', 'dsa-\d+' ); :>
+<:= get_recent_security_list_rdf('rdfseq', '1m', '6', '.', '$(ENGLISHDIR)/security' ); :>
 
   
 
 
-<:= get_recent_list ( '1m', '6', '$(ENGLISHDIR)/security', 'rdflong bydate', 'dsa-\d+' ); :>
+<:= get_recent_security_list_rdf('rdf-long', '1m', '6', '.', '$(ENGLISHDIR)/security' ); :>
 
 
Index: dsa.rdf.in
===
RCS file: /cvs/webwml/webwml/english/security/dsa.rdf.in,v
retrieving revision 1.10
diff -u -r1.10 dsa.rdf.in
--- dsa.rdf.in	30 Apr 2014 09:22:52 -	1.10
+++ dsa.rdf.in	4 Apr 2016 20:45:25 -
@@ -1,4 +1,4 @@
-#use wml::debian::recent_list
+#use wml::debian::recent_list_security
 
 
 
@@ -21,11 +21,11 @@
   <:= rdf_ctime(); :>
   
 
-<:= get_recent_list ( '1m', '6', '$(ENGLISHDIR)/security', 'rdfseq bydate', 'dsa-\d+' ); :>
+<:= get_recent_security_list_rdf( 'rdfseq', '1m', '6', '.', '$(ENGLISHDIR)/security' ); :>
 
   
 
 
-<:= get_recent_list ( '1m', '6', '$(ENGLISHDIR)/security', 'rdf bydate', 'dsa-\d+' ); :>
+<:= get_recent_security_list_rdf( 'rdf', '1m', '6', '.', '$(ENGLISHDIR)/security' ); :>
 
 
Index: index.wml

Bug#720745: [www.debian.org] Support - On-line Real Time Help Using IRC: Please mention OFTC WebChat

[Frank Lichtenheld]

Package: www.debian.org
Followup-For: Bug #720745

Please find a proposed patch attached.

Feedback welcome.

Regards,
  Frank

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=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)
Index: support.wml
===
RCS file: /cvs/webwml/webwml/english/support.wml,v
retrieving revision 1.72
diff -u -r1.72 support.wml
--- support.wml	30 Apr 2014 07:41:18 -	1.72
+++ support.wml	2 Apr 2016 19:45:21 -
@@ -191,7 +191,7 @@
 http://www.irchelp.org/;>IRC (Internet Relay Chat) is a way
 to chat with people from all over the world in real time.
 IRC channels dedicated to Debian can be found on
-http://www.oftc.net/;>OFTC.
+https://www.oftc.net/;>OFTC.
 
 To connect, you need an IRC client. Some of the most popular clients are
 https://packages.debian.org/stable/net/xchat;>XChat,
@@ -200,7 +200,11 @@
 https://packages.debian.org/stable/net/epic5;>epic5 and
 https://packages.debian.org/stable/net/kvirc;>KVIrc,
 all of which have been packaged for
-Debian. Once you have the client installed, you need to tell it to connect
+Debian. OFTC also offers a https://www.oftc.net/WebChat/;>WebChat
+web interface which allows you to connect to IRC with a browser without
+the need to install any local client.
+
+Once you have the client installed, you need to tell it to connect
 to the server. In most clients, you can do that by typing:
 
 

Bug#819778: songwrite: outdated homepage link

[Frank Dietrich]

Package: songwrite
Version: 0.14-10
Severity: minor
Tags: patch

Dear Maintainer,

in the package description as homepage is named
http://home.gna.org/oomadness/en/songwrite/

on top of that webpage it's mentioned that a new URL
exists

http://www.lesfleursdunormal.fr/static/informatique/songwrite/index_en.html

kind regards
Frank



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

Kernel: Linux 4.4.0-1-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)

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> On 28 March 2016 at 12:18, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote:
> > Felipe Sateler wrote:
> >
> >> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.
> >> Could you please upgrade to that version and try using the
> >> After=swap.target workaround?
> >
> > Actually, I'm not sure if it works. I could not reproduce the bug
> > now (but it wasn't 100% reproducible anyway).
> >
> > However, "systemd-analyze blame" still shows tmp.mount started
> > before the swap targets. Is this not the right tool to check? Any
> > other way to check the order dependencies systemd actually uses, so
> > I can positively verify that it does things in the correct order and
> > it wasn't just lucky timing?
> 
> You can check `systemctl list-dependencies --after tmp.mount`

OK, this confirms it works correctly.

> >> If it works, then using
> >> overcommit_memory would require adding the After= snippet, and this
> >> bug could be turned into a documentation bug (but where?).
> >
> > It doesn't really depend on overcommit_memory. You get the bug also
> > with tmpfs usage larger than physical RAM. So if that's the
> > solution, "After=swap.target" should always be there, i.e. in the
> > tmp.mount as installed.
> >
> > Or is there any case where swapoff needs to be before umount /tmp?
> > The only possibility I could imagine, in the spirit of
> > https://bugzilla.redhat.com/show_bug.cgi?id=1031158, is when a swap
> > file is in a tmpfs, but that's just silly. ;) So I think in most
> > cases, the order doesn't matter, and if it does, umount before
> > swapoff is correct. So it shouldn't hurt to always do the ordering.
> 
> This makes sense to me, but I'll defer to others (in particular, this
> is probably something best brought up upstream).

https://github.com/systemd/systemd/issues/2930

Regards,
Frank

Bug#762255: Some thoughts

[Frank Lichtenheld]

Hi.

I actually started looking into this today to see how much work it would be.

Some findings:

Writing a parser for DLAs is pretty simple, you can reuse a lot of the
stuff in parse-advisory.pl. If someone is interested, I can provide
the code.

The fun starts when you generate index.wml files. My thought was that
DSAs and DLAs should be mixed together since creating a completely
separate listing for them sounds silly. But it turns out that DSAs are
sorted by number and not by date (why, oh why?) and to change that you
actually need to touch get_recent_list
(english/templates/debian/recent_list.wml). This function is used
everywhere and has a lot of different calling conventions and a lot of
weird special handling and is just a horror to touch.

Maybe I will find some more motivation to look into it on the weekend.

Regards,
  Frank

Bug#756397: Add or replace

[Frank Lichtenheld]

I was wondering how to proceed with this bug.

Does it make sense to replace the PTS link with the tracker link or
should both be present?

Regards,
-- 
Frank Lichtenheld <dj...@debian.org>

Bug#594868: Still applies

[Frank Lichtenheld]

On Wed, 30 Mar 2016 01:52:40 +0200 Frank Lichtenheld <dj...@debian.org> wrote:
> This bug still applies.
> A more recent example would be
> https://packages.debian.org/jessie-backports/libapache2-mod-security2
>
> It depends on apache2-api-20120211 which is provided in jessie, but
> the page in jessie-backports doesn't reflect that.

I looked a bit further into this. It basically boils down to the
horrible function Packages::Search::read_entry_simple() which is much
too terse and too cryptic in its return value. It should be completely
reimplemented. Which is not that bad since it is only used in two
places in the code anyway.

Regards,
  Frank

-- 
Frank Lichtenheld <dj...@debian.org>

Bug#594868: Still applies

[Frank Lichtenheld]

This bug still applies.
A more recent example would be
https://packages.debian.org/jessie-backports/libapache2-mod-security2

It depends on apache2-api-20120211 which is provided in jessie, but
the page in jessie-backports doesn't reflect that.

-- 
Frank Lichtenheld <dj...@debian.org>

Bug#616654: p.d.o: untranslatable top menu

[Frank Lichtenheld]

On Wed, 08 Apr 2015 01:28:12 +0200 Laura Arjona Reina
<larj...@larjona.net> wrote:
> Dear all
> I'm not sure about the status of this bug...
>
> https://packages.debian.org/en/wheezy/ for example, shows that the page
> is available in several other languages, but when I click on them (for
> example https://packages.debian.org/fr/wheezy/ ), I still see the page
> in English.
>
> I've reviewed
> https://anonscm.debian.org/cgit/webwml/packages.git/tree/templates/html/head.tmpl
> and I cannot see the lines corresponding to the titles, nor translatable
> nor untranslatable.
>
> OTOH, I'm Spanish translator and the Spanish language is not shown in
> the list of available languages. I would like to provide translations to
> fix that, but I'm not sure how to proceed, where are the current
> templates, in which branch should I commit...

FTR, the correct solution was to merge all the translation relevant
changes to master which I did now.

debian-master was really only intended for debian deployment related
changes that are not relevant for people hosting their own instance.

Will apply the patch to master.

Regards,
-- 
Frank Lichtenheld <dj...@debian.org>

Bug#815202: packages: machines and sponsors information is outdated

[Frank Lichtenheld]

On Sat, 20 Feb 2016 09:26:23 +0800 Paul Wise <p...@debian.org> wrote:
> Package: www.debian.org
> Severity: minor
> User:Â www.debian@packages.debian.org
> Usertags: packages
>
> The packages site says the two packages mirrors are piatti and rore but
> these were decommissioned a long time ago. It would be best to generate
> the machines and sponsors info from Debian LDAP on a regular basis so
> that this information never gets out of date. Some combination of
> the description, purpose, sponsor and allowedGroups LDAP fields should
> be enough to find the right hosts and display the right info. picconi
> and pkgmirror-1and1 are the current hosts for this service.

Patches welcome ;)

-- 
Frank Lichtenheld <dj...@debian.org>

Bug#790774: Not reproducable on my test instance

[Frank Lichtenheld]

I can reproduce this issue fine on packages.debian.org, but not my
test instance.

So I assume this comes from some obsolete files not cleaned up
correctly (probably due to the Contents move)

When we roll out all my changes in did in the last two days I will ask
for archive/ to be purged once. Hopefully this will fix this issue.

Regards,
  Frank

-- 
Frank Lichtenheld <dj...@debian.org>

Bug#814677: Not reproducable in my test instance

[Frank Lichtenheld]

I can reproduce this issue fine on packages.debian.org, but not my
test instance.

So I assume this comes from some obsolete files not cleaned up
correctly (probably due to the Contents move)

When we roll out all my changes in did in the last two days I will ask
for archive/ to be purged once. Hopefully this will fix this issue.

Regards,
  Frank

Bug#819415: [pkg-php-pear] Bug#819420: php-seclib: Call to undefined method Crypt_Base::Crypt_Base()

[Frank Jung]

As suggested, I downgraded to php-seclib version 1.0.1-2, and
restarted lighttpd.

Error no longer appears.

Full log of lighttpd errors:

using version 1.0.1-3
2016-03-28 22:44:14: (log.c.194) server started
2016-03-28 22:44:20: (mod_fastcgi.c.2520) FastCGI-stderr: PHP Fatal
error:  Call to undefined method Crypt_Base::Crypt_Base() in
/usr/share/php/Crypt/Rijndael.php on line 269
2016-03-28 22:55:20: (server.c.1572) server stopped by UID = 0 PID = 1

using version 1.0.1-2
2016-03-29 08:49:00: (log.c.194) server started
2016-03-29 08:49:03: (mod_fastcgi.c.2520) FastCGI-stderr: PHP Warning:
 Invalid argument supplied for foreach() in
/usr/share/dokuwiki/lib/exe/js.php on line 79
2016-03-29 08:49:03: (mod_fastcgi.c.2520) FastCGI-stderr: PHP Warning:
 Invalid argument supplied for foreach() in
/usr/share/dokuwiki/lib/exe/css.php on line 86
2016-03-29 08:49:03: (mod_fastcgi.c.2520) FastCGI-stderr: PHP Warning:
 Invalid argument supplied for foreach() in
/usr/share/dokuwiki/lib/exe/css.php on line 86

- frank


On 29 March 2016 at 00:55, David Prévot <da...@tilapin.org> wrote:
> Hi,
>
> Thank you for your report.
>
> CCing Perpetuum who reported a similar issue in #819415, and Mathieu who
> uploaded php-seclib 1.0.1-3.
>
> Le 28/03/2016 07:31, Frank Jung a écrit :
>> Package: php-seclib
>> Version: 1.0.1-3
>
>> Loading Dokuwiki running on lighttpd reported a 500 "The localhost page isn’t
>> working" error. Looking into lighttpd logs I see in error.log
>>
>> (mod_fastcgi.c.2520) FastCGI-stderr: PHP Fatal error:  Call to undefined 
>> method
>> Crypt_Base::Crypt_Base() in /usr/share/php/Crypt/Rijndael.php on line 269
>
> I guess the “Fix Methods with the same name as their class” is
> incomplete, can you please roll back to 1.0.1-2 and comment if it fixes
> the issue for you.
>
> Regards
>
> David
>



-- 
- frankhj...@linux.com

Bug#819462: httpredir doesn't work for mips64el

[Frank Lichtenheld]

Package: mirrors
Severity: important
User: mirr...@packages.debian.org 
Usertags: httpredir

$ wget -nv -S --spider 
http://httpredir.debian.org/debian/dists/sid/main/binary-mips64el/Packages.xz 
2>&1 | head -n 1
  HTTP/1.1 503 Service Unavailable
$ wget -nv -S --spider 
http://ftp.de.debian.org/debian/dists/sid/main/binary-mips64el/Packages.xz 2>&1 
| head -n 1
  HTTP/1.1 200 OK

Maybe also affects some other new architectures, but haven't tested that, yet.

Regards,
  Frank

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

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

Bug#818761: packages.debian.org doesn't list experimental packages anymore

[Frank Lichtenheld]

Package: www.debian.org
Followup-For: Bug #818761

I've prepared a patch for this. Please find it attached.

I don't just want to push it though, since it would be good to clean
up the archive/ directory on packages.debian.org. So it would be
preferable that someone with access to the deployment merges it and
then takes care of the deployment immediately.

Regards,
  Frank


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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)
>From 63322b969c931107c3d26d3e9c8b1b24a41b7da5 Mon Sep 17 00:00:00 2001
From: Frank Lichtenheld <fr...@lichtenheld.de>
Date: Mon, 28 Mar 2016 20:21:12 +0200
Subject: [PATCH] Teach packages.debian.org to handle .xz archive files

Currently only for main archive, not backports or
debports, yet.
Crude mix of autodetection and configuration but
since at least experimental is completely broken
right now my priority was to get it working.

Closes: #818761
---
 bin/parse-packages| 38 ++
 bin/parse-sources | 35 ---
 config.sh.sed.in  |  4 
 cron.d/100syncarchive | 33 +
 4 files changed, 91 insertions(+), 19 deletions(-)

diff --git a/bin/parse-packages b/bin/parse-packages
index a7403a9..280adaf 100755
--- a/bin/parse-packages
+++ b/bin/parse-packages
@@ -63,6 +63,37 @@ mkpath( "$DBDIR/xapian.new" );
 my %descriptions_english_db;
 tie %descriptions_english_db, "DB_File", "files/db/descriptions_translated_english_only.db", O_RDONLY, 0666, $DB_BTREE;
 
+my %ext_to_prog = (
+xz => 'xzcat',
+gz => 'zcat',
+);
+sub open_packages_files {
+my( $suite_dir, $component) = @_;
+
+my (@files, $prog);
+for my $ext (qw(xz gz)){
+	my $packages_match = "binary-*/Packages.$ext";
+	@files = ();
+	push @files, <"$suite_dir/$component/$packages_match">;
+	push @files, <"$suite_dir/updates/$component/$packages_match">;
+	push @files, <"$suite_dir/$component/debian-installer/$packages_match">;
+
+	if( @files ){
+	$prog = $ext_to_prog{$ext};
+	last;
+	}
+}
+
+if( @files && $prog ){
+	print "\tprog=$prog\n";
+	print "\tfiles=@files\n";
+	open my $fh, '-|', $prog, @files;
+	return $fh;
+}
+print "\tno files found, skipping...\n";
+return;
+}
+
 for my $suite (@SUITES) {
 my %package_names_suite = ();
 my %packages_all_db;
@@ -76,10 +107,9 @@ for my $suite (@SUITES) {
 print "\tseems not to exist, skipping...\n";
 next;
 }
-	open PKG, "zcat $TOPDIR/archive/$archive/$suite/$what/binary-*/Packages.gz"
-	. " $TOPDIR/archive/$archive/$suite/updates/$what/binary-*/Packages.gz"
-	. " $TOPDIR/archive/$archive/$suite/$what/debian-installer/binary-*/Packages.gz|";
-	while () {
+
+	my $fh = open_packages_files("$TOPDIR/archive/$archive/$suite/", $what) || next;
+	while (<$fh>) {
 		next if /^\s*$/;
 		my $data = "";
 		my %data = ();
diff --git a/bin/parse-sources b/bin/parse-sources
index 1f73bcc..a4e6d06 100755
--- a/bin/parse-sources
+++ b/bin/parse-sources
@@ -38,6 +38,36 @@ $/ = "";
 
 -d $DBDIR || mkpath( $DBDIR );
 
+my %ext_to_prog = (
+xz => 'xzcat',
+gz => 'zcat',
+);
+sub open_sources_files {
+my( $suite_dir, $component) = @_;
+
+my (@files, $prog);
+for my $ext (qw(xz gz)){
+	my $sources_match = "source/Sources.$ext";
+	@files = ();
+	push @files, <"$suite_dir/$component/$sources_match">;
+	push @files, <"$suite_dir/updates/$component/$sources_match">;
+
+	if( @files ){
+	$prog = $ext_to_prog{$ext};
+	last;
+	}
+}
+
+if( @files && $prog ){
+	print "\tprog=$prog\n";
+	print "\tfiles=@files\n";
+	open my $fh, '-|', $prog, @files;
+	return $fh;
+}
+print "\tno files found, skipping...\n";
+return;
+}
+
 for my $archive (@ARCHIVES) {
 for my $suite (@SUITES) {
 
@@ -51,9 +81,8 @@ for my $archive (@ARCHIVES) {
 		print "\tseems not to exist, skipping...\n";
 		next;
 	}
-	open PKG, "zcat $TOPDIR/archive/$archive/$suite/$what/source/Sources.gz"
-	. " $TOPDIR/archive/$archive/$suite/updates/$what/source/Sources.gz|";
-	while () {
+	my $fh = open_sources_files("$TOPDIR/archive/$archive/$suite/", $what) || next;
+	while (<$fh>) {
 		next if /^\s*$/;
 		my $data = "";
 		my %data = ();
diff --git a/config.sh.sed.in b/config.sh.sed.in
index 10970d2..03ffc31 100644
--- a/config.sh.sed.in
+++ b/config.sh.sed.in
@@ -6

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

Felipe Sateler wrote:

> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.
> Could you please upgrade to that version and try using the
> After=swap.target workaround?

Actually, I'm not sure if it works. I could not reproduce the bug
now (but it wasn't 100% reproducible anyway).

However, "systemd-analyze blame" still shows tmp.mount started
before the swap targets. Is this not the right tool to check? Any
other way to check the order dependencies systemd actually uses, so
I can positively verify that it does things in the correct order and
it wasn't just lucky timing?

> If it works, then using
> overcommit_memory would require adding the After= snippet, and this
> bug could be turned into a documentation bug (but where?).

It doesn't really depend on overcommit_memory. You get the bug also
with tmpfs usage larger than physical RAM. So if that's the
solution, "After=swap.target" should always be there, i.e. in the
tmp.mount as installed.

Or is there any case where swapoff needs to be before umount /tmp?
The only possibility I could imagine, in the spirit of
https://bugzilla.redhat.com/show_bug.cgi?id=1031158, is when a swap
file is in a tmpfs, but that's just silly. ;) So I think in most
cases, the order doesn't matter, and if it does, umount before
swapoff is correct. So it shouldn't hurt to always do the ordering.

Regards,
Frank

Bug#819420: php-seclib: Call to undefined method Crypt_Base::Crypt_Base()

[Frank Jung]

Package: php-seclib
Version: 1.0.1-3
Severity: normal
Tags: newcomer

Dear Maintainer,

   * What led up to the situation?

Loading Dokuwiki running on lighttpd reported a 500 "The localhost page isn’t
working" error. Looking into lighttpd logs I see in error.log

(mod_fastcgi.c.2520) FastCGI-stderr: PHP Fatal error:  Call to undefined method
Crypt_Base::Crypt_Base() in /usr/share/php/Crypt/Rijndael.php on line 269

   * What exactly did you do (or not do) that was effective (or ineffective)?

Restarting lighttpd service.

   * What was the outcome of this action?

This had no effect, error still reported in lighttpd error logs.




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

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

Versions of packages php-seclib depends on:
ii  php-common  1:35

php-seclib recommends no packages.

Versions of packages php-seclib suggests:
pn  php-compat  
pn  php-gmp 
pn  php-mcrypt  

-- no debconf information

Bug#819350: Workaround

[Frank Lichtenheld]

FWIW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819083;mbox=yes works.

Downloads is 49 MB, though.

Regards,
  Frank

Bug#782740: bugs.debian.org: broken link in "Changed bug forwarded-to-address" message

[Frank Lichtenheld]

Package: bugs.debian.org
Followup-For: Bug #782740

I've prepared a patch for this. The patch doesn't touch the regex in
Bugreport.pm since that is difficult to test. Instead it changes
some strings in Control.pm to include a '.' at the end of the
string to make them consistent with all other control messages.
This makes the regex from Bugreport.pm match correctly.

Obviously this will only fix new instances of the issue, not
retroactively fix all the instances from past bugs.

The patch also includes a test case. This part of the patch depends
on my patch from #767327.

Regards,
  Frank

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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)
>From cfd18704f92efde38d5cbe0615fa84774dd57d24 Mon Sep 17 00:00:00 2001
From: Frank Lichtenheld <fr...@lichtenheld.de>
Date: Sun, 27 Mar 2016 17:01:46 +0200
Subject: [PATCH] Control: Add missing full stop at the end of "Changed"
 messages

This leads to broken links for at least the forwarded-to case.
(Closes: #782740)
---
 Debbugs/Control.pm | 6 +++---
 t/07_bugreport.t   | 6 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/Debbugs/Control.pm b/Debbugs/Control.pm
index 44d0062..36c416f 100644
--- a/Debbugs/Control.pm
+++ b/Debbugs/Control.pm
@@ -1116,7 +1116,7 @@ sub set_submitter {
 	}
 	else {
 	if (defined $data->{originator} and length($data->{originator})) {
-		$action= "Changed $config{bug} submitter to '$param{submitter}' from '$data->{originator}'";
+		$action= "Changed $config{bug} submitter to '$param{submitter}' from '$data->{originator}'.";
 		$notify_old_submitter = 1;
 	}
 	else {
@@ -1231,7 +1231,7 @@ sub set_forwarded {
 		$action= "Unset $config{bug} forwarded-to-address";
 	}
 	elsif (defined $data->{forwarded} and length($data->{forwarded})) {
-		$action= "Changed $config{bug} forwarded-to-address to '$param{forwarded}' from '$data->{forwarded}'";
+		$action= "Changed $config{bug} forwarded-to-address to '$param{forwarded}' from '$data->{forwarded}'.";
 	}
 	else {
 		$action= "Set $config{bug} forwarded-to-address to '$param{forwarded}'.";
@@ -1316,7 +1316,7 @@ sub set_title {
 	}
 	else {
 	if (defined $data->{subject} and length($data->{subject})) {
-		$action= "Changed $config{bug} title to '$param{title}' from '$data->{subject}'";
+		$action= "Changed $config{bug} title to '$param{title}' from '$data->{subject}'.";
 	} else {
 		$action= "Set $config{bug} title to '$param{title}'.";
 	}
diff --git a/t/07_bugreport.t b/t/07_bugreport.t
index 80dfc92..78d89b1 100644
--- a/t/07_bugreport.t
+++ b/t/07_bugreport.t
@@ -1,7 +1,7 @@
 # -*- mode: cperl;-*-
 
 
-use Test::More tests => 14;
+use Test::More tests => 16;
 
 use warnings;
 use strict;
@@ -101,6 +101,10 @@ my @control_commands =
 			 value   => 'https://foo.invalid/bugs?id=1',
 			 regex   => qr{Set bug forwarded-to-address to https://foo\.invalid/bugs\?id=1;>https://foo\.invalid/bugs\?id=1\.},
 			},
+  forwarded_foo_2=> {command => 'forwarded',
+			 value   => 'https://foo.example/bugs?id=1',
+			 regex   => qr{Changed bug forwarded-to-address to https://foo\.example/bugs\?id=1;>https://foo\.example/bugs\?id=1 from https://foo\.invalid/bugs\?id=1;>https://foo\.invalid/bugs\?id=1\.},
+			},
   clone=> {command => 'clone',
 		   value   => '-1',
 		   regex   => qr{Bug 1 cloned as bug 2},
-- 
2.1.4

Bug#767327: b.d.o: wrong package links in "reassigned" message

[Frank Lichtenheld]

Package: bugs.debian.org
Followup-For: Bug #767327

I've prepared a testcase and a patch for the issue.

Please see the attached commits.

Regards,
  Frank

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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)
>From c6904460b23cb1e80987624dca932b959fb4d6b2 Mon Sep 17 00:00:00 2001
From: Frank Lichtenheld <fr...@lichtenheld.de>
Date: Sun, 27 Mar 2016 15:24:15 +0200
Subject: [PATCH 1/2] Extend bugreport test cases to check the output of some
 control messages

This exposes #767327 (wrong package links in "reassigned" message)
as a test failure.
---
 t/07_bugreport.t | 41 +++--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/t/07_bugreport.t b/t/07_bugreport.t
index 3600e1c..80dfc92 100644
--- a/t/07_bugreport.t
+++ b/t/07_bugreport.t
@@ -1,7 +1,7 @@
 # -*- mode: cperl;-*-
 
 
-use Test::More tests => 8;
+use Test::More tests => 14;
 
 use warnings;
 use strict;
@@ -90,7 +90,44 @@ print STDERR $mech->content();
 ok($mech->content() !~ qr/[\x01\x02\x03\x05\x06\x07]/i,
'No unescaped states');
 
-
+# now test the output of some control commands
+my @control_commands =
+ (
+  reassign_foo => {command => 'reassign',
+		   value   => 'bar',
+		   regex => qr{bug reassigned from package foo to bar},
+		  },
+  forwarded_foo  => {command => 'forwarded',
+			 value   => 'https://foo.invalid/bugs?id=1',
+			 regex   => qr{Set bug forwarded-to-address to https://foo\.invalid/bugs\?id=1;>https://foo\.invalid/bugs\?id=1\.},
+			},
+  clone=> {command => 'clone',
+		   value   => '-1',
+		   regex   => qr{Bug 1 cloned as bug 2},
+		  },
+ );
+
+while (my ($command,$control_command) = splice(@control_commands,0,2)) {
+  # just check to see that control doesn't explode
+  $control_command->{value} = " $control_command->{value}" if length $control_command->{value}
+and $control_command->{value} !~ /^\s/;
+  send_message(to => 'control@bugs.something',
+	   headers => [To   => 'control@bugs.something',
+			   From => 'foo@bugs.something',
+			   Subject => "Munging a bug with $command",
+			  ],
+	   body => <<EOF) or fail 'message to control@bugs.something failed';
+debug 10
+$control_command->{command} 1$control_command->{value}
+thanks
+EOF
+  ;
+  # Now test that the output has changed accordingly
+  $mech->get_ok('http://localhost:'.$port.'/?bug=1',
+		'Page received ok');
+  like($mech->content(), $control_command->{regex},
+   'Page matches regex');
+}
 
 # Other tests for bugs in the page should be added here eventually
 
-- 
2.1.4

>From 6176d46de938ccb848b14ed8ca1098313bf7678f Mon Sep 17 00:00:00 2001
From: Frank Lichtenheld <fr...@lichtenheld.de>
Date: Sun, 27 Mar 2016 15:26:20 +0200
Subject: [PATCH 2/2] Bugreport: Fix problems with reassign message

* Matched hardcoded "Bug" instead of $config{bug} (which leads
  to problems at least in the test suite)
* Use package_links() wrong. package_links() already adds HTML.
  (Closes: #767327)
---
 Debbugs/CGI/Bugreport.pm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Debbugs/CGI/Bugreport.pm b/Debbugs/CGI/Bugreport.pm
index b1be2ed..8ebbfe8 100644
--- a/Debbugs/CGI/Bugreport.pm
+++ b/Debbugs/CGI/Bugreport.pm
@@ -395,10 +395,10 @@ sub handle_record{
 		  {$1.$2.(bug_links(bug=>$3)).$4.
 			   english_join([map {bug_links(bug=>$_)} (split /\,?\s+(?:and\s+)?/, $5)])}eo;
 	  # Add links to reassigned packages
-	  $output =~ s{(Bug\sreassigned\sfrom\spackage\s(?:[\`']|\&\#39;))([^']+?)((?:'|\&\#39;|\\;)
+	  $output =~ s{($config{bug}\sreassigned\sfrom\spackage\s(?:[\`']|\&\#39;))([^']+?)((?:'|\&\#39;|\\;)
\sto\s(?:[\`']|\&\#39;|\\;))([^']+?)((?:'|\&\#39;|\\;))}
-	  {$1.q($2).$3.
-   q($4).$5}exo;
+	  {$1.package_links(package=>$2).$3.
+   package_links(package=>$4).$5}exo;
 	  if (defined $time) {
 	   $output .= ' ('.strftime('%a, %d %b %Y %T GMT',gmtime($time)).') ';
 	  }
-- 
2.1.4

Bug#819327: bash: executes statement after "exit"

[Frank Heckenbach]

Package: bash
Version: 4.3-11+b1
Severity: normal

% cat bash-bug
#!/bin/bash

if true; then
  $[()]
  exit
fi

echo "Should not get here."
% ./bash-bug
./bash-bug: line 4: (): syntax error: operand expected (error token is ")")
Should not get here.

The error is correct, but after that it should continue with exit,
or with "set -e", abort immediately. In both cases it goes on to
execute the statement below.

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

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

Versions of packages bash depends on:
ii  base-files   8+deb8u3
ii  dash 0.5.7-4+b1
ii  debianutils  4.4+b1
ii  libc62.19-18+deb8u4
ii  libncurses5  5.9+20140913-1+b1
ii  libtinfo55.9+20140913-1+b1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#788303: State of the bug?

[Frank Heckenbach]

Hi,

> I am experiencing this bug on 20 low memory Jessie VMs. But only in 20%
> of rebbot attempts. Adding memory might perhaps solve the problem, but
> also rises budget, and can I be sure? Its a real problem anyway.
> 
> It took me some time to find out this might be a bug at all, because it
> happens only at some of the reboots. Further I searched for other
> reasons, until I found this bugreport and the corresponding log entry:
> 
> Mar 23 17:21:22 x swapoff[4187]: swapoff:
> /dev/disk/by-uuid/38cd3812-d2ae-4d79-971a-1ed9b8b08505: swapoff failed:
> Nicht genügend Hauptspeicher verfügbar
> 
> at shutdown time.
> 
> Thanks for the reporting and analysis so far!
> 
> @Frank Heckenbach: I would love to give the "workaround" a try, but I
> don't fully understand, what will be achieved by
> 
> > ExecStop=/bin/sh -c 'while mount | grep -q "on /tmp "; do umount /tmp;
> sleep 1; done; while ! swapoff -a; do sleep 1; done'
> 
> in systemctl shutdown phase. This is only working with /tmp as mount or
> am I wrong? I don't think this can work for me.

Yes, only for /tmp. That's why it's only a workaround. ;)

It works for me (tm), because /tmp is my only tmpfs that ever
carries significant amounts of data. (Of course, there's /run etc.,
but there's not much in it.)

In those cases where I had problems shutting down, swapoff failed
because /tmp used too much space, more than would fit into RAM
without swap. So my workaround was to umount /tmp to free this
space, then swapoff would work.

Your situation may be different. You could try to find out what uses
the memory. There should not be many processes left running at this
point, unless you explicitly prevent them from stopping (or there
are other bugs ...). If you have another large tmpfs, you can try
umounting that instead (or in addition). If that's not it, you'll
need to find out what it is ...

In the worst case (before I'd waste money on more RAM just for
shutting down, which seems quite ridiculous ;), there's a real
hackish solution:

You can forcibly shut down a system with the "magic sysrq key",
using S(ync), U(mount), O(ff). You can also script this using
/proc/sys/kernel/sysrq and /proc/sysrq-trigger. You can google for
that stuff. If necessary, ask me again.

But that should really be a last resort. It will completely bypass
systemd (of course, it hasn't deserved better, if it causes us such
problems ... ;)

> Is there a general solution on the way or in work?

They said they fixed it upstream, but it doesn't look like it will
be backported to jessie, and therefore I haven't tried it. So from
my point of view, I can only hope it will be fixed in the next
stable release. Until then, I hope my workaround will work for me.

Regards,
Frank

Bug#818037: vorbis-tools: vcut always(?) segfaults

[Frank Heckenbach]

> I debugged it and found the problem. It was a simple indexing problem
> that seemed to have slipped away during quite some time because of a 
> lucky memory layout: The pointer resulting from the wrong indexing 
> points to the stack and therefore to valid memory (in terms of memory 
> management), unless the block is too big. Now the memory layout has 
> changed for some reason (GCC 5?), therefore we read a different value as 
> block size, the block is too big for the stack and we get the 
> segmentation faults.

Not GCC 5, jessie still uses 4.9.2 (and I tried rebuilding it
myself, same bug), but anyway.

> The patch is in the git repository.

Where can I get it (just the patch, so I can try it against the
jessie version)?

https://git.xiph.org/ says:
vorbis-tools.git ... Last change 5 months ago

Regards,
Frank

Bug#818037: vorbis-tools: vcut always(?) segfaults

[Frank Heckenbach]

> It's not yet in the upstream git repository (I submitted the patch
> through their bug tracker, but someone from upstream has to check it and 
> apply it), but in our (the Debian package's) git repository.
> 
> You can find the patch here:
> 
> https://anonscm.debian.org/cgit/pkg-xiph/vorbis-tools.git/tree/debian/patches/Fix-segfault-in-vcut.patch

Seems to work for me. Thanks.

Frank

Bug#818045: libspice-server1: cursor disappears in KDE in Xspice

[Frank Heckenbach]

Package: libspice-server1
Version: 0.12.5-1+deb8u2
Severity: normal
Tags: patch

When running KDE in Xspice, the cursor disappears.

To reproduce, I start the server like this:

#!/bin/sh
set -e
export DISPLAY=:30
zcat /usr/share/doc/xserver-xspice/spiceqxl.xorg.conf.example.gz > 
/tmp/xspice.conf
Xspice --config /tmp/xspice.conf --disable-ticketing "$DISPLAY" &
sleep 1
dbus-launch startkde

(Note: Since xserver-xspice is missing in jessie, I use the version
xserver-xorg-video-qxl_0.1.1-3+ubuntu which can be built from
sources under jessie without problems.)

Then I start the client with:

spicec -h localhost -p 5900

When I move the cursor over the spicec window (containing KDE), it
becomes invisible most of the time (occasionally, some garbage is
drawn instead). The patch below seems to fix the problem.

Note, the regression was apparently introduced in 0.12.5-1+deb8u2
which is a security fix. I don't suppose the cursor being visible
was the vulnerability fixed, and it was rather a mistake. However,
it did not do a security check of my patch. (I use spice in a
private network, and for me a possibly-insecure, working version is
better than a possibly-secure, non-working one ...)

As far as I could debug, the cause of the problem is that
0001-worker-validate-correctly-surfaces.patch moves up
VALIDATE_SURFACE_RET(), not only (correctly) before the access of
worker->surfaces[surface_id], but also before
flush_display_commands(). In this situation, apparently, the
commands to be flushed cause the surface to become valid. So the
surface is mistakenly seen as invalid too early. By moving up
flush_display_commands(), it becomes valid in time:

--- server/red_worker.c
+++ server/red_worker.c
@@ -10882,12 +10882,12 @@
 QXLRect *qxl_dirty_rects = msg->qxl_dirty_rects;
 uint32_t clear_dirty_region = msg->clear_dirty_region;
 
+flush_display_commands(worker);
 VALIDATE_SURFACE_RET(worker, surface_id);
 
 rect = spice_new0(SpiceRect, 1);
 surface = >surfaces[surface_id];
 red_get_rect_ptr(rect, qxl_area);
-flush_display_commands(worker);
 
 spice_assert(worker->running);

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

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

Versions of packages libspice-server1:amd64 depends on:
ii  libc6  2.19-18+deb8u4
ii  libglib2.0-0   2.42.1-1+b1
ii  libjpeg62-turbo1:1.3.1-12
ii  libopus0   1.1-2
ii  libpixman-1-0  0.32.6-3
ii  libsasl2-2 2.1.26.dfsg1-13+deb8u1
ii  libssl1.0.01.0.1k-3+deb8u4
ii  multiarch-support  2.19-18+deb8u4
ii  zlib1g 1:1.2.8.dfsg-2+b1

libspice-server1:amd64 recommends no packages.

libspice-server1:amd64 suggests no packages.

-- no debconf information

Bug#818037: vorbis-tools: vcut always(?) segfaults

[Frank Heckenbach]

Package: vorbis-tools
Version: 1.4.0-6
Severity: grave
File: /usr/bin/vcut
Justification: renders package unusable

Sorry for the brief description, but for what I can tell, that's
really it. I tried various cases, and vcut always seems to just
segfault. Here's one example:

% head -c 50 /dev/zero | oggenc -Q -r -o 1.ogg -
% vcut 1.ogg 2.ogg 3.ogg +1
Processing: Cutting at 1,00 seconds
Segmentation fault

Tried on both i386 and amd64.

It did work correctly under squeeze and wheezy.

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

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

Versions of packages vorbis-tools depends on:
ii  libao4   1.1.0-3
ii  libc62.19-18+deb8u4
ii  libcurl3-gnutls  7.38.0-4+deb8u3
ii  libflac8 1.3.0-3
ii  libogg0  1.3.2-1
ii  libspeex11.2~rc1.2-1
ii  libvorbis0a  1.3.4-2
ii  libvorbisenc21.3.4-2
ii  libvorbisfile3   1.3.4-2

vorbis-tools recommends no packages.

vorbis-tools suggests no packages.

-- no debconf information

Bug#732228: rsync: fails to remove files with --remove-source when used with --copy-links

[Frank Altpeter]

Hi,

I can confirm this bug still persists in rsync 3.1.1.



With kind regards

Frank Altpeter

-- 
FA-RIPE || http://about.me/frank.altpeter/



signature.asc
Description: Digital signature

Bug#735595: Re: [vbox-dev] Bug#735595: Patch to update RTC after time change

[Frank Mehnert]

Hi Gianfranco,

we will not apply this patch. I provided the rationale in

  https://www.virtualbox.org/ticket/11980#comment:4

We will probably fix VBoxService to use adjtimex() instead of adjtime()
which should be enough for most users. We also might synchronize the
RTC with the system time on 'steps' (ie host/guest time are out of sync
for more than 20 seconds) but the latter still needs to be discussed
internally.

Kind regards,

Frank

On Friday 11 March 2016 10:23:24 Gianfranco Costamagna wrote:
> Hi Sam and VBox developers,
> I'm forwarding the following mail to VirtualBox Developers's list
> 
> can you please release it under MIT license, to allow them review and
> possibly apply it?
> 
> cheers,
> 
> Gianfranco
> 
> 
> 
> 
> Il Giovedì 10 Marzo 2016 19:18, Sam Morris <s...@robots.org.uk> ha scritto:
> Here's a patch to VBoxService that makes it write to the RTC after it
> updates the system clock.

-- 
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

Bug#735595: Re: [vbox-dev] Bug#735595: Patch to update RTC after time change

[Frank Mehnert]

On Friday 11 March 2016 12:57:17 Frank Mehnert wrote:
> We also might synchronize the RTC with the system time on 'steps' (ie
> host/guest time are out of sync for more than 20 seconds) but the latter
> still needs to be discussed internally.

s/20 seconds/20 minutes/ of course.

Frank
-- 
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

Bug#766294: virt-manager: Cannot Exit Console Fullscreen Mode [VNC]

[Frank Lin PIAT]

Package: virt-manager
Version: 1:1.2.1-4
Followup-For: Bug #766294

Hello,

I have the same problem when my guest is running in VNC mode.
But it's fine when running in Spice mode.

Frank lin Piat

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

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

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gconf2   3.2.6-3
ii  gir1.2-gtk-3.0   3.18.7-1
ii  gir1.2-gtk-vnc-2.0   0.5.3-1.3+b1
ii  gir1.2-libosinfo-1.0 0.2.12-2
ii  gir1.2-libvirt-glib-1.0  0.2.2-0.1
ii  gir1.2-vte-2.91  0.42.4-1
ii  librsvg2-common  2.40.11-2
ii  python-dbus  1.2.0-3
ii  python-gi3.18.2-2
ii  python-gi-cairo  3.18.2-2
ii  python-ipaddr2.1.11-2
ii  python-libvirt   1.3.1-1
ii  python-urlgrabber3.9.1-4.2
pn  python2.7:any
pn  python:any   
ii  virtinst 1:1.2.1-4

Versions of packages virt-manager recommends:
ii  gir1.2-spice-client-gtk-3.0  0.30-1
ii  gnome-icon-theme 3.12.0-1
ii  libvirt-daemon-system1.3.1-1

Versions of packages virt-manager suggests:
ii  gnome-keyring3.18.3-1
ii  python-gnomekeyring  2.32.0+dfsg-3
pn  python-guestfs   
ii  ssh-askpass  1:1.2.4.1-9
ii  virt-viewer  1.0-1

-- no debconf information

Bug#816848: pepperflashplugin-nonfree: Doesn't update pepperflash

[Frank McCormick]

Package: pepperflashplugin-nonfree
Version: 1.8.2
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,


The pepperflashplugin-nonfree doesn't update or install pepperflash. I suspect 
the reason
is Google has dropped support for 32 bit Google-Chrome, so the flash package is 
simply not available anymore.

This is the result of running it 



root@frank-debian:/home/frank# update-pepperflashplugin-nonfree --install 
--verbose
options :  --install --verbose --
temporary directory: /tmp/pepperflashplugin-nonfree.lOWqvvqSXk
doing apt-get update on google repository
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
downloading 
http://people.debian.org/~bartm/pepperflashplugin-nonfree/latest-stable-verified.txt
selected action = --install
dpkg-deb: error: --extract needs a target directory.
Perhaps you should be using dpkg --install ?

Type dpkg-deb --help for help about manipulating *.deb files;
Type dpkg --help for help about installing and deinstalling packages.
root@frank-debian:/home/frank# 




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

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils   2.26-5
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.58
ii  gnupg  1.4.20-4
ii  libatk1.0-02.18.0-1
ii  libcairo2  1.14.6-1
ii  libcurl3-gnutls7.47.0-1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.3-3
ii  libgcc11:5.3.1-10
ii  libglib2.0-0   2.46.2-3
ii  libgtk2.0-02.24.29-1
ii  libnspr4   2:4.11-1
ii  libnss32:3.21-1.1
ii  libpango-1.0-0 1.38.1-1
ii  libpango1.0-0  1.38.1-1
ii  libstdc++6 5.3.1-10
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.17.1-1+b1

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
ii  chromium   49.0.2623.75-2
pn  hal
ii  ttf-dejavu 2.35-1
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#622340: udev - system hangs about 90 seconds on boot (first line,"Loading, please wait") -> ata1.00: failed command: IDENTIFY PACKET DEVICE

[Frank Heckenbach]

Hi Jort,

> Great comment and recommendation. I was using SB04 and experienced the 90
> second boot delay. Workaround was functioning as described before, however
> udev rules might easily get overwritten so it's not an ideal solution.
> 
> I have a dual boot OS.
> What I did:
> Booted to windows and downloaded the SB07 firmware (auto-flashed from
> executable).
> Rebooted to linux (I'm running mint):
> 
>- Reinstated the original line from
>/lib/udev/rules.d/60-persistent-storage.rules
>- update-initramfs -u
>- Reboot again and check boot time + dmesg.
> 
> It seems to have worked for me, I tried some other reboots to see whether I
> could get it to break again without 'success'.
> 
> So it might be worth the one time effort for people to plug the drive to a
> windows box and flash it, or boot to win OS.
> 
> Download link I used (official tsstodd):
> http://www.tsstodd.com/TotalLib/popup/Download.asp?path=fwdownload=eng=SH-S223C_SB07.exe
> 
> Note that you should also be able to use MacOS with the separate TSDNMAC
> firmware flash program and extracting the .bin from the windows download
> above (it's just an archive).

Nice that it works for you. OTOH, I don't have any other OS on
my machine, and removing the drive and taking it to a friend's
Windows machine quite frankly seems more effort than the drive is
worth. Probably "cheaper" to buy a new one then. But as long as the
workaround works, I can use this. (If you know a method to upgrade
under Linux, or maybe FreeDos which I could probably set up quickly,
I'd still like to try it.)

I understand that it's the drive that's doing something wrong, but
so far udev is the only thing that seems to have a problem with it,
everything else works fine regardless. It's not the first software
workaround for hardware bugs I've had to use either. (The kernel has
a number of those, and at least one of my former MBs definitely
needed one to use UDMA reliably.) Such is life in the hardware-near
world, so maybe udev could just adapt this little workaround ...

Regards,
Frank

Bug#815407: xd: FTBFS on hurd-i386: error: 'PATH_MAX' was not declared in this scope

[Frank B. Brokken]

Dear Andreas Beckmann, you wrote:
> 
> On 2016-02-21 12:30, Frank B. Brokken wrote:
> > It should be trivially fixable: should be a matter of including
> >  in alternatives/alternatives.ih. (*should* because I don't
> 
> Does that header exist on hurd-i386?

Don't know, but the problem has been fixed in another way: by passing 0 (NULL)
to realpath's 2nd argument an appropriately sized buffer is allocated by
realpath, and there's no reference anymore to PATH_MAX. Problem solved :-)

Thanks for the quick reply!

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#815407: xd: FTBFS on hurd-i386: error: 'PATH_MAX' was not declared in this scope

[Frank B. Brokken]

Dear Andreas Beckmann, you wrote:

> If this isn't trivially fixable, please request the outdated binary
> packages to be decrufted.

It should be trivially fixable: should be a matter of including
 in alternatives/alternatives.ih. (*should* because I don't
have access to a hurd machine, so I can't test the presumed fix directly).

I'll try to prepare a new release today. Thanks!

-- 
    Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#813485: RFS: setop/0.1-1 [ITP]

[Frank Stähr]

Package: sponsorship-requests
Severity: wishlist


Dear mentors,


I am looking for a sponsor for my package "setop":

 * Package name: setop
   Version : 0.1-1
   Upstream Author : Frank Stähr
 * URL : <http://github.com/phisigma/setop>
 * License : GPL-2+
   Section : utils


dupload did not exactly what I wanted it to do, nevertheless, look here: 
<ftp://ftp.upload.debian.org/pub/UploadQueue/>
Please tell me if I should try to get it to <http://mentors.debian.net/> 
or whereever.


I have planned setop years ago and programed it after getting a slightly 
positve feedback from this list, see 
<https://lists.debian.org/msgid-search/56057231.7080...@gmx.net>.



More information about setop can be obtained by executing it via setop 
--help, but here is a rough overview:

===
setop A -d B C
yields in (A ∪ C) ∖ B
===
setop -i A B -c "el"
checks if el ∈ A ∩ B
===
setop - A B -n [[:space:]] -o "\t"
unions A, B, and the standard input, where every "whitespace" (i. e. \v 
\t \n \r \f or space) is interpreted as an element separator; output 
elements are separated by a horizontal tab (normally it’s a new line 
character)

===
setop C1 C2 […]
is similar to sort --unique C1 C2 […]
===

Several other options for input parsing and calculation output sets are 
possible.


For additional information about the motivation for this program see 
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813485>: setop 
unifies many features from other programs (like sort, uniq, comm, join, 
grep, awk, cat, combine, or wc) into one universal, flexible, and easy 
program.



Regards,
Frank

Bug#813485: ITP: setop -- apply set operations like intersection to text inputs

[Frank Stähr]

Package: wnpp
Severity: wishlist
Owner: "Frank Stähr" <der-storch...@gmx.net>

* Package name: setop
  Version : 0.1
  Upstream Author : Frank Stähr <der-storch...@gmx.net>
* URL : http://github.com/phisigma/setop
* License : GPL-2+
  Programming Lang: C++
  Description : apply set operations like intersection to text inputs

setop is a simple console utility for handling multiple inputs from files or 
other streams as mathematical sets.
That is you can apply typical set operations like union, intersection, or set 
difference and print a resulting set (sorted and with unique string elements) 
to standard output or you can give answer to special queries like number of 
elements.

Up to now, there is no similar package in the repository. Programs like sort, 
uniq, comm, join, grep, awk, cat, combine, wc etc. can only inconveniently deal 
with some (in each case one or two) features of setop, but none of these is as 
universal, flexible, and easy to use as setop itself, including non-standalone 
utilities like script languages.

I already asked at <debian-ment...@lists.debian.org> for the need of something 
like setop and got at least a slightly positive feedback, mixed with references 
to the above mentioned "workarounds", Python and LISP. See 
<https://lists.debian.org/msgid-search/56057231.7080...@gmx.net>.

Further maintance (e. g. translations, new features and of course bug fixing) 
are planned, but at first I need a sponsor and am going to ask at 
debian-mentors.

Bug#812236: CD-Image does not boot with Libreboot/GRUB

[Frank Guthausen]

On Thu, Jan 21, 2016 at 11:48:27PM +, Steve McIntyre wrote:
> 
> See
> 
>   http://www.syslinux.org/wiki/index.php/Doc/menu
> 
> for docs on isolinux menus. Grub's support for isolinux menus is
> clearly not complete/correct here, and that's your problem I'm
> afraid. Isolinux parses these menus just fine.

I digged deeper, and I guess this is correct. There are three problems
around here AFAICS:

1) Grub's implementation of invoking isolinux doesn't work correctly.

2) Grub's chainloading depends on BIOS/UEFI:
http://www.gnu.org/software/grub/manual/grub.html
| Chain-loading is only supported on PC BIOS and EFI platforms.

> It looks like a (design?) bug that Libreboot won't do normal boot
> sector booting like a conventional BIOS.

3) Libreboot doesn't provide the information for chainloading the same
way as BIOS/UEFI.

Most likely those issues have to be fixed in Grub.  Maybe there is a
workaround to mitigate the problem with an intermediate USB-stick by
invoking SmartBootManager as payload (kernel), which doesn't depend
on chainloading at all. There are hints that this was done a couple
of years ago, but it looks difficult to reproduce this solution.

Some tests indicate that there might be
more issues with 16bit vs. 32bit mode.
-- 
regards
Frank

Bug#812236: CD-Image does not boot with Libreboot/GRUB

[Frank Guthausen]

Package: debian-cd
Version: 3.1.17

Debian 8.2.0 amd64 CD 1

On a system with Libreboot and GRUB payload, the Debian installation
CD 1 does not boot properly. An error message as follows can be provoked:

| error: kernel without label.

Similar issues can be observed with older versions or derived
distributions.

The file /isolinux/txt.cfg contains a boot entry
| menu default
| kernel /install.amd/vmlinuz
which has got a different pattern than other boot entries.

I suggest to change the first line of the boot entry into
| menu label default
which fits into the syntax pattern.

Starting from /isolinux/menu.cfg there are other config files included,
but some of them do not exist in the CD-Image iso9660 filesystem, e.g.
amdtxt.cfg or amdgtk.cfg which might cause problems, too.
-- 
regards
Frank

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> > This seems to work. However, given that this single line is now >1
> > KB and more than 3 times as long as my work-around service, and
> > heavily depends on the system configuration, I doubt whether it's
> > actually less hackish. (I do occasionally change my swap partitions.
> > I also build system images to run on different machines.)
> >
> > One could try to auto-generate this, of course. Not too hard, but
> > when should it run? From a systemd service run during boot, which
> > modifies another systemd run during boot -- doesn't seem like a good
> > idea. (And it would break if swap partitions are added/removed after
> > boot.)
> >
> > So I'll stick with my work-around, but I think the above can perhaps
> > serve as an example for what to do in systemd interally (the only
> > place I could image it working reliably), maybe similar to the patch
> > in https://github.com/systemd/systemd/issues/1902 (but I don't know
> > the internals well enough to really tell).
> 
> Once this package is fixed in stable, the workaround can be reduced to
> After=swap.target.
> 
> I don't think we want to diverge locally (ie, in Debian) from what
> dependencies are automatically added to tmpfs mounts. I figure if you
> change overcommit_memory you can also specify the tpmfs ordering...

Not really. overcommit_memory is a simple, static setting
/etc/sysctl.d/local.conf whereas as I said the tmpfs change is
rather long and system-dependent (if you have a solution for
auto-generating it, let me know).

I suggest we keep this bug open until it's fixed in stable (and I
keep using my work-around until then). When it's done, I can try
"After=swap.target" and report if it works.

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> What if instead of this service, you add an:
> 
> After=swap.target
> 
> To your tmp.mount ?

Doesn't work. Also, systemctl still lists tmp.mount before the swap
targets, which means (I suppose) it will be stopped after them.

I thought maybe swap.target is just a virtual target that depends on
the actual swap targets, so I should put them there, but it also
doesn't work. Or do I need to quote the names differently?

After=dev-disk-by\x2duuid-01db9e17\x2d60e5\x2d428c\x2dbbbf\x2dfd817e2f1ec9.swap 
dev-disk-by\x2duuid-740bd0c3\x2da38f\x2d4732\x2d9120\x2da88b78f889a6.swap 
dev-disk-by\x2duuid-8178b5f7\x2d410f\x2d46c4\x2da4c3\x2d5003af570dbc.swap 
dev-disk-by\x2duuid-fe4e8739\x2d2114\x2d4994\x2d9ada\x2d2bf7b275e42e.swap

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> Due to the other bug I linked, this may not be sufficient. Please list
> all the swap units listed in
> 
> % systemctl list-units '*.swap'
> 
> You'll see that there are multiple units each of the different ways
> you can access the underlying partition (by uuid, did, wwm and sdX
> name).
> 
> I don't think you need to quote differently.

This seems to work. However, given that this single line is now >1
KB and more than 3 times as long as my work-around service, and
heavily depends on the system configuration, I doubt whether it's
actually less hackish. (I do occasionally change my swap partitions.
I also build system images to run on different machines.)

One could try to auto-generate this, of course. Not too hard, but
when should it run? From a systemd service run during boot, which
modifies another systemd run during boot -- doesn't seem like a good
idea. (And it would break if swap partitions are added/removed after
boot.)

So I'll stick with my work-around, but I think the above can perhaps
serve as an example for what to do in systemd interally (the only
place I could image it working reliably), maybe similar to the patch
in https://github.com/systemd/systemd/issues/1902 (but I don't know
the internals well enough to really tell).

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

As a work around, I've put the following in
/etc/systemd/system/workaround-788303.service and activated it with
systemctl enable workaround-788303

This seems to work for me for now. Of course, I'd prefer a real
bugfix. (And so should the systemd author, seeing how much he hates
using the shell ... ;)

[Unit]
Description=Work-around for Debian bug #788303
After=local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/bin/sh -c 'while mount | grep -q "on /tmp "; do umount /tmp; sleep 1; 
done; while ! swapoff -a; do sleep 1; done'

[Install]
WantedBy=multi-user.target

Bug#810615: pg_upgradecluster seems not to honour some/all config from postgresql.auto.conf

[Frank Gard]

Package: postgresql-client-common
Version: 172.pgdg70+1

Hi!

I think I have found a bug similar to #787154. The latter is archived
now, so I have to report it as new.

Description:
I just installed PostgreSQL 9.5.0 and tried to migrate my 9.4.5 cluster
to the new version using pg_upgradecluster. At a first glance everything
worked fine, but the BaRMan I use had some problems when doing a backup:
It was hanging with "Asking PostgreSQL server to finalize the backup".
Looked for it in their F.A.Q. at http://www.pgbarman.org/faq/backup/,
and found that the problem was a misconfiguration of my WAL archiving,
especially the value of archive_command.

While trying to solve the problem, I found out, that I set the WAL
configuration using ALTER SYSTEM, so it was written to
/var/lib/postgresql/9.4/main/postgresql.auto.conf. I looked for the
corresponding /var/lib/postgresql/9.5/main/postgresql.auto.conf, but
without any success, there's no such file. The default config file, i.e.
/etc/postgresql/9.5/main/postgresql.conf contains the old and invalid
WAL config entries from times when I didn't use BaRMan, yet. The config
entrys in the auto-file are not transferred to the new cluster in any way!

Fortunately the archive_command didn't work, because the corresponding
program isn't available anymore. So my quick and dirty solution was:
1. doing as Linux user postgres
grep -Eve '^\s*(#|$)' \
/var/lib/postgresql/9.4/main/postgresql.auto.conf \
  | sed 's/^/ALTER SYSTEM SET /;s/$/\;/' \
  | psql
2. (less interesting here:) tidying up old BaRMan backup and
3. restarting PostgreSQL 9.5 cluster

Now, everything works fine for me, but I think that others should be
prevented from walking into this trap. Therefore I send this e-mail.
Please, could you check if there's any way to transfer the original
postgresql.auto.conf file (or at least its entrys) when using
pg_upgradecluster?

Just for completeness the "uname -a" output:
Linux host.dom.tld 2.6.32-042stab111.12 #1 SMP Thu Sep 17 11:38:20 MSK 2015 
x86_64 GNU/Linux
If you need any further information, please let me know.

And, last but not least, thank you very much for your effort!
The Debian PostgreSQL tools are really admirable and I like very
much using them.

Thanks in advance,
Frank.

--

GnuPG / PGP info

Key-ID:  0xC8C1A552
Fingerprint: 3EFD EF94 4841 38B5 DB40 95D8 C69C 71C5 C8C1 A552



signature.asc
Description: OpenPGP digital signature

Bug#810615: Wrong package?

[Frank Gard]

Package: postgresql-commonVersion: 172.pgdg70+1
Probably I reported the bug using the wrong package name. Please reassign, if 
I'm right.
Sorry!!!
Thx,Frank.

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> On 6 Jan 2016 02:45, "Frank Heckenbach" <f.heckenb...@fh-soft.de> wrote:
> >
> > I did some more debugging, and found out some things:
> >
> > - In a debug shell after the failed shutdown, I did:
> >
> >   systemctl status `systemctl | grep failed | grep swap | awk '{print
> $2}'`
> >
> >   and found an error message like this:
> >
> >   swapoff: /dev/sdxx: swapoff failed: Cannot allocate memory
>
> Maybe related to:
> 
> https://github.com/systemd/systemd/issues/1902
> 
> I don't think we have backported that fix to stable. Could you try the
> workaround of ordering the aliased swap units?
> 
> Add a file /etc/systemd/system/swap.target.d/override.conf
> 
> [Unit]
> After=$swapunits
> 
> You can find out the precise swap units by using `systemctl list-units
> --type swap`
> 
> You need to do systemctl daemon-reload after adding the file.

Doesn't help, and I hadn't really expected it to. It seems to be
about the ordering relative to swap.target, but what I need is for
swapoff to be ordered after unmounting (of at least all tmpfs
mounts).

Bug#790535: susv4: fails to install: post-installation script returned error exit status 1

[Frank Terbeck]

Hello maintainer!

I just tried to install the "susv4" package on my system and it revealed
the following issue, which I believe was mentioned in the bug id I am
reopening right now.

Note, that I tried to install "susv2" and "susv3" and neither of those
packages had any problems of that kind.


Regards, Frank


i-(6007)-~% apt-get install susv4
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  susv4
0 upgraded, 1 newly installed, 0 to remove and 56 not upgraded.
Need to get 0 B/3,088 B of archives.
After this operation, 15.4 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package susv4.
(Reading database ... 319792 files and directories currently installed.)
Preparing to unpack .../susv4_7.20150719_all.deb ...
Unpacking susv4 (7.20150719) ...
Processing triggers for doc-base (0.10.6) ...
Processing 1 added doc-base file...
Error in `/usr/share/doc-base/susv4', line 9: all `Format' sections are invalid.
Note: `install-docs --verbose --check file_name' may give more details about 
the above error.
Setting up susv4 (7.20150719) ...
Fetching file...
--2016-01-06 14:06:16--  
http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4tc1.tar.bz2
Resolving pubs.opengroup.org (pubs.opengroup.org)... 69.80.200.148
Connecting to pubs.opengroup.org (pubs.opengroup.org)|69.80.200.148|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 3638538 (3.5M) [application/x-bzip2]
Saving to: ‘/tmp/tmp.CEtMv9qZZX/susv4tc1.tar.bz2’

susv4tc1.tar.bz2100%[=>]   3.47M  
56.7KB/sin 41s

2016-01-06 14:06:58 (87.2 KB/s) - ‘/tmp/tmp.CEtMv9qZZX/susv4tc1.tar.bz2’ saved 
[3638538/3638538]

Verifying SHA512 checksum...
dpkg: error processing package susv4 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 susv4
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

I did some more debugging, and found out some things:

- In a debug shell after the failed shutdown, I did:

  systemctl status `systemctl | grep failed | grep swap | awk '{print $2}'`

  and found an error message like this:

  swapoff: /dev/sdxx: swapoff failed: Cannot allocate memory

- Manually running "swapoff -a" while my system is up, also often
  fails with this error (especially if KDE and Firefox are running
  and overcommit_memory is disabled), even though there seems to be
  enough free memory. This is explained here (including the links in
  the comments):

  
http://unix.stackexchange.com/questions/89514/swapoff-fails-when-overcommit-memory-2

  This may be the root cause of our problems, not a systemd bug (but
  don't close the issue yet, read on).

- I also wondered, why do swapoff at all before shutdown/restart?
  This is apparently answered in:

  https://bugzilla.redhat.com/show_bug.cgi?id=1031158

  Though I don't really agree with that reasoning (breaking the
  shutdown process for many people, as indicated in this, that, and
  all the merged bug reports, just for the sake of a rather unlikely
  IMHO niche case), that seems to be the way it is and it's not
  strictly a bug, either.

- However, to answer the question asked there (I don't have an RH
  account to post there, and the report there is closed already, so
  I'll write it here; feel free to forward it to RH and/or systemd):

  "What is using the memory in your case?"

  At least in one case I debugged, it seems to be a tmpfs which
  indeed had grown to several GB size (which I'd normally expect to
  be discarded on shutdown, that's fine).

  Apparently, systemd tries to swapoff before unmounting the tmpfs.
  It does so, apparently, because tmpfs was mounted before swapon,
  and shutdown order is reverse startup order.

  So swapoff fails because tmpfs uses too much memory. Then tmpfs is
  unmounted (successfully), but swapoff is never retried, shutdown
  is considered failed, and the system is basically dead.

So AFAICS there are at least two issues to fix in systemd:

1. Do swapoff *after* umount.

   I know this might be difficult given systemds concepts of
   depedencies and ordering, but I don't care. I didn't ask for it,
   it was systemd that introduced it (and Debian who throw systemd
   on us), so it's your job to sort out the mess. If a proper
   solution is not feasible easily, at least do an additional
   swapoff after umounting.

2. Handle shutdown failures better (i.e., at all).

   Currently, all you get is a message which (unlike in sysvinit) is
   not even shown on the console, but only in its journal (which you
   normally can't even read, because you have no shell at this
   point, so the message might as well not exist at all).

   Then the system just hangs (I wasn't as patient as Will Aoki and
   didn't wait for 27 minutes, but I assume it will hang forever),
   unless you take harder measures ...

   That's not really acceptable behaviour. systemd must know that
   shutdown has failed and nothing can progress anymore. If so, at
   least give me a maintenance shell or something! And tell me about
   the error (see above)!

   (I know this might be difficult etc., see above.)

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

Just saying me too (also to get informed about news on this front).
It happenes both on reboot and shutdown attempts.

I can also offer to help debugging it, if there's something specific
I can do (in jessie).

Also, I'd suggest to increase the severity, since, you know, not
shutting down the system properly seems a pretty big deal to me. For
all its perceived weaknesses, sysvinit has been able to do that for
decades. (I'm getting used to shut down by raising elephants --
still easier to do than manually doing swapoff every time -- but
that really can't be the way to go.):

Bug#809633: socat: exits with incorrect status when terminated by signal

[Frank Heckenbach]

Package: socat
Version: 1.7.2.4-2
Severity: normal
Tags: upstream

When socat is terminated by a signal that it catches (e.g. SIGTERM),
it exits with status 128+signum (socat_signal() -> diag_exit() ->
_diag_exit() -> Exit() -> exit()).

Though 128+signum is a convention used by common shells to set $?
for processes killed by a signal, it's not actually the same;
wait() on such a process returns different statuses.

I noticed this when I tried to use socat in a systemd service. When
terminating it properly (i.e. via SIGTERM), systemd would
(correctly) describe it as "failed":

  Active: failed (Result: exit-code)
  Process: 1096 ExecStart=/usr/bin/socat [...] (code=exited, status=143)

rather than "dead" as it does after proper termination:

  Active: inactive (dead)
  Process: 20422 ExecStart=/some/other/program (code=killed, signal=TERM)

The usual way to achieve the correct behaviour, i.e. acting on a
signal and then terminating as if by the signal, is to restore the
handler to SIG_DFL, then raise() the signal again.

This would require small changes to the intermediate functions
listed above, and maybe manual calling atexit() functions, but
should otherwise be a rather easy fix.

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

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

Versions of packages socat depends on:
ii  libc62.19-18+deb8u1
ii  libssl1.0.0  1.0.1k-3+deb8u2
ii  libwrap0 7.6.q-25

socat recommends no packages.

socat suggests no packages.

-- no debconf information

Bug#622340: udev - system hangs about 90 seconds on boot (first line,"Loading, please wait") -> ata1.00: failed command: IDENTIFY PACKET DEVICE

[Frank Heckenbach]

Bob B wrote:

> It's curious whether the problem can be resolved
>
> by updating the ODD's firmware
>
> to the latest version (currently "SB07"):
>
> http://www.tsstodd.com/eng/firmware/fwdownload/?functionvalue=view=733

I'd like to try it if there's some way to update the firmware.
The web site only seems to support other OSs.

Bug#809296: config file example

[Frank McCormick]

I have attached a sample of what wbar-config does to my $HOME/.wbar file 
after

I hit reload.




.wbar
Description: Binary data

Bug#809296: Thanks for the quick action!

[Frank McCormick]

Appreciate it...even if I am one of the few running wbar :)

--
Do not handicap your children by making their lives easy.
 -- Robert Heinlein--Time Enough For Love--

Bug#809296: wbar-config in same package garbles the config file.

[Frank McCormick]

Package: wbar
Version: 2.3.4-4
Severity: normal

Making changes to the wbar configuration using wbar-config garbles the second 
line
of the $HOME/.wbar file which normally contains the parameters to wbar.
Running wbar after that places the wbar image in a seemingly arbitrary manner on
the screen.

I haven't run wbar for sometime and this behavior just started so it might
be changes in one of the other libraries wbar depands on. Just a guess.




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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages wbar depends on:
ii  libc6   2.21-6
ii  libgcc1 1:5.3.1-4
ii  libimlib2   1.4.7-1+b1
ii  libstdc++6  5.3.1-4
ii  libx11-62:1.6.3-1

Versions of packages wbar recommends:
ii  fonts-liberation  1.07.4-1
pn  lxde-icon-theme   

Versions of packages wbar suggests:
ii  bash-completion  1:2.1-4.2
ii  wbar-config  2.3.4-4

-- Configuration Files:
/etc/xdg/autostart/wbar.desktop [Errno 2] No such file or directory: 
u'/etc/xdg/autostart/wbar.desktop'

-- no debconf information

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Dear Michael Biebl, you wrote:
> Here is a more complete log excerpt for v228 (full log attached)
> 
> > Dez 20 01:27:42 debian systemd[1]: -.mount: Changed dead -> mounted
...
> 
> So the best guess is that the timing in v228 changed a little (some code
> paths became faster). This would confirm Frank's findings that enabling
> verbose output (which slows down boot a bit) made it less likely to hit.
> 
> Martin has been working/debugging the tentative stuff in the past, so
> maybe he has some insights here.
> 
> We should probably also involve upstream at some point.

OK, thanks for the help and (for me at least) final conclusion. For me
personally the problem has been solved: for the time being I'm happy with 227,
and I'm sure that the problem will soon be fixed.

Thanks again for helping along!

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Dear Michael Biebl, you wrote:

> > This information is available at https://www.icce.rug.nl/systemd in the 
> > files 
> > initramfs.debug and alb.
> 
> Hm, unfortunately the journal dump is incomplete again. I have no idea why

Remarkable. I made it available the way I got it, so that's apparently what
there is.

> > booting procedure. You're sure it can't be some timing problem? 
> 
> Well, what kind of timing problem do you have in mind?

Don't know: I didn't design systemd. But if it's doing things in parallel then
maybe on newer, faster, computers things might have completed, like remounting
/usr rw before it's actually used. A race condition might then explain why the
problem doesn't always show itself, and why chances of failure are reduced
when more time is spent writing debug/verbose messages.

 
> So far, the only thing I can say for sure looking at the initramfs log,
> is that /usr has been mounted successfully in the initramfs.
> 
> "Something" apparently causes /usr to be unmounted later on. Which part
> and why that is, is not clear yet.
> 
> Do you have any (custom) init scripts in /etc/rcS.d/ which fiddle around
> with mount settings, run telinit or stuff like that?

Nope.

> I'm running out of ideas, tbh.

Well, that's already a *lot* more than I could offer myself :-) But
fortunately (for me, but hard to fix, I realize), the problem doesn't emerge
all the time. If rebooting every now and then gets me a running system, then
so be it. The FailureAction=reboot-force entry in systemd-remount-fs.service
already has proven to be my friend :-)


> If you suspect the remount service to be the cause for this, let's
> output the mounts before and after
> For that run
> $ systemctl edit systemd-remount-fs.service

When I issue that command I get the reply

Warning: systemd-remount-fs.service changed on disk. Run 'systemctl
daemon-reload' to reload units.

I guess the warning is obvious as I edited the file 

/lib/systemd/system/local-fs.target.wants/systemd-remount-fs.service

to prevent the reboot action. So I did as advised and reran the command,
but got an empty file in my editor, while the following message was shown
after ending the editor:

Editing "/etc/systemd/system/systemd-remount-fs.service.d/override.conf"
canceled: temporary file is empty.

> Then add
> [Service]
> ExecStartPre=/bin/sh -c 'echo "before rootfs remount"; findmnt'
> ExecStartPost=/bin/sh -c 'echo "after rootfs remount"; findmnt'
> 
> Reboot and attach the journal log again.

Instead of running the systemctl command I edited the file
/lib/systemd/system/local-fs.target.wants/systemd-remount-fs.service and added
the lines you suggested. My next e-mail is about the contents of journal log.

Thereafter I'll try to downgrade to the previous version to see what
happens then.


-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Hi Michael,

The journalctl -alb output after adding:

> Then add
> [Service]
> ExecStartPre=/bin/sh -c 'echo "before rootfs remount"; findmnt'
> ExecStartPost=/bin/sh -c 'echo "after rootfs remount"; findmnt'

and rebooting (until failure) is at https:/www.icce.rug.nl/systemd/alb-1650

It does contain the 'before rootfs' line, but the 'after rootfs' line isn't
there:

$ grep 'before rootfs' *1650
Dec 19 16:45:18 localhost.localdomain sh[430]: before rootfs remount
Dec 19 16:45:20 localhost.localdomain sh[487]: before rootfs remount
Dec 19 16:45:21 localhost.localdomain sh[516]: before rootfs remount
Dec 19 16:45:24 localhost.localdomain sh[620]: before rootfs remount
$ grep 'after rootfs' *1650
$

Next thing I'll try is to downgrade to 227-2.

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Hi Michael,

I downgraded to the following versions of the following packages:

libpam-systemd_227-2_i386.deb  libudev1_227-2_i386.deb 
libsystemd-dev_227-2_i386.deb  systemd-sysv_227-2_i386.deb 
libsystemd0_227-2_i386.deb systemd_227-2_i386.deb 
libudev-dev_227-2_i386.deb udev_227-2_i386.deb 

Thereafter I rebooted several times without encountering any problems. Also
with reduced output (grub's option 'quiet') no problems were encountered.

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Dear Michael Biebl, you wrote:
> Am 18.12.2015 um 15:59 schrieb Frank B. Brokken:
> > Is there a way to determine that? What I do to upgrade the system is run
> > 'aptitude update' and then 'aptitude upgrade'. Is there a log somewhere that
> > tells me what packages and versions were updated at what moments in time?
> 
> /var/log/dpkg.log is a low-level log.
> 
> and then there is one for aptitude at /var/log/aptitude

Thanks: I made the logs available at https://www.icce.rug.nl/systemd


> ...
> Btw, you mentioned that this happened after an upgrade. Which previous
> version did you run which worked fine? Which other packages were
> upgraded along with it?

Tue, Dec  1 2015 14:07:23 +0100: 
the aptitude log shows an upgrade from systemd 227-2 to 228-2 

dpkg log: 2015-12-01 14:08:42 upgrade systemd:i386 227-2 228-2

dpkg log: 2015-12-03 08:30:01 upgrade systemd:i386 228-2 215-17+deb8u2

Thu, Dec  3 2015 08:31:37 +0100
the aptitude log shows an upgrade from systemd 215-17+deb8u2 -> 228-2

dpkg log: 2015-12-03 08:31:40 upgrade systemd:i386 215-17+deb8u2 228-2

and then, recently, by me trying to downgrade:

dpkg log: 2015-12-17 12:59:12 upgrade systemd:i386 228-2 228-2
dpkg log: 2015-12-18 16:15:37 upgrade systemd:i386 228-2 215-17+deb8u2
dpkg log: 2015-12-18 16:17:11 upgrade systemd:i386 215-17+deb8u2 228-2

Before Dec 1 no updates were recorded for systemd or udev, and until the
upgrades early December everything ran fine.




> If you downgrade systemd/udev, does the problem go away?

As I feared, downgrading is difficult because of the many reverse
dependencies. 

I looked at 

ftp://ftp.de.debian.org/debian/pool/main/s/systemd/

which is the mirror I usually use for earlier .deb files, but the one before
228-2 is 215-17, and 227-2 is only available as source archives and not AFAICS
as .deb packages.

I'll add the debug entry next (cf. your mail from Date: Fri, 18 Dec 2015
03:15:15 +0100) and let you know the results.


-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Hi Michael,

As announced in my previous e-mail:

> I'll add the debug entry next (cf. your mail from Date: Fri, 18 Dec 2015
> 03:15:15 +0100) and let you know the results.

This information is available at https://www.icce.rug.nl/systemd in the files 
initramfs.debug and alb.

Maybe useful to note: it took like four or five reboot attempts before the
booting process eventually failed. This time even more output than with using
'verbose' flashes by during the booting process, which somewhat slows down the
booting procedure. You're sure it can't be some timing problem? 

-- 
    Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Dear Michael Biebl, you wrote:

> Well, /usr is mounted by the initramfs these days. So it should already
> be available when systemd is started. If that fails, this is a bug which
> needs to be addressed by initramfs-tools (or one of the hook scripts).
> It wasn't clear so far that /usr hasn't been mounted at all.
> 
> Is /usr on LVM, RAID, etc?

No, nothing like that. And for what it's worth: the problem only appeared
after I upgraded systemd last week. The laptop has nothing special in its
setup, and has been working perfectly for years, until last week when systemd
was renwed. I think in my bugreport I mentioned the problem that /usr wasn't
mounted.

In your next reply you wrote:

> I'm a bit confused by those logs. They show that sda5 have been mounted.
> 
> Dec 17 15:44:29 localhost.localdomain kernel: EXT4-fs (sda5): mounting
> ext3 file system using the ext4 subsystem
> Dec 17 15:44:29 localhost.localdomain kernel: EXT4-fs (sda5): mounted
> filesystem with ordered data mode. Opts: (null)
> 
> I figure /dev/sda5 is your /usr partition? Just to be sure, please
> attach ls -la /dev/disk/by-uuid/

I seem to remember that message, in particular the Opts: (null) remark, and I
think at that point /usr was mounted by me fron the systemd shell. Also,
couldn't it be that initramfs *did* do the mount, but that remounting it rw,
als reported in the error message is the problem? Also, to me it appears
remarkable that by removing the 'quiet' from the kernel parameters, so that
things go a bit slower because of the extra messages that are displayed the
frequency of failing boot procedures is greatly diminished. I'm considering
trying to add 'verbose' to grub's parameters to see if that produces more
output and maybe further reduces the frequency, but I haven't had the time to
do that yet. Something on the TODO list :-)

Anyway, here's the ls -la output:

total 0
drwxr-xr-x 2 root root 200 Dec 18 13:05 ./
drwxr-xr-x 5 root root 100 Dec 18 13:02 ../
lrwxrwxrwx 1 root root  10 Dec 18 13:02 04b82e8b-f871-4abb-978a-44ae44c5d1f7
-> ../../sda1
lrwxrwxrwx 1 root root  10 Dec 18 13:02 595bcdbf-6436-45a7-99d2-297a3dd85930
-> ../../sda6
lrwxrwxrwx 1 root root  10 Dec 18 13:02 693c71eb-d411-4ee0-a1b3-c577df02e01b
-> ../../sda9
lrwxrwxrwx 1 root root  10 Dec 18 13:02 6bcb2a05-33c9-402b-8093-e6a35ffd7aa1
-> ../../sda8
lrwxrwxrwx 1 root root  11 Dec 18 13:05 82e52787-6072-4af9-a5e6-2d88c365e62b
-> ../../loop0
lrwxrwxrwx 1 root root  10 Dec 18 13:02 c5591eff-0a6c-4310-bb11-7d5535f7da7b
-> ../../sda7
lrwxrwxrwx 1 root root  10 Dec 18 13:05 e289e4ad-be1d-42a8-9b38-f4dad9473520
-> ../../dm-0
lrwxrwxrwx 1 root root  10 Dec 18 13:02 ea8202e7-4564-424c-af70-a6a640fafb65
-> ../../sda5
~

I'll do the 'debug' addition later this weekend, like you requested.

Finally, you asked:

> Do you have any custom udev rules in /etc/udev/rules.d?

I don't think so, looking at the time stamps nothing has been changed there for 
years:

total 10
drwxr-xr-x 2 root root 3072 Dec  6  2014 ./
drwxr-xr-x 4 root root 1024 Dec  3 08:34 ../
-rw-r--r-- 1 root root  115 Dec  6  2014 70-automount.rules
-rw-r--r-- 1 root root 3841 Dec  6  2014 70-persistent-cd.rules
-rw-r--r-- 1 root root  895 Feb 26  2013 70-persistent-net.rules

And I definitely didn't recently change there any files, so again: the problem
appeared out of the blue since last weeks upgrade. 

I hope the above gives you at least some additional info. As I wrote: I'll do
the 'debug' addition tomorrow.

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Dear Michael Biebl, you wrote:

> The verbose debug log from the initramfs and systemd can maybe tell us
> more. But looking at https://www.icce.rug.nl/systemd/journalctl, the
> sda5 mount happens at line 773, the first errors start at line 785 and
> the remount is at line 802.
> So it looks like /usr is not mounted at the time
> systemd-remount-fs.service is run.

Right. That's consistent with the impression I got from the error messages.
*Why* that is true, however, eludes me.

> 
> What's also curious is, that the log doesn't seem to be complete.
> Usually systemd's first log line is something like
> 
> > Dez 18 07:03:47 pluto systemd[1]: systemd 228 running in system mode. (+PAM 
> > +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> > +GCRYPT +GNUTLS +ACL +X
> > Dez 18 07:03:47 pluto systemd[1]: Detected architecture x86-64.
> 
> Those early boot messages seem to be missing completely.

Well, I didn't edit anything. The information I generated is passed to you the
way it was made available by the various programs/commands.


> Btw, you mentioned that this happened after an upgrade. Which previous
> version did you run which worked fine? Which other packages were
> upgraded along with it?

Is there a way to determine that? What I do to upgrade the system is run
'aptitude update' and then 'aptitude upgrade'. Is there a log somewhere that
tells me what packages and versions were updated at what moments in time?


> If you downgrade systemd/udev, does the problem go away?

I thought about doing that, but was afraid for an avalanche of forced
downgrades of packages that might now depend on the most recent udev and
systemd versions. But I'll give it a try asap and let you know the results.

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Dear Michael Biebl, you wrote:

> What happens afterwards? Are you dropped into the rescue shell?

Afterwards (i.e., after the initial failure message) the system tries to
continue booting, but shows lots of failure messages, eventually grinding to a
halt. No reboot (e.g. ctrl-alt-del) is possible and there's no rescue shell.

> If not, try to enable the debug shell by adding "systemd.debug-shell" to
> the kernel command line. This will give you a root shell on tty9.

Unfortunately, it doesn't, since the system halts (I first removed the
automatic reboot on failure).

However, during the process I observed that setting systemd.debug-shell and
removing the default 'quiet' specification from grub's /etc/default/grub (so,
now it specifies:

GRUB_CMDLINE_LINUX_DEFAULT="systemd.debug-shell" 

greatly reduces the chances of a failing boot. Not completely, but
greatly. Still, when rebooting fails there's just the plain halt, w/o a debug
shell. Since removing the quiet also produces a lot more output on the screen,
might my problem not simply be some timing problem?


-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#808151: systemd: failed to start remount root and kernel file system

[Frank B. Brokken]

Dear Michael Biebl, you wrote:
> Am 17.12.2015 um 13:46 schrieb Frank B. Brokken:

> > halt. No reboot (e.g. ctrl-alt-del) is possible and there's no rescue 
> > shell> 
> What exactly do you mean with halt? The systems completely locks up so
> you can't use the keyboard and switch to tty9?

No, that's not what happens. I mean that doing a reboot using ctrl-alt-del
isn't possible. Switching VTs is no problem, but except for VT1 nothing was
being shown. But maybe I overlooked things when I sent you the previous reply:
see below.

> That would sound like a kernel problem.

> > might my problem not simply be some timing problem?
> 
> Can you make a screenshot or a video from the boot process with "quiet"
> removed from the kernel command line.

I did. Not only that, I also tried to reboot again and this time I was able to
run the commands you asked before from tty9:

systemctl status
systemd-analyze dump
journalctl -alb

This time the debug shell prompt was available at tty9, although booting
failed. And in line with my previous findings, systemd-analyze and journalctl
weren't available, as they live in /usr/bin, and /usr hadn't been mounted. But
after mounting /usr from tty9 and then using the mount command systemd-analyze
and journalctl were available, so I also have the output from those commands
for you. The output, and the mp4 movie I made during the booting process are a
bit too large for the e-mail, but they are available for download/inspection
at https://www.icce.rug.nl/systemd/

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#808016: bisonc++: FTBFS: [icmake/readlog, line 5] Error: conflicting operand types for fgets

[Frank B. Brokken]

Dear Chris Lamb, you wrote:
> Source: bisonc++
> Version: 4.11.00-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> bisonc++ fails to build from source in unstable/amd64:

Ha! I beat you here by 1/2 day :-) 

Yesterday I prepared a new release, among other adapting the scripts to icmake
8.00.04 and updated the Debian files accordingly. We're now at bisonc++
4.13.00, and the new package should be available RSN.

@Tony: could you add a Closed #808016 entry to Debian's changelog, please?



scripts and 
> 
>   [..]
> 
>   # Add here commands to clean up after the build process.
>   ./build clean
>   [icmake/md, line 15] Warning: `sizeof' is deprecated. Use `listlen'
>   ...
>   2 error(s) detected
>   debian/rules:52: recipe for target 'clean' failed
>   make: *** [clean] Error 1
> 
>   [..]

Cheers,

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#807734: bobcat: FTBFS: Error: double quote at end of string not found

[Frank B. Brokken]

Dear Chris Lamb, you wrote:

> bobcat fails to build from source in unstable/amd64:

>   ./build clean
>   [./build, line 38] Error: double quote at end of string not found
>   [./build, line 38] Error: Syntax error at `#include'
>   debian/rules:34: recipe for target 'clean' failed

Thanks! That's a plain old typo. But an update also including the required
changes for the icmake 8.00.04 upgrade is being prepared right now.

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA