*** dcmwai has joined #gnuenterprise *** ncjp has quit IRC *** btami has joined #gnuenterprise good morning *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise *** johannesV has joined #gnuenterprise *** sjc has joined #gnuenterprise good morning *** reinhard has joined #gnuenterprise good morning all hi reinhard i'm just reading through data.py ... hi reinhard, johannesV johannesV: if you have a little time, please don't forget yesterday problem reported by kilo in INV_grid.gfd, line 135, that code works perfect. i increase a counter, commit it and print a report, and the report shows the increased number but in INV_Head, line 256, does not do the same... ok, i'll have a look thx have to setup a new invoice-db first in a nutshell caling report from INV_grid is ok, but from INV_head not OK btami, ist that setup-db.sh in gnue-invoice/scripts up to date ? yes ok, but GNUEDIR is still wrong ... (i don't have a /home/gabor/SVN/gnue ...) yes you have to change it ofcourse until we have no gnue-packages setup, but want to use modules from base, finance, etc. we have to tell where it is ok, i now have an appserver up and running with gnue-invoice what am i supposed to do now ? run INV_grid.gfd produce a new invoice *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise after clicking OK in INV_Head.gfd we got no invoice report got an empty so i need to run INV_Head first ? but if you click then on "print" in the main form (INV_grid) it's ok no "New" calls it FilterError: Unable to find a filter definition for GNUe:Reports:Char:text if i run INV_Head.gfd and press OK ah, you have to update report-filters.conf (after filling out all that fields grr) from sample... how do i do this ? ah i see ok, i can press print in INV_grid.gfd and get a dump to stdout showing some kind of a report ... it seems to me that "invNumber = blkHead.fldNumber.get()" doesn't work in INV_Head.gfd how to produce the error in INV_Head.gfd ? pressing Ok ? but the same works in INV_grid yes i see an error in that trigger-code right away range cannot handle strings ! will change this to continue ... oh hmm i do not get an error now, but there's no report too .. but the get() problem is before the range problem i'v put a "print invNumber" line, and it prints nothing i mean after "invNumber = blkHead.fldNumber.get()" it's working fine for me but: blkSeller.fldNumPrint is empty ! shouldn't this be blkHead instead ?! blkHead.fldPrinted ? yep great now it's printing my reports :) shall i post the fixed INV_Head ? sure thx good morning hi dimas hi dimas btami, please svn-up and try again * johannesV is now again lookin at dirty reads ... hello johannesV, btami johannesV: i think i'd take you to the forest blkSeller.fldNumPrint was the *good* field, just contained wrong data *** dcmwai has quit IRC it tells how much copy had to printed form one invoice *** TSCHAK2 has quit IRC the original problem remaining :( btami but the get() problem is before the range problem btami i'v put a "print invNumber" line, and it prints nothing btami i mean after "invNumber = blkHead.fldNumber.get()" *** TSCHAK2 has joined #gnuenterprise have to go now bbl *** btami has quit IRC *** dcmwai has joined #gnuenterprise *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise for the logs: btami/kilo i've found the bug you've told about *** kilo has joined #gnuenterprise good morning hi kilo still looking for a solution to your INV_number problem hi johannesV, btami just debriefing... *** dcmwai has quit IRC kilo: your problem is as following: the invoice-number generated in OnValidate of the INV_Head class is not automatically updated in the blkHead (INV_Head.gfd) even if you do a manual 'blkHead.update ()' it's not updated (which i don't know why atm) in INV_grid.gfd it is working, because after calling the form 'INV_Head.gfd' you do a 'createResultSet ()' which completely reloads the client-side cache (block) and therefore get's the newly created invoice-number i've checked this case with 'sample.gfd' showing up this error while it is a common problem at all to 'invalidate' the *complete* client-cache after a commit has happend we cannot do a quick fix though: what if a OnValidate creates a bunch of new records in a completely different class ? meanwhile doing a "block.update ()" should do the trick (for at least the currently loaded records) this is the case for sample.gfd *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise hmm there's something strange with the list of properties beeing 'reloaded' by appserver's db-driver ... maybe this is a master-/detail-problem will look at it closer in the afternoon kilo: found a workaround which is doing the job, but all that questions still remaining ... really off for lunch now reading the logs. you two wrecked my dear little code gem??? 8-)) *** lekma has joined #gnuenterprise morning everyone hi lekma hello lekma johannesV is already working on the dirty reads as you are someone with quite deep insight into appserver and probably it's heaviest user, I'd like to get your feedback on the strategy actually i'm hunting a bug in our db-driver i think reinhard: sorry i was away what is your strategy for dirty reads ? brb what is blocking us is two things johannesV: commit r190 was bogus commit, should i revert it? first: being able to find objects that are not yet commited kilo, if you like you can (i did so) or are you working on it? second: read properties from an object that is not yet commited antd even though they seem likely, they are not i'm still debuging first case is session.find "linked" second case, for example, is a property change that triggers an OnChange which will itself change another property brb this will also trigger an OnChange but, the first property changed is not available to the second OnChange * lekma thinks he's not very clear lekma: i think i understand lekma: the actual change will only happen when the OnChange has finished so if one OnChange triggers another OnChange, the actual change of the first OnChange hasn't happened yet yep that's it this way the second OnChange could for example raise an exception that would prvent both changes to happen (I think) but yeah, I get it in fact that's what we do lekma: is that also a show stopper for you? but we need the first value to raise the error kinda it would be much easier you could in the first OnChange catch the exception and raise another one with a solution however, actually I wanted to talk about the dirty reads (find) currently we see 2 possibilities to implement it (a) after appserver has queried the database, mix all cached dirty records (that are not yet sent to the backend) into the result set, re-test all conditions and re-sort "manually" in appserver re-test conditions because newly created records can or can not match the query condition also a record that did initially match the query condition could have been changed (but uncommitted) meanwhile to not match it any more and as well for the other way around re-sort because uncommitted changes could have happened on sort fields (b) *before* any query to the database, send all pending changes to the db backend but don't commit yet so the backend will always be up to date on any query drawback of (a) is we more or less reimplement a complete db engine within appserver drawback of (b) is the post of the pending changes to the db might affect other sessions (users) for db backends that don't support transaction isolation what do you think? frances (who's following the thread) tells me (b) is the "standard" way of doing this in others db dependant apps oh say hello from me :-) (b) is also what we're following now I think *both* ways might have major performance impact in certain situations but she also says that you should disallow the availability of changes to other sessions i would "vote" for (a) we are the knights who say 'b' gut feeling here: (a) relies less on db backend, so to me it's more reliable and will behave in a kind of always similar way whatever db you choose I think we might investigate how different db's support transaction isolation and base our decision on that another drawback for (a) I didn't mention yet is it might take *way* longer to implement i thought about this hmmm, i think noone should build appserver on csv-files 8-))) :)) frances here: reinhard, I think you can only choose b) if you can guarantee transaction isolation or solve this issue, otherwise this is no option s/you can guarantee/we can guarantee well, for db's that don't support transaction isolation, appserver doesn't guarantee it now, either for example if you have a find() in a procedure that find() might read data that was committed by another session after the current transaction has started so two identical find's in a transaction might yield two different results *if* the db doens't properly isolate transaction transactions frances here: ok, I didn't realize that frances here: but the way the app server works now, we have no this problem frances here: because it is only written to the database at the moment of commit frances here: so nobody else can access not committed data frances here: correct? yes i understand transaction isolation in 2 ways a) nobody except me can read my uncommitted data b) within a given transaction, two subsequent identical queries return the same result (except for my own changes) currently, a) is always made sure and b) depends on the db frances here: yes, me also the change option (b) would also break a) if the db doesn't support it btw: you can just do "/nick frances" :-) frances here: that is exactly my worry ok I share your worry :) I propose we investigate transaction capabilities of the db's we support before we finally decide just to give you a feeling about time frame too much dbs supported :) if we go (a) (reimplement condition check and sorting in appserver) we are probably talking about weeks aaarrrghhh :) reinhard: if you can delegate a problem, delegate it. just like yesterday's thoughts about cron and appserver lekma: is there a "must have it by" date for you? kilo: correct. So we have to find out whether we *can* delegate yes well the sooner the better, it's hard to say, cause we don't help much in the coding, so it's a bit embarrassing to ask for a feature but to be honest we need it for the day before yesterday we are so overwhelmed by coding/making gcds/ calc properties/rtesting that we cannot step back and think about how it "could" be for us it is the way it is and we try to finish the project as soon as possible (the customer needs to take orders from its customers) and there's not even a workaround for your problem? and we stumble on something that is to difficult to solve, we turn to you :) we didn't find one are there several places where you would need dirty reads, or is it a single special case? no now we need it "everywhere" at least in each and every "document" creation (order/ picking list/pod orders...) s/pod orders/prod orders can you explain a bit? (maybe I can find a workaround) bbl 10 min example: after confirmation of the picking list, the status of the sales order is changed the change of the sales order is done by an 'on change' in this on change I read the positions to check, whether the change is correct but the change of positions were also done just before in the same transactions so the program raises an error these checks are important, because there are multiple occasions, where the status is changed, either by another program or by an user interface Result: I do a pass instead of a raise error now, everytime that I have a problem but that means that the customer can create data combinations, which are wrong, so data integrity is not guaranteed by the ERP at the moment bbl * lekma is away: feeding the cat... kilo, are you there ? aye i have a workaround for you making INV_Head.gfd work * kilo interested ok then add a field "fldGnueid" to the blkHead pointing to 'gnue_id' in the saveAll trigger add the line: "dts.createResultSet ({'gnue_id': blkHead.fldGnueid})" just before: invNumber = blkHead.fldNumber.get () this way you force the blkHead to be really reloaded and fldNumber has the valid number i'm still curious why this isn't the case doing a 'blkHead.update ()' which should do the same trick ... ??? it is as good as spilling a black cock's blood at midnight right next to a crossroad... what should commit do? and what should update do? * kilo confused anyway, i don't know why the rpc-call "load" for blkHead has an empty porperty-list after the commit well, commit post's all changes from forms and executes OnValidate triggers all changes done by the OnValidate trigger are *not* communicated back to forms calling a 'block.update ()' you force it's datasource to do a post () and an updateFields () which actually reloads all field-values, in other words it re-invalidates the client-side cache so, doing a blkHead.update () should retrieve the newly set invoice-number but, as i've mentioned before, the rpc-load sent to the appserver does not have any 'fieldnames' specified ... johannesV: looks like a bug to e me bug? yes, i think so too but i cannot find out where it is created ... i know: it is created somewhere in gnue code 8-))) johannesV: looking at __updateFields maybe it's a prob with the case of fieldnames either self._field is empty no, it's not empty self._fields of course it only holds 'gnue_id' or the isFieldBound fails self._fields only holds gnue_id? checking ... (self._fields, not propertylist!) think i got it seems like we had just about the same idea ... *lol* isFieldBound fails? case problem? yes, case problem self._fields has all fields in lower case hmm ok, fixed it *** ra3vat has joined #gnuenterprise anybody could give me exact versions of python and pw_xmlrpc you have on sarge? i'm still suffering with non-latin commit johannesV, and i set up appserver sample.gfd ra3vat: we all work with python 2.3 2.3.4 to be precise ds@latitude:~$ python Python 2.3.3 (#2, Feb 24 2004, 09:29:20) [GCC 3.3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib >>> xmlrpclib.__version__ '1.0.1' >>> reinhard, you have the same version of xmlrpclib? or johannesV * lekma is back (gone 00:50:47) is 0.4 branch already open?? ra3vat: exact the same version of xmlrpclib oh Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib >>> xmlrpclib.__version__ '1.0.1' >>> kilo, is it working for you too now ? lekma: not yet, but soon ra3vat, as you can see i'm using the same version too reinhard: thx Python 2.3.3 (#1, Feb 15 2004, 00:27:11) [GCC 3.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib >>> xmlrpclib.__version__ '1.0.1' >>> johannesV: testing thanks guys :) lekma: i have questions on your example, but i'm at the phone now ok back now trying to understand your example is the picking list a class, or is it just a report from the sales order class? hmm, using the psycopg, the isolation level defaults to 'serializable' hi, newbie question, do i need wxpython to show forms with ncurses? no ra3vat: great :) thanks mnemoc, thou, navigator as one of the ui program exist only for wx navigator also works with gtk2 but not with curses *** SachaS has joined #gnuenterprise did not know that lekma: from that example I read the positions already exist and have just been *modified*, that should work already *** jamest has joined #gnuenterprise reinhard, ra3vat: uhm, ic lekma: appserver should never see *old* data, it just can happen to not see completely new records johannesV: still not good * reinhard is about to release appserver 0.3.5 to free the road for 0.4 bbl *** kilo has quit IRC done appserver is ready for breakage *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise ok, who's curious about MySQL and transaction isolation levels ? * mnemoc waiting anxious * reinhard is always curious transaction isolation for MySQL works only for InnoDB the InnoDB-Engine has to be enabled (on mysql-server-startup) and all tables has to be created with a "TYPE=InnoDB" or "ENGINE=InnoDB" in their CREATE TABLE statements if this is done, there are 4 isolation levels available, where 'repeatable read' is the default InnoDB seems to be available for MySQL 3.23 and enabled by default for MySQL 4.0 "Basic support for schema creation is also included." on Designer means 'limited' or just ugly? but in my debian-config (sarge) i had to uncomment a line in /etc/mysql/my.cnf "repeatable read" would be what we want, right? repeatable read means: you can repeat all your reads in a transaction, and you will get the same result. even if another transaction has commited changes to the same data ok, that *is* what we want hmm mysql 3.23 is what is available in woody even so i think we can take the "backend can isolate transactions properly" for granted for mysql and for postgres could maybe any of kilo or btamy check for interbase? i can check for interbase too but, please note: mysql needs other Schema.Creation for innodb then ! johannesV: but it would be doable, correct? of course i think it's not very much work though *** jcater has joined #gnuenterprise hi everyone u guys still going hard! thats great to see *** johannesV_ has joined #gnuenterprise *** johannesV has quit IRC me again, do you know where can i read code to make a form (curses) print? *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise i have to prove my boss gnue is a good choice against porting a legacy system to clip (unix native clipper/xbase compiler) firebird has also isolation levels, where it defaults to 'repeatable-read' too (at least my firebird 1.5 does) excellent btw serializable (what psycopg does) is also ok for us sorry to bother you with this stupid questions, see you. mnemoc: sorry, I didn't see your question serializable seems to be the same as repeatable-read mnemoc: what do you mean with "make a form print"? print a screen dump of the form? or start a report from within a form? a POS (point of sale) i would need to print over pre-print documents like invoices ah so you need a report that's not a matter of gnue-forms and not a matter of the ui you choose i recommend you take a look at gnue-reports i *think* it contains some good samples thanks :) of course you would use forms for data entry but then start reports to print the invoice sup dudes? last question, do i need to know python to use forms and reports? basic? advanced? ...? mnemoc: very basic if at all, depending on what you need to do but realistically, any major project will use it some, for triggers thanks, i think now i'm ready to "propose" to my boss :) hi jcater *** TSCHAK2 has quit IRC chillywilly: howdy how goes the diet? *** TSCHAK has joined #gnuenterprise *** SachaS has quit IRC lekma and frances: AFAWCT all db's we support *can* handle the transaction isolation on db level would you agree that the method of "post all pending changes before any select" would be the way to go then? jcater: I just now started...I figured there was no point trying to do it while the holidays were going on jcater: that was not going to happen ;) chillywilly: true that I stopped mine on thanksgiving plan to start back last week of January *** titopbs has joined #gnuenterprise no sense in kidding myself did you gain at all? I went from 220 down to 186 then went up to 192 when I quit but have been constant at 192 all of december I weigh 230 right now :( frances: well that is good news !!! so you agree? excellent frances: If this is the case, I would suggest to go for t he solution b) ok johannesV_: appserver dirty read rocket now has official start permission ;-) huh? frances: thanks for your help and research :) I would be delighted to have this problem solved chillywilly, jcater: i weigh 74 currently.... kg? ... but we measure in kilogramms ;-) BAH kilograms? blasphemy! reinhard: where are you from? 104.32 austria :-o 104kg I know, I'll just tell everyone I weigh 104 ;) .oO( my two favorites projects have austrian leaders, what a coincidence )o *** wendall911 has joined #gnuenterprise mnemoc: your favorite projects being? reinhard: why do you call them dirty not shining? :) reinhard: rocklinux and vserver ra3vat: :) reinhard, ok. i'll dig into that dirty-read stuff tomorrow johannesV_: tomorrow is a holiday :) (since lucas has his 7th birthday today ... and i've to do a plenty of things ) reinhard, there are no holidays in gnue-world :)) :) happy birthday party johannesV_ thanks :) bbl hrmmmm johannesV_: reinhard, there are no holidays in gnue-world :)) maybe he could explain that to my wife at some point? ;-) reinhard, could you check some code in typeconv.py gnue-common/src/rpc/drivers/xmlrpc/pw_xmlrpc/typeconv.py def rpc_to_python (value, exception): # None or String if isinstance (value, types.StringType): if value: return unicode (value, 'utf-8') *** dcmwai has joined #gnuenterprise if i change it to return unicode(value) my non-latin commit problem gone you are on Python 2.3 now? yep well the fact that this line i reached at all actually indicates a bug can you check what string gets passed there in "value" and whether it is server side or client side? (this routine is used on both sides) checking btw you use postgres? yes psycopg? yes plain non-latin string on server side value that is the value you committed? yes wx frontend? yes ok thanks * reinhard goes to reinstall wx reinhard, got the same error with 2 lines code from python shell 1 line >>> unicode('привет', 'utf-8') Traceback (most recent call last): File "", line 1, in ? UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid data where 'привет' is non-local string in local encoding non-latin ra3vat: the non-latin not-unicode string shouldn't make it to that point at all it should be converted to unicode before arriving there it was in utf-8 in xmlrpc packet it is not before it is after how did you check that? note i grabbed the value on appserver side and i have debug print in xmlrpclib that shows the packet right before that local string is passed to unicode(value, 'utf-8') in packet string is encoded in utf-8 so xmlrpclib converts from utf-8 to local encoding? ...string is passed to unicode(value, 'utf-8') in rcp_to_python i do not know yet who do the work :) i found a bug ra3vat: did you do a query before you inserted a new record? no and can you please check whether that makes any difference for you? opened sample.gfd put non-latin in name field, push F6 can you please test when you first do F8 F9 then insert new record and go on like your other test? ok, will change to original typeconv.py first i have non-latin in db already and the same error during query what should I do? delete it first? hmmm other test can you comment out the encoding = utf-8 in connections.conf? and see what happens then? query works and commit? commit with same error ok i think we're facing two problems that overlay overlap and without encoding=utf-8 i can't issue gsscvs with --createdb option in connections.conf that is yes i know just trying to find the bug by removing other known problems do you have any of textEncoding or Encoding set in gnue.conf? textEncoding = koi8-r ok Encoding commented out ok should both be correct ? both settings are correct AFAICT ok *** holycow has joined #gnuenterprise I think I will commit the fix for the first bug I found now great *** dcmwai has quit IRC hmmm still fighting sigh seems like I can't get psycopg to return the result of a query as utf-8 *** SachaS has joined #gnuenterprise neither does it work with any other postgres python binding reinhard, anything i could do for more testing? hey, would any of you guys think it is nuts to use an inhouse install of the savannah code for project tracking/management or inhouse development projects? would you recommend any other software? ra3vat: I'm pretty confident that we are facing two different overlapping issues here issue 1 is that postgres loses the SET CLIENT_ENCODING setting with the first commit or rollback (that's what causes the error for the query if the db encoding in connections.conf is not the default encoding) issue 2 is the question why the field values arrive as plain strings instead of utf-8 strings in typeconv i can reproduce issue 1 completely but haven't found a solution yet i can't reproduce issue 2 at all ok, will test issue 2 more I think I have found a solution for issue 1 *** lekma has quit IRC *** TSCHAK has quit IRC *** TSCHAK has joined #gnuenterprise dimas: issue 1 should be fixed i.e. you should be able to use or not use encoding = utf-8 in your connections.conf and appserver+forms should behave the same have you commited? that i could updates on notebook before leaving? and test later yes ra3vat: as to issue 2 the data you enter in the form should client side be passed to gnue-common's rpc library as UnicodeString get passed to xmlrpclib client side as UnicodeString get converted to utf-8 internally in xmlrpclib arrive at the xmlrpclib server side as utf-8 *** mnemoc_ has joined #gnuenterprise and get converted in typeconv back to unicode again (if that helps you in debugging) updated reinhard, thanks cu tomorrow, bye *** ra3vat has quit IRC *** mnemoc has quit IRC *** SachaS has quit IRC *** soda has joined #gnuenterprise hello hi soda today i had the first encounter with gnue its great for me this is the fing i was looking for all time nice to hear that should i give you an account number to send your donation to? ;-) :) oki , i will give this account number to my boss :) or rather a postal address to send a bottle of whisky? hmmm .pl yes so rather wodka I suppose :) anyway, now seriously any questions we can answer? yeah we have got good vodka in pl, the best one is hand maded right now im just trying to play with gnue that's a good way to start i have to write some invoicing , so im playin well but its great i thing look out for two guys here who call themselves kilo and btami they wrote an invoicing app with gnue and they are from .hu so your requirememts might be well compatible i did not write even a line in python but i will look in source, and see what is going on, and maybe i will can help *** titopbs has quit IRC if you know *any* other programming language, you will learn python within a rainy afternoon right now im writing in perl/php/c/bash, im wondering about makin the raports output as .pdf or .ps maybe i will try to write sth I have seen several people doing that with gnue-reports well actually I did it myself, too :) :) f...ing great *** cilkay has quit IRC *** sjc has quit IRC *** johannesV_ has quit IRC brb, cigarets has left :( going to the shop *** kilo has joined #gnuenterprise *** titopbs has joined #gnuenterprise kilo: you read the logs? soda is aiming at a gnue based invoicing solution :) :) yes but it will be nice, but the invoicing in my firm is realy f...ed up so right now im writing some views in sql hi hi kilo havent read logs yet, got to check something. in fact johannes' hack today to appserver was good, it was me who made an error and did not test it with great care... hah so johannes, if you read the logs tomorrow morning, your hack is great. thx hi soda i've seen that!! ;-) reinhard: so you released ok... not broken... kilo: it was in gnue-common anyway :) that's why i didn't consider to hold back the release was it? ah, yes, i see now * kilo needs whisky reading logs reinhard: or rather a postal address to send a bottle of whisky? valid currency... soda: finished reading logs, any questions? hmm right now , i made a form , iam querying the database , evrything is ok , i have added the button, wich will opens the new form, and im trying to figure out how to send fe. some value from 1form to 2form and then ask database using this value taken from 1form in the trigger there is a parameters ={} is it this i need ? yes, exactly. do you have gnue-contrib downloaded? .oO( what is that? )o nope yes svn co svn://svn.gnuenterprise.org/var/svn/gnue-contrib yes sorry for missinforming *** holycow has quit IRC there one can see several good examples of gnue usage kilo: thanks example params = {'id': blkHead.fldPaymentmeth.get() or ''} form.runForm('INV_PaymentMethod.gfd', params) thanks so you can pass a dictionary containing parameters to the newly opened form and you can also use this dictionary to get back values from the child form like here params = {'kunde': blkKunde.fldKundeId.get (), 'ticket': None} activateDialog ('selectTicket', params, 1) if params.get ('ticket'): dtsTicket.simpleQuery ({'gnue_id': params ['ticket']}) updGrund = False activateDialog can be considered a special case of runForm good night all *** reinhard has left #gnuenterprise good night jcater: could we add a reference to gnue-contrib somewhere on the www pages? ok , good night, i`ll be back tommorow :) ok, see you tomorrow good night *** jamest has left #gnuenterprise anybody have experience getting McMillan Installer 6a2 working with wx? *** TSCHAK has quit IRC *** TSCHAK has joined #gnuenterprise *** XEN has joined #gnuenterprise *** kilo has quit IRC *** sjc has joined #gnuenterprise *** XEN has quit IRC *** titopbs has quit IRC *** jamest has joined #gnuenterprise *** jamest has quit IRC *** sjc has quit IRC *** XEN has joined #gnuenterprise *** XEN has quit IRC *** dcmwai has joined #gnuenterprise *** jcater has quit IRC *** jcater has joined #gnuenterprise *** CRIMANY has joined #gnuenterprise *** wendall911 has quit IRC *** CRIMANY has quit IRC *** TSCHAK has quit IRC *** TSCHAK has joined #gnuenterprise *** XEN has joined #gnuenterprise *** XEN has quit IRC *** TSCHAK has quit IRC *** TSCHAK has joined #gnuenterprise *** TSCHAK has quit IRC *** TSCHAK2 has joined #gnuenterprise *** XEN has joined #gnuenterprise *** jcater has joined #gnuenterprise *** TSCHAK2 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** TSCHAK3 has quit IRC *** TSCHAK2 has joined #gnuenterprise *** TSCHAK2 has joined #gnuenterprise *** XEN has quit IRC