Re: [gentoo-user] Is there a way to list orphaned services?
On Thu, 12 Dec 2019 16:52:21 -0800, Daniel Frey wrote: > I've been merging/unmerging packages for testing and some have to be > started via a daemon, so I've had to add them to /etc/runlevels/* via > rc-update. > > The problem is I was removing packages without doing `rc-update del > `, leaving them added in the runlevel with no valid > script/symlink. > > Now, I could just do `ls -al /etc/runlevels/*` and search manually for > broken symlinks and then manually remove them. How about: find -L /etc/runlevels -type l -- Neil Bothwick Every morning is the dawn of a new error... pgpvJRTeJ9SCq.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Emerge and CPU core usage
Howdy, I don't recall seeing the thread on the forums but it sort of sounds a lot like what I was reading on -dev as to why it is not. Basically, it would be a complex and difficult piece of code. According to some, it could even create problems that don't exist now, depending on what dependencies may pop into the process. It would be nice IF it could be done and really help with the time it takes to calculate but it sounds like it might not even help much if it was coded that way. I guess it won't be done anytime soon. It seems like for good reason but it would be nifty. I might add, I think that forum thread was way earlier than the posts on -dev. I think the discussion on -dev was only a few years ago. All in all, the emerge command has come a long ways since I started uses Gentoo back in 2003. Thanks for the info. Dale :-) :-) Woohyung Jeon wrote: > I can't be sure whether these links will help, but there were conversations. > > https://forums.gentoo.org/viewtopic-t-866779-start-0.html > https://www.reddit.com/r/Gentoo/comments/68psrz/why_does_emerge_calculate_dependencies_on_a/ > > On Fri, Dec 13, 2019 at 6:44 AM Dale wrote: >> james wrote: >>> On 12/9/19 1:31 AM, Dale wrote: Howdy, I'm sure trying to get portage to do things in parallel would be a programmers nightmare.� It may not even be doable given how the tree is done or that the complexity of calculating all the options is just to much to run in parallel. >>> Hello Dale, >>> >>> Not sure this is what you are looking for, but it's pretty easy to set >>> up. >>> >>> >>> in my /etc/make.conf file I have this:: >>> >>> >>> MAKEOPTS="-j7 -l8" >>> >>> >>> so it does what you are looking for on larger upgrades. Some files >>> that do not compile properly, auto limit to one core. My understanding >>> is there are a variety of mechanism to achieve this. >>> >>> The kernel version/setting surely has more options, but they are >>> optimized according to the types of workloads and the scheduler you >>> have selected. YOU or anyone can waist weeks and months going down >>> that pathway. >>> >>> Then there are mechanisms to further refine how your system works. >>> >>> >>> It's a wide open area so read up a bit and find your comfort level. >>> >>> >>> hth, >>> James >>> >>> >> >> I have that type of setting already. What I was talking about is when >> you do a emerge -uaDN world and it is calculating what packages needs >> updating. When it is doing that, it only uses one core, thread I guess >> for those who have threads, which means having a multi-core CPU doesn't >> help speed things up. Basically, my question was about the emerge >> command itself not when it is actually compiling packages. >> >> I read where it was discussed on -dev a couple years or so ago. I'm not >> a coder but from what I could understand, it sounded really complicated >> to have the emerge command able to run calculations in parallel. It >> seems there is a couple things that just can not be done that way. >> >> Maybe one day. Just maybe. >> >> Dale >> >> :-) :-) >> >
Re: [gentoo-user] Emerge and CPU core usage
I can't be sure whether these links will help, but there were conversations. https://forums.gentoo.org/viewtopic-t-866779-start-0.html https://www.reddit.com/r/Gentoo/comments/68psrz/why_does_emerge_calculate_dependencies_on_a/ On Fri, Dec 13, 2019 at 6:44 AM Dale wrote: > > james wrote: > > On 12/9/19 1:31 AM, Dale wrote: > >> Howdy, > >> > > > >> I'm sure trying to get portage to do things in parallel would be a > >> programmers nightmare.� It may not even be doable given how the > >> tree is > >> done or that the complexity of calculating all the options is just to > >> much to run in parallel. > > > > Hello Dale, > > > > Not sure this is what you are looking for, but it's pretty easy to set > > up. > > > > > > in my /etc/make.conf file I have this:: > > > > > > MAKEOPTS="-j7 -l8" > > > > > > so it does what you are looking for on larger upgrades. Some files > > that do not compile properly, auto limit to one core. My understanding > > is there are a variety of mechanism to achieve this. > > > > The kernel version/setting surely has more options, but they are > > optimized according to the types of workloads and the scheduler you > > have selected. YOU or anyone can waist weeks and months going down > > that pathway. > > > > Then there are mechanisms to further refine how your system works. > > > > > > It's a wide open area so read up a bit and find your comfort level. > > > > > > hth, > > James > > > > > > > I have that type of setting already. What I was talking about is when > you do a emerge -uaDN world and it is calculating what packages needs > updating. When it is doing that, it only uses one core, thread I guess > for those who have threads, which means having a multi-core CPU doesn't > help speed things up. Basically, my question was about the emerge > command itself not when it is actually compiling packages. > > I read where it was discussed on -dev a couple years or so ago. I'm not > a coder but from what I could understand, it sounded really complicated > to have the emerge command able to run calculations in parallel. It > seems there is a couple things that just can not be done that way. > > Maybe one day. Just maybe. > > Dale > > :-) :-) > -- WooHyung Jeon.
[gentoo-user] Is there a way to list orphaned services?
Subject kind of says it all... I was reading manpages and I don't think there's a way, so I thought I'd ask. I've been merging/unmerging packages for testing and some have to be started via a daemon, so I've had to add them to /etc/runlevels/* via rc-update. The problem is I was removing packages without doing `rc-update del `, leaving them added in the runlevel with no valid script/symlink. Now, I could just do `ls -al /etc/runlevels/*` and search manually for broken symlinks and then manually remove them. It seems that `rc-update -a` parses /etc/init.d/* and looks for matching symlinks in /etc/runlevels, but not the other way around. It looks like rc-update has a "-a" parameter that deals with broken symlinks but it still requires a service name which is not listed any more in /etc/init.d. I did test this, `rc-update -v show` did not show NetworkManager (which I'd removed. Manual inspection of /etc/runlevels showed a broken link. I then ran `rc-update del NetworkManager default`, which worked even though it isn't listed in the rc-update output. Or am I overthinking things? Or maybe I'm just getting too tired to think about this. :o) Dan
Re: [gentoo-user] Emerge and CPU core usage
james wrote: > On 12/9/19 1:31 AM, Dale wrote: >> Howdy, >> > >> I'm sure trying to get portage to do things in parallel would be a >> programmers nightmare.� It may not even be doable given how the >> tree is >> done or that the complexity of calculating all the options is just to >> much to run in parallel. > > Hello Dale, > > Not sure this is what you are looking for, but it's pretty easy to set > up. > > > in my /etc/make.conf file I have this:: > > > MAKEOPTS="-j7 -l8" > > > so it does what you are looking for on larger upgrades. Some files > that do not compile properly, auto limit to one core. My understanding > is there are a variety of mechanism to achieve this. > > The kernel version/setting surely has more options, but they are > optimized according to the types of workloads and the scheduler you > have selected. YOU or anyone can waist weeks and months going down > that pathway. > > Then there are mechanisms to further refine how your system works. > > > It's a wide open area so read up a bit and find your comfort level. > > > hth, > James > > I have that type of setting already. What I was talking about is when you do a emerge -uaDN world and it is calculating what packages needs updating. When it is doing that, it only uses one core, thread I guess for those who have threads, which means having a multi-core CPU doesn't help speed things up. Basically, my question was about the emerge command itself not when it is actually compiling packages. I read where it was discussed on -dev a couple years or so ago. I'm not a coder but from what I could understand, it sounded really complicated to have the emerge command able to run calculations in parallel. It seems there is a couple things that just can not be done that way. Maybe one day. Just maybe. Dale :-) :-)
Re: [gentoo-user] Emerge and CPU core usage
On 12/9/19 1:31 AM, Dale wrote: Howdy, I'm sure trying to get portage to do things in parallel would be a programmers nightmare.� It may not even be doable given how the tree is done or that the complexity of calculating all the options is just to much to run in parallel. Hello Dale, Not sure this is what you are looking for, but it's pretty easy to set up. in my /etc/make.conf file I have this:: MAKEOPTS="-j7 -l8" so it does what you are looking for on larger upgrades. Some files that do not compile properly, auto limit to one core. My understanding is there are a variety of mechanism to achieve this. The kernel version/setting surely has more options, but they are optimized according to the types of workloads and the scheduler you have selected. YOU or anyone can waist weeks and months going down that pathway. Then there are mechanisms to further refine how your system works. It's a wide open area so read up a bit and find your comfort level. hth, James
Re: [gentoo-user] XDM Start Faster
On Mon, 9 Dec 2019 22:27:40 + jdm wrote: > Hi, > > Over the last couple of weeks my wifi connection net.wlp5s0 doesn't > see to want to connect at boot up (It used to be very fast but now > taking 1min +). Therefore XDM (login screen slim) takes a long time > to start up. And LXD daemon doesn't start at all. > > I have my rc.conf set to rc_parallel="YES" but if I set this to "NO" > then clamd seems to take an age to start up as well as the wireless. > > Is there a way I can get XDM to start quicker and leave the other > services to start up whilst logging in. I can then set rc_parrallel to > "NO" which I hope should ensure LXD starts correctly. > > It's only a minor gripe but feels like it's taking a long time to > login. At least if I can get into desktop I can change wallpaper, > themes and icons whilst my wireless decides to get a grip. > > Thanks > John > After some testing this looks like a kernel problem. I updated kernel to 4.19.86 and keep getting slow start up of wireless card during boot process. Revert back to 4.19.82 and have no issues and PC keeps booting in very fast time. Think I'll try something newer as they must have done some wirless network ath9k updates to 86. Deep joy. If it ain't broke don't fix it. But maybe is for someone else. John
Re: [gentoo-user] Kernel panic on 5.4.2 - not sure of cause yet
On 2019-12-10 21:31, Andrew Udvare wrote: I have been getting relatively consistent kernel panics on some call to find_css_set and sometimes a stack trace that mentions cgroups. On 5.4.0 I don't get this same crash and I added blocking of auto-loading nvidia under the ramdisk just in case that's the issue, as I was sometimes getting a similar crash on 5.4.0. /etc/default/grub: GRUB_PRELOAD_MODULES=lvm GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd systemd.legacy_systemd_cgroup_controller=yes rd.driver.blacklist=nvidia rd.driver.blacklist=nvidia_modeset rd.driver.blacklist=nvidia_drm" GRUB_GFXPAYLOAD_LINUX="keep" The reason the legacy argument is there is because Docker won't work under the new cgroups, for now. I have a couple of modules, but the one that sticks out most is nvidia. This is the one I see in the stack trace. I have not seen a bug report on Gentoo or Nvidia's end. For now I've masked >5.4.0 gentoo-sources. Anyone else getting a similar issue? Thanks Andrew I have just installed fresh new gentoo installs with 5.4.2 and both machines use nvidia-drivers - I have not seen this at all. I have been doing a fair bit of compiling on one of the machines and haven't had any hiccups whatsoever. Dan
Re: [gentoo-user] What ntp/sntp client do people use?
On Wednesday, 11 December 2019 04:59:08 GMT Walter Dnes wrote: > On Tue, Dec 10, 2019 at 03:19:16AM -0600, Dale wrote > > > I think I used ntpdate years ago. Can't recall why I switched but > > > > something wasn't working right. People here recommended chrony and once > > set up, its worked ever since. OP, if you haven't tried it yet, may be > > worth giving it a test run. Man chronyc; man chronyd. Here's my chrony.conf: # cat /etc/chrony/chrony.conf # Use public NTP servers from the pool.ntp.org project. # Also Zen's closer servers: server ntp0.zen.co.uk iburst server ntp1.zen.co.uk iburst pool uk.pool.ntp.org iburst server 0.gentoo.pool.ntp.org iburst server 1.gentoo.pool.ntp.org iburst server 2.gentoo.pool.ntp.org iburst server 3.gentoo.pool.ntp.org iburst # Record the rate at which the system clock gains/losses time. driftfile /var/lib/chrony/drift # Allow the system clock to be stepped in the first three updates # if its offset is larger than 1 second. makestep 1.0 3 # Enable kernel synchronization of the real-time clock (RTC). rtcsync rtconutc -- HTH. -- Regards, Peter.
[gentoo-user] Re: What ntp/sntp client do people use?
On 2019-12-11 22:18, Walter Dnes wrote: > openrdate defaults to set correct time directly, but it does have an > optional parameter to gradually skew local time to the remote time. I > use openrdate in client mode once a month or so to sync a machine. NTP (the protocol implemented by both chrony and ntpd) is one of the classic TCP/IP protocols, going back to 1985 (RFC 958). You really should use it the way it was intended, and not adopt various later hacks from the world of Linux distributions. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] kodi reports symbol lookup error
> > If you're not on the live ebuild, you'll probably have to mask > >libfmt-6.1.0. I noticed I had build issues with the live ebuild and > just masked it assuming it would eventually be fixed (which it appears > to be now) > Thanks for that. I'm using ~arch. FWIW I needed >=dev-libs/libfmt-6.1.0 to push me down to 6.0.0 to get it to work again.
Re: [gentoo-user] kodi reports symbol lookup error
On Thu, Dec 12, 2019 at 4:49 PM David Haller wrote:
> First of all, decode that C++ symbol with c++filt:
>
> $ echo
> _ZN3fmt2v68internal14sprintf_formatIeEEPcT_RNS1_6bufferIcEENS1_13sprintf_specsE
> | c++filt
> char* fmt::v6::internal::sprintf_format(long double,
> fmt::v6::internal::buffer&, fmt::v6::internal::sprintf_specs)
>
> Now, with a bit of guesswork and tabbing,
> $ grep -r sprintf_format /usr/include/fmt/
> /usr/include/fmt/format.h:void sprintf_format(Double, internal::buffer &,
> core_format_specs);
> /usr/include/fmt/format.h:internal::sprintf_format(value, buffer,
> normalized_spec);
> /usr/include/fmt/format-inl.h:void sprintf_format(Double value,
> internal::buffer ,
>
With libfmt-6.1.1 there's no matches to that grep. With a looser match;
$ grep -r sprintf /usr/include/fmt/*
/usr/include/fmt/printf.h:inline std::basic_string vsprintf(
/usr/include/fmt/printf.h:std::string message = fmt::sprintf("The
answer is %d", 42);
/usr/include/fmt/printf.h:inline std::basic_string sprintf(const S&
format, const Args&... args) {
/usr/include/fmt/printf.h: return vsprintf(to_string_view(format),
{make_format_args(args...)});
The format.h file is there, however.
libfmt-6.1.0 is also missing internal::sprintf_format but its there in
6.0.0. Kodi runs now with 6.0.0 and didn't require a rebuild. Thanks!
Before I posted I had already rebuilt kodi, and run revdep-rebuild, which
didnt find anything.
