Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Charalampos Stratakis]

> I spent most of yesterday repairing a rawhide VM that had a bad upgrade,
> resulting in dnf segfaulting and making the machine difficult to fix.
> Had to build a second rawhide VM as a baseline to guide a manual
> download and install of affected RPMs.  Very not happy, and I would
> advise more testing before making it official.

Managed to destroy one of my own rawhide VM's that had automatic updates
enabled till I figured out how to workaround, so for anyone interested.

Hadn't rebooted for some time and when I tried to do a distro-sync I was
getting:

> Problem 1: problem with installed package
python3-slip-dbus-0.6.4-29.fc38.noarch
 >  - package python3-slip-dbus-0.6.4-29.fc38.noarch from @System requires
python(abi) = 3.11, but none of the providers can be installed
 >  - package python3-slip-dbus-0.6.4-29.fc38.noarch from rawhide requires
python(abi) = 3.11, but none of the providers can be installed
 >  - python3-3.11.3-1.fc39.ppc64le from @System  does not belong to a
distupgrade repository
 > Problem 2: problem with installed package
python3-slip-0.6.4-29.fc38.noarch
 > - package python3-slip-0.6.4-29.fc38.noarch from @System requires
python(abi) = 3.11, but none of the providers can be installed
 > - package python3-slip-0.6.4-29.fc38.noarch from rawhide requires
python(abi) = 3.11, but none of the providers can be installed
 > - package python3-3.11.3-1.fc39.ppc64le from @System requires
python3-libs(ppc-64) = 3.11.3-1.fc39, but none of the providers can be
installed
 > - python3-libs-3.11.3-1.fc39.ppc64le from @System  does not belong to a
distupgrade repository
> (try to add '--skip-broken' to skip uninstallable packages)

Hence removed python3-slip and python3-slip-dbus. After that I got a
segfault when trying to distro-sync. Consistent with 2 other rawhide VM's,
the same thing happened.

My system had sqlite-3.42.0-7.fc39 and rpm-4.18.1-3.fc39 so I grabbed from
koji the sqlite-3.41.2-3.fc39
 version
(which was also dependent on the python3.11 abi) and installed it with:

$ sudo rpm -Uvh --oldpackage sqlite-3.41.2-3.fc39.ppc64le.rpm
sqlite-libs-3.41.2-3.fc39.ppc64le.rpm sqlite-devel-3.41.2-3.fc39.ppc64le.rpm

Then dnf didn't segfault anymore and I could distro-sync, getting the
latest python3.12, latest dnf etc.

-- 
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Jens Petersen]

> I've been actually using dnf5 daily and while it's a little rough
> around the edges it seems usable enough.

I agree, I would like to see dnf5 staying in rawhide.
Otherwise I don't think it will receive sufficient testing.

> (1) The allow_vendor_change option makes things strange.  I think this
> feature should be turned off (ie True) until it is fixed properly.
> https://github.com/rpm-software-management/dnf5/issues/722

(I believe this happened upstream already. :)

Jens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 12:38 PM Neal Gompa  wrote:
>
> On Wed, Jul 19, 2023 at 6:11 AM Peter Robinson  wrote:
> >
> > On Wed, Jul 19, 2023 at 10:21 AM Jaroslav Mracek  wrote:
> > >
> > > > On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek 
> > > >  > > >
> > > > Does that mean the issues with dnf [2] we able to be solved all the
> > > > time but just weren't investigated?
> > >
> > > The issue was investigated also with DNF, but the issue was well hidden, 
> > > because the code uses hard coded set for downloaded elements. For most 
> > > investigation we used the biggest repository (Fedora) that showed a high 
> > > memory usage and we tried to mitigate what can we do to improve the 
> > > situation. The real issue was with update repository that surprisingly 
> > > uses slightly more RAM then fedora repository.
> > >
> > > With DNF5 we reinvest it as a completely different issue. DNF5 has a 
> > > better option for investigation that allow us to discover the real source 
> > > of the issue. We knew that DNF5 fixed RAM usage for `fedora` repository 
> > > therefore we continued to search in other directions. Basically we were 
> > > surprised why we got the report with DNF5 because we know that RAM usage 
> > > was  improved with DNF5 and default setting. It means that there where 
> > > two issues that overlaps with symptoms but has a different reproducers. 
> > > Solving the first one (too big metadata to process) uncover the second 
> > > issue with processing updateinfo metadata.
> > >
> > > The status of the issue - We have to wait until our patch is reviewed and 
> > > merged in libsolv and we have to wait until libsolv creates the upstream 
> > > release, because downstream of libsolv in Fedora is not under DNF team 
> > > control and the main admin doesn't like any downstream patches.
> >
> > Looking at upstream releases it seems they don't release often, in the
> > last 18 months there's been 4 releases anywhere between a month and 9
> > months apart.
> >
> > I don't see how it's feasible to sit around and tell users "I'm sorry,
> > you have to wait until upstream bothers to release before you can have
> > a fix to enable you to update your system" when there is a fix
> > available. Can you please explain that to me? It is entirely
> > reasonable to pull in a fix that is headed upstream to fix a key
> > problem in a key distro component so that it doesn't remain broken for
> > MONTHS!
>
> I agree. But the reason releases don't get made is that libsolv
> doesn't have a set schedule, and I can just ask upstream to make a
> release and they probably will.
>
> If the fix is already merged upstream, it's reasonable enough to
> backport. What we want to avoid is non-upstream patches, because this
> component is critical enough that we don't want that burden.

I agree with not having long term non upstream patches but at the same
time patches that are upstream or headed upstream to make things work
I think is a reasonable compromise.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Neal Gompa]

On Wed, Jul 19, 2023 at 6:11 AM Peter Robinson  wrote:
>
> On Wed, Jul 19, 2023 at 10:21 AM Jaroslav Mracek  wrote:
> >
> > > On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek  > > wrote:
> > >
> > > Does that mean the issues with dnf [2] we able to be solved all the
> > > time but just weren't investigated?
> >
> > The issue was investigated also with DNF, but the issue was well hidden, 
> > because the code uses hard coded set for downloaded elements. For most 
> > investigation we used the biggest repository (Fedora) that showed a high 
> > memory usage and we tried to mitigate what can we do to improve the 
> > situation. The real issue was with update repository that surprisingly uses 
> > slightly more RAM then fedora repository.
> >
> > With DNF5 we reinvest it as a completely different issue. DNF5 has a better 
> > option for investigation that allow us to discover the real source of the 
> > issue. We knew that DNF5 fixed RAM usage for `fedora` repository therefore 
> > we continued to search in other directions. Basically we were surprised why 
> > we got the report with DNF5 because we know that RAM usage was  improved 
> > with DNF5 and default setting. It means that there where two issues that 
> > overlaps with symptoms but has a different reproducers. Solving the first 
> > one (too big metadata to process) uncover the second issue with processing 
> > updateinfo metadata.
> >
> > The status of the issue - We have to wait until our patch is reviewed and 
> > merged in libsolv and we have to wait until libsolv creates the upstream 
> > release, because downstream of libsolv in Fedora is not under DNF team 
> > control and the main admin doesn't like any downstream patches.
>
> Looking at upstream releases it seems they don't release often, in the
> last 18 months there's been 4 releases anywhere between a month and 9
> months apart.
>
> I don't see how it's feasible to sit around and tell users "I'm sorry,
> you have to wait until upstream bothers to release before you can have
> a fix to enable you to update your system" when there is a fix
> available. Can you please explain that to me? It is entirely
> reasonable to pull in a fix that is headed upstream to fix a key
> problem in a key distro component so that it doesn't remain broken for
> MONTHS!

I agree. But the reason releases don't get made is that libsolv
doesn't have a set schedule, and I can just ask upstream to make a
release and they probably will.

If the fix is already merged upstream, it's reasonable enough to
backport. What we want to avoid is non-upstream patches, because this
component is critical enough that we don't want that burden.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 10:21 AM Jaroslav Mracek  wrote:
>
> > On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek  > wrote:
> >
> > Does that mean the issues with dnf [2] we able to be solved all the
> > time but just weren't investigated?
>
> The issue was investigated also with DNF, but the issue was well hidden, 
> because the code uses hard coded set for downloaded elements. For most 
> investigation we used the biggest repository (Fedora) that showed a high 
> memory usage and we tried to mitigate what can we do to improve the 
> situation. The real issue was with update repository that surprisingly uses 
> slightly more RAM then fedora repository.
>
> With DNF5 we reinvest it as a completely different issue. DNF5 has a better 
> option for investigation that allow us to discover the real source of the 
> issue. We knew that DNF5 fixed RAM usage for `fedora` repository therefore we 
> continued to search in other directions. Basically we were surprised why we 
> got the report with DNF5 because we know that RAM usage was  improved with 
> DNF5 and default setting. It means that there where two issues that overlaps 
> with symptoms but has a different reproducers. Solving the first one (too big 
> metadata to process) uncover the second issue with processing updateinfo 
> metadata.
>
> The status of the issue - We have to wait until our patch is reviewed and 
> merged in libsolv and we have to wait until libsolv creates the upstream 
> release, because downstream of libsolv in Fedora is not under DNF team 
> control and the main admin doesn't like any downstream patches.

Looking at upstream releases it seems they don't release often, in the
last 18 months there's been 4 releases anywhere between a month and 9
months apart.

I don't see how it's feasible to sit around and tell users "I'm sorry,
you have to wait until upstream bothers to release before you can have
a fix to enable you to update your system" when there is a fix
available. Can you please explain that to me? It is entirely
reasonable to pull in a fix that is headed upstream to fix a key
problem in a key distro component so that it doesn't remain broken for
MONTHS!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Jaroslav Mracek]

> On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek  wrote:
> 
> Does that mean the issues with dnf [2] we able to be solved all the
> time but just weren't investigated?

The issue was investigated also with DNF, but the issue was well hidden, 
because the code uses hard coded set for downloaded elements. For most 
investigation we used the biggest repository (Fedora) that showed a high memory 
usage and we tried to mitigate what can we do to improve the situation. The 
real issue was with update repository that surprisingly uses slightly more RAM 
then fedora repository. 

With DNF5 we reinvest it as a completely different issue. DNF5 has a better 
option for investigation that allow us to discover the real source of the 
issue. We knew that DNF5 fixed RAM usage for `fedora` repository therefore we 
continued to search in other directions. Basically we were surprised why we got 
the report with DNF5 because we know that RAM usage was  improved with DNF5 and 
default setting. It means that there where two issues that overlaps with 
symptoms but has a different reproducers. Solving the first one (too big 
metadata to process) uncover the second issue with processing updateinfo 
metadata.

The status of the issue - We have to wait until our patch is reviewed and 
merged in libsolv and we have to wait until libsolv creates the upstream 
release, because downstream of libsolv in Fedora is not under DNF team control 
and the main admin doesn't like any downstream patches.

Best regards

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Wed, Jul 19, 2023 at 6:23 AM Jaroslav Mracek  wrote:
>
> > On Mon, Jul 17, 2023 at 6:40 AM Jaroslav Mracek  > wrote:
> >
> > Except dnf5 broke a number of microdnf usecases with low memory where
> > microdnf worked [1].
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2214520
>
> Correct but as you can see the issue was not in DNF5 but in libsolv (solver 
> for DNF, DNF5, zypper, PackageKit). Ales Matej from DNF team prepared two 
> patches - one to resolve the issue in libsolv and second to enable workaround 
> for DNF5. Thanks to better DNF5 structure we were able to discover the real 
> cause of the issue.

Does that mean the issues with dnf [2] we able to be solved all the
time but just weren't investigated?

> Therefore I am curios why the issue is mentioned here?

Because the issues, while quite probably now known, still aren't
resolved in F-38 where it was meant to be stable for those usecases
from the release of F-38. This in turn gives me little confidence in
the rest of dnf5 being ready to replace the much larger set of
usecases as implemented by dnf4 by the Change Completion [3] deadline
in less than 3 weeks time.

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1907030
[3] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Jaroslav Mracek]

> On 7/17/23 07:39, Jaroslav Mracek wrote:
> 
> Hi, I put more details in the fesco ticket: 
> https://pagure.io/fesco/issue/3039#comment-864686 I believe these are 
> commonly known so I did not open any ticket against dnf5.
> 
> As said in the comment, I stopped putting effort into making dnf5 work 
> for our use case (which is provisioning of multiple distributions for 
> upstream PR CI via ansible), we would certainly hit more issues - or 
> unimplemented functionality if you want to sugar coat it - that would 
> require workarounds.

I have a great news dnf5-5.1.0-1.fc39 is in stable. The version 5.1 is the 
first version with stable API.

Best regards

Jarda
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Jaroslav Mracek]

> On Mon, Jul 17, 2023 at 6:40 AM Jaroslav Mracek  wrote:
> 
> Except dnf5 broke a number of microdnf usecases with low memory where
> microdnf worked [1].
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2214520

Correct but as you can see the issue was not in DNF5 but in libsolv (solver for 
DNF, DNF5, zypper, PackageKit). Ales Matej from DNF team prepared two patches - 
one to resolve the issue in libsolv and second to enable workaround for DNF5. 
Thanks to better DNF5 structure we were able to discover the real cause of the 
issue.

Therefore I am curios why the issue is mentioned here?

Best regards

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Jaroslav Mracek]

> On 7/13/23 23:59, Fabio Valentini wrote:
> 
> +1 for postponing. We have hit issues preparing CI environment via 
> ansible and applying workarounds to make dnf5 work is imho not the way 
> to go with such core tool. It should be there as opt-in so it can get 
> tested but not default.

The problem is that ansible uses a different release cycle then Fedora. DNF5 is 
already in Fedora 38 and not only for testing, but also as a replacement of 
microdnf.

Please check the list of reported issue and you will find that a lot of issues 
are currently resolved.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Jaroslav Mracek]

Hello,

> We keep the list of issues tracked here:
> https://github.com/rpm-software-management/mock/issues/894
> And namely, https://github.com/rpm-software-management/dnf5/issues/617
> seems like a showstopper ATM.  At least as long as we have to check
> GPG signatures at koji buildroot installation time.

The issue https://github.com/rpm-software-management/dnf5/issues/617 is under 
development and we will handle it as a priority issue.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Kevin Fenzi]

On Mon, Jul 17, 2023 at 01:37:35PM +0200, Pavel Raiskup wrote:
> 
> As I understand how DNF5 team works, they keep updating DNF5 quickly
> enough even in Fedora 38 (but the 'dnf -> dnf-3' exists, instead of
> 'dnf -> dnf5').
> 
> I'm a bit lost in the minor numbers; and Mirek is right, not all the
> missing features are actually important from the Koji perspective (e.g.
> forcearch).
> 
> We keep the list of issues tracked here:
> https://github.com/rpm-software-management/mock/issues/894
> And namely, https://github.com/rpm-software-management/dnf5/issues/617
> seems like a showstopper ATM.  At least as long as we have to check
> GPG signatures at koji buildroot installation time.

We don't in koji, but developers do on local mockbuilds.

> Otherwise, Mock 4.1+ on Fedora 38 *host* (or in container) should just
> work fine with fedora rawhide chroots and package_manager=dnf5.  Don't
> forget to `mock -r fedora-rawhide-x86_64 --scrub=bootstrap` first,
> because the root_cache tarball for bootstrap has the installed DNF4
> packages, not DNF5, from previous calls.

We could try this out in staging, I don't think we want to push anything
into prod right now since the mass rebuild starts wed.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Pavel Březina]

On 7/17/23 07:39, Jaroslav Mracek wrote:

Hello Pavel,

May I ask you to be more specific what is the problem with including 
references for issues? I am not sure whether your issues are related to 
issues referenced by Fabio or whether you have in mind something else. 
It will help us to prioritize the work.


Hi, I put more details in the fesco ticket: 
https://pagure.io/fesco/issue/3039#comment-864686 I believe these are 
commonly known so I did not open any ticket against dnf5.


As said in the comment, I stopped putting effort into making dnf5 work 
for our use case (which is provisioning of multiple distributions for 
upstream PR CI via ansible), we would certainly hit more issues - or 
unimplemented functionality if you want to sugar coat it - that would 
require workarounds.




On Fri, Jul 14, 2023 at 10:50 AM Pavel Březina > wrote:


On 7/13/23 23:59, Fabio Valentini wrote:
 > Hi all,
 >
 > I'm opening this thread to trigger discussion of the roadmap for DNF5
 > in Fedora 39 - whether the switch still looks doable for this
release,
 > or whether it should be reverted for F39 and postponed to F40.

+1 for postponing. We have hit issues preparing CI environment via
ansible and applying workarounds to make dnf5 work is imho not the way
to go with such core tool. It should be there as opt-in so it can get
tested but not default.


DNF5 was released in Fedora 38 where it replaced microdnf, therefore it 
was possible to test it in Fedora 38


Best regards

Jaroslav


 > This is also being tracked in a FESCo ticket:
 > https://pagure.io/fesco/issue/3039

 >
 > The DNF5 Change was approved with the condition that bits that are
 > important to the distribution *MUST* work, but this does not seem to
 > be the case yet, six months after this was initially approved -
 > there's at least a few things that are still using dnf-3 or have been
 > broken since the switch to dnf5:
 >
 > - rawhide mock / koji builds still default to dnf-3 (DNF 4)
 > - Fedora CI has been partially broken since the switch to DNF5 (c.f.
 >
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416) 
),
 > making CI results for bodhi updates at least partially useless
 > - fedora-review has been broken since the switch to DNF5 (c.f.
 > [FedoraReview#482](FedoraReview/issue/482)), which is really hurting
 > the rate at which new packages are getting reviewed and added to
 > Fedora
 > - (not an exhaustive list, feel free to mention other things, I will
 > update the list to include them)
 >
 > We are now mere days before the Fedora 39 mass rebuild is
scheduled to
 > start, so I think it's time to start talking about the roadmap for
 > getting missing pieces into place for Fedora 39, or if that is not
 > possible within this timeframe, whether the contingency mechanism
 > should be enacted.
 >
 > Fabio
 > ___
 > devel mailing list -- devel@lists.fedoraproject.org

 > To unsubscribe send an email to
devel-le...@lists.fedoraproject.org

 > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

 > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines

 > List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 

 > Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org

To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 

Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue



___
devel mailing 

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Pavel Raiskup]

On pátek 14. července 2023 14:30:03 CEST Miroslav Suchý wrote:
> Dne 14. 07. 23 v 2:11 Kevin Fenzi napsal(a):
> > On Fri, Jul 14, 2023 at 12:26:27AM +0200, Miroslav Suchý wrote:
> >> Dne 13. 07. 23 v 23:59 Fabio Valentini napsal(a):
> >>> - rawhide mock / koji builds still default to dnf-3 (DNF 4)
> >> Support for DNF5 landed in Mock
> >>
> >> https://rpm-software-management.github.io/mock/Release-Notes-4.0
> >>
> >> In the meantime 4.1 was released.
> >>
> >> I hope that in week or two we release 4.2 and we can set
> >>
> >> config_opts['package_manager'] = 'dnf5'
> >>
> >> for fedora-rawhide config. I have just created
> >> https://github.com/rpm-software-management/mock/issues/1147
> >>
> >> Of course, Koji admins can do that independently in their configs.
> > Sure, but... our builders are Fedora 38.
> > Is the dnf5 in f38 expected to be ready to do bootstrap chroots?
> > Or only the rawhide one?
> 
> Hmm,
> 
> F39 has dnf5-5.0.15-4.fc39 
> 
> 
> F38 has dnf5-5.0.13-2.fc38 
> 
> 
> and there are some important changes (like module enable or forcearch) but 
> not sure if Koji will need this. Mock uses it 
> in some scenarions.

As I understand how DNF5 team works, they keep updating DNF5 quickly
enough even in Fedora 38 (but the 'dnf -> dnf-3' exists, instead of
'dnf -> dnf5').

I'm a bit lost in the minor numbers; and Mirek is right, not all the
missing features are actually important from the Koji perspective (e.g.
forcearch).

We keep the list of issues tracked here:
https://github.com/rpm-software-management/mock/issues/894
And namely, https://github.com/rpm-software-management/dnf5/issues/617
seems like a showstopper ATM.  At least as long as we have to check
GPG signatures at koji buildroot installation time.

Otherwise, Mock 4.1+ on Fedora 38 *host* (or in container) should just
work fine with fedora rawhide chroots and package_manager=dnf5.  Don't
forget to `mock -r fedora-rawhide-x86_64 --scrub=bootstrap` first,
because the root_cache tarball for bootstrap has the installed DNF4
packages, not DNF5, from previous calls.

Pavel





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Peter Robinson]

On Mon, Jul 17, 2023 at 6:40 AM Jaroslav Mracek  wrote:
>
> Hello Pavel,
>
> May I ask you to be more specific what is the problem with including 
> references for issues? I am not sure whether your issues are related to 
> issues referenced by Fabio or whether you have in mind something else. It 
> will help us to prioritize the work.
>
> On Fri, Jul 14, 2023 at 10:50 AM Pavel Březina  wrote:
>>
>> On 7/13/23 23:59, Fabio Valentini wrote:
>> > Hi all,
>> >
>> > I'm opening this thread to trigger discussion of the roadmap for DNF5
>> > in Fedora 39 - whether the switch still looks doable for this release,
>> > or whether it should be reverted for F39 and postponed to F40.
>>
>> +1 for postponing. We have hit issues preparing CI environment via
>> ansible and applying workarounds to make dnf5 work is imho not the way
>> to go with such core tool. It should be there as opt-in so it can get
>> tested but not default.
>
>
> DNF5 was released in Fedora 38 where it replaced microdnf, therefore it was 
> possible to test it in Fedora 38

Except dnf5 broke a number of microdnf usecases with low memory where
microdnf worked [1].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2214520

> Best regards
>
> Jaroslav
>
>>
>>
>> > This is also being tracked in a FESCo ticket:
>> > https://pagure.io/fesco/issue/3039
>> >
>> > The DNF5 Change was approved with the condition that bits that are
>> > important to the distribution *MUST* work, but this does not seem to
>> > be the case yet, six months after this was initially approved -
>> > there's at least a few things that are still using dnf-3 or have been
>> > broken since the switch to dnf5:
>> >
>> > - rawhide mock / koji builds still default to dnf-3 (DNF 4)
>> > - Fedora CI has been partially broken since the switch to DNF5 (c.f.
>> > [fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
>> > making CI results for bodhi updates at least partially useless
>> > - fedora-review has been broken since the switch to DNF5 (c.f.
>> > [FedoraReview#482](FedoraReview/issue/482)), which is really hurting
>> > the rate at which new packages are getting reviewed and added to
>> > Fedora
>> > - (not an exhaustive list, feel free to mention other things, I will
>> > update the list to include them)
>> >
>> > We are now mere days before the Fedora 39 mass rebuild is scheduled to
>> > start, so I think it's time to start talking about the roadmap for
>> > getting missing pieces into place for Fedora 39, or if that is not
>> > possible within this timeframe, whether the contingency mechanism
>> > should be enacted.
>> >
>> > Fabio
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct: 
>> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives: 
>> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> > Do not reply to spam, report it: 
>> > https://pagure.io/fedora-infrastructure/new_issue
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Jaroslav Mracek]

Hello Pavel,

May I ask you to be more specific what is the problem with including
references for issues? I am not sure whether your issues are related to
issues referenced by Fabio or whether you have in mind something else. It
will help us to prioritize the work.

On Fri, Jul 14, 2023 at 10:50 AM Pavel Březina  wrote:

> On 7/13/23 23:59, Fabio Valentini wrote:
> > Hi all,
> >
> > I'm opening this thread to trigger discussion of the roadmap for DNF5
> > in Fedora 39 - whether the switch still looks doable for this release,
> > or whether it should be reverted for F39 and postponed to F40.
>
> +1 for postponing. We have hit issues preparing CI environment via
> ansible and applying workarounds to make dnf5 work is imho not the way
> to go with such core tool. It should be there as opt-in so it can get
> tested but not default.
>

DNF5 was released in Fedora 38 where it replaced microdnf, therefore it was
possible to test it in Fedora 38

Best regards

Jaroslav


>
> > This is also being tracked in a FESCo ticket:
> > https://pagure.io/fesco/issue/3039
> >
> > The DNF5 Change was approved with the condition that bits that are
> > important to the distribution *MUST* work, but this does not seem to
> > be the case yet, six months after this was initially approved -
> > there's at least a few things that are still using dnf-3 or have been
> > broken since the switch to dnf5:
> >
> > - rawhide mock / koji builds still default to dnf-3 (DNF 4)
> > - Fedora CI has been partially broken since the switch to DNF5 (c.f.
> > [fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
> > making CI results for bodhi updates at least partially useless
> > - fedora-review has been broken since the switch to DNF5 (c.f.
> > [FedoraReview#482](FedoraReview/issue/482)), which is really hurting
> > the rate at which new packages are getting reviewed and added to
> > Fedora
> > - (not an exhaustive list, feel free to mention other things, I will
> > update the list to include them)
> >
> > We are now mere days before the Fedora 39 mass rebuild is scheduled to
> > start, so I think it's time to start talking about the roadmap for
> > getting missing pieces into place for Fedora 39, or if that is not
> > possible within this timeframe, whether the contingency mechanism
> > should be enacted.
> >
> > Fabio
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Richard W.M. Jones]

I've been actually using dnf5 daily and while it's a little rough
around the edges it seems usable enough.

Here are some notes ...

(1) The allow_vendor_change option makes things strange.  I think this
feature should be turned off (ie True) until it is fixed properly.

https://github.com/rpm-software-management/dnf5/issues/722

Also dnf downgrade seems broken, probably related to this.

(2) Current bugs that stop fedora-review or mock from working:

https://bugzilla.redhat.com/show_bug.cgi?id=2217496
https://bugzilla.redhat.com/show_bug.cgi?id=2217496#c5

(3) [superficial] I don't like the update summary that it prints as
much as the old dnf one.  The dnf5 one lacks "==" to delineate the
headers from the list.

Also the actual transaction lines are clipped so you cannot see the
full versions, eg:

[ 3/20] Upgrading nbdkit-server-0:1.35. 100% |   6.8 MiB/s | 228.4 KiB |  00m00s
[ 4/20] Upgrading nbdkit-basic-filters- 100% |  31.2 MiB/s | 831.8 KiB |  00m00s
[ 5/20] Upgrading nbdkit-basic-plugins- 100% |  32.5 MiB/s | 532.1 KiB |  00m00s
...
[12/20] Erasing nbdkit-0:1.34.1-1.fc38. 100% |  16.3 KiB/s | 100.0   B |  00m00s
[13/20] Erasing nbdkit-basic-filters-0: 100% |  14.2 KiB/s | 145.0   B |  00m00s
[14/20] Erasing nbdkit-basic-plugins-0: 100% |   8.9 KiB/s |  64.0   B |  00m00s

(4) It's a lot faster, great!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Miroslav Suchý]

Dne 14. 07. 23 v 2:11 Kevin Fenzi napsal(a):

On Fri, Jul 14, 2023 at 12:26:27AM +0200, Miroslav Suchý wrote:

Dne 13. 07. 23 v 23:59 Fabio Valentini napsal(a):

- rawhide mock / koji builds still default to dnf-3 (DNF 4)

Support for DNF5 landed in Mock

https://rpm-software-management.github.io/mock/Release-Notes-4.0

In the meantime 4.1 was released.

I hope that in week or two we release 4.2 and we can set

config_opts['package_manager'] = 'dnf5'

for fedora-rawhide config. I have just created
https://github.com/rpm-software-management/mock/issues/1147

Of course, Koji admins can do that independently in their configs.

Sure, but... our builders are Fedora 38.
Is the dnf5 in f38 expected to be ready to do bootstrap chroots?
Or only the rawhide one?


Hmm,

F39 has dnf5-5.0.15-4.fc39 


F38 has dnf5-5.0.13-2.fc38 


and there are some important changes (like module enable or forcearch) but not sure if Koji will need this. Mock uses it 
in some scenarions.


Miroslav

--

Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Vít Ondruch]

Since DNF5 was forced upon me as a Rawhide user, I'd prefer to keep it 
this way and actually rename DNF5 back to DNF to have e.g. man pages 
correctly available.



Vít


Dne 13. 07. 23 v 23:59 Fabio Valentini napsal(a):

Hi all,

I'm opening this thread to trigger discussion of the roadmap for DNF5
in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.

This is also being tracked in a FESCo ticket:
https://pagure.io/fesco/issue/3039

The DNF5 Change was approved with the condition that bits that are
important to the distribution *MUST* work, but this does not seem to
be the case yet, six months after this was initially approved -
there's at least a few things that are still using dnf-3 or have been
broken since the switch to dnf5:

- rawhide mock / koji builds still default to dnf-3 (DNF 4)
- Fedora CI has been partially broken since the switch to DNF5 (c.f.
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
making CI results for bodhi updates at least partially useless
- fedora-review has been broken since the switch to DNF5 (c.f.
[FedoraReview#482](FedoraReview/issue/482)), which is really hurting
the rate at which new packages are getting reviewed and added to
Fedora
- (not an exhaustive list, feel free to mention other things, I will
update the list to include them)

We are now mere days before the Fedora 39 mass rebuild is scheduled to
start, so I think it's time to start talking about the roadmap for
getting missing pieces into place for Fedora 39, or if that is not
possible within this timeframe, whether the contingency mechanism
should be enacted.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Pavel Březina]

On 7/13/23 23:59, Fabio Valentini wrote:

Hi all,

I'm opening this thread to trigger discussion of the roadmap for DNF5
in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.


+1 for postponing. We have hit issues preparing CI environment via 
ansible and applying workarounds to make dnf5 work is imho not the way 
to go with such core tool. It should be there as opt-in so it can get 
tested but not default.



This is also being tracked in a FESCo ticket:
https://pagure.io/fesco/issue/3039

The DNF5 Change was approved with the condition that bits that are
important to the distribution *MUST* work, but this does not seem to
be the case yet, six months after this was initially approved -
there's at least a few things that are still using dnf-3 or have been
broken since the switch to dnf5:

- rawhide mock / koji builds still default to dnf-3 (DNF 4)
- Fedora CI has been partially broken since the switch to DNF5 (c.f.
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
making CI results for bodhi updates at least partially useless
- fedora-review has been broken since the switch to DNF5 (c.f.
[FedoraReview#482](FedoraReview/issue/482)), which is really hurting
the rate at which new packages are getting reviewed and added to
Fedora
- (not an exhaustive list, feel free to mention other things, I will
update the list to include them)

We are now mere days before the Fedora 39 mass rebuild is scheduled to
start, so I think it's time to start talking about the roadmap for
getting missing pieces into place for Fedora 39, or if that is not
possible within this timeframe, whether the contingency mechanism
should be enacted.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Adam Williamson]

On Fri, 2023-07-14 at 10:25 +0900, Mamoru TASAKA wrote:
> DJ Delorie wrote on 2023/07/14 9:13:
> > Fabio Valentini  writes:
> > > in Fedora 39 - whether the switch still looks doable for this release,
> > > or whether it should be reverted for F39 and postponed to F40.
> > 
> > I spent most of yesterday repairing a rawhide VM that had a bad upgrade,
> > resulting in dnf segfaulting and making the machine difficult to fix.
> > Had to build a second rawhide VM as a baseline to guide a manual
> > download and install of affected RPMs.  Very not happy, and I would
> > advise more testing before making it official.
> > 
> > #0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
> > Downloading 0.00 MB source file 
> > /usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/string/../sysdeps/x86_64/multiarch/strlen-sse2.S
> > 142 movdqu  (%rax), %xmm4
> > (gdb) where
> > #0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
> > #1  0x7fc9d36614e8 in __printf_buffer (buf=buf@entry=0x7ffe8ca81350, 
> > format=0x7fc9c5160293 "%s: %s: %s\n", ap=0x7ffe8ca81460, mode_flags=2) at 
> > /usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/stdio-common/vfprintf-process-arg.c:435
> > #2  0x7fc9d3682106 in __vsnprintf_internal (string=string@entry=0x0, 
> > maxlen=maxlen@entry=0, format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", 
> > args=args@entry=0x7ffe8ca81460, mode_flags=mode_flags@entry=2) at 
> > vsnprintf.c:96
> > #3  0x7fc9d3724922 in ___vsnprintf_chk (s=s@entry=0x0, 
> > maxlen=maxlen@entry=0, flag=flag@entry=2, 
> > slen=slen@entry=18446744073709551615, format=format@entry=0x7fc9c5160293 
> > "%s: %s: %s\n", ap=ap@entry=0x7ffe8ca81460) at vsnprintf_chk.c:34
> > #4  0x7fc9c50d66ae in vsnprintf (__ap=0x7ffe8ca81460, 
> > __fmt=0x7fc9c5160293 "%s: %s: %s\n", __n=0, __s=0x0) at 
> > /usr/include/bits/stdio2.h:68
> > #5  rpmlog (code=4, fmt=0x7fc9c5160293 "%s: %s: %s\n") at 
> > /usr/src/debug/rpm-4.18.0-11.fc39.x86_64/rpmio/rpmlog.c:446
> > #6  0x7fc9c4f811b1 in renderLogMsg (iErrCode=283, zFormat= > out>, ap=ap@entry=0x7ffe8ca816a0) at 
> > /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31531
> > #7  0x7fc9c4f81294 in sqlite3_log (iErrCode=, 
> > zFormat=) at 
> > /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31542
> 
> 
> 
> Just note that sqlite was downgraded from sqlite-3.42.0-1.fc39 to 
> sqlite-3.41.2-3.fc39 on 2023/Jun/23
> due to this issue (without bumping epoch).
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2219084
> 
> (I have not tried dnf5 myself yet as currently I am using Fedora 38.)

It was not exactly downgraded. 3.42.0 was tagged and then untagged
without ever making a compose:
https://pagure.io/releng/issue/11497

The bug in rpm was then fixed later, in 4.18.91-6.fc39:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-81ae8f677d

and so we re-tagged 3.42.0. If you still have crashes with rpm-4.18.91-
6 or later and sqlite-3.42.0, this is a problem and needs fixing. So
far this isn't a bug in dnf, though.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Mamoru TASAKA]

DJ Delorie wrote on 2023/07/14 9:13:

Fabio Valentini  writes:

in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.


I spent most of yesterday repairing a rawhide VM that had a bad upgrade,
resulting in dnf segfaulting and making the machine difficult to fix.
Had to build a second rawhide VM as a baseline to guide a manual
download and install of affected RPMs.  Very not happy, and I would
advise more testing before making it official.

#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
Downloading 0.00 MB source file 
/usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/string/../sysdeps/x86_64/multiarch/strlen-sse2.S
142 movdqu  (%rax), %xmm4
(gdb) where
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
#1  0x7fc9d36614e8 in __printf_buffer (buf=buf@entry=0x7ffe8ca81350, 
format=0x7fc9c5160293 "%s: %s: %s\n", ap=0x7ffe8ca81460, mode_flags=2) at 
/usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/stdio-common/vfprintf-process-arg.c:435
#2  0x7fc9d3682106 in __vsnprintf_internal (string=string@entry=0x0, 
maxlen=maxlen@entry=0, format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", 
args=args@entry=0x7ffe8ca81460, mode_flags=mode_flags@entry=2) at vsnprintf.c:96
#3  0x7fc9d3724922 in ___vsnprintf_chk (s=s@entry=0x0, maxlen=maxlen@entry=0, 
flag=flag@entry=2, slen=slen@entry=18446744073709551615, 
format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", ap=ap@entry=0x7ffe8ca81460) 
at vsnprintf_chk.c:34
#4  0x7fc9c50d66ae in vsnprintf (__ap=0x7ffe8ca81460, __fmt=0x7fc9c5160293 "%s: 
%s: %s\n", __n=0, __s=0x0) at /usr/include/bits/stdio2.h:68
#5  rpmlog (code=4, fmt=0x7fc9c5160293 "%s: %s: %s\n") at 
/usr/src/debug/rpm-4.18.0-11.fc39.x86_64/rpmio/rpmlog.c:446
#6  0x7fc9c4f811b1 in renderLogMsg (iErrCode=283, zFormat=, 
ap=ap@entry=0x7ffe8ca816a0) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31531
#7  0x7fc9c4f81294 in sqlite3_log (iErrCode=, 
zFormat=) at /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31542




Just note that sqlite was downgraded from sqlite-3.42.0-1.fc39 to 
sqlite-3.41.2-3.fc39 on 2023/Jun/23
due to this issue (without bumping epoch).
https://koji.fedoraproject.org/koji/buildinfo?buildID=2219084

(I have not tried dnf5 myself yet as currently I am using Fedora 38.)

Regards,
Mamoru
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[DJ Delorie]

Fabio Valentini  writes:
> in Fedora 39 - whether the switch still looks doable for this release,
> or whether it should be reverted for F39 and postponed to F40.

I spent most of yesterday repairing a rawhide VM that had a bad upgrade,
resulting in dnf segfaulting and making the machine difficult to fix.
Had to build a second rawhide VM as a baseline to guide a manual
download and install of affected RPMs.  Very not happy, and I would
advise more testing before making it official.

#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
Downloading 0.00 MB source file 
/usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/string/../sysdeps/x86_64/multiarch/strlen-sse2.S
142 movdqu  (%rax), %xmm4
(gdb) where
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
#1  0x7fc9d36614e8 in __printf_buffer (buf=buf@entry=0x7ffe8ca81350, 
format=0x7fc9c5160293 "%s: %s: %s\n", ap=0x7ffe8ca81460, mode_flags=2) at 
/usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/stdio-common/vfprintf-process-arg.c:435
#2  0x7fc9d3682106 in __vsnprintf_internal (string=string@entry=0x0, 
maxlen=maxlen@entry=0, format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", 
args=args@entry=0x7ffe8ca81460, mode_flags=mode_flags@entry=2) at vsnprintf.c:96
#3  0x7fc9d3724922 in ___vsnprintf_chk (s=s@entry=0x0, 
maxlen=maxlen@entry=0, flag=flag@entry=2, slen=slen@entry=18446744073709551615, 
format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", ap=ap@entry=0x7ffe8ca81460) 
at vsnprintf_chk.c:34
#4  0x7fc9c50d66ae in vsnprintf (__ap=0x7ffe8ca81460, __fmt=0x7fc9c5160293 
"%s: %s: %s\n", __n=0, __s=0x0) at /usr/include/bits/stdio2.h:68
#5  rpmlog (code=4, fmt=0x7fc9c5160293 "%s: %s: %s\n") at 
/usr/src/debug/rpm-4.18.0-11.fc39.x86_64/rpmio/rpmlog.c:446
#6  0x7fc9c4f811b1 in renderLogMsg (iErrCode=283, zFormat=, 
ap=ap@entry=0x7ffe8ca816a0) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31531
#7  0x7fc9c4f81294 in sqlite3_log (iErrCode=, 
zFormat=) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31542
#8  0x7fc9c4f91887 in walIndexRecover (pWal=0x563fa87849c8) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:64936
#9  walIndexReadHdr (pWal=pWal@entry=0x563fa87849c8, 
pChanged=pChanged@entry=0x7ffe8ca8195c) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:422
#10 0x7fc9c4f91edb in walTryBeginRead (pWal=pWal@entry=0x563fa87849c8, 
pChanged=pChanged@entry=0x7ffe8ca8195c, useWal=useWal@entry=0, cnt=cnt@entry=1) 
at /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:66260
#11 0x7fc9c4f931cc in sqlite3WalBeginReadTransaction 
(pChanged=0x7ffe8ca8195c, pWal=0x563fa87849c8) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:66554
#12 pagerBeginReadTransaction (pPager=0x563fa8b75098) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:58955
#13 sqlite3PagerSharedLock (pPager=0x563fa8b75098) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:61124
#14 0x7fc9c4f98ef8 in lockBtree (pBt=0x563fa893ab28) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:71967
#15 sqlite3BtreeBeginTrans (p=0x563fa88f5b88, wrflag=0, pSchemaVersion=0x0) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:6823
#16 0x7fc9c4ff410a in sqlite3InitOne (db=0x563fa88f5d18, iDb=iDb@entry=0, 
pzErrMsg=pzErrMsg@entry=0x7ffe8ca82878, mFlags=mFlags@entry=0) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:138178
#17 0x7fc9c4ff487c in sqlite3Init (db=db@entry=0x563fa88f5d18, 
pzErrMsg=pzErrMsg@entry=0x7ffe8ca82878) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:138372
#18 0x7fc9c4ff48cf in sqlite3ReadSchema (pParse=0x7ffe8ca82870) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:138398
#19 0x7fc9c4feca53 in sqlite3Pragma (pParse=0x7ffe8ca82870, pId1=, pId2=0x7ffe8ca81ee0, pValue=, minusFlag=) 
at /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:135486
#20 0x7fc9c5086335 in yy_reduce.isra.0 (yypParser=0x7ffe8ca81e80, 
yyruleno=250, yyLookaheadToken=..., pParse=0x7ffe8ca82870, 
yyLookahead=) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:172382
#21 0x7fc9c501fd2d in sqlite3Parser (yyminor=, 
yymajor=, yyp=0x7ffe8ca81e80) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:173016
#22 sqlite3RunParser (pParse=, zSql=) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:43244
#23 0x7fc9c4ff3895 in sqlite3Prepare (db=db@entry=0x563fa88f5d18, 
zSql=zSql@entry=0x7fc9c5715eae "PRAGMA journal_mode = WAL; PRAGMA foreign_keys 
= ON;", nBytes=nBytes@entry=-1, prepFlags=prepFlags@entry=128, 
pReprepare=pReprepare@entry=0x0, ppStmt=ppStmt@entry=0x7ffe8ca82b38, 
pzTail=0x7ffe8ca82b40)
at /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:138700
#24 0x7fc9c4ff49f0 in sqlite3LockAndPrepare (pzTail=0x7ffe8ca82b40, 
ppStmt=0x7ffe8ca82b38, pOld=0x0, prepFlags=128, nBytes=-1, zSql=0x7fc9c5715eae 
"PRAGMA journal_mode = WAL; PRAGMA foreign_keys = ON;", db=0x563fa88f5d18) at 

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Kevin Fenzi]

On Fri, Jul 14, 2023 at 12:26:27AM +0200, Miroslav Suchý wrote:
> Dne 13. 07. 23 v 23:59 Fabio Valentini napsal(a):
> > - rawhide mock / koji builds still default to dnf-3 (DNF 4)
> 
> Support for DNF5 landed in Mock
> 
> https://rpm-software-management.github.io/mock/Release-Notes-4.0
> 
> In the meantime 4.1 was released.
> 
> I hope that in week or two we release 4.2 and we can set
> 
> config_opts['package_manager'] = 'dnf5'
> 
> for fedora-rawhide config. I have just created
> https://github.com/rpm-software-management/mock/issues/1147
> 
> Of course, Koji admins can do that independently in their configs.

Sure, but... our builders are Fedora 38.
Is the dnf5 in f38 expected to be ready to do bootstrap chroots?
Or only the rawhide one?

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Chris Adams]

Once upon a time, Adam Williamson  said:
> The biggest one for me is that offline updating - `dnf offline-upgrade`
> - still isn't implemented on dnf5. But I've run into quite a lot of
> smaller 'paper cuts', like `dnf history info ` doesn't
> work...just today I found that installing an older kernel doesn't work
> (older dnf does this just fine)...there are quite a lot of these at
> https://github.com/rpm-software-management/dnf5/issues .

I recently ran into a bug with dnf where reposync and repomanage don't
agree on what "new" means, filed a bug against RHEL 9 (where I ran into
it), and the response was that it wouldn't be fixed but it would be kept
in mind when developing that functionality for dnf5.  So from that, and
a quick look at the dnf5 packages in F38, I guess neither has been
implemented yet.

I use that in several places to keep local copies of repos, so that
missing is a problem for me.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Adam Williamson]

On Thu, 2023-07-13 at 23:59 +0200, Fabio Valentini wrote:
> Hi all,
> 
> I'm opening this thread to trigger discussion of the roadmap for DNF5
> in Fedora 39 - whether the switch still looks doable for this release,
> or whether it should be reverted for F39 and postponed to F40.
> 
> This is also being tracked in a FESCo ticket:
> https://pagure.io/fesco/issue/3039
> 
> The DNF5 Change was approved with the condition that bits that are
> important to the distribution *MUST* work, but this does not seem to
> be the case yet, six months after this was initially approved -
> there's at least a few things that are still using dnf-3 or have been
> broken since the switch to dnf5:
> 
> - rawhide mock / koji builds still default to dnf-3 (DNF 4)
> - Fedora CI has been partially broken since the switch to DNF5 (c.f.
> [fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
> making CI results for bodhi updates at least partially useless
> - fedora-review has been broken since the switch to DNF5 (c.f.
> [FedoraReview#482](FedoraReview/issue/482)), which is really hurting
> the rate at which new packages are getting reviewed and added to
> Fedora
> - (not an exhaustive list, feel free to mention other things, I will
> update the list to include them)
> 
> We are now mere days before the Fedora 39 mass rebuild is scheduled to
> start, so I think it's time to start talking about the roadmap for
> getting missing pieces into place for Fedora 39, or if that is not
> possible within this timeframe, whether the contingency mechanism
> should be enacted.

The biggest one for me is that offline updating - `dnf offline-upgrade`
- still isn't implemented on dnf5. But I've run into quite a lot of
smaller 'paper cuts', like `dnf history info ` doesn't
work...just today I found that installing an older kernel doesn't work
(older dnf does this just fine)...there are quite a lot of these at
https://github.com/rpm-software-management/dnf5/issues .
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Miroslav Suchý]

Dne 13. 07. 23 v 23:59 Fabio Valentini napsal(a):

- rawhide mock / koji builds still default to dnf-3 (DNF 4)


Support for DNF5 landed in Mock

https://rpm-software-management.github.io/mock/Release-Notes-4.0

In the meantime 4.1 was released.

I hope that in week or two we release 4.2 and we can set

config_opts['package_manager'] = 'dnf5'

for fedora-rawhide config. I have just created
https://github.com/rpm-software-management/mock/issues/1147

Of course, Koji admins can do that independently in their configs.
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Fabio Valentini]

Hi all,

I'm opening this thread to trigger discussion of the roadmap for DNF5
in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.

This is also being tracked in a FESCo ticket:
https://pagure.io/fesco/issue/3039

The DNF5 Change was approved with the condition that bits that are
important to the distribution *MUST* work, but this does not seem to
be the case yet, six months after this was initially approved -
there's at least a few things that are still using dnf-3 or have been
broken since the switch to dnf5:

- rawhide mock / koji builds still default to dnf-3 (DNF 4)
- Fedora CI has been partially broken since the switch to DNF5 (c.f.
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
making CI results for bodhi updates at least partially useless
- fedora-review has been broken since the switch to DNF5 (c.f.
[FedoraReview#482](FedoraReview/issue/482)), which is really hurting
the rate at which new packages are getting reviewed and added to
Fedora
- (not an exhaustive list, feel free to mention other things, I will
update the list to include them)

We are now mere days before the Fedora 39 mass rebuild is scheduled to
start, so I think it's time to start talking about the roadmap for
getting missing pieces into place for Fedora 39, or if that is not
possible within this timeframe, whether the contingency mechanism
should be enacted.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue