Don't use dnfdragora for transactions (there is no logging)

Tags: #<Tag:0x00007fc0c133ea30> #<Tag:0x00007fc0c133e6e8>

Note: This thread is not in any way be me meant to be anti-dnfdragora. IMO this is a serious issue. If we are going to ship dnfdragora on our ISO’s and include it in our package list this really is an issue that needs to be fixed.

Don’t use dnfdragora for transactions. Why? Because there is no logging of transactions.

If you update, install, or remove packages and run in to a problem and there are no logs you are in a bad place regarding problem solving so please avoid that situation and don’t use dnfdragora until this matter gets resolved.

Post-edit: While this thread in not meant in any way to be anti-dnfdragora anyone that knows me knows I have for a long time recommended for users to use terminal for package management rather than a GUI application. Package Management for user purposes in terminal is very easy and this is an outstanding way for user to get used to and comfortable with using the command line.

Know it, learn it, believe it, use it.

:speak_no_evil: :see_no_evil: :hear_no_evil:

1 Like

dnfdragor is not logging transactions in logs.
https://issues.openmandriva.org/show_bug.cgi?id=2454

For users to create an easier to read log of dnf transactions there is the @rugyada method:

$ sudo dnf --refresh upgrade 2&gt;&amp;1 | tee konsole_01-update.log

just rememver that for every transaction you need to change the number or the log will be over writtern. Like konsole_02-update.log konsole_03-update.log, and so on.

Note: Why? Because there are a lot of debug lines in the dnf.log making it harder to find things for us technological mortals.

1 Like

Here’s my dnf.log dnf.log.tar.xz (159.2 KB) as asked in List of recent updates how to

dnf.rpm.log is a bit more human readable, fwiw.
Still transactions from dnfragora are not logged (anywhere in any log files that I can guess).

Postedit:
PS>
Forget dnfdragora :stuck_out_tongue:

1 Like

Thanks that matters.

1 Like

@Giorgio this is from your log.

Above is the Calamares package installation or your system. Another transaction from your log:

That transaction is a package removal where it looks like you removed unnecessary locale packages.

So your logs do have some transactions logged as they should. However we now know that dnfdragora has not been logging transactions so those won’t and aren’t in the log. Which is what this thread and bug report 2454 are about. And you did cause this to be uncovered. So thanks for that. Big thanks because this is a serious issue.

The only difference between your logs and mine is the missing transactions because of this bug. You should have no problem finding the transactions in the screen shots above.

dnfdragora should collect log from installed/removed packages, if not then there is a problem.

In /etc/dnfdragora/dnfdragora.yaml is small config where we can define some options:

settings:
    use_comps: False
    always_yes: False
    update_interval: 180
#    log_filename: PATH/TO/dnfdragora.log
#    log_level_debug: True

#    path:
#        group_icons: /usr/share/icons
#        To see icons set the following path 
#        images: PATH_TO_DNFDRAGORA/share/images

maybe it’s possible. If someone has time, can try to play with the change of path etc.
Maybe this help, maybe…

Man page here: dnfdragora.yaml man page - dnfdragora | ManKier

2 Likes

This is confirmed there is definitely a problem. dnf transactions made by dnfdragora are not being logged.

Thanks, but not working for the purpose

Aside, the file has been created in /home/user :unamused:

1 Like

uncomment log_level_debug: True (remove #)

after this, for me log file look like this:

2019-04-06 20:55:00,297 [dnfdragora.ui](DEBUG) adding: install falkon,0,3.1.0,1,x86_64,cooker-x86_64
2019-04-06 20:55:00,310 [dnfdragora.dnf_backend](DEBUG) TransactionEvent : start-build
2019-04-06 20:55:00,469 [dnfdragora.dnf_backend](DEBUG) TransactionEvent : end-build
2019-04-06 20:55:05,074 [dnfdragora.dnf_backend](DEBUG) Downloaded : falkon-3.1.0-1-omv4000.x86_64.rpm
2019-04-06 20:55:11,074 [dnfdragora.dnf_backend](DEBUG) Downloaded : falkon-core-3.1.0-1-omv4000.x86_64.rpm
2019-04-06 20:55:17,584 [dnfdragora.dnf_backend](DEBUG) on_RPMProgress : [falkon-core,0,3.1.0,1,x86_64,cooker-x86_64]
2019-04-06 20:55:22,819 [dnfdragora.dnf_backend](DEBUG) on_RPMProgress : [falkon,0,3.1.0,1,x86_64,cooker-x86_64]
2019-04-06 20:55:38,850 [dnfdragora.dnf_backend](DEBUG) on_RPMProgress : [falkon-core,0,3.1.0,1,x86_64,cooker-x86_64]
2019-04-06 20:55:40,770 [dnfdragora.base](DEBUG) Unlock the DNF root daemon
2019-04-06 20:55:40,773 [dnfdragora.base](INFO) Unlocked the DNF root daemon

Installed falkon.

2 Likes

:+1:

Well, not much different from dnf.rpm.log.
43 lines of ‘DEBUG’ just to read (at line 26) remove kblocks :grin:

1 Like

The DEBUG stuff in the various dnf logs is interesting. This gets in to a separate topic (which maybe needs it’s own thread) but with all of that in these logs it more or less assures that users will be intimidated or confused and won’t use these logs. Whether that is intentional or not I don’t know.

None the less the logs are there and will be valuable to QA-Team and developers when there are problems.

I’ve already learned the hard way in another conversation that it is probably a bad idea to suggest to users to try to use these logs themselves. Best is that we only ask them to post the entire log so a dev can read. (Or a QA minion.)

:monkey:

1 Like

This has been sort of fixed. There is now a dnfdragora.log in /home/. Thank @AngryPenguin for this fix.

:monkey:

1 Like