From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Few questions concerning creating addon package Date: Sun, 28 Mar 2021 22:21:38 +0200 Message-ID: <57aabff1-0bb4-3539-2f98-3f50e9ef920e@ipfire.org> In-Reply-To: <4f10e4300d701818619a24eab7e3314e9e9ab98d.camel@filekeeper.sicho.home> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4630088699363090347==" List-Id: --===============4630088699363090347== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Robin, On 28/03/2021 20:29, Robin Roevens wrote: > Hi all > > Firstly, thank you Adolf for the encouragement and extra pointers to > start this task.. > I think I have currently successfully prepared a new version of the > zabbix_agentd package containing latest zabbix_agentd LTS version > (v5.0.9). > > I tested the package on an ipfire-test-vm instance set up with the iso > built by the make.sh script and then manually unpacking the package > using the instructions of > https://wiki.ipfire.org/devel/ipfire-2-x/addon-howto and all seems well > except that the service is not automatically started during install.sh > which calls: > --- > restore_backup ${NAME} > start_service --background ${NAME} > --- > So I'm assuming ${NAME} is not available when I manually run install.sh > as per instructions, and that it will be available when pakfire itself > installs the package? That is correct in both cases. > Is there a way to test the actual package deployment using pakfire ? When I am testing a package what I do is run the following commands first:- NAME=3D"zabbix_agentd" export NAME That then sets $NAME to your package name and should make all commands that u= se $NAME work successfully. Hopefully that will also help you. > Then I have a few other questions: > - In the LFS template there is a PAK_VER variable, and it is not clear > to me what this exactly is. Is this a revision number for current > packaged version?=C2=A0or just a 'counter' for how many package versions > there have been for this program in IPFire ? In IPFire 2.x it is used as a continuously incrementing counter so you should= set it one higher than the previous version. It never resets. (That is diffe= rent to what the aim is for IPFire 3 but that is still under development). > - In the LFS template for current zabbix_agentd v4.2.6 DL_FROM is > pointing to URL_IPFIRE.. Should this be changed ? Or should I upload > the new source-file for v5.0.9 to URL_IPFIRE in some way ? (are there > instructions somewhere?) or ..? Leave that as it is and when you run ./make.sh downloadsrc if it completes su= ccessfully then it means that the new version you are using was successfully = downloaded by the IPFire source system. IPFire keeps a copy on their system o= f all source tarballs in case the original versions have a problem. > Then a more practical question: > Next to 'just' an upgrade of the current Zabbix agent I also added a > few config files etc for use with my Zabbix IPFire specific monitoring > template. This changes Alexander's original config a little, but should > remain backwards compatible. > Should I submit this as 2 separate patches or will a single patch > suffice? I think the core devs prefer changes separated but it depends, they would be = best to comment on that. I think it depends on how closely integrated the changes are. You can do them= as a single patch, you can do them as a series of patches [PATCH 1/2] and [P= ATCH 2/2] or as completely separate patches. To me it sounds like probably a = series would make sense. For a series do a git commit -s on the changed files that make up your core c= hange and then do a second git commit -s on the additional changed files. The= n do a git format-patch -o ..... command and it will create two patch files 0= 001.... and 0002.... from the two commits. Hopefully that is clear enough. I would also say that if you make your best effort with your submission you w= ill get feedback on if you should have done it differently but it will be fri= endly constructive feedback. I have had that sort of feedback myself and it h= as always been an opportunity to learn and do better the following time. I look forwards to seeing your update successfully getting into Core Update 1= 56. Regards, Adolf Belka > Regards > Robin > > > > --===============4630088699363090347==--