On 2014-03-26 02:49, Paul Wise wrote:
On Wed, Mar 26, 2014 at 6:16 AM, Philipp Kern wrote:
To be honest I'd rather like to see a "ruling" which is codified in a
policy
than random guesswork we do on -devel from observing FTP masters'
actions.
This is not Mao.
Figuring out what the source is a
On Wed, Mar 26, 2014 at 6:16 AM, Philipp Kern wrote:
> To be honest I'd rather like to see a "ruling" which is codified in a policy
> than random guesswork we do on -devel from observing FTP masters' actions.
> This is not Mao.
Figuring out what the source is and where it is can be hard, even for
On Tue, Mar 25, 2014 at 11:16:12PM +0100, Philipp Kern wrote:
> To be honest I'd rather like to see a "ruling" which is codified in
> a policy than random guesswork we do on -devel from observing FTP
> masters' actions. This is not Mao.
There was an ftpteam meeting last week, and this was discusse
On 2014-03-24 17:23, Thorsten Glaser wrote:
I don’t have the source of it at hand (and IANAftpmaster), but
right now, the answer is NO because the promise of the DFSG and
surrounding documents also extends to not just the source pak-
kages but also the distfiles (*.orig.tar.*) isolated. Basically
Joachim Breitner debian.org> writes:
> The minified file contains a copyright header, and the license is MIT,
> so I believe shipping jquery-1.11.0.min.js without query-1.11.0.js is
It’s legal, but it’s not allowed because it breaks the *promise* we
(Debian) do to our users/downstreams.
That’s
Joachim Breitner debian.org> writes:
> Before this thread gets too long and we hear too many opinion from
> people don’t have a say in this (like me), I’d like to hear an official
> statement from the ftp-team on the question:
>
> Does Debian tolerate files in upstream tarballs that are
]] Russ Allbery
> Lars Wirzenius writes:
> > On Tue, Mar 18, 2014 at 01:20:20AM +0100, Matthias Urlichs wrote:
>
> >> Actually, if we really want to strictly +literally interpret the DFSG,
> >> then yes, tarballs (or the directory trees they represent) are no
> >> longer "the preferred form of
❦ 18 mars 2014 16:00 CET, Guillem Jover :
> On Thu, 2014-03-13 at 14:21:22 +0900, Charles Plessy wrote:
>> On the other hand, the "upstream" tarballs are becoming temporary cruft that
>> are not the preferred form for modification because they do not contain the
>> typical revision information a
* Paul Tagliamonte , 2014-03-18, 09:13:
That would work only if the embedded copy was the same version as the
packaged one. And there are lots of jQuery versions in the wild.
In <20120817111437.ga8...@jwilk.net> I suggested making a package that
would bundle all the needed sources, but my prop
Lars Wirzenius writes:
> On Tue, Mar 18, 2014 at 01:20:20AM +0100, Matthias Urlichs wrote:
>> Actually, if we really want to strictly +literally interpret the DFSG,
>> then yes, tarballs (or the directory trees they represent) are no
>> longer "the preferred form of modification" when everybody u
[ Lars just covered some of this in another part of the thread, but as
I had this drafted already, I'm sending it anyway. ]
On Thu, 2014-03-13 at 14:21:22 +0900, Charles Plessy wrote:
> On the other hand, the "upstream" tarballs are becoming temporary cruft that
> are not the preferred form for
On Wed, Mar 12, 2014 at 09:57:50PM +0100, Jakub Wilk wrote:
> That would work only if the embedded copy was the same version as
> the packaged one. And there are lots of jQuery versions in the wild.
>
> In <20120817111437.ga8...@jwilk.net> I suggested making a package
> that would bundle all the n
* Thomas Goirand , 2014-03-15, 14:09:
In <20120817111437.ga8...@jwilk.net> I suggested making a package that
would bundle all the needed sources, but my proposal wasn't met with
enthusiasm.
I think it's a good idea, however, instead of packaging all version
possible, would it be possible to i
On 03/18/2014 01:20, Matthias Urlichs wrote:
> Scott Kitterman:
>> Oh. So you think to meet the DFSG we need to provide a copy of the VCS
>> repository since the tarball isn't the preferred form of modification?
>
> Actually, if we really want to strictly +literally interpret the DFSG,
> then ye
On Tue, Mar 18, 2014 at 01:20:20AM +0100, Matthias Urlichs wrote:
> Actually, if we really want to strictly +literally interpret the DFSG,
> then yes, tarballs (or the directory trees they represent) are no longer
> "the preferred form of modification" when everybody uses a DVCS like git.
I don't
Hi,
Scott Kitterman:
> Oh. So you think to meet the DFSG we need to provide a copy of the VCS
> repository since the tarball isn't the preferred form of modification?
Actually, if we really want to strictly +literally interpret the DFSG,
then yes, tarballs (or the directory trees they represent
On 03/13/2014 04:57 AM, Jakub Wilk wrote:
> * Philipp Kern , 2014-03-12, 21:11:
>> I still think it should be acceptable given that it's an open source
>> project, it's clearly versioned from which source it comes and we
>> check by not using the file that no changes have been done to the
>> minifi
Le Sat, Mar 15, 2014 at 11:47:44AM +0800, Paul Wise a écrit :
>
> I note that the ftpmasters currently reject packages that are missing
> source for non-programmatic works (REJECT-FAQ explicitly mentions
> PS/PDF documentation). So the current archive requirements are in
> practice stricter than t
On Sat, Mar 15, 2014 at 11:24:19AM +0800, Paul Wise wrote:
> On Sat, Mar 15, 2014 at 11:02 AM, Steve Langasek wrote:
> > That was a conscious decision on the part of the project to revise the text
> > of the Social Contract. That vote did *not* replace the use of the word
> > "program" in DFSG#2
On Sat, Mar 15, 2014 at 11:29 AM, Russ Allbery wrote:
> Paul Wise writes:
>
>> As far as I can tell, not modifying the DSFG at the same time was an
>> oversight. Fixing that mistake was attempted in a later GR but that was
>> blocked with a narrow margin.
>
>> https://www.debian.org/vote/2006/vote_
Paul Wise writes:
> As far as I can tell, not modifying the DSFG at the same time was an
> oversight. Fixing that mistake was attempted in a later GR but that was
> blocked with a narrow margin.
> https://www.debian.org/vote/2006/vote_004
That GR proposal does not require source for non-program
On Sat, Mar 15, 2014 at 11:02 AM, Steve Langasek wrote:
> That was a conscious decision on the part of the project to revise the text
> of the Social Contract. That vote did *not* replace the use of the word
> "program" in DFSG#2 with the word "software". It is incorrect to infer from
> this vot
Steve Langasek writes:
> On Sat, Mar 15, 2014 at 10:50:13AM +0800, Paul Wise wrote:
>> I guess you are referring to the GR that clarified the Social Contract
>> to read "work" instead of "software".
>> https://www.debian.org/vote/2004/vote_003
> That was a conscious decision on the part of the
On Sat, Mar 15, 2014 at 10:50:13AM +0800, Paul Wise wrote:
> On Sat, Mar 15, 2014 at 10:20 AM, Steve Langasek wrote:
> > A PNG is not a program.
> Depends on your definition of program.
Yes. If you use the English definition of the word "program", then it's not
a program. But I guess if you ma
On Sat, Mar 15, 2014 at 10:20 AM, Steve Langasek wrote:
> A PNG is not a program.
Depends on your definition of program. PNG files are programs that run
in a PNG decoder. ELF binaries aren't programs, they are just data
interpreted by CPUs.
> There is no source required for a PNG under DFSG #2
On 03/13/2014 11:45 PM, Vincent Bernat wrote:
> ❦ 12 mars 2014 22:26 CET, Ben Finney :
>
>>> The javascript world is difficult to deal with. They like embedded
>>> copies, they may not really care about API/ABI stability, even for big
>>> projects. Those are difficulties that we already have to
On Sat, Mar 15, 2014 at 10:07:22AM +0800, Paul Wise wrote:
> On Thu, Mar 13, 2014 at 8:02 PM, Craig Small wrote:
> > FWIW, I think the concept of a graphic needing its source is also bogus.
> > It means that the upstream have to hang onto some script they might of
> > used once years ago for.. wha
On Thu, Mar 13, 2014 at 8:02 PM, Craig Small wrote:
> FWIW, I think the concept of a graphic needing its source is also bogus.
> It means that the upstream have to hang onto some script they might of
> used once years ago for.. what reason?
> To give you a concrete example, I made the SPI logo (an
On Thu, 13 Mar 2014, Craig Small wrote:
> It means that the upstream have to hang onto some script they might of
> used once years ago for.. what reason?
No, that's not what it means. The whole point of requiring source is to
stop artificially inhibiting user's (and Debian's) ability to modify a
w
❦ 12 mars 2014 22:26 CET, Ben Finney :
>> The javascript world is difficult to deal with. They like embedded
>> copies, they may not really care about API/ABI stability, even for big
>> projects. Those are difficulties that we already have to deal with. We
>> already work around them by using De
On Wed, Mar 12, 2014 at 12:58:51PM +, Ian Jackson wrote:
> I have a completely different approach to the DFSG. The DFSG is not
> carefully drafted document and it doesn't stand up to detailed
> legalistic interpretation. Rather, it is a statement of aims and
> values.
That was certainly how I
On 03/13/2014 01:37 PM, Scott Kitterman wrote:
> On Thursday, March 13, 2014 14:21:22 Charles Plessy wrote:
>> Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit :
>>> What percentage of free software in Debian main do you expect then?
>>
>> Hi Scott,
>>
>> I expect 100 % in the bina
On 03/13/2014 01:21 PM, Charles Plessy wrote:
> Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit :
>>
>> What percentage of free software in Debian main do you expect then?
>
> Hi Scott,
>
> I expect 100 % in the binary packages.
>
> On the other hand, the "upstream" tarballs ar
Scott Kitterman writes:
> I think it's black and white if it's a bug. If it's worth investing the
> effort in fixing the bug is all kinds of shades of gray.
I don't think that's a horribly useful distinction for this conversation,
which is about what will be accepted into the archive or not. (
On Wednesday, March 12, 2014 22:23:02 Russ Allbery wrote:
> Scott Kitterman writes:
> > On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote:
> >> On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote:
> >>> SC§1 states that we want Debian to remain 100% free; the common
> >>> interpret
On Thursday, March 13, 2014 14:21:22 Charles Plessy wrote:
> Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit :
> > What percentage of free software in Debian main do you expect then?
>
> Hi Scott,
>
> I expect 100 % in the binary packages.
>
> On the other hand, the "upstream"
Scott Kitterman writes:
> On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote:
>> On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote:
>>> SC§1 states that we want Debian to remain 100% free; the common
>>> interpretation of that is that one can download anything from Debian
>>> mai
Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit :
>
> What percentage of free software in Debian main do you expect then?
Hi Scott,
I expect 100 % in the binary packages.
On the other hand, the "upstream" tarballs are becoming temporary cruft that
are not the preferred form fo
On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote:
> On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote:
> > Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit :
> > > If an interpretation of the DFSG suggests that we should be doing work
> > > which does not further those obj
On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote:
> Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit :
> > If an interpretation of the DFSG suggests that we should be doing work
> > which does not further those objectives, then I think that
> > interpretation is a misreading.
>
> S
Vincent Bernat writes:
> [A bundled, source version of the library] will just go out of sync.
> For upstream, the preferred form of "modification" is the minified
> version (modification is merely the update to a new version).
Yes, the cause of that is that upstream doesn't treat these files as
* Philipp Kern , 2014-03-12, 21:11:
I still think it should be acceptable given that it's an open source
project, it's clearly versioned from which source it comes and we
check by not using the file that no changes have been done to the
minification. I guess we could even go one step further an
❦ 12 mars 2014 21:11 CET, Philipp Kern :
> how bad would it be for those upstreams to just include an unused copy
> of the non-minified version? Clearly it'd never be used by anything in
> the upstream packaging because you almost always want to ship minified
> JS to browsers in production. But
On Wed, Mar 12, 2014 at 1:11 PM, Philipp Kern wrote:
> Hi,
>
>
> On 2014-03-11 00:09, Joachim Breitner wrote:
>>
>> Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern:
>>>
>>> as long as the code in question is not under a license that requires the
>>> full, non-minified source to be repr
Hi,
On 2014-03-11 00:09, Joachim Breitner wrote:
Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern:
as long as the code in question is not under a license that requires
the
full, non-minified source to be reproduced and if the copyright
notices
and license terms as potentially requir
On 12.03.2014 16:47, Paul Tagliamonte wrote:
> Also archive size, for what it's worth.
>
> Shipping GBs of DLLs, minified JS and other sourceless nonsense
> is totally a waste of everyone's time and storage space.
this is not a good argument, the best you can usually get out of
upstreams it to s
Quoting Ian Jackson (2014-03-12 13:58:51)
> If an interpretation of the DFSG suggests that we should be doing work
> which does not further those objectives, then I think that
> interpretation is a misreading. Conversely, if an interpretation of
> the DFSG suggests that we should tolerate a sit
Also archive size, for what it's worth.
Shipping GBs of DLLs, minified JS and other sourceless nonsense
is totally a waste of everyone's time and storage space.
On Wed, Mar 12, 2014 at 11:44 AM, Don Armstrong wrote:
> On Wed, 12 Mar 2014, Ian Jackson wrote:
> > No-one has come up with any prac
On Wed, 12 Mar 2014, Ian Jackson wrote:
> No-one has come up with any practical benefit from the repacking of
> source tarballs to remove nonfree files.
Non-free files in source files are distributed by Debian. They cannot be
modified, inspected, or easily patched. Removing them assures us that
th
Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit :
> Didier 'OdyX' Raboud writes ("Re: jquery debate with upstream"):
> > I disagree: I don't think it's tolerable to ship a .exe freeware [0]
> > in a source package in main, just because it hap
Didier 'OdyX' Raboud writes ("Re: jquery debate with upstream"):
> I disagree: I don't think it's tolerable to ship a .exe freeware [0] in
> a source package in main, just because it happens to be redistributable;
> in my reading, considering that the &quo
Le mardi, 11 mars 2014, 19.02:55 Ian Jackson a écrit :
> Thomas Goirand writes ("Re: jquery debate with upstream"):
> > In one of my package, I had openssl.dll in the source tarball (it
> > was of course removed later on).
> >
> > Would you consider it ok a
On Tue, Mar 11, 2014 at 02:34:47PM -0400, Paul Tagliamonte wrote:
> You may think a line is somewhere, but the DFSG is interpreted by the
> ftp-masters, so the question isn't what paultag or ian says, but what
> the ftp-masters say :)
I don't accept that. The interpretation must come from a conc
On 03/12/2014 05:16 AM, Sune Vuorela wrote:
> On 2014-03-11, Paul Tagliamonte wrote:
>> On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
>>> I don't think this is a significant breach of the DFSG.
>>
>> Ah, but you do acknowledge this *is* a breach, even if a small one.
>>
>>
>> So thi
Sune Vuorela writes:
> If I had to disregard the DFSG in some cases, I'd rather see rfc files
> in our files than sourceless javascripts.
If they're in the source packages but not installed, I believe this is an
equivalent case, yes. And it would certainly make some packages easier to
manage (o
Le Tue, Mar 11, 2014 at 08:14:24PM +, Jonathan Dowland a écrit :
> On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
> > We should stop this makework and get on with doing something useful.
>
> Thanks for providing me with my 'word of the day' (makework) which seems
> to me to embod
Hi,
Am Dienstag, den 11.03.2014, 19:02 + schrieb Ian Jackson:
> I think that if we want a more convenient and reliable way to avoid
> them being used during the build, we should have a way to make
> dpkg-source remove the files from the tree as it unpacks the source.
debian/clean is sufficien
On 2014-03-11, Paul Tagliamonte wrote:
> On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
>> I don't think this is a significant breach of the DFSG.
>
> Ah, but you do acknowledge this *is* a breach, even if a small one.
>
>
> So this comes down to where the line is, like I said.
"As
On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
> We should stop this makework and get on with doing something useful.
Thanks for providing me with my 'word of the day' (makework) which seems
to me to embody a growing collection of activities in Debian in modern
times.
--
To UNSUBS
Thomas Goirand writes ("Re: jquery debate with upstream"):
> In one of my package, I had openssl.dll in the source tarball (it was of
> course removed later on).
>
> Would you consider it ok as well to have it in a source package, as long
> as it's not used duri
On Tue, 11 Mar 2014, Ian Jackson wrote:
> Repackaging these tarballs for this reason is utterly pointless.
> No-one has been able to explain what the benefit is, to anyone. All we
> get when we challenge it is, I'm sad to say, vague and abstract
> responses like this one.
The point of repacking th
[not ftpteam]
On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote:
> I don't think this is a significant breach of the DFSG.
Ah, but you do acknowledge this *is* a breach, even if a small one.
So this comes down to where the line is, like I said.
You may think a line is somewhere, but
Paul Tagliamonte writes ("Re: jquery debate with upstream"):
> On Tue, Mar 11, 2014 at 03:16:14PM +, Ian Jackson wrote:
> > You have conspicuously failed to answer Jonas's question. What
> > objective does removing these files and repacking the tarballs serve ?
On 03/11/2014 11:16 PM, Ian Jackson wrote:
>> Debian have a certain definition of Freedoms [...]
> Whose freedom is impaired, and in what way, by the presence of these
> useless but ignored files in the tarball ?
In one of my package, I had openssl.dll in the source tarball (it was of
course remov
[ not as ftpteam -- man, I'm saying this a lot lately ]
On Tue, Mar 11, 2014 at 03:16:14PM +, Ian Jackson wrote:
> You have conspicuously failed to answer Jonas's question. What
> objective does removing these files and repacking the tarballs serve ?
We distribute source. The question is, do
Jonas Smedegaard writes ("Re: jquery debate with upstream"):
> Quoting Steve M. Robbins (2014-03-11 07:11:36)
> > I can understand that it is nicer if upstream can be persuaded to
> > clean things up and not do either of the above. I also realize that
> > som
Quoting Steve M. Robbins (2014-03-11 07:11:36)
> On March 11, 2014 10:50:10 AM Paul Wise wrote:
>> On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote:
>>> I'd love to see clarification of the ftp-team's position on
>>> obfuscated files in source packages, preferably in an official
>>> location for
On March 11, 2014 10:50:10 AM Paul Wise wrote:
> On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote:
> > I'd love to see clarification of the ftp-team's position on obfuscated
> > files in source packages, preferably in an official location for future
> > reference.
Recalling that the context of th
On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote:
> I'd love to see clarification of the ftp-team's position on obfuscated
> files in source packages, preferably in an official location for future
> reference.
I quote from [1]:
Source missing
Your package contains files that need source but do
Joachim Breitner writes:
> So you’d say it is acceptable to leave jquery-1.11.0.min.js in a tarball
> if it is unused (e.g. if it is removed in the clean target, and possibly
> documented in README.Source)? Can maybe someone from the ftp-team
> confirm this?
My understanding (as someone who is n
Hi,
Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern:
> as long as the code in question is not under a license that requires the
> full, non-minified source to be reproduced and if the copyright notices
> and license terms as potentially required by the license are present, I
> don't
71 matches
Mail list logo
