[Debian-med-packaging] You pushed new upstream source but no Debian packaging (Was: [Git][med-team/bali-phy] Pushed new tag upstream/3.1.4+dfsg)
Benjamin Redelings
benjamin.redelings at gmail.com
Tue May 22 17:49:09 BST 2018
Hi Andreas,
On 05/22/2018 02:12 AM, Andreas Tille wrote:
> Hi Benjamin,
>
> I noticed your push of the new upstream source but no change in
> packaging arrived in Git. I wonder whether you might have some not yet
> pushed commits on your side.
Yes, that was the problem.
> Please also note: While I'm observing the
> commits I usually do not sponsor a package to the Debian mirror before I
> get an explicite signal via mail asking for it. Just commiting to Git
> does not have the effect that a package is uploaded automatically.
Actually, I didn't expect that a git push would somehow trigger an
upload. I was thinking about whether to develop and push another
release 3.1.5 before e-mailing you. Given the build problems with
3.1.2, let's try and solve those first, and then I'll test a 3.1.5, push
it, and ask for an upload.
> BTW, there are some issues for 3.1.2 on some architectures. You can see
> an overview on the package tracker[1]. This is the relevant part of the
> build log on i386:
Thanks, I have now incorporated the link to the build logs into my
packaging-for-debian notes.
It looks like the problems fall into two categories
(1) compilation problems: gcc runs out of virtual memory compiling a
template-heavy c++ file.
I have reported this exact problem to gcc bugzilla here: see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80318
One work-around might be to stop compiling with '-g', and to stop
building the debug symbols package. I just checked and this gets
compile-time and memory down to 40s / 2.3g. I just checked that
"-fno-var-tracking -fno-var-tracking-assignments" doesn't only gets the
memory down to 4.6g.
Disabling the package on 32-bit archs seems a bit orthogonal to the
problem, since the build could fail on 64-build archs if the RAM is too
small.
Thoughts? Is removing -g possible / frowned-upon?
(2) Test timeouts
We have one test that times out -- it doesn't actually fail. It looks
like the build machine is taking about 10 times longer per test than my
laptop. Is that expected? For example, the test that succeeds at 29s
second runs in 3.1s on my laptop, and the test that times out at 30
second in the build log runs in 4.3 seconds on my laptop.
So, I could adjust the meson.build file to allow (say) 2 minutes for the
test that takes 3.1 seconds on my laptop, and (say) 3 minutes for the
test that takes 4.3 seconds on my laptop.
In summary, how about we wait to upload until a 3.1.5 that will hopefull
fix some of the build problems on other archs?
-BenRI
>
>
> ...
> [111/242] c++ -Isrc/src@@bali-phy at exe -Isrc -I../src -I. -I../ -I/usr/include/eigen3 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++14 -DHAVE_CONFIG_H -Wall -Wextra -Wno-sign-compare -Woverloaded-virtual -Wstrict-aliasing -Wno-unknown-pragmas -Wno-maybe-uninitialized -DNDEBUG -DNDEBUG_DP -O3 -funroll-loops -ffast-math -g -O2 -fdebug-prefix-map=/<<BUILDDIR>>/bali-phy-3.1.2+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -O3 -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 'src/src@@bali-phy at exe/parser_parse.cc.o' -MF 'src/src@@bali-phy at exe/parser_parse.cc.o.d' -o 'src/src@@bali-phy at exe/parser_parse.cc.o' -c ../src/parser/parse.cc
> FAILED: src/src@@bali-phy at exe/parser_parse.cc.o
> c++ -Isrc/src@@bali-phy at exe -Isrc -I../src -I. -I../ -I/usr/include/eigen3 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++14 -DHAVE_CONFIG_H -Wall -Wextra -Wno-sign-compare -Woverloaded-virtual -Wstrict-aliasing -Wno-unknown-pragmas -Wno-maybe-uninitialized -DNDEBUG -DNDEBUG_DP -O3 -funroll-loops -ffast-math -g -O2 -fdebug-prefix-map=/<<BUILDDIR>>/bali-phy-3.1.2+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -O3 -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 'src/src@@bali-phy at exe/parser_parse.cc.o' -MF 'src/src@@bali-phy at exe/parser_parse.cc.o.d' -o 'src/src@@bali-phy at exe/parser_parse.cc.o' -c ../src/parser/parse.cc
> ../src/parser/parse.cc: In constructor ‘HParser<Iterator>::HParser(HParser<Iterator>::error_handler_type&, const TokenDef&) [with TokenDef = HTokens<boost::spirit::lex::lexertl::actor_lexer<boost::spirit::lex::lexertl::position_token<boost::spirit::basic_istream_iterator<char>, boost::mpl::vector<int, char, std::__cxx11::basic_string<char> > > > >; Iterator = boost::spirit::lex::lexertl::iterator<boost::spirit::lex::lexertl::functor<boost::spirit::lex::lexertl::position_token<boost::spirit::basic_istream_iterator<char>, boost::mpl::vector<int, char, std::__cxx11::basic_string<char> > >, boost::spirit::lex::lexertl::detail::data, boost::spirit::basic_istream_iterator<char>, mpl_::bool_<true>, mpl_::bool_<true> > >]’:
> ../src/parser/parse.cc:563:5: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
> HParser(error_handler_type& error_handler, const TokenDef& tok)
> ^~~~~~~
> virtual memory exhausted: Operation not permitted
> ...
>
>
> I wonder whether this is a sign that balil-phy should be restricted to
> 64bit architectures. However the build on mips64el has another issue[2]:
>
> ...
> dh_auto_test -a -O--buildsystem=meson
> cd obj-mips64el-linux-gnuabi64 && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test
> [1/4] Generating git-version.h with a custom command.
> [1/2] Running all tests.
> 1/28 bali-phy version OK 0.11 s
> 2/28 bali-phy help OK 0.10 s
> 3/28 bali-phy 5d test OK 5.44 s
> 4/28 bali-phy 5d +A 50 TIMEOUT 30.12 s
> 5/28 bali-phy 5d -A 200 OK 29.63 s
> 6/28 model_P --help OK 0.05 s
> 7/28 statreport --help OK 0.04 s
> 8/28 stats-select --help OK 0.03 s
> 9/28 alignment-gild --help OK 0.03 s
> 10/28 alignment-consensus --help OK 0.04 s
> 11/28 alignment-max --help OK 0.04 s
> 12/28 alignment-chop-internal --help OK 0.04 s
> 13/28 alignment-indices --help OK 0.04 s
> 14/28 alignment-info --help OK 0.03 s
> 15/28 alignment-cat --help OK 0.03 s
> 16/28 alignment-translate --help OK 0.04 s
> 17/28 alignment-find --help OK 0.04 s
> 18/28 trees-consensus --help OK 0.04 s
> 19/28 tree-mean-lengths --help OK 0.04 s
> 20/28 mctree-mean-lengths --help OK 0.04 s
> 21/28 trees-to-SRQ --help OK 0.04 s
> 22/28 pickout --help OK 0.03 s
> 23/28 subsample --help OK 0.03 s
> 24/28 cut-range --help OK 0.04 s
> 25/28 trees-distances --help OK 0.04 s
> 26/28 alignment-thin --help OK 0.04 s
> 27/28 alignments-diff --help OK 0.03 s
> 28/28 bali-phy testsuite OK 359.37 s
>
> OK: 27
> FAIL: 1
> SKIP: 0
> TIMEOUT: 1
> ...
>
>
> Please let me know whether I should upload 3.1.4 and what you think about the
> issues on the other architectures.
>
> Kind regards
>
> Andreas.
>
> [1] https://buildd.debian.org/status/package.php?p=bali-phy
> [2] https://buildd.debian.org/status/fetch.php?pkg=bali-phy&arch=mips64el&ver=3.1.2%2Bdfsg-1&stamp=1525904116&raw=0
>
>
> On Mon, May 14, 2018 at 12:51:53PM +0000, Benjamin Redelings wrote:
>> Benjamin Redelings pushed new tag upstream/3.1.4+dfsg at Debian Med / bali-phy
>>
>> ---
>> View it on GitLab: https://salsa.debian.org/med-team/bali-phy/tree/upstream/3.1.4+dfsg
>> You're receiving this email because of your account on salsa.debian.org.
>> _______________________________________________
>> debian-med-commit mailing list
>> debian-med-commit at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit
>
More information about the Debian-med-packaging
mailing list