Re: [PATCH] Nano: Move nano editor from packages to core system

["Peter Müller" <peter.mueller@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 8049 bytes --]

Hello Jon,

thanks for your reply.

> Hey Peter!
> 
> This is my first patch so I am looking to learn!  (See below)

No worries, everybody starts from the very beginning (loosely translated from the German phrase
"jeder fängt mal an", which one sometimes gets to hear in hacker- or makerspaces). My first patch
attempts were quite bumpy too. :-)

>> On Mar 21, 2022, at 2:06 PM, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>
>> Hello *,
>>
>> I just merged this patch into next, but since it was generated manually, I had to do
>> the changes introduced by it myself manually.
> 
> Did I create the patch incorrectly?  Is there something I can do differently?

To me, it looks like you created this patch manually. You don't have to do that, and
there are two common scenarios:

1. You work on something that is in a Git repository

   In this case, just edit the file in question, and do a commit by running "git commit -vs [path
   to the changed file]". Then, an editor will open, giving you the possibility to write down
   the title and description of the soon-to-become patch.

   Afterwards, run "git format-patch -1" to output that commit in a patch format. The command
   will create a text file, containing the commit and some additional metadata.

   Some IPFire people like to use "git send-email" for submitting their patches to the mailing
   list. Personally, I prefer to past the contents of the file "git format-patch" has created
   into my MUA, adjust some metadata if necessary, and send it manually from there to the list.

2. You work on something that is not in a Git repository

   This happens, for example, if you want to create a patch for a piece of software IPFire
   uses (such as my zlib patch I submitted earlier). Often, this is necessary if there is a bug
   or security vulnerability in a 3rd party software, but it has not been fixed upstream, or did
   not made it into a release of that software. In the latter case, updating the software would
   be sufficient.

   In this case, you will have to obtain the software - for example, from your local ~/cache/
   directory where IPFire keeps the tarballs -, and unpack it twice to different folders. Keep
   one folder unchanged, and make your changes in the other one.

   (Some people append ".orig" or ".org" to the unchanged folder name, to indicate this one was
   not being changed.)

   Afterwards, run "diff -Naur [unchanged folder] [changed folder]", which will give you the
   difference between these two folders in a format "patch" can parse. Save the output of that
   command to a new patch file in the ~/src/patches directory, and append a "patch" command to
   the LFS file of the software.

   The only thing left to do now is to bring this patch upstream, which is basically scenario 1,
   as your local copy of IPFire's source code is a Git repository. Treat the newly created patch
   file like any other changes, and follow the procedure above to create a patch for including
   the patch. :-)

I mention the second scenario just for the sake of completeness, since it becomes necessary sooner
or later. In your case, the first scenario is completely sufficient:

- You would go into your local copy of IPFire 2.x's source code.

- Delete the lines from the lfs/nano file, and run "git add lfs/nano" to stage it.

- By running "git mv config/rootfiles/packages/nano config/rootfiles/common/nano", you would move
  nano's rootfile to the core system, simultaneously telling Git to keep track of this change.

- Run "git commit -vs" and write your patch title and description.

- Afterwards, submit the patch, either via "git send-email" or by a MUA.

That's it. :-)

>>> Hello,
>>>
>>> I personally do not count nano as an editor. There are so many things wrong with it :)
>>>
>>> But if everyone wants this, I do not think that shipping ~444 KB of code will break the camel’s back.
>>
>> Certainly not.
>>
>>>
>>> Acked-by: Michael Tremer <michael.tremer(a)ipfire.org>
>>>
>>> -Michael
>>>
>>> P.S. @Peter: Would you please make sure that pakfire drops the metadata of the package?
> 
> Same with this question - Is there something I can do differently?

Not really, because when you submit a patch, you normally do not know for sure which Core Update
it will go into. If you want to be nice to the person responsible of the Core Update, add a short
notice to the patch description saying what needs to be done to ship this patch in an update.

For package updates, and anything that just needs to be shipped, this seldomly needed. If an
extra step is required during an update, such as removing Pakfire metadata in your case, mentioning
that can never hurt to ensure it does not get forgotten.

>> Yes.
>>
>> Thanks, and best regards,
>> Peter Müller

Hope my descriptions above were helpful. Just drop me a line if there is anything unclear, or
I should have elaborated more detailed on a certain step.

> 
> Thank you!
> Jon
> 
>>
>>>
>>>> On 21 Mar 2022, at 17:49, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> On 21/03/2022 17:22, Peter Müller wrote:
>>>>> Hello *,
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> How is everybody feeling about this?
>>>>> I understand the motivation behind this. In my early days, I completely lacked any vim
>>>>> skills, and found it pretty stressing to bring things back up after a crash while at the
>>>>> same time frantically thinking "how to %&§#$ deal with this text editor?!".
>>>>>
>>>>>> How many nano users do we have here?
>>>> I am definitely one. I also use nano for working on my Arch Linux systems and adjust the default editor for things like visudo so it uses nano.
>>>>
>>>>
>>>> Regards,
>>>> Adolf.
>>>>> Back then, nano would have helped me. Today, I am used to vim and would not experience
>>>>> any benefit from nano being around on IPFire as well.
>>>>>
>>>>> Nevertheless, I vote in favour of this patch, for reasons mentioned above.
>>>>>
>>>>> Acked-by: Peter Müller <peter.mueller(a)ipfire.org>
>>>>>
>>>>> Thanks, and best regards,
>>>>> Peter Müller
>>>>>
>>>>>> -Michael
>>>>>>
>>>>>>> On 17 Mar 2022, at 17:06, Jon Murphy <jon.murphy(a)ipfire.org> wrote:
>>>>>>>
>>>>>>> - this will not change the default editor `vim`
>>>>>>>
>>>>>>> Signed-off-by: Jon Murphy <jon.murphy(a)ipfire.org>
>>>>>>> ---
>>>>>>> config/rootfiles/{packages => common}/nano | 0
>>>>>>> lfs/nano                                   | 7 +++----
>>>>>>> 2 files changed, 3 insertions(+), 4 deletions(-)
>>>>>>> rename config/rootfiles/{packages => common}/nano (100%)

This was completely right. While applying your patch manually, braindead me moved the rootfile
to the "core" folder instead of "common". I fixed that later in commit 5a33fd9bc6123e9073ecb0976c72d4be4e4f8b5e.
Everybody starts from the very beginning. :-)

>>>>>>>
>>>>>>> diff --git a/config/rootfiles/packages/nano b/config/rootfiles/common/nano
>>>>>>> similarity index 100%
>>>>>>> rename from config/rootfiles/packages/nano
>>>>>>> rename to config/rootfiles/common/nano
>>>>>>> diff --git a/lfs/nano b/lfs/nano
>>>>>>> index df994364f..85be014ee 100644
>>>>>>> --- a/lfs/nano
>>>>>>> +++ b/lfs/nano
>>>>>>> @@ -32,12 +32,11 @@ DL_FILE    = $(THISAPP).tar.xz
>>>>>>> DL_FROM    = $(URL_IPFIRE)
>>>>>>> DIR_APP    = $(DIR_SRC)/$(THISAPP)
>>>>>>> TARGET     = $(DIR_INFO)/$(THISAPP)
>>>>>>> -PROG       = nano
>>>>>>> -PAK_VER    = 4

Here, it becomes clear that this was created manually. "diff" would have inserted a minus
sign as well, since the blank lines were also deleted. 

>>>>>>>
>>>>>>> -DEPS       = ""
>>>>>>>

Same as above.

All the best,
Peter Müller

>>>>>>> -SERVICES   =
>>>>>>>
>>>>>>> ###############################################################################
>>>>>>> # Top-level Rules
>>>>>>> -- 
>>>>>>> 2.30.2
>>>>>>>
>>>>
>>>> -- 
>>>> Sent from my laptop
>>>
>