(OLD) (ARCHIVED) Puppy Linux Discussion Forum Forum Index (OLD) (ARCHIVED) Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info

This forum can also be accessed as http://oldforum.puppylinux.com
It is now read-only and serves only as archives.

Please register over the NEW forum
https://forum.puppylinux.com
and continue your work there. Thank you.

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups    
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 19 Jan 2021, 04:45
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
RC7 (STABLE) WeeDogLinux Arch 64 now released
Moderators: Flash, JohnMurga
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
Page 6 of 55 [822 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, ..., 53, 54, 55 Next
Author Message
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Tue 04 Jun 2019, 10:23    Post subject:  

wiak wrote:
New versions (0.0.3) of mount_chroot.sh and umount_chroot.sh uploaded to first post of this thread (alongside the recently uploaded build_firstrib_rootfs version 0.0.4 scripts).

Actually, I have simply regressed mount_chroot.sh and umount_chroot.sh back to version 0.0.1 form but commented out the mount bind sharing of /mnt/home and put in a WARNING note regarding the potential danger of such a wide share: My warning stems from the fact that I just zapped my main XenialDog64 installation because I forgot I had a bind mount of /mnt/home active when I ran command 'rm -rf firstrib_rootfs' (oh no...). Unfortunately, since firstrib_rootfs/mnt/home was bind mounted to host XenialDog64 /mnt/home that whole partition and installation was itself deleted!!! Oh dear...



I made a similar mistake before but in my case I actually first tried to remove my binds. I now always ask, "do I really need to bind /mnt/home???". That said, I discovered the "-R" (i.e. recursive) option:

Code:

umount -R -f $CHROOT_DIR/dev

/woof-next/builders/chroot_and_tmpfs_fns.sh#L132
which might be a more reliable way to unmount a rbind.

fredx181 wrote:

Good that you can laugh about it, I had a similar drama years ago because of a mistake and I couldn't laugh about it. Confused
But hopefully for you , your backup is good enough to restore.
Btw, I had a look at your umount_chroot.sh script a I wonder: isnt't it more safe to use the -l (lazy) option of umount ? (but maybe you have special reason to not use it).

Fred


Lazy is safer unless you are going to do something distructive like delete the /dev folder, in which case you really do want to try your hardest to make sure the folder unbound and this might mean using the "-f" force option.

One could use the "-l" option in a loop with the necessary warning prompts and delays but eventually use the "-f" option if all else fails.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Tue 04 Jun 2019, 16:57    Post subject:  

Yeah, I suppose -l is slightly safer option, I wasn't aware of the option (but am aware of -R), but I don't think it would have protected me in this case (or maybe it would? I can't say I really understand the option) or any of the other suggestions. My limited understanding of umount -l option is that it will protect firstrib_rootfs itself if attempt made to umount these locations when firstrib has some processes still using them(?)

Fact is, my error was really a rare example of why it can be risky running our systems as root user. rm -rf is always risky in that situation! As hobbyists most of the time it doesn't matter and is a great convenience so I agree not worth being paranoid about. However, in mission critical kind of work, such an accident would be very costly and no-one is such environment should be doing serious admin work as permanent root user, but of course admins sometimes need to become root user and then they can always damage the system anyway if not thinking straight.

But, yeah, in my case hardly anything lost - I did indeed have a full backup of most of my partitions, which covered me for even most of the newer additions.

I didn't mount with --rbind so I'm surprised (without thinking how it worked) I lost quite so much, but I'm no expert at using mount. I will however stick the -l option on the umount lines and leave it at that.

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797

Last edited by wiak on Tue 04 Jun 2019, 17:53; edited 4 times in total
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Tue 04 Jun 2019, 17:05    Post subject:  

What complicated matters for me is that I must have been in crazy mode because I had, completely unrelated to the umount matter, somehow erased part of my grub2 folder so I could no longer boot the system. That in fact is how I noticed my big /mnt/home delete - I was trying to boot - got grub2 errors so booted a live distro from usb and discovered /mnt/home was also gone - totally separate matter (I had been experimenting moving a full Void install around but forgot it had the grub2 files in its /boot sigh...). Oh well, lightning can strike twice despite the rumours.

I actually know nothing about grub2 other than how to fill in the linux install details to grub.cfg so was lucky I had a Void boot folder backed up, which contained the same grub2 info I had lost.

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Tue 04 Jun 2019, 18:06    Post subject:  

Decided to always make version number of mount_chroot.sh and umount_chroot.sh same as current build_firstrib_rootfs*.sh to avoid confusion. I've thus uploaded ver 0.0.4 of mount_chroot.sh and umount_chroot.sh.

The only change from previous version is that I've used the umount -l option so that the umount won't occur while firstrib busy.

From man page umount -l: "Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore. (Requires kernel 2.4.11 or later.)"

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
AndresC2

Joined: 08 Jul 2017
Posts: 76

PostPosted: Tue 04 Jun 2019, 20:13    Post subject:  

Hi wiak

"running firstrib in a chroot or container"

for example rufwoof script

http://murga-linux.com/puppy/viewtopic.php?t=112125&start=540

from rufwoof script for example

change:

mount -o loop /initrd/mnt/dev_save/dpup/puppy_stretch_7.5.sfs /root/sfs

to

mount -o loop firstrib_rootfs.sfs /root/sfs

but you need this in tinycore or another distro

# unionfs_fuse
# libcap2-bin_2.25-1
# xserver-xephyr

you can try study rufwoof script

good bye.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Tue 04 Jun 2019, 21:27    Post subject:  

AndresC2 wrote:
Hi wiak

"running firstrib in a chroot or container"

for example rufwoof script

http://murga-linux.com/puppy/viewtopic.php?t=112125&start=540

from rufwoof script for example

change:

mount -o loop /initrd/mnt/dev_save/dpup/puppy_stretch_7.5.sfs /root/sfs

to

mount -o loop firstrib_rootfs.sfs /root/sfs

but you need this in tinycore or another distro

# unionfs_fuse
# libcap2-bin_2.25-1
# xserver-xephyr

you can try study rufwoof script

good bye.


Thanks, AndresC2, using containers such as rufwoof described and as used by BarryK in EasyOS, is a nice way to do things. The extra info on tinycore needs will prove very useful to those using that.

Cheers,

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Tue 04 Jun 2019, 22:03    Post subject: getting backspace to work with bash install  

rockedge wrote:
I can't backspace and if I resize the terminal window it pulls lots of prompts.


Finally... I've solved the issue with bash not working with backspace key in a small installation:

For backspace to work, bash needs /usr/share/terminfo, which is packaged as part of 'ncurses-base' (which has an install size of only 225kB). Oddly, though I came across others, on other Linux system installs, with similar bash backspace issues via google, nowhere did I find a working answer to the issue they raised. Ending up finding it myself by 'experiment' (I guess I should google again and provide the answer...):

i.e. To install bash with result that backspace key works correctly use:

Code:
xbps-install -S bash ncurses-base


Alternatively, you might want the larger package of full ncurses anyway (install size of around 5 MB), which auto-install ncurses-base as a dependency, in which case you would:

Code:
xbps-install -S bash ncurses


Of course, a larger install that uses the likes of base-system template/meta-package includes ncurses-base as a dependency anyway.

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Wed 05 Jun 2019, 07:07    Post subject:  

So just for some fun I downloaded latest dotpet of sc0ttman's pkg, untarred it, and merged the result into my pre-built firstrib_rootfs and ./mount_chroot.sh into that via my XenialDog64 host.

Using xbps-install I installed what seemed to be some of the major pkg dependencies: coreutils, sed, grep, findutils, wget. I had hoped pkg would work with busybox versions of these, but it had problems without the full versions (despite pkg advertised dependencies saying busybox wget and find okay, that didn't prove to be the case). When I first ran pkg --help it complained something about no repos, so I opened up BionicPup64 sfs and manually copied and pasted its /var/packages folder contents into firstrib_rootfs /root/.packages (a directory that came with the pkg installation). A symlink back to /var/packages approach would have been a bit better...

So on running pkg --help, pkg gave me its startup help screen (as shown on attached screenshot).

I also did a: pkg --update-sources

"pkg list-deps kodi" also worked, though it was a bit slow to report the dependencies.

I then got ambitious and tried installing frisbee (since I noticed it was in the current repo). pkg came back and said it was already built-in (as it is in BionicPup64 of course). I checked pkg script and noted it worked that out from /root/.packages/woof-installed-packages. So I cheated, and deleted the frisbee entry from that file, and once again tried: pkg add frisbee (actually ended up doing it twice so used pkg -f -g add frisbee command).

And pkg tried to do it's job and succeeded partially at least, as the second attached screenshot shows (despite Error on installation being indicated, frisbee binary, and various of its dependencies, was certainly now found on the system).

So could we build a Puppy via FirstRib and installed pkg (with pkg dependencies themselves installed using xbps)? Seems like it is possible... but I won't be doing it (my experiment was a very quick one just out of curiousity and I can't be bothered working harder on that since I have other priorities). Maybe interesting for someone to try though. Once pkg correctly set up xbps could be removed of course. I do wish pkg could have worked with busybox alone though, and I got the feeling pkg might unfortunately depend on a lot more underlying puppy core files than I dealt with, which would be a pity really. Nice if pkg could be made standalone capable, such as xbps - then it would be simple to build a FirstRib Puppy flavour. Nevertheless, the experiment suggested pkg was close to being capable of standalone (with say busybox) operation.

wiak

EDIT: Have since added petget (files takes from BionicDog64) so I could try "pkg repo-update". Basically just copied over the whole folder /usr/local/petget and then made a symlink ln -s /usr/local/petget /usr/bin/petget/petget. I'm not sure what difference having petget has (and would prefer anyway if pkg was not petget dependent in anyway). I think I needed to use xbps to install bash (with ncurses-base) for petget to work.

EDIT2: Also added dpkg-deb binary from BionicPup64 into /usr/bin and as a new test did:
Code:
pkg add jsfutils

and that seems to have successfully installed. Trouble with Puppy building, however, is that it doesn't use its package manager for its complete build; first it simply downloads a rootfs-skeleton containing tons of files in a fixed directory structure - that's a bit of a pain IMO, but I guess I can try that and see if I can end up with some form of BionicPup64 root filesystem (after also getting selection of woof-CE rootfs-packages and other packages such as specified in DISTRO_PKGS_SPECS-ubuntu-bionic). I'm tempted to try - will think about it tomorrow... Main thing is, that if pkg and petget are now working correctly it should I feel now be possible to build a puppy based on FirstRib.
pkg3.jpg
 Description   
 Filesize   78.6 KB
 Viewed   874 Time(s)

pkg3.jpg

pkg2.jpg
 Description   
 Filesize   55.06 KB
 Viewed   944 Time(s)

pkg2.jpg

pkg1.jpg
 Description   
 Filesize   67.09 KB
 Viewed   959 Time(s)

pkg1.jpg


_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797

Last edited by wiak on Thu 06 Jun 2019, 17:13; edited 2 times in total
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Thu 06 Jun 2019, 08:42    Post subject:  

But no, it was an interesting experiment playing with sc0ttman's pkg, but I'd prefer to leave that now and get on with my plans for FirstRib void flavour rather than trying to script some kind of Puppy out of it, since Puppy rootfs would have to be reorganised and all made into dotpet form for pkg to install it all. But, yes, it's pretty clear to me that that could be done by extending my above post (and scripting it using build_firstrib_rootfs*.sh as the core of that). Hopefully above post is enough for someone else to try this if they so want.

My advice, therefore, to anyone wanting to re-design a Puppy build system would be to re-organise it such that a suitable commandline package manager (maybe pkg, albeit modified a bit to just depend on busybox and not need to also depend on petget for any functionality) would be able to fetch and install the complete system in modular form (such as is done with Void Linux; base-files, base-system, and so on). So if pkg could be made dependent only on busybox and the current rootfs-skeleton be done as some kind of base dotpet and other parts also packaged in dotpet form for pkg to fetch, then the build system becomes easy to script (as it is with FirstRib Void Linux flavour).

i.e. design should be organised into the form: busybox + native package manager

which is what FirstRib build system design is.

Then the rest of the build script simply uses the package manager to install the rest of the system and another simple build script builds the initramfs in similar fashion, for booting.

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Thu 06 Jun 2019, 10:01    Post subject:  

wiak wrote:

EDIT: Have since added petget (files takes from BionicDog64) so I could try "pkg repo-update". I'm not sure what difference having petget has (and would prefer anyway if pkg was not petget dependent in anyway). I think I needed to use xbps to install bash (with ncurses-base) for petget to work.


I think the only petget files that you need from pkg are:
/usr/local/petget/0setup
/usr/local/petget/debdb2pupdb
/usr/local/petget/find_cat

not count the files that you need in /root/.packages:
DISTRO_COMPAT_REPOS
DISTRO_PET_REPOS
DISTRO_PKGS_SPECS
PKGS_HOMEPAGES
PKGS_MANAGEMENT
Packages-devuan-ascii-contrib
Packages-devuan-ascii-main
Packages-devuan-ascii-non-free
Packages-puppy-ascii-official
Packages-puppy-common-official
Packages-puppy-noarch-official

The first group of files are to convert the compatible repo database into the puppy format. The latter group of files are to define which repos to use. I think it still might be slightly buggy though because I think that the name of some files in the repo might depend on three fields: name, version + update number; but this is just a wild guess. I haven't investigated it yet and I need to reproduce the error.

Quote:

"pkg list-deps kodi" also worked, though it was a bit slow to report the dependencies.


I think that pkg is slow because it is searching multiple repos. That said I think if pkg used awk it might be faster than the combination of grep + cut.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Thu 06 Jun 2019, 16:25    Post subject:  

s243a wrote:
wiak wrote:

EDIT: Have since added petget (files takes from BionicDog64) so I could try "pkg repo-update". I'm not sure what difference having petget has (and would prefer anyway if pkg was not petget dependent in anyway). I think I needed to use xbps to install bash (with ncurses-base) for petget to work.


I think the only petget files that you need from pkg are:
/usr/local/petget/0setup
/usr/local/petget/debdb2pupdb
/usr/local/petget/find_cat


Yes, that sounds right since pkg does the other petget-type functions itself. For the moment just using whole of /usr/local/petget though since not particularly large in size anyway.

find_cat is the ELF binary part of petget, which I presume is compiled code as a speed-up search component. I guess pkg itself uses that similarly though I have not studied pkg at all myself and have no idea how it does things.

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Thu 06 Jun 2019, 16:30    Post subject:  

wiak wrote:
s243a wrote:
wiak wrote:

EDIT: Have since added petget (files takes from BionicDog64) so I could try "pkg repo-update". I'm not sure what difference having petget has (and would prefer anyway if pkg was not petget dependent in anyway). I think I needed to use xbps to install bash (with ncurses-base) for petget to work.


I think the only petget files that you need from pkg are:
/usr/local/petget/0setup
/usr/local/petget/debdb2pupdb
/usr/local/petget/find_cat


Yes, that sounds right since pkg does the other petget-type functions itself. For the moment just using whole of /usr/local/petget though since not particularly large in size anyway.

find_cat is the ELF binary part of petget, which I presume is compiled code as a speed-up search component. I guess pkg itself uses that similarly though I have not studied pkg at all myself and have no idea how it does things.

wiak


correct. The source files can be found at:
/woof-CE/tree/master/initrd-progs/pkg/w_apps_static/w_apps

P.S. there might be a bug in the code that converts the files from debian format. I reported the issue in sc0ttman's pkg thread:
p=1029951#1029951

alternatively the bug might be in scottman's "pkg". As a final alternative, maybe I needed to copy more than these three files listed above???

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Thu 06 Jun 2019, 17:21    Post subject:  

I'm presumed 'pkg repo-update' performs some kind of sync of upstream repo contents to local, but if that was the case I'm surprised pkg list-deps kodi took so long if only then having to search through the deps locally. I suspect either the deps search routine could do with speeding up or the search isn't happening locally (it would be better if it was: apt update takes a while, and so does xbps-install -S, but thereafter searching, since local, is very quick, and Puppy pkg should do similar).

Any error in conversion from deb pkg format would certainly be a priority for a fix, wherever (pkg or petget) it is occuring.

plg itself is certainly a nice and promising piece of work; pity it inherits some petget design concepts though: having to set up the likes of DISTRO_PKGS_SPECS and similar seems overly complicated from the Puppy distro user/builder's point of view. Should just need to provide a simple list of packages wanted really, rather than having to tinker with such specially formatted files, which is far too complicated a process for most people to consider.

It's a pity, really, that Puppy itself, once carefully built, has such nice usability, from users point of view, but its build system woof-CE is so poor in that user-friendly/usability respect, and petget system so annoying/inefficient and flawed more generally. Really needs package management concept redesign and woof-CE needs binned since quicker to make a new design than continually hack away at that woof-CE mess IMO. Yes, it would take a lot of effort to read and understand all of how woof-CE works before being able to contribute to it, but why bother? It is like trying to master a language that no-one uses or would want to use. Throw it away and start afresh (though use it in the meantime since that's all there is - but too much time wasted on it - doesn't need 'guardians'... the opposite actually). It is ridiculous that a build system needs constant user-input (should be properly commandline driven, via commandline arguments - then various frontends could be easily produced for it using ncurses, dialog, yad, gtkdialog, whatever...).

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Fri 07 Jun 2019, 18:57    Post subject:  

wiak wrote:
My advice, therefore, to anyone wanting to re-design a Puppy build system would be to re-organise it such that a suitable commandline package manager (maybe pkg, albeit modified a bit to just depend on busybox and not need to also depend on petget for any functionality) would be able to fetch and install the complete system in modular form (such as is done with Void Linux; base-files, base-system, and so on).


It seems like the woof-CE team might agree with you here:

wdlkmpx wrote:

The ppm in the experimental branch probably needs some more testing and a few more fixes, i.... don't feel like doing that. And in fact it needs to be simplified even more.

It's basically a massive cleanup with some optimizations, one of the many massive cleanups in the history of woofce performed by yours truly.

https://github.com/puppylinux-woof-CE/woof-CE/issues/1460#issuecomment-499960217


mistfire is doing a lot of fixes to the puppy package manager on the github woof-CE repo under the name rizalmart see post:
http://www.murga-linux.com/puppy/viewtopic.php?p=1029733#1029733

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 2075
Location: not Bulgaria

PostPosted: Sat 15 Jun 2019, 08:14    Post subject:  

Started new thread on creation of initramfs for FirstRib to allow it to be booted independently of any host Linux. The first, very simple, initramfs build script has now been uploaded with details here:

http://www.murga-linux.com/puppy/viewtopic.php?p=1030321#1030321

As explained there, this first initramfs isn't of much practical use. Rather it is uploaded to illustrate some general principles of initramfs construction.

With suitable vmlinuz kernel (that from BionicPup is highly recommended) it may, depending on your hardware, allow firstrib_rootfs to be booted independently (albeit without internet connectivity unless your firstrib_rootfs has been expanded to include network apps/configuration). Nor does this first initramfs provide save persistence, though next build script (already working but not yet uploaded) will provide that via overlayfs/chroot mechanism.

wiak

_________________
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 6 of 55 [822 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, ..., 53, 54, 55 Next
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
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.4395s ][ Queries: 13 (0.3103s) ][ GZIP on ]