package/libglib2: bump version to 2.70.0
PATCH 1/2 package/libglib2: bump version to 2.70.0
The internal_pcre option was dropped in:
https://gitlab.gnome.org/GNOME/glib/-/commit/9fbd7f3dc1f029b64b6991a540402b2bfa98de5c
--- package/libglib2/0002-remove-cpp-requirement.patch | 2 +- package/libglib2/libglib2.hash | 4 ++-- package/libglib2/libglib2.mk | 6 ++---- 3 files changed, 5 insertions(+), 7 deletions(-)
package/libglib2/0002-remove-cpp-requirement.patch +1 -1
@@ -35,7 +35,7 @@ index 4bbf4c2..ac59f4e 100644 @@ -1,4 +1,4 @@ -project('glib', 'c', 'cpp', +project('glib', 'c', - version : '2.68.4', + version : '2.70.0', # NOTE: We keep this pinned at 0.49 because that's what Debian 10 ships meson_version : '>= 0.49.2', @@ -10,7 +10,6 @@ project('glib', 'c', 'cpp',
package/libglib2/libglib2.hash +2 -2
@@ -1,4 +1,4 @@ -# https://download.gnome.org/sources/glib/2.68/glib-2.68.4.sha256sum -sha256 62fd061d08a75492617e625a73e2c05e259f831acbb8e1f8b9c81f23f7993a3b glib-2.68.4.tar.xz +# https://download.gnome.org/sources/glib/2.70/glib-2.70.0.sha256sum +sha256 200d7df811c5ba634afbf109f14bb40ba7fde670e89389885da14e27c0840742 glib-2.70.0.tar.xz # License files, locally calculated sha256 dc626520dcd53a22f727af3ee42c770e56c97a64fe3adb063799d8ab032fe551 COPYING
package/libglib2/libglib2.mk +2 -4
@@ -4,8 +4,8 @@ # ################################################################################ -LIBGLIB2_VERSION_MAJOR = 2.68 -LIBGLIB2_VERSION = $(LIBGLIB2_VERSION_MAJOR).4 +LIBGLIB2_VERSION_MAJOR = 2.70 +LIBGLIB2_VERSION = $(LIBGLIB2_VERSION_MAJOR).0 LIBGLIB2_SOURCE = glib-$(LIBGLIB2_VERSION).tar.xz LIBGLIB2_SITE = http://ftp.gnome.org/pub/gnome/sources/glib/$(LIBGLIB2_VERSION_MAJOR) LIBGLIB2_LICENSE = LGPL-2.1+
@@ -30,7 +30,6 @@ HOST_LIBGLIB2_CONF_OPTS = \ -Dselinux=disabled \ -Dsystemtap=false \ -Dxattr=false \ - -Dinternal_pcre=false \ -Dtests=false \ -Doss_fuzz=disabled
@@ -52,7 +51,6 @@ HOST_LIBGLIB2_DEPENDENCIES = \ # bogus installation path once combined with $(DESTDIR). LIBGLIB2_CONF_OPTS = \ -Dglib_debug=disabled \ - -Dinternal_pcre=false \ -Dlibelf=disabled \ -Dgio_module_dir=/usr/lib/gio/modules \ -Dtests=false \
Signature · 6 lines
2.17.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH 2/2 package/libsoup: add choice between libsoup2 and libsoup3
Libsoup3 has a new API [1], packages using libsoup2 may not compile with libsoup3 or may crash at runtime in unexpected ways. So the default will (for now) stay on libsoup2. A tracking table for the migration can be found here [2].
Changes for libsoup3:
- "0001-meson.build-set-c_std-to-gnu99.patch" is upstream now [3].
- The "gnome" option was dropped in [4].
- A new "libnghttp2" dependency is added since libsoup 2.99.6 (HTTP2 backend) [5].
[1] https://libsoup.org/libsoup-3.0/ch02.html
[2] https://gitlab.gnome.org/GNOME/libsoup/-/issues/218
[3] https://gitlab.gnome.org/GNOME/libsoup/-/commit/5c3d431bdb094c59997f2a23e31e83f815ab667c
[4] https://gitlab.gnome.org/GNOME/libsoup/-/commit/3fcaa882c4eb29fd754cdb6dd06195632cb4b52a
[5] https://gitlab.gnome.org/GNOME/libsoup/-/commit/1a1d29c3114ca86c673d0c0b02a492d0962dcfe8
---
.../0001-meson.build-set-c_std-to-gnu99.patch | 0
package/libsoup/Config.in | 16 ++++++++++++++++
package/libsoup/libsoup.hash | 2 ++
package/libsoup/libsoup.mk | 11 +++++++++++
4 files changed, 29 insertions(+)
rename package/libsoup/{ => 2.74.0}/0001-meson.build-set-c_std-to-gnu99.patch (100%)package/libsoup/2.74.0/0001-meson.build-set-c_std-to-gnu99.patch renamed from package/libsoup/0001-meson.build-set-c_std-to-gnu99.patch +0 -0
package/libsoup/Config.in +16 -0
@@ -16,8 +16,24 @@ config BR2_PACKAGE_LIBSOUP if BR2_PACKAGE_LIBSOUP +choice + prompt "libsoup version" + default BR2_PACKAGE_LIBSOUP_VERSION_2 + help + Select the version of libsoup you wish to use. + +config BR2_PACKAGE_LIBSOUP_VERSION_3 + select BR2_PACKAGE_NGHTTP2 + bool "libsoup3" + +config BR2_PACKAGE_LIBSOUP_VERSION_2 + bool "libsoup2" + +endchoice + config BR2_PACKAGE_LIBSOUP_GNOME bool "libsoup-gnome" + depends on BR2_PACKAGE_LIBSOUP_VERSION_2 help Build libsoup-gnome library.
package/libsoup/libsoup.hash +2 -0
@@ -1,3 +1,5 @@ +# From https://ftp.gnome.org/pub/GNOME/sources/libsoup/3.0/libsoup-3.0.0.sha256sum +sha256 cde05f3e20114ce985cbd03d575ff74e5e41e70a218e5eb3068c4bf4710dbf2b libsoup-3.0.0.tar.xz # From https://ftp.gnome.org/pub/GNOME/sources/libsoup/2.74/libsoup-2.74.0.sha256sum sha256 33b1d4e0d639456c675c227877e94a8078d731233e2d57689c11abcef7d3c48e libsoup-2.74.0.tar.xz # Locally calculated
package/libsoup/libsoup.mk +11 -0
@@ -4,8 +4,13 @@ # ################################################################################ +ifeq ($(BR2_PACKAGE_LIBSOUP_VERSION_3),y) +LIBSOUP_VERSION_MAJOR = 3.0 +LIBSOUP_VERSION = $(LIBSOUP_VERSION_MAJOR).0 +else LIBSOUP_VERSION_MAJOR = 2.74 LIBSOUP_VERSION = $(LIBSOUP_VERSION_MAJOR).0 +endif LIBSOUP_SOURCE = libsoup-$(LIBSOUP_VERSION).tar.xz LIBSOUP_SITE = http://ftp.gnome.org/pub/gnome/sources/libsoup/$(LIBSOUP_VERSION_MAJOR) LIBSOUP_LICENSE = LGPL-2.0+
@@ -55,10 +60,16 @@ else LIBSOUP_CONF_OPTS += -Dgssapi=disabled endif +ifeq ($(BR2_PACKAGE_LIBSOUP_VERSION_2),y) ifeq ($(BR2_PACKAGE_LIBSOUP_GNOME),y) LIBSOUP_CONF_OPTS += -Dgnome=true else LIBSOUP_CONF_OPTS += -Dgnome=false endif +endif + +ifeq ($(BR2_PACKAGE_LIBSOUP_VERSION_3),y) +LIBSOUP_DEPENDENCIES += nghttp2 +endif $(eval $(meson-package))
Signature · 6 lines
2.17.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 2/2] package/libsoup: add choice between libsoup2 and libsoup3
Hello Thomas,
Thanks for your patch.
Quoted 4 lines · On Sat, 29 Jan 2022 22:42:35 +0100 Thomas Devoogdt <[email protected]>…
Libsoup3 has a new API [1], packages using libsoup2 may not compile with libsoup3 or may crash at runtime in unexpected ways. So the default will (for now) stay on libsoup2. A tracking table for the migration can be found here [2].
A "choice" is not going to work well, as it means that in a given configuration we will only be able to install either packages that need libsoup2 *or* packages that libsoup3, bit not a mix of both.
Is it possible to install both libsoup2 and libsoup3 side-by-side in the same system? This requires them having a different library name and a different location for header files.
If that's the case, we will definitely want to have a separate libsoup3 package, so that we can install libsoup and libsoup3 side by side in the same system.
Best regards,
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 2/2] package/libsoup: add choice between libsoup2 and libsoup3
Hi Thomas, Thomas, and all,
Quoted 10 lines · On Sun, 30 Jan 2022 15:49:08 +0100 Thomas Petazzoni via buildroot…
Thanks for your patch.
Quoted 4 lines · On Sat, 29 Jan 2022 22:42:35 +0100 Thomas Devoogdt <[email protected]>…
Libsoup3 has a new API [1], packages using libsoup2 may not compile with libsoup3 or may crash at runtime in unexpected ways. So the default will (for now) stay on libsoup2. A tracking table for the migration can be found here [2].
Quoted 7 lines
A "choice" is not going to work well, as it means that in a given configuration we will only be able to install either packages that need libsoup2 *or* packages that libsoup3, bit not a mix of both.
Is it possible to install both libsoup2 and libsoup3 side-by-side in the same system? This requires them having a different library name and a different location for header files.
Yes, libsoup2 and libsoup3 are parallel-installable, both can coexist in the same system. The only caveat is, as I mentioned in a previous email, that having both versions loaded in the same process will result in odd crashes and assorted failures due to symbols clashing.
Quoted 3 lines
If that's the case, we will definitely want to have a separate libsoup3 package, so that we can install libsoup and libsoup3 side by side in the same system.
Yes, I think we may need to have a separate libsoup2 package. While most “big” packages are already supporting libsoup3 (or will soon), probably others (like gupnp) may take longer and allowing to continue building them with libsoup2 would be a good ide.
Cheers,
—Adrián
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 2/2] package/libsoup: add choice between libsoup2 and libsoup3
Quoted 8 lines · On Mon, 31 Jan 2022 00:02:21 +0200 Adrian Perez de Castro <[email protected]>…
Quoted 3 lines
Is it possible to install both libsoup2 and libsoup3 side-by-side in the same system? This requires them having a different library name and a different location for header files.
Yes, libsoup2 and libsoup3 are parallel-installable, both can coexist in the same system. The only caveat is, as I mentioned in a previous email, that having both versions loaded in the same process will result in odd crashes and assorted failures due to symbols clashing.
If both libsoup2 and libsoup3 are enabled in the same build, it's going to be difficult to guarantee that one application doesn't end up loading both, by the usage of separate shared libraries that independently use a different version of libsoup.
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 2/2] package/libsoup: add choice between libsoup2 and libsoup3
Hi Adrián, Thomas, and all,
Adrián:
Quoted 4 lines
Yes, libsoup2 and libsoup3 are parallel-installable, both can coexist in the same system. The only caveat is, as I mentioned in a previous email, that having both versions loaded in the same process will result in odd crashes and assorted failures due to symbols clashing.
Thomas:
Quoted 4 lines
If both libsoup2 and libsoup3 are enabled in the same build, it's going to be difficult to guarantee that one application doesn't end up loading both, by the usage of separate shared libraries that independently use a different version of libsoup.
After reading all those opinions, do we need to go that path?
- From what I see, most packages do not yet support libsoup3.
- Packages that do, will also support libsoup2 for a while.
So why not proceed whit libsoup2 as default, but allow to select libsoup3. We can explicitly mark some packages with depends on !BR2_PACKAGE_LIBSOUP_VERSION_3.
By this, developers can at least start integrating libsoup3 in their custom packages.
I didn't add depends on !BR2_PACKAGE_LIBSOUP_VERSION_3 to this path yet. I think that such flags should be added by the respective package maintainers (in the next bump cycle).
--> For me, libsoup3 support is important for the additional APIs that webkitgtk 2.34.4 is providing.
kr,
Thomas
Op zo 30 jan. 2022 om 23:17 schreef Thomas Petazzoni < [email protected]>:
Quoted 17 lines
Quoted 8 lines · On Mon, 31 Jan 2022 00:02:21 +0200 Adrian Perez de Castro <[email protected]>…
Quoted 3 lines
Is it possible to install both libsoup2 and libsoup3 side-by-side in the same system? This requires them having a different library name and a different location for header files.
Yes, libsoup2 and libsoup3 are parallel-installable, both can coexist in the same system. The only caveat is, as I mentioned in a previous email, that having both versions loaded in the same process will result in odd crashes and assorted failures due to symbols clashing.
If both libsoup2 and libsoup3 are enabled in the same build, it's going to be difficult to guarantee that one application doesn't end up loading both, by the usage of separate shared libraries that independently use a different version of libsoup.
Quoted 6 lines
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 2/2] package/libsoup: add choice between libsoup2 and libsoup3
In reply to Thomas DevoogdtThomas, All,
On 2022-01-29 22:42 +0100, Thomas Devoogdt spake thusly:
Quoted 4 lines
Libsoup3 has a new API [1], packages using libsoup2 may not compile with libsoup3 or may crash at runtime in unexpected ways. So the default will (for now) stay on libsoup2. A tracking table for the migration can be found here [2].
Seeing the comment by Peter on a previous iteration [0]...
I investigated a bit, and found that both libsoup2 and libsoup3 will detect one another and explicitly fail; these are commits:
- 9596a869414b Detect if libsoup2 is loaded in the same process at init
- e7f842c35e97 Error when libsoup3 is detected as already loaded in the same process
Also, I've checked, and the includes are instaleld in different directories and shared libraries have different filenames and SONAMES.
So, in case both are enabeld at the same time, what would fail is only trhe case of a package loading one or the other via a third-party shared library, e.g.:
my-exec -> libA -> libsoup2
`-> libsoup3(or the other way around, or both through a library).
I don't think that is going to be a very common situation.
So, I think we should introduce libsoup3 as a different package. We have only 10 packages in Buildroot that use libsoup, with the following status (also looking at [2])
- gmpc: 2.4 only
- gssdp: should be 3.0 compatible since e3598a582783 (ci: Track libsoup master again) which is a few days old, so not in a relase yet (but at least, we could backport something...)
- gst1-plugins-good: it should be in-tree with c3455def2e7b (soup:
Runtime compatibility support for libsoup2 and libsoup3)
- gstd-1.x: 2.4 only
- gupnp-tools: 3.0 only since 09dfcdc65568 (Merge branch 'wip/gupnp-1.6' into 'master') and 7ee5fd9beb04 (Port to GUPnP 1.6 and libsoup 3), but no release yet.
- gvfs: 2.4 only for now
- libostree: 2.4 only
- midori: uses webkitgtk, so I expect like webkitgtk?
- webkitgtk: you seemed to imply that was OK [1]?
- wpewebkit: this being webkit stuff, I would guess OK like webkitgtk?
So, the only one I can see conflicting is gstd: it links with libsoup3, but I expect it also links or loads gstreamer libs or plugins, so there will be a conflict.
So, if we need libsoup3 for a package that has no libsoup2 support, then I think we should introduce a separate package. If we do not yet have a need for libsoup3, let's postpone the introdution of it.
[0] https://lore.kernel.org/buildroot/[email protected]/
[1] https://lore.kernel.org/buildroot/CACXRmJjSOrww35YVVmkg_DEHDaG3ngQts4obTeDUsfsigM4cBQ@mail.gmail.com/
[2] https://gitlab.gnome.org/GNOME/libsoup/-/issues/218
Regards,
Yann E. MORIN.
Quoted 105 lines
Changes for libsoup3:
- "0001-meson.build-set-c_std-to-gnu99.patch" is upstream now [3].
- The "gnome" option was dropped in [4].
- A new "libnghttp2" dependency is added since libsoup 2.99.6 (HTTP2 backend) [5].[1] https://libsoup.org/libsoup-3.0/ch02.html
[2] https://gitlab.gnome.org/GNOME/libsoup/-/issues/218
[3] https://gitlab.gnome.org/GNOME/libsoup/-/commit/5c3d431bdb094c59997f2a23e31e83f815ab667c
[4] https://gitlab.gnome.org/GNOME/libsoup/-/commit/3fcaa882c4eb29fd754cdb6dd06195632cb4b52a
[5] https://gitlab.gnome.org/GNOME/libsoup/-/commit/1a1d29c3114ca86c673d0c0b02a492d0962dcfe8Signed-off-by Thomas Devoogdt <[email protected]>--- .../0001-meson.build-set-c_std-to-gnu99.patch | 0 package/libsoup/Config.in | 16 ++++++++++++++++ package/libsoup/libsoup.hash | 2 ++ package/libsoup/libsoup.mk | 11 +++++++++++ 4 files changed, 29 insertions(+) rename package/libsoup/{ => 2.74.0}/0001-meson.build-set-c_std-to-gnu99.patch (100%)package/libsoup/2.74.0/0001-meson.build-set-c_std-to-gnu99.patch renamed from package/libsoup/0001-meson.build-set-c_std-to-gnu99.patch +0
-0package/libsoup/Config.in +16
-0@@ -16,8 +16,24 @@ config BR2_PACKAGE_LIBSOUP if BR2_PACKAGE_LIBSOUP +choice + prompt "libsoup version" + default BR2_PACKAGE_LIBSOUP_VERSION_2 + help + Select the version of libsoup you wish to use. + +config BR2_PACKAGE_LIBSOUP_VERSION_3 + select BR2_PACKAGE_NGHTTP2 + bool "libsoup3" + +config BR2_PACKAGE_LIBSOUP_VERSION_2 + bool "libsoup2" + +endchoice + config BR2_PACKAGE_LIBSOUP_GNOME bool "libsoup-gnome" + depends on BR2_PACKAGE_LIBSOUP_VERSION_2 help Build libsoup-gnome library.package/libsoup/libsoup.hash +2
-0@@ -1,3 +1,5 @@ +# From https://ftp.gnome.org/pub/GNOME/sources/libsoup/3.0/libsoup-3.0.0.sha256sum +sha256 cde05f3e20114ce985cbd03d575ff74e5e41e70a218e5eb3068c4bf4710dbf2b libsoup-3.0.0.tar.xz # From https://ftp.gnome.org/pub/GNOME/sources/libsoup/2.74/libsoup-2.74.0.sha256sum sha256 33b1d4e0d639456c675c227877e94a8078d731233e2d57689c11abcef7d3c48e libsoup-2.74.0.tar.xz # Locally calculatedpackage/libsoup/libsoup.mk +11
-0@@ -4,8 +4,13 @@ # ################################################################################ +ifeq ($(BR2_PACKAGE_LIBSOUP_VERSION_3),y) +LIBSOUP_VERSION_MAJOR = 3.0 +LIBSOUP_VERSION = $(LIBSOUP_VERSION_MAJOR).0 +else LIBSOUP_VERSION_MAJOR = 2.74 LIBSOUP_VERSION = $(LIBSOUP_VERSION_MAJOR).0 +endif LIBSOUP_SOURCE = libsoup-$(LIBSOUP_VERSION).tar.xz LIBSOUP_SITE = http://ftp.gnome.org/pub/gnome/sources/libsoup/$(LIBSOUP_VERSION_MAJOR) LIBSOUP_LICENSE = LGPL-2.0+@@ -55,10 +60,16 @@ else LIBSOUP_CONF_OPTS += -Dgssapi=disabled endif +ifeq ($(BR2_PACKAGE_LIBSOUP_VERSION_2),y) ifeq ($(BR2_PACKAGE_LIBSOUP_GNOME),y) LIBSOUP_CONF_OPTS += -Dgnome=true else LIBSOUP_CONF_OPTS += -Dgnome=false endif +endif + +ifeq ($(BR2_PACKAGE_LIBSOUP_VERSION_3),y) +LIBSOUP_DEPENDENCIES += nghttp2 +endif $(eval $(meson-package))Signature · 6 lines
2.17.1 _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Signature · 10 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Thomas Petazzoni via buildroot
AppliedQuoted 9 lines · On Sat, 29 Jan 2022 22:42:34 +0100 Thomas Devoogdt <[email protected]>…
The
internal_pcreoption was dropped in:
https://gitlab.gnome.org/GNOME/glib/-/commit/9fbd7f3dc1f029b64b6991a540402b2bfa98de5cSigned-off-by Thomas Devoogdt <[email protected]>--- package/libglib2/0002-remove-cpp-requirement.patch | 2 +- package/libglib2/libglib2.hash | 4 ++-- package/libglib2/libglib2.mk | 6 ++---- 3 files changed, 5 insertions(+), 7 deletions(-)
I've applied, thanks!
It would be nice if you could watch http://autobuild.buildroot.net/ in the next few days and see if there are any failures related to libglib2 (note: failures can happen in other packages that libglib2), as major updates of libglib2 have several times caused breakage.
Thanks!
Thomas
Signature · 7 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Hi Thomas, All,
Quoted 1 line
It's a bit difficult to follow http://autobuild.buildroot.net/, but I saw one thing when doing a quick scan:
bluez5_utils:
http://autobuild.buildroot.net/results/5c7/5c75ad724df3ff726559acee0da31f777ef6bc68/build-end.log
--> g_memdup, deprecated since 2.68:
https://docs.gtk.org/glib/func.memdup.html
Kr,
Thomas
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Hi,
Quoted 9 lines · Thomas Devoogdt
Hi Thomas, All,
It's a bit difficult to follow http://autobuild.buildroot.net/, but I saw one thing when doing a quick scan:
bluez5_utils: http://autobuild.buildroot.net/results/5c7/5c75ad724df3ff726559acee0da31f777ef6bc68/build-end.log
-->g_memdup, deprecated since 2.68: https://docs.gtk.org/glib/func.memdup.html
You can also add this one:
- libblockdev: http://autobuild.buildroot.net/results/2fd/2fd1b4001b64004be49dd91329945ab108e1a90c/build-end.log
exec.c: In function 'bd_utils_exec_and_report_status_error':
exec.c:239:5: error: 'g_spawn_check_exit_status' is deprecated: Use 'g_spawn_check_wait_status' instead [-Werror=deprecated-declarations]
239 | if (!g_spawn_check_exit_status (exit_status, error)) {
| ^~Quoted 4 lines
Kr,
Thomas
Best Regards,
Fabrice
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot