Re: [ANNOUNCEMENT] New package: brltty 3.8
* Samuel Thibault (Wed, 6 Jun 2007 07:08:31 +0800) > Version 3.8 of "brltty" has been uploaded. > > Access software for a blind person using a soft braille terminal. > Brltty is a background process (daemon) providing access to the Windows > Console for a blind person using a refreshable braille display. Aah, wonderful. But why are we all by default blind? I mean: why is it in the "Base" category?! -- 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] New package: brltty 3.8
Thorsten Kampe, le Wed 06 Jun 2007 09:33:04 +0100, a écrit : > * Samuel Thibault (Wed, 6 Jun 2007 07:08:31 +0800) > > Version 3.8 of "brltty" has been uploaded. > > > > Access software for a blind person using a soft braille terminal. > > Brltty is a background process (daemon) providing access to the Windows > > Console for a blind person using a refreshable braille display. > > Aah, wonderful. But why are we all by default blind? I mean: why is it > in the "Base" category?! Mmm, because for a blind person this is a very basic package? Are packages from the Base category automatically installed? (Note that Ubuntu installs brltty by default too). Samuel -- 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] New package: brltty 3.8
Samuel Thibault wrote: > Mmm, because for a blind person this is a very basic package? Perhaps, but that doesn't mean that most Cygwin users are blind. > Are packages from the Base category automatically installed? Yes, setup automatically selects everything in Base for installation, which by definition forms the basic core set of packages that every user will have installed unconditionally. I don't think brltty should be in this category. Note that even if you select to uninstall a Base package in setup it will just get re-installed again the next time you run it; there's no way to override this. Base really does mean the core set of packages that are unconditionally selected. > (Note that Ubuntu installs brltty by default too). Yes, and Windows installs accessibility features by default too. But Cygwin is not an operating system and a package in Base is not an optional thing that a user can easily uninstall, so the comparison doesn't hold much weight in my opinion. 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: [ANNOUNCEMENT] New package: brltty 3.8
On Jun 6 02:42, Brian Dessent wrote: > Samuel Thibault wrote: > > > Mmm, because for a blind person this is a very basic package? > > Perhaps, but that doesn't mean that most Cygwin users are blind. Perhaps, but that doesn't mean that an accessibility package doesn't make sense in the Base category. It *might* be better to put it into Utils, but YMMV depending on your eyesight. Looking into the package again, I noticed two problems, though: - There's an executable xbrlapi.exe in the package which depends on X. This is not noted in setup.hint. However, No package in the Base category should depend on X, so that X isn't pulled in by default. Samuel, can you re-package brltty so that it comes in two packages, one brltty package which could be in Base or Utils, and another package called xbrlapi which is in X11 and Utils? - cygbrlapi-0.5.dll depends on WS2_32.DLL. Why? Shouldn't the package use Cygwin's socket functions? 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/
need working cygwin tool for https download
Hi, I tried lynx and curl on this and can't get either to work: https://www.affymetrix.com/analysis/netaffx/fullrecord.affx?pk=CANINE%3A1602952_AT Since I've never used https before, I'm not sure if I'm doing something stupid or there is a problem with lynx or the page is setup to defeat automated download. I've had good luck with this company's techsupport but their developer support refused to tell me how to download a single webpage. This created a core dump: lynx -pauth user:xxx -dump "https://www.affymet... and this didn't seem to work much better: curl --user-agent "Mozilla/4.0" --anyauth -d "logon=xxx" -d "password=xxxc" -c cookies -L "https://www.affymetrix.com/analysis/netaf fx/fullrecord.affx?pk=CANINE%3A1592474_AT" If you are really interested, you can get a free account to try it but I imagine there is something obvious I have done wrong or a known bug with lynx. Thanks. _ Play games, earn tickets, get cool prizes. Play nowit's FREE! http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink1 -- 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: file-4.21-1
I've updated the version of file to 4.21-1. This version is an update to the official version 4.21. This is mainly a security bugfix release, fixing a buffer underflow vulnerability. See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2799 The Cygwin version is build from the vanilla sources, plus an additional patch for a problem found by the AMaVis team. The patch to the magic file as described in paragraph 4. "Additional information" from http://www.amavis.org/security/asa-2007-3.txt has been applied to this Cygwin release. 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. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- 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: need working cygwin tool for https download
Mike Marchywka wrote: > curl --user-agent "Mozilla/4.0" --anyauth -d "logon=xxx" > -d "password=xxxc" -c cookies -L "https://www.affymetrix.com/analysis/netaf > fx/fullrecord.affx?pk=CANINE%3A1592474_AT" And what is the exact error or failure? curl works just fine with https, you can verify that your installation works with a site that has a known-good cert, such as: $ curl -o /dev/null https://login.yahoo.com/ If you want to use https with a command line tool you need to determine who signed the site's certificate and if that CA's cert is included in the stock CA-bundle which for curl is /usr/share/curl/curl-ca-bundle.crt. If it's not in the bundle you need to specify it with --cacert or --capath. Read the man page and don't be confused by --cert which is something very different and unrelated unless you yourself have a peer cert and the website expects it (and if you don't know, you don't.) If you can't do any of this, or the site is using self-signed/snake oil, then you can use -k which means don't verify the site's certificate. The connection is still encrypted and cannot be snooped by third parties, but there's no assurance that the party you are talking to is who them claim to be. 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: need working cygwin tool for https download
Thanks- I was hoping lynx would work as I use that for everything else. Apparently curl was just redirecting to a login screen. If I post to their form I can at least get the bad user/pw screen so it seems that curl, and for that matter wget, do seem to just fine. Now, I just need to figure out how to put the form data together and deal with session things. From: Brian Dessent <[EMAIL PROTECTED]> Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com Subject: Re: need working cygwin tool for https download Date: Wed, 06 Jun 2007 04:01:29 -0700 Mike Marchywka wrote: > curl --user-agent "Mozilla/4.0" --anyauth -d "logon=xxx" > -d "password=xxxc" -c cookies -L "https://www.affymetrix.com/analysis/netaf > fx/fullrecord.affx?pk=CANINE%3A1592474_AT" And what is the exact error or failure? curl works just fine with https, you can verify that your installation works with a site that has a known-good cert, such as: $ curl -o /dev/null https://login.yahoo.com/ If you want to use https with a command line tool you need to determine who signed the site's certificate and if that CA's cert is included in the stock CA-bundle which for curl is /usr/share/curl/curl-ca-bundle.crt. If it's not in the bundle you need to specify it with --cacert or --capath. Read the man page and don't be confused by --cert which is something very different and unrelated unless you yourself have a peer cert and the website expects it (and if you don't know, you don't.) If you can't do any of this, or the site is using self-signed/snake oil, then you can use -k which means don't verify the site's certificate. The connection is still encrypted and cannot be snooped by third parties, but there's no assurance that the party you are talking to is who them claim to be. 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/ _ Like puzzles? Play free games & earn great prizes. Play Clink now. http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2 -- 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: Problem with /proc/registry
Bengt-Arne Fjellner wrote:
> Hi When trying to check some keys in the registry I ran into some
> problems System is winxp and it doesn't matter if I'm administrator
> Or not.
>
> ls -la /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices/
> Gives a long list of:
> ls: cannot access
> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices/\??\Volume{8
> 38be
> 37a-f0e7-11db-8f46-000f1fe9abb4}: No such file or directory
>
> And the entries later looks like:
> ?? ? ? ? ??
> \??\Volume{df4d791a-290c-11da-b3c8-806d6172696f
>
> Is this a known problem or is it just me?
>
> --
> Bengt-Arne Fjellner
It's not just U; it's WinXP privileges. Just being an administrator
doesn't automatically give U all the authorization U need to do
anything U want. U may have to add privileges in order to look at
those keys. I'm not sure how to go about doing that, but U can
probably find more pertinent information on microsoft.com (or google
for non-mirosoft information).
Goss ... Innovation for Business
NOTICE: This e-mail and any attachment(s) may contain confidential and
proprietary information of Goss International Corporation and/or its
subsidiaries and may be legally privileged. This e-mail is intended solely for
the addressee. If you are not the addressee, dissemination, copying or other
use of this e-mail or any of its content is strictly prohibited and may be
unlawful. If you are not the intended recipient please inform the sender
immediately and destroy the e-mail and any copies. All liability for viruses is
excluded to the fullest extent permitted by law. Any views expressed in this
message are those of the individual sender. No contract may be construed by
this e-mail.
--
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/
cron functionality regression?
Hello, >From http://sourceware.org/ml/cygwin/2007-04/msg00319.html : > The changes (listed in /usr/share/doc/cron/CHANGES) don't appear to break > compatibility with 3.0. this seems to be a version of vixie cron which (contrary to the previous one) consistently (e.g. also in the manpage) does not (yet?, any more?) support crontabs in /etc/cron.d . How sad. Thomas Berger -- 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/
CVS 1.7.0 heap errors
FYI, I'm seeing the following errors quite often with current 1.7.0 CVS and have been for some time. For instance, I can't use my CVS build to build Cygwin again. I've yet to have time to investigate much, and don't see that changing for some time :-(. 6 [main] ? (1584) C:\cygwin\bin\make.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x68, top 0x6B, reserve_size 192512, allocsize 196608, page_const 4096 585603 [main] make 1736 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 This is just in case any developer remembers a recent (within a couple of months) possibly related change. If not, I'll try to binary search CVS as soon as my schedule frees up some. Thanks. -- 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: [ANNOUNCEMENT] New package: brltty 3.8
On Wed, Jun 06, 2007 at 12:26:54PM +0200, Corinna Vinschen wrote: >On Jun 6 02:42, Brian Dessent wrote: >> Samuel Thibault wrote: >> >> > Mmm, because for a blind person this is a very basic package? >> >> Perhaps, but that doesn't mean that most Cygwin users are blind. > >Perhaps, but that doesn't mean that an accessibility package doesn't >make sense in the Base category. It *might* be better to put it into >Utils, but YMMV depending on your eyesight. With all due respect to blind people, I don't think that we should be putting things in the Base category without consensus. Hopefully other people haven't been doing this either. 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: [ANNOUNCEMENT] New package: brltty 3.8
Brian Dessent wrote: > Samuel Thibault wrote: >> Mmm, because for a blind person this is a very basic package? > > Perhaps, but that doesn't mean that most Cygwin users are blind. Last I heard, setup.exe was not particularly friendly wrt screen readers (cf. package selection). Hence the visually impaired would have difficulty selecting brltty for installation. In addition to installation brltty also needs an amount of configuration to select the type of terminal to use, and for the daemon to be started. Despite the latter I would suggest that (at least the non-X bit of) brltty should be kept in Base to make things simpler for those who need it. At least until we get that revamped setup.exe :) Regards, DaveK2. -- 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] New package: brltty 3.8
On 6/6/07, Dave wrote: Brian Dessent wrote: > Samuel Thibault wrote: >> Mmm, because for a blind person this is a very basic package? > > Perhaps, but that doesn't mean that most Cygwin users are blind. Last I heard, setup.exe was not particularly friendly wrt screen readers (cf. package selection). Hence the visually impaired would have difficulty selecting brltty for installation. In addition to installation brltty also needs an amount of configuration to select the type of terminal to use, and for the daemon to be started. Despite the latter I would suggest that (at least the non-X bit of) brltty should be kept in Base to make things simpler for those who need it. At least until we get that revamped setup.exe :) Regards, DaveK2. It seems that when you trace the requirements of brltty down, you end up with xorg, perl, and python packages getting installed. So, do we want those to be considered part of Base? -Jason -- NOTICE: This email is being sent in clear-text across the public Internet. Therefore, any attempts to include unenforceable legalese restrictions are ridiculous and pointless. If you can read this, consider yourself authorized (whether I like it or not). -- 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] New package: brltty 3.8
On Wed, Jun 06, 2007 at 02:22:30PM -0500, DePriest, Jason R. wrote: > On 6/6/07, Dave wrote: >> Brian Dessent wrote: >> > Samuel Thibault wrote: >> >> Mmm, because for a blind person this is a very basic package? >> > >> > Perhaps, but that doesn't mean that most Cygwin users are blind. >> >> Last I heard, setup.exe was not particularly friendly wrt screen readers >> (cf. package selection). Hence the visually impaired would have >> difficulty selecting brltty for installation. >> >> In addition to installation brltty also needs an amount of configuration >> to select the type of terminal to use, and for the daemon to be started. >> >> Despite the latter I would suggest that (at least the non-X bit of) >> brltty should be kept in Base to make things simpler for those who need >> it. At least until we get that revamped setup.exe :) > > It seems that when you trace the requirements of brltty down, you end > up with xorg, perl, and python packages getting installed. > > So, do we want those to be considered part of Base? No. I've removed it from Base. 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: [ANNOUNCEMENT] New package: brltty 3.8
Samuel Thibault, le Thu 07 Jun 2007 03:24:45 +0800, a écrit : > About the linux-utils dependency, it was needed in previous brltty > revisions, but not any more, so I'll drop it. You may want to update setup.hint from http://brl.thefreecat.org/brltty/setup.hint to fix them as soon as now without the need for a new packaging. Samuel -- 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] New package: brltty 3.8
Hi, DePriest, Jason R., le Wed 06 Jun 2007 14:22:30 -0500, a écrit : > It seems that when you trace the requirements of brltty down, you end > up with xorg, perl, and python packages getting installed. Python dependency is only hard for compile-time. Brltty doesn't itself use python. Only python programmers may want to use the brltty python bindings. Again, this could be very well split apart, but that again makes a very little package for no benefit. Samuel -- 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: cron functionality regression?
- Original Message - From: "Thomas Berger" To: "The Cygwin Mailing List" Sent: Wednesday, June 06, 2007 9:38 AM Subject: cron functionality regression? | Hello, | | From http://sourceware.org/ml/cygwin/2007-04/msg00319.html : | | > The changes (listed in /usr/share/doc/cron/CHANGES) don't appear to break | > compatibility with 3.0. | | this seems to be a version of vixie cron which (contrary to the | previous one) consistently (e.g. also in the manpage) does not (yet?, | any more?) support crontabs in /etc/cron.d . Yep, looks like it's gone (there is no real changelog), no idea why (except that /etc/cron.d is not in POSIX ). Is this regression a real problem for you (i.e. no quick workaround) or for others? If so I could try to cut & paste it back from 3.0, or use another cron (which one?). In general I prefer not modifying "standard" packages. Pierre -- 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] New package: brltty 3.8
Brian Dessent, le Wed 06 Jun 2007 02:42:50 -0700, a écrit : > > Mmm, because for a blind person this is a very basic package? > > Perhaps, but that doesn't mean that most Cygwin users are blind. Indeed, but as pointed out by DaveK2: > Last I heard, setup.exe was not particularly friendly wrt screen readers > (cf. package selection). I can confirm that. > Hence the visually impaired would have difficulty selecting brltty for > installation. Indeed. > > Are packages from the Base category automatically installed? > > Yes, setup automatically selects everything in Base for installation, Ah, I didn't know that, is that documented somewhere ? > Note that even if you select to uninstall a Base package in setup it > will just get re-installed again the next time you run it; there's no > way to override this. Base really does mean the core set of packages > that are unconditionally selected. Just the same. > > (Note that Ubuntu installs brltty by default too). > > Yes, and Windows installs accessibility features by default too. But > Cygwin is not an operating system and a package in Base is not an > optional thing that a user can easily uninstall, so the comparison > doesn't hold much weight in my opinion. Indeed. > - There's an executable xbrlapi.exe in the package which depends on X. > This is not noted in setup.hint. However, No package in the Base > category should depend on X, so that X isn't pulled in by default. > > Samuel, can you re-package brltty so that it comes in two packages, > one brltty package which could be in Base or Utils, and another > package called xbrlapi which is in X11 and Utils? Well, xbrlapi is not useful by itself alone with X11, it is only useful with other applications, so that building a separate package just for it to pull the X11 dependency looked to me quite abusive, but I can still do that. > - cygbrlapi-0.5.dll depends on WS2_32.DLL. Why? Shouldn't the package > use Cygwin's socket functions? That would make programming less easy. Brltty can communicate with other (potentially non-cygwin) applications with tcp/ip (remotely) or local pipes (locally, more efficiently). For keeping compatibility with other applications for local pipes, windows pipes are used. Mixing cygwin sockets and windows local pipes is not particularly fun, so that's why we end up just using windows socket and WaitForMultipleObjects() in a separate thread. About the linux-utils, it was needed in previous brltty revisions, but not any more, so I'll drop it. Samuel -- 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] New package: brltty 3.8
On Thu, Jun 07, 2007 at 03:24:45AM +0800, Samuel Thibault wrote: >Brian Dessent, le Wed 06 Jun 2007 02:42:50 -0700, a ?crit : >> > Mmm, because for a blind person this is a very basic package? >> >> Perhaps, but that doesn't mean that most Cygwin users are blind. > >Indeed, but as pointed out by DaveK2: > >> Last I heard, setup.exe was not particularly friendly wrt screen readers >> (cf. package selection). > >I can confirm that. > >> Hence the visually impaired would have difficulty selecting brltty for >> installation. > >Indeed. > >> > Are packages from the Base category automatically installed? >> >> Yes, setup automatically selects everything in Base for installation, > >Ah, I didn't know that, is that documented somewhere?? Yes: http://cygwin.com/cygwin-ug-net/setup-net.html >That would make programming less easy. Brltty can communicate with >other (potentially non-cygwin) applications with tcp/ip (remotely) or >local pipes (locally, more efficiently). For keeping compatibility >with other applications for local pipes, windows pipes are used. >Mixing cygwin sockets and windows local pipes is not particularly fun, >so that's why we end up just using windows socket and >WaitForMultipleObjects() in a separate thread. You haven't really described why the linux-like pipe() command is inadequate for anything that an application needs. Merely stating that "mixing cygwin sockets and windows local pipes is not... fun" is not really an argument for not doing it. I have no idea what you're talking about there but regardless if this is a hybrid windows/cygwin program then we'll have to reconsider its inclusion in the distribution. Unless there is good reason, the cygwin distribution really is supposed to be comprised of programs which use the linux API. 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/
chgcheck.out
Cygwin Configuration Diagnostics Current System Time: Wed Jun 06 14:50:17 2007 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 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 c:\progra~1\VIAVOI~1 C cygwin\bin C:\cygwin\usr\X11R6\bin c:\Program Files\websm\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 11126(CarlosR) GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 10545(mkgroup-l-d) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11126(CarlosR) GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 10545(mkgroup-l-d) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'CarlosR' PWD = '/cygdrive/c/Documents and Settings/carlosr' HOME = '/cygdrive/c/Documents and Settings/carlosr' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\carlosr' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\carlosr\Application Data' HOSTNAME = 'OIS-CROBINSON-LT' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 13 Stepping 8, GenuineIntel' WINDIR = 'C:\WINDOWS' OLDPWD = '/usr/bin' USERDOMAIN = 'ITSEP' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/carlosr/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' WSMDIR = 'C:\Program Files\websm' USERNAME = 'CarlosR' PROCESSOR_LEVEL = '6' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' __COMPAT_LAYER = 'EnableNXShowUI ' USERPROFILE = 'C:\Documents and Settings\carlosr' CLIENTNAME = 'Console' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\NTITS01' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' USERDNSDOMAIN = 'ITS.NET.UCSF.EDU' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/carlosr/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'HP Color LaserJet 2600n' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0d08' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '1' SESSIONNAME = 'Console' COMPUTERNAME = 'OIS-CROBINSON-L' _ = '/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 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 57153Mb 60% CP CS UN PA FC d: cd N/AN/A h: net NTFS 4096Mb 0% CP CS UN PA FC Users k: netN/AN/A m: net NTFS 14637Mb 65% CP CS UN PA FC p: net NTFS 15006Mb 87% CP CS UN PA FC NTITS01-06 s: net NTFS 14637Mb 65% CP CS UN PA FC w: net NTFS 14637Mb 65% CP CS UN PA FC x: net NTFS 4096Mb 0% CP CS UN PA FC Users C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Not Found: cpp (good!) Not Found: crontab Found: C:\cygwin\bin\find.exe Not Found: gcc Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Not Found: ld Found: C:\cygwin\bin\ls.exe Not Found: make Found: C:\cygwin\bin\mv.exe Not Found: patch Found: C:\cygwin\bin\perl.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\test.exe Not Found: vi Found: C:\cygwin\bin\vim.exe 32k 2007/06/05 C:\cygwin\bin\cygbrlapi-0.5.dll - os=4.0 img=1.0 sys=4.0 "cygbrlapi-0.5.dll" v0.0 ts=2007/6/4 18:30 61k 2006/11/10 C:\cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0 "cygbz2-1.dll" v0.0 ts=2006/11/10 15:42 7k 2006/10/22 C:\cygwin\bin\cygcharset-1.dll - os=4.0 img=1.0 sys=4.0 "cygcharset-1.dll" v0.0 ts=2006/10/22 16:43
Re: SWIG: Python 2.5
Yaakov (Cygwin Ports) wrote: > SWIG maintainer, > > Support for Python 2.5 was added to SWIG in >= 1.3.30, but the distro > has curr: 1.3.29-2. As Python 2.5 is now in the distro, a SWIG update > is imperative to those of us building Python extensions. The Subversion Python bindings build fine, using Cygwin's Python 2.5 and SWIG 1.3.29. Max. signature.asc Description: OpenPGP digital signature
replicating my cygwin install on a different machine
Hi There, I was wondering if there was a way to save and duplicate my cygwin installation so I can replicate it on a different machine. The idea is, I have scripts and programs developed and tested on my cygwin install. I want to be able to deploy everything that I am running on my machine. I'm not sure if the setup.exe will get me what I want since older versions of packages are not always readily available (dependent on the server). Also, I want to be able to provide the operations team with a zip file or some kind of installation package to replicate on each server. The idea is to avoid new downloads and use what I have until I need to upgrade. thanks, Jerome -- 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: replicating my cygwin install on a different machine
On 6/6/07, Jerome Fong wrote: Hi There, I was wondering if there was a way to save and duplicate my cygwin installation so I can replicate it on a different machine. The idea is, I have scripts and programs developed and tested on my cygwin install. I want to be able to deploy everything that I am running on my machine. I'm not sure if the setup.exe will get me what I want since older versions of packages are not always readily available (dependent on the server). Also, I want to be able to provide the operations team with a zip file or some kind of installation package to replicate on each server. The idea is to avoid new downloads and use what I have until I need to upgrade. thanks, Jerome Assuming you use the same drive letters and directory structure, you can just zip up your cygwin data (preferably with something that can maintain file permissions) and dump HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions to a .reg file. Just extract the stuff on the other system and import the .reg and you should be good to go. Depending on your install, the archive file could end up being quite large. -Jason -- NOTICE: This email is being sent in clear-text across the public Internet. Therefore, any attempts to include unenforceable legalese restrictions are ridiculous and pointless. If you can read this, consider yourself authorized (whether I like it or not). -- 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: replicating my cygwin install on a different machine
On Wed, Jun 06, 2007 at 06:03:22PM -0500, DePriest, Jason R. wrote: > On 6/6/07, Jerome Fong wrote: >> Hi There, >> >> I was wondering if there was a way to save and duplicate my cygwin >> installation so I can replicate it on a different machine. The idea is, >> I have scripts and programs developed and tested on my cygwin install. >> I want to be able to deploy everything that I am running on my machine. >> >> I'm not sure if the setup.exe will get me what I want since older >> versions of packages are not always readily available (dependent on the >> server). Also, I want to be able to provide the operations team with a >> zip file or some kind of installation package to replicate on each >> server. The idea is to avoid new downloads and use what I have until >> I need to upgrade. > > Assuming you use the same drive letters and directory structure, you > can just zip up your cygwin data (preferably with something that can > maintain file permissions) and dump HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus I would not suggest using "zip" as the mechanism for backing up and restoring. As has been noted 10497 times in this mailing list Windows ZIP does not properly save the bits needed to recreate things like symlinks. And, we've also mentioned at least as many times that you DO NOT MANIPULATE THE REGISTRY DIRECTLY. Use "mount -m" to create a .bat file suitable for recreating the mount table. So, the proper way to do this is to copy cygwin1.dll, tar.exe, mount.exe to the other computer, in a temporary directory. Run the .bat file created by mount -m to recreate the mount table and use tar.exe to extract the tar ball created. 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/
[EMAIL PROTECTED]: Re: replicating my cygwin install on a different machine]
- Forwarded message from Christopher Faylor <[EMAIL PROTECTED]> - I would not suggest using "zip" as the mechanism for backing up and restoring. As has been noted 10497 times in this mailing list Windows ZIP does not properly save the bits needed to recreate things like symlinks. And, we've also mentioned at least as many times that you DO NOT MANIPULATE THE REGISTRY DIRECTLY. Use "mount -m" to create a .bat file suitable for recreating the mount table. So, the proper way to do this is to copy cygwin1.dll, tar.exe, mount.exe to the other computer, in a temporary directory. Run the .bat file created by mount -m to recreate the mount table and use tar.exe to extract the tar ball created. - End forwarded message - Will this alternate method work? I am thinking about trying this. 1. Archive the "Local Package Directory" that features in setup.exe. 2. Restore the above to the new computer. Preserve file structure, but don't worry about permissions or symlinks. Make everything read and writable by everyone. 3. Run setup.exe on the new computer. Apply the "Install from Local Directory" option. Select the new location of the above "Local Package Directory" that was restored in step 2. -- 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: replicating my cygwin install on a different machine
[ Reply to the list please! ] David Arnstein wrote: > Will this alternate method work? I am thinking about trying this. > > 1. Archive the "Local Package Directory" that features in setup.exe. > 2. Restore the above to the new computer. Preserve file structure, but >don't worry about permissions or symlinks. Make everything read and >writable by everyone. > 3. Run setup.exe on the new computer. Apply the "Install from Local >Directory" option. Select the new location of the above "Local >Package Directory" that was restored in step 2. No, that will not do what you want. The only thing that the two installs will have in common is that for any package that happens to be selected in both installs, it is likely to have the same version since they came from the same pool. But even that's not a guarantee. The local package directory should be considered just like creating a local package mirror that contains any number of packages. But this has no effect on which packages are selected in setup, and just replicating the package cache does not replicate that set of selections that the user made when they ran setup. Nor will it replicate any user settings, mount points, local custom scripts, etc. It will only result in a new, fresh, completely-stock install of Cygwin. 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: replicating my cygwin install on a different machine
Sorry, I'm not sure what am I suppose to tar up? Christopher Faylor wrote: On Wed, Jun 06, 2007 at 06:03:22PM -0500, DePriest, Jason R. wrote: On 6/6/07, Jerome Fong wrote: Hi There, I was wondering if there was a way to save and duplicate my cygwin installation so I can replicate it on a different machine. The idea is, I have scripts and programs developed and tested on my cygwin install. I want to be able to deploy everything that I am running on my machine. I'm not sure if the setup.exe will get me what I want since older versions of packages are not always readily available (dependent on the server). Also, I want to be able to provide the operations team with a zip file or some kind of installation package to replicate on each server. The idea is to avoid new downloads and use what I have until I need to upgrade. Assuming you use the same drive letters and directory structure, you can just zip up your cygwin data (preferably with something that can maintain file permissions) and dump HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus I would not suggest using "zip" as the mechanism for backing up and restoring. As has been noted 10497 times in this mailing list Windows ZIP does not properly save the bits needed to recreate things like symlinks. And, we've also mentioned at least as many times that you DO NOT MANIPULATE THE REGISTRY DIRECTLY. Use "mount -m" to create a .bat file suitable for recreating the mount table. So, the proper way to do this is to copy cygwin1.dll, tar.exe, mount.exe to the other computer, in a temporary directory. Run the .bat file created by mount -m to recreate the mount table and use tar.exe to extract the tar ball created. 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: replicating my cygwin install on a different machine
On Wed, Jun 06, 2007 at 05:15:35PM -0700, Jerome Fong wrote: > Sorry, I'm not sure what am I suppose to tar up? You can't even hazard a guess? 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: replicating my cygwin install on a different machine
Jerome Fong wrote: Christopher Faylor wrote: On Wed, Jun 06, 2007 at 06:03:22PM -0500, DePriest, Jason R. wrote: On 6/6/07, Jerome Fong wrote: Hi There, I was wondering if there was a way to save and duplicate my cygwin installation so I can replicate it on a different machine. The idea is, I have scripts and programs developed and tested on my cygwin install. I want to be able to deploy everything that I am running on my machine. I'm not sure if the setup.exe will get me what I want since older versions of packages are not always readily available (dependent on the server). Also, I want to be able to provide the operations team with a zip file or some kind of installation package to replicate on each server. The idea is to avoid new downloads and use what I have until I need to upgrade. Assuming you use the same drive letters and directory structure, you can just zip up your cygwin data (preferably with something that can maintain file permissions) and dump HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus I would not suggest using "zip" as the mechanism for backing up and restoring. As has been noted 10497 times in this mailing list Windows ZIP does not properly save the bits needed to recreate things like symlinks. And, we've also mentioned at least as many times that you DO NOT MANIPULATE THE REGISTRY DIRECTLY. Use "mount -m" to create a .bat file suitable for recreating the mount table. So, the proper way to do this is to copy cygwin1.dll, tar.exe, mount.exe to the other computer, in a temporary directory. Run the .bat file created by mount -m to recreate the mount table and use tar.exe to extract the tar ball created. > Sorry, I'm not sure what am I suppose to tar up? > How about the same stuff that you were suggested zipping up? -- 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/
