Hello, > On 13 Aug 2021, at 11:49, Robin Roevens wrote: > > Hi > > Michael Tremer schreef op vr 13-08-2021 om 10:18 [+0100]: >> Hello, >> >>> On 12 Aug 2021, at 19:28, Robin Roevens < >>> robin.roevens(a)disroot.org >>>> wrote: >>> >>> Hi Michael >>> >>> Michael Tremer schreef op do 12-08-2021 om 16:37 [+0100]: >>>> Hello Robin, >>>> >>>>> On 12 Aug 2021, at 16:34, Robin Roevens < >>>>> robin.roevens(a)disroot.org >>>>>> >>>>> wrote: >>>>> >>>>> Hi all >>>>> >>>>> Had anybody already had a chance to start reviewing this patch- >>>>> set >>>>> during my absence ? >>>> >>>> Did it make it on the list? I thought there were some outstanding >>>> emailing issues. >>> >>> Yes, it did the second try. Also recorded by patchwork: >>> https://patchwork.ipfire.org/project/ipfire/list/?series=2178 >>> >> >> Okay. It looks like I missed it then. No problem. >> >>>>> I also have changes to Pakfire in the pipeline to actually use >>>>> the >>>>> metadata provided by this set, but I'm waiting to submit those >>>>> patches >>>>> as they depend on the acceptance of this set (and on my >>>>> other patch "pakfire: implement function to parse meta files" >>>>> to >>>>> counter Jonathan's comments about de pakfire code quality which >>>>> I >>>>> originally duplicated in a previous prototype of the changes to >>>>> come.) >>>> >>>> We currently have a massive backlog of changes that are being >>>> merged. >>>> >>>> We are shipping massive core updates that become almost >>>> impossible to >>>> test and we have added loads of regressions that have not been >>>> resolved, or are being shipped months after they have been fixed. >>>> So >>>> I would like to spend more time on structuring changes and test, >>>> test, test! >>> >>> I understand. It's a bit unlucky that this patch then was not >>> applied >>> before all those changes, as those changes will probably require me >>> to >>> review my patch again against all changes made to pak's in the >>> meantime. >> >> What packages have changed? >> >> If a package has been dropped or so this won’t matter. There will be >> a merge conflict which will be trivial to solve. >> > Actually all LFS files for pak's are changed in my patch (198 at the > time of submitting my patch) by adding a SUMMARY and a SERVICES > variable to them. And where applicable the call to INSTALL_INITSCRIPT > was changed to INSTALL_INITSCRIPTS,$(SERVICES) . That should not cause any trouble I think. >>> So I'll try to keep an eye on when next core is submitted and then >>> review and resubmit my patchset. >> >> Arne is currently working on putting the next Core Update together. >> Now is the time to have things on the list for him to grab them. > Ok, I will then try to review my patch against master again this > evening.. Please rebase against “next”. -Michael > > Regards > Robin > >> >> -Michael >> >>> Regards >>> Robin >>> >>>> -Michael >>>> >>>>> Regards >>>>> >>>>> Robin >>>>> >>>>> Robin Roevens schreef op do 01-07-2021 om 21:15 [+0200]: >>>>>> Hi >>>>>> >>>>>> Second attemt to submit this patchset. Hoping the mailserver >>>>>> won't >>>>>> find >>>>>> malicious URLs in it. >>>>>> >>>>>> For completeness, the summary included in the first attempt: >>>>>> >>>>>> As discussed earlier, I hereby submit a patchset adding extra >>>>>> metadata >>>>>> to all pak's. >>>>>> >>>>>> First patch adds the new metadata fields "Summary" and >>>>>> "Services" >>>>>> to >>>>>> the >>>>>> meta-file templates and introduces the new macro >>>>>> INSTALL_INITSCRIPTS >>>>>> accepting a space seperated list of initscripts to install to >>>>>> avoid >>>>>> duplicating the list of service initscripts. (Once in the new >>>>>> SERVICES >>>>>> meta-data field and once by calling INSTALL_INITSCRIPT for >>>>>> each >>>>>> of >>>>>> them). >>>>>> The original INSTALL_INITSCRIPT macro is kept (and called by >>>>>> the >>>>>> new >>>>>> macro) for corner cases where non-service initscripts need to >>>>>> be >>>>>> installed and for use by non-pak lfs files as they currently >>>>>> don't >>>>>> have >>>>>> a SERVICES variable. >>>>>> >>>>>> The second patch adds the new metadata for all pak's in their >>>>>> respective >>>>>> lfs files. >>>>>> As I went over all pak lfs files, I did not encounter any >>>>>> corner >>>>>> cases >>>>>> hence all calls to INSTALL_INITSCRIPT are replaced by calls >>>>>> to >>>>>> the >>>>>> new >>>>>> INSTALL_INITSCRIPTS passing the SERVICES variable as >>>>>> argument. >>>>>> The only special case maybe worth mentioning is Icinga, where >>>>>> a >>>>>> service >>>>>> initscript is installed by a make rule of the source. Hence >>>>>> no >>>>>> call >>>>>> to >>>>>> INSTALL_INITSCRIPT or INSTALL_INITSCRIPTS is required. But >>>>>> the >>>>>> service >>>>>> is included in the SERVICES variable to have it recorded in >>>>>> the >>>>>> meta- >>>>>> file. >>>>>> >>>>>> This set does not yet contain changes in pakfire or >>>>>> services.cgi >>>>>> to >>>>>> actually do something with the new meta-data. >>>>>> Those changes will be posted shortly. >>>>>> >>>>>> Regards >>>>>> >>>>>> Robin >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dit bericht is gescanned op virussen en andere gevaarlijke >>>>> inhoud door MailScanner en lijkt schoon te zijn. >>>>> >>>> >>>> >>> >>> >>> -- >>> Dit bericht is gescanned op virussen en andere gevaarlijke >>> inhoud door MailScanner en lijkt schoon te zijn. >> >> >> > > > -- > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn.