My favourite CAD software used to run on at least ten different platforms, including my trusty SGI Indy. There was even a Linux student version. Evidently the market spoke, and for nearly twenty years the software has been Windows-only.

Between IRIX and Linux, I’ve never had a need to allow Windows across the threshold (not least because I could get my fill by going to work). Six years ago I needed to run the CAD software at home again, so I bit the bullet, bought a Windows DVD and started dual-booting it on a desktop machine.

Sensing the completion of the work, the hard drive died, and I dismantled the computer. When I needed to reinstall the CAD software this year for some freelance work, I used the DVD to install Windows into Boxes on my laptop. In the spirit of the Bill Gates quote that never happened, I specified twice as much disk space as I could ever imagine needing. Naturally, the OS and app together consumed the alotted disk space to within a few kilobytes. I needed to resize.

The Red Hat and Fedora Guest Resizing pages were nearly what I wanted, but my libguestfs tools are too new, the first partition is already a good size, and my second partition isn’t a logical volume. Here’s what worked (as usual, if there’s a better way please set me straight):

cd ~/.local/share/libvirt/images
mv Win7.qcow2 Win7.backup
qemu-img create -f qcow2 Win7.qcow2 100G
virt-df -h ./Win7.backup
virt-resize ./Win7.backup ./Win7.qcow2 --expand /dev/sda2

Since the drive resizing I’ve been able to downgrade the CAD software to an earlier version, so 40 GB probably would have been plenty. I think I’ll leave it, though, because my laptop is relatively new and has all the disk space I could ever need.

The lesson might appear to be Windows’ disinclination to be contained, but a licensing issue with the CAD software took a few weeks to resolve. In the interim I continued to do remarkable things with FreeCAD. I’ll use the proprietary software for details related to transferring the files, but FreeCAD is very close to keeping my CAD experience Windows-free.

Last March, the Toronto area GNOME 3.20 release party happened to fall on release day. This release day saw Nancy and me at the hospital for the birth of our second grandson, Gord and Maggie’s second boy. Name suggestions honouring the occasion (GNOME with any manner of capitalization, Portland, or Three Two Four) were politely rejected in favour of the original plan: Finnegan Walter “Finn” Hill. Welcome to Finn and the new GNOME.

Photo by attente.

I had the privilege of sitting in on the GTK+ hackfest in Toronto last week, getting re-energized for my day job by hanging out with developers from Canonical, Collabora, Endless and Red Hat. Toronto is a fabulous city for a hackfest, and Red Hat provided a great workspace.

While there, I reviewed some user help and updated some of the Settings pages. The Transformer makes a good hackfest computer, lightweight enough for a great deal of walking, and comfortable to use when paired with the right keyboard. Remarkably, it has sufficient resources for running Continuous-in-a-Box.

There’s nothing quite as dramatic as a GNOME controversy at its epicentre. The decision-making process is as open and visible in person as it is on IRC. There is no behind the scenes.

Debian Stretch

After successfully building 32-bit kernels using the Fedora method, I decided to try 64-bit Linux on my ASUS Transformer Book T100TA. The Debian multi-arch installer successfully deals with the 32-bit UEFI boot installation, and even better, certain pre-packaged Ubuntu kernels can simply be installed. Here’s my experience with the upgrade.

I started with the DebianOn ASUS T100TA wiki page. Particularly crucial is the grub command line switch for the cstates issue.

After a bit of trial and error with the install isos— couldn’t locate the correct wifi firmware on the Jessie non-free firmware netinst iso, the Alpha 5 Stretch multi-arch DVD iso would start but never complete the install to the eMMC drive—I settled on the Jessie multi-arch DVD iso with 3.16 kernel. This gave me a running Cinnamon desktop—the iso didn’t contain sufficient packages to switch to GNOME.

I located and installed the wifi firmware according to the wiki page instructions and connected using wpa_supplicant. The upgrade to Stretch and GNOME was a challenge because the wifi connection would drop every few dozen megabytes. It finished after several hours, and I had a running GNOME 3.20 desktop (something I never achieved on the Fedora install). I then…

• switched to NetworkManager and re-installed the wifi firmware (the latter seemed to fix the issue of the connection cutting out).
• installed non-free intel-sound firmware and the t100_B.state file, then applied Vinod Koul’s settings for working audio (be sure to keep the volume down for testing).
• enabled and started ModemManager and installed the mobile-broadband-provider-info package to tether my phone.

The ASUS T100 Ubuntu Google+ community is a volunteer effort geared toward establishing which kernel patches, firmware, and configuration settings are required to get the hardware in the various T100* models working in Linux. Although the stock Debian Stretch kernel (4.5.0) boots with working wifi, the Ubuntu kernel packages from the G+ page (4.4.8.2 and 4.4.9.1) boot with working wifi, sound, mobile broadband, and Bluetooth. There’s still work being done on the camera driver and I haven’t tried anything with the touch screen, but at the moment my GNOME tablet experience is reasonably complete.

Corrections and suggestions welcome.

Fedora 23

As Pa Bailey might have put it, it’s deep in the race to want to run GNOME on your tablet. At last year’s Libre Graphics Meeting in Toronto, pippin displayed GNOME on his Lenovo MIIX 3 Bay Trail device. A few months later I was able to pick up an ASUS T100TA with similar specs (if not as elegant) for a good discount. Adam Williamson’s latest Fedlet release was days old at the time, and I installed it.

I’ve been through the Fedlet installation three times, the second and third installs necessitated by some newfound inherent skill at rendering the device unusable. The installation is nerve-wracking on account of some missing or invisible buttons in Anaconda, so I’d rather upgrade than re-install. The processor supports 64-bit Linux with 32-bit UEFI, but at this point I’m happy with the 32-bit kernel. (The experience of local LUG members suggests the Debian multiarch installer will address the 32-bit UEFI while installing a 64-bit system, but a brand new Ubuntu installer will not.)

There’s a Google+ Community dedicated to running Ubuntu on the different varieties of T100. After some weeks of reading about further advances specific to the hardware, I wasn’t satisfied with the Fedlet 4.2 kernel and decided to build a newer one. For ease of installation and removal, Fedora kernel packages are worth the small effort required beyond simply compiling a kernel. The procedure on the wiki page is pretty comprehensive; below are the changes I needed to get mine working. First some notes:

• ‘dnf upgrade’ on the newly-installed Fedlet led directly to the first from-scratch re-install. Since then I’ve installed specific required packages with dnf using ‘–best –allowerasing’. I’m still running Fedora 23 to prevent the loss of any of the customized packages (other than the kernel) from the Fedlet repo, but hopefully it will become possible (if it’s not already) to do without them. I would experiment, but at this point it’s easier to just avoid the risk.
• the last re-install was required after I built a kernel that was capable of eating the contents of the eMMC hard drive.
• sometime between 4.2 and 4.6, a dracut upgrade was required to enable the kernel installation to complete.
• the 60 GB hard drive needs a hefty percentage of free space to perform the build: I usually delete the contents of BUILD and BUILDROOT from the previous build, and keep my music on the removable SD card.

Asus T100 Ubuntu: progress reports, patches and config file, sound configuration (sound works with kernels older than 4.6-rc* but so far 4.6 breaks it). The About this community panel has a Google Drive link called Asus Files with all the good stuff.

These are the sections I follow from Building a custom kernel. Please consult the original page for the details.

Dependencies for building kernels
Yes.

Skip to…
Building a kernel from the source RPM: Get the Source
I grab the kernel source package from Koji that corresponds to the patches in the Google Drive folder.

Prepare the Kernel Source Tree

rpmbuild -bp --target=$(uname -m) kernel.spec

Use ‘target=i686’ if building on my x86_64 laptop (hypothetical at this point since I haven’t successfully done this).

Copy the Source Tree and Generate a Patch
Skip this section: at this point I apply the patches (from the Google+ page) directly to the linux-* folder. I’ve performed the operation of copying the tree to create a single patch, but haven’t been successful automating it with ApplyPatch in the .spec file.

Configure kernel options
Copy in the config file acquired from the Google+ page.
Step 5 is i686.

Prepare Build Files
Customize the buildid in the .spec file (.mdh in my case).

Build the New Kernel
Use ‘noprep’ to prevent refreshing the source tree and re-applying the Fedora patches.

rpmbuild -bb --noprep --with baseonly --without debuginfo --target=`uname -m` kernel.spec

Use ‘target=i686’ if (someday) building on my x86_64 laptop.
On occasion at this point I need to rename the ~/rpmbuild/BUILD/kernel-*/linux-* folder to include the buildid  and fc23 instead of the version from the source rpm (currently fc25).

I usually do the last step with the power connected, but occasionally carry it to the car and back for the trip to work, so as not to interrupt the build. If it finishes, a full set of packages should appear in ~/rpmbuild/RPMS/i686.

Corrections and recommendations welcome.

Platform 53, a remarkable co-working space in Covington, Kentucky (across the river from Cincinnati) was the setting for GNOME’s Open Help doc sprint this week. We spent three intense days updating the GNOME User Help for 3.18. I reviewed and updated the networking pages to reflect a number of changes.

A big part of our mission is to test all of GNOME’s features so we can write accurate help pages, and find out what works. A number of issues were uncovered and reported, and some of the solutions will be implemented in 3.18.1. The Documentation Team is a perfect mix of writers, developers, friends.

As a team-building exercise, Cincinnati treated us to a Major League Rain Delay, followed by a baseball game. Our productivity was heightened by a prodigious amount of walking around the city and over the river.

Many thanks to Shaun McCance for organizing a sensational event, and Syllogist and Red Hat for sponsoring it. Thanks to the GNOME Foundation for enabling me to attend.

Photo by Petr Kovar.

It was a rare spring day in April when a visiting dignitary from Norway prompted a spontaneous release party.

Tea and crêpes at Café Crêpe

Here’s an awesome idea… schedule FOSDEM right after a docs hackfest! A hired carload of us accompanied Kat and Dave from Norwich, on the Eurotunnel Shuttle. We brought Mallard balls.

It was a blast working in the GNOME booth on Sunday afternoon, alongside Alexandre, Nathalie, Tobi, Fred, and Baptiste. The enthusiasm of Tobi and Bastian Ilsø was infectious. In the spirit of catching flies with honey, Alexandre and Baptiste used the Mallard balls to good effect promoting Mallard.

Baptiste et Alexandre s’allient afin de donner une démonstration en profondeur après une pêche fructueuse à l’aide d’une balle Mallard.

After his visit in 1848, Charles Dickens wrote of Norwich, “in short, some of the hackfest’s noisiest authorities insisted on its being received in the superlative degree of comparison only.” (He would famously reuse the line in part one of an upcoming serialization.) It was Robbie Burns, however, who wrote in the song “Highland Mary” the words about it that Norwich would one day adopt as its motto: “A Fine City.” For those of us who were there, it was so much more.

The walks were long and invigorating, the weather was marked by a distinct lack of snow and sub-zero temperatures, the architecture was positively mediæval, the space at the university was ideal, the tea was abundant and varied, the hospitality was wonderful. It was the best.

Sunshine over the University of East Anglia.

Some Lessons Learnt:

• Elementary Chicken Care
• Proper Use of British Power Tools
• Distinguishing Crisps from Chips
• Tea Brewing for Coffee Drinkers
• Looking the Wrong Way First When Crossing

A particularly tricky Baobab debugging session ChezKatDave.

It was fascinating to observe and participate in the processes at this hackfest: the redesign of Yelp, brainstorming the developer docs, planning the future of desktop help. It was an event of instant gratification: bug fixes and feature requests courtesy of Fred and Shaun, bug annihilation by André and Dave, system issues dispatched by Dave and Ryan, decisions on terminology. Julita colourfully plotted the downfall of the Evolution index page.

Round table discussion at the university (photo courtesy of Baptiste Mille-Mathias)

For my part, it meant working with Phil again to rewrite and update the System Monitor docs for Kat to review; a final review of Bijiben help after work by Shobha and Aruna; assessing the gaps in Boxes pages with Zeeshan; updating the application help inventory with Kat (with the ability to verify everything in GNOME Continuous); and occasionally unleashing a brood of chickens on an unsuspecting garden.

Hacking at the venue.

Many thanks to the GNOME Foundation for the travel sponsorship, and to the University of East Anglia’s School of Computing Sciences for hosting us. I can’t thank Kat and Dave enough for putting us up in their home and showing us their little corner of England in spectacular fashion… proper English fish and chips, real English pub fare, full English breakfast, cream tea, Fawlty Towers. Hopefully Shobha and Aruna can get visas next time.

On his visit to Cambridge in 2012, Richard Schwarting said, “GNOME 3 makes me happy.” Working passionately on GNOME has not only made me happy, it has made me good friends who are passionate about working on GNOME.

When writing documentation for GNOME, it’s essential to be running the latest version. GNOME Continuous provides a ready-to-boot virtual machine image containing much of the GNOME stack straight from git. As a bonus, Boxes will open and run the image as soon as it’s downloaded. (In Fedora 20 it’s necessary to sidestep this bug but Colin’s installation instructions reflect this.)

When the image is up and running in Boxes, you can use jhbuild to install additional apps, as documented by Andreas… I use this procedure to add Yelp. You can also try setting it up for external network connections as detailed in Ben Kahn’s blog entry.