From mboxrd@z Thu Jan  1 00:00:00 1970
From: Robin Roevens <robin.roevens@disroot.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/2] buildprocess: additional pak metadata
Date: Thu, 01 Jul 2021 21:31:09 +0200
Message-ID: <08e584126866f381e253ebb70c9070028b251ec4.camel@disroot.org>
In-Reply-To: <30A08081-1073-4ED1-BCDD-DE790E4C7931@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5908741397131238005=="
List-Id: <development.lists.ipfire.org>

--===============5908741397131238005==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

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.


--===============5908741397131238005==--