-
-
Dear Internet,
As I noted in an earlier post, Eclipse on Fedora 22 has some usability problems with the colors it uses. Eclipse uses GTK 3 for a lot of the theming of the interface. With the Gnome Adwaita theme, several of the drop-down dialogs (like Content Assist) have very little contrast between the background and foreground of a selected item. The result is the highlighted text is extremely difficult to read. Your only recourse is to mess with GTK settings.
I had managed to address an issue with the Content Assist drop-down only to run into another issue with the Quick Outline drop-down. Finally I gave up and said, “to heck with it, I’m going to redo the whole thing.” To check out the result I came up with, head over to the Eclipse Graphene repo.
Here’s an example:
-
When I write Java, I use Eclipse. It does what I need it to do, but there are a few things about it that bother me. One of them is that Eclipse allows very limited control over the color scheme. Most of the color settings are inherited from the desktop theme that you’re using. I recently upgraded to Fedora 22 and with the Adwaita theme under XFCE, this is what the Eclipse content assist dropdown looks like:
Can you read the top selection?
Notice how close the foreground and background colors are for the selected item. I find that intolerable. I’m not sure exactly why Eclipse is picking that color combination, because the content assist object is a GtkTreeView which has the selected item background color set to cerulean blue in Adwaita. In any case, to fix it create
~/.config/gtk-3.0/gtk.csswith the following contents:GtkTreeView:selected { background-color: @theme_selected_bg_color; }That snippet will override whatever weirdness is going on with the content assist dropdown and set the background color back to the theme’s default background color for selected items. You can also just set it to a hex value. Note that this setting will apply to any GTK3 application, but that should be all right since you’re just asking the theme to do what it is already doing.
-
Back in late 2013 I joined what was jokingly referred to as the Red Hat IT “DevOps” team. We didn’t like that name, so we changed it and there-after became officially known as Team Inception. From the time the team was formed, we all accepted that the team was to retire in 18-24 months. We were totally cool with that too! To us having a pure “DevOps” team in perpetuity just didn’t make sense.
Over the course of the team’s lifespan I feel like I experienced incredible growth, both personally and professionally. I’m proud to look back at all the cool things we accomplished as a team, and I’m even more thankful to have had the opportunity to be a member of that team. Here’s a taste of some things we did as a team publicly:
- Blogged a bunch of posts for Red Hat Developer Blog
- Created a functioning Continuous Deployment system, Release Engine [Docs]
- Created jsonstats, a tool for exporting system information over a REST interface
- And another tool, Talook, which provides a view into jsonstats running on a collection of servers
- Cacophony, a simple REST API for automatic SSL certificate generation
- The Ansible XML module. This grew in popularity so much that we realized the best way to ensure it lives on was by transferring complete ownership over to Chris Prescott, a former contributor (Thanks Chris)!
- git-branch-blacklist – A git-hook based system for blacklisting pushes to specific branches
Two week ago (2015-06-20 → 2015-06-24) the DevNation and Red Hat Summit 2015 conferences were held in Boston, MA. Of the many excellent speakers and panel groups [S|D] that held sessions during the conferences, there’s one group I am especially fond of: My old team, Inception.
On Wednesday, July 24th we held a panel session called Bootstrapping a DevOps Movement in Red Hat IT. This was our final activity together as Team Inception. During this panel-style session Jen Krieger, our Product Owner/Scrum Master, facilitated a look back at some of our experiences during our 18 months as the Red Hat IT “DevOp Team”.
We began the initial round of questions with what our individual perceptions of “DevOps” were before the team had formed. We followed that with what ended up being a great Q&A with the audience (thank you everyone who participated!). We ended the panel with our closing thoughts on what “DevOps” means to each of us now.
Here’s a snippet from the official session description:
Topics will include
- What we accomplished. We’ll take you step-by-step through how we deliver our work using a combination of open source tools, including Docker.
- How we rate both our cultural and tooling success.
- Roadblocks, disruptions, and surprises we encountered and how we handled them.
- How this project has changed the way we view our jobs and our work relationships.
- What’s next for the team.
Panel
- Tim Bielawa, Release Engineering / Development
- Ryan Cook, System Administration
- Steve Milner [blog], Security / Development
- Chris Murphy, System Administration
Panel facilitator
- Jen Krieger [pinterest], Agile Coach & Original Inception Product Owner
Between ourselves, we casually referred to this as our final team retrospective, an honest (and very public) look-back at lessons learned over the last year and a half.
Click play below to watch the full video now, or go directly to it on YouTube.
And before I forget. So much thanks to Andrew “Hoss” Butcher [GH] for recording, editing, and posting the recording for us. I (we) owe you many Tasty Beverages for that.
-
The “git archive” man page states:
git archive behaves differently when given a tree ID versus when given a commit ID or tag ID. In the first case the current time is used as the modification time of each file in the archive.
By using the current time in this case, git-archive is dooming all of our tarballs to have constantly changing SHA256 hashes. A lot of build systems, including Fedora’s Koji, rely on source tarballs maintaining a consistent fingerprint. What is a person to do?
Fix it of course! Below is a Python 2 program I wrote that addresses the issue. The code is well-commented (I hope) so you should be able to follow along. You give it the Unix timestamp you want the files to have, the git ref you want baked into the tar header, and the initial tarball. The result is printed to stdout so just redirect that to wherever you please (or pipe it into gzip). It also has some code in there to deal with tarballs created by the maven-assembly plugin, but it doesn’t surface that on the primitive CLI. I’m leaving that as an exercise for the reader I guess.
-
Recently I noticed that in my IRC client, when I right-click a URL and select “Open Link In Browser”, the system would open a new browser window (or tab if appropriate) but not pointed to the link I wanted to visit. It would just open the home page.
What gives? Well, I happen to know from experience that in Linux most programs that need to use a “default” type service of which there are many implementations (such as a web-browser) use the
xdg-opencommand. XDG associates different mime-types to default applications. Step one then is to figure out what’s going on with XDG.% xdg-mime query default text/html firefox.desktop firefox.desktopHere I’m asking XDG what applications are associated with the
text/htmlmime-type. Seeing two firefox.desktop files was a bit of a surprise. Let’s find out more!% locate firefox.desktop /usr/share/applications/firefox.desktop /usr/share/xfce4/helpers/firefox.desktopSo I open up those two files and the first file looks normal and that file actually belongs to the Firefox package according to
rpm -qf. In the second file, I seeX-XFCE-Commands=%B -remote "openURL(about:blank,new-window)";%B; X-XFCE-CommandsWithParameter=%B -remote "openURL(%s,new-window)";%B "%s";That looks strange to me. If I want to open a URL from the command line, I don’t use
openURL. Let’s see what happens if I replace that withX-XFCE-Commands=%B; X-XFCE-CommandsWithParameter=%B "%s";Aha! It works! But why? Well, after a little searching I came across Mozilla Bug 1080319. Looks like the
openURLwas a legacy thing and got removed in Firefox 36. And a quickrpm -q firefoxconfirms that I’m running that version. Firefox 36.0.1 add support foropenURLback in, but my hack will serve until that version hits Fedora.
-
-
Technitribe by Tim Bielawa is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.