Hi
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
* Add a Summary and Services field to the meta-* addon files. * Add an INSTALL_INITSCRIPTS macro that takes a space seperated list of initscripts to install. * I kept the original INSTALL_INITSCRIPT as a method to install individual initscripts for backwards compatibility and possible corner cases.
Signed-off-by: Robin Roevens robin.roevens@disroot.org --- lfs/Config | 11 ++++++++++- src/pakfire/meta | 2 ++ 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/lfs/Config b/lfs/Config index 7d98e303b..5f48b0f33 100644 --- a/lfs/Config +++ b/lfs/Config @@ -297,13 +297,16 @@ define PAK # Cleanup rm -rf $(DIR_TMP_PAK)
- # Create meta file + # Escape SUMMARY variable and create meta file + summaryEscaped=$$(sed 's/[&/]/\&/g' <<< "$(SUMMARY)"); \ sed \ -e "s/NAME/$(PROG)/g" \ + -e "s/SUMMARY/$$summaryEscaped/g" \ -e "s/VER/$(VER)/g" \ -e "s/RELEASE/$(PAK_VER)/g" \ -e "s/DEPS/$(DEPS)/g" \ -e "s/SIZE/$$(stat --format=%s /install/packages/$(PROG)-$(VER)-$(PAK_VER).ipfire)/g" \ + -e "s/SERVICES/$(SERVICES)/g" \ < /usr/src/src/pakfire/meta > /install/packages/meta-$(PROG) endef
@@ -311,6 +314,12 @@ define INSTALL_INITSCRIPT install -m 754 -v $(DIR_SRC)/src/initscripts/packages/$(1) /etc/rc.d/init.d/$(1) endef
+define INSTALL_INITSCRIPTS + for initscript in $(1); do \ + $(call INSTALL_INITSCRIPT,$$initscript) || exit 1; \ + done +endef + ifeq "$(BUILD_ARCH)" "$(filter $(BUILD_ARCH),aarch64 riscv64)" define UPDATE_AUTOMAKE for i in $$(find $(DIR_APP) -name config.guess -o -name config.sub); do \ diff --git a/src/pakfire/meta b/src/pakfire/meta index d97b2a0fa..08e7d53fb 100644 --- a/src/pakfire/meta +++ b/src/pakfire/meta @@ -1,6 +1,8 @@ Name: NAME +Summary: SUMMARY ProgVersion: VER Release: RELEASE Size: SIZE Dependencies: DEPS File: NAME-VER-RELEASE.ipfire +Services: SERVICES
It seems patch 2/2 of this set is rejected by the mailserver:
554 5.7.1 Rejected due to policy violation: Contains blacklisted URL.
For as far as I can see, the patch does not contain any URL's of any sort.
How should I proceed from here? Is there an alternative way to submit this patch-set? Or can it be checked what triggers this mailserver error ?
Regards Robin
Robin Roevens schreef op vr 25-06-2021 om 00:50 [+0200]:
Hi
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
Hello,
On 25 Jun 2021, at 00:04, Robin Roevens robin.roevens@disroot.org wrote:
It seems patch 2/2 of this set is rejected by the mailserver:
554 5.7.1 Rejected due to policy violation: Contains blacklisted URL.
Yes, our mail server seems to do that a lot recently.
For as far as I can see, the patch does not contain any URL's of any sort.
How should I proceed from here? Is there an alternative way to submit this patch-set? Or can it be checked what triggers this mailserver error ?
You have done the right thing by copying postmaster.
Peter and I had a brief discussion about this yesterday. Let’s see what he says after looking at some logs.
Best, -Michael
Regards Robin
Robin Roevens schreef op vr 25-06-2021 om 00:50 [+0200]:
Hi
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.
Hi Any news on this? Or should I try to submit the patch straight to git ? Or just have a bit more patience? (I will be on vacation starting tomorrow for about a month..so I won't be able to resubmit it then until next month) Robin Michael Tremer schreef op za 26-06-2021 om 13:09 [+0100]:
Hello,
On 25 Jun 2021, at 00:04, Robin Roevens robin.roevens@disroot.org wrote: It seems patch 2/2 of this set is rejected by the mailserver: 554 5.7.1 Rejected due to policy violation: Contains blacklisted URL.
Yes, our mail server seems to do that a lot recently.
For as far as I can see, the patch does not contain any URL's of anysort. How should I proceed from here? Is there an alternative way to submitthis patch-set? Or can it be checked what triggers this mailservererror ?
You have done the right thing by copying postmaster. Peter and I had a brief discussion about this yesterday. Let’s see what he says after looking at some logs. Best,-Michael
RegardsRobin Robin Roevens schreef op vr 25-06-2021 om 00:50 [+0200]:
Hi 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" tothe meta-file templates and introduces the new macro INSTALL_INITSCRIPTS accepting a space seperated list of initscripts to install to avoidduplicating the list of service initscripts. (Once in the new SERVICESmeta-data field and once by calling INSTALL_INITSCRIPT for each of them).The original INSTALL_INITSCRIPT macro is kept (and called by the newmacro) for corner cases where non-service initscripts need to be installed and for use by non-pak lfs files as they currently don't havea SERVICES variable. The second patch adds the new metadata for all pak's in theirrespectivelfs files. As I went over all pak lfs files, I did not encounter any corner caseshence all calls to INSTALL_INITSCRIPT are replaced by calls to the newINSTALL_INITSCRIPTS passing the SERVICES variable as argument.The only special case maybe worth mentioning is Icinga, where a serviceinitscript is installed by a make rule of the source. Hence no call toINSTALL_INITSCRIPT or INSTALL_INITSCRIPTS is required. But the serviceis 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 toactually do something with the new meta-data.Those changes will be posted shortly. Regards Robin
-- Dit bericht is gescanned op virussen en andere gevaarlijkeinhoud door MailScanner en lijkt schoon te zijn.
Hello Robin,
I raised this with Peter, but it looks he didn’t find time to have a look at it yet, or it is a bit more complicated than a one-liner.
Could you try to submit this again, and if it doesn’t work try sending them to my personal email address so that we can keep this going while you are away? I would like to keep the ball rolling…
Best, -Michael
On 1 Jul 2021, at 09:29, Robin Roevens robin.roevens@disroot.org wrote:
Hi
Any news on this? Or should I try to submit the patch straight to git ? Or just have a bit more patience? (I will be on vacation starting tomorrow for about a month..so I won't be able to resubmit it then until next month)
Robin
Michael Tremer schreef op za 26-06-2021 om 13:09 [+0100]:
Hello,
On 25 Jun 2021, at 00:04, Robin Roevens < robin.roevens@disroot.org
wrote:
It seems patch 2/2 of this set is rejected by the mailserver:
554 5.7.1 Rejected due to policy violation: Contains blacklisted URL.
Yes, our mail server seems to do that a lot recently.
For as far as I can see, the patch does not contain any URL's of any sort.
How should I proceed from here? Is there an alternative way to submit this patch-set? Or can it be checked what triggers this mailserver error ?
You have done the right thing by copying postmaster.
Peter and I had a brief discussion about this yesterday. Let’s see what he says after looking at some logs.
Best, -Michael
Regards Robin
Robin Roevens schreef op vr 25-06-2021 om 00:50 [+0200]:
Hi
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.
Hi Michael, Peter
I resubmitted the patch, and it now seemed to have just worked. It can be a bit confusing as I'm also in the CC of the patch, so I get the mail anyhow. But I see the patch both 1/2 and 2/2 appearing in patchwork now. I marked previous attempt as superseded in patchwork.
Looking forward to see my patches being accepted :-).
Regards Robin
Michael Tremer schreef op do 01-07-2021 om 09:31 [+0100]:
Hello Robin,
I raised this with Peter, but it looks he didn’t find time to have a look at it yet, or it is a bit more complicated than a one-liner.
Could you try to submit this again, and if it doesn’t work try sending them to my personal email address so that we can keep this going while you are away? I would like to keep the ball rolling…
Best, -Michael
On 1 Jul 2021, at 09:29, Robin Roevens robin.roevens@disroot.org wrote:
Hi
Any news on this? Or should I try to submit the patch straight to git ? Or just have a bit more patience? (I will be on vacation starting tomorrow for about a month..so I won't be able to resubmit it then until next month)
Robin
Michael Tremer schreef op za 26-06-2021 om 13:09 [+0100]:
Hello,
On 25 Jun 2021, at 00:04, Robin Roevens < robin.roevens@disroot.org
wrote:
It seems patch 2/2 of this set is rejected by the mailserver:
554 5.7.1 Rejected due to policy violation: Contains blacklisted URL.
Yes, our mail server seems to do that a lot recently.
For as far as I can see, the patch does not contain any URL's of any sort.
How should I proceed from here? Is there an alternative way to submit this patch-set? Or can it be checked what triggers this mailserver error ?
You have done the right thing by copying postmaster.
Peter and I had a brief discussion about this yesterday. Let’s see what he says after looking at some logs.
Best, -Michael
Regards Robin
Robin Roevens schreef op vr 25-06-2021 om 00:50 [+0200]:
Hi
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.
-
Michael Tremer -
Robin Roevens