[PATCH] gnu: Add MEGA SDK

The SDK is a dependency of MEGAsync so I thought to make a new file since there's multiple packages that are MEGA related and then I discovered that the megacmd package exists; is it better for this to be placed in sync.scm, next to megacmd?

---

gnu/packages/mega.scm | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++

1 file changed, 74 insertions(+)

new file   gnu/packages/mega.scm

@@ -0,0 +1,74 @@

+;;; GNU Guix --- Functional package management for GNU

+;;; Copyright © 2021 Wamm K. D. <jaft.r@outlook.com>

+;;;

+;;; This file is part of GNU Guix.

+;;;

+;;; GNU Guix is free software; you can redistribute it and/or modify it

+;;; under the terms of the GNU General Public License as published by

+;;; the Free Software Foundation; either version 3 of the License, or (at

+;;; your option) any later version.

+;;;

+;;; GNU Guix is distributed in the hope that it will be useful, but

+;;; WITHOUT ANY WARRANTY; without even the implied warranty of

+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

+;;; GNU General Public License for more details.

+;;;

+;;; You should have received a copy of the GNU General Public License

+;;; along with GNU Guix.  If not, see http://www.gnu.org/licenses/.

+

+(define-module (gnu packages mega)

+  #:use-module ((guix licenses) #:prefix license:)

+  #:use-module (guix utils)

+  #:use-module (guix packages)

+  #:use-module (guix git-download)

+  #:use-module (guix build-system gnu)

+  #:use-module (gnu packages pkg-config)

+  #:use-module (gnu packages autotools)

+  #:use-module (gnu packages crypto)

+  #:use-module (gnu packages compression)

+  #:use-module (gnu packages sqlite)

+  #:use-module (gnu packages tls)

+  #:use-module (gnu packages adns)

+  #:use-module (gnu packages curl)

+  #:use-module (gnu packages image)

+  #:use-module (gnu packages readline)

+  #:use-module (gnu packages crypto))

+

+(define-public mega-sdk

+  (let ([version "3.9.10"])

+    (package

+      (name "mega-sdk")

+      (version version)

+      (source (origin

+                (method git-fetch)

+                (uri (git-reference

+                      (url "https://github.com/meganz/sdk/")

+                      (commit (string-append "v" version))))

+                (file-name (git-file-name name version))

+                (sha256 (base32

+                          "08qw23rm4rrvlsbcixrncbi5x0qgqkpx74l5f1gq2rgll0ksx8ph"))

+                (modules '((guix build utils)))))

+      (build-system gnu-build-system)

+      (native-inputs `(("autoconf" ,autoconf)

+                       ("automake" ,automake)

+                       ("libtool" ,libtool)))

+      (inputs `(("crypto++" ,crypto++)

+                ("zlib" ,zlib)

+                ("sqlite" ,sqlite)

+                ("openssl" ,openssl)

+                ("c-ares" ,c-ares)

+                ("curl" ,curl)

+                ("freeimage" ,freeimage)

+                ("readline" ,readline)

+                ("libsodium" ,libsodium)))

+      (arguments `(#:tests? #f))

+      (home-page "https://mega.nz/sdk")

+      (synopsis "SDK for the MEGA service, offered by MEGA Limited")

+      (description "A low-level SDK for the MEGA service which powers the

+file-sharing site.  This package provides two executables:

+@itemize

+@item megacli: a command-line tool that allows usage of all SDK features

+@item megasimplesync: a command line tool that allows usage of the

+synchronization engine

+@end itemize")

+      (license license:bsd-2))))

Am Donnerstag, den 02.12.2021, 06:32 +0000 schrieb Jaft:

Should be "New variable."

Sync is good. If existing Mega packages use the SDK, try to unbundle

them.

I don't know if I told you that yet, but comments ought to go below

this line.

I hate you too, Outlook.

Guile is not Racket, we use uniform brackets.

There's no reason to let-bind version if you're just going to assign it

here anyway.

Never leave #:tests? #f uncommented.

Sponsored by RAID: Shadow Legends.

Given the megacli command, what's the relation to existing MEGA

packages, particularly megacmd?

Cheers

Which part should be "New variable"? "* gnu/packages/mega.scm (mega-sdk): New variable"? Or the whole line? "* New variable"?

Makes sense; megatools doesn't seem to rely on it but megacmd pulls from git recursively since the SDK repo.'s setup as a module for it so I've adjusted that definition to make use of the SDK, now.

Mmm, I think you did but I must've misunderstood as I thought you were saying the opposite; noted and I'll do it the other way, going forward.

It hadn't been clear to me that the macro functions in that fashion; I've removed the use of let.

Makes sense; that's been revised.

I don't understand what this is communicating.

Noted above (and addressed in the new patch).

It seems like I'll likely have to make further changes but I've attached what I have for the patch, thus far, just to keep track of what changes have been made.

Hi,

Am Freitag, dem 17.12.2021 um 22:30 +0000 schrieb Jaft:

The joke is that you make it sound like and advertisement.

Since core-update's been merged now, try to use new-style inputs.

Unclear reasons including googletest not being present in the inputs?

You probably want to swap out the .la dependency for a .so dependency.

Pardon me if I was unclear, but this would be done in a separate

commit. But thanks anyway for confirming that it'd be easily

swappable.

Cheers

Hmm; I thought it was for the same reasons that tests had been disabled for megacmd but, taking another look at it, it seems I'm misremembering from the last time I worked on this.

It says it's failing because the MEGA_EMAIL and MEGA_PWD environment variables aren't set; from what I can tell, it uses those to test whether it can interact with a MEGA account appropriately. As that'd require requests to the internet, I'd expect the tests to fail in the end, still; is that a reasonable reason to disable them or should I try some other course of action?

Gotcha; because I'm unsure, how should I do that? Should I just attach two separate patches? Or should I open a separate ticket for the megacmd update (with its own separate patch, of course)?

Hi Jaft,

Am Samstag, dem 18.12.2021 um 05:14 +0000 schrieb Jaft:

If the entire suite requires internet access, then yeah, that's a good

case for #:tests? #f. If it's just certain test cases/groups, then

we'd rather go for disabling those.

You can send two patches as attachments, that's completely fine with

me. The typical Guix approach would however be to set up git send-

email and invoke it like 

$ git send-email --to=BUGNUMBER@debugs.gnu.org [--cc=REVIEWER ...] \ 

[--in-reply-to=MSGID] [--reroll-count N] PATCH ...

That's probably a lot to take in at once, but once you get the hang out

of it, it's actually quite easy. You can also use `git format-patch`

to prepare the emails with the arguments above and then send them by a

separate command. In any case, they go to a singular BUGNUMBER, in

this case 52238.

Cheers

Makes sense; it seems like it's present in the integration and tool_purge_account tests while the third group of tests – unit – seems to not rely on those. I adjusted the files to remove those two sets of tests and things built alright.

Gotcha. This is really useful and helpful; thanks a ton for walking through it.

I've attached two patches, one for each package; the SDK one removes the troublesome tests so the rest can be ran.

Hi,

Am Montag, dem 20.12.2021 um 01:58 +0000 schrieb Jaft:

LGTM, albeit somewhat overkill. Wouldn't it suffice to simply set

TESTS and possibly dropping those extra subdirectories?

By patch, I do mean patches in mbox format, not mere `git diff`s.

Don't strip mail headers; those are important.

Cheers

---

gnu/packages/sync.scm | 62 +++++++++++++++++++++++++++++++++++++++++++

1 file changed, 62 insertions(+)

rather than build mega-sdk via building recursively.

---

gnu/packages/sync.scm | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

Am Donnerstag, dem 03.02.2022 um 18:34 -0600 schrieb Wamm K. D:

Note that the hash didn't change, so you're still fetching the

recursive version. In addition, the non-recursive version won't build

as mega-sdk is deeply bundled into megacmd.

Hmm; perhaps a past installed caused things to build last time I tried this. I see what you mean, now.

In that case, I'm not sure that I have enough experience or knowledge with make tools to be able to untangle things, I'm afraid.

On Friday, February 4, 2022, 12:18:50 PM CST, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Am Donnerstag, dem 03.02.2022 um 18:34 -0600 schrieb Wamm K. D:

Note that the hash didn't change, so you're still fetching the

recursive version.  In addition, the non-recursive version won't build

as mega-sdk is deeply bundled into megacmd.

Am Samstag, dem 05.02.2022 um 03:05 +0000 schrieb Jaft:

Not necessarily. As I said, Guix already has substitutes for the

source, so it will fetch them regardless.

Fair enough, on the top of my head I'm not too sure how to untangle

this either. However, note that mega-sdk appears pretty useless as a

standalone package, so I'd like to solve that issue before pushing it.

Cheers

That's fair; I had been first trying to get it added as a package as I was trying to package up MEGAsync and, as you might imagine, this is a dependency of it. I've nearly got the MEGAsync package working but need to get icons working properly, still; if I'm able to get it, would it make sense to send a patch here and move forward with that package?

Am Sonntag, dem 13.02.2022 um 08:34 +0000 schrieb Jaft:

Sure. As long as there's a consumer to test that the package is

working as expected, everything ought to be fine. I don't know which

road will be the easier one, however.