Back
[08:52:36] <lilo> [Global Notice] Hi all. Apologies for not getting back with you on that main rotation server split. We're looking at the problem. Meanwhile, US donor tax receipts for paypal donations have been sent to your paypal email address. If you need a receipt and haven't received one, please message me. Thanks!
[08:54:09] <lilo> [Global Notice] Those are the 2005 tax receipts. We're about to start our 2006-2007 fundraiser for PDPC, so if you would like to help get us going a bit early, please take a look at the freenode website (
http://freenode.net/pdpc_donations.shtml ). Thanks, and have a great morning!
[16:43:07] <SWPadnos> SWPadnos is now known as SWP_Away
[17:13:07] <SWP_Away> SWP_Away is now known as SWPadnos
[19:45:07] <SWPadnos> weird - I wonder if CIA is having trouble
[19:46:42] <rayh> Regarding?
[19:47:08] <SWPadnos> the docs directory you just added - I got no CIA message, but I did get a SF commit message
[19:48:20] <rayh> There you go. Proves it.
[19:48:26] <SWPadnos> heh
[19:48:41] <SWPadnos> of course, it could have been freenode, or chatzilla as well
[19:49:08] <rayh> I want to replace all instances of # Path to help file
[19:49:08] <rayh> HELP_FILE = docs/help.txt
[19:49:28] <rayh> with the new. Is there a handy way to do this.
[19:49:43] <rayh> other than babelfish
[19:49:52] <SWPadnos> cradek can tell you the correct incantation of find, xargs, and sed
[19:50:06] <SWPadnos> you're trying to replace the text in all the ini files, right>
[19:50:08] <SWPadnos> ?
[19:50:10] <rayh> thanks
[19:50:17] <rayh> Yep.
[19:51:14] <SWPadnos> ok - something like find . -name *.ini -print | xargs {something} sed -e 's/docs\/help.txt/new\/path\/to\/docs/'
[19:51:21] <cradek> rayh: we need to figure out how to handle this properly. Whatever you change this to, it will fail to work for make-install or run-in-place
[19:51:21] <SWPadnos> but the something is where I'm fuzzy
[19:51:47] <cradek> rayh: so changing it is a waste of time right now.
[19:52:09] <SWPadnos> too bad there's no include for ini files
[19:52:17] <rayh> I suppose adding a help variable like the tcl vars in ,in is the proper way to go.
[19:52:31] <cradek> SWPadnos: that's one possible answer.
[19:52:49] <SWPadnos> or an env var that has the EMCDOCROOT
[19:52:50] <cradek> SWPadnos: also, configure could write appropriate changes to the ini files we distribute.
[19:52:50] <rayh> Course I've got no use for install and think it is a great waste of effort for near zero gain.
[19:53:04] <rayh> other than a perceived "correctness."
[19:53:08] <cradek> rayh: you can't simultaneously say that and be happy that there are deb packages.
[19:53:49] <SWPadnos> it allows people to test out new versions, but not destroy the default installation in the process
[19:53:58] <rayh> Sure I can. I'm blissfully ignorant of the finness and know that synergy does it every day.
[19:54:12] <SWPadnos> ie, shop foreman looks at new capabilities, but bonehead still runs the default install from his desktop icon
[19:54:45] <cradek> rayh: I don't want to debate about it right now. I'm busy working on deb packages.
[19:54:51] <rayh> I've got zero faith right now in reversion to previous installs. That doesn't work any better than my broken snowblower.
[19:54:51] <SWPadnos> heh
[19:55:12] <rayh> cradek: I know the feeling.
[19:55:22] <SWPadnos> that's the point - you never have to revert if you test in one dir, then only install as default when you're satisfied that nothing (new) is broken
[19:55:50] <rayh> But I would like to get at least the start of help at the ability level of the old system.
[19:56:07] <SWPadnos> do the tcl programs know where they are?
[19:56:29] <cradek> rayh: you could add a hack to tkemc that searches a few likely relative and absolute paths to find its help file. That's how it finds its resources already.
[19:56:47] <SWPadnos> if so, make the doc file ../docs/help.txt or whatever
[19:57:19] <rayh> Do these debs know the difference between install and run in place?
[19:57:34] <cradek> it coud search ../docs/tkemc-help.txt /usr/share/doc/emc2/tkemc-help.txt for instance
[19:57:45] <SWPadnos> .debs are always "install", unless you explicitly tell them otherwise
[19:57:48] <cradek> a deb always installs to the system directories
[19:57:54] <cradek> /usr/bin etc.
[19:58:09] <SWPadnos> actually, it's already a relative path to the docs, just make it relative to ../../
[19:58:17] <rayh> Unless you build them to install in a single directory.
[19:58:27] <SWPadnos> (or whereever EMC2DIR is, relative to the tcl dir)
[19:59:15] <rayh> ah forget it.who needs help anyway. wish I could revert the directory I just added.
[19:59:16] <cradek> the debian policy manual explicitly disallows debs from installing files in /usr/local, for instance. We can't make a conforming package that slaps everything in /usr/local/emc.
[20:00:00] <cradek> rayh: for now, just do the list of paths to search, like it does for the resource file.
[20:00:37] <rayh> Um that is not relative at all
[20:01:13] <cradek> you can search relative and absolute paths the same way.
[20:01:20] <SWPadnos> what isn't relative?
[20:01:34] <rayh> Unless you are thinking of the work that aj did to define variables that hold relative position.
[20:01:48] <cradek> no, hold on a second.
[20:01:58] <cradek> look at the code that starts at # read the application defaults
[20:02:21] <rayh> That is aj's work.
[20:02:23] <cradek> it checks several paths. One is broken out of the foreach, but it's the same test.
[20:02:31] <cradek> oh, ok
[20:03:10] <cradek> The alternative is to have configure write a file with these paths in it (or generate tkemc.tcl from tkemc.tcl.in)
[20:03:11] <rayh> The only testing I do inside the tickle itself is to find tcl/scripts and make a menu
[20:04:03] <SWPadnos> so tkemc expects to run from the emc dir?
[20:04:09] <SWPadnos> emc2, in this case
[20:04:20] <cradek> only as far as finding a couple files.
[20:04:24] <rayh> IMO the location of help docs is completely broken now.
[20:04:45] <SWPadnos> right, just make a var HELPDIR that's "help/"
[20:04:47] <SWPadnos> true
[20:05:13] <SWPadnos> then load the file "$HELPDIR$helpfilename"
[20:05:51] <SWPadnos> I did some experimentation some time ago, trying to find out where the help file needed to be so that it would show up. I can't get at it now (and I don't remember what I found out)
[20:06:50] <rayh> I'm guessing that this "help" directory will not always be relative to emc2
[20:06:58] <cradek> right
[20:07:00] <rayh> and that is the only way I know to get at em
[20:07:10] <rayh> so I'll do nothing.
[20:07:15] <cradek> it will be in /usr/share somewhere
[20:07:35] <cradek> If you want to write a search like aj's, I can give you a list of likely paths
[20:07:46] <cradek> if you want to let aj or me handle it, that's cool too.
[20:08:43] <rayh> I thought maybe in my humble way I could contribute to one small error... Do it your way.
[20:09:30] <rayh> I suppose that a better way is to have several helps. Like the README in configs.
[20:10:07] <cradek> SWP is right that includes in ini files would be really nice
[20:10:32] <cradek> then everything dealing with paths would be easier
[20:12:41] <SWPadnos> well - it might be possible by changing only inifind
[20:15:02] <rayh> Am I being overreaching to think that there might be some common help info for the axis interface and the tickle interfaces.
[20:15:38] <SWPadnos> I think it would be bad to assume that forever, but it's true that many keystrokes are the smae
[20:15:41] <SWPadnos> same
[20:16:31] <rayh> g-codes, m-codes
[20:16:45] <cradek> I think most key shortcuts are the same
[20:16:50] <SWPadnos> ah - the emc-related stuff - that would hopefully remain the same ;)
[20:17:05] <cradek> definitely there is a lot of help that would be useful that is not dependent on the particular gui
[20:18:23] <rayh> This whole notion of emc help started early on with plain text files saved in emc/doc along with lots of other junk
[20:18:31] <cradek> right now, unfortunately most of that is pdf/latex so it's a little hard to view online - more geared toward printing
[20:18:52] <cradek> moving to good online help might be a trick (unless it's just html)
[20:19:01] <SWPadnos> make should run latex docs through a pdf or ps conversion
[20:19:03] <cradek> heck, we could distribute the wiki
[20:19:12] <cradek> if we thought it was somewhat up-to-date
[20:19:16] <SWPadnos> so they're readable
[20:19:32] <rayh> lyx can easily be converted to html
[20:20:10] <SWPadnos> html would be fine as well - just something that looks better to the end user than a tex file
[20:20:23] <SWPadnos> after all, it is documentation source code - it should be compiled as well
[20:20:38] <rayh> a bit primitive by the standards of todays db related stuff.
[20:21:06] <rayh> tex or text?
[20:21:16] <SWPadnos> tex, like latex source
[20:21:40] <rayh> tex is not very readable
[20:22:12] <SWPadnos> nope - that's why I suggested converting to some user-readable form during make ;)
[20:22:15] <SWPadnos> like make docs
[20:22:53] <rayh> One of the small problems with the lyx repository is that
[20:23:25] <rayh> lyx needs to read em and make them intelligible to a latex converter.
[20:23:58] <SWPadnos> funny - there is a make docs target, but it only runs doxygen for source code documentation, nothing for end-user documentation
[20:24:13] <rayh> Right.
[20:24:35] <SWPadnos> but there is a command-line method of converting from the source form to a .pdf or .html file, right?
[20:25:22] <rayh> I'm not certain how lyx does that.
[20:26:06] <rayh> it would have to be lyx2latex and latex2 whatever using one of several converters.
[20:27:12] <SWPadnos> ok - there's a TEx2pdf program, and another one called lyxport
[20:28:29] <rayh> I don't see the name of the lyx to latex at least not from the lyx gui.
[20:29:35] <SWPadnos> lyx has a command-line option for export, I'm looking for the supported formats
[20:32:53] <SWPadnos> ok - you're right, it looks like it calls latex2{whatever} internally
[20:34:36] <rayh> true but many of these can run standalone or in a pipe.
[20:34:40] <SWPadnos> yep
[20:34:52] <SWPadnos> http://amath.colorado.edu/faculty/fperez/lyxport/lyxport.html
[20:35:14] <rayh> relyx comes to mind as a custom converter for lyx.
[20:39:21] <rayh> but that is the other way around.
[20:39:59] <rayh> I don't see it right off.
[20:40:36] <rayh> If we saved in latex we could do command line conversion.
[20:43:26] <SWPadnos> so the source is in lyx format?
[20:45:19] <rayh> Yes.
[20:45:50] <SWPadnos> there's a command-line option -e (or --export) fmt, but I haven't found a list of supported formats
[20:46:04] <SWPadnos> I suspect that ps, pdf, and html are in the list, but I can't tell for sure
[20:46:26] <SWPadnos> http://wiki.lyx.org/LyX/ManPage
[20:46:53] <rayh> I would not think so. Those are achieved through latex to whatever using many different converters.
[20:47:13] <SWPadnos> I'd bet that lyx will just call the appropriate converter(s), and exit
[20:47:32] <SWPadnos> it can do that, since you can vire as various things from within lyx
[20:47:36] <SWPadnos> view
[20:55:41] <rayh> I do get a pdf from the commandline using lyx -e halconfig.lyx
[20:56:01] <rayh> let me try html
[20:57:17] <rayh> Got it.
[20:58:14] <rayh> * rayh moves to the other box and tests with the repository.
[21:01:05] <rayh_> * rayh_ shakes his head from the pain.
[21:02:07] <rayh_> in the documents/lyx directory it is possible to run lyx -e pdf and say hal_introduction.lyx and get a good pdf.
[21:03:12] <SWPadnos> ok - where's the pain from? ;)
[21:03:45] <rayh_> so much to learn so little time.
[21:03:58] <SWPadnos> heh - I know the feeling
[21:04:29] <rayh_> I believe that if I setup my lyx configuration for hevea or ttl I can also get html.
[21:04:48] <SWPadnos> err - what?
[21:07:03] <rayh_> Those are html converters for latex.
[21:07:13] <SWPadnos> ok ;)
[21:07:15] <rayh_> This is wierd wild stuff.
[21:07:24] <SWPadnos> it looked like terribly botched helvetica nad ttf?
[21:07:27] <SWPadnos> and
[21:10:54] <rayh_> works fine.
[21:11:18] <SWPadnos> cool. does it introduce more build-time dependencies?
[21:11:27] <SWPadnos> or are those programs included with lyx / latex
[21:11:37] <rayh_> So the short answer is that we could write a command line option for make
[21:11:57] <rayh_> that would yield the latest lyx stuff in either of several formats.
[21:12:29] <rayh_> problem becomes one of do we want to and what do we do with the sources.
[21:12:57] <SWPadnos> the sources are just that - source. they should be treated the same as C file IMO
[21:13:29] <SWPadnos> make docs (or make pdfdocs or htmldocs) should create the documentation (in $DOCDIR/)
[21:13:59] <SWPadnos> make install should put the documentation into whatever documentation directory is "standard" (or specified)
[21:14:50] <rayh_> This isn't going to be a developers vesion of make, is it?
[21:15:08] <SWPadnos> how do you mean?
[21:15:41] <rayh_> we would have to ship all of the document/lyx files and the images
[21:15:54] <rayh_> we would be looking at several meg.
[21:16:19] <SWPadnos> that should come along with the cvs checkout (of the docs, if they're a separate cvs checkout from the source)
[21:16:46] <rayh_> They are documents is a module at sf just like emc2 is
[21:17:02] <SWPadnos> well, it can be done two ways
[21:17:22] <SWPadnos> someone building a .deb can either have separate emc2.deb and emc2-docs.deb
[21:17:32] <SWPadnos> or they can build them together into one larger .deb
[21:18:06] <SWPadnos> I guess a developer would just have to check out the extra module, and make whatever version of the docs they want
[21:18:30] <rayh_> and have lyx on board and properly configured.
[21:18:48] <SWPadnos> yep, just like having c/c++/python/make ...
[21:18:57] <SWPadnos> but only if they choose to build the docs
[21:19:09] <rayh_> right.
[21:20:23] <rayh_> blue sky here --> given that we can do this, what kind of a file would be easiest for us to use for help?
[21:21:02] <cradek> I think the most obvious thing to do is use html, since everyone has a web browser.
[21:21:03] <rayh_> Every system has some sort of web/html browser.
[21:21:13] <rayh_> great minds...
[21:21:15] <SWPadnos> depends. if the html output is in small pages that the user can navigate through (table of contents -> sections ...), that's the best
[21:21:36] <SWPadnos> if it's all one pagem then it's not really better than pdf, which is also better for printing
[21:22:07] <cradek> have we checked lately to see whether modern browsers (firefox) still print badly?
[21:22:26] <rayh_> It would be as easily possible to build a menu in tkemc or mini that shows the names of files available
[21:22:27] <SWPadnos> firefox is pretty good, with non-frame stuff
[21:22:44] <SWPadnos> it also allows you to scale by whatever percentage you want to fit to page (at least on Windows)
[21:23:03] <SWPadnos> what it doesn't do is paginate well - I'm not sure if the pdf export does widow/orphan control
[21:23:10] <SWPadnos> I know firefox doesn't
[21:23:14] <rayh_> lyx can wrap figures and min pages better to pdf than html
[21:24:37] <rayh_> I just finished a 90 letter size page book for SO. Fantastic printing, wrapping images, tables, and references.
[21:24:39] <SWPadnos> right - HTML has no concept of a page
[21:25:09] <rayh_> breaks images tables and boxes across pages.
[21:25:32] <rayh_> I wonder how much longer it takes kghostview to open a doc as konqueror.
[21:25:50] <SWPadnos> how about kpdf?
[21:26:04] <rayh_> not used it.
[21:26:18] <SWPadnos> it's pretty nice. has thimbnails of all the pages on the left side
[21:26:22] <SWPadnos> thumbnails
[21:26:42] <SWPadnos> has "continuous" mode, so you can have part of multiple pages visible at once
[21:27:04] <SWPadnos> that's one thing that really bugs me about gpdf and ghostview, you get one page at a time
[21:27:19] <rayh_> got it on the deb box. looks the same as kghostview.
[21:27:57] <rayh_> oops
[21:28:04] <SWPadnos> hmmm - I wonder if it's different in KDE 3.4 (or whatever I have on my Ubuntu box)
[21:28:09] <SWPadnos> or is that 3.3.4?
[21:28:19] <SWPadnos> yeah - oops
[21:29:49] <rayh_> In view of your notion of lyx as source we ought to have a emc2/src/lyx
[21:30:18] <SWPadnos> or src/docs
[21:30:21] <rayh_> that gets built into a set of emc2/docs/xx
[21:30:50] <SWPadnos> or, have a top-level makefile that will drp into src/ by default, and has targets for documentation
[21:31:08] <SWPadnos> ie, a makefile in the emc2/ dir (as people would often expect anyway)
[21:31:52] <rayh_> pdf is famous for bandwidth consumption.
[21:32:10] <rayh_> but it has a huge advantage in printing.
[21:32:35] <rayh_> latex2pdf is a version 3 pdf now.
[21:32:56] <rayh_> don't know if that is clickable links in the table of contents or not.
[21:32:57] <SWPadnos> the pdfs shouldn't be any bigger than the images and text combined - they are compressed (or it's an option, I think)
[21:33:56] <rayh_> This would make for a very attractive help system. Even if we had to write some files specifically for it.
[21:34:05] <SWPadnos> yep
[21:35:05] <rayh_> If you were producing such a thing, what would the file structure for lyx and images look like inside emc2
[21:35:54] <SWPadnos> depending on how lyx expects to get the images, I'd have docs/ contain the lyx source files, images in docs/images/
[21:36:09] <rayh_> that should be no problem for lyx.
[21:36:13] <SWPadnos> and make the actual documentation go into subdirs off docs, docs/pdf, docs/html ...
[21:36:46] <SWPadnos> the html docs should refer back to the same copy of the images, if that can work well for run-in-place and installed documentation
[21:37:13] <rayh_> um. I
[21:37:19] <rayh_> 'd have to check that
[21:37:42] <rayh_> and then they would be different for the installed v run-in-place systems.
[21:39:01] <SWPadnos> the images/ dir would need to be copied for installed versions
[21:39:16] <SWPadnos> the html docs would have to refer to ../images/blahblah
[21:39:42] <SWPadnos> this all depends on how many documents are created as well
[21:40:35] <SWPadnos> if there are separate docs for each UI, plus G-code, then HAL and CL, then a separate dir for pdf vs. html makes a lot of sense
[21:41:55] <rayh_> Yes and that is a lot like some systems provide their docs as well.
[21:42:36] <SWPadnos> yep
[21:42:44] <rayh_> If we had both html and pdf versions. "Click here for print ready." might work
[21:43:06] <SWPadnos> it would be good to generate an "overview" doc as well, like the master index.html, that has links to the other docs
[21:43:22] <SWPadnos> yep - make both, and link to the pdf files in the html, for printing
[21:43:26] <rayh_> Sure.
[21:43:36] <SWPadnos> I'm not sure what that does to the lyx source, or the cmd-line options though
[21:43:44] <SWPadnos> might get a bit complex
[21:44:40] <rayh_> Well something to ponder and play with a bit.
[21:44:52] <SWPadnos> yep
[22:28:53] <alex_joni> hello
[22:31:30] <rayh> Hi alex
[22:42:11] <alex_joni> still reading back, give me 5 mins
[22:43:40] <rayh> k
[22:43:46] <rayh> brb
[22:45:30] <alex_joni> back
[22:47:44] <rayh> me to
[22:47:58] <alex_joni> ok.. care to talk about tcl help?
[22:48:10] <alex_joni> seen you & chris started to talk about it..
[22:48:13] <rayh> sure.
[22:48:24] <rayh> What are your impressions of the need
[22:48:27] <alex_joni> ok.. I see the docs/help as needed
[22:48:32] <alex_joni> very much so
[22:48:55] <alex_joni> certainly even more so after reading user emails from the list (those people don't really have a clue)
[22:49:21] <rayh> It is easy enough to add help.txt to that and mod the ini files.
[22:49:41] <alex_joni> right, but the problem is what we enter in the ini file?
[22:49:50] <rayh> But there was concern about the installed version
[22:50:21] <alex_joni> if you enter HELPFILE=../../docs/help/help.txt then it works for run-in-place
[22:50:37] <rayh> Right I've done that here.
[22:50:40] <alex_joni> it might be with only one ../ (can't recall right now)
[22:50:46] <rayh> 2
[22:51:14] <alex_joni> ok, the problem with the installed version is that configs get installed in /etc/emc2 (for ubuntu for example)
[22:51:22] <alex_joni> in that case ../../ makes no sense
[22:51:35] <alex_joni> agreed?
[22:51:59] <rayh> okay but configs doesn't matter to help.
[22:52:17] <rayh> Unless we also want to try to get at some config specific help.
[22:52:35] <alex_joni> redefine 'configs doesn't matter to help'
[22:53:05] <rayh> I think the problem was that docs will get moved to /usr/share.emc2/...
[22:53:30] <rayh> oops /usr/share/emc2/...
[22:53:52] <alex_joni> no, the real problem is that the runscript gets executed inside the configs dir
[22:54:08] <rayh> oh crap.
[22:54:16] <alex_joni> it first cd's to the stepper/ dir, then runs the rest of the commands
[22:54:29] <alex_joni> that's why you had to enter ../../docs/help/
[22:54:39] <alex_joni> in your run-in-place case
[22:54:59] <alex_joni> but that doesn't work for installed versions, as the location might vary
[22:55:01] <rayh> In emc the run was from emcs main directory.
[22:55:19] <rayh> is it not possible to make the same thing happen for emc2
[22:55:32] <alex_joni> yup, but that meant you can't install it like configure wants
[22:55:51] <alex_joni> with --prefix=usr, then configs in /etc, help in /usr/share etc
[22:56:13] <alex_joni> you basicly can specify all that at configure time, and during make install data gets copied in flexible locations
[22:56:26] <alex_joni> so there isn't an 'main directory'
[22:56:34] <alex_joni> but let me ask you one thing:
[22:56:51] <alex_joni> what if the ini would say HELPFILE=tkemc.txt
[22:57:08] <alex_joni> and the runscript or even tkemc will work out where the file is
[22:57:22] <alex_joni> runscript exports $HELPDIR, tkemc uses that
[22:57:45] <rayh> Then it ain't an ini in the old sence of the notion.
[22:58:03] <alex_joni> in that case $HELPDIR can be easily exported as emc2/docs/help for r-i-p, or /usr/whatever for installed
[22:58:24] <alex_joni> I really don't see a reason for users to change the place where the helpfile gets found
[22:58:39] <alex_joni> not even for integrators
[22:59:15] <rayh> It's no wonder that Bob at Synergy refused Paul when he demanded that synergy be installed like an ordinary package.
[22:59:50] <alex_joni> well.. synergy is pretty badly hacked together
[22:59:56] <rayh> I see that we are talking about installing TkEmc in the xll stuff.
[23:00:06] <rayh> that is where it was originally when we wrote tkemc
[23:00:15] <alex_joni> no, TkEmc IS installed in the x11 stuff
[23:00:20] <alex_joni> ;)
[23:00:24] <rayh> but 5 times out of 6 it was useless there.
[23:00:30] <alex_joni> how so?
[23:00:37] <rayh> never got found.
[23:00:44] <alex_joni> ???
[23:00:50] <rayh> and if you wanted to change it you had to be root.
[23:01:38] <rayh> IMO this installed version of emc2 is a huge waste of time when we are short of it.
[23:01:43] <alex_joni> you need that to run emc (or needed)
[23:01:52] <alex_joni> root that is..
[23:02:08] <alex_joni> well, the problem is the following: the installed version of emc2 is DONE
[23:02:19] <alex_joni> a waste of time would be to revert it
[23:02:22] <rayh> Not for any of the user space stuff except ioshow
[23:02:49] <alex_joni> what kind of user space stuff?
[23:02:51] <rayh> because that depended upon inb and outb
[23:03:04] <rayh> tkemc, mini,
[23:03:35] <alex_joni> I don't follow
[23:03:50] <rayh> Yes if the installed version is ready for daylight then reverting is a waste.
[23:04:11] <alex_joni> rayh: if I just ran: apt-get install emc2 and it worked as it should
[23:04:22] <alex_joni> then I must say it is ready for daylight
[23:04:49] <alex_joni> probably at the moment it might be a bit better than run-in-place
[23:04:53] <rayh> and were you able to revert to the previous version?
[23:05:11] <alex_joni> meaning removing this one, and installing an earlier emc2 deb?
[23:05:25] <alex_joni> I see no reason why not
[23:05:27] <rayh> no using apt get to undo the install
[23:05:33] <alex_joni> sure
[23:05:34] <rayh> if it didn't work.
[23:05:42] <alex_joni> apt-get remove emc2
[23:05:44] <rayh> Paul's updates have never worked properly
[23:05:54] <alex_joni> guess they are busted then
[23:06:06] <rayh> but when you try to step back using apt you can not do it.
[23:06:10] <alex_joni> but it depends on what you expect an update to do
[23:06:28] <alex_joni> if you apt-get install emc2, and it pulls along a new kernel & rtai
[23:06:35] <alex_joni> apt-get remove emc2 will only remove emc2
[23:06:40] <rayh> Say for a moment that a shop floor has machines running last months emc2
[23:06:42] <alex_joni> and leave the new kernel & rtai
[23:06:49] <alex_joni> that is how apt works
[23:06:56] <alex_joni> ok
[23:07:11] <alex_joni> last months emc2 is a emc2-fooversion.deb
[23:07:17] <rayh> how do they know that the newest version will work in their environment
[23:07:21] <alex_joni> released by us
[23:07:44] <alex_joni> we will not advice anyone (or at least I won't) to use CVS on a shop floor machine
[23:07:55] <rayh> If they could run in place from an apt that would allow them to test
[23:08:06] <alex_joni> there is no runin-place from apt
[23:08:13] <alex_joni> except if the get a source deb
[23:08:21] <alex_joni> that can work
[23:08:27] <rayh> Sorry I'm being so difficult.
[23:08:35] <alex_joni> no, we need to get this straight
[23:08:53] <alex_joni> we can't miss something and be in the rain afterwards
[23:08:54] <rayh> but I have had dozens of my customers kill their systems because they tried to apt-get update emc
[23:09:11] <rayh> The only way to recover is to reinstall from the original CD
[23:09:16] <alex_joni> that is only because of faulty packages
[23:09:30] <alex_joni> and if that happens the packages need to be fixed
[23:09:47] <rayh> and that by first backing up to the old kernel and
[23:09:55] <alex_joni> but I'd NOT want that to happen in the first place, so every realease will be thoroughly fixed
[23:10:15] <rayh> I'm afraid that I don't trust any update.
[23:10:21] <rayh> right now.
[23:10:24] <alex_joni> rayh: yeah, I know .. I didn't managa with BDI myself
[23:10:32] <rayh> If a customer can test then okay.
[23:10:38] <alex_joni> but I didn't have the time/patience to run enough apt foo magic
[23:10:43] <rayh> but with apt-get update you can not test.
[23:11:02] <alex_joni> apt-get upgrade actually ;)
[23:11:05] <rayh> So all of my customers will run in place.
[23:11:17] <rayh> yes
[23:11:21] <alex_joni> apt-get update doesn nothing (except pulls the new lists)
[23:11:41] <alex_joni> we can release packages like debian does (stable, testing, unstable,..)
[23:11:47] <rayh> Now that means my customers will not use the deb packages that you guys are working so hard to produce.
[23:11:49] <alex_joni> although I don't see that as a need
[23:12:02] <alex_joni> that would be too bad
[23:12:14] <rayh> Right my point exactly.
[23:12:18] <alex_joni> and something I would advise against
[23:12:28] <rayh> Weber systems builds a deb that installs okay.
[23:12:31] <alex_joni> run-in-place from CVS is not very safe
[23:12:33] <rayh> And it runs in place
[23:12:50] <alex_joni> yes, and disregards most of the debian rules
[23:13:22] <alex_joni> in the process of doning that
[23:13:31] <alex_joni> s/doning/doing/
[23:13:56] <alex_joni> but that's not really the issue
[23:14:10] <alex_joni> the issue is what version of emc2 do we advise users to use
[23:14:30] <alex_joni> imho that will be emc-2.0.0 (the stable release we are working for)
[23:14:44] <alex_joni> and the next one will be 2.0.1 or whatever, again after a few rc's
[23:15:03] <alex_joni> so between 2.0.0 and 2.0.1 there will be planty CVS versions, but no deb updates
[23:15:17] <alex_joni> only stable emc2 releases should get an deb package
[23:16:19] <rayh> I hear what you are saying but I don't know of any customer that is going to update unless I tell them to.
[23:16:42] <rayh> and in spite of my best testing the mess from bdi-4.30 got past me.
[23:16:55] <alex_joni> right, and I EXPECT you not to tell them to update unless there is a new STABLE emc2 version
[23:17:18] <rayh> But BDI 4.30 was supposed to be stable.
[23:17:32] <alex_joni> says who?
[23:17:39] <rayh> It looked like on all of my machines.
[23:17:50] <rayh> It was customer machines that failed.
[23:18:13] <alex_joni> that is one of the problems we want to overcome
[23:18:22] <alex_joni> not to worry about the linux part..
[23:18:31] <rayh> That is why I'd like a customer to be able to run in place and change between installed versions
[23:18:50] <alex_joni> ubuntu certainly has a lot more users (and machine/setup experience) than we will ever have
[23:19:17] <rayh> until bdi-4xx we have always been able to install and run in place.
[23:19:17] <alex_joni> rayh: and that flexibility is the exact cause of the complexity you are seeing
[23:19:43] <rayh> nope.
[23:20:06] <rayh> I'll go find something to eat, improve my mood and bbl
[23:20:15] <alex_joni> ok, I need to go to sleep
[23:20:26] <alex_joni> it's too late ;) need to work in about 6 hours
[23:20:31] <rayh> catch you tomorrow.