On Tue, 23 Oct 2018 22:48:30 -0300 Laura Lazzati 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? 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 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. > 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? > 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. > 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? 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. > - 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. > 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. > 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