lupo__ (lupo@p5085F96B.dip.t-dialin.net) left irc: Remote closed the connection Nick change: SachaS -> SachaAway reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) joined #gnuenterprise. jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) left irc: "Client exiting" btami (~tamas@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. good morning reinhard: you here? btami: yes good morning i'v tried a new setup.py yesterday i have 2 notices it depends on setup-cvs-py now can i suggest to change gsscvs to gnue-schema in build_files() ? and put that block into an if sys.platform != "win32": on gsscvs vs. gnue-schema gnue-schema doesn't exist either if setup-cvs.py isn't run however if we get rid of the gnue-schema.in -> gnue-schema step we could use gnue-schema to generate the man page on win32 doesn't setup-cvs-win.py generate gsscvs? setup-cvs-win.py is not a general/usable thing it's working only with ntfs5 oh ah ok i never use it but generally generating manpages with gnue-xxxx --generate-manpage on windows works, doesn't it? yes ok so if we can provide a ready-to-go gnue-schema instead of a gnue-schema.in we have won thierry (~thierry@musashi.xtensive.com) joined #gnuenterprise. actually i need your help for that if you look at setup.py now morning all morning thierry btami: label _build_gnue_env morning reinhard there's only stuff left for windows and all of them is actually fixed (it will be always the same) the question ist does that have to be in the script reinhard: wait a min, have to update cvs here or can it be put somewhere in BaseApp.py or like that reinhard: i'm really not a setup expert, just testing it, and reporting what i get so, gnue-schema *do* exist when build_files calls it instead os gsscvs s/os/of currently, no gnue-schema is generated from gnue-schema.in at a later point this generation was once needed because gnue-schema contained some paths dependent on installation target directory but now gnue-schema doesn't contain variable content at all but it contains the stuff for windows that is defined in _build_gnue_env i thought maybe you can explain what those lines are for reinhard: i'v deleted gnue-schema before i run setup.py install and it's created before build_file build_files had called sorry, but i cant explain "those" lines :) btami: you're right gnue-schema gets generated _before_ build_files however i want to get rid of the need to generate gnue-schema at all anyhow, i think man-page generation hes little sense on win32 well yes and no i'm sure there is a "man" for windows from cygwin and probably others instead i like to see some pdf docs for appserver :) yes, but it's not a built in tool i'm not sure i like to have pdf docs in our release .zip's and generally we want to cut off dependacies but there are always current versions of the docs as .pdf on the web hmm pdfs would blow up the .zip's (IIRC) forms and others pot the into the zip release in terms of megabytes put do they? ok yes SachaS (~Sacha@dialup-196-220.wasp.net.au) joined #gnuenterprise. we should at least be consistent then :) :) SachaS (~Sacha@dialup-196-220.wasp.net.au) left #gnuenterprise ("Client exiting"). back to setup.py, my initial complaint was please setup.py not depend on setup-cvs.py koz someone wants to use setup.py install with snapshots or on win32 yes i will do that thanks my plans are to have a "final" gnue-schema i cvs and release anyway (instead of gnue-schema.in) and then the problem will go away anyway about man-pages/cygwin if you don't like pdf's in release i don't like package cygwin into a setup.exe too :) setup.exe's are about 15 Mb now wx is 6 Mb itself maybe we can do a gnue-docs(only pdf's) package later when they are mature/big enough Nick change: btami -> btami_away wendall911 (~wendallc@198.31.172.218) left irc: ""got to sleep"" thierry (~thierry@musashi.xtensive.com) left irc: Read error: 110 (Connection timed out) thierry (~thierry@musashi.xtensive.com) joined #gnuenterprise. johannesX (~johannes@M1264P006.adsl.highway.telekom.at) joined #gnuenterprise. Nick change: btami_away -> btami btami: two questions 1. do you usually generate the windows .exe files, or does somebody else make them 2. what do i need to install on windows to test setup.py on win32 myself? if i can get gnue to run on windows i would try to break it less often 1. yes, it's me 2. http://mail.gnu.org/archive/html/gnue/2003-08/msg00005.html you don't need all dbdrivers, and pil,reportlab for a basic install thanks how are the .exe's created? with mc'milann and inno are they created under linux or under windows? under windows ok thanks a lot inno is a win32 stuff you can find the required hook files for mc'millan in gnue-designer's packaging subdir i'm wrong, they are in gnue-common hmm, cvs's packaging dirs needs some cleanup... reinhard: http://www.gnuenterprise.org/~jan/Install_GNUe-CVS-Snapshot_on_Win32_mini-HOWTO.html btami: thanks oh hmmm as long as gnue-common is not completely installed gnue-schema doesn't run because pythonpath isn't set hmm i have to set PYTHONPATH before calling it i think dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) joined #gnuenterprise. dneighbo_ (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: Read error: 110 (Connection timed out) marcello (~marcello@adsl-ull-145-101.42-151.net24.it) joined #gnuenterprise. jamest (~jamest@adsl-66-142-212-57.dsl.tpkaks.swbell.net) joined #gnuenterprise. marcello (~marcello@adsl-ull-145-101.42-151.net24.it) left irc: Remote closed the connection dimas_ (~dimas@195.218.177.46) joined #gnuenterprise. lupo__ (lupo@pD9E68622.dip.t-dialin.net) joined #gnuenterprise. ToyMan (~stuq@smtp.dstoys.com) joined #gnuenterprise. morning all dimas (~dimas@195.218.177.46) left irc: Read error: 110 (Connection timed out) morning bbl jamest (~jamest@adsl-66-142-212-57.dsl.tpkaks.swbell.net) left irc: "Client exiting" btami: if you have 5 minutes could you please test if setup.py works again under windows? i've changed it to generate man pages only on posix systems trying... there is a typo in gnue-schema line #29 if os.eviron the setup.py install worked well but in gnue.pth contains c:\\python23\\lib\\site-packages ? oh so it did generate a gnue.pth for you? ah yeah i know why what does import sys sys.path give you on windows? hm it's to long to type here but c:\\python23\\lib\\site-packages is in the list jamest (~jamest@gw.math.ksu.edu) joined #gnuenterprise. is it the same case? C:\\Python23\\lib\\site-packages is this what sys.path contains or what gnue.pth contains? it's from sys.path gnue.pth contains: c:\\python23\\Lib\site-packages yes hmmm they arn't == does gnue.pth matter? i mean no does python give an error message or something? or would you think we can leave it that way i used setup.py install without any parameters always in that case gnue.pth has no sense ok i fixed the typo in gnue-schema ok, thanks did you try if gnue-schema works when installed with this new setup.py? ToyMan (~stuq@smtp.dstoys.com) left irc: Read error: 104 (Connection reset by peer) trying... gnue-schema is OK but what is installer dir in common ? :) cool thanks that is something old nothig i did i'm not guilty !! setup installs it too ;-) oh maybe it wasn't before ToyMan (~stuq@smtp.dstoys.com) joined #gnuenterprise. ok fixed that thanks reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) left irc: Read error: 104 (Connection reset by peer) reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) joined #gnuenterprise. reinhard: thanks for adjusting the setup for win32 too is it correct that we actually would only need to install the *.mo files? oh got disconnected ok fixed that thanks you notice a lot of things :) btw as we clean up what gets installed is it correct that we actually would only need to install the *.mo files? (in "translations") yes ok are .mo files platform dependent? no btw. can you change all png,bmp files in image dirs to binary in CVS ? i'v forgot how jcater did it before hmmm... have to look up how that works and for .mo files too :) wincvs can download them correct only they are marked as binary don't find anything in my cvs man page maybe we ask jcater or jamest nevermind, i will dig into the irc archive anyhow, the new setup.py is great now! Nick change: SachaAway -> SachaS hi SachaS hi btami were you lucky with appserver on windows ... eg ie and the webfrontend? SachaS: you win, the IE6 can't open sample.html with webfrontend but mozilla is OK ask what? ah, how to turn to binary SachaS: with appserver running on XP i don't recall how to do it either btami. ok. hallo reinhard jamest: has there be any talk/decision about whether or not to put generated files in cvs? SachaS: hi marcello (~marcello@adsl-ull-247-205.42-151.net24.it) joined #gnuenterprise. co_alim (~co_alim@202.73.120.39) joined #gnuenterprise. btami (~tamas@ip102-205.ktv.tiszanet.hu) left irc: "going home" what kind of generated files like *.mo files (binary, generated from *.po files) pdf or text format of documentation originally written in other formats index.txt and index.html of technotes sql scripts generated with gnue-schema from .gsd files manpages generated with --generate-manpage and maybe even some others i don't recall now marcello (~marcello@adsl-ull-247-205.42-151.net24.it) left irc: "Leaving" dsmith (~dsmith@mail.actron.com) joined #gnuenterprise. reinhard: i believe we generally don't put generated files in cvs normally that would be the rule however it seems we have some as bins play havoc w/ cvs which ones? technotes/index.* is in cvs and the .mo files are, too :( [09:53] Last message repeated 1 time(s). i wonder if index.html is an accident er, index.* and I know nothing about mo files they're part of i18n right? yes the problem is all those files need special tools to generate them some of the tools are not even available on non-posix systems (read: windows) all those files go in distributions ah damn but on windows nobody could generate those files if he downloads cvs like btami then we'd have to include them wouldn't we i'm torn so they more or less fall into same category as .png files a necessary evil it is against my strongest principles to do something that is against the rules just to support a broken os i'm 100% against anything that would make btami not want to maintain the windows port :) yeah that's the other side :) in appserver we've written makefiles to generate those files so at least they can easily be regenerated which would require btami to have cygwin installed right? which would require btami to trust that files are kept current in cvs and would make it easier to actually keep them current because we jsut have to type "make" i wish we were in svn svn? i *think* it provides a precommit hook that might be able to automate that ah subversion yeah however i don't think it ready for prime time use it's still a little odd for me i run private svn server instead of cvs now bbiab co_alim (~co_alim@202.73.120.39) left irc: jbailey (~jbailey@atlas.fundserv.com) joined #gnuenterprise. jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) joined #gnuenterprise. jbailey: can you please try to sid gnue-common? and if there's anything we can improve in setup.py please tell me btw jamest/jcater: the need to generate scripts at install time is gone reinhard: What's the prefered way to set it to look at /etc/gnue for things? reinhard: cool is this for all packages? or just common/appserver? jbailey: ./setup.py install --prefix=/usr --root=.... you can also do --install-config=/etc but if prefix = /usr then it defaults to /etc if prefix = /opt/gnue then it defaults to /etc/opt/gnue otherwise it defaults to $prefix/etc Cool. I tend to do /etc/gnue, so I'll add the --install-config ok good idea currently it installes the samples.*.conf there i'm not sure if that is wise Mmm.. I will probably put something in to move them to /usr/share/gnue-common/examples at some point. That's what Debian prefers. i even would have believed /usr/share/doc/gnue-common i always found some example config files there in the past jamest: principially for all packages however only common currently _does_ provide non-generated scripts cool I guess the question is should those be installed by default. the other scripts still get generated but the wouldn't need to be that is, you could look at gnue-common/scripts/gnue-schema and change the scripts in the other packages accordingly jbailey: you probably have to talk to jamest/jcater about wheter the config files should be installed by default i know gnue doesn't run without connections.conf but it works without gnue.conf at least appserver and commmon do i thought we fixed the connections.conf bug I think jamest fixed that to shut me up about 2 weeks ago... will now it issues a message IMHO Action: jamest recalls hunting it down s/IMHO/IIRC/ it now issues a message, yes which is better than traceback so probably we should install no connections.conf by default becuase the correct connections.conf can't be figured out clearly IMHO bbl must go cook dinner for kids jbailey: from INSTALL for packagers we recommend (POSIX only) ./setup.py install --prefix=/usr --install-lib=/usr/lib/gnue --root=... Nice! I'll look at that in an hour or so. jbailey: i changed the default from /etc to /etc/gnue if prefix is /usr man reinhard, you're trying really, really hard to make us not hate distutils aren't you *lol* my primary goal is to make users not hate gnue :) GACK!!!!!!!!!! users!!!!!!!!! Action: jamest grabs his bat where!?!?!?!?!? be bewwy bewwy quiet... we're hunting wusers.... silly gnuers ooo, a usah jamest: grab the bat Action: jcater dives on chilly to hold him down Action: chillywilly squirms away and waddles off into the sunset Action: jamest starts wailing awaay at the uzan w/ the bat oooo, wait. is chilly a uzah? Action: chillywilly is a nuisance ok, i'll go for that Action: jamest puts the bat down dimas_ (~dimas@195.218.177.46) left irc: Read error: 110 (Connection timed out) Action: Vee2d2 whistles http://www.dilbert.com/comics/dilbert/archive/dilbert-20030928.html that's pretty funny rofl hehe I particularly like the "bald guys" comment cause you're folliclely challenged? Action: chillywilly ducks btami (~btami@3e70d836.dialin.enternet.hu) joined #gnuenterprise. hi all chillywilly: that it happened *9* times.. ;) hi btami hello reinhard Vee2d2: suuuure ;) reinhard: i'm absolutely agree with you to not have generated files in CVS and no need to keep that files just besause me i have a debian box on my office so i can run tools needed for releases I missed the conversation what files are these? i'v just wanted to let people run setup.py install from snapshots without setup-cvs.py jcater: docs,*.po,man files etc. ah I could modify my nightly snapshot scripts to run setup-cvs.py to do generate those files before creating the .zip/.tgz files if that would be beneficial cool jcater: would it help to have kind of common infrastructure there ? like just the need to call "make" in the root directory of each project or "autogen.sh" or something like that setup-cvs.py could work just as well I was thinking about adding a --defaults option to setup-cvs.py so it didn't ask any questions not sure if that is the same target (just used the default answers) Action: jcater hasn't read the backlogs setup-cvs.py creates a runtime environment you are right i.e. it creates a .cvsdevelbase, a ~/gnue and such things I'm not thinking right I blame it on the users what we talk about is things like generate-technote-index or creating text and pdf docs from source files (be they texinfo or docbook) dsmith (~dsmith@mail.actron.com) left irc: "Client exiting" btami (~btami@3e70d836.dialin.enternet.hu) left irc: mouns (mouns@kali.mouns.org) joined #gnuenterprise. btami (~btami@ngprs.pannongsm.hu) joined #gnuenterprise. jamest/jcater: if i would define a "setup" module for gnue that all packages could use to have a simple setup.py would that be "gnue.setup" or rather "gnue.common.setup" ? or would it even be "gnue.common.GSetup"? hmmm it would not be used by the applications themselves only the setup.py scripts would import it are you sure? about what? as i use the gnue setup.py for a side project that is based on common it would rock if i could use a common module to simplfy that setup.py too I'd go w/gnue.common.setup, regardless that fits into the naming/structuring theme I moved common to not long agao jamest: please look at the current version of setup.py for common and try to find this line # ============================================================================= # No changes should be required below this line # ============================================================================= i envision setup.py of the tools (gnue-forms, gnue-reports, jamest's-external-prog) to end at that points with about the same things above jcater: please note it will be a module, not a package that is the file would be in src/ and be named setup.py jcater: please note it will be a module, not a package what do you mean? a module is a .py file a package is a directory containing __init__.py was my understanding so "apps" is a package for example and GBaseApp is a module our modules seem to generally only contain a single class but that need not be hmm I've been trying to eliminate single files from gnue-common's root simply because of the breadth of things common does it was getting overwhelming yeah on the other hand i'm not sure how good it would be to have from gnue.common.setup.GSetup import GSetup OTOH i could in setup/__init__.py simply do that's why we usually include from "GSetup import *" in __init__.py from GSetup import * eh *lol*