In fact I don’t know how to use ‘whois’ in Kate. I would use that in Konsole.
In Kate I would use >Edit>Find like this:
Note the up and down arrows to the right that allow you to go to previous or next match, ect.
The goal is not for me to do it for you (or any user) the goal if for you to be able to do it for yourself. Logs are logs, they are purposely designed to be the same for all systems. This could only be changed if someone changed the code in the dnf software.
Searching for information in logs is not something that is immediate, it sometimes takes a bit of time and patience to find what you want. If you haven’t done it before it requires a tiny amount of learning “How to find what I want”.
Post-edit: To put in perspective what it takes to find things in these logs on the computer I’m on at this moment the dnf.rpm.log is over 16,500 lines the dnf.log is over 97,500 lines. That is not unusual, many users will find their logs to be as big or bigger.
Of course but I’m not able to find updated package. May be I make a mistake this is why I suggest to send you my file.
I’m not convinced. This morning (4 april 2019) I opened OMLx 4, updated several packages and few seconds after I closed.
Here’s last rows of my dnf.log:
2019-04-03T18:11:14Z DEBUG Creazione dei file di cache per i metadati.
2019-04-03T18:11:14Z INFO Il timer per la cache dei metadati è disabilitato quando si è su una connessione a consumo.
2019-04-03T18:11:14Z DDEBUG Cleaning up.
As you can see not even a row on 2019-04-04.
Why do you keep talking about “last rows of my dnf.log”? That is not the right place to be looking. You have to go further back in the logs.
Using my own dnf.log as an example currently last line is 107,602. Now I want to scroll back past all lines that have DEBUG, DDEBUG, INFO, or WARNING. Which in this case takes me to line 105,601. That happens to be an update I did less than 5 hours ago. What??? 2001 lines to go back less than 5 hours? Yep, I’m afraid that this currently how this log works.
Now I do understand your frustration and hope that you and others see my frustration. How will we get users to use a log where you have to go back 2000 lines to find an update that user did less than 5 hours ago. Developers are you paying attention? (Here’s the question: Developers will all this debug output go away when repos are split for Lx 4.0? I’m hoping so.)
Also now you and other users are perhaps more aware of why I would use the ‘Find’ utility in Kate or Kwrite to find things in this dnf.log or the dnf.rpm.log. Scrolling takes more time a patience than most of us have.
1 Like
In my dnf.log there are several lines reading
Installing:
followed by the list of packages installed in that given instance.
I think if you make a search like this, that may help.
At any rate, the simple command in console is the easiest way to get just all you wanted to know
therefore I don’t see the point of having to look into thousands of lines of logs.
1 Like
Of course I used “Find” but no way to find any of the updated packages.
My most recent “installing” is on 29 march 2019. Then this don’t works either.
This just to show that dnf.log don’t contain information on updated packages, at least in my system.
If I need a list of updates I will use konsole.
There are also lines
Upgrading:
and, maybe the best
Transaction Summary
1 Like
Then you have a serious problem and need to figure out what has been done to corrupt your system.
I’ll say this one more time. Your dnf.log is supposed to contain every transaction by dnf going back to and including installation on you system. I’ve looked at dnf.log on quite a few hardware systems by now and I have never seen otherwise. I won’t say something is impossible without confirmation, so post your entire dnf.log. And I mean the entire log, every line. Post-edit: To post every line may require you to split the log in to 2 or more files. Or compress it with xz which can be done easily in Dolphin and xz files will upload here.
As per example the dnf.log on the machine I am on right now begins with entries dated Feb. 04, 2019 with the packages that Calamares initially installed. Here’s is what line 1 should look like (your date and time will obviously be different):
2019-02-04T14:36:42Z INFO --- logging initialized ---
Then line 5 is an incredibly long line because it is the exact line from Calamares installer to install entire system. Here’s first part of line 5:
2019-02-04T14:36:42Z DDEBUG Command: dnf install -y --refresh --nogpgcheck --forcearch=x86_64 --exclude=*.i686 --setopt=install_weak_deps=False --installroot /home/omv/iso_builder/BASE
Note the “/home/omv/iso_builder/BASE” that is the Calamares installer.
Then the log at current moment goes to line 107,748. If your log is not something like that something is really wrong. Let’s do some simple math here. Feb. 4 until today just happens to be exactly 2 months. So that is 107,748 lines after 2 months.
1 Like
By the way, you won’t find glibc-6:2.29-1. Most likely you will find glibc-2.29-1.
1 Like
@rugyada has provided us with some great tips here. Thanks @rugyada.
Post-edit: If I search with ‘Find’ “Transaction Summary” it will find all entries that say that starting with the very first one on Feb. 04, which is for 2280 packages, in other words the install. Then to the right of ‘Find’ there is a down arrow that take you to the most recent “Transaction Summary” from today. Something similar should be in everyone’s dnf.log.
Post-edit-2: Really good suggestions from @rugyada.
1 Like
The .xz file below is the dnf.log I have been using as an example so it contains everything I have talked about above and lots more. If interested see if you can find the things talked about.
dnf.log.tar.xz (319.8 KB)
and if @Giorgio or anyone wishes to they can compare my file to yours and maybe we all learn some things.
And don’t anyone go thinking I’m smarter than any other users here or that I think that way. I am wrong sometimes and get to “eat humble pie”. I don’t think I will turn out to be wrong on this one but well you just never know until you know.
I use very often “Find” to search and I know I’ve to keep pressing key to go further.
I used “Find” to search for package names or other significant words but i don’t find anything corresponding to updated packages.
Then I think my dnf.log is probably different from yours. Not a big problem for me, now I’ve an easy alternative to list updated packages.
First post your entire dnf.log as a file here and we can see if this is true.
Another exercise, simply do this:
Open ‘/var/log/dnf.log’ with Kate. Select ‘Edit>Find’ and type in the ‘Find’ bar “Transaction Summary”
and it should look like this:
Post-edit: Won’t matter if user is updating with dnfdragora (strongly not recommended) or command line (strongly recommended) everyone should have this in their dnf.log because this is showing the original installation of your system for Calamares.
@rugyada can you check and confirm whether dnfdragora is logging dnf transactions, here it looks like it is not. If so that is absolutely horrible.
Post-edit: And I’m all but certain that I’m about to get another opportunity to admit I was wrong about some things above. Not all of it but some of it.
So I asked Son_Goku on IRC (he is one of the principle authors of dnf and dnfdragora) and dnfdragora transactions are definitely supposed to be logged in the dnf logs. But my own investigation shows that they aren’t currently. Indicating I was right that the information is supposed to be there but that @Giorgio was right in insisting that his logs are different. And the possibility that his logs might be different because of bug with dnfdragora did not occur to me until today.
It would be strongly advised to not use dnfdragora until this issue is addressed. Discussion here.
dnfdragor is not logging transactions in logs.
https://issues.openmandriva.org/show_bug.cgi?id=2454
The answer to the original question in this thread and to it’s title is provided by @rugyada thus:
$ rpm -qa --last
So let’s close this thread and deal with the issues with dnfdragora and dnf logs here.
I made an effort 
and installed using dnfragora
Checked and confirmed.
Nothing in log files dnf.log, dnf.rpm.log or hawkey.log