Re: Built-Using usage question

2017-12-31 Thread Russ Allbery
kage needs a copy of that license. > Do you think it's possible to apply some sort of automated solution to > the problem? I could think of a "built-using" support in debhelper that > will not only add the built-using header but also copy the (complete) > copyright file from t

Re: Built-Using usage question

2017-12-31 Thread Lukas Schwaighofer
Hi, On Sat, 30 Dec 2017 19:42:01 -0800 Russ Allbery <r...@debian.org> wrote: > I don't think you need to change anything about Built-Using. That > seems like exactly the sort of reason anticipated by DFSG > compliance. The clarification in Policy is because the previous >

Re: Built-Using usage question

2017-12-30 Thread Russ Allbery
Paul Wise <p...@debian.org> writes: > Personally, I feel this change to policy is a mistake. Alternative proposals that achieve the goal of not adding Built-Using fields to the entire archive are welcome. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

Re: Built-Using usage question

2017-12-30 Thread Russ Allbery
]”) I need to keep using the Built-Using control field. > Especially since it's conceivable that a new version of gnu-efi breaks > compatibility with some specific efi implementation. However, on a > technical level, I don't really see the difference between my case and > linking

Re: Built-Using usage question

2017-12-30 Thread Paul Wise
On Sat, Dec 30, 2017 at 10:49 PM, Lukas Schwaighofer wrote: > I read the update in policy 4.1.3 and I'm not sure how to handle the > change / clarification of the Built-Using control field for the > syslinux package (which I maintain in the debian-cd team). I suggest you ask this

Built-Using usage question

2017-12-30 Thread Lukas Schwaighofer
Hi mentors, I read the update in policy 4.1.3 and I'm not sure how to handle the change / clarification of the Built-Using control field for the syslinux package (which I maintain in the debian-cd team). I have two questions: The syslinux-efi binary package contains parts of the gnu-efi package

Re: Built-Using:

2016-09-04 Thread Jakub Wilk
* Paul Wise <p...@debian.org>, 2016-09-04, 09:46: As I understand Policy, Built-Using: should mention any packages, parts of which were incorporated into binary package, including any debhelper, that insert shell snippets into maintainer scripts, flex/bison. There is some controversy

Re: Built-Using:

2016-09-03 Thread Paul Wise
On Sun, Sep 4, 2016 at 2:02 AM, Dmitry Bogatov wrote: > As I understand Policy, Built-Using: should mention any packages, parts > of which were incorporated into binary package, including any debhelper, that > insert shell snippets into maintainer scripts, flex/bison. There is some co

Built-Using:

2016-09-03 Thread Dmitry Bogatov
Hello! As I understand Policy, Built-Using: should mention any packages, parts of which were incorporated into binary package, including any debhelper, that insert shell snippets into maintainer scripts, flex/bison. Which debhelper is used to create this field, and isn't it is superseeded

Re: Built-Using field

2015-10-25 Thread Giovani Ferreira
Hi! On 21-10-2015 18:02, Santiago Vila wrote: > > See the mp4h package currently in testing for an example. Apart from the example of mp4h also found in the bash package. The bash was specific glibc. Thanks for your help. cheers -- Giovani Ferreira http://softwarelivre.org/jova2 GNU/Linux

Re: Built-Using field

2015-10-21 Thread Santiago Vila
On Tue, Oct 20, 2015 at 11:05:11PM -0200, Giovani Ferreira wrote: > I'll update the unhide package and I need help. > The package has a serious bug #769345, which is about statically-linked > glibc. According to the bug and Debian policy 7.8 is required the > Built-Using field in d/co

Built-Using field

2015-10-20 Thread Giovani Ferreira
Hello mentors, I'll update the unhide package and I need help. The package has a serious bug #769345, which is about statically-linked glibc. According to the bug and Debian policy 7.8 is required the Built-Using field in d/control. How should I make this reference? Another thing, the package