[0/2] buildprocess: additional pak metadata

  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
  

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