For a very goofy reason involving a bug with composer, and new warning messages in PHP, I decided I needed to reinstall eclipse on oregano. Reinstalling eclipse is always a test of my patience. During the entire course of my life I do not believe that the installation of eclipse along with the various components I need, especially subclipse, has ever “just worked”. There is always some issue. So, of course, I do not look forward to it with gleeful anticipation.
I think part of the problem for me – a problem of my own making I suppose – is that I mostly use distros (Fedora and Ubuntu) in which the packagers have already arranged for tools like eclipse to appear as “system level” rather than “user level” tools. By this I mean they appear (or are symlinked from) /usr/bin, their configuration files are located it /etc, their icons appear when you search for apps, etc. Whereas if you just use the upstream installers the installation will be carried out at the user level, they will ask you where to put the binary, and they will put configuration files in ~/.config,
Continue reading Desktop Files
I have been plagued by this error in subversion particularly when trying to commit from some of the boxes which I use less frequently:
svn: E175002: Unexpected HTTP status 200 ‘OK’ on ‘POST’ request to ‘/svn/!svn/me’
I have spent hours doing searches, reading posts, but have never found anyone whose issue was exactly like mine, not been able to figure it out based on other peoples issues. I resolved today to pay serious attention to figuring it out.
The solution turned out to be related to the url I used when I check something out of the svn repository. Long ago I set up a cname in dns for svn.wmbuck.net, and for a long time I used it. There is an apache config file for the servername svn.wmbuck.net, and it redirects http to https. Then at some point I began to just use https://wmbuck.net/svn/… to check things out. And that is where I went wrong, because that will work fine to do checkout, but when I try to commit from a box with that url (wmbuck.net) the http request is being routed to the default server, and the setup of the SSL session is failing.
I’m unsure exactly what is happening to cause the request to go to the default server. Perhaps the commit request does not specify SNI information.
What I do know is how to fix it. Do the checkout with https://svn.wmbuck.net/svn/ and commits work fine.
I had some trouble on the development box with permissions and decided it would be “easy” to just have apache run under user dee, that would just make everything so much easier. Right.
Two things have come up so far, and more likely to follow. One, I had to change the ownership on /var/lib/php/session from apache to dee. Second, I had to add dee into tlsusers so the media stuff can read the certificate.
This may have been a bad idea.
1/31/18: Went back to using apache user, when I moved to Fedora 27. Fedora now uses php-fpm service, and now apache needs to open a socket to it, and it just became complicated.
Eclipse on Fedora (and as I read it, also on Ubuntu) has now got a problem with colors. Specifically, when one hovers over a function to obtain the calling sequence, a pop up appears to provide this information but the background of the pop-up is black, which makes the content unreadable. This is relatively new, though I’m not sure whether it was with the change to Eclipse Neon or earlier, or the change to Fedora 24.
It turns out this is not a setting in eclipse, although I wasted quite a lot of time looking for it. This ends up being a system setting, associated with gtk, the graphical toolkit. If one starts eclipse with
which starts eclipse with gtk 2.0, instead of gtk 3.0, the problem goes away, the background of the pop-ups becomes a nice cream color.
The settings we are using are set in the theme one chooses, the default theme being Adwaita. The themes are kept in /usr/share/themes. I tried simply changing to a different theme (TraditionalOk) but the setting affecting this did not change. So I resorted to force.
In /usr/share/themes/TraditionalOk there are directories for gtk-2.0 and gtk-3.0. Within gtk-3.0 I changed the file gtk-widgets.css, specifically, I changed the setting in the tooltip section to background-color #f5f5b5; Previously the value was “@theme_tooltip_bg_color;” and as I read it, that define ought to have the value #f5f5b5. But something is wrong, and the setting is disruptd. But forcing it this way, it seems to work.