Re: [gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 12/03/2021 16:48, Grant Edwards wrote: On 2021-03-12, Spackman, Chris wrote: On 2021/03/12 at 02:57pm, Grant Edwards wrote: When I drag a tab out of it's parent window to create a new window [...] instead of staying where it's put the new window will follow the mouse cursor around the desktop anytime Chrom(e|ium) has focus. [...] any keypress will cause the weird behavior to stop. I have the same problem. Started recently. Right clicking on the tab and choosing "Move tab to new window" (if there is only one window) or "Move tab to another window" => "New window" (if there is already more than one window) works without problem. Yep, same here. I've no idea what is causing the problem. Fluxbox is my window manager. I'm using openbox. The most recent upgrade of Chrome/Chromium was about 3 days before the problem started. libXt and wayland got upgraded about 2 days before the problem started. I haven't tried downgrading anything yet. Now that I know to just hit a key to stop it, it's not so bad, so I'll probably just try to wait it out until it gets fixed. For the first day or so it was infuriating... I don't use Chrome/Chromium, but I've notice similar behaviour. istr it was Windows though ... Cheers, Wol
Re: [gentoo-user] Why do we add the local host name to the 127.0.0.1 / ::1 entry in the /etc/hosts file?
On Thursday, 11 March 2021 16:50:37 GMT Grant Taylor wrote: > On 3/11/21 6:38 AM, Michael wrote: > > I'm losing my thread in this ... thread, but what I'm trying to say > > is the AD/ DC and Kerberos way of processing the /etc/hosts entries, > > when an /etc/hosts file is used, is different to your run of the mill > > Linux box and server. > > I disagree. > > First, AD/DC ~ Kerberos don't process the /etc/hosts file. They do ask > the system to resolve names to IP addresses. Yes, of course. I realise I didn't express this point accurately. I think the hosts file is parsed, if it exists, by the glibc which then provides the required IP info to applications. > Second, the system will process the /etc/hosts file, DNS, NIS(+) in the > order configured in the /etc/nsswitch file so that it can resolve names > to IP addresses for programs that ask it to do so. Yes, /etc/hosts could be even be configured to be the last source to be consulted, or not exist at all. > Third, both non-AD / non-Kerberos and AD / Kerberos systems ask the > system to resolve names to IP addresses. Further, I'll bet dollars to > donuts that they call the same functions and use the same subsystems. > > I will agree that non-AD / non-Kerberos systems are not sensitive to -- > what some consider to be -- the misconfigurations that AD / Kerberos > systems are. Right. That's the nub of it. Samba, with AD-DC and Kerberos configuration deserves special attention and the apps devs advise accordingly. > > The Samba link in a previous message makes it clear the DC must have > > a DNS domain, which corresponds to the domain for the AD forest, > > this will be used by the Kerberos AD realm; and, the DC must have a > > static IP address. > > Yes. But that has nothing to do with the contents of the /etc/hosts file. It does, insofar the hosts file contents and syntax could break Samba, AD/DC and Kerberos, if the Samba devs advice is not heeded. Unless I got all this thread wrong, this is the main bone of contention - handbook recommendations can lead to such breakage. [snip...] > > Since /etc/hosts is parsed from the top, things may work fine when > > the localhost entry is further down the list and further down than > > any other entries acting as AD DNS resolvers - I don't recall testing > > this on Samba to know for sure. > > Why are you putting entries for the DNS servers in the /etc/hosts file? You wouldn't normally add in the hosts file the IP addresses of DNS forwarders/resolvers, but depending on the topology of the AD forest you could if you wanted to. > > The same syntax won't break a LAMP, or vanilla linux PC, as long as > > the same box is not acting as a DC. > > Actually it can. I've seen it multiple times in the past. > > Bind a service to /only/ the LAN IP. Then have the system try to > connect to itself. It will fail because the service isn't listening on > the loopback IP. Quite. If you set up this service to only listen to the LAN IP address, rather than any address, it should do just so. There is also the question why should a service for the LAN need to listen to localhost, it's not always necessary. > This is (or was) common on web servers that had multiple IP addresses to > use different TLS certificates before SNI became a viable thing. Have > each virtual web server listen on only it's specific IP address. Have > the virtual web server for the system's FQDN follow suit for consistency > reasons. Then trying to connect to the FQDN would fail if it was an > alias for 127.0.0.1 or ::1. Yes, I recall apache would fail if you tried to contact http://localhost or its FQDN from the server itself, with something like "... host name not valid for this server", but it would serve the default "It works!" webpage when the server's FQDN was called from clients. Anyway, all this is O/T from the main question. > > See my statement above re. entries for AD DNS resolvers, if these > > are listed in the /etc/hosts file. > > You didn't answer my question. > > What does the number of DNS servers (configured in /etc/resolv.conf) > have to do with the contents of the /etc/hosts file? It doesn't, obviously the two files are fulfilling different purposes. You could however specify in the DC's host file any additional DNS servers in the AD DNS zone with their static IP addresses. I tend to do this and also check the hosts file in the first instance when I forget what other machines play some (important) role on the current host's functions. This is by no means a rule or even a recommendation for others to do the same. ;-) > > The /etc/hosts file specifies the LAN IP address(es) of the DC which > > acts as DNS resolver for the AD DNS zones. > > No, the /etc/hosts file has nothing to do with how /DNS/ resolution > operates. Yes, but I was not referring to DNS resolution mechanism itself, other than specifying static addresses of other DCs PCs in the hosts file. It's just a list
Re: [gentoo-user] Weird harddisk problem: AHCI disks sometimes not found
On Thu, Mar 11, 2021 at 12:39 PM Alexander Puchmayr < alexander.puchm...@linznet.at> wrote: > > Hi there, > Any ideas? > One other point that I'd make on this subject is that even if you had the same kernel config file there could be differences in the tool chain that are causing your problem. I suspect researching that sort of cause would use huge amounts of time and likely never lead to a real understanding. You can, of course, build your own kernel on Ubuntu using Gentoo source code & config file and see whether your new Ubuntu kernel shows the problem or acts like the provided kernel. That might actually produce more forward progress should you not find a more simple solution. At least that would presumably produce systems with the same things built in vs modules. I would probably build vanilla-sources on the gentoo side to see if it's Gentoo patching. Good luck, Mark
Re: [gentoo-user] how to install mailman3 on gentoo
On 3/11/21 7:37 PM, John Covici wrote: I would appreciate some assistance. I would highly recommend that you subscribe to the Mailman Users mailing list. I have been subscribed to the MM-Users mailing list for a decade or more and have always found everybody to be quite helpful. Mark S. is the current maintainer and he routinely responds to posts. There are a handful of other frequent prolific helpers in the MM community too. Tell them what you're wanting to do, where you're wanting to do it (Gentoo vs Ubuntu) and they will help you with anything Mailman specific. They will probably try to answer more Gentoo specific questions, but may refer you back to a more Gentoo specific location (here) if things wonder too far from Mailman. E.e. they may only be able to offer limited help on Gentoo specific init scripts for Mailman. Go subscribe, and ask your questions. Note: I don't know if there is one common list or separate lists for MMv2 and MMv3. -- Grant. . . . unix || die
[gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 2021-03-12, Spackman, Chris wrote: > On 2021/03/12 at 02:57pm, Grant Edwards wrote: > >> > When I drag a tab out of it's parent window to create a new window >> > [...] instead of staying where it's put the new window will follow >> > the mouse cursor around the desktop anytime Chrom(e|ium) has focus. >> [...] >> any keypress will cause the weird behavior to stop. > > I have the same problem. Started recently. Right clicking on the tab > and choosing "Move tab to new window" (if there is only one window) > or "Move tab to another window" => "New window" (if there is already > more than one window) works without problem. Yep, same here. > I've no idea what is causing the problem. Fluxbox is my window > manager. I'm using openbox. The most recent upgrade of Chrome/Chromium was about 3 days before the problem started. libXt and wayland got upgraded about 2 days before the problem started. I haven't tried downgrading anything yet. Now that I know to just hit a key to stop it, it's not so bad, so I'll probably just try to wait it out until it gets fixed. For the first day or so it was infuriating... -- Grant
Re: [gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 2021/03/12 at 02:57pm, Grant Edwards wrote: > On 2021-03-12, Grant Edwards wrote: > > When I drag a tab out of it's parent window to create a new window > > [...] instead of staying where it's put the new window will follow > > the mouse cursor around the desktop anytime Chrom(e|ium) has focus. > [...] > > If I press ctrl-alt-backspace this behavior will stop, and the new > > window will behave normally. > I just realized that any keypress will cause the weird behavior to > stop. I have the same problem. Started recently. Right clicking on the tab and choosing "Move tab to new window" (if there is only one window) or "Move tab to another window" => "New window" (if there is already more than one window) works without problem. I've no idea what is causing the problem. Fluxbox is my window manager. -- Chris Spackman (he / him) ch...@osugisakae.com ESL Coordinator The Graham Family of Schools ESL Instructor Columbus State Community College Japan Exchange and Teaching Program Wajima, Ishikawa 1995-1998 Linux user since 1998 Linux User #137532
[gentoo-user] Re: Odd Chrome behavior when dragging tab to create new window
On 2021-03-12, Grant Edwards wrote: > When I drag a tab out of it's parent window to create a new window > [...] instead of staying where it's put the > new window will follow the mouse cursor around the desktop anytime > Chrom(e|ium) has focus. [...] > If I press ctrl-alt-backspace this behavior will stop, and the new > window will behave normally. I just realized that any keypress will cause the weird behavior to stop. I've also tried removing .config/chromium and .cache/chromium, and the problem persists.
[gentoo-user] Odd Chrome behavior when dragging tab to create new window
Yesterday afternoon, both Chrome and Chromium started behaving oddly. When I drag a tab out of it's parent window to create a new window (this is something I do a lot, every day), it works normally until I release the mouse button. Then, instead of staying where it's put the new window will follow the mouse cursor around the desktop anytime Chrom(e|ium) has focus. If I move the mouse quickly, the window will lag behind enough to loose focus, and then the new window will stay put -- as long as Chrom(e|ium) doesn't have focus. But if I move the mouse back to the original window, the new one will jump back to the new window and merge with it. If I move the mouse back to the new window, it will again start following the mouse cursor around the desktop. There also seems to be a limit on how far I can initially drag the new window before it gets "stuck" and I have to release the mouse buttin, grab the banner and drag it further. If I press ctrl-alt-backspace this behavior will stop, and the new window will behave normally. If I right-click on a tab and select "Move tab to new window" the new window will behave normally. No other application seem to have a similar problem. I'm not aware of any changes in configuration in the past few days, and it's been three days since the last emerge. The window manager is openbox, and it's been untouched for at least two months. I've logged out, restarted X11, and even rebooted, and Chrome's odd behavior persists. Any suggestions on how to diagnose/fix this? -- Grant
Re: [gentoo-user] how to install mailman3 on gentoo
On Fri, 12 Mar 2021 02:47:46 -0500, Matthias Hanft wrote: > > John Covici wrote: > > Hi. I have to convert my mailman2 to mailman3 because of the python > > business. I installed the appropriate packages, but their > > documentation as to how to set it up and upgrade mailman2 is quite > > inscrutible -- also it assumes ubunto and some strange python things > > such as installing in a virtual environment, and assumes postgresql > > which I might or might not want to do. Anyway, I have no idea what I > > am doing here, so if anyone has figured this out, I would appreciate > > some assistance. > > Same here. My solution: I changed to mlmmj - http://mlmmj.org/ (available > with Portage) - and everything works fine. Configuration is done by > simple text files, and transferring the list members is just copy-and-paste. > > If you're not stuck to mailman, you could take this into consideration. I will look into that one. I would like to use mailman, but it seems difficult and obscure. Thanks. -- 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
