[bug#52238] [PATCH] gnu: Add MEGA SDK

[Jaft]

> On Saturday, December 18, 2021, 01:47:47 AM CST, Liliana Marie Prikler 
> <liliana.prikler@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@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
Description: Text Data

megacmd.patch
Description: Text Data