Archives for: June 2013, 14


  09:12:00 am, by The Dreamer   , 1412 words  
Categories: Healthcare, Quicken/TurboTax

Screwed by Quicken

A while back I was having trouble updating transactions in my TIAA-CREF account. I used to update my entering each transaction by hand every so often, but then a few years ago (when I rolled over a Rollover IRA, which I had parked my 401k of my previous employer, as the invisible money fee was huge....share counts would drop every month, with no explanation in the account statements.) I let them generate the funds I should spread my retirement into...which makes it much harder to be entering transactions by hand.

I had tried the Quicken download option, but the dates of the transactions didn't line up with my pay days or the website's transaction history. So, making the download match what I was entering was tedious, as was not entering any by hand and adjusting after download. Also, the download likes to splatter my register with placeholders, and the complain that the placeholders are missing information so it can't do gain calculations.

So, originally, I'd only like invest in 6 +/- 1 funds. Basically a fund out each slice and some multiple of 5% rather than the specific percentage an investment tool had suggested for me.

Now, I have my retirement funds spread of 12 funds in my Mandatory Plan, and 19 Funds in my Voluntary Plan (since the Voluntary has access to more choices than those specified by pension administrator.) The Mandatory Plan is funded by the mandatory 5.5% that comes out of every paycheck, plus an 8.5% match from employer. While the Voluntary Plan is money that came from other sources, which could be in the form of additional deductions from pay. But, in my case it represents what was in my previous 401k.

So, I just let the Quicken download be as it is....deleting most of the placeholder transactions, because the only transaction that doesn't appear anywhere is the share count growth of my TIAA-CREF Traditional Annuity. But, I just change them into reinvestment actions with a price of $1. Not sure how I would get quicken to tell me what the gain/loss % is from that....

Somebody had described how to do the math to get include re-investments into the overall gain, perhaps I'll have to look into that someday.

Anyways, I noticed that I somehow hadn't done a download in almost 2 months (since the download ranges are 30, 60, 90 or All), so I try to do it about every 30 days. Quicken doesn't seem too bright on knowing transactions that overlap the previous download aren't new, and it'll refuse to let me manually match them with the correct transaction, since it the transaction had already been matched (or created by a previous download). So, I have to delete some of the new transactions, along with all the placeholder entries...before accepting the rest.

Normally this works great....even if the dates happen a day or two before payday. It makes the transfer from my associated cash account for my Mandatory Plan...sure it might go negative...but it all zeros out in the end, usually.

But, then last fall, there was a weird extra $3 and change in my cash account. I kept looking for a missing transaction, but didn't see one. Eventually, I found that when it had done my annual birthday re-balancing...where it sells parts of some funds and Quicken transfers into my cash account, an then buys amounts in the other funds with Quicken transferring out of my cash account. It didn't do that when it added to my Wells Fargo Advantage Growth Fund Institutional. I fixed it by hand, somehow and continued on my way.

Full story »

  08:36:00 am, by The Dreamer   , 959 words  
Categories: Software, FreeBSD, CFEngine

Perl update + cfengine3 and subversion == great big mess on FreeBSD

So being up ridiculously early this morning, because I got up at the right time during the night...but forgot to take my second dose, and too late to take it when I woke again.

So, I thought I would tackle updating to the latest perl on zen. Choose not to just do a blind 'portmaster -r perl', since that would include anything that depends on being able to run perl or depends on something that depends on perl...possibly many levels down. Somebody should come up with a simple way to only rebuild the ports that directly depend on another port....

What I decided to do what after updating perl, was 'portmaster p5-*' then do a pkg_libchk to see what ports are missing and redo those.

I did this first by logging into my machine at work (mew) and it went quickly and worked pretty cleanly. Though there are only half the number p5- ports, and less ports missing as well.

So, back on zen...I updated perl and then started the 'portmaster p5-*', when it stopped. A port is dependent on /usr/local/bin/perl5.14.2, which is not found because I just updated to 5.14.4!

How do you have ports that are dependent on a specific version, especially since its possible to have a different version of perl. When I first installed zen, the default perl was 5.12.x...but I had elected to upgrade to 5.14.x when that became the new default. OTOH, when I setup cbox/dbox, I opted to go with 5.16.x...and at work, mew had started before zen, so it was also 5.12.x initially...but I choose to jump that up to 5.16.x (actually no .x at first, but it was very quickly followed by a .1...which inflicted a lot of pain again....though in this latest update they have switched to just major.minor for module path, which means no more pain until its time to upgrade to a newer minor release....

The first casualty was devel/p5-B-Keywords ...and I find its depended on by textproc/p5-Perl-Critic and textproc/p5-Test-Perl-Critic....with the last port being the leaf. So that seems to be that it was probably just a build depend for something I had installed long ago (since it doesn't sound like anything I could call in any of my own perl scripts.) So, I figure I'll just delete those packages and carry on.

Nope, the next port also fails with the same strange demand.


After hunting around a bit, to try and figure out what is making this port think it depends on the previous version of dawns on me that the perl port updates /etc/make.conf as to what version of perl is installed.

And, I have


being managed by cfengine3. :oops:

So, I go update the file, and try to svn commit the change....which blows up because the perl modules needed for the commit hook haven't been updated yet.

Well, guess I'll stop cfengine3 from reverting my /etc/make.conf (by disabling the promise from the root side) Though IIRC now, the commit hook is mainly to prevent root from doing commits into my subversion repository, instead of the put subversion on an NFS filesystem and have rootsquash prevent root from being able to write into the repository, that we do at work.

Phew....I can commit updated /etc/make.conf and let cfengine promise it. Perhaps in a future project, I'll see if there's some way to have cfengine set that dynamically or something.

Though should I have cfengine promising all of /etc/make.conf ? There's a block in /etc/make.conf that is the same across all my FreeBSD systems, since its the ports that I come across that don't like 'make -j#'. And, it was intended to have cfengine promise that part, though it there have been other additions that I want the same on all my FreeBSD systems, like the override on modules in net-snmp, that I mention when I ran into some cacti. Though there's value in having cfengine having the whole file....or rather its that the files are in subversion.

Next up...nagios has alerted me that spamassassin has stopped, yeah, I guess that would happen. Which means there's going to be a big chunk of spam in all my mailboxes (126...I need to find a good way to aggregate them back so that I can read them all ... from roundcube) module rebuilds are done, and spamassassin seems to be running again (probably because cfengine3 has a promise to keep for that) Though might work better if I do an 'sa-compile' to make sure that part is right...though seemed to me it was only major.minor....

Full story »

Now instead of subjecting some poor random forum to a long rambling thought, I will try to consolidate those things into this blog where they can be more easily ignored profess to be collected thoughts from my mind.

Latest Poopli Updaters --


There are 20 years 3 months 3 hours 55 minutes and 27 seconds until the end of time.
And, it has been 4 years 9 months 28 days 10 hours 7 minutes and 29 seconds since The Doctor saved us all from the end of the World!


June 2013
Mon Tue Wed Thu Fri Sat Sun
 << < Current> >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


  XML Feeds

Who's Online?

  • Guest Users: 2
This seal is issued to by StopTheHacker Inc.
powered by b2evolution

hosted by
Green Web Hosting! This site hosted by DreamHost.

monitored by
Monitored by eXternalTest
SiteUptime Web Site Monitoring Service
website uptime