On Wed, Mar 18 2009, Steve Langasek wrote:
> On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
>> >> Given that we already have a tool that can download upstream
>> >> sources, with or without mangling, and can be used by facilities
>> >> outside of the unpacked Debian so
On Mon, Mar 16, 2009 at 11:38:50AM -0500, Manoj Srivastava wrote:
> I am opposed to bloating the policy with dictum that are
> unnecessary, but I see your point about the API. The API is essentially
> the watch file, and we already specify that in the policy. DEHS (as
> mentioned in pol
On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
> >> Given that we already have a tool that can download upstream
> >> sources, with or without mangling, and can be used by facilities
> >> outside of the unpacked Debian source package to determine if there was
> >> new
On Mon, Mar 16, 2009 at 03:14:25AM -0500, Manoj Srivastava wrote:
> On Mon, Mar 16 2009, Ben Finney wrote:
>
> > Manoj Srivastava writes:
> >
> >> I would not be against a recommendation in policy to implement
> >> direct-from-vcs upstream tarballs to be created vbia get-orig-source,
>
Stefano Zacchiroli wrote:
[...]
> NACK. While uscan can be considered an API, it looks much like an
> implementation to me. The API you get with it is that you can call
> "uscan" with its parameters, but you cannot implement that API with
> anything else. An API is something I expect to be able t
On Mon, Mar 16, 2009 at 11:38:50AM -0500, Manoj Srivastava wrote:
> I am opposed to bloating the policy with dictum that are
> unnecessary, but I see your point about the API.
Of course, nobody would object to that, but this bit can be seen as
necessary.
> The API is essentially the watch file, a
On Mon, Mar 16 2009, Stefano Zacchiroli wrote:
> In a sense, while uscan offers an implementation, the policy offer its
> API. The two are complementary and I don't see why I should loose one
> because of the other.
>
> Also, having an API, offers exactly encapsulation, in the sense that
> you ca
On Sun, Mar 15, 2009 at 06:48:11PM -0500, Manoj Srivastava wrote:
> Given that we already have a tool that can download upstream
> sources, with or without mangling, and can be used by facilities
> outside of the unpacked Debian source package to determine if there was
> new versions and
On Mon, Mar 16 2009, Ben Finney wrote:
> Manoj Srivastava writes:
>
>> I would not be against a recommendation in policy to implement
>> direct-from-vcs upstream tarballs to be created vbia get-orig-source,
>> and everyone else just use debian/watch and debian/urepack files.
>
> Okay,
Ben Finney writes:
> Ben Hutchings writes:
>
>> # Upstream homepage links to a file called puzzles.tar.gz which
>> # redirects to puzzles-r$version.tar.gz. uscan can't check that.
>> # However, this is a nightly snapshot numbered according to the SVN
>> # revision number, so we can extract the
Manoj Srivastava writes:
> I would not be against a recommendation in policy to implement
> direct-from-vcs upstream tarballs to be created vbia get-orig-source,
> and everyone else just use debian/watch and debian/urepack files.
Okay, now I'm officially confused. I don't see how the
On Sun, Mar 15 2009, Steve Langasek wrote:
> On Sun, Mar 15, 2009 at 06:48:11PM -0500, Manoj Srivastava wrote:
>> On Thu, Mar 12 2009, Russ Allbery wrote:
>
>> Given that we already have a tool that can download upstream
>> sources, with or without mangling, and can be used by facilities
Ben Hutchings writes:
> # Upstream homepage links to a file called puzzles.tar.gz which
> # redirects to puzzles-r$version.tar.gz. uscan can't check that.
> # However, this is a nightly snapshot numbered according to the SVN
> # revision number, so we can extract the version number from its web
Russ Allbery writes:
> However, I don't think this helps with the original problem on the
> thread where upstream uses only a VCS. I think that's a bad idea,
> but some upstreams do it, and right now uscan doesn't handle that
> sort of case (and it's rather outside its current purpose).
Note tha
Ben Hutchings writes:
> On Sun, 2009-03-15 at 18:15 -0700, Russ Allbery wrote:
>> However, I don't think this helps with the original problem on the
>> thread where upstream uses only a VCS. I think that's a bad idea, but
>> some upstreams do it, and right now uscan doesn't handle that sort of
>
On Sun, Mar 15, 2009 at 06:48:11PM -0500, Manoj Srivastava wrote:
> On Thu, Mar 12 2009, Russ Allbery wrote:
> Given that we already have a tool that can download upstream
> sources, with or without mangling, and can be used by facilities
> outside of the unpacked Debian source package t
On Sun, 2009-03-15 at 18:15 -0700, Russ Allbery wrote:
> Manoj Srivastava writes:
>
> > Given that we already have a tool that can download upstream
> > sources, with or without mangling, and can be used by facilities
> > outside of the unpacked Debian source package to determine if the
Manoj Srivastava writes:
> Given that we already have a tool that can download upstream
> sources, with or without mangling, and can be used by facilities
> outside of the unpacked Debian source package to determine if there was
> new versions and to download unmangled versions, is the
Manoj Srivastava writes:
> # You should have received a copy of the GNU General Public License
> # along with this program; if not, write to the Free Software
> # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> # USA
W: old-fsf-address-in-copyright-notice
:-) Thanks, Manoj
On Thu, Mar 12 2009, Russ Allbery wrote:
> Manoj Srivastava writes:
>
>> a) Run a upstream version check from cron, which mails me if there are
>> new upstream versions of something I have.
>> b) If there is a new upstream version, cd checked out dir
>> 1. No munging required: use uscan
Bernd Zeimetz wrote:
> My impression is that people become lazy
> since uscan and similar tools exist and are not enough in contact with
> their upstreams anymore. I may be wrong, though...
> Watch files are nice to have, but nothing more.
>
But there are cases where any attempt of contact with u
Just for the sake of the discussion:
A post-download command can be specified directly in the watch file, which
can be either uupdate, debian/rules get-orig-source, debian/dfsg.sh, or
whatever you want to call.
>From uscan(1):
> Finally, if a third parameter (an action) is given in the watchfile l
Ben Finney wrote:
> On 12-Mar-2009, Bernd Zeimetz wrote:
>> Hi,
>>
>> > The best way to get the exact sources for the current
>> > version probably should be a new watch file
>> > (watch-current) which has a static version number in the
>> > regexp
>
> I don't se
On Thu, Mar 12 2009, Steve Langasek wrote:
> On Thu, Mar 12, 2009 at 06:48:32PM -0500, Manoj Srivastava wrote:
>
> Oh, I think the existing language is perfectly unambiguous, I'm just saying
> that the behavior described doesn't seem to be what most/many maintainers
> want in practice, with the re
Russ Allbery wrote:
> Bernd Zeimetz writes:
>
>> No, please don't just add another watch file just for the sake of it,
>> using these files is more or less like living in the last
>> century. People are able to get the current source from the Debian pool,
>> if that is not enough for them, they s
Manoj Srivastava wrote:
> On Thu, Mar 12 2009, Bernd Zeimetz wrote:
>
>> Manoj Srivastava wrote:
>>> a) Run a upstream version check from cron, which mails me if there are
>>> new upstream versions of something I have.
>> What happens if your watch file breaks? Do you check upstream announcem
On Thu, Mar 12, 2009 at 08:49:19PM +0100, Bernd Zeimetz wrote:
> No, please don't just add another watch file just for the sake of it, using
> these files is more or less like living in the last century. People are able
> to
> get the current source from the Debian pool, if that is not enough for
On Thu, Mar 12, 2009 at 06:48:32PM -0500, Manoj Srivastava wrote:
> >> Is this so very different from what people do? Some times I do
> >> not package every upstream version, if they are coming in rapid
> >> succession, or if I find some version unfit for Debian -- but in any
> >> case,
On 12-Mar-2009, Bernd Zeimetz wrote:
> Hi,
>
> > The best way to get the exact sources for the current
> > version probably should be a new watch file
> > (watch-current) which has a static version number in the
> > regexp
I don't see why this file would be needed
Ben Finney writes:
> On 12-Mar-2009, Russ Allbery wrote:
>> I never use uscan --download; I always download the new upstream source
>> myself using wget or a web browser or FTP client.
> Why is that? Is there some downside to using ‘uscan --download’? I would
> have thought it best to use the au
On 12-Mar-2009, Russ Allbery wrote:
> Manoj Srivastava writes:
>
> > b) If there is a new upstream version, cd checked out dir
> > 1. No munging required: use uscan --rename --verbose to get the
> >latest source.
> > 2. Munging needed. Run get-orig-source to get the latest upstre
Hi,
[Moving this away from the BTS]
On Thu, Mar 12 2009, Steve Langasek wrote:
> On Thu, Mar 12, 2009 at 12:38:24PM -0500, Manoj Srivastava wrote:
>
>> Is this so very different from what people do? Some times I do
>> not package every upstream version, if they are coming in rapid
>>
On 12-Mar-2009, Manoj Srivastava wrote:
> To recap:
> 1) apt-get source is enough to get the latest Debian source from the
> archive (and whet for older sources)
I presume you mean ‘wget’ here. (Apart from ‘apt-get source’, is there
another tool that is *solely* focussed on getting th
On Thu, Mar 12 2009, Bernd Zeimetz wrote:
> Manoj Srivastava wrote:
>> a) Run a upstream version check from cron, which mails me if there are
>> new upstream versions of something I have.
>
> What happens if your watch file breaks? Do you check upstream announcements
> manually, too?
On Thu, Mar 12 2009, Russ Allbery wrote:
> Manoj Srivastava writes:
>
>> a) Run a upstream version check from cron, which mails me if there are
>> new upstream versions of something I have.
>> b) If there is a new upstream version, cd checked out dir
>> 1. No munging required: use uscan
On 12-Mar-2009, Gunnar Wolf wrote:
> I feel this should clearly be an optional target, and the canonical
> location for orig.tar.gz files should still be our archive
Yes to both. Thanks for making this explicit in the discussion.
--
\ “Reichel's Law: A body on vacation tends to remain on v
Steve Langasek writes:
> (N.B.: I say "it makes sense to me", but in practice the packages I've
> inherited hardcode the version to pull in debian/rules rather than
> parsing the changelog. I consider this a minor bug that I just haven't
> gotten around to fixing.)
I got into the habit of doing
On Thu, Mar 12, 2009 at 09:59:50AM -0700, Russ Allbery wrote:
> I personally use the same technique that Steve uses for the packages that
> I maintain that need to be repacked, and I'm having a failure of
> imagination for how I could do it the way that Manoj describes.
I use versionned for packag
On Thu, Mar 12, 2009 at 12:38:24PM -0500, Manoj Srivastava wrote:
> Is this so very different from what people do? Some times I do
> not package every upstream version, if they are coming in rapid
> succession, or if I find some version unfit for Debian -- but in any
> case, the majori
Bernd Zeimetz writes:
> No, please don't just add another watch file just for the sake of it,
> using these files is more or less like living in the last
> century. People are able to get the current source from the Debian pool,
> if that is not enough for them, they should be old enough to be ab
Manoj Srivastava wrote:
> a) Run a upstream version check from cron, which mails me if there are
> new upstream versions of something I have.
What happens if your watch file breaks? Do you check upstream announcements
manually, too?
> b) If there is a new upstream version, cd checked out di
Hi,
> The best way to get the exact sources for the current version
> probably should be a new watch file (watch-current) which has a static
> version number in the regexp, but can use all the other facilities f
> uscan -- wild carded directory, looking thoiugh an index.html page for
>
Manoj Srivastava writes:
> a) Run a upstream version check from cron, which mails me if there are
> new upstream versions of something I have.
> b) If there is a new upstream version, cd checked out dir
> 1. No munging required: use uscan --rename --verbose to get the
>latest so
On Thu, Mar 12 2009, Russ Allbery wrote:
>
> I personally use the same technique that Steve uses for the packages that
> I maintain that need to be repacked, and I'm having a failure of
> imagination for how I could do it the way that Manoj describes.
Hmm. Let me see if I can elucidate. He
Gunnar Wolf writes:
> Good point you have here - But (and I know it is not being discussed
> yet, maybe you want to teleport this thread a couple of years into the
> future) I feel this should clearly be an optional target, and the
> canonical location for orig.tar.gz files should still be our ar
On Thu, Mar 12 2009, Steve Langasek wrote:
> On Wed, Mar 11, 2009 at 10:13:51AM -0500, Manoj Srivastava wrote:
>> This is what diferentiates is from uscan; indeed, I use uscan in
>> the cases where I provide the target, The target unpacks the
>> raw upstream source, munges it (by, say, r
Steve Langasek dijo [Thu, Mar 12, 2009 at 02:05:42AM -0700]:
> I think it's perfectly reasonable to want the get-orig-source target to give
> you a *specified* version of an upstream tarball, rather than the *newest*
> version of an upstream tarball. Packaging a new upstream version doesn't
> nece
On Wed, Mar 11, 2009 at 10:13:51AM -0500, Manoj Srivastava wrote:
> This is what diferentiates is from uscan; indeed, I use uscan in
> the cases where I provide the target, The target unpacks the
> raw upstream source, munges it (by, say, removing a subdir which has
> non-dfsg stuff, or
On 11-Mar-2009, Manoj Srivastava wrote:
> On Wed, Mar 11 2009, Ben Finney wrote:
> > It's worth asking, then, what is the original purpose for which the
> > ‘get-orig-source’ target specification was inserted into the policy?
>
> Indeed, the whole rationale for the target, and why it got in
Manoj Srivastava writes:
> Perhaps it is time for me to play a more active role in policy
> again, if Russ is willing to let me back in.
Good heavens, yes. :) I've always found your Policy work to be extremely
valuable, and whatever time you're willing to spend on the work is greatly
Hi,
The best way to get the exact sources for the current version
probably should be a new watch file (watch-current) which has a static
version number in the regexp, but can use all the other facilities f
uscan -- wild carded directory, looking thoiugh an index.html page for
a matchi
On Wed, Mar 11 2009, Ben Finney wrote:
> On 11-Mar-2009, Goswin von Brederlow wrote:
>> 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 Debi
On 11-Mar-2009, Goswin von Brederlow wrote:
> 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 s
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 07-Mar-2009, Steve Langasek wrote:
> On Fri, Mar 06, 2009 at 11:03:57AM +1100, Ben Finney wrote:
>
> > === modified file 'policy.sgml'
[…]
> > + for Debian. See the “Original source archive”
> > + section, below, for policy details of this file.
> > +
>
> Surely, g
On Fri, Mar 06, 2009 at 11:03:57AM +1100, Ben Finney wrote:
> === modified file 'policy.sgml'
> --- policy.sgml 2009-03-05 08:44:48 +
> +++ policy.sgml 2009-03-05 23:59:38 +
> @@ -1907,12 +1907,21 @@
> get-orig-source (optional)
>
>
> -
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
Howdy all,
A Debian source package is constructed from a “pristine source”
tree, plus Debian-specific changes. The pristine source is usually the
tarball distributed by the upstream developer of the work.
The ‘uscan’ tool, as configured by the ‘debian/watch’ file in the
source package, allows ass
77 matches
Mail list logo
