Hey Peter!

Thank you for the reply!  It is very helpful to get the feedback.

On Mar 24, 2022, at 4:52 AM, Peter Müller <peter.mueller@ipfire.org> wrote:

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@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.

Ugh!  I actually did not do this manually.  I started here:

git clone git://git.ipfire.org/ipfire-2.x.git    

git config sendemail.to development@lists.ipfire.org

sudo ./make.sh downloadsrc

sudo ./make.sh gettoolchain

sudo ./make.sh build

And so on!

I know had problems with the commit and `git send-email -1`.

So I think I know where the problem is/was.  I’ll dig the the Terminal Logs and report back!


Jon


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@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@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@ipfire.org>

Thanks, and best regards,
Peter Müller

-Michael

On 17 Mar 2022, at 17:06, Jon Murphy <jon.murphy@ipfire.org> wrote:

- this will not change the default editor `vim`

Signed-off-by: Jon Murphy <jon.murphy@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