[PATCH 0/2] buildprocess: additional pak metadata

[PATCH 0/2] buildprocess: additional pak metadata

[Robin Roevens]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

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.

[PATCH 1/2] buildprocess: Add extra metadata to meta-* files

[Robin Roevens]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

* 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(a)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
-- 
2.31.1


-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Robin Roevens]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

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


-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

Hello,

> On 25 Jun 2021, at 00:04, Robin Roevens <robin.roevens(a)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.
> 

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3613 bytes --]

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(a)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(a)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.

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Robin Roevens]

[-- Attachment #1: Type: text/plain, Size: 4655 bytes --]

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(a)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(a)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.
> 
> 


-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.

[PATCH 0/2] buildprocess: additional pak metadata

[Robin Roevens]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

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.

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Robin Roevens]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

Hi all

Had anybody already had a chance to start reviewing this patch-set
during my absence ?

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

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.

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]

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.

> 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!

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

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Robin Roevens]

[-- Attachment #1: Type: text/plain, Size: 3976 bytes --]

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
> 
> > 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.
So I'll try to keep an eye on when next core is submitted and then
review and resubmit my patchset.

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.

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4558 bytes --]

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.

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

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

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Robin Roevens]

[-- Attachment #1: Type: text/plain, Size: 5692 bytes --]

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

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

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.

Re: [PATCH 0/2] buildprocess: additional pak metadata

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5615 bytes --]

Hello,

> On 13 Aug 2021, at 11:49, Robin Roevens <robin.roevens(a)disroot.org> 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.