*** SachaS has quit IRC
*** havoc has quit IRC
*** sjc has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<dimas> johannesV: hello
*** havoc has joined #gnuenterprise
<johannesV> hi dimas
*** btami has joined #gnuenterprise
<dimas> hello btami
<dimas> btami: sorry to hear about the father :(
<btami> hi dimas
<btami> thx
<johannesV> btami, i've read it in the log today, and i feel very sorry too
*** havoc has quit IRC
<btami> johannesV: thx, what do you think about introducing an optional feature for dbdrivers not supporting rowid thingy
<btami> something like tablename_id as keyfield with an autogenerated id
<btami> is this make sense ?
* btami is thinking loud
<johannesV> i haven't follwed this discussion in very much detail, so you'd better ask reinhard
<btami> ok
<johannesV> btami, you mean instead of gnue_id ?
<btami> yep
<btami> in 2 tier
<johannesV> yes, i see
<johannesV> well, i could imagine something like a _rowIdField setting per driver (if it's not there already) defining the 'id-field'
<johannesV> but, as mentioned before, i don't have a very deep insight regarding this topic atm
*** reinhard has joined #gnuenterprise
*** dimas has quit IRC
*** dimas has joined #gnuenterprise
*** btami has quit IRC
*** nickr has quit IRC
*** johannesV has quit IRC
*** sjc has quit IRC
*** Vee2d2 has quit IRC
*** dcmwai has quit IRC
*** mnemoc_ has quit IRC
*** chillywilly has quit IRC
*** ajmitch has quit IRC
*** cilkay has quit IRC
*** reinhard has quit IRC
*** derek has quit IRC
*** tiredbones has quit IRC
*** Amorphous has quit IRC
*** elwis has joined #gnuenterprise
*** elwis has left #gnuenterprise
*** Vee2d2 has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** mnemoc_ has joined #gnuenterprise
*** tiredbones has joined #gnuenterprise
*** chillywilly has joined #gnuenterprise
*** ajmitch has joined #gnuenterprise
*** Amorphous has joined #gnuenterprise
*** cilkay has joined #gnuenterprise
*** nickr has joined #gnuenterprise
*** btami has joined #gnuenterprise
<kilo> reinhard: what should I provide for new designer release? NEWS?
<reinhard> kilo: people were noticing problems with designer yesterday
<reinhard> I think they are not sorted out
<reinhard> when calling "run form" from menu there was a traceback
<reinhard> seemed to come from initializing the debug system twice
<reinhard> or something like that
<kilo> when doing 'run form' a new gfinstance is created, so that seems logical...
<reinhard> it's setDebug
<reinhard> which actually should be called in GFClient, not in GFInstance
<kilo> but designer has a menu entry a user can use to set debug level
<kilo> how to change that then?
<reinhard> oh
<reinhard> hmmm
<reinhard> will I really have to fire up designer now?
<reinhard> :)
<reinhard> will look at it asap (~ 1 hour)
<reinhard> as to release
<reinhard> see gnue-common/doc/technotes/00011.txt :-)
<kilo> gnue-designer/src/forms/Instance.py line 371
*** aries_mindworks has joined #gnuenterprise
<aries_mindworks> hi
* aries_mindworks testing gaim's irc functions
<btami> hi aries_mindworks
<reinhard> kilo: could you please check what the value of sys.__stderr__ is before that call to setDebug ?
<reinhard> wee
<kilo> dicovered a bug just now
<reinhard> in forms/Debugger.py sys.__stderr__ is redirected
<reinhard> to a class
<reinhard> this class must implement a flush () method
<reinhard> that's all
<reinhard> (that flush() would have to flush() the underlying file)
<kilo> i see
<reinhard> although I consider it quite bad to redirect __stderr__ (as that is usually the *original* stderr)
<kilo> it is redirected to a simple windows that shows the debug messages
<reinhard> setDebug would take a second parameter with a file handle or compatible object
<reinhard> so it *should* work to pass that _stderrcatcher as second parameter to setDebug
<kilo> I think Jason thought that this new windows is more comfortable than seeing debug messages in somewhere in the console
<reinhard> I agree, but the above would be a cleaner way to achieve the same
<reinhard> however this would probably need testing
<reinhard> also, what I'm missing is resetting the debug to the original state
<ajmitch> hi
<ajmitch> reinhard: going to provide a new designer release or shall I apply the patch?
<reinhard> which would mean that debug messages of designer wouldn't work any more after a form was run
<reinhard> ajmitch: I think we want to provide a new release
<ajmitch> ok
* ajmitch has only 2 weeks before the hoary release
<kilo> reinhard: it is reset in Debugger.py line 80
<reinhard> kilo: that's not enough
<kilo> blame Jason
<reinhard> if you look at setDebug in GDebug.py
<kilo> it is all his code
<kilo> and in fact i cannot say that i feel comfortable hacking this...
<reinhard> kilo: I understand that :)
<reinhard> kilo: if you look at setDebug in GDebug.py, you can see that the current sys.__stderr__ is saved as the filehandle to write debug and error messages to
<reinhard> resetting sys.__stderr__ in Debugger.py won't help, because the _fh in GDebug will still point to the _stderrcatcher of designer
<reinhard> which then points to a non-existing window
<reinhard> which actually *might* even be the reason for the problems with exiting from a debugged form
* btami hopes finally reinhard will fix this bastard :)
<kilo> Debugger.py line 144 does this, doesnt it?
<reinhard> well, actually there's parts of gnue that i don't want to mess with
<reinhard> :)
<reinhard> kilo: ahh
<reinhard> now I see what broke it
<reinhard> GDebug._fh is only half of the truth
<reinhard> __stderrcatcherr.filehandle is the other half
* kilo locks reinhard and jason in a room for a day and throws away the key. very very far...
<reinhard> so instead of setting sys.__stderr__ and GDebug._fh
<reinhard> _stderrcatcher should do GDebug.__chatchStderr (self)
<reinhard> and in _restore, GDebug.__catchStderr (self.origfh)
<reinhard> but anyway
<reinhard> the flush() method needs implemented
<reinhard> this doesn't change
<reinhard> and that will fix the traceback
* kilo feels that reinhard wont touch this...
<reinhard> I can't even test properly
<reinhard> actually I'm not even sure if I have wx installed here
<aries_mindworks> btami: hi
<reinhard> kilo/btami: from the code i read that adodbapi and interbase have problems with cursor.rowcount
<kilo> it must have
<reinhard> now I have read in DBSIG2 docs that for some db's rowcount is only available after the first fetch
<reinhard> is there any chance you can test that?
<reinhard> I'd like to implement the handling of broken rowcount in the general DBSIG2 driver so adodbapi and interbase wouldn't need special handling
<btami> sure
<reinhard> thanks
<kilo> where is rowcount used?
<kilo> we've started a form connected to a firebird db and it works
*** elwis has joined #gnuenterprise
<reinhard> kilo: please compare interbase's DataObject._createResultSet with the standard DBSIG2 one
* kilo lost deep in designer code
<reinhard> DBSIG2 just does
<kilo> i just reported as btami was eating pizza...
<reinhard>         recordCount = cursor.rowcount
<reinhard>     if self._strictQueryCount:
<reinhard>       rs._recordCount = recordCount
<reinhard> while interbase does a query like SELECT count(...) from...
<reinhard> to determine the _recordCount of the resultset
<reinhard> and I wondered if cursor.rowcount is broken for interbase
<reinhard> or if there is another reason why interbase does it differently than the other DBSIG2 drivers
<btami> from kinterbasdb docs:
<btami> rowcount attribute
<btami> Although KInterbasDB's Cursors implement this attribute, the database engine's own support for the determination of "rows affected"/"rows selected" is quirky.
<btami> The database engine only supports the determination of rowcount for INSERT, UPDATE, DELETE, and SELECT statements. When stored procedures become involved, row count figures are usually not available to the client.
<btami> Determining rowcount for SELECT statements is problematic: the rowcount is reported as zero until at least one row has been fetched from the result set, and the rowcount is misreported if the result set is larger than 1302 rows. The server apparently marshals result sets internally in batches of 1302, and will misreport the rowcount for result sets larger than 1302 rows until the 1303rd row is fetched, result sets larger than 2604 rows unti
<btami> l the 2605th row is fetched, and so on, in increments of 1302.
<btami> As required by the Python DB API Spec, the rowcount attribute "is -1 in case no executeXX() has been performed on the cursor or the rowcount of the last operation is not determinable by the interface".
<reinhard> wee
<reinhard> thanks btami
*** aries_mindworks has left #gnuenterprise
<reinhard> elwis: sorry, odbc driver has not been maintained for years; I've finally removed it from last week as it was not functional for quite some time :(
<reinhard> elwis: as to master detail, I think you misunderstood
<reinhard> even if it sounds wrong, the master is always the "main" table of the form, in your case the order
<reinhard> and the "detail" is then the customer
<reinhard> bbl
<elwis> reinhard: no odbc, not in the future either then?
<btami> elwis: maybe you have to try the adodbapi dbdriver
<reinhard> the problem is that I don't have windows and can't help
<reinhard> redoing the driver for odbc should not be a very big problem
<elwis> reinhard: Good for you ;)
<reinhard> (at least if you don't need introspection support)
<reinhard> but I can't do it :)
<reinhard> bbl now for real
<elwis> btami: How would I try out the adodbapi driver?
<elwis> btami: Maybe I'll start with walking over to my colleague who wrote the ODBC drivber :)
<btami> elwis: here is my two examles from connections.conf
<btami> [xls]
<btami> provider = adodbapi
<btami> oledb_provider = Microsoft.Jet.OLEDB.4.0
<btami> data_source = C:\home\proba.xls
<btami> extended_properties="Excel 8.0;HDR=Yes"
<btami> [booksale]
<btami> provider = adodbapi
<btami> oledb_provider = Microsoft.Jet.OLEDB.4.0
<btami> data_source = C:\home\booksale.mdb
<btami> database = valami
<btami> and another one:
<btami> [tabl_dbf]
<btami> comment = tabl_dbf.dbf adodbapi-val
<btami> provider = adodbapi
<btami> oledb_provider = vfpoledb
<btami> data_source = c:\home\tabl_dbf.dbf
<elwis> Thanks a lot, I'll check those out
<btami> we have some docs generated from *.py sources for all our dbdrivers
<btami> like this: http://www.gnuenterprise.org/tools/common/databases/adodbapi.php
<elwis> Thanx that will be useful when showing my win-friends at work
<elwis> Won't work with our ERP system though ;)
<elwis> A quick one, how well does the menu work? I saw Saschas "BabyERP" screenies and want one :)
*** sjc has quit IRC
<btami> it's far from perfect, but works
<elwis> Thanks for the info, seem to lack som documantation, both the Navigator and Reports
<btami> yes
<btami> any help are welcome
<elwis> Actually, I was planning to write my "GNUe for the helpless" .. I'm the man for it :)
<btami> cool !
<kilo> it will be a success story
<elwis> I'' give you notice when it's ready, then someone could check it, and maybe put it on the wiki
<elwis> For other helpless ones.. ;)
<kilo> it will sell out in the first week...
<elwis> maybe I'll try to do business from that instead from my GNUe cash-registry..
<reinhard> elwis: knowledge about gnue is a terse good on this world ;-)
<btami> bbl
*** btami has quit IRC
* reinhard is happy about the increasing number of translations we get for this project
<reinhard> now we seem to have de, hu, nl, and it
<reinhard> with people that constantly maintain them or at least intend to do so
<reinhard> also ru
<reinhard> (sorry dimas) :)
*** dimas has quit IRC
*** Vee2d2 has quit IRC
*** kilo has quit IRC
*** Vee2d2 has joined #gnuenterprise
<reinhard> bbl
*** kilo has joined #gnuenterprise
*** havoc has joined #gnuenterprise
*** lekma has joined #gnuenterprise
<lekma> hi everyone
<elwis> reinhard: I'm back, and i have to spell out my intention to get the knowledge to translate to swedish
<kilo> elwis: great!
<johannesV> reinhard, it looks like gnue-schema is broken now ...
<johannesV> hmm, if i add a 'primarykey' definition to the DataSourceWrapper's attribute in gnue-schema it seems to work again ...
<johannesV> i think gnue-schema needs an 'optimization run' ... :)
*** kilo has quit IRC
*** jamest has joined #gnuenterprise
*** jamest has joined #gnuenterprise
<lekma> Traceback (most recent call last):
<lekma>    File "/usr/lib/gnue/appserver/geasSessionManager.py", line 399, in call
<lekma>     result = s.call (classname, obj_id_list, procedurename, parameters)
<lekma>    File "/usr/lib/gnue/appserver/geasSession.py", line 659, in call
<lekma>     result.append (instance.call (procdef, parameters))
<lekma>    File "/usr/lib/gnue/appserver/geasInstance.py", line 362, in call
<lekma>     method = cx.buildFunction (proceduredef.gnue_name, proceduredef.gnue_code,
<lekma>    File "/usr/lib/gnue/appserver/repository.py", line 373, in __getattr__
<lekma>     result = getattr (self.__object, attr)
<lekma>    File "/usr/lib/gnue/appserver/language/Object.py", line 99, in __getattr__
<lekma>     res = sm.load (self.__sid, self.__class, [self.objectId], [name])
<lekma>    File "/usr/lib/gnue/appserver/geasSessionManager.py", line 358, in load
<lekma>     result = s.load (classname, obj_id_list, propertylist)
<lekma>    File "/usr/lib/gnue/appserver/geasSession.py", line 537, in load
<lekma>     result.append (instance.get (propertylist))
<lekma>    File "/usr/lib/gnue/appserver/geasInstance.py", line 261, in get
<lekma>     return [self.__getValue (aProperty) for aProperty in propertylist]
<lekma>    File "/usr/lib/gnue/appserver/geasInstance.py", line 254, in __getValue
<lekma>     return self.__convert (value, propertydef, DbValueError)
<lekma>    File "/usr/lib/gnue/appserver/geasInstance.py", line 124, in __convert
<lekma>     return unicode (value)
<lekma>  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 220: ordinal not in range(128)
<lekma> this one is new
<chillywilly> yay, traceback ;)
<chillywilly> nothing like a good traceback in the morning
<johannesV> lekma, i get the same error if i use german umlaut ... seems as if there's something broken ....
<johannesV> (i'm using sample.gfd [if reinhard is reading this])
<lekma> i can't seem to find out what has changed between yesterday and today that triggers this error
<johannesV> yes, i've thought the same ...
<johannesV> was it working for you yesterday ?
<lekma> yep
<lekma> that was the same proc that triggered the commit pb you fixed yesterday
<lekma> so i assume smthing changed in between you fixed it and now
<lekma> cause neither the proc nor the way it's called changed
<johannesV> hmm, i've to run now but i'll look into it in the evening ... maybe reinhard could have a look at it ...
<lekma> thx
*** elwis has quit IRC
*** titopbs has joined #gnuenterprise
<lekma> anybody can help with reports?
*** jcater has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
<lekma> jcater: can you help with reports?
<lekma> i have a strange pb
<lekma> i finally made a master/detail
<lekma> report (still first stepS)
<lekma> but i have one more detail line than available in data
<lekma> :)
<lekma> i have a master (a bill)
<lekma> which has 2 details
<lekma> (bill items)
<lekma> but when i fire the report i get 3 lines in the detail table
<lekma> the first one being repeated at the end
<lekma> the backend is appserver
<lekma> and i double checked in db: there really is only 2 records
*** kilo has joined #gnuenterprise
*** SachaS has joined #gnuenterprise
<lekma> well in fact if you make master/detail datasources in reports the result is completly screwed
<lekma> in the previous description the detail that appears first and third isn't even related to the master
<SachaS> hi gnuers
<lekma> hi SachaS
<SachaS> hi lekma
*** dimas has joined #gnuenterprise
<kilo> lekma: plz check gnue-invoice's report in ggnue-contrib, iirc it has m/d
<lekma> kilo: thx
<kilo> but blame btami for it 8-)
<lekma> can't seem to find a gnue-contrib
<lekma> is an other svn trunk
<lekma> ?
<lekma> s/is/is it
<jamest> it's in it's own repository
<jamest> co gnue-contrib instead of gnue
<jamest> or download a tarball from
<jamest> http://www.gnuenterprise.org/cgi-bin/viewcvs.cgi/gnue-contrib/
*** jamest has left #gnuenterprise
*** wendall911 has joined #gnuenterprise
*** elwis has joined #gnuenterprise
*** jamest has joined #gnuenterprise
*** monolithic has joined #gnuenterprise
<elwis> *Ouch* I'm on page 3 in my "GNUe for the brainless" guide... and I just reached how to install the packages. is the correct packagename "gnue-forms-wxgtk"?
<elwis> Or is that Hoary only?
<dimas> packages are different in different distro
<elwis> that's what I thought, didn't recognize the name. I'll stick to Hoary only then
<dimas> hm
<dimas> packages that required for gnue that is
<dimas> not sure about gnue-* packages themselfs
<elwis> Oh. I thought wxGTK is "always" needed on *nix platform? Not true?
<dimas> i have no wxGTK right now at all
<dimas> here is altlinux.org distro on one machine
<elwis> So, what do you use for your ui? GTK?
<dimas> yep
<elwis> Wait a second? How does gnue-forms make that desicion if you don't specify a parameter? What's the "default"?
<elwis> Cause my forms looked somehow more polished on the Novell-GNOME Desk then on my Hobby Hoary?
<dimas> there is DefaultUI in gnue.conf
<reinhard> elwis: it's a bit confusing, sorry
<reinhard> about the package names
<reinhard> the *plan* was to have
<reinhard> gnue-forms-wxgtk
<reinhard> gnue-forms-gtk2
<reinhard> gnue-forms-curses
<reinhard> gnue-forms-kde3
<reinhard> and the first one to run smoothly was wxgtk
<reinhard> then, when the others were finished, debian had stopped accepting of new packages (in anticipation of sarge release)
<reinhard> so to have everything there, we packed everything in gnue-forms-wxgtk (which was already accepted)
<reinhard> so currently, gnue-forms-wxgkt contains *all* ui drivers
<reinhard> but that will change as soon as we seem to be able to get the other packages into debian
<elwis> clever, clever, so if I mention to install gnue-forms-wxgtk, they'll have it all :) ... today...
<reinhard> yep, sorry for that confusion
<reinhard> however, the package names are identical for ubuntu and debian
<reinhard> (and, fwiw, the package content)
<elwis> but then I shouldn't mention any need of having wxGTK installed? GTK2 would also do?
<reinhard> yes
<reinhard> but you *should* probably mention that the defaultUI should be set in gnue.conf
<elwis> not until I checked that setting myself.. I didn't know that.. :)
<reinhard> the difference you see with wx (the default) might come from different wx versions
<reinhard> brb
<elwis> changed to gtk2, it's still not as nice as the Novell GNOME, supose the themes comes in to play though. Is it possible to mess with fonts for example?
<reinhard> yes, I think it's the themes
<reinhard> bbl
*** reinhard has quit IRC
<monolithic> Hello all
<dimas> hi monolithic
<monolithic> Hate to sound odd, but I would like to help w/ the project
<monolithic> Not a programmer, but am a small business owner
<dimas> there are few the same here
<monolithic> Don't wanna sound pushy, but I do have ideas about what I would like to see implemented
<dimas> monolithic: you could help greatly
<monolithic> What can I do w/o getting in the way?
<jamest> i think that depends more on what you'd like to do than what we need done
<dimas> share with your ideas of what and how you see it need to be done
<jamest> asking you to do something you don't enjoy will chase you away :)
<monolithic> jamest, I never really have gotten involved w/ something like this before. Should I just start rambling?
<monolithic> First, is gnue useable at all right now?
<jamest> the tools most definately
<johannesV_> reinhard: for the logs: result of connection.requery() is not unicode !!!
*** titopbs has quit IRC
<jamest> monolithic: you're free to rambling in here but i can't promise timely responses
<jamest> i have to go beat a co-worker
*** reinhard has joined #gnuenterprise
<reinhard> doh!
<reinhard> <johannesV_> reinhard: for the logs: result of connection.requery() is not unicode !!!
<reinhard> I think that was a good hint :)
<monolithic> Gnue obviously is about general accounting (accounts payable, receivable, etc.), but here is what I would like to see.
<monolithic> invoicing
<monolithic> estimating
<monolithic> job costing
<monolithic> scheduling & dispatch
<monolithic> integrate w/ common office apps
<monolithic> Are any of these in the works?
<dimas> there is gnue-invoice in contrib
<jamest> gnue is mainly about the tools to create business apps quickly and easily
<jamest> we are to have some apps built upon it but they never seem to get much past concept
<jamest> for instance in house my invoicing system is all gnue based
<monolithic> I'm an hvac contractor, but I hobby w/ gnu/linux at home. I would love to see gnu/linux for contractors like me.
<dimas> monolithic: hvac?
<monolithic> However, biggest hurdles are standard apps, special apps, and even custom apps (like load calcs, etc.)
<monolithic> heat & air conditioning
<dimas> ok
<reinhard> is svn dead again?
<jamest> seems to be
<jamest> try now
<johannesV_> great, that unicode-problem is fixed ! thanks reinhard
<johannesV_> lekma, please svn up and try again ...
<jamest> i'm shutting off apache-ssl and postgresql on ash
<jamest> unless someone has a reason we need to run them
<lekma> johannesV_: yep it works now
<lekma> reinhard: thx
<lekma> bb
<lekma> bbl
* lekma is away: feeding the cat...
*** johannesV_ has quit IRC
*** titopbs has joined #gnuenterprise
<reinhard> gack!!!!
<reinhard> python expert question
<reinhard> def foo (bar = {}):
<reinhard>   print bar
<reinhard>   bar ['x'] = 100
<reinhard> foo ()
<reinhard> foo ()
<reinhard> ----------
<reinhard> what does the above code print?
<jamest> interesting
<jamest> so the default dict is only initialized once eh
<jamest> i wouldn't have thought that
<reinhard> http://www.python.org/doc/2.3.5/ref/function.html
<reinhard> nice little trap
<reinhard> for example we do things like
<reinhard>   def __init__ (self, parent, initialData = {}, defaultData = {})
<reinhard> and later we modify the initialData in the code
<reinhard> and voila
<jamest> i wonder if that is the reason for some oddities that i get in datasources once in a great while
<reinhard> the next record inserted gets the data of the previous one
<reinhard> jamest: there are quite a few potential reasons for oddities hidden in datasources ;-)
<jamest> lol
<jamest> they've only been rewritten what now 3 times?
<reinhard> but this has made me believe like I was insane
<jamest> you are
<jamest> er, i mean, really?
<reinhard> I called the __init__ with initialData not set at all
<jamest> and had data!
<reinhard> in function header I give default value of {}
<reinhard> and right as the first line of the function I did print initialData
<reinhard> and got {'oid': 81203}
<reinhard> and was like "wtf??""
<jamest> reinhard: while youre in there
<jamest> (datasources)
<jamest> one thing i've noticed is that gnue datasources leave connections in transaction
<jamest> so if I want to update the structure of a table in postgresql I have to tell all my forms users to exit the application
<jamest> as they block the table updates
<reinhard> isn't that a DBSIG2 module problem?
<jamest> i don't recall our sql code issueing a FOR UPDATE on the selects
<jamest> which i think would cause that
<reinhard> no, it doesn't
<reinhard> but psycopg & friends do a BEGIN right on connect
<reinhard> (IIRC)
<jamest> sigh
<reinhard> and immediately after commit and rollback
<jamest> that's special
<elwis> *Ouuch* My neck, my back.. my brain.. page 11 and finally the structure of a .gfd file..
* reinhard remembers monty python's "doctor! doctor! my brain hurts ... me"
<reinhard> ***********************
<reinhard> johannesV: you can reverse your change in gnue-schema
<reinhard> it was a bug in datasources, fixed it
<reinhard> thanks for leading me to this awful bug
<reinhard> ***********************
*** elwis has left #gnuenterprise
*** nickr has quit IRC
*** dcmwai has quit IRC
<kilo> any1 knows an msn client for linux
<kilo> ?
*** nickr has joined #gnuenterprise
<reinhard> I think that's an oxymoron
<reinhard> :)
<kilo> my wife wants to chat with friend who use that thing...
<jamest> kilo: kopete offers it though i've not used it
<kilo> hmm, i think i will recommend her to use skype...
*** dcmwai has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** jcater has quit IRC
*** reinhard has quit IRC
*** wendall911 has quit IRC
<kilo> hi SachaS
*** mnemoc has joined #gnuenterprise
*** kilo has quit IRC
*** mnemoc_ has quit IRC
*** titopbs_ has joined #gnuenterprise
*** titopbs_ has quit IRC
*** titopbs has quit IRC
*** monolithic has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** titopbs has quit IRC
*** holycow has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** titopbs has quit IRC
*** jcater has quit IRC
*** holycow has quit IRC
*** cilkay has left #gnuenterprise