On Thu, Sep 06, 2012 at 03:36:11PM +0200, Mehdi Dogguy wrote:
I think he was mentioning another method that helps maintainers to
automatically clean the imported tarball when importing it. IIRC,
this method has been added to git-import-orig circa DebConf9. Its
use is very simple, IMHO. Did
On 05/09/2012 22:11, Andreas Tille wrote:
On Tue, Sep 04, 2012 at 08:19:29PM +0200, Stéphane Glondu wrote:
Le 17/08/2012 13:08, Andreas Tille a écrit :
So we finally have three independently developed solutions (we
also have several instances of a debian/get-orig-source script in
Debian Med
On Tue, Sep 04, 2012 at 08:19:29PM +0200, Stéphane Glondu wrote:
Le 17/08/2012 13:08, Andreas Tille a écrit :
So we finally have three independently developed solutions (we also have
several instances of a debian/get-orig-source script in Debian Med
team) and my suggestion was just to
Le 05/09/2012 22:11, Andreas Tille a écrit :
So we finally have three independently developed solutions (we also have
several instances of a debian/get-orig-source script in Debian Med
team) and my suggestion was just to settle with a common and simple
solution. This should be pretty simple
Le 17/08/2012 13:08, Andreas Tille a écrit :
So we finally have three independently developed solutions (we also have
several instances of a debian/get-orig-source script in Debian Med
team) and my suggestion was just to settle with a common and simple
solution. This should be pretty simple
On Sat, Aug 25, 2012 at 12:27:02PM +0200, Jonas Smedegaard wrote:
1) We have the source for the parts that we ship in binary packages,
yes. We do not, however, necessarily have the actual source for the
minified files unused for binary packages yet redistributed by us in
source tarballs:
--
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/20120830225209.GA6550@pegase
On 08/29/2012 03:40 AM, Stefano Zacchiroli wrote:
The point here is whether having non-free material, which is in
distributed tarballs but hidden by dpkg-source, would constitute
inclusion of non-free material in what we call Debian. (Of course we're
talking about main here.)
Personally, I
Stefano Zacchiroli writes (Re: Minified javascript files):
The problem I see with it, is that it adds complexity to the judgement
of whether something is suitable for a source package or not (on all
actors involved: maintainer, ftp-masters, QA, bug reporters, etc.). With
something like
On Tue, Aug 28, 2012 at 11:56:53AM +0100, Ian Jackson wrote:
Stefano Zacchiroli writes (Re: Minified javascript files):
The problem I see with it, is that it adds complexity to the judgement
of whether something is suitable for a source package or not (on all
actors involved: maintainer
On 12-08-25 at 04:21pm, Pau Garcia i Quiles wrote:
On Sat, Aug 25, 2012 at 12:09 PM, Stefano Zacchiroli z...@debian.org wrote:
Another problem is that the DFSG-freeness of the material contained
in a (source) package is no longer a local property. If one day
the package containing the
On 12-08-25 at 11:29pm, Stephen Kitt wrote:
On Sat, 25 Aug 2012 12:27:02 +0200, Jonas Smedegaard d...@jones.dk
wrote:
2) Each source and binary package (+ core parts) is considered a
legal entity of its own. That's why we can refer to licensing texts
existing in common-licenses, but
Le Sun, Aug 26, 2012 at 09:22:24AM +0200, Jonas Smedegaard a écrit :
Interesting. Where is that documented? I fail to locate it in Debian
Policy 3.9.3.1 or Developers Reference 3.4.9 - the documents available
for Debian Sid.
Hi Jonas,
the Built-Using will documented in the next release
On 12-08-26 at 04:37pm, Charles Plessy wrote:
Le Sun, Aug 26, 2012 at 09:22:24AM +0200, Jonas Smedegaard a écrit :
Interesting. Where is that documented? I fail to locate it in Debian
Policy 3.9.3.1 or Developers Reference 3.4.9 - the documents available
for Debian Sid.
Hi Jonas,
On 08/26/2012 03:37 PM, Charles Plessy wrote:
Hi Jonas,
the Built-Using will documented in the next release of the Policy, thanks to
the input of the FTP team.
http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=4953fb7792b9fbe04c27dc817a2eb3cd9ab450b8
Hi Thomas,
On Sun, 26 Aug 2012 23:43:32 +0800, Thomas Goirand z...@debian.org wrote:
On 08/26/2012 03:37 PM, Charles Plessy wrote:
the Built-Using will documented in the next release of the Policy, thanks
to the input of the FTP team.
Thomas Goirand z...@debian.org writes:
If a package has Built-Using, where/how will the build dependency be
downloaded? In /usr/src/package-name-version?
Build dependencies are installed in the same location that they're always
installed; Built-Using doesn't change anything about the
On Fri, Aug 24, 2012 at 07:13:01PM -0700, Russ Allbery wrote:
The counter-argument from affected maintainers is that we *do* have the
source. It just happens to be in a different source package. We even
know that, because when we build the binary package we use the version of
the Javascript
On 12-08-24 at 07:13pm, Russ Allbery wrote:
Ben Finney ben+deb...@benfinney.id.au writes:
It seems to me that the primary objection to the presence of these
files without source is that they are then distributed as part of
Debian, in the source package. That violates our social
On Sat, Aug 25, 2012 at 12:09 PM, Stefano Zacchiroli z...@debian.org wrote:
Another problem is that the DFSG-freeness of the material contained in a
(source) package is no longer a local property. If one day the package
containing the corresponding source vanishes from the archive, unrelated
On Sat, 25 Aug 2012 12:27:02 +0200, Jonas Smedegaard d...@jones.dk wrote:
2) Each source and binary package (+ core parts) is considered a legal
entity of its own. That's why we can refer to licensing texts existing
in common-licenses, but for e.g. Apache license cannot refer to the text
Bernd Zeimetz writes (Re: Minified javascript files):
On 08/16/2012 08:59 PM, Marco d'Itri wrote:
On Aug 16, Vincent Bernat ber...@debian.org wrote:
I know this is tedious but what others think about this matter?
This is another case in which the DFSG has become a religion
Raphael Hertzog writes (Re: Minified javascript files):
I agree with you that it's useless work. But the ftpmasters believe that
Debian is made of source and binary packages and that the content of the
source package should respect DFSG #2 “The program must include source
code[...]”.
Maybe
Andreas Tille writes (Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)):
1. The new field Files-Excluded in debian/copyright contains
a space separated list of regular expressions.
The deletion process will loop over every expression
Hi,
On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
Andreas Tille writes (Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)):
1. The new field Files-Excluded in debian/copyright contains
I don't think debian/copyright should
Andreas Tille writes (Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)):
On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
Andreas Tille writes (Re: Enabling uupdate to simply remove files from
upstream source
Hi,
On Fri, Aug 24, 2012 at 04:32:05PM +0100, Ian Jackson wrote:
Andreas Tille writes (Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)):
On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
Andreas Tille writes (Re: Enabling
Andreas Tille writes (Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)):
On Fri, Aug 24, 2012 at 04:32:05PM +0100, Ian Jackson wrote:
Some of the information is machine-readable, and some is not. This is
obviously necessary in the general
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I don't think this should be fixed by changing the DFSG. The DFSG is
correct - sourceless minified js files, GFDL docs with invariant
sections, gimp-generated pixmaps without the original gimp source,
etc., are all Not Free Software.
I
Ben Finney ben+deb...@benfinney.id.au writes:
It seems to me that the primary objection to the presence of these files
without source is that they are then distributed as part of Debian, in
the source package. That violates our social contract.
The counter-argument from affected maintainers
On Aug 25, Ben Finney ben+deb...@benfinney.id.au wrote:
Upholding the social contract – that Debian, as distributed by the
Debian project, remain 100% free – is sufficient reason to remove these
files without corresponding source.
As I said, this is a religious argument.
It's OK, billions of
m...@linux.it (Marco d'Itri) writes:
On Aug 25, Ben Finney ben+deb...@benfinney.id.au wrote:
Upholding the social contract – that Debian, as distributed by the
Debian project, remain 100% free – is sufficient reason to remove these
files without corresponding source.
As I said, this is a
m...@linux.it (Marco d'Itri) writes:
On Aug 25, Ben Finney ben+deb...@benfinney.id.au wrote:
Upholding the social contract – that Debian, as distributed by the
Debian project, remain 100% free – is sufficient reason to remove these
files without corresponding source.
As I said, this is a
Russ Allbery r...@debian.org writes:
Ben Finney ben+deb...@benfinney.id.au writes:
It seems to me that the primary objection to the presence of these
files without source is that they are then distributed as part of
Debian, in the source package. That violates our social contract.
The
[About yui-compressor]
On 08/21/2012 02:49 AM, Vincent Bernat wrote:
It is not used anymore and is therefore less tested and less
trustworthy.
Sorry for the dumb questions (which are kind of conflicting each
other btw), but:
- If the only problem is testing, can't it be tested, so we know?
20.08.2012 11:33, Thomas Goirand пишет:
So, could you tell in what way yui-compressor isn't considered
not reliable enough? Does it crash? Or does it produce bad
minified scripts? In which case: in what way bad?
yui-compressor has a lot of dependencies :-)
--
To UNSUBSCRIBE, email to
Hi,
/me put on his yui-compressor maintainer hat ;)
Le 22/08/2012 13:03, Thomas Goirand a écrit :
[About yui-compressor]
On 08/21/2012 02:49 AM, Vincent Bernat wrote:
It is not used anymore and is therefore less tested and less
trustworthy.
Sorry for the dumb questions (which are kind of
Le 22/08/2012 14:52, Simon Josefsson a écrit :
Damien Raude-Morvan draz...@drazzib.com writes:
IMHO, it's obvious that yui-compressor is not - anymore - the most
efficient javascript minifier and better alternative exists. It's
simply not used anymore by big players of Javascript libs (like
Damien Raude-Morvan draz...@drazzib.com writes:
IMHO, it's obvious that yui-compressor is not - anymore - the most
efficient javascript minifier and better alternative exists. It's
simply not used anymore by big players of Javascript libs (like
jQuery) so it receives less attention (even from
On 08/17/2012 10:21 PM, Raphael Hertzog wrote:
Hi,
On Fri, 17 Aug 2012, Luca Falavigna wrote:
2012/8/17 Bernd Zeimetz be...@bzed.de:
But it usually does and also results in a source tarball which is
missing essential pieces of the software, so people who download it for
non-Debian usage
On 08/22/2012 10:09 PM, Bernd Zeimetz wrote:
Also please remember the Social Contract:
Our priorities are our users and free software.
If I would remove an otherwise free piece of software I'm not using in
the binary package just because the original, non-minified version of it
is missing, I
Thomas Goirand z...@debian.org writes:
While I can agree that removing the minified version of a javascript
script from the original source might be seen as (arguably) a little bit
extreme and annoying (but I do respect this view), I really think we
*do* need the normal non-minified version
On Wed, Aug 22, 2012 at 8:30 PM, Russ Allbery r...@debian.org wrote:
I think the debate in this thread is about whether it makes sense to
require removing the minimized version from the upstream source when we
don't install that file or otherwise use it in the binary package (because
the
Pau Garcia i Quiles pgqui...@elpauer.org writes:
While working today on Wt again, I've noticed if I were to repackage the
upstream tarball to remove jquery.min.js, I would also remove the
Doxygen-generated HTML apidox. After all, I'm also regenerating them,
therefore to me it's just a few
❦ 23 août 2012 01:01 CEST, Pau Garcia i Quiles pgqui...@elpauer.org :
I think the debate in this thread is about whether it makes sense to
require removing the minimized version from the upstream source when we
don't install that file or otherwise use it in the binary package (because
the
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
On 08/19/2012 09:49 PM, Vincent Bernat wrote:
As for
verification, having the source next to the minified version does not
guarantee anything about the minified version
Right, which is why we should build from source (eg: minify ourselves
the javascript libs).
all the more that we
don't
On Mon, Aug 20, 2012 at 12:32:28AM +0200, Jonas Smedegaard wrote:
Well, uscan makes some use of system so this could work - but I hoped
for a more Perl-ish solution (similar to the rfc822 reader in
python-debian).
Is this Perl-ish enough for you?:
:-)
#!/usr/bin/perl -w
use
On 08/20/2012 03:23 AM, Simon Josefsson wrote:
I believe differences like that are not important, compare how gcc
generate different binaries each time depending on parameters etc.
However, if a minified file is shipped that cannot be re-created at all
(due to no minifier) I don't think
On 08/20/2012 03:34 AM, Vincent Bernat wrote:
Other minifiers (like yui-compressor) are considered not
reliable enough.
Sorry that I asked you about this before reading this.
So, could you tell in what way yui-compressor isn't considered
not reliable enough? Does it crash? Or does it produce
On Aug 20, Thomas Goirand z...@debian.org wrote:
If it's that hard to produce a minified version, then shouldn't
we use the normal version? How much speed-up do we really
No.
get anyway (my wild guess: not much...)?
Very important, anybody who deals with web scalability knows that
javascript
❦ 20 août 2012 09:33 CEST, Thomas Goirand z...@debian.org :
Other minifiers (like yui-compressor) are considered not
reliable enough.
Sorry that I asked you about this before reading this.
So, could you tell in what way yui-compressor isn't considered
not reliable enough? Does it crash? Or
❦ 20 août 2012 09:31 CEST, Thomas Goirand z...@debian.org :
I believe differences like that are not important, compare how gcc
generate different binaries each time depending on parameters etc.
However, if a minified file is shipped that cannot be re-created at all
(due to no minifier) I
On 12-08-19 at 08:32am, Charles Plessy wrote:
Le Sun, Aug 19, 2012 at 12:44:44AM +0200, Jonas Smedegaard a écrit :
On 12-08-18 at 10:19pm, Andreas Tille wrote:
1. The new field Files-Excluded in debian/copyright contains
a space separated list of regular expressions.
The
On Sun, Aug 19, 2012 at 12:44:44AM +0200, Jonas Smedegaard wrote:
On 12-08-18 at 10:19pm, Andreas Tille wrote:
1. The new field Files-Excluded in debian/copyright contains
a space separated list of regular expressions.
The deletion process will loop over every expression
* Vincent Bernat ber...@debian.org [120818 21:18]:
The difference is that we need to bug upstream about a file that we
won't even use. There is no real bug (not even a licensing issue).
They are distributing files without source, so everyone else can either
not just easily modify it or verify
❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org :
The difference is that we need to bug upstream about a file that we
won't even use. There is no real bug (not even a licensing issue).
They are distributing files without source, so everyone else can either
not just easily
Vincent Bernat ber...@debian.org writes:
❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org :
They are distributing files without source, so everyone else can either
not just easily modify it or verify if it really does what it is
supposed to do. This is definitely a shortcoming in
Vincent Bernat ber...@debian.org writes:
❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org :
The difference is that we need to bug upstream about a file that we
won't even use. There is no real bug (not even a licensing issue).
They are distributing files without source, so
On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson si...@josefsson.org wrote:
As for
verification, having the source next to the minified version does not
guarantee anything about the minified version, all the more that we
don't have currently in Debian Wheezy a reliable minifier.
That seems
Pau Garcia i Quiles pgqui...@elpauer.org writes:
On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson si...@josefsson.org wrote:
As for
verification, having the source next to the minified version does not
guarantee anything about the minified version, all the more that we
don't have currently
❦ 19 août 2012 20:10 CEST, Simon Josefsson si...@josefsson.org :
They are distributing files without source, so everyone else can either
not just easily modify it or verify if it really does what it is
supposed to do. This is definitely a shortcoming in what upstream ships
and really
On 12-08-19 at 08:10pm, Simon Josefsson wrote:
Vincent Bernat ber...@debian.org writes:
❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org :
The difference is that we need to bug upstream about a file that we
won't even use. There is no real bug (not even a licensing issue).
On 12-08-18 at 12:36am, Andreas Tille wrote:
On Fri, Aug 17, 2012 at 11:03:27PM +0200, Jonas Smedegaard wrote:
I admit I'm not very experienced with Perl and reading RFC822 files -
so if somebody would help implementing this I'd be glad.
grep-dctrl -FFormat -n -sFiles-Excluded \
On Fri, 17 Aug 2012 23:48:32 +0100, Ben Hutchings b...@decadent.org.uk wrote:
On Fri, Aug 17, 2012 at 07:50:39PM +, Sam Morris wrote:
tcltrf (source)
* win/msvcrt.dll
This is part of Windows. I don't expect Debian has been granted
permission to distribute it. :)
It's the
On Fri, Aug 17, 2012 at 04:43:51PM +0600, Andrey Rahmatullin wrote:
On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote:
So yes, we have the problem for precompiled windows DLLs in a source
package.
Interesting, that issue seems rather common. Maybe a lintian check
could
* Raphael Hertzog hert...@debian.org [120817 14:04]:
That way, there's no need to strip unused RFC, minified javascript, Flash
files,
PDF without sources, etc.
Striping them away is only the forth best solution. There are some better
solutions like:
- make upstream include the sources
-
* Pau Garcia i Quiles pgqui...@elpauer.org, 2012-08-17, 13:39:
3) Make a new source package containing every jQuery version existing
in the wild, then build depend on that.
FTP Masters do not like that solution.
Interesting. Do you have any evidence for that?
--
Jakub Wilk
--
To
❦ 18 août 2012 19:46 CEST, Bernhard R. Link brl...@debian.org :
That way, there's no need to strip unused RFC, minified javascript, Flash
files,
PDF without sources, etc.
Striping them away is only the forth best solution. There are some better
solutions like:
- make upstream include
Hi,
trying to summarise suggested changes for the proposal:
1. The new field Files-Excluded in debian/copyright contains
a space separated list of regular expressions.
The deletion process will loop over every expression
rm -rf ${MAIN_SOURCE_DIR}/expression
An example
On 12-08-18 at 10:19pm, Andreas Tille wrote:
1. The new field Files-Excluded in debian/copyright contains
a space separated list of regular expressions.
The deletion process will loop over every expression
rm -rf ${MAIN_SOURCE_DIR}/expression
Copyright file format emplicitly
Le Sun, Aug 19, 2012 at 12:44:44AM +0200, Jonas Smedegaard a écrit :
On 12-08-18 at 10:19pm, Andreas Tille wrote:
1. The new field Files-Excluded in debian/copyright contains
a space separated list of regular expressions.
The deletion process will loop over every expression
On Sat, Aug 18, 2012 at 8:06 PM, Jakub Wilk jw...@debian.org wrote:
* Pau Garcia i Quiles pgqui...@elpauer.org, 2012-08-17, 13:39:
3) Make a new source package containing every jQuery version existing in
the wild, then build depend on that.
FTP Masters do not like that solution.
* Vincent Bernat ber...@debian.org, 2012-08-16, 19:24:
1. The license allows redistribution and modification of the minified
version without having the sources. Therefore, we are only dealing with
DFSG here.
While jQuery license is permissive, it does impose certain conditions[0]
on
On Thu, Aug 16, 2012 at 08:59:55PM +0200, Marco d'Itri wrote:
On Aug 16, Vincent Bernat ber...@debian.org wrote:
I know this is tedious but what others think about this matter?
This is another case in which the DFSG has become a religion to be
followed in a literalist interpretation
On 08/17/2012 09:39 AM, Jakub Wilk wrote:
* Vincent Bernat ber...@debian.org, 2012-08-16, 19:24:
1. The license allows redistribution and modification of the minified
version without having the sources. Therefore, we are only dealing
with DFSG here.
While jQuery license is permissive, it
On Fri, Aug 17, 2012 at 09:39:05AM +0200, Jakub Wilk wrote:
Part of the problem is that we lack good tools to do this extra work
for us.
As an unrelated idea which popped up when reading this: Do you think it
would be a sensible enhancement to uupdate if it could deal with a list
of files
On 08/17/2012 09:40 AM, Paul Wise wrote:
On Fri, Aug 17, 2012 at 1:24 AM, Vincent Bernat wrote:
What I didn't know until recently is that the minified version in the
source package should be removed (or the appropriate full version should
be appended).
Do we also require that for
Hi there!
On Fri, 17 Aug 2012 10:53:09 +0200, Bernd Zeimetz wrote:
On 08/17/2012 09:39 AM, Jakub Wilk wrote:
* Vincent Bernat ber...@debian.org, 2012-08-16, 19:24:
3. Repacking the original tarball just to remove those files is extra
work.
Part of the problem is that we lack good tools to
Andreas Tille wrote:
On Fri, Aug 17, 2012 at 09:39:05AM +0200, Jakub Wilk wrote:
Part of the problem is that we lack good tools to do this extra work
for us.
As an unrelated idea which popped up when reading this: Do you think it
would be a sensible enhancement to uupdate if it could
On Fri, Aug 17, 2012 at 11:55:02AM +0200, Daniel Leidert wrote:
Andreas Tille wrote:
On Fri, Aug 17, 2012 at 09:39:05AM +0200, Jakub Wilk wrote:
Part of the problem is that we lack good tools to do this extra work
for us.
As an unrelated idea which popped up when reading this: Do
On Fri, Aug 17, 2012 at 12:23:56PM +0200, Mike Hommey wrote:
On Fri, Aug 17, 2012 at 11:55:02AM +0200, Daniel Leidert wrote:
Andreas Tille wrote:
On Fri, Aug 17, 2012 at 09:39:05AM +0200, Jakub Wilk wrote:
Part of the problem is that we lack good tools to do this extra work
for us.
Thomas Goirand z...@debian.org writes:
On 08/17/2012 09:40 AM, Paul Wise wrote:
On Fri, Aug 17, 2012 at 1:24 AM, Vincent Bernat wrote:
What I didn't know until recently is that the minified version in the
source package should be removed (or the appropriate full version should
be
On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote:
So yes, we have the problem for precompiled windows DLLs in a source
package.
Interesting, that issue seems rather common. Maybe a lintian check
could alarm packagers of this?
On Fri, Aug 17, 2012 at 12:26:49PM +0200, Mike Hommey wrote:
As an unrelated idea which popped up when reading this: Do you think it
would be a sensible enhancement to uupdate if it could deal with a list
of files (wildcard strings that could be feed to `rm -rf`) which should
be
* Bernd Zeimetz be...@bzed.de, 2012-08-17, 10:53:
3. Repacking the original tarball just to remove those files is extra
work.
Part of the problem is that we lack good tools to do this extra work
for us. Really, repacking shouldn't be a tedious operation, it
shouldn't take more than 5
On Fri, Aug 17, 2012 at 1:14 PM, Jakub Wilk jw...@debian.org wrote:
3) Make a new source package containing every jQuery version existing in the
wild, then build depend on that.
FTP Masters do not like that solution.
Vincent's question was due to FTP masters complaining about the
package
On Fri, 17 Aug 2012 13:08:39 +0200, Andreas Tille wrote:
So we finally have three independently developed solutions (we also have
several instances of a debian/get-orig-source script in Debian Med
team) and
pkg-perl variant:
http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=tree
On Fri, Aug 17, 2012 at 1:08 PM, Andreas Tille andr...@an3as.eu wrote:
On Fri, Aug 17, 2012 at 12:26:49PM +0200, Mike Hommey wrote:
As an unrelated idea which popped up when reading this: Do you think
it
would be a sensible enhancement to uupdate if it could deal with a list
of
Hi,
On Fri, Aug 17, 2012 at 01:55:23PM +0200, Pau Garcia i Quiles wrote:
On Fri, Aug 17, 2012 at 1:08 PM, Andreas Tille andr...@an3as.eu wrote:
On Fri, Aug 17, 2012 at 12:26:49PM +0200, Mike Hommey wrote:
As an unrelated idea which popped up when reading this: Do you
think it
On Fri, 17 Aug 2012, Pau Garcia i Quiles wrote:
Given that I'm not using upstream's jquery.min.js at all, I wonder why
I should repackage the source package.
I agree with you that it's useless work. But the ftpmasters believe that
Debian is made of source and binary packages and that the
Hi Gregor,
On Fri, Aug 17, 2012 at 01:47:48PM +0200, gregor herrmann wrote:
On Fri, 17 Aug 2012 13:08:39 +0200, Andreas Tille wrote:
So we finally have three independently developed solutions (we also have
several instances of a debian/get-orig-source script in Debian Med
team) and
Le vendredi, 17 août 2012 14.03:38, Raphael Hertzog a écrit :
Maybe we should fix DFSG #2 to say “The program must include source code
for all the files that gets installed in the Debian binary packages [...]“.
With this modification, upstream might then include (distributable) win32
2012/8/17 Jakub Wilk jw...@debian.org:
Part of the problem is that we lack good tools to do this extra work for us.
Really, repacking shouldn't be a tedious operation, it shouldn't take more
than 5 seconds, it shouldn't require writing two dozens lines of code and
documentation. :(
ACK.
2012/8/17 Bernd Zeimetz be...@bzed.de:
But it usually does and also results in a source tarball which is
missing essential pieces of the software, so people who download it for
non-Debian usage will fail to run the shipped source just because we
removed an otherwise free piece of software.
Hi Luca,
On Fri, Aug 17, 2012 at 03:01:12PM +0200, Luca Falavigna wrote:
2012/8/17 Jakub Wilk jw...@debian.org:
Part of the problem is that we lack good tools to do this extra work for us.
Really, repacking shouldn't be a tedious operation, it shouldn't take more
than 5 seconds, it
Le 17 août 2012 14:15, Andreas Tille andr...@an3as.eu a écrit :
Hi Gregor,
On Fri, Aug 17, 2012 at 01:47:48PM +0200, gregor herrmann wrote:
On Fri, 17 Aug 2012 13:08:39 +0200, Andreas Tille wrote:
So we finally have three independently developed solutions (we also
have
several
2012/8/17 Andreas Tille andr...@an3as.eu:
http://lists.debian.org/debian-devel/2012/08/msg00397.html
and do you agree that a (enhanced) uscan could be this tool?
Sounds good for the majority of the cases, I don't think there are too
many repacked sources in the archive for which it's
On Fri, Aug 17, 2012 at 2:37 PM, Didier 'OdyX' Raboud o...@debian.org wrote:
Le vendredi, 17 août 2012 14.03:38, Raphael Hertzog a écrit :
Maybe we should fix DFSG #2 to say “The program must include source code
for all the files that gets installed in the Debian binary packages [...]“.
With
On Fri, Aug 17, 2012 at 03:12:02PM +0200, Bastien ROUCARIES wrote:
I like this
Please add a flag for specifying recompression method
Noted. On the other hand I wonder whether this should be separated from
the removal issue because we currently just do have a --repack option
and I think this
1 - 100 of 126 matches
Mail list logo
