Oh, the Windows/Fedora time schizophrenia…

Every other beta test release, my time zone goes askew, thanks to Windows defaulting to keeping the hardware clock at localtime and Linux kernel+userland’s ever shifting way of dealing with this (to be fair, at least they tried – OS X just insisted on the clock being set to UTC).

Right now it seems that systemd¬†expects the kernel to assume the clock was UTC and so it had to do the heavy lifting of adding the 7 hours offset — but somehow the kernel (or some other utility?) has already added those 7 hours, with the result that my clock ended up 14 hours ahead. And somehow this didn’t manifest itself until I booted to Windows to pull some pictures from my Lytro…


Going to try a clean installation first, to reduce the possible things that could go wrong – and help test the new Anaconda installer in advance of the Fedora 18 beta – but if this fails, I’m seriously going to just tell Windows to use UTC (though *that* codepath there is not well tested either, and used to be buggy in Windows XP and Vista).


Update: after a complete reinstall (still using the F17 installer since the pre-beta live image is broken), having verified that on F17 prior to upgrading it works, the same issue still occurs. Bug filed; moving on to more productive endeavors for the rest of the weekend.

Advertisements

Oh, Oracle… (on dates and sane defaults)

An Oracle DATE stores timestamp information as well, with reduced granularity, while a TIMESTAMP also store timestamps. With the result that if you use DATE Oracle’s own SQL Developer tool assumes, by default, that you don’t want the (less accurate) timestamp and default to only showing the date part.

Compare and contrast with PostgreSQL’s sane types and weep. To paraphrase that saying, friends don’t let friends use Oracle products.

Google Music Manager not installable on RPM systems: workaround

Per the subject line, Google’s Music Manager software (used for uploading music to its cloud offering, Google Play Music) is currently not installable on RPM systems, at least Fedora 17 and the pre-release of Fedora 18.

This seems to be either due to changes in Google’s packaging of google-musicmanager-beta, or changes in how strictly RPM validates packages with duplicate directory ownership — as attested by the error message:

Transaction Check Error:
  file /usr/bin from install of google-musicmanager-beta-1.0.43.6722-0.x86_64 conflicts with file from
package filesystem-3.1-2.fc18.x86_64

Contacting Google is so far an exercise in futility (they really need to beef up on technical support — anyone who has tried filing Android bugs and feature requests could attest to this):

  • when sending a support request online, the clueless response is from someone who clearly does not understand Linux at all. He suggested I might have a corrupt download
    <facepalm />
    
  • when sending an email to the address listed in the RPM metadata:
    $ rpm -qpi ./google-musicmanager-beta_current_x86_64.rpm | grep -i packager
    Packager    : Google Music Team <musicmanager-linux@google.com>
    

    Believe it or not, that email address bounces…

Which leads me to using a workaround:

mkdir -p ${sometempdir}
cd ${sometempdir}
rpm2cpio /path/to/google-musicmanager-betacurrent${arch}.rpm | cpio -vid
mkdir -p opt/google
mv opt/google/musicmanager /opt/google

and then just launching Music Manager manually whenever I need to — probably not worth manually registering the application entry and the cron (scheduler) job also in that package.

If anyone has a contact who does Linux packaging for Google, please forward this to them — thanks!