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:
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.)
>
> Personal
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 (o
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.). Wi
Thomas Goirand writes:
> If a package has Built-Using, where/how will the build dependency be
> downloaded? In /usr/src/package-name-?
Build dependencies are installed in the same location that they're always
installed; Built-Using doesn't change anything about the functioning of
the package man
Hi Thomas,
On Sun, 26 Aug 2012 23:43:32 +0800, Thomas Goirand 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.
> >
> > http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=c
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
>
> http://bug
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.
>
>
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 relea
On 12-08-25 at 11:29pm, Stephen Kitt wrote:
> On Sat, 25 Aug 2012 12:27:02 +0200, Jonas Smedegaard
> 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.
On 12-08-25 at 04:21pm, Pau Garcia i Quiles wrote:
> On Sat, Aug 25, 2012 at 12:09 PM, Stefano Zacchiroli 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 corresp
On Sat, 25 Aug 2012 12:27:02 +0200, Jonas Smedegaard 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
> shipped wit
On Sat, Aug 25, 2012 at 12:09 PM, Stefano Zacchiroli 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
> packages,
On 12-08-24 at 07:13pm, Russ Allbery wrote:
> Ben Finney 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-
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 Javascri
m...@linux.it (Marco d'Itri) writes:
> On Aug 25, Ben Finney 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 argumen
m...@linux.it (Marco d'Itri) writes:
> On Aug 25, Ben Finney 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 argumen
On Aug 25, Ben Finney 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 people have a faith and y
Ben Finney 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 is that we *do* have the
Ian Jackson 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 agree entirely with that paragra
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 mu
Bernd Zeimetz writes ("Re: Minified javascript files"):
> On 08/16/2012 08:59 PM, Marco d'Itri wrote:
> > On Aug 16, Vincent Bernat wrote:
> >
> >> I know this is tedious but what others think about this matter?
> > This is another case in which the D
❦ 23 août 2012 01:01 CEST, Pau Garcia i Quiles :
>> 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 binary package
Pau Garcia i Quiles 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 thousands of useless
On Wed, Aug 22, 2012 at 8:30 PM, Russ Allbery 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 binary package d
Thomas Goirand 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 of every scri
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 missi
On 08/17/2012 10:21 PM, Raphael Hertzog wrote:
> Hi,
>
> On Fri, 17 Aug 2012, Luca Falavigna wrote:
>> 2012/8/17 Bernd Zeimetz :
>>> 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 wi
Damien Raude-Morvan 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 Yahoo for YUI
Le 22/08/2012 14:52, Simon Josefsson a écrit :
Damien Raude-Morvan 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 receiv
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 c
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 debi
[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 kno
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 o
❦ 20 août 2012 09:31 CEST, Thomas Goirand :
>> 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 thi
❦ 20 août 2012 09:33 CEST, Thomas Goirand :
>> 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
On Aug 20, Thomas Goirand 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 minificati
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 b
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 shi
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
On 12-08-19 at 08:10pm, Simon Josefsson wrote:
> Vincent Bernat writes:
>
> > ❦ 19 août 2012 15:11 CEST, "Bernhard R. Link" :
> >
> >>> 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
❦ 19 août 2012 20:10 CEST, Simon Josefsson :
>>> 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 something you s
Pau Garcia i Quiles writes:
> On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson 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 reliabl
On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson 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 problemati
Vincent Bernat writes:
> ❦ 19 août 2012 15:11 CEST, "Bernhard R. Link" :
>
>>> 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
Vincent Bernat writes:
> ❦ 19 août 2012 15:11 CEST, "Bernhard R. Link" :
>> 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
>> an
❦ 19 août 2012 15:11 CEST, "Bernhard R. Link" :
>> 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
* Vincent Bernat [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 if it really does
On Sat, Aug 18, 2012 at 8:06 PM, Jakub Wilk wrote:
> * Pau Garcia i Quiles , 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 evid
❦ 18 août 2012 19:46 CEST, "Bernhard R. Link" :
>> 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 sou
* Pau Garcia i Quiles , 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 UNSUBSCRIBE, email to debian-de
* Raphael Hertzog [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
- include the sources
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 che
On Fri, 17 Aug 2012 23:48:32 +0100, Ben Hutchings 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 run-time lib
Le Fri, Aug 17, 2012 at 01:19:05PM +0800, Thomas Goirand a écrit :
> On 08/17/2012 01:24 AM, Vincent Bernat wrote:
> > 3. Repacking the original tarball just to remove those files is extra
> > work.
> >
> Yeah, just annoying everyone for a minified jquery in upstream
> tarball is, to me, a
On Fri, Aug 17, 2012 at 07:50:39PM +, Sam Morris wrote:
> On Fri, 17 Aug 2012 16:43:51 +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.
> >>
> >>
* Pau Garcia i Quiles , 2012-08-17, 22:35:
http://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html
This includes:
tcltrf (source)
* win/msvcrt.dll
This is part of Windows. I don't expect Debian has been granted
permission to distribute it. :)
Are you sure it's not wine's
On Fri, 17 Aug 2012 22:35:07 +0200, Pau Garcia i Quiles wrote:
> On Fri, Aug 17, 2012 at 9:50 PM, Sam Morris 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
cou
On Fri, Aug 17, 2012 at 9:50 PM, Sam Morris 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?
>> http://lintian.debian.org/tags/source-cont
Hi,
On Fri, 17 Aug 2012, Luca Falavigna wrote:
> 2012/8/17 Bernd Zeimetz :
> > 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
> >
On Fri, 17 Aug 2012 16:43:51 +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
>> cou
On 12-08-17 at 07:19pm, Vincent Bernat wrote:
> ❦ 17 août 2012 09:39 CEST, Jakub Wilk :
> > [0] “The above copyright notice and this permission notice shall be
> > included in all copies or substantial portions of the Software.”
>
> That's true that the permission notice is not included in the
❦ 17 août 2012 09:39 CEST, Jakub Wilk :
>> 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 distributors
On Fri, Aug 17, 2012 at 2:37 PM, Didier 'OdyX' Raboud 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 this modi
2012/8/17 Andreas Tille :
>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 impossible to
provide
Hi Luca,
On Fri, Aug 17, 2012 at 03:01:12PM +0200, Luca Falavigna wrote:
> 2012/8/17 Jakub Wilk :
> > 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
2012/8/17 Bernd Zeimetz :
> 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.
This does no
2012/8/17 Jakub Wilk :
> 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.
Should we write a
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
executab
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 conte
On Fri, Aug 17, 2012 at 1:14 PM, Jakub Wilk 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 'witty', which I ma
* Bernd Zeimetz , 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 seconds, it shouldn't
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?
http://lintian.debian.org/tags/source-cont
Thomas Goirand 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 append
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 , 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 do t
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
On 08/17/2012 09:39 AM, Jakub Wilk wrote:
> * Vincent Bernat , 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
On Thu, Aug 16, 2012 at 08:59:55PM +0200, Marco d'Itri wrote:
> On Aug 16, Vincent Bernat 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 instead of a tool
* Vincent Bernat , 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 distributors. In my experi
On 08/17/2012 01:24 AM, Vincent Bernat wrote:
> 3. Repacking the original tarball just to remove those files is extra
> work.
>
Yeah, just annoying everyone for a minified jquery in upstream
tarball is, to me, a bit too extreme to my taste as well, as we all know
where it's coming from, and
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 say, precompiled DLLs of GTK+ or SDL for
Windows pl
Le Thu, Aug 16, 2012 at 07:24:32PM +0200, Vincent Bernat a écrit :
>
> On the behalf of the FTP master team, Ansgar Burchardt explained me why
> the dependency to libjs-jquery is not enough to fulfill the "provide the
> sources" part since the source in the archive may not correspond to the
> vers
On 08/16/2012 08:59 PM, Marco d'Itri wrote:
> On Aug 16, Vincent Bernat 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 instead of a tool to be used
> for th
On Aug 16, Vincent Bernat 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 instead of a tool to be used
for the purpose of advancing software freedom.
--
ciao,
Mar
Russ Allbery writes:
> Vincent Bernat writes:
>> On the behalf of the FTP master team, Ansgar Burchardt explained me why
>> the dependency to libjs-jquery is not enough to fulfill the "provide
>> the sources" part since the source in the archive may not correspond to
>> the version included in t
Vincent Bernat writes:
> On the behalf of the FTP master team, Ansgar Burchardt explained me why
> the dependency to libjs-jquery is not enough to fulfill the "provide the
> sources" part since the source in the archive may not correspond to the
> version included in the upstream tarball.
> I ag
86 matches
Mail list logo
