Re: [outreachy] Further steps

[Gábor Boskovits]

Hello Laura,

Congratulations!

Björn Höfling <address@hidden> ezt írta (időpont:
2018. okt. 24., Sze, 7:17):
>
> On Tue, 23 Oct 2018 22:48:30 -0300
> Laura Lazzati <address@hidden> 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 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 <address@hidden>
> 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".
>
> 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.

>
> > 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 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.
>
> There is plenty of magic to be explored in Guix :-)
>
> Björn

Best regards,
g_bor