Hi,
2009/11/2 Mark Hymers mhy@debian.org:
On Mon, 02, Nov, 2009 at 12:43:42PM +0000, Philipp Kern spoke thus..
Of course it is a sane approach but very special care needs to be taken when releasing to ensure GPL compliance. So what we should get is support in the toolchain to declare against what source package the upload was built to keep that around.
We haven't implemented that yet for the archive software but it's on the TODO list (and not that difficult). None of us have had time to do the d-d-a post from the ftpteam meeting yet, but I'll make sure information is in there about it.
I'm hoping to the archive-side support done in the next week or so.
Squeeze has already been released, cross toolchains were not released along Debian main, but found at Emdebian repository.
Marcin Juszkiewicz has been working out cross compiler packages for armel as part of his work for Linaro, which I attempt to include into Debian main archive. As a result of the work done, linux-armel, binutils-armel, eglibc-armel are merged into a single source package named `cross-toolchain-base', the package is not optimal, but once we got multiarch support, it should be renamed to `binutils-armel' (or similar name) and use linux and eglibc libraries and headers provided by multiarch.
Along this package I also plan to upload `gcc-4.5-cross' (#590465).
At the moment we are targeting one target architecture on two build hosts ('{amd64,i386}->armel'), not sure if it is desired to be supported on more build hosts. Target architecture support might grow up in future, but right now it is not a priority.
Not sure if that is an issue for someone? Comments?
Best regards,
On Mon, Mar 14, 2011 at 02:04:30PM +0000, Hector Oron wrote:
the package is not optimal, but once we got multiarch support, it should be renamed to `binutils-armel' (or similar name) and use linux and eglibc libraries and headers provided by multiarch.
Please note that building such a package in the archive not only requires that multiarch is implemented, it also requires that the buildds be enabled to support installing packages of the foreign architecture to satisfy build dependencies. We haven't even begun to have an earnest discussion with the ftpmasters, release team, and buildd team about what a policy for this would need to look like - currently the policy remains the existing one, that all build-dependencies must be satisfied by the current architecture.
Cheers,
On Mon, 14, Mar, 2011 at 02:04:30PM +0000, Hector Oron spoke thus..
Hi,
2009/11/2 Mark Hymers mhy@debian.org:
On Mon, 02, Nov, 2009 at 12:43:42PM +0000, Philipp Kern spoke thus..
Of course it is a sane approach but very special care needs to be taken when releasing to ensure GPL compliance. So what we should get is support in the toolchain to declare against what source package the upload was built to keep that around.
Ok, I'm only going to comment on this part. This is nearly implemented and should be there by the end of the day (I need to run up some test packages to work with).
The current design is the Binary packages can contain an additional control field: Built-Using.
The specification of this field is that it *must* contain only strict version dependencies and these must be to source packages. I.e.
Built-Using: gcc-4.5 (= 4.5.2-5)
If dak can't parse this field, or the source versions which are declared are not present when the binary package is uploaded, it will reject the upload. If it can parse and find these dependencies, it stores them in an extra table in projectb which prevents us from throwing away the relevant source files until these binaries no longer exist anywhere in the archive, the same way as we handle it for the normal source case.
I'm not entirely sure where this should be documented, it's not really a policy thing as it's specific to the archive. Suggestions welcome. We'll obviously include it in the minutes to d-d-a at the end of the meeting (the main people this should be used by, as far as I know are cross-compiler builders and the d-i and kernel-wedge people).
Mark
On 22.03.2011 12:54, Mark Hymers wrote:
On Mon, 14, Mar, 2011 at 02:04:30PM +0000, Hector Oron spoke thus..
Hi,
2009/11/2 Mark Hymers mhy@debian.org:
On Mon, 02, Nov, 2009 at 12:43:42PM +0000, Philipp Kern spoke thus..
Of course it is a sane approach but very special care needs to be taken when releasing to ensure GPL compliance. So what we should get is support in the toolchain to declare against what source package the upload was built to keep that around.
Ok, I'm only going to comment on this part. This is nearly implemented and should be there by the end of the day (I need to run up some test packages to work with).
The current design is the Binary packages can contain an additional control field: Built-Using.
The specification of this field is that it *must* contain only strict version dependencies and these must be to source packages. I.e.
Built-Using: gcc-4.5 (= 4.5.2-5)
If dak can't parse this field, or the source versions which are declared are not present when the binary package is uploaded, it will reject the upload. If it can parse and find these dependencies, it stores them in an extra table in projectb which prevents us from throwing away the relevant source files until these binaries no longer exist anywhere in the archive, the same way as we handle it for the normal source case.
I'm not entirely sure where this should be documented, it's not really a policy thing as it's specific to the archive. Suggestions welcome. We'll obviously include it in the minutes to d-d-a at the end of the meeting (the main people this should be used by, as far as I know are cross-compiler builders and the d-i and kernel-wedge people).
that would be too strict for e.g. gcj-4.5
Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3)
would be correct, however this already can be expressed in the build dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need to be changed.
Matthias
On Tue, 22, Mar, 2011 at 01:51:00PM +0100, Matthias Klose spoke thus..
that would be too strict for e.g. gcj-4.5
Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3)
would be correct, however this already can be expressed in the build dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need to be changed.
This is nothing to do with Build-Depends. This is simply informing the archive what *happened* during the build. The obvious case is when someone Build-Depends on gcc-4.5-source (a binary package), they should then tell us in the control file of their Binary packages that they used gcc-4.5 (the source package) and the exact version they used. This means that we'll ensure that we hold that version of the source around correctly until we no longer need it. It has no effect on the end-user's system, it simply allows us to automatically ensure GPL compliance (and means we're doing the right thing)
Mark
On 2011-03-22, Matthias Klose doko@debian.org wrote:
The current design is the Binary packages can contain an additional
^^^^^^
control field: Built-Using.
[...]
that would be too strict for e.g. gcj-4.5 Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) would be correct, however this already can be expressed in the build dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need to be changed.
They'd need to *generate* them in the *binary* packages. So you "just" declare the one that was installed at the time of building and you're set.
Kind regards Philipp Kern
On 22.03.2011 14:20, Philipp Kern wrote:
On 2011-03-22, Matthias Klose doko@debian.org wrote:
The current design is the Binary packages can contain an additional
^^^^^^control field: Built-Using.
[...]
that would be too strict for e.g. gcj-4.5 Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) would be correct, however this already can be expressed in the build dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need to be changed.
They'd need to *generate* them in the *binary* packages. So you "just" declare the one that was installed at the time of building and you're set.
no, they are not needed at all for these packages.
On Tue, Mar 22, 2011 at 14:33:09 +0100, Matthias Klose wrote:
On 22.03.2011 14:20, Philipp Kern wrote:
On 2011-03-22, Matthias Klose doko@debian.org wrote:
The current design is the Binary packages can contain an additional
^^^^^^control field: Built-Using.
[...]
that would be too strict for e.g. gcj-4.5 Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) would be correct, however this already can be expressed in the build dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need to be changed.
They'd need to *generate* them in the *binary* packages. So you "just" declare the one that was installed at the time of building and you're set.
no, they are not needed at all for these packages.
If that's not needed for those packages then why bring them up?
Cheers, Julien
Hi Mark,
2011/3/22 Mark Hymers mhy@debian.org:
The current design is the Binary packages can contain an additional control field: Built-Using.
First of all, thanks very much for taking care of it, that probably will get us going.
I just would like to point out that current design solves half of the problem (being GPL compliant), but it does not solve code duplication in the archive, which it can also be useful for large datasets. IMHO, we do not want source and binary packages containing the same bits, bytes and nibbles, problem which might be solved by the multiarch specification, treating 'source' as yet another architecture (in next couple years?) :-)
Best regards,
On Tue, 22, Mar, 2011 at 01:57:42PM +0000, Hector Oron spoke thus..
Hi Mark,
2011/3/22 Mark Hymers mhy@debian.org:
The current design is the Binary packages can contain an additional control field: Built-Using.
First of all, thanks very much for taking care of it, that probably will get us going.
I just would like to point out that current design solves half of the problem (being GPL compliant), but it does not solve code duplication in the archive, which it can also be useful for large datasets. IMHO, we do not want source and binary packages containing the same bits, bytes and nibbles, problem which might be solved by the multiarch specification, treating 'source' as yet another architecture (in next couple years?) :-)
I'd have thought the right answer to that was to allow some form of Build-Depends-Source mechanism where the source is unpacked at build time in a known place or something. Of course, the problem with this is that we traditionally haven't allowed network access to be required during a build so the exact semantics would have to be worked out. Maybe something like, if a package declares Build-Depends-Source: gcc-4.5 the source code must be available under debian/external-source/gcc-4.5 and then leave it up to the builder to sort that out. That's a rough (and probably bad) idea off the top of my head - I'm sure the buildd team at least will have other thoughts on the matter.
Mark
Mark Hymers mhy@debian.org writes:
On Tue, 22, Mar, 2011 at 01:57:42PM +0000, Hector Oron spoke thus..
Hi Mark,
2011/3/22 Mark Hymers mhy@debian.org:
The current design is the Binary packages can contain an additional control field: Built-Using.
First of all, thanks very much for taking care of it, that probably will get us going.
I just would like to point out that current design solves half of the problem (being GPL compliant), but it does not solve code duplication in the archive, which it can also be useful for large datasets. IMHO, we do not want source and binary packages containing the same bits, bytes and nibbles, problem which might be solved by the multiarch specification, treating 'source' as yet another architecture (in next couple years?) :-)
I'd have thought the right answer to that was to allow some form of Build-Depends-Source mechanism where the source is unpacked at build time in a known place or something. Of course, the problem with this is that we traditionally haven't allowed network access to be required during a build so the exact semantics would have to be worked out. Maybe something like, if a package declares Build-Depends-Source: gcc-4.5 the source code must be available under debian/external-source/gcc-4.5 and then leave it up to the builder to sort that out. That's a rough (and probably bad) idea off the top of my head - I'm sure the buildd team at least will have other thoughts on the matter.
Mark
Using the multiarch syntax this could be folded into Build-Depends:
Build-Depends: gcc-4.5:src
That would then cause the gcc-4.5 source to be unpacked to /usr/src/gcc-4.5/ (I would guess) as part of the installation of Build-Depends done by sbuild or pbuilder or whatever tool you use. There would be no special network access required during the build other than what is already in use for installing Build-Depends in general prior to a build.
What this really comes down to is patching dpkg / apt / aptitude so they can "install" sources and sbuild / wanna-build / quinn-diff to cope with the syntax.
MfG Goswin
The current design is the Binary packages can contain an additional control field: Built-Using.
First of all, thanks very much for taking care of it, that probably will get us going.
I just would like to point out that current design solves half of the problem (being GPL compliant),
No, it solves all of the problem, cos ....
but it does not solve code duplication in the archive,
this is a different thing entirely. B-U is solely mean of ensuring to do what the licenses want us to do. Getting sanity into packages providing source around and duplication is different to that.
Mark Hymers mhy@debian.org writes:
On Mon, 14, Mar, 2011 at 02:04:30PM +0000, Hector Oron spoke thus..
Hi,
2009/11/2 Mark Hymers mhy@debian.org:
On Mon, 02, Nov, 2009 at 12:43:42PM +0000, Philipp Kern spoke thus..
Of course it is a sane approach but very special care needs to be taken when releasing to ensure GPL compliance. Â So what we should get is support in the toolchain to declare against what source package the upload was built to keep that around.
Ok, I'm only going to comment on this part. This is nearly implemented and should be there by the end of the day (I need to run up some test packages to work with).
The current design is the Binary packages can contain an additional control field: Built-Using.
The specification of this field is that it *must* contain only strict version dependencies and these must be to source packages. I.e.
Built-Using: gcc-4.5 (= 4.5.2-5)
So ia32-libs could contain
Built-using: acl (= 2.2.49-4), ... 112 more entries
and drop the source copies (75% of the source package)?
It isn't exactly "using" the packages to build but it contains copies of the prebuild debs of those versions. The GPL requirement for the source to exist is the same though.
If dak can't parse this field, or the source versions which are declared are not present when the binary package is uploaded, it will reject the upload. If it can parse and find these dependencies, it stores them in an extra table in projectb which prevents us from throwing away the relevant source files until these binaries no longer exist anywhere in the archive, the same way as we handle it for the normal source case.
What exactly means "not present"? The ia32-libs packages are curently build against testing. Would an upload to unstable be allowed with a Built-Using string listing versions only in testing?
Also does the testing transition consider the Built-Using? If I specify 'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5 (= 4.5.2-5) from being replaced from testing?
I'm not entirely sure where this should be documented, it's not really a policy thing as it's specific to the archive. Suggestions welcome. We'll obviously include it in the minutes to d-d-a at the end of the meeting (the main people this should be used by, as far as I know are cross-compiler builders and the d-i and kernel-wedge people).
Mark
MfG Goswin
linaro-toolchain@lists.linaro.org
-
Goswin von Brederlow -
Hector Oron -
Joerg Jaspert -
Julien Cristau -
Mark Hymers -
Matthias Klose -
Philipp Kern -
Steve Langasek