Every been typing along somewhere and have your cursor jump across the page because your thumb hit the touchpad on your laptop accidentally?
Well, on some of those high priced commercial operating systems like Windows or MacOS there might actually be a setting or a keyboard shortcut that disables your touchpad. Us Slackware users are made of stronger stuff than most. We don’t want no silly buttons and keyboard shortcuts. We want scripts and command line stuff, right? We like to do things down at the nitty-gritty level of computing.
So, with that in mind, if you’re running Slackware/KDE, you can make yourself a nice little script that will disable your laptop’s touchpad and you’ll never have to cuss again when that cursor goes zooming across the screen while you’re typing that flaming post on USENET to that know-it-all Ubuntu dev.
Here’s what you do…
First check to see if you have a /home/<username>/.kde/env directory. If you don’t, create it:
you@your_system ~:$ cd .kde
you@your_system ~:$ mkdir env
You can also do this graphically, if you prefer, but we know you hardcore Slackers don’t do things graphically now, do you?
Anyway, once you’ve determined that you have the directory or have created one, you can now create the simple little script to place in there that will KILL that annoying touchpad.
Using vi, vim, or whatever editor you like, create this small file:
Save the file as “myenv.sh” in your /home/username/.kde/env directory. Make sure it is executable:
you@your_system ~:$ chmod 755 myenv.sh
Log out of your current KDE session and log back in. The touchpad from HELL is now as dead as weird uncle Bob’s hairpiece. WOO-HOO!
For those of you who occasionally use your laptop sans an external mouse, you can always revive the touchpad by changing the permissions on the myenv.sh file or just renaming it to myenv.inop. Since “inop” is an extension that the operating system does not recognize, it just ignores it. I’ve used “inop” to kill executables since way back in my Windoze daze. It works fine.
Anywho, I hope this little trick will make your Slackware/KDE computering that much more enjoyable. Oh, and I cannot take credit for this at all. A member of the kde.org forums called google01103 posted this tip in a thread over there about disabling that pesky touchpad. Credit where credit is due. That’s my motto.
Image credits: toilet laptop user – source/ownership unknown = If you own this image, please contact me regarding permissions/copyrights. ~Eric
Well, this article is just what you need.
Recently, over at Scot’s Newsletter Forums, we were discussing email encryption options and methods. It’s a fun thread. Give it a looksee. There is some good info and some useful links to be had. For me, this is the culmination of all the recent stories regarding NSA and FBI email and Internet snooping spurred by the revelations of ex-NSA contractor, and current guest of Mr. Putin, Edward Snowden.
People should be more conscious of their privacy, I think. You’d be amazed how many people think that email is private. I asked five of my family and friends about this in the past couple days. Everyone of them thought email was at least as private as 1st class USPS mail (snail mail). None of these folks were technical types. They were just aunts, truck drivers, etc… everyday people. Sadly, I’d bet that many techies out there are just a confident of the privacy of their emails.
With all this in mind, I’m here today to enlighten you just a bit about email privacy (or lack thereof) and simple, yet very secure, methods you can use to ensure that what you send to grandma will only be read by grandma. We’re going to talk a bit about email encryption using OpenPGP. You can do this in GNU/Linux, MS Windows, or MacOS. Encryption works everywhere for the most part. You just need a couple tools to make it happen.
My focus is on the Thunderbird email client using the Enigmail extension in GNU/Linux, Slackware to be specific. However, encrypting of emails and attachments is not difficult in any operating system. You just may have to use different means and applications to achieve it. Enigmail uses a protocol called OpenPGP. It is a very secure means of encrypting email and other documents using the Pretty Good Privacy data encryption method.
Security In-a-Box has created an excellent illustrated tutorial for setting up Enigmail in Thunderbird. I wouldn’t even attempt to top that one. Click on the hyperlink and learn very quickly and easily what you need to do to set this all up for yourself. In a matter of a few minutes, you can have your T-bird set up and capable of sending/receiving encrypted emails to your family, friends, workmates, etc.
For you MS Windows folks, there are also options. Windows Mail has a short FAQ regarding digitally signing and encrypting emails. It’s concise but informative. If you want to utilize OpenPGP in MS Windows, you can also do that thanks to the German government for creating an app called Gpg4win that allows you to set up and use OpenPGP in MS Windows just as you would in Linux.
There are quite a few good websites that explain email encryption, its methods, and the tools necessary to perform this feat. Here are a few to help you understand how this stuff works:
- Why Should You Encrypt Your Email – About.com
- How to Encrypt Your Email – PCWorld
- How Do I Send Encrypted Email – Ask Leo
It might seem complicated, and the encryption part is pretty heavy stuff mathematically speaking; however, to actually utilize the tools available to encrypt your email and documents is not at all complicated. You drive your car yet you have no clue how the internal combustion engine works, right? Well, there you go. You don’t have to be Einstein to encrypt your emails. C’mon! Even grandma is doing it. Give it a try. Encryption can be FUN! And remember…
Privacy is a right.
Security is YOUR responsibility.
Trust no one. Encrypt everything.
Have some fun with it. You might even learn a thing or two.
Image Credits: The Cone of Silence from the Get Smart television series. Image ownership unknown. Used without express permission. Contact author if this is a copyright violation. Image will be removed.
Don’t let KAOS read your mail.
Wow! What a refreshing idea; fix something rather than toss it in a landfill and purchase another. Who’d a-thunk it? Well, let me brief you younger folks on a bit of history…
Back in the Dark Ages… oh, say 25 years ago or so… we used to actually fix things. Yup. That’s right. When your dad’s Sony Walkman or mom’s Singer sewing machine stopped working for some reason, they’d take it into a shop where a repair person*, with actual knowledge of the device and real tools, would sit at a work bench and troubleshoot and fix the issue for them. Awesome, huh? Then, dad and mom would pay a small price (compared to the price of a replacement) and take their Walkman or sewing machine home for many more years of use and enjoyment.
Now, why did such a remarkably sensible solution to broken items go the way of the T-Rex? Well, it’s simple. Greed. Yup. That’s right. You youngsters may have heard me gripe about greed before. It’s an all-pervasive sickness in this world at the moment. I’m not here to bitch today, though. I’m here to tell you about a really cool website that might appeal to you tech nerds and geeks out there.
iFixit – it’s sorta’ like a Wikipedia for fixing stuff. Between this site and another old favorite of mine, How Stuff Works, you should be able to fix just about anything in your home, as long as you have the skills and can get the parts needed to do the fix. Fixing things yourself is rewarding. You feel you accomplished something. Wouldn’t it be cool to be able to fix that favorite old laptop of yours with the jammed up keyboard? You can do it. It could actually be rocket science, but hey… rockets aren’t that complicated. Really!
Well, next time you play with your little iThing, think about the 11 year old Chinese girl who works 16 hour shifts in the factory that makes that thing. Think about the entire countrysides laid waste by the mining of rare earths to make that thing work. Think about all your friends and neighbors who would love a job in a factory that makes stuff instead of some dead-end job in a cubicle farm of some call center. When your iThing breaks, FIX IT! That’ll piss Apple off, huh? Heh-heh…
*For 20+ years I was a component level electronics repair technician. That career no longer exists in the U.S. because very little is actually repaired here anymore. It’s a sad thing.
Image credits: Technician from clipartheaven.com.
Being able to have common profiles for my Mozilla products across operating systems on my main computer has been a dream for a few years now.
I tried this a few years ago between Slackware and my then secondary OS, Debian (stable). The way I had it set up then worked well until the day that Debian dropped FF and TB from their repos and started using their own IceCritters. Another problem I had back then was that Debian’s Mozilla apps were usually quite a bit older versions than the ones in Slackware. If the versions get too disparate, as they eventually did between Slack and Debian, the common profiles no longer function properly.
Later on, when I adopted Arch Linux as my secondary OS, I tried to run common profiles again. I had forgotten my lesson about needing similar versions of the Mozilla apps for the common profiles to work. Arch is much faster at getting newest versions into their repos than Slackware, so once again I had this version disparity issue. Since Mozilla’s recent change to the update-as-often-as-you-change-underwear schedule, I’ve learned to blacklist Mozila apps in Arch so they don’t get updated. Once Slackware puts out an update (I manualy download and install from current) for the Mozilla applications (Firefox, Thunderbird, Seamonkey), I allow the Arch update to go through.
Now that I have my Slack and Arch Moz versions the same or very similar, the common profiles should work. Below is a look at how I did it on my system. It will, of course, be different on yours, but the principles are about the same.
First, I used a common partition on a separate internal hard drive for my common profiles directory.
This partition automounts within my /home/<user> directory at boot up. You could theoretically use a thumb drive for this, if you wanted to. You’d just have to make sure that it automounts with the proper permissions at boot time.
Next, I copied the firefox and seamonkey directories from my Slackware (main OS) /home/vtel57/.mozilla directory into my newly created /home/vtel57/vtel57_common/common_mozilla directory. I also copied the contents of the .thunderbird directory into a directory called thunderbird also in /home/vtel5/vtel57_common/common_mozilla. You can perform these operations from the command line or in your GUI file manager app, as you prefer.
Now, in the /home/vtel57/.mozilla directory, I renamed the old firefox and seamonkey profiles to inoperative. The old profiles had some random <number/letter>.default as their name. I just added “inop” to the end of that to deactivate them. I did the same with the /home/vtel57/.thunderbird profile. This will prevent the apps from trying to use these old versions.
vtel57_Slackware~/.mozilla/firefox:$ mv 3mvew7qq.default 3mvew7qq.default_inop
Back in the new common directory shown above, I renamed the <number/letter>.default profiles to names that made more sense to me: ff_profile.default, tb_profile.default, and sm_profile.default.
Once I did all of the above, I needed to edit the profile.ini in each original application directory (/home/vtel57/.mozilla/firebird and seamonkey, /home/vtel57/.thunderbird) to point to the newly created common profiles. You can open your favorite gui or command line editor and make these changes to each profile.ini file. Here is my profile.ini for Firefox, for example:
*change the items in red to the ones in green
So now, whenever I fire up firefox, seamonkey, or thunderbird in either Slackware or Arch, they will be running off the same profiles; meaning all data, preferences, etc. are synch’d. Ain’t it great!?
I’m sure there are easier ways to do this, but this is how I managed it. You can experiment to find what works best for you on your systems.
Yes, I’m still on spring hiatus, but the place was getting to look a bit run down.
Plus, I wanted to show you all how to install this cool little browser that I found called Midori. Oh, it’s nothing new. It’s been around for a while, but it’s new to me. I first found it while using Salix OS recently on one of my tester partitions. I’m also using it in Zorin OS on one of my laptops. It’s fast. It’s pretty simplistic and minimal, too.
It is a bit complicated to install on Slackware, though. However, I’m sure you can do it. It just requires using some excellent SlackBuild scripts provided by the dedicated folks at SlackBuilds.org. Unfortunately, Midori is not one of those apps that you can install with just one SlackBuild. It has some dependencies… and its dependencies have some dependencies.
That always complicates things a bit, particularly in Slackware where you have to be smart enough to resolve dependency issues on your own. There is no a gaggle of volunteer repo maintainers doing it for you. That’s alright, though. Slackers are known to be smart and tough. We can take it. Dependency H3LL don’t scare us none.
Let’s get started, OK?
Fire up your current browser and navigate to SlackBuilds.org. You know the place. You’ve been there before. Once you’re there, you’re going to search and download six different SlackBuild scripts and their related source tar balls. Got that? OK.
Here they are (click for the SlackBuilds.org page for each one):
Midori is your ultimate goal. It requires webkitgtk, libunique, and vala. The others are dependencies of webkitgtk and will have to be built first and installed before you build webkitgtk.
You should be familiar with the whole SlackBuild thing by now. Just in case, though, I’ll run through one for you.
Let’s build libunique first:
1. Download the source and the SlackBuild
2. Decompress the SlackBuild (using Xarchiver or your favorite tool)
3. Move the newly untar’d directory to your favorite temporary build directory
4. Move the libunique source package to the untar’d libunique SlackBuild directory (see Fig. 1)
5. Open a terminal and make the script executable:
# chmod +x *Build
6. Execute the script:
# sh *Build
NOTE: If you’re building on a 64 bit Slackware, you should use the prefix Arch=x86_64. For example: # Arch=x86_64 sh *Build
7. Once the script completes, using Slackware’s pkgtool to install the newly created .tgz package you’ll find in your /tmp directory:
# installpkg libunique*
NOTE: You might also want to keep these packages somewhere safe in case you ever want to reinstall Midori on this system or another Slackware installation somewhere.
Now, we need to build and install the rest of the dependencies in this order: icu4c, libsoup, vala. Once you’ve built and installed these guys, you can then build and install webkitgtk. Something to keep in mind once you begin your webkitgtk build; it is NOT one of those zippity-fast builds. Even on a fast system, it may take 45 minutes to build. Just be patient. Don’t sit there waiting for the pot to boil. Go have some dinner or take a healthy walk around the neighborhood while it builds.
OK, assuming you’ve managed to build and install libunique, icu4c, libsoup, vala… and then webkitgtk, you should now be able to build and install midori. It’s a pretty fast build, less than 1/2 a minute. Install it using pkgtool, as you did with the others above. If all went well, you should have a nice working Midori browser on your system now. If you run Xfce4 like I do, it will automagically show up in the Menu –> Network sub-menu.
Here’s my Midori running with the Midori Home Page opened:
NOTE: That’s an April Fools post you’re seeing there about merging Midori with Postler.
Have lots of FUN!
P.S. I’m going back on hiatus now. See you again soon…
Let me state right out in the open here that my knowledge of computer networking is lacking. I’m learning as I go.
For most of the time that I’ve used computers in my home, I’ve only had one machine going at any given time. This past year or so, though, I’ve gained two more systems in addition to my main system. I have a laptop and a shop system up and running now in my home. The laptop connects via Ethernet or wireless. The shop system, which is outside in my workshop connects via wireless 100% of the time.
The main OS on all three of these systems is Slackware. For a year now, I’ve been running back and forth with thumb drives or CDs filled with data to keep the systems in sync with one another; mostly my personal documents, music, and Mozilla settings. I occasionally use DropBox for small files, but it’s not feasible for larger stuff due to its slow upload speeds. Cloud computing ain’t never going to work as long as ISPs throttle upload speeds.
Anyway, back when I first got the laptop, I attempted to network it with my main system. I failed miserably and ended up throwing in the towel. You can read about that learning experience in this long thread at Scot’s Newsletter Forums – Bruno’s All Things Linux. You’ll see that quite a few folks there were trying to help the dunderhead get his systems linked. Well, I finally succeeded just this past weekend.
Sometimes, you just have to walk away from a problem for a while.
Here’s how I finally got it working using ssh:
- Make sure that the ssh daemon script is executable so that it will run at boot up
#chmod 755 /etc/rc.d/rc.sshd
- Modify the /etc/ssh/ssh_config as follows:
# Port 22
Port <your port choice>
# Protocol 2,1
*Either un-comment and change the default port setting and the protocol or just add a line, as I did.
The purpose of this is mostly for security. Changing the port to a port of your choosing enhances your “security by obscurity” chances. Changing to to Protocol 2 is recommended because there are security flaws in Protocol 1.
- Modify the /etc/ssh/sshd_config as follows:
Port <your port choice>
# The default requires explicit activation of protocol 1
- In your router’s Administration preferences (see your manufacturer’s instructions) you’ll need to set each device you plan on linking via ssh to use a static IP address. This has nothing to do with your ISP’s assigned IP address. This is just your home network we’re talking about here. The router assigns an IP to each device hooked to it. In order to ssh into remote devices, you’ll need to make sure the devices’ IP addresses don’t change (static).
That’s it. You are ssh’ing now, my friends.
It’s easy to access your remote machines now.
$ssh <username>@<device name>
The username is the name of the account that your are trying to access on the remote machine, say your wife Debbie’s account. The device name is the domain name of the device. Like this…
Once you enter the password for Debbie’s account, you’ll have access to her user data and privileges.
In Arch Linux, the process is a bit simpler. First, make sure you have openssh installed on your Arch system. You still need to modify the ssh_config and sshd_config files in a similar fashion, but the getting the daemon to run at boot time is as simple as just adding “ssh” to your /etc/rc.conf file.
You can manipulate (edit, backup, copy, etc.) files on remote machines using ssh from the command line. However, to transfer files between machines, you might want to use ftp. It’s easier, in my opinion. Personally, I use gFTP in Slackware and Arch for this. There are many other choices out there, though. Use whatever works best for you.
So, there you have it. My next project is going to be adding my printer to my router’s USB connection and setting it up as a network printer for all three of my systems.
I’ve been busy designing a website for a client this past week or so.
I just wanted to pop in here real quick-like and tell you about a good article I just read over at Linux Journal. It’s a mini command line tutorial on how to backup CDs to .iso files. You’ll like it.
Learn something. It won’t hurt you none. I promise.
SlackBuilds are custom written installation scripts used to install non-native applications into your Slackware Linux operating system.
For today’s little SlackBuild tutorial, I’m going to use a SlackBuild to install PysolFC, a collection of really cool card games and majong-type games that is maintained by my friend Matthew Fillpot. Matt is one of the lead gurus over at the Linux.com Community site. Stop on over for a visit sometime.
One of the first things I do on any of my Linux installations is to create a hidden directory called .build in my /home directory that I use primarily for manual compiling of applications, or in this case in Slackware, installation of SlackBuild scripts (see Fig 1).
Figure 1 – /home/<user>/.build
OK, let’s get started. The first thing you’ll need to do is navigate to SlackBuilds.org in your favorite browser. In the small search window in the upper right hand corner, type in the application you’re looking for. In this case, that would be PysolFC. Once the search is completed, you’ll be on the pysolfc SlackBuild page (see Fig 2).
Figure 2 – Pysolfc SlackBuild Page
Now, the next thing you’ll need to do is download the source (PySolFC-1.1.tar.bz2) and the SlackBuild (pysolfc.tar.gz) into your .build directory (or wherever you want to build your stuff). Untar the SlackBuild script from the command line using this command:
$ tar -xvf pysolfc.tar.gz
Or you can unpack it using your favorite graphical decompression app like Ark or Xarchiver… use whatever you’re comfortable with.
You’ll now have an uncompressed directory called “pysolfc”. Move the source directory (PySolFC-1.1.tar.bz2) that you downloaded previously into your newly uncompressed pysolfc directory. That’s right. Just grab and drag that source directory right on into the pysolfc directory (see Fig 3).
Figure 3 – Inside the Pysolfc Directory
OK, then… Now for some fun command line stuff. I know you love working in the command line. Don’t be afraid. Just follow my directions. Alrighty…
1. Open your terminal application (Gnome Terminal, Konsole, etc.)
2. Type the following command to make the pysolfc SlackBuild script executable:
$ chmod +x pysolfc.SlackBuild
3. As root (to install globally on your Slackware system so all users can access), type the following command:
4. If all went well, the SlackBuild script will have created a .tgz application installer in your /tmp directory. Navigate to the /tmp directory in the terminal:
# cd /tmp
5. Check to see what’s there:
6. You should see a file called pysolfc-1.1-i486-2_SBo.tgz. That’s the baby! Install it using Slackware’s native pkgtool:
# installpkg pysolfc-1.1-i486-2_SBo.tgz
Voila! That’s it, folks. Easy-peasy. You’ll find an entry for PysolFC in your menu. Click on it and waste a few hours of your life playing some of those funky solitaire card games or that majong stuff.
Have FUN with it…
Note: This article originally appeared on my Nocturnal Slacker/Lockergnome blog (now defunct).
… you can’t have just one.
Multi-booting – My Way
I’ve been multi-booting since I first came to Linux. Originally, it was due to my transition from MS Windows to GNU/Linux. Later, it was because I wanted to try more distributions. I was still hunting for the one that fit me best. I’ve since found that distro (Slackware). However, I still have multiple operating systems on my computer for varying reasons.
My current hard drive partition and usage map looks like this:
SATA 1 – Main/Secondary OS + Linux Archive
Primary – 25Gig: /(root) Slackware on /dev/sda1 (ext3)
Primary – 50Gig: /home Slackware on /dev/sda2 (ext3)
Extended – 175Gig: /dev/sda3
Partition – 25Gig: /(root) Debian on /dev/sda5 (ext3)
Partition – 50Gig: /home Debian on /dev/sda6 (ext3)
Partition – 2Gig: /swap (common) on /dev/sda7 (swap)
Partition – 98Gig: Linux Archive on /dev/sda8 (ext2)
SATA 2 – MS Windows + Experimental Operating Systems
Primary – 25Gig: MS Windows Main on /dev/sdb1 (ntfs)
Primary – 25Gig: MS Windows Programs on /dev/sdb2 (ntfs)
Extended – 200Gig: /dev/sdb3
Partition – 2Gig: /swap (common) on /dev/sdb5 (swap)
Partition – 15Gig: /(root) CentOS on /dev/sdb6 (ext3)
Partition – 25Gig: /home CentOS on /dev/sdb7 (ext3)
Partition – 15Gig: /(root) Arch Linux on /dev/sdb8 (ext3)
Partition – 25Gig: /home Arch Linux on /dev/sdb9 (ext3)
Partition – 15Gig: /(root) PCLOS on /dev/sdb10 (ext3)
Partition – 25Gig: /home PCLOS on /dev/sdb11 (ext3)
Partition – 15Gig: /(root) Sidux on /dev/sdb12 (ext3)
Partition – 25Gig: /home Sidux on /dev/sdb13(ext3)
Partition – 15Gig: /(root) Mandriva on /dev/sdb14 (ext3)
Partition – 23Gig: /home Mandriva on /dev/sdb15 (ext3)
EIDE 1 – Backups
Primary – 50Gig: Slackware Backups on /dev/hda1 (ext2)
Primary – 50Gig: Debian Backups on /dev/hda2 (ext2)
Extended – 150Gig: /dev/hda3
Partition – 50Gig: MS Windows Backups on /dev/hda5 (FAT32)
Partition – 50Gig: Other OS Backups on /dev/hda6 (ext2)
Partition – 50Gig: OS Common Storage on /dev/hda7 (FAT32)
These three drives add up to three quarters of a Terabyte of space… way more than I actually need. However, space is cheap these days. I still remember paying $100 for a 10Gig drive less than ten years ago. Previously, SATA 1 and 2 were in RAID 1 (mirrored) configuration with MS Win XP Pro on them. What a waste. I rarely ever boot that OS these days (games only), so I broke the RAID down and repartitioned/reinstalled everything on my system.
The ten partitions you see on the SATA 2 drive are my experimental Linux slots. When this partition map was made, I intended to put CentOS, Arch, and Ark back on them, with the last two saved for Gentoo and maybe FreeBSD. It didn’t work out quite that way, as you can see. What is installed on those experimental partitions tends to change often.
A few things to take note of when partitioning and multi-booting in this fashion:
1) Remember the SATA 15 partition limit. Many newer distros use the libATA kernel drivers which force drive recognition as SATA regardless of whether the drive is EIDE or SATA, so for this reason remember to place your /common partitions and /swap partitions on the lower numbered ones. A libATA distro installed anywhere else on the lower 15 partitions (or another drive) will still be able to “see” and mount them this way.
2) MS Windows is like the “Borg” when it comes to being installed on a computer with other operating systems. It seeks out and destroys other operating systems. Be sure to install MS Windows first. It needs to be on the first partition of whatever drive you’re installing it on. After which, you can install your GNU/Linux distros safely.
3) Install your MBR controlling distribution last, time-wise, regardless of which partition/drive you’re installing on. This will allow it, especially in the case of Debian’s excellent GRUB, to “see” all the other installations and write them into your menu.lst for you. Even though Slackware is my primary operating system, and since I don’t use LILO, I allow Debian to control the MBR and boot my system with its GRUB.
4) Lastly, as in the case above, if your MS Windows installation is on a different drive than your MBR controlling OS, then your BIOS may have troubles booting the correct drive. No matter what you choose in BIOS as the first device, the Windows drive will boot. The reason for this is that Windows installs a bootable flag on its own drive. This flag gets priority from the BIOS. To set a bootable flag on the drive that you want to boot will require a bit of manipulation using a Live Linux CD* and the fdisk command.
Boot your Live CD and start it. From a terminal session within the CD do the following:
# fdisk /dev/
fdisk> a (option to toggle bootable flag on drive
–partition number? 1 (first partition on the drive)
fdisk> w (command to write the new info to disk and exit fdisk)
–bootable flag reset for this drive
This will set the bootable flag to the drive you choose. Reboot, go into BIOS setup and choose your first boot drive. It should boot fine now.
*Another option to use is the way I actually did it on my own system… I used SLAX on a flash drive to perform the fdisk above. Worked like a champ!
Anyway, that’s the way my system is set up. Whenever I add or change operating systems, I just edit the Debian /boot/grub/menu.lst to reflect those changes.
Have fun with it!
Until next time…
Note: This article first appeared on my Linux.com Community Blog (now defunct). Some of the above is out-dated. I currently only run Slackware (primary), Arch (secondary), CentOS (tester1), and Debian (tester2).
Some of you Slackers out there who use this panel applet may have noticed that it’s no longer updating.
There’s a reason why: Xfce Bugzilla – Bug 8105.
I’d been sloughing this off for a few weeks now. Today, I decided I was going to find a way to fix the damned thing… or dump it from my panel. I had noticed last night that it was still working fine in my Arch installation. Hmm… seems that the Arch folks patched their package with a working license key and partner ID to alleviate the bug issue reported above.
The first thing you want to do is extract the /xfce4-weather-plugin-0.7.4/panel-plugin/weather.h file from the source tarball. Modify this file as per the patch linked above by exchanging the old license key/partner ID for the newer ones:
#define PARTNER_ID “1121946239″
#define LICENSE_KEY “3c4cd39ee5dec84f”
#define PARTNER_ID “1003666583″
#define LICENSE_KEY “4128909340a9b2fc”
Once that’s done, save the file and add it back to the tarball.
Now you can build and install your SlackBuild as you normally would. After which, your xfce4-weather-plugin will work again. YAY! Thanks, Robby!
NOTE: I found no need to modify the SlackBuild file as Robby does for his patch. It worked fine without any changes.
Enjoy your weather, wherever you may be.