Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Russ Allbery writes (Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)): Ian Jackson ijack...@chiark.greenend.org.uk writes: Well, some maintainers have been rebuilding source packages to remove things like RFCs and non-free-GFDL documentation. Perhaps not everyone has. RFCs are definitely non-free because they're unmodifiable. They can't even be in contrib. [...] My point stands: it is a waste of everyone's time to repackage upstream source to remove insufficiently free stuff. This applies whether the item is non-modifiable, or non-rebuildable, or whatever. Obviously it has to be redistributable or we're not _allowed_ to distribute it, but removing incidental non-free stuff from source packages is a collossal waste of effort. Doing so does not advance freedom, because practically no-one is going to rely more on these files due to us not removing them from our tarballs, and no upstreams are going to be persuaded to remove them because of our zealous stance. It just uses up time which we could spend 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: http://lists.debian.org/19562.27602.910912.514...@chiark.greenend.org.uk
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Russ Allbery writes (Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)): Ian Jackson ijack...@chiark.greenend.org.uk writes: If you have this situation you have to have two separate source packages; one in main which builds only the free parts, and one in non-free which builds only the non-free parts. I don't believe this is correct. Source packages in main can build binaries in contrib, and I believe the problem with not being able to rebuild with free tools is more of a contrib thing than a non-free thing. Well, some maintainers have been rebuilding source packages to remove things like RFCs and non-free-GFDL documentation. Perhaps not everyone has. But I'm not certain, which is why I was hesitating to reply to the first message. It looks like there's confusion in this area. Perhaps policy could be clarified. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19561.8118.350610.700...@chiark.greenend.org.uk
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes: I don't believe this is correct. Source packages in main can build binaries in contrib, and I believe the problem with not being able to rebuild with free tools is more of a contrib thing than a non-free thing. Well, some maintainers have been rebuilding source packages to remove things like RFCs and non-free-GFDL documentation. Perhaps not everyone has. RFCs are definitely non-free because they're unmodifiable. They can't even be in contrib. What I'm not sure about is software that's freely modifiable but just requires non-free tools to build after modification. I know that's okay for contrib, and I know it's not okay for main in packages, but I wasn't sure if it was okay for main source packages if it's not installed in a main package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkwm5u0z@windlord.stanford.edu
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Aren't the licenses of source files generally documented by upstream, either by e.g. the COPYING file or inline within the files themselves? Why is there a requirement to duplicate this information in the copyright file? Thats certainly a nice dream, but in most cases not reality (having upstream document it sanely). In many cases upstream doesnt even know what they all have. -- bye, Joerg [...] some would argue that too much free beer with hamper your ability to free speech; this is an opinion. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaom1iug@gkar.ganneff.de
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Le jeudi 12 août 2010, Russ Allbery a écrit : I don't think anyone disagrees with this, including the ftp-masters. The question is whether the source package also needs a copyright file of its own. As we are distributing these files, it seems reasonable to document their licence. But the Policy is not clear about that requirement. Now, about compilation issue, for me, compiling a package means applying whatever rule is needed to produce the target binary package. In the case of a non-recompilable binary that gets stripped during this process, the “compilation” we apply to is is a deletion, that is done using tools from main. The problematic binary being only in the source package, I do not think it is relevant to oppose that “I cannot build the original tarball from source using free tools”, because the original tarball is not meant to be built from source, as it is the source. As I saw no opponent to such a solution, then I shall simply keep the binary Flash file and its source code on the original tarball, and strip them at build time. Let me see what happens next. -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
No. There is no sensible way to do this. The problem is inherent: the binary packages in main have to be rebuildable using the source package (and supporting binary packages eg compilers) in main. If you have this situation you have to have two separate source packages; one in main which builds only the free parts, and one in non-free which builds only the non-free parts. I don't believe this is correct. Source packages in main can build binaries in contrib, and I believe the problem with not being able to rebuild with free tools is more of a contrib thing than a non-free thing. But I'm not certain, which is why I was hesitating to reply to the first message. Yes, you can have a source in main building a package in contrib, provided the whole source and build process does only require main, and its just the execution part that needs non-main stuff. We have about one handful of packages in Debian doing this (yes, less than 5, IIRC). FTPMaster would love to get rid of this feature, as it does complicate some handlings a little, for nearly no gain. :) -- bye, Joerg buxy I wish mrvn stopped supporting 3.0 (quilt), it's a recipe for failure -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eie3vtts@gkar.ganneff.de
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
I don't think anyone disagrees with this, including the ftp-masters. The question is whether the source package also needs a copyright file of its own. As we are distributing these files, it seems reasonable to document their licence. But the Policy is not clear about that requirement. We distribute source and binary. So the copyright file has to document the contents of them all. Most commonly packages have exactly 1 of those files, copied everywhere. Then it has to document all, and the file ending up in binary packages will obviously document the source tarball too. Now, you can go and split the file, and have one per binary package seperated, as well as one documenting all of it once for the source. Besides that being a fair bit of useless extra work, for both you and ftpmaster, it seems pretty pointless to do, as the only thing that happens with just one file for all is slightly more text in the file as the binary may need. The problematic binary being only in the source package, I do not think it is relevant to oppose that “I cannot build the original tarball from source using free tools”, because the original tarball is not meant to be built from source, as it is the source. As I saw no opponent to such a solution, then I shall simply keep the binary Flash file and its source code on the original tarball, and strip them at build time. Let me see what happens next. As you do mention its license and stuff anyways (source distributing it), also state you remove that on build time. One little sentence keeping away possible confusion. -- bye, Joerg 20. What would you do if you wanted to retire from the project? Remove the passphrase from the (secret) gpg key and post it to debian-devel. The keyring maintainers will lock the account ASAP. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaorvtih@gkar.ganneff.de
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Ian Jackson ijack...@chiark.greenend.org.uk writes: Tanguy Ortolo writes (Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)): Let us say an upstream tarball contains such a non-recompilable binary as a minor component that can be stripped and maybe distributed by other means. The debian/rules will not compile it (it cannot), but if it does not even include it in the generated binary package, would such a package (both source and binary) ?not require a package outside of main for compilation or execution?? In other words, to be in main, does the maintainer have to strip the problematic file from the binary package, or does he have to repack the original tarball stripping it? The current approach of the project in these cases seems to be that the right thing to do is to rebuild the source package so that the non-free pieces are removed. Personally I think this is a complete waste of everyone's time; particularly, rebuilding upstream source archives is troublesome and doesn't really benefit anyone. Is it? My understanding was that as long as the upstream tarball is legaly distributable and the unneeded/unwanted parts in it aren't too big then the pristine tarball should be used as is. The clean target should then remove the extraneous files so they are not (accidentally) used during build, so that all binaries are build from fully DFSG free sources. I'd much rather you could just write in your .dsc a set of glob patterns for files to remove, somehow, which dpkg-source would remove when you unpacked it (unless you told it not to). That would prevent the non-free files from being accidentally used during the build process or shipped (eg when upstream Makefiles change), but would save a lot of work. It would also mean that the upstream tarball in our archive would be the real upstream tarball. I can see that there might be the objection that we were then distrubuting non-free stuff from our main archive section but given that our archive is almost entirely used by people using our tools, this is a small price worth paying for not obstructing our work on the free parts of the package. Obviously if the non-free parts are significant in size this doesn't apply. The benefit would be that we would no longer have to rebuild upstream source packages where upstream has helpfully included files such as RFCs (which we usually consider non-free) or other non-free stuff. Upstreams normally regard it as a convenience for people, to provide apocrypha etc. in their tarballs, and to be honest they're probably right. We are making a rod for our own back by our current practice of insisting on repackaging their tarballs. (I'm assuming that the non-recompilable binary is distributable. If it isn't then it can't be in our archive at all of course.) Which is the case for flash, isn't it? Same case, but with two binary packages generated, one with the main content, the other one with the problematic files appart: can the source file be in main? That case does not apply if all the packages associated to a single orig tarball must be in the same area. No. There is no sensible way to do this. The problem is inherent: the binary packages in main have to be rebuildable using the source package (and supporting binary packages eg compilers) in main. If you have this situation you have to have two separate source packages; one in main which builds only the free parts, and one in non-free which builds only the non-free parts. Ian. Actually you can have a source in main that builds binary packages for main and contrib. There are (or were) a few examples in Debian. But as you say the source in main must be buildable with just main. The case of non-recompilable binaries just doesn't fall into this category. The non-recompilable binary will never be DFSG free and has to go to non-free, not contrib, imho. Or it has to Build-Depend on something outside main to make the binaries recompilable and then the source can't be in main as it becomes unbuildable with just main. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwyi4xuy@frosties.localdomain
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Le vendredi 13 août 2010, Goswin von Brederlow a écrit : The case of non-recompilable binaries just doesn't fall into this category. The non-recompilable binary will never be DFSG free and has to go to non-free, not contrib, imho. Again, I think they can be DFSG-free, as the DFSG never mention the need for a free compilation chain. And this if it was not the case, according to the Policy §2.2.2: very package in contrib must comply with the DFSG. then all the software that requires stuff outside of main for building should be moved to non-free, according to the Policy §2.2.3: Packages must be placed in non-free if they are not compliant with the DFSG non-free is the only section that allows non-free software. In fact, if requirering non-free software for compilation or exectution makes something fail at the DFSG, then I do not see the point of the contrib section, as defined by the Policy §2.2.2: Examples of packages which would be included in contrib are: free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution… -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Joerg Jaspert jo...@debian.org writes: I don't think anyone disagrees with this, including the ftp-masters. The question is whether the source package also needs a copyright file of its own. As we are distributing these files, it seems reasonable to document their licence. But the Policy is not clear about that requirement. We distribute source and binary. So the copyright file has to document the contents of them all. Most commonly packages have exactly 1 of those files, copied everywhere. Then it has to document all, and the file ending up in binary packages will obviously document the source tarball too. Now, you can go and split the file, and have one per binary package seperated, as well as one documenting all of it once for the source. Besides that being a fair bit of useless extra work, for both you and ftpmaster, it seems pretty pointless to do, as the only thing that happens with just one file for all is slightly more text in the file as the binary may need. Aren't the licenses of source files generally documented by upstream, either by e.g. the COPYING file or inline within the files themselves? Why is there a requirement to duplicate this information in the copyright file? A binary package needs a copyright file because the copyright notices would otherwise be stripped out or obfuscated. That's not true for the source package though. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbiy4hbc@bignachos.net
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Le vendredi 13 août 2010, Goswin von Brederlow a écritâ¯: The case of non-recompilable binaries just doesn't fall into this category. The non-recompilable binary will never be DFSG free and has to go to non-free, not contrib, imho. Again, I think they can be DFSG-free, as the DFSG never mention the need for a free compilation chain. And this if it was not the case, according to the Policy §2.2.2: The source must be modifiable and for that to have any meaning the modified source must be compilable into a modified binary. If the DFSG isn't specific enough on that and common sense doesn't tell you that then maybe you could propose some wording for it. very package in contrib must comply with the DFSG. then all the software that requires stuff outside of main for building should be moved to non-free, according to the Policy §2.2.3: Requiring stuff outside of main for building is not the same as non-recompilable. The source is compilable (and is compiled during build) if you install the Build-Depends from outside of main. It just isn't compilable inside of main. I do see a difference there. Packages must be placed in non-free if they are not compliant with the DFSG non-free is the only section that allows non-free software. In fact, if requirering non-free software for compilation or exectution makes something fail at the DFSG, then I do not see the point of the contrib section, as defined by the Policy §2.2.2: Examples of packages which would be included in contrib are: free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution⦠-- Tanguy Ortolo Again, the difference between compilable with stuff outside of main and non-recompilable at all. Policy 2.2.2 allows contrib to Build-Depend on packages outside of main. It doesn't excempt them from the DFSG, which imho indirectly means compilable source. How does a source fullfill the DFSG if you can modify it but then can not compile it to get a modified binary? Who is to say the files claiming to be the source for some non-recompilable binary even is the source for that binary. Lets make the blanked claim that the source provided is not the source of the binary. Now prove me wrong. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq3etplg@frosties.localdomain
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Le vendredi 13 août 2010, Goswin von Brederlow a écrit : Requiring stuff outside of main for building is not the same as non-recompilable. The source is compilable (and is compiled during build) if you install the Build-Depends from outside of main. It just isn't compilable inside of main. I do see a difference there. Well, FLA files are compilable into SWF binaries. Using Adobe Flash, that is a software outside of main. It is a non-free software, not even free as in free beer. Is that the problem? Do you mean that the DFSG implicitely require that software must be compilable using tools that cost no money? -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Le vendredi 13 août 2010, Goswin von Brederlow a écritâ¯: Requiring stuff outside of main for building is not the same as non-recompilable. The source is compilable (and is compiled during build) if you install the Build-Depends from outside of main. It just isn't compilable inside of main. I do see a difference there. Well, FLA files are compilable into SWF binaries. Using Adobe Flash, that is a software outside of main. It is a non-free software, not even free as in free beer. Is that the problem? Do you mean that the DFSG implicitely require that software must be compilable using tools that cost no money? -- Tanguy Ortolo No. Policy says nothing about the tools needed to compile needing to be free as in beer. If you have the FLA files under a DFSG free license in the source and you Build-Depend on Adobe Flash and do compile them into the SWF binary during build then the package can be in contrib as I see it. It can't be in main because of that dependency on tools outside of main. On the other hand if you simply use a prebuild SWF binary supplied in the orig.tar.gz then the package belongs in non-free. Users won't be able to unpack the source, edit it, dpkg-buildpackage and get a modified binary and that I believe violates the spirit of the DFSG if not the letter. I don't think anything states specifically that you have to compile the source on every build but I believe that is essential for the simple reason of ensuring it can be done. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp96l1hp@frosties.localdomain
Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Hello, I know that there is a recent thread that talked about the status of non-recompilable binaries in packages, with the common particular case is Flash applets. As I understood it, the overall conclusion was: even if their licence is DFSG-free, according to the policy section 2.2, packages containing such binaries cannot go to main and, if distributed, must go to contrib. I agree with that, but I think the reality is more complex, as software can be built of several, partly independant bricks. Indeed, as a package can be a source package or a binary package, I wonder how this applies. First of all, as the control file allows to set the section both for the source package and for each binary package, can a source package be in a different area than one of the binary packages it generates? Let us say an upstream tarball contains such a non-recompilable binary as a minor component that can be stripped and maybe distributed by other means. The debian/rules will not compile it (it cannot), but if it does not even include it in the generated binary package, would such a package (both source and binary) “not require a package outside of main for compilation or execution”? In other words, to be in main, does the maintainer have to strip the problematic file from the binary package, or does he have to repack the original tarball stripping it? Same case, but with two binary packages generated, one with the main content, the other one with the problematic files appart: can the source file be in main? That case does not apply if all the packages associated to a single orig tarball must be in the same area. -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Tanguy Ortolo writes (Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)): Let us say an upstream tarball contains such a non-recompilable binary as a minor component that can be stripped and maybe distributed by other means. The debian/rules will not compile it (it cannot), but if it does not even include it in the generated binary package, would such a package (both source and binary) ?not require a package outside of main for compilation or execution?? In other words, to be in main, does the maintainer have to strip the problematic file from the binary package, or does he have to repack the original tarball stripping it? The current approach of the project in these cases seems to be that the right thing to do is to rebuild the source package so that the non-free pieces are removed. Personally I think this is a complete waste of everyone's time; particularly, rebuilding upstream source archives is troublesome and doesn't really benefit anyone. I'd much rather you could just write in your .dsc a set of glob patterns for files to remove, somehow, which dpkg-source would remove when you unpacked it (unless you told it not to). That would prevent the non-free files from being accidentally used during the build process or shipped (eg when upstream Makefiles change), but would save a lot of work. It would also mean that the upstream tarball in our archive would be the real upstream tarball. I can see that there might be the objection that we were then distrubuting non-free stuff from our main archive section but given that our archive is almost entirely used by people using our tools, this is a small price worth paying for not obstructing our work on the free parts of the package. Obviously if the non-free parts are significant in size this doesn't apply. The benefit would be that we would no longer have to rebuild upstream source packages where upstream has helpfully included files such as RFCs (which we usually consider non-free) or other non-free stuff. Upstreams normally regard it as a convenience for people, to provide apocrypha etc. in their tarballs, and to be honest they're probably right. We are making a rod for our own back by our current practice of insisting on repackaging their tarballs. (I'm assuming that the non-recompilable binary is distributable. If it isn't then it can't be in our archive at all of course.) Same case, but with two binary packages generated, one with the main content, the other one with the problematic files appart: can the source file be in main? That case does not apply if all the packages associated to a single orig tarball must be in the same area. No. There is no sensible way to do this. The problem is inherent: the binary packages in main have to be rebuildable using the source package (and supporting binary packages eg compilers) in main. If you have this situation you have to have two separate source packages; one in main which builds only the free parts, and one in non-free which builds only the non-free parts. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19556.14016.688915.420...@chiark.greenend.org.uk
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Le jeudi 12 août 2010, Ian Jackson a écrit : The current approach of the project in these cases seems to be that the right thing to do is to rebuild the source package so that the non-free pieces are removed. Non-free? According to the DFSG, are not they free? I cannot see any point of the DFSG that such a program, distributed both in source and compiled form, with a free license, compilable only with non-free tools, would infringe. I thought they were only failing one policy condition to be in the free area, but not the DFSG. As the policy section 2.2.2 says: Every package in contrib must comply with the DFSG. So if such a non-recompilable, free-licensed binary fails the DFSG, it should not even go to contrib, but to non-free! -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Ian Jackson ijack...@chiark.greenend.org.uk writes: No. There is no sensible way to do this. The problem is inherent: the binary packages in main have to be rebuildable using the source package (and supporting binary packages eg compilers) in main. If you have this situation you have to have two separate source packages; one in main which builds only the free parts, and one in non-free which builds only the non-free parts. I don't believe this is correct. Source packages in main can build binaries in contrib, and I believe the problem with not being able to rebuild with free tools is more of a contrib thing than a non-free thing. But I'm not certain, which is why I was hesitating to reply to the first message. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp97hdf5@windlord.stanford.edu
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
On Thu, 2010-08-12 at 20:31 +0200, Tanguy Ortolo wrote: Le jeudi 12 août 2010, Ian Jackson a écrit : The current approach of the project in these cases seems to be that the right thing to do is to rebuild the source package so that the non-free pieces are removed. Non-free? According to the DFSG, are not they free? I cannot see any point of the DFSG that such a program, distributed both in source and compiled form, with a free license, compilable only with non-free tools, would infringe. I thought they were only failing one policy condition to be in the free area, but not the DFSG. As the policy section 2.2.2 says: Every package in contrib must comply with the DFSG. So if such a non-recompilable, free-licensed binary fails the DFSG, it should not even go to contrib, but to non-free! Tanguy You may want to look at this thread http://lists.debian.org/debian-devel/2010/08/msg00082.html Best regards Charlie -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281639570.2772.27.ca...@debian
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
On to, 2010-08-12 at 20:31 +0200, Tanguy Ortolo wrote: Le jeudi 12 août 2010, Ian Jackson a écrit : The current approach of the project in these cases seems to be that the right thing to do is to rebuild the source package so that the non-free pieces are removed. Non-free? According to the DFSG, are not they free? I cannot see any point of the DFSG that such a program, distributed both in source and compiled form, with a free license, compilable only with non-free tools, would infringe. There's at least two requirements for software included in Debian main: a) the license must be free according to the DFSG b) all binaries in main must be built only from sources in main, using only tools in main If we don't have b), Debian is not self-sustaining: in order to build Debian we would have to have access to other systems, or software from outside of Debian. (Non-free being outside of Debian for the purpose of this paragraph.) Not being self-sustainable, in turn, means we are limited in how efficiently we can fix bugs, especially security bugs. Relying on tools package in Debian's non-free section might work, technically, depending on the exact (and possibly changing) details of the license. However, I doubt it's the kind of thing the project wants to rely on. To me, it sounds like you need to put your package into contrib, including its binary packages, until you can convince upstream to fix things so that they do not require non-free tools to build, or you convince the upstreams of the non-free tools to free their software. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281639220.2264.88.ca...@havelock
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Le jeudi 12 août 2010, Charlie Smotherman a écrit : On Thu, 2010-08-12 at 20:31 +0200, Tanguy Ortolo wrote: I thought they were only failing one policy condition to be in the free area, but not the DFSG. As the policy section 2.2.2 says: Every package in contrib must comply with the DFSG. So if such a non-recompilable, free-licensed binary fails the DFSG, it should not even go to contrib, but to non-free! You may want to look at this thread http://lists.debian.org/debian-devel/2010/08/msg00082.html I did. Especially to the message http://lists.debian.org/debian-devel/2010/08/msg00093.html. I am just a newbie, so I shall not risk myself to interpret the DFSG, but, if not being compilable with free tools is a DFSG failure, then, according to the policy section 2.2.2: Every package in contrib must comply with the DFSG. then, with no possible ambiguity, such tools should not go to contrib, but to non-free. Anyway, this is just pure curiosity, and I have time to discover that, as I am not facing this exact problem with any package, but a slightly different one: should I strip non-recompilable binaries only from the binary package or from the original tarball? -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Le vendredi 13 août 2010, Lars Wirzenius a écrit : On to, 2010-08-12 at 20:31 +0200, Tanguy Ortolo wrote: Non-free? According to the DFSG, are not they free? I cannot see any point of the DFSG that such a program, distributed both in source and compiled form, with a free license, compilable only with non-free tools, would infringe. There's at least two requirements for software included in Debian main: a) the license must be free according to the DFSG b) all binaries in main must be built only from sources in main, using only tools in main I do agree. This is from the policy. To me, it sounds like you need to put your package into contrib, including its binary packages, until you can convince upstream to fix things so that they do not require non-free tools to build, or you convince the upstreams of the non-free tools to free their software. I should rather strip the problematic file from the package, as it is only a minor component, that one can very well live without, and that is easy to install by other means. -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Le jeudi 12 août 2010, Ian Jackson a écrit : I'd much rather you could just write in your .dsc a set of glob patterns for files to remove, somehow, which dpkg-source would remove when you unpacked it (unless you told it not to). Is there a better way to achieve that than amnually editing the .dsc file after each package build? By the way, I did not find the documentation for the .dsc format, neither in the policy, nor in the reference, nor in dpkg-source(1)… -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Is there a better way to achieve that than amnually editing the .dsc file after each package build? By the way, I did not find the documentation for the .dsc format, neither in the policy, nor in the reference, nor in dpkg-source(1)… Policy 5.4. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrrvfvzt@windlord.stanford.edu
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Russ Allbery wrote: Tanguy Ortolo tanguy+deb...@ortolo.eu writes: I did not find the documentation for the .dsc format, neither in the policy, nor in the reference, nor in dpkg-source(1)… Policy 5.4. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles Thank you, I wonder how I could miss it. Ian Jackson wrote: I'd much rather you could just write in your .dsc a set of glob patterns for files to remove, somehow, which dpkg-source would remove when you unpacked it (unless you told it not to). Well, I see no .dsc field that would allow such a thing. dpkg-source has the options to ignore files when building a source package, but this is the closest match I found, but I have only used it for a couple of months, not developped it. :-) -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Ian Jackson wrote: I'd much rather you could just write in your .dsc a set of glob patterns for files to remove, somehow, which dpkg-source would remove when you unpacked it (unless you told it not to). Well, I see no .dsc field that would allow such a thing. dpkg-source has the options to ignore files when building a source package, but this is the closest match I found, but I have only used it for a couple of months, not developped it. :-) I think Ian was saying that he'd like dpkg-source to add that feature, not that it already existsed today and was something you could use. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq3ffup9@windlord.stanford.edu
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
I would like to narrow the discussion to my specific problem, as I have to make a decision to solve it. The dokuwiki upstream tarball contains a Flash applet, in both source and binary form. Only a proprietary tool can generate the binary from the source. This applet is only a minor component, that can be stripped without impacting the overall functionnality of the software. Rather than keeping that file, moving dokuwiki to contrib, I would rather strip it, document that, and explain how to install it manually if needed. My question is: should I strip it from the original tarball, repacking it, or only from the binary package? Technically, I prefer the latter solution. I think that this solution, stripping it only from the binary package, is acceptable according to the Debian Policy. Here are the arguments I identified agains that: 1. Policy §2.2.1 requires every package in main to compy with the DFSG, and DFSG §3 requires to allow the recipient to modify and rebuild. 2. Policy §2.2.1 forbids any package in main to require a package outside of main for compilation or execution. Let me detail these arguments, and why I think they do not apply. 1. DFSG §3 is written as follows: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Well, first, this point does not require a free toolchain, as it does not include a proposition such as: “by using only software that follow these Guidelines”. Plus, it only speaks of the license, not about facts outside of the licence that could forbid the compilation or the execution, like: the user does not have a computer, does not have the compiler, has an incompatible processor, etc. And here, the licence of that Flash applet does allow modifications. 2. Policy §2.2.1 is about packages. A source package containing some non-compilable-with-software-in-main code, but which rules do not make use of that code, neither by compiling it, nor by copying it to the binary package (that is, rules that /strip/ that code) needs, no package outside of main for compilation or execution. As I said, I am not very experienced with the DFSG and the Policy, so I may be wrong, and I may miss some arguments. I told that I would not risk myself to try and interpret these fundamental texts: in fact, I did so, and I think it may be a good exercice. I just have a problem to solve, and I wish to avoid an original tarball repacking if I can. -- Tanguy Ortolo signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
[Tanguy Ortolo] 2. Policy §2.2.1 is about packages. A source package containing some non-compilable-with-software-in-main code, but which rules do not make use of that code, neither by compiling it, nor by copying it to the binary package (that is, rules that /strip/ that code) needs, no package outside of main for compilation or execution. I am inclined to agree with you. This in fact reminds me of the issue Steve Langasek brought up two years ago: http://lists.debian.org/debian-project/2008/07/msg00017.html wherein he complains that the ftpmasters were requiring him to document licenses for things not shipped in binary packages, in the copyright file. I agreed with Steve at the time, that files not shipped in a .deb need not be documented in /usr/share/doc/foo/copyright shipped in the .deb; and I agree with you now, that files not shipped in a .deb need not be subject to our rule about self-hosted building. Of course they are still subject to the DFSG. As a service to the user, of course it's still helpful to document in the source package why you aren't building or shipping the .swf file. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100812225043.gi3...@p12n.org
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
On Thu Aug 12 11:51, Russ Allbery wrote: No. There is no sensible way to do this. The problem is inherent: the binary packages in main have to be rebuildable using the source package (and supporting binary packages eg compilers) in main. If you have this situation you have to have two separate source packages; one in main which builds only the free parts, and one in non-free which builds only the non-free parts. I don't believe this is correct. Source packages in main can build binaries in contrib, and I believe the problem with not being able to rebuild with free tools is more of a contrib thing than a non-free thing. But I'm not certain, which is why I was hesitating to reply to the first message. I think the difference here is between components which require non-(free/debian) components to build and non-(free/debian) components to run. It seems consistent, at least, that if you can build with only free tools then the source package can be in main. If you can run with only free tools then the binary package can be in main (although, of course, if you can build with non-free tools but run with free tools, you still have to be in contrib). If, as is the case here, the building can't be done in main, then it has to be in contrib. Matt signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
On 12/08/10 16:21, Russ Allbery wrote: Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Ian Jackson wrote: I'd much rather you could just write in your .dsc a set of glob patterns for files to remove, somehow, which dpkg-source would remove when you unpacked it (unless you told it not to). Well, I see no .dsc field that would allow such a thing. dpkg-source has the options to ignore files when building a source package, but this is the closest match I found, but I have only used it for a couple of months, not developped it. :-) I think Ian was saying that he'd like dpkg-source to add that feature, not that it already existsed today and was something you could use. CDBS currently has get-orig-source rule which does that. You just define a variable with a space separated list of globs and it excludes them when fetching the source from the web. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
On Thu, 12 Aug 2010, Peter Samuelson wrote: [Tanguy Ortolo] 2. Policy §2.2.1 is about packages. A source package containing some non-compilable-with-software-in-main code, but which rules do not make use of that code, neither by compiling it, nor by copying it to the binary package (that is, rules that /strip/ that code) needs, no package outside of main for compilation or execution. I agreed with Steve at the time, that files not shipped in a .deb need not be documented in /usr/share/doc/foo/copyright shipped in the .deb; and I agree with you now, that files not shipped in a .deb need not be subject to our rule about self-hosted building. Of course they are still subject to the DFSG. My understanding is that for those (programmatic?) works, source code must be provided, and we certainly shouldn't be shipping them in the binary part of the distribution if we cannot build them from that source. Assuming the source is present, we should just blow them away in the clean rule to be sure that they aren't shipped by accident. If the source isn't provided, we have to either provide it, or not ship it in the source package. Personally, I view that including things that don't get shipped or used in an upstream source package is a minor bug that should be fixed upstream. [With possible increase in severity if the useless bits are large.] Don Armstrong -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100813000145.gx31...@rzlab.ucr.edu
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Felipe Sateler fsate...@debian.org writes: On 12/08/10 16:21, Russ Allbery wrote: Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Ian Jackson wrote: I'd much rather you could just write in your .dsc a set of glob patterns for files to remove, somehow, which dpkg-source would remove when you unpacked it (unless you told it not to). Well, I see no .dsc field that would allow such a thing. dpkg-source has the options to ignore files when building a source package, but this is the closest match I found, but I have only used it for a couple of months, not developped it. :-) I think Ian was saying that he'd like dpkg-source to add that feature, not that it already existsed today and was something you could use. CDBS currently has get-orig-source rule which does that. You just define a variable with a space separated list of globs and it excludes them when fetching the source from the web. I believe that's implemented by repacking the upstream source to omit those files from the *.orig.tar.gz, which is exactly what Ian doesn't want people to have to do. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrrvbc0u@windlord.stanford.edu
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Peter Samuelson pe...@p12n.org writes: I agreed with Steve at the time, that files not shipped in a .deb need not be documented in /usr/share/doc/foo/copyright shipped in the .deb; I don't think anyone disagrees with this, including the ftp-masters. The question is whether the source package also needs a copyright file of its own. In other words, if you created both debian/copyright and debian/binary-package.copyright, where the latter contains only information about what's in the binary package and is installed in that binary package, I highly doubt ftp-master will complain. However, they currently still rely on debian/copyright documenting the entire source package for the purposes of license review. I think we need a broader discussion following the Policy process to work out and reach consensus on exactly what copyright documentation we, as a project, want to require in our packages, both source and binary. We keep having one-off, ad-hoc discussions without all the involved parties participating, which is a large part of why we don't reach consensus. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk2jbbuo@windlord.stanford.edu
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
On 12/08/10 20:18, Russ Allbery wrote: Felipe Sateler fsate...@debian.org writes: On 12/08/10 16:21, Russ Allbery wrote: Tanguy Ortolo tanguy+deb...@ortolo.eu writes: Ian Jackson wrote: I'd much rather you could just write in your .dsc a set of glob patterns for files to remove, somehow, which dpkg-source would remove when you unpacked it (unless you told it not to). Well, I see no .dsc field that would allow such a thing. dpkg-source has the options to ignore files when building a source package, but this is the closest match I found, but I have only used it for a couple of months, not developped it. :-) I think Ian was saying that he'd like dpkg-source to add that feature, not that it already existsed today and was something you could use. CDBS currently has get-orig-source rule which does that. You just define a variable with a space separated list of globs and it excludes them when fetching the source from the web. I believe that's implemented by repacking the upstream source to omit those files from the *.orig.tar.gz, which is exactly what Ian doesn't want people to have to do. As I understood it, Ian doesn't want people to waste time on it. Filling a glob on the .dsc is the same work as putting the same glob in debian/rules. While it is a bit more cumbersome to override than his proposed method, it can still be easily done. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
