Re: nfs-server - status request for information
Robb, Sam wrote: A workaround is to create a regular directory, mount the Windows drive at that directory, and then export the directory. For example: $ mkdir -p /exports/c $ mount -f -s -b c:/ /exports/c $ echo /exports/c (ro,all_squash) /etc/exports Would another possible workaround be just a simple ``mkdir -p /cygdrive/c/cygwin/cygdrive/c'' (this assumes cygwin is installed in c:\cygwin)? Earnie.
RE: Mirrors list order is snafued - What is the order supposed to be?
On Mon, 20 Jan 2003, Lapo Luchini wrote: LL I guess the best would be to sort by ping time (smalest to bigger) to LL help reduce unnecessary trans-oceanic downloads. LL But of course it would need to check them each time... or may it be LL cached in the local setup.ini? Ping time would probably be rather unfriendly to the mirrors :-) Would this seriously be a concern? I can't imagine that the cygwin user base is that update-happy that they'd be flooding download servers (which would have to serve them multimegabytes anyway) with pings. Especially when we still have folks going, Hi, I recently upgraded from B6. Why did you break everything?. I was thinking treeview Continent/Country/Site. NOO!! NOT MORE TREEVIEWS!!! ;-) Seriously, what I'd really like to see us work towards is a UI-less mirror selection system as the default. 99% of users couldn't give a whit which server the stuff is coming from, as long as it works. Hence, a UI can only cause grief for all involved, and the more involved it is, the more grief it will cause. -- Gary R. Van Sickle Brewer. Patriot.
LPRng and ifhp packages ready
After spending a lot of time putzing around with LPRng, I decided to make a single package including both server and client components. I rewrote the postinstall and preremove scripts such that they will not actually install/start the server daemon. Further, I added instructions in /usr/doc/Cygwin/LPRng-3.8.19.README for how to start up the server. Here's the setup.hint file for LPRng: -CUT HERE-- # setup.hint for LPRng sdesc: LPRng: the next generation print daemon ldesc: LPRng: the next generation print daemon category: Net requires: cygwin openssl -CUT HERE-- Here's the setup.hint for ifhp. -CUT HERE-- # setup.hint for ifhp sdesc: print filter for use with LPRng ldesc: A print filter for use with LPRng. It may, in fact, be used with other lpd software, or even as a standalone filter, though you will likely have to fight with it to get the desired effect. category: Net requires: cygwin LPRng -CUT HERE-- Here are the URLs: https://www.as.cmu.edu/~geek/LPRng/LPRng-3.8.19-1-src.tgz https://www.as.cmu.edu/~geek/LPRng/LPRng-3.8.19-1.tar.bz2 https://www.as.cmu.edu/~geek/LPRng/setup.hint https://www.as.cmu.edu/~geek/ifhp/ifhp-3.5.10-1-src.tar.bz2 https://www.as.cmu.edu/~geek/ifhp/ifhp-3.5.10-1.tar.bz2 https://www.as.cmu.edu/~geek/ifhp/setup.hint
LPRng and ifhp packages ready
After spending a lot of time putzing around with LPRng, I decided to make a single package including both server and client components. I rewrote the postinstall and preremove scripts such that they will not actually install/start the server daemon. Further, I added instructions in /usr/doc/Cygwin/LPRng-3.8.19.README for how to start up the server. Here's the setup.hint file for LPRng: -CUT HERE-- # setup.hint for LPRng sdesc: LPRng: the next generation print daemon ldesc: LPRng: the next generation print daemon category: Net requires: cygwin openssl -CUT HERE-- Here's the setup.hint for ifhp. -CUT HERE-- # setup.hint for ifhp sdesc: print filter for use with LPRng ldesc: A print filter for use with LPRng. It may, in fact, be used with other lpd software, or even as a standalone filter, though you will likely have to fight with it to get the desired effect. category: Net requires: cygwin LPRng -CUT HERE-- Here are the URLs: https://www.as.cmu.edu/~geek/LPRng/LPRng-3.8.19-1-src.tgz https://www.as.cmu.edu/~geek/LPRng/LPRng-3.8.19-1.tar.bz2 https://www.as.cmu.edu/~geek/LPRng/setup.hint https://www.as.cmu.edu/~geek/ifhp/ifhp-3.5.10-1-src.tar.bz2 https://www.as.cmu.edu/~geek/ifhp/ifhp-3.5.10-1.tar.bz2 https://www.as.cmu.edu/~geek/ifhp/setup.hint
Re: nfs-server - status request for information
On Tue, Jan 21, 2003 at 07:39:26AM -0500, Earnie Boyd wrote: Robb, Sam wrote: A workaround is to create a regular directory, mount the Windows drive at that directory, and then export the directory. For example: $ mkdir -p /exports/c $ mount -f -s -b c:/ /exports/c $ echo /exports/c (ro,all_squash) /etc/exports Would another possible workaround be just a simple ``mkdir -p /cygdrive/c/cygwin/cygdrive/c'' (this assumes cygwin is installed in c:\cygwin)? I'd actually appreciate it if someone would actually fix the problem in cygwin rather than providing workarounds. cgf
Re: nfs-server - status request for information
Christopher Faylor wrote: On Tue, Jan 21, 2003 at 07:39:26AM -0500, Earnie Boyd wrote: Robb, Sam wrote: A workaround is to create a regular directory, mount the Windows drive at that directory, and then export the directory. For example: $ mkdir -p /exports/c $ mount -f -s -b c:/ /exports/c $ echo /exports/c (ro,all_squash) /etc/exports Would another possible workaround be just a simple ``mkdir -p /cygdrive/c/cygwin/cygdrive/c'' (this assumes cygwin is installed in c:\cygwin)? I'd actually appreciate it if someone would actually fix the problem in cygwin rather than providing workarounds. But workarounds are useful until then. My suggestion, if it works, will avoid adding an entry into the mount table. Earnie.
Re: Mirrors list order is snafued - What is the order supposed to be?
Gary R. Van Sickle wrote: On Mon, 20 Jan 2003, Lapo Luchini wrote: I guess the best would be to sort by ping time (smalest to bigger) to help reduce unnecessary trans-oceanic downloads. But of course it would need to check them each time... or may it be cached in the local setup.ini? Ping time would probably be rather unfriendly to the mirrors :-) Would this seriously be a concern? I can't imagine that the cygwin user base is that update-happy that they'd be flooding download servers (which would have to serve them multimegabytes anyway) with pings. Especially when we still have folks going, Hi, I recently upgraded from B6. Why did you break everything?. I don't know. But pinging 30 to 40 servers seems rather a heavyweight solution. I was thinking treeview Continent/Country/Site. NOO!! NOT MORE TREEVIEWS!!! ;-) Seriously, what I'd really like to see us work towards is a UI-less mirror selection system as the default. 99% of users couldn't give a whit which server the stuff is coming from, as long as it works. Hence, a UI can only cause grief for all involved, and the more involved it is, the more grief it will cause. Nevertheless, wouldn't you agree that the treeview I proposed above would be an improvement over the current listview? Max.
Re: Mirrors list order is snafued - What is the order supposedto be?
On Wed, 2003-01-22 at 05:55, Max Bowsher wrote: Nevertheless, wouldn't you agree that the treeview I proposed above would be an improvement over the current listview? No. There are several facets to resolve in the design... 1) Where do custom mirrors go? 2) What if all the mirrors in region X are slow, or update slowly? 3) What improvements does it give to the process of choosing a mirror? Or to put it another way: what use case is best served by the proposed tree view over a (say) reliability sorted plain old' list. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Integrating Ralf's rebase into setup.exe
Ralf,
On Sat, Jan 04, 2003 at 12:16:57AM +0100, Ralf Habacker wrote:
This seems mostly to be fixed in the recent cvs release.
The attached patch enables libimagehelper.a to be usable by C source
too.
Thanks,
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Index: imagehelper.h
===
RCS file: /cvsroot/kde-cygwin/tools/rebase/imagehelper.h,v
retrieving revision 1.1
diff -u -p -r1.1 imagehelper.h
--- imagehelper.h 2 Jan 2003 17:03:13 - 1.1
+++ imagehelper.h 21 Jan 2003 12:31:11 -
@@ -23,6 +23,10 @@
#include windows.h
+#ifdef __cplusplus
+extern C {
+#endif
+
BOOL ReBaseImage(
PSTR CurrentImageName,
PSTR SymbolPath,// ignored
@@ -89,6 +93,7 @@ DWORD SetImageHelperDebug(
DWORD level
);
-
-
+#ifdef __cplusplus
+}
+#endif
#endif
Index: rebaseimage.cc
===
RCS file: /cvsroot/kde-cygwin/tools/rebase/rebaseimage.cc,v
retrieving revision 1.4
diff -u -p -r1.4 rebaseimage.cc
--- rebaseimage.cc 3 Jan 2003 23:16:05 - 1.4
+++ rebaseimage.cc 21 Jan 2003 12:31:11 -
@@ -22,6 +22,7 @@
#include sstream
#include objectfile.h
+#include imagehelper.h
BOOL ReBaseImage(
PSTR CurrentImageName,
RE: Integrating Ralf's rebase into setup.exe
Hi Jason, The attached patch enables libimagehelper.a to be usable by C source too. Applied. Thanks for fixing this. Ralf
Pine-4.53-1
Hello, I have packed a new distribution of the popular e-mail client Pine. Version 4.53 is the stable release of the 4.5X series. This would be the first release for Cygwin in this series. Here are the relevant links: http://www.math.washington.edu/~chappa/cygwin/pine-4.53-1-src.tar.bz2 http://www.math.washington.edu/~chappa/cygwin/pine-4.53-1.tar.bz2 http://www.math.washington.edu/~chappa/cygwin/setup.hint In case you are interested in what's new in Pine, here's a brief description: * Extended thread support (fancy thread interface). * Rudimentary support of character set conversion. * Extended filter/roles functionality. * Fixed bugs in justification in the default editor (it works way better now!). * Cygwin port is official. This means that no more patches are needed to build a version of Pine suitable for cygwin. All you need to do is to unpack the source code and execute the command ./buildcyg cyg. (You still need a patch to be able to fix some bugs found while running Pine in the default cygwin terminal). -- Eduardo http://www.math.washington.edu/~chappa/pine/
RE: Mirrors list order is snafued - What is the order supposed to be?
[snip] Ping time would probably be rather unfriendly to the mirrors :-) Would this seriously be a concern? I can't imagine that the cygwin user base is that update-happy that they'd be flooding download servers (which would have to serve them multimegabytes anyway) with pings. Especially when we still have folks going, Hi, I recently upgraded from B6. Why did you break everything?. I don't know. But pinging 30 to 40 servers seems rather a heavyweight solution. On-line multiplayer games do exactly that all the time, so unless I'm missing something here, I really can't see it being a problem. Unless the pings in the games aren't real internet pings or something I was thinking treeview Continent/Country/Site. NOO!! NOT MORE TREEVIEWS!!! ;-) Seriously, what I'd really like to see us work towards is a UI-less mirror selection system as the default. 99% of users couldn't give a whit which server the stuff is coming from, as long as it works. Hence, a UI can only cause grief for all involved, and the more involved it is, the more grief it will cause. Nevertheless, wouldn't you agree that the treeview I proposed above would be an improvement over the current listview? Yes, but I think it adds needless complexity to that particular interface, and doesn't solve the real problem, which is, which of these selections gets me the stuff fastest?. Physical location gives you a hint, but the server across the street may be a 386 with a 14.4 modem and a dozen other Cygwinners downloading, while the one across the ocean may have a pipe the size of... well, I can't think of an appropriate similie, but a really fat pipe and no waiting. I think the best and easiest solution here would be to simply ping each server in the list, sort by ping, and display server.name.here | ping_in_ms in a two-column list box (which would probably have to be hand-rolled). I know ping isn't going to give you a definitive answer to the question either, but it is one step closer, and probably the best that we could realistically do. -- Gary R. Van Sickle Brewer. Patriot.
