mdupont (mdupont@p5080E928.dip0.t-ipconnect.de) joined #gnuenterprise. mdupont: hi moin ello sirs ajmitch: hi there good evening dtm hey ajmitch Action: mdupont makes a kawffee hmmm nice fresh pressed coffee Action: Vee2d2 makes preperations to hijack said beverage. I want coffee steal one for me too Vee2d2 ;) dtm (~dtm@r1.txwifi.com) got netsplit. Vee2d2 (~vin@c66.169.136.41.ts46v-07.otn-c1.ftwrth.tx.charter.com) got netsplit. tripz__ (~ville@as13-5-6.ld.bonet.se) got netsplit. nickr (nick@e-64-35-146-235.empnet.net) got netsplit. jcater (~jcater@66.61.71.147) got netsplit. dimas_ (~dimas@195.218.177.46) got netsplit. ajmitch (~ajmitch@wlg1-port4.jetstart.maxnet.co.nz) got netsplit. chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) got netsplit. mdupont (mdupont@p5080E928.dip0.t-ipconnect.de) got netsplit. dcmwai (~dcmwai@219.95.164.179) got netsplit. LuftHans (~lufthans@wsip-68-107-221-207.ph.ph.cox.net) got netsplit. havoc (~havoc@CPE-65-31-122-112.wi.rr.com) got netsplit. Stoke (~stoker@dpvc-141-149-254-50.buff.east.verizon.net) got netsplit. SachaS (~sacha@online.havanawave.com) got netsplit. mdupont (mdupont@p5080E928.dip0.t-ipconnect.de) returned to #gnuenterprise. dcmwai (~dcmwai@219.95.164.179) returned to #gnuenterprise. dimas_ (~dimas@195.218.177.46) returned to #gnuenterprise. jcater (~jcater@66.61.71.147) returned to #gnuenterprise. chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) returned to #gnuenterprise. ajmitch (~ajmitch@wlg1-port4.jetstart.maxnet.co.nz) returned to #gnuenterprise. LuftHans (~lufthans@wsip-68-107-221-207.ph.ph.cox.net) returned to #gnuenterprise. nickr (nick@e-64-35-146-235.empnet.net) returned to #gnuenterprise. Stoke (~stoker@dpvc-141-149-254-50.buff.east.verizon.net) returned to #gnuenterprise. SachaS (~sacha@online.havanawave.com) returned to #gnuenterprise. havoc (~havoc@CPE-65-31-122-112.wi.rr.com) returned to #gnuenterprise. hey mdupont you still here? you ever use ModPerl::Registry? tripz__ (~ville@as13-5-6.ld.bonet.se) got lost in the net-split. Vee2d2 (~vin@c66.169.136.41.ts46v-07.otn-c1.ftwrth.tx.charter.com) got lost in the net-split. dtm (~dtm@r1.txwifi.com) got lost in the net-split. dtm (~dtm@r1.txwifi.com) joined #gnuenterprise. Vee2d2 (~vin@c66.169.136.41.ts46v-07.otn-c1.ftwrth.tx.charter.com) joined #gnuenterprise. tripz__ (~ville@as13-5-6.ld.bonet.se) joined #gnuenterprise. jcater (~jcater@66.61.71.147) got netsplit. nickr (nick@e-64-35-146-235.empnet.net) got netsplit. chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) got netsplit. ajmitch (~ajmitch@wlg1-port4.jetstart.maxnet.co.nz) got netsplit. dimas_ (~dimas@195.218.177.46) got netsplit. Stoke (~stoker@dpvc-141-149-254-50.buff.east.verizon.net) got netsplit. LuftHans (~lufthans@wsip-68-107-221-207.ph.ph.cox.net) got netsplit. dcmwai (~dcmwai@219.95.164.179) got netsplit. SachaS (~sacha@online.havanawave.com) got netsplit. havoc (~havoc@CPE-65-31-122-112.wi.rr.com) got netsplit. mdupont (mdupont@p5080E928.dip0.t-ipconnect.de) got netsplit. Vee2d2 (~vin@c66.169.136.41.ts46v-07.otn-c1.ftwrth.tx.charter.com) got netsplit. dtm (~dtm@r1.txwifi.com) got netsplit. tripz__ (~ville@as13-5-6.ld.bonet.se) got netsplit. dtm (~dtm@r1.txwifi.com) returned to #gnuenterprise. Vee2d2 (~vin@c66.169.136.41.ts46v-07.otn-c1.ftwrth.tx.charter.com) returned to #gnuenterprise. tripz__ (~ville@as13-5-6.ld.bonet.se) returned to #gnuenterprise. mdupont (mdupont@p5080E928.dip0.t-ipconnect.de) returned to #gnuenterprise. dcmwai (~dcmwai@219.95.164.179) returned to #gnuenterprise. dimas_ (~dimas@195.218.177.46) returned to #gnuenterprise. jcater (~jcater@66.61.71.147) returned to #gnuenterprise. chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) returned to #gnuenterprise. ajmitch (~ajmitch@wlg1-port4.jetstart.maxnet.co.nz) returned to #gnuenterprise. LuftHans (~lufthans@wsip-68-107-221-207.ph.ph.cox.net) returned to #gnuenterprise. nickr (nick@e-64-35-146-235.empnet.net) returned to #gnuenterprise. Stoke (~stoker@dpvc-141-149-254-50.buff.east.verizon.net) returned to #gnuenterprise. SachaS (~sacha@online.havanawave.com) returned to #gnuenterprise. havoc (~havoc@CPE-65-31-122-112.wi.rr.com) returned to #gnuenterprise. I guess there's nothing real compilcated about it just compiles your script in each apache child and keeps it around reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) joined #gnuenterprise. hi reinhard i am really looking forward to see you driving gnue-appserver :) The argument against using an operator for other than its primary purpose strikes me the same as the old argument that you shouldn't have sex for other than procreational purposes. Sometimes side effects are more enjoyable than the originally intended effect. -- Larry Wall ;P yeah... nothing like aids, herpes, the clap etc... i.e. not all side effects are enjoyable and often times they are deadly haha I saw no mention of promiscuity in there dcmwai er, derek just that a lot of people have sex because it is enjoyable and not to "procreate" Action: chillywilly ruins derek's joke ;P hi SachaS hi reinhard. Nick change: mdupont -> md-work l8ter btami (~tamas@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. good morning good morning btami reinahrd: i assume procedures have high priorities on your gnue-appserver list once the installation rewrite settles down. mouns (mouns@kali.mouns.org) joined #gnuenterprise. dimas__ (~dimas@195.218.177.46) joined #gnuenterprise. dimas_ (~dimas@195.218.177.46) left irc: Read error: 104 (Connection reset by peer) thierry (~thierry@musashi.xtensive.com) joined #gnuenterprise. morning all hi thierry hi btami ajmitch (~ajmitch@wlg1-port4.jetstart.maxnet.co.nz) left irc: "I like core dumps" Arturas (~arturas@gsk.vtu.lt) joined #gnuenterprise. Hello hello Action: dcmwai is away: Dinner, Let get food and Go home :) SachaS: yes they have reinhard: btw. what is your vision about maintaining procedures? through designer? in 2-tier they are in a separate dir, and that's easy but in n they are stored in a databas if i understand correct btami: that is correct i guess procedures will be maintained through a form with a multi line edit like we already have a form for class definitions gnue-forms supports a "vi" mode in multiline edits, doesn't it? ;-) yes :9 dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) joined #gnuenterprise. maybe we can enhance the multiline edit with scintilla, like jcater did it with trigger editor in designer ajmitch (~ajmitch@wlg1-port31.jetstart.maxnet.co.nz) joined #gnuenterprise. derek (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: Read error: 110 (Connection timed out) SachaS: are you here? reinhard: yes you confirmed appserver working on unstable did you test appserver with forms? Action: dcmwai is back (gone 01:30:05) reinahrd: yes I did test appserver with gnue-forms on debian unstable from cvs-install do you have this still installed there? yes i have. and you have gnue-forms on the same machine? yes i have. did check webforms on ie on win xp which failed and webforms on mozilla on win xp which succeeded bigbrother joined #gnuenterprise. broman (~broman@apollo.gti.net) joined #gnuenterprise. lupo__ (lupo@pD9E686A9.dip.t-dialin.net) joined #gnuenterprise. hi lup__ lupo__ are you the one from north of Sydney? SachaS: a last question can you confirm that querying all records works when one of the recors has a blank field (e.g. zip is not filled out) let me check still OK with zip field being empty in one record of the address_person table thanks SachaS I just found it this second why oh why do i have to be named "Müller" broman (~broman@apollo.gti.net) got netsplit. pw_xmlrpc doesn't work with 8 bit characters ouch but at least now i can confirm that the debs are ok :) broman (~broman@apollo.gti.net) returned to #gnuenterprise. cool well at least forms was talking with siesel this morning. of application integration with a possible scenario: app-xyz <-> gnue-integrator <-> gnue-appserver with a message oriented middleware aware gnue-common will further elaborate with siesel ok i have too little experience in such things dont hink I have more :) ToyMan (~stuq@smtp.dstoys.com) joined #gnuenterprise. Arturas (~arturas@gsk.vtu.lt) left irc: "Bye :)" R45 (~rastabeen@cuscon6873.tstt.net.tt) joined #gnuenterprise. johannesX (~johannes@M1264P006.adsl.highway.telekom.at) joined #gnuenterprise. morning all hey morning all dcmwai (~dcmwai@219.95.164.179) left irc: "Client exiting" dsmith (~dsmith@mail.actron.com) joined #gnuenterprise. johannesX (~johannes@M1264P006.adsl.highway.telekom.at) left irc: "Client Exiting" johannesX (~johannes@M1264P006.adsl.highway.telekom.at) joined #gnuenterprise. jrobiez (~jrobiez@nas-p19-3-62-147-222-225.dial.proxad.net) joined #gnuenterprise. jbailey (~jbailey@CPE0060082df811-CM014260028338.cpe.net.cable.rogers.com) joined #gnuenterprise. stuq_ (~stuq@smtp.dstoys.com) joined #gnuenterprise. ToyMan (~stuq@smtp.dstoys.com) left irc: Read error: 104 (Connection reset by peer) bbl dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: "Bye Bye" jcater (~jcater@66.61.71.147) left irc: Read error: 104 (Connection reset by peer) jbailey (~jbailey@CPE0060082df811-CM014260028338.cpe.net.cable.rogers.com) left irc: "Client exiting" ajmitch (~ajmitch@wlg1-port31.jetstart.maxnet.co.nz) left irc: Read error: 110 (Connection timed out) ajmitch (~ajmitch@wlg1-port19.jetstart.maxnet.co.nz) joined #gnuenterprise. jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) joined #gnuenterprise. jbailey (~jbailey@atlas.fundserv.com) joined #gnuenterprise. Nick change: SachaS -> SachaZzz hi jbailey Heya reinhard. gnue forms debs are working w00t! did I send you the other two as well? Actaully, never mind. gnue designer is uninstallable due to a typo in an unused part of the code :( If forms works, the others will work. i fixed designer in cvs and committed a few hours ago didn't get reports Thanks, I'll update designer. postinstall bombed when trying to compile the python files Ah, sorry. I hadn't even tried to install it. I just made sure that the postinst had generated all the right commands. =) you're not the one to have to excuse for that :) Well, as a DD I'm supposed to test before uploading. After all this does designer seems to work right, or should I send it to you again? if you can send me again i can test however i can't imagine that it won't work when install runs through without errors oh forgot something the binary forms package is named gnue-forms-wxgtk Yes. I think that's right. but it contains *all* supported ui frontends Last I checked, they couldn't be easily separated. (even win32) sure but now my question is the wxgtk frontend depends on libwxgtk2.4-python other fronends depend on other libs should we add libwxgtk2.4-python to the Depends: or not (I vote yes: then at least _one_ frontend works) Isn't it there already? Hmm why not call it gnue-forms for now and depend on wxgtk and suggest the others? Apparently it's not there. If you apt-get install gnue-forms, it will install gnue-forms-wxgtk instead. when there are other modules, if you try to install gnue-forms, it'll list all of the different front ends. that's nice Huh, for some reason it's not. I thought -common depended on it. no thanks god reinhard: i'v fixed a typo in GBaseApp.py (gettext related) because libwxgtk depends on a full x install and i'd hate to have appserver depend on X btami: yes saw it, thanks if it counts, all tools needs repackaging(debs) it was my fault IIRC as soon as all debs work i am for releasing 0.5.2 and repackage properly ok I am ok with releasing 0.5.2 as well I have some changes to common's datasources I haven't committed yet and I think a release would be nice before I do so yes cool jcater: please don't forget to do something with designer's startup bug on win32 bleh I planned to gnue this past weekend but painted instead brb testing reports deb :) reports source files contain syntax errors :( I can fix those in a few there's a lot of partial work in reports right now in modules that aren't part of final package it's all in the Universal driver there are such modules? yes, like, um, the Universal module :) hmmm the new setup.py installs all modules that it finds under src/ yeah well, I'll remove syntax errors from the file s it eliminates the need to list all modules which was a PITA before because I'd rather leave setup.py the way you made it i actually thought (hoped) it's a good idea I think it is ok :) which report filter should work without dependencies? (except raw) is there one? reinhard: Maybe add a --modules= hack to setup.py that allows you to override the modules list? yes jbailey: you wouldn't want to do that btami's stuff Action: jcater forgets the name but part of SimpleTabulation iirc tabulator common for example has like 100 modules yeah ok thanks siesel (~jan@xdsl-213-196-209-199.netcologne.de) joined #gnuenterprise. btami: which jamest and I are both using :) nice to hear :) hey siesel hi pw-xmlrpc doesn't like me personally :) like DCL me before btami: it's not a joke No, it likes Reinhard, it just don't like your family ;) i know siesel: yes, exactly :) is there something we can do about it? seems that its connected with missing unicode support because M\x??ller is not valid utf-8, so it could raise an error during message parsing It would be possible to add encode/decode functions to the pw_xmlrpc wrapper, but that's not the way I would like it. jbailey: designer debs ok anyone know how to add a sequence to a WO in dcl? nevermind! reinhard: Tx. Blargh. I need dcl to be a real product so I can switch to it. There are little things I wish rt could do that I know I could get derek to just put in. =) btami (~tamas@ip102-205.ktv.tiszanet.hu) left irc: jbailey: oh, another point i've forgot there is a /usr/share/doc/gnue-forms and a /usr/share/doc/gnue-forms-wxgtk i'm not sure both should exist Oh hmm. Thanks for the note. jbailey: just a question: why do you not just provide a gnue-forms.deb if all uidriver are included. And create dummy packages for wxgtk and gtk2, which get recommended by gnue-forms and draw the dependencies? siesel: Waste of space. siesel: The right solution is that gnue should cope with only certain modules being there, that way it can be used on small systems. i agree 100% with jbailey here (I'm thinking like a Sharp Zaurus PDA or something like that with a limited amount of space available) does it not now? No, when I pulled in only one set of files, it complained about the others not being there. but gnue-forms-wxgtk and gnue-forms-gtk2 would share 99% of the code, and I think installing both should be possible without overhead which one set of files? siesel: On a palmtop, several K might make a difference. jcater: Been 'bout a year since I last tried. I'd prefer not to do anything that causes the FTP masters work at this point, though. They haven't been processing overrides changes for like 2 weeks. So it would risk gnue being in sarge. (I found this out last night. So it's entirely possible that they simply won't accept appserver) i agree that we should leave it the way it is for sarge and then for the next round we should have gnue-forms-base gnue-forms-wxgtk gnue-forms-qut gnue-forms-qu err gnue-forms-qt gnue-forms-gtk2 and the same game probably for gnue-common gnue-dbdriver-psycopg I'm fine with waiting gnue-dbdriver-mysql etc I was just confused as to why he was saying it wouldn't work now as the various uidrivers don't depend on each other but that's another conversation for another day Yup. It'll also marge forms updates less fragile to modules in development. s/marge/make/ I couldn't packaging for a while becaue the curses FE wouldn't compile. (That was when I tried ripping it out, and found that I couldn't) ok, that means that although gtk2 is working, faster (esp. for palmtops), and all dependencies are in sarge, it would only be accessible through the old style gnue-forms-wxgtk now. but if this is the only way to get along with debian ftp masters its ok for me. for sarge yes like it seems Just for now. ah yes and Would it be possible to add a comment to README.Debian, that all uidrivers are included in gnue-forms-wxgtk, and its just a problem of missing dependencies? when i tested forms on my testing machine (pentium 200) i thought we really need to fix curses driver :) siesel: No - I'd get beaten for that, I think. siesel: not sure if that is a good idea siesel: The answer would be to provide the missing deps, rename the package and deal. Action: siesel hate politics pepole _using_ the gtk2 frontend that is in gnue-forms-wxgtk If I could reasonably just include wxgtk in the package for now, I'd do it. siesel: It's not politics so much as the desire to release Debian. would get a bad surprise in the next update just joking ;) when -wxgtk _really_ contains only wxgtk So I shouldn't give up on Good Sense to work around annoyances such as users. reinhard: People are doing that? Boot to the head for them. reinhard: But I don't mind leaving it in for now. jbailey: is there no way to remove the other drivers? jbailey: if we put a note in README.Debian we would provoke it that's what i was trying to say reinhard: ah, yes. Phone call, bbias. It should be just rm /usr/lib/gnue/python/gnue/src/uidrivers/gtk2|ncurses|qt |win32 :) yeah, we really should remove the win32 stuff, or possibly gnue-forms moves into non-free ;) roflmao siesel: It would be contrib, but yeah. jrobiez (~jrobiez@nas-p19-3-62-147-222-225.dial.proxad.net) left irc: "Client exiting" Actually, it would probably be an RC bug with instructions to get rid of it. reinhard: what about adding --with-win32 --with-XXX targets to gnue-forms setup.py? Nick change: stuq_ -> ToyMan that could be done quite fast, and would solve later override problems. jbailey: deleting gtk2, curses, qt and win32 from the dbdriver directory would work for now can you do that in your build script? you mean uidriver directory :) err yes uidriver:) wendall911 (~wendallc@198.31.172.218) joined #gnuenterprise. bbl putting kids to bed jamest (~jamest@adsl-65-71-168-178.dsl.tpkaks.swbell.net) joined #gnuenterprise. back hi jamest Nick change: md-work -> mdupont hi all jamest & jcater if you have a minute i have some questions wrt setup/packaging thierry (~thierry@musashi.xtensive.com) left irc: Read error: 110 (Connection timed out) thierry (~thierry@musashi.xtensive.com) joined #gnuenterprise. reinhard: such as? R45 (~rastabeen@cuscon6873.tstt.net.tt) left irc: first man pages jbailey found out that in the whole process of checking out cvs, running setup.py install (with --root) and building the debian package there is not a single point where the scripts are functional enough to run --generate-manpage i see 3 possibilities a) put the manpage in cvs ignoring the fact that it's actually a generated file b) put the manpage not in cvs but in release tarballs and make the possibility to generate tarballs and installs from cvs dependent on setup-cvs.py being run before (so we can use gfcvs --generate-manpage) c) let debian create the manpage in the postinstall script former setup.py did b) but this actually makes it impossible to do debian packages for cvs versions in an automated way well, I'm not too fond of debian packages for cvs versions I'm ok with any of the 3 me neither I like c least of all metoo but am not necessarily opposed to it and jbailey too :) there might also be a point when we have manpages for connections.conf(5) or such which we would put in cvs anyway there might also be manpages for languages other than C which we would also put in CVS so i'm tempted to say a) I'm ok with a) actually, the more I think about it, the more I think they should be in cvs\ as just because they can be automatically generated, doesn't mean the install routines should have to do it ok good i'll do it. the automatic generation was a convenience for developers btw did you ever _look_ at such a manpage lately? on an 80x24 terminal? possibly not why, what's it doing? there might be a problem with line breaks (or the absence of them) ah well, I did the --generate-manpage code and before that, I'd never looked at the manpage format before so I got a crash course in it hehe btw. if its a convenient function for developers, should the command line option be allways enabled, or removed for end user programms? siesel: i think it hurts noone second point now we should be consistent if we want to *install* technotes or just include them in the distro reinhard: I just don't like too much bloat produced by an --help command line argument. siesel: true but I don't like undocumented command line switches those drive me up the wall I like the solution to create DTDs automaticly better (using a seperate tool) jcater: so I thought about removing them totaly in "end user" prog I actually was hoping to move the DTD thing onto GNUe Common's GApp as the advantage of that is they always work I haven't looked at the Manpage code in a while but it still works the DTD is likely out of date after a big release jcater: sorry back to first point we put the manpages in cvs in man/man1/ or in doc/man/man1 ? (only cvs dir, install dir is given by fhs anyway) hmm I never thought about doc/man but that does make sense I take it that's what you're leaning to? somehow I don't have strong feelings either way would leave the root dir clean just pick one and people would tend to update the manpages if the update the other docs (if they do so at all) ;-) you've any preference wrt doc/man or doc/man/man1 ? i'd propose doc/man (as we won't have many) jcater: I like the man page code, I just think that, for an end user, its just command line namespace pollution. but thats just my 2 cents. brb watching news siesel (~jan@xdsl-213-196-209-199.netcologne.de) left irc: "bbl" back jcater: what is your view on technotes? should they be installed and included in binary distros? hmm I can't think of any reason an enduser would need a technote so I'm leaning towards "no" ok agreed that's what i wanted to hear :) at the moment all packages have technotes/index.html|txt in cvs except appserver where i removed it although this generates the need to have gnue-common installed in source to build a release tarfile should they be in cvs or not? we could also make create-technote-index.py an "official" tool like gnue-schema Hey - do you guys expect more tools based on gnue-common to wind up in Debian? Or is forms, appserver, and designer pretty much it? (Like, would everything esle just depend on those?) navigator someday I could see other stuff later on reinhard: I don't see why they'd need to be in CVS I want to get the technotes automatically uploaded to the website I'm thinking about writing a dh_gnue debhelper file to make sure that the latest version of common is always depended on. I don't see any harm in having an index.txt in cvs though Action: jcater is indifferent on almost everything today :) jcater: would you agree that technotes should go in source distributions? sure ok jbailey proposed to also install the several utility scripts like create-technote-index.py for the enduser if he/she wants to use gnue-common for their own packages that would then be a gnue-common-dev i suppor er s/suppor/suppose/ hmm in debian-land, I guess that makes sense ok not now anyway can you tell me which ui drivers for forms are functional now? we have wx, curses, gtk2, qt and win32 hmm curses and qt need some more loving before I'd put them in front of an enduser curses! ok GTK2 and Win32 are siesel and btami's babies so I don't know their status i think both work