[gentoo-user] problem with firefox/libvpx
Hi. Well, I have run into a problem on the world update I am about to do? Firefox requires libvpx-1.7.0 and handbrake wants 8.x. Now there is a use flag systemlibvpx which is enabled, I am assuming if I disable that the great God of portage will let me continue with my update -- any reason why I should not do this? Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
On Fri, Feb 7, 2020 at 2:34 PM Michael Jones wrote: > > Here's an example of how 4.19.97 being stabilized might have exposed users to > functionality breaking bugs: https://bugs.gentoo.org/706036 > > Honestly I'd rather see the 30 day stabilization policy apply to LTS kernels > vs. being stabilized faster. Maybe I'm once bitten twice shy. One issue here is that the kernel upstream doesn't really consistently label kernels for bug criticality (including security bugs), or severity of regressions. So, in general any newer release should only make things better, but if a particular release made things much worse you'd only know from general discussion on high-volume lists. I follow upstream directly and just tend to hold off a day or two before updates, and look for signs of chatter before doing so. That is hardly optimal. A company like RedHat just hires a ton of kernel engineers to basically do their own QA on top of upstream's - they can stay on top of those sorts of problems. I'm sure the Gentoo kernel team does a better job than I personally do, but I doubt they can sink as much time as that. > As an aside: The gentoo bug tracker has way too many open bugs > (Thousands and thousands of them opened over 10 years ago), and the > search interface is... frustrating. Took me over 5 minutes to find > that bug despite being a commenter on it. Does anyone know if there's > any plans for that situation to change in any way? I doubt it, but the search interface is probably more likely to change than the number of open bugs. I mean, you could just close bugs without resolving them after a period of time. That would make the open bug counts look better, but it wouldn't change the actual quality of the distro, and would just tend to hide problems packages that are still in the repo. Obviously fixing bugs would be the ideal path, but we're volunteer driven, so that is up to the volunteers. I mean, we could just remove any package from the repo that has open bugs older than a certain time, but that seems likely to just end up with a repo without any packages in it. Unless the bugs have security implications or are causing impact to updates to other packages there usually isn't any policy requiring that they be fixed. I'm sure lots of people would be up for improving the UI, though that still requires volunteer work. Also, if the fix involves switching away from bugzilla that is a much bigger hurdle, and one challenge is that Gentoo doesn't like to host stuff written in Java/Ruby, which tends to exclude a lot of popular stuff. I don't sysadmin webservers for a living, so I won't comment on whether that policy is a good one or a bad one, but I suspect those behind it know a lot more about maintaining webservers than I do... -- Rich
Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
I'll start by saying that I appreciate all the work the Gentoo developers do, and by no means have any animosity for them for this, Here's an example of how 4.19.97 being stabilized might have exposed users to functionality breaking bugs: https://bugs.gentoo.org/706036 Took me several hours to figure out why several of my machines weren't working right. Honestly I'd rather see the 30 day stabilization policy apply to LTS kernels vs. being stabilized faster. Maybe I'm once bitten twice shy. As an aside: The gentoo bug tracker has way too many open bugs (Thousands and thousands of them opened over 10 years ago), and the search interface is... frustrating. Took me over 5 minutes to find that bug despite being a commenter on it. Does anyone know if there's any plans for that situation to change in any way? On Fri, Feb 7, 2020 at 11:56 AM Franz Fellner wrote: > That doesn't apply to the kernel. > 4.19.97 got tagged on January 17. > January 18. it was stable on amd64 and x86 - one day instead of 30. > Here is the stabilization request: https://bugs.gentoo.org/705006 > There were some issues and changes to the targeted versions. > > > Am Fr., 7. Feb. 2020 um 19:18 Uhr schrieb Mike Gilbert >: > >> On Thu, Feb 6, 2020 at 10:23 PM Matt Connell >> wrote: >> > >> > On 2020-02-06 11:40, Ian Zimmerman wrote: >> > > 5.4 has just become the newest LTS. >> > >> > I see that now. But my original question still stands as to why the >> > stable version of gentoo-sources is consistently a few versions behind >> > the latest LTS release. >> >> Typically, Gentoo maintainers leave new versions in ~arch for some >> time so they can be tested by a broad set of people. Stabilization >> bugs are normally not filed until a given version has spent at least >> 30 days in ~arch. >> >> See GLEP 40 for details on this process. >> >> https://www.gentoo.org/glep/glep-0040.html >> >>
Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
That doesn't apply to the kernel. 4.19.97 got tagged on January 17. January 18. it was stable on amd64 and x86 - one day instead of 30. Here is the stabilization request: https://bugs.gentoo.org/705006 There were some issues and changes to the targeted versions. Am Fr., 7. Feb. 2020 um 19:18 Uhr schrieb Mike Gilbert : > On Thu, Feb 6, 2020 at 10:23 PM Matt Connell > wrote: > > > > On 2020-02-06 11:40, Ian Zimmerman wrote: > > > 5.4 has just become the newest LTS. > > > > I see that now. But my original question still stands as to why the > > stable version of gentoo-sources is consistently a few versions behind > > the latest LTS release. > > Typically, Gentoo maintainers leave new versions in ~arch for some > time so they can be tested by a broad set of people. Stabilization > bugs are normally not filed until a given version has spent at least > 30 days in ~arch. > > See GLEP 40 for details on this process. > > https://www.gentoo.org/glep/glep-0040.html > >
Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
On Thu, Feb 6, 2020 at 10:23 PM Matt Connell wrote: > > On 2020-02-06 11:40, Ian Zimmerman wrote: > > 5.4 has just become the newest LTS. > > I see that now. But my original question still stands as to why the > stable version of gentoo-sources is consistently a few versions behind > the latest LTS release. Typically, Gentoo maintainers leave new versions in ~arch for some time so they can be tested by a broad set of people. Stabilization bugs are normally not filed until a given version has spent at least 30 days in ~arch. See GLEP 40 for details on this process. https://www.gentoo.org/glep/glep-0040.html
Re: [gentoo-user] Question about gentoo-sources kernel release versions
On Fri, 7 Feb 2020 at 06:19, Franz Fellner wrote: > > That article you linked to is about a variant of linux, "rt". And as it looks > they didn't update their branch since the release of 4.19.100-r41. > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/log/?h=v4.19-rt > linux is at 4.19.102 now... Just a note: that is a kind of "LTS" branch of the RT-kernels, the current one is 5.4.17-rt9 Regards, Arve
