Re: 2 files related to xdvi missing in the latest teTeXdistribution
Volker Zell [EMAIL PROTECTED] writes: There are 2 files missing in the latest teTeX distro: o /usr/share/texmf/xdvi/ps2pk.map which used to be in the tetex-bin package This file was moved to tetex-texmf, and is now part of tetex-base, but I failed to add it to tetex-tiny. o /usr/share/texmf/xdvi/xdvi.cfg which used to be in the tetex-base package This was removed from tetex-texmf, and I failed to package the version from tetex-src. Here is a minimal xdvi.cfg: % xdvi.cfg enc 8r TeXBase1Encoding8r.enc dvipsmap ps2pk.map % 8r.enc also is only in tetex-base, not in tetex-tiny. This will be fixed for the next release. Thanks for the report. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
RE: Setup: LogFile::exit
On Sun, 2003-03-02 at 13:30, Gary R. Van Sickle wrote: Rob, LogFile::exit() actually exit()s Setup, i.e. main() never returns under any circumstances. This doesn't seem like a good thing to me; it's not at all clear to me why a logging object should as a matter of course be responsible for terminating the program. Mind if I dink with it, or am I missing something? static object destructors. Get those working (under mingw gui apps), and we can dink with it. How about just replace it with a flush() member? -- Gary R. Van Sickle Brewer. Patriot.
RE: Setup: LogFile::exit
On Tue, 2003-03-04 at 19:10, Gary R. Van Sickle wrote: How about just replace it with a flush() member? As long as you track down *all* the exit points and ensure they call it. Safer IMO to a) fix static object destructors or b) exit via the log object. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Pending packages status
5. TCM date : 27 Jan 2003 version: 2.20-1 status : not reviewed notes : http://www.cygwin.com/ml/cygwin-apps/2003-01/msg00299.html http://www.cygwin.com/ml/cygwin-apps/2003-01/msg00100.html votes : 2 (Christopher and Lapo) url: http://home.in.tum.de/~boesswet/tcm-2.20-1.tar.bz2 http://home.in.tum.de/~boesswet/tcm-2.20-1-src.tar.bz2 http://home.in.tum.de/~boesswet/setup.hint I tried TCM, but it seems not to work properly. After installation through setup, I launch it in this way: $ tcm could not open color info file '/usr/X11R6/share/tcm-2.20colorrgb.txt' It seems that a slash is missing between tcm-2.20 and colorrgb.txt. In addition when I try to click on the single tools I get errors like these (on the console): /usr/X11R6/doc/tcm-2.20/bin/tgd: not found /usr/X11R6/doc/tcm-2.20/bin/tgt: not found I tried also to download the sources (from the TCM site I think) and to compile them: in that case tcm works (even if it's installed under /opt). Ciao, Danilo Turina
Re: Please upload this new pdksh (was: Re: Ok, to upload pdksh ?)
On Mon, 3 Mar 2003, Pavel Tsekov wrote: On Mon, 3 Mar 2003, Elfyn McBratney wrote: http://twoducks.exposure.org.uk/elfyn/cygwin/pdksh/pdksh-5.2.14-2-src.tar.b z2 http://twoducks.exposure.org.uk/elfyn/cygwin/pdksh/pdksh-5.2.14-2.tar.bz2 http://twoducks.exposure.org.uk/elfyn/cygwin/pdksh/setup.hint Please upload. Cheers! Uploaded. I've removed -1. Please, send an announcement for -2.
Re: Cygwin setup crashes
On Tue, 4 Mar 2003, Max Bowsher wrote:
Call stack:
00406816 SETUP.EXE:00406816 compress_gz::destroy()
compress_gz.cc:472 ...
free (outbuf);
if (original)
delete original;
}
Interesting indeed. Something very weird is happening, if a non-null pointer
if causing a segfault on being deleted. I wonder if it could be a
double-free. I'll fiddle with this.
Manu: Just to confirm, this is setup from HEAD of CVS, showing version 2.312
on it's splash page?
Also, could you send the output of 'find' run from your local package
directory? (as an attachment)
How about this snippet from install.cc:
if (thefile)
{
String fn;
if (type == package_binary)
{
io_stream *tmp = io_stream::open (String
(cygfile:///etc/setup/) +
pkgm.name + .lst.gz, wb);
lst = new compress_gz (tmp, w9);
if (lst-error ())
{
delete lst;
lst = NULL;
}
}
It looks suspicious. delete-ing 'lst' after an error may cause double free
as you suggested, because the destroy() method is called in contrsuct(),
if error condition is detected.
Now i see something really interesting. The patch the I wanted to be
backported to 200206, seems to be applied incorrectly to HEAD. I think
this is the real cause of the problem.
Re: Cygwin setup crashes
On Tue, 4 Mar 2003, Pavel Tsekov wrote: Now i see something really interesting. The patch the I wanted to be backported to 200206, seems to be applied incorrectly to HEAD. I think this is the real cause of the problem. Actually this patch was never applied correctly to cvs. Here is my original post with the correct patch: http://sources.redhat.com/ml/cygwin-apps/2002-07/msg00049/compress_gz.cc.patch
[PATCH] Postinstall script ordering in setup - take 2
Attached is try #2. This incorporates Rob's comments from
http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also
refactored FileDesc to handle all dependence processing.
I think this would be good as a long-term solution as well. As I
mentioned previously, I don't think we can use the existing package
dependence mechanism unless we also somehow track which package contains
which postinstall scripts. Personally, I think storing dependences in the
postinstall scripts themselves is cleaner. Opinions?
Igor
==
ChangeLog:
2003-03-03 Igor Pechtchanski [EMAIL PROTECTED]
* postinstall.cc (RunFindVisitor::executeAll): New
member function that propagates script dependences,
topologically sorts the script list, and then executes
the scripts (via other calls).
(RunFindVisitor::visitFile): Change to add file to list
instead of running it immediately.
(RunFindVisitor::files): New member variable.
(RunFindVisitor::checkAndLogMissingDependences): New
member function.
(FileDesc): New class that extracts and stores
dependences from a script file.
(DEPEND_STR): New #define.
(do_postinstall): Add executeAll() call.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
Index: postinstall.cc
===
RCS file: /cvs/cygwin-apps/setup/postinstall.cc,v
retrieving revision 2.9
diff -u -p -r2.9 postinstall.cc
--- postinstall.cc 19 May 2002 03:07:51 - 2.9
+++ postinstall.cc 4 Mar 2003 17:54:20 -
@@ -26,6 +26,140 @@ static const char *cvsid =
#include mount.h
#include script.h
#include FindVisitor.h
+#include io_stream.h
+#include resource.h
+#include msg.h
+#include log.h
+#include list
+#include set
+#include map
+
+#define DEPEND_STR depends on:
+#define BUFLEN 500
+
+class FileDesc
+{
+public:
+ FileDesc(String const basePath);
+ String const path() { return _path; }
+ std::setFileDesc* const dependences() { return _dependences; }
+ bool addDependence(FileDesc *dep) {
+return _dependences.insert(dep).second;
+ }
+ bool addDependence(String const deps) {
+// TODO: free unused map entries
+return addDependence(create(deps));
+ }
+ void propagateDependences() {
+// TODO: detect circular dependences
+if (_mark) return;
+_mark = true;
+for (std::setFileDesc*::iterator i = _dependences.begin();
+i != _dependences.end();
+++i)
+ {
+ (*i)-propagateDependences();
+ for (std::setFileDesc*::iterator d = (*i)-_dependences.begin();
+d != (*i)-_dependences.end();
+++d)
+ addDependence(*d);
+ }
+ }
+ bool operator == (FileDesc const f) const {
+return _path == f._path _dependences == f._dependences;
+ }
+ bool operator (FileDesc f) {
+return (_dependences.find(f) != _dependences.end());
+ }
+ bool operator (FileDesc f) {
+return (f *this);
+ }
+
+ static FileDesc *create(String const path) {
+FileDesc *fd = fdmap[path];
+if (fd == NULL) fd = new FileDesc(path);
+return fd;
+ }
+private:
+ String _path;
+ std::setFileDesc* _dependences;
+ bool _mark;
+ char _buf[BUFLEN];
+ char const *commentString();
+ char *readDependenceLine();
+
+ static std::mapString, FileDesc*, String::caseless fdmap;
+};
+
+char const *FileDesc::commentString()
+{
+ char const *ext = strrchr (_path.cstr_oneuse(), '.');
+ char const *cmt = NULL;
+ if (strcasecmp(ext, .sh) == 0)
+cmt = #;
+ else if (strcasecmp(ext, .bat) == 0)
+cmt = rem;
+ return cmt;
+}
+
+#define WHITESPACE \t
+
+char *FileDesc::readDependenceLine()
+{
+ io_stream *f = io_stream::open(String(file://) + _path, rt);
+ if (!f)
+{
+ const char *err = strerror (errno);
+ if (!err)
+ err = (unknown error);
+ note (NULL, IDS_ERR_OPEN_READ, _path.cstr_oneuse(), err);
+ return NULL;
+}
+
+ // Read first line after shbang (if any)
+ f-gets(_buf, BUFLEN);
+ if (*_buf == '#')
+{
+ char *bang = strtok(_buf+1, WHITESPACE);
+ if (bang != NULL *bang == '!')
+ f-gets(_buf, BUFLEN);
+ else
+*(bang+strlen(bang)) = ' ';
+}
+
+ delete f;
+
+ // Check if a dependence line
+ char const *cmt = commentString();
+
+ // - has to start with a comment
+ if (strncasecmp(_buf, cmt, strlen(cmt)) != 0)
+return NULL;
+ // - has to contain a marker after whitespace
+ char *mstr = strtok(_buf+strlen(cmt), WHITESPACE);
+ if (mstr == NULL)
+return
Re: [PATCH] Postinstall script ordering in setup - take 2
Igor Pechtchanski wrote: Attached is try #2. This incorporates Rob's comments from http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also refactored FileDesc to handle all dependence processing. I think this would be good as a long-term solution as well. As I mentioned previously, I don't think we can use the existing package dependence mechanism unless we also somehow track which package contains which postinstall scripts. Personally, I think storing dependences in the postinstall scripts themselves is cleaner. Opinions? Good idea. Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. I'm thinking about passwd-grp.sh mainly. Max.
Re: Cygwin setup crashes
On Tue, 4 Mar 2003, Max Bowsher wrote: Actually this patch was never applied correctly to cvs. Here is my original post with the correct patch: http://sources.redhat.com/ml/cygwin-apps/2002-07/msg00049/compress_gz.cc.pat ch Looks like a botched application of the patch. I don't know what 'botched' is :) Robert: OK to fix on HEAD? OK to apply to setup-200206? OK to apply similar fix to setup-200207, just in case we want to use that branch to help find some of the weird logic bugs that have crept in since 200206? I'm going to suggest Manu tries this fix. I guess it will fix his problems, however I think the patch should be enhanced a bit. It should handle properly also the other case i.e. compress_gz_object = new compress_gz; if (compress_gz_object-error()) delete compress_gz_object; This code is dangerous. compress_gz::construct() calls compress_gz::destroy() if an error is encountered. The the destructor will trigger a second call to compress_gz::destroy() which will try to free memory which was already freed. So I suggest either to zero the pointer members after they're deleted or use the 'destroyed' member of compress_gz to check if the object has already been destroyed. This member is only set now but not checked. Sorry, dont have time to do a proper patch right now.
Re: Cygwin setup crashes
Pavel Tsekov wrote: On Tue, 4 Mar 2003, Max Bowsher wrote: Actually this patch was never applied correctly to cvs. Here is my original post with the correct patch: http://sources.redhat.com/ml/cygwin-apps/2002-07/msg00049/compress_gz.cc.pat ch Looks like a botched application of the patch. I don't know what 'botched' is :) Accidentally incorrect. The code fragment was added in it's new location, but not removed from it's old location. Max.
Re: [PATCH] Postinstall script ordering in setup - take 2
On Tue, 4 Mar 2003, Max Bowsher wrote: Igor Pechtchanski wrote: Attached is try #2. This incorporates Rob's comments from http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also refactored FileDesc to handle all dependence processing. I think this would be good as a long-term solution as well. As I mentioned previously, I don't think we can use the existing package dependence mechanism unless we also somehow track which package contains which postinstall scripts. Personally, I think storing dependences in the postinstall scripts themselves is cleaner. Opinions? Good idea. Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. I'm thinking about passwd-grp.sh mainly. Max. Depends on where you mark it. If we go by name, just have setup.exe be aware of those names, and simply make that script a default dependence (i.e., always add that script to the dependence list for all others). If you're thinking of marking it in the script itself, then it is pretty implausible, since setup will then have to parse *all* of the postinstall scripts *every time* even one of them has to run... If setup had stored state or a config file, we could store the names of those high-priority scripts in there, rather than in the code... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
RE: [PATCH] Postinstall script ordering in setup - take 2
From: Max Bowsher Igor Pechtchanski wrote: Attached is try #2. This incorporates Rob's comments from http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also refactored FileDesc to handle all dependence processing. I think this would be good as a long-term solution as well. As I mentioned previously, I don't think we can use the existing package dependence mechanism unless we also somehow track which package contains which postinstall scripts. Personally, I think storing dependences in the postinstall scripts themselves is cleaner. Opinions? Good idea. Definately. Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. and the ones that should be run only after all others. I'm thinking about passwd-grp.sh mainly. J.
Re: Pending setup patches (issue 2)
On Tue, 4 Mar 2003, Max Bowsher wrote: Updated: * Remove concat.* In http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00022.html and its reply, I asked a question about this. * Igor's error message patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00017.html * Gary's big chooser patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00020.html * Pavel's patch for Exceptions freeing their messages too early http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00176.html * Pavel's Do not uninstall if upgrade package fails md5 patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00178.html * Patch I forwarded from Brian Keener, for adding extra views http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00346.html * Igor's postinstall ordering patch http://cygwin.com/ml/cygwin-apps/2003-03/msg00051.html * Preliminary colour-coding patch (from me) http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00361.html [This is a where-do-we-go-from-here patch, not a please-apply patch] How about http://cygwin.com/ml/cygwin-apps/2002-10/msg00129.html ? This is pretty old, but I can regenerate it against the current CVS if people think it's a good idea. This is also a where-do-we-go-from-here patch... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: Pending setup patches (issue 2)
On Tue, 4 Mar 2003, Igor Pechtchanski wrote: On Tue, 4 Mar 2003, Max Bowsher wrote: Updated: * Remove concat.* In http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00022.html and its reply, I asked a question about this. * Igor's error message patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00017.html * Gary's big chooser patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00020.html * Pavel's patch for Exceptions freeing their messages too early http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00176.html * Pavel's Do not uninstall if upgrade package fails md5 patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00178.html * Patch I forwarded from Brian Keener, for adding extra views http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00346.html * Igor's postinstall ordering patch http://cygwin.com/ml/cygwin-apps/2003-03/msg00051.html * Preliminary colour-coding patch (from me) http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00361.html [This is a where-do-we-go-from-here patch, not a please-apply patch] How about http://cygwin.com/ml/cygwin-apps/2002-10/msg00129.html ? This is pretty old, but I can regenerate it against the current CVS if people think it's a good idea. This is also a where-do-we-go-from-here patch... Igor Oops, that should have been http://cygwin.com/ml/cygwin-apps/2002-10/msg00137.html Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
RE: [PATCH] Postinstall script ordering in setup - take 2
On Tue, 4 Mar 2003, John Morrison wrote: From: Max Bowsher Igor Pechtchanski wrote: Attached is try #2. This incorporates Rob's comments from http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also refactored FileDesc to handle all dependence processing. I think this would be good as a long-term solution as well. As I mentioned previously, I don't think we can use the existing package dependence mechanism unless we also somehow track which package contains which postinstall scripts. Personally, I think storing dependences in the postinstall scripts themselves is cleaner. Opinions? Good idea. Definately. Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. and the ones that should be run only after all others. J. John, That's already possible with my patch -- just include all other scripts in the list of dependences, and your script will be run last. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: [PATCH] Postinstall script ordering in setup
On Wed, 2003-03-05 at 01:58, Igor Pechtchanski wrote: Rob, Thanks for the review. Comments below... This does too much. When a method does more than one thing... split it up. This does it by calling 3 functions. It's a 7-line function. :-D I guess my eagerness to make the changelog detailed enough got the best of me. :}. I suspect at this point we may want a class to handle this - to extract, remember and sort dependencies. There is a class that contains the dependences (FileDesc). I could put this function in that class (as static, though, so doesn't change much). It makes the ownership of the function more clear, and gives it access to any privates of the class without needing a friendship. This should be in a class, IMO. Rob I've forgotten a lot of C++ in the recent years. In Java, I would have made this a private method. How expensive are non-virtual private functions in C++? If same as regular functions, I'll put it in the class (along with processFile). non-virtual privates are == regular extern functions. I.e. they will inline within the same compilation unit. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Pending setup patches (issue 2)
Igor Pechtchanski wrote: On Tue, 4 Mar 2003, Max Bowsher wrote: Updated: * Remove concat.* In http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00022.html and its reply, I asked a question about this. * Igor's error message patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00017.html * Gary's big chooser patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00020.html * Pavel's patch for Exceptions freeing their messages too early http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00176.html * Pavel's Do not uninstall if upgrade package fails md5 patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00178.html * Patch I forwarded from Brian Keener, for adding extra views http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00346.html * Igor's postinstall ordering patch http://cygwin.com/ml/cygwin-apps/2003-03/msg00051.html * Preliminary colour-coding patch (from me) http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00361.html [This is a where-do-we-go-from-here patch, not a please-apply patch] How about http://cygwin.com/ml/cygwin-apps/2002-10/msg00129.html ? This is pretty old, but I can regenerate it against the current CVS if people think it's a good idea. This is also a where-do-we-go-from-here patch... Sounds like a good idea to me. Adding to the pending list, and hoping Robert will comment on it. Max.
Re: [PATCH] Postinstall script ordering in setup - take 2
At 06:52 PM 3/4/2003 -, Max Bowsher wrote: Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. I'm thinking about passwd-grp.sh mainly. Good point. Any other script doing a chown would need it, but that's all I can think of (so far). Starting with 1.3.21 the if [ -x/r/w ... ] test won't depend on it. Pierre
Re: Cygwin setup crashes
On Wed, 2003-03-05 at 06:05, Max Bowsher wrote: Pavel Tsekov wrote: On Tue, 4 Mar 2003, Pavel Tsekov wrote: Now i see something really interesting. The patch the I wanted to be backported to 200206, seems to be applied incorrectly to HEAD. I think this is the real cause of the problem. Actually this patch was never applied correctly to cvs. Here is my original post with the correct patch: http://sources.redhat.com/ml/cygwin-apps/2002-07/msg00049/compress_gz.cc.pat ch Looks like a botched application of the patch. Robert: OK to fix on HEAD? OK to apply to setup-200206? OK to apply similar fix to setup-200207, just in case we want to use that branch to help find some of the weird logic bugs that have crept in since 200206? Please do. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
RE: [PATCH] Postinstall script ordering in setup - take 2
From: Igor Pechtchanski On Tue, 4 Mar 2003, John Morrison wrote: From: Max Bowsher Igor Pechtchanski wrote: Attached is try #2. This incorporates Rob's comments from http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also refactored FileDesc to handle all dependence processing. I think this would be good as a long-term solution as well. As I mentioned previously, I don't think we can use the existing package dependence mechanism unless we also somehow track which package contains which postinstall scripts. Personally, I think storing dependences in the postinstall scripts themselves is cleaner. Opinions? Good idea. Definately. Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. and the ones that should be run only after all others. J. John, That's already possible with my patch -- just include all other scripts in the list of dependences, and your script will be run last. *All* other scripts? Even the ones I didn't know about when I wrote the script? quizicalHow?/quizical J.
Re: [PATCH] Postinstall script ordering in setup - take 2
On Tue, 4 Mar 2003, Pierre A. Humblet wrote: At 06:52 PM 3/4/2003 -, Max Bowsher wrote: Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. I'm thinking about passwd-grp.sh mainly. Good point. Any other script doing a chown would need it, but that's all I can think of (so far). Starting with 1.3.21 the if [ -x/r/w ... ] test won't depend on it. Pierre If that's all it is, then there is no need for special treatment. It's a simple rule: if your script does a chown, include passwd-grp.sh in its dependences, that's all. I thought it was more like something is essential to running all scripts, so there had better be a dependence there whether the author included it or not. Can't think of any that would need it, though... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: [PATCH] Postinstall script ordering in setup - take 2
John Morrison wrote: From: Igor Pechtchanski On Tue, 4 Mar 2003, John Morrison wrote: From: Max Bowsher Igor Pechtchanski wrote: Attached is try #2. This incorporates Rob's comments from http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also refactored FileDesc to handle all dependence processing. I think this would be good as a long-term solution as well. As I mentioned previously, I don't think we can use the existing package dependence mechanism unless we also somehow track which package contains which postinstall scripts. Personally, I think storing dependences in the postinstall scripts themselves is cleaner. Opinions? Good idea. Definately. Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. and the ones that should be run only after all others. J. John, That's already possible with my patch -- just include all other scripts in the list of dependences, and your script will be run last. *All* other scripts? Even the ones I didn't know about when I wrote the script? quizicalHow?/quizical What scenario are you thinking of here? I don't understand how this would be useful. Max.
RE: [PATCH] Postinstall script ordering in setup - take 2
On Tue, 4 Mar 2003, John Morrison wrote: From: Igor Pechtchanski On Tue, 4 Mar 2003, John Morrison wrote: From: Max Bowsher Igor Pechtchanski wrote: Attached is try #2. This incorporates Rob's comments from http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also refactored FileDesc to handle all dependence processing. I think this would be good as a long-term solution as well. As I mentioned previously, I don't think we can use the existing package dependence mechanism unless we also somehow track which package contains which postinstall scripts. Personally, I think storing dependences in the postinstall scripts themselves is cleaner. Opinions? Good idea. Definately. Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. and the ones that should be run only after all others. J. John, That's already possible with my patch -- just include all other scripts in the list of dependences, and your script will be run last. *All* other scripts? Even the ones I didn't know about when I wrote the script? quizicalHow?/quizical J. Oops, sorry, I see your point. To use Pavel's terminology, IOWTWIWT. Maybe we could have a reserved script name, something like |all| (an invalid filename)? Then all you say is that your script depends on |all|, and that subsumes all other scripts (so it'll be run last). This would present a problem with circular dependences, though, and if there is more than one script with that property... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
RE: [PATCH] Postinstall script ordering in setup - take 2
From: Max Bowsher [mailto:[EMAIL PROTECTED] John Morrison wrote: From: Igor Pechtchanski On Tue, 4 Mar 2003, John Morrison wrote: From: Max Bowsher Igor Pechtchanski wrote: Attached is try #2. This incorporates Rob's comments from http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html. I've also refactored FileDesc to handle all dependence processing. I think this would be good as a long-term solution as well. As I mentioned previously, I don't think we can use the existing package dependence mechanism unless we also somehow track which package contains which postinstall scripts. Personally, I think storing dependences in the postinstall scripts themselves is cleaner. Opinions? Good idea. Definately. Do we also need a way to mark 'high-priority' scripts? i.e. ones that should run before all others. and the ones that should be run only after all others. J. John, That's already possible with my patch -- just include all other scripts in the list of dependences, and your script will be run last. *All* other scripts? Even the ones I didn't know about when I wrote the script? quizicalHow?/quizical What scenario are you thinking of here? I don't understand how this would be useful. I was thinking of the defaults post install script, but, thinking about it I got my logic twisted. defaults doesn't depend on the other scripts they depend on it. Never mind. Sorry for the noise! J.
Re: [PATCH] Postinstall script ordering in setup - take 2
On Wed, 2003-03-05 at 05:37, Christopher Faylor wrote: Of course, maybe it's only because I don't have to change upset, but still... Just wait for the first X doesn't install correctly when Y isn't installed, and I checked, and Y-install.sh is in the list for the X-instal script resulting from a missing package level dependency :}. /remove pessimism hat Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Postinstall script ordering in setup - take 2
On Wed, 2003-03-05 at 05:52, Max Bowsher wrote: I'm thinking about passwd-grp.sh mainly. No. Package authors have enough info to describe their requirements such that setup will DoTheRightThing. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Postinstall script ordering in setup - take 2
On Tue, 4 Mar 2003, Max Bowsher wrote:
Igor Pechtchanski wrote:
On Tue, 4 Mar 2003, Pierre A. Humblet wrote:
At 06:52 PM 3/4/2003 -, Max Bowsher wrote:
Do we also need a way to mark 'high-priority' scripts?
i.e. ones that should run before all others.
I'm thinking about passwd-grp.sh mainly.
Good point. Any other script doing a chown would need it, but that's
all I can think of (so far).
Starting with 1.3.21 the if [ -x/r/w ... ] test won't depend on it.
Pierre
If that's all it is, then there is no need for special treatment.
It's a simple rule: if your script does a chown, include
passwd-grp.sh in its dependences, that's all.
I thought it was more like something is essential to running all
scripts, so there had better be a dependence there whether the author
included it or not. Can't think of any that would need it, though...
Neither can I, specifically. We will see if John has a specific requirement
for his run-last idea.
What I was thinking of, is that a script could be tagged high (or low)
priority, and setup would simply determine which scripts to run, then sort
the list by priority.
Whilst I'm thinking about it, how does your patch handle circular
dependencies?
Max.
It doesn't (yet):
+ void propagateDependences() {
+// TODO: detect circular dependences
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
Re: [PATCH] Postinstall script ordering in setup - take 2
On 5 Mar 2003, Robert Collins wrote: I.e. if package foo has an install script depending on a script found in package bar, setup.ini has to list foo requiring bar. Then in the script we list foo-install requiring bar-utility to have completed first. Using the packages as dependencies we can build the same topological tree based on the packages that will end up as installed (Because we do know which package has which postinstall script). Yes, but using scripts is more fine-grained. Re-running install scripts every time, when a package has not changed, is bad IMO, because we haven't made any requirements for idempotent behaviour. If a package needs something to occur because it's changed it, it should trigger that (or, for generics like info pages setup should observe the occurence and trigger the action). Umm, the patch I submitted won't do that. It will only re-run the script if it exists. If the script exists with .done after it, it'll assume the script has already run, and won't re-run it. Thus - I think this is a short term bandaid, because it increases work, not decreases it, and there is a better solution out there, as shown by the other package managers. Rob I agree. If the package dependence mechanism becomes more fine-grained, then we could certainly merge the two. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: Pending setup patches (issue 2)
On Wed, 2003-03-05 at 07:41, Max Bowsher wrote: How about http://cygwin.com/ml/cygwin-apps/2002-10/msg00129.html ? This is pretty old, but I can regenerate it against the current CVS if people think it's a good idea. This is also a where-do-we-go-from-here patch... Sounds like a good idea to me. Adding to the pending list, and hoping Robert will comment on it. http://cygwin.com/ml/cygwin-apps/2002-10/msg00137.html Still: * Not tested on Win95. It's a fairly low level change, and I have 'this much' (holds thumb and forefinger very close together) confidence that we won't get surprised. Other than that, please expand to address all postinstall scripts. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Pending setup patches (issue 2)
On Wed, 2003-03-05 at 07:41, Max Bowsher wrote:
* Patch I forwarded from Brian Keener, for adding extra views
http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00346.html
Ok, reviewed again to refresh my memory.
Brian, Why do you change the scroll bar behaviour? Thats orthogonal to
the presence of more views IMO.
Anyway, Max, please commit this.
Brian, if you have time, once this is in, the chooser selection logic
+ else if (chooser-get_view_mode () == PickView::views::PackageKeeps)
+{
+ for (vector packagemeta *::iterator i = db.packages.begin ();
+ i != db.packages.end (); ++i)
+ {
+ packagemeta pkg = **i;
+ if (pkg.installed pkg.desired !pkg.desired.picked()
+ !pkg.desired.sourcePackage().picked())
+ chooser-insert_pkg (pkg);
+ }
+}
should be refactored:
else if (choose-get_view_mode() == PickView::views::PackageKeeps)
insertPackages(db.packages.begin(), db.packages.end(),
PackageKeeps::predicateForDisplay());
As a first step.
Waay to much duplicate code there :}. Not a problem you created, just one that the
extra views exacerbated.
IF, and only IF you have time, this would be really appreciated.
Rob
--
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
signature.asc
Description: This is a digitally signed message part
Re: Pending setup patches (issue 2)
On Wed, 2003-03-05 at 08:58, Robert Collins wrote: Other than that, please expand to address all postinstall scripts. s/postinstall// :}. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Preliminary colour-coding patch (was: Pending setup patches (issue 2))
Robert Collins wrote: On Wed, 2003-03-05 at 07:41, Max Bowsher wrote: * Preliminary colour-coding patch (from me) http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00361.html [This is a where-do-we-go-from-here patch, not a please-apply patch] Sorry, I hadn't given you UI feedback. I had anticipated some change in the design though (http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00362.html) I was anticipating the need to customize the colours. Re-designing would be premature until that has been discussed. Can you post a couple of screenshots, or a snapshot somewhere? It'll let me do the UI feedback much more quickly.. http://www.srcf.ucam.org/~mob22/setup.exe, but the *only* change is colour, so you should be able to imagine it quite easily. Max.
Re: Pending setup patches (issue 2)
Robert Collins wrote: Brian, Why do you change the scroll bar behaviour? Thats orthogonal to the presence of more views IMO. I think I (IIRC) that I changed it because there were cases depending if there were more than a screen full of packages listed that the scroll bar went hinky both aesthetically and functionally. I think it was when my view changed from less than a screens worth of packages to more than a screens worth or vice versa and then the scroll bar did not adapt as it should to the change. Anyway, Max, please commit this. Woo hoo Brian, if you have time, once this is in, the chooser selection logic [code snip...] Should be refactored: [code snip...] As a first step. I'll take a look. Waay to much duplicate code there :}. Not a problem you created, just one that the extra views exacerbated. We do what we can - the more I learn the better I get - gotta long way to go though IF, and only IF you have time, this would be really appreciated. I'll review and see what I can improve. A challenge/project to try my hand at :-). bk
Re: [PATCH] Postinstall script ordering in setup - take 2
On 5 Mar 2003, Robert Collins wrote: On Wed, [EMAIL PROTECTED]:19, Igor Pechtchanski wrote: On 5 Mar 2003, Robert Collins wrote: Using the packages as dependencies we can build the same topological tree based on the packages that will end up as installed (Because we do know which package has which postinstall script). Yes, but using scripts is more fine-grained. What granularity is needed that isn't present today? Rob Well, one example I could think of off the top of my head is mutually dependent packages. Package dependences can be circular, script dependences cannot. Suppose we have packages A (containing A1.sh and A2.sh) and B (containing B1.sh and B2.sh). Currently we can specify that A should be installed for B to work, *and* that B should be installed for A to work. However, we can't specify, for example, that A1.sh should run before B2.sh, but B1.sh should run before A2.sh. We could say that postinstall scripts in mutually-dependent packages will run in an indeterminate order, but we'd have to run either both B?.sh first or both A?.sh first. Even combining them into one package will not ensure postinstall script ordering. The only solution I see, aside from adding script dependences, is a bunch of almost-empty helper packages... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: Pending setup patches (issue 2)
On 5 Mar 2003, Robert Collins wrote: On Wed, 2003-03-05 at 07:41, Max Bowsher wrote: How about http://cygwin.com/ml/cygwin-apps/2002-10/msg00129.html ? This is pretty old, but I can regenerate it against the current CVS if people think it's a good idea. This is also a where-do-we-go-from-here patch... Sounds like a good idea to me. Adding to the pending list, and hoping Robert will comment on it. http://cygwin.com/ml/cygwin-apps/2002-10/msg00137.html Yup, I mentioned that in a later message... Still: * Not tested on Win95. It's a fairly low level change, and I have 'this much' (holds thumb and forefinger very close together) confidence that we won't get surprised. Uh, can someone test this on Win95? I only have a Win98 machine handy (and tested on that). Thanks. Other than that, please expand to address all scripts. Rob Rob, There is a design issue here that I'd like to address before I work more on this. I recall your comment that this should be tied into the logging subsystem. Unfortunately, this would involve a much more complex code, with pipes and forks. The same is true if we want tee-like behavior, i.e. windows popping up *and* output going to a file. The way this is implemented now is the output stream of the script process is tied to a file, but the limitation is that the file is written right away. Do we want a more complex design now, or should I just allow running a generic script with output going to a file (for the moment)? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Pending setup patches (issue 3)
Updated: * Remove concat.* In http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00022.html and its reply, I asked a question about this. Essentially, I think we should remove autotool-generated files from setup cvs. * Igor's error message patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00017.html * Gary's big chooser patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00020.html Currently being troubleshot by Gary. * Pavel's patch for Exceptions freeing their messages too early http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00176.html * Pavel's Do not uninstall if upgrade package fails md5 patch http://sources.redhat.com/ml/cygwin-apps/2003-02/msg00178.html * Igor's postinstall ordering patch http://cygwin.com/ml/cygwin-apps/2003-03/msg00051.html The following are where-do-we-go-from-here patches, not please-apply patches, and are in active discussion: * Preliminary colour-coding patch (from me) http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00361.html * Igor's postinstall logging Thread start: http://cygwin.com/ml/cygwin-apps/2002-10/msg00129.html Patch: http://cygwin.com/ml/cygwin-apps/2002-10/msg00137.html
Re: [PATCH] Sometimes, You Just Need A Bigger Chooser
Gary R. Van Sickle wrote: I've just been testing this, and I've found setup hangs when 'Finish' is clicked. It then unhangs and continues when the window focus is moved to another application. Gary, do you see this too? Well... I hadn't until I just rebuilt. Son of a diddly, I *was* having a very similar problem which I know I fixed before sending the patch (problem with the message loop). I've synced with cvs main.cc in the interim, that may have done something. I'll look into stopping the crazy number of LOG: boxes gdb is popping up so I can actually debug this. My solution to this is to just use command-line gdb. Max.
RE: Setup: LogFile::exit
On Tue, 2003-03-04 at 19:10, Gary R. Van Sickle wrote: How about just replace it with a flush() member? As long as you track down *all* the exit points and ensure they call it. Well, that's another issue (i.e. if they didn't call exit() before, they're already broken). Safer IMO to a) fix static object destructors Wouldn't know where to start, but yeah that should be fixed regardless. or b) exit via the log object. Safer or preferable? I disagree that exit()ing somehwhere in the guts of an object is a good way to go, especially when that class's raisin de etre is not exiting, but logging. But I've got a message loop that's hosed, so this is all pretty much moot at this point. -- Gary R. Van Sickle Brewer. Patriot.
RE: [PATCH] Sometimes, You Just Need A Bigger Chooser
Gary R. Van Sickle wrote: I've just been testing this, and I've found setup hangs when 'Finish' is clicked. It then unhangs and continues when the window focus is moved to another application. Gary, do you see this too? Well... I hadn't until I just rebuilt. Son of a diddly, I *was* having a very similar problem which I know I fixed before sending the patch (problem with the message loop). I've synced with cvs main.cc in the interim, that may have done something. I'll look into stopping the crazy number of LOG: boxes gdb is popping up so I can actually debug this. My solution to this is to just use command-line gdb. Ok, got past that issue; it's DebugOut that ends up popping up the boxes, so just commenting that out stops it. And of course the results are that, yes indeed, the message loop is once again f*$^$ed up for unkown reasons. -- Gary R. Van Sickle Brewer. Patriot.
RE: [PATCH] Sometimes, You Just Need A Bigger Chooser
Gary R. Van Sickle wrote: I've just been testing this, and I've found setup hangs when 'Finish' is clicked. It then unhangs and continues when the window focus is moved to another application. Gary, do you see this too? Well... I hadn't until I just rebuilt. Son of a diddly, I *was* having a very similar problem which I know I fixed before sending the patch (problem with the message loop). I've synced with cvs main.cc in the interim, that may have done something. I'll look into stopping the crazy number of LOG: boxes gdb is popping up so I can actually debug this. My solution to this is to just use command-line gdb. Ok, got past that issue; it's DebugOut that ends up popping up the boxes, so just commenting that out stops it. And of course the results are that, yes indeed, the message loop is once again f*$^$ed up for unkown reasons. Yet you *can* cancel at any time with no problem. These should be exercising the same code. Hmmm -- Gary R. Van Sickle Brewer. Patriot.
