Re: [gentoo-dev] Gentoo-sources - should we stable?
On Fri, Jan 2, 2015 at 5:52 PM, Diamond wrote: > On Fri, 02 Jan 2015 12:25:56 -0500 > Mike Pagano wrote: > >> Kernel versions are coming out 1-2 a week at this point. > > There's also a problem to upgrade kernel for a user every 1-2 week by > hands using "make oldconfig" and reading smth like > kernelnewbies.org/LinuxChanges. Not everyone uses genkernel. > If you're sticking with a stable kernel branch, especially a longterm one, make oldconfig is about all there is to it - most likely you won't get even a single prompt. If you're paranoid you can read the changes, but they're called stable for a reason. When you move between branches then there is of course more work. -- Rich
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Fri, 02 Jan 2015 12:25:56 -0500 Mike Pagano wrote: > Are there solid arguments for stabilizing any version of > gentoo-sources? I think the valid arguments for not stabilizing > gentoo-sources can be garnered from the thread about not stabilizing > vanilla-sources[1]. > > This is in no way complaining about how long it takes to stabilize a > kernel. It's just a fact that by the time we do stabilizing one, > there might be many, many kernel versions released for that 3.X > branch that contains security fixes for which the stable version will > not have. Kernel versions are coming out 1-2 a week at this point. There's also a problem to upgrade kernel for a user every 1-2 week by hands using "make oldconfig" and reading smth like kernelnewbies.org/LinuxChanges. Not everyone uses genkernel.
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Saturday, January 03, 2015 12:39:39 AM Mikle Kolyada wrote: > 02.01.2015 20:25, Mike Pagano пишет: > > This is in no way complaining about how long it takes to stabilize a > > kernel. > As for this fact. > > > > The main problem is that: we only can test sources on machine we can > reboot. For example me and Agostino > have access to the rest hardware like alpha, ia64 and so on. But we > can't reboot it for clear reason i think. > Another side is that: not all hardware i have around can use > gentoo-sources, so it works with custom kernels. > > Mikle, Let me reiterate. This should be in no way interpreted as an attack on the arch teams. I'm getting more and more constrained by life and slacking like crazy, so I would never complain about the amount of time other volunteers put into this distribution. AFAIC, you definitely don't need to defend the arch teams whom I respect and whose efforts I greatly appreciate. Mike -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] Gentoo-sources - should we stable?
02.01.2015 20:25, Mike Pagano пишет: > This is in no way complaining about how long it takes to stabilize a kernel. As for this fact. The main problem is that: we only can test sources on machine we can reboot. For example me and Agostino have access to the rest hardware like alpha, ia64 and so on. But we can't reboot it for clear reason i think. Another side is that: not all hardware i have around can use gentoo-sources, so it works with custom kernels.
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Friday, January 02, 2015 04:05:42 PM Rich Freeman wrote: > On Fri, Jan 2, 2015 at 3:44 PM, Mike Pagano wrote: > > To summarize. > > > > In this instance, as this moment: > > > > 1. Only enter stable req bugs for 3.18 and 3.17. > > I assume this bit is just a transition since we don't want to > downgrade from 3.17/18 to 3.14, and that once we get the next longterm > we'll just follow that? If we kept doing delayed stablereqs on the > latest stable then users are going to tend to be behind on the fixes > just as they are today since they won't run longterm by default. I would not "destabilize" 3.17 (or anything for that matter). So those people would not be affected. > > 2. Once they enter LTS, then auto stable going forward. > > 3. At this moment, auto stable 3.14, 3.12, 3.10 and 3.4. > > ++ > > > If this is what you're saying, this would make things much better for me > > and better for our users. > > > > Who needs to bless this? Council, Arch Teams, Rich0, God, my dog? > > Not that it means anything, but you have a +4 from me and my cats > (just be happy I don't let them post here - FYI they're easily bribed > with food). Good news, I wasn't sure if I should CC them or not. > I'd suggest that the kernel maintainers can "just do it" if there is > no objection after a few days. Escalation is for when there is > disagreement. That sounds like good advice. -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Fri, Jan 2, 2015 at 3:44 PM, Mike Pagano wrote: > To summarize. > > In this instance, as this moment: > > 1. Only enter stable req bugs for 3.18 and 3.17. I assume this bit is just a transition since we don't want to downgrade from 3.17/18 to 3.14, and that once we get the next longterm we'll just follow that? If we kept doing delayed stablereqs on the latest stable then users are going to tend to be behind on the fixes just as they are today since they won't run longterm by default. > 2. Once they enter LTS, then auto stable going forward. > 3. At this moment, auto stable 3.14, 3.12, 3.10 and 3.4. ++ > > If this is what you're saying, this would make things much better for me and > better for our users. > > Who needs to bless this? Council, Arch Teams, Rich0, God, my dog? > Not that it means anything, but you have a +4 from me and my cats (just be happy I don't let them post here - FYI they're easily bribed with food). I'd suggest that the kernel maintainers can "just do it" if there is no objection after a few days. Escalation is for when there is disagreement. -- Rich
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Friday, January 02, 2015 03:30:40 PM Rich Freeman wrote: > On Fri, Jan 2, 2015 at 3:11 PM, Ian Stakenvicius wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On 02/01/15 02:57 PM, Mike Pagano wrote: > >> I understand your point. Maybe waiting a few days to auto stable > >> makes sense, because less than 7 days later, a new version with > >> bug/security fixes is released. > >> > >> Isn't our current rate of stabilization "selling" a promise of > >> stability we can't stand behind? > >> > >> Mike > > > > Well to be perfectly honest, the current-stable 3.16 and 3.17 kernels > > for me at least have some rather unfortunate regressions over 3.15 and > > previous, so even with the stabilization we're achieving now I don't > > think we're living up to our "promise of stability" :) > > As a btrfs user I went through quite a bit of pain in the whole > 3.15-17 series, but I that probably isn't a typical mainstream user > experience. This sort of thing was why I did suggest targeting > longterm. When the next longterm is announced then we could > transition to it at our leisure (ie with plenty of testing while > following point releases quickly on the previous longterm). > > So, moving between longterm branches would have a more typical Gentoo > QA process. However, between point releases within a branch we would > auto-stable releases, since it is unlikely that our own QA process is > going to add any real value beyond what upstream already does. > > We also need to keep in mind just what our "promise of stability" even > means. We're not a release-based distro, and we're NEVER going to > offer an experience like RHEL or Debian Stable where the entirety of > the package base is pinned and tested and we only do security > backports. The kernel stable branches probably represent a lot more > stability than we have almost anywhere else in the distro anyway. We have had a lot of stable kernels with a not-so-stable btrfs. That's a whole conversation in itself. There are pieces of the kernel that are in a, shall we say, less stable state than others. -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Friday, January 02, 2015 03:22:31 PM Ian Stakenvicius wrote: > On 02/01/15 03:17 PM, Mike Pagano wrote: > > On Friday, January 02, 2015 03:11:22 PM Ian Stakenvicius wrote: > >> On 02/01/15 02:57 PM, Mike Pagano wrote: > >>> I understand your point. Maybe waiting a few days to auto > >>> stable makes sense, because less than 7 days later, a new > >>> version with bug/security fixes is released. > >>> > >>> Isn't our current rate of stabilization "selling" a promise of > >>> stability we can't stand behind? > >>> > >>> Mike > >> > >> Well to be perfectly honest, the current-stable 3.16 and 3.17 > >> kernels for me at least have some rather unfortunate regressions > >> over 3.15 and previous, so even with the stabilization we're > >> achieving now I don't think we're living up to our "promise of > >> stability" :) > > > > Exactly. It may give people a warm fuzzy feeling, but it's not > > like other packages. > > I agree; and also with Rich. > > It might be a good idea to avoid stabilization of versions other than > the LTS ones, ie let users that want anything newer than a (at this > time of writing) 3.14 kernel use keywords to get them, and > direct-to-stable gentoo-sources packages for 3.14, 3.12, 3.10 > (probably with a 'genkernel kernel' test run on at least one arch > first to make sure this doesn't break for the really lazy user). Then > major dev work related to gentoo-sources stabilization is just in > preparation for the next longterm release. > Would that workflow still be too much for the current gentoo-sources > maintainers? Hi, that's only me. :) FYI, I do a compile/boot test on amd64 for every kernel I put out there. OK, I don't hate this idea. To summarize. In this instance, as this moment: 1. Only enter stable req bugs for 3.18 and 3.17. 2. Once they enter LTS, then auto stable going forward. 3. At this moment, auto stable 3.14, 3.12, 3.10 and 3.4. If this is what you're saying, this would make things much better for me and better for our users. Who needs to bless this? Council, Arch Teams, Rich0, God, my dog? Mike -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Fri, Jan 2, 2015 at 3:11 PM, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 02/01/15 02:57 PM, Mike Pagano wrote: >> >> I understand your point. Maybe waiting a few days to auto stable >> makes sense, because less than 7 days later, a new version with >> bug/security fixes is released. >> >> Isn't our current rate of stabilization "selling" a promise of >> stability we can't stand behind? >> >> Mike >> > > Well to be perfectly honest, the current-stable 3.16 and 3.17 kernels > for me at least have some rather unfortunate regressions over 3.15 and > previous, so even with the stabilization we're achieving now I don't > think we're living up to our "promise of stability" :) > As a btrfs user I went through quite a bit of pain in the whole 3.15-17 series, but I that probably isn't a typical mainstream user experience. This sort of thing was why I did suggest targeting longterm. When the next longterm is announced then we could transition to it at our leisure (ie with plenty of testing while following point releases quickly on the previous longterm). So, moving between longterm branches would have a more typical Gentoo QA process. However, between point releases within a branch we would auto-stable releases, since it is unlikely that our own QA process is going to add any real value beyond what upstream already does. We also need to keep in mind just what our "promise of stability" even means. We're not a release-based distro, and we're NEVER going to offer an experience like RHEL or Debian Stable where the entirety of the package base is pinned and tested and we only do security backports. The kernel stable branches probably represent a lot more stability than we have almost anywhere else in the distro anyway. -- Rich
Re: [gentoo-dev] Gentoo-sources - should we stable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/01/15 03:17 PM, Mike Pagano wrote: > On Friday, January 02, 2015 03:11:22 PM Ian Stakenvicius wrote: >> On 02/01/15 02:57 PM, Mike Pagano wrote: >>> I understand your point. Maybe waiting a few days to auto >>> stable makes sense, because less than 7 days later, a new >>> version with bug/security fixes is released. >>> >>> Isn't our current rate of stabilization "selling" a promise of >>> stability we can't stand behind? >>> >>> Mike >> >> Well to be perfectly honest, the current-stable 3.16 and 3.17 >> kernels for me at least have some rather unfortunate regressions >> over 3.15 and previous, so even with the stabilization we're >> achieving now I don't think we're living up to our "promise of >> stability" :) > > Exactly. It may give people a warm fuzzy feeling, but it's not > like other packages. > I agree; and also with Rich. It might be a good idea to avoid stabilization of versions other than the LTS ones, ie let users that want anything newer than a (at this time of writing) 3.14 kernel use keywords to get them, and direct-to-stable gentoo-sources packages for 3.14, 3.12, 3.10 (probably with a 'genkernel kernel' test run on at least one arch first to make sure this doesn't break for the really lazy user). Then major dev work related to gentoo-sources stabilization is just in preparation for the next longterm release. Would that workflow still be too much for the current gentoo-sources maintainers? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlSm/gYACgkQ2ugaI38ACPC8KgEAp57inwfpkk7O3IewDlUOt3ga QL6vcX630xaismVyrCYBALUR2e+zTtvbxXMJLsJoXWxFGJCCeSvB6rV2yH85gJnW =pnlH -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Friday, January 02, 2015 03:11:22 PM Ian Stakenvicius wrote: > On 02/01/15 02:57 PM, Mike Pagano wrote: > > I understand your point. Maybe waiting a few days to auto stable > > makes sense, because less than 7 days later, a new version with > > bug/security fixes is released. > > > > Isn't our current rate of stabilization "selling" a promise of > > stability we can't stand behind? > > > > Mike > > Well to be perfectly honest, the current-stable 3.16 and 3.17 kernels > for me at least have some rather unfortunate regressions over 3.15 and > previous, so even with the stabilization we're achieving now I don't > think we're living up to our "promise of stability" :) Exactly. It may give people a warm fuzzy feeling, but it's not like other packages. -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] Gentoo-sources - should we stable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/01/15 02:57 PM, Mike Pagano wrote: > > I understand your point. Maybe waiting a few days to auto stable > makes sense, because less than 7 days later, a new version with > bug/security fixes is released. > > Isn't our current rate of stabilization "selling" a promise of > stability we can't stand behind? > > Mike > Well to be perfectly honest, the current-stable 3.16 and 3.17 kernels for me at least have some rather unfortunate regressions over 3.15 and previous, so even with the stabilization we're achieving now I don't think we're living up to our "promise of stability" :) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlSm+2oACgkQ2ugaI38ACPD88QD+IX23em/uE3v7lpuuKnWvGDRR hMeVG1U+1NtdKp87Kr0A/jE2byckqz2eNgp8DwUE4fgOwI8lZACpafB1vcdPyWcQ =yAXA -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Friday, January 02, 2015 02:18:24 PM Rich Freeman wrote: > On Fri, Jan 2, 2015 at 1:10 PM, Ian Stakenvicius wrote: > > The thing about stable gentoo-sources is that it shows that it's been > > tested, and ideally that testing's been done against the rdeps of the > > kernel package too (ie, external modules). ... > > That said, given the frequency of security updates, I do think it > > makes sense to try and keep the stabilization of LTS kernel versions > > in sync with upstream as much as possible, including > > quick-stabilization whenever we can. > > ++ and ++ > > Would an approach like this make sense: > 1. For ~arch keep doing what we're doing (which seems to be generally > following the upstream stable branches). > 2a. For stable always target the latest longterm, and commit straight > to stable. > or > 2b. For stable just follow ~arch a few days behind. > 3. Either way immediately remove packages that aren't > upstream-supported (by all means keep all the longterm/stable > branches, but don't leave cruft hanging around or abandoned stable > branches - if somebody ~arch tagged a particular branch and didn't get > the news that it won't go longterm then they'll either downgrade to a > supported stable or notice and adjust their keywords to go to the next > stable). > > 2a is extremely unlikely to break anything, but probably won't get any > testing so you might as well commit straight to stable (nobody running > ~arch is going to be running longterm as well). 2b is more likely to > break stuff, but on the other hand will be more likely to have actual > bugs reported so it will be more tested. > > The biggest issue I see is with packages that actually use recent > kernel features (systemd comes to mind, maybe udev to a lesser degree, > and I'm sure there are others). These kinds of packages should have > clear kernel dependencies though. In some sense EVERYTHING is an rdep > of the kernel so breakage could conceivably happen anywhere - but the > risk is higher in some places. > > I think the classical stable user is probably best off following > upstream longterm anyway, unless they just bought a new laptop or > something like that. > > In general though I think that it is perfectly acceptable to have a QA > policy specific to the kernel since upstream has very robust stable > branch support, and the level of QA and release maturity is extremely > high. > > I do think that it makes sense to not throw stable Gentoo users at > kernels that were mainline release candidates only a day before. I understand your point. Maybe waiting a few days to auto stable makes sense, because less than 7 days later, a new version with bug/security fixes is released. Isn't our current rate of stabilization "selling" a promise of stability we can't stand behind? Mike -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Friday, January 02, 2015 01:10:21 PM Ian Stakenvicius wrote: Resending as I replied to Ian instead of the list by accident. (sorry, Ian) > On 02/01/15 12:25 PM, Mike Pagano wrote: > > Hello, Everyone, > > > > Are there solid arguments for stabilizing any version of > > gentoo-sources? I think the valid arguments for not stabilizing > > gentoo-sources can be garnered from the thread about not > > stabilizing vanilla-sources[1]. > > > > This is in no way complaining about how long it takes to stabilize > > a kernel. It's just a fact that by the time we do stabilizing one, > > there might be many, many kernel versions released for that 3.X > > branch that contains security fixes for which the stable version > > will not have. Kernel versions are coming out 1-2 a week at this > > point. > > > > I feel we are giving users a false sense of security, and maybe it > > would be better for them to upgrade faster than they are doing now > > if they are only using stable kernels. > > > > Having stable kernels around keeps me from deleting these old, > > potentially vulnerable releases.[2] > > > > Mike > > > > [1] http://marc.info/?l=gentoo-kernel&m=137182668616082&w=2 [2] > > http://packages.gentoo.org/package/sys-kernel/gentoo-sources > > The thing about stable gentoo-sources is that it shows that it's been > tested, and ideally that testing's been done against the rdeps of the > kernel package too (ie, external modules). For instance, I like that > I can generally expect vbox-modules and tp_smapi and bbswitch to > emerge against whatever the current-stable gentoo-sources kernel is, > whereas with the ~arch one(s) I don't hold any such expectation > (although it's nice when it does). You should *definitely* not assume out of kernel modules are stable (or even compile, install or run) on any stable version. Kernel stabilization has never been held up by out of kernel modules. They are not part of the decision on whether or not a kernel should be stabilized. > Similarly, when there are known functionality issues that do not have > an upstream fix (nor one scheduled for some time), like say, intel drm > being broken except for ~arch or - xorg/libdrm/xf86-video-intel , > I think it's pertinent that the newer versions stay ~arch until a fix > is developed and available -- the stable kernel being pegged at 3.4.9 > for a long time is a good example of this. Some Arch members have told me that stabilizing kernel does not include much more than a compile and boot test. Some run it for a few days, but the mixture of hardware and versions out there really precludes an all encompassing blessing. > That said, given the frequency of security updates, I do think it > makes sense to try and keep the stabilization of LTS kernel versions > in sync with upstream as much as possible, including > quick-stabilization whenever we can. Hopefully those security > backports don't usually change functionality and features much, > although if they do then perhaps we need to hold off on their > stabilization for a little while too.. And that is the problem. We can't keep up and still with a straight face tell user's *this* is the kernel you should run. > Makes sense or am I way off base? Thanks for responding, MIke -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Fri, Jan 2, 2015 at 1:10 PM, Ian Stakenvicius wrote: > > The thing about stable gentoo-sources is that it shows that it's been > tested, and ideally that testing's been done against the rdeps of the > kernel package too (ie, external modules). ... > That said, given the frequency of security updates, I do think it > makes sense to try and keep the stabilization of LTS kernel versions > in sync with upstream as much as possible, including > quick-stabilization whenever we can. ++ and ++ Would an approach like this make sense: 1. For ~arch keep doing what we're doing (which seems to be generally following the upstream stable branches). 2a. For stable always target the latest longterm, and commit straight to stable. or 2b. For stable just follow ~arch a few days behind. 3. Either way immediately remove packages that aren't upstream-supported (by all means keep all the longterm/stable branches, but don't leave cruft hanging around or abandoned stable branches - if somebody ~arch tagged a particular branch and didn't get the news that it won't go longterm then they'll either downgrade to a supported stable or notice and adjust their keywords to go to the next stable). 2a is extremely unlikely to break anything, but probably won't get any testing so you might as well commit straight to stable (nobody running ~arch is going to be running longterm as well). 2b is more likely to break stuff, but on the other hand will be more likely to have actual bugs reported so it will be more tested. The biggest issue I see is with packages that actually use recent kernel features (systemd comes to mind, maybe udev to a lesser degree, and I'm sure there are others). These kinds of packages should have clear kernel dependencies though. In some sense EVERYTHING is an rdep of the kernel so breakage could conceivably happen anywhere - but the risk is higher in some places. I think the classical stable user is probably best off following upstream longterm anyway, unless they just bought a new laptop or something like that. In general though I think that it is perfectly acceptable to have a QA policy specific to the kernel since upstream has very robust stable branch support, and the level of QA and release maturity is extremely high. I do think that it makes sense to not throw stable Gentoo users at kernels that were mainline release candidates only a day before. -- Rich
Re: [gentoo-dev] Gentoo-sources - should we stable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/01/15 12:25 PM, Mike Pagano wrote: > Hello, Everyone, > > Are there solid arguments for stabilizing any version of > gentoo-sources? I think the valid arguments for not stabilizing > gentoo-sources can be garnered from the thread about not > stabilizing vanilla-sources[1]. > > This is in no way complaining about how long it takes to stabilize > a kernel. It's just a fact that by the time we do stabilizing one, > there might be many, many kernel versions released for that 3.X > branch that contains security fixes for which the stable version > will not have. Kernel versions are coming out 1-2 a week at this > point. > > I feel we are giving users a false sense of security, and maybe it > would be better for them to upgrade faster than they are doing now > if they are only using stable kernels. > > Having stable kernels around keeps me from deleting these old, > potentially vulnerable releases.[2] > > Mike > > [1] http://marc.info/?l=gentoo-kernel&m=137182668616082&w=2 [2] > http://packages.gentoo.org/package/sys-kernel/gentoo-sources The thing about stable gentoo-sources is that it shows that it's been tested, and ideally that testing's been done against the rdeps of the kernel package too (ie, external modules). For instance, I like that I can generally expect vbox-modules and tp_smapi and bbswitch to emerge against whatever the current-stable gentoo-sources kernel is, whereas with the ~arch one(s) I don't hold any such expectation (although it's nice when it does). Similarly, when there are known functionality issues that do not have an upstream fix (nor one scheduled for some time), like say, intel drm being broken except for ~arch or - xorg/libdrm/xf86-video-intel , I think it's pertinent that the newer versions stay ~arch until a fix is developed and available -- the stable kernel being pegged at 3.4.9 for a long time is a good example of this. That said, given the frequency of security updates, I do think it makes sense to try and keep the stabilization of LTS kernel versions in sync with upstream as much as possible, including quick-stabilization whenever we can. Hopefully those security backports don't usually change functionality and features much, although if they do then perhaps we need to hold off on their stabilization for a little while too.. Makes sense or am I way off base? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlSm3w0ACgkQ2ugaI38ACPDpKQD+Jh6MwY3wZaITArse7lgUZRIU 7EEYotPicjMFdXXY9PgA/ROwIl9zfstub3RxucyWQKuvm9GC9Xwd7TfIs14WOPT4 =tpMN -END PGP SIGNATURE-
[gentoo-dev] Gentoo-sources - should we stable?
Hello, Everyone, Are there solid arguments for stabilizing any version of gentoo-sources? I think the valid arguments for not stabilizing gentoo-sources can be garnered from the thread about not stabilizing vanilla-sources[1]. This is in no way complaining about how long it takes to stabilize a kernel. It's just a fact that by the time we do stabilizing one, there might be many, many kernel versions released for that 3.X branch that contains security fixes for which the stable version will not have. Kernel versions are coming out 1-2 a week at this point. I feel we are giving users a false sense of security, and maybe it would be better for them to upgrade faster than they are doing now if they are only using stable kernels. Having stable kernels around keeps me from deleting these old, potentially vulnerable releases.[2] Mike [1] http://marc.info/?l=gentoo-kernel&m=137182668616082&w=2 [2] http://packages.gentoo.org/package/sys-kernel/gentoo-sources -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
[gentoo-dev] New sysfs based battery monitor widget for kde
Hi, I had some time to resolve the long outstanding issue I had with loosing upower to systemd. The only feature I personally had was the battery monitor stopped working, yes, I did not install pm-utils either... So after few times my battery went empty while I worked... decided that enough is enough and I need to learn how to write kde plasmoid. Documentation of kde plasmoid is not great, especially when using scripts, but after looking on various of valid examples, I managed to produce a new battery monitor[1][2] which is very simple and looks decent. All that it does is once per interval read the /status and /capacity and update the images within widget, it does not create a load nor adds dependencies. Install to user home by: $ plasmapkg -i kbatsysfs-1.0.0.plasmoid I hope someone will find this useful, Alon [1] http://kde-apps.org/content/show.php/kbatsysfs?content=168436 [2] https://github.com/alonbl/kbatsysfs
