Bug#834511: libexplain: FTBFS on hppa - FAILED test of eventfd EINVAL
Source: libexplain Version: 1.4.D001-4 Severity: important Putting my comments on this here so they're not forgotten: > On 15/08/16 17:07, Helge Deller wrote: >> libexplain FTBFS on hppa, because of a testcase which doesn't take care of >> HP PARISC: >> >> PATH=`pwd`/bin:$PATH /bin/sh test/04/t0472a.sh >> 1,2c1,3 >> < eventfd(initval = 0, flags = 0) failed, Invalid argument (EINVAL) because >> < the flags argument was incorrectly specified, it contained undefined bits >> --- >>> eventfd(initval = 0, flags = 0x10005) failed, Invalid argument (EINVAL) >>> because the flags argument was incorrectly specified, it contained >>> undefined bits >> FAILED test of eventfd EINVAL >> Makefile:42022: recipe for target 't0467a' failed >> make[1]: *** [t0467a] Error 1 >> make[1]: *** Waiting for unfinished jobs >> >> The flags = 0x10005 are actually correct on hppa. >> We have in /usr/include/hppa-linux-gnu/bits/eventfd.h: >> #define EFD_CLOEXEC EFD_CLOEXEC >> EFD_NONBLOCK = 0024 /* HPUX has separate NDELAY & NONBLOCK */ >> >> Any idea how we can make the package build successfully on hppa ? > > It looks like the eventfd flags are defined here: > https://sources.debian.net/src/libexplain/1.4.D001-4/libexplain/buffer/eventfd_flags.c/ > > That function then calls explain_parse_bits_print to actually parse the > bits: > http://sources.debian.net/src/libexplain/1.4.D001-4/libexplain/parse_bits/print.c/ > > But explain_parse_bits_print only handles flag tables containing single > bit values. The correct fix would be to teach explain_parse_bits_print > how to handle these tables. I think the best way would be to iterate > over the entire flag table, and calculate (value & flag) == flag. If > that's true, we output the flag name and remove those bits from the > value. James signature.asc Description: OpenPGP digital signature
Bug#834511: libexplain: FTBFS on hppa - FAILED test of eventfd EINVAL
Control: tags -1 patch
This patch should work, but is untested on hppa.
James
Description: Fix FTBFS on hppa - add handling of flags with multiple bits set
On hppa the 'eventfd EINVAL' test was failing because the EFD_NONBLOCK was
being incorrectly parsed. On hppa this flag sets two separate bits but the
explain_parse_bits_print function does not handle this case. Fix by rewriting
the algorithm to work on both cases. The access_modes table needed reordering
to keep the old behavior there (this patch might change the ordering of some
flags).
Author: James Cowgill
Bug-Debian: https://bugs.debian.org/834511
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/libexplain/parse_bits/print.c
+++ b/libexplain/parse_bits/print.c
@@ -26,7 +26,7 @@ explain_parse_bits_print(explain_string_
const explain_parse_bits_table_t *table, int table_size)
{
int first;
-int other;
+int i;
if (value == 0)
{
@@ -34,32 +34,29 @@ explain_parse_bits_print(explain_string_
return;
}
first = 1;
-other = 0;
-for (;;)
-{
-int bit;
-const explain_parse_bits_table_t *tp;
-bit = value & -value;
-value -= bit;
-tp = explain_parse_bits_find_by_value(bit, table, table_size);
-if (tp)
+// Iterate over entire table checking value against each flag
+for (i = 0; i < table_size; i++)
+{
+int flag = table[i].value;
+if (flag != 0 && (flag & value) == flag)
{
+value -= flag;
+
if (!first)
explain_string_buffer_puts(sb, " | ");
-explain_string_buffer_puts(sb, tp->name);
+explain_string_buffer_puts(sb, table[i].name);
first = 0;
+
+if (value == 0)
+break;
}
-else
-other |= bit;
-if (!value)
-break;
}
-if (other)
+if (value != 0)
{
if (!first)
explain_string_buffer_puts(sb, " | ");
-explain_string_buffer_printf(sb, "0x%X", other);
+explain_string_buffer_printf(sb, "0x%X", value);
}
}
--- a/libexplain/buffer/access_mode.c
+++ b/libexplain/buffer/access_mode.c
@@ -27,10 +27,10 @@
static const explain_parse_bits_table_t table[] =
{
-{ "F_OK", F_OK },
-{ "R_OK", R_OK },
-{ "W_OK", W_OK },
{ "X_OK", X_OK },
+{ "W_OK", W_OK },
+{ "R_OK", R_OK },
+{ "F_OK", F_OK },
};
signature.asc
Description: OpenPGP digital signature
Bug#834511: libexplain: FTBFS on hppa - FAILED test of eventfd EINVAL
On Tue, 16 Aug 2016 16:14:04 +0100 James Cowgill wrote:
> Control: tags -1 patch
>
> This patch should work, but is untested on hppa.
Attached is a revised patch which builds on hppa.
James
Description: Fix FTBFS on hppa - add handling of flags with multiple bits set
On hppa the 'eventfd EINVAL' test was failing because the EFD_NONBLOCK was
being incorrectly parsed. On hppa this flag sets two separate bits but the
explain_parse_bits_print function does not handle this case. Fix by rewriting
the algorithm to work on both cases. The access_modes table needed reordering
to keep the old behavior there (this patch might change the ordering of some
flags). Also handle a similar situation in explain_buffer_open_flags.
Author: James Cowgill
Bug-Debian: https://bugs.debian.org/834511
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/libexplain/parse_bits/print.c
+++ b/libexplain/parse_bits/print.c
@@ -26,7 +26,7 @@ explain_parse_bits_print(explain_string_
const explain_parse_bits_table_t *table, int table_size)
{
int first;
-int other;
+int i;
if (value == 0)
{
@@ -34,32 +34,26 @@ explain_parse_bits_print(explain_string_
return;
}
first = 1;
-other = 0;
-for (;;)
-{
-int bit;
-const explain_parse_bits_table_t *tp;
-bit = value & -value;
-value -= bit;
-tp = explain_parse_bits_find_by_value(bit, table, table_size);
-if (tp)
+// Iterate over entire table checking value against each flag
+for (i = 0; i < table_size && value != 0; i++)
+{
+int flag = table[i].value;
+if (flag != 0 && (flag & value) == flag)
{
+value -= flag;
+
if (!first)
explain_string_buffer_puts(sb, " | ");
-explain_string_buffer_puts(sb, tp->name);
+explain_string_buffer_puts(sb, table[i].name);
first = 0;
}
-else
-other |= bit;
-if (!value)
-break;
}
-if (other)
+if (value != 0)
{
if (!first)
explain_string_buffer_puts(sb, " | ");
-explain_string_buffer_printf(sb, "0x%X", other);
+explain_string_buffer_printf(sb, "0x%X", value);
}
}
--- a/libexplain/buffer/access_mode.c
+++ b/libexplain/buffer/access_mode.c
@@ -27,10 +27,10 @@
static const explain_parse_bits_table_t table[] =
{
-{ "F_OK", F_OK },
-{ "R_OK", R_OK },
-{ "W_OK", W_OK },
{ "X_OK", X_OK },
+{ "W_OK", W_OK },
+{ "R_OK", R_OK },
+{ "F_OK", F_OK },
};
--- a/libexplain/buffer/open_flags.c
+++ b/libexplain/buffer/open_flags.c
@@ -158,7 +158,7 @@ void
explain_buffer_open_flags(explain_string_buffer_t *sb, int flags)
{
int low_bits;
-int other;
+int i;
low_bits = flags & O_ACCMODE;
flags &= ~O_ACCMODE;
@@ -194,25 +194,21 @@ explain_buffer_open_flags(explain_string
explain_string_buffer_printf(sb, "%d", low_bits);
break;
}
-other = 0;
-while (flags != 0)
-{
-int bit;
-const explain_parse_bits_table_t *tp;
-bit = (flags & -flags);
-flags &= ~bit;
-tp = explain_parse_bits_find_by_value(bit, table, SIZEOF(table));
-if (tp)
+// Iterate over entire table checking flags against each flag
+for (i = 0; i < SIZEOF(table) && flags != 0; i++)
+{
+int curr_flag = table[i].value;
+if (curr_flag != 0 && (curr_flag & flags) == curr_flag)
{
+flags -= curr_flag;
+
explain_string_buffer_puts(sb, " | ");
-explain_string_buffer_puts(sb, tp->name);
+explain_string_buffer_puts(sb, table[i].name);
}
-else
-other |= bit;
}
-if (other != 0)
-explain_string_buffer_printf(sb, " | %#o", other);
+if (flags != 0)
+explain_string_buffer_printf(sb, " | %#o", flags);
}
signature.asc
Description: OpenPGP digital signature
Bug#838430: volti: traceback on startup
Hi, On 21/09/16 03:50, Toni Mueller wrote: > Package: volti > Version: 0.2.3-7 > Severity: important > > Dear Maintainer, > > I can't use volti because everytime I try to start it, it crashes: > > $ volti > [alsactrl.py:__init__:41] can't open Master control for card HDMI, > trying to select first available mixer channel > > [alsactrl.py:__init__:49] can't open first available control for card > HDMI > error: list index out of range > Traceback (most recent call last): > File "/usr/bin/volti", line 52, in > volti = main.VolumeTray() > File "/usr/lib/volti/volti/main.py", line 124, in __init__ > self.watchid = gobject.io_add_watch(fd, eventmask, self.update) > TypeError: an integer is required > $ > > This happens on a Dell Latitude E7440, which I have installed with > Jessie and then immediately upgraded to Stretch. You could try this: sed -i 's/card_index = 0/card_index = 1/' ~/.config/volti/config ALSA/pulseaudio may have rearranged your cards when you upgraded. However I think volti should at least detect the correct card and not crash, so I'll leave the bug open. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#841192: mozplugger: mplayer2 has gone away
Package: mozplugger Version: 1.14.5-2 Severity: minor Hi, mplayer2 no longer exists in stretch, please can you remove it from the suggested packages. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#844357: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd'
Control: reassign -1 binutils 2.25-5 Control: severity -1 important Control: affects -1 src:fracplanet Control: retitle -1 binutils: mips* mesa libGL.so.1 contains an invalid symbol table Hi, On 14/11/16 19:08, Adrian Bunk wrote: > Package: fracplanet > Version: 0.4.0-5 > Severity: serious > > https://buildd.debian.org/status/package.php?p=fracplanet&suite=sid > > g++ -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong > -Wformat -Werror=format-security -Wl,-z,relro -Wl,-O1 -o fracplanet > obj/common.o obj/control.o obj/control_about.o obj/control_render.o > obj/control_save.o obj/control_terrain.o obj/dialog_documentation.o > obj/fracplanet.o obj/fracplanet_main.o obj/geometry.o obj/image.o > obj/license.o obj/matrix33.o obj/matrix34.o obj/noise.o > obj/parameters_cloud.o obj/parameters_noise.o obj/parameters_object.o > obj/parameters_render.o obj/parameters_save.o obj/parameters_terrain.o > obj/progress.o obj/random.o obj/rgb.o obj/scan.o obj/spinbox.o obj/triangle.o > obj/triangle_edge.o obj/triangle_mesh.o obj/triangle_mesh_cloud.o > obj/triangle_mesh_terrain.o obj/triangle_mesh_viewer.o > obj/triangle_mesh_viewer_display.o obj/vertex.o obj/xyz.o > obj/moc_control_about.o obj/moc_control_render.o obj/moc_control_save.o > obj/moc_control_terrain.o obj/moc_dialog_documentation.o > obj/moc_fracplanet_main.o obj/moc_triangle_mesh_viewer.o obj/moc_triang > le_mesh_viewer_display.o-L/usr/lib/mips-linux-gnu -L/usr/X11R6/lib > -lboost_program_options -lGLU -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread > /usr/lib/mips-linux-gnu/libQtOpenGL.so: undefined reference to `glLoadMatrixd' > > > Michael Biebl mentioned #844227 on IRC, are these bugs coincidence, > or is there something that broke/changed in Mesa on mips* recently? Looking at this a bit closer, it appears to be a longstanding binutils bug which was recently made worse due to a change in counting local symbols. Dumping the dynamic symbol table of libGL.so.1 on mipsel shows the first (long standing) bug: $ readelf --syms libGL.so.1 | head -n15 Symbol table '.dynsym' contains 1559 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 000163c0 0 SECTION LOCAL DEFAULT 10 2: 000902a8 0 SECTION LOCAL DEFAULT 16 3: 0007264052 FUNCGLOBAL DEFAULT 11 glCheckFramebufferStatusE 4: 0006c47052 FUNCGLOBAL DEFAULT 11 glConvolutionFilter1D 5: 0007219828 FUNCGLOBAL DEFAULT 11 glVertexAttrib3fvARB 6: 0006b73052 FUNCGLOBAL DEFAULT 11 glLoadMatrixd 7: 000943d0 0 NOTYPE LOCAL DEFAULT 24 _fbss 8: 0006c6a052 FUNCGLOBAL DEFAULT 11 glGetConvolutionParameter 9: 0006973052 FUNCGLOBAL DEFAULT 11 glVertex4i 10: 0006ebe052 FUNCGLOBAL DEFAULT 11 glGetBufferPointervARB 11: 0006e3d828 FUNCGLOBAL DEFAULT 11 glWindowPos2f Here the _fbss symbol is LOCAL which is prohibited by the ELF standard which requires all LOCAL symbols to precede GLOBAL symbols. This bug is definitely present in jessie's binutils, because jessie's libGL also has a symbol table similar to this. Wheezy's mesa doesn't have this bug but I don't know if binutils definitely doesn't have it in wheezy. Ordinarily this wasn't much of an issue since glibc and ld would just skip LOCAL symbols when processing the symbol tables. However somewhere between binutils 2.27-9 and 2.27.51.20161108-1 the behavior for calculating the 'st_info' field for the .dynsym section header changed. Recompiling mesa with both versions of binutils gives identical libGL binaries except for this difference in the section header: diffoscope output (- 2.27-9, + 2.27.51.20161108-1): │ - [ 5] .dynsym DYNSYM 2e40 002e40 009228 18 A 6 3 8 │ + [ 5] .dynsym DYNSYM 2e40 002e40 009228 18 A 6 9 8 Here 3 = the index of the first non-global symbol, and 9 = the total number of local symbols. These values should of course be equal if the rules about symbol ordering were followed. ld uses the value of the 'st_info' field to skip LOCAL symbols when linking, which explains why only the 5 symbols from 3-8 in the above symbol table cause link errors. I'm still investigating, but getting a reduced testcase is quite tricky and recompiling mesa on mips takes about an hour. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#858405: xmlto: intermittent Segmentation fault when building manpages for libreswan on mips64el
Hi, On 22/03/17 01:29, Daniel Kahn Gillmor wrote: > Package: xmlto > Version: 0.0.28-1 > Severity: normal > > https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=mips64el&ver=3.20-6&stamp=1490132010&raw=0 > > shows xmlto having a segfault during the build of libreswan's manpages. > > make[5]: Leaving directory '/«PKGBUILDDIR»/OBJ.linux.mips64/programs/proc' > sed -e "s:@IPSECVERSION@:3.20:g" -e "/@linux_START@/,/@linux_END@/d" -e > "s:@EXAMPLECONFDIR@:/usr/share/doc/libreswan:g" -e > "s:@FINALBINDIR@:/usr/lib/ipsec:g" -e "s:@FINALCONFDDIR@:/etc/ipsec.d:g" -e > "s:@FINALCONFDIR@:/etc:g" -e "s:@FINALCONFFILE@:/etc/ipsec.conf:g" -e > "s:@FINALDOCDIR@:/usr/share/doc/libreswan:g" -e > "s:@FINALEXAMPLECONFDIR@:/usr/share/doc/libreswan:g" -e > "s:@FINALLIBEXECDIR@:/usr/lib/ipsec:g" -e "s:@FINALRCDIR@:/etc/init.d:g" -e > "s:@FINALSBINDIR@:/usr/sbin:g" -e "s:@FINALSYSCONFDIR@:/etc:g" -e > "s:@FINALVARDIR@:/var:g" -e "s:@IPSEC_CONF@:/etc/ipsec.conf:g" -e > "s:@IPSEC_CONFDDIR@:/etc/ipsec.d:g" -e > "s:@IPSEC_NSSDIR@:/var/lib/ipsec/nss:g" -e "s:@IPSEC_DIR@:/usr/lib/ipsec:g" > -e "s:@IPSEC_EXECDIR@:/usr/lib/ipsec:g" -e "s:@IPSEC_VARDIR@:/var:g" -e > "s:@IPSEC_SBINDIR@:/usr/sbin:g" -e > "s:@IPSEC_SECRETS_FILE@:/etc/ipsec.secrets:g" -e "s:@MODPROBEBIN@:modprobe:g" > -e "s:@MODPROBEARGS@:--quiet --use-blacklist:g" -e "s:@USE_DEFAULT_CONNS@::g" > -e "s:@SD_TYPE@:notify:g" -e "s:@SD_RESTART_TYPE@:"always":g" -e > "s:@SD_PLUTO_OPTIONS@:"--leak-detective":g" -e "s:@SD_WATCHDOGSEC@:200:g" < > ipsec_version.5.xml > > ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp.tmp > mv ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp.tmp > ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp > : ignoring seemingly bogus xmlto exit status > xmlto man ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp -o > ../../OBJ.linux.mips64/programs/proc || true > /usr/bin/xmlto: line 613: 5007 Segmentation fault "/usr/bin/xsltproc" > --nonet --xinclude --param passivetex.extensions '1' -o > "/tmp/xmlto.vUw7Aq/ipsec_version.5.proc" "/tmp/xmlto-xsl.XOSOth" > "/«PKGBUILDDIR»/programs/proc/../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp" > test -z "" -a -r ../../OBJ.linux.mips64/programs/proc/ipsec_version.5 > ../../mk/manpages.mk:79: recipe for target > '../../OBJ.linux.mips64/programs/proc/ipsec_version.5.man' failed > make[4]: *** [../../OBJ.linux.mips64/programs/proc/ipsec_version.5.man] Error > 1 > make[4]: Leaving directory '/«PKGBUILDDIR»/programs/proc' > > The build of the previous version, 3.20-5, which is very similar code, did > not have the segfault: > > https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=mips64el&ver=3.20-5&stamp=1490115466&raw=0 > > make[5]: Leaving directory '/«PKGBUILDDIR»/OBJ.linux.mips64/programs/proc' > sed -e "s:@IPSECVERSION@:3.20:g" -e "/@linux_START@/,/@linux_END@/d" -e > "s:@EXAMPLECONFDIR@:/usr/share/doc/libreswan:g" -e > "s:@FINALBINDIR@:/usr/lib/ipsec:g" -e "s:@FINALCONFDDIR@:/etc/ipsec.d:g" -e > "s:@FINALCONFDIR@:/etc:g" -e "s:@FINALCONFFILE@:/etc/ipsec.conf:g" -e > "s:@FINALDOCDIR@:/usr/share/doc/libreswan:g" -e > "s:@FINALEXAMPLECONFDIR@:/usr/share/doc/libreswan:g" -e > "s:@FINALLIBEXECDIR@:/usr/lib/ipsec:g" -e "s:@FINALRCDIR@:/etc/init.d:g" -e > "s:@FINALSBINDIR@:/usr/sbin:g" -e "s:@FINALSYSCONFDIR@:/etc:g" -e > "s:@FINALVARDIR@:/var:g" -e "s:@IPSEC_CONF@:/etc/ipsec.conf:g" -e > "s:@IPSEC_CONFDDIR@:/etc/ipsec.d:g" -e > "s:@IPSEC_NSSDIR@:/var/lib/ipsec/nss:g" -e "s:@IPSEC_DIR@:/usr/lib/ipsec:g" > -e "s:@IPSEC_EXECDIR@:/usr/lib/ipsec:g" -e "s:@IPSEC_VARDIR@:/var:g" -e > "s:@IPSEC_SBINDIR@:/usr/sbin:g" -e > "s:@IPSEC_SECRETS_FILE@:/etc/ipsec.secrets:g" -e "s:@MODPROBEBIN@:modprobe:g" > -e "s:@MODPROBEARGS@:--quiet --use-blacklist:g" -e "s:@USE_DEFAULT_CONNS@::g" > -e "s:@SD_TYPE@:notify:g" -e "s:@SD_RESTART_TYPE@:"always":g" -e > "s:@SD_PLUTO_OPTIONS@:"--leak-detective":g" -e "s:@SD_WATCHDOGSEC@:200:g" < > ipsec_version.5.xml > > ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp.tmp > mv ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp.tmp > ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp > : ignoring seemingly bogus xmlto exit status > xmlto man ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp -o > ../../OBJ.linux.mips64/programs/proc || true > Note: Writing ipsec_version.5 > test -z "" -a -r ../../OBJ.linux.mips64/programs/proc/ipsec_version.5 > touch ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.man > > So xmlto seems to fail intermittently on mips64el, even though it > behaves reliably on all the other debian architectures. > > Sorry that i haven't been able to debug it further. > > Perhaps someone who knows mips64el can debug it better than i can. > > For debian revisions of 3.20, failures happened on: > > mipsel-manda-02 > eberlin > > Also for revisions of 3.20, successes happened on: > > mipsel-sil-01 > mipsel-manda-03 > mipsel
Bug#858405: xmlto: intermittent Segmentation fault when building manpages for libreswan on mips64el
reassign 858405 xsltproc
forcemerge 750593 858405
retitle 750593 xsltproc: bus error on some arches with linux < 4.1
thanks
Hi,
On 22/03/17 21:01, Daniel Kahn Gillmor wrote:
> On Wed 2017-03-22 06:22:41 -0400, James Cowgill wrote:
>> On 22/03/17 01:29, Daniel Kahn Gillmor wrote:
>>> For debian revisions of 3.20, failures happened on:
>>>
>>> mipsel-manda-02
>>> eberlin
>>>
>>> Also for revisions of 3.20, successes happened on:
>>>
>>> mipsel-sil-01
>>> mipsel-manda-03
>>> mipsel-manda-01
>>
>> This is a known issue and it only affects Loongson buildds.
>> Interestingly mipsel-manda-01 is Loongson and didn't fail there so there
>> may be a random element involved here. I don't think anyone's tracked
>> down the underlying issue though.
>
> thanks, is there a public reference for the known issue that we can
> point to?
I think #750593 looks a lot like the bug here.
After some investigation, it seems I was being a bit unfair to Loongson.
This is arguably a non mips specific bug in Linux < 4.1. It just so
happens that all the Loongson buildds run jessie's 3.16 kernel and all
the other buildds run >= 4.7 from backports.
In #750593 there was lots of talk about stack overflows causing this but
there is actually another element to this. Indeed if I reduced the stack
size down with ulimit, the segfaults become more frequent, but
increasing the stack size didn't help at all. After looking at the
mappings for a failing process, I saw this (taken just after starting
xsltproc):
[...]
> fff7f5-fff7f5c000 ---p 4000 fd:00 1060250
> /usr/lib/mips64el-linux-gnuabi64/libeatmydata.so.1.1.2
> fff7f5c000-fff7f6 rw-p fd:00 1060250
> /usr/lib/mips64el-linux-gnuabi64/libeatmydata.so.1.1.2
> fff7f6-fff7f88000 r-xp fd:00 1060375
> /lib/mips64el-linux-gnuabi64/ld-2.24.so
> fff7f94000-fff7f98000 rw-p 00024000 fd:00 1060375
> /lib/mips64el-linux-gnuabi64/ld-2.24.so
> fff7f98000-fff7fa r-xp fd:00 947544
> /usr/bin/xsltproc
> fff7fa4000-fff7fac000 rw-p 00:00 0
> fff7fac000-fff7fb rw-p 4000 fd:00 947544
> /usr/bin/xsltproc
> 1d4000-384000 rwxp 00:00 0
> [heap]
> 9e-a04000 rwxp 00:00 0
> [stack]
> ffc000-100 r-xp 00:00 0
> [vdso]
Notice that there is a very small gap between the heap and the stack
here (at least compared to working xsltproc runs). I think that the heap
is growing to a point where it limits the maximum size of the stack and
so increasing the stack size with ulimit doesn't help.
The reason the program and the heap are at these very high addresses is
that xsltproc is built with PIE and the kernel is treating the
executable like a mmap and grouping it with all the other libraries. In
d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR") the behavior
changed and now the program and it's heap will be mapped at a lower
address so the bug does not affect newer kernels. Using "setarch -L" or
"setarch -R" is another workaround for this bug because that moves the
program so that there is a much larger gap between the heap and the stack.
This might affect other applications as well. Effectively it means that
PIE executables which use lots of stack space might not work properly
with jessie's kernel. The chances the bug will be hit seems to vary
between arches however (depending on what each arch does in
arch_pick_mmap_layout and arch_randomize_brk) - mips64el seems to be hit
pretty frequently. In xsltproc's case, PIE was enabled some time ago
which is why this bug is quite old.
I believe any of the following will fix this (but have not all been tested):
- Reduce the stack usage in xsltproc (the upstream bug)
- Upgrade the relevant buildds to Linux >= 4.1
- Apply d1fd836dcf00 to jessie's kernel
- Disable PIE in xsltproc.
- Run xsltproc inside setarch -L / setarch -R
>> For the moment, I'll rebuild libreswan again and hope a good buildd is
>> picked.
>
> i see 5 mips64el rebuilds now at
> https://buildd.debian.org/status/logs.php?pkg=libreswan&ver=3.20-6&suite=sid,
> but none of them have succeded yet :/
>
> 3 of the builds are from mipsel-manda-02, 1 is from eberlin, and one
> additional new "bad" builder is:
>
> mipsel-aql-01
There are 3 non-Loongson buildds: mipsel-aql-03, mipsel-manda-03 and
mipsel-sil-01. I expect libreswan will only build on one of those
buildds at the moment.
Thanks,
James
signature.asc
Description: OpenPGP digital signature
Bug#873589: clearsilver: FTBFS on arm64, mips*, ppc64el during clean - unable to guess system type
Source: clearsilver Version: 0.10.5-2 Severity: serious Tags: sid buster Hi, clearsilver FTBFS on arm64, mips* and ppc64el with this error: > checking build system type... ./config.guess: unable to guess system type > > This script, last modified 2001-09-04, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > ftp://ftp.gnu.org/pub/gnu/config/ > > If the version you run (./config.guess) is already up to date, please > send the following data and any information you think might be > pertinent to in order to provide the needed > information to handle your system. > > config.guess timestamp = 2001-09-04 This happens during the "clean" phase of the build: > fakeroot debian/rules clean > dh clean --with python2 >dh_auto_clean > make -j6 distclean > make[1]: Entering directory '/<>' > Makefile:10: rules.mk: No such file or directory > ./configure > checking for gcc... gcc Calling "make distclean" should probably be skipped if rules.mk does not exist so that the configure script isn't run. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#879460: libavg: FTBFS with ffmpeg 3.4
Source: libavg Version: 1.8.1-5 Severity: important Tags: sid buster Hi, libavg FTBFS with ffmpeg 3.4 (currently in experimental): > In file included from AsyncVideoDecoder.cpp:26:0: > VDPAUHelper.h:59:8: error: 'VdpPresentationQueueTargetCreateX11' does not > name a type; did you mean 'VdpPresentationQueueTargetDestroy'? > extern VdpPresentationQueueTargetCreateX11* > vdp_presentation_queue_target_create_x11; > ^~~ > VdpPresentationQueueTargetDestroy > Makefile:748: recipe for target 'AsyncVideoDecoder.lo' failed > make[4]: *** [AsyncVideoDecoder.lo] Error 1 > make[4]: *** Waiting for unfinished jobs I think this is due to this FFmpeg commit which removes an include to vdpau_x11.h which is needed by libavg: https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/932cc6496ef6ab0e589ea51d3adefe5b7d7f1e2a Thanks, James signature.asc Description: OpenPGP digital signature
Bug#881746: enscribe: build dependency libgd2-xpm-dev does not exist
Source: enscribe Version: 0.1.0-2 Severity: serious Tags: sid buster Hi, enscribe build depends on: libgd2-xpm-dev | libgd-dev The libgd2-xpm-dev no longer exists. Although libgd-dev does exist, it is ignored by the buildds which only use the first build-dependency. Please remove libgd2-xpm-dev and only build-depend on libgd-dev. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#888327: xine-lib-1.2: FTBFS with FFmpeg 3.5
Control: tags -1 fixed-upstream patch
On Wed, 24 Jan 2018 22:26:51 + jcowg...@debian.org wrote:
> Source: xine-lib-1.2
> Version: 1.2.8-2
> Severity: important
> User: debian-multime...@lists.debian.org
> Usertags: ffmpeg-3.5-transition
>
> Hi,
>
> Your package FTBFS with the upcoming version 3.5 of FFmpeg.
Fixed upstream by this commit:
https://sourceforge.net/p/xine/xine-lib-1.2/ci/abd6e04c7a53f10d1a2975159f65ba7e33bee61c/
Patch attached.
James
Description: Fix FTBFS with FFmpeg 4.0
Origin: upstream, https://sourceforge.net/p/xine/xine-lib-1.2/ci/abd6e04c7a53f10d1a2975159f65ba7e33bee61c/
Bug-Debian: https://bugs.debian.org/888327
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/combined/ffmpeg/ff_audio_decoder.c
+++ b/src/combined/ffmpeg/ff_audio_decoder.c
@@ -221,7 +221,7 @@ static void ff_audio_ensure_buffer_size(
xprintf(this->stream->xine, XINE_VERBOSITY_LOG,
_("ffmpeg_audio_dec: increasing buffer to %d to avoid overflow.\n"),
this->bufsize);
-this->buf = xine_realloc_aligned (this->buf, this->bufsize + FF_INPUT_BUFFER_PADDING_SIZE);
+this->buf = xine_realloc_aligned (this->buf, this->bufsize + AV_INPUT_BUFFER_PADDING_SIZE);
}
}
@@ -232,9 +232,9 @@ static void ff_audio_handle_special_buff
free (this->context->extradata);
this->context->extradata_size = buf->decoder_info[2];
-this->context->extradata = malloc (buf->decoder_info[2] + FF_INPUT_BUFFER_PADDING_SIZE);
+this->context->extradata = malloc (buf->decoder_info[2] + AV_INPUT_BUFFER_PADDING_SIZE);
memcpy (this->context->extradata, buf->decoder_info_ptr[2], buf->decoder_info[2]);
-memset (this->context->extradata + buf->decoder_info[2], 0, FF_INPUT_BUFFER_PADDING_SIZE);
+memset (this->context->extradata + buf->decoder_info[2], 0, AV_INPUT_BUFFER_PADDING_SIZE);
ff_aac_mode_set (this, 0);
}
@@ -451,10 +451,10 @@ static void ff_handle_header_buffer(ff_a
this->ff_channels, this->ff_bits, this->ff_sample_rate,
this->context->block_align);
if (!data_len) break;
- e = malloc (data_len + FF_INPUT_BUFFER_PADDING_SIZE);
+ e = malloc (data_len + AV_INPUT_BUFFER_PADDING_SIZE);
if (!e) break;
xine_fast_memcpy (e, p, data_len);
- memset (e + data_len, 0, FF_INPUT_BUFFER_PADDING_SIZE);
+ memset (e + data_len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
this->context->extradata = e;
this->context->extradata_size = data_len;
break;
@@ -1008,7 +1008,7 @@ static void ff_audio_decode_data (audio_
offset = 0;
/* pad input data */
- memset(&this->buf[this->size], 0, FF_INPUT_BUFFER_PADDING_SIZE);
+ memset(&this->buf[this->size], 0, AV_INPUT_BUFFER_PADDING_SIZE);
while (this->size>=0) {
--- a/src/combined/ffmpeg/ff_mpeg_parser.c
+++ b/src/combined/ffmpeg/ff_mpeg_parser.c
@@ -26,6 +26,7 @@
#define LOG
*/
#include "ff_mpeg_parser.h"
+#include "ffmpeg_compat.h"
/* mpeg frame rate table from lavc */
static const int frame_rate_tab[][2] = {
@@ -50,7 +51,7 @@ static const int frame_rate_tab[][2] = {
void mpeg_parser_init (mpeg_parser_t *parser)
{
- parser->chunk_buffer = malloc(BUFFER_SIZE + FF_INPUT_BUFFER_PADDING_SIZE);
+ parser->chunk_buffer = malloc(BUFFER_SIZE + AV_INPUT_BUFFER_PADDING_SIZE);
mpeg_parser_reset(parser);
}
--- a/src/combined/ffmpeg/ff_video_decoder.c
+++ b/src/combined/ffmpeg/ff_video_decoder.c
@@ -869,16 +869,18 @@ static void init_video_codec (ff_video_d
this->stream->video_out->open (this->stream->video_out, this->stream);
this->edge = 0;
- if(this->codec->capabilities & CODEC_CAP_DR1 && this->class->enable_dri) {
+ if(this->codec->capabilities & AV_CODEC_CAP_DR1 && this->class->enable_dri) {
if (this->stream->video_out->get_capabilities (this->stream->video_out) & VO_CAP_CROP) {
/* We can crop. Fine. Lets allow decoders to paint over the frame edges.
This will be slightly faster. And it is also a workaround for buggy
v54 who likes to ignore EMU_EDGE for wmv2 and xvid. */
this->edge = XFF_EDGE_WIDTH ();
+#ifdef CODEC_FLAG_EMU_EDGE
} else {
/* Some codecs (eg rv10) copy flags in init so it's necessary to set
* this flag here in case we are going to use direct rendering */
this->context->flags |= CODEC_FLAG_EMU_EDGE;
+#endif
}
}
@@ -887,7 +889,7 @@ static void init_video_codec (ff_video_d
this->context->codec_type = this->codec->type;
if (this->class->choose_speed_over_accuracy)
-this->context->flags2 |= CODEC_FLAG2_FAST;
+this->context->flags2 |= AV_CODEC_FLAG2_FAST;
this->context->skip_loop_filter = skip_loop_filter_enum_values[this->class->skip_loop_filter_enum];
@@ -912,7 +914,7 @@ static void init_video_codec (ff_video_d
/* enable direct rendering by default */
this->output_format = XINE_IMGFMT_YV12;
#ifdef ENABLE_DIRECT_RENDERING
- if( th
Bug#891556: faketime: FTBFS with GCC 8 - error: 'strncpy' specified bound 128 equals destination size
Source: ifhp Version: 3.5.20-15 Severity: important User: debian-...@lists.debian.org Usertag: ftbfs-gcc-8 Hi, I recently performed an (unofficial) archive rebuild with GCC 8 on mips64el. The main purpose of the rebuild was to discover mips toolchain regressions, however I noticed this error in the logs which might be interesting to you: > ifhp.c: In function 'Find_sub_value': > ifhp.c:2803:3: error: 'strncpy' specified bound 128 equals destination size > [-Werror=stringop-truncation] >strncpy(copy,id+1,sizeof(copy)); >^~~ > cc1: all warnings being treated as errors > : recipe for target 'ifhp.o' failed > make[2]: *** [ifhp.o] Error 1 > make[2]: Leaving directory '/<>/src' > Makefile:51: recipe for target 'src' failed > make[1]: *** [src] Error 2 > make[1]: Leaving directory '/<>' > debian/rules:32: recipe for target 'build-stamp' failed > make: *** [build-stamp] Error 2 > dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit > status 2 As you probably know, you need to be careful using strncpy. Instead of: char out[SIZE]; strncpy(out, in, SIZE); You need to do: char out[SIZE] strncpy(out, in, SIZE - 1); out[SIZE - 1] = '\0'; See strcpy(3) James signature.asc Description: OpenPGP digital signature
Accepted xine-lib-1.2 1.2.9-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 27 Mar 2018 00:48:56 +0100
Source: xine-lib-1.2
Binary: libxine2-doc libxine2 libxine2-bin libxine2-dev libxine2-ffmpeg
libxine2-gnome libxine2-console libxine2-vdr libxine2-x libxine2-misc-plugins
libxine2-plugins libxine2-all-plugins
Architecture: source
Version: 1.2.9-1
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group
Changed-By: James Cowgill
Description:
libxine2 - xine media player library – metapackage
libxine2-all-plugins - xine video/media player library ‒ metapackage for all
plugins
libxine2-bin - xine video/media player library – binary files
libxine2-console - libaa/libcaca/framebuffer/directfb related plugins for
libxine2
libxine2-dev - xine video player library – development packages
libxine2-doc - xine video player library – documentation files
libxine2-ffmpeg - MPEG-related plugins for libxine2
libxine2-gnome - GNOME-related plugins for libxine2
libxine2-misc-plugins - Input, audio output and post plugins for libxine2
libxine2-plugins - xine video/media player library ‒ metapackage for
commonly-used p
libxine2-vdr - VDR-related plugins for libxine2
libxine2-x - X desktop video output plugins for libxine2
Closes: 883298 888327
Changes:
xine-lib-1.2 (1.2.9-1) unstable; urgency=medium
.
* QA upload.
* New upstream version.
- Fixes FTBFS with FFmpeg 4.0. (Closes: #888327)
- Fixes FTBFS on x32. (Closes: #883298)
.
* debian/copyright:
- Update for 1.2.9.
* debian/control:
- Migrate Vcs to salsa.debian.org.
- Remove unused shlibs:{Recommends,Suggests} from libxine2-bin.
- Add missing perl:Depends to libxine2-dev.
- Bump standards version to 4.1.3.
* debian/libxine2-bin.symbols:
- Add new symbols for 1.2.9.
* debian/libxine2-misc-plugins.install:
- Merge network plugins into a single file.
* debian/not-installed:
- Update path to mime.types.
Checksums-Sha1:
759c16cf7429851a5a6e8f038d1b846da35fbc5c 3417 xine-lib-1.2_1.2.9-1.dsc
ad6e72b7d8ff6172a8a170ab1bc38577ae321371 5180452 xine-lib-1.2_1.2.9.orig.tar.xz
fd2fe1a55ba30133b95f318e9eff84bb69ec2698 35196
xine-lib-1.2_1.2.9-1.debian.tar.xz
7cf4ba5e14973d24513a5eabdcf284b0a728d3df 19948
xine-lib-1.2_1.2.9-1_source.buildinfo
Checksums-Sha256:
76cf2c2f1af5b6639e22cd981947f9cd81824ff3596f53d18f9324c66d8c925b 3417
xine-lib-1.2_1.2.9-1.dsc
32b34e8049feb762d75a551d5d2cdb56c396fdd83e35b9b7de5fd08e498e948d 5180452
xine-lib-1.2_1.2.9.orig.tar.xz
3a45936a35cbed697d6ef0f3f9cb1b6c738a5f3f7303382a731545807b44f5d4 35196
xine-lib-1.2_1.2.9-1.debian.tar.xz
b9e0e6b886526abb94499c33c59dde36676f5c1c99789f49f6ccf22b25ea6abb 19948
xine-lib-1.2_1.2.9-1_source.buildinfo
Files:
453aa4009b4b3855a7be979ed530fbb1 3417 libs optional xine-lib-1.2_1.2.9-1.dsc
cd42d2ba92f943d17736d9bca712b3d1 5180452 libs optional
xine-lib-1.2_1.2.9.orig.tar.xz
d86f5943ddee4a5659663a3a3feac5c6 35196 libs optional
xine-lib-1.2_1.2.9-1.debian.tar.xz
2aeff803a79e6a620c269564805332a6 19948 libs optional
xine-lib-1.2_1.2.9-1_source.buildinfo
-BEGIN PGP SIGNATURE-
iQJIBAEBCgAyFiEE+Ixt5DaZ6POztUwQx/FnbeotAe8FAlq6cdsUHGpjb3dnaWxs
QGRlYmlhbi5vcmcACgkQx/FnbeotAe/e1g/+Ibq0sorL43ybPvfqEELyIm+HP2/7
D7nWFUfAN+hFUr0pMyOAcQkTxRLyipLkRgyI5HmSw3PDzznaW+Rf6JGkmpOatCv/
apRDy8d9gl1voXABiV1Jou/zkf2RHbi2A29278PR9mOXWVrz3TGWKJ17OTuMbHDj
pSUoV5WqzknxkzQClCRHYbcvHYF/bsrhixGUCUaRB2Dwk3hImaWpBmpNVWlFkVhB
wHQ7g22QgdPpZ5ID9VJXX0JT6r4GDxWYzk/jt4SWYto+VELpTyaYZiGhLKhGcLT1
+TE8ac5fbCMc/XU2FK77Iv1tbpSyNEGqciQVLCyojw3/FihHrAkVy/Jgovf9yiKr
wAYHOqwYrMXvkYnGqwOWirkcZLxI4gLuDWzQtrSRjEeQhGVXY3cPElnNuB3nwOcA
je/pDQfBGAlh3BPeae3uqvJ5g0x9j17/FMV+pKA9znl/yExNAsauyjU0mPukX8M0
4kE9ZRZcnyAg1M5EfAHSgryW7jbCjEuP6srXWqCXaBOulHD82M9DMOtGiWHFFDtf
upI7b3SXjYlGTgT5IJqGeosEy38/6NaXKxfcnC3na9kYlmw8VmFR+VUiqPXFfDWE
SwHTZrnbzgH/o178E9sdvEQqsW/5BDWrHwW6VpvmE1XlKyIro4WE1zU8/RbQp0RM
IEDDE6iscNFi2u4=
=P0J7
-END PGP SIGNATURE-
Bug#912066: linux-igd: FTBFS with upnp 1.8.4
Source: linux-igd Version: 1.0+cvs20070630-6 Severity: important Tags: sid buster User: jcowg...@debian.org Usertags: upnp-1.8-transition Control: block 884635 by -1 Hi, linux-idg FTBFS with upnp 1.8.4 (in experimental) with this error: > gatedevice.c:10:10: fatal error: TimerThread.h: No such file or directory > #include > ^~~ > compilation terminated. The threadutil library is no longer shipped with upnp 1.8 since it's an implementation detail which has nothing to do with upnp itself. Unfortunately it looks like a lot of code needs rewriting to use pthreads directly or another threading library (which can cope with some of the extra features of threadutil like thread pooling). James signature.asc Description: OpenPGP digital signature
Bug#775357: libexplain: FTBFS on mips64el
Source: libexplain Version: 1.4.D001-2 Severity: important Hi, libexplain FTBFS on mips64el with the following testsuite error: PATH=`pwd`/bin:$PATH /bin/sh test/00/t0056a.sh 3c3 < which is unsuitable for writing (O_RDONLY | O_LARGEFILE) --- > which is unsuitable for writing (O_RDONLY | 02) FAILED test of write vs EINVAL make[1]: *** [t0056a] Error 1 The full log is available here: http://mipsdebian.imgtec.com/debian/logs/libe/libexplain/libexplain_1.4.D001-2_mips64el-20150114-0214.build.gz Thanks, James -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1421253962.25328.41.ca...@cowgill.org.uk
Bug#788555: blackbox: FTBFS on mips64el
Source: blackbox Version: 0.70.1-28 Severity: important Hi, blackbox FTBFS on mips64el with various symbol errors. See this build log: http://mipsdebian.imgtec.com/debian/logs/b/blackbox/blackbox_0.70.1-28_mips64el-20150609-1412.gz I'm working on a fix for this which is generic so this package doesn't require an update everytime a new architecture is added. Thanks, James signature.asc Description: This is a digitally signed message part
Re: Bug#789256: cmus: Pulls in unwanted and potentially dangerous DECnet packages through libroar2
(sorry I got the pts email addresses wrong before) On Fri, 2015-06-19 at 13:06 +0200, John Paul Adrian Glaubitz wrote: > On 06/19/2015 01:02 PM, James Cowgill wrote: > > Using apt-get with --install-suggests isn't that common so I don't > > think this warrants an RC severity (it doesn't break the package > > for everyone). > > It was RC severity before, see [1]. Furthermore, ROAR audio currently > breaks cmus because of DECnet and the ROAR developers refuse to > remove support for it. From the bug: > RC severity mostly so this shows up on the radars of all the right > people crossing off the details we need to finalise for the release. That doesn't apply here. Hmm I personally can't get cmus to break this way but it could be RC if it breaks in default installations. > > If you look at the status of DECnet: > > > > No kernel maintainer (except general net/ maintenance): > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/M > AINTAINERS?id=v4.1-rc8#n3060 > > > > dnprogs upstream appears to be dead: > > http://sourceforge.net/projects/linux-decnet/ > > > > dnprogs is orphaned: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750670 > > Which is my whole point. Then this is a bug in roaraudio / dnprogs, not cmus. > > IMHO dnprogs should be removed and roaraudio should drop support > > for DECnet - unless someone who actually uses DECnet is willing to > > maintain this stuff. > > The ROAR developers and maintainers refuse to do that which is why > we should drop it from cmus. They, for some reason, think it's important > to support a pre-historic networking protocol. I found this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675014 This is the newer one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755934 But I couldn't find any evidence the _current_ maintainer of roaraudio has refused to remove DECnet support. The current bug about it has no replies. James signature.asc Description: This is a digitally signed message part
Bug#1098206: libid3-3.8.3-dev: Including id3.h fails in C23 mode due to bool typedef
Package: libid3-3.8.3-dev Version: 3.8.3-18 Severity: important Tags: upstream Forwarded: https://sourceforge.net/p/id3lib/bugs/215/ Hi, It is not possible to include with a C23 compiler (which is going to be the default mode for GCC 15) because the header tries to typedef bool which is now a keyword. > $ gcc -std=c23 -c -x c -include /usr/include/id3.h - -o /dev/null < /dev/null > In file included from /usr/include/id3.h:32, > from : > /usr/include/id3/globals.h:87:13: error: two or more data types in > declaration specifiers >87 | typedef int bool; > | ^~~~ > /usr/include/id3/globals.h:87:1: warning: useless type name in empty > declaration >87 | typedef int bool; > | ^~~ This old Ubuntu bug contains a patch to include when compiling with C99 or greater which seems like the best solution to me. https://bugs.launchpad.net/ubuntu/+source/id3lib3.8.3/+bug/912945 James
Bug#1098206: libid3-3.8.3-dev: Including id3.h fails in C23 mode due to bool typedef
Although...
bool is typedefed here:
> #ifndef __cplusplus
>
> typedef int bool;
> # define false (0)
> # define true (!false)
>
> #endif /* __cplusplus */
then we have:
> ID3_STRUCT(Mp3_Headerinfo)
> {
> Mpeg_Layers layer;
> Mpeg_Version version;
> MP3_BitRates bitrate;
> Mp3_ChannelMode channelmode;
> Mp3_ModeExt modeext;
> Mp3_Emphasis emphasis;
> Mp3_Crc crc;
> uint32 vbr_bitrate; // avg bitrate from xing header
> uint32 frequency; // samplerate
> uint32 framesize;
> uint32 frames;// nr of frames
> uint32 time; // nr of seconds in song
> bool privatebit;
> bool copyrighted;
> bool original;
> };
(+ other things using bool)
So switching to stdbool.h will break the ABI of this structure from C
(but not from C++) which is unfortunate. But I think it's already a bit
broken because id3 itself is compiled with C++. Maybe switching to
stdbool.h will unbreak it ???
There are also functions that return "bool". At least on x86_64 the top
bits of a bool are unspecified so false could be interpreted as true by
a C program. I guess it only works right now by luck!
James
