Quoting Andreas Tille (2013-01-16 15:11:22)
> On Wed, Jan 16, 2013 at 02:43:54PM +0100, Jonas Smedegaard wrote:
> >
> > Sorry if I am dense...
>
> I like you because I know you are dense. ;-)
>
> > You agree that Files and Files-Excluded should ideally use same
> > format, but you find it more
On Wed, Jan 16, 2013 at 02:43:54PM +0100, Jonas Smedegaard wrote:
>
> Sorry if I am dense...
I like you because I know you are dense. ;-)
> You agree that Files and Files-Excluded should ideally use same format,
> but you find it more important that Files-Excluded be flexible - even
> if File
Quoting Andreas Tille (2013-01-16 14:19:55)
> On Wed, Jan 16, 2013 at 12:35:27PM +0100, Jonas Smedegaard wrote:
> > > OK. So Fields-Excluded is currently not part of DEP5 anyway and so I
> > > revert my former answer that it fits the Files format because it may
> > > contain [] wildcards (and I
On Wed, Jan 16, 2013 at 12:35:27PM +0100, Jonas Smedegaard wrote:
> > OK. So Fields-Excluded is currently not part of DEP5 anyway and so I
> > revert my former answer that it fits the Files format because it may
> > contain [] wildcards (and I do not see any problem because of this).
> > I agr
Quoting Andreas Tille (2013-01-16 10:45:04)
> Hi,
>
> On Fri, Jan 11, 2013 at 08:06:43PM +0100, Jonas Smedegaard wrote:
> > > On Fri, Jan 11, 2013 at 08:39:41PM +0900, Charles Plessy wrote:
> > > > > Not any more (hopefully) since I droped the `find -name`
> > > > > approach which turned out as i
Le Wed, Jan 16, 2013 at 10:45:04AM +0100, Andreas Tille a écrit :
>
> OK. So Fields-Excluded is currently not part of DEP5 anyway and so I
> revert my former answer that it fits the Files format because it may
> contain [] wildcards (and I do not see any problem because of this). I
> agree with
Hi,
On Fri, Jan 11, 2013 at 08:06:43PM +0100, Jonas Smedegaard wrote:
> > On Fri, Jan 11, 2013 at 08:39:41PM +0900, Charles Plessy wrote:
> > > > Not any more (hopefully) since I droped the `find -name` approach
> > > > which turned out as insufficient (even if very attractive in the
> > > > fir
Quoting Andreas Tille (2013-01-11 13:36:19)
> On Fri, Jan 11, 2013 at 08:39:41PM +0900, Charles Plessy wrote:
> > > Not any more (hopefully) since I droped the `find -name` approach
> > > which turned out as insufficient (even if very attractive in the
> > > first place).
> > In that case, the f
Quoting Nicolas Boulenguez (2013-01-11 17:51:20)
> Before renouncing to a consistent use of the format expressivity for
> documentation of upstream files licence or removal, I would like your
> first reactions about modifying the format towards the direction
> suggested by this pseudo-patch.
[p
Best wishes to all readers for the new year.
On Mon, Jan 07, 2013 at 11:13:16PM +0100, Andreas Tille wrote:
> From my point of view we should now discuss first what way to
> prefer: Either the 'Files-Excluded' field or 'License:
> not-shipped-by-debian' should be used and we should decide now
> be
Hi Charles,
On Fri, Jan 11, 2013 at 08:39:41PM +0900, Charles Plessy wrote:
> > Not any more (hopefully) since I droped the `find -name` approach which
> > turned out as insufficient (even if very attractive in the first place).
>
> Hi Andreas,
>
> In that case, the field in mothur's copyright
Le Thu, Jan 10, 2013 at 08:36:56AM +0100, Andreas Tille a écrit :
> On Thu, Jan 10, 2013 at 09:00:49AM +0900, Charles Plessy wrote:
>
> > By the way, are there differences with the syntax of the Files field ?
>
> Not any more (hopefully) since I droped the `find -name` approach which
> turned ou
Hi Charles,
On Thu, Jan 10, 2013 at 09:00:49AM +0900, Charles Plessy wrote:
> I think that it would be preferrable to refrain from adding special keywords
> to
> the License field, to guarantee that it contains only license information. I
> would therefore recommend using the Files-Excluded fiel
Le Mon, Jan 07, 2013 at 11:13:16PM +0100, Andreas Tille a écrit :
>
> From my point of view we should now discuss first what way to prefer:
> Either the 'Files-Excluded' field or 'License: not-shipped-by-debian'
> should be used and we should decide now before we keep on implementing
> it. I have
Hi Nicolas,
happy new year - happy new discussion.
I was busy editing the Wiki page you created[1] and updated also the Git
repository to finally apply the patch you mentioned in the previous
discussion[2] because I realised that the `find -name` solution had the
drawback that it is not possible
On Mon, Sep 10, 2012 at 09:26:40AM +0200, Andreas Tille wrote:
> Would you volunteer to create a Wiki page to enable better structure
> and which might lead to some consensus about the implementation?
Anyone interested, feel free to review [1] and continue the
discussion there.
[1] http://wiki.d
On Mon, Sep 10, 2012 at 09:26:40AM +0200, Andreas Tille wrote:
> Would you volunteer to create a Wiki page to enable better structure
> and which might lead to some consensus about the implementation?
I would like to... if I eventually manage to create an account on
wiki.debian.org. Sorry for the
Hi Nicolas,
thanks for your additional comments. I see some good ideas in your new
suggestions (which do solve for instance the issue of enabling per
removal comments). However, I have the impression that the discussion
via mailing list fails to scale to handle the complex branches of this
discu
On Thu, Sep 06, 2012 at 10:34:38PM +0200, Andreas Tille wrote:
> It specifies:
>
> Files-Excluded:
> __MACOSX
> [a-z]*.jar
>
> with the purpose to save ReadSeq.jar inside the source package. This
> works with the old method:
>
> $ find . -name "[a-z]*.jar"
> ./rdp_classifier_2.5/lib/junit.j
Hi Nicolas,
On Wed, Sep 05, 2012 at 01:17:47AM +0200, Nicolas Boulenguez wrote:
>
> diff --git a/scripts/uscan.pl b/scripts/uscan.pl
> index 649f822..34e31a9 100755
> --- a/scripts/uscan.pl
> +++ b/scripts/uscan.pl
> @@ -1494,17 +1494,9 @@ EOF
> print STDERR "Error: $main_source_
On Wed, Sep 05, 2012 at 09:04:19AM +0900, Charles Plessy wrote:
> the machine-readable format does not mention trailing slashes at the end
> of directory names, and refers to the -path test of the GNU find command,
Good. Having a trailing-slash be meaningful is very confusing. I especially
hate th
Le Wed, Sep 05, 2012 at 01:17:47AM +0200, Nicolas Boulenguez a écrit :
>
> - "foo" should match "foo", even if a directory.
> but do not correct
> - "foo" should not match "bar/foo", even if a file.
> - "foo/" should never match, even if "foo" is a directory.
>
> DEP5 does not distinguish files f
On Tue, Sep 04, 2012 at 07:14:21PM +0200, Andreas Tille wrote:
> You might like to check my last commit to
> git://git.debian.org/git/users/tille/devscripts.git
(currently 4b3a4a6310ff1ff80ac1498cf92a99817c75ffce)
> and check whether it matches your expectations when injecting
> Files-Exclud
On Fri, Aug 31, 2012 at 11:38:15AM +0200, Jonas Smedegaard wrote:
>
> Hmm. Seems my head was stock in a too old draft of DEP-5 - or
> completely off track. Sorry!
>
> I'll step back and let others figure out wat is proper interpretation.
You might like to check my last commit to
git://gi
On 12-08-31 at 03:38am, Nicolas Boulenguez wrote:
> (apologizes for the previous empty mail)
>
> On Thu, Aug 30, 2012 at 11:44:34PM +0200, Andreas Tille wrote:
> > On Thu, Aug 30, 2012 at 02:32:56AM +0200, Nicolas Boulenguez wrote:
>
> > > Assume that "a" and "b" are directories, if I understand
(apologizes for the previous empty mail)
On Thu, Aug 30, 2012 at 11:44:34PM +0200, Andreas Tille wrote:
> On Thu, Aug 30, 2012 at 02:32:56AM +0200, Nicolas Boulenguez wrote:
> > Assume that "a" and "b" are directories, if I understand well, the
> > current behaviour is to recursively remove "a/b/
On 12-08-30 at 11:44pm, Andreas Tille wrote:
> I repost some extract from some private discussion about the
> Files-Excluded enhancement of uscan where Nicolas Boulenguez found
> some issues. (Nicolas, I hope you don't mind if I quote some of your
> non-private remarks in public.)
>
> Nicolas
Hi,
I repost some extract from some private discussion about the
Files-Excluded enhancement of uscan where Nicolas Boulenguez found
some issues. (Nicolas, I hope you don't mind if I quote some of
your non-private remarks in public.)
Nicolas problem is mainly that if you specify
"Files-Exclu
On Wed, Aug 29, 2012 at 09:17:19AM +0100, Simon McVittie wrote:
> On 29/08/12 07:55, Andreas Tille wrote:
> > When trying to get rid of some get-orig-source
> > scripts I noticed that besided some file removals I need to execute
> > some extra code. This is basically fetching some extra files like
* Simon McVittie , 2012-08-29, 09:17:
IMHO this could be done quite simple if we would enable uscan to call
a script say debian/uscan.hook (feel free to propose a better name).
This is a security flaw if you want uscan to be safe to use on
untrusted source (e.g. in DEHS). It seems that uscan tri
Le 29 août 2012 10:17, "Simon McVittie" a écrit :
>
> On 29/08/12 07:55, Andreas Tille wrote:
> > When trying to get rid of some get-orig-source
> > scripts I noticed that besided some file removals I need to execute
> > some extra code. This is basically fetching some extra files like
> > source
On 29/08/12 07:55, Andreas Tille wrote:
> When trying to get rid of some get-orig-source
> scripts I noticed that besided some file removals I need to execute
> some extra code. This is basically fetching some extra files like
> sources for documentation, uncompressed JS files etc from external
>
Hi,
as you might have noticed I implemented some way to teach uscan
excluding certain files from upstream tarball to make it dfsg compatible
(see bug #685787). When trying to get rid of some get-orig-source
scripts I noticed that besided some file removals I need to execute some
extra code. This
33 matches
Mail list logo
