Re: Possible release note for systems running PHP through CGI.

[Ondřej Surý]

On Mon, Aug 20, 2012 at 8:12 PM, Stefan Fritsch  wrote:
> On Monday 20 August 2012, Ondřej Surý wrote:
>> Ah, I see; it gets executed when there is no know handler or
>> mime-type for second extension.
>>
>> E.g. index.php.jpeg works as expected (e.g. returning PHP source
>> code), index.php.blubb but gets executed. I don't think there's any
>> harm in disabling php.foobar and php.blubb files.
>
> There is also the case that the extensions after .php are known to
> Apache but are not associated with mime types or handlers. For
> example, there are extensions like .de and .en which cause the
> Content-Language header to be set, extensions for setting the charset
> (e.g. .utf8) and extensions for setting the content-encoding (none
> configured by default).
>
> I don't know how often this is actually used together with php.
> Setting the Content-* headers in the php script seems saner to me.

Right, I have never seen this to be used together with PHP, but it
probably deserves a note somewhere.

>> > Good to see that we are heading towards a solution anyway.
>> >
>> > What shall I do with #674089 ?  I can reassign it to php5-cgi so
>> > that your next upload closes it, or do we still need release
>> > notes ?
>>
>> I think we still might need release notes, but it needs to be
>> updated based on final impact of changes we have done. I am not
>> sure if the information about .php.
>> is worth release notes or just NEWS file in PHP. My guess would be
>> latter, but opinions may vary.
>
> Maybe add just a small paragraph that the configuration of the
> extensions has changed and php users should read the NEWS file?

That's probably sensible approach.  I have quickly drafted short
paragraph which can be used for release notes:

Default PHP extension configuration
---

The mime-types package has dropped non-standard definitions of
PHP MIME-Types as a security measure.  Default PHP configuration
for libapache2-mod-php5{filter} and php5-cgi now only serve files
which have .php, .php[345] and .phtml extensions on a most right
place as opposed to previous state where .php.foobar
would have been interpreted.  Please read NEWS file in the PHP
SAPI of your choice for further information.


---

O.
-- 
Ondřej Surý 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALjhHG_CqTNyOY2K8QwLk=yFAJ6JYKDvs9aRAjFUVGdYZCB=l...@mail.gmail.com

Bug#685483: ITP: redmine-plugin-markdown -- Redmine plugin to add Markdown as a wiki format

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: redmine-plugin-markdown
Version: 2.0.1+git20120821-1
Upstream Author: Takashi Okamoto 
URL: https://github.com/alminium/redmine_redcarpet_formatter
License: GPL-2+
Description: "Redmine Redcarpet Markdown formatter"
 use Redcarpet which is GitHub's markdown wiki formatter
 to introduce Markdown support for Wiki in Redmine.
 Redcarpet is extreme fast and compatible GitHub's Wiki.


signature.asc
Description: This is a digitally signed message part.

Re: Possible release note for systems running PHP through CGI.

[Ondřej Surý]

> Default PHP extension configuration

^^^
This needs Apache 2, e.g.

Default PHP extension configuration for Apache 2.

> ---
>
> The mime-types package has dropped non-standard definitions of
> PHP MIME-Types as a security measure.  Default PHP configuration
> for libapache2-mod-php5{filter} and php5-cgi now only serve files
> which have .php, .php[345] and .phtml extensions on a most right
> place as opposed to previous state where .php.foobar
> would have been interpreted.  Please read NEWS file in the PHP
> SAPI of your choice for further information.

O.
-- 
Ondřej Surý 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg_0smdoegerxyen1u0mxgpmyyt1gbvmqdmictt-u4e...@mail.gmail.com

Re: Possible release note for systems running PHP through CGI.

[Ondřej Surý]

On Tue, Aug 21, 2012 at 9:38 AM, Konstantin Khomoutov
 wrote:
> On Tue, Aug 21, 2012 at 09:07:59AM +0200, Ondřej Surý wrote:
>
> [...]
>>> Maybe add just a small paragraph that the configuration of the
>>> extensions has changed and php users should read the NEWS file?
>>
>> That's probably sensible approach.  I have quickly drafted short
>> paragraph which can be used for release notes:
>>
>> Default PHP extension configuration
>> ---
>>
>> The mime-types package has dropped non-standard definitions of
>> PHP MIME-Types as a security measure.  Default PHP configuration
>> for libapache2-mod-php5{filter} and php5-cgi now only serve files
>> which have .php, .php[345] and .phtml extensions on a most right
>> place as opposed to previous state where .php.foobar
>> would have been interpreted.  Please read NEWS file in the PHP
>> SAPI of your choice for further information.
>
> I fail to parse that "on a most right place" bit though I'm not a native
> speaker.  If you meant that those extension specifications form a minimal
> sane and safe subset, may be just go ahead and write exactly that. ;-)

Nope I mean that the extension should be last.

E.g.  index.blah.php, but not index.php.blah.

O.
-- 
Ondřej Surý 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALjhHG8-3XkmJK53qrHpJjvFBATpproJB�h5rk7pgksmj...@mail.gmail.com

Re: Possible release note for systems running PHP through CGI.

[Konstantin Khomoutov]

On Tue, Aug 21, 2012 at 09:07:59AM +0200, Ondřej Surý wrote:

[...]
>> Maybe add just a small paragraph that the configuration of the
>> extensions has changed and php users should read the NEWS file?
> 
> That's probably sensible approach.  I have quickly drafted short
> paragraph which can be used for release notes:
> 
> Default PHP extension configuration
> ---
> 
> The mime-types package has dropped non-standard definitions of
> PHP MIME-Types as a security measure.  Default PHP configuration
> for libapache2-mod-php5{filter} and php5-cgi now only serve files
> which have .php, .php[345] and .phtml extensions on a most right
> place as opposed to previous state where .php.foobar
> would have been interpreted.  Please read NEWS file in the PHP
> SAPI of your choice for further information.

I fail to parse that "on a most right place" bit though I'm not a native
speaker.  If you meant that those extension specifications form a minimal
sane and safe subset, may be just go ahead and write exactly that. ;-)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821073858.GH1685@localhost.localdomain

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Gergely Nagy]

Philipp Kern  writes:

> On Mon, Aug 20, 2012 at 10:32:07AM +0200, Gergely Nagy wrote:
>> If neither upstream, nor porters care about a particular package, that
>> means there are very little use of having it on that port, and one
>> should consider changing the Architecture line to exclude the failing
>> port.
>> 
>> That's about a minute of work + an RM request for that port: another
>> minute or two. I don't think this is a bad thing, or something *any*
>> maintainer should find troublesome.
>
> That's untrue. An RM request might have far reaching consequences. It can mean
> that another package gets uninstallable, which then requires editing its
> Build-Dependency list if it can be built on the target architecture without 
> it.
> And that might trickle down to many packages. AFAIK that's basically the
> approach the GNOME maintainers use and it means that despite the package not
> being tested (and possibly used) at all on those architectures, you need to
> carry on a lot of excludes for that port and possibly cripple the platform.

Indeed, there are parts of the archive that are far more complicated
than the rest, where an RM request has far reaching consequences. I'd
like to believe that is the exception, though.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx1oej3u.fsf@algernon.balabit

Re: Possible release note for systems running PHP through CGI.

[Wouter Verhelst]

On Mon, Aug 20, 2012 at 03:12:14PM +0100, Steven Chamberlain wrote:
> On 20/08/12 14:35, Wouter Verhelst wrote:
> > On Mon, Aug 20, 2012 at 01:10:57PM +0100, Steven Chamberlain wrote:
> >> Yes it's possible some people rely on that behaviour, e.g. serving JPEG
> >> data from PHP scripts named like foo.php.jpeg.
> 
> Sorry, I was wrong.  For extensions like .jpeg with a known MIME type it
> does not work.  So, people are unlikely to be relying on this effect.
> 
> http://lists.debian.org/caljhhg8dd+nv2uvgjbvrtubdna3m+o1afo0bqylyfpqkhuj...@mail.gmail.com
> 
> 
> >> But some sites accept file uploads with arbitrary names, [...]
> > 
> > Don't Do That Then(TM).
> 
> Yes I very much agree...
> 
> > [...] write your upload scripts so that they
> > - Store uploads in a directory which is served by the webserver, but
> >   without allowing any kind of script execution (i.e., "Options
> >   -ExecCGI" and similar things for other scripting environments and/or
> >   webservers)
> 
> I believe -ExecCGI would work for php5-cgi but not for
> libapache2-mod-php5 (whose handler relies on MIME types).

I did say "and similar things for other scripting environments" for a
reason...

> To protect against that, I notice our drupal6 packages create an .htaccess
> file in the file uploads directory, with:
>
> > SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006

Yes. This is exactly what I described above: make sure the uploads are
in a directory that disallows any kind of script execution.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821090717.gb6...@grep.be

Re: Possible release note for systems running PHP through CGI.

[Wouter Verhelst]

On Mon, Aug 20, 2012 at 06:40:54PM +0200, Marco d'Itri wrote:
> On Aug 20, Wouter Verhelst  wrote:
> 
> > > But some sites accept file uploads with arbitrary names, perhaps
> > > expected to be a JPEG image, but actually named bar.php.jpeg and
> > > containing malicious server-side PHP which they could execute from the
> > > browser.
> > Don't Do That Then(TM).
> I see that you are not in the web hosting business. 

Nope. But we can't do the job of a person running a shared hosting
webserver, anyway, because the security issues in that area of business
are so intense that people doing shared hosting for random crap code of
their customers need to review and overhaul the default configuration in
minute detail anyway.

Again, if there's something we can do to make their jobs easier without
impacting a significant amount of our other users, I'm all for it. I
don't think this particular bit qualifies, however.

> Millions of web sites do this, so now matter how a bad practice this is 
> (and I agree that it is) we need to do everything possible to work 
> around insecure web sites.

Yes, you (a person who maintains servers in a shared hosting business)
need to do that. We (Debian) have different priorities, however.

> Also, we are talking about PHP: if educating developers were possible, 
> they would not use PHP in the first place.

*g*

[...]

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821091425.gc6...@grep.be

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Bernhard R. Link]

* Ben Hutchings  [120820 20:21]:
> I don't think we should expect other developers to spend any large
> amount of time to help with our own pet projects, except in so far as
> they benefit 'our users and the free software community', which I take
> to mean collective interests (i.e. numbers matter).  Right now, most
> package maintainers can provide more benefit to more users by working
> on bugs that affect x86, than by spending that same time investigating
> even the most serious problems on some other architecture.  Of course
> they should not stand in the way of porters and should be ready to
> answer questions and apply reasonable patches.

While I agree with the first part (people doing their pet stuff should
not distract others), I see the roles afterwards differently, though:

Most software working only on x86 is simply some pet project, with code
so broken that any newer compiler version will likely break it[1]. And
it is porters that waste their time fixing bugs in toy software, most of
the time having to cope with code so broken it is a miracle it worked
even on any compiler version on x86[2].

There is some minor number of port specific issues (though they are
of course quite frustrating as one as maintainer of a package can
do little in this case), but in my experience the numbers are similar
as with alleged bugs of compiler misoptimising code: in over 95% of
cases it is a bug in the program instead.
More often than not a serious bug in another architecture is just
a case of a serious bug that does not yet show up on the more common
architectures or only very seldom, but lurking in the dark, waiting
till it can also hit your "more users" later if ignored now.

Bernhard R. Link

[1] As a C program can give very little information, almost all
optimisations involve some step of "the rules forbid this behavior
as it would not work on some obscure architecture, so I can assume
that behavior is not the intended, so I can optimize for the other
case".
[2] Well, it's not really a miracle, but observation bias: Only that
buggy code that 'luckily' did not cause breakage on previous compiler
versions on x86 (or on sparc if you look at 15 years old code)
has survived testing by the original authors, so you only meet those,
unlikely as they are.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821093243.ga2...@client.brlink.eu

Re: Possible release note for systems running PHP through CGI.

[Konstantin Khomoutov]

On Tue, 21 Aug 2012 09:48:37 +0200
Ondřej Surý  wrote:

[...]
> >> The mime-types package has dropped non-standard definitions of
> >> PHP MIME-Types as a security measure.  Default PHP configuration
> >> for libapache2-mod-php5{filter} and php5-cgi now only serve files
> >> which have .php, .php[345] and .phtml extensions on a most right
> >> place as opposed to previous state where .php.foobar
> >> would have been interpreted.  Please read NEWS file in the PHP
> >> SAPI of your choice for further information.
> >
> > I fail to parse that "on a most right place" bit though I'm not a
> > native speaker.  If you meant that those extension specifications
> > form a minimal sane and safe subset, may be just go ahead and write
> > exactly that. ;-)
> 
> Nope I mean that the extension should be last.
> 
> E.g.  index.blah.php, but not index.php.blah.
Thanks for the explanation.

Then I suggest it to be rephrased "... extensions on the rightmost
place ...", or may be even simpler: "... php5-cgi now only serves files
which have .php, .php[345] or .phtml as their rightmost extension ...".


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120821135240.8966d86610134c36f300a...@domain007.com

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

Hi,

third summary of the proposal

 1. The new field Files-Excluded in debian/copyright contains a space
separated list of globs (as used by find and for specifying file
lists in machine readable debian/control files). The deletion
process will loop over every expression

  rm -rf ${MAIN_SOURCE_DIR}/

An example copyright file would look like this:

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: http://susy.oddbird.net/
  Repackaged, excluding non-DFSG licensed fonts and source-less
  JavaScript
Files-Excluded:
  docs/source/fonts/*
  docs/source/javascripts/jquery-1.7.1.min.js
  docs/source/javascripts/modernizr-2.5.3.min.js

 2. If files matching are contained in the source tarball this will
be repackaged except if the option --no-exclusion is given at
uscan command line or if USCAN_NO_EXCLUSION is set in
/etc/devscripts.conf or ~/.devscripts.

 3. If the tarball did not contained any of the globs in
debian/copyright::Files-Excluded it should be left untouched
(except if the repackaging is needed because of compression method
anyway if the user forces --repack).

 4. In case something was removed the version string will be appended by
'+dfsg' to express the fact that the content of the original source
was changed.

This discussion brought up additional new wishlist features for uscan:

 a) Configurable option when repacking (this is somehow related to
the suggestion above but I would like to split up this to a
different task).

 b) Uscan should be enabled to download VCS repositories (and once
it does deletion of files should be possible according to the same
method above (this is an interesting feature in principle but once
uscan is able to delete files it can do it for any download method).

 c) The suggested repackaging method was requested for non-uscan
based downloads (for instance from VCS) which might have an
influence for the final implementation as a separate tool which
could simply called by uscan (and others).

 d) Enable confirguration of compression method.  I'd consider this
an unrelated feature which also could be useful for --repack.
I admit once we are repackaging anyway it might be reasonable to
be able to influence the compression method but I also would like
to split this up to a different task.

Regarding the implementation there was some uncertainity about the
actual Perl module to use.  In the attached example script I decided to
stick to Dpkg::Control and left the code for Parse::DebControl as a
comment which could pretty easily could replace the other parser.  The
code works for me however, there might be some remaining empty
directories which I'm tempted to delete these as well via an "educated"

   find tmp -type d -empty -delete

which means I would care for deleting only those directories that became
empty by the previous removal process and not those directories which
were originally empty in the tarball.  On the other hand we might simply
go with those empty dirs that finally do not harm.

Any further hints / remarks?

Kind regards

  Andreas.

--
http://fam-tille.de
#!/usr/bin/perl   
use strict;
use warnings;

my $parsefile = 'debian/copyright';

# Dpkg::Control::Hash prefered by James McCoy (who did the last three uscan.pl edits using a debian.org e-mail address)
use Dpkg::Control::Hash;
my $data = Dpkg::Control::Hash->new();
$data->load($parsefile);

# Parse::DebControl suggested by Jonas Smedegaard
# use Parse::DebControl;
# my $parser = new Parse::DebControl(1);
# my $data = $parser->parse_file($parsefile, {discardCase=>1,singleBlock=>1,});

my $okformat = qr'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0';
my $main_source_dir = $ARGV[0] ;
die unless ($data->{'format'} =~ m{^$okformat/?$});
if ( $data->{'files-excluded'} ) {
my $nfiles_before = `find $main_source_dir | wc -l`;
foreach (grep {/\//} split /\s+/, $data->{"files-excluded"}) {
`find $main_source_dir -path "$main_source_dir/$_" -delete`;
};
foreach (grep {/^[^\/]+$/} split /\s+/, $data->{"files-excluded"}) {
`find $main_source_dir -type f -name $_ -delete`;
};
my $nfiles_after = `find $main_source_dir | wc -l`;
if ( $nfiles_before == $nfiles_after ) {
	print "Source tree remains identical - no need for repacking.\n"
}
}

Re: Enabling uscan to simply remove files from upstream source

[Jakub Wilk]

* Andreas Tille , 2012-08-21, 12:21:
The new field Files-Excluded in debian/copyright contains a space 
separated list of globs (as used by find and for specifying file lists 
in machine readable debian/control files). The deletion process will 
loop over every expression


 rm -rf ${MAIN_SOURCE_DIR}/


So wildcards in the Files-Excluded field would have different semantics 
than in the Files field. That's confusing.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821103218.ga7...@jwilk.net

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

On Tue, Aug 21, 2012 at 12:32:18PM +0200, Jakub Wilk wrote:
> * Andreas Tille , 2012-08-21, 12:21:
> >The new field Files-Excluded in debian/copyright contains a space
> >separated list of globs (as used by find and for specifying file
> >lists in machine readable debian/control files). The deletion
> >process will loop over every expression
> >
> > rm -rf ${MAIN_SOURCE_DIR}/
> 
> So wildcards in the Files-Excluded field would have different
> semantics than in the Files field. That's confusing.

In how far?

  http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field

   Filename patterns in the Files field are specified using a simplified
   shell glob syntax. Patterns are separated by whitespace.

Please propose a better wording that does not confuse you.

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821110238.ge14...@an3as.eu

Re: Enabling uscan to simply remove files from upstream source

[Simon Josefsson]

Andreas Tille  writes:

> Files-Excluded:
>   docs/source/fonts/*
>   docs/source/javascripts/jquery-1.7.1.min.js
>   docs/source/javascripts/modernizr-2.5.3.min.js
...
> Regarding the implementation there was some uncertainity about the
> actual Perl module to use.  In the attached example script I decided to
> stick to Dpkg::Control and left the code for Parse::DebControl as a
> comment which could pretty easily could replace the other parser.  The
> code works for me however, there might be some remaining empty
> directories which I'm tempted to delete these as well via an "educated"
>
>find tmp -type d -empty -delete
>
> which means I would care for deleting only those directories that became
> empty by the previous removal process and not those directories which
> were originally empty in the tarball.  On the other hand we might simply
> go with those empty dirs that finally do not harm.
>
> Any further hints / remarks?

How about resolving the empty directory problem by permitting the
Files-Excluded to match directories?  Thus, if you want to remove the
docs/source/fonts/ hierarchy, you would instead write:

Files-Excluded:
   docs/source/fonts/
   docs/source/javascripts/jquery-1.7.1.min.js
   docs/source/javascripts/modernizr-2.5.3.min.js

I'm worried that empty directories may be present for other reasons, and
removing all of them would have bad side-effects.  I would prefer to not
remove empty directories over using the find-approach above, if my
proposal is not adopted.

Thanks for doing this, I believe that having an easy way to remove files
from upstream packages will save Debian package maintainers time and
frustration.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehn0ij15@latte.josefsson.org

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

On Tue, Aug 21, 2012 at 01:25:26PM +0200, Simon Josefsson wrote:
> How about resolving the empty directory problem by permitting the
> Files-Excluded to match directories?  Thus, if you want to remove the
> docs/source/fonts/ hierarchy, you would instead write:
> 
> Files-Excluded:
>docs/source/fonts/

You can certainly do this but this would leave you with the chance
that docs/source/ remains as empty directory.
 
> I'm worried that empty directories may be present for other reasons, and
> removing all of them would have bad side-effects.  I would prefer to not
> remove empty directories over using the find-approach above, if my
> proposal is not adopted.

Sure I would never remove simply all empty directories.  This would be
insane and finally an empty directory does not really harm.

> Thanks for doing this, I believe that having an easy way to remove files
> from upstream packages will save Debian package maintainers time and
> frustration.

I'm quite positive that I get back my time I spend into this considering
how promising it is to safe a lot of time in the future. :-)

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821120644.gf14...@an3as.eu

Re: Enabling uscan to simply remove files from upstream source

[Charles Plessy]

Le Tue, Aug 21, 2012 at 12:21:21PM +0200, Andreas Tille a écrit :
> 
>  1. The new field Files-Excluded in debian/copyright contains a space
> separated list of globs (as used by find and for specifying file
> lists in machine readable debian/control files). The deletion
> process will loop over every expression
> 
>   rm -rf ${MAIN_SOURCE_DIR}/
 
>  3. If the tarball did not contained any of the globs in
> debian/copyright::Files-Excluded it should be left untouched
> (except if the repackaging is needed because of compression method
> anyway if the user forces --repack).
 
> Regarding the implementation there was some uncertainity about the
> actual Perl module to use.  In the attached example script I decided to
> stick to Dpkg::Control and left the code for Parse::DebControl as a
> comment which could pretty easily could replace the other parser.  The
> code works for me however, there might be some remaining empty
> directories which I'm tempted to delete these as well via an "educated"
> 
>find tmp -type d -empty -delete

Hi Andreas,

I would suggest to stick to the format of the Files field, and to abort with
error when files are not found, so that the Files-Excluded list stays accurate.

As suggested in http://lists.debian.org/2012081822.gt5...@jones.dk,
something similar to the following two commands would do be compatible with the
syntax of the Files field (although I am still unsure if a prefix to
 needs to be added or not).

find ${MAIN_SOURCE_DIR}/* -path  -delete

find ${MAIN_SOURCE_DIR}/* type f -name  -delete

The key limitation of the solution you propose, apart from the complexity of
introducing a new syntax, is that it can not recognise expressions such as
*/Makefile.in, as in the example of the Files field.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821121147.gc27...@falafel.plessy.net

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

Hi Charles,

On Tue, Aug 21, 2012 at 09:11:47PM +0900, Charles Plessy wrote:
> As suggested in http://lists.debian.org/2012081822.gt5...@jones.dk,
> something similar to the following two commands would do be compatible with 
> the
> syntax of the Files field (although I am still unsure if a prefix to
>  needs to be added or not).
> 
> find ${MAIN_SOURCE_DIR}/* -path  -delete
> 
> find ${MAIN_SOURCE_DIR}/* type f -name  -delete
> 
> The key limitation of the solution you propose, apart from the complexity of
> introducing a new syntax, is that it can not recognise expressions such as
> */Makefile.in, as in the example of the Files field.

I wonder what you and Jacub mean with this.  Did any of you read the
example script I attached to my mail[1].  It implements what you are
writing above.  Some testing would be nice.

I somehow afraid that my cut-n-pasto in item 1. where I said

   'rm -rf ${MAIN_SOURCE_DIR}/'  (=old, outdated, wrong)

might have lead to the confusion.  Please forget this and read

   'find ... -delete'(=what I intended to write)

(as it is realised inside the code ...)

Kind regards

Andreas.

[1] http://lists.debian.org/debian-devel/2012/08/msg00600.html

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821122216.ga23...@an3as.eu

Re: Enabling uscan to simply remove files from upstream source

[Simon Josefsson]

Andreas Tille  writes:

> On Tue, Aug 21, 2012 at 01:25:26PM +0200, Simon Josefsson wrote:
>> How about resolving the empty directory problem by permitting the
>> Files-Excluded to match directories?  Thus, if you want to remove the
>> docs/source/fonts/ hierarchy, you would instead write:
>> 
>> Files-Excluded:
>>docs/source/fonts/
>
> You can certainly do this but this would leave you with the chance
> that docs/source/ remains as empty directory.

Ah, right, I see.  Then if somebody finds that to be a problem, the
maintainer can change Files-Excluded to be docs/source/, surely?  I'm
just trying to keep the complexity low.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txvwh22g@latte.josefsson.org

Re: Enabling uscan to simply remove files from upstream source

[olivier sallou]

2012/8/21 Andreas Tille 

> Hi,
>
> third summary of the proposal
>
>  1. The new field Files-Excluded in debian/copyright contains a space
> separated list of globs (as used by find and for specifying file
> lists in machine readable debian/control files). The deletion
> process will loop over every expression
>
>   rm -rf ${MAIN_SOURCE_DIR}/
>
> An example copyright file would look like this:
>
> Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Source: http://susy.oddbird.net/
>   Repackaged, excluding non-DFSG licensed fonts and source-less
>   JavaScript
> Files-Excluded:
>   docs/source/fonts/*
>   docs/source/javascripts/jquery-1.7.1.min.js
>   docs/source/javascripts/modernizr-2.5.3.min.js
>
>  2. If files matching are contained in the source tarball this will
> be repackaged except if the option --no-exclusion is given at
> uscan command line or if USCAN_NO_EXCLUSION is set in
> /etc/devscripts.conf or ~/.devscripts.
>
>  3. If the tarball did not contained any of the globs in
> debian/copyright::Files-Excluded it should be left untouched
> (except if the repackaging is needed because of compression method
> anyway if the user forces --repack).
>

Just a remark, it would be nice in this case to get a warning/log that
some/all glob do not match to track changes in upstream tarballs (exclusion
in previous release, then not needed anymore).

Olivier


>  4. In case something was removed the version string will be appended by
> '+dfsg' to express the fact that the content of the original source
> was changed.
>
> This discussion brought up additional new wishlist features for uscan:
>
>  a) Configurable option when repacking (this is somehow related to
> the suggestion above but I would like to split up this to a
> different task).
>
>  b) Uscan should be enabled to download VCS repositories (and once
> it does deletion of files should be possible according to the same
> method above (this is an interesting feature in principle but once
> uscan is able to delete files it can do it for any download method).
>
>  c) The suggested repackaging method was requested for non-uscan
> based downloads (for instance from VCS) which might have an
> influence for the final implementation as a separate tool which
> could simply called by uscan (and others).
>
>  d) Enable confirguration of compression method.  I'd consider this
> an unrelated feature which also could be useful for --repack.
> I admit once we are repackaging anyway it might be reasonable to
> be able to influence the compression method but I also would like
> to split this up to a different task.
>
> Regarding the implementation there was some uncertainity about the
> actual Perl module to use.  In the attached example script I decided to
> stick to Dpkg::Control and left the code for Parse::DebControl as a
> comment which could pretty easily could replace the other parser.  The
> code works for me however, there might be some remaining empty
> directories which I'm tempted to delete these as well via an "educated"
>
>find tmp -type d -empty -delete
>
> which means I would care for deleting only those directories that became
> empty by the previous removal process and not those directories which
> were originally empty in the tarball.  On the other hand we might simply
> go with those empty dirs that finally do not harm.
>
> Any further hints / remarks?
>
> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>



-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: Enabling uscan to simply remove files from upstream source

[Andrew Shadura]

Hello,

On Tue, 21 Aug 2012 12:21:21 +0200
Andreas Tille  wrote:

>  2. If files matching are contained in the source tarball this will
> be repackaged except if the option --no-exclusion is given at
> uscan command line or if USCAN_NO_EXCLUSION is set in
> /etc/devscripts.conf or ~/.devscripts.

>  3. If the tarball did not contained any of the globs in
> debian/copyright::Files-Excluded it should be left untouched
> (except if the repackaging is needed because of compression method
> anyway if the user forces --repack).

By the way, how about adding something under debian/source/... to allow
automatic repacking regardless of Files-Excluded? (Or please tell me
how to repack upstream's zipball to targz automatically without having
to specify --repack every time.)

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

On Tue, Aug 21, 2012 at 03:48:33PM +0200, Andrew Shadura wrote:
> 
> By the way, how about adding something under debian/source/... to allow
> automatic repacking regardless of Files-Excluded? (Or please tell me
> how to repack upstream's zipball to targz automatically without having
> to specify --repack every time.)

I admit I fail to see the connection to the proposal if we are actually
are talking about Files-Excluded.  This somehow goes in line with
specifying the arget compression method and as I said I would like to
see this discussed under a different topic.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821141205.gb23...@an3as.eu

Re: Enabling uscan to simply remove files from upstream source

[Stefano Zacchiroli]

On Tue, Aug 21, 2012 at 12:21:21PM +0200, Andreas Tille wrote:
> Any further hints / remarks?

... just a big THANKS for helping the discussion in this thread and for
the draft code! I totally agree with Jakub that the main issue here is
that repackaging is a PITA, fixing the tools is the way to go.

Zack, enjoying pop-corns while reading a productive -devel thrad.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Enabling uscan to simply remove files from upstream source

[Andreas Tille]

On Tue, Aug 21, 2012 at 03:40:41PM +0200, olivier sallou wrote:
> 
> Just a remark, it would be nice in this case to get a warning/log that
> some/all glob do not match to track changes in upstream tarballs (exclusion
> in previous release, then not needed anymore).

Yes.  Uscan does print several messages in verbose mode.  Something like
this should be printed (that's what I planed but forgot to mention). 

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821141406.gc23...@an3as.eu

Bug#685517: ITP: libdbix-class-uuidcolumns-perl -- Implicit uuid columns

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdbix-class-uuidcolumns-perl
  Version : 0.02006
  Upstream Author : Chia-liang Kao 
* URL : http://search.cpan.org/dist/DBIx-Class-UUIDColumns/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Implicit uuid columns

DBIx::Class provides a behaviour similar to Class::DBI::UUID. It
impments globally unique columns values. When an object is created, the
columns specified are given unique IDs.

When loaded, UUIDColumns will search for a suitable uuid generation module
from the following list of supported modules:

 * Data::UUID
 * APR::UUID*
 * UUID

If no supporting module can be found, an exception will be thrown.

This module is a dependency of libhtml-formhandler-model-dbic-perl


-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201208211649.19800@debian.org

Bug#685518: ITP: libdbix-class-inflatecolumn-fs-perl -- Inflate/deflate columns to Path::Class::File objects

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdbix-class-inflatecolumn-fs-perl
  Version : 0.01007
  Upstream Author : semifor: Marc Mims 
* URL : http://search.cpan.org/dist/DBIx-Class-InflateColumn-FS/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Inflate/deflate columns to Path::Class::File objects

DBIx::Class::InflateColumn::FS provides DBIx::Class style column
inflation to a Path::Class::File object allowing file system storage
of BLOBS.

The storage path is specified with fs_column_path. Each file receives a
unique name, so the storage for all FS columns can share the same path.

Within the path specified by fs_column_path, files are stored in
sub-directories based on the first 2 characters of the unique file
names.

This module is a dependency of libhtml-formhandler-model-dbic-perl


-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201208211659.37725@debian.org

Re: Enabling uupdate to simply remove files from upstream source

[Guillem Jover]

On Tue, 2012-08-21 at 08:42:39 +0200, Andreas Tille wrote:
> On Tue, Aug 21, 2012 at 03:37:58AM +0200, Guillem Jover wrote:
> > On Mon, 2012-08-20 at 20:50:31 +0200, gregor herrmann wrote:
> > > Not sure how "official" my use of Dpkg::Control::Hash is, so maybe
> > > better stick to Jonas' proposal :)
> > 
> > That module is version >= 1.00, so it's a stable and public interface
> > that can be used by third party code w/o worrying about backward
> > incompatibilities.
> 
> I don't get what you want to express:
> 
> $ LANG=C apt-cache policy libparse-debcontrol-perl
> $ LANG=C apt-cache policy libdpkg-perl
>  
> Both modules have version >= 1.00.

Module not package, sorry, I thought it was clear from the context.

See:

  /usr/share/doc/libdpkg-perl/README.api

  $ dpkg -L libdpkg-perl|grep 'Hash\.pm'|xargs grep VERSION

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821152024.ga17...@gaara.hadrons.org

Bug#685539: ITP: msnake -- A snake game in the terminal

[mogria]

Package: wnpp
Severity: wishlist
Owner: mogria 


* Package name: msnake
  Version : 0.1.1
  Upstream Author : mogria 
* URL : http://github.com/mogria/msnake
* License : MIT
  Programming Lang: C
  Description : A snake game in the terminal

A snake game written in C using the ncurses library. It's completely based
on ASCII characters so you can play it inside the terminal. There are also
some nice additional features to it like an highscore system and fruits
(the things the snake eats) with diffrent special effects.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821175840.2400.69259.report...@debian.home

Re: Enabling uupdate to simply remove files from upstream source

[Andreas Tille]

On Tue, Aug 21, 2012 at 05:20:24PM +0200, Guillem Jover wrote:
> > I don't get what you want to express:
> > 
> > $ LANG=C apt-cache policy libparse-debcontrol-perl
> > $ LANG=C apt-cache policy libdpkg-perl
> >  
> > Both modules have version >= 1.00.
> 
> Module not package, sorry, I thought it was clear from the context.

Sorry, I'm not that involved in Perl and somehow assumed that the
package version has some relation to the module version
 
> See:
> 
>   /usr/share/doc/libdpkg-perl/README.api
> 
>   $ dpkg -L libdpkg-perl|grep 'Hash\.pm'|xargs grep VERSION

It seems my assumption is not that wrong:

dpkg -L libparse-debcontrol-perl|grep 'DebControl\.pm'|xargs grep VERSION
use vars qw($VERSION);
$VERSION = '2.005';

So your conclusion from module version >= 1.00 to stability of API
remains unclear to me because both look somehow stable.  As I have
written in my example test code:  It does not really matter which one
we prefer - both are working perfectly fine.  I'll leave the final
decision to the maintainer of uscan code who needs to accept the patch.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821190912.ge23...@an3as.eu

Bug#685545: ITP: pthreads-win32 -- POSIX threads library for Windows

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: pthreads-win32
  Version : 2.9.1+dfsg
  Upstream Author : Ross Johnson 
* URL : http://sources.redhat.com/pthreads-win32/
* License : LGPL-2.1
  Programming Lang: C
  Description : POSIX threads library for Windows

 pthreads-win32 provides an implementation of POSIX 1003.1-2001
 threads for 32- and 64-bit Windows.
 .
 This package contains both development and runtime files required to
 develop with and use pthreads using MinGW-w64.


This is required to support libgomp with MinGW-w64 (as well as being
generally useful for software using pthreads).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120821200432.8671.81932.report...@heffalump.sk2.org

Re: Enabling uscan to simply remove files from upstream source

[Charles Plessy]

Le Tue, Aug 21, 2012 at 03:48:33PM +0200, Andrew Shadura a écrit :
> 
> By the way, how about adding something under debian/source/... to allow
> automatic repacking regardless of Files-Excluded? (Or please tell me
> how to repack upstream's zipball to targz automatically without having
> to specify --repack every time.)

Hi all,

actually, wouldn't a file under debian/source (or directly under debian/) be a
better place than debian/copyright, given that there are reason for excluding
files that are not related to copyright, such as for their size, or a safeguard
against accidentally building against convenience code copies.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821223811.gc11...@falafel.plessy.net

Re: Enabling uscan to simply remove files from upstream source

[Russ Allbery]

Charles Plessy  writes:
> Le Tue, Aug 21, 2012 at 03:48:33PM +0200, Andrew Shadura a écrit :

>> By the way, how about adding something under debian/source/... to allow
>> automatic repacking regardless of Files-Excluded? (Or please tell me
>> how to repack upstream's zipball to targz automatically without having
>> to specify --repack every time.)

> actually, wouldn't a file under debian/source (or directly under
> debian/) be a better place than debian/copyright, given that there are
> reason for excluding files that are not related to copyright, such as
> for their size, or a safeguard against accidentally building against
> convenience code copies.

It would be nice to keep all of the information about the provenance of
the upstream source in one location.  Currently, that's (mostly)
debian/copyright.  If we start moving that data, perhaps we could move
*all* of it, rather than deciding every new piece of data piecemeal?

The argument for having that data in debian/copyright is, so far as I
understand it, two-fold: identifying the upstream location allows people
to review and confirm license information, and some upstream licenses may
require pointers to the original source location.  However, the latter
should, I hope, be dealt with by the license text, which we have to
reproduce anyway, and in any case are a minority.  And the former seems
like a relatively weak association with debian/copyright to me.

Personally, I care more about it being in one place than about what that
place is.  As long as people aren't going to move this information out of
debian/copyright, I want new, related information, such as excluded files,
to go in the same place so that the information isn't split.  But I'm fine
with moving it entirely.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lih7n9y3@windlord.stanford.edu

Re: Enabling uupdate to simply remove files from upstream source

[Guillem Jover]

On Tue, 2012-08-21 at 21:09:12 +0200, Andreas Tille wrote:
> On Tue, Aug 21, 2012 at 05:20:24PM +0200, Guillem Jover wrote:
> > See:
> > 
> >   /usr/share/doc/libdpkg-perl/README.api
> > 
> >   $ dpkg -L libdpkg-perl|grep 'Hash\.pm'|xargs grep VERSION
> 
> It seems my assumption is not that wrong:
> 
> dpkg -L libparse-debcontrol-perl|grep 'DebControl\.pm'|xargs grep VERSION
> use vars qw($VERSION);
> $VERSION = '2.005';
> 
> So your conclusion from module version >= 1.00 to stability of API
> remains unclear to me because both look somehow stable.  As I have
> written in my example test code:  It does not really matter which one
> we prefer - both are working perfectly fine.  I'll leave the final
> decision to the maintainer of uscan code who needs to accept the patch.

Oh, my comment was in response to gregor's doubts about his usage of
the libdpkg-perl module, and my reply was intended to clarify just
that, because there's modules in libdpkg-perl which are not public nor
stable yet, for example. I don't know anything about the expectactions
one should assume from libparse-debcontrol-perl (although I'd guess
those are pretty similar given the versioning).

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821233108.ga22...@gaara.hadrons.org

Re: Possible release note for systems running PHP through CGI.

[Christoph Anton Mitterer]

On Tue, 2012-08-21 at 09:07 +0200, Ondřej Surý wrote:
> > Maybe add just a small paragraph that the configuration of the
> > extensions has changed and php users should read the NEWS file?
> 
> That's probably sensible approach.  I have quickly drafted short
> paragraph which can be used for release notes:
Sounds good...

> which have .php, .php[345] and .phtml extensions on a most right
> place 
May I suggest to add "for security reasons" in the end?
I guess we all agreed that deliberately using "foo.php.jpeg" is in most
cases dangerous and bad style, too,... so why not teach our users a
bit?! :-)


On Tue, 2012-08-21 at 09:48 +0200, Ondřej Surý wrote:
> Nope I mean that the extension should be last.
Perhaps use the phrase "rightmost extension", or "trailing extension"?
Or even give a short example?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#685566: ITP: juju-jitsu -- external tools to enhance juju

[Clint Byrum]

Package: wnpp
Severity: wishlist
Owner: Clint Byrum 

* Package name: juju-jitsu
  Version : 0.20
  Upstream Author : Clint Byrum 
* URL : https://launchpad.net/juju-jitsu
* License : AGPL
  Programming Lang: Python, Shell
  Description : external tools to enhance juju

 Project to gather external tools for working with Juju. This includes
 visualizations, integration with other system management tools, and
 helper commands that do not belong in juju core or are in a prototype
 state and not ready for juju core.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120821235050.18636.83056.reportbug@localhost6.localdomain6

Re: Minified javascript files

[Philipp Kern]

On Mon, Aug 20, 2012 at 10:26:40AM +0200, Marco d'Itri wrote:
> Very important, anybody who deals with web scalability knows that 
> javascript minification is one of the first and easier steps you take to 
> improve performance.
> 
> The current situation is just sad, and it reflects quite badly on the 
> viability on Debian as a serious OS.

If our main problem to become a "serious" OS in your view is Javascript
minification, I'm quite happy.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Enabling uscan to simply remove files from upstream source

[Paul Wise]

On Tue, Aug 21, 2012 at 6:21 PM, Andreas Tille wrote:

> Any further hints / remarks?

In comparison to the current method for repacking (debian/rules
get-orig-source), this doesn't allow per-file-set comments about why
the file-set is being removed. I often use this to document in more
detail why I am removing files. So I view this spec as a downgrade
from what we have now.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6hhd392gepadjmxkqe3vfg5j++qg1fkdrqn4sjf9bz...@mail.gmail.com