Package Details: megasync 5.12.0.1-1

Git Clone URL: https://aur.archlinux.org/megasync.git (read-only, click to copy)
Package Base: megasync
Description: Official MEGA desktop application for syncing with MEGA Cloud Drive
Upstream URL: https://github.com/meganz/MEGAsync/
Licenses: LicenseRef-Mega-Limited-Code-License
Submitter: son_link
Maintainer: dbermond
Last Packager: dbermond
Votes: 381
Popularity: 1.07
First Submitted: 2014-09-01 18:12 (UTC)
Last Updated: 2025-05-30 22:55 (UTC)

Latest Comments

1 2 3 4 5 6 .. 54 Next › Last »

dbermond commented on 2025-06-07 12:30 (UTC)

@archisman sorry, but I cannot support the aarch64 architecture.

archisman commented on 2025-06-06 13:26 (UTC)

Now that megasync officially supports arm64, could you add aarch64 to the list of supported architectures?

dbermond commented on 2025-05-10 11:09 (UTC)

@vagelis what I tried to show you, is that in many cases there is no 'Linux' tag, so obviously there is no way to use it, hence your question in invalid in such cases as in version 5.11.0.3. And sometimes the 'Linux' tag comes only several days after the other ones. Anyway, this does not make any difference, as the 'Windows', 'OSX' and 'Linux' tags usually points to the same commit. We could use even the 'Windows' tag and the source code would be the same, since the commit is the same for all tags.

vagelis commented on 2025-05-10 04:51 (UTC) (edited on 2025-05-10 05:04 (UTC) by vagelis)

No tag for 5.11.0.3 but this released yesterday, thus my question https://github.com/meganz/MEGAsync/releases/tag/v5.11.1.0_Linux

dbermond commented on 2025-05-10 01:26 (UTC)

@vagelis can you please point me where is the 'Linux' tag for the upstream version 5.11.0.3?

vagelis commented on 2025-05-09 20:36 (UTC)

Hi. Why are we using the OSX version to build this package and not the Linux version that's provided by upstream? Thank you.

dbermond commented on 2025-05-07 18:14 (UTC)

@bartus The package is building perfectly fine with the cmake 'None' build type. The issue that you linked is closed, and it mentions that a build error happens only when not using NDEGUB, but we use it here.

bartus commented on 2025-05-07 07:54 (UTC) (edited on 2025-05-07 09:25 (UTC) by bartus)

Don't use CMAKE_BUILD_TYPE="None" as it triggers the error in recursive_mutex missing owns_lock() due to mismatch debug assertions.

https://github.com/meganz/sdk/issues/2679

FixedWing commented on 2025-02-12 01:55 (UTC)

You're right, I missed an update to libpdfium-nojs. I also miss-attributed the issue to MEGAsync rather than libpdfium-nojs. Thank you!

dbermond commented on 2025-02-11 17:11 (UTC)

@FixedWing Contrary to what upstream said, this package does not depend specifically on a pre-compiled libpdfium, but simply on libpdfium. If you use libpdfium-nojs (the one that is built from sources) to satisfy the dependency, it depends in icu, and you will need to rebuild it at every icu rebuild / soname bump. It's user responsibility to track and manage the needed rebuilds for all installed AUR packages. Being such, your issue can be summarized as a missed rebuild by the end-user, and this is not a packaging issue, and neither an upstream issue.

1 2 3 4 5 6 .. 54 Next › Last »