Manoj Srivastava writes:
> I am wondering which is of more use to the end users as well: I
> can always get the sources of the package I have already on my disk
> from Debian, but getting the latest munged source seems more useful to
> me.
Full ACK. The way to get the current upstream
On Thu, Mar 05 2009, Russ Allbery wrote:
> Ben Finney writes:
>
>> It's been brought to my attention that this approach actually conflicts
>> with the above section of policy.
>>
>> Am I right in thinking that the ‘get-orig-source’ target should ignore
>> the version strings in ‘debian/changelog’
On 05-Mar-2009, Charles Plessy wrote:
> at the same time, your patch would make it mandatory to write a
> get-orig-source target when uscan(1) can not do the job. […] Can you
> soften your wording to the current "optional" status ?
Agreed. I also should have used the standard document markup for
v
Le Thu, Mar 05, 2009 at 08:39:50PM +1100, Ben Finney a écrit :
>
> I've proposed a patch to policy (in bug#466550) to bring policy in
> line with this practice.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466550#42
- This target is optional, but providing it if
Reinhard Tartler writes:
> Russ Allbery writes:
>
> > I think the way that you're using it is more useful (and possible)
> > than doing what an exact reading of the current text would
> > indicate, and I do the same thing that you're doing.
>
> FYI, from the ffmpeg-debian (and soon mplayer) pa
Russ Allbery writes:
>> Am I right in thinking that the ‘get-orig-source’ target should ignore
>> the version strings in ‘debian/changelog’, and should instead get
>> whatever version is the latest available from upstream?
>
> I think the way that you're using it is more useful (and possible) tha
Ben Finney writes:
> It's been brought to my attention that this approach actually conflicts
> with the above section of policy.
>
> Am I right in thinking that the ‘get-orig-source’ target should ignore
> the version strings in ‘debian/changelog’, and should instead get
> whatever version is the
Ben Finney writes:
> Debian's policy §4.9 discusses a ‘debian/rules’ target named
> ‘get-orig-source’:
>
> `get-orig-source' (optional)
> This target fetches the most recent version of the original
> source package from a canonical archive site (via FTP or
> WW
Russ Allbery writes:
> Adeodato Simó writes:
>
> > From the first paragraph in the manpage, it would seem that
> > pristine-tar just wants a "checkout" of the appropriate revision,
> > i.e. an unpacked tree. So you could checkout that from the
> > upstream VCS, and store the delta in the debian
Russ Allbery:
> I'm fairly sure that pristine-tar as currently implemented needs the
> upstream source to be in Git, whether in your local repository or in some
> remote repository to which you have a reference.
Only for the "checkout" and "commit" commands which store the deltas
in a git reposito
Adeodato Simó writes:
> From the first paragraph in the manpage, it would seem that pristine-tar
> just wants a "checkout" of the appropriate revision, i.e. an unpacked
> tree. So you could checkout that from the upstream VCS, and store the
> delta in the debian-only VCS, if in fact your packagin
On Wed, Mar 04, 2009 at 11:30:14AM +0100, Adeodato Simó wrote:
> * Stefano Zacchiroli [Wed, 04 Mar 2009 11:25:23 +0100]:
> > What you can do is probably have a 2 level architecture, with a VCS
> > Debian-side which mirrors upstream VCS (easy with DVCS) but has in
> > addition the deltas. The first
* Stefano Zacchiroli [Wed, 04 Mar 2009 11:25:23 +0100]:
> What you can do is probably have a 2 level architecture, with a VCS
> Debian-side which mirrors upstream VCS (easy with DVCS) but has in
> addition the deltas. The first time your tarball fetching tool will
> create the tarball and store it
On Wed, Mar 04, 2009 at 09:08:08PM +1100, Ben Finney wrote:
> I'm not sure how to actually use it in a Debian package though.
>
> Reading the manual pages, I get the impression it's designed to
> produce deltas that upstream then commits in their VCS. If I don't
> have access to commit to the upst
Cyril Brulebois writes:
> | $ apt-cache search pristine
> | dbs - Allows Debian source packages with multiple patches
> | linux-patch-debian-2.6.28 - Debian patches to version 2.6.28 of the Linux
> kernel
> | pristine-tar - regenerate pristine tarballs
>
> See the last one. pristine-{gz,bz2} in
Ben Finney (04/03/2009):
> How feasible is it to ensure reproducibility, though, when there is no
> canonical upstream release tarball?
Just saying that your get-orig-source stuff will not necessarily give
you the same tarball on different machines/setups/etc.
You want to look at pristine-tar to
On Wed, Mar 04, 2009 at 07:09:07PM +1100, Ben Finney wrote:
> I don't know what ‘pristine-*’ refers to there. I get no result from
> ‘apropos pristine’, so if you're referring to a command, I have no
> corresponding manpage.
See the pristine-tar package.
--
Stefano Zacchiroli -o- PhD in Computer
On Wed, Mar 4, 2009 at 5:09 PM, Ben Finney wrote:
>> See pristine-* for hints about things that can change between one
>> environment and another.
>
> I don't know what ‘pristine-*’ refers to there. I get no result from
> ‘apropos pristine’, so if you're referring to a command, I have no
> corres
Cyril Brulebois writes:
> Ben Finney (04/03/2009):
> > * Invoke the appropriate VCS tool to export the specified revision
> > from the VCS repository URL to a temporary directory.
> >
> > * Pack the temporary directory to an appropriately-named tarball in
> > the current directory.
Ben Finney (04/03/2009):
> * Invoke the appropriate VCS tool to export the specified revision
> from the VCS repository URL to a temporary directory.
>
> * Pack the temporary directory to an appropriately-named tarball in
> the current directory.
AFAICT, that doesn't ensure reproduci
Ben Finney writes:
> For an example of this approach, see the ‘docutils-manpage-writer’
> package.
The package is actually named ‘docutils-writer-manpage’.
--
\“The errors of great men are venerable because they are more |
`\ fruitful than the truths of little men.” —Friedrich N
21 matches
Mail list logo