Re: [outreachy] Further steps

[Laura Lazzati <laura.lazzati.15@gmail.com>]

On Wed, Oct 24, 2018 at 4:01 AM Gábor Boskovits <boskovits@gmail.com> wrote:
>
> Hello Laura,
>
> Congratulations!
>
> Björn Höfling <bjoern.hoefling@bjoernhoefling.de> ezt írta (időpont:
> 2018. okt. 24., Sze, 7:17):
> >
> > On Tue, 23 Oct 2018 22:48:30 -0300
> > Laura Lazzati <laura.lazzati.15@gmail.com> wrote:
> >
> > > Hi all!
> > >
> > > I'm really happy that the patch worked :)
> > >
> > > Tomorrow -yet Tuesday here, I live in the past :P - I will close the
> > > in progress contribution.
> > >
> > > If you don't mind, I have some questions and need some feedback to go
> > > on.
> > >
> > > - As regards patches, for future ones:
> > >
> > > 1)Why my patch file (the one I sent) does not work applying it with
> > > git am in my local cloned repo? Do I need to create a new branch or
> > > something like that?
> >
>
> The last version you sent worked just fine for me. I could use git am
> without a problem. (I downloaded the attachment, and used git am on
> that)
> I used the current master, created a branch, then used git am to apply
> your patch. (I create a branch so that I don't touch master in my checkout,
> it should work without it)
>
> How was it failing for you?
I guess it was failing because of not branching. I pulled master,
branched, reset to a previous commit on the branch and am worked fine.
>
> > I think that was the problem. Here I already applied your patch and it
> > fails (On line 9 already because of the copyright header):
> >
> > ~/guix/wt/kde$ git log -1 | cat; git am ~/0001-gnu-Add-r-aspi.patch
> > commit c3ff36b4aa08caa8131b65a14caa03161b71e564
> > Author: Laura Lazzati <laura.lazzati.15@gmail.com>
> > Date:   Tue Oct 23 01:59:22 2018 -0300
> >
> >     gnu: Add r-aspi.
> >
> >     * gnu/packages/cran.scm (r-aspi): New variable.
> > Applying: gnu: Add r-aspi.
> > error: patch failed: gnu/packages/cran.scm:9
> > error: gnu/packages/cran.scm: patch does not apply
> > Patch failed at 0001 gnu: Add r-aspi.
> > hint: Use 'git am --show-current-patch' to see the failed patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
Yes, I was getting that error too.
> >
> > My workflow usually is to get the lastest master and then to create and
> > work on a branch for that, for example "wip-r-aspi". Then I can create
> > another branch "wip-r-aspi2" and go  again from there. Usually I have
> > too many of those branches and have to clean up from time to tome.
> >
>
> Yes, the workflow Björn described works for me as well :)
> I git you often have a lot of branches, as they are cheap,
> and help to organize work. I also have to clean them up from time
> to time. I also tend to have throwaway branches,  where I just experiment.
>
Great! I will apply it too :)
> >
> > > 2)Where can I read about how to set an appropriate commit log? (not
> > > running just git log to see how they were generated before)
> >
> > That's a bit hidden, but documented: In section "7.5 Submitting
> > Patches" there is a link to the GNU Coding Standards:
> >
> > https://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs
> >
> >
> > > 3) I added an eol with emacs editor, just as you mentioned. Could you
> > > send me your previous output about the error you were getting about
> > > that line break, if you still have it?
> >
> > I haven't looked into that broken patch. Gabor?
> >
>
> As we have those messages, you can have a look at the output yourself, just
> try to apply the inline patch from the mail. (You can download in mbox format
> from the debbugs interface)
>
> You will see an output similar to what Björn quoted above, except it will say:
> 'Corrupt patch at line 10' instead of 'patch does not apply'
>
> > > 4) I guess you already answered this one, but Is it ok to send patches
> > > attached to an email or is it strict to send them with git send-email
> > > when getting much more involved?
> >
> > It's OK. I think it comes more convenient when you have a long series
> > of patches, i.e. you add one package one its 20 dependencies, then you
> > get a series Patch[1/21]..., see the patch-tracker for examples. But
> > there are also some examples of people sending patches as attachments.
> >
>
> Yes, Björn is right here, it is easier to handle longer series with
> git send-email,
> but it is perfectly ok to send patches as attachments.
>
> >
> > > In the thread of mails, I have already asked you, but I would like to
> > > know how to continue from now on:
> > >
> > > I would like to go on contributing as much as possible up to November
> > > 6th (the deadline for applying for Outreachy).
> > > 1) Is it fine to go on packaging R packages that are not available
> > > yet, now that I know how to import them, modify them and the whole
> > > process?
> > > 2) Do you prefer another tasks to be done?
> >
> > I would say that R-packages is fine. Gabor do you see any specific
> > other tasks?
> >
>
> R-packages are fine for now.
>
> > If you have any other favourite packages, you can give them also a try.
> > It could just get more difficult, with more manual steps, other build
> > systems, dependencies to be packed first, code to be patched, etc.
> >
>
> Yes, this would also be good. Please tell us if you have any specific package
> in mind.
I guess I could package some more R packages, and then let me know
which ones you think are more convenient, or you find more appealing
for Guix.
>
> >
> > > - I would like to contribute even after November 6th since I like the
> > > project really much and the community made me feel really comfortable,
> > > that's why I kept saying thank you almost all the time.
> >
> > Of cause. Nice to hear.
> >
>
> Yes, nice to hear.
>
> > > Maybe after the deadline for applying for Outreachy, I could be
> > > participating - just some ideas that came into my mind:
> > > 1) reading all the documentation even more carefully, and learning
> > > even more about guix commands.
> > > 2) Getting much more involved with all the suggested tools that you
> > > use - I used vim in the past, for instance, so I'm learning emacs
> > > commands - and  I am  also learning new git commands, such as the ones
> > > that I had to use for the patches - or even install another hypervisor
> > > that is not VirtualBox. I played a little with KVM in the past, for
> > > example.
> > > 3) Go on playing with my VM with GuixSD.
> >
> > If you have guix on top of another distro on your real hardware: You
> > can just install qemu with guix. And you can try
> >
> > guix system vm-image my-system-configuration.scm
> >
> > That produces a QEMU image. Copy it out of your store into your home
> > directory, then it is read/write. and start it.
> >
>
> You can also try guix system vm, but that way the image is not writeable.
>
> > > I
> > > don't know, there are always many things to go on learning, and I will
> > > not have the pressure by then to have contributions to be done for
> > > Outreachy . And of course this are some ideas, so that's why I am
> > > asking you for suggestions, and what do you think about them.
> >
> >
> > Looking at Outreachy, you could try out all things with generations:
> >
> >  * guix package
> >  * guix pull
> >  * guix system
> >
> > See how they behave, how you can roll back, delete old generations,
> > garbage collect.
> >
> > You can also get more into environment and containers:
> >
> > guix environment, with "-C" or "--pure", with network "-N" or
> > "--shared" folders.
Ok, I'll take all this into account for later :)
> >
> > There is plenty of magic to be explored in Guix :-)
> >
> > Björn
>
> Best regards,
> g_bor

Best regards!
Laura