Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Avoiding opentmpfiles minimising silent breakage
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 309

PostPosted: Fri Sep 28, 2018 12:18 pm    Post subject: Reply with quote

Thanks everyone, I have changed the title of the thread as it became apparent to me that it was opentmpfiles which I wanted to avoid and that I have tmpfiles already as part of openrc-0.13.11.
Adding virtual/tmpfiles-0 to package.provided works for me.

Sorry for any confusion caused by my incorrect thread title and initial post information :oops:
Thanks for explaining tmpfiles and why it is probably a good idea for me to retain it 8)
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 309

PostPosted: Fri Sep 28, 2018 12:58 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Upstream is not forcing us to do this, it's Hubbs insane desire to make openrc look like systemd.
Since there are holdouts not wanting a systemd only distro, he's decided to slowly destroy it by making it look like the warmed over coprophilic pile called systemd.
That's all on Hubbs and should be a reason for his dismissal from power in gentoo.


I do not know Hubbs motivation - but sadly the outcome appears to be some fairly fundamental packages like openrc are suffering ... it might be that the only practical way to run a system with openrc for most people in future is by supporting more and more mechanisms like those provided as part of systemd which system components/applications rely on. For me at present openrc-0.13.11 does what I need but having this package in a local overlay rather than using the in tree stable version is a worry ... but some of the changes going on with openrc at the time made little sense to me.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3869
Location: Dallas area

PostPosted: Fri Sep 28, 2018 2:27 pm    Post subject: Reply with quote

One other thing is needed to emulate the latest tmpfiles on older openrc
Code:
ln -s /lib/rc/sh/tmpfiles.sh /bin/tmpfiles

Either be root or sudo to do the above.

That's because tmpfiles_process in tmpfiles.eclass calls it to run the /usr/lib/tmpfiles.d/*.conf files for whatever is put there.

I just noticed that I didn't have a /run/sudo directory, and that hasn't stopped sudo from running.
But the change above 100% mirrors what the latest opentmpfiles does.


---

These are the files that call tmpfiles.eclass (right now)
app-admin/sudo
app-admin/puppetserver
app-emulation/virtualbox
app-metrics/collectd
app-portage/eix
dev-db/mysql-init-scripts
mail-filter/policyd-weight
net-ftp/proftpd
net-im/coturn
net-misc/connman
net-misc/quagga
net-misc/gerbera
net-p2p/resilio-sync
sys-apps/logwatch
www-servers/apache
x11-wm/xpra

but out of those these are the only files in /usr/lib/tmpfiles.d
cyrus-sasl.conf
eix.conf
man-db.conf
named.conf
portage-ccache.conf
revdep-rebuild.conf
samba.conf
sudo.conf


I checked what was running vs what would have happened if I had had the link done earlier and
I had to run sudo.conf and named.conf (though they were fine with the old permissions)

To manually run (and do what tmpfiles_process from eclass does by way of the ebuild)
Code:
tmpfiles --create /usr/lib/tmpfiles.d/<name>.conf


In the case of sudo it creates a directory and a directory w/timestamp under it (systemd crapola) but sudo had worked just fine without it (I use it daily)
In the case of named it changed the directory permissions from 770 root name to 755 named named. But again it's been working just fine for me the old way.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon


Last edited by Anon-E-moose on Fri Sep 28, 2018 5:04 pm; edited 1 time in total
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3048
Location: Illinois, USA

PostPosted: Fri Sep 28, 2018 4:00 pm    Post subject: Reply with quote

Anon-E-moose wrote:
ETA2: I did look at the difference between what's in openrc-0.13 and opentmpfile-0.1.3 and the init.d files differ in where the tmpfiles shell script is called from, but the options passed are exactly the same, other than location of shell script.
Opentmpfiles puts the tmpfiles shell script in /bin instead of /lib/rc/sh/ which is stupid, AFAIC, as it's not something that should be used indiscriminately, which it might be if left in /bin.
The tmpfiles shell script has been changed, mostly to add new options, for dry-run, etc. but overall it does the same things as tmpfiles.sh from <openrc-0.23.
Thank you for your research. I have updated my ebuild accordingly. I intend to research all these differences between the tarballs that you kindly linked to, but it will probably take months, squeezing it in a bit at a time.
Back to top
View user's profile Send private message
engineermdr
Apprentice
Apprentice


Joined: 08 Nov 2003
Posts: 273
Location: Altoona, WI, USA

PostPosted: Fri Sep 28, 2018 8:51 pm    Post subject: Reply with quote

Thanks everyone! This topic has been very useful to me as well.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sat Sep 29, 2018 10:57 am    Post subject: Reply with quote

Hu wrote:
Given those choices, supporting tmpfiles is the path of least resistance.

Hu ... missed this yesterday. I thought the argument was that we accept systemd into the tree as "gentoo is about choice", and that such choices would happily co-exist. When the results of that "choice" is laid bare we are prompted to accept the current state of affairs, as though it wasn't obvious from the outset that such "choice" would negatively effect those not choosing systemd. At the time, anyone voicing an objection was labelled anti-choice, and the substantive question of what that choice would inevitably mean was swept aside, because it simply didn't serve the interests of those promoting its inclusion/adoption. All of this was clear as day, but there wasn't the political will to do anything to resist this deception, and to preserve some semblance of "community". That is gentoo's failure, not upstream's ... and so after the fact we can't pretend that this state of affairs wasn't the result of our actions (including that of following "the path of least resistance") ... we didn't stumble blindly into this situation, we were active participants (some more than others). So, I reject the idea that this is some sort of accident that we must now make the best of, that is little more than cover for those who actively brought this about (again, some more than others), otherwise all we have here is peace of the boiled frog front.

best ... khay
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3869
Location: Dallas area

PostPosted: Sat Sep 29, 2018 11:34 am    Post subject: Reply with quote

I know I was on openrc-0.9.8.4 for a couple of years and it didn't have tmpfiles at all, I also think that was before the /usr "merge"

I went from there to openrc-0.11.5/6 and tmpfiles was in that version. So not sure exactly when it was introduced but between those 2 versions

The system did work well without tmpfiles, I think they just used whatever package defaults there were for dir/file permissions.


Edit to add: From the 0.13.11 ebuild
Code:
    # termencoding was added in 0.2.1 and needed in boot
    has_version ">=sys-apps/openrc-0.2.1" || add_boot_init termencoding

    # swapfiles was added in 0.9.9 and needed in boot (february 2012)
    has_version ">=sys-apps/openrc-0.9.9" || add_boot_init swapfiles

    if ! has_version ">=sys-apps/openrc-0.11"; then
        add_boot_init sysfs sysinit
    fi

    if ! has_version ">=sys-apps/openrc-0.11.3" ; then
        migrate_udev_mount_script
        add_boot_init tmpfiles.setup boot
    fi

    # these were added in 0.12.
    if ! has_version ">=sys-apps/openrc-0.12"; then
        add_boot_init loopback
        add_boot_init tmpfiles.dev sysinit

_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13761

PostPosted: Sat Sep 29, 2018 4:11 pm    Post subject: Reply with quote

khayyam: for this thread, I am mostly ignoring how we got into the state that systemd has encroached as far as it has, and consequently ignoring who is at fault for the situation. I am looking at the practical consequences to non-systemd users, which is what I laid out above. Their choices are:
  1. Cease using programs that develop a systemd dependency.
  2. Accept reduced, possibly severely reduced, functionality in those programs when the program tries to use systemd and cannot, because it is not installed. In extreme cases, the program may be completely unusable when systemd is absent.
  3. Patch those programs not to depend on systemd.
  4. Motivate the authors of those programs (e.g. GNOME) to make systemd optional.
  5. Emulate the systemd functionality that those programs now depend on.
For the specific situation of tmpfiles, the systemd solution is ugly, but relatively effective at solving the stated problem (the need for specific directories to effectively survive reboot, despite being stored in a tmpfs) and relatively easy to emulate on non-systemd systems. Other systemd features, such as its replacement for service management and the bundled in sandboxing, are far more invasive and may require a different answer. For example, it is currently accepted wisdom that services on a non-systemd system should be handled through an initscript (option 3 or option 4, depending on whether upstream maintains the script or the distribution maintains it), rather than having a service responsible for reading and executing systemd unit files (which would be option 5).
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6944
Location: Austria

PostPosted: Sat Sep 29, 2018 4:14 pm    Post subject: Reply with quote

Hu wrote:
Motivate the authors of those programs (e.g. GNOME) to make systemd optional.

This is already the case. And it is done through elogind, which is a standalone logind implementation (see your point 5). Alas, some people prefer to run in circles rather than making a positive contribution, e.g. as a follow-up to https://forums.gentoo.org/viewtopic-p-8243122.html#8243122.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 17862

PostPosted: Sat Sep 29, 2018 5:00 pm    Post subject: Reply with quote

Hu wrote:
3. Patch those programs not to depend on systemd.
4. Motivate the authors of those programs (e.g. GNOME) to make systemd optional.
It is disconcerting how many seemingly non-Gnome programs now use the tmpfiles.eclass (Anon-E-moose's post). I presume it is due to upstream, which is why I find it disconcerting. I wonder how difficult it would be to port sudo from BSD. And there does appear to be at least one Linux port of OpenBSD's doas. But maybe the effort wouldn't be worth the benefit.
_________________

Believing I had supernatural powers I slammed into a brick wall.
I said hey, is this my problem? Is this my fault?
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3869
Location: Dallas area

PostPosted: Sat Sep 29, 2018 5:12 pm    Post subject: Reply with quote

Tmpfiles.eclass in and of itself isn't bad, though it hardcodes virtual/tmpfiles and that only looks at 2 choices systemd (sigh) and opentmpfile (which only looks at openrc >0.22) (sigh again)

Actually with a little modification, opentmpfile would work with all versions of openrc. It's not terribly difficult.
But not worth the effort to file a bug, go and forth with someone like hubbs and then have it rejected anyway.

Edit to add: I suppose a patch to openrc <0.23 would work then opentmpfile would be installed.
I just don't understand the mindset of people like hubbs who keep destroying things that work and try and make things like openrc look like systemd.
They don't do the same thing and if one looks at many ebuilds they are have an if-else for systemd/openrc, so it's not like it's forced to be one way.


ETA2: something like copying openrc-0.13.11.ebuild to openrc-1.13.11-r1.ebuild and applying this patch would probably work (off the top of my head - NOT TESTED)
Code:
$ diff -u openrc-0.13.11.ebuild openrc-1.13.11-r1.ebuild
--- openrc-0.13.11.ebuild   2015-02-26 13:01:17.000000000 -0600
+++ openrc-1.13.11-r1.ebuild   2018-09-29 12:49:10.748413189 -0500
@@ -210,13 +210,13 @@
 
    if ! has_version ">=sys-apps/openrc-0.11.3" ; then
       migrate_udev_mount_script
-      add_boot_init tmpfiles.setup boot
+      rm -f /etc/runlevels/boot/tmpfiles.setup
    fi
 
    # these were added in 0.12.
    if ! has_version ">=sys-apps/openrc-0.12"; then
       add_boot_init loopback
-      add_boot_init tmpfiles.dev sysinit
+      rm -f /etc/runlevels/sysinit/tmpfiles.dev
 
       # ensure existing /etc/conf.d/net is not removed
       # undoes the hack to get around CONFIG_PROTECT in openrc-0.11.8 and earlier


It does leave /lib/rc/sh/tmpfiles.sh where it is, but it won't be used so no big deal
and it would allow opentmpfile to be installed and run (no need for virtual/tmpfile in package.provided)

Several ways (choose your poison) :lol:
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sat Sep 29, 2018 6:47 pm    Post subject: Reply with quote

Hu wrote:
khayyam: for this thread, I am mostly ignoring how we got into the state that systemd has encroached as far as it has, and consequently ignoring who is at fault for the situation. I am looking at the practical consequences to non-systemd users, which is what I laid out above.

Hu ... which is to cast it as a technical problem, when it is in fact a socio-political problem.

best ... khay
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 17862

PostPosted: Sat Sep 29, 2018 9:53 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Tmpfiles.eclass in and of itself isn't bad, though it hardcodes virtual/tmpfiles and that only looks at 2 choices systemd (sigh) and opentmpfile (which only looks at openrc >0.22) (sigh again)
The description of opentmpfiles indicates a "utility to process systemd-style tmpfiles.d files." So does that not mean virtual/tmpfiles must support "systemd-style tmpfiles.d files"? I personally do not want systemd style anything in my environment.

Anon-E-moose wrote:
Several ways (choose your poison) :lol:
Unfortunately I have never been employed such that I could justifiably work on it during business hours, and playing Whack-A-Systemd is starting to take too much manual effort. I was already on openrc-0.28 by the time I found out about some of the changes and haven't made the time to downgrade (and be prepared to deal with breakage).
_________________

Believing I had supernatural powers I slammed into a brick wall.
I said hey, is this my problem? Is this my fault?
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3869
Location: Dallas area

PostPosted: Sat Sep 29, 2018 10:35 pm    Post subject: Reply with quote

As I said earlier I've run without the .conf files being processed ala systemd, most software takes a reasonable default for directory ownership and permissions.
But in looking at even old openrc tmpfiles has been part of openrc going back to 0.11 IIRC, and it's followed the systemd way for a while, so even without it being acknowledge it's been there. It's just that with breaking it out into a separate package, it's gotten visible.

This is from tmpfiles.sh which came from openrc-0.13.11 that I run.
Code:
# This instance is a pure-POSIX sh version, written by Robin H Johnson
# <robbat2@gentoo.org>, based on the Arch Linux version as of 2012/01/01:
# http://projects.archlinux.org/initscripts.git/tree/arch-tmpfiles
#
# See the tmpfiles.d manpage as well:
# http://0pointer.de/public/systemd-man/tmpfiles.d.html
# This script should match the manpage as of 2012/03/12


Is it necessary? No, I use the older version and the latest sudo and named still ran fine, even though directories weren't being created ala systemd way.
Both new sudo and named call /bin/tmpfiles, which the older versions of openrc didn't have, they used /lib/rc/sh/tmpfiles.sh, so .conf files didn't get run.
New eix .conf didn't get called either but /var/cache/eix directory had already had the correct ownership/permissions from previous installs.


I don't think there would be much breakage with downgrading, but since I've not upgraded and then downgraded, take my opinion with a grain of salt.
I do know that with a reasonable amount of system knowledge you wouldn't be left with an unusable system.
Basically, put virtual/tmpfiles in package.provided, depclean opentmpfile and set a limit on openrc <0.23


Going forward from here, it's just play it by ear, maybe the openrc devs will quit mucking with it and things like opentmpfile, but who knows.


Edit to add:
Code:
$ equery d openrc
 * These packages depend on openrc:
net-misc/netifrc-0.2.2 (>=sys-apps/openrc-0.12)
virtual/service-manager-0 (!prefix ? sys-apps/openrc)

_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3048
Location: Illinois, USA

PostPosted: Sat Sep 29, 2018 11:31 pm    Post subject: Reply with quote

Code:
tony@MSI ~ $ equery d openrc
 * These packages depend on openrc:
media-tv/sageclient-bin-9.1.9.514-r4 (sys-apps/openrc)
media-tv/sageserver-bin-9.1.9.514-r2 (sys-apps/openrc)
net-misc/netifrc-0.2.2 (sys-apps/openrc)
virtual/service-manager-0 (!prefix ? sys-apps/openrc)
virtual/tmpfiles-10-r2 (<sys-apps/openrc-0.23)
The first two are from my private overlay and as indicated above, I've modified virtual/tmpfiles in that overlay.

Regarding sudo, I used meld to view the changes pre- and post- requiring tmpfiles but saw nothing indicating anything had changed. Why would tmpfiles be needed? Does sudo run during boot or sysinit? I don't see that.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6279

PostPosted: Sun Sep 30, 2018 7:38 pm    Post subject: Reply with quote

Anon-E-moose wrote:
when one is using an older openrc that supports tmpfiles

I was surprised to hear that openrc-0.13 already had tmpfiles support. (Also from the topic I had guessed that this is not the case).
But I checked and you are right: tmpfiles support exists since openrc-0.11.
In this case, of course, package.provided has no technical issues and does not cause silent breakage (except perhaps due to some bugs in the early tmpfile implementation; I did not check now when these bugs have been fixed.) Of course with freezing the openrc version you also freeze the tmpfiles version unless you manually update from opentmpfiles.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 17862

PostPosted: Sun Sep 30, 2018 8:23 pm    Post subject: Reply with quote

Anon-E-moose wrote:
But in looking at even old openrc tmpfiles has been part of openrc going back to 0.11 IIRC, and it's followed the systemd way for a while, so even without it being acknowledge it's been there. It's just that with breaking it out into a separate package, it's gotten visible.
Exactly. So the "systemd style tmpfiles" are going to be there, regardless. So I have to ask myself, what am I gaining by fighting opentmpfiles? My interest in downgrading openrc predated this information, which seems to make less worth the effort.

Anon-E-moose wrote:
Is it necessary? No, I use the older version and the latest sudo and named still ran fine, even though directories weren't being created ala systemd way.
Despite that, sudo theoretically expects the support to exist, does it not?

Anon-E-moose wrote:
Both new sudo and named call /bin/tmpfiles, which the older versions of openrc didn't have, they used /lib/rc/sh/tmpfiles.sh, so .conf files didn't get run.
New eix .conf didn't get called either but /var/cache/eix directory had already had the correct ownership/permissions from previous installs.
Is "optntmpfiles / systemd tyle tmpfiles" support optional without an option to disable it? I think I'm just getting more confused about what opentmpfiles supposedly does if applications that require it don't actually need it but don't allow for it to not be excluded. Such as "USE=-systemd" -> "systemd support is not necessary, so I don't required virtual/tmpfiles."

Anon-E-moose wrote:
I don't think there would be much breakage with downgrading, but since I've not upgraded and then downgraded, take my opinion with a grain of salt.
I do know that with a reasonable amount of system knowledge you wouldn't be left with an unusable system.
Basically, put virtual/tmpfiles in package.provided, depclean opentmpfile and set a limit on openrc <0.23
I don't expect any problems, but given what it is, I presume that it could fail to boot. So I need to make sure my boot USB stick is still around / working. I had also planned to attempt it in a virtual environment. Mainly it's just not something I think of when I'm not busy with other stuff. Then I read something and remember, "Oh yeah, I was going to try that."

Anon-E-moose wrote:
Going forward from here, it's just play it by ear, maybe the openrc devs will quit mucking with it and things like opentmpfile, but who knows.
The "play it by ear" part is my primary concern about the effort required to "fight it." Some of this is outside of my comfort zone. I recently had to fix the openrc-0.28 ebuild because "path_exists" was no longer supported. Fortunately newer ebuilds had the correction.
_________________

Believing I had supernatural powers I slammed into a brick wall.
I said hey, is this my problem? Is this my fault?
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3869
Location: Dallas area

PostPosted: Sun Sep 30, 2018 8:53 pm    Post subject: Reply with quote

I'll try and clarify and summarize with this post.

You don't really gain anything by fighting opentmpfile, if you're running a version of >=openrc-0.23,
whether you lock openrc at a particular version, just keep up with it as new versions roll along or downgrade it's up to you.
Downgrading doesn't buy you anything other than perhaps some peace of mind about the direction of openrc, but it requires a small amount of work.


If running a version of <openrc-0.23
These things need doing:

1. put virtual/tmpfiles in package.provided OR modify virtual/tmpfiles ala Tony's post from earlier OR modify opentmpfile to allow it to be installed with <=openrc-0.23
(last choice requires removing /etc/runlevels/sysinit/tmpfiles.dev and /etc/runlevels/boot/tmpfiles.setup, as opentmpfile will put new ones down,
along with modifying opentmpfile ebuild to remove "!<sys-apps/openrc-0.23" from RDEPEND)

2. if using 1st or 2nd choice from 1, then do this "ln -s /lib/rc/sh/tmpfiles.sh /bin/tmpfiles"
(effectively you're doing the same as opentmpfile and newer packages that call tmpfiles will work as well as older ones that call tmpfiles.sh)

That's the long and short of it. Pick your poison.

Edit to add:
as with any package that's locked at a particular version, when changes come along in the future,
extra work may be necessary to make the locked package compatible.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 17862

PostPosted: Sun Sep 30, 2018 9:35 pm    Post subject: Reply with quote

Thanks for the feedback, I'll give it some thought. Maybe if things really go south, the path forward will reveal itself.
_________________

Believing I had supernatural powers I slammed into a brick wall.
I said hey, is this my problem? Is this my fault?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
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