From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/2] buildprocess: additional pak metadata
Date: Thu, 01 Jul 2021 09:31:40 +0100
Message-ID: <30A08081-1073-4ED1-BCDD-DE790E4C7931@ipfire.org>
In-Reply-To: <1b25db163f59f5f89796a05b7d97ab2098eb230d.camel@disroot.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5860931734483571953=="
List-Id: <development.lists.ipfire.org>

--===============5860931734483571953==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello Robin,

I raised this with Peter, but it looks he didn=E2=80=99t 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=E2=80=99t work try sendin=
g 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=E2=80=A6

Best,
-Michael

> On 1 Jul 2021, at 09:29, Robin Roevens <robin.roevens(a)disroot.org> wrote:
>=20
> Hi
>=20
> 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 a=
ble to resubmit it then until next month)
>=20
> Robin
>=20
> Michael Tremer schreef op za 26-06-2021 om 13:09 [+0100]:
>> Hello,
>>=20
>>> On 25 Jun 2021, at 00:04, Robin Roevens <
>>> robin.roevens(a)disroot.org
>>> > wrote:
>>>=20
>>> It seems patch 2/2 of this set is rejected by the mailserver:
>>>=20
>>> 554 5.7.1 Rejected due to policy violation: Contains blacklisted URL.
>>=20
>> Yes, our mail server seems to do that a lot recently.
>>=20
>>> For as far as I can see, the patch does not contain any URL's of any
>>> sort.
>>>=20
>>> 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 ?
>>=20
>> You have done the right thing by copying postmaster.
>>=20
>> Peter and I had a brief discussion about this yesterday. Let=E2=80=99s see=
 what he says after looking at some logs.
>>=20
>> Best,
>> -Michael
>>=20
>>>=20
>>> Regards
>>> Robin
>>>=20
>>> Robin Roevens schreef op vr 25-06-2021 om 00:50 [+0200]:
>>>> Hi
>>>>=20
>>>> As discussed earlier, I hereby submit a patchset adding extra metadata=20
>>>> to all pak's.
>>>>=20
>>>> First patch adds the new metadata fields "Summary" and "Services" to
>>>> the=20
>>>> meta-file templates and introduces the new macro INSTALL_INITSCRIPTS=20
>>>> 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=20
>>>> them).
>>>> The original INSTALL_INITSCRIPT macro is kept (and called by the new
>>>> macro) for corner cases where non-service initscripts need to be=20
>>>> installed and for use by non-pak lfs files as they currently don't have
>>>> a SERVICES variable.=20
>>>>=20
>>>> The second patch adds the new metadata for all pak's in their
>>>> respective
>>>> lfs files.=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Regards
>>>>=20
>>>> Robin
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> --=20
>>> Dit bericht is gescanned op virussen en andere gevaarlijke
>>> inhoud door MailScanner en lijkt schoon te zijn.
>>>=20
>>=20
>>=20
>=20
> --=20
> Dit bericht is gescanned op virussen en andere gevaarlijke=20
> inhoud door MailScanner en lijkt schoon te zijn.


--===============5860931734483571953==--