On Mon, Feb 26, 2018 at 02:42:40PM -0600, Jason L Tibbitts III wrote:
> > "JJ" == Jakub Jelinek writes:
>
> JJ> Ok, so the problem is ignoring important warnings, in this case:
> JJ> imap/xapian_wrap.cpp: In function 'int
> JJ> stem_version_set(Xapian::WritableDatabase*, int)':
> JJ> imap/xap
> "JJ" == Jakub Jelinek writes:
JJ> Ok, so the problem is ignoring important warnings, in this case:
JJ> imap/xapian_wrap.cpp: In function 'int
JJ> stem_version_set(Xapian::WritableDatabase*, int)':
JJ> imap/xapian_wrap.cpp:267:1: warning: no return statement in function
JJ> returning non-voi
On Fri, Feb 23, 2018 at 05:40:23PM -0600, Jason L Tibbitts III wrote:
> It creates various search indices for the IMAP server (which is why it
> wraps Xapian). The manpage is available from
> https://cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html
> Technically the test suite si
I'm sorry, for the first time in decades I actually hit the send
key sequence (Ctrl-C Ctrl-C) accidentally.
> "JJ" == Jakub Jelinek writes:
JJ> Strangely, --enable-network to mock was really needed so that the
JJ> first testsuite passes.
That's absolutely bizarre.
JJ> I can now get the cor
I'm sorry, for the first time in decades I actually hit the send
key sequence (Ctrl-C Ctrl-C) accidentally.
> "JJ" == Jakub Jelinek writes:
JJ> Strangely, --enable-network to mock was really needed so that the
JJ> first testsuite passes.
That's absolutely bizarre.
JJ> I can now get the cor
> "JJ" == Jakub Jelinek writes:
JJ> Strangely, --enable-network to mock was really needed so that the
JJ> first testsuite passes.
That's absolutely bizarre.
JJ> I can now get the coredumps, but I'm afraid I really need a way to
JJ> reproduce it under gdb, from the core dump there isn't suff
Some more information:
I looked through the Koschei logs for this package and it seemed it
actually started failing before gcc8 went in. Specifically, the first
failed build was on January 22, and the changes for that run were:
mariadb-devel 3:10.2.12-2.fc28 -> 3:10.2.12-3.fc28
bi
On Fri, Feb 23, 2018 at 02:17:34PM -0600, Jason L Tibbitts III wrote:
> > "JJ" == Jakub Jelinek writes:
>
> JJ> Well, I'm seeing
> [...]
>
> So that's the first of the two test suites, which I've seen fail before
> but I haven't invested any time into debugging it. It's completely
> unrelat
> "JJ" == Jakub Jelinek writes:
JJ> Well, I'm seeing
[...]
So that's the first of the two test suites, which I've seen fail before
but I haven't invested any time into debugging it. It's completely
unrelated to any of the failures I'm talking about.
You can just remove or comment the line
On Fri, Feb 23, 2018 at 11:54:28AM -0600, Jason L Tibbitts III wrote:
> > "JJ" == Jakub Jelinek writes:
>
> JJ> Haven't managed to reproduce it, while there are some testsuite
> JJ> failures, they are due to timeouts and e.g. dmesg doesn't show any
> JJ> segvs nor traps.
>
> Of course I can
> "JJ" == Jakub Jelinek writes:
JJ> Haven't managed to reproduce it, while there are some testsuite
JJ> failures, they are due to timeouts and e.g. dmesg doesn't show any
JJ> segvs nor traps.
Of course I can reproduce this easily and it also happens in the
buildsystem. The first failure aft
On Fri, Feb 23, 2018 at 10:56:47AM -0600, Jason L Tibbitts III wrote:
> > "JJ" == Jakub Jelinek writes:
>
> JJ> Can I get detailed info on how to reproduce this (most importantly,
> JJ> which src.rpm you are trying to build)?
>
> Sorry, that was all in the original message.
>
> The package
> "JJ" == Jakub Jelinek writes:
JJ> Can I get detailed info on how to reproduce this (most importantly,
JJ> which src.rpm you are trying to build)?
Sorry, that was all in the original message.
The package is cyrus-imapd; all you have to do is check it out and do
fedpkg mockbuild (on the raw
On 23/02/18 13:16, Jakub Jelinek wrote:
On Thu, Feb 22, 2018 at 01:34:00PM -0800, John Reiser wrote:
Looking at the code:
= gcc/libgcc/unwind.inc
_Unwind_ForcedUnwind_Phase2 (struct _Unwind_Exception *exc,
struct _Unwind_Context *context,
On Thu, Feb 22, 2018 at 01:34:00PM -0800, John Reiser wrote:
> Looking at the code:
> = gcc/libgcc/unwind.inc
> _Unwind_ForcedUnwind_Phase2 (struct _Unwind_Exception *exc,
> struct _Unwind_Context *context,
> unsigned long *frames_p)
> "JR" == John Reiser writes:
JR> Those one-line tracebacks, with no source file and no line number,
JR> are a clue that valgrind could find no corresponding degbuginfo.
JR> Please install the debuginfo for libcyrus_imap.so.0.0.0 and
JR> libstdc++.so.6.0.25, then re-run valgrind. This is ver
Jason L Tibbitts III wrote:
"JR" == John Reiser writes:
JR> Please create a bugzilla report, or other well-known tracking
JR> instance.
But where? I don't even know whose problem this is. It's taken me days
of what little free time I have just to figure out how to get the
backtrace I was ab
> "JR" == John Reiser writes:
JR> Please create a bugzilla report, or other well-known tracking
JR> instance.
But where? I don't even know whose problem this is. It's taken me days
of what little free time I have just to figure out how to get the
backtrace I was able to provide.
I am cert
I could really use some help from the gcc experts.
Please create a bugzilla report, or other well-known tracking instance.
In particular, bugzilla asks about repeatability, version numbers, etc.
Non-repeatability due to unspecified or mismatched versions is frustrating.
A package I maintain, c
I could really use some help from the gcc experts.
A package I maintain, cyrus-imapd, contains two extensive test suites
which we run at package build time. After the big flag day where we
updated gcc and glibc and such in rawhide, one of the test suites now
shows failures and produces 22 core du
20 matches
Mail list logo
