Entry tags:
Code on 32 bit arch (and other stuff).
Hi everyone! I'm Frank and I'm in charge of the DJ code upgrade from old LJ -> DW. If you get tired of my dev posting just holler and I'll move everything over to zilla. Yes, I am the guy who started/ran-forever DeadJournal.
I just got a snapshot of the old DJ database up and runnning on the DW code. Ran update-db.pl (that script gives me heartburn like you would never believe). All db modifications/changes and theme population etc ran without error.
This is a standard debian etch install. Nothing special about it.
Going to a journal brings up the journal/theme/userpic/etc (hooray). However clicking to view comments gives me a 500 error with the following in the error log:
[Mon Aug 17 21:49:44 2009] [error] [client 10.172.20.254] Invalid type 'Q' in pack at /home/dj/cgi-bin/LJ/Entry.pm line 1492.\n, referer: http://scsi.dj.dmz.vadept.com/
Line 1492 (when Columbus sailed the ocean blue, or mid-way through get_log2_row) reads:
# note: this cannot distinguish between security == private and security == usemask with allowmask == 0 (no groups)
# both should have the same display behavior, but we don't store the security value in memcache
$row = pack("NNNQN", $item->{'posterid'}, $eventtime, $logtime, $sec,
$item->{'ditemid'});
As far as I can read, Q is 64-bit arch only, which my test server is not. http://perldoc.perl.org/functions/pack.html
Changing that Q to an N makes it work (although it doesn't bring up any titles in the comments, and the update-db.pl script was complaining about unknown table logsubject2) however it makes apache segfault almost continuously.
This "Q" pack is in multiple places in Entry.pm from posting to viewing, etc. Maybe a config option for 64 vs 32 bit archs? Am I in left field?
I just got a snapshot of the old DJ database up and runnning on the DW code. Ran update-db.pl (that script gives me heartburn like you would never believe). All db modifications/changes and theme population etc ran without error.
This is a standard debian etch install. Nothing special about it.
Going to a journal brings up the journal/theme/userpic/etc (hooray). However clicking to view comments gives me a 500 error with the following in the error log:
[Mon Aug 17 21:49:44 2009] [error] [client 10.172.20.254] Invalid type 'Q' in pack at /home/dj/cgi-bin/LJ/Entry.pm line 1492.\n, referer: http://scsi.dj.dmz.vadept.com/
Line 1492 (when Columbus sailed the ocean blue, or mid-way through get_log2_row) reads:
# note: this cannot distinguish between security == private and security == usemask with allowmask == 0 (no groups)
# both should have the same display behavior, but we don't store the security value in memcache
$row = pack("NNNQN", $item->{'posterid'}, $eventtime, $logtime, $sec,
$item->{'ditemid'});
As far as I can read, Q is 64-bit arch only, which my test server is not. http://perldoc.perl.org/functions/pack.html
Changing that Q to an N makes it work (although it doesn't bring up any titles in the comments, and the update-db.pl script was complaining about unknown table logsubject2) however it makes apache segfault almost continuously.
This "Q" pack is in multiple places in Entry.pm from posting to viewing, etc. Maybe a config option for 64 vs 32 bit archs? Am I in left field?
no subject
I know that in some cases (people running a linux box at home) they're still 32...but most production hardware setups (as well as VPS like Slicehost/Linode/etc) should have the ability to run 64 bit.
Is 32 a hard requirement for you?
no subject
I can manage to obtain/steal a 64 bit box. We are using Amazons AWS which (i believe) is all 64 bit (at least it should be). Wasn't sure if the 64 bit was a hard requirement or if I stumbled upon something.
no subject
I do not see how the code would -require- 64bit address space and instructions. Using 64bit size files for database, etc has been around for quite a while, but I need more information on what the exact issue is.
I guess there needs to be a bug # to complain on more.
no subject
RE: It's 2009, do people really have 32 bit kicking around that much?
I currently have *counts* 5 functioning systems within in my sphere of influence. (Translation: that I can modify with impunity.) Only one of those is a 64-bit system. (Also, feel loved, that system was only acquired recently so that I could code-poke DW with sticks.)
no subject
* Please, please, please post to this community as much as necessary as you go through the process! Our install/upgrade documents are kinda shit at this point; we know they are, and are working on them, but it's slow going.
* Anything you run into that seems weird or counterintuitive, anything you think needs documenting, or anything that makes you go "damn I wish I'd known that", please do note on the Wiki so future generations can benefit from your knowledge, pain, and suffering.
* EEEEEEE YOU GUYS ARE GONNA USE OUR STUFF OMG THIS IS SO EXCITING OMG OMG OMG *ahem*
no subject
no subject
http://wiki.dwscoalition.org/notes/Upgrading_an_old_LJ_Installation_to_DW_Codebase
I'm even using your wiki to store the offical documentation!
no subject
Also, if you find things that you need to patch as you go, you know where Bugzilla is :) Just be sure to fill out a CLA.
(EDIT: And, barring the level of support the LJ codebase has or doesn't have, it doesn't change the fact that we built this, and you are using it, omg omg omg. That thrill will never get old. Ever.)
no subject
Squee!
no subject
no subject
FYI, I do most of my development on a VM on a 32-bit laptop. My current convert-back-to-32-bit patch basically converts all the NNNQN's to NNNLN's and the security allowmask field from 2**63 to 2**31. Those changes are all in Entry.pm and ljprotocol.pl. It seems to run fine that way for me.
Of course, if you can run 64-bit, you're a lot better off doing so.
no subject
no subject
The Amazon AWS is about 4 times larger for a 64 bit instance than a 32 bit instance. :\
no subject
no subject
no subject