Re: Updating glib2.0
On 5/28/2020 7:20 AM, Achim Gratz wrote: 1. It's probably unrealistic to expect someone to adopt all the GNOME components. If such a person existed, I think we would have heard from him/her by now. Ideally that person would have some ties into the upstream development community as well. It might be worth asking there directly if anybody has any points of contact already (I don't). I'm pretty sure there's no one there (or at least no one who works on glib) who understands Cygwin. For years, Yaakov has used a "Cygwin is not win32" patch in his Cygwin build of glib2.0. About a year ago someone noticed this and patched the glib sources in an effort to capture the intent of Yaakov's patch. (They didn't just apply his patch!) They didn't get it quite right, but they made progress, and the corresponding patch needed today is much smaller than the old one. My point here is that whoever made this change had good intentions but is not qualified to be a Cygwin maintainer, even if they wanted to be. And no one else has touched that code. 2. I'm willing to adopt various components on an as-needed basis. For example, since I want to update gimp and it needs an updated glib2.0, I'm willing to adopt the latter and update it to its latest release. I've just started working on it and discovered that it needs an updated gtk-doc, so I'll plan on adopting that too. I think the current way of adopting as needed and then immediately letting it fall into orphaned status again is better than doing nothing, but eventually we'll run into troublöe with that model. If I were to adopt some of these packages, I would do it with the intention of keeping them up to date. But I'll wait to hear from Yaakov. If he thinks it's better to keep the GNOME components at their current state until someone is willing to adopt all of them, I'll go along with that. Ken
Re: Updating glib2.0
1. It's probably unrealistic to expect someone to adopt all the GNOME components. If such a person existed, I think we would have heard from him/her by now. Ideally that person would have some ties into the upstream development community as well. It might be worth asking there directly if anybody has any points of contact already (I don't). 2. I'm willing to adopt various components on an as-needed basis. For example, since I want to update gimp and it needs an updated glib2.0, I'm willing to adopt the latter and update it to its latest release. I've just started working on it and discovered that it needs an updated gtk-doc, so I'll plan on adopting that too. I think the current way of adopting as needed and then immediately letting it fall into orphaned status again is better than doing nothing, but eventually we'll run into troublöe with that model. -- Achim. (on the road :-)
Re: Updating glib2.0
On 5/23/2020 2:08 PM, Ken Brown via Cygwin-apps wrote: On 5/22/2020 7:18 PM, Ken Brown via Cygwin-apps wrote: I've been planning to adopt gimp and some related build dependencies. My reason is that I use gimp and would like to see it kept up to date. I thought I had all the prerequisites I needed. But when I built gimp, I discovered that it used two functions, g_set_weak_pointer and g_date_time_new_from_iso8601, that were introduced in glib-2.56. [gimp's configure.ac says that it only requires glib 2.54.2, but this seems to be wrong. Cygwin's glib is at 2.54.3. Fedora's is at 2.64.3, which is the latest upstream release.] I'd appreciate some advice about how to proceed. I'm not interested in adopting all of GNOME, and it probably doesn't make sense for different components of GNOME to be adopted by different people. A short-term solution (from my personal POV) would be for me to do a non-maintainer update of glib to 2.56, assuming that's doable without messing up other GNOME components. A better solution (again from my personal POV) would be for someone to adopt GNOME and update it to its latest release. To focus the discussion a little better, I've built and installed glib2.0-2.56.4. My cygport file and patches are attached. I can now build gimp-2.10.18, and it seems to run fine in limited testing. Sorry to keep replying to myself, but I have some further thoughts. 1. It's probably unrealistic to expect someone to adopt all the GNOME components. If such a person existed, I think we would have heard from him/her by now. 2. I'm willing to adopt various components on an as-needed basis. For example, since I want to update gimp and it needs an updated glib2.0, I'm willing to adopt the latter and update it to its latest release. I've just started working on it and discovered that it needs an updated gtk-doc, so I'll plan on adopting that too. 3. I don't use the GNOME desktop environment, so I am not going to adopt packages like gnome-session, gnome-flashback, etc., which I can't easily test. If no one objects, I'll continue sending ITAs and updating individual GNOME components as I need them. Ken
Re: Updating glib2.0
On 5/22/2020 7:18 PM, Ken Brown via Cygwin-apps wrote: I've been planning to adopt gimp and some related build dependencies. My reason is that I use gimp and would like to see it kept up to date. I thought I had all the prerequisites I needed. But when I built gimp, I discovered that it used two functions, g_set_weak_pointer and g_date_time_new_from_iso8601, that were introduced in glib-2.56. [gimp's configure.ac says that it only requires glib 2.54.2, but this seems to be wrong. Cygwin's glib is at 2.54.3. Fedora's is at 2.64.3, which is the latest upstream release.] I'd appreciate some advice about how to proceed. I'm not interested in adopting all of GNOME, and it probably doesn't make sense for different components of GNOME to be adopted by different people. A short-term solution (from my personal POV) would be for me to do a non-maintainer update of glib to 2.56, assuming that's doable without messing up other GNOME components. A better solution (again from my personal POV) would be for someone to adopt GNOME and update it to its latest release. To focus the discussion a little better, I've built and installed glib2.0-2.56.4. My cygport file and patches are attached. I can now build gimp-2.10.18, and it seems to run fine in limited testing. Ken Fix for -Werror=nested-externs --- origsrc/glib-2.34.3/m4macros/glib-gettext.m42012-11-20 08:27:12.0 -0600 +++ src/glib-2.34.3/m4macros/glib-gettext.m42013-04-15 02:04:25.707401500 -0500 @@ -222,8 +222,8 @@ msgstr "" AC_PATH_PROG(GMSGFMT, gmsgfmt, $MSGFMT) GLIB_PATH_PROG_WITH_TEST(XGETTEXT, xgettext, [test -z "`$ac_dir/$ac_word -h 2>&1 | grep '(HELP)'`"], :) - AC_TRY_LINK(, [extern int _nl_msg_cat_cntr; -return _nl_msg_cat_cntr], + AC_TRY_LINK([extern int _nl_msg_cat_cntr;], + [return _nl_msg_cat_cntr], [CATOBJEXT=.gmo DATADIRNAME=share], [case $host in --- origsrc/glib-2.36.3/configure.ac2013-08-04 20:21:20.808722600 -0500 +++ src/glib-2.36.3/configure.ac2013-08-04 18:30:21.852852200 -0500 @@ -1880,7 +1880,7 @@ dnl AC_MSG_CHECKING(for platform-dependent source) case "$host" in - *-*-cygwin*|*-*-mingw*) + *-*-mingw*) PLATFORMDEP=gwin32.lo ;; *) @@ -2594,9 +2594,6 @@ dnl *** Win32 API libs *** dnl ** case $host in - *-*-cygwin*) - G_LIBS_EXTRA="-luser32 -lkernel32" -;; *-*-mingw*) G_LIBS_EXTRA="-lws2_32 -lole32 -lwinmm -lshlwapi" ;; --- origsrc/glib-2.36.3/docs/reference/gio/Makefile.am 2013-08-04 20:21:20.849725000 -0500 +++ src/glib-2.36.3/docs/reference/gio/Makefile.am 2013-08-04 18:11:14.0 -0500 @@ -77,6 +77,8 @@ IGNORE_HFILES = \ gunixvolume.h \ gunixvolumemonitor.h\ gwin32appinfo.h \ + gwin32inputstream.h \ + gwin32outputstream.h\ gwin32mount.h \ gwin32resolver.h\ gwin32volumemonitor.h --- origsrc/glib-2.36.3/gio/giomodule-priv.h2013-08-04 20:21:20.877726600 -0500 +++ src/glib-2.36.3/gio/giomodule-priv.h2013-08-04 18:11:14.0 -0500 @@ -39,7 +39,7 @@ GType_g_io_module_get_default_type ( const gchar *envvar, guintis_supported_offset); -#ifdef G_PLATFORM_WIN32 +#ifdef G_OS_WIN32 void *_g_io_win32_get_module (void); #endif --- origsrc/glib-2.36.3/gio/giomodule.c 2013-08-04 20:21:20.886727100 -0500 +++ src/glib-2.36.3/gio/giomodule.c 2013-08-04 18:11:14.0 -0500 @@ -894,7 +894,7 @@ extern GType g_network_monitor_base_get_ extern GType _g_network_monitor_netlink_get_type (void); #endif -#ifdef G_PLATFORM_WIN32 +#ifdef G_OS_WIN32 #include --- origsrc/glib-2.36.3/gio/tests/live-g-file.c 2013-08-04 20:21:20.898727800 -0500 +++ src/glib-2.36.3/gio/tests/live-g-file.c 2013-08-04 18:11:14.0 -0500 @@ -1282,7 +1282,7 @@ main (int argc, char *argv[]) write_test = TRUE; only_create_struct = FALSE; target_path = DEFAULT_TEST_DIR; -#ifdef G_PLATFORM_WIN32 +#ifdef G_OS_WIN32 posix_compat = FALSE; #else posix_compat = TRUE; --- origsrc/glib-2.36.3/glib/gatomic.c 2013-08-04 20:21:20.907728300 -0500 +++ src/glib-2.36.3/glib/gatomic.c 2013-08-04 18:11:14.0 -0500 @@ -464,7 +464,7 @@ gsize return g_atomic_pointer_xor ((volatile gpointer *) atomic, val); } -#elif defined (G_PLATFORM_WIN32) +#elif defined (G_OS_WIN32) #include #if !defined(_M_AMD64) && !defined (_M_IA64) && !defined(_M_X64) && !(defined _MSC_VER && _MSC_VER <= 1200) --- origsrc/glib-2.36.3/glib/gcharset.c 2013-08-04 20:21:20.925729300 -0500 +++ src/glib-2.36.3/glib/gcharset.c 2013-08-04 18:11:14.0
Updating glib2.0
I've been planning to adopt gimp and some related build dependencies. My reason is that I use gimp and would like to see it kept up to date. I thought I had all the prerequisites I needed. But when I built gimp, I discovered that it used two functions, g_set_weak_pointer and g_date_time_new_from_iso8601, that were introduced in glib-2.56. [gimp's configure.ac says that it only requires glib 2.54.2, but this seems to be wrong. Cygwin's glib is at 2.54.3. Fedora's is at 2.64.3, which is the latest upstream release.] I'd appreciate some advice about how to proceed. I'm not interested in adopting all of GNOME, and it probably doesn't make sense for different components of GNOME to be adopted by different people. A short-term solution (from my personal POV) would be for me to do a non-maintainer update of glib to 2.56, assuming that's doable without messing up other GNOME components. A better solution (again from my personal POV) would be for someone to adopt GNOME and update it to its latest release. Ken
