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 mailto: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:
- 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.
- 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