GNU bug report logs -
#52238
[PATCH] gnu: Add MEGA SDK
Previous Next
Full log
View this message in rfc822 format
[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)]
This bug report was last modified 3 years and 220 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.