Re: [aur-general] AUR Best Practice for New Package Upload
On jeu, 2014-09-18 at 11:26 -0700, stef wrote: On Tue, 9/16/14, Nuno Araujo nuno.ara...@russo79.com wrote: Subject: Re: [aur-general] AUR Best Practice for New Package Upload To: aur-general@archlinux.org Date: Tuesday, September 16, 2014, 1:42 PM Try to study it and feel free to ask any questions you want about it. -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com = @nuno @list So, I have studied the PKGBUILD and install file. I have some questions, a few of which might be really newb-type but please bear with me. All is clear in your PKGBUILD: and it was certainly helpful to see how you went about it; clean and simple. 1) Questions regarding the variables $pkgdir and $srcdir . My understanding: these 2 babies are directories created by makepkg during the fetch source, configure, build and install to fakeroot process. $srcdir is where makepkg stores all source files downloaded. $pkgdir is where the build/compiled files are then stored in the fakeroot environment which gets compressed into the final .pkg.tar.xz file. THAT .tar.xz file is a compressed archive which contains the directory structure and installed files which pacman will then extract to user's root system. a) Did i get this right? More or less, the source files are into $SRCDEST, which defaults to the current directory. (you should take a look at makepkg.conf man page). $srcdir is a folder where the source files are uncompressed (or symlinked). As for $pkgdir, you are right. It should be noted that besides the built/compiled files, the .install files as well as a .PKGINFO file providing the package metadata is also in that directory. b) what happens to $srcdir and $pkgdir ? I imagine those are just 'temp' dirs which makepkg deletes when it's done compressing the fakeroot? makepkg doesn't delete them. It's your work. 2) in the PKGBUILD, you are dropping the data/ directory and installing both .svg and .glade files to /usr/share/masshash-launcher/ In python3/ masshash-launcher: L31 #path to glade ui file L32 glade_source_dir = '../data/masshash-launcher.glade' L33 if os.path.isfile(glade_source_dir): L34 glade = glade_source_dir L35 else: L36 glade = '/usr/share/masshash-launcher/masshash-launcher.glade' So you're using L36 as opposed to 32. This is your preference? Or for the sake of simplicity? So as not to create an additional dir data as unnecessary? (Sorry not trying to be anal but only to understand.) Neither. If you give it a look, you'll see that L32 refers to a relative path. This is usually used when developing a program. While coding, you would like to access your work version of the files. This allows work to be done on a development version of the program without affecting the one installed on your system. 3) You are copying the svg file to /usr/share/icons/hicolor/scalable/apps/ Then you are using the install file to update the gtk icon cache--which I didn't even think of and makes a lot of sense. Why the hicolor though? Your choice? Because it is the most basic/core GTK icon theme? Sorry, but this is all a bit new to me. If you give a look at the contents of the hicolor-icon-theme package, you will see that it has no icons by itself. Only a standard set of directories where icons should to be stored and a index file describing these directories. Having this theme installed ensure that you can call gtk-update-icon-cache without issues. This theme is usually the standard place to store your application icons (at least in a XDG compatible desktop). 4) Not important; for the CLI program, the category I would use to upload to AUR would be system but since we also have the GUI, (which would be what X11?), which category would you recommend when uploading to AUR? X11? My personal opinion: I don't care about AUR categories. But if I had to choose between both, I would pick system. 5) @nuno : Do you want to be listed as contributor? Would only be (more than) fair (eeer...) but might be a bit of a PITA for youJust let me know. Don't care. Seing the time and effort you're putting to study a single and simple PKGBUILD, you deserve to take all the credit for it. Thanks. As a generic advice, take the time to read the man pages of Arch Linux build system utilities and configuration files (e.g. man PKGBUILD, man makepkg, man pacman, man pacman.conf, and so on...). Also read other AUR PKGBUILDs (or even better, the one published in core and extra repositories). There you would have find answers for some of the questions you asked. -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] AUR Best Practice for New Package Upload
To be clear, this program, for which I am trying to build my first AUR PKGBUILD (bear with me please, still learning) is NOT a python package or library. So perhaps a setup.py may not necessarily be needed or relevant in this case. (I could be wrong.) There is no obligation to have a setup.py. Usually, when it is provided by upstream, it is used to ease the installation process. Right now, personally, on my box, I have the package as so (I just downloaded it since it is self-contained, there is nothing to build; and am just running it from there): [...] This is not the best approach. Usually /opt is used for *large* self-contained packages. *The program is self-contained.* In each of /opt/MassHash/python2/ and /opt/MassHash/python3/ there are 2 executables: masshash for the CLI and masshash-launcher to launch the program with the GTK+ GUI. Since it's an application and not a library, one should only install the python3 version of the scripts, since this is the default version of python in ArchLinux now. So looking at https://wiki.archlinux.org/index.php/Python_Package_Guidelines I am not sure this applies here. And looking at https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Directories one idea would be to install as such: /usr/share/program/ /usr/share/program/data/ /usr/share/masshash/data/masshash-launcher.glade /usr/share/masshash/data/masshash-launcher.svg /usr/share/masshash/python3/ /usr/share/masshash/python3/masshash /usr/share/masshash/python3/masshash-launcher /usr/share/doc/ /usr/share/doc/masshash/AUTHORS /usr/share/doc/masshash/COPYING /usr/share/doc/masshash/README.md Then the PKGBUILD script creates another script or symlink which is placed in /usr/bin You're not far from truth. I would install masshash and masshash-launcher directly in in /usr/bin. No need for the symlinks. I wouldn't install the README.md and the AUTHORS file. Usually, those files belong to the source archive and are not deployed. However, you can as well put them in /usr/share/doc/masshash if you like. I would also add a .desktop file to allow the mashhash-launcher to be run from your desktop environment without having to open a terminal for it. And finally, I would create a split package for this application. One for the console application only and one for the GUI. Would either /opt or /usr/share as above work or do you guys confirm that, according to AUR packaging standards it should have a setup.py ? (Johannes has already told me not to use /opt but I had not given the full data previously. Johannes, based on the additional info given here, feel free to confirm your earlier recommendation; or change it, as the case may be.) No /opt for your package ;) Guys, please also, let me know if the AUR forum might be better suited for this discussion and if so, I will move it there. Thanks a lot for your feedback and patience. For the exercice, I packaged the application, and you can find the result here [1] (in the masshash directory). Feel free to inspire yourself, or simply to take it as it is if you wish. Try to study it and feel free to ask any questions you want about it. [1] https://cloud.russo79.com/public.php?service=filest=f00d660f9ae6001dd09276e960a02e9d -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] AUR Best Practice for New Package Upload
On mar, 2014-09-16 at 05:56 -0700, stef wrote: Nuno, Thanks a lot for helpful feedback. I was kind of hoping no one would write a PKGBUILD for this so I would not be tempted to use a shortcut and cheat but hey ;) I will use your PKGBUILD and files as a model, really make sure I understand them fully, make any modifications as desired and post here final result (if different from yours.) I may have some questions and will post here if any. Thanks. I don't think that giving a look at existing PKGBUILDs is cheating. Referring to examples is a very good way of learning. As long was you try to understand what's done and not just blindly do some copy and paste. Feel free to post your questions here. -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] AUR Best Practice for New Package Upload
Some suggestions for your PKGBUILD: - You could use $pkgver inside sources=() so you don't always have to adjust the version number in two places. - You should really quote $pkgdir and $srcdir properly: http://mywiki.wooledge.org/Quotes Your PKGBUILD will break when someone uses it inside a path with spaces in it. Yeah, I wrote it a bit quickly, and didn't took the time to re-read myself. ;) I uploaded a new version with these issues fixed, just so that stef has a good example to refer to. Thanks for the comments. -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] AUR Best Practice for New Package Upload
On mer, 2014-09-10 at 04:17 -0700, stef wrote: Lastly, what about splitting CLI only package from GUI? Can I make only one package or is it advisable to dp one package for each? This would result in the actual program (CLI) in one package and the GUI on top of it in a different package. It's more work to maintain 2 packages so is it necessary or advisable or can I stick to a single package? Well, you can make a split package. This way you only have a PKGBUILD to maintain. AUR now supports them by default so I see no major issues here. The rule of thumb that I tend to apply now is: Write a single PKGBUILD per downloaded file. Make it a split package if necessary. -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] AUR Best Practice for New Package Upload
On mer, 2014-09-10 at 08:58 -0700, stef wrote: Nuno, sorry but I'm lost here. To me a split package is 2 separate packages, one for the CLI and another one for the GUI. The GUI will only include the GUI itself (GTK+) obviously and not the actual program which will be listed as a dependency. So, does that not imply 2 separate PKGBUILD's and 2 separate packages? One for CLI and one for GUI? No, for quite some time now now create multiple packages from a single PKGBUILD. Take a look at [1] for an example of a single PKGBUILD that creates a package both for python2 and python3 for instance. Another a bit more complex example can be found at [2]. Sorry but I'm obviously missing something. I looked at wiki AUR packaging standard but not finding what you are referring to. You are referring to a single PKGBUILD. Can you please explain or refer me to proper wiki section? As for documenting split packages, just take a look at the PKGBUILD man page [3]. :) [1] https://aur.archlinux.org/packages/py/python-pyside/PKGBUILD [2] https://aur.archlinux.org/packages/ap/apparmor/PKGBUILD [3] https://www.archlinux.org/pacman/PKGBUILD.5.html#_package_splitting -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] AUR Best Practice for New Package Upload
On sam, 2014-09-06 at 13:03 +0200, Johannes Löthberg wrote: On 06 Sep 2014, at 12:06, stef stef_...@yahoo.com wrote: 1) the main script which is CLI (available for python2 and/or python3) 2) a GTK+ GUI (optional) for python2 3) the GTK+ GUI (optional) for python3 I use the GTK+GUI for python3 on my box but perhaps some users might want (or have to) use python2. Question 1): The program is small (approx 250kb only) and my tendency would be to just do the one package with all 3 components which users will then use as they see fit, CLI only or GUI, etc. This would allow me to maintain only one package for this program. Is only one package OK with the AUR community? You shouldn’t mix python2 and 3. Make it a split package. Do you really need to build both the python2 and python3 versions? If it is just an application (and not a library), I would recommend to build just the python3 version. -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] Removal request
Hi Could a TU please remove glade3-gtk2 [1]? It's a duplicate of glade-gtk2 [2]. Both packages were orphaned and I took ownership and updated the glade-gtk2 [2] to the latest release. Thank you [1] https://aur.archlinux.org/packages/glade3-gtk2/ [2] https://aur.archlinux.org/packages/glade-gtk2/ -- Nuno Araujo nuno.ara...@russo79.com http://www.russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] Package deletion request
Please delete subvein [1]. It has been renamed upstream to mutantfactions [2]. Thank you [1] https://aur.archlinux.org/packages/subvein/ [2] https://aur.archlinux.org/packages/mutantfactions/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] Merge request
Hi Can you please merge python2-virtkey [1] into python-virtkey [2]? python-virtkey is now a split package that builds binaries both for python2 and python3. Thank you [1] https://aur.archlinux.org/packages/python2-virtkey/ [2] https://aur.archlinux.org/packages/python-virtkey/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] REMOVE: git-bzr-ng-penangtom
Hi Please remove git-bzr-ng-penangtom [1]. The kermie branch packaged by csgeek at http://aur.archlinux.org/packages.php?ID=41669 integrates the same fixes and is better maintained. Thank you. [1] https://aur.archlinux.org/packages/git-bzr-ng-penangtom/ -- Nuno Araujo nuno.ara...@russo79.com
[aur-general] Merge request
Hello Could you please merge the following packages: https://aur.archlinux.org/packages/gnome15-gnome-shell/ https://aur.archlinux.org/packages/gnome15-plugin-impulse15/ https://aur.archlinux.org/packages/gnome15-plugins/ https://aur.archlinux.org/packages/python2-pylibg19/ into: https://aur.archlinux.org/packages/gnome15/ Gnome15 source code has been through a major reorganization and now integrates the packages to merge. Thanks -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] Merge request
Hi Could you please merge arnold-pulseaudio [1] into arnold [2] ? The maintainer of arnold has now enabled pulseaudio support into it's PKGBUILD so mine (arnold-pulseaudio) is now unnecessary. Thanks [1] https://aur.archlinux.org/packages/arnold-pulseaudio/ [2] https://aur.archlinux.org/packages/arnold/ -- Nuno Araujo nuno.ara...@russo79.com
[aur-general] Merge request
Hi Could you please merge pyusb [1] into python2-pyusb [2] ? [1] https://aur.archlinux.org/packages/pyusb/ [2] https://aur.archlinux.org/packages/python2-pyusb/ Thank you -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] Merge request
Hello Could you please merge gnome15-impulse15 [1] into gnome15-plugin-impulse15 [2] ? The package was renamed to be consistent with the other plugins in the gnome15-plugins package. Thanks [1] https://aur.archlinux.org/packages/gnome15-impulse15/ [2] https://aur.archlinux.org/packages/gnome15-plugin-impulse15/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] Disown request
Could you please disown pyusb [1]. I get a Undelivered Mail Returned to Sender when trying to contact the maintainer. It seems its email is no longer valid. Thanks [1] https://aur.archlinux.org/packages/pyusb/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] Disown request
On ven, 2013-04-05 at 20:05 +, Xyne wrote: Nuno Araujo wrote: Could you please disown pyusb [1]. [1] https://aur.archlinux.org/packages/pyusb/ done Is there a race taking place to see who takes ownership of the recently disowned packages or to see who has the most packages maintained in AUR? Less than one hour after the package was disowned, ownership was taken by user luolimao. This user has over 200 packages on AUR! However the fix that I need to see applied to the package was still not applied. I don't care who maintains the package (less work for me if it's someone else), but when someone takes ownership of a given package that needs some work I expect that he has already prepared what needs to be done locally. Could we change the behavior of the disown requests to give ownership to the user who makes the request? Regards -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] Deletion request
Could you please remove the following packages: [1]https://aur.archlinux.org/packages/bzr-fastimport-deleted-entries-fix/ [2]https://aur.archlinux.org/packages/python2-fastimport-bzr/ [1] applied a patch that is now available upstream. [2] is a source control version of python2-fastimport which was necessary for building [1]. Thanks -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
[aur-general] Software packaging - Security question
Hi
I am trying to create a package for the subvein[1] game.
Installation instructions[2] of the game tell to simply uncompress the
tar.gz archive in a folder and run the Subvein program.
No problem with that. But then when running the game, it tries to store
information in it's data folder (logs, configuration, user
profiles...). We have a permission problem.
To workaround this problem, I:
- Create a group named subvein;
- set the setgid bit for the game data folder and all it's sub-folders;
- set the game data folder and all it's content group writable;
- set the group of the game data folder to the subvein group.
- Created a wrapper bash script that changes the umask to 002 and then
launches the game.
This way, all the contents created by the game will belong to the
subvein group and will be group writable, so that anyone can use the game.
Is this a valid way of doing it? Are there any security concerns I need
to take into account?
The game has also a server part. I still didn't started to handle this
in the package, but was thinking to do the following:
- Create a user names subvein that belongs only to the subvein group.
- Create a systemd .service file that runs the server program as the
subvein user.
Does this seems OK as approach?
Thank you for your help.
P.S. You can find my draft of the PKGBUILD, the install script and the
bash wrapper attached.
[1] http://subvein.net/
[2] http://subvein.net/download.php
--
Nuno Araujo nuno.ara...@russo79.com
#! /bin/sh
cd /opt/subvein
umask 002
./Subvein
post_install() {
if [ ! `grep subvein /etc/group` ]; then
groupadd subvein /dev/null;
fi
chgrp -R subvein /opt/subvein/data
echoAdd yourself to the subvein group to run the game.
}
post_upgrade() {
post_install
}
pre_remove() {
groupdel subvein /dev/null
}
# Maintainer: Nuno Araujo nuno.ara...@russo79.com
pkgname=subvein
pkgver=0.73
pkgrel=1
pkgdesc=Free multiplayer action game
arch=('i686' 'x86_64')
url=http://subvein.net;
license=('GPL')
depends=()
if [[ $CARCH == x86_64 ]]; then
depends+=('lib32-glu' 'lib32-libxrandr' 'lib32-libgl' 'lib32-openal'
'lib32-freealut')
else
depends+=('glu' 'libxrandr' 'libgl' 'openal' 'freealut')
fi
optdepends=()
install=subvein.install
source=(http://subvein.net/downloads/Subvein0730.tar.gz;
subvein)
md5sums=('76845fa4502363c02362954a6ae6c6c6'
'f0741d0f778acb0ef2422c51b2a0e587')
package() {
mkdir -p $pkgdir/opt/subvein
cp -r $srcdir/Subvein/. $pkgdir/opt/subvein
rm -rf $pkgdir/opt/subvein/lib
chmod -R g+w $pkgdir/opt/subvein
find $pkgdir/opt/subvein/ -type d -exec chmod g+s {} \;
install -m 755 -D $srcdir/subvein $pkgdir/usr/bin/subvein
}
# vim:set ts=2 sw=2 et:
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] Software packaging - Security question
On 10. 01. 13 11:43, Felix Yan wrote: This way, all the contents created by the game will belong to the subvein group and will be group writable, so that anyone can use the game. Is this a valid way of doing it? Are there any security concerns I need to take into account? In a multi-user environment this would fail, so the game save _should_ be kept under $HOME. Don't know if there's a good way to do it, though, maybe someone else could help with this. When you say this would fail in a multi-user environment, do you refer to some technical issue or it's just because (and I agree with you), things shouldn't be this way? The game has also a server part. I still didn't started to handle this in the package, but was thinking to do the following: - Create a user names subvein that belongs only to the subvein group. - Create a systemd .service file that runs the server program as the subvein user. Does this seems OK as approach? I think this part is OK and nice :) Great, thanks :-) -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: OpenPGP digital signature
Re: [aur-general] Software packaging - Security question
On 10. 01. 13 12:25, Lukas Jirkovsky wrote: I think UnionFs can be used for this. I never actually tried it, but it should allow you to mount the data directory read only and then mount a RW directory from $HOME on top of, so all changes will be stored in the home directory. Thanks Lukas! I just tried it (manually, not yet packaged? and it works perfectly! :-) It bothers me to have to add a dependency on an fully unrelated package, but I think this is cleaner and safer than my previous solution. The only concern that I have with this approach, it's when the package gets upgraded. subvein seems to update some of it's own packaged files (at least translation files) when running. If suddenly, there is a new version of the modified files when upgrading, they won't be taken into account, since the priority will be given to those in the user $HOME. Well, I can display a warning message when upgrading the package, so that the user removes the files in it's $HOME folder. After all, this is Arch Linux, a distribution who targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system. :-) Thank you for your help everyone! -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: OpenPGP digital signature
Re: [aur-general] Merge request pylibg19 - python2-pylibg19
On 01. 01. 13 03:24, Sébastien Luttringer wrote: On Mon, Dec 31, 2012 at 6:36 PM, Nuno Araujo nuno.ara...@russo79.com wrote: Hi Could you please merge pylibg19 [1] into python2-pylibg19 [2]? Done. However, python-imaging doesn't exists. Fixed, thanks for the info. -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: OpenPGP digital signature
[aur-general] Merge request pylibg19 - python2-pylibg19
Hi Could you please merge pylibg19 [1] into python2-pylibg19 [2]? Thank you and happy new year! [1]https://aur.archlinux.org/packages/pylibg19/ [2]https://aur.archlinux.org/packages/python2-pylibg19/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: OpenPGP digital signature
[aur-general] Package removal
Hello Could you please remove the gnome-shell-theme-gnomeorg[1] package. It is no longer compatible with the current versions of gnome-shell. [1] https://aur.archlinux.org/packages/gnome-shell-theme-gnomeorg/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: OpenPGP digital signature
[aur-general] Removal request
Could you please delete python2-uinput0.5[1] and g19d[2]. These packages are now obsolete. Thank you. [1] https://aur.archlinux.org/packages/python2-uinput0.5/ [2] https://aur.archlinux.org/packages/g19d/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: OpenPGP digital signature
[aur-general] removal request
Hello Could you please remove the following obsolete packages? - gimp-plugin-file-ora-git[1] - bzr-fastimport-russo79-bzr[2] Thank you. [1]https://aur.archlinux.org/packages/gimp-plugin-file-ora-git/ [2]https://aur.archlinux.org/packages/bzr-fastimport-russo79-bzr/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: OpenPGP digital signature
Re: [aur-general] Package removal request
On 19. 08. 12 00:59, Evangelos Foutras wrote: On Sun, Aug 19, 2012 at 1:50 AM, Nuno Araujo nuno.ara...@russo79.com wrote: Hello Me again, sorry... Could you remove the following packages? gnome15-gnome-plugins (https://aur.archlinux.org/packages.php?ID=47363) gnome15-panel-applet (https://aur.archlinux.org/packages.php?ID=47362) gnome15-systemtray (https://aur.archlinux.org/packages.php?ID=47361) Those packages are obsolete (gnome15-panel-applet) or were integrated into existing packages (gnome15-gnome-plugins and gnome15-systemtray). Done, thanks. It seems that the gnome15-systemtray (https://aur.archlinux.org/packages.php?ID=47361) package was not removed. Could you please remove it? Thanks -- Nuno Araujo nuno.ara...@russo79.com
[aur-general] Package removal request
Hi Could you remove the following packages: roccat (https://aur.archlinux.org/packages.php?ID=41347) kone (https://aur.archlinux.org/packages.php?ID=41349) koneplus (https://aur.archlinux.org/packages.php?ID=44946) pyra (https://aur.archlinux.org/packages.php?ID=41348) All those packages were replaced upstream by roccat-tools (https://aur.archlinux.org/packages.php?ID=57300). Thank you -- Nuno Araujo nuno.ara...@russo79.com
[aur-general] Package removal request
Hello Me again, sorry... Could you remove the following packages? gnome15-gnome-plugins (https://aur.archlinux.org/packages.php?ID=47363) gnome15-panel-applet (https://aur.archlinux.org/packages.php?ID=47362) gnome15-systemtray (https://aur.archlinux.org/packages.php?ID=47361) Those packages are obsolete (gnome15-panel-applet) or were integrated into existing packages (gnome15-gnome-plugins and gnome15-systemtray). You can check AUR comments for more information. Thank you once again! -- Nuno Araujo nuno.ara...@russo79.com
