Bug#1074437: RFS: sitecopy/1:0.16.6-13 [QA] [RC] -- program for managing a WWW site via FTP, SFTP, DAV or HTTP

[Phil Wyett]

On Sun, 2024-06-30 at 15:21 +0800, Bo YU wrote:
> Hi,
> 
> It seems pere has uploaded it to unstable[0], so these issues will be
> addressed by the next upload maybe.
> 
> Thanks all.
> 
> BR,
> Bo
> 
> [0]: 
> https://tracker.debian.org/news/1540507/accepted-sitecopy-10166-13-source-into-unstable/
> 

Morning Bo and all,

While attention during this trip through mentors would have been ideal, I am 
sure that you will
address things raised during a future upload. Your continued efforts on these 
orphaned and neglected
packages is amazing and appreciated by myself and many many others.

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


signature.asc
Description: This is a digitally signed message part

Bug#1074437: RFS: sitecopy/1:0.16.6-13 [QA] [RC] -- program for managing a WWW site via FTP, SFTP, DAV or HTTP

[Bo YU]

Hi,

It seems pere has uploaded it to unstable[0], so these issues will be
addressed by the next upload maybe.

Thanks all.

BR,
Bo

[0]: 
https://tracker.debian.org/news/1540507/accepted-sitecopy-10166-13-source-into-unstable/

Bug#1074437: RFS: sitecopy/1:0.16.6-13 [QA] [RC] -- program for managing a WWW site via FTP, SFTP, DAV or HTTP

[Leandro Cunha]

On Fri, Jun 28, 2024 at 12:36 PM Phil Wyett  wrote:
>
> Hi Bo,
>
> Preamble...
>
> Thanks for taking time to create this package and your contribution to Debian.
>
> The below review is for assistance. It is offered to help submitters of
> packages to Debian mentors improve their packages prior to possible
> sponsorship into Debian. There is no obligation on behalf of the subitter to
> make any alterations based upon information provided in the review.
>
> Review...
>
> 1. Build: Good
>
> 2. Lintian: Warnings / Information
>
> I: sitecopy source: quilt-patch-missing-description 
> [debian/patches/32_neon-0.31.patch]
>
> A description for the patch would probably be beneficial.
>
> I: sitecopy: hardening-no-bindnow [usr/bin/sitecopy]
> N:
> N:   This package provides an ELF binary that lacks the "bindnow" linker flag.
> N:
> N:   This is needed (together with "relro") to make the "Global Offset Table"
> N:   (GOT) fully read-only. The bindnow feature trades startup time for
> N:   improved security. Please consider enabling this feature or consider
> N:   overriding the tag (possibly with a comment about why).
> N:
> N:   If you use dpkg-buildflags, you may have to add hardening=+bindnow or
> N:   hardening=+all to DEB_BUILD_MAINT_OPTIONS.
> N:
> N:   The relevant compiler flags are set in LDFLAGS.
> N:
> N:   Please refer to https://wiki.debian.org/Hardening for details.
> N:
> N:   Visibility: info
> N:   Show-Always: no
> N:   Check: binaries/hardening
>
> I would be quite tempted to fix this with the addition of the below line near 
> the top of
> 'debian/rules' even though it is a QA upload. I would ask others opinion 
> though as they may feel it
> is not within the scope of a QA upload.
>
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
>

This report can be resolved using the links below. Hope this helps.
https://wiki.debian.org/Hardening
https://wiki.debian.org/HardeningWalkthrough

Quality control is good to always resolve any package issues when possible.

-- 
Cheers,
Leandro Cunha

Bug#1074437: RFS: sitecopy/1:0.16.6-13 [QA] [RC] -- program for managing a WWW site via FTP, SFTP, DAV or HTTP

[Phil Wyett]

Hi Bo,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Warnings / Information

I: sitecopy source: quilt-patch-missing-description 
[debian/patches/32_neon-0.31.patch]

A description for the patch would probably be beneficial.

I: sitecopy: hardening-no-bindnow [usr/bin/sitecopy]
N: 
N:   This package provides an ELF binary that lacks the "bindnow" linker flag.
N:   
N:   This is needed (together with "relro") to make the "Global Offset Table"
N:   (GOT) fully read-only. The bindnow feature trades startup time for
N:   improved security. Please consider enabling this feature or consider
N:   overriding the tag (possibly with a comment about why).
N:   
N:   If you use dpkg-buildflags, you may have to add hardening=+bindnow or
N:   hardening=+all to DEB_BUILD_MAINT_OPTIONS.
N:   
N:   The relevant compiler flags are set in LDFLAGS.
N: 
N:   Please refer to https://wiki.debian.org/Hardening for details.
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: binaries/hardening

I would be quite tempted to fix this with the addition of the below line near 
the top of
'debian/rules' even though it is a QA upload. I would ask others opinion though 
as they may feel it
is not within the scope of a QA upload.

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

3. Licenses: QA upload - Latitude given :-)

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Install (No previous installs): Good

6. Upgrade (Over previous installs if any): Good

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


signature.asc
Description: This is a digitally signed message part

Re: RFS: sitecopy

[Geert Stappers]

( please honour the explicite set 'Reply-To:' )

Hello Release Team,

The text below is from [EMAIL PROTECTED]
about a Request For Sponsoring.

My questions are at the bottom.


On Wed, Apr 27, 2005 at 08:25:11AM -0500, Reed Snellenberger wrote:
> Geert Stappers wrote:
> >On Tue, Apr 26, 2005 at 09:27:06PM -0500,
> >Reed Snellenberger wrote, in some odd order:
> > 
> >>Philipp Kern wrote:
> >>
> >>>On 23 Apr 2005, at 05:45, Reed Snellenberger wrote:
> >>>
> Files are available at:
> http://home.houston.rr.com/snellenberger/debian/sitecopy/
> 
> >>>Do you know why there is an outdated debian/ subdirectory in the 
> >>>upstream tarball?
> >>>And if the current version of sitecopy does not work with the old 
> >>>xsitecopy I would suggest a ``Conflicts: xsitecopy'' instead of the 
> >>>versioned one.
> >>>
> >>Philipp:
> >>
> >>Following up on my earlier post, upstream has asked "what do you want me 
> >>to do about that old debian directory?", and I asked him to remove it.  
> >>Although it's still in place for the 0.15.1 version that he released on 
> >>Sunday (May 24), it'll be gone from subsequent releases.
> >
> >Please reply below the text
> >
> Sorry about that... I didn't want this century to have gone by without 
> having top-posted at least once :-(
> 
> >What I missed in this thread
> >
> >$ apt-cache show sitecopy
> >Package: sitecopy
> >Priority: extra
> >Section: web
> >Installed-Size: 456
> >Maintainer: Masayuki Hatta <[EMAIL PROTECTED]>
> >Architecture: i386
> >Version: 1:0.11.4-6
> >Depends: libc6 (>= 2.3.1-1), libssl0.9.7, libxml2 (>= 2.5.0-1), zlib1g (>= 
> >1:1.1.4)
> >Suggests: xsitecopy
> >Conflicts: xsitecopy (<< 1:0.10.15-1)
> >Filename: pool/main/s/sitecopy/sitecopy_0.11.4-6_i386.deb
> >Size: 172196
> >MD5sum: 72e13e31b1ed7de8a0644bdb46a83811
> >Description: A program for managing a WWW site via FTP, DAV or HTTP
> >sitecopy is for copying locally stored websites to remote ftp servers.
> >With a single command, the program will synchronize a set of local files
> >to a remote server by performing uploads and remote deletes as required.
> >The aim is to remove the hassle of uploading and deleting individual files
> >using an FTP client.  sitecopy will also optionally try to spot files you
> >move locally, and move them remotely.
> >.
> >sitecopy is designed to not care about what is actually on the remote
> >server - it simply keeps a record of what it THINKS is in on the remote
> >server, and works from that.
> >
> >Is this Request For Sponsor about _duplicate_ work?
> >
> No -- I've taken over maintainership from Masayuki (1), and the original 
> RFS (2) was for the then-current version of sitecopy (0.15.0). 
> 
> I've since packaged upstream's 0.15.1 release from last Sunday and 
> replaced the "older" 0.15.0 deb on my storage site (3).  So... if anyone 
> decides to sponsor the upload, it'll would be for sitecopy_0.15.1-1, not 
> sitecopy_0.15.0-1 as originally RFS'd.
> 
> (1) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294991
> (2) http://lists.debian.org/debian-mentors/2005/04/msg00296.html
> (3) http://home.houston.rr.com/snellenberger/debian/sitecopy/
> 
> -- 
> Reed Snellenberger  
> GPG KeyID: 5A978843  
> rsnellenberger-at-houston.rr.com

I'm considering sponsoring it.

Does it make sense doing this during the freeze?
If yes: Should I do (after package checking) more then `dupload`?


Cheers
Geert Stappers



signature.asc
Description: Digital signature

RFS: sitecopy: A program for managing a WWW site via FTP, DAV or HTTP

[Reed Snellenberger]

I'd like to request a sponsor for sitecopy 1:0.15.1-1.
Files are available at:
  http://home.houston.rr.com/snellenberger/debian/sitecopy/
Since my last (4/22) request for a sponsor, upstream has released an new
minor version and I have incorporated that into this release.  Since
0.15.0-1 wasn't uploaded, I have merged the changelogs to make certain
that all referenced bugs are marked closed properly.
Reed
Package: sitecopy
Maintainer: Reed Snellenberger <[EMAIL PROTECTED]>
Description: A program for managing a WWW site via FTP, DAV or HTTP
sitecopy is for copying locally stored websites to remote ftp servers.
With a single command, the program will synchronize a set of local files
to a remote server by performing uploads and remote deletes as required.
The aim is to remove the hassle of uploading and deleting individual 
files using an FTP client. sitecopy will also optionally try to spot 
files you move locally, and move them remotely.

Sitecopy is designed to not care about what is actually on the remote
server - it simply keeps a record of what it THINKS is in on the remote
server, and works from that.
Changes (since last debian upload):
 sitecopy (1:0.15.1-1) unstable; urgency=low
 .
   * New maintainer (closes: #294991)
   * New upstream release (closes: #181949, #198307, #285249, #207546,
 #285249)
   * Removed xsitecopy build from control & debian/rules (obsolete 
upstream, confirmed with upstream author)
   * Removed --disable-debug flag from build to allow client-level
 debugging (closes: #185624)
   * Added man description of SSL configuration (closes: #228643)
   * Upstream release handles spaces in file & directory names (closes:
 #285722)

--
Reed Snellenberger
GPG KeyID: 5A978843
rsnellenberger-at-houston.rr.com

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: sitecopy

[Reed Snellenberger]

Geert Stappers wrote:
On Tue, Apr 26, 2005 at 09:27:06PM -0500,
Reed Snellenberger wrote, in some odd order:
 

Philipp Kern wrote:
   

On 23 Apr 2005, at 05:45, Reed Snellenberger wrote:
 

Files are available at:
http://home.houston.rr.com/snellenberger/debian/sitecopy/
   

Do you know why there is an outdated debian/ subdirectory in the 
upstream tarball?
And if the current version of sitecopy does not work with the old 
xsitecopy I would suggest a ``Conflicts: xsitecopy'' instead of the 
versioned one.
 

Philipp:
Following up on my earlier post, upstream has asked "what do you want me 
to do about that old debian directory?", and I asked him to remove it.  
Although it's still in place for the 0.15.1 version that he released on 
Sunday (May 24), it'll be gone from subsequent releases.
   

Please reply below the text
 

Sorry about that... I didn't want this century to have gone by without 
having top-posted at least once :-(

What I missed in this thread
$ apt-cache show sitecopy
Package: sitecopy
Priority: extra
Section: web
Installed-Size: 456
Maintainer: Masayuki Hatta <[EMAIL PROTECTED]>
Architecture: i386
Version: 1:0.11.4-6
Depends: libc6 (>= 2.3.1-1), libssl0.9.7, libxml2 (>= 2.5.0-1), zlib1g (>= 
1:1.1.4)
Suggests: xsitecopy
Conflicts: xsitecopy (<< 1:0.10.15-1)
Filename: pool/main/s/sitecopy/sitecopy_0.11.4-6_i386.deb
Size: 172196
MD5sum: 72e13e31b1ed7de8a0644bdb46a83811
Description: A program for managing a WWW site via FTP, DAV or HTTP
sitecopy is for copying locally stored websites to remote ftp servers.
With a single command, the program will synchronize a set of local files
to a remote server by performing uploads and remote deletes as required.
The aim is to remove the hassle of uploading and deleting individual files
using an FTP client.  sitecopy will also optionally try to spot files you
move locally, and move them remotely.
.
sitecopy is designed to not care about what is actually on the remote
server - it simply keeps a record of what it THINKS is in on the remote
server, and works from that.

Is this Request For Sponsor about _duplicate_ work?
 

No -- I've taken over maintainership from Masayuki (1), and the original 
RFS (2) was for the then-current version of sitecopy (0.15.0). 

I've since packaged upstream's 0.15.1 release from last Sunday and 
replaced the "older" 0.15.0 deb on my storage site (3).  So... if anyone 
decides to sponsor the upload, it'll would be for sitecopy_0.15.1-1, not 
sitecopy_0.15.0-1 as originally RFS'd.

(1) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294991
(2) http://lists.debian.org/debian-mentors/2005/04/msg00296.html
(3) http://home.houston.rr.com/snellenberger/debian/sitecopy/
--
Reed Snellenberger  
GPG KeyID: 5A978843  
rsnellenberger-at-houston.rr.com


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: sitecopy

[Geert Stappers]

On Tue, Apr 26, 2005 at 09:27:06PM -0500,
Reed Snellenberger wrote, in some odd order:
> Philipp Kern wrote:
> 
> >On 23 Apr 2005, at 05:45, Reed Snellenberger wrote:
> >
> >>Files are available at:
> >>  http://home.houston.rr.com/snellenberger/debian/sitecopy/
> >
> >
> >Do you know why there is an outdated debian/ subdirectory in the 
> >upstream tarball?
> >And if the current version of sitecopy does not work with the old 
> >xsitecopy I would suggest a ``Conflicts: xsitecopy'' instead of the 
> >versioned one.
>
> Philipp:
> 
> Following up on my earlier post, upstream has asked "what do you want me 
> to do about that old debian directory?", and I asked him to remove it.  
> Although it's still in place for the 0.15.1 version that he released on 
> Sunday (May 24), it'll be gone from subsequent releases.

Please reply below the text


What I missed in this thread

$ apt-cache show sitecopy
Package: sitecopy
Priority: extra
Section: web
Installed-Size: 456
Maintainer: Masayuki Hatta <[EMAIL PROTECTED]>
Architecture: i386
Version: 1:0.11.4-6
Depends: libc6 (>= 2.3.1-1), libssl0.9.7, libxml2 (>= 2.5.0-1), zlib1g (>= 
1:1.1.4)
Suggests: xsitecopy
Conflicts: xsitecopy (<< 1:0.10.15-1)
Filename: pool/main/s/sitecopy/sitecopy_0.11.4-6_i386.deb
Size: 172196
MD5sum: 72e13e31b1ed7de8a0644bdb46a83811
Description: A program for managing a WWW site via FTP, DAV or HTTP
 sitecopy is for copying locally stored websites to remote ftp servers.
 With a single command, the program will synchronize a set of local files
 to a remote server by performing uploads and remote deletes as required.
 The aim is to remove the hassle of uploading and deleting individual files
 using an FTP client.  sitecopy will also optionally try to spot files you
 move locally, and move them remotely.
 .
 sitecopy is designed to not care about what is actually on the remote
 server - it simply keeps a record of what it THINKS is in on the remote
 server, and works from that.



Is this Request For Sponsor about _duplicate_ work?


Cheers
Geert Stappers



signature.asc
Description: Digital signature

Re: RFS: sitecopy

[Reed Snellenberger]

Philipp:
Following up on my earlier post, upstream has asked "what do you want me 
to do about that old debian directory?", and I asked him to remove it.  
Although it's still in place for the 0.15.1 version that he released on 
Sunday (May 24), it'll be gone from subsequent releases.

Reed
Philipp Kern wrote:
On 23 Apr 2005, at 05:45, Reed Snellenberger wrote:
Files are available at:
  http://home.houston.rr.com/snellenberger/debian/sitecopy/

Do you know why there is an outdated debian/ subdirectory in the 
upstream tarball?
And if the current version of sitecopy does not work with the old 
xsitecopy I would suggest a ``Conflicts: xsitecopy'' instead of the 
versioned one.

Kind regards,
Philipp Kern
Debian Developer

--
Reed Snellenberger  
GPG KeyID: 5A978843  
rsnellenberger-at-houston.rr.com


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: sitecopy

[Reed Snellenberger]

Interesting... is this (flagging source packages who "lose" a binary 
package) an automatic process in the Debian back-end system, or 
something that would only be initiated at the request of the package's 
maintainer? 

Reed
Florian Ernst wrote:
Hello *,
On Sun, Apr 24, 2005 at 01:01:52AM +0200, Philipp Kern wrote:
 

On 23 Apr 2005, at 16:32, Reed Snellenberger wrote:
   

3) as an interim step, possibly ask ftp-masters to remove the existing 
(semi-broken) xsitecopy-0.11.4-6 package (still undecided about that)
 

I don't know really what our archive maintenance ladies do if they lose 
a binary package from a source package. Perhaps someone else could 
comment on this.
   

They'd ask melanie to take over, please see
 and the dak source at
cvs.debian.org.
Cheers,
Flo
 

--
Reed Snellenberger  
GPG KeyID: 5A978843  
rsnellenberger-at-houston.rr.com


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: sitecopy

[Reed Snellenberger]

Florian Ernst wrote:
Did you contact upstream about this already? Are there really any
plans to bring xsitecopy back?
 

Yes, I have.  He says he's done some work on the Gnome 2.x version, but 
didn't finish it.  It's in his "If I ever get time..." queue at the moment.

FWIW, he agreed with the notion of getting the console version out now 
rather than waiting for a new xsitecopy.

--
Reed Snellenberger  
GPG KeyID: 5A978843  
rsnellenberger-at-houston.rr.com


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: sitecopy

[Florian Ernst]

Hello *,

On Sat, Apr 23, 2005 at 09:32:14AM -0500, Reed Snellenberger wrote:
> 4) After this release goes out, begin working with the upstream to try 
> and get a new xsitecopy that could be added back to the sitecopy source 
> package for some subsequent release. 

Did you contact upstream about this already? Are there really any
plans to bring xsitecopy back?

Cheers,
Flo


signature.asc
Description: Digital signature

Re: RFS: sitecopy

[Florian Ernst]

Hello *,

On Sun, Apr 24, 2005 at 01:01:52AM +0200, Philipp Kern wrote:
> On 23 Apr 2005, at 16:32, Reed Snellenberger wrote:
> >3) as an interim step, possibly ask ftp-masters to remove the existing 
> >(semi-broken) xsitecopy-0.11.4-6 package (still undecided about that)
> 
> I don't know really what our archive maintenance ladies do if they lose 
> a binary package from a source package. Perhaps someone else could 
> comment on this.

They'd ask melanie to take over, please see
 and the dak source at
cvs.debian.org.

Cheers,
Flo


signature.asc
Description: Digital signature

Re: RFS: sitecopy

[Philipp Kern]

On 23 Apr 2005, at 16:32, Reed Snellenberger wrote:
2) leave the existing Conflicts: in place as-is, because it suggested 
an actual conflict with the earlier version of xsitecopy.
My question was more like this: Is the current xsitecopy in Debian 
incompatible with the new one? If so please conflict, if not you did 
the right thing. I was just wondering about it.

3) as an interim step, possibly ask ftp-masters to remove the existing 
(semi-broken) xsitecopy-0.11.4-6 package (still undecided about that)
I don't know really what our archive maintenance ladies do if they lose 
a binary package from a source package. Perhaps someone else could 
comment on this.

Comments on this strategy would be appreciated ;-)
Looks ok to me.
Kind regards,
Philipp Kern


PGP.sig
Description: This is a digitally signed message part

Re: RFS: sitecopy

[Reed Snellenberger]

Philipp Kern wrote:
Do you know why there is an outdated debian/ subdirectory in the 
upstream tarball?
For this release, it's just the way the upstream developer put it 
together :-) -- it's outdated because the last time it was touched by a 
debian maintainer was for the 0.11.4 upstream release.  My thoughts on 
this were to get this release out, then ask upstream to either remove 
the debian directory altogether (using arguments from the earlier 
discussion in -mentors; thanks all!) or to at least synch it back up. 

And if the current version of sitecopy does not work with the old 
xsitecopy I would suggest a ``Conflicts: xsitecopy'' instead of the 
versioned one.
The actual problem here is that xsitecopy is a Gnome 1.x application 
that hasn't been ported to 2.x (and can't be built on a 2.x system).  
There are some bugs against xsitecopy that reflect this (155009, 
208510).  The upstream developer has worked a little bit on a 2.x 
update, but has no definite plans to finish the work. 

Given that background, my approach to taking up maintenance of the 
package was:

1) get a 0.15.0 release of sitecopy (console version) out by eliminating 
the xsitecopy targets from debian/rules (otherwise, it would be FTBFS).
2) leave the existing Conflicts: in place as-is, because it suggested an 
actual conflict with the earlier version of xsitecopy.
3) as an interim step, possibly ask ftp-masters to remove the existing 
(semi-broken) xsitecopy-0.11.4-6 package (still undecided about that)
4) After this release goes out, begin working with the upstream to try 
and get a new xsitecopy that could be added back to the sitecopy source 
package for some subsequent release. 

Comments on this strategy would be appreciated ;-)
--
Reed Snellenberger  
GPG KeyID: 5A978843  
rsnellenberger-at-houston.rr.com


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: sitecopy

[Philipp Kern]

On 23 Apr 2005, at 05:45, Reed Snellenberger wrote:
Files are available at:
  http://home.houston.rr.com/snellenberger/debian/sitecopy/
Do you know why there is an outdated debian/ subdirectory in the 
upstream tarball?
And if the current version of sitecopy does not work with the old 
xsitecopy I would suggest a ``Conflicts: xsitecopy'' instead of the 
versioned one.

Kind regards,
Philipp Kern
Debian Developer


PGP.sig
Description: This is a digitally signed message part

Re: RFS: sitecopy

[Jan Wagemakers]

Reed Snellenberger <[EMAIL PROTECTED]> schreef:

> I'd like to request a sponsor for sitecopy 1:0.15.0-1.
> Files are available at:
>   http://home.houston.rr.com/snellenberger/debian/sitecopy/
> Package: sitecopy

I make use of sitecopy and have just upgraded to your new package. It works 
without a problem. Thanks! :-)

I really hope that you can find a sponsor for this package.


-- 
Met vriendelijke groetjes - Jan Wagemakers -

 - Debian GNU/Linux 3.1 - Up : 115 days 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFS: sitecopy

[Reed Snellenberger]

I'd like to request a sponsor for sitecopy 1:0.15.0-1.

Files are available at:
  http://home.houston.rr.com/snellenberger/debian/sitecopy/

Package: sitecopy
Maintainer: Reed Snellenberger <[EMAIL PROTECTED]>

Description: A program for managing a WWW site via FTP, DAV or HTTP
 sitecopy is for copying locally stored websites to remote ftp servers.  
 With a single command, the program will synchronize a set of local files
 to a remote server by performing uploads and remote deletes as required.
 The aim is to remove the hassle of uploading and deleting individual files 
 using an FTP client.  sitecopy will also optionally try to spot files you 
 move locally, and move them remotely.
  
 Sitecopy is designed to not care about what is actually on the remote
 server - it simply keeps a record of what it THINKS is in on the remote
 server, and works from that.

Changes: 
 sitecopy (1:0.15.0-1) unstable; urgency=low
 .
   * New maintainer (closes: #294991)
   * New upstream release (closes: #181949, #198307, #285249, #207546,
 #285249)
   * Removed xsitecopy build from control & debian/rules (obsolete upstream)
   * Removed --disable-debug flag from build to allow client-level
 debugging (closes: #185624)
   * Added man description of SSL configuration (closes: #228643)
   * Upstream release handles spaces in file & directory names (closes:
 #285722)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]