Russ Allbery writes ("Re: Non-recompilable binaries in source and binary
packages (Adobe Flash strikes again)"):
>Ian Jackson writes:
>>Well, some maintainers have been rebuilding source packages to remove
>>things like RFCs and non-free-GFDL documentation. Perhaps not
> 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
u
Ian Jackson 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
Russ Allbery writes ("Re: Non-recompilable binaries in source and binary
packages (Adobe Flash strikes again)"):
> Ian Jackson writes:
> > If you have this situation you have to have two separate source
> > packages; one in main which builds only the free parts, and
Tanguy Ortolo 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
>>
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.
Tanguy Ortolo 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 b
Joerg Jaspert 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
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 menti
Ian Jackson 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 d
>> 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 requiremen
>> 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 ma
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 Po
On 12/08/10 20:18, Russ Allbery wrote:
> Felipe Sateler writes:
>> On 12/08/10 16:21, Russ Allbery wrote:
>>> Tanguy Ortolo 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 wou
Peter Samuelson 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
Felipe Sateler writes:
> On 12/08/10 16:21, Russ Allbery wrote:
>> Tanguy Ortolo 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
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 packag
On 12/08/10 16:21, Russ Allbery wrote:
> Tanguy Ortolo 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,
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 h
[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 p
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, tha
Tanguy Ortolo 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
Russ Allbery wrote:
> Tanguy Ortolo 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 wond
Tanguy Ortolo 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.o
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
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, compila
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 DF
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? Accor
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? Acco
Ian Jackson 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
> pac
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
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 de
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 co
33 matches
Mail list logo
