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

still valid for Mga7-beta3

updated release and keywords as required

Same as bug 21260

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

This tool should be rewrite to switch to GTK+3 and udisks2, this is why it is broken for a long time.

With rsnapshot 1.3.1, on a reinstall of Mga 6, the rsnapshot service is not created, after 3 attempts.

CC: (none) => laidlaws

The same seems to be true of rsnapshot 1.4.? in Cauldron.

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...]

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.

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

uh, "bug," not "but."

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.

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

I talk too much.  Unsubscribing.

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

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

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

Created attachment 11651 [details]
Patch for changing gtk2 to gtk3 + chnage from interval to retain keywork

Thierry, can you review the patch please ?

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

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)

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

looking to the spec file i would say this is not  'yet' on our git.

Strange ...

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

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...

Created attachment 11653 [details]
draksnapshot-config (changed)

Indeed, with modifications of the config file, I get the window \o/
Now, we need to go further and check the whole application.

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.

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.

Is this bug fixed yet in Mageia 8 ?

CC: (none) => chris

Not yet.

Assigning this, raising priority.

Keywords: 7final => (none)
CC: (none) => ouaurelien
Target Milestone: Mageia 8 => Mageia 9
Whiteboard: (none) => MGA7TOO MGA8TOO
Source RPM: draksnapshot-0.20.3-18.mga7.src.rpm => draksnapshot-0.20.3-19.mga8.src.rpm
Version: 7 => Cauldron
Hardware: x86_64 => All
Severity: normal => major
Status comment: (none) => patches proposed

Yes still since at least 2017 in Bug 21260 

Mageia 8 - 64, Plasma:
Started MCC from Konsole,
Selected snapshot and it installed draksnapshot and deps.
Then the GUI got stuck at "Loading... Wait" (translated)
In Konsole i see: same output as in comment 0

And same if i start draksnapshot-config in Konsole.

Also same it i launch draksnapshot-applet.

draksnapshot-restore do launch GUI, and say it need be run as root.
(sidenote: it could be improved to ask for privilegies)

https://wiki.mageia.org/en/Mageia_8_Errata#Various_software

CC: (none) => fri
Keywords: (none) => IN_ERRATA8

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

CC: (none) => lloyd.osten

Hi.

I attempted to run the patch and same result as comment 22.

so, any chance of having another look?

thanks for your efforts so far!

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

CC: (none) => 79625490833

Hello,

It is not patchs, but you might try the zip file here ( just a try to make it work).

https://www.mageialinux-online.org/forum/topic-15594-4+draksnapshot-ne-marche-pas.php#m283933

"draksnapshot-applet" and "draksnapshot-restore" files to put in /usr/sbin/
"draksnapshot-config" to put in /usr/libexec"
"Hal.pm" and "restore.pm" to put in /usr/share/perl5/vendor_perl/MDV/Snapshot/ 
"rsnapshot.conf" in /etc ( note it is not the one in rsnapshot package)...

hal is not really supported ;-) so media detection is not real.

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

CC: (none) => joselp

I just downloaded and installed Mageia 9 Alpha and I'm pleased to report that draksnapshot is now working as expected. The /etc/rsnapshot.conf file is constructed and the cron entries (in hourly, daily, weekly and monthly) are created.

The only "nit" I would pick is that upon completing the configuration (clicking the "Apply" button) there is no action taken to confirm that the process has completed. 

I hope it's OK that I've selected the "RESOLVED" and "FIXED" options in this bug reporting system. Neither "UNRESOLVED" nor "NEW" were applicable...

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Thank you for the testing and update.

I assume it is still valid for mga8 though.

mga7 is EOS.

Version: Cauldron => 8
Whiteboard: MGA7TOO MGA8TOO => (none)
Target Milestone: Mageia 9 => ---
Keywords: FOR_ERRATA9 => (none)
Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

seems to be fixed in Mga9 

Thanks, tv

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED