Pkg xen devel - Feb 2006 - Debian revisions and policy comments [signed]

I've just been trying to catch up with the posts already so figured
I'd just start another thread as it seemed I would address things from
multiple emails. I really need to get my sieve filter script updated to
move the list emails into the proper folder now I guess :)

    We can play with the revision of the packaging during testing. One
idea would be to use 3.0.1-0.YYYYMMDD for experimental test packaging
and then later change to 3.0.1-1 for the actual release. The advantage
of this is that it gives us an indefinate amount of revisions without
making the version string considerably longer with multiple versions. Of
course it would limit us to a daily build release. We also need not have
to necessarially upload to the 'experimental' distro for testing but can
host a mini-repository using the mini-dinstall package and even have it
so anyone in the group could actually upload to that, whereas the
official upload would need to be done by one of us with DD upload rights.

    As for the kernel patch build policy. As I've spoken with a few
other DDs, the build should be self-contained and this not require
anything beyond what is listed in the Build-Depends in order to build
properly. The idea being a blackbox build that only downloads what's
listed in the Build-Depends and builds offline. With that the use of the
upstream build process using wget to download the kernel doesn't fit
well. Unfortunately Debian only provides one kernel source package and
it isn't exactly the same version in stable, testing and unstable so
this is a bit of a quandry to work out as we need to provide a patch. as
someone stated this would be a lot easier if it were merged with the
mainstream kernel, but that may take some time so we need to come up
with the most elegant way that fits the distribution. I hadn't taken
much of a look yet to see what the patches actually did but noticed that
the patches were applied before the sparse tree during the patch
creation process. Would it potentially be possible for us to manage
multiple kernel version patches to be applied before the sparse tree in
order to match the versions available within the distribution? Granted
this would add extra effort into making the build. Obviously having
upstream just providing kernel-<version>.patch files would be better
than having to generate the patch during build process, but that may
take even more time to coordinate.

    Regards,
    Jeremy


--
------------------------ [ SECURITY NOTICE ] ------------------------
To: pkg-xen-devel@lists.alioth.debian.org.
For your security, jbouse@debian.org
digitally signed this message on 16 February 2006 at 17:53:28 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAjhwa2cteGVuLWRldmVsQGxpc3RzLmFsaW90aC5kZWJpYW4ub3JnA
Gpib3VzZUBkZWJpYW4ub3JnAGVtYWlsIGJvZHkAzAcAAHwAfAAAAAEAAAAYvPRDzAcAAF
sDAAIAAgACACBbbe/kx8tpUyJhmgvpubSxgZmn0dxD/KgljpsTpsvZVQEAJLQlVT52rnd
nqox8AzyHB09mthbDWqsaMF1UXyCm8B52Ot2iqqv7oV+1Cv1A2EjeFH4fxk/pRtHuKTx8
w8WdmgQG/yRiU2lnRW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------

Am Donnerstag, 16. Februar 2006 18:53 schrieb Jeremy T. Bouse [c]:
[...]
>     As for the kernel patch build policy. As I've spoken with a few
> other DDs, the build should be self-contained and this not require
> anything beyond what is listed in the Build-Depends in order to build
> properly. The idea being a blackbox build that only downloads what's
> listed in the Build-Depends and builds offline. With that the use of the
> upstream build process using wget to download the kernel doesn't fit
> well. 
an alternative is to create source package that already have the 
"linux-<version>.tar.bz2" file included. That would blow the
package but
would make it possible to build the binary packages without any inet access. 
> Unfortunately Debian only provides one kernel source package and 
> it isn't exactly the same version in stable, testing and unstable so
> this is a bit of a quandry to work out as we need to provide a patch. 
and adam seems to dislike using the debian kernel-source packages also, but as 
I mentioned after that comment he never uploaded a newer version anymore.

the problem is not just that there are different versions in stable, testing 
and unstable, but also that a kernel-source version will disappear from 
testing and unstable and that would force us to find another solution then.
> as 
> someone stated this would be a lot easier if it were merged with the
> mainstream kernel, but that may take some time so we need to come up
> with the most elegant way that fits the distribution. I hadn't taken
> much of a look yet to see what the patches actually did but noticed that
> the patches were applied before the sparse tree during the patch
> creation process. Would it potentially be possible for us to manage
> multiple kernel version patches to be applied before the sparse tree in
> order to match the versions available within the distribution?
hmmm, I don't know If I got you right, but supporting another kernel version
then the xen upstream normally uses is afaik a hard job.
> Granted 
> this would add extra effort into making the build. Obviously having
> upstream just providing kernel-<version>.patch files would be better
> than having to generate the patch during build process, but that may
> take even more time to coordinate.
I don't know if upstream wants that, but on the other hand they haven't
fixed
a problem that exists in the upstream mehtod to create the kernel patch for 
some time now, that's why the patch gets created with the following command 
in debian/rules:

diff -Nurp pristine-linux-$(LINUX_VERSIONS)/ linux-$(LINUX_VERSIONS)-xen/
>linux-$(LINUX_VERSIONS)-xen.patch
normaly even that should be done with xen's makefile target: mkpatches.
>
>     Regards,
>     Jeremy

On Thu, Feb 16, 2006 at 09:53:22AM -0800, Jeremy T. Bouse [c]
wrote:
>     We can play with the revision of the packaging during testing. One
> idea would be to use 3.0.1-0.YYYYMMDD for experimental test packaging
> and then later change to 3.0.1-1 for the actual release. The advantage
> of this is that it gives us an indefinate amount of revisions without
> making the version string considerably longer with multiple versions.
It will be ok for the pre 3.0.1-1 version, but not after, I guess. :)
> Of
> course it would limit us to a daily build release. We also need not have
> to necessarially upload to the 'experimental' distro for testing
but can
> host a mini-repository using the mini-dinstall package and even have it
> so anyone in the group could actually upload to that, whereas the
> official upload would need to be done by one of us with DD upload rights.
Right. Too early to say if we have a lot of "experimental" upload to
do, for me.
>     As for the kernel patch build policy. As I've spoken with a few
> other DDs, the build should be self-contained and this not require
> anything beyond what is listed in the Build-Depends in order to build
> properly. The idea being a blackbox build that only downloads what's
> listed in the Build-Depends and builds offline. With that the use of the
> upstream build process using wget to download the kernel doesn't fit
> well.
Good point.
> Unfortunately Debian only provides one kernel source package and
> it isn't exactly the same version in stable, testing and unstable so
> this is a bit of a quandry to work out as we need to provide a patch.
We should follow Debian/unstable, anyway.
> Obviously having
> upstream just providing kernel-<version>.patch files would be better
> than having to generate the patch during build process, but that may
> take even more time to coordinate.
Maybe we should simply do this patches ourselves and repackage upstream
tarball a bit ? (not sure this is a good way to do, just an idea).

-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20060216/47ebb992/attachment.pgp

On Thu, Feb 16, 2006 at 09:53:22AM -0800, Jeremy T. Bouse [c] wrote:

Hi,
>     We can play with the revision of the packaging during testing. One
> idea would be to use 3.0.1-0.YYYYMMDD for experimental test packaging
> and then later change to 3.0.1-1 for the actual release. The advantage
> of this is that it gives us an indefinate amount of revisions without
> making the version string considerably longer with multiple versions. Of
> course it would limit us to a daily build release. We also need not have
> to necessarially upload to the 'experimental' distro for testing
but can
> host a mini-repository using the mini-dinstall package and even have it
> so anyone in the group could actually upload to that, whereas the
> official upload would need to be done by one of us with DD upload rights.
> 
Having a mini-dinstall repo is fine... I can provide one under debian.quaqua.net
if you like! As for the versioning... Since we don't want to confuse with
NMUs
maybe it's better if we avoid the "." in the debian part...

Also, even if we have our private mini-dinstall repo every time we upload there
we need to bump up the version, as we would do with experimental, in order to
let people upgrade, but what about the changlog entry? Would every entry be
official only for debian uploads? In that case we can just do something like
3.0.1-0+internal_number bumping up internal_number whenever ones like, and then
changing the first one when we do debian uploads... And the internal number will
always be shorter than YYYYMMDD and also grant us more than one upload a day!
>     As for the kernel patch build policy. As I've spoken with a few
> other DDs, the build should be self-contained and this not require
> anything beyond what is listed in the Build-Depends in order to build
> properly. The idea being a blackbox build that only downloads what's
> listed in the Build-Depends and builds offline. With that the use of the
> upstream build process using wget to download the kernel doesn't fit
> well. 
True... Well, let's avoid that, then!
> Unfortunately Debian only provides one kernel source package and
> it isn't exactly the same version in stable, testing and unstable so
> this is a bit of a quandry to work out as we need to provide a patch. 
And also xen doesn't support the last one debian-stable has, but an older
one...
> as someone stated this would be a lot easier if it were merged with the
> mainstream kernel, but that may take some time so we need to come up with
the
> most elegant way that fits the distribution. I hadn't taken much of a
look yet
> to see what the patches actually did but noticed that the patches were
applied
> before the sparse tree during the patch creation process. Would it
potentially
> be possible for us to manage multiple kernel version patches to be applied
> before the sparse tree in order to match the versions available within the
> distribution? 
The first point is: do we want to support anything different than 2.6.12.6,
which is the one xen 3.0.1 supports officially? If we do then I guess we're
in
trouble because of the fact that patches might not apply, etc!
> Granted this would add extra effort into making the build. Obviously having
> upstream just providing kernel-<version>.patch files would be better
than
> having to generate the patch during build process, but that may take even
more
> time to coordinate.
> 
On the other hand if we just support 2.6.12.6 we can just ship
kernel-2.6.12.6.patch prepared manually in the debian/ directory and forget
about it...

Guido