From boxbackup at fluffy.co.uk Wed Aug 3 02:57:46 2005 From: boxbackup at fluffy.co.uk (boxbackup at fluffy.co.uk) Date: Tue, 2 Aug 2005 21:57:46 -0400 (EDT) Subject: [Box Backup] Make/install help Message-ID: <3628.68.209.163.187.1123034266.squirrel@www.quickbackups.com> I'm fairly new to linux, and I'm trying to make/install boxbackup. I've downloaded the tarball, and extracted it to /usr/local/src/boxbackup I did ./configure, with no errors. But when I try make, I get the following: - A lot of warnings about using private kernel header instead of /usr/include/asm/byteorder.h - lots of struct IOStream errors in protocol.cpp and .h What am I doing wrong? Thanks, Bill From boxbackup at fluffy.co.uk Wed Aug 3 09:45:58 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Wed, 3 Aug 2005 09:45:58 +0100 Subject: [Box Backup] Make/install help In-Reply-To: <3628.68.209.163.187.1123034266.squirrel@www.quickbackups.com> References: <3628.68.209.163.187.1123034266.squirrel@www.quickbackups.com> Message-ID: <07C3DBB9-878B-44E2-9FBF-A2B1F71DBC52@fluffy.co.uk> On 3 Aug 2005, at 02:57, captaink at quickbackups.com wrote: > I'm fairly new to linux, and I'm trying to make/install boxbackup. > > I've downloaded the tarball, and extracted it to /usr/local/src/ > boxbackup > > I did ./configure, with no errors. > > But when I try make, I get the following: > > - A lot of warnings about using private kernel header > instead > of /usr/include/asm/byteorder.h This is because Linux helpfully doesn't include useful things like endian-independent byte ordering macros in the files you're supposed to include. > - lots of struct IOStream errors in protocol.cpp and .h > > What am I doing wrong? Thanks, You need to post the latter error, otherwise it's impossible to tell what's going on. Ben From boxbackup at fluffy.co.uk Wed Aug 3 09:53:04 2005 From: boxbackup at fluffy.co.uk (Johannes Dagemark) Date: Wed, 03 Aug 2005 10:53:04 +0200 Subject: [Box Backup] Make/install help In-Reply-To: <3628.68.209.163.187.1123034266.squirrel@www.quickbackups.com> References: <3628.68.209.163.187.1123034266.squirrel@www.quickbackups.com> Message-ID: <42F085F0.9040207@op5.se> Hi Bill It looks to mee that you dont have the linux kernel headers installed. To fix this you either download the proper rpm, kernel-headers something depending on which distribution you are running. Or you can download the full kernel sources from www.kernel.org. Cheers Johannes Dagemark captaink at quickbackups.com wrote: > I'm fairly new to linux, and I'm trying to make/install boxbackup. > > I've downloaded the tarball, and extracted it to /usr/local/src/boxbackup > > I did ./configure, with no errors. > > But when I try make, I get the following: > > - A lot of warnings about using private kernel header instead > of /usr/include/asm/byteorder.h > - lots of struct IOStream errors in protocol.cpp and .h > > What am I doing wrong? Thanks, > > Bill > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Thu Aug 4 01:15:37 2005 From: boxbackup at fluffy.co.uk (Scott McNee) Date: Thu, 4 Aug 2005 10:15:37 +1000 Subject: [Box Backup] (no subject) Message-ID: <000e01c59889$a426b9b0$6501a8c0@SCOTTLAPTOP> Hi All, Thanks Ben for your advice. Everything is working great. Restoration works from read-only media. A quick question. Are you aware of any limitations that box-backup has? Ie. Max Simultaneous clients etc? Thanks. Scott McNee ITServices From boxbackup at fluffy.co.uk Thu Aug 4 17:57:40 2005 From: boxbackup at fluffy.co.uk (Bill DAlessandro) Date: Thu, 04 Aug 2005 12:57:40 -0400 Subject: [Box Backup] Re: Make/install help Message-ID: This is a multi-part message in MIME format. ------=NEOMAIL_ATT_0.284442213903279 Content-Type: text/plain; charset=iso-8859-1 Here's the full output of make (attached) What can I do to remedy the errors? Thanks, Bill ------=NEOMAIL_ATT_0.284442213903279 Content-Type: text/plain; name="results.txt" Content-Transfer-Encoding: base64 bWtkaXIgcGFyY2Vscy9ib3hiYWNrdXAtMC4wOS1iYWNrdXAtY2xpZW50LUxpbnV4CihjZCBiaW4v YmJhY2t1cGQ7IG1ha2UgUkVMRUFTRT0xKQptYWtlWzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC91 c3IvbG9jYWwvc3JjL2JveGJhY2t1cC0wLjA5L2Jpbi9iYmFja3VwZCcKZysrIC1ETkRFQlVHIC1P MiAtV2FsbCAtSS4uLy4uL2xpYi9jb21tb24gLUkuLi8uLi9saWIvY29tcHJlc3MgLUkuLi8uLi9s aWIvY3J5cHRvIC1JLi4vLi4vbGliL3NlcnZlciAtSS4uLy4uL2xpYi9iYWNrdXBjbGllbnQgLURQ TEFURk9STV9MSU5VWCAtREJPWF9WRVJTSU9OPSJcIjAuMDlcIiIgLURfRklMRV9PRkZTRVRfQklU Uz02NCAgLWMgQmFja3VwQ2xpZW50RGlyZWN0b3J5UmVjb3JkLmNwcCAtbyAuLi8uLi9yZWxlYXNl L2Jpbi9iYmFja3VwZC9CYWNrdXBDbGllbnREaXJlY3RvcnlSZWNvcmQubwpnKysgLUROREVCVUcg LU8yIC1XYWxsIC1JLi4vLi4vbGliL2NvbW1vbiAtSS4uLy4uL2xpYi9jb21wcmVzcyAtSS4uLy4u L2xpYi9jcnlwdG8gLUkuLi8uLi9saWIvc2VydmVyIC1JLi4vLi4vbGliL2JhY2t1cGNsaWVudCAt RFBMQVRGT1JNX0xJTlVYIC1EQk9YX1ZFUlNJT049IlwiMC4wOVwiIiAtRF9GSUxFX09GRlNFVF9C SVRTPTY0ICAtYyBCYWNrdXBEYWVtb24uY3BwIC1vIC4uLy4uL3JlbGVhc2UvYmluL2JiYWNrdXBk L0JhY2t1cERhZW1vbi5vCmcrKyAtRE5ERUJVRyAtTzIgLVdhbGwgLUkuLi8uLi9saWIvY29tbW9u IC1JLi4vLi4vbGliL2NvbXByZXNzIC1JLi4vLi4vbGliL2NyeXB0byAtSS4uLy4uL2xpYi9zZXJ2 ZXIgLUkuLi8uLi9saWIvYmFja3VwY2xpZW50IC1EUExBVEZPUk1fTElOVVggLURCT1hfVkVSU0lP Tj0iXCIwLjA5XCIiIC1EX0ZJTEVfT0ZGU0VUX0JJVFM9NjQgIC1jIEJhY2t1cENsaWVudENvbnRl eHQuY3BwIC1vIC4uLy4uL3JlbGVhc2UvYmluL2JiYWNrdXBkL0JhY2t1cENsaWVudENvbnRleHQu bwpnKysgLUROREVCVUcgLU8yIC1XYWxsIC1JLi4vLi4vbGliL2NvbW1vbiAtSS4uLy4uL2xpYi9j b21wcmVzcyAtSS4uLy4uL2xpYi9jcnlwdG8gLUkuLi8uLi9saWIvc2VydmVyIC1JLi4vLi4vbGli L2JhY2t1cGNsaWVudCAtRFBMQVRGT1JNX0xJTlVYIC1EQk9YX1ZFUlNJT049IlwiMC4wOVwiIiAt RF9GSUxFX09GRlNFVF9CSVRTPTY0ICAtYyBCYWNrdXBDbGllbnREZWxldGVMaXN0LmNwcCAtbyAu Li8uLi9yZWxlYXNlL2Jpbi9iYmFja3VwZC9CYWNrdXBDbGllbnREZWxldGVMaXN0Lm8KKGNkIC4u Ly4uL2xpYi9jb21tb247IG1ha2UgUkVMRUFTRT0xIE5PREVQUz0xKQptYWtlWzJdOiBFbnRlcmlu ZyBkaXJlY3RvcnkgYC91c3IvbG9jYWwvc3JjL2JveGJhY2t1cC0wLjA5L2xpYi9jb21tb24nCmcr KyAtRE5ERUJVRyAtTzIgLVdhbGwgIC1EUExBVEZPUk1fTElOVVggLURCT1hfVkVSU0lPTj0iXCIw LjA5XCIiIC1EX0ZJTEVfT0ZGU0VUX0JJVFM9NjQgIC1jIEV2ZW50V2F0Y2hGaWxlc3lzdGVtT2Jq ZWN0LmNwcCAtbyAuLi8uLi9yZWxlYXNlL2xpYi9jb21tb24vRXZlbnRXYXRjaEZpbGVzeXN0ZW1P YmplY3QubwpnKysgLUROREVCVUcgLU8yIC1XYWxsICAtRFBMQVRGT1JNX0xJTlVYIC1EQk9YX1ZF UlNJT049IlwiMC4wOVwiIiAtRF9GSUxFX09GRlNFVF9CSVRTPTY0ICAtYyBhdXRvZ2VuX0NvbW1v bkV4Y2VwdGlvbi5jcHAgLW8gLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL2F1dG9nZW5fQ29tbW9u RXhjZXB0aW9uLm8KZysrIC1ETkRFQlVHIC1PMiAtV2FsbCAgLURQTEFURk9STV9MSU5VWCAtREJP WF9WRVJTSU9OPSJcIjAuMDlcIiIgLURfRklMRV9PRkZTRVRfQklUUz02NCAgLWMgYXV0b2dlbl9D b252ZXJzaW9uRXhjZXB0aW9uLmNwcCAtbyAuLi8uLi9yZWxlYXNlL2xpYi9jb21tb24vYXV0b2dl bl9Db252ZXJzaW9uRXhjZXB0aW9uLm8KZysrIC1ETkRFQlVHIC1PMiAtV2FsbCAgLURQTEFURk9S TV9MSU5VWCAtREJPWF9WRVJTSU9OPSJcIjAuMDlcIiIgLURfRklMRV9PRkZTRVRfQklUUz02NCAg LWMgQ29udmVyc2lvblN0cmluZy5jcHAgLW8gLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL0NvbnZl cnNpb25TdHJpbmcubwooZWNobyAtbiA+IC4uLy4uL3JlbGVhc2UvbGliL2NvbW1vbi9jb21tb24u YTsgcm0gLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL2NvbW1vbi5hKQphciAtcSAuLi8uLi9yZWxl YXNlL2xpYi9jb21tb24vY29tbW9uLmEgLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL1JlYWRHYXRo ZXJTdHJlYW0ubyAuLi8uLi9yZWxlYXNlL2xpYi9jb21tb24vRGVidWdQcmludGYubyAuLi8uLi9y ZWxlYXNlL2xpYi9jb21tb24vQ29sbGVjdEluQnVmZmVyU3RyZWFtLm8gLi4vLi4vcmVsZWFzZS9s aWIvY29tbW9uL1V0aWxzLm8gLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL0lPU3RyZWFtLm8gLi4v Li4vcmVsZWFzZS9saWIvY29tbW9uL0V2ZW50V2F0Y2hGaWxlc3lzdGVtT2JqZWN0Lm8gLi4vLi4v cmVsZWFzZS9saWIvY29tbW9uL0xpbnV4V29ya2Fyb3VuZC5vIC4uLy4uL3JlbGVhc2UvbGliL2Nv bW1vbi9GaWxlU3RyZWFtLm8gLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL0RlYnVnQXNzZXJ0RmFp bGVkLm8gLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL2F1dG9nZW5fQ29tbW9uRXhjZXB0aW9uLm8g Li4vLi4vcmVsZWFzZS9saWIvY29tbW9uL0ZkR2V0TGluZS5vIC4uLy4uL3JlbGVhc2UvbGliL2Nv bW1vbi9Cb3hUaW1lVG9UZXh0Lm8gLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL2F1dG9nZW5fQ29u dmVyc2lvbkV4Y2VwdGlvbi5vIC4uLy4uL3JlbGVhc2UvbGliL2NvbW1vbi9OYW1lZExvY2subyAu Li8uLi9yZWxlYXNlL2xpYi9jb21tb24vVW5peFVzZXIubyAuLi8uLi9yZWxlYXNlL2xpYi9jb21t b24vUGFydGlhbFJlYWRTdHJlYW0ubyAuLi8uLi9yZWxlYXNlL2xpYi9jb21tb24vQ29udmVyc2lv blN0cmluZy5vIC4uLy4uL3JlbGVhc2UvbGliL2NvbW1vbi9FeGNsdWRlTGlzdC5vIC4uLy4uL3Jl bGVhc2UvbGliL2NvbW1vbi9EZWJ1Z01lbUxlYWtGaW5kZXIubyAuLi8uLi9yZWxlYXNlL2xpYi9j b21tb24vSU9TdHJlYW1HZXRMaW5lLm8gLi4vLi4vcmVsZWFzZS9saWIvY29tbW9uL0JveFRpbWUu byAuLi8uLi9yZWxlYXNlL2xpYi9jb21tb24vTWVtQmxvY2tTdHJlYW0ubyAuLi8uLi9yZWxlYXNl L2xpYi9jb21tb24vQ29uZmlndXJhdGlvbi5vIC4uLy4uL3JlbGVhc2UvbGliL2NvbW1vbi9TdHJl YW1hYmxlTWVtQmxvY2subyAuLi8uLi9yZWxlYXNlL2xpYi9jb21tb24vQm94RXhjZXB0aW9uLm8g Li4vLi4vcmVsZWFzZS9saWIvY29tbW9uL1dhaXRGb3JFdmVudC5vCnJhbmxpYiAuLi8uLi9yZWxl YXNlL2xpYi9jb21tb24vY29tbW9uLmEKbWFrZVsyXTogTGVhdmluZyBkaXJlY3RvcnkgYC91c3Iv bG9jYWwvc3JjL2JveGJhY2t1cC0wLjA5L2xpYi9jb21tb24nCihjZCAuLi8uLi9saWIvY29tcHJl c3M7IG1ha2UgUkVMRUFTRT0xIE5PREVQUz0xKQptYWtlWzJdOiBFbnRlcmluZyBkaXJlY3Rvcnkg YC91c3IvbG9jYWwvc3JjL2JveGJhY2t1cC0wLjA5L2xpYi9jb21wcmVzcycKZysrIC1ETkRFQlVH IC1PMiAtV2FsbCAtSS4uLy4uL2xpYi9jb21tb24gLURQTEFURk9STV9MSU5VWCAtREJPWF9WRVJT SU9OPSJcIjAuMDlcIiIgLURfRklMRV9PRkZTRVRfQklUUz02NCAgLWMgYXV0b2dlbl9Db21wcmVz c0V4Y2VwdGlvbi5jcHAgLW8gLi4vLi4vcmVsZWFzZS9saWIvY29tcHJlc3MvYXV0b2dlbl9Db21w cmVzc0V4Y2VwdGlvbi5vCmcrKyAtRE5ERUJVRyAtTzIgLVdhbGwgLUkuLi8uLi9saWIvY29tbW9u IC1EUExBVEZPUk1fTElOVVggLURCT1hfVkVSU0lPTj0iXCIwLjA5XCIiIC1EX0ZJTEVfT0ZGU0VU X0JJVFM9NjQgIC1jIENvbXByZXNzU3RyZWFtLmNwcCAtbyAuLi8uLi9yZWxlYXNlL2xpYi9jb21w cmVzcy9Db21wcmVzc1N0cmVhbS5vCihlY2hvIC1uID4gLi4vLi4vcmVsZWFzZS9saWIvY29tcHJl c3MvY29tcHJlc3MuYTsgcm0gLi4vLi4vcmVsZWFzZS9saWIvY29tcHJlc3MvY29tcHJlc3MuYSkK YXIgLXEgLi4vLi4vcmVsZWFzZS9saWIvY29tcHJlc3MvY29tcHJlc3MuYSAuLi8uLi9yZWxlYXNl L2xpYi9jb21wcmVzcy9hdXRvZ2VuX0NvbXByZXNzRXhjZXB0aW9uLm8gLi4vLi4vcmVsZWFzZS9s aWIvY29tcHJlc3MvQ29tcHJlc3NTdHJlYW0ubwpyYW5saWIgLi4vLi4vcmVsZWFzZS9saWIvY29t cHJlc3MvY29tcHJlc3MuYQptYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9sb2NhbC9z cmMvYm94YmFja3VwLTAuMDkvbGliL2NvbXByZXNzJwooY2QgLi4vLi4vbGliL2NyeXB0bzsgbWFr ZSBSRUxFQVNFPTEgTk9ERVBTPTEpCm1ha2VbMl06IEVudGVyaW5nIGRpcmVjdG9yeSBgL3Vzci9s b2NhbC9zcmMvYm94YmFja3VwLTAuMDkvbGliL2NyeXB0bycKZysrIC1ETkRFQlVHIC1PMiAtV2Fs bCAtSS4uLy4uL2xpYi9jb21tb24gLURQTEFURk9STV9MSU5VWCAtREJPWF9WRVJTSU9OPSJcIjAu MDlcIiIgLURfRklMRV9PRkZTRVRfQklUUz02NCAgLWMgYXV0b2dlbl9DaXBoZXJFeGNlcHRpb24u Y3BwIC1vIC4uLy4uL3JlbGVhc2UvbGliL2NyeXB0by9hdXRvZ2VuX0NpcGhlckV4Y2VwdGlvbi5v CihlY2hvIC1uID4gLi4vLi4vcmVsZWFzZS9saWIvY3J5cHRvL2NyeXB0by5hOyBybSAuLi8uLi9y ZWxlYXNlL2xpYi9jcnlwdG8vY3J5cHRvLmEpCmFyIC1xIC4uLy4uL3JlbGVhc2UvbGliL2NyeXB0 by9jcnlwdG8uYSAuLi8uLi9yZWxlYXNlL2xpYi9jcnlwdG8vQ2lwaGVyQ29udGV4dC5vIC4uLy4u L3JlbGVhc2UvbGliL2NyeXB0by9Sb2xsaW5nQ2hlY2tzdW0ubyAuLi8uLi9yZWxlYXNlL2xpYi9j cnlwdG8vYXV0b2dlbl9DaXBoZXJFeGNlcHRpb24ubyAuLi8uLi9yZWxlYXNlL2xpYi9jcnlwdG8v Q2lwaGVyQUVTLm8gLi4vLi4vcmVsZWFzZS9saWIvY3J5cHRvL0NpcGhlckJsb3dmaXNoLm8gLi4v Li4vcmVsZWFzZS9saWIvY3J5cHRvL1JhbmRvbS5vIC4uLy4uL3JlbGVhc2UvbGliL2NyeXB0by9D aXBoZXJEZXNjcmlwdGlvbi5vIC4uLy4uL3JlbGVhc2UvbGliL2NyeXB0by9NRDVEaWdlc3Qubwpy YW5saWIgLi4vLi4vcmVsZWFzZS9saWIvY3J5cHRvL2NyeXB0by5hCm1ha2VbMl06IExlYXZpbmcg ZGlyZWN0b3J5IGAvdXNyL2xvY2FsL3NyYy9ib3hiYWNrdXAtMC4wOS9saWIvY3J5cHRvJwooY2Qg Li4vLi4vbGliL3NlcnZlcjsgbWFrZSBSRUxFQVNFPTEgTk9ERVBTPTEpCm1ha2VbMl06IEVudGVy aW5nIGRpcmVjdG9yeSBgL3Vzci9sb2NhbC9zcmMvYm94YmFja3VwLTAuMDkvbGliL3NlcnZlcicK ZysrIC1ETkRFQlVHIC1PMiAtV2FsbCAtSS4uLy4uL2xpYi9jb21tb24gLURQTEFURk9STV9MSU5V WCAtREJPWF9WRVJTSU9OPSJcIjAuMDlcIiIgLURfRklMRV9PRkZTRVRfQklUUz02NCAgLWMgTG9j YWxQcm9jZXNzU3RyZWFtLmNwcCAtbyAuLi8uLi9yZWxlYXNlL2xpYi9zZXJ2ZXIvTG9jYWxQcm9j ZXNzU3RyZWFtLm8KZysrIC1ETkRFQlVHIC1PMiAtV2FsbCAtSS4uLy4uL2xpYi9jb21tb24gLURQ TEFURk9STV9MSU5VWCAtREJPWF9WRVJTSU9OPSJcIjAuMDlcIiIgLURfRklMRV9PRkZTRVRfQklU Uz02NCAgLWMgYXV0b2dlbl9TZXJ2ZXJFeGNlcHRpb24uY3BwIC1vIC4uLy4uL3JlbGVhc2UvbGli L3NlcnZlci9hdXRvZ2VuX1NlcnZlckV4Y2VwdGlvbi5vCmcrKyAtRE5ERUJVRyAtTzIgLVdhbGwg LUkuLi8uLi9saWIvY29tbW9uIC1EUExBVEZPUk1fTElOVVggLURCT1hfVkVSU0lPTj0iXCIwLjA5 XCIiIC1EX0ZJTEVfT0ZGU0VUX0JJVFM9NjQgIC1jIFByb3RvY29sLmNwcCAtbyAuLi8uLi9yZWxl YXNlL2xpYi9zZXJ2ZXIvUHJvdG9jb2wubwptYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vz ci9sb2NhbC9zcmMvYm94YmFja3VwLTAuMDkvbGliL3NlcnZlcicKbWFrZVsxXTogTGVhdmluZyBk aXJlY3RvcnkgYC91c3IvbG9jYWwvc3JjL2JveGJhY2t1cC0wLjA5L2Jpbi9iYmFja3VwZCcK ------=NEOMAIL_ATT_0.284442213903279-- From boxbackup at fluffy.co.uk Thu Aug 4 18:08:08 2005 From: boxbackup at fluffy.co.uk (Bill DAlessandro) Date: Thu, 04 Aug 2005 13:08:08 -0400 Subject: [Box Backup] Re: Make/install help Message-ID: This is a multi-part message in MIME format. ------=NEOMAIL_ATT_0.805656081604869 Content-Type: text/plain; charset=iso-8859-1 Oops, I wanted to attach the error output ------=NEOMAIL_ATT_0.805656081604869 Content-Type: application/octet-stream; name="results" Content-Transfer-Encoding: base64 SW4gZmlsZSBpbmNsdWRlZCBmcm9tIC4uLy4uL2xpYi9jb21tb24vQm94Lmg6MTgzLAogICAgICAg ICAgICAgICAgIGZyb20gQmFja3VwQ2xpZW50RGlyZWN0b3J5UmVjb3JkLmNwcDo0OToKL3Vzci9p bmNsdWRlL2FzbS9ieXRlb3JkZXIuaDo2OjI6IHdhcm5pbmc6ICN3YXJuaW5nIHVzaW5nIHByaXZh dGUga2VybmVsIGhlYWRlcjsgaW5jbHVkZSA8ZW5kaWFuLmg+IGluc3RlYWQhCkluIGZpbGUgaW5j bHVkZWQgZnJvbSAuLi8uLi9saWIvY29tbW9uL0JveC5oOjE4MywKICAgICAgICAgICAgICAgICBm cm9tIEJhY2t1cERhZW1vbi5jcHA6NDk6Ci91c3IvaW5jbHVkZS9hc20vYnl0ZW9yZGVyLmg6Njoy OiB3YXJuaW5nOiAjd2FybmluZyB1c2luZyBwcml2YXRlIGtlcm5lbCBoZWFkZXI7IGluY2x1ZGUg PGVuZGlhbi5oPiBpbnN0ZWFkIQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gLi4vLi4vbGliL2NvbW1v bi9Cb3guaDoxODMsCiAgICAgICAgICAgICAgICAgZnJvbSBCYWNrdXBDbGllbnRDb250ZXh0LmNw cDo0OToKL3Vzci9pbmNsdWRlL2FzbS9ieXRlb3JkZXIuaDo2OjI6IHdhcm5pbmc6ICN3YXJuaW5n IHVzaW5nIHByaXZhdGUga2VybmVsIGhlYWRlcjsgaW5jbHVkZSA8ZW5kaWFuLmg+IGluc3RlYWQh CkluIGZpbGUgaW5jbHVkZWQgZnJvbSAuLi8uLi9saWIvY29tbW9uL0JveC5oOjE4MywKICAgICAg ICAgICAgICAgICBmcm9tIEJhY2t1cENsaWVudERlbGV0ZUxpc3QuY3BwOjQ5OgovdXNyL2luY2x1 ZGUvYXNtL2J5dGVvcmRlci5oOjY6Mjogd2FybmluZzogI3dhcm5pbmcgdXNpbmcgcHJpdmF0ZSBr ZXJuZWwgaGVhZGVyOyBpbmNsdWRlIDxlbmRpYW4uaD4gaW5zdGVhZCEKSW4gZmlsZSBpbmNsdWRl ZCBmcm9tIEJveC5oOjE4MywKICAgICAgICAgICAgICAgICBmcm9tIEV2ZW50V2F0Y2hGaWxlc3lz dGVtT2JqZWN0LmNwcDo0OToKL3Vzci9pbmNsdWRlL2FzbS9ieXRlb3JkZXIuaDo2OjI6IHdhcm5p bmc6ICN3YXJuaW5nIHVzaW5nIHByaXZhdGUga2VybmVsIGhlYWRlcjsgaW5jbHVkZSA8ZW5kaWFu Lmg+IGluc3RlYWQhCkluIGZpbGUgaW5jbHVkZWQgZnJvbSBCb3guaDoxODMsCiAgICAgICAgICAg ICAgICAgZnJvbSBhdXRvZ2VuX0NvbW1vbkV4Y2VwdGlvbi5jcHA6NDoKL3Vzci9pbmNsdWRlL2Fz bS9ieXRlb3JkZXIuaDo2OjI6IHdhcm5pbmc6ICN3YXJuaW5nIHVzaW5nIHByaXZhdGUga2VybmVs IGhlYWRlcjsgaW5jbHVkZSA8ZW5kaWFuLmg+IGluc3RlYWQhCkluIGZpbGUgaW5jbHVkZWQgZnJv bSBCb3guaDoxODMsCiAgICAgICAgICAgICAgICAgZnJvbSBhdXRvZ2VuX0NvbnZlcnNpb25FeGNl cHRpb24uY3BwOjQ6Ci91c3IvaW5jbHVkZS9hc20vYnl0ZW9yZGVyLmg6NjoyOiB3YXJuaW5nOiAj d2FybmluZyB1c2luZyBwcml2YXRlIGtlcm5lbCBoZWFkZXI7IGluY2x1ZGUgPGVuZGlhbi5oPiBp bnN0ZWFkIQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gQm94Lmg6MTgzLAogICAgICAgICAgICAgICAg IGZyb20gQ29udmVyc2lvblN0cmluZy5jcHA6NDk6Ci91c3IvaW5jbHVkZS9hc20vYnl0ZW9yZGVy Lmg6NjoyOiB3YXJuaW5nOiAjd2FybmluZyB1c2luZyBwcml2YXRlIGtlcm5lbCBoZWFkZXI7IGlu Y2x1ZGUgPGVuZGlhbi5oPiBpbnN0ZWFkIQphcjogY3JlYXRpbmcgLi4vLi4vcmVsZWFzZS9saWIv Y29tbW9uL2NvbW1vbi5hCkluIGZpbGUgaW5jbHVkZWQgZnJvbSAuLi8uLi9saWIvY29tbW9uL0Jv eC5oOjE4MywKICAgICAgICAgICAgICAgICBmcm9tIGF1dG9nZW5fQ29tcHJlc3NFeGNlcHRpb24u Y3BwOjQ6Ci91c3IvaW5jbHVkZS9hc20vYnl0ZW9yZGVyLmg6NjoyOiB3YXJuaW5nOiAjd2Fybmlu ZyB1c2luZyBwcml2YXRlIGtlcm5lbCBoZWFkZXI7IGluY2x1ZGUgPGVuZGlhbi5oPiBpbnN0ZWFk IQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gLi4vLi4vbGliL2NvbW1vbi9Cb3guaDoxODMsCiAgICAg ICAgICAgICAgICAgZnJvbSBDb21wcmVzc1N0cmVhbS5jcHA6NDk6Ci91c3IvaW5jbHVkZS9hc20v Ynl0ZW9yZGVyLmg6NjoyOiB3YXJuaW5nOiAjd2FybmluZyB1c2luZyBwcml2YXRlIGtlcm5lbCBo ZWFkZXI7IGluY2x1ZGUgPGVuZGlhbi5oPiBpbnN0ZWFkIQphcjogY3JlYXRpbmcgLi4vLi4vcmVs ZWFzZS9saWIvY29tcHJlc3MvY29tcHJlc3MuYQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gLi4vLi4v bGliL2NvbW1vbi9Cb3guaDoxODMsCiAgICAgICAgICAgICAgICAgZnJvbSBhdXRvZ2VuX0NpcGhl ckV4Y2VwdGlvbi5jcHA6NDoKL3Vzci9pbmNsdWRlL2FzbS9ieXRlb3JkZXIuaDo2OjI6IHdhcm5p bmc6ICN3YXJuaW5nIHVzaW5nIHByaXZhdGUga2VybmVsIGhlYWRlcjsgaW5jbHVkZSA8ZW5kaWFu Lmg+IGluc3RlYWQhCmFyOiBjcmVhdGluZyAuLi8uLi9yZWxlYXNlL2xpYi9jcnlwdG8vY3J5cHRv LmEKSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC4uLy4uL2xpYi9jb21tb24vQm94Lmg6MTgzLAogICAg ICAgICAgICAgICAgIGZyb20gTG9jYWxQcm9jZXNzU3RyZWFtLmNwcDo0OToKL3Vzci9pbmNsdWRl L2FzbS9ieXRlb3JkZXIuaDo2OjI6IHdhcm5pbmc6ICN3YXJuaW5nIHVzaW5nIHByaXZhdGUga2Vy bmVsIGhlYWRlcjsgaW5jbHVkZSA8ZW5kaWFuLmg+IGluc3RlYWQhCkluIGZpbGUgaW5jbHVkZWQg ZnJvbSAuLi8uLi9saWIvY29tbW9uL0JveC5oOjE4MywKICAgICAgICAgICAgICAgICBmcm9tIGF1 dG9nZW5fU2VydmVyRXhjZXB0aW9uLmNwcDo0OgovdXNyL2luY2x1ZGUvYXNtL2J5dGVvcmRlci5o OjY6Mjogd2FybmluZzogI3dhcm5pbmcgdXNpbmcgcHJpdmF0ZSBrZXJuZWwgaGVhZGVyOyBpbmNs dWRlIDxlbmRpYW4uaD4gaW5zdGVhZCEKSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC4uLy4uL2xpYi9j b21tb24vQm94Lmg6MTgzLAogICAgICAgICAgICAgICAgIGZyb20gUHJvdG9jb2wuY3BwOjQ5Ogov dXNyL2luY2x1ZGUvYXNtL2J5dGVvcmRlci5oOjY6Mjogd2FybmluZzogI3dhcm5pbmcgdXNpbmcg cHJpdmF0ZSBrZXJuZWwgaGVhZGVyOyBpbmNsdWRlIDxlbmRpYW4uaD4gaW5zdGVhZCEKSW4gZmls ZSBpbmNsdWRlZCBmcm9tIFByb3RvY29sLmNwcDo1OToKUHJvdG9jb2xXaXJlLmg6NTg6IGVycm9y OiBzdHJheSDigJgj4oCZIGluIHByb2dyYW0KUHJvdG9jb2xXaXJlLmg6Nzg6IGVycm9yOiBzdHJh eSDigJgj4oCZIGluIHByb2dyYW0KUHJvdG9jb2xXaXJlLmg6NTg6IGVycm9yOiDigJhwcmFnbWHi gJkgZG9lcyBub3QgbmFtZSBhIHR5cGUKUHJvdG9jb2xXaXJlLmg6NjQ6IGVycm9yOiBleHBlY3Rl ZCBjb25zdHJ1Y3RvciwgZGVzdHJ1Y3Rvciwgb3IgdHlwZSBjb252ZXJzaW9uIGJlZm9yZSDigJg7 4oCZIHRva2VuClByb3RvY29sV2lyZS5oOjc4OiBlcnJvcjog4oCYcHJhZ21h4oCZIGRvZXMgbm90 IG5hbWUgYSB0eXBlCi4uLy4uL2xpYi9jb21tb24vUGFydGlhbFJlYWRTdHJlYW0uaDo2MjogZXJy b3I6IGludmFsaWQgdXNlIG9mIHVuZGVmaW5lZCB0eXBlIOKAmHN0cnVjdCBJT1N0cmVhbeKAmQpQ cm90b2NvbC5oOjU0OiBlcnJvcjogZm9yd2FyZCBkZWNsYXJhdGlvbiBvZiDigJhzdHJ1Y3QgSU9T dHJlYW3igJkKLi4vLi4vbGliL2NvbW1vbi9QYXJ0aWFsUmVhZFN0cmVhbS5oOjc0OiBlcnJvcjog 4oCYcG9zX3R5cGXigJkgZG9lcyBub3QgbmFtZSBhIHR5cGUKLi4vLi4vbGliL2NvbW1vbi9QYXJ0 aWFsUmVhZFN0cmVhbS5oOjYzOiB3YXJuaW5nOiDigJhjbGFzcyBQYXJ0aWFsUmVhZFN0cmVhbeKA mSBoYXMgdmlydHVhbCBmdW5jdGlvbnMgYnV0IG5vbi12aXJ0dWFsIGRlc3RydWN0b3IKLi4vLi4v bGliL2NvbW1vbi9QYXJ0aWFsUmVhZFN0cmVhbS5oOjczOiBlcnJvcjogaW5jb21wbGV0ZSB0eXBl IOKAmElPU3RyZWFt4oCZIHVzZWQgaW4gbmVzdGVkIG5hbWUgc3BlY2lmaWVyClByb3RvY29sVW5j ZXJ0YWluU3RyZWFtLmg6NjI6IGVycm9yOiBpbnZhbGlkIHVzZSBvZiB1bmRlZmluZWQgdHlwZSDi gJhzdHJ1Y3QgSU9TdHJlYW3igJkKUHJvdG9jb2wuaDo1NDogZXJyb3I6IGZvcndhcmQgZGVjbGFy YXRpb24gb2Yg4oCYc3RydWN0IElPU3RyZWFt4oCZClByb3RvY29sVW5jZXJ0YWluU3RyZWFtLmg6 NzQ6IGVycm9yOiDigJhwb3NfdHlwZeKAmSBkb2VzIG5vdCBuYW1lIGEgdHlwZQpQcm90b2NvbFVu Y2VydGFpblN0cmVhbS5oOjYzOiB3YXJuaW5nOiDigJhjbGFzcyBQcm90b2NvbFVuY2VydGFpblN0 cmVhbeKAmSBoYXMgdmlydHVhbCBmdW5jdGlvbnMgYnV0IG5vbi12aXJ0dWFsIGRlc3RydWN0b3IK UHJvdG9jb2xVbmNlcnRhaW5TdHJlYW0uaDo3MzogZXJyb3I6IGluY29tcGxldGUgdHlwZSDigJhJ T1N0cmVhbeKAmSB1c2VkIGluIG5lc3RlZCBuYW1lIHNwZWNpZmllcgpQcm90b2NvbC5jcHA6IElu IG1lbWJlciBmdW5jdGlvbiDigJh2b2lkIFByb3RvY29sOjpIYW5kc2hha2UoKeKAmToKUHJvdG9j b2wuY3BwOjE2NDogZXJyb3I6IOKAmFBXX0hhbmRzaGFrZeKAmSB3YXMgbm90IGRlY2xhcmVkIGlu IHRoaXMgc2NvcGUKUHJvdG9jb2wuY3BwOjE2NDogZXJyb3I6IGV4cGVjdGVkIGA7JyBiZWZvcmUg 4oCYaHNTZW5k4oCZClByb3RvY29sLmNwcDoxNjU6IGVycm9yOiDigJhoc1NlbmTigJkgd2FzIG5v dCBkZWNsYXJlZCBpbiB0aGlzIHNjb3BlClByb3RvY29sLmNwcDoxNzA6IGVycm9yOiBpbnZhbGlk IHVzZSBvZiB1bmRlZmluZWQgdHlwZSDigJhzdHJ1Y3QgSU9TdHJlYW3igJkKUHJvdG9jb2wuaDo1 NDogZXJyb3I6IGZvcndhcmQgZGVjbGFyYXRpb24gb2Yg4oCYc3RydWN0IElPU3RyZWFt4oCZClBy b3RvY29sLmNwcDoxNzE6IGVycm9yOiBpbnZhbGlkIHVzZSBvZiB1bmRlZmluZWQgdHlwZSDigJhz dHJ1Y3QgSU9TdHJlYW3igJkKUHJvdG9jb2wuaDo1NDogZXJyb3I6IGZvcndhcmQgZGVjbGFyYXRp b24gb2Yg4oCYc3RydWN0IElPU3RyZWFt4oCZClByb3RvY29sLmNwcDoxNzQ6IGVycm9yOiBleHBl Y3RlZCBgOycgYmVmb3JlIOKAmGhzUmVjZWl2ZeKAmQpQcm90b2NvbC5jcHA6MTc1OiBlcnJvcjog 4oCYaHNSZWNlaXZl4oCZIHdhcyBub3QgZGVjbGFyZWQgaW4gdGhpcyBzY29wZQpQcm90b2NvbC5j cHA6MTgxOiBlcnJvcjogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3RydWN0IElP U3RyZWFt4oCZClByb3RvY29sLmg6NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9mIOKA mHN0cnVjdCBJT1N0cmVhbeKAmQpQcm90b2NvbC5jcHA6IEluIG1lbWJlciBmdW5jdGlvbiDigJh2 b2lkIFByb3RvY29sOjpDaGVja0FuZFJlYWRIZHIodm9pZCop4oCZOgpQcm90b2NvbC5jcHA6MjI1 OiBlcnJvcjogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3RydWN0IElPU3RyZWFt 4oCZClByb3RvY29sLmg6NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9mIOKAmHN0cnVj dCBJT1N0cmVhbeKAmQpQcm90b2NvbC5jcHA6IEluIG1lbWJlciBmdW5jdGlvbiDigJhzdGQ6OmF1 dG9fcHRyPFByb3RvY29sT2JqZWN0PiBQcm90b2NvbDo6UmVjZWl2ZSgp4oCZOgpQcm90b2NvbC5j cHA6MjY2OiBlcnJvcjogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3RydWN0IElP U3RyZWFt4oCZClByb3RvY29sLmg6NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9mIOKA mHN0cnVjdCBJT1N0cmVhbeKAmQpQcm90b2NvbC5jcHA6IEluIG1lbWJlciBmdW5jdGlvbiDigJh2 b2lkIFByb3RvY29sOjpTZW5kKGNvbnN0IFByb3RvY29sT2JqZWN0JinigJk6ClByb3RvY29sLmNw cDozNTk6IGVycm9yOiBpbnZhbGlkIHVzZSBvZiB1bmRlZmluZWQgdHlwZSDigJhzdHJ1Y3QgSU9T dHJlYW3igJkKUHJvdG9jb2wuaDo1NDogZXJyb3I6IGZvcndhcmQgZGVjbGFyYXRpb24gb2Yg4oCY c3RydWN0IElPU3RyZWFt4oCZClByb3RvY29sLmNwcDozNjA6IGVycm9yOiBpbnZhbGlkIHVzZSBv ZiB1bmRlZmluZWQgdHlwZSDigJhzdHJ1Y3QgSU9TdHJlYW3igJkKUHJvdG9jb2wuaDo1NDogZXJy b3I6IGZvcndhcmQgZGVjbGFyYXRpb24gb2Yg4oCYc3RydWN0IElPU3RyZWFt4oCZClByb3RvY29s LmNwcDogSW4gbWVtYmVyIGZ1bmN0aW9uIOKAmHZvaWQgUHJvdG9jb2w6OlNlbmRTdHJlYW0oSU9T dHJlYW0mKeKAmToKUHJvdG9jb2wuY3BwOjcxNjogZXJyb3I6IGluY29tcGxldGUgdHlwZSDigJhJ T1N0cmVhbeKAmSB1c2VkIGluIG5lc3RlZCBuYW1lIHNwZWNpZmllcgpQcm90b2NvbC5jcHA6NzE2 OiBlcnJvcjogZXhwZWN0ZWQgYDsnIGJlZm9yZSDigJhzdHJlYW1TaXpl4oCZClByb3RvY29sLmNw cDo3MTc6IGVycm9yOiDigJhzdHJlYW1TaXpl4oCZIHdhcyBub3QgZGVjbGFyZWQgaW4gdGhpcyBz Y29wZQpQcm90b2NvbC5jcHA6NzE3OiBlcnJvcjogaW5jb21wbGV0ZSB0eXBlIOKAmElPU3RyZWFt 4oCZIHVzZWQgaW4gbmVzdGVkIG5hbWUgc3BlY2lmaWVyClByb3RvY29sLmNwcDo3MjU6IGVycm9y OiDigJhzdHJlYW1TaXpl4oCZIHdhcyBub3QgZGVjbGFyZWQgaW4gdGhpcyBzY29wZQpQcm90b2Nv bC5jcHA6NzMzOiBlcnJvcjogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3RydWN0 IElPU3RyZWFt4oCZClByb3RvY29sLmg6NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9m IOKAmHN0cnVjdCBJT1N0cmVhbeKAmQpQcm90b2NvbC5jcHA6NzUwOiBlcnJvcjogaW52YWxpZCB1 c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3RydWN0IElPU3RyZWFt4oCZClByb3RvY29sLmg6NTQ6 IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9mIOKAmHN0cnVjdCBJT1N0cmVhbeKAmQpQcm90 b2NvbC5jcHA6NzUzOiBlcnJvcjogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3Ry dWN0IElPU3RyZWFt4oCZClByb3RvY29sLmg6NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9u IG9mIOKAmHN0cnVjdCBJT1N0cmVhbeKAmQpQcm90b2NvbC5jcHA6NzY3OiBlcnJvcjogaW52YWxp ZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3RydWN0IElPU3RyZWFt4oCZClByb3RvY29sLmg6 NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9mIOKAmHN0cnVjdCBJT1N0cmVhbeKAmQpQ cm90b2NvbC5jcHA6NzgxOiBlcnJvcjogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCY c3RydWN0IElPU3RyZWFt4oCZClByb3RvY29sLmg6NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0 aW9uIG9mIOKAmHN0cnVjdCBJT1N0cmVhbeKAmQpQcm90b2NvbC5jcHA6Nzg3OiBlcnJvcjogaW52 YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3RydWN0IElPU3RyZWFt4oCZClByb3RvY29s Lmg6NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9mIOKAmHN0cnVjdCBJT1N0cmVhbeKA mQpQcm90b2NvbC5jcHA6IEluIG1lbWJlciBmdW5jdGlvbiDigJhpbnQgUHJvdG9jb2w6OlNlbmRT dHJlYW1TZW5kQmxvY2sodV9pbnQ4X3QqLCBpbnQp4oCZOgpQcm90b2NvbC5jcHA6ODM1OiBlcnJv cjogaW52YWxpZCB1c2Ugb2YgdW5kZWZpbmVkIHR5cGUg4oCYc3RydWN0IElPU3RyZWFt4oCZClBy b3RvY29sLmg6NTQ6IGVycm9yOiBmb3J3YXJkIGRlY2xhcmF0aW9uIG9mIOKAmHN0cnVjdCBJT1N0 cmVhbeKAmQovdXNyL2xpYi9nY2MvaTM4Ni1yZWRoYXQtbGludXgvNC4wLjEvLi4vLi4vLi4vLi4v aW5jbHVkZS9jKysvNC4wLjEvbWVtb3J5OiBJbiBkZXN0cnVjdG9yIOKAmHN0ZDo6YXV0b19wdHI8 X1RwPjo6fmF1dG9fcHRyKCkgW3dpdGggX1RwID0gSU9TdHJlYW1d4oCZOgpQcm90b2NvbC5jcHA6 Njg5OiAgIGluc3RhbnRpYXRlZCBmcm9tIGhlcmUKL3Vzci9saWIvZ2NjL2kzODYtcmVkaGF0LWxp bnV4LzQuMC4xLy4uLy4uLy4uLy4uL2luY2x1ZGUvYysrLzQuMC4xL21lbW9yeToyNTk6IHdhcm5p bmc6IHBvc3NpYmxlIHByb2JsZW0gZGV0ZWN0ZWQgaW4gaW52b2NhdGlvbiBvZiBkZWxldGUgb3Bl cmF0b3I6Ci91c3IvbGliL2djYy9pMzg2LXJlZGhhdC1saW51eC80LjAuMS8uLi8uLi8uLi8uLi9p bmNsdWRlL2MrKy80LjAuMS9tZW1vcnk6MjU5OiB3YXJuaW5nOiBpbnZhbGlkIHVzZSBvZiB1bmRl ZmluZWQgdHlwZSDigJhzdHJ1Y3QgSU9TdHJlYW3igJkKUHJvdG9jb2wuaDo1NDogd2FybmluZzog Zm9yd2FyZCBkZWNsYXJhdGlvbiBvZiDigJhzdHJ1Y3QgSU9TdHJlYW3igJkKL3Vzci9saWIvZ2Nj L2kzODYtcmVkaGF0LWxpbnV4LzQuMC4xLy4uLy4uLy4uLy4uL2luY2x1ZGUvYysrLzQuMC4xL21l bW9yeToyNTk6IG5vdGU6IG5laXRoZXIgdGhlIGRlc3RydWN0b3Igbm9yIHRoZSBjbGFzcy1zcGVj aWZpYyBvcGVyYXRvciBkZWxldGUgd2lsbCBiZSBjYWxsZWQsIGV2ZW4gaWYgdGhleSBhcmUgZGVj bGFyZWQgd2hlbiB0aGUgY2xhc3MgaXMgZGVmaW5lZC4KbWFrZVsyXTogKioqIFsuLi8uLi9yZWxl YXNlL2xpYi9zZXJ2ZXIvUHJvdG9jb2wub10gRXJyb3IgMQptYWtlWzFdOiAqKiogW2RlcF9tb2R1 bGVzXSBFcnJvciAyCm1ha2U6ICoqKiBbcGFyY2Vscy9ib3hiYWNrdXAtMC4wOS1iYWNrdXAtY2xp ZW50LUxpbnV4LnRnel0gRXJyb3IgMgo= ------=NEOMAIL_ATT_0.805656081604869-- From boxbackup at fluffy.co.uk Thu Aug 4 22:18:40 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 4 Aug 2005 22:18:40 +0100 Subject: [Box Backup] limitations (was: (no subject)) In-Reply-To: <000e01c59889$a426b9b0$6501a8c0@SCOTTLAPTOP> References: <000e01c59889$a426b9b0$6501a8c0@SCOTTLAPTOP> Message-ID: On 4 Aug 2005, at 01:15, Scott McNee wrote: > Hi All, > Thanks Ben for your advice. Everything is working great. > Restoration > works from read-only media. Good. > > A quick question. Are you aware of any limitations that box-backup > has? Ie. > Max Simultaneous clients etc? No. It's down to what your OS and hardware can cope with. However, I would have thought that disc space would be more of an issue that handling connections. Given a 500Gb drive and 10G accounts, that's still a maximum of 50 simultaneous connections. And the backup client (in lazy mode) adds a random factor to the sync interval to try and even out the load on the server. Ben From boxbackup at fluffy.co.uk Thu Aug 4 22:24:18 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 4 Aug 2005 22:24:18 +0100 Subject: [Box Backup] Re: Make/install help In-Reply-To: References: Message-ID: <6D67BD77-B287-4DE8-BD8D-CBA2BC9718C1@fluffy.co.uk> On 4 Aug 2005, at 17:57, Bill DAlessandro wrote: > Here's the full output of make (attached) > > What can I do to remedy the errors? Are you using gcc v4? (type gcc --version to see the version number). If so, you'll need a small change to infrastructure/BoxPlatform.pm: $gcc_v3 = 1 if (m/version gcc [34]/ || m/gcc version [34]/ || m/gcc \(GCC\) [34]/i || m/gcc.Version\s+[34]/i); That compiler was released after Box Backup 0.09. Ben From boxbackup at fluffy.co.uk Fri Aug 5 12:35:03 2005 From: boxbackup at fluffy.co.uk (Remco Poelstra) Date: Fri, 05 Aug 2005 13:35:03 +0200 Subject: [Box Backup] Re: Make/install help In-Reply-To: <6D67BD77-B287-4DE8-BD8D-CBA2BC9718C1@fluffy.co.uk> References: <6D67BD77-B287-4DE8-BD8D-CBA2BC9718C1@fluffy.co.uk> Message-ID: <42F34EE7.6090408@beryllium.net> This is a multi-part message in MIME format. --------------070607000402070501020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ben Summers wrote: > Are you using gcc v4? (type gcc --version to see the version number). > If so, you'll need a small change to infrastructure/BoxPlatform.pm: > > $gcc_v3 = 1 if (m/version gcc [34]/ || m/gcc version [34]/ || > m/gcc \(GCC\) [34]/i || m/gcc.Version\s+[34]/i); Hi, I've the same problem, so I was watching this thread for a solution. I'm using GCC 4 (FC 4), but fixing the above doesn't help. I get the attached errors. Furthermore, I would like to make an rpm, how can I make a tarball with the fix, so I can do rpmbuild -ta ? Thanks in advance, Remco Poelstra --------------070607000402070501020807 Content-Type: text/plain; name="boxbackup-errors" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="boxbackup-errors" [remco at isis boxbackup-0.09]$ make mkdir parcels/boxbackup-0.09-backup-client-Linux mkdir: cannot create directory `parcels/boxbackup-0.09-backup-client-Linux': Fil e exists make: *** [parcels/boxbackup-0.09-backup-client-Linux.tgz] Error 1 [remco at isis boxbackup-0.09]$ make clean rm -rf parcels/boxbackup-0.09-backup-client-Linux rm -f parcels/boxbackup-0.09-backup-client-Linux.tgz rm -rf parcels/boxbackup-0.09-backup-server-Linux rm -f parcels/boxbackup-0.09-backup-server-Linux.tgz [remco at isis boxbackup-0.09]$ make mkdir parcels/boxbackup-0.09-backup-client-Linux (cd bin/bbackupd; make RELEASE=1)make[1]: Entering directory `/home/remco/src/boxbackup-0.09/bin/bbackupd' (cd ../../lib/common; make RELEASE=1 NODEPS=1) make[2]: Entering directory `/home/remco/src/boxbackup-0.09/lib/common' (echo -n > ../../release/lib/common/common.a; rm ../../release/lib/common/common .a) ar -q ../../release/lib/common/common.a ../../release/lib/common/Configuration.o ../../release/lib/common/IOStream.o ../../release/lib/common/LinuxWorkaround.o ../../release/lib/common/NamedLock.o ../../release/lib/common/WaitForEvent.o ../ ../release/lib/common/CollectInBufferStream.o ../../release/lib/common/MemBlockS tream.o ../../release/lib/common/DebugMemLeakFinder.o ../../release/lib/common/a utogen_CommonException.o ../../release/lib/common/BoxTime.o ../../release/lib/co mmon/BoxException.o ../../release/lib/common/DebugAssertFailed.o ../../release/l ib/common/FdGetLine.o ../../release/lib/common/UnixUser.o ../../release/lib/comm on/PartialReadStream.o ../../release/lib/common/StreamableMemBlock.o ../../relea se/lib/common/ReadGatherStream.o ../../release/lib/common/EventWatchFilesystemOb ject.o ../../release/lib/common/autogen_ConversionException.o ../../release/lib/ common/BoxTimeToText.o ../../release/lib/common/Utils.o ../../release/lib/common /ConversionString.o ../../release/lib/common/ExcludeList.o ../../release/lib/com mon/IOStreamGetLine.o ../../release/lib/common/DebugPrintf.o ../../release/lib/c ommon/FileStream.o ar: creating ../../release/lib/common/common.a ranlib ../../release/lib/common/common.a make[2]: Leaving directory `/home/remco/src/boxbackup-0.09/lib/common' (cd ../../lib/compress; make RELEASE=1 NODEPS=1) make[2]: Entering directory `/home/remco/src/boxbackup-0.09/lib/compress' (echo -n > ../../release/lib/compress/compress.a; rm ../../release/lib/compress/ compress.a) ar -q ../../release/lib/compress/compress.a ../../release/lib/compress/CompressS tream.o ../../release/lib/compress/autogen_CompressException.o ar: creating ../../release/lib/compress/compress.a ranlib ../../release/lib/compress/compress.a make[2]: Leaving directory `/home/remco/src/boxbackup-0.09/lib/compress' (cd ../../lib/crypto; make RELEASE=1 NODEPS=1) make[2]: Entering directory `/home/remco/src/boxbackup-0.09/lib/crypto' (echo -n > ../../release/lib/crypto/crypto.a; rm ../../release/lib/crypto/crypto .a) ar -q ../../release/lib/crypto/crypto.a ../../release/lib/crypto/CipherAES.o ../ ../release/lib/crypto/CipherContext.o ../../release/lib/crypto/CipherDescription .o ../../release/lib/crypto/CipherBlowfish.o ../../release/lib/crypto/Random.o . ./../release/lib/crypto/autogen_CipherException.o ../../release/lib/crypto/MD5Di gest.o ../../release/lib/crypto/RollingChecksum.o ar: creating ../../release/lib/crypto/crypto.a ranlib ../../release/lib/crypto/crypto.a make[2]: Leaving directory `/home/remco/src/boxbackup-0.09/lib/crypto' (cd ../../lib/server; make RELEASE=1 NODEPS=1) make[2]: Entering directory `/home/remco/src/boxbackup-0.09/lib/server' g++ -DNDEBUG -O2 -Wall -I../../lib/common -DPLATFORM_LINUX -DBOX_VERSION="\"0.09 \"" -D_FILE_OFFSET_BITS=64 -c Protocol.cpp -o ../../release/lib/server/Protocol .o In file included from ../../lib/common/Box.h:183, from Protocol.cpp:49: /usr/include/asm/byteorder.h:6:2: warning: #warning using private kernel header; include instead! In file included from Protocol.cpp:59: ProtocolWire.h:58: error: stray ???#??? in program ProtocolWire.h:78: error: stray ???#??? in program ProtocolWire.h:58: error: ???pragma??? does not name a type ProtocolWire.h:64: error: expected constructor, destructor, or type conversion b efore ???;??? token ProtocolWire.h:78: error: ???pragma??? does not name a type ../../lib/common/PartialReadStream.h:62: error: invalid use of undefined type ???s truct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? ../../lib/common/PartialReadStream.h:74: error: ???pos_type??? does not name a type ../../lib/common/PartialReadStream.h:63: warning: ???class PartialReadStream??? has virtual functions but non-virtual destructor ../../lib/common/PartialReadStream.h:73: error: incomplete type ???IOStream??? used in nested name specifier ProtocolUncertainStream.h:62: error: invalid use of undefined type ???struct IOStr eam??? Protocol.h:54: error: forward declaration of ???struct IOStream??? ProtocolUncertainStream.h:74: error: ???pos_type??? does not name a type ProtocolUncertainStream.h:63: warning: ???class ProtocolUncertainStream??? has virtu al functions but non-virtual destructor ProtocolUncertainStream.h:73: error: incomplete type ???IOStream??? used in nested n ame specifier Protocol.cpp: In member function ???void Protocol::Handshake()???: Protocol.cpp:164: error: ???PW_Handshake??? was not declared in this scope Protocol.cpp:164: error: expected `;' before ???hsSend??? Protocol.cpp:165: error: ???hsSend??? was not declared in this scope Protocol.cpp:170: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp:171: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp:174: error: expected `;' before ???hsReceive??? Protocol.cpp:175: error: ???hsReceive??? was not declared in this scope Protocol.cpp:181: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp: In member function ???void Protocol::CheckAndReadHdr(void*)???: Protocol.cpp:225: error: invalid use of undefined type ???struct IOStream???Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp: In member function ???std::auto_ptr Protocol::Receiv e()???: Protocol.cpp:266: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp: In member function ???void Protocol::Send(const ProtocolObject&)???: Protocol.cpp:359: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp:360: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp: In member function ???void Protocol::SendStream(IOStream&)???: Protocol.cpp:716: error: incomplete type ???IOStream??? used in nested name specifie r Protocol.cpp:716: error: expected `;' before ???streamSize??? Protocol.cpp:717: error: ???streamSize??? was not declared in this scope Protocol.cpp:717: error: incomplete type ???IOStream??? used in nested name specifie r Protocol.cpp:725: error: ???streamSize??? was not declared in this scope Protocol.cpp:733: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp:750: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp:753: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp:767: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp:781: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp:787: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? Protocol.cpp: In member function ???int Protocol::SendStreamSendBlock(u_int8_t*, i nt)???: Protocol.cpp:835: error: invalid use of undefined type ???struct IOStream??? Protocol.h:54: error: forward declaration of ???struct IOStream??? /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/memory: In de structor ???std::auto_ptr<_Tp>::~auto_ptr() [with _Tp = IOStream]???: Protocol.cpp:689: instantiated from here /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/memory:259: w arning: possible problem detected in invocation of delete operator: /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/memory:259: w arning: invalid use of undefined type ???struct IOStream??? Protocol.h:54: warning: forward declaration of ???struct IOStream??? /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/memory:259: n ote: neither the destructor nor the class-specific operator delete will be calle d, even if they are declared when the class is defined. make[2]: *** [../../release/lib/server/Protocol.o] Error 1 make[2]: Leaving directory `/home/remco/src/boxbackup-0.09/lib/server' make[1]: *** [dep_modules] Error 2 make[1]: Leaving directory `/home/remco/src/boxbackup-0.09/bin/bbackupd' make: *** [parcels/boxbackup-0.09-backup-client-Linux.tgz] Error 2 --------------070607000402070501020807-- From boxbackup at fluffy.co.uk Fri Aug 5 12:56:52 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Fri, 5 Aug 2005 12:56:52 +0100 Subject: [Box Backup] Re: Make/install help In-Reply-To: <42F34EE7.6090408@beryllium.net> References: <6D67BD77-B287-4DE8-BD8D-CBA2BC9718C1@fluffy.co.uk> <42F34EE7.6090408@beryllium.net> Message-ID: <4AD49B43-40B9-41BD-9D95-ADAAADA3CA28@fluffy.co.uk> On 5 Aug 2005, at 12:35, Remco Poelstra wrote: > Ben Summers wrote: > >> Are you using gcc v4? (type gcc --version to see the version >> number). If so, you'll need a small change to infrastructure/ >> BoxPlatform.pm: >> $gcc_v3 = 1 if (m/version gcc [34]/ || m/gcc version >> [34]/ || m/gcc \(GCC\) [34]/i || m/gcc.Version\s+[34]/i); >> > > Hi, > > I've the same problem, so I was watching this thread for a > solution. I'm using GCC 4 (FC 4), but fixing the above doesn't > help. I get the attached errors. > Furthermore, I would like to make an rpm, how can I make a tarball > with the fix, so I can do rpmbuild -ta ? It looks like the configure script still didn't realise that it's GCC v4. Instead, wipe out your sources, then do ./configure compile:-DPLATFORM_GCC3 (that is correct to use 3, not 4) And can you post the output of gcc --version? Maybe RedHat have "customised" it again. I do love Linux. Especially the way that all the distributions change things subtly for no real good reason, making application authors adjust for every single distribution. There is an rpm description file in the contrib directory, but whether it'll work on RedHat's latest wonder, who knows? Hopefully the Linux experts on this list will help out. Ben From boxbackup at fluffy.co.uk Fri Aug 5 13:11:49 2005 From: boxbackup at fluffy.co.uk (Remco Poelstra) Date: Fri, 05 Aug 2005 14:11:49 +0200 Subject: [Box Backup] Re: Make/install help In-Reply-To: <4AD49B43-40B9-41BD-9D95-ADAAADA3CA28@fluffy.co.uk> References: <6D67BD77-B287-4DE8-BD8D-CBA2BC9718C1@fluffy.co.uk> <42F34EE7.6090408@beryllium.net> <4AD49B43-40B9-41BD-9D95-ADAAADA3CA28@fluffy.co.uk> Message-ID: <42F35785.7040301@beryllium.net> Ben Summers wrote: > It looks like the configure script still didn't realise that it's GCC > v4. Instead, wipe out your sources, then do > > ./configure compile:-DPLATFORM_GCC3 > > (that is correct to use 3, not 4) This works. Thank you. > And can you post the output of gcc --version? Maybe RedHat have > "customised" it again. [remco at isis boxbackup-0.09]$ gcc --version gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'll try the rpm later.... I'll first try to get my backups back. Remco Poelstra From boxbackup at fluffy.co.uk Fri Aug 5 13:01:56 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Fri, 05 Aug 2005 13:01:56 +0100 Subject: [Box Backup] Re: Make/install help In-Reply-To: <4AD49B43-40B9-41BD-9D95-ADAAADA3CA28@fluffy.co.uk> References: <6D67BD77-B287-4DE8-BD8D-CBA2BC9718C1@fluffy.co.uk> <42F34EE7.6090408@beryllium.net> <4AD49B43-40B9-41BD-9D95-ADAAADA3CA28@fluffy.co.uk> Message-ID: <1123243316.2978.2.camel@avenin.ebourne.me.uk> On Fri, 2005-08-05 at 12:56 +0100, Ben Summers wrote: > And can you post the output of gcc --version? Maybe RedHat have > "customised" it again. > > I do love Linux. Especially the way that all the distributions change > things subtly for no real good reason, making application authors > adjust for every single distribution. > > There is an rpm description file in the contrib directory, but > whether it'll work on RedHat's latest wonder, who knows? Hopefully > the Linux experts on this list will help out. Yes, the rpm still compiles fine on FC3 and FC4. The only change needed is the version check change above, which does work. I can only guess that either the original user made an error when applying the change, or didn't rerun configure or something. There's no reason it shouldn't work on FC4. Cheers, Martin. From boxbackup at fluffy.co.uk Tue Aug 9 14:32:07 2005 From: boxbackup at fluffy.co.uk (Johannes Dagemark) Date: Tue, 09 Aug 2005 15:32:07 +0200 Subject: [Box Backup] recursive restore Message-ID: <42F8B057.80206@op5.se> Hi all Maby a stupied question but is there a way to restore a directory and all its contents? For example if I have deleted a dir which had thousands of files it would be a bit timeconsuming to do 'get' for each one of the files. Cheers Johannes Dagemark From boxbackup at fluffy.co.uk Tue Aug 9 14:33:57 2005 From: boxbackup at fluffy.co.uk (Johannes Dagemark) Date: Tue, 09 Aug 2005 15:33:57 +0200 Subject: [Box Backup] recursive restore In-Reply-To: <42F8B057.80206@op5.se> References: <42F8B057.80206@op5.se> Message-ID: <42F8B0C5.2050600@op5.se> forget about it, I found the answer. sorry. /Johannes Johannes Dagemark wrote: > Hi all > > Maby a stupied question but is there a way to restore a directory and > all its contents? > > For example if I have deleted a dir which had thousands of files it > would be a bit timeconsuming to do 'get' for each one of the files. > > Cheers > Johannes Dagemark > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Tue Aug 9 14:37:01 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 9 Aug 2005 14:37:01 +0100 Subject: [Box Backup] recursive restore In-Reply-To: <42F8B057.80206@op5.se> References: <42F8B057.80206@op5.se> Message-ID: <8820AD23-992B-4D3D-8F90-9D4A51E06231@fluffy.co.uk> On 9 Aug 2005, at 14:32, Johannes Dagemark wrote: > Hi all > > Maby a stupied question but is there a way to restore a directory > and all its contents? Yes. > > For example if I have deleted a dir which had thousands of files it > would be a bit timeconsuming to do 'get' for each one of the files. Run bbackupquery, type help restore for more details. Ben From boxbackup at fluffy.co.uk Tue Aug 9 14:35:47 2005 From: boxbackup at fluffy.co.uk (Garry Glendown) Date: Tue, 09 Aug 2005 15:35:47 +0200 Subject: [Box Backup] recursive restore In-Reply-To: <42F8B057.80206@op5.se> References: <42F8B057.80206@op5.se> Message-ID: <42F8B133.6000308@nethinks.com> Johannes Dagemark wrote: > Hi all > > Maby a stupied question but is there a way to restore a directory and > all its contents? > > For example if I have deleted a dir which had thousands of files it > would be a bit timeconsuming to do 'get' for each one of the files. "help" is your friend ... or the manual ... have you tried "restore"? Works for me ;) -gg From boxbackup at fluffy.co.uk Fri Aug 12 09:04:50 2005 From: boxbackup at fluffy.co.uk (Garry Glendown) Date: Fri, 12 Aug 2005 10:04:50 +0200 Subject: [Box Backup] Suggestion ... Message-ID: <42FC5822.5090809@glendown.de> Hi Ben, just a minor suggestion - how about extending the program help syntax a bit? Mainly of bbstoreaccounts! While e.g. bbstored-config is pretty verbose, and bbackupctl lists the option, the one I use the least has close to no information on the usage ... I know what I want to do, but as I only need the command every other month, I always find myself having to go back to the webpage to look up the usage for setlimit etc ... ;) (maybe I'm just getting old ;)) Tnx, -garry From boxbackup at fluffy.co.uk Mon Aug 15 20:09:54 2005 From: boxbackup at fluffy.co.uk (Leo De Geer) Date: Mon, 15 Aug 2005 21:09:54 +0200 Subject: [Box Backup] problem to get bbstored to start (2/2) - RaidFile BadConfigFile Message-ID: <200508151909.j7FJ9sqB041085@bamse2.ktv.se> The raidfile.conig are working ok and eaven the bbstore-config are ok = buth then i start to create users and are trying to start thebbstored i get = the error (2/2) - RaidFile BadConfigFile. This is my raidconfig file disc0 { SetNumber =3D 0 BlockSize =3D 2048 Dir0 =3D /raid0.0 Dir1 =3D /raid0.1 Dir2 =3D /raid0.2 } disc1 { SetNumber =3D 0 BlockSize =3D 2048 Dir0 =3D /raid1.0 Dir0 =3D /raid1.1 Dir0 =3D /raid1.2 } And the system is FreeBSD 5.4 Stable regards Leo De Geer ____________________________________ mobil +46705915987 hem=A0 +464457121 From boxbackup at fluffy.co.uk Mon Aug 15 20:21:21 2005 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Mon, 15 Aug 2005 12:21:21 -0700 Subject: [Box Backup] problem to get bbstored to start (2/2) - RaidFile BadConfigFile In-Reply-To: <200508151909.j7FJ9sqB041085@bamse2.ktv.se> References: <200508151909.j7FJ9sqB041085@bamse2.ktv.se> Message-ID: <4300EB31.5090306@reedtz.com> On 8/15/05 12:09 PM, Leo De Geer wrote: >The raidfile.conig are working ok and eaven the bbstore-config are ok buth >then i start to create users and are trying to start thebbstored i get the >error (2/2) - RaidFile BadConfigFile. This is my raidconfig file > >disc0 >{ > SetNumber = 0 > BlockSize = 2048 > Dir0 = /raid0.0 > Dir1 = /raid0.1 > Dir2 = /raid0.2 >} > >disc1 >{ > SetNumber = 0 > BlockSize = 2048 > Dir0 = /raid1.0 > Dir0 = /raid1.1 > Dir0 = /raid1.2 >} > >And the system is FreeBSD 5.4 Stable > > A couple of things: The SetNumber should be 1, not 0. You now have two sets with the same setnumber. Also, you need to name the 'DirX' variables using increasing numbers, as follows: disc1 { SetNumber = 1 BlockSize = 2048 Dir0 = /raid1.0 Dir1 = /raid1.1 Dir2 = /raid1.2 } HTH, Per -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Mon Aug 15 20:41:35 2005 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Mon, 15 Aug 2005 15:41:35 -0400 Subject: [Box Backup] Total transferred bytes reporting on the server Message-ID: <4300EFEF.8080502@overnet.qc.ca> Would it be easy to add logging for the amount of bytes transferred during a connection on the server side? Something very simple, like sending a line to syslog with the number of bytes transferred along with the account number, once a connection ends (even if the connection ends in error). If I recall the client already does this, but could it be possible on the server? The obvious use for this is to know who's making our monthly quota exceed its limit. Pascal Lalonde From boxbackup at fluffy.co.uk Tue Aug 16 17:36:49 2005 From: boxbackup at fluffy.co.uk (Mikael Syska) Date: Tue, 16 Aug 2005 18:36:49 +0200 Subject: [Box Backup] Long time since last release.... Message-ID: <43021621.6060702@syska.dk> Hi Ben, Are the work on BoxBackup towards a new release in the near future, and what might we expect of new features? There have been alot of suggestions on the list, both good and bad I think! But I cant seen to find a list of what we can expect of it in the future... kind regards Mikael Syska From boxbackup at fluffy.co.uk Tue Aug 16 17:43:43 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 16 Aug 2005 17:43:43 +0100 Subject: [Box Backup] Long time since last release.... In-Reply-To: <43021621.6060702@syska.dk> References: <43021621.6060702@syska.dk> Message-ID: On 16 Aug 2005, at 17:36, Mikael Syska wrote: > Hi Ben, > > Are the work on BoxBackup towards a new release in the near future, > and what might we expect of new features? There have been alot of > suggestions on the list, both good and bad I think! But I cant seen > to find a list of what we can expect of it in the future... To be honest, I haven't had much time to work on Box Backup recently. There is a lot of stuff which has been contributed, including the Win32 port and a vastly improved diffing algorithm. I think the next release should wrap all this up, and then the one after will add the lovely new features. I am considering using a CVS server on Sourceforge, importing the latest version, and then inviting the contributers to commit their changes. I'm not sure what to do about style and quality issues though. Then if there's enough interest, perhaps the features could be added as a collaborative effort too? Ben From boxbackup at fluffy.co.uk Tue Aug 16 17:44:26 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 16 Aug 2005 17:44:26 +0100 Subject: [Box Backup] Suggestion ... In-Reply-To: <42FC5822.5090809@glendown.de> References: <42FC5822.5090809@glendown.de> Message-ID: On 12 Aug 2005, at 09:04, Garry Glendown wrote: > Hi Ben, > > just a minor suggestion - how about extending the program help > syntax a > bit? Mainly of bbstoreaccounts! While e.g. bbstored-config is pretty > verbose, and bbackupctl lists the option, the one I use the least has > close to no information on the usage ... I know what I want to do, but > as I only need the command every other month, I always find myself > having to go back to the webpage to look up the usage for setlimit etc > ... ;) (maybe I'm just getting old ;)) I'm not entirely clear what you're asking for. An explanatory message when the arguments are incorrect? Or something else? Ben From boxbackup at fluffy.co.uk Tue Aug 16 17:49:40 2005 From: boxbackup at fluffy.co.uk (Leo De Geer) Date: Tue, 16 Aug 2005 18:49:40 +0200 Subject: [Box Backup] Long time since last release.... In-Reply-To: Message-ID: <200508161649.j7GGnat3065056@bamse2.ktv.se> Where can i get the win32 port im trying to get the cygwin port to work but i can't get it to work on my computer. Im running all my FreeBSD to one vox bacup and are trying to get the win xp to do the same. Regards leo ____________________________________ mobil +46705915987 hem +464457121 -----Original Message----- From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] On Behalf Of Ben Summers Sent: den 16 augusti 2005 18:44 To: boxbackup at fluffy.co.uk Subject: Re: [Box Backup] Long time since last release.... On 16 Aug 2005, at 17:36, Mikael Syska wrote: > Hi Ben, > > Are the work on BoxBackup towards a new release in the near future, > and what might we expect of new features? There have been alot of > suggestions on the list, both good and bad I think! But I cant seen > to find a list of what we can expect of it in the future... To be honest, I haven't had much time to work on Box Backup recently. There is a lot of stuff which has been contributed, including the Win32 port and a vastly improved diffing algorithm. I think the next release should wrap all this up, and then the one after will add the lovely new features. I am considering using a CVS server on Sourceforge, importing the latest version, and then inviting the contributers to commit their changes. I'm not sure what to do about style and quality issues though. Then if there's enough interest, perhaps the features could be added as a collaborative effort too? Ben _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Tue Aug 16 18:17:57 2005 From: boxbackup at fluffy.co.uk (Garry Glendown) Date: Tue, 16 Aug 2005 19:17:57 +0200 Subject: [Box Backup] Suggestion ... In-Reply-To: References: <42FC5822.5090809@glendown.de> Message-ID: <43021FC5.30801@nethinks.com> Ben Summers wrote: > > On 12 Aug 2005, at 09:04, Garry Glendown wrote: > >> Hi Ben, >> >> just a minor suggestion - how about extending the program help syntax a >> bit? Mainly of bbstoreaccounts! While e.g. bbstored-config is pretty >> verbose, and bbackupctl lists the option, the one I use the least has >> close to no information on the usage ... I know what I want to do, but >> as I only need the command every other month, I always find myself >> having to go back to the webpage to look up the usage for setlimit etc >> ... ;) (maybe I'm just getting old ;)) > > > I'm not entirely clear what you're asking for. An explanatory message > when the arguments are incorrect? Or something else? ? backup:~ # bbstoreaccounts Usage: bbstoreaccounts [-c config_file] action account_id [args] Account ID is integer specified in hex What I mean is that the help isn't really helpfull, escpecially compared to the relatively long help text of other commands: dustpuppy:~ # bbackupctl Usage: bbackupctl [-q] [-c config_file] Commands are: sync -- start a syncronisation run now force-sync -- force the start of a syncronisation run, even if SyncAllowScript says no reload -- reload daemon configuration terminate -- terminate daemon now wait-for-sync -- wait until the next sync starts, then exit I recon just adding the sample lines for the commands like setlimit etc. would be nice ... ;) -garry From boxbackup at fluffy.co.uk Tue Aug 16 18:25:33 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Tue, 16 Aug 2005 18:25:33 +0100 Subject: [Box Backup] Long time since last release.... In-Reply-To: References: <43021621.6060702@syska.dk> Message-ID: <1124213133.2905.63.camel@avenin.ebourne.me.uk> On Tue, 2005-08-16 at 17:43 +0100, Ben Summers wrote: > I am considering using a CVS server on Sourceforge, importing the > latest version, and then inviting the contributers to commit their > changes. I'm not sure what to do about style and quality issues though. This would be a good start, but I would prefer you used something a bit better than CVS. Personally I have imported recent versions of box into a local SVN repository and make all my mods in there, from which I generate patches. Does sourceforge provide anything other than CVS these days? Some of the other free hosting sites do. I don't think it really matters which version control system you use, as long as it's recent, they're all loads better than CVS. I'm sure that opening up some kind of repository with committer access is the way to go though, that's what open source is all about. > Then if there's enough interest, perhaps the features could be added > as a collaborative effort too? Quite possibly. The thing I'd be most interested in writing would be to add inotify support since it will be in the mainline Linux kernel soon. This would let bbackupd be fed lists of changed files real time from the kernel, and avoid the need to do disk scanning (which has sucked for at least 20 years now :)). Cheers, Martin. From boxbackup at fluffy.co.uk Tue Aug 16 19:44:17 2005 From: boxbackup at fluffy.co.uk (Leo De Geer) Date: Tue, 16 Aug 2005 20:44:17 +0200 Subject: [Box Backup] Long time since last release.... In-Reply-To: <1124213133.2905.63.camel@avenin.ebourne.me.uk> Message-ID: <200508161844.j7GIiETu066726@bamse2.ktv.se> Don't forget that there are more than Linux servers running boxbackup you have allot of BSD brands and they are not running a Linux kernel. Regards Leo ____________________________________ mobil +46705915987 hem +464457121 -----Original Message----- From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] On Behalf Of Martin Ebourne Sent: den 16 augusti 2005 19:26 To: boxbackup at fluffy.co.uk Subject: Re: [Box Backup] Long time since last release.... On Tue, 2005-08-16 at 17:43 +0100, Ben Summers wrote: > I am considering using a CVS server on Sourceforge, importing the > latest version, and then inviting the contributers to commit their > changes. I'm not sure what to do about style and quality issues though. This would be a good start, but I would prefer you used something a bit better than CVS. Personally I have imported recent versions of box into a local SVN repository and make all my mods in there, from which I generate patches. Does sourceforge provide anything other than CVS these days? Some of the other free hosting sites do. I don't think it really matters which version control system you use, as long as it's recent, they're all loads better than CVS. I'm sure that opening up some kind of repository with committer access is the way to go though, that's what open source is all about. > Then if there's enough interest, perhaps the features could be added > as a collaborative effort too? Quite possibly. The thing I'd be most interested in writing would be to add inotify support since it will be in the mainline Linux kernel soon. This would let bbackupd be fed lists of changed files real time from the kernel, and avoid the need to do disk scanning (which has sucked for at least 20 years now :)). Cheers, Martin. _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Tue Aug 16 20:56:09 2005 From: boxbackup at fluffy.co.uk (Mikael Syska) Date: Tue, 16 Aug 2005 21:56:09 +0200 Subject: [Box Backup] Long time since last release.... In-Reply-To: <200508161844.j7GIiETu066726@bamse2.ktv.se> References: <200508161844.j7GIiETu066726@bamse2.ktv.se> Message-ID: <430244D9.2040009@syska.dk> Yo, Primary developed for OpenBSD, the system i run. BSD is the way to go :-) But I will look forward if there will be new developers on the project, I would also help, but my experience in programming aint that good yet, but maybe it will be in a year or 2. // ouT Leo De Geer wrote: >Don't forget that there are more than Linux servers running boxbackup you >have allot of BSD brands and they are not running a Linux kernel. > >Regards Leo >____________________________________ >mobil +46705915987 >hem +464457121 > >-----Original Message----- >From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] On >Behalf Of Martin Ebourne >Sent: den 16 augusti 2005 19:26 >To: boxbackup at fluffy.co.uk >Subject: Re: [Box Backup] Long time since last release.... > >On Tue, 2005-08-16 at 17:43 +0100, Ben Summers wrote: > > >>I am considering using a CVS server on Sourceforge, importing the >>latest version, and then inviting the contributers to commit their >>changes. I'm not sure what to do about style and quality issues though. >> >> > >This would be a good start, but I would prefer you used something a bit >better than CVS. Personally I have imported recent versions of box into >a local SVN repository and make all my mods in there, from which I >generate patches. Does sourceforge provide anything other than CVS these >days? Some of the other free hosting sites do. I don't think it really >matters which version control system you use, as long as it's recent, >they're all loads better than CVS. > >I'm sure that opening up some kind of repository with committer access >is the way to go though, that's what open source is all about. > > > >>Then if there's enough interest, perhaps the features could be added >>as a collaborative effort too? >> >> > >Quite possibly. The thing I'd be most interested in writing would be to >add inotify support since it will be in the mainline Linux kernel soon. >This would let bbackupd be fed lists of changed files real time from the >kernel, and avoid the need to do disk scanning (which has sucked for at >least 20 years now :)). > >Cheers, > >Martin. > >_______________________________________________ >boxbackup mailing list >boxbackup at fluffy.co.uk >http://lists.warhead.org.uk/mailman/listinfo/boxbackup > >_______________________________________________ >boxbackup mailing list >boxbackup at fluffy.co.uk >http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > From boxbackup at fluffy.co.uk Thu Aug 18 00:12:00 2005 From: boxbackup at fluffy.co.uk (Scott McNee) Date: Thu, 18 Aug 2005 09:12:00 +1000 Subject: [Box Backup] Re. Example of quality Code. Message-ID: <002901c5a381$15ecdb40$6501a8c0@SCOTTLAPTOP> Hi All, Just a quick real-life example of the coding quality in box-backup. On one of my systems I accidentally placed the script to call box-backup in the "run once a minute" section of crond. Without even noticing a change the system has been quite happily running once a minute for the last 2 weeks. My congratulation to Ben and all the people who coded box-backup. It is in times like these that you would normally be searching for the reason why the system keeps crashing. Thanks. Scott McNee ITServices From boxbackup at fluffy.co.uk Thu Aug 18 11:25:13 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 18 Aug 2005 11:25:13 +0100 Subject: [Box Backup] Future development plan Message-ID: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> As briefly discussed, I think we need to move to a more collaborative development process to take the project forward properly. I propose: * Set up SVN repository. Import 0.09 + my minor modifications * Add in the following code in branches: - Win32 port (Nick) - Solaris port (Martin) - Autoconf, 64 bit stuff, etc (LinuxOnPower) (Martin) - Optimised diffing (Jonathan) - (anything I've forgotten?) trying to keep different changes in different branches. * In each of the branches, check - Code quality - Code style - Functionality / tests passing * Merge into the main branch * Release to users for testing * Release 0.10 * Agree procedure for design changes and coding amongst developers * Write up design documents for new version * Get coding! Questions we need to answer: * Are all the contributors happy with this plan? * Has everyone got enough time to get this done? * Will people put up with my insistence on the style of the code being consistent? * Where should the SVN repository live? (Sourceforge don't provide one, but there are a few "free" providers listed. I might set up a repository on one of my servers, however.) * What do we do about the license, and who holds the copyright? I use the various libraries to build other private projects, and I'd quite like to be able to bring changes into my own code. I have a preference for the BSD license, because BSD licensed projects have been so helpful to me in the past. But apart from that, I have no strong feelings either way. Thoughts? Ben From boxbackup at fluffy.co.uk Thu Aug 18 11:34:09 2005 From: boxbackup at fluffy.co.uk (Leo De Geer) Date: Thu, 18 Aug 2005 12:34:09 +0200 Subject: [Box Backup] Future development plan In-Reply-To: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> Message-ID: <000501c5a3e0$5e8e19e0$1a00680a@SRSA19> I can set up a SVN on my server if it is interesting Regards Leo De Geer "Dinsignal.com webhosting" -----Original Message----- From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] On Behalf Of Ben Summers Sent: Thursday, 18 August 2005 12:25 PM To: boxbackup at fluffy.co.uk Subject: [Box Backup] Future development plan As briefly discussed, I think we need to move to a more collaborative development process to take the project forward properly. I propose: * Set up SVN repository. Import 0.09 + my minor modifications * Add in the following code in branches: - Win32 port (Nick) - Solaris port (Martin) - Autoconf, 64 bit stuff, etc (LinuxOnPower) (Martin) - Optimised diffing (Jonathan) - (anything I've forgotten?) trying to keep different changes in different branches. * In each of the branches, check - Code quality - Code style - Functionality / tests passing * Merge into the main branch * Release to users for testing * Release 0.10 * Agree procedure for design changes and coding amongst developers * Write up design documents for new version * Get coding! Questions we need to answer: * Are all the contributors happy with this plan? * Has everyone got enough time to get this done? * Will people put up with my insistence on the style of the code being consistent? * Where should the SVN repository live? (Sourceforge don't provide one, but there are a few "free" providers listed. I might set up a repository on one of my servers, however.) * What do we do about the license, and who holds the copyright? I use the various libraries to build other private projects, and I'd quite like to be able to bring changes into my own code. I have a preference for the BSD license, because BSD licensed projects have been so helpful to me in the past. But apart from that, I have no strong feelings either way. Thoughts? Ben _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Thu Aug 18 12:23:07 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Thu, 18 Aug 2005 12:23:07 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> Message-ID: <1124364187.6556.32.camel@avenin.ebourne.me.uk> On Thu, 2005-08-18 at 11:25 +0100, Ben Summers wrote: > I propose: > > * Set up SVN repository. Import 0.09 + my minor modifications > > * Add in the following code in branches: > - Win32 port (Nick) > - Solaris port (Martin) > - Autoconf, 64 bit stuff, etc (LinuxOnPower) (Martin) > - Optimised diffing (Jonathan) > - (anything I've forgotten?) > trying to keep different changes in different branches. I would be happy to make my branch (and maybe a separate one for the autoconf stuff) and import the patches myself. > * In each of the branches, check > - Code quality > - Code style > - Functionality / tests passing > > * Merge into the main branch When we get to this point we should all take a look at the branches and have a discussion as to order of merging to try and make life easier. > * Release to users for testing > > * Release 0.10 > > * Agree procedure for design changes and coding amongst developers > > * Write up design documents for new version > > * Get coding! Sounds like a top plan. > Questions we need to answer: > > * Are all the contributors happy with this plan? Ack. > * Has everyone got enough time to get this done? I can find enough time to merge all my stuff in and support bug fixing etc. As to ongoing development it'll depend on how much I want a feature vs. the work I'm doing on other projects. I don't even need to say I've got limited time, because so has everyone else. ;) > * Will people put up with my insistence on the style of the code > being consistent? Yes, and would encourage you to be moderately pedantic on that one. I've tried quite hard with mine to match your formatting style at least. The only thing I would like to add here is I think that experience has shown that with projects worked on by multiple people using tabs in source code causes endless trouble, especially if not set to the default 8 spaces. It would be worth considering expanding all the tabs to spaces at whatever tab-stop you like and not accepting tabs from then on. But only after we've merged all the current streams of course! > * Where should the SVN repository live? (Sourceforge don't provide > one, but there are a few "free" providers listed. I might set up a > repository on one of my servers, however.) You'd probably be ok with a repository on one of your servers. SVN itself is very low maintenance (with the now default fsfs backend), but you do need to run apache to get webdav, which is preferred. Unlike CVS, SVN keeps local copies of the untouched files in the working copy and hence makes a lot less roundtrips to the server. The server is mainly used for updating so is low traffic. I have a SVN server with box already in it, and I don't mind opening that up to general access if it helps. It's backed up off site (using box of course). Having said that, in the long run you'd probably be better with your own. > * What do we do about the license, and who holds the copyright? Well you know I prefer GPL, mainly to prevent you/us getting ripped off by some company closing the source, which has happened with a number of open source projects. Having said that, I've got nothing against BSD either, and am happy to submit my changes under the BSD licence as before. The only thing I would prefer is the 3-clause BSD licence as discussed previously, but purely from the practical point of being more compatible with other licences - eg. allowing shipping of binaries linked with readline, which is otherwise an issue. > I use the various libraries to build other private projects, and I'd > quite like to be able to bring changes into my own code. I have a > preference for the BSD license, because BSD licensed projects have > been so helpful to me in the past. But apart from that, I have no > strong feelings either way. Me neither. If you stick with the current licence with your name on it then that's fine by me, I think you deserve credit after all. :) If you were to change the licence for box then I also don't mind giving dual licence on any of the relevant code so you can continue to use that for other projects. Cheers, Martin. From boxbackup at fluffy.co.uk Thu Aug 18 13:44:09 2005 From: boxbackup at fluffy.co.uk (Gary) Date: Thu, 18 Aug 2005 05:44:09 -0700 (PDT) Subject: [Box Backup] Future development plan In-Reply-To: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> Message-ID: <20050818124409.85671.qmail@web30210.mail.mud.yahoo.com> Ben, > - (anything I've forgotten?) A couple of things included in my own version of boxbackup (http://home.earthlink.net/~gniemcew/): 1.) Unlimited MaximumDiffingTime. It seems that the diffing algorithm under both Win32 and Cygwin does not work too well on very large files (500MB and up), thus causing very large uploads. The mod allows for unlimited diffing time. 2.) KeepAliveTime. In case of very long or unlimited file diff operations when searching for changes in large files, it is possible for an SSL session/connection to time out, causing various upload errors when a scan completes. The KeepAliveTime modification adds a set of GetIsAlive() and IsAlive() client/server commands, to produce factual packet traffic while a file diff operation is in progress. ----- The problem that the above two items above solve (for me) has been seen under both Win32 and Cygwin, and (I believe) have been already merged by Nick into the Win32 port. If we have a better diffing algorithm for very large files, we could discard those two changes. ----- 3.) StoreObjectInfoFile. Re-scanning a backup set for changes after a shutdown/restart becomes almost instantaneous. > Thoughts? I think whatever the plan is, we sould really get the end-to-end remote backup store content verification (without the need to re-download the whole content) to work ASAP, if possible. Gary ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From boxbackup at fluffy.co.uk Thu Aug 18 13:36:41 2005 From: boxbackup at fluffy.co.uk (Jonathan Morton) Date: Thu, 18 Aug 2005 13:36:41 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> Message-ID: <03616f835329d7c314bc85693882de47@chromatix.uklinux.net> > I propose: > > * Set up SVN repository. Import 0.09 + my minor modifications > > * Add in the following code in branches: > - Win32 port (Nick) > - Solaris port (Martin) > - Autoconf, 64 bit stuff, etc (LinuxOnPower) (Martin) > - Optimised diffing (Jonathan) > - (anything I've forgotten?) > trying to keep different changes in different branches. Seems reasonable. > * Has everyone got enough time to get this done? It may be slow at my end, but I can get things done. > * Will people put up with my insistence on the style of the code being > consistent? Consistent code style is a good idea, although I think yours is slightly different from mine... > * Where should the SVN repository live? (Sourceforge don't provide > one, but there are a few "free" providers listed. I might set up a > repository on one of my servers, however.) No idea about this. > * What do we do about the license, and who holds the copyright? > I use the various libraries to build other private projects, and I'd > quite like to be able to bring changes into my own code. I have a > preference for the BSD license, because BSD licensed projects have > been so helpful to me in the past. But apart from that, I have no > strong feelings either way. For "private" projects, which are never released, the licence doesn't matter at all (unless it's an EULA that prohibits reverse-engineering or something stupid like that - and even that's debatable). The GPL specifically encourages this kind of code sharing. The only problem would be if you wanted to take some of the modified code and use it in a commercial project. Then you'd either need to stipulate to your customer that the result will be released under the GPL, or ensure you have the right to use all the relevant code in a closed-source project, or go back to your original code that you own yourself. One solution would be to gather all "library type" code under an LGPL licence, which encourages code-sharing but does not preclude use in a commercial, closed-source project. Not everyone will be happy with this, but I would hazard that it's the same set of people who would be unhappy with simply assigning copyright. -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. From boxbackup at fluffy.co.uk Thu Aug 18 14:56:25 2005 From: boxbackup at fluffy.co.uk (Nick Knight) Date: Thu, 18 Aug 2005 14:56:25 +0100 Subject: [Box Backup] Future development plan Message-ID: Agree with all - I will try to commit some time to this it is an important project. The diffing time patch is in the win32 port - it would be good to agree to on the approach. Coding standard - definitely the way to go if this is going to be a team effort! Nick -----Original Message----- From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] On Behalf Of Jonathan Morton Sent: 18 August 2005 13:37 To: boxbackup at fluffy.co.uk Subject: Re: [Box Backup] Future development plan > I propose: > > * Set up SVN repository. Import 0.09 + my minor modifications > > * Add in the following code in branches: > - Win32 port (Nick) > - Solaris port (Martin) > - Autoconf, 64 bit stuff, etc (LinuxOnPower) (Martin) > - Optimised diffing (Jonathan) > - (anything I've forgotten?) > trying to keep different changes in different branches. Seems reasonable. > * Has everyone got enough time to get this done? It may be slow at my end, but I can get things done. > * Will people put up with my insistence on the style of the code being > consistent? Consistent code style is a good idea, although I think yours is=20 slightly different from mine... > * Where should the SVN repository live? (Sourceforge don't provide=20 > one, but there are a few "free" providers listed. I might set up a=20 > repository on one of my servers, however.) No idea about this. > * What do we do about the license, and who holds the copyright? > I use the various libraries to build other private projects, and I'd=20 > quite like to be able to bring changes into my own code. I have a=20 > preference for the BSD license, because BSD licensed projects have=20 > been so helpful to me in the past. But apart from that, I have no=20 > strong feelings either way. For "private" projects, which are never released, the licence doesn't=20 matter at all (unless it's an EULA that prohibits reverse-engineering=20 or something stupid like that - and even that's debatable). The GPL=20 specifically encourages this kind of code sharing. The only problem would be if you wanted to take some of the modified=20 code and use it in a commercial project. Then you'd either need to=20 stipulate to your customer that the result will be released under the=20 GPL, or ensure you have the right to use all the relevant code in a=20 closed-source project, or go back to your original code that you own=20 yourself. One solution would be to gather all "library type" code under an LGPL=20 licence, which encourages code-sharing but does not preclude use in a=20 commercial, closed-source project. Not everyone will be happy with=20 this, but I would hazard that it's the same set of people who would be=20 unhappy with simply assigning copyright. -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Thu Aug 18 15:18:53 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 18 Aug 2005 15:18:53 +0100 Subject: [Box Backup] Future development plan In-Reply-To: References: Message-ID: <9E4E639E-0DBD-4250-9408-7278DEC42877@fluffy.co.uk> On 18 Aug 2005, at 14:56, Nick Knight wrote: > Agree with all - I will try to commit some time to this it is an > important project. > > The diffing time patch is in the win32 port - it would be good to > agree > to on the approach. And with that, we have basic agreement from all the recent contributors. (I'm really hoping I haven't forgotten anyone having said that!) > > Coding standard - definitely the way to go if this is going to be a > team > effort! I shall write some brief notes on it, and get agreement before we start. But having said that, I got here first. There is the tab stop issue. I work with tabs set to four spaces, and I do know how painful it is to work with others. Especially emacs users, who seem to delight in using wonderfully odd combinations of spaces and tabs. On the license, Martin's comments are only relevant to GPL licenses. The BSD license would allow me to pull back changes. If we're to stay with the BSD license, there are two issues: 1) The copyright holder. When there are multiple contributors, it becomes confusing. However, I think this is only a real issue for GPL projects who wish to have a dual license in the future. 2) The "advertising clause". This becomes much less clear-cut when there are many contributors. Amusingly, if we let it stand, I would have to enforce that clause on any changes I pulled back. I hope I'm not going into too much detail or making too big a thing out of this, but I don't want to have licensing issues or misunderstandings later on! Ben > -----Original Message----- > From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup- > admin at fluffy.co.uk] > On Behalf Of Jonathan Morton > Sent: 18 August 2005 13:37 > To: boxbackup at fluffy.co.uk > Subject: Re: [Box Backup] Future development plan > > >> I propose: >> >> * Set up SVN repository. Import 0.09 + my minor modifications >> >> * Add in the following code in branches: >> - Win32 port (Nick) >> - Solaris port (Martin) >> - Autoconf, 64 bit stuff, etc (LinuxOnPower) (Martin) >> - Optimised diffing (Jonathan) >> - (anything I've forgotten?) >> trying to keep different changes in different branches. >> > > Seems reasonable. > > >> * Has everyone got enough time to get this done? >> > > It may be slow at my end, but I can get things done. > > >> * Will people put up with my insistence on the style of the code >> being >> > > >> consistent? >> > > Consistent code style is a good idea, although I think yours is > slightly different from mine... > > >> * Where should the SVN repository live? (Sourceforge don't provide >> one, but there are a few "free" providers listed. I might set up a >> repository on one of my servers, however.) >> > > No idea about this. > > >> * What do we do about the license, and who holds the copyright? >> > > >> I use the various libraries to build other private projects, and I'd >> quite like to be able to bring changes into my own code. I have a >> preference for the BSD license, because BSD licensed projects have >> been so helpful to me in the past. But apart from that, I have no >> strong feelings either way. >> > > For "private" projects, which are never released, the licence doesn't > matter at all (unless it's an EULA that prohibits reverse-engineering > or something stupid like that - and even that's debatable). The GPL > specifically encourages this kind of code sharing. > > The only problem would be if you wanted to take some of the modified > code and use it in a commercial project. Then you'd either need to > stipulate to your customer that the result will be released under the > GPL, or ensure you have the right to use all the relevant code in a > closed-source project, or go back to your original code that you own > yourself. > > One solution would be to gather all "library type" code under an LGPL > licence, which encourages code-sharing but does not preclude use in a > commercial, closed-source project. Not everyone will be happy with > this, but I would hazard that it's the same set of people who would be > unhappy with simply assigning copyright. > > -------------------------------------------------------------- > from: Jonathan "Chromatix" Morton > mail: chromi at chromatix.demon.co.uk > website: http://www.chromatix.uklinux.net/ > tagline: The key to knowledge is not to rely on people to teach > you it. > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Thu Aug 18 15:27:14 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Thu, 18 Aug 2005 15:27:14 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <9E4E639E-0DBD-4250-9408-7278DEC42877@fluffy.co.uk> References: <9E4E639E-0DBD-4250-9408-7278DEC42877@fluffy.co.uk> Message-ID: <1124375234.6556.37.camel@avenin.ebourne.me.uk> On Thu, 2005-08-18 at 15:18 +0100, Ben Summers wrote: > And with that, we have basic agreement from all the recent > contributors. (I'm really hoping I haven't forgotten anyone having > said that!) Excellent! I wonder if this would be a good time to split the list into -users and -dev to prevent everyone else from getting spammed. > There is the tab stop issue. I work with tabs set to four spaces, and > I do know how painful it is to work with others. Especially emacs > users, who seem to delight in using wonderfully odd combinations of > spaces and tabs. Only because Emacs makes it so easy, I'm sure. :) I always use Emacs and from my own editing point of view the tabs are fine since I've set Emacs up to that style. However, the diversity of editors and other tools out there makes spaces a better bet. I think it would make sense to wait till the code is all merged and then just run expand on the whole lot in one go. That way there'll be no conflicts and no pain. Cheers, Martin. From boxbackup at fluffy.co.uk Thu Aug 18 16:19:41 2005 From: boxbackup at fluffy.co.uk (Charles Lecklider) Date: Thu, 18 Aug 2005 16:19:41 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> Message-ID: <4304A70D.4050500@invis.net> Ben Summers wrote: > > As briefly discussed, I think we need to move to a more collaborative > development process to take the project forward properly. > > I propose: > > * Set up SVN repository. Import 0.09 + my minor modifications Have you considered Perforce? Being an Open Source project Perforce will give you a free licence (see ), and without wishing to start a "my SCM is better than your SCM" war, IMHO it is better than SVN ;-) If finding something to run Perforce on is an issue I can do that here. I think moving to some sort of SCM is a great idea. I've threatened to do some work on the Win32 side a couple of times, but never seem to have quite enough time to do the work and explain the changes well enough that e.g. Nick can see the point; SCM would solve that for me. As for coding style, I simply assumed that it would need to follow the existing code. I don't see it working any other way. Tabs have been raised as an issue, and while I prefer tabs over spaces, I think the key issue is consistency. If the existing source uses tabs then I suggest that the style guide says clearly that "tabs are X spaces big, changes that don't match that will be reverted". As for the license, I'd rather put my code under the existing BSD one. I don't much care about attribution - there'll be a list of contributors someplace I'm sure, that's good enough. Again, without wishing to start a war, either the code is going to be Free, or it isn't; BSD is, GPL isn't. I think that covers all the major points.... -C From boxbackup at fluffy.co.uk Thu Aug 18 16:22:25 2005 From: boxbackup at fluffy.co.uk (Jonathan Morton) Date: Thu, 18 Aug 2005 16:22:25 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <1124375234.6556.37.camel@avenin.ebourne.me.uk> References: <9E4E639E-0DBD-4250-9408-7278DEC42877@fluffy.co.uk> <1124375234.6556.37.camel@avenin.ebourne.me.uk> Message-ID: <3f8c9313c18d68bd404c37df04e448b9@chromatix.uklinux.net> > However, the diversity of editors and other tools out there makes > spaces > a better bet. I think it would make sense to wait till the code is all > merged and then just run expand on the whole lot in one go. That way > there'll be no conflicts and no pain. A better idea, IMO, is to run a "pretty printer" over the code before each merge. Most of these can be set up for a particular style, as long as it isn't too esoteric. Emacs even has one built-in (I think it's somewhere near the kitchen sink and the coffee maker). I prefer to use tabs rather than spaces, otherwise I'll get COBOL fingers from my space and backspace keys. I happen to use Nedit and CodeWarrior (depending on which platform I'm working on), which are both easy to set up for arbitrary-width tabs - and I think four is probably better than two or eight, which are the other common possibilities. -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. From boxbackup at fluffy.co.uk Thu Aug 18 18:13:41 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 18 Aug 2005 18:13:41 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <4304A70D.4050500@invis.net> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> <4304A70D.4050500@invis.net> Message-ID: On 18 Aug 2005, at 16:19, Charles Lecklider wrote: > Ben Summers wrote: > >> >> As briefly discussed, I think we need to move to a more collaborative >> development process to take the project forward properly. >> >> I propose: >> >> * Set up SVN repository. Import 0.09 + my minor modifications >> > > Have you considered Perforce? Being an Open Source project Perforce > will > give you a free licence (see > ), and without > wishing to start a "my SCM is better than your SCM" war, IMHO it is > better than SVN ;-) If finding something to run Perforce on is an > issue > I can do that here. Would anyone really object if Perforce is used? The branch and merge functionality looks rather neat. It is an amusing thought to use a closed source SCM on an open source project though... Ben From boxbackup at fluffy.co.uk Thu Aug 18 20:09:40 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Thu, 18 Aug 2005 20:09:40 +0100 Subject: [Box Backup] Future development plan In-Reply-To: References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> <4304A70D.4050500@invis.net> Message-ID: <1124392181.6556.74.camel@avenin.ebourne.me.uk> On Thu, 2005-08-18 at 18:13 +0100, Ben Summers wrote: > Would anyone really object if Perforce is used? The branch and merge > functionality looks rather neat. I don't run closed source software on any of my machines, so I personally wouldn't use it. As to whether it's really a better solution I've never used Perforce so can't help. But I've read some of the manual and a few comparison pages and would offer the following. Perforce is faster than subversion, but then Box Backup is a small project, and I know from experience that it runs at an acceptable speed in subversion. Perforce does merge tracking which subversion doesn't do yet. But reading the manual, merging from the command line doesn't seem any easier than subversion, it just saves you looking up revision numbers from the log. Maybe with the graphical tool it is easier, I didn't check. The actual conflict resolution (the bit of merging that can take time) looks almost exactly the same in perforce as in subversion. Perforce doesn't work as well as subversion in disconnected operation - likes to connect to the server for more functions than subversion does, including marking a file as editable. Perforce communicates over a port using its own protocol. Therefore it is not usable in locations where you do not have control over the firewall, whereas subversion over webdav works in all situations including through a http proxy (you can even look at code directly in a web browser). As to merging in subversion, it's one of the easiest of the version control systems I've used. Just as an example, here's an actual transcript grepped from my command line history. It looks like a lot of commands, but then I did quite a lot. I made a branch to hold my submissions, selectively merged a bunch of changesets from two branches into it and then fetched those out as patches. I even split one of the changesets out into two, for good measure. Examples in manuals are never this complicated. :-) These submissions were my last 4 patches to box: svn cp vendor branches/submit svn ci -m "Branched branches/submit from vendor" svn merge -r 9:11 trunk branches/submit svn merge -r 14:15 trunk branches/submit svn revert branches/submit/boxbackup/lib/raidfile/RaidFileWrite.cpp svn ci -m "Merged r10, r11, r15 from trunk to submit, excluding the workaround for RaidFileWrite.cpp from r15." svn merge -r 14:15 trunk branches/submit svn ci -m "Merged the workaround for RaidFileWrite.cpp from r15 on trunk to submit." svn merge -r 4:9 trunk branches/submit svn merge -r 11:14 trunk branches/submit svn merge -r 15:16 trunk branches/submit svn ci -m "Merged r4:9, r11:14, r16 from trunk into submit." svn merge -r 17:49 branches/autoconf branches/submit svn ci -m "Merged r17:49 from autoconf into submit." svn diff -r 53:54 > ~/stuff/box/competition/1-ppc-fixes.patch svn diff -r 54:55 > ~/stuff/box/competition/2-ppc-workaround.patch svn diff -r 55:56 > ~/stuff/box/competition/3-xattr.patch svn diff -r 56:57 > ~/stuff/box/competition/4-autoconf.patch Cheers, Martin. From boxbackup at fluffy.co.uk Thu Aug 18 20:36:25 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 18 Aug 2005 20:36:25 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <1124392181.6556.74.camel@avenin.ebourne.me.uk> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> <4304A70D.4050500@invis.net> <1124392181.6556.74.camel@avenin.ebourne.me.uk> Message-ID: <5A8A612D-B76F-4BB2-9AEB-28F9BF991DF6@fluffy.co.uk> On 18 Aug 2005, at 20:09, Martin Ebourne wrote: > On Thu, 2005-08-18 at 18:13 +0100, Ben Summers wrote: > >> Would anyone really object if Perforce is used? The branch and merge >> functionality looks rather neat. >> > > I don't run closed source software on any of my machines, so I > personally wouldn't use it. Well there we go. A veto. So SVN it is. :-) Thanks for the notes comparing the two. I've never done merging in SVN, I've always used CVS before. Ben From boxbackup at fluffy.co.uk Thu Aug 18 20:47:49 2005 From: boxbackup at fluffy.co.uk (Mr R G Shepherd) Date: Thu, 18 Aug 2005 20:47:49 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <5A8A612D-B76F-4BB2-9AEB-28F9BF991DF6@fluffy.co.uk> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> <4304A70D.4050500@invis.net> <1124392181.6556.74.camel@avenin.ebourne.me.uk> <5A8A612D-B76F-4BB2-9AEB-28F9BF991DF6@fluffy.co.uk> Message-ID: <4304E5E5.5040608@robshepherd.net> Ben Summers wrote: > Well there we go. A veto. So SVN it is. :-) Grab a recent version of SVN, so you get a nice stable fsfs backend by default instead of Berkeley-db. eurgh :) Whilst SVN is nice, I found bdb ridiculous, nothing but trouble. Even for my one-man rcs type setup.... (I got into the habit of dumping the dbs four times a day.... well cron did) Its new native format (fsfs) is supposedly faster and definately much less prone to screwing up... $*50^-1 Rob From boxbackup at fluffy.co.uk Thu Aug 18 21:30:30 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Thu, 18 Aug 2005 21:30:30 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <4304E5E5.5040608@robshepherd.net> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> <4304A70D.4050500@invis.net> <1124392181.6556.74.camel@avenin.ebourne.me.uk> <5A8A612D-B76F-4BB2-9AEB-28F9BF991DF6@fluffy.co.uk> <4304E5E5.5040608@robshepherd.net> Message-ID: <1124397030.6556.78.camel@avenin.ebourne.me.uk> On Thu, 2005-08-18 at 20:47 +0100, Mr R G Shepherd wrote: > Ben Summers wrote: > > Well there we go. A veto. So SVN it is. :-) > > Grab a recent version of SVN, so you get a nice stable fsfs backend by default > instead of Berkeley-db. eurgh :) Sound advice indeed. While BDB has advantages, I think it's been well demonstrated that the fsfs backend is just better. Stick to svn 1.2 or later and it will use that by default. One day I'll get round to converting my remaining BDB repos to fsfs. One big advantage with fsfs is that you can use boxbackup to back it up directly, without needing to dump it to a file. Cheers, Martin. From boxbackup at fluffy.co.uk Fri Aug 19 06:39:09 2005 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Thu, 18 Aug 2005 22:39:09 -0700 Subject: [Box Backup] Future development plan In-Reply-To: <1124392181.6556.74.camel@avenin.ebourne.me.uk> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> <4304A70D.4050500@invis.net> <1124392181.6556.74.camel@avenin.ebourne.me.uk> Message-ID: <4305707D.2050605@reedtz.com> On 8/18/05 12:09 PM, Martin Ebourne wrote: >On Thu, 2005-08-18 at 18:13 +0100, Ben Summers wrote: > > >>Would anyone really object if Perforce is used? The branch and merge >>functionality looks rather neat. >> >> > >I don't run closed source software on any of my machines, so I >personally wouldn't use it. > >As to whether it's really a better solution I've never used Perforce so >can't help. But I've read some of the manual and a few comparison pages >and would offer the following. > > I haven't used SVN, but at a previous job, I used Perforce with great success. We were using cvs before switching to Perforce, and the difference in developer performance was tremendous. Branching and merging actually worked, as opposed to cvs. We had about 20 developers working on a 1.5MLOC system, and Perforce never really broke a sweat. Anyway, my $0.02 Thanks, Per -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Sat Aug 20 10:46:33 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sat, 20 Aug 2005 10:46:33 +0100 Subject: [Box Backup] Future development plan In-Reply-To: <4305707D.2050605@reedtz.com> References: <0C8DF0BD-A9B0-4EC0-AA9F-90EAE1BBEA7E@fluffy.co.uk> <4304A70D.4050500@invis.net> <1124392181.6556.74.camel@avenin.ebourne.me.uk> <4305707D.2050605@reedtz.com> Message-ID: I think we're almost there with a plan. I shall write up some notes on coding standards and how we're going to work over the next week, and then aim to get started shortly afterwards. Ben From boxbackup at fluffy.co.uk Mon Aug 22 20:11:42 2005 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 22 Aug 2005 20:11:42 +0100 (BST) Subject: [Box Backup] Long time since last release.... In-Reply-To: <1124213133.2905.63.camel@avenin.ebourne.me.uk> References: <43021621.6060702@syska.dk> <1124213133.2905.63.camel@avenin.ebourne.me.uk> Message-ID: Hi Ben, Martin and all, On Tue, 16 Aug 2005, Martin Ebourne wrote: > On Tue, 2005-08-16 at 17:43 +0100, Ben Summers wrote: >> I am considering using a CVS server on Sourceforge, importing the >> latest version, and then inviting the contributers to commit their >> changes. I'm not sure what to do about style and quality issues though. [...] > I'm sure that opening up some kind of repository with committer access > is the way to go though, that's what open source is all about. I would definitely second this, and suggest Have you considered having that you only give a few trusted developers commit rights, requiring them to scrutinise patches before committing them. I think that many projects with multiple developers work effectively this way. > This would be a good start, but I would prefer you used something a bit > better than CVS. Personally I have imported recent versions of box into > a local SVN repository and make all my mods in there, from which I > generate patches. Does sourceforge provide anything other than CVS these > days? Some of the other free hosting sites do. I don't think it really > matters which version control system you use, as long as it's recent, > they're all loads better than CVS. I think that Sourceforge would be a good choice, and although they currently only support CVS, I don't mind too much. It's rare that its limitations are a major problem, although they frequently annoy. :-) I had as many problems with Subversion as with CVS, including infinite repository growth and difficulty of pruning. On the other hand, it does have a nice Eclipse interface. Darcs looks like a good contender as well. Sourceforge apparently does intend to support Subversion: > Subversion Service: The research, analysis, and support gear-up needed > to implement a Subversion service at SourceForge.net is now in progress. > As with all SourceForge.net services, extensive analysis and testing > must be performed to verify suitable levels of stability and scalability > before a service can be rolled-out. > > We are expecting the initial phases of this effort to last several > weeks, to be followed by the implementation of a testing environment > which will be used for a live beta test by specific selected projects. > Pending successful scalability testing, service details will be > finalized and service will be offered to all projects. (Refreshed > 2005-04-21, to show continued in-progress status.) [https://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352] > Quite possibly. The thing I'd be most interested in writing would be to > add inotify support since it will be in the mainline Linux kernel soon. > This would let bbackupd be fed lists of changed files real time from the > kernel, and avoid the need to do disk scanning (which has sucked for at > least 20 years now :)). That's a great idea :-) I would also like to see similar support on Win32, and the BSDs, if possible. I'm sure the APIs exist, but I'm not very familiar with win32 development. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Thu Aug 25 20:48:31 2005 From: boxbackup at fluffy.co.uk (Alex Howansky) Date: Thu, 25 Aug 2005 14:48:31 -0500 (CDT) Subject: [Box Backup] monitoring bbackupd Message-ID: I've got BoxBackup clients running on about a dozen servers and I'm finding that bbackupd dies every once in a while on one or another of them. While I suppose that in itself is a bug, what I'm really looking for is a way to be able to tell (from a remote server) if that has happened. I've got an existing centralized monitoring system and I was hoping to avoid installing some other local monitoring system on each machine. Ideally, I'd like to be able to do a remote connect to bbackupd over a TCP/IP port, but seems that bbackupd uses sockets only. Any ideas? I suppose alternatively, that I could use daemontools to keep bbackupd running. Does anybody know offhand if fghack works ok in this case? Or is there maybe an undocumented switch on bbackupd to prevent it from backgrounding? Thanks, -- Alex Howansky Wankwood Associates http://wankwood.com/ From boxbackup at fluffy.co.uk Thu Aug 25 22:27:14 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Thu, 25 Aug 2005 22:27:14 +0100 Subject: [Box Backup] monitoring bbackupd In-Reply-To: References: Message-ID: <1125005235.22026.20.camel@avenin.ebourne.me.uk> On Thu, 2005-08-25 at 14:48 -0500, Alex Howansky wrote: > I've got BoxBackup clients running on about a dozen servers and I'm finding > that bbackupd dies every once in a while on one or another of them. While I > suppose that in itself is a bug, what I'm really looking for is a way to be > able to tell (from a remote server) if that has happened. I've got an existing > centralized monitoring system and I was hoping to avoid installing some other > local monitoring system on each machine. Ideally, I'd like to be able to do a > remote connect to bbackupd over a TCP/IP port, but seems that bbackupd uses > sockets only. Any ideas? I actually use nagios on my machines. I've got a script I wrote for it that restarts any service and it can check remote machines by use of nagios-nrpe. Don't ever remember the clients dying though. > I suppose alternatively, that I could use daemontools to keep bbackupd running. > Does anybody know offhand if fghack works ok in this case? Or is there maybe an > undocumented switch on bbackupd to prevent it from backgrounding? You can give it SINGLEPROCESS as the first parameter (look in the self tests). It's possible that may have other side effects I'm unaware of though. Cheers, Martin. From boxbackup at fluffy.co.uk Thu Aug 25 23:49:26 2005 From: boxbackup at fluffy.co.uk (Scott McNee) Date: Fri, 26 Aug 2005 08:49:26 +1000 Subject: [Box Backup] monitoring bbackupd In-Reply-To: <1125005235.22026.20.camel@avenin.ebourne.me.uk> Message-ID: <000901c5a9c7$42758030$6501a8c0@SCOTTLAPTOP> Hi Martin, Any chance of saving some work and getting a copy of the script? Thanks. Scott McNee =20 -----Original Message----- From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] = On Behalf Of Martin Ebourne Sent: Friday, 26 August 2005 7:27 AM To: boxbackup at fluffy.co.uk Subject: Re: [Box Backup] monitoring bbackupd On Thu, 2005-08-25 at 14:48 -0500, Alex Howansky wrote: > I've got BoxBackup clients running on about a dozen servers and I'm=20 > finding that bbackupd dies every once in a while on one or another of=20 > them. While I suppose that in itself is a bug, what I'm really looking = > for is a way to be able to tell (from a remote server) if that has=20 > happened. I've got an existing centralized monitoring system and I was = > hoping to avoid installing some other local monitoring system on each=20 > machine. Ideally, I'd like to be able to do a remote connect to=20 > bbackupd over a TCP/IP port, but seems that bbackupd uses sockets=20 > only. Any ideas? I actually use nagios on my machines. I've got a script I wrote for it = that restarts any service and it can check remote machines by use of = nagios-nrpe. Don't ever remember the clients dying though. > I suppose alternatively, that I could use daemontools to keep bbackupd = > running. Does anybody know offhand if fghack works ok in this case? Or = > is there maybe an undocumented switch on bbackupd to prevent it from=20 > backgrounding? You can give it SINGLEPROCESS as the first parameter (look in the self tests). It's possible that may have other side effects I'm unaware of though. Cheers, Martin. _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Fri Aug 26 00:31:47 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Fri, 26 Aug 2005 00:31:47 +0100 Subject: [Box Backup] monitoring bbackupd In-Reply-To: <000901c5a9c7$42758030$6501a8c0@SCOTTLAPTOP> References: <000901c5a9c7$42758030$6501a8c0@SCOTTLAPTOP> Message-ID: <1125012707.22026.33.camel@avenin.ebourne.me.uk> --=-AXj9aJ6skXtDXjouqBsg Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-08-26 at 08:49 +1000, Scott McNee wrote: > Hi Martin, > Any chance of saving some work and getting a copy of the > script? I put restart_service (attached) in /etc/nagios/eventhandlers. It's a generic service restart script, so can be used for anything including bbstored and bbackupd. In misccommands.cfg I have: define command { command_name restart_service command_line $USER6$/restart_service "$SERVICESTATE$" "$STATETYPE$" "$SERVICEATTEMPT$" "$SERVICEDESC$" >> /var/log/nagios/event_handler.log 2>&1 } You'll need to make sure $USER6$ is set for the restart_service script location, or hard-code it. I then have the following in services.cfg: define service { use generic-service host_name hordein service_description bbackupd check_command check_service!bbackupd event_handler restart_service } define service { use generic-service host_name hordein service_description bbstored check_command check_service!bbstored event_handler restart_service } You'll need a suitable generic-service set up. If you want to get a central machine to monitor remote ones then use the same script on the remote machine and set up nrpe. If you need help with that then I think the nagios lists would be more appropriate. One day I'll write one that uses bbackupquery to log in and check the store out, free space etc. This is all on Fedora Core. YMMV. Cheers, Martin. --=-AXj9aJ6skXtDXjouqBsg Content-Disposition: attachment; filename=restart_service Content-Type: application/x-shellscript; name=restart_service Content-Transfer-Encoding: 7bit #!/bin/sh # # Event handler script for restarting unix services on the local machine state="$1" failure="$2" attempt="$3" service="$4" # What state is the service in? case "$state" in OK) # The service just came back up, so don't do anything... ;; WARNING) # We don't really care about warning states, since the service is probably still running... ;; UNKNOWN) # We don't know what might be causing an unknown error, so don't do anything... ;; CRITICAL) # Is this a "soft" or a "hard" state? case "$failure" in SOFT) # What check attempt are we on? case "$attempt" in 2) echo "Restarting $service service (2nd soft critical state)..." /usr/bin/sudo /sbin/service $service restart ;; esac ;; HARD) echo "Restarting $service service..." # Call the init script to restart the server /usr/bin/sudo /sbin/service $service restart ;; esac ;; esac exit 0 --=-AXj9aJ6skXtDXjouqBsg-- From boxbackup at fluffy.co.uk Fri Aug 26 00:34:33 2005 From: boxbackup at fluffy.co.uk (Scott McNee) Date: Fri, 26 Aug 2005 09:34:33 +1000 Subject: [Box Backup] monitoring bbackupd In-Reply-To: <1125012707.22026.33.camel@avenin.ebourne.me.uk> Message-ID: <000e01c5a9cd$8f119090$6501a8c0@SCOTTLAPTOP> Thankyou. Scott McNee =20 -----Original Message----- From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] = On Behalf Of Martin Ebourne Sent: Friday, 26 August 2005 9:32 AM To: boxbackup at fluffy.co.uk Subject: RE: [Box Backup] monitoring bbackupd On Fri, 2005-08-26 at 08:49 +1000, Scott McNee wrote: > Hi Martin, > Any chance of saving some work and getting a copy of the script? I put restart_service (attached) in /etc/nagios/eventhandlers. It's a generic service restart script, so can be used for anything including bbstored and bbackupd. In misccommands.cfg I have: define command { command_name restart_service command_line $USER6$/restart_service "$SERVICESTATE$" "$STATETYPE$" "$SERVICEATTEMPT$" "$SERVICEDESC$" >> /var/log/nagios/event_handler.log = 2>&1 } You'll need to make sure $USER6$ is set for the restart_service script location, or hard-code it. I then have the following in services.cfg: define service { use generic-service host_name hordein service_description bbackupd check_command check_service!bbackupd event_handler restart_service } define service { use generic-service host_name hordein service_description bbstored check_command check_service!bbstored event_handler restart_service } You'll need a suitable generic-service set up. If you want to get a central machine to monitor remote ones then use the same script on the remote machine and set up nrpe. If you need help with that then I think the nagios lists would be more appropriate. One day I'll write one that uses bbackupquery to log in and check the = store out, free space etc. This is all on Fedora Core. YMMV. Cheers, Martin. From boxbackup at fluffy.co.uk Sun Aug 28 00:44:33 2005 From: boxbackup at fluffy.co.uk (dm) Date: Sat, 27 Aug 2005 18:44:33 -0500 Subject: [Box Backup] monitoring bbackupd In-Reply-To: References: Message-ID: <4310FAE1.4090700@amarillowireless.net> Alex Howansky wrote: >I've got BoxBackup clients running on about a dozen servers and I'm finding >that bbackupd dies every once in a while on one or another of them. While I >suppose that in itself is a bug, what I'm really looking for is a way to be >able to tell (from a remote server) if that has happened. I've got an existing >centralized monitoring system and I was hoping to avoid installing some other >local monitoring system on each machine. Ideally, I'd like to be able to do a >remote connect to bbackupd over a TCP/IP port, but seems that bbackupd uses >sockets only. Any ideas? > >I suppose alternatively, that I could use daemontools to keep bbackupd running. >Does anybody know offhand if fghack works ok in this case? Or is there maybe an >undocumented switch on bbackupd to prevent it from backgrounding? > >Thanks, > > > Just one suggestion.. You could enable SNMP and query the following community string. This seems to work with both windows and linux SNMP daemons(of course, they have to be configured to allow this information to be sent). If you are on a closed network, then this would probably be fine, but on the internet you'd probably want to tunnel through a secure connection. HOST-RESOURCES-MIB::hrSWRunName = OID .1.3.6.1.2.1.25.4.2.1.2.$PID snmpwalk -c community hrSWRunName | egrep "bbackupd|bbstored" or (if you don't have MIB definitions installed) snmpwalk -c community .1.3.6.1.2.1.25.4.2.1.2 | egrep "bbackupd|bbstored" Windows client output HOST-RESOURCES-MIB::hrSWRunName.3100 = STRING: "bbackupd.exe" boxbackup linux client output HOST-RESOURCES-MIB::hrSWRunName.4639 = STRING: "bbackupd" boxbackup linux server output HOST-RESOURCES-MIB::hrSWRunName.1718 = STRING: "bbstored" HOST-RESOURCES-MIB::hrSWRunName.1721 = STRING: "bbstored" HOST-RESOURCES-MIB::hrSWRunName.31881 = STRING: "bbstored" In the long run, it would probably be better to have an agent installed that attempts to restart things on its own, and if failure occurs, should also be capable of reporting back to a central location securely. BTW, It might not be a bad idea to enable bbstored and bbackupd to send SNMP Traps to a centralized monitoring server based on specific configurable events? This would make it more managable in larger configurations, and it could much more easily integrated into many monitoring solutions. dm From boxbackup at fluffy.co.uk Mon Aug 29 19:39:38 2005 From: boxbackup at fluffy.co.uk (Mikael Syska) Date: Mon, 29 Aug 2005 20:39:38 +0200 Subject: [Box Backup] Win32 Client State Message-ID: <4313566A.3070701@syska.dk> Hey, What are the state of the win32 client(s)? Are there any news or work-in-progress information for the public boxbackup users? Getting more and more afraid of loosing data from my win32 workstation.... so wanting to start backup up some of the data soon..... Are there only Nick's win32 port or are there others out there? // ouT From boxbackup at fluffy.co.uk Wed Aug 31 11:05:43 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Wed, 31 Aug 2005 11:05:43 +0100 Subject: [Box Backup] Coding standards Message-ID: <932219F4-3E93-46D8-8B02-86553432530D@fluffy.co.uk> In preparation for getting the code up for others to work on, I've written some notes on coding standards. I hope this documents the style and preferences to date, and that I haven't forgotten anything. I think that consistency is important, and since the code base is quite large, we should stick to the existing "standards" regardless of whether something else is "better". I don't think anything below should place an intolerable burden on anyone. So, are they OK? Ben The coding style should be fairly easy to pick up when looking at the source files. But here are some pointers: Indent with tabs, with 4 character tab stops. Bracing style: if(condition) { } Use braces, even if it's a single statement. Prefer references to pointers. Function(), if(), switch(), etc... no space before the brackets. Variable names are prefixed with m (class member), p (pointer), r (reference) in that order. Arguments to functions are capitalised (ArgumentToFunction, rArgumentToFunction), local variables aren't (localVariable). Member variables are caplitalised too, but always start with m. Classes are ClassName (with no prefix), and member functions are FunctionName(). Code lives in .cpp and .h files with the same name as the class. Non-member function calls are prefixed with ::, eg ::printf(...). Exceptions are used. All are autogenerated, and thrown with the THROW_EXCEPTION macro. Except for std::bad_alloc, which is thrown when memory allocations failed. Objects are allocated on the stack whereever possible to ease exception handling. No overloading of operators, especially not for i/o. Only exception is comparison operators, but even then, only if really justified. (Justification: it's not obvious what an operator will do!) Use the STL wherever useful, but don't use the STL style! If a function returns a newly allocated object, use an std::auto_ptr<> to return it. Code is split up into logical groups in the lib/* directories, although the use of these is minimised. #include "Box.h" must be the first include in every cpp file. On some platforms, failing to do this absolutely first will cause the compiled code to crash due to inconsistent options. There is no global base class. Serialisation is done using two functions: void ReadFromStream(IOStream &rStream, int Timeout); void WriteToStream(IOStream &rStream) const; Serialisable objects are not derived from any particular base class as it doesn't seem necessary. Templates can be used if generic code is necessary. All serialised objects use network byte order. From boxbackup at fluffy.co.uk Wed Aug 31 11:24:30 2005 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Wed, 31 Aug 2005 11:24:30 +0100 Subject: [Box Backup] Coding standards In-Reply-To: <932219F4-3E93-46D8-8B02-86553432530D@fluffy.co.uk> References: <932219F4-3E93-46D8-8B02-86553432530D@fluffy.co.uk> Message-ID: <20050831112430.sbbsx128bosss08k@ebourne.me.uk> Ben Summers wrote: > So, are they OK? Looks ok to me, just a couple of points below. > Non-member function calls are prefixed with ::, eg ::printf(...). The scoping operator should be used where correct and appropriate. eg. printf is in and is part of the std namespace, so it should be std::printf. execve is in and is not in a namespace, so it should be ::execve. I think it is often useful to put 'using namespace std;' in .cpp files (but never in .h files), to make the code more readable. > Use the STL wherever useful, but don't use the STL style! How do you define 'STL style'? Cheers, Martin. From boxbackup at fluffy.co.uk Wed Aug 31 11:43:57 2005 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Wed, 31 Aug 2005 11:43:57 +0100 Subject: [Box Backup] Coding standards In-Reply-To: <20050831112430.sbbsx128bosss08k@ebourne.me.uk> References: <932219F4-3E93-46D8-8B02-86553432530D@fluffy.co.uk> <20050831112430.sbbsx128bosss08k@ebourne.me.uk> Message-ID: On 31 Aug 2005, at 11:24, Martin Ebourne wrote: > Ben Summers wrote: > >> So, are they OK? >> > > Looks ok to me, just a couple of points below. > > >> Non-member function calls are prefixed with ::, eg ::printf(...). >> > > The scoping operator should be used where correct and appropriate. The intention for this is to clearly show non-class functions, and to reduce ambiguity. > > eg. > printf is in and is part of the std namespace, so it > should be std::printf. > execve is in and is not in a namespace, so it should > be ::execve. > > I think it is often useful to put 'using namespace std;' in .cpp > files (but never in .h files), to make the code more readable. Ah, there we differ. I always use explicit std:: namespacing. > > >> Use the STL wherever useful, but don't use the STL style! >> > > How do you define 'STL style'? Lower case with underscore separators, eg const_iterator not ConstIterator. Ben