Re: Non-source Javascript files in upstream source
❦ 8 mai 2014 12:21 +1000, Ben Finney b...@benfinney.id.au : When I get some time to work on my packages and I see this: http://lintian.debian.org/maintainer/pkg-roundcube-maintain...@lists.alioth.debian.org.html#roundcube Yes, it's disheartening to see such files in a source distribution from upstream. Fortunately the solution isn't complex. From the upstream point of view, people want to be able to install that by just dropping the source files into the appropriate directory. Upstream has already puts a lot of effort to accomodate us by always providing a GPL version of the packages (without most of the embedded copies). Well, I say Let's do something else, I'll have another look later. I am using URL:https://wiki.debian.org/BenFinney/software/repack for another package, to remove non-source JavaScript files from the Debian source package. I have now re-worked it for the ‘roundcube’ package and submitted it in patches for bug#736782. Thanks for that. As pointed in the bug report, jQuery UI has been modified by roundcube authors (I don't know exactly how, just putting the same version from Debian introduced some bugs) and jstz.min.js has no source. Just to say that this takes time not just because I am too lazy. -- /* Fuck me gently with a chainsaw... */ 2.0.38 /usr/src/linux/arch/sparc/kernel/ptrace.c signature.asc Description: PGP signature
Re: Non-source Javascript files in upstream source
Vincent Bernat ber...@debian.org writes: ❦ 8 mai 2014 12:21 +1000, Ben Finney b...@benfinney.id.au : I am using URL:https://wiki.debian.org/BenFinney/software/repack for another package, to remove non-source JavaScript files from the Debian source package. I have now re-worked it for the ‘roundcube’ package and submitted it in patches for bug#736782. Thanks for that. You're welcome; I tried to make that program robust and easily-adapted to most packages that need it. I hope it's useful to other package maintainers. As pointed in the bug report, jQuery UI has been modified by roundcube authors (I don't know exactly how, just putting the same version from Debian introduced some bugs) and jstz.min.js has no source. Okay. Those both sound like problems to be solved before the Debian package source will meet the standard set by the ftpmaster team. Just to say that this takes time not just because I am too lazy. Yes, for many packages, ensuring the source is distributed as entirely free software does take time. I definitely sympathise with that. -- \ “The long-term solution to mountains of waste is not more | `\ landfill sites but fewer shopping centres.” —Clive Hamilton, | _o__)_Affluenza_, 2005 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85lhucbsi2@benfinney.id.au
Re: Non-source Javascript files in upstream source
Dear Ben, Am Donnerstag, den 08.05.2014, 12:21 +1000 schrieb Ben Finney: Well, I say Let's do something else, I'll have another look later. I am using URL:https://wiki.debian.org/BenFinney/software/repack for another package, to remove non-source JavaScript files from the Debian source package. the same functionality is provided by uscan (via mk-origtargz) in the next devscritps release, based on Files-Excluded fields in debian/copyright. Would you mind evaluating whether that does all that you need? (debcheckout devscripts and build and install usually). We need this integrated seemlessly in our tools to not waste more developer time than necessary. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Non-source Javascript files in upstream source
Wouter Verhelst w...@uter.be writes: [W]hile I agree that this is a problem for things like precompiled Windows binaries, I'm not so sure when it regards convenience copies of minified javascript libraries. After all, there are many other packages whose upstream source ships with convenience copies of other code, and we don't consider those to be problems. That is apparently conflating two distinct issues: A third-party work in *source* form in the Debian upstream source is not in itself a problem: if it is known to be free software, we can confidently ship it in the Debian source package as a work in source form. A work in *non-source* form in the Debian source package is more likely to be a problem. If we cannot verify the corresponding source is also distributed in Debian, we can't state with confidence that we have it; without corresponding source for that work, the package will violate the DFSG. The issue being discussed is not convenience copies of code (problematic in the binary package, but AFAIK neutral in the source package). The issue rather is non-source works in Debian source packages. We now have the ftpmaster team's clarification that the Debian source package is part of Debian; and that such works in non-source form, without corresponding source known to be in Debian, are not acceptable in the Debian source package. If a package will work equally well when using the Debian-packaged version of a javascript library rather than using the shipped convenience copy of the said library (as proven by using a symlink and a dependency to the relevant file and package rather than shipping the convenience copy in the binary package) The Debian source package also needs to be free software. If a non-source work can't be demonstrated to have its source also in Debian, then distributing that work in the Debian source package threatens breach of the Social Contract to recipients of Debian. then the source requirements for all relevant code is satisfied; it's just that they're done so by another source package. Sure. Shipping the source for a work in another Debian source package is fine; the problem is for the package maintainer to assert that *is* the corresponding source for a particular work. We should not, IMO, accept such an assertion without an independently verifiable guarantee that can be automated for each release of the source package. I can see two ways for Debian package maintainers to make that guarantee with confidence: * Automatically perform a hash check of the non-source work against a specified other non-source work in Debian, for which we have a reliable guarantee the corresponding source *is* in Debian; and automatically reject any release of the package if the hash does not match. This pushes the question of how to make the guarantee of corresponding source to yet another package. Such verification also doesn't AFAIK have any systematic automated support at present. It also sounds to me like more work and error-prone complexity than the second option: * Discard the non-source work when re-packing the upstream source, to ensure it does not appear in the Debian source package. If the non-source form is needed for the binary package, re-generate it at build time from that work's corresponding source. Distributing the non-source work in the Debian source package, without automatic verification each release that its corresponding source is in Debian, leaves us wide open to the divergence of that work from what we hope is the corresponding source, and thereby breaking our promises. -- \ “I do not believe in forgiveness as it is preached by the | `\church. We do not need the forgiveness of God, but of each | _o__)other and of ourselves.” —Robert G. Ingersoll | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mweudpkj@benfinney.id.au
Re: Non-source Javascript files in upstream source
Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte: If you were to 'update' the image, how would you do it? What things would you need? Include that. Think about what you'd need when you fork the project. Does that mean I should include wget? Most minified externally-produced javascript files are just downloaded verbatim off the web. I agree with the sentiment that we should provide source in Debian for everything that's actually useful for our users. If a dependency and a symlink exists, however, it's clear that the maintainer meant to say source is over there. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: Non-source Javascript files in upstream source
Wouter Verhelst wou...@debian.org writes: Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte: If you were to 'update' the image, how would you do it? What things would you need? Include that. Think about what you'd need when you fork the project. Does that mean I should include wget? I'm sure you know this, and I am having difficulty interpreting your question in good faith. But in case you actually don't know: Paul is referring, by “what things do you need?”, not to tools used, but to the *form of the work* for making modifications to it. Clearly the “wget” program is not a form of any work except the “wget” program. As an aside to Paul: This is a prime example why a clear definition of “source” in terms of the “form of the work” is needed: you need to be clear you're talking about a specific *form of the work*; in particular, the preferred form of the work for making modifications to it. Most minified externally-produced javascript files are just downloaded verbatim off the web. How can we verify which ones are verbatim copies, automatically for every release of the source package? If we don't verify, we can't assert with confidence that some particular minified file actually matches, in every detail of behaviour, a version for which we distribute source. I agree with the sentiment that we should provide source in Debian for everything that's actually useful for our users. Do you agree that nobody except the recipient gets to decide what they find useful? Or would you arrogate to the Debian project the power to deny the fact that a recipient may find a Debian source package useful in itself? If a dependency and a symlink exists, however, it's clear that the maintainer meant to say source is over there. The maintainer may intend that to be true. Without independent automated verification, we are merely guessing and hoping. How can we verify independently that no such assertion is false? I've described a means that is certain and simple: discard the non-source form from the source package. -- \ “Instead of a trap door, what about a trap window? The guy | `\ looks out it, and if he leans too far, he falls out. Wait. I | _o__)guess that's like a regular window.” —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85d2fpevz9@benfinney.id.au
Re: Non-source Javascript files in upstream source
On Wed, 07 May 2014 20:14:50 +1000 Ben Finney b...@benfinney.id.au wrote: Wouter Verhelst wou...@debian.org writes: Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte: If you were to 'update' the image, how would you do it? What things would you need? Include that. Think about what you'd need when you fork the project. Does that mean I should include wget? I'm sure you know this, and I am having difficulty interpreting your question in good faith. But in case you actually don't know: Paul is referring, by “what things do you need?”, not to tools used, but to the *form of the work* for making modifications to it. Clearly the “wget” program is not a form of any work except the “wget” program. As an aside to Paul: This is a prime example why a clear definition of “source” in terms of the “form of the work” is needed: you need to be clear you're talking about a specific *form of the work*; in particular, the preferred form of the work for making modifications to it. In terms of updating the package, I don't consider that it is good enough to assume that the following sequence does not provide *all* of the source code necessary to modify all parts of the package, in the form preferred for modification: $ apt-get install package # to get the runtime dependencies $ apt-get source package $ apt-get build-dep package That needs to include the probability of updating the package to use a new version of the JS code which is needed by the package. I'm applying this upstream too - the code is susceptible to bugs on version changes in the JS code, so we'll be packaging known good versions and only symlinking when those versions are available. At least, that's the plan. There are cases where this doesn't work - if the thing over there is actually a service rather than a couple of files. Most minified externally-produced javascript files are just downloaded verbatim off the web. How can we verify which ones are verbatim copies, automatically for every release of the source package? If we don't verify, we can't assert with confidence that some particular minified file actually matches, in every detail of behaviour, a version for which we distribute source. Downloading random versions is also likely to cause bugs. Downloading strict versions is susceptible to causing 404s when upstream stop bothering about obsolete versions, causing more bugs. Much better to put those dependencies into the package information. I agree with the sentiment that we should provide source in Debian for everything that's actually useful for our users. Do you agree that nobody except the recipient gets to decide what they find useful? Or would you arrogate to the Debian project the power to deny the fact that a recipient may find a Debian source package useful in itself? If a dependency and a symlink exists, however, it's clear that the maintainer meant to say source is over there. As I've tried to show above, over there is not helpful. over there can go away, can be updated and cannot be verified as the actual code needed by the package. over there doesn't help anyone fix installs on older boxes which have suddenly stopped working. The maintainer may intend that to be true. Without independent automated verification, we are merely guessing and hoping. How can we verify independently that no such assertion is false? I've described a means that is certain and simple: discard the non-source form from the source package. Agreed, the source package needs to contain the JS in the preferred form for modification. *If* that is provided by a package at a supported version, then a symlink can be used (and a versioned dependency if the version matters as it does in some of my usecases). From upstream perspective, provide the JS in the form preferred for modification and minify during the package build. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Non-source Javascript files in upstream source
Neil Williams codeh...@debian.org writes: Ben Finney b...@benfinney.id.au wrote: Wouter Verhelst wou...@debian.org writes: If a dependency and a symlink exists, however, it's clear that the maintainer meant to say source is over there. As I've tried to show above, over there is not helpful. over there can go away, can be updated and cannot be verified as the actual code needed by the package. over there doesn't help anyone fix installs on older boxes which have suddenly stopped working. I think Wouter is referring to “over there” as the destination of the symlink. In other words, this isn't a proposal for linking outside Debian for the source; the hypothetical symlink is to a file provided by some other Debian package. The maintainer may intend [an assertion that the source for some non-source form is found in a different Debian package] to be true. Without independent automated verification, we are merely guessing and hoping. How can we verify independently that no such assertion is false? I've described a means that is certain and simple: discard the non-source form from the source package. Agreed, the source package needs to contain the JS in the preferred form for modification. *If* that is provided by a package at a supported version, then a symlink can be used (and a versioned dependency if the version matters as it does in some of my usecases). From upstream perspective, provide the JS in the form preferred for modification and minify during the package build. That is much preferable, I agree. It's unfortunate that many upstream projects consider “the package build” of so little importance that they provide *only* a non-source form of third-party files, expecting that no recipient cares to get the full source. We need to respectfully educate them that this is not enough. -- \ “Working out the social politics of who you can trust and why | `\ is, quite literally, what a very large part of our brain has | _o__) evolved to do.” —Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857g5xetpf@benfinney.id.au
Re: Non-source Javascript files in upstream source
Op woensdag 7 mei 2014 20:14:50 schreef Ben Finney: Wouter Verhelst wou...@debian.org writes: Op vrijdag 2 mei 2014 15:58:37 schreef Paul Tagliamonte: If you were to 'update' the image, how would you do it? What things would you need? Include that. Think about what you'd need when you fork the project. Does that mean I should include wget? I'm sure you know this, and I am having difficulty interpreting your question in good faith. But in case you actually don't know: I was speaking with tongue in cheek here. Of course I know. The point is, I'm having a hard time buying the argument that if the minified javascript was unmodified, and if the non-minified javascript library is in the archive (or a version of said javascript library which will function in exactly the same way), that the minified javascript is suddenly non-free because it does not contain the non-minified version in the *same* source tarball. The source is there. For the very same reason we accept built-using and *- source packages, I don't see a problem with having a minified javascript library in a source tarball *as long as the source is in Debian*, somewhere. The point of freedom is to allow people to make changes, not to have a pedantically correct version of every bit of source out there. So long as people can make such changes without too much effort (and I submit that in the case of minified javascript libraries without non-minified version, they can), I don't see what the problem is. [...] Most minified externally-produced javascript files are just downloaded verbatim off the web. How can we verify which ones are verbatim copies, automatically for every release of the source package? If you must, you could take a checksum and build a database of known- unmodified versions. I'm not convinced that's actually useful, however. [...] I agree with the sentiment that we should provide source in Debian for everything that's actually useful for our users. Do you agree that nobody except the recipient gets to decide what they find useful? Or would you arrogate to the Debian project the power to deny the fact that a recipient may find a Debian source package useful in itself? If a dependency and a symlink exists, however, it's clear that the maintainer meant to say source is over there. The maintainer may intend that to be true. Without independent automated verification, we are merely guessing and hoping. We are merely guessing and hoping that most of the code in Debian is actually under the license terms as specified in the debian/copyright file, too. Yes, with machine-parseable copyright files you can make verifications as to whether the copyright file matches the copyright header in the file. That's still not a proof. How can we verify independently that no such assertion is false? I've described a means that is certain and simple: discard the non-source form from the source package. It is certainly a certain way of doing that, yes. It is also annoying for the maintainer involved, and should not be necessary. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Re: Non-source Javascript files in upstream source
Wouter Verhelst w...@uter.be writes: The point is, I'm having a hard time buying the argument that if the minified javascript was unmodified, and if the non-minified javascript library is in the archive (or a version of said javascript library which will function in exactly the same way), that the minified javascript is suddenly non-free because it does not contain the non-minified version in the *same* source tarball. No-one AFAIK is making that argument, so that hopefully sets your mind at ease. For the very same reason we accept built-using and *- source packages, I don't see a problem with having a minified javascript library in a source tarball *as long as the source is in Debian*, somewhere. Agreed, if that can be known with confidence at least as good as the very simple and reliable method of removing the non-source form out of the Debian source package. The point of freedom is to allow people to make changes, not to have a pedantically correct version of every bit of source out there. The point of freedom is more than merely to make changes; it is the freedom to inspect the work and see what it does, it is the freedom to share the work with others in the same freedom as the original. Both those are thwarted by receiving a non-source form of the work, without a verifiable assurance that the claimed source *actually* is the corresponding source for the non-source form they received. So long as people can make such changes without too much effort (and I submit that in the case of minified javascript libraries without non-minified version, they can), I don't see what the problem is. So that I understand your position: You're saying a recipient of Debian who obtains, from the Debian source package, a minified JavaScript file *without* corresponding source, has effective freedom to modify that work? That the freedom to modify the work does not entail that they receive the preferred form of the work for making modifications, in order to make modifications? [...] How can we verify which [non-source JavaScript libraries] are verbatim copies [from a work for which we demonstrably have source], automatically for every release of the source package? If you must, you could take a checksum and build a database of known- unmodified versions. I'm not convinced that's actually useful, however. If you must, that could work. That's more complex and less reliable than simply omitting the non-source form of the work. We are merely guessing and hoping that most of the code in Debian is actually under the license terms as specified in the debian/copyright file, too. The difference being that in the case of upstream's claim of copyright grant and license terms, we have little choice, since there is no good way to automatically and independently verify those claims. In the case of non-source forms of a JavaScript library, we clearly have a simple way to be certain: How can we verify independently that no such assertion is false? I've described a means that is certain and simple: discard the non-source form from the source package. It is certainly a certain way of doing that, yes. It is also annoying for the maintainer involved, and should not be necessary. I'd love for it not to be necessary; sadly, until upstream stop bundling non-source forms of a work, the onus for ensuring Debian recipients actually get the corresponding source for what's in Debian falls to us as maintainers. -- \ “The best mind-altering drug is truth.” —Jane Wagner, via Lily | `\Tomlin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8538glenhz@benfinney.id.au
Re: Non-source Javascript files in upstream source
Op woensdag 7 mei 2014 23:18:00 schreef Ben Finney: Wouter Verhelst w...@uter.be writes: The point is, I'm having a hard time buying the argument that if the minified javascript was unmodified, and if the non-minified javascript library is in the archive (or a version of said javascript library which will function in exactly the same way), that the minified javascript is suddenly non-free because it does not contain the non-minified version in the *same* source tarball. No-one AFAIK is making that argument, so that hopefully sets your mind at ease. For the very same reason we accept built-using and *- source packages, I don't see a problem with having a minified javascript library in a source tarball *as long as the source is in Debian*, somewhere. Agreed, if that can be known with confidence at least as good as the very simple and reliable method of removing the non-source form out of the Debian source package. The point of freedom is to allow people to make changes, not to have a pedantically correct version of every bit of source out there. The point of freedom is more than merely to make changes; it is the freedom to inspect the work and see what it does, it is the freedom to share the work with others in the same freedom as the original. Yes, that too. My point was that we should consider *why* we want source. If the source is elsewhere available, then it is available, and it does not matter that it is not available in the current source package. So long as people can make such changes without too much effort (and I submit that in the case of minified javascript libraries without non-minified version, they can), I don't see what the problem is. So that I understand your position: You're saying a recipient of Debian who obtains, from the Debian source package, a minified JavaScript file *without* corresponding source, has effective freedom to modify that work? No. But I agree that my above sentence could have been written with some more care; I should have cleared up my braindump a bit better. Allow me to rephrase: I submit that in the case of minified javascript libraries that are *already available* in Debian, and that are symlinked (in the way as described before) but ship in a source tarball as convenience copies *which are not used*, they can. It is easy to verify whether such minified javascript libraries are used: if the binary package does not ship with them, they are not used, even if they are in the source package. [...] How can we verify which [non-source JavaScript libraries] are verbatim copies [from a work for which we demonstrably have source], automatically for every release of the source package? If you must, you could take a checksum and build a database of known- unmodified versions. I'm not convinced that's actually useful, however. If you must, that could work. That's more complex and less reliable than simply omitting the non-source form of the work. They need not be removed from the source package, IMO. [...] -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2684636.6uzum2g...@grep.be
Re: Non-source Javascript files in upstream source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/07/2014 11:06 AM, Wouter Verhelst wrote: I submit that in the case of minified javascript libraries that are *already available* in Debian, and that are symlinked (in the way as described before) but ship in a source tarball as convenience copies *which are not used*, they can. It is easy to verify whether such minified javascript libraries are used: if the binary package does not ship with them, they are not used, even if they are in the source package. One difficulty with this is that it is (potentially) confusing to the end user. Specifically, it violates my (pre-this-thread) expectation of what it is that I get from 'apt-get source'. Prior to reading this thread, it would never have occurred to me to think that something obtained that way might not be actually part of the source (or source-documentation, et cetera) of the binary package; I would have looked at the source, seen the minified JS file, and expected that it would be used during the build or in the final binary. If I needed to modify it, or to trace code flow through it for debugging purposes, I could have spent a fair amount of time and effort unnecessarily. I don't think I'm likely to be alone in this. I think this is akin to the question of embedded copies of separately-packaged libraries; I would have been similarly though not identically misled by the presence of the source of such a library in the 'apt-get source' result of a non-library package. I believe I've seen discussions of whether to strip out such code copies here in the past, though I don't recall what the outcomes may have been. At minimum, I would think that all such included but not used code should be explicitly documented somewhere (preferably somewhere relatively visible) in the source package, listing all files - or, when applicable, directories - which should be ignored because the package build uses external ones. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTalQaAAoJEASpNY00KDJrVPMP/3HumvVxXjnnx7TEVCNvm4x+ h2/gVP0+4XjKFuqVpwDuIfws8Vw1/JRdd+W3QMZTRR9+8xET37Wtk6wp/yxCBQkA kyQY/vVUrgVFxf++0xDvqvh8rRPlDOCNQuHQkz7gUHk7rJDv0shZsI9I+R7JuPU3 7j1srzwJHFazxcFA5WZkeaNQmdcDUA8ZBkS9McbXEDYeS40vO+2fxoT7CaVKYlYc I3LFTVIiPWZ9AHc+6YjzqNabTZt4CcTNRSs06+LFrpsh21t801LCFcpV2neP+5Im njbe7WgvOV3ct94Jk2G6d9trD7WjI3/smhaQKbeCywvTG4oghGQhHTM6TaG8kqAY sirPW+miUiuh8olLyza9CmqM9cO9scYE3prkzpYDpga2iZ8xJBFKFCsj5K8+bfqy 3PIBuUPOahoMLJM/lWMwmqAtuWKpGQ1Ls74TklqsD8bV+rhctkbf1K5XcK7Ibce1 wJSRMBLXaCRT8XIcS1oo9Se4Qdrnykv9JmIJT16jAqvL7SU7tWol6Ym5kEHjJxkX 0qVWUHMgXVRMoLTon9WG2huW9CMGowmzwOIy4LTD8nAxdhupGZlmOtz8LB9QKUgo xUCOngB4b5bOTEkWouzadvVycT1WBRZh1706iFQJWSguImiM4e1VDGT+3dN+TfNr 9IG04PxvYp/kgpzFfYQo =YBi4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536a541a.7000...@fastmail.fm
Re: Non-source Javascript files in upstream source
On Wed, May 07, 2014 at 05:18:36PM +1000, Ben Finney wrote: the problem is for the package maintainer to assert that *is* the corresponding source for a particular work. We should not, IMO, accept such an assertion without an independently verifiable guarantee that can be automated for each release of the source package. And that is precisely the disagreement. You say this is important, but there's no rule that requires it and others, including me, say that our time is better spent doing other things. I have no problem accepting the assertion. And if I do that, I see a generated file with what I believe to be its source, and there is no problem. What do you think about configure files? Should they all be removed, because we can never check if configure.ac really is the source (given all the different versions of the tools used to generate it)? What if things break and the maintainer fixes it by editing configure (not configure.ac, for whatever reason) by hand? Does that make the package non-free? I'm not opposed to cleaning every source package so it only uses what is really required for building the Debian package, but that is a big change from don't touch upstream's tarball unless you really have to, and IMO a GR would be in order for such a big change. Thanks, Bas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507182238.gu10...@fmf.nl
Re: Non-source Javascript files in upstream source
❦ 7 mai 2014 17:41 CEST, The Wanderer wande...@fastmail.fm : Specifically, it violates my (pre-this-thread) expectation of what it is that I get from 'apt-get source'. Prior to reading this thread, it would never have occurred to me to think that something obtained that way might not be actually part of the source (or source-documentation, et cetera) of the binary package; I would have looked at the source, seen the minified JS file, and expected that it would be used during the build or in the final binary. If I needed to modify it, or to trace code flow through it for debugging purposes, I could have spent a fair amount of time and effort unnecessarily. I don't think I'm likely to be alone in this. This is to be compared with the time spent by the maintainer to deal with this problem by adding files or removing files from the source package without affecting the resulting binary package. This may keep some contributors away from Debian. When I get some time to work on my packages and I see this: http://lintian.debian.org/maintainer/pkg-roundcube-maintain...@lists.alioth.debian.org.html#roundcube Well, I say Let's do something else, I'll have another look later. -- Make input easy to prepare and output self-explanatory. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Non-source Javascript files in upstream source
Le jeudi 08 mai 2014 à 00:57 +0200, Vincent Bernat a écrit : ❦ 7 mai 2014 17:41 CEST, The Wanderer wande...@fastmail.fm : Specifically, it violates my (pre-this-thread) expectation of what it is that I get from 'apt-get source'. Prior to reading this thread, it would never have occurred to me to think that something obtained that way might not be actually part of the source (or source-documentation, et cetera) of the binary package; I would have looked at the source, seen the minified JS file, and expected that it would be used during the build or in the final binary. If I needed to modify it, or to trace code flow through it for debugging purposes, I could have spent a fair amount of time and effort unnecessarily. I don't think I'm likely to be alone in this. This is to be compared with the time spent by the maintainer to deal with this problem by adding files or removing files from the source package without affecting the resulting binary package. This may keep some contributors away from Debian. When I get some time to work on my packages and I see this: http://lintian.debian.org/maintainer/pkg-roundcube-maintain...@lists.alioth.debian.org.html#roundcube Well, I say Let's do something else, I'll have another look later. The situation for roundcube is not that bad... i'm offering to help (in the pkg-roundcube repository) ? Jérémy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1399504310.10734.22.camel@imac.chaumes
Re: Non-source Javascript files in upstream source
❦ 8 mai 2014 01:11 +0200, Jérémy Lal kapo...@melix.org : This is to be compared with the time spent by the maintainer to deal with this problem by adding files or removing files from the source package without affecting the resulting binary package. This may keep some contributors away from Debian. When I get some time to work on my packages and I see this: http://lintian.debian.org/maintainer/pkg-roundcube-maintain...@lists.alioth.debian.org.html#roundcube Well, I say Let's do something else, I'll have another look later. The situation for roundcube is not that bad... i'm offering to help (in the pkg-roundcube repository) ? Sure, I'll accept your request. Thanks. But there are some other things to do in the package. I have put a TODO in debian/changelog. That's just that from a Debian point of view, the problem with the sourceless files have to be handled first (serious bugs). -- panic(Oh boy, that early out of memory?); 2.2.16 /usr/src/linux/arch/mips/mm/init.c signature.asc Description: PGP signature
Re: Non-source Javascript files in upstream source
Vincent Bernat ber...@debian.org writes: When I get some time to work on my packages and I see this: http://lintian.debian.org/maintainer/pkg-roundcube-maintain...@lists.alioth.debian.org.html#roundcube Yes, it's disheartening to see such files in a source distribution from upstream. Fortunately the solution isn't complex. Well, I say Let's do something else, I'll have another look later. I am using URL:https://wiki.debian.org/BenFinney/software/repack for another package, to remove non-source JavaScript files from the Debian source package. I have now re-worked it for the ‘roundcube’ package and submitted it in patches for bug#736782. -- \ “Yesterday I parked my car in a tow-away zone. When I came back | `\ the entire area was missing.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85zjitau43@benfinney.id.au
Re: Non-source Javascript files in upstream source
Op zaterdag 26 april 2014 16:51:57 schreef Ben Finney: Steve M. Robbins st...@sumost.ca writes: On April 25, 2014 11:02:29 PM Ben Finney wrote: We promise the source for everything any recipient downloads as part of Debian. If non-source files are distributed in Debian source packages, without a way to confidently guarantee the corresponding source is what's already available in Debian, then that is a definite impact on the freedom of Debian recipients: it threatens the freedom promises in the Social Contract. That is certainly not a universally held view. Some of us [1] regard random trash littering the source distribution -- but not used in generating the actual software (binary distribution) -- as merely a nuisance that can be tolerated. If it's in the Debian source package, it is distributed as part of Debian. If it's distributed as part of Debian, it is subject to the promises in the Debian Social Contract. Those promises include the promise that anything in Debian has its source in Debian. Yes. And while I agree that this is a problem for things like precompiled Windows binaries, I'm not so sure when it regards convenience copies of minified javascript libraries. After all, there are many other packages whose upstream source ships with convenience copies of other code, and we don't consider those to be problems. If a package will work equally well when using the Debian-packaged version of a javascript library rather than using the shipped convenience copy of the said library (as proven by using a symlink and a dependency to the relevant file and package rather than shipping the convenience copy in the binary package), then the source requirements for all relevant code is satisfied; it's just that they're done so by another source package. I have to say that this absolutist zeal in scrubbing the source package grates on me for two reasons. FIrst, it introduces an undocumented difference between upstream source and Debian source. The difference should not be undocumented: the difference should be described in the package, and its rationale given. ‘README.source’ is a good place to document the difference. No, that's not what README.source is meant for. This should document weirdness about the package build system as necessary for an NMU'er to figure out how the package works. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Re: Non-source Javascript files in upstream source
Paul Tagliamonte paul...@debian.org writes: On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote: 2. What is source for a non-programmatic work such as a rendered bitmap of a 3-D model, do we require source for non-programmatic works, and if not, what defines a programmatic work? Preferred form of modification. As far as I understand it, that phrase doesn't make sense. My understanding of the FTP team's operating policy for what constitutes source for a work is: the preferred form of the work for making modifications to it. Is that what you meant? Yes, there exist edge-cases (an image made from a photo taken of someone which had two pixels flipped after putting it through scanner after skydiving while drawing it), but I think good judgement here is fine. Right. The “preferred form of the work for making modifications to it” definition, while not perfect, is a good rule of thumb and in practice resolves such edge cases fairly clearly. In particular: if the form in question either doesn't exist as digital information, or is not the form used in practice by those who actually make the primary modifications of the work, then that form definitely isn't the preferred form of the work for making modifications. These seem to me to be clear implications of that definition. Neither of these is clarified by their recent statement. I believe they are. We require source. This applies to source packages. If you don't have source, don't include the thing. If you have the source, rebuild it at build time. Perhaps the definition “the preferred form of the work for making modifications to it”, if that is in fact the operational definition for “the source form of a work” in Debian, needs to be made more widely and clearly known where maintainers will expect to find it. -- \ “I went camping and borrowed a circus tent by mistake. I didn't | `\ notice until I got it set up. People complained because they | _o__) couldn't see the lake.” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85zjizfffa@benfinney.id.au
Re: Non-source Javascript files in upstream source
Hi Ben, On Samstag, 3. Mai 2014, Ben Finney wrote: Preferred form of modification. As far as I understand it, that phrase doesn't make sense. My understanding of the FTP team's operating policy for what constitutes source for a work is: the preferred form of the work for making modifications to it. Is that what you meant? care to explain the difference? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Non-source Javascript files in upstream source
Holger Levsen hol...@layer-acht.org writes: Hi Ben, On Samstag, 3. Mai 2014, Ben Finney wrote: As far as I understand it, that phrase [“preferred form of modification”] doesn't make sense. My understanding of the FTP team's operating policy for what constitutes source for a work is: the preferred form of the work for making modifications to it. Is that what you meant? care to explain the difference? We're not interested in what form a *modification* takes (if it even makes sense to talk about a “form of modification”, which doesn't seem coherent in the context). We're interested in what form of the *work* is the source form. That is, to answer the question “what is the source form of the work”, we need a definition that answers in terms of “such-and-so form of the work”. To answer that question, an answer that talks about “form of modification” doesn't line up; at least, I can't make it coherent without changing the wording. So, that's why I'm suggesting we use the GPL's phrase to answer that same question: “the preferred form of the work for making modifications to it”, which is AIUI what the ftp-team already uses to define the source form of a work. I suspect that definition is what is meant here, but I'd rather we not need to guess, and I'd rather we not use a divergent definition that isn't already widely understood if we don't need to. -- \ “Nullius in verba” (“Take no-one's word for it”) —motto of the | `\ Royal Society, since 1663-06-30 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85tx97f5li@benfinney.id.au
Re: Non-source Javascript files in upstream source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/03/2014 07:45 AM, Ben Finney wrote: Holger Levsen hol...@layer-acht.org writes: Hi Ben, My understanding of the FTP team's operating policy for what constitutes source for a work is: the preferred form of the work for making modifications to it. Is that what you meant? care to explain the difference? We're not interested in what form a *modification* takes (if it even makes sense to talk about a “form of modification”, which doesn't seem coherent in the context). We're interested in what form of the *work* is the source form. I've always reflexively translated preferred form of modification into preferred form for modification, which simply elides the noun from the long-form phrase, while - unlike the of version - retaining the same meaning. If a short-form version of the phrase is wanted, I suspect using for instead of of might work considerably better. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTZNjzAAoJEASpNY00KDJrUN0P/im3fXPLH8+IJDOxLHgeerwE ySZIaFkYMtxpBSIp9vwhm/0WglkUmxNx3c2Qcrc4THbSmNnmESYlcFYZl38s589W T7WuJgbLWMcWkr0fnFn+Jz3cs67beNwqKbFIWfap2QIcVJeVRwqS64WNBnVp+WnB ehiEzxa6d842Nz+oq3h6W+WwVC4c01f2Uo/joJ6S2/vH3jsscfq4rdqCPAyNQ+xE 0EMa6/pkaMqKDpkamt23VY6p+Lh2InfNL+1XYv0oyJbZvoUjGov9i5bv46YThYLR FCNM9v80NEdQ0+0Br7uK6wglrsK4gZnXg37dnDdMWrAVOAX9QJxy6Nfu3GjisBbc L3YyHUVeddP0rYnh2Ct+UotT0SXJ5JDrXJioSi8PL3J9GdB/EqXPCpLyHz+A6g9B 0UCZCuiMnpHhCspWkkgoduBP9AU+45YZgnOrSP0G7jHhUamhkaOy1V9dQHe3GO/Z FAgknjRTefK60rduiMdyVEC54gBlAKO5peoxy9teEdXJB/tveSfrPAQiVwRQpNkg ApVZymYw0W8hHWpD6ok3WbG6GZZUbOW8WMf2ctEi/md1J5dNgWo5N4mkyg0YKAZ3 SHPyhCe2jMbYWe57QLg26LRFZiKEjxR0PE7s1hVs47sdVdLbZqB8cp9ZZ9DiGag7 IqXI3NS4NVQtQ+keXYpA =/Kxg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5364d8f3.7040...@fastmail.fm
Re: Non-source Javascript files in upstream source
Nikolaus Rath dixit: Ah, wait. So is the requirement that we ship the source to all files in the source package, or is the requirement to ship the source to all files in the source package that are used to generate the binary package? The former, plus… Paul Tagliamonte paul...@debian.org writes: Yes. Please see the email. You need to make sure you have source for everything. If you're not shipping the raw source (e.g. most Python), be sure you're making the binary in your rules file, and using that binary in the deb. … you need to actually *use* those sources to generate the binary. I'm still surprised that I had to start stripping out javascript files in the Sphinx-generated documentation from upstream tarballs, despite the documentation being completely removed and regenerated during the build. That is because Debian is about a promise. The promise here is that, if you take anything from Debian (main), it’s DFSG free, be it a binary, the source to the binary, the source .tar.gz, firmware, images, audiovisual content, works of literacy, etc. It took me a while to “get” it, but it’s really the only thing that makes sense for Debian. (And yes, this means that even tytso should really regenerate his configure files in the e2fsprogs debian/rules file.) bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405031206470.29...@herc.mirbsd.org
Re: Non-source Javascript files in upstream source
Ben Finney dixit: That is, to answer the question “what is the source form of the work”, we need a definition that answers in terms of “such-and-so form of the work”. Well, the one you’d want to have when you were to modify (think, fork) the original work in question. In the autoconf case: even if one occasionally changes the configure file *after* generating it, this still means you’d want to have the .ac file available. bye, //mirabilos -- Hi, does anyone sell openbsd stickers by themselves and not packaged with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405031216530.29...@herc.mirbsd.org
Re: Non-source Javascript files in upstream source
Hi Ben, On Samstag, 3. Mai 2014, Ben Finney wrote: care to explain the difference? We're not interested in what form a *modification* takes (if it even makes sense to talk about a “form of modification”, which doesn't seem coherent in the context). We're interested in what form of the *work* is the source form. That is, to answer the question “what is the source form of the work”, we need a definition that answers in terms of “such-and-so form of the work”. To answer that question, an answer that talks about “form of modification” doesn't line up; at least, I can't make it coherent without changing the wording. thanks for the explaination, even though I cannot make much sense out of it ;) I appreciate there seems to be a huge difference for native english speakers, but to me, “preferred form of modification” equals he preferred form of the work for making modifications to it. And since it's shorter and appearantly many other people don't seem to get the difference, preferred form of modification” in my book has become a standing expression, which most people seem to get righ. And it's still ambigious: if I prefer to edit assember with a hex editor... I suspect that definition is what is meant here, but I'd rather we not need to guess, and I'd rather we not use a divergent definition that isn't already widely understood if we don't need to. I agree and would suggest to accept that “preferred form of||for modifications” is supposed to mean that too. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Non-source Javascript files in upstream source
On Fri, May 02, 2014 at 03:58:37PM -0400, Paul Tagliamonte wrote: On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote: Is there any disagreement about this? As far as I've understood so far, there are only two points that keep being discussed: 1. Do we need to check that generated files which we don't use are actually generated from the provided source? Main example here is a configure file which gets overwritten during build. Yes. Please see the email. You need to make sure you have source for everything. If you're not shipping the raw source (e.g. most Python), be sure you're making the binary in your rules file, and using that binary in the deb. This was not the point I wrote about, and AFAIK not a point that is contested. What I was saying is: We have a configure file, and we have a configure.ac, which upstream claims was used to generate the shipped configure. During package build, we ignore the shipped configure file and generate a new one from configure.ac. Up to this point, AFAIK there is consensus about everything. The contested point is: what do we do with the shipped (and unused) configure file? Do we need to check that upstream's statement (that it was generated from configure.ac) is correct (or more likely, remove configure from the source package because we can't really check this)? Or can we trust upstream on this? 2. What is source for a non-programmatic work such as a rendered bitmap of a 3-D model, do we require source for non-programmatic works, and if not, what defines a programmatic work? Preferred form of modification. Yes, there exist edge-cases (an image made from a photo taken of someone which had two pixels flipped after putting it through scanner after skydiving while drawing it), but I think good judgement here is fine. I tend to agree with this. My point wasn't that I don't have an opinion, but that there isn't consensus on this. Which is illustrated by the replies to your statement. ;-) Neither of these is clarified by their recent statement. I believe they are. We require source. This applies to source packages. If you don't have source, don't include the thing. If you have the source, rebuild it at build time. For point 1, the contested part is are we sure configure.ac is the source for configure? and in point 2, it is does a file exist which is source code for this file, or should it be considered source itself? On Fri, May 02, 2014 at 07:47:08PM -0400, Theodore Ts'o wrote: If someone starts complaining that I shipped a version of configure that corresponded to autoconf version N, and sid just uploaded N+1, and therefore my configure doesn't match with my configure.in, and that's therefore a DFSG violation, I'm going to be really annoyed. Yes, I don't think anyone is suggesting that this is a problem. If configure was generated from configure.ac, even if you can't regenerate the exact same file with your system, that configure.ac is still its source. This is about the unlikely case where upstream ships a new configure and an outdated configure.ac, so that the build process works better using the shipped configure than when regenerating it. If this would actually happen, I think everyone would agree that this configure file doesn't have source in the package and cannot be in Debian. This is however very unlikely and several people are saying let's just trust upstream that they don't do this and not waste our time on it, which I think is a valid argument. On the other hand, removing the file from the source package isn't a lot of work either. But do we want to repackage all of our source tarballs? Also, we'd be sending a signal to the community that files such as configure don't belong in a release tarball, while they really do: they make it easier to compile the program on a system with bad or broken tools. Debian doesn't need that, but that doesn't mean we want to tell upstream not to include it. Heck, when autoconf has been busted, there have been times that modifying the configure script directly *was* my preferred form for making modifications Ah, and what to do then? If we would decide that we remove configure because we don't want to check, that really means in such a case you must check that the configure before you made modifications to it is generated by configure.ac (if you wouldn't need to check that, we also wouldn't need to check the other cases). And that doesn't seem like something that reasonably can be done. So for those who claim that we need to remove configure files: how would you handle this? Is this an exception? Is the maintainer (or upstream) not allowed to do this? Personally, I like the idea of trusting upstream that configure.ac is source for configure, and we don't have to remove configure from the source package (assuming configure.ac is there, of course). On Sat, May 03, 2014 at 10:59:50AM +0900, Charles Plessy wrote: Le Fri, May 02,
Re: Non-source Javascript files in upstream source
Quoting Holger Levsen (2014-05-03 15:26:37) On Samstag, 3. Mai 2014, Ben Finney wrote: care to explain the difference? We're not interested in what form a *modification* takes (if it even makes sense to talk about a “form of modification”, which doesn't seem coherent in the context). We're interested in what form of the *work* is the source form. That is, to answer the question “what is the source form of the work”, we need a definition that answers in terms of “such-and-so form of the work”. To answer that question, an answer that talks about “form of modification” doesn't line up; at least, I can't make it coherent without changing the wording. thanks for the explaination, even though I cannot make much sense out of it ;) I appreciate there seems to be a huge difference for native english speakers, but to me, “preferred form of modification” equals he preferred form of the work for making modifications to it. form of modification: How it is modified. form for modification: That which is modified. We care about form of source, not form of modification [to source]. And since it's shorter and appearantly many other people don't seem to get the difference, preferred form of modification” in my book has become a standing expression, which most people seem to get righ. Replace of with for and it is (not identical to other texts arguably perfected via lawyers, but) correct english. I sure hope it is not a single character that feels too heavy ;-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Non-source Javascript files in upstream source
Russ Allbery writes (Re: Non-source Javascript files in upstream source): I continue to hold to my position that distributing sourceless files in source packages, provided they are under a free license and not used as part of the process of building binary package, is a nuisance rather than a meaningful DFSG violation and not worth spending project time and resources on. That said, I do understand why people want simple rules with no exceptions, even if those rules lead to moderately nonsensical corner cases. I very much doubt that further discussion of this is going to change anyone's mind, and I suspect we will simply continue to disagree on the requirements until such a time as someone proposes a GR to clarify this (if that ever happens). I don't care enough about the issue to do that myself. I'm starting to get tempted. If we have a GR on it, regardless of the outcome, we can stop these arguments a bit sooner. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21347.55434.940648.630...@chiark.greenend.org.uk
Re: Non-source Javascript files in upstream source
On Fri, May 02, 2014 at 06:40:26PM +0100, Ian Jackson wrote: I'm starting to get tempted. If we have a GR on it, regardless of the outcome, we can stop these arguments a bit sooner. Please do note that this would be a GR to override a DPL delegated team's decision[1], just to be absolutely clear. Cheers, Paul [1]: https://lists.debian.org/debian-devel-announce/2014/04/msg00014.html -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Non-source Javascript files in upstream source
Paul Tagliamonte paul...@debian.org writes: On Fri, May 02, 2014 at 06:40:26PM +0100, Ian Jackson wrote: I'm starting to get tempted. If we have a GR on it, regardless of the outcome, we can stop these arguments a bit sooner. Please do note that this would be a GR to override a DPL delegated team's decision[1], just to be absolutely clear. That doesn't matter for a GR. A GR can do that with a simple majority. However, to put this issue to rest, the GR probably needs to amend the DFSG to make it unambiguous, so a 3:1 supermajority would be a good idea anyway. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uqkjb7q@windlord.stanford.edu
Re: Non-source Javascript files in upstream source
On Fri, May 02, 2014 at 11:18:33AM -0700, Russ Allbery wrote: Paul Tagliamonte paul...@debian.org writes: On Fri, May 02, 2014 at 06:40:26PM +0100, Ian Jackson wrote: I'm starting to get tempted. If we have a GR on it, regardless of the outcome, we can stop these arguments a bit sooner. Please do note that this would be a GR to override a DPL delegated team's decision[1], just to be absolutely clear. Is there any disagreement about this? As far as I've understood so far, there are only two points that keep being discussed: 1. Do we need to check that generated files which we don't use are actually generated from the provided source? Main example here is a configure file which gets overwritten during build. 2. What is source for a non-programmatic work such as a rendered bitmap of a 3-D model, do we require source for non-programmatic works, and if not, what defines a programmatic work? Neither of these is clarified by their recent statement. However, to put this issue to rest, the GR probably needs to amend the DFSG to make it unambiguous, so a 3:1 supermajority would be a good idea anyway. That would be a good idea, but given the constant discussions and the vote in 2006[1], it seems doubtful whether we can get a simple majority on any point of view in this matter. So it might be better to at least include an option which makes the statement without modifying the DFSG. Thanks, Bas [1] https://www.debian.org/vote/2006/vote_004 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502192002.ga10...@fmf.nl
Re: Non-source Javascript files in upstream source
I'm not writing this email with my ftpteam hat on. On whenever (I can't be bothered to actually quote, sorry :) ) Russ wrote: That doesn't matter for a GR. A GR can do that with a simple majority. I know, but I just want to make it absolutely clear, since I believe the statement made covers this, and I think it presents a GR in a different light -- just politically, even if it doesn't change the votes needed. On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote: Is there any disagreement about this? As far as I've understood so far, there are only two points that keep being discussed: 1. Do we need to check that generated files which we don't use are actually generated from the provided source? Main example here is a configure file which gets overwritten during build. Yes. Please see the email. You need to make sure you have source for everything. If you're not shipping the raw source (e.g. most Python), be sure you're making the binary in your rules file, and using that binary in the deb. 2. What is source for a non-programmatic work such as a rendered bitmap of a 3-D model, do we require source for non-programmatic works, and if not, what defines a programmatic work? Preferred form of modification. Yes, there exist edge-cases (an image made from a photo taken of someone which had two pixels flipped after putting it through scanner after skydiving while drawing it), but I think good judgement here is fine. If the png was made from the svg, include the svg. If a binary was made from c, include the c. If a min.js was made from .js, include the js. If a config file was made by a jinja template, include the template. If you were to 'update' the image, how would you do it? What things would you need? Include that. Think about what you'd need when you fork the project. Hopefully most maintainers can identify the preferred form of modification on their own. If anyone has trouble, ask for help. Debian Legal is a good place, as is the ftpteam, debian-devel or wherever you feel most comfortable soliciting the help of others. Neither of these is clarified by their recent statement. I believe they are. We require source. This applies to source packages. If you don't have source, don't include the thing. If you have the source, rebuild it at build time. However, to put this issue to rest, the GR probably needs to amend the DFSG to make it unambiguous, so a 3:1 supermajority would be a good idea anyway. That would be a good idea, but given the constant discussions and the vote in 2006[1], it seems doubtful whether we can get a simple majority on any point of view in this matter. So it might be better to at least include an option which makes the statement without modifying the DFSG. -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Non-source Javascript files in upstream source
On Fri, May 02, 2014 at 03:58:37PM -0400, Paul Tagliamonte wrote: If the png was made from the svg, include the svg. Well, it is unclear who you are adressing here. If upstream made a .png from (prsumably) an .svg, but did not include the .svg in the tarball, how can the Debian maintainer include if they don't have access to it? I agree that when possible and feasable, the original source should be used. I just also tend to think then when upstream includes a PDF as very useful documentation, and it can be decuced from the layout that this was done by LaTeX or LibreOffice, but the respective source files are missing, our users are best served by including this PDF in this case (if there are no overriding licensing issues on top). It is ok to ask upstream if the maintainer wants to take that extra step, but I don't think it should be mandated. My 0.02 cents, anyway. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502214330.gf25...@raptor.chemicalconnection.dyndns.org
Re: Non-source Javascript files in upstream source
On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote: 1. Do we need to check that generated files which we don't use are actually generated from the provided source? Main example here is a configure file which gets overwritten during build. For the record, the reason why I ship a configure as well as a configure.in file with e2fsprogs is simply because I don't trust that an arbitrary version of autoconf won't break with what I have in my configure.in. And I don't want to trouble-shoot some random Gentoo's user's version of autoconf --- as far as I am concerned, the autoconf maintainers have provided no guarantees of stability between versions, at least none that I am willing to trust. So I am only going to ship configure as generated by a version of autoconf that I have personally tested as working. And there have been times in the past when I've simply kept an older version of autoconf because the current version of autoconf was busted as far as I was concerned, and I didn't have time to trouble shoot the damned thing. If someone starts complaining that I shipped a version of configure that corresponded to autoconf version N, and sid just uploaded N+1, and therefore my configure doesn't match with my configure.in, and that's therefore a DFSG violation, I'm going to be really annoyed. Heck, when autoconf has been busted, there have been times that modifying the configure script directly *was* my preferred form for making modifications *Especially* if debian stable, testing, unstable, and experimental might theoretically have completely different versions of autoconf, making it fundamentally impossible to guarantee that configure is exactly generated from the version of autoconf in all releases of Debian. There is such a thing of trying to adhere to the DFSG to the point of insanity - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502234708.ga11...@thunk.org
Re: Non-source Javascript files in upstream source
On May 2, 2014 5:43:30 PM EDT, Michael Banck mba...@debian.org wrote: On Fri, May 02, 2014 at 03:58:37PM -0400, Paul Tagliamonte wrote: If the png was made from the svg, include the svg. Well, it is unclear who you are adressing here. If upstream made a .png from (prsumably) an .svg, but did not include the .svg in the tarball, how can the Debian maintainer include if they don't have access to it? I agree that when possible and feasable, the original source should be used. I just also tend to think then when upstream includes a PDF as very useful documentation, and it can be decuced from the layout that this was done by LaTeX or LibreOffice, but the respective source files are missing, our users are best served by including this PDF in this case (if there are no overriding licensing issues on top). It is ok to ask upstream if the maintainer wants to take that extra step, but I don't think it should be mandated. My 0.02 cents, anyway. I think these are all a different case than JavaScript. JavaScript is code and I don't think there's much debate about the question of if code requires source. The debate is primarily about if lack of non-minified JavaScript source is a big enough problem to be worth the effort of fixing if it's not used in the binary. The works you describe aren't code, so there is an ambiguity between DFSG and the social contract that creates a difference of opinion about if these require source at all. I believe it's important to keep these two issues separate in order to better resolve both of them. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c5a0379d-1546-49c4-920e-e03f4e771...@email.android.com
Re: Non-source Javascript files in upstream source
Le Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen a écrit : 1. Do we need to check that generated files which we don't use are actually generated from the provided source? Main example here is a configure file which gets overwritten during build. 2. What is source for a non-programmatic work such as a rendered bitmap of a 3-D model, do we require source for non-programmatic works, and if not, what defines a programmatic work? Neither of these is clarified by their recent statement. I totally agree: in the FTP team's statement, first there is a quote of the DFSG: “The program must include source code” but then it adds later: ”all files in source packages must come with their source as required by the DFSG” This does not resolve the ambiguity in our Social Contract and the DFSG, where sometimes we refer to a “work”, sometimes a “component” and sometimes a “program” (and actually never to “files” in that context). Regarding the possibility of a GR: Most of the text of the DFSG is about judging licenses, not files. It refers to “programs” without defining what they are. Points 2 (related to source code) and 4 (related to patches) suggest that “program” refers to executables, but this interpretation may be too naive as it does not take into account how others defined a “program” before the DFSG were written (in the GPL: a copyrightable work), nor it takes into account the historical discussions when the DFSG were written. Altogether, this calls for clarifying what a “program” is. Point 2 is also strange from a gramatical point of view: “The program must […], and must allow distribution in source code”. I do not think that it was written with DRMs in mind (where programs really allow or disallow some actions), and it looks like what it intended is rather : “The program must […], and its license must…”. We could clarify the DFSG by separating the two issues (freedom by source code and freedom by license): - Introduce a point 0 explaining our requirements for the presence of source code. - Replace “program must include source code, and” by “license” in point 2. - Either define what a “program” is in point 0, or introduce a new definition for “works”, and replace “program” by “work” in the remaining points. The contents of this new point 0 are the core of the disagreemnts. I think that GR could be useful to solve the ambiguity of the DFSG it would not contain too many overlaping options. For instance: a) Disambiguate in a way that represents a status quo regarding our current practices. b) Extend our requirements for source code to explicitely include non-programs in our source packages. c) Focus our requirements for source code on the binary packages and the files necessary to rebuild them from the source packages. People know which one is my favorite, so I will not repeat it here :) Have a nice week-end, -- 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: https://lists.debian.org/20140503015950.ga1...@falafel.plessy.net
Re: Non-source Javascript files in upstream source
Paul Tagliamonte paul...@debian.org writes: On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote: Is there any disagreement about this? As far as I've understood so far, there are only two points that keep being discussed: 1. Do we need to check that generated files which we don't use are actually generated from the provided source? Main example here is a configure file which gets overwritten during build. Yes. Please see the email. You need to make sure you have source for everything. If you're not shipping the raw source (e.g. most Python), be sure you're making the binary in your rules file, and using that binary in the deb. Ah, wait. So is the requirement that we ship the source to all files in the source package, or is the requirement to ship the source to all files in the source package that are used to generate the binary package? I always thought it was the latter, and your mail seems to say that as well, but the original email indicates the former. I'm still surprised that I had to start stripping out javascript files in the Sphinx-generated documentation from upstream tarballs, despite the documentation being completely removed and regenerated during the build. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r44bpmof@vostro.rath.org
Re: Non-source Javascript files in upstream source
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com writes: 2014-04-26 07:51 Ben Finney: If it's in the Debian source package, it is distributed as part of Debian. (I'm assuming, from the lack of response to this point, that this is uncontroversial.) What's your position on 'configure' scripts for which we don't know if they are generated from the .ac? (Is there a good method to even test this?). Are they also missing the source? I don't have a special position on those; also, I'm not much of an expert on ‘configure’ and its generated files. My general position is: If it's in the Debian source package, it is thereby part of Debian; as part of Debian, the Debian Social Contract promises every recipient that the corresponding source must be in Debian; for that promise to be sound, we need to have independent verification. If we dismiss the need for that verification, then we are not serious about that promise. What part are you saying is “not a universally held view”, and how do you reconcile that with the Debian Social Contract? My understanding is that SC and DFSG, similarly to the definition of Free Software by FSF and other efforts, were devised to promote user freedom when using and modifying software, etc. Yes. Every Debian source package is software; every Debian recipient has a promise of freedom in that software, to modify it and redistribute the result. If we ship a non-source file without being able to verifiably demonstrate the corresponding source to that file is in Debian, we shouldn't pretend to make that promise. If the consequence of following SC and DFS *Guidelines* (SC#1 refer to it) does not further these goals, it is an exercise in futility, and thus not worth doing in my opinion. I'hope you're in agreement that a Debian source package is software, and every recipient of that package deserves all the freedoms promised in the Social Contract. Interpreting SC or DFSG (or any law or guideline, for that matter) without thinking of the utility, the costs or the consequences, does not seem very wise to me. If the consequence is to dismiss a promise of freedom to Debian recipients, I think that's an unbearable cost. source-is-missing is not important if we (or the users) don't need, or even use or want, the source or the derived file. It's not for you, or me, or anyone else, to decide which part of the freedoms we've promised to Debian recipients are unimportant to those recipients. It's for them to decide — unilaterally, without consulting us to see whether we still feel like honouring our promise. And if they want to use/modify it, they can easily get it Can they get the corresponding source? Or are you saying it's unimportant to get the *corresponding* source for a bundled non-source file, but sufficient to offer some other source that no-one has determined is the corresponding source for the file in question? and in fact it is *better* if they get it from JQuery upstream (or our canonical Debian package) than from the upstream project that ships it (more recent fixes, etc). That's assuming the bundled file *is* functionally identical. How its that determined? Do you agree it's important to determine that, given the promises that the corresponding source is in Debian for every part of Debian? And, if it is a non-source file that we *know* is functionally identical to something we already ship in Debian, why would we bundled in the source package, risking divergent copies? Every person with knowledge about how to modify the minified JQuery, or to ask some other person to do it for them, will know (the minified file tells them) where to get the preferred form of modification, I don't know what “preferred form of modification” means. I assume you mean “preferred form of the work for modifying it”. As such, I think your assertion is suspect and likely false, as discussed above. And having minified+unminified would be just another case of embedded 3rd party libs. Yes, a case which should be eradicated as inviting unwanted and untracked divergent copies. -- \“You can't have everything; where would you put it?” —Steven | `\Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85bnvnkv53@benfinney.id.au
Re: Non-source Javascript files in upstream source
Ben Finney b...@benfinney.id.au writes: 2014-04-26 07:51 Ben Finney: If it's in the Debian source package, it is distributed as part of Debian. (I'm assuming, from the lack of response to this point, that this is uncontroversial.) You should probably not assume that. Rather, you should probably assume that most people are uninterested in having this argument for the 14th time. I continue to hold to my position that distributing sourceless files in source packages, provided they are under a free license and not used as part of the process of building binary package, is a nuisance rather than a meaningful DFSG violation and not worth spending project time and resources on. That said, I do understand why people want simple rules with no exceptions, even if those rules lead to moderately nonsensical corner cases. I very much doubt that further discussion of this is going to change anyone's mind, and I suspect we will simply continue to disagree on the requirements until such a time as someone proposes a GR to clarify this (if that ever happens). I don't care enough about the issue to do that myself. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a9b7udy3@windlord.stanford.edu
Re: Non-source Javascript files in upstream source
Russ Allbery r...@debian.org writes: Ben Finney b...@benfinney.id.au writes: 2014-04-26 07:51 Ben Finney: If it's in the Debian source package, it is distributed as part of Debian. You should probably not assume [that statement to be uncontroversial within the Debian project]. Thanks. I note, though, that your stated position doesn't contradict the above point: that Debian source packages are part of Debian. Rather, you should probably assume that most people are uninterested in having this argument for the 14th time. I can certainly sympathise with that. I continue to hold to my position that distributing sourceless files in source packages, provided they are under a free license and not used as part of the process of building binary package, is a nuisance rather than a meaningful DFSG violation and not worth spending project time and resources on. Okay. Is it accurate to say, then, that you and I agree these files are distributed as part of the Debian source package, and thereby part of Debian? If so, then I understand your position as being that, while these are sourceless files distribuited as part of Debian, they do not constitute a problem worth spending resources to address. -- \“There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85y4yqkgy3@benfinney.id.au
Re: Non-source Javascript files in upstream source
Ben Finney b...@benfinney.id.au writes: Okay. Is it accurate to say, then, that you and I agree these files are distributed as part of the Debian source package, and thereby part of Debian? Mu. I find this definition of the problem reductionist and overly simplistic and think there are various shades of grey in what part of Debian means. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhuquacl@windlord.stanford.edu
Re: Non-source Javascript files in upstream source
Hi all, I'm a bit disapointed. I don't know what to do. I try to fix following bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744317 Two files are pointed to have no upstream source. Theses files are html template files used by a javascript engine. If I understood, the problem is that theses files seems to be minified. The real problem is that it cannot works if theses are not in that format. How can it be fixed ? Regards, Nicolas 2014-04-27 16:15 GMT+02:00 Russ Allbery r...@debian.org: Ben Finney b...@benfinney.id.au writes: Okay. Is it accurate to say, then, that you and I agree these files are distributed as part of the Debian source package, and thereby part of Debian? Mu. I find this definition of the problem reductionist and overly simplistic and think there are various shades of grey in what part of Debian means. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhuquacl@windlord.stanford.edu
Re: Non-source Javascript files in upstream source
Jo Nicolas, You could generate the minified javascript from normal javascript files. I know that but non minified files don't work. It gives errors Uncaught SyntaxError: Unexpected token ILLEGAL
Re: Non-source Javascript files in upstream source
On 27/04/14, 06:18pm, Nicolas wrote: Jo Nicolas, You could generate the minified javascript from normal javascript files. I know that but non minified files don't work. It gives errors Uncaught SyntaxError: Unexpected token ILLEGAL Then the issue is with the source files. That's not right. If you want you can mail me privately and I will help you patching them. Maybe the actual upstream source has it right. Kind regards. -- Jose Luis Rivas -- GPG: 0xB9AC8C43 http://www.joseluisrivas.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140427102043.ga...@arya.ghostbar.co
Re: Non-source Javascript files in upstream source
On Sunday 27 April 2014 09:37 PM, Nicolas wrote: Hi all, I'm a bit disapointed. I don't know what to do. I try to fix following bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744317 Two files are pointed to have no upstream source. Theses files are html template files used by a javascript engine. If I understood, the problem is that theses files seems to be minified. The real problem is that it cannot works if theses are not in that format. How can it be fixed ? Jo Nicolas, You could generate the minified javascript from normal javascript files. Thanks Praveen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535d2cb0.5050...@debian.org
Re: Non-source Javascript files in upstream source (was: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699)
On April 25, 2014 11:02:29 PM Ben Finney wrote: Neil Williams codeh...@debian.org writes: On Fri, 25 Apr 2014 01:16:04 +0100 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I don't think that we should go and do the tedious work of repack thousands of packages because of this, with no real benefit in terms of freedom (or any other) for our users -- provided that we depend and link to the canonical versions in the binary packages. We promise the source for everything any recipient downloads as part of Debian. If non-source files are distributed in Debian source packages, without a way to confidently guarantee the corresponding source is what's already available in Debian, then that is a definite impact on the freedom of Debian recipients: it threatens the freedom promises in the Social Contract. That is certainly not a universally held view. Some of us [1] regard random trash littering the source distribution -- but not used in generating the actual software (binary distribution) -- as merely a nuisance that can be tolerated. I have to say that this absolutist zeal in scrubbing the source package grates on me for two reasons. FIrst, it introduces an undocumented difference between upstream source and Debian source. Second, it adds a bunch of busywork that distracts and, frankly, de-motivates me from working on packaging. [1] https://lists.debian.org/debian-devel/2014/03/msg00270.html -Steve signature.asc Description: This is a digitally signed message part.
Re: Non-source Javascript files in upstream source
Steve M. Robbins st...@sumost.ca writes: On April 25, 2014 11:02:29 PM Ben Finney wrote: We promise the source for everything any recipient downloads as part of Debian. If non-source files are distributed in Debian source packages, without a way to confidently guarantee the corresponding source is what's already available in Debian, then that is a definite impact on the freedom of Debian recipients: it threatens the freedom promises in the Social Contract. That is certainly not a universally held view. Some of us [1] regard random trash littering the source distribution -- but not used in generating the actual software (binary distribution) -- as merely a nuisance that can be tolerated. If it's in the Debian source package, it is distributed as part of Debian. If it's distributed as part of Debian, it is subject to the promises in the Debian Social Contract. Those promises include the promise that anything in Debian has its source in Debian. That promise entails a confident guarantee that the source corresponding to any non-source file – such as an obfuscated Javascript file's corresponding source form – is in Debian. What part are you saying is “not a universally held view”, and how do you reconcile that with the Debian Social Contract? I have to say that this absolutist zeal in scrubbing the source package grates on me for two reasons. FIrst, it introduces an undocumented difference between upstream source and Debian source. The difference should not be undocumented: the difference should be described in the package, and its rationale given. ‘README.source’ is a good place to document the difference. Second, it adds a bunch of busywork that distracts and, frankly, de-motivates me from working on packaging. I'm sorry you feel that way. I'm presenting what appear to me to be clear implications of the facts of the matter. Fortunately, we have people working on tools to make this significantly easier (e.g. nominating files to be automatically removed from downloaded upstream source; nominating files to be presented in the source package as corresponding source; etc.). So, please don't be disheartened! This is a situation that is eminently addressible in a manner conformant with the Social Contract, and work already being done to address it. -- \ “It is wrong to think that the task of physics is to find out | `\ how nature *is*. Physics concerns what we can *say* about | _o__) nature…” —Niels Bohr | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mwf8lh0y@benfinney.id.au
Re: Non-source Javascript files in upstream source
2014-04-26 07:51 Ben Finney: Steve M. Robbins st...@sumost.ca writes: On April 25, 2014 11:02:29 PM Ben Finney wrote: We promise the source for everything any recipient downloads as part of Debian. If non-source files are distributed in Debian source packages, without a way to confidently guarantee the corresponding source is what's already available in Debian, then that is a definite impact on the freedom of Debian recipients: it threatens the freedom promises in the Social Contract. That is certainly not a universally held view. Some of us [1] regard random trash littering the source distribution -- but not used in generating the actual software (binary distribution) -- as merely a nuisance that can be tolerated. If it's in the Debian source package, it is distributed as part of Debian. What's your position on 'configure' scripts for which we don't know if they are generated from the .ac? (Is there a good method to even test this?). Are they also missing the source? If the versions of autotools used by upstream generating code from the .ac into 'configure', not shipped in [almost?] any source packages, were not even ever packaged in Debian (or patched in upstream's distributions or local systems), we are missing the source (preferred form of modification) of 'configure' script as well. Svante explained in a previous e-mail of this thread a case with Makefile/.in/.am. This has important consequences, and IMO much more serious than the case of minified JS. If we regenerate 'configure' from the .ac for all packages, part of the tests and compilation flags at build time will change, most likely runtime behaviour will change as well. I think that there were even security problems reported recently related with this. If you agree that source-is-missing also applies in those cases, do you also think that we should immediately declare all source packages in Debian containing a 'configure' script as somehow non free (unless we can check unambigously that they were generated by the .ac), and emit lintian errors asking all the source packages are repackaged stripping the 'configure' script and regenerating from the .ac? Or what alternative solutions are acceptable for you? (I'm in favour of regenerating 'configure' scripts automatically as expressed in another recent thread, but because of ports and other practical purposes... and because they actually are a central part of building every package in which they are present. But I would also be against requiring to strip source packages of this file just because we don't know exactly where its source comes from -- that would be Very Silly and counter-productive). If it's distributed as part of Debian, it is subject to the promises in the Debian Social Contract. Those promises include the promise that anything in Debian has its source in Debian. [...] What part are you saying is “not a universally held view”, and how do you reconcile that with the Debian Social Contract? My understanding is that SC and DFSG, similarly to the definition of Free Software by FSF and other efforts, were devised to promote user freedom when using and modifying software, etc. If the consequence of following SC and DFS *Guidelines* (SC#1 refer to it) does not further these goals, it is an exercise in futility, and thus not worth doing in my opinion. Interpreting SC or DFSG (or any law or guideline, for that matter) without thinking of the utility, the costs or the consequences, does not seem very wise to me. source-is-missing is not important if we (or the users) don't need, or even use or want, the source or the derived file. And if they want to use/modify it, they can easily get it, and in fact it is *better* if they get it from JQuery upstream (or our canonical Debian package) than from the upstream project that ships it (more recent fixes, etc). Every person with knowledge about how to modify the minified JQuery, or to ask some other person to do it for them, will know (the minified file tells them) where to get the preferred form of modification, change them to their heart's content, and replace it. In principle most versions will work fine; and people who want to modify it will generally just grab the latest one from upstream, from another file their system or a Debian package, or elsewhere. So I think that not having the unminified file in the same source package doesn't have any practical negative consequence for users. I could be mistaken, though. I asked in several emails of the thread for people to provide realistic examples in which doing the huge *collective* work of repackaging thousands of source packages improves user freedom in any way, but I think that nobody provided an example. So unless/until somebody does that, I consider all this issue a futile effort (and by wasting time and energy of this, we are actually harming other aspects of Debian, etc...). I would wish it to stop before more maintainers spend time on this; but
Re: Non-source Javascript files in upstream source
[Manuel A. Fernandez Montecelo] If you agree that source-is-missing also applies in those cases, do you also think that we should immediately declare all source packages in Debian containing a 'configure' script as somehow non free (unless we can check unambigously that they were generated by the .ac) There's 2 reasons to care if configure was built from the configure.ac in the tarball. The immediately practical reason is to ensure that if we or our users need to patch it, we can patch the actual source, and still be able to build correctly. (These things do tend to bitrot if you don't watch them.) Basically that means always rebuilding from source - which is already a best practice in Debian. Not every package does it, but IMO every package _should_. The other reason to care is of course to comply with our free software guidelines. For that purpose, I think it's entirely reasonable to assume good faith in upstream. If we find out that some upstream intentionally tricks us by shipping a mismatching configure, just so they can point and laugh at the DFSG violation, the solution is very simple: remove the package from Debian, because such upstreams clearly can't be trusted not to trick us in more malicious ways. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426232014.gd4...@p12n.org
Re: Non-source Javascript files in upstream source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El 26/04/14, 06:20pm, Peter Samuelson escribió: [Manuel A. Fernandez Montecelo] If you agree that source-is-missing also applies in those cases, do you also think that we should immediately declare all source packages in Debian containing a 'configure' script as somehow non free (unless we can check unambigously that they were generated by the .ac) There's 2 reasons to care if configure was built from the configure.ac in the tarball. The immediately practical reason is to ensure that if we or our users need to patch it, we can patch the actual source, and still be able to build correctly. (These things do tend to bitrot if you don't watch them.) Basically that means always rebuilding from source - which is already a best practice in Debian. Not every package does it, but IMO every package _should_. The other reason to care is of course to comply with our free software guidelines. For that purpose, I think it's entirely reasonable to assume good faith in upstream. If we find out that some upstream intentionally tricks us by shipping a mismatching configure, just so they can point and laugh at the DFSG violation, the solution is very simple: remove the package from Debian, because such upstreams clearly can't be trusted not to trick us in more malicious ways. I think is unfair to compare `configure` files with minified JavaScript, starting by the fact that you can't read the minified JavaScript and distinguish if is doing something wrong compared with the source of the same un-minified JavaScript. I think is fine to ship these minified JS files as long as you have a reproducible way to show that is the same as the source. Maybe a dh script should be born for this and my head says the prototype may look like `dh_js_minify_reproduc --source source.js --output min.js - --rules-should-apply='--with-license --with-copyright' and throw an error if it's a mismatch. Kind regards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426232014.gd4...@p12n.org - -- Jose Luis Rivas -- GPG: 0xB9AC8C43 http://www.joseluisrivas.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlNcQeUACgkQOKCtW8rKsRhndwCfWOT9rNfsvyf9A+wNRH3G1xJr 03IAoL8NazLacbwzqYqjIqQxLlKu2EIR =z0qp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426233149.gc12...@arya.ghostbar.co
Re: Non-source Javascript files in upstream source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El 26/04/14, 06:20pm, Peter Samuelson escribió: [Manuel A. Fernandez Montecelo] If you agree that source-is-missing also applies in those cases, do you also think that we should immediately declare all source packages in Debian containing a 'configure' script as somehow non free (unless we can check unambigously that they were generated by the .ac) There's 2 reasons to care if configure was built from the configure.ac in the tarball. The immediately practical reason is to ensure that if we or our users need to patch it, we can patch the actual source, and still be able to build correctly. (These things do tend to bitrot if you don't watch them.) Basically that means always rebuilding from source - which is already a best practice in Debian. Not every package does it, but IMO every package _should_. The other reason to care is of course to comply with our free software guidelines. For that purpose, I think it's entirely reasonable to assume good faith in upstream. If we find out that some upstream intentionally tricks us by shipping a mismatching configure, just so they can point and laugh at the DFSG violation, the solution is very simple: remove the package from Debian, because such upstreams clearly can't be trusted not to trick us in more malicious ways. I think is unfair to compare `configure` files with minified JavaScript, starting by the fact that you can't read the minified JavaScript and distinguish if is doing something wrong compared with the source of the same un-minified JavaScript. I think is fine to ship these minified JS files as long as you have a reproducible way to show that is the same as the source. Maybe a dh script should be born for this and my head says the prototype may look like `dh_js_minify_reproduc --source source.js --output min.js - --rules-should-apply='--with-license --with-copyright' and throw an error if it's a mismatch. Kind regards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426232014.gd4...@p12n.org - -- Jose Luis Rivas -- GPG: 0xB9AC8C43 http://www.joseluisrivas.net/ - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426233149.gc12...@arya.ghostbar.co -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlNcVbEACgkQOKCtW8rKsRjmGQCfVPeh/hut08w4cnyIzmsNYi9W LcoAoIc6H549oQNmsXcMvYXZNAlIauXZ =Y5kV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140427005617.ga27...@arya.ghostbar.co
Non-source Javascript files in upstream source (was: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699)
Neil Williams codeh...@debian.org writes: On Fri, 25 Apr 2014 01:16:04 +0100 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I don't think that we should go and do the tedious work of repack thousands of packages because of this, with no real benefit in terms of freedom (or any other) for our users -- provided that we depend and link to the canonical versions in the binary packages. We promise the source for everything any recipient downloads as part of Debian. If non-source files are distributed in Debian source packages, without a way to confidently guarantee the corresponding source is what's already available in Debian, then that is a definite impact on the freedom of Debian recipients: it threatens the freedom promises in the Social Contract. Talk to upstream, get them to package the unminified JS or no JS in their releases, then minify during the build. If the built version matches a packaged version, then do the dh_link but not otherwise. One special problem with minified Javascript, in works that are web applications or components in particular, is that upstream commonly has: * No distinct “source”: They distribute only files that recipients are expected to use as-is. * Bundled third-party pre-compiled Javascript files, which the immediate upstream doesn't bother to get the source form, let alone make the source form available to recipients. * No managed “release”: they expect people to just get whatever is currently in the head revision of the VCS repository. * No automated “build”: they collate the bundle of files and expect recipients to simply deploy the downloaded files as-is. So in the case of many such upstreams, the discussion we'd like to have, focussed on “please separate the source Javascript in your release from the compiled result in the build”, quickly expands in scope because such a request can only be addressed by first introducing: * The concept of the package source as separate from the deployed result; * The concept of releasing such source in a form not intended for immediate as-is deployment; * The concept of maintaining such a source build for download; * The concept of obtaining the (frequently third-party) Javascript in source form rather than just passing along a pre-compiled file; * The concept of a separate build step to transform the source, as distributed, into a deployable application; * The concept that some recipients want to build from the upstream developer's source files on their own, independent of the upstream developer; and other related matters. Many such upstreams will, in my experience, when the discussion expands to encompass the all these concepts for which they perceive little need, attempt to wave the whole discussion off as too much effort to satisfy what appears to be a minority of recipients with bizarre requests. So tackling this issue with such upstreams requires a lot of education, diplomacy, patience, and respect for their position: these all tend to be problems that they've not felt the need to address to date, and as Debian maintainers we need to help them understand the benefits. None of this detracts from the truth of what you say: we need more dependable source distinct from build artefacts, more dependable source releases, more dependable build procedures, more dependable versioned APIs, etc. All of this feeds into the issues of freedom for the recipient of the work. -- \ “Some people have a problem, and they think “I know, I'll use | `\ Perl!”. Now they have some number of problems but they're not | _o__) sure whether it's a string or an integer.” —Benno Rice, 2011 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857g6dmuje.fsf...@benfinney.id.au
