Re: etch's upgrades during life cycle
On Friday 02 February 2007 06:49, Andreas Barth <[EMAIL PROTECTED]> wrote: > > What i am saying is: is it possible to in a lenny or lenny++ change the > > way debian upgrades it's stable, just for the kernel? > > There are few plans how to add one more kernel in the middle of Etchs > life time to support more hardware - reality will show us how good we > match that. Is it certain that a kernel alone will be enough? Might there be changes required to x.org, fdisk, udev, hal, and other things for new hardware? Another possible reason for a new package is discovering bugs in code that has potential security issues. Currently we release new packages to fix security problems, but AFAIK we don't fix potential issues. I recall the mremap() kernel security issue that was discovered by the bad guys after it was fixed as a non-security issue in the kernel.org repository. Maybe some similar fixes could be candidates for inclusion. What about documentation changes? If package foo-doc changes then it has little potential for serious regression, and if the old version of the document was misleading in a bad way then it could justify an upgrade. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
* Luis Matos ([EMAIL PROTECTED]) [070103 20:55]: > My proposal would be in point releases to change the kernel a bit to > support more hardware. That kernel would be tested, ofcourse. > > What i am saying is: is it possible to in a lenny or lenny++ change the > way debian upgrades it's stable, just for the kernel? There are few plans how to add one more kernel in the middle of Etchs life time to support more hardware - reality will show us how good we match that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
On Friday 05 January 2007 09:00, Luis Matos <[EMAIL PROTECTED]> wrote: > I always compared debian stable with RHEL. They both target the same, i > think. I agree that RHEL offers some significant benefits to users that Debian could copy. RHEL kernels are updated to support new hardware. This means that drivers are back-ported to the kernel version from the initial release of the version of RHEL in question. This means that there is a minimal chance that people who use old hardware will have things broken by the new hardware support. Do we have people who have the time and ability to back-port such drivers for Debian? Some packages that have bugs fixed in RHEL updates also need to have the fixes applied to Fedora, Rawhide, and newer RHEL releases. In some cases this means that bugs which affect the newer distributions are only discovered because of people hitting them in older versions of RHEL in production. Therefore this policy of applying fixes (including some feature requests) helps the newer versions. I believe that the way updates are managed in RHEL is better than we have done in the past for Debian. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qui, 2007-01-04 às 20:22 -0500, Matthias Julius escreveu: > Luis Matos <[EMAIL PROTECTED]> writes: > > >> > >> There could be another archive called updates.debian.org where > >> selected packages go in in coordination with the security and stable > >> release teams. > > that would be nicier ... but that's a bit of volatile's purpose. > > Although it is not very used. > > You are right. It does sound a lot like volatile. I didn't know much > abaut it up to now. Maybe all that needs to be done is to make it > more official, have it supported by the security team and put a > commented out line for it into sources.list. I think for desktop use, volatile could be a good answear to update some software. Also, like to servers. > > Matthias > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Luis Matos <[EMAIL PROTECTED]> writes: >> >> There could be another archive called updates.debian.org where >> selected packages go in in coordination with the security and stable >> release teams. > that would be nicier ... but that's a bit of volatile's purpose. > Although it is not very used. You are right. It does sound a lot like volatile. I didn't know much abaut it up to now. Maybe all that needs to be done is to make it more official, have it supported by the security team and put a commented out line for it into sources.list. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Sex, 2007-01-05 às 00:57 +0100, Daniel Baumann escreveu: > Luis Matos wrote: > > backports use testing as base for the packages. > > setting up security for backports is a bit easier than for testing. Lot > > less packages. > > My point is, for example, when the security team lauches a DSA, it > > always sees if both unstable and testing are afected. They already > > monitor testing and unstable too ... it's just a question of applying > > patches. (maybe a apt-patch package. in which he rebuilds the package > > with the selected patch). > > > > The same would do for backports, security team would patch the package > > and send it to the buildd. > > > > I know ... it's more and more work for the security team ... > > thinking aloud: hypothetically assumed that (parts of) backports.org > would get official, i could do security support for it as i do it atm > for about half of the packages on backports.org anyway. That was a good idea (if backports integrate debian). The security team already monitors testing and unstable ... do, it is only needed for someone to patch the packages. I am not a DD ... But this could be a good step to bring backports.org into debian for etch. > > -- > Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist > Email: [EMAIL PROTECTED] > Internet: http://people.panthera-systems.net/~daniel-baumann/ > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Luis Matos wrote: > backports use testing as base for the packages. > setting up security for backports is a bit easier than for testing. Lot > less packages. > My point is, for example, when the security team lauches a DSA, it > always sees if both unstable and testing are afected. They already > monitor testing and unstable too ... it's just a question of applying > patches. (maybe a apt-patch package. in which he rebuilds the package > with the selected patch). > > The same would do for backports, security team would patch the package > and send it to the buildd. > > I know ... it's more and more work for the security team ... thinking aloud: hypothetically assumed that (parts of) backports.org would get official, i could do security support for it as i do it atm for about half of the packages on backports.org anyway. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qui, 2007-01-04 às 16:43 -0500, Matthias Julius escreveu: > Luis Matos <[EMAIL PROTECTED]> writes: > > > Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu: > >> > >> backports.org is, to my mind, a perfect solution to this problem; it > >> allows you to selectively upgrade your favourite/important packages that > >> you need, whilst retaining the stable base on which to run them. > >> > > > > here i agree that backports.org is the way out and that should be > > official so maintainers could upload backports in a easier and have a > > better security support. (and gives users other view for it if > > backports.org is indeed in debian and recommended by debian.) > > Maybe backports.org is too much and changing to frequently to provide > security support for and to be really stable. backports use testing as base for the packages. setting up security for backports is a bit easier than for testing. Lot less packages. My point is, for example, when the security team lauches a DSA, it always sees if both unstable and testing are afected. They already monitor testing and unstable too ... it's just a question of applying patches. (maybe a apt-patch package. in which he rebuilds the package with the selected patch). The same would do for backports, security team would patch the package and send it to the buildd. I know ... it's more and more work for the security team ... > > There could be another archive called updates.debian.org where > selected packages go in in coordination with the security and stable > release teams. that would be nicier ... but that's a bit of volatile's purpose. Although it is not very used. at a certain point several packages could be updated, because mainstream releases an important release. Like mysql-5.0, or ooo 2.0 ... and they could be addressed to backports or volatile or updates (volatile, for me, means critical updates for debian stable ... because stable must remain ... stable). We definitly need something to make debian stable move while it is stable. Someone talked about the release cycles ... i think debian should not move to less than one year ... we already have ubuntu and see what is going there with the 6 months. The main problem for the year release is desktop, because linux has suffered lots of evolution in this field in so little time. Companies that deploy linux on desktop seem to seek for updating contantly the desktop (or others let them to rott). I think what debian needs is a lift in the desktop part, and the desktop team is moving. (the desktop team needs designers or people in the design area) I always compared debian stable with RHEL. They both target the same, i think. > > Matthias > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Luis Matos <[EMAIL PROTECTED]> writes: > Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu: >> >> backports.org is, to my mind, a perfect solution to this problem; it >> allows you to selectively upgrade your favourite/important packages that >> you need, whilst retaining the stable base on which to run them. >> > > here i agree that backports.org is the way out and that should be > official so maintainers could upload backports in a easier and have a > better security support. (and gives users other view for it if > backports.org is indeed in debian and recommended by debian.) Maybe backports.org is too much and changing to frequently to provide security support for and to be really stable. There could be another archive called updates.debian.org where selected packages go in in coordination with the security and stable release teams. Matthias
Re: etch's upgrades during life cycle
Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu: > On Thu, Jan 04, 2007 at 11:00:16AM +, Paul Waring wrote: > > > I think the problem that many people find with Debian is that they do > > want the stability and security of stable, but at the same time they > > don't want to be a dozen releases behind upstream. I've seen many > > occasions where there's been a new release with useful features that has > > been available in upstream for months and it's still not in Debian > > stable, even though it is available in the package repositories of other > > Linux distributions. It's not so much a case of wanting to be on the > > bleeding edge for most people, but more that we don't want to still be > > powering our machines with crank handles when everyone else has moved on > > to electricity. > > backports.org is, to my mind, a perfect solution to this problem; it > allows you to selectively upgrade your favourite/important packages that > you need, whilst retaining the stable base on which to run them. > here i agree that backports.org is the way out and that should be official so maintainers could upload backports in a easier and have a better security support. (and gives users other view for it if backports.org is indeed in debian and recommended by debian.) > One proviso I would add to that is that it's only good so long as it > doesn't move too much focus away from Debian's own stable releases. I > can't see any evidence of that at present. It's also possibly the case > that backports.org could/should made more official or at least offically > recommended by Debian, although I understand why this isn't necessarily > the case right now. > > However, the original question was about hardware support, which is a > rather special case. I've spent many frustrated hours getting Debian > stable onto modern hardware using various tricks and hacks, and I'm sure > anyone running Debian extensively in production has had similar > experiences. This is one area where an official updated installer and > kernel would greatly improve life, and I'm very interested by Moritz's > comment that this is planned for etch. oh yeah ... in the woody time, i was save by a d-i rc1, installing new hp proliants. > > Cheers, > > Dominic. > > -- > Dominic Hargreaves | http://www.larted.org.uk/~dom/ > PGP key 5178E2A5 from the.earth.li (keyserver,web,email) > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
On Thu, Jan 04, 2007 at 11:00:16AM +, Paul Waring wrote: > I think the problem that many people find with Debian is that they do > want the stability and security of stable, but at the same time they > don't want to be a dozen releases behind upstream. I've seen many > occasions where there's been a new release with useful features that has > been available in upstream for months and it's still not in Debian > stable, even though it is available in the package repositories of other > Linux distributions. It's not so much a case of wanting to be on the > bleeding edge for most people, but more that we don't want to still be > powering our machines with crank handles when everyone else has moved on > to electricity. backports.org is, to my mind, a perfect solution to this problem; it allows you to selectively upgrade your favourite/important packages that you need, whilst retaining the stable base on which to run them. One proviso I would add to that is that it's only good so long as it doesn't move too much focus away from Debian's own stable releases. I can't see any evidence of that at present. It's also possibly the case that backports.org could/should made more official or at least offically recommended by Debian, although I understand why this isn't necessarily the case right now. However, the original question was about hardware support, which is a rather special case. I've spent many frustrated hours getting Debian stable onto modern hardware using various tricks and hacks, and I'm sure anyone running Debian extensively in production has had similar experiences. This is one area where an official updated installer and kernel would greatly improve life, and I'm very interested by Moritz's comment that this is planned for etch. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Daniel Baumann wrote: however, if you want to have latest and greatest but with stability and security as you know it from debian stable, then you are asking for the impossible. I think the problem that many people find with Debian is that they do want the stability and security of stable, but at the same time they don't want to be a dozen releases behind upstream. I've seen many occasions where there's been a new release with useful features that has been available in upstream for months and it's still not in Debian stable, even though it is available in the package repositories of other Linux distributions. It's not so much a case of wanting to be on the bleeding edge for most people, but more that we don't want to still be powering our machines with crank handles when everyone else has moved on to electricity. Having said that, the Debian release cycle does seem to be speeding up a bit, which is definitely a good thing. Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qua, 2007-01-03 às 22:28 +0100, Daniel Baumann escreveu: > Luis Matos wrote: > > So, if we loose security and stability ... why use debian? > > security and stability, that is excately what makes these backports > unofficial (more stability and bugs are an issue than security, though). > > however, if you want to have latest and greatest but with stability and > security as you know it from debian stable, then you are asking for the > impossible. i don't want the latest and the greatest ... i want a newer kernel :P not means to be the latest ... even when you know that there are some buggy releases. > > -- > Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist > Email: [EMAIL PROTECTED] > Internet: http://people.panthera-systems.net/~daniel-baumann/ > > -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Luis Matos wrote: > Many users have complaints about in the middle of the life cycle, or > before the debian stable release no longer supports new hardware. > Therefor a new kernel would be needed for d-i ( or an hardware > compatibility update for the kernel and modules). > > My proposal would be in point releases to change the kernel a bit to > support more hardware. That kernel would be tested, ofcourse. > > What i am saying is: is it possible to in a lenny or lenny++ change the > way debian upgrades it's stable, just for the kernel? Yes, there are plans for a second set of kernels (and probably xservers) nine months after Etch release, which will also have security support. However nothing's fixed yet, as the current focus is on getting Etch ready. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Luis Matos wrote: > So, if we loose security and stability ... why use debian? security and stability, that is excately what makes these backports unofficial (more stability and bugs are an issue than security, though). however, if you want to have latest and greatest but with stability and security as you know it from debian stable, then you are asking for the impossible. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qua, 2007-01-03 às 22:13 +0100, Daniel Baumann escreveu: > Luis Matos wrote: > > What i am saying is: is it possible to in a lenny or lenny++ change the > > way debian upgrades it's stable, just for the kernel? > > both things are already solved unofficially. there are kernel backports > [0], and kenshi makes stable-with-new-kernel installer-images[1]. > > so, basically, you are asking to make them (more) official now? basically yes. When a user approaches debian, goes to www.debian.org then follows the link to the distribution, grabs the iso, burns it and install it. when it does not fit ... he will say that debian does not support hardware foo (this can be truth) and goes for another distribution. Even, i don't know if the d-i images posted there have security updates. People know that a kernel that is debian supported is secure and bug free (or more bug free than others). So, if we loose security and stability ... why use debian? > > [0] http://www.backports.org/debian/pool/main/l/linux-2.6/ > [1] http://kmuto.jp/debian/d-i/ > > -- > Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist > Email: [EMAIL PROTECTED] > Internet: http://people.panthera-systems.net/~daniel-baumann/ > > -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Luis Matos wrote: > What i am saying is: is it possible to in a lenny or lenny++ change the > way debian upgrades it's stable, just for the kernel? both things are already solved unofficially. there are kernel backports [0], and kenshi makes stable-with-new-kernel installer-images[1]. so, basically, you are asking to make them (more) official now? [0] http://www.backports.org/debian/pool/main/l/linux-2.6/ [1] http://kmuto.jp/debian/d-i/ -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
