HUBackup

Bug #64594
Comment #43

Comment 43 for bug 64594

Revision history for this message

Felipe Figueiredo (philsf) wrote on 2009-04-05: Re: [Bug 64594] Re: hurestore will always crash on startup (unfinished tool)

#43

Martin Bergner escreveu:
> It was a bad decision to promote hubackup (which works in most cases)
> and hurestore as a main backup tool since they are not finished. I tried
> to help Sivan getting hurestore to work, but didn't succed.
>
Martin,

do you agree it would be best to develop hubackup off the distribution,
and re-include it in the archive when it's ready? Without further
frustrating users

do you think maybe it would be best to develop hubackup off the
distribution, and re-include it in the archive when it's ready?

> Maybe someone else has a better idea, so I will create some background
> information for someone to start.
>
> The problem with hurestore is, that you need to create an interface to
> dar.
>
> I tried the dar python bindings, but they are unstable and also
> unfinished. I have a bzr branch on lp for both the bindings (dar-python)
> and hurestore (look in my branches) which uses these bindings and can
> show the contents of the archive. The problem is however, that there you
> cannot have any statistics about the archive (the bindings fail there
> and I didn't get them to work) and that is needed at some point.
>
This doesn't explain why the restore GUI refuses to start. Why does it
happen?

> I also tried to interface dar directly, but is this error-prone and
> quite slow. The usage of appropriate bindings would be much better.
>
> I am willing to help anyone starting on that, but you should have some
> (or better good) knowledge on python, pygtk, python bindings, swig, c++
> and (at the end) building debian packages. I think that these are a lot
> of requirements for such a small tool. Of course, the swig and binding
> part is optional, but preferred. Dar is written in C++, so is the
> library. If you want to use (fix) the bindings you need to know that as
> well.
>
> Contact me if you like to help.
>
It seems dealing with dar itself is a compromise of time, and
availability of a proper binding. I have some Perl skills, and have seen
Python, maybe I can help with that if there's some prototype somewhere
to give a headstart. If the GUI (pygtk) was at least working, it could
be a fast thing (not for Jaunty anymore).

Anyway, IMHO it should be removed from the archives until it's finished.

regards
FF

do you agree it would be best to develop hubackup off the distribution,
and re-include it in the archive when it's ready? Without further
frustrating users

do you think maybe it would be best to develop hubackup off the
distribution, and re-include it in the archive when it's ready?

> Maybe someone else has a better idea, so I will create some background
> information for someone to start.
>
> The problem with hurestore is, that you need to create an interface to
> dar.
>
> I tried the dar python bindings, but they are unstable and also
> unfinished. I have a bzr branch on lp for both the bindings (dar-python)
> and hurestore (look in my branches) which uses these bindings and can
> show the contents of the archive. The problem is however, that there you
> cannot have any statistics about the archive (the bindings fail there
> and I didn't get them to work)  and that is needed at some point.
>   
This doesn't explain why the restore GUI refuses to start. Why does it
happen?

> I also tried to interface dar directly, but is this error-prone and
> quite slow. The usage of appropriate bindings would be much better.
>
> I am willing to help anyone starting on that, but you should have some
> (or better good) knowledge on python, pygtk, python bindings, swig, c++
> and (at the end) building debian packages. I think that these are a lot
> of requirements for such a small tool. Of course, the swig and binding
> part is optional, but preferred. Dar is written in C++, so is the
> library. If you want to use (fix) the bindings you need to know that as
> well.
>
> Contact me if you like to help.
>   
It seems dealing with dar itself is a compromise of time, and
availability of a proper binding. I have some Perl skills, and have seen
Python, maybe I can help with that if there's some prototype somewhere
to give a headstart. If the GUI (pygtk) was at least working, it could
be a fast thing (not for Jaunty anymore).

Anyway, IMHO it should be removed from the archives until it's finished.

regards
FF