backuppc-devel — BackupPC developer list

[BackupPC-devel] RFE: Combing include and exclude in rsyncd backups

[Kenneth P. <sh...@se...>]

It would be nice if I could combine exclude and include in an rsyncd 
backup. That way I could back up a subdirectory within a module but still 
exclude directories within that directory. Ie. apply the exclude list after 
the include list. Is this a protocol limitation or a BackupPC limitation?

Example:

Host provides "C" module exposing C:\ for backup. I have backups like this:

C\devel\Boost (just the Boost C++ libraries)
C\devel (all development except Boost)
C (the rest of the drive)

Currently I have to list all the directories under C\devel for the include 
list. I'd rather have it recognize an exclude list of just C\devel\Boost so 
that when a user adds a new directory under C\devel I don't have to modify 
the backup configuration.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [BackupPC-devel] IPv6 support?

[Craig B. <cba...@us...>]

BackupPC 4.0 is backward compatible with 3.x backup storage - they can be
viewed/restored etc.  I just pushed an optional migration
tool, BackupPC_migrateV3toV4, that replaces the hardlinked 3.x storage in
each backup with 4.x-style attrib files and reference counting.  So you can
use that to get rid of all the 3.x hardlinks if you want, but it's not
necessary.

That said, the 4.0 client configuration has changed for rsync hosts due to
the use of rsync_bpc, so a package upgrade from 3.x to 4.x will potentially
require some admin effort to update the client configs.  So I agree it
won't be a completely seamless upgrade.

What do other people recommend in terms of having a new package name for
BackupPC 4.x?

Craig

On Mon, Mar 13, 2017 at 9:23 AM, Fritz Elfert <fr...@fr...> wrote:

> Please don't!!!
>
> Reason:
>
> AFAIK, backup data v3 is incompatible with backup data v4 and there's
> now way to properly upgrade existing backup data. So a dnf update would
> make all existing backup data inacessible all of a sudden which would
> probably piss of many existing users. At least it would piss of me.
>
> Instead, make a second package "backuppc4".  This way, user can have
> both versions installed and then gracefully migrate.
>
> Thanks
>  -Fritz
>
> On 13.03.2017 14:49, Richard Shaw wrote:
> > I just took over maintenance of the BackupPC package for Fedora and EPEL
> > and I'm working on updating the package to version 4.
> >
> > There are several patches which I should probably share here to see if
> > they are necessary or if some form of them can be included upstream but
> > for now I need some feedback if this patch is still needed for IPv6
> support.
> >
> > https://src.fedoraproject.org/cgit/rpms/BackupPC.git/tree/
> BackupPC-3.3.1-IPv6-support.patch
> >
> > Thanks,
> > Richard
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Announcing the Oxford Dictionaries API! The API offers world-renowned
> > dictionary content that is easy and intuitive to access. Sign up for an
> > account today to start using our lexical data to power your apps and
> > projects. Get started today and enter our developer competition.
> > http://sdm.link/oxford
> >
> >
> >
> > _______________________________________________
> > BackupPC-devel mailing list
> > Bac...@li...
> > List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
> > Wiki:    http://backuppc.wiki.sourceforge.net
> > Project: http://backuppc.sourceforge.net/
> >
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> BackupPC-devel mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>

Re: [BackupPC-devel] IPv6 support?

[Craig B. <cba...@us...>]

Thanks for the patch.  I applied the same patch to 4.0 a couple of months
ago, but made some edits (in particular, PingPath6 should be Ping6Path, and
"resolve()" is too generic - I changed that to getHostAddrInfo().

I'd apply the patch to 3.x if you mirrored the 4.0 changes, and ideally
submitted a pull request against github 3.x.

Craig

On Mon, Mar 13, 2017 at 6:49 AM, Richard Shaw <hob...@gm...> wrote:

> I just took over maintenance of the BackupPC package for Fedora and EPEL
> and I'm working on updating the package to version 4.
>
> There are several patches which I should probably share here to see if
> they are necessary or if some form of them can be included upstream but for
> now I need some feedback if this patch is still needed for IPv6 support.
>
> https://src.fedoraproject.org/cgit/rpms/BackupPC.git/tree/
> BackupPC-3.3.1-IPv6-support.patch
>
> Thanks,
> Richard
>
> ------------------------------------------------------------
> ------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> BackupPC-devel mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>

Re: [BackupPC-devel] IPv6 support?

[Alexander M. <mo...@me...>]

On 3/13/17 7:23 PM, Fritz Elfert wrote:
> AFAIK, backup data v3 is incompatible with backup data v4 and there's
> now way to properly upgrade existing backup data. So a dnf update would
> make all existing backup data inacessible all of a sudden which would
> probably piss of many existing users. At least it would piss of me.
> 
That is not correct. v3 pool  backups are accessible from BackupPC v4.

> Instead, make a second package "backuppc4".  This way, user can have
> both versions installed and then gracefully migrate.

You can't use both v3 and v4 on the same host as they install files in the same place.

However, keeping v3 package "backuppc" and making "backuppc4" package for v4 is a quite good point as a lot of people use v3 in production and changes between v3 and v4 are substantial.

BTW v3 support is not dropped by upstream yet.

Re: [BackupPC-devel] IPv6 support?

[Fritz E. <fr...@fr...>]

Please don't!!!

Reason:

AFAIK, backup data v3 is incompatible with backup data v4 and there's
now way to properly upgrade existing backup data. So a dnf update would
make all existing backup data inacessible all of a sudden which would
probably piss of many existing users. At least it would piss of me.

Instead, make a second package "backuppc4".  This way, user can have
both versions installed and then gracefully migrate.

Thanks
 -Fritz

On 13.03.2017 14:49, Richard Shaw wrote:
> I just took over maintenance of the BackupPC package for Fedora and EPEL
> and I'm working on updating the package to version 4.
> 
> There are several patches which I should probably share here to see if
> they are necessary or if some form of them can be included upstream but
> for now I need some feedback if this patch is still needed for IPv6 support.
> 
> https://src.fedoraproject.org/cgit/rpms/BackupPC.git/tree/BackupPC-3.3.1-IPv6-support.patch
> 
> Thanks,
> Richard
> 
> 
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> 
> 
> 
> _______________________________________________
> BackupPC-devel mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
> 

Re: [BackupPC-devel] IPv6 support?

[Alexander M. <mo...@me...>]

On 13.03.2017 16:49, Richard Shaw wrote:
> I just took over maintenance of the BackupPC package for Fedora and EPEL and I'm working on updating the package to version 4.
> 
> There are several patches which I should probably share here to see if they are necessary or if some form of them can be included upstream but for now I need some feedback if this patch is still needed for IPv6 support.
> 
> https://src.fedoraproject.org/cgit/rpms/BackupPC.git/tree/BackupPC-3.3.1-IPv6-support.patch
> 
They are already included in v4:

https://github.com/backuppc/backuppc/commit/6df4c4e8126d9c1df2e6b4843133a6661b64d5c4

[BackupPC-devel] IPv6 support?

[Richard S. <hob...@gm...>]

I just took over maintenance of the BackupPC package for Fedora and EPEL
and I'm working on updating the package to version 4.

There are several patches which I should probably share here to see if they
are necessary or if some form of them can be included upstream but for now
I need some feedback if this patch is still needed for IPv6 support.

https://src.fedoraproject.org/cgit/rpms/BackupPC.git/tree/BackupPC-3.3.1-IPv6-support.patch

Thanks,
Richard

Re: [BackupPC-devel] [BackupPC-users] BackupPC 4.0.0 released

[Craig B. <cba...@us...>]

>
> Will this release be repacked and put on a repo for an easy install with
> e.g. yum?


Other volunteers create the repo packages, so hopefully they are working on
it!

Craig

On Mon, Mar 6, 2017 at 5:34 AM, Sorin Srbu <Sor...@or...> wrote:

> >From: Craig Barratt [mailto:cba...@us...]
> >Sent: den 4 mars 2017 20:13
> >To: General list for user discussion, questions and support
> ><bac...@li...>;
> >bac...@li...; Developers discussion
> ><backuppc->de...@li...>
> >Subject: [BackupPC-users] BackupPC 4.0.0 released
> >
> >I'm happy to announce that BackupPC 4.0.0 has been released on Github and
> >SourceForge.
>
> Nice, thanks Craig!
>
> It's been awhile since I installed BackupPC...
>
> Will this release be repacked and put on a repo for an easy install with
> e.g.
> yum?
>
> --
> //Sorin
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> BackupPC-users mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>

[BackupPC-devel] BackupPC 4.0.0 released

[Craig B. <cba...@us...>]

BackupPC community,

I'm happy to announce that BackupPC 4.0.0 has been released on Github
<https://github.com/backuppc/backuppc/releases> and SourceForge
<https://sourceforge.net/projects/backuppc/files/backuppc/4.0.0/>.

BackupPC 4.0.0 is a significant improvement over 3.x in terms of
performance and storage efficiency. It is backward compatible with 3.x
storage, so it can be used to upgrade an existing V3 installation as well
as for brand new installs.

BackupPC 4.0.0 requires the perl module BackupPC::XS
<https://github.com/backuppc/backuppc-xs/releases> (>= 0.50) and rsync-bpc
<https://github.com/backuppc/rsync-bpc/releases> (>= 3.0.9.5).

After installing those two packages, BackupPC 4.0.0 can be installed from
the tar ball with:

    tar zxf BackupPC-4.0.0.tar.gz
    cd BackupPC-4.0.0
    perl configure.pl

See the README.md, ChangeLog and doc/BackupPC.html
<http://backuppc.sourceforge.net/BackupPC-4.0.0.html> files for more
information.  An overview of the major changes is below.

Thanks for to everyone who provided fixes and reported issues with the
alpha and github versions.

Enjoy!!

Craig

Here's a summary of the most significant changes in V4:

   - No use of hardlinks (except temporarily to do atomic renames).
   Reference counting is handled at the application level in a batch manner
   (hardlinks will still remain for any legacy V3 backups).
   - Backups are stored as "reverse deltas" - the most recent backup is
   always filled and older backups are reconstituted by merging all the deltas
   starting with the nearest future filled backup and working backwards.
   - This is the opposite of V3 where incrementals are stored as "forward
   deltas" to a prior backup (typically the last full backup or prior
   lower-level incremental backup, or the last full in the case of rsync).
   - Since the most recent backup is filled, viewing/restoring that backup
   (which is the most common backup used) doesn't require merging any deltas
   from other backups.
   - The concepts of incr/full backups and unfilled/filled storage are
   decoupled. The most recent backup is always filled. By default, for the
   remaining backups, full backups are filled and incremental backups are
   unfilled, but that is configurable.
   - Uses full-file MD5 digests, which are stored in the directory attrib
   files.  Each backup directory only contains an empty attrib file whose name
   includes its own MD5 digest, which is used to look up the attrib file's
   contents in the pool.  In turn, that file contains the metadata for every
   file in that directory, including each files's MD5 digest.
   - The Pool layout still supports chains to handle md5 collisions. While
   collisions can be constructed and are now well-known, they are highly
   unlikely in the wild. Pool files are never renamed or moved, unlike V3.
   - Any backup can be deleted (deltas are merged into next older backup if
   it is not filled).
   - The reverse deltas allow "infinite incrementals" - no need for a full
   backup if you are willing to trade speed for the risk that a file change
   will not be detected if the metadata (eg, mtime or size) doesn't change.
   - An rsync "full" backup now uses --checksum (instead of
   --ignore-times), which is much more efficient on the server side - the
   server just needs to check the full-file checksum computed by the client,
   together with the mtime, nlinks, size attributes, to see if the file has
   changed. If you want a more conservative approach, you can change it back
   to --ignore-times, which requires the server to send block checksums to the
   client.
   - The use of rsync --checksum allows BackupPC to guess a potential match
   anywhere in the pool, even on a first-time backup. In that case, the usual
   rsync block checksums are still exchanged to make sure the complete file is
   identical.
   - Uses a modified rsync called rsync_bpc (currently based on
   rsync-3.0.9) on the server side (in place of File::RsyncP), with a C code
   interface to the BackupPC storage. So the whole data path for rsync is now
   in compiled C code, which is much faster than perl.
   - Due to the use of rsync-3.X, acls and xattrs are supported, and many
   other useful options (but not all) are supported. Rsync protocol 30
   supports the efficient incremental file list, which significantly improves
   memory usage and startup time. It also supports MD5 full-file checksums,
   which match BackupPC's new digest. That allows a full-file digest to be
   checked as easily as an mtime on the server side.
   - Significant portions of the BackupPC code are now compiled C code in a
   new module called BackupPC::XS that is dynamically linked to perl.
   - V3 migration: nothing specific is needed. V4 can browse/view/restore
   V3 backups. When you install V4, no changes are made to any V3 backups. If
   you are upgrading from V3, be sure to set $Conf{PoolV3Enabled} to 1 so the
   old V3 pool is searched for matching files.
      - When you install V4, it will notice that the V3 pool exists.
      Running configure.pl should set $Conf{PoolV3Enabled} to 1 in that
      case, but you should be sure to check that.
      - When a V4 backup is first done, BackupPC_backupDuplicate is run to
      duplicate the most recent V3 backup to create a new V4 backup. A "filled"
      view of the most recent V3 backup is used to create a "filled" V4 backup
      tree.
      - This step could be time consuming, since every file needs to be
      read (as a V3 file) and written as a V4 file. However, the V4
pooling code
      knows about the V3 pool, so it will move the V3 pool file into
the V4 pool.
      So this duplication process doesn't burn a lot of pool storage space, but
      every file still needs to be read (to compute the MD5 digest)
and "written"
      (really just matching/linking).
      - Expiry: all the V3 + V4 backups are considered on a combined basis
      for expiry checking.
      - On a clean new V4 install, the steps of computing and checking V3
      digests is eliminated.

Re: [BackupPC-devel] BackupPC 3.3.2 released

[Joe B. <jo...@ts...>]

+1


On 08/02/17 00:00, Nick van IJzendoorn wrote:
> Yeah, 5 years and counting! Good peace of software! :)
>
> On Feb 7, 2017 23:51, "Johan Cwiklinski" <mai...@ul... 
> <mailto:mai...@ul...>> wrote:
>
>     Hello,
>
>     Le 07/02/2017 à 12:21, Juergen Harms a écrit :
>     > Craig, just giving voice to what probably everybody is thinking:
>     thank
>     > you for finding the time to keep BackupPC at its high level of
>     quality!
>
>     Juergen is right.
>
>     I'm using BackupPC for years, it already save my time (a *lot* of my
>     time!) several times...
>
>     Thank you very much Craig for all the job you do on this lovely
>     project!
>
>     Cheers,
>     --
>     Johan
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>     _______________________________________________
>     BackupPC-devel mailing list
>     Bac...@li...
>     <mailto:Bac...@li...>
>     List: https://lists.sourceforge.net/lists/listinfo/backuppc-devel
>     <https://lists.sourceforge.net/lists/listinfo/backuppc-devel>
>     Wiki: http://backuppc.wiki.sourceforge.net
>     <http://backuppc.wiki.sourceforge.net>
>     Project: http://backuppc.sourceforge.net/
>     <http://backuppc.sourceforge.net/>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> BackupPC-devel mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/

Re: [BackupPC-devel] BackupPC 3.3.2 released

[Nick v. I. <nij...@en...>]

Yeah, 5 years and counting! Good peace of software! :)

On Feb 7, 2017 23:51, "Johan Cwiklinski" <mai...@ul...> wrote:

> Hello,
>
> Le 07/02/2017 à 12:21, Juergen Harms a écrit :
> > Craig, just giving voice to what probably everybody is thinking: thank
> > you for finding the time to keep BackupPC at its high level of quality!
>
> Juergen is right.
>
> I'm using BackupPC for years, it already save my time (a *lot* of my
> time!) several times...
>
> Thank you very much Craig for all the job you do on this lovely project!
>
> Cheers,
> --
> Johan
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> BackupPC-devel mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>

Re: [BackupPC-devel] BackupPC 3.3.2 released

[Johan C. <mai...@ul...>]

Hello,

Le 07/02/2017 à 12:21, Juergen Harms a écrit :
> Craig, just giving voice to what probably everybody is thinking: thank 
> you for finding the time to keep BackupPC at its high level of quality!

Juergen is right.

I'm using BackupPC for years, it already save my time (a *lot* of my
time!) several times...

Thank you very much Craig for all the job you do on this lovely project!

Cheers,
-- 
Johan

Re: [BackupPC-devel] BackupPC 3.3.2 released

[Juergen H. <jue...@un...>]

Craig, just giving voice to what probably everybody is thinking: thank 
you for finding the time to keep BackupPC at its high level of quality!

Juergen

[BackupPC-devel] Delete 4.0.0 branch on github

[Craig B. <cba...@us...>]

I plan to delete the 4.0.0 branch on github.

Currently the master branch has all the 4.x development, and the 3.x.x
branch is the prior major version.

Does anyone have an issue with me doing that?

Craig

[BackupPC-devel] BackupPC 3.3.2 released

[Craig B. <cba...@us...>]

I'm pleased to announce that BackupPC 3.3.2 was released a few days ago on
Github <https://github.com/backuppc/backuppc/releases> and SF.net
<http://backuppc.sourceforge.net/>.  It's a minor release with a couple of
small changes.

The ChangeLog is below.

Craig

#------------------------------------------------------------------------
# Version 3.3.2, 25 Jan 2017
#------------------------------------------------------------------------

* Updates to bin/BackupPC_dump and lib/BackupPC/Xfer/Smb.pm from maksyms to
fix
  incompatabilities with Samba 4.3 (#22)

* Sort hash of config editor tabs in lib/BackupPC/CGI/EditConfig.pm from
  polo (#23)

* Fixes to bin/BackupPC_sendEmail to avoid per-host overwrite of
EMailAdminUserName
  from derrickdominic (#30)

* Fixed minor typos in several language files; from Alexander Moisseev

* Updated deprecated syntax (defined(@array) and "{" in regexps) from
  Alexander Moisseev.

* Documentation updates from Alexander Moisseev.

Re: [BackupPC-devel] Security issue

[Craig B. <cba...@us...>]

Feel free to send it directly to me.

Craig

On Tue, Jan 24, 2017 at 1:13 AM, Frank Spierings <fr...@wa...> wrote:

> Where can I safely drop a possible security issue?
>
> Regards,
>
> Frank
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> BackupPC-devel mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>

[BackupPC-devel] Security issue

[Frank S. <fr...@wa...>]

Where can I safely drop a possible security issue?

Regards,

Frank

Re: [BackupPC-devel] [BackupPC-users] Error Rsync Unexpected empty share name skipped

[Holger P. <wb...@pa...>]

Hi,

Adam Goryachev wrote on 2016-10-04 09:16:47 +1100 [Re: [BackupPC-users] Error Rsync Unexpected empty share name skipped]:
> On 04/10/16 02:36, Orazio Di nino wrote:
> > [...]
> >I have this error in the log /var/lib/backuppc/pc/192.168.2.80/LOG102016:
> >
> >-full backup started for directory /tecno
> >-unexpected empty share name skipped
> >-Backup aborted

well, have you got an empty share name in your configuration? Hint: a share
named '' (the empty string) does not make any sense. Further hint: BackupPC
says you do, so you probably do. If it's not clear, you want to look at the
value of $Conf {RsyncShareName} ...

I believe you've actually found a bug in BackupPC_dump, though. Apparently,
an empty (or duplicate) share name generates a warning only, unless it is
the last share for the host, in which case it causes the backup to fail.
That does not make sense. It should either always be a fatal error or never.
Patch attached (one of these days, I'll have a look at git ...).

> > [...]
> >Negotiated protocol version 28
> >Xfer PIDs are now 16298,16299
> >[ saltate 47 righe ]
> >Done: 37 files, 85325611 bytes
> > [...]
> >
> I think the first thing to do is get rsync to talk in US English, I
> don't think backuppc will understand any other language.

Actually, the line quoted above would seem to be generated by
BackupPC::CGI::View ;-), but I agree that quoting foreign language
diagnostic messages tends to be confusing. While for tar/smb xfer
language is important (because the diagnostic output is parsed),
I believe for rsync(d), that is not the case (but I might be
mistaken).

Regards,
Holger

[BackupPC-devel] Hardlink testing still present

[Johan E. <jo...@eh...>]

Hi,

I am exploring various scenarios with BackupPC 4 using object storage 
and cloud file systems.

One of them uses zfs on a local SSD for metadata (pc) and gluster for 
pool (cpool). I noticed that the installation is still checking for 
hardlinkability between these. Should that be removed or is there 
something still using hardlinks?

Best regards,
Johan Ehnberg

-- 
Johan Ehnberg
jo...@eh...
johan.ehnberg.net
+358503209688

Re: [BackupPC-devel] Git branching

[François <ai...@gm...>]

On Tue, Aug 02, 2016 at 09:12:39PM -0700, Craig Barratt wrote:
> Yes, github is now official for all three projects.  The master branch has
> a number of changes / fixes for 4.x, and should be in releasable form.  I'm
> (slowly) working on Ftp.pm, which should be the last thing before a 4.0
> release.

Looks like I'll have to delete 3 repos on github then!
I do have some issues installing a working 4.0 version, no backups are performed.
Where should I ask for help?

-- 
François

Re: [BackupPC-devel] Git branching

[Craig B. <cba...@us...>]

Yes, github is now official for all three projects.  The master branch has
a number of changes / fixes for 4.x, and should be in releasable form.  I'm
(slowly) working on Ftp.pm, which should be the last thing before a 4.0
release.

I committed some changes to rsync_bpc and backuppc-xs that fixes a subtle
crash, and I closed the corresponding issue.

Craig

On Tue, Aug 2, 2016 at 4:54 AM, Lars Tobias Skjong-Børsting <
li...@re...> wrote:

> On 02/08/16 10:52, Alexander Moisseev wrote:
>
> > It looks like Craig have converted (or started converting by hand
> release code to source) and started commiting in the master. As I take it,
> he doesn't have source code at all. Or I completely don't understand his
> intentions.
>
> Oh, wow, I didn't look at the github repo before posting. That's great.
> I suppose that means that we've officially moved to github.
>
> --
> Lars Tobias
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> BackupPC-devel mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>

Re: [BackupPC-devel] Git branching

[Lars T. Skjong-B. <li...@re...>]

On 02/08/16 10:52, Alexander Moisseev wrote:

> It looks like Craig have converted (or started converting by hand release code to source) and started commiting in the master. As I take it, he doesn't have source code at all. Or I completely don't understand his intentions.

Oh, wow, I didn't look at the github repo before posting. That's great.
I suppose that means that we've officially moved to github.

-- 
Lars Tobias

Re: [BackupPC-devel] Git branching

[Alexander M. <mo...@me...>]

On 02.08.16 10:21, Lars Tobias Skjong-Børsting wrote:
> It seems we are not going to get the v4 CVS tree anytime soon. Should we
> make a plan to carry on forward with what we have already?
>

It looks like Craig have converted (or started converting by hand release code to source) and started commiting in the master. As I take it, he doesn't have source code at all. Or I completely don't understand his intentions.

Re: [BackupPC-devel] Git branching

[Lars T. Skjong-B. <li...@re...>]

Hi,

It seems we are not going to get the v4 CVS tree anytime soon. Should we
make a plan to carry on forward with what we have already?

-- 
Best regards,
Lars Tobias

[BackupPC-devel] New Fedora packager

[Benjamin L. <le...@fe...>]

Hi,

Just a notification that I went through with this and took over
packaging on Fedora and EPEL (RHEL, CentOS, Scientific Linux…) since
the previous packager was gone.

https://apps.fedoraproject.org/packages/BackupPC

BZ: https://bugzilla.redhat.com//show_bug.cgi?id=1342138

If no one here objects, I would like to change the upstream source to
github.

Regards,

Benjamin Lefoul (lef)