Well, that's a week of my life I'll never have again. Spent most of last week playing with WinXP, LinuxMint 8, and Fedora 11 & 12 (both 32- and 64-bit) trying to find a solution to my external display issues.
Turns out that it's a software issue: the latest xorg intel driver has a bug.
Last week, I switched my xubuntu 8.04 (Hardy Heron) box to Linux Mint 8 (Helena), to see how things had evolved in the past 18 months. Unfortunately, I also decided to switch from 32- to 64-bit, and of course not everything works the way it used to.
Luckily, the good folks at Scooter Software pointed me to this hack to allow their 32-bit Linux flavour of Beyond Compare 3 to find the 32-bit libraries it needs to run.
So, here's an updated version of that hack for ubuntu 9.10 Karmic Koala or Linux Mint 8 Helena:
$ sudo suapt-get install ia32-libs cd /tmp; dpkg-deb --extract /tmp/libqt3-mt*.deb libqt3-mt cp -R libqt3-mt/usr/lib/* /usr/lib32; rm -fr /tmp/libqt3-mt dpkg -i --force-architecture /tmp/BCompareLinux*.deb
I've drafted a collection of tips for keeping your plugins healthy and your builds green.
Feel free to add to, change, or comment on the list here:
Sure, there are applets and other GUI tools to do this, but nothing beats the purity of going commando, er, commandline. :) Thanks to this article for the inspiration.
# reset xrandr --auto # turn off laptop screen xrandr --output LVDS --off # 24" 16x12 on xrandr --output VGA --mode 1600x1200
# reset
xrandr --auto
# turn off external screen
xrandr --output VGA --off
# laptop screen on
xrandr --output LVDS --mode 1280x800UPDATE, 2010/01/05:
To enable both screens and force the larger one to include the taskbar:
# reset xrandr --auto # laptop screen on xrandr --output LVDS1 --mode 1280x800 --noprimary --pos 1600x0 # 24" 16x12 on xrandr --output VGA1 --mode 1600x1200 --primary --pos 0x0 # echo current status xrandr --current
I'm having a problem w/ a purchase.
I added a Blackberry Bold compatible 2400mAh battery to my cart, on sale for 20% off ($24.07).
On page two, the price was still 20% discounted:
On page three of the cart, the price jumped back up to the full $30.09 price.
So... is this item on sale, or not?
I was recently asked the best approach for how to control the input to one's builds, and while there is no single solution to this that fits all projects, here are two ways you might want to go.
The current approach for JBoss Tools development involves continuous nightly builds from trunk until such time as the project is deemed frozen in prep for an upcoming milestone or release candidate. At that time, the trunk is copied to branches/JBossTools-3.1.0.M4, and very little is done to that branch - only urgent tweaks and fixes. A new Hudson job is cloned from the current one, and adjusted to point at the branched sources instead of trunk. The maps are also updated to point at the new source location in SVN.
This allows more nightly builds towards an upcoming stable development milestone, while new development can continue in parallel in trunk. When the milestone is released, the unneeded job is disabled or removed.
The only issue with this approach is that all plugins, built from the head of a branch (or trunk) are re-versioned w/ the latest timestamp every time they're compiled. Thus upgrading from one 80M update to the next requires another 80M download. To mitigate this, milestones are released only once every month or two.
The current approach for numerous Eclipse.org projects, such as GEF, is to develop continuously in HEAD and when a number of changes are ready to be released, a tool such as the org.eclipse.releng.tools plugin can be used to, in a single operation, both tag the sources and release those tags into the map file.
This permits a granular approach to plugin versioning wherein only the plugins which have actually changed are renumbered, and thus incremental updates between releases is possible, and if only a single plugin changes from week to week, only that plugin will be upgraded.
This approach also allows your adopters to get more stable, weekly updates rather than hourly or ad hoc nightlies which may include incomplete changes. Sure, you can only watch for good builds in Hudson, but a more predictable schedule makes inter-build communication easier.
The only issue with this approach is that it introduces extra overhead, unless the tag&release process can be automated and run on a (weekly?) schedule. For CVS sources, there is the org.eclipse.releng.tools.tagandrelease crontab script available; for SVN, no such script (yet) exists. Want to help? See bug 264713.
With the Athena Common Build, you can set up a Hudson job to run from tagged maps, but also override those tags on demand to force a build from head (or trunk) instead of from the specific repo tags.
To do so, pass in the following flags to EXTRAFLAGS via your build's job configuration / parameters. To build from the workspace's sources instead of fetching anything new from the repo (bug 252774):
-localSourceCheckoutDir /opt/users/hudsonbuild/.hudson/jobs/${JOB_NAME}/workspace/
To fetch from the repo, but ignore tags (bug 251926):
-forceContextQualifier -fetchTag HEAD
Or, like many projects on build.eclipse.org have done, set up two jobs: one for nightly from trunk, and one for weekly integration from maps. Then instead of doing CI builds when you remember to, they will run automatically when the repo changes so you'll have immediate feedback when something has broken. Add email, IRC, or Twitter notification to the job, and everyone else will know too.
testLocal build step
failBuildIfTestFailuresOrErrors=true
PACK200_JAVA_HOME=/path/to/different/JDK
packageFeaturesIncludedBinaries=false
http://path/to/foo.zip to jar:file:/tmp/path/foo.zip!/
Annoyed that your boss didn't approve that expense to fly over to Germany for Eclipse Summit Europe? Well, fret no more!
Have we got a deal for you!
For only $40 you can attend Ontario [GNU] Linux Fest 2009 - a whole day of open source geekery from the following speakers! And, while there, stop by the Eclipse and Fedora tables for your chance to win some schwag!
I'd like to say we'll be giving away Slap-Chops or Sham-Wows too, but Vince will be rappin' & reppin' elsewhere. :)
About a week ago, Wayne Beaton approached me with an unexpected question: would I like to be drafted into the rank and file of the Eclipse Architecture Council?
I was honoured. Flabbergasted. And a bit apprehensive: could I measure up?
Well, it seems my first act as an AC member was, Thursday night, to cripple our shared Hudson build server by dumb-assedly performing a seemingly innocuous update. Heartfelt thanks to the Webmasters for once again extracting my cheeks from the fire and getting everyone's builds back up and running.
My second act, Friday afternoon, was to commit some "fixes" to the Athena Common Build code which effectively prevented it from reading your project's build.properties. Thankfully, the ever-vigilant Dave Carver spotted the snafu, filed a bug, and I had it my error fixed shortly after my return from Zombieland last night (aside: best zom-rom-com since Shaun Of The Dead!)
Thanks to Matt, Dave C, David W, Denis, Gunnar, and everyone else for reporting &/or fixing these issues, and to the AC for welcoming me into their fold. It's going to be interesting!
Have you heard the latest? Here's what's been going on in the Dash Athena project lately.
product=Dash&component=Common+Builder to product=Dash+Athena. Here's what's changed this week.
See also Older New & Noteworthy.
Contact:: Nick Boldt:: Toronto + Halifax, Canada Productization, Containers & Operators:: Red Hat CodeReady Workspaces |
  |
|
|