[ANNOUNCEMENT] texinfo 7.0.3-1
The following packages have been uploaded to the Cygwin distribution: * texinfo-7.0.3-1 * texinfo-tex-7.0.3-1 * info-7.0.3-1 Texinfo is a documentation system that uses a single source file to produce output in a number of formats, both online and printed (HTML, PDF, DVI, Info, DocBook, LaTeX, EPUB 3, etc.). This is an update to the latest upstream release. It is a minor bugfix release. See https://lists.gnu.org/archive/html/bug-texinfo/2023-03/msg00087.html for a list of changes since the previous release. Cygwin packaging The info package contains the standalone info viewer as well as the install-info program. The texinfo package contains everything else except support for the printable output formats (such as pdf). The texinfo-tex package supplies the latter. In particular, /usr/bin/texi2any is in the texinfo package, but the command texi2any --pdf' won't work unless you install texinfo-tex. Ken -- 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
texinfo 7.0.3-1
The following packages have been uploaded to the Cygwin distribution: * texinfo-7.0.3-1 * texinfo-tex-7.0.3-1 * info-7.0.3-1 Texinfo is a documentation system that uses a single source file to produce output in a number of formats, both online and printed (HTML, PDF, DVI, Info, DocBook, LaTeX, EPUB 3, etc.). This is an update to the latest upstream release. It is a minor bugfix release. See https://lists.gnu.org/archive/html/bug-texinfo/2023-03/msg00087.html for a list of changes since the previous release. Cygwin packaging The info package contains the standalone info viewer as well as the install-info program. The texinfo package contains everything else except support for the printable output formats (such as pdf). The texinfo-tex package supplies the latter. In particular, /usr/bin/texi2any is in the texinfo package, but the command texi2any --pdf' won't work unless you install texinfo-tex. Ken
harfbuzz 7.1.0-1
The following packages have been uploaded to the Cygwin distribution: * harfbuzz-7.1.0-1 * libharfbuzz0-7.1.0-1 * libharfbuzz-devel-7.1.0-1 * libharfbuzz-gobject0-7.1.0-1 * libharfbuzz-gobject-devel-7.1.0-1 * libharfbuzz-subset0-7.1.0-1 * libharfbuzz-subset-devel-7.1.0-1 * libharfbuzz-icu0-7.1.0-1 * libharfbuzz-icu-devel-7.1.0-1 * libharfbuzz-cairo0-7.1.0-1 * libharfbuzz-cairo-devel-7.1.0-1 * girepository-HarfBuzz0.0-7.1.0-1 HarfBuzz is an OpenType text shaping engine. This is an update to the latest upstream release. Ken
[ANNOUNCEMENT] harfbuzz 7.1.0-1
The following packages have been uploaded to the Cygwin distribution: * harfbuzz-7.1.0-1 * libharfbuzz0-7.1.0-1 * libharfbuzz-devel-7.1.0-1 * libharfbuzz-gobject0-7.1.0-1 * libharfbuzz-gobject-devel-7.1.0-1 * libharfbuzz-subset0-7.1.0-1 * libharfbuzz-subset-devel-7.1.0-1 * libharfbuzz-icu0-7.1.0-1 * libharfbuzz-icu-devel-7.1.0-1 * libharfbuzz-cairo0-7.1.0-1 * libharfbuzz-cairo-devel-7.1.0-1 * girepository-HarfBuzz0.0-7.1.0-1 HarfBuzz is an OpenType text shaping engine. This is an update to the latest upstream release. Ken -- 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: [PATCH cygport] lib/src_postinst.cygpart: parallelize __prepstrip
On 30/03/2023 20:49, Achim Gratz via Cygwin-apps wrote:
Jon Turney via Cygwin-apps writes:
On 26/03/2023 19:12, Jon Turney via Cygwin-apps wrote:
- usr/lib/gcc/*/lib*|usr/lib/gcc/*/*.o)
+ usr/lib/gcc/*/*.o)
Why this change?
It looks like a mistake that I didn't catch.
+ local nproc=$(nproc)
This limit should probably be taken from the --jobs command line
parameter, if specified
Yes, although one could argue that it should actually oversubscribe
since the CPU load per process is expected to be significantly less than
100% per process.
Looking at this a bit more, a couple of perhaps more serious problems:
* The parallel invocations of __prepstrip_one are all appending to
${T}/.dbgsrc.out
I don't see what makes that safe against interleaving of the output.
Line-buffering and the line being shorter than the buffer should.
and what causes line-buffering be on?
It's probably possible to have each instance write to a separate file
and collect them together in __prepdebugsrc
Nah, if you insist on making it _really_ safe regardless of line lenght
and buffer size vagaries I'll do file locking on the output file.
If you lock the file while objdump is running, you've basically
serialized this again...
* This patch causes several failures in the testsuite, e.g. with
autotools/c testcase.
Which?
The full list of failing tests is:
21/54 autotools/c FAIL63.16s exit status 1
22/54 autotools/gnome FAIL 170.49s exit status 1
23/54 autotools/gtkmm FAIL 177.54s exit status 1
24/54 autotools/mate FAIL 131.24s exit status 1
25/54 autotools/xfce FAIL85.64s exit status 1
26/54 cmake/c FAIL13.75s exit status 1
28/54 cmake/qt5 FAIL94.44s exit status 1
37/54 lua/all FAIL10.92s exit status 1
38/54 httpd/apxs FAIL31.98s exit status 1
44/54 perl/Module-Build FAIL16.09s exit status 1
46/54 php/peclFAIL48.13s exit status 1
49/54 qmake/qt5 FAIL46.84s exit status 1
On a brief attempt at debugging, it this looks like it's due to not
waiting for all the __prepstrip_one to complete before moving on, but
I think the final wait should prevent that, so idk.
I've seen an indication that the final wait doesn't work, but that is
fixable by a sleep apparently. Did You see that the process number
limiting doesn't work?
No, but I haven't been trying to test it.
I'm not clear that invoking 'jobs', is actually doing anything, if
job-control is turned off in a non-interactive shell?
No, "jobs" shouldn't do anything, but wait should still work I think
(the manpage talks about jobs, but it really means "children"). But
then again, a bit of googling tells me that the bashism "wait -n"
actually needs job control to be enabled, natch.
Re: [PATCH cygport] lib/src_postinst.cygpart: parallelize __prepstrip
Jon Turney via Cygwin-apps writes:
> On 26/03/2023 19:12, Jon Turney via Cygwin-apps wrote:
>>> - usr/lib/gcc/*/lib*|usr/lib/gcc/*/*.o)
>>> + usr/lib/gcc/*/*.o)
>> Why this change?
It looks like a mistake that I didn't catch.
>>
>>> + local nproc=$(nproc)
>> This limit should probably be taken from the --jobs command line
>> parameter, if specified
Yes, although one could argue that it should actually oversubscribe
since the CPU load per process is expected to be significantly less than
100% per process.
> Looking at this a bit more, a couple of perhaps more serious problems:
>
> * The parallel invocations of __prepstrip_one are all appending to
> ${T}/.dbgsrc.out
>
> I don't see what makes that safe against interleaving of the output.
Line-buffering and the line being shorter than the buffer should.
> It's probably possible to have each instance write to a separate file
> and collect them together in __prepdebugsrc
Nah, if you insist on making it _really_ safe regardless of line lenght
and buffer size vagaries I'll do file locking on the output file.
> * This patch causes several failures in the testsuite, e.g. with
> autotools/c testcase.
Which?
> On a brief attempt at debugging, it this looks like it's due to not
> waiting for all the __prepstrip_one to complete before moving on, but
> I think the final wait should prevent that, so idk.
I've seen an indication that the final wait doesn't work, but that is
fixable by a sleep apparently. Did You see that the process number
limiting doesn't work?
> I'm not clear that invoking 'jobs', is actually doing anything, if
> job-control is turned off in a non-interactive shell?
No, "jobs" shouldn't do anything, but wait should still work I think
(the manpage talks about jobs, but it really means "children"). But
then again, a bit of googling tells me that the bashism "wait -n"
actually needs job control to be enabled, natch.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: cygwin does not run quietly if --quiet-mode given on commandline
Am Do., 30.März.2023 um 18:24:20 schrieb Brian Inglis via Cygwin:
On 2023-03-30 08:23, Thomas Schweikle via Cygwin wrote:
starting cygwin setup-x86_64.exe with parameters:
setup-x86_64.exe ^
--verbose ^
--delete-orphans ^
--local-package-dir "C:\WINDOWS\ccmcache\4r\installdata" ^
--no-desktop ^
--proxy "" ^
--root "C:\cygwin" ^
--upgrade-also ^
--quiet-mode ^
--wait
It does not matter if "--quiet-mode" is given or not: in all cases
cygwin setup opens a window showing setup progress and the real bad
thing: allows the user on whom desktop the window is shown to stop the
upgrade!
I need a really unattended upgrade with some log written what setup
had done.
And is it a bug? As far as I could find "--quiet-mode" means no
window, no messages at all - am I wrong and all those interpreting it
the same way?
Might want to try dropping:
> --verbose ^
> --delete-orphans ^
> --wait
If i drop "--verbose" it only does less output to console.
"--delete-orphans" is supposed to delete packages not found on servers
any more. It is sometimes needed to have setup update cygwin without
hassles. But I am aware of it removing more than necessary sometimes.
"--wait" is necessary. If it is not given, setup will immediate return,
triggering following routines -- bad if some rely on cygwin upgraded and
functional.
What I found after trying: the only way is to make this setup window
hidden. It is opened in all cases. It is opened even before given
options are evaluated. Thus "--quiet" is nearly useless: the window is
open before setup evaluates not to open a window.
I was able to get what i wanted mostly with:
$SetupOpts = @{
FilePath = $isf
ArgumentList = @(
"--verbose",
"--delete-orphans",
"--upgrade-also",
"--quiet-mode",
"--wait",
"--no-desktop",
"--local-package-dir", "`"C:\WINDOWS\ccmcache\4r\installdata`"",
"--proxy", "`"`"",
"--root", "`"C:\cygwin`""
)
WindowStyle = "Hidden"
PassThru = $True
Wait = $True
RedirectStandardOutput = "$isl"
RedirectStandardError = "$ise"
}
$proc = Start-Process @SetupOpts
It behaves slightly different if "--wait" is only flagged for setup and
not the calling process "Wait = $True". If "--wait" is given, but not
"Wait = $True" it returns before final cleanup is done (PowerShell calls
a hidden cmd.exe, which in tune calls setup-x86_64.exe). In case both
waits are given it returns after everything is done.
If only "Wait = $True" was given it returns nearly immediately -- setup
has not finished then.
or, from cmd.exe
setup-x86_64.exe ^
--verbose ^
--delete-orphans ^
--local-package-dir "C:\WINDOWS\ccmcache\4r\installdata" ^
--no-desktop ^
--proxy "" ^
--package-manager ^
--root "C:\cygwin" ^
--upgrade-also ^
--wait
and add -O|--only-site -s|--site /url/ -s|--site ... closest/fastest
Found this only a good idea if mirrors where reliable. But they are not.
If one goes down you'll need a backup. Or you've got your own local
mirror. Not too difficult to set up, but takes a lot of storage. Maybe
in near future.
It is way to often the selected mirror is out of order. Giving --site or
--only-site is then a point upgrades/installs fail.
mirrors as long as it is/they are active in
https://cygwin.com/mirrors.lst - probably best if they are different
protocols at the same mirror (handles cert expiry) and/or reliable backup.
--
Thomas
OpenPGP_0x27AE2304B4974851.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
--
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: cygwin does not run quietly if --quiet-mode given on commandline
On 2023-03-30 08:23, Thomas Schweikle via Cygwin wrote: starting cygwin setup-x86_64.exe with parameters: setup-x86_64.exe ^ --verbose ^ --delete-orphans ^ --local-package-dir "C:\WINDOWS\ccmcache\4r\installdata" ^ --no-desktop ^ --proxy "" ^ --root "C:\cygwin" ^ --upgrade-also ^ --quiet-mode ^ --wait It does not matter if "--quiet-mode" is given or not: in all cases cygwin setup opens a window showing setup progress and the real bad thing: allows the user on whom desktop the window is shown to stop the upgrade! I need a really unattended upgrade with some log written what setup had done. And is it a bug? As far as I could find "--quiet-mode" means no window, no messages at all - am I wrong and all those interpreting it the same way? Might want to try dropping: >--verbose ^ >--delete-orphans ^ >--wait and add -O|--only-site -s|--site /url/ -s|--site ... closest/fastest mirrors as long as it is/they are active in https://cygwin.com/mirrors.lst - probably best if they are different protocols at the same mirror (handles cert expiry) and/or reliable backup. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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 does not run quietly if --quiet-mode given on commandline
Hi! starting cygwin setup-x86_64.exe with parameters: setup-x86_64.exe ^ --verbose ^ --delete-orphans ^ --local-package-dir "C:\WINDOWS\ccmcache\4r\installdata" ^ --no-desktop ^ --proxy "" ^ --root "C:\cygwin" ^ --upgrade-also ^ --quiet-mode ^ --wait It does not matter if "--quiet-mode" is given or not: in all cases cygwin setup opens a window showing setup progress and the real bad thing: allows the user on whom desktop the window is shown to stop the upgrade! I need a really unattended upgrade with some log written what setup had done. And is it a bug? As far as I could find "--quiet-mode" means no window, no messages at all - am I wrong and all those interpreting it the same way? -- Thomas OpenPGP_0x27AE2304B4974851.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- 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
