sjc (~sjc@cpc2-seve3-4-0-cust112.popl.cable.ntl.com) joined #gnuenterprise.
ajmitch_ (~ajmitch@202.89.56.151) joined #gnuenterprise.
bddebppc (~bddebppc@ip68-4-154-50.oc.oc.cox.net) left irc: "Client exiting"
dimas (~ds@195.218.177.46) joined #gnuenterprise.
<ajmitch_> alright, who broke php on ash?
Action: ajmitch_ looks for someone to point the finger at
<ajmitch_> looks like the module isn't even being loaded in the apache config
sjc (~sjc@cpc2-seve3-4-0-cust112.popl.cable.ntl.com) left #gnuenterprise ("Client exiting").
johannesV (~johannes@M1568P009.adsl.highway.telekom.at) joined #gnuenterprise.
thierry (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) left irc: Read error: 110 (Connection timed out)
thierry (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) joined #gnuenterprise.
reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) joined #gnuenterprise.
<ajmitch> hi reinhard
<reinhard> hi ajmitch and ajmitch_
<reinhard> is either of you planning to sid yesterday's releases?
<reinhard> ;)
Action: reinhard remembers the usage of release names as verbs sometime ago in dwn
<reinhard> like "gnome finally sarged"
<ajmitch> yes
<reinhard> great
<ajmitch> if you read logs you may see that I've had some issues getting to the website :)
<reinhard> ah oh
<ajmitch> I might just scp the tarballs from ash :)
<reinhard> http://www.gnuenterprise.org/downloads/current/
<reinhard> could help you too
<reinhard> seems like php is no longer interpreted by the server
<reinhard> but you get the source code instead
<ajmitch> yep
<ajmitch> [23:19:18] <ajmitch_> looks like the module isn't even being loaded in the apache config
<reinhard> well
<ajmitch> oh, I did manage to grab the tarballs earlier.. I just remembered
<ajmitch> but then I got sidetracked by the weekly dotgnu meeting again ;)
<reinhard> i've managed to earn my money w/ computers for 12 years now without even touching apache
<reinhard> i won't touch it now for sure :)
<reinhard> you might want to take the chance to upgrade to current debian policy :)
<reinhard> and also it could be cool if you divided the forms package into the separate ui's
<reinhard> bbl
Nick change: reinhard -> rm-away
<ajmitch> sure :)
greyboy (~pat@62.232.176.2) joined #gnuenterprise.
greyboy (~pat@62.232.176.2) left #gnuenterprise.
dimas (~ds@195.218.177.46) left irc: "Вышел из XChat"
<jcater> bah
<jcater> wonder if mailing list server is down
<jcater> hmmm
<jcater> I haven't gotten commit emails since Wednesday
<jcater> anyone else have that problem?
siesel (~jan@218-162-231-73.HINET-IP.hinet.net) joined #gnuenterprise.
<siesel> yes,  but as the wednesday mail came in yesterday, I think the mail server is just slow. very slow :(
<siesel> btw. jcater, can you enable php on ash again? http://www.gnuenterprise.org/downloads/current.php doesn't work
<siesel> bbl
<rm-away> jcater: i get commit mails with a delay of several days
Nick change: rm-away -> reinhard
scotty (~scotty@CPE-24-167-201-211.wi.rr.com) joined #gnuenterprise.
scotty (~scotty@CPE-24-167-201-211.wi.rr.com) left irc: "games"
chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) got netsplit.
nickr (nick@e-64-35-146-235.empnet.net) got netsplit.
gsoti_away (~gsoti@68.72.160.63) joined #gnuenterprise.
chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) returned to #gnuenterprise.
nickr (nick@e-64-35-146-235.empnet.net) returned to #gnuenterprise.
<dneighbo> you all figure out issue with mail server yet?
Action: dneighbo is thinking it is possible that ash was hit by our power issues
<dneighbo> i.e. the data center is having power issues
<dneighbo> everything is on UPS but our stuff is only on like 8hr UPS instead of 16 to 24 hour UPS
<dneighbo> and not on a generator
<dneighbo> so if the power flips out on the weekend
<dneighbo> the boxes get restarted
<dneighbo> and its possible some services are not starting automagically
<dneighbo> dneighbo@ash:~$ uptime
<dneighbo>  10:03:26 up 3 days, 4 min,  4 users,  load average: 1.57, 0.76, 0.29
<dneighbo> dneighbo@ash:~$ 
<dneighbo> looks like it had problems a few days ago
<jcater> mailing lists are on gnu.org servers
<jcater> siesel: php has been fixed
<jcater> that's one of my pet peeves w/woody apache
<jcater> whenever I install anything new related to apache
<jcater> it comments out mod_php during the DSO scan
<jcater> does it on every machine I have
<reinhard> i have some questions regarding translations
<reinhard> first of all
<reinhard> does anybody remember the rationale behind using textEncoding in gnue.conf instead of just using the user's locale?
<reinhard> (for the encoding of message output)
<reinhard> and second point
<reinhard> i've changed the translation code to use a separate domain per package
<reinhard> so we have translation domains gnue-common, gnue-appserver, gnue-forms, gnue-designer etc.
<reinhard> we basically did agree that we want that
<reinhard> i found a way of finding out the module of the code that called the _() function
<reinhard> and in the _() function i set the domain according to that
<reinhard> any objections against committing this?
<jcater> not from me
<jcater> and I have no idea about textEncoding... I really don't understand how all that works
<wendall911> congrats everybody on the release
<jcater> I just use _() on my text strings
<jcater> and let you guys figure the rest out
<jcater> L)
<jcater> :)
<reinhard> :)
<wendall911> siesel: xcdroast is great...nice gui frontend
bddebian (~bddebian@ip68-4-154-50.oc.oc.cox.net) joined #gnuenterprise.
<dneighbo> jcater: i thought you were using swahili exclusively now?
Nick change: dneighbo -> derek
<siesel> reinhard: commit
<reinhard> siesel: ok (cleaning up before)
<reinhard> do you have any answer to
<reinhard> <reinhard> does anybody remember the rationale behind using textEncoding in gnue.conf instead of just using the user's locale?
<siesel> I can't tell you much about the original rationale, just that there was a formsFontEncoding which developed in the textEncoding setting.
<reinhard> hmmm...
<reinhard> currently, translated strings are encoded over textEncoding
<reinhard> i'd like to change that to encoding according to user's locale
<reinhard> you'd think that would break a lot of stuff?
<siesel> I'm not shure how to do it with locale settings, but IMHO it should be possible to use f.e. textEncoding utf-8 with locale de even if this locale is set to iso8859-1
<siesel> I'm not shure how much stuff that would break, but I would say before we do that we directly use unicode strings instead
<reinhard> if we do unicode strings
<reinhard> we will not even be able to do
<reinhard> print _("Some message")
<siesel> ok. it will raise an UnicodeEncodeError if the string contains character which are not in the current locale
<reinhard> yes exactly
<siesel> but if you move the conversion up into the _() function, you will get the encoding error there, so its just a question of the place
<siesel> conversion like _()   ~   catalog.ugettext(...).encode('myencoding')
<siesel> but we get the same kind of error for all other unicode types, ... so IMHO this is no problem
<siesel> the bigger problem are all other function which still raise errors on unicode values
<reinhard> that, too
<siesel> so splitting up _() into a unicode _() and a normal n_() function would be an option.
<siesel> vice versa is ok too: u_() and _()
<reinhard> not sure how xgettext would get along with that
johannesV (~johannes@M1568P009.adsl.highway.telekom.at) left irc: "Client Exiting"
<siesel> it supported by pygettext and xpot
<siesel> xgettext I dunno
<siesel> but should be possible via the -k command arg
<reinhard> siesel: ok, then i will do it that way
holycow (~rtaylor@24.86.227.162) left irc: Ping timeout: 14400 seconds
<siesel> another option is to use a unicode _() and overwrite the standart "print" command to support unicode strings
<reinhard> i think we can change _() to return unicode when most of the code is unicode safe
<reinhard> until then i think it's best for _() to return local encoding
<reinhard> ok?
<siesel> ok.
<siesel> so you mean using u_() when we need unicode translations?
<reinhard> not sure if we need unicode translations at all
<reinhard> all translations are essentially done to print to the screen somehow
<reinhard> aren't they?
<reinhard> if we need it, we can always introduce u_() later IMHO
<siesel> at the moment we load unicode and encode it to local encoding. this can lead to an information loss
<siesel> so if the output accepts unicode (like gtk2 and qt uidrivers) I prefer to send the unicode directly to them
<reinhard> ah ok
<siesel> this can't should not happen if we have locale = textEncoding = database Encoding
<reinhard> what i am thinking is
<reinhard> if we want to change _() to return unicode at some point
<reinhard> i don't like to make a u_() now and use it all over the code
<reinhard> when in a month or so u_() and _() will be exactly the same
<siesel> But because it has sometimes to be a bit more flexible, I recommend to use unicode as often as possible and differentiate between database text and locale encoding
<siesel> thats the reason, why I put the _() n_() first
<reinhard> yeah
<reinhard> but that would break lots of occurences of _() now
<reinhard> and instead of changing all _() to n_() where it bombs
<reinhard> we could just as well fix the code to accept unicode properly there
<siesel> the best choice depends on the number of places where we need unicode and the places where it crashes something
<reinhard> i think for now i will commit _() returning local encoding
<reinhard> and we go through the code to make it unicode safe
<reinhard> and as soon as we think we're done, we change _() to return unicode
<reinhard> and fix those few (hopefully) points where it still bombs
<siesel> ok, I will create another global function o() or something the like which convert unicode to locale encoding, to make the conversion changes minimal
<siesel> yes, we should go this way
<reinhard> ok
<reinhard> i can do the o() function
<siesel> that would be nice :)
<reinhard>   if isinstance (msg, UnicodeType):
<reinhard>     return msg.encode (encoding)
<reinhard>   else:
<reinhard>     return str (msg)
<reinhard> is that what you were thinking of?
<reinhard> (where encoding is the current locale's encoding
<reinhard> )
<siesel> yes, but remove the str() and encoding could/should be a global variable.
<siesel> then we don't have to do gconfig("textencoding") too often
<reinhard> most instances of gConfig('textEncoding') appear as in foo.encode(gConfig('textEncoding'))
<reinhard> and we will do that as o(foo)
<reinhard> and why remove the str?
<reinhard> ah ok
<reinhard> i understand :)
<siesel> we could even remove the foo.encode and replace it
<siesel> I just dunno if we then should still use o(). or probably oencode(). 
<reinhard> we could even use
<reinhard> s(foo) = foo.encode (encoding)
<reinhard> u(foo) = unicode (foo, encoding)
<reinhard> both with type checks as above
<reinhard> that is, non-string types won't be touched
<reinhard> but still not sure
<reinhard> actually, it's still a hack
<reinhard> bbl
<reinhard> will commit tonight
reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) left irc: "For each complex problem, there is a simple, understandable, obvious, and wrong solution."
<siesel> reinhard: as you read the log :)
<siesel> IMHO we should add a typecheck but comment it out for the production release
<siesel> and add a counter which tells how many conversion were done
<siesel> but thats just ideas
<siesel> time to sleep
siesel (~jan@218-162-231-73.HINET-IP.hinet.net) left irc: "Client exiting"
sjc (~sjc@cpc2-seve3-4-0-cust112.popl.cable.ntl.com) joined #gnuenterprise.
Nick change: bddebian -> bddeb_away
derek (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: Read error: 104 (Connection reset by peer)
su (~su@p50865323.dip0.t-ipconnect.de) joined #gnuenterprise.
derek (~dneighbo@ip68-109-180-32.ph.ph.cox.net) joined #gnuenterprise.
su (~su@p50865323.dip0.t-ipconnect.de) left #gnuenterprise.
dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) joined #gnuenterprise.
reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) joined #gnuenterprise.
derek (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: Read error: 110 (Connection timed out)
sjc (~sjc@cpc2-seve3-4-0-cust112.popl.cable.ntl.com) left #gnuenterprise ("Client exiting").
Nick change: bddeb_away -> bddebian
jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) left irc: Remote closed the connection
jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) joined #gnuenterprise.
jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) left irc: Client Quit
jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) joined #gnuenterprise.
jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) got netsplit.
jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) got lost in the net-split.
jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) joined #gnuenterprise.
<jcater> reinhard: you here?
<jcater> I saw some commits where you removed the executable flag on some files in CVS
<jcater> how did you do that?
<jcater> CVS=SVN
rdean (~rdean@c-66-177-153-39.se.client2.attbi.com) joined #gnuenterprise.
<reinhard> jcater: svn propdel svn:executable <filename>
<jcater> thanks
<reinhard> hmm
<reinhard> it's again past my bedtime
<reinhard> i think i'll commit tomorrow
<reinhard> still got to fix the install procedure for new po schema
<reinhard> night
reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) left irc: "There are two kinds of people: those who divide people into two kinds, and those who don't."
reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) joined #gnuenterprise.
reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) left irc: Remote closed the connection
holycow (~rtaylor@24.86.227.162) joined #gnuenterprise.
_holycow_ (~rtaylor@24.86.227.162) joined #gnuenterprise.
holycow (~rtaylor@24.86.227.162) left irc: Read error: 60 (Operation timed out)
holycow (~rtaylor@24.86.227.162) joined #gnuenterprise.
rdean (~rdean@c-66-177-153-39.se.client2.attbi.com) left irc: "Leaving"
_holycow_ (~rtaylor@24.86.227.162) left irc: Read error: 110 (Connection timed out)
_holycow_ (~rtaylor@24.86.227.162) joined #gnuenterprise.
holycow (~rtaylor@24.86.227.162) left irc: Read error: 60 (Operation timed out)
gsoti_away (~gsoti@68.72.160.63) left #gnuenterprise.
Nick change: _holycow_ -> holycow
--- Sun Mar  7 2004