Re: [gtk-osx-users] Announcement: this mailing list will be retired by the end of Oct 2022

[Andrea Veri]

Hi,

I’ve received several questions during the past days which possibly makes
sense to summarize in a single topic [1] which I can then reference.
Hopefully this specific post will help anyone looking for the same set of
answers as well. If any additional common question arises I’ll make sure to
add it to this same topic in Discourse.

Thanks and please let us know if you have any questions around Discourse or
your onboarding process!

[1]
https://discourse.gnome.org/t/common-questions-re-mailman-to-discourse/11841


On Thu, Oct 20, 2022 at 1:09 PM Andrea Veri  wrote:

> Hi,
>
> As we have been communicating during the past few months GNOME's Mailman
> platform is being decommissioned (python2 deprecation, major burden in
> managing lists spam). The deadline is currently set to the end of October
> 2022. Mailing list subscribers are invited to migrate to GNOME's Discourse
> instance [1]. Neil made sure [2] to create a set of tags you can re-use to
> initiate a new topic in the new platform, if a tag is missing please reach
> out to me directly.
>
> Jehan (from the GIMP Team) kindly provided some instructions you can
> follow [3] in order to safely migrate your reading workflow to Discourse.
> The new platform supports several login methods including your GNOME
> Account and other major OpenID providers.
>
> After the deadline of the end of October Mailman archives will remain
> alive in read only mode for posterity. If the mailing list was used behind
> an alias, please let me know so we can re-do the same setup but on
> Discourse instead.
>
> Thanks,
>
> P.S All the l10n lists are still pending code changes in damned-lies, the
> deadline to decommission those lists may slip by a week or two depending
> how soon those changes will be made available in DL codebase
>
> [1] https://discourse.gnome.org
> [2]
> https://mail.gnome.org/archives/desktop-devel-list/2022-September/msg00018.html
> [3]
> https://discourse.gnome.org/t/welcome-to-gimp-forum-on-gnome-discourse/11534/5
>
> --
> Cheers,
> Andrea
>
> Principal Systems Engineer at Red Hat,
> GNOME Infrastructure Team Coordinator,
> Former GNOME Foundation Board of Directors Secretary,
> GNOME Foundation Membership & Elections Committee Chairman
>
> Homepage: https://www.dragonsreach.it
>


-- 
Cheers,
Andrea

Principal Systems Engineer at Red Hat,
GNOME Infrastructure Team Coordinator,
Former GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: https://www.dragonsreach.it
___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-devel] Announcement: this mailing list will be retired by the end of Oct 2022

[Andrea Veri]

Hi,

I’ve received several questions during the past days which possibly makes
sense to summarize in a single topic [1] which I can then reference.
Hopefully this specific post will help anyone looking for the same set of
answers as well. If any additional common question arises I’ll make sure to
add it to this same topic in Discourse.

Thanks and please let us know if you have any questions around Discourse or
your onboarding process!

[1]
https://discourse.gnome.org/t/common-questions-re-mailman-to-discourse/11841


On Thu, Oct 20, 2022 at 1:09 PM Andrea Veri  wrote:

> Hi,
>
> As we have been communicating during the past few months GNOME's Mailman
> platform is being decommissioned (python2 deprecation, major burden in
> managing lists spam). The deadline is currently set to the end of October
> 2022. Mailing list subscribers are invited to migrate to GNOME's Discourse
> instance [1]. Neil made sure [2] to create a set of tags you can re-use to
> initiate a new topic in the new platform, if a tag is missing please reach
> out to me directly.
>
> Jehan (from the GIMP Team) kindly provided some instructions you can
> follow [3] in order to safely migrate your reading workflow to Discourse.
> The new platform supports several login methods including your GNOME
> Account and other major OpenID providers.
>
> After the deadline of the end of October Mailman archives will remain
> alive in read only mode for posterity. If the mailing list was used behind
> an alias, please let me know so we can re-do the same setup but on
> Discourse instead.
>
> Thanks,
>
> P.S All the l10n lists are still pending code changes in damned-lies, the
> deadline to decommission those lists may slip by a week or two depending
> how soon those changes will be made available in DL codebase
>
> [1] https://discourse.gnome.org
> [2]
> https://mail.gnome.org/archives/desktop-devel-list/2022-September/msg00018.html
> [3]
> https://discourse.gnome.org/t/welcome-to-gimp-forum-on-gnome-discourse/11534/5
>
> --
> Cheers,
> Andrea
>
> Principal Systems Engineer at Red Hat,
> GNOME Infrastructure Team Coordinator,
> Former GNOME Foundation Board of Directors Secretary,
> GNOME Foundation Membership & Elections Committee Chairman
>
> Homepage: https://www.dragonsreach.it
>


-- 
Cheers,
Andrea

Principal Systems Engineer at Red Hat,
GNOME Infrastructure Team Coordinator,
Former GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: https://www.dragonsreach.it
___
gtk-osx-devel-list mailing list
gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: [gtk-osx-users] These mailing lists will be closed.

[jralls]

Emmanuele,

Neil Gorman's email didn't even suggest that was an option. He published two 
lists: Mailing lists deemed worthy of migration to Discourse and those deemed 
unworthy. These were on the unworthy list.

I'm sure you know from lurking here for several years that the topic here is 
mostly the gtk-osx modulesets with occasional visits to gtk-mac-integration and 
gtk-mac-bundler. I've generally pushed anything involving Gtk itself to the 
appropriate place, though that hasn't come up in a long time. That won't change 
even though the venue does.

Meson is a nice build system, but not all projects are able to migrate to it; 
some teams might even like something else better. There are a lot of projects, 
even in Gnome Core, that have dependencies that don't build with meson, so 
subprojects aren't an option. jhbuild, for better or worse, remains the most 
flexible and easy to use build-from-source package manager.(Other contenders: 
paceman, BSD ports, and emerge; all are harder to use and have more overhead.)

Regards,
John Ralls

> On Sep 29, 2022, at 1:38 PM, Emmanuele Bassi  wrote:
> 
> I wished you contacted the Discourse mods, or the rest of the GTK developers…
> 
> In any case:
> 
> - there is a macos tag on discourse.gnome.org  
> already: https://discourse.gnome.org/tag/macos
> - you can subscribe to that tag if you are only interested on GTK on macos
> 
> In general, if you want to ask questions about GTK, and GTK on macOS, then 
> feel free to use Discourse.
> 
> I assume the gtk-osx-build discussion on GitHub will be useful for questions 
> related to using jhbuild with the gtk-osx moduleset.
> 
> As a side note: GTK4 gets built and tested on macOS using Meson and 
> subprojects—similarly to how we build GTK4 using MSVC on Windows. If you are 
> targeting GTK4, or you're planning to, the GTK team recommends using the 
> Meson build system, and adding GTK as a subproject.
> 
> Ciao,
>  Emmanuele.
> 
> 
> On Thu, 29 Sept 2022 at 18:18,  > wrote:
>> The Gnome foundation that hosts these mailing lists has decided that they 
>> are too low traffic to justify their continued existence or even to migrate 
>> to Gnome Discourse. Without specialization Discourse is way too noisy to be 
>> useful so I've enabled https://github.com/jralls/gtk-osx-build/discussions 
>> to replace these lists. 
>> 
>> Regards,
>> John Ralls
>> 
>> ___
>> gtk-osx-users-list mailing list
>> gtk-osx-users-list@gnome.org 
>> https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
> 
> 
> -- 
> https://www.bassi.io 
> [@] ebassi [@gmail.com ]

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] These mailing lists will be closed.

[Emmanuele Bassi via gtk-osx-users-list]

I wished you contacted the Discourse mods, or the rest of the GTK
developers…

In any case:

- there is a macos tag on discourse.gnome.org already:
https://discourse.gnome.org/tag/macos
- you can subscribe to that tag if you are only interested on GTK on macos

In general, if you want to ask questions about GTK, and GTK on macOS, then
feel free to use Discourse.

I assume the gtk-osx-build discussion on GitHub will be useful for
questions related to using jhbuild with the gtk-osx moduleset.

As a side note: GTK4 gets built and tested on macOS using Meson and
subprojects—similarly to how we build GTK4 using MSVC on Windows. If you
are targeting GTK4, or you're planning to, the GTK team recommends using
the Meson build system, and adding GTK as a subproject.

Ciao,
 Emmanuele.


On Thu, 29 Sept 2022 at 18:18,  wrote:

> The Gnome foundation that hosts these mailing lists has decided that they
> are too low traffic to justify their continued existence or even to migrate
> to Gnome Discourse. Without specialization Discourse is way too noisy to be
> useful so I've enabled https://github.com/jralls/gtk-osx-build/discussions to
> replace these lists.
>
> Regards,
> John Ralls
>
> ___
> gtk-osx-users-list mailing list
> gtk-osx-users-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] ITSTool building error with Python built before.

[jralls]

> On Sep 5, 2022, at 1:21 PM, Pascal  wrote:
> 
>> 
>> Le 5 sept. 2022 à 06:38, jra...@ceridwen.fremont.ca.us a écrit :
>> 
>>> On Sep 4, 2022, at 12:04 PM, Pascal  wrote:
>>> 
 Le 1 sept. 2022 à 03:06, john  a écrit :
 
> On Aug 31, 2022, at 3:18 AM, Pascal  wrote:
> 
>> Le 30 août 2022 à 18:18, john  a écrit :
>> 
>>> On Aug 30, 2022, at 8:31 AM, Pascal  wrote:
>>> 
 Le 16 août 2022 à 22:11, John Ralls  a écrit :
 
> On Aug 16, 2022, at 1:03 PM, Pascal  wrote:
> 
>> Le 16 août 2022 à 02:09, john  a écrit :
>> 
>>> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
>>> 
>>> Hello,
>>> 
>>> I've made a fresh gtk-osx install with:
>>> jhbuild bootstrap-gtk-osx
>>> jhbuild build pygments
>>> jhbuild build meta-gtk-osx-bootstrap
>>> 
>>> I've got this error:
>>> 
>>> *** Configuring libxml2 *** [5/9]
>>> ...
>>> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
>>> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" 
>>> --with-python  
>>> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
>>> ...
>>> *** Configuring itstool *** [7/9]
>>> ...
>>> checking whether 
>>> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>>>  version is >= 2.6... yes
>>> ...
>>> checking for python module libxml2... 
>>> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 
>>> Doneecho "import $py_module"
>>> 59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
>>> not found
>>> configure: error: Python module libxml2 is needed to run this 
>>> package
>>> *** Error during phase configure of itstool: ## Error 
>>> running 
>>> 
>>> <...>
>>> 
> Nothing relevant in the console but some lldb gives:
> 
> % lldb ./xnadalib-2022/bin/python3
> (lldb) target create "./xnadalib-2022/bin/python3"
> Current executable set to '/Users/me/2022b/xnadalib-2022/bin/python3' 
> (x86_64).
> (lldb) run
> Process 12477 launched: '/Users/me/2022b/xnadalib-2022/bin/python3' 
> (x86_64)
> Python 3.10.2 (main, Aug 30 2022, 11:48:18) [Clang 13.1.6 
> (clang-1316.0.21.2.5)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import libxml2
> libpython3.10.dylib was compiled with optimization - stepping may behave 
> oddly; variables may not be available.
> Process 12477 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_ACCESS (code=1, address=0x10)
> frame #0: 0x0001039359ab libpython3.10.dylib`PyModule_Create2 
> [inlined] _PyInterpreterState_GET at pycore_pystate.h:117:20 [opt]
> 114   #ifdef Py_DEBUG
> 115   _Py_EnsureTstateNotNULL(tstate);
> 116   #endif
> -> 117return tstate->interp;
> 118   }
> 119   
> 120   
> Target 0: (python3) stopped.
> (lldb) frame variable 
> (PyThreadState *) tstate = NULL
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_ACCESS (code=1, address=0x10)
> * frame #0: 0x0001039359ab libpython3.10.dylib`PyModule_Create2 
> [inlined] _PyInterpreterState_GET at pycore_pystate.h:117:20 [opt]
> frame #1: 0x00010393599d 
> libpython3.10.dylib`PyModule_Create2(module=0x00010313c110, 
> module_api_version=1013) at moduleobject.c:176:34 [opt]
> frame #2: 0x0001031059d9 libxml2mod.so`PyInit_libxml2mod + 25
> frame #3: 0x0001006d8b72 
> libpython3.10.dylib`_PyImport_LoadDynamicModuleWithSpec + 530
> 
> What would you advice to go further?
 
 Pascal,
 
 Not The Console, /Applications/Utilities/Console.app. Select Crash Reports 
 from the sidebar. You'll find a list of programs that have crashed. Double 
 click one and it will display a nice report with a stack trace.
 
 But you got there with lldb, so that's OK.
 
 You could rebuild python with --with-pydebug. That will enable that 
 _Py_EnsureTstateNotNULL function call and presumably avoid the crash. It 
 might also provide some info about why tstate was NULL and lead to either 
 a solution or at least something that you can feed back to the libxml2 
 folks.
>>> 
>>> Hello,
>>> 
>>> Console Crash Reports and option --with-pydebug even with -O0 -g haven't 
>>> brought any more clues.
>>> 
>>> I've continued my investigations by reordering the instructions:
>>> (building pygments e.g. python is placed after building 
>>> meta-gtk-osx-bootstrap)
>>> 
>>> % jhbuild bootstrap-gtk-osx
>>> % jhbuild build meta-gtk-osx-bootstrap
>>> % jhbuild build pygments

Re: [gtk-osx-users] ITSTool building error with Python built before.

[Pascal]

> Le 5 sept. 2022 à 06:38, jra...@ceridwen.fremont.ca.us a écrit :
> 
>> On Sep 4, 2022, at 12:04 PM, Pascal  wrote:
>> 
>>> Le 1 sept. 2022 à 03:06, john  a écrit :
>>> 
 On Aug 31, 2022, at 3:18 AM, Pascal  wrote:
 
> Le 30 août 2022 à 18:18, john  a écrit :
> 
>> On Aug 30, 2022, at 8:31 AM, Pascal  wrote:
>> 
>>> Le 16 août 2022 à 22:11, John Ralls  a écrit :
>>> 
 On Aug 16, 2022, at 1:03 PM, Pascal  wrote:
 
> Le 16 août 2022 à 02:09, john  a écrit :
> 
>> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
>> 
>> Hello,
>> 
>> I've made a fresh gtk-osx install with:
>> jhbuild bootstrap-gtk-osx
>> jhbuild build pygments
>> jhbuild build meta-gtk-osx-bootstrap
>> 
>> I've got this error:
>> 
>> *** Configuring libxml2 *** [5/9]
>> ...
>> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
>> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" 
>> --with-python  
>> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
>> ...
>> *** Configuring itstool *** [7/9]
>> ...
>> checking whether 
>> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>>  version is >= 2.6... yes
>> ...
>> checking for python module libxml2... 
>> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 
>> Doneecho "import $py_module"
>> 59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
>> not found
>> configure: error: Python module libxml2 is needed to run this package
>> *** Error during phase configure of itstool: ## Error 
>> running 
>> 
>> <...>
>> 
 Nothing relevant in the console but some lldb gives:
 
 % lldb ./xnadalib-2022/bin/python3
 (lldb) target create "./xnadalib-2022/bin/python3"
 Current executable set to '/Users/me/2022b/xnadalib-2022/bin/python3' 
 (x86_64).
 (lldb) run
 Process 12477 launched: '/Users/me/2022b/xnadalib-2022/bin/python3' 
 (x86_64)
 Python 3.10.2 (main, Aug 30 2022, 11:48:18) [Clang 13.1.6 
 (clang-1316.0.21.2.5)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2
 libpython3.10.dylib was compiled with optimization - stepping may behave 
 oddly; variables may not be available.
 Process 12477 stopped
 * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
 (code=1, address=0x10)
  frame #0: 0x0001039359ab libpython3.10.dylib`PyModule_Create2 
 [inlined] _PyInterpreterState_GET at pycore_pystate.h:117:20 [opt]
 114#ifdef Py_DEBUG
 115_Py_EnsureTstateNotNULL(tstate);
 116#endif
 -> 117 return tstate->interp;
 118}
 119
 120
 Target 0: (python3) stopped.
 (lldb) frame variable 
 (PyThreadState *) tstate = NULL
 (lldb) bt
 * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
 (code=1, address=0x10)
 * frame #0: 0x0001039359ab libpython3.10.dylib`PyModule_Create2 
 [inlined] _PyInterpreterState_GET at pycore_pystate.h:117:20 [opt]
  frame #1: 0x00010393599d 
 libpython3.10.dylib`PyModule_Create2(module=0x00010313c110, 
 module_api_version=1013) at moduleobject.c:176:34 [opt]
  frame #2: 0x0001031059d9 libxml2mod.so`PyInit_libxml2mod + 25
  frame #3: 0x0001006d8b72 
 libpython3.10.dylib`_PyImport_LoadDynamicModuleWithSpec + 530
 
 What would you advice to go further?
>>> 
>>> Pascal,
>>> 
>>> Not The Console, /Applications/Utilities/Console.app. Select Crash Reports 
>>> from the sidebar. You'll find a list of programs that have crashed. Double 
>>> click one and it will display a nice report with a stack trace.
>>> 
>>> But you got there with lldb, so that's OK.
>>> 
>>> You could rebuild python with --with-pydebug. That will enable that 
>>> _Py_EnsureTstateNotNULL function call and presumably avoid the crash. It 
>>> might also provide some info about why tstate was NULL and lead to either a 
>>> solution or at least something that you can feed back to the libxml2 folks.
>> 
>> Hello,
>> 
>> Console Crash Reports and option --with-pydebug even with -O0 -g haven't 
>> brought any more clues.
>> 
>> I've continued my investigations by reordering the instructions:
>> (building pygments e.g. python is placed after building 
>> meta-gtk-osx-bootstrap)
>> 
>> % jhbuild bootstrap-gtk-osx
>> % jhbuild build meta-gtk-osx-bootstrap
>> % jhbuild build pygments
>> % jhbuild build meta-gtk-osx-gtk3
>> 
>> And then no errors, good, but no explanations as well.
> 
> In that setup is libsml2 building its python bindings with the virteznv's 
> 

Re: [gtk-osx-users] ITSTool building error with Python built before.

[jralls]

> On Sep 4, 2022, at 12:04 PM, Pascal  wrote:
> 
>> 
>> Le 1 sept. 2022 à 03:06, john  a écrit :
>> 
>>> On Aug 31, 2022, at 3:18 AM, Pascal  wrote:
>>> 
 Le 30 août 2022 à 18:18, john  a écrit :
 
> On Aug 30, 2022, at 8:31 AM, Pascal  wrote:
> 
>> Le 16 août 2022 à 22:11, John Ralls  a écrit :
>> 
>>> On Aug 16, 2022, at 1:03 PM, Pascal  wrote:
>>> 
 Le 16 août 2022 à 02:09, john  a écrit :
 
> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
> 
> Hello,
> 
> I've made a fresh gtk-osx install with:
> jhbuild bootstrap-gtk-osx
> jhbuild build pygments
> jhbuild build meta-gtk-osx-bootstrap
> 
> I've got this error:
> 
> *** Configuring libxml2 *** [5/9]
> ...
> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" 
> --with-python  
> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
> ...
> *** Configuring itstool *** [7/9]
> ...
> checking whether 
> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>  version is >= 2.6... yes
> ...
> checking for python module libxml2... 
> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 
> Doneecho "import $py_module"
> 59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
> not found
> configure: error: Python module libxml2 is needed to run this package
> *** Error during phase configure of itstool: ## Error running 
> 
> <...>
> 
>>> Nothing relevant in the console but some lldb gives:
>>> 
>>> % lldb ./xnadalib-2022/bin/python3
>>> (lldb) target create "./xnadalib-2022/bin/python3"
>>> Current executable set to '/Users/me/2022b/xnadalib-2022/bin/python3' 
>>> (x86_64).
>>> (lldb) run
>>> Process 12477 launched: '/Users/me/2022b/xnadalib-2022/bin/python3' (x86_64)
>>> Python 3.10.2 (main, Aug 30 2022, 11:48:18) [Clang 13.1.6 
>>> (clang-1316.0.21.2.5)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>> import libxml2
>>> libpython3.10.dylib was compiled with optimization - stepping may behave 
>>> oddly; variables may not be available.
>>> Process 12477 stopped
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
>>> (code=1, address=0x10)
>>>  frame #0: 0x0001039359ab libpython3.10.dylib`PyModule_Create2 
>>> [inlined] _PyInterpreterState_GET at pycore_pystate.h:117:20 [opt]
>>> 114 #ifdef Py_DEBUG
>>> 115 _Py_EnsureTstateNotNULL(tstate);
>>> 116 #endif
>>> -> 117  return tstate->interp;
>>> 118 }
>>> 119 
>>> 120 
>>> Target 0: (python3) stopped.
>>> (lldb) frame variable 
>>> (PyThreadState *) tstate = NULL
>>> (lldb) bt
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
>>> (code=1, address=0x10)
>>> * frame #0: 0x0001039359ab libpython3.10.dylib`PyModule_Create2 
>>> [inlined] _PyInterpreterState_GET at pycore_pystate.h:117:20 [opt]
>>>  frame #1: 0x00010393599d 
>>> libpython3.10.dylib`PyModule_Create2(module=0x00010313c110, 
>>> module_api_version=1013) at moduleobject.c:176:34 [opt]
>>>  frame #2: 0x0001031059d9 libxml2mod.so`PyInit_libxml2mod + 25
>>>  frame #3: 0x0001006d8b72 
>>> libpython3.10.dylib`_PyImport_LoadDynamicModuleWithSpec + 530
>>> 
>>> What would you advice to go further?
>> 
>> Pascal,
>> 
>> Not The Console, /Applications/Utilities/Console.app. Select Crash Reports 
>> from the sidebar. You'll find a list of programs that have crashed. Double 
>> click one and it will display a nice report with a stack trace.
>> 
>> But you got there with lldb, so that's OK.
>> 
>> You could rebuild python with --with-pydebug. That will enable that 
>> _Py_EnsureTstateNotNULL function call and presumably avoid the crash. It 
>> might also provide some info about why tstate was NULL and lead to either a 
>> solution or at least something that you can feed back to the libxml2 folks.
> 
> Hello,
> 
> Console Crash Reports and option --with-pydebug even with -O0 -g haven't 
> brought any more clues.
> 
> I've continued my investigations by reordering the instructions:
> (building pygments e.g. python is placed after building 
> meta-gtk-osx-bootstrap)
> 
> % jhbuild bootstrap-gtk-osx
> % jhbuild build meta-gtk-osx-bootstrap
> % jhbuild build pygments
> % jhbuild build meta-gtk-osx-gtk3
> 
> And then no errors, good, but no explanations as well.

In that setup is libsml2 building its python bindings with the virteznv's 
libpython instead of the built one's?

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org

Re: [gtk-osx-users] ITSTool building error with Python built before.

[john]

> On Aug 31, 2022, at 3:18 AM, Pascal  wrote:
> 
>> 
>> Le 30 août 2022 à 18:18, john  a écrit :
>> 
>>> On Aug 30, 2022, at 8:31 AM, Pascal  wrote:
>>> 
 Le 16 août 2022 à 22:11, John Ralls  a écrit :
 
> On Aug 16, 2022, at 1:03 PM, Pascal  wrote:
> 
>> Le 16 août 2022 à 02:09, john  a écrit :
>> 
>>> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
>>> 
>>> Hello,
>>> 
>>> I've made a fresh gtk-osx install with:
>>> jhbuild bootstrap-gtk-osx
>>> jhbuild build pygments
>>> jhbuild build meta-gtk-osx-bootstrap
>>> 
>>> I've got this error:
>>> 
>>> *** Configuring libxml2 *** [5/9]
>>> ...
>>> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
>>> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" --with-python  
>>> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
>>> ...
>>> *** Configuring itstool *** [7/9]
>>> ...
>>> checking whether 
>>> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>>>  version is >= 2.6... yes
>>> ...
>>> checking for python module libxml2... 
>>> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 Done 
>>>echo "import $py_module"
>>> 59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
>>> not found
>>> configure: error: Python module libxml2 is needed to run this package
>>> *** Error during phase configure of itstool: ## Error running 
>>> /Users/me/2022a/src-2022/itstool-2.0.6/configure --prefix 
>>> /Users/me/2022a/xnadalib-2022 *** [7/9]
>>> 
>>> itstool configure is unfortunately using $PYTHON:
>>>   if test -n "$PYTHON"; then
>>> # If the user set $PYTHON, use it and don't search something else.
>>> 
>>> which is set to (in jhbuild env):
>>> PYTHON=/Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>>> 
>>> This PYTHON variable wasn't set in January'22 the last time I ran 
>>> jhbuild.
>>> Thus itstool was built ok.
>>> 
>>> What could be a workaround?
>> 
>> 
>> The most straightforward is to add
>> module_extra_env['itstool'] = ('PYTHON' : os.env.path(prefix, 'bin', 
>> 'python3'))
>> to your jhbuildrc-custom.
> 
> Thanks John for your quick answer,
> 
> My thinking was erroneous, sorry, the error is not that python doesn't 
> find libxml2 like:
> ModuleNotFoundError: No module named 'libxml2'
> 
> Whatever the PYTHON value is, as PYTHONPATH is set with 
> ${prefix}/lib/python3.10/site-packages then libxml2 is successfully found 
> but provoques a Segmentation fault.
> 
> It was ok last time with python 3.9:
> bld% ./xnadalib-2021/bin/python
> Python 3.9.2 (default, Jan  9 2022, 11:56:26) 
> [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import libxml2
 
> 
> But not with python 3.10:
> bld% ./xnadalib-2022/bin/python3
> Python 3.10.2 (main, Aug 15 2022, 12:49:45) [Clang 13.1.6 
> (clang-1316.0.21.2.5)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import libxml2
> zsh: segmentation fault  ./xnadalib-2022/bin/python3
> 
> Both built libxml2 have same version.
> 
> I don't find any relevant help on Google.
> libxml2 is a too long story :-( sorry to bother you with that.
 
 Not quite enough information there, but as a guess you didn't rebuild 
 libxml2 with the new python so it's linked to libpython3.9.dylib instead 
 of libpython3.10.dylib.
>>> 
>>> Hello John,
>>> 
>>> I ran again all the installation (2022b) from the beginning but I got the 
>>> same error.
>>> My configuration:
>>> Prefix is /Users/me/2022b/xnadalib-2022
>>> % uname -v   
>>> Darwin Kernel Version 21.6.0: Wed Aug 10 14:25:27 PDT 2022; 
>>> root:xnu-8020.141.5~2/RELEASE_X86_64
>>> % xcodebuild -version 
>>> Xcode 13.4.1
>>> Build version 13F100
>>> % java -version  
>>> java version "14" 2020-03-17
>>> Java(TM) SE Runtime Environment (build 14+36-1461)
>>> Java HotSpot(TM) 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)
>>> 
>>> The offending file si libxml2mod.so imported by libxml2.py:
>>> % ls ./xnadalib-2022/lib/python3.10/site-packages
>>> Pygments-2.9.0-py3.10.egg-info/ libxml2mod.a
>>> README.txt  libxml2mod.so*
>>> __pycache__/pkg_resources/
>>> _distutils_hack/pygments/
>>> distutils-precedence.pthsetuptools/
>>> drv_libxml2.py  setuptools-58.1.0.dist-info/
>>> libxml2.py
>>> 
>>> % ./xnadalib-2022/bin/python3
>>> Python 3.10.2 (main, Aug 30 2022, 11:48:18) [Clang 13.1.6 
>>> (clang-1316.0.21.2.5)] on darwin
>>> Type "help", "copyright", "credits" or 

Re: [gtk-osx-users] ITSTool building error with Python built before.

[Pascal]

> Le 30 août 2022 à 18:18, john  a écrit :
> 
>> On Aug 30, 2022, at 8:31 AM, Pascal  wrote:
>> 
>>> Le 16 août 2022 à 22:11, John Ralls  a écrit :
>>> 
 On Aug 16, 2022, at 1:03 PM, Pascal  wrote:
 
> Le 16 août 2022 à 02:09, john  a écrit :
> 
>> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
>> 
>> Hello,
>> 
>> I've made a fresh gtk-osx install with:
>> jhbuild bootstrap-gtk-osx
>> jhbuild build pygments
>> jhbuild build meta-gtk-osx-bootstrap
>> 
>> I've got this error:
>> 
>> *** Configuring libxml2 *** [5/9]
>> ...
>> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
>> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" --with-python  
>> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
>> ...
>> *** Configuring itstool *** [7/9]
>> ...
>> checking whether 
>> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>>  version is >= 2.6... yes
>> ...
>> checking for python module libxml2... 
>> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 Done  
>>   echo "import $py_module"
>> 59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
>> not found
>> configure: error: Python module libxml2 is needed to run this package
>> *** Error during phase configure of itstool: ## Error running 
>> /Users/me/2022a/src-2022/itstool-2.0.6/configure --prefix 
>> /Users/me/2022a/xnadalib-2022*** [7/9]
>> 
>> itstool configure is unfortunately using $PYTHON:
>>if test -n "$PYTHON"; then
>>  # If the user set $PYTHON, use it and don't search something else.
>> 
>> which is set to (in jhbuild env):
>> PYTHON=/Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>> 
>> This PYTHON variable wasn't set in January'22 the last time I ran 
>> jhbuild.
>> Thus itstool was built ok.
>> 
>> What could be a workaround?
> 
> 
> The most straightforward is to add
> module_extra_env['itstool'] = ('PYTHON' : os.env.path(prefix, 'bin', 
> 'python3'))
> to your jhbuildrc-custom.
 
 Thanks John for your quick answer,
 
 My thinking was erroneous, sorry, the error is not that python doesn't 
 find libxml2 like:
 ModuleNotFoundError: No module named 'libxml2'
 
 Whatever the PYTHON value is, as PYTHONPATH is set with 
 ${prefix}/lib/python3.10/site-packages then libxml2 is successfully found 
 but provoques a Segmentation fault.
 
 It was ok last time with python 3.9:
 bld% ./xnadalib-2021/bin/python
 Python 3.9.2 (default, Jan  9 2022, 11:56:26) 
 [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2
>>> 
 
 But not with python 3.10:
 bld% ./xnadalib-2022/bin/python3
 Python 3.10.2 (main, Aug 15 2022, 12:49:45) [Clang 13.1.6 
 (clang-1316.0.21.2.5)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2
 zsh: segmentation fault  ./xnadalib-2022/bin/python3
 
 Both built libxml2 have same version.
 
 I don't find any relevant help on Google.
 libxml2 is a too long story :-( sorry to bother you with that.
>>> 
>>> Not quite enough information there, but as a guess you didn't rebuild 
>>> libxml2 with the new python so it's linked to libpython3.9.dylib instead of 
>>> libpython3.10.dylib.
>> 
>> Hello John,
>> 
>> I ran again all the installation (2022b) from the beginning but I got the 
>> same error.
>> My configuration:
>> Prefix is /Users/me/2022b/xnadalib-2022
>> % uname -v   
>> Darwin Kernel Version 21.6.0: Wed Aug 10 14:25:27 PDT 2022; 
>> root:xnu-8020.141.5~2/RELEASE_X86_64
>> % xcodebuild -version 
>> Xcode 13.4.1
>> Build version 13F100
>> % java -version  
>> java version "14" 2020-03-17
>> Java(TM) SE Runtime Environment (build 14+36-1461)
>> Java HotSpot(TM) 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)
>> 
>> The offending file si libxml2mod.so imported by libxml2.py:
>> % ls ./xnadalib-2022/lib/python3.10/site-packages
>> Pygments-2.9.0-py3.10.egg-info/ libxml2mod.a
>> README.txt  libxml2mod.so*
>> __pycache__/pkg_resources/
>> _distutils_hack/pygments/
>> distutils-precedence.pthsetuptools/
>> drv_libxml2.py  setuptools-58.1.0.dist-info/
>> libxml2.py
>> 
>> % ./xnadalib-2022/bin/python3
>> Python 3.10.2 (main, Aug 30 2022, 11:48:18) [Clang 13.1.6 
>> (clang-1316.0.21.2.5)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
> import libxml2mod
>> zsh: segmentation fault  ./xnadalib-2022/bin/python3
>> 
>> But this file is well bound against Python 3.10:
>> % 

Re: [gtk-osx-users] ITSTool building error with Python built before.

[john]

> On Aug 30, 2022, at 8:31 AM, Pascal  wrote:
> 
>> 
>> Le 16 août 2022 à 22:11, John Ralls  a écrit :
>> 
>>> On Aug 16, 2022, at 1:03 PM, Pascal  wrote:
>>> 
 
 Le 16 août 2022 à 02:09, john  a écrit :
 
> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
> 
> Hello,
> 
> I've made a fresh gtk-osx install with:
> jhbuild bootstrap-gtk-osx
> jhbuild build pygments
> jhbuild build meta-gtk-osx-bootstrap
> 
> I've got this error:
> 
> *** Configuring libxml2 *** [5/9]
> ...
> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" --with-python  
> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
> ...
> *** Configuring itstool *** [7/9]
> ...
> checking whether 
> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>  version is >= 2.6... yes
> ...
> checking for python module libxml2... 
> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 Done   
>  echo "import $py_module"
> 59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
> not found
> configure: error: Python module libxml2 is needed to run this package
> *** Error during phase configure of itstool: ## Error running 
> /Users/me/2022a/src-2022/itstool-2.0.6/configure --prefix 
> /Users/me/2022a/xnadalib-2022*** [7/9]
> 
> itstool configure is unfortunately using $PYTHON:
>if test -n "$PYTHON"; then
>  # If the user set $PYTHON, use it and don't search something else.
> 
> which is set to (in jhbuild env):
> PYTHON=/Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
> 
> This PYTHON variable wasn't set in January'22 the last time I ran jhbuild.
> Thus itstool was built ok.
> 
> What could be a workaround?
 
 
 The most straightforward is to add
 module_extra_env['itstool'] = ('PYTHON' : os.env.path(prefix, 'bin', 
 'python3'))
 to your jhbuildrc-custom.
>>> 
>>> Thanks John for your quick answer,
>>> 
>>> My thinking was erroneous, sorry, the error is not that python doesn't find 
>>> libxml2 like:
>>> ModuleNotFoundError: No module named 'libxml2'
>>> 
>>> Whatever the PYTHON value is, as PYTHONPATH is set with 
>>> ${prefix}/lib/python3.10/site-packages then libxml2 is successfully found 
>>> but provoques a Segmentation fault.
>>> 
>>> It was ok last time with python 3.9:
>>> bld% ./xnadalib-2021/bin/python
>>> Python 3.9.2 (default, Jan  9 2022, 11:56:26) 
>>> [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>> import libxml2
>> 
>>> 
>>> But not with python 3.10:
>>> bld% ./xnadalib-2022/bin/python3
>>> Python 3.10.2 (main, Aug 15 2022, 12:49:45) [Clang 13.1.6 
>>> (clang-1316.0.21.2.5)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>> import libxml2
>>> zsh: segmentation fault  ./xnadalib-2022/bin/python3
>>> 
>>> Both built libxml2 have same version.
>>> 
>>> I don't find any relevant help on Google.
>>> libxml2 is a too long story :-( sorry to bother you with that.
>> 
>> Not quite enough information there, but as a guess you didn't rebuild 
>> libxml2 with the new python so it's linked to libpython3.9.dylib instead of 
>> libpython3.10.dylib.
> 
> Hello John,
> 
> I ran again all the installation (2022b) from the beginning but I got the 
> same error.
> My configuration:
> Prefix is /Users/me/2022b/xnadalib-2022
> % uname -v   
> Darwin Kernel Version 21.6.0: Wed Aug 10 14:25:27 PDT 2022; 
> root:xnu-8020.141.5~2/RELEASE_X86_64
> % xcodebuild -version 
> Xcode 13.4.1
> Build version 13F100
> % java -version  
> java version "14" 2020-03-17
> Java(TM) SE Runtime Environment (build 14+36-1461)
> Java HotSpot(TM) 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)
> 
> The offending file si libxml2mod.so imported by libxml2.py:
> % ls ./xnadalib-2022/lib/python3.10/site-packages
> Pygments-2.9.0-py3.10.egg-info/ libxml2mod.a
> README.txt  libxml2mod.so*
> __pycache__/pkg_resources/
> _distutils_hack/pygments/
> distutils-precedence.pthsetuptools/
> drv_libxml2.py  setuptools-58.1.0.dist-info/
> libxml2.py
> 
> % ./xnadalib-2022/bin/python3
> Python 3.10.2 (main, Aug 30 2022, 11:48:18) [Clang 13.1.6 
> (clang-1316.0.21.2.5)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import libxml2mod
> zsh: segmentation fault  ./xnadalib-2022/bin/python3
> 
> But this file is well bound against Python 3.10:
> % otool -L ./xnadalib-2022/lib/python3.10/site-packages/libxml2mod.so
> ./xnadalib-2022/lib/python3.10/site-packages/libxml2mod.so:
>   

Re: [gtk-osx-users] ITSTool building error with Python built before.

[Pascal]

> Le 16 août 2022 à 22:11, John Ralls  a écrit :
> 
>> On Aug 16, 2022, at 1:03 PM, Pascal  wrote:
>> 
>>> 
>>> Le 16 août 2022 à 02:09, john  a écrit :
>>> 
 On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
 
 Hello,
 
 I've made a fresh gtk-osx install with:
 jhbuild bootstrap-gtk-osx
 jhbuild build pygments
 jhbuild build meta-gtk-osx-bootstrap
 
 I've got this error:
 
 *** Configuring libxml2 *** [5/9]
 ...
 /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
 /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" --with-python  
 --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
 ...
 *** Configuring itstool *** [7/9]
 ...
 checking whether 
 /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
  version is >= 2.6... yes
 ...
 checking for python module libxml2... 
 /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 Done
 echo "import $py_module"
  59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
 not found
 configure: error: Python module libxml2 is needed to run this package
 *** Error during phase configure of itstool: ## Error running 
 /Users/me/2022a/src-2022/itstool-2.0.6/configure --prefix 
 /Users/me/2022a/xnadalib-2022*** [7/9]
 
 itstool configure is unfortunately using $PYTHON:
 if test -n "$PYTHON"; then
   # If the user set $PYTHON, use it and don't search something else.
 
 which is set to (in jhbuild env):
 PYTHON=/Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
 
 This PYTHON variable wasn't set in January'22 the last time I ran jhbuild.
 Thus itstool was built ok.
 
 What could be a workaround?
>>> 
>>> 
>>> The most straightforward is to add
>>>  module_extra_env['itstool'] = ('PYTHON' : os.env.path(prefix, 'bin', 
>>> 'python3'))
>>> to your jhbuildrc-custom.
>> 
>> Thanks John for your quick answer,
>> 
>> My thinking was erroneous, sorry, the error is not that python doesn't find 
>> libxml2 like:
>> ModuleNotFoundError: No module named 'libxml2'
>> 
>> Whatever the PYTHON value is, as PYTHONPATH is set with 
>> ${prefix}/lib/python3.10/site-packages then libxml2 is successfully found 
>> but provoques a Segmentation fault.
>> 
>> It was ok last time with python 3.9:
>> bld% ./xnadalib-2021/bin/python
>> Python 3.9.2 (default, Jan  9 2022, 11:56:26) 
>> [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
> import libxml2
> 
>> 
>> But not with python 3.10:
>> bld% ./xnadalib-2022/bin/python3
>> Python 3.10.2 (main, Aug 15 2022, 12:49:45) [Clang 13.1.6 
>> (clang-1316.0.21.2.5)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
> import libxml2
>> zsh: segmentation fault  ./xnadalib-2022/bin/python3
>> 
>> Both built libxml2 have same version.
>> 
>> I don't find any relevant help on Google.
>> libxml2 is a too long story :-( sorry to bother you with that.
> 
> Not quite enough information there, but as a guess you didn't rebuild libxml2 
> with the new python so it's linked to libpython3.9.dylib instead of 
> libpython3.10.dylib.

Hello John,

I ran again all the installation (2022b) from the beginning but I got the same 
error.
My configuration:
Prefix is /Users/me/2022b/xnadalib-2022
% uname -v   
Darwin Kernel Version 21.6.0: Wed Aug 10 14:25:27 PDT 2022; 
root:xnu-8020.141.5~2/RELEASE_X86_64
% xcodebuild -version 
Xcode 13.4.1
Build version 13F100
% java -version  
java version "14" 2020-03-17
Java(TM) SE Runtime Environment (build 14+36-1461)
Java HotSpot(TM) 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)

The offending file si libxml2mod.so imported by libxml2.py:
% ls ./xnadalib-2022/lib/python3.10/site-packages
Pygments-2.9.0-py3.10.egg-info/ libxml2mod.a
README.txt  libxml2mod.so*
__pycache__/pkg_resources/
_distutils_hack/pygments/
distutils-precedence.pthsetuptools/
drv_libxml2.py  setuptools-58.1.0.dist-info/
libxml2.py

% ./xnadalib-2022/bin/python3
Python 3.10.2 (main, Aug 30 2022, 11:48:18) [Clang 13.1.6 
(clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2mod
zsh: segmentation fault  ./xnadalib-2022/bin/python3

But this file is well bound against Python 3.10:
% otool -L ./xnadalib-2022/lib/python3.10/site-packages/libxml2mod.so
./xnadalib-2022/lib/python3.10/site-packages/libxml2mod.so:
/Users/me/2022b/xnadalib-2022/lib/libxml2.2.dylib (compatibility 
version 12.0.0, current version 12.12.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1311.100.3)
/Users/me/2022b/xnadalib-2022/lib/libz.1.dylib 

Re: [gtk-osx-users] ITSTool building error with Python built before.

[John Ralls]

> On Aug 16, 2022, at 1:03 PM, Pascal  wrote:
> 
>> 
>> Le 16 août 2022 à 02:09, john  a écrit :
>> 
>>> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
>>> 
>>> Hello,
>>> 
>>> I've made a fresh gtk-osx install with:
>>> jhbuild bootstrap-gtk-osx
>>> jhbuild build pygments
>>> jhbuild build meta-gtk-osx-bootstrap
>>> 
>>> I've got this error:
>>> 
>>> *** Configuring libxml2 *** [5/9]
>>> ...
>>> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
>>> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" --with-python  
>>> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
>>> ...
>>> *** Configuring itstool *** [7/9]
>>> ...
>>> checking whether 
>>> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>>>  version is >= 2.6... yes
>>> ...
>>> checking for python module libxml2... 
>>> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 Done 
>>>echo "import $py_module"
>>>   59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
>>> not found
>>> configure: error: Python module libxml2 is needed to run this package
>>> *** Error during phase configure of itstool: ## Error running 
>>> /Users/me/2022a/src-2022/itstool-2.0.6/configure --prefix 
>>> /Users/me/2022a/xnadalib-2022*** [7/9]
>>> 
>>> itstool configure is unfortunately using $PYTHON:
>>>  if test -n "$PYTHON"; then
>>># If the user set $PYTHON, use it and don't search something else.
>>> 
>>> which is set to (in jhbuild env):
>>> PYTHON=/Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>>> 
>>> This PYTHON variable wasn't set in January'22 the last time I ran jhbuild.
>>> Thus itstool was built ok.
>>> 
>>> What could be a workaround?
>> 
>> 
>> The most straightforward is to add
>>   module_extra_env['itstool'] = ('PYTHON' : os.env.path(prefix, 'bin', 
>> 'python3'))
>> to your jhbuildrc-custom.
> 
> Thanks John for your quick answer,
> 
> My thinking was erroneous, sorry, the error is not that python doesn't find 
> libxml2 like:
> ModuleNotFoundError: No module named 'libxml2'
> 
> Whatever the PYTHON value is, as PYTHONPATH is set with 
> ${prefix}/lib/python3.10/site-packages then libxml2 is successfully found but 
> provoques a Segmentation fault.
> 
> It was ok last time with python 3.9:
> bld% ./xnadalib-2021/bin/python
> Python 3.9.2 (default, Jan  9 2022, 11:56:26) 
> [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import libxml2
 
> 
> But not with python 3.10:
> bld% ./xnadalib-2022/bin/python3
> Python 3.10.2 (main, Aug 15 2022, 12:49:45) [Clang 13.1.6 
> (clang-1316.0.21.2.5)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import libxml2
> zsh: segmentation fault  ./xnadalib-2022/bin/python3
> 
> Both built libxml2 have same version.
> 
> I don't find any relevant help on Google.
> libxml2 is a too long story :-( sorry to bother you with that.

Not quite enough information there, but as a guess you didn't rebuild libxml2 
with the new python so it's linked to libpython3.9.dylib instead of 
libpython3.10.dylib.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] ITSTool building error with Python built before.

[Pascal]

> Le 16 août 2022 à 02:09, john  a écrit :
> 
>> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
>> 
>> Hello,
>> 
>> I've made a fresh gtk-osx install with:
>> jhbuild bootstrap-gtk-osx
>> jhbuild build pygments
>> jhbuild build meta-gtk-osx-bootstrap
>> 
>> I've got this error:
>> 
>> *** Configuring libxml2 *** [5/9]
>> ...
>> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
>> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" --with-python  
>> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
>> ...
>> *** Configuring itstool *** [7/9]
>> ...
>> checking whether 
>> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>>  version is >= 2.6... yes
>> ...
>> checking for python module libxml2... 
>> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 Done  
>>   echo "import $py_module"
>>59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
>> not found
>> configure: error: Python module libxml2 is needed to run this package
>> *** Error during phase configure of itstool: ## Error running 
>> /Users/me/2022a/src-2022/itstool-2.0.6/configure --prefix 
>> /Users/me/2022a/xnadalib-2022*** [7/9]
>> 
>> itstool configure is unfortunately using $PYTHON:
>>   if test -n "$PYTHON"; then
>> # If the user set $PYTHON, use it and don't search something else.
>> 
>> which is set to (in jhbuild env):
>> PYTHON=/Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>> 
>> This PYTHON variable wasn't set in January'22 the last time I ran jhbuild.
>> Thus itstool was built ok.
>> 
>> What could be a workaround?
> 
> 
> The most straightforward is to add
>module_extra_env['itstool'] = ('PYTHON' : os.env.path(prefix, 'bin', 
> 'python3'))
> to your jhbuildrc-custom.

Thanks John for your quick answer,

My thinking was erroneous, sorry, the error is not that python doesn't find 
libxml2 like:
ModuleNotFoundError: No module named 'libxml2'

Whatever the PYTHON value is, as PYTHONPATH is set with 
${prefix}/lib/python3.10/site-packages then libxml2 is successfully found but 
provoques a Segmentation fault.

It was ok last time with python 3.9:
bld% ./xnadalib-2021/bin/python
Python 3.9.2 (default, Jan  9 2022, 11:56:26) 
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2
>>> 

But not with python 3.10:
bld% ./xnadalib-2022/bin/python3
Python 3.10.2 (main, Aug 15 2022, 12:49:45) [Clang 13.1.6 
(clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import libxml2
zsh: segmentation fault  ./xnadalib-2022/bin/python3

Both built libxml2 have same version.

I don't find any relevant help on Google.
libxml2 is a too long story :-( sorry to bother you with that.

What is your feedback?

Thanks, Pascal.
https://blady.pagesperso-orange.fr


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] ITSTool building error with Python built before.

[john]

> On Aug 15, 2022, at 9:13 AM, Pascal  wrote:
> 
> Hello,
> 
> I've made a fresh gtk-osx install with:
>  jhbuild bootstrap-gtk-osx
>  jhbuild build pygments
>  jhbuild build meta-gtk-osx-bootstrap
> 
> I've got this error:
> 
> *** Configuring libxml2 *** [5/9]
> ...
> /Users/me/2022a/src-2022/libxml2-2.9.12/configure --prefix 
> /Users/me/2022a/xnadalib-2022 --libdir="$JHBUILD_LIBDIR" --with-python  
> --with-python-install-dir=/Users/me/2022a/xnadalib-2022/lib/python3.10/site-packages
> ...
> *** Configuring itstool *** [7/9]
> ...
> checking whether 
> /Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
>  version is >= 2.6... yes
> ...
> checking for python module libxml2... 
> /Users/me/2022a/src-2022/itstool-2.0.6/configure: line 2604: 59919 Done   
>  echo "import $py_module"
> 59920 Segmentation fault: 11  | $PYTHON - >&/dev/null
> not found
> configure: error: Python module libxml2 is needed to run this package
> *** Error during phase configure of itstool: ## Error running 
> /Users/me/2022a/src-2022/itstool-2.0.6/configure --prefix 
> /Users/me/2022a/xnadalib-2022*** [7/9]
> 
> itstool configure is unfortunately using $PYTHON:
>if test -n "$PYTHON"; then
>  # If the user set $PYTHON, use it and don't search something else.
> 
> which is set to (in jhbuild env):
> PYTHON=/Users/me/2022a/src-2022/.new_local/share/virtualenvs/etc-Mg3srn31/bin/python3
> 
> This PYTHON variable wasn't set in January'22 the last time I ran jhbuild.
> Thus itstool was built ok.
> 
> What could be a workaround?


The most straightforward is to add
module_extra_env['itstool'] = ('PYTHON' : os.env.path(prefix, 'bin', 
'python3'))
to your jhbuildrc-custom.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Can I install and use GNOME on macOS?

[john]

> On Jul 21, 2022, at 2:41 AM, Turritopsis Dohrnii Teo En Ming via 
> gtk-osx-users-list  wrote:
> 
> Subject: Can I install and use GNOME on macOS?
> 
> Good day from Singapore,
> 
> Can I install and use GNOME on macOS?
> 
> Just wondering.
> 
> Thank you.


If you mean to install and run the Gnome desktop environment, no. macOS can run 
only its own desktop environment directly. If you want to run the Gnome desktop 
environment on your Mac you can do so using a virtual machine running Linux or 
install Linux on your Mac in a dual-boot setup. Running Linux is an excellent 
way to keep older Macs that Apple no longer supports running with an up-to-date 
and secure operating system.

If on the other hand you mean can you run Gnome programs on macOS, yes. Take a 
look at Homebrew (https://brew.sh ) and MacPorts 
(https://www.macports.org ). Many of the major Gnome 
applications like The Gimp, Inkscape, and GnuCash provide drag-and-drop macOS 
application bundles that you can simply install and use like any other macOS 
application. 

This mailing list for developers of applications in that last category who use 
a particular toolset, https://gitlab.gnome.org/GNOME/gtk-osx.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Black screen on ARM based Macs

[Miroslav Rajcic via gtk-osx-users-list]

Thanks John,

I've solved the icons for the main window (works fine now), now slowly 
converting function calls for the rest of the program.

I've also modified my .bundle file to match the demo bundle posted here (my 
copy was evolving from GTK2.x version):
https://gitlab.gnome.org/GNOME/gtk-mac-bundler/-/blob/master/examples/gtk3-demo.bundle

I have a related suggestion, packaging the following directory is important, or 
else the program will crash when opening the File Open/Save windows (missing 
Gio or GSettings schema files, forgot the exact name now):

  *
${prefix}/share/glib-2.0
  

I understand that your demo might not use these windows, but it might be useful 
to add this into the demo bundle, because people might use it as a template for 
their own projects.

Best regards,
  Miroslav



From: john 
Sent: Sunday, July 10, 2022 4:54 AM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

There's more than one moving part here: Adwaita-icon-theme and the Adwaita 
icons built in to Gtk3 itself. It looks to me like there was a bit of a 
communications failure between the two groups. One of the Gtk devs has moved 
the icons eliminated by adwaita-icon-theme into Gtk3 itself, but it will take a 
couple of weeks for that to percolate into a release and probably quite a bit 
longer before I update the gtk-osx modules  to pick it up. Regardless, 
switching to the -symbolic icon names is the way forward so you might as well 
get it over with.

Regards,
John Ralls


On Jun 30, 2022, at 12:03 PM, Miroslav Rajcic  wrote:

Thanks John,

the information was quite helpful, but also quite surprising.
When choosing what icon names to use to replace stock icons, I used official 
documentation, see for example comments in this file:
https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/deprecated/gtkstock.h

Example comment:

/**
 * GTK_STOCK_OPEN:
 *
 * The “Open” item and icon.
 *
 * Deprecated: 3.10: Use named icon document-open or the label 
_Open.
 */


I guess that means that the documentation does not match the current state.
Will replace names with "-symbolic" variants.

Best regards,
  Miroslav


From: john 
Sent: Thursday, June 30, 2022 6:39 PM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

The basic problem is that all of those color icons were declared "legacy" by 
the Gnome designers a long time ago and Adwaita-icon-theme v42 finally removed 
them. As it happens that broke a Gtk test, see 
https://gitlab.gnome.org/GNOME/gtk/-/issues/4754, so they've been added back to 
Gtk-3.24.34. Another "but": It's only the legacy icons used by Gtk3 itself, so 
it might not cover all of the icons you need.

The simplest temporary fix is to add a module for an older Adwaita version to 
your local moduleset. I picked 3.38.0 for GnuCash, see 
https://github.com/Gnucash/gnucash-on-osx/blob/cd34a47d2236929c931a8676845b5714e2ccde20/modulesets/gnucash.modules#L376.
 Just arrange for it to be built after meta-gtk-osx-gtk3 and it will overwrite 
the current Adwaita-42.

The longer-term fix is to switch to the newer foo-symbolic names, e.g. 
"document-new-symbolic". You should do that soon because the legacy icons will 
disappear from Linux distros soon if they haven't already, particularly on 
bleeding-edge distros like Arch Linux and Gentoo. I don't know if all of the 
legacy icons were converted, so you may need to find alternatives or design 
your own in some cases.

Regards,
John Ralls



On Jun 30, 2022, at 4:14 AM, Miroslav Rajcic  wrote:

I've been converting from stock icons to symbolic icons, but no luck so far.

Example code (both GTK2 and GTK3 builds are supported):
#if GTK_CHECK_VERSION(3,10,0)
icon = gtk_image_new_from_icon_name("edit-delete", 
GTK_ICON_SIZE_MENU);
#else
icon = gtk_image_new_from_stock(GTK_STOCK_DELETE, 
GTK_ICON_SIZE_MENU);
#endif

As I can see adwaita theme icons are correctly bundled, and I added test code 
on startup to write the theme name and search paths:
gchar* szIconTheme = nullptr;
g_object_get(gtk_settings_get_default(), "gtk-icon-theme-name", 
, (char*) nullptr);
XLOG(LL_INFO, "Icon theme used: %s\n", szIconTheme);
g_free(szIconTheme);

  gint n_elements = 0;
  gchar **path;
  gtk_icon_theme_get_search_path(gtk_icon_theme_get_default(), , 
_elements);
  for(int j=0; j-symbolic.symbolic.png" files):
http://notecase.sourceforge.net/temp/notecase-4.6.5pre2.pkg<http://notecase.sourceforge.net/temp/notecase-4.6.5pre2.pkg.filepart>

Any idea how to debug this?
Can I perhaps activate an additional GTK logging for the GTK theme related code 
through GTK_DEBUG variable or something similar?

Best regards,
  Miroslav

___

Re: [gtk-osx-users] Black screen on ARM based Macs

[john]

Miroslav,

There's more than one moving part here: Adwaita-icon-theme and the Adwaita 
icons built in to Gtk3 itself. It looks to me like there was a bit of a 
communications failure between the two groups. One of the Gtk devs has moved 
the icons eliminated by adwaita-icon-theme into Gtk3 itself, but it will take a 
couple of weeks for that to percolate into a release and probably quite a bit 
longer before I update the gtk-osx modules  to pick it up. Regardless, 
switching to the -symbolic icon names is the way forward so you might as well 
get it over with.

Regards,
John Ralls


> On Jun 30, 2022, at 12:03 PM, Miroslav Rajcic  wrote:
> 
> Thanks John,
> 
> the information was quite helpful, but also quite surprising.
> When choosing what icon names to use to replace stock icons, I used official 
> documentation, see for example comments in this file:
> https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/deprecated/gtkstock.h
> 
> Example comment:
> /**
>  * GTK_STOCK_OPEN:
>  *
>  * The “Open” item and icon.
>  *
>  * Deprecated: 3.10: Use named icon document-open or the label 
> _Open.
>  */
> I guess that means that the documentation does not match the current state.
> Will replace names with "-symbolic" variants.
> 
> Best regards,
>   Miroslav
> 
> From: john 
> Sent: Thursday, June 30, 2022 6:39 PM
> To: Miroslav Rajcic 
> Cc: gtk-osx-users-list@gnome.org 
> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>  
> Miroslav,
> 
> The basic problem is that all of those color icons were declared "legacy" by 
> the Gnome designers a long time ago and Adwaita-icon-theme v42 finally 
> removed them. As it happens that broke a Gtk test, see 
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4754, so they've been added back 
> to Gtk-3.24.34. Another "but": It's only the legacy icons used by Gtk3 
> itself, so it might not cover all of the icons you need.
> 
> The simplest temporary fix is to add a module for an older Adwaita version to 
> your local moduleset. I picked 3.38.0 for GnuCash, see 
> https://github.com/Gnucash/gnucash-on-osx/blob/cd34a47d2236929c931a8676845b5714e2ccde20/modulesets/gnucash.modules#L376.
>  Just arrange for it to be built after meta-gtk-osx-gtk3 and it will 
> overwrite the current Adwaita-42.
> 
> The longer-term fix is to switch to the newer foo-symbolic names, e.g. 
> "document-new-symbolic". You should do that soon because the legacy icons 
> will disappear from Linux distros soon if they haven't already, particularly 
> on bleeding-edge distros like Arch Linux and Gentoo. I don't know if all of 
> the legacy icons were converted, so you may need to find alternatives or 
> design your own in some cases.
> 
> Regards,
> John Ralls
> 
> 
>  
>> On Jun 30, 2022, at 4:14 AM, Miroslav Rajcic  wrote:
>> 
>> I've been converting from stock icons to symbolic icons, but no luck so far.
>> 
>> Example code (both GTK2 and GTK3 builds are supported):
>> #if GTK_CHECK_VERSION(3,10,0)
>> icon = gtk_image_new_from_icon_name("edit-delete", 
>> GTK_ICON_SIZE_MENU);
>> #else
>> icon = gtk_image_new_from_stock(GTK_STOCK_DELETE, 
>> GTK_ICON_SIZE_MENU);
>> #endif
>> 
>> As I can see adwaita theme icons are correctly bundled, and I added test 
>> code on startup to write the theme name and search paths:
>> gchar* szIconTheme = nullptr;
>> g_object_get(gtk_settings_get_default(), "gtk-icon-theme-name", 
>> , (char*) nullptr);
>> XLOG(LL_INFO, "Icon theme used: %s\n", szIconTheme);
>> g_free(szIconTheme);
>> 
>>   gint n_elements = 0;
>>   gchar **path;
>>   gtk_icon_theme_get_search_path(gtk_icon_theme_get_default(), , 
>> _elements);
>>   for(int j=0; j> XLOG(LL_INFO, "Icon path: %s\n", path[j]);
>> 
>> Logs below indicate that the search paths are correct, but the icons can not 
>> be found anyway:
>> 12:38:03.534 Icon theme used: Adwaita
>> 12:38:03.534 Icon path: /Users/gtk3/.local/share/icons
>> 12:38:03.534 Icon path: /Users/gtk3/.icons
>> 12:38:03.534 Icon path: 
>> /Applications/NotecasePro.app/Contents/Resources/share/icons
>> 12:38:03.534 Icon path: 
>> /Applications/NotecasePro.app/Contents/Resources/share/pixmaps
>> ...
>> 12:38:03.925 GTK [16]:
>> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.925: Error loading theme icon 
>> 'document-new' for stock: Icon 'document-new' not present in theme Adwaita
>> 12:38:03.927 GTK [16]: 
>> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.927: Error loading theme icon 
>> 'document-open' fo

Re: [gtk-osx-users] Black screen on ARM based Macs

[Miroslav Rajcic via gtk-osx-users-list]

Thanks John,

the information was quite helpful, but also quite surprising.
When choosing what icon names to use to replace stock icons, I used official 
documentation, see for example comments in this file:
https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/deprecated/gtkstock.h

Example comment:

/**
 * GTK_STOCK_OPEN:
 *
 * The “Open” item and icon.
 *
 * Deprecated: 3.10: Use named icon document-open or the label 
_Open.
 */


I guess that means that the documentation does not match the current state.
Will replace names with "-symbolic" variants.

Best regards,
  Miroslav


From: john 
Sent: Thursday, June 30, 2022 6:39 PM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

The basic problem is that all of those color icons were declared "legacy" by 
the Gnome designers a long time ago and Adwaita-icon-theme v42 finally removed 
them. As it happens that broke a Gtk test, see 
https://gitlab.gnome.org/GNOME/gtk/-/issues/4754, so they've been added back to 
Gtk-3.24.34. Another "but": It's only the legacy icons used by Gtk3 itself, so 
it might not cover all of the icons you need.

The simplest temporary fix is to add a module for an older Adwaita version to 
your local moduleset. I picked 3.38.0 for GnuCash, see 
https://github.com/Gnucash/gnucash-on-osx/blob/cd34a47d2236929c931a8676845b5714e2ccde20/modulesets/gnucash.modules#L376.
 Just arrange for it to be built after meta-gtk-osx-gtk3 and it will overwrite 
the current Adwaita-42.

The longer-term fix is to switch to the newer foo-symbolic names, e.g. 
"document-new-symbolic". You should do that soon because the legacy icons will 
disappear from Linux distros soon if they haven't already, particularly on 
bleeding-edge distros like Arch Linux and Gentoo. I don't know if all of the 
legacy icons were converted, so you may need to find alternatives or design 
your own in some cases.

Regards,
John Ralls



On Jun 30, 2022, at 4:14 AM, Miroslav Rajcic  wrote:

I've been converting from stock icons to symbolic icons, but no luck so far.

Example code (both GTK2 and GTK3 builds are supported):
#if GTK_CHECK_VERSION(3,10,0)
icon = gtk_image_new_from_icon_name("edit-delete", 
GTK_ICON_SIZE_MENU);
#else
icon = gtk_image_new_from_stock(GTK_STOCK_DELETE, 
GTK_ICON_SIZE_MENU);
#endif

As I can see adwaita theme icons are correctly bundled, and I added test code 
on startup to write the theme name and search paths:
gchar* szIconTheme = nullptr;
g_object_get(gtk_settings_get_default(), "gtk-icon-theme-name", 
, (char*) nullptr);
XLOG(LL_INFO, "Icon theme used: %s\n", szIconTheme);
g_free(szIconTheme);

  gint n_elements = 0;
  gchar **path;
  gtk_icon_theme_get_search_path(gtk_icon_theme_get_default(), , 
_elements);
  for(int j=0; j-symbolic.symbolic.png" files):
http://notecase.sourceforge.net/temp/notecase-4.6.5pre2.pkg<http://notecase.sourceforge.net/temp/notecase-4.6.5pre2.pkg.filepart>

Any idea how to debug this?
Can I perhaps activate an additional GTK logging for the GTK theme related code 
through GTK_DEBUG variable or something similar?

Best regards,
  Miroslav


From: gtk-osx-users-list  on behalf of 
Miroslav Rajcic via gtk-osx-users-list 
Sent: Sunday, June 26, 2022 7:52 PM
To: john 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Will do, thanks!

Best regards,
  Miroslav

From: john 
Sent: Sunday, June 26, 2022 6:24 PM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

That's good news, and I tested it here as well. Don't forget to investigate the 
toolbar icons and menu. BTW, File>Quit doesn't work though command-Q does.

Regards,
John Ralls

On Jun 26, 2022, at 1:01 AM, Miroslav Rajcic  wrote:

Hi John,

I've got confirmation that the following new build works OK for the user:
http://notecase.sourceforge.net/temp/notecase-4.6.5.pkg

Changelog: I've updated the launcher script, set the target to 10.12 (as you've 
done) and removed libspell.
I can now experiment to see which of these helped to resolve the issue.

Thanks again for your help.

Best regards,
   Miroslav

From: gtk-osx-users-list  on behalf of 
Miroslav Rajcic via gtk-osx-users-list 
Sent: Saturday, June 25, 2022 11:34 AM
To: John Ralls 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Thanks John,

will work to fix the issues you've observed.

Best regards,
Miroslav


From: John Ralls 
Sent: Saturday, June 25, 2022 1:45 AM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

I built a 

Re: [gtk-osx-users] Black screen on ARM based Macs

[john]

Miroslav,

The basic problem is that all of those color icons were declared "legacy" by 
the Gnome designers a long time ago and Adwaita-icon-theme v42 finally removed 
them. As it happens that broke a Gtk test, see 
https://gitlab.gnome.org/GNOME/gtk/-/issues/4754, so they've been added back to 
Gtk-3.24.34. Another "but": It's only the legacy icons used by Gtk3 itself, so 
it might not cover all of the icons you need.

The simplest temporary fix is to add a module for an older Adwaita version to 
your local moduleset. I picked 3.38.0 for GnuCash, see 
https://github.com/Gnucash/gnucash-on-osx/blob/cd34a47d2236929c931a8676845b5714e2ccde20/modulesets/gnucash.modules#L376.
 Just arrange for it to be built after meta-gtk-osx-gtk3 and it will overwrite 
the current Adwaita-42.

The longer-term fix is to switch to the newer foo-symbolic names, e.g. 
"document-new-symbolic". You should do that soon because the legacy icons will 
disappear from Linux distros soon if they haven't already, particularly on 
bleeding-edge distros like Arch Linux and Gentoo. I don't know if all of the 
legacy icons were converted, so you may need to find alternatives or design 
your own in some cases.

Regards,
John Ralls


 
> On Jun 30, 2022, at 4:14 AM, Miroslav Rajcic  wrote:
> 
> I've been converting from stock icons to symbolic icons, but no luck so far.
> 
> Example code (both GTK2 and GTK3 builds are supported):
> #if GTK_CHECK_VERSION(3,10,0)
> icon = gtk_image_new_from_icon_name("edit-delete", 
> GTK_ICON_SIZE_MENU);
> #else
> icon = gtk_image_new_from_stock(GTK_STOCK_DELETE, 
> GTK_ICON_SIZE_MENU);
> #endif
> 
> As I can see adwaita theme icons are correctly bundled, and I added test code 
> on startup to write the theme name and search paths:
> gchar* szIconTheme = nullptr;
> g_object_get(gtk_settings_get_default(), "gtk-icon-theme-name", 
> , (char*) nullptr);
> XLOG(LL_INFO, "Icon theme used: %s\n", szIconTheme);
> g_free(szIconTheme);
> 
>   gint n_elements = 0;
>   gchar **path;
>   gtk_icon_theme_get_search_path(gtk_icon_theme_get_default(), , 
> _elements);
>   for(int j=0; j XLOG(LL_INFO, "Icon path: %s\n", path[j]);
> 
> Logs below indicate that the search paths are correct, but the icons can not 
> be found anyway:
> 12:38:03.534 Icon theme used: Adwaita
> 12:38:03.534 Icon path: /Users/gtk3/.local/share/icons
> 12:38:03.534 Icon path: /Users/gtk3/.icons
> 12:38:03.534 Icon path: 
> /Applications/NotecasePro.app/Contents/Resources/share/icons
> 12:38:03.534 Icon path: 
> /Applications/NotecasePro.app/Contents/Resources/share/pixmaps
> ...
> 12:38:03.925 GTK [16]:
> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.925: Error loading theme icon 
> 'document-new' for stock: Icon 'document-new' not present in theme Adwaita
> 12:38:03.927 GTK [16]: 
> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.927: Error loading theme icon 
> 'document-open' for stock: Icon 'document-open' not present in theme Adwaita
> 12:38:03.927 GTK [16]: 
> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.927: Error loading theme icon 
> 'document-save' for stock: Icon 'document-save' not present in theme Adwaita
> 12:38:03.928 GTK [16]: 
> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.928: Error loading theme icon 
> 'list-add' for stock: Icon 'list-add' not present in theme Adwaita
> 12:38:03.928 GTK [16]: 
> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.928: Error loading theme icon 
> 'go-previous' for stock:
> 12:38:03.928 GTK [16]: 
> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.928: Error loading theme icon 
> 'go-next' for stock:
> 12:38:03.928 GTK [16]: 
> (notecase-bin:79345): Gtk-WARNING **: 12:38:03.928: Error loading theme icon 
> 'edit-undo' for stock:
> 
> I've uploaded the new build, as it seems the icons are correctly bundled (lot 
> of "-symbolic.symbolic.png" files):
> http://notecase.sourceforge.net/temp/notecase-4.6.5pre2.pkg 
> <http://notecase.sourceforge.net/temp/notecase-4.6.5pre2.pkg.filepart>
> 
> Any idea how to debug this?
> Can I perhaps activate an additional GTK logging for the GTK theme related 
> code through GTK_DEBUG variable or something similar?
> 
> Best regards,
>   Miroslav
> 
> From: gtk-osx-users-list  on behalf of 
> Miroslav Rajcic via gtk-osx-users-list 
> Sent: Sunday, June 26, 2022 7:52 PM
> To: john 
> Cc: gtk-osx-users-list@gnome.org 
> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>  
> Will do, thanks!
> 
> Best regards,
>   Miroslav
> From: john 
> Sent: Sunday, June 26, 2022 6:24 PM
> To: Miroslav Rajcic 
> Cc: gtk-osx-users-list@gnome.org 
> Subject: Re: [gtk-osx-users] Black screen on 

Re: [gtk-osx-users] Black screen on ARM based Macs

[Miroslav Rajcic via gtk-osx-users-list]

I've been converting from stock icons to symbolic icons, but no luck so far.

Example code (both GTK2 and GTK3 builds are supported):
#if GTK_CHECK_VERSION(3,10,0)
icon = gtk_image_new_from_icon_name("edit-delete", 
GTK_ICON_SIZE_MENU);
#else
icon = gtk_image_new_from_stock(GTK_STOCK_DELETE, 
GTK_ICON_SIZE_MENU);
#endif

As I can see adwaita theme icons are correctly bundled, and I added test code 
on startup to write the theme name and search paths:
gchar* szIconTheme = nullptr;
g_object_get(gtk_settings_get_default(), "gtk-icon-theme-name", 
, (char*) nullptr);
XLOG(LL_INFO, "Icon theme used: %s\n", szIconTheme);
g_free(szIconTheme);

  gint n_elements = 0;
  gchar **path;
  gtk_icon_theme_get_search_path(gtk_icon_theme_get_default(), , 
_elements);
  for(int j=0; j-symbolic.symbolic.png" files):
http://notecase.sourceforge.net/temp/notecase-4.6.5pre2.pkg<http://notecase.sourceforge.net/temp/notecase-4.6.5pre2.pkg.filepart>

Any idea how to debug this?
Can I perhaps activate an additional GTK logging for the GTK theme related code 
through GTK_DEBUG variable or something similar?

Best regards,
  Miroslav


From: gtk-osx-users-list  on behalf of 
Miroslav Rajcic via gtk-osx-users-list 
Sent: Sunday, June 26, 2022 7:52 PM
To: john 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Will do, thanks!

Best regards,
  Miroslav

From: john 
Sent: Sunday, June 26, 2022 6:24 PM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

That's good news, and I tested it here as well. Don't forget to investigate the 
toolbar icons and menu. BTW, File>Quit doesn't work though command-Q does.

Regards,
John Ralls

On Jun 26, 2022, at 1:01 AM, Miroslav Rajcic  wrote:

Hi John,

I've got confirmation that the following new build works OK for the user:
http://notecase.sourceforge.net/temp/notecase-4.6.5.pkg

Changelog: I've updated the launcher script, set the target to 10.12 (as you've 
done) and removed libspell.
I can now experiment to see which of these helped to resolve the issue.

Thanks again for your help.

Best regards,
   Miroslav

From: gtk-osx-users-list  on behalf of 
Miroslav Rajcic via gtk-osx-users-list 
Sent: Saturday, June 25, 2022 11:34 AM
To: John Ralls 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Thanks John,

will work to fix the issues you've observed.

Best regards,
Miroslav


From: John Ralls 
Sent: Saturday, June 25, 2022 1:45 AM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

I built a fresh meta-gtk-osx-gtk3 with macOS version min set to 10.12, 
symlinked $PREFIX/inst to $PREFIX/Resources and copied notecore-bin to 
$PREFIX/MacOS/notecore so that it would find my libraries with 
@executable_path/../Resources, then ran notecore from a jhbuild shell. It 
displayed correctly on both Retina and not. That tells me that whatever is 
messed up it isn't Gtk.

There seems to be a lot of extraneous stuff in your bundle as well, your 
launcher-script looks rather haphazardly ported from a Gtk2 one, and libspell 
is in the wrong place.  So start off with a fresh build of meta-gtk-osx-gtk3 in 
an empty folder starting with bootstrap-gtk-osx and for safety libspell too. 
While the build is going on clean up your bundle file so that only the 
libraries and other folders that you need are installed and redo your launcher 
script based on gtk-mac-bundler/examples/gtk3-launcher.sh.

Some other things that need addressing: You seem not to have updated your use 
of gtk-mac-integration for Gtk3: It doesn't work, the menu bar is on the window 
instead of at the top of the screen. The Gtk-supplied icons aren't visible, 
perhaps you're trying to use the GTK_STOCK icons that were deprecated in 
Gtk-3.0.0 and removed somewhere around Gtk 3.10. I thought at first you'd 
gotten tripped up with the removal of the deprecated stock names in Adwaita-42, 
but they don't work with Adwaita-3.38 either.

Once you've got a clean bundle I'll test it for you, but you might want to get 
the Additional Tools for Xcode 13 from https://developer.apple.com/downloads. 
It includes Quartz Debug that might enable you to fake retina resolution if 
your MBA has enough GPU to support it.

Regards,
John Ralls


> On Jun 24, 2022, at 2:17 PM, John Ralls  wrote:
>
> Miroslav,
>
> Thanks. I can confirm that it’s a Retina issue, not an Apple Silicon one. I 
> have the same 1/4 render on my Retina monitor on both my Intel Mac Pro and my 
> M1 mini. It looks normal on the non-Retina monitor on both systems.
> Next I tried my 2014 MBP Retina running macOS 11 BigSur. Sam

Re: [gtk-osx-users] Black screen on ARM based Macs

[Miroslav Rajcic via gtk-osx-users-list]

Will do, thanks!

Best regards,
  Miroslav

From: john 
Sent: Sunday, June 26, 2022 6:24 PM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

That's good news, and I tested it here as well. Don't forget to investigate the 
toolbar icons and menu. BTW, File>Quit doesn't work though command-Q does.

Regards,
John Ralls

On Jun 26, 2022, at 1:01 AM, Miroslav Rajcic  wrote:

Hi John,

I've got confirmation that the following new build works OK for the user:
http://notecase.sourceforge.net/temp/notecase-4.6.5.pkg

Changelog: I've updated the launcher script, set the target to 10.12 (as you've 
done) and removed libspell.
I can now experiment to see which of these helped to resolve the issue.

Thanks again for your help.

Best regards,
   Miroslav

From: gtk-osx-users-list  on behalf of 
Miroslav Rajcic via gtk-osx-users-list 
Sent: Saturday, June 25, 2022 11:34 AM
To: John Ralls 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Thanks John,

will work to fix the issues you've observed.

Best regards,
Miroslav


From: John Ralls 
Sent: Saturday, June 25, 2022 1:45 AM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

I built a fresh meta-gtk-osx-gtk3 with macOS version min set to 10.12, 
symlinked $PREFIX/inst to $PREFIX/Resources and copied notecore-bin to 
$PREFIX/MacOS/notecore so that it would find my libraries with 
@executable_path/../Resources, then ran notecore from a jhbuild shell. It 
displayed correctly on both Retina and not. That tells me that whatever is 
messed up it isn't Gtk.

There seems to be a lot of extraneous stuff in your bundle as well, your 
launcher-script looks rather haphazardly ported from a Gtk2 one, and libspell 
is in the wrong place.  So start off with a fresh build of meta-gtk-osx-gtk3 in 
an empty folder starting with bootstrap-gtk-osx and for safety libspell too. 
While the build is going on clean up your bundle file so that only the 
libraries and other folders that you need are installed and redo your launcher 
script based on gtk-mac-bundler/examples/gtk3-launcher.sh.

Some other things that need addressing: You seem not to have updated your use 
of gtk-mac-integration for Gtk3: It doesn't work, the menu bar is on the window 
instead of at the top of the screen. The Gtk-supplied icons aren't visible, 
perhaps you're trying to use the GTK_STOCK icons that were deprecated in 
Gtk-3.0.0 and removed somewhere around Gtk 3.10. I thought at first you'd 
gotten tripped up with the removal of the deprecated stock names in Adwaita-42, 
but they don't work with Adwaita-3.38 either.

Once you've got a clean bundle I'll test it for you, but you might want to get 
the Additional Tools for Xcode 13 from https://developer.apple.com/downloads. 
It includes Quartz Debug that might enable you to fake retina resolution if 
your MBA has enough GPU to support it.

Regards,
John Ralls


> On Jun 24, 2022, at 2:17 PM, John Ralls  wrote:
>
> Miroslav,
>
> Thanks. I can confirm that it’s a Retina issue, not an Apple Silicon one. I 
> have the same 1/4 render on my Retina monitor on both my Intel Mac Pro and my 
> M1 mini. It looks normal on the non-Retina monitor on both systems.
> Next I tried my 2014 MBP Retina running macOS 11 BigSur. Same problem. Maybe 
> this is your user’s first experience with Retina displays?
>
> I hadn’t really paid attention to 
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4342#note_1299321 until now. I 
> think that’s a separate issue from the Monterey absolute value change that 
> screwed up flipping the coordinate system. His issue appears similar to yours 
> and he worked around it by removing the scaling 
> line,https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L194
>  , altogether. I’m not sure why that would be necessary for you and him and 
> not for anybody else. That line has been there for 6 years, having been 
> introduced in 
> https://gitlab.gnome.org/GNOME/gtk/-/commit/3f077ec36f4a59e803c9f4509996269c862e04af.
>  Note that the scale division in the CTM is countered by scaling the size of 
> the Cairo surface 
> athttps://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L352.
>
> Regards,
> John Ralls
>
>
>
>> On Jun 24, 2022, at 12:01 PM, Miroslav Rajcic  wrote:
>>
>> Hi John,
>>
>> you can find the installer with new build here:
>> http://notecase.sourceforge.net/temp/notecase-4.6.4pre1.pkg
>>
>> Thanks for the help.
>>
>> Best regards,
>>  Miroslav
>>
>> From: john 
>> Sent: Friday, June 24, 2022 7:49 PM
>> To: Miroslav Rajcic 
>&

Re: [gtk-osx-users] Black screen on ARM based Macs

[john]

Miroslav,

That's good news, and I tested it here as well. Don't forget to investigate the 
toolbar icons and menu. BTW, File>Quit doesn't work though command-Q does.

Regards,
John Ralls

> On Jun 26, 2022, at 1:01 AM, Miroslav Rajcic  wrote:
> 
> Hi John,
> 
> I've got confirmation that the following new build works OK for the user:
> http://notecase.sourceforge.net/temp/notecase-4.6.5.pkg
> 
> Changelog: I've updated the launcher script, set the target to 10.12 (as 
> you've done) and removed libspell.
> I can now experiment to see which of these helped to resolve the issue.
> 
> Thanks again for your help.
> 
> Best regards,
>Miroslav
> From: gtk-osx-users-list  on behalf of 
> Miroslav Rajcic via gtk-osx-users-list 
> Sent: Saturday, June 25, 2022 11:34 AM
> To: John Ralls 
> Cc: gtk-osx-users-list@gnome.org 
> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>  
> Thanks John,
> 
> will work to fix the issues you've observed.
> 
> Best regards,
> Miroslav
> 
> From: John Ralls 
> Sent: Saturday, June 25, 2022 1:45 AM
> To: Miroslav Rajcic 
> Cc: gtk-osx-users-list@gnome.org 
> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>  
> Miroslav,
> 
> I built a fresh meta-gtk-osx-gtk3 with macOS version min set to 10.12, 
> symlinked $PREFIX/inst to $PREFIX/Resources and copied notecore-bin to 
> $PREFIX/MacOS/notecore so that it would find my libraries with 
> @executable_path/../Resources, then ran notecore from a jhbuild shell. It 
> displayed correctly on both Retina and not. That tells me that whatever is 
> messed up it isn't Gtk.
> 
> There seems to be a lot of extraneous stuff in your bundle as well, your 
> launcher-script looks rather haphazardly ported from a Gtk2 one, and libspell 
> is in the wrong place.  So start off with a fresh build of meta-gtk-osx-gtk3 
> in an empty folder starting with bootstrap-gtk-osx and for safety libspell 
> too. While the build is going on clean up your bundle file so that only the 
> libraries and other folders that you need are installed and redo your 
> launcher script based on gtk-mac-bundler/examples/gtk3-launcher.sh.
> 
> Some other things that need addressing: You seem not to have updated your use 
> of gtk-mac-integration for Gtk3: It doesn't work, the menu bar is on the 
> window instead of at the top of the screen. The Gtk-supplied icons aren't 
> visible, perhaps you're trying to use the GTK_STOCK icons that were 
> deprecated in Gtk-3.0.0 and removed somewhere around Gtk 3.10. I thought at 
> first you'd gotten tripped up with the removal of the deprecated stock names 
> in Adwaita-42, but they don't work with Adwaita-3.38 either.
> 
> Once you've got a clean bundle I'll test it for you, but you might want to 
> get the Additional Tools for Xcode 13 from 
> https://developer.apple.com/downloads. It includes Quartz Debug that might 
> enable you to fake retina resolution if your MBA has enough GPU to support it.
> 
> Regards,
> John Ralls
> 
> 
> > On Jun 24, 2022, at 2:17 PM, John Ralls  wrote:
> > 
> > Miroslav,
> > 
> > Thanks. I can confirm that it’s a Retina issue, not an Apple Silicon one. I 
> > have the same 1/4 render on my Retina monitor on both my Intel Mac Pro and 
> > my M1 mini. It looks normal on the non-Retina monitor on both systems.
> > Next I tried my 2014 MBP Retina running macOS 11 BigSur. Same problem. 
> > Maybe this is your user’s first experience with Retina displays? 
> > 
> > I hadn’t really paid attention to 
> > https://gitlab.gnome.org/GNOME/gtk/-/issues/4342#note_1299321 until now. I 
> > think that’s a separate issue from the Monterey absolute value change that 
> > screwed up flipping the coordinate system. His issue appears similar to 
> > yours and he worked around it by removing the scaling 
> > line,https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L194
> >  , altogether. I’m not sure why that would be necessary for you and him and 
> > not for anybody else. That line has been there for 6 years, having been 
> > introduced in 
> > https://gitlab.gnome.org/GNOME/gtk/-/commit/3f077ec36f4a59e803c9f4509996269c862e04af.
> >  Note that the scale division in the CTM is countered by scaling the size 
> > of the Cairo surface 
> > athttps://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L352.
> > 
> > Regards,
> > John Ralls
> > 
> > 
> > 
> >> On Jun 24, 2022, at 12:01 PM, Miroslav Rajcic  wrote:
> >> 
> >> Hi John,
> >> 
> >> you can find the installer with new build here:
> >> http://notecase.sourcefo

Re: [gtk-osx-users] Black screen on ARM based Macs

[Miroslav Rajcic via gtk-osx-users-list]

Hi John,

I've got confirmation that the following new build works OK for the user:
http://notecase.sourceforge.net/temp/notecase-4.6.5.pkg

Changelog: I've updated the launcher script, set the target to 10.12 (as you've 
done) and removed libspell.
I can now experiment to see which of these helped to resolve the issue.

Thanks again for your help.

Best regards,
   Miroslav

From: gtk-osx-users-list  on behalf of 
Miroslav Rajcic via gtk-osx-users-list 
Sent: Saturday, June 25, 2022 11:34 AM
To: John Ralls 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Thanks John,

will work to fix the issues you've observed.

Best regards,
Miroslav


From: John Ralls 
Sent: Saturday, June 25, 2022 1:45 AM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

I built a fresh meta-gtk-osx-gtk3 with macOS version min set to 10.12, 
symlinked $PREFIX/inst to $PREFIX/Resources and copied notecore-bin to 
$PREFIX/MacOS/notecore so that it would find my libraries with 
@executable_path/../Resources, then ran notecore from a jhbuild shell. It 
displayed correctly on both Retina and not. That tells me that whatever is 
messed up it isn't Gtk.

There seems to be a lot of extraneous stuff in your bundle as well, your 
launcher-script looks rather haphazardly ported from a Gtk2 one, and libspell 
is in the wrong place.  So start off with a fresh build of meta-gtk-osx-gtk3 in 
an empty folder starting with bootstrap-gtk-osx and for safety libspell too. 
While the build is going on clean up your bundle file so that only the 
libraries and other folders that you need are installed and redo your launcher 
script based on gtk-mac-bundler/examples/gtk3-launcher.sh.

Some other things that need addressing: You seem not to have updated your use 
of gtk-mac-integration for Gtk3: It doesn't work, the menu bar is on the window 
instead of at the top of the screen. The Gtk-supplied icons aren't visible, 
perhaps you're trying to use the GTK_STOCK icons that were deprecated in 
Gtk-3.0.0 and removed somewhere around Gtk 3.10. I thought at first you'd 
gotten tripped up with the removal of the deprecated stock names in Adwaita-42, 
but they don't work with Adwaita-3.38 either.

Once you've got a clean bundle I'll test it for you, but you might want to get 
the Additional Tools for Xcode 13 from https://developer.apple.com/downloads. 
It includes Quartz Debug that might enable you to fake retina resolution if 
your MBA has enough GPU to support it.

Regards,
John Ralls


> On Jun 24, 2022, at 2:17 PM, John Ralls  wrote:
>
> Miroslav,
>
> Thanks. I can confirm that it’s a Retina issue, not an Apple Silicon one. I 
> have the same 1/4 render on my Retina monitor on both my Intel Mac Pro and my 
> M1 mini. It looks normal on the non-Retina monitor on both systems.
> Next I tried my 2014 MBP Retina running macOS 11 BigSur. Same problem. Maybe 
> this is your user’s first experience with Retina displays?
>
> I hadn’t really paid attention to 
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4342#note_1299321 until now. I 
> think that’s a separate issue from the Monterey absolute value change that 
> screwed up flipping the coordinate system. His issue appears similar to yours 
> and he worked around it by removing the scaling 
> line,https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L194
>  , altogether. I’m not sure why that would be necessary for you and him and 
> not for anybody else. That line has been there for 6 years, having been 
> introduced in 
> https://gitlab.gnome.org/GNOME/gtk/-/commit/3f077ec36f4a59e803c9f4509996269c862e04af.
>  Note that the scale division in the CTM is countered by scaling the size of 
> the Cairo surface at 
> https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L352.
>
> Regards,
> John Ralls
>
>
>
>> On Jun 24, 2022, at 12:01 PM, Miroslav Rajcic  wrote:
>>
>> Hi John,
>>
>> you can find the installer with new build here:
>> http://notecase.sourceforge.net/temp/notecase-4.6.4pre1.pkg
>>
>> Thanks for the help.
>>
>> Best regards,
>>  Miroslav
>>
>> From: john 
>> Sent: Friday, June 24, 2022 7:49 PM
>> To: Miroslav Rajcic 
>> Cc: gtk-osx-users-list@gnome.org 
>> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>>
>> Miroslav,
>>
>> I installed NoteCasePro from your download page to my M1Pro MBP running the 
>> Ventura developer beta and it looks just like your screenshot. It also has 
>> Gtk-3.24.30. Can you give me a link to your Gtk3.24.33 installer?
>>
>> I think that the reason you can't see the problem is that your 2017 MBA 
>

Re: [gtk-osx-users] Black screen on ARM based Macs

[Miroslav Rajcic via gtk-osx-users-list]

Thanks John,

will work to fix the issues you've observed.

Best regards,
Miroslav


From: John Ralls 
Sent: Saturday, June 25, 2022 1:45 AM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

I built a fresh meta-gtk-osx-gtk3 with macOS version min set to 10.12, 
symlinked $PREFIX/inst to $PREFIX/Resources and copied notecore-bin to 
$PREFIX/MacOS/notecore so that it would find my libraries with 
@executable_path/../Resources, then ran notecore from a jhbuild shell. It 
displayed correctly on both Retina and not. That tells me that whatever is 
messed up it isn't Gtk.

There seems to be a lot of extraneous stuff in your bundle as well, your 
launcher-script looks rather haphazardly ported from a Gtk2 one, and libspell 
is in the wrong place.  So start off with a fresh build of meta-gtk-osx-gtk3 in 
an empty folder starting with bootstrap-gtk-osx and for safety libspell too. 
While the build is going on clean up your bundle file so that only the 
libraries and other folders that you need are installed and redo your launcher 
script based on gtk-mac-bundler/examples/gtk3-launcher.sh.

Some other things that need addressing: You seem not to have updated your use 
of gtk-mac-integration for Gtk3: It doesn't work, the menu bar is on the window 
instead of at the top of the screen. The Gtk-supplied icons aren't visible, 
perhaps you're trying to use the GTK_STOCK icons that were deprecated in 
Gtk-3.0.0 and removed somewhere around Gtk 3.10. I thought at first you'd 
gotten tripped up with the removal of the deprecated stock names in Adwaita-42, 
but they don't work with Adwaita-3.38 either.

Once you've got a clean bundle I'll test it for you, but you might want to get 
the Additional Tools for Xcode 13 from https://developer.apple.com/downloads. 
It includes Quartz Debug that might enable you to fake retina resolution if 
your MBA has enough GPU to support it.

Regards,
John Ralls


> On Jun 24, 2022, at 2:17 PM, John Ralls  wrote:
>
> Miroslav,
>
> Thanks. I can confirm that it’s a Retina issue, not an Apple Silicon one. I 
> have the same 1/4 render on my Retina monitor on both my Intel Mac Pro and my 
> M1 mini. It looks normal on the non-Retina monitor on both systems.
> Next I tried my 2014 MBP Retina running macOS 11 BigSur. Same problem. Maybe 
> this is your user’s first experience with Retina displays?
>
> I hadn’t really paid attention to 
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4342#note_1299321 until now. I 
> think that’s a separate issue from the Monterey absolute value change that 
> screwed up flipping the coordinate system. His issue appears similar to yours 
> and he worked around it by removing the scaling 
> line,https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L194
>  , altogether. I’m not sure why that would be necessary for you and him and 
> not for anybody else. That line has been there for 6 years, having been 
> introduced in 
> https://gitlab.gnome.org/GNOME/gtk/-/commit/3f077ec36f4a59e803c9f4509996269c862e04af.
>  Note that the scale division in the CTM is countered by scaling the size of 
> the Cairo surface at 
> https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L352.
>
> Regards,
> John Ralls
>
>
>
>> On Jun 24, 2022, at 12:01 PM, Miroslav Rajcic  wrote:
>>
>> Hi John,
>>
>> you can find the installer with new build here:
>> http://notecase.sourceforge.net/temp/notecase-4.6.4pre1.pkg
>>
>> Thanks for the help.
>>
>> Best regards,
>>  Miroslav
>>
>> From: john 
>> Sent: Friday, June 24, 2022 7:49 PM
>> To: Miroslav Rajcic 
>> Cc: gtk-osx-users-list@gnome.org 
>> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>>
>> Miroslav,
>>
>> I installed NoteCasePro from your download page to my M1Pro MBP running the 
>> Ventura developer beta and it looks just like your screenshot. It also has 
>> Gtk-3.24.30. Can you give me a link to your Gtk3.24.33 installer?
>>
>> I think that the reason you can't see the problem is that your 2017 MBA 
>> doesn't have a Retina display. I'll check it on my MacPro that does have a 
>> Retina display in a bit and follow up.
>>
>> I haven't tried cross-compiling to arm64 from intel yet, but it didn't work 
>> at all back in the PPC->Intel days so when I was distributing PPC apps I 
>> built on the respective machines. Universal builds definitely don't work 
>> from the command line, I did try that. I can also say that I haven't seen 
>> any significant behavior differences between running Intel builds with 
>> Rosetta2 and native builds on M1s, so I think it's unlikely that that'

Re: [gtk-osx-users] Black screen on ARM based Macs

[John Ralls]

Miroslav,

I built a fresh meta-gtk-osx-gtk3 with macOS version min set to 10.12, 
symlinked $PREFIX/inst to $PREFIX/Resources and copied notecore-bin to 
$PREFIX/MacOS/notecore so that it would find my libraries with 
@executable_path/../Resources, then ran notecore from a jhbuild shell. It 
displayed correctly on both Retina and not. That tells me that whatever is 
messed up it isn't Gtk.

There seems to be a lot of extraneous stuff in your bundle as well, your 
launcher-script looks rather haphazardly ported from a Gtk2 one, and libspell 
is in the wrong place.  So start off with a fresh build of meta-gtk-osx-gtk3 in 
an empty folder starting with bootstrap-gtk-osx and for safety libspell too. 
While the build is going on clean up your bundle file so that only the 
libraries and other folders that you need are installed and redo your launcher 
script based on gtk-mac-bundler/examples/gtk3-launcher.sh.

Some other things that need addressing: You seem not to have updated your use 
of gtk-mac-integration for Gtk3: It doesn't work, the menu bar is on the window 
instead of at the top of the screen. The Gtk-supplied icons aren't visible, 
perhaps you're trying to use the GTK_STOCK icons that were deprecated in 
Gtk-3.0.0 and removed somewhere around Gtk 3.10. I thought at first you'd 
gotten tripped up with the removal of the deprecated stock names in Adwaita-42, 
but they don't work with Adwaita-3.38 either.

Once you've got a clean bundle I'll test it for you, but you might want to get 
the Additional Tools for Xcode 13 from https://developer.apple.com/downloads. 
It includes Quartz Debug that might enable you to fake retina resolution if 
your MBA has enough GPU to support it.

Regards,
John Ralls


> On Jun 24, 2022, at 2:17 PM, John Ralls  wrote:
> 
> Miroslav,
> 
> Thanks. I can confirm that it’s a Retina issue, not an Apple Silicon one. I 
> have the same 1/4 render on my Retina monitor on both my Intel Mac Pro and my 
> M1 mini. It looks normal on the non-Retina monitor on both systems.
> Next I tried my 2014 MBP Retina running macOS 11 BigSur. Same problem. Maybe 
> this is your user’s first experience with Retina displays? 
> 
> I hadn’t really paid attention to 
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4342#note_1299321 until now. I 
> think that’s a separate issue from the Monterey absolute value change that 
> screwed up flipping the coordinate system. His issue appears similar to yours 
> and he worked around it by removing the scaling 
> line,https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L194
>  , altogether. I’m not sure why that would be necessary for you and him and 
> not for anybody else. That line has been there for 6 years, having been 
> introduced in 
> https://gitlab.gnome.org/GNOME/gtk/-/commit/3f077ec36f4a59e803c9f4509996269c862e04af.
>  Note that the scale division in the CTM is countered by scaling the size of 
> the Cairo surface at 
> https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L352.
> 
> Regards,
> John Ralls
> 
> 
> 
>> On Jun 24, 2022, at 12:01 PM, Miroslav Rajcic  wrote:
>> 
>> Hi John,
>> 
>> you can find the installer with new build here:
>> http://notecase.sourceforge.net/temp/notecase-4.6.4pre1.pkg
>> 
>> Thanks for the help.
>> 
>> Best regards,
>>  Miroslav
>> 
>> From: john 
>> Sent: Friday, June 24, 2022 7:49 PM
>> To: Miroslav Rajcic 
>> Cc: gtk-osx-users-list@gnome.org 
>> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>> 
>> Miroslav,
>> 
>> I installed NoteCasePro from your download page to my M1Pro MBP running the 
>> Ventura developer beta and it looks just like your screenshot. It also has 
>> Gtk-3.24.30. Can you give me a link to your Gtk3.24.33 installer?
>> 
>> I think that the reason you can't see the problem is that your 2017 MBA 
>> doesn't have a Retina display. I'll check it on my MacPro that does have a 
>> Retina display in a bit and follow up.
>> 
>> I haven't tried cross-compiling to arm64 from intel yet, but it didn't work 
>> at all back in the PPC->Intel days so when I was distributing PPC apps I 
>> built on the respective machines. Universal builds definitely don't work 
>> from the command line, I did try that. I can also say that I haven't seen 
>> any significant behavior differences between running Intel builds with 
>> Rosetta2 and native builds on M1s, so I think it's unlikely that that's the 
>> problem. The Xcode version shouldn't matter either.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>> 
>>> On Jun 24, 2022, at 5:45 AM, Miroslav Rajcic  wrote:
>>> 
>>> Thanks John,
>>> 
>>

Re: [gtk-osx-users] Black screen on ARM based Macs

[John Ralls]

Miroslav,

Thanks. I can confirm that it’s a Retina issue, not an Apple Silicon one. I 
have the same 1/4 render on my Retina monitor on both my Intel Mac Pro and my 
M1 mini. It looks normal on the non-Retina monitor on both systems.
Next I tried my 2014 MBP Retina running macOS 11 BigSur. Same problem. Maybe 
this is your user’s first experience with Retina displays? 

I hadn’t really paid attention to 
https://gitlab.gnome.org/GNOME/gtk/-/issues/4342#note_1299321 until now. I 
think that’s a separate issue from the Monterey absolute value change that 
screwed up flipping the coordinate system. His issue appears similar to yours 
and he worked around it by removing the scaling 
line,https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L194
 , altogether. I’m not sure why that would be necessary for you and him and not 
for anybody else. That line has been there for 6 years, having been introduced 
in 
https://gitlab.gnome.org/GNOME/gtk/-/commit/3f077ec36f4a59e803c9f4509996269c862e04af.
 Note that the scale division in the CTM is countered by scaling the size of 
the Cairo surface at 
https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/quartz/gdkwindow-quartz.c#L352.

Regards,
John Ralls



> On Jun 24, 2022, at 12:01 PM, Miroslav Rajcic  wrote:
> 
> Hi John,
> 
> you can find the installer with new build here:
> http://notecase.sourceforge.net/temp/notecase-4.6.4pre1.pkg
> 
> Thanks for the help.
> 
> Best regards,
>   Miroslav
> 
> From: john 
> Sent: Friday, June 24, 2022 7:49 PM
> To: Miroslav Rajcic 
> Cc: gtk-osx-users-list@gnome.org 
> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>  
> Miroslav,
> 
> I installed NoteCasePro from your download page to my M1Pro MBP running the 
> Ventura developer beta and it looks just like your screenshot. It also has 
> Gtk-3.24.30. Can you give me a link to your Gtk3.24.33 installer?
> 
> I think that the reason you can't see the problem is that your 2017 MBA 
> doesn't have a Retina display. I'll check it on my MacPro that does have a 
> Retina display in a bit and follow up.
> 
> I haven't tried cross-compiling to arm64 from intel yet, but it didn't work 
> at all back in the PPC->Intel days so when I was distributing PPC apps I 
> built on the respective machines. Universal builds definitely don't work from 
> the command line, I did try that. I can also say that I haven't seen any 
> significant behavior differences between running Intel builds with Rosetta2 
> and native builds on M1s, so I think it's unlikely that that's the problem. 
> The Xcode version shouldn't matter either.
> 
> Regards,
> John Ralls
> 
> 
> 
>> On Jun 24, 2022, at 5:45 AM, Miroslav Rajcic  wrote:
>> 
>> Thanks John,
>> 
>> I don't have M1 hardware, so I depend on users to help troubleshooting the 
>> issue. 
>> 
>> I do my build on Intel hardware (macOS 12.0.1, MacBook Air 2017, XCode 
>> 13.2.1), with the following target setup:
>> setup_sdk(target="10.9", sdk_version="native", architectures=["x86_64"])
>> i.e. program is being run on M1 through Rosetta.
>> 
>> The issue was reported against the build using GTK 3.24.30, then I've 
>> rebuilt the program to use latest v3.24.33,
>> but both users reported that the issue was not fixed (screenshots below). 
>> They are not developers, so they did not try running gtk-demo.
>> 
>> I do have an app log that redirects all GTK logging, but could not find any 
>> clue (GTK error/warning) in it. The same binary works fine
>> on Intel hardware, no such issues were reported.
>> I will re-check to make sure they properly installed the newer build.
>> 
>> Could adding native "arm64" architecture into the setup help with this bug 
>> (based on the bug that was fixed)?
>> Do I need to use newer XCode for this?
>> 
>> Best regards,
>>   Miroslav
>> 
>> 
>> 
>> 
>> 
>> From: john 
>> Sent: Thursday, June 23, 2022 2:30 AM
>> To: Miroslav Rajcic 
>> Cc: gtk-osx-users-list@gnome.org 
>> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>>  
>> 
>> 
>>> On Jun 21, 2022, at 9:50 PM, Miroslav Rajcic via gtk-osx-users-list 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> several users of my program reported the main application screen being 
>>> partially black on ARM based Macs (M1) on macOS Monterey.
>>> Digging online, it seems that this bug has been known:
>>> https://gitlab.gnome.org/GNOME/gtk/-/issues/4342
>>> https://gitlab.gnome.org/GNOME/gtk/-/issues/4395
>>> 
>>> I've rebuilt l

Re: [gtk-osx-users] Black screen on ARM based Macs

[Miroslav Rajcic via gtk-osx-users-list]

Hi John,

you can find the installer with new build here:
http://notecase.sourceforge.net/temp/notecase-4.6.4pre1.pkg

Thanks for the help.

Best regards,
  Miroslav


From: john 
Sent: Friday, June 24, 2022 7:49 PM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs

Miroslav,

I installed NoteCasePro from your download page to my M1Pro MBP running the 
Ventura developer beta and it looks just like your screenshot. It also has 
Gtk-3.24.30. Can you give me a link to your Gtk3.24.33 installer?

I think that the reason you can't see the problem is that your 2017 MBA doesn't 
have a Retina display. I'll check it on my MacPro that does have a Retina 
display in a bit and follow up.

I haven't tried cross-compiling to arm64 from intel yet, but it didn't work at 
all back in the PPC->Intel days so when I was distributing PPC apps I built on 
the respective machines. Universal builds definitely don't work from the 
command line, I did try that. I can also say that I haven't seen any 
significant behavior differences between running Intel builds with Rosetta2 and 
native builds on M1s, so I think it's unlikely that that's the problem. The 
Xcode version shouldn't matter either.

Regards,
John Ralls



On Jun 24, 2022, at 5:45 AM, Miroslav Rajcic  wrote:

Thanks John,

I don't have M1 hardware, so I depend on users to help troubleshooting the 
issue.

I do my build on Intel hardware (macOS 12.0.1, MacBook Air 2017, XCode 13.2.1), 
with the following target setup:
setup_sdk(target="10.9", sdk_version="native", architectures=["x86_64"])
i.e. program is being run on M1 through Rosetta.

The issue was reported against the build using GTK 3.24.30, then I've rebuilt 
the program to use latest v3.24.33,
but both users reported that the issue was not fixed (screenshots below). They 
are not developers, so they did not try running gtk-demo.

I do have an app log that redirects all GTK logging, but could not find any 
clue (GTK error/warning) in it. The same binary works fine
on Intel hardware, no such issues were reported.
I will re-check to make sure they properly installed the newer build.

Could adding native "arm64" architecture into the setup help with this bug 
(based on the bug that was fixed)?
Do I need to use newer XCode for this?

Best regards,
  Miroslav






From: john 
Sent: Thursday, June 23, 2022 2:30 AM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs



On Jun 21, 2022, at 9:50 PM, Miroslav Rajcic via gtk-osx-users-list 
 wrote:

Hi,

several users of my program reported the main application screen being 
partially black on ARM based Macs (M1) on macOS Monterey.
Digging online, it seems that this bug has been known:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4342
https://gitlab.gnome.org/GNOME/gtk/-/issues/4395

I've rebuilt latest gtk-osx yesterday (moduleset-stable), but the issue still 
seems to be here.
What's the status of this issue in gtk-osx?

Miroslav,

The fix for issue 4342 is in Gtk+-3.0 since 3.24.31 and modulesets-stable has 
3.24.33, so perhaps the problem your users have found isn't the same one.

Is this an Apple Silicon build or an Intel one? What minimum macOS version did 
you specify? Does the problem reproduce in gtk3-demo or is it just your app?

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Black screen on ARM based Macs

[john]

Miroslav,

I installed NoteCasePro from your download page to my M1Pro MBP running the 
Ventura developer beta and it looks just like your screenshot. It also has 
Gtk-3.24.30. Can you give me a link to your Gtk3.24.33 installer?

I think that the reason you can't see the problem is that your 2017 MBA doesn't 
have a Retina display. I'll check it on my MacPro that does have a Retina 
display in a bit and follow up.

I haven't tried cross-compiling to arm64 from intel yet, but it didn't work at 
all back in the PPC->Intel days so when I was distributing PPC apps I built on 
the respective machines. Universal builds definitely don't work from the 
command line, I did try that. I can also say that I haven't seen any 
significant behavior differences between running Intel builds with Rosetta2 and 
native builds on M1s, so I think it's unlikely that that's the problem. The 
Xcode version shouldn't matter either.

Regards,
John Ralls



> On Jun 24, 2022, at 5:45 AM, Miroslav Rajcic  wrote:
> 
> Thanks John,
> 
> I don't have M1 hardware, so I depend on users to help troubleshooting the 
> issue. 
> 
> I do my build on Intel hardware (macOS 12.0.1, MacBook Air 2017, XCode 
> 13.2.1), with the following target setup:
> setup_sdk(target="10.9", sdk_version="native", architectures=["x86_64"])
> i.e. program is being run on M1 through Rosetta.
> 
> The issue was reported against the build using GTK 3.24.30, then I've rebuilt 
> the program to use latest v3.24.33,
> but both users reported that the issue was not fixed (screenshots below). 
> They are not developers, so they did not try running gtk-demo.
> 
> I do have an app log that redirects all GTK logging, but could not find any 
> clue (GTK error/warning) in it. The same binary works fine
> on Intel hardware, no such issues were reported.
> I will re-check to make sure they properly installed the newer build.
> 
> Could adding native "arm64" architecture into the setup help with this bug 
> (based on the bug that was fixed)?
> Do I need to use newer XCode for this?
> 
> Best regards,
>   Miroslav
> 
> 
> 
> 
> 
> From: john 
> Sent: Thursday, June 23, 2022 2:30 AM
> To: Miroslav Rajcic 
> Cc: gtk-osx-users-list@gnome.org 
> Subject: Re: [gtk-osx-users] Black screen on ARM based Macs
>  
> 
> 
>> On Jun 21, 2022, at 9:50 PM, Miroslav Rajcic via gtk-osx-users-list 
>>  wrote:
>> 
>> Hi,
>> 
>> several users of my program reported the main application screen being 
>> partially black on ARM based Macs (M1) on macOS Monterey.
>> Digging online, it seems that this bug has been known:
>> https://gitlab.gnome.org/GNOME/gtk/-/issues/4342
>> https://gitlab.gnome.org/GNOME/gtk/-/issues/4395
>> 
>> I've rebuilt latest gtk-osx yesterday (moduleset-stable), but the issue 
>> still seems to be here.
>> What's the status of this issue in gtk-osx?
> 
> Miroslav,
> 
> The fix for issue 4342 is in Gtk+-3.0 since 3.24.31 and modulesets-stable has 
> 3.24.33, so perhaps the problem your users have found isn't the same one. 
> 
> Is this an Apple Silicon build or an Intel one? What minimum macOS version 
> did you specify? Does the problem reproduce in gtk3-demo or is it just your 
> app?
> 
> Regards,
> John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Black screen on ARM based Macs

[Miroslav Rajcic via gtk-osx-users-list]

Thanks John,

I don't have M1 hardware, so I depend on users to help troubleshooting the 
issue.

I do my build on Intel hardware (macOS 12.0.1, MacBook Air 2017, XCode 13.2.1), 
with the following target setup:
setup_sdk(target="10.9", sdk_version="native", architectures=["x86_64"])
i.e. program is being run on M1 through Rosetta.

The issue was reported against the build using GTK 3.24.30, then I've rebuilt 
the program to use latest v3.24.33,
but both users reported that the issue was not fixed (screenshots below). They 
are not developers, so they did not try running gtk-demo.

I do have an app log that redirects all GTK logging, but could not find any 
clue (GTK error/warning) in it. The same binary works fine
on Intel hardware, no such issues were reported.
I will re-check to make sure they properly installed the newer build.

Could adding native "arm64" architecture into the setup help with this bug 
(based on the bug that was fixed)?
Do I need to use newer XCode for this?

Best regards,
  Miroslav

[cid:d29d94ff-5494-408f-8448-b165a6c340f6]

[cid:db4a8d72-0815-4032-b61d-9b8392bee9f5]


From: john 
Sent: Thursday, June 23, 2022 2:30 AM
To: Miroslav Rajcic 
Cc: gtk-osx-users-list@gnome.org 
Subject: Re: [gtk-osx-users] Black screen on ARM based Macs



On Jun 21, 2022, at 9:50 PM, Miroslav Rajcic via gtk-osx-users-list 
 wrote:

Hi,

several users of my program reported the main application screen being 
partially black on ARM based Macs (M1) on macOS Monterey.
Digging online, it seems that this bug has been known:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4342
https://gitlab.gnome.org/GNOME/gtk/-/issues/4395

I've rebuilt latest gtk-osx yesterday (moduleset-stable), but the issue still 
seems to be here.
What's the status of this issue in gtk-osx?

Miroslav,

The fix for issue 4342 is in Gtk+-3.0 since 3.24.31 and modulesets-stable has 
3.24.33, so perhaps the problem your users have found isn't the same one.

Is this an Apple Silicon build or an Intel one? What minimum macOS version did 
you specify? Does the problem reproduce in gtk3-demo or is it just your app?

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Black screen on ARM based Macs

[john]

> On Jun 21, 2022, at 9:50 PM, Miroslav Rajcic via gtk-osx-users-list 
>  wrote:
> 
> Hi,
> 
> several users of my program reported the main application screen being 
> partially black on ARM based Macs (M1) on macOS Monterey.
> Digging online, it seems that this bug has been known:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4342
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4395
> 
> I've rebuilt latest gtk-osx yesterday (moduleset-stable), but the issue still 
> seems to be here.
> What's the status of this issue in gtk-osx?

Miroslav,

The fix for issue 4342 is in Gtk+-3.0 since 3.24.31 and modulesets-stable has 
3.24.33, so perhaps the problem your users have found isn't the same one. 

Is this an Apple Silicon build or an Intel one? What minimum macOS version did 
you specify? Does the problem reproduce in gtk3-demo or is it just your app?

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: problem to install Gtk2

[Thierry Vignaud via gtk-perl-list]

Le jeu. 4 nov. 2021 à 19:11, Emmanuele Bassi via gtk-perl-list <
gtk-perl-list@gnome.org> a écrit :

> On Thu, 4 Nov 2021 at 18:04, Jeremy Volkening via gtk-perl-list <
> gtk-perl-list@gnome.org> wrote:
>
>> > *** can not find package cairo >= 1.0.0
>>
>> You need to have the underlying C libraries installed in order to use the
>> Perl wrappers. Here is a good place to start:
>>
>> https://www.gtk.org/docs/installations/windows
>>
>> Note that if you really want/need to use Gtk2 rather than Gtk3, you need
>> to change the corresponding lines in those instructions. For example:
>>
>> pacman -S mingw-w64-x86_64-gtk3
>>
>> becomes
>>
>> pacman -S mingw-w64-x86_64-gtk2
>>
>> Once you have installed Gtk itself, you should have more luck with the
>> CPAN install.
>>
>
> As a side note: GTK2 is EOL since December 2020, and nobody should write
> new code using it.
>
> GTK3 is in maintenance mode (no new API, no new features), and the current
> stable release of GTK is GTK 4.4.
>
> Sadly, there are no Perl bindings for GTK 4 as of yet, though you can
> easily use Glib::Object::Introspection to load the introspection data, just
> like you'd do with GTK 3.
>

I've a local Gtk4.pm based of Gtk3 for my own projects if you want
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: [gtk-osx-users] Changing from modulesets-stable to modulesets and universal architecture questions

[Dominik Reichardt via gtk-osx-users-list]

--- Original Message ---
On Monday, April 4th, 2022 at 12:01 AM, john  wrote:

> If you manage to get the cross-compiling and lipo-ing to work I'd like to 
> know about it, in particular any special settings or environment variables 
> you needed to make.

With only painstaking manual work I was able to glue everything together and 
have a working universal gtk-osx.
But that consists of 104 lines like this:
lipo -create -arch x86_64 /opt/gtk3x86/lib/libatk-1.0.0.dylib -arch arm64 
/opt/gtk3arm/lib/libatk-1.0.0.dylib -output /opt/gtk/lib/libatk-1.0.0.dylib

I'm pretty sure someone could make a script out of this to automate this, I'm 
not good at this :)
And I've had to build both arches in /opt/gtk3 and then rename the prefixes so 
I wouldn't have to use install_name_tool.
But it works and I have a working build of Exult Studio for both arches now.

Btw. any idea why using strip on our binary breaks everything?
When I run it after using strip I get a lot of

Gtk-WARNING **: 23:12:04.835: Could not find signal handler *some of our 
function*. Did you compile with -rdynamic?

I thought of a possible way to do universal builds on gtk-osx.
Problem: cross-compilation is a pain and I have no idea how meson/ninja handle 
this (I have only experience in autotools and some cmake). If the package runs 
a lot of scripts to figure out what the system provides it really is no fun to 
mess with it. And the gtk-osx packages fall into this category.

So my idea would only work on an M1 machine and only as long as Rosetta2 is 
available (so not really future proof) as I understood from the mailing list 
that you can build the x86_64 arch on an M1 device.

when both arches are defined

- compile and install the packages first for x86_64 and set the prefix to 
prefix_x86_64,
- then the same for arm64 and set the prefix to prefix_arm64.
- Then run install_name_tool on the binaries of both arches to set the id and 
the linked libraries to the path of prefix (I think the project dylibbundler 
has extensive scripts for that).
- And eventually have a script that lipo glues the binaries and places them in 
the prefix.
- copy the non binary stuff from either arch prefix into the main prefix.

Sounds like a lot of work that is reliant on too many scripts and likely to 
break. Probably too much work for too little gain, only working on M1 devices, 
and will stop working as soon as Apple gets rid of Rosetta2.
People are better off to just do a build for each arch, I guess.

Take care,

Dom___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Changing from modulesets-stable to modulesets and universal architecture questions

[john]

> On Apr 3, 2022, at 11:10 AM, Dominik Reichardt via gtk-osx-users-list 
>  wrote:
> 
> 
> 
> 
> --- Original Message ---
> On Sunday, April 3rd, 2022 at 6:38 PM, john  wrote:
> 
>> 
>> 
>>> On Apr 3, 2022, at 5:59 AM, Dominik Reichardt via gtk-osx-users-list 
>>> mailto:gtk-osx-users-list@gnome.org>> wrote:
>>> 
>>> 
>>> Hi all,
>>> 
>>> as per the instructions on https://wiki.gnome.org/Projects/GTK/OSX/Building 
>>>  I added 
>>> moduleset="https://gitlab.gnome.org/GNOME/gtk-osx/blob/master/MODULESETS/gtk-osx.modules
>>>  
>>> "
>>>  to jhbuildrc-custom.
>>> Along with that I have setup_sdk(target="10.11") and changed the paths of 
>>> prefix and checkoutroot.
>>> "jhbuild bootstrap-gtk-osx" works but when I run "jhbuild build 
>>> meta-gtk-osx-bootstrap meta-gtk-osx-gtk3" I get this error:
>>> 
>>> Loading .env environment variables...
>>> jhbuild build: failed to parse 
>>> https://gitlab.gnome.org/GNOME/gtk-osx/blob/master/MODULESETS/gtk-osx.modules:
>>>  
>>> 
>>>  not well-formed (invalid token): line 132, column 4
>>> 
>>> Am I doing it wrong or did it break at some point?
>>> 
>>> I'm also wondering what the correct setup_sdk() entry is for trying my 
>>> hands at building both arches, x86_64 and arm64. And on top of that whether 
>>> it is possible to use different targets depending on the arch? Perhaps 
>>> through reading the architecture environment variable?
>>> Something like this perhaps:
>>> setup_sdk(architectures=["x86_64"]["arm64"]) <- here I don't know how to 
>>> enter different arches
>>> _arches = os.environ.get("ARCHITECTURES")
>>> if _arches is arm64:
>>>setup_sdk(target="11.1")
>>> if _arches is x86_64
>>>setup_sdk(target="10.11")
>>> 
>>> Thanks so much for this project! Through this I've been able to provide a 
>>> macOS snapshot of our Exult Studio for about a year now (http://exult.info 
>>> ).
>> 
>> You didn't do anything wrong, there was I typo. I just pushed a fix.
> 
> Thanks, I had taken a quick look but didn't see an error right away (and I 
> wasn't sure whether the "tag" error meant a closing tag or a github tag).
> Installing this right now.
> 
>> 
>> It would be setup_sdk(architectures=['x86_64', 'arm64']) but unfortunately 
>> most build systems aren't able to deal with that so it doesn't work. Way 
>> back in the PPC/i686 days there was a jhbuildrc that tried to build each 
>> architecture separately and lipo them together, but it never really worked 
>> and I took it out as part of the virtualenv rewrite a few years ago since at 
>> that time macOS was x86_64 only. It's still in git history so you could dig 
>> it out and have a go at getting it working. Warning: When it was written 
>> everything in the main gtk stack used autotools. That's no longer the case 
>> so it will be much harder now. Even cross-compiling will be harder now 
>> because of the different build systems in use. Gobject-introspection is 
>> another wrinkle, as is librsvg's use of Rust.
>> 
>> jhbuildrc-custom is python so if you can program it in python you can do it. 
>> My jhbuildrc-custom uses an environment variable to select the project I 
>> want to build, the modulesets directory to use, and the macosx-version-min 
>> to set. It calls uname to set the architecture.
> 
> Yes, using the setup_sdk way fails right away in the configure stage of 
> xz-5.2.5 (both on an intel and m1 machine), so I'm abandoning this idea 
> again. 
> As Exult Studio "only" depends on 43 libs (including the 14 gdk-pixbiúf-2.0 
> loaders), I might go down the road of gluing them via lipo via script and 
> only bother to update every once in a while.

If you manage to get the cross-compiling and lipo-ing to work I'd like to know 
about it, in particular any special settings or environment variables you 
needed to make.

Regards,
John Ralls
 

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Changing from modulesets-stable to modulesets and universal architecture questions

[Dominik Reichardt via gtk-osx-users-list]

--- Original Message ---
On Sunday, April 3rd, 2022 at 6:38 PM, john  wrote:

>> On Apr 3, 2022, at 5:59 AM, Dominik Reichardt via gtk-osx-users-list 
>>  wrote:
>>
>> Hi all,
>>
>> as per the instructions on https://wiki.gnome.org/Projects/GTK/OSX/Building 
>> I added 
>> moduleset="https://gitlab.gnome.org/GNOME/gtk-osx/blob/master/MODULESETS/gtk-osx.modules;
>>  to jhbuildrc-custom.
>> Along with that I have setup_sdk(target="10.11") and changed the paths of 
>> prefix and checkoutroot.
>> "jhbuild bootstrap-gtk-osx" works but when I run "jhbuild build 
>> meta-gtk-osx-bootstrap meta-gtk-osx-gtk3" I get this error:
>>
>> Loading .env environment variables...
>> jhbuild build: failed to parse 
>> https://gitlab.gnome.org/GNOME/gtk-osx/blob/master/MODULESETS/gtk-osx.modules:
>>  not well-formed (invalid token): line 132, column 4
>>
>> Am I doing it wrong or did it break at some point?
>>
>> I'm also wondering what the correct setup_sdk() entry is for trying my hands 
>> at building both arches, x86_64 and arm64. And on top of that whether it is 
>> possible to use different targets depending on the arch? Perhaps through 
>> reading the architecture environment variable?
>> Something like this perhaps:
>> setup_sdk(architectures=["x86_64"]["arm64"]) <- here I don't know how to 
>> enter different arches
>> _arches = os.environ.get("ARCHITECTURES")
>> if _arches is arm64:
>> setup_sdk(target="11.1")
>> if _arches is x86_64 setup_sdk(target="10.11")
>>
>> Thanks so much for this project! Through this I've been able to provide a 
>> macOS snapshot of our Exult Studio for about a year now (http://exult.info).
>
> You didn't do anything wrong, there was I typo. I just pushed a fix.

Thanks, I had taken a quick look but didn't see an error right away (and I 
wasn't sure whether the "tag" error meant a closing tag or a github tag).
Installing this right now.

> It would be setup_sdk(architectures=['x86_64', 'arm64']) but unfortunately 
> most build systems aren't able to deal with that so it doesn't work. Way back 
> in the PPC/i686 days there was a jhbuildrc that tried to build each 
> architecture separately and lipo them together, but it never really worked 
> and I took it out as part of the virtualenv rewrite a few years ago since at 
> that time macOS was x86_64 only. It's still in git history so you could dig 
> it out and have a go at getting it working. Warning: When it was written 
> everything in the main gtk stack used autotools. That's no longer the case so 
> it will be much harder now. Even cross-compiling will be harder now because 
> of the different build systems in use. Gobject-introspection is another 
> wrinkle, as is librsvg's use of Rust.
>
> jhbuildrc-custom is python so if you can program it in python you can do it. 
> My jhbuildrc-custom uses an environment variable to select the project I want 
> to build, the modulesets directory to use, and the macosx-version-min to set. 
> It calls uname to set the architecture.

Yes, using the setup_sdk way fails right away in the configure stage of 
xz-5.2.5 (both on an intel and m1 machine), so I'm abandoning this idea again.
As Exult Studio "only" depends on 43 libs (including the 14 gdk-pixbiúf-2.0 
loaders), I might go down the road of gluing them via lipo via script and only 
bother to update every once in a while.

Cheers,

Dom

>___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: Problem with long list for ComboBoxText

[Jeremy Volkening via gtk-perl-list]

This is, I think, a design decision of GTK (mainly due to accessibility 
concerns). See issue post here: 
https://gitlab.gnome.org/GNOME/gtk/-/issues/270#note_394060.

It may be possible to implement the keypress hack you described, but you may be 
compromising accessibility for aesthetics.

Best,
Jeremy

On Wed, Mar 23, 2022 at 04:59:42PM +0100, Kerenoc Kerenoc via gtk-perl-list 
wrote:
> Hello,
> 
> With Gtk3 on Windows and Linux, when a ComboBox has a long list of items to
> select from, there is a large empty zone above the first element of the
> list. Using the up arrow key then the down arrow key restores a normal
> situation.
> 
> Here is a simple program to reproduce the problem.
> 
> 
> #!/usr/bin/perl
> 
> use Gtk3 -init;
> 
> my $combobox = Gtk3::ComboBoxText->new;
> for (0 .. 150) { $combobox->append_text("$_"); };
> $combobox->set_active(0);
> 
> my $window=Gtk3::Window->new('toplevel');
> $window->signal_connect( destroy => sub {Gtk3::main_quit} );
> $window->add($combobox);
> $window->show_all;
> Gtk3->main();
> 
> 
> The problem can also be reproduced with a Gtk3::ComboBox.
> 
> In case this problem couldn't be solved, how could one emulate two key
> events (up and down) in a callback when the combobox opens?
> 
> Best regards

> ___
> gtk-perl-list mailing list
> gtk-perl-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-perl-list


-- 
Few things are harder to put up with than the annoyance of a good example.
-- "Mark Twain, Pudd'nhead Wilson's Calendar"
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[Spock]

me” simply does not 
>>>>>> work reliably! That’s not a sensible situation really is it?
>>>>>> 
>>>>>> Now, there is some traffic in the Cmake repo regarding a new flag that 
>>>>>> can be sent to CMake to force it to omit some paths. Given that you want 
>>>>>> to keep all the gtk stuff separate, this would mean telling CMake to not 
>>>>>> search /opt/homebrew and /usr/local (at least - not check for 
>>>>>> fink/macports properly). This would result in you being able to insulate 
>>>>>> your builds from whatever else is installed on the Mac - you would 
>>>>>> simply include the system library paths in CMake and omit everything 
>>>>>> else except within jhbuild’s world. That would be sustainable …
>>>>>> 
>>>>>> See: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6880 
>>>>>> <https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6880> for the 
>>>>>> new CMAKE_SYSTEM_IGNORE_PREFIX_PATH parameter. 
>>>>>> 
>>>>>> I think that when this version of CMake is released, it would make sense 
>>>>>> for meson to pass the CMAKE_SYSTEM_IGNORE_PREFIX_PATH flag to CMake. 
>>>>>> Presumably this could be done by jhbuild - but let’s see?
>>>>>> 
>>>>>> Meanwhile, thinking about gtk-osx-setup.sh, I think you could be missing 
>>>>>> an opportunity - I think that on M1 Macs at least, you are perhaps being 
>>>>>> over restrictive / prescriptive about homebrew. As things stand your 
>>>>>> script happily ignores /opt/homebrew provided that homebrew is not in 
>>>>>> any environment variables. Your script could even clean up the 
>>>>>> environment so that jhbuild is not ‘polluted’ - this is very simple to 
>>>>>> do. In fact, the script is doing what it is required to do to be a 
>>>>>> decent citizen, so I have no problem with it - especially now that we 
>>>>>> have shaken down a couple of bugs. Once we have the meson/cmake bug 
>>>>>> sorted out, your script and homebrew can peacefully coexist.
>>>>>> 
>>>>>> It could be that by embracing the fact that many or most developers need 
>>>>>> tools from homebrew that you could attract more people to using gtk on 
>>>>>> MacOS? Perhaps one way would be to have an example jhbuild-custom that 
>>>>>> removes homebrew paths and perhaps sorts the cmake issue on M1 ?
>>>>>> 
>>>>>> If nothing happens, I expect you will get more comments from M1 based 
>>>>>> Mac developers ...
>>>>>> 
>>>>>> Best
>>>>>> Paul
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 17 Feb 2022, at 04:53, john >>>>>> <mailto:jra...@ceridwen.us>> wrote:
>>>>>>> 
>>>>>>> On .pythonversion, got it. Glad that's fixed.
>>>>>>> 
>>>>>>> On brotlidec in homebrew are you *sure* that there's no link to it in 
>>>>>>> /usr/local/lib? That's one of Homebrew's major malignancies, by default 
>>>>>>> it links its files into the default search locations. 
>>>>>>> I'm not inclined to add work-arounds for users who ignore my 
>>>>>>> precondition that homebrew should not be installed. You can add the 
>>>>>>> additional argument to jhbuild-custom. That file exists specifically to 
>>>>>>> customize your build.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> John Ralls
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Feb 16, 2022, at 2:56 AM, Spock >>>>>>> <mailto:sp...@rogersfamily.me.uk>> wrote:
>>>>>>>> 
>>>>>>>> Happy to be of some help!
>>>>>>>> 
>>>>>>>> My issue with ~/.pythonversion was due to my rough fix for the pip 
>>>>>>>> issue:
>>>>>>>> 
>>>>>>>> —snip—
>>>>>>>> export PYTHON_CONFIGURE_OPTS="--enable-shared"
>>>>>>>> export PYENV_PYTHON_VERSION=3.10.0
>>>>>>>&g

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[john]

ce we have the meson/cmake bug sorted out, your script 
>>>>> and homebrew can peacefully coexist.
>>>>> 
>>>>> It could be that by embracing the fact that many or most developers need 
>>>>> tools from homebrew that you could attract more people to using gtk on 
>>>>> MacOS? Perhaps one way would be to have an example jhbuild-custom that 
>>>>> removes homebrew paths and perhaps sorts the cmake issue on M1 ?
>>>>> 
>>>>> If nothing happens, I expect you will get more comments from M1 based Mac 
>>>>> developers ...
>>>>> 
>>>>> Best
>>>>> Paul
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 17 Feb 2022, at 04:53, john >>>>> <mailto:jra...@ceridwen.us>> wrote:
>>>>>> 
>>>>>> On .pythonversion, got it. Glad that's fixed.
>>>>>> 
>>>>>> On brotlidec in homebrew are you *sure* that there's no link to it in 
>>>>>> /usr/local/lib? That's one of Homebrew's major malignancies, by default 
>>>>>> it links its files into the default search locations. 
>>>>>> I'm not inclined to add work-arounds for users who ignore my 
>>>>>> precondition that homebrew should not be installed. You can add the 
>>>>>> additional argument to jhbuild-custom. That file exists specifically to 
>>>>>> customize your build.
>>>>>> 
>>>>>> Regards,
>>>>>> John Ralls
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Feb 16, 2022, at 2:56 AM, Spock >>>>>> <mailto:sp...@rogersfamily.me.uk>> wrote:
>>>>>>> 
>>>>>>> Happy to be of some help!
>>>>>>> 
>>>>>>> My issue with ~/.pythonversion was due to my rough fix for the pip 
>>>>>>> issue:
>>>>>>> 
>>>>>>> —snip—
>>>>>>> export PYTHON_CONFIGURE_OPTS="--enable-shared"
>>>>>>> export PYENV_PYTHON_VERSION=3.10.0
>>>>>>> $PYENV install -v $PYENV_PYTHON_VERSION
>>>>>>> PIP="$PYENV_ROOT/shims/pip"
>>>>>>> $PYENV local 3.10.0
>>>>>>> $PIP install --upgrade --user pip
>>>>>>> — snip —
>>>>>>> 
>>>>>>> The use of "pyenv local 3.10.0” creates the ~/.pythonversion file - but 
>>>>>>> using the *cough* correct pip3, there’s no need for a pipenv before 
>>>>>>> pip3 … so no .pythonversion :-)
>>>>>>> 
>>>>>>> I did a clean run with your latest pushed changes and confirm that the 
>>>>>>> setup script now works.
>>>>>>> 
>>>>>>> As an aside, I found problems with the later steps of the instructions 
>>>>>>> on https://wiki.gnome.org/Projects/GTK/OSX/Building 
>>>>>>> <https://wiki.gnome.org/Projects/GTK/OSX/Building> ...
>>>>>>> 
>>>>>>> These problems are just like Pascal’s problems with "ft-fb.h not found” 
>>>>>>> last month - but I did make some progress.
>>>>>>> 
>>>>>>> The key issue is that the freetype builds, despite being run in an 
>>>>>>> environment where no environment variables contain the word “homebrew”, 
>>>>>>> still decides to find the librotlidec library in /opt/homebrew/lib. 
>>>>>>> This causes a build failure later on ...
>>>>>>> 
>>>>>>> Adding "-D CMAKE_DISABLE_FIND_PACKAGE_BrotliDec=TRUE” to both steps in 
>>>>>>> GtkApplication-osx.modules resolves this issue.
>>>>>>> This looks like a bug on freetype's part - they should not be scanning 
>>>>>>> random parts of the filesystem ! Anyhow, when disabling the search for 
>>>>>>> this library, and re-running, I end up with all steps of the 
>>>>>>> instructions on the webpage working.
>>>>>>> 
>>>>>>> Perhaps you want to make a change GTK-OSX.modules, perhaps not. The big 
>>>>>>> thing here is that developers should not have to have a separate 
>>>>>>> username, vm or machine to build GtkApplication apps - 

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[john]

e a decent citizen, so I have 
> no problem with it - especially now that we have shaken down a couple of 
> bugs. Once we have the meson/cmake bug sorted out, your script and homebrew 
> can peacefully coexist.
> 
> It could be that by embracing the fact that many or most developers need 
> tools from homebrew that you could attract more people to using gtk on MacOS? 
> Perhaps one way would be to have an example jhbuild-custom that removes 
> homebrew paths and perhaps sorts the cmake issue on M1 ?
> 
> If nothing happens, I expect you will get more comments from M1 based Mac 
> developers ...
> 
> Best
> Paul
> 
> 
> 
>> On 17 Feb 2022, at 04:53, john > <mailto:jra...@ceridwen.us>> wrote:
>> 
>> On .pythonversion, got it. Glad that's fixed.
>> 
>> On brotlidec in homebrew are you *sure* that there's no link to it in 
>> /usr/local/lib? That's one of Homebrew's major malignancies, by default it 
>> links its files into the default search locations. 
>> I'm not inclined to add work-arounds for users who ignore my precondition 
>> that homebrew should not be installed. You can add the additional argument 
>> to jhbuild-custom. That file exists specifically to customize your build.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>> 
>> 
>>> On Feb 16, 2022, at 2:56 AM, Spock >> <mailto:sp...@rogersfamily.me.uk>> wrote:
>>> 
>>> Happy to be of some help!
>>> 
>>> My issue with ~/.pythonversion was due to my rough fix for the pip issue:
>>> 
>>> —snip—
>>> export PYTHON_CONFIGURE_OPTS="--enable-shared"
>>> export PYENV_PYTHON_VERSION=3.10.0
>>> $PYENV install -v $PYENV_PYTHON_VERSION
>>> PIP="$PYENV_ROOT/shims/pip"
>>> $PYENV local 3.10.0
>>> $PIP install --upgrade --user pip
>>> — snip —
>>> 
>>> The use of "pyenv local 3.10.0” creates the ~/.pythonversion file - but 
>>> using the *cough* correct pip3, there’s no need for a pipenv before pip3 … 
>>> so no .pythonversion :-)
>>> 
>>> I did a clean run with your latest pushed changes and confirm that the 
>>> setup script now works.
>>> 
>>> As an aside, I found problems with the later steps of the instructions on 
>>> https://wiki.gnome.org/Projects/GTK/OSX/Building 
>>> <https://wiki.gnome.org/Projects/GTK/OSX/Building> ...
>>> 
>>> These problems are just like Pascal’s problems with "ft-fb.h not found” 
>>> last month - but I did make some progress.
>>> 
>>> The key issue is that the freetype builds, despite being run in an 
>>> environment where no environment variables contain the word “homebrew”, 
>>> still decides to find the librotlidec library in /opt/homebrew/lib. This 
>>> causes a build failure later on ...
>>> 
>>> Adding "-D CMAKE_DISABLE_FIND_PACKAGE_BrotliDec=TRUE” to both steps in 
>>> GtkApplication-osx.modules resolves this issue.
>>> This looks like a bug on freetype's part - they should not be scanning 
>>> random parts of the filesystem ! Anyhow, when disabling the search for this 
>>> library, and re-running, I end up with all steps of the instructions on the 
>>> webpage working.
>>> 
>>> Perhaps you want to make a change GTK-OSX.modules, perhaps not. The big 
>>> thing here is that developers should not have to have a separate username, 
>>> vm or machine to build GtkApplication apps - especially when some simple 
>>> configuration can resolve these issues. Simply put for many, the tools that 
>>> macports or homebrew provide are required part of daily workflows. Maybe 
>>> putting a catch at the start of gtk-osx-setup.sh would be useful? Something 
>>> like:
>>> 
>>> —snip--
>>> CHECK_HOMEBREW=`printenv |grep homebrew`
>>> 
>>> If [[ Z$CHECK_HOMEBREW == “Z” ]] ; then
>>> echo “Can’t use this script with a homebrew environment !”
>>> exit 1
>>> fi
>>> — snip --
>>> 
>>> I’ll get around to trying to build the simple app that I started out on two 
>>> weeks ago - and will report back if this ends up being problematic.
>>> 
>>> Thanks for your help meanwhile.
>>> 
>>> Regards
>>> Paul
>>> 
>>> 
>>>> On 16 Feb 2022, at 05:30, John Ralls >>> <mailto:jra...@ceridwen.us>> wrote:
>>>> 
>>>> Ah, got it. Fix pushed. Thanks.
>>>> I also finally figured out the cause of "pye

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[Spock]

P="$PYENV_ROOT/shims/pip"
>> $PYENV local 3.10.0
>> $PIP install --upgrade --user pip
>> — snip —
>> 
>> The use of "pyenv local 3.10.0” creates the ~/.pythonversion file - but 
>> using the *cough* correct pip3, there’s no need for a pipenv before pip3 … 
>> so no .pythonversion :-)
>> 
>> I did a clean run with your latest pushed changes and confirm that the setup 
>> script now works.
>> 
>> As an aside, I found problems with the later steps of the instructions on 
>> https://wiki.gnome.org/Projects/GTK/OSX/Building 
>> <https://wiki.gnome.org/Projects/GTK/OSX/Building> ...
>> 
>> These problems are just like Pascal’s problems with "ft-fb.h not found” last 
>> month - but I did make some progress.
>> 
>> The key issue is that the freetype builds, despite being run in an 
>> environment where no environment variables contain the word “homebrew”, 
>> still decides to find the librotlidec library in /opt/homebrew/lib. This 
>> causes a build failure later on ...
>> 
>> Adding "-D CMAKE_DISABLE_FIND_PACKAGE_BrotliDec=TRUE” to both steps in 
>> GtkApplication-osx.modules resolves this issue.
>> This looks like a bug on freetype's part - they should not be scanning 
>> random parts of the filesystem ! Anyhow, when disabling the search for this 
>> library, and re-running, I end up with all steps of the instructions on the 
>> webpage working.
>> 
>> Perhaps you want to make a change GTK-OSX.modules, perhaps not. The big 
>> thing here is that developers should not have to have a separate username, 
>> vm or machine to build GtkApplication apps - especially when some simple 
>> configuration can resolve these issues. Simply put for many, the tools that 
>> macports or homebrew provide are required part of daily workflows. Maybe 
>> putting a catch at the start of gtk-osx-setup.sh would be useful? Something 
>> like:
>> 
>> —snip--
>> CHECK_HOMEBREW=`printenv |grep homebrew`
>> 
>> If [[ Z$CHECK_HOMEBREW == “Z” ]] ; then
>>  echo “Can’t use this script with a homebrew environment !”
>>  exit 1
>> fi
>> — snip --
>> 
>> I’ll get around to trying to build the simple app that I started out on two 
>> weeks ago - and will report back if this ends up being problematic.
>> 
>> Thanks for your help meanwhile.
>> 
>> Regards
>> Paul
>> 
>> 
>>> On 16 Feb 2022, at 05:30, John Ralls >> <mailto:jra...@ceridwen.us>> wrote:
>>> 
>>> Ah, got it. Fix pushed. Thanks.
>>> I also finally figured out the cause of "pyenv: pip: command not found" and 
>>> pushed a fix for that too.
>>> 
>>> BTW, I don't see ~/.pythonversion. Are you sure that's from pyenv?
>>> 
>>> Regards,
>>> John Ralls
>>> 
>>> 
>>>> On Feb 15, 2022, at 2:08 PM, Spock >>> <mailto:sp...@rogersfamily.me.uk>> wrote:
>>>> 
>>>> Sorry - I did not explain myself well enough there John.
>>>> 
>>>> I guess the issue that I’m pointing out is that gtk-osx-setup.sh writes 
>>>> the jhbuild script but writes an absolute path for $PATH to be set to 
>>>> rather than escaping so that $PATH is read from the environment when 
>>>> running jhbuild.
>>>> 
>>>> In the code snip from gtk-osx-setup.sh below the second $PATH should be 
>>>> escaped to be ‘\$PATH’ (as shown). Without this, it means that PATH only 
>>>> gets set correctly if the environment $PATH when calling  gtk-osx-setup.sh 
>>>> contains something like “~/.new_local/bin”.
>>>> 
>>>> — snip ---
>>>> cat < “$DEVPREFIX/bin/jhbuild"
>>>> #!$DEVPREFIX/bin/bash
>>>> ...
>>>> export PATH="$PYENV_ROOT/shims:$PATH”  <<<<<<<- Should be …/shims:\$PATH
>>>> ...
>>>> exec $DEVPREFIX/bin/pipenv run jhbuild \$@
>>>> EOF
>>>> — snip ---
>>>> 
>>>> This explains why people with fresh machines or fresh usernames end up 
>>>> with the build failing.
>>>> 
>>>> So the either the instructions need to say “Set your PATH to include 
>>>> ~/.new_local/bin before invoking  gtk-osx-setup.sh” or the script needs to 
>>>> be fixed to include the line:
>>>> 
>>>> —snip—
>>>> export PATH="$PYENV_ROOT/shims:$PATH”
>>>> —snip --
>>>> 
>>>> Once I make this change, I 

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[john]

On .pythonversion, got it. Glad that's fixed.

On brotlidec in homebrew are you *sure* that there's no link to it in 
/usr/local/lib? That's one of Homebrew's major malignancies, by default it 
links its files into the default search locations. 
I'm not inclined to add work-arounds for users who ignore my precondition that 
homebrew should not be installed. You can add the additional argument to 
jhbuild-custom. That file exists specifically to customize your build.

Regards,
John Ralls




> On Feb 16, 2022, at 2:56 AM, Spock  wrote:
> 
> Happy to be of some help!
> 
> My issue with ~/.pythonversion was due to my rough fix for the pip issue:
> 
> —snip—
> export PYTHON_CONFIGURE_OPTS="--enable-shared"
> export PYENV_PYTHON_VERSION=3.10.0
> $PYENV install -v $PYENV_PYTHON_VERSION
> PIP="$PYENV_ROOT/shims/pip"
> $PYENV local 3.10.0
> $PIP install --upgrade --user pip
> — snip —
> 
> The use of "pyenv local 3.10.0” creates the ~/.pythonversion file - but using 
> the *cough* correct pip3, there’s no need for a pipenv before pip3 … so no 
> .pythonversion :-)
> 
> I did a clean run with your latest pushed changes and confirm that the setup 
> script now works.
> 
> As an aside, I found problems with the later steps of the instructions on 
> https://wiki.gnome.org/Projects/GTK/OSX/Building 
> <https://wiki.gnome.org/Projects/GTK/OSX/Building> ...
> 
> These problems are just like Pascal’s problems with "ft-fb.h not found” last 
> month - but I did make some progress.
> 
> The key issue is that the freetype builds, despite being run in an 
> environment where no environment variables contain the word “homebrew”, still 
> decides to find the librotlidec library in /opt/homebrew/lib. This causes a 
> build failure later on ...
> 
> Adding "-D CMAKE_DISABLE_FIND_PACKAGE_BrotliDec=TRUE” to both steps in 
> GtkApplication-osx.modules resolves this issue.
> This looks like a bug on freetype's part - they should not be scanning random 
> parts of the filesystem ! Anyhow, when disabling the search for this library, 
> and re-running, I end up with all steps of the instructions on the webpage 
> working.
> 
> Perhaps you want to make a change GTK-OSX.modules, perhaps not. The big thing 
> here is that developers should not have to have a separate username, vm or 
> machine to build GtkApplication apps - especially when some simple 
> configuration can resolve these issues. Simply put for many, the tools that 
> macports or homebrew provide are required part of daily workflows. Maybe 
> putting a catch at the start of gtk-osx-setup.sh would be useful? Something 
> like:
> 
> —snip--
> CHECK_HOMEBREW=`printenv |grep homebrew`
> 
> If [[ Z$CHECK_HOMEBREW == “Z” ]] ; then
>   echo “Can’t use this script with a homebrew environment !”
>   exit 1
> fi
> — snip --
> 
> I’ll get around to trying to build the simple app that I started out on two 
> weeks ago - and will report back if this ends up being problematic.
> 
> Thanks for your help meanwhile.
> 
> Regards
> Paul
> 
> 
>> On 16 Feb 2022, at 05:30, John Ralls > <mailto:jra...@ceridwen.us>> wrote:
>> 
>> Ah, got it. Fix pushed. Thanks.
>> I also finally figured out the cause of "pyenv: pip: command not found" and 
>> pushed a fix for that too.
>> 
>> BTW, I don't see ~/.pythonversion. Are you sure that's from pyenv?
>> 
>> Regards,
>> John Ralls
>> 
>> 
>>> On Feb 15, 2022, at 2:08 PM, Spock >> <mailto:sp...@rogersfamily.me.uk>> wrote:
>>> 
>>> Sorry - I did not explain myself well enough there John.
>>> 
>>> I guess the issue that I’m pointing out is that gtk-osx-setup.sh writes the 
>>> jhbuild script but writes an absolute path for $PATH to be set to rather 
>>> than escaping so that $PATH is read from the environment when running 
>>> jhbuild.
>>> 
>>> In the code snip from gtk-osx-setup.sh below the second $PATH should be 
>>> escaped to be ‘\$PATH’ (as shown). Without this, it means that PATH only 
>>> gets set correctly if the environment $PATH when calling  gtk-osx-setup.sh 
>>> contains something like “~/.new_local/bin”.
>>> 
>>> — snip ---
>>> cat < “$DEVPREFIX/bin/jhbuild"
>>> #!$DEVPREFIX/bin/bash
>>> ...
>>> export PATH="$PYENV_ROOT/shims:$PATH”  <<<<<<<- Should be …/shims:\$PATH
>>> ...
>>> exec $DEVPREFIX/bin/pipenv run jhbuild \$@
>>> EOF
>>> — snip ---
>>> 
>>> This explains why people with fresh machines or fresh usernames end up with 
>>>

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[Spock]

Happy to be of some help!

My issue with ~/.pythonversion was due to my rough fix for the pip issue:

—snip—
export PYTHON_CONFIGURE_OPTS="--enable-shared"
export PYENV_PYTHON_VERSION=3.10.0
$PYENV install -v $PYENV_PYTHON_VERSION
PIP="$PYENV_ROOT/shims/pip"
$PYENV local 3.10.0
$PIP install --upgrade --user pip
— snip —

The use of "pyenv local 3.10.0” creates the ~/.pythonversion file - but using 
the *cough* correct pip3, there’s no need for a pipenv before pip3 … so no 
.pythonversion :-)

I did a clean run with your latest pushed changes and confirm that the setup 
script now works.

As an aside, I found problems with the later steps of the instructions on 
https://wiki.gnome.org/Projects/GTK/OSX/Building 
<https://wiki.gnome.org/Projects/GTK/OSX/Building> ...

These problems are just like Pascal’s problems with "ft-fb.h not found” last 
month - but I did make some progress.

The key issue is that the freetype builds, despite being run in an environment 
where no environment variables contain the word “homebrew”, still decides to 
find the librotlidec library in /opt/homebrew/lib. This causes a build failure 
later on ...

Adding "-D CMAKE_DISABLE_FIND_PACKAGE_BrotliDec=TRUE” to both steps in 
GtkApplication-osx.modules resolves this issue.
This looks like a bug on freetype's part - they should not be scanning random 
parts of the filesystem ! Anyhow, when disabling the search for this library, 
and re-running, I end up with all steps of the instructions on the webpage 
working.

Perhaps you want to make a change GTK-OSX.modules, perhaps not. The big thing 
here is that developers should not have to have a separate username, vm or 
machine to build GtkApplication apps - especially when some simple 
configuration can resolve these issues. Simply put for many, the tools that 
macports or homebrew provide are required part of daily workflows. Maybe 
putting a catch at the start of gtk-osx-setup.sh would be useful? Something 
like:

—snip--
CHECK_HOMEBREW=`printenv |grep homebrew`

If [[ Z$CHECK_HOMEBREW == “Z” ]] ; then
echo “Can’t use this script with a homebrew environment !”
exit 1
fi
— snip --

I’ll get around to trying to build the simple app that I started out on two 
weeks ago - and will report back if this ends up being problematic.

Thanks for your help meanwhile.

Regards
Paul


> On 16 Feb 2022, at 05:30, John Ralls  wrote:
> 
> Ah, got it. Fix pushed. Thanks.
> I also finally figured out the cause of "pyenv: pip: command not found" and 
> pushed a fix for that too.
> 
> BTW, I don't see ~/.pythonversion. Are you sure that's from pyenv?
> 
> Regards,
> John Ralls
> 
> 
>> On Feb 15, 2022, at 2:08 PM, Spock  wrote:
>> 
>> Sorry - I did not explain myself well enough there John.
>> 
>> I guess the issue that I’m pointing out is that gtk-osx-setup.sh writes the 
>> jhbuild script but writes an absolute path for $PATH to be set to rather 
>> than escaping so that $PATH is read from the environment when running 
>> jhbuild.
>> 
>> In the code snip from gtk-osx-setup.sh below the second $PATH should be 
>> escaped to be ‘\$PATH’ (as shown). Without this, it means that PATH only 
>> gets set correctly if the environment $PATH when calling  gtk-osx-setup.sh 
>> contains something like “~/.new_local/bin”.
>> 
>> — snip ---
>> cat < “$DEVPREFIX/bin/jhbuild"
>> #!$DEVPREFIX/bin/bash
>> ...
>> export PATH="$PYENV_ROOT/shims:$PATH”  <<<<<<<- Should be …/shims:\$PATH
>> ...
>> exec $DEVPREFIX/bin/pipenv run jhbuild \$@
>> EOF
>> — snip ---
>> 
>> This explains why people with fresh machines or fresh usernames end up with 
>> the build failing.
>> 
>> So the either the instructions need to say “Set your PATH to include 
>> ~/.new_local/bin before invoking  gtk-osx-setup.sh” or the script needs to 
>> be fixed to include the line:
>> 
>> —snip—
>> export PATH="$PYENV_ROOT/shims:$PATH”
>> —snip --
>> 
>> Once I make this change, I can build a lot more of the "jhbuild build 
>> meta-gtk-osx-bootstrap meta-gtk-osx-gtk3“ stage.
>> It still fails, btw, but I need to diagnose why and or ask some more 
>> questions!
>> 
>> 
>> Hope this makes sense and is helpful?
>> 
>> Regards
>> Paul
>> 
>> 
>> 
>>> On 15 Feb 2022, at 18:52, john  wrote:
>>> 
>>> Well, it's been a requirement since forever that you put $DEVPREFIX/bin in 
>>> your path before invoking jhbuild, but I suppose there's no harm in also 
>>> adding it with jhbuild to prevent path pollution. I hadn't noticed 
>>> ~/.pythonversion. That's rude of them, I'll look for

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[John Ralls]

Ah, got it. Fix pushed. Thanks.
I also finally figured out the cause of "pyenv: pip: command not found" and 
pushed a fix for that too.

BTW, I don't see ~/.pythonversion. Are you sure that's from pyenv?

Regards,
John Ralls


> On Feb 15, 2022, at 2:08 PM, Spock  wrote:
> 
> Sorry - I did not explain myself well enough there John.
> 
> I guess the issue that I’m pointing out is that gtk-osx-setup.sh writes the 
> jhbuild script but writes an absolute path for $PATH to be set to rather than 
> escaping so that $PATH is read from the environment when running jhbuild.
> 
> In the code snip from gtk-osx-setup.sh below the second $PATH should be 
> escaped to be ‘\$PATH’ (as shown). Without this, it means that PATH only gets 
> set correctly if the environment $PATH when calling  gtk-osx-setup.sh 
> contains something like “~/.new_local/bin”.
> 
> — snip ---
> cat < “$DEVPREFIX/bin/jhbuild"
> #!$DEVPREFIX/bin/bash
> ...
> export PATH="$PYENV_ROOT/shims:$PATH”  <<<<<<<- Should be …/shims:\$PATH
> ...
> exec $DEVPREFIX/bin/pipenv run jhbuild \$@
> EOF
> — snip ---
> 
> This explains why people with fresh machines or fresh usernames end up with 
> the build failing.
> 
> So the either the instructions need to say “Set your PATH to include 
> ~/.new_local/bin before invoking  gtk-osx-setup.sh” or the script needs to be 
> fixed to include the line:
> 
> —snip—
> export PATH="$PYENV_ROOT/shims:$PATH”
> —snip --
> 
> Once I make this change, I can build a lot more of the "jhbuild build 
> meta-gtk-osx-bootstrap meta-gtk-osx-gtk3“ stage.
> It still fails, btw, but I need to diagnose why and or ask some more 
> questions!
> 
> 
> Hope this makes sense and is helpful?
> 
> Regards
> Paul
> 
> 
> 
>> On 15 Feb 2022, at 18:52, john  wrote:
>> 
>> Well, it's been a requirement since forever that you put $DEVPREFIX/bin in 
>> your path before invoking jhbuild, but I suppose there's no harm in also 
>> adding it with jhbuild to prevent path pollution. I hadn't noticed 
>> ~/.pythonversion. That's rude of them, I'll look for a way to bury that 
>> somewhere so that it doesn't affect other stuff.
>> 
>> Regards,
>> John Ralls
>> 
>>> On Feb 15, 2022, at 5:26 AM, Spock  wrote:
>>> 
>>> Hi John,
>>> 
>>> I guess the issue with the $PYENV local 23.10.0 is that it causes 
>>> ~/.pythonversion to be created - which may or may not be a permanent change 
>>> a developer might want?
>>> 
>>> The more serious issue is with meson not finding ninja. I think this is 
>>> down to jhbuild not having ~/.new_local/bin in its path.
>>> 
>>> Here’s an example:
>>> 
>>> — snip —
>>> 
>>> j@pauls-mbp ~ [nobrew] % echo $PATH
>>> /Users/j/.new_local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/j/.cargo/bin
>>> j@pauls-mbp ~ [nobrew] % jhbuild shell
>>> Loading .env environment variables...
>>> Found Command Line Tools 'version: 13.2.0.0.1.1638488800'
>>> Command Line Tools version 13.20
>>> Prefix: /Users/j/gtk/inst
>>> Entered jhbuild shell, type 'exit' to return.
>>> j@pauls-mbp ~ % jhbuild
>>> zsh: command not found: jhbuild
>>> j@pauls-mbp ~ %
>>> 
>>> — snip —
>>> 
>>> I think this means that the jhbuild configuration installed by 
>>> gtk-osx-setup.sh does not set up jhbuild so that it uses the binaries that 
>>> have been installed?
>>> 
>>> I’m not sure if the issue is with jhbuild or gtk-osx-setup.sh - but I guess 
>>> it’s right to start in this list before looking at what might be wrong (if 
>>> anything) with jhbuild?
>>> 
>>> Regards
>>> Paul Rogers
>>> 
>>>> On 15 Feb 2022, at 01:55, John Ralls  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Feb 14, 2022, at 10:03 AM, Spock  wrote:
>>>>> 
>>>>> Hi, I’m running gtk-osx-setup.sh on an M1 Mac/MacOS 12.2 and am having a 
>>>>> couple of problems ...
>>>>> 
>>>>> First off, I’m running without any homebrew paths in any of the 
>>>>> environment variables.
>>>>> 
>>>>> Now, with this shell, when I run the script, I get the following:
>>>>> 
>>>>> — snip 
>>>>> pyenv: pip: command not found
>>>>> 
>>>>> The `pip' command exists in these Python versions:
>>>>> 3.10.0

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[Spock]

Sorry - I did not explain myself well enough there John.

I guess the issue that I’m pointing out is that gtk-osx-setup.sh writes the 
jhbuild script but writes an absolute path for $PATH to be set to rather than 
escaping so that $PATH is read from the environment when running jhbuild.

In the code snip from gtk-osx-setup.sh below the second $PATH should be escaped 
to be ‘\$PATH’ (as shown). Without this, it means that PATH only gets set 
correctly if the environment $PATH when calling  gtk-osx-setup.sh contains 
something like “~/.new_local/bin”.

— snip ---
cat < “$DEVPREFIX/bin/jhbuild"
#!$DEVPREFIX/bin/bash
...
export PATH="$PYENV_ROOT/shims:$PATH”  <<<<<<<- Should be …/shims:\$PATH
...
exec $DEVPREFIX/bin/pipenv run jhbuild \$@
EOF
— snip ---

This explains why people with fresh machines or fresh usernames end up with the 
build failing.

So the either the instructions need to say “Set your PATH to include 
~/.new_local/bin before invoking  gtk-osx-setup.sh” or the script needs to be 
fixed to include the line:

—snip—
export PATH="$PYENV_ROOT/shims:$PATH”
—snip --

Once I make this change, I can build a lot more of the "jhbuild build 
meta-gtk-osx-bootstrap meta-gtk-osx-gtk3“ stage.
It still fails, btw, but I need to diagnose why and or ask some more questions!


Hope this makes sense and is helpful?

Regards
Paul



> On 15 Feb 2022, at 18:52, john  wrote:
> 
> Well, it's been a requirement since forever that you put $DEVPREFIX/bin in 
> your path before invoking jhbuild, but I suppose there's no harm in also 
> adding it with jhbuild to prevent path pollution. I hadn't noticed 
> ~/.pythonversion. That's rude of them, I'll look for a way to bury that 
> somewhere so that it doesn't affect other stuff.
> 
> Regards,
> John Ralls
> 
>> On Feb 15, 2022, at 5:26 AM, Spock  wrote:
>> 
>> Hi John,
>> 
>> I guess the issue with the $PYENV local 23.10.0 is that it causes 
>> ~/.pythonversion to be created - which may or may not be a permanent change 
>> a developer might want?
>> 
>> The more serious issue is with meson not finding ninja. I think this is down 
>> to jhbuild not having ~/.new_local/bin in its path.
>> 
>> Here’s an example:
>> 
>> — snip —
>> 
>> j@pauls-mbp ~ [nobrew] % echo $PATH
>> /Users/j/.new_local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/j/.cargo/bin
>> j@pauls-mbp ~ [nobrew] % jhbuild shell
>> Loading .env environment variables...
>> Found Command Line Tools 'version: 13.2.0.0.1.1638488800'
>> Command Line Tools version 13.20
>> Prefix: /Users/j/gtk/inst
>> Entered jhbuild shell, type 'exit' to return.
>> j@pauls-mbp ~ % jhbuild
>> zsh: command not found: jhbuild
>> j@pauls-mbp ~ %
>> 
>> — snip —
>> 
>> I think this means that the jhbuild configuration installed by 
>> gtk-osx-setup.sh does not set up jhbuild so that it uses the binaries that 
>> have been installed?
>> 
>> I’m not sure if the issue is with jhbuild or gtk-osx-setup.sh - but I guess 
>> it’s right to start in this list before looking at what might be wrong (if 
>> anything) with jhbuild?
>> 
>> Regards
>> Paul Rogers
>> 
>>> On 15 Feb 2022, at 01:55, John Ralls  wrote:
>>> 
>>> 
>>> 
>>>> On Feb 14, 2022, at 10:03 AM, Spock  wrote:
>>>> 
>>>> Hi, I’m running gtk-osx-setup.sh on an M1 Mac/MacOS 12.2 and am having a 
>>>> couple of problems ...
>>>> 
>>>> First off, I’m running without any homebrew paths in any of the 
>>>> environment variables.
>>>> 
>>>> Now, with this shell, when I run the script, I get the following:
>>>> 
>>>> — snip 
>>>> pyenv: pip: command not found
>>>> 
>>>> The `pip' command exists in these Python versions:
>>>> 3.10.0
>>>> 
>>>> Note: See 'pyenv help global' for tips on allowing both
>>>>   python2 and python3 to be found.
>>>> pyenv: pip: command not found
>>>> 
>>>> The `pip' command exists in these Python versions:
>>>> 3.10.0
>>>> 
>>>> Note: See 'pyenv help global' for tips on allowing both
>>>>   python2 and python3 to be found.
>>>> —- snip ---
>>>> 
>>>> So I add a line to the script to allow it to find python:
>>>> 
>>>> — snip —
>>>> PIP=“$PYENV_ROOT/shims/pip”
>>>> # Point pyenv at the 3.10.0 Python ...
>>>> $PYENV local 3.10.0
>>>> $PIP install --upgrade --user pip
>>&

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[john]

Well, it's been a requirement since forever that you put $DEVPREFIX/bin in your 
path before invoking jhbuild, but I suppose there's no harm in also adding it 
with jhbuild to prevent path pollution. I hadn't noticed ~/.pythonversion. 
That's rude of them, I'll look for a way to bury that somewhere so that it 
doesn't affect other stuff.

Regards,
John Ralls

> On Feb 15, 2022, at 5:26 AM, Spock  wrote:
> 
> Hi John,
> 
> I guess the issue with the $PYENV local 23.10.0 is that it causes 
> ~/.pythonversion to be created - which may or may not be a permanent change a 
> developer might want?
> 
> The more serious issue is with meson not finding ninja. I think this is down 
> to jhbuild not having ~/.new_local/bin in its path.
> 
> Here’s an example:
> 
> — snip —
> 
> j@pauls-mbp ~ [nobrew] % echo $PATH
> /Users/j/.new_local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/j/.cargo/bin
> j@pauls-mbp ~ [nobrew] % jhbuild shell
> Loading .env environment variables...
> Found Command Line Tools 'version: 13.2.0.0.1.1638488800'
> Command Line Tools version 13.20
> Prefix: /Users/j/gtk/inst
> Entered jhbuild shell, type 'exit' to return.
> j@pauls-mbp ~ % jhbuild
> zsh: command not found: jhbuild
> j@pauls-mbp ~ %
> 
> — snip —
> 
> I think this means that the jhbuild configuration installed by 
> gtk-osx-setup.sh does not set up jhbuild so that it uses the binaries that 
> have been installed?
> 
> I’m not sure if the issue is with jhbuild or gtk-osx-setup.sh - but I guess 
> it’s right to start in this list before looking at what might be wrong (if 
> anything) with jhbuild?
> 
> Regards
> Paul Rogers
> 
>> On 15 Feb 2022, at 01:55, John Ralls  wrote:
>> 
>> 
>> 
>>> On Feb 14, 2022, at 10:03 AM, Spock  wrote:
>>> 
>>> Hi, I’m running gtk-osx-setup.sh on an M1 Mac/MacOS 12.2 and am having a 
>>> couple of problems ...
>>> 
>>> First off, I’m running without any homebrew paths in any of the environment 
>>> variables.
>>> 
>>> Now, with this shell, when I run the script, I get the following:
>>> 
>>> — snip 
>>> pyenv: pip: command not found
>>> 
>>> The `pip' command exists in these Python versions:
>>> 3.10.0
>>> 
>>> Note: See 'pyenv help global' for tips on allowing both
>>>python2 and python3 to be found.
>>> pyenv: pip: command not found
>>> 
>>> The `pip' command exists in these Python versions:
>>> 3.10.0
>>> 
>>> Note: See 'pyenv help global' for tips on allowing both
>>>python2 and python3 to be found.
>>> —- snip ---
>>> 
>>> So I add a line to the script to allow it to find python:
>>> 
>>> — snip —
>>> PIP=“$PYENV_ROOT/shims/pip”
>>> # Point pyenv at the 3.10.0 Python ...
>>> $PYENV local 3.10.0
>>> $PIP install --upgrade --user pip
>>> — snip ---
>>> 
>>> With this line, I remove the artefacts from the previous build and re-run. 
>>> This time the script completes, so I move on to “./.new_local/bin/jhbuild 
>>> bootstrap-gtk-osx which appears to complete successfully.
>>> 
>>> *** Was this the right thing to do?
>>> 
>>> The final step “jhbuild meta-gtk-osx-bootstrap meta-gtk-osx-gtk3 fails due 
>>> to problems finding a version of ninja …
>>> 
>>> — snip ---
>>> gtk-doc 1.33.1
>>> 
>>> User defined options
>>>  libdir : lib
>>>  prefix : /Users/j/gtk/inst
>>>  wrap_mode  : nofallback
>>>  tests  : false
>>>  yelp_manual: false
>>> 
>>> 
>>> ERROR: Could not detect Ninja v1.8.2 or newer
>>> — snip ---
>>> 
>>> I checked the version installed by the script …
>>> 
>>> — snip ---
>>> j@pauls-mbp ~ [nobrew] % ./.new_local/bin/ninja —version
>>> 1.10.2
>>> — snip ---
>>> 
>>> *** So what is happening with ninja? Is there a setup step I’m missing?
>>> 
>>> Any help much appreciated!
>> 
>> Your fix for pip seems reasonable. Did you remember to add ~/.new_local/bin 
>> to $PATH?
>> 
>> Regards,
>> John Ralls
>> 
>> 
> 

___
gtk-osx-devel-list mailing list
gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[Spock]

Hi John,

I guess the issue with the $PYENV local 23.10.0 is that it causes 
~/.pythonversion to be created - which may or may not be a permanent change a 
developer might want?

The more serious issue is with meson not finding ninja. I think this is down to 
jhbuild not having ~/.new_local/bin in its path.

Here’s an example:

— snip —

j@pauls-mbp ~ [nobrew] % echo $PATH
/Users/j/.new_local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/j/.cargo/bin
j@pauls-mbp ~ [nobrew] % jhbuild shell
Loading .env environment variables...
Found Command Line Tools 'version: 13.2.0.0.1.1638488800'
Command Line Tools version 13.20
Prefix: /Users/j/gtk/inst
Entered jhbuild shell, type 'exit' to return.
j@pauls-mbp ~ % jhbuild
zsh: command not found: jhbuild
j@pauls-mbp ~ %

— snip —

I think this means that the jhbuild configuration installed by gtk-osx-setup.sh 
does not set up jhbuild so that it uses the binaries that have been installed?

I’m not sure if the issue is with jhbuild or gtk-osx-setup.sh - but I guess 
it’s right to start in this list before looking at what might be wrong (if 
anything) with jhbuild?

Regards
Paul Rogers

> On 15 Feb 2022, at 01:55, John Ralls  wrote:
> 
> 
> 
>> On Feb 14, 2022, at 10:03 AM, Spock  wrote:
>> 
>> Hi, I’m running gtk-osx-setup.sh on an M1 Mac/MacOS 12.2 and am having a 
>> couple of problems ...
>> 
>> First off, I’m running without any homebrew paths in any of the environment 
>> variables.
>> 
>> Now, with this shell, when I run the script, I get the following:
>> 
>> — snip 
>> pyenv: pip: command not found
>> 
>> The `pip' command exists in these Python versions:
>> 3.10.0
>> 
>> Note: See 'pyenv help global' for tips on allowing both
>> python2 and python3 to be found.
>> pyenv: pip: command not found
>> 
>> The `pip' command exists in these Python versions:
>> 3.10.0
>> 
>> Note: See 'pyenv help global' for tips on allowing both
>> python2 and python3 to be found.
>> —- snip ---
>> 
>> So I add a line to the script to allow it to find python:
>> 
>> — snip —
>> PIP=“$PYENV_ROOT/shims/pip”
>> # Point pyenv at the 3.10.0 Python ...
>> $PYENV local 3.10.0
>> $PIP install --upgrade --user pip
>> — snip ---
>> 
>> With this line, I remove the artefacts from the previous build and re-run. 
>> This time the script completes, so I move on to “./.new_local/bin/jhbuild 
>> bootstrap-gtk-osx which appears to complete successfully.
>> 
>> *** Was this the right thing to do?
>> 
>> The final step “jhbuild meta-gtk-osx-bootstrap meta-gtk-osx-gtk3 fails due 
>> to problems finding a version of ninja …
>> 
>> — snip ---
>> gtk-doc 1.33.1
>> 
>> User defined options
>>   libdir : lib
>>   prefix : /Users/j/gtk/inst
>>   wrap_mode  : nofallback
>>   tests  : false
>>   yelp_manual: false
>> 
>> 
>> ERROR: Could not detect Ninja v1.8.2 or newer
>> — snip ---
>> 
>> I checked the version installed by the script …
>> 
>> — snip ---
>> j@pauls-mbp ~ [nobrew] % ./.new_local/bin/ninja —version
>> 1.10.2
>> — snip ---
>> 
>> *** So what is happening with ninja? Is there a setup step I’m missing?
>> 
>> Any help much appreciated!
> 
> Your fix for pip seems reasonable. Did you remember to add ~/.new_local/bin 
> to $PATH?
> 
> Regards,
> John Ralls
> 
> 

___
gtk-osx-devel-list mailing list
gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[John Ralls]

> On Feb 14, 2022, at 10:03 AM, Spock  wrote:
> 
> Hi, I’m running gtk-osx-setup.sh on an M1 Mac/MacOS 12.2 and am having a 
> couple of problems ...
> 
> First off, I’m running without any homebrew paths in any of the environment 
> variables.
> 
> Now, with this shell, when I run the script, I get the following:
> 
> — snip 
> pyenv: pip: command not found
> 
> The `pip' command exists in these Python versions:
>  3.10.0
> 
> Note: See 'pyenv help global' for tips on allowing both
>  python2 and python3 to be found.
> pyenv: pip: command not found
> 
> The `pip' command exists in these Python versions:
>  3.10.0
> 
> Note: See 'pyenv help global' for tips on allowing both
>  python2 and python3 to be found.
> —- snip ---
> 
> So I add a line to the script to allow it to find python:
> 
> — snip —
> PIP=“$PYENV_ROOT/shims/pip”
> # Point pyenv at the 3.10.0 Python ...
> $PYENV local 3.10.0
> $PIP install --upgrade --user pip
> — snip ---
> 
> With this line, I remove the artefacts from the previous build and re-run. 
> This time the script completes, so I move on to “./.new_local/bin/jhbuild 
> bootstrap-gtk-osx which appears to complete successfully.
> 
> *** Was this the right thing to do?
> 
> The final step “jhbuild meta-gtk-osx-bootstrap meta-gtk-osx-gtk3 fails due to 
> problems finding a version of ninja …
> 
> — snip ---
> gtk-doc 1.33.1
> 
>  User defined options
>libdir : lib
>prefix : /Users/j/gtk/inst
>wrap_mode  : nofallback
>tests  : false
>yelp_manual: false
> 
> 
> ERROR: Could not detect Ninja v1.8.2 or newer
> — snip ---
> 
> I checked the version installed by the script …
> 
> — snip ---
> j@pauls-mbp ~ [nobrew] % ./.new_local/bin/ninja —version
> 1.10.2
> — snip ---
> 
> *** So what is happening with ninja? Is there a setup step I’m missing?
> 
> Any help much appreciated!

Your fix for pip seems reasonable. Did you remember to add ~/.new_local/bin to 
$PATH?

Regards,
John Ralls


___
gtk-osx-devel-list mailing list
gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

Re: Method get_active_iter of ComboBox

[Kerenoc Kerenoc via gtk-perl-list]

Many thanks, it solved my problem.

And it prompted me to use perldoc on an Ubuntu virtual machine as  there
is'nt any Gtk related documentation on Strawberry Perl, my primary
development environment.

Regards

  Kerenoc

Le ven. 14 janv. 2022 à 13:00,  a écrit :

>
>
> Message: 1
> Date: Thu, 13 Jan 2022 21:30:52 +0100
> From: Torsten Schoenfeld 
> To: gtk-perl-list@gnome.org
> Subject: Re: Method get_active_iter of ComboBox
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 04.01.22 23:35, Kerenoc Kerenoc via gtk-perl-list wrote:
> > I'd like to know how to test the result of get_active_iter() when no
> > element is active.In Gtk2 it returns undef but in Gtk3 it returns a
> > Gtk3::TreeIter object that isn't usable.
>
> Apparently, we never added an overload for it to make it behave like in
> Gtk2, so you can ask perli11ndoc how to use it:
>
> ---
> # perli11ndoc Gtk3::ComboBox::get_active_iter
> METHOD
>
>Gtk3::ComboBox::get_active_iter [available since 2.4]
>
> SYNOPSIS
>
>($retval, $iter) = $object->get_active_iter ()
>
> DESCRIPTION
>
>...
>
> RETURN VALUES
>
>? gboolean
>  %TRUE if @iter was set, %FALSE otherwise
>
>? iter: Gtk3::TreeIter
>  A #GtkTreeIter
> ---
>
> Use the bool $retval to know whether $iter is valid.
>
> -Torsten
>
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: [gtk-osx-users] Setting up JHBuild environment and forcing builds if patches have changed

[John Ralls]

> On Jan 23, 2022, at 11:45 AM, Lukas Oberhuber via gtk-osx-users-list 
>  wrote:
> 
> Hi,
> 
> Two questions:
> 
> 1. How do I set up the JHBuild environment to then run my own build, for a 
> package?
> 
> 2. How can I configure JHBuild to detect that I've made a change to the 
> patches I've included on a package. This is especially critical for CI builds 
> where I find I have to make a commit with 'jhbuild buildone --force 
> package_name' because it otherwise won't detect the change (and I have to use 
> caching because the build otherwise times out so full rebuilds are not an 
> option).

The way I do #1 is to build whatever package I'm going to work on, then run 
`jhbuild shell && cd $PREFIX ../build/package && make uninstall` (or ninja 
uninstall if it's a meson project). You could also do `jhbuild build --skip foo 
foo` to build all of the dependencies without the package, but then you have to 
set up your own build directory and run the configuration (i.e. 
autogen.sh/autoreconf/configure, cmake, meson, ...) by hand. You'll need to do 
that anyway if you want to test different config options or build systems and 
it's sometimes a good idea to just clear out the build directory and 
reconfigure from scratch.

In another Terminal tab I cd to the corresponding src/package, though I don't 
usually start a jhbuild shell for that so I can't use $PREFIX. Aim your 
favorite editor at the same source directory. Now you can edit files in the 
editor, use the source-directory terminal tab for git, and run builds in the 
build-directory tab.

Changing patches on tarballs is a bit cumbersome because you have to stop the 
build and choose 6 - delete directory and start over. The only other way to get 
jhbuild to reload a tarball and apply different patches is to delete the source 
directory before starting jhbuild. The easiest way to deal with that is to set 
up a git build of that dependency and point the repo at a bare repo on your 
machine. Then you can push changes to that repo and jhbuild will pick them up 
without extra effort. That has the added advantage that you've got a git safety 
net for your work.

You don't want to use jhbuild in a CI recipe. I prepare a tarball of the 
dependencies by running jhbuild with a prefix pointed at a directory tree that 
mirrors the one that the CI runner uses. `jhbuild build --skip foo foo` builds 
and installs all of the dependencies. Tar up the prefix and put the tarball 
somewhere that the CI runner can find it and add a step to your CI recipe to 
retrieve and un-tar it. Build your project using the CI runner's build recipe.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Building freetype: Fatal error: 'hb-ft.h' file not found.

[John Ralls]

> On Jan 17, 2022, at 12:21 PM, Pascal  wrote:
> 
> 
>> Le 18 mai 2021 à 23:53, John Ralls  a écrit :
> ...
>> Examining the config.log from the year-ago build shows complaints about not 
>> finding libbrotlidec, so with autotools it's definitely an optional package. 
>> Brotli is off by default in CMakeLists.txt (CmakeCache.txt has
>> CMakeCache.txt:BROTLIDEC_INCLUDE_DIRS:PATH=BROTLIDEC_INCLUDE_DIRS-NOTFOUND
>> CMakeCache.txt:BROTLIDEC_LIBRARIES:FILEPATH=BROTLIDEC_LIBRARIES-NOTFOUND
>> CMakeCache.txt:FT_WITH_BROTLI:BOOL=OFF
>> ).
>> 
>> So my guess about Debian is that the packager built freetype2 with 
>> libbrotlidec installed but didn't include it in the package dependencies. 
>> They fixed that by adding it to the package dependencies rather than 
>> rebuilding it without brotli. As usual, that has nothing whatsoever to do 
>> with gtk-osx.
>> 
>> Interestingly https://ports.macports.org/port/freetype/summary shows their 
>> freetype2 depends on brotli while 
>> https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/freetype.rb 
>> shows Homebrew's doesn't.
> 
> Hello John,
> 
> Good guess, then I took some times to dig in my logs:
> 
> *** Configuring freetype-no-harfbuzz *** [13/32]
> cmake -DCMAKE_INSTALL_PREFIX=/usr/local/xnadalib-2021 
> -DCMAKE_INSTALL_LIBDIR=lib -G Ninja 
> -DCMAKE_DISABLE_FIND_PACKAGE_HarfBuzz=TRUE 
> -DCMAKE_DISABLE_FIND_PACKAGE_BZip2=TRUE -D BUILD_SHARED_LIBS=true -D 
> CMAKE_BUILD_TYPE=Release 
> -DCMAKE_INSTALL_NAME_DIR="/usr/local/xnadalib-2021/lib" 
> /usr/local/src-2021/freetype-2.10.4
> -- The C compiler identification is AppleClang 12.0.5.12050022
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: 
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Found ZLIB: /usr/local/xnadalib-2021/lib/libz.dylib (found version 
> "1.2.11") 
> -- Found PNG: /usr/local/xnadalib-2021/lib/libpng.dylib (found version 
> "1.6.37") 
> CMake Warning (dev) at 
> /usr/local/xnadalib-2021/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:438
>  (message):
>  The package name passed to `find_package_handle_standard_args` (PkgConfig)
>  does not match the name of the calling package (BrotliDec).  This can lead
>  to problems in calling code that expects `find_package` result variables
>  (e.g., `_FOUND`) to follow a certain pattern.
> Call Stack (most recent call first):
>  /usr/local/xnadalib-2021/share/cmake-3.20/Modules/FindPkgConfig.cmake:70 
> (find_package_handle_standard_args)
>  builds/cmake/FindBrotliDec.cmake:22 (include)
>  CMakeLists.txt:236 (find_package)
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> -- Found PkgConfig: /usr/local/xnadalib-2021/bin/pkg-config (found version 
> "0.29.2") 
> CMake Warning (dev) at 
> /usr/local/xnadalib-2021/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:438
>  (message):
>  The package name passed to `find_package_handle_standard_args` (brotlidec)
>  does not match the name of the calling package (BrotliDec).  This can lead
>  to problems in calling code that expects `find_package` result variables
>  (e.g., `_FOUND`) to follow a certain pattern.
> Call Stack (most recent call first):
>  builds/cmake/FindBrotliDec.cmake:43 (find_package_handle_standard_args)
>  CMakeLists.txt:236 (find_package)
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> -- Found brotlidec: /opt/local/include  
> 
> The configuration script had found BrotliDec in MacPorts folders: /opt/local.
> However I take care to keep away MacPorts when building GTK-OSX. 
> 
> How to prevent the search in /opt/local?
> 
> Looking at CMakeLists.txt, even Brotli is set off, it is looked for (line 90):
> #-D CMAKE_DISABLE_FIND_PACKAGE_BrotliDec=TRUE [...]
> 
> Or else is it possible to add this option?

Pascal,

You know darned well what my answer is for how to keep MacPorts or Homebrew 
from interfering with Gtk-OSX: Don't install either of them. 

Since you insist on breaking that rule it's up to you to figure out how to work 
around it. I'm certainly not going to spend time and corrupt my mac by 
installing MacPorts so that I can test for you.

I suppose that you tried starting a login shell with a clean .zsh_profile and 
that it didn't work. Did you try creating a user? If nothing else works a macOS 
VM should be sufficiently insulated from whatever you've done to the host 
system.

Brotli is a compression scheme that I guess is used for some fonts. I don't see 
any real value to adding it to Gtk-OSX.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Building freetype: Fatal error: 'hb-ft.h' file not found.

[Pascal]

> Le 18 mai 2021 à 23:53, John Ralls  a écrit :
...
> Examining the config.log from the year-ago build shows complaints about not 
> finding libbrotlidec, so with autotools it's definitely an optional package. 
> Brotli is off by default in CMakeLists.txt (CmakeCache.txt has
> CMakeCache.txt:BROTLIDEC_INCLUDE_DIRS:PATH=BROTLIDEC_INCLUDE_DIRS-NOTFOUND
> CMakeCache.txt:BROTLIDEC_LIBRARIES:FILEPATH=BROTLIDEC_LIBRARIES-NOTFOUND
> CMakeCache.txt:FT_WITH_BROTLI:BOOL=OFF
> ).
> 
> So my guess about Debian is that the packager built freetype2 with 
> libbrotlidec installed but didn't include it in the package dependencies. 
> They fixed that by adding it to the package dependencies rather than 
> rebuilding it without brotli. As usual, that has nothing whatsoever to do 
> with gtk-osx.
> 
> Interestingly https://ports.macports.org/port/freetype/summary shows their 
> freetype2 depends on brotli while 
> https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/freetype.rb shows 
> Homebrew's doesn't.

Hello John,

Good guess, then I took some times to dig in my logs:

*** Configuring freetype-no-harfbuzz *** [13/32]
cmake -DCMAKE_INSTALL_PREFIX=/usr/local/xnadalib-2021 
-DCMAKE_INSTALL_LIBDIR=lib -G Ninja -DCMAKE_DISABLE_FIND_PACKAGE_HarfBuzz=TRUE 
-DCMAKE_DISABLE_FIND_PACKAGE_BZip2=TRUE -D BUILD_SHARED_LIBS=true -D 
CMAKE_BUILD_TYPE=Release 
-DCMAKE_INSTALL_NAME_DIR="/usr/local/xnadalib-2021/lib" 
/usr/local/src-2021/freetype-2.10.4
-- The C compiler identification is AppleClang 12.0.5.12050022
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: 
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found ZLIB: /usr/local/xnadalib-2021/lib/libz.dylib (found version "1.2.11") 
-- Found PNG: /usr/local/xnadalib-2021/lib/libpng.dylib (found version 
"1.6.37") 
CMake Warning (dev) at 
/usr/local/xnadalib-2021/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:438
 (message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (BrotliDec).  This can lead
  to problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/local/xnadalib-2021/share/cmake-3.20/Modules/FindPkgConfig.cmake:70 
(find_package_handle_standard_args)
  builds/cmake/FindBrotliDec.cmake:22 (include)
  CMakeLists.txt:236 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found PkgConfig: /usr/local/xnadalib-2021/bin/pkg-config (found version 
"0.29.2") 
CMake Warning (dev) at 
/usr/local/xnadalib-2021/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:438
 (message):
  The package name passed to `find_package_handle_standard_args` (brotlidec)
  does not match the name of the calling package (BrotliDec).  This can lead
  to problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  builds/cmake/FindBrotliDec.cmake:43 (find_package_handle_standard_args)
  CMakeLists.txt:236 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found brotlidec: /opt/local/include  

The configuration script had found BrotliDec in MacPorts folders: /opt/local.
However I take care to keep away MacPorts when building GTK-OSX. 

How to prevent the search in /opt/local?

Looking at CMakeLists.txt, even Brotli is set off, it is looked for (line 90):
#-D CMAKE_DISABLE_FIND_PACKAGE_BrotliDec=TRUE [...]

Or else is it possible to add this option?

Thanks, Pascal.
https://blady.pagesperso-orange.fr


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Ninja not found.

[Pascal]

> Le 9 janv. 2022 à 18:40, john  a écrit :
> 
> 
> 
>> On Jan 9, 2022, at 4:51 AM, Pascal  wrote:
>> 
>> Hello,
>> 
>> When building:
>> 
>> % sh gtk-osx-setup.sh
>> % PATH=.new_local/bin:$PATH
>> 
>> % jhbuild bootstrap-gtk-osx
>> % jhbuild build pygments
>> % jhbuild build meta-gtk-osx-bootstrap
>> 
>> An error occurs: ninja is not found.
>> 
>> It happens that .new_local/bin is not appended to PATH before running the 
>> original jhbuild.
>> Thus I propose to add it when creating local jhbuild:
>> 
>> --- ./gtk-osx-setup.sh.0 2022-01-04 21:43:05.0 +0100
>> +++ ./gtk-osx-setup.sh   2022-01-09 13:33:04.0 +0100
>> @@ -188,7 +188,7 @@
>> export PIPENV_PIPFILE="$DEVPREFIX/etc/Pipfile"
>> export PYENV_ROOT="$PYENV_ROOT"
>> export PYENV_VERSION="$PYENV_VERSION"
>> -export PATH="$PYENV_ROOT/shims:$PATH"
>> +export PATH="$PYENV_ROOT/shims:$DEVPREFIX/bin:$PATH"
>> export CARGO_HOME="$CARGO_HOME"
>> export RUSTUP_HOME="$RUSTUP_HOME"
>> export WORKON_HOME="$WORKON_HOME"
>> 
>> What is your feedback?
>> 
> 
> Instead of 
> 
>  PATH=.new_local/bin:$PATH
> 
> you need to say
> 
>  export PATH="$HOME/.new_local/bin:$PATH"
> 
> otherwise it has effect for only that line.
> 
> Adding the path export to $DEVPREFIX/bin/jhbuild would require invoking 
> jhbuild with ~/.new_local/bin/jhbuild because it's not on the path. I think 
> it's better to have the user set the path in their shell rc file. I think 
> install scripts like Rust's that do that for the user are annoying. That's 
> why gtk-osx-setup.sh issues a warning instead of adding it.

Hello John,

Fully agreed.
I don't really like when my shell rc files are automatically modified like Rust 
install did.
Rust install added a shell script to add the rust compiler location to PATH, 
that is in our case: $DEVPREFIX/bin.

Thus an extra option has been added to prevent it:
https://github.com/jralls/gtk-osx-build/commit/99fec075c1417bca5e814e8bd0d19e873143f6b2#diff-4ea81385fdbe38d9a30830cbec97fc6ce49505903123c2bd9aa9d91cc9b4a161R151

I notice that shell rc files aren't anymore modified, perfect.

Thus, as now Rust install doesn't add it to PATH and if you haven't done before 
on command line or in your shell rc files then it is not taken in account when 
building PATH for jhbuild script:
https://github.com/jralls/gtk-osx-build/blob/master/gtk-osx-setup.sh#L191

Even setting PATH after executing gtk-osx-setup.sh, I got:

% PATH=/usr/local/src-2021/.new_local/bin:$PATH
% which ninja
/usr/local/src-2021/.new_local/bin/ninja
% jhbuild shell  
Loading .env environment variables...
Prefix: /usr/local/xnadalib-2021
Entered jhbuild shell, type 'exit' to return.
Restored session: Sun Jan 16 12:22:17 CET 2022
[JH] % which ninja
ninja not found

How to get a good PATH setting with jhbuild on a fresh session?

Thanks, Pascal.
https://blady.pagesperso-orange.fr


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Setting module_extra_env['pkg-config'] discussion.

[john]

> On Jan 15, 2022, at 7:46 AM, Pascal  wrote:
> 
> Hello,
> 
> JHbuildrc line 622 is:
> module_extra_env['pkg-config'] = {'PYTHON':sys.executable}
> (https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/jhbuildrc-gtk-osx#L622)
> 
> This overrides the previous line 364:
> module_extra_env["pkg-config"] = {'CFLAGS': os.environ['CFLAGS'] + ' 
> -std=gnu89'}
> (https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/jhbuildrc-gtk-osx#L364)
> 
> Shouldn't line 622 updates the value instead of overriding?

Probably, but since pkg-config seems to build fine with the CFLAGS being 
overridden I suspect that line 364 can be removed.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[Pascal]

> Le 14 janv. 2022 à 22:23, John Ralls  a écrit :
> 
> Pascal,
> 
> I happened to have started looking into this yesterday; I can reproduce the 
> issue. shared-mime-info is currently installed only on the stable branch and 
> the only target that depends on it is devhelp-gtk3. Installing it and making 
> sure that XDG_DATA_DIRS includes $PREFIX/share didn't prevent the complaint 
> about not being able to handle the SVG file. At that point I ran out of time. 
> I'll get back to it today or tomorrow.

Thanks John, please don't be too much in a hurry for that ;-)

In the meanwhile, I'll take the opportunity to improve my proposal for LibXML2 
configuration patch.

Pascal.
https://blady.pagesperso-orange.fr


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[John Ralls]

> On Jan 14, 2022, at 12:57 PM, Pascal  wrote:
> 
> 
>> Le 11 janv. 2022 à 05:35, john  a écrit :
>> 
>>> On Jan 10, 2022, at 1:06 PM, Pascal  wrote:
>>> 
>>> I ran gdk-pixbuf-query-loaders --update-cache and even set 
>>> GDK_PIXBUF_MODULEDIR:
>>> 
>>> % LANG=en GDK_PIXBUF_MODULEDIR=$xnadainst/lib/gdk-pixbuf-2.0/2.10.0/loaders 
>>> XDG_DATA_DIRS=$xnadainst/share ./testgtk
>>> 
>>> (testgtk:29352): Gtk-WARNING **: 21:49:39.220: Could not load a pixbuf from 
>>> icon theme.
>>> This may indicate that pixbuf loaders or the mime database could not be 
>>> found.
>>> **
>>> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
>>>  assertion failed (error == NULL): Failed to load 
>>> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png:
>>>  Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>>> Bail out! 
>>> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
>>>  assertion failed (error == NULL): Failed to load 
>>> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png:
>>>  Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>>> 
>>> What is the "mime database" present in the GTK warning message?
>>> May the error coming from this file?
>> 
>> Pascal,
>> 
>> The mime database maps file extensions to types, among a bunch of other 
>> things. It lives in $PREFIX/share/mime and is built by the shared-mime-info 
>> package.
>> 
>> Maybe there's something messed up with the png loader? You can `grep png 
>> $PREFIX/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache` to make sure it's 
>> catalogued. Check also that 
>> $PREFIX/lib/gdk-pixbuff-2.0/2.10.0/loaders/libpixbufloader-png.so is present 
>> and that its dependencies are all sane.
> 
> Hello John,
> 
> I have no mime file or folder:
> 
> % ls /usr/local/xnadalib-2021/share/m*
> /usr/local/xnadalib-2021/share/man:
> man1/ man3/ man5/ man8/
> 
> /usr/local/xnadalib-2021/share/metainfo:
> org.gnome.Glade.appdata.xml
> 
> Neither shared-mime-info file.
> 
> I found this issue in Gnome:
> https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/159
> 
> And this one too:
> https://source.puri.sm/Librem5/OS-issues/-/issues/17
> 
> But I didn't find update-mime-database.
> Is it needed to install it? With jhbuild?
> 
> Here are my status of png install:
> 
> % grep png /usr/local/xnadalib-2021/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache 
> "lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so"
> "png" 5 "gdk-pixbuf" "PNG" "LGPL"
> "image/png" ""
> "png" ""
> 
> % ls 
> /usr/local/xnadalib-2021/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png*
> /usr/local/xnadalib-2021/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so*
> 
> It seems to be good.
> 
> How to check "that its dependencies are all sane"?

Pascal,

I happened to have started looking into this yesterday; I can reproduce the 
issue. shared-mime-info is currently installed only on the stable branch and 
the only target that depends on it is devhelp-gtk3. Installing it and making 
sure that XDG_DATA_DIRS includes $PREFIX/share didn't prevent the complaint 
about not being able to handle the SVG file. At that point I ran out of time. 
I'll get back to it today or tomorrow.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[Pascal]

> Le 11 janv. 2022 à 05:35, john  a écrit :
> 
>> On Jan 10, 2022, at 1:06 PM, Pascal  wrote:
>> 
>> I ran gdk-pixbuf-query-loaders --update-cache and even set 
>> GDK_PIXBUF_MODULEDIR:
>> 
>> % LANG=en GDK_PIXBUF_MODULEDIR=$xnadainst/lib/gdk-pixbuf-2.0/2.10.0/loaders 
>> XDG_DATA_DIRS=$xnadainst/share ./testgtk
>> 
>> (testgtk:29352): Gtk-WARNING **: 21:49:39.220: Could not load a pixbuf from 
>> icon theme.
>> This may indicate that pixbuf loaders or the mime database could not be 
>> found.
>> **
>> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
>>  assertion failed (error == NULL): Failed to load 
>> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png: 
>> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>> Bail out! 
>> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
>>  assertion failed (error == NULL): Failed to load 
>> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png: 
>> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>> 
>> What is the "mime database" present in the GTK warning message?
>> May the error coming from this file?
> 
> Pascal,
> 
> The mime database maps file extensions to types, among a bunch of other 
> things. It lives in $PREFIX/share/mime and is built by the shared-mime-info 
> package.
> 
> Maybe there's something messed up with the png loader? You can `grep png 
> $PREFIX/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache` to make sure it's 
> catalogued. Check also that 
> $PREFIX/lib/gdk-pixbuff-2.0/2.10.0/loaders/libpixbufloader-png.so is present 
> and that its dependencies are all sane.

Hello John,

I have no mime file or folder:

% ls /usr/local/xnadalib-2021/share/m*
/usr/local/xnadalib-2021/share/man:
man1/ man3/ man5/ man8/

/usr/local/xnadalib-2021/share/metainfo:
org.gnome.Glade.appdata.xml

Neither shared-mime-info file.

I found this issue in Gnome:
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/159

And this one too:
https://source.puri.sm/Librem5/OS-issues/-/issues/17

But I didn't find update-mime-database.
Is it needed to install it? With jhbuild?

Here are my status of png install:

% grep png /usr/local/xnadalib-2021/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache 
"lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so"
"png" 5 "gdk-pixbuf" "PNG" "LGPL"
"image/png" ""
"png" ""

% ls 
/usr/local/xnadalib-2021/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png*
/usr/local/xnadalib-2021/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so*

It seems to be good.

How to check "that its dependencies are all sane"?

Thanks for your help, Pascal.
https://blady.pagesperso-orange.fr


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: Method get_active_iter of ComboBox

[Torsten Schoenfeld via gtk-perl-list]

On 04.01.22 23:35, Kerenoc Kerenoc via gtk-perl-list wrote:

I'd like to know how to test the result of get_active_iter() when no
element is active.In Gtk2 it returns undef but in Gtk3 it returns a
Gtk3::TreeIter object that isn't usable.


Apparently, we never added an overload for it to make it behave like in
Gtk2, so you can ask perli11ndoc how to use it:

---
# perli11ndoc Gtk3::ComboBox::get_active_iter
METHOD

  Gtk3::ComboBox::get_active_iter [available since 2.4]

SYNOPSIS

  ($retval, $iter) = $object->get_active_iter ()

DESCRIPTION

  ...

RETURN VALUES

  • gboolean
%TRUE if @iter was set, %FALSE otherwise

  • iter: Gtk3::TreeIter
A #GtkTreeIter
---

Use the bool $retval to know whether $iter is valid.

-Torsten
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[john]

> On Jan 10, 2022, at 1:06 PM, Pascal  wrote:
> 
>> 
>> Le 3 janv. 2022 à 01:52, john > > a écrit :
>> 
>>> On Jan 2, 2022, at 3:23 AM, Pascal  wrote:
>>> 
 Le 30 déc. 2021 à 19:31, John Ralls  a écrit :
 
> On Dec 30, 2021, at 10:21 AM, Pascal  wrote:
> 
>> Le 30 déc. 2021 à 17:57, Paul Emsley via gtk-osx-users-list 
>>  a écrit :
>> 
>> On 30/12/2021 16:13, Pascal wrote:
 Le 30 déc. 2021 à 14:43, Paul Emsley via gtk-osx-users-list 
  a écrit :
 
 On 30/12/2021 11:29, Pascal wrote:
> Hello,
> 
> My configuration is macOS 12, I just built:
> 
> % jhbuild bootstrap-gtk-osx
> % jhbuild build python3
> % jhbuild build meta-gtk-osx-bootstrap
> 
> When I build my program I got a lot of:
> ld: warning: dylib (/usr/local/xnadalib-2021/lib/libgtk-3.dylib) was 
> built for newer macOS version (12.0) than being linked (11.0)
> 
> It is not so clear.
> What is this actually meaning?
> 
> This seems just to be a warning but my program shows some erroneous 
> GTK executions.
> 
> How to deal with it?
> 
> NB : with GTK which was built when I was on macOS 11, I have no 
> warning and no issue to build my program on macOS 12.
> 
 Have you installed homebrew? If so, rename or remove it while 
 compiling gtk-osx.
>>> No Paul, I haven't.
>> OK, interesting. It seems that you do have something in /usr/local 
>> though - do you know what it is?
> 
> I found only CLI tools like BBEdit or OSXFuse.
> 
>>> I have MacPorts installed in /usr/local/local but not in PATH.
>>> Should I delete XDG_CACHE_HOME folder before building GTK?
>> 
>> I don't know, sorry. My feeling is that you shouldn't need to do so.
> 
> When looking in environnement variables in jhbuild shell, I found:
> [JH] % echo $MACOSX_DEPLOYMENT_TARGET 
> 12
> 
> Should I specify 11 in calling setup_sdk in jhbuildrc-custom?
> 
> If so, I wonder: why the link message is issued as I have rebuilt all on 
> macOS 12?
 
 The link message is saying that whatever you're trying to link was 
 compiled with macosx-version-min=11.0 while libgtk-3.dylib was compiled 
 with macosx-version-min=12.0. Did you perhaps forget to reconfigure your 
 project after rebuilding everything else?
>>> 
>>> Hello John,
>>> 
>>> I aim to build the GTKAda bindings with the fixed version of GTK for macOS 
>>> 12.
>>> I dig in my building configuration without success.
>>> In fact the issue is coming from my Ada compiler which is stuck to macOS 
>>> 11, the internal compilation is done with -mmacosx-version-min=11.0.0.
>>> 
>>> So I got:
>>> otool -l 
>>> /usr/local/xnadalib-2021/lib/gtkada/gtkada.relocatable/gtkada/libgtkada.dylib
>>> cmd LC_BUILD_VERSION
>>> cmdsize 32
>>> platform 1
>>>   minos 11.0
>>> sdk 10.17
>>> 
>>> Thus the warning.
>>> 
>>> The test program is nevertheless running but fails with:
>>> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
>>>  assertion failed (error == NULL): Failed to load 
>>> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png:
>>>  Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>>> Bail out! 
>>> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
>>>  assertion failed (error == NULL): Failed to load 
>>> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png:
>>>  Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>>> 
>>> However the GTKAda source code is the same since I built it on macOS 11 
>>> with success.
>>> 
>>> Well now, should I specify setup_sdk(target="11") in jhbuildrc-custom and 
>>> rebuild all GTK stuff?
>> 
>> The gdk-pixbuf errors have to do with not being able to find its modules. 
>> That might be because you need to run gdk-pixbuf-query-loaders 
>> --update-cache (in a jhbuild shell of course!) or you need to set 
>> GDK_PIXBUF_MODULEDIR to point at where it is, see 
>> http://manpages.ubuntu.com/manpages/impish/man1/gdk-pixbuf-query-loaders.1.html
>>  
>> .
> 
> Thanks John,
> 
> I was blinded with the linker warning and the fact I had just upgrading with 
> macOS 12.
> Obviously it is not the case: I built all GTK again with 
> setup_sdk(target="10.11") with no more success.
> I'm so confused that all was well on October with macOS 11 and not now with 
> these GTK errors with macOS 12 :-(
> 
> I ran gdk-pixbuf-query-loaders --update-cache and even set 
> GDK_PIXBUF_MODULEDIR:
> 
> % LANG=en GDK_PIXBUF_MODULEDIR=$xnadainst/lib/gdk-pixbuf-2.0/2.10.0/loaders 
> XDG_DATA_DIRS=$xnadainst/share ./testgtk
> 
> (testgtk:29352): Gtk-WARNING 

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[Pascal]

> Le 3 janv. 2022 à 01:52, john  a écrit :
> 
>> On Jan 2, 2022, at 3:23 AM, Pascal  wrote:
>> 
>>> Le 30 déc. 2021 à 19:31, John Ralls  a écrit :
>>> 
 On Dec 30, 2021, at 10:21 AM, Pascal  wrote:
 
> Le 30 déc. 2021 à 17:57, Paul Emsley via gtk-osx-users-list 
>  a écrit :
> 
> On 30/12/2021 16:13, Pascal wrote:
>>> Le 30 déc. 2021 à 14:43, Paul Emsley via gtk-osx-users-list 
>>>  a écrit :
>>> 
>>> On 30/12/2021 11:29, Pascal wrote:
 Hello,
 
 My configuration is macOS 12, I just built:
 
 % jhbuild bootstrap-gtk-osx
 % jhbuild build python3
 % jhbuild build meta-gtk-osx-bootstrap
 
 When I build my program I got a lot of:
 ld: warning: dylib (/usr/local/xnadalib-2021/lib/libgtk-3.dylib) was 
 built for newer macOS version (12.0) than being linked (11.0)
 
 It is not so clear.
 What is this actually meaning?
 
 This seems just to be a warning but my program shows some erroneous 
 GTK executions.
 
 How to deal with it?
 
 NB : with GTK which was built when I was on macOS 11, I have no 
 warning and no issue to build my program on macOS 12.
 
>>> Have you installed homebrew? If so, rename or remove it while compiling 
>>> gtk-osx.
>> No Paul, I haven't.
> OK, interesting. It seems that you do have something in /usr/local though 
> - do you know what it is?
 
 I found only CLI tools like BBEdit or OSXFuse.
 
>> I have MacPorts installed in /usr/local/local but not in PATH.
>> Should I delete XDG_CACHE_HOME folder before building GTK?
> 
> I don't know, sorry. My feeling is that you shouldn't need to do so.
 
 When looking in environnement variables in jhbuild shell, I found:
 [JH] % echo $MACOSX_DEPLOYMENT_TARGET 
 12
 
 Should I specify 11 in calling setup_sdk in jhbuildrc-custom?
 
 If so, I wonder: why the link message is issued as I have rebuilt all on 
 macOS 12?
>>> 
>>> The link message is saying that whatever you're trying to link was compiled 
>>> with macosx-version-min=11.0 while libgtk-3.dylib was compiled with 
>>> macosx-version-min=12.0. Did you perhaps forget to reconfigure your project 
>>> after rebuilding everything else?
>> 
>> Hello John,
>> 
>> I aim to build the GTKAda bindings with the fixed version of GTK for macOS 
>> 12.
>> I dig in my building configuration without success.
>> In fact the issue is coming from my Ada compiler which is stuck to macOS 11, 
>> the internal compilation is done with -mmacosx-version-min=11.0.0.
>> 
>> So I got:
>> otool -l 
>> /usr/local/xnadalib-2021/lib/gtkada/gtkada.relocatable/gtkada/libgtkada.dylib
>>  cmd LC_BUILD_VERSION
>>  cmdsize 32
>> platform 1
>>minos 11.0
>>  sdk 10.17
>> 
>> Thus the warning.
>> 
>> The test program is nevertheless running but fails with:
>> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
>>  assertion failed (error == NULL): Failed to load 
>> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png: 
>> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>> Bail out! 
>> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
>>  assertion failed (error == NULL): Failed to load 
>> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png: 
>> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>> 
>> However the GTKAda source code is the same since I built it on macOS 11 with 
>> success.
>> 
>> Well now, should I specify setup_sdk(target="11") in jhbuildrc-custom and 
>> rebuild all GTK stuff?
> 
> The gdk-pixbuf errors have to do with not being able to find its modules. 
> That might be because you need to run gdk-pixbuf-query-loaders --update-cache 
> (in a jhbuild shell of course!) or you need to set GDK_PIXBUF_MODULEDIR to 
> point at where it is, see 
> http://manpages.ubuntu.com/manpages/impish/man1/gdk-pixbuf-query-loaders.1.html.

Thanks John,

I was blinded with the linker warning and the fact I had just upgrading with 
macOS 12.
Obviously it is not the case: I built all GTK again with 
setup_sdk(target="10.11") with no more success.
I'm so confused that all was well on October with macOS 11 and not now with 
these GTK errors with macOS 12 :-(

I ran gdk-pixbuf-query-loaders --update-cache and even set GDK_PIXBUF_MODULEDIR:

% LANG=en GDK_PIXBUF_MODULEDIR=$xnadainst/lib/gdk-pixbuf-2.0/2.10.0/loaders 
XDG_DATA_DIRS=$xnadainst/share ./testgtk

(testgtk:29352): Gtk-WARNING **: 21:49:39.220: Could not load a pixbuf from 
icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
 assertion failed (error == NULL): Failed to load 

Re: [gtk-osx-users] Ninja not found.

[john]

> On Jan 9, 2022, at 4:51 AM, Pascal  wrote:
> 
> Hello,
> 
> When building:
> 
> % sh gtk-osx-setup.sh
> % PATH=.new_local/bin:$PATH
> 
> % jhbuild bootstrap-gtk-osx
> % jhbuild build pygments
> % jhbuild build meta-gtk-osx-bootstrap
> 
> An error occurs: ninja is not found.
> 
> It happens that .new_local/bin is not appended to PATH before running the 
> original jhbuild.
> Thus I propose to add it when creating local jhbuild:
> 
> --- ./gtk-osx-setup.sh.0  2022-01-04 21:43:05.0 +0100
> +++ ./gtk-osx-setup.sh2022-01-09 13:33:04.0 +0100
> @@ -188,7 +188,7 @@
> export PIPENV_PIPFILE="$DEVPREFIX/etc/Pipfile"
> export PYENV_ROOT="$PYENV_ROOT"
> export PYENV_VERSION="$PYENV_VERSION"
> -export PATH="$PYENV_ROOT/shims:$PATH"
> +export PATH="$PYENV_ROOT/shims:$DEVPREFIX/bin:$PATH"
> export CARGO_HOME="$CARGO_HOME"
> export RUSTUP_HOME="$RUSTUP_HOME"
> export WORKON_HOME="$WORKON_HOME"
> 
> What is your feedback?
> 

Instead of 

  PATH=.new_local/bin:$PATH

you need to say

  export PATH="$HOME/.new_local/bin:$PATH"

otherwise it has effect for only that line.

Adding the path export to $DEVPREFIX/bin/jhbuild would require invoking jhbuild 
with ~/.new_local/bin/jhbuild because it's not on the path. I think it's better 
to have the user set the path in their shell rc file. I think install scripts 
like Rust's that do that for the user are annoying. That's why gtk-osx-setup.sh 
issues a warning instead of adding it.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] LibXML2 site-packages configuration.

[john]

> On Jan 9, 2022, at 4:40 AM, Pascal  wrote:
> 
>> 
>> Le 8 janv. 2022 à 15:26, Pascal  a écrit :
>> 
>> Hello,
>> 
>> As the jhbuild Python version has changed to 3.10 and moduleset Python 
>> version is still 3.9, when building Python and GTK, LibXML2 is puzzled to 
>> find the good site-packages folder.
>> 
>> /usr/local/xnadalib-2021/lib/python3.9/site-packages
>> and
>> /usr/local/xnadalib-2021/lib/python3.10/site-packages
>> are both present in prefix.
>> 
>> LibXML2 is installed in the latter :-(
>> 
>> I propose some changes:
>> 
>> +++ ./jhbuildrc  2022-01-08 13:21:29.0 +0100
>> @@ -23,6 +23,7 @@
>> import sys
>> import errno
>> import re
>> +import subprocess
>> 
>> #some variables we'll need defined later
>> _default_arch = ""
>> @@ -620,6 +622,18 @@
>>'pygments' in modules):
>>os.environ['PYTHON'] = os.path.join(prefix, 'bin', 'python3')
>>module_extra_env['pkg-config'] = {'PYTHON':sys.executable}
>> +elif os.path.isfile (os.path.join(prefix, 'bin', 'python3')):
>> +python_version = subprocess.Popen([os.path.join(prefix, 'bin', 
>> 'python3'), "--version"], stdout=subprocess.PIPE).stdout.read()
>> +_python_ver = re.search(r"Python ([0-9]+[.][0-9]+)[.]", 
>> python_version.decode('utf-8')).group(1)
>> +_python_install_path = os.path.join(prefix, 'lib', 'python' + 
>> _python_ver,
>> +'site-packages')
>> +append_autogenargs('libxml2',
>> +   '--with-python-install-dir=' + _python_install_path)
>> +environ_append('PYTHONPATH', _python_install_path, ':')
>> +_python_library_path = os.path.join(prefix, 'lib')
>> +environ_append('LDFLAGS', '-L' + _python_library_path)
>> +os.environ['PYTHON'] = os.path.join(prefix, 'bin', 'python3')
>> +del python_version
>> else:
>>_python_ver = str(sys.version_info.major) + '.' + 
>> str(sys.version_info.minor)
>>_python_install_path = os.path.join(prefix, 'lib', 'python' + _python_ver,
> 
> I went too fast on that changes, GTK build is broken, so I propose to merge 
> both environnements if Python3 is installed in prefix:
> 
> +elif os.path.isfile (os.path.join(prefix, 'bin', 'python3')):
> +python_version = subprocess.Popen([os.path.join(prefix, 'bin', 
> 'python3'), "--version"], stdout=subprocess.PIPE).stdout.read()
> +_python_ver = re.search(r"Python ([0-9]+[.][0-9]+)[.]", 
> python_version.decode('utf-8')).group(1)
> +_python_install_path = os.path.join(prefix, 'lib', 'python' + 
> _python_ver,
> +'site-packages')
> +append_autogenargs('libxml2',
> +   '--with-python-install-dir=' + _python_install_path)
> +environ_append('PYTHONPATH', _python_install_path, ':')
> +_python_library_path = os.path.join(prefix, 'lib')
> +environ_append('LDFLAGS', '-L' + _python_library_path)
> +_python_ver = str(sys.version_info.major) + '.' + 
> str(sys.version_info.minor)
> +_python_install_path = os.path.join(prefix, 'lib', 'python' + 
> _python_ver,
> +'site-packages')
> +environ_append('PYTHONPATH', _python_install_path, ':')
> +_python_library_path = os.path.join(os.environ['PYENV_ROOT'], 'versions',
> +   os.environ['PYENV_VERSION'], 'lib')
> +environ_append('LDFLAGS', '-L' + _python_library_path)
> +os.environ['PYTHON'] = sys.executable
> +del python_version
> 
> Is it not too much confusing?
> 

Definitely too confusing, see my comment on the other thread.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK-DOC Required Python3 module 'pygments' not found.

[john]

> On Jan 9, 2022, at 4:27 AM, Pascal  wrote:
> 
> 
>> Le 28 déc. 2021 à 21:07, Pascal  a écrit :
>> 
>>> Le 28 déc. 2021 à 17:18, john  a écrit :
>>> 
 On Dec 28, 2021, at 1:48 AM, Pascal  wrote:
 
 Hello,
 
 For this build, I needed Python3, so I did:
 
 %  jhbuild bootstrap-gtk-osx
 %  jhbuild build python3
 %  jhbuild build meta-gtk-osx-bootstrap
 ...
 *** Configuring gtk-doc *** [8/9]
 meson --prefix /usr/local/xnadalib-2021 --libdir lib -Dyelp_manual=false 
 -Dtests=false --wrap-mode=nofallback /usr/local/src-2021/gtk-doc-1.33.2
 The Meson build system
 Version: 0.60.3
 Source dir: /usr/local/src-2021/gtk-doc-1.33.2
 Build dir: /usr/local/src-2021/cache/jhbuild/build/gtk-doc-1.33.2
 Build type: native build
 Project name: gtk-doc
 Project version: 1.33.1
 C compiler for the host machine: 
 /Applications/Xcode.app/Contents/Developer/usr/bin/gcc (clang 13.0.0 
 "Apple clang version 13.0.0 (clang-1300.0.29.3)")
 C linker for the host machine: 
 /Applications/Xcode.app/Contents/Developer/usr/bin/gcc ld64 711
 Host machine cpu family: x86_64
 Host machine cpu: x86_64
 Program python3 found: YES (/usr/local/xnadalib-2021/bin/python3)
 
 ../../../../gtk-doc-1.33.2/meson.build:45:4: ERROR: Problem encountered: 
 Required Python3 module 'pygments' not found
 
 The build used python3 installed in prefix (/usr/local/xnadalib-2021) 
 which is expected, isn't it?
 
 Do I need to install pygments in addition ?
 If so how do to it? with jhbuild?
 Thanks for help.
>>> 
>>> If you use pygments instead of python3 in your modules list it will pull in 
>>> python3 and build pygments for you. If you're already into the build it's 
>>> easier to just drop to a shell and say 'pip3 install pygments'.
>> 
>> 
>> Thanks John, I did the pip3 with success.
> 
> Hello John,
> 
> This time, i tried 'jhbuild build pygments'.
> It works but pygments is installed in $prefix/lib/python3.10/site-packages.
> That's odd if you install before Python3 which is version 3.9.
> GTK-DOC is still puzzled.
> Then in order to get pygments installed in 
> $prefix/lib/python3.9/site-packages, I propose to change jhbuildrc as:
> 
> if ('python3' in modules or 'meta-gtk-osx-python3' in modules or
> -'pygments' in modules):
> +'pygments' in modules
> +or 'python3' in sys.argv or 'meta-gtk-osx-python3' in sys.argv
> +or 'pygments' in sys.argv):
> 
> What is your feedback?

I think that's getting a bit too convoluted and the whole approach is too 
fragile. Recalling that the original purpose--still required--of the segment 
was to make sure that libxml2's python module got put in the right 
$PREFIX/lib/pythonxx, none of that will work if the user does
  jhbuild build python3
  jhbuild meta-gtk-osx-bootstrap

Xcode 12's addition of a python3 framework that doesn't include the headers is 
another problem because pipenv is finding it and setting up the virtenv in 
spite of the directive in Pipfile to use 3.10 which is supposed to trigger an 
automatic build and install of python3.10 and create a virtenv from that. As 
long as one builds and installs python3 into $PREFIX it's not that important, 
but if one doesn't then building libxml2 and pygments will fail for no Python.h.

To add to the fun I discovered yesterday that librsvg has added two more PyPi 
dependencies, documents and go-documentation, in their master branch, and no 
configure option to disable making documentation and thus to avoid them.

It would be nice to have a pip3 module in jhbuild so one could just say

  

and it would do the right thing. That still wouldn't fix libxml2 but it would 
take care of everything else.

Failing that we need logic in jhbuildrc that looks at the project modules list 
to see what jhbuild is actually going to build and checks for 
$PREFIX/bin/python3-config to see if python3 is already built. Easiest said 
than done, unfortunately.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] LibXML2 site-packages configuration.

[Pascal]

> Le 8 janv. 2022 à 15:26, Pascal  a écrit :
> 
> Hello,
> 
> As the jhbuild Python version has changed to 3.10 and moduleset Python 
> version is still 3.9, when building Python and GTK, LibXML2 is puzzled to 
> find the good site-packages folder.
> 
> /usr/local/xnadalib-2021/lib/python3.9/site-packages
> and
> /usr/local/xnadalib-2021/lib/python3.10/site-packages
> are both present in prefix.
> 
> LibXML2 is installed in the latter :-(
> 
> I propose some changes:
> 
> +++ ./jhbuildrc   2022-01-08 13:21:29.0 +0100
> @@ -23,6 +23,7 @@
> import sys
> import errno
> import re
> +import subprocess
> 
> #some variables we'll need defined later
> _default_arch = ""
> @@ -620,6 +622,18 @@
> 'pygments' in modules):
> os.environ['PYTHON'] = os.path.join(prefix, 'bin', 'python3')
> module_extra_env['pkg-config'] = {'PYTHON':sys.executable}
> +elif os.path.isfile (os.path.join(prefix, 'bin', 'python3')):
> +python_version = subprocess.Popen([os.path.join(prefix, 'bin', 
> 'python3'), "--version"], stdout=subprocess.PIPE).stdout.read()
> +_python_ver = re.search(r"Python ([0-9]+[.][0-9]+)[.]", 
> python_version.decode('utf-8')).group(1)
> +_python_install_path = os.path.join(prefix, 'lib', 'python' + 
> _python_ver,
> +'site-packages')
> +append_autogenargs('libxml2',
> +   '--with-python-install-dir=' + _python_install_path)
> +environ_append('PYTHONPATH', _python_install_path, ':')
> +_python_library_path = os.path.join(prefix, 'lib')
> +environ_append('LDFLAGS', '-L' + _python_library_path)
> +os.environ['PYTHON'] = os.path.join(prefix, 'bin', 'python3')
> +del python_version
> else:
> _python_ver = str(sys.version_info.major) + '.' + 
> str(sys.version_info.minor)
> _python_install_path = os.path.join(prefix, 'lib', 'python' + _python_ver,

I went too fast on that changes, GTK build is broken, so I propose to merge 
both environnements if Python3 is installed in prefix:

+elif os.path.isfile (os.path.join(prefix, 'bin', 'python3')):
+python_version = subprocess.Popen([os.path.join(prefix, 'bin', 'python3'), 
"--version"], stdout=subprocess.PIPE).stdout.read()
+_python_ver = re.search(r"Python ([0-9]+[.][0-9]+)[.]", 
python_version.decode('utf-8')).group(1)
+_python_install_path = os.path.join(prefix, 'lib', 'python' + _python_ver,
+'site-packages')
+append_autogenargs('libxml2',
+   '--with-python-install-dir=' + _python_install_path)
+environ_append('PYTHONPATH', _python_install_path, ':')
+_python_library_path = os.path.join(prefix, 'lib')
+environ_append('LDFLAGS', '-L' + _python_library_path)
+_python_ver = str(sys.version_info.major) + '.' + 
str(sys.version_info.minor)
+_python_install_path = os.path.join(prefix, 'lib', 'python' + _python_ver,
+'site-packages')
+environ_append('PYTHONPATH', _python_install_path, ':')
+_python_library_path = os.path.join(os.environ['PYENV_ROOT'], 'versions',
+   os.environ['PYENV_VERSION'], 'lib')
+environ_append('LDFLAGS', '-L' + _python_library_path)
+os.environ['PYTHON'] = sys.executable
+del python_version

Is it not too much confusing?

Thanks, Pascal.
https://blady.pagesperso-orange.fr


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK-DOC Required Python3 module 'pygments' not found.

[Pascal]

> Le 28 déc. 2021 à 21:07, Pascal  a écrit :
> 
>> Le 28 déc. 2021 à 17:18, john  a écrit :
>> 
>>> On Dec 28, 2021, at 1:48 AM, Pascal  wrote:
>>> 
>>> Hello,
>>> 
>>> For this build, I needed Python3, so I did:
>>> 
>>> %  jhbuild bootstrap-gtk-osx
>>> %  jhbuild build python3
>>> %  jhbuild build meta-gtk-osx-bootstrap
>>> ...
>>> *** Configuring gtk-doc *** [8/9]
>>> meson --prefix /usr/local/xnadalib-2021 --libdir lib -Dyelp_manual=false 
>>> -Dtests=false --wrap-mode=nofallback /usr/local/src-2021/gtk-doc-1.33.2
>>> The Meson build system
>>> Version: 0.60.3
>>> Source dir: /usr/local/src-2021/gtk-doc-1.33.2
>>> Build dir: /usr/local/src-2021/cache/jhbuild/build/gtk-doc-1.33.2
>>> Build type: native build
>>> Project name: gtk-doc
>>> Project version: 1.33.1
>>> C compiler for the host machine: 
>>> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc (clang 13.0.0 "Apple 
>>> clang version 13.0.0 (clang-1300.0.29.3)")
>>> C linker for the host machine: 
>>> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc ld64 711
>>> Host machine cpu family: x86_64
>>> Host machine cpu: x86_64
>>> Program python3 found: YES (/usr/local/xnadalib-2021/bin/python3)
>>> 
>>> ../../../../gtk-doc-1.33.2/meson.build:45:4: ERROR: Problem encountered: 
>>> Required Python3 module 'pygments' not found
>>> 
>>> The build used python3 installed in prefix (/usr/local/xnadalib-2021) which 
>>> is expected, isn't it?
>>> 
>>> Do I need to install pygments in addition ?
>>> If so how do to it? with jhbuild?
>>> Thanks for help.
>> 
>> If you use pygments instead of python3 in your modules list it will pull in 
>> python3 and build pygments for you. If you're already into the build it's 
>> easier to just drop to a shell and say 'pip3 install pygments'.
> 
> 
> Thanks John, I did the pip3 with success.

Hello John,

This time, i tried 'jhbuild build pygments'.
It works but pygments is installed in $prefix/lib/python3.10/site-packages.
That's odd if you install before Python3 which is version 3.9.
GTK-DOC is still puzzled.
Then in order to get pygments installed in $prefix/lib/python3.9/site-packages, 
I propose to change jhbuildrc as:

 if ('python3' in modules or 'meta-gtk-osx-python3' in modules or
-'pygments' in modules):
+'pygments' in modules
+or 'python3' in sys.argv or 'meta-gtk-osx-python3' in sys.argv
+or 'pygments' in sys.argv):

What is your feedback?

Thanks, Pascal.
https://blady.pagesperso-orange.fr


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] gtk-osx-setup.sh minor error.

[John Ralls]

> On Jan 7, 2022, at 1:09 PM, Pascal  wrote:
> 
> Hello,
> 
> I've run a fresh install from gtk-osx-setup.sh and I've got this error:
> gtk-osx-setup.sh: line 235: test: -eq: unary operator expected
> 
> It seem's that there isn't any major impact on jhbuild process, is it?
> 

Dang, I thought I'd removed that. Yes, it's harmless. And now it's gone.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[Gabriele Greco via gtk-osx-users-list]

The warning you have are almost harmless, they said just that the MAIN
application is built with an OSX sdk older than the libraries it uses. This
can be a problem since the application will be able to run on macos 11 but
the library may use some macos12 only symbols.

I usually build with 10.10 MACOSX_DEPLOYMENT_TARGET env variable, both the
libraries (gtk, ffmpeg...) and the application.

Please note that the C target (so most GTK APIs) has an ABI that is almost
freezed, but if you use also C++ libraries (ie GTKmm) having libraries
compiled against a newer SDK than the application may be a problem.

On Mon, Jan 3, 2022 at 1:53 AM john  wrote:

>
>
> On Jan 2, 2022, at 3:23 AM, Pascal  wrote:
>
>
> Le 30 déc. 2021 à 19:31, John Ralls  a écrit :
>
> On Dec 30, 2021, at 10:21 AM, Pascal  wrote:
>
> Le 30 déc. 2021 à 17:57, Paul Emsley via gtk-osx-users-list <
> gtk-osx-users-list@gnome.org> a écrit :
>
> On 30/12/2021 16:13, Pascal wrote:
>
> Le 30 déc. 2021 à 14:43, Paul Emsley via gtk-osx-users-list <
> gtk-osx-users-list@gnome.org> a écrit :
>
> On 30/12/2021 11:29, Pascal wrote:
>
> Hello,
>
> My configuration is macOS 12, I just built:
>
> % jhbuild bootstrap-gtk-osx
> % jhbuild build python3
> % jhbuild build meta-gtk-osx-bootstrap
>
> When I build my program I got a lot of:
> ld: warning: dylib (/usr/local/xnadalib-2021/lib/libgtk-3.dylib) was built
> for newer macOS version (12.0) than being linked (11.0)
>
> It is not so clear.
> What is this actually meaning?
>
> This seems just to be a warning but my program shows some erroneous GTK
> executions.
>
> How to deal with it?
>
> NB : with GTK which was built when I was on macOS 11, I have no warning
> and no issue to build my program on macOS 12.
>
> Have you installed homebrew? If so, rename or remove it while compiling
> gtk-osx.
>
> No Paul, I haven't.
>
> OK, interesting. It seems that you do have something in /usr/local though
> - do you know what it is?
>
>
> I found only CLI tools like BBEdit or OSXFuse.
>
> I have MacPorts installed in /opt/local but not in PATH.
> Should I delete XDG_CACHE_HOME folder before building GTK?
>
>
> I don't know, sorry. My feeling is that you shouldn't need to do so.
>
>
> When looking in environnement variables in jhbuild shell, I found:
> [JH] % echo $MACOSX_DEPLOYMENT_TARGET
> 12
>
> Should I specify 11 in calling setup_sdk in jhbuildrc-custom?
>
> If so, I wonder: why the link message is issued as I have rebuilt all on
> macOS 12?
>
>
> The link message is saying that whatever you're trying to link was
> compiled with macosx-version-min=11.0 while libgtk-3.dylib was compiled
> with macosx-version-min=12.0. Did you perhaps forget to reconfigure your
> project after rebuilding everything else?
>
>
> Hello John,
>
> I aim to build the GTKAda bindings with the fixed version of GTK for macOS
> 12.
> I dig in my building configuration without success.
> In fact the issue is coming from my Ada compiler which is stuck to macOS
> 11, the internal compilation is done with -mmacosx-version-min=11.0.0.
>
> So I got:
> otool -l
> /usr/local/xnadalib-2021/lib/gtkada/gtkada.relocatable/gtkada/libgtkada.dylib
>  cmd LC_BUILD_VERSION
>  cmdsize 32
> platform 1
>minos 11.0
>  sdk 10.17
>
> Thus the warning.
>
> The test program is nevertheless running but fails with:
> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
> assertion failed (error == NULL): Failed to load
> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png:
> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
> Bail out!
> Gtk:ERROR:../../../../gtk+-3.24.30/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
> assertion failed (error == NULL): Failed to load
> /usr/local/xnadalib-2021/share/icons/Adwaita/24x24/status/image-missing.png:
> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>
> However the GTKAda source code is the same since I built it on macOS 11
> with success.
>
> Well now, should I specify setup_sdk(target="11") in jhbuildrc-custom and
> rebuild all GTK stuff?
>
>
> The gdk-pixbuf errors have to do with not being able to find its modules.
> That might be because you need to run gdk-pixbuf-query-loaders
> --update-cache (in a jhbuild shell of course!) or you need to set
> GDK_PIXBUF_MODULEDIR to point at where it is, see
> http://manpages.ubuntu.com/manpages/impish/man1/gdk-pixbuf-query-loaders.1.html
> .
>
> Regards,
> John Ralls
>
> ___
> gtk-osx-users-list mailing list
> gtk-osx-users-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
>


-- 
Bye,
 Gabry
___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Error during phase checkout of libjpeg: file hash is incorrect

[John Ralls]

> On Jan 5, 2022, at 11:45 PM, Richard Greene via gtk-osx-users-list 
>  wrote:
> 
> I am a noob, trying to build Gtk-OSX for the first time.  When I run this 
> command:
> jhbuild build meta-gtk-osx-bootstrap
> I get this error when it tries to checkout libjpeg:
> 
> *** Error during phase checkout of libjpeg: file hash is incorrect (expected 
> 6c434a3be59f8f62425b2e3c077e785c9ce30ee5874ea1c270e843f273ba71ee, got 
> 2303a6acfb6cc533e0e86e8a9d29f7e6079e118b9de3f96e07a71a11c082fa6a) *** [3/9]
> 
> It happens every time, so is presumably a problem with the expected hash of 
> the library itself, rather than a corruption during download.
> 
> How can I fix that?

If you've cloned the repository you can put the new hash in the module, then 
file a merge request on gitlab. Otherwise you can tell me and I'll fix it, 
which you and I just did.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[John Ralls]

> On Dec 30, 2021, at 10:21 AM, Pascal  wrote:
> 
>> 
>> Le 30 déc. 2021 à 17:57, Paul Emsley via gtk-osx-users-list 
>>  a écrit :
>> 
>> On 30/12/2021 16:13, Pascal wrote:
 Le 30 déc. 2021 à 14:43, Paul Emsley via gtk-osx-users-list 
  a écrit :
 
 On 30/12/2021 11:29, Pascal wrote:
> Hello,
> 
> My configuration is macOS 12, I just built:
> 
> % jhbuild bootstrap-gtk-osx
> % jhbuild build python3
> % jhbuild build meta-gtk-osx-bootstrap
> 
> When I build my program I got a lot of:
> ld: warning: dylib (/usr/local/xnadalib-2021/lib/libgtk-3.dylib) was 
> built for newer macOS version (12.0) than being linked (11.0)
> 
> It is not so clear.
> What is this actually meaning?
> 
> This seems just to be a warning but my program shows some erroneous GTK 
> executions.
> 
> How to deal with it?
> 
> NB : with GTK which was built when I was on macOS 11, I have no warning 
> and no issue to build my program on macOS 12.
> 
 Have you installed homebrew? If so, rename or remove it while compiling 
 gtk-osx.
>>> No Paul, I haven't.
>> OK, interesting. It seems that you do have something in /usr/local though - 
>> do you know what it is?
> 
> I found only CLI tools like BBEdit or OSXFuse.
> 
>>> I have MacPorts installed in /opt/local but not in PATH.
>>> Should I delete XDG_CACHE_HOME folder before building GTK?
>> 
>> I don't know, sorry. My feeling is that you shouldn't need to do so.
> 
> When looking in environnement variables in jhbuild shell, I found:
> [JH] % echo $MACOSX_DEPLOYMENT_TARGET 
> 12
> 
> Should I specify 11 in calling setup_sdk in jhbuildrc-custom?
> 
> If so, I wonder: why the link message is issued as I have rebuilt all on 
> macOS 12?

The link message is saying that whatever you're trying to link was compiled 
with macosx-version-min=11.0 while libgtk-3.dylib was compiled with 
macosx-version-min=12.0. Did you perhaps forget to reconfigure your project 
after rebuilding everything else?

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[Pascal]

> Le 30 déc. 2021 à 17:57, Paul Emsley via gtk-osx-users-list 
>  a écrit :
> 
> On 30/12/2021 16:13, Pascal wrote:
>>> Le 30 déc. 2021 à 14:43, Paul Emsley via gtk-osx-users-list 
>>>  a écrit :
>>> 
>>> On 30/12/2021 11:29, Pascal wrote:
 Hello,
 
 My configuration is macOS 12, I just built:
 
 % jhbuild bootstrap-gtk-osx
 % jhbuild build python3
 % jhbuild build meta-gtk-osx-bootstrap
 
 When I build my program I got a lot of:
 ld: warning: dylib (/usr/local/xnadalib-2021/lib/libgtk-3.dylib) was built 
 for newer macOS version (12.0) than being linked (11.0)
 
 It is not so clear.
 What is this actually meaning?
 
 This seems just to be a warning but my program shows some erroneous GTK 
 executions.
 
 How to deal with it?
 
 NB : with GTK which was built when I was on macOS 11, I have no warning 
 and no issue to build my program on macOS 12.
 
>>> Have you installed homebrew? If so, rename or remove it while compiling 
>>> gtk-osx.
>> No Paul, I haven't.
> OK, interesting. It seems that you do have something in /usr/local though - 
> do you know what it is?

I found only CLI tools like BBEdit or OSXFuse.

>> I have MacPorts installed in /opt/local but not in PATH.
>> Should I delete XDG_CACHE_HOME folder before building GTK?
> 
> I don't know, sorry. My feeling is that you shouldn't need to do so.

When looking in environnement variables in jhbuild shell, I found:
[JH] % echo $MACOSX_DEPLOYMENT_TARGET 
12

Should I specify 11 in calling setup_sdk in jhbuildrc-custom?

If so, I wonder: why the link message is issued as I have rebuilt all on macOS 
12?

Thanks, Pascal.
https://blady.pagesperso-orange.fr 


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[Paul Emsley via gtk-osx-users-list]

On 30/12/2021 16:13, Pascal wrote:

Le 30 déc. 2021 à 14:43, Paul Emsley via gtk-osx-users-list 
 a écrit :

On 30/12/2021 11:29, Pascal wrote:

Hello,

My configuration is macOS 12, I just built:

% jhbuild bootstrap-gtk-osx
% jhbuild build python3
% jhbuild build meta-gtk-osx-bootstrap

When I build my program I got a lot of:
ld: warning: dylib (/usr/local/xnadalib-2021/lib/libgtk-3.dylib) was built for 
newer macOS version (12.0) than being linked (11.0)

It is not so clear.
What is this actually meaning?

This seems just to be a warning but my program shows some erroneous GTK 
executions.

How to deal with it?

NB : with GTK which was built when I was on macOS 11, I have no warning and no 
issue to build my program on macOS 12.


Have you installed homebrew? If so, rename or remove it while compiling gtk-osx.

No Paul, I haven't.
OK, interesting. It seems that you do have something in /usr/local 
though - do you know what it is?

I have MacPorts installed in /opt/local but not in PATH.
Should I delete XDG_CACHE_HOME folder before building GTK?


I don't know, sorry. My feeling is that you shouldn't need to do so.

Paul.



___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Newer macOS version (12.0) than being linked (11.0)

[Paul Emsley via gtk-osx-users-list]

On 30/12/2021 11:29, Pascal wrote:

Hello,

My configuration is macOS 12, I just built:

% jhbuild bootstrap-gtk-osx
% jhbuild build python3
% jhbuild build meta-gtk-osx-bootstrap

When I build my program I got a lot of:
ld: warning: dylib (/usr/local/xnadalib-2021/lib/libgtk-3.dylib) was built for 
newer macOS version (12.0) than being linked (11.0)

It is not so clear.
What is this actually meaning?

This seems just to be a warning but my program shows some erroneous GTK 
executions.

How to deal with it?

NB : with GTK which was built when I was on macOS 11, I have no warning and no 
issue to build my program on macOS 12.

Have you installed homebrew? If so, rename or remove it while compiling 
gtk-osx.


Paul.


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK-DOC Required Python3 module 'pygments' not found.

[Pascal]

> Le 28 déc. 2021 à 17:18, john  a écrit :
> 
>> On Dec 28, 2021, at 1:48 AM, Pascal  wrote:
>> 
>> Hello,
>> 
>> For this build, I needed Python3, so I did:
>> 
>> %  jhbuild bootstrap-gtk-osx
>> %  jhbuild build python3
>> %  jhbuild build meta-gtk-osx-bootstrap
>> ...
>> *** Configuring gtk-doc *** [8/9]
>> meson --prefix /usr/local/xnadalib-2021 --libdir lib -Dyelp_manual=false 
>> -Dtests=false --wrap-mode=nofallback /usr/local/src-2021/gtk-doc-1.33.2
>> The Meson build system
>> Version: 0.60.3
>> Source dir: /usr/local/src-2021/gtk-doc-1.33.2
>> Build dir: /usr/local/src-2021/cache/jhbuild/build/gtk-doc-1.33.2
>> Build type: native build
>> Project name: gtk-doc
>> Project version: 1.33.1
>> C compiler for the host machine: 
>> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc (clang 13.0.0 "Apple 
>> clang version 13.0.0 (clang-1300.0.29.3)")
>> C linker for the host machine: 
>> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc ld64 711
>> Host machine cpu family: x86_64
>> Host machine cpu: x86_64
>> Program python3 found: YES (/usr/local/xnadalib-2021/bin/python3)
>> 
>> ../../../../gtk-doc-1.33.2/meson.build:45:4: ERROR: Problem encountered: 
>> Required Python3 module 'pygments' not found
>> 
>> The build used python3 installed in prefix (/usr/local/xnadalib-2021) which 
>> is expected, isn't it?
>> 
>> Do I need to install pygments in addition ?
>> If so how do to it? with jhbuild?
>> Thanks for help.
> 
> If you use pygments instead of python3 in your modules list it will pull in 
> python3 and build pygments for you. If you're already into the build it's 
> easier to just drop to a shell and say 'pip3 install pygments'.


Thanks John, I did the pip3 with success.


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK-DOC Required Python3 module 'pygments' not found.

[john]

> On Dec 28, 2021, at 1:48 AM, Pascal  wrote:
> 
> Hello,
> 
> For this build, I needed Python3, so I did:
> 
> %  jhbuild bootstrap-gtk-osx
> %  jhbuild build python3
> %  jhbuild build meta-gtk-osx-bootstrap
> ...
> *** Configuring gtk-doc *** [8/9]
> meson --prefix /usr/local/xnadalib-2021 --libdir lib -Dyelp_manual=false 
> -Dtests=false --wrap-mode=nofallback /usr/local/src-2021/gtk-doc-1.33.2
> The Meson build system
> Version: 0.60.3
> Source dir: /usr/local/src-2021/gtk-doc-1.33.2
> Build dir: /usr/local/src-2021/cache/jhbuild/build/gtk-doc-1.33.2
> Build type: native build
> Project name: gtk-doc
> Project version: 1.33.1
> C compiler for the host machine: 
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc (clang 13.0.0 "Apple 
> clang version 13.0.0 (clang-1300.0.29.3)")
> C linker for the host machine: 
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc ld64 711
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Program python3 found: YES (/usr/local/xnadalib-2021/bin/python3)
> 
> ../../../../gtk-doc-1.33.2/meson.build:45:4: ERROR: Problem encountered: 
> Required Python3 module 'pygments' not found
> 
> The build used python3 installed in prefix (/usr/local/xnadalib-2021) which 
> is expected, isn't it?
> 
> Do I need to install pygments in addition ?
> If so how do to it? with jhbuild?
> Thanks for help.

If you use pygments instead of python3 in your modules list it will pull in 
python3 and build pygments for you. If you're already into the build it's 
easier to just drop to a shell and say 'pip3 install pygments'.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] No dependency for gobject-introspection when building pygobject3.

[john]

> On Dec 24, 2021, at 6:43 AM, Pascal  wrote:
> 
> Hello,
> 
> gobject-introspection seems not in pygobject3 dependency list:
> 
> % jhbuild build pygobject3   
> Loading .env environment variables...
> in jhbuildrc-custom
> *** Checking out zlib *** [1/20]
> *** Skipping zlib (package and dependencies not updated) *** [1/20]
> *** Checking out libpng *** [2/20]
> *** Skipping libpng (package and dependencies not updated) *** [2/20]
> *** Checking out libjpeg *** [3/20]
> *** Skipping libjpeg (package and dependencies not updated) *** [3/20]
> *** Checking out libtiff *** [4/20]
> *** Skipping libtiff (package and dependencies not updated) *** [4/20]
> *** Checking out libxml2 *** [5/20]
> *** Skipping libxml2 (package and dependencies not updated) *** [5/20]
> *** Checking out libxslt *** [6/20]
> *** Skipping libxslt (package and dependencies not updated) *** [6/20]
> *** Checking out itstool *** [7/20]
> *** Skipping itstool (package and dependencies not updated) *** [7/20]
> *** Checking out gtk-doc *** [8/20]
> *** Skipping gtk-doc (package and dependencies not updated) *** [8/20]
> *** Checking out pixman *** [10/20]
> *** Skipping pixman (package and dependencies not updated) *** [10/20]
> *** Checking out libffi *** [11/20]
> *** Skipping libffi (package and dependencies not updated) *** [11/20]
> *** Checking out glib *** [12/20]
> *** Skipping glib (package and dependencies not updated) *** [12/20]
> *** Checking out freetype-no-harfbuzz *** [13/20]
> *** Skipping freetype-no-harfbuzz (package and dependencies not updated) *** 
> [13/20]
> *** Checking out icu *** [14/20]
> *** Skipping icu (package and dependencies not updated) *** [14/20]
> *** Checking out harfbuzz-no-cairo *** [15/20]
> *** Skipping harfbuzz-no-cairo (package and dependencies not updated) *** 
> [15/20]
> *** Checking out freetype *** [16/20]
> *** Skipping freetype (package and dependencies not updated) *** [16/20]
> *** Checking out fontconfig *** [17/20]
> *** Skipping fontconfig (package and dependencies not updated) *** [17/20]
> *** Checking out cairo *** [18/20]
> *** Skipping cairo (package and dependencies not updated) *** [18/20]
> *** Checking out pycairo *** [19/20]
> *** Skipping pycairo (package and dependencies not updated) *** [19/20]
> *** Checking out pygobject3 *** [20/20]
> *** Configuring pygobject3 *** [20/20]
> meson --prefix /usr/local/xnadalib-2021 --libdir lib  --wrap-mode=nofallback 
> /usr/local/src-2021/pygobject-3.40.1
> The Meson build system
> Version: 0.59.0
> Source dir: /usr/local/src-2021/pygobject-3.40.1
> Build dir: /usr/local/src-2021/cache/jhbuild/build/pygobject-3.40.1
> Build type: native build
> Project name: pygobject
> Project version: 3.40.1
> C compiler for the host machine: 
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc (clang 13.0.0 "Apple 
> clang version 13.0.0 (clang-1300.0.29.3)")
> C linker for the host machine: 
> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc ld64 711
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Program python3 found: YES (/usr/local/xnadalib-2021/bin/python3)
> Found pkg-config: /usr/local/xnadalib-2021/bin/pkg-config (0.29.2)
> Dependency python found: YES (pkgconfig)
> Found CMake: /usr/local/xnadalib-2021/bin/cmake (3.20.0)
> Run-time dependency gobject-introspection-1.0 found: NO (tried pkgconfig, 
> framework and cmake)
> Not looking for a fallback subproject for the dependency 
> gobject-introspection-1.0 because:
> Use of fallback dependencies is disabled.
> 
> ../../../../pygobject-3.40.1/meson.build:29:0: ERROR: Dependency 
> 'gobject-introspection-1.0' is required but not found.
> 
> A full log can be found at 
> /usr/local/src-2021/cache/jhbuild/build/pygobject-3.40.1/meson-logs/meson-log.txt
> *** Error during phase configure of pygobject3: ## Error running 
> meson --prefix /usr/local/xnadalib-2021 --libdir lib  --wrap-mode=nofallback 
> /usr/local/src-2021/pygobject-3.40.1 *** [20/20]
> 
>  [1] Rerun phase configure
>  [2] Ignore error and continue to build
>  [3] Give up on module
>  [4] Start shell
>  [5] Reload configuration
>  [6] Go to phase "wipe directory and start over"
> choice: 3
> 
> Is it worth adding it in gtk-osx-python.modules?
> 
Pascal,

No, because pygobject has soft dependencies on meta-gtk-osx-gtk2 or 
meta-gtk-osx-gtk3. You're supposed to include one or the other in your module 
list.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] right mouse with trackpad

[john]

> On Nov 16, 2021, at 9:17 PM, Paul Emsley via gtk-osx-users-list 
>  wrote:
> 
> 
> On 17/11/2021 04:44, john wrote:
>> 
>>> On Nov 16, 2021, at 3:41 PM, Paul Emsley via gtk-osx-users-list 
>>>  wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> Is there a way to simulate right mouse click and drag using a trackpad? (I 
>>> want to do this in a GtkGLArea)
>>> 
>>> Thanks,
>>> 
>>> Paul.
>>> 
>>> (is this the right place to ask? If not, where should I go?)
>> Not really the right place, that's a basic how-do-I-use-my-mac question for 
>> your favorite web search engine. Google returns 478 thousand responses for 
>> "macos trackpad click-and-drag".
>> 
>> FWIW I usually click hard with my thumb and use my index finger to drag. 
>> Works for both selection and DnD.
>> 
> 
> Hi John,
> 
> Thanks for your prompt reply, but I am not sure that you answered the 
> question that I meant to ask.
> 
> There were extra conditions: GTK, right-mouse (and GtkGLArea). Reading 
> between the lines of your reply, it seems that it doesn't matter if the 
> application is a GTK application (is that right/what you think?)
> 
> I did google search before I posted, I read this (for example)
> 
> https://www.imore.com/how-activate-right-click-functionality-mac 
> 
> 
> but I couldn't get it to work. Which is why I asked here.

As I said, this isn't the place; I've provided a little more detail about that 
in another thread. The Gnome Discourse instance at discourse.gnome.org/ 
 would be better if this is really a Gtk-specific 
question, but that seems unlikely: Gtk programs get events from the operating 
system; the events you're asking about are right-down and mouse-motion. The 
trackpad gestures that generate those events have nothing to do with Gtk. To 
generate a right-down on a Mac trackpad hold the control key down and press 
hard on the trackpad so that it clicks. You can then drag with another finger 
to generate the mouse-motion events. This gesture is normally used to pop and 
navigate a context menu, firing the selected menu item when you release, i.e. 
generate a right-up.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK MACOS: jhbuild fails with ModuleNotFoundError: No module named 'pipenv'

[john]

> On Nov 17, 2021, at 8:33 AM, Paul Emsley via gtk-osx-users-list 
>  wrote:
> It might be best to install gtk before homebrew.
> 
> 


This list is about a set of tools for Gnome developers to integrate their 
projects on macs. Those tools don't work if one has Homebrew installed.

In spite of its name it is emphatically not for non-developers who happen to 
run Gtk-based apps on macOS.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK MACOS: jhbuild fails with ModuleNotFoundError: No module named 'pipenv'

[Paul Emsley via gtk-osx-users-list]

On 17/11/2021 16:09, Holger Rodriguez wrote:

Hi John,
my iMac died last week and I just got a new one.
I will follow up on this.
Holger


john 
10 November, 2021 at 17:55



You have two choices: You can either patch the pyenv build 
(gtk-osx-setup.sh created a repo clone in ~/Source/pyenv) to use the 
new OpenSSL tarball or you can wait for someone else to do so and for 
the pyenv maintainers to merge it.


Meanwhile, please answer my questions from yesterday.

Regards,
John Ralls


Holger Rodriguez 
10 November, 2021 at 17:36
now I get another error:

wsmac01:~ gtk$ ./gtk-osx-setup.sh
Cloning into '/Users/gtk/Source/pyenv'...
remote: Enumerating objects: 20634, done.
remote: Counting objects: 100% (1657/1657), done.
remote: Compressing objects: 100% (613/613), done.
remote: Total 20634 (delta 992), reused 1511 (delta 914), pack-reused 
18977

Receiving objects: 100% (20634/20634), 4.20 MiB | 5.02 MiB/s, done.
Resolving deltas: 100% (13869/13869), done.
Downloading openssl-1.1.1k.tar.gz...
-> https://www.openssl.org/source/openssl-1.1.1k.tar.gz
error: failed to download openssl-1.1.1k.tar.gz

BUILD FAILED (OS X 10.13.6 using python-build 2.2.0-12-g5b7c140f)

The problem is, that the file:
    openssl-1.1.1k.tar.gz
does not exist anymore, but they bumped it up to:
    openssl-1.1.1l.tar.gz

How do I resolve this?



___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
John Ralls 
9 November, 2021 at 22:41



Huh, didn't notice that. It will need to be fixed before building 
anything, but it shouldn't have anything to do with pipenv not working.


Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
Paul Emsley via gtk-osx-users-list 
9 November, 2021 at 22:31


On 09/11/2021 18:42, john wrote:


(This doesn't answer the question, just another data point, really)

From above

> python-build: use openssl@1.1 from homebrew
> python-build: use readline from homebrew

I wonder if that matters.

I recently did much the same as Holger Rodriguez. However, instead of 
changing the path, I deleted my /usr/local before I started. I then 
compiled and installed python 3.8. Then I started the build script. 
For me


$ grep PYTHONPATH jhbuild:

export PYTHONPATH="$HOME/.new_local/lib/python/site-packages:"

$ head -1 pipenv

#!/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

I wonder if that matter.

For me, the build script worked and gtk installed (yay).


Paul




___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
john 
9 November, 2021 at 19:42



Does the PYTHONPATH line in .new_local/bin/jhbuild correctly point to 
$HOME/.new_local/lib/python3.10/site-packages? Does that directory 
have a subdirectory pipenv containing __init__.py and cli/ among others?


Regards,
John Ralls



It might be best to install gtk before homebrew.


Paul.



___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK MACOS: jhbuild fails with ModuleNotFoundError: No module named 'pipenv'

[Holger Rodriguez]

Hi John,
my iMac died last week and I just got a new one.
I will follow up on this.
Holger


john 
10 November, 2021 at 17:55



You have two choices: You can either patch the pyenv build 
(gtk-osx-setup.sh created a repo clone in ~/Source/pyenv) to use the 
new OpenSSL tarball or you can wait for someone else to do so and for 
the pyenv maintainers to merge it.


Meanwhile, please answer my questions from yesterday.

Regards,
John Ralls


Holger Rodriguez 
10 November, 2021 at 17:36
now I get another error:

wsmac01:~ gtk$ ./gtk-osx-setup.sh
Cloning into '/Users/gtk/Source/pyenv'...
remote: Enumerating objects: 20634, done.
remote: Counting objects: 100% (1657/1657), done.
remote: Compressing objects: 100% (613/613), done.
remote: Total 20634 (delta 992), reused 1511 (delta 914), pack-reused 
18977

Receiving objects: 100% (20634/20634), 4.20 MiB | 5.02 MiB/s, done.
Resolving deltas: 100% (13869/13869), done.
Downloading openssl-1.1.1k.tar.gz...
-> https://www.openssl.org/source/openssl-1.1.1k.tar.gz
error: failed to download openssl-1.1.1k.tar.gz

BUILD FAILED (OS X 10.13.6 using python-build 2.2.0-12-g5b7c140f)

The problem is, that the file:
    openssl-1.1.1k.tar.gz
does not exist anymore, but they bumped it up to:
    openssl-1.1.1l.tar.gz

How do I resolve this?



___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
John Ralls 
9 November, 2021 at 22:41



Huh, didn't notice that. It will need to be fixed before building 
anything, but it shouldn't have anything to do with pipenv not working.


Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
Paul Emsley via gtk-osx-users-list 
9 November, 2021 at 22:31


On 09/11/2021 18:42, john wrote:


(This doesn't answer the question, just another data point, really)

From above

> python-build: use openssl@1.1 from homebrew
> python-build: use readline from homebrew

I wonder if that matters.

I recently did much the same as Holger Rodriguez. However, instead of 
changing the path, I deleted my /usr/local before I started. I then 
compiled and installed python 3.8. Then I started the build script. For me


$ grep PYTHONPATH jhbuild:

export PYTHONPATH="$HOME/.new_local/lib/python/site-packages:"

$ head -1 pipenv

#!/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

I wonder if that matter.

For me, the build script worked and gtk installed (yay).


Paul




___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
john 
9 November, 2021 at 19:42



Does the PYTHONPATH line in .new_local/bin/jhbuild correctly point to 
$HOME/.new_local/lib/python3.10/site-packages? Does that directory 
have a subdirectory pipenv containing __init__.py and cli/ among others?


Regards,
John Ralls



___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] right mouse with trackpad

[Paul Emsley via gtk-osx-users-list]

On 17/11/2021 04:44, john wrote:



On Nov 16, 2021, at 3:41 PM, Paul Emsley via gtk-osx-users-list 
 wrote:


Hi,

Is there a way to simulate right mouse click and drag using a trackpad? (I want 
to do this in a GtkGLArea)

Thanks,

Paul.

(is this the right place to ask? If not, where should I go?)

Not really the right place, that's a basic how-do-I-use-my-mac question for your favorite 
web search engine. Google returns 478 thousand responses for "macos trackpad 
click-and-drag".

FWIW I usually click hard with my thumb and use my index finger to drag. Works 
for both selection and DnD.



Hi John,

Thanks for your prompt reply, but I am not sure that you answered the 
question that I meant to ask.


There were extra conditions: GTK, right-mouse (and GtkGLArea). Reading 
between the lines of your reply, it seems that it doesn't matter if the 
application is a GTK application (is that right/what you think?)


I did google search before I posted, I read this (for example)

https://www.imore.com/how-activate-right-click-functionality-mac

but I couldn't get it to work. Which is why I asked here.

Regards,

Paul.


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK MACOS: jhbuild fails with ModuleNotFoundError: No module named 'pipenv'

[john]

> On Nov 10, 2021, at 8:36 AM, Holger Rodriguez  wrote:
> 
> now I get another error:
> 
> wsmac01:~ gtk$ ./gtk-osx-setup.sh 
> Cloning into '/Users/gtk/Source/pyenv'...
> remote: Enumerating objects: 20634, done.
> remote: Counting objects: 100% (1657/1657), done.
> remote: Compressing objects: 100% (613/613), done.
> remote: Total 20634 (delta 992), reused 1511 (delta 914), pack-reused 18977
> Receiving objects: 100% (20634/20634), 4.20 MiB | 5.02 MiB/s, done.
> Resolving deltas: 100% (13869/13869), done.
> Downloading openssl-1.1.1k.tar.gz...
> -> https://www.openssl.org/source/openssl-1.1.1k.tar.gz 
> 
> error: failed to download openssl-1.1.1k.tar.gz
> 
> BUILD FAILED (OS X 10.13.6 using python-build 2.2.0-12-g5b7c140f)
> 
> The problem is, that the file:
> openssl-1.1.1k.tar.gz
> does not exist anymore, but they bumped it up to:
> openssl-1.1.1l.tar.gz
> 
> How do I resolve this?

You have two choices: You can either patch the pyenv build (gtk-osx-setup.sh 
created a repo clone in ~/Source/pyenv) to use the new OpenSSL tarball or you 
can wait for someone else to do so and for the pyenv maintainers to merge it.

Meanwhile, please answer my questions from yesterday.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK MACOS: jhbuild fails with ModuleNotFoundError: No module named 'pipenv'

[John Ralls]

> On Nov 9, 2021, at 1:31 PM, Paul Emsley via gtk-osx-users-list 
>  wrote:
> 
> 
> (This doesn't answer the question, just another data point, really)
> 
> From above
> 
> > python-build: use openssl@1.1 from homebrew
> > python-build: use readline from homebrew
> 
> I wonder if that matters.

Huh, didn't notice that. It will need to be fixed before building anything, but 
it shouldn't have anything to do with pipenv not working.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] GTK MACOS: jhbuild fails with ModuleNotFoundError: No module named 'pipenv'

[Paul Emsley via gtk-osx-users-list]

On 09/11/2021 18:42, john wrote:




On Nov 9, 2021, at 8:56 AM, Holger Rodriguez  wrote:

Hi all,
I have:
macOS 10.13.6 (High Sierra)


==

I created a *new* user
gtk
as instructed and removed the
/usr/local/bin
fromthe PATH, as in this directory, homebrew has its tools.
So I ensured, that, as advised in:
https://wiki.gnome.org/Projects/GTK/OSX/Building
that no homebrew references exist.



I downloaded the script:
https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/gtk-osx-setup.sh
and ran it:
wsmac01:~ gtk$ ./gtk-osx-setup.sh

 - OUTPUT
Cloning into '/Users/gtk/Source/pyenv'...
remote: Enumerating objects: 20631, done.
remote: Counting objects: 100% (1654/1654), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 20631 (delta 991), reused 1467 (delta 883), pack-reused 
18977

Receiving objects: 100% (20631/20631), 4.20 MiB | 6.85 MiB/s, done.
Resolving deltas: 100% (13869/13869), done.
python-build: use openssl@1.1 from homebrew
python-build: use readline from homebrew
Downloading Python-3.10.0.tar.xz...
-> https://www.python.org/ftp/python/3.10.0/Python-3.10.0.tar.xz
Installing Python-3.10.0...
patching file aclocal.m4
patching file configure
Hunk #5 succeeded at 10537 (offset -15 lines).
python-build: use readline from homebrew
Installed Python-3.10.0 to 
/Users/gtk/.new_local/share/pyenv/versions/3.10.0


Requirement already satisfied: pip in 
./.new_local/share/pyenv/versions/3.10.0/lib/python3.10/site-packages 
(21.2.3)

Collecting pip
Downloading pip-21.3.1-py3-none-any.whl (1.7 MB)
|| 1.7 MB 2.5 MB/s
Installing collected packages: pip
WARNING: The scripts pip, pip3 and pip3.10 are installed in 
'/Users/gtk/.new_local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress 
this warning, use --no-warn-script-location.

Successfully installed pip-21.3.1
WARNING: You are using pip version 21.2.3; however, version 21.3.1 is 
available.
You should consider upgrading via the 
'/Users/gtk/.new_local/share/pyenv/versions/3.10.0/bin/python3.10 -m 
pip install --upgrade pip' command.

Collecting pipenv==2020.11.15
Downloading pipenv-2020.11.15-py2.py3-none-any.whl (3.9 MB)
|| 3.9 MB 2.6 MB/s
Collecting certifi
Downloading certifi-2021.10.8-py2.py3-none-any.whl (149 kB)
|| 149 kB 9.1 MB/s
Collecting virtualenv-clone>=0.2.5
Downloading virtualenv_clone-0.5.7-py3-none-any.whl (6.6 kB)
Collecting virtualenv
Downloading virtualenv-20.10.0-py2.py3-none-any.whl (5.6 MB)
|| 5.6 MB 8.0 MB/s
Requirement already satisfied: pip>=18.0 in 
./.new_local/lib/python3.10/site-packages (from pipenv==2020.11.15) 
(21.3.1)
Requirement already satisfied: setuptools>=36.2.1 in 
./.new_local/share/pyenv/versions/3.10.0/lib/python3.10/site-packages 
(from pipenv==2020.11.15) (57.4.0)

Collecting backports.entry-points-selectable>=1.0.4
Downloading 
backports.entry_points_selectable-1.1.1-py2.py3-none-any.whl (6.2 kB)

Collecting six<2,>=1.9.0
Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Collecting platformdirs<3,>=2
Downloading platformdirs-2.4.0-py3-none-any.whl (14 kB)
Collecting distlib<1,>=0.3.1
Downloading distlib-0.3.3-py2.py3-none-any.whl (496 kB)
|| 496 kB 7.6 MB/s
Collecting filelock<4,>=3.2
Downloading filelock-3.3.2-py3-none-any.whl (9.7 kB)
Installing collected packages: six, platformdirs, filelock, distlib, 
backports.entry-points-selectable, virtualenv-clone, virtualenv, 
certifi, pipenv
WARNING: The script virtualenv-clone is installed in 
'/Users/gtk/.new_local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress 
this warning, use --no-warn-script-location.
WARNING: The script virtualenv is installed in 
'/Users/gtk/.new_local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress 
this warning, use --no-warn-script-location.
WARNING: The scripts pipenv and pipenv-resolver are installed in 
'/Users/gtk/.new_local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress 
this warning, use --no-warn-script-location.
Successfully installed backports.entry-points-selectable-1.1.1 
certifi-2021.10.8 distlib-0.3.3 filelock-3.3.2 pipenv-2020.11.15 
platformdirs-2.4.0 six-1.16.0 virtualenv-20.10.0 virtualenv-clone-0.5.7

WARNING: Package(s) not found: typing
Cloning into '/Users/gtk/Source/jhbuild'...
fatal: unable to access 
'https://gitlab.gnome.org/GNOME/jhbuild.git/': SSL certificate 
problem: certificate has expired
./gtk-osx-setup.sh: line 114: cd: /Users/gtk/Source/jhbuild: No such 
file or directory

Archive: /Users/gtk/.new_local/ninja-mac.zip
inflating: /Users/gtk/.new_local/bin/ninja
info: downloading installer
info: profile set to 'minimal'
info: default host triple 

Re: [gtk-osx-users] GTK MACOS: jhbuild fails with ModuleNotFoundError: No module named 'pipenv'

[john]

> On Nov 9, 2021, at 8:56 AM, Holger Rodriguez  wrote:
> 
> Hi all,
> I have:
> macOS 10.13.6 (High Sierra)
> 
> 
> ==
> 
> I created a *new* user
> gtk
> as instructed and removed the
> /usr/local/bin
> from the PATH, as in this directory, homebrew has its tools.
> So I ensured, that, as advised in:
> https://wiki.gnome.org/Projects/GTK/OSX/Building 
> 
> that no homebrew references exist.
> 
> 
> 
> I downloaded the script:
> https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/gtk-osx-setup.sh 
> 
> and ran it:
> wsmac01:~ gtk$ ./gtk-osx-setup.sh
> 
>  - OUTPUT
> Cloning into '/Users/gtk/Source/pyenv'...
> remote: Enumerating objects: 20631, done.
> remote: Counting objects: 100% (1654/1654), done.
> remote: Compressing objects: 100% (641/641), done.
> remote: Total 20631 (delta 991), reused 1467 (delta 883), pack-reused 18977
> Receiving objects: 100% (20631/20631), 4.20 MiB | 6.85 MiB/s, done.
> Resolving deltas: 100% (13869/13869), done.
> python-build: use openssl@1.1  from homebrew
> python-build: use readline from homebrew
> Downloading Python-3.10.0.tar.xz...
> -> https://www.python.org/ftp/python/3.10.0/Python-3.10.0.tar.xz 
> 
> Installing Python-3.10.0...
> patching file aclocal.m4
> patching file configure
> Hunk #5 succeeded at 10537 (offset -15 lines).
> python-build: use readline from homebrew
> Installed Python-3.10.0 to /Users/gtk/.new_local/share/pyenv/versions/3.10.0
> 
> Requirement already satisfied: pip in 
> ./.new_local/share/pyenv/versions/3.10.0/lib/python3.10/site-packages (21.2.3)
> Collecting pip
>   Downloading pip-21.3.1-py3-none-any.whl (1.7 MB)
>  || 1.7 MB 2.5 MB/s 
> Installing collected packages: pip
>   WARNING: The scripts pip, pip3 and pip3.10 are installed in 
> '/Users/gtk/.new_local/bin' which is not on PATH.
>   Consider adding this directory to PATH or, if you prefer to suppress this 
> warning, use --no-warn-script-location.
> Successfully installed pip-21.3.1
> WARNING: You are using pip version 21.2.3; however, version 21.3.1 is 
> available.
> You should consider upgrading via the 
> '/Users/gtk/.new_local/share/pyenv/versions/3.10.0/bin/python3.10 -m pip 
> install --upgrade pip' command.
> Collecting pipenv==2020.11.15
>   Downloading pipenv-2020.11.15-py2.py3-none-any.whl (3.9 MB)
>  || 3.9 MB 2.6 MB/s
> Collecting certifi
>   Downloading certifi-2021.10.8-py2.py3-none-any.whl (149 kB)
>  || 149 kB 9.1 MB/s
> Collecting virtualenv-clone>=0.2.5
>   Downloading virtualenv_clone-0.5.7-py3-none-any.whl (6.6 kB)
> Collecting virtualenv
>   Downloading virtualenv-20.10.0-py2.py3-none-any.whl (5.6 MB)
>  || 5.6 MB 8.0 MB/s
> Requirement already satisfied: pip>=18.0 in 
> ./.new_local/lib/python3.10/site-packages (from pipenv==2020.11.15) (21.3.1)
> Requirement already satisfied: setuptools>=36.2.1 in 
> ./.new_local/share/pyenv/versions/3.10.0/lib/python3.10/site-packages (from 
> pipenv==2020.11.15) (57.4.0)
> Collecting backports.entry-points-selectable>=1.0.4
>   Downloading backports.entry_points_selectable-1.1.1-py2.py3-none-any.whl 
> (6.2 kB)
> Collecting six<2,>=1.9.0
>   Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
> Collecting platformdirs<3,>=2
>   Downloading platformdirs-2.4.0-py3-none-any.whl (14 kB)
> Collecting distlib<1,>=0.3.1
>   Downloading distlib-0.3.3-py2.py3-none-any.whl (496 kB)
>  || 496 kB 7.6 MB/s
> Collecting filelock<4,>=3.2
>   Downloading filelock-3.3.2-py3-none-any.whl (9.7 kB)
> Installing collected packages: six, platformdirs, filelock, distlib, 
> backports.entry-points-selectable, virtualenv-clone, virtualenv, certifi, 
> pipenv
>   WARNING: The script virtualenv-clone is installed in 
> '/Users/gtk/.new_local/bin' which is not on PATH.
>   Consider adding this directory to PATH or, if you prefer to suppress this 
> warning, use --no-warn-script-location.
>   WARNING: The script virtualenv is installed in '/Users/gtk/.new_local/bin' 
> which is not on PATH.
>   Consider adding this directory to PATH or, if you prefer to suppress this 
> warning, use --no-warn-script-location.
>   WARNING: The scripts pipenv and pipenv-resolver are installed in 
> '/Users/gtk/.new_local/bin' which is not on PATH.
>   Consider adding this directory to PATH or, if you prefer to suppress this 
> warning, use --no-warn-script-location.
> Successfully installed backports.entry-points-selectable-1.1.1 
> certifi-2021.10.8 distlib-0.3.3 filelock-3.3.2 pipenv-2020.11.15 
> platformdirs-2.4.0 six-1.16.0 

Re: problem to install Gtk2

[Emmanuele Bassi via gtk-perl-list]

On Thu, 4 Nov 2021 at 18:04, Jeremy Volkening via gtk-perl-list <
gtk-perl-list@gnome.org> wrote:

> > *** can not find package cairo >= 1.0.0
>
> You need to have the underlying C libraries installed in order to use the
> Perl wrappers. Here is a good place to start:
>
> https://www.gtk.org/docs/installations/windows
>
> Note that if you really want/need to use Gtk2 rather than Gtk3, you need
> to change the corresponding lines in those instructions. For example:
>
> pacman -S mingw-w64-x86_64-gtk3
>
> becomes
>
> pacman -S mingw-w64-x86_64-gtk2
>
> Once you have installed Gtk itself, you should have more luck with the
> CPAN install.
>

As a side note: GTK2 is EOL since December 2020, and nobody should write
new code using it.

GTK3 is in maintenance mode (no new API, no new features), and the current
stable release of GTK is GTK 4.4.

Sadly, there are no Perl bindings for GTK 4 as of yet, though you can
easily use Glib::Object::Introspection to load the introspection data, just
like you'd do with GTK 3.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: problem to install Gtk2

[Jeremy Volkening via gtk-perl-list]

> *** can not find package cairo >= 1.0.0

You need to have the underlying C libraries installed in order to use the Perl 
wrappers. Here is a good place to start:

https://www.gtk.org/docs/installations/windows

Note that if you really want/need to use Gtk2 rather than Gtk3, you need to 
change the corresponding lines in those instructions. For example:

pacman -S mingw-w64-x86_64-gtk3

becomes

pacman -S mingw-w64-x86_64-gtk2

Once you have installed Gtk itself, you should have more luck with the CPAN 
install.

Jeremy
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

RE: problem to install Gtk2

[Ed . via gtk-perl-list]

https://metacpan.org/pod/Cairo says:

“Cairo - Perl interface to the cairo 2d vector graphics library”

Do you have the cairo library installed?

From: leglaude via gtk-perl-list
Sent: 04 November 2021 15:34
To: gtk-perl-list@gnome.org
Subject: problem to install Gtk2

Hi all,
I work in windows 10 with Strawbery

but if I try install Gtk2
cpan install Gtk2

I have error.

Can you help me?

thanks!


C:\>cpan install Gtk2
Loading internal logger. Log::Log4perl recommended for better logging
CPAN: CPAN::SQLite loaded ok (v0.219)
Database was generated on Thu, 04 Nov 2021 13:06:54 GMT
Running install for module 'Gtk2'
CPAN: Digest::SHA loaded ok (v6.02)
CPAN: Compress::Zlib loaded ok (v2.096)
Checksum for C:\STRAWB~1\cpan\sources\authors\id\X\XA\XAOC\Gtk2-1.24993.tar.gz 
ok
CPAN: Archive::Tar loaded ok (v2.38)
CPAN: YAML::XS loaded ok (v0.82)
CPAN: CPAN::Meta::Requirements loaded ok (v2.140)
CPAN: Parse::CPAN::Meta loaded ok (v2.150010)
CPAN: CPAN::Meta loaded ok (v2.150010)
CPAN: Module::CoreList loaded ok (v5.20200717)
 Unsatisfied dependencies detected during 
 XAOC/Gtk2-1.24993.tar.gz 
Cairo [build_requires]
Glib [build_requires]
Pango [build_requires]
Running install for module 'Cairo'
Checksum for C:\STRAWB~1\cpan\sources\authors\id\X\XA\XAOC\Cairo-1.109.tar.gz ok
Configuring X/XA/XAOC/Cairo-1.109.tar.gz with Makefile.PL
 at Makefile.PL line 99.
*** can not find package cairo >= 1.0.0
*** check that it is properly installed and available in PKG_CONFIG_PATH
 at Makefile.PL line 99.
No 'Makefile' created  XAOC/Cairo-1.109.tar.gz
  C:\Strawberry\perl\bin\perl.exe Makefile.PL -- NOT OK
Stopping: 'install' failed for 'Cairo'.



___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Some strings corrupted when inserting into liststore model

[Grant McLean via gtk-perl-list]

On Tue, 2021-10-19 at 11:34 +1100, Daniel Kasak via gtk-perl-list
wrote:
> Right. I found a hack on https://perldoc.perl.org/perlunicode ( which
> you directed me to ) that appears to have fixed *this* particular
> issue ( though it's not clear what I've then broken as a result )
> Calling:
> 
> Encode::_utf8_on($_)
> 
>  ... for every value just prior to being pushed into the model
> appears to work. Yay :)

The operative word here is "appears".  This hack will work for most
characters but not all.

The general advice for working with encodings from Perl is that you
should:

 * decode bytes on input to give you strings in Perl's internal
   representation which supports multi-byte characters; and

 * encode strings to bytes in a particular encoding on output

These days the most common encoding you will encounter is UTF-8.
To do the relevant decoding of a UTF-8 file you might open it like
this:

open(my $fh, '<:utf8', $filename);

Or, if the string was not read from a file but was simply defined in
your script, you would tell Perl to decode the bytes of your script
from UTF-8 by including this pragma:

use utf8;

For output to a file you might use:

open(my $fh, '>:utf8', $filename);

Your experience seems to suggest that the Perl Gtk bindings will do the
right thing when presented with a string that has the internal "utf8"
flag set.  But if your string has non-ASCII characters but does not
already have that flag set then it seems the decoding step has been
missed.

Data that came from a DB connection rather than a file might need to be
decoded with something like:

$perl_string = Encode::decode_utf8($db_string);

However most of the DBD drivers allow you to set a flag so that this
happens automatically.

The reason messing with the utf8 flag on the Perl string appears to
work is that Perl's internal encoding is almost-but-not-quite UTF-8.
For historical reasons (and arguably as an memory optimisation)
sometimes Perl will encode some characters in the range 0x80-0xFF as a
single byte ("Latin-1" encoding) rather than the two bytes that UTF-8
would require.

For example chr(0x20AC) would return a Perl string which was
represented in memory using UTF-8 bytes. Whereas chr(0xE9) would return
a Perl string which was represented in memory using a single Latin-1
byte.  Simply setting the utf8 flag on the first string would do no
harm (since it's already set) but it would make a mess of the second
string because it's only one byte long and not a valid UTF-8 sequence.

If you really want to understand this stuff here's a link to a
conference talk I did on the subject:

https://www.youtube.com/watch?v=cgswnneFp-s

Regards
Grant

___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Some strings corrupted when inserting into liststore model

[Daniel Kasak via gtk-perl-list]

Right. I found a hack on https://perldoc.perl.org/perlunicode ( which
you directed me to ) that appears to have fixed *this* particular
issue ( though it's not clear what I've then broken as a result )
Calling:

Encode::_utf8_on($_)

 ... for every value just prior to being pushed into the model appears
to work. Yay :)

Thanks!

Dan

On Mon, Oct 18, 2021 at 11:12 PM Jeremy Volkening via gtk-perl-list
 wrote:
>
> On Mon, Oct 18, 2021 at 08:39:36PM +1100, Daniel Kasak via gtk-perl-list 
> wrote:
> > It's not really clear if there's something *else* I'm
> > supposed to do to these strings coming out of the DB or not?
>
> Typically you need to tell Perl to treat them as UTF-8. Without knowing 
> exactly how you're getting your strings into Perl, there are a number of ways 
> to do this (https://perldoc.perl.org/perlunicode). For instance, if you're 
> reading from a filehandle you can set its mode:
>
> binmode(\*STDIN, ':utf8');
>
> Or you can can specifically mark the string after it's imported:
>
> use Encode;
> $str = Encode::decode("UTF-8", $str);
>
> One of these might help with your issue.
>
> Jeremy
> ___
> gtk-perl-list mailing list
> gtk-perl-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-perl-list
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Some strings corrupted when inserting into liststore model

[Jeremy Volkening via gtk-perl-list]

On Mon, Oct 18, 2021 at 08:39:36PM +1100, Daniel Kasak via gtk-perl-list wrote:
> It's not really clear if there's something *else* I'm
> supposed to do to these strings coming out of the DB or not?

Typically you need to tell Perl to treat them as UTF-8. Without knowing exactly 
how you're getting your strings into Perl, there are a number of ways to do 
this (https://perldoc.perl.org/perlunicode). For instance, if you're reading 
from a filehandle you can set its mode:

binmode(\*STDIN, ':utf8');

Or you can can specifically mark the string after it's imported:

use Encode;
$str = Encode::decode("UTF-8", $str);

One of these might help with your issue.

Jeremy
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Some strings corrupted when inserting into liststore model

[Daniel Kasak via gtk-perl-list]

Hi Jeremy. Thanks for the response :)

> In the case of your example script, you need 'use utf8;' in the preamble. In 
> the case of your example script, you
> need 'use utf8;' in the preamble. This fixes handling of the hard-coded 
> unicode characters in the script -- it won't
> necessarily fix the issue with the strings coming from your database.

Interesting. Yeah I don't usually embed unicode in source - I'd
forgotten about that :)

>  Are you certain they are being stored in the database correctly?

Yeah actually they're coming from an execution plan, so they're not
"stored" as such in the database. Example:

+-+--+---+--++
| id  | estRows  | task  | access object|
operator info  |
+-+--+---+--++
| TableReader_7   | 6656.67  | root  |  |
data:Selection_6   |
| └─Selection_6   | 6656.67  | cop[tikv] |  |
ne(dett.ffa_client.city, "")   |
|   └─TableFullScan_5 | 1.00 | cop[tikv] | table:ffa_client |
keep order:false, stats:pseudo |
+-+--+---+--++
3 rows in set (0.010 sec)

It renders correctly in a console in the MySQL client. I can inspect
the values in a debugger and copy them out, and they render correctly
both inside the IDE, and in a text editor when I paste the values. I
was under the impression that Perl handled strings as kinda-utf8
internally. It's not really clear if there's something *else* I'm
supposed to do to these strings coming out of the DB or not? Anyway,
they totally look correct if I print() them or inspect them in an IDE.

Dan
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: Some strings corrupted when inserting into liststore model

[Jeremy Volkening via gtk-perl-list]

In the case of your example script, you need 'use utf8;' in the preamble. This 
fixes handling of the hard-coded unicode characters in the script -- it won't 
necessarily fix the issue with the strings coming from your database. Are you 
certain they are being stored in the database correctly?

Jeremy

On Mon, Oct 18, 2021 at 02:42:42PM +1100, Daniel Kasak via gtk-perl-list wrote:
> Hi all. I'm seeing some strings ( coming from a database ) corrupted
> when I insert into a liststore model. I've pasted a bare-bones script
> before which demonstrates the issue ( hard-coded string value in this
> case ). Any ideas what's happening and how to get the original string
> rendering? Interestingly, I can copy/paste directly into the
> treeview/cell and it handles data input this way.
> 
> ---
> 
> #!/usr/bin/perl
> 
> use strict;
> use warnings;
> 
> use Gtk3 '-init';
> use Glib 'TRUE', 'FALSE';
> 
> use Encode;
> 
> my $window = Gtk3::Window->new;
> $window->signal_connect( destroy => sub { Gtk3->main_quit } );
> $window->set_border_width(8);
> $window->set_default_size( 300, 250 );
> 
> my $box = Gtk3::Box->new( 'vertical', 8 );
> $box->set_homogeneous(FALSE);
> $window->add($box);
> 
> my $sw = Gtk3::ScrolledWindow->new( undef, undef );
> $sw->set_shadow_type('etched-in');
> $sw->set_policy( 'never', 'automatic' );
> $box->pack_start( $sw, TRUE, TRUE, 5 );
> 
> # Create TreeModel
> my $model = Gtk3::ListStore->new( 'Glib::String', );
> my $iter = $model->append();
> $model->set( $iter , 0 , "└─Selection_6" );
> 
> # Create a TreeView
> my $treeview = Gtk3::TreeView->new($model);
> $treeview->set_rules_hint(TRUE);
> $treeview->set_search_column(0);
> $sw->add($treeview);
> 
> # Add columns to TreeView
> add_columns($treeview);
> 
> $window->show_all;
> Gtk3->main();
> 
> sub add_columns {
> my $treeview = shift;
> my $model= $treeview->get_model();
> my $renderer = Gtk3::CellRendererText->new;
> # Column for description
> my $column = Gtk3::TreeViewColumn->new_with_attributes(
> 'Description', $renderer, text => 0 );
> $column->set_sort_column_id(0);
> $treeview->append_column($column);
> }
> ___
> gtk-perl-list mailing list
> gtk-perl-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-perl-list
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: [gtk-osx-users] Updating GTK3: ninja error.

[John Ralls]

> On Sep 27, 2021, at 12:29 PM, Pascal  wrote:
> 
>> 
>> Le 26 sept. 2021 à 18:32, john  a écrit :
>> 
>>> On Sep 26, 2021, at 1:41 AM, Pascal  wrote:
>>> 
>>> Hello,
>>> 
>>> I have got a ninja error when updating gtk3:
>>> 
>>> % jhbuild build meta-gtk-osx-gtk3
>>> ...
>>> *** Checking out gtk+-3.0 *** [28/33]
>>> curl --continue-at - -L 
>>> http://ftp.gnome.org/pub/GNOME/sources/gtk+/3.24/gtk+-3.24.30.tar.xz -o 
>>> /usr/local/src-2021/pkgs/gtk+-3.24.30.tar.xz
>>> % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>>   Dload  Upload   Total   SpentLeft  Speed
>>> 0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>>> 100   272  100   2720 0334  0 --:--:-- --:--:-- --:--:-- 
>>> 2385
>>> 0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 0
>>> 100 21.3M  100 21.3M0 0  2050k  0  0:00:10  0:00:10 --:--:-- 
>>> 2451k
>>> xzcat -d "/usr/local/src-2021/pkgs/gtk+-3.24.30.tar.xz" | tar xf -
>>> *** Applying patch Quartz-version-detection-for-macOS-12.patch *** [28/33]
>>> patch -p1 < 
>>> "/usr/local/src-2021/cache/jhbuild/Quartz-version-detection-for-macOS-12.patch"
>>> patching file gdk/quartz/gdkglobals-quartz.c
>>> patching file gdk/quartz/gdkquartz.h
>>> *** Configuring gtk+-3.0 *** [28/33]
>>> ...
>>> *** Building gtk+-3.0 *** [28/33]
>>> ninja  
>>> [0/1288] Generating gdkenumtypes.h with a custom command (wrapped by meson 
>>> to ca
>>> ...
>>> [1075/1288] Compiling C object testsuite/gtk/gtkmenu.p/gtkmenu.c.o
>>> ninja: build stopped: subcommand failed.
>>> *** Error during phase build of gtk+-3.0: ## Error running ninja   
>>> *** [28/33]
>>> 
>>> There isn't any straight forward explanation found in logs.
>>> Any idea?
>>> What could help to go further?
>>> 
>> 
>> The real error is in there somewhere, but it might be easier to find by 
>> dropping to the shell and running
>> ninja -j 1
>> so that you don't have to look through all of the build threads to find the 
>> one that errored out.
> 
> Thanks, it helps:
> 
> [JH] % ninja -j 1
> [2/385] Generating Gtk-3.0.gir with a custom command
> FAILED: gtk/Gtk-3.0.gir 
> /usr/local/xnadalib-2021/bin/g-ir-scanner --no-libtool --namespace=Gtk 
> --nsversion=3.0 --warn-all --output gtk/Gtk-3.0.gir --c-
> ...
> dyld: Symbol not found: _gtk_file_chooser_widget_accessible_get_type
>  Referenced from: 
> /usr/local/src-2021/cache/jhbuild/build/gtk+-3.24.30/tmp-introspectpilk3d9b/Gtk-3.0
>  Expected in: /usr/local/xnadalib-2021/lib/libgtk-3.0.dylib
> in 
> /usr/local/src-2021/cache/jhbuild/build/gtk+-3.24.30/tmp-introspectpilk3d9b/Gtk-3.0
> 
> It seems that it is looking for the already installed file libgtk-3.0.dylib?!
> 
> Thus, I uninstall GTK and go on with success:
> % jhbuild uninstall gtk+-3.0
> % jhbuild build meta-gtk-osx-gtk3
> 

Yup. And you found the right solution.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Updating GTK3: ninja error.

[Pascal]

> Le 26 sept. 2021 à 18:32, john  a écrit :
> 
>> On Sep 26, 2021, at 1:41 AM, Pascal  wrote:
>> 
>> Hello,
>> 
>> I have got a ninja error when updating gtk3:
>> 
>> % jhbuild build meta-gtk-osx-gtk3
>> ...
>> *** Checking out gtk+-3.0 *** [28/33]
>> curl --continue-at - -L 
>> http://ftp.gnome.org/pub/GNOME/sources/gtk+/3.24/gtk+-3.24.30.tar.xz -o 
>> /usr/local/src-2021/pkgs/gtk+-3.24.30.tar.xz
>> % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>>Dload  Upload   Total   SpentLeft  Speed
>> 0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>> 100   272  100   2720 0334  0 --:--:-- --:--:-- --:--:--  
>> 2385
>> 0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 0
>> 100 21.3M  100 21.3M0 0  2050k  0  0:00:10  0:00:10 --:--:-- 
>> 2451k
>> xzcat -d "/usr/local/src-2021/pkgs/gtk+-3.24.30.tar.xz" | tar xf -
>> *** Applying patch Quartz-version-detection-for-macOS-12.patch *** [28/33]
>> patch -p1 < 
>> "/usr/local/src-2021/cache/jhbuild/Quartz-version-detection-for-macOS-12.patch"
>> patching file gdk/quartz/gdkglobals-quartz.c
>> patching file gdk/quartz/gdkquartz.h
>> *** Configuring gtk+-3.0 *** [28/33]
>> ...
>> *** Building gtk+-3.0 *** [28/33]
>> ninja  
>> [0/1288] Generating gdkenumtypes.h with a custom command (wrapped by meson 
>> to ca
>> ...
>> [1075/1288] Compiling C object testsuite/gtk/gtkmenu.p/gtkmenu.c.o
>> ninja: build stopped: subcommand failed.
>> *** Error during phase build of gtk+-3.0: ## Error running ninja   
>> *** [28/33]
>> 
>> There isn't any straight forward explanation found in logs.
>> Any idea?
>> What could help to go further?
>> 
> 
> The real error is in there somewhere, but it might be easier to find by 
> dropping to the shell and running
>  ninja -j 1
> so that you don't have to look through all of the build threads to find the 
> one that errored out.

Thanks, it helps:

[JH] % ninja -j 1
[2/385] Generating Gtk-3.0.gir with a custom command
FAILED: gtk/Gtk-3.0.gir 
/usr/local/xnadalib-2021/bin/g-ir-scanner --no-libtool --namespace=Gtk 
--nsversion=3.0 --warn-all --output gtk/Gtk-3.0.gir --c-
...
dyld: Symbol not found: _gtk_file_chooser_widget_accessible_get_type
  Referenced from: 
/usr/local/src-2021/cache/jhbuild/build/gtk+-3.24.30/tmp-introspectpilk3d9b/Gtk-3.0
  Expected in: /usr/local/xnadalib-2021/lib/libgtk-3.0.dylib
 in 
/usr/local/src-2021/cache/jhbuild/build/gtk+-3.24.30/tmp-introspectpilk3d9b/Gtk-3.0

It seems that it is looking for the already installed file libgtk-3.0.dylib?!

Thus, I uninstall GTK and go on with success:
% jhbuild uninstall gtk+-3.0
% jhbuild build meta-gtk-osx-gtk3

Thanks again, Pascal.
https://blady.pagesperso-orange.fr


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] moduleset gtk-osx-gtkmm

[john]

> On Sep 26, 2021, at 2:03 PM, Jim Charlton  wrote:
> 
> HI JOhn:
> 
> I was trying to install gtk on Big Sur and I got gtk-osx-gtk3 installed OK 
> using jhbuild.  But I need the gtk-osx-gtkmm3 module  and it no longer seems 
> to be available in modulesets-stable.
> 
> Can you give me a hint on how to get gtkmm?
> 
> Many thanks
> 
> jim...

Please use the mailing list for support requests instead of mailing me 
directly. I've cc'd it for your convenience, you'll need to subscribe to post.

I removed the gtk-osx-gtkmm3 meta-module served no useful purpose. Just add 
gtkmm3 to your modules list and it will pull in the other dependencies.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Updating GTK3: ninja error.

[john]

> On Sep 26, 2021, at 1:41 AM, Pascal  wrote:
> 
> Hello,
> 
> I have got a ninja error when updating gtk3:
> 
> % jhbuild build meta-gtk-osx-gtk3
> ...
> *** Checking out gtk+-3.0 *** [28/33]
> curl --continue-at - -L 
> http://ftp.gnome.org/pub/GNOME/sources/gtk+/3.24/gtk+-3.24.30.tar.xz -o 
> /usr/local/src-2021/pkgs/gtk+-3.24.30.tar.xz
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
> 100   272  100   2720 0334  0 --:--:-- --:--:-- --:--:--  2385
>  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 0
> 100 21.3M  100 21.3M0 0  2050k  0  0:00:10  0:00:10 --:--:-- 2451k
> xzcat -d "/usr/local/src-2021/pkgs/gtk+-3.24.30.tar.xz" | tar xf -
> *** Applying patch Quartz-version-detection-for-macOS-12.patch *** [28/33]
> patch -p1 < 
> "/usr/local/src-2021/cache/jhbuild/Quartz-version-detection-for-macOS-12.patch"
> patching file gdk/quartz/gdkglobals-quartz.c
> patching file gdk/quartz/gdkquartz.h
> *** Configuring gtk+-3.0 *** [28/33]
> ...
> *** Building gtk+-3.0 *** [28/33]
> ninja  
> [0/1288] Generating gdkenumtypes.h with a custom command (wrapped by meson to 
> ca
> ...
> [1075/1288] Compiling C object testsuite/gtk/gtkmenu.p/gtkmenu.c.o
> ninja: build stopped: subcommand failed.
> *** Error during phase build of gtk+-3.0: ## Error running ninja   
> *** [28/33]
> 
> There isn't any straight forward explanation found in logs.
> Any idea?
> What could help to go further?
> 

The real error is in there somewhere, but it might be easier to find by 
dropping to the shell and running
  ninja -j 1
so that you don't have to look through all of the build threads to find the one 
that errored out.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Hello World with gtk

[John Ralls]

> On Aug 26, 2021, at 11:14 AM, David Price via gtk-osx-users-list 
>  wrote:
> 
> Hello
> 
> I finally managed to use jhbuild to install gtk.  Thanks to John Ralls for 
> helping me with the Rust problem.
> 
> Now I am trying to do the basic GTK Hello World in Rust from 
> "https://gtk-rs.org/gtk4-rs/stable/latest/docs/gtk4/; and getting the 
> following errors :
> 
> 
> error: failed to run custom build command for `glib-sys v0.14.0`
> 
> process didn't exit successfully: 
> `/Users/david/MyStuff/Rust/RustGTK/my-gtk-app/target/debug/build/glib-sys-a2f0018fbdfb445a/build-script-build`
>  (exit status: 1)
> 
> cargo:warning=Failed to run `"pkg-config" "--libs" "--cflags" "glib-2.0" 
> "glib-2.0 >= 2.66"`: No such file or directory (os error 2)
> 
> 
> Was I supposed to set up a PATH variable for gtk (which has glib-2.68.0)?  If 
> so, how?  Is it looking for glib in .cargo ?
> 
> Also, when I run just the build-script-build mentioned above, I get the 
> following warning :
> 
> cargo:warning=$CARGO_MANIFEST_DIR not set
> 
> 
> If it helps, this is my $PATH
> 
> /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/david/.cargo/bin:/Users/david/.new_local/bin
> 
> I am a newbie at all this, so any patient assistance would be appreciated
> 

Sorry, those questions are mostly about rust, a topic about which I know next 
to nothing. You'll have to go ask for help from the gtk-rs.org folks.

Note, however, that Gtk-osx builds a self-contained working environment that is 
by design not exported to the rest of the system and which imports only the 
macOS SDK from the system because its purpose is to create a build environment 
that can create stand-alone application bundles for drag-and-drop installation 
on other users' Macs. That's not to say that you can't use it for your rust 
development, but you'll have to start a jhbuild shell and run rust from in 
there. Since gtk-osx isn't intended to work with rust there may also be 
additional environment variables that you'll have to set by hand; again, the 
place to ask for help about that is on the gtk-rs.org support channels. You'll 
probably have an easier time if you remove gtk-osx and use Homebrew or MacPorts 
instead.

Regards,
John Ralls



 
___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Another jhbuild problem

[John Ralls]

Very good.

RUSTUP isn't RUSTUP_HOME, which needs to point to where the toolchains live, 
something I didn't really understand when I wrote that section of 
gtk-osx-setup.sh. I think I know how to fix it.

Regards,
John Ralls

> On Aug 26, 2021, at 4:21 AM, David Price  wrote:
> 
> 
> Hello
> 
> Success!
> 
> I changed the relevant line in jhbuild to read : export 
> RUSTUP_HOME="/Users/david/.rustup"
> 
> and jhbuild finished building successfully.
> 
> The "which rustup" command in my Terminal returns 
> /Users/david/.cargo/bin/rustup
> 
> whereas I changed jhbuild to look for the .rustup directory, not the .cargo 
> one.
> 
> I noticed the gtk-osx-setup.sh also uses RUSTUP='which rustup' so perhaps it 
> is using the .cargo directory as well.
> 
> Thank you for your help, John.
> 
> David
> 
> 
> 
> On 2021-08-25 11:05 p.m., John Ralls wrote:
>> No, I recommend figuring out why the RUSTUP_HOME environment variable in 
>> ~/.new_local/bin/jhbuild isn't finding your rust installation and fixing it 
>> so that it does. If you can also figure out how to get gtk-osx-setup.sh to 
>> configure jhbuild correctly in the first place I'll gladly apply it.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>>> On Aug 25, 2021, at 1:37 PM, David Price  wrote:
>>> 
>>> 
>>> Hi
>>> 
>>> I already have Rust installed (~/.rustup) and have been using it for a 
>>> while. Do you recommend uninstalling it, then re-running jhbuild?
>>> 
>>> David
>>> 
>>> 
>>> 
>>> On 2021-08-25 4:24 p.m., John Ralls wrote:
>>>>> On Aug 25, 2021, at 12:28 PM, David Price via gtk-osx-users-list 
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>> Hello again. Sorry to bother you again but I have another problem, this 
>>>>> time in 31/33 librsvg.
>>>>> 
>>>>> I tried rerunning the phase build but it still failed.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> *** Building librsvg *** [31/33]
>>>>> make -j 5
>>>>> make  all-recursive
>>>>> make[1]: Entering directory 
>>>>> '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>>>>> Making all in .
>>>>> make[2]: Entering directory 
>>>>> '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>>>>>   CC   _rsvg_dummy.lo
>>>>> cd /Users/david/gtk/source/librsvg-2.51.0 && \
>>>>> PKG_CONFIG_ALLOW_CROSS=1\
>>>>> PKG_CONFIG='/Users/david/gtk/inst/bin/pkg-config' \
>>>>> CARGO_TARGET_DIR=/Users/david/.cache/jhbuild/build/librsvg-2.51.0/target  
>>>>>\
>>>>> cargo --locked build   --release --bin rsvg-convert
>>>>> error: no override and no default toolchain set
>>>>> make[2]: *** [Makefile:1599: 
>>>>> /Users/david/.cache/jhbuild/build/librsvg-2.51.0/target/release/rsvg-convert]
>>>>>  Error 1
>>>>> make[2]: *** Waiting for unfinished jobs
>>>>> make[2]: Leaving directory 
>>>>> '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>>>>> make[1]: *** [Makefile:1105: all-recursive] Error 1
>>>>> make[1]: Leaving directory 
>>>>> '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>>>>> make: *** [Makefile:738: all] Error 2
>>>>> *** Error during phase build of librsvg: ## Error running make -j 
>>>>> 5  *** [31/33]
>>>>> 
>>>>>   [1] Rerun phase build
>>>>>   [2] Ignore error and continue to install
>>>>>   [3] Give up on module
>>>>>   [4] Start shell
>>>>>   [5] Reload configuration
>>>>>   [6] Go to phase "wipe directory and start over"
>>>>>   [7] Go to phase "configure"
>>>>>   [8] Go to phase "clean"
>>>>>   [9] Go to phase "distclean"
>>>>> choice:
>>>> Rust can't find its toolchain. It would normally look in $RUSTUP_HOME; in 
>>>> a clean macOS that's set in ~/.new_local/bin/jhbuild to ~/.new_local and 
>>>> the toolchains should be in ~/.new_local/toolchains. In the unlikely event 
>>>> that you already had rust installed gtk-osx-setup.sh would have tried to 
>>>> use the already-installed one instead.
>>>> 
>>>> Regards,
>>>> John Ralls
>>>> 

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Another jhbuild problem

[David Price via gtk-osx-users-list]

Hello

Success!

I changed the relevant line in jhbuild to read : export 
RUSTUP_HOME="/Users/david/.rustup"


and jhbuild finished building successfully.

The "which rustup" command in my Terminal returns 
/Users/david/.cargo/bin/rustup


whereas I changed jhbuild to look for the .rustup directory, not the 
.cargo one.


I noticed the gtk-osx-setup.sh also uses RUSTUP='which rustup' so 
perhaps it is using the .cargo directory as well.


Thank you for your help, John.

    David



On 2021-08-25 11:05 p.m., John Ralls wrote:

No, I recommend figuring out why the RUSTUP_HOME environment variable in 
~/.new_local/bin/jhbuild isn't finding your rust installation and fixing it so 
that it does. If you can also figure out how to get gtk-osx-setup.sh to 
configure jhbuild correctly in the first place I'll gladly apply it.

Regards,
John Ralls



On Aug 25, 2021, at 1:37 PM, David Price  wrote:


Hi

I already have Rust installed (~/.rustup) and have been using it for a while. 
Do you recommend uninstalling it, then re-running jhbuild?

 David



On 2021-08-25 4:24 p.m., John Ralls wrote:

On Aug 25, 2021, at 12:28 PM, David Price via gtk-osx-users-list 
 wrote:


Hello again. Sorry to bother you again but I have another problem, this time in 
31/33 librsvg.

I tried rerunning the phase build but it still failed.




*** Building librsvg *** [31/33]
make -j 5
make  all-recursive
make[1]: Entering directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
Making all in .
make[2]: Entering directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
   CC   _rsvg_dummy.lo
cd /Users/david/gtk/source/librsvg-2.51.0 && \
PKG_CONFIG_ALLOW_CROSS=1\
PKG_CONFIG='/Users/david/gtk/inst/bin/pkg-config' \
CARGO_TARGET_DIR=/Users/david/.cache/jhbuild/build/librsvg-2.51.0/target
 \
cargo --locked build   --release --bin rsvg-convert
error: no override and no default toolchain set
make[2]: *** [Makefile:1599: 
/Users/david/.cache/jhbuild/build/librsvg-2.51.0/target/release/rsvg-convert] 
Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
make[1]: *** [Makefile:1105: all-recursive] Error 1
make[1]: Leaving directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
make: *** [Makefile:738: all] Error 2
*** Error during phase build of librsvg: ## Error running make -j 5  
*** [31/33]

   [1] Rerun phase build
   [2] Ignore error and continue to install
   [3] Give up on module
   [4] Start shell
   [5] Reload configuration
   [6] Go to phase "wipe directory and start over"
   [7] Go to phase "configure"
   [8] Go to phase "clean"
   [9] Go to phase "distclean"
choice:

Rust can't find its toolchain. It would normally look in $RUSTUP_HOME; in a 
clean macOS that's set in ~/.new_local/bin/jhbuild to ~/.new_local and the 
toolchains should be in ~/.new_local/toolchains. In the unlikely event that you 
already had rust installed gtk-osx-setup.sh would have tried to use the 
already-installed one instead.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Another jhbuild problem

[John Ralls]

No, I recommend figuring out why the RUSTUP_HOME environment variable in 
~/.new_local/bin/jhbuild isn't finding your rust installation and fixing it so 
that it does. If you can also figure out how to get gtk-osx-setup.sh to 
configure jhbuild correctly in the first place I'll gladly apply it.

Regards,
John Ralls


> On Aug 25, 2021, at 1:37 PM, David Price  wrote:
> 
> 
> Hi
> 
> I already have Rust installed (~/.rustup) and have been using it for a while. 
> Do you recommend uninstalling it, then re-running jhbuild?
> 
> David
> 
> 
> 
> On 2021-08-25 4:24 p.m., John Ralls wrote:
>> 
>>> On Aug 25, 2021, at 12:28 PM, David Price via gtk-osx-users-list 
>>>  wrote:
>>> 
>>> 
>>> Hello again. Sorry to bother you again but I have another problem, this 
>>> time in 31/33 librsvg.
>>> 
>>> I tried rerunning the phase build but it still failed.
>>> 
>>> 
>>> 
>>> 
>>> *** Building librsvg *** [31/33]
>>> make -j 5
>>> make  all-recursive
>>> make[1]: Entering directory 
>>> '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>>> Making all in .
>>> make[2]: Entering directory 
>>> '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>>>   CC   _rsvg_dummy.lo
>>> cd /Users/david/gtk/source/librsvg-2.51.0 && \
>>> PKG_CONFIG_ALLOW_CROSS=1\
>>> PKG_CONFIG='/Users/david/gtk/inst/bin/pkg-config' \
>>> CARGO_TARGET_DIR=/Users/david/.cache/jhbuild/build/librsvg-2.51.0/target
>>>  \
>>> cargo --locked build   --release --bin rsvg-convert
>>> error: no override and no default toolchain set
>>> make[2]: *** [Makefile:1599: 
>>> /Users/david/.cache/jhbuild/build/librsvg-2.51.0/target/release/rsvg-convert]
>>>  Error 1
>>> make[2]: *** Waiting for unfinished jobs
>>> make[2]: Leaving directory 
>>> '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>>> make[1]: *** [Makefile:1105: all-recursive] Error 1
>>> make[1]: Leaving directory 
>>> '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>>> make: *** [Makefile:738: all] Error 2
>>> *** Error during phase build of librsvg: ## Error running make -j 5 
>>>  *** [31/33]
>>> 
>>>   [1] Rerun phase build
>>>   [2] Ignore error and continue to install
>>>   [3] Give up on module
>>>   [4] Start shell
>>>   [5] Reload configuration
>>>   [6] Go to phase "wipe directory and start over"
>>>   [7] Go to phase "configure"
>>>   [8] Go to phase "clean"
>>>   [9] Go to phase "distclean"
>>> choice:
>> Rust can't find its toolchain. It would normally look in $RUSTUP_HOME; in a 
>> clean macOS that's set in ~/.new_local/bin/jhbuild to ~/.new_local and the 
>> toolchains should be in ~/.new_local/toolchains. In the unlikely event that 
>> you already had rust installed gtk-osx-setup.sh would have tried to use the 
>> already-installed one instead.
>> 
>> Regards,
>> John Ralls
>> 

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Another jhbuild problem

[David Price via gtk-osx-users-list]

Hi

I already have Rust installed (~/.rustup) and have been using it for a 
while. Do you recommend uninstalling it, then re-running jhbuild?


    David



On 2021-08-25 4:24 p.m., John Ralls wrote:



On Aug 25, 2021, at 12:28 PM, David Price via gtk-osx-users-list 
 wrote:


Hello again. Sorry to bother you again but I have another problem, this time in 
31/33 librsvg.

I tried rerunning the phase build but it still failed.




*** Building librsvg *** [31/33]
make -j 5
make  all-recursive
make[1]: Entering directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
Making all in .
make[2]: Entering directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
   CC   _rsvg_dummy.lo
cd /Users/david/gtk/source/librsvg-2.51.0 && \
PKG_CONFIG_ALLOW_CROSS=1\
PKG_CONFIG='/Users/david/gtk/inst/bin/pkg-config' \
CARGO_TARGET_DIR=/Users/david/.cache/jhbuild/build/librsvg-2.51.0/target
 \
cargo --locked build   --release --bin rsvg-convert
error: no override and no default toolchain set
make[2]: *** [Makefile:1599: 
/Users/david/.cache/jhbuild/build/librsvg-2.51.0/target/release/rsvg-convert] 
Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
make[1]: *** [Makefile:1105: all-recursive] Error 1
make[1]: Leaving directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
make: *** [Makefile:738: all] Error 2
*** Error during phase build of librsvg: ## Error running make -j 5  
*** [31/33]

   [1] Rerun phase build
   [2] Ignore error and continue to install
   [3] Give up on module
   [4] Start shell
   [5] Reload configuration
   [6] Go to phase "wipe directory and start over"
   [7] Go to phase "configure"
   [8] Go to phase "clean"
   [9] Go to phase "distclean"
choice:

Rust can't find its toolchain. It would normally look in $RUSTUP_HOME; in a 
clean macOS that's set in ~/.new_local/bin/jhbuild to ~/.new_local and the 
toolchains should be in ~/.new_local/toolchains. In the unlikely event that you 
already had rust installed gtk-osx-setup.sh would have tried to use the 
already-installed one instead.

Regards,
John Ralls


___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Re: [gtk-osx-users] Another jhbuild problem

[John Ralls]

> On Aug 25, 2021, at 12:28 PM, David Price via gtk-osx-users-list 
>  wrote:
> 
> 
> Hello again. Sorry to bother you again but I have another problem, this time 
> in 31/33 librsvg.
> 
> I tried rerunning the phase build but it still failed.
> 
> 
> 
> 
> *** Building librsvg *** [31/33]
> make -j 5
> make  all-recursive
> make[1]: Entering directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
> Making all in .
> make[2]: Entering directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
>   CC   _rsvg_dummy.lo
> cd /Users/david/gtk/source/librsvg-2.51.0 && \
> PKG_CONFIG_ALLOW_CROSS=1\
> PKG_CONFIG='/Users/david/gtk/inst/bin/pkg-config' \
> CARGO_TARGET_DIR=/Users/david/.cache/jhbuild/build/librsvg-2.51.0/target  
>\
> cargo --locked build   --release --bin rsvg-convert
> error: no override and no default toolchain set
> make[2]: *** [Makefile:1599: 
> /Users/david/.cache/jhbuild/build/librsvg-2.51.0/target/release/rsvg-convert] 
> Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: Leaving directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
> make[1]: *** [Makefile:1105: all-recursive] Error 1
> make[1]: Leaving directory '/Users/david/.cache/jhbuild/build/librsvg-2.51.0'
> make: *** [Makefile:738: all] Error 2
> *** Error during phase build of librsvg: ## Error running make -j 5  
> *** [31/33]
> 
>   [1] Rerun phase build
>   [2] Ignore error and continue to install
>   [3] Give up on module
>   [4] Start shell
>   [5] Reload configuration
>   [6] Go to phase "wipe directory and start over"
>   [7] Go to phase "configure"
>   [8] Go to phase "clean"
>   [9] Go to phase "distclean"
> choice:

Rust can't find its toolchain. It would normally look in $RUSTUP_HOME; in a 
clean macOS that's set in ~/.new_local/bin/jhbuild to ~/.new_local and the 
toolchains should be in ~/.new_local/toolchains. In the unlikely event that you 
already had rust installed gtk-osx-setup.sh would have tried to use the 
already-installed one instead.

Regards,
John Ralls

___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list