Bug#1066136: NMU pending for #1066136

[Steinar H. Gunderson]

Control: tags 1066136 + pending

Hi,

I've prepared an NMU for python-xapian-haystack (versioned as
2.1.1-1+deb12u0.1) and uploaded it to DELAYED/14-day. (The unusually
long delay is since this is a stable upload.)

NMU diff is attached.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
diff -Nru python-xapian-haystack-2.1.1/debian/changelog python-xapian-haystack-2.1.1/debian/changelog
--- python-xapian-haystack-2.1.1/debian/changelog	2021-10-19 22:10:20.0 +0200
+++ python-xapian-haystack-2.1.1/debian/changelog	2024-03-19 23:35:19.0 +0100
@@ -1,3 +1,12 @@
+python-xapian-haystack (2.1.1-1+deb12u0.1) bookworm; urgency=medium
+
+  * Non-maintainer upload, to stable.
+  * Remove dependency on the django.utils.six module, which no longer exists,
+causing the package to be completely broken. Patch by Ole Peder Brandtzæg,
+based on reducing a patch from upstream. (Closes: #1066136)
+
+ -- Steinar H. Gunderson   Tue, 19 Mar 2024 23:35:19 +0100
+
 python-xapian-haystack (2.1.1-1) unstable; urgency=low
 
   [ Debian Janitor ]
diff -Nru python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch
--- python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch	1970-01-01 01:00:00.0 +0100
+++ python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch	2024-03-19 23:35:19.0 +0100
@@ -0,0 +1,32 @@
+Index: python-xapian-haystack-2.1.1/xapian_backend.py
+===
+--- python-xapian-haystack-2.1.1.orig/xapian_backend.py
 python-xapian-haystack-2.1.1/xapian_backend.py
+@@ -7,7 +7,6 @@ import re
+ import shutil
+ import sys
+ 
+-from django.utils import six
+ from django.conf import settings
+ from django.core.exceptions import ImproperlyConfigured
+ from django.utils.encoding import force_text
+@@ -346,7 +345,7 @@ class XapianSearchBackend(BaseSearchBack
+ def _get_ngram_lengths(value):
+ values = value.split()
+ for item in values:
+-for ngram_length in six.moves.range(NGRAM_MIN_LENGTH, NGRAM_MAX_LENGTH + 1):
++for ngram_length in range(NGRAM_MIN_LENGTH, NGRAM_MAX_LENGTH + 1):
+ yield item, ngram_length
+ 
+ for obj in iterable:
+@@ -356,8 +355,8 @@ class XapianSearchBackend(BaseSearchBack
+ def ngram_terms(value):
+ for item, length in _get_ngram_lengths(value):
+ item_length = len(item)
+-for start in six.moves.range(0, item_length - length + 1):
+-for size in six.moves.range(length, length + 1):
++for start in range(0, item_length - length + 1):
++for size in range(length, length + 1):
+ end = start + size
+ if end > item_length:
+ continue
diff -Nru python-xapian-haystack-2.1.1/debian/patches/series python-xapian-haystack-2.1.1/debian/patches/series
--- python-xapian-haystack-2.1.1/debian/patches/series	2021-10-19 22:10:20.0 +0200
+++ python-xapian-haystack-2.1.1/debian/patches/series	2024-03-19 23:35:19.0 +0100
@@ -1 +1,2 @@
 0001-Use-io.open-to-read-UTF-8-encoded-README-file.patch
+0002-Remove-dependency-on-six.patch

Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)

[Steinar H. Gunderson]

On Mon, Mar 04, 2024 at 07:34:06PM +0100, Sven Joachim wrote:
> Not really, these arches now default to a 64-bit time_t and therefore
> you get the conflicting types (suseconds_t is a long int,
> __suseconds64_t a long long int).  This has nothing to do with implicit
> function declarations.

It's a bit crazy that tv_usec changes type, it should be in [0,100)
no matter what tv_sec is:

struct timeval
{
#ifdef __USE_TIME_BITS64
  __time64_t tv_sec;/* Seconds.  */
  __suseconds64_t tv_usec;  /* Microseconds.  */
#else 
  __time_t tv_sec;  /* Seconds.  */
  __suseconds_t tv_usec;/* Microseconds.  */
#endif
};
#endif

But the fix is straightforward, no? Just change the offending test to something 
like

  CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);

and it should work no matter what type c.tv_usec is. Or, if you prefer
brace-initialization (which would prevent you from ever writing in a too-big
value, like 999 or something):

  CPPUNIT_ASSERT_EQUAL(decltype(c.tv_usec){99}, c.tv_usec);

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption

[Steinar H. Gunderson]

On Fri, Dec 30, 2022 at 12:04:29PM +0100, Tobias Frost wrote:
> (I'm currently take a look at 2.17, to see if I can get it packages, if I'm 
> succeeding,
> there will be an NMU announcement :))

If you are NMUing, could you orphan the package in the upload?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption

[Steinar H. Gunderson]

On Fri, Dec 30, 2022 at 11:04:46AM +0100, Tobias Frost wrote:
> I was trying to triage this CVE and *maybe* those revisions are related:
> 
> r1894937 ("apreq_parse_headers: Discard CRLF of folded values.")
> r1894940 ("reindent (no functional change).") 
> r1894977 ("Follow up to r1894937: Fix setting of empty value.")
> r1895054 ("Follow up to r1894937: Always eat CRLF at the end of header 
> value.")

Perhaps it's best to remove libapreq2 entirely? I don't use nor maintain it
anymore, it's been out of testing for a while, and there's this CVE.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups

[Steinar H. Gunderson]

On Thu, Sep 22, 2022 at 08:13:53PM +0200, Ondřej Surý wrote:
> I am sorry this has caused inconvenience for you, but the original problem 
> here was that the implicit inline-signing with the dnssec-policy was also 
> problematic and causing other problems, see the upstream issue: 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3381
> 
> Especially this: 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3381#note_308893

Sure, but that's not appropriate to change in a stable-security update.
You can ask the SRMs whether it is applicable for a stable update
(I would say no; the point of stable is that you know what issues
you have and don't get new ones), but you cannot just put it into
a security update unless they are positively required for the security
issues in question.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1020529: 1:9.16.33-1~deb11u1 security upgrade breaks DNSSEC setups

[Steinar H. Gunderson]

Package: bind9
Version: 1:9.16.33-1~deb11u1
Severity: grave

Hi,

After applying the security updates for DSA 5235-1, named completely breaks
and refuses to start. (This caused downtime in production for us.) The reason
seems to be that the patch includes a full minor version bump, including
policy changes such as:

5941.   [func]  Zones with dnssec-policy now require dynamic DNS or
inline-siging to be configured explicitly. [GL #3381]

Since we have DNSSEC zones (as is recommended!), and use dnssec-policy to
configure them (also recommended!) it dies on startup with

Sep 22 16:17:59 cirkus named[3045282]: /etc/bind/named.conf.local:388: 
'dnssec-policy;' requires dynamic DNS or inline-signing to be configured for 
the zone
Sep 22 16:17:59 cirkus named[3045282]: loading configuration: failure
Sep 22 16:17:59 cirkus named[3045282]: exiting (due to fatal error)

It seems that one can change add “inline-signing yes;” manually to each zone
to work around it, but this is not the kind of change that really should be
done in a security update without a very good reason _and_ a very clear
warning. :-)

It seems the test suite even had to be changed for this change, which should
have been a pretty clear red flag:

  
https://salsa.debian.org/dns-team/bind9/-/commit/9036610e13ed037f776460d7806ea0a0e3841bdf#6f59e8ac2674d0c1120aa79f6f2ac2aa946d99e5

I haven't checked if there are other breaking changes.

-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.10 (SMP w/56 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bind9 depends on:
ii  adduser   3.118
ii  bind9-libs1:9.16.27-1~deb11u1
pn  bind9-utils   
pn  bind9utils
ii  debconf [debconf-2.0] 1.5.77
ii  dns-root-data 2021011101
ii  init-system-helpers   1.60
ii  iproute2  5.10.0-4
pn  libbind9-140  
pn  libbind9-161  
ii  libc6 2.31-13+deb11u4
ii  libcap2   1:2.44-1
ii  libcom-err2 [libcomerr2]  1.46.2-2
pn  libdns1104
pn  libdns162 
ii  libfstrm0 0.6.0-1+b1
ii  libgeoip1 1.6.12-7
ii  libgssapi-krb5-2  1.18.3-6+deb11u2
pn  libirs141 
pn  libisc1100
pn  libisc160 
pn  libisccc140   
pn  libisccc161   
pn  libisccfg140  
pn  libisccfg163  
pn  libjson-c3
ii  libjson-c50.15-2
ii  libk5crypto3  1.18.3-6+deb11u2
ii  libkrb5-3 1.18.3-6+deb11u2
ii  liblmdb0  0.9.24-1
pn  liblwres141   
pn  liblwres161   
ii  libmaxminddb0 1.5.2-1
ii  libnghttp2-14 1.43.0-1
ii  libprotobuf-c11.3.3-1+b2
pn  libssl1.0.2   
ii  libssl1.1 1.1.1n-0+deb11u3
ii  libuv11.40.0-2
ii  libxml2   2.9.10+dfsg-6.7+deb11u2
ii  lsb-base  11.1.0
ii  net-tools 1.60+git20181103.0eebece-1
ii  netbase   6.3
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.16.27-1~deb11u1
pn  bind9-doc  
ii  dnsutils   1:9.16.27-1~deb11u1
pn  resolvconf 
pn  ufw

-- Configuration Files:
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]

Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption

[Steinar H. Gunderson]

On Fri, Aug 26, 2022 at 09:07:06PM +0200, Salvatore Bonaccorso wrote:
> The following vulnerability was published for libapreq2.
> 
> CVE-2022-22728[0]:
> | A flaw in Apache libapreq2 versions 2.16 and earlier could cause a
> | buffer overflow while processing multipart form uploads. A remote
> | attacker could send a request causing a process crash which could lead
> | to a denial of service attack.

Based on the description, I assume it is this one:

http://svn.apache.org/viewvc?view=revision=1866760

I'm not sure if it counts as “buffer overflow”, but given that it only
mentions DoS and not arbitrary code execution, NULL pointer dereference
looks a lot like it. 2.13 appears vulnerable to me, given the description.

I don't use libapreq2 anymore, so anyone wanting to pick up the package
would be more than welcome. Upstream homepage is now seemingly at:

  https://httpd.apache.org/apreq/

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#996167: dpkg: unrecoverable fatal error, aborting: unknown system group 'plocate' in statoverride file;

[Steinar H. Gunderson]

On Mon, Oct 11, 2021 at 06:17:51PM +, Thorsten Glaser wrote:
>> Is there any good reason why the plocate group would disappear
>> that you know of?
> Not that… wait, doesn’t schroot copy groups? Let me see…
> 
> AH! It does! And since my main system is now
> bullseye, not sid, this is the first time it broke. In this
> case, my sincere apology for the report.

Thanks for the quick reply!

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#996167: dpkg: unrecoverable fatal error, aborting: unknown system group 'plocate' in statoverride file;

[Steinar H. Gunderson]

On Mon, Oct 11, 2021 at 07:33:19PM +0200, Thorsten Glaser wrote:
> Package: plocate
> Version: 1.1.12-1
> Severity: critical
> Justification: breaks unrelated software
> X-Debbugs-Cc: t...@mirbsd.de
> 
> I'm encountering this:
> 
> [... apt-get dist-upgrade ...]

Can you say something about what you are upgrading from and to?
Is there any good reason why the plocate group would disappear
that you know of?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#988604: plocate: autopkgtest regression: plocate and mlocate can't be co-installed anymore

[Steinar H. Gunderson]

On Sun, May 16, 2021 at 10:46:30PM +0200, Paul Gevers wrote:
>> Thanks for noticing. Given how annoying everything in autopkgtest is,
>> perhaps the easiest thing is just deleting the tests. (1.1.7-3 wouldn't
>> migrate to bullseye, then, but that's fine.)
> As it stands, you'd only need to remove the third test, not all three.

This is true, but the ergonomics of autopkgtest have been a huge
disappointment for me in general (plocate was the first, and so far only,
package I've tried it on), and I'm not convinced they are likely to catch
any real bugs in the package.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#988604: plocate: autopkgtest regression: plocate and mlocate can't be co-installed anymore

[Steinar H. Gunderson]

On Sun, May 16, 2021 at 09:17:57PM +0200, Paul Gevers wrote:
> With a recent upload of plocate the autopkgtest of plocate fails in
> testing when that autopkgtest is run with the binary packages of plocate
> from unstable. It passes when run with only packages from testing. In
> tabular form:

Thanks for noticing. Given how annoying everything in autopkgtest is,
perhaps the easiest thing is just deleting the tests. (1.1.7-3 wouldn't
migrate to bullseye, then, but that's fine.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#988286: plocate: missing Breaks: mlocate

[Steinar H. Gunderson]

forcemerge 976321 988286
thanks

On Sun, May 09, 2021 at 07:01:07PM +0200, Andreas Beckmann wrote:
> The list of installed files at points (1) and (2) should be identical,
> but the following files have disappeared:
> 
>   /etc/updatedb.conf
>   /usr/share/man/man5/updatedb.conf.5.gz

If so, I believe this is a dpkg issue; I asked #debian-dpkg about this at the
time, and was told sharing conffiles via Replaces: was explicitly allowed,
and unit tested for.

> This is a serious bug violating policy 7.6, see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

I don't see anything in 7.6 that says a Breaks is needed? Only that it is
commonly used.

Note that plocate is meant to be able to be installed alongside mlocate,
so Breaks: is not appropriate. But they share updatedb.conf (they read it
using the same code).

> and also see the footnote that describes this incorrect behavior:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

This link is probably not what you meant; it highlights this footnote:

Build-Depends in the source package is not adequate since it (rightfully)
does not document the exact version used in the build.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#979582: nageru: please drop the Build-Depends on libsrt-gnutls-dev which is RC-buggy

[Steinar H. Gunderson]

On Fri, Jan 08, 2021 at 05:36:58PM +0100, Paul Gevers wrote:
> The srt source package is RC buggy and has just been orphaned. We'll
> probably remove it soon from bullseye. nageru will go too then, unless
> it drop the (apparent optional) Build-Depends.

That's sad to hear. I'll drop the B-D in an upcoming upload; thanks for the
heads-up.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#974150: [Pkg-fonts-devel] Bug#974150: Noto Mono looks completely different after upgrade

[Steinar H. Gunderson]

On Tue, Nov 10, 2020 at 08:34:10PM +0100, Jonas Smedegaard wrote:
> Would you still find it relevant to pin the old font even if the new one 
> works but simply uses different visual style?

Yes. I find the new one fairly unreadable as a terminal font.

> Source for Debian package is https://github.com/googlefonts/noto-fonts/ 
> - but interestingly, the NotoMono fonts was renamed just 2 days after 
> our latest snapshot - with a totally unrevealing commit message of 
> "Published NotoTraditionalNushu hinted and unhinted static instances":
> https://github.com/googlefonts/noto-fonts/commit/1eda585
> 
> Seems Google changed their mind regarding the reuse of font name, and we 
> can go back to keeping the old legacy font alive...

It sounds they simply messed up the naming when uploading Noto Sans Mono,
and fixed it in that commit.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#974150: [Pkg-fonts-devel] Bug#974150: Noto Mono looks completely different after upgrade

[Steinar H. Gunderson]

On Tue, Nov 10, 2020 at 07:46:55PM +0100, Jonas Smedegaard wrote:
> Why the severity?
> 
> Visual changes does not seem reason release-critical to me.
> 
> "completely broken" need more than a vague suspicion, IMHO.

Feel free to downgrade. The background for the severity: I installed the
package to get a specific font, and that font suddenly disappeared and
was replaced by a completely different font. For me, that's completely
broken. If it's by intention, well... perhaps I'll need to pin the old one
indefinitely, then.

> Google dropped Noto Mono a few years ago.  We kept it alive, until 
> recently when Google re-introduced Noto Mono.

Huh, OK. But why is the web font different from the .ttf, then?
It doesn't make a lot of sense.

If I download the .ttf from https://www.google.com/get/noto/,
it looks like the one in stable. And https://github.com/googlefonts/noto-fonts
doesn't list any “Noto Mono” at all except “Noto Sans Mono”. Where's this new
font coming from?

> This shows which actual fonts are most likely used:
> 
>   fc-match -s 'Noto Mono' | head -n 5

Looks fine for me:

kos:~> fc-match -s 'Noto Mono' | head -n 5  

NotoMono-Regular.ttf: "Noto Mono" "Regular"
Vera.ttf: "Bitstream Vera Sans" "Roman"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"


> 
> 
> Thanks for reporting this,
> 
>  - Jonas
> 
-- 
Homepage: https://www.sesse.net/

Bug#974150: Noto Mono looks completely different after upgrade

[Steinar H. Gunderson]

Package: fonts-noto-mono
Version: 20201027-3
Severity: grave

Hi,

For unknown reasons, Noto Mono looks completely different after
I upgraded my unstable machines recently, to the point that it's
not the same font anymore (for one, it has serifs). This affects
multiple machines, both rxvt-unicode and gnome-terminal, both
X11 and Wayland, and goes away if I downgrade. Compare the stable
and unstable fonts below (the version of fonts-noto-mono installed
when urxvt started is the sole difference between the two windows):

  https://home.samfundet.no/~sesse/noto-mono.png

The upper (stable) also matches what the font looks like if I
look at https://www.google.com/get/noto/#mono-mono. You can see
some fragments of it in the screenshot; look at e.g. the lowercase
g.

gnome-terminal doesn't even list Noto Mono in its list of available
fonts, so I'm wondering if it does some sort of fallback and that
the font just is completely broken somehow.

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

On Fri, Oct 23, 2020 at 03:27:23PM +0200, Guillem Jover wrote:
> If we want to support the interim versions that have never been in a
> stable release, then I think the only way is to bump the minmum
> version in liburing shlibs and symbols files to 0.7, then rebuild the
> couple of packages built with 0.6 against 0.7, and then add Breaks in
> liburing against the old dependent package versions using the previous
> liburing releases.

Well, seemingly there are people who run old sid, and then only
“apt update ; apt install plocate” -- which will pull in newer plocate
but not liburing1 :-)

But all that _must_ be supported as per Policy is upgrades from stable to
stable, I believe? Not entirely sure how strict it is. It helps that
liburing1 has never been in stable (only stable-bpo).

> Otherwise I'll just package the new upstream release and request a
> rebuild of reverse dependencies, and we could just ignore 0.7 as if
> it never existed. :)

Yes, a soname bump would certainly do the trick for unstable.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

On Fri, Oct 23, 2020 at 12:41:36PM +0200, Julien Cristau wrote:
> All that's needed is a 0.8 release I guess.

Yes, that would fix it. Optionally, one would require something like
a Breaks: liburing (<< 0.7-2) added on all packages compiled against
liburing, plus versioned Breaks on liburing1 on all packages in the
archive ever built against pre-0.7. :-/

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote:
> https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd
> seems to have bumped SONAME upstream.

That would fix it, yes, but it seems to have missed the kflags change
(the commit says all added padding is at the end).

The kflags change was made a month or so before 0.7 release:

  
https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

On Fri, Oct 23, 2020 at 09:55:36AM +0200, Steinar H. Gunderson wrote:
> If this were somehow only about newer functionality or critical fixes, it 
> could
> be fixed by bumping the versioned dependency, but rhis goes both ways; if you
> build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1,
> you get a similar crash. So it would seem there's hidden ABI breakage here 
> that
> needs a soname bump.

It seems there's a new “unsigned *kflags;” added in the middle of
struct io_uring_cq that would explain this.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

Package: liburing1
Version: 0.7-1
Severity: grave
Tags: upstream

Hi,

I've had a number of reports from people who are having problems with plocate,
that can be traced to differing versions of liburing1. Specifically, plocate
is built in sid against liburing1 0.7-1 (which gets a versioned dependency
only on liburing1 >= 0.4), but if people instead have liburing1 0.6-3 on their
systems, they crash:

kos:~> plocate plocate md5sums
/home/sesse/nmu/plocate-1.0.2/debian/.debhelper/plocate/dbgsym-root/DEBIAN/md5sums
/home/sesse/nmu/plocate-1.0.2/debian/plocate/DEBIAN/md5sums
/var/lib/dpkg/info/plocate-dbgsym.md5sums
/var/lib/dpkg/info/plocate.md5sums

kos:~> sudo dpkg -i liburing1_0.6-3_amd64.deb 
[...]

kos:~> plocate plocate md5sums   
zsh: segmentation fault  plocate plocate md5sums

If this were somehow only about newer functionality or critical fixes, it could
be fixed by bumping the versioned dependency, but rhis goes both ways; if you
build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1,
you get a similar crash. So it would seem there's hidden ABI breakage here that
needs a soname bump.

/* Steinar */

Bug#964563: nageru: FTBFS: ../shared/httpd.cpp:47:25: error: invalid conversion

[Steinar H. Gunderson]

On Thu, Jul 09, 2020 at 09:41:16AM +0200, Sebastian Ramacher wrote:
> Looks like libmicrohttpd upstream didn't consider what it would mean for
> C++ users:
> https://lists.gnu.org/archive/html/libmicrohttpd/2020-07/msg00011.html

Indeed. But calling a function pointer through one of a different type is
undefined behavior even in C.

In any case, I'll need to add some #ifdefs, I believe.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#964563: nageru: FTBFS: ../shared/httpd.cpp:47:25: error: invalid conversion

[Steinar H. Gunderson]

On Wed, Jul 08, 2020 at 08:26:36PM +0200, Steinar H. Gunderson wrote:
> Has libmicrohttpd changed ABI or something? I assume the size of size_t
> hasn't changed :-)

Indeed, they broke the API:

Wed 08 Apr 2020 10:53:01 PM CEST
Introduce `enum MHD_Result` for #MHD_YES/#MHD_NO to avoid using 'int' so 
much.
Note that this change WILL cause compiler warnings until (most) MHD 
callbacks
in application code change their return type from 'int' to 'enum 
MHD_Result'.
That said, avoiding possible confusions of different enums is going to make
the code more robust in the future. For conditional compilation, test
for "MHD_VERSION >= 0x00097002". -CG

“Will cause compiler warnings”, aka errors in C++ and undefined behavior in C...

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#964563: nageru: FTBFS: ../shared/httpd.cpp:47:25: error: invalid conversion

[Steinar H. Gunderson]

On Wed, Jul 08, 2020 at 08:15:01PM +0200, Sebastian Ramacher wrote:
> | ../shared/httpd.cpp:47:25: error: invalid conversion from ‘int (*)(void*, 
> MHD_Connection*, const char*, const char*, const char*, const char*, size_t*, 
> void**)’ {aka ‘int (*)(void*, MHD_Connection*, const char*, const char*, 
> const char*, const char*, long unsigned int*, void**)’} to 
> ‘MHD_AccessHandlerCallback’ {aka ‘MHD_Result (*)(void*, MHD_Connection*, 
> const char*, const char*, const char*, const char*, long unsigned int*, 
> void**)’} [-fpermissive]
> |47 | _to_connection_thunk, this,
> |   | ^~~
> |   | |
> |   | int (*)(void*, MHD_Connection*, const 
> char*, const char*, const char*, const char*, size_t*, void**) {aka int 
> (*)(void*, MHD_Connection*, const char*, const char*, const char*, const 
> char*, long unsigned int*, void**)}

Has libmicrohttpd changed ABI or something? I assume the size of size_t
hasn't changed :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#956959: closed by Debian FTP Masters (reply to Dmitry Smirnov ) (Bug#956959: fixed in xpra 3.0.9+dfsg1-1)

[Steinar H. Gunderson]

reopen 956959
found 956959 3.0.9+dfsg1-1
thanks

On Mon, Apr 20, 2020 at 01:39:17AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the xpra package:
> 
> #956959: can no longer connect after dist-upgrading server

Hi,

Unfortunately, 3.0.9 does not solve the problem. (I've upgraded both on the
client and the server.)

sesse@bigscreen:~$ xpra start ssh:sgunders@10.172.139.131 --start=urxvt
2020-04-21 09:59:40,056 Xpra GTK3 X11 client version 3.0.9-r26127 64-bit
2020-04-21 09:59:40,205  running on Linux Debian unstable sid
2020-04-21 09:59:40,206  window manager is 'Mutter (Muffin)'
2020-04-21 09:59:40,224 Warning: failed to import opencv:
2020-04-21 09:59:40,224  No module named 'cv2'
2020-04-21 09:59:40,224  webcam forwarding is disabled
2020-04-21 09:59:40,506 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-04-21 09:59:40,587 No OpenGL_accelerate module loaded: No module named 
'OpenGL_accelerate'
2020-04-21 09:59:40,898 OpenGL enabled with GeForce GTX 950/PCIe/SSE2
2020-04-21 09:59:41,169 Connected (version 2.0, client OpenSSH_8.2p1)
2020-04-21 09:59:41,827 Authentication (publickey) successful!
2020-04-21 09:59:42,466 missing some build information: cannot import name 
'build_info' from 'xpra' (/usr/lib/python3/dist-packages/xpra/__init__.py)
2020-04-21 09:59:42,468  keyboard settings: rules=evdev, model=pc105, layout=no
2020-04-21 09:59:42,470  desktop size is 3840x2160 with 1 screen:
2020-04-21 09:59:42,470   :0.0 (1016x572 mm - DPI: 96x95) workarea: 3840x2120
2020-04-21 09:59:42,470 SAM HDMI-0 (521x293 mm - DPI: 187x187)
2020-04-21 09:59:42,512 Warning: the python netifaces package is missing
2020-04-21 09:59:42,630 Error: failed to receive anything, not an xpra server?
2020-04-21 09:59:42,630   could also be the wrong protocol, username, password 
or port
2020-04-21 09:59:42,630   or the session was not found
2020-04-21 09:59:42,631 Connection lost

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#951778: libva2: NULL vtable when querying nvidia render device

[Steinar H. Gunderson]

Package: libva2
Version: 2.6.1-1
Severity: grave

Hi,

It seems that after a recent full-upgrade, querying certain render nodes fails,
crashing my program; it is easily reproducible using vainfo:

  gruessi:~> vainfo --display drm --device /dev/dri/renderD129
  libva info: VA-API version 1.6.0
  vainfo: VA-API version: 1.6 (libva 2.6.0)
  vainfo: Driver version: 
  zsh: segmentation fault  vainfo --display drm --device /dev/dri/renderD129

The crash is in

  Program received signal SIGSEGV, Segmentation fault.
  0x77e254f2 in vaQueryConfigProfiles (dpy=0xd2d0, 
profile_list=0xdc10, 
  num_profiles=0x7fffe92c) at va.c:903
  903   va.c: Ingen slik fil eller filkatalog.
  (gdb) bt
  #0  0x77e254f2 in vaQueryConfigProfiles (dpy=0xd2d0, 
profile_list=0xdc10, 
  num_profiles=0x7fffe92c) at va.c:903
  #1  0x64e3 in ?? ()
  #2  0x77c73bbb in __libc_start_main (main=0x6370, argc=5, 
argv=0x7fffea48, 
  init=, fini=, rtld_fini=, 
stack_end=0x7fffea38)
  at ../csu/libc-start.c:308
  #3  0x68aa in ?? ()

It seems that somehow, the device is opened but gets a NULL vtable:

  (gdb) print *ctx
  $2 = {pDriverData = 0x0, vtable = 0x0, vtable_glx = 0x0, vtable_egl = 0x0, 
vtable_tpi = 0x0, 
native_dpy = 0x0, x11_screen = 0, version_major = 0, version_minor = 0, 
max_profiles = 0, 
max_entrypoints = 0, max_attributes = 0, max_image_formats = 0, 
max_subpic_formats = 0, 
max_display_attributes = 0, str_vendor = 0x0, handle = 0x0, drm_state = 
0xd2a0, glx = 0x0, 
display_type = 49, vtable_wayland = 0x0, vtable_vpp = 0x0, 
override_driver_name = 0x0, 
pDisplayContext = 0xd2d0, error_callback = 0x77e23540 
, 
info_callback = 0x77e23560 , reserved = {0 
}}

I can query renderD128, which corresponds to my Intel iGPU just fine.
renderD129 corresponds to my RTX 2070:

  gruessi:~> cat /sys/class/drm/renderD129/device/vendor
  0x10de
  gruessi:~> cat /sys/class/drm/renderD129/device/device
  0x1f02

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libva2 depends on:
ii  libc6  2.29-10

Versions of packages libva2 recommends:
ii  i965-va-driver-shaders [va-driver]  2.4.0-1
ii  intel-media-va-driver-non-free [va-driver]  19.4.0+ds1-1
ii  mesa-va-drivers [va-driver] 19.3.3-1
ii  va-driver-all   2.6.1-1

libva2 suggests no packages.

-- no debconf information

Bug#949264: nageru: FTBFS on arm/i386/mipsel architectures

[Steinar H. Gunderson]

On Mon, Jan 20, 2020 at 04:32:14PM -0500, Boyuan Yang wrote:
> In this case a rebuild might be worthwhile anyway. Rebuilding package is
> almost always harmless.

Well, rebuilding movit would fix it, but it would also break any reverse
dependency, so they would also need to be rebuilt. And if my theory is right,
this might affect other libraries (although taking in this specific type and
using C++ might not be that common).

> Are you going to trigger the rebuild recently? If not, I can help to trigger
> it through NMU.

I don't intend to do a Movit upload anytime soon, no, and I if I did one,
it would be unlikely to contain a soname bump.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#949264: nageru: FTBFS on arm/i386/mipsel architectures

[Steinar H. Gunderson]

On Sun, Jan 19, 2020 at 12:50:43AM -0500, Boyuan Yang wrote:
> Recent source-only rebuild for nageru has mulitple FTBFS architectures on
> buildd: https://buildd.debian.org/status/package.php?p=nageru
> 
> The tail log all reads like this:

It looks like the definition of GLsizeiptr is different between the movit and
nageru builds:

> ./obj-mipsel-linux-gnu/../nageru/timecode_renderer.cpp:51: undefined reference
> to `movit::generate_vbo(int, unsigned int, long, void const*)'
> /usr/bin/ld: ./obj-mipsel-linux-gnu/../nageru/timecode_renderer.cpp:51:
> undefined reference to `movit::generate_vbo(int, unsigned int, long, void
> const*)'

klump:~/dev/movit> nm --dynamic --demangle 
/usr/lib/i386-linux-gnu/libmovit.so.8 | grep vbo
0001b9a0 T movit::generate_vbo(int, unsigned int, int, void const*)   

Is this an ABI break caused by some recent Mesa change, perhaps? I guess one
could always rebuild Movit...

Seemingly it changed upstream from ptrdiff_t to khronos_ssize_t in Nov 2018,
but I don't know if that was the actual break. krhonos_ssize_t is defined as:

  typedef signed   long  int khronos_ssize_t;

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#939937: Acknowledgement (Remotely exploitable null pointer dereference bug)

[Steinar H. Gunderson]

On Wed, Sep 11, 2019 at 12:36:03PM +0200, Max Kellermann wrote:
> I committed my patch to libapreq's Subversion repository:
> 
>  http://svn.apache.org/viewvc?view=revision=1866760

Thanks! I'll make an upload to unstable when I get the time, but I guess the
security team should do one for stable. TBH I don't know how this process
works currently; perhaps security-team@ should be involved?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#939333: varnish: VSV00003 DoS attack vector

[Steinar H. Gunderson]

tags 939333 + patch
thanks

On Tue, Sep 03, 2019 at 02:27:33PM +0200, Salvatore Bonaccorso wrote:
> See https://varnish-cache.org/security/VSV3.html . A CVE does not
> seem yet to be assigned (but a request pending now).

I made a backport to 6.1.1 for stable. It consists of all changes between
6.2.0 and 6.2.1 in git, except:

 - No bumping of version number or changelog.
 - Removed some unrelated change of #include order in otherwise untouched
   files.
 - The tests are not included (probably should be; I removed them as part
   of trying to backport in a slightly different fashion).
 - bin/varnishtest/vtc_http.c needed additional changes from the 6.2.0 set
   to have the end pointer vct_iscrlf() and vct_skipcrlf() now need;
   since varnishtest is not meant to be run against untrusted servers,
   I changed the patch to simply use the old, insecure versions
   (now named vct_iscrlf_unsafe() and vct_skipcrlf_unsafe()).
 - The diff has been refreshed to fix line numbers.

With this patch in debian/patches/, Varnish compiles and appears to run
normally (we already use it in production).

/* Steinar */
-- 
Homepage: https://www.sesse.net/
Index: varnish-6.1.1/bin/varnishd/cache/cache_http.c
===
--- varnish-6.1.1.orig/bin/varnishd/cache/cache_http.c
+++ varnish-6.1.1/bin/varnishd/cache/cache_http.c
@@ -212,7 +212,8 @@ http_Proto(struct http *to)
 
 	fm = to->hd[HTTP_HDR_PROTO].b;
 
-	if ((fm[0] == 'H' || fm[0] == 'h') &&
+	if (fm != NULL &&
+	(fm[0] == 'H' || fm[0] == 'h') &&
 	(fm[1] == 'T' || fm[1] == 't') &&
 	(fm[2] == 'T' || fm[2] == 't') &&
 	(fm[3] == 'P' || fm[3] == 'p') &&
Index: varnish-6.1.1/bin/varnishd/http1/cache_http1_proto.c
===
--- varnish-6.1.1.orig/bin/varnishd/http1/cache_http1_proto.c
+++ varnish-6.1.1/bin/varnishd/http1/cache_http1_proto.c
@@ -111,6 +111,7 @@ http1_dissect_hdrs(struct http *hp, char
 unsigned maxhdr)
 {
 	char *q, *r, *s;
+	int i;
 
 	assert(p > htc->rxbuf_b);
 	assert(p <= htc->rxbuf_e);
@@ -121,31 +122,34 @@ http1_dissect_hdrs(struct http *hp, char
 
 		/* Find end of next header */
 		q = r = p;
-		if (vct_iscrlf(p))
+		if (vct_iscrlf(p, htc->rxbuf_e))
 			break;
 		while (r < htc->rxbuf_e) {
 			if (!vct_isctl(*r) || vct_issp(*r)) {
 r++;
 continue;
 			}
-			if (!vct_iscrlf(r)) {
+			i = vct_iscrlf(r, htc->rxbuf_e);
+			if (i == 0) {
 VSLb(hp->vsl, SLT_BogoHeader,
 "Header has ctrl char 0x%02x", *r);
 return (400);
 			}
 			q = r;
-			assert(r < htc->rxbuf_e);
-			r += vct_skipcrlf(r);
-			if (r >= htc->rxbuf_e)
+			r += i;
+			assert(r <= htc->rxbuf_e);
+			if (r == htc->rxbuf_e)
 break;
-			if (vct_iscrlf(r))
+			if (vct_iscrlf(r, htc->rxbuf_e))
 break;
 			/* If line does not continue: got it. */
 			if (!vct_issp(*r))
 break;
 
 			/* Clear line continuation LWS to spaces */
-			while (vct_islws(*q))
+			while (q < r)
+*q++ = ' ';
+			while (q < htc->rxbuf_e && vct_issp(*q))
 *q++ = ' ';
 		}
 
@@ -206,11 +210,9 @@ http1_dissect_hdrs(struct http *hp, char
 			return (400);
 		}
 	}
-	/* We cannot use vct_skipcrlf() we have to respect rxbuf_e */
-	if (p+2 <= htc->rxbuf_e && p[0] == '\r' && p[1] == '\n')
-		p += 2;
-	else if (p+1 <= htc->rxbuf_e && p[0] == '\n')
-		p += 1;
+	i = vct_iscrlf(p, htc->rxbuf_e);
+	assert(i > 0);		/* HTTP1_Complete guarantees this */
+	p += i;
 	HTC_RxPipeline(htc, p);
 	htc->rxbuf_e = p;
 	return (0);
@@ -224,7 +226,7 @@ static uint16_t
 http1_splitline(struct http *hp, struct http_conn *htc, const int *hf,
 unsigned maxhdr)
 {
-	char *p;
+	char *p, *q;
 	int i;
 
 	assert(hf == HTTP1_Req || hf == HTTP1_Resp);
@@ -265,26 +267,34 @@ http1_splitline(struct http *hp, struct
 	hp->hd[hf[1]].e = p;
 	if (!Tlen(hp->hd[hf[1]]))
 		return (400);
-	*p++ = '\0';
 
 	/* Skip SP */
+	q = p;
 	for (; vct_issp(*p); p++) {
 		if (vct_isctl(*p))
 			return (400);
 	}
-	hp->hd[hf[2]].b = p;
+	if (q < p)
+		*q = '\0';	/* Nul guard for the 2nd field. If q == p
+ * (the third optional field is not
+ * present), the last nul guard will
+ * cover this field. */
 
 	/* Third field is optional and cannot contain CTL except TAB */
-	for (; !vct_iscrlf(p); p++) {
-		if (vct_isctl(*p) && !vct_issp(*p)) {
-			hp->hd[hf[2]].b = NULL;
+	q = p;
+	for (; p < htc->rxbuf_e && !vct_iscrlf(p, htc->rxbuf_e); p++) {
+		if (vct_isctl(*p) && !vct_issp(*p))
 			return (400);
-		}
 	}
-	hp->hd[hf[2]].e = p;
+	if (p > q) {
+		hp->hd[hf[2]].b = q;
+		hp->hd[hf[2]].e = p;
+	}
 
 	/* Skip CRLF */
-	i = vct_skipcrlf(p);
+	i = vct_iscrlf(p, htc->rxbuf_e);
+	if (!i)
+		return (400);
 	*p = '\0';
 	p += i;
 
Index: varnish-6.1.1/include/vct.h
===
--- varnish-6.1.1.orig/include/vct.h
+++ varnish-6.1.1/include/vct.h
@@ -30,6 +30,8 @@
 
 /* from libvarnish/vct.c */
 
+#include "vas.h"
+
 #define VCT_SP			(1<<0)
 

Bug#934043: segfaults with use-after-free when using KrbServiceName Any

[Steinar H. Gunderson]

Package: libapache2-mod-auth-kerb
Version: 5.4-2.3
Severity: grave
Tags: patch upstream

Hi,

After upgrading to buster, mod_auth_kerb keeps on crashing Apache (thus the
grave severity), after printing

  double free or corruption (out)

This is indeed a use-after-free; verify_krb5_user gets in a keytab as a
parameter, and chooses to deallocate it even though the parent expects to keep
using it. I don't know why this didn't trigger as often in stretch,
although we've certainly seen mod_auth_kerb segfaults there as well
(especially with outdated keytabs).

The patch is trivial and can be found in upstream's bug tracker; just don't
deallocate the keytab in verify_krb5_user():

  https://sourceforge.net/p/modauthkerb/bugs/61/

This is not a leak, since the parent closes it inself, in all paths. I've 
verified
that it applies in Debian (just some changed line numbers) and fixes the issue.

Please consider for a buster point release, in addition to unstable.
It makes mod_auth_kerb borderline unusable.

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

Kernel: Linux 5.1.11 (SMP w/40 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libapache2-mod-auth-kerb depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.38-3
ii  krb5-config 2.6
ii  libc6   2.28-10
pn  libcomerr2  
ii  libgssapi-krb5-21.17-3
ii  libk5crypto31.17-3
ii  libkrb5-3   1.17-3

libapache2-mod-auth-kerb recommends no packages.

libapache2-mod-auth-kerb suggests no packages.

Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian

[Steinar H. Gunderson]

On Wed, May 08, 2019 at 10:02:46PM +0200, Mathieu Parent wrote:
> Downgrading the severity as the AppArmor side is already fixed it seems in 
> sid.

serious and grave are of equal severity; serious is for Policy violations
(e.g. package doesn't install), grave is for functionality issues
(e.g. program segfaults on start).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#928427: nageru: FTBFS in experimental: nageru/pbo_frame_allocator.h:36:8: error: ‘bmusb::FrameAllocator::Frame PBOFrameAllocator::create_frame(size_t, size_t, size_t)’ marked ‘override’, but does

[Steinar H. Gunderson]

On Sat, May 04, 2019 at 01:59:36PM +0200, Andreas Beckmann wrote:
> nageru/experimental FTBFS on all platforms:
> https://buildd.debian.org/status/package.php?p=nageru=experimental

It depends on newer bmusb, currently in NEW. I should probably add a
Build-Depends.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#928240: etw: Segmentation fault at start

[Steinar H. Gunderson]

On Wed, May 01, 2019 at 01:11:32AM +0200, Markus Koschany wrote:
> Thanks for providing a solution and a way forward. Could you provide a
> trivial fix/patch as well? I'm willing to test it and ask the release
> team for an unblock. I currently don't understand the underlying issue
> and why it was triggered in the first place but I gladly accept patches.

This appears to be the simplest way forward:

Index: etw-3.6+svn162/etw/prefix.c
===
--- etw-3.6+svn162.orig/etw/prefix.c
+++ etw-3.6+svn162/etw/prefix.c
@@ -113,7 +113,7 @@ br_locate (void *symbol)
 
 if (!fgets (line, sizeof (line), f))
 continue;
-if (!strstr (line, " r-xp ") || !strchr (line, '/'))
+if ((!strstr (line, " r-xp ") && !strstr(line, " r--p")) || !strchr 
(line, '/'))
 continue;
 
 sscanf (line, "%lx-%lx ", , );

I couldn't figure out the controls of the game itself, but at least it
appears to start up okay. :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#928240: etw: Segmentation fault at start

[Steinar H. Gunderson]

On Tue, Apr 30, 2019 at 11:23:52PM +0100, Simon McVittie wrote:
>> On a quick analysis: It appears that etw tries to find its own path by
>> opening /proc/self/maps (code is in etw/prefix.c), looking for an executable
>> mapping (r-xp) that contains the string "", and then looking at the path.
> This seems unnecessarily complicated? /proc/self/maps is Linux-specific,
> and if relying on Linux-specific things is acceptable, then
> evaluating the symlink /proc/self/exe seems a lot easier. (See
> e.g. Sys_FindExecutableName() in darkplaces.)

Yes; it seems to be written by someone whose primary experience was with
Windows, given that it talks about LINUX and not Linux. :-)

However, given that we are in deep freeze, you probably want the smallest
possible fix for buster.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#928240: etw: Segmentation fault at start

[Steinar H. Gunderson]

On Tue, Apr 30, 2019 at 04:38:14PM +0200, Bernat wrote:
> Running the game results in a segmentation fault.

On a quick analysis: It appears that etw tries to find its own path by
opening /proc/self/maps (code is in etw/prefix.c), looking for an executable
mapping (r-xp) that contains the string "", and then looking at the path.

At some point, string constants were no longer mapped as executable.
I can see two possible fixes here:

  1. Look for some actual executable symbol instead of ""; in particular,
 main seems to work.
  2. When parsing the file, accept r--p as equivalent to r-xp.

Both of these seem to fix the issue here.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian

[Steinar H. Gunderson]

On Tue, Apr 23, 2019 at 10:24:54PM +0200, Mathieu Parent wrote:
> There are several issues here. Trying a summary.
> 1. We need to patch bind9 apparmor profile (this is the cloned bug)

Yes.

> 2. The /var/lib/samba/bind-dns directory is created on domain
> provision. Nothing to do here?

It's not created on upgrade from stretch, though? You don't re-provision your
domain when upgrading Samba, yet upgrading should be allowed.

> 2. bind9 conf "include" should be updated. As the conffile is not
> owned by samba all we can do is printing a message in samba preinst
> (if include "/usr/local/samba/private/named.conf" is found in
> /etc/named/named.conf or /etc/bind/named.conf.local)

Yes.

> 3.Patching "named.conf" template to load the correct bind9 module (i.e 9.11)

I _think_ samba_dnsupgradedns writes a new config fragment.

> 4. Run "samba_upgradedns --dns-backend=BIND9_DLZ", but when?

I would assume in postinst (assuming we detect its use).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#927747: bind9_dlz backend is entirely broken in Debian

[Steinar H. Gunderson]

Package: samba
Version: 2:4.9.5+dfsg-3
Severity: grave

Hi,

I upgraded a DC from stretch to buster, and DNS for AD (via bind9_dlz)
started failing in strange ways. (In particular, when I changed the IP address
of the DC, samba-tool dns query would return the correct addresses, but actual
DNS lookups would return the old ones.) It turns out that upstream, bind9_dlz
data has moved from /var/lib/samba/private to /var/lib/samba/bind-dns; however,
there's no notice about this anywhere, and the path does not exist in Debian.
(Thus, the .conf file in use didn't even mention the BIND 9.11 .so file, much
less load it.) Furthermore, if you try to remedy this problem yourself by
mkdir-ing the new directory and running samba_dnsupgrade, BIND will no longer
start due to AppArmor policies being out of date:

  [84419.640664] audit: type=1400 audit(1555945763.230:88): apparmor="DENIED" 
operation="open" profile="/usr/sbin/named" 
name="/var/lib/samba/bind-dns/named.conf" pid=9043 comm="isc-worker" 
requested_mask="r" denied_mask="r" fsuid=111 ouid=0
  [84486.581899] audit: type=1400 audit(1555945830.170:89): apparmor="DENIED" 
operation="open" profile="/usr/sbin/named" 
name="/var/lib/samba/bind-dns/named.conf" pid=9171 comm="isc-worker" 
requested_mask="r" denied_mask="r" fsuid=111 ouid=0

Given that AppArmor now seems to be default on in buster, this breaks
the functionality completely, even for new installations (not just for
upgrades from stretch).

I would suppose that postinst needs to check whether BIND9_DLZ is in use,
and if so, run samba_upgradedns --dns-backend=BIND9_DLZ and then finally
pop up a message saying that the admin will have to change the .conf path
in named.conf.local. And the AppArmor profile will need to be fixed.

Even after this, I had to run samba_dnsupdate once with --use-samba-tool,
and then it would finally run without “dns_tkey_gssnegotiate: TKEY is
unacceptable” the next time.

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

Kernel: Linux 5.0.6 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages samba depends on:
ii  adduser  3.118
ii  dpkg 1.19.6
ii  init-system-helpers  1.56+nmu1
ii  libbsd0  0.9.1-2
ii  libc62.28-8
ii  libldb1  2:1.5.1+really1.4.6-3
ii  libpam-modules   1.3.1-5
ii  libpam-runtime   1.3.1-5
ii  libpopt0 1.16-12
ii  libpython2.7 2.7.16-2
ii  libtalloc2   2.1.14-2
ii  libtdb1  1.3.16-2+b1
ii  libtevent0   0.9.37-1
ii  libwbclient0 2:4.9.5+dfsg-3
ii  lsb-base 10.2019031300
ii  procps   2:3.3.15-2
ii  python   2.7.16-1
pn  python-dnspython 
pn  python-samba 
ii  python2.72.7.16-2
pn  samba-common 
pn  samba-common-bin 
ii  samba-libs   2:4.9.5+dfsg-3
pn  tdb-tools
ii  update-inetd 4.49

Versions of packages samba recommends:
ii  attr1:2.4.48-4
ii  logrotate   3.14.0-4
pn  samba-dsdb-modules  
pn  samba-vfs-modules   

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p12+dfsg-4
pn  smbldap-tools  
pn  ufw
pn  winbind

Bug#923773: logind sessions are ended immediately after login

[Steinar H. Gunderson]

severity 923773 normal
retitle 923773 broken fstab entries stop logind sessions in X
thanks

On Sun, Apr 14, 2019 at 10:56:17PM +0200, Michael Biebl wrote:
> Could you also please paste the output of
> grep pam_systemd /etc/pam.d/*

I think maybe I found it; it seems that there was a bad entry in fstab:

  april 14 23:08:08 klump systemd[1]: home-sesse.mount: Directory /home/sesse 
to mount over is not empty, mounting anyway.
  april 14 23:08:08 klump systemd[1]: Mounting /home/sesse...
  april 14 23:08:08 klump mount[781]: mount: /home/sesse: special device fake 
does not exist.
  april 14 23:08:08 klump systemd[1]: home-sesse.mount: Mount process exited, 
code=exited, status=32/n/a
  april 14 23:08:08 klump systemd[1]: home-sesse.mount: Failed with result 
'exit-code'.
  april 14 23:08:08 klump systemd[1]: Failed to mount /home/sesse.
  april 14 23:08:08 klump systemd[1]: Dependency failed for Session 2 of user 
sesse.

Should that really stop logind sessions from activating? Nevertheless,
downgrading.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#923866: aptly: unable to delete local repositories

[Steinar H. Gunderson]

On Wed, Mar 06, 2019 at 01:40:33PM +0100, Torsten Fichtner wrote:
> Package: aptly
> Version: 1.3.0+ds1-2+b10
> Severity: grave
> Justification: renders package unusable

Are you sure this makes the _entire_ package unusable? Not being able to delete
a local repository doesn't sound RC to me, if the rest of the package works.

> the aptly package in Buster seems to be broken. It is possible to create local
> repositories but unfortunately removing the previously created local
> repositories is impossible.

Seemingly it _appears_ to succeed, but doesn't:

klump:~> aptly repo create test
Config file not found, creating default config at /home/sesse/.aptly.conf
klump:~> aptly repo drop test  
Local repo `test` has been removed.
klump:~> aptly repo list
List of local repos:
 * [test] (packages: 0)

To get more information about local repository, run `aptly repo show `.

> The problem could be caused by the uuid patch.

I tried building without the patch (using go-uuid from Github instead),
and it doesn't change anything.

> The precompiled version from the website works properly

I tried the version from the upstream repository (deb http://repo.aptly.info/
squeeze main), and indeed, it works. Note that I have to clear out the entire
~/.aptly directory first and create a new repo; even the upstream version is
unable to drop test once it's in this broken state.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#909417: gtk-vnc: FTBFS randomly (vncconnectiontest fails with "assertion failed")

[Steinar H. Gunderson]

On Sat, Mar 09, 2019 at 07:26:52PM +0100, Santiago Vila wrote:
> Whoever wants to reproduce this (and possibly debug it), *please*
> contact me privately and I will gladly provide ssh access to a machine
> where it happens very often.

I've looked briefly into this.

First, to reproduce this reliably, simply restrict it to one core
(taskset -c 0 /build/gtk3/src/vncconnectiontest). The reason will be fairly
clear from the text below.

As far as I can see, this test simulates a broken VNC server (to test the
client's robustness). It says it's got a 100x100 true color display, but then
goes on and starts sending a color map.

As soon as the client receives the information about the color map,
it realizes something is wrong, and a race starts. Now the client wants to
close the connection at the same time as the fake server wants to keep
sending the cmap data. If you've got two cores, the server just keeps on
sending data happily; by the time it's noticed that the client is gone,
the test has passed and all is fine. But if you've only got one, then the
first byte of the cmap causes a context switch over to the client, which then
gets ample time to read the data and close the socket before the server gets
to send the next byte. The server thus gets EPIPE, and test_send_u16()
breaks.

I believe the right fix is to send every byte after the first “set color map”
byte using a non-asserting send. When we've done something invalid, we'd
better be ready for sending data to fail.

Please try the attached diff; it fixes the problem for me. I can NMU if the
maintainers want.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
Index: gtk-vnc-0.9.0/src/vncconnectiontest.c
===
--- gtk-vnc-0.9.0.orig/src/vncconnectiontest.c
+++ gtk-vnc-0.9.0/src/vncconnectiontest.c
@@ -56,12 +56,23 @@ static void test_send_u8(GOutputStream *
 g_assert(g_output_stream_write_all(os, , 1, NULL, NULL, NULL));
 }
 
+static void send_u8(GOutputStream *os, guint8 v)
+{
+g_output_stream_write_all(os, , 1, NULL, NULL, NULL);
+}
+
 static void test_send_u16(GOutputStream *os, guint16 v)
 {
 v = GUINT16_TO_BE(v);
 g_assert(g_output_stream_write_all(os, , 2, NULL, NULL, NULL));
 }
 
+static void send_u16(GOutputStream *os, guint16 v)
+{
+v = GUINT16_TO_BE(v);
+g_output_stream_write_all(os, , 2, NULL, NULL, NULL);
+}
+
 static void test_send_u32(GOutputStream *os, guint32 v)
 {
 v = GUINT32_TO_BE(v);
@@ -429,18 +440,18 @@ static void test_unexpected_cmap_server(
 test_recv_u16(is, 100);
 test_recv_u16(is, 100);
 
-/* set color map */
+/* set color map -- after this, the client may close the connection at any time */
 test_send_u8(os, 1);
 /* pad */
-test_send_u8(os, 0);
+send_u8(os, 0);
 /* first color, ncolors */
-test_send_u16(os, 0);
-test_send_u16(os, 1);
+send_u16(os, 0);
+send_u16(os, 1);
 
 /* r,g,b */
-test_send_u16(os, 128);
-test_send_u16(os, 128);
-test_send_u16(os, 128);
+send_u16(os, 128);
+send_u16(os, 128);
+send_u16(os, 128);
 }
 
 
@@ -505,11 +516,13 @@ static void test_overflow_cmap_server(GI
 test_send_u16(os, 65535);
 test_send_u16(os, 2);
 
+/* after this, the client may close the connection at any time */
+
 /* r,g,b */
 for (int i = 0 ; i < 2; i++) {
-test_send_u16(os, i);
-test_send_u16(os, i);
-test_send_u16(os, i);
+send_u16(os, i);
+send_u16(os, i);
+send_u16(os, i);
 }
 }
 

Bug#909865: diff for 2.2.1-4.1 NMU

[Steinar H. Gunderson]

Hi,

I've uploaded an NMU for this bug in DELAYED/7-day. Please see the attached
diff.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
diff -Nru openexr-2.2.1/debian/changelog openexr-2.2.1/debian/changelog
--- openexr-2.2.1/debian/changelog	2018-03-11 14:10:23.0 +0100
+++ openexr-2.2.1/debian/changelog	2019-03-20 22:40:43.0 +0100
@@ -1,3 +1,11 @@
+openexr (2.2.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * bug909865.patch: Add -ffloat-store when compiling tests, to fix test
+failures on i386. Patch backported from experimental. (Closes: #909865)
+
+ -- Steinar H. Gunderson   Wed, 20 Mar 2019 22:40:43 +0100
+
 openexr (2.2.1-4) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru openexr-2.2.1/debian/patches/bug909865.patch openexr-2.2.1/debian/patches/bug909865.patch
--- openexr-2.2.1/debian/patches/bug909865.patch	1970-01-01 01:00:00.0 +0100
+++ openexr-2.2.1/debian/patches/bug909865.patch	2019-03-20 22:40:02.0 +0100
@@ -0,0 +1,17 @@
+Description: Usual double rounding issue with x87
+Author: Mathieu Malaterre 
+Bug-Debian: https://bugs.debian.org/909865
+Forwarded: https://github.com/openexr/openexr/issues/346
+Last-Update: 2018-12-19
+
+--- openexr-2.3.0.orig/IlmImfTest/Makefile.am
 openexr-2.3.0/IlmImfTest/Makefile.am
+@@ -54,6 +54,8 @@ IlmImfTest_SOURCES = main.cpp tmpDir.h t
+ 
+ AM_CPPFLAGS = -DILM_IMF_TEST_IMAGEDIR=\"$(srcdir)/\"
+ 
++AM_CPPFLAGS += -ffloat-store
++
+ if BUILD_IMFHUGETEST
+ IlmImfTest_SOURCES += testDeepScanLineHuge.cpp testDeepScanLineHuge.h
+ AM_CPPFLAGS += -DENABLE_IMFHUGETEST
diff -Nru openexr-2.2.1/debian/patches/series openexr-2.2.1/debian/patches/series
--- openexr-2.2.1/debian/patches/series	2018-02-19 23:18:13.0 +0100
+++ openexr-2.2.1/debian/patches/series	2019-03-20 22:40:02.0 +0100
@@ -9,3 +9,4 @@
 bigendian_step2.patch
 bug815594.patch
 #CVE-2017-911x.patch
+bug909865.patch

Bug#916673: mandos : Depends: libgnutls30 (< 3.6.0) but 3.6.5-2 is to be installed

[Steinar H. Gunderson]

On Mon, Dec 17, 2018 at 10:57:44AM +0200, Adrian Bunk wrote:
> Package: mandos
> Version: 1.7.20-1
> Severity: serious
> 
> The following packages have unmet dependencies:
>  mandos : Depends: libgnutls28-dev (< 3.6.0) but 3.6.5-2 is to be installed or
>libgnutls30 (< 3.6.0) but 3.6.5-2 is to be installed
> 
> 
> Additionally, the libgnutls28-dev alternative of the dependencies
> looks wrong - this should likely just be libgnutls30.

The reason for the -dev dependency appears to be that the Python code does
something like

  from ctypes.util import find_library
  find_library('gnutls')

but that works just fine even without the -dev package installed (so either
libgnutls28 or libgnutls30 ought to do).

Actually, I wonder if using ${shlibs:Depends} would be fine, even for the
Python code. At least it would make transitioning this package much easier. :-)
Or move back to using python-gnutls; NEWS indicates that ctypes was used
because python-gnutls didn't support GnuTLS 3.3 at the time, but
python-gnutls indicates it has supported GnuTLS 3.4 since 2016.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#888778: nageru: build-depends on libluajit-5.1-dev, not available on s390x

[Steinar H. Gunderson]

On Mon, Jan 29, 2018 at 09:19:21PM +0100, Emilio Pozuelo Monfort wrote:
> Package: nageru
> Version: 1.6.4-1
> Severity: serious
> 
> Hi,
> 
> Your package now depends on libluajit-5.1-dev, which is not available on s390x
> (and other non-release architectures).

There's no way Nageru would run on s390x (it requires OpenGL and USB, for one).
Is s390x a release architecture these days? If so, I can simply exclude it
from the architecture list.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#880997: nageru: FTBFS on armel

[Steinar H. Gunderson]

On Tue, Nov 07, 2017 at 12:21:24PM +0200, Adrian Bunk wrote:
>> FWIW, last time I asked about this, it was a toolchain bug on armel
>> (std::atomic doesn't work). Is there any other information I should know
>> about?
> It is not true that std::atomic doesn't work on armel,
> and that's not what the error message is about.

If you can't use something from std:: without linking to an extra library,
it “doesn't work” in my world. :-) Especially given that it used to work just
fine.

> The following patch fixes the FTBFS on armel
> and the other architectures where nageru currently FTBFS:

I'll be happy to include the patch in the next upload, but I do consider it a
workaround (and in particular, I won't be pulling it upstream).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#880997: nageru: FTBFS on armel

[Steinar H. Gunderson]

On Mon, Nov 06, 2017 at 08:51:27PM +0100, Sebastian Ramacher wrote:
> | /usr/bin/ld: httpd.o: undefined reference to symbol 
> '__atomic_fetch_sub_8@@LIBATOMIC_1.0'
> | //usr/lib/arm-linux-gnueabi/libatomic.so.1: error adding symbols: DSO 
> missing from command line

FWIW, last time I asked about this, it was a toolchain bug on armel
(std::atomic doesn't work). Is there any other information I should know
about?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#865530: nageru rebuild on arm* [Was: Bug#865530: nageru FTBFS on armhf/armel: error: '::glBindTexture' has not been declared]

[Steinar H. Gunderson]

On Mon, Jul 03, 2017 at 11:32:17AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> I have uploaded qtbase with a backported patch that should fix this. Please 
> ask for a give back with a dep wait on qtbase-opensource-src 5.7.1+dfsg-4 on 
> arm*

Hi wanna-build team,

Could you please rebuild Nageru on arm* as requested by Lisandro?

gb nageru_1.6.0-2 . armel armhf . -m 'qtbase-opensource-src (>= 5.7.1+dfsg-4)'

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#866512: SIGFPE when encoding H.264 video

[Steinar H. Gunderson]

reassign 866512 nageru
tags 866512 + pending
thanks

On Fri, Jun 30, 2017 at 10:22:49AM +0200, Sebastian Ramacher wrote:
>>> 1.8.3-1 just got accepted. Could you please test if the issue persits with 
>>> that
>>> version? If it's still there, we should take this upstream.
>> 1.8.3-1 has same issue.
> Thanks for checking. I've forwarded the issue upstream.

Upstream found out that it's a bug in Nageru, triggered by the fact that
1.8.x now supports VBR rate control. I have a fix in git, which will go into
the 1.6.1 release.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#866512: SIGFPE when encoding H.264 video

[Steinar H. Gunderson]

On Thu, Jun 29, 2017 at 09:13:36PM +0200, Sebastian Ramacher wrote:
> 1.8.3-1 just got accepted. Could you please test if the issue persits with 
> that
> version? If it's still there, we should take this upstream.

1.8.3-1 has same issue.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#866512: SIGFPE when encoding H.264 video

[Steinar H. Gunderson]

On Thu, Jun 29, 2017 at 09:13:36PM +0200, Sebastian Ramacher wrote:
> 1.8.3-1 just got accepted. Could you please test if the issue persits with 
> that
> version? If it's still there, we should take this upstream.

I don't see it on the mirrors yet. Will give it a try when I do.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#866512: SIGFPE when encoding H.264 video

[Steinar H. Gunderson]

Package: i965-va-driver
Version: 1.8.2-2
Severity: grave

Hi,

After dist-upgrading, I can no longer start nageru without a segfault:

  Thread 13 "QS_Encode" received signal SIGFPE, Arithmetic exception.
  [Switching to Thread 0x7fffbaa7e700 (LWP 8583)]
  0x7fffc0bfab37 in intel_mfc_brc_postpack_vbr (frame_bits=3696, 
  encoder_context=0x565487d0, encode_state=0x5653dff8)
  at gen6_mfc_common.c:402
  402   gen6_mfc_common.c: Ingen slik fil eller filkatalog.
  (gdb) bt
  #0  0x7fffc0bfab37 in intel_mfc_brc_postpack_vbr (frame_bits=3696, 
  encoder_context=0x565487d0, encode_state=0x5653dff8)
  at gen6_mfc_common.c:402
  #1  intel_mfc_brc_postpack (encode_state=encode_state@entry=0x5653dff8, 
  encoder_context=encoder_context@entry=0x565487d0, 
  frame_bits=frame_bits@entry=3696) at gen6_mfc_common.c:484
  #2  0x7fffc0c1586f in gen75_mfc_avc_encode_picture (
  encoder_context=, encode_state=0x5653dff8, 
  ctx=0x564f3500) at gen75_mfc.c:1707
  #3  gen75_mfc_pipeline (ctx=0x564f3500, profile=, 
  encode_state=0x5653dff8, encoder_context=)
  at gen75_mfc.c:2529
  #4  0x7fffc0c58bac in intel_encoder_end_picture (ctx=0x564f3500, 
  profile=, codec_state=0x5653dff8, 
  hw_context=0x565487d0) at i965_encoder.c:1327
  #5  0x75111dbf in vaEndPicture ()
 from /usr/lib/x86_64-linux-gnu/libva.so.1
  #6  0x555f1a4d in QuickSyncEncoderImpl::encode_frame (
  this=this@entry=0x56068c70, frame=..., 
  encoding_frame_num=encoding_frame_num@entry=2, 
  display_frame_num=display_frame_num@entry=1, 
  gop_start_display_frame_num=gop_start_display_frame_num@entry=0, 
  frame_type=frame_type@entry=1, pts=16800, dts=14000, duration=4800, 
  ycbcr_coefficients=movit::YCBCR_REC_601) at quicksync_encoder.cpp:2045

Downgrading i965-va-driver to 1.7.3-1 (the version in stable) fixes the issue.

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

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

Versions of packages i965-va-driver depends on:
ii  libc6   2.24-11
ii  libdrm-intel1   2.4.81-2
ii  libdrm2 2.4.81-2
ii  libva1 [libva-driver-abi-0.40]  1.8.2-2

i965-va-driver recommends no packages.

i965-va-driver suggests no packages.

-- no debconf information

Bug#865530: nageru FTBFS on armhf/armel: error: '::glBindTexture' has not been declared

[Steinar H. Gunderson]

On Thu, Jun 29, 2017 at 01:10:20PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> The header if there at build time, but as it is exposed as public API you
> might need it too.

If Qt tries to #include a GLES header in its public headers, surely lack of
those headers would be en error message about missing .h file, not missing
symbol?

I can understand the situation being different for Qt build time, since I
assume Qt has some autoconf/CMake/whatever probing for headers.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#865530: nageru FTBFS on armhf/armel: error: '::glBindTexture' has not been declared

[Steinar H. Gunderson]

On Thu, Jun 29, 2017 at 10:49:42AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> I would first add libgles2-mesa-dev as a build dependency and try building
> nageru on arm. If it works maybe adding that dependency to
> libqt5opengl5-dev will do the trick (and I'm pretty confident that building
> nageru is much faster than building Qt).
> 
> If that works you will be able to drop it with Qt 5.9.

I don't have an unstable armhf installation, unfortunately. How would adding
a -dev package make any difference anyway? How would the Qt .h files know to
include the newly installed header?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#865530: nageru FTBFS on armhf/armel: error: '::glBindTexture' has not been declared

[Steinar H. Gunderson]

On Thu, Jun 29, 2017 at 04:38:26PM +0300, Dmitry Shachnev wrote:
> This was fixed in Qt 5.9 upstream, see this commit:
> https://code.qt.io/cgit/qt/qtbase.git/commit/?id=7e393280e4d07393
> 
> We are already working on a transition to Qt 5.9, so the fix should be
> available within a month.

OK. I'd like nageru to be available in testing so I can make backports to
stable, though. So should I upload with !armel !armhf for now?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#865530: nageru FTBFS on armhf/armel: error: '::glBindTexture' has not been declared

[Steinar H. Gunderson]

On Thu, Jun 29, 2017 at 09:52:22AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Normally the issue was with apps using GLU/GLUT because it has not been 
> ported 
> to GLES, so I first suspected this... but it seems not the issue.
> 
> ::glBindTexture is definitely not a Qt call:
> 
>  glBindTexture.xhtml>
> 
> So I would rather point at the libs implementing OpenGL ES.

I guess the question is whether Qt has included the GLES headers?
qopenglfunctions.h doesn't do it by itself, but I suppose it's meant to come
in through some indirect header?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#865530: nageru FTBFS on armhf/armel: error: '::glBindTexture' has not been declared

[Steinar H. Gunderson]

On Thu, Jun 22, 2017 at 11:59:15PM +0300, Adrian Bunk wrote:
> On Thu, Jun 22, 2017 at 02:41:17PM +0200, Steinar H. Gunderson wrote:
>> On Thu, Jun 22, 2017 at 03:35:33PM +0300, Adrian Bunk wrote:
>> > Am armel and armhf, Qt is compiled with OpenGL ES instead of full OpenGL.
>> 
>> Interesting. But isn't this a bug in qcustomplot, not nageru?
> 
> At first sight it actually looks like a bug in qtbase5-dev to me,
> adding the maintainer to Cc:

Hm, no response in a week. Should we simply mark nageru as not for
armhf/armel at this stage? I'm not sure it even works with GLES
(although Movit should, assuming you have at least GLES3).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#865530: nageru FTBFS on armhf/armel: error: '::glBindTexture' has not been declared

[Steinar H. Gunderson]

On Thu, Jun 22, 2017 at 03:35:33PM +0300, Adrian Bunk wrote:
> Am armel and armhf, Qt is compiled with OpenGL ES instead of full OpenGL.

Interesting. But isn't this a bug in qcustomplot, not nageru?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#865435: nageru FTBFS: mixer.cpp:159:72: error: invalid new-expression of abstract class type 'DeckLinkCapture'

[Steinar H. Gunderson]

On Wed, Jun 21, 2017 at 03:40:29PM +0300, Adrian Bunk wrote:
> Source: nageru
> Version: 1.4.2-2
> Severity: serious
> Tags: buster sid
> 
> https://buildd.debian.org/status/package.php?p=nageru=sid
> 
> ...
> g++ -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -std=gnu++11 -fPIC -pthread 
> -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGLExtensions 
> -I/usr/include/x86_64-linux-gnu/qt5 
> -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL 
> -I/usr/include/x86_64-linux-gnu/qt5 
> -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
> -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui 
> -I/usr/include/x86_64-linux-gnu/qt5 
> -I/usr/include/x86_64-linux-gnu/qt5/QtCore 
> -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/movit 
> -I/usr/include/lua5.2 -I/usr/include/p11-kit-1 -I/usr/include/libusb-1.0 
> -I/usr/include/eigen3 -pthread -DMOVIT_SHADER_DIR=\"/usr/share/movit\" 
> -Idecklink/ -o mixer.o -c mixer.cpp
> mixer.cpp: In constructor 'Mixer::Mixer(const QSurfaceFormat&, unsigned int)':
> mixer.cpp:159:72: error: invalid new-expression of abstract class type 
> 'DeckLinkCapture'
>  configure_card(card_index, new DeckLinkCapture(decklink, card_index), 
> /*is_fake_capture=*/false);

Hmm, why is it still trying to build 1.4.2? I thought I had uploaded 1.6.0
to unstable, which fixes this issue. Evidently not, so I'll make a re-upload.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#864793: crashes with JavaScript errors

[Steinar H. Gunderson]

Package: grafana
Version: 2.6.0+dfsg-3
Severity: grave

Hi,

After making a default installation of Grafana, I went to localhost:3000.
I got redirected to http://localhost:3000/login, which is black and otherwise
entirely blank (Chrome 59). The developer console says:

  Uncaught TypeError: Cannot read property 'indexOf' of undefined
  at 
public/vendor/angular-native-dragdrop/draganddrop.js?bust=1497481640638:25
  at 
public/vendor/angular-native-dragdrop/draganddrop.js?bust=1497481640638:390
  jquery.js?bust=1497481640638:3855 Uncaught Error: [$injector:modulerr] Failed 
to instantiate module ang-drag-drop due to:
  Error: [$injector:nomod] Module 'ang-drag-drop' is not available! You either 
misspelled the module name or forgot to load it. If registering a module ensure 
that you specify the dependencies as the second argument.
  http://errors.angularjs.org/1.4.3/$injector/nomod?p0=ang-drag-drop
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:68:12
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1958:17
  at ensure 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1882:38)
  at module 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1956:14)
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4362:22
  at forEach 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:336:20)
  at loadModules 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4346:5)
  at createInjector 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4272:11)
  at doBootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1630:20)
  at Object.bootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1651:12)
  
http://errors.angularjs.org/1.4.3/$injector/modulerr?p0=ang-drag-drop=Er…Fpublic%2Fvendor%2Fangular%2Fangular.js%3Fbust%3D1497481640638%3A1651%3A12)
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:68:12
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1958:17
  at ensure 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1882:38)
  at module 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1956:14)
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4362:22
  at forEach 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:336:20)
  at loadModules 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4346:5)
  at createInjector 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4272:11)
  at doBootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1630:20)
  at Object.bootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1651:12)
  
http://errors.angularjs.org/1.4.3/$injector/modulerr?p0=ang-drag-drop=Er…Fpublic%2Fvendor%2Fangular%2Fangular.js%3Fbust%3D1497481640638%3A1651%3A12)
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:68:12
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4385:15
  at forEach 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:336:20)
  at loadModules 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4346:5)
  at createInjector 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4272:11)
  at doBootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1630:20)
  at Object.bootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1651:12)
  at HTMLDocument. 
(http://localhost:3000/public/app/app.js?bust=1497481640638:85:19)
  at mightThrow 
(http://localhost:3000/public/vendor/jquery/dist/jquery.js?bust=1497481640638:3570:29)
  at process 
(http://localhost:3000/public/vendor/jquery/dist/jquery.js?bust=1497481640638:3638:12)

I can't find a workaround, and thus, the package seems entirely broken to me.

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

Kernel: Linux 4.11.2 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#864296: throws StopIteration exception, then immediately dies

[Steinar H. Gunderson]

On Wed, Jun 07, 2017 at 12:37:27AM +0300, Apollon Oikonomopoulos wrote:
> Looking at the message emitted by notification2.chess24.com ("Welcome to 
> socket.io."), it uses the old 0.9 socket.io protocol. Major socket.io 
> protocols are not backwards compatible and this version of 
> python-socketio-client supports only the 1.x socket.io protocol.

Compatibility or not, throwing a random internal exception isn't a good 
way of going about this, no? Shouldn't it then be some error message?

I agree that having an error message isn't RC, though.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#864296: throws StopIteration exception, then immediately dies

[Steinar H. Gunderson]

Package: python-socketio-client
Version: 0.6.5-0.1
Severity: grave

Hi,

Since upgrading to stretch, python-socketio-client no longer works for me at 
all.
I have code looking roughly this:

  #! /usr/bin/python
  from __future__ import print_function
  from socketIO_client import SocketIO
  from socketIO_client.exceptions import TimeoutError
  with SocketIO('https://notification2.chess24.com', 
transports=['xhr-polling'], verify=True) as socketIO:
pass

But all I get is this:

  DEBUG:requests.packages.urllib3.connectionpool:Starting new HTTPS connection 
(1): notification2.chess24.com
  
DEBUG:requests.packages.urllib3.connectionpool:https://notification2.chess24.com:443
 "GET /socket.io/?EIO=3=polling=1496761595949-0 HTTP/1.1
  " 200 None
  Traceback (most recent call last):
File "./chess24.py", line 198, in 
  with SocketIO('https://notification2.chess24.com', verify=True) as 
socketIO:
File "/usr/lib/python2.7/dist-packages/socketIO_client/__init__.py", line 
331, in __init__
  resource, hurry_interval_in_seconds, **kw)
File "/usr/lib/python2.7/dist-packages/socketIO_client/__init__.py", line 
51, in __init__
  self._transport
File "/usr/lib/python2.7/dist-packages/socketIO_client/__init__.py", line 
59, in _transport
  self._engineIO_session = self._get_engineIO_session()
File "/usr/lib/python2.7/dist-packages/socketIO_client/__init__.py", line 
73, in _get_engineIO_session
  transport.recv_packet())
  StopIteration

It seems there is indeed a stray “break” on line 73 that isn't caught by any
exception handler. Downgrading to jessie immediately fixes the problem.
WebSockets vs. XHR transport doesn't make a difference.

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

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

Versions of packages python-socketio-client depends on:
ii  python2.7.13-2
ii  python-requests   2.12.4-1
ii  python-six1.10.0-3
ii  python-websocket  0.37.0-2

python-socketio-client recommends no packages.

python-socketio-client suggests no packages.

-- debconf-show failed

Bug#863890: dblatex: postrm fails on jessie to stretch upgrade

[Steinar H. Gunderson]

On Mon, Jun 05, 2017 at 01:16:05PM +0200, Andreas Beckmann wrote:
>> I don't have a full list of pre-upgrade packages, but the command was a
>> standard “apt full-upgrade”. The deconfigure is presumably due to the
>> Breaks:, as Norbert mentioned.
> You should be able to find the logs for the actions taken/planned by apt
> for that upgrade in /var/log/apt/history.log*, the should help me
> reproduce the upgrade scenario.

Sure, but that's a different thing. :-) I've seen this on at least three
distinct installations, so I'm a bit surprised nobody else has reported it.
I'm attaching history.log.1 from one of the affected machines.

/* Steinar */
-- 
Homepage: https://www.sesse.net/


history.log.1.gz
Description: application/gzip

Bug#863890: postrm fails on jessie to stretch upgrade

[Steinar H. Gunderson]

On Sat, Jun 03, 2017 at 07:27:10PM +0200, Andreas Hoenen wrote:
> Changing this in stretch dblatex is easy (with a new version 0.3.9-3),
> but I'm not sure how a corresponding change in jessie dblatex (with a
> new version 0.3.5-3) would reach the jessie installations out there: is
> there any mechanism that upgrades jessie installations to the most
> recent jessie packages first before upgrading to stretch in a second
> step?

There's no mechanism for forcing upgrades through a middle version, no.
You can write something in the release notes asking to upgrade certain
packages before others, though.

> Or is it something that the users are told in the release notes?
> The only requirement I'm able to find there is upgrading to the latest
> stable point release [1].  Are there plans for a final jessie point
> release?

You'd have to ask the release managers for this.

> Another question: after releasing new dblatex jessie version 0.3.5-3, I
> need to incorporate the new jessie changelog entry into the changelog of
> the new dblatex stretch version 0.3.9-3, don't I?  Although this will
> add to the differences between 0.3.9-2 and 0.3.9-3, which the release
> managers request to keep as minimal as possible.

No, you don't need to do this. Packages can diverge, and the BTS understands
it.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#863890: postrm fails on jessie to stretch upgrade

[Steinar H. Gunderson]

Package: dblatex
Version: 0.3.5-2
Severity: serious

Hi,

When dist-upgrading from jessie to stretch, I've seen this happen on a number
of systems:

Removing dblatex (0.3.5-2) ...
/var/lib/dpkg/info/dblatex.postrm: 44: /var/lib/dpkg/info/dblatex.postrm: 
mktexlsr: not found
dpkg: error processing package dblatex (--remove):
 subprocess installed post-removal script returned error exit status 127
Removing texlive-math-extra (2014.20141024-1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
 dblatex
E: Sub-process /usr/bin/dpkg returned an error code (1)

This breaks the upgrade. It might be that we need a fix in jessie,
but I don't honestly know the best fix, as it seems to be about
removing the old package, not installing the new one. I've included a full
transcript below in case it helps:


[long list of downloads]
Fetched 1,549 MB in 1min 8s (22.6 MB/s) 
 
Traceback (most recent call last):
  File "/usr/bin/apt-listchanges", line 250, in 
main()
  File "/usr/bin/apt-listchanges", line 48, in main
debs = apt_listchanges.read_apt_pipeline(config)
  File "/usr/share/apt-listchanges/apt_listchanges.py", line 98, in 
read_apt_pipeline
del filenames[pkg]
KeyError: 'texlive-latex-recommended'
Extracting templates from packages: 100%
Preconfiguring packages ...
Deferring configuration of apt-listchanges until python3 is available
(Reading database ... 109184 files and directories currently installed.)
Preparing to unpack .../libkeyutils1_1.5.9-9_amd64.deb ...
Unpacking libkeyutils1:amd64 (1.5.9-9) over (1.5.9-5+b1) ...
Preparing to unpack .../libk5crypto3_1.15-1_amd64.deb ...
Unpacking libk5crypto3:amd64 (1.15-1) over (1.12.1+dfsg-19+deb8u2) ...
Preparing to unpack .../libgssapi-krb5-2_1.15-1_amd64.deb ...
Unpacking libgssapi-krb5-2:amd64 (1.15-1) over (1.12.1+dfsg-19+deb8u2) ...
Preparing to unpack .../libkrb5-3_1.15-1_amd64.deb ...
Unpacking libkrb5-3:amd64 (1.15-1) over (1.12.1+dfsg-19+deb8u2) ...
Preparing to unpack .../libkrb5support0_1.15-1_amd64.deb ...
Unpacking libkrb5support0:amd64 (1.15-1) over (1.12.1+dfsg-19+deb8u2) ...
Preparing to unpack .../libncurses5-dev_6.0+20161126-1_amd64.deb ...
Unpacking libncurses5-dev:amd64 (6.0+20161126-1) over (5.9+20140913-1+b1) ...
Replacing files in old package ncurses-bin (5.9+20140913-1+b1) ...
Preparing to unpack .../libtinfo-dev_6.0+20161126-1_amd64.deb ...
Unpacking libtinfo-dev:amd64 (6.0+20161126-1) over (5.9+20140913-1+b1) ...
Preparing to unpack .../binutils_2.28-5_amd64.deb ...
Unpacking binutils (2.28-5) over (2.25-5) ...
Preparing to unpack .../libc6-dev_2.24-10_amd64.deb ...
Unpacking libc6-dev:amd64 (2.24-10) over (2.19-18+deb8u6) ...
Preparing to unpack .../libc-dev-bin_2.24-10_amd64.deb ...
Unpacking libc-dev-bin (2.24-10) over (2.19-18+deb8u6) ...
Preparing to unpack .../linux-libc-dev_4.9.25-1_amd64.deb ...
Unpacking linux-libc-dev:amd64 (4.9.25-1) over (3.16.36-1+deb8u1) ...
Preparing to unpack .../libtinfo5_6.0+20161126-1_amd64.deb ...
Unpacking libtinfo5:amd64 (6.0+20161126-1) over (5.9+20140913-1+b1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up libtinfo5:amd64 (6.0+20161126-1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
(Reading database ... 109283 files and directories currently installed.)
Preparing to unpack .../libncursesw5_6.0+20161126-1_amd64.deb ...
Unpacking libncursesw5:amd64 (6.0+20161126-1) over (5.9+20140913-1+b1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Setting up libncursesw5:amd64 (6.0+20161126-1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
(Reading database ... 109283 files and directories currently installed.)
Preparing to unpack .../libncurses5_6.0+20161126-1_amd64.deb ...
Unpacking libncurses5:amd64 (6.0+20161126-1) over (5.9+20140913-1+b1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Setting up libncurses5:amd64 (6.0+20161126-1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
(Reading database ... 109283 files and directories currently installed.)
Preparing to unpack .../ncurses-bin_6.0+20161126-1_amd64.deb ...
Unpacking ncurses-bin (6.0+20161126-1) over (5.9+20140913-1+b1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up ncurses-bin (6.0+20161126-1) ...
(Reading database ... 109279 files and directories currently installed.)
Preparing to unpack .../zlib1g-dev_1%3a1.2.8.dfsg-5_amd64.deb ...
Unpacking zlib1g-dev:amd64 (1:1.2.8.dfsg-5) over (1:1.2.8.dfsg-2+b1) ...
Preparing to unpack .../zlib1g_1%3a1.2.8.dfsg-5_amd64.deb ...
Unpacking zlib1g:amd64 (1:1.2.8.dfsg-5) over (1:1.2.8.dfsg-2+b1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Setting up zlib1g:amd64 (1:1.2.8.dfsg-5) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
(Reading database ... 109277 files and directories currently 

Bug#863286: completely broken in non-US locales

[Steinar H. Gunderson]

Package: lua-http
Version: 0.1-1
Severity: grave
Tags: upstream

Hi,

lua-http cannot construct legal requests if a non-US locale (or more precisely,
anything using comma as decimal separator) is in use. Example:

  klump:~> cat test.lua
  os.setlocale('nb_NO.UTF-8')
  local http_request = require "http.request"
  local headers, stream = 
assert(http_request.new_from_uri("http://example.com;):go())
  local body = assert(stream:get_body_as_string())
  if headers:get ":status" ~= "200" then
  error(body)
  end
  print(body)
  
  klump:~> lua5.2 test.lua
  lua5.2: test.lua:6: 
  http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
  http://www.w3.org/1999/xhtml; xml:lang="en" lang="en">

505 - HTTP Version Not Supported


505 - HTTP Version Not Supported

  
  
  stack traceback:
[C]: in function 'error'
test.lua:6: in main chunk
[C]: in ?

This is because the request it constructs looks like this:

  GET / HTTP/1,1
  host: example.com
  user-agent: lua-http/0.1

Note the “1,1” in the HTTP version number where it should have been 1.1.

This makes the library completely broken for a large swath of Debian's user 
base;
thus the severity.

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

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

Bug#861383: grpc: Incomplete debian/copyright?

[Steinar H. Gunderson]

On Fri, Apr 28, 2017 at 05:19:16PM +0100, Chris Lamb wrote:
>>>   src/objective-c/!ProtoCompiler.podspec
>>>   src/python/grpcio/commands.py
>> I'm trying to figure out these; what's wrong with the current
>> attribution?
> The files are now elsewhere so a little difficult to look into this, but
> if you've checked them over please go ahead and re-upload. :)

I need to create something to look over the almost 1 copies of the BSD
3-clause license first; it's too much to do by hand. :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#861383: grpc: Incomplete debian/copyright?

[Steinar H. Gunderson]

On Fri, Apr 28, 2017 at 09:04:57AM +0100, Chris Lamb wrote:
>   src/objective-c/!ProtoCompiler.podspec
>   src/python/grpcio/commands.py

I'm trying to figure out these; what's wrong with the current attribution?
It looks like copyright holder is right (and largely the year, too), and the
license appears to be the same.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#861383: grpc: Incomplete debian/copyright?

[Steinar H. Gunderson]

On Fri, Apr 28, 2017 at 09:04:57AM +0100, Chris Lamb wrote:
> Source: grpc
> Version: 1.2.5-1+nmu0
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Steinar H. Gunderson <se...@debian.org>
> 
> Hi,
> 
> I just ACCEPTed grpc from NEW but noticed it was missing attribution 
> in debian/copyright for at least:
> 
>   src/objective-c/!ProtoCompiler.podspec
>   src/python/grpcio/commands.py
>   third_party/nanopb/
>   third_party/rake-compiler-dock/
>   [..]
> 
> (This is not exhaustive so please check over the entire package 
> carefully and address these on your next upload.)

Sounds good, I'll have a look tonight.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#860316: CVE-2017-7861

[Steinar H. Gunderson]

On Fri, Apr 14, 2017 at 03:06:35PM +0200, Moritz Muehlenhoff wrote:
> Source: grpc
> Severity: grave
> Tags: security
> 
> Please see
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7861 for details.

Since the packaging team seems to be dead, I've uploaded an NMU of gRPC 1.2.5
to unstable (it doesn't matter for the freeze, as it's not in stretch anyway).
It fixes this bug and all the other RC bugs. It's currently stuck in NEW,
since it has a soname bump, as well as new packages for libgrpc++ and the
protobuf compiler plugins.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#859217: closed by "Steinar H. Gunderson" <sgunder...@bigfoot.com> (Re: Bug#859217: nageru: just segfaults)

[Steinar H. Gunderson]

severity 859217 important
thanks

On Sat, Apr 01, 2017 at 02:34:13AM +0300, Adrian Bunk wrote:
> I am also getting segfaults when trying to start Nageru on my computer
> (old AMD card).
> 
> Whether Nageru is ever expected to work on my or Antonios computer is 
> one thing.
> 
> But failing with a segfault is clearly a bug in the error handling.
> 
> It is fine to display a window "Sorry, your hardware is not supported",
> segfaulting just causes user confusion. [1]

Hi,

While I agree failing to show a friendly message is a bug, I'm not sure
whether it fits the definition of grave (“makes the package in question
unusable or mostly so”). I'll try to investigate how easy it is to show
something friendlier -- I honestly don't know, and it would probably require
poking a bit around into Qt implementation details. At that point, it will
be up to the release team to see if they will accept an upload to stretch to
fix this bug.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#859217: nageru: just segfaults

[Steinar H. Gunderson]

On Fri, Mar 31, 2017 at 03:54:01PM -0300, Antonio Terceiro wrote:
>> Do you think you could supply a backtrace?
> argh, forgot the attachment.

I was hoping for a gdb backtrace, though, not an strace log.
But I think we're already getting to it.

>> Also, do you have working OpenGL? Can you say something about your GPU and
>> driver setup?
> 00:02.0 VGA compatible controller: Intel Corporation Core Processor 
> Integrated Graphics Controller (rev 02)
> 
> It's an old-ish integrated Intel graphics. Everything else just works AFAICT.

This sounds more “really old” than “old-ish” :-) It's not entirely clear
still what kind it is, though. Do you think you could supply an “lspci -n”
as well as “glxinfo”?

FWIW, Nageru requires support for OpenGL 3.1, which is now eight years old
(and lots of hardware older than eight years support it by means of newer
drivers).

>> Nageru does not support V4L devices, so no, you can't use your webcam.
>> But it will generate some fake sources for you (showing a single color).
> Do you have plans for supporting V4L? nageru seems really nice and it
> would be very useful to support lower end devices, for those who don't
> have special equipment (yet).

There are no such plans, sorry. I realize it would be useful for testing,
but if you're going out to build a rig from scratch, I don't know of any V4L
devices that are in the same league as the Blackmagic stuff (for the same
price), and supporting V4L means supporting a ton of different standards.
(It's really just an umbrella standard, where the device can choose to supply
pretty much whatever it wants, and dealing efficiently with a data stream
that can basically contain “whatever, and it might change at any time” is
very hard.) As it is, I have a long list of features I want to get to,
and I'm trying not to spread myself too thin. Again, sorry :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#859217: nageru: just segfaults

[Steinar H. Gunderson]

On Fri, Mar 31, 2017 at 02:41:12PM -0300, Antonio Terceiro wrote:
> I deciced to try nageru here, and it just segfaults:
> 
> $ nageru
> QEGLPlatformContext: Failed to create context: 3009
> QEGLPlatformContext: Failed to create context: 3009
> QEGLPlatformContext: Failed to create context: 3009
> Segmentation fault

Hi,

Do you think you could supply a backtrace?

Also, do you have working OpenGL? Can you say something about your GPU and
driver setup?

> I have no external camera connected, only the integrated webcam. I would 
> expect
> to be able to use it for a simple test.

Nageru does not support V4L devices, so no, you can't use your webcam.
But it will generate some fake sources for you (showing a single color).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#850226: no longer advertises route

[Steinar H. Gunderson]

On Sun, Jan 08, 2017 at 01:16:20AM +1100, Scott Leggett wrote:
> Though the broken versions appear to be different, this issue looks
> similar to an existing upstream bug:
> https://bugzilla.quagga.net/show_bug.cgi?id=870
> 
> Does this look like the same issue to you?

It might be the same, but it's hard to say. I use iBGP, but this route isn't
learned from iBGP; it's advertised out from the host in question (through a
network statement).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#850226: no longer advertises route

[Steinar H. Gunderson]

Package: quagga-bgpd
Version: 1.1.0-3
Severity: grave

Hi,

I lost all of my IPv6 connectivity this morning; a bit of searching shows that
it is due to an automated upgrade of:

  2017-01-05 07:36:26 upgrade quagga:amd64 1.0.20160315-2 1.1.0-3

None of the neighbors see my IPv6 route anymore; it is not in the table,
and the peers (over various GRE tunnels, using link-local addresses) say:

  altersex# show bgp neighbors fe80::5ccc:2ed1 routes 
  altersex# 

Similarly for another Quagga peer:

  pannekake.samfundet.no# show bgp neighbors fe80::5ccc:2ed1 routes 
  pannekake.samfundet.no# 

My side claims it's advertising the network to one of them, though:

  morgental# show bgp neighbors fe80::c30b:9a61 advertised-routes 
  BGP table version is 0, local router ID is 80.218.216.227
  Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
  Origin codes: i - IGP, e - EGP, ? - incomplete
  
 Network  Next HopMetric LocPrf Weight Path
  *> 2001:67c:29f4::/48
  fe80::5ccc:2ed1600  0 58302 i

But somehow not to the other one:

  morgental# show bgp neighbors fe80::6bbf:a185 advertised-routes 
  morgental# 

Restart of the daemon does not work, but downgrading Quagga back to
the previous version (1.0.20160315-3) immediately fixes the issue:

  pannekake.samfundet.no# show bgp neighbors fe80::5ccc:2ed1 routes 
  BGP table version is 0, local router ID is 129.241.93.35
  Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
  Origin codes: i - IGP, e - EGP, ? - incomplete
  
 Network  Next HopMetric LocPrf Weight Path
  *> 2001:67c:a4::/48 :: 600 0 48908 i
  
  Total number of prefixes 1
  pannekake.samfundet.no# 

Here's the entire Quagga config, for reference:

morgental# show run
Building configuration...

Current configuration:
!
hostname morgental
log file /var/log/quagga/quagga.log
log file /var/log/quagga/ospf6d.log
hostname fugl
log file /var/log/quagga/bgpd.log
bgp multiple-instance
!
service advanced-vty
!
debug ospf6 lsa unknown
debug bgp
!
password 
enable password 
!
interface bablefisk
 no link-detect
!
interface br0
 no link-detect
!
interface elfkin
 no link-detect
!
interface eno1
 no link-detect
!
interface enp2s0
 no link-detect
!
interface enp2s0.2
 no link-detect
!
interface enp2s0.3
 no link-detect
!
interface enp2s0.10
 no link-detect
!
interface enp2s0.11
 no link-detect
!
interface eth0
 no link-detect
!
interface eth0.2
 no link-detect
!
interface eth0.3
 no link-detect
!
interface eth0.4
 no link-detect
!
interface eth0.5
 no link-detect
!
interface eth0.10
 no link-detect
!
interface eth0.11
 no link-detect
!
interface eth0.2000
 no link-detect
!
interface eth2
 no link-detect
!
interface fnismc
 no link-detect
!
interface foo
 no link-detect
!
interface gre0
 no link-detect
!
interface gretap0
 no link-detect
!
interface he-ipv6
 no link-detect
!
interface ifb0
 no link-detect
!
interface ifb1
 no link-detect
!
interface ip6gre0
 no link-detect
!
interface ip6tnl0
 no link-detect
!
interface k_adamcik
 no link-detect
!
interface k_altersex
 no link-detect
 ipv6 ospf6 cost 1
 ipv6 ospf6 network broadcast
!
interface k_berge
 no link-detect
!
interface k_jodal
 no link-detect
!
interface k_klette
 no link-detect
!
interface k_kletteoslo
 no link-detect
!
interface k_magne
 no link-detect
 ipv6 ospf6 cost 1
 ipv6 ospf6 network broadcast
!
interface k_molven
 no link-detect
 ipv6 ospf6 cost 1
 ipv6 ospf6 network broadcast
!
interface k_molvenfinnoy
 no link-detect
!
interface k_pannekake
 no link-detect
!
interface k_sandsmark
 no link-detect
!
interface k_sesse
 no link-detect
 ipv6 ospf6 cost 1
 ipv6 ospf6 network broadcast
!
interface k_torvaldl
 no link-detect
!
interface k_trygve
 no link-detect
!
interface k_underworld
 no link-detect
!
interface k_wikene
 no link-detect
!
interface k_xml
 no link-detect
!
interface l2tpeth0
 no link-detect
!
interface lo
 no link-detect
!
interface merete
 no link-detect
!
interface nat64
 no link-detect
!
interface pan0
 no link-detect
!
interface pimreg
 no link-detect
!
interface renater
 no link-detect
!
interface sit0
 no link-detect
!
interface test
 no link-detect
!
interface tungre
 no link-detect
!
interface wlan0
 no link-detect
!
interface wlp3s0
 no link-detect
!
interface wmaster0
 no link-detect
!
router bgp 48908
 bgp router-id 80.218.216.227
 bgp always-compare-med
 bgp bestpath med missing-as-worst
 neighbor kvadratsky peer-group
 neighbor kvadratsky next-hop-self
 neighbor kvadratsky soft-reconfiguration inbound
 neighbor kvadratsky prefix-list kvadratsky in
 neighbor 2001:470:12:84::1 remote-as 6939
 neighbor 2001:470:12:84::1 update-source 2001:470:12:84::2
 neighbor 2001:470:12:84::1 next-hop-self
 neighbor 2001:470:12:84::1 

Bug#847135: openconnect: vpn connection mtu too big

[Steinar H. Gunderson]

On Mon, Dec 19, 2016 at 09:53:06AM -0800, Mike Miller wrote:
> That it affects only some people does not make it grave, but I'll
> compromise with serious. Regardless of severity, 7.08 is coming soon,
> which is expected to fix this. I hope you will update to it before it
> hits testing and let us know if there are still problems.

Hi,

serious and grave are actually equal severities -- serious is for Policy
violations, and grave is for functional issues. But the main point is that
it's RC, so that it gets properly tracked for stretch.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#818327: missing protoc plugin

[Steinar H. Gunderson]

On Wed, Mar 16, 2016 at 12:57:22AM +0100, Steinar H. Gunderson wrote:
> After looking around a bit, it looks like this (and the C++ version of the
> shared library) depends on protobuf 3.0.0 (beta) entering Debian, but I cannot
> find a bug for that to block this one with.

Seemingly 3.0.0-7 is now in testing (and may have been for a while).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#838638: [Cloud-packages] Bug#838638: /usr/bin/python3-google-api-tools broken; missing several dependencies, does not work even after doing so

[Steinar H. Gunderson]

On Fri, Sep 23, 2016 at 11:27:11PM +0200, Thomas Goirand wrote:
>> But in 2.7, there are tons of similar issues.
> Like what? I really don't think so.

pannekake:~> /usr/bin/python2-google-api-tools
Traceback (most recent call last):
  File "/usr/bin/python2-google-api-tools", line 6, in 
from googlecloudapis.apitools.base.py.base_cli import main
  File 
"/usr/lib/python2.7/dist-packages/googlecloudapis/apitools/base/py/__init__.py",
 line 12, in 
from googlecloudapis.apitools.base.py.transfer import *
  File 
"/usr/lib/python2.7/dist-packages/googlecloudapis/apitools/base/py/transfer.py",
 line 14, in 
import mimeparse
ImportError: No module named mimeparse

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#838638: [Cloud-packages] Bug#838638: /usr/bin/python3-google-api-tools broken; missing several dependencies, does not work even after doing so

[Steinar H. Gunderson]

On Fri, Sep 23, 2016 at 03:47:08PM +0200, Thomas Goirand wrote:
> If I'm not mistaking, that's not what's going on. httplib is a standard
> Python 2.7 library, but in Python 3, it was renamed as "http". So here,
> we're in a case of not-good-enough Python 3 support.

But in 2.7, there are tons of similar issues. And if I install all of the
packages that I seemingly need, I get:

  pannekake:~> /usr/bin/python2-google-api-tools
  Traceback (most recent call last):
File "/usr/bin/python2-google-api-tools", line 6, in 
  from googlecloudapis.apitools.base.py.base_cli import main
  ImportError: cannot import name main

> However, you've opened a bug against the wrong package. It's
> python3-googlecloudapis which you really wanted.

Is the above also in python3-googlecloudapis, or is it a separate issue,
so that we should split the bug?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#838638: /usr/bin/python3-google-api-tools broken; missing several dependencies, does not work even after doing so

[Steinar H. Gunderson]

Package: python3-google-apputils
Version: 0.4.1-1
Severity: grave

Hi,

python3-google-apputils packages /usr/bin/python3-google-api-tools, but
completely fails to declare the dependencies it needs:

  pannekake:~> /usr/bin/python3-google-api-tools
  Traceback (most recent call last):
File "/usr/bin/python3-google-api-tools", line 6, in 
  from googlecloudapis.apitools.base.py.base_cli import main
File 
"/usr/lib/python3/dist-packages/googlecloudapis/apitools/base/py/__init__.py", 
line 4, in 
  from googlecloudapis.apitools.base.py.base_api import *
File 
"/usr/lib/python3/dist-packages/googlecloudapis/apitools/base/py/base_api.py", 
line 4, in 
  import httplib
  ImportError: No module named 'httplib'


The same goes for the Python 2 version. It holds in both stable and unstable
(they have the same version).

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

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

Versions of packages python-google-apputils depends on:
ii  python   2.7.9-1
ii  python-dateutil  2.2-2
ii  python-gflags1.5.1-2
ii  python-tz2012c+dfsg-0.1

python-google-apputils recommends no packages.

python-google-apputils suggests no packages.

-- no debconf information

Bug#837397: broke SSH to HP devices

[Steinar H. Gunderson]

Package: rancid
Version: 3.5.0-1
Severity: grave

Hi,

We're running this through the jessie backport (3.5.0-1~bpo8+1), but given that
there are no changes (just a straight rebuild), I guess it should apply to the
base, too.

Since the upgrade, SSH to all of our HP switches have been broken:

  rancid@pannekake:~$ hrancid -d duskalhoremye.samfundet.no
  executing hlogin -t 90 -c"show version;show flash;show 
system-information;show system information;show module;show stack;show tech 
transceivers;show config files;show config status;write term" 
duskalhoremye.samfundet.no
  duskalhoremye.samfundet.no clogin error: Error: Couldn't login
  duskalhoremye.samfundet.no clogin error: Error: Couldn't login
  duskalhoremye.samfundet.no: missed cmd(s): all commands
  duskalhoremye.samfundet.no: End of run not found
  ;

It seems that somehow, it's picking up an empty cipher type and tries to
authenticate with that:

  rancid@pannekake:~$ hlogin -t 90 -c"show version;show flash;show 
system-information;show system information;show module;show stack;show tech 
transceivers" duskalhoremye.samfundet.no 
  duskalhoremye.samfundet.no
  spawn hpuifilter -- ssh -c  -x -l admin duskalhoremye.samfundet.no
  Unknown cipher type ''

  Error: Couldn't login

The only workaround I've found is to force one in .cloginrc for the given
device (nothing else has cyphertype):

  add cyphertype *.samfundet.no3des

But this is highly suboptimal -- it precludes negotiation of the strongest
possible cipher depending on the device.

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

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

Versions of packages rancid depends on:
ii  adduser 3.113+nmu3
ii  cvs 2:1.12.13+real-15
ii  debconf [debconf-2.0]   1.5.56
ii  expect  5.45-6
ii  git 1:2.8.0~rc3+next.20160316-1
ii  iputils-ping [ping] 3:20121221-5+b2
ii  libc6   2.19-18+deb8u4
ii  libperl4-corelibs-perl  0.003-1
ii  openssh-client  1:6.7p1-5+deb8u3
ii  passwd  1:4.2-3+deb8u1
ii  perl5.20.2-3+deb8u6
ii  ssh 1:6.7p1-5+deb8u3

rancid recommends no packages.

Versions of packages rancid suggests:
ii  diffstat  1.58-1

-- Configuration Files:
/etc/rancid/rancid.conf changed [not included]

-- debconf-show failed

Bug#833304: closed by se...@debian.org (Steinar H. Gunderson) (Bug#833304: fixed in nageru 1.3.4-1)

[Steinar H. Gunderson]

On Wed, Aug 03, 2016 at 12:16:10AM +0200, Chris Lamb wrote:
>> Fixes FTBFS. (Closes: #833304)
> This seems a little terse. Could you elaborate..?

I guess I could have pasted in the relevant commit from upstream:

  commit 156470e2dca8813f8eb736f52363e94501ab36f5
  Author: Steinar H. Gunderson <sgunder...@bigfoot.com>
  Date:   Tue Aug 2 22:46:01 2016 +0200

  Run IWYU on quicksync_encoder.{cpp,h}.

One of the effects of this was that #include  now was properly
#included. You can see the commit at

  
https://git.sesse.net/?p=nageru;a=commitdiff;h=156470e2dca8813f8eb736f52363e94501ab36f5

I normally don't put detailed upstream information in Debian changelogs,
though. In this case, it really is the new upstream version that fixes the
issue, so it's a simple sub-point of “new upstream release”; if something
changed in the Debian packaging, I do of course document it.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#833304: nageru: FTBFS: quicksync_encoder.cpp:996:15: error: 'close' was not declared in this scope

[Steinar H. Gunderson]

On Tue, Aug 02, 2016 at 10:41:02PM +0200, Chris Lamb wrote:
>> That's odd; I built it in a pbuilder, and several buildds have built it in
>> the past few days. Is there anything special about your setup?
> Not that I am aware of, sorry. Up-to-date pretty minimal-ish chroot, etc., the
> usual. :)

Well, I'll put on my upstream hat and apt install iwyu, then... Thanks for
the bug report.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#833304: nageru: FTBFS: quicksync_encoder.cpp:996:15: error: 'close' was not declared in this scope

[Steinar H. Gunderson]

On Tue, Aug 02, 2016 at 07:59:28PM +0200, Chris Lamb wrote:
> nageru fails to build from source in unstable/amd64:

That's odd; I built it in a pbuilder, and several buildds have built it in
the past few days. Is there anything special about your setup?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#824389: grub-efi-arm-bin: the .efi file itself is missing

[Steinar H. Gunderson]

On Sun, May 15, 2016 at 11:39:39AM +0200, Steinar H. Gunderson wrote:
> Debian ships a package “grub-efi-arm-bin” that's supposed to contain an .efi
> image (and “grub-efi-arm” that wraps in some /etc/kernel hooks), and U-Boot
> is set up to search for it, but all it contains are the GRUB modules -- the
> actual .efi file (/efi/boot/bootarm.elf on the bootable partition) is nowhere
> to be seen.

I can confirm that if I build the .efi manually, it does indeed work and
boot a working GRUB (given an appropriate device tree already in /boot/dtbs):
  
  root@soldroid:~/grub2-2.02~beta2# debian/build-efi-images 
obj/grub-efi-arm/grub-mkimage obj/grub-efi-arm/grub-core outdir/ arm-efi arm
  mkfs.fat 4.0 (2016-05-06)
  mkfs.fat 4.0 (2016-05-06)
  root@soldroid:~/grub2-2.02~beta2# ls -l outdir
  total 1817
  -rw-r--r-- 1 root root 632832 May 15 12:41 gcdarm.efi
  -rw-r--r-- 1 root root 589312 May 15 12:41 grubarm.efi
  -rw-r--r-- 1 root root 637440 May 15 12:41 grubnetarm.efi
  root@soldroid:~/grub2-2.02~beta2# mkdir -p /boot/efi/boot/
  root@soldroid:~/grub2-2.02~beta2# cp outdir/grubarm.efi 
/boot/efi/boot/bootarm.elf

Or you can seemingly build it even without the package source available,
by mimicking build-efi-images:

  root@soldroid:~/grub2-2.02~beta2# /usr/bin/grub-mkimage -O arm-efi -o 
/boot/efi/boot/bootarm.elf -d /usr/lib/grub/arm-efi -p /EFI/ubuntu all_video 
boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext 
gfxmenu gfxterm gfxterm_background gzio halt hfsplus iso9660 jpeg keystatus 
loadenv linux lsefi lsefimmap lsefisystab lssal memdisk minicmd normal 
part_apple part_msdos part_gpt password_pbkdf2 png reboot search search_fs_uuid 
search_fs_file search_label sleep test true video zfs zfscrypt zfsinfo lvm 
mdraid09 mdraid1x raid5rec raid6rec

So the software does really handle it, it just needs activation from the
packaging. Or is it flash-kernel that's supposed to link this together
somehow?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#824389: grub-efi-arm-bin: the .efi file itself is missing

[Steinar H. Gunderson]

Package: grub-efi-arm-bin
Version: 2.02~beta2-22
Severity: grave
Justification: breaks entire (binary) package

Hi,

Debian ships a package “grub-efi-arm-bin” that's supposed to contain an .efi
image (and “grub-efi-arm” that wraps in some /etc/kernel hooks), and U-Boot
is set up to search for it, but all it contains are the GRUB modules -- the
actual .efi file (/efi/boot/bootarm.elf on the bootable partition) is nowhere
to be seen.

As far as I can see, there are two reasons for this; one, there's code in
debian/rules that doesn't activate EFI image building (SB_PACKAGE etc.)
unless the build happens on Ubuntu, and two, it seems grub-efi-arm was simply
forgotten in the list, only grub-efi-amd64 and grub-efi-arm64 are remembered.

I tried looking through the changelogs, but I couldn't find any recent
changes here; I'm suspecting that this simply never worked? It's the exact
same thing in jessie, at least, so I'm putting the version number at -22 to
mark that this is not a regression (although I certainly see it on
2.02~beta2-36).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#824153: 08_hlogin_paging.patch breaks all (?) ProCurve logins

[Steinar H. Gunderson]

Package: rancid
Version: 3.4.1-3
Severity: grave

Hi,

Since upgrading to 3.4.x (from an upstream 2.3.9), HP ProCurve logins have been
completely broken for me.

It turns out 08_hlogin_paging.patch breaks this; it makes hlogin send “no 
page\r”
and then wait for first a partial prompt (the switch's name alone) and then
a full prompt (the switch's name followed by [#>]) without sending any commands
in-between. Example session:

  rancid@pannekake:~$ /usr/lib/rancid/bin/hlogin -t 90 -c "show version;show 
flash" james.wlan.samfundet.no < /dev/null
  james.wlan.samfundet.no
  spawn hpuifilter -- ssh -c 3des-cbc -x -l admin james.wlan.samfundet.no
  ad...@james.wlan.samfundet.no's password:
  ProCurve J9087A Switch 2610-24-PWR
  Software revision R.11.112

  Copyright (C) 1991-2015 Hewlett-Packard Co.  All Rights Reserved.

 RESTRICTED RIGHTS LEGEND

   Use, duplication, or disclosure by the Government is subject to restrictions
   as set forth in subdivision (b) (3) (ii) of the Rights in Technical Data and
   Computer Software clause at 52.227-7013.

   HEWLETT-PACKARD COMPANY, 3000 Hanover St., Palo Alto, CA 94303

  Press any key to continuejames#
  james# no page
  james#
  Error: TIMEOUT reached

Looking at the code, I doubt it works in any ProCurve device; I've tested it on
2650, 2824, 2840 and 2610, and it works on neither. (Thus the RC severity;
if it breaks all of HP, it's pretty bad.) My guess is that the patch got borked
in a merge at some point, because the patch in 2.3.8-6 seems good in comparison
(it has a send "terminal length 0\r" that is now lost).

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

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

Versions of packages rancid depends on:
ii  adduser 3.113+nmu3
ii  cvs 2:1.12.13+real-15
ii  debconf [debconf-2.0]   1.5.56
ii  expect  5.45-6
ii  git 1:2.8.0~rc3+next.20160316-1
ii  iputils-ping [ping] 3:20121221-5+b2
ii  libc6   2.19-18+deb8u4
ii  libperl4-corelibs-perl  0.003-1
ii  openssh-client  1:6.7p1-5+deb8u2
ii  passwd  1:4.2-3+deb8u1
ii  perl5.20.2-3+deb8u4
ii  ssh 1:6.7p1-5+deb8u2

rancid recommends no packages.

Versions of packages rancid suggests:
ii  diffstat  1.58-1

-- Configuration Files:
/etc/rancid/rancid.conf changed [not included]

-- debconf information:
* rancid/warning:
* rancid/go_on: true

Bug#819531: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steinar H. Gunderson]

On Wed, Mar 30, 2016 at 01:37:58PM +0200, Steinar H. Gunderson wrote:
> I'll have a look at it tonight and see what I can do. Thanks for alerting me
> of it.

I made a new upload, and tested that it installs (including upgrades from the
version in testing).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#819531: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steinar H. Gunderson]

On Wed, Mar 30, 2016 at 07:48:03PM +0900, Hideki Yamane wrote:
>  Already uploaded :-(

Yes, something went wrong with the delay, like I said. すみません :-/

>  git tree is WIP and has bug I thought, so it's bad for me upload...
>  I don't know why you've uploaded it based on git, it should be minimized
>  for change and now we have Bug#819531 (of course I know it is caused by 
>  my code but it should be tested before upload, though).

I'll have a look at it tonight and see what I can do. Thanks for alerting me
of it.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#818327: missing protoc plugin

[Steinar H. Gunderson]

Package: libgrpc-dev
Version: 0.12.0-1
Severity: grave

Hi,

libgrpc-dev does not include the protoc compiler plugin, and it is not
shipped in any other binary package. This makes it (as far as I can tell)
impossible to actually compile a project in any useful way; even the hello
world projects 
(https://github.com/grpc/grpc/tree/release-0_13/examples/cpp/helloworld)
depend on this, thus the RC severity.

After looking around a bit, it looks like this (and the C++ version of the
shared library) depends on protobuf 3.0.0 (beta) entering Debian, but I cannot
find a bug for that to block this one with.

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

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

Bug#808866: (snappy:15699): Clutter-CRITICAL **: The Clutter backend is not a X11 backend

[Steinar H. Gunderson]

On Wed, Dec 23, 2015 at 11:40:59PM +0100, Julian Andres Klode wrote:
> Package: snappy
> Severity: grave
> 
> Trying to run snappy just fails:
> 
> (snappy:15699): GLib-GObject-CRITICAL **: g_object_set: assertion 
> 'G_IS_OBJECT (object)' failed
> No media set. You can drag and drop a file into snappy to play it.
> Loading ui!

Hm, why did the BTS sent this to me? I do maintain the snappy source package,
but not the snappy _binary_ package (which has snappy-player as its source
package). Somehow BTS appears confused:

  Package: snappy; Maintainer for snappy is Steinar H. Gunderson 
<se...@debian.org>; Source for snappy is src:snappy-player.

BTS owners, do you have anything to add?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#802880: closed by Gianfranco Costamagna <costamagnagianfra...@yahoo.it> (qtcreator: not really a bug)

[Steinar H. Gunderson]

fixed 802280 qtcreator/3.5.0+dfsg-2+b1
thanks

On Sat, Oct 24, 2015 at 02:33:04PM +, Debian Bug Tracking System wrote:
> Hi, this bug is invalid.

Uhm, no?

> During transitions it is normal to have uninstallable packages in sid,
> until they get rebuilt on top of the new library.

It's still a bug.

> qtcreator has been rebuilt around 20 hours ago.
> 
> 3.5.0+dfsg-2+b1
> Rebuild against qtbase-abi-5-5-1.

If so, the binNMU fixes this bug (and should nominally have a Closes: line
with the bug number, except the bug was probably filed after the binNMU was
scheduled). Thank you for taking care of that.

In particular, having a bug in the BTS will enable users to see that the
issue is on its way to being fixed (or not, for some architectures, as you
mention). :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Bug#802880: package is uninstallable due to Qt 5.5 transition

[Steinar H. Gunderson]

Source: qtcreator
Version: 3.5.0+dfsg-2
Severity: serious

Hi,

I can't install qtcreator anymore, since unstable is now on Qt 5.5:

  klump:~> sudo LANG=C apt-get install qtcreator 
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   qtcreator : Depends: qtbase-abi-5-4-2
   Depends: qtdeclarative-abi-5-4-1
   Recommends: qtdeclarative5-dev-tools
   Recommends: qttools5-dev-tools but it is not going to be 
installed
  E: Unable to correct problems, you have held broken packages.

I assume this needs a newer version from upstream.

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

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

Bug#798190: reads nonexistant dir, segfaults Kodi on startup

[Steinar H. Gunderson]

On Mon, Sep 07, 2015 at 12:39:33AM +0200, Bálint Réczey wrote:
> OK, I tried that, too.
> Could you please confirm if the latest upload fixed the bug?
> I would forward the fix to upstream then.

Did you upload it to the archive? I couldn't find it in incoming, nor on my
local mirror.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Bug#798190: reads nonexistant dir, segfaults Kodi on startup

[Steinar H. Gunderson]

Package: libcec3
Version: 3.0.1+dfsg2-4
Severity: grave

Hi,

Recently, Kodi has started segfaulting on startup, pointing to libcec3.
A backtrace reads:

#0  0x7fffecf55789 in __readdir (dirp=dirp@entry=0x0) at 
../sysdeps/posix/readdir.c:44
#1  0x7fffc81d8b74 in PLATFORM::CDRMEdidParser::GetPhysicalAddress 
(this=this@entry=0x7fffc29e8550)
at 
/home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/platform/drm/drm-edid.cpp:54
#2  0x7fffc81e4c0e in CEC::CUSBCECAdapterCommunication::GetPhysicalAddress 
(this=0x7fffb4000f50)
at 
/home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/adapter/Pulse-Eight/USBCECAdapterCommunication.cpp:697
#3  0x7fffc81baaec in CEC::CCECClient::AutodetectPhysicalAddress 
(this=0x1a7cab0)
at /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/CECClient.cpp:1224
#4  0x7fffc81b884c in CEC::CCECClient::SetPhysicalAddress (this=0x1a7cab0, 
configuration=...)
at /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/CECClient.cpp:236
#5  0x7fffc81bcdcb in CEC::CCECClient::OnRegister (this=0x1a7cab0) at 
/home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/CECClient.cpp:138
#6  0x7fffc81cd4d2 in CEC::CCECProcessor::RegisterClient (this=0x1a76840, 
client=std::shared_ptr (count 4, weak 0) 0x1a7cab0)
at /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/CECProcessor.cpp:899
#7  0x7fffc81d3e7a in CEC::CLibCEC::Open (this=0x1a78d10, 
strPort=, iTimeoutMs=)
at /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/LibCEC.cpp:91
#8  0x010cdd39 in PERIPHERALS::CPeripheralCecAdapter::OpenConnection() 
()
#9  0x010d0434 in PERIPHERALS::CPeripheralCecAdapter::Process() ()
#10 0x0113f56f in CThread::Action() ()
#11 0x0113f832 in CThread::staticThread(void*) ()
#12 0x755ad0a4 in start_thread (arg=0x7fffc29e9700) at 
pthread_create.c:309
#13 0x7fffecf8807d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

It would seem libcec3 unconditionally assumes /sys/class/drm exists
(it does not on my system using the proprietary NVIDIA driver, since
that driver doesn't use drm), and then segfaults when it doesn't.

Could you please add a check for the NULL value?

Bug#798190: reads nonexistant dir, segfaults Kodi on startup

[Steinar H. Gunderson]

On Sun, Sep 06, 2015 at 07:48:24PM +0200, Bálint Réczey wrote:
> Thank you for the detailed bug report.
> Could you please test the fix built here?:
> http://debomatic-amd64.debian.net/distribution#unstable/libcec/3.0.1+dfsg2-5

Uhm, I must understand I couldn't figure that UI out at all. Do you have a
patch?

FWIW, I tried just returning immediately if the pointer from opendir is NULL,
and that seems to have worked correctly. If your fix is anything like that,
it should be fine.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Bug#798108: SSL keepalive broken with IE and Safari

[Steinar H. Gunderson]

Package: libapache2-mpm-itk
Version: 2.4.7-02-1.1
Severity: grave

This is a tracking bug for my forthcoming upload (including to stable).

mpm-itk (2.4.x series only, not 2.2.x) has an issue where, after it
does its extra fork, it doesn't call ap_lingering_close() in the child
process. This means prefork ends up doing it, in the parent process.
In particular, this means that when using mod_ssl, the connection is
attempted closed in a process that does not have the right state,
starting a new SSL handshake. This causes unclean shutdown, causing
problems with keepalive when using IE and Safari.

It also means "Connection: close" on SSL connections is not honored,
no matter the browser.

A patch has been developed and is currently in user testing.

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

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

Bug#794993: libsnappy1: library transition may be needed when GCC 5 is the default

[Steinar H. Gunderson]

forcemerge 791289 794993
thanks

On Sun, Aug 09, 2015 at 07:52:37AM +0200, László Böszörményi wrote:
 It seems Matthias missed this C++ library transition.

He did not; see #791289.

I can upload the patch given there now if you want.

 --- debian/libsnappy1.symbols 2015-08-08 23:54:52.415075073 +
 +++ debian/libsnappy1/DEBIAN/symbols  2015-08-08 23:59:25.046660564 +
 @@ -1,5 +1,5 @@
  libsnappy.so.1 libsnappy1 #MINVER#
 - _ZN6snappy10UncompressEPKcmPSs@Base 1.1.3
 + 
 _ZN6snappy10UncompressEPKcmPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
  1.1.3
   _ZN6snappy10UncompressEPNS_6SourceEPNS_4SinkE@Base 1.1.3
   _ZN6snappy11RawCompressEPKcmPcPm@Base 1.1.3
   _ZN6snappy13RawUncompressEPKcmPc@Base 1.1.3

Surely you cannot patch things in DEBIAN/.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789621: Assert error in SES_ScheduleReq()

[Steinar H. Gunderson]

Package: varnish
Version: 4.0.2-1
Severity: grave
Tags: upstream patch

Hi,

My Varnish keeps crashing with messages like this:

Jun 22 19:55:15 pannekake varnishd[20885]: Child (2880) Panic 
message:#012Assert error in SES_ScheduleReq(), cache/cache_session.c line 
229:#012  Condition
((sp)-magic == 0x2c2f9c5a) not true.#012thread = (cache-worker)#012ident = 
Linux,4.0.4,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012  0x4330a
8: /usr/sbin/varnishd() [0x4330a8]#012  0x43baed: 
/usr/sbin/varnishd(SES_ScheduleReq+0x18d) [0x43baed]#012  0x425208: 
/usr/sbin/varnishd() [0x425208]#012  
0x4276d0: /usr/sbin/varnishd(HSH_DerefObjCore+0x1a0) [0x4276d0]#012  0x4279a5: 
/usr/sbin/varnishd(HSH_DerefObj+0x45) [0x4279a5]#012  0x436f47: /usr/sbin/va
rnishd(CNT_Request+0x4a7) [0x436f47]#012  0x42d18b: 
/usr/sbin/varnishd(HTTP1_Session+0x3eb) [0x42d18b]#012  0x43b537: 
/usr/sbin/varnishd() [0x43b537]#012  
0x435cdc: /usr/sbin/varnishd(Pool_Work_Thread+0x39c) [0x435cdc]#012  0x44912c: 
/usr/sbin/varnishd() [0x44912c]#012req = 0x7f8033c3e020 {#012  sp = 0x7f8033
c0e560, vxid = 1074397190,  step = R_STP_DELIVER,#012  req_body = 
R_BODY_NONE,#012  restarts = 0, esi_level = 0#012  sp = 0x7f8033c0e560 {#012
fd = 140,
 vxid = 655365,#012client = 86.60.190.83 63497,#012step = 
S_STP_WORKING,#012  },#012  worker = 0x7f803b0fdc90 {#012ws = 
0x7f803b0fdea8 {#012   
   id = wrk,#012  {s,f,r,e} = 
{0x7f803b0fd490,0x7f803b0fd490,(nil),+2048},#012},#012  VCL::method = 
0x0,#012  VCL::return = deliver,#012  },#012 
 ws = 0x7f8033c3e1b8 {#012id = req,#012{s,f,r,e} = 
{0x7f8033c40010,+704,(nil),+57360},#012  },#012  http[req] = {#012ws = 
0x7f8033c3e1b8[req]
#012  GET,#012  
/analysis.pl?ims=1434995708000unique=0.4145990631941726,#012  
HTTP/1.1,#012  Host: analysis.sesse.net,#012  U
ser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 
Firefox/38.0,#012  Accept: */*,#012  Accept-Language: 
fi-FI,fi;q=0.8,en-
US;q=0.5,en;q=0.3,#012  DNT: 1,#012  X-Requested-With: 
XMLHttpRequest,#012  Referer: http://analysis.sesse.net/,#012  
Connection: k
eep-alive,#012  X-Forwarded-For: 86.60.190.83, 86.60.190.83,#012  
x-analysis-backend: backend1,#012  Accept-Encoding: gzip,#012  },#012 
 http[resp] = {#012ws = 0x7f8033c3e1b8[req]#012  HTTP/1.1,#012  
200,#012  OK,#012  Content-Type: text/json,#012  X-RGLM: 1
434995714000,#012  X-RGNV: 376,#012  Access-Control-Expose-Headers: 
X-RGLM, X-RGNV, X-RGMV,#012  Vary: Accept-Encoding,#012  Conten
t-Encoding: gzip,#012  Date: Mon, 22 Jun 2015 17:55:14 GMT,#012  
Content-Length: 319,#012  Connection: keep-alive,#012  Accept-Rang
es: bytes,#012  },#012  vcl = {#012srcname = {#012  input,#012  
Builtin,#012},#012  },#012},

This is https://www.varnish-cache.org/trac/ticket/1607, and indeed upgrading to 
4.0.3
fixes it. Could we please have a stable upload?

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

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

Versions of packages varnish depends on:
ii  adduser   3.113+nmu3
ii  gcc   4:4.9.2-2
ii  libc6 2.19-18
ii  libc6-dev [libc-dev]  2.19-18
ii  libedit2  3.1-20140620-2
ii  libjemalloc1  3.6.0-3
ii  libncurses5   5.9+20140913-1+b1
ii  libpcre3  2:8.35-3.3
ii  libtinfo5 5.9+20140913-1+b1
ii  libvarnishapi14.0.3-2~wheezy

varnish recommends no packages.

Versions of packages varnish suggests:
pn  varnish-doc  none

-- Configuration Files:
/etc/default/varnish changed [not included]
/etc/default/varnishlog changed [not included]
/etc/default/varnishncsa changed [not included]
/etc/logrotate.d/varnish changed [not included]
/etc/varnish/default.vcl changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783523: FTBFS due to missing build-depends

[Steinar H. Gunderson]

Package: amoeba
Version: 1.1-27
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Filing for my own tracking, and so that whoever porter gets to see it first
doesn't have to.

  In file included from main/linux-config/linux-config.cpp:34:0:
  ./audio/linux_alsa.h:9:28: fatal error: alsa/asoundlib.h: No such file or 
directory
   #include alsa/asoundlib.h

Probably just a missing build-dependency on libasound-dev.

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

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


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781024: quassel: Denial of service (no CVE yet)

[Steinar H. Gunderson]

tags 781024 + patch
thanks

On Tue, Mar 31, 2015 at 10:48:08AM +0200, Thomas Müller wrote:
 NMU upload is more then welcome - I lack the time to take care of this at
 the moment.

I took the patch from upstream and backported it to the version in sid;
this was a fair amount of work as the patch uses C++11 lambdas heavily
(and the version in jessie is compiled in C++03 mode; I thought changing
this would be too intrusive), but not immediately tricky in itself.
There were also some other merge conflicts that I've fixed.

The patch compiles and has had a second pair of eyes for review, but I've
never used Quassel in my life, so I can't say if it works or not. In any case
it ought to help whoever ends up doing the NMU.

/* Steinar */
-- 
Homepage: http://www.sesse.net/
From b5e38970ffd55e2dd9f706ce75af9a8d7730b1b8 Mon Sep 17 00:00:00 2001
From: Michael Marley mich...@michaelmarley.com
Date: Sat, 21 Feb 2015 07:33:57 -0500
Subject: [PATCH] Improve the message-splitting algorithm for PRIVMSG and CTCP

This introduces a new message splitting algorithm based on
QTextBoundaryFinder.  It works by first starting with the entire
message to be sent, encoding it, and checking to see if it is over
the maximum message length.  If it is, it uses QTBF to find the
word boundary most immediately preceding the maximum length.  If no
suitable boundary can be found, it falls back to searching for
grapheme boundaries.  It repeats this process until the entire
message has been sent.

Unlike what it replaces, the new splitting code is not recursive
and cannot cause stack overflows.  Additionally, if it is unable
to split a string, it will give up gracefully and not crash the
core or cause a thread to run away.

This patch fixes two bugs.  The first is garbage characters caused
by accidentally splitting the string in the middle of a multibyte
character.  Since the new code splits at a character level instead
of a byte level, this will no longer be an issue.  The second is
the core crash caused by sending an overlength CTCP query (/me)
containing only multibyte characters.  This bug was caused by the
old CTCP splitter using the byte index from lastParamOverrun() as
a character index for a QString.
---
 src/core/corebasichandler.cpp |  3 ++
 src/core/corebasichandler.h   |  1 +
 src/core/corenetwork.cpp  | 86 +++
 src/core/corenetwork.h|  5 +++
 src/core/coreuserinputhandler.cpp | 72 +++-
 src/core/coreuserinputhandler.h   |  2 +-
 src/core/ctcpparser.cpp   | 26 +++-
 7 files changed, 124 insertions(+), 71 deletions(-)

Index: quassel-0.10.0/src/core/corebasichandler.cpp
===
--- quassel-0.10.0.orig/src/core/corebasichandler.cpp
+++ quassel-0.10.0/src/core/corebasichandler.cpp
@@ -33,6 +33,9 @@ CoreBasicHandler::CoreBasicHandler(CoreN
 connect(this, SIGNAL(putCmd(QString, const QListQByteArray , const QByteArray )),
 network(), SLOT(putCmd(QString, const QListQByteArray , const QByteArray )));
 
+connect(this, SIGNAL(putCmd(QString, const QListQListQByteArray  , const QByteArray )),
+network(), SLOT(putCmd(QString, const QListQListQByteArray  , const QByteArray )));
+
 connect(this, SIGNAL(putRawLine(const QByteArray )),
 network(), SLOT(putRawLine(const QByteArray )));
 }
Index: quassel-0.10.0/src/core/corebasichandler.h
===
--- quassel-0.10.0.orig/src/core/corebasichandler.h
+++ quassel-0.10.0/src/core/corebasichandler.h
@@ -55,6 +55,7 @@ public:
 signals:
 void displayMsg(Message::Type, BufferInfo::Type, const QString target, const QString text, const QString sender = , Message::Flags flags = Message::None);
 void putCmd(const QString cmd, const QListQByteArray params, const QByteArray prefix = QByteArray());
+void putCmd(const QString cmd, const QListQListQByteArray  params, const QByteArray prefix = QByteArray());
 void putRawLine(const QByteArray msg);
 
 protected:
Index: quassel-0.10.0/src/core/corenetwork.cpp
===
--- quassel-0.10.0.orig/src/core/corenetwork.cpp
+++ quassel-0.10.0/src/core/corenetwork.cpp
@@ -283,6 +283,16 @@ void CoreNetwork::putCmd(const QString 
 }
 
 
+void CoreNetwork::putCmd(const QString cmd, const QListQListQByteArray  params, const QByteArray prefix)
+{
+QListIteratorQListQByteArray  i(params);
+while (i.hasNext()) {
+QListQByteArray msg = i.next();
+putCmd(cmd, msg, prefix);
+}
+}
+
+
 void CoreNetwork::setChannelJoined(const QString channel)
 {
 _autoWhoQueue.prepend(channel.toLower()); // prepend so this new chan is the first to be checked
@@ -979,3 +989,82 @@ void CoreNetwork::requestSetNetworkInfo(
 }
 }
 }
+
+
+CoreNetwork::SplitGenerator::~SplitGenerator() {}
+
+
+QListQListQByteArray