Bug 22425 - GUI draksnapshot-config dies with no further output (or maybe with "terminated abnormally")
Summary: GUI draksnapshot-config dies with no further output (or maybe with "terminate...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: x86_64 Linux
Priority: High normal
Target Milestone: Mageia 8
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords: 7final
Depends on: 21260
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-19 21:14 CET by keith ericson
Modified: 2021-01-31 00:07 CET (History)
11 users (show)

See Also:
Source RPM: draksnapshot-0.20.3-18.mga7.src.rpm
CVE:
Status comment:


Attachments
Patch for changing gtk2 to gtk3 + chnage from interval to retain keywork (4.65 KB, patch)
2020-05-18 08:52 CEST, Nicolas Nicolas
Details | Diff
draksnapshot-config (changed) (14.41 KB, application/x-perl)
2020-05-21 23:31 CEST, Nicolas Nicolas
Details

Description keith ericson 2018-01-19 21:14:34 CET
Description of problem:

draksnapshot-config (and draksnapshot-applet) do not run to completion.
(This is new with Release 6; I just successfully configured rsnapshot using this tool on Version 5; that Source RPM is draksnapshot-0.20.3-11.mga5-src.rpm)

Running draksnapshot-config from the command-line results in the following output:

Subroutine Pango::Layout::set_text redefined at /usr/lib/perl5/vendor_perl/5.22.3/Gtk3.pm line 2182.
Subroutine Pango::Layout::set_markup redefined at /usr/lib/perl5/vendor_perl/5.22.3/Gtk3.pm line 2188.
GLib-GObject-WARNING **: cannot register existing type 'GtkWidget' at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-GObject-WARNING **: cannot add class private field to invalid type '<invalid>' at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-GObject-WARNING **: cannot add private field to invalid (non-instantiatable) type '<invalid>' at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-GObject-WARNING **: cannot register existing type 'GtkBuildable' at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-GObject-CRITICAL **: g_type_register_static: assertion 'parent_type > 0' failed at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.
GLib-GObject-WARNING **: cannot add private field to invalid (non-instantiatable) type '<invalid>' at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 110.


Version-Release number of selected component (if applicable):
Version     : 0.20.3
Release     : 15.mga6


How reproducible: 100%


Steps to Reproduce via GUI:
1. Open MCC
2. Select System
3. Select Snapshots
3a. this will offer to install draksnapshot if not already installed
4. Window opens showing "Loading" but it never completes

Steps to Reproduce via Command Line
1. run /usr/bin/draksnapshot-config
2. Observer error messages
Marja Van Waes 2018-01-19 21:39:25 CET

CC: (none) => marja11
Assignee: bugsquad => mageiatools

ben mcmonagle 2018-07-11 08:08:20 CEST

CC: (none) => westel

Comment 1 Omnio Torr 2019-03-17 15:20:22 CET
Exactly the same behavior here (Mageia-7-beta2-Live-Xfce-x86_64). Please remove Snapshots from MCC before releasing Mageia 7, carrying a broken functionality from one release to the next is bad for Mageia's image.

CC: (none) => storage

ben mcmonagle 2019-04-22 08:56:24 CEST

Keywords: (none) => 7beta3
Version: 6 => 7

Comment 2 ben mcmonagle 2019-04-22 08:57:37 CEST
still valid for Mga7-beta3

updated release and keywords as required
ben mcmonagle 2019-04-22 08:59:55 CEST

Source RPM: draksnapshot-0.20.3-15.mga6.src.rpm => draksnapshot-0.20.3-18.mga7.src.rpm

Comment 3 David GEIGER 2019-04-22 09:27:22 CEST
Same as bug 21260

CC: (none) => geiger.david68210
Depends on: (none) => 21260

Comment 4 David GEIGER 2019-04-22 09:29:45 CEST
This tool should be rewrite to switch to GTK+3 and udisks2, this is why it is broken for a long time.
aguador 2019-04-22 10:53:48 CEST

CC: (none) => waterbearer54

Comment 5 Doug Laidlaw 2019-05-15 16:23:34 CEST
With rsnapshot 1.3.1, on a reinstall of Mga 6, the rsnapshot service is not created, after 3 attempts.

CC: (none) => laidlaws

Comment 6 Doug Laidlaw 2019-05-15 16:39:52 CEST
The same seems to be true of rsnapshot 1.4.? in Cauldron.
Comment 7 Doug Laidlaw 2019-05-15 18:12:53 CEST
I gave up trying to install rsnapshot from the tarball.  I found this link re .service files:

https://mark.stosberg.com/blog/tech/rsnapshot-and-systemd/

It is for ubuntu.

[Opening the page, all I saw was a set of teeth.  My father was a dentist...]
Comment 8 Doug Laidlaw 2019-05-16 12:52:36 CEST
Sorry, not a bug.  rsnapshot is not run as a service.  The executable "rsnapshot" is called by cron.  All working as it should.  I didn't like stosberg's idea of locking the backup intervals into systemd.  This way is far more configurable.
Comment 9 keith ericson 2019-05-16 18:14:29 CEST
It appears to me that this discussion has drifted away from the original bug report: the problem is NOT with rsnapshot but with draksnapshot-config, the GUI that is (or was) used to configure the rsnapshot system.

Yes, one can install rsnapshot and configure it manually (command-line) but the GUI was really sweet. Now it's pretty sour.

Keith Ericson, Original submitter of this but
Comment 10 keith ericson 2019-05-16 18:15:25 CEST
uh, "bug," not "but."
Comment 11 Doug Laidlaw 2019-05-16 18:25:45 CEST
I had a senior moment.  Nowadays, they are happening too often.  I have saved a config file and a cron file, and simply copy them across each time.  I don't think I have ever used the GUI.
Comment 12 ben mcmonagle 2019-09-18 03:26:32 CEST
Can this be corrected before release of Mga-8.
 
maybe also will clear out old bugs:
Bug 17390 draksnapshot-config - default snapshot configuration incomplete,

Bug 19195 Snapshots cannot be taken by clicking on "Apply" in MCC-System-Snapshots,

Bug 21260 "Snapshots" won't start.

I tried it in cauldron over the last few days, and problem still exists.

changing release version and keyword as required
ben mcmonagle 2019-09-18 03:29:52 CEST

Keywords: 7beta3 => 7final
Priority: Normal => High
Target Milestone: --- => Mageia 8

Comment 13 Doug Laidlaw 2019-09-18 06:56:46 CEST
I talk too much.  Unsubscribing.
Doug Laidlaw 2019-09-18 06:57:07 CEST

CC: laidlaws => (none)

Comment 14 Peter Grun 2019-11-29 08:27:24 CET
I found a way around the bugs 17390, 19195, 21260, 22425.
With the entry:
5 9 * * *   root   /bin/rsnapshot hourly
in the crontab, rsnapshot starts as desired. rsnapshot is running at 09:05
The same with daily, weekly ....

CC: (none) => p.grun

Filip Komar 2019-12-02 14:20:41 CET

CC: (none) => filip.komar

Comment 15 keith ericson 2019-12-04 08:52:41 CET
Repeat Observation: it appears to me that this discussion has once again drifted away from the original bug report: the problem reported and requested be repaired is NOT with rsnapshot but with draksnapshot-config, the GUI that is (or was) used to configure the rsnapshot system.

Yes, rsnapshot will successfully complete the configured backups, but it now requires hand-coding the parameters in rsnapshot.conf and in crontab. That all used to be neatly accomplished with drakshapshot-config, saving (especially) newbies the pain and suffering of all that hand coding (especially forgetting that separators in rsnapshot.conf MUST be tabs and not spaces :-)).

Yes, one can install rsnapshot and configure it manually (command-line) but the GUI was really sweet. Now it's pretty sour.

Keith Ericson, Original submitter of this bug
Comment 16 Nicolas Nicolas 2020-05-18 08:50:50 CEST
Hello,

For the some part of GUI ( launching from terminal) to be launched, there is a need to replace gtk2 to gtk3 in the file draksnapshot-config. Running from CCM is not working doing theses changes because of the create_factory_menu function that doesn't exists in ugtk3.pm.

adding/excluding new folders is not working (vbox issue)

There is also a need to modify manually the /etc/rsnapshot.conf to replace the interval/retain (which seems to be new keyword) ( default is alpha, gamma,....)

/sbin/draksnapshot-applet has also to be corrected (even replacing gtk2 by gtk3 can only give the ability to the tool to be launched ( but hang whatever is done on the icon ( StatusIcon doesn't exists in Gtk3)

CC: (none) => joe_c_moi

Comment 17 Nicolas Nicolas 2020-05-18 08:52:37 CEST
Created attachment 11651 [details]
Patch for changing gtk2 to gtk3 + chnage from interval to retain keywork
Comment 18 Nicolas Lécureuil 2020-05-19 15:25:06 CEST
Thierry, can you review the patch please ?

CC: (none) => mageia, thierry.vignaud

Comment 19 Nicolas Nicolas 2020-05-21 12:06:07 CEST
Hello,

Just to warn... I know nothing about Perl , so yes it has be reviewed by a Perl expert... ;-)

After changing the gtk2-> gtk3 in the /usr/libexec/draksnapshot-config ( that is what have i mostly done in the proposed patch beside also modified manually /etc/rsnapshot.conf for defining "retain" hourly,daily,monthly,yearly ( maybe it can be inserted in the rsnapshot package by default ?), i modified the line:

my $_menubar = $::isEmbedded ? create_factory_menu($my_win->{rwindow}, @menu_items) : undef;

to 

my $_menubar = $::isEmbedded ? Gtk3::MenuBar->new($my_win->{rwindow}, @menu_items) : undef;

And interface seems to launch from the MCC.

Another annoying bug is that when trying to add/exclude directories the application hangs !).

I think that draksnapshot-applet has also to be reviewed (i think it hangs at startup)
Comment 20 papoteur 2020-05-21 12:30:49 CEST
Hello,
To be sure. I don't find draksnapshot on our git. Is it stored only in the rpm source?

CC: (none) => yves.brungard_mageia

Comment 21 Nicolas Lécureuil 2020-05-21 18:33:12 CEST
looking to the spec file i would say this is not  'yet' on our git.

Strange ...
Comment 22 papoteur 2020-05-21 22:13:07 CEST
Hi Nicolas,
Can you pass the whole program? I tried with patch, but I get an error:
undefined value for mandatory argument 'text' encountered at /usr/lib/libDrakX/mygtk3.pm line 518.
  Perl's trace:
  drakbug::bug_handler() called from /usr/share/perl5/Carp.pm:291
  Carp::croak() called from /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm:67
  Glib::Object::Introspection::__ANON__() called from /usr/lib/libDrakX/mygtk3.pm:518
  mygtk3::_gtk__Entry() called from /usr/lib/libDrakX/mygtk3.pm:122
  mygtk3::_gtk() called from /usr/lib/libDrakX/mygtk3.pm:59
  mygtk3::gtknew() called from /usr/bin/draksnapshot-config:191
Comment 23 Nicolas Nicolas 2020-05-21 23:29:53 CEST
Hello Papoteur,

I tried to copy the file /usr/libexec/draksnapshot-config to my current computer (the tests i made are on a VM).

And it was not working (even after changing the retain fields in /etc/rsnapshot.conf (changed the defaults ones to hourly,daily,weekly and monthly (all have to be uncommented)).

So after remember what i tried to change manually, i also uncommented "snapshot_root" and "no_create_root" fields in the /etc/rsnapshot.conf , so it seems that a variable is not initialized correctly). So the interface is launching but it is not out of box...
Comment 24 Nicolas Nicolas 2020-05-21 23:31:50 CEST
Created attachment 11653 [details]
draksnapshot-config (changed)
Comment 25 papoteur 2020-05-22 10:38:44 CEST
Indeed, with modifications of the config file, I get the window \o/
Now, we need to go further and check the whole application.
Comment 26 Nicolas Nicolas 2020-05-22 12:11:59 CEST
Hello,

In fact, the snapshot_root has to be uncommented because the program draksnapshot-config has to define a variable $backupdirectory.

It has two way to do it:

1) parse the /etc/rsnapshot.conf file to use the snapshot_root (uncommented (because it is a filter like /^snapshot_root/) that can't work if uncommented. ( see the file /usr/share/perl5/vendor_perl/MDV/Snapshot/Common.pm to see this).
2) if the above is not working it is using the first removable device that is mounted. For this it relies on /usr/share/perl5/vendor_perl/MDV/Snapshot/Hal.pm that is serach a org.freedesktop.Hal (that indeed not existing at all)

So if the 2 both methods are not successful the backupdirectory variable is not defined and then perl thows the error you get.

It should be useful to modify the hal.pm file to use the UDisks or UDisks2 manager to get the program to start ( and will be useful for the draksnapshot-applet that also rely on this Hal.pm file for starting correctly (after changed reference to gtk2 to gtk3).

A quick dirty workaround for the draksnapshot-config program to start is to set a default value in the /usr/share/perl5/vendor_perl/MDV/Snapshot/Common.pm file (this way it will always launch in case the snapshot_root is commented in /etc/rsnapshot.conf or if there is an issue with (hal)/udisks/udisks2 or no removable device plugged on the computer.
Comment 27 keith ericson 2021-01-31 00:07:59 CET
As of Mageia 7.1, which I just installed, draksnapshot-config, used to perform the initial setup of (drak)snapshots, is still broken.

When started graphically the result is a window that displays a "Loading" icon (down-arrow emanating from a gear) which never resolves.

When started from a command line (e.g., /usr/bin/perl /usr/libexec/draksnapshot-config) the result is a list of problems with the attempt to run, none of which I understand. Moreover, at the end of the process, after H.A.L. has reported, "I'm sorry, Dave. I'm afraid I can't do that," the command-line just sits there waiting for a Control-C to terminate it.

Note You need to log in before you can comment on or make changes to this bug.