*** kilo has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** derek has quit IRC
*** aries_mindworks has joined #gnuenterprise
<aries_mindworks> hi
*** aries_mindworks has left #gnuenterprise
*** aries_mindworks has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<dimas> good morning
*** btami has joined #gnuenterprise
<btami> good morning
<aries_mindworks> hi
<johannesV> hi aries_mindworks
<johannesV> regarding your allocation problems with mysql
<johannesV> the username and password portions are left out from the mysqladmin-command
<johannesV> which creates the db
<johannesV> this is because that command is executed as system command and thus could be seen by any ps
<johannesV> i've found it a more secure way to use a ".my.cnf" file in the homedirectory having a "[mysqladmin]" section
<johannesV> this file is readable only to you and makes it easy to provide credentials for database allocation in a secure way
<aries_mindworks> johannesV: What's about the u/p if I set it in the connections.conf?
<johannesV> first, they are GRANTed access to the newly created db
<aries_mindworks> johannesV: it's not insecure, and many user are not familiar with my.cnf and they don't care. they wan't to run the app
<johannesV> and finally they are used to connect to the created db
<johannesV> well, i don't have a problem with adding -u %s and -p %s to the mysqladmin command if you like to
<aries_mindworks> johannesV: I don't understand. the gsscvs are not using connections.conf?
<johannesV> of course they do
<aries_mindworks> johannesV: if not, why should I set the --connection parameter? :)
<johannesV> but the username/password provided by connections.conf (or command-line) will *not* be used for database-allocation, but only for getting access to a created db
<johannesV> (as these cred. can't be used for mysqladmin-shell-command if not provided as arguments)
<aries_mindworks> johannesV: it would be nice if --createdb try to use the u/p from connections.conf. if the user has grants to create db, the gsscvs should create the db, else it should tell that he hasn't got the rights. but you shouldn't limit the user because there's another way to set the login parameters
<johannesV> would you prefer adding --username= --password= to the mysqladmin command issued on db-creation (from gnue-schema) ?
<aries_mindworks> johannesV: or if you don't wan't to implement, just write a good error msg to the user, what the should understand
<aries_mindworks> johannesV: yes. if anyone wan't to use it, just let it to him
*** reinhard has joined #gnuenterprise
<aries_mindworks> johannesV: or get the defaults from the connections.conf
<johannesV> but that connections.conf thing doesn't change anything
<reinhard> good morning
<johannesV> the question is wether to issue u/p on creation (via args) or not
*** ajmitch has quit IRC
<johannesV> aries_mindworks, i've commited a Behaviour.py which passes the given credentials (either by command-line or connections.conf) to mysqladmin
<johannesV> but please note: this implies that the given user is allowed to create new databases on your mysql-server in order to let it work
<aries_mindworks> reinhard: hi
<aries_mindworks> johannesV: if not allowed, it should write an exact error message, because as I am, the user don't know why
*** ajmitch has joined #gnuenterprise
<reinhard> hi aries_mindworks
<reinhard> aries_mindworks: I think you misunderstood the problem johannesV was talking about
<reinhard> no matter where you give the password
<reinhard> in the background, gnue-schema (or gsscvs) will run a "mysqladmin" command to create the database
<reinhard> and if you provide a password from *anywhere* (no matter from commandline or from gnue.conf)
<aries_mindworks> johannesV: as I know, if you're not allowed to create tables, you will not be able to use gsscvs... so in my view you should take care the connections.conf AND command line...
<aries_mindworks> reinhard: ok, I see
<reinhard> the command that runs in the background will be "mysqladmin --password foo"
<reinhard> and anybody doing "ps -ef" will see that password
<aries_mindworks> reinhard: but the application should give good error messages to the user and explanations if needed
<reinhard> yes, I agree with that
<aries_mindworks> are there any good practice to install the fresh-new updates?
<aries_mindworks> ./setup-cvs.py ?
<reinhard> that's not needed
<reinhard> setup-cvs.py creates symlinks
<reinhard> so after updating svn everything is already current
<reinhard> except for the very rare cases when e.g. a new command is introduced
<aries_mindworks> in system-wide installation too?
<reinhard> yes
<aries_mindworks> that sound great!
<aries_mindworks> ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
<aries_mindworks> am I do something wrong?
<aries_mindworks> i've updated
*** sjc has joined #gnuenterprise
<aries_mindworks> interesting
<aries_mindworks> it's creating the database
<johannesV> aries_mindworks, maybe this is the grand-command sent to the fresh db
<aries_mindworks> but it gives me error msg
<johannesV> have you got enough permissions for "root" to add new grants ?
<johannesV> aries_mindworks, check if the tables are created and the data posted ... i bet they are
<aries_mindworks> johannesV: everything is ok, the tables are ready
<aries_mindworks> johannesV: but I don't understand why it said the ERROR 1045
<aries_mindworks> johannesV: because it created the db
<aries_mindworks> johannesV: after this there's no error
<johannesV> yeah, but after creating the db it performs some grants
<johannesV> (exactly two grants)
<johannesV> and they seem to fail
<johannesV> (due to a lack of permission)
<aries_mindworks> johannesV: grants? to what?
<aries_mindworks> to whom?
<johannesV> GRANT ALL PRIVILEGES ON %(db)s.* TO '%(user)s'@'%%' %(pass)s
<johannesV> GRANT ALL PRIVILEGES ON %(db)s.* TO '%(user)s'@'localhost' " \
<johannesV>            "%(pass)s"
<johannesV> aries_mindworks, have you read gnue-common/doc/hints.mysql.txt ?
<aries_mindworks> johannesV: no, I'm starting to read
<aries_mindworks> johannesV: ok, but on my desktop, the root user has all the privileges
<johannesV> are you sure ?
<aries_mindworks> johannesV: yes I'm sure
<johannesV> i don't have all the priv-tables in mind which are used by mysql
<johannesV> hm
<aries_mindworks> | %                        | root | 1b7134066be07a97 | Y           | Y           | Y           | Y           | Y           | Y         | Y           | Y             | Y            | Y         | Y          | Y               | Y          | Y          |
<aries_mindworks> from the mysql.user
<johannesV> hm, would have to fiddle with it a bit to find out ...
<aries_mindworks> Updating schema ...
<aries_mindworks> Updating data ...
<aries_mindworks>   updating table 'gnue_property' ...
<aries_mindworks>     Rows: 49 inserted, 0 updated, 0 unchanged.
<aries_mindworks> [...]
<johannesV> btw (as jamest was asking yesterday) ... the new wx26 driver seems to work fine with wx 2.5.3+
<reinhard> johannesV: maybe it would help debugging if you saw exactly what command causes the error?
<aries_mindworks> reinhard: should I sent anyone the output?
<reinhard> don't know if the output would help johannesV
<aries_mindworks> sent to him
<johannesV> i can reproduce the error 1045, if i set GRANT_PRIV to 'N' in mysql.user for the username i try to connect with
<johannesV> if that user has a grant_priv 'Y' everything works fine
<johannesV> check: select host, user, grant_priv from user;
<aries_mindworks> johannesV: I don't see the bug, and you?
<johannesV> is that line above the only one ?
<aries_mindworks> johannesV: only one? I've sent the all of the output, mysql.user, connection.conf :)
<johannesV> ah, haven't got any mail yet
<aries_mindworks> johannesV: via irc
<aries_mindworks> johannesV: but I send you via email if you want
<aries_mindworks> johannesV: but you should send me your address
<aries_mindworks> :)
<aries_mindworks> I've sent the mail
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
<johannesV> aries_mindworks, i think i can reproduce it now ...
<johannesV> aries_mindworks, please svn-up and retry
<johannesV> it should work now ...
<aries_mindworks> johannesV: ok, updating
<aries_mindworks> johannesV: now it's OK, thanks! (please don't forget those speaky error messages ;))
<johannesV> well, that message are sent from the mysql-db and i don't have any influence on them ...
<johannesV> we'd have to parse the message for some error-codes but ... well, ...
<aries_mindworks> johannesV: ok, I understand
<aries_mindworks> johannesV: :)
<johannesV> better way is to use a .my.cnf anyway :)
<aries_mindworks> johannesV: why don't you use mysql for python module?
<reinhard> aries_mindworks: you can't create new databases with that module
<reinhard> for normal data access, we use it anyway
<johannesV> aries_mindworks, a database cannot be created by such a MySQLdb.Connection instance
<johannesV> because creating a database must not be done *within* a transaction
<johannesV> the same reason applies to granting permissions ... this is not possible within a running transaction
<johannesV> so the only way to accomplish the task was using mysqladmin and mysql as well
<johannesV> maybe the MySQLdb module provides a better mechanism in the future
<aries_mindworks> thanks for the answers
<johannesV> np
<johannesV> i'm off for a while now ... have a nice day !
*** btami has quit IRC
*** sjc has quit IRC
<aries_mindworks> [root@ganja forms]# gfcvs grid-hu.gfd
<aries_mindworks> python2: Modules/gcmodule.c:275: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.
<aries_mindworks> Aborted
<aries_mindworks> after I try to edit a customer, the gfcvs exists
<aries_mindworks> exits
*** erkkie has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** kilo has quit IRC
*** kilo has joined #gnuenterprise
*** jcater has quit IRC
<reinhard> aries_mindworks: wow
<reinhard> that's a python internal exception
<reinhard> never even seen that
<aries_mindworks> reinhard: where I'm appearing, everything will be collapsed :)
*** jcater has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** jamest has joined #gnuenterprise
<aries_mindworks> reinhard: am I do something wrong?
<reinhard> aries_mindworks: I have not the slightest idea what causes this error
<reinhard> can you reproduce it 100%?
<reinhard> can you reproduce it with a different form? (maybe one that is pure ascii, just to play safe)
<aries_mindworks> yes, 100%
<aries_mindworks> i've tried with gnue-invoice
<aries_mindworks> grid-hu.gfd
<aries_mindworks> trying with the english form...
<aries_mindworks> Python 2.4.1 (#1, May 16 2005, 15:19:29)
<aries_mindworks> [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
<aries_mindworks> the command was gfcvs grid-hu.gfd
<aries_mindworks> the problem isn't appearing when I'm using the grid.gfd
<aries_mindworks> the second problem is, when I try to edit a payment method (all of them, include empty) I've getting the following error msg (detailed):
<aries_mindworks> Traceback (most recent call last):
<aries_mindworks>    File "<unknown_executioncontext>", line 11, in __main_____GF_1214494868___GF_1214494740_btnEditPaymMeth_ON_ACTION_btnEditPaymentMethodTrigger
<aries_mindworks>    File "/home/aries/GNUe/gnue/.cvsdevelbase/gnue/common/logic/NamespaceCore.py", line 219, in __getattr__
<aries_mindworks>     raise AttributeError, '%s' % (name)
<aries_mindworks>  AttributeError: fldPaymentmeth
<aries_mindworks> nonono
<aries_mindworks> the bug is appearing with grid.gfd too, but not in that case
<aries_mindworks> 1) gfcvs grid.gfd
<aries_mindworks> 2) New item
<aries_mindworks> 3)
<aries_mindworks> 3) Edit product (it's ok now)
<aries_mindworks> 4) Edit product again then crashed with the same error msg in the terminal:  python2: Modules/gcmodule.c:275: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.
<aries_mindworks> Aborted
<aries_mindworks> any hint?
*** derek has joined #gnuenterprise
<reinhard> kilo: are you here?
<reinhard> I'm quite lost on this problem - it's a very long time since I looked at gnue-invoice
*** derek has quit IRC
<reinhard> and it seems to be a python internally problem
<reinhard> like a bug in python itself or what
<reinhard> If you get errors similar to:        python: Modules/gcmodule.c:275: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.      Aborted     It means your installment of Python has a corrupted garbage   collector; it is often caused by incorrect or aggressive   optimization during the compilation. Just recompiling a stock   python environment from http://python.org/ usually solves   this.
<reinhard> ... is what google tells me
<aries_mindworks> reinhard: thanks... but... I like the pre-compiled products. The problem is not compiling, but maintaining, because all of the python-dependency should be handled manually... I'm using Fedora, lot of Fedora stuff using python... too many...
*** derek has joined #gnuenterprise
<kilo> reinhard: i am around-ish only
*** klasstek has joined #gnuenterprise
<reinhard> aries_mindworks: so you didn't compile python yourself?
<aries_mindworks> reinhard: it's the Fedora Core 4's "native" python
<aries_mindworks> python-2.4.1-2
<reinhard> :(
<reinhard> doesn't look good
<reinhard> only chance is to try and see under what conditions the error happens
<reinhard> maybe try other backends (sqlite should be pretty painless)
<aries_mindworks> reinhard: how can I help?
<reinhard> other forms like the appserver sample form
<reinhard> bbl
<aries_mindworks> reinhard: I've tried the Org.gfd too, but after some poped up window, it's crashed again :(((
<aries_mindworks> reinhard: it can be the wxpython's fault
<aries_mindworks> reinhard: or something else
<aries_mindworks> reinhard: sorry, with the wx engine in gnue.conf, the problem doesn't appearing
<aries_mindworks> reinhard: just with gtk2
<aries_mindworks> reinhard: hmm
<aries_mindworks> I have to go
<aries_mindworks> bye
*** aries_mindworks has left #gnuenterprise
*** yure has quit IRC
<reinhard> cu all
*** reinhard has quit IRC
*** yure has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** johannesV has quit IRC
*** nenhum___ has joined #gnuenterprise
*** nenhum___ has quit IRC
*** andremachado has joined #gnuenterprise
*** andremachado has quit IRC
*** jamest has quit IRC
*** yure has quit IRC
*** kilo has quit IRC
*** derek has quit IRC
*** dimas has quit IRC
*** klasstek has quit IRC
*** dimas has joined #gnuenterprise
*** jcater_ has joined #gnuenterprise
*** ajmitch has quit IRC
*** sjc has quit IRC
*** derek has joined #gnuenterprise