Bug#1006599: transition: capnproto

[Tom Lee]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: deb...@tomlee.co tmanc...@debian.org
Severity: normal

Hi,

Requesting a transition for capnproto 0.9.1. It's in experimental and there
is
an auto transition page here:

https://release.debian.org/transitions/html/auto-capnproto.html

clickhouse is the only reverse dependency that FTBFS but it was already
broken
prior to the 0.8.0 transition due to issues unrelated to the capnproto
package:

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

clickhouse was removed from testing in 2021 because of this issue and there
has been no movement since. Since it's not likely to be fixed soon and we're
again receiving requests for new capnproto packaging we'd like to proceed
with the transition.

Let me know if I can provide any further details.

Ben file:

title = "capnproto";
is_affected = .depends ~ "libcapnp-0.8.0" | .depends ~ "libcapnp-0.9.1";
is_good = .depends ~ "libcapnp-0.9.1";
is_bad = .depends ~ "libcapnp-0.8.0";

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#1006415: FTBFS with capnproto 0.9.1

[Tom Lee]

Hi Dirk,

First let me answer a few of your questions that I just realized I missed:

Can you explain (to a cmake newb) the logic behind
>
> ++if (TILEDB_UPDATE_SERIALIZATION)
> ++  add_dependencies(tiledb_shared update-serialization)
> ++endif()
> + if (TILEDB_STATIC)
> +   set_target_properties(tiledb_static
> + PROPERTIES
> +   PUBLIC_HEADER "${TILEDB_PUBLIC_HEADERS}"
> +   )
> ++  if (TILEDB_UPDATE_SERIALIZATION)
> ++add_dependencies(tiledb_static update-serialization)
> ++  endif()
> + endif()
>

So the tiledb upstream sources include *pre-generated *capnproto sources
that were generated using 0.8.0. The *update-serialization* target will
regenerate those sources for us using whatever version of capnproto is
installed but that target doesn't run by default. So here I'm making
*update-serialization* a dependency of tiledb_shared and tiledb_static to
ensure it runs.

It could also be achieved by modifying debian/rules to invoke the
*update-serialization
*target before running the main build if you'd prefer that, I was just
trying to come up with something that upstream might be interested in to
make future upgrades more straightforward for us.

Why a second variable TILEDB_UPDATE_SERIALIZATION?  To cover the 'yes well
> it
> is 0.8.0 but you will live' case from allowing 0.9.1 in the new interval
> spec
> '++set(TILEDB_CAPNPROTO_VERSION 0.8.0...0.9.1)' ?
>

Again, by default *update-serialization *won't run so this option forces it
to run by adding it as a dependency of tiledb_shared/tiledb_static.

Now, back to the patch: if it's not clear, the patch I sent you is
something to be applied to the whole source repo, not something added to
the quilt series. It's a patch that includes a patch, if you like. :)
Should apply cleanly against 2.6.2-2 with *patch -p1
= 0.8.0) *to the Build-Depends in debian/control
2. Set TILEDB_CAPNPROTO_VERSION to 0.8.0...0.9.1 (either directly in the
configure step or via the cmake foo in my patch)
3. Invoke the *update-serialization* cmake target before building shared
libraries (either right before the build step or via the cmake foo in my
patch)

You can skip the TILEDB_UPDATE_SERIALIZATION stuff if it's getting in the
way.

Cheers,
Tom

On Fri, Feb 25, 2022 at 1:14 PM Tom Lee  wrote:

> Hi Dirk,
>
> Thanks for giving it a shot. Surprised to hear the patch didn't apply
> cleanly, believe I worked directly from the source pulled via
>
> dget -a http://deb.debian.org/debian/pool/main/t/tiledb/tiledb_2.6.2-2.dsc
>
> I even had a DD co-maintainer try the patch before I sent it your way so
> not quite sure what I messed up. In terms of testing, tested by myself and
> the co-maintainer. I'm not sure what to suggest here but I can try
> regenerating the patch, perhaps I should try again using dpkg-source
> --commit.
>
> Can't speak to the build failure, perhaps send through your own patch and
> the full build log and I'll take a look.
>
> Cheers,
> Tom
>
>
> On Fri, Feb 25, 2022 at 5:17 AM Dirk Eddelbuettel  wrote:
>
>>
>> Tom,
>>
>> Sad news.  The build fails for me in unstable as is (using an updated
>> pbuilder chroot).  I log these to file and what I see is
>>
>> cd /build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb && /usr/bin/cc
>> -DFMT_LOCALE -DFMT_SHARED -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL
>> -DSPDLOG_FMT_EXTERNAL=1 -DSPDLOG_SHARED_LIB -DTILEDB_CORE_OBJECTS_EXPORTS
>> -DTILEDB_SERIALIZATION -DTILEDB_STATS -D_FILE_OFFSET_BITS=64
>> -I/build/tiledb-2.6.2/tiledb/..
>> -I/build/tiledb-2.6.2/tiledb/../tiledb/sm/c_api
>> -I/build/tiledb-2.6.2/tiledb/../external/include
>> -I/build/tiledb-2.6.2/tiledb/../external/include/bitshuffle
>> -I/build/tiledb-2.6.2/tiledb/../external/include/blosc
>> -I/build/tiledb-2.6.2/external/blosc/include
>> -I/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb/..
>> -I/build/tiledb-2.6.2/tiledb/../tiledb/sm/cpp_api
>> -I/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb -g -O2
>> -ffile-prefix-map=/build/tiledb-2.6.2=. -fstack-protector-strong -Wformat
>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
>> -fvisibility=hidden -Wall -Wextra -mavx2 -w -DPTHREAD_AVAILABLE -MD -MT
>> tiledb/CMakeFiles/TILEDB_CORE_OBJECTS.dir/__/external/blosc/src/shuffle-avx2.c.o
>> -MF
>> CMakeFiles/TILEDB_CORE_OBJECTS.dir/__/external/blosc/src/shuffle-avx2.c.o.d
>> -o
>> CMakeFiles/TILEDB_CORE_OBJECTS.dir/__/external/blosc/src/shuffle-avx2.c.o
>> -c /build/tiledb-2.6.2/external/blosc/src/shuffle-avx2.c
>> [ 96%] Building CXX object
>> tiledb/CMakeFiles/TILEDB_CORE_OBJECTS.dir/sm/serialization/posix/tiledb-rest.capnp.c++.o
>> cd /build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb && /u

Bug#1006415: FTBFS with capnproto 0.9.1

[Tom Lee]

Hi Dirk,

Thanks for giving it a shot. Surprised to hear the patch didn't apply
cleanly, believe I worked directly from the source pulled via

dget -a http://deb.debian.org/debian/pool/main/t/tiledb/tiledb_2.6.2-2.dsc

I even had a DD co-maintainer try the patch before I sent it your way so
not quite sure what I messed up. In terms of testing, tested by myself and
the co-maintainer. I'm not sure what to suggest here but I can try
regenerating the patch, perhaps I should try again using dpkg-source
--commit.

Can't speak to the build failure, perhaps send through your own patch and
the full build log and I'll take a look.

Cheers,
Tom


On Fri, Feb 25, 2022 at 5:17 AM Dirk Eddelbuettel  wrote:

>
> Tom,
>
> Sad news.  The build fails for me in unstable as is (using an updated
> pbuilder chroot).  I log these to file and what I see is
>
> cd /build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb && /usr/bin/cc
> -DFMT_LOCALE -DFMT_SHARED -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL
> -DSPDLOG_FMT_EXTERNAL=1 -DSPDLOG_SHARED_LIB -DTILEDB_CORE_OBJECTS_EXPORTS
> -DTILEDB_SERIALIZATION -DTILEDB_STATS -D_FILE_OFFSET_BITS=64
> -I/build/tiledb-2.6.2/tiledb/..
> -I/build/tiledb-2.6.2/tiledb/../tiledb/sm/c_api
> -I/build/tiledb-2.6.2/tiledb/../external/include
> -I/build/tiledb-2.6.2/tiledb/../external/include/bitshuffle
> -I/build/tiledb-2.6.2/tiledb/../external/include/blosc
> -I/build/tiledb-2.6.2/external/blosc/include
> -I/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb/..
> -I/build/tiledb-2.6.2/tiledb/../tiledb/sm/cpp_api
> -I/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb -g -O2
> -ffile-prefix-map=/build/tiledb-2.6.2=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> -fvisibility=hidden -Wall -Wextra -mavx2 -w -DPTHREAD_AVAILABLE -MD -MT
> tiledb/CMakeFiles/TILEDB_CORE_OBJECTS.dir/__/external/blosc/src/shuffle-avx2.c.o
> -MF
> CMakeFiles/TILEDB_CORE_OBJECTS.dir/__/external/blosc/src/shuffle-avx2.c.o.d
> -o
> CMakeFiles/TILEDB_CORE_OBJECTS.dir/__/external/blosc/src/shuffle-avx2.c.o
> -c /build/tiledb-2.6.2/external/blosc/src/shuffle-avx2.c
> [ 96%] Building CXX object
> tiledb/CMakeFiles/TILEDB_CORE_OBJECTS.dir/sm/serialization/posix/tiledb-rest.capnp.c++.o
> cd /build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb && /usr/bin/c++
> -DFMT_LOCALE -DFMT_SHARED -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL
> -DSPDLOG_FMT_EXTERNAL=1 -DSPDLOG_SHARED_LIB -DTILEDB_CORE_OBJECTS_EXPORTS
> -DTILEDB_SERIALIZATION -DTILEDB_STATS -D_FILE_OFFSET_BITS=64
> -I/build/tiledb-2.6.2/tiledb/..
> -I/build/tiledb-2.6.2/tiledb/../tiledb/sm/c_api
> -I/build/tiledb-2.6.2/tiledb/../external/include
> -I/build/tiledb-2.6.2/tiledb/../external/include/bitshuffle
> -I/build/tiledb-2.6.2/tiledb/../external/include/blosc
> -I/build/tiledb-2.6.2/external/blosc/include
> -I/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb/..
> -I/build/tiledb-2.6.2/tiledb/../tiledb/sm/cpp_api
> -I/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb/tiledb -g -O2
> -ffile-prefix-map=/build/tiledb-2.6.2=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> -fvisibility=hidden -Wall -Wextra -Wno-literal-suffix -mavx2 -std=c++17 -MD
> -MT
> tiledb/CMakeFiles/TILEDB_CORE_OBJECTS.dir/sm/serialization/posix/tiledb-rest.capnp.c++.o
> -MF
> CMakeFiles/TILEDB_CORE_OBJECTS.dir/sm/serialization/posix/tiledb-rest.capnp.c++.o.d
> -o
> CMakeFiles/TILEDB_CORE_OBJECTS.dir/sm/serialization/posix/tiledb-rest.capnp.c++.o
> -c /build/tiledb-2.6.2/tiledb/sm/serialization/posix/tiledb-rest.capnp.c++
> make[7]: Leaving directory
> '/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb'
> [ 96%] Built target TILEDB_CORE_OBJECTS
> make[6]: Leaving directory
> '/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb'
> make[5]: *** [Makefile:146: all] Error 2
> make[5]: Leaving directory
> '/build/tiledb-2.6.2/obj-x86_64-linux-gnu/tiledb'
> make[4]: *** [CMakeFiles/tiledb.dir/build.make:89:
> tiledb-prefix/src/tiledb-stamp/tiledb-build] Error 2
> make[4]: Leaving directory '/build/tiledb-2.6.2/obj-x86_64-linux-gnu'
> make[3]: *** [CMakeFiles/Makefile2:90: CMakeFiles/tiledb.dir/all] Error 2
> make[3]: Leaving directory '/build/tiledb-2.6.2/obj-x86_64-linux-gnu'
> make[2]: *** [Makefile:94: all] Error 2
> make[2]: Leaving directory '/build/tiledb-2.6.2/obj-x86_64-linux-gnu'
> dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j12
> "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2
> make[1]: *** [debian/rules:47: override_dh_auto_build] Error 25
> make[1]: Leaving directory '/build/tiledb-2.6.2'
> make: *** [debian/rules:22: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit
> status 2
>
> which makes no sense to me as I see no error.
>
> I would appreciate some help here.
>
> Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#1006416: FTBFS with capnproto 0.9.1

[Tom Lee]

Source: mir
Version: 1.8.2+dfsg-2
Severity: important
Tags: bookworm sid
X-Debbugs-CC: tmanc...@debian.org

Hi, mir fails to build against capnproto 0.9.1 because of a conflict with
Xlib headers -- see: https://github.com/capnproto/capnproto/issues/1393 ...
mir has applied this change upstream to work around the issue:
https://github.com/MirServer/mir/pull/2267. I've attached a patch
incorporating the upstream fix but it should be trivial to apply it
manually if you prefer.

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>


mir-capnp-0.9.1.patch
Description: Binary data

Bug#1006415: FTBFS with capnproto 0.9.1

[Tom Lee]

Source: tiledb
Version: 2.6.2
Severity: important
Tags: bookworm sid
X-Debbugs-CC: tmanc...@debian.org

Hi there,

tiledb fails to build against capnproto 0.9.1, largely because of the
hard-coded version number in the cmake modules. Attached is a patch that
should allow tiledb to build against both 0.8.0 and 0.9.1 for the upcoming
transition.

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>


tiledb-capnp-0.9.1.patch
Description: Binary data

Bug#1006299: capnproto: FTBFS with OpenSSL 3.0

[Tom Lee]

Sounds good to me Tony. I'll try to take a look at tiledb and mir too.

On Wed, Feb 23, 2022 at 12:39 PM tony mancill  wrote:

> On Tue, Feb 22, 2022 at 11:35:54PM +0100, Sebastian Andrzej Siewior wrote:
> > Source: capnproto
> > Version: 0.8.0-2
> > Severity: important
> > Tags: bookworm sid
> > User: pkg-openssl-de...@lists.alioth.debian.org
> > Usertags: ftbfs-3.0
> >
> > Your package is failing to build using OpenSSL 3.0 with the
> > following error:
>
> Tom, I don't know if you've had a chance to look at this in depth yet (I
> haven't), but I'm wondering if we shouldn't just push forward with the
> capnproto 0.9.1 transition, since that's our target for bookworm anyway.
>
> I checked the r-deps and tiledb and mir are (still) FTBFS against 0.9.1,
> so digging into those build failures are next on my list.
>
> Thoughts?
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#983645: plans for capnproto

[Tom Lee]

Hey meskio,

0.9.1 is being actively worked on, biggest blocker at this point is around
making sure we have all our copyright attributions correct I think. A few
important architectures were also FTBFS with the last upload but believe we
have a fix for that.

I think we should expect 0.9.1 in sid "soon" but it's hard to give an exact
timeline at this point. Bear with me if you can but go ahead and upload to
experimental for now if you're blocked.

Cheers,
Tom


On Fri, Feb 11, 2022 at 2:00 AM meskio  wrote:

> Hello Tom,
>
> I'm the maintainer of the laminar[0] debian package, which uses capnproto.
> There
> are several fixes that we care about included in capnproto >= 0.9.0. I see
> 0.9.1
> is already in experimental. What are your plans for it? Might it graduate
> to sid
> soon? Or will it take some time in experimental?
>
> I'm thinking if is worth it for me to upload the new version of laminar
> into
> experimental or wait for capnproto to get into sid.
>
> Thanks.
>
> [0] https://laminar.ohwg.net/
>
>
> Quoting Jan-Benedict Glaw (2022-02-10 11:09:57)
> >   * Under some circumstances, laminard didn't accept any further web
> > requests when a client shut down the connection kind of at the
> > wrong point. That was an issue with capnproto
> > (https://github.com/capnproto/capnproto/pull/1407), which has no
> > new release yet after that was merged. I hope Tom Lee will package
> > capnproto quickly with the next release. Right now, Debian's 0.7
> > version is quite dated...
>
> --
> meskio | https://meskio.net/
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  My contact info: https://meskio.net/crypto.txt
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Nos vamos a Croatan.



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#1005066: capnproto 0.9.1 FTBFS on armel

[Tom Lee]

If I'm reading right I *think* it's more likely to be just an
oversight/bug. Atomic operations are basically intrinsics on some
architectures (most notably x86) so no need to link another library. Other
architectures need a little more of a lift. I'll have a patch we can try
soon.

tom@debian-bullseye-arm64:~$ apt-cache show libatomic1
Package: libatomic1
Source: gcc-11
Version: 11.2.0-13
Installed-Size: 48
Maintainer: Debian GCC Maintainers 
Architecture: arm64
Depends: gcc-11-base (= 11.2.0-13), libc6 (>= 2.17)
Description-en: support library providing __atomic built-in functions
 library providing __atomic built-in functions. When an atomic call cannot
 be turned into lock-free instructions, GCC will make calls into this
library.
Description-md5: 16938852526fc26bdbcb46c18435ed08
Multi-Arch: same
Homepage: http://gcc.gnu.org/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/g/gcc-11/libatomic1_11.2.0-13_arm64.deb
Size: 9468
MD5sum: ecc8ec0485239764081a18816ad03c99
SHA256: c75dea8b3d70d994a90cc180779b4d531220d3566d38a5081ef2e4c3f9df3664

...snip...

On Sun, Feb 6, 2022 at 8:45 AM tony mancill  wrote:

> On Sun, Feb 06, 2022 at 08:12:12AM -0800, tony mancill wrote:
> > Source: capnproto
> > Version: 0.9.1-1
> > Severity: important
> >
> > This bug is for tracking the armel build failure [1]:
>
> And it's the same on mipsel.  Did upstream drop support for 32-bit
> architectures other than x86?
>
> https://buildd.debian.org/status/logs.php?pkg=capnproto=0.9.1-1
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#1005066: capnproto 0.9.1 FTBFS on armel

[Tom Lee]

Looks like we might need -latomic on armel

On Sun, Feb 6, 2022 at 8:15 AM tony mancill  wrote:

> Source: capnproto
> Version: 0.9.1-1
> Severity: important
>
> This bug is for tracking the armel build failure [1]:
>
> > libtool: link: g++  -fPIC -DPIC -shared -nostdlib
> /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/crti.o
> /usr/lib/gcc/arm-linux-gnueabi/11/crtbeginS.o
> src/capnp/compiler/.libs/type-id.o
> src/capnp/compiler/.libs/error-reporter.o
> src/capnp/compiler/.libs/lexer.capnp.o src/capnp/compiler/.libs/lexer.o
> src/capnp/compiler/.libs/grammar.capnp.o src/capnp/compiler/.libs/parser.o
> src/capnp/compiler/.libs/generics.o
> src/capnp/compiler/.libs/node-translator.o
> src/capnp/compiler/.libs/compiler.o src/capnp/.libs/schema-parser.o
> src/capnp/.libs/serialize-text.o   -Wl,-rpath -Wl,/<>/.libs
> ./.libs/libcapnp.so ./.libs/libkj.so -lpthread
> -L/usr/lib/gcc/arm-linux-gnueabi/11
> -L/usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi
> -L/usr/lib/gcc/arm-linux-gnueabi/11/../../.. -L/lib/arm-linux-gnueabi
> -L/usr/lib/arm-linux-gnueabi -lstdc++ -lm -lc -lgcc_s
> /usr/lib/gcc/arm-linux-gnueabi/11/crtendS.o
> /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/crtn.o
> -pthread -g -O2 -fstack-protector-strong -pthread -Wl,-z -Wl,relro -Wl,-z
> -Wl,now   -pthread -Wl,-soname -Wl,libcapnpc-0.9.1.so -o .libs/
> libcapnpc-0.9.1.so
> > libtool: link: g++ -I./src -I./src -DKJ_HEADER_WARNINGS
> -DCAPNP_HEADER_WARNINGS -DCAPNP_INCLUDE_DIR=\"/usr/include\" -pthread -g
> -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -DNDEBUG -pthread -DKJ_HAS_ZLIB -DKJ_HAS_OPENSSL
> -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/capnpc-c++
> src/capnp/compiler/capnpc-c++.o  ./.libs/libcapnp.so ./.libs/libkj.so
> -lpthread -pthread
> > /usr/bin/ld: ./.libs/libcapnp.so: undefined reference to
> `__atomic_load_8'
> > /usr/bin/ld: ./.libs/libcapnp.so: undefined reference to
> `__atomic_store_8'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [Makefile:2111: capnpc-c++] Error 1
>
> Cheers,
> tony
>
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=capnproto=armel=0.9.1-1=1644104535=log
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#1005011: lots of missing entries in debian/copyright

[Tom Lee]

Tony, without commenting on severity and policy concerns I'm happy to have
a first stab at this if you like.

And seconding Tony, thank you for the detailed review Thorsten!

On Sat, Feb 5, 2022 at 8:51 AM tony mancill  wrote:

> On Sat, Feb 05, 2022 at 12:08:03PM +, Thorsten Alteholz wrote:
> > Package: capnproto
> > please rework your debian/copyright. Especially
>
> Hi Thorsten,
>
> In my previous response, I neglected to say thank you for the thorough
> review of the package and its debian/copyright.  Thank you for the
> effort and detail you put into these reviews!
>
> Regards,
> tony
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#920230: Patch for your Git repository

[Tom Lee]

Appreciate it Andreas, thank you. Working the NMU changes into a new
release along with some other important changes that have come up.

I'll look at moving things over to salsa.debian.org when time permits --
thanks for the suggestion.

On Wed, Jan 30, 2019 at 12:21 AM Andreas Tille  wrote:

> Hi,
>
> I attached a commit for you Git repository to record the changes of my NMU.
> BTW, it would be easier if you would decide to maintain capnproto on
>https://salsa.debian.org/debian
>
> Hope this helps, Andreas.
>
> --
> http://fam-tille.de
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#919180: [PATCH] Install missing shared libraries (Closes: #919180)

[Tom Lee]

Thanks for that Dmitry, big oversight on my part.

Thanks too for the nudge Tony -- can you give
https://github.com/thomaslee/capnproto-debian/pull/2 a quick eyeball &
we'll call it 0.7.0-3? Incorporating Andreas' NMU changes + Dmitry's patch
and a few other changes to fill in the gaps. Added you as a collaborator,
feel free to merge/whatever if it makes things easier for you.

On Sun, Feb 3, 2019 at 10:11 AM tony mancill  wrote:

> Hi Dmitry,
>
> Thank you for the patch.
>
> Tom, any concerns with an upload to acknowledge Andreas's NMU and
> include Dmitry's patch?
>
> Cheers,
> tony
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

Awesome, will do Chris. I'll leave this ticket & the rest of hiredis in
your capable hands. Hopefully this will streamline redis maintenance for
you folks going forward. Thanks & all the best!

On Sun, Nov 4, 2018 at 3:24 PM Chris Lamb  wrote:

> Hi Tom,
>
> >1. Clone https://github.com/thomaslee/hiredis-debian and push
> everything
> >up to wherever is convenient for ongoing maintenance if you want to
> keep
> >git history from this point forward.
>
> So, I've:
>
>  * Cloned it all
>
>  * Pushed to salsa
>
>  * Made an upload (hiredis_0.14.0-3_amd64.changes) to "confirm" all
>of this with a handful of minor changes.
>
> What I suggest you do re. repo deletion is mark at is "Archived" or
> similar in the admin settings for this repo on Github and change
> the description to say:
>
>   Moved to: https://salsa.debian.org/lamby/pkg-hiredis;
>
> .. or similar. Thanks!
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

Sorry for the confusion guys, I assumed (perhaps as Tony did) we'd need an
RFA/something to transfer maintainership to Chris & was just trying to keep
everything moving in the interim.

Chris, if you're ready to take ownership of hiredis immediately it's all
yours -- can I suggest you:

   1. Clone https://github.com/thomaslee/hiredis-debian and push everything
   up to wherever is convenient for ongoing maintenance if you want to keep
   git history from this point forward. (I have no intention of deleting the
   repo from GitHub, but don't want a thoughtless repo deletion to cause you
   folks any headaches in the future). Note I haven't yet tagged
   debian/0.14.0-2 just yet but it can be safely made against the HEAD commit
   on master -- I'm not near my Debian "stuff" right now, but I can create the
   tag later today if you don't beat me to it.
   2. Take care of whatever needs to happen in the packaging and/or Debian
   infra RE: reporting you / the redis team as the maintainers of the hiredis
   packages (including taking point on the issue tracker etc.)
   3. Do whatever you need to do to get 0.14.0-3 out the door without me
   getting in the way.

Tony, don't think there's any action needed from you or me at this point.
Thanks so much for your help with the earlier releases of 0.14.0 & taking a
look at the backport, hope I didn't waste too much of your time in the
process.

I think that's everything Chris, but let me know if you need anything else
on my end.

Cheers,
Tom


On Sun, Nov 4, 2018 at 10:29 AM Chris Lamb  wrote:

> Tony,
>
> > transition maintainership, we can file an RFA bug, which is all of the
> > formality that is needed.
>
> hm? No formalities are required. Indeed, an RFA bug would actually
> be misleading here as it implies a request for anyone to adopt it
> (vs.  me adopting it).
>
> > Also, since I have porterbox access, let me know what would be helpful.
>
> I wouldn't spend too long; this architecture is notorious. Just
> make it non-fatal on that arch and move on. :)
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

>
> Tempting to disable the tests on this architecture (or, rather, making
> them non-fatal).
>

I'd prefer the latter, but might be better to simply disable 'em on
mips64el since they sit there doing nothing for ~2.5 hours apparently: "E:
Build killed with signal TERM after 150 minutes of inactivity".

Tony, not sure if you're following along at home, but I'll try to hook that
up over the next day or two if I can trouble you for a 0.14.0-3 upload.

Sure. Shall we discuss this on another bug, or..?


I'm not sure what kind of formalities are involved (if any) in this sort of
"direct" adoption, so maybe another ticket makes sense. Whatever works best
for you, honestly.


On Fri, Nov 2, 2018 at 5:35 AM Chris Lamb  wrote:

> Hi Tom,
>
> > Yeah, oddly enough this happened with 0.14.0-1 too then mysteriously
> > resolved itself when retried
>
> Likely to be some timeout issue. Tempting to disable the tests on
> this architecture (or, rather, making them non-fatal).
>
> > Thinking slightly longer term: if you and/or the folks maintaining the
> > redis package would like to adopt hiredis that might make sense
>
> Sure. Shall we discuss this on another bug, or..?
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

Yeah, oddly enough this happened with 0.14.0-1 too then mysteriously
resolved itself when retried on a different mips64el buildd while I was
waiting for porterbox access.

Looking over here it seems to hate the mipsel-manda-* buildds:
https://buildd.debian.org/status/logs.php?pkg=hiredis=mips64el ... bit
odd.

Guess I should kick off the porterbox request again to get to the bottom of
it. I'll figure that out with Tony.

Thinking slightly longer term: if you and/or the folks maintaining the
redis package would like to adopt hiredis that might make sense -- as a
non-DD/DM it's likely I'll always be moving slower than you & redis is
obviously a relatively "hot" package. Aside from these occasionally
annoying cross-platform headaches, hiredis is very low maintenance in the
scheme of things & I don't want to be holding you folks up any time
vendored hiredis & released hiredis diverge. (Don't feel obliged & I'm
happy to continue maintenance, it just seems like you folks might be able
to operate more effectively if we get hiredis + redis maintenance under the
same umbrella.)

Cheers,
Tom

On Fri, Nov 2, 2018 at 1:58 AM Chris Lamb  wrote:

> Chris Lamb wrote:
>
> > > will push the backport when 0.14.0-2 hits testing.
> >
> > Great, hopefully soon.
>
> Looks like there's a build issue on mips64el that is blocking this:
>
>   https://qa.debian.org/excuses.php?package=hiredis
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

Hey Chris,

See Tony's comment on the ticket dated Oct 28th -- he's uploaded 0.14.0-2
to unstable & will push the backport when 0.14.0-2 hits testing.

Cheers,
Tom


On Mon, Oct 29, 2018 at 5:39 AM Chris Lamb  wrote:

> Hi Tom,
>
> > Hey Chris -- maybe hold off on that. I have a work buddy DD who literally
> > emailed me this evening with a patch and an offer to upload the
> backport. :)
>
> Any progress on this? Thanks!
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

Awesome -- thank you Tony!

On Sun, Oct 28, 2018 at 11:27 AM tony mancill  wrote:

> owner 911732 tmanc...@debian.org
> thanks
>
> Hi All,
>
> The backport to stretch-backports is trivial - I only have to downgrade
> debhelper from 11 to 10 to build against stretch - and so I plan to do
> the bpo upload once 0.14.0-2 hits testing.
>
> Cheers,
> tony
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

Hey Chris -- maybe hold off on that. I have a work buddy DD who literally
emailed me this evening with a patch and an offer to upload the backport. :)

He may or may not also be pushing a 0.14.0-2 release with some very minor
packaging fixes, don't think it should be anything that impacts you though.
I'll keep you updated RE: what eventuates, but it's now unlikely to be
"weeks".

Cheers,
Tom


On Thu, Oct 25, 2018 at 5:56 AM Chris Lamb  wrote:

> Hi Tom,
>
> > > Thank you for packaging 0.14.0 in #907259. Would it be possible
> > > backport this version to stretch-backports? That would allow me
> > > Redis to use the system hiredis for its own backport too.
> [..]
> > Hey Chris -- sure, but maybe give me a few weeks to look into it -- not
> > something I've done before. Keep you posted.
>
> I could upload in the meantime with your ACK...?
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#911732: hiredis: Please backport 0.14.0 to stretch -backports

[Tom Lee]

Hey Chris -- sure, but maybe give me a few weeks to look into it -- not
something I've done before. Keep you posted.

On Tue, Oct 23, 2018 at 7:51 PM Chris Lamb  wrote:

> Package: hiredis
> Version: 0.14.0-1
> Severity: wishlist
>
> Hi,
>
> Thank you for packaging 0.14.0 in #907259. Would it be possible
> backport this version to stretch-backports? That would allow me
> Redis to use the system hiredis for its own backport too.
>
> Thanks in advance.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#905351: can capnproto be marked Multi-Arch: foreign?

[Tom Lee]

Thanks for the report Helmut, very sorry for the delay in getting back to
you.

You asked:

The invocation however says "compile". Does it actually run a C compiler?


I don't believe so: the "compile" step should just be converting a
(textual) schema into some target source language (usually C++).

The multiarch hinter says that the libcapnp-* packages should be
> Multi-Arch: same.
>

I'm confused whether I should be adding Multi-Arch: foreign or Multi-Arch:
same. :) I'm also a little unclear of the implications of adding either --
if you can give a high-level summary it'd be appreciated. I'm not
particularly familiar with multi-arch/cross-compilation as it pertains to
Debian at the moment.

Thanks a ton for your patience -- I'm in the process of prepping 0.7.0 for
release, so if this is easy enough to wrap up we should be able to get it
out in the next upload.


On Fri, Aug 3, 2018 at 6:45 AM Helmut Grohne  wrote:

> Package: capnproto
> Version: 0.6.1-1
> Control: affects -1 + src:sonic-visualiser
> User: helm...@debian.org
> Usertags: rebootstrap
>
> cross building sonic-visualiser fails, because running capnp fails with
> an "Exec format error". That usually indicates that the relevant package
> (capnproto in this case) should be marked Multi-Arch: foreign to select
> the build architecture version rather than the host architecture one.
> But is such a marking actually correct?
>
> Unfortunately, answering that question is usually difficult as it
> requires both multiarch-specific knowledge and package-specific
> knowledge. Most people lack either or both. I for one lack the latter.
> Can you help me understand whether the marking is correct?
>
> The capnproto package contains a few programs. When thinking about
> Multi-Arch, one thinks about the interface of a package and these
> programs certainly are the main interface. The question to ask is: Do
> they behave any different when run on a different architecture?
> Sometimes one can quickly assert that both input and output formats are
> textual rather than binary. Is that the case for capnproto? If yes, it
> seems very likely that the marking can be correct. The invocation
> however says "compile". Does it actually run a C compiler? Since the
> output of a C compiler is architecture-dependent, running it voids and
> Multi-Arch: foreign marking.
>
> Please enter a discussion with me such that we can find out the correct
> Multi-Arch marking for capnproto. The actual marking is a rather simple
> step, once we know how it should be marked. The multiarch hinter says
> that the libcapnp-* packages should be Multi-Arch: same. Please consider
> adding that. If in doubt, please ask me.
>
> Thanks for your assistance
>
> Helmut
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#907258: Bug#907259: Bug#907258: Bug#907259: Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

On Thu, Sep 27, 2018 at 2:21 AM Chris Lamb  wrote:

> Hi Tom,
>
> > Otherwise it should be fine aside from a few gripes from the pedantic
> > lintian checks.
>
> Hm, why don't you just fix these?


Time, mostly. Was expecting not to be available for a while, but had some
spare time today to wrap it up.

One outstanding lint check I'm not sure if I should be actioning yet:

P: hiredis source: debug-symbol-migration-possibly-complete
> --dbgsym-migration='libhiredis-dbg (line 37)
>

I should leave that one be until after this upload, right?


> Also, before I upload please could
> you address:
>
>  * Use compat level 11.
>
>  * Add  to the relevant build-dependencies.
>
>  * Drop unnecessary cruft (DEB_DESTDIR, "#export DH_VERBOSE=1" etc.
>etc.)
>
>
Should be all done.

Of note:

   - Haven't used the build profile stuff before, hopefully I'm doing it
   right.
   - I think dh_fixperms (or something else independent of the build) may
   be marking .pc/.cmake files under usr/lib, so had to work around that in
   override_dh_fixperms. Not sure if there's a better way.
   - No GPG signatures available upstream, so added a lintian override for
   that for now.

Cheers,
Tom
-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#907258: Bug#907259: Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

Phew, done: https://github.com/thomaslee/hiredis-debian

Note because of the SONAME change / API & ABI breakage the binary package
name changed from libhiredis0.13 to libhiredis0.14. Can't recall exactly
how to handle that ... I was tempted to add Breaks/Replaces stanzas to
debian/control but thought better of it. Let me know if I need to take any
action there.

Otherwise it should be fine aside from a few gripes from the pedantic
lintian checks.

Cheers,
Tom

On Wed, Sep 26, 2018 at 1:21 AM Chris Lamb  wrote:

> Hi Tom,
>
> Great stuff.
>
> > Would you be willing to sponsor the upload when it's ready
>
> Gladly. Please either send me a HTTP-accessible link to a .dsc that works
> with "dget" or a pointer to a git-buildpackage repository when you are
> ready for me to have a look at this.
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

Hey again Chris,

Quick update: we've got a 0.14.0 release from upstream that I think should
be compatible with redis. Patches updated, test suite is passing & now I've
just got a few lintian headaches to work through. Should have a new release
for you in the next day or two.

Would you be willing to sponsor the upload when it's ready, or should I
reach out to somebody else?

On Mon, Sep 24, 2018 at 2:26 PM Tom Lee  wrote:

> Works for me.
>
> On Mon, Sep 24, 2018 at 2:21 PM Chris Lamb  wrote:
>
>> Hi Tom,
>>
>> > So if you don't mind waiting a little longer to see where upstream
>> hiredis
>> > #609 lands that'd be awesome
>>
>> Mmm, although let's not wait too long. I've replied to the issue (which
>> already has had one reply) so we'll see how it looks by this weekend...?
>>
>>
>> Best wishes,
>>
>> --
>>   ,''`.
>>      : :'  : Chris Lamb
>>  `. `'`  la...@debian.org / chris-lamb.co.uk
>>`-
>>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

Works for me.

On Mon, Sep 24, 2018 at 2:21 PM Chris Lamb  wrote:

> Hi Tom,
>
> > So if you don't mind waiting a little longer to see where upstream
> hiredis
> > #609 lands that'd be awesome
>
> Mmm, although let's not wait too long. I've replied to the issue (which
> already has had one reply) so we'll see how it looks by this weekend...?
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#907258: Bug#907259: Bug#907258: Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

Back up and running again Chris, thanks for your patience!

After poking around in diffs between 0.13.3 and master for a bit, I raised
a ticket upstream to see if we can get a "real" release:
https://github.com/redis/hiredis/issues/609

I'd really prefer to see a real release than to go yanking from an
arbitrary SHA -- even if it is a relatively slow-moving code base. No doubt
as time goes on we can expect redis & hiredis to slowly diverge again, but
it would be nice to keep things sane for good citizens targeting a specific
version number.

So if you don't mind waiting a little longer to see where upstream hiredis
#609 lands that'd be awesome. On the other hand, if you're really desperate
for the phony release let me know & I'll figure it out.

Bug#907259: hiredis: New upstream "release" ?

[Tom Lee]

Sorry for the delay & radio silence Chris -- I've been lazy getting my
Debian development environment set up on a new computer. Should have some
time over the weekend to get this sorted out.

On Wed, Sep 19, 2018 at 2:30 AM Chris Lamb  wrote:

> Hi Tom,
>
> > hiredis: New upstream "release" ?
>
> Gentle ping on this? it is blocking a fix for #907258 ("redis: Please
> use system hiredis to avoid embedded code copy")
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#878474: hiredis FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Tom Lee]

>
> I don't expect that you have to do anything special, apart from "git
> pull" and keeping the changes in the next versions.


Yep! That's what I meant: I'll be sure to pull this change into the next
release.

I'll try to have a look to the package BTS for some weeks, to see if
> the package has new bugs as a consequence of this change; but just in
> case that I fail to notice, please tell me if such things happens or
> if you think that I can help in any way!


Appreciate it, will do.  :)

Cheers,
Tom

On Sun, Nov 19, 2017 at 4:50 PM, Manuel A. Fernandez Montecelo <
manuel.montez...@gmail.com> wrote:

> 2017-11-20 0:17 GMT+01:00 Tom Lee <deb...@tomlee.co>:
> > Thank you Manuel, go for it. This slipped off my radar, will try to get
> it
> > sorted out soon. Sorry folks!
>
> OK, rescheduled, thanks.
>
> I don't expect that you have to do anything special, apart from "git
> pull" and keeping the changes in the next versions.
>
> I'll try to have a look to the package BTS for some weeks, to see if
> the package has new bugs as a consequence of this change; but just in
> case that I fail to notice, please tell me if such things happens or
> if you think that I can help in any way!
>
>
> Cheers.
> --
> Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#878474: hiredis FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Tom Lee]

Thank you Manuel, go for it. This slipped off my radar, will try to get it
sorted out soon. Sorry folks!

Cheers,
Tom

On Nov 19, 2017 2:42 PM, "Manuel A. Fernandez Montecelo" <
manuel.montez...@gmail.com> wrote:

> Control: tags -1 + pending
>
>
> Hi,
>
> 2017-10-15 02:09 Manuel A. Fernandez Montecelo:
>
>> Hi,
>>
>> 2017-10-14 00:34 Helmut Grohne:
>>
>>> Source: hiredis
>>> Version: 0.13.3-2
>>> Tags: patch
>>> User: helm...@debian.org
>>> Usertags: rebootstrap
>>>
>>> hiredis fails to cross build from source, because it fails running tests
>>> that it shouldn't be running when DEB_BUILD_OPTIONS contains nocheck.
>>> After making it honour the nocheck option, hiredis cross builds
>>> successfully. Please consider applying the attached patch.
>>>
>>
>> I can offer to sponsor an upload or NMU, if it helps.
>>
>
> I am going to do a NMU with this change, uploaded to delayed/10.
>
> If you want me to cancel it please say so; if it's OK please tell me and
> I can re-schedule it to happen earlier.
>
> Since the package is under collab-maint, instead of attaching the diff I
> just pushed to the repo.
>
>
> Cheers.
> --
> Manuel A. Fernandez Montecelo 
>

Bug#873540: capnproto: FTBFS on mips64el: test.capnp wants AnyList::Pipeline

[Tom Lee]

Thanks for the report Aaron, raised upstream at
https://github.com/capnproto/capnproto/issues/541

I'll dig into it more later this week if upstream doesn't beat me to it.

On Mon, Aug 28, 2017 at 1:01 PM, Aaron M. Ucko <u...@debian.org> wrote:

> Source: capnproto
> Version: 0.6.1-1
> Severity: serious
> Tags: upstream
> Justification: fails to build from source
>
> The latest mips64el build of capnproto failed, as detailed at
> https://buildd.debian.org/status/fetch.php?pkg=
> capnproto=mips64el=0.6.1-1=1503916947=0
> and (very briefly) excerpted below:
>
>   src/capnp/test.capnp.h:12247:29: error: 'Pipeline' in 'struct
>   capnp::AnyList' does not name a type
>  inline  ::capnp::AnyList::Pipeline getAnyListAsList();
>^~~~
>
> AFAICT, there's not supposed to be any such type, so the problem
> presumably lies in code generation.  Could you please take a look?
> Thanks!
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/
> finger/?a...@monk.mit.edu
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#871443: nanomsg questions

[Tom Lee]

Hi Harlan,

I'm potentially interested in picking up the Debian packaging for nanomsg,
just a few questions:

First, you mentioned upstream hasn't been especially responsive. Have they
simply not looked at / commented on patches that you've offered up,
expressed disinterest in figuring out the compatibility issues once the
issue was brought to their attention, ignored bug reports ... what exactly
is/was happening there?

Second, though I currently maintain a few Debian packages I'm not an
"accredited" DM capable of uploading my own packages. Would you be okay
acting as a sponsor for uploads? If not, I'll need to ask around.

Cheers,
Tom

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#866525: capnproto: New upstream release 0.6.1

[Tom Lee]

Thanks for the heads-up Jaromir, 0.6.1-1 is in the NEW queue and should
land in sid sometime over the next few days/weeks.

Bug#860960: capnproto: CVE-2017-7892

[Tom Lee]

Salvatore,

Assuming you raised this on behalf of the security team (and per
https://www.debian.org/intro/organization#security I'm assuming you are):

For a moment I thought it might be worth applying upstream's patch as a
precaution & requesting an unblock, but it really seems like it's just a
band-aid for a specific instances of the potential bad behavior rather than
a full-throated fix.

Per their info from the CVE:

> This change has been shown to fix the problem in practice. However, this
> quick fix does not technically avoid undefined behavior, as the code still
> computes pointers that point to invalid locations before they are checked.
> A technically-correct solution has been implemented in the next
> commit,2ca8e41140ebc618b8fb314b393b0a507568cf21. However, as this required
> more extensive refactoring, it is not appropriate for cherry-picking, and
> will only land in versions 0.6 and up.
>
> Given that, the fact there doesn't seem to be any evidence of the
practical aspects of the CVE outside of the Apple ecosystem and the fact
we're in the middle of a freeze, I think I'm going to defer any changes
directed at a "fix" until after the freeze lifts. Does that work for you?

Lastly: I'll work with my sponsor to get the 0.5.3.1-1 release uploaded as
soon as I can once the freeze does lift, but should we perhaps leave this
bug open until we see 0.6+ roll down from upstream with the
"technically-correct" solution?

Thanks again for flagging this.

Cheers,
Tom


On Sat, Apr 22, 2017 at 12:50 PM, Tom Lee <deb...@tomlee.co> wrote:

> Thanks for the reminder Salvatore -- I'll get this sorted out.
>
> On Sat, Apr 22, 2017 at 10:43 AM, Salvatore Bonaccorso <car...@debian.org>
> wrote:
>
>> Source: capnproto
>> Version: 0.5.3-2
>> Severity: minor
>> Tags: upstream security fixed-upstream
>>
>> Hi,
>>
>> the following vulnerability was published for capnproto.
>>
>> CVE-2017-7892[0]:
>> | Sandstorm Cap'n Proto before 0.5.3.1 allows remote crashes related to a
>> | compiler optimization. A remote attacker can trigger a segfault in a
>> | 32-bit libcapnp application because Cap'n Proto relies on pointer
>> | arithmetic calculations that overflow. An example compiler with
>> | optimization that elides a bounds check in such calculations is Apple
>> | LLVM version 8.1.0 (clang-802.0.41). The attack vector is a crafted far
>> | pointer within a message.
>>
>> So far only Apple's compiler has been shown to apply the problematic
>> optimization. The issue though is fixed in 0.5.3.1 and this bugreport
>> is to help track the fix so that we can properly update the fixing
>> version once the fix lands in the archive.
>>
>> If you fix the vulnerability please also make sure to include the
>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>>
>> For further information see:
>>
>> [0] https://security-tracker.debian.org/tracker/CVE-2017-7892
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7892
>>
>> Regards,
>> Salvatore
>>
>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#860960: capnproto: CVE-2017-7892

[Tom Lee]

Thanks for the reminder Salvatore -- I'll get this sorted out.

On Sat, Apr 22, 2017 at 10:43 AM, Salvatore Bonaccorso <car...@debian.org>
wrote:

> Source: capnproto
> Version: 0.5.3-2
> Severity: minor
> Tags: upstream security fixed-upstream
>
> Hi,
>
> the following vulnerability was published for capnproto.
>
> CVE-2017-7892[0]:
> | Sandstorm Cap'n Proto before 0.5.3.1 allows remote crashes related to a
> | compiler optimization. A remote attacker can trigger a segfault in a
> | 32-bit libcapnp application because Cap'n Proto relies on pointer
> | arithmetic calculations that overflow. An example compiler with
> | optimization that elides a bounds check in such calculations is Apple
> | LLVM version 8.1.0 (clang-802.0.41). The attack vector is a crafted far
> | pointer within a message.
>
> So far only Apple's compiler has been shown to apply the problematic
> optimization. The issue though is fixed in 0.5.3.1 and this bugreport
> is to help track the fix so that we can properly update the fixing
> version once the fix lands in the archive.
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2017-7892
>     https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7892
>
> Regards,
> Salvatore
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

Alrighty, having read through the other responses I'm inclined to agree
something's not playing nice with certain hardware:

I think that the difference is more likely to be in the configuration,
> rather than the patches we apply.
>
> As in the kernel config? I guess that's possible. I think I built my
"good" vanilla 4.9 kernel using the debian 4.6 config. Perhaps in addition
the booting-from-power-off, maybe worth my time to try another vanilla 4.9
build using the debian 4.9 config to see if things get miserable again.


On Thu, Jan 26, 2017 at 6:10 PM, Tom Lee <deb...@tomlee.co> wrote:

> Oops, somehow missed those follow-ups. Thanks, I'll catch up.
>
> Have you tried booting one of the newer kernel versions from power-off?
>
>
> I'll be sure to give that a go, thanks.
>
>
> On Thu, Jan 26, 2017 at 5:54 PM, Ben Hutchings <b...@decadent.org.uk>
> wrote:
>
>> On Wed, 2017-01-25 at 17:52 -0800, Tom Lee wrote:
>> > Just an update: I am still encountering similar performance issues with
>> the
>> > 4.9.0-1 kernel that was recently promoted to testing. In fact, the
>> 4.9.0-1
>> > kernel may be the worst yet in terms of this specific issue, with
>> IntelliJ
>> > starting so slowly as to be effectively unusable. One time the entire
>> > system appeared to become completely unresponsive & a hard reset was
>> > required.
>> >
>> > The most recent kernel with which I've experienced problems:
>> >
>> > $ apt-cache show linux-image-4.9.0-1-amd64
>> > Package: linux-image-4.9.0-1-amd64
>> > Source: linux-signed (4)
>> > Version: 4.9.2-2
>> > Installed-Size: 183299
>> >
>> > This problem does *not* seem to occur with a vanilla 4.9.2 kernel,
>> implying
>> > something Debian-specific:
>> >
>> > $ uname -a
>> > Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
>> > GNU/Linux
>> >
>> > If you're aware of any Debian patches that might be suspect, I'm happy
>> to
>> > try some custom builds. Reproducing the issue is trivial on my end when
>> a
>> > kernel is "bad".
>> [...]
>>
>> I think that the difference is more likely to be in the configuration,
>> rather than the patches we apply.
>>
>> Some other people followed up to your bug report suggesting there might
>> be a BIOS bug affecting behaviour after a warm reboot, but not booting
>> from power-off:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#17
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#32
>>
>> (Unfortunately I don't see any BIOS updates available for this model.)
>> Have you tried booting one of the newer kernel versions from power-off?
>>
>> Ben.
>>
>> --
>> Ben Hutchings
>> Design a system any fool can use, and only a fool will want to use it.
>>
>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

Oops, somehow missed those follow-ups. Thanks, I'll catch up.

Have you tried booting one of the newer kernel versions from power-off?


I'll be sure to give that a go, thanks.


On Thu, Jan 26, 2017 at 5:54 PM, Ben Hutchings <b...@decadent.org.uk> wrote:

> On Wed, 2017-01-25 at 17:52 -0800, Tom Lee wrote:
> > Just an update: I am still encountering similar performance issues with
> the
> > 4.9.0-1 kernel that was recently promoted to testing. In fact, the
> 4.9.0-1
> > kernel may be the worst yet in terms of this specific issue, with
> IntelliJ
> > starting so slowly as to be effectively unusable. One time the entire
> > system appeared to become completely unresponsive & a hard reset was
> > required.
> >
> > The most recent kernel with which I've experienced problems:
> >
> > $ apt-cache show linux-image-4.9.0-1-amd64
> > Package: linux-image-4.9.0-1-amd64
> > Source: linux-signed (4)
> > Version: 4.9.2-2
> > Installed-Size: 183299
> >
> > This problem does *not* seem to occur with a vanilla 4.9.2 kernel,
> implying
> > something Debian-specific:
> >
> > $ uname -a
> > Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
> > GNU/Linux
> >
> > If you're aware of any Debian patches that might be suspect, I'm happy to
> > try some custom builds. Reproducing the issue is trivial on my end when a
> > kernel is "bad".
> [...]
>
> I think that the difference is more likely to be in the configuration,
> rather than the patches we apply.
>
> Some other people followed up to your bug report suggesting there might
> be a BIOS bug affecting behaviour after a warm reboot, but not booting
> from power-off:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#17
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#32
>
> (Unfortunately I don't see any BIOS updates available for this model.)
> Have you tried booting one of the newer kernel versions from power-off?
>
> Ben.
>
> --
> Ben Hutchings
> Design a system any fool can use, and only a fool will want to use it.
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

Just an update: I am still encountering similar performance issues with the
4.9.0-1 kernel that was recently promoted to testing. In fact, the 4.9.0-1
kernel may be the worst yet in terms of this specific issue, with IntelliJ
starting so slowly as to be effectively unusable. One time the entire
system appeared to become completely unresponsive & a hard reset was
required.

The most recent kernel with which I've experienced problems:

$ apt-cache show linux-image-4.9.0-1-amd64
Package: linux-image-4.9.0-1-amd64
Source: linux-signed (4)
Version: 4.9.2-2
Installed-Size: 183299

This problem does *not* seem to occur with a vanilla 4.9.2 kernel, implying
something Debian-specific:

$ uname -a
Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
GNU/Linux

If you're aware of any Debian patches that might be suspect, I'm happy to
try some custom builds. Reproducing the issue is trivial on my end when a
kernel is "bad".


On Sun, Nov 20, 2016 at 2:24 PM, Tom Lee <deb...@tomlee.co> wrote:

> Also potentially relevant: kworker/0:0 has 421h on-cpu time reported per
> htop (the TIME+ column) and top. /proc//stat output for PID=4
> (kworker/0:0) vs PID=63 (kworker/1:1):
>
> tom@desktop ~ $ cat /proc/63/stat
> 63 (kworker/1:1) S 2 0 0 0 -1 69238880 0 0 0 0 0 0 0 0 20 0 1 0 82 0 0
> 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 1 0 0 184 0 0 0 0
> 0 0 0 0 0 0
> tom@desktop ~ $ cat /proc/4/stat
> 4 (kworker/0:0) S 2 0 0 0 -1 69238880 0 0 0 0 151836336 0 0 0 20 0 1 0 10
> 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0
>
> In fact, kworker:0:0 seems to be the only process with on-cpu stats
> reported (forgive the shell abuse, quick and dirty):
>
> $ for pid in $(ls /proc | awk '/^[0-9]*$/'); do [ -d /proc/$pid ] && awk
> '$14 != "0" { print $2 }' /proc/$pid/stat; done
> (kworker/0:0)
> $
>
>
> On Sun, Nov 20, 2016 at 2:12 PM, Tom Lee <deb...@tomlee.co> wrote:
>
>> Tried 4.8.0-1 with similar results. Perhaps slightly better, but not much.
>>
>> $ uname -a
>> Linux desktop 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64
>> GNU/Linux
>>
>> Like 4.7, can't see what's hogging the CPUs as per-process CPU stats
>> don't appear to be correctly reported in /proc//stat.
>>
>> 4.6.x continues to be perfect with respect to both overall performance
>> and the correctness of /proc//stat.
>>
>>
>> On Sat, Nov 12, 2016 at 8:23 PM, Ben Hutchings <b...@decadent.org.uk>
>> wrote:
>>
>>> Control: tag -1 moreinfo
>>>
>>> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
>>> [...]
>>> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't
>>> yet
>>> > tried 4.8.0-1 from unstable, not sure if it's impacted.
>>> [...]
>>>
>>> Please do.
>>>
>>> Ben.
>>>
>>> --
>>> Ben Hutchings
>>> Nothing is ever a complete failure; it can always serve as a bad
>>> example.
>>>
>>>
>>
>>
>> --
>> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>>
>>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

Also potentially relevant: kworker/0:0 has 421h on-cpu time reported per
htop (the TIME+ column) and top. /proc//stat output for PID=4
(kworker/0:0) vs PID=63 (kworker/1:1):

tom@desktop ~ $ cat /proc/63/stat
63 (kworker/1:1) S 2 0 0 0 -1 69238880 0 0 0 0 0 0 0 0 20 0 1 0 82 0 0
18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 1 0 0 184 0 0 0 0
0 0 0 0 0 0
tom@desktop ~ $ cat /proc/4/stat
4 (kworker/0:0) S 2 0 0 0 -1 69238880 0 0 0 0 151836336 0 0 0 20 0 1 0 10 0
0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0
0 0 0 0 0 0

In fact, kworker:0:0 seems to be the only process with on-cpu stats
reported (forgive the shell abuse, quick and dirty):

$ for pid in $(ls /proc | awk '/^[0-9]*$/'); do [ -d /proc/$pid ] && awk
'$14 != "0" { print $2 }' /proc/$pid/stat; done
(kworker/0:0)
$


On Sun, Nov 20, 2016 at 2:12 PM, Tom Lee <deb...@tomlee.co> wrote:

> Tried 4.8.0-1 with similar results. Perhaps slightly better, but not much.
>
> $ uname -a
> Linux desktop 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64
> GNU/Linux
>
> Like 4.7, can't see what's hogging the CPUs as per-process CPU stats don't
> appear to be correctly reported in /proc//stat.
>
> 4.6.x continues to be perfect with respect to both overall performance and
> the correctness of /proc//stat.
>
>
> On Sat, Nov 12, 2016 at 8:23 PM, Ben Hutchings <b...@decadent.org.uk>
> wrote:
>
>> Control: tag -1 moreinfo
>>
>> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
>> [...]
>> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't yet
>> > tried 4.8.0-1 from unstable, not sure if it's impacted.
>> [...]
>>
>> Please do.
>>
>> Ben.
>>
>> --
>> Ben Hutchings
>> Nothing is ever a complete failure; it can always serve as a bad
>> example.
>>
>>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

Tried 4.8.0-1 with similar results. Perhaps slightly better, but not much.

$ uname -a
Linux desktop 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64
GNU/Linux

Like 4.7, can't see what's hogging the CPUs as per-process CPU stats don't
appear to be correctly reported in /proc//stat.

4.6.x continues to be perfect with respect to both overall performance and
the correctness of /proc//stat.


On Sat, Nov 12, 2016 at 8:23 PM, Ben Hutchings <b...@decadent.org.uk> wrote:

> Control: tag -1 moreinfo
>
> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
> [...]
> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't yet
> > tried 4.8.0-1 from unstable, not sure if it's impacted.
> [...]
>
> Please do.
>
> Ben.
>
> --
> Ben Hutchings
> Nothing is ever a complete failure; it can always serve as a bad
> example.
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

oller ERROR
Registers 1 [1028:0541]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

ff:10.4 System peripheral [0880]: Intel Corporation Xeon E5/Core i7
Integrated Memory Controller Channel 0-3 Thermal Control 2 [8086:3cb4] (rev
07)
Subsystem: Dell Xeon E5/Core i7 Integrated Memory Controller Channel 0-3
Thermal Control 2 [1028:0541]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snbep_uncore

ff:10.5 System peripheral [0880]: Intel Corporation Xeon E5/Core i7
Integrated Memory Controller Channel 0-3 Thermal Control 3 [8086:3cb5] (rev
07)
Subsystem: Dell Xeon E5/Core i7 Integrated Memory Controller Channel 0-3
Thermal Control 3 [1028:0541]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snbep_uncore

ff:10.6 System peripheral [0880]: Intel Corporation Xeon E5/Core i7
Integrated Memory Controller ERROR Registers 2 [8086:3cb6] (rev 07)
Subsystem: Dell Xeon E5/Core i7 Integrated Memory Controller ERROR
Registers 2 [1028:0541]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

ff:10.7 System peripheral [0880]: Intel Corporation Xeon E5/Core i7
Integrated Memory Controller ERROR Registers 3 [8086:3cb7] (rev 07)
Subsystem: Dell Xeon E5/Core i7 Integrated Memory Controller ERROR
Registers 3 [1028:0541]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

ff:11.0 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 DDRIO
[8086:3cb8] (rev 07)
Subsystem: Dell Xeon E5/Core i7 DDRIO [1028:0541]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
ii  grub-efi-amd64  2.02~beta3-1
pn  linux-doc-4.7   

Versions of packages linux-image-4.7.0-1-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20160824-1
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#837126:

[Tom Lee]

Package: capnproto
Version: 0.5.3-2
Severity: important

The folks at Sandstorm have suggested it might make more sense for the
.capnp files to live in the capnproto package rather than libcapnp-dev.
This makes a whole lot of sense, since these files are only really useful
to the capnp command line tool & aren't really related to development
headers etc.

As it stands, it's a minor annoyance for users since in some cases folks
may need to install both capnproto _and_ libcapnp-dev to process certain
IDLs that in turn depend on "core" Capnproto IDLs. This seems avoidable if
we simply move those IDLs over to the capnproto binary package.

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#826684: staden,spin: error when trying to install together

[Tom Lee]

Thanks Andreas, appreciate you bringing this to my attention.

Complicating this: we're still in the process of getting spin through the
ITP/RFS process due to some licensing concerns with parts of the source
package, I think the package may have been accidentally uploaded today
instead of being rejected from the NEW queue. I'll follow up with the FTP
folks to get a sense of what's going on and try to get this resolved as
soon as I can.

Keep you posted.


On Tue, Jun 7, 2016 at 3:07 PM, Andreas Beckmann <a...@debian.org> wrote:

> Package: staden,spin
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
>
> Hi,
>
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
>
>   Selecting previously unselected package spin.
>   Preparing to unpack .../spin_6.4.5-1_amd64.deb ...
>   Unpacking spin (6.4.5-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/spin_6.4.5-1_amd64.deb (--unpack):
>trying to overwrite '/usr/bin/spin', which is also in package staden
> 2.0.0+b10-5
>   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
>   Errors were encountered while processing:
>/var/cache/apt/archives/spin_6.4.5-1_amd64.deb
>
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
>
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
>   usr/bin/spin
>   usr/share/man/man1/spin.1.gz
>
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
>
> Cheers,
>
> Andreas
>
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Cheers for the review Mattia! I'll look into all of this. A few comments:

On Sun, May 15, 2016 at 9:19 AM, Mattia Rizzolo  wrote:

> ...
> * d/patches/01_makefile_fixes.patch:
>   + Probably use += instead of ?= in the first CFLAGS?
>   + I'd rather use install(1) instead of cp(1)
>   + Really forward at least the DESTDIR/INSTALL change
>

Yes, thanks for reminding me -- do intend to follow up with upstream. I'm
curious if this makefile was perhaps written for some crusty old version of
make that doesn't do well with the "optional assignment" syntax used for
DESTDIR/INSTALL. I had similar questions about the use of cp vs. install.
I'll see if upstream has any strong attachment to any of this.


> * d/patches/02_manpage_fixes.patch:
>   + what's blocking you from forwarding this patch?
>

Nothing at all, it just hasn't been done yet.


> * d/rules:
>   + get rid of all those useless comments
>   + DPKG_EXPORT_BUILDFLAGS and the inclusion of buildflags.mk is
> useless, please read debhelper(7)
>   + trailing whitespace at line 22
>   + what's wrong with using --sourcedirectory on the dh(1) call instead
> of overriding everything like that?
>

Oh much better idea, didn't know I could do that.


>   + I'd avoid that "INSTALL=install -D" by patching correctly the
> makefile to default INSTALL on install(1) instead of cp(1) (as I
> said above)
>

Sure.

Thanks again!

Bug#809065:

[Tom Lee]

Thanks Artur! I'll land this when I get a few moments spare.

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Still looking for a sponsor for the spin verification tool. I added a
spin-dbg binary package to the mix earlier today:

http://mentors.debian.net/package/spin

Builds fine in pbuilder, is lint clean, etc. Appreciate reviews too!

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Great, got it -- thanks Paul. Uploading to mentors again now.

On Wed, Mar 30, 2016 at 11:59 PM, Paul Wise <p...@debian.org> wrote:

> On Thu, Mar 31, 2016 at 2:47 PM, Tom Lee wrote:
>
> > N.B. no watchfile is present due to the naming strategy of the upstream
> tarball:
> > uscan interprets the version number as "645" when the release is
> actually "6.4.5".
> > if there's a way to teach uscan how to figure this out, I'm all ears!
>
> I think you want the uversionmangle option.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the "spin" package:

* Package name: spin
  Version : 6.4.5
  Upstream Author : Gerard J. Holzmann 
* URL : http://spinroot.com
* License : BSD-3-clause
  Section : devel

It builds those binary packages:

   spin - formal software verification tool

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/spin

N.B. no watchfile is present due to the naming strategy of the upstream tarball:
uscan interprets the version number as "645" when the release is actually 
"6.4.5".
if there's a way to teach uscan how to figure this out, I'm all ears!

One can also download the package with dget using this command:

 dget -x http://mentors.debian.net/debian/pool/main/s/spin/spin_6.4.5-1.dsc

More information about spin can be obtained from http://spinroot.com

Cheers,
Tom

Bug#814306: ITP: spin -- a software verification tool

[Tom Lee]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

I'm working on Debian packages for Gerard J. Holzmann's Spin software
verification tool, which has recently become available under the BSD
3-Clause license. Holzmann's original paper "The Model Checker: SPIN" has
been cited over a thousand times in academia according to ACM. Spin has
also seen success in a number of commercial and government projects,
including NASA's investigation of alleged unintended acceleration in the
Toyota Camry MY05's control software.

Packaging WIP is available here: https://github.com/thomaslee/spin-debian

Initial indications are the packaging will be relatively simple with some
minimal patches.

Further reading:

http://spinroot.com
https://en.wikipedia.org/wiki/SPIN_model_checker
https://en.wikipedia.org/wiki/Promela
http://spinroot.com/spin/success.html



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#792404: hiredis: FTBFS on kfreebsd-*: test failures

[Tom Lee]

Okay, if anybody has the time to try them out:

A patch for the original kfreebsd FTBFS:
https://raw.githubusercontent.com/thomaslee/hiredis-debian/master/debian/patches/08_kfreebsd_ftbfs.patch

And a work-around for the race I observed in the "invalid timeout" tests:
https://raw.githubusercontent.com/thomaslee/hiredis-debian/master/debian/patches/09_fix_test_race.patch

Both have been forwarded upstream but have not yet been applied. If there
are no pressing issues with these patches I'll request a new upload once
upstream has had a chance to look things over.


On Tue, Nov 17, 2015 at 3:40 AM, Tom Lee <deb...@tomlee.co> wrote:

> This was a much deeper rabbit hole than I expected, but I think I've
> worked it out. Most of the notes below are for my own benefit, but happy to
> elaborate if folks have any questions about the details. TL;DR is fmacros.h
> fails to detect kfreebsd as some sort of modern *nix & falls back to some
> old, weird implementation of strerror_r.
>
> To confirm my initial suspicion that this was just a platform-specific
> issue wrt error messages, I passed EAGAIN to strerror_r in a trivial
> program on kfreebsd-amd64 and got the "Resource unavailable" message that
> the hiredis tests expected first try. Given this result, I couldn't
> understand why we were getting empty error strings in the hiredis tests but
> not in my little isolated test. Back to the drawing board.
>
> The failures have to do with the semantics of GNU vs. XSI-compatible
> implementations of strerror_r described here:
> http://man7.org/linux/man-pages/man3/strerror.3.html
>
> When running tests, hiredis behaves as though the implementation in use is
> the GNU version, sometimes not filling the buffer provided to strerror_r
> with the appropriate error message -- this explains why we get blank error
> messages, since hiredis believes us to be using the XSI-compatible version
> & the __redis_strerror_r macro doesn't do any of the requisite footwork to
> handle the odd behavior of GNU's strerror_r.
>
> If we modify __redisSetError to call strerror_r directly (instead of
> indirectly via __redis_strerror_r) then try to capture the output of
> strerror_r in a char *, we wind up with invalid pointers on amd64 since the
> XSI API returns a 32-bit int value.
>
> If we force -D_GNU_SOURCE, we get build errors due to some bad macros in
> hiredis' GNU implementation of __redis_strerror_r. These are easily fixed.
> Once fixed, everything works perfectly -- though the GNU semantics are kind
> of stupid. I modified the build to force -D_XOPEN_SOURCE=600 & removed
> -D_GNU_SOURCE. Suddenly everything was using XSI-compatible semantics.
>
> But why didn't I need to do this sort of thing in my trivial test of
> strerror_r to get the expected behavior? Believe the strange behavior is
> because hiredis fmacros.h #defines _XOPEN_SOURCE with no value/version
> since it can't detect kfreebsd as "some modern *nix". With this
> "versionless" define and nothing else, we get the weird
> GNU-impl-with-XSI-API behavior that causes our tests to fail. We can force
> the right behavior by avoiding the fall-through branch in fmacros.h on
> kfbsd ... just need to think a little on how best to do it: have the
> preprocessor detect kfreebsd, or remove the fall-through branch all
> together to fall back to system defaults.
>
> On top of all this, it also looks like the "Set error when an invalid
> timeout {,u}sec value is given to redisConnectWithTimeout" tests appear to
> be failing due to a race: the test seems to assume that the connect() call
> will fail, but it's succeeding immediately. As a result the code to do the
> validation of tv_usec/tv_sec never gets executed.
>
> I'll try to get a few patches together for all this later in the week.
>
>
> On Mon, Nov 16, 2015 at 11:27 PM, Tom Lee <deb...@tomlee.co> wrote:
>
>> Alrighty, despite my fdisk woes a bit of "printf debugging" has revealed
>> the test failure is simply that c->errstr doesn't contain the message the
>> test expects (instead errstr is an empty string). Easy enough to work
>> around: I'll put a patch together in a few minutes & drop it on here for
>> folks to verify.
>>
>> I'd still be interested to know how I can resize partitions on kfreebsd
>> for future reference :)
>>
>> On Mon, Nov 16, 2015 at 11:20 PM, Tom Lee <deb...@tomlee.co> wrote:
>>
>>> Thanks Steven, that was really helpful. Got Cristoph's image up &
>>> running in VirtualBox with a little playing around and I've been able to
>>> reproduce the issue. However, I've hit something of a newbie problem:
>>> there's insufficient space on the disk imag

Bug#792404: hiredis: FTBFS on kfreebsd-*: test failures

[Tom Lee]

This was a much deeper rabbit hole than I expected, but I think I've worked
it out. Most of the notes below are for my own benefit, but happy to
elaborate if folks have any questions about the details. TL;DR is fmacros.h
fails to detect kfreebsd as some sort of modern *nix & falls back to some
old, weird implementation of strerror_r.

To confirm my initial suspicion that this was just a platform-specific
issue wrt error messages, I passed EAGAIN to strerror_r in a trivial
program on kfreebsd-amd64 and got the "Resource unavailable" message that
the hiredis tests expected first try. Given this result, I couldn't
understand why we were getting empty error strings in the hiredis tests but
not in my little isolated test. Back to the drawing board.

The failures have to do with the semantics of GNU vs. XSI-compatible
implementations of strerror_r described here:
http://man7.org/linux/man-pages/man3/strerror.3.html

When running tests, hiredis behaves as though the implementation in use is
the GNU version, sometimes not filling the buffer provided to strerror_r
with the appropriate error message -- this explains why we get blank error
messages, since hiredis believes us to be using the XSI-compatible version
& the __redis_strerror_r macro doesn't do any of the requisite footwork to
handle the odd behavior of GNU's strerror_r.

If we modify __redisSetError to call strerror_r directly (instead of
indirectly via __redis_strerror_r) then try to capture the output of
strerror_r in a char *, we wind up with invalid pointers on amd64 since the
XSI API returns a 32-bit int value.

If we force -D_GNU_SOURCE, we get build errors due to some bad macros in
hiredis' GNU implementation of __redis_strerror_r. These are easily fixed.
Once fixed, everything works perfectly -- though the GNU semantics are kind
of stupid. I modified the build to force -D_XOPEN_SOURCE=600 & removed
-D_GNU_SOURCE. Suddenly everything was using XSI-compatible semantics.

But why didn't I need to do this sort of thing in my trivial test of
strerror_r to get the expected behavior? Believe the strange behavior is
because hiredis fmacros.h #defines _XOPEN_SOURCE with no value/version
since it can't detect kfreebsd as "some modern *nix". With this
"versionless" define and nothing else, we get the weird
GNU-impl-with-XSI-API behavior that causes our tests to fail. We can force
the right behavior by avoiding the fall-through branch in fmacros.h on
kfbsd ... just need to think a little on how best to do it: have the
preprocessor detect kfreebsd, or remove the fall-through branch all
together to fall back to system defaults.

On top of all this, it also looks like the "Set error when an invalid
timeout {,u}sec value is given to redisConnectWithTimeout" tests appear to
be failing due to a race: the test seems to assume that the connect() call
will fail, but it's succeeding immediately. As a result the code to do the
validation of tv_usec/tv_sec never gets executed.

I'll try to get a few patches together for all this later in the week.


On Mon, Nov 16, 2015 at 11:27 PM, Tom Lee <deb...@tomlee.co> wrote:

> Alrighty, despite my fdisk woes a bit of "printf debugging" has revealed
> the test failure is simply that c->errstr doesn't contain the message the
> test expects (instead errstr is an empty string). Easy enough to work
> around: I'll put a patch together in a few minutes & drop it on here for
> folks to verify.
>
> I'd still be interested to know how I can resize partitions on kfreebsd
> for future reference :)
>
> On Mon, Nov 16, 2015 at 11:20 PM, Tom Lee <deb...@tomlee.co> wrote:
>
>> Thanks Steven, that was really helpful. Got Cristoph's image up & running
>> in VirtualBox with a little playing around and I've been able to reproduce
>> the issue. However, I've hit something of a newbie problem: there's
>> insufficient space on the disk image to install gdb & actually take a
>> closer look at what's going on. I've increased the size of the image itself
>> but fdisk doesn't seem to play nice (I get "fdisk: cannot open /dev/ada0:
>> Operation not permitted").
>>
>> Is there some other tool I should be using to resize partitions under
>> kfreebsd?
>>
>> On Sun, Nov 8, 2015 at 1:22 AM, Steven Chamberlain <ste...@pyro.eu.org>
>> wrote:
>>
>>> Hello,
>>>
>>> Tom Lee wrote:
>>> > I've had some trouble getting kfreebsd up and running in a VM
>>>
>>> Christoph has created a prebuilt VM image of jessie-kfreebsd, if that
>>> helps you:
>>> https://people.debian.org/~christoph/jessie-kfreebsd-vmimage.raw.xz
>>>
>>> Otherwise I will likely get around to looking at this bug myself.
>>>
>>> Regards,
>>> --
>>> Steven Chamberlain
>>> ste...@pyro.eu.org
>>>
>>
>>
>>
>> --
>> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>>
>>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#792404: hiredis: FTBFS on kfreebsd-*: test failures

[Tom Lee]

Alrighty, despite my fdisk woes a bit of "printf debugging" has revealed
the test failure is simply that c->errstr doesn't contain the message the
test expects (instead errstr is an empty string). Easy enough to work
around: I'll put a patch together in a few minutes & drop it on here for
folks to verify.

I'd still be interested to know how I can resize partitions on kfreebsd for
future reference :)

On Mon, Nov 16, 2015 at 11:20 PM, Tom Lee <deb...@tomlee.co> wrote:

> Thanks Steven, that was really helpful. Got Cristoph's image up & running
> in VirtualBox with a little playing around and I've been able to reproduce
> the issue. However, I've hit something of a newbie problem: there's
> insufficient space on the disk image to install gdb & actually take a
> closer look at what's going on. I've increased the size of the image itself
> but fdisk doesn't seem to play nice (I get "fdisk: cannot open /dev/ada0:
> Operation not permitted").
>
> Is there some other tool I should be using to resize partitions under
> kfreebsd?
>
> On Sun, Nov 8, 2015 at 1:22 AM, Steven Chamberlain <ste...@pyro.eu.org>
> wrote:
>
>> Hello,
>>
>> Tom Lee wrote:
>> > I've had some trouble getting kfreebsd up and running in a VM
>>
>> Christoph has created a prebuilt VM image of jessie-kfreebsd, if that
>> helps you:
>> https://people.debian.org/~christoph/jessie-kfreebsd-vmimage.raw.xz
>>
>> Otherwise I will likely get around to looking at this bug myself.
>>
>> Regards,
>> --
>> Steven Chamberlain
>> ste...@pyro.eu.org
>>
>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#792404: hiredis: FTBFS on kfreebsd-*: test failures

[Tom Lee]

Thanks Steven, that was really helpful. Got Cristoph's image up & running
in VirtualBox with a little playing around and I've been able to reproduce
the issue. However, I've hit something of a newbie problem: there's
insufficient space on the disk image to install gdb & actually take a
closer look at what's going on. I've increased the size of the image itself
but fdisk doesn't seem to play nice (I get "fdisk: cannot open /dev/ada0:
Operation not permitted").

Is there some other tool I should be using to resize partitions under
kfreebsd?

On Sun, Nov 8, 2015 at 1:22 AM, Steven Chamberlain <ste...@pyro.eu.org>
wrote:

> Hello,
>
> Tom Lee wrote:
> > I've had some trouble getting kfreebsd up and running in a VM
>
> Christoph has created a prebuilt VM image of jessie-kfreebsd, if that
> helps you:
> https://people.debian.org/~christoph/jessie-kfreebsd-vmimage.raw.xz
>
> Otherwise I will likely get around to looking at this bug myself.
>
> Regards,
> --
> Steven Chamberlain
> ste...@pyro.eu.org
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#792404: hiredis: FTBFS on kfreebsd-*: test failures

[Tom Lee]

Thanks again for the report and untangling the mess between hiredis +
webdis, and sorry I've been so slow to follow up on this. I've had some
trouble getting kfreebsd up and running in a VM to dig deeper into why this
is messed up (unfortunately the way the tests are written, it's hard to
know what exactly is failing here: suspect this may just be a mismatch in
the specific error message being checked in the test).

A fix likely won't make the next release, but I'll keep trying & keep you
posted. If all else fails I'll jump on a porterbox.


On Tue, Jul 14, 2015 at 7:17 AM, Cyril Brulebois <k...@debian.org> wrote:

> Source: hiredis
> Version: 0.13.1-1
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: kfreebsd
>
> (debian-...@lists.debian.org in copy, please follow up with them if you
> need help.)
>
> Hi,
>
> Your package no longer builds on kfreebsd-* due to two failing tests
> (same on both archs):
> | #44 Does not return a reply when the command times out: FAILED
> …
> | #63 Does not return a reply when the command times out: FAILED
>
> I've scheduled binNMUs accordingly (excluding kfreebsd-*), see #785349.
>
> By the way, it would be nice to avoid using escape sequences when
> logging to a file is detected (instead of a terimnal).
>
> Full build logs:
>   https://buildd.debian.org/status/package.php?p=hiredis=sid
>
> https://buildd.debian.org/status/fetch.php?pkg=hiredis=kfreebsd-amd64=0.13.1-2=1434139411
>
> https://buildd.debian.org/status/fetch.php?pkg=hiredis=kfreebsd-i386=0.13.1-2=1434138443
>
> Mraw,
> KiBi.
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#784768: libhiredis-dev: Transition to cmake 3.2

[Tom Lee]

Tags: +confirmed +pending

A fix for this is forthcoming.

Bug#804122: FTBFS on hurd-i386 due to test breakages

[Tom Lee]

Package: capnproto
Version: 0.5.3-1

A few tests breaking due to EMIG_REPLY_MISMATCH:

[ RUN  ] AsyncUnixTest.SignalsNoWait
unknown file: Failure
C++ exception with description "src/kj/async-unix.c++:667: failed:
poll(): (ipc/mig) wrong reply message ID" thrown in the test body.
[  FAILED  ] AsyncUnixTest.SignalsNoWait (10 ms)

[ RUN  ] AsyncUnixTest.Wake
unknown file: Failure
C++ exception with description "src/kj/async-unix.c++:667: failed:
poll(): (ipc/mig) wrong reply message ID" thrown in the test body.
[  FAILED  ] AsyncUnixTest.Wake (0 ms)


Other tests busted due to unsupported socket options:

[--] 6 tests from SerializeAsyncTest
[ RUN  ] SerializeAsyncTest.ParseAsync
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, , sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.ParseAsync (0 ms)
[ RUN  ] SerializeAsyncTest.ParseAsyncOddSegmentCount
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, , sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.ParseAsyncOddSegmentCount (0 ms)
[ RUN  ] SerializeAsyncTest.ParseAsyncEvenSegmentCount
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, , sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.ParseAsyncEvenSegmentCount (0 ms)
[ RUN  ] SerializeAsyncTest.WriteAsync
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, , sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.WriteAsync (0 ms)
[ RUN  ] SerializeAsyncTest.WriteAsyncOddSegmentCount
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, , sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.WriteAsyncOddSegmentCount (0 ms)
[ RUN  ] SerializeAsyncTest.WriteAsyncEvenSegmentCount
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, , sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.WriteAsyncEvenSegmentCount (0 ms)

Haven't seen these errors manifest on other archs yet, though still waiting
on buildd for some.

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#804112: FTBS due to test failure in AsyncUnixTest.SignalWith{,Pointer}Value on some archs

[Tom Lee]

Package: capnproto
Version: 0.5.3-1

mips, powerpc, hppa appear to be affected, possibly others -- still waiting
on buildds after the most recent upload. Suspect it's related to
https://lkml.org/lkml/2015/2/10/159 but yet to confirm.

-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#781787: capnproto: FTBFS on hppa: nan tests fail

[Tom Lee]

A release fixing this issue is on its way out to unstable:
https://ftp-master.debian.org/new/capnproto_0.5.3-1.html

Thanks again for the patch!

On Thu, Apr 2, 2015 at 7:25 PM, John David Anglin <dave.ang...@bell.net>
wrote:

> Package: capnproto
> Version: 0.4.1-3
> Severity: normal
> Tags: patch
>
> The hppa and mips architecture have the same nan format (i.e.,
> quiet and signalling nans are different from x86, etc).  With the
> attached change, capnproto builds successfully on hppa.  See:
>
> http://buildd.debian-ports.org/status/fetch.php?pkg=capnproto=hppa=0.4.1-3=1428027386
>
> The current mips patch could be modified to add hppa.
>
> -- System Information:
> Debian Release: 8.0
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: hppa (parisc64)
>
> Kernel: Linux 3.17.8+ (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to
> en_CA.utf8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#790571: please give-back capnproto on mipsel

[Tom Lee]

Thanks for all your help with this folks -- a release with this fix is
(finally) on its way out to unstable:

https://ftp-master.debian.org/new/capnproto_0.5.3-1.html

On Wed, Aug 12, 2015 at 11:29 AM, Arturo Borrero Gonzalez <
arturo.borrero.g...@gmail.com> wrote:

> On 7 August 2015 at 18:11, Dejan Latinovic <dejan.latino...@imgtec.com>
> wrote:
> >
> >
> >
> > Hi,
> >
> > I was not able to reproduce internal compiler error.
> >
> > Both patches (Tom's, and upstream) build fine for me.
> >
> > And seems to solves mentioned tests.
> >
>
> Yes, that's true.
>
> I updated my pbuilder environment and the ICE is gone and the package
> is built just fine.
>
> --
> Arturo Borrero González
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#790571: please give-back capnproto on mipsel

[Tom Lee]

Control: tags +confirmed

Dejan, Arturo, thanks for looking into this. Sorry I've been so slow
to get back to you.

Arturo, I understand you've followed up with upstream regarding the
affected tests  Kenton's helping you out with some experimental
patches to disable the failing tests. I'd be interested to know how
that works out, but I do worry that by disabling the tests we'll be
potentially glossing over a real issue.

Dejan, I think you might be onto something with that 4k buffer but let
me look into it a little. Are you aware of any porterboxes with
similar setups to mips-aql-02 + mipsel-manda-0{1,2}?
https://db.debian.org/machines.cgi?host=eder (Loongson 2E) looks like
it might be a promising candidate from a quick google around.

I'm guessing this is likely what's causing builds to fail on several
other archs too.

Cheers,
Tom

On Fri, Jul 17, 2015 at 8:20 AM, Dejan Latinovic
dejan.latino...@imgtec.com wrote:

 Hi,
 I have tested capnproto on a few local machines.
 Initially, build failed on all boards.
 On different MIPS boards, different tests were failing.


 AsyncUnixTest.WriteObserver fails if the kernel PAGESIZE is larger that 4k.

 After I reduced PAGESIZE to 4096 on CI20, all tests passed.

 The solution could be to increase buffer size:
 char buffer[4096]
 (src/kj/async-unix-test.c++ +416)
 I had increased it to 16384 and tried it on Loongson 3A
 (PAGESIZE is 16k, same board as mipsel-manda-01, mipsel-manda-02),
 all test passed.
 We should keep on mind that pagesize on some MIPS board is up to 64k.
 This solution should be discussed upstream.


 On EdgeRouter Pro (mips-aql-02),
 these two test failed:
 [  FAILED  ] 2 tests, listed below:
 [  FAILED  ] AsyncUnixTest.SignalWithValue
 [  FAILED  ] AsyncUnixTest.SignalWithPointerValue

 I will do further investigating.

 Best Regards,
 Dejan



-- 
Tom Lee / http://tomlee.co / @tglee


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

Bug#790571: please give-back capnproto on mipsel

[Tom Lee]

Control: tags -1 +confirmed

(Resending this because I messed up the control flags earlier --
apologies for the spam)

Dejan, Arturo, thanks for looking into this. Sorry I've been so slow
to get back to you.

Arturo, I understand you've followed up with upstream regarding the
affected tests  Kenton's helping you out with some experimental
patches to disable the failing tests. I'd be interested to know how
that works out, but I do worry that by disabling the tests we'll be
potentially glossing over a real issue.

Dejan, I think you might be onto something with that 4k buffer but let
me look into it a little. Are you aware of any porterboxes with
similar setups to mips-aql-02 + mipsel-manda-0{1,2}?
https://db.debian.org/machines.cgi?host=eder (Loongson 2E) looks like
it might be a promising candidate from a quick google around.

I'm guessing this is likely what's causing builds to fail on several
other archs too.

Cheers,
Tom

On Fri, Jul 17, 2015 at 8:20 AM, Dejan Latinovic
dejan.latino...@imgtec.com wrote:

 Hi,
 I have tested capnproto on a few local machines.
 Initially, build failed on all boards.
 On different MIPS boards, different tests were failing.


 AsyncUnixTest.WriteObserver fails if the kernel PAGESIZE is larger that 4k.

 After I reduced PAGESIZE to 4096 on CI20, all tests passed.

 The solution could be to increase buffer size:
 char buffer[4096]
 (src/kj/async-unix-test.c++ +416)
 I had increased it to 16384 and tried it on Loongson 3A
 (PAGESIZE is 16k, same board as mipsel-manda-01, mipsel-manda-02),
 all test passed.
 We should keep on mind that pagesize on some MIPS board is up to 64k.
 This solution should be discussed upstream.


 On EdgeRouter Pro (mips-aql-02),
 these two test failed:
 [  FAILED  ] 2 tests, listed below:
 [  FAILED  ] AsyncUnixTest.SignalWithValue
 [  FAILED  ] AsyncUnixTest.SignalWithPointerValue

 I will do further investigating.

 Best Regards,
 Dejan



-- 
Tom Lee / http://tomlee.co / @tglee


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

Bug#790571: please give-back capnproto on mipsel

[Tom Lee]

Just noticed that the description in the patch itself misleading --
please disregard that. My earlier email represents my best
understanding of the issue.

On Sat, Aug 1, 2015 at 1:28 PM, Tom Lee deb...@tomlee.co wrote:
 Control: tags -1 +patch

 Alrighty, potential patch is attached. Can you folks try it out  let
 me know if it works? If all looks good I'll prep a new upload  send
 the patch upstream.

 Dejan, you were right on the money with the page size thing. Looks
 like the write operation in async-unix-test.c++ writes data to the
 pipe until the underlying buffer is completely filled. At that point,
 the write operation fails  the test continues until we hit the read
 operation. At that point we try to read 4096 bytes. It seems like if
 PIPE_BUF  4096 (where PIPE_BUF is typically the size of a page), the
 pipe doesn't become writable  so the test fails.

 I find this behavior a little surprising, but I can reproduce it
 myself on x86_64 by simply changing the buffer size to something less
 than PIPE_BUF. Interesting stuff.

 With this patch applied I wouldn't be surprised if we saw the write
 notification fire multiple times (once per PIPE_BUF bytes read). Even
 if that is happening, I feel like we're testing the intended behavior.

 Cheers,
 Tom


 On Sat, Aug 1, 2015 at 9:04 AM, Tom Lee deb...@tomlee.co wrote:
 Control: tags +confirmed

 Dejan, Arturo, thanks for looking into this. Sorry I've been so slow
 to get back to you.

 Arturo, I understand you've followed up with upstream regarding the
 affected tests  Kenton's helping you out with some experimental
 patches to disable the failing tests. I'd be interested to know how
 that works out, but I do worry that by disabling the tests we'll be
 potentially glossing over a real issue.

 Dejan, I think you might be onto something with that 4k buffer but let
 me look into it a little. Are you aware of any porterboxes with
 similar setups to mips-aql-02 + mipsel-manda-0{1,2}?
 https://db.debian.org/machines.cgi?host=eder (Loongson 2E) looks like
 it might be a promising candidate from a quick google around.

 I'm guessing this is likely what's causing builds to fail on several
 other archs too.

 Cheers,
 Tom

 On Fri, Jul 17, 2015 at 8:20 AM, Dejan Latinovic
 dejan.latino...@imgtec.com wrote:

 Hi,
 I have tested capnproto on a few local machines.
 Initially, build failed on all boards.
 On different MIPS boards, different tests were failing.


 AsyncUnixTest.WriteObserver fails if the kernel PAGESIZE is larger that 4k.

 After I reduced PAGESIZE to 4096 on CI20, all tests passed.

 The solution could be to increase buffer size:
 char buffer[4096]
 (src/kj/async-unix-test.c++ +416)
 I had increased it to 16384 and tried it on Loongson 3A
 (PAGESIZE is 16k, same board as mipsel-manda-01, mipsel-manda-02),
 all test passed.
 We should keep on mind that pagesize on some MIPS board is up to 64k.
 This solution should be discussed upstream.


 On EdgeRouter Pro (mips-aql-02),
 these two test failed:
 [  FAILED  ] 2 tests, listed below:
 [  FAILED  ] AsyncUnixTest.SignalWithValue
 [  FAILED  ] AsyncUnixTest.SignalWithPointerValue

 I will do further investigating.

 Best Regards,
 Dejan



 --
 Tom Lee / http://tomlee.co / @tglee



 --
 Tom Lee / http://tomlee.co / @tglee



-- 
Tom Lee / http://tomlee.co / @tglee


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

Bug#790571: please give-back capnproto on mipsel

[Tom Lee]

Control: tags -1 +patch

Alrighty, potential patch is attached. Can you folks try it out  let
me know if it works? If all looks good I'll prep a new upload  send
the patch upstream.

Dejan, you were right on the money with the page size thing. Looks
like the write operation in async-unix-test.c++ writes data to the
pipe until the underlying buffer is completely filled. At that point,
the write operation fails  the test continues until we hit the read
operation. At that point we try to read 4096 bytes. It seems like if
PIPE_BUF  4096 (where PIPE_BUF is typically the size of a page), the
pipe doesn't become writable  so the test fails.

I find this behavior a little surprising, but I can reproduce it
myself on x86_64 by simply changing the buffer size to something less
than PIPE_BUF. Interesting stuff.

With this patch applied I wouldn't be surprised if we saw the write
notification fire multiple times (once per PIPE_BUF bytes read). Even
if that is happening, I feel like we're testing the intended behavior.

Cheers,
Tom


On Sat, Aug 1, 2015 at 9:04 AM, Tom Lee deb...@tomlee.co wrote:
 Control: tags +confirmed

 Dejan, Arturo, thanks for looking into this. Sorry I've been so slow
 to get back to you.

 Arturo, I understand you've followed up with upstream regarding the
 affected tests  Kenton's helping you out with some experimental
 patches to disable the failing tests. I'd be interested to know how
 that works out, but I do worry that by disabling the tests we'll be
 potentially glossing over a real issue.

 Dejan, I think you might be onto something with that 4k buffer but let
 me look into it a little. Are you aware of any porterboxes with
 similar setups to mips-aql-02 + mipsel-manda-0{1,2}?
 https://db.debian.org/machines.cgi?host=eder (Loongson 2E) looks like
 it might be a promising candidate from a quick google around.

 I'm guessing this is likely what's causing builds to fail on several
 other archs too.

 Cheers,
 Tom

 On Fri, Jul 17, 2015 at 8:20 AM, Dejan Latinovic
 dejan.latino...@imgtec.com wrote:

 Hi,
 I have tested capnproto on a few local machines.
 Initially, build failed on all boards.
 On different MIPS boards, different tests were failing.


 AsyncUnixTest.WriteObserver fails if the kernel PAGESIZE is larger that 4k.

 After I reduced PAGESIZE to 4096 on CI20, all tests passed.

 The solution could be to increase buffer size:
 char buffer[4096]
 (src/kj/async-unix-test.c++ +416)
 I had increased it to 16384 and tried it on Loongson 3A
 (PAGESIZE is 16k, same board as mipsel-manda-01, mipsel-manda-02),
 all test passed.
 We should keep on mind that pagesize on some MIPS board is up to 64k.
 This solution should be discussed upstream.


 On EdgeRouter Pro (mips-aql-02),
 these two test failed:
 [  FAILED  ] 2 tests, listed below:
 [  FAILED  ] AsyncUnixTest.SignalWithValue
 [  FAILED  ] AsyncUnixTest.SignalWithPointerValue

 I will do further investigating.

 Best Regards,
 Dejan



 --
 Tom Lee / http://tomlee.co / @tglee



-- 
Tom Lee / http://tomlee.co / @tglee
Description: Read PIPE_BUF bytes from pipes in tests.
  When we write() = PIPE_BUF bytes to an anonymous pipe on Linux,
  PIPE_BUF bytes appear to be received by the other side of the
  pipe (irrespective of the length passed to write()).

  This would cause the read() in async-unix-test to succeed with
  EAGAIN when PIPE_BUF = 4096 because the pipe would not enter the
  writable state until all PIPE_BUF bytes have been read.

  Affects certain flavors of mips{,el} and ppc{,64el} as far as I
  can tell.
Author: Tom Lee deb...@tomlee.co
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790571
Last-Update: 2015-08-01
--- a/src/kj/async-unix-test.c++
+++ b/src/kj/async-unix-test.c++
@@ -394,15 +394,20 @@
   KJ_SYSCALL(pipe(pipefds));
   kj::AutoCloseFd infd(pipefds[0]), outfd(pipefds[1]);
   setNonblocking(outfd);
+  setNonblocking(infd);
 
   UnixEventPort::FdObserver observer(port, outfd, UnixEventPort::FdObserver::OBSERVE_WRITE);
 
-  // Fill buffer.
+  // Fill the pipe buffer.
   ssize_t n;
   do {
 KJ_NONBLOCKING_SYSCALL(n = write(outfd, foo, 3));
   } while (n = 0);
 
+  // Make sure we haven't hit some unexpected failure.
+  EXPECT_EQ(n, -1);
+  EXPECT_EQ(errno, EAGAIN);
+
   bool writable = false;
   auto promise = observer.whenBecomesWritable()
   .then([]() { writable = true; }).eagerlyEvaluate(nullptr);
@@ -414,7 +419,13 @@
   EXPECT_FALSE(writable);
 
   char buffer[4096];
-  KJ_SYSCALL(read(infd, buffer, sizeof(buffer)));
+  do {
+  KJ_NONBLOCKING_SYSCALL(n = read(infd, buffer, sizeof(buffer)));
+  } while (n = 0);
+
+  // Make sure we've fully drained the buffer.
+  EXPECT_EQ(n, -1);
+  EXPECT_EQ(errno, EAGAIN);
 
   loop.run();
   port.poll();

Bug#790571: capnproto: ICE with upstream patch for the mipsel FTBFS

[Tom Lee]

Hey Arturo,

Thanks for the report -- can I get more information? Specifically:

* What steps did you take to reproduce this?
* I assumed this was against sid, but the build log pasted on the
tracker hinted at version 4.9 of g++ ... looks like sid mipsel is on
g++ 5.2: https://packages.debian.org/sid/g++ -- are you building
against testing? jessie? or is it just an out-of-date sid?

Cheers,
Tom

On Sat, Aug 1, 2015 at 3:42 PM, Arturo Borrero Gonzalez
arturo.borrero.g...@gmail.com wrote:
 Hi there,

 bad news, I hit an ICE (internal compiler error) with the upstream patch.
 For more details, see the github issue comment [0].

 regards.

 [0] 
 https://github.com/sandstorm-io/capnproto/issues/204#issuecomment-126958876

 --
 Arturo Borrero González



-- 
Tom Lee / http://tomlee.co / @tglee


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

Bug#777810: GCC 5 build issue

[Tom Lee]

Will do Martin -- thank you!
On Jun 25, 2015 9:55 AM, Martin Michlmayr t...@hp.com wrote:

 * Tom Lee m...@tomlee.co [2015-05-03 02:34]:
  Not sure if you're actively attempting test rebuilds every so often, but
  feel free to try for yourself when 0.5.2-1 hits unstable.

 I can confirm that the package in unstable builds fine with GCC 5.
 Tom, as the maintainer, I suggest you close this bug.

 --
 Martin Michlmayr
 Linux for HP Helion OpenStack, Hewlett-Packard

Bug#789654: libjemalloc1: Mysterious memory corruption issues on powerpc

[Tom Lee]

Package: libjemalloc1
Version: 3.6.0-3
Severity: important

Dear Maintainer,

Running the hiredis tests on powerpc causes redis-server to crash due to
what appears to be strange memory corruption issues. Upon further
investigation on the partch.debian.org porterbox, I've managed to
convince myself that the issue lies somewhere in the Debian jemalloc
package.

Additional (hopefully useful) info is available in my comment against
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788591

Key information from #788591:

If I link redis-server against the jemalloc-3.6.0-3 binary found in
unstable  run against that, I can trivially reproduce the redis-server
crashes by simply running make check in the hiredis package.

If I rebuild jemalloc-3.6.0-3 from source then run redis-server against
the resulting binaries, the mysterious crashes/memory corruption issues
go away.

Any thoughts? Only thing that occurs to me is perhaps some kind of
compiler bug: I notice that jemalloc-3.6.0-3 was built with gcc 4.9.1-5
while my porterbox schroot would have built the package using gcc
4.9.2-21.

Happy to offer any additional info I can to confirm/reject my hypothesis
while I still have access to the porterbox, just let me know what you
need.

Cheers,
Tom


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

Bug#788591: hiredis: FTBFS on powerpc

[Tom Lee]

*)replies[i]) == 0' failed.

 See 
 https://buildd.debian.org/status/fetch.php?pkg=hiredisarch=powerpcver=0.13.1-2stamp=1434137918
 for a full log.

 Emilio



-- 
Tom Lee / http://tomlee.co / @tglee


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

Bug#785476: segfault when building against libhiredis0.13 due to vendored header files

[Tom Lee]

Package: webdis
Version: 0.1.1-2
Severity: serious

Hello, I'm trying to transition the hiredis package from libhiredis0.10 to
libhiredis0.13, but some issues with the packaging (specifically the
vendored sources) of webdis are causing me some problems. Specifically, the
vendored hiredis and jansson headers are used instead of the headers from
libhiredis-dev and libjansson-dev.

The most noisy symptom is a segfault when building webdis against
libhiredis0.13, which gdb shows is pool_connect trying to call strlen(...)
on a null pointer:

(gdb) set follow-fork-mode child
(gdb) run /tmp/tmp.swHGJysNL5/webdis.json
Starting program: /home/tom/Source/debian/webdis-0.1.1/webdis
/tmp/tmp.swHGJysNL5/webdis.json
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New process 25152]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x76585700 (LWP 25153)]
[New Thread 0x75d84700 (LWP 25154)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x76585700 (LWP 25153)]
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x0040798f in pool_connect (p=0x623940, db_num=0,
attach=attach@entry=1) at pool.c:134
#2  0x004031a3 in worker_pool_connect (w=0x623b70, w=0x623b70) at
worker.c:133
#3  worker_main (p=0x623b70) at worker.c:153
#4  0x7715a0a4 in start_thread (arg=0x76585700) at
pthread_create.c:309
#5  0x76e8f04d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Stepping through gdb a little more carefully, we can trace the issue down
to the call out to redisAsyncConnectUnix in pool_connect.

Inside redisAsyncConnectUnix (all the way up until the final retq
instruction on amd64) the redisAsyncContext looks something like this:

 p *ac
$4 = {c = {err = 1, errstr = No such file or directory, '\000' repeats
102 times, fd = -1, flags = 0,
obuf = 0x7f68 , reader = 0x7f80, connection_type =
REDIS_CONN_UNIX, timeout = 0x0, tcp = {
  host = 0x0, source_addr = 0x0, port = 0}, unix_sock = {
  path = 0x78c0 /tmp/tmp.ltIFMqN271/redis.sock}}, err = 1,
  errstr = 0x700011e4 No such file or directory, data = 0x0, ev =
{data = 0x0, addRead = 0x0, delRead = 0x0,
addWrite = 0x0, delWrite = 0x0, cleanup = 0x0}, onDisconnect = 0x0,
onConnect = 0x0, replies = {head = 0x0,
tail = 0x0}, sub = {invalid = {head = 0x0, tail = 0x0}, channels =
0x7e80, patterns = 0x7ec0}}

*The moment the retq instruction in this function returns* the struct
layout changes in gdb (e.g. the connection_type field disappears):

 p *ac
$6 = {c = {err = 1, errstr = No such file or directory, '\000' repeats
102 times, fd = -1, flags = 0,
obuf = 0x7f68 , reader = 0x7f80}, err = 1, errstr =
0x0, data = 0x0, ev = {data = 0x0,
addRead = 0x0, delRead = 0x78c0, addWrite = 0x1, delWrite =
0x700011e4, cleanup = 0x0},
  onDisconnect = 0x0, onConnect = 0x0, replies = {head = 0x0, tail = 0x0},
sub = {invalid = {head = 0x0, tail = 0x0},
channels = 0x0, patterns = 0x0}}

So the layout of the redisContext struct used to build libhiredis-dev
0.13.1-1 differs from one used to build webdis. This can be explained by
the vendored headers  can be further verified with strace when building
the package with gbp:

$ strace -e open -f -o ../strace.txt gbp buildpackage
--git-debian-branch=debian --git-upstream-branch=master

Any possibility you could sort that out? If it were up to me I'd use a
patch to blow away the vendored sources, but I'm not sure if that's the
best way to handle this sort of situation. gbp's support for filtering may
also be an option.

libhiredis0.13 and libhiredis-dev 0.13.1-1 have been uploaded to the
experimental distribution if you'd like to reproduce this for yourself.

Cheers,
Tom

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#785349: transition: hiredis

[Tom Lee]

I'm assuming this doesn't change anything with respect to the transition,
but upon further investigation in gdb the segfault actually seems to be a
packaging issue with webdis. Seems like upstream webdis vendors hiredis and
jansson. In the Debian packaging we're correctly trying to use the .so, but
the #include directives are picking up the vendored headers instead of the
headers from libhiredis-dev/libjansson-dev. Thus structs have different
layouts in the .so vs the webdis binary and things get weird.

I'll raise a bug with the webdis maintainer to get this addressed.

Cheers,
Tom


On Sat, May 16, 2015 at 8:56 AM, Jonathan Wiltshire j...@debian.org wrote:

 Control: tag -1 moreinfo

 On 2015-05-16 12:23, Tom Lee wrote:

 Confirmed the webdis segfault is due to an ABI change.


 That'll need sorting out before the transition begins please.

 Thanks,

 --
 Jonathan Wiltshire  j...@debian.org
 Debian Developer http://people.debian.org/~jmw

 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 directhex i have six years of solaris sysadmin experience, from
 8-10. i am well qualified to say it is made from bonghits
 layered on top of bonghits




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#785349: transition: hiredis

[Tom Lee]

Control: block -1 by 785476

Bug raised against webdis:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785476

On Sat, May 16, 2015 at 11:26 AM, Tom Lee deb...@tomlee.co wrote:

 I'm assuming this doesn't change anything with respect to the transition,
 but upon further investigation in gdb the segfault actually seems to be a
 packaging issue with webdis. Seems like upstream webdis vendors hiredis and
 jansson. In the Debian packaging we're correctly trying to use the .so, but
 the #include directives are picking up the vendored headers instead of the
 headers from libhiredis-dev/libjansson-dev. Thus structs have different
 layouts in the .so vs the webdis binary and things get weird.

 I'll raise a bug with the webdis maintainer to get this addressed.

 Cheers,
 Tom


 On Sat, May 16, 2015 at 8:56 AM, Jonathan Wiltshire j...@debian.org
 wrote:

 Control: tag -1 moreinfo

 On 2015-05-16 12:23, Tom Lee wrote:

 Confirmed the webdis segfault is due to an ABI change.


 That'll need sorting out before the transition begins please.

 Thanks,

 --
 Jonathan Wiltshire  j...@debian.org
 Debian Developer http://people.debian.org/~jmw

 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 directhex i have six years of solaris sysadmin experience, from
 8-10. i am well qualified to say it is made from bonghits
 layered on top of bonghits




 --
 *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#785349: transition: hiredis

[Tom Lee]

Confirmed the webdis segfault is due to an ABI change.

On Fri, May 15, 2015 at 10:07 PM, Tom Lee deb...@tomlee.co wrote:



 On Fri, May 15, 2015 at 1:36 AM, Emilio Pozuelo Monfort po...@debian.org
 wrote:

 On 15/05/15 06:10, Tom Lee wrote:
  Package: release.debian.org
  Severity: normal
  User: release.debian@packages.debian.org
  Usertags: transition
 
  Hello, I'd like to request a transition slot from the release team.
 
  The libhiredis SONAME changed in the latest release from upstream,
  indicating ABI-incompatible changes to the library. Updating the binary
  package to reflect the new SONAME. libhiredis0.13 has been uploaded to
  experimental by my sponsor.
 
  I couldn't quite figure out how to get the Ben file reportbug generated
  for me below to give me a list of dependent packages (this is my first
  request for a transition), but I pulled this list from apt-cache
  rdepends if that's at all useful:
 
  zmap
  webdis
  syslog-ng-mod-redis
  ruby-hiredis
  rspamd
  rfc5766-turn-server
  python-hiredis
  ntopng
  kamailio-redis-modules
  libhiredis-dev
  libhiredis-dbg
  coturn

 Have you tested that they build fine against the new version of the
 library?


 All seem to build just fine except for webdis, which segfaults during
 tests. There are no segfaults when building against libhiredis0.10, so
 looks like it's running afoul of something in the latest release.


 --
 *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#785349: transition: hiredis

[Tom Lee]

On Fri, May 15, 2015 at 1:36 AM, Emilio Pozuelo Monfort po...@debian.org
wrote:

 On 15/05/15 06:10, Tom Lee wrote:
  Package: release.debian.org
  Severity: normal
  User: release.debian@packages.debian.org
  Usertags: transition
 
  Hello, I'd like to request a transition slot from the release team.
 
  The libhiredis SONAME changed in the latest release from upstream,
  indicating ABI-incompatible changes to the library. Updating the binary
  package to reflect the new SONAME. libhiredis0.13 has been uploaded to
  experimental by my sponsor.
 
  I couldn't quite figure out how to get the Ben file reportbug generated
  for me below to give me a list of dependent packages (this is my first
  request for a transition), but I pulled this list from apt-cache
  rdepends if that's at all useful:
 
  zmap
  webdis
  syslog-ng-mod-redis
  ruby-hiredis
  rspamd
  rfc5766-turn-server
  python-hiredis
  ntopng
  kamailio-redis-modules
  libhiredis-dev
  libhiredis-dbg
  coturn

 Have you tested that they build fine against the new version of the
 library?


All seem to build just fine except for webdis, which segfaults during
tests. There are no segfaults when building against libhiredis0.10, so
looks like it's running afoul of something in the latest release.


-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#785349: transition: hiredis

[Tom Lee]

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

Hello, I'd like to request a transition slot from the release team.

The libhiredis SONAME changed in the latest release from upstream,
indicating ABI-incompatible changes to the library. Updating the binary
package to reflect the new SONAME. libhiredis0.13 has been uploaded to
experimental by my sponsor.

I couldn't quite figure out how to get the Ben file reportbug generated
for me below to give me a list of dependent packages (this is my first
request for a transition), but I pulled this list from apt-cache
rdepends if that's at all useful:

zmap
webdis
syslog-ng-mod-redis
ruby-hiredis
rspamd
rfc5766-turn-server
python-hiredis
ntopng
kamailio-redis-modules
libhiredis-dev
libhiredis-dbg
coturn

Please let me know if I'm doing it wrong -- happy to get some practice.

The reportbug-generated Ben file:

title = hiredis;
is_affected = .depends ~ libhiredis0.10 | .depends ~ libhiredis0.13;
is_good = .depends ~ libhiredis0.13;
is_bad = .depends ~ libhiredis0.10;


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

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


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

Bug#777810:

[Tom Lee]

I managed to successfully build
http://mentors.debian.net/debian/pool/main/c/capnproto/capnproto_0.5.2-1.dsc
against experimental/GCC-5 using pbuilder.

Not sure if you're actively attempting test rebuilds every so often, but
feel free to try for yourself when 0.5.2-1 hits unstable.

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#781787: capnproto: FTBFS on hppa: nan tests fail

[Tom Lee]

Thanks for reporting this John. I somehow overlooked this in prepping
0.5.2-1 thinking that upstream had fixed it, but obviously they're only
going to be applying a fix for mips  not hppa.

I've opened a PR to get this fixed upstream:

https://github.com/sandstorm-io/capnproto/pull/200

Sorry for the oversight. If upstream hasn't pushed a new source tarball
with this fix by the time I get around to cutting the next release, I'll
pull this patch back into the Debian packages.

On Thu, 2 Apr 2015 22:25:34 -0400 John David Anglin dave.ang...@bell.net
wrote:
 Package: capnproto
 Version: 0.4.1-3
 Severity: normal
 Tags: patch

 The hppa and mips architecture have the same nan format (i.e.,
 quiet and signalling nans are different from x86, etc).  With the
 attached change, capnproto builds successfully on hppa.  See:

http://buildd.debian-ports.org/status/fetch.php?pkg=capnprotoarch=hppaver=0.4.1-3stamp=1428027386

 The current mips patch could be modified to add hppa.

 -- System Information:
 Debian Release: 8.0
   APT prefers unreleased
   APT policy: (500, 'unreleased'), (500, 'unstable')
 Architecture: hppa (parisc64)

 Kernel: Linux 3.17.8+ (SMP w/4 CPU cores)
 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to
en_CA.utf8)
 Shell: /bin/sh linked to /bin/dash
 Init: sysvinit (via /sbin/init)

Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past

[Tom Lee]

  ] CharParsers.Number
[   OK ] CharParsers.Number (0 ms)
[ RUN  ] CharParsers.DoubleQuotedString
[   OK ] CharParsers.DoubleQuotedString (0 ms)
[ RUN  ] CharParsers.SingleQuotedString
[   OK ] CharParsers.SingleQuotedString (0 ms)
[--] 10 tests from CharParsers (1 ms total)

[--] 4 tests from Blob
[ RUN  ] Blob.Text
[   OK ] Blob.Text (0 ms)
[ RUN  ] Blob.Data
[   OK ] Blob.Data (0 ms)
[ RUN  ] Blob.Compare
[   OK ] Blob.Compare (0 ms)
[ RUN  ] Blob.StlInterop
[   OK ] Blob.StlInterop (0 ms)
[--] 4 tests from Blob (0 ms total)

[--] 4 tests from Endian
[ RUN  ] Endian.Byte
[   OK ] Endian.Byte (0 ms)
[ RUN  ] Endian.TwoBytes
[   OK ] Endian.TwoBytes (0 ms)
[ RUN  ] Endian.FourBytes
[   OK ] Endian.FourBytes (0 ms)
[ RUN  ] Endian.EightBytes
[   OK ] Endian.EightBytes (0 ms)
[--] 4 tests from Endian (1 ms total)

[--] 4 tests from EndianUnoptimized
[ RUN  ] EndianUnoptimized.Byte
[   OK ] EndianUnoptimized.Byte (0 ms)
[ RUN  ] EndianUnoptimized.TwoBytes
[   OK ] EndianUnoptimized.TwoBytes (0 ms)
[ RUN  ] EndianUnoptimized.FourBytes
[   OK ] EndianUnoptimized.FourBytes (0 ms)
[ RUN  ] EndianUnoptimized.EightBytes
[   OK ] EndianUnoptimized.EightBytes (0 ms)
[--] 4 tests from EndianUnoptimized (0 ms total)

[--] 4 tests from EndianReverse
[ RUN  ] EndianReverse.Byte
[   OK ] EndianReverse.Byte (0 ms)
[ RUN  ] EndianReverse.TwoBytes
[   OK ] EndianReverse.TwoBytes (0 ms)
[ RUN  ] EndianReverse.FourBytes
[   OK ] EndianReverse.FourBytes (0 ms)
[ RUN  ] EndianReverse.EightBytes
[   OK ] EndianReverse.EightBytes (0 ms)
[--] 4 tests from EndianReverse (1 ms total)

[--] 5 tests from WireFormat
[ RUN  ] WireFormat.SimpleRawDataStruct
[   OK ] WireFormat.SimpleRawDataStruct (0 ms)
[ RUN  ] WireFormat.StructRoundTrip_OneSegment
[   OK ] WireFormat.StructRoundTrip_OneSegment (0 ms)
[ RUN  ] WireFormat.StructRoundTrip_OneSegmentPerAllocation
[   OK ] WireFormat.StructRoundTrip_OneSegmentPerAllocation (0 ms)
[ RUN  ] WireFormat.StructRoundTrip_MultipleSegmentsWithMultipleAl
locations
[   OK ] WireFormat.StructRoundTrip_MultipleSegmentsWithMultipleAllocations
(0 ms)
[ RUN  ] WireFormat.NanPatching
[   OK ] WireFormat.NanPatching (0 ms)
[--] 5 tests from WireFormat (0 ms total)

[--] 1 test from Any
[ RUN  ] Any.AnyPointer
[   OK ] Any.AnyPointer (1 ms)
[--] 1 test from Any (1 ms total)

[--] 1 test from Message
[ RUN  ] Message.MallocBuilderWithFirstSegment
[   OK ] Message.MallocBuilderWithFirstSegment (0 ms)
[--] 1 test from Message (0 ms total)

[--] 14 tests from Capability
[ RUN  ] Capability.Basic
[   OK ] Capability.Basic (1 ms)
[ RUN  ] Capability.Inheritance
[   OK ] Capability.Inheritance (0 ms)
[ RUN  ] Capability.Pipelining
[   OK ] Capability.Pipelining (1 ms)
[ RUN  ] Capability.TailCall
[   OK ] Capability.TailCall (0 ms)
[ RUN  ] Capability.AsyncCancelation
[   OK ] Capability.AsyncCancelation (0 ms)
[ RUN  ] Capability.DynamicClient
[   OK ] Capability.DynamicClient (1 ms)
[ RUN  ] Capability.DynamicClientInheritance

On Sun, Mar 29, 2015 at 11:01 PM, Niels Thykier ni...@thykier.net wrote:

 On 2015-03-30 04:30, Tom Lee wrote:
  Hey Niels,
 
  Understood. Hard to see exactly what's going on here because we seem to
 be
  falling afoul of
 https://lists.debian.org/debian-devel/2014/04/msg00322.html.
  Do you happen to know if there's another way to get access to
  test-suite.log from these builds? The suggested work-around in that
 mailing
  list thread appears to require a change to the packaging, which I imagine
  we want to try and avoid.
 
  Cheers,
  Tom
 
 
  [...]

 Hi Tom,

 I see no problem in adding a VERBOSE=1 (or --disable-silent-rules, or
 whatever), as it does not have an effect of the produced built.
   In fact, I am not aware of any other way to obtain the test-suite.log
 from the buildds.  To my knowledge, the buildds more or less discards
 the build environment immediately after the build terminates.

 My best alternative is for you to get -guest access to a porterbox and
 try to reproduce it there[1].  It may take some time before you get such
 an account.  It might make sense for you to try that in parallel with
 the build logs - just in case the build logs are not enough for you to
 fix the issue.
   DDs also have access to porterboxes, so you might also be able to
 convince your sponsor to help you with obtaining additional information
 from the porterbox.  Though, in this case, you will probably want to
 stack up a few things to save a few roundtrips.  Maybe something like:

 
  * Please build the package and which fail the tests
  * Extract test-build.log
  * Run the test via gdb and do a bt at the point

Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past

[Tom Lee]

Hey Niels,

Understood. Hard to see exactly what's going on here because we seem to be
falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html.
Do you happen to know if there's another way to get access to
test-suite.log from these builds? The suggested work-around in that mailing
list thread appears to require a change to the packaging, which I imagine
we want to try and avoid.

Cheers,
Tom


On Sun, Mar 29, 2015 at 4:45 AM, Niels Thykier ni...@thykier.net wrote:

 Source: capnproto
 Version: 0.4.1-3
 Severity: serious

 Hi,

 It seems that the current version of capnproto FTBFS on armel and
 armhf due to a segmentation fault in one of the tests.  This prevents
 the new version of migrating to testing as it is a regression compared
 to the version in testing.

 Thanks,
 ~Niels




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#780565: Integer overflow in pointer validation

[Tom Lee]

Package: capnproto
Version: 0.4.1-2
Severity: critical

Upstream has reported a number of security issues in capnproto 0.4.1.
Creating bugs to track these issues while I work on getting them fixed.

This bug is tracking the Integer overflow in pointer validation bug
reported on 2015-03-02.

Full details + patch:
https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-0-c%2B%2B-integer-overflow.md

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#780568: CPU usage amplification attack #2

[Tom Lee]

Package: capnproto
Version: 0.4.1-2
Severity: critical

Upstream has reported a number of security issues in capnproto 0.4.1.
Creating bugs to track these issues while I work on getting them fixed.

This bug is tracking the second CPU usage amplification attack bug
reported on 2015-03-05.

Full details + patch:
https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-05-0-c%2B%2B-addl-cpu-amplification.md

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#780567: CPU usage amplification attack

[Tom Lee]

Package: capnproto
Version: 0.4.1-2
Severity: critical

Upstream has reported a number of security issues in capnproto 0.4.1.
Creating bugs to track these issues while I work on getting them fixed.

This bug is tracking the CPU usage amplification attack bug reported on
2015-03-02.

Full details + patch:
https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-2-all-cpu-amplification.md


-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#780566: Integer underflow in pointer validation

[Tom Lee]

Package: capnproto
Version: 0.4.1-2
Severity: critical

Upstream has reported a number of security issues in capnproto 0.4.1.
Creating bugs to track these issues while I work on getting them fixed.

This bug is tracking the Integer underflow in pointer validation bug
reported on 2015-03-02.

Full details + patch:
https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-1-c%2B%2B-integer-underflow.md

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: no subject

[Tom Lee]

Sorry, I probably haven't communicated my own inaction here. I've been
holding off on an unblock request given a) this appears to be a bug in
pbuilder, and b) we don't have a fix uploaded to unstable yet (which seems
reasonable given `a`). The pbuilder bug has gone relatively quiet over the
last few days too.

Anyway: I've talked things over with jcristau (release team) and the
suggestion is to reduce the severity of this bug to important, so it is no
longer release-critical.

On Thu, Dec 4, 2014 at 7:30 PM, Potter, Tim (Cloud Services) 
timothy.pot...@hp.com wrote:

 Hi everyone.  I'm nervously following along with this bug since its
 presence is threatening the removal of a couple of dozen other packages as
 you can all probably see from the QA page.

 In the spirit of not hassling anyone (-: I was curious whether there was a
 plan to close this out?  It sounds like a solution is very near, hopefully
 to the satisfaction of both the maintainers and release coordinators.


 Regards,

 Tim.




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

Alrighty, talking this over with Alessandro he made the case that we should
keep tests that don't rely on *external *network connections. See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753944 which makes the
case for a loopback interface in pbuilder.

Tobi, to that effect I modified your patch to keep the tests that work fine
with localhost  thus pass in pbuilder.

Also, I feel like the serious severity is overstating the issue given
that 0.11.0-4 builds fine in buildd/sbuild. Alessandro pointed out the
periodic rebuilds would have revealed this issue otherwise.

If there are no objections I'd like to propose we adjust the severity of
this bug to normal  leave the fix for this particular bug until after
the Jessie freeze.

Otherwise, I can reach out to the release team to get the hiredis package
unblocked  work through getting a new package uploaded with the pbuilder
fixes  nocheck support.


On Mon, Nov 24, 2014 at 4:32 AM, Tobias Frost t...@frost.de wrote:

 On Mon, 24 Nov 2014 00:45:04 -0800 Tom Lee deb...@tomlee.co wrote:
  Alrighty, patch applied  pbuilder's clean. Now just waiting on
 Alessandro
  to review my changes  push the package. On master here if you want to
 try
  things out in the interim: git://
 anonscm.debian.org/collab-maint/hiredis.git
 
 
  Daniel, I also added support for DEB_BUILD_OPTS=nocheck since it caused
 you
  additional grief.
 
  Tobi, I haven't bothered addressing the pid file etc. in /tmp just yet,
 but
  I'll take a look at that sometime soon.

 Please remember we are in freeze: Both those changes are not covered by the
 freeze policy as they are not targeting RC bugs.
 As the DEB_BUILD_OPTIONS=nocheck is already committed, I suggest you ask on
 #debian-release if that they could accept this.

 The /tmp thing is unimportant now, and can be fixed for Stretch, (if you
 want
 to fix it)

 --
 tobi




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

Talked this over with the release team on #debian-release, they agree it's
a serious bug  indicated that they'd prefer the fix to be something more
along the lines of what Gregor is suggesting. I feel like the test should
call out the fact it's skipped not passed, but otherwise imagine it would
look the same.

I'll open a bug against release.debian.org  get this resolved -- thanks
everyone!

On Sun, Nov 30, 2014 at 10:17 AM, gregor herrmann gre...@debian.org wrote:

 On Sun, 30 Nov 2014 17:36:04 +0100, Alessandro Ghedini wrote:

  On dom, nov 30, 2014 at 03:06:55 +0100, Tobias Frost wrote:
   Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee:

Also, I feel like the serious severity is overstating the issue
given that 0.11.0-4 builds fine in buildd/sbuild. Alessandro pointed
out the periodic rebuilds would have revealed this issue otherwise.
  
   
If there are no objections I'd like to propose we adjust the severity
of this bug to normal  leave the fix for this particular bug until
after the Jessie freeze.
  
   Here I can reprodcue the FTBFS locally with pbuilder 0.215+nmu3, so
   I disagree. It maybe has not been detected *yet*?
 
  What does this yet even mean? Except inside pbuilder, hiredis builds
 fine [1].
  The fact that it fails *only* inside pbuilder (and the fact that hiredis
 is not
  the only package in this situation) suggests that this is indeed a
 pbuilder bug.
  I really don't see how this is release critical in any way on the part
 of the
  hiredis package.

 While I tend to agree in general, here's an additional data point:
 I rebuilt 0.11.0-4 in my sid amd64 cowbuilder chroot, which has
 USENETWORK=yes (due to #753944) but firewalls off everything except
 localhost during build. And in this environment I see a test failure:

 make check
 make[2]: Entering directory '/tmp/buildd/hiredis-0.11.0'
 echo \
 daemonize yes\n \
 pidfile /tmp/hiredis-test-redis.pid\n \
 port 56379\n \
 bind 127.0.0.1\n \
 unixsocket /tmp/hiredis-test-redis.sock \
 | redis-server -
 ./hiredis-test -h 127.0.0.1 -p 56379 -s /tmp/hiredis-test-redis.sock || \
 ( kill `cat /tmp/hiredis-test-redis.pid`  false )
 #01 Format command without interpolation: PASSED
 #02 Format command with %s string interpolation: PASSED
 #03 Format command with %s and an empty string: PASSED
 #04 Format command with an empty string in between proper interpolations:
 PASSED
 #05 Format command with %b string interpolation: PASSED
 #06 Format command with %b and an empty string: PASSED
 #07 Format command with literal %: PASSED
 #08 Format command with printf-delegation (int): PASSED
 #09 Format command with printf-delegation (char): PASSED
 #10 Format command with printf-delegation (short): PASSED
 #11 Format command with printf-delegation (long): PASSED
 #12 Format command with printf-delegation (long long): PASSED
 #13 Format command with printf-delegation (unsigned int): PASSED
 #14 Format command with printf-delegation (unsigned char): PASSED
 #15 Format command with printf-delegation (unsigned short): PASSED
 #16 Format command with printf-delegation (unsigned long): PASSED
 #17 Format command with printf-delegation (unsigned long long): PASSED
 #18 Format command with printf-delegation (float): PASSED
 #19 Format command with printf-delegation (double): PASSED
 #20 Format command with invalid printf format: PASSED
 #21 Format command by passing argc/argv without lengths: PASSED
 #22 Format command by passing argc/argv with lengths: PASSED
 #23 Error handling in reply parser: PASSED
 #24 Memory cleanup in reply parser: PASSED
 #25 Set error on nested multi bulks with depth  7: PASSED
 #26 Works with NULL functions for reply: PASSED
 #27 Works when a single newline (\r\n) covers two calls to feed: PASSED
 #28 Don't reset state after protocol error: PASSED
 #29 Don't do empty allocation for empty multi bulk: PASSED
 #30 Returns error when host cannot be resolved: FAILED
 #31 Returns error when the unix socket path doesn't accept connections:
 PASSED

 [..]

 which seems to be the same as what Daniel originally reported.


 Adding a printf statement to test.c shows:
 #30 Returns error when host cannot be resolved: FAILED
 ERROR: Temporary failure in name resolution

 test.c currently looks for Name or service not known or Can't
 resolve: idontexist.local but not for what I get here ...

 Not sure what the best way forward is; adding a test for Temporary
 failure in name resolution might be an option (and works
 unsurprisingly):

 #v+
 --- a/test.c
 +++ b/test.c
 @@ -286,7 +286,8 @@
  c = redisConnect((char*)idontexist.local, 6379);
  test_cond(c-err == REDIS_ERR_OTHER 
  (strcmp(c-errstr,Name or service not known) == 0 ||
 - strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
 + strcmp(c-errstr,Can't resolve: idontexist.local) == 0 ||
 + strcmp(c-errstr,Temporary failure in name resolution) == 0));
  redisFree(c

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

D'oh :) There I go making assumptions.

All the same, I feel like we can argue back and forth about the severity of
this issue but we've got a potential fix ready to go. Might as well get the
release team involved -- if we can arrange an unblock the whole issue is
moot.

On Sun, Nov 30, 2014 at 11:00 AM, gregor herrmann gre...@debian.org wrote:

 On Sun, 30 Nov 2014 10:51:56 -0800, Tom Lee wrote:

  Talked this over with the release team on #debian-release,

 Except that noone who responded is a member of the release team :)

 Cheers,
 gregor

 --
  .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key
 0xBB3A68018649AA06
  : :' : Debian GNU/Linux user, admin, and developer  -
 http://www.debian.org/
  `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation
 Europe
`-   NP: Cat Stevens: I Love My Dog

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQJ8BAEBCgBmBQJUe2l0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
 QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGscoQAJIK0qNAR4/HTYvVRo7barIC
 ZK9EombbjP8kK+iNoX2lAhDhawJgwEJ7fUOWtcjG4rjamYsSGI9HKB9abu7Brqhb
 nap+NS5NKFctfdQP2zSn9AXpu8TWwzdC73a5BOAs3Msr6T2BHcKX+e8xcdXj77xc
 FFtvcPUcFLzBtCxZA+wBrWWvPn+ZJAVIKhcoxf/85JFpfmbGyjHdwiwq9XoTgfHu
 f5esudD3UjSzYYDpMf1fgWbdfG3E1CDmbfNsuBMAmnp4TUUGlL5MiaFjIMggBk/f
 M8K9TuLah/I8/kTLNfoWjQ74+q6WJI3GySXPpHdmHny+wltY92gs0d7mea3pzov/
 UiIMGUpO5kwX6CwL3mN9wFkhSbjEy6kBrUTBnDgXsH2ktGjn6bbjnDl8Tn++Idnz
 iLfDVStzlDtihg12zxT2gthoiFx7YcYFOlQSo6wxwDoOFUM0zJmuv1rov919UaQ4
 5GJhHD4CWG1oFEn/s/7z+aOrjb39X2cF1OQa8FzqYTnmBTd+vwSLNNP4S2ipOKJU
 hTWb6cov7xpZwdxZJfOCzWX3PJEuxDHZZjLHWQy0QNdkeEJouEe6edMdb//tYQEk
 vDCplr7xZfcVbJ2ALz0uiKWyOaP48AB0r8MED7T1e8qwxEBp1LqS1AQA87NNsNgA
 G0q+Hrl4KbKUVI8I2RDO
 =6Enz
 -END PGP SIGNATURE-




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

Rather than add to the overhead of getting this change accepted, I'm going
to roll back the DEB_BUILD_OPTS=nocheck change given it's unrelated to this
bug (per the freeze policy
https://release.debian.org/jessie/freeze_policy.html). I'll roll it back in
after the freeze.

Proposed change to 0.11.0-4 looks like this:

$ debdiff ~/Source/hiredis_0.11.0-4.dsc ../hiredis_0.11.0-5.dsc
gpgv: Signature made Sun 30 Nov 2014 01:12:44 PM PST using RSA key ID
6C6608D1
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on
/home/tom/Source/debian/hiredis_0.11.0-5.dsc
diff -Nru hiredis-0.11.0/debian/changelog hiredis-0.11.0/debian/changelog
--- hiredis-0.11.0/debian/changelog 2014-10-03 20:30:13.0 -0700
+++ hiredis-0.11.0/debian/changelog 2014-11-30 13:09:15.0 -0800
@@ -1,3 +1,9 @@
+hiredis (0.11.0-5) unstable; urgency=medium
+
+  * Disable a network test failing in pbuilder (closes: #770648)
+
+ -- Tom Lee deb...@tomlee.co  Mon, 24 Nov 2014 00:17:31 -0800
+
 hiredis (0.11.0-4) unstable; urgency=medium

   * Symlinks for cmake 3.0 (closes: #758548)
diff -Nru hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
--- hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
 1969-12-31 16:00:00.0 -0800
+++ hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
 2014-11-29 22:36:40.0 -0800
@@ -0,0 +1,25 @@
+Description: Disable Returns error when host cannot be resolved
+ This patch disables a test that relies on the presence of a
+ network connection.
+Author: Tobias Frost t...@debian.org
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/test.c
 b/test.c
+@@ -282,12 +282,16 @@
+ static void test_blocking_connection_errors(void) {
+ redisContext *c;
+
++#if 0
+ test(Returns error when host cannot be resolved: );
+ c = redisConnect((char*)idontexist.local, 6379);
+ test_cond(c-err == REDIS_ERR_OTHER 
+ (strcmp(c-errstr,Name or service not known) == 0 ||
+  strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
+ redisFree(c);
++#else
++test(SKIPPED: Returns error when host cannot be resolved\n);
++#endif
+
+ /*test(Returns error when the port is not open: );
+ c = redisConnect((char*)localhost, 1);
diff -Nru hiredis-0.11.0/debian/patches/series
hiredis-0.11.0/debian/patches/series
--- hiredis-0.11.0/debian/patches/series2014-10-03
20:30:13.0 -0700
+++ hiredis-0.11.0/debian/patches/series2014-11-24
00:11:32.0 -0800
@@ -1,3 +1,4 @@
 01_use-proper-destdir.patch
 02_disable-failing-test.patch
 03_pkgconfig-cmake.patch
+04_disable-network-tests.patch


On Sun, Nov 30, 2014 at 12:59 PM, Tom Lee deb...@tomlee.co wrote:

 D'oh :) There I go making assumptions.

 All the same, I feel like we can argue back and forth about the severity
 of this issue but we've got a potential fix ready to go. Might as well get
 the release team involved -- if we can arrange an unblock the whole issue
 is moot.

 On Sun, Nov 30, 2014 at 11:00 AM, gregor herrmann gre...@debian.org
 wrote:

 On Sun, 30 Nov 2014 10:51:56 -0800, Tom Lee wrote:

  Talked this over with the release team on #debian-release,

 Except that noone who responded is a member of the release team :)

 Cheers,
 gregor

 --
  .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key
 0xBB3A68018649AA06
  : :' : Debian GNU/Linux user, admin, and developer  -
 http://www.debian.org/
  `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation
 Europe
`-   NP: Cat Stevens: I Love My Dog

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQJ8BAEBCgBmBQJUe2l0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
 QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGscoQAJIK0qNAR4/HTYvVRo7barIC
 ZK9EombbjP8kK+iNoX2lAhDhawJgwEJ7fUOWtcjG4rjamYsSGI9HKB9abu7Brqhb
 nap+NS5NKFctfdQP2zSn9AXpu8TWwzdC73a5BOAs3Msr6T2BHcKX+e8xcdXj77xc
 FFtvcPUcFLzBtCxZA+wBrWWvPn+ZJAVIKhcoxf/85JFpfmbGyjHdwiwq9XoTgfHu
 f5esudD3UjSzYYDpMf1fgWbdfG3E1CDmbfNsuBMAmnp4TUUGlL5MiaFjIMggBk/f
 M8K9TuLah/I8/kTLNfoWjQ74+q6WJI3GySXPpHdmHny+wltY92gs0d7mea3pzov/
 UiIMGUpO5kwX6CwL3mN9wFkhSbjEy6kBrUTBnDgXsH2ktGjn6bbjnDl8Tn++Idnz
 iLfDVStzlDtihg12zxT2gthoiFx7YcYFOlQSo6wxwDoOFUM0zJmuv1rov919UaQ4
 5GJhHD4CWG1oFEn/s/7z+aOrjb39X2cF1OQa8FzqYTnmBTd+vwSLNNP4S2ipOKJU
 hTWb6cov7xpZwdxZJfOCzWX3PJEuxDHZZjLHWQy0QNdkeEJouEe6edMdb//tYQEk
 vDCplr7xZfcVbJ2ALz0uiKWyOaP48AB0r8MED7T1e8qwxEBp1LqS1AQA87NNsNgA
 G0q+Hrl4KbKUVI8I2RDO
 =6Enz
 -END PGP SIGNATURE-




 --
 *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

On Sun, Nov 30, 2014 at 1:31 PM, Alessandro Ghedini gh...@debian.org
wrote:

 This is, I think, the exact same problem as #759799 (which is btw severity:
 important). If the consensus is that this should be fixed in the affected
 packages (e.g. by disabling the tests), I'm all for it, but I really think
 that
 the effort should go into fixing pbuilder, since who knows how many
 packages
 are actually affected by this.


Agreed, but I'm going to get the release team involved to get this sorted
out given hiredis has been flagged for auto-removal in Jessie as a result
of this bug. Specifically, I'm requesting an unblock for 0.11.0-5 alongside
a request for clarification RE: the severity of this bug.

I suspect they're going to need to see 0.11.0-5 in unstable to make the
unblock happen, but if you like we can wait for them to comment on the
unblock request.


  Not sure what the best way forward is; adding a test for Temporary
  failure in name resolution might be an option (and works
  unsurprisingly):
 
  #v+
  --- a/test.c
  +++ b/test.c
  @@ -286,7 +286,8 @@
   c = redisConnect((char*)idontexist.local, 6379);
   test_cond(c-err == REDIS_ERR_OTHER 
   (strcmp(c-errstr,Name or service not known) == 0 ||
  - strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
  + strcmp(c-errstr,Can't resolve: idontexist.local) == 0 ||
  + strcmp(c-errstr,Temporary failure in name resolution) ==
 0));
   redisFree(c);
 
   /*test(Returns error when the port is not open: );
  #v-
 
  But maybe there are better ways to fix this.

 That would make the test kinda useless, but I guess it's no worse than
 disabling
 it completely.


I don't mind this approach if we call out the fact the test was skipped
rather than silently passed, but at that point it's providing the same
value as a test that's been completely disabled ... keeping Tobias'
original patch for now.


-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

 it with USENETWORK=yes, which
 just makes the test take much longer to fail.

 It would also seem that the source package doesn't honor
 DEB_BUILD_OPTIONS=nocheck, which makes it difficult to disable the tests
 to get
 a package built despite the test failures.
 --
 Daniel Schepler




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

Thanks so much Daniel for the bug report  Tobi for your patch. I'll get a
new build together over the next day or so.

Alessandro Ghedini has been pretty responsive wrt sponsoring my uploads,
but I'll reach out if I can't get a hold of him.

On Sun, Nov 23, 2014 at 2:52 AM, Tobias Frost t...@debian.org wrote:

 Package: src:hiredis
 Followup-For: Bug #770648

 Dear Maintainer,

 As already mentioned by David, you must not use network when building the
 package,
 even lo might not be available.

 The attached patch disables the network-based tests.

 PS: The pid-file location hardcoded to /tmp looks weird.. Maybe should be
 patched
 to use $CURDIR or a relatie path ?

 If you want me to sponsor that upload, please  ping me.

 --
 tobi

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

 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#758548: cmake 3.0 in unstable

[Tom Lee]

Fix is in git master, waiting for blessing from the package sponsor.
Hopefully see this ticket closed soon. Thanks!

On Sun, Sep 14, 2014 at 2:25 PM, Felix Geyer fge...@debian.org wrote:

 Control: severity -1 important

 I have just uploaded cmake 3.0.2-1 to unstable so the Find*.cmake files
 in /usr/share/cmake-2.8/Modules are not used anymore.

 Please provide a symlink/copy of those in /usr/share/cmake-3.0/Modules.

 Cheers,
 Felix




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#758548:

[Tom Lee]

Apologies for the delay on this, it slipped my mind. I'm tied up this week,
but I'll try to get a fix together sometime next week.

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#743402: capnproto: failed to run test on mips64el

[Tom Lee]

Patch will be available in 0.4.1-2. Thanks for your help getting this
sorted out, Yunqiang!


On Thu, Apr 17, 2014 at 9:22 AM, Yunqiang Su wzss...@gmail.com wrote:

 dpkg-buildpackage -B

 On Fri, Apr 18, 2014 at 12:20 AM, Tom Lee deb...@tomlee.co wrote:
  Weird. Can I ask what commands you're using to build the package from the
  github repo?
 
 
  On Thu, Apr 17, 2014 at 7:46 AM, Yunqiang Su wzss...@gmail.com wrote:
 
  seems still the same problem
 
  PASS: capnp-test
  PASS: capnp-evolution-test
  FAIL: src/capnp/compiler/capnp-test.sh
  make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
  make  all-recursive
  make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
  make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
  make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
 
 
 
  Testsuite summary for Capn Proto 0.4.1
 
 
 
  # TOTAL: 3
  # PASS:  2
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  1
  # XPASS: 0
  # ERROR: 0
 
 
 
  See ./test-suite.log
  Please report to capnpr...@googlegroups.com
 
 
 
  make[5]: *** [test-suite.log] Error 1
  make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[4]: *** [check-TESTS] Error 2
  make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[3]: *** [check-am] Error 2
  make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[2]: *** [check-recursive] Error 1
  make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[1]: *** [check] Error 2
  make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
  dh_auto_test: make -j1 check returned exit code 2
 
 
  On Thu, Apr 17, 2014 at 2:50 PM, Tom Lee deb...@tomlee.co wrote:
   Great, thanks again. Seems like this may have been an upstream bug.
 I've
   pushed a patch -- can you try the latest code on master?
  
   http://github.com/thomaslee/capnproto-debian
  
   Cheers,
   Tom
  
  
   On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com
 wrote:
  
   On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co wrote:
Thanks! Can you try the same thing, but instead of passing an empty
string
to the __builtin_nan* functions, can you pass 0? e.g.
   
__builtin_nanf(0)
  
   root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
   7fa0 7ff4 7ff4
   root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
   7fa0 7ff4 7ff4
   root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
   7fa0 7ff4 7ff4
   root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
   7fa0 7ff4 7ff4
  
  
   
   
On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su wzss...@gmail.com
wrote:
   
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fbf 7ff7 7ff7e000
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fbf 7ff7 7ff7
   
   
On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co
 wrote:
 Hey Yunqiang,

 I spoke to the upstream maintainer. He's asked if you can
 compile
 
 run
 this
 small C program (with and without optimizations) and to send the
 output
 from
 both:

 // begin

 #include stdio.h
 #include inttypes.h
 #include string.h

 int main() {
   float nanf = __builtin_nanf();
   double nand = __builtin_nan();
   double nancast = nanf;

   uint32_t nanfi;
   uint64_t nandi;
   uint64_t nancasti;

   memcpy(nanfi, nanf, 4);
   memcpy(nandi, nand, 8);
   memcpy(nancasti, nancast, 8);

   printf(%x %llx %llx\n, nanfi, nandi, nancasti);
   return 0;
 }

 // end

 Thanks!
 Tom



 On Sun, Apr 13, 2014 at 8:57 AM, Yunqiang Su wzss...@gmail.com
 
 wrote:

 make  check-TESTS
 make[4]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[5]: Entering directory `/tmp/capnproto/capnproto-debian'
 PASS: capnp-test
 PASS: capnp-evolution-test
 FAIL: src/capnp/compiler/capnp-test.sh
 make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
 make  all-recursive
 make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[7]: Leaving directory

Bug#743402: capnproto: failed to run test on mips64el

[Tom Lee]

Okay, thanks -- confirmed with upstream that the issue is a little trickier
to fix than he first thought. He doesn't have access to MIPS hardware to
test out his ideas for a fix, though. I'm going to ask around a little 
see if we can get direct access to a MIPS system to attack this bug. I'll
keep you posted.


On Thu, Apr 17, 2014 at 9:22 AM, Yunqiang Su wzss...@gmail.com wrote:

 dpkg-buildpackage -B

 On Fri, Apr 18, 2014 at 12:20 AM, Tom Lee deb...@tomlee.co wrote:
  Weird. Can I ask what commands you're using to build the package from the
  github repo?
 
 
  On Thu, Apr 17, 2014 at 7:46 AM, Yunqiang Su wzss...@gmail.com wrote:
 
  seems still the same problem
 
  PASS: capnp-test
  PASS: capnp-evolution-test
  FAIL: src/capnp/compiler/capnp-test.sh
  make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
  make  all-recursive
  make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
  make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
  make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
 
 
 
  Testsuite summary for Capn Proto 0.4.1
 
 
 
  # TOTAL: 3
  # PASS:  2
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  1
  # XPASS: 0
  # ERROR: 0
 
 
 
  See ./test-suite.log
  Please report to capnpr...@googlegroups.com
 
 
 
  make[5]: *** [test-suite.log] Error 1
  make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[4]: *** [check-TESTS] Error 2
  make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[3]: *** [check-am] Error 2
  make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[2]: *** [check-recursive] Error 1
  make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[1]: *** [check] Error 2
  make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
  dh_auto_test: make -j1 check returned exit code 2
 
 
  On Thu, Apr 17, 2014 at 2:50 PM, Tom Lee deb...@tomlee.co wrote:
   Great, thanks again. Seems like this may have been an upstream bug.
 I've
   pushed a patch -- can you try the latest code on master?
  
   http://github.com/thomaslee/capnproto-debian
  
   Cheers,
   Tom
  
  
   On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com
 wrote:
  
   On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co wrote:
Thanks! Can you try the same thing, but instead of passing an empty
string
to the __builtin_nan* functions, can you pass 0? e.g.
   
__builtin_nanf(0)
  
   root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
   7fa0 7ff4 7ff4
   root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
   7fa0 7ff4 7ff4
   root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
   7fa0 7ff4 7ff4
   root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
   7fa0 7ff4 7ff4
  
  
   
   
On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su wzss...@gmail.com
wrote:
   
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fbf 7ff7 7ff7e000
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fbf 7ff7 7ff7
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fbf 7ff7 7ff7
   
   
On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co
 wrote:
 Hey Yunqiang,

 I spoke to the upstream maintainer. He's asked if you can
 compile
 
 run
 this
 small C program (with and without optimizations) and to send the
 output
 from
 both:

 // begin

 #include stdio.h
 #include inttypes.h
 #include string.h

 int main() {
   float nanf = __builtin_nanf();
   double nand = __builtin_nan();
   double nancast = nanf;

   uint32_t nanfi;
   uint64_t nandi;
   uint64_t nancasti;

   memcpy(nanfi, nanf, 4);
   memcpy(nandi, nand, 8);
   memcpy(nancasti, nancast, 8);

   printf(%x %llx %llx\n, nanfi, nandi, nancasti);
   return 0;
 }

 // end

 Thanks!
 Tom



 On Sun, Apr 13, 2014 at 8:57 AM, Yunqiang Su wzss...@gmail.com
 
 wrote:

 make  check-TESTS
 make[4]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[5]: Entering directory `/tmp/capnproto/capnproto-debian'
 PASS: capnp-test
 PASS: capnp-evolution-test
 FAIL: src/capnp/compiler/capnp-test.sh
 make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
 make  all-recursive
 make[7

Bug#743402: capnproto: failed to run test on mips64el

[Tom Lee]

Oh great, thanks very much! Would you mind if I instead got the upstream
maintainer (Kenton Varda, CCed on this email) to give you his public key?
He's in a better position to fix the busted test.

Once he's got a patch I'll weave it back into the Debian packaging scripts
 let you know when they're ready to try again.


On Sat, Apr 19, 2014 at 2:26 PM, Yunqiang Su wzss...@gmail.com wrote:

 I can provide you a porterbox for remote access.
 Please give me your ssh public key with gpg signed.

 On Sun, Apr 20, 2014 at 4:00 AM, Tom Lee deb...@tomlee.co wrote:
  Okay, thanks -- confirmed with upstream that the issue is a little
 trickier
  to fix than he first thought. He doesn't have access to MIPS hardware to
  test out his ideas for a fix, though. I'm going to ask around a little 
 see
  if we can get direct access to a MIPS system to attack this bug. I'll
 keep
  you posted.
 
 
  On Thu, Apr 17, 2014 at 9:22 AM, Yunqiang Su wzss...@gmail.com wrote:
 
  dpkg-buildpackage -B
 
  On Fri, Apr 18, 2014 at 12:20 AM, Tom Lee deb...@tomlee.co wrote:
   Weird. Can I ask what commands you're using to build the package from
   the
   github repo?
  
  
   On Thu, Apr 17, 2014 at 7:46 AM, Yunqiang Su wzss...@gmail.com
 wrote:
  
   seems still the same problem
  
   PASS: capnp-test
   PASS: capnp-evolution-test
   FAIL: src/capnp/compiler/capnp-test.sh
   make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
   make  all-recursive
   make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
   make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
   make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
  
  
  
 
   Testsuite summary for Capn Proto 0.4.1
  
  
  
 
   # TOTAL: 3
   # PASS:  2
   # SKIP:  0
   # XFAIL: 0
   # FAIL:  1
   # XPASS: 0
   # ERROR: 0
  
  
  
 
   See ./test-suite.log
   Please report to capnpr...@googlegroups.com
  
  
  
 
   make[5]: *** [test-suite.log] Error 1
   make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[4]: *** [check-TESTS] Error 2
   make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[3]: *** [check-am] Error 2
   make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[2]: *** [check-recursive] Error 1
   make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[1]: *** [check] Error 2
   make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
   dh_auto_test: make -j1 check returned exit code 2
  
  
   On Thu, Apr 17, 2014 at 2:50 PM, Tom Lee deb...@tomlee.co wrote:
Great, thanks again. Seems like this may have been an upstream bug.
I've
pushed a patch -- can you try the latest code on master?
   
http://github.com/thomaslee/capnproto-debian
   
Cheers,
Tom
   
   
On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com
wrote:
   
On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co
 wrote:
 Thanks! Can you try the same thing, but instead of passing an
 empty
 string
 to the __builtin_nan* functions, can you pass 0? e.g.

 __builtin_nanf(0)
   
root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
7fa0 7ff4 7ff4
root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
7fa0 7ff4 7ff4
   
   


 On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su 
 wzss...@gmail.com
 wrote:

 root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
 7fbf 7ff7 7ff7e000
 root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
 7fbf 7ff7 7ff7
 root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
 7fbf 7ff7 7ff7
 root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
 7fbf 7ff7 7ff7


 On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co
 wrote:
  Hey Yunqiang,
 
  I spoke to the upstream maintainer. He's asked if you can
  compile
  
  run
  this
  small C program (with and without optimizations) and to send
  the
  output
  from
  both:
 
  // begin
 
  #include stdio.h
  #include inttypes.h
  #include string.h
 
  int main() {
float nanf = __builtin_nanf();
double nand = __builtin_nan();
double nancast = nanf;
 
uint32_t nanfi

Bug#743402: capnproto: failed to run test on mips64el

[Tom Lee]

Great, thanks again. Seems like this may have been an upstream bug. I've
pushed a patch -- can you try the latest code on master?

http://github.com/thomaslee/capnproto-debian

Cheers,
Tom


On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com wrote:

 On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co wrote:
  Thanks! Can you try the same thing, but instead of passing an empty
 string
  to the __builtin_nan* functions, can you pass 0? e.g.
 
  __builtin_nanf(0)

 root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
 7fa0 7ff4 7ff4
 root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
 7fa0 7ff4 7ff4
 root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
 7fa0 7ff4 7ff4
 root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
 7fa0 7ff4 7ff4


 
 
  On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su wzss...@gmail.com wrote:
 
  root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
  7fbf 7ff7 7ff7e000
  root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
  7fbf 7ff7 7ff7
  root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
  7fbf 7ff7 7ff7
  root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
  7fbf 7ff7 7ff7
 
 
  On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co wrote:
   Hey Yunqiang,
  
   I spoke to the upstream maintainer. He's asked if you can compile 
 run
   this
   small C program (with and without optimizations) and to send the
 output
   from
   both:
  
   // begin
  
   #include stdio.h
   #include inttypes.h
   #include string.h
  
   int main() {
 float nanf = __builtin_nanf();
 double nand = __builtin_nan();
 double nancast = nanf;
  
 uint32_t nanfi;
 uint64_t nandi;
 uint64_t nancasti;
  
 memcpy(nanfi, nanf, 4);
 memcpy(nandi, nand, 8);
 memcpy(nancasti, nancast, 8);
  
 printf(%x %llx %llx\n, nanfi, nandi, nancasti);
 return 0;
   }
  
   // end
  
   Thanks!
   Tom
  
  
  
   On Sun, Apr 13, 2014 at 8:57 AM, Yunqiang Su wzss...@gmail.com
 wrote:
  
   make  check-TESTS
   make[4]: Entering directory `/tmp/capnproto/capnproto-debian'
   make[5]: Entering directory `/tmp/capnproto/capnproto-debian'
   PASS: capnp-test
   PASS: capnp-evolution-test
   FAIL: src/capnp/compiler/capnp-test.sh
   make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
   make  all-recursive
   make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
   make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
   make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
  
  
  
 
   Testsuite summary for Capn Proto 0.4.1
  
  
  
 
   # TOTAL: 3
   # PASS:  2
   # SKIP:  0
   # XFAIL: 0
   # FAIL:  1
   # XPASS: 0
   # ERROR: 0
  
  
  
 
   See ./test-suite.log
   Please report to capnpr...@googlegroups.com
  
  
  
 
   make[5]: *** [test-suite.log] Error 1
   make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[4]: *** [check-TESTS] Error 2
   make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[3]: *** [check-am] Error 2
   make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[2]: *** [check-recursive] Error 1
   make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
   make[1]: *** [check] Error 2
   make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
   dh_auto_test: make -j1 check returned exit code 2
   make: *** [build-arch] Error 2
  
  
   On Sun, Apr 13, 2014 at 11:02 AM, Tom Lee deb...@tomlee.co wrote:
Thanks for the report -- I believe a downstream patch from the
 Ubuntu
folks
may fix this in the upcoming 0.4.1-1 release. Can you try the
debian/0.4.1-1
tag from git://github.com/thomaslee/capnproto-debian  let me
 know if
it
works any better?
   
   
On Wed, Apr 2, 2014 at 4:54 AM, Yunqiang Su wzss...@gmail.com
wrote:
   
Package: capnproto
Version: 0.4.0-1
   
I try to build capnproto on mips64el while it failed due to
 failure
on
test.
   
./src/capnp/compiler/../testdata/binary - differ: byte 1989, line
 4
FAIL: src/capnp/compiler/capnp-test.sh
===
1 of 3 tests failed
Please report to capnpr...@googlegroups.com
   
   
--
Yunqiang Su
   
   
   
   
--
Tom Lee / http://tomlee.co / @tglee
   
  
  
  
   --
   Yunqiang Su
  
  
  
  
   --
   Tom Lee / http://tomlee.co / @tglee
  
 
 
 
  --
  Yunqiang Su
 
 
 
 
  --
  Tom Lee / http://tomlee.co

Bug#743402: capnproto: failed to run test on mips64el

[Tom Lee]

Weird. Can I ask what commands you're using to build the package from the
github repo?


On Thu, Apr 17, 2014 at 7:46 AM, Yunqiang Su wzss...@gmail.com wrote:

 seems still the same problem

 PASS: capnp-test
 PASS: capnp-evolution-test
 FAIL: src/capnp/compiler/capnp-test.sh
 make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
 make  all-recursive
 make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'

 
 Testsuite summary for Capn Proto 0.4.1

 
 # TOTAL: 3
 # PASS:  2
 # SKIP:  0
 # XFAIL: 0
 # FAIL:  1
 # XPASS: 0
 # ERROR: 0

 
 See ./test-suite.log
 Please report to capnpr...@googlegroups.com

 
 make[5]: *** [test-suite.log] Error 1
 make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[4]: *** [check-TESTS] Error 2
 make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[3]: *** [check-am] Error 2
 make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[2]: *** [check-recursive] Error 1
 make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[1]: *** [check] Error 2
 make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
 dh_auto_test: make -j1 check returned exit code 2


 On Thu, Apr 17, 2014 at 2:50 PM, Tom Lee deb...@tomlee.co wrote:
  Great, thanks again. Seems like this may have been an upstream bug. I've
  pushed a patch -- can you try the latest code on master?
 
  http://github.com/thomaslee/capnproto-debian
 
  Cheers,
  Tom
 
 
  On Wed, Apr 16, 2014 at 11:18 PM, Yunqiang Su wzss...@gmail.com wrote:
 
  On Thu, Apr 17, 2014 at 1:19 PM, Tom Lee deb...@tomlee.co wrote:
   Thanks! Can you try the same thing, but instead of passing an empty
   string
   to the __builtin_nan* functions, can you pass 0? e.g.
  
   __builtin_nanf(0)
 
  root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
  7fa0 7ff4 7ff4
  root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
  7fa0 7ff4 7ff4
  root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
  7fa0 7ff4 7ff4
  root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
  7fa0 7ff4 7ff4
 
 
  
  
   On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su wzss...@gmail.com
 wrote:
  
   root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
   7fbf 7ff7 7ff7e000
   root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
   7fbf 7ff7 7ff7
   root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
   7fbf 7ff7 7ff7
   root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
   7fbf 7ff7 7ff7
  
  
   On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co wrote:
Hey Yunqiang,
   
I spoke to the upstream maintainer. He's asked if you can compile 
run
this
small C program (with and without optimizations) and to send the
output
from
both:
   
// begin
   
#include stdio.h
#include inttypes.h
#include string.h
   
int main() {
  float nanf = __builtin_nanf();
  double nand = __builtin_nan();
  double nancast = nanf;
   
  uint32_t nanfi;
  uint64_t nandi;
  uint64_t nancasti;
   
  memcpy(nanfi, nanf, 4);
  memcpy(nandi, nand, 8);
  memcpy(nancasti, nancast, 8);
   
  printf(%x %llx %llx\n, nanfi, nandi, nancasti);
  return 0;
}
   
// end
   
Thanks!
Tom
   
   
   
On Sun, Apr 13, 2014 at 8:57 AM, Yunqiang Su wzss...@gmail.com
wrote:
   
make  check-TESTS
make[4]: Entering directory `/tmp/capnproto/capnproto-debian'
make[5]: Entering directory `/tmp/capnproto/capnproto-debian'
PASS: capnp-test
PASS: capnp-evolution-test
FAIL: src/capnp/compiler/capnp-test.sh
make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
make  all-recursive
make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
   
   
   
   
 
Testsuite summary for Capn Proto 0.4.1
   
   
   
   
 
# TOTAL: 3
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0

Bug#743402: capnproto: failed to run test on mips64el

[Tom Lee]

Hey Yunqiang,

I spoke to the upstream maintainer. He's asked if you can compile  run
this small C program (with and without optimizations) and to send the
output from both:

// begin

#include stdio.h
#include inttypes.h
#include string.h

int main() {
  float nanf = __builtin_nanf();
  double nand = __builtin_nan();
  double nancast = nanf;

  uint32_t nanfi;
  uint64_t nandi;
  uint64_t nancasti;

  memcpy(nanfi, nanf, 4);
  memcpy(nandi, nand, 8);
  memcpy(nancasti, nancast, 8);

  printf(%x %llx %llx\n, nanfi, nandi, nancasti);
  return 0;
}

// end

Thanks!
Tom



On Sun, Apr 13, 2014 at 8:57 AM, Yunqiang Su wzss...@gmail.com wrote:

 make  check-TESTS
 make[4]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[5]: Entering directory `/tmp/capnproto/capnproto-debian'
 PASS: capnp-test
 PASS: capnp-evolution-test
 FAIL: src/capnp/compiler/capnp-test.sh
 make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
 make  all-recursive
 make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
 make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'

 
 Testsuite summary for Capn Proto 0.4.1

 
 # TOTAL: 3
 # PASS:  2
 # SKIP:  0
 # XFAIL: 0
 # FAIL:  1
 # XPASS: 0
 # ERROR: 0

 
 See ./test-suite.log
 Please report to capnpr...@googlegroups.com

 
 make[5]: *** [test-suite.log] Error 1
 make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[4]: *** [check-TESTS] Error 2
 make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[3]: *** [check-am] Error 2
 make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[2]: *** [check-recursive] Error 1
 make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
 make[1]: *** [check] Error 2
 make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
 dh_auto_test: make -j1 check returned exit code 2
 make: *** [build-arch] Error 2


 On Sun, Apr 13, 2014 at 11:02 AM, Tom Lee deb...@tomlee.co wrote:
  Thanks for the report -- I believe a downstream patch from the Ubuntu
 folks
  may fix this in the upcoming 0.4.1-1 release. Can you try the
 debian/0.4.1-1
  tag from git://github.com/thomaslee/capnproto-debian  let me know if it
  works any better?
 
 
  On Wed, Apr 2, 2014 at 4:54 AM, Yunqiang Su wzss...@gmail.com wrote:
 
  Package: capnproto
  Version: 0.4.0-1
 
  I try to build capnproto on mips64el while it failed due to failure on
  test.
 
  ./src/capnp/compiler/../testdata/binary - differ: byte 1989, line 4
  FAIL: src/capnp/compiler/capnp-test.sh
  ===
  1 of 3 tests failed
  Please report to capnpr...@googlegroups.com
 
 
  --
  Yunqiang Su
 
 
 
 
  --
  Tom Lee / http://tomlee.co / @tglee
 



 --
 Yunqiang Su




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#743402: capnproto: failed to run test on mips64el

[Tom Lee]

Thanks! Can you try the same thing, but instead of passing an empty string
to the __builtin_nan* functions, can you pass 0? e.g.

__builtin_nanf(0)


On Wed, Apr 16, 2014 at 10:13 PM, Yunqiang Su wzss...@gmail.com wrote:

 root@lm6100:/tmp/test# gcc -O0 xx.c;./a.out
 7fbf 7ff7 7ff7e000
 root@lm6100:/tmp/test# gcc -O1 xx.c;./a.out
 7fbf 7ff7 7ff7
 root@lm6100:/tmp/test# gcc -O2 xx.c;./a.out
 7fbf 7ff7 7ff7
 root@lm6100:/tmp/test# gcc -O3 xx.c;./a.out
 7fbf 7ff7 7ff7


 On Thu, Apr 17, 2014 at 1:08 PM, Tom Lee deb...@tomlee.co wrote:
  Hey Yunqiang,
 
  I spoke to the upstream maintainer. He's asked if you can compile  run
 this
  small C program (with and without optimizations) and to send the output
 from
  both:
 
  // begin
 
  #include stdio.h
  #include inttypes.h
  #include string.h
 
  int main() {
float nanf = __builtin_nanf();
double nand = __builtin_nan();
double nancast = nanf;
 
uint32_t nanfi;
uint64_t nandi;
uint64_t nancasti;
 
memcpy(nanfi, nanf, 4);
memcpy(nandi, nand, 8);
memcpy(nancasti, nancast, 8);
 
printf(%x %llx %llx\n, nanfi, nandi, nancasti);
return 0;
  }
 
  // end
 
  Thanks!
  Tom
 
 
 
  On Sun, Apr 13, 2014 at 8:57 AM, Yunqiang Su wzss...@gmail.com wrote:
 
  make  check-TESTS
  make[4]: Entering directory `/tmp/capnproto/capnproto-debian'
  make[5]: Entering directory `/tmp/capnproto/capnproto-debian'
  PASS: capnp-test
  PASS: capnp-evolution-test
  FAIL: src/capnp/compiler/capnp-test.sh
  make[6]: Entering directory `/tmp/capnproto/capnproto-debian'
  make  all-recursive
  make[7]: Entering directory `/tmp/capnproto/capnproto-debian'
  make[8]: Entering directory `/tmp/capnproto/capnproto-debian'
  make[8]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[7]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[6]: Leaving directory `/tmp/capnproto/capnproto-debian'
 
 
 
  Testsuite summary for Capn Proto 0.4.1
 
 
 
  # TOTAL: 3
  # PASS:  2
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  1
  # XPASS: 0
  # ERROR: 0
 
 
 
  See ./test-suite.log
  Please report to capnpr...@googlegroups.com
 
 
 
  make[5]: *** [test-suite.log] Error 1
  make[5]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[4]: *** [check-TESTS] Error 2
  make[4]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[3]: *** [check-am] Error 2
  make[3]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[2]: *** [check-recursive] Error 1
  make[2]: Leaving directory `/tmp/capnproto/capnproto-debian'
  make[1]: *** [check] Error 2
  make[1]: Leaving directory `/tmp/capnproto/capnproto-debian'
  dh_auto_test: make -j1 check returned exit code 2
  make: *** [build-arch] Error 2
 
 
  On Sun, Apr 13, 2014 at 11:02 AM, Tom Lee deb...@tomlee.co wrote:
   Thanks for the report -- I believe a downstream patch from the Ubuntu
   folks
   may fix this in the upcoming 0.4.1-1 release. Can you try the
   debian/0.4.1-1
   tag from git://github.com/thomaslee/capnproto-debian  let me know
 if it
   works any better?
  
  
   On Wed, Apr 2, 2014 at 4:54 AM, Yunqiang Su wzss...@gmail.com
 wrote:
  
   Package: capnproto
   Version: 0.4.0-1
  
   I try to build capnproto on mips64el while it failed due to failure
 on
   test.
  
   ./src/capnp/compiler/../testdata/binary - differ: byte 1989, line 4
   FAIL: src/capnp/compiler/capnp-test.sh
   ===
   1 of 3 tests failed
   Please report to capnpr...@googlegroups.com
  
  
   --
   Yunqiang Su
  
  
  
  
   --
   Tom Lee / http://tomlee.co / @tglee
  
 
 
 
  --
  Yunqiang Su
 
 
 
 
  --
  Tom Lee / http://tomlee.co / @tglee
 



 --
 Yunqiang Su




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#743402: capnproto: failed to run test on mips64el

[Tom Lee]

Thanks for the report -- I believe a downstream patch from the Ubuntu folks
may fix this in the upcoming 0.4.1-1 release. Can you try the
debian/0.4.1-1 tag from git://github.com/thomaslee/capnproto-debian  let
me know if it works any better?


On Wed, Apr 2, 2014 at 4:54 AM, Yunqiang Su wzss...@gmail.com wrote:

 Package: capnproto
 Version: 0.4.0-1

 I try to build capnproto on mips64el while it failed due to failure on
 test.

 ./src/capnp/compiler/../testdata/binary - differ: byte 1989, line 4
 FAIL: src/capnp/compiler/capnp-test.sh
 ===
 1 of 3 tests failed
 Please report to capnpr...@googlegroups.com


 --
 Yunqiang Su




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#739834: libhiredis-dev: Wrong include path in hiredis.pc

[Tom Lee]

Thanks Mikhail. Fix applied, I'll try to get a new package uploaded over
the next few days.


On Sat, Feb 22, 2014 at 4:48 PM, Mikhail Gusarov dotted...@debian.orgwrote:

 Package: libhiredis-dev
 Version: 0.11.0-3
 Severity: normal

 Dear Maintainer,

 hiredis.pc shipped in libhiredis-dev does not provide
 -I/usr/include/hiredis when asked for --cflags.

 However, examples in the same package include hiredis by #include
 hiredis.h,
 so path to directory containing hiredis.h should be emitted by pkg-config.

 See for yourself:
 $ cd /usr/share/doc/libhiredis-dev/examples
 $ gcc example.c $(pkg-config --cflags --libs hiredis)
 example.c:5:21: fatal error: hiredis.h: No such file or directory
 compilation terminated.
 $ gcc -o /tmp/a.out example.c $(pkg-config --cflags --libs hiredis)
 -I/usr/include/hiredis
 $

 I suppose

 Cflags: -I${includedir} -D_FILE_OFFSET_BITS=64

 should be changed to

 Cflags: -I${includedir}/hiredis -D_FILE_OFFSET_BITS=64

 in the .pc file.

 -- System Information:
 Debian Release: 7.1
   APT prefers testing
   APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1,
 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored:
 LC_ALL set to en_US.UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages libhiredis-dev depends on:
 ii  libhiredis0.10  0.11.0-3

 libhiredis-dev recommends no packages.

 libhiredis-dev suggests no packages.

 -- no debconf information




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#735232: capnproto: use dh-autoreconf to fix FTBFS on ppc64el and update config.{sub, guess} for new arches

[Tom Lee]

Thanks Logan, I've applied your patch:
https://github.com/thomaslee/capnproto-debian/commit/d89935f2ef1f82177e73baec0a9c0b9c087ce851

Expect it to land in 0.4.0-2.


On Mon, Jan 13, 2014 at 1:34 PM, Logan Rosen lo...@ubuntu.com wrote:

 Package: capnproto
 Version: 0.4.0-1
 Severity: normal
 Tags: patch
 User: ubuntu-de...@lists.ubuntu.com
 Usertags: origin-ubuntu trusty ubuntu-patch

 Dear Maintainer,

 For the ppc64el architecture in Ubuntu, since this package uses libtool, a
 full
 autoreconf is necessary instead of just config.{sub,guess} updates with
 autotools-dev. This is because we need new libtool macros for ppc64el.

 In Ubuntu, the attached patch was applied to achieve the following:

   * Use dh-autoreconf to get new libtool macros for ppc64el and update
 config.{sub,guess} for new arches.

 Thanks for considering the patch.

 Logan Rosen



 -- System Information:
 Debian Release: jessie/sid
   APT prefers trusty-updates
   APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
 'trusty'), (100, 'trusty-backports')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.13.0-2-generic (SMP w/1 CPU core)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee