diff mbox series

[bug#52238] gnu: Add MEGA SDK

Message ID DM6PR19MB2460B6C6C5A1E4B1E98CDEAE997B9@DM6PR19MB2460.namprd19.prod.outlook.com
State New
Headers show
Series [bug#52238] gnu: Add MEGA SDK | expand

Checks

Context Check Description
cbaines/comparison success View comparision
cbaines/git branch success View Git branch
cbaines/applying patch success View Laminar job
cbaines/issue success View issue

Commit Message

Wamm K. D Dec. 20, 2021, 1:58 a.m. UTC 
> 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.

Comments

Liliana Marie Prikler Dec. 20, 2021, 8:08 p.m. UTC | #1 
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
diff mbox series

Patch

* gnu/packages/sync.scm (megacmd): Use MEGA SDK
---
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 ce815ed5c7..1c75c3ca53 100644
--- a/gnu/packages/sync.scm
+++ b/gnu/packages/sync.scm
@@ -222,8 +222,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 +241,7 @@  (define-public megacmd
        ("curl" ,curl)
        ("freeimage" ,freeimage)
        ("gtest" ,googletest)
+       ("mega-sdk" ,mega-sdk)
        ("openssl" ,openssl)
        ("pcre" ,pcre)
        ("readline" ,readline)