Re: Future of the linux udebs
On Tue, Feb 19, 2008 at 10:05:15PM +0100, Frans Pop wrote: Before I replay to the proposal and the various options, I have two questions: 1) Exactly what problem or problems is this proposal solving? This was no proposal, this was an announcement. We don't longer use this sort of source since we have one common source package for the kernels. 2) How would the new situation be better than the current situation for Debian as a whole? Nothing. This only removes the burden of maintenance from one team. Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, Shore Leave, stardate 3025.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the linux udebs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: On Tue, Feb 19, 2008 at 10:05:15PM +0100, Frans Pop wrote: Before I replay to the proposal and the various options, I have two questions: 1) Exactly what problem or problems is this proposal solving? This was no proposal, this was an announcement. We don't longer use this sort of source since we have one common source package for the kernels. Calm down a bit Bastian. You can't change this without agrement from d-i side. - -- O T A V I OS A L V A D O R - - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - - Microsoft sells you Windows ... Linux gives you the whole house. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFHvZSeLqiZQEml+FURAhsgAKCk+2XjAe4DzIx18w6N19qazFxr9QCeO9do DyZbL6VUNDcLfR0IizyYGN4= =jrJl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the linux udebs
Hi, On Sat, Feb 16, 2008 at 10:52:17PM -0200, Otavio Salvador wrote: Please read the thread we had about 2.6.24 kernel testing migration... this is what worries me. I don't want to reopen that discussion here, and I see your argument. There are really good reasons to do beta1 with .24, and good reasons for .22 too. In such a case we might need someone to arbitrate, the release managers come to mind. I personally have a good relation with all active people in debian-kernel but I think that we might have a policy to avoid problems to happen. Good will isn't enough, IMO. We should decide case by case, considering what is best to get closer to the release. If adapting the concerned installer components to .24 takes too long and requires developers to focus on other things than stabilizing the code for beta1, we should indeed go with .22 for it, and so we can test 2.6.24 on a stabilized installer in beta2. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Future of the linux udebs
Frederik Schueler [EMAIL PROTECTED] writes: ... I personally have a good relation with all active people in debian-kernel but I think that we might have a policy to avoid problems to happen. Good will isn't enough, IMO. We should decide case by case, considering what is best to get closer to the release. If adapting the concerned installer components to .24 takes too long and requires developers to focus on other things than stabilizing the code for beta1, we should indeed go with .22 for it, and so we can test 2.6.24 on a stabilized installer in beta2. That's the plan. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the linux udebs
On Fri, Feb 15, 2008 at 04:40:47PM -0200, Otavio Salvador wrote: If a unwanted kernel is uploaded to sid and we wanted to update the udebs, for a release or something, we would end up doing it t-p-u. This would be done with minor testing and possible breaking lenny installer. So? If we need to update the kernel themself, it is also needed. So your idea is to this list be placed inside each source package? It's the only solution which will not kill new versions without code to ignore udebs if the definitions are broken. Didn get you here. Could you elaborate it a bit? The list contains module X. This module got removed. What should happen with the build? - Fail silent. Ignore the error and don't output any udebs. - Fail loud. The first variant needs to be used if the list is included from an external source if it should not break it complete. I won't implement it because the build output is not longer reproducible. The list needs to be available during build of the source package, it is not possible to change them after that. Sure. But it could be available from kernel-wedge or something? It introduces an out-of-date problem. You can only force the availability of a new enough version by an explicit build-dep. To be exact, it needs to be a = dep. This would allow us to keep control about what would be end in d-i kernel modules packages. We have to process it anyway and will be able to change it in any way we want. This is called trust. If this could be done from a d-i package (k-w or anything) it gives us a cannonical place to look at and don't force us to follow another commit mailing list to get the need information. You would be forced to read build logs for failures and handle them on your own, because we don't like breakages and would disable the build completely, which does not get as anything except more possible problems. Everything might break. And we need to try to avoid it as possible. Yes. The solution is called test, either programmatic (which is not that easy in this case) or manual. Bastian -- Killing is stupid; useless! -- McCoy, A Private Little War, stardate 4211.8 signature.asc Description: Digital signature
Re: Future of the linux udebs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: On Fri, Feb 15, 2008 at 04:40:47PM -0200, Otavio Salvador wrote: If a unwanted kernel is uploaded to sid and we wanted to update the udebs, for a release or something, we would end up doing it t-p-u. This would be done with minor testing and possible breaking lenny installer. So? If we need to update the kernel themself, it is also needed. But it's obviously something to avoid. I know that there're alternatives however it's not the best option. So your idea is to this list be placed inside each source package? It's the only solution which will not kill new versions without code to ignore udebs if the definitions are broken. Didn get you here. Could you elaborate it a bit? The list contains module X. This module got removed. What should happen with the build? - Fail silent. Ignore the error and don't output any udebs. - Fail loud. The first variant needs to be used if the list is included from an external source if it should not break it complete. I won't implement it because the build output is not longer reproducible. I think it should fail loudly. Yeah, after thinking more about it I figured that if we choose to go for udebs being build by kernel source packages, we does need to have it in the kernel package source. This would allow us to keep control about what would be end in d-i kernel modules packages. We have to process it anyway and will be able to change it in any way we want. This is called trust. While I agree that it's suppose to work, I also think that it can bring serious discussions like we had lately (because of 2.6.24 migration to testing). If we were already using this schema, the Beta1 release would need to delay since we do not have 2.6.22 on sid anymore. For me, to think more about it, we need an agreement from kernel team that d-i can veto uploads of kernel. Obviously d-i team won't deny any upload with real reasons however this agreement this is a must from my POV. Let me express my conclusion up to now for this thread (even I still want to see a comment from Colin, Joey and Frans on this): - if we choose to go with kernel sources building udebs, k-w is dead; - kernel team needs to accept nacks from d-i team for badly time uploads (this is a must); - time needed for migration to new kernel would be reduced a lot; - tests would be need, for d-i, from snapshots of kernel; Cheers, - -- O T A V I OS A L V A D O R - - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - - Microsoft sells you Windows ... Linux gives you the whole house. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFHt0qSLqiZQEml+FURAs1HAJ43XrO2zga1AZtHDvsQwUjxYpGHvACgkPRh a6AzostXhbnMNenQ9B1NDT0= =Kwqe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the linux udebs
On Sat, Feb 16, 2008 at 06:42:05PM -0200, Otavio Salvador wrote: For me, to think more about it, we need an agreement from kernel team that d-i can veto uploads of kernel. Obviously d-i team won't deny any upload with real reasons however this agreement this is a must from my POV. Not acceptable. -- Live long and prosper. -- Spock, Amok Time, stardate 3372.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the linux udebs
Hello, On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote: Bastian Blank [EMAIL PROTECTED] writes: - Is impossible to release d-i with a different kernel from sid without a lot of hassle - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i development is affected This last item is where I worry a lot. Obviously, kernel team want to put newest kernel on sid however, when he does it, d-i will be forced to change it too. Coordination is already needed now, and will be needed even more when this change is implemented. If this means waiting with a new upstream kernel version for a week or two until the next beta of d-i is done, we will of course wait, no one wants to break d-i development by purpose. For it to work testing images, _before_ the kernel upload to happen, would be required to at least reduce the risk of a kernel upload to stop all d-i development until it gets fixed. We have the kernel-snapshots archive to test new images before uploading them. This infrastructure could be extended, by adding buildds for all missing architectures, and whatever else is needed to get daily d-i snapshots built with these kernels. Another thihk that I see as a _must_ is that d-i team could nack a kernel upload. This is requred since d-i won't be allowed to diverge from sid kernels anymore (I mean during development) and those migrations would need to be much more coordinated with d-i RM and d-i porters. Nobody will insist on uploading a new kernel version if this breaks the release schedule, just think of 2.6.19, which never was uploaded to the archive because we where in the middle of releasing etch. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Future of the linux udebs
Frederik Schueler [EMAIL PROTECTED] writes: Hello, On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote: Bastian Blank [EMAIL PROTECTED] writes: - Is impossible to release d-i with a different kernel from sid without a lot of hassle - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i development is affected This last item is where I worry a lot. Obviously, kernel team want to put newest kernel on sid however, when he does it, d-i will be forced to change it too. Coordination is already needed now, and will be needed even more when this change is implemented. If this means waiting with a new upstream kernel version for a week or two until the next beta of d-i is done, we will of course wait, no one wants to break d-i development by purpose. Exactly however for that to work we, d-i team, need to be able to nack a kernel upload. Please read the thread we had about 2.6.24 kernel testing migration... this is what worries me. For it to work testing images, _before_ the kernel upload to happen, would be required to at least reduce the risk of a kernel upload to stop all d-i development until it gets fixed. We have the kernel-snapshots archive to test new images before uploading them. This infrastructure could be extended, by adding buildds for all missing architectures, and whatever else is needed to get daily d-i snapshots built with these kernels. Yes, that's one thing that do like. This would allow us to have a current d-i image and one using the next kernel, just released. Another thihk that I see as a _must_ is that d-i team could nack a kernel upload. This is requred since d-i won't be allowed to diverge from sid kernels anymore (I mean during development) and those migrations would need to be much more coordinated with d-i RM and d-i porters. Nobody will insist on uploading a new kernel version if this breaks the release schedule, just think of 2.6.19, which never was uploaded to the archive because we where in the middle of releasing etch. I guess so but we had a hard time about 2.6.24. This needs to get an agreement from both sides to be able to work. I personally have a good relation with all active people in debian-kernel but I think that we might have a policy to avoid problems to happen. Good will isn't enough, IMO. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the linux udebs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: While I'm not nacking it right now, I nack it to happen before Beta2 with 2.6.24 gets out. ... Build the udebs from the linux-2.6/linux-modules-extra-2.6 sources. Pros: - Only one step. - Problems in the module selection can be found during the kernel development cycle. This includes added modules. Cons for the kernel team: - Another list to handle and which will kill the build if someone got it wrong. - The additional configs for the build can't be checked without a real build. Cons for the d-i team: - They have to trust another instance to don't get it completely wrong. - Changes in the module selection may need a full rebuild. - Out-of-dateness of modules and buildsystem during the introdution of a new abiname. - Is impossible to release d-i with a different kernel from sid without a lot of hassle - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i development is affected This last item is where I worry a lot. Obviously, kernel team want to put newest kernel on sid however, when he does it, d-i will be forced to change it too. For it to work testing images, _before_ the kernel upload to happen, would be required to at least reduce the risk of a kernel upload to stop all d-i development until it gets fixed. Another thihk that I see as a _must_ is that d-i team could nack a kernel upload. This is requred since d-i won't be allowed to diverge from sid kernels anymore (I mean during development) and those migrations would need to be much more coordinated with d-i RM and d-i porters. linux-2.6/linux-modules-extra-2.6 would build the udebs using what list? Still using kernel-wedge? How the uploads of kernel would be coordinated? Will kernel team allow d-i to _nack_ a kernel upload? - -- O T A V I OS A L V A D O R - - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - - Microsoft sells you Windows ... Linux gives you the whole house. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFHtaImLqiZQEml+FURAoJEAKCrFV2EuCgLH45/zouGG0k6whkGawCgpfnp /So/qOzYfRyGUWWmdc8u2b4= =QBkE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the linux udebs
On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote:
While I'm not nacking it right now, I nack it to happen before Beta2
with 2.6.24 gets out.
I did not setup a timeline yet. Because of the status of .24, it won't
get the support anyway. So .25 is the minimum.
- Is impossible to release d-i with a different kernel from sid
without a lot of hassle
d-i releases are built with testing udebs. Or do you mean something
else?
| ifeq (${SUITE},UNRELEASED)
| USE_UDEBS_FROM=unstable
| else
| USE_UDEBS_FROM=lenny
| endif
- If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i
development is affected
If a bad glibc is uploaded, anything is affected. With such sort of
arguments you can kill anything because the propability that something
will get wrong is always larger than zero. We do a lot to not let really
broken things through and I don't think you will be able to catch more
problems.
For it to work testing images, _before_ the kernel
upload to happen, would be required to at least reduce the risk of a
kernel upload to stop all d-i development until it gets fixed.
We provide a snapshots archive which can be used through the whole
development cycle.
Another thihk that I see as a _must_ is that d-i team could nack a
kernel upload. This is requred since d-i won't be allowed to diverge
from sid kernels anymore (I mean during development) and those
migrations would need to be much more coordinated with d-i RM and d-i
porters.
We coordinate the uploads on d-kernel@, for security uploads the waiting
period is usualy a lot shorter. If someone have a problem, he can speak
up and his concerns will get heard.
linux-2.6/linux-modules-extra-2.6 would build the udebs using what
list? Still using kernel-wedge?
They need to include the list themself, it will get version dependant.
How the uploads of kernel would be coordinated? Will kernel team allow
d-i to _nack_ a kernel upload?
Not for uploads which fixes bugs like CVE-2008-0600. A nack without
anything may also not have any effect. But if there are concerns we
should be able to find a solution which both sides can live with.
Bastian
--
There are some things worth dying for.
-- Kirk, Errand of Mercy, stardate 3201.7
signature.asc
Description: Digital signature
Re: Future of the linux udebs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote: ... - Is impossible to release d-i with a different kernel from sid without a lot of hassle d-i releases are built with testing udebs. Or do you mean something else? Not during development cycle. And the udebs on testing migrated to it from sid. I hope to not need to do uploads to t-p-u for d-i kernel ;-) ... - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i development is affected If a bad glibc is uploaded, anything is affected. With such sort of arguments you can kill anything because the propability that something will get wrong is always larger than zero. We do a lot to not let really broken things through and I don't think you will be able to catch more problems. Right. But it is a cons since currently we only migrate to the new kernel when it's already widly tested on sid. For it to work testing images, _before_ the kernel upload to happen, would be required to at least reduce the risk of a kernel upload to stop all d-i development until it gets fixed. We provide a snapshots archive which can be used through the whole development cycle. Yes, right. We'd need to setup some way to get d-i builds against those images and do testing using it before major kernel version uploads. Another thihk that I see as a _must_ is that d-i team could nack a kernel upload. This is requred since d-i won't be allowed to diverge from sid kernels anymore (I mean during development) and those migrations would need to be much more coordinated with d-i RM and d-i porters. We coordinate the uploads on d-kernel@, for security uploads the waiting period is usualy a lot shorter. If someone have a problem, he can speak up and his concerns will get heard. I'm not wondering about security uploads but about ABI changes and major kernel version updates. Those would need to be coordinated on debian-boot too. I guess that a notice about upload, few days before, to debian-boot ml should be enough, for ABI changes. For major versions, we'd need much larger coordination since it would affect whole d-i. Obviously, as already spot by you, we can get images built against the kernel snapshots but we'd need to get an infrastructure to get d-i images built against it and tested before approval for the kernel upload. linux-2.6/linux-modules-extra-2.6 would build the udebs using what list? Still using kernel-wedge? They need to include the list themself, it will get version dependant. So your idea is to this list be placed inside each source package? This means kernel-wedge will be useless and _any_ change would be need to be done on kernel team svn. This is a big regression from my POV since d-i team does need to be able to change the list by himself. How the uploads of kernel would be coordinated? Will kernel team allow d-i to _nack_ a kernel upload? Not for uploads which fixes bugs like CVE-2008-0600. A nack without anything may also not have any effect. But if there are concerns we should be able to find a solution which both sides can live with. I agree that security uploads are exception here however any other ABI or major version update would must to be acked by d-i team. This looks logical since we'll be directly affected by it and the installer might break. - -- O T A V I OS A L V A D O R - - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - - Microsoft sells you Windows ... Linux gives you the whole house. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFHtboLLqiZQEml+FURAonUAJwNMZNYsOEqYLvNFrf+brBOMdOvXgCghMdX Tr/IltraJ/QKXpLXLlRwVis= =9+UD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the linux udebs
Bastian Blank [EMAIL PROTECTED] writes: On Fri, Feb 15, 2008 at 02:13:02PM -0200, Otavio Salvador wrote: ... And the udebs on testing migrated to it from sid. I hope to not need to do uploads to t-p-u for d-i kernel ;-) I still don't get you. Kernel udebs on testing came from sid. So they're suppose to be uploaded there and migrate. If a unwanted kernel is uploaded to sid and we wanted to update the udebs, for a release or something, we would end up doing it t-p-u. This would be done with minor testing and possible breaking lenny installer. That's why it should be avoided as possible. linux-2.6/linux-modules-extra-2.6 would build the udebs using what list? Still using kernel-wedge? They need to include the list themself, it will get version dependant. So your idea is to this list be placed inside each source package? It's the only solution which will not kill new versions without code to ignore udebs if the definitions are broken. Didn get you here. Could you elaborate it a bit? This means kernel-wedge will be useless and _any_ change would be need to be done on kernel team svn. The list needs to be available during build of the source package, it is not possible to change them after that. Sure. But it could be available from kernel-wedge or something? This would allow us to keep control about what would be end in d-i kernel modules packages. This is a big regression from my POV since d-i team does need to be able to change the list by himself. There are two sorts of changes: - Modules got renamed/merged/removed. This will kill the build if not fixed, so we need to be able to do such changes on ourself. Right. - Modules got added. This may have an effect, but usualy it is new hardware support. Now please explain why you _need_ to change that directly and produce the following workflow mailto:d-i, commit, upload k-w, mailto:kernel, commit, upload l instead of mailto:kernel, commit, upload l. This is a classical indirection. The problem of doing it directly inside of kernel is that we'll lose the control of what is being deployed and we'll then need to get informated about every change inside of kernel packages to get this information sorted out. If this could be done from a d-i package (k-w or anything) it gives us a cannonical place to look at and don't force us to follow another commit mailing list to get the need information. This looks logical since we'll be directly affected by it and the installer might break. Everything might break. And we need to try to avoid it as possible. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
