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

Gnome 44 series release deadlines for Gtk-Perl

[Brian Manning via gtk-perl-list]

Hello everybody,

This will probably be the last release deadline announcement on the
GNOME mailing lists, as they will be retired at the end of this
month[1].  I will also cross-post this announcement in the GNOME
Discourse server, tagged with #perl.  You should be able to view it,
along with any new release announcements, using this URL:

https://discourse.gnome.org/tag/perl

You can find this announcement cross-posted to GNOME Discourse here:

https://discourse.gnome.org/t/gnome-44-series-release-deadlines-for-gtk-perl/11813

This is a single release deadline announcement that will cover the
Gnome version 44 release cycle, from now until April 2023.

Based on the Gnome 44 release calendar [2], I am setting the deadlines
for code submissions for Gtk-Perl modules as follows:

- December 3rd, 2022
- January 8th, 2023
- February 12th, 2023
- March 19th, 2023
- April 23rd, 2023

On all of the above days, the deadline for code submission will be at 00:01 UTC.

Please have all code submissions into the Gtk-Perl maintainers before
the above deadline(s); please allow time for the maintainers to audit
and test code submissions.

If you have your favorite RT ticket[3][4] or an issue in a given
module's Gnome GitLab repo that you would like someone to take a look
at, don't be afraid to bring it up for discussion here on the mailing
list.

Once a deadline date arrives, I will begin packaging any new code in
the Gtk-Perl git repos.  After packaging, I will distribute tarballs
to CPAN and Sourceforge, and post the release announcements, usually
within a few days of the release date.

If you have any questions about the above, please ask.

Thanks,

Brian

[1] https://mail.gnome.org/archives/gtk-perl-list/2022-October/msg0.html
[2] https://wiki.gnome.org/FortyFour
[3] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=XAOC
[4] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=TSCH
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

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

[Andrea Veri]

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
___
gtk-osx-devel-list mailing list
gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list

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

[Andrea Veri]

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
___
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list

Announcement: this mailing list will be retired by the end of Oct 2022

[Andrea Veri]

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
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-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

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

[jralls]

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

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

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

[Pascal]

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?

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] 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

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

[Turritopsis Dohrnii Teo En Ming via gtk-osx-users-list]

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.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
21 July 2022 Thursday
Blogs:
https://tdtemcerts.blogspot.com
https://tdtemcerts.wordpress.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] 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

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 

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' 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 

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

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 

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 
> 
> 
> 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 

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

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. Same problem. Maybe 
> this is your user’s first experience with Retina 

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 
>> 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 

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.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 

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 
>> 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 

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'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 

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,
>>> 
>>> 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 

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 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

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

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

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

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?

Best regards,
  Miroslav
___
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

Release deadlines for Gtk-Perl modules for June - October 2022

[Brian Manning via gtk-perl-list]

Hi everybody,

This is a single release deadline announcement that will cover the
rest of the Gnome version 43 release cycle, from now until October
2022.

Based on the Gnome 43 release calendar [1], I am setting the deadlines
for code submissions for Gtk-Perl modules as follows:

June: Saturday, June 18th, 2022
July: Saturday, July 2nd, 2022
August: Saturday, August 6th, 2022
September: Saturday, September 17th, 2022
October: Saturday, October 22nd, 2022

On all of the above days, the deadline for code submission will be at 00:01 UTC.

Please have all code submissions into the Gtk-Perl maintainers before
the above deadline(s); please allow time for the maintainers to audit
and test code submissions.

If you have your favorite RT ticket[2][3] or an issue in a given
module's Gnome GitLab repo that you would like someone to take a look
at, don't be afraid to bring it up for discussion here on the mailing
list.

Once a deadline date arrives, I will begin packaging any new code in
the Gtk-Perl git repos.  After packaging, I will distribute tarballs
to CPAN and Sourceforge, and post the release announcements, usually
within a few days of the release date.

If you have any questions about the above, please ask.

Thanks,

Brian

[1] https://wiki.gnome.org/FortyThree
[2] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=XAOC
[3] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=TSCH
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Next release deadline: May 28th, 2022 at 00:01 UTC

[Brian Manning via gtk-perl-list]

Hi everybody,

Based on the Gnome 43 release calendar [1], I am setting the deadline
for code submissions for the next release of Gtk-Perl modules to be
May 28th, 2022, at 00:01 UTC.

Please have all code submissions into the Gtk-Perl maintainers before
the above deadline; please allow time for the maintainers to audit and
test code submissions.  If you have your favorite RT ticket[2][3] or
an issue in a given module's Gnome GitLab repo that you would like
someone to take a look at, don't be afraid to bring it up for
discussion here on the mailing list.

Once the above deadline date arrives, I will begin packaging any new
code in the Gtk-Perl git repos.  After packaging, I will distribute
tarballs to CPAN and Sourceforge, and post the release announcements,
usually within a few days of the release date.

If you have any questions about the above, please ask.

Heads up for June, the release deadline will be June 18th, 2022, at 00:01UTC.

Thanks,

Brian

[1] https://wiki.gnome.org/FortyThree
[2] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=XAOC
[3] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=TSCH
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

[gtk-osx-users] Building GTK 2 on apple silicon

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

I'm trying to build gtk+2 on apple silicon but I have a small problem in
the bootstrap stage:

The itstool download site seems broken (401 on download) and I cannot find
alternative download locations for:

http://files.itstool.org/itstool/itstool-2.0.6.tar.bz2

Can someone help me (also sending me the file itself through e-mail if
nothing better :) )

-- 
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] 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

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

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

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).

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

Next release deadline: April 23rd, 2022 at 00:01 UTC

[Brian Manning via gtk-perl-list]

Hi everybody,

Based on the Gnome 43 release calendar [1], I am setting the deadline
for code submissions for the next release of Gtk-Perl modules to be
April 23rd, 2022, at 00:01 UTC.

Please have all code submissions into the Gtk-Perl maintainers before
the above deadline; please allow time for the maintainers to audit and
test code submissions.  If you have your favorite RT ticket[2][3] or
an issue in a given module's Gnome GitLab repo that you would like
someone to take a look at, don't be afraid to bring it up for
discussion here on the mailing list.

Once the above deadline date arrives, I will begin packaging any new
code in the Gtk-Perl git repos.  After packaging, I will distribute
tarballs to CPAN and Sourceforge, and post the release announcements,
usually within a few days of the release date.

If you have any questions about the above, please ask.

Heads up for May, the release deadline will be May 28th, 2022, at 00:01UTC.

Thanks,

Brian

[1] https://wiki.gnome.org/FortyThree
[2] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=XAOC
[3] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=TSCH
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-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

Problem with long list for ComboBoxText

[Kerenoc Kerenoc via gtk-perl-list]

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

Next release deadline: March 19th, 2022 at 00:01 UTC

[Brian Manning via gtk-perl-list]

Hi everybody,

Based on the Gnome 42 release calendar [1], I am setting the deadline
for code submissions for the next release of Gtk-Perl modules to be
March 19th, 2022, at 00:01 UTC.

Please have all code submissions into the Gtk-Perl maintainers before
the above deadline; please allow time for the maintainers to audit and
test code submissions.  If you have your favorite RT ticket[2][3] or
an issue in a given module's Gnome GitLab repo that you would like
someone to take a look at, don't be afraid to bring it up for
discussion here on the mailing list.

Once the above deadline date arrives, I will begin packaging any new
code in the Gtk-Perl git repos.  After packaging, I will distribute
tarballs to CPAN and Sourceforge, and post the release announcements,
usually within a few days of the release date.

If you have any questions about the above, please ask.

Heads up for April, the release deadline will be April 23rd, 2022, at 00:01UTC.

Thanks,

Brian

[1] https://wiki.gnome.org/FortyTwo
[2] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=XAOC
[3] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=TSCH
___
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]

Sorry about not doing the reply-all - many decades of trying not to do that 
accidentally …

Agree on /usr/local - we are making the same point but two different ways. On 
any unix type system any developer simply has to take care to avoid problems 
with /user/local - “ignore at your peril” if you like … Certainly the 
professional projects I have led and/or been involved with have always taken 
serious steps to obviate these problems. Most of the time a chroot gaol was the 
answer - hence my fondness for containers which are a more full-fat version of 
the same thing. Interestingly even “dedicated build servers” ended up becoming 
infected with cruft … leading back to container-like build systems.

Agreed on sandbox-exec - I mentioned it just so you could see what some are 
thinking about. There are some challenges for gaols on macOS in recent versions 
given the development of SIP - where system dyld’s are not present in the user 
visible filesystem.


Best
Paul

> On 18 Feb 2022, at 17:31, john  wrote:
> 
> Please remember to copy the list on all replies.
> 
> Of course one can't rely on something being in /usr/local, but that misses 
> the point: If you install something in /usr/local the compiler is going to 
> find it unless there's another instance in the command line search list (-I 
> and -L). Worse, /usr/local/bin is on the default path. That's why 
> Homebrew-on-Intel's default of creating symlinks there changes Homebrew from 
> a convenience to a serious vulnerability. Poorly controlled package managers 
> like that are a rich opportunity for bad guys, e.g. 
> https://arstechnica.com/information-technology/2021/11/malware-downloaded-from-pypi-41000-times-was-surprisingly-stealthy/
>  
> .
> 
> The sandbox-exec article is interesting, though I'm skeptical that Apple is 
> really using it for much: It's built on the Application Sandbox feature 
> that's required for App Store and Notarized apps. *That* part of it is 
> obviously not going away, but it looks like Apple wants us to use Launch 
> Services for accessing it, not the original sandbox_init(). One could set up 
> a jhbuild environment that way, but it's probably no less complicated that 
> the chroot jail method that most Unix developers already know how to do and 
> that Apple can't disable in the future.
> 
> Regards,
> John Ralls
> 
> 
>> On Feb 18, 2022, at 8:13 AM, Spock > > wrote:
>> 
>> You’d be surprised just how much 1980’s (and earlier) code is still running 
>> - hence my now-and-again use of 3270 ...
>> In my case, I do talks for kids on “how things used to be” and so keeping 
>> roughly familiar with MVS and some other systems is a important to me.
>> 
>> You will see that I used the English passive-aggressive “friendly” when 
>> talking about CMake - of course, it’s anything but that!
>> 
>> On /usr/local though, no application being built for distribution should 
>> ever rely on anything in that subtree - unless the application developer 
>> puts the code there as part of an installation it can’t rely on it being 
>> there. Such is life on unix … I can’t count the number of times I have seen 
>> people accidentally link to something in /usr/local only to find that their 
>> application won’t load or breaks in some horrible way on a different machine.
>> 
>> On the “build in a container” front, I totally agree - though to build on 
>> MacOS you don’t want a docker container. Docker would give you a linux 
>> environment … As an aside, many like podman as a docker alternative, but 
>> that is best installed using, er, *cough* *cough*, homebrew! 
>> 
>> There’s some discussion around how to have a sandboxed macOS environment 
>> running inside MacOS. See https://macoscontainers.org 
>>  for example. This is an interesting article, 
>> but probably not much use for Gtk-OSX - 
>> https://www.karltarvas.com/2020/10/25/macos-app-sandboxing-via-sandbox-exec.html
>>  
>> 
>> 
>> 
>> Best
>> Paul
>> 
>>> On 18 Feb 2022, at 04:54, john >> > wrote:
>>> 
>>> 3270 is still a  thing? Scary.
>>> 
>>> CMake's bug isn't really that recent, the fink and MacPorts inclusion goes 
>>> back more than 10 years, and homebrew-on-intel uses /usr/local that's on 
>>> the hard-coded defaults built into the kernel and every Unix compiler I've 
>>> met. This is also the first time I've heard anyone claim that Cmake is 
>>> friendly!
>>> 
>>> Meson's pretty nice. The only wart I've run up against is that fallback 
>>> feature, which is fine if your environment happens to fit the fallback's 
>>> settings but is otherwise a PITA. A lot of the GNOME projects have migrated 
>>> their builds to it.
>>> 
>>> I'll think a bit on how to word the paragraph in Building 

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

[john]

Please remember to copy the list on all replies.

Of course one can't rely on something being in /usr/local, but that misses the 
point: If you install something in /usr/local the compiler is going to find it 
unless there's another instance in the command line search list (-I and -L). 
Worse, /usr/local/bin is on the default path. That's why Homebrew-on-Intel's 
default of creating symlinks there changes Homebrew from a convenience to a 
serious vulnerability. Poorly controlled package managers like that are a rich 
opportunity for bad guys, e.g. 
https://arstechnica.com/information-technology/2021/11/malware-downloaded-from-pypi-41000-times-was-surprisingly-stealthy/.

The sandbox-exec article is interesting, though I'm skeptical that Apple is 
really using it for much: It's built on the Application Sandbox feature that's 
required for App Store and Notarized apps. *That* part of it is obviously not 
going away, but it looks like Apple wants us to use Launch Services for 
accessing it, not the original sandbox_init(). One could set up a jhbuild 
environment that way, but it's probably no less complicated that the chroot 
jail method that most Unix developers already know how to do and that Apple 
can't disable in the future.

Regards,
John Ralls


> On Feb 18, 2022, at 8:13 AM, Spock  wrote:
> 
> You’d be surprised just how much 1980’s (and earlier) code is still running - 
> hence my now-and-again use of 3270 ...
> In my case, I do talks for kids on “how things used to be” and so keeping 
> roughly familiar with MVS and some other systems is a important to me.
> 
> You will see that I used the English passive-aggressive “friendly” when 
> talking about CMake - of course, it’s anything but that!
> 
> On /usr/local though, no application being built for distribution should ever 
> rely on anything in that subtree - unless the application developer puts the 
> code there as part of an installation it can’t rely on it being there. Such 
> is life on unix … I can’t count the number of times I have seen people 
> accidentally link to something in /usr/local only to find that their 
> application won’t load or breaks in some horrible way on a different machine.
> 
> On the “build in a container” front, I totally agree - though to build on 
> MacOS you don’t want a docker container. Docker would give you a linux 
> environment … As an aside, many like podman as a docker alternative, but that 
> is best installed using, er, *cough* *cough*, homebrew! 
> 
> There’s some discussion around how to have a sandboxed macOS environment 
> running inside MacOS. See https://macoscontainers.org 
>  for example. This is an interesting article, 
> but probably not much use for Gtk-OSX - 
> https://www.karltarvas.com/2020/10/25/macos-app-sandboxing-via-sandbox-exec.html
>  
> 
> 
> 
> Best
> Paul
> 
>> On 18 Feb 2022, at 04:54, john > > wrote:
>> 
>> 3270 is still a  thing? Scary.
>> 
>> CMake's bug isn't really that recent, the fink and MacPorts inclusion goes 
>> back more than 10 years, and homebrew-on-intel uses /usr/local that's on the 
>> hard-coded defaults built into the kernel and every Unix compiler I've met. 
>> This is also the first time I've heard anyone claim that Cmake is friendly!
>> 
>> Meson's pretty nice. The only wart I've run up against is that fallback 
>> feature, which is fine if your environment happens to fit the fallback's 
>> settings but is otherwise a PITA. A lot of the GNOME projects have migrated 
>> their builds to it.
>> 
>> I'll think a bit on how to word the paragraph in Building Gtk-OSX. I think 
>> the ultimate solution is Docker-style containers but since Docker is very 
>> much not Free I'm reluctant to promote it. Flatpak would be an obvious GNOME 
>> alternative but AFAIK it doesn't play well with macOS and I don't have any 
>> bandwidth available to do anything about that.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>>> On Feb 17, 2022, at 10:46 AM, Spock >> > wrote:
>>> 
>>> I guess it all depends on whether you use your Mac exclusively for 
>>> developing gtk apps or not. Certainly on my Macs, I have need of a number 
>>> of tools that are out of-date in the Apple supplied versions and so use 
>>> homebrew for more recent versions. In the possibly most simple use case, I 
>>> use htop to monitor system performance - Apple does not supply it, so I use 
>>> homebrew … I use meld, supplied again by homebrew … I also develop a number 
>>> of different projects where a unix-like set of tools are required. If I 
>>> want to develop linux stuff for linux, I have machines or VMs for that ...
>>> 
>>> Oh, I also use applications such as c3270 (part of x3270) for accessing 
>>> some legacy systems … I get them from homebrew ..
>>> 
>>> So it goes on. The gtk-osx world and the rest-of-the-world should really 
>>> find a way to 

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

[john]

I consider it normal to *not* have homebrew, fink, and MacPorts installed. Why 
would anyone want to make their Mac behave like Linux? Contrariwise, if you 
want to develop for one of those environments what use do you have for Gtk-OSX?

Cmake's homebrew wart is a fairly recent addition 
(https://github.com/Kitware/CMake/commit/1a5c1a68b6a3ffdee2a2ae106af6724eb2d4786a)
 but the fink and mac ports ones have been there since 2.8 
(https://github.com/Kitware/CMake/commit/eae45a67e7901b9b5531a4cd49e9716e8edb3956).
 It's a fairly recent concern for gtk-osx though because more projects are 
abandoning the horror of autotools.

Cmake has, at least as far as gtk-osx is concerned, always had a way to disable 
that: https://cmake.org/cmake/help/v3.0/variable/CMAKE_SYSTEM_IGNORE_PATH.html. 
Add it to cmakeargs in jhbuildrc-custom:
cmakeargs = '-DCMAKE_SYSTEM_IGNORE_PATH="/opt/homebrew:/opt/macports:/sw"'

I've added that instruction to the Building Gtk-OSX wiki page.

AFAICT meson does *not* have this problem as long as you don't let it do its 
fallback trick on a Crake-based dependency, and the way to prevent that is to 
make sure that all fallback dependencies are already built the way you want 
them.

Regards,
John Ralls

> On Feb 17, 2022, at 7:52 AM, Spock  wrote:
> 
> As mentioned, I’m on an M1 Mac where everything homebrew does is in 
> /opt/homebrew … there is no /usr/local “pollution” from homebrew on M1 Macs … 
> I agree that there may have been problems with the x86 version where homebrew 
> used /usr/local as its own fiefdom!
> 
> Now, as I said earlier in the thread, there is nothing at all in 
> /usr/local/lib. There is no environment member containing ‘homebrew’.
> 
> Looking at the situation with freetype, the simple fact is that something in 
> /opt should not and does not affect another packages or build systems. The 
> reasoning here is that package A is required to ignore package B when package 
> B is in /opt - this is a fundamental principle of unix filesystems for the 
> past few decades ! The upshot from this is that it's down to package A to not 
> look at or notice package B. If package A is that fussy, it has problems and 
> won’t do well. Whatever package A thinks, it has no option but to work around 
> the fact that /opt/B exists ...
> 
> The freetype build seems to be a problem - and it appears this is caused by 
> cmake putting the paths for fink, macports and homebrew into its search paths 
> for include files and libraries. If you look in:
> 
>  path>/inst/share/cmake-3.20/Modules/Platform/Darwin.cmake
> 
> … you will see …
> 
> — snip --
> if(CMAKE_SYSTEM_NAME STREQUAL "Darwin" AND CMAKE_SYSTEM_PROCESSOR STREQUAL 
> "arm64")
>   list(PREPEND CMAKE_SYSTEM_PREFIX_PATH
> /opt/homebrew # Brew on Apple Silicon
> )
> endif()
> — snip —
> 
> This means that all CMake invocations by meson on M1 Macs will include 
> /opt/homebrew in the search path for include and libs.
> This is wrong - very, very wrong.
> 
> The upshot of this is that to use your script as-is requires a special M1 Mac 
> with no homebrew, fink or macports on it - your advice/requirement to “build 
> using a different username” 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 
>  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 

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

[Spock]

As mentioned, I’m on an M1 Mac where everything homebrew does is in 
/opt/homebrew … there is no /usr/local “pollution” from homebrew on M1 Macs … I 
agree that there may have been problems with the x86 version where homebrew 
used /usr/local as its own fiefdom!

Now, as I said earlier in the thread, there is nothing at all in 
/usr/local/lib. There is no environment member containing ‘homebrew’.

Looking at the situation with freetype, the simple fact is that something in 
/opt should not and does not affect another packages or build systems. The 
reasoning here is that package A is required to ignore package B when package B 
is in /opt - this is a fundamental principle of unix filesystems for the past 
few decades ! The upshot from this is that it's down to package A to not look 
at or notice package B. If package A is that fussy, it has problems and won’t 
do well. Whatever package A thinks, it has no option but to work around the 
fact that /opt/B exists ...

The freetype build seems to be a problem - and it appears this is caused by 
cmake putting the paths for fink, macports and homebrew into its search paths 
for include files and libraries. If you look in:

/inst/share/cmake-3.20/Modules/Platform/Darwin.cmake

… you will see …

— snip --
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin" AND CMAKE_SYSTEM_PROCESSOR STREQUAL 
"arm64")
  list(PREPEND CMAKE_SYSTEM_PREFIX_PATH
/opt/homebrew # Brew on Apple Silicon
)
endif()
— snip —

This means that all CMake invocations by meson on M1 Macs will include 
/opt/homebrew in the search path for include and libs.
This is wrong - very, very wrong.

The upshot of this is that to use your script as-is requires a special M1 Mac 
with no homebrew, fink or macports on it - your advice/requirement to “build 
using a different username” 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 
 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  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 > > 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 

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 
>  ...
> 
> 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, 

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 
 ...

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 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 

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
> 
> 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 

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
 — 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 …
 
 

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

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

[Spock]

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!
___
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

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

[Lukas Oberhuber via gtk-osx-users-list]

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).

Thanks,

Lukas
___
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 

Next release deadline: February 12th, 2022 at 00:01 UTC

[Brian Manning via gtk-perl-list]

Hi everybody,

Based on the Gnome 42 release calendar [1], I am setting the deadline
for code submissions for the next release of Gtk-Perl modules to be
February 12th, 2022, at 00:01 UTC.

Please have all code submissions into the Gtk-Perl maintainers before
the above deadline; please allow time for the maintainers to audit and
test code submissions.  If you have your favorite RT ticket[2][3] or
an issue in a given module's Gnome GitLab repo that you would like
someone to take a look at, don't be afraid to bring it up for
discussion here on the mailing list.

Once the above deadline date arrives, I will begin packaging any new
code in the Gtk-Perl git repos.  After packaging, I will distribute
tarballs to CPAN and Sourceforge, and post the release announcements,
usually within a few days of the release date.

If you have any questions about the above, please ask.

Heads up for March, the release deadline will be March 19th, 2022, at 00:01UTC.

Thanks,

Brian

[1] https://wiki.gnome.org/FortyTwo
[2] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=XAOC
[3] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=TSCH
___
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)

[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

[gtk-osx-users] Ninja not found.

[Pascal]

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.02022-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?

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] 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

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

[Pascal]

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,

Maybe some cleanup is also needed.

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

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

[Pascal]

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?

HTH, 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)

[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

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

[Richard Greene via gtk-osx-users-list]

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?

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

Method get_active_iter of ComboBox

[Kerenoc Kerenoc via gtk-perl-list]

Hello,

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.

Best regards

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

[gtk-osx-users] Fwd: Retreating from GNAT Ada on Apple Silicon

[Mace Ayres via gtk-osx-users-list]

> Please excuse my one-off comment, but when I ran into  problems moving my 
> Intel based Ada CE (GNAT and GPS interface) over to my newer Apple MacBook 
> M1, I just kept my older Intel silicon Macbook which runs my Ada set up fine 
> and use a screen share against it from my newer Macbook with M1.
> 
> The frustration, of what saw as a problem I was not able to spend any more 
> time, was solved for me by patience. I am glad I keep my older MCB with the 
> Intel chips, I will try Ada on M1 later, sometime.
> 
> Best regards
> 
> Michael Ayres
> Michael Ayres, MS, CISSP, CSEP, CSM, PMI-ACP, PMP |
>> Michael.ayres@yahoo.comcom |
>>  www.mace-associates.com
>> San Francisco, CA. | 415.999.2049  
>> 
>> 
> 
> 
>>> On Dec 30, 2021, at 10:22 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?
>> 
>> 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
___
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

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

[Pascal]

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.

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 à 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

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

[Pascal]

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?

Season's greetings, 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

Next release deadline: January 8th, 2022 at 00:01 UTC

[Brian Manning via gtk-perl-list]

Hi everybody,

Based on the Gnome 42 release calendar [1], I am setting the deadline
for code submissions for the next release of Gtk-Perl modules to be
January 8th, 2022, at 00:01 UTC.

Please have all code submissions into the Gtk-Perl maintainers before
the above deadline; please allow time for the maintainers to audit and
test code submissions.  If you have your favorite RT ticket[2][3] or
an issue in a given module's Gnome GitLab repo that you would like
someone to take a look at, don't be afraid to bring it up for
discussion here on the mailing list.

Once the above deadline date arrives, I will begin packaging any new
code in the Gtk-Perl git repos.  After packaging, I will distribute
tarballs to CPAN and Sourceforge, and post the release announcements,
usually within a few days of the release date.

If you have any questions about the above, please ask.

Heads up for February, the release deadline will be February 12th,
2022, at 00:01UTC.

Thanks,

Brian

[1] https://wiki.gnome.org/FortyTwo
[2] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=XAOC
[3] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=TSCH
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list