GNU bug report logs - #52238
[PATCH] gnu: Add MEGA SDK

Previous Next

To reply to this bug, email your comments to 52238 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jaft <jaft.r <at> outlook.com>
To: "guix-patches <at> gnu.org" <guix-patches <at> gnu.org>
Subject: [PATCH] gnu: Add MEGA SDK
Date: Thu, 2 Dec 2021 06:32:26 +0000 (UTC)

* gnu/packages/mega.scm (mega-sdk):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 <at> 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))))

Message #8 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Jaft <jaft.r <at> outlook.com>, 52238 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: Add MEGA SDK
Date: Mon, 06 Dec 2021 20:52:59 +0100

Am Donnerstag, den 02.12.2021, 06:32 +0000 schrieb Jaft:
> * gnu/packages/mega.scm (mega-sdk):Add MEGA SDK
Should be "New variable."

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

> +(define-public mega-sdk
> +=C2=A0 (let ([version "3.9.10"])
> +=C2=A0=C2=A0=C2=A0 (package
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (name "mega-sdk")
I hate you too, Outlook.

> +(define-public mega-sdk
> +  (let ([version "3.9.10"])
Guile is not Racket, we use uniform brackets.
> +    (package
> +      (name "mega-sdk")
> +      (version version)
There's no reason to let-bind version if you're just going to assign it
here anyway.
> +      (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))
Never leave #:tests? #f uncommented.
> +      (home-page "https://mega.nz/sdk")
> +      (synopsis "SDK for the MEGA service, offered by MEGA Limited")
Sponsored by RAID: Shadow Legends.
> +      (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))))
Given the megacli command, what's the relation to existing MEGA
packages, particularly megacmd?

Cheers

Message #11 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Jaft <jaft.r <at> outlook.com>
To: "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>, 
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: [PATCH] gnu: Add MEGA SDK
Date: Fri, 17 Dec 2021 22:30:55 +0000 (UTC)

[Message part 1 (text/plain, inline)]

> On Monday, December 6, 2021, 01:53:09 PM CST, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote: 
>
>
>
>
>
> Am Donnerstag, den 02.12.2021, 06:32 +0000 schrieb Jaft:
> > * gnu/packages/mega.scm (mega-sdk):Add MEGA SDK
> Should be "New variable."

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

> > 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?
> Sync is good.  If existing Mega packages use the SDK, try to unbundle
> them.

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.

> > ---
> I don't know if I told you that yet, but comments ought to go below
> this line.

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.

> > +    (package
> > +      (name "mega-sdk")
> > +      (version version)
> There's no reason to let-bind version if you're just going to assign it
> here anyway.

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

> > +      (arguments `(#:tests? #f))
> Never leave #:tests? #f uncommented.

Makes sense; that's been revised.

> > +      (home-page "https://mega.nz/sdk")
> > +      (synopsis "SDK for the MEGA service, offered by MEGA Limited")
> Sponsored by RAID: Shadow Legends.

I don't understand what this is communicating.

> Given the megacli command, what's the relation to existing MEGA
> packages, particularly megacmd?
>
> Cheers

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.

[mega-sdk.patch (text/x-patch, attachment)]

Message #14 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Jaft <jaft.r <at> outlook.com>, "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>
Subject: Re: [PATCH] gnu: Add MEGA SDK
Date: Sat, 18 Dec 2021 00:22:09 +0100

Hi,

Am Freitag, dem 17.12.2021 um 22:30 +0000 schrieb Jaft:
> 
> >  > +      (home-page "https://mega.nz/sdk")
> >  > +      (synopsis "SDK for the MEGA service, offered by MEGA
> > Limited")
> >  Sponsored by RAID: Shadow Legends.
> 
> I don't understand what this is communicating.
The joke is that you make it sound like and advertisement.

> +    (native-inputs `(("autoconf" ,autoconf)
> +                     ("automake" ,automake)
> +                     ("libtool" ,libtool)))
> +    (inputs `(("c-ares" ,c-ares)
> +              ("crypto++" ,crypto++)
> +              ("curl" ,curl)
> +              ("freeimage" ,freeimage)
> +              ("libsodium" ,libsodium)
> +              ("openssl" ,openssl)
> +              ("readline" ,readline)
> +              ("sqlite" ,sqlite)
> +              ("zlib" ,zlib)))
Since core-update's been merged now, try to use new-style inputs.

> +    ;; XXX: Disabling tests because they depend on libgtest.la from
> googletest,
> +    ;; which is not installed for unclear reasons.
> +    (arguments `(#:tests? #f))
Unclear reasons including googletest not being present in the inputs? 
You probably want to swap out the .la dependency for a .so dependency.

>  (define-public megacmd
>    (package
>      (name "megacmd")
> @@ -222,8 +262,7 @@ (define-public megacmd
>          (method git-fetch)
>          (uri (git-reference
>                (url "https://github.com/meganz/MEGAcmd")
> -              (commit (string-append version "_Linux"))
> -              (recursive? #t)))
> +              (commit (string-append version "_Linux"))))
>          (sha256
>           (base32
>            "004j8m3xs6slx03g2g6wzr97myl2v3zc09wxnfar5c62a625pd53"))
> @@ -242,6 +281,7 @@ (define-public megacmd
>         ("curl" ,curl)
>         ("freeimage" ,freeimage)
>         ("gtest" ,googletest)
> +       ("mega-sdk" ,mega-sdk)
>         ("openssl" ,openssl)
>         ("pcre" ,pcre)
>         ("readline" ,readline)
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
> 

Message #17 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Jaft <jaft.r <at> outlook.com>
To: "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>, 
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: [PATCH] gnu: Add MEGA SDK
Date: Sat, 18 Dec 2021 05:14:48 +0000 (UTC)

> > +    ;; XXX: Disabling tests because they depend on libgtest.la from
> > googletest,
> > +    ;; which is not installed for unclear reasons.
> > +    (arguments `(#:tests? #f))
> Unclear reasons including googletest not being present in the inputs? 
> You probably want to swap out the .la dependency for a .so dependency.

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?

> >  (define-public megacmd
> >    (package
> >      (name "megacmd")
> > @@ -222,8 +262,7 @@ (define-public megacmd
> >          (method git-fetch)
> >          (uri (git-reference
> >                (url "https://github.com/meganz/MEGAcmd")
> > -              (commit (string-append version "_Linux"))
> > -              (recursive? #t)))
> > +              (commit (string-append version "_Linux"))))
> >          (sha256
> >          (base32
> >            "004j8m3xs6slx03g2g6wzr97myl2v3zc09wxnfar5c62a625pd53"))
> > @@ -242,6 +281,7 @@ (define-public megacmd
> >        ("curl" ,curl)
> >        ("freeimage" ,freeimage)
> >        ("gtest" ,googletest)
> > +      ("mega-sdk" ,mega-sdk)
> >        ("openssl" ,openssl)
> >        ("pcre" ,pcre)
> >        ("readline" ,readline)
> 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.

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

Message #20 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Jaft <jaft.r <at> outlook.com>, "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>
Subject: Re: [PATCH] gnu: Add MEGA SDK
Date: Sat, 18 Dec 2021 08:47:44 +0100

Hi Jaft,

Am Samstag, dem 18.12.2021 um 05:14 +0000 schrieb Jaft:
> >  > +    ;; XXX: Disabling tests because they depend on libgtest.la
> > from
> >  > googletest,
> >  > +    ;; which is not installed for unclear reasons.
> >  > +    (arguments `(#:tests? #f))
> >  Unclear reasons including googletest not being present in the
> > inputs? 
> >  You probably want to swap out the .la dependency for a .so
> > dependency.
> 
> 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?
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.

> >  >  (define-public megacmd
> >  >    (package
> >  >      (name "megacmd")
> >  > @@ -222,8 +262,7 @@ (define-public megacmd
> >  >          (method git-fetch)
> >  >          (uri (git-reference
> >  >                (url "https://github.com/meganz/MEGAcmd")
> >  > -              (commit (string-append version "_Linux"))
> >  > -              (recursive? #t)))
> >  > +              (commit (string-append version "_Linux"))))
> >  >          (sha256
> >  >          (base32
> >  >           
> > "004j8m3xs6slx03g2g6wzr97myl2v3zc09wxnfar5c62a625pd53"))
> >  > @@ -242,6 +281,7 @@ (define-public megacmd
> >  >        ("curl" ,curl)
> >  >        ("freeimage" ,freeimage)
> >  >        ("gtest" ,googletest)
> >  > +      ("mega-sdk" ,mega-sdk)
> >  >        ("openssl" ,openssl)
> >  >        ("pcre" ,pcre)
> >  >        ("readline" ,readline)
> >  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.
> 
> 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)?
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 <at> 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

Message #23 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Jaft <jaft.r <at> outlook.com>
To: "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>, 
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: [PATCH] gnu: Add MEGA SDK
Date: Mon, 20 Dec 2021 01:58:08 +0000 (UTC)

[Message part 1 (text/plain, inline)]

> On Saturday, December 18, 2021, 01:47:47 AM CST, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote: 
>
>
>
>
>
> Hi Jaft,
>
> Am Samstag, dem 18.12.2021 um 05:14 +0000 schrieb Jaft:
> > >  > +    ;; XXX: Disabling tests because they depend on libgtest.la
> > > from
> > >  > googletest,
> > >  > +    ;; which is not installed for unclear reasons.
> > >  > +    (arguments `(#:tests? #f))
> > >  Unclear reasons including googletest not being present in the
> > > inputs? 
> > >  You probably want to swap out the .la dependency for a .so
> > > dependency.
> > 
> > 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?
> 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.

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.

> > >  >  (define-public megacmd
> > >  >    (package
> > >  >      (name "megacmd")
> > >  > @@ -222,8 +262,7 @@ (define-public megacmd
> > >  >          (method git-fetch)
> > >  >          (uri (git-reference
> > >  >                (url "https://github.com/meganz/MEGAcmd")
> > >  > -              (commit (string-append version "_Linux"))
> > >  > -              (recursive? #t)))
> > >  > +              (commit (string-append version "_Linux"))))
> > >  >          (sha256
> > >  >          (base32
> > >  >           
> > > "004j8m3xs6slx03g2g6wzr97myl2v3zc09wxnfar5c62a625pd53"))
> > >  > @@ -242,6 +281,7 @@ (define-public megacmd
> > >  >        ("curl" ,curl)
> > >  >        ("freeimage" ,freeimage)
> > >  >        ("gtest" ,googletest)
> > >  > +      ("mega-sdk" ,mega-sdk)
> > >  >        ("openssl" ,openssl)
> > >  >        ("pcre" ,pcre)
> > >  >        ("readline" ,readline)
> > >  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.
> > 
> > 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)?
> 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 <at> 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

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.

[mega-sdk2.patch (text/x-patch, attachment)]

[megacmd.patch (text/x-patch, attachment)]

Message #26 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Jaft <jaft.r <at> outlook.com>, "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>
Subject: Re: [PATCH] gnu: Add MEGA SDK
Date: Mon, 20 Dec 2021 21:08:07 +0100

Hi,

Am Montag, dem 20.12.2021 um 01:58 +0000 schrieb Jaft:
> 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.
LGTM, albeit somewhat overkill.  Wouldn't it suffice to simply set
TESTS and possibly dropping those extra subdirectories?
> 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.
By patch, I do mean patches in mbox format, not mere `git diff`s. 
Don't strip mail headers; those are important.

Cheers

Message #29 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: "Wamm K. D" <jaft.r <at> outlook.com>
To: 52238 <at> debbugs.gnu.org
Cc: "Wamm K. D" <jaft.r <at> outlook.com>, liliana.prikler <at> gmail.com
Subject: [PATCH] gnu: Add mega-sdk.
Date: Thu,  3 Feb 2022 18:30:12 -0600

* gnu/packages/sync.scm (mega-sdk): New package.
---
 gnu/packages/sync.scm | 62 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/gnu/packages/sync.scm b/gnu/packages/sync.scm
index f897c1ec4a..52003a7c9d 100644
--- a/gnu/packages/sync.scm
+++ b/gnu/packages/sync.scm
@@ -210,6 +210,68 @@ (define-public nextcloud-client
                    license:lgpl2.1+  ; qtokenizer
                    license:gpl2+))))
 
+(define-public mega-sdk
+  (package
+    (name "mega-sdk")
+    (version "3.9.10")
+    (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 `(("c-ares" ,c-ares)
+              ("crypto++" ,crypto++)
+              ("curl" ,curl)
+              ("freeimage" ,freeimage)
+              ("libsodium" ,libsodium)
+              ("openssl" ,openssl)
+              ("readline" ,readline)
+              ("sqlite" ,sqlite)
+              ("zlib" ,zlib)))
+    (arguments
+     `(#:phases
+       (modify-phases %standard-phases
+         (add-before 'bootstrap 'remove-tests-that-require-a-mega-account
+           (lambda _
+             (substitute* "tests/include.am"
+               (("TESTS = tests/test_unit .+") "TESTS = tests/test_unit")
+               ;; tool_purge_account related
+               (("tests_tool_purge_account_SOURCES = \\\\") "")
+               (("    tests/tool/purge_account\\.cpp") "")
+               (("tests_tool_purge_account_CXXFLAGS = .+") "")
+               (("tests_tool_purge_account_LDADD = .+") "")
+               ;; test_integration related
+               (("tests_test_integration_SOURCES = \\\\") "")
+               (("    tests/integration/main\\.cpp \\\\") "")
+               (("    tests/integration/SdkTest_test\\.cpp \\\\") "")
+               (("    tests/integration/Sync_test\\.cpp") "")
+               (("tests_test_integration_CXXFLAGS = .+") "")
+               (("tests_test_integration_LDADD = .+") ""))
+
+             (substitute* "contrib/QtCreator/MEGAtests/MEGAtests.pro"
+               (("SUBDIRS [+]= MEGAtest_integration") "")
+               (("SUBDIRS [+]= MEGAtest_purge_account") "")
+               (("    SUBDIRS [+]= MEGAtest_integration_fsevents_loader") "")
+               (("    MEGAtest_integration_fsevents_loader\\.depends = .+") "")))))))
+    (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)))
+
 (define-public megacmd
   (package
     (name "megacmd")
-- 
2.34.0

Message #32 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: "Wamm K. D" <jaft.r <at> outlook.com>
To: 52238 <at> debbugs.gnu.org
Cc: "Wamm K. D" <jaft.r <at> outlook.com>, liliana.prikler <at> gmail.com
Subject: [PATCH] gnu: megacmd: Add mega-sdk as dependency.
Date: Thu,  3 Feb 2022 18:34:51 -0600

* gnu/packages/sync.scm (megacmd): Use new package mega-sdk as dependency
rather than build mega-sdk via building recursively.
---
 gnu/packages/sync.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/sync.scm b/gnu/packages/sync.scm
index 52003a7c9d..753b4e4d47 100644
--- a/gnu/packages/sync.scm
+++ b/gnu/packages/sync.scm
@@ -281,8 +281,7 @@ (define-public megacmd
         (method git-fetch)
         (uri (git-reference
               (url "https://github.com/meganz/MEGAcmd")
-              (commit (string-append version "_Linux"))
-              (recursive? #t)))
+              (commit (string-append version "_Linux"))))
         (sha256
          (base32
           "004j8m3xs6slx03g2g6wzr97myl2v3zc09wxnfar5c62a625pd53"))
@@ -301,6 +300,7 @@ (define-public megacmd
        ("curl" ,curl)
        ("freeimage" ,freeimage)
        ("gtest" ,googletest)
+       ("mega-sdk" ,mega-sdk)
        ("openssl" ,openssl)
        ("pcre" ,pcre)
        ("readline" ,readline)
-- 
2.34.0

Message #35 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: "Wamm K. D" <jaft.r <at> outlook.com>, 52238 <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: megacmd: Add mega-sdk as dependency.
Date: Fri, 04 Feb 2022 19:18:44 +0100

Am Donnerstag, dem 03.02.2022 um 18:34 -0600 schrieb Wamm K. D:
> * gnu/packages/sync.scm (megacmd): Use new package mega-sdk as
> dependency
> rather than build mega-sdk via building recursively.
> ---
>  gnu/packages/sync.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gnu/packages/sync.scm b/gnu/packages/sync.scm
> index 52003a7c9d..753b4e4d47 100644
> --- a/gnu/packages/sync.scm
> +++ b/gnu/packages/sync.scm
> @@ -281,8 +281,7 @@ (define-public megacmd
>          (method git-fetch)
>          (uri (git-reference
>                (url "https://github.com/meganz/MEGAcmd")
> -              (commit (string-append version "_Linux"))
> -              (recursive? #t)))
> +              (commit (string-append version "_Linux"))))
>          (sha256
>           (base32
>            "004j8m3xs6slx03g2g6wzr97myl2v3zc09wxnfar5c62a625pd53"))
> @@ -301,6 +300,7 @@ (define-public megacmd
>         ("curl" ,curl)
>         ("freeimage" ,freeimage)
>         ("gtest" ,googletest)
> +       ("mega-sdk" ,mega-sdk)
>         ("openssl" ,openssl)
>         ("pcre" ,pcre)
>         ("readline" ,readline)
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.

Message #38 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Jaft <jaft.r <at> outlook.com>
To: "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>, 
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: [PATCH] gnu: megacmd: Add mega-sdk as dependency.
Date: Sat, 5 Feb 2022 03:05:48 +0000 (UTC)

[Message part 1 (text/plain, inline)]

 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 <at> gmail.com> wrote:  
 
 Am Donnerstag, dem 03.02.2022 um 18:34 -0600 schrieb Wamm K. D:
> * gnu/packages/sync.scm (megacmd): Use new package mega-sdk as
> dependency
> rather than build mega-sdk via building recursively.
> ---
>  gnu/packages/sync.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gnu/packages/sync.scm b/gnu/packages/sync.scm
> index 52003a7c9d..753b4e4d47 100644
> --- a/gnu/packages/sync.scm
> +++ b/gnu/packages/sync.scm
> @@ -281,8 +281,7 @@ (define-public megacmd
>          (method git-fetch)
>          (uri (git-reference
>                (url "https://github.com/meganz/MEGAcmd")
> -              (commit (string-append version "_Linux"))
> -              (recursive? #t)))
> +              (commit (string-append version "_Linux"))))
>          (sha256
>           (base32
>            "004j8m3xs6slx03g2g6wzr97myl2v3zc09wxnfar5c62a625pd53"))
> @@ -301,6 +300,7 @@ (define-public megacmd
>         ("curl" ,curl)
>         ("freeimage" ,freeimage)
>         ("gtest" ,googletest)
> +       ("mega-sdk" ,mega-sdk)
>         ("openssl" ,openssl)
>         ("pcre" ,pcre)
>         ("readline" ,readline)
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.
  

[Message part 2 (text/html, inline)]

Message #41 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Jaft <jaft.r <at> outlook.com>, "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>
Subject: Re: [PATCH] gnu: megacmd: Add mega-sdk as dependency.
Date: Sat, 05 Feb 2022 07:59:42 +0100

Am Samstag, dem 05.02.2022 um 03:05 +0000 schrieb Jaft:
> Hmm; perhaps a past installed caused things to build last time I
> tried this. I see what you mean, now.
Not necessarily.  As I said, Guix already has substitutes for the
source, so it will fetch them regardless.

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

Message #44 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Jaft <jaft.r <at> outlook.com>
To: "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>, 
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: [PATCH] gnu: megacmd: Add mega-sdk as dependency.
Date: Sun, 13 Feb 2022 08:34:18 +0000 (UTC)

> On Saturday, February 5, 2022, 12:59:47 AM CST, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote: 
>
>
>
>
>
> Am Samstag, dem 05.02.2022 um 03:05 +0000 schrieb Jaft:
> > 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.
> 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.

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?

Message #47 received at 52238 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Jaft <jaft.r <at> outlook.com>, "52238 <at> debbugs.gnu.org" <52238 <at> debbugs.gnu.org>
Subject: Re: [PATCH] gnu: megacmd: Add mega-sdk as dependency.
Date: Sun, 13 Feb 2022 09:42:52 +0100

Am Sonntag, dem 13.02.2022 um 08:34 +0000 schrieb Jaft:
> > On Saturday, February 5, 2022, 12:59:47 AM CST, Liliana Marie
> > Prikler <liliana.prikler <at> gmail.com> wrote: 
> > Am Samstag, dem 05.02.2022 um 03:05 +0000 schrieb Jaft:
> > > 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.
> > 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.
> 
> 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?
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.