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] pakfire: Fix small bug: wrong pak count on list
Date: Mon, 07 Feb 2022 10:46:56 +0000
Message-ID: <4B7CE67E-FCD8-46A8-B416-78D74C50E2EF@ipfire.org>
In-Reply-To: <f6cb78551c3c88a957ca2ac70c23d34ee0bfdc0d.camel@sicho.home>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7547617664745458553=="
List-Id: <development.lists.ipfire.org>
--===============7547617664745458553==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hello,
> On 31 Jan 2022, at 22:36, Robin Roevens <robin.roevens(a)disroot.org> wrote:
>=20
> Hi Peter, Michael, *
>=20
> No problem, good to know that my submissions are still in the running.
> I will try to poke a bit more in the future if I don't see much
> progress. :-)
>=20
> I will re-submit my last patch, where I add extra meta-data to all
> pak's, against current next, as the previous one was based on next of
> about half a year ago.
> As that patch touches all pak lfs files it is quite a big one and,
> until it is accepted and merged, it currently requires me to revise it
> every time a pak lfs file is changed in next.
> I will mark that previous patch as superseded in patchwork.
>=20
> An earlier patch "pakfire: implement function to parse meta files" is
> still accurate on current next but still needs review by others.
> It was a response on Jonatan's suggestion for a unique pakfire function
> to read meta-data (where the idea was approved by Michael
> here: https://lists.ipfire.org/pipermail/development/2021-May/010249.html
> )
>=20
> Any other previous patches should not be reviewed or merged for now.
> There where a few discussion around them which resulted in that meta-
> data patch and the meta-data-parse-function which lays the groundwork
> for upcoming patches/improvements to pakfire and services.cgi. (The
> whole idea was explained in
> https://lists.ipfire.org/pipermail/development/2021-April/010094.html
> )
> I'm not sure what status to give those old patches in patchwork for
> now, as they will be superseded after the above mentioned 2 patches are
> reviewed/merged.
>=20
> Also I noticed another patch of mine: "[v2] misc-progs: getipstat:
> Refactor + extend", which was already merged
> (https://lists.ipfire.org/pipermail/development/2021-May/010151.html),
> is still marked as new in patchwork. Should I proceed to mark it as
> Accepted?
Yes. Patchwork sometimes cannot track them properly and they won=E2=80=99t be=
updated automatically.
-Michael
>=20
> Regards
> Robin
>=20
> Peter M=C3=BCller schreef op ma 31-01-2022 om 17:43 [+0000]:
>> Hello Robin,
>> hello Michael,
>> hello *,
>>=20
>> there is no actual reason for this patch being ignored this whole
>> time at all.
>>=20
>> Given the - um - rather messy situation we have in Patchwork, I
>> simply did not
>> have time to clean this up yet. Therefore, it scrolled past page one,
>> and I
>> forgot about it. Zut alors. :-/
>>=20
>> @Robin: The patch is now included in my temporary branch for Core
>> Update 164
>> (
>> https://git.ipfire.org/?p=3Dpeople/pmueller/ipfire-2.x.git;a=3Dcommit;h=3D=
a0
>> 6a552ccf0cfcc0df0ebb04a5ba0346897aa42e).
>> I will go through the other patches of yours later this week. In
>> general, feel
>> free to poke at us once in a while to keep things moving. :-)
>>=20
>> @Arne: Please merge my temporary branch for Core Update 164 into
>> next, if this
>> is fine to you. It also contains some bug fixes I discovered the
>> other day.
>>=20
>> Thanks, and best regards,
>> Peter M=C3=BCller
>>=20
>>=20
>>> Hello Robin,
>>>=20
>>> Sorry for this. It is okay to end a reminder every once in a while.
>>>=20
>>> @Peter: Is there any reason this patch did not get merged, yet?
>>>=20
>>> -Michael
>>>=20
>>>> On 30 Jan 2022, at 21:13, Robin Roevens
>>>> <robin.roevens(a)disroot.org> wrote:
>>>>=20
>>>> Hi all
>>>>=20
>>>> I have been patiently waiting for quite some time now. But I'm
>>>> starting
>>>> to think my patches are silently forgotten? Or is there something
>>>> else
>>>> wrong? Are there some more procedures I have to follow, which I
>>>> didn't?
>>>>=20
>>>> This one in particular was reviewed and all, but never
>>>> implemented.
>>>>=20
>>>> Thanks
>>>> Robin
>>>>=20
>>>> Michael Tremer schreef op vr 16-07-2021 om 11:50 [+0100]:
>>>>> Thanks!
>>>>>=20
>>>>> Reviewed-by: Michael Tremer <michael.tremer(a)ipfire.org>
>>>>>=20
>>>>>> On 24 Jun 2021, at 23:07, Robin Roevens
>>>>>> <robin.roevens(a)disroot.org>
>>>>>> wrote:
>>>>>>=20
>>>>>> Fixes pakfire list installed/notinstalled command displaying
>>>>>> the
>>>>>> count of all available paks instead of the count of actual
>>>>>> installed
>>>>>> respectively not installed paks.
>>>>>>=20
>>>>>> Signed-off-by: Robin Roevens <robin.roevens(a)disroot.org>
>>>>>> ---
>>>>>> src/pakfire/lib/functions.pl | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>=20
>>>>>> diff --git a/src/pakfire/lib/functions.pl
>>>>>> b/src/pakfire/lib/functions.pl
>>>>>> index f9a19b60d..c15e54f94 100644
>>>>>> --- a/src/pakfire/lib/functions.pl
>>>>>> +++ b/src/pakfire/lib/functions.pl
>>>>>> @@ -512,13 +512,13 @@ sub dblist {
>>>>>> foreach $line (sort @db) {
>>>>>> next unless ($line =3D~ /.*;.*;.*;/ );
>>>>>> $use_color =3D "";
>>>>>> - $count++;
>>>>>> @templine =3D split(/\;/,$line);
>>>>>> if ("$filter" eq "notinstalled") {
>>>>>> next if ( -e
>>>>>> "$Conf::dbdir/installed/meta-$templine[0]" );
>>>>>> } elsif ("$filter" eq "installed") {
>>>>>> next unless ( -e
>>>>>> "$Conf::dbdir/installed/meta-$templine[0]" );
>>>>>> }
>>>>>> + $count++;
>>>>>> if ("$forweb" eq "forweb")
>>>>>> {
>>>>>> if ("$filter" eq
>>>>>> "notinstalled") {
>>>>>> --=20
>>>>>> 2.31.1
>>>>>>=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
>>>> inhoud door MailScanner en lijkt schoon te zijn.
>>>>=20
>>>=20
>>=20
>=20
> --=20
> Dit bericht is gescanned op virussen en andere gevaarlijke
> inhoud door MailScanner en lijkt schoon te zijn.
>=20
--===============7547617664745458553==--