Re: definition of contrib & buildd inconsistency
Carlo Segre writes: > On Mon, 22 Mar 2010, Marc 'HE' Brockschmidt wrote: >> We are currently reworking the non-free support in the buildd >> network. In the long term, we want to be able to build whitelisted >> packages, and allow contrib packages to use binaries built from >> whitelisted package. This is not done yet, but people (more >> specifically, Andreas Barth) are working on it. > Thanks for the information. Do you have any notion about when this > might be completed? No, sorry. Marc -- BOFH #310: asynchronous inode failure pgpAZ3rDSkaGh.pgp Description: PGP signature
Re: definition of contrib & buildd inconsistency
Hi Marc: On Mon, 22 Mar 2010, Marc 'HE' Brockschmidt wrote: Carlo Segre writes: An alternative which would remove the inconsistency is to make the decision that contrib packages will not be built by the officeial buildd network but have to be built as non-free packages are, on the unofficial buildd network. If my understanding is current, non-free packages are autobuilt only as a result of explicit whitelisting indicating that there are no license problems resulting from doing so. I think the same would have to be true of contrib packages, since even *installing* packages from non-free could have license implications that impact the buildd operators. OK, in my case pgplot5 has been whitelisted for many years. Is it possible to have these contrib packages whitelisted on the non-free buildd network too? We are currently reworking the non-free support in the buildd network. In the long term, we want to be able to build whitelisted packages, and allow contrib packages to use binaries built from whitelisted package. This is not done yet, but people (more specifically, Andreas Barth) are working on it. Thanks for the information. Do you have any notion about when this might be completed? I am not trying to be pushy, I just want to be able to make an informed decision about what to do with my packages for squeeze. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Graduate Admissions, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://www.iit.edu/~segre se...@debian.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/alpine.deb.2.00.1003220724580.3...@oxide.phys.iit.edu
Re: definition of contrib & buildd inconsistency
Carlo Segre writes: >>> An alternative which would remove the inconsistency is to make the >>> decision that contrib packages will not be built by the officeial >>> buildd network but have to be built as non-free packages are, on the >>> unofficial buildd network. >> If my understanding is current, non-free packages are autobuilt only as a >> result of explicit whitelisting indicating that there are no license >> problems resulting from doing so. I think the same would have to be true of >> contrib packages, since even *installing* packages from non-free could have >> license implications that impact the buildd operators. > OK, in my case pgplot5 has been whitelisted for many years. Is it > possible to have these contrib packages whitelisted on the non-free > buildd network too? We are currently reworking the non-free support in the buildd network. In the long term, we want to be able to build whitelisted packages, and allow contrib packages to use binaries built from whitelisted package. This is not done yet, but people (more specifically, Andreas Barth) are working on it. Marc -- Fachbegriffe der Informatik - Einfach erklärt 255: City Die Gegend mit der höchsten Kneipendichte und den wenigsten Parkplätzen. (Juergen Nieveler) pgpCJ7Nt0Yhe1.pgp Description: PGP signature
Re: definition of contrib & buildd inconsistency
On Sun, 21 Mar 2010, Steve Langasek wrote: On Sun, Mar 21, 2010 at 04:37:25PM -0500, Carlo Segre wrote: * free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, There is apparently an ambiguity here since a contrib package can depend on non-free in two distinct ways: No, there isn't. "for compilation or execution" - so if it depends on packages not in main at build time *or* at run time. You are correct, I missed that. It's possible that most maintainers when confronted with this have simply opted to move their packages directly to non-free in order to get autobuilder support. There are only five packages in contrib currently affected by this problem (out of 74 total that build architecture-dependent packages): ifeffit and libpgplot-perl, which b-d on pgplot5; r-cran-surveillance, which b-d on r-cran-maptools; snes9express, which b-d on snes9x-x; and suitesparse-metis, which b-d on libparmetis-dev. Yes, two of these are my packages and when I initially uploaded them, I followed the letter of the Policy which makes them contrib not non-free. I have no choice now but to move them both to non-free, however, my attempt to do this has been rejected by ftpmaster. I am not sure how to proceed at this point. An alternative which would remove the inconsistency is to make the decision that contrib packages will not be built by the officeial buildd network but have to be built as non-free packages are, on the unofficial buildd network. If my understanding is current, non-free packages are autobuilt only as a result of explicit whitelisting indicating that there are no license problems resulting from doing so. I think the same would have to be true of contrib packages, since even *installing* packages from non-free could have license implications that impact the buildd operators. OK, in my case pgplot5 has been whitelisted for many years. Is it possible to have these contrib packages whitelisted on the non-free buildd network too? -- Carlo U. Segre -- Professor of Physics Associate Dean for Graduate Admissions, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://www.iit.edu/~segre se...@debian.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/alpine.deb.2.00.1003212230570.3...@hydride.iit.edu
Re: definition of contrib & buildd inconsistency
On Sun, Mar 21, 2010 at 04:37:25PM -0500, Carlo Segre wrote: > Hello All: > The definition of the contrib section of the archive reads [0] > 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, > There is apparently an ambiguity here since a contrib package can > depend on non-free in two distinct ways: No, there isn't. "for compilation or execution" - so if it depends on packages not in main at build time *or* at run time. > Which is the correct interpretation? If both are included, then all > buildds MUST include non-free sources. There is no such requirement. The buildd network has never assumed responsibility for building packages which build-depend on non-free packages. It's possible that most maintainers when confronted with this have simply opted to move their packages directly to non-free in order to get autobuilder support. There are only five packages in contrib currently affected by this problem (out of 74 total that build architecture-dependent packages): ifeffit and libpgplot-perl, which b-d on pgplot5; r-cran-surveillance, which b-d on r-cran-maptools; snes9express, which b-d on snes9x-x; and suitesparse-metis, which b-d on libparmetis-dev. (Two other packages have build-dependencies that are satisfied by main+contrib; and one other package has build-dependencies that aren't satisfied even with non-free.) > An alternative which would remove the inconsistency is to make the > decision that contrib packages will not be built by the officeial > buildd network but have to be built as non-free packages are, on the > unofficial buildd network. If my understanding is current, non-free packages are autobuilt only as a result of explicit whitelisting indicating that there are no license problems resulting from doing so. I think the same would have to be true of contrib packages, since even *installing* packages from non-free could have license implications that impact the buildd operators. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
definition of contrib & buildd inconsistency
Hello All: The definition of the contrib section of the archive reads [0] 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, There is apparently an ambiguity here since a contrib package can depend on non-free in two distinct ways: 1. depends only at runtime, for example a non-free Perl or Python module. 2. depends at build time and runtime, for example a package which needs non-free libraries to be built and linked to. Which is the correct interpretation? If both are included, then all buildds MUST include non-free sources. This is not currently the case. If only 1 is included in the definition for contrib, then any package which falls in category 2 MUST be moved to non-free. Personally, I have no preference as to the interpretation but the current state, where some of the buildds do not include non-free sources and contrib packages can fall under both the categories listed above is inconsistent and needs to be resolved. An alternative which would remove the inconsistency is to make the decision that contrib packages will not be built by the officeial buildd network but have to be built as non-free packages are, on the unofficial buildd network. Cheers, Carlo [0] section 2.2.2 of http://www.debian.org/doc/debian-policy/ch-archive.html -- Carlo U. Segre -- Professor of Physics Associate Dean for Graduate Admissions, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://www.iit.edu/~segre se...@debian.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/alpine.deb.2.00.1003211606470.3...@hydride.iit.edu
