> On Saturday, December 18, 2021, 01:47:47 AM CST, Liliana Marie Prikler 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.