Re: [ITA] ocaml-bigarray-compat 1.1.0, ocaml-ctypes 0.23.0 [ITP] ocaml-csexp 1.5.2

William Hu via Cygwin-apps writes: > src_install() { > cd ${S} > ocaml_dune_install > # temporary workaround to remove absolute paths in dune-package > cd ${D}/usr/lib/ocaml/bigarray-compat > sed -E -i 's|/cygdrive/d/a/scallywag/.*/([^/]+)|\1|g' dune-package > } That

Re: OT: It's never done *this* before

Mark Geisert via Cygwin-apps writes: > In the midst of yet another long, tedious Qt5-Base build, this happened: > > g++ -c -fno-keep-inline-dllexport -D_GNU_SOURCE -pipe -ggdb -O2 -pipe > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=3 > -fstack-protector-strong --param=ssp-buffer-size=4 -Wer

Re: [ITA] llvm

Takashi Yano via Cygwin-apps writes: > Anyway I'll revise the cygport file. Any suggenstions > will be appreciated. I've looked at the cygport in more detail, comments below. Indentation is inconsistent. I personally prefer not to use tabs and reduce indentation to four. The bootstrapping shou

Re: [ITA] llvm

Takashi Yano via Cygwin-apps writes: > On Sun, 04 May 2025 08:59:00 +0200 > I'm very sorry, but I wish you had told me that when I issued > the ITA. Anyway I'll revise the cygport file. Any suggenstions > will be appreciated. I assumed you were well aware of the earlier thread from almost two year

Re: [ITA] llvm

Takashi Yano via Cygwin-apps writes: > I pushed current working files in the packages > llvm Thereby obliterating all the work I'd done two years ago in getting the packaging halfway up to speed and making it a mess again. Not impressed… :-( Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuro

Re: llvm/clang packages

Takashi Yano via Cygwin-apps writes: > Now I am trying to build llvm for cygwin. For now, it fails with > ld: error: export ordinal too large: x > in dll linkage. > > If you could give me a suggestion, I would greatly appreciate it. That usually happens if the linker tries to export all symbo

Re: [ITA] nano

Philippe Baril Lecavalier via Cygwin-apps writes: > Thank you for the clarifications. I thought there could be something > with rsync and cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org, but it might > be a nuisance to > administer properly, to prevent some crazy slurping "by mistake" or > read acc

cygport 0.37.0 needs a new calm release

> Our package distribution pipeline should already be prepared to ingest > filenames of this form, but if you are doing some custom handling of > your packages, some adjustments might be needed. That might be the case on Sourceware, but the currently released official calm package from more than

Re: GCL and dependencies on cygwin

Camm Maguire via Cygwin-apps writes: > Greetings -- just checking, the url I should use is: > ssh:cygwin`at`cygwin.com:/git/cygwin-packages/playground.git Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAtta

Re: sqlite3 update?

Jan Nijtmans via Cygwin-apps writes: > Does anyone know what could be the problem? Sourceware is getting hit with a lot of abusive traffic and due to this (or an unrelated reason) SSH connections are getting dropped after the initial key exchange, before the actual data transfer starts. Keep tryi

Re: List of packages installed by Cygwin setup.exe by default?

Brian Inglis via Cygwin-apps writes: […] How about trimming your replies? >> BTW, the current disk space used by the above packages (4992 files, >> 581 directories): >> 148 MiB without compression, >> 93 MiB with NTFS compression (may result in significant file fragmentation), >> 63 MiB with Comp

Re: [ITA] astyle

Michael Cook via Cygwin-apps writes: > +SRC_URI=" > https://gitlab.com/saalen/astyle/-/archive/3.6.6/astyle-3.6.6.tar.gz"; https://gitlab.com/saalen/${PN}/-/archive/${PV}/${P}.tar.gz"; will let you change versions without having to find it in each and every string. > +SRC_DIR=astyle-3.6.6 If yo

Re: [cygport] enabling a replacement for "objdump -d -l"

Marco Atzeri via Cygwin-apps writes: > Am I wrong or this patch was never merged/updated ? Well, Jon wanted changes and I haven't had time to implement them. You can always get it from https://repo.or.cz/w/cygport/rpm-style.git if you don't mind that it's not upstreamed yet. Regards, Achim. --

Re: [ITA] c-ares 1.16.1 - Curl Asynchronous RESolver library

Brian Inglis via Cygwin-apps writes: > I have noticed when there is only a single exe/dll in a package, > debuginfo does not seem to be created! Nope, that's not it, the library or object files just don't contain any debuginfo. And running the compile in verbose mode that indeed '-g0' ist set, so

Re: [ITA] c-ares 1.16.1 - Curl Asynchronous RESolver library

Brian Inglis via Cygwin-apps writes: > Comparison of previous against latest version config feature options. > I will consider where I can run perhaps a script based on: Just in case: the debuginfo package was missing from your upload. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron micro

Re: Update stable release of mingw64-x86_64-openssl

David Allsopp via Cygwin-apps writes: > The "current" release marked as stable for mingw64-x86_64-openssl is > 1.0.2+za-1. Please could the latest stable be changed at least to > 1.1.1w-0.1, or preferably to a 3.x release. I haven't made up my mind whether to just update to v3 LTS or abandon this

Re: [ITA] zint 2.13.0 - multi-format barcode encoder

Brian Inglis via Cygwin-apps writes: > most other test issues appear to be what they interpret as file access > writing to a file they make readonly, but looks like errno 10 - ECHILD > 10 No child processes? That sort of test usually fails when run with a user token that has backup/restore privile

Re: [Attn. MAINTAINERS] Heads up: Perl 5.40.0 is imminent

Ken Brown via Cygwin-apps writes: > Yes, it really does need to depend on perl; it runs much slower otherwise. That's what I meant: although no functionality is lost, the performance suffers. So you would not normally skip the dependency, but it's possible if only to bootstrap. > Yes, that would

Re: [Attn. MAINTAINERS] Heads up: Perl 5.40.0 is imminent

Ken Brown via Cygwin-apps writes: > Yes, it really does need to depend on perl; it runs much slower otherwise. That's what I meant: although no functionality is lost, the performance suffers. So you would not normally skip the dependency, but it's possible if only to bootstrap. > Yes, that would

Re: [Attn. MAINTAINERS] Heads up: Perl 5.40.0 is imminent

Ken Brown via Cygwin-apps writes: > texinfo also depends on perl5_036. I was almost saying it doesn't need to, but it seems to come with it's own XS module that gets installed into a non-standard path (which is why I didn't pick it up before). It might still not really need it iff there is a PP f

[Attn. MAINTAINERS] Heads up: Perl 5.40.0 is imminent

I'm going to release Perl 5.40.0 to Cygwin in a few days. I've skipped 5.38 in order to update only every second year (which I've done since the 5.22 release). I haven't seen any trouble in my own Perl distribution packages from the update even though there are lots of them that haven't been up

Re: [cygport] Avoid the package's provides appearing in requires

Jon Turney via Cygwin-apps writes: >> You can just add any such package or provide names twice at the >> beginning of the echo invocation, as any package that appears more than >> once in the resulting output is not recorded as a dependency. > > Uh, what, really? > > I can't spot the mechanism in _

Re: [ATTN] ca-certificates-letsencrypt maintainer

Brian Inglis via Cygwin-apps writes: >> Re-installed last ca-certificates-letencrypt package and cygport >> announce and git send-email are working again. Then keep it installed one or two months longer, but I will not revive that package. The original problem with the R3 cross-signed through X3

[cygport] Avoid the package's provides appearing in requires

This commit introduces a bug. It will not work for packages that have multiple provides or extra whitespace around the provides name as that will produce a bogus regex for grep. You can just add any such package or provide names twice at the beginning of the echo invocation, as any package that

Re: Attn: libgpg-error maintainer

Marco Atzeri via Cygwin-apps writes: > it seems it was much simpler. > For some strange reason the HAVE_WEAK_SYMBOLS was defined. Which would mean that the sources ship with a very outdated version of GNUlib… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>

Re: Build machines

ASSI via Cygwin-apps writes: >> I misremembered the code names. The direct successor to the 7735HS >> (Rembrandt Refresh) are the 7840HS / 7940HS (Phoenix-H at 8 cores and >> upgraded to 4nm Zen4/RDNA3 and about 15% better performance per Watt); >> the upcoming 16 core is

Re: [ITP] perl-Parse-Yapp-1.21

Ziemowit Laski via Cygwin-apps writes: > This is a straightforward port, akin to other Perl packages. The question is: what do you need it for and why should it get packaged in Cygwin? […] > I can be the maintainer-at-large for this if you'd like. I'd rather not have separate maintenance of rand

Re: [PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify

Brian Inglis via Cygwin-apps writes: > Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly, > single operation gpg verification helper designed for use in scripts > instead of gpg2 --verify: see 'info gpg2 helper gpgv' NAK. This tool doesn't check for expired keys and also searc

Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

Brian Inglis via Cygwin-apps writes: > Some package upstreams offer only checksums, for example .sha512sum, > .sha256sum, > for verification rather than gpg signatures, for example .asc, .sig, .sign, > etc; > use these checksum files when provided in a similar manner to gpg signatures; > these fi

Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS

Christian Franke via Cygwin-apps writes: > _FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc > 13.2.1 test release. > > Silently falls back to level 2 if level 3 is unsupported (older > headers or gcc) or to level 0 if unsupported at all (C++, clang). Well, if only that was the

Re: [cygport] enabling a replacement for "objdump -d -l"

Jon Turney via Cygwin-apps writes: > But I'm not being oblique here. I really do want comments. Well, adding comments or proper POD is about the same effort, so I'd tend towards the latter. > I'm not sure what's so astounding about the suggestion that a fifty > line script should have some commen

Re: [cygport] enabling a replacement for "objdump -d -l"

Jon Turney via Cygwin-apps writes: > Thanks, this is great! You're welcome. > Please, please make a patch with git format-patch, which I can then > just apply. You can always just pull it in from my repo… when it's ready. > Fifty lines of perl with no comments! This is just line noise to me > u

[ATTN. MAINTAINER] units

The postinstall script for units downloads currency exchange rates and hangs up for a long time if it can't access the server (if it ever finishes, I've killed the process on all machines where I've seen this). Can this part please either be removed entirely or moved into a sub-package that doen'

Re: [cygport] enabling a replacement for "objdump -d -l"

Marco Atzeri via Cygwin-apps writes: > if works should not be the default ? Let's start with interested parties giving it a spin, shall we? ONce configured into your .cygportrc it essentially is the default for all your builds. > Reducing that time is very interesting for the big stuff That's t

[cygport] enabling a replacement for "objdump -d -l"

Cygport uses "objdump -d -l" to extract the list of source files that need to be copied into the debuginfo package. This operation triggers some O(N²) or even higher complexity and in addition has been getting slower in recent binutils releases due to more and more information being put into the

Re: Tmux crashes on copy

Jon Turney via Cygwin-apps writes: > I don't use tmux, so if I were to just bump the version, I'd just be > deploying the updated package without any testing, which is something > I try to avoid doing. I do, I just built it locally (with the dud patch that doesn't actually fix control mode backed

Re: [ITP] pigz 2.8

Marco Atzeri via Cygwin-apps writes: > BUILD_REQUIRES="zlib-devel ncompress gzip" Why is ncompress a build dependency? Please remove if possible. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stro

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: > now updated to 15.0.7 I've built it and activated the tests, which seem to have roughly the same results as 9.0.1, so that looks good. For 9.0.1 I think I've finally got it to build almost cleanly. I still need to ignore some fallout from documentation bitrot, but

Re: [ITA] llvm

徐持恒 Xu Chiheng via Cygwin-apps writes: > Without process_install_dir_bin_symlinks, you can't get an installable > package *.xz. You have not explained what exactly the issue is you're trying to solve. If you get links to outside DESTDIR then the install targets are broken and you need to fix the M

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: > On Thursday, 14 December 2023 at 2:42 PM, 小さい猫 via Cygwin-apps > wrote: > >> By the way, just now I have updated these cygports to 13.0.1 LLVM release in >> my GitHub repo. > > now updated to 14.0.5 THanks for letting us know. I can't promise, but I'll try to hav

Re: [ITA] llvm

ASSI via Cygwin-apps writes: > That's mildly confusing to me… anyway, I'll try to build LLVM from this > (maybe this weekend). I expect there will need to be further changes to > the packaging, given how far out of date the cygport you based it on is. LLVM 16 does indeed bu

Re: [ITA] llvm

徐持恒 Xu Chiheng via Cygwin-apps writes: > I'd like to adopt the llvm package. > I have build scripts and patches, and .cygport files at > https://github.com/xu-chiheng/Note. That's mildly confusing to me… anyway, I'll try to build LLVM from this (maybe this weekend). I expect there will need to b

Re: Unmaintained packages in base package set

Takashi Yano via Cygwin-apps writes: > I found the cause. DISTCLEANFILES in original cygport file removes them. > Now I can successfully build libatk1.0-doc. Thanks! No, that means the tarball includes files that should get re-built, but apparently you somehow failed to do that. Regards, Achim.

[Attn. MAINTAINER] gpg2

Hi Marco, Since the last update gpg2 segfaults, rolling back step by step points at libgpg-error as the culprit. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWav

Re: [NMU] inkscape 0.92.3-2 (Test)

Mark Geisert via Cygwin-apps writes: > I've uploaded a non-maintainer re-build of the existing inkscape > 0.92.3. This attempts to work around a problem with the current > inkscape reported to exit with 127 error code (missing DLL). This > build was produced with gcc-g++ 7.4 while the current buil

Re: cygport upgrade to use gnupg2/gpg2 if available

Brian Inglis via Cygwin-apps writes: > After applying the attached patches, which add support for the newer > gpg2 from gnupg2 if installed, the attached log second chunk shows the > new keys verified by gpg2 added to lib/src_prep.cygpart > ___gpg_verify(). > > Similar code has been added to lib/pk

Re: [PATCH cygport] git.cygclass: Suppress the depth option

Jon Turney via Cygwin-apps writes: > This could just be named something a little shorter, like > "GIT_URI_NO_SMART_TRANSPORT", since it's really a property of the > URI's host? > > But I wonder if wouldn't just be better to try with --depth and then > fallback to without it, if that fails (especial

Re: [cygport RFC PATCH 1/1] Run install functions separately

Adam Dinwoodie via Cygwin-apps writes: > I think you've misunderstood how `set -e` works. Likely, for some definition of "works". I'm the last person to understand bash, really. […] > The issue is that the && chain disables `set -e` for anything other than > the final command in the chain, *incl

Re: [cygport RFC PATCH 1/1] Run install functions separately

Adam Dinwoodie via Cygwin-apps writes: > When running as part of a `&&` chain, Bash's `set -e` behaviour is > suppressed entirely, which means calls that produce non-zero error codes > will be ignored if they're called inside functions that are part of such > a chain. > > To avoid silent failures f

[Pending NMU] mysql, mariadb-connector-c

Due to a problem with a new major version of perl-DBD-mysql (trhat hasn't been resolved and will have to wait for an upstream fix) I've been looking at re-building those two packages. The updated packaging is available in the playground branches: https://cygwin.com/cgit/cygwin-packages/mysql/co

Re: Updated: mingw64-x86_64-/nghttp2 libnghttp2_14/-devel 1.57

Cygwin nghttp2 Maintainer via Cygwin-announce writes: > * libnghttp2_14 1.57 This library pulls in a lot of build dependencies, but then does not have any actual dependencies on anything. You seem to be building a static library? If so, please stop doing that. Regards, Ach

Re: [Attn. Maintainers] OpenSSL v3

ASSI via Cygwin-apps writes: > Support for OpenSSL LTS v1.1.1 is ending on September 11. > > With the next release from upstream I will make OpenSSL LTS v3.0 current > on Cygwin. I've just rebuilt OpenSSH locally using the 3.0.10 test > package without any problems and unless

Re: [PATCH setup] Enable large files (>2 GiB)

Jon Turney via Cygwin-apps writes: > This seems right, and works for installing qt5-webkit-debuginfo when I > gave it a quick try (seems to work on i686 as well). Oh good to know, so I don't need to boot up the machine that still has the 32bit installation for testing. > (Note that if you have an

[PATCH setup] Enable large files (>2 GiB)

This fixes the issue reported here: https://cygwin.com/pipermail/cygwin/2023-October/254562.html Not tested on 32bit. --8<---cut here---start->8--- diff --git a/Makefile.am b/Makefile.am index 3bd83dc4..70bfd032 100644 --- a/Makefile.am +++ b/Makefile.am @@

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

William Hu via Cygwin-apps writes: > Hi All, > > Re OCaml compilers: I should be able to package OCaml 4.14.1 (and hopefully > an > alpha version of 5.1.0 as well) for Cygwin in the coming weeks. OCaml 5.0.0 > temporarily dropped Cygwin support so the Cygwin versions will of course skip > that

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

William Hu via Cygwin-apps writes: > On Wednesday, August 30th, 2023, ASSI wrote: >> NOt immediately, but it makes me wonder if there's other such leakage. >> I have not found a (text) file that stores this information in the >> installed package, so it seems that the information is compiled in >>

Re: The correct manner to obsolete subpackage.

Takashi Yano via Cygwin-apps writes: > But, my case is > >> If the package is really being removed without any replacement, there >> are mechanisms to deal with that case, but that case should be really rare. > > this. pulseaudio package no longer provides esound and gconf, > however, these packag

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

William Hu via Cygwin-apps writes: > Just checked the file and I agree that CFLAGS looks a little funny - are > there any > other stupid flags/variables that you had in mind? NOt immediately, but it makes me wonder if there's other such leakage. I have not found a (text) file that stores this in

Re: what license is this?

Andrew Schulman via Cygwin-apps writes: > https://github.com/jqlang/jq/blob/master/COPYING OpenSUSE License:CC-BY-3.0 AND MIT Fedora License:MIT and ASL 2.0 and CC-BY and GPLv3 Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: >> - [ ] dtc (?) > > Ah sorry... that device tree compiler cygport repo in the github org > is not related to LLVM stuffs. just i happened to need it for building > something else and it's adapted from the old cygwinports-extras[1]. OK, I thought so already, but I wasn

Re: [PATCH cygport] Add initial support for SOURCE_DATE_EPOCH

Christian Franke via Cygwin-apps writes: > If the build-path changes, more files differ (cygcheck.exe, ldd.exe, > cygserver.exe) because __FILE__ is used and expands to an absolute > path name. This could be fixed by adding -fmacro-prefix and/or -ffile-prefix arguments. Regards, Achim. -- +<[Q+

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

ASSI via Cygwin-apps writes: > I've started a local llvm-revival branch… Progress, OCaml bindings are back again (I've not run the tests yet): --8<---cut here---start->8--- * OCaml Updates - [X] flexdll 0.39 ==> 0.43 + does not r

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: > i am not familiar with the ocaml stuffs, and i dont quite understand > what is the problem ur currently getting. Dune cannot be fully built because lwt.unix or one of it's dependencies is missing. I could built a bootstrapped package, but that later runs into troubl

Re: [PATCH cygport] Add initial support for SOURCE_DATE_EPOCH

Christian Franke via Cygwin-apps writes: > If binutils, gzip and tar also would support this, the patch would be > empty :-) GZip has -n though and GNU tar --mtime and --clamp-mtime, so why not use that? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wa

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: > On Monday, August 14th, 2023 at 12:50 AM, ASSI via Cygwin-apps > wrote: > >> I've started a local llvm-revival branch… I got sidetracked with OCaml, >> but that will need some more time and currently I have just disabled the >> OCa

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

ASSI via Cygwin-apps writes: > I've started a local llvm-revival branch… I got sidetracked with OCaml, > but that will need some more time and currently I have just disabled the > OCaml bindings in LLVM instead (not removed: this is controlled by a > variable in the script and an

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

I've started a local llvm-revival branch… I got sidetracked with OCaml, but that will need some more time and currently I have just disabled the OCaml bindings in LLVM instead (not removed: this is controlled by a variable in the script and another variable to control the LLVM target list). --8

[Attn. Maintainers] OpenSSL v3

Support for OpenSSL LTS v1.1.1 is ending on September 11. With the next release from upstream I will make OpenSSL LTS v3.0 current on Cygwin. I've just rebuilt OpenSSH locally using the 3.0.10 test package without any problems and unless your package has no current upstream I expect no problems

Re: [PATCH cygport] lib/src_prep.cygpart: Fix incorrect options passed to unzstd in unpack()

Jon Turney via Cygwin-apps writes: > Yes, I had managed to deduce that much. :) > > Providing a specific instance would save me having to find or invent > one, though. Sorry, I did not have one at hand, all such instances in my stack of packages are either uncompressed files or compressed archives

Re: [PATCH cygport] lib/src_prep.cygpart: Fix incorrect options passed to unzstd in unpack()

Yasutaka ATARASHI via Cygwin-apps writes: > Yeah, I also wonder why the --keep option is not used for .gz and .bz2. > Now, I recognized the reason. Thanks. > `unpack()` is expected to extract the files to the current working > directory regardless of the specified path of the input. Please see >

Re: [PATCH cygport] lib/src_prep.cygpart: Fix incorrect options passed to unzstd in unpack()

Jon Turney via Cygwin-apps writes: > Do you have an example of a cygport which fails without this fix, so I > can add a test for this? Anything with a SRC_URI or PATCH_URI that has .zst suffix but not .tar.zst should suffice. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Androm

Re: [PATCH cygport] lib/src_prep.cygpart: Fix incorrect options passed to unzstd in unpack()

yak_ex via Cygwin-apps writes: > `unpack()` invokes `unzstd` for a *.zst file as > `unzstd -qo file.zst` > Then, an error occurs as 'stdin is a console, aborting', > because the `-o` option is to specify an output file name. Indeed, sorry for that. > There are some choices to fix it. This patch a

Re: [RFC] parallelizing cygport test

ASSI via Cygwin-apps writes: > I've recently updated a few packages that do a serious amount of > compilation during test and it became painfully obvious that cygtest > does not run make with the "-j" option nor does it currently offer an > option to change that. > &

Re: chattr makes cygport slow

Jon Turney via Cygwin-apps writes: > Ok. I made a cygport 0.36.6 release with this change. Thanks. You haven't tagged that release on GitHub yet it seems. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional document

[RFC] parallelizing cygport test

I've recently updated a few packages that do a serious amount of compilation during test and it became painfully obvious that cygtest does not run make with the "-j" option nor does it currently offer an option to change that. Given the brittleness of some test suites it might be prudent to keep

Re: chattr makes cygport slow

Jon Turney via Cygwin-apps writes: > The warning (error if RESTRICT=case_insensitive) should occur for all > commands, not just prep. OK. > How about the attached. Looks promising. > Even then, it should only be modifying every directory, not every file. Run strace on "chattr -r +C ." and see

[ITA] uchardet

For the record: I have adopted the uchardet package, previously orphaned by Yaakov. 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: chattr makes cygport slow

Jon Turney via Cygwin-apps writes: > So, the idea here is that we try to ensure it's on, at least for the > working directory. That IMHO should only be done when the working directory is created, but not retroactively applied to an existing workdir. > Skipping it when 'finish' is used isn't right

Re: [ITP] italic-man

[I've had no time to look at this in detail and that will have to wait a bit more.] Thomas Wolff via Cygwin-apps writes: >>> would it actually make a difference whether the zp_ is a script of >>> italic-man or of man-db? I've also added a cygport file to the >>> repository so you can try the upd

Re: Build machines

Achim Gratz via Cygwin-apps writes: > I misremembered the code names. The direct successor to the 7735HS > (Rembrandt Refresh) are the 7840HS / 7940HS (Phoenix-H at 8 cores and > upgraded to 4nm Zen4/RDNA3 and about 15% better performance per Watt); > the upcoming 16 core is the 7945HX (Dragon Ran

Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

Marco Atzeri via Cygwin-apps writes: > are you planning to upload 5.36.1 as test ? No. > I will be on the road for 2 weeks in May and I will not be able to > update any package starting from 8th May I need to check another few hundred build logs this evening, then the release should be good to g

Re: [ITP] openh264 (2.3.1)

Takashi Yano via Cygwin-apps writes: > Thanks for the advice. I have revised the cygport file. You are getting the file and the hash from the same unprotected source. I was thinking you should put the hash into the cygport file and hence the postinstall script. Also note that the system doing the

Re: [ITP] openh264 (2.3.1)

Takashi Yano via Cygwin-apps writes: > - The libopenh264 package includes only /etc/postinstall > and /etc/preremove, which downloads/removes Cisco's dll > (binary) as well as license file. This is a Windows / MingW64 DLL, not a Cygwin one? Also, since Cisco seems to be unable to correctly pr