Re: [gentoo-dev] Re: [gentoo-dev-announce] Removing profiles/use.local.desc file from CVS on 2011-02-11
On Mon, 07 Feb 2011 13:47:55 +0100 Gilles Dartiguelongue e...@gentoo.org wrote: Le dimanche 06 février 2011 à 23:52 -0600, Jeremy Olexa a écrit : As for the re-syncing all files thing - I can't reproduce that, though I've seen multiple reports. Did it settle down now? (I assume so) -Jeremy synced my laptop this morning around 11AM UTC and was hit by this mysterious resyncs whole tree problem. I'm still seeing this too on the _first_ sync on a system after the 4th of February. Subsequent syncs exhibit normal behavior and speed. It's basically a one-time-per-system thing, at least that's what I see. -- Best regards, Luca Longinotti aka chtekk. LongiTEKK Networks Admin: cht...@longitekk.com TILUG Member: cht...@tilug.ch
[gentoo-dev] Re: [gentoo-dev-announce] Removing profiles/use.local.desc file from CVS on 2011-02-11
On Fri, 04 Feb 2011 13:50:20 -0600 Jeremy Olexa darks...@gentoo.org wrote: Hello, The CVS-RSYNC service has moved hosts and now we generate the use.local.desc file via egencache. Hi, could any of this cause a (kinda) full resync from the mirrors? Because an emerge --sync I'm doing now is syncing up _all_ files in the tree and taking ages on my laptop, on the other hand the emerge --sync I did yesterday at around 1400 CET just synced the changed files, as usual... I also tried multiple mirrors, thinking maybe one of them was the problem, but they all happily continued syncing everything. At the end of the sync, Portage also processed all the update-files, which too is strange. All the modification times of the files seem to have been updated... The date on my system is set correctly, so I can't really explain why this would suddenly happen, as between yesterday and today I didn't update Portage or rsync. -- Best regards, Luca Longinotti aka chtekk. LongiTEKK Networks Admin: cht...@longitekk.com TILUG Member: cht...@tilug.ch
[gentoo-dev] net-www/apache-1* masked.
Hi all! As announced in the 30 April 2007 edition of GWN [1], net-www/apache-1* as well as all packages depending/using it were masked, pending removal on 12 June 2007. I fixed all packages, dependencies, etc. I could find to work correctly after the masking (generally removing Apache 1.X support from them). If you find any issue still, please open a bug about it, assign it to [EMAIL PROTECTED] and make it block bug #178189 [2]. If you use or plan on using the apache-module or depend.apache eclasses, be aware that the need_apache function doesn't anymore export the apache2 USE flag to IUSE, since now it directly depends on Apache 2.X, so be sure to declare it in your ebuilds IUSE (I fixed the few cases where this wasn't already done). Thanks and happy upgrading to Apache 2.X! [1] http://www.gentoo.org/news/en/gwn/20070430-newsletter.xml [2] https://bugs.gentoo.org/show_bug.cgi?id=178189 -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
Ned Ludd wrote: Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. eclass/mysql.eclass:529: eclass/mysql.eclass:530: media-libs/pdflib/pdflib-5.0.4_p1-r1.ebuild:39: media-libs/pdflib/pdflib-6.0.3-r1.ebuild:48: media-libs/pdflib/pdflib-6.0.3.ebuild:38: Fixed, thanks for the report! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unused global useflags
Piotr Jaroszyński wrote: Unused global useflags: dba - Enables dbm-compatible layers dio - Adds direct i/o support hardenedphp - include the hardened php security patch for the php group of ebuilds ingres - Adds support for Ingres database msession - Adds support for msession daemon Any reason to keep them? Not really... I've thus removed the unused PHP ones: dba, dio, hardenedphp, ingres, msession are all gone, thanks for the heads-up @ peper! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: www-misc/pglogd
Masked www-misc/pglogd for removal on 13.02.2007. Dead upstream, no release in 2 years and doesn't work with PostgreSQL 8.X releases. An alternative for the Apache webserver is mod_log_sql. -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RC_STRICT_NET_CHECKING or the net dependency
Francesco Riosa wrote: because if mysqlmanager provide mysql _now_ all the baselayout-1.13 versions will complain loudly, that's because provide mysql is commented out in the current init.d/mysqlmanager::depend() ;) Hmmm from how I understood it, basically you cannot provide something that already exists (so if there is a mysql init script, you can't provide mysql in another init-script), but you can make up some fancy name to do that? Fex: dev-db/mysql installs both /etc/init.d/mysql /etc/init.d/mysqlmanager both are able to provide some mysql server service, so with baselayout 1.13 we would just make both provide mysqld (notice the ending d), and that should work, right? -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] a new TLP to unify programming langiages?
Stuart Herbert wrote: The PHP team will be opting out. Confirmed, PHP will remain its own TLP. -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per-package default USE flags
Zac Medico wrote: Should we include support in portage for one or both types of per-package default USE flags? If support is included for IUSE defaults now, we won't be able to use them in the tree until after a waiting period or an EAPI bump [4]. Great, this will be very useful, so +1 on implementing both now from me. -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: There have been a number of developers leaving Gentoo in the past 6 months as well as a number of news stories on DistroWatch, Slashdot, LWN, and others about Gentoo's internal problems. People come and go, I still see Gentoo going forward, packages still get updated, work gets done... So I'm really beginning to think people read t much into a few people leaving over 6 months and a few, generally wrong articles based on misinterpreting someones blog... simply don't have enough developers to support the many projects that we have. Here are my ideas for fixing this problem: Maybe, maybe not... Projects exist, so there is at least _someone_ that's interested in them... If that's not true, then ok, just remove that project... Let's start the comments on the 10 points (all imho): - Cut the number of packages in half (put the removed ebuilds in community run overlays) Who decides what goes away and what now? Which criteria is used here? Btw, this is already being done splendidly by the TreeCleaners project, and Sunrise and other overlays are already absorbing stuff from the community. - Formal approval process (or at least strict criteria) for adding new packages Err what? So I, as a dev, that did quizzes, etc., cannot even anymore just add the package that has got my fancy atm, because there are some criteria to what is added and what not, and I have to go through a bureaucratic process just for that? Never! If for strict criteria you mean there must be at least a dev or herd maintaining it, or such stuff, they already exist, they may just need some more enforcing... ;) - Make every dev a member of at least 1 arch team Which doesn't mean he will ever keyword stuff stable, other than his own, which he already can... Let's face it: most devs are mainly interested in their stuff, getting their stuff keyworded, and many wouldn't anyway have the time to efficiently work on an arch-team, as members of such I mean, not just as I'm a member, so I keyword my stuff, that's it... For that I agree with the current practice: if you want that, ask the arch-team first. ;) - Double the number of developers with aggressive recruiting That's something that goes on since... forever! Gentoo's continuously recruiting new people, more aggressive recruiting has already been proposed many times, but it was always agreed to try to maintain a relatively high standard of new recruits, and if you want quality, finding loads of people who just happen to have the time and dedication to become a Gentoo dev isn't that easy. - No competing projects Kills innovation... Who comes first has total monopoly of that branch of things basically... I'd never agree to something like this, personally. - New projects must have 5 devs, a formal plan, and be approved by the council New projects do always have a plan, they wouldn't be created else... ;) Making it formal, be approved by the council... How to slow everything down? We continuously see how adding bureaucratic stuff just suffocates innovation, I totally agree with discussion et all, but not really on the need to have everything approved by someone (the council in this case)... The council may kill the project later on if it's doing totally crazy shit, but that's another thing entirely... - Devs can only belong to 5 projects at most Why? If someone has time to dedicate and work on a lot of projects, why not? - Drop all arches and Gentoo/Alt projects except Linux on amd64, ppc32/64, sparc, and x86 Uhhh is this real? How would this help at all? Hell, it would make things worse to an extent, we've already seen that at least Gentoo/BSD helped in finding problems in ebuilds using too GNUish stuff, other arches may help in finding broken code, etc.. I'd agree with some proposal to relax keywording policy for all arches you've not listed, since on those others, sadly, not soo many people are active, and you get to wait on keywords for months sometimes... This is something we should imo address from an arch-team PoV, some kind of if they don't react in time, I can drop their keyword back to unstable or entirely, or something like that, that would help many package maintainers I think. - Reduce the number of projects by eliminating the dead, weak, understaffed, and unnecessary projects Again, who's the judge of that? If there is a project with at least one person active, it means for him it's not unnecessary... What means weak project? What's unnecessary? Sure, kill the dead ones with no activity and no active members, that's easy and I agree with that, but the other, little ones, who's the one to say you're understaffed and useless, go die!? :S - Project status reports once a month for every project Totally agree on this one! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
Thomas Cort wrote: On 10/4/06, Luca Longinotti [EMAIL PROTECTED] wrote: The number of opened bugs has always been higher than the number of closed bugs in the bug stats listed in every 2006 GWN. How is this 'going forward'? It seems to me like we are falling behind. That's not an indicator you can really trust imo... A lot of those are WTF??? segfault? eh? and/or waiting on user input because they're irreproducible by the devs involved, but I agree, there are a lot of open ones because lately it seems that people tend to just go MIA, return sometimes, do 1-2 commits, then away again... This has to stop and such people have to be retired, but devrel already does that. And orphaned/broken ebuilds do get punted from the tree... TreeCleaners! Who decides what goes away and what now? Which criteria is used here? Duplicate packages (we don't need more than a few mp3 players), unpopular packages with only a few users, unmaintained packages, and broken packages. We've all seen how we don't need more than a few mp3 players when trying to remove XMMS, which is _broken_, _old_ and _dead_. :) One of Gentoo's strenghts is the it's all about choice paradigm, don't ever remove that, ever. ;) If there are people willing to maintain them, or if they are not broken and perfectly work, don't kill stuff just because you think it's duplicate/useless/unpopular. We would provide a set of packages for most things a user would want to do and then sunrise/someone else provides ebuilds for the rest. I was thinking something similar to what Ubuntu does, they provide the basics to do most things and then they have universe and multiverse repos for extra stuff. Yes, but we're a meta-distro, we do not know what the user wants to do, he just does... I myself run desktops and www-servers, mail-servers, others run embedded-apps, game-servers etc... So the whole breaking stuff up idea that's cursing atm through the blogs just doesn't cut it, and would imo in the end only increase maintainance because packages are spread out and you have to jump through loops to get them like you want. - Formal approval process (or at least strict criteria) for adding new packages Err what? I believe that we have too many packages for us to maintain. We have over 11,000 packages (over 24,000 ebuilds) and only about 175 active developers. I don't think its maintainable and I don't think adding more packages will make it any better. TreeCleaners, to an extent Security etc. _do_ remove what is dead, what has reached points of unmaintainability and brokenness that cannot be anymore supported. The rest still is there because it works (so why remove it?), or because it has someone that keeps it alive (so why remove it?). If there's something to do here, it's kicking out old, broken stuff etc. faster and improving QA (as Kevin already pointed out), definitely not making it so difficult to add new stuff that no one will, that only produces stagnation of the tree in the end. - Make every dev a member of at least 1 arch team Which doesn't mean he will ever keyword stuff stable, other than his own, which he already can... Every developer should have access to at least 1 Gentoo system. They should also be able to determine if something is stable or not. It would cut down on the number of keyword/stable bugs if developers did a lot of their own keywording. Cool... But that's exactly what the arch-teams were created against... From what I always understood arch-teams are there to have a second set of eyes for stabling and testing stuff, even if the maintainer himself can do that. Then he can stable his own stuff (just ask the arch-team permission), or not... And the arch-team may or not give permission, depends on the package in question. That's a relatively good approach that ensures a measure of peer-review at least on the important packages. - Double the number of developers with aggressive recruiting That's something that goes on since... Even when someone is found it is hard for them to find mentors. We need to improve this. I had found someone who wanted to join the sound team and I was unable to locate a mentor for him (I wasn't a dev for 6 months then, so I couldn't do it myself). I e-mailed [EMAIL PROTECTED] and only one person offered. The person who offered fell through because he didn't have enough free time. Ok, so I don't see how aggressive recruiting would improve that... Improving recruiters/mentors capacity would have to be done first, so even if we did some aggressive recruiting (which I'm not sure would bring quality... probably quantity hey cool Gentoo wants new devs, let's join cause I like Linux! w0h000!!11!), we wouldn't have the resources to sustain it. - No competing projects Kills innovation... What happened to working together? Should we work together instead of competing against each other? Sure, working together is cool, but it doesn't always work, it never always worked
Re: [gentoo-dev] Orphaned packages
Gustavo Felisberto wrote: net-ftp/pure-ftpd net-ftp/pureadmin net-ftp/proftpd I'll take those as I use them on all my systems to do FTP serving. -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Ciaran McCreesh wrote: On Thu, 24 Aug 2006 09:11:52 -0500 Lance Albertson [EMAIL PROTECTED] wrote: | I partially agree that a strong council will help the situation, but | the problem with any leadership-by-committee model is the lack of | quick decisions. Many times things come up that need a quick | resolution (when I say quick, I mean within a few days). And if you | have a committee of 7 or so people that live in several different | timezones, its extremely hard to get them together to discuss it all. Mmm, afaics there's nothing preventing the council from having quick, 'as needed' informal interim meetings with whoever happens to be around. If a few people aren't there, it's not as big a deal as if people don't show up to the monthly meetings. Heck, the monthly meetings could be considered a minimum... Indeed. I have to agree with Ciaran here, a stronger council seems to be one of the best solutions. A (benevolent) dictatorship, or the opposite of extending the democracy level even more, aren't going to solve anything imho. The dictatorship model sure doesn't motivate volunteers, and having more than one person is anyway better, as already pointed out, to not have single points of failure, or potential for quick and big damage. The opposite of a total democracy too doesn't cut it, when anyone starts having the power to put stuff to vote, make up referendums etc., things start to slow down and get caught up in endless bureaucracy (I'm swiss, it happens there, often, not that it isn't a good thing for something like a nation, but for something the size of Gentoo, and with the scope of Gentoo, it would just hurt imho). | The council has its merits, but it also has its weaknesses, this one | being one of them. I think I mentioned 6mo ago that we could keep the | council, but select one person to sort of be the operational lead | to make quick decisions so that development moves on. What happens if he or she (ok, he) isn't around? Is the flexibility of having a single on the spot decision leader enough to outweigh the disadvantages over allowing mini meetings? The ability of the council to hold arbitrary mini-meetings when needed, and eventually change the decisions at a later date (with a time limit of course, so that people can start doing work, and at the same time don't do too much work for it to then be eventually refused) if there is extreme opposition (basically if you have only 2 members around, those decides YES, and the other 5 then tell NO NO NO!) would seem the best course of action to me. Having the one council leader doesn't cut it, as Ciaran already mentioned for reasons of availability, and again we'd introduce a possible quick point-of-failure. If there is a decision that needs to be done extremely quick, just get together the council members that are there and do it, although I wouldn't expect it to be commonplace to have decisions that affect the whole of Gentoo that need to be taken in like an hour or two, at least 1-4 days of time to prepare for the decision can always be required, thus allowing the council members to be there in a reasonable amount for those mini-meetings, and if not, but if they know they want to say something, there still are proxies that can act for them. Raising the number to two co-leads can also be a solution, but what if exactly those two are away for whatever reason, but the other 5 are around? Now do they have to wait on one of the aforementioned two people to do anything? That still is a possible point-of-failure, which the other model (who is there decides, who is not does not) would solve relatively well. -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites for dev-db/xmysqladmin
dev-db/xmysqladmin has no herd or maintainer, upstream hasn't made a release since 2001, and it has an open security bug [1]. It's already package.masked since about a year because of the security bug, so the removal is long overdue, and I will proceed with it in a month. An alternative, more powerful and modern GUI tool to administer MySQL databases is dev-db/mysql-administrator. [1] https://bugs.gentoo.org/show_bug.cgi?id=93792 -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Einput eclass
John Jawed wrote: Below is a link to an enhanced input eclass as well as a screenshot. This eclass was made to simplify interacting with the user at pkg_config(). This is a good idea imo, it could really simplify and help with pkg_config stuff, think of dev-db/mysql or others who need to ask questions, passwords etc., this would help doing that in a simple, standardized way. Maintainance is no problem, I'm willing to put this eclass in the tree and maintain it myself for now, and when John will become a full Gentoo dev (this is already scheduled, he'll help out on PostgreSQL related stuff in the near future), he can take it over directy... Any objections to this wandering into the tree? Suggestions, ideas? Thanks! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] SLOTed MySQL or not?
Ramon van Alteren wrote: No dev but +1 from me. I liked slotted mysql a lot and use it extensively. It has helped us tremendously during our upgrade path and I would be very sad to see it go. Public opinion is just that, public opinion, doesn't neccesarily mean something went wrong. FWIW, I'd like to keep the slotted mysql ebuilds. If they are removed from the tree I'll re-add them to our local frozen tree for our company. We're not a hosting company BTW, we just run lots of mysql daemons ;-) Ramon Slotted MySQL will definitely go away from the main Portage tree, there only the normal MySQL ebuilds will remain. Atm we're setting up an overlay for MySQL, so there you'll still be able to download the slotted ebuilds and eventually if someone's intersted he can maintain them/bring them to a usable, better state or whatever, but we (MySQL Herd) won't do that at the moment and will only maintain and provide non-slotted MySQL ebuilds. -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[gentoo-dev] SLOTed MySQL or not?
As the title says, what would you prefer for the future of MySQL in Gentoo? Please take a moment to read https://forums.gentoo.org/viewtopic-t-438557.html and vote (and eventually comment on it). Thanks! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[gentoo-dev] SLOTed MySQL or not?
As the title says, what would you prefer for the future of MySQL in Gentoo? Please take a moment to read https://forums.gentoo.org/viewtopic-t-438557.html and vote (and eventually comment on it). Thanks! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[gentoo-dev] Meeting summary: PHP Herd, January 2006
Hi, The minutes of the PHP Herd's January meeting are now available [1], including a full log [2] if anyone needs it. We elected herd leads, agreed on how to deal with the old-style PHP packages and discussed a number of ideas like SLOTing of PHP minor version and some eclass changes, amongst other things. The next meeting will be on Tuesday 7th Febrary 2006 at 19:00 UTC in #gentoo-php on irc.freenode.net. All are welcome. If anyone has a topic they'd like to see on the agenda [3], please let a member of the PHP herd know before the meeting. [1] http://tinyurl.com/cc964 [2] http://tinyurl.com/bg3a3 [3] http://tinyurl.com/7gqn3 -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.
Francesco R. wrote: mysql-4.1.14 has been added to the tree on 29 Aug 2005, should be time to stabilize the 4.1 branch of mysql. ARCH teams, robbat2, php-herd, thoughts ? If no one is versus I'll stabilize 4.1.14 for x86 and amd64 tomorrow (with dev-perl/DBD-mysql-2.9007), then mysql-5.0 will be unmasked. Furter note to the sh ARCH, my apologies, I've removed your keyword from mysql-4.0.[456]* ebuilds, repoman commit gived me a badindev for dev-perl/DBI. Best regards, Francesco Riosa PHP Herd is perfectly ok with it and we're eagerly awaiting a stable MySQL 4.1! :) So, from us, full ok and proceed without doubts (about PHP). -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] MaxDev Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
