-
-
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.
-
I wanted to use a Logitech R400 that a friend loaned my in a presentation, but I wanted to tweak the mappings for the buttons a bit. My presentation is done using Reveal.js and uses both left/right and up/down. The R400 has four buttons but two of them are mapped to “go to black screen” and “slideshow mode” neither of which is useful to me. Here is how I fixed it in Fedora 20.
- Create the directory
/etc/udev/hwdb.d - Write the following out to
/etc/udev/hwdb.d/99-logitech-r400.hwdb# The lower left button actually emits two # different scancodes depending on the state of # the "presentation". # E.g. one code to start and one to stop. keyboard:usb:v046DpC538 KEYBOARD_KEY_70029=up KEYBOARD_KEY_7003E=up KEYBOARD_KEY_70037=down KEYBOARD_KEY_7004B=left KEYBOARD_KEY_7004E=rightThis maps the left and right buttons to left and right, the both states of the slideshow button to up, and the blank screen button to down. The
046Dis the Logitech vendor code and theC538is the model number. Those magic numbers after “KEYBOARD_KEY” are the scancodes associated with the button. Supposedlyshowkey --scancodeswill display them but I couldn’t get that to work and ended up taking them from another blog post. - Now we need to load this information.
# udevadm hwdb --update && udevadm trigger - We can test by running the command below and pushing the buttons
# xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p' - Everything should work now, but if we unplug the USB receiver everything gets reset. That’s annoying so we will fix it
- Write the following to
/etc/udev/rules.d/99-logitech-r400.rulesSUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c538", IMPORT{builtin}="hwdb 'keyboard:usb:v046DpC538'", RUN{builtin}+="keyboard"That will import our custom mapping when the USB receiver is plugged in.
Thanks to the following who helped me figure all this out:
- Create the directory
-
In my experience, the best way to learn about how to package RPMs is to look at how other people package RPMs. That means looking at lots of spec files. Sure
fedpkgwill let you clone lots of package repos, but what if you only have the SRPM? You can get the spec file out of a SRPM, but it takes a little work withcpio, a tool with so many options that I can never remember the exact invocation. So I wrote a quick two-liner to save me some aggravation:#! /bin/sh spec=$(rpm -qlp $1 | grep -E '\.spec$') rpm2cpio $1 | cpio -i --to-stdout $specAnd how can you get the SRPM? Simple, install
yum-utilsthen run$ yumdownloader --source --downloadonly PACKAGE_NAME -
I use mock frequently when I am building packages for Fedora. Koji is great, but mock really shines when you are rapidly iterating over spec file changes. The
--no-cleanoption keeps the chroot around so you don’t have to download packages repeatedly and you can actually look around inside the chroot to see where a build is going wrong if you need to.I also use repoquery a lot to see what a package requires or provides. Knowing what a package requires or provides is especially helpful when you’re doing builds. By default repoquery runs against the repos in
/etc/yum.repos.d. Wouldn’t it be nice if we could run repoquery against the repos set up in our mock configs?It turns out that you can. Repoquery takes a
--repofrompathargument that can be used to create an ad hoc repo to query. The only missing piece is reading the mock config, grabbing the repo URL, and formatting it.I wrote a little Zsh function to do just that.
#! /bin/zsh mock-repoquery() { local profile="$1" [ -f "$profile" ] || profile="/etc/mock/${1}.cfg" # Take all baseurls in a file and make them into an array # See Parameter Expansion Flags section of the zshexpn man page and # http://unix.stackexchange.com/a/29748 local repo_urls repo_urls=("${(@f)$(sed -n -r 's/.*baseurl=(.*)(\\n|$)/\1/p' $profile | cut -d'\' -f1)}") local repo_args repo_args=() for ((i=1; i <= ${#repo_urls}; i++)); do repo_args+="--repofrompath=r${i},$repo_urls[i]" repo_args+="--repoid=r${i}" done repoquery "${repo_args[@]}" "$@[2,-1]" } mock-repoquery "$@"Drop the above code into
~/.zfunc/mock-repoqueryand then add the following to~/.zshrcfpath=( ~/.zfunc "${fpath[@]}" ) autoload -Uz mock-repoqueryThen you can use
mock-repoqueryby passing a mock profile as the first argument. Any additional arguments will be forwarded to repoquery. For example:$ mock-repoquery /etc/mock/fedora-20-x86_64.cfg --requires tig git libc.so.6(GLIBC_2.15)(64bit) libncursesw.so.5()(64bit) libtinfo.so.5()(64bit) rtld(GNU_HASH)Note that
mock-repoquerywill only work in Zsh due to my usage of Zsh parameter expansion. Converting this function to work in Bash is possible, but I use Zsh so I didn’t bother. Patches will be accepted happily!
-
-
Technitribe by Tim Bielawa is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.