Re: Minified javascript files
On Sat, Aug 25, 2012 at 12:27:02PM +0200, Jonas Smedegaard wrote: 1) We have the source for the parts that we ship in binary packages, yes. We do not, however, necessarily have the actual source for the minified files unused for binary packages yet redistributed by us in source tarballs: Just as with autotools files we generally do not verify that these files has same source as the source we instead use for our binary packages. That's true; however, it's a source of *potential* bugs, rather than definitely a bug in every such package, which is an improvement on the view that they violate the DFSG, where that would be the case. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120904194043.GA15040@debian
Re: Minified javascript files
On 08/29/2012 03:40 AM, Stefano Zacchiroli wrote: The point here is whether having non-free material, which is in distributed tarballs but hidden by dpkg-source, would constitute inclusion of non-free material in what we call Debian. (Of course we're talking about main here.) Personally, I wouldn't consider that acceptable. I agree. And with latest addition in uscan, we have no excuse anymore. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/503db18b.20...@debian.org
Re: Minified javascript files
Stefano Zacchiroli writes (Re: Minified javascript files): The problem I see with it, is that it adds complexity to the judgement of whether something is suitable for a source package or not (on all actors involved: maintainer, ftp-masters, QA, bug reporters, etc.). With something like that we'll have 3 cases: - DFSG-free source[1] - stay in the tarball, not hidden - non DFSG-free binary - must be removed, via repacking - binary generated from DFSG-free source available elsewhere in the archive - stay in the tarball, hidden at the dpkg-source level That's not what I was proposing. I was proposing that we would treat your 2nd and 3rd points identically. They would then be in our archive in the .orig.tar.gz files. If this is not ideologically[1] acceptable to other members of the project in your third case, then I think we should not do it at all even for the second case. [1] NB I do not mean to use ideological in a pejorative way. I am very comfortable with the idea that Debian might make decisions based on ideology. The root question being discussed here is IMO essentially ideological. If we do decide that we must remove the non-free parts from the tarballs, repacking upstream's sources, rather than just having them removed by dpkg-source during unpack, then I certainly welcome the provision of better tools to help with that. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20540.41973.750949.958...@chiark.greenend.org.uk
Re: Minified javascript files
On Tue, Aug 28, 2012 at 11:56:53AM +0100, Ian Jackson wrote: Stefano Zacchiroli writes (Re: Minified javascript files): The problem I see with it, is that it adds complexity to the judgement of whether something is suitable for a source package or not (on all actors involved: maintainer, ftp-masters, QA, bug reporters, etc.). With something like that we'll have 3 cases: - DFSG-free source[1] - stay in the tarball, not hidden - non DFSG-free binary - must be removed, via repacking - binary generated from DFSG-free source available elsewhere in the archive - stay in the tarball, hidden at the dpkg-source level That's not what I was proposing. I was proposing that we would treat your 2nd and 3rd points identically. They would then be in our archive in the .orig.tar.gz files. Right, that's, strictly speaking, not what you proposed. But it seems to me that to support the argument it's not SC violation because the source is available in a different package, you do need to perform such a distinction. Anyway, the most important part seems to be your ideological[1] question: If this is not ideologically[1] acceptable The point here is whether having non-free material, which is in distributed tarballs but hidden by dpkg-source, would constitute inclusion of non-free material in what we call Debian. (Of course we're talking about main here.) Personally, I wouldn't consider that acceptable. Even if I were ready to accept the idea that hidden for any reasonable purpose non-free material could be part of Debian tarballs (and I'm not), I wouldn't consider dpkg-source hiding good enough. The reason is that what to do with a .orig.tar.gz file --- invoking dpkg-source on it --- is obvious to anyone with Debian knowledge, but it is obscure to anyone else. A random *nix user with no Debian knowledge would just open it up, find non-free material, and be induced to conclude that it is part of Debian. For DFSG-related purposes dpkg-source hiding is just not enough, IMO. (Thought it'd still be fine for the 3rd case above.) Cheers. [1] same footnote of yours: [1] NB I do not mean to use ideological in a pejorative way. I am very comfortable with the idea that Debian might make decisions based on ideology. The root question being discussed here is IMO essentially ideological. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Minified javascript files
On 12-08-25 at 04:21pm, Pau Garcia i Quiles wrote: On Sat, Aug 25, 2012 at 12:09 PM, Stefano Zacchiroli z...@debian.org wrote: Another problem is that the DFSG-freeness of the material contained in a (source) package is no longer a local property. If one day the package containing the corresponding source vanishes from the archive, unrelated packages, possibly many of them, will become RC-instabuggy. I'd say it's not a problem. If one day the package containing the corresponding source vanishes from the archive, the other package (witty, in my case) would not be buildable, as witty build-depends on libjs-jquery. Witty may quite likely build fine with a newer jQuery, which does not include the sources for the then older one shipped minified with witty. - 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: Digital signature
Re: Minified javascript files
On 12-08-25 at 11:29pm, Stephen Kitt wrote: On Sat, 25 Aug 2012 12:27:02 +0200, Jonas Smedegaard d...@jones.dk wrote: 2) Each source and binary package (+ core parts) is considered a legal entity of its own. That's why we can refer to licensing texts existing in common-licenses, but for e.g. Apache license cannot refer to the text shipped with Apache but must repeat that text in each package. So (build-)depending on other packages is not enough - the required source must exist either in same package or in a core package. Not quite - there's Built-Using now as well, so a package can be built using source from another package, and as long as the appropriate Built-Using relationship is declared in the resulting binary packages all the required source packages will be preserved in the archives. Interesting. Where is that documented? I fail to locate it in Debian Policy 3.9.3.1 or Developers Reference 3.4.9 - the documents available for Debian Sid. Is this something that our ftp-masters agree with? More generally, where do one go to keep up-to-date on what is the standards used by Debian, if not Debian Policy and Developers Reference? - 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: Digital signature
Re: Minified javascript files
Le Sun, Aug 26, 2012 at 09:22:24AM +0200, Jonas Smedegaard a écrit : Interesting. Where is that documented? I fail to locate it in Debian Policy 3.9.3.1 or Developers Reference 3.4.9 - the documents available for Debian Sid. Hi Jonas, the Built-Using will documented in the next release of the Policy, thanks to the input of the FTP team. http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=4953fb7792b9fbe04c27dc817a2eb3cd9ab450b8 http://bugs.debian.org/641153 Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120826073733.gd1...@falafel.plessy.net
Re: Minified javascript files
On 12-08-26 at 04:37pm, Charles Plessy wrote: Le Sun, Aug 26, 2012 at 09:22:24AM +0200, Jonas Smedegaard a écrit : Interesting. Where is that documented? I fail to locate it in Debian Policy 3.9.3.1 or Developers Reference 3.4.9 - the documents available for Debian Sid. Hi Jonas, the Built-Using will documented in the next release of the Policy, thanks to the input of the FTP team. http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=4953fb7792b9fbe04c27dc817a2eb3cd9ab450b8 http://bugs.debian.org/641153 Ah, thanks. Have a nice Sunday, U2 :-) - 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: Digital signature
Re: Minified javascript files
On 08/26/2012 03:37 PM, Charles Plessy wrote: Hi Jonas, the Built-Using will documented in the next release of the Policy, thanks to the input of the FTP team. http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=4953fb7792b9fbe04c27dc817a2eb3cd9ab450b8 http://bugs.debian.org/641153 Have a nice Sunday, Interesting! If a package has Built-Using, where/how will the build dependency be downloaded? In /usr/src/package-name-version? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/503a4424.5000...@debian.org
Re: Minified javascript files
Hi Thomas, On Sun, 26 Aug 2012 23:43:32 +0800, Thomas Goirand z...@debian.org wrote: On 08/26/2012 03:37 PM, Charles Plessy wrote: the Built-Using will documented in the next release of the Policy, thanks to the input of the FTP team. http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=4953fb7792b9fbe04c27dc817a2eb3cd9ab450b8 http://bugs.debian.org/641153 Have a nice Sunday, Interesting! If a package has Built-Using, where/how will the build dependency be downloaded? In /usr/src/package-name-version? Built-Using doesn't determine behaviour before or during the build, it just records the fact that a binary package was built using some other (binary) package - the aim is to ensure that all the source code required to build a package is available in the archives. (So the Built-Using declaration actually uses the source package and version, not the binary package and version.) Take for example my gcc-mingw-w64 package: it build-depends on gcc-4.6-source which provides the gcc source and Debian patches; the build then uses those files to build gcc, and records the specific source version used in the Built-Using field in its binary packages. The declaration doesn't help me build the packages, it's just a record so that the archive tools can ensure we honour our license obligations and provide the exact source used to build the binaries we ship. I do something similar in my mednafen package: the mednafen source includes mini-lzo's source, which is also available in liblzo2-dev; to make security maintenance easier, the build copies mini-lzo from liblzo2-dev, so the resulting packages declare a Built-Using relationship on lzo2 (the source package). It doesn't help packages build using arbitrary source packages; it's only really useful for builds using -source packages (binutils-source, gcc-...-source, and so on), or builds using statically-linked libraries. Being able to build-depend on source packages would be nice but that's another discussion ;-). (Here's another Built-Using idea: automatic binNMUs when external source is updated...) Regards, Stephen signature.asc Description: PGP signature
Re: Minified javascript files
Thomas Goirand z...@debian.org writes: If a package has Built-Using, where/how will the build dependency be downloaded? In /usr/src/package-name-version? Build dependencies are installed in the same location that they're always installed; Built-Using doesn't change anything about the functioning of the package manager. Maybe you thought that Built-Using meant that the other *source* package is installed at build time? If so, no, that's not the case. Built-Using doesn't change anything about the build process; it only documents, for archive purposes, the location of additional source used to produce the binary package. -- 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: http://lists.debian.org/874nnpsggy@windlord.stanford.edu
Re: Minified javascript files
On Fri, Aug 24, 2012 at 07:13:01PM -0700, Russ Allbery wrote: The counter-argument from affected maintainers is that we *do* have the source. It just happens to be in a different source package. We even know that, because when we build the binary package we use the version of the Javascript library derived from that other source package. There is therefore no *actual* violation of the social contract here, just an inadequacy of bookkeeping. Agreed, which is why I too find Ian's proposal interesting. The problem I see with it, is that it adds complexity to the judgement of whether something is suitable for a source package or not (on all actors involved: maintainer, ftp-masters, QA, bug reporters, etc.). With something like that we'll have 3 cases: - DFSG-free source[1] - stay in the tarball, not hidden - non DFSG-free binary - must be removed, via repacking - binary generated from DFSG-free source available elsewhere in the archive - stay in the tarball, hidden at the dpkg-source level This is quite a bit of extra complexity. And it would require documenting not only that something is being removed at the dpkg-source level (the dpkg-source configuration file for the removal feature would suffice), but also documenting where the corresponding source is. Another problem is that the DFSG-freeness of the material contained in a (source) package is no longer a local property. If one day the package containing the corresponding source vanishes from the archive, unrelated packages, possibly many of them, will become RC-instabuggy. On the positive side, the proposed dpkg-source exclusion feature is interesting in its own right, to ensure that something included in the tarball does not interfere with the build process, as already mentioned. (Yes, that could be achieved in debian/rules via rm invocations, but having a declarative way of doing so would be preferable.) Cheers. [1] in the sense of preferred form of modification -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Minified javascript files
On 12-08-24 at 07:13pm, Russ Allbery wrote: Ben Finney ben+deb...@benfinney.id.au writes: It seems to me that the primary objection to the presence of these files without source is that they are then distributed as part of Debian, in the source package. That violates our social contract. The counter-argument from affected maintainers is that we *do* have the source. It just happens to be in a different source package. We even know that, because when we build the binary package we use the version of the Javascript library derived from that other source package. There is therefore no *actual* violation of the social contract here, just an inadequacy of bookkeeping. I see 2 issues here: 1) We have the source for the parts that we ship in binary packages, yes. We do not, however, necessarily have the actual source for the minified files unused for binary packages yet redistributed by us in source tarballs: Just as with autotools files we generally do not verify that these files has same source as the source we instead use for our binary packages. 2) Each source and binary package (+ core parts) is considered a legal entity of its own. That's why we can refer to licensing texts existing in common-licenses, but for e.g. Apache license cannot refer to the text shipped with Apache but must repeat that text in each package. So (build-)depending on other packages is not enough - the required source must exist either in same package or in a core package. - 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: Digital signature
Re: Minified javascript files
On Sat, Aug 25, 2012 at 12:09 PM, Stefano Zacchiroli z...@debian.org wrote: Another problem is that the DFSG-freeness of the material contained in a (source) package is no longer a local property. If one day the package containing the corresponding source vanishes from the archive, unrelated packages, possibly many of them, will become RC-instabuggy. I'd say it's not a problem. If one day the package containing the corresponding source vanishes from the archive, the other package (witty, in my case) would not be buildable, as witty build-depends on libjs-jquery. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakcbokv540myod_decwh5515t_ihk1mln2m6ixwn8biwptn...@mail.gmail.com
Re: Minified javascript files
On Sat, 25 Aug 2012 12:27:02 +0200, Jonas Smedegaard d...@jones.dk wrote: 2) Each source and binary package (+ core parts) is considered a legal entity of its own. That's why we can refer to licensing texts existing in common-licenses, but for e.g. Apache license cannot refer to the text shipped with Apache but must repeat that text in each package. So (build-)depending on other packages is not enough - the required source must exist either in same package or in a core package. Not quite - there's Built-Using now as well, so a package can be built using source from another package, and as long as the appropriate Built-Using relationship is declared in the resulting binary packages all the required source packages will be preserved in the archives. (I know this doesn't help in the minified JavaScript case.) Regards, Stephen signature.asc Description: PGP signature
Re: Minified javascript files
Bernd Zeimetz writes (Re: Minified javascript files): On 08/16/2012 08:59 PM, Marco d'Itri wrote: On Aug 16, Vincent Bernat ber...@debian.org wrote: I know this is tedious but what others think about this matter? This is another case in which the DFSG has become a religion to be followed in a literalist interpretation instead of a tool to be used for the purpose of advancing software freedom. I rarely share Marco's opinion, but this time I do. I agree. There are good reasons for being cautious about non-free stuff in source packages, but the way we do things now is pointless make-work. Better would be if we could teach dpkg-source to remove undesirable things, present in the original source tarball, from the unpacked source tree. Then they wouldn't be distracting/confusing and there would be no risk of using them by mistake but we wouldn't have to prat about rebuilding archives which might otherwise remain pristine. Doing it this way would also prevent accidental reintroduction of the undesired files into the source tree visible to Debian, which can happen if someone uploading a new upstream version forgets to launder the upstream source. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20535.29144.610789.729...@chiark.greenend.org.uk
Re: Minified javascript files
Raphael Hertzog writes (Re: Minified javascript files): I agree with you that it's useless work. But the ftpmasters believe that Debian is made of source and binary packages and that the content of the source package should respect DFSG #2 “The program must include source code[...]”. Maybe we should fix DFSG #2 to say “The program must include source code for all the files that gets installed in the Debian binary packages [...]“. I don't think this should be fixed by changing the DFSG. The DFSG is correct - sourceless minified js files, GFDL docs with invariant sections, gimp-generated pixmaps without the original gimp source, etc., are all Not Free Software. The question is simply a practical one: is it actually worth our while to repackage upstream sources to remove unused non-free (but redistributable) elements. Who does this benefit ? If it enhances anyone's freedom (or to put it another way, if failing to do it would risk harming anyone's freedom) then that would be a good reason to do it, but at the moment I don't see where that risk comes from. The effect is just to make us do work. The main objection, it seems to me, to the presence of these files is that removing them is the only sure way to make sure that the actual package build doesn't use them somehow. But that objective could be met by some kind of filtering by dpkg-source at unpack time. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20535.29720.103031.195...@chiark.greenend.org.uk
Re: Minified javascript files
Ian Jackson ijack...@chiark.greenend.org.uk writes: I don't think this should be fixed by changing the DFSG. The DFSG is correct - sourceless minified js files, GFDL docs with invariant sections, gimp-generated pixmaps without the original gimp source, etc., are all Not Free Software. I agree entirely with that paragraph. The main objection, it seems to me, to the presence of these files is that removing them is the only sure way to make sure that the actual package build doesn't use them somehow. That is one which has been discussed. I don't think it's the most compelling one though. It seems to me that the primary objection to the presence of these files without source is that they are then distributed as part of Debian, in the source package. That violates our social contract. This objection is unrelated to what our build process does with those files, or even whether the build process ignores them. By remaining in the source package, we are distributing them as part of Debian. Upholding the social contract – that Debian, as distributed by the Debian project, remain 100% free – is sufficient reason to remove these files without corresponding source. -- \ “Isn't it enough to see that a garden is beautiful without | `\ having to believe that there are fairies at the bottom of it | _o__) too?” —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: http://lists.debian.org/87k3wng29r@benfinney.id.au
Re: Minified javascript files
Ben Finney ben+deb...@benfinney.id.au writes: It seems to me that the primary objection to the presence of these files without source is that they are then distributed as part of Debian, in the source package. That violates our social contract. The counter-argument from affected maintainers is that we *do* have the source. It just happens to be in a different source package. We even know that, because when we build the binary package we use the version of the Javascript library derived from that other source package. There is therefore no *actual* violation of the social contract here, just an inadequacy of bookkeeping. -- 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: http://lists.debian.org/87ipc7ra6q@windlord.stanford.edu
Re: Minified javascript files
On Aug 25, Ben Finney ben+deb...@benfinney.id.au wrote: Upholding the social contract – that Debian, as distributed by the Debian project, remain 100% free – is sufficient reason to remove these files without corresponding source. As I said, this is a religious argument. It's OK, billions of people have a faith and your one appears to be literally following the DFSG. But let's not pretend that this in some way helps software to be more free, because it does not. -- ciao, Marco signature.asc Description: Digital signature
Re: Minified javascript files
m...@linux.it (Marco d'Itri) writes: On Aug 25, Ben Finney ben+deb...@benfinney.id.au wrote: Upholding the social contract – that Debian, as distributed by the Debian project, remain 100% free – is sufficient reason to remove these files without corresponding source. As I said, this is a religious argument. You'll need to explain better what you mean, then, because the argument makes no reference to any supernatural entities. It's OK, billions of people have a faith and your one appears to be literally following the DFSG. I don't know why you bring faith into this. -- \ “Nothing is so common as to imitate one's enemies, and to use | `\ their weapons.” —Voltaire, _Dictionnaire Philosophique_ | _o__) | Ben Finney pgp2I6oJgR9W4.pgp Description: PGP signature
Re: Minified javascript files
m...@linux.it (Marco d'Itri) writes: On Aug 25, Ben Finney ben+deb...@benfinney.id.au wrote: Upholding the social contract – that Debian, as distributed by the Debian project, remain 100% free – is sufficient reason to remove these files without corresponding source. As I said, this is a religious argument. You'll need to explain better what you mean, then, because the argument makes no reference to any supernatural entities. It's OK, billions of people have a faith and your one appears to be literally following the DFSG. I don't know why you bring faith into this, if not as a vague smear without addressing any points. -- \ “Nothing is so common as to imitate one's enemies, and to use | `\ their weapons.” —Voltaire, _Dictionnaire Philosophique_ | _o__) | Ben Finney pgp1hJzJ8KcHz.pgp Description: PGP signature
Re: Minified javascript files
[About yui-compressor] On 08/21/2012 02:49 AM, Vincent Bernat wrote: It is not used anymore and is therefore less tested and less trustworthy. Sorry for the dumb questions (which are kind of conflicting each other btw), but: - If the only problem is testing, can't it be tested, so we know? - If it's not trustworthy, why should it stay in Debian? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034bc6f.6080...@debian.org
Re: Minified javascript files
20.08.2012 11:33, Thomas Goirand пишет: So, could you tell in what way yui-compressor isn't considered not reliable enough? Does it crash? Or does it produce bad minified scripts? In which case: in what way bad? yui-compressor has a lot of dependencies :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034cdb4.8010...@gmail.com
Re: Minified javascript files
Hi, /me put on his yui-compressor maintainer hat ;) Le 22/08/2012 13:03, Thomas Goirand a écrit : [About yui-compressor] On 08/21/2012 02:49 AM, Vincent Bernat wrote: It is not used anymore and is therefore less tested and less trustworthy. Sorry for the dumb questions (which are kind of conflicting each other btw), but: - If the only problem is testing, can't it be tested, so we know? - If it's not trustworthy, why should it stay in Debian? IMHO, it's obvious that yui-compressor is not - anymore - the most efficient javascript minifier and better alternative exists. It's simply not used anymore by big players of Javascript libs (like jQuery) so it receives less attention (even from Yahoo for YUI). But I disagree on trustworthy argument : - yui-compressor have been used for years for javascript compression (way before closure-compiler or uglifyjs) so it can't be *that* bad - as casual user of yui-compressor, I have hardly seen failure to correctly minify javascript file - in Debian, I haven't received a bug report about any corner case So, from my point of view, it seems that we can at least try use it as a alterntive minifier of upstream official is not available in Debian. my 2 cents, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034d333.5060...@drazzib.com
Re: Minified javascript files
Le 22/08/2012 14:52, Simon Josefsson a écrit : Damien Raude-Morvan draz...@drazzib.com writes: IMHO, it's obvious that yui-compressor is not - anymore - the most efficient javascript minifier and better alternative exists. It's simply not used anymore by big players of Javascript libs (like jQuery) so it receives less attention (even from Yahoo for YUI). What is upstream jQuery using? Is it free software? Please, try to read all posts in thread before posting a question... it has already been explained. jQuery now use Grunt as build system. It's grunt who automatically lint files with JSLint and minify files with UglifyJS [1]. UglifyJS is under BSD licence and, AFAIK, is already packaged for Debian but blocked by freeze of nodejs package : http://bugs.debian.org/684044 [1] https://github.com/mishoo/UglifyJS/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034d971.4050...@drazzib.com
Re: Minified javascript files
Damien Raude-Morvan draz...@drazzib.com writes: IMHO, it's obvious that yui-compressor is not - anymore - the most efficient javascript minifier and better alternative exists. It's simply not used anymore by big players of Javascript libs (like jQuery) so it receives less attention (even from Yahoo for YUI). What is upstream jQuery using? Is it free software? /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d32jay22@latte.josefsson.org
Re: Minified javascript files
On 08/17/2012 10:21 PM, Raphael Hertzog wrote: Hi, On Fri, 17 Aug 2012, Luca Falavigna wrote: 2012/8/17 Bernd Zeimetz be...@bzed.de: But it usually does and also results in a source tarball which is missing essential pieces of the software, so people who download it for non-Debian usage will fail to run the shipped source just because we removed an otherwise free piece of software. This does not make sense if the removed pieces are useless, as the core of this discussion is about. They are not useless if you take the pristine source which is the situation that was described by Bernd. When we remove files we often have to do supplementary modifications (debian/patches/ or add symlink at the proper place) to get the software to work again... for example changing the path where the libraries are expected to be found. Also please remember the Social Contract: Our priorities are our users and free software. If I would remove an otherwise free piece of software I'm not using in the binary package just because the original, non-minified version of it is missing, I think that I would violate the SC. If the opinion of the ftp-masters is different from mine I think we might need a GR to solve this issue. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034e837.4050...@bzed.de
Re: Minified javascript files
On 08/22/2012 10:09 PM, Bernd Zeimetz wrote: Also please remember the Social Contract: Our priorities are our users and free software. If I would remove an otherwise free piece of software I'm not using in the binary package just because the original, non-minified version of it is missing, I think that I would violate the SC. Did you miss the word *free* in free software? It's actually a quite important word... ;) I'm afraid I don't agree with your reading of the SC. I believe we want the *full* source code of what we release. While I can agree that removing the minified version of a javascript script from the original source might be seen as (arguably) a little bit extreme and annoying (but I do respect this view), I really think we *do* need the normal non-minified version of every script and build from that. I don't think anyone else has argued otherwise in this thread (please correct me if I'm wrong here...), we have only been discussing removing the minified version from the original sources only (but didn't discuss the fact the non-minified version should be there *always*). Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5035208c.2070...@debian.org
Re: Minified javascript files
Thomas Goirand z...@debian.org writes: While I can agree that removing the minified version of a javascript script from the original source might be seen as (arguably) a little bit extreme and annoying (but I do respect this view), I really think we *do* need the normal non-minified version of every script and build from that. I don't think anyone else has argued otherwise in this thread (please correct me if I'm wrong here...), we have only been discussing removing the minified version from the original sources only (but didn't discuss the fact the non-minified version should be there *always*). I think the debate in this thread is about whether it makes sense to require removing the minimized version from the upstream source when we don't install that file or otherwise use it in the binary package (because the binary package depends on the separately-packaged version of the same Javascript library, which already has both the minimized and non-minimized version and fully satisfies the DFSG). -- 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: http://lists.debian.org/87obm27pan@windlord.stanford.edu
Re: Minified javascript files
On Wed, Aug 22, 2012 at 8:30 PM, Russ Allbery r...@debian.org wrote: I think the debate in this thread is about whether it makes sense to require removing the minimized version from the upstream source when we don't install that file or otherwise use it in the binary package (because the binary package depends on the separately-packaged version of the same Javascript library, which already has both the minimized and non-minimized version and fully satisfies the DFSG). That's exactly the point IMHO, it's just one more useless file in upstream's tarball. While working today on Wt again, I've noticed if I were to repackage the upstream tarball to remove jquery.min.js, I would also remove the Doxygen-generated HTML apidox. After all, I'm also regenerating them, therefore to me it's just a few thousands of useless files in upstream's tarball. But what's FTP masters stance on this? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakcbokskacx5v8eqjcgqoy9sn6sd76kkkge8cmpwq-64nxf...@mail.gmail.com
Re: Minified javascript files
Pau Garcia i Quiles pgqui...@elpauer.org writes: While working today on Wt again, I've noticed if I were to repackage the upstream tarball to remove jquery.min.js, I would also remove the Doxygen-generated HTML apidox. After all, I'm also regenerating them, therefore to me it's just a few thousands of useless files in upstream's tarball. But what's FTP masters stance on this? I don't think ftp-master particularly cares what additional scrubbing you do once you have to repackage upstream. If you don't have to repackage upstream, there's a strong preference that you don't do so, but once you go down that path, I don't think anyone is particularly concerned with what else you change provided that it's generally sensible. Either one can verify checksums with the upstream release or one can't. I drop the Windows code and the products of upstream's autogen.sh in one of my packages for similar reasons; it saves a few MB of archive space for code that's never used in Debian, and I have to repackage upstream anyway, so why not. -- 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: http://lists.debian.org/87vcga1p4c@windlord.stanford.edu
Re: Minified javascript files
❦ 23 août 2012 01:01 CEST, Pau Garcia i Quiles pgqui...@elpauer.org : I think the debate in this thread is about whether it makes sense to require removing the minimized version from the upstream source when we don't install that file or otherwise use it in the binary package (because the binary package depends on the separately-packaged version of the same Javascript library, which already has both the minimized and non-minimized version and fully satisfies the DFSG). That's exactly the point IMHO, it's just one more useless file in upstream's tarball. While working today on Wt again, I've noticed if I were to repackage the upstream tarball to remove jquery.min.js, I would also remove the Doxygen-generated HTML apidox. After all, I'm also regenerating them, therefore to me it's just a few thousands of useless files in upstream's tarball. But what's FTP masters stance on this? You don't need to reove the doxygen documentation since the source is also present in the tarball. -- Follow each decision as closely as possible with its associated action. - The Elements of Programming Style (Kernighan Plauger) pgpNkdnmA4fFd.pgp Description: PGP signature
Re: Minified javascript files
On Mon, Aug 20, 2012 at 10:26:40AM +0200, Marco d'Itri wrote: Very important, anybody who deals with web scalability knows that javascript minification is one of the first and easier steps you take to improve performance. The current situation is just sad, and it reflects quite badly on the viability on Debian as a serious OS. If our main problem to become a serious OS in your view is Javascript minification, I'm quite happy. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Minified javascript files
On 08/19/2012 09:49 PM, Vincent Bernat wrote: As for verification, having the source next to the minified version does not guarantee anything about the minified version Right, which is why we should build from source (eg: minify ourselves the javascript libs). all the more that we don't have currently in Debian Wheezy a reliable minifier. This is the first time I read this. have you tried yui-compressor? Isn't it good enough? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5031e72d.60...@debian.org
Re: Minified javascript files
On 08/20/2012 03:23 AM, Simon Josefsson wrote: I believe differences like that are not important, compare how gcc generate different binaries each time depending on parameters etc. However, if a minified file is shipped that cannot be re-created at all (due to no minifier) I don't think shipping source for the file is the only problem. Both source code and the tools needed to generate output forms is needed for users to be able to use a modified version of the program. /Simon If it's that hard to produce a minified version, then shouldn't we use the normal version? How much speed-up do we really get anyway (my wild guess: not much...)? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5031e7be.80...@debian.org
Re: Minified javascript files
On 08/20/2012 03:34 AM, Vincent Bernat wrote: Other minifiers (like yui-compressor) are considered not reliable enough. Sorry that I asked you about this before reading this. So, could you tell in what way yui-compressor isn't considered not reliable enough? Does it crash? Or does it produce bad minified scripts? In which case: in what way bad? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5031e84c.7020...@debian.org
Re: Minified javascript files
On Aug 20, Thomas Goirand z...@debian.org wrote: If it's that hard to produce a minified version, then shouldn't we use the normal version? How much speed-up do we really No. get anyway (my wild guess: not much...)? Very important, anybody who deals with web scalability knows that javascript minification is one of the first and easier steps you take to improve performance. The current situation is just sad, and it reflects quite badly on the viability on Debian as a serious OS. -- ciao, Marco signature.asc Description: Digital signature
Re: Minified javascript files
❦ 20 août 2012 09:33 CEST, Thomas Goirand z...@debian.org : Other minifiers (like yui-compressor) are considered not reliable enough. Sorry that I asked you about this before reading this. So, could you tell in what way yui-compressor isn't considered not reliable enough? Does it crash? Or does it produce bad minified scripts? In which case: in what way bad? It is not used anymore and is therefore less tested and less trustworthy. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679665 -- panic(Detected a card I can't drive - whoops\n); 2.2.16 /usr/src/linux/drivers/net/daynaport.c pgp5Yi3ZboYYa.pgp Description: PGP signature
Re: Minified javascript files
❦ 20 août 2012 09:31 CEST, Thomas Goirand z...@debian.org : I believe differences like that are not important, compare how gcc generate different binaries each time depending on parameters etc. However, if a minified file is shipped that cannot be re-created at all (due to no minifier) I don't think shipping source for the file is the only problem. Both source code and the tools needed to generate output forms is needed for users to be able to use a modified version of the program. /Simon If it's that hard to produce a minified version, then shouldn't we use the normal version? How much speed-up do we really get anyway (my wild guess: not much...)? See: $ ls -lh jquery* -rw-r--r-- 1 bernat users 247K août 20 20:52 jquery.js -rw-r--r-- 1 bernat users 81K août 20 20:52 jquery.js.gz -rw-r--r-- 1 bernat users 93K août 20 20:53 jquery.min.js -rw-r--r-- 1 bernat users 37K août 20 20:52 jquery.min.js.gz A 44KB difference is pretty important for mobile users (which have poor bandwidth and poor latency which makes bandwidth available at the beginning of a TCP connection low). -- Make sure your code does nothing gracefully. - The Elements of Programming Style (Kernighan Plauger) pgpZw9FPcdckX.pgp Description: PGP signature
Re: Minified javascript files
* Vincent Bernat ber...@debian.org [120818 21:18]: The difference is that we need to bug upstream about a file that we won't even use. There is no real bug (not even a licensing issue). They are distributing files without source, so everyone else can either not just easily modify it or verify if it really does what it is supposed to do. This is definitely a shortcoming in what upstream ships and really something you should bug upstream about. We request him to add a file that we won't use anyway. There is more than just us. If it is for us, they could just remove the file. It's for the people that those files is supposed to be for. They should have the right to change it, for which they effectively need the source. I don't know many upstream who have so much free time. If just adding a source file they hopefully have anyway or to remove a file does not take much time. (There is a lot of unmaintained software out there, but as I said, not much difference to getting any other patch in). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120819131132.ga9...@client.brlink.eu
Re: Minified javascript files
❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org : The difference is that we need to bug upstream about a file that we won't even use. There is no real bug (not even a licensing issue). They are distributing files without source, so everyone else can either not just easily modify it or verify if it really does what it is supposed to do. This is definitely a shortcoming in what upstream ships and really something you should bug upstream about. The source is one link away. People wanting the source just have to click on the link in the header of the minified version. As for verification, having the source next to the minified version does not guarantee anything about the minified version, all the more that we don't have currently in Debian Wheezy a reliable minifier. We request him to add a file that we won't use anyway. There is more than just us. If it is for us, they could just remove the file. It's for the people that those files is supposed to be for. They should have the right to change it, for which they effectively need the source. Your use case is inexistant. Regular people needing the source will grab it at http://jquery.com. I don't know many upstream who have so much free time. If just adding a source file they hopefully have anyway or to remove a file does not take much time. (There is a lot of unmaintained software out there, but as I said, not much difference to getting any other patch in). No, upstream usually don't have the source. They download the minified version from jQuery website. And no upstream will remove a file that is useful for 99.999% of his users just to please one Debian maintainer. -- Modularise. Use subroutines. - The Elements of Programming Style (Kernighan Plauger) pgpNUT2TYscKI.pgp Description: PGP signature
Re: Minified javascript files
Vincent Bernat ber...@debian.org writes: ❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org : They are distributing files without source, so everyone else can either not just easily modify it or verify if it really does what it is supposed to do. This is definitely a shortcoming in what upstream ships and really something you should bug upstream about. The source is one link away. People wanting the source just have to click on the link in the header of the minified version. As for verification, having the source next to the minified version does not guarantee anything about the minified version, all the more that we don't have currently in Debian Wheezy a reliable minifier. Right. Debian's current policies here aren't exactly wrong. In an ideal world, we would indeed always provide source next to everything, and that's a good goal. But this is a very hard sell upstream, whose immediate reaction is There are copies of the unminified source of jquery all over the net -- you can't throw a rock without hitting one! Why am I responsible for shipping the 48,194th copy? There really isn't any feasible scenario in which someone wanting to modify the package can't find the relevant source (*provided* that they haven't modified jquery or the similar Javascript library first before minimizing it, but that's quite rare). -- 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: http://lists.debian.org/87a9xqepzo@windlord.stanford.edu
Re: Minified javascript files
Vincent Bernat ber...@debian.org writes: ❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org : The difference is that we need to bug upstream about a file that we won't even use. There is no real bug (not even a licensing issue). They are distributing files without source, so everyone else can either not just easily modify it or verify if it really does what it is supposed to do. This is definitely a shortcoming in what upstream ships and really something you should bug upstream about. The source is one link away. People wanting the source just have to click on the link in the header of the minified version. As for verification, having the source next to the minified version does not guarantee anything about the minified version, all the more that we don't have currently in Debian Wheezy a reliable minifier. That seems problematic -- so even if the source is shipped, there is no way to re-build the minified file? /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boi64ut2@latte.josefsson.org
Re: Minified javascript files
On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson si...@josefsson.org wrote: As for verification, having the source next to the minified version does not guarantee anything about the minified version, all the more that we don't have currently in Debian Wheezy a reliable minifier. That seems problematic -- so even if the source is shipped, there is no way to re-build the minified file? It really depends on using exactly the same version of the same minifier with exactly the same parameters (which you may not know) and even then you cannot be sure, e. g. a minifier may use generate shortened variable names randomly. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcBoku94n7aqPsw3AYTZu=i84drkT=yqp9ayw-enpyrgzf...@mail.gmail.com
Re: Minified javascript files
Pau Garcia i Quiles pgqui...@elpauer.org writes: On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson si...@josefsson.org wrote: As for verification, having the source next to the minified version does not guarantee anything about the minified version, all the more that we don't have currently in Debian Wheezy a reliable minifier. That seems problematic -- so even if the source is shipped, there is no way to re-build the minified file? It really depends on using exactly the same version of the same minifier with exactly the same parameters (which you may not know) and even then you cannot be sure, e. g. a minifier may use generate shortened variable names randomly. I believe differences like that are not important, compare how gcc generate different binaries each time depending on parameters etc. However, if a minified file is shipped that cannot be re-created at all (due to no minifier) I don't think shipping source for the file is the only problem. Both source code and the tools needed to generate output forms is needed for users to be able to use a modified version of the program. /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gsu4rfs@latte.josefsson.org
Re: Minified javascript files
❦ 19 août 2012 20:10 CEST, Simon Josefsson si...@josefsson.org : They are distributing files without source, so everyone else can either not just easily modify it or verify if it really does what it is supposed to do. This is definitely a shortcoming in what upstream ships and really something you should bug upstream about. The source is one link away. People wanting the source just have to click on the link in the header of the minified version. As for verification, having the source next to the minified version does not guarantee anything about the minified version, all the more that we don't have currently in Debian Wheezy a reliable minifier. That seems problematic -- so even if the source is shipped, there is no way to re-build the minified file? Not in Debian Wheezy. The most up-to-date minifier, uglifyjs, has suffered from the node.js name transition and is not currently available in wheezy. Other minifiers (like yui-compressor) are considered not reliable enough. Therefore, currently, we offer only uncompressed version of jQuery. -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan Plauger) pgpQQQuSzsTgn.pgp Description: PGP signature
Re: Minified javascript files
On 12-08-19 at 08:10pm, Simon Josefsson wrote: Vincent Bernat ber...@debian.org writes: ❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org : The difference is that we need to bug upstream about a file that we won't even use. There is no real bug (not even a licensing issue). They are distributing files without source, so everyone else can either not just easily modify it or verify if it really does what it is supposed to do. This is definitely a shortcoming in what upstream ships and really something you should bug upstream about. The source is one link away. People wanting the source just have to click on the link in the header of the minified version. As for verification, having the source next to the minified version does not guarantee anything about the minified version, all the more that we don't have currently in Debian Wheezy a reliable minifier. That seems problematic -- so even if the source is shipped, there is no way to re-build the minified file? In Wheezy we have the minifier yui-compressor which probably(!) doesn't produce broken code but is not the most efficient at its job. I say probably, because regression testing is uncommon, and the environment for which is must work is often alien (e.g. compile on Debian but run the code in Internet Explorer in Windows), so broken JavaScript may go unnoticed for some time. Because yui-compressor is not the most efficient at minifying, it receives less testing, which also leads to potential bugs going unnoticed for longer time. For status of uglifyjs - the minifier used upstream for e.g. jQuery, see http://bugs.debian.org/684044 Regards, - 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: Digital signature
Re: Minified javascript files
On Fri, 17 Aug 2012 23:48:32 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Fri, Aug 17, 2012 at 07:50:39PM +, Sam Morris wrote: tcltrf (source) * win/msvcrt.dll This is part of Windows. I don't expect Debian has been granted permission to distribute it. :) It's the run-time library for Microsoft Visual C++ and is, as I recall, distributable along with applications that are built using that compiler. In fact, it is *recommended* to distribute it with applications. However, various applications bundled with Windows also need it, so in practice you can get away without doing this if you're sure your application doesn't depend on any newer features. Since Windows 2000 and Visual C++ 7, msvcrt.dll is part of Windows and isn't redistributable; the redistributable runtimes carry a version number in their name (msvcr71.dll etc.) and are supposed to be redistributed within their own installer (vcredist.exe and co.). The DLL included in the tcltrf source is older though (version 5 corresponds to Visual Studio 97) and dates back to a time when it was supposed to be redistributed (albeit restrictively, see below)... See http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.110%29.aspx for detais on current versions of Visual C++. http://kegel.com/wine/isv/visual-studio-6-EULA.html is a copy of the Visual Studio 6 which would be similar to that covering the DLL in tcltrf. Section 4 covers the distribution requirements; in particular, we're supposed to limit others' distribution rights so the DLL can't be redistributed outwith the accompanying software requiring it. I doubt it could be considered DFSG-free by any interpretation; what's more tcltrf's source is already repacked so removing the DLL shouldn't be too onerous. I've filed a bug; it might affect oldstable too, I'll check later. Regards, Stephen signature.asc Description: PGP signature
Re: Minified javascript files
On Fri, Aug 17, 2012 at 04:43:51PM +0600, Andrey Rahmatullin wrote: On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote: So yes, we have the problem for precompiled windows DLLs in a source package. Interesting, that issue seems rather common. Maybe a lintian check could alarm packagers of this? http://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html I hereby suggest rewording the description and/or raising the severity of this tag. -- WBR, wRAR signature.asc Description: Digital signature
Re: Minified javascript files
* Raphael Hertzog hert...@debian.org [120817 14:04]: That way, there's no need to strip unused RFC, minified javascript, Flash files, PDF without sources, etc. Striping them away is only the forth best solution. There are some better solutions like: - make upstream include the sources - include the sources yourself - make upstream not include files without source That might not always be easy, but it's not different from getting any other fixes upstream. All this has been useless bureaucracy which has drawn people away. If people are drawn away by someone caring for the freedom of our users, perhaps they are not really a loss. /scnr Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120818174632.ga8...@client.brlink.eu
Re: Minified javascript files
* Pau Garcia i Quiles pgqui...@elpauer.org, 2012-08-17, 13:39: 3) Make a new source package containing every jQuery version existing in the wild, then build depend on that. FTP Masters do not like that solution. Interesting. Do you have any evidence for that? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120818180649.ga8...@jwilk.net
Re: Minified javascript files
❦ 18 août 2012 19:46 CEST, Bernhard R. Link brl...@debian.org : That way, there's no need to strip unused RFC, minified javascript, Flash files, PDF without sources, etc. Striping them away is only the forth best solution. There are some better solutions like: - make upstream include the sources - include the sources yourself - make upstream not include files without source That might not always be easy, but it's not different from getting any other fixes upstream. The difference is that we need to bug upstream about a file that we won't even use. There is no real bug (not even a licensing issue). We request him to add a file that we won't use anyway. I don't know many upstream who have so much free time. All this has been useless bureaucracy which has drawn people away. If people are drawn away by someone caring for the freedom of our users, perhaps they are not really a loss. /scnr If the chosen solution is to repack (which does not involve arguing with upstream about it), I don't really see what difference it will make on the freedom of our users to keep or not such a file. We are talking about unused files whose license allows redistribution. -- Don't compare floating point numbers just for equality. - The Elements of Programming Style (Kernighan Plauger) pgphOkBPezu5U.pgp Description: PGP signature
Re: Minified javascript files
On Sat, Aug 18, 2012 at 8:06 PM, Jakub Wilk jw...@debian.org wrote: * Pau Garcia i Quiles pgqui...@elpauer.org, 2012-08-17, 13:39: 3) Make a new source package containing every jQuery version existing in the wild, then build depend on that. FTP Masters do not like that solution. Interesting. Do you have any evidence for that? I'll look for the mail (maybe my memory fails) but even if FTP Masters accept that as a solution, it looks insane to me: if every package which build-depends on jQuery needs to include the full jQuery source, why do we build-depend on jQuery at all? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcBokvCF=juhfuad41dxmutbxjrbzhykwnlq+nkts_r+k5...@mail.gmail.com
Re: Minified javascript files
* Vincent Bernat ber...@debian.org, 2012-08-16, 19:24: 1. The license allows redistribution and modification of the minified version without having the sources. Therefore, we are only dealing with DFSG here. While jQuery license is permissive, it does impose certain conditions[0] on distributors. In my experience, upstreams often fail to fulfil these requirements. 3. Repacking the original tarball just to remove those files is extra work. Part of the problem is that we lack good tools to do this extra work for us. Really, repacking shouldn't be a tedious operation, it shouldn't take more than 5 seconds, it shouldn't require writing two dozens lines of code and documentation. :( [0] “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120817073904.ga3...@jwilk.net
Re: Minified javascript files
On Thu, Aug 16, 2012 at 08:59:55PM +0200, Marco d'Itri wrote: On Aug 16, Vincent Bernat ber...@debian.org wrote: I know this is tedious but what others think about this matter? This is another case in which the DFSG has become a religion to be followed in a literalist interpretation instead of a tool to be used for the purpose of advancing software freedom. I'd regard using an untouched source and using just the Debian packaged version of the library (and thus ignoring the upstream shiped copy / minimisation in the binary package) as common sense. IMHO DFSG should not conflict with common sense and if this is the case we might consider fixing it. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120817082412.gc2...@an3as.eu
Re: Minified javascript files
On 08/17/2012 09:39 AM, Jakub Wilk wrote: * Vincent Bernat ber...@debian.org, 2012-08-16, 19:24: 1. The license allows redistribution and modification of the minified version without having the sources. Therefore, we are only dealing with DFSG here. While jQuery license is permissive, it does impose certain conditions[0] on distributors. In my experience, upstreams often fail to fulfil these requirements. 3. Repacking the original tarball just to remove those files is extra work. Part of the problem is that we lack good tools to do this extra work for us. Really, repacking shouldn't be a tedious operation, it shouldn't take more than 5 seconds, it shouldn't require writing two dozens lines of code and documentation. :( But it usually does and also results in a source tarball which is missing essential pieces of the software, so people who download it for non-Debian usage will fail to run the shipped source just because we removed an otherwise free piece of software. [0] “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502e0675.3040...@bzed.de
Re: Minified javascript files
On 08/17/2012 09:40 AM, Paul Wise wrote: On Fri, Aug 17, 2012 at 1:24 AM, Vincent Bernat wrote: What I didn't know until recently is that the minified version in the source package should be removed (or the appropriate full version should be appended). Do we also require that for say, precompiled DLLs of GTK+ or SDL for Windows platforms? I had the OpenSSL dll for windows embedded in one of my source packages, because there was some windows software together with it. I had to remove it completely, as I was asked to have the source code for it, and I found ridiculous to embed the sources of OpenSSL too. So yes, we have the problem for precompiled windows DLLs in a source package. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502e09bf.9030...@debian.org
Re: Minified javascript files
Hi there! On Fri, 17 Aug 2012 10:53:09 +0200, Bernd Zeimetz wrote: On 08/17/2012 09:39 AM, Jakub Wilk wrote: * Vincent Bernat ber...@debian.org, 2012-08-16, 19:24: 3. Repacking the original tarball just to remove those files is extra work. Part of the problem is that we lack good tools to do this extra work for us. Really, repacking shouldn't be a tedious operation, it shouldn't take more than 5 seconds, it shouldn't require writing two dozens lines of code and documentation. :( But it usually does and also results in a source tarball which is missing essential pieces of the software, so people who download it for non-Debian usage will fail to run the shipped source just because we removed an otherwise free piece of software. I fully agree with Bernd here: if what we want to remove is under a free license, then I would not repack the original tarball simply because we do not use it. Thx, bye, Gismo / Luca pgpKpAjCBu2jJ.pgp Description: PGP signature
Re: Minified javascript files
Thomas Goirand z...@debian.org writes: On 08/17/2012 09:40 AM, Paul Wise wrote: On Fri, Aug 17, 2012 at 1:24 AM, Vincent Bernat wrote: What I didn't know until recently is that the minified version in the source package should be removed (or the appropriate full version should be appended). Do we also require that for say, precompiled DLLs of GTK+ or SDL for Windows platforms? I had the OpenSSL dll for windows embedded in one of my source packages, because there was some windows software together with it. I had to remove it completely, as I was asked to have the source code for it, and I found ridiculous to embed the sources of OpenSSL too. So yes, we have the problem for precompiled windows DLLs in a source package. Interesting, that issue seems rather common. Maybe a lintian check could alarm packagers of this? See below for a list of *.dll files in packages starting with 'a' only. Overall, I found *.dll files in around 131 packages (of course not all of those represent a problem). /Simon ./abe_1.1.orig.tar.gz:abe-1.1/SDL.dll ./abe_1.1.orig.tar.gz:abe-1.1/SDL_mixer.dll ./activemq_5.6.0+dfsg.orig.tar.gz:activemq-5.6.0+dfsg/assembly/src/release/bin/win64/wrapper.dll ./alpine_2.02.orig.tar.gz:re-alpine-2.02/alpine/ldap32.dll ./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/debug/ldap32.dll ./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/debug/libldap.dll ./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/release/ldap32.dll ./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/release/libldap.dll ./altos_1.0.3.tar.gz:altos-1.0.3/altosui/Instdrv/NSIS/Plugins/InstDrv.dll ./antlr_2.7.7+dfsg.orig.tar.gz:antlr-2.7.7/examples/csharp/csharp_v1/Tools/runtime.dll ./antlr_2.7.7.orig.tar.gz:antlr-2.7.7/examples/csharp/csharp_v1/Tools/runtime.dll ./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/ddk_make/sources_dll ./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/libusb0.dll ./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/libusb0_x64.dll ./armadillo_0.9.52.orig.tar.gz:armadillo-0.9.52/examples/lib_win32/blas_win32_MT.dll ./armadillo_0.9.52.orig.tar.gz:armadillo-0.9.52/examples/lib_win32/lapack_win32_MT.dll ./atanks_5.5.orig.tar.gz:atanks-5.5/alleg42.dll ./atanks_5.5.orig.tar.gz:atanks-5.5/src/alleg42.dll -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3wx7s44@latte.josefsson.org
Re: Minified javascript files
On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote: So yes, we have the problem for precompiled windows DLLs in a source package. Interesting, that issue seems rather common. Maybe a lintian check could alarm packagers of this? http://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html -- WBR, wRAR signature.asc Description: Digital signature
Re: Minified javascript files
* Bernd Zeimetz be...@bzed.de, 2012-08-17, 10:53: 3. Repacking the original tarball just to remove those files is extra work. Part of the problem is that we lack good tools to do this extra work for us. Really, repacking shouldn't be a tedious operation, it shouldn't take more than 5 seconds, it shouldn't require writing two dozens lines of code and documentation. :( But it usually does and also results in a source tarball which is missing essential pieces of the software, so people who download it for non-Debian usage will fail to run the shipped source just because we removed an otherwise free piece of software. Meh. How is it different from the software failing to build/work because of other missing (build-)dependencies? Or: why did upstream stuffed this JavaScript blob into their tarballs in the first place? (These are serious questions, answers for which should bring us closer to a solution for the problem.) Also, it should be noted that repacking is not the only way of satisfying DFSG§2. Others that come to my mind: 1) Ask upstream to include the full source in their tarballs! (I know, this is hard.) 2) Put the source somewhere in the debian/ directory. (Don't forget to mention this fact in the copyright file.) 3) Make a new source package containing every jQuery version existing in the wild, then build depend on that. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120817111437.ga8...@jwilk.net
Re: Minified javascript files
On Fri, Aug 17, 2012 at 1:14 PM, Jakub Wilk jw...@debian.org wrote: 3) Make a new source package containing every jQuery version existing in the wild, then build depend on that. FTP Masters do not like that solution. Vincent's question was due to FTP masters complaining about the package 'witty', which I maintain and he sponsors. http://packages.qa.debian.org/w/witty.html Witty does build-depend on libjs-jquery (it has for a long time, way before FTP masters expressed any concern), then minifies it, and symlinks it. But FTP Masters say the jquery.min.js must be removed from witty.orig.tar.gz because the non-minified version is not included. Given that I'm not using upstream's jquery.min.js at all, I wonder why I should repackage the source package. How is an unused jquery.min.js in the original tarball different from any other unused file (a picture, a README, or anything?) The users is not expected to modify jquery.min.js ever, if he wants to rebuild the binaries for witty, he is expected to modify libjs-jquery. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcBokuzz_iZK9qOhLgW=x+mh02gr7jydsrusp34u6vtl4j...@mail.gmail.com
Re: Minified javascript files
On Fri, 17 Aug 2012, Pau Garcia i Quiles wrote: Given that I'm not using upstream's jquery.min.js at all, I wonder why I should repackage the source package. I agree with you that it's useless work. But the ftpmasters believe that Debian is made of source and binary packages and that the content of the source package should respect DFSG #2 “The program must include source code[...]”. Maybe we should fix DFSG #2 to say “The program must include source code for all the files that gets installed in the Debian binary packages [...]“. That way, there's no need to strip unused RFC, minified javascript, Flash files, PDF without sources, etc. All this has been useless bureaucracy which has drawn people away. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120817120337.gb23...@rivendell.home.ouaza.com
Re: Minified javascript files
Le vendredi, 17 août 2012 14.03:38, Raphael Hertzog a écrit : Maybe we should fix DFSG #2 to say “The program must include source code for all the files that gets installed in the Debian binary packages [...]“. With this modification, upstream might then include (distributable) win32 executables (or whatever else) in their upstream tarballs and have them distributed by the Debian mirrors network without us taking a close look at them? I don't see why we should only be looking at what we distribute in the binaries we distribute and not in the sources: we are also distributing blessed tarballs as a central part of our free software distribution. If we stop doing that in our source tarballs, then why should be care about non- recompiled blobs in our binary packages? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Minified javascript files
2012/8/17 Jakub Wilk jw...@debian.org: Part of the problem is that we lack good tools to do this extra work for us. Really, repacking shouldn't be a tedious operation, it shouldn't take more than 5 seconds, it shouldn't require writing two dozens lines of code and documentation. :( ACK. Should we write a tool that, once and for all, allows to automate the process? I think workflow should something similar to: * tool should receive an URI of the orig tarball * tool should download and unpack the orig tarball * tool should compare orig tarball with already clean sources * tool should not consider file differences, just file removals * tool should generate a policy-compliant get-orig-source target based on the diff Also, where to put this tool? Devscripts? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADk7b0OpYe8HzYYFSxRZ7wbxhugj=k9o8sbkw5yuvcwfbo1...@mail.gmail.com
Re: Minified javascript files
2012/8/17 Bernd Zeimetz be...@bzed.de: But it usually does and also results in a source tarball which is missing essential pieces of the software, so people who download it for non-Debian usage will fail to run the shipped source just because we removed an otherwise free piece of software. This does not make sense if the removed pieces are useless, as the core of this discussion is about. I also don't see the point of providing dozens of convenience copies of the very same third-party software bundled with every single pet package. If a software really needs a third-party software, just warn in $buildsystem_of_choice and in INSTALL file. Upstream should be really taugth not to reinventing the wheel again and again and again... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0mxazk+ejmoe1u9fdbevimmkqx98r5gydywsma1bzx...@mail.gmail.com
Re: Minified javascript files
Hi Luca, On Fri, Aug 17, 2012 at 03:01:12PM +0200, Luca Falavigna wrote: 2012/8/17 Jakub Wilk jw...@debian.org: Part of the problem is that we lack good tools to do this extra work for us. Really, repacking shouldn't be a tedious operation, it shouldn't take more than 5 seconds, it shouldn't require writing two dozens lines of code and documentation. :( ACK. Should we write a tool that, once and for all, allows to automate the process? I think workflow should something similar to: * tool should receive an URI of the orig tarball * tool should download and unpack the orig tarball * tool should compare orig tarball with already clean sources * tool should not consider file differences, just file removals * tool should generate a policy-compliant get-orig-source target based on the diff Also, where to put this tool? Devscripts? Did you read http://lists.debian.org/debian-devel/2012/08/msg00397.html and do you agree that a (enhanced) uscan could be this tool? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120817131449.gi6...@an3as.eu
Re: Minified javascript files
2012/8/17 Andreas Tille andr...@an3as.eu: http://lists.debian.org/debian-devel/2012/08/msg00397.html and do you agree that a (enhanced) uscan could be this tool? Sounds good for the majority of the cases, I don't think there are too many repacked sources in the archive for which it's impossible to provide a watch file [0]. [0] maintainers' laziness is not a justification -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0p1s++rcirmn9fp7gr3yqo8mddo5w7gawz8uomf4w7...@mail.gmail.com
Re: Minified javascript files
On Fri, Aug 17, 2012 at 2:37 PM, Didier 'OdyX' Raboud o...@debian.org wrote: Le vendredi, 17 août 2012 14.03:38, Raphael Hertzog a écrit : Maybe we should fix DFSG #2 to say “The program must include source code for all the files that gets installed in the Debian binary packages [...]“. With this modification, upstream might then include (distributable) win32 executables (or whatever else) in their upstream tarballs and have them distributed by the Debian mirrors network without us taking a close look at them? The modification to DFSG #2 that Raphaël proposes is indeed not good but I'd say this one would clear the issues: The program ust include source code for all the files that are used in building the Debian binary packages Which means: - If upstream is including jquery.min.js but I'm not using it because I'm using libjs-jquery, I don't need to repack the source tarball - If upstream is including a a Win32 DLL but I'm not using it for anything, I don't need to repack the source tarball etc -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakcbokv+hnafhtjkv2c7xtqgbeq2l8lcjk1fzqeozk6fhsk...@mail.gmail.com
Re: Minified javascript files
❦ 17 août 2012 09:39 CEST, Jakub Wilk jw...@debian.org : 1. The license allows redistribution and modification of the minified version without having the sources. Therefore, we are only dealing with DFSG here. While jQuery license is permissive, it does impose certain conditions[0] on distributors. In my experience, upstreams often fail to fulfil these requirements. Unmodified minified versions (downloaded from the website or from a CDN) keeps the appropriate copyright notice. Minifiers also keep the first comment which happens to be the license block, unless instructed otherwise. [0] “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” That's true that the permission notice is not included in the copy. But, this is also the case for the version provided by jQuery and for the version we provide ourselves in libjs-jquery. -- die_if_kernel(Kernel gets FloatingPenguinUnit disabled trap, regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c pgpnEnxn0EQb6.pgp Description: PGP signature
Re: Minified javascript files
On 12-08-17 at 07:19pm, Vincent Bernat wrote: ❦ 17 août 2012 09:39 CEST, Jakub Wilk jw...@debian.org : [0] “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” That's true that the permission notice is not included in the copy. But, this is also the case for the version provided by jQuery and for the version we provide ourselves in libjs-jquery. What jQuery does is less relevant: copyright holder need no license. What we do[0] in libjs-jquery is to include the permission notice in debian/copyright - i.e. included in both source and binary package even if not embedded into the file itself. - Jonas [0] if we don't it is a bug. -- * 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: Digital signature
Re: Minified javascript files
On Fri, 17 Aug 2012 16:43:51 +0600, Andrey Rahmatullin wrote: On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote: So yes, we have the problem for precompiled windows DLLs in a source package. Interesting, that issue seems rather common. Maybe a lintian check could alarm packagers of this? http://lintian.debian.org/tags/source-contains-prebuilt-windows- binary.html This includes: tcltrf (source) * win/msvcrt.dll This is part of Windows. I don't expect Debian has been granted permission to distribute it. :) I wonder how many of these DLLs and EXEs link together code licensed under the GPL with versions of the Microsoft Visual C++ Runtime that does not ship with Windows (and hence qualify for the 'major parts of the operating system' exception)? «i686-w64-mingw32-objdump -p foo.dll | grep 'DLL Name'» will output a list of dependant DLLs. The bad ones to look for match at least «msvc[pr] [0-9]+.dll» or «mfc[0-9]+.dll» (case-insensitively). I'd do this myself, but I don't have the hard drive space nor the bandwidth here, sorry. Regards, -- Sam Morris -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2012.08.17.19.50...@robots.org.uk
Re: Minified javascript files
Hi, On Fri, 17 Aug 2012, Luca Falavigna wrote: 2012/8/17 Bernd Zeimetz be...@bzed.de: But it usually does and also results in a source tarball which is missing essential pieces of the software, so people who download it for non-Debian usage will fail to run the shipped source just because we removed an otherwise free piece of software. This does not make sense if the removed pieces are useless, as the core of this discussion is about. They are not useless if you take the pristine source which is the situation that was described by Bernd. When we remove files we often have to do supplementary modifications (debian/patches/ or add symlink at the proper place) to get the software to work again... for example changing the path where the libraries are expected to be found. I also don't see the point of providing dozens of convenience copies of the very same third-party software bundled with every single pet package. The point is that they do mostly no harm and that saving those few kilobytes cost human time. Our scarcest resource is human time... If a software really needs a third-party software, just warn in $buildsystem_of_choice and in INSTALL file. Upstream should be really taugth not to reinventing the wheel again and again and again... Unfortunately Debian is not the only downstream of our upstream authors. While we can try to suggest improvements, we can't always convince them. That's a reality that we have to live with. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120817202100.ga3...@rivendell.home.ouaza.com
Re: Minified javascript files
On Fri, Aug 17, 2012 at 9:50 PM, Sam Morris s...@robots.org.uk wrote: So yes, we have the problem for precompiled windows DLLs in a source package. Interesting, that issue seems rather common. Maybe a lintian check could alarm packagers of this? http://lintian.debian.org/tags/source-contains-prebuilt-windows- binary.html This includes: tcltrf (source) * win/msvcrt.dll This is part of Windows. I don't expect Debian has been granted permission to distribute it. :) Are you sure it's not wine's? http://source.winehq.org/WineAPI/msvcrt.html -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcBoksqu9z4f_3d6bE_EsRL4fvP9xLUqvPYH1s6=weL03EU=q...@mail.gmail.com
Re: Minified javascript files
On Fri, 17 Aug 2012 22:35:07 +0200, Pau Garcia i Quiles wrote: On Fri, Aug 17, 2012 at 9:50 PM, Sam Morris s...@robots.org.uk wrote: So yes, we have the problem for precompiled windows DLLs in a source package. Interesting, that issue seems rather common. Maybe a lintian check could alarm packagers of this? http://lintian.debian.org/tags/source-contains-prebuilt-windows- binary.html This includes: tcltrf (source) * win/msvcrt.dll This is part of Windows. I don't expect Debian has been granted permission to distribute it. :) Are you sure it's not wine's? http://source.winehq.org/WineAPI/msvcrt.html Doesn't look like it: $ strings -e l win/msvcrt.dll ... VS_VERSION_INFO StringFileInfo 040904B0 CompanyName Microsoft Corporation FileDescription Microsoft (R) C Runtime Library FileVersion 5.00.7128 InternalName MSVCRT.DLL LegalCopyright Copyright (C) Microsoft Corp. 1981-1997 OriginalFilename MSVCRT.DLL ProductName Microsoft (R) Visual C++ ProductVersion 5.00.7128 VarFileInfo Translation -- Sam Morris -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2012.08.17.20.41...@robots.org.uk
Re: Minified javascript files
* Pau Garcia i Quiles pgqui...@elpauer.org, 2012-08-17, 22:35: http://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html This includes: tcltrf (source) * win/msvcrt.dll This is part of Windows. I don't expect Debian has been granted permission to distribute it. :) Are you sure it's not wine's? $ strings -e l win/msvcrt.dll | grep ^Copyright Copyright (C) Microsoft Corp. 1981-1997 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120817204422.ga7...@jwilk.net
Re: Minified javascript files
On Fri, Aug 17, 2012 at 07:50:39PM +, Sam Morris wrote: On Fri, 17 Aug 2012 16:43:51 +0600, Andrey Rahmatullin wrote: On Fri, Aug 17, 2012 at 12:03:23PM +0200, Simon Josefsson wrote: So yes, we have the problem for precompiled windows DLLs in a source package. Interesting, that issue seems rather common. Maybe a lintian check could alarm packagers of this? http://lintian.debian.org/tags/source-contains-prebuilt-windows- binary.html This includes: tcltrf (source) * win/msvcrt.dll This is part of Windows. I don't expect Debian has been granted permission to distribute it. :) It's the run-time library for Microsoft Visual C++ and is, as I recall, distributable along with applications that are built using that compiler. In fact, it is *recommended* to distribute it with applications. However, various applications bundled with Windows also need it, so in practice you can get away without doing this if you're sure your application doesn't depend on any newer features. Now, distributing it *separately* from any application or other library built with that compiler may well be copyright infringement. But it's a long time since I had to think about this and actually read the licence. Anyway, I see no point in distributing the library with source, since whatever compiler you use to build it should come with the appropriate run-time library. I wonder how many of these DLLs and EXEs link together code licensed under the GPL with versions of the Microsoft Visual C++ Runtime that does not ship with Windows (and hence qualify for the 'major parts of the operating system' exception)? I don't believe any licence is required for dynamically linking some program to a library that implements a standard interface that the program was already written for. Anyway, GPLv3 explicitly exempts run-time libraries from source requirements (clause 1 paragraph 3). Ben. «i686-w64-mingw32-objdump -p foo.dll | grep 'DLL Name'» will output a list of dependant DLLs. The bad ones to look for match at least «msvc[pr] [0-9]+.dll» or «mfc[0-9]+.dll» (case-insensitively). I'd do this myself, but I don't have the hard drive space nor the bandwidth here, sorry. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120817224832.ge29...@decadent.org.uk
Re: Minified javascript files
Le Fri, Aug 17, 2012 at 01:19:05PM +0800, Thomas Goirand a écrit : On 08/17/2012 01:24 AM, Vincent Bernat wrote: 3. Repacking the original tarball just to remove those files is extra work. Yeah, just annoying everyone for a minified jquery in upstream tarball is, to me, a bit too extreme to my taste as well, as we all know where it's coming from, and even it would be possible to check that its hash. However, I do respect this view, and I think you should as well. Hi all, I think that it would be great that in addition to respect from bottom to top, respect also comes from top to bottom, in the form of a written documentation, that would for instance indicate to what extent we need to reproduce copyright notices, that would keep a track of why a license is accepted or rejected, etc. 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: http://lists.debian.org/20120818013554.gb32...@falafel.plessy.net
Re: Minified javascript files
Vincent Bernat ber...@debian.org writes: On the behalf of the FTP master team, Ansgar Burchardt explained me why the dependency to libjs-jquery is not enough to fulfill the provide the sources part since the source in the archive may not correspond to the version included in the upstream tarball. I agree with the rationale. However, here is mine: 1. The license allows redistribution and modification of the minified version without having the sources. Therefore, we are only dealing with DFSG here. 2. The package does not need the shipped minified version to work correctly. We replace it with another minified version from another package. This may mean that from the point of view of the package, the sources provided in libjs-jquery is equivalent to the sources that would have been provided with the package. 3. Repacking the original tarball just to remove those files is extra work. I know this is tedious but what others think about this matter? Could this be solved via the Built-Using field? That indicates that you're embedding source from another package (in this case, libjs-jquery). -- 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: http://lists.debian.org/87has2agc4@windlord.stanford.edu
Re: Minified javascript files
Russ Allbery r...@debian.org writes: Vincent Bernat ber...@debian.org writes: On the behalf of the FTP master team, Ansgar Burchardt explained me why the dependency to libjs-jquery is not enough to fulfill the provide the sources part since the source in the archive may not correspond to the version included in the upstream tarball. I agree with the rationale. However, here is mine: 1. The license allows redistribution and modification of the minified version without having the sources. Therefore, we are only dealing with DFSG here. 2. The package does not need the shipped minified version to work correctly. We replace it with another minified version from another package. This may mean that from the point of view of the package, the sources provided in libjs-jquery is equivalent to the sources that would have been provided with the package. 3. Repacking the original tarball just to remove those files is extra work. I know this is tedious but what others think about this matter? Could this be solved via the Built-Using field? That indicates that you're embedding source from another package (in this case, libjs-jquery). Oh, no, wait, never mind, that's only for binary packages, and the problem you have is with the source package containing sources that are not in the preferred form for modification. Yeah, I don't think there's a good solution for that. -- 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: http://lists.debian.org/87boiaag9w@windlord.stanford.edu
Re: Minified javascript files
On Aug 16, Vincent Bernat ber...@debian.org wrote: I know this is tedious but what others think about this matter? This is another case in which the DFSG has become a religion to be followed in a literalist interpretation instead of a tool to be used for the purpose of advancing software freedom. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816185955.ga1...@bongo.bofh.it
Re: Minified javascript files
On 08/16/2012 08:59 PM, Marco d'Itri wrote: On Aug 16, Vincent Bernat ber...@debian.org wrote: I know this is tedious but what others think about this matter? This is another case in which the DFSG has become a religion to be followed in a literalist interpretation instead of a tool to be used for the purpose of advancing software freedom. I rarely share Marco's opinion, but this time I do. A way around removing the files would be to ask upstream to add the original (big) sources and some way to generate the shipped small files out of them, like a makefile/whatever which does the job. Then the miniaturized version comes with their original source (yet another copy of...) and everybody would be happy. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502d63da.4000...@bzed.de
Re: Minified javascript files
Le Thu, Aug 16, 2012 at 07:24:32PM +0200, Vincent Bernat a écrit : On the behalf of the FTP master team, Ansgar Burchardt explained me why the dependency to libjs-jquery is not enough to fulfill the provide the sources part since the source in the archive may not correspond to the version included in the upstream tarball. I agree with the rationale. However, here is mine: 1. The license allows redistribution and modification of the minified version without having the sources. Therefore, we are only dealing with DFSG here. 2. The package does not need the shipped minified version to work correctly. We replace it with another minified version from another package. This may mean that from the point of view of the package, the sources provided in libjs-jquery is equivalent to the sources that would have been provided with the package. 3. Repacking the original tarball just to remove those files is extra work. I know this is tedious but what others think about this matter? Hi Vincent, I also find this rule tedious and demotivating. Also, I regularly see people losing their time uploading repacked sources that are not binary identical to the ones in our archive (repacking scripts can not guarantee this), or fighting with pristine-tar branches in Git. In the case of sourceless redistributable files, I would prefer to save my time by ignoring them. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816212631.ga31...@falafel.plessy.net
Re: Minified javascript files
On Fri, Aug 17, 2012 at 1:24 AM, Vincent Bernat wrote: What I didn't know until recently is that the minified version in the source package should be removed (or the appropriate full version should be appended). Do we also require that for say, precompiled DLLs of GTK+ or SDL for Windows platforms? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GC0=kw=C=y6pjtfcgtzfzsujqmyvnjycfueatvnus...@mail.gmail.com
Re: Minified javascript files
On 08/17/2012 01:24 AM, Vincent Bernat wrote: 3. Repacking the original tarball just to remove those files is extra work. Yeah, just annoying everyone for a minified jquery in upstream tarball is, to me, a bit too extreme to my taste as well, as we all know where it's coming from, and even it would be possible to check that its hash. However, I do respect this view, and I think you should as well. I do not agree that this is so much work, once it is automated. Doing it *once*, for example as a debian/rules target to produce the orig.tar.xz, makes it manageable. Extra bonus points if on top of this, it makes you use xz strong compression instead of less compressing gz / bz2. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502dd449.30...@debian.org
