Latest version no longer works after upgrading to Sonoma #147
Comments
|
same here :( |
|
mine no error, but blank window |
|
All of a sudden stopped working on Ventura 13.5.1 as well. It shows the window but the buttons are not responsive |
|
I am using Ventura 13.5.2 and it is working well. |
|
Could this be related to this issue in cairo? https://gitlab.freedesktop.org/cairo/cairo/-/issues/420 |
|
same here on Sonoma RC |
|
On Sonoma (final, released today), Meld stopped working (segmentation fault meld)... :( |
|
same here |
|
Same here but I get a segmentation fault : Crash report (first bits): |
|
@yousseb in full appreciation of your work I have to ask: am I correct that you do not intend to release an update soon? In my case to fix the crash on Sonoma (which has now been released). Is there something we can contribute? |
|
I tried building it from source, and it gets past the error (building it was a little tricky). So it doesn't look like any code changes are required, but probably just needs to be rebuilt. If I can package this up as a Mac App then I will share it. Issues run into while building
After that, I was able to run meld from source |
|
However, it does work if you compile it from source like in the instructions. We will have to wait for the author or someone more experienced with Mac app packaging. |
|
This is very frustrating |
|
same problem, is there an alternative for meld? |
|
I wouldn't write off Meld, it just needs to be recompiled and repackaged. This Mac OS specific fork still works great. We just need someone more experienced with Mac OS development to put up a .app of it. |
|
Meld was perfect when it worked earlier for folder comparison. I hope the author finds the time to update it. |
|
If it's just creating a package, it can be forked. |
|
Same issue here: $ meld (meld:25565): Gtk-WARNING **: 09:59:08.546: Locale not supported by C library. |
Can you share the py3cairo pkg file ? i'm stuck with meson _build failing to find py3cairo (though it is installed). Thanks ! |
|
Meld on Sonoma is broken for me as well. |
I was able to compile meld in Sonoma on M1 and run the ninja installer; i moved the meld pkg from /opt/homebrew/opt/homebrew/lib/python3.11/site-packages to /opt/homebrew/lib/python3.11/site-packages (I think it is where it was supposed to be...) but when I start meld I'm greeted with the error: Traceback (most recent call last): I installed both python modules Foundation and PyObjC, but it is still not working. |
|
I don't have the py3cairo package file. I tried searching for it but I might've overwritten it at some point when rebuilding. For the meld.conf issue: |
|
please fix, very useful tool |
does anyone know how to resolve that? |
|
I personally didn’t run into that when compiling or running. But try seeing if you can install it from pip.
…________________________________
From: rybalkoss ***@***.***>
Sent: Thursday, October 5, 2023 6:57:57 AM
To: yousseb/meld ***@***.***>
Cc: Lyga, Joe ***@***.***>; Comment ***@***.***>
Subject: Re: [yousseb/meld] Latest version no longer works after upgrading to Sonoma (Issue #147)
<External Email>
Traceback (most recent call last): File "/opt/homebrew/bin/meld", line 111, in import meld.conf # noqa: E402 ^^^^^^^^^^^^^^^^ File "/opt/homebrew/lib/python3.11/site-packages/meld/conf.py", line 5, in from Foundation import NSBundle ModuleNotFoundError: No module named 'Foundation'
I installed both python modules Foundation and PyObjC, but it is still not working. I personally hate python, it always has problem like that ....
does anyone know how to resolve that?
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/yousseb/meld/issues/147*issuecomment-1748656744__;Iw!!CxwJSw!OJRlv2O90FU8duoK_SsC89p_yP9ZhshSzgH9xwymJtEEYhTJNHga4V1bZqQmeitDOG7p-6KVAlO40MWB3Zcn4TpJ$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/APFUNDI43VKMRD6K2BZSYLTX52HDLAVCNFSM6AAAAAAZAU7YMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBYGY2TMNZUGQ__;!!CxwJSw!OJRlv2O90FU8duoK_SsC89p_yP9ZhshSzgH9xwymJtEEYhTJNHga4V1bZqQmeitDOG7p-6KVAlO40MWB3SrdxeTX$>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Meld on Sonoma is broken for me as well. |
|
Same here :( |
|
Flow the build guide，but end with: |
yes, and they are all hot garbage. I thought meld performed a little slow on OSX and went on a brief tour seeing what else is out there. Almost everything else was 1.) also slow or slower 2.) missing extremely basic 101 features. |
|
Hi Meld team. Are there news? This is an important tool to work. |
I tried this but I got this message. I tried to resolve by myself with no success 
I have Mac book Pro M1 with Sonoma 14.1.1 |
I was getting the same error as you when I ran the binary linked in #148 (comment). Many thanks to @matthiasdiener for providing the binary. Here is what did to fix it:
On a side note I installed only |
|
Sonoma 14.1.2 on x86 Latest pre-release works (and is actually quite fast) if you install libpng and brotoli using homebrew. However, there are some issue related to font rendering. Text seems to be stretched and font setting is not saving in preferences. I.e even after setting custom font to make it look a little better, the font will reset after closing of the app. |
|
Meld 3.21.0 (r4) Sonoma at 14.1.2 with Apple silicon Hope this snippet can help everyone; I've successfully used it myself and wanted to share it with all of you. https://gist.github.com/syneart/4a8724cd479d31f0f742f499f807dcb2
|
|
Meld 3.21.0 (r4) on x86-64 works as well https://github.com/yousseb/meld/releases
|
|
I just upgraded to macOS Sonomata 14.2, and it seems to have solved the issue somehow, Meld is now working again.
|
Yep, just tried it on an Intel mac here after upgrading to Sonoma 14.2 and the r3 release is working again. 🥳 Edit: spoke too soon - as marcink said below - it crashes when trying to compare directories. File comparisons work. Crashes in _cairo_surface_release_source_image: To be clear; the above is related to the last release version, 3.21.0 (r3). Directory diff is working fine in the r4 pre-release. |
|
I can launch meld on its own, and I can compare individual files, but as soon as I try to compare directories Meld crashes. Update: fixed by the comment below from syneart |
I'm also testing Meld version 3.21.0 (r4) on the Sonoma system at 14.2 / 14.2.1 with Apple silicon, and it's still functioning properly. |
|
I'm continuing to test r4 on Sonoma w/ an Intel chip. Two things I've encountered that seem unintended;
|
|
ugh . . . |
|
@william-wallace-simplisafe let's hope this will revive meld! |
|
Any workaround ideas for this? My OS got upgraded to Sonoma today and not having meld is very crippling :) |
|
I also used Meld for many years. Because of the problems with Sonoma, I have now switched to the great Diff Folders extension for Visual Studio Code: https://marketplace.visualstudio.com/items?itemName=L13RARY.l13-diff&ssr=false#overview Comparing two folders works very well there and I'm not alone in this opinion. |
|
I've been using meld for.. decades already. My main usage is in conjunction with git-meld, which is not maintained for many years, but still works like a charm. I now see that after upgrading to Looks like we'll have to wait for a new release, which is hard to predict based on the fact that the latest Meld 3.21.0 was released nearly 4 years ago.. UNLESS someone has an idea on how to bypass the internally packaged libraries and run with system packages instead.
|
|
@fullheart @AviBueno this is already a long thread but if you read through there should be a working MacOS build for both Intel and Apple silicon. @AviBueno looks like you have a different bug. @yousseb packages meld for MacOS but meld itself is an unmaintained Gnome project initiative. |
Where do you get that from? https://gitlab.gnome.org/GNOME/meld/-/commits/main |
|
@jonee @syneart I ran the script from the suggested solution and got a bunch of errors. I had Meld installed via homebrew. Saw that I should use the MacPorts, so I replaced the versions. When I ran the script again I got even more errors (see below).
|
|
It's all well and good that someone has uploaded working binaries, and I respect the effort someone had to go through to publish them. However, given the popularity of supply chain attacks, for some of us, "built on random (though very nice) guy's machine" is not what we're looking for. We prefer something built in an automated fashion on a clean environment with absolutely zero unrelated stuff touching it, ideally by some pipeline on GitHub. We have no idea what is going on with the security posture of very-nice-random-guy's machine, and it's not a risk we're looking to take. |
|
|
Thank you @syneart. Applying the hotfix indeed bypasses the "developer cannot be verified" error, so your script is working. The problem is that when Meld launches I can see it in the Dock, but it doesn't open any window. Moreover, I cannot launch it from CLI when issuing a simple |
|
Hey, I'd like to share that things started working for me after taking a different route (without patching @syneart's hotfix). I noticed that installing Meld (version 3.21.0 osx4, tag: osx-20) into the Application's folder will create the files with the "admin" group, but when installing to a folder under my home dir the files are created with the "staff" group. The steps I took are:
Once set up, Meld can be opened by double clicking in Finder. But more important for me - it can also be launched via CLI: Hope this helps someone. |
I installed Meld to my applications directory from day one and I still had to patch Meld. |
|
Using the path @AviBueno detailed, I can run the app and I can even use the CLI to compare files, but comparing directories via the CLI still blows up. The latter is my primary use case, unfortunately. |
|
@robwilkerson It was the same for me but at some point something changed and I'm now able to compare directories, which is the primary use case for me as well. The "assertion 'GTK_IS_WINDOW (window)' failed" error is still being printed to the console, but where it used to just not do anything after that line, it now launches the main window. I cannot tell if this happened just by running meld from CLI several times or if there was some system update that enabled it. My currently installed OS version is Sonoma 14.4.1. |
Trying to follow these steps but in Steps 5 and 6 I get |
|
@nkoroste I'm on the same Sonoma version but with the Intel core i9 flavor. Not familiar with this error and maybe someone else could better help. Until then I don't have much to offer other than the seemingly dumb notion to retry the operation and see if it gets untangled at some point. |
|
@nkoroste - Might help to follow the conversation over here. @syneart has done some awesome work patching the r4 release and I can now open the app as well as run diffs from the command line. |
|
@robwilkerson is right. I used the hot fix from @syneart linked above and it is working perfectly now. |
|
Any chance to have an official release with the fix in the coming days ? |
and others
I upgraded my mac to sonoma and now the software crashes on startup. Here is the crash message:
Translated Report (Full Report Below)
Process: Meld [13083]
Path: /Applications/Meld.app/Contents/MacOS/Meld
Identifier: org.gnome.meld
Version: 3.21.0.osx2 (3.21.0.osx2)
Code Type: ARM-64 (Translated)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2023-06-09 09:27:14.8923 -0400
OS Version: macOS 14.0 (23A5257q)
Report Version: 12
Anonymous UUID: 24976634-5085-2C39-8A49-4462CB674113
Sleep/Wake UUID: BB6CB32F-0CE4-43D8-AC9B-A12741CB7AE9
Time Awake Since Boot: 62000 seconds
Time Since Wake: 3052 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 0x7ff89732aa78 ???
1 libsystem_kernel.dylib 0x7ff8075ea88e __pthread_kill + 10
2 libsystem_pthread.dylib 0x7ff807622f30 pthread_kill + 262
3 libsystem_c.dylib 0x7ff807542a71 abort + 126
4 libsystem_c.dylib 0x7ff807541d84 __assert_rtn + 314
5 libcairo.2.dylib 0x10df39aa3 _cairo_surface_release_source_image.cold.1 + 35
6 libcairo.2.dylib 0x10dedad50 _cairo_surface_release_source_image + 32
7 libcairo.2.dylib 0x10df05899 DataProviderReleaseCallback + 25
8 CoreGraphics 0x7ff80ce467f1 data_release_info + 31
9 CoreGraphics 0x7ff80cdff8bd data_provider_finalize + 54
10 CoreGraphics 0x7ff80cdc7a68 data_provider_retain_count + 74
11 CoreFoundation 0x7ff8077c6906 _CFRelease + 515
12 CoreGraphics 0x7ff80ce25e93 image_finalize + 103
13 CoreFoundation 0x7ff8077c681b _CFRelease + 280
14 CoreGraphics 0x7ff80ce6d411 CG::DisplayListResourceImage::~DisplayListResourceImage() + 23
15 CoreGraphics 0x7ff80ce6d3ea CG::DisplayListResourceImage::~DisplayListResourceImage() + 14
16 CoreGraphics 0x7ff80d41a407 std::__1::shared_ptrCG::DisplayListResourceImage::~shared_ptrabi:v160002 + 49
17 CoreGraphics 0x7ff80d412893 std::__1::__tree<std::__1::shared_ptrCG::DisplayListResourceImage, CG::CompareResourceImage, std::__1::allocator<std::__1::shared_ptrCG::DisplayListResourceImage>>::destroy(std::__1::__tree_node<std::__1::shared_ptrCG::DisplayListResourceImage, void*>) + 47
18 CoreGraphics 0x7ff80d41287e std::__1::__tree<std::__1::shared_ptrCG::DisplayListResourceImage, CG::CompareResourceImage, std::__1::allocator<std::__1::shared_ptrCG::DisplayListResourceImage>>::destroy(std::__1::__tree_node<std::__1::shared_ptrCG::DisplayListResourceImage, void>) + 26
19 CoreGraphics 0x7ff80d41287e std::__1::__tree<std::__1::shared_ptrCG::DisplayListResourceImage, CG::CompareResourceImage, std::__1::allocator<std::__1::shared_ptrCG::DisplayListResourceImage>>::destroy(std::__1::__tree_node<std::__1::shared_ptrCG::DisplayListResourceImage, void>) + 26
20 CoreGraphics 0x7ff80ce6d2d3 CG::DisplayList::~DisplayList() + 301
21 CoreFoundation 0x7ff8077c681b _CFRelease + 280
22 libobjc.A.dylib 0x7ff8072640d5 object_cxxDestructFromClass(objc_object, objc_class*) + 83
23 libobjc.A.dylib 0x7ff80725d2f0 objc_destructInstance + 96
24 libobjc.A.dylib 0x7ff80725d289 _objc_rootDealloc + 62
25 AppKit 0x7ff80b4c8b6e -[NSViewBackingStoreImage dealloc] + 41
26 QuartzCore 0x7ff80fec40d5 CA::release_objects(X::List<void const*>*) + 21
27 QuartzCore 0x7ff80feb5258 CA::Transaction::commit() + 1548
28 AppKit 0x7ff80ad2b0bd __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 285
29 AppKit 0x7ff80b66ce99 ___NSRunLoopObserverCreateWithHandler_block_invoke + 41
30 CoreFoundation 0x7ff8076fdfac CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 23
31 CoreFoundation 0x7ff8076fded1 __CFRunLoopDoObservers + 493
32 CoreFoundation 0x7ff8076fd453 __CFRunLoopRun + 850
33 CoreFoundation 0x7ff8076fcae9 CFRunLoopRunSpecific + 557
34 HIToolbox 0x7ff812312819 RunCurrentEventLoopInMode + 292
35 HIToolbox 0x7ff812312456 ReceiveNextEventCommon + 201
36 HIToolbox 0x7ff812312371 _BlockUntilNextEventMatchingListInModeWithFilter + 66
37 AppKit 0x7ff80abce571 _DPSNextEvent + 880
38 AppKit 0x7ff80abcd2d3 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1304
39 libgdk-3.0.dylib 0x10f5abc4c poll_func + 172
40 libglib-2.0.0.dylib 0x10d82648d g_main_context_iterate + 445
41 libglib-2.0.0.dylib 0x10d826594 g_main_context_iteration + 100
42 libgio-2.0.0.dylib 0x10e4f823d g_application_run + 541
The text was updated successfully, but these errors were encountered: