Bug 152744 - sysutils/duplicity updated to 0.6.11
Summary: sysutils/duplicity updated to 0.6.11
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Sahil Tandon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-01 14:20 UTC by Vlad V. Teterya
Modified: 2011-03-16 03:30 UTC (History)
1 user (show)

See Also:


Attachments
duplicity-0.6.11.patch (4.07 KB, patch)
2010-12-01 14:20 UTC, Vlad V. Teterya
no flags Details | Diff
updating.txt (665 bytes, text/plain; charset=US-ASCII)
2011-02-16 21:35 UTC, Peter Schuller
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vlad V. Teterya 2010-12-01 14:20:03 UTC
- update to 0.6.11 (fixed s3 issue)
- add WITHOUT_NLS switch

Note: sysUtils/duplicity-devel must be updated to new development branch 0.7
MAINTAINER in Cc

Please close my previous PR - ports/152717
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2010-12-01 14:20:11 UTC
Maintainer of sysutils/duplicity,

Please note that PR ports/152744 has just been submitted.

If it contains a patch for an upgrade, an enhancement or a bug fix
you agree on, reply to this email stating that you approve the patch
and a committer will take care of it.

The full text of the PR can be found at:
    http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/152744

-- 
Edwin Groothuis via the GNATS Auto Assign Tool
edwin@FreeBSD.org
Comment 2 Edwin Groothuis freebsd_committer freebsd_triage 2010-12-01 14:20:13 UTC
State Changed
From-To: open->feedback

Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Comment 3 Peter Schuller 2010-12-12 11:05:13 UTC
Can a committer willing to sort out repocopy/renames etc get in touch with me?

duplicity needs updating but this patch should really be towards
-devel currently. Except that 0.6 is no longer -devel, but I haven't
been able to get in touch with someone who can help with repocopies
and the like.

I don't have time to produce a bunch of diffs if nothing is going to
happen anyway.

If no one has time I guess this can be committed but it will put the
duplicity ports into an even more confusing state than they are
already.

-- 
/ Peter Schuller
Comment 4 Sahil Tandon freebsd_committer freebsd_triage 2011-02-13 15:14:37 UTC
Peter,

What do you need in the way of repocopies?  Please clarify why this
patch should not be applied to this version of the port.  Thanks.

-- 
Sahil Tandon <sahil@FreeBSD.org>
Comment 5 Sahil Tandon freebsd_committer freebsd_triage 2011-02-13 15:14:50 UTC
Responsible Changed
From-To: freebsd-ports-bugs->sahil

Take.
Comment 6 Peter Schuller 2011-02-13 15:32:57 UTC
> What do you need in the way of repocopies? =C2=A0Please clarify why this
> patch should not be applied to this version of the port. =C2=A0Thanks.

Currently, there is sysutils/duplicity (at 0.5) and
sysutils/duplicity-devel (at 0.6). sysutils/duplicity-devel is really
no longer -devel, but previous attempts at arranging a repocopy
failed.

I have no problem with the submitted patch being applied against
sysutil/duplicity except VCS history retention issues, but if that is
done then sysutils/duplicity-devel should be removed.

My suggestion is to be kinder w.r.t. backwards compatibility and make
sysutils/duplicity in its current form (0.5) sysutils/duplicity05,
make sysutils/duplicity-devel sysutils/duplicity (which also implies
applying this patch).

sysutils/duplicity-devel need not be retained I think, until
development becomes more active upstream and there is a non-stable
release series like there used to be.

So to re-state; my suggestion for maximum history retention and cleanliness=
 is:

(1) repocopy sysutils/duplicity to sysutils/duplicity05
(2) repocopy sysutils/duplicity-devel to sysutils/duplicity
(3) upgrade sysutils/duplicity to the latest version

I can double check and make sure the patch is still valid for (3)
given (1) and (2) or else produce an alternate patch. I can't do (1)
and (2) without the help of a committer.

Alternatively if retaining sysutils/duplicity05 is deemed
unacceptable, I suggest just doing (2) (implying the removal of the
old version) and (3). Or for that matter just removing -devel and
applying the patch as originally submitted.

In either case, a note in UPDATING would be useful unless duplicity is
below the threshold of general interest. I could provide a phrasing
for such an entry (but I have to go back and double-check what the
most important differences are; IIRC 05->06 implies cmdline changes
and some POLA violating changes in behavior w.r.t. local caching of
meta data).

I'll do this if someone's on the horn to work with me to get it
resolved; I just want to avoid doing the work uselessly (time
constraints). My main aim is that I would want the final status of
duplicity in ports to make sense for the user, meaning that
sysutils/duplicity is the stable version and sysutils/duplicity-devel
is either non-existent or as up-to-date as sysutils/duplicity.
Retaining 0.5 as sysutils/duplicity05 is a bonus, but would be kind to
users IMO.

--=20
/ Peter Schuller
Comment 7 Sahil Tandon 2011-02-13 15:59:53 UTC
On Sun, 2011-02-13 at 15:40:08 +0000, Peter Schuller wrote:

>  Currently, there is sysutils/duplicity (at 0.5) and
>  sysutils/duplicity-devel (at 0.6). sysutils/duplicity-devel is really
>  no longer -devel, but previous attempts at arranging a repocopy
>  failed.

I am sorry that previous attempts failed; I hope I can help you this
time around.

>  I have no problem with the submitted patch being applied against
>  sysutil/duplicity except VCS history retention issues, but if that is
>  done then sysutils/duplicity-devel should be removed.
>  
>  My suggestion is to be kinder w.r.t. backwards compatibility and make
>  sysutils/duplicity in its current form (0.5) sysutils/duplicity05,
>  make sysutils/duplicity-devel sysutils/duplicity (which also implies
>  applying this patch).

This seems fine, but I just wonder why duplicity05 rather than
duplicity5? :)

>  sysutils/duplicity-devel need not be retained I think, until
>  development becomes more active upstream and there is a non-stable
>  release series like there used to be.

Ok, so we should just remove it from the tree and make an appropriate
entry in ports/MOVED to note its removal.

>  So to re-state; my suggestion for maximum history retention and
>  cleanliness is:
>  
>  (1) repocopy sysutils/duplicity to sysutils/duplicity05

OK.

>  (2) repocopy sysutils/duplicity-devel to sysutils/duplicity 

I would rather remove the -devel port, since after doing (1), we can
simply do (3).  This is how many major-level upgrades are handled in
other parts of the tree.  Let me know if you have strong feelings
against that approach.

>  (3) upgrade sysutils/duplicity to the latest version

Sounds good.

>  In either case, a note in UPDATING would be useful unless duplicity
>  is below the threshold of general interest. I could provide a
>  phrasing for such an entry (but I have to go back and double-check
>  what the most important differences are; IIRC 05->06 implies cmdline
>  changes and some POLA violating changes in behavior w.r.t. local
>  caching of meta data).

Please draft a patch against UPDATING based on the above exchange, and I
will be happy to commit it.

-- 
Sahil Tandon <sahil@tandon.net>
Comment 8 Sahil Tandon freebsd_committer freebsd_triage 2011-02-16 00:53:03 UTC
Hi Peter,

Just following up.  Are you OK with the approach outlined in my response
earlier in the audit trail?  Do you have a draft of what you would like
to note in ports/UPDATING?  Once you give me the green light, I'll ask
the repomeister to proceed with the repocopy.

Thanks,
-- 
Sahil Tandon <sahil@FreeBSD.org>
Comment 9 Peter Schuller 2011-02-16 18:58:25 UTC
Thank you very much for your effort and following up. Unfortunately I
have been truly swamped. I'll try to get back to you later tonight.
But yes it all sounds good, I just need to check back what the changes
where. There are two I know of that I want to node (cmdline + cache).

-- 
/ Peter Schuller
Comment 10 Peter Schuller 2011-02-16 21:33:17 UTC
>> =C2=A0My suggestion is to be kinder w.r.t. backwards compatibility and m=
ake
>> =C2=A0sysutils/duplicity in its current form (0.5) sysutils/duplicity05,
>> =C2=A0make sysutils/duplicity-devel sysutils/duplicity (which also impli=
es
>> =C2=A0applying this patch).
>
> This seems fine, but I just wonder why duplicity05 rather than
> duplicity5? :)

duplicity5 is fine if you think it is more idiomatic. I just had vague
feelings that 05 was the way I had seen it done in the past.

> Ok, so we should just remove it from the tree and make an appropriate
> entry in ports/MOVED to note its removal.

Sounds good.

> I would rather remove the -devel port, since after doing (1), we can
> simply do (3). =C2=A0This is how many major-level upgrades are handled in
> other parts of the tree. =C2=A0Let me know if you have strong feelings
> against that approach.

If that's how it's usually done, +1 from me. (I was thinking that
loosing the incremental upgrade steps from VCS history that went into
the 0.6 version would want to be kept. I don't really think it's
important though so I'm not fussed. Just trying to be idioamatic :)

>> =C2=A0(3) upgrade sysutils/duplicity to the latest version
>
> Sounds good.

I tested the patch as originally submitted; looks good to me.

> Please draft a patch against UPDATING based on the above exchange, and I
> will be happy to commit it.

So I went back and refreshed my memory with the upstream changelog.
Turns out the command line changes pre-date 0.5 and are no longer
relevant. However, the handling of the cache/archive directory has
still changed in relevant ways and I would suggest the following entry
(gmail may mangle whitespace, we'll see):

  AFFECTS: users of sysutils/duplicity, sysutils/duplicity-devel

  sysutils/duplicity has been upgraded to 0.6.11. The old version
(0.5.20) is retained as
  sysutils/duplicity5. duplicity 0.6 should be generally compatible,
but pay special attention
  to the new meaning of the --archive-dir command. In particular, the
archive dir is now
  mandatory and defaults to ~/.cache/duplicity. You may have to
--exclude accordingly.
  In addition, it is recommended you consult the changelog:

    /usr/local/share/doc/duplicity/CHANGELOG

  Specifically the "New in v0.6.00 (2009/06/08)" section and the
checkpoint/restore
  feature, which is enabled by default, and its implications.

Sorry about holding up the update of this port.

--=20
/ Peter Schuller
Comment 11 Peter Schuller 2011-02-16 21:35:32 UTC
gmail mangled. Attaching a text file (sorry, no mutt for me right now).

-- 
/ Peter Schuller
Comment 12 Sahil Tandon freebsd_committer freebsd_triage 2011-02-18 02:42:12 UTC
On Wed, 2011-02-16 at 22:33:17 +0100, Peter Schuller wrote:

> >> =A0My suggestion is to be kinder w.r.t. backwards compatibility and =
make
> >> =A0sysutils/duplicity in its current form (0.5) sysutils/duplicity05=
,
> >> =A0make sysutils/duplicity-devel sysutils/duplicity (which also impl=
ies
> >> =A0applying this patch).
> >
> > This seems fine, but I just wonder why duplicity05 rather than
> > duplicity5? :)
>=20
> duplicity5 is fine if you think it is more idiomatic. I just had vague
> feelings that 05 was the way I had seen it done in the past.

I agree that duplicity05 would be more idiomatic; sorry for leading you
astray.

> > Ok, so we should just remove it from the tree and make an appropriate
> > entry in ports/MOVED to note its removal.
>=20
> Sounds good.
>=20
> > I would rather remove the -devel port, since after doing (1), we can
> > simply do (3). =A0This is how many major-level upgrades are handled i=
n
> > other parts of the tree. =A0Let me know if you have strong feelings
> > against that approach.
>=20
> If that's how it's usually done, +1 from me. (I was thinking that
> loosing the incremental upgrade steps from VCS history that went into
> the 0.6 version would want to be kept. I don't really think it's
> important though so I'm not fussed. Just trying to be idioamatic :)

The VCS histry would remain because the existing duplicity port gets
upgraded to 0.6.x; while the 05 port (because it is repocopied) also
retains that same VCS history.

The only concern I have is that a 0.7.x development branch is supposedly
going to be released at some point in the future.  Will it then be
necessary to re-introduce the -devel port?  In that case, all the prior
VCS history would be lost and a new port would have to be created.

[ .. ]

> Sorry about holding up the update of this port.

No problem, and no need to apologize.  We all have real lives, and
they definitely take precedence. :-)

--=20
Sahil Tandon <sahil@FreeBSD.org>
Comment 13 Peter Schuller 2011-02-26 10:35:01 UTC
> The only concern I have is that a 0.7.x development branch is supposedly
> going to be released at some point in the future. =C2=A0Will it then be
> necessary to re-introduce the -devel port? =C2=A0In that case, all the pr=
ior
> VCS history would be lost and a new port would have to be created.

Well, extrapolating from past history of duplicity the 0.7 devel
branch may be useful to users for quite a while before becoming stable
so it would be nice it if were eventually available in ports. I
suppose it boils down to the overhead of having the extra port vs. the
number of users that use duplicity in ports (and I have no idea about
the latter). So I suppose yes - I'd expect there to be interest in
-devel in the future too.

--=20
/ Peter Schuller
Comment 14 Sahil Tandon freebsd_committer freebsd_triage 2011-02-27 04:33:36 UTC
OK.  I've requested a repocopy, and we will IGNORE the -devel port until
it is updated to a version higher than the new sysutils/duplicity.

-- 
Sahil Tandon <sahil@FreeBSD.org>
Comment 15 dfilter service freebsd_committer freebsd_triage 2011-03-16 03:25:11 UTC
sahil       2011-03-16 03:24:49 UTC

  FreeBSD ports repository

  Modified files:
    sysutils/duplicity   Makefile distinfo pkg-plist 
    sysutils/duplicity/files patch-setup.py 
  Log:
  Update to 0.6.11, add WITHOUT_NLS switch and
  update CONFLICTS.
  
  PR:             ports/152744
  Submitted by:   Vlad V. Teterya <vlad@vlad.uz.ua>
  Approved by:    maintainer
  
  Revision  Changes    Path
  1.35      +15 -4     ports/sysutils/duplicity/Makefile
  1.23      +2 -3      ports/sysutils/duplicity/distinfo
  1.7       +4 -4      ports/sysutils/duplicity/files/patch-setup.py
  1.13      +13 -7     ports/sysutils/duplicity/pkg-plist
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 16 Sahil Tandon freebsd_committer freebsd_triage 2011-03-16 03:26:28 UTC
State Changed
From-To: feedback->closed

Committed, with minor changes. Thanks!