Re: Some repeated tasks at every update
>> A list of those would be useful unless access to your system is available? Thank you Brian. For info my very reduced but entirely adequate Cygwin installation (to my purposes) is driven by setup-x86_64 -P ImageMagick,R,autoconf,automake,bash-completion,bc,binutils,bison,byacc, coreutils,cpio,csih,cygutils,cygutils-extra,diffutils,dos2unix,e2fsprogs,fdupes,file, findutils,flex, gcc,gcc-core,gcc-g++,gnuplot-X11,gv,hexedit,joe,libRmath-devel,libX11-devel, libheif-devel,libheif-tool,libncurses-devel,libreadline-devel,libsqlite3-devel,libusb-devel, lua,lua-devel,make,mintty,mkisofs,moreutils,mysql,nano,ncurses,patchutils,python,sqlite3, tcl-tix,tcl-tk-devel,texlive-collection-latex,tree,util-linux,xinit,xorg-x11-fonts-dpi75, xorg-x11-fonts-dpi100,xpdf (sorry for the length) (and some of these are probably carried by Base or setup-defined dependencies) and as a consequence my 12 persistent updates in /etc/postinstall/ are zp_hicolor-icon-theme.sh zp_fontconfig_dtd.dash zp_adwaita-icon-theme.sh 0p_000_autorebase.dash zp_glib2.0.sh zp_desktop-file-utils.sh zp_fontconfig_cache_1.sh zp_shared-mime-info.sh zp_man-db-update-index.dash 0p_texlive_prep.dash zp_texlive_finish.dash 0p_update-info-dir.dash The requirements adwaita and texlive are the most time-consuming (and perplexing!). Fergus -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Some repeated tasks at every update
There are 12 tasks never shown ".done" in /etc/postinstall/ (6 .dash and 6 .sh) and therefore repeated at every update. (Other users' installations might have 12 +/-.) They are not particularly intrusive (though they can take a while) but nor is their inclusion or the exclusion of many others at all obvious, except perhaps for *update* and maybe autorebase. Not really too bothered about rationale but can an Admin confirm their necessary presence? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
exit code 2 from /etc/preremove/python39-pip.sh
I don't think it matters much (or at all*) but while installing today's python39 update I got: running: .. .. \bin\bash.exe --norc --noprofile "/etc/preremove/python39-pip.sh" abnormal exit: exit code=2 On inspection the .sh file contains the single command: /usr/sbin/alternatives --remove pip3 /usr/bin/pip3.9 This syntax with arguments and switches is duplicated frequently in /etc/preremove/ scripts so I cannot quite see where the problem resides .. .. Fergus (*) Nothing seems to be broken. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: New installation of Cygwin64: xinit.sh exit code 3
<< Detail >>
>> When I used Explorer to visit C:\ProgramData\Microsoft\Windows\Start
>> Menu\Cygwin-X I was told:
>> "You don't currently have permission to access this folder"
>> and clicking on Continue to get access I was told:
>> "You have been denied permission to access this folder"
>>There was then offered an option to edit Permissions which I didn't feel like
>>pursuing.
>> (I am the Administrator on my own standalone Windows machine. The denial of
>> access to Cygwin-X feels odd.
>> PS I also have Cygwin32 installed and running. I _am_ permitted access to
>> the equivalent folder Cygwin-X (32-bit).)
> Please try running the following command/s, under Cygwin 32 and 64, and
> posting
> the outputs:
> $ for p in "`cygpath -A -P -U`"{,/Cygwin-X}; do for c in 'lsattr -d' 'ls -dl'
> getfacl; do $c "$p"; echo; done; icacls "`cygpath -m "$p"`"; done
Thank you. (Again.)
1. Actually before reading this I had deleted both folders
(successfully, despite not being permitted entry into one
of them) and the re-ran the xinit installation with no
bother at all.
I'm guessing the Permissions glitch resulted from some local
recent accidental keypress or sequence.
2. icacls? Haven't got this though I have got getfacl; found icacl in
"Search packages" under libattica-devel and ng-spice-debuginfo?
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: New installation of Cygwin64: xinit.sh exit code 3
>> Should have added: the file /var/log/setup.log shows no detail beyond
>> 2023/10/21 09:29:46 running: G:\console64\bin\bash.exe --norc --noprofile
>> "/etc/postinstall/xinit.sh"
>> 2023/10/21 09:29:49 abnormal exit: exit code=3
>>
>> -Original Message-
>>
>> I made a new installation of Cygwin 64 on a new USB stick, including the
>> package xinit.
>> (I use setup -P followed by a longish but far from complete list of required
>> packages ..,..,xinit,..,..)
>> At this first use of setup I got a single error message:
>>Package: _/xinit xinit.sh exit code 3
>> At 2nd and all subsequent uses of setup (i.e. as update) I get the slightly
>> altered error message:
>>Package: _/Unknown package xinit.sh exit code 3
>> In practice, any usage of xinit (e.g. to launch xterm) seems to work
>> perfectly well, but the repeated
>> error message at any update transaction (including when empty) is
>> disconcerting.
>> I have not tried an explicit command "bash (or dash)
>> /etc/postinstall/xinit.sh" as - even if this worked -
>> I would prefer to canvass opinion on this minor glitch.
>> All the same - the glitch is recent, despite being minor .. ..
> What filesystem is the drive formatted as: NTFS, ExFAT, FAT32, or other?
> Try rerunning the xinit postinstall script as follows and report the failing
> command(s) and error messages:
> $ CYGWINFORALL=-A /bin/sh -vx /etc/postinstall/xinit.sh
Thank you!
1. The identical error msg occurs on all of NTFS, FAT32, exFAT file systems.
2. The output from your test command is identical on all file systems,
3. The failing commands are the two separate "case .. mkdir .. mkshortcut"
sequences that occur
at the end of the xinit.sh script, with consequent error notification as
follows:
case $(uname -s) in *-WOW*) wow64=" (32-bit)" ;; esac
+ case $(uname -s) in
++ uname -s
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X${wow64}"
++ /usr/bin/cygpath -A -P
+ /usr/bin/mkdir -p '/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X'
/usr/bin/mkshortcut $CYGWINFORALL -P -w / -i /usr/bin/xwin-xdg-menu.exe -n
"Cygwin-X${wow64}/XWin Server" -a "--quote /usr/bin/bash.exe
-l -c \"cd; exec /usr/bin/startxwin\"" /usr/bin/run.exe
+ /usr/bin/mkshortcut -A -P -w / -i /usr/bin/xwin-xdg-menu.exe -n
'Cygwin-X/XWin Server' -a '--quote /usr/bin/bash.exe
-l -c "cd; exec /usr/bin/startxwin"' /usr/bin/run.exe
mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X/XWin Server.lnk" failed;
does the target directory exist?
case $(uname -s) in *-WOW*) wow64=" (32-bit)" ;; esac
+ case $(uname -s) in
++ uname -s
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X${wow64}"
++ /usr/bin/cygpath -A -P
+ /usr/bin/mkdir -p '/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X'
/usr/bin/mkshortcut $CYGWINFORALL -P -w / -i /usr/bin/XWin.exe -n
"Cygwin-X${wow64}/User script" -a "--quote /usr/bin/bash.exe
-l -c \"cd; XSESSION_ICON= exec /usr/bin/startx /etc/X11/xinit/Xsession
xinit-compat\"" /usr/bin/run.exe
+ /usr/bin/mkshortcut -A -P -w / -i /usr/bin/XWin.exe -n 'Cygwin-X/User script'
-a '--quote /usr/bin/bash.exe
-l -c "cd; XSESSION_ICON= exec /usr/bin/startx /etc/X11/xinit/Xsession
xinit-compat"' /usr/bin/run.exe
mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X/User script.lnk" failed;
does the target directory exist?
When I used Explorer to visit C:\ProgramData\Microsoft\Windows\Start
Menu\Cygwin-X I was told:
"You don't currently have permission to access this folder"
and clicking on Continue to get access I was told:
"You have been denied permission to access this folder"
There was then offered an option to edit Permissions which I didn't feel like
pursuing.
(I am the Administrator on my own standalone Windows machine. The denial of
access to Cygwin-X feels odd.
PS I also have Cygwin32 installed and running. I _am_ permitted access to the
equivalent folder Cygwin-X (32-bit).)
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: New installation of Cygwin64: xinit.sh exit code 3
Should have added: the file /var/log/setup.log shows no detail beyond 2023/10/21 09:29:46 running: G:\console64\bin\bash.exe --norc --noprofile "/etc/postinstall/xinit.sh" 2023/10/21 09:29:49 abnormal exit: exit code=3 -Original Message- I made a new installation of Cygwin 64 on a new USB stick, including the package xinit. (I use setup -P followed by a longish but far from complete list of required packages ..,..,xinit,..,..) At this first use of setup I got a single error message: Package: _/xinit xinit.sh exit code 3 At 2nd and all subsequent uses of setup (i.e. as update) I get the slightly altered error message: Package: _/Unknown package xinit.sh exit code 3 In practice, any usage of xinit (e.g. to launch xterm) seems to work perfectly well, but the repeated error message at any update transaction (including when empty) is disconcerting. I have not tried an explicit command "bash (or dash) /etc/postinstall/xinit.sh" as - even if this worked - I would prefer to canvass opinion on this minor glitch. All the same - the glitch is recent, despite being minor .. .. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
New installation of Cygwin64: xinit.sh exit code 3
I made a new installation of Cygwin 64 on a new USB stick, including the package xinit. (I use setup -P followed by a longish but far from complete list of required packages ..,..,xinit,..,..) At this first use of setup I got a single error message: Package: _/xinit xinit.sh exit code 3 At 2nd and all subsequent uses of setup (i.e. as update) I get the slightly altered error message: Package: _/Unknown package xinit.sh exit code 3 In practice, any usage of xinit (e.g. to launch xterm) seems to work perfectly well, but the repeated error message at any update transaction (including when empty) is disconcerting. I have not tried an explicit command "bash (or dash) /etc/postinstall/xinit.sh" as - even if this worked - I would prefer to canvass opinion on this minor glitch. All the same - the glitch is recent, despite being minor .. .. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Updated: openssl 1.1.1u-1
During today's update (not test 3.0.9-0.1) this probably unimportant error msg occurred: running: D:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/openssl.sh" can't run /etc/postinstall/openssl.sh: No such file -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Has anybody managed to build FSArchiver?
A visit to https://www.fsarchiver.org/ yields references to versions 0.8.x but at ./configure (though at a very late stage) presents the error msg configure: error: Unsupported system type Cygwin The application looks very competent. Has anybody managed to hack it for Cygwin? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error running setup-x86_64.exe: syntax error in setup.zst
>> I'm concerned that the bad setup.zst might propagate to other mirrors. Yes, identical error arising at https://cygwin.mirror.uk.sargasso.net/x86_64/setup.zst and elsewhere. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
bash shell script: recently running, now failing
I have a "hash bang" bash shell script i.e. first line #! /bin/sh or equivalently #! /bin/bash For various reasons I want this file to be identified as binary so its second line is the single character null \x00 showing up in some editors e.g. nano as ^@ This does not prevent the script from running to a successful conclusion. Or not until recently. Now the script fails with /home/user/bin/file.old.sh: cannot execute binary file Q1 - was bash recently updated? Would this explain the changed behaviour? Q2 - if so, is this newly introduced "glitch" known and presumably intended? Or an unintended consequence that will be retracted in a later update? I then altered the first line to #! /bin/dash whilst retaining the null character at line 2 and subsequent content also unaltered.. The altered script file.new.sh runs as previously to a successful conclusion. Q3 - at 1/8 the size of bash and sh, I am not at all sure of the role and reach of dash. Should the edit (dash replacing bash/sh) be incorporated elsewhere or would this be a bad idea (and retained only locally in what is indeed an eccentric and one-off context)? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Strange link /bin/rungs in 32-bit Cygwin
>> Maybe of diminishing interest (32-bit Cygwin) - but: >> Out of nowhere (but see below (*)) a link has occurred >> /bin/rungs -> /usr/share/texmf-dist/scripts/texlive/rungs.tlu >> which is, I think, a typo for /usr/share/texmf-dist/scripts/texlive/rungs.lua >> Can anybody confirm? > The symlink and script come from texlive-collection-basic. In current > TeX Live on 64-bit Cygwin, the link does indeed point to rungs.lua. But > I think the .tlu extension is used for texlua scripts, so what you're > seeing might not be a typo. I'd have to look back at last year's > texlive-collection-basic to be sure, but you can do that more easily > than I can, since you already have a system with last year's > texlive-collection-basic. You are right. The provision is right though different: Cygwin32: texlive-collection-basic-20220321-1 Cygwin64: texlive-collection-basic-20230313-2 Both setup.ini files are right and so is their enactment. Actually both my platforms were correctly configured with correct links too. My housekeeping, or rather my interpretation of housekeeping reports, was faulty. Sorry for wasted time. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Strange link /bin/rungs in 32-bit Cygwin
Maybe of diminishing interest (32-bit Cygwin) - but: Out of nowhere (but see below (*)) a link has occurred /bin/rungs -> /usr/share/texmf-dist/scripts/texlive/rungs.tlu which is, I think, a typo for /usr/share/texmf-dist/scripts/texlive/rungs.lua Can anybody confirm? (*) Weird. For no particular reason other than for OC fun I ran the 32-bit setup command setup-x86-2.924.exe --allow-unsupported-windows --site http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2022/11/23/063457 (all on one line) on an EXISTING setup (with, as anticipated, no obvious change to the entire resource and, in particular, no change to the timestamp 1669214097 i.e. almost exactly 17 weeks ago when Cygwin-32 was archived. Either (1) this error (if it is one) has been there all the time or (2) has been recently introduced. (1) would be odd because of the recently mentioned OCD and (2) would be odd because it raises questions How? and Why? Notwithstanding the diminishing relevance any enlightenment would be interesting and welcome. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
A query about latest update to "make"
I update my local Cygwin using setup-x86_64.exe. The latest setup.ini file includes the lines setup-timestamp: 1676945925 setup-version: 2.924 @ make version: 4.4-1 [prev] version: 4.3-1 [test] version: 4.4.0.91-1 I definitely do not use the switch -t (for test versions); and yet, following today's update, my /etc/setup/installed.db file includes the lines INSTALLED.DB 3 make make-4.4.0.91-1.tar.bz2 0 Not at all sure why not v.4.4-1? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygwin x86 end-of-life instructions worked really well
Just to say: the instructions at https://cygwin.com/pipermail/cygwin-announce/2022-November/010810.html work really well. I used the following single command at the Command Prompt: "setup-x86-2.924.exe --allow-unsupported-windows --site http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2022/11/23/063457 -P package1,package2,..,packageN" (all on one line) to recover completely my original Cygwin32 platform (being Base + list of required additions). PS1: If you visit this page there is an intrusive word "option" in the instruction .. '--allow-unsupported-windows option --site circa_URL' .. PS2: Can't actually remember where or how I got the required executable setup-x86-2.924.exe -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Contents of /dev/
Until recently my Cygwin installation (which is of considerable size though far from complete) consisted entirely of directories (here about 3300), files (49000), links (2300) and just 1 socket. Now under /dev/ I find 3 directories 0 files 4 links 12 type b being block (buffered) special 17 type c being character (unbuffered) special I don't think I've installed anything new for ages so these have probably arrived with an update. For me the last two types are an entirely new animal. Is it easy to explain what they are and (only secondly, out of interest) whether anybody else is experiencing this for the first time? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: gcc v.11.3.0 failing - possible cause gcc or libreadline.a?
>>> In a gcc build script terminating with the instruction
>>> gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
>>> I have suddenly started getting very many instances of both of
>>> ld: /usr/src/debug/readline-8.2-2/terminal.c:nn various: undefined
>>> reference to `{various}'
>>> ld: /usr/src/debug/readline-8.2-2/display.c:nn various: undefined
>>> reference to `{various}'
>>> and the build fails.
>> The problem was with readline not gcc
>> and I assume originates in myarchive.a and the required switch -lreadline in
>> the gcc line
>> rather than in readline: nevertheless I reverted both libreadline-devel and
>> libreadline7
>> from 8.2-2 to 7.03 and the problem went away.
> Please provide a few examples which include the actual texts of "nn various"
> and
> `{various}' especially where any prefixes vary.
> Did you also upgrade/downgrade libncurses-devel concurrent with
> libreadline-devel as they are dependent?
> Why suppress all warnings -w from the ld (or any) phase of compilation?
> Those warnings could tell you what causes an issue.
No I didn't upgrade / downgrade libncurses-devel concurrently with
libreadline-devel.
In fact after upgrading back to 8.2-2 and confirming the failed build I
retained all current and up-to-date
and made _just_one_change_: I extracted the single file libreadline.a from
libreadline-devel-8.1-2.tar.xz
(i.e. just one reversion to 8.1 not two to 7.0) and substituted it in place
leaving everything else as for 8.2-2
including libreadline.dll.a and confirmed that this single substitution allowed
the build.
I suppress the warnings because there are so many of them! I can supply them
but for the moment the issues
that prevent a successful build using libreadline.a (8.2-2) are listed in the
attached text file.
Thank you very much for taking an interest.
Description:
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: gcc v.11.3.0 failing - possible cause gcc or libreadline.a?
>> In a gcc build script terminating with the instruction
>> gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
>> I have suddenly started getting very many instances of both of
>> ld: /usr/src/debug/readline-8.2-2/terminal.c:nn various: undefined
>> reference to `{various}'
>> ld: /usr/src/debug/readline-8.2-2/display.c:nn various: undefined
>> reference to `{various}'
>> and the build fails.
The problem was with readline not gcc
and I assume originates in myarchive.a and the required switch -lreadline in
the gcc line
rather than in readline: nevertheless I reverted both libreadline-devel and
libreadline7
from 8.22 to 7.03 and the problem went away.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Long lines in posts to this mailing list
What causes long lines without word wrap in posts to this list (such as the immediately preceding "gcc v.11.3.0 failing") and how can they be avoided? (They are very inconvenient - sorry!) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
gcc v.11.3.0 failing - possible cause gcc or libreadline.a?
In a gcc build script terminating with the instruction
gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
I have suddenly started getting very many instances of both of
ld: /usr/src/debug/readline-8.2-2/terminal.c:nn various: undefined
reference to `{various}'
ld: /usr/src/debug/readline-8.2-2/display.c:nn various: undefined reference
to `{various}'
and the build fails.
It's a while since I attempted this build of myexe (myarchive has been
unaltered for years) and the attempt is triggered by a reported bug in gcc -pg
after update that has been corrected.
I don't know whether it is a change in readline (libreadline.a) or gcc that has
possibly caused the glitch (and obviously I cannot and do not expect anybody to
debug my build for me) but is this glitch familiar to anybody through current
or previous experience, or by appearance, that means you could point to cause
or possible cause?
Thank you!
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
terminfo packaging glitch?
Does this: $ ls /usr/share/terminfo/terminfo lrwxrwxrwx /usr/share/terminfo/terminfo -> /usr/share/terminfo/ serve a purpose, or supply a workaround .. or .. is it a packaging glitch? (Only in Cygwin64, not Cygwin32.) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Portable CygWin version for Windows?
Am 14.11.2021 um 11:32 schrieb Marco Atzeri via Cygwin: > On 14.11.2021 08:37, Peter Steiner via Cygwin wrote: >> On webpage >> >> https://cygwin.com/ >> >> I found only a CgyWin Installer to download. >> >> I prefer to put CygWin on an USB flash drive and run it on various >> computers without leaving installation traces. >> >> Is there really no portable version to download? > > correct. No one should install all the files > >> >> What if I install it once one computer and copy all the files to my >> USB flash drive? >> Are there any disadvantages? > > The file permissions will be not correct. Actually, if you format your USB stick to NTFS, this should work. I remember to have had a mobile cygwin stick around a while ago. > > What you can do is use the USB stick as location for the cache download > and install from the USB on the other computers. > >> >> Peter >> > > Regards > Marco >> The file permissions will be not correct. >> Actually, if you format your USB stick to NTFS, this should work. I >> remember to have had a mobile cygwin stick around a while ago. Having trouble following the assertions here. I've had a FAT32 portable USB stick supporting both Cygwin32 and Cygwin64 for, dunno, 20 years or something. I made a new one from scratch last night, actually, absolutely coincidentally to this post. Whilst not "Full" the installation is way in advance of "Base". I just run setup -P at the Windows command prompt, installing to a formatted FAT32 stick, and away I go. Time after time after time. Fergus -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: rename using regexpr - is it possible?
-Original Message-
From: Eliot Moss
Sent: 24 October 2021 17:11
To: Fergus Daly ; 'cygwin@cygwin.com'
Subject: Re: rename using regexpr - is it possible?
On 10/24/2021 4:55 PM, Fergus Daly wrote:
>>> I might be wrong but:
>>> The Cygwin implementation of rename seems completely different from "the"
>>> (my) Linux version.
>>> (Almost unique? Otherwise the matching in Cygwin of all syntax -
>>> vocab, switches, outcomes - to Linux, seems almost perfect.) Can I
>>> rename a set of files *.d (say) as filename.d -> XXfilename.d?
>>> In Linux this would be achieved by
>>> $ rename 's/^/XX/g' ./*.d
>>> whereas in Cygwin
>>> $ rename ^ XX *.d
>>> (and all similar attempts) fails.
>>> Thank you.
>
>> You're confusing perl-rename with util-linu rename.
>> The former, which seems to be what you want, can be installed using
>> cpan (install File::Rename), assuming you have perl installed.
>> It will put its rename command in /usr/local/bin, presumably taking
>> precedence over the util-linux one in /usr/bin.
>> It further seems that "normally" these two have different names, like
>> rename.ul and prename, and /etc/alternatives is used to set up the rename
>> command.
>> This required some web searching to determine ...
>> Cheers - Eliot
>
> Perfect. Worked like a dream.
> All in place, and naming managed.
> Thanks so much.
No problem - learned something myself! EM
PS When I said .. ..
> Perfect. Worked like a dream
.. .. I had only tried things in Cygwin32. The cpan step failed in Cygwin64 so
I couldn't follow up with the install File::Rename command.
(I'm quite surprised. Here, the Cygwin32 and Cygwin64 setups are identical
in that, whilst incomplete i.e. not "Full", they are constructed using the
identical
C:> setup -P {long list of packages separated by commas}
command at the Windows prompt. Up to now they have behaved identically.
Solved by copying across from Cygwin32 to Cygwin64 all the newly
"rename-augmented"
files under /usr/local/bin/, /usr/local/lib/, /usr/local/man/, and not
forgetting the
augmented file /etc/bash.bashrc containing the 4 export perl* lines.
Seems to work so far. But if I hadn't also got Cygwin32, I would have been
stuck with the
cpan failure under Cygwin64. I must have missed something for Cygwin64 .. ..
but Goodness
knows what.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: rename using regexpr - is it possible?
>> I might be wrong but: >> The Cygwin implementation of rename seems completely different from "the" >> (my) Linux version. >> (Almost unique? Otherwise the matching in Cygwin of all syntax - >> vocab, switches, outcomes - to Linux, seems almost perfect.) >> Can I rename a set of files *.d (say) as filename.d -> XXfilename.d? >> In Linux this would be achieved by >> $ rename 's/^/XX/g' ./*.d >> whereas in Cygwin >> $ rename ^ XX *.d >> (and all similar attempts) fails. >> Thank you. > You're confusing perl-rename with util-linu rename. > The former, which seems to be what you want, can be installed using cpan > (install File::Rename), > assuming you have perl installed. > It will put its rename command in /usr/local/bin, presumably taking > precedence over the util-linux one in /usr/bin. > It further seems that "normally" these two have different names, like > rename.ul and prename, > and /etc/alternatives is used to set up the rename command. > This required some web searching to determine ... > Cheers - Eliot Perfect. Worked like a dream. All in place, and naming managed. Thanks so much. Fergus -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Trouble with setting ini files : gnuplot and vi
>> Despite best efforts I cannot find a way of setting user preferences >> for vi (e.g. preferred syntax-sensitive settings) and gnuplot (e.g. >> preferred line colours / thickness). >> I have tried editing /etc/vimrc, /etc/virc for vi; and >> /etc/X11/app-defaults/Gnuplot for gnuplot accordingly. >> (I use gnuplot-x11.) No change from standard representation. >> Any ideas? > If you are really using /usr/bin/vi and not /usr/bin/vim, then you are using > the small version of vim, > which does not support filetype detection or syntax highlighting as well as > some other vim features. > If you want a full-featured vim, install the vim package. > Regards, Gary Seen immediately after my reply to Eliot. Thanks very much - now all is clear. Fergus -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Trouble with setting ini files : gnuplot and vi
>> Despite best efforts I cannot find a way of setting user preferences >> for vi (e.g. preferred syntax-sensitive settings) and gnuplot (e.g. >> preferred line colours / thickness). >> I have tried editing /etc/vimrc, /etc/virc for vi; and >> /etc/X11/app-defaults/Gnuplot for gnuplot accordingly. >> (I use gnuplot-x11.) No change from standard representation. >> Any ideas? >The first thing I would check is whether you have an individual ~/.virc or >~/.gnuplot file that is overriding the settings of interest. > For gnuplot, at least, the man page says that its "show loadpath" command > will indicate where it looks for gnuplotrc. > On my system that is /usr/share/gnuplot/5.4/. > Since my gnuplot offers x11 for "set term", I think I'm looking at the right > thing, but if gnuplot-x11 is truly different, > then maybe try the "show loadpath" command for it. I don't have vi installed > (only vim) so I can't speak to that. > The next thing I would check are the various permissions, to make sure the > program can actually read the file(s) in question. > Maybe you have done all this, in which case I'm sorry my ideas were not > helpful ... > Best wishes - Eliot Moss Thank you! For gnuplot your suggestion worked perfectly. I have now tweaked /usr/share/gnuplot/5.4/gnuplotrc as required. Perplexed by your "vim not vi". I set up my Cygwin platform using setup -P and do not specify any editor beyond nano (which is perfect to my needs). Nevertheless I get vi. From "Package search" I'm guessing it comes as an adjunct because I also need groff and latex. You must actually specify vim? which I vaguely recall preferring to vi but cannot remember why. (Mainly, I liked neither. But I can remember easily setting and locating /etc/vimrc, and that it was properly picked up.) Nevertheless, still having problems with setting and location virc - since I've got vi, I'd just like to be able to use it effectively .. .. Thanks again, anyway. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
gnuplot post-install : exit code 1
Both cygwin32 and cygwin64, both up-to-date: Following recent update to gnuplot I'm getting post-install errors as follows in both setup logs: running: D:\cygwin..\bin\bash.exe --norc --noprofile "/etc/postinstall/gnuplot.sh" abnormal exit: exit code=1 My installed.db shows gnuplot-X11 gnuplot-X11-5.4.1-1.tar.bz2 1 gnuplot-base gnuplot-base-5.4.1-1.tar.bz2 0 for both 32 and 64 bit setups. Previously to this update, no such messages. Any ideas? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Starting xterm as a DOS Command Prompt one-liner
This one-line DOS command to start an xterm terminal: D:\cygwin> bin\run bin\XWin -clipboard -nolock -multiwindow 2> nul & timeout 4 > nul 2> nul & bin\xterm -display :0.0 2> nul & bin\kill -KILL -- -1 (broken here after each "&" for clarity of presentation only) works, and is a neat and convenient alternative to starting xterm at the bash or mintty prompt with the single line $ /bin/xinit /bin/xterm -- -nolock -multiwindow 2> /dev/null (The "> nul" phrases in all the above just suppress notifications.) Question 1: I find the timeout .. chunk necessary to give XWin enough time to load before the xterm .. chunk draws upon it. Is there a different conjunction to "&" that says "wait till this is enacted before moving on" (which is actually what I thought "&" did!)? Question 2: The final kill .. chunk only operates after the xterm terminal is closed, and its purpose is to kill XWin, which otherwise hangs about. Is there some other way of assuring that the un-needed XWin is killed, maybe (I dunno) by adding a qualifier to the initial "run XWin" chunk? Thank you! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock"
-Original Message- From: Cygwin On Behalf Of rt...@sciencetools.com Sent: 18 November 2020 22:03 To: cygwin@cygwin.com Subject: Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock" Hey everyone, SUPER long time Cygwin user, seldom need help, and my versions are all ancient now and I can't upgrade, I don't think. I'm on Windows 7 and am stuck there. Other version data follows. Everything had been working fine for years, then I had a system crash and on restart, this is the only error I can find. When run from the Cygwin shell command line, it goes like this: $ XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.19.2.0 OS: CYGWIN_NT-6.1 Okrasa 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.19.2-1 built 2017-03-09 XWin was started with the following command line: XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp (EE) Fatal server error: (EE) Could not create lock file in /tmp/.tX0-lock winDeinitMultiWindowWM - Noting shutdown in progress $ I tried with window IDs 1 and 2 instead of zero but these didn't work either. Later, while busy with other things, there was a power failure for the facility and when the power came back on, of course the system had rebooted so I tried again and got the same thing. ...Somehow early in my testing to get this going, without intentionally doing anything else, I noticed the error changed from "Could not create lock file in", to "Can't read lock file /tmp/.X0-lock". Looking for the directory previously mentioned, it wasn't there so I decided to try and create that directory. When I do that, the error goes back to "Could not create lockfile in". ... I wonder if I created it with the right ownership and permissions, so I tried several things with no success. ...I'm rather desperate to fix this as this feature has become a key tool for this particular system. Ideas? Help? Thanks, RT Also a long-time W7 user: try deleting everything X-relevant under /tmp/ (in my case .X11-unix/ and its contents) and then $ run XWin -clipboard -nolock -multiwindow I know, simpler than yours - but this has evolved over the years, replacing earlier more complex command lines which suddenly broke, usually after some relevant update. Any good? BUT NB I am Cygwin-current - what's your difficulty with updating? Fergus -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygwin-64 on W10-64 : the only game in town?
With W7 no longer supported, W10-32 supported but no longer provided on new machines (Microsoft states that, "Beginning with Windows 10, version 2004, all new Windows 10 systems will be required to use 64-bit builds and Microsoft will no longer release 32-bit builds for OEM distribution .. the weaker version of Windows 10 has several limitations, like capping out at 3.2GB of RAM and less stringent security measures") and the functionality of Cygwin-32 significantly downplayed on Cygwin's own Home page, that really does leave Cygwin-64 on W10-64 on 64-bit hardware as the sole recommended platform. Yes? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: postinstall: fontconfig abnormal exit
>> Fergus and Hamish, the problem you reported should be fixed with >> fontconfig 2.13.1-2 and libxml2-2.9.10-2. Yes: all good now. For me, anyway: I tried setup-x86.exe -P texlive-collection-latex -mn (i.e. just Base + TeX) which earlier caused the problem: no errors. Thank you! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: postinstall: fontconfig abnormal exit
> On 2020-09-10 04:57, Fergus Daly via Cygwin wrote:
> >>>> Sorry if this has been asked 4 million times already.
> >
> >>> $ head /etc/postinstall/{fontconfig_dtd,libxml2}.*
> >>==> /etc/postinstall/fontconfig_dtd.sh.done <==
> hmmm. i don't understand exactly what this thread is about, but i do know
> that on my latest fresh install of cygwin,
> the fontconfig_dtd install is claiming an error at the end.
> is this related to that ?
Exactly. On first setup and all subsequent updates this post-installation error
recurs.
The cure described depends on the presence of several files including one that
the script creates if necessary.
PS Before I enlisted help to cure this glitch "properly", I found it and its
recurrence sufficiently intrusive to become an annoyance.
Since nothing was obviously broken I guessed that nothing further would be
broken by artificially achieving the post-installation
sequence as follows:
$ mv /etc/postinstall/fontconfig_dtd.sh /etc/postinstall/fontconfig_dtd.sh.done
And so it transpired: nothing awful seemed to happen, or fail to happen, as a
consequence of this "fix"; and the error msg stopped.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: postinstall: fontconfig abnormal exit
>>> Sorry if this has been asked 4 million times already.
>> $ head /etc/postinstall/{fontconfig_dtd,libxml2}.*
>==> /etc/postinstall/fontconfig_dtd.sh.done <==
>> if [ -x /usr/bin/xmlcatalog ] ; then
> /usr/bin/xmlcatalog --noout --add "system" "fonts.dtd"
> /usr/share/xml/fontconfig/fonts.dtd /etc/xml/catalog
> fi
==>> /etc/postinstall/libxml2.sh.done <==
>> if test ! -f /etc/xml/catalog; then
> /bin/mkdir -p /etc/xml
> /usr/bin/xmlcatalog --noout --create /etc/xml/catalog
> fi
>> $ llgo /{etc/xml/,usr/bin/xml}catalog /usr/share/xml/fontconfig/fonts.dtd
> /etc/postinstall/{fontconfig_dtd,libxml2}.*
> Thank you!
Out of interest:
Is this something that would usually be achieved during setup, as in other
instances of
.sh -> .sh.done, but has just fallen off?
Or (say) would it be achieved if I appended some specific package using setup
-P?
Or .. .. ?
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: postinstall: fontconfig abnormal exit
> Greetings, Fergus Daly!
>> Sorry if this has been asked 4 million times already.
>> During postinstall, both at ground-zero installation and at every update
>> thereafter, and for both Cygwin-32 and -64,
>> (both using the appropriate setup-x86[_64].exe) I get:
>> running: {pathToCygwin}\bin\bash.exe --norc --noprofile
>> "/etc/postinstall/fontconfig_dtd.sh"
>> abnormal exit: exit code=2
>> Is there something that can be done to address this "error", if that is
>> what it is, or is it just a quirk of setup?
> Run the same command manually and see where it's failing.
> IIRC (as this has been raised before), the problem is that a certain
> file/directory not exists.
> Check the mailing list archive?
Thank you for this advice.
1
For a long time (years) I have included an empty file
/etc/X11/fontpath.d/thisisafile
in my architecture as a workaround to address some installation problem,
the nature of which I have completely forgotten.
Having incorporated this dummy file, I should then re-install some package,
but precisely which one I have regrettably also forgotten.
2
This kind suggestion came from Ken Brown. By a strange coincidence, less than a
week ago,
https://cygwin.com/pipermail/cygwin/2020-September/246128.html,
I lamented the lack of ease with which one may search this archive. I just
searched in a limited way
to try to discover the problem for which Ken's workaround provided the cure,
but without success.
3
I also just now added "fontconfig" to my setup using "setup -P fontconfig" and
then also ran the command
fc-cache -v
at the bash prompt, and whilst achieving a raft of checks, this has not
addressed the original postinstall error
message.
I did not really think it would, guessing that if the fontconfig package were
to successfully address such a
basic (and recurrent) fault, then it would necessarily have been included in
Base.
So: nil progress, but thank you for your suggestion.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: heic to jpg conversion
> The just uploaded ImageMagick 7 is able to convert > from heic to both jpg and png (and more I assume ..) > I also added libheif and libde265 needed for the job. All working well. THANK YOU! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: heic to jpg conversion
>> Does Cygwin include the capability to convert heic to jpg (or png or >> anything else Windows-readable)? >> I tried "convert" (previously all-powerful) but that does not work (in any >> obvious way, anyway). >> Thank you! > Works for me. What does `type convert` say? I have this: ~/tmp> type convert convert is /usr/bin/convert ~/tmp> ls -x L1a.heic L2a.heic ~/tmp> file * L1a.heic: ISO Media L2a.heic: ISO Media ~/tmp> convert L1a.heic L1a.jpg convert: no decode delegate for this image format `HEIC' @ error/constitute.c/ReadImage/560. convert: no images defined `L1a.jpg' @ error/convert.c/ConvertImageCommand/3258. (BTW, in the above dialogue, should ISO Media read IOS Media?) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Needing readline to build a local 64-bit exec
Of more than 640 *.c files incorporated into a locally-built executable, exactly one contains many references to readline, such as "#include ". The 32-bit build proceeds impeccably to completion: there is a subdirectory x86/release/readline in the Cygwin resource and a paragraph for @ readline in the file x86/setup.ini, albeit with "obsolete" qualifiers. However the 64-bit build fails at the compilation of the file containing the reference to readline: various *.h not found. There is a subdirectory x86_64/release/readline in the resource but it contains only subdirectories, not the root readline-7.*.tar.xz files. The file x86_64/setup.ini contains no paragraph for @ readline. I do not fully understand the interpretation or consequences of obsoletion, but this changed provision relating to readline is the key difference between x86/ and x86_64/. I tried supplementing the resource under x86_64/release/readline with the "missing" *.tar.xz files and editing x86_64/setup.ini to include the paragraph for @ readline, but this broke setup.ini.sig. (I use a constantly updated mirror on a local drive. It takes 62G but it's worth it.) It is clear (well, given my limited understanding of the handling of obsoleted files) that in some way the provision under x86/release/readline and its referencing in x86/setup.ini remains critical to the successful build of the 32-bit executable, and the lack of provision under x86_64/release/readline and omission from x86_64/setup.ini is critical to the failed build. It seems to be located, picked up and used, despite its obsolete status? Can it be recovered into the x86_64 provision? Or can somebody who understands it better please explain the discrepancy in x86 and x86_64 provision that triggers the contrasting success and failure for 32-bit and 64-bit version build attempts. And, even better, how to achieve 64-bit success? Thank you! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
xterm stackdump
Lately I have been experiencing an xterm stackdump with varying triggers but all leading to a forced exit. Here is typical output. Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at eip=0045D5EF eax=0092 ebx=80080300 ecx= edx= esi=800D4C88 edi= ebp=0004 esp=006BC820 program=D:\console32\bin\xterm.exe, pid 1661, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args ~> Identical problem on Windows 10 AND Windows 7. (And that really is unusual. Most times a problem on W10 is not mimicked on the ultra-robust W7 platform.) Using cygwin1.dll v.3.1.6 and up-to-datest versions of xinit, xterm, gnuplot, etc. I can provide output from cygcheck -srv but the file is 1600 lines long and 98K? Not sure if this is useful / welcome - or how best to transmit it, if it is. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Setting appearance in bash / mintty
This is a bash question, but it is posed only because I am experiencing a lack of parallel alignment between bash and mintty in Cygwin. Hope OK to ask. The file /etc/minttyrc [or equivalent] [or R-click in the mintty console] can be used to set FG and BG colours, font style and size. When using mintty, it picks up all of echo -n $'\e]4; 3;255, 0, 0\a' echo -n $'\e]4; 6;139, 69, 19\a' echo -n $'\e]4;10; 0,127, 0\a' echo -n $'\e]4;12; 0, 0,255\a' echo -n $'\e]4;14;127, 0, 0\a' in /etc/bash.bashrc [or equivalent] so that ls shows directories in blue, text files in black, executables in green, links in dark brown. I daresay other fine and attractive distinctions are available. Thus the full working appearance, within mintty, may be set to the user's preference. For various reasons I have reverted to a bash shell*. R-click -> Properties to set FG, BG, font, placement, etc. But the settings above in /etc/bash.bashrc seem to be missed, or maybe interpreted differently. If missed, can anybody dictate where I should set them? If interpreted differently, can anybody point me to a recipe book for bash appearance? Thank you. * Some odd behaviours in mintty, not mimicked in bash or xterm, when calling a non-Cygwin external (which admittedly could be the source of the problem). If/when I can trigger these behaviours entirely within Cygwin, I shall try to describe them here. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Current setup timestamp 1590343308
>> It looks to me that /etc/setup/timestamp is updated by the last successful
>> setup
>> (upgrade?) run, and contains a copy of the selected mirror's setup.ini
>> setup_timestamp field as of the last successful setup (upgrade?) run, a few
>> hours earlier than the last successful setup (upgrade?) run.
Thank you for this.
I can't really think of anything to say other than repeat my observation,
today, of altered practice.
Since as long as I can remember (and I mean - a matter of years) a successful
upgrade of Cygwin32
(implementing the current version of setup-x86.exe currently 2.904
and pulling in the latest version of setup.ini found at {source}/Cygwin/x86/)
has concluded with
(i) a glitch-free accounting in /var/log/setup.log(.full), together with
(ii) a revision of the file /etc/setup/timestamp
which reflects the timestamp line in the aforementioned setup.ini file.
(And other things too, quite apart from any updates to the Cygwin provision -
e.g. an updated /etc/setup/installed.db file.)
What I have observed, twice now (earlier today using setup.ini incorporating
timestamp 1590343308 and now using the latest setup.ini incorporating timestamp
1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not
updated - and if it isn't there at all, it is not created.
Maybe this does not matter. The file is not referred to during any upgrade
session (or not obviously - I think the contents of /etc/setup/installed.db
are what dictate any necessary upgrades to an individual user's Cygwin
provision) but it has been, for me at least, a useful rapid check of whether
"what I've got" matches "what is now available".
All I was trying to do was draw attention to (what I perceive to be) suddenly
altered practice, with no change to the setup executable that might have
explained it or caused it. So (a) is it a real change? (easily confirmed, or
not, by anybody with /etc/setup/timestamp reporting < 1590407755 then running
an upgrade, and seeing what happens to /etc/setup/timestamp); and (b) if so, is
it intended? or is it a trivial glitch introduced goodness-knows-how that can
be corrected; and (c) if intended, to provide what improvement? because it
seems to me a bad move.
Fergus
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Current setup timestamp 1590343308
-Original Message- From: marco atzeri [mailto:marco.atz...@gmail.com] Sent: 25 May 2020 13:13 To: Fergus Daly Cc: cygwin@cygwin.com Subject: Re: Current setup timestamp 1590343308 On Mon, May 25, 2020 at 2:08 PM Fergus Daly via Cygwin wrote: > > Current setup timestamp 1590343308 > does not seem to overwrite /etc/setup/timestamp accurately (or at all). > I think /etc/setup/installed.db is seen to as it should be. > Fergus > -- What exactly is your problem ? Be verbose we can NOT guess your thoughts. Unix time: seconds since Jan 01 1970. (UTC) https://www.unixtimestamp.com/index.php Sorry for lack of clarity. Cygwin32. Current installed timestamp 1590341902 (got from /etc/setup/timestamp). I noticed there's a newer setup.ini with timestamp 1590343308. So I ran setup-x86.exe. After a (presumed) successful run I noticed however, that the file /etc/setup/timestamp had not altered. "Presumed successful run" because the file /etc/setup/installed.db had a new, current, timestamp. Fergus (I deleted /etc/setup/timestamp and re-running setup-x86.exe to see whether any self-correcting behaviour would ensue. The file was not recovered.) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
