Re: Notable performance improvement in 64-bit build
Hi Ivan, On Wed, Nov 12, 2014 at 12:52 AM, Ivan Todoroski wrote: > Hello everyone, > > I'm just curious, has there been any special focus on performance > improvements in the 64-bit version compared to 32-bit? > > I'm asking because I recently upgraded from 32-bit to 64-bit Cygwin, and I > noticed that my bash prompt would show up noticeably quicker when I opened a > new Cygwin shell (I have a rather complicated ~/.profile script, so the > delay is actually visible to the eye). Do you have the same .profile in both installations? Do you have the same bash-completion package (often the most time-consuming part of bash startup)? Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup 2.774 texlive postinstall takes 10+ hours
On Nov 12 18:53, Achim Gratz wrote: > Corinna Vinschen writes: > >> >Incremental autorebase packages and patched setup.exe available on > >> >request. > >> > >> I'd like to see them. Thanks. > > I'll upload them on the weekend latest, I'm a bit swamped at work. I'll > follow up on this in cygwin-applications. > > > Yes, me too. > > > > Achim, does your perpetual autorebase rely on the existing autorebase > > script? If so, do you see a good chance to consolidate the changes > > into a single package we're still calling _autorebase? > > No, No? > I've replaced it with an incremental autorebase which can function > as a normal autorebase as well. I've discussed bits of it on the list > ~2 years ago, but at that time there was no further interest in having > something run on every installation. > > Ah, here it is: > http://thread.gmane.org/gmane.os.cygwin.applications/23733 > http://thread.gmane.org/gmane.os.cygwin.applications/23772 From what I read here your _incautorebase would replace _autorebase just fine. I'm not concerned about an exact replacement for the rebaseall script. The idea would be to make _incautorebase into drop-in replacement for _autorebase and throw away my _autorebase stuff. Rebaseall would stay, it's part of the rebase package anyway. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTlGAKPboQU.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
On Nov 11 12:36, Corinna Vinschen wrote: > On Nov 11 07:39, Christian Franke wrote: > > Or mkpasswd -l behavior depends on nsswitch.conf setting: > > > > passwd only: Old behavior > > passwd, db: New behavior, print warning > > db only: fail > > That's an interesting idea... What I implemented in CVS now: passwd only: -l unprefixed, -L prefixed passwd, db: -l/-L local machine depends on nsswitch.conf, for other machines -l/-L behave as with passwd only. db: ditto. mkpasswd/mkgroup are used in scripts to fetch account info, not necessarily to create passwd/group, so I don't want it to fail in "db" mode. I also changed the wording of the help text to describe the -l behaviour in more detail. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpS3YTkPrS6m.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 12 21:51, Habermann, David (D) wrote: > > current scenario. Besides, it is nice to have the Cygwin HOME > > directory isolated to the Cygwin installation for a portable install > > that can be used on a USB thumb drive. > > I hadn't even thought about thumb drive/portable use since I hadn't > used mine for a while. I, too, will have to work around any change to > the current home directory location in order to continue use. For the > moment at least we can always fall back onto specifying these things > in the passwd file, although I already like the new AD system and hope > I don't have to abandon it. The idea of this discussion is to find a solution which works for everybody. In theory, the default should work for all or at least most home users. For AD environments I expect that admins already know that a bit of tweaking is required, here I'm looking for something which doesn't make the job too hard. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQkUQZ2Z0dp.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 12 23:23, Andrey Repin wrote: > > So the Cygwin home dir > > is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%, > > Which is covered by "system" setting. Which will either read the location from > AD or use %HOMEPATH%, if all else fails. > > > not %HOMEPATH%/AppData/Roaming/CMD. > > I don't see, why not. Forget for a moment about its true location. > Does it matter, where the files are located, when cygwin is running? Not when it's running, but a homedir does *not* belong under AppData, especially not under Roaming. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpT3ihn8CE_W.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 12 09:45, Warren Young wrote: > On Nov 11, 2014, at 3:18 AM, Corinna Vinschen > wrote: > > > 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). > > 2. If homeDirectory is empty, fall back to /home/$USER. > > This is just a subset of what I suggested, so I’m in favor of it. > (By subset I mean that I’d prefer you do essentially the same thing for the > non-AD case, too.) This would be most easily implemented as well. The beauty here is that probably 99% of the home users don't set HOMEDRIVE/HOMEPATH in their SAM. So they get /home/$USER as fallback, which is what they got with /etc/passwd as well. And SAM users have the XML-like description field entry as well. For AD environments HOMEDRIVE/HOMEPATH are typically set, though. Here the users get what they have to use as homedir anyway. It's simple, but it should work OOTB for most people. > > 1. Always use /home/$USER and let the admins come up with a matching > > mount point scheme. > > That’s neglecting your responsibility as BDFL to set a sensible Heh. I didn't see myself as BDFL yet. Not sure if that's an honor. > default. The consequence is that everyone will do it differently, and > then you’ll have to support everything on an equal basis, because you > chose not to endorse anything. > > When you choose a sensible default, you get the option to criticize > and even deprecate wild alternative schemes. This is a philosophical argument. You'd have to argue in how far always using /home/$USER is NOT a sensible default. > > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of > > the above: > > > >home: [unix|win|home]... > > > > - "unix" means, set pw_dir to unixHomeDirectory > > - "win" means, set pw_dir to homeDirectory > > - "home" means, set pw_dir to /home/$USER > > - Multiple entries are possible. > > - Default in the absence of this setting is: always set pw_dir to > > /home/$USER. > > I see that as orthogonal. It has the advantage of providing not only > a sensible default but also a list of endorsed alternatives. > > Whether you *want* to endorse some or all of these alternatives by > codifying them is a separate question. I guess I end up doing this anyway. How complex it becomes is another question, which I can answer probably only after starting to code it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpP3UFaFqJ96.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 12 17:19, Warren Young wrote: > On Nov 12, 2014, at 3:43 PM, Andrew DeFaria > wrote: > > > On 11/12/2014 2:16 PM, Warren Young wrote: > >>> What local changes/installations get lost? > >> > >> Currently, if you nuke a default installation into c:\cygwin, you > >> lose /home, /etc, /var and /usr/local, all of which contain user > >> files and/or local system configuration. > > > > Technically user files can exist anywhere in the file system > > All the more reason to move to a world where it’s possible to start > securing /usr/bin, /usr/lib, /usr/share… so that only setup.exe can > write to it. > > I’m not advocating that step so early, but maybe if this breakup does > happen, a few years later setup.exe can start applying some strong > ACLs to files it writes. ??? What "strong" ACLs? Setup creates the files with standard POSIX permissions. Which permissions are too open from your POV? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQ3JF4ytkeu.pgp Description: PGP signature
Re: gnutls-3.2.20 doesn't compile anymore, probably conficting with installed libopts-devel
> Yaakov Selkowitz writes: > On 2014-11-12 14:40, Dr. Volker Zell wrote: >> I now tried the compilation with your cygport and your two patches but I >> still get the same error. I also updated to the latest autogen package >> you just provided. Do you mind sending me your compilation log files...I >> would like to diff them with mine... > I don't have them at the moment, as I cleaned the directories after the build. > Could you send yours? http://volkerzell.de/cygwin/tmp/gnutls-3.2.20-1-compile.log >> I haven't done any cygwin stuff since more than a year, and I recently >> updated my cygwin installation to ALL the current packages (both >> 32/64bit) , but something seems strange here. I want to sort this out >> before updating my packages to their latest upstream versions. By the >> way the current gnutls compilation has been done on a 32bit >> installation, so please send me the corresponding log files. > Wait, are you saying that you are trying to cross-compile from i686 to x86_64? No, I have separate installations of 32bit and 64bit installations. Ciao Volker -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 12 11:00, Warren Young wrote: > I didn’t want to derail the discussion about the future of /home with > this, so I’m starting a new thread. > > I think it would be an improvement to Cygwin if c:\cygwin contained > only things that can be reinstalled from your local setup.exe download > cache, in the same way that you can nuke "c:\Program Files\Microsoft > Office $version” and reinstall without losing anything you created > locally. > > Further design principles follow from this: > > - User data should live in directories that those users are normally > allowed to write to. > > - Per-machine software and per-machine configuration should be in > directories that local Administrators can normally write to. > > - Software built from source (/usr/local) should not be in c:\cygwin; > it is per-machine configuration, and so should be elsewhere. > > - If you tighten down what remains so that normal users only get read > permission, it should continue to function, in the same way that > normal users on a Linux box don’t need write access to, say, > /usr/include. > > > This /etc/fstab addition mostly accomplishes that: > > > c:/Users/Public/Cygwin/var /var ntfs auto 0 0 > c:/Users/Public/Cygwin/usr/local /usr/local ntfs auto 0 0 > > c:/Users/Public/Cygwin/tmp /tmp ntfs notexec 0 0 > c:/Users/Public/Cygwin/tmp /usr/tmp ntfs notexec 0 0 > c:/Users/Public/Cygwin/tmp /var/tmp ntfs notexec 0 0 > > > I propose that this or something like it be added to the default > fstab. No. This would even break Setup right now. Also, Users\Public doesn't exist on XP/2K3 so this needs additional logic as long as we support XP/2K3. I'm not entirely opposed to such an idea. But... - definitely not this year. or even the first half of next year. We have to consolidate the changes to account handling first, and, right now, I'm basically the only developer working on the Cygwin core more than just doing small patches. - A change like this should probably work in conjunction with a setting in the Setup GUI. - So this requires changes in Setup and Cygwin. I'm not going to do that, unless I have more support on the coding side, and more participation of serious coders on the cygwin-developer ML. - Did I mention that stuff like this would be much less hassle if we had more people doing some coding? > The only thing remaining in c:\cygwin that can’t be moved in this way > — but which it would be nice to — is /etc. If you try, you will find > that it makes Cygwin asplode; cygwin1.dll needs to find > $cygbindir/../etc in order to find /etc/fstab, at the least. That's documented behaviour, and it's an obvious chicken/egg problem, isn't it? fstab is the file *defining* mount points, so Cygwin can't use the mount points in fstab to find etc/fstab Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDvCZRNLHzF.pgp Description: PGP signature
Re: gnutls-3.2.20 doesn't compile anymore, probably conficting with installed libopts-devel
On 2014-11-13 03:34, Dr. Volker Zell wrote:
Yaakov Selkowitz writes:
> On 2014-11-12 14:40, Dr. Volker Zell wrote:
>> I now tried the compilation with your cygport and your two patches but I
>> still get the same error. I also updated to the latest autogen package
>> you just provided. Do you mind sending me your compilation log files...I
>> would like to diff them with mine...
> I don't have them at the moment, as I cleaned the directories after the
build.
> Could you send yours?
http://volkerzell.de/cygwin/tmp/gnutls-3.2.20-1-compile.log
Would you happen to have another autogen in your PATH besides that in
/usr/bin? Could you also post your generated srptool-args.{c,h}?
--
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [REQUEST] Please upgrade irssi (0.8.17)
On 11/12/2014 10:14 PM, Keith Christian wrote: Perhaps it hasn't propagated to the osuosl server yet. Should I click the EXP radio button in Setup and cycle through Keep...Reinstall...Src... etc. to see the new version? correct, EXP button. You should not need to cycle through, 0.8.17 will be offered as new update Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] [HEADSUP] Intermediate 1.7.33 release coming
Hi folks, Given the ongoing discussion about required changes to the new, Windows SAM/AD-based account handling in Cygwin, the release coming with these changes will be deferred until we have a satisfying solution for this. However, there's a good number of changes compared to 1.7.32 in the repository which are likewise important and shouldn't be deferred any longer. Therefore I'm going to release an intermediate 1.7.33 release in the next couple of hours, which comes with most, but not all changes from the 1.7.33 test releases. The new test release will have a 1.7.34-xxx version number, so don't be surprised. You have been warned and all that. Thanks for reading, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: sitecopy 0.16.6-2
An update of the sitecopy package is available in the Cygwin distribution. This is a Cygwin-only update, that puts documentation files in the right locations. Thanks to Volker Zell for reporting the problem in the previous release. sitecopy is for easily maintaining remote web sites. The program will upload files to the server which have changed locally, and delete files from the server which have been removed locally, to keep the remote site synchronized with the local site with a single command. Home page: http://www.manyfish.co.uk/sitecopy/ Andrew E. Schulman *** 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: cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#subscribe-unsubscribe Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gnutls-3.2.20 doesn't compile anymore, probably conficting with installed libopts-devel
> Yaakov Selkowitz writes: > On 2014-11-13 03:34, Dr. Volker Zell wrote: >>> Yaakov Selkowitz writes: >> >> > On 2014-11-12 14:40, Dr. Volker Zell wrote: >> >> I now tried the compilation with your cygport and your two patches but I >> >> still get the same error. I also updated to the latest autogen package >> >> you just provided. Do you mind sending me your compilation log files...I >> >> would like to diff them with mine... >> >> > I don't have them at the moment, as I cleaned the directories after the build. >> > Could you send yours? >> >> http://volkerzell.de/cygwin/tmp/gnutls-3.2.20-1-compile.log > Would you happen to have another autogen in your PATH besides that in /usr/bin? Bingo...I had a self compiled version from years ago lying in my /usr/local structure. After removing the old craft everything is fine again. I try now to catch up updating all of my packages Ciao Volker -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup 2.774 texlive postinstall takes 10+ hours)
On Nov 11 12:53, Corinna Vinschen wrote:
> On Nov 10 22:33, Yaakov Selkowitz wrote:
> > On 2014-11-10 22:23, Yaakov Selkowitz wrote:
> > >Dependency order of packages: libgcc1 base-cygwin cygwin dash tzcode
> > >libstdc++6 terminfo sed gzip libpcre1 grep libreadline7 bash
> > >libncursesw10
> > [snip]
> >
> > Now that I think about it, regardless of libgcc1, that still doesn't make
> > much sense. sed, grep, and bash depend on libintl8, which depends on
> > libiconv2, and libreadline7 (which is required by bash) itself depends on
> > libncursesw10, so that should be at least two places earlier. All of those
> > dependencies are listed in setup.hint (and hence setup.ini), so is there
> > something wrong with setup itself?
>
> What about dependency loops?
>
> AFAICS, coreutils depends on tzcode, tzcode depends on coreutils. Both
> depend on libgcc1. This introduces a big problem in dependency
> resolution because there's no unambiguous starting point.
>
> What if we remove the coretuls dep from tzcode.
>
> Or, actually, what if we make sure that Base packages only depend
> on libs, but never on any other Base package?
Ok, now after a collegue of mine informed me about the existence of
tsort (*blush*), I could finally produce some more info about loops
in our dependencies. I wrote a simple script:
awk '/^@ /{ left=$2; }
/^requires: /{ for (i=2; i<=NF; ++i) print left " " $i; }
' < setup.ini | tsort
It found the following dependency loops which have to be fixed.
Most notably are the dep loops of _autorebase and _update-info-dir,
which we'll fix ASAP.
GConf2 -> libgconf2_4 -> gconf-desktop-schemas -> GConf2
xf86-video-dummy -> xorg-server -> xf86-video-dummy
xf86-video-nested -> xorg-server -> xf86-video-nested
texlive -> texlive-collection-basic -> texlive
libautotrace3 -> libMagickCore5 -> libautotrace3
libgeoclue0 -> geoclue -> libgeoclue0
shared-mime-info -> libglib2.0_0 -> shared-mime-info
libatspi0 -> at-spi2-core -> libatspi0
libfam0 -> gamin -> libglib2.0_0 -> libfam0
gsettings-desktop-schemas -> libglib2.0_0 -> gsettings-desktop-schemas
libdbus1_3 -> dbus -> libdbus1_3
php-Archive_Tar -> php-PEAR -> php-Archive_Tar
autogen -> libopts-devel -> autogen
python-libxslt -> python-libxml2 -> python-libxslt
libopenldap2_4_2 -> libsasl2_3 -> libopenldap2_4_2
perl-Mozilla-CA -> perl-IO-Socket-SSL -> perl-Mozilla-CA
rubygems -> ruby-io-console -> ruby -> rubygems
ruby-rake -> rubygems -> ruby-rake
ruby-rdoc -> rubygems -> ruby-rdoc
ruby-rdoc -> rubygems -> ruby-io-console -> ruby -> ruby-rdoc
mingw64-i686-runtime -> mingw64-i686-gcc-core -> mingw64-i686-runtime
mingw64-x86_64-runtime -> mingw64-x86_64-gcc-core -> mingw64-x86_64-runtime
_autorebase -> rebase -> sed -> libintl8 -> libiconv2 -> libgcc1 ->
_autorebase
_autorebase -> rebase -> coreutils -> libgmp10 -> _autorebase
tesseract-ocr-eng -> tesseract-ocr -> tesseract-ocr-eng
openmpi -> libopenmpi -> openmpi
_autorebase -> rebase -> grep -> libpcre1 -> _autorebase
_autorebase -> rebase -> grep -> bash -> libreadline7 -> libncursesw10 ->
libstdc++6 -> _autorebase
_update-info-dir -> bash -> _update-info-dir
_update-info-dir -> bash -> coreutils -> _update-info-dir
_update-info-dir -> info -> _update-info-dir
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpfhw4MAZA3B.pgp
Description: PGP signature
Re: [REQUEST] Please upgrade irssi (0.8.17)
Updated, but missing cygperl5_14.dll. + ls -l /usr/bin/irssi.exe -rwxr-xr-x 1 kchris Domain Users 1180701 Nov 12 10:47 /usr/bin/irssi.exe + irssi -version /usr/bin/irssi.exe: error while loading shared libraries: cygperl5_14.dll: cannot open shared object file: No such file or directory + echo + locate -i '*cygperl5_14.dll*' On Thu, Nov 13, 2014 at 4:39 AM, Marco Atzeri wrote: > On 11/12/2014 10:14 PM, Keith Christian wrote: >> >> Perhaps it hasn't propagated to the osuosl server yet. Should I click >> the EXP radio button in Setup and cycle through >> Keep...Reinstall...Src... etc. to see the new version? >> > > correct, EXP button. > You should not need to cycle through, 0.8.17 will be offered > as new update > > > Regards > Marco > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [REQUEST] Please upgrade irssi (0.8.17)
On 11/13/2014 3:44 PM, Keith Christian wrote: Updated, but missing cygperl5_14.dll. + ls -l /usr/bin/irssi.exe -rwxr-xr-x 1 kchris Domain Users 1180701 Nov 12 10:47 /usr/bin/irssi.exe + irssi -version /usr/bin/irssi.exe: error while loading shared libraries: cygperl5_14.dll: cannot open shared object file: No such file or directory + echo + locate -i '*cygperl5_14.dll*' Strange irssi requires perl where cygperl5_14.dll is on 64 bit $ cygcheck -f $(which cygperl5_14.dll) perl-5.14.4-1 on 32bit $ cygcheck -f $(which cygperl5_14.dll) perl-5.14.2-3 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [REQUEST] Please upgrade irssi (0.8.17)
I get a cygcheck usage error for both of those commands. On Thu, Nov 13, 2014 at 7:52 AM, Marco Atzeri wrote: > On 11/13/2014 3:44 PM, Keith Christian wrote: >> >> Updated, but missing cygperl5_14.dll. >> >> + ls -l /usr/bin/irssi.exe >> -rwxr-xr-x 1 kchris Domain Users 1180701 Nov 12 10:47 >> /usr/bin/irssi.exe >> + irssi -version >> /usr/bin/irssi.exe: error while loading shared libraries: >> cygperl5_14.dll: cannot open shared object file: No such file or >> directory >> + echo >> >> + locate -i '*cygperl5_14.dll*' > > > Strange > > irssi requires perl where cygperl5_14.dll is > > on 64 bit > $ cygcheck -f $(which cygperl5_14.dll) > perl-5.14.4-1 > > on 32bit > $ cygcheck -f $(which cygperl5_14.dll) > perl-5.14.2-3 > > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
gfortran netcdf version mismatch
Hi, Trying to compile using gfortran and netcdf I get: Fatal Error: Cannot read module file 'netcdf.mod' opened at (1), because it was created by a different version of GNU Fortran Might be the cygwin netcdf needs be rebuilt with current gfortran? (CYGWIN_NT-6.1-WOW64 xxx 1.7.32(0.274/5/3) 2014-08-13 23:03 i686 Cygwin) Regards, Brendan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup 2.774 texlive postinstall takes 10+ hours)
On 11/13/2014 9:18 AM, Corinna Vinschen wrote:
On Nov 11 12:53, Corinna Vinschen wrote:
On Nov 10 22:33, Yaakov Selkowitz wrote:
On 2014-11-10 22:23, Yaakov Selkowitz wrote:
Dependency order of packages: libgcc1 base-cygwin cygwin dash tzcode
libstdc++6 terminfo sed gzip libpcre1 grep libreadline7 bash
libncursesw10
[snip]
Now that I think about it, regardless of libgcc1, that still doesn't make
much sense. sed, grep, and bash depend on libintl8, which depends on
libiconv2, and libreadline7 (which is required by bash) itself depends on
libncursesw10, so that should be at least two places earlier. All of those
dependencies are listed in setup.hint (and hence setup.ini), so is there
something wrong with setup itself?
What about dependency loops?
AFAICS, coreutils depends on tzcode, tzcode depends on coreutils. Both
depend on libgcc1. This introduces a big problem in dependency
resolution because there's no unambiguous starting point.
What if we remove the coretuls dep from tzcode.
Or, actually, what if we make sure that Base packages only depend
on libs, but never on any other Base package?
Ok, now after a collegue of mine informed me about the existence of
tsort (*blush*), I could finally produce some more info about loops
in our dependencies. I wrote a simple script:
awk '/^@ /{ left=$2; }
/^requires: /{ for (i=2; i<=NF; ++i) print left " " $i; }
' < setup.ini | tsort
It found the following dependency loops which have to be fixed.
Most notably are the dep loops of _autorebase and _update-info-dir,
which we'll fix ASAP.
GConf2 -> libgconf2_4 -> gconf-desktop-schemas -> GConf2
xf86-video-dummy -> xorg-server -> xf86-video-dummy
xf86-video-nested -> xorg-server -> xf86-video-nested
texlive -> texlive-collection-basic -> texlive
libautotrace3 -> libMagickCore5 -> libautotrace3
libgeoclue0 -> geoclue -> libgeoclue0
shared-mime-info -> libglib2.0_0 -> shared-mime-info
libatspi0 -> at-spi2-core -> libatspi0
libfam0 -> gamin -> libglib2.0_0 -> libfam0
gsettings-desktop-schemas -> libglib2.0_0 -> gsettings-desktop-schemas
libdbus1_3 -> dbus -> libdbus1_3
php-Archive_Tar -> php-PEAR -> php-Archive_Tar
autogen -> libopts-devel -> autogen
python-libxslt -> python-libxml2 -> python-libxslt
libopenldap2_4_2 -> libsasl2_3 -> libopenldap2_4_2
perl-Mozilla-CA -> perl-IO-Socket-SSL -> perl-Mozilla-CA
rubygems -> ruby-io-console -> ruby -> rubygems
ruby-rake -> rubygems -> ruby-rake
ruby-rdoc -> rubygems -> ruby-rdoc
ruby-rdoc -> rubygems -> ruby-io-console -> ruby -> ruby-rdoc
mingw64-i686-runtime -> mingw64-i686-gcc-core -> mingw64-i686-runtime
mingw64-x86_64-runtime -> mingw64-x86_64-gcc-core -> mingw64-x86_64-runtime
_autorebase -> rebase -> sed -> libintl8 -> libiconv2 -> libgcc1 ->
_autorebase
_autorebase -> rebase -> coreutils -> libgmp10 -> _autorebase
tesseract-ocr-eng -> tesseract-ocr -> tesseract-ocr-eng
openmpi -> libopenmpi -> openmpi
_autorebase -> rebase -> grep -> libpcre1 -> _autorebase
_autorebase -> rebase -> grep -> bash -> libreadline7 -> libncursesw10 ->
libstdc++6 -> _autorebase
_update-info-dir -> bash -> _update-info-dir
_update-info-dir -> bash -> coreutils -> _update-info-dir
_update-info-dir -> info -> _update-info-dir
Many of the dependency loops are harmless. If two packages A and B are
involved in a loop, and if they both provide postinstall scripts, then
you can't be sure which script will run first. So we only have to worry
about those loops in which the order is important.
The real problem here is that the "requires" line in setup.ini is being
used for two unrelated purposes. The first one is to make sure that if
package A requires package B in order to run properly, and if A is
chosen for install, then so is B. For this purpose, loops are not only
harmless, they're sometimes necessary. For example, the dependency loop
between texlive and texlive-collection-basic is completely appropriate.
How else can we make sure that if one is chosen, then so is the other?
The second purpose is to determine the order of running postinstall
scripts, and this is where loops are bad. We need to rethink how
postinstall order is determined. What about just adding a provision for
specifying postinstall dependencies, independent of the current
"requires" line? We've already discussed a couple of situations where
this would be useful:
* base-cygwin needs to run first;
* autorebase should be run as early as possible.
A third one concerns texlive. I could greatly speed up the texlive
postinstall scripts if I had a package (maybe called "_texlive_post")
that provided a script to be run after all other texlive scripts.
There's one final idea I'd like to throw out, possibly as an alternative
to Achim's perpetual postinstall scripts: It would be useful to be able
to specify that a certain package (such as _autorebase, or my p
Re: gfortran netcdf version mismatch
On 11/13/2014 4:35 PM, DeTracey, Brendan wrote: Hi, Trying to compile using gfortran and netcdf I get: Fatal Error: Cannot read module file 'netcdf.mod' opened at (1), because it was created by a different version of GNU Fortran Might be the cygwin netcdf needs be rebuilt with current gfortran? (CYGWIN_NT-6.1-WOW64 xxx 1.7.32(0.274/5/3) 2014-08-13 23:03 i686 Cygwin) Regards, Brendan I will rebuild/upgrade netcdf-fortran it should be enough Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup 2.774 texlive postinstall takes 10+ hours)
On Nov 13 10:46, Ken Brown wrote:
> On 11/13/2014 9:18 AM, Corinna Vinschen wrote:
> >Ok, now after a collegue of mine informed me about the existence of
> >tsort (*blush*), I could finally produce some more info about loops
> >in our dependencies. I wrote a simple script:
> >
> >awk '/^@ /{ left=$2; }
> > /^requires: /{ for (i=2; i<=NF; ++i) print left " " $i; }
> > ' < setup.ini | tsort
> >
> >It found the following dependency loops which have to be fixed.
> >Most notably are the dep loops of _autorebase and _update-info-dir,
> >which we'll fix ASAP.
> >
> > GConf2 -> libgconf2_4 -> gconf-desktop-schemas -> GConf2
> >
> > xf86-video-dummy -> xorg-server -> xf86-video-dummy
> >
> > xf86-video-nested -> xorg-server -> xf86-video-nested
> >
> > texlive -> texlive-collection-basic -> texlive
> >
> > libautotrace3 -> libMagickCore5 -> libautotrace3
> >
> > libgeoclue0 -> geoclue -> libgeoclue0
> >
> > shared-mime-info -> libglib2.0_0 -> shared-mime-info
> >
> > libatspi0 -> at-spi2-core -> libatspi0
> >
> > libfam0 -> gamin -> libglib2.0_0 -> libfam0
> >
> > gsettings-desktop-schemas -> libglib2.0_0 -> gsettings-desktop-schemas
> >
> > libdbus1_3 -> dbus -> libdbus1_3
> >
> > php-Archive_Tar -> php-PEAR -> php-Archive_Tar
> >
> > autogen -> libopts-devel -> autogen
> >
> > python-libxslt -> python-libxml2 -> python-libxslt
> >
> > libopenldap2_4_2 -> libsasl2_3 -> libopenldap2_4_2
> >
> > perl-Mozilla-CA -> perl-IO-Socket-SSL -> perl-Mozilla-CA
> >
> > rubygems -> ruby-io-console -> ruby -> rubygems
> >
> > ruby-rake -> rubygems -> ruby-rake
> >
> > ruby-rdoc -> rubygems -> ruby-rdoc
> >
> > ruby-rdoc -> rubygems -> ruby-io-console -> ruby -> ruby-rdoc
> >
> > mingw64-i686-runtime -> mingw64-i686-gcc-core -> mingw64-i686-runtime
> >
> > mingw64-x86_64-runtime -> mingw64-x86_64-gcc-core ->
> > mingw64-x86_64-runtime
> >
> > tesseract-ocr-eng -> tesseract-ocr -> tesseract-ocr-eng
> >
> > openmpi -> libopenmpi -> openmpi
> >
Update: All loops concerning _autorebase and _update-info-dir are
gone now. This should help a lot.
> Many of the dependency loops are harmless. If two packages A and B are
> involved in a loop, and if they both provide postinstall scripts, then you
> can't be sure which script will run first. So we only have to worry about
> those loops in which the order is important.
Right, but the maintainer should certainly have a look.
> The real problem here is that the "requires" line in setup.ini is being used
> for two unrelated purposes. The first one is to make sure that if package A
> requires package B in order to run properly, and if A is chosen for install,
> then so is B. For this purpose, loops are not only harmless, they're
> sometimes necessary. For example, the dependency loop between texlive and
> texlive-collection-basic is completely appropriate. How else can we make
> sure that if one is chosen, then so is the other?
In theory one could argue that the package split is not in the best
interest of things...
> The second purpose is to determine the order of running postinstall scripts,
> and this is where loops are bad. We need to rethink how postinstall order
> is determined. What about just adding a provision for specifying
> postinstall dependencies, independent of the current "requires" line?
This needs support by the upset perl script as well as Setup. It
would sure be nice, but *basically* the requires also defines an
order of postinstall scripts. If no dangerous loops occur. For
the time being we should probably run my tiny awk|tsort script once
a week or so :}
> We've
> already discussed a couple of situations where this would be useful:
>
> * base-cygwin needs to run first;
> * autorebase should be run as early as possible.
Right. This *should* be taken care of by the dependency order. There
was a really bad bug in setup.ini. Originally the _autobase package
depended on rebase, bash and cygwin. Despite removing the requires:
line from _autobase'es setup.hint file, setup.ini still kept this
line in all the time :-P
I added an empty "requires:" line to _autobase/setup.hint, and the new
setup.ini does not contain these old requirements anymore.
What we really need short-term is some perl guru fixing upset. Is
anybody feeling up to the task?
> A third one concerns texlive. I could greatly speed up the texlive
> postinstall scripts if I had a package (maybe called "_texlive_post") that
> provided a script to be run after all other texlive scripts.
>
> There's one final idea I'd like to throw out, possibly as an alternative to
> Achim's perpetual postinstall scripts: It would be useful to be able to
> specify that a certain package (such as _autorebase, or my proposed
> _texlive_post) should always be selected for *reinstall* whenever a package
> that depends on it is installed.
>
> Ken
>
> P.S. If there is support for any of my suggestions, I'll do all I can to
> help with the implementati
[ANNOUNCEMENT] Updated: Cygwin 1.7.33-1
Hi Cygwin friends and users, I just released Cygwin 1.7.33-1. This release comes with a bunch of changes and bugfixes collected since 1.7.32-1. It does NOT come with the account handling changes originally planned for 1.7.33 since there are still a couple of problems to solve before this can be officially released. These changes will hopefully make it into 1.7.34. Here's the list of changes for 1.7.33-1: What's new: --- - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix. This can be utilized in scripts to access paths via cygdrive prefix, even if the cygdrive prefix has been changed by the user. - /proc/partitions now prints the windows mount points the device is mounted on. This allows to recognize the underlying Windows devices of the Cygwin raw device names. - New API: quotactl, designed after the Linux/BSD function, but severely restricted: Windows only supports user block quotas on NTFS, no group quotas, no inode quotas, no time constraints. - New APIs: ffsl, ffsll (glibc extensions). - New API: stime (SVr4). What changed: - - New internal exception handling based on SEH on 64 bit Cygwin. - When exec'ing applications, check if $PATH exists and is non-empty. If not, add PATH variable with Cygwin installation directory as content to Windows environment to allow loading of Cygwin system DLLs. - Disable CYGWIN "dosfilewarning" option by default. - Improve various header files for C++- and standards-compliance. - Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6. - atexit is now exported as statically linked function from libcygwin.a. This allows reliable access to the DSO handle of the caller for newly built executables. The former atexit entry point into the DLL remains for backward compatibility only. Bug Fixes - - Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid directory stream. - Fix a resource leak in rmdir(2). - Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after open and before calling one of the affected functions. Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html - Handle Netapp-specific problem in statvfs(2)/fstatvfs(2). Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html - Fix chown(2) on ptys in a corner case. - Generate correct error when a path is inaccessible due to missing permissions. Addresses: https://cygwin.com/ml/cygwin-developers/2014-10/msg00010.html - Don't hang in accept calls if socket is no listener. Set errno to EINVAL instead. - Don't allow seeking on serial lines and sockets. Set errno to ESPIPE instead. Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00319.html - Fix output of /proc//statm. - Fix a SEGV in cygcheck if the environment variable COMSPEC is not, or incorrectly set. Addresses: https://cygwin.com/ml/cygwin/2014-10/msg00292.html - Fix a SEGV in some 64 bit applications explicitely dlclosing DLLs. Addresses: https://cygwin.com/ml/cygwin/2014-10/msg00402.html - Fix -fuse-cxa-atexit handling where dlclose fails to trigger calling global dtors in dynamically loaded modules in C++ applications (and thus another potential SEGV). To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe If you're already running a 32 bit version of Cygwin on 64 bit Windows machines, you can continue to do so. If you're planning a new install of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit Cygwin version, unless you need certain packages not yet available in the 64 bit release. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-001
Hi Cygwin friends and users,
I just released another TEST version of the next upcoming Cygwin release,
now called 1.7.34-001. Nothing much has changed compared to the former
test release 1.7.33-0.8. The new subversion number 001 is used because
the dot in the number seem to make problems in the Setup installer.
If you want to help testing this new release (which I seriously hope
for), you can find it in your setup-x86.exe or setup-x86_64.exe as
"test" release.
The major change in this new release is the new method to read account
(passwd and group) information from the Windows user databases directly,
without the requirement to generate /etc/passwd and /etc/group files to
generate Unix-like uid and gid.
For your convenience I wrote new documentation. Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at
https://cygwin.com/preliminary-ntsec.html
If you read it
(which I seriously hope for) and it's all just incomprehensible
gobbledygook to you, please say so on the mailing list
cygwin AT cygwin DOT com
so we have a chance to improve the documentation.
Please give this TEST release a try.
If you find problems in the new features or regressions compared to the
current stable release 1.7.33, please report them to the public mailing
list
cygwin AT cygwin DOT com
Following is a list of changes in this new release:
What's new:
---
- Cygwin can now generate passwd/group entries directly from Windows
user databases (local SAM or Active Directory), thus allowing to run
Cygwin without having to create /etc/passwd and /etc/group files.
Introduce /etc/nsswitch.conf file to configure passwd/group handling.
For bordercase which require to use /etc/passwd and /etc/group files,
change mkpasswd/mkgroup to generate passwd/group entries compatible
with the entries read from SAM/AD.
- Add -b/--remove-all option to setfacl to reduce the ACL to only the
entries representing POSIX permission bits.
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
What changed:
-
- Revamp Solaris ACL implementation to more closely work like POSIX ACLs
are supposed to work. Finally implement a CLASS_OBJ emulation. Update
getfacl(1)/setfacl(1) accordingly.
- The xdr functions are no longer exported for newly built executables.
Use libtirpc-devel instead.
To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe
If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so. If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet available in
the 64 bit release.
Have fun,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.33-1
On 11/13/2014 11:37 AM, Corinna Vinschen wrote: Hi Cygwin friends and users, I just released Cygwin 1.7.33-1. This release comes with a bunch of changes and bugfixes collected since 1.7.32-1. It does NOT come with the account handling changes originally planned for 1.7.33 since there are still a couple of problems to solve before this can be officially released. These changes will hopefully make it into 1.7.34. Here's the list of changes for 1.7.33-1: What's new: --- - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix. This can be utilized in scripts to access paths via cygdrive prefix, even if the cygdrive prefix has been changed by the user. - /proc/partitions now prints the windows mount points the device is mounted on. This allows to recognize the underlying Windows devices of the Cygwin raw device names. - New API: quotactl, designed after the Linux/BSD function, but severely restricted: Windows only supports user block quotas on NTFS, no group quotas, no inode quotas, no time constraints. - New APIs: ffsl, ffsll (glibc extensions). - New API: stime (SVr4). What changed: - - New internal exception handling based on SEH on 64 bit Cygwin. - When exec'ing applications, check if $PATH exists and is non-empty. If not, add PATH variable with Cygwin installation directory as content to Windows environment to allow loading of Cygwin system DLLs. - Disable CYGWIN "dosfilewarning" option by default. - Improve various header files for C++- and standards-compliance. - Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6. - atexit is now exported as statically linked function from libcygwin.a. This allows reliable access to the DSO handle of the caller for newly built executables. The former atexit entry point into the DLL remains for backward compatibility only. Bug Fixes - - Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid directory stream. - Fix a resource leak in rmdir(2). - Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after open and before calling one of the affected functions. Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html - Handle Netapp-specific problem in statvfs(2)/fstatvfs(2). Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html - Fix chown(2) on ptys in a corner case. - Generate correct error when a path is inaccessible due to missing permissions. Addresses: https://cygwin.com/ml/cygwin-developers/2014-10/msg00010.html - Don't hang in accept calls if socket is no listener. Set errno to EINVAL instead. - Don't allow seeking on serial lines and sockets. Set errno to ESPIPE instead. Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00319.html - Fix output of /proc//statm. - Fix a SEGV in cygcheck if the environment variable COMSPEC is not, or incorrectly set. Addresses: https://cygwin.com/ml/cygwin/2014-10/msg00292.html - Fix a SEGV in some 64 bit applications explicitely dlclosing DLLs. Addresses: https://cygwin.com/ml/cygwin/2014-10/msg00402.html - Fix -fuse-cxa-atexit handling where dlclose fails to trigger calling global dtors in dynamically loaded modules in C++ applications (and thus another potential SEGV). You forgot to mention the signal-handling bug that was causing corruption of the flags register. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.33-1
On Nov 13 12:16, Ken Brown wrote: > On 11/13/2014 11:37 AM, Corinna Vinschen wrote: > >Hi Cygwin friends and users, > > > > > >I just released Cygwin 1.7.33-1. > >[...] > You forgot to mention the signal-handling bug that was causing corruption of > the flags register. Right, sorry! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSNCmyX1c9c.pgp Description: PGP signature
Re: cygwin setup program questions
just to check my understanding of the setup program, latest version 2.852 (64 bit); the options are install / re-install / un-install / default my understanding is as follows; choosing "install" creates a new installation of the selected cygwin components choosing "re-install" uninstalls the selected cygwin components, then creates a new installation choosing "un-install" uninstalls the selected cygwin components choosing "default" updates the selected cygwin components so if I wish to update my local installation to the latest release, I would choose "default", as per the following screen capture; http://www.cpm86.com/default.jpg the "keep" / "cur" / "exp" radio buttons; changes what the "Default" means: keep the installed packages, update to whatever the current version is or update to whatever the "experimental" or test version is. (thanks Achim) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: zlib-1.2.8-2 breaks clamav
On 11/7/14 5:19 AM, Mike Bonnet wrote: On 11/06/2014 11:40 AM, Marco Atzeri wrote: On 11/6/2014 4:35 PM, Mike Bonnet wrote: On 11/01/2014 08:31 PM, Mike Bonnet wrote: Hi. I just found out that the zlib-1.2.8-2 breaks clamav. A log of the output of the "sigtool" commmand from clamav is attached. It's using gzread() to read the compressed signature databases, and the format of the data returned has apparently changed between zlib 1.2.8-1 and 1.2.8-2. This should be fixed ASAP. Who would I talk to about getting this fixed? Thanks, Mike This is the place. The zlib package maintainer follow the mailing list. Have you tested if reinstalling previous zlib-1.2.8-1 restore the expected behaviour ? Yes, downgrading to zlib-1.2.8-1 fixes the issues with clamav. Any update on this? The broken -2 version is still the latest. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup 2.774 texlive postinstall takes 10+ hours
Corinna Vinschen writes: > No? … in the sense of something almost, but not quite entirely unlike _autorebase. > From what I read here your _incautorebase would replace _autorebase > just fine. I'm not concerned about an exact replacement for the > rebaseall script. The idea would be to make _incautorebase into > drop-in replacement for _autorebase and throw away my _autorebase > stuff. Rebaseall would stay, it's part of the rebase package anyway. Correct. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.33-1
On 2014-11-13 17:37, Corinna Vinschen wrote: > > I just released Cygwin 1.7.33-1. Just to report that 'uname -a' (and also /proc/version) shows 1.7.33-2 for this one. Denis Excoffier. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.33-1
On Nov 13 20:42, Denis Excoffier wrote: > On 2014-11-13 17:37, Corinna Vinschen wrote: > > > > I just released Cygwin 1.7.33-1. > > Just to report that 'uname -a' (and also /proc/version) shows 1.7.33-2 for > this one. Oh, darn. This was a definitive copy/paste bug, just using rsync. Is that much of a problem? Otherwise I'd just keep it at that for now... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpiI6p1_qIc0.pgp Description: PGP signature
Re: Setup 2.774 texlive postinstall takes 10+ hours)
Ken Brown writes: > There's one final idea I'd like to throw out, possibly as an > alternative to Achim's perpetual postinstall scripts: It would be > useful to be able to specify that a certain package (such as > _autorebase, or my proposed _texlive_post) should always be selected > for *reinstall* whenever a package that depends on it is installed. That's roughly equivalent to what Debian calls postinstall triggers. Yes, these would be useful, but it requires some infrastructure in upset/genini and setup.exe that's simply not there yet. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Accessing a "Test" release
binQfwD7Q09Pa.bin Description: PGP/MIME version identification encrypted.asc Description: OpenPGP encrypted message
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13, 2014, at 2:33 AM, Corinna Vinschen wrote: > On Nov 12 17:19, Warren Young wrote: >> >> I’m not advocating that step so early, but maybe if this breakup does >> happen, a few years later setup.exe can start applying some strong >> ACLs to files it writes. > > ??? What "strong" ACLs? The ones that are not there right now. :) Just to pick a random example: $ ls -l /bin/ls.exe -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe The same file’s permissions, from Windows’ perspective: http://etr-usa.com/cygwin/ls-perms.png So, just because I installed Cygwin with my regular user account, I get permission to rewrite ls.exe. This is not a good thing, if our goal is to make Cygwin work like Linux while working *within* the Windows environment. IMHO, the way to meet both goals simultaneously is to put programs in c:\Program Files, and to give full-control perms to the local Administrator account in the SAM case, or possibly the domain one in the AD case. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Accessing a "Test" release
Whoops. Last message was encrypted. My bad. I'm interested in running the 1.7.34-001 test release. In the announcements it says: "...you can find it in your setup-x86.exe or setup-x86_64.exe as "test" release." "In" the setup? I've run the setup-x86_64.exe and don't see anywhere to choose a test release including the pane for "choose a download site". Where do I find the option? Thanks DJ signature.asc Description: OpenPGP digital signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 14:09, Warren Young wrote: > On Nov 13, 2014, at 2:33 AM, Corinna Vinschen > wrote: > > > On Nov 12 17:19, Warren Young wrote: > >> > >> I’m not advocating that step so early, but maybe if this breakup does > >> happen, a few years later setup.exe can start applying some strong > >> ACLs to files it writes. > > > > ??? What "strong" ACLs? > > The ones that are not there right now. :) > > Just to pick a random example: > > $ ls -l /bin/ls.exe > -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe > > The same file’s permissions, from Windows’ perspective: > > http://etr-usa.com/cygwin/ls-perms.png icacls output would be more helpful than a picture. However, this isn't really a problem. The group permissions are apparently faked by Cygwin, they don't reflect the reality. I just don't remember why this is done, it's probably old. Have to check... > So, just because I installed Cygwin with my regular user account, I > get permission to rewrite ls.exe. This is not a good thing, if our > goal is to make Cygwin work like Linux while working *within* the > Windows environment. > IMHO, the way to meet both goals simultaneously is to put programs in > c:\Program Files, No, sorry, but no. We're certainly not going to turn everything upside down installation-wise. If you want Cygwin installed into Program Files, just change it in the GUI. > and to give full-control perms to the local > Administrator account in the SAM case, or possibly the domain one in > the AD case. BTDT. The code is still in Setup, just doesn't run anymore. The idea was to install with user and group set to Administator/ Administrators, but we had some complaints and the code got deactivated. We can reactivate the Administrators group, but that still requires to run Setup elevated. It doesn't work when running under a non-admin account. However, the *other* idea is that if you install with an elevated Setup, your account is an admin account anyway. Ideally when you install Cygwin for multiple users, you're using an account you're not using for daily usage. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpUScr7NJVhJ.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13, 2014, at 2:55 AM, Corinna Vinschen wrote: > On Nov 12 11:00, Warren Young wrote: >> >> I propose that this or something like it be added to the default >> fstab. > > No. This would even break Setup right now. I’m guessing this is because setup.exe doesn’t know what to do with a redirected /var and /usr/local on the first install, when /etc/fstab doesn’t exist yet? I assume setup.exe does obey /etc/fstab on subsequent installs. If not, I can see that this will break the installation of any package that puts files in either location. I don’t see that the */tmp changes would bother setup.exe. None of these problems seem difficult. Doesn’t setup.exe write the initial /etc/fstab, and so is in a position to know what it will contain on first install? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13, 2014, at 2:30 PM, Corinna Vinschen wrote: > On Nov 13 14:09, Warren Young wrote: >> >> http://etr-usa.com/cygwin/ls-perms.png > > icacls output would be more helpful than a picture. $ icacls ls.exe ls.exe MOSSYMAZE\Warren:(F) MOSSYMAZE\Warren:(RX) Everyone:(RX) > It doesn't work when running under a non-admin account. Every other Windows setup program is playing by that same restriction. > However, the *other* idea is that if you install with an elevated Setup, > your account is an admin account anyway. Ideally when you install > Cygwin for multiple users, you're using an account you're not using for > daily usage. Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the installing user? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! > On Nov 12 23:23, Andrey Repin wrote: >> > So the Cygwin home dir >> > is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%, >> >> Which is covered by "system" setting. Which will either read the location >> from >> AD or use %HOMEPATH%, if all else fails. >> >> > not %HOMEPATH%/AppData/Roaming/CMD. >> >> I don't see, why not. Forget for a moment about its true location. >> Does it matter, where the files are located, when cygwin is running? > Not when it's running, but a homedir does *not* belong under AppData, > especially not under Roaming. Perhaps, I'm missing something. What meaning exactly you put into "homedir", which seems to preclude any possibility of discussion? -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <00:47> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! >> > 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). >> > 2. If homeDirectory is empty, fall back to /home/$USER. >> >> This is just a subset of what I suggested, so I’m in favor of it. >> (By subset I mean that I’d prefer you do essentially the same thing for the >> non-AD case, too.) > This would be most easily implemented as well. > The beauty here is that probably 99% of the home users don't set > HOMEDRIVE/HOMEPATH in their SAM. They are always set by default. > So they get /home/$USER as fallback, No. > which is what they got with /etc/passwd as well. And SAM users have the > XML-like description field entry as well. > For AD environments HOMEDRIVE/HOMEPATH are typically set, though. HOMEDRIVE/HOMEPATH always set. > Here the users get what they have to use as homedir anyway. > It's simple, but it should work OOTB for most people. Yes, it'll work. Just not as you expect it. >> > 1. Always use /home/$USER and let the admins come up with a matching >> > mount point scheme. >> >> That’s neglecting your responsibility as BDFL to set a sensible > Heh. I didn't see myself as BDFL yet. Not sure if that's an honor. That's a chore. But someone has to pull it. >> default. The consequence is that everyone will do it differently, and >> then you’ll have to support everything on an equal basis, because you >> chose not to endorse anything. >> >> When you choose a sensible default, you get the option to criticize >> and even deprecate wild alternative schemes. > This is a philosophical argument. You'd have to argue in how far > always using /home/$USER is NOT a sensible default. I can give you a whole list of reason, including quotes from Cygwin documentation, why this is not a good idea. And "cygwin is not an operating system" will be a red canvas through them. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <00:49> Sorry for my terrible english...
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 22:30, Corinna Vinschen wrote: > On Nov 13 14:09, Warren Young wrote: > > On Nov 13, 2014, at 2:33 AM, Corinna Vinschen > > wrote: > > > > > On Nov 12 17:19, Warren Young wrote: > > >> > > >> I’m not advocating that step so early, but maybe if this breakup does > > >> happen, a few years later setup.exe can start applying some strong > > >> ACLs to files it writes. > > > > > > ??? What "strong" ACLs? > > > > The ones that are not there right now. :) > > > > Just to pick a random example: > > > > $ ls -l /bin/ls.exe > > -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe > > > > The same file’s permissions, from Windows’ perspective: > > > > http://etr-usa.com/cygwin/ls-perms.png > > icacls output would be more helpful than a picture. > > However, this isn't really a problem. The group permissions are > apparently faked by Cygwin, they don't reflect the reality. I just > don't remember why this is done, it's probably old. Have to check... Btw., I never saw this happen. Did you install for "just you", or in a non-elevated Setup? In my case the permissions make at least sense, even if my own account still has full access: $ ls -l /bin/ls.exe -rwxr-xr-x 1 corinna vinschen 116253 Oct 13 18:12 /bin/ls.exe Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpouBUUItxDj.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 14:39, Warren Young wrote: > On Nov 13, 2014, at 2:30 PM, Corinna Vinschen > wrote: > > > On Nov 13 14:09, Warren Young wrote: > >> > >> http://etr-usa.com/cygwin/ls-perms.png > > > > icacls output would be more helpful than a picture. > > $ icacls ls.exe > ls.exe MOSSYMAZE\Warren:(F) >MOSSYMAZE\Warren:(RX) >Everyone:(RX) > > > It doesn't work when running under a non-admin account. > > Every other Windows setup program is playing by that same restriction. Setup tries to install with (explicit) POSIX permissions, not with (inherited) Windows permissions. It's not quite the same thing. > > However, the *other* idea is that if you install with an elevated Setup, > > your account is an admin account anyway. Ideally when you install > > Cygwin for multiple users, you're using an account you're not using for > > daily usage. > > Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the > installing user? In a corporate model this might make sense, but for the home user? I'm not so sure about SYSTEM, though. Administrator/Administrators sounds right to me. SYSTEM? Hmm. As I said, at one point back in the early 1.7 days setup did something like that, but we got complaints. I don't remember the details. But if we do something like that again, it should be configurable. Maybe the "Just Me"/"All users" choice is sufficient if explained sufficiently in the GUI? Also, who's going to do that? The coding part, I mean. Lots of what's required is already in setup, but I can't write it often enough (it's an obsession probably): I would be very glad for developers not shy making their hands dirty. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp5uYM3TRCbt.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13, 2014, at 3:09 PM, Corinna Vinschen wrote: > Did you install for "just you", I just made a fresh install into c:\zz, accepting all the defaults in setup.exe, so it installed for everyone. I got the same result as my preexisting install. Perhaps this is helpful: $ id uid=1000(Warren) gid=513(None) groups=513(None),559(Performance Log Users),545(Users) Apparently I am a member of both None and Users, whatever that means. > or in a non-elevated Setup? I did these tests on a Windows 10 technical preview VM with UAC left in its default setting. I did get the blue and yellow UAC dimmed desktop dialog when running setup.exe, so I assume it managed to elevate itself. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 14:30, Warren Young wrote: > On Nov 13, 2014, at 2:55 AM, Corinna Vinschen > wrote: > > > On Nov 12 11:00, Warren Young wrote: > >> > >> I propose that this or something like it be added to the default > >> fstab. > > > > No. This would even break Setup right now. > > I’m guessing this is because setup.exe doesn’t know what to do with a > redirected /var and /usr/local on the first install, when /etc/fstab > doesn’t exist yet? > > I assume setup.exe does obey /etc/fstab on subsequent installs. If > not, I can see that this will break the installation of any package > that puts files in either location. > > I don’t see that the */tmp changes would bother setup.exe. > > None of these problems seem difficult. Doesn’t setup.exe write the > initial /etc/fstab, and so is in a position to know what it will > contain on first install? Perhaps, but I don't want to make such changes short-term, and I don't want to enforce such a big change in directory layout. This has to be made configurable in the GUI. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpP1YS7fnVuN.pgp Description: PGP signature
Re: Can't Run Excel From A Cron Job Under Windows 7
Greetings, Kertz, Denis (D)** CTR **! >>> What I mean by runs fine is that when I type this command at a bash prompt: >>> run.excel 'c:\Shared\Bin\Create_Daily_Scorecard.xls' >>> it runs to completion and creates a new .xls as its output. When I run >>> this run.excel script from a cron job it hangs. >> >> Hangs as in - do not create new file? > Hangs as in never finishes and I don't know what, if anything, it has done. > But that suggests some tests for me to run that I should have thought of. > First, create a test .xls that does nothing and see if that runs to > completion. If it does, then create a test .xls that simply creates a file > to test whether it actually creates the file. :) >>> I'm not trying to run Excel interactively from a cron job. One of the >>> limitations with using Excel from a cron job is Excel has to run error free. >>> If Excel does run into some error it will typically generate an error >>> message and wait for a user response. Since Excel is running invisibly from >>> a cron job, there is no user to give a response and Excel just sits there >>> waiting for a response that will never come. >> >> Try starting cron in terminal session and see if anything comes up. > Can you tell me how to do this? When I run the ps command in a terminal > session, I see this: > $ ps > PIDPPIDPGID WINPID TTY UIDSTIME COMMAND > 578055685780 3408 pty01000 Nov 5 /usr/bin/bash > 5568 15568 5568 ? 1000 Nov 5 /usr/bin/mintty > 371657803716 1016 pty01000 18:58:16 /usr/bin/ps > 1820 11820 1820 ? 1000 Nov 5 /usr/bin/cygrunsrv > 185618201856 1892 ? 1000 Nov 5 /usr/sbin/cron > Do I have to kill the cygrunsrv and cron processes and then ?? Stop (don't kill! Everyone, who use -KILL, must be -KILL'ed) the cron service, then start cron in terminal, using `runas /user:... ...'. So it would run under proper user, and see if anything come up, when it execute your excel job. >>> Why "of course"? Shouldn't I be able to kill my own processes? >> >> It's not "your own" process, it's "cron job" started with your credentials. >> >>> I can certainly do that under WinXP. >> >> Again, only if you logged in as admin. >> This is not the case in Vista+ by default. > Okay, I think what you are telling me is that the login I'm using on "my" > WinXP PC (which I inherited) must be an administrator login By default, the first user account created after system installation (rid:1000), have admin rights. In any system, starting from Win2000. However, WinXP has no concept of privilege escalation, and if you've had admin rights, you were always working with them enabled. > and the login > I'm using on the Win7 PC is not an administrator login (it isn't). That > sounds plausible (I know a lot more about UNIX than I do about Windows). Then just think as if you've been running as root in WinXP, but now, you're running as user with access to sudo facility under Win7. This is not entirely correct, but close enough to give you an idea. > So > the differences I'm seeing between WinXP and Win7 is due to using/not using > an administrator login, not due to whether it is WinXP or Win7. The difference is inherently architectural, and not directly related to using or not using admin account. I think we best keep discussion strictly relevant to your present issue. If you want any more details on Win7 security "improvements", google "UAC description". -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <01:14> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
On Nov 13 15:20, Warren Young wrote: > On Nov 13, 2014, at 3:09 PM, Corinna Vinschen > wrote: > > > Did you install for "just you", > > I just made a fresh install into c:\zz, accepting all the defaults in > setup.exe, so it installed for everyone. I got the same result as my > preexisting install. > > Perhaps this is helpful: > > $ id > uid=1000(Warren) gid=513(None) groups=513(None),559(Performance Log > Users),545(Users) > > Apparently I am a member of both None and Users, whatever that means. That's normal. No idea what "they" thought by introducing the local "None" group. It's your primary group with every local SAM account, unchangable in the user management. > > or in a non-elevated Setup? > > I did these tests on a Windows 10 technical preview VM with UAC left > in its default setting. I did get the blue and yellow UAC dimmed > desktop dialog when running setup.exe, so I assume it managed to > elevate itself. Weird. I wonder why the ACL doesn't contain your primary group. Setup installs all files with explicit ACL containing entries for you, your primary group, and "Everyone". Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFWBWx55jeZ.pgp Description: PGP signature
Re: /usr/local, /var and */tmp in c:\Users\Public
Greetings, Warren Young! >>> I propose that this or something like it be added to the default >>> fstab. >> >> No. This would even break Setup right now. > I’m guessing this is because setup.exe doesn’t know what to do with a > redirected /var and /usr/local on the first install, when /etc/fstab doesn’t > exist yet? > I assume setup.exe does obey /etc/fstab on subsequent installs. If not, I > can see that this will break the installation of any package that puts files > in either location. I can't see, why it ever should care about /etc/fstab at all. The postinstall scripts - they do, but again, they run in cygwin environment, not native. > I don’t see that the */tmp changes would bother setup.exe. > None of these problems seem difficult. Doesn’t setup.exe write the initial > /etc/fstab, and so is in a position to know what it will contain on first > install? Even if it does, there's no reason to read it on subsequent updates. The expectation is that the directory tree is in one place. If you really want to scatter it, use native tools. It is possible and way less intrusive. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <01:34> Sorry for my terrible english...
Re: Accessing a "Test" release
Greetings, DJ Sylvester! > Whoops. Last message was encrypted. My bad. > I'm interested in running the 1.7.34-001 test release. In the > announcements it says: > "...you can find it in your setup-x86.exe or setup-x86_64.exe as > "test" release." > "In" the setup? I've run the setup-x86_64.exe and don't see anywhere to > choose a test release including the pane for "choose a download site". > Where do I find the option? Package list - full mode - search for "cygwin" - click the spinner until the experimental version appear. Also don't forget to account for mirror propagation. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <01:51> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin setup program questions
Greetings, t s! > just to check my understanding of the setup program, latest version 2.852 (64 > bit); > the options are install / re-install / un-install / default > my understanding is as follows; > choosing "install" creates a new installation of the selected cygwin > components Or upgrade. > choosing "re-install" uninstalls the selected cygwin components, then creates > a new installation I wouldn't use the term "new installation", unless it's a completely new installation of Cygwin. But, yes. Reinstall will perform uninstall of the selected package, including removal of specified files and execution of relevant scripts, then install it again. Again, executing all relevant scripts in process. > choosing "un-install" uninstalls the selected cygwin components > choosing "default" updates the selected cygwin components > so if I wish to update my local installation to the latest release, I would > choose "default", as per the following screen capture; > http://www.cpm86.com/default.jpg Generally speaking, yes. Though, if I were you, I would never touch the top-level spinner. We've been there already, and we've seen the results. > the "keep" / "cur" / "exp" radio buttons; changes what the "Default" means: > keep the installed packages, update to whatever the current version is or > update to whatever the "experimental" or test version is. (thanks Achim) Yes. Though, if you're curious (or thorough. Or both.), you may spin the list view to "Pending" and confirm the real list of packages and their versions to be installed. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <01:43> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
Greetings, Corinna Vinschen! >> > However, the *other* idea is that if you install with an elevated Setup, >> > your account is an admin account anyway. Ideally when you install >> > Cygwin for multiple users, you're using an account you're not using for >> > daily usage. >> >> Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the >> installing user? > In a corporate model this might make sense, but for the home user? I'm > not so sure about SYSTEM, though. Administrator/Administrators sounds > right to me. SYSTEM? NT SERVICE\TrustedInstaller >.< At least that's what many of the apps installed with. @ /c/Program Files/DVD Maker $ icacls DVDMaker.exe | iconv -f cp866 DVDMaker.exe NT SERVICE\TrustedInstaller:(F) BUILTIN\Administrators:(RX) NT AUTHORITY\SYSTEM:(RX) BUILTIN\Users:(RX) Not all, though. @ /c/Program Files/Opera $ icacls.exe opera.exe | iconv -f cp866 opera.exe NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) > Hmm. As I said, at one point back in the early > 1.7 days setup did something like that, but we got complaints. I don't > remember the details. But if we do something like that again, it should > be configurable. Maybe the "Just Me"/"All users" choice is sufficient > if explained sufficiently in the GUI? It's interested to know, what these complaints were about exactly. I was away from the list, when transition to 1.7 occured. > Also, who's going to do that? The coding part, I mean. Lots of what's > required is already in setup, but I can't write it often enough (it's > an obsession probably): I would be very glad for developers not shy > making their hands dirty. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <02:02> Sorry for my terrible english...
Re: /usr/local, /var and */tmp in c:\Users\Public
Greetings, Corinna Vinschen! >> > Just to pick a random example: >> > >> > $ ls -l /bin/ls.exe >> > -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe >> > >> > The same file’s permissions, from Windows’ perspective: >> > >> > http://etr-usa.com/cygwin/ls-perms.png >> >> icacls output would be more helpful than a picture. >> >> However, this isn't really a problem. The group permissions are >> apparently faked by Cygwin, they don't reflect the reality. I just >> don't remember why this is done, it's probably old. Have to check... > Btw., I never saw this happen. Did you install for "just you", or > in a non-elevated Setup? In my case the permissions make at least > sense, even if my own account still has full access: > $ ls -l /bin/ls.exe > -rwxr-xr-x 1 corinna vinschen 116253 Oct 13 18:12 /bin/ls.exe Curious. Same for me. Win7/64 with 64-bit Cygwin default (elevated) install. $ LANG=C ls -l /bin/ls -rwxr-xr-x 1 anrdaemon None 116253 Oct 13 19:12 /bin/ls $ LANG=C ls -l /bin/ls.exe -rwxr-xr-x 1 anrdaemon None 116253 Oct 13 19:12 /bin/ls.exe -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, <02:13> Sorry for my terrible english...
Re: [REQUEST] Please upgrade irssi (0.8.17)
Just installed irssi 0.8.17-1 update on 32-bit installation and it works as expected. Have not yet upgraded to most recent version of cygwin, though. On Thu, Nov 13, 2014 at 10:26 AM, Keith Christian wrote: > I get a cygcheck usage error for both of those commands. > > On Thu, Nov 13, 2014 at 7:52 AM, Marco Atzeri wrote: >> On 11/13/2014 3:44 PM, Keith Christian wrote: >>> >>> Updated, but missing cygperl5_14.dll. >>> >>> + ls -l /usr/bin/irssi.exe >>> -rwxr-xr-x 1 kchris Domain Users 1180701 Nov 12 10:47 >>> /usr/bin/irssi.exe >>> + irssi -version >>> /usr/bin/irssi.exe: error while loading shared libraries: >>> cygperl5_14.dll: cannot open shared object file: No such file or >>> directory >>> + echo >>> >>> + locate -i '*cygperl5_14.dll*' >> >> >> Strange >> >> irssi requires perl where cygperl5_14.dll is >> >> on 64 bit >> $ cygcheck -f $(which cygperl5_14.dll) >> perl-5.14.4-1 >> >> on 32bit >> $ cygcheck -f $(which cygperl5_14.dll) >> perl-5.14.2-3 >> >> >> >> -- >> Problem reports: http://cygwin.com/problems.html >> FAQ: http://cygwin.com/faq/ >> Documentation: http://cygwin.com/docs.html >> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >> > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Notable performance improvement in 64-bit build
Csaba Raduly writes: > Do you have the same .profile in both installations? Yes, the two installations are actually sharing the same home dir, I have both of them configured to use HOME=%USERPROFILE%. > Do you have the same bash-completion package (often the most > time-consuming part of bash startup)? I don't have the "bash-completion" package installed at all, neither in the 32-bit nor 64-bit installs. I just double checked this now. Also, I didn't mention this in the original mail, but to make sure I was comparing apples to apples I actually put "set -x" at the top of the .profile script, then I ran it under the 32-bit and 64-bit installs and compared the outputs using "diff", to make sure the exact sequence of steps was executed in both cases. Of course I removed the "set -x" for the actual benchmark measurements. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /usr/local, /var and */tmp in c:\Users\Public
Hi, On 14/11/14 08:30, Corinna Vinschen wrote: On Nov 13 14:09, Warren Young wrote: On Nov 13, 2014, at 2:33 AM, Corinna Vinschen wrote: On Nov 12 17:19, Warren Young wrote: I’m not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes. ??? What "strong" ACLs? The ones that are not there right now. :) Just to pick a random example: $ ls -l /bin/ls.exe -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe The same file’s permissions, from Windows’ perspective: http://etr-usa.com/cygwin/ls-perms.png icacls output would be more helpful than a picture. However, this isn't really a problem. The group permissions are apparently faked by Cygwin, they don't reflect the reality. I just don't remember why this is done, it's probably old. Have to check... So, just because I installed Cygwin with my regular user account, I get permission to rewrite ls.exe. This is not a good thing, if our goal is to make Cygwin work like Linux while working *within* the Windows environment. IMHO, the way to meet both goals simultaneously is to put programs in c:\Program Files, No, sorry, but no. We're certainly not going to turn everything upside down installation-wise. If you want Cygwin installed into Program Files, just change it in the GUI. and to give full-control perms to the local Administrator account in the SAM case, or possibly the domain one in the AD case. BTDT. The code is still in Setup, just doesn't run anymore. The idea was to install with user and group set to Administator/ Administrators, but we had some complaints and the code got deactivated. We can reactivate the Administrators group, but that still requires to run Setup elevated. It doesn't work when running under a non-admin account. However, the *other* idea is that if you install with an elevated Setup, your account is an admin account anyway. Ideally when you install Cygwin for multiple users, you're using an account you're not using for daily usage. If you read back through some of my emails to this list, you'll see that this is exactly the setup I adopted some time back. It is also why I contributed the -B switch to setup. What the OP is asking for has always been available. And it is analogous with Unix. What I do is: 1) create a non-admin user named portapps. 2) cmd 3) runas /user:portapps cmd 4) as portapps, run c:\Program Files\7zip\7zFM to give me a graphical way to navigate the filesystem and create folders. 5) Create a folder c:\Users\Public\portapps. 6) Adjust the permissions on that folder so that inheritance from c:\Users\Public is broken, and inherited permissions with portapps FullControl and Everyone read/execute (I'm talking Windows perms here). 7) Now I run setup-x86(_64) -B still as portapps from cmd, install to c:\User\Public\portapps\cygwin. 8) That's it. Now my regular user can run c:\User\Public\portapps\cygwin\bin\mintty - and cannot accidentally overwrite /bin, /etc or anything like that. All software administration (install, /etc config) is done via portapps user. 9) This is no different to unix/linux, where you'd have to do sudo apt-get install, or sudo yum install, or sudo vi /etc/profile etc portapps is almost equal to root. 10) If you want to do Windows privileged stuff, you'll have to run those in an elevated mintty. Of course there is still the danger of overwriting /bin there. But if you are limiting doing that to just things like ssh-host-config etc, than it's fine. Also best to have a separate admin account to your account if possible. -- Regards, Shaddy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: Ruby 2.0.0-p598
The following packages have been updated in the Cygwin distribution: * ruby-2.0.0-p598-1 * ruby-doc-2.0.0-p598-1 * ruby-tcltk-2.0.0-p598-1 Ruby is the interpreted scripting language for quick and easy object-oriented programming. It has many features to process text files and to do system management tasks (as in Perl). It is simple, straight forward, and extensible. This is an update to the latest upstream patch release for the 2.0 branch, with one more security fix: https://www.ruby-lang.org/en/news/2014/11/13/rexml-dos-cve-2014-8090/ -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: Ruby on Rails 4.0.11
The following packages have been updated in the Cygwin distribution: * ruby-actionmailer-4.0.11-1 * ruby-actionpack-4.0.11-1 * ruby-activemodel-4.0.11-1 * ruby-activerecord-4.0.11-1 * ruby-activesupport-4.0.11-1 * ruby-bcrypt-3.1.9-1 * ruby-bundler-1.6.9-1 * ruby-execjs-2.2.2-1 * ruby-mysql2-0.3.17-1 * ruby-oj-2.11.1-1 * ruby-rails-4.0.11-1 * ruby-railties-4.0.11-1 * ruby-sass-rails-4.0.4-1 * ruby-sprockets-2.11.3-1 * ruby-sqlite3-1.3.10-1 * ruby-turbolinks-2.5.2-1 Rails is a web application development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. These releases represent the latest upstream patch release of Rails 4.0, including security fixes: http://weblog.rubyonrails.org/2014/10/30/Rails_3_2_20_4_0_11_4_1_7_and_4_2_0_beta3_have_been_released/ Installing the 'ruby-rails' package and its dependencies should provide the gems required for an application in the default configuration; optional dependencies also available need to be selected separately for installation. Because of how gem dependencies work, in order to assure that you use these versions, the following steps must be followed when creating a new Rails application: $ rails new testapp1 --skip-bundle (files are installed) $ cd testapp1 $ bundle install --local (this will show that existing gems are being used) $ rails server (then point browser to http://localhost:3000/, or install rails-unicorn and...) $ unicorn_rails (then point browser to http://localhost:8080/) And to upgrade existing apps to this version of Rails: $ $EDITOR Gemfile (and update the gem 'rails' version number) $ bundle update --local (Existing gems should be found and used.) $ rake rails:update (and follow the prompts to update files) If you do not use the --local flags as indicated above, then other versions of these gems may end up being installed, which may break things either then or down the road. As always, you get to keep both pieces. :-) -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Incorrect workaround for KB 823764 in fhandler_socket.cc
Hello, While investigating a problem on the google cloud infrastructure, we have discovered that the workaround for KB 823764 in fhandler_socket.cc is incorrect - the data must be split in packets strictly less than the send buffer size (instead of <=). What is the procedure for submitting patches for cygwin? Also, are there cross-compiling cygwin1.dll on ubuntu? I assume that must be possible. Thank you. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Incorrect workaround for KB 823764 in fhandler_socket.cc
On 2014-11-14 05:37, Iuliu Rus wrote: > > What is the procedure for submitting patches for cygwin? See https://cygwin.com/contrib.html Denis Excoffier. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
