Have you let AI loose on the BackupPC codebase to: - Identify bugs & vulnerabilities - Improve robustness, logging, etc (wherever you think there is a lag) - Identify speed/efficiency improvements - including possibly moving other code to C to make it faster (if it would give a significant speedup)
G.W. Haywood wrote at about 17:47:36 +0100 on Friday, October 2, 2026: > Hi there, > > [BackupPC maintainer hat on.] > > On Thu, 1 Oct 2026, Robert Howard wrote: > > > The latest tag in Github for BackupPC? is 4.4.1rc1 and this tag is 11 > > months old. There have been a number of code changes since then. When > > will a more recent tag be created? Is there an estimate of when will the > > BackupPC? 4.4.1 general release will occur? Also when will the ancillary > > programs updates be completed? > > > > The reason I ask this is the Linux distributions I use will not package > > and ship release candidates. > > Understood that distros aren't keen on packaging RCs, and understood > also that installing from upstream when you've been using a package is > a nuisance at best; at worst it can be challenging. But it is there > as an option, and this list has quite a few experienced people which > can help you through it. > > The sudden bursting on the scene of Claude, Mythos et. al. has caught > almost everyone on the hop. I admit that I didn't see it happening so > suddenly and I guess neither did most of the rsync developers. Most > of my time this year has been invested in working on rsync-bpc so that > it embodies the vulnerability fixes and hardening in the rsync code on > which it is based at least as far as is necessary for use by BackupPC. > > That has meant that picking up where I left off with BackupPC 4.4.1rc1 > has had to go on the back burner for longer than I'm happy about, but > there has really been no choice as rsync-bpc is pretty fundamental to > a large number of BackupPC users. Originally I planned to bring out > rsync-bpc 3.4.something, but trying to separate out fixes from feature > creep in rsync updates became impractical, and in the end I decided to > bite the bullet and go direct to rsync-bpc V 3.5.0.0. Fortunately I'm > seeing light at the end of what has been a longer tunnel than expected > and I'm now running, more or less, what I plan to call version 3.5.0.0 > of rsync-bpc on my own network. If all goes well I'll be sending out > a tarball for testing this weekend. Anyone who is interested in doing > some testing with it is very welcome to ask for it. > > Assuming there are no show-stoppers in rsync-bpc I'll get back to work > on the release of 4.4.1, which will be very little different from the > current master on Github. If there's great demand I could simply tag > the existing rc1 as 4.4.1 right now, and the few remaning changes I'd > like to do can go into a 4.4.2 release. To me it's always seemed that > frequent releases aren't necessarily a sign of stable software (and if > you want stability anywhere, I think it's in your backup software) but > if there are any looming distro deadlines please let me know. I make > no attempt to keep a diary of them. The guy at Red Hat has been very > helpful but there's been no response to my mail to Debian maintainers. > > Regarding the ancillaries, we should probably define what they are. > > Things like the zlib and popt libraries could come under that heading > but I'm working on eliminating the versions that used to be bundled > with BackupPC. BackupPC-XS no longer bundles them, rsync still does > but rsync-bpc does not. That means that security issues in bundled > code will no longer be a problem but it does mean that you will need > to install the libraries if you don't have them, and the development > libraries (C header files) too if you're going to build from source. > The distro packagers should handle all of that for you of course. > > Apart from smbclient, the main other ancillaries that I can think of > are things like Apache and of course tar, gzip and Cygwin which are > all more or less out of my hands. My original plan for this year - > which I had to drop because of the AI juggernaut - was to look at how > BackupPC uses smbclient (specifically how it parses smbclient output) > and maybe to get in touch with the people Down Under with a view to > collaborating on producing a machine-readable version of said output > which won't break use by BackupPC every time they add another stat. > Looking at the enormous number of rsync commits this year I'm not sure > that our Aussie friends would have welcomed the approach, but I still > want to sound them out. That's looking more like work for next year, > but if anyone is pitting their wits against SMB transfers please pipe > up here on the list; I want to know about it and I'm up for the job. > > Anything I missed? Well, apart from that Perlephant in the room... > > -- > > 73, > Ged. > > > _______________________________________________ > BackupPC-users mailing list > [email protected] > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users > Wiki: https://github.com/backuppc/backuppc/wiki > Project: https://backuppc.github.io/backuppc/ _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
