build failures on mipsel

classic Classic list List threaded Threaded
9 messages Options
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|

build failures on mipsel

hey folks--

the notmuch 0.27 release candidates are failing to build on the debian
mipsel build daemons:

https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=mipsel&ver=0.27%7Erc0-1&stamp=1527466396&raw=0
https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=mipsel&ver=0.27%7Erc1-1&stamp=1528017305&raw=0

They both fail the test suite here:


T357-index-decryption: Testing indexing decrypted mail
 FAIL   stash decryption during show
        --- T357-index-decryption.9.expected 2018-06-03 09:13:02.472009180 +0000
        +++ T357-index-decryption.9.output 2018-06-03 09:13:02.472009180 +0000
        @@ -1 +1 @@
        -This is a test encrypted message with a wumpus.
        +
 FAIL   search should now find the contents
        --- T357-index-decryption.10.expected 2018-06-03 09:13:02.528010019 +0000
        +++ T357-index-decryption.10.output 2018-06-03 09:13:02.528010019 +0000
        @@ -1 +1 @@
        -thread:0000000000000003   2000-01-01 [1/1] Notmuch Test Suite; test encrypted message for cleartext index 002 (encrypted inbox unread)
        +


I've tried to replicate the problem over on eller.debian.org (the mipsel
porterbox) but when i build 0.27~rc1 over there in an schroot, i don't
even get to T357 because the emacs_fcc_message() function hangs in this
loop (is this known to not work in an schroot or under similar
situations?):

+(test/test-lib.sh:988): test_emacs(): sleep 1
+(test/test-lib.sh:987): test_emacs(): test_emacs '()'
+(test/test-lib.sh:960): test_emacs(): missing_dependencies=
+(test/test-lib.sh:961): test_emacs(): test_require_external_prereq dtach
+(test/test-lib.sh:674): test_require_external_prereq(): binary=dtach
+(test/test-lib.sh:675): test_require_external_prereq(): [[ '' == t ]]
+(test/test-lib.sh:679): test_require_external_prereq(): true
+(test/test-lib.sh:962): test_emacs(): test_require_external_prereq emacs
+(test/test-lib.sh:674): test_require_external_prereq(): binary=emacs
+(test/test-lib.sh:675): test_require_external_prereq(): [[ '' == t ]]
+(test/test-lib.sh:679): test_require_external_prereq(): true
+(test/test-lib.sh:963): test_emacs(): test_require_external_prereq emacsclient
+(test/test-lib.sh:674): test_require_external_prereq(): binary=emacsclient
+(test/test-lib.sh:675): test_require_external_prereq(): [[ '' == t ]]
+(test/test-lib.sh:679): test_require_external_prereq(): true
+(test/test-lib.sh:964): test_emacs(): test -z ''
+(test/test-lib.sh:966): test_emacs(): '[' -z notmuch-test-suite-1593 ']'
+(test/test-lib.sh:997): test_emacs(): rm -f OUTPUT
+(test/test-lib.sh:998): test_emacs(): touch OUTPUT
+(test/test-lib.sh:1000): test_emacs(): emacsclient --socket-name=notmuch-test-suite-1593 --eval '(notmuch-test-progn ())'

can anyone suggest a good next debugging step?

    --dkg

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch

signature.asc (233 bytes) Download Attachment
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: build failures on mipsel

Daniel Kahn Gillmor <[hidden email]> writes:

>
>
> I've tried to replicate the problem over on eller.debian.org (the mipsel
> porterbox) but when i build 0.27~rc1 over there in an schroot, i don't
> even get to T357 because the emacs_fcc_message() function hangs in this
> loop (is this known to not work in an schroot or under similar
> situations?):

Try:

$ make test-binaries && ./T357-index-decryption.sh

That works for me on eller, so there must be some difference between the
two environments (buildd versus porterbox)

d
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Tomi Ollila-2 Tomi Ollila-2
Reply | Threaded
Open this post in threaded view
|

Re: build failures on mipsel

In reply to this post by Daniel Kahn Gillmor
On Mon, Jun 04 2018, Daniel Kahn Gillmor wrote:

> hey folks--
>
> the notmuch 0.27 release candidates are failing to build on the debian
> mipsel build daemons:
>
> https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=mipsel&ver=0.27%7Erc0-1&stamp=1527466396&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=mipsel&ver=0.27%7Erc1-1&stamp=1528017305&raw=0
>
> They both fail the test suite here:
>
>
> T357-index-decryption: Testing indexing decrypted mail
>  FAIL   stash decryption during show
> --- T357-index-decryption.9.expected 2018-06-03 09:13:02.472009180 +0000
> +++ T357-index-decryption.9.output 2018-06-03 09:13:02.472009180 +0000
> @@ -1 +1 @@
> -This is a test encrypted message with a wumpus.
> +
>  FAIL   search should now find the contents
> --- T357-index-decryption.10.expected 2018-06-03 09:13:02.528010019 +0000
> +++ T357-index-decryption.10.output 2018-06-03 09:13:02.528010019 +0000
> @@ -1 +1 @@
> -thread:0000000000000003   2000-01-01 [1/1] Notmuch Test Suite; test encrypted message for cleartext index 002 (encrypted inbox unread)
> +
>
>
> I've tried to replicate the problem over on eller.debian.org (the mipsel
> porterbox) but when i build 0.27~rc1 over there in an schroot, i don't
> even get to T357 because the emacs_fcc_message() function hangs in this
> loop (is this known to not work in an schroot or under similar
> situations?):
>
> +(test/test-lib.sh:988): test_emacs(): sleep 1
> +(test/test-lib.sh:987): test_emacs(): test_emacs '()'
> +(test/test-lib.sh:960): test_emacs(): missing_dependencies=
> +(test/test-lib.sh:961): test_emacs(): test_require_external_prereq dtach
> +(test/test-lib.sh:674): test_require_external_prereq(): binary=dtach
> +(test/test-lib.sh:675): test_require_external_prereq(): [[ '' == t ]]
> +(test/test-lib.sh:679): test_require_external_prereq(): true
> +(test/test-lib.sh:962): test_emacs(): test_require_external_prereq emacs
> +(test/test-lib.sh:674): test_require_external_prereq(): binary=emacs
> +(test/test-lib.sh:675): test_require_external_prereq(): [[ '' == t ]]
> +(test/test-lib.sh:679): test_require_external_prereq(): true
> +(test/test-lib.sh:963): test_emacs(): test_require_external_prereq emacsclient
> +(test/test-lib.sh:674): test_require_external_prereq(): binary=emacsclient
> +(test/test-lib.sh:675): test_require_external_prereq(): [[ '' == t ]]
> +(test/test-lib.sh:679): test_require_external_prereq(): true
> +(test/test-lib.sh:964): test_emacs(): test -z ''
> +(test/test-lib.sh:966): test_emacs(): '[' -z notmuch-test-suite-1593 ']'
> +(test/test-lib.sh:997): test_emacs(): rm -f OUTPUT
> +(test/test-lib.sh:998): test_emacs(): touch OUTPUT
> +(test/test-lib.sh:1000): test_emacs(): emacsclient --socket-name=notmuch-test-suite-1593 --eval '(notmuch-test-progn ())'
>
> can anyone suggest a good next debugging step?

emacs did not start for some reason.

You could try changing the line

sh -c "stty rows 24 cols 80; exec '$TMP_DIRECTORY/run_emacs' \

to

script -c "stty rows 24 cols 80; exec '$TMP_DIRECTORY/run_emacs' \

in test-lib.sh and then see what you get in 'typescriptä file

>
>     --dkg


Tomi
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|

Re: build failures on mipsel

In reply to this post by David Bremner-2
On Mon 2018-06-04 23:44:25 -0300, David Bremner wrote:
> $ make test-binaries && ./T357-index-decryption.sh
>
> That works for me on eller, so there must be some difference between the
> two environments (buildd versus porterbox)

what schroot are you working from on eller?  i wonder what the
difference is between your schroot and mine, because mine fails with the
same emacs problem that tomi identified.

     --dkg
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|

Re: build failures on mipsel

In reply to this post by Daniel Kahn Gillmor
On Mon 2018-06-04 17:52:46 -0400, Daniel Kahn Gillmor wrote:
> I've tried to replicate the problem over on eller.debian.org (the mipsel
> porterbox) but when i build 0.27~rc1 over there in an schroot, i don't
> even get to T357 because the emacs_fcc_message() function hangs in this
> loop (is this known to not work in an schroot or under similar
> situations?):

This problem appears to be related to some bad interaction with
screen(1) inside a sid chroot on eller.  i note that bash also has
problems with command line editing in that environment as well.

I'm now running inside of tmux instead, and that problem doesn't happen
any more.

Furthermore, i can't replicate the failure from the buildd when building
on eller either.  So neither bremner nor i were able to replicate the
problem.

mipsel porters, do you have any suggestions for next-step debugging?

       --dkg

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch

signature.asc (233 bytes) Download Attachment
Tomi Ollila-2 Tomi Ollila-2
Reply | Threaded
Open this post in threaded view
|

Re: build failures on mipsel

On Wed, Jun 06 2018, Daniel Kahn Gillmor wrote:

> On Mon 2018-06-04 17:52:46 -0400, Daniel Kahn Gillmor wrote:
>> I've tried to replicate the problem over on eller.debian.org (the mipsel
>> porterbox) but when i build 0.27~rc1 over there in an schroot, i don't
>> even get to T357 because the emacs_fcc_message() function hangs in this
>> loop (is this known to not work in an schroot or under similar
>> situations?):
>
> This problem appears to be related to some bad interaction with
> screen(1) inside a sid chroot on eller.  i note that bash also has
> problems with command line editing in that environment as well.
>
> I'm now running inside of tmux instead, and that problem doesn't happen
> any more.
>
> Furthermore, i can't replicate the failure from the buildd when building
> on eller either.  So neither bremner nor i were able to replicate the
> problem.
>
> mipsel porters, do you have any suggestions for next-step debugging?


This is the line to start emacs

  # start a detached session with an emacs server
  # user's TERM (or 'vt100' in case user's TERM is known dumb
  # or unknown) is given to dtach which assumes a minimally
  # VT100-compatible terminal -- and emacs inherits that

  TERM=$SMART_TERM dtach -n "$TEST_TMPDIR/emacs-dtach-socket.$$" \
          sh -c "stty rows 24 cols 80; exec '$TMP_DIRECTORY/run_emacs' \
                  --no-window-system \
                  $load_emacs_tests \
                  --eval '(setq server-name \"$server_name\")' \
                  --eval '(server-start)' \
                  --eval '(orphan-watchdog $$)'" || return

my first guess: SMART_TERM is 'screen', and terminfo for that is missing

if not, then some TTY problem, which may break dtach, and if not dtach,
then emacs

my usual try is strace(1):

  TERM=$SMART_TERM strace -f dtach -n "$TEST_TMPDIR/emacs-dtach-socket.$$" \
          sh -c "stty rows 24 cols 80; exec '$TMP_DIRECTORY/run_emacs' \
                  --no-window-system \
                  $load_emacs_tests \
                  --eval '(setq server-name \"$server_name\")' \
                  --eval '(server-start)' \
                  --eval '(orphan-watchdog $$)'" &

(have to be run in background as strace -f will not exit until every child
program have exited...)

and then comb through strace output (-o option to strace may be useful...).

>
>        --dkg
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: build failures on mipsel

In reply to this post by Daniel Kahn Gillmor
Daniel Kahn Gillmor <[hidden email]> writes:

> On Mon 2018-06-04 23:44:25 -0300, David Bremner wrote:
>> $ make test-binaries && ./T357-index-decryption.sh
>>
>> That works for me on eller, so there must be some difference between the
>> two environments (buildd versus porterbox)
>
> what schroot are you working from on eller?  i wonder what the
> difference is between your schroot and mine, because mine fails with the
> same emacs problem that tomi identified.
>
>      --dkg

I'm using schroot session bremner-notmuch, which iirc I based on sid and
running ./T357-index-decryption.sh directly (in tmux or out doesn't seem
to matter).

d
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|

Re: build failures on mipsel

In reply to this post by Daniel Kahn Gillmor
On Wed 2018-06-06 10:30:15 -0400, Daniel Kahn Gillmor wrote:
> Furthermore, i can't replicate the failure from the buildd when building
> on eller either.  So neither bremner nor i were able to replicate the
> problem.
>
> mipsel porters, do you have any suggestions for next-step debugging?

I notice that the two failures for notmuch

  https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=mipsel&ver=0.27%7Erc0-1&stamp=1527466396&raw=0
  https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=mipsel&ver=0.27%7Erc1-1&stamp=1528017305&raw=0

are both built on the buildd mipsel-manda-03.debian.org.

perhaps there's something wrong with that buildd?  maybe a giveback
would let another build daemon take a crack at the package.

mipsel folks, could you give back the experimental version of notmuch to
the mipsel buildd network and try to avoid having it land on
mipsel-manda-03?

thanks,

      --dkg
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|

Re: build failures on mipsel

On Wed 2018-06-06 13:05:15 -0400, Daniel Kahn Gillmor wrote:
> mipsel folks, could you give back the experimental version of notmuch to
> the mipsel buildd network and try to avoid having it land on
> mipsel-manda-03?

Thank you for the giveback!  However, it looks like it landed on
mipsel-manda-03 again (and had the same error).  could you try giving it
back one more time?  is there a way to force it to another host?

or do you have another recommendation for debugging?

      --dkg
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch