Re: [gentoo-dev] rfc: hwclock service in OpenRC
On Sat, 15 Dec 2018 17:36:00 +0300 Andrew Savchenko wrote: > Yes, it is. CONFIG_RTC_HCTOSYS (and CONFIG_RTC_SYSTOHC) is > available in kernel for years and should be a preferred way to > handle the clock. > > Best regards, > Andrew Savchenko AFAIK those options still don’t work with RTCs set to local time, do they? Which, sadly, are required by anyone who dual-boots with a certain other OS made by Microsoft? So hwclock will still be needed for many people—perhaps kernel support should be the default, but a painless migration path for those who need to keep using hwclock would be appropriate (if any migration is even needed—I’m unclear on whether hwclock would be removed from the boot runlevel on existing installs or only not added on new installs). -- Christopher Head pgp9kI8u8utDp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: hwclock service in OpenRC
Hi! On Thu, 13 Dec 2018 12:18:26 -0600 William Hubbs wrote: > All, > > the hwclock service is Linux specific, so all of this applies only to > OpenRC on Linux. > > OpenRC currently adds the hwclock service to the boot runlevel upstream. > The linux kernel also has had a way for some time to handle the clock > itself if you have an RTC. > > Is it reasonable to stop adding the hwclock service to the boot runlevel > upstream and documenting the options and asking users to make that > choice? Yes, it is. CONFIG_RTC_HCTOSYS (and CONFIG_RTC_SYSTOHC) is available in kernel for years and should be a preferred way to handle the clock. Best regards, Andrew Savchenko pgpg2tlANZzJC.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] adding more entries to profiles/info_pkgs
On 15.12.2018 5:00, Georgy Yakovlev wrote: > Hi, > > while lurking on bugzilla lately I noticed that package part of > "emerge --info" output may be lacking in some cases. > > Good candidates for adding to that file are: > > virtual/rust > llvm ? > dev-util/meson > dev-util/ninja > > that should be enough to provide a bit more to initial information without > going crazy and clobbering output too much. > > Thoughts? > > Regards, > Georgy Yakovlev > Gentoo Linux Developer They all are not way too much spread, especially rust. Do not think it worth to include them. meson can be reconsidered later, as more and more people are using this one. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d
On Fri, 14 Dec 2018 15:04:22 +0100 Jeroen Roovers wrote: > According to Nvidia these are former "Short Lived" branches that are no > longer supported. > > > # Jeroen Roovers (14 Dec 2018) > # Deprecated short lived branches > # https://www.nvidia.com/object/unix.html > # File a bug report if you need to use one of these > # Removal on or about 14 January 2019 > =x11-drivers/nvidia-drivers-375* > =x11-drivers/nvidia-drivers-378* > =x11-drivers/nvidia-drivers-381* > =x11-drivers/nvidia-drivers-384* > =x11-drivers/nvidia-drivers-387* > =x11-drivers/nvidia-drivers-396* I personally have a 540M, for which the "newest" supporting drivers are 396.18 But I'm not gonna block this, I'm just irate with the status quo upstream is delivering. Noveau support is just as flaky and so my only option is "hey, just stop using video acceleration", which, amongst other things, makes video conferencing impossible. So I'm not going to cite Linus'es opinions on Nvidia verbatim here, but if you know what they are, well, pretend I did :) ( And please, no nonsense about upgrading hardware, unlike upgrading software, upgrading hardware isn't free ) pgpV_WMd5IsBv.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] adding more entries to profiles/info_pkgs
On Fri, 14 Dec 2018 18:00:55 -0800 Georgy Yakovlev wrote: > Good candidates for adding to that file are: > > virtual/rust > llvm ? > dev-util/meson > dev-util/ninja I'm really not sure these are widespread enough to justify putting those details in the ouput of every emerge --info. Instead, it seems to make more sense to have them displayed via the pkg_info() function[1], which can be provided by eclasses where need be. 1: https://devmanual.gentoo.org/ebuild-writing/functions/pkg_info/index.html pgpZaUwWdfHFB.pgp Description: OpenPGP digital signature
