Re: jquery debate with upstream
On 2014-03-26 02:49, Paul Wise wrote: On Wed, Mar 26, 2014 at 6:16 AM, Philipp Kern wrote: To be honest I'd rather like to see a ruling which is codified in a policy than random guesswork we do on -devel from observing FTP masters' actions. This is not Mao. Figuring out what the source is and where it is can be hard, even for code. For example, xserver-xorg-video-nv was in Debian for 3 months before #383465 was filed and the code was in xserver-xfree86 for a couple of releases before that. I don't think this is similar to what we are discussing. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fcc97873e9b61f91ad79523ff5de4...@hub.kern.lc
Re: jquery debate with upstream
On 2014-03-24 17:23, Thorsten Glaser wrote: I don’t have the source of it at hand (and IANAftpmaster), but right now, the answer is NO because the promise of the DFSG and surrounding documents also extends to not just the source pak- kages but also the distfiles (*.orig.tar.*) isolated. Basically, it extends to every single file in the distribution. I wouldn't be surprised if that would make a bunch of packages RC-buggy. (Well, I have one. I was tempted to upload another tarball with some source files which might happen to be usable to regenerate some files if you have the right non-free tools. But then figured that everyone interested in that will just look up the sources on the upstream website instead. In the end the developers want to get their job done and release something free. Also those files are not code, but resources. Some might classify a minified jquery similar, though.) To be honest I'd rather like to see a ruling which is codified in a policy than random guesswork we do on -devel from observing FTP masters' actions. This is not Mao. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/06e99434f56c4eaf224d712bd4cb1...@hub.kern.lc
Re: jquery debate with upstream
On Tue, Mar 25, 2014 at 11:16:12PM +0100, Philipp Kern wrote: To be honest I'd rather like to see a ruling which is codified in a policy than random guesswork we do on -devel from observing FTP masters' actions. This is not Mao. There was an ftpteam meeting last week, and this was discussed. I think there was internal consensus and the team is midway through drafting a statement. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: jquery debate with upstream
On Wed, Mar 26, 2014 at 6:16 AM, Philipp Kern wrote: To be honest I'd rather like to see a ruling which is codified in a policy than random guesswork we do on -devel from observing FTP masters' actions. This is not Mao. Figuring out what the source is and where it is can be hard, even for code. For example, xserver-xorg-video-nv was in Debian for 3 months before #383465 was filed and the code was in xserver-xfree86 for a couple of releases before that. -- 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: https://lists.debian.org/CAKTje6HTa5OELZVLgQVDhmS=qvo8wuyyruu22a4waxj_jqd...@mail.gmail.com
Re: jquery debate with upstream
Joachim Breitner nomeata at debian.org writes: Before this thread gets too long and we hear too many opinion from people don’t have a say in this (like me), I’d like to hear an official statement from the ftp-team on the question: Does Debian tolerate files in upstream tarballs that are (1) legally distributable and (2) not used in any way during the build, even if they do not come with their preferred form of modification? This is a good summary of it. I don’t have the source of it at hand (and IANAftpmaster), but right now, the answer is NO because the promise of the DFSG and surrounding documents also extends to not just the source pak- kages but also the distfiles (*.orig.tar.*) isolated. Basically, it extends to every single file in the distribution. (Long ago, an upload of mine was rejected because I added a licence file to the upstream portion of the package based on information from upstream, in the .diff.gz – the next upload contained the licencing information in the .orig.tar.gz and all was fine.) bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140324t172117-...@post.gmane.org
Re: jquery debate with upstream
Joachim Breitner nomeata at debian.org writes: The minified file contains a copyright header, and the license is MIT, so I believe shipping jquery-1.11.0.min.js without query-1.11.0.js is It’s legal, but it’s not allowed because it breaks the *promise* we (Debian) do to our users/downstreams. That’s what this is all about. Needing proper licences and sources is not necessary to stay legal, or to not get sued in court, but it’s a matter of a promise. That’s the thing that led me to accept and understand precisely why non-free firmware must be in non-free, in Debian. And it’s worth a lot. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140324t171848-...@post.gmane.org
Re: jquery debate with upstream
]] Russ Allbery Lars Wirzenius l...@liw.fi writes: On Tue, Mar 18, 2014 at 01:20:20AM +0100, Matthias Urlichs wrote: Actually, if we really want to strictly +literally interpret the DFSG, then yes, tarballs (or the directory trees they represent) are no longer the preferred form of modification when everybody uses a DVCS like git. I don't think this makes sense. The tarball has never been the source: the files contained in the tarball are the source. The tarball is merely a container for them. Likewise, a version control system can be considered a container. I think it's more that one can argue that the preferred form of modification includes revision history, the branch structure, historical tags, and so forth. Yup, I don't think anybody is actually particularly hung up about whether it's a git repo or something else, as long as the semantics are preserved and it's easily consumable using standard tools. (So a git or bzr repo are both ok, a Visual Sourcesafe or Perforce repo less so.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2wqfq614r@rahvafeir.err.no
Re: jquery debate with upstream
On Tue, Mar 18, 2014 at 01:20:20AM +0100, Matthias Urlichs wrote: Actually, if we really want to strictly +literally interpret the DFSG, then yes, tarballs (or the directory trees they represent) are no longer the preferred form of modification when everybody uses a DVCS like git. I don't think this makes sense. The tarball has never been the source: the files contained in the tarball are the source. The tarball is merely a container for them. Likewise, a version control system can be considered a container. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140318083000.GX23248@holywood
Re: jquery debate with upstream
On 03/18/2014 01:20, Matthias Urlichs wrote: Scott Kitterman: Oh. So you think to meet the DFSG we need to provide a copy of the VCS repository since the tarball isn't the preferred form of modification? Actually, if we really want to strictly +literally interpret the DFSG, then yes, tarballs (or the directory trees they represent) are no longer the preferred form of modification when everybody uses a DVCS like git. Upstream tarballs frequently contain generated cruft. Configure scripts, for instance. Nobody in their right mind would modify these and nobody removes these from upstream tarballs either. Actually I started to remove configure scripts from upstream (at least when I have to repack it anyway) or just use git-archive to generate the source tarball. It makes it much easier to review diffs between different releases. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53280b22.7050...@debian.org
Re: jquery debate with upstream
* Thomas Goirand z...@debian.org, 2014-03-15, 14:09: In 20120817111437.ga8...@jwilk.net I suggested making a package that would bundle all the needed sources, but my proposal wasn't met with enthusiasm. I think it's a good idea, however, instead of packaging all version possible, would it be possible to identify which API is incompatible and package just as much as needed only? The goal is to provide missing source, which we would have to provide for every bundled version that lacks it. Not sure what API has to do with it… -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140318100712.ga6...@jwilk.net
Re: jquery debate with upstream
On Wed, Mar 12, 2014 at 09:57:50PM +0100, Jakub Wilk wrote: That would work only if the embedded copy was the same version as the packaged one. And there are lots of jQuery versions in the wild. In 20120817111437.ga8...@jwilk.net I suggested making a package that would bundle all the needed sources, but my proposal wasn't met with enthusiasm. I think this mega-package might actually be hella useful, but I think it'd be useful if we do some dh-foo to automagically strip and link copies at build-time, so that we *never* ship a jquery file (if it's a matching shasum or something), but it strips it and turns it into a dep + symlink. As for having the source to a source package in another source package? Hurm. I don't know how I feel about that, but I don't think I like it. But, I do like the jquery mega-package // javascript mega-package. We could at least fix Doxygen to not throw these copies all around. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: jquery debate with upstream
[ Lars just covered some of this in another part of the thread, but as I had this drafted already, I'm sending it anyway. ] On Thu, 2014-03-13 at 14:21:22 +0900, Charles Plessy wrote: On the other hand, the upstream tarballs are becoming temporary cruft that are not the preferred form for modification because they do not contain the typical revision information and comments found in version control systems used upstream. This was not the case when Debian was founded, but as the world evolves, we need to evolve. You keep bringing this up, and it keeps making no sense. Upstream authors, use $EDITOR (be that vim, gimp, etc) to modify the files, might use $VCS (be that diff, cvs, git, etc) to track modifications on those files, and use $PUBLISHER (be that tarball, patch, $VCS, etc) to distribute the files. And still when talking about the preferred form of modification, it's all about the _files_ themselves, not any of the above, what's relevant is if we are dealing with say a foo.S foo.c or foo.o file, and if one is the source for the other. Otherwise maintainers might have to use eclipse and bzr, because that's what upstream prefers, when they might be more comfortable with emacs and a git-bzr bridge, for example. Not to mention that part of the upstream project context is in the authors' brains… You also keep repeating that tarballs are cruft/obsolete and similar adjectives, which I don't think is a generally held view or opinion, personally I find it an unfortuntate side effect of the DVCS craze; they are just well defined snapshots, and allow to bundle in a “universal” and DVCS tool-independent way the project source, in the same way the “universal” change tracking interchange format is still a patch. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140318150038.ga30...@gaara.hadrons.org
Re: jquery debate with upstream
Lars Wirzenius l...@liw.fi writes: On Tue, Mar 18, 2014 at 01:20:20AM +0100, Matthias Urlichs wrote: Actually, if we really want to strictly +literally interpret the DFSG, then yes, tarballs (or the directory trees they represent) are no longer the preferred form of modification when everybody uses a DVCS like git. I don't think this makes sense. The tarball has never been the source: the files contained in the tarball are the source. The tarball is merely a container for them. Likewise, a version control system can be considered a container. I think it's more that one can argue that the preferred form of modification includes revision history, the branch structure, historical tags, and so forth. To me, this just underscores that preferred form of modification is too vague to be useful as more than a guiding principle. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874n2vs7xy@windlord.stanford.edu
Re: jquery debate with upstream
* Paul Tagliamonte paul...@debian.org, 2014-03-18, 09:13: That would work only if the embedded copy was the same version as the packaged one. And there are lots of jQuery versions in the wild. In 20120817111437.ga8...@jwilk.net I suggested making a package that would bundle all the needed sources, but my proposal wasn't met with enthusiasm. I think this mega-package might actually be hella useful, but I think it'd be useful if we do some dh-foo to automagically strip and link copies at build-time, so that we *never* ship a jquery file (if it's a matching shasum or something), but it strips it and turns it into a dep + symlink. Just to be clear, for the moment I'm advocating only a source mega-package, which should be dead easy to implement. Binary mega-package is a more ambitious task, especially if you intend that other users will use it. As for having the source to a source package in another source package? Hurm. I don't know how I feel about that, but I don't think I like it. Hey, I don't like it either. But I dislike status quo even more. Stuffing the source to a separate package is better than stuffing it to .diff.tar (or diff.gz), and the latter is already happening. If binary packages are allowed to have source in foreign source packages, why wouldn't source packages be allowed to do the same? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140318190706.gb7...@jwilk.net
Re: jquery debate with upstream
❦ 18 mars 2014 16:00 CET, Guillem Jover guil...@debian.org : On Thu, 2014-03-13 at 14:21:22 +0900, Charles Plessy wrote: On the other hand, the upstream tarballs are becoming temporary cruft that are not the preferred form for modification because they do not contain the typical revision information and comments found in version control systems used upstream. This was not the case when Debian was founded, but as the world evolves, we need to evolve. You keep bringing this up, and it keeps making no sense. Upstream authors, use $EDITOR (be that vim, gimp, etc) to modify the files, might use $VCS (be that diff, cvs, git, etc) to track modifications on those files, and use $PUBLISHER (be that tarball, patch, $VCS, etc) to distribute the files. And still when talking about the preferred form of modification, it's all about the _files_ themselves, not any of the above, what's relevant is if we are dealing with say a foo.S foo.c or foo.o file, and if one is the source for the other. That's not all clear. What if a part of the build process is using VCS? For example, to generate the changelog... Just to say that preferred form of modification should not be the ultimate weapon for anything. What about scanned artworks? Should we ship the original piece of paper that was scanned? -- # Okay, what on Earth is this one supposed to be used for? 2.4.0 linux/drivers/char/cp437.uni signature.asc Description: PGP signature
Re: jquery debate with upstream
Hi, Scott Kitterman: Oh. So you think to meet the DFSG we need to provide a copy of the VCS repository since the tarball isn't the preferred form of modification? Actually, if we really want to strictly +literally interpret the DFSG, then yes, tarballs (or the directory trees they represent) are no longer the preferred form of modification when everybody uses a DVCS like git. Upstream tarballs frequently contain generated cruft. Configure scripts, for instance. Nobody in their right mind would modify these and nobody removes these from upstream tarballs either. Leave those *.min.js files in there. The effort to remove them serves no practical purpose whatsoever, regardless of how large that effort actually is, and is _way_ better spent in other ways to improve our packages. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: jquery debate with upstream
On 03/13/2014 04:57 AM, Jakub Wilk wrote: * Philipp Kern p...@philkern.de, 2014-03-12, 21:11: I still think it should be acceptable given that it's an open source project, it's clearly versioned from which source it comes and we check by not using the file that no changes have been done to the minification. I guess we could even go one step further and argue that the source for this is in fact in Debian. That would work only if the embedded copy was the same version as the packaged one. And there are lots of jQuery versions in the wild. In 20120817111437.ga8...@jwilk.net I suggested making a package that would bundle all the needed sources, but my proposal wasn't met with enthusiasm. I think it's a good idea, however, instead of packaging all version possible, would it be possible to identify which API is incompatible and package just as much as needed only? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5323ee7d.1010...@debian.org
Re: jquery debate with upstream
On Thu, Mar 13, 2014 at 8:02 PM, Craig Small wrote: FWIW, I think the concept of a graphic needing its source is also bogus. It means that the upstream have to hang onto some script they might of used once years ago for.. what reason? To give you a concrete example, I made the SPI logo (and I think it is the current one, it looks like it) using gimp and some sort of lisp script. I don't have that script anymore, does that make the logo non-free? Should that change the status of the graphic? If, instead of a script I manually typed/moused the commands, does that change the status? You are conflating two issues: What is the source as required by DFSG item 2. Under the scenario you have described, the PNG of the SPI logo appears to be source since if you/upstream were to modify the SPI logo you/upstream would use the PNG since the XCF and Lisp script no longer exist. What upstream should be doing with the forms of data that they have or create. Under the scenario you have described, you threw away (or lost) the more useful forms, which I think was a mistake. As the upstream maintainer and the Debian maintainer for a bunch of games where the original authors have thrown away the source for the graphic/video data, preventing simple modifications like increasing the resolution to modern screen sizes, let alone fixing visual glitches or using different 3D models, I find it a bit sad that you threw away this data. I assume you wouldn't compile your C code to assembler, throw away the C code, ship the assembler and hope you never have to fix bugs in it, optimise it or add new features. This is essentially what you did with the SPI logo. I expect there are people out there who might want to modify the SPI logo, for example see what various artists have done for the Debian swirl for DebConf logos, which were only possible because the vector formats where not thrown away. I would encourage anyone creating code, docs, fonts, graphics, audio, video or other digital works to think carefully before throwing away the higher-level forms in favour of lower-level forms. I would encourage Debian folks to look at what upstream provides, evaluate what the source might be and in cases of doubt ask upstream for clarification. This page provides a guide for the sort of things upstream should think about and for Debian folk to audit. http://www.freedesktop.org/wiki/Games/Upstream/#source Sometimes you will find that upstream's preferred form for modification is available in a VCS repository but not the tarball, sometimes possibly resulting in GPL violations on Debian's behalf (cf FSF/Emacs or Warzone 2100) and that you simply need to ask them to ship it in tarballs. Sometimes you will find that upstream relies on artists who aren't willing to share their preferred form for modification (such as the Blender/Povray source for a 3D scene). Sometimes you will find that upstream's preferred form for modification has been thrown away and they don't intend to modify it again. -- 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: https://lists.debian.org/CAKTje6GuA6M3PjjJhHfg6JEMSZNaP37rAEpaP=XrBmAjak=s...@mail.gmail.com
Re: jquery debate with upstream
On Sat, Mar 15, 2014 at 10:07:22AM +0800, Paul Wise wrote: On Thu, Mar 13, 2014 at 8:02 PM, Craig Small wrote: FWIW, I think the concept of a graphic needing its source is also bogus. It means that the upstream have to hang onto some script they might of used once years ago for.. what reason? To give you a concrete example, I made the SPI logo (and I think it is the current one, it looks like it) using gimp and some sort of lisp script. I don't have that script anymore, does that make the logo non-free? Should that change the status of the graphic? If, instead of a script I manually typed/moused the commands, does that change the status? You are conflating two issues: What is the source as required by DFSG item 2. Under the scenario you have described, the PNG of the SPI logo appears to be source since if you/upstream were to modify the SPI logo you/upstream would use the PNG since the XCF and Lisp script no longer exist. A PNG is not a program. There is no source required for a PNG under DFSG #2, and anyone who says otherwise is engaging in (or a victim of) historical revisionism. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: jquery debate with upstream
On 03/13/2014 11:45 PM, Vincent Bernat wrote: ❦ 12 mars 2014 22:26 CET, Ben Finney ben+deb...@benfinney.id.au : The javascript world is difficult to deal with. They like embedded copies, they may not really care about API/ABI stability, even for big projects. Those are difficulties that we already have to deal with. We already work around them by using Debian package when possible but this makes the software we ship more buggy because we don't match the exact version that upstream uses. Right. This can only really improve by addressing the general problems you describe in that paragraph, which itself requires collaborating with upstream to join with us in expecting better interoperability from JS library developers. In the past, we have seen it is useless to try to convince an upstream they should do like we want to. We should wait for them to notice that this is the way to go or they will just start some hate campaign about how slow and deprecated we are. In my experience, this really depends on upstream, and you shouldn't generalize that much. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5323bb98.8020...@debian.org
Re: jquery debate with upstream
On Sat, Mar 15, 2014 at 10:20 AM, Steve Langasek wrote: A PNG is not a program. Depends on your definition of program. PNG files are programs that run in a PNG decoder. ELF binaries aren't programs, they are just data interpreted by CPUs. There is no source required for a PNG under DFSG #2 I disagree, I've always assumed the DFSG applied to all of Debian main regardless of format. anyone who says otherwise is engaging in (or a victim of) historical revisionism. I guess you are referring to the GR that clarified the Social Contract to read work instead of software. https://www.debian.org/vote/2004/vote_003 -- 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: https://lists.debian.org/CAKTje6GdzQJr7bW82wetPx3sfyn05O0_=__j=v6smumxt6a...@mail.gmail.com
Re: jquery debate with upstream
On Sat, Mar 15, 2014 at 10:50:13AM +0800, Paul Wise wrote: On Sat, Mar 15, 2014 at 10:20 AM, Steve Langasek wrote: A PNG is not a program. Depends on your definition of program. Yes. If you use the English definition of the word program, then it's not a program. But I guess if you make up definitions for program to get the result you want: PNG files are programs that run in a PNG decoder. ELF binaries aren't programs, they are just data interpreted by CPUs. ... then you can claim that it's a program. There is no source required for a PNG under DFSG #2 I disagree, I've always assumed the DFSG applied to all of Debian main regardless of format. You may have assumed that, but that is not what the DFSG says. anyone who says otherwise is engaging in (or a victim of) historical revisionism. I guess you are referring to the GR that clarified the Social Contract to read work instead of software. https://www.debian.org/vote/2004/vote_003 That was a conscious decision on the part of the project to revise the text of the Social Contract. That vote did *not* replace the use of the word program in DFSG#2 with the word software. It is incorrect to infer from this vote that Debian decided to require source for all non-program works. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: jquery debate with upstream
Steve Langasek vor...@debian.org writes: On Sat, Mar 15, 2014 at 10:50:13AM +0800, Paul Wise wrote: I guess you are referring to the GR that clarified the Social Contract to read work instead of software. https://www.debian.org/vote/2004/vote_003 That was a conscious decision on the part of the project to revise the text of the Social Contract. That vote did *not* replace the use of the word program in DFSG#2 with the word software. It is incorrect to infer from this vote that Debian decided to require source for all non-program works. That matches my memory of the discussion as well. The purpose was to require that non-program content in the archive also be covered by a DFSG-free license concerning such things as modification, redistribution, and so on, partly because of the GFDL invariant section issues and related problems (such as RFCs). If there was much discussion of the applicability of the source requirement to such works, I don't recall it, and I'm pretty sure it didn't play a role in at least my vote. That said, when there *is* source of some kind for a non-program work, often we would want it. I'm not sure I'd be particularly happy about, say, documentation in the form of PDF files generated from some markup language but where that source was not available. I'm largely convinced by the FSF argument that free software should also have free documentation, since being able to modify the software but not the documentation is quite annoying and frustrating. (It's a shame the FSF itself doesn't guarantee that its documentation is free in that fashion, but that's a different argument.) I'm less convinced that retaining the original Photoshop file with all the layers and transparencies alongside any random PNG file is that important. Particularly since I know graphic designers who routinely discard those files for small works once they've gotten the final output they want, since, if they're going to revise a small graphic, they don't use those files anyway. It also could create the ironic situation of adding files to the archive that can only be used by non-free software as source for images that can be edited fine in GIMP with fairly minimal loss of functionality. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87eh24gn75@windlord.stanford.edu
Re: jquery debate with upstream
On Sat, Mar 15, 2014 at 11:02 AM, Steve Langasek wrote: That was a conscious decision on the part of the project to revise the text of the Social Contract. That vote did *not* replace the use of the word program in DFSG#2 with the word software. It is incorrect to infer from this vote that Debian decided to require source for all non-program works. As far as I can tell, not modifying the DSFG at the same time was an oversight. Fixing that mistake was attempted in a later GR but that was blocked with a narrow margin. https://www.debian.org/vote/2006/vote_004 The DFSG mentions program in other sections too. Does that mean that we can accept non-programs with licenses that: Discriminate against fields of endeavour (item 6)? Don't let Debian pass licenses on to users (item 7)? Don't apply to entities other than Debian (item 8)? I definitely can't agree with your interpretation here and think we should amend the DFSG to replace all uses of the words software or program with work or similar. -- 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: https://lists.debian.org/CAKTje6Hz9q+Cpj1TWANrGGweTUHh9UD+q72iNbvm6ds5a-_g=a...@mail.gmail.com
Re: jquery debate with upstream
Paul Wise p...@debian.org writes: As far as I can tell, not modifying the DSFG at the same time was an oversight. Fixing that mistake was attempted in a later GR but that was blocked with a narrow margin. https://www.debian.org/vote/2006/vote_004 That GR proposal does not require source for non-programmatic works. It only strongly recommends it, and says explicitly that such source doesn't have to be in the archive. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uscgmvx@windlord.stanford.edu
Re: jquery debate with upstream
On Sat, Mar 15, 2014 at 11:29 AM, Russ Allbery wrote: Paul Wise writes: As far as I can tell, not modifying the DSFG at the same time was an oversight. Fixing that mistake was attempted in a later GR but that was blocked with a narrow margin. https://www.debian.org/vote/2006/vote_004 That GR proposal does not require source for non-programmatic works. It only strongly recommends it, and says explicitly that such source doesn't have to be in the archive. Interesting, I must have glossed over that as I was on VAC at the time. I note that the ftpmasters currently reject packages that are missing source for non-programmatic works (REJECT-FAQ explicitly mentions PS/PDF documentation). So the current archive requirements are in practice stricter than the DFSG and the attempted DFSG clarification GR. https://ftp-master.debian.org/REJECT-FAQ.html -- 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: https://lists.debian.org/caktje6hq2jbjazmi8j_gfgtpdq4t15l2-eg8vdysofvw3+f...@mail.gmail.com
Re: jquery debate with upstream
On Sat, Mar 15, 2014 at 11:24:19AM +0800, Paul Wise wrote: On Sat, Mar 15, 2014 at 11:02 AM, Steve Langasek wrote: That was a conscious decision on the part of the project to revise the text of the Social Contract. That vote did *not* replace the use of the word program in DFSG#2 with the word software. It is incorrect to infer from this vote that Debian decided to require source for all non-program works. As far as I can tell, not modifying the DSFG at the same time was an oversight. Fixing that mistake was attempted in a later GR but that was blocked with a narrow margin. https://www.debian.org/vote/2006/vote_004 I agree that it was an oversight to leave these ambiguities in the DFSG at the time it was being amended. I do not agree with your implied assumption that an attempt to remove these ambiguities would have resulted in us deciding to apply DFSG#2 to non-program works. I would have voted against that then and would vote against it now. I was also among the majority who voted against the above GR, and that GR didn't even go as far as you are proposing. That it was blocked by a narrow margin gives you no more moral authority than if it were defeated in a landslide; the Debian project did not ratify this interpretation of the DFSG, and it is inappropriate for anyone to make source a de facto requirement for main by changing the facts on the ground. We all agree that it is best to have source available for everything we ship in main, including non-programs. But there's a big difference between agreeing that it's a best practice, and kicking it out of main for not complying with this best-practice guideline. The DFSG mentions program in other sections too. Does that mean that we can accept non-programs with licenses that: Discriminate against fields of endeavour (item 6)? Don't let Debian pass licenses on to users (item 7)? Don't apply to entities other than Debian (item 8)? I definitely can't agree with your interpretation here and think we should amend the DFSG to replace all uses of the words software or program with work or similar. It's fine for you to hold the position that we should amend it in this way. It's not fine to demand that Debian behave as if this amendment *had already been made*, because this is *not* the meaning the document had either at the time it was adopted or at the time it was amended. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: jquery debate with upstream
Le Sat, Mar 15, 2014 at 11:47:44AM +0800, Paul Wise a écrit : I note that the ftpmasters currently reject packages that are missing source for non-programmatic works (REJECT-FAQ explicitly mentions PS/PDF documentation). So the current archive requirements are in practice stricter than the DFSG and the attempted DFSG clarification GR. https://ftp-master.debian.org/REJECT-FAQ.html Hi Paul, I think that this hard-line position is problematic at mutiple levels. One of them is that it is far more frequent for an upstream work to occasionally receive additional documentation or artwork with missing source, compared with receiving addtional source code under a non-DFSG-free license. As a consequence, it is quite common for packages in main to suddenly fall in a limbo where they are DFSG-free and FTPmaster-rejectable. With a best-effort approach, following the spirit and the letter of the DFSG, one can engage in a constructive discussion with Upstream. However, with a hard-line approach it is hard to not sound like an ultimatum menacing to remove the package from Debian (usually, nobody volunteers to maintain these packages in non-free). Personally, this is a reason why I have quitted R packaging. This is far too stressful for me as I beleive that as a packager it is my responsibiltiy to keep a package in main if possible, but on the other hand the situation is out of my control (to the extent being between the hammer and the anvil can be considered having some control). The take home message is that when Upstream starts to add documentation or artwork in his documentation, it should be something positive for all, even if it is started in a way that can be improved, and not a source of RC bugs as it is now. I think that the hard-line point of view does not motivate and rather leads people to give up. Have a nice week-end. -- 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: https://lists.debian.org/20140315042829.ga24...@falafel.plessy.net
Re: jquery debate with upstream
On 03/13/2014 01:21 PM, Charles Plessy wrote: Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit : What percentage of free software in Debian main do you expect then? Hi Scott, I expect 100 % in the binary packages. On the other hand, the upstream tarballs are becoming temporary cruft that are not the preferred form for modification because they do not contain the typical revision information and comments found in version control systems used upstream. This was not the case when Debian was founded, but as the world evolves, we need to evolve. Actually, this is a very good case for doing git based packaging and using git archive based on tags. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53214aa3.90...@debian.org
Re: jquery debate with upstream
On 03/13/2014 01:37 PM, Scott Kitterman wrote: On Thursday, March 13, 2014 14:21:22 Charles Plessy wrote: Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit : What percentage of free software in Debian main do you expect then? Hi Scott, I expect 100 % in the binary packages. On the other hand, the upstream tarballs are becoming temporary cruft that are not the preferred form for modification because they do not contain the typical revision information and comments found in version control systems used upstream. This was not the case when Debian was founded, but as the world evolves, we need to evolve. Oh. So you think to meet the DFSG we need to provide a copy of the VCS repository since the tarball isn't the preferred form of modification? That would be a huge change. Far bigger than repacking a few tarballs. Well, we have debcheckout... :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53214e04.8030...@debian.org
Re: jquery debate with upstream
On Wed, Mar 12, 2014 at 12:58:51PM +, Ian Jackson wrote: I have a completely different approach to the DFSG. The DFSG is not carefully drafted document and it doesn't stand up to detailed legalistic interpretation. Rather, it is a statement of aims and values. That was certainly how I remember the crafting of it as well. Removing source files you don't use seems very, well, meta to me. Once all other problems are solved and we've got nothing to do, perhaps then we should look at it. It provides no benefit except work for developers. FWIW, I think the concept of a graphic needing its source is also bogus. It means that the upstream have to hang onto some script they might of used once years ago for.. what reason? To give you a concrete example, I made the SPI logo (and I think it is the current one, it looks like it) using gimp and some sort of lisp script. I don't have that script anymore, does that make the logo non-free? Should that change the status of the graphic? If, instead of a script I manually typed/moused the commands, does that change the status? - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313120208.gb12...@enc.com.au
Re: jquery debate with upstream
❦ 12 mars 2014 22:26 CET, Ben Finney ben+deb...@benfinney.id.au : The javascript world is difficult to deal with. They like embedded copies, they may not really care about API/ABI stability, even for big projects. Those are difficulties that we already have to deal with. We already work around them by using Debian package when possible but this makes the software we ship more buggy because we don't match the exact version that upstream uses. Right. This can only really improve by addressing the general problems you describe in that paragraph, which itself requires collaborating with upstream to join with us in expecting better interoperability from JS library developers. In the past, we have seen it is useless to try to convince an upstream they should do like we want to. We should wait for them to notice that this is the way to go or they will just start some hate campaign about how slow and deprecated we are. In the meantime, should we avoid packaging JS stuff or try to be flexible? -- panic(Aarggh: attempting to free lock with active wait queue - shoot Andy); 2.0.38 /usr/src/linux/fs/locks.c signature.asc Description: PGP signature
Re: jquery debate with upstream
On Thu, 13 Mar 2014, Craig Small wrote: It means that the upstream have to hang onto some script they might of used once years ago for.. what reason? No, that's not what it means. The whole point of requiring source is to stop artificially inhibiting user's (and Debian's) ability to modify a work for any purpose. If the script no longer exists, then the preferred form for modification that actually exists is the source. Requiring the vector file for bitmap graphics which were made from a vector file is an example of enabling modifications of the work. It's already normal to need vastly different resolutions of graphics for some devices with high DPI screens, and it's not unusual for there to be spelling errors or untranslated words in graphics which should be fixed, either. But then again, my feelings on this matter should be obvious, as I did write https://www.debian.org/vote/2006/vote_004 after all... -- Don Armstrong http://www.donarmstrong.com Herodotus says, Very few things happen at the right time, and the rest do not happen at all. The conscientious historian will correct these defects. -- Mark Twain _A Horse's Tail_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313170513.ge...@teltox.donarmstrong.com
Re: jquery debate with upstream
On Tue, Mar 11, 2014 at 02:34:47PM -0400, Paul Tagliamonte wrote: You may think a line is somewhere, but the DFSG is interpreted by the ftp-masters, so the question isn't what paultag or ian says, but what the ftp-masters say :) I don't accept that. The interpretation must come from a concensus of Debian Developers. Regards, -Steve signature.asc Description: Digital signature
Re: jquery debate with upstream
Le mardi, 11 mars 2014, 19.02:55 Ian Jackson a écrit : Thomas Goirand writes (Re: jquery debate with upstream): In one of my package, I had openssl.dll in the source tarball (it was of course removed later on). Would you consider it ok as well to have it in a source package, as long as it's not used during the build? And what about a windows .exe? Is it different from having a minified .js that is also not in use? Yes, I think all of these things are tolerable, so long as the files are in fact redistributable (which depending on the licence they might not be). I disagree: I don't think it's tolerable to ship a .exe freeware [0] in a source package in main, just because it happens to be redistributable; in my reading, considering that the source package _is_ a component of the Debian system, doing so violates at least SC§1 and DFSG§2. I don't think there should be a standards' difference between our source and binary packages. That said, the minified .js case is slightly different iff it can be proved that it can be recreated from DFSG-free sources, which should then really be actually done in the build phase. Now, if the problem is that stripping out non-free stuff from upstream archives is boring work, then that's the thing to solve using smart tools rather than bending our standards. Cheers, OdyX [0] And that's without speaking of actively harmful executables… signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstream
Didier 'OdyX' Raboud writes (Re: jquery debate with upstream): I disagree: I don't think it's tolerable to ship a .exe freeware [0] in a source package in main, just because it happens to be redistributable; in my reading, considering that the source package _is_ a component of the Debian system, doing so violates at least SC§1 and DFSG§2. I don't think there should be a standards' difference between our source and binary packages. I have a completely different approach to the DFSG. The DFSG is not carefully drafted document and it doesn't stand up to detailed legalistic interpretation. Rather, it is a statement of aims and values. When interpreting it, we need to primarily consider its underlying purpose - and, ultimately, the underlying purpose of the whole project. That purpose is to improve the freedom of software users (and to an extent developers) by providing an operating system which they can (individually and collectively) examine, modify and share. If an interpretation of the DFSG suggests that we should be doing work which does not further those objectives, then I think that interpretation is a misreading. Conversely, if an interpretation of the DFSG suggests that we should tolerate a situation which undermines the freedom of our users, then that would be a subversion of our values. No-one has come up with any practical benefit from the repacking of source tarballs to remove nonfree files. The requirement to be sure that these nonfree files aren't unwittingly relied on by our build processes could be easily achieved by removing them in clean targets, filtering in dpkg-source, or whatever. If we are worried that users might be misled about the status of these files, filtering them out in dpkg-source would suffice. The result would be that the only people who saw them would be people who are using our archive as a convenient location to fetch the upstream tarball. I would argue that everyone's freedom is served, rather than hindered, by having those people come to us for that (as it is in a similar way for the nonfree archive sections). Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21280.23051.488968.947...@chiark.greenend.org.uk
Re: jquery debate with upstream
Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit : Didier 'OdyX' Raboud writes (Re: jquery debate with upstream): I disagree: I don't think it's tolerable to ship a .exe freeware [0] in a source package in main, just because it happens to be redistributable; in my reading, considering that the source package _is_ a component of the Debian system, doing so violates at least SC§1 and DFSG§2. I don't think there should be a standards' difference between our source and binary packages. I have a completely different approach to the DFSG. The DFSG is not carefully drafted document and it doesn't stand up to detailed legalistic interpretation. Rather, it is a statement of aims and values. My intent was not to draw a legalistic line, I was merely explaining what my (current) interpretation of these aims and values are with regards to shipping non-free binaries in source packages in main. That purpose is to improve the freedom of software users (and to an extent developers) by providing an operating system which they can (individually and collectively) examine, modify and share. If an interpretation of the DFSG suggests that we should be doing work which does not further those objectives, then I think that interpretation is a misreading. SC§1 states that we want Debian to remain 100% free; the common interpretation of that is that one can download anything from Debian main and only get DFSG-free material; I think our sources are held to the same expectation. In fact, we _are_ shipping source and binary packages in the exact same way through our mirrors network. Now, granted, making Debian 100% free is not improving the freedom of software users if they don't use these non-free parts (and having them in the source packages only is certainly a blocker), but I strongly feel that weakening our promise to only address binary packages for the sake of practicability is certainly not worth the practical benefit. No-one has come up with any practical benefit from the repacking of source tarballs to remove nonfree files. There's no practical benefit, granted, but doing so is a service to our users and a continued statement that we hold ourselves to high standards with regards to software freedom. The requirement to be sure that these nonfree files aren't unwittingly relied on by our build processes could be easily achieved by removing them in clean targets, filtering in dpkg-source, or whatever. I think that, given proper tools, the explicit work of making sure that some non-free files are not used in the build process is equivalent to making sure they are not present in the source package. If we are worried that users might be misled about the status of these files, filtering them out in dpkg-source would suffice. That would protect sources.debian.net from publishing these indeed. I still disagree it's sufficient though. The result would be that the only people who saw them would be people who are using our archive as a convenient location to fetch the upstream tarball. I would argue that everyone's freedom is served, rather than hindered, by having those people come to us for that (as it is in a similar way for the nonfree archive sections). … besides main is not the non-free archive section. At the risk of repeating myself: I value our promise that Debian will remain 100% free and I want that promise to include our source archives because access to sourcecode is what free software is all about. I'd be saddened by a decision to exempt the source archives from that freeness requirement. Cheers, OdyX P.S. There's no need to CC me, as I can't CC you in return and am subscribed to the list… signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstream
On Wed, 12 Mar 2014, Ian Jackson wrote: No-one has come up with any practical benefit from the repacking of source tarballs to remove nonfree files. Non-free files in source files are distributed by Debian. They cannot be modified, inspected, or easily patched. Removing them assures us that they will never be accidentally included in a Debian binary package. It also means that people running searches for embedded copies to fix security issues don't have false positives. Whether these benefits outweigh the costs of doing it is arguable, but these are some of the benefits. -- Don Armstrong http://www.donarmstrong.com The state must declare the child to be the most precious treasure of the people. As long as the government is perceived as working for the benefit of the children, the people will happily endure almost any curtailment of liberty and almost any deprivation. -- Adolf Hitler _Mein Kampf_ p403 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140312154438.gd12...@teltox.donarmstrong.com
Re: jquery debate with upstream
Also archive size, for what it's worth. Shipping GBs of DLLs, minified JS and other sourceless nonsense is totally a waste of everyone's time and storage space. On Wed, Mar 12, 2014 at 11:44 AM, Don Armstrong d...@debian.org wrote: On Wed, 12 Mar 2014, Ian Jackson wrote: No-one has come up with any practical benefit from the repacking of source tarballs to remove nonfree files. Non-free files in source files are distributed by Debian. They cannot be modified, inspected, or easily patched. Removing them assures us that they will never be accidentally included in a Debian binary package. It also means that people running searches for embedded copies to fix security issues don't have false positives. Whether these benefits outweigh the costs of doing it is arguable, but these are some of the benefits. -- Don Armstrong http://www.donarmstrong.com The state must declare the child to be the most precious treasure of the people. As long as the government is perceived as working for the benefit of the children, the people will happily endure almost any curtailment of liberty and almost any deprivation. -- Adolf Hitler _Mein Kampf_ p403 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140312154438.gd12...@teltox.donarmstrong.com -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq
Re: jquery debate with upstream
Quoting Ian Jackson (2014-03-12 13:58:51) If an interpretation of the DFSG suggests that we should be doing work which does not further those objectives, then I think that interpretation is a misreading. Conversely, if an interpretation of the DFSG suggests that we should tolerate a situation which undermines the freedom of our users, then that would be a subversion of our values. No-one has come up with any practical benefit from the repacking of source tarballs to remove nonfree files. I fail to follow your logic. It does not hurt our users' freedoms that we ship minified Javascript code (i.e. functionally identical code but non-reversable to its preferred editable form) - as long as our users ignore the same files as we do in our build routines. Similarly it does not hurt our users' freedoms if we shipped RFC GFDL-licensed documents, as long as they didn't edit those doxuments. I don't understandf how one breed should be treated differently from the other. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: jquery debate with upstream
On 12.03.2014 16:47, Paul Tagliamonte wrote: Also archive size, for what it's worth. Shipping GBs of DLLs, minified JS and other sourceless nonsense is totally a waste of everyone's time and storage space. this is not a good argument, the best you can usually get out of upstreams it to ship an unminified file in _addition_ to the minified one, so one just ends up with wasting more time and storage space. Its not very good for the relations with upstream trying to convince them to ship unminified files without being able to back it up with good arguments besides DFSG says so. I haven't seen any argument that would convince an upstream in this thread yet. I tried bettering upstreams a few times, while sometimes successful in retrospect I should have just repacked instead of bothering them with Debian politics. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5320c0c3.2000...@googlemail.com
Re: jquery debate with upstream
Hi, On 2014-03-11 00:09, Joachim Breitner wrote: Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern: as long as the code in question is not under a license that requires the full, non-minified source to be reproduced and if the copyright notices and license terms as potentially required by the license are present, I don't see why not. But I guess the latter is not commonly happening? The most common case is that the file http://code.jquery.com/jquery-1.11.0.min.js is included without http://code.jquery.com/jquery-1.11.0.js The minified file contains a copyright header, and the license is MIT, so I believe shipping jquery-1.11.0.min.js without query-1.11.0.js is allowed. So you’d say it is acceptable to leave jquery-1.11.0.min.js in a tarball if it is unused (e.g. if it is removed in the clean target, and possibly documented in README.Source)? Can maybe someone from the ftp-team confirm this? how bad would it be for those upstreams to just include an unused copy of the non-minified version? Clearly it'd never be used by anything in the upstream packaging because you almost always want to ship minified JS to browsers in production. But if they already fetch the min and you have a working relationship with upstream… maybe they're sympathetic. I still think it should be acceptable given that it's an open source project, it's clearly versioned from which source it comes and we check by not using the file that no changes have been done to the minification. I guess we could even go one step further and argue that the source for this is in fact in Debian. If we could generate the same minification result as jquery upstream in Debian, all we'd need would be the equivalent of a source-depends or a pointer in debian/copyright. It's not that we don't ship its source, after all. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7243c42b9ff3af08884ee08e41bb9...@hub.kern.lc
Re: jquery debate with upstream
On Wed, Mar 12, 2014 at 1:11 PM, Philipp Kern p...@philkern.de wrote: Hi, On 2014-03-11 00:09, Joachim Breitner wrote: Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern: as long as the code in question is not under a license that requires the full, non-minified source to be reproduced and if the copyright notices and license terms as potentially required by the license are present, I don't see why not. But I guess the latter is not commonly happening? The most common case is that the file http://code.jquery.com/jquery-1.11.0.min.js is included without http://code.jquery.com/jquery-1.11.0.js The minified file contains a copyright header, and the license is MIT, so I believe shipping jquery-1.11.0.min.js without query-1.11.0.js is allowed. So you'd say it is acceptable to leave jquery-1.11.0.min.js in a tarball if it is unused (e.g. if it is removed in the clean target, and possibly documented in README.Source)? Can maybe someone from the ftp-team confirm this? how bad would it be for those upstreams to just include an unused copy of the non-minified version? Clearly it'd never be used by anything in the upstream packaging because you almost always want to ship minified JS to browsers in production. But if they already fetch the min and you have a working relationship with upstream... maybe they're sympathetic. From upstream's point of view, it often comes down to extra work and no gain. Avoiding busywork is a fairly compelling reason to not do something. I still think it should be acceptable given that it's an open source project, it's clearly versioned from which source it comes and we check by not using the file that no changes have been done to the minification. I guess we could even go one step further and argue that the source for this is in fact in Debian. If we could generate the same minification result as jquery upstream in Debian, all we'd need would be the equivalent of a source-depends or a pointer in debian/copyright. It's not that we don't ship its source, after all. My understanding is this is what the Built-Using field in debian/control is supposed to help with, although I don't think it's in widespread usage yet. Regards, Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczd_tcpycsdqziub0pzrrzaqexgyd21k+v11ezkv6_9o16...@mail.gmail.com
Re: jquery debate with upstream
❦ 12 mars 2014 21:11 CET, Philipp Kern p...@philkern.de : how bad would it be for those upstreams to just include an unused copy of the non-minified version? Clearly it'd never be used by anything in the upstream packaging because you almost always want to ship minified JS to browsers in production. But if they already fetch the min and you have a working relationship with upstream… maybe they're sympathetic. It will just go out of sync. For upstream, the preferred form of modification is the minified version (modification is merely the update to a new version). The javascript world is difficult to deal with. They like embedded copies, they may not really care about API/ABI stability, even for big projects. Those are difficulties that we already have to deal with. We already work around them by using Debian package when possible but this makes the software we ship more buggy because we don't match the exact version that upstream uses. We have so many important difficulties to deal with when packaging something that uses javascript stuff that it is quite exhausting to pile additional problems like repacking to remove unused minified JS stuff. -- Don't comment bad code - rewrite it. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: jquery debate with upstream
* Philipp Kern p...@philkern.de, 2014-03-12, 21:11: I still think it should be acceptable given that it's an open source project, it's clearly versioned from which source it comes and we check by not using the file that no changes have been done to the minification. I guess we could even go one step further and argue that the source for this is in fact in Debian. That would work only if the embedded copy was the same version as the packaged one. And there are lots of jQuery versions in the wild. In 20120817111437.ga8...@jwilk.net I suggested making a package that would bundle all the needed sources, but my proposal wasn't met with enthusiasm. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140312205750.ga7...@jwilk.net
Re: jquery debate with upstream
Vincent Bernat ber...@debian.org writes: [A bundled, source version of the library] will just go out of sync. For upstream, the preferred form of modification is the minified version (modification is merely the update to a new version). Yes, the cause of that is that upstream doesn't treat these files as source at all – they are dependencies, third-party libraries. Ideally they would not appear in the source at all. Upstream include these non-source files bundled in with other, actual-source files, merely because they perceive no better option for declaring a dependency on a third-party library. The javascript world is difficult to deal with. They like embedded copies, they may not really care about API/ABI stability, even for big projects. Those are difficulties that we already have to deal with. We already work around them by using Debian package when possible but this makes the software we ship more buggy because we don't match the exact version that upstream uses. Right. This can only really improve by addressing the general problems you describe in that paragraph, which itself requires collaborating with upstream to join with us in expecting better interoperability from JS library developers. -- \ “Generally speaking, the errors in religion are dangerous; | `\those in philosophy only ridiculous.” —David Hume, _A Treatise | _o__) of Human Nature_, 1739 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/854n33t8g7@benfinney.id.au
Re: jquery debate with upstream
On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote: Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit : If an interpretation of the DFSG suggests that we should be doing work which does not further those objectives, then I think that interpretation is a misreading. SC§1 states that we want Debian to remain 100% free; the common interpretation of that is that one can download anything from Debian main and only get DFSG-free material; I think our sources are held to the same expectation. That's never been my expectation, FWIW. I do agree with Ian that this is stretching the goals of the project, at least as I perceive them. -Steve signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstream
On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote: On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote: Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit : If an interpretation of the DFSG suggests that we should be doing work which does not further those objectives, then I think that interpretation is a misreading. SC§1 states that we want Debian to remain 100% free; the common interpretation of that is that one can download anything from Debian main and only get DFSG-free material; I think our sources are held to the same expectation. That's never been my expectation, FWIW. I do agree with Ian that this is stretching the goals of the project, at least as I perceive them. What percentage of free software in Debian main do you expect then? Scott K signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstream
Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit : What percentage of free software in Debian main do you expect then? Hi Scott, I expect 100 % in the binary packages. On the other hand, the upstream tarballs are becoming temporary cruft that are not the preferred form for modification because they do not contain the typical revision information and comments found in version control systems used upstream. This was not the case when Debian was founded, but as the world evolves, we need to evolve. Have a nice day, Charles -- 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: https://lists.debian.org/20140313052122.gb1...@falafel.plessy.net
Re: jquery debate with upstream
Scott Kitterman deb...@kitterman.com writes: On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote: On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote: SC§1 states that we want Debian to remain 100% free; the common interpretation of that is that one can download anything from Debian main and only get DFSG-free material; I think our sources are held to the same expectation. That's never been my expectation, FWIW. I do agree with Ian that this is stretching the goals of the project, at least as I perceive them. What percentage of free software in Debian main do you expect then? Absolutes have the benefit of simplicity and the disadvantage of not modeling the world all that well. Sometimes the simplicity and universal guarantee is still worth it, but at the same time I think it's worth realizing there are places where absolutes create weird corners. The part of free software that clearly matters the most is the software we provide to users to run, namely the contents of our binary packages and the source that produces them. That doesn't mean that nothing else is important, but I think it's fairly clear that's what's *most* important. Of the files that are not part of that set, there are a variety of cases, which have varying negative effects. The worst would be some file that's under a license with distribution restrictions. That may not be redistributable at all, and even if it is for us, it might cause problems for some downstream that wants to sell source CDs, etc. I think those are clearly not okay. Then there are files like RFCs that are under a non-DFSG license because they have weird restrictions on modification, but are freely distributable without modification. If these were installed in binary packages, they represent a clear problem, albeit usually a very frustrating one since it's highly unlikely that the restriction on RFC modification would ever actually be enforced by anyone. When they're only present in source packages, it's much harder to construct a scenario in which this matters. And it's very unclear why anyone would start from our source packages to modify RFCs instead of downloading them from all over the Internet. But it doesn't follow some of our guarantees for what one can do with everything one downloads from our archives. The case we're talking about here are files that are covered by a DFSG license but are not accompanied by source. These don't cause us or our downstreams any legal problems, and it's quite difficult to construct a likely scenario in which they cause any problems for our users either. Those files are not *useful* -- they are, in essence, random trash -- but they're a bit like litter. Against our rules, but not clearly able to cause anyone concrete problems. Farther down that chain are files that are under a DFSG license but are not source, where the source no longer, so far as anyone knows, exists. Those are still technical violations of the DFSG, but the violation is very technical and arguable. (If no one *has* the source, then whatever still exists is arguably now the preferred form of modification.) Those are already accepted into the archive (even in binary packages), because it's even harder to see any way in which they're really hurting anyone, and sometimes that's the only form in which still-useful documentation is available. And then there are license texts, many of which (such as the GPL) are covered by blatantly non-DFSG licenses themselves, but which are always acceptable in the archive and installed on every Debian system. Because we decided license texts were special and don't count as software for DFSG purposes. This stuff isn't *actually* black and white. We can *make* it black and white because we want simple rules even if they're sometimes weird, but the contents of distributions themselves are full of weird edge cases. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioriwu2x@windlord.stanford.edu
Re: jquery debate with upstream
On Thursday, March 13, 2014 14:21:22 Charles Plessy wrote: Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit : What percentage of free software in Debian main do you expect then? Hi Scott, I expect 100 % in the binary packages. On the other hand, the upstream tarballs are becoming temporary cruft that are not the preferred form for modification because they do not contain the typical revision information and comments found in version control systems used upstream. This was not the case when Debian was founded, but as the world evolves, we need to evolve. Oh. So you think to meet the DFSG we need to provide a copy of the VCS repository since the tarball isn't the preferred form of modification? That would be a huge change. Far bigger than repacking a few tarballs. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4529772.1BmzsFCMxx@scott-latitude-e6320
Re: jquery debate with upstream
On Wednesday, March 12, 2014 22:23:02 Russ Allbery wrote: Scott Kitterman deb...@kitterman.com writes: On Wednesday, March 12, 2014 23:22:13 Steve M. Robbins wrote: On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote: SC§1 states that we want Debian to remain 100% free; the common interpretation of that is that one can download anything from Debian main and only get DFSG-free material; I think our sources are held to the same expectation. That's never been my expectation, FWIW. I do agree with Ian that this is stretching the goals of the project, at least as I perceive them. What percentage of free software in Debian main do you expect then? Absolutes have the benefit of simplicity and the disadvantage of not modeling the world all that well. Sometimes the simplicity and universal guarantee is still worth it, but at the same time I think it's worth realizing there are places where absolutes create weird corners. The part of free software that clearly matters the most is the software we provide to users to run, namely the contents of our binary packages and the source that produces them. That doesn't mean that nothing else is important, but I think it's fairly clear that's what's *most* important. Of the files that are not part of that set, there are a variety of cases, which have varying negative effects. The worst would be some file that's under a license with distribution restrictions. That may not be redistributable at all, and even if it is for us, it might cause problems for some downstream that wants to sell source CDs, etc. I think those are clearly not okay. Then there are files like RFCs that are under a non-DFSG license because they have weird restrictions on modification, but are freely distributable without modification. If these were installed in binary packages, they represent a clear problem, albeit usually a very frustrating one since it's highly unlikely that the restriction on RFC modification would ever actually be enforced by anyone. When they're only present in source packages, it's much harder to construct a scenario in which this matters. And it's very unclear why anyone would start from our source packages to modify RFCs instead of downloading them from all over the Internet. But it doesn't follow some of our guarantees for what one can do with everything one downloads from our archives. The case we're talking about here are files that are covered by a DFSG license but are not accompanied by source. These don't cause us or our downstreams any legal problems, and it's quite difficult to construct a likely scenario in which they cause any problems for our users either. Those files are not *useful* -- they are, in essence, random trash -- but they're a bit like litter. Against our rules, but not clearly able to cause anyone concrete problems. Farther down that chain are files that are under a DFSG license but are not source, where the source no longer, so far as anyone knows, exists. Those are still technical violations of the DFSG, but the violation is very technical and arguable. (If no one *has* the source, then whatever still exists is arguably now the preferred form of modification.) Those are already accepted into the archive (even in binary packages), because it's even harder to see any way in which they're really hurting anyone, and sometimes that's the only form in which still-useful documentation is available. And then there are license texts, many of which (such as the GPL) are covered by blatantly non-DFSG licenses themselves, but which are always acceptable in the archive and installed on every Debian system. Because we decided license texts were special and don't count as software for DFSG purposes. This stuff isn't *actually* black and white. We can *make* it black and white because we want simple rules even if they're sometimes weird, but the contents of distributions themselves are full of weird edge cases. I think it's black and white if it's a bug. If it's worth investing the effort in fixing the bug is all kinds of shades of gray. If we're going to have the rule be that source in the preferred form of modification is only required when the license requires it, then we should change the rules of the project to match. DFSG #2 is not at all vague about what it requires. Additionally, I disagree that the freeness of the packages we give our users so they can modify the software is substantially less important than the freeness of the packages we give them to run. (recognizing that as a practically matter, compromises get made). Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/19106895.lMhg2AU34Z@scott-latitude-e6320
Re: jquery debate with upstream
Scott Kitterman deb...@kitterman.com writes: I think it's black and white if it's a bug. If it's worth investing the effort in fixing the bug is all kinds of shades of gray. I don't think that's a horribly useful distinction for this conversation, which is about what will be accepted into the archive or not. (In essence, this whole conversation is about whether it's an RC bug, which by definition is worth effort in fixing unless we remove the package entirely.) If we're going to have the rule be that source in the preferred form of modification is only required when the license requires it, then we should change the rules of the project to match. DFSG #2 is not at all vague about what it requires. Then we cannot include the GPL in our distribution, since it is under a clearly and unambiguously non-DFSG license, and therefore, by its license terms, must remove all of the software in the archive that is covered by it. In other words, while the above sounds very clear and consistent, it's not what we actually do. It's not clear to me that amending the social contract to carve out these various exception cases is worth the effort or will result in a less ambiguous document than we have now. The reality of practice is always messy. Additionally, I disagree that the freeness of the packages we give our users so they can modify the software is substantially less important than the freeness of the packages we give them to run. (recognizing that as a practically matter, compromises get made). There's a saying about priorities: if everything is equally important, that means nothing is important. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnxawsfl@windlord.stanford.edu
Re: jquery debate with upstream
On March 11, 2014 10:50:10 AM Paul Wise wrote:
On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote:
I'd love to see clarification of the ftp-team's position on obfuscated
files in source packages, preferably in an official location for future
reference.
Recalling that the context of the question was whether it is acceptable to
leave ${some file} in a tarball if it is unused ...
Source missing
Your package contains files that need source but do not have it. These
include PDF and PS files in the documentation, or auto-generated
files.
... I guess if a file is not needed for the build, then that file does not
need source either.
Generated files
Your package contains generated files (such as compressed .js
libraries) without corresponding original form. They're not considered
as the preferred form of modification,
Nor would it need to be modified, so it shouldn't matter that it's not the
preferred form for modification.
I can understand that it is nicer if upstream can be persuaded to clean things
up and not do either of the above. I also realize that some folks may prefer
to re-pack a tarball for cleanliness objectives. But are you really
suggesting a distributable but non source file in the tarball can't simply be
ignored? What objective would that serve?
Regards,
-Steve
signature.asc
Description: This is a digitally signed message part.
Re: jquery debate with upstream
Quoting Steve M. Robbins (2014-03-11 07:11:36)
On March 11, 2014 10:50:10 AM Paul Wise wrote:
On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote:
I'd love to see clarification of the ftp-team's position on
obfuscated files in source packages, preferably in an official
location for future reference.
Recalling that the context of the question was whether it is
acceptable to leave ${some file} in a tarball if it is unused ...
Yes. Leaving in tarball (as opposed to repackaging tarball to exclude a
file) relates to *source* package, not produced binary packages.
Source missing
Your package contains files that need source but do not have it.
These include PDF and PS files in the documentation, or
auto-generated files.
... I guess if a file is not needed for the build, then that file does
not need source either.
Whether it is needed for build or not is related to production and
Debian redistribution of *binary* packages.
Generated files
Your package contains generated files (such as compressed .js
libraries) without corresponding original form. They're not
considered as the preferred form of modification,
Nor would it need to be modified, so it shouldn't matter that it's not
the preferred form for modification.
I can understand that it is nicer if upstream can be persuaded to
clean things up and not do either of the above. I also realize that
some folks may prefer to re-pack a tarball for cleanliness
objectives. But are you really suggesting a distributable but non
source file in the tarball can't simply be ignored? What objective
would that serve?
I believe it is exactly the case that Debian do not allow
(re)distribution of source which is not in the preferred form of
editing.
Debian have a certain definition of Freedoms that we uphold which is
largely compatible with other parts of the FOSS community, but not
always identical - which leads to oddities like this need to repackage
and strip parts of code that is properly licensed by upstream but still
do not fit our definition of how things are acceptable to _us_ to
distribute.
When approaching upstreams about this, we should be careful to not try
impose our World views onto them, but only share with them how we treat
their code that they have chosen to share with us, and how it would be
more convenient for us that they share it slightly different. They are
commonly not doing anything wrong, just by a different freedom logic
than ours.
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: jquery debate with upstream
Jonas Smedegaard writes (Re: jquery debate with upstream): Quoting Steve M. Robbins (2014-03-11 07:11:36) I can understand that it is nicer if upstream can be persuaded to clean things up and not do either of the above. I also realize that some folks may prefer to re-pack a tarball for cleanliness objectives. But are you really suggesting a distributable but non source file in the tarball can't simply be ignored? What objective would that serve? None. I think the file can be disregarded, provided we're sure it's not used during the build. I believe it is exactly the case that Debian do not allow (re)distribution of source which is not in the preferred form of editing. You have conspicuously failed to answer Jonas's question. What objective does removing these files and repacking the tarballs serve ? Debian have a certain definition of Freedoms [...] Whose freedom is impaired, and in what way, by the presence of these useless but ignored files in the tarball ? When approaching upstreams about this, we should be careful to not try impose our World views onto them, but only share with them how we treat their code that they have chosen to share with us, and how it would be more convenient for us that they share it slightly different. They are commonly not doing anything wrong, just by a different freedom logic than ours. In this subthread I think we are having an internal conversation about what our own logic is, within Debian. I'm sorry to say that I still fail to see the logic behind your apparent (but not explicitly stated) point of view. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21279.10430.860867.946...@chiark.greenend.org.uk
Re: jquery debate with upstream
[ not as ftpteam -- man, I'm saying this a lot lately ] On Tue, Mar 11, 2014 at 03:16:14PM +, Ian Jackson wrote: You have conspicuously failed to answer Jonas's question. What objective does removing these files and repacking the tarballs serve ? We distribute source. The question is, do we want to distribute binaries in the source to which we have no, well, source. This means, do we want to break the DFSG on the distribution of source packages? Debian have a certain definition of Freedoms [...] Whose freedom is impaired, and in what way, by the presence of these useless but ignored files in the tarball ? We distribute them. The challenge here is does anyone use them. I leave that question up to the reader. In this subthread I think we are having an internal conversation about what our own logic is, within Debian. I'm sorry to say that I still fail to see the logic behind your apparent (but not explicitly stated) point of view. Hopefully you can grok mine :) Ian. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: jquery debate with upstream
On 03/11/2014 11:16 PM, Ian Jackson wrote: Debian have a certain definition of Freedoms [...] Whose freedom is impaired, and in what way, by the presence of these useless but ignored files in the tarball ? In one of my package, I had openssl.dll in the source tarball (it was of course removed later on). Would you consider it ok as well to have it in a source package, as long as it's not used during the build? And what about a windows .exe? Is it different from having a minified .js that is also not in use? Cheers, Thomas (note: this is not sarcasm or whatever, this is a real case that I'm talking about, and I'm really interested in the opinion of Ian) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531f37bb.9050...@debian.org
Re: jquery debate with upstream
Paul Tagliamonte writes (Re: jquery debate with upstream): On Tue, Mar 11, 2014 at 03:16:14PM +, Ian Jackson wrote: You have conspicuously failed to answer Jonas's question. What objective does removing these files and repacking the tarballs serve ? We distribute source. The question is, do we want to distribute binaries in the source to which we have no, well, source. This means, do we want to break the DFSG on the distribution of source packages? I don't think this is a significant breach of the DFSG. The whole point of the project is to enhance people's software freedom. Repackaging these tarballs to remove these useless and unused files does not enhance anyone's freedom. Debian have a certain definition of Freedoms [...] Whose freedom is impaired, and in what way, by the presence of these useless but ignored files in the tarball ? We distribute them. The challenge here is does anyone use them. I leave that question up to the reader. Why would anyone take the Debian package and then go out of their way to use sourceless files they find in it ? I don't think these kind of hypotheticals are answering the question. Repackaging these tarballs for this reason is utterly pointless. No-one has been able to explain what the benefit is, to anyone. All we get when we challenge it is, I'm sad to say, vague and abstract responses like this one. We should stop this makework and get on with doing something useful. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21279.20836.500723.92...@chiark.greenend.org.uk
Re: jquery debate with upstream
[not ftpteam] On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote: I don't think this is a significant breach of the DFSG. Ah, but you do acknowledge this *is* a breach, even if a small one. So this comes down to where the line is, like I said. You may think a line is somewhere, but the DFSG is interpreted by the ftp-masters, so the question isn't what paultag or ian says, but what the ftp-masters say :) Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: jquery debate with upstream
On Tue, 11 Mar 2014, Ian Jackson wrote: Repackaging these tarballs for this reason is utterly pointless. No-one has been able to explain what the benefit is, to anyone. All we get when we challenge it is, I'm sad to say, vague and abstract responses like this one. The point of repacking the tarballs is to avoid ever distributing things for which we do not have the source. We do that for multiple reasons: 1) We promise that all of the components of Debian will be free, and thus will have source available. 2) Stripping out the non-source means that the binary package won't ever accidentally distribute it. The primary reason not to strip is because repacking is annoying, but with uscan's support of Files-Excluded, and other utility scripts[1] this is largely resolved. Even if you don't strip, you still have to do all the work to make sure that the embedded non-source copy isn't built against or distributed. 1: I personally use the perl team's repack.sh, but I'll probably transition to Files-Excluded. -- Don Armstrong http://www.donarmstrong.com Ban cryptography! Yes. Let's also ban pencils, pens and paper, since criminals can use them to draw plans of the joint they are casing or even, god forbid, create one time pads to pass uncrackable codes to each other. Ban open spaces since criminals could use them to converse with each other out of earshot of the police. Let's ban flags since they could be used to pass secret messages in semaphore. In fact let's just ban all forms of verbal and non-verbal communication -- let's see those criminals make plans now! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140311183927.gg7...@rzlab.ucr.edu
Re: jquery debate with upstream
Thomas Goirand writes (Re: jquery debate with upstream): In one of my package, I had openssl.dll in the source tarball (it was of course removed later on). Would you consider it ok as well to have it in a source package, as long as it's not used during the build? And what about a windows .exe? Is it different from having a minified .js that is also not in use? Yes, I think all of these things are tolerable, so long as the files are in fact redistributable (which depending on the licence they might not be). I think that if we want a more convenient and reliable way to avoid them being used during the build, we should have a way to make dpkg-source remove the files from the tree as it unpacks the source. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21279.24031.252935.355...@chiark.greenend.org.uk
Re: jquery debate with upstream
On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote: We should stop this makework and get on with doing something useful. Thanks for providing me with my 'word of the day' (makework) which seems to me to embody a growing collection of activities in Debian in modern times. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140311201424.ga32...@bryant.redmars.org
Re: jquery debate with upstream
On 2014-03-11, Paul Tagliamonte paul...@debian.org wrote: On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote: I don't think this is a significant breach of the DFSG. Ah, but you do acknowledge this *is* a breach, even if a small one. So this comes down to where the line is, like I said. As a Debian Developer, I will uphold the DFSG except where it is inconvenient ? I actually think the DFSG is a great document and we shouldn't just stray from it because it is inconvenient. If I had to disregard the DFSG in some cases, I'd rather see rfc files in our files than sourceless javascripts. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lfnufq$f0n$1...@ger.gmane.org
Re: jquery debate with upstream
Hi, Am Dienstag, den 11.03.2014, 19:02 + schrieb Ian Jackson: I think that if we want a more convenient and reliable way to avoid them being used during the build, we should have a way to make dpkg-source remove the files from the tree as it unpacks the source. debian/clean is sufficient for that, I’d say. Enough package building tools clean before the build so that one would notice in due time that the build accidentally uses it. Before this thread gets too long and we hear too many opinion from people don’t have a say in this (like me), I’d like to hear an official statement from the ftp-team on the question: Does Debian tolerate files in upstream tarballs that are (1) legally distributable and (2) not used in any way during the build, even if they do not come with their preferred form of modification? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: jquery debate with upstream
Le Tue, Mar 11, 2014 at 08:14:24PM +, Jonathan Dowland a écrit : On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote: We should stop this makework and get on with doing something useful. Thanks for providing me with my 'word of the day' (makework) which seems to me to embody a growing collection of activities in Debian in modern times. I agree. Debian is too much about some people telling others to do useless things. We can not at the same time glorify ourselves for our number of packages and our universality, and on the other hand expect that all the upstream sources have the same level of cleanness as core works such as the Linux kernel, GCC, the coreutils etc. Tarball repacking is a practice from the tarball world. Our future if we stay in the tarball world is to be the rock-solid base package supermarket on which others build the real thing, because our intolerance for minor defects will make us unable to collect complex ensembles of specialised packages. Long time ago, one could see the Debian CD as a state-of-the-art multipurpose software repository useful on other systems as Debian itself, but now, more people would not find it useful and would rather clone an upstream Git repository than apt-get-sourcing the not-always latest source from our archive. Therefore, more than ever, it is on the binary packages that we must commit on the highest level. The upstream source tarball matters much less. Cheers, -- 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: https://lists.debian.org/20140311220829.ga8...@falafel.plessy.net
Re: jquery debate with upstream
Sune Vuorela nos...@vuorela.dk writes: If I had to disregard the DFSG in some cases, I'd rather see rfc files in our files than sourceless javascripts. If they're in the source packages but not installed, I believe this is an equivalent case, yes. And it would certainly make some packages easier to manage (openldap and heimdal come to mind just off the top of my head). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a9cwjsk8@windlord.stanford.edu
Re: jquery debate with upstream
On 03/12/2014 05:16 AM, Sune Vuorela wrote: On 2014-03-11, Paul Tagliamonte paul...@debian.org wrote: On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote: I don't think this is a significant breach of the DFSG. Ah, but you do acknowledge this *is* a breach, even if a small one. So this comes down to where the line is, like I said. As a Debian Developer, I will uphold the DFSG except where it is inconvenient ? I actually think the DFSG is a great document and we shouldn't just stray from it because it is inconvenient. If I had to disregard the DFSG in some cases, I'd rather see rfc files in our files than sourceless javascripts. /Sune Oh, let's talk about this! :) I had once a package rejected because the doc contained a logo in PNG format, which had in its header clues that it has been generated. I later on just removed the logo in a +dfsg package... Added benefits to this? In my opinion, the package was just *less* good, it took some of my time, and users don't have an (ugly and generated) logo in the doc, and have instead a broken link in the HTML (cause I had better things to do than to fix this as well...). I think THAT went too far (but I do agree we should get rid of minified javascript files). As Paul wrote it, it's all about where we draw the line. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531fc8e8.5030...@debian.org
Re: jquery debate with upstream
Hi, Am Montag, den 10.03.2014, 20:29 +0100 schrieb Philipp Kern: as long as the code in question is not under a license that requires the full, non-minified source to be reproduced and if the copyright notices and license terms as potentially required by the license are present, I don't see why not. But I guess the latter is not commonly happening? The most common case is that the file http://code.jquery.com/jquery-1.11.0.min.js is included without http://code.jquery.com/jquery-1.11.0.js The minified file contains a copyright header, and the license is MIT, so I believe shipping jquery-1.11.0.min.js without query-1.11.0.js is allowed. So you’d say it is acceptable to leave jquery-1.11.0.min.js in a tarball if it is unused (e.g. if it is removed in the clean target, and possibly documented in README.Source)? Can maybe someone from the ftp-team confirm this? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: jquery debate with upstream
Joachim Breitner nome...@debian.org writes: So you’d say it is acceptable to leave jquery-1.11.0.min.js in a tarball if it is unused (e.g. if it is removed in the clean target, and possibly documented in README.Source)? Can maybe someone from the ftp-team confirm this? My understanding (as someone who is not on the ftp-team) is contrary to that. Rather, a file that is in a non-source form – such as an obfuscated (minified) JS file – must be removed from the source package. I'd love to see clarification of the ftp-team's position on obfuscated files in source packages, preferably in an official location for future reference. -- \ “Nothing is more sacred than the facts.” —Sam Harris, _The End | `\ of Faith_, 2004 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85y50htyay@benfinney.id.au
Re: jquery debate with upstream
On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote: I'd love to see clarification of the ftp-team's position on obfuscated files in source packages, preferably in an official location for future reference. I quote from [1]: Source missing Your package contains files that need source but do not have it. These include PDF and PS files in the documentation, or auto-generated files. Generated files Your package contains generated files (such as compressed .js libraries) without corresponding original form. They're not considered as the preferred form of modification, so you will either have to provide corresponding original form, or remove them from your tarball, eventually depending on an already available packages to provide missing features. 1. https://ftp-master.debian.org/REJECT-FAQ.html -- 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: https://lists.debian.org/CAKTje6HtQ5k_-APj8msrDq=k_qkcsr74ypn5hwsg6c5-kve...@mail.gmail.com
