Looks like a dupe of bug 1720234

At any rate, this is a cosmetical issue.

Eh not really as it is preventing legitimate bugs from being diagnosed. My link (bug 1644642) and now your link (bug 1720234). Also (total conjecture) its easy to imagine this being some sort of pointer mismanagement.

There is indeed a number of problems here.

Going through your original list:
1. This is a problem in DNF, I will fix this.
2. This warning line is from rpm, so it has to be fixed there.
3. Here DNF is at fault again. Although rpm gives as the "key" argument to the callback just the name of the package (I think its this: https://github.com/rpm-software-management/rpm/blob/master/python/rpmts-py.c#L530). It may be more useful to get the full NEVRA, so we don't have to search for the package after that, but I don't know whether this would break anything else.
4. Here we could also use help from rpm since it passes the value for the rpmtag in the "amount" parameter of the callback, however names for these trigger rpmtags are marked as internal (such as RPMTAG_TRANSFILETRIGGERIN in this example) and don't seem to be accessible from python rpm api. The second part of the message is wrong in DNF once again.

While writing tests for this I also discovered that when scriptlet defined with FILETRIGGERIN runs rpm passes to dnf name of the package that triggered this not the name of the package whose the FILETRIGGERIN scriplet is. I have also tested with triggerin and transfiletriggerpostun which seem to be fine, don't know about the others.

At the same time I think that for all the [TRANS]FILETRIGGER* scriptlets wrong value for "amount" gets passed. For example instead of value for RPMTAG_TRANSFILETRIGGERPOSTUN we get RPMTAG_TRIGGERPOSTUN.
(values from https://github.com/rpm-software-management/rpm/blob/8390fa8515f499994646cf3bd113423744dc7bd9/lib/rpmtag.h#L174)

Panu can you help with this?

I created PR for the DNF part: https://github.com/rpm-software-management/dnf/pull/1471
And some tests: https://github.com/rpm-software-management/ci-dnf-stack/pull/616

(In reply to amatej from comment #4)
> 3. Here DNF is at fault again. Although rpm gives as the "key" argument to
> the callback just the name of the package (I think its this:
> https://github.com/rpm-software-management/rpm/blob/master/python/rpmts-py.
> c#L530). It may be more useful to get the full NEVRA, so we don't have to
> search for the package after that, but I don't know whether this would break
> anything else.

This is an ancient, unfortunate misdesign of the python callback, and hard to change because yes it would break all python clients. You'd find life much saner if the callback handling was pushed to libdnf side.

> 4. Here we could also use help from rpm since it passes the value for the
> rpmtag in the "amount" parameter of the callback, however names for these
> trigger rpmtags are marked as internal (such as RPMTAG_TRANSFILETRIGGERIN in
> this example) and don't seem to be accessible from python rpm api. The
> second part of the message is wrong in DNF once again.

Yup, another old problem. The thing is, those tags need to be kept internal as that's exactly what they are, they only exist in the rpmbuild internals. One possibility could be defining an alternate set of symbols for the values used in script amount, and export those.

> While writing tests for this I also discovered that when scriptlet defined
> with FILETRIGGERIN runs rpm passes to dnf name of the package that triggered
> this not the name of the package whose the FILETRIGGERIN scriplet is. I have
> also tested with triggerin and transfiletriggerpostun which seem to be fine,
> don't know about the others.

I've looked at the code once or twice and couldn't see how this might be the case, but that doesn't mean it can't.
If you have a reproducer case for this, please file a separate bug on rpm with that reproducer.

> At the same time I think that for all the [TRANS]FILETRIGGER* scriptlets
> wrong value for "amount" gets passed. For example instead of value for
> RPMTAG_TRANSFILETRIGGERPOSTUN we get RPMTAG_TRIGGERPOSTUN.
> (values from
> https://github.com/rpm-software-management/rpm/blob/
> 8390fa8515f499994646cf3bd113423744dc7bd9/lib/rpmtag.h#L174)

This affects rpm's own debug logging too, and unfortunately not an easy fix due to the way file triggers are implemented. It'd be nice to get it fixed some day though.

> I've looked at the code once or twice and couldn't see how this might be the case, but that doesn't mean it can't.
> If you have a reproducer case for this, please file a separate bug on rpm with that reproducer.

Never mind, I found a reproducer in our own test-suite, it's just that rpm itself doesn't emit output for scriptlets so this has gone invisible all along. I'll have a look, this was supposed to be fixed already.

> I've looked at the code once or twice and couldn't see how this might be the case, but that doesn't mean it can't.

QED: https://github.com/rpm-software-management/rpm/pull/892

*** Bug 1720234 has been marked as a duplicate of this bug. ***

Ok, thank you. So we have decided to do an incomplete fix in the scope of DNF4. Also it seems the rpm problems are already known and I will leave them out from now on. (Alternate set of symbols for the internal tags would be nice in the future, maybe discuss with dmach.)

Final summary for DNF : 

Wrong message for running scriptlet (Running scriptlet: gpxsee-7.9-1.fc30.x86_64)
- wrong package -> this will be partially fixed now, only a name of the package will be shown because of the python API, DNF5 should do better because it will use the C rpm API using libdnf.

Wrong message to stderr for error in scriptlet (Error in <unknown> scriptlet in rpm package gpxsee)
- wrong format of the message, when some package triggered scriptlet of some other package -> will be fixed now.
- wrong scriptlet type (or unknown) -> part of the rpm problems
- wrong package names -> this should be fixed now.

The tests I created describe this behavior and should ensure we eventually get there because some of them will be marked as failing now.

So, rawhide composes have been failing since this landed (failing to make live media). 

I see the following traceback: 

07:57:50,228 INF packaging: Configuring (running scriptlet for): samba-client-2:4.11.2-1.fc32.x86_6
4 1573035436 934aceaaccdc5254613f8dfa10682cab8f79f6252e735d52cc1e5aa3cd92273d
07:57:50,268 CRT dnf: Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/dnf/yum/rpmtrans.py", line 291, in callback
    self._script_start(key)
  File "/usr/lib/python3.8/site-packages/dnf/yum/rpmtrans.py", line 439, in _script_start
    display.progress(pkg_or_key, action, 100, 100, complete, total)
  File "/usr/lib64/python3.8/site-packages/pyanaconda/payload/dnfpayload.py", line 205, in progress
    nevra = "%s-%s.%s" % (package.name, package.evr, package.arch)
AttributeError: 'str' object has no attribute 'name'

07:57:50,287 INF packaging: Installed: audit-3.0-0.15.20191104git1c2f876.fc32.x86_64 1572899312 3c4
fa72b45db7e538d7fe4aa4049f2aef0c38e29169684351b8826002f388fe2

the install goes on a bit more then exits. 

Here's a kde live from last night (but they are all failing the same way): 

https://koji.fedoraproject.org/koji/taskinfo?taskID=38852681

I'm not 100% sure dnf is to blame here, but to test that theory I did: 'koji untag-pkg f32 librepo-1.11.0-1.fc32  libdnf-0.37.2-1.fc32 dnf-4.2.15-1.fc32 dnf-plugins-extras-4.0.8-1.fc32 dnf-plugins-core-4.0.11-1.fc32' and am going to run another compose. If it works, we know, if not, I can tag them all back. If there is a fix in just one package let me know and I can tag the rest in for you to build against.

I am pretty sure DNF is to blame here. I changed the input to the progress function to sometimes be only a string (because we only know the name of the package) but Anaconda seems to rely on the fact that it is a package object.

We will revert the patch to fix the situation.

We have also decided that the best way to proceed with this bug is to keep the behavior broken for now and delay its fix to DNF5 where we will move from the Python rpm API to the C API.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Any news about this?

(In reply to Tao Feng from comment #15)
> Any news about this?

We are working on DNF5 in the dnf-5-devel branch of libdnf: https://github.com/rpm-software-management/libdnf/tree/dnf-5-devel which will have the DNF part of problems fixed.

It is a major rewrite though so it's going to take more time.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

*** Bug 2120346 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.