[BUG] cygport-0.2.7 fails to build multiple binary packages
While tying to rebuild the gettext-0.15-1 package, (with the intent with the po-mode emacs mode), I noticed that it did not build correctly any more. The problem is that the postinstall/preremove scripts for all but the primary binary packages are ignored, and thus the packaging step fails. I have tried to correct this fault in the attached patch, but as it was done in a bit of a rush I probably broke as much as I corrected. Could someone familiar with cygport have a look at it, please? Some notes on the changes: * The __prepetc() postinstall function is staring to become too large, so some part were split out into separate functions: - The __prepetc_pre_post_old() now contains the old postinstall/preremove scripts handling. - The __prepetc_profile() now contains the old profile scripts handling. - The __prep_check_pre_post() now postinstall/preremove scripts chmod. * The __prepetc_pre_post() was added to handle postinstall/preremove scripts for multiple binary packages. * The prep_gnu_info.sh script added commands to the wrong postinstall/preremove script, if more than one was used. That is it assumed that all info files were located in the primary package, which is not true for the gettext package. This was replaced with the new prep_gnu_info() function, (not sure if this was an imrovement or not). This function now checks which package the info file belongs to and adds the command to the corresponding postinstall/preremove scripts. Unfortunately this change will probably break the postinstall/preremove scripts in the existing multiple binary packages. Coincidentally this also removes the need for the handcrafted postinstall/preremove scripts in the gettext package, so this change seems to be in line with the intent of the cygport goals. Test Package etc: = http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1/cygport-test http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1/cygport-test.patch http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1/gettext-0.15-2.tar.bz2 http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1gettext-0.15-2-src.tar.bz2 /Stefan B.
Please upload: aspell-sv-0.50.2-2
In-Reply-To: [EMAIL PROTECTED] --text follows this line-- Hi Please upload at your earliest convinience. http://www.update.uu.se/~stefanb/cygwin/release/aspell-sv/setup.hint http://www.update.uu.se/~stefanb/cygwin/release/aspell-sv/aspell-sv-0.50.2-2.tar.bz2 http://www.update.uu.se/~stefanb/cygwin/release/aspell-sv/aspell-sv-0.50.2-2-src.tar.bz2 Dr. Volker Zell wrote: stefanb writes: Hi, I would like to propose the new cygwin package aspell-sv and I am prepared to be the maintainer of this package. Debian includes aaspell-sv as stable, so no votes are needed: http://packages.debian.org/stable/text/aspell-sv Thank you in advance for you time in considering this package. Documentation lives in /usr/share/doc and NOT in /usr/doc. Otherwise GTG. Ciao Volker Thanks for the help. /Stefan B.
Re: [BUG] cygport-0.2.7 fails to build multiple binary packages
Stefan Björnelund wrote:
While tying to rebuild the gettext-0.15-1 package, (with the intent
with the po-mode emacs mode), I noticed that it did not build
correctly any more.
The gettext .cygport requires additional features not implemented by the
stock çygport-0.2.7 framework. In particular, the relocatable package
patch here:
http://sourceware.org/ml/cygwin/2006-11/msg00719.html
It's #3 on the list, but see also
http://cygwin.com/ml/cygwin/2007-01/msg00115.html
where I have withdrawn that patch (as it is now out of date and I'll
update it when I release the next version of gettext/libiconv).
FWIW, the gettext .cygport ALSO requires the following patch:
http://cygwin.com/ml/cygwin/2007-01/msg00115.html
And it *might* also require this patch:
http://cygwin.com/ml/cygwin/2007-01/msg00114.html
In any case, you won't have much luck until those patches are approved
by the cygport maintainer, and a new version of cygport is released.
However, that might be a while:
http://cygwin.com/ml/cygwin-talk/2006-q4/msg00159.html
Most of what your patch implemented already exists in
http://cygwin.com/ml/cygwin/2007-01/msg00115.html -- and THAT patch has
the advantage of NOT breaking other .cygports:
Unfortunately this change will probably break the
postinstall/preremove scripts in the existing multiple binary
packages. Coincidentally this also removes the need for the
handcrafted postinstall/preremove scripts in the gettext package,
so this change seems to be in line with the intent of the cygport
goals.
I think the added complexity -- and brittleness -- of check which
binary package a given info file belongs to, and add the install-info
command to a matching .postinstall/.preremove script is too high a
price for the minimal improvement in usability for a few oddball
packages like the gettext family.
The solution pursued in msg00115.html above is When necessary, allow
the maintainer to turn off install-info automation, and provide explicit
postinstall/preremove files specific to each subpackage. This provides
the maintainer with the most flexibility, without over-complicating the
cygport package's internal logic.
--
Chuck
cygwin gettext maintainer
P.S. I just noticed something: since Í withdrew the relocatable patch,
even if Yaakov integrates all 7 of the patches I posted on January 6 (so
far: 2 down, 5 to go), the gettext .cygport STILL will not work, even if
you do not attempt to enable the relocation part (that is, you leave the
following commented-out):
### Uncomment the following line to enable relocation support
#inherit relocatable.cygclass
This is because gettext.cygport's src_compile(), gettext_check*(),
src_test(), and src_install() functions all call the non-existant
__maybe_relocate()
function. Quick fix (assuming my other 5 patches are integrated into
the cygport framework) is to add the following to gettext's .cygport
file somewhere near the top:
__maybe_relocate() {
:
}
1.5.23 on vista: difficulties launching X
I'm experiencing difficulty starting X on a fresh install of cygwin on a fresh install of Windows Vista. I've tried both startxwin.sh and startx. startxwin.sh always fails, and startx sometimes succeeds. A copy of cygcheck output is attached. startxwin.sh fails in three ways. 1) Immediately after the system has been booted, a popup appears to notify me that sh.exe has exited, and X seems to be stalled. An X appears in the toolbar, and both xterm and XWin are in the cygwin process table (ps -aux). No xterm appears. A copy of the combined standard output and standard input are provided in startxwin.sh-outerr-postreboot. The xterm in the process table can be killed with kill -TERM. Attempts to launch an xterm fail. (I open a new cygwin window, set and export DISPLAY, and run xterm). XWin cannot be killed with kill -TERM. It can be killed with kill -9. All of the above is repeatable if the system is rebooted. I have seen the previous post of sh.exe exit that turned out not to be repeatable. Maybe the above will provide some insight on getting it to repeat. Without rebooting, what happens on subsequent runs of startxwin.sh depends on how I clean up from the first failed run. 2) If I clean up from a first failed run by killing the xterm and Xwin, subsequent runs of startxwin fail with a popup stating that Cygwin X has failed. The cause seems to be a lingering sh.exe process in the table. 3) If I clean up from a first failed run by dismissing the cygwin terminal window by clicking on the window-close button, the sh.exe process goes away, and startxwin.sh fails with a message like xterm 3228 child_copy: linked dll data write copy failed, Full output is attached as startxwin.sh-outerr. Unlike the previous poster who reported a similar error, there is no logitech camera or virus program running on the system. It is indeed a fresh install. startx sometimes succeeds and sometimes fails. It succeeds in 35 % of runs and fails in 65 % of runs. A contingency table indicates that success of successive runs are independent of one another: observed cell frequencies are very close to expected values. Again if startx is run immediately after a system reboot, it fails in a manner that is similar to that in which startxwin.sh fails. Subsequent runs sometimes work or not. If they work the X server exits normally when xterm that has been run in the foreground exits. When it fails, it too fails with the xterm child copy error, but that error is followed by a number of other messages as processes shut down. A combined output and error are attached as startx-outerr. Hope that helps, Dick Dick Repasky Center for Computational Cytomics UITS Cubicle 101.08 Indiana University USA [EMAIL PROTECTED] Cygwin Configuration Diagnostics Current System Time: Mon Jan 08 16:54:23 2007 Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6000 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Windows\system32 c:\Windows c:\Windows\System32\Wbem SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'rrepasky' PWD = '/home/rrepasky' HOME = '/home/rrepasky' MAKE_MODE = 'unix' HOMEPATH = '\Users\rrepasky' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\rrepasky\AppData\Roaming' HOSTNAME = 'rrepasky-PC' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 8, GenuineIntel' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/usr/bin' PROGRAMDATA = 'C:\ProgramData' USERDOMAIN = 'rrepasky-PC' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' !:: = '::\' TEMP = '/cygdrive/c/Users/rrepasky/AppData/Local/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'rrepasky' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Users\rrepasky' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\RREPASKY-PC' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\rrepasky\AppData\Local' !C: = 'C:\cygwin\bin' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/cygdrive/c/Users/rrepasky/AppData/Local/Temp' SYSTEMROOT = 'C:\Windows' PRINTER = 'hrothgar' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0208' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '1' SESSIONNAME = 'Console' COMPUTERNAME = 'RREPASKY-PC' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
Re: 1.5.23 on vista: difficulties launching X
Dick Repasky wrote: I'm experiencing difficulty starting X on a fresh install of cygwin on a fresh install of Windows Vista. I've tried both startxwin.sh and startx. startxwin.sh always fails, and startx sometimes succeeds. A copy of cygcheck output is attached. startxwin.sh fails in three ways. 1) Immediately after the system has been booted, a popup appears to notify me that sh.exe has exited, and X seems to be stalled. An X appears in the toolbar, and both xterm and XWin are in the cygwin process table (ps -aux). No xterm appears. A copy of the combined standard output and standard input are provided in startxwin.sh-outerr-postreboot. The xterm in the process table can be killed with kill -TERM. Attempts to launch an xterm fail. (I open a new cygwin window, set and export DISPLAY, and run xterm). XWin cannot be killed with kill -TERM. It can be killed with kill -9. All of the above is repeatable if the system is rebooted. I have seen the previous post of sh.exe exit that turned out not to be repeatable. Maybe the above will provide some insight on getting it to repeat. Without rebooting, what happens on subsequent runs of startxwin.sh depends on how I clean up from the first failed run. 2) If I clean up from a first failed run by killing the xterm and Xwin, subsequent runs of startxwin fail with a popup stating that Cygwin X has failed. The cause seems to be a lingering sh.exe process in the table. 3) If I clean up from a first failed run by dismissing the cygwin terminal window by clicking on the window-close button, the sh.exe process goes away, and startxwin.sh fails with a message like xterm 3228 child_copy: linked dll data write copy failed, Full output is attached as startxwin.sh-outerr. Unlike the previous poster who reported a similar error, there is no logitech camera or virus program running on the system. It is indeed a fresh install. Have you tried the suggestions mentioned in this thread? http://sourceware.org/ml/cygwin/2006-11/msg00059.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog mmap.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-01-09 11:18:57 Modified files: winsup/cygwin : ChangeLog mmap.cc Log message: * mmap.cc: Do bookkeeping in 4K pages, rather than in 64K chunks. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3702r2=1.3703 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mmap.cc.diff?cvsroot=srcr1=1.134r2=1.135
src/winsup/utils ChangeLog cygpath.cc utils.sgml
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-01-09 12:17:05 Modified files: winsup/utils : ChangeLog cygpath.cc utils.sgml Log message: * cygpath.cc (usage): Add -O and -F, remove tabs. (get_special_folder): New function. (get_user_folder): New function. (dowin): Add -O and -F, better -D, -P error handling. (main): Add -O and -F. * utils.sgml (cygpath): Document -O and -F. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.370r2=1.371 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/cygpath.cc.diff?cvsroot=srcr1=1.45r2=1.46 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/utils.sgml.diff?cvsroot=srcr1=1.61r2=1.62
src/winsup/cygwin ChangeLog syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-01-09 15:46:42 Modified files: winsup/cygwin : ChangeLog syscalls.cc Log message: * syscalls.cc (getpagesize): Change condition for clarity. (getsystempagesize): Ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3703r2=1.3704 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.421r2=1.422
Re: [Patch] cygpath -O and -F options (was: Two short scripts for Cygwin-Windows interoperation)
On Jan 8 19:32, Christian Franke wrote: Applied. However, may I ask you to do the patch against current CVS instead of the release the next time? It would also be nice if you could create the ChangeLog entry so that it's just a copy/paste job: 2007-01-07Christian Franke [EMAIL PROTECTED] ^^ ^^ Two spaces here and two spaces here * cygpath.cc (usage): Add -O and -F, remove tabs. (get_special_folder): New function. (get_user_folder): New function. (dowin): Add -O and -F, better -D, -P error handling. (main): Add -O and -F. * utils.sgml (cygpath): Document -O and -F. ^^^ One TAB here. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Support for Baud Rates above 250000 baud?
David le Comte wrote: I am running Cygwin on a PC that is running Windows XP. My Cygwin version is CYGWIN_NT-5.1 and it was downloaded and installed late last No, it's not. The output from uname tells us nothing about which version of Cygwin (or any of the other of dozens of packages you might have installed), rather it simply means that you are running Windows NT version 5.1, aka Windows XP. The current version of Cygwin is 1.5.23-2, and if you want to include helpful information try attaching the output of cygcheck -svr as requested in the posting instructions. Adding entries into termios.h for higher baudrates using the convention that B460800 was 0x01006, B50 was 0x01007, and B921600 was 0x01008 caused errors. #define B230400 0x01004 #define B256000 0x01005 /* 3 new entries - as an experiement to see if it works */ #define B460800 0x01006 #define B50 0x01007 #define B921600 0x01008 The calls to cfsetispeed() and cfsetospeed() failed. Not unsurprising, as one could assume that they had been using the original termios.h when they were compiled. This is a Very Bad Idea in general. You can't just add new defines to a header file and expect it to work. The header is an indication of what a library supports, it is a one-way street. 1) Is there a build available for Cygwin (on a Windows platform) that has support for higher baud rates? If so, does anyone know where I could find it? That's kind of an odd question. Cygwin is open source and of course people are free to take it and patch it to do whatever they want, so it's certainly possible that someone has patched their Cygwin to allow other baud rate settings. But if they did it would be a separate project and off-topic for this list, and I'm not aware of any such thing existing. Occasionally new features are added to the code which have yet to be included in released versions, in which case users are directed to try the new code in the Cygwin snapshots which are provided on cygwin.com, but in this case that's not an issue as I'm not aware of any recent changes to this part of the code. 2) Assuming there is no such build available, are there plans to add support for higher baud rates? If so, does anyone know when? 2) Would it be difficult to download the appropriate source files, modify them, and make my own Cygwin build? (The idea of doing this terrifies me by the way). If it is possible, could someone give me some pointers on how to do this? If you read the Win32 API docs for SetCommState() http://msdn2.microsoft.com/en-us/library/aa363436.aspx and struct DCB: http://msdn2.microsoft.com/en-us/library/aa363214.aspx you see the canonical list of #defined baud rates that Win32 supports. But there's also this tidbit: This member can be an actual baud rate value, or one of the following indexes. So from this we can see that Win32 supports arbitrary baud rates (with a certain list of #defined standard ones) whereas the POSIX termios.h / speed_t API that Cygwin is emulating does not have the capability to set the rate arbitarily. Thus, any baud rate can be supported, but the code has to exist to do the mapping of the symbolic constant. You can see this happening in fhandler_serial.cc, which does the actual mapping of termios to filling the Win32 struct DCB: case B110: state.BaudRate = CBR_110; break; case B300: state.BaudRate = CBR_300; break; case B600: state.BaudRate = CBR_600; break; case B1200: state.BaudRate = CBR_1200; break; case B2400: state.BaudRate = CBR_2400; break; case B4800: state.BaudRate = CBR_4800; break; case B9600: state.BaudRate = CBR_9600; break; case B19200: state.BaudRate = CBR_19200; break; case B38400: state.BaudRate = CBR_38400; break; case B57600: state.BaudRate = CBR_57600; break; case B115200: state.BaudRate = CBR_115200; break; case B230400: state.BaudRate = 230400 /* CBR_230400 - not defined */; break; default: /* Unsupported baud rate! */ termios_printf (Invalid t-c_ospeed %d, t-c_ospeed); set_errno (EINVAL); return -1; } Thus it appears that it should be easily possible to add a Bx define for any desired baud rate, as long as you update termios.h and fhandler_serial.cc to know about it. So yes, you could just make this change and rebuild a local cygwin1.dll that supports it. Building cygwin1.dll is not much different than any other autoconf-style package and there are instructions in the Users Guide (or the FAQ, I can't remember.) It would be better however to somehow figure out a list of the missing standard baud rates that are in common use and submit a patch to add them upstream, rather than just ad hoc adding whatever you need. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports:
Re: 1.7.0 CVS mmap failure
On Sun, Jan 07, 2007 at 11:58:44AM +0100, Corinna Vinschen wrote:
Lots of comments throughout the file...
Unfortunately the code-path is less than clear to follow. This may be
a matter of opinion but it's fairly complex and looks to have history in
it.
In the 2nd strace, I changed the mmap logic to stop trying to align the 1st
map on a 4k granularity boundary and just allocate a single map w/ 64k of
left over dead space (what I would typically expect in posix land). I also
added more debug info at various stages to try and figure things out. When
changing it to use 64k period, the mmaps are both successful - which is
good,
but VirtualProtect always fails, no matter what, on unmap.
The strace is rather useless without the (hopefully very short) source
code of the (hopefully very small) testcase.
Okay, I understand where you're coming from. Where I'm coming from is that it
is difficult to generate a test case that actually demonstrates the issue
outside of the scope of my application. Suffice to say, I do see the errors in
strace output - and I can see MapViewNT returning an error in the double-map
-so-we-can-have-4k-pseudopages version. Do you have a 4GB machine running w/
PAE enabled in which to even test a test case if I could come up with one which
consistently works? Also, VirtualProtect fails on unmap everytime, a test case
for this is a matter of any old map/unmap it seems.
33 /* Filler pages are the pages from the last file backed page to the next
3464K boundary. These pages are created as anonymous pages, but with
35the same page protection as the file's pages, since POSIX applications
36expect to be able to access this part the same way as the file pages. */
37 #define __PROT_FILLER 0x400
1247 if (orig_len)
1248 {
1249 /* If the requested length is bigger than the file size, the
1250 remainder is created as anonymous mapping. Actually two
1251 mappings are created, first the reminder from the file end to
1252 the next 64K boundary as accessible pages with the same
1253 protection as the file's pages, then as much pages as necessary
1254 to accomodate the requested length, but as reserved pages which
1255 raise a SIGBUS when trying to access them. AT_ROUND_TO_PAGE
1256 and page protection on shared pages is only supported by 32 bit
NT,
1257 so don't even try on 9x and in WOW64. This is accomplished by not
1258 setting orig_len on 9x and in WOW64 above. */
1259 orig_len = roundup2 (orig_len, pagesize);
1260 len = roundup2 (len, getsystempagesize ());
^
Why? This also violates the to the next 64k boundary as accessible pages part.
The pagesize is 64k, the granularity for addressing is 4k. Don't see why 4k has
to be mixed in here by calling getsystempagesize() or am I totally missing
something here?
1261
1262 if (orig_len - len)
1263 {
1264 orig_len -= len;
1265 size_t valid_page_len = orig_len % pagesize;
1266 size_t sigbus_page_len = orig_len - valid_page_len;
1267
1268 caddr_t at_base = base + len;
The system shall always zero-fill any partial page at the end of
an object. Further, the system shall never write out any
modified portions of the last page of an object which are beyond
its end. References within the address range starting at pa
and continuing for len bytes to whole pages following the end of an
object shall result in delivery of a SIGBUS signal.
Which I would expect to be: |0 len 65536| on Windows.
/* start */
#include fcntl.h
#include stdio.h
#include unistd.h
#include sys/mman.h
#include sys/stat.h
int main(int argc, char **argv)
{
struct stat st;
long psz, r;
char *q;
char a;
int fd;
if (argc = 2) return -1;
if ((fd = open(argv[1], O_RDONLY)) == -1) {
perror(open);
return -1;
}
if (fstat(fd, st) == -1) {
perror(stat);
return -1;
}
psz = sysconf(_SC_PAGESIZE);
fprintf(stderr, psz = %ld\n, psz);
fprintf(stderr, st.st_size == %lu\n, (long)st.st_size);
q = mmap(0, st.st_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
if (q == MAP_FAILED) {
perror(mmap);
return -1;
}
if (*argv[2] == 'r') {
for (r = 0; ; r++) {
if (r st.st_size)
fprintf(stderr, %lu , r);
a = q[r];
}
} else if (*argv[2] == 'w') {
for (r = 0; ; r++) {
if (r st.st_size)
fprintf(stderr, %lu , r);
q[r] = a;
}
}
return 0;
}
/* end */
Re: 1.7.0 CVS mmap failure
Also, check this out: http://blogs.msdn.com/oldnewthing/archive/2003/10/08/55239.aspx Meant to also include: http://support.microsoft.com/kb/125713 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CR/LF problems after upgrade
On Jan 8 21:27, Eric Blake wrote: http://cygwin.com/acronyms/#TOFU - reformatted -Original Message- From: cygwin-owner AT cygwin DOT com ^ http://cygwin.com/acronyms/#PCYMTNQREAIYR - raw email munged According to Eramo, Mark on 1/8/2007 9:33 AM: I use tsch as opposed to bash. Is there something different that needs to be set in this shell? tcsh is not the same as bash, and SHELLOPTS does not affect tcsh (although even with tcsh, you probably end up invoking a lot of sh scripts that are affected). You'll have to show a simple test case that someone else can reproduce before we can offer help. Don't use CR/LF in tcsh scripts. Cygwin's standard tcsh doesn't like them. There's an experimental 6.14.00-6 release which has some tweaks to handle CR/LF, but I don't think I'll follow through with this. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
make: Facing problem while compiling using make 3.80
Hi, I am trying to compile my code using cywin. My source code has several directories each having makefiles which gives the rules to compile files contained in the folder. When i m compiling, make is throwing an error: Serious error: C3052E: couldn't read file path/filename C3050U: Compilation aborted. Strangely, make is giving errors only in one folder whereas it is able to properly compile files contained in other folders. I am not able to figure out the problem. make version - GNU make 3.80 Host machine - Windows XP running on intel centrino Cywin setup-version - 2.510.2.2 I don't know whether this is some kind of bug in make. Can someone suggest how to fix it or if someone has faced similar problem and fixed it or some other version of make where it works well. regards Send instant messages to your online friends http://uk.messenger.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Fw: help win winxp install
On 09 January 2007 01:06, Morgan Gangwere wrote: well, there is a fundamental flaw here in the distribution system then. i have looked at the versions from (agast!) three different mirrors and they have so far been completely different. It would have been helpful if you said *which* mirrors. i have found (long ago, dont know if this was fixed) a version 0.3.4 of bash _on_ that mirrors package list. Since the mirrors list and the package list are two completely different things, I think you have at least some degree of confusion here. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: make: Facing problem while compiling using make 3.80
On 09 January 2007 10:07, Faisal Sajjad wrote: Hi, I am trying to compile my code using cywin. My source code has several directories each having makefiles which gives the rules to compile files contained in the folder. When i m compiling, make is throwing an error: Serious error: C3052E: couldn't read file path/filename C3050U: Compilation aborted. No. That's not an error from make at all. That's an error from your compiler. Strangely, make is giving errors only in one folder whereas it is able to properly compile files contained in other folders. No. Make isn't having the problem. The compiler is having the problem. I am not able to figure out the problem. make version - GNU make 3.80 That's a bit old, but it isn't the problem. Host machine - Windows XP running on intel centrino Cywin setup-version - 2.510.2.2 Telling us which version of setup you used to install cygwin isn't useful; that's only the version of setup.exe itself, and doesn't contain any information about what package versions were current when you ran it. I don't know whether this is some kind of bug in make. I do. It isn't. Can someone suggest how to fix it or if someone has faced similar problem and fixed it or some other version of make where it works well. I think the real problem /might/ be (because you haven't included an example that I could use to reproduce the problem) that you're trying to pass a cygwin POSIX-style path to a windows msvc-based compiler that has no idea what it means? I'm guessing that the reason it sometimes works and sometimes doesn't is because you're sometimes passing full paths to it, and sometimes just bare filenames in the current directory, which of course are exactly the same in both windows and unix style. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 CVS mmap failure
On Jan 9 01:04, Christopher Layne wrote:
On Sun, Jan 07, 2007 at 11:58:44AM +0100, Corinna Vinschen wrote:
Lots of comments throughout the file...
Unfortunately the code-path is less than clear to follow. This may be
a matter of opinion but it's fairly complex and looks to have history in
it.
Sure enough :)
The strace is rather useless without the (hopefully very short) source
code of the (hopefully very small) testcase.
Okay, I understand where you're coming from. Where I'm coming from is that it
is difficult to generate a test case that actually demonstrates the issue
outside of the scope of my application. Suffice to say, I do see the errors in
strace output - and I can see MapViewNT returning an error in the double-map
-so-we-can-have-4k-pseudopages version.
I'm under the impression you're getting something upside-down. Windows
has 4K system pages, but an allocation granularity of 64K. For a long
time I stubbornly tried to stick with 4K pagesize for POSIX applications,
but the code got more and more complicated because there was always yet
another situation which just didn't work correctly due to the 64K
allocation granularity.
So I decided to give up and change the POSIX-side pagesize to 64K
which really simplified mmap. However, there's this one problem
left: While you can only allocate usefully in 64K steps, the size of
the memory area allocated for a file is only 4K aligned, thus leaving
((roundup(filesize,64K) - roundup(filesize,4K)) / 4K) pages in the last
64K chunk of a file mapping unmapped. The code you quote below is
adding a 4K aligned anonymous mapping attached to the file mapping so
that the POSIX application can access the whole 64K page.
Do you have a 4GB machine running w/
PAE enabled in which to even test a test case if I could come up with one
which
consistently works?
No.
Also, VirtualProtect fails on unmap everytime, a test case
for this is a matter of any old map/unmap it seems.
I see what happens. I applied a patch for that.
1247 if (orig_len)
1248 {
1249 /* If the requested length is bigger than the file size, the
1250 remainder is created as anonymous mapping. Actually two
1251 mappings are created, first the reminder from the file end to
1252 the next 64K boundary as accessible pages with the same
1253 protection as the file's pages, then as much pages as necessary
1254 to accomodate the requested length, but as reserved pages which
1255 raise a SIGBUS when trying to access them. AT_ROUND_TO_PAGE
1256 and page protection on shared pages is only supported by 32 bit
NT,
1257 so don't even try on 9x and in WOW64. This is accomplished by
not
1258 setting orig_len on 9x and in WOW64 above. */
1259 orig_len = roundup2 (orig_len, pagesize);
1260 len = roundup2 (len, getsystempagesize ());
^
Why? This also violates the to the next 64k boundary as accessible pages
part.
The pagesize is 64k, the granularity for addressing is 4k. Don't see why 4k
has
to be mixed in here by calling getsystempagesize() or am I totally missing
something here?
Yes. The pagesize is 4K in Windows, the allocation granularity is 64K.
orig_len is what should have been allocated considering 64K POSIX pages,
len is what the system actually allocated using 4K Windows pages.
(orig_len - len) is the size of the yet to be allocated anonymous
mapping, which consists of up to two parts. First, the filler which
is normally accessible to the application, called valid_page_len here:
1264 orig_len -= len;
1265 size_t valid_page_len = orig_len % pagesize;
which is the above mentioned
((roundup(filesize,64K) - roundup(filesize,4K)) / 4K)
Second, the remainder which is handled by a SIGBUS area:
1266 size_t sigbus_page_len = orig_len - valid_page_len;
which is (roundup(requested_allocation_size,64K) - (roundup(filesize,64K)))
The system shall always zero-fill any partial page at the end of
an object. Further, the system shall never write out any
modified portions of the last page of an object which are beyond
its end. References within the address range starting at pa
and continuing for len bytes to whole pages following the end of an
object shall result in delivery of a SIGBUS signal.
Yes, exactly. The partial page at the end of an object is what is
named valid_page_len above plus the tiny reminder within the last 4K
page of the Windows file mapping.
Which I would expect to be: |0 len 65536| on Windows.
I don't understand this sentence here. What is expected to be 64K?
Anyway, I though the comments in the source should have made this
all clear already.
I don't see anything unusual happen in your small testcase. Looks
good to me. Why do you expect to be unable to read pages beyond the
end of the mapping?
Re: 1.7.0 CVS mmap failure
Real quick here and I'll follow up tomorrow. I don't get SIGSEGV in my application ever. I get an error back from mmap saying it cannot allocate memory when i'm simply trying to open a small file! The original events ere posted up in that first part of the strace - which is unmodified original behavior. Things did not start happening UNTIL the MEM_TOP_DOWN change. My code does not do ANYTHING out of the ordinary that it wasn't doing before and working completely fine with. On Tue, Jan 09, 2007 at 12:56:43PM +0100, Corinna Vinschen wrote: Yet the latter works for me, whereas the former results in mmap() failures for files smaller than the page size. The latter works for you because it's wrong. Since it uses 64K, mmap thinks it doesn't have to add filler pages. So adding the filler pages can't go wrong. So you can access your file, but you get the SEGV exaclty after the last 4K page of the file, not at the end of the expected 64K page. Corinna -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: help win winxp install
On Tue, Jan 09, 2007 at 10:25:33AM -, Dave Korn wrote: On 09 January 2007 01:06, Morgan Gangwere wrote: well, there is a fundamental flaw here in the distribution system then. i have looked at the versions from (agast!) three different mirrors and they have so far been completely different. It would have been helpful if you said *which* mirrors. Details? What a novel concept. I don't think the concept will catch on since making statements like they have...been completely different is much easier than clearly elucidating the actual differences. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 CVS mmap failure
On Jan 9 04:04, Christopher Layne wrote: Real quick here and I'll follow up tomorrow. I don't get SIGSEGV in my application ever. I get an error back from mmap saying it cannot allocate memory when i'm simply trying to open a small file! The original events ere posted up in that first part of the strace - which is unmodified original behavior. Things did not start happening UNTIL the MEM_TOP_DOWN change. Yes, I know. I never said you get a SEGV from mmap, but you get the SEGV in your testapp. That's what I'm referring to. mmap fails (just fails, no SEGV, yes, I know) because it fails to generate the filler pages. This should be really clear know from what I wrote. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 CVS mmap failure
On Tue, Jan 09, 2007 at 01:23:58PM +0100, Corinna Vinschen wrote: Yes, I know. I never said you get a SEGV from mmap, but you get the SEGV in your testapp. That's what I'm referring to. mmap fails (just fails, no SEGV, yes, I know) because it fails to generate the filler pages. This should be really clear know from what I wrote. Sorry, I should have indicated that the test app was purely used to test out mapping regions and boundaries - not show off the original issue. I found certain things about the boundaries on windows to be peciluar. When I looked up what getpagesize() and getsystempagesize() return, respectively, I could have sworn that GPS returned page size and GSPS returned allocation granularity (both via GetSytemInfo). -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 CVS mmap failure
On Tue, Jan 09, 2007 at 12:56:43PM +0100, Corinna Vinschen wrote:
Okay, I understand where you're coming from. Where I'm coming from is that
it
is difficult to generate a test case that actually demonstrates the issue
outside of the scope of my application. Suffice to say, I do see the errors
in
strace output - and I can see MapViewNT returning an error in the double-map
-so-we-can-have-4k-pseudopages version.
I'm under the impression you're getting something upside-down. Windows
has 4K system pages, but an allocation granularity of 64K. For a long
time I stubbornly tried to stick with 4K pagesize for POSIX applications,
but the code got more and more complicated because there was always yet
another situation which just didn't work correctly due to the 64K
allocation granularity.
extern C size_t
getpagesize ()
{
if (!system_info.dwPageSize)
GetSystemInfo (system_info);
return (size_t) system_info.dwAllocationGranularity;
}
size_t
getsystempagesize ()
{
if (!system_info.dwAllocationGranularity)
GetSystemInfo (system_info);
return (size_t) system_info.dwPageSize;
}
Turns out I was reading these backwards, yes.
$ ./psz
psz == 4096, ag == 65536
I'll try and reanalyze some of the other stuff tomorrow.
-cl
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: CR/LF problems after upgrade
-Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Monday, January 08, 2007 11:27 PM To: cygwin@cygwin.com; Eramo, Mark Subject: Re: CR/LF problems after upgrade -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://cygwin.com/acronyms/#TOFU - reformatted -Original Message- From: cygwin-owner AT cygwin DOT com ^ http://cygwin.com/acronyms/#PCYMTNQREAIYR - raw email munged On 1/5/07, fschmidt wrote: Okay, how can I set SHELLOPTS before invoking bash? I tried it in the /etc/profile but that didn't work. According to Eramo, Mark on 1/8/2007 9:33 AM: I have the same problem and I set this under the Windows System Variables as well as in the Cygwin shell window but neither worked. Actually, it sounds like you don't have the same problem. I use tsch as opposed to bash. Is there something different that needs to be set in this shell? tcsh is not the same as bash, and SHELLOPTS does not affect tcsh (although even with tcsh, you probably end up invoking a lot of sh scripts that are affected). You'll have to show a simple test case that someone else can reproduce before we can offer help. Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] Thanks for the reply Eric. I actually tried this using bash first but I think I maybe see what is wrong. First, I added the following Environment Variable SHELLOPTS=igncr I then Opened Cygwin (envoking bash) and issued the SET command to see the environment. As you can see below, the SHELLOPTS variable does not have igncr included SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:igncr:interactive -comments:monitor So, I just need to figure out why it's not picking it up (this must be read only variable) and then how to get it added. Once I do that, I can hopefully run an appropriate test. Thanks, Mark -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: CR/LF problems after upgrade
On 09 January 2007 14:36, Eramo, Mark wrote: MARK! Please pay attention to the polite requests Eric has made, particularly this one: -Original Message- From: cygwin-owner AT cygwin DOT com ^ http://cygwin.com/acronyms/#PCYMTNQREAIYR - raw email munged because I DO NOT WANT TO GET SPAMMED IF YOU REPLY TO THIS EMAIL. First, I added the following Environment Variable SHELLOPTS=igncr I then Opened Cygwin (envoking bash) and issued the SET command to see the environment. As you can see below, the SHELLOPTS variable does not have igncr included SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:igncr:interactive ^ -comments:monitor :) Looks like it does to me; I suggest you proceed with that test, because it should be working now and if there are any further problems that would indicate a definite bug. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 CVS mmap failure
On Jan 7 11:51, Corinna Vinschen wrote: On Jan 5 15:15, Brian Ford wrote: On Fri, 5 Jan 2007, Corinna Vinschen wrote: overmap? -v please? Posix symantics: mmap fixed region x, mmap fixed region y which is a subregion of x where y replaces x's mapping. AFAIK that doesn't work on Windows. But, somebody has to test it(tm). I just tried it, it doesn't work. As I expected I get a status C018, STATUS_CONFLICTING_ADDRESSES, which translates into Win32 error 487 ERROR_INVALID_ADDRESS. You have to unmap the space before you can reuse it for another mapping. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 CVS mmap failure
On Tue, 9 Jan 2007, Christopher Layne wrote:
extern C size_t
getpagesize ()
{
if (!system_info.dwPageSize)
GetSystemInfo (system_info);
return (size_t) system_info.dwAllocationGranularity;
}
size_t
getsystempagesize ()
{
if (!system_info.dwAllocationGranularity)
GetSystemInfo (system_info);
return (size_t) system_info.dwPageSize;
}
Um..., don't these functions look backward to anyone else in that the test
for local cache initialization is not what gets returned. I know it
really doesn't matter functionally, but it sure looks confusing ;-).
--
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.7.0 CVS mmap failure
On Jan 9 09:33, Brian Ford wrote:
On Tue, 9 Jan 2007, Christopher Layne wrote:
extern C size_t
getpagesize ()
{
if (!system_info.dwPageSize)
GetSystemInfo (system_info);
return (size_t) system_info.dwAllocationGranularity;
}
size_t
getsystempagesize ()
{
if (!system_info.dwAllocationGranularity)
GetSystemInfo (system_info);
return (size_t) system_info.dwPageSize;
}
Um..., don't these functions look backward to anyone else in that the test
for local cache initialization is not what gets returned. I know it
really doesn't matter functionally, but it sure looks confusing ;-).
Agreed.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
username should be lower-case for $USER
I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. On unix based hosts I log into, it is always lower-case. So if I try to SSH to another machine where I have the same login name, I can't let SSH automatically default to $USER because the case isn't right. *Even if* Windows user names are case sensitive and so there is a difference between DSMILEY and dsmiley (are they?, I don't know) I think $USER should be made to be all lower-case to be consistent with unix environments. ~ David Smiley -- View this message in context: http://www.nabble.com/username-should-be-lower-case-for-%24USER-tf2947156.html#a8241120 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: activestate perl on cygwin
But how do you then install modules? Just like in unix from the tarballs that are intended for unix? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: username should be lower-case for $USER
David Smiley escribe: I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. On unix based hosts I log into, it is always lower-case. So if I try to SSH to another machine where I have the same login name, I can't let SSH automatically default to $USER because the case isn't right. *Even if* Windows user names are case sensitive and so there is a difference between DSMILEY and dsmiley (are they?, I don't know) I think $USER should be made to be all lower-case to be consistent with unix environments. Making ssh use different user names for logging in to different hosts is obvious enough IMO. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 [1]La media hostiaj. [EMAIL PROTECTED] 1. http://lamediahostia.blogspot.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: activestate perl on cygwin
[EMAIL PROTECTED] wrote: But how do you then install modules? Just like in unix from the tarballs that are intended for unix? Essentially, yes. Just run CPAN (perl -MCPAN -e shell) and type install Foo::Bar just as you would on any unix system. You don't have to actually know or care about tarballs, CPAN does all that for you. Note that if a module has a prerequisite for a library you must install that library first, just as you would on a unix system. But modules that require this are few and far between (e.g. DBD::MySql requires libmysqlclient.) When in doubt, the answer to any Cygwin question should be as you would on any posix system. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: username should be lower-case for $USER
On 09 January 2007 16:25, David Smiley wrote: I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. On unix based hosts I log into, it is always lower-case. So if I try to SSH to another machine where I have the same login name, I can't let SSH automatically default to $USER because the case isn't right. *Even if* Windows user names are case sensitive and so there is a difference between DSMILEY and dsmiley (are they?, I don't know) I think $USER should be made to be all lower-case to be consistent with unix environments. It would /not/ be consistent with unix environments. Just because *you* haven't used one with capitals in usernames does *not* mean they do not exist. The Opengroup posix spec quite explicitly allows different cases: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_ 426 cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: username should be lower-case for $USER
I know this is clearly a minor problem I am reporting, but a problem nonetheless. Ismael Valladolid Torres-4 wrote: David Smiley escribe: I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. On unix based hosts I log into, it is always lower-case. So if I try to SSH to another machine where I have the same login name, I can't let SSH automatically default to $USER because the case isn't right. *Even if* Windows user names are case sensitive and so there is a difference between DSMILEY and dsmiley (are they?, I don't know) I think $USER should be made to be all lower-case to be consistent with unix environments. Making ssh use different user names for logging in to different hosts is obvious enough IMO. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 [1]La media hostiaj. [EMAIL PROTECTED] 1. http://lamediahostia.blogspot.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- View this message in context: http://www.nabble.com/username-should-be-lower-case-for-%24USER-tf2947156.html#a8241408 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated (and new) cygport patches
2007/1/6, Charles Wilson [EMAIL PROTECTED]: [2] cygport-mixedmode.patch [*] NOTE: the PATCH_URI functionality in 0.2.7 is not sufficient to reproduce all of the functionality of this patch. Sometimes upstream patches are not distributed as .patch files. They can be .zip files that contain new files to be copied into srcdir plus a script to run that itself modifies srcdir files (as in rxvt-unicode-X-7.7-5) or tarballs that include a patch as well as some binary test images (as in lossless jpeg). clamav would also benefit from charles' patch for adding the binary positive testcases, which cannot be added as src patch. only for check though. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Exclude cygwin folder from malware scans?
While it's true that not many viruses will target Cygwin directly, there are some that target folders based on string matching. For instance, a few years ago my computer at work caught a virus which apparently tried to spread itself through peer-to-peer file-sharing. It looked for folders with the string share in them, and then put in a bunch of doubtless infected files with tempting names(BRITNEY SPEARS NAKED!, etc.)in them. So I found a bunch of these files sitting in the C:\Cygwin\usr\share tree. While they were doubtless relatively harmless where they were, and weren't going to be shared over the Internet and infect anyone that way, I still didn't want to keep them around. This may also have been the virus that stopped any program with the substring sh.exe in it from running, presumably because they were aware that such a program could be used to kill the executing virus process. Made it hard to run Cygwin.bat. In other words, while bad virus checkers do seem to be the bane of functional Cygwin installations (though I've never had problems with AVG), you can't trust the Cygwin tree to never be targeted. -- --Alfvaen (Web page: http://www.telusplanet.net/public/alfvaen/ ) Current Album--LFO:Life Is Good Current Book--Steven Brust:Dzur You're too kind for your own good; you're too good for your own kind. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: activestate perl on cygwin
On 1/9/07, Brian Dessent wrote: moka at hol dot gr wrote: But how do you then install modules? Just like in unix from the tarballs that are intended for unix? Essentially, yes. Just run CPAN (perl -MCPAN -e shell) and type install Foo::Bar just as you would on any unix system. You don't have to actually know or care about tarballs, CPAN does all that for you. One caveat. If you are behind a proxy server that requires authentication, ActiveState's PPM install tools are much easier to get reliably working than the various command-line tools that CPAN uses (wget, lynx, ncftp, Net::FTP, etc). -Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compile-time detection of EOL translation mode (CLISP)
2007/1/4, Dave Korn [EMAIL PROTECTED]: On 04 January 2007 18:58, Aaron Brown wrote: Dave Korn wrote: What is the /end/ result you're trying to achieve here? When CLISP does text output, it opens the file in binary mode and does EOL translation itself, according to the requested line terminator mode. For instance, the following function writes a file with LF, CRLF, or CR EOLs depending on whether its argument is :unix, :dos, or :mac. That works exactly as intended. Good, and indeed, CLISP should probably not care either way about the mount mode on which it writes these files, because that's the whole point of textmounts: to provide a way for the user to instruct cygwin (the kernel, effectively) to override the application's choice at a lower level when needed. My problem is that if I don't specify a :line-terminator, :dos is used instead of unix. (This is controlled by *default-file-encoding*, which itself is set by line 2571 of encoding.d when CLISP is compiled.) Ok, that is simply the wrong default, and I think it is /that/ which needs to be fixed. The reason I expect :unix to be the default rather than :dos is that when I ran the Cygwin setup.exe, I selected the Unix / binary (RECOMMENDED) radio button under Default Text File Type. Is this expectation unwarranted? Yes, it is really; unless CLISP used some compile-time autoconf test to figure this out and adjust that default you mentioned, how else could it make a difference? The one-sentence version of the problem: CLISP writes newlines as \r\n by default, when I want the default to be \n. I could just specify :unix every time, but that's a hassle and is (as far as I can tell) impossible with standard output. This smacks of a build/packaging error to me, but perhaps it was a deliberate decision; we need to hear from the CLISP maintainer. Without having looked into building CLISP, I don't know whether it would just need an option when configuring or a #define patched into the source somewhere. The maintainer is now back from holidays. We really have to ask upstream Sam why he wanted to use global DOS EOL for cygwin. Probably to support default textmounts. But then defined(UNIX) (O_BINARY != 0) seems to only target cygwin and looks like an upstream bug to me. If binary then do binary and not DOS. Thanks for the report! I'll check and update it then. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: username should be lower-case for $USER
Change the username to lower case on Your Windows login or at least within cygwins /etc/passwd ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Smiley Sent: Tuesday, January 09, 2007 5:25 PM To: cygwin@cygwin.com Subject: username should be lower-case for $USER I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. On unix based hosts I log into, it is always lower-case. So if I try to SSH to another machine where I have the same login name, I can't let SSH automatically default to $USER because the case isn't right. *Even if* Windows user names are case sensitive and so there is a difference between DSMILEY and dsmiley (are they?, I don't know) I think $USER should be made to be all lower-case to be consistent with unix environments. ~ David Smiley -- View this message in context: http://www.nabble.com/username-should-be-lower-case-for-%24USER-tf294715 6.html#a8241120 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: help win winxp install
this was a good 6 months ago, and i cant get acess to my log books (im at school, and my log books were kept by the client). IMIR what is the more pressing issue is that _we_ should provide a script that _nightly_ (im serious) gets the latest files. an _example_ of how the mirrors have been different is that I have found different version numbers for all of the mirrors that host X/Cygwin (a big part of what i am doing) so i cant be shure what version is going to be distributed! am i clear at this point? On 1/9/07, Christopher Faylor [EMAIL PROTECTED] wrote: On Tue, Jan 09, 2007 at 10:25:33AM -, Dave Korn wrote: On 09 January 2007 01:06, Morgan Gangwere wrote: well, there is a fundamental flaw here in the distribution system then. i have looked at the versions from (agast!) three different mirrors and they have so far been completely different. It would have been helpful if you said *which* mirrors. Details? What a novel concept. I don't think the concept will catch on since making statements like they have...been completely different is much easier than clearly elucidating the actual differences. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Morgan gangwere Space does not reflect society, it expresses it. -- Castells, M., Space of Flows, Space of Places: Materials for a Theory of Urbanism in the Information Age, in The Cybercities Reader, S. Graham, Editor. 2004, Routledge: London. p. 82-93. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
My experience build the 2.6.17 kernel under Cygwin
First I must say I love Cygwin. I have a few guys here with VM Ware and Redhat for development. I've been reluctant to go down that path because of the resources it takes up. So when it came to my first shot at kernel targeting, I decided to give Cygwin a run. While most everything worked quite well, I did want to make a concise list of the issues I had because I found no such list. 1. The international lib reference is missing from the kconfig make file. Even compiling with KBUILD_HAVE_NLS=no won't get past this. I also suspect its missing references to ncurses. This was my first hurdle, but modifying the kconfig make file got make xconfig to work. I don't know if this is across the board (normal Linux) or not. Line 133 HOSTLOADLIBES_mconf += -lintl 2. Cygwin does not appear to handle the advanced file system mechanics to support mknod properly. This may be a specific thing to my situation, but my dev kit had a sample file system. It would not untar into cygwin without a seg fault. My workaround was to basically do this on a VM Ware / RH machine. Annoying, but it did work. What I may suggest is a way to have a real linux file system that you can 'mount' and provide this functionality. In general the kernel built great, but from what I can tell, building file systems is still something to be left of a full linux box. If anyone has any other suggestions or thoughts on this, I'd like to hear them because I'd really like to stay all on Cygwin. Thanks, Gabriel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Support for Baud Rates above 250000 baud?
what I would do is have say Minicom try and talk at those rates first.
another option is to have a file like newbaud.h that looks like
this:
! Begin
//
// newbaud.h -high speed baud rate functions
//
#IFNDEF NEWBAUD_H
#DEFINE NEWBAUD_H
int setbaud(int baudrate, int port) {
// this sets the buad rate to baudrate
//...
if(sucess) { return 1}
else {return failure}
//...
}
#ENDIF
where failiure would be used for the FAILIURE MODE. IAGT, it should
never happen, as you should always be able to set the baud rate
On 1/9/07, Brian Dessent [EMAIL PROTECTED] wrote:
David le Comte wrote:
I am running Cygwin on a PC that is running Windows XP. My Cygwin
version is CYGWIN_NT-5.1 and it was downloaded and installed late last
No, it's not. The output from uname tells us nothing about which
version of Cygwin (or any of the other of dozens of packages you might
have installed), rather it simply means that you are running Windows NT
version 5.1, aka Windows XP. The current version of Cygwin is 1.5.23-2,
and if you want to include helpful information try attaching the output
of cygcheck -svr as requested in the posting instructions.
Adding entries into termios.h for higher
baudrates using the convention that B460800 was 0x01006,
B50 was 0x01007, and B921600 was 0x01008
caused errors.
#define B230400 0x01004
#define B256000 0x01005
/* 3 new entries - as an experiement to see if it works */
#define B460800 0x01006
#define B50 0x01007
#define B921600 0x01008
The calls to cfsetispeed() and cfsetospeed() failed. Not unsurprising,
as one could assume that they had been using the original termios.h when
they were compiled.
This is a Very Bad Idea in general. You can't just add new defines to a
header file and expect it to work. The header is an indication of what
a library supports, it is a one-way street.
1) Is there a build available for Cygwin (on a Windows platform) that
has support for higher baud rates? If so, does anyone know where I
could find it?
That's kind of an odd question. Cygwin is open source and of course
people are free to take it and patch it to do whatever they want, so
it's certainly possible that someone has patched their Cygwin to allow
other baud rate settings. But if they did it would be a separate
project and off-topic for this list, and I'm not aware of any such thing
existing.
Occasionally new features are added to the code which have yet to be
included in released versions, in which case users are directed to try
the new code in the Cygwin snapshots which are provided on cygwin.com,
but in this case that's not an issue as I'm not aware of any recent
changes to this part of the code.
2) Assuming there is no such build available, are there plans to add
support for higher baud rates? If so, does anyone know when?
2) Would it be difficult to download the appropriate source files, modify
them, and make my own Cygwin build? (The idea of doing this terrifies
me by the way). If it is possible, could someone give me some pointers
on how to do this?
If you read the Win32 API docs for SetCommState()
http://msdn2.microsoft.com/en-us/library/aa363436.aspx and struct DCB:
http://msdn2.microsoft.com/en-us/library/aa363214.aspx you see the
canonical list of #defined baud rates that Win32 supports. But there's
also this tidbit: This member can be an actual baud rate value, or one
of the following indexes.
So from this we can see that Win32 supports arbitrary baud rates (with a
certain list of #defined standard ones) whereas the POSIX termios.h /
speed_t API that Cygwin is emulating does not have the capability to set
the rate arbitarily. Thus, any baud rate can be supported, but the code
has to exist to do the mapping of the symbolic constant. You can see
this happening in fhandler_serial.cc, which does the actual mapping of
termios to filling the Win32 struct DCB:
case B110:
state.BaudRate = CBR_110;
break;
case B300:
state.BaudRate = CBR_300;
break;
case B600:
state.BaudRate = CBR_600;
break;
case B1200:
state.BaudRate = CBR_1200;
break;
case B2400:
state.BaudRate = CBR_2400;
break;
case B4800:
state.BaudRate = CBR_4800;
break;
case B9600:
state.BaudRate = CBR_9600;
break;
case B19200:
state.BaudRate = CBR_19200;
break;
case B38400:
state.BaudRate = CBR_38400;
break;
case B57600:
state.BaudRate = CBR_57600;
break;
case B115200:
state.BaudRate = CBR_115200;
break;
case B230400:
state.BaudRate = 230400 /* CBR_230400 - not defined */;
break;
default:
/* Unsupported baud rate! */
termios_printf (Invalid t-c_ospeed %d, t-c_ospeed);
set_errno (EINVAL);
return -1;
}
Thus it appears that it should be easily possible to add a Bx define
for any desired baud rate, as long as you update termios.h and
Re: Fw: help win winxp install
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Morgan Gangwere on 1/9/2007 10:57 AM: an _example_ of how the mirrors have been different is that I have found different version numbers for all of the mirrors that host X/Cygwin (a big part of what i am doing) so i cant be shure what version is going to be distributed! am i clear at this point? No. A clear example would be listing the exact mirrors that you are trying to download from, and the exact version numbers of the file that you claim differs between those two mirrors. And keep in mind that the list of mirrors is automatically pruned - any mirror that is found to be more than 48 hours old is not advertised by setup.exe (other than the fact that setup.exe remembers the last mirror you used, even if that mirror went stale). So once you realize that various mirrors have different update schedules, they should all be within a day of each other. And if it really matters to have the same version across your entire distribution, then pick just one mirror. And since the cygwin X port is currently looking for a maintainer, I highly doubt you are seeing mirror discrepancies there - the collection of X packages has not had an update in a couple of months, so you are pretty much getting the latest version no matter what mirror you use, unless you happen to point setup.exe to a non-standard mirror that is out of date. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo9kd84KuGfSFAYARAhTmAKDOuEIalAlMY3CU6Fr21Op6urd2OQCgq+tP 5YDsw9bJrtF11Za6+afKu/w= =+DHK -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: git-1.4.4.4-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of git, 1.4.4.4-1, has been uploaded, replacing 1.4.4.3-1 as the current version. NEWS: = This is a new upstream release. See also the package documentation in /usr/share/doc/git-1.4.4.4/. This release fixes a cygwin packaging bug. Upstream changes since v1.4.4.3 are listed below. DESCRIPTION: Git is popular version control system designed to handle very large projects with speed and efficiency; it is used mainly for various open source projects, most notably the Linux kernel. Git falls in the category of distributed source code management tools, similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary world). Every Git working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access or a central server. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'git' from the 'Devel' category. DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. - -- Eric Blake volunteer cygwin git maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Changes since v1.4.4.3 are as follows: Johannes Schindelin (1): diff --check: fix off by one error Junio C Hamano (3): spurious .sp in manpages Fix infinite loop when deleting multiple packed refs. pack-check.c::verify_packfile(): don't run SHA-1 update on huge data -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo9re84KuGfSFAYARAjlRAKDCSZJGliPnkZEc0CPI0uc2jkCQ+gCfcsHO xMC46ezMGuQq6OQWlnrB8RU= =hVFh -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: help win winxp install
On 1/9/07, Eric Blake [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Morgan Gangwere on 1/9/2007 10:57 AM: an _example_ of how the mirrors have been different is that I have found different version numbers for all of the mirrors that host X/Cygwin (a big part of what i am doing) so i cant be shure what version is going to be distributed! am i clear at this point? No. A clear example would be listing the exact mirrors that you are trying to download from, and the exact version numbers of the file that you claim differs between those two mirrors. as i said, i dont have my log books avail. to me. i can say that there was a (max) variation of 3 minor versions. And keep in mind that the list of mirrors is automatically pruned - any mirror that is found to be more than 48 hours old is not advertised by setup.exe (other than the fact that setup.exe remembers the last mirror you used, even if that mirror went stale). So once you realize that various mirrors have different update schedules, they should all be within a day of each other. And if it really matters to have the same version across your entire distribution, then pick just one mirror. And since the cygwin X port is currently looking for a maintainer, I highly doubt you are seeing mirror discrepancies there - the collection of X packages has not had an update in a couple of months, so you are pretty much getting the latest version no matter what mirror you use, unless you happen to point setup.exe to a non-standard mirror that is out of date. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo9kd84KuGfSFAYARAhTmAKDOuEIalAlMY3CU6Fr21Op6urd2OQCgq+tP 5YDsw9bJrtF11Za6+afKu/w= =+DHK -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ this outlines my point exactly. we need to give _all_ of the mirrors not a _48_ hour but at max a _24_ hour. and _all_ the mirrors should have the same packages. this goes back to having _libintl8_ but not being able to get the _libintl3_ packages. TIDSIHD. but what we need is to have _all_ the mirrors _mirror_ each other. does the main cygwin server have libintl8? -- Morgan gangwere Space does not reflect society, it expresses it. -- Castells, M., Space of Flows, Space of Places: Materials for a Theory of Urbanism in the Information Age, in The Cybercities Reader, S. Graham, Editor. 2004, Routledge: London. p. 82-93. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: help win winxp install
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Morgan Gangwere on 1/9/2007 11:14 AM: this outlines my point exactly. we need to give _all_ of the mirrors not a _48_ hour but at max a _24_ hour. You need more convincing arguments if you want the current mirror policy to change. and _all_ the mirrors should have the same packages. They do. In order to be a non-stale mirror on cygwin's setup.exe list, the mirror must provide everything that cygwin.com provides, updated to within the last 48 hours. this goes back to having _libintl8_ but not being able to get the _libintl3_ packages. libintl8 and libintl3 are two different packages, but both are available on all current cygwin mirrors. libintl3 is obsolete. New code should not be using it. But old packages, which depend on it, should automatically pull it in via their dependencies. You really should be trying to figure out what package you have that depends on libintl3, and whether that package has been updated to be recompiled against libintl8, or whether it has a missing dependency in the setup.exe dependency logic. But changing mirroring policy will not help you here. TIDSIHD. but what we need is to have _all_ the mirrors _mirror_ each other. does the main cygwin server have libintl8? All the mirrors DO mirror each other (implicitly, since they all mirror the master at cygwin.com). I think you are confusing the issue. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo91s84KuGfSFAYARAvoYAKDC2fSQh8mi1tg/oATmkKMSSCAjaQCfamn9 deH87FUZjDWi5Jnjfs9WgXQ= =hFbE -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: help win winxp install
On Tue, Jan 09, 2007 at 10:57:01AM -0700, Morgan Gangwere wrote: this was a good 6 months ago, and i cant get acess to my log books (im at school, and my log books were kept by the client). IMIR what is the more pressing issue is that _we_ should provide a script that _nightly_ (im serious) gets the latest files. Uh. Who's the _we_ in the above paragraph? Are you offering advice without really understanding how it works now or are you making a note of something you have to do for yourself? an _example_ of how the mirrors have been different is that I have found different version numbers for all of the mirrors that host X/Cygwin (a big part of what i am doing) so i cant be shure what version is going to be distributed! am i clear at this point? Sorry but no. Making assertions that things are different is not the same as providing details about what precisely is different. For this to be at all useful, you'd have to tell us which mirrors you're talking about and what versions you're talking about. If you don't have these details, then there is no reason to respond. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Fw: help win winxp install
On 09 January 2007 17:57, Morgan Gangwere wrote: this was a good 6 months ago, and i cant get acess to my log books (im at school, and my log books were kept by the client). IMIR what is the more pressing issue is that _we_ should provide a script that _nightly_ (im serious) gets the latest files. First off, all the mirrors are autonomous and not under our control. We cannot force them to stick to any particular update schedule. That is their prerogative. Secondly, they almost all probably use rsync. We wouldn't need to provide a script, just a single command-line. an _example_ of how the mirrors have been different is that I have found different version numbers for all of the mirrors that host X/Cygwin (a big part of what i am doing) so i cant be shure what version is going to be distributed! am i clear at this point? Still not, I'm afraid. As long as they all have the curr, prev and exp versions, nothing else matters. In particular, it does not matter if some of them retain older versions for much longer than others, because you will never be offered those versions by setup.exe. Your problem is that you're browsing the mirror site using an html or ftp client, and you're getting confused by the structure and conventions, and mistaking non-issues for problems. The mirrors are designed to be accessed by setup.exe, and unless /that/ does something wrong, there is no problem. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: My experience build the 2.6.17 kernel under Cygwin
On 09 January 2007 18:01, Gabriel Goldstein wrote: 2. Cygwin does not appear to handle the advanced file system mechanics to support mknod properly. This may be a specific thing to my situation, but my dev kit had a sample file system. It would not untar into cygwin without a seg fault. Can you narrow it down to a tarball containing just a single file? Or is it a fairly small tarchive? My workaround was to basically do this on a VM Ware / RH machine. Annoying, but it did work. What I may suggest is a way to have a real linux file system that you can 'mount' and provide this functionality. This one gets raised every so often, but it's not really a cygwin issue. It requires a windows filesystem driver that knows how to mount a linux filesystem. That's a device driver, whereas cygwin is all user-mode application; if you have such a driver on your machine, the linux drive will show up in windows and have a drive letter, and will automatically be availably through /cygdrive/letter. (Yes, it would be *possible* to provide a cygwin filesystem driver that runs in usermode, and just uses ioctls to do raw sector reads and writes. Maybe porting FUSE to cygwin would be the way to go at some stage) cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: My experience build the 2.6.17 kernel under Cygwin
On 09 January 2007 18:42, Gabriel Goldstein wrote: Can you narrow it down to a tarball containing just a single file? Or is it a fairly small tarchive? -- File attached for review. It's just a small sample fs from my dev kit mfg. -- Heh, if you had answered yes to that question I was going to ask you to send it to me off-list never mind, at least it wasn't huge! Anyway, I can reproduce the fault, so I'll take a look at it. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
bug in syscalls.cc sync()
I was just browsing the CVSweb repository looking at the sync()
implementation and noticed this small typo. It's not worth the trouble
for me to download the CVS repository just for this:
/* sync: SUSv3 */
extern C void
sync ()
{
char vol[CYG_MAX_PATH];
if (wincap.has_guid_volumes ()) /* Win2k and newer */
{
char a_drive[CYG_MAX_PATH] = {0};
char b_drive[CYG_MAX_PATH] = {0};
if (is_floppy (A:))
GetVolumeNameForVolumeMountPointA (A:\\, a_drive, CYG_MAX_PATH);
if (is_floppy (B:))
GetVolumeNameForVolumeMountPointA (B:\\, a_drive, CYG_MAX_PATH);
Notice the last line there - a_drive should be b_drive.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: username should be lower-case for $USER
TDavid Smiley wrote: I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. As David said, that's because you created your username in ALL UPPERCASE when setting up the user on Windows. The only way to fix this for you would be to rename your Windows user to have a lower-case name. (If windows allows that operation..) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Exclude cygwin folder from malware scans?
Fred Ma wrote: After some surfing, I haven't found any evidence of malware targetting cygwin. I'm considering excluding the massive file tree from scans (AV, SpyBot, AdAware). I'd be interested in more experienced opinions about this. Thanks. I'd still be wary of as-yet-unknown viruses that reach out and infect loaded DLLs. You probably should continue to scan c:\cygwin\bin, but exclude everything else (which is still a big help). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: username should be lower-case for $USER
I forgot to add, I log into a windows domain and so I can't set the case. Perhaps this issue only relates to windows domain logins. Maybe they are case insensitive because when I log into the domain, I ALWAYS specify it in lower case. I don't think I've ever seen it presented to me (in Windows) as upper case. Yet in CYGWIN, $USER=DSMILEY. If domain logins are case *in*sensitive (appears likely), then it would seem to me that it should be normalized to lower-case for use in CYGWIN. Dave Korn wrote: On 09 January 2007 16:25, David Smiley wrote: I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. On unix based hosts I log into, it is always lower-case. So if I try to SSH to another machine where I have the same login name, I can't let SSH automatically default to $USER because the case isn't right. *Even if* Windows user names are case sensitive and so there is a difference between DSMILEY and dsmiley (are they?, I don't know) I think $USER should be made to be all lower-case to be consistent with unix environments. It would /not/ be consistent with unix environments. Just because *you* haven't used one with capitals in usernames does *not* mean they do not exist. The Opengroup posix spec quite explicitly allows different cases: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_ 426 cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- View this message in context: http://www.nabble.com/username-should-be-lower-case-for-%24USER-tf2947156.html#a8247784 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: username should be lower-case for $USER
On 1/9/07, Shankar Unni wrote: TDavid Smiley wrote: I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. As David said, that's because you created your username in ALL UPPERCASE when setting up the user on Windows. The only way to fix this for you would be to rename your Windows user to have a lower-case name. (If windows allows that operation..) My user ID is numbers only so I cannot test this. The suggestion of just renaming your user account is actually the easiest one if you have administrative rights in your domain. But I do have a few other suggestions in case you don't. Since Windows is not a case-sensitive operating system and since the $USER environment variable is dynamically populated when you logon, try logging on with your user name as 'dsmiley' instead of 'DSMILEY' and see if that changes the environment variable. If it doesn't, you may be able to fix it by deleting your user profile and then logging on with your user name in lower case. As I said, Windows is not case-sensitive as far as user names go. You can log on as 'DSMILEY', 'dsmiley', or 'DsMiLEy' and it will work. But I don't know if it will change your $USER environment variable because I don't know exactly how Windows populates it. -Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: username should be lower-case for $USER
On 1/9/07, David Smiley wrote: I forgot to add, I log into a windows domain and so I can't set the case. Perhaps this issue only relates to windows domain logins. Maybe they are case insensitive because when I log into the domain, I ALWAYS specify it in lower case. I don't think I've ever seen it presented to me (in Windows) as upper case. Yet in CYGWIN, $USER=DSMILEY. If domain logins are case *in*sensitive (appears likely), then it would seem to me that it should be normalized to lower-case for use in CYGWIN. $USER is a Windows environment variable and Cygwin doesn't change it. It just reports what Windows says. I disagree that Cygwin should normalize it to lower case by default. You can do something creative with your logon process by sending the variable to some shell script and having it fix the case. I don't write bash scripts or awk so here is an example in perl. =-=-=-=-=-=-=-=-=-=-=-=-= code =-=-=-=-=-=-=-=-=-=-=-=-= #!/usr/bin/perl -w $word = shift; print In: $word\n; $word =~ s/([A-Z])/lc($1)/ge; print Out: $word\n; =-=-=-=-=-=-=-=-=-=-=-=-= code =-=-=-=-=-=-=-=-=-=-=-=-= Examples of output: [EMAIL PROTECTED] ~ $ ./test3.pl DSmiley In: DSmiley Out: dsmiley [EMAIL PROTECTED] ~ $ ./test3.pl DSMILEY In: DSMILEY Out: dsmiley [EMAIL PROTECTED] ~ $ ./test3.pl dsmiley In: dsmiley Out: dsmiley [EMAIL PROTECTED] ~ $ -Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: username should be lower-case for $USER
On Tue, 9 Jan 2007, DePriest, Jason R. wrote: On 1/9/07, David Smiley wrote: I forgot to add, I log into a windows domain and so I can't set the case. Perhaps this issue only relates to windows domain logins. Maybe they are case insensitive because when I log into the domain, I ALWAYS specify it in lower case. I don't think I've ever seen it presented to me (in Windows) as upper case. Yet in CYGWIN, $USER=DSMILEY. If domain logins are case *in*sensitive (appears likely), then it would seem to me that it should be normalized to lower-case for use in CYGWIN. $USER is a Windows environment variable and Cygwin doesn't change it. It just reports what Windows says. Not true. $USER is actually a shell variable, and is (re)set by the shell (bash, ash, tcsh, what have you). You must be thinking of $USERNAME, which is a Windows variable. Cygwin sets it from the data it finds in /etc/passwd. In fact, the only thing that Cygwin actually uses is the SID in /etc/passwd -- everything else (including the username) is under the user's control. I disagree that Cygwin should normalize it to lower case by default. You can do something creative with your logon process by sending the variable to some shell script and having it fix the case. [snip perl script] Or you can edit /etc/passwd and make your username whatever you wish it to be (just be sure to leave the SID unchanged). For more information, see the NTSEC section of the User's Guide (outdated as it is). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Freedom is just another word for nothing left to lose... -- Janis Joplin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: help win winxp install
According to Morgan Gangwere on 1/9/2007 11:14 AM: this outlines my point exactly. we need to give _all_ of the mirrors not a _48_ hour but at max a _24_ hour. You need more convincing arguments if you want the current mirror policy to change. and _all_ the mirrors should have the same packages. They do. In order to be a non-stale mirror on cygwin's setup.exe list, the mirror must provide everything that cygwin.com provides, updated to within the last 48 hours. this goes back to having _libintl8_ but not being able to get the _libintl3_ packages. libintl8 and libintl3 are two different packages, but both are available That might be true now -- but it was not true last friday eve. Two complete downloads from two different mirrors (no I no longer remeber which) did not yeld 'libint3' on all current cygwin mirrors. libintl3 is obsolete. New code should not be using it. Thats interesting -- the package I had problmes with was 'gcc' specifically the first pass parser 'cc1'. Unless things have changed it would seem to me that the flagship compiler would not be considered 'old code' But old packages, which depend on it, should automatically pull it in via their dependencies. You really should be trying to figure out what package you have that depends on libintl3, and whether that package has been updated to be recompiled against libintl8, or whether it has a missing dependency in the setup.exe dependency logic. But changing mirroring policy will not help you here. Totally Agree TIDSIHD. but what we need is to have _all_ the mirrors _mirror_ each other. does the main cygwin server have libintl8? All the mirrors DO mirror each other (implicitly, since they all mirror the master at cygwin.com). I think you are confusing the issue. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo91s84KuGfSFAYARAvoYAKDC2fSQh8mi1tg/oATmkKMSSCAjaQCfamn9 deH87FUZjDWi5Jnjfs9WgXQ= =hFbE -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[BUG] cygport-0.2.7 fails to build multiple binary packages
While tying to rebuild the gettext-0.15-1 package, I noticed that it
did not build correctly any more.
The problem is that the postinstall/preremove scripts for all but the
primary binary packages are ignored, and thus the packaging step
fails.
I have tried to correct this fault in the attached patch, but as it
was done in a bit of a rush I probably broke as much as I corrected.
Could someone familiar with cygport have a look at it, please?
Some notes on the suggested changes:
* The __prepetc() postinstall function is staring to become too large,
so some part were split out into separate functions:
- The __prepetc_pre_post_old() now contains the old
postinstall/preremove scripts handling.
- The __prepetc_profile() now contains the old
profile scripts handling.
- The __prep_check_pre_post() now postinstall/preremove scripts chmod.
* The __prepetc_pre_post() was added to handle postinstall/preremove
scripts for multiple binary packages.
* The prep_gnu_info.sh script added commands to the wrong
postinstall/preremove script, if more than one was used.
That is it assumed that all info files were located in the primary
package, which is not true for the gettext package.
This was replaced with the new prep_gnu_info() function, (not sure
if this was an imrovement or not). This function now checks which
package the info file belongs to and adds the command to the
corresponding postinstall/preremove scripts.
Unfortunately this change will probably break the
postinstall/preremove scripts in the existing multiple binary
packages. Coincidentally this also removes the need for the
handcrafted postinstall/preremove scripts in the gettext package,
so this change seems to be in line with the intent of the cygport
goals.
Test Package etc:
=
Cygcheck result:
http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1/cygcheck.out
The corrected cygport script, and diff to the 0.2.7-1 baseline:
http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1/cygport-test
http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1/cygport-test.patch
A adapted version of the gettext package
(with the po-mode emacs mode included):
http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1/gettext-0.15-2.tar.bz2
http://www.update.uu.se/~stefanb/cygwin/bug/cygport-1/gettext-0.15-2-src.tar.bz2
Regards
Stefan Björnelund.
--- /usr/bin/cygport2006-12-26 06:43:10.00100 +0100
+++ cygport-test2007-01-07 21:09:26.037408000 +0100
@@ -1031,20 +1031,62 @@
done
}
-# creates and installs postinstall, preremove, and profile.d scripts
-__prepetc() {
+# creates and installs postinstall, preremove scripts
+__prepetc_pre_post_old() {
local d;
local s;
+ local -i n=0;
+
+ __step Installing postinstall, preremove scripts. Old style.
+ # Old style
for s in postinstall preremove
do
if [ -f ${C}/${s}.sh ]
then
+ echo /etc/${s}/${PN}.sh;
dodir /etc/${s};
cat ${D}/etc/${s}/${PN}.sh ${C}/${s}.sh;
fi
done
+}
+
+
+# creates and installs postinstall, preremove scripts
+__prepetc_pre_post() {
+ local d;
+ local s;
+ local -i n=0;
+
+ __step Installing postinstall, preremove scripts.
+
+ # New style
+ for s in postinstall preremove
+ do
+ n=0;
+ while defined pkg_name[${n}]
+ do
+ if [ -f ${C}/${pkg_name[${n}]}.${s} ]
+ then
+ echo /etc/${s}/${pkg_name[${n}]}.sh
from ${C}/${pkg_name[${n}]}.${s};
+ dodir /etc/${s};
+ cat ${D}/etc/${s}/${pkg_name[${n}]}.sh
${C}/${pkg_name[${n}]}.${s};
+ fi
+ n+=1;
+ done
+ done
+}
+
+
+
+# creates and installs postinstall, preremove, and profile.d scripts
+__prepetc_profile() {
+ local d;
+ local -i n=0;
+ __step Installing profile scripts.
+
+ # Old stype, Single package:
if [ -f ${C}/profile.d.sh ]
then
exeinto /etc/profile.d;
@@ -1057,6 +1099,159 @@
newexe ${C}/profile.d.csh ${PN}.csh;
fi
+ # New style, multiple packages
+ n=0;
+ while defined pkg_name[${n}]
+ do
+ if [ -f ${C}/${pkg_name[${n}]}.profile.d.sh ]
+ then
+ exeinto /etc/profile.d;
+ newexe ${C}/${pkg_name[${n}]}.profile.d.sh ${PN}.sh;
+ fi
+
+ if [ -f ${C}/${pkg_name[${n}]}.profile.d.csh ]
+ then
+ exeinto /etc/profile.d;
+ newexe ${C}/${pkg_name[${n}]}.profile.d.csh ${PN}.csh;
+ fi
+
+ n+=1;
+ done
+}
RE: Re: username should be lower-case for $USER
Hi all, My first constructive post to this group outside of my inane question asking... TDavid Smiley wrote: I am new to Cygwin. I noticed that the $USER environment variable has my username in upper-case. So it is DSMILEY. As David said, that's because you created your username in ALL UPPERCASE when setting up the user on Windows. The only way to fix this for you would be to rename your Windows user to have a lower-case name. (If windows allows that operation..) As covered later in this thread the user is logging into a domain. Windows is indeed case insensitive WRT logins and can even be forced into case insensitive mode for passwords programatically (as demonstrated by the l0phtcrack algorithm). But I have never seen a DOMAIN report the user id back in lowercase, even when it was specifically entered in lower case (I may be wrong about this - please let me know if you have contrary evidence). There is another workaround, tho! In my environment I log into the domain with a login in the form AA, but need my Cygwin environment to recognise me as sybase. So I simply edited the leading column of my record in /etc/passwd and changed the contents sybase. Since the other tokens linking me record to the domain account were unchanged Cygwin sees me as sybase, but the domain sees me as myself. This has been working for well over a year. If anyone sees any problems with it I'd be glad to hear form them. -doug echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |dc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Re: username should be lower-case for $USER
First - On 1/9/07, Igor Peshansky wrote: On Tue, 9 Jan 2007, DePriest, Jason R. wrote: $USER is a Windows environment variable and Cygwin doesn't change it. It just reports what Windows says. Not true. $USER is actually a shell variable, and is (re)set by the shell (bash, ash, tcsh, what have you). You must be thinking of $USERNAME, which is a Windows variable. Yes, you are exactly correct. I goobered that and I am glad you caught it and put it out there so at least the archives will reflect the truth. Next - On 1/9/07, Irwin, Doug wrote: As covered later in this thread the user is logging into a domain. Windows is indeed case insensitive WRT logins and can even be forced into case insensitive mode for passwords programatically (as demonstrated by the l0phtcrack algorithm). But I have never seen a DOMAIN report the user id back in lowercase, even when it was specifically entered in lower case (I may be wrong about this - please let me know if you have contrary evidence). If the user ID is created with lower-cased letters, it will be stored and reported in lower-cased letters. At least that is how the Windows 2003 Active Directory where I work expresses its user IDs. For example, our regular IDs are a number. Some special IDs have letters added to the beginning of the number. I am looking at user IDs right now through the AD User and Computers mmc snap-in and I can see that most of them are in all caps, but some are not. No matter how I look at the account name for this particular ID, it is in lower-cased letters. The reported 'dn' of objects with lower-cased letters have lower-cased letters in them, so AD will use that to report the values. I also know that when you initially log on to a system and it creates a new user profile for you, the folder it creates will have upper / lower -cased letters based on how you logged on and not on how AD says your ID should be capitalized. There is another workaround, tho! In my environment I log into the domain with a login in the form AA, but need my Cygwin environment to recognise me as sybase. So I simply edited the leading column of my record in /etc/passwd and changed the contents sybase. Since the other tokens linking me record to the domain account were unchanged Cygwin sees me as sybase, but the domain sees me as myself. This has been working for well over a year. If anyone sees any problems with it I'd be glad to hear form them. -doug This is of course the new best answer to the problem and is something I also routinely do (mostly to distinguish between groups that are in different domains but would otherwise have the same name). I have no idea why it wasn't suggested earlier unless we all just thought he had probably already tried that. -Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: help win winxp install
Sam The Cat wrote: According to Morgan Gangwere on 1/9/2007 11:14 AM: this outlines my point exactly. we need to give _all_ of the mirrors not a _48_ hour but at max a _24_ hour. You need more convincing arguments if you want the current mirror policy to change. and _all_ the mirrors should have the same packages. They do. In order to be a non-stale mirror on cygwin's setup.exe list, the mirror must provide everything that cygwin.com provides, updated to within the last 48 hours. this goes back to having _libintl8_ but not being able to get the _libintl3_ packages. libintl8 and libintl3 are two different packages, but both are available That might be true now -- but it was not true last friday eve. Two complete downloads from two different mirrors (no I no longer remeber which) did not yeld 'libint3' Well you must have caught them cleaning house since libintl3 has been around for years. You can check the announcements list to see when various packages were added and updated. on all current cygwin mirrors. libintl3 is obsolete. New code should not be using it. Thats interesting -- the package I had problmes with was 'gcc' specifically the first pass parser 'cc1'. Unless things have changed it would seem to me that the flagship compiler would not be considered 'old code' It's not old code but gcc is a long time package. Looks like it incorrectly picked up cygintl-3.dll for cc1.exe the last time it was built. But looking at the setup.hint files, it correctly says that it depends on it. So if you were installing gcc, you would get the libintl3 package if it existed on the mirror you chose. I do notice, however, that gcc has a dependency on cygintl-8.dll but doesn't show the dependency in the setup.hint file. Dave, can you review this and see if the setup.hint files need to be updated? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: help win winxp install
Sam The Cat wrote: According to Morgan Gangwere on 1/9/2007 11:14 AM: this outlines my point exactly. we need to give _all_ of the mirrors not a _48_ hour but at max a _24_ hour. You need more convincing arguments if you want the current mirror policy to change. and _all_ the mirrors should have the same packages. They do. In order to be a non-stale mirror on cygwin's setup.exe list, the mirror must provide everything that cygwin.com provides, updated to within the last 48 hours. this goes back to having _libintl8_ but not being able to get the _libintl3_ packages. libintl8 and libintl3 are two different packages, but both are available That might be true now -- but it was not true last friday eve. Two complete downloads from two different mirrors (no I no longer remeber which) did not yeld 'libint3' Well you must have caught them cleaning house since libintl3 has been around for years. You can check the announcements list to see when various packages were added and updated. on all current cygwin mirrors. libintl3 is obsolete. New code should not be using it. Thats interesting -- the package I had problmes with was 'gcc' specifically the first pass parser 'cc1'. Unless things have changed it would seem to me that the flagship compiler would not be considered 'old code' It's not old code but gcc is a long time package. Looks like it incorrectly picked up cygintl-3.dll for cc1.exe the last time it was built. But looking at the setup.hint files, it correctly says that it depends on it. So if you were installing gcc, you would get the libintl3 package if it existed on the mirror you chose. I do notice, however, that gcc has a dependency on cygintl-8.dll but doesn't show the dependency in the setup.hint file. Dave, can you review this and see if the setup.hint files need to be updated? Thanks -- I was hoping that someone with more wherewithall would look into this Cheers Eric -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: activestate perl on cygwin
I don't actually install through cygwin, but use the ppm installer from Activestate. I still need to know how to solve the issue that occurs with the command I mentioned in my original post. Using the version of perl installed with cygwin is not really an option since I already have scripts written that utilize windows specific modules. Thanks, Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DePriest, Jason R. Sent: Tuesday, January 09, 2007 12:13 PM To: cygwin@cygwin.com Subject: Re: activestate perl on cygwin On 1/9/07, Brian Dessent wrote: moka at hol dot gr wrote: But how do you then install modules? Just like in unix from the tarballs that are intended for unix? Essentially, yes. Just run CPAN (perl -MCPAN -e shell) and type install Foo::Bar just as you would on any unix system. You don't have to actually know or care about tarballs, CPAN does all that for you. One caveat. If you are behind a proxy server that requires authentication, ActiveState's PPM install tools are much easier to get reliably working than the various command-line tools that CPAN uses (wget, lynx, ncftp, Net::FTP, etc). -Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: activestate perl on cygwin
Kevin T Cella kcella at nycap.rr.com writes: Using the version of perl installed with cygwin is not really an option since I already have scripts written that utilize windows specific modules. Out of curiousity, which modules are those? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
windows bluescreens while looking for ANSI C headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bug #2 Make reports that it Cant find the ANSI C headers while compiling GnuPG (this makes no sense to me because i have all the dev packages installed). partial output: [clip] Making sure you can build shared objects with ln.exe... ok checking for ANSI C headers... [blue screen] i have yet to be able to understand _why_ this is occurring... thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) iD8DBQFFpGZoXIyDjlIx4voRAu3YAJ9i8REDPS4w9egZtmdE0b+/m7wFIACcCMwf rCOHOGlrthHxb9NQRWwW9/s= =fG7D -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: windows bluescreens while looking for ANSI C headers
Morgan Gangwere wrote: bug #2 Make reports that it Cant find the ANSI C headers while compiling GnuPG (this makes no sense to me because i have all the dev packages installed). partial output: [clip] Making sure you can build shared objects with ln.exe... ok checking for ANSI C headers... [blue screen] i have yet to be able to understand _why_ this is occurring... Typical causes are buggy drivers or an O/S (kernel) bug. My money is on the former. Try uninstalling any spyware or virus software you have and see if the problem goes away. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: windows bluescreens while looking for ANSI C headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Hall (Cygwin) wrote: Morgan Gangwere wrote: bug #2 Make reports that it Cant find the ANSI C headers while compiling GnuPG (this makes no sense to me because i have all the dev packages installed). partial output: [clip] Making sure you can build shared objects with ln.exe... ok checking for ANSI C headers... [blue screen] i have yet to be able to understand _why_ this is occurring... Typical causes are buggy drivers or an O/S (kernel) bug. My money is on the former. Try uninstalling any spyware or virus software you have and see if the problem goes away. tried that my friend. ClamAV is disabled and Spybot SD (and the resident) are stopped and killed. I've also tried running sh -x configure and it still fails -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) iD8DBQFFpGglXIyDjlIx4voRAj6IAJwKfs1zb41tIjzBwlj2DLYmBhUxsQCdF7av djhFLQHLPYSTZ1jKXqc5Rig= =PBWu -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: windows bluescreens while looking for ANSI C headers
Morgan Gangwere wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Hall (Cygwin) wrote: Morgan Gangwere wrote: bug #2 Make reports that it Cant find the ANSI C headers while compiling GnuPG (this makes no sense to me because i have all the dev packages installed). partial output: [clip] Making sure you can build shared objects with ln.exe... ok checking for ANSI C headers... [blue screen] i have yet to be able to understand _why_ this is occurring... Typical causes are buggy drivers or an O/S (kernel) bug. My money is on the former. Try uninstalling any spyware or virus software you have and see if the problem goes away. tried that my friend. ClamAV is disabled and Spybot SD (and the resident) are stopped and killed. I've also tried running sh -x configure and it still fails Turning these things off is not enough. You have to uninstall them. Otherwise, they will still be active in the network stack. Try uninstalling them. Also, there are other buggy hardware drivers. Logitec webcams are one known culprit. Unfortunately, you're going to need to experiment to find out what driver on your system is causing the problems you're seeing. FWIW, I expect ClamAV isn't the culprit but that's just my WAG. I wouldn't let that dissuade you from including it in your experimentation. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: windows bluescreens while looking for ANSI C headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Hall (Cygwin) wrote: Morgan Gangwere wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Hall (Cygwin) wrote: Morgan Gangwere wrote: bug #2 Make reports that it Cant find the ANSI C headers while compiling GnuPG (this makes no sense to me because i have all the dev packages installed). partial output: [clip] Making sure you can build shared objects with ln.exe... ok checking for ANSI C headers... [blue screen] i have yet to be able to understand _why_ this is occurring... Typical causes are buggy drivers or an O/S (kernel) bug. My money is on the former. Try uninstalling any spyware or virus software you have and see if the problem goes away. tried that my friend. ClamAV is disabled and Spybot SD (and the resident) are stopped and killed. I've also tried running sh -x configure and it still fails Turning these things off is not enough. You have to uninstall them. Otherwise, they will still be active in the network stack. Try uninstalling them. Also, there are other buggy hardware drivers. Logitec webcams are one known culprit. Unfortunately, you're going to need to experiment to find out what driver on your system is causing the problems you're seeing. FWIW, I expect ClamAV isn't the culprit but that's just my WAG. I wouldn't let that dissuade you from including it in your experimentation. i am using a NetGear Mobile adapter with NG's driver. i have also tried running spybot SD in dead mode - a completely scan-of-the-drive only mode another thing that I do have is the _windows_ firewall... i have no way of removing that (sans for going back to 98, OC...) though I can DISABLE it to some extent (when it says something is trying to talk to the net! i'm gonna block it until you say otherwise! i tell it to unblock and go away)... i doubt this is the culprit though i have no Way of Testing this. one note is that when i try to build on my main WinXP machine (never touches the net etc.) i get the same results. i have disabled the Windows Firewall by using GoAwaySP2Firewall.. this however does not make life any simpler.. is this an issue with the configure script or make? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) iD8DBQFFpGvbXIyDjlIx4voRAvQIAJkB+ErkKqCulRl0OeAMxhd1vvI/gQCffodC mwgpGJaAj3RjpaIJko80hM4= =X/YX -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [BUG] cygport-0.2.7 fails to build multiple binary packages
Stefan Björnelund wrote: While tying to rebuild the gettext-0.15-1 package, I noticed that it did not build correctly any more. Answered here: http://cygwin.com/ml/cygwin-apps/2007-01/msg00014.html -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Link errors related to vtable
Hi, I am getting link errors like below when I compile my code(systemc) which is on cygwin 1.5.23 with gcc 3.4.4 (systemc is a c++ class library) I may be wrong but I feel the errors are related to the gcc in cygwin. I searched the archive but couldnt find any posts related to this. Can anyone can give me any pointers to what might be the problem. --- g++ -O3 -Wall -I. -I.. -I../../../include -L. -L.. -L../../../lib-linux -o run.x packet.o packet_generator.o hub.o main.o -lsystemc -lm 21 | c++filt main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0x91): undefined reference to `VTT for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0xa3): undefined reference to `VTT for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0xad): undefined reference to `VTT for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0xc2): undefined reference to `VTT for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0xcc): undefined reference to `vtable for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0xd3): undefined reference to `vtable for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0xda): undefined reference to `vtable for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0xe1): undefined reference to `vtable for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0x600): undefined reference to `VTT for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0x612): undefined reference to `VTT for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0x622): undefined reference to `VTT for packet_fifo' main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fifo::packet_fifo(sc_core::sc_module_name)]+0x62f): undefined reference to `VTT for packet_fifo' collect2: ld returned 1 exit status --- thanks mark __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Arkeia
I'm working with Arkeia and I'm trying to get Cygwin on a windows xp client to connect to the Linux backup server using SSH. Does anybody have experience with this? I'm able to connect to the server but I can't get the gui to come up. I can ping both ways and I've shut down firewalls on both sides (This is just a test network). I thought SSH handles the exporting of the Linux gui so it should be visible through Cygwin. Do I need to change anything on the linux server? Thanks -- View this message in context: http://www.nabble.com/Arkeia-tf2950828.html#a8252654 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: git-1.4.4.4-1
Eric Blake writes: A new release of git, 1.4.4.4-1, has been uploaded, replacing 1.4.4.3-1 as the current version. No big deal but I'm wondering why all files are listed twice in o /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/Git/.packlist Ciao Volker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
New procps package filename is procps-3.2.7-1-bin.tar.bz2 instead of procps-3.2.7-1.tar.bz2
see subject Ciao Volker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
