| Message ID | 20210701191514.8176-1-robin.roevens@disroot.org |
|---|---|
| Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4GG7Gm72C6z3wxc for <patchwork@web04.haj.ipfire.org>; Thu, 1 Jul 2021 19:16:00 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4GG7Gl476Pz15G; Thu, 1 Jul 2021 19:15:59 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4GG7Gl2ZHTz2yF0; Thu, 1 Jul 2021 19:15:59 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4GG7Gj4DMZz2xBf for <development@lists.ipfire.org>; Thu, 1 Jul 2021 19:15:57 +0000 (UTC) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPS id 4GG7Gh5tg1z1Tl for <development@lists.ipfire.org>; Thu, 1 Jul 2021 19:15:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 617D682408 for <development@lists.ipfire.org>; Thu, 1 Jul 2021 21:15:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XGvWLgvdxoE for <development@lists.ipfire.org>; Thu, 1 Jul 2021 21:15:55 +0200 (CEST) Received: from amaterasu.sicho.home ([192.168.0.1] helo=chojin.sicho.home) by filekeeper.sicho.home with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <robin.roevens@disroot.org>) id 1lz29d-0008SN-Jw for development@lists.ipfire.org; Thu, 01 Jul 2021 21:15:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1625166955; bh=s8rKkjfofncolYymlNL/Zmg8+2M0QCguenxIie4YgiM=; h=From:To:Subject:Date; b=JlvE12md8tlmwlyLDiimywL2jW+fD4la0OgGkrO5U1nilqsVJkxUBhgbznviXXrke zztmG+4l46dckss79zcdAvZDPu+z5hheqts5LUW3C5q69BFkSSb4GAbZ3Puono4Fq/ 8WUIwjLGE9CGUcUu4M1Moof3waLIrM1UiM+ffIYY9RqxDurBTyCIkZ8FERgS/kDuAi wTyFjkcfVDzfluEwY643wRD+UQVmLTo1LzBrR7gjtEfGD3R8C9fp/vhgxrZRpUvVt5 /d/rkjAQPbwk77bh4NI6XJpqT8ZD98sM+0Hr4WIcpFH823wUyzS5NpUsIk2VFVUVh2 OGrjhMwDSXbOw== From: Robin Roevens <robin.roevens@disroot.org> To: development@lists.ipfire.org Subject: [PATCH 0/2] buildprocess: additional pak metadata Date: Thu, 1 Jul 2021 21:15:12 +0200 Message-Id: <20210701191514.8176-1-robin.roevens@disroot.org> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-filekeeper-MailScanner-ID: 1lz29d-0008SN-Jw X-filekeeper-MailScanner: Found to be clean X-filekeeper-MailScanner-From: robin.roevens@disroot.org X-filekeeper-MailScanner-Watermark: 1625771723.99589@6yQTri5HhBhiikbS1wByuQ ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b=JlvE12md; spf=pass (mail01.ipfire.org: domain of robin.roevens@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=robin.roevens@disroot.org ARC-Seal: i=1; s=202003rsa; d=lists.ipfire.org; t=1625166956; a=rsa-sha256; cv=none; b=aMcEdOKSvgPo7MqSz2Kezqvx8zVfPBYmrHALOv7ErKqpUWhm5BUiBN1H1UQ1A1jPxtqiKJ AZ1NbTLvysEpCYiQRsxMdhjVaKRWfmDlgZBpu95YxudFwD58xVIlx9dDOfQBpxjxZN2T55 J5Ir0f+D80h9Q1r2dOvUO+KQk6VcEt4MRd2b5ILKg29iT8GS7Ivhvap71+EBM636mhoULu BS4JpEw9wr2mOryLMOT024kQ0+kgIug+XUZ/RV+xaB9+TjvrDKVm9R0tXnWl7GRbppAiWs ClK5xf4pGo/L0FUOMzaEdVLMUPfSE4XXwIj02JhriSSTto2657AiFE4udMFObA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1625166956; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=QLDukTJoujMrVOcUcV6/3RiJ+VT7KHe3vhU+gogPmUo=; b=RWVrN4v3aEc8Sw6EiCQUt80sk30ELTbIiHeKn5HDwxXtpINGuZP9b7HVVDhZ9r3J2rKkqQ yla/G9knNcfoVZGrlzEogT8B6tpy/uuK2AFeBYcgVXTrFqRxUSJVkbyycJPNqBbvJucnHg SnnH6IIWTMhuKqn/WDxF1bnPDF4IDPMc6c5hUqtn/Ux5cFQpMtVEa0Cr9Jpy4nhcLokIjd U6xQgp+Nku2v2r1H7JZ+Uhp2Wyo6MEomCdUAmQvue5LUbqMCa0Mfgd1Av4JOLowVUNzZwo QjdJrniuFy1xFDzDVn/aWnWngvLhg5NfQa9GhqHVcDPDpiCzPCHVncvxRxaHUg== X-Rspamd-Queue-Id: 4GG7Gh5tg1z1Tl Authentication-Results: mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b=JlvE12md; dmarc=pass (policy=quarantine) header.from=disroot.org; spf=pass (mail01.ipfire.org: domain of robin.roevens@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=robin.roevens@disroot.org X-Rspamd-Server: mail01.haj.ipfire.org X-Spamd-Result: default: False [2.48 / 11.00]; ARC_NA(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[disroot.org,quarantine]; R_DKIM_ALLOW(-0.20)[disroot.org:s=mail]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[development@lists.ipfire.org]; BROKEN_CONTENT_TYPE(1.50)[]; R_MISSING_CHARSET(2.50)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[disroot.org:+]; MX_GOOD(-0.01)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM(-1.00)[-1.000]; IP_REPUTATION_HAM(-1.01)[asn: 50673(-0.29), country: NL(-0.01), ip: 178.21.23.139(-0.71)]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:50673, ipnet:178.21.23.0/24, country:NL] X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
| Series |
buildprocess: additional pak metadata
|
|
Message
Robin Roevens
July 1, 2021, 7:15 p.m. UTC
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
Comments
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 > > >
Hello Robin, > On 12 Aug 2021, at 16:34, Robin Roevens <robin.roevens@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. >
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@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. > > > >
Hello, > On 12 Aug 2021, at 19:28, Robin Roevens <robin.roevens@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@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.
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@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@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. > > >
Hello, > On 13 Aug 2021, at 11:49, Robin Roevens <robin.roevens@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@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@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.