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

Mplayer fix build and warning #10

Closed
wants to merge 2 commits into from

Conversation

abelal
Copy link
Contributor

@abelal abelal commented Dec 4, 2014

The patches fix build/configuration issues and a packaging warning. The commit messages describe the issue and how the problem is fixed.

Awais Belal added 2 commits December 4, 2014 16:15
The mplayer2 package does not support out of tree builds
and the do_configure step also tries to find the configure
script in the same build directory while the script lies in
the src directory.
This patch updates the builddir to point to the srcdir in
order to cope with the above issues.

Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Awais Belal <[email protected]>
The mplayer "make install" phase leaves an empty
/usr/lib directory seemingly regardless of the setting
of libdir.  Remove it to avoid a packaging warning.

Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Awais Belal <[email protected]>
@abelal
Copy link
Contributor Author

abelal commented Dec 5, 2014

Submitted to mailing list.

@abelal abelal closed this Dec 5, 2014
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 13, 2018
WARNING: hddtemp-0.3-beta15-r1 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 hddtemp_0.3-beta15-52.diff
patching file doc/hddtemp.8
patching file po/fr.po
patching file po/ru.po
patching file po/sv.po
patching file po/pt.po
patching file po/de.po
patching file po/LINGUAS
patching file po/hddtemp.pot
patching file src/sata.c
patching file src/satacmds.c
patching file src/backtrace.c
patching file src/daemon.c
patching file src/hddtemp.c
Hunk #5 succeeded at 268 with fuzz 2 (offset 4 lines).
Hunk #6 succeeded at 283 (offset 4 lines).
Hunk #7 succeeded at 295 (offset 4 lines).
Hunk #8 succeeded at 372 (offset 4 lines).
Hunk #9 succeeded at 409 (offset 4 lines).
Hunk #10 succeeded at 483 (offset 4 lines).
Hunk #11 succeeded at 496 (offset 4 lines).
Hunk #12 succeeded at 510 (offset 4 lines).
Hunk #13 succeeded at 532 (offset 4 lines).
patching file src/ata.c
patching file src/hddtemp.h
patching file src/scsicmds.c

Now at patch hddtemp_0.3-beta15-52.diff

Signed-off-by: Armin Kuster <[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]>
halstead pushed a commit that referenced this pull request Jul 30, 2020
Currently, testcnx ptest fails due to expired CA certificates:
Test project /usr/lib64/freeDiameter/ptest
...
Start 10: testcnx
10/11 Test #10: testcnx ..........................***Failed 0.12 sec
...

<snip>
Command: "/usr/lib64/freeDiameter/ptest/testcnx"
Directory: /usr/lib64/freeDiameter/ptest
"testcnx" start time: Jun 17 10:52 UTC
Output:
----------------------------------------------------------
10:52:43  ERROR  ERROR: Invalid parameter '(conn->cc_rcvthr != (pthread_t)((voidd
 *)0))', 22
10:52:43  ERROR  TLS: Remote certificate invalid on socket 6 (Remote: 'localhostt
.localdomain')(Connection: '{---T} TCP from [127.0.0.1]:57898 (4<-6)') :
10:52:43  ERROR   - The certificate has expired.
10:52:43  ERROR  TLS ERROR: in 'ret = gnutls_handshake(conn->cc_tls_para.sessionn
)' :    Error in the certificate.
10:52:43  FATAL! testcnx.c:867: CHECK FAILED : fd_cnx_handshake(server_side, GNUU
TLS_SERVER, ALGO_HANDSHAKE_DEFAULT , NULL, NULL) == 16 != 0
10:52:43  FATAL! FAILED: testcnx.c
<end of output>
Test time =   0.02 sec
<snip>

Backport upstream patch [1] to fix this issue.

[1] http://www.freediameter.net/hg/freeDiameter/rev/eff5bb332b5a

This patch is present in version 1.4.0, so master is not affected.

Signed-off-by: Ovidiu Panait <[email protected]>

Signed-off-by: Armin Kuster <[email protected]>
chaitu236 referenced this pull request in chaitu236/meta-openembedded Aug 10, 2020
Currently, testcnx ptest fails due to expired CA certificates:
Test project /usr/lib64/freeDiameter/ptest
...
Start 10: testcnx
10/11 Test ni#10: testcnx ..........................***Failed 0.12 sec
...

<snip>
Command: "/usr/lib64/freeDiameter/ptest/testcnx"
Directory: /usr/lib64/freeDiameter/ptest
"testcnx" start time: Jun 17 10:52 UTC
Output:
----------------------------------------------------------
10:52:43  ERROR  ERROR: Invalid parameter '(conn->cc_rcvthr != (pthread_t)((voidd
 *)0))', 22
10:52:43  ERROR  TLS: Remote certificate invalid on socket 6 (Remote: 'localhostt
.localdomain')(Connection: '{---T} TCP from [127.0.0.1]:57898 (4<-6)') :
10:52:43  ERROR   - The certificate has expired.
10:52:43  ERROR  TLS ERROR: in 'ret = gnutls_handshake(conn->cc_tls_para.sessionn
)' :    Error in the certificate.
10:52:43  FATAL! testcnx.c:867: CHECK FAILED : fd_cnx_handshake(server_side, GNUU
TLS_SERVER, ALGO_HANDSHAKE_DEFAULT , NULL, NULL) == 16 != 0
10:52:43  FATAL! FAILED: testcnx.c
<end of output>
Test time =   0.02 sec
<snip>

Backport upstream patch [1] to fix this issue.

[1] http://www.freediameter.net/hg/freeDiameter/rev/eff5bb332b5a

This patch is present in version 1.4.0, so master is not affected.

Signed-off-by: Ovidiu Panait <[email protected]>

Signed-off-by: Armin Kuster <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jul 15, 2021
License_Update: Update license to GPLv3

version 1.1.0:
 - drop support for libparted older than 2.4 (openembedded#16)
 - introduce `-n, --partition` to set a partition number when
   dealing with file dumps, /dev/loop and /dev/ram devices (openembedded#15)
 - ask confirmation for operations (e.g. FAT32 -> FAT16 conversion),
   add `-f, --force` option to not prompt (openembedded#13)
 - do not limit FAT32 usage on small partitions (openembedded#11)
 - update ChangeLog (openembedded#10)

Signed-off-by: Wang Mingyu <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jul 16, 2021
License_Update: Update license to GPLv3

version 1.1.0:
 - drop support for libparted older than 2.4 (openembedded#16)
 - introduce `-n, --partition` to set a partition number when
   dealing with file dumps, /dev/loop and /dev/ram devices (openembedded#15)
 - ask confirmation for operations (e.g. FAT32 -> FAT16 conversion),
   add `-f, --force` option to not prompt (openembedded#13)
 - do not limit FAT32 usage on small partitions (openembedded#11)
 - update ChangeLog (openembedded#10)

Signed-off-by: Wang Mingyu <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Jul 16, 2021
License_Update: Update license to GPLv3

version 1.1.0:
 - drop support for libparted older than 2.4 (openembedded#16)
 - introduce `-n, --partition` to set a partition number when
   dealing with file dumps, /dev/loop and /dev/ram devices (openembedded#15)
 - ask confirmation for operations (e.g. FAT32 -> FAT16 conversion),
   add `-f, --force` option to not prompt (openembedded#13)
 - do not limit FAT32 usage on small partitions (openembedded#11)
 - update ChangeLog (openembedded#10)

Signed-off-by: Wang Mingyu <[email protected]>
Signed-off-by: Khem Raj <[email protected]>
schnitzeltony added a commit to schnitzeltony/meta-openembedded that referenced this pull request Apr 1, 2022
* License checksum changed by polishing [1}
* Patch does not apply but took care for libical3 - see announcement below

[1] https://gitlab.xfce.org/apps/orage/-/commit/723fb89b3011db32a64986ea9ae560ae009f68fd

Release notes for 4.16.0
========================
Note: GlobalTime and Orage panel plugin are being deprecated and
will be removed in a future release. Their features will be
integrated with or provided by existing Xfce components.
See https://gitlab.xfce.org/apps/orage/-/issues/3#note_43209

Finalize port to GTK 3, small fixes and cleanup for 4.16.0 (see MRs
for more details):
- Add new application icon (!18)
- Fix some memory leaks
- i18n: Use `xfce_textdomain()` to initialize translations
- Trace messages cleanup (!15)
- Update COPYING (Issue openembedded#10, !17)
- Use stdout and stderr correctly in main.c
- Build tz_convert only with bundled libical (!14)
- Switch to reverse-DNS naming for icon and desktop files (!13)
- D-Bus service cleanup (!12)
- Fix `orage_exec()` and its calls
- Update project files (!10)
- Fixed strptime parse issue on FreeBSD (openembedded#6, !11)
- Fix make distcheck warnning
- Fixed libpopt detection on FreeBSD (!9)
- Fix build warnings 3: Clang static analyzer (!6)
- Added 'git' to program version string and 'sed' check (!7)
- Fix build warnings 2: Compilation (!4)
- Fix build warnings 1: Autotools (!3)
- Add basic GitLab pipeline (!2)

Commits from merge request !1 (GTK 3 port), which also includes
4.15.x below:
- Reverted to c60567fe
- Fixed typos
- Added support for 'legacy' non RGBA GTK colours. Both RGBA and old colous
  are now supported.
- Replaced unused parameters '(void)' castings with GLib G_GNUC_UNUSED. Added
  GLib check to configure.
- Removed trailing whitespaces and corrected formatting
- Updated version numbers
- Aligned new appointment->alarm Sound and Procedure entry fields and removed
  unused code.
- Renamed 'OragePlugin *clock' to 'OragePlugin *plugin' or 'OragePlugin
  *orage_plugin'
- Fixed libical support, supported libical version is now >= 3.0.
- Added variable tmp only when HAVE_LIBICAL is not defined
- Dead code removal
- Removed outdated is_utc, libical uses UTC timezone. This patch allows to use
  libical 3.0
- Updated with 'Ical week start day' issue
- Fixed: "'Ical week start day' configuration parameter is ignored". Issue openembedded#5
- Changed version number to 4.15.2

- Translation Updates

Signed-off-by: Andreas Müller <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Apr 2, 2022
* License checksum changed by polishing [1}
* Patch does not apply but took care for libical3 - see announcement below

[1] https://gitlab.xfce.org/apps/orage/-/commit/723fb89b3011db32a64986ea9ae560ae009f68fd

Release notes for 4.16.0
========================
Note: GlobalTime and Orage panel plugin are being deprecated and
will be removed in a future release. Their features will be
integrated with or provided by existing Xfce components.
See https://gitlab.xfce.org/apps/orage/-/issues/3#note_43209

Finalize port to GTK 3, small fixes and cleanup for 4.16.0 (see MRs
for more details):
- Add new application icon (!18)
- Fix some memory leaks
- i18n: Use `xfce_textdomain()` to initialize translations
- Trace messages cleanup (!15)
- Update COPYING (Issue openembedded#10, !17)
- Use stdout and stderr correctly in main.c
- Build tz_convert only with bundled libical (!14)
- Switch to reverse-DNS naming for icon and desktop files (!13)
- D-Bus service cleanup (!12)
- Fix `orage_exec()` and its calls
- Update project files (!10)
- Fixed strptime parse issue on FreeBSD (openembedded#6, !11)
- Fix make distcheck warnning
- Fixed libpopt detection on FreeBSD (!9)
- Fix build warnings 3: Clang static analyzer (!6)
- Added 'git' to program version string and 'sed' check (!7)
- Fix build warnings 2: Compilation (!4)
- Fix build warnings 1: Autotools (!3)
- Add basic GitLab pipeline (!2)

Commits from merge request !1 (GTK 3 port), which also includes
4.15.x below:
- Reverted to c60567fe
- Fixed typos
- Added support for 'legacy' non RGBA GTK colours. Both RGBA and old colous
  are now supported.
- Replaced unused parameters '(void)' castings with GLib G_GNUC_UNUSED. Added
  GLib check to configure.
- Removed trailing whitespaces and corrected formatting
- Updated version numbers
- Aligned new appointment->alarm Sound and Procedure entry fields and removed
  unused code.
- Renamed 'OragePlugin *clock' to 'OragePlugin *plugin' or 'OragePlugin
  *orage_plugin'
- Fixed libical support, supported libical version is now >= 3.0.
- Added variable tmp only when HAVE_LIBICAL is not defined
- Dead code removal
- Removed outdated is_utc, libical uses UTC timezone. This patch allows to use
  libical 3.0
- Updated with 'Ical week start day' issue
- Fixed: "'Ical week start day' configuration parameter is ignored". Issue openembedded#5
- Changed version number to 4.15.2

- Translation Updates

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 Apr 3, 2022
* License checksum changed by polishing [1}
* Patch does not apply but took care for libical3 - see announcement below

[1] https://gitlab.xfce.org/apps/orage/-/commit/723fb89b3011db32a64986ea9ae560ae009f68fd

Release notes for 4.16.0
========================
Note: GlobalTime and Orage panel plugin are being deprecated and
will be removed in a future release. Their features will be
integrated with or provided by existing Xfce components.
See https://gitlab.xfce.org/apps/orage/-/issues/3#note_43209

Finalize port to GTK 3, small fixes and cleanup for 4.16.0 (see MRs
for more details):
- Add new application icon (!18)
- Fix some memory leaks
- i18n: Use `xfce_textdomain()` to initialize translations
- Trace messages cleanup (!15)
- Update COPYING (Issue openembedded#10, !17)
- Use stdout and stderr correctly in main.c
- Build tz_convert only with bundled libical (!14)
- Switch to reverse-DNS naming for icon and desktop files (!13)
- D-Bus service cleanup (!12)
- Fix `orage_exec()` and its calls
- Update project files (!10)
- Fixed strptime parse issue on FreeBSD (openembedded#6, !11)
- Fix make distcheck warnning
- Fixed libpopt detection on FreeBSD (!9)
- Fix build warnings 3: Clang static analyzer (!6)
- Added 'git' to program version string and 'sed' check (!7)
- Fix build warnings 2: Compilation (!4)
- Fix build warnings 1: Autotools (!3)
- Add basic GitLab pipeline (!2)

Commits from merge request !1 (GTK 3 port), which also includes
4.15.x below:
- Reverted to c60567fe
- Fixed typos
- Added support for 'legacy' non RGBA GTK colours. Both RGBA and old colous
  are now supported.
- Replaced unused parameters '(void)' castings with GLib G_GNUC_UNUSED. Added
  GLib check to configure.
- Removed trailing whitespaces and corrected formatting
- Updated version numbers
- Aligned new appointment->alarm Sound and Procedure entry fields and removed
  unused code.
- Renamed 'OragePlugin *clock' to 'OragePlugin *plugin' or 'OragePlugin
  *orage_plugin'
- Fixed libical support, supported libical version is now >= 3.0.
- Added variable tmp only when HAVE_LIBICAL is not defined
- Dead code removal
- Removed outdated is_utc, libical uses UTC timezone. This patch allows to use
  libical 3.0
- Updated with 'Ical week start day' issue
- Fixed: "'Ical week start day' configuration parameter is ignored". Issue openembedded#5
- Changed version number to 4.15.2

- Translation Updates

Signed-off-by: Andreas Müller <[email protected]>
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Apr 4, 2022
* License checksum changed by polishing [1}
* Patch does not apply but took care for libical3 - see announcement below

[1] https://gitlab.xfce.org/apps/orage/-/commit/723fb89b3011db32a64986ea9ae560ae009f68fd

Release notes for 4.16.0
========================
Note: GlobalTime and Orage panel plugin are being deprecated and
will be removed in a future release. Their features will be
integrated with or provided by existing Xfce components.
See https://gitlab.xfce.org/apps/orage/-/issues/3#note_43209

Finalize port to GTK 3, small fixes and cleanup for 4.16.0 (see MRs
for more details):
- Add new application icon (!18)
- Fix some memory leaks
- i18n: Use `xfce_textdomain()` to initialize translations
- Trace messages cleanup (!15)
- Update COPYING (Issue openembedded#10, !17)
- Use stdout and stderr correctly in main.c
- Build tz_convert only with bundled libical (!14)
- Switch to reverse-DNS naming for icon and desktop files (!13)
- D-Bus service cleanup (!12)
- Fix `orage_exec()` and its calls
- Update project files (!10)
- Fixed strptime parse issue on FreeBSD (openembedded#6, !11)
- Fix make distcheck warnning
- Fixed libpopt detection on FreeBSD (!9)
- Fix build warnings 3: Clang static analyzer (!6)
- Added 'git' to program version string and 'sed' check (!7)
- Fix build warnings 2: Compilation (!4)
- Fix build warnings 1: Autotools (!3)
- Add basic GitLab pipeline (!2)

Commits from merge request !1 (GTK 3 port), which also includes
4.15.x below:
- Reverted to c60567fe
- Fixed typos
- Added support for 'legacy' non RGBA GTK colours. Both RGBA and old colous
  are now supported.
- Replaced unused parameters '(void)' castings with GLib G_GNUC_UNUSED. Added
  GLib check to configure.
- Removed trailing whitespaces and corrected formatting
- Updated version numbers
- Aligned new appointment->alarm Sound and Procedure entry fields and removed
  unused code.
- Renamed 'OragePlugin *clock' to 'OragePlugin *plugin' or 'OragePlugin
  *orage_plugin'
- Fixed libical support, supported libical version is now >= 3.0.
- Added variable tmp only when HAVE_LIBICAL is not defined
- Dead code removal
- Removed outdated is_utc, libical uses UTC timezone. This patch allows to use
  libical 3.0
- Updated with 'Ical week start day' issue
- Fixed: "'Ical week start day' configuration parameter is ignored". Issue openembedded#5
- Changed version number to 4.15.2

- Translation Updates

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, 2022
* License checksum changed by polishing [1}
* Patch does not apply but took care for libical3 - see announcement below

[1] https://gitlab.xfce.org/apps/orage/-/commit/723fb89b3011db32a64986ea9ae560ae009f68fd

Release notes for 4.16.0
========================
Note: GlobalTime and Orage panel plugin are being deprecated and
will be removed in a future release. Their features will be
integrated with or provided by existing Xfce components.
See https://gitlab.xfce.org/apps/orage/-/issues/3#note_43209

Finalize port to GTK 3, small fixes and cleanup for 4.16.0 (see MRs
for more details):
- Add new application icon (!18)
- Fix some memory leaks
- i18n: Use `xfce_textdomain()` to initialize translations
- Trace messages cleanup (!15)
- Update COPYING (Issue #10, !17)
- Use stdout and stderr correctly in main.c
- Build tz_convert only with bundled libical (!14)
- Switch to reverse-DNS naming for icon and desktop files (!13)
- D-Bus service cleanup (!12)
- Fix `orage_exec()` and its calls
- Update project files (!10)
- Fixed strptime parse issue on FreeBSD (#6, !11)
- Fix make distcheck warnning
- Fixed libpopt detection on FreeBSD (!9)
- Fix build warnings 3: Clang static analyzer (!6)
- Added 'git' to program version string and 'sed' check (!7)
- Fix build warnings 2: Compilation (!4)
- Fix build warnings 1: Autotools (!3)
- Add basic GitLab pipeline (!2)

Commits from merge request !1 (GTK 3 port), which also includes
4.15.x below:
- Reverted to c60567fe
- Fixed typos
- Added support for 'legacy' non RGBA GTK colours. Both RGBA and old colous
  are now supported.
- Replaced unused parameters '(void)' castings with GLib G_GNUC_UNUSED. Added
  GLib check to configure.
- Removed trailing whitespaces and corrected formatting
- Updated version numbers
- Aligned new appointment->alarm Sound and Procedure entry fields and removed
  unused code.
- Renamed 'OragePlugin *clock' to 'OragePlugin *plugin' or 'OragePlugin
  *orage_plugin'
- Fixed libical support, supported libical version is now >= 3.0.
- Added variable tmp only when HAVE_LIBICAL is not defined
- Dead code removal
- Removed outdated is_utc, libical uses UTC timezone. This patch allows to use
  libical 3.0
- Updated with 'Ical week start day' issue
- Fixed: "'Ical week start day' configuration parameter is ignored". Issue #5
- Changed version number to 4.15.2

- Translation Updates

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 Oct 31, 2022
Fix RDEPENDS, in particular perl-module-perlio-encoding and
perl-module-encode-encoding were needed to be able to open the database in
/usr/lib/perl5/5.36.0/vendor_perl/MIME/types.db... even though no
warnings or errors were reported.

bin/collect-types was dropped in 2.18

Upstream release notes:

version 2.22: Wed 27 Oct 16:54:38 CEST 2021

        Changes:
        - webm keeps on producting unexpected results [issue openembedded#11, Даша
	  Федорова]
        - iana updates

version 2.21: Fri 28 May 12:01:00 CEST 2021

        Changes:
        - application/octet-stream is better for .dat [issue openembedded#11, Даша
	  Федорова]
        - add video/webm which Google forgot to register [issue openembedded#12,
	  Brent Laabs]
        - add image/webp which Google registered too late [issue openembedded#12,
	  Brent Laabs]

version 2.20: Thu 22 Apr 12:48:35 CEST 2021

        Fixes:
        - problems with PAUSE cause the previous release to show-up in
          the wrong location.  Let's hope this release solves it.

        Changes:
        - heif/heic/heifs/heics/hif fix [issue openembedded#9, Даша Федорова]
        - no 'and' and 'or' extensions [issue openembedded#9, Даша Федорова]
        - application/octet-stream is better for .bin [issue openembedded#10, Даша
	  Федорова]

version 2.19: Fri 16 Apr 11:47:10 CEST 2021

        Improvements:
        - update with the newest data from IANA and Apache httpd

        Changes:
        - mp4 preference is video/mp4 [issue openembedded#5, Даша Федорова]
        - yt preference is video/vnd.youtube.yt [issue openembedded#6, Даша
	  Федорова]
        - 3gp and 3gpp preference is video/3gpp [issue openembedded#7, Даша
	  Федорова]

version 2.18: Wed  9 Dec 10:29:46 CET 2020

        Improvements:
        - update with newest data

        Changes:
        - Mojo 6.0 changed types() into mapping() [Dmitry Latin]
        - Mojo 7.94 adds experimental file_type()
        - Mojo 7.94 adds experimental content_type()

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 Mar 24, 2023
0001-configure-check-for-ns_get16-and-ns_get32-as-well.patch
Fixed-build-error-on-musl.patch
removed since they're included in 0.9.2.

Changelog:
==========
 - adenroll: set password via LDAP instead Kerberos [openembedded#27]
 - disco: fall back to LDAPS if CLDAP ping was not successful [openembedded#31]
 - tools: replace getpass() [openembedded#10]
 - adenroll: write SID before secret to Samba's db [rhbz#1991619]
 - doc: add clarification to add-member command on doc/adcli.xml
 - tools: Set umask before calling mkdtemp()
 - Avoid undefined behaviour in short option parsing
 - library: include endian.h for le32toh
 - man: Fix typos and use consistent upper case for some keywords
 - doc: avoid gnu-make specific usage of $< [openembedded#26]
 - configure: check for ns_get16 and ns_get32 as well [rhbz#1984891]
 - Add setattr and delattr options [rhbz#1690920]
 - entry: add passwd-user sub-command [rhbz#1952828]
 - Add dont-expire-password option [rhbz#1769644]
 - build: add --with-vendor-error-message configure option [rhbz#1889386]
 - tools: add show-computer command [rhbz#1737342]
 - add description option to join and update [rhbz#1737342]
 - Use GSS-SPNEGO if available [rhbz#1762420]
 - add option use-ldaps [rhbz#1762420]
 - tools: disable SSSD's locator plugin [rhbz#1762633]
 - doc: explain required AD permissions [gfo#20]
 - computer: add create-msa sub-command [rhbz#1854112}
 - Add account-disable option [gfo#21]

Signed-off-by: Wang Mingyu <[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