[FreeBSD]Portsnap / gunzip: can’t stat: files/… .gz: No such file or directory

My FreeBSD got an unknown fever today. When I updated my ports using portsnap, it gave the following error message:

#sudo portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from your-org.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Thu May 23 09:08:53 CDT 2013 to Thu May 23 09:25:25 CDT 2013.
Fetching 0 metadata patches. done.
Applying metadata patches... done.
Fetching 0 metadata files... done.
gunzip: can't stat: files/992a1325cdc9a00a3543aa38fdf58903cdf70eaee02b8bb8aebea5505ac7b3f8.gz: No such file or directory
Fetching 0 patches. done.
Applying patches... done.
Fetching 0 new ports or files... done.
Building new INDEX files... gunzip: can't stat: /var/db/portsnap/files/09f65f8a730283fd31d068a5927ed46d95e37540f89090c257d7809b75116293.gz: No such file or directory
gunzip: can't stat: /var/db/portsnap/files/e3d3219617c1ea87cdfac7c8df0a52d611b191be8a80fd97f511277dff4cce77.gz: No such file or directory
gunzip: can't stat: /var/db/portsnap/files/8c2576279258f0d1b8762df8fc1e0cb4bcfcd23b6b09cdb4e7d68886af35ed7d.gz: No such file or directory
done.

Apparently, something in /var/db/portsnap/ is broken. Many people will try to remove /var/db/portsnap/ and run the command again. Do not do it. It will make portsnap failed. Instead, do the following:

sudo cp -r /var/db/portsnap /var/db/portsnap_backup
sudo rm -Rf /var/db/portsnap/tag /var/db/portsnap/files/*
sudo portsnap fetch extract
sudo portsnap update

Now your portsnap should be happy.

–Derrick

Our sponsors:

[Solved]FreeBSD: Problem to Update glib20

I decided to install Java on my FreeBSD box today. It wasn’t a very good experience. Primary the system is not automated. It requires a lot of manual works.

Anyway, after waiting for couple hours, I found that the process was stuck on glib. The system could not build the /usr/ports/devel/glib20. Here is the error message:

===>  Building for glib-2.34.3
gmake  all-recursive
gmake[1]: Entering directory `/usr/ports/devel/glib20/work/glib-2.34.3'
Making all in .
gmake[2]: Entering directory `/usr/ports/devel/glib20/work/glib-2.34.3'
gmake[2]: Nothing to be done for `all-am'.
gmake[2]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.34.3'
Making all in m4macros
gmake[2]: Entering directory `/usr/ports/devel/glib20/work/glib-2.34.3/m4macros'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.34.3/m4macros'
Making all in glib
gmake[2]: Entering directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib'
gmake  all-recursive
gmake[3]: Entering directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib'
Making all in libcharset
gmake[4]: Entering directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib/libcharset'
gmake[4]: Nothing to be done for `all'.
gmake[4]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib/libcharset'
Making all in update-pcre
gmake[4]: Entering directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib/update-pcre'
gmake[4]: Nothing to be done for `all'.
gmake[4]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib/update-pcre'
Making all in .
gmake[4]: Entering directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib'
  CC       gstrfuncs.lo
  CC       gthreadpool.lo
gstrfuncs.c:330: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'get_C_locale'
gstrfuncs.c: In function 'g_ascii_strtod':
gstrfuncs.c:700: warning: implicit declaration of function 'strtod_l'
gstrfuncs.c:700: warning: implicit declaration of function 'get_C_locale'
gstrfuncs.c: In function 'g_ascii_formatd':
gstrfuncs.c:902: error: 'locale_t' undeclared (first use in this function)
gstrfuncs.c:902: error: (Each undeclared identifier is reported only once
gstrfuncs.c:902: error: for each function it appears in.)
gstrfuncs.c:902: error: expected ';' before 'old_locale'
gstrfuncs.c:904: error: 'old_locale' undeclared (first use in this function)
gstrfuncs.c:904: warning: implicit declaration of function 'uselocale'
gstrfuncs.c: In function 'g_ascii_strtoull':
gstrfuncs.c:1148: warning: implicit declaration of function 'strtoull_l'
gstrfuncs.c: In function 'g_ascii_strtoll':
gstrfuncs.c:1195: warning: implicit declaration of function 'strtoll_l'
gmake[4]: *** [gstrfuncs.lo] Error 1
gmake[4]: *** Waiting for unfinished jobs....
gmake[4]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.34.3/glib'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/devel/glib20/work/glib-2.34.3'
gmake: *** [all] Error 2
*** Error code 1

Stop in /usr/ports/devel/glib20.
*** Error code 1

Stop in /usr/ports/devel/glib20.

This is not a popular problem. After I google a while, I found a very similar problem here. Basically, the author suggests that the problem may be caused by an uncleaned run of freebsd-update. In short, you need to run the program twice, i.e.,

sudo freebsd-update fetch install
sudo reboot
sudo freebsd-update install

Obviously, it didn’t work for me. So I decided to try my last solution: pkg_add

sudo pkg_add -r glib20

and I tried to resume the installation:

cd /usr/ports/java/jdk16
sudo make install

It worked!

Hope this little trick is helpful to you.

–Derrick

Our sponsors:

[FreeBSD/Linux]How To Remove ZFS Meta Data

I have many hard drives circulating among my servers for testing purpose. For example, I took a hard drive from one server and put it on a different server. After doing this for many times, I’ve noticed that the ZFS has put many header information / meta data left on my hard drive. While it does not do anything harmful to the normal ZFS operation, I think it is not a good idea to have some outdated information living on my hard drive.

Here is an example:

#sudo zpool import

  pool: storage
    id: 4394681882400895515
 state: UNAVAIL
status: The pool was last accessed by another system.
action: The pool cannot be imported due to damaged devices or data.
   see: http://www.sun.com/msg/ZFS-8000-EY
config:

        storage                   UNAVAIL  insufficient replicas
          raidz1-0                UNAVAIL  insufficient replicas
            12688516256739208392  UNAVAIL  cannot open
            ada3                  ONLINE
            4218969245912188584   UNAVAIL  cannot open
            1537006695366032450   UNAVAIL  cannot open
            8194123525800888894   UNAVAIL  cannot open
            13778624724471040977  UNAVAIL  cannot open

  pool: storage
    id: 12159013771499288095
 state: FAULTED
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
        The pool may be active on another system, but can be imported using
        the '-f' flag.
   see: http://www.sun.com/msg/ZFS-8000-5E
config:

        storage                FAULTED  corrupted data
          6113585248511400089  UNAVAIL  corrupted data

Although ZFS provides a way (zpool labelclear) to remove this information, it only works if the hard drive is still attached to the server. If the hard drive is missing, there is nothing you can do. For example, the following command will be failed:

#sudo zpool labelclear -f ada3

I googled for solutions and I found many idea. Unfortunately, none of them works.

Anyway, I came up a solution that is quick, easy and simple. Since ZFS stores the header information in the first and last sector of the hard drive, all I need to do is to wipe out the first and the last sector. That’s it.

How To Remove ZFS Meta Data – Linux

#replace /dev/sdXX with that actual ID of your hard drive
dd if=/dev/zero of=/dev/sdXX bs=512 count=10
dd if=/dev/zero of=/dev/sdXX bs=512 seek=$(( $(blockdev --getsz /dev/sdXX) - 4096 )) count=1M

That’s it for Linux. Below is the FreeBSD version.

How To Remove ZFS Meta Data – FreeBSD

First, you will need to identify which hard drive you want to clean up. The easiest way is to use dmesg

#dmesg


or 

#dmesg | grep ada | grep MB | grep -v 'MB/s'


which will return something like this:


ada0: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C)
ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada3: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada4: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)

Next, I need to know which one is the system hard drive, something I don’t want to touch.

#df

/dev/ada0p2    362G    3.6G    329G     1%    /
devfs          1.0k    1.0k      0B   100%    /dev

In this example, my goal is very clear. I need to wipe clear ada1, ada2, ada3 and ada4, and leave ada0 untouched.

Next, I need to clear the first sector:

#sudo dd if=/dev/zero of=/dev/ada1 count=1 bs=512k

repeat this for the other hard drives

Next, I need to clear the last sector. You can use the sector information from dmesg (if available), or you can use the following command to find the location of the last sector:

#sudo diskinfo -c /dev/ada1

which will return something like the following:

/dev/ada1
        512             # sectorsize
        1500301910016   # mediasize in bytes (1.4T)
        2930277168      # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        2907021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        S1Y6J1KS710613  # Disk ident.

I/O command overhead:
        time to read 10MB block      0.091942 sec       =    0.004 msec/sector
        time to read 20480 sectors   1.945038 sec       =    0.095 msec/sector
        calculated command overhead                     =    0.090 msec/sector

In this example, the total number of sector is 2930277168 (mediasize in sectors).

To keep things simple, I am going to wipe out the hard drive from 2930270000 to the end (Replace the last four digits of the sector size to zero).

#sudo dd if=/dev/zero of=/dev/ada1 oseek=293027000

Now, repeat the same thing for each hard drive. Keep in mind that the sector size of each hard drive may not be the same. So it is better to run the command and get the sector information first.

After running these commands, the ZFS meta information should be removed. You can verify your work by doing this:

#sudo zfs import


which should output nothing.

That’s it. Enjoy building a new ZFS!

–Derrick

Our sponsors:

[FreeBSD]The net/samba35 port has been deleted: Obsoleted by net/samba36

FreeBSD is designed for users who got lots of spare time. Every once a while, it will give you some troubles (or “snacks” in programmer language), which help you to burn some of your spare time. If you cannot handle these troubles, then FreeBSD is not for you.

Although FreeBSD is a rock solid operating system, it is not smart enough to tell whether the owners (i.e., you and me) got plenty of spare time or not. Anyway, comparing to Windows Server, I think FreeBSD is considered an honor student already.

Okay, let’s go back to the error message. When I tried to update FreeBSD, I got the following error message:

Building new INDEX files... done.
===>>> Starting check of installed ports for available updates

===>>> The net/samba35 port has been deleted: Obsoleted by net/samba36
===>>> Aborting update

Terminated

Again, this is an old-school error. The port-maintainer decided that the samba35 is too old, and he likes to replace it by samaba36. We all love the new stuffs, but we want the transition goes smooth too. Apparently, it seems that the port-maintainer totally forgot about it.

If you check the directory, you will notice that /usr/ports/net/samba35 is deleted. If you try to soft-link samba36 to samba35, portmaster will likely to complain. The only way to solve this problem is by removing samba35 first, and installing samaba36 afterward.

So here is how to solve this problem:

sudo pkg_info | grep samba35

You will see something like the following:

samba35-3.5.19      A free SMB and CIFS client and server for UNIX

Let’s delete it.

sudo pkg_delete -f samba35-3.5.19

FreeBSD may remind you to manually remove Samba’s configuration, DO NOT do it.

WARNING: If you will *NOT* use this package anymore, please remove the
  following directories manually:
  /usr/local/etc/samba
  /var/log/samba
  /var/db/samba

Verify that the package has been deleted. The package should be gone.

sudo pkg_info | grep samba35

Now try to install the package again:

cd /usr/ports/net/samba36
sudo make install clean

After the installation is completed, don’t forget to start the Samba server:

sudo /usr/local/etc/rc.d/samba start

That’s it!

–Derrick

Our sponsors:

How to Upgrade FreeBSD from 8 to 9

Upgrading FreeBSD is very easy. Thanks for the simple architecture design and the disconnection between the kernel and the applications (ports), the whole process takes around 15 to 45 minutes. The coolest thing is that the system down time is very short. In my case, the down time was only about 3 minutes.

This table will help you to estimate the whole process and system down time:

Action Down Time? Approximate Duration
Download the update files None 5 to 15 minutes
Installing the update None 5 to 15 minutes
Helping FreeBSD to set up the system configurations None 1 to 3 minutes
Reboot Yes 1 to 3 minutes
Installing the update None 1 to 2 minutes
Reboot (Optional) Yes 1 to 3 minutes

Notice that this tutorial only works for i386 or amd64. For other CPU architectures such as Sparc, you will either reinstall the whole thing or rebuild the whole world (i.e., make buildworld). One way or the other, that’s a very time-consuming process.

First, I am assuming that your FreeBSD is up-to-date in your current version. You can do it by running the following command:

First, make sure that your ports are up to date.

#Download the latest ports
sudo portsnap fetch update

#Upgrade the old ports:
sudo portmaster -Da

Next, we want to upgrade the FreeBSD. Currently, the latest version is 9.1:

sudo freebsd-update upgrade -r 9.1-RELEASE

FreeBSD will try to download files for you. Just say yes.

Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 8.2-RELEASE from update5.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata files... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic world/base world/manpages

The following components of FreeBSD do not seem to be installed:
src/base src/bin src/cddl src/contrib src/crypto src/etc src/games
src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue
src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin
world/catpages world/dict world/doc world/games world/info world/lib32
world/proflibs

Does this look reasonable (y/n)? y

Next, it will download the patches. Depending on your internet connection speed, it may take 1 to 10 minutes:

...
Applying patches... done.
Fetching 1962 files... done.
Attempting to automatically merge changes in files... done.

Now, FreeBSD will try to check whether your configuration is compatible with the new version or not. It may need your help to merge the configuration files manually. Notice that it uses VI, a standard (and very old, not really user-friendly) editor in Unix. If you’ve never used vi before, here are some simple commands:

#By default, a document is opened in read-only mode. To switch to a wrote mode:
i

#To set the mode to read only
Press the ESC key

#Delete a character
x

#Delete the whole line
dd


#Save a file
:w

#To quite vi
:q

#To save and quite
:wq

After some file editing, FreeBSD will give you a summary of what files will be changed. Just hit either ESC or q to end the list.

...
/usr/share/man/man3/lwres_addr_parse.3.gz
/usr/share/man/man3/lwres_buffer.3.gz
/usr/share/man/man3/lwres_buffer_add.3.gz
/usr/share/man/man3/lwres_buffer_back.3.gz
/usr/share/man/man3/lwres_buffer_clear.3.gz
/usr/share/man/man3/lwres_buffer_first.3.gz
/usr/share/man/man3/lwres_buffer_forward.3.gz
/usr/share/man/man3/lwres_buffer_getmem.3.gz

At this point, FreeBSD finish the upgrade plan. (It hasn’t made any change to your system.) Now we need to give a green light to FreeBSD to start upgrade the system.

sudo freebsd-update install
...Please reboot and run "/usr/sbin/freebsd-update install" again to finish installing updates.

After the reboot, run the command again to update the userland components:

sudo freebsd-update install

Installing updates...
Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates.

Reboot the computer again to finish the upgrade.

sudo reboot

Now, we need to upgrade all of the ports. Notice that this step is optional. You don’t need to do it unless you found any problem after the upgrade.

#Upgrade all the installed ports
sudo portmaster -fa

Reboot the computer again to finish the upgrade.

sudo reboot

Make sure that FreeBSD is running on the latest version:

# uname -a
FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     [email protected]:/usr/obj/usr/src/sys/GENERIC  amd64

Have fun with FreeBSD.

–Derrick

Our sponsors:

[FreeBSD]MySQL server could not start

Today, I noticed that the MySQL server on my FreeBSD server is down for unknown reason, and today is Thanksgiving.

Initially, I tried to restart the MySQL server using the following command, but it didn’t help to restart the MySQL:

sudo /usr/local/etc/rc.d/mysql-server restart

and it gives me the following error message:

mysql not running? (check /var/db/mysql/icesquare.com.pid).

That’s interesting. So I check the pid file and I found that it is not available. After scratching my head for a while, I noticed one thing:

df
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad4s1d    7.7G    7.7G     -1M   100%    /var

Obviously, the /var directory is full. No wonder why the MySQL could not create any file, which explains why it stopped working.

Since the server is already up and running, it will be too late to increase the size of /var without reinstalling the entire system. The simplest way is to soft link the /var directory to somewhere else. Since a lot of system applications depends on /var, I don’t want to move the entire /var into a different places. So I decide to softlink /var/log into /usr/var/log.

The steps are easy:

sudo su
mkdir -p /usr/var/
mv /var/log /usr/var/
ln -s /usr/var/log /var/

To verify your work, it should look something like that:

ls /var
lrwxr-xr-x   1 root    wheel       13B Nov 22 11:48 log -> /usr/var/log/
df
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad4s1d    7.7G    1.1G    6.0G    15%    /var

Now, if you try to start the MySQL server again, it may or may not work. If you experience any difficulties, try to reboot the server. After the server is reboot, MySQL should be up and running again.

Lesson learned: Always create single partition. 🙂

–Derrick

Our sponsors:

FreeBSD.org Was Compromised. What Should You Do Next?

In case you are not aware this bad news. FreeBSD.org was compromised on September 17, 2012. Good news is that the compromise was caused by a human error (a stupid developer leaked a SSH private key somewhere), which has nothing to do with the code quality of the FreeBSD. 🙂 Bad news is that this may affect you if you use port. 🙁

The compromise is believed to have occurred due to the leak of an SSH key from a developer who legitimately had access to the machines in question, and was not due to any vulnerability or code exploit within FreeBSD.

We unfortunately cannot guarantee the integrity of any packages available for installation between 19th September 2012 and 11th November 2012, or of any ports compiled from trees obtained via any means other than through svn.freebsd.org or one of its mirrors. Although we have no evidence to suggest any tampering took place and believe such interference is unlikely, we have to recommend you consider reinstalling any machine from scratch, using trusted sources.

In short, the port tree was affected from September 19, 2012 to November 11, 2012. If you downloaded the ports in between this period, you are likely a victim of this incident. 🙁 Here is how to clean up the mess:

Stop using cvsup/csup to update your port. Use portsnap instead.

If you already used portsnap, do the following:

sudo portsnap fetch extract
sudo portsnap upgrade

If you have no idea what is portsnap, here is a quick tutorial:

First, install the portmaster and portupgrade. Port-Upgrade downloads the new ports to your server and Port-Master updates your applications based on the downloaded ports.

sudo pkg_add -r portupgrade portmaster

Download all ports. Notice that this is one-time work.

sudo portsnap fetch extract

If you decide to update your port tree, run the following:

sudo portsnap fetch update

Or if you like to run it in a cron job, run the following instead:

sudo nano /etc/crontab

#Run every three hours
0       */3     *       *       *       root    portsnap -I cron update && pkg_version -vIL= >/dev/null 2>&1

Now you have an updated port tree. Next you will need to update your applications based on your local port tree:

sudo portmaster -Dai

That’s it.

And remember, NEVER put your SSH private key in a public area.

–Derrick

Our sponsors:

[FreeBSD]The devel/pkg-config port moved to devel/pkgconf; Reason: pkg-config has been replace by pkgconf; pkgconf-0.8.5 conflicts with installed package(s): pkg-config-0.25_1

FreeBSD is designed for users who got lots of spare time. Every once a while, it will give you some troubles (or “snacks” in programmer language), which help you to burn some of your spare time. If you cannot handle those troubles, then FreeBSD is not for you.

Although FreeBSD is a rock solid operating system, it is not smart enough to tell whether the owners (i.e., me and you) got plenty of spare time or not.

Anyway, comparing to Windows Server, I think FreeBSD is considered an honor student.

Okay, let’s go back to the error message. When I tried to update FreeBSD, I saw the following error:

===>>> All >> pkg-config-0.25_1 (1/1)

        ===>>> The devel/pkg-config port moved to devel/pkgconf
        ===>>> Reason: pkg-config has been replace by pkgconf

===>  pkgconf-0.8.5 conflicts with installed package(s):
      pkg-config-0.25_1

      They install files into the same place.
      You may want to stop build with Ctrl + C.

Again, this is an old-school error. The port-maintainer decided that the app A is too old, and he likes to replace it by app B. We all love the new stuffs, but we want the transition goes smooth. Apparently, it seems that the port-maintainer totally forgot about it.

So here is how to solve this problem:

sudo pkg_info | grep pkg

You will see something like the following:

pkg-config-0.25_1   A utility to retrieve information about installed libraries

Let’s delete it.

sudo pkg_delete -f pkg-config-0.25_1

Verify that the package has been deleted:

sudo pkg_info | grep pkg

Now try to install the package again:

cd /usr/ports/devel/pkgconf
sudo make install clean

That’s it!

–Derrick

Our sponsors:

[FreeBSD]How to run PECL Tokyo Tyrant in PHP 5.4

After upgrading to PHP 5.4.3 (which is the first version of PHP 5.4 available in the FreeBSD port), I found that the pecl-tokyo_tyrant could not be compiled. Here is the error messages:

cd /usr/ports/databases/pecl-tokyo_tyrant
sudo make
===>  pecl-tokyo_tyrant-0.6.0 cannot install: doesn't work with PHP version : 5 (Doesn't support PHP 5).
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant.
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1827: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1867: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_table_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1911: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_query_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1936: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_iterator_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_query_object_new':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2001: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_iterator_object_new':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2052: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_object_new_ex':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2090: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'zm_startup_tokyo_tyrant':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: 'php_tokyo_tyrant_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: (Each undeclared identifier is reported only once
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: for each function it appears in.)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2171: error: 'php_tokyo_tyrant_table_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2176: error: 'php_tokyo_tyrant_query_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2182: error: 'php_tokyo_tyrant_iterator_class_methods' undeclared (first use in this function)
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0.
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant.

Basically, it means that the pecl-tokyo_tyrant is not happy with the new version of PHP 5.4. I’ve tried several methods, including using pkg_add, compiling from source, copying a working tokyo_tyrant.so etc, unfortunately none of these methods works.

Finally, I found that the maintainer of this package has made a new version available(0.6.2) at github. Here is how I did it:

First, go to here to grab the source code. Make sure that you download the tag.gz version because it has the file attribute available.

Second, let’s remove the pecl-tokyo_tyrant from your system. You can either do it in the port or pkg_delete:

From port:

cd /usr/ports/databases/pecl-tokyo_tyrant
sudo make deinstall

Or using pkg_delete:

sudo pkg_delete pecl-tokyo_tyrant-0.6.0

Now, extract the files and compile it from source:

tar -zxvf mkoppanen-php-tokyo_tyrant-0.6.0-2-gb0d7e0c.tar.gz
cd mkoppanen-php-tokyo_tyrant-b0d7e0c
sudo phpize
sudo ./configure
sudo make
sudo make install

and don’t forget to include the .so file in your configuration:

sudo nano /usr/local/etc/php/extensions.ini

Add the following (if not available) to the end of the file:

extension=tokyo_tyrant.so

Finally, let’s restart the Apache:

sudo apachectl stop
sudo apachectl start

That’s it! Have fun with Tokyo Tyrant with PHP 5.4.

–Derrick

Our sponsors:

[PHP/FreeBSD]===>>> The databases/php5-sqlite port has been deleted: Removed from core php ===>>> Aborting update

When PHP 5.4 was available few months ago, I was hesitated to upgrade my FreeBSD box to upgrade to 5.4, because it comes with lots of big changes, including removing LOTS of old stuffs that were available in 5.3 or earlier versions.

Today PHP 5.4.3 becomes available in FreeBSD ports. I guess it is stable enough and I should give it a try, and I am glad that I tried it in my test machine first.

Warning: Before you upgrade to PHP 5.4, make sure that you are not using any of the following packages, because they are not compatible with the PHP 5.4. Unfortunately, I don’t have a solution yet. Basically, I could not get them compiled.

  • eAccelerator: /usr/ports/www/eaccelerator/
  • PECL-TokyoTyrant: /usr/ports/databases/pecl-tokyo_tyrant/ (Updated: I just came up a solution here)

When I performed the upgrade using the following command:

sudo portsnap fetch update
sudo portmaster -Da

I got the following error message:

===>>> The databases/php5-sqlite port has been deleted: Removed from core php
===>>> Aborting update

The reason why you see this problem because php5-sqlite is no longer available in PHP 5.4. In order to solve this problem, you will need to delete the php5-sqlite extension.

cd /usr/ports/lang/php5-extensions
sudo make config

Uncheck the following: sqlite3 support

Now, deinstall this port. Yes, let’s remove it and install it again. (I’ve tried the reinstall option and it didn’t work, so let’s stick with deinstall and install.

sudo make deinstall clean install clean

Now let’s find out which php-SQLite we should delete:

pkg_info | grep php5-sqlite

In my case, I deleted this one:

sudo pkg_delete php5-sqlite-5.3.13

Now upgrade the port again and FreeBSD should be happy about it. Enjoy PHP 5.4.

–Derrick

Our sponsors: