Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 18 Oct 2019, 17:25
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Derivatives
TazPup64 (pre-alpha17) - getting close to alpha quality
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 7 [92 Posts]   Goto page: 1, 2, 3, 4, 5, 6, 7 Next
Author Message
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Sat 23 Feb 2019, 19:00    Post subject:  TazPup64 (pre-alpha17) - getting close to alpha quality  

Latest ISO
TazPup64-PreAlpha-17.iso (See post)

Latest .vdi file (for virtualbox and other virtualization/emulationtools):
TazPup64-PreAlpha-17.vdi (see post)

Older Info
I think we're getting close to alpha quality with TazPup64-PreAlpha-15

Some notes, the ISO will automatically log you into tux in the lxde desktop. On the bottom left (in the panel) there is a red logout/shutdown/reboot button that looks like the power symbol. If you click on it you can log out and then log in as root in the jwm desktop. The password for root is "root".

To use gparted you must install gtkmm.
Code:

tazpkg get-install gtkmm


I recommend starting gparted from the command line. If for some reason you get an error try it one more time from the command line.

The puppy universal installer works. I verified after installing and creating a save file that tux still works but I think there is a catch. If you install any software (e.g. gtkmm) in the pfx=ram mode then creating a save file might mess up the permissions for non root users. Therefore if you install any software in pfx=ram mode then you should first reboot without creating a save file, and then after rebooting create a save file before installing any packages.

Further notes on why not to install any packages before creating a save file can be found in the following post:
http://murga-linux.com/puppy/viewtopic.php?p=1026679#1026679

And if you disregard this advice, then notes on how to fix the save file after the fact can be found in the following post:
http://murga-linux.com/puppy/viewtopic.php?p=1026527#1026527

A .vdi (virtual disk image) for virtualbox is available for this release (see post) but I will be doing further updates to it before the next release.

There is no recent buildkit but an older version of the buildkit is referenced in the following post:
http://murga-linux.com/puppy/viewtopic.php?p=1026677#1026677

The password for root is root. Both spot and tux have a zero length passwords (almost equivalent to having no password but this gets around restrictions in the pam package).

If you login with the screen=text option (equivalent to pfx=nox) then you can start jwm with the command:
Code:

startx_jwm


or alternatively start lxde with the command:
Code:

startlxde


Note that I'll eventually change the name of the command to start lxde because I'm starting Xorg with this script but the standard version of this script does not do this. Also note that I disabled the autostart for many applications. To have them autostart, rename the files in the folder:
Code:

/etc/xdg/autostart


so that they end in ".desktop", This will be more apparent if you are using the rox file manager rather than pcmanfm. This is because for ".desktop" file pcmanfm displays the "application name" rather than the "file name".

Edit 1 To see the rox desktop in jwm for some reason you have to first log in as root, and then "Exit to Prompt" and restart the desktop with the command:
Code:

startx_jwm


I think the reason is that the pcmanfm desktop overlays the rox desktop, and so far the only way I know to remove this is to kill Xorg. As an alternative to the above way of seeing the rox desktop you can boot with the screen=text option and then start jwm with the command startx_jwm.

Last edited by s243a on Tue 07 May 2019, 03:24; edited 47 times in total
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Sat 23 Feb 2019, 20:52    Post subject:  

The build script doesn't seem to be creating the 64bit version of the iso for me regardless of whether or not I use the online or cloud version.

I think that mistfire moved to using tazpkg to build the ISO. On configureation file used by tazpkg is located in
Code:

/etc/slitaz/slitaz.conf


Some important lines in this file are:
Code:

#05 - SLITAZ_RELEASE="$(cat /etc/slitaz-release)"
#30 - MIRROR_URL="http://mirror.slitaz.org"
#33 - ONLINE_PKGS="$MIRROR_URL/packages/$SLITAZ_RELEASE/"


some other vars in this file that look relavant:

Code:

#20 - STABLE="$SLITAZ_HOME/stable"
#21 - COOKING="$SLITAZ_HOME/cooking"
#22 - UNDIGEST="$SLITAZ_HOME/undigest"


I'm not sure yet where this file is being pulled from but probably not the slitaz iso like it should be.

So urls where 64 bit packages can be found are:
http://mirror.slitaz.org/packages/next64/
http://mirror1.slitaz.org/packages/next64/


The above config file I can't find but from the build script:
Ln#452-468:
Code:

cd $curdir/slitaz-livecd-wkg

rcount=$(ls -1 ./rootfs*.gz | wc -l)

if [ $rcount -eq 1 ]; then
 echo "Extracting rootfs gz..."
 extractfs $curdir/slitaz-livecd-wkg/rootfs.gz
elif [ $rcount -gt 1 ]; then
   for rf1 in $(ls -1 ./rootfs*.gz | sort -r)
   do
    echo "Extracting $(basename $rf1)..."
    extractfs $rf1
   done
else
 echo "No rootfs found"
 exit
fi


we see that the extrafs command moves the iso contents to the root-fs folder:
LN#207-215:
Code:

extractfs() {
   
if [ ! -d $curdir/slitaz-rootfs ]; then
mkdir $curdir/slitaz-rootfs
fi

(busybox unlzma -c $1 || cat $1 ) 2>/dev/null | (cd $curdir/slitaz-rootfs; busybox cpio -idmu > /dev/null)

}
Back to top
View user's profile Send private message Visit poster's website 
mistfire

Joined: 04 Nov 2008
Posts: 1218
Location: PH

PostPosted: Sun 24 Feb 2019, 10:31    Post subject:  

@s243a

Did you ran the tazpuppy build kit on 64-bit puppy?

Also you must study the slitaz documentation very well before you do it
Back to top
View user's profile Send private message 
mistfire

Joined: 04 Nov 2008
Posts: 1218
Location: PH

PostPosted: Sun 24 Feb 2019, 12:20    Post subject:  

@s243a

according to slitaz download page. slitaz-core64 was just 32-bit program suite, only 64-bit was their kernel
Back to top
View user's profile Send private message 
mistfire

Joined: 04 Nov 2008
Posts: 1218
Location: PH

PostPosted: Sun 24 Feb 2019, 12:25    Post subject:  

@s243a

this link might help you
http://forum.slitaz.org/topic/slitaz-x86_64
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Mon 25 Feb 2019, 01:41    Post subject:  

mistfire wrote:
@s243a

this link might help you
http://forum.slitaz.org/topic/slitaz-x86_64


I found some links to ISOs in the discussion, unfortunately the links either expired or I needed permission. I did learn though from the thread that I can build an iso using cookutils so I may gave that a try.

In the mean time, I've replaced the 32bit files in your build kit with the 64bit version of the package from the next64 folder.
**I did this manually and didn't verify the checksums.


This modified build kit can be downloaded from:
https://www.dropbox.com/s/vuirof94f8g38e8/tazpup-builder64-pre-alpha?dl=0
**Build using "local mode". Still some syncing issues.

The following packages are missing 64bit versions:
Code:

grub4dos
libtdl
pcmciautis
util-linux-losetup
Xdialog
xorg-renderproto
xorg-xf86-video-geode
xorg-xf86-video-modesetting
xorg-xf86-video-radeonhd
xorg-xf86-video-v4l



Maybe:
aufs-utils-20150122.tazpkg
flsynclient
squashfs
xorgrdp


Some of these like grub4dos I replaced with a pet version from slaco 6.9.9.9. I noticed there was a folder called, "special packages".
Code:

flsynclient_tazpkg

I added a -32 at the end of the file name in this folder so that it wouldn't be included in the build. I also commented out the associted exit statment and replaced it with a "press enter to continue".

around line#244:
Code:

if [ $(find $curdir/special-packages -type f -name "*.tazpkg" | wc -l) -eq 0 ]; then
  echo "Special tazpup package is missing."
  #exithttps://www.dropbox.com/s/vuirof94f8g38e8/tazpup-builder64-pre-alpha?dl=0
  read -p "Press enter to continue" #added by s243a
fi


I added another "press enter to continue" at the point after the SliTaZ iso is extracted so that one could modify it if desired before the script starts installing packages (this would be required for now to get cloud-build mode to work):

Around line#257
Code:

if [ $rcount -eq 1 ]; then
 echo "Extracting rootfs gz..."
 extractfs $curdir/slitaz-livecd-wkg/rootfs.gz
elif [ $rcount -gt 1 ]; then
   for rf1 in $(ls -1 ./rootfs*.gz | sort -r)
   do
    echo "Extracting $(basename $rf1)..."
    extractfs $rf1
   done
else
 echo "No rootfs found"
 exit
fi

#exit
#chroot "$curdir/slitaz-rootfs/" tazpkg setup-mirror http://mirror.slitaz.org/packages/next64/
"http://mirror.slitaz.org/packages/next64/">$curdir/slitaz-livecd-wkg/var/lib/tazpkg/mirror
read -p "Press enter to continue"

*Note the line to overwriite /var/lib/tazpkg/mirror was added by me
**Note2 I should be writing to the slitaz-rootfs folder and not the slitaz-livcd-wkg folder but this doesn't matter since this isn't enough to change the repo. If one can't change the repo than cloud mode can't be used to download 64bit packages.
Code:

"http://mirror.slitaz.org/packages/next64/">$curdir/slitaz-rootfs/var/lib/tazpkg/mirror

***I also tried changing the repo with the "tazpkg setup-mirror" command but this also didn't work for me.

On another note; at the top of the folder structure there is a folder called s243a. This does nothing useful. It is just some snippets that I found interesting from the build script. Anyway, the kernal isn't syncing for me (with 64bit packages) at the point of the swhich-root when using the slitaz-core64 iso. You noted that this iso might not be suitable, so I'll look into building an iso via cookutils. I will also play around with what I built using the above build kit in a chroot environment.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Mon 25 Feb 2019, 05:01    Post subject:  

As I mentioned in another post; In the build-kit I think we have to patch tazpkg before installing files.

To do this I suggest moving:

--around line 554
Code:

if [ "$xmode" == "local" ]; then
 install_local_pkg
else
 install_online_pkg
fi

after

--Around line 632:
Code:

echo "Applying patches..."

cp --remove-destination -arf $curdir/tazpup-core-files/slitaz/* $curdir/slitaz-rootfs/ 2>/dev/null
cp --remove-destination -arf $curdir/tazpup-core-files/puppy/* $curdir/slitaz-rootfs/ 2>/dev/null

make_pupcore

if [ -f $curdir/slitaz-rootfs/usr/sbin/hald ]; then
 mv -f $curdir/slitaz-rootfs/usr/sbin/hald $curdir/slitaz-rootfs/usr/bin/hald
 sed -i -e "s#\/usr\/sbin\/hald#\/usr\/bin\/hald#g" $curdir/slitaz-rootfs/var/lib/tazpkg/installed/hal/files.list
 sed -i -e "s#\/usr\/sbin\/hald#\/usr\/bin\/hald#g" $curdir/slitaz-rootfs/var/lib/tazpkg/installed/hal/md5sum
 sed -i -e "s#\/usr\/sbin\/hald#\/usr\/bin\/hald#g" $curdir/slitaz-rootfs/etc/init.d/hald
fi

if [ -f $curdir/slitaz-rootfs/usr/share/applications/defaults.list ]; then
 rm -f $curdir/slitaz-rootfs/usr/share/applications/defaults.list
fi

echo "Updating system database..."

chroot "$curdir/slitaz-rootfs/" tazpkg tazpkg recharge
chroot "$curdir/slitaz-rootfs/" /usr/bin/update-desktop-database /usr/share/applications
chroot "$curdir/slitaz-rootfs/" /usr/bin/update-mime-database /usr/share/mime
chroot "$curdir/slitaz-rootfs/" /usr/bin/gtk-update-icon-cache /usr/share/icons/hicolor
chroot "$curdir/slitaz-rootfs/" /usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas
chroot "$curdir/slitaz-rootfs/" /usr/bin/gdk-pixbuf-query-loaders --update-cache
chroot "$curdir/slitaz-rootfs/" /usr/bin/gio-querymodules /usr/lib/gio/modules   
chroot "$curdir/slitaz-rootfs/" /usr/bin/fc-cache -f

if [ -e $curdir/slitaz-rootfs/usr/sbin/iconvconfig ]; then
 chroot "$curdir/slitaz-rootfs/" /usr/sbin/iconvconfig
fi


I'll try this and see what happens.

Edit 1: I notice that if you apply the patches early then packages won't install because "sh" points to "bash" which doesn't exist yet. My solution was to first install bash then install the patches and then install the rest of the packages.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Mon 25 Feb 2019, 08:32    Post subject:  

duplicate
Last edited by s243a on Mon 25 Feb 2019, 08:32; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Mon 25 Feb 2019, 08:32    Post subject:  

Another wierd thing I notice that after applying the patches that the bash executable doesn't work in the chroot environment but ash does. I think the difference is that ash is linked to busybox which is a static executable whereas the bash executable depends on the linker. I'm guessing that I need to add something like glibc to the package list but that wouldn't explain whey the executable worked before the patches but not after.
Back to top
View user's profile Send private message Visit poster's website 
mistfire

Joined: 04 Nov 2008
Posts: 1218
Location: PH

PostPosted: Mon 25 Feb 2019, 20:32    Post subject:  

@s243a keep exploring, you can do it.
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Wed 27 Feb 2019, 06:13    Post subject:  

mistfire wrote:
@s243a keep exploring, you can do it.


I'm making some progress. It now boots up to the log-in screen but slim doesn't load:
Code:

slim: waiting for X server to begin accepting connections.
slim: open_session: Unable to open session: The name org.freedesktop.ConsoleKit was not provided by any .service files



Current ISO:
https://www.dropbox.com/s/uw9z6xba8m0en8h/tazpup64-pre-alpha-1b.iso.iso?dl=0
Current Buidkit (unclearn)
https://www.dropbox.com/s/ymgzbn7jijil02s/buildkit-a1-unclearn.tar.gz?dl=0
Current Buildkit (clean)
https://www.dropbox.com/s/w9ustwlmpv8cabl/buildkit-a1-clearn.tar.gz?dl=0
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Sun 03 Mar 2019, 07:07    Post subject:  

**Just posting a note for myself here.

At startup:
/etc/init.d/rcS
calls
/etc/init.d/network.sh

around line #262 in funciton boot we have
Code:

[ -s /etc/sysctl.conf ] && sysctl -p /etc/sysctl.conf


This throws the following error if one installs procps-ng
Code:

sysctl: error while loading shared libraries: libproc-3.2.8.so: cannot open shared object file: No such file or directory

however if one installs procps -- which I think is a cutdown version -- then one doesn't get this error. The cutdown version (i.e. procps) uses the busybox version of sysctl.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Tue 05 Mar 2019, 23:07    Post subject:  

I'm planning to release an ISO soon which will work with the window manager and an updated build kit. I'm putting some notes here for my reference.

The following will be excluded from the iso:
Quote:

libgiomm-2.56.0-x86_64.tazpkg
gtkmm-2.24.5-x86_64.tazpkg
procps-3.2.8-x86_64.tazpkg and/or procps-ng-3.3.12-x86_64.tazpkg
consolekit2-1.2.1-x86_64.tazpkg
udev-182-x86_64.tazpkg #instead use eudev-3.2.7-x86_64.tazpkg



libgiomm seems to cause segmentation faults and isn't required. It is listed as a dependency for gtkmm and gtkmm is listed as a dependency for gparted. However, gparted will work with an alternative version of gtk.

procsps seems to be missing the dependency libproc-3.2.8.so, but the functions supplied by procsps can be replaced with the busybox version. I added some code in my build script to automatically replace these functions in case one installs procsps ( I think the procps-ng package has the same issues)
Code:

#Somd utilities in procps link to missing library libproc-3.2.8.so
while read -r line; do #https://unix.stackexchange.com/questions/85060/getting-relative-links-between-two-paths
  #https://stackoverflow.com/questions/9293887/reading-a-delimited-string-into-an-array-in-bash
  #https://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_10_02.html
  arr=($line)
  target_f=$curdir/slitaz-rootfs$prefix${arr[0]}
  source_f=${arr[1]}
  if [ -f $target_f ]; then
   
    fname=`basename $target_f`
    target_d=`dirname $target_f`
    mv $target_f $target_d/$fname-old
    cd $target_d
    pwd
    ln -s $source_f $fname
  fi
done <<EOM
/bin/uname busybox
/sbin/sysctl ../bin/busybox
/bin/ps busybox
/bin/kill busybox
/usr/bin/w ../../bin/busybox
/usr/bin/pmap ../../bin/busybox
/usr/bin/free ../../bin/busybox
/usr/bin/uptime ../../bin/busybox
/usr/bin/pkill ../../bin/busybox
/usr/bin/pgrep ../../bin/busybox
/usr/bin/top ../../bin/busybox
/usr/bin/watch ../../bin/busybox
EOM


Note that uname is supplied by several packages. One version depends on some receipt and I don't understand this process enough. However, hard-coding it to a receipt would be problematic if someone changed the kernel.

I think the version of eudev is newer than the udev package but I can't seem to find the missing library error. This error at least doesn't show up in the boot log. To ensure that I'm using eudev I make sure that it is installed after udev. This seems to eliminate a boot error that I noted on another post.

There is a boot message related to consolekit. I don't think it is required and I think it may cause some problems so currently I don't plan to include it.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Wed 06 Mar 2019, 00:49    Post subject:  

The latest challenge I've been having was to get the desktop to work. I've been booting into console mode with the boot option:
Code:

screen=text

I was able to get into the desktop with the command:
Code:

startx

https://www.pearltrees.com/s243a/startx-usr-tazpup-filesystem/id24233101
https://pastebin.com/vdrEK8pg

This function looks for a startup script called $HOME/.xsession, to start the Xorg & desktop session and if it isn't there it first creates the startup script via the function tazx. Tazx also does some basic configuration such as the fonts and keyboards.

The ./xsession script is nice and simple. It simply starts the Xorg server in the background and then starts the desktop. The default configuration file is loaded from:
Code:

. /etc/slitaz/applications.conf

which provides the name of the function to start the windows manager (e.g. lxde-session).

Actually both stat-up scripts .xsession and .xinitrc are generated by tazx. They are generated by installing the respective packages slitaz-configs-base and slitaz-configs. There are some errors in tazx that I note below:

Code:

slitaz_apps_conf() {
   apps_conf=/etc/slitaz/applications.conf #

   [ -f $apps_conf ] || inst_pkg slitaz-configs --forced #s243a: $apps_conf comes from slitaz-configs-base so this statement is wrong. 

   if [ "$(id -u)" -eq 0 ]; then
      user_conf="$apps_conf"
      new_user_conf='/etc/skel/.config/slitaz/applications.conf' #Not referenced by either .xsession or .xinitrc
      mkdir -p $(dirname $new_user_conf)
      cp -f $apps_conf $new_user_conf
   else
      # If started by: startx and with boot opts screen=text
      user_conf="${XDG_CONFIG_HOME:-$HOME/.config}/slitaz/applications.conf" #Not referenced by either .xsession or .xinitrc
      if [ ! -f "$user_conf" ]; then
         mkdir -p $(dirname $user_conf)
         cp $apps_conf $user_conf
      fi
   fi
   [ -f "$HOME/.xinitrc" ] || inst_pkg slitaz-configs-base --forced #s243a: $HOME/.xinitrc comes from slitaz-configs  so this statement is wrong. 
}


Both .xsession and .xinitrc import settings from /etc/slitaz/applications.conf but with .xinitrc you can over-ride these settings by specifying the window manager as the first argument:
Code:

. /etc/slitaz/applications.conf
tazbox mkmenu

[ "$1" ] && WINDOW_MANAGER="$1"

she startx script starts the Xorg script but the .xintrc script doesn't. I think this is because if one is using .xintrc then the xinit utility is supposed to start the Xorg server. Here is the ussage of xinit:
Code:

xinit [ [ client ] options ... ] [ -- [ server ] [ display ] options ... ]

https://linux.die.net/man/1/xinit

The window manager (e.g. jwm) is the client and Xorg is typically the server. I think that if one wants to pass an input argument to .xinitrc then they would do the following:
Code:

xinit ~/.xinitrc jwm -- Xorg :0


I'll experiment. Options for the Xorg server are documented at:
https://linux.die.net/man/1/xserver

Many are default. For instance
Code:
:0

is the default display. Actually one could leave off:
Code:

 -- Xorg :0

because Xorg is also the default xserver.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2124

PostPosted: Wed 06 Mar 2019, 03:27    Post subject:  

More notes to self:

One issue that I had is that when the desktop started (via startx) up the taskbar wasn't showing. I noticed in in the .xinitrc script there is a call to tazbox but there is no related call in the .xsession startup script. Tazbox has the following mkmenu() function:

Code:

mkmenu() {
   # (re)make the menu button with the user log name
   dd="$HOME/.local/share/desktop-directories"; mkdir -p "$dd"
   echo -e "[Desktop Entry]\nType=Directory\nName=$(whoami)" > "$dd/user.directory"

   # check the panel config file existence, copy from default config if needed
   panels=$(find $HOME/.config/lxpanel -type f -name panel 2>/dev/null)
   if [ -z "$panels" ]; then
      mkdir -p "$HOME/.config/lxpanel"
      cp -a /etc/skel/.config/lxpanel/* "$HOME/.config/lxpanel"
   fi

   for panel in $panels; do
      conf=$(tr '\n' '`' < $panel | sed 's|Plugin|\n&|g') # each plugin on its own line
      if fgrep -q 'user.directory' "$panel"; then
         # if menu already exists - shrink it to '@@@'
         newconf=$(echo "$conf" | sed 's|.*user\.directory.*$|@@@|')
      else
         # otherwise do nothing
         newconf="$conf"
      fi
      menu=$(cat <<EOT
Plugin {
    type = menu
    Config {
        name=user.directory
        image=avatar-default
        tintcolor=#33230D
        item {
            image=system-log-out-panel
            name=$(_ 'Close X session')
            action=tazbox logout exit
        }
        item {
            image=system-reboot-panel
            name=$(_ 'Reboot system')
            action=tazbox logout reboot
        }
        item {
            image=system-shutdown-panel
            name=$(_ 'Shutdown system')
            action=tazbox logout halt
        }
    }
}


I think the related puppylinux script is called fixmenus. I tried testing fixmenus in the chroot enviornment. I noticed that it looks in a folder called:
Code:

$HOME/.config/autostart/*.desktop

tazpup doesn't apear to use this mechanism for statup scripts. However, if I include an acount with the puppy windows manager jwm, then maybe I'll copy the *.desktop files into said folder.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 1 of 7 [92 Posts]   Goto page: 1, 2, 3, 4, 5, 6, 7 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Derivatives
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0952s ][ Queries: 11 (0.0152s) ][ GZIP on ]