Re: [gentoo-user] Bounced messages
On 11/1/19 2:00 PM, Dale wrote: I think we came to the conclusion that one person is causing this. I don't agree with that conclusion. Basically his emails trigger the spam alarm and it gets marked before or upon receipt by gmail. It doesn't even make it to my in box. I don't know if spam is the proper term per say, but it's certainly in the email hygiene category. Now how a individual can find themselves in a place where their emails are marked as spam like that, one can only guess. I don't need to guess. Any subscriber that posts to the list from an email domain that employs contemporary security; i.e. SPF, and DKIM, and DMARC, all with strict settings, will likely cause this to happen for subscribers that have email with a provider that honors said strict security. Thanks for the info. You're welcome. Note: I expect this larger problem to get considerably worse (across mailing lists in general) before it gets better. Some governments around the world are mandating that any business that partners with the government in any way must implement the contemporary technologies that I'm talking about. Germany and the U.S.A. come to mind. I don't know of other examples off hand. -- Grant. . . . unix || die
Re: [gentoo-user] Consolekit and elogind switch questions
Mick wrote: > On Sunday, 3 November 2019 06:08:15 GMT Dale wrote: >> Mick wrote: >>> On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote: On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote: > Thanks much for the info. Maybe the switch will go well for me too. If it works for you it will be good news for the rest of us ;-) >>> If hald's list of devices has anything to do with it, Dale is bound to >>> nail it on the first (re)boot! :-) >>> >>> The consolekit framework is responsible switching between users on a >>> system. As I understand it, when you go to 'Plasma/Leave/Switch User' >>> menu option, console kit daemon is responsible for: >>> >>> 1. Looking at PAM and any processes you own as a user in a login session. >>> 2. Checking which seat (local or remote) you are logged in as and >>> associating the hardware you are using with it (e.g. keyboard, mouse, >>> monitor, etc.). 3. Connecting to the d-bus system bus to manage the local >>> login session and pass control of hardware devices to the new user. >>> 4. When the new user enters their credentials at the Display Manager, >>> check >>> with PAM what processes the new user is authorised to access/use in their >>> login session. >>> >>> I should have the above mostly correct. You may ask if any of this >>> control >>> framework complexity is *necessary* for a single user called Dale, who >>> won't allow anyone else to take his 'seat' at the PC without a fight. >>> The answer is probably no, and this is why simpler desktop environments >>> like *box, Enlightenment, etc. do not offer the facility to switch users >>> and therefore do not ultimately need consolekit. >>> >>> There are no screenshots of consolekit/elogind because AFAIK neither offer >>> a GUI application. However, when you run 'ck-list-sessions' in a >>> terminal you'll see your local session, as well as any other login >>> sessions you may be running at the time, e.g. /dev/tt1, remote logins >>> over ssh and which of these are active at the time. >>> >>> Since consolekit is no longer under development and systemd appears to >>> have >>> taken over most of the Linux distros, elogind is the current service which >>> can run as stand alone on openrc (just as udev of systemd does). >>> >>> When elogind is running you can use 'loginctl list-sessions' in a terminal >>> to see who's running a session. The man page gives more options. >>> >>> You don't *have* to add elogind as a boot service, because any >>> applications >>> which need it will launch it themselves. However, don't be surprised if >>> some desktop functions are not working as expected. For example, the >>> SDDM Display Manager's shutdown/reboot buttons may not be displayed and >>> even if they are displayed they'll do nothing when you click on them >>> after a reboot. If after a reboot you login/out into your Plasma >>> desktop, then elogind will be running and the SDDM buttons should >>> function again normally. >>> >>> I have converted a number of systems to elogind. It should be as easy as >>> setting in your make.conf: >>> >>> USE="elogind -consolekit" >>> >>> grep consolekit -r /etc/portage >>> >>> to find and remove/replace any USE flags still asking for consolekit to be >>> emerged. Then, >>> >>> emerge --depclean -v -a consolekit >>> >>> emerge -uaNDv @world >>> >>> emerge @preserved-rebuild -v -a >>> >>> rc-update del consolekit >>> rc-update add elogind boot >>> >>> reboot >>> >>> >From memory that's all there is to it. >> One quick question, is a reboot necessary or would going to single and >> back be enough? I hate rebooting because I've had a init thingy fail a >> couple times in the past. Makes me nervous and my blood pressure go up >> as well. Reminds me a little of hal. :/ >> >> I'm thinking about going ahead and doing this but may sync again first, >> just to be sure the tree is up to date enough. I did a -p on it and it >> doesn't look like to much changes, mostly USE flags. >> >> Thanks. >> >> Dale >> >> :-) :-) > I forgot, you should stop the consolekit service before you remove/delete it > and do this *after* you have logged out. > > Since consolekit/elogind are services dealing with desktop user access, you > should at least log out, stop consolekit, start elogind and then log back > into > your KDE/Plasma desktop. Rebooting is not necessary, although I tend to > reboot just to check boot services (re)start as they should and there are no > errors/clashes. > OK, thanks much. Since it is a service, I thought a reboot may not be required but wanted to be sure. The extra information did help me with what I thought would be required, like stopping consolekit first. That hadn't occurred to me. Dale :-) :-)
Re: [gentoo-user] why is writing to an async-mounted USB disk so slow?
Thomas Mueller wrote: >> Mick has a good point. I have two or three of the cheaper USB external >> enclosures and only one of them was somewhat fast, it is USB 2.0 after >> all. The other two logged a lot of errors in messages file about >> resetting something. It was resetting so often that moving data to or >> from the drive was very slow. I pitched the two bad ones, saved the one >> that works but bought a known good one, it has a fan and a display with >> the temps and fan RPMs etc on it. It is a eSATA or USB enclosure. I >> use the eSATA port and it is as fast as my internal drives. If >> interested, I can find a link for one so you can see what it looks >> like. I can also find the one that doesn't work just in case you have >> it. The good one is black and the iffy ones are a silver color. Point >> is, not all external enclosures work well. USB ports in my experience >> really complicate matters. >> I like USB for my camera and my little card reader, that I use to get >> deer pics off my trail camera. Other than that, I try to avoid USB. >> Oh, printers tend to work too. >> Dale > I am curious about your USB and eSATA enclosure. > > I have two such Sabrent enclosures, USB 2.0 and eSATA. > > USB 2.0 works with IDE or SATA hard drive, while eSATA works only with SATA > hard drive. > > I also have a Micronet Fantom G-Force hard drive with USB 3.0 and eSATA > connections. > > Tom > > > This first one is like the one that doesn't work. Of the three, two didn't work correctly and the one that works without errors isn't that fast either. I wouldn't recommend this one unless something has changed which makes it much faster in the case of the one that works and is dependable in the case of the two who doesn't. https://www.ebay.com/itm/USB3-0-HDD-Enclosure-3-5-SATA-External-Hard-Drive-Caddy-Case-cooling-fan/293073024042 This next one is the one that works great. It's fast, every bit as fast as my internal drives. I have not tried the USB port so I'm referring to the eSATA port only. Let's hope they haven't changed this since it works great. The display is hard to see on the main image but another image shows it well. I might add, the price has went up quite a bit too. o_O https://www.ebay.com/itm/Rosewill-Armer-RX304-APU3-35B-External-3-5-SATA-III-6-Gb-s-Hard-Drive-Enclosu/383002494116 One other note, neither of those are the vendor I bought from. The original vendor had sold out and either unlisted the item or no longer had all the info. I'm sure there are others out there that work fine. I'm just sharing the ones I have that don't work right and one that does. Just like hard drives in general, I'm sure others will have different experiences. Dale :-) :-)
[gentoo-user] Re: Welcome to gentoo-user@lists.gentoo.org
В письме от воскресенье, 3 ноября 2019 г. 23:01:39 +07 пользователь gentoo- user+h...@lists.gentoo.org написал: > Thank you for confirming your subscription. You have now been added to the > normal version of the list. > > The email address you are subscribed with is . > > If you ever wish to unsubscribe, send a message to > using this email address. The > subject and the body of the message can be anything. You will then receive > confirmation or further instructions. > > For other information and help about this list, send a message to > .
Re: [gentoo-user] problem changing to 17.1 profile
On Sun, 03 Nov 2019 02:21:18 -0500, Andrew Udvare wrote: > > [1 ] > [1.1 ] > On 02/11/2019 01:36, John Covici wrote: > > Hi. Well, I was finally able to do the change of profile tothe 17.1 > > profile. I have gotten all the way almost to the end of this process > > to the final step where itwantsto emerge all the 32-bit packages. I > > am about two from the end of that list and trying to emerge > > x11-libs/gtk+-2.24.32-r1 andI have run into this problem: > > > > libtool: link: x86_64-pc-linux-gnu-gcc -O2 -mtune=core2 -pipe -ggdb > > -Wall -Wl,-O1 -o decompose-bits decompose-bits.o -Wl,--as-needed > > /usr/lib/libatk-1.0.so -lpango-1.0 -lcairo -lgdk_pixbuf-2.0 > > -lgobject-2.0 -lglib-2.0 > > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > > /usr/lib/libatk-1.0.so: error adding symbols: file in wrong format > > collect2: error: ld returned 1 exit status > > > > Now, I re-emerged dev-libs/atk which contains the offending > > library, but no joy. the gtk package is pulled in by several other > > packages, so I cannot remove it. > > If you re-emerged atk successfully, then the gtk linking stage should > not fail with the same error as /usr/lib/libatk-1.0.so should now be in > the correct format (32-bit instead of 64-bit). > > > > > Thanks in advance for any suggestions asto howto proceed. > > > > You have to pull in some packages in a very specific order. > > With KDE we have a sort of circular dependency on freetype[harfbuzz], > because harfbuzz itself depends on freetype. For this reason I had to do > the following: > > env USE=-harfbuzz emerge -1 freetype > emerge -1 harfbuzz > emerge -1 freetype > > There is currently no way for Portage to do this automatically. > > Your issue sounds similar and I would suggest emerging offending > packages separately before continuing the rebuild process for /lib32, > etc. The order is going to depend on other packages you have installed. > > As soon as one of these special packages errors, you need to check the > build log. Most likely it was during the configure stage where a > dependency is not being found in /lib because it has not been built yet. > Build that dependency with --oneshot and try again with the failing > package after. Thanks for your response. I am pretty sure it has something to do with the accessibility infrastructure, I tried emerging those separately, but no joy on doing that. I will look and see if there are any other dependencies, but this was at the very end of the list and all others were successful. Very strange, indeed. -- 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] Consolekit and elogind switch questions
On Sunday, 3 November 2019 06:08:15 GMT Dale wrote: > Mick wrote: > > On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote: > >> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote: > >>> Thanks much for the info. Maybe the switch will go well for me too. > >> > >> If it works for you it will be good news for the rest of us ;-) > > > > If hald's list of devices has anything to do with it, Dale is bound to > > nail it on the first (re)boot! :-) > > > > The consolekit framework is responsible switching between users on a > > system. As I understand it, when you go to 'Plasma/Leave/Switch User' > > menu option, console kit daemon is responsible for: > > > > 1. Looking at PAM and any processes you own as a user in a login session. > > 2. Checking which seat (local or remote) you are logged in as and > > associating the hardware you are using with it (e.g. keyboard, mouse, > > monitor, etc.). 3. Connecting to the d-bus system bus to manage the local > > login session and pass control of hardware devices to the new user. > > 4. When the new user enters their credentials at the Display Manager, > > check > > with PAM what processes the new user is authorised to access/use in their > > login session. > > > > I should have the above mostly correct. You may ask if any of this > > control > > framework complexity is *necessary* for a single user called Dale, who > > won't allow anyone else to take his 'seat' at the PC without a fight. > > The answer is probably no, and this is why simpler desktop environments > > like *box, Enlightenment, etc. do not offer the facility to switch users > > and therefore do not ultimately need consolekit. > > > > There are no screenshots of consolekit/elogind because AFAIK neither offer > > a GUI application. However, when you run 'ck-list-sessions' in a > > terminal you'll see your local session, as well as any other login > > sessions you may be running at the time, e.g. /dev/tt1, remote logins > > over ssh and which of these are active at the time. > > > > Since consolekit is no longer under development and systemd appears to > > have > > taken over most of the Linux distros, elogind is the current service which > > can run as stand alone on openrc (just as udev of systemd does). > > > > When elogind is running you can use 'loginctl list-sessions' in a terminal > > to see who's running a session. The man page gives more options. > > > > You don't *have* to add elogind as a boot service, because any > > applications > > which need it will launch it themselves. However, don't be surprised if > > some desktop functions are not working as expected. For example, the > > SDDM Display Manager's shutdown/reboot buttons may not be displayed and > > even if they are displayed they'll do nothing when you click on them > > after a reboot. If after a reboot you login/out into your Plasma > > desktop, then elogind will be running and the SDDM buttons should > > function again normally. > > > > I have converted a number of systems to elogind. It should be as easy as > > setting in your make.conf: > > > > USE="elogind -consolekit" > > > > grep consolekit -r /etc/portage > > > > to find and remove/replace any USE flags still asking for consolekit to be > > emerged. Then, > > > > emerge --depclean -v -a consolekit > > > > emerge -uaNDv @world > > > > emerge @preserved-rebuild -v -a > > > > rc-update del consolekit > > rc-update add elogind boot > > > > reboot > > > > >From memory that's all there is to it. > > One quick question, is a reboot necessary or would going to single and > back be enough? I hate rebooting because I've had a init thingy fail a > couple times in the past. Makes me nervous and my blood pressure go up > as well. Reminds me a little of hal. :/ > > I'm thinking about going ahead and doing this but may sync again first, > just to be sure the tree is up to date enough. I did a -p on it and it > doesn't look like to much changes, mostly USE flags. > > Thanks. > > Dale > > :-) :-) I forgot, you should stop the consolekit service before you remove/delete it and do this *after* you have logged out. Since consolekit/elogind are services dealing with desktop user access, you should at least log out, stop consolekit, start elogind and then log back into your KDE/Plasma desktop. Rebooting is not necessary, although I tend to reboot just to check boot services (re)start as they should and there are no errors/clashes. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] why is writing to an async-mounted USB disk so slow?
> Mick has a good point. I have two or three of the cheaper USB external > enclosures and only one of them was somewhat fast, it is USB 2.0 after > all. The other two logged a lot of errors in messages file about > resetting something. It was resetting so often that moving data to or > from the drive was very slow. I pitched the two bad ones, saved the one > that works but bought a known good one, it has a fan and a display with > the temps and fan RPMs etc on it. It is a eSATA or USB enclosure. I > use the eSATA port and it is as fast as my internal drives. If > interested, I can find a link for one so you can see what it looks > like. I can also find the one that doesn't work just in case you have > it. The good one is black and the iffy ones are a silver color. Point > is, not all external enclosures work well. USB ports in my experience > really complicate matters. > I like USB for my camera and my little card reader, that I use to get > deer pics off my trail camera. Other than that, I try to avoid USB. > Oh, printers tend to work too. > Dale I am curious about your USB and eSATA enclosure. I have two such Sabrent enclosures, USB 2.0 and eSATA. USB 2.0 works with IDE or SATA hard drive, while eSATA works only with SATA hard drive. I also have a Micronet Fantom G-Force hard drive with USB 3.0 and eSATA connections. Tom
Re: [gentoo-user] problem changing to 17.1 profile
On 02/11/2019 01:36, John Covici wrote: > Hi. Well, I was finally able to do the change of profile tothe 17.1 > profile. I have gotten all the way almost to the end of this process > to the final step where itwantsto emerge all the 32-bit packages. I > am about two from the end of that list and trying to emerge > x11-libs/gtk+-2.24.32-r1 andI have run into this problem: > > libtool: link: x86_64-pc-linux-gnu-gcc -O2 -mtune=core2 -pipe -ggdb > -Wall -Wl,-O1 -o decompose-bits decompose-bits.o -Wl,--as-needed > /usr/lib/libatk-1.0.so -lpango-1.0 -lcairo -lgdk_pixbuf-2.0 > -lgobject-2.0 -lglib-2.0 > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > /usr/lib/libatk-1.0.so: error adding symbols: file in wrong format > collect2: error: ld returned 1 exit status > > Now, I re-emerged dev-libs/atk which contains the offending > library, but no joy. the gtk package is pulled in by several other > packages, so I cannot remove it. If you re-emerged atk successfully, then the gtk linking stage should not fail with the same error as /usr/lib/libatk-1.0.so should now be in the correct format (32-bit instead of 64-bit). > > Thanks in advance for any suggestions asto howto proceed. > You have to pull in some packages in a very specific order. With KDE we have a sort of circular dependency on freetype[harfbuzz], because harfbuzz itself depends on freetype. For this reason I had to do the following: env USE=-harfbuzz emerge -1 freetype emerge -1 harfbuzz emerge -1 freetype There is currently no way for Portage to do this automatically. Your issue sounds similar and I would suggest emerging offending packages separately before continuing the rebuild process for /lib32, etc. The order is going to depend on other packages you have installed. As soon as one of these special packages errors, you need to check the build log. Most likely it was during the configure stage where a dependency is not being found in /lib because it has not been built yet. Build that dependency with --oneshot and try again with the failing package after. -- Andrew signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Consolekit and elogind switch questions
Mick wrote: > On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote: >> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote: >>> Thanks much for the info. Maybe the switch will go well for me too. >> If it works for you it will be good news for the rest of us ;-) > If hald's list of devices has anything to do with it, Dale is bound to nail > it > on the first (re)boot! :-) > > The consolekit framework is responsible switching between users on a system. > As I understand it, when you go to 'Plasma/Leave/Switch User' menu option, > console kit daemon is responsible for: > > 1. Looking at PAM and any processes you own as a user in a login session. > 2. Checking which seat (local or remote) you are logged in as and associating > the hardware you are using with it (e.g. keyboard, mouse, monitor, etc.). > 3. Connecting to the d-bus system bus to manage the local login session and > pass control of hardware devices to the new user. > 4. When the new user enters their credentials at the Display Manager, check > with PAM what processes the new user is authorised to access/use in their > login session. > > I should have the above mostly correct. You may ask if any of this control > framework complexity is *necessary* for a single user called Dale, who won't > allow anyone else to take his 'seat' at the PC without a fight. The answer > is > probably no, and this is why simpler desktop environments like *box, > Enlightenment, etc. do not offer the facility to switch users and therefore > do > not ultimately need consolekit. > > There are no screenshots of consolekit/elogind because AFAIK neither offer a > GUI application. However, when you run 'ck-list-sessions' in a terminal > you'll see your local session, as well as any other login sessions you may be > running at the time, e.g. /dev/tt1, remote logins over ssh and which of these > are active at the time. > > Since consolekit is no longer under development and systemd appears to have > taken over most of the Linux distros, elogind is the current service which > can > run as stand alone on openrc (just as udev of systemd does). > > When elogind is running you can use 'loginctl list-sessions' in a terminal to > see who's running a session. The man page gives more options. > > You don't *have* to add elogind as a boot service, because any applications > which need it will launch it themselves. However, don't be surprised if some > desktop functions are not working as expected. For example, the SDDM Display > Manager's shutdown/reboot buttons may not be displayed and even if they are > displayed they'll do nothing when you click on them after a reboot. If after > a reboot you login/out into your Plasma desktop, then elogind will be running > and the SDDM buttons should function again normally. > > I have converted a number of systems to elogind. It should be as easy as > setting in your make.conf: > > USE="elogind -consolekit" > > grep consolekit -r /etc/portage > > to find and remove/replace any USE flags still asking for consolekit to be > emerged. Then, > > emerge --depclean -v -a consolekit > > emerge -uaNDv @world > > emerge @preserved-rebuild -v -a > > rc-update del consolekit > rc-update add elogind boot > > reboot > > >From memory that's all there is to it. One quick question, is a reboot necessary or would going to single and back be enough? I hate rebooting because I've had a init thingy fail a couple times in the past. Makes me nervous and my blood pressure go up as well. Reminds me a little of hal. :/ I'm thinking about going ahead and doing this but may sync again first, just to be sure the tree is up to date enough. I did a -p on it and it doesn't look like to much changes, mostly USE flags. Thanks. Dale :-) :-)
