Closed axonasif closed 6 months ago
Ideally, we need a way to build the app with GitHub Actions. Related to #1873.
Ideally, we need a way to build the app with GitHub Actions. Related to #1873.
Agreed 💯 But sadly M1 runners aren't available yet: https://github.com/actions/virtual-environments/issues/2187, I wonder if QEMU can be used.
Other than that, I was able to replicate the tasks from build-macos.yml and got myself the CopyQ.app for M1 arch a while back, it's working very nicely than before! Previously it used to be "Intel" on the Kind
section, now it's "Apple".
Yesterday I was trying to follow this although it turns out to be incomplete, can I step forward and update this section through a PR 😃 ?
Thanks!
PRs are welcome!
@axonasif can you please give the steps to build m1 variant, really would appreciate it. CopyQ is the only thing running Intel for me right now.
Hey @Moulick, I raised a PR: https://github.com/hluk/CopyQ/pull/1961, you can just check there 😄 I was going to do it way before but was busy and forgot 😬
@axonasif left a couple comments in the PR, but yeah, was able to build a M1 native build from them 🎉. Now only if we could put them in Github actions, I wonder how other projects are doing M1 builds when Github does not support them.
Would this Github announcement in May/June help? https://github.com/github/roadmap/issues/528
Summary Apple developers will get the hardware and performance they need for their CI/CD operations with GitHub-hosted macOS runners powered by Apply silicone in an OSX arm64 runtime. The new runner options will make certain their apps are compatible with past, present, and future software requirements and have the performance they need to increase development velocity.
Intended Outcome Developers that want to build and deploy their applications using the latest Apple technologies will be able to do so with ease using GitHub Actions.
How will it work? To get started using M1 powered GitHub-hosted macOS runners, create a new GitHub-hosted runner with the desired machine specifications. Then, update the runs-on: key in your Actions workflow YAML to have those jobs target your larger runner.
We could probably use that when they provide the runner: https://github.com/actions/virtual-environments#available-environments
GitHub actions still do not have the M1 Darwin 😞 https://github.com/actions/runner-images/issues/2187. I am compiling for M1 locally every time there is a new release like the 6.3.1 a few hours ago. @hluk I can share the native M1 compiled copyq.app
with you every time CopyQ has a release if you'd like, you could sign it and include it in the release artefacts if that helps us distribute the M1 native version to more people.
Another option could be cross-compiling using qemu
which I am currently doing for my golang based projects. Though I have no experience with C++ so I would not know how to go about doing that
@Moulick, I'm looking forward to the universals binaries, CopyQ is the last Rosetta app I use. Have you noticed any memory leaks with the arm64 version #1928 ?
@Moulick, I'm looking forward to the universals binaries, CopyQ is the last Rosetta app I use. Have you noticed any memory leaks with the arm64 version #1928 ?
@reagle I didn't see CopyQ have any memory leak, I have only 1 tab, but CopyQ right from the startup uses 262MB for me. It's probably that much as I have stretched CopyQ to keep as much history as possible, aka shove as many nines into the configs as possible 🤣
Mem usage on startup 262MB After a week: 350MB
any progress on this? 🙏🏼
@hluk looks like M1 macOS runners are finally in beta [edit: better link] actions/runner-images#8439
@hluk looks like M1 macOS runners are finally in beta https://github.com/actions/runner-images/issues/8439
Unfortunately, it does not work. I get an error (https://github.com/hluk/CopyQ/actions/runs/6405963327):
The job was not started because recent account payments have failed or your spending limit needs to be increased. Please check the 'Billing & plans' section in your settings.
@hluk This error means that you need to provide up-to-date payment information, as this functionality is paid.
@hluk This error means that you need to provide up-to-date payment information, as this functionality is paid.
Yeah, that is confusing because the link above says:
There is no sign-up required for the beta and the runner is immediately available to all developers, teams, and enterprises.
@hluk This error means that you need to provide up-to-date payment information, as this functionality is paid.
Yeah, that is confusing because the link above says:
There is no sign-up required for the beta and the runner is immediately available to all developers, teams, and enterprises.
It appears open source support is coming in '24.
So it sounds like we'll have to wait another 6 months at least...? How much would it cost to pay for this feature until then I wonder?
Hi all,
You can use the FlyCI)'s macOS M2 runners. Our runners are on average 2x faster and 2x cheaper than GitHub's.
runs-on
label in your workflow file:
jobs:
ci:
- runs-on: macos-latest
+ runs-on: flyci-macos-large-latest-m2
steps:
- name: 👀 Checkout repo
uses: actions/checkout@v4
If your repo is public, then FlyCI offers 500 mins/month of free M1 runner usage with the flyci-macos-large-latest-m1
runner.
Best Regards, Kiril Gantchev CEO and co-founder of FlyCI
GitHub released m1 runners for opensource!!
GitHub released m1 runners for opensource!!
Nice! Looks like those work well.
The problem I have now is that Homebrew installs Qt libraries for x86_64 instead of arm64. Pending changes in #2609.
The problem I have now is that Homebrew installs Qt libraries for x86_64 instead of arm64.
I read it error wrong, it says:
ld: warning: ignoring file '/opt/homebrew/Cellar/qt/6.6.1/lib/QtWidgets.framework/Versions/A/QtWidgets': found architecture 'arm64', required architecture 'x86_64'
I think CMake is still trying to build for wrong architecture.
I finally got all the tests to pass for new M1 builds. I had to migrate the code the latest version of Qt 6 framework for all macOS builds.
The dmg files are suspiciously small (~5 MiB instead of previous ~25 MiB Qt 5 builds). It is possible that some plugins are missing (e.g. for displaying images).
Can anyone help verify that all works well? But make sure to backup your configuration and data before testing! New builds are here: https://github.com/hluk/CopyQ/actions/runs/7874076663?pr=2609#artifacts
@hluk I'll test it! Do you have a link to where I can find my config and db please?
No joy.
I downloaded the CopyQ-macos-12-m1.dmg
(what's the difference with 10
?). After unzipping and expanding into dmg
, I noted a share
folder in the DMG? I both ignored it, and I copied it to /Applications
, but neither made a difference.
After setting the permission xattr -d com.apple.quarantine /Applications/CopyQ.app
I launched with error.
@reagle Thanks for testing!
After unzipping and expanding into
dmg
, I noted ashare
folder in the DMG?
Looks like a stray config file in the share folder. Removing.
After setting the permission
xattr -d com.apple.quarantine /Applications/CopyQ.app
I launched with error.
Hmm, I though the whole CopyQ.app
folder created with cmake --install
would be included in the DMG file when using cpack
, but it does not include any libraries. I may need to revert it to the previous version using macdeployqt
manually.
New builds: https://github.com/hluk/CopyQ/actions/runs/7883890737?pr=2609#artifacts
But now the package size is ~40 MiB -- 102MiB unpacked, which was 60MiB in v7.1.0.
I see some Qt framework parts that probably should not be included in the package: QtDBus, QtQmlModels, QtQuick, QtPdf
Let me know when you want me to try again. Oh, and what's the difference between CopyQ-macos-10.dmg
and CopyQ-macos-12-m1.dmg
?
I tried the latest 12-m1.dmg
from https://github.com/hluk/CopyQ/actions/runs/7888024879.
```
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: CopyQ [38420]
Path: /Users/USER/Downloads/CopyQ.app/Contents/MacOS/CopyQ
Identifier: io.github.hluk.CopyQ
Version: 7.1 (7.1.0-gbd040711-macos-m1)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 502
Date/Time: 2024-02-14 13:27:01.2040 +0100
OS Version: macOS 14.3.1 (23D60)
Report Version: 12
Anonymous UUID: A595B976-3ED0-3F7E-8026-9D48A2E21047
Sleep/Wake UUID: 9F619422-6836-42A9-8B75-AC8796966D31
Time Awake Since Boot: 170000 seconds
Time Since Wake: 14178 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [38420]
VM Region Info: 0 is not in any region. Bytes before following region: 4301651968
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 100660000-100bb4000 [ 5456K] r-x/r-x SM=COW ...s/MacOS/CopyQ
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 CopyQ 0x10068eecc 0x100660000 + 192204
1 CopyQ 0x10068ee9c 0x100660000 + 192156
2 CopyQ 0x10068ee68 0x100660000 + 192104
3 CopyQ 0x10068ee00 0x100660000 + 192000
4 CopyQ 0x10071d65c QTextCharFormat::fontFamily() const + 104
5 libitemtext.so 0x119a66164 sanitizeTextDocument(QTextDocument*) + 196
6 libitemtext.so 0x119a74944 ItemText::ItemText(QString const&, QString const&, QString const&, int, int, int, QWidget*) + 1360
7 libitemtext.so 0x119a74de4 ItemText::ItemText(QString const&, QString const&, QString const&, int, int, int, QWidget*) + 84
8 libitemtext.so 0x119a75970 ItemTextLoader::create(QMap
Let me know when you want me to try again. Oh, and what's the difference between
CopyQ-macos-10.dmg
andCopyQ-macos-12-m1.dmg
?
CopyQ-macos-10.dmg
- this is compatible with macOS 10.15CopyQ-macos-12-m1.dmg
- this is compatible with macOS 12 and only for the M1 architectureTrying to open the UI works as long as any entry with text/html is not visible. It crashes with with below report
@Moulick Thanks for testing!
The crash seems to be related to a workaround on macOS to avoid showing dialogs to download fonts. It seems like a bug in Qt in this case (https://bugreports.qt.io/browse/QTBUG-97864). This can be hopefully fixed by not using the deprecated Qt API.
New builds with the fix: https://github.com/hluk/CopyQ/actions/runs/7912619593?pr=2609
@hluk It is stable and running now!!
One issue I see is while scrolling up my clipboard in the UI. Scrolling down is fine. Scrolling up somehow snaps back down again and prevents scrolling up. Video attached
https://github.com/hluk/CopyQ/assets/15780903/7d51af8c-3249-47b6-afc6-ae115d98560a
I immediately get a crash report with https://github.com/hluk/CopyQ/actions/runs/7912619593?pr=2609 .
I immediately get a crash report with https://github.com/hluk/CopyQ/actions/runs/7912619593?pr=2609 .
@reagle Please attach the crash report?
@reagle for now you'll need to run codesign --force --deep --sign - /Applications/CopyQ.app
with the test builds
Okay, I need both of the following, but it seems to work, and I don't notice any scrolling issues. BTW: The dmg
file doesn't have a link to the /Applications folder for quick drag and install, I think it did in an earlier version.
xattr -d com.apple.quarantine /Applications/CopyQ.app
codesign --force --deep --sign - /Applications/CopyQ.app
For testing I am just running the .app from the Downloads folder
The
dmg
file doesn't have a link to the /Applications folder for quick drag and install, I think it did in an earlier version.
The command to create the dmg
is now same as for previous versions (at least for 1.7.0) except the utility macdeployqt
is probably different (whatever is included in the specific Qt 6 installation). I also don't really see much difference between the old and new package contents (just different libraries included).
@hluk perhaps I misremember; having a link to the /Applications
folder is common within DMGs, but not a big deal in any case.
BTW: I've been running the M1 version of copyq for a few days now and no crashes or problems. Woot!
I see that cpack
was able to include Applications
in the archive, perhaps I can add it manually or the could be a flag to macdeployqt
.
I've been running the M1 version of copyq for a few days now and no crashes or problems. Woot!
That sounds great!
But one problem could be that the app won't be able to show above full screen windows. I had to change the main window type because it had some problems with getting focus after closing dialogs (in automated tests).
Same here, running since a few days, is stable. The stuttering on scrolling up still exists though
But one problem could be that the app won't be able to show above full screen windows. I had to change the main window type because it had some problems with getting focus after closing dialogs (in automated tests).
I sometimes maximize a window, but never use MacOS fullscreen mode (such that the window gets its own virtual desktop). I can report that in that full screen mode, raising copyq with my keyboard shortcut takes me to a different desktop to show me the popup.
I can't replicate @Moulick's issue, but I limit my queue to 200 items, and it looks like in the video they are scrolling near 5k items.
I keep the limit as high as possible :) I'ma raise a ticket to allow higher :)
Actually, I just checked, the old 6.3.1 also has this problem, so it's not related to 7.1 or M1, I'll open a new one to track that separately. Never noticed it before as I don't use the CopyQ UI at all
I keep the limit as high as possible :) I'ma raise a ticket to allow higher :)
The new version of the app allows 100,000 items per tab because it does not load all items at once (it keeps large items in separate storage).
The stuttering on scrolling up is happening due to some other optimization where the app calculates an item size only when it shows up on the screen. This may appear more unstable depending on the current system configuration.
Not sure if I can fix that properly. Best solution I found is to override some undocumented Qt method:
Well, at least the keyboard navigation (Up arrow and Page Up) is much more stable (at least for me).
How does one get this via homebrew? I ran a brew reinstall copyq
but it pulled the Intel .app again.
https://github.com/Homebrew/homebrew-cask/blob/master/Casks/c/copyq.rb needs to be updated it seems, I see some improvements needs to be done in there.
@hluk Can you maybe please make a new release so that the releases tab has a m1 build? I can fix the cask in homebrew to handle installing intel vs ARM build but needs a release to have an url.
Can you maybe please make a new release so that the releases tab has a m1 build? I can fix the cask in homebrew to handle installing intel vs ARM build but needs a release to have an url.
CopyQ 8.0.0 is now released!
Can you maybe please make a new release so that the releases tab has a m1 build? I can fix the cask in homebrew to handle installing intel vs ARM build but needs a release to have an url.
CopyQ 8.0.0 is now released!
Thank you so much, I'll take this as soon as I can
Is your feature request related to a problem? Please describe. I installed the latest build of CopyQ from Releases but realised that it's still only compiled for x86 architecture. I can still use it almost perfectly with the rosetta translation of the M1 chip but nothing like having a native build.
Describe the solution you'd like I'm not sure if we already can successfully compile for the M1(arm64), but it would be great if you guys can provide an universal macOS package with native binaries for M1. I'm more than happy if there is anything I can help with in terms of testing and such :)
Describe alternatives you've considered NULL
Additional context Nothing, but thanks for reading!