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

Previous Next

Full log

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

Previous Next

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