usb-modeswitch recipy update #3
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
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]>
Closed
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
USB modeswitch recipy update 2.2.0