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
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
58 matches
Mail list logo
