As far as i can say we shouldn't use comps, since it isn't configured by default in our /etc/dnfdragora/dnfdragora.yaml where should be
use_comps: False

Will check on my VM as soon as it is up to date

CC: (none) => anaselli

Created attachment 12982 [details]
screenshot showing it's working

Works here

hmm 2.1.2 is out really

So is this RESOLVED FIXED (by the new release) or a WORKSFORME ?

CC: (none) => ftg

Sorry guys, I made a mistake. I am running the 2.1.2 version.

Assigning to registered maintainer.

Assignee: bugsquad => ngompa13

from my POW it is working, and Mageia is not using, as said, comps. So we need more information from reporter, for instance /etc/dnfdragora/dnfdragora.yaml content

/etc/dnfdragora/dnfdragora.yaml content :
__________________________________________
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

hmm not that then. 

I've just noticed this line:
ImportError: /lib64/librpmbuild.so.9: undefined symbol: rpmluavNew

That shows a problem into "lib64rpmbuild9" something broken in your system?
Here i have this version: lib64rpmbuild9-4.17.0-2.mga9.x86_64

Here it works also in stable, mageia 8:
dnfdragora-2.1.1-1.mga8 and lib64rpmbuild9-4.16.1.3-1.1.mga8

Angelo,
I'm running the same version of lib64rpmbuild9 but in my environment dnfdragora is V2.1.2-1.mga9

do you mean you backported dnfdragora to Mageia 8?

No, I didn't. I only got this release in the last automatic upgrade through Drakconf (see attachment).

Created attachment 12991 [details]
Drakconf screen copy for dnfgragora

As far as i know, i don't have 2.1.2 as update, and i didn't plan to do it and neither did Neal... 
Are you sure you are not playing cauldron?

Comment on attachment 12991 [details]
Drakconf screen copy for dnfgragora

As you can see there is a 1.mga9 tagged there, so you probably picked up from a cauldron repository, official version is 2.1.1 in mageia 8.

No.
______________________________________
[michel@localhost ~]$ cat /etc/release
Mageia release 8 (Official) for x86_64


I even don't see dnfdragora V.2.1.1. anymore through drakconf ...

(In reply to Michel AUTEM from comment #13)
> No, I didn't. I only got this release in the last automatic upgrade through
> Drakconf (see attachment).

Michel, "urpmq --list-url" will show the repositories that have been added
and the url for each of those repositories.

In a Mageia 8 install, every url should contain the string "distrib/8" in
the url.

In order to get mga9 packages showing up, that system must have either
"distrib/9" or "distrib/cauldron" in some of the lines.

What does urpmq --list-url show?

CC: (none) => davidwhodgins

and to understand if the system is a bit broken 
 rpm -qa | grep mga9 | wc -l

And you should get 0 (but it isn't of course).

[michel@localhost ~]$ urpmq --list-url
Core Release (Installer) cdrom://x86_64/media/core
Nonfree Release (Installer) cdrom://x86_64/media/nonfree
Core Release (distrib1) http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/media/core/release
Core Release Debug (distrib2) 
Core Updates (distrib3) http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/media/core/updates
Core Updates Debug (distrib4) 
Core Updates Testing (distrib5) 
Core Updates Testing Debug (distrib6) 
Core Backports (distrib7) 
Core Backports Debug (distrib8) 
Core Backports Testing (distrib9) 
Core Backports Testing Debug (distrib10) 
Nonfree Release (distrib11) http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/media/nonfree/release
Nonfree Release Debug (distrib12) 
Nonfree Updates (distrib13) http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/media/nonfree/updates
Nonfree Updates Debug (distrib14) 
Nonfree Updates Testing (distrib15) 
Nonfree Updates Testing Debug (distrib16) 
Nonfree Backports (distrib17) 
Nonfree Backports Debug (distrib18) 
Nonfree Backports Testing (distrib19) 
Nonfree Backports Testing Debug (distrib20) 
Tainted Release (distrib21) http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/media/tainted/release
Tainted Release Debug (distrib22) 
Tainted Updates (distrib23) http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/media/tainted/updates
Tainted Updates Debug (distrib24) 
Tainted Updates Testing (distrib25) 
Tainted Updates Testing Debug (distrib26) 
Tainted Backports (distrib27) 
Tainted Backports Debug (distrib28) 
Tainted Backports Testing (distrib29) 
Tainted Backports Testing Debug (distrib30) 
Core 32bit Release (distrib31) 
Core 32bit Updates (distrib32) 
Core 32bit Updates Testing (distrib33) 
Core 32bit Backports (distrib34) 
Core 32bit Backports Testing (distrib35) 
Nonfree 32bit Release (distrib36) 
Nonfree 32bit Updates (distrib37) 
Nonfree 32bit Updates Testing (distrib38) 
Nonfree 32bit Backports (distrib39) 
Nonfree 32bit Backports Testing (distrib40) 
Tainted 32bit Release (distrib41) 
Tainted 32bit Updates (distrib42) 
Tainted 32bit Updates Testing (distrib43) 
Tainted 32bit Backports (distrib44) 
Tainted 32bit Backports Testing (distrib45)

[michel@localhost ~]$  rpm -qa | grep mga9 | wc -l
300

Yeap. It looks like I downloaded a bunch of mga9 stuff the last time I used dnfdragora (when it worked yet) to update my system ...

Maybe a mirror issue?

Unfortunately i'm not sure Transaction undo is working anymore... maybe you could try to uninstall and install again the mga9 packates, so that you could restore your system.

After you fix your system, we could close this issue i believe

As the urpmi mirrors are ok, what does "dnf repolist" show?

Dave,
dnf doesn't work anymore, it sends only error messages.

Angelo,
"Uninstall the mga9 packages and reinstall the mga8 versions" ? How do I do that by hand ? I'm afraid I'm not clever enough in Mageia ... Would not it be easier to "simply" reformat my system partition and to reinstall Mageia as a whole ? I think I gonna do nothing as, excepted dnfdragora, I got no other problem for now.

But why don't I see dnfdragora V2.1.1 in my repository lists but *only* V2.1.2 ? If I de-install the V2.1.1, I have no other choice ... It's a mess.

well urpmi should work if dnf is broken, so if you urpme dnfdragora it should work urpmi dnfdragora again. But i suspect you have more packages from cauldron that are important, so 
rpm -qa | grep mga9
should show which they are and if they are not vital you should be able to urpme and urpmi them again or at least their main dependencies (i.e. programs you know from that list).
If dnf does not work any more probably something has been broken there, but again i have it here working, so maybe your dnf mirrors had problems...

but you should be able to use rpmdrake too i believe

The crash implies that libdnf wasn't rebuilt after rpm was rebuilt. Did someone try to do that to see if it would fix it?

I reinstalled Mageia twice since my last post (for other reasons) and ... the "dnfdragora mess" continues. Luckily it's not vital : now I can launch if but it freezes in a loop :
________________________________
[michel@localhost ~]$ dnfdragora
Try reading configuration file
From ./dnfdragora.yaml
Skipped exception: <[Errno 2] Aucun fichier ou dossier de ce type: './dnfdragora.yaml'> 
From /etc/dnfdragora/dnfdragora.yaml
Finally read user settings from /home/michel/.config/dnfdragora.yaml
Logging disabled
<_M_> [ui] YUILoader.cc:60 loadUI(): DISPLAY: ":0.0"
<_M_> [ui] YUILoader.cc:61 loadUI(): XDG_CURRENT_DESKTOP: "XFCE"
<_M_> [ui] YUILoader.cc:62 loadUI(): YUI_PREFERED_BACKEND: ""
<_M_> [ui] YUILoader.cc:74 loadUI(): Detected a Gtk-based desktop environment.
<_M_> [ui] YUILoader.cc:74 loadUI(): Prefering Gtk-UI if available and no
<_M_> [ui] YUILoader.cc:74 loadUI(): user-selected override is present.
<_M_> [ui] YUILoader.cc:96 loadUI(): User-selected UI-plugin: ""
<_M_> [ui] YUILoader.cc:128 loadUI(): Using UI-plugin: "gtk"
<_M_> [ui] YUI.cc:81 YUI(): This is libyui 3.10.0
<_M_> [ui] YUI.cc:82 YUI(): Creating UI without threads
<_M_> [gtk] YGUI.cc:48 YGUI(): This is libyui-gtk 2.49.0
<_M_> [gtk] YGUI.cc:166 checkInit(): Style "/usr/share/libyui/theme/current/wizard/style.css"
<_M_> [gtk] YGUI.cc:188 checkInit(): Style "/usr/share/libyui/theme/current/wizard/style.css" not found. Ignoring style
<WRN> [gtk] YGUtils.cc:543 loadPixbuf(): Could not load icon: /usr/share/libyui/theme/icons/32x32/apps/yast.png
<WRN> [gtk] YGUtils.cc:543 loadPixbuf(): Reason: Impossible d’ouvrir le fichier « /usr/share/libyui/theme/icons/32x32/apps/yast.png » : Aucun fichier ou dossier de ce type
<_M_> [ui] YUI.cc:236 topmostConstructorHasFinished(): Running without threads
<_M_> [ew] YExternalWidgets.cc:40 YExternalWidgets(): Creating Libyui External Widgets object
<_M_> [gtk] YMGA_GCBTable.cc:414 YMGA_GCBTable():  Slection mode 2
<_M_> [gtk] YMGA_GCBTable.cc:433 YMGA_GCBTable():  columns 8 tot 8
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
Get root backend. Locked (False)
... etc.

well that seems to say dnfdaemon  is not running, maybe not installed? But it seems a different problem to me

Here I am ..

[michel@localhost ~]$ su -f
Mot de passe : 
[root@localhost michel]# systemctl status dnfdaemon
● dnfdaemon.service - Package management dnf daemon
     Loaded: loaded (/usr/lib/systemd/system/dnfdaemon.service; static)
     Active: inactive (dead)
[root@localhost michel]# systemctl enable dnfdaemon
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.
[root@localhost michel]#

dnfdaemon looks fine, it runs on "call".

are you using dnfdaenon-update by any chance?

It seems you are running another instance of dnfdragora (or dnfdragora-update) that is connected to dnfdaemon, so the backend is locked already.

if for any reasons that was dead badly, you could run dnfdragora --exit first to unlock the dnfdaemon.
But i suspect you are (or were) download update metadata from mirrors and as happens often something for mageia dnf mirrors, is broken and the mirrors are slow so you cannot run dnfdragora again until that process is finished.

Angelo,
That's correct and it works now : I used dnf-update a couple of days ago but I uninstalled it almost immediately. That's when my problem begun. But why does it persist after a reboot of the system ? I guess I tried to stop and restart too quickly dnfdragora, before the daemon was made free again, because I thought the process was frozen and dead.
Thanks a lot, you may close this ticket.

One

Resolution: (none) => WORKSFORME
Status: UNCONFIRMED => RESOLVED