Re: cygutils Postinstall Script Errors With Exit Code 128
exit code 128 <http://www.keepdynamic.com/barcoding/asp-net-barcode-generator.shtml> Generally, this kind of failure stems from a few common problems: 1. The existence of another (often old) cygwin1.dll. Find it. Remove it. 2. http://cygwin.com/acronyms/#BLODA. Remove BLODA. 3. Possibly fork failures. Install the rebase package and run rebaseall after reading the README in /usr/share/doc/Cygwin. Also, make sure you're using the latest 'setup.exe' as found at cygwin.com. Beware of proxies along your path that could be caching an old version. You want version 2.697. Problem reports: http://cygwin.com/problems.html If it's none of the above, please provide cygcheck output as requested by the link above. -- View this message in context: http://cygwin.1069669.n5.nabble.com/Re-cygutils-Postinstall-Script-Errors-With-Exit-Code-128-tp99002p109846.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 6/5/2013 12:47 PM, Yaakov (Cygwin/X) wrote: On 2013-05-31 03:34, Corinna Vinschen wrote: On May 30 16:50, Charles Wilson wrote: If we want to include (some subset of) cygutils explicitly in Base, I could see splitting into three subpackages: cygutils (Base): cygdrop cygstart lpr mkshortcut readshortcut winln What about "cygstart mkshortcut readshortcut"? These may be used by postinstall scripts, the other stuff is extra, afaics. Agreed. Ack. IMO man1 pages should be packaged together with their executables. Ack. So, as result, we should do this for a start: - cygwin-doc drops "Base" from the categories. - dos2unix adds "Base" to the categories. - cygutils drops "dos2unix" from requires. Yes. The man3 and info pages definitely don't need to be in Base, but it would be nice if the man1 pages were packaged with cygwin. Is that possible? Otherwise, this sounds good to me. Sure, I can do that. I'll roll a new release tonight (for both 32- and 64-). -- Chuck -- 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: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 2013-05-31 03:34, Corinna Vinschen wrote: On May 30 16:50, Charles Wilson wrote: If we want to include (some subset of) cygutils explicitly in Base, I could see splitting into three subpackages: cygutils (Base): cygdrop cygstart lpr mkshortcut readshortcut winln What about "cygstart mkshortcut readshortcut"? These may be used by postinstall scripts, the other stuff is extra, afaics. Agreed. cygutils-extra (Util): [requires: cygutils] almost everything else, including documentation and man pages (even for the exe's in the Base package) IMO man1 pages should be packaged together with their executables. cygutils-x11 (X11): [requires: cygutils] the two desktop files, and the postinstall scripts that handle them This way, any package that currently requires: cygutils will almost certainly get the tool it is looking for, without having to change its requires line (and besides, if cygutils is in Base you'd get those anyway). So, as result, we should do this for a start: - cygwin-doc drops "Base" from the categories. - dos2unix adds "Base" to the categories. - cygutils drops "dos2unix" from requires. And additionally you propose the above change to cygutils. Sounds good to me. Yaakov? The man3 and info pages definitely don't need to be in Base, but it would be nice if the man1 pages were packaged with cygwin. Is that possible? Otherwise, this sounds good to me. 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: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On May 30 16:50, Charles Wilson wrote: > On 5/30/2013 5:08 AM, Corinna Vinschen wrote: > >That sounds strange. Was cygwin-doc always in Base? It contains the > >cygwin docs and basic man pages but that doesn't really qualify for the > >Base category. > [...] > One caveat, mentioned in my other reply: cygutils' own requires: > line lists dos2unix, so right now a Base install gets that package. > This is probably desirable, but if we (effectively) remove cygutils > from a Base install, we probably would want to add dos2unix to Base > explicitly. > > If we want to include (some subset of) cygutils explicitly in Base, > I could see splitting into three subpackages: >cygutils (Base): > cygdrop cygstart lpr mkshortcut readshortcut winln What about "cygstart mkshortcut readshortcut"? These may be used by postinstall scripts, the other stuff is extra, afaics. >cygutils-extra (Util): [requires: cygutils] > almost everything else, including documentation and man > pages (even for the exe's in the Base package) >cygutils-x11 (X11): [requires: cygutils] > the two desktop files, and the postinstall scripts that > handle them > > This way, any package that currently requires: cygutils will almost > certainly get the tool it is looking for, without having to change > its requires line (and besides, if cygutils is in Base you'd get > those anyway). So, as result, we should do this for a start: - cygwin-doc drops "Base" from the categories. - dos2unix adds "Base" to the categories. - cygutils drops "dos2unix" from requires. And additionally you propose the above change to cygutils. Sounds good to me. Yaakov? 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: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 5/30/2013 5:08 AM, Corinna Vinschen wrote: On May 29 18:51, Yaakov (Cygwin/X) wrote: But now that you mention it, is cygutils *supposed* to be in Base? It is marked category: Utils, but seems to be pulled into Base only because of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be Doc?) listing it as a dependency. That sounds strange. Was cygwin-doc always in Base? It contains the cygwin docs and basic man pages but that doesn't really qualify for the Base category. Over the years, cygutils has "lost" a lot of content to other packages (standalone, util-linux, etc), and gained a smaller collection of new tools. In the past, cygutils may have been considered more central than its current incarnation deserves. current contents of cygutils: banner.exe getclip.exe readshortcut.exe conv.exeipcksemstat.exe cygdrop.exe lpr.exe semtool.exe cygicons-0.dll mkshortcut.exe shmtool.exe cygstart.exemsgtool.exe winln.exe dump.exeputclip.exe Other than cygstart, cygdrop and lpr(?), and maybe the new winln, I can't see that any of those really deserve to be in Base. If cygwin-doc is truly the only thing pulling cygutils into Base, then (a) removing cygutils from cygwin-doc's requires:, or (b) removing cygwin-doc from Base, would have the (desired?) effect of removing cygutils from Base. One caveat, mentioned in my other reply: cygutils' own requires: line lists dos2unix, so right now a Base install gets that package. This is probably desirable, but if we (effectively) remove cygutils from a Base install, we probably would want to add dos2unix to Base explicitly. If we want to include (some subset of) cygutils explicitly in Base, I could see splitting into three subpackages: cygutils (Base): cygdrop cygstart lpr mkshortcut readshortcut winln cygutils-extra (Util): [requires: cygutils] almost everything else, including documentation and man pages (even for the exe's in the Base package) cygutils-x11 (X11): [requires: cygutils] the two desktop files, and the postinstall scripts that handle them This way, any package that currently requires: cygutils will almost certainly get the tool it is looking for, without having to change its requires line (and besides, if cygutils is in Base you'd get those anyway). > Also, why does cygwin-doc depend on cygutils at all? It only contains > info and man pages, so the deps should be coreutils and man, > but nothing else, AFAICS. Maybe it used to install a shortcut to the documentation into the Start Menu, and needed mkshortcut to do so? It doesn't do that anymore (if it ever did), so the dependency on cygutils sure seems superfluous. -- Chuck -- Chuck -- 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: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 5/29/2013 7:51 PM, Yaakov (Cygwin/X) wrote: On 2013-05-29 17:43, Charles Wilson wrote: /usr/share/applications/cygstart.desktop /usr/share/mime/packages/cygutils.xml Right, because packages providing those kind of files usually need those commands to be run in order for them to take effect; see below. However, at user request I've manually removed the requires: line, because the addition of these two files to the cygutils package shouldn't have the effect of pulling *PERL* into the Base category. I assumed we'd live with the semi-brokenness for a few days, until... Perl? I thought it was Python, due to a false positive in the dependency detection with glib2.0, which I fixed on sourceware. You're right, it was python. One of the gigantic "p*" packages, anyway... But now that you mention it, is cygutils *supposed* to be in Base? It is marked category: Utils, but seems to be pulled into Base only because of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be Doc?) listing it as a dependency. I've got email from 2006 [1] where the following was mentioned: "Since cygutils is required by some packages in the Base category, ..." so maybe at one point, several packages required it. It's also possible, at one point, that we explicitly wanted it to be in that category, as it provided our d2u/u2d tools. Obviously now that we have an standalone u2d package that isn't an issue (but I note that dos2unix is NOT in Base, but IS listed as requirement for cygutils. So if we take action to (effectively) remove cygutils from Base, then dos2unix will also go "missing". The "problem" here is that cygutils is not primarily a desktop-oriented package. Most packages providing XDG menu and mime entries *are*, so these dependencies not only mandatory, but quite modest by those standards. I added these files because it allows better integration between desktop file managers (Nautilus/Caja/Thunar/PCManFM/Dolphin/etc.) and Windows, e.g. making it easy to launch an EXE/MSI installer from one's Downloads folder. However, most people use cygutils outside of the desktop, so particularly if its pulled into Base, these deps would be more than the bare-minimal system. If cygutils should be in Base, the "solution" is probably one of the following: * provide these files (and postinstall scripts) in a 'cygutils-x11' subpackage; * OR move them to another package (not sure which yet) which will already be installed in desktop scenarios, and adding cygutils as a dependency thereto. For now, should we go with the first option? Yes, that's probably the best way to go. I'll roll a new release with that change, for both 32- and 64- cygwin, soon. (Need to investigate the recent resurrected report about cygdrop and privelege dropping first). [1] http://cygwin.com/ml/cygwin-apps/2006-03/msg00117.html -- Chuck -- 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: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On May 29 18:51, Yaakov (Cygwin/X) wrote: > But now that you mention it, is cygutils *supposed* to be in Base? > It is marked category: Utils, but seems to be pulled into Base only > because of cygwin-doc (which *is* in Base, oddly enough; shouldn't > it just be Doc?) listing it as a dependency. That sounds strange. Was cygwin-doc always in Base? It contains the cygwin docs and basic man pages but that doesn't really qualify for the Base category. Also, why does cygwin-doc depend on cygutils at all? It only contains info and man pages, so the deps should be coreutils and man, but nothing else, AFAICS. 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: Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
Sorry for missing this before. On 2013-05-29 17:43, Charles Wilson wrote: Known issue, waiting for cygport fix. cygutils relies on cygport auto-generating the postinstall scripts which invoke those tools. Cygport does this because the install package contains the following two files: /usr/share/applications/cygstart.desktop /usr/share/mime/packages/cygutils.xml ...and it generates the postinstall script unconditionally (e.g. I can't turn it off) and the generated postinstall scripts themselves call the tools unconditionally. Cygport also automatically adds the packages which contain those tools to the requires: field of the setup.hint, so...under normal circumstances, everything should be fine. Right, because packages providing those kind of files usually need those commands to be run in order for them to take effect; see below. However, at user request I've manually removed the requires: line, because the addition of these two files to the cygutils package shouldn't have the effect of pulling *PERL* into the Base category. I assumed we'd live with the semi-brokenness for a few days, until... Perl? I thought it was Python, due to a false positive in the dependency detection with glib2.0, which I fixed on sourceware. But now that you mention it, is cygutils *supposed* to be in Base? It is marked category: Utils, but seems to be pulled into Base only because of cygwin-doc (which *is* in Base, oddly enough; shouldn't it just be Doc?) listing it as a dependency. ...I'm waiting for Yaakov to say whether this should be "fixed" in cygport [1], or if I should override all the auto-generation stuff by manually creating an explicit postinstall script (with suitable tool existence checks) and setup.hint. The "problem" here is that cygutils is not primarily a desktop-oriented package. Most packages providing XDG menu and mime entries *are*, so these dependencies not only mandatory, but quite modest by those standards. I added these files because it allows better integration between desktop file managers (Nautilus/Caja/Thunar/PCManFM/Dolphin/etc.) and Windows, e.g. making it easy to launch an EXE/MSI installer from one's Downloads folder. However, most people use cygutils outside of the desktop, so particularly if its pulled into Base, these deps would be more than the bare-minimal system. If cygutils should be in Base, the "solution" is probably one of the following: * provide these files (and postinstall scripts) in a 'cygutils-x11' subpackage; * OR move them to another package (not sure which yet) which will already be installed in desktop scenarios, and adding cygutils as a dependency thereto. For now, should we go with the first option? 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
Attn: Yaakov [Was: Re: cygutils Postinstall Script Errors With Exit Code 128]
On 5/29/2013 11:47 AM, Reini Urban wrote: I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database /usr/share/mime Known issue, waiting for cygport fix. cygutils relies on cygport auto-generating the postinstall scripts which invoke those tools. Cygport does this because the install package contains the following two files: /usr/share/applications/cygstart.desktop /usr/share/mime/packages/cygutils.xml ...and it generates the postinstall script unconditionally (e.g. I can't turn it off) and the generated postinstall scripts themselves call the tools unconditionally. Cygport also automatically adds the packages which contain those tools to the requires: field of the setup.hint, so...under normal circumstances, everything should be fine. However, at user request I've manually removed the requires: line, because the addition of these two files to the cygutils package shouldn't have the effect of pulling *PERL* into the Base category. I assumed we'd live with the semi-brokenness for a few days, until... ...I'm waiting for Yaakov to say whether this should be "fixed" in cygport [1], or if I should override all the auto-generation stuff by manually creating an explicit postinstall script (with suitable tool existence checks) and setup.hint. [1] arguably, cygport is doing the right thing: (1) ensuring that the tools are called to install the two files, and (2) ensuring that the packages which contain those tools are listed in the requires: line. So, I'm not sure what the "correct" fix should be, and am waiting for Yaakov's input. See: http://cygwin.com/ml/cygwin/2013-05/msg00211.html -- Chuck -- 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: cygutils Postinstall Script Errors With Exit Code 128
cygwin-owner at cygwin dot com wrote on 05/29/2013 11:47:20 AM: > From: Reini Urban > To: The Cygwin Mailing List , Charles Wilson > , > Date: 05/29/2013 11:47 AM > Subject: Re: cygutils Postinstall Script Errors With Exit Code 128 > Sent by: cygwin-owner at cygwin dot com > > On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote: > > Package: cygutils > > cygutils.sh exit code 127 > > Package: man > > man.sh exit code 128 > > I got the cygutils postinstall error also, caused by missing dependencies. > > $ cat /etc/postinstall/cygutils.sh > /usr/bin/update-desktop-database > /usr/bin/update-mime-database /usr/share/mime > > both scripts do not exist, and are no cygutils reqs. > please test against it. > like: > test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database > test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database > /usr/share/mime > -- > Reini Urban > http://cpanel.net/ http://www.perl-compiler.org/ Those update-* files do not exist for me either. However, I think my problems are starting before cygutils.sh returns with exit code 127. Are you asking me to test that the files exist before I run them? Or, are you asking the Cygwin maintainers to have their cygutils script do so? ~ Paul -- 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: cygutils Postinstall Script Errors With Exit Code 128
On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote: > I am attempting to install Cygwin, and am getting errors near the end of > the process. I am using version 2.774 of setup.exe on Microsoft Windows > Server 2003 R2 Datacenter x64 Edition Service Pack 2 and the default > Cygwin packages. This is an Amazon AWS EC2 instance, and I am remote > desktopping in. In the Cygwin Setup GUI, after it goes through the install > procedure, I get a window titled Postinstall script errors, with the below > output text: > > Package: base-cygwin > 000-cygwin-post-install.sh exit code 128 > Package: terminfo > terminfo.sh exit code 128 > Package: bash > bash.sh exit code 128 > Package: coreutils > coreutils.sh exit code 128 > Package: _autorebase > autorebase.bat exit code -1073741819 > Package: base-files > base-files-profile.sh exit code 2816 > base-files-mketc.sh exit code 128 > Package: cygutils > cygutils.sh exit code 127 > Package: man > man.sh exit code 128 I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database /usr/share/mime > If I then open Cygwin Terminal using the Desktop shortcut, I get a window > titled "-sh" and a prompt that says "-sh-4.1$". The command "ls" returns > "-sh: ls: command not found", but echo works. I have tried re-running > setup.exe, removing the cygwin directory, re-downloading the setup.exe, > removing HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin from the registry, > setting "Turn on DEP for essential Windows programs and services only" and > rebooting, altering file and folder permissions, deleting the cache and > using different mirrors, and using rdesktop in CentOS vs. mstsc.exe in > Windows to remote desktop in, but none of this changes the behavior. > > I have an odd and possibly related behavior. If I open Command Prompt, run > C:\cygwin\bin\bash.exe --norc --noprofile > to get a "bash-4.1$" prompt, then in there run > if [ "foo" = "foo" ]; then echo "Expression evaluated as true."; fi > the bash prompt will exit back to command prompt, and %ERRORLEVEL% has > been set to 128. > Running that if statement in the window brought up by the Cygwin Terminal > Desktop shortcut will sometimes make the window close, but not always. I > have not explored how I might be triggering the Desktop shortcut to work > or not work. > > I have attached setup.log and setup.log.full. > > When I run cygcheck -s -v -r > cygcheck.out, it hangs and does not exit. > Checking Task Manager, I see that it's using ~45% CPU (I have 2 virtual > cores). It does write some things out to cygcheck.out, which I have > attached. When I run the command in Command Prompt without redirecting > output to a file, I get a little more information before it hangs, which I > have copied out of the command prompt and attached as > cygcheck-no-redirect.out. I do not know why it's saying I have multiple > cygwin1.dlls on my path. There is only C:\cygwin\bin\cygwin1.dll. > > Looking at cygcheck.out, I am running in a Terminal Service session, which > makes sense as I am remote desktopped in. My problem might be related to > FAQ #2.14 (http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts > ), but the DEP solution is not helping me. I tried running > "C:\cygwin\bin>peflags --tsaware=true --tsaware *" in Command Prompt, but > it did not change anything. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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