System Restore

[OutOfReach]

@LaRoza on imports. Do you mean how the Qt interface imports the Qt modules or the sysres core modules? I changed the way the Qt interface imports the Sysres Core module in the last update (see my branch).

If you do mean the way the Qt interface import Qt modules than I'll happily change the way the importing is done.

[LaRoza]

Hi
I'm very interested in this.

In fact it should work like honey on OzOS, since it is a slim (X)Ubuntu base and a highly system-independent DE (all implemented in a single folder).
We have already self made tools for backup and restore DE, so with a System Restore application, in our case, we will have *really* all our bases covered

Ah, good. It will work on any Linux (meaning: run and do what it is told), but to use the gui's you need python-qt4 or python-gtk (or whatever it is called, it is installed by default on Ubuntu). The CLI version could conceivably run in Windows, but it wouldn't work in the same way.

The only thing that don't shows it's icon, since it's a svg.
Can you include a png image too (with same name so .desktop would not require changes on Icon)?

We'll try to get it in for 1.0.2.

Some bugs (vers 1.0.1 deb):
If i select 'Use custom directory' and change Add files to Defaults choice, it seems to ignore the new adds. On Default directory works correctly.

That really depends on what GUI you are using, and I don't do squat for the GUI's

I use the CLI version, which I wrote, and has no bugs. (Because it is CLI and more linear)

Ahh the fame... well that i can't offer, but since it's a GPL project I'm thinking in include it by default on OzOS repos and future versions.
Thank you.

Please wait until 1.0.2. 1.0.1 has some bugs (that looks like an IP address of a sort, too many .)

The code of 1.0.1 and 1.0.2 is not for the future, so any work you do would best be done with trunk, however, trunk has a few issues with the GUI's related to error handling because the driving force behind that started while work was being done on 1.0 and 0.9 and the GUI devs haven't seen it yet (well, at least, not developing with yet)

[LaRoza]

@LaRoza on imports. Do you mean how the Qt interface imports the Qt modules or the sysres core modules? I changed the way the Qt interface imports the Sysres Core module in the last update (see my branch).

If you do mean the way the Qt interface import Qt modules than I'll happily change the way the importing is done.

No, for sysres Core.

It is fixed in trunk though. Merge with it remember.

For the importing of the other things, the interfaces are now independant of everything, so as long as it works and you can maintain it, it is fine.

[Rui Pais]

Ah, good. It will work on any Linux (meaning: run and do what it is told), but to use the gui's you need python-qt4 or python-gtk (or whatever it is called, it is installed by default on Ubuntu). The CLI version could conceivably run in Windows, but it wouldn't work in the same way.


We'll try to get it in for 1.0.2.


That really depends on what GUI you are using, and I don't do squat for the GUI's

I use the CLI version, which I wrote, and has no bugs. (Because it is CLI and more linear)

Here, on OzOS i run both from command line and menu and always get the gtk version...
It would be nice if would have some way of run desired interface with a flag ot a different start script (like: sysres -g or sysres-gtk)
For such kind of actions I usually prefer the CLI too (it's weird restore a system from a running DE...)

Another useful thing would be the ability of add full directory to default to backup, instead of single files, for things like user tune of pm/acpi for suspend or HD parking issues or the simpler case of sources.list implemented on /etc/apt.sources.d/*.list

Please wait until 1.0.2. 1.0.1 has some bugs (that looks like an IP address of a sort, too many .)

The code of 1.0.1 and 1.0.2 is not for the future, so any work you do would best be done with trunk, however, trunk has a few issues with the GUI's related to error handling because the driving force behind that started while work was being done on 1.0 and 0.9 and the GUI devs haven't seen it yet (well, at least, not developing with yet)

Ok. No problem at all.
(Let me know if you need help testing or packaging.)

[LaRoza]

Here, on OzOS i run both from command line and menu and always get the gtk version...
It would be nice if would have some way of run desired interface with a flag ot a different start script (like: sysres -g or sysres-gtk)

sysres --qt

There are four options:

• sysres --cli
• sysres --gtk
• sysres --qt

The fourth is done by command line arguments only (no interface) for ease of use for...me (I wrote it entirely for me) and has several options.

Another useful thing would be the ability of add full directory to default to backup, instead of single files, for things like user tune of pm/acpi for suspend or HD parking issues or the simpler case of sources.list implemented on /etc/apt.sources.d/*.list

The way it works, it wouldn't be able to do a directory. By its design, it doesn't. It is meant to be a system restore, not a backup program.

Ok. No problem at all.
(Let me know if you need help testing or packaging.)

Testing of lp:sysres/1.0 would be beneficial, you can run it from the directory completely. Do you use bzr?

Packaging is covered by mssever but any suggestions (non of us are packagers, and he is new to it) are helpful.

[Rui Pais]

sysres --qt

There are four options:

• sysres --cli
• sysres --gtk
• sysres --qt

The fourth is done by command line arguments only (no interface) for ease of use for...me (I wrote it entirely for me) and has several options.

Ah silly me! i not even tried the obvious (i'm tired...)

The way it works, it wouldn't be able to do a directory. By its design, it doesn't. It is meant to be a system restore, not a backup program.

Yes, i understand.

Testing of lp:sysres/1.0 would be beneficial, you can run it from the directory completely. Do you use bzr?

Packaging is covered by mssever but any suggestions (non of us are packagers, and he is new to it) are helpful.

Ok i'll try it the source with bzr.
I'll check package. Look quite good.
My only suggestion, as i said, would be both png and svg icons to cover a large number of DEs and maybe a .desktop file or a mini script to run the cli version independently of DE... but maybe kind of redundant...
i see it recommends python-gtk it should be python-gtk2 or if python-gtk it's fromother non-ubuntu version recommends/depends on both :
Recommends: python-gtk2|python-gtk
on control file.

[mssever]

First, a comment about the recent file reshuffling: It appears to me (though I can't be certain) that the files were moved, then added back in to bzr. I say that, because those files have completely lost their history. Furthermore, doing things like this can in some cases cause merge conflicts that would otherwise be avoided. Bazaar has a command to prevent this situation and allow bzr to keep track of renames: bzr mv. The idea is, all filesystem operations should be done with bzr commands whenever such a command is available.

The only thing that don't shows it's icon, since it's a svg.
Can you include a png image too (with same name so .desktop would not require changes on Icon)?

I'll work on that. I'm a bit surprised, though, that e17 doesn't support SVG. Perhaps it's showing its age.

Just a "contribution" for desktop file, Pt translation:

Thanks I added it to my main branch. LaRoza, my branch has some things for merging into trunk. Also, you can take just revision 62 and merge it into 1.0 to get the updated translation.

Please wait until 1.0.2. 1.0.1 has some bugs (that looks like an IP address of a sort, too many .)

Is 1.0.2 ready for release now? The launchsysres script will workaround the bug you mentioned, and it's in 1.0.

(Let me know if you need help testing or packaging.)

If you have experience with packaging, I'd appreciate a code review (feel free to be blunt). I'm the packager, and it's my first time. I've also been toying with the idea of creating separate packages, like nvteighen suggested: sysres-common, sysres-qt, sysres-gtk, sysres-cli (sysres-common should probably recommend sysres-cli, sysres-gtk | sysres-qt, and of course all the interface packages would depend on sysres-common). As this is an area in which I have no experience, suggestions, criticisms and/or code would be welcome. For packaging, you can track lp:sysres or my main branch, lp:~scott.severance/sysres/main.

[mssever]

i see it recommends python-gtk it should be python-gtk2 or if python-gtk it's fromother non-ubuntu version recommends/depends on both :
Recommends: python-gtk2|python-gtk
on control file.

Could you elaborate a bit? What is the advantage of depending on python-gtk2 over python-gtk? <Later...> I just looked, and apparently python-gtk is a virtual package. But python-gtk2 doesn't provide it, so what does? I'll change the dependency as you recommended.

[OutOfReach]

Conflicts are such a pain. Even when I use bzr resolve it still leaves some ====TREE things in some files, really annoying.

As a note to LaRoza: I hope you don't mind me doing this (tell me if you do), but I am changing the core logging a bit, as it currently is the core only writes out the name of the restore point when it is created, which can seem a little confusing to an average user. I am changing it so it writes something like:

[16:44:59.028179] Created: /home/username/.sysres/Backups--2008-09-18 16:44:56.729055

so that it will be more 'readable' to the average user looking through it.

[mssever]

Conflicts are such a pain. Even when I use bzr resolve it still leaves some ====TREE things in some files, really annoying.

I'm not sure what you're doing, but here's how I handle conflicts. For the sake of this post, let's assume that the conflict is in changelog (which is where they seem to crop up the most for me).

meld changelog.*
# meld will show you a three-way diff, which you can use to determine what should
# happen. Usually, *.OTHER is the proper file to use. Meld allows editing in case that
# should be necessary.
# Assuming you're resolving in favor of changelog.OTHER (possibly with some edits):
mv changelog{.OTHER,}
bzr resolve changelog

And you're done...unless you have more conflicts to resolve.