Software\’s whipping boy

April 13, 2006

Again a test of 0.5.14

Filed under: Uncategorized — rslomkow @ 11:51 pm

Here goeFlocks nothing Polizei%20MiniThe fun police car from Munich


March 10, 2006

subversion conversion

Filed under: Uncategorized — rslomkow @ 5:11 pm

We are switching source control systems once again.  We are back to subversion.

 Most of the migration is mostly done. is the place to peruse current flock code.  If you want to check it out, then svn:// is the URL to checkout.  The fbuild docs have been updated.  There is even a new version of optimized for being used by people with anonymous access to the source code.

We are currently using subversion, though I don’t know how final our setup is, as not that many people have been checking in code yet, so there may still be some changes in our setup.  Times for commits still need to be updated, how we layout are source code is still in flux, getting the right access for people is still being worked out, commit messages still need to be fine tuned.  But we currently are building our tinderbox out of subversion, and changes done by developers are making their way in.


Filed under: Uncategorized — rslomkow @ 3:18 pm

Some people have asked "what is up?" with  Flock on  Apple Intel Macintosh machines.

First Flock 0.5.12 runs just fine under  Rosetta.  Honestly it runs just about as fast under Rosetta as it does on any other Macintosh.  Also currently, post 0.5.12 code in subversion builds and runs natively on Intel x86.

We do plan to eventually offer Universal binaries.  We will follow Mozilla’s lead on this, after they release, we will use the system that Mozilla is using documented at:  So assuming we have some MacIntel boxes in house dedicated for testing, we will probably have testing builds some time in May 2006.

December 1, 2005

Tinderbox coming back to Flock

Filed under: Uncategorized — rslomkow @ 10:22 pm

Well the first phase of getting tinderbox back is there.  Automated builds are occurring, but because of the lack of tools to manipulate mercurial by date they don’t build from quite the right source code.  Meaning that the date stamp right now is no necessarily an accurate representation of what code is there.  The other issue is tinderbox doesn’t tell you who to blame.  Which is a major missing feature.

This leaves me with two big problems with tinderbox.

  1. doesn’t show checking (and our check-ins are in mercurial)
  2. doesn’t show localized time (and the time display logic is scattered everywhere)

I guess I will just hack tinderbox2, and not write my own thing, but it certainly is tempting.

Once I confirm that automated builds with mercurial are producing reasonable builds for all 3 platforms I will update the warning message and upgrade to FF 1.5 release

I geuss my list of needed mercurial/build tools

  1. efficient date to changeset tool
  2. web changelog (show comments, links to bugzilla, select ranges by date)
  3. commit emails
  4. tinderbox-integration
  5. make branch logic work

November 25, 2005

Mercurial Working! *sort of*

Filed under: Uncategorized — rslomkow @ 11:06 pm

So now I have a build script up to build from current source using mercurial using fbuild.  I am even posting this from a mercurial build, run from that script.

It builds flock on Linux & Windows (still waiting on the Mac when I wrote this), but some theming stuff doesn’t work.  To get automated build back up again, I need to setup a source mirror in the office or they clobber the network and none-of the build servers work and people in the office start wanting to use cell phone modems for the better connections quality.  There are also some tweaks to the build scripts that need to be done, but it is fewer now.

The big win is that we are now storing the mozilla code and flock code together, it makes updating to a new version of mozilla much harder, but it makes daily development much easier, because people don’t get confused about where they are working and which files can be symlinks and which cannot.  Still a lot of work to do to clean up the repository.

browser/components/flock -> flock/components/flock
most of the theming stuff has already been moved into the flock project directory.  There is some more stuff that needs to go there, and I need to disable the weird hacks to get around the windows compiler not being able to read cygwin symlinks.

This far more difficult than it should have been.

  1. tailor was more trouble than I thought.
  1. cannot deal with cvs directories that only have attic files.  I actually got around this problem with a different solutions.  I converted cvs -> svn with cvs2svn and then went from svn -> hg with tailor.  At least both svn and hg have the concept of change-sets and cvs2svn is well tested.
  2. is incredibly slow, now some of this is our hardwares fault, the discount servers from rackspace have very slow disks.  2MB/s sustained and 4MB/s max.  My external USB attached to my Linux box can do 17MB/s sustained.  And since it is crummy IDE, it cause the whole machine to be unresponsive when you max out the io.  This meant over 4+ hours to do a conversion.
  • hg is a bit immature still, a few surprises
    1. The 0.7 Windows build does not deal with ssh properly.  When you attempt to do an ssh transaction it says “hg specific_command –stdio” command not found, which is clearly running the exec for ssh incorrectly.  This happend both for cygwin ssh, and plink.  The solution is build hg 0.7 using the process for unix under cygwin.
    2. hg rename does not support traditional filesystem primatives, you must specify a destination filename.  ie you cannot: hg mv foo bar/; instead you must hg mv foo bar/foo
    1. when you rename you cannot view comments history in: hg log -v
      (yes you need the -v to see the comments otherwise you just see the revisions, manifests and dates.  The documentation is much better on tip right now.)  I have been assured that the rename can be determined in the data-store, but is not hooked up yet.
  • hg could not add certain funny filenames by default.  The example here is I have directory called “{b01bf10c-302a-11da-b67b-000d60ca027b}” this was not automatically added and I could type “hg add” and it wouldn’t do anything but “hg status” knew that the files where not there.  This has been fixed in tip, but for now the hack is “hg add relname:{b01bf10c-302a-11da-b67b-000d60ca027b}”  People on the dev irc channel were really helpful in helping me figure out this weird stuff.
  • November 23, 2005

    Everything Breaks

    Filed under: Uncategorized — rslomkow @ 1:00 am

    Time switch to a new source control, will be landing it by end of day tomorrow.

    We are going with Mercurial I have only two complaints and that is not very high.

    1. Not many 3rd party tools that support it: like bonsai, a read-write web client and such
    2. No concept of querying by time

    So for the next couple of weeks we won’t have hourly builds, change-logs, or source releases.
    (OK hopefully it will be sooner than that, but I am sure I can make that date, no matter what comes up)

    We will see how fast we get these things up and running.

    Hope you have fun over the holiday, sorry for the interruption to playing with the latest stuff.

    Look for coming soon, for those people that like to hack on stuff.

    November 2, 2005

    Big build migration

    Filed under: Uncategorized — @ 5:12 pm

    Been spending a lot of time looking at subversion.   Loks like we will be moving to it.

    Of course changing source control systems is easy, changing your development processes is always much harder.  The think I have found the nicest about subversion is the the simplicity of the metaphor to source control.  You just copy, rather than having extra-dimensional tags and branches.

    1. Too bad it doesn’t have symlinks and overlays

    Linux doesn’t get the UI love that other platforms do.

    October 21, 2005

    How to build Flock

    Filed under: Uncategorized — rslomkow @ 2:05 pm

    How do I build flock from source?

    Well first you need to be familiar with building software, but you probably are if you are looking at this page.

    First you need the mozilla build requirements. If you cannot build mozilla, you cannot build

    Additional restrictions: on Windows we have only testing with Microsoft Visual Studio .NET 2003. I have been told that didn’t work for someone who tried with a different compiler.

    Quick buiild

    Quick way: If you have everything setup to be able to build mozilla.
    Download flock-source-0.4.9-complete.tar

    *NOTE on Windows you will need to set the followin environment variables

    $ CC=cl ; CXX=cl ; export CC CXX

    Everyone needs the following steps

    $ tar xvf flock-source-0.4.9-complete.tar
    $ cd flock-source-0.4.9-complete
    $ sh ./

    This will probably take over an hour (possibly several hours) depending on how fast your computer is.

    Building by hand

    This assumes you are a pretty advanced developer and familiar with UN*X tools. First make sure you have all of the requirements listed below. Download all of the source code files and the Patch into the same directory, from now on I will refer to this directory as src_dir

    • Windows needs to use cl to compile clucene
      CC=cl; CXX=cl; export CC CXX
    • FreeBSD needs a patch for cairo
      I am hoping the need for this will go away as this goes into mainstream Firefox
    1. Mozilla development requirements:
    2. Mozilla Firefox Beta 2 source code:
    3. Flock MPL source code:
    4. Flock GPL source code:
    5. Clucene 0.8.13 source code:
    6. Flock Clucene Patch:

    Now to build

    1. Get the Mozilla build requirements for your platform!
    2. unpack Firefox Beta 2 source code (this must be done first as flock over-writes some files from this)
      tar xjf firefox-1.5b2-source.tar.bz2
    3. Make a directory called “local” at the same level as the mozilla directory
      mkdir local
    4. unpack Flock MPL source code
      tar xzf flock-0.4.8-strict_mpl.tar.gz
    5. unpack Flock GPL source code
      tar xzf flock-0.4.8-gpl.tar.gz
    6. unpack Clucene source code
      tar xzf clucene-0.8.13-src.tar.gz
    7. apply the Flock Clucene Patch to the clucene code
      patch -p0
    8. change into the clucene directory
      cd clucene-0.8.13
    9. configure Clucene with the prefix of the local directory
      ./configure –prefix=src_dir/local
    10. build clucene and install it
      make && make install
    11. change to the mozilla directory
      cd src_dir; cd mozilla
    12. configure mozilla
    13. make
    14. when this succeeds (75 minutes on laptop)
    1. Linux: files executable is ./dist/bin/flock
      cd ./dist/bin; ./flock
    2. Windows: executable is ./dist/bin/flock.exe
      cd ./dist/bin; ./flock.exe
    3. MacOS: executable is ./dist/
      cd ./dist; open

    That should be it. The first thing to try if you run into problems is to make sure you can build firefox
    with the instructions from:

    October 19, 2005

    As of yet another release

    Filed under: Uncategorized — @ 9:29 pm

    release early release often, though I think this may be a little bit insane.

    I need to get some sleep, and some vacaton in, in theory I am on vacation here.

    I don’t klnow if paragraph tags are actually any better than

    RSS viewer is still kind of wacked, it views, but isn’t a propper reader.

    Favorites has been the object of my nit-picking, but I think it is time to move on to other things.Flickr Photo

    Technorati Tags: ,

    October 14, 2005

    Cool! this worked

    Filed under: Uncategorized — @ 10:42 am

    The Flock is coming.  Sure it is a pre-release of a Beta and not ready for prime time!
    Flickr Photo

    All these sort of people want to play with the flock, and we want the feedback so this can become the ultimate browser for the online social set.

    Grrr.. Cross platform work, is never that easy.  Mysterious things work on one platform and not on another.

    « Newer PostsOlder Posts »

    Blog at