Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

usb-modeswitch recipy update #3

Closed
wants to merge 2 commits into from
Closed

usb-modeswitch recipy update #3

wants to merge 2 commits into from

Conversation

tactical-drone
Copy link

USB modeswitch recipy update 2.2.0

  • usb-modeswitch recipe tarballs (2.0.1) were deleted and replaced them with 2.2.0 ones.
  • Updated recipes to reflect this.

@tactical-drone
Copy link
Author

Not how they do it

philb pushed a commit that referenced this pull request Jul 8, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Jul 15, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Jul 15, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Jul 16, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Jul 27, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Jul 29, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Jul 30, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 3, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 17, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 18, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 18, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 20, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 24, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 24, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 27, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Aug 31, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
philb pushed a commit that referenced this pull request Sep 14, 2015
the patch comes from:
https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455
https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch

The cleanup function in telnetd is called both directly and on SIGCHLD
signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while
running on a 2.6.31.11 kernel.

What we were seeing is hangs like these:

  (gdb) bt
  #0  0xb7702424 in __kernel_vsyscall ()
  #1  0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6
  #2  0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6
  #3  0xb767e6e0 in utmpname () from ./lib/libc.so.6
  #4  0xb76bcde7 in logout () from ./lib/libutil.so.1
  #5  0x0804c827 in cleanup ()
  #6  <signal handler called>
  #7  0xb7702424 in __kernel_vsyscall ()
  #8  0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6
  #9  0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6
  #10 0xb767d675 in getutline_r () from ./lib/libc.so.6
  #11 0xb76bce42 in logout () from ./lib/libutil.so.1
  #12 0x0804c827 in cleanup ()
  #13 0x0804a0b5 in telnet ()
  #14 0x0804a9c3 in main ()

and what has happened here is that the user closes the telnet session
via the escape character. This causes telnetd to call cleanup in frame
the SIGCHLD signal is delivered while telnetd is executing cleanup.

Telnetd then calls the signal handler for SIGCHLD, which is cleanup().
Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the
__libc_utmp_lock lock, and utmpname above does the same thing in frame

The fix registers the SIGCHLD handler as cleanup_sighandler, and makes
cleanup disable the SIGCHLD signal before calling cleanup_sighandler.

Signed-off-by: Simon Kagstrom <[email protected]>
Signed-off-by: Li Wang <[email protected]>
Signed-off-by: Martin Jansa <[email protected]>
halstead pushed a commit that referenced this pull request Apr 9, 2018
WARNING: pidgin-2.12.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch sanitize-configure.ac.patch
patching file configure.ac
Hunk #1 succeeded at 642 with fuzz 1 (offset 170 lines).
Hunk #2 succeeded at 2397 (offset 537 lines).
Hunk #3 succeeded at 2429 (offset 537 lines).

Now at patch sanitize-configure.ac.patch

Signed-off-by: Martin Jansa <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
halstead pushed a commit that referenced this pull request Apr 9, 2018
WARNING: pidgin-2.12.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch sanitize-configure.ac.patch
patching file configure.ac
Hunk #1 succeeded at 642 with fuzz 1 (offset 170 lines).
Hunk #2 succeeded at 2397 (offset 537 lines).
Hunk #3 succeeded at 2429 (offset 537 lines).

Now at patch sanitize-configure.ac.patch

Signed-off-by: Martin Jansa <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
halstead pushed a commit that referenced this pull request Apr 9, 2018
Fix QA warning:

WARNING: crda-3.18-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch fix-linking-of-libraries-used-by-reglib.patch
patching file Makefile
Hunk #2 succeeded at 40 with fuzz 2.
Hunk #3 succeeded at 46 (offset -5 lines).
Hunk #4 succeeded at 116 (offset -5 lines).

Now at patch fix-linking-of-libraries-used-by-reglib.patch

Signed-off-by: Yi Zhao <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
halstead pushed a commit that referenced this pull request Apr 9, 2018
WARNING: pidgin-2.12.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch sanitize-configure.ac.patch
patching file configure.ac
Hunk #1 succeeded at 642 with fuzz 1 (offset 170 lines).
Hunk #2 succeeded at 2397 (offset 537 lines).
Hunk #3 succeeded at 2429 (offset 537 lines).

Now at patch sanitize-configure.ac.patch

Signed-off-by: Martin Jansa <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
halstead pushed a commit that referenced this pull request Apr 9, 2018
Fix QA warning:

WARNING: crda-3.18-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch fix-linking-of-libraries-used-by-reglib.patch
patching file Makefile
Hunk #2 succeeded at 40 with fuzz 2.
Hunk #3 succeeded at 46 (offset -5 lines).
Hunk #4 succeeded at 116 (offset -5 lines).

Now at patch fix-linking-of-libraries-used-by-reglib.patch

Signed-off-by: Yi Zhao <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
anujm1 pushed a commit to anujm1/meta-openembedded that referenced this pull request Apr 9, 2018
WARNING: pidgin-2.12.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch sanitize-configure.ac.patch
patching file configure.ac
Hunk openembedded#1 succeeded at 642 with fuzz 1 (offset 170 lines).
Hunk openembedded#2 succeeded at 2397 (offset 537 lines).
Hunk openembedded#3 succeeded at 2429 (offset 537 lines).

Now at patch sanitize-configure.ac.patch

Signed-off-by: Martin Jansa <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
halstead pushed a commit that referenced this pull request Apr 13, 2018
WARNING:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
checking file Makefile
checking file configure
Hunk #3 succeeded at 232 (offset -4 lines).
Hunk #4 succeeded at 356 (offset -5 lines).
checking file src/vlock-main.c
Hunk #1 succeeded at 112 with fuzz 1 (offset 1 line).
Hunk #2 succeeded at 184 (offset 1 line).
Hunk #3 succeeded at 194 (offset 1 line).
Hunk #4 succeeded at 223 (offset 1 line).

among others

Signed-off-by: Armin Kuster <[email protected]>
halstead pushed a commit that referenced this pull request Apr 13, 2018
WARNING: nginx-1.12.2-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch nginx-cross.patch
patching file auto/feature
patching file auto/options
Hunk #1 succeeded at 386 (offset 33 lines).
Hunk #2 succeeded at 580 (offset 35 lines).
Hunk #3 succeeded at 599 (offset 22 lines).
patching file auto/types/sizeof
patching file auto/unix
Hunk #1 succeeded at 587 (offset 194 lines).
Hunk #2 succeeded at 604 with fuzz 1 (offset 188 lines).
Hunk #3 succeeded at 620 with fuzz 2 (offset 188 lines).

Now at patch nginx-cross.patch

Signed-off-by: Armin Kuster <[email protected]>
halstead pushed a commit that referenced this pull request Apr 13, 2018
Fix QA warning:

WARNING: crda-3.18-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch fix-linking-of-libraries-used-by-reglib.patch
patching file Makefile
Hunk #2 succeeded at 40 with fuzz 2.
Hunk #3 succeeded at 46 (offset -5 lines).
Hunk #4 succeeded at 116 (offset -5 lines).

Now at patch fix-linking-of-libraries-used-by-reglib.patch

Signed-off-by: Yi Zhao <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/meta-openembedded that referenced this pull request May 14, 2018
Source: meta-openembedded
MR: 00000
Type: Integration
Disposition: Merged from meta-openembedded
ChangeID: 8173679
Description:

WARNING: android-tools-5.1.1.r37-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:

    devtool modify <recipe>
    devtool finish --force-patch-refresh <recipe> <layer_path>

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch preserve-ownership.patch
patching file system/extras/ext4_utils/make_ext4fs_main.c
Hunk openembedded#1 succeeded at 47 with fuzz 2 (offset -2 lines).
Hunk openembedded#2 succeeded at 81 (offset -2 lines).
Hunk openembedded#3 succeeded at 144 (offset -2 lines).
patching file system/extras/ext4_utils/make_ext4fs.c

Now at patch preserve-ownership.patch

Signed-off-by: Martin Jansa <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
Signed-off-by: Jeremy Puhlman <[email protected]>
kraj pushed a commit to kraj/meta-openembedded that referenced this pull request May 29, 2018
When switch PATCHTOOL to patch, the key-replay-cve-multiple.patch can't
be apply with "--dry-run" as follows:

checking file src/ap/ieee802_11.c
checking file src/ap/wpa_auth.c
checking file src/ap/wpa_auth.h
checking file src/ap/wpa_auth_ft.c
checking file src/ap/wpa_auth_i.h
checking file src/common/wpa_common.h
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 FAILED at 709.
Hunk openembedded#2 FAILED at 757.
Hunk openembedded#3 succeeded at 840 (offset -12 lines).
Hunk openembedded#4 FAILED at 868.
Hunk openembedded#5 FAILED at 900.
Hunk openembedded#6 FAILED at 924.
Hunk openembedded#7 succeeded at 1536 (offset -38 lines).
Hunk openembedded#8 FAILED at 2386.
Hunk openembedded#9 FAILED at 2920.
Hunk openembedded#10 succeeded at 2940 (offset -46 lines).
Hunk openembedded#11 FAILED at 2998.
8 out of 11 hunks FAILED
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 FAILED at 32.
1 out of 1 hunk FAILED
checking file src/common/wpa_common.h
Hunk openembedded#1 succeeded at 215 with fuzz 1.
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/ap/wpa_auth.c
Hunk openembedded#1 succeeded at 1898 (offset -3 lines).
Hunk openembedded#2 succeeded at 2470 (offset -3 lines).
checking file src/rsn_supp/tdls.c
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 succeeded at 2378 (offset -62 lines).
checking file src/rsn_supp/wpa_ft.c
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 succeeded at 123 (offset -5 lines).

So split the key-replay-cve-multiple.patch to 7 patches.

Signed-off-by: Zheng Ruoqin <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to kraj/meta-openembedded that referenced this pull request May 29, 2018
When switch PATCHTOOL to patch, the key-replay-cve-multiple.patch can't
be apply with "--dry-run" as follows:

checking file src/ap/ieee802_11.c
checking file src/ap/wpa_auth.c
checking file src/ap/wpa_auth.h
checking file src/ap/wpa_auth_ft.c
checking file src/ap/wpa_auth_i.h
checking file src/common/wpa_common.h
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 FAILED at 709.
Hunk openembedded#2 FAILED at 757.
Hunk openembedded#3 succeeded at 840 (offset -12 lines).
Hunk openembedded#4 FAILED at 868.
Hunk openembedded#5 FAILED at 900.
Hunk openembedded#6 FAILED at 924.
Hunk openembedded#7 succeeded at 1536 (offset -38 lines).
Hunk openembedded#8 FAILED at 2386.
Hunk openembedded#9 FAILED at 2920.
Hunk openembedded#10 succeeded at 2940 (offset -46 lines).
Hunk openembedded#11 FAILED at 2998.
8 out of 11 hunks FAILED
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 FAILED at 32.
1 out of 1 hunk FAILED
checking file src/common/wpa_common.h
Hunk openembedded#1 succeeded at 215 with fuzz 1.
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/ap/wpa_auth.c
Hunk openembedded#1 succeeded at 1898 (offset -3 lines).
Hunk openembedded#2 succeeded at 2470 (offset -3 lines).
checking file src/rsn_supp/tdls.c
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 succeeded at 2378 (offset -62 lines).
checking file src/rsn_supp/wpa_ft.c
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 succeeded at 123 (offset -5 lines).

So split the key-replay-cve-multiple.patch to 7 patches.

Signed-off-by: Zheng Ruoqin <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to kraj/meta-openembedded that referenced this pull request May 29, 2018
When switch PATCHTOOL to patch, the key-replay-cve-multiple.patch can't
be apply with "--dry-run" as follows:

checking file src/ap/ieee802_11.c
checking file src/ap/wpa_auth.c
checking file src/ap/wpa_auth.h
checking file src/ap/wpa_auth_ft.c
checking file src/ap/wpa_auth_i.h
checking file src/common/wpa_common.h
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 FAILED at 709.
Hunk openembedded#2 FAILED at 757.
Hunk openembedded#3 succeeded at 840 (offset -12 lines).
Hunk openembedded#4 FAILED at 868.
Hunk openembedded#5 FAILED at 900.
Hunk openembedded#6 FAILED at 924.
Hunk openembedded#7 succeeded at 1536 (offset -38 lines).
Hunk openembedded#8 FAILED at 2386.
Hunk openembedded#9 FAILED at 2920.
Hunk openembedded#10 succeeded at 2940 (offset -46 lines).
Hunk openembedded#11 FAILED at 2998.
8 out of 11 hunks FAILED
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 FAILED at 32.
1 out of 1 hunk FAILED
checking file src/common/wpa_common.h
Hunk openembedded#1 succeeded at 215 with fuzz 1.
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/ap/wpa_auth.c
Hunk openembedded#1 succeeded at 1898 (offset -3 lines).
Hunk openembedded#2 succeeded at 2470 (offset -3 lines).
checking file src/rsn_supp/tdls.c
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 succeeded at 2378 (offset -62 lines).
checking file src/rsn_supp/wpa_ft.c
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 succeeded at 123 (offset -5 lines).

So split the key-replay-cve-multiple.patch to 7 patches.

Signed-off-by: Zheng Ruoqin <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/meta-openembedded that referenced this pull request Jun 13, 2018
Source: meta-openembedded
MR: 00000
Type: Integration
Disposition: Merged from meta-openembedded
ChangeID: 543bb9c
Description:

When switch PATCHTOOL to patch, the key-replay-cve-multiple.patch can't
be apply with "--dry-run" as follows:

checking file src/ap/ieee802_11.c
checking file src/ap/wpa_auth.c
checking file src/ap/wpa_auth.h
checking file src/ap/wpa_auth_ft.c
checking file src/ap/wpa_auth_i.h
checking file src/common/wpa_common.h
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 FAILED at 709.
Hunk openembedded#2 FAILED at 757.
Hunk openembedded#3 succeeded at 840 (offset -12 lines).
Hunk openembedded#4 FAILED at 868.
Hunk openembedded#5 FAILED at 900.
Hunk openembedded#6 FAILED at 924.
Hunk openembedded#7 succeeded at 1536 (offset -38 lines).
Hunk openembedded#8 FAILED at 2386.
Hunk openembedded#9 FAILED at 2920.
Hunk openembedded#10 succeeded at 2940 (offset -46 lines).
Hunk openembedded#11 FAILED at 2998.
8 out of 11 hunks FAILED
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 FAILED at 32.
1 out of 1 hunk FAILED
checking file src/common/wpa_common.h
Hunk openembedded#1 succeeded at 215 with fuzz 1.
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/ap/wpa_auth.c
Hunk openembedded#1 succeeded at 1898 (offset -3 lines).
Hunk openembedded#2 succeeded at 2470 (offset -3 lines).
checking file src/rsn_supp/tdls.c
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 succeeded at 2378 (offset -62 lines).
checking file src/rsn_supp/wpa_ft.c
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 succeeded at 123 (offset -5 lines).

So split the key-replay-cve-multiple.patch to 7 patches.

Signed-off-by: Zheng Ruoqin <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
Signed-off-by: Jeremy Puhlman <[email protected]>
halstead pushed a commit that referenced this pull request Jun 20, 2018
When switch PATCHTOOL to patch, the key-replay-cve-multiple.patch can't
be apply with "--dry-run" as follows:

checking file src/ap/ieee802_11.c
checking file src/ap/wpa_auth.c
checking file src/ap/wpa_auth.h
checking file src/ap/wpa_auth_ft.c
checking file src/ap/wpa_auth_i.h
checking file src/common/wpa_common.h
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/rsn_supp/wpa.c
Hunk #1 FAILED at 709.
Hunk #2 FAILED at 757.
Hunk #3 succeeded at 840 (offset -12 lines).
Hunk #4 FAILED at 868.
Hunk #5 FAILED at 900.
Hunk #6 FAILED at 924.
Hunk #7 succeeded at 1536 (offset -38 lines).
Hunk #8 FAILED at 2386.
Hunk #9 FAILED at 2920.
Hunk #10 succeeded at 2940 (offset -46 lines).
Hunk #11 FAILED at 2998.
8 out of 11 hunks FAILED
checking file src/rsn_supp/wpa_i.h
Hunk #1 FAILED at 32.
1 out of 1 hunk FAILED
checking file src/common/wpa_common.h
Hunk #1 succeeded at 215 with fuzz 1.
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/ap/wpa_auth.c
Hunk #1 succeeded at 1898 (offset -3 lines).
Hunk #2 succeeded at 2470 (offset -3 lines).
checking file src/rsn_supp/tdls.c
checking file src/rsn_supp/wpa.c
Hunk #1 succeeded at 2378 (offset -62 lines).
checking file src/rsn_supp/wpa_ft.c
checking file src/rsn_supp/wpa_i.h
Hunk #1 succeeded at 123 (offset -5 lines).

So split the key-replay-cve-multiple.patch to 7 patches.

Signed-off-by: Zheng Ruoqin <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
(cherry picked from commit 543bb9c)
Signed-off-by: Armin Kuster <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/meta-openembedded that referenced this pull request Jun 26, 2018
Source: meta-openembedded
MR: 00000
Type: Integration
Disposition: Merged from meta-openembedded
ChangeID: 49f937b
Description:

When switch PATCHTOOL to patch, the key-replay-cve-multiple.patch can't
be apply with "--dry-run" as follows:

checking file src/ap/ieee802_11.c
checking file src/ap/wpa_auth.c
checking file src/ap/wpa_auth.h
checking file src/ap/wpa_auth_ft.c
checking file src/ap/wpa_auth_i.h
checking file src/common/wpa_common.h
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 FAILED at 709.
Hunk openembedded#2 FAILED at 757.
Hunk openembedded#3 succeeded at 840 (offset -12 lines).
Hunk openembedded#4 FAILED at 868.
Hunk openembedded#5 FAILED at 900.
Hunk openembedded#6 FAILED at 924.
Hunk openembedded#7 succeeded at 1536 (offset -38 lines).
Hunk openembedded#8 FAILED at 2386.
Hunk openembedded#9 FAILED at 2920.
Hunk openembedded#10 succeeded at 2940 (offset -46 lines).
Hunk openembedded#11 FAILED at 2998.
8 out of 11 hunks FAILED
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 FAILED at 32.
1 out of 1 hunk FAILED
checking file src/common/wpa_common.h
Hunk openembedded#1 succeeded at 215 with fuzz 1.
checking file src/rsn_supp/wpa.c
checking file src/rsn_supp/wpa_i.h
checking file src/ap/wpa_auth.c
Hunk openembedded#1 succeeded at 1898 (offset -3 lines).
Hunk openembedded#2 succeeded at 2470 (offset -3 lines).
checking file src/rsn_supp/tdls.c
checking file src/rsn_supp/wpa.c
Hunk openembedded#1 succeeded at 2378 (offset -62 lines).
checking file src/rsn_supp/wpa_ft.c
checking file src/rsn_supp/wpa_i.h
Hunk openembedded#1 succeeded at 123 (offset -5 lines).

So split the key-replay-cve-multiple.patch to 7 patches.

Signed-off-by: Zheng Ruoqin <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
(cherry picked from commit 543bb9c)
Signed-off-by: Armin Kuster <[email protected]>
Signed-off-by: Jeremy Puhlman <[email protected]>
kraj pushed a commit to kraj/meta-openembedded that referenced this pull request Aug 21, 2018
Pass parameter "--disable-optimizations" to
configure script to disable compiler optimizations
to fix below issue:
$ gdb /usr/bin/fio
(gdb) r -h
Starting program: /usr/bin/fio -h
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000000000407220 in prio_tree_init () at lib/prio_tree.c:61
 61	index_bits_to_maxindex[i] = (1UL << (i + 1)) - 1;
(gdb) bt
 #0 0x0000000000407220 in prio_tree_init () at lib/prio_tree.c:61
 openembedded#1 0x0000000000482208 in __libc_csu_init (argc=argc@entry=2,
    argv=argv@entry=0x7fffffffecc8, envp=0x7fffffffece0)
    at /usr/src/debug/glibc/2.26-r0/git/csu/elf-init.c:88
 openembedded#2 0x00000031c742095e in __libc_start_main (main=0x407700 <main>, argc=2,
    argv=0x7fffffffecc8, init=0x4821b6 <__libc_csu_init>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffecb8)
    at /usr/src/debug/glibc/2.26-r0/git/csu/libc-start.c:264
 openembedded#3 0x00000000004077ea in _start () at ../sysdeps/x86_64/start.S:120

Signed-off-by: Mingli Yu <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/meta-openembedded that referenced this pull request Aug 23, 2018
Source: meta-openembedded
MR: 00000
Type: Integration
Disposition: Merged from meta-openembedded
ChangeID: 739349d
Description:

Pass parameter "--disable-optimizations" to
configure script to disable compiler optimizations
to fix below issue:
$ gdb /usr/bin/fio
(gdb) r -h
Starting program: /usr/bin/fio -h
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000000000407220 in prio_tree_init () at lib/prio_tree.c:61
 61	index_bits_to_maxindex[i] = (1UL << (i + 1)) - 1;
(gdb) bt
 #0 0x0000000000407220 in prio_tree_init () at lib/prio_tree.c:61
 openembedded#1 0x0000000000482208 in __libc_csu_init (argc=argc@entry=2,
    argv=argv@entry=0x7fffffffecc8, envp=0x7fffffffece0)
    at /usr/src/debug/glibc/2.26-r0/git/csu/elf-init.c:88
 openembedded#2 0x00000031c742095e in __libc_start_main (main=0x407700 <main>, argc=2,
    argv=0x7fffffffecc8, init=0x4821b6 <__libc_csu_init>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffecb8)
    at /usr/src/debug/glibc/2.26-r0/git/csu/libc-start.c:264
 openembedded#3 0x00000000004077ea in _start () at ../sysdeps/x86_64/start.S:120

Signed-off-by: Mingli Yu <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
Signed-off-by: Jeremy Puhlman <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jun 13, 2019
* Add EXTRA_CPANFLAGS to fix "undefined symbol: RAND_seed"
* Add DEPENDS on libcrypt-openssl-guess-perl-native
* Add runtime and ptest dependencies

Upstream release notes:
0.15  2018-04-22 rurban
        - fix mingw hints for pkg-config support (akiym, PR openembedded#7)

0.14  2018-04-17 rurban
        - add library paths to LIBS from Crypt::OpenSSL::Guess (akiym, PR openembedded#6)

0.13  2018-04-14 rurban
        - move Crypt::OpenSSL::Guess to configure dependency. (grinnz, PR openembedded#4)

0.12  2018-04-13 rurban
        - use Crypt::OpenSSL::Guess to resolve OpenSSL include path,
          fixes MacOS's homebrew OpenSSL installation problem. (akiym, PR openembedded#3)

Signed-off-by: Tim Orling <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jun 13, 2019
* Add EXTRA_CPANFLAGS to fix "undefined symbol: RAND_seed"
* Add DEPENDS on libcrypt-openssl-guess-perl-native
* Add runtime and ptest dependencies

Upstream release notes:
0.15  2018-04-22 rurban
        - fix mingw hints for pkg-config support (akiym, PR openembedded#7)

0.14  2018-04-17 rurban
        - add library paths to LIBS from Crypt::OpenSSL::Guess (akiym, PR openembedded#6)

0.13  2018-04-14 rurban
        - move Crypt::OpenSSL::Guess to configure dependency. (grinnz, PR openembedded#4)

0.12  2018-04-13 rurban
        - use Crypt::OpenSSL::Guess to resolve OpenSSL include path,
          fixes MacOS's homebrew OpenSSL installation problem. (akiym, PR openembedded#3)

Signed-off-by: Tim Orling <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jun 14, 2019
* Add EXTRA_CPANFLAGS to fix "undefined symbol: RAND_seed"
* Add DEPENDS on libcrypt-openssl-guess-perl-native
* Add runtime and ptest dependencies

Upstream release notes:
0.15  2018-04-22 rurban
        - fix mingw hints for pkg-config support (akiym, PR openembedded#7)

0.14  2018-04-17 rurban
        - add library paths to LIBS from Crypt::OpenSSL::Guess (akiym, PR openembedded#6)

0.13  2018-04-14 rurban
        - move Crypt::OpenSSL::Guess to configure dependency. (grinnz, PR openembedded#4)

0.12  2018-04-13 rurban
        - use Crypt::OpenSSL::Guess to resolve OpenSSL include path,
          fixes MacOS's homebrew OpenSSL installation problem. (akiym, PR openembedded#3)

Signed-off-by: Tim Orling <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jun 14, 2019
* Add EXTRA_CPANFLAGS to fix "undefined symbol: RAND_seed"
* Add DEPENDS on libcrypt-openssl-guess-perl-native
* Add runtime and ptest dependencies

Upstream release notes:
0.15  2018-04-22 rurban
        - fix mingw hints for pkg-config support (akiym, PR openembedded#7)

0.14  2018-04-17 rurban
        - add library paths to LIBS from Crypt::OpenSSL::Guess (akiym, PR openembedded#6)

0.13  2018-04-14 rurban
        - move Crypt::OpenSSL::Guess to configure dependency. (grinnz, PR openembedded#4)

0.12  2018-04-13 rurban
        - use Crypt::OpenSSL::Guess to resolve OpenSSL include path,
          fixes MacOS's homebrew OpenSSL installation problem. (akiym, PR openembedded#3)

Signed-off-by: Tim Orling <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jun 15, 2019
* Add EXTRA_CPANFLAGS to fix "undefined symbol: RAND_seed"
* Add DEPENDS on libcrypt-openssl-guess-perl-native
* Add runtime and ptest dependencies

Upstream release notes:
0.15  2018-04-22 rurban
        - fix mingw hints for pkg-config support (akiym, PR openembedded#7)

0.14  2018-04-17 rurban
        - add library paths to LIBS from Crypt::OpenSSL::Guess (akiym, PR openembedded#6)

0.13  2018-04-14 rurban
        - move Crypt::OpenSSL::Guess to configure dependency. (grinnz, PR openembedded#4)

0.12  2018-04-13 rurban
        - use Crypt::OpenSSL::Guess to resolve OpenSSL include path,
          fixes MacOS's homebrew OpenSSL installation problem. (akiym, PR openembedded#3)

Signed-off-by: Tim Orling <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/meta-openembedded that referenced this pull request Jun 28, 2019
Source: meta-openembedded
MR: 00000
Type: Integration
Disposition: Merged from meta-openembedded
ChangeID: b86d2d0
Description:

* Add EXTRA_CPANFLAGS to fix "undefined symbol: RAND_seed"
* Add DEPENDS on libcrypt-openssl-guess-perl-native
* Add runtime and ptest dependencies

Upstream release notes:
0.15  2018-04-22 rurban
        - fix mingw hints for pkg-config support (akiym, PR openembedded#7)

0.14  2018-04-17 rurban
        - add library paths to LIBS from Crypt::OpenSSL::Guess (akiym, PR openembedded#6)

0.13  2018-04-14 rurban
        - move Crypt::OpenSSL::Guess to configure dependency. (grinnz, PR openembedded#4)

0.12  2018-04-13 rurban
        - use Crypt::OpenSSL::Guess to resolve OpenSSL include path,
          fixes MacOS's homebrew OpenSSL installation problem. (akiym, PR openembedded#3)

Signed-off-by: Tim Orling <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
Signed-off-by: Jeremy Puhlman <[email protected]>
eric-ch pushed a commit to eric-ch/meta-openembedded that referenced this pull request Feb 19, 2020
The patch does not apply on lvm2 2.03.02.

Applying patch 0001-configure-Fix-setting-of-CLDFLAGS-default.patch
patching file configure
Hunk openembedded#1 FAILED at 3077.
Hunk openembedded#2 FAILED at 3098.
Hunk openembedded#3 FAILED at 3111.
3 out of 3 hunks FAILED -- rejects in file configure
patching file configure.ac
Hunk openembedded#2 succeeded at 50 (offset -1 lines).
Hunk openembedded#3 succeeded at 63 (offset -1 lines).
Patch 0001-configure-Fix-setting-of-CLDFLAGS-default.patch does not apply (enforce with -f)

Signed-off-by: Eric Chanudet <[email protected]>
schnitzeltony added a commit to schnitzeltony/meta-openembedded that referenced this pull request Jan 3, 2021
Release notes for 0.7.1
=======================
- Add option to not move cursor after calculations (openembedded#3)
- Align spin buttons in properties dialog
- Add close button to properties dialog
- Handle delete event when properties dialog is closed
- Adds new README.md updates AM_INIT_AUTOMAKE
- Update URLs from goodies.x.o to docs.x.o (Bug #16155)
- Allow compilation with panel 4.15
- Disable emoji input
- Translation Updates:
  Albanian, Armenian (Armenia), Basque, Belarusian, Bulgarian, Catalan,
  Chinese (China), Chinese (Taiwan), Croatian, Czech, Danish, Dutch,
  Eastern Armenian, English (Australia), English (Canada), Estonian,
  Finnish, French, Galician, German, Hebrew, Hindi, Hungarian,
  Icelandic, Indonesian, Interlingue, Italian, Japanese, Korean,
  Lithuanian, Malay, Norwegian Bokmål, Persian (Iran), Polish,
  Portuguese, Portuguese (Brazil), Russian, Serbian, Slovak, Slovenian,
  Spanish, Swedish, Turkish, Ukrainian

Signed-off-by: Andreas Müller <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jan 3, 2021
Release notes for 0.7.1
=======================
- Add option to not move cursor after calculations (openembedded#3)
- Align spin buttons in properties dialog
- Add close button to properties dialog
- Handle delete event when properties dialog is closed
- Adds new README.md updates AM_INIT_AUTOMAKE
- Update URLs from goodies.x.o to docs.x.o (Bug #16155)
- Allow compilation with panel 4.15
- Disable emoji input
- Translation Updates:
  Albanian, Armenian (Armenia), Basque, Belarusian, Bulgarian, Catalan,
  Chinese (China), Chinese (Taiwan), Croatian, Czech, Danish, Dutch,
  Eastern Armenian, English (Australia), English (Canada), Estonian,
  Finnish, French, Galician, German, Hebrew, Hindi, Hungarian,
  Icelandic, Indonesian, Interlingue, Italian, Japanese, Korean,
  Lithuanian, Malay, Norwegian Bokmål, Persian (Iran), Polish,
  Portuguese, Portuguese (Brazil), Russian, Serbian, Slovak, Slovenian,
  Spanish, Swedish, Turkish, Ukrainian

Signed-off-by: Andreas Müller <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jan 4, 2021
Release notes for 0.7.1
=======================
- Add option to not move cursor after calculations (openembedded#3)
- Align spin buttons in properties dialog
- Add close button to properties dialog
- Handle delete event when properties dialog is closed
- Adds new README.md updates AM_INIT_AUTOMAKE
- Update URLs from goodies.x.o to docs.x.o (Bug #16155)
- Allow compilation with panel 4.15
- Disable emoji input
- Translation Updates:
  Albanian, Armenian (Armenia), Basque, Belarusian, Bulgarian, Catalan,
  Chinese (China), Chinese (Taiwan), Croatian, Czech, Danish, Dutch,
  Eastern Armenian, English (Australia), English (Canada), Estonian,
  Finnish, French, Galician, German, Hebrew, Hindi, Hungarian,
  Icelandic, Indonesian, Interlingue, Italian, Japanese, Korean,
  Lithuanian, Malay, Norwegian Bokmål, Persian (Iran), Polish,
  Portuguese, Portuguese (Brazil), Russian, Serbian, Slovak, Slovenian,
  Spanish, Swedish, Turkish, Ukrainian

Signed-off-by: Andreas Müller <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
schnitzeltony added a commit to schnitzeltony/meta-openembedded that referenced this pull request Jan 4, 2021
Release notes for 0.7.1
=======================
- Add option to not move cursor after calculations (openembedded#3)
- Align spin buttons in properties dialog
- Add close button to properties dialog
- Handle delete event when properties dialog is closed
- Adds new README.md updates AM_INIT_AUTOMAKE
- Update URLs from goodies.x.o to docs.x.o (Bug #16155)
- Allow compilation with panel 4.15
- Disable emoji input
- Translation Updates:
  Albanian, Armenian (Armenia), Basque, Belarusian, Bulgarian, Catalan,
  Chinese (China), Chinese (Taiwan), Croatian, Czech, Danish, Dutch,
  Eastern Armenian, English (Australia), English (Canada), Estonian,
  Finnish, French, Galician, German, Hebrew, Hindi, Hungarian,
  Icelandic, Indonesian, Interlingue, Italian, Japanese, Korean,
  Lithuanian, Malay, Norwegian Bokmål, Persian (Iran), Polish,
  Portuguese, Portuguese (Brazil), Russian, Serbian, Slovak, Slovenian,
  Spanish, Swedish, Turkish, Ukrainian

Signed-off-by: Andreas Müller <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jan 4, 2021
Release notes for 0.7.1
=======================
- Add option to not move cursor after calculations (openembedded#3)
- Align spin buttons in properties dialog
- Add close button to properties dialog
- Handle delete event when properties dialog is closed
- Adds new README.md updates AM_INIT_AUTOMAKE
- Update URLs from goodies.x.o to docs.x.o (Bug #16155)
- Allow compilation with panel 4.15
- Disable emoji input
- Translation Updates:
  Albanian, Armenian (Armenia), Basque, Belarusian, Bulgarian, Catalan,
  Chinese (China), Chinese (Taiwan), Croatian, Czech, Danish, Dutch,
  Eastern Armenian, English (Australia), English (Canada), Estonian,
  Finnish, French, Galician, German, Hebrew, Hindi, Hungarian,
  Icelandic, Indonesian, Interlingue, Italian, Japanese, Korean,
  Lithuanian, Malay, Norwegian Bokmål, Persian (Iran), Polish,
  Portuguese, Portuguese (Brazil), Russian, Serbian, Slovak, Slovenian,
  Spanish, Swedish, Turkish, Ukrainian

Signed-off-by: Andreas Müller <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jan 5, 2021
Release notes for 0.7.1
=======================
- Add option to not move cursor after calculations (openembedded#3)
- Align spin buttons in properties dialog
- Add close button to properties dialog
- Handle delete event when properties dialog is closed
- Adds new README.md updates AM_INIT_AUTOMAKE
- Update URLs from goodies.x.o to docs.x.o (Bug #16155)
- Allow compilation with panel 4.15
- Disable emoji input
- Translation Updates:
  Albanian, Armenian (Armenia), Basque, Belarusian, Bulgarian, Catalan,
  Chinese (China), Chinese (Taiwan), Croatian, Czech, Danish, Dutch,
  Eastern Armenian, English (Australia), English (Canada), Estonian,
  Finnish, French, Galician, German, Hebrew, Hindi, Hungarian,
  Icelandic, Indonesian, Interlingue, Italian, Japanese, Korean,
  Lithuanian, Malay, Norwegian Bokmål, Persian (Iran), Polish,
  Portuguese, Portuguese (Brazil), Russian, Serbian, Slovak, Slovenian,
  Spanish, Swedish, Turkish, Ukrainian

Signed-off-by: Andreas Müller <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
halstead pushed a commit that referenced this pull request Apr 7, 2021
* fixes:
WARNING: opencv-4.1.0-r0 do_patch: Fuzz detected:

Applying patch CVE-2019-14491.patch
patching file modules/objdetect/src/cascadedetect.cpp
Hunk #1 succeeded at 46 with fuzz 1 (offset -1 lines).
Hunk #2 succeeded at 540 (offset -1 lines).
Hunk #3 succeeded at 552 (offset -1 lines).
Hunk #4 succeeded at 613 (offset -1 lines).
Hunk #5 succeeded at 774 (offset -1 lines).
Hunk #6 succeeded at 825 (offset -1 lines).
Hunk #7 succeeded at 1470 (offset -36 lines).
patching file modules/objdetect/src/cascadedetect.hpp

The context lines in the patches can be updated with devtool:

    devtool modify opencv
    devtool finish --force-patch-refresh opencv <layer_path>

Don't forget to review changes done by devtool!

WARNING: opencv-4.1.0-r0 do_patch: QA Issue: Patch log indicates that patches do not apply cleanly. [patch-fuzz]

Signed-off-by: Martin Jansa <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/meta-openembedded that referenced this pull request Apr 8, 2021
Source: meta-openembedded
MR: 108246
Type: Integration
Disposition: Merged from meta-openembedded
ChangeID: 637967e
Description:

* fixes:
WARNING: opencv-4.1.0-r0 do_patch: Fuzz detected:

Applying patch CVE-2019-14491.patch
patching file modules/objdetect/src/cascadedetect.cpp
Hunk openembedded#1 succeeded at 46 with fuzz 1 (offset -1 lines).
Hunk openembedded#2 succeeded at 540 (offset -1 lines).
Hunk openembedded#3 succeeded at 552 (offset -1 lines).
Hunk openembedded#4 succeeded at 613 (offset -1 lines).
Hunk openembedded#5 succeeded at 774 (offset -1 lines).
Hunk openembedded#6 succeeded at 825 (offset -1 lines).
Hunk openembedded#7 succeeded at 1470 (offset -36 lines).
patching file modules/objdetect/src/cascadedetect.hpp

The context lines in the patches can be updated with devtool:

    devtool modify opencv
    devtool finish --force-patch-refresh opencv <layer_path>

Don't forget to review changes done by devtool!

WARNING: opencv-4.1.0-r0 do_patch: QA Issue: Patch log indicates that patches do not apply cleanly. [patch-fuzz]

Signed-off-by: Martin Jansa <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
Signed-off-by: Jeremy Puhlman <[email protected]>
halstead pushed a commit that referenced this pull request Mar 27, 2022
Applying patch CVE-2021-22570.patch
patching file src/google/protobuf/descriptor.cc
Hunk #1 succeeded at 2603 with fuzz 1 (offset -23 lines).
Hunk #2 succeeded at 2817 with fuzz 1 (offset -14 lines).
Hunk #3 succeeded at 4006 (offset -17 lines).
Hunk #4 succeeded at 4050 (offset -18 lines).
Hunk #5 succeeded at 4368 (offset -18 lines).

Signed-off-by: Ross Burton <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/meta-openembedded that referenced this pull request Mar 28, 2022
Source: meta-openembedded
MR: 115838
Type: Integration
Disposition: Merged from meta-openembedded
ChangeID: a14eb5e
Description:

Applying patch CVE-2021-22570.patch
patching file src/google/protobuf/descriptor.cc
Hunk openembedded#1 succeeded at 2603 with fuzz 1 (offset -23 lines).
Hunk openembedded#2 succeeded at 2817 with fuzz 1 (offset -14 lines).
Hunk openembedded#3 succeeded at 4006 (offset -17 lines).
Hunk openembedded#4 succeeded at 4050 (offset -18 lines).
Hunk openembedded#5 succeeded at 4368 (offset -18 lines).

Signed-off-by: Ross Burton <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
Signed-off-by: Jeremy A. Puhlman <[email protected]>
halstead pushed a commit that referenced this pull request May 26, 2022
Applying patch CVE-2021-22570.patch
patching file src/google/protobuf/descriptor.cc
Hunk #1 succeeded at 2603 with fuzz 1 (offset -23 lines).
Hunk #2 succeeded at 2817 with fuzz 1 (offset -14 lines).
Hunk #3 succeeded at 4006 (offset -17 lines).
Hunk #4 succeeded at 4050 (offset -18 lines).
Hunk #5 succeeded at 4368 (offset -18 lines).

Signed-off-by: Ross Burton <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
jhershbe pushed a commit to jhershbe/meta-openembedded that referenced this pull request Sep 8, 2022
Pass parameter "--disable-optimizations" to
configure script to disable compiler optimizations
to fix below issue:
$ gdb /usr/bin/fio
(gdb) r -h
Starting program: /usr/bin/fio -h
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000000000407220 in prio_tree_init () at lib/prio_tree.c:61
 61	index_bits_to_maxindex[i] = (1UL << (i + 1)) - 1;
(gdb) bt
 #0 0x0000000000407220 in prio_tree_init () at lib/prio_tree.c:61
 #1 0x0000000000482208 in __libc_csu_init (argc=argc@entry=2,
    argv=argv@entry=0x7fffffffecc8, envp=0x7fffffffece0)
    at /usr/src/debug/glibc/2.26-r0/git/csu/elf-init.c:88
 openembedded#2 0x00000031c742095e in __libc_start_main (main=0x407700 <main>, argc=2,
    argv=0x7fffffffecc8, init=0x4821b6 <__libc_csu_init>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffecb8)
    at /usr/src/debug/glibc/2.26-r0/git/csu/libc-start.c:264
 openembedded#3 0x00000000004077ea in _start () at ../sysdeps/x86_64/start.S:120

Signed-off-by: Mingli Yu <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
jhershbe pushed a commit to jhershbe/meta-openembedded that referenced this pull request Oct 5, 2022
Pass parameter "--disable-optimizations" to
configure script to disable compiler optimizations
to fix below issue:
$ gdb /usr/bin/fio
(gdb) r -h
Starting program: /usr/bin/fio -h
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000000000407220 in prio_tree_init () at lib/prio_tree.c:61
 61	index_bits_to_maxindex[i] = (1UL << (i + 1)) - 1;
(gdb) bt
 #0 0x0000000000407220 in prio_tree_init () at lib/prio_tree.c:61
 #1 0x0000000000482208 in __libc_csu_init (argc=argc@entry=2,
    argv=argv@entry=0x7fffffffecc8, envp=0x7fffffffece0)
    at /usr/src/debug/glibc/2.26-r0/git/csu/elf-init.c:88
 openembedded#2 0x00000031c742095e in __libc_start_main (main=0x407700 <main>, argc=2,
    argv=0x7fffffffecc8, init=0x4821b6 <__libc_csu_init>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffecb8)
    at /usr/src/debug/glibc/2.26-r0/git/csu/libc-start.c:264
 openembedded#3 0x00000000004077ea in _start () at ../sysdeps/x86_64/start.S:120

Signed-off-by: Mingli Yu <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant