Re: jquery debate with upstrea
Hi Joachim, On Wed, Mar 12, 2014 at 11:02:27PM +0100, Joachim Breitner wrote: Hi, Am Mittwoch, den 12.03.2014, 18:37 -0300 schrieb Lisandro Damián Nicanor Pérez Meyer: Do you (or anyone) know if it repacks the file consistently? I.e. will two developers, who both use uscan to get the original tarball for the same version and with the same File-Excluded get identical results? IIRC, it uses an invocation of find to do the job, so I guess the answer is yes. it sounded be too good to be true: $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz d6af2e99727cfb6abca56d1c5a4d1e92 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz 9bd7134bb56a093b5f61ba7b710af826 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz This would be quite annoying in my usual workflow. I hope you are aware that taring up two byte identical trees usually does not lead to a byte identical tarball. This was discussed on debian-devel several times and the only way to *regenerate* a *given* tarball is pristine-tar. So if you use the usual Git workflow your team mates can obtain a byte identical tarball as you did create. You are simply expecting the impossible and this is for instance the same (mis)feature as you get when repackaging an original zip archive. The only thing Files-Excluded is solving that the *unpackaged* tarball is byte identical. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313130650.gc7...@an3as.eu
Re: jquery debate with upstrea
Hi Lisandro, On Wed, Mar 12, 2014 at 07:53:52PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: it sounded be too good to be true: $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz d6af2e99727cfb6abca56d1c5a4d1e92 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz 9bd7134bb56a093b5f61ba7b710af826 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz Ah, at the tar level. Yes, they will no be the same. Or more correctly: They technically *can not* be the same. If you use something else than the Git workflow with pristine-tar this is actually also no problem. The orig-tarball which is actually uploaded with the package could be used afterwards anyway - there is no point in firing up uscan again. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313130934.gd7...@an3as.eu
Re: jquery debate with upstrea
Hi, Am Donnerstag, den 13.03.2014, 14:06 +0100 schrieb Andreas Tille: This would be quite annoying in my usual workflow. I hope you are aware that taring up two byte identical trees usually does not lead to a byte identical tarball. Well, I was hoping that uscan would not simply create new tarballs, but rather removing it from the tarfile, which seems to be deterministic: $ zcat haskell-mtl_2.1.2.orig.tar.gz | md5sum - bac0c479109021b9d2b3696a0b001f5a - $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | md5sum - 0ef3b46f5e345521fd40bc634e0fc1d1 - $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | md5sum - 0ef3b46f5e345521fd40bc634e0fc1d1 - $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | gzip -n | md5sum - 909d962dacabbf1c5430df2ac1c20ef3 - $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | gzip -n | md5sum - 909d962dacabbf1c5430df2ac1c20ef3 - (This is probably equivalent to what Mike does in python.) Of course I could change my workflow to cope with a non-deterministic uscan --download, so this is not very important. But then, this thread is all about what level of convenience we allow ourselves, and what we spend our time on. 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 upstrea
Hi Joachim, On Thu, Mar 13, 2014 at 02:49:00PM +0100, Joachim Breitner wrote: I hope you are aware that taring up two byte identical trees usually does not lead to a byte identical tarball. Well, I was hoping that uscan would not simply create new tarballs, but rather removing it from the tarfile, which seems to be deterministic: $ zcat haskell-mtl_2.1.2.orig.tar.gz | md5sum - bac0c479109021b9d2b3696a0b001f5a - $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | md5sum - 0ef3b46f5e345521fd40bc634e0fc1d1 - $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | md5sum - 0ef3b46f5e345521fd40bc634e0fc1d1 - $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | gzip -n | md5sum - 909d962dacabbf1c5430df2ac1c20ef3 - $ zcat haskell-mtl_2.1.2.orig.tar.gz | tar --delete mtl-2.1.2/mtl.cabal | gzip -n | md5sum - 909d962dacabbf1c5430df2ac1c20ef3 - (This is probably equivalent to what Mike does in python.) I admit that I simply failed to consider this option when implementing Files-Excluded and when thinking about it I'm not sure how this should elegantly work together with `find` to exclude groups of files reasonably. My original patch to implement Files-Excluded contained another feature described in #730768 (and fixed in Git as I just realised) to enable better compression once we are loosing the same MD5sum feature anyway. From my perspective this definitely would outweight the fact that two different persons would get a byte identical result. For historical reasons and to simplify the acceptance of the whole patch Rafael Laboissiere has split those two functions into two separate patches (and according bug reports) and these made their way into different releases of devscripts. In short: I consider the repackaging as a solution that works in the same way as before when there were reasons to repack something (*.zip) which if you want to use extra features like better compression does not have any visible drawbacks. I agree that your --delete solution looks more clean but would need somebody who might implement this. Of course I could change my workflow to cope with a non-deterministic uscan --download, so this is not very important. But then, this thread is all about what level of convenience we allow ourselves, and what we spend our time on. Exactly. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313141403.gh7...@an3as.eu
Re: jquery debate with upstrea
On Tuesday 11 March 2014 09:07:43 Joachim Breitner wrote: Hi, Am Dienstag, den 11.03.2014, 10:34 +0800 schrieb Paul Wise: On Tue, Mar 11, 2014 at 1:27 AM, Joachim Breitner wrote: nor mess with tarball repackaging (which I consider ugly, a cludge, and to be avoided if possible) Recent versions of uscan can automatically repack upstream tarballs to remove files, just include a Files-Excluded line in debian/copyright. ah, that’s news to me and has been on my secret wish list for long (and wasn’t the case when I last looked)! That solves half of my issues with this. It’s not well documented in man uscan, which only tells me how to disable that feature. Do you (or anyone) know if it repacks the file consistently? I.e. will two developers, who both use uscan to get the original tarball for the same version and with the same File-Excluded get identical results? IIRC, it uses an invocation of find to do the job, so I guess the answer is yes. -- Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch. So there's a camaraderie here we seldom see outside of our professional contacts. http://www.c2.com/cgi/wiki?WhyWikiWorks Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstrea
Hi, Am Mittwoch, den 12.03.2014, 18:37 -0300 schrieb Lisandro Damián Nicanor Pérez Meyer: Do you (or anyone) know if it repacks the file consistently? I.e. will two developers, who both use uscan to get the original tarball for the same version and with the same File-Excluded get identical results? IIRC, it uses an invocation of find to do the job, so I guess the answer is yes. it sounded be too good to be true: $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz d6af2e99727cfb6abca56d1c5a4d1e92 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz 9bd7134bb56a093b5f61ba7b710af826 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz This would be quite annoying in my usual workflow. 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 upstrea
On Wed, Mar 12, 2014 at 11:02:27PM +0100, Joachim Breitner wrote: Hi, Am Mittwoch, den 12.03.2014, 18:37 -0300 schrieb Lisandro Damián Nicanor Pérez Meyer: Do you (or anyone) know if it repacks the file consistently? I.e. will two developers, who both use uscan to get the original tarball for the same version and with the same File-Excluded get identical results? IIRC, it uses an invocation of find to do the job, so I guess the answer is yes. it sounded be too good to be true: $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz d6af2e99727cfb6abca56d1c5a4d1e92 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz 9bd7134bb56a093b5f61ba7b710af826 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz This would be quite annoying in my usual workflow. I guess it just unpacks, removes and repacks. Which also means it would be quite annoying in my own workflow which involves unpacking/repacking 700MB. The script I'm using now does the filtering on the tar stream itself, without actually unpacking. (it's also able to do it while downloading) Mike -- 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/20140312221408.ga30...@glandium.org
Re: jquery debate with upstrea
On Wednesday 12 March 2014 23:02:27 Joachim Breitner wrote: Hi, Am Mittwoch, den 12.03.2014, 18:37 -0300 schrieb Lisandro Damián Nicanor Pérez Meyer: Do you (or anyone) know if it repacks the file consistently? I.e. will two developers, who both use uscan to get the original tarball for the same version and with the same File-Excluded get identical results? IIRC, it uses an invocation of find to do the job, so I guess the answer is yes. it sounded be too good to be true: $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz d6af2e99727cfb6abca56d1c5a4d1e92 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz $ rm ../*tar.gz uscan --download md5sum ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz haskell-ekg: Newer version (0.3.1.4) available on remote site: http://hackage.haskell.org/package/ekg-0.3.1.4/ekg-0.3.1.4.tar.gz (local version is 0.3.1.3) haskell-ekg: Successfully downloaded updated package ekg-0.3.1.4.tar.gz and removed files from it in haskell-ekg_0.3.1.4+dfsg.orig.tar.gz 9bd7134bb56a093b5f61ba7b710af826 ../haskell-ekg_0.3.1.4+dfsg.orig.tar.gz Ah, at the tar level. Yes, they will no be the same. -- You don’t marry someone you can live with – you marry the person who you cannot live without. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstrea
On Thu, Mar 13, 2014 at 6:14 AM, Mike Hommey wrote: I guess it just unpacks, removes and repacks. Which also means it would be quite annoying in my own workflow which involves unpacking/repacking 700MB. The script I'm using now does the filtering on the tar stream itself, without actually unpacking. (it's also able to do it while downloading) I think it would be interesting to improve the uscan implementation, could you share how it does 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/caktje6hugkow1kfakh1ft_w9wvz-wd5e1deekzisv2nbs1g...@mail.gmail.com
Re: jquery debate with upstrea
On Thu, Mar 13, 2014 at 08:06:14AM +0800, Paul Wise wrote: On Thu, Mar 13, 2014 at 6:14 AM, Mike Hommey wrote: I guess it just unpacks, removes and repacks. Which also means it would be quite annoying in my own workflow which involves unpacking/repacking 700MB. The script I'm using now does the filtering on the tar stream itself, without actually unpacking. (it's also able to do it while downloading) I think it would be interesting to improve the uscan implementation, could you share how it does that? http://anonscm.debian.org/gitweb/?p=pkg-mozilla/iceweasel.git;a=blob;f=debian/repack.py;h=582938ac29f2f572da4651e2c2e39e05f180cc78;hb=5714e86ab68899722589e7c4e8de758e73b4d4bd Mike -- 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/20140313005439.ga32...@glandium.org
Re: jquery debate with upstrea
Hi, Am Dienstag, den 11.03.2014, 10:34 +0800 schrieb Paul Wise: On Tue, Mar 11, 2014 at 1:27 AM, Joachim Breitner wrote: nor mess with tarball repackaging (which I consider ugly, a cludge, and to be avoided if possible) Recent versions of uscan can automatically repack upstream tarballs to remove files, just include a Files-Excluded line in debian/copyright. ah, that’s news to me and has been on my secret wish list for long (and wasn’t the case when I last looked)! That solves half of my issues with this. It’s not well documented in man uscan, which only tells me how to disable that feature. Do you (or anyone) know if it repacks the file consistently? I.e. will two developers, who both use uscan to get the original tarball for the same version and with the same File-Excluded get identical results? 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 upstrea
Hi. Joachim Breitner nome...@debian.org writes: Hi, I keep discussing the same issues caused by minified JS files (mostly JQuery) in their source tarballs over and over. Could maybe those who care deeply about this write a concise wiki page with all that upstream needs to know about our expectations, so that I can point them to it? That page should also point out the least effort required to satisfy us (which, I believe, is downloading the corresponding source and dumping it in the tarball). It seems no one mentioned it, so may the following page suit your needs: https://wiki.debian.org/UpstreamGuide Maybe it lacks specific directions about the minimized JS files, or should point at a dedicated page. My 2 cents, Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- 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/871ty9rrfh@inf-8660.int-evry.fr
Re: jquery debate with upstrea
Quoting Russ Allbery (2014-03-11 03:32:54) Paul Wise p...@debian.org writes: I'd suggest an acceptable workaround is to include the source in the debian.tar.gz/diff.gz or to repack the upstream tarball, probably the latter since jQuery is usually an embedded code copy. https://wiki.debian.org/EmbeddedCodeCopies Note that we do not (and should not) repack upstream source for embedded code copies that are not used in the build, if there are no other issues with those copies. It's sufficient to just not use them. I agree that there are better ways than repackaging. I disagree that just not using [parts lacking true source] is one of them. Instead I find that the combination of these is acceptable: a) Include the true source in our addendum (the diff for v1 or the tarball for v3 source formats) b) Ensure that reformulated source in the tarball we redistribute pristine is indeed a reformulation of the true source (e.g. by comparing checksum against same processing done once) That's more elegant in that we ship pristine upstream tarball, but not simpler because it puts the burden on the package maintainer to prove that the source we redistribute was not altered only reformulated. - 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 upstrea
Hi, Am Dienstag, den 11.03.2014, 11:22 +0100 schrieb Jonas Smedegaard: Quoting Russ Allbery (2014-03-11 03:32:54) Paul Wise p...@debian.org writes: I'd suggest an acceptable workaround is to include the source in the debian.tar.gz/diff.gz or to repack the upstream tarball, probably the latter since jQuery is usually an embedded code copy. https://wiki.debian.org/EmbeddedCodeCopies Note that we do not (and should not) repack upstream source for embedded code copies that are not used in the build, if there are no other issues with those copies. It's sufficient to just not use them. I agree that there are better ways than repackaging. I disagree that just not using [parts lacking true source] is one of them. Instead I find that the combination of these is acceptable: a) Include the true source in our addendum (the diff for v1 or the tarball for v3 source formats) b) Ensure that reformulated source in the tarball we redistribute pristine is indeed a reformulation of the true source (e.g. by comparing checksum against same processing done once) That's more elegant in that we ship pristine upstream tarball, but not simpler because it puts the burden on the package maintainer to prove that the source we redistribute was not altered only reformulated. I see how that is solves the problem, and how it is idiologically desirable, but is it worth it? Consider this: I find a package that ships some-lib.min.js without source. It happens that we have libsomelib-js in Debian. So I 1. Make debian/rules not install some-lib.min.js into the binaries. 2. Change e.g. the HTML files to point to the file in libsomelib-js. 3. Try to find out what precise version some-lib.min.js is. 4. Hunt down the source package for that version and include it in debian/ 5. Build that to get another copy of some-lib.min.js is. 6. Compare it with the one shipped by upstream. 7. Possibly tweak build settings until the results are the same, trying out various minimizers and options. Of these 7 steps, only the first two actually affect the resulting package, i.e. our users. From a practical point of view, I don’t believe that we should spend time on 3-7, and instead replace it by 3. Ensure that we can legally distribute libsomelib-js 4. Add it to debian/clean (or maybe Excluded-Files), and be done with it. 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 upstrea
Quoting Joachim Breitner (2014-03-11 11:29:31) Am Dienstag, den 11.03.2014, 11:22 +0100 schrieb Jonas Smedegaard: Quoting Russ Allbery (2014-03-11 03:32:54) Paul Wise p...@debian.org writes: I'd suggest an acceptable workaround is to include the source in the debian.tar.gz/diff.gz or to repack the upstream tarball, probably the latter since jQuery is usually an embedded code copy. https://wiki.debian.org/EmbeddedCodeCopies Note that we do not (and should not) repack upstream source for embedded code copies that are not used in the build, if there are no other issues with those copies. It's sufficient to just not use them. I agree that there are better ways than repackaging. I disagree that just not using [parts lacking true source] is one of them. Instead I find that the combination of these is acceptable: a) Include the true source in our addendum (the diff for v1 or the tarball for v3 source formats) b) Ensure that reformulated source in the tarball we redistribute pristine is indeed a reformulation of the true source (e.g. by comparing checksum against same processing done once) That's more elegant in that we ship pristine upstream tarball, but not simpler because it puts the burden on the package maintainer to prove that the source we redistribute was not altered only reformulated. I see how that is solves the problem, and how it is idiologically desirable, but is it worth it? Consider this: I find a package that ships some-lib.min.js without source. It happens that we have libsomelib-js in Debian. So I 1. Make debian/rules not install some-lib.min.js into the binaries. 2. Change e.g. the HTML files to point to the file in libsomelib-js. 3. Try to find out what precise version some-lib.min.js is. 4. Hunt down the source package for that version and include it in debian/ 5. Build that to get another copy of some-lib.min.js is. 6. Compare it with the one shipped by upstream. 7. Possibly tweak build settings until the results are the same, trying out various minimizers and options. Of these 7 steps, only the first two actually affect the resulting package, i.e. our users. From a practical point of view, I don’t believe that we should spend time on 3-7, and instead replace it by 3. Ensure that we can legally distribute libsomelib-js 4. Add it to debian/clean (or maybe Excluded-Files), and be done with it. Yes, I did not mean to say that the tedious 7-step process is the only possible way, just that it was _a_ possible way to avoid repackaging upstream tarball but redistribute it pristine. Your alternate 4-step process is an easier but uglier alternative. If you care only about those of our users that consume binary packages, you may not even recognize the 4-step procedure as uglier ;-) - 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
jquery debate with upstrea
Hi, I keep discussing the same issues caused by minified JS files (mostly JQuery) in their source tarballs over and over. Could maybe those who care deeply about this write a concise wiki page with all that upstream needs to know about our expectations, so that I can point them to it? That page should also point out the least effort required to satisfy us (which, I believe, is downloading the corresponding source and dumping it in the tarball). Also, am I too pragmatic in suggesting that we should accept non-source files in tarballs if they are legally distributed and not used during the build (especially not included in the binary packages)? If we had this I would neither have to bug upstream about their convenience copies nor mess with tarball repackaging (which I consider ugly, a cludge, and to be avoided if possible) and simply make sure in the packaging that I use libjs-jquery instead of the included file. 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 upstrea
On March 10, 2014 06:27:01 PM Joachim Breitner wrote: Also, am I too pragmatic in suggesting that we should accept non-source files in tarballs if they are legally distributed and not used during the build (especially not included in the binary packages)? I generally take that approach. If there's a concern about tainting the binary package, then I put a rule in debian/rules to make sure the offending file is removed before building. -Steve signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstrea
On 2014-03-10 13:05:30, Steve M. Robbins wrote: On March 10, 2014 06:27:01 PM Joachim Breitner wrote: Also, am I too pragmatic in suggesting that we should accept non-source files in tarballs if they are legally distributed and not used during the build (especially not included in the binary packages)? I generally take that approach. If there's a concern about tainting the binary package, then I put a rule in debian/rules to make sure the offending file is removed before building. Hi all, Some time ago there was discussion about minified js on d-mentors and from what I know conclusion was that if orig.tar.gz contains any of this type of files it should be repacked and version should be +dfsg. Explanation about it should be in README.source. -- |_|0|_| | |_|_|0| Heghlu'Meh QaQ jajVam | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: Digital signature
Re: jquery debate with upstrea
Hi, On 2014-03-10 18:27, Joachim Breitner wrote: I keep discussing the same issues caused by minified JS files (mostly JQuery) in their source tarballs over and over. Could maybe those who care deeply about this write a concise wiki page with all that upstream needs to know about our expectations, so that I can point them to it? That page should also point out the least effort required to satisfy us (which, I believe, is downloading the corresponding source and dumping it in the tarball). Also, am I too pragmatic in suggesting that we should accept non-source files in tarballs if they are legally distributed and not used during the build (especially not included in the binary packages)? If we had this I would neither have to bug upstream about their convenience copies nor mess with tarball repackaging (which I consider ugly, a cludge, and to be avoided if possible) and simply make sure in the packaging that I use libjs-jquery instead of the included file. 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? 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/3bf683cdfbaab11625a69edecad8a...@hub.kern.lc
Re: jquery debate with upstrea
On Tue, Mar 11, 2014 at 3:29 AM, Philipp Kern pk...@debian.org wrote: Hi, On 2014-03-10 18:27, Joachim Breitner wrote: I keep discussing the same issues caused by minified JS files (mostly JQuery) in their source tarballs over and over. Could maybe those who care deeply about this write a concise wiki page with all that upstream needs to know about our expectations, so that I can point them to it? That page should also point out the least effort required to satisfy us (which, I believe, is downloading the corresponding source and dumping it in the tarball). Also, am I too pragmatic in suggesting that we should accept non-source files in tarballs if they are legally distributed and not used during the build (especially not included in the binary packages)? If we had this I would neither have to bug upstream about their convenience copies nor mess with tarball repackaging (which I consider ugly, a cludge, and to be avoided if possible) and simply make sure in the packaging that I use libjs-jquery instead of the included file. 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? 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/3bf683cdfbaab11625a69edecad8a...@hub.kern.lc -- bye, pabs http://wiki.debian.org/PaulWise http://bonedaddy.net/pabs3/ -- 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/CAKTje6Eu9gywVd_in=v+h+gcvyn9-johsh2vbaaj0k4itdx...@mail.gmail.com
Re: jquery debate with upstrea
On Tue, Mar 11, 2014 at 3:29 AM, Philipp Kern wrote: 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? I think that DFSG item 2 means we have promised not to do this. Also this particular issue is in the reject FAQ. https://ftp-master.debian.org/REJECT-FAQ.html I'd suggest an acceptable workaround is to include the source in the debian.tar.gz/diff.gz or to repack the upstream tarball, probably the latter since jQuery is usually an embedded code copy. https://wiki.debian.org/EmbeddedCodeCopies -- 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/CAKTje6H4E0sm=zUp4Gft1YggfRoBPYs=uvjpx07lexywix2...@mail.gmail.com
Re: jquery debate with upstrea
Paul Wise p...@debian.org writes: I'd suggest an acceptable workaround is to include the source in the debian.tar.gz/diff.gz or to repack the upstream tarball, probably the latter since jQuery is usually an embedded code copy. https://wiki.debian.org/EmbeddedCodeCopies Note that we do not (and should not) repack upstream source for embedded code copies that are not used in the build, if there are no other issues with those copies. It's sufficient to just not use them. -- 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/8761nltqg9@windlord.stanford.edu
Re: jquery debate with upstrea
On Tue, Mar 11, 2014 at 1:27 AM, Joachim Breitner wrote: nor mess with tarball repackaging (which I consider ugly, a cludge, and to be avoided if possible) Recent versions of uscan can automatically repack upstream tarballs to remove files, just include a Files-Excluded line in debian/copyright. -- 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/caktje6hg9yjzbw+uyetof8s65axyfacejcjvc8bgtquanwg...@mail.gmail.com
Re: jquery debate with upstrea
Paul Wise p...@debian.org writes: I think that DFSG item 2 means we have promised not to do this. Also this particular issue is in the reject FAQ. https://ftp-master.debian.org/REJECT-FAQ.html It would be very helpful if Paul could at this point give a URL to exactly which item he's referring to. But that document doesn't appear to have an addressible structure. Which item in that FAQ document are you referring to? -- \ “You say “Carmina”, and I say “Burana”, You say “Fortuna”, and | `\I say “cantata”, Carmina, Burana, Fortuna, cantata, Let's Carl | _o__)the whole thing Orff.” —anonymous | 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/85lhwhtmjm@benfinney.id.au
