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 the 7945HX (Dragon Range, 5nm Zen4/RDNA2). > > The Phoenix mini PC are starting to appear right now, about 15%…20% more > performance for about 150€…200€ higher price (about 40…50%) right now. > Still waiting for Dragon Range, first teasers have popped up, so I think > it'll be available before the end of the year. I've finally got my hands on that Dragon Range mITX motherboard, paired it with 96 GiB memory, 2×4TB NVMe and built it into a nice small form-factor case. I've decided to run it under Linux for now and virtualize Windows via KVM. Running the gcc compilation test as before, but with a different version of gcc to be built and the objdump improvements, so not directly comparable. I'll see if and when I can re-do the older tests with the current versions later. | Processor | HW | Core| TDP | Base | Turbo | aTurbo | L1i/L1d+L2 |L3 | Mem | comp | inst | pack | test | tot | ||| | [W] | [MHz] | [MHz] | [MHz] | [kiB] | [MiB] | [GiB/s] | [min] | [min] | [min] | [min] | [min] | |++-+-+---+---+++---+-+---+---+---+---+---| | Xeon E3-1276v3 | 1S/4C/8T | Haswell | 84 | 3600 | 4000 | 3800 | 32/32+256 | 8 |25.6 | 101 |15 | 9 | 445 | 570 | | EPYC 7252 | 2S/16C/32T | Zen2| 120 | 3100 | 3200 | 3200 | 32/32+512 | 128 | 170.6 | 123 | 9 |10 | 200 | 342 | | Ryzen 7735HS | 1S/8C/16T | Zen3+ | 54 | 3200 | 4750 | 3850 | 32/32+512 |16 |75.0 |68 |32 | 7 | 200 | 307 | |++-+-+---+---+++---+-+---+---+---+---+---| | Ryzen 7845HX | 1S/16C/32T | Zen4| 75 | 3000 | 5200 | 4000 | 32/32+1024 |64 |81.2 |43 | 2 | 4 | 122 | 171 | Efficiency wise this (expectedly) doesn't quite reach the level of the miniPC for low and medium load, hovering around 23W at idle under Linux and 60W with the Windows VM started and idling, peaking at about 130W under full load, which makes it slightly more efficient than two miniPC for this scenario. Virtualization seems to consume around two cores with high filesystem activity, so maybe bare-metal via dual-boot would help a bit. I can't test direct hardware passthrough for disks at the moment, which might also help. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
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 random Perl packages, so if it gets accepted into Cygwin I would suggest to assign it to me. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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 searches for
keys in different places, so you'd have to change your setup. More
specifically you'd either have to explicitly trust all keys you want to
check (not going to happen) or use a "--keyring" argument to force it to
use the pubring.
(I've used an old key file for Cygwin in the following for
demonstration, the current key is not expired obviously.)
--8<---cut here---start->8---
~> gpg2 --verify cygwin/setup64.zst{.sig,}
gpg: Signature made So 07 Apr 2024 16:30:47 CEST
gpg:using RSA key 56405CF6FCC81574682A5D561A698DE9E2E56300
gpg: Good signature from "Cygwin " [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 5640 5CF6 FCC8 1574 682A 5D56 1A69 8DE9 E2E5 6300
~> gpgv2 cygwin/setup64.zst{.sig,}
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/gratz/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made So 07 Apr 2024 16:30:47 CEST
gpgv:using RSA key 56405CF6FCC81574682A5D561A698DE9E2E56300
gpgv: Can't check signature: No public key
~> gpgv2 --keyring .gnupg/pubring.gpg cygwin/setup64.zst{.sig,}
gpgv: Signature made So 07 Apr 2024 16:30:47 CEST
gpgv:using RSA key 56405CF6FCC81574682A5D561A698DE9E2E56300
gpgv: Good signature from "Cygwin "
--8<---cut here---end--->8---
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: [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 files are often provided with fixed names which may be renamed on > download > to unique values using cygport URI fragment support like > #/$NAME-VERSION.sha...sum; > use coreutils cksum as it supports all modern and legacy checksums and > formats. https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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 case… --8<---cut here---start->8--- from /usr/include/w32api/windows.h:9, from /mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/test_utils/test_common.h:88, from /mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/tar/test/test.h:38, from /mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/tar/test/test_extract_tar_lrz.c:25: /usr/include/w32api/_mingw_mac.h:319:8: warning: #warning Using _FORTIFY_SOURCE=2 (level 3 requires __builtin_dynamic_object_size support) [-Wcpp] 319 | # warning Using _FORTIFY_SOURCE=2 (level 3 requires __builtin_dynamic_object_size support) --8<---cut here---end--->8--- Can't we conditiohnalize this to depend on the actual compiler support? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
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 comments in it that you can't believe I > mean that literally... As the saying goes: Communication is possible, but improbable… > Well, OK. This is less useful to people who actually want to use it, > though, requiring them to know that > "DWARF_PARSE=/usr/share/cygport/tools/dwarf-parse.pl" is the right > incantation. > > Perhaps "DWARF_PARSE=1" could be a shorthand for that? I don't see why not, it just requires one extra test. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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 > unless I spend lots of time staring at it :) That's what you get from an experiment that went rather more well than planned. > Seriously, this should at least say "I'm running objdump -Wl to dump > out the .debug_line section containing DWARF XYZ information. > > Then maybe some comments about what assumptions it's making about the > human-readable output it's parsing. So you're asking for a manpage, really. Should be doable with enough round tuits. > cygport goes to some lengths to identify the correct objdump to use > when cross-building, so it should probably should be used here (passed > in as an arg?), rather than assuming it's /usr/bin/objdump. Yes, either that or using whatever variable cygport sets up with the correct objdump. > What this line is doing is obvious, the rest of this block, not so much. Nothing to see here, move along… :-P > You might also like to touch on why we bother looking at the line > number information at all, rather than just producing a (filtered) > list of all the pathnames mentioned? I was using this to figure out why the "objdump -d -l" was missing some of the file names I was seeing (in general, again, it comes to the same set of files in the end). > If you're going to keep this (which you probably should), perhaps it > should be under some 'if (DEBUG)' conditional. Yeah, can do if I use GetOpt::Long, which I should probably do anyway just in case this gets extended later on. > DWARF_PARSE should be mentioned in the documentation for cygport.conf Yes. > Since the helper script will be installed, it could be made a boolean. Out of habit grown over decades, I always keep an escape hatch for using local (modified) copies in such scripts. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
[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't get installed by default? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
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 the raison d'être… Anyway, I still hope to wrap my head around how libbfd works and either produce a standalone executable or objdump sub-command that implements the same functionality (probably sans the filtering). 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
[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 object files. For gcc-11 extracting the debug source
files takes up to 45 minutes per executable (up from about 15 minutes
until 2.39) and for gcc-13 (with about 1.5 times the number of lines to
extract) it is already taking more than two hours. So if you just
package gcc-13 using a single thread you'd be looking on the order of 20
hours wall clock time, which is unacceptable.
The deassembly implied by the "-d" (which is not the part that has the
superlinear complexity btw, but produces a baseline of 2 hours single
thread runtime all by itself) is also unnecessary to extract just the
filenames of the source files as we throw away the location information
anyway and so I've written a small parser that works on the DWARF dump
instead (which can be produced in linear time with a very small scaling
factor, so practically constant time even for very large executables).
Unfortunately binutils does not yet offer a machine readable format for
these dumps, but parsing the text is not too difficult even though the
format is undocumented. The DWARF-5 documentation isn't the most
enjoyable read, but it was helpful enough to figure it all out. I've
also integrated the filtering of unrelated source file information (from
system headers and external libraries). The end result is the same
runtime as before on small object files, a factor up to 100 speedup for
medium sized object files and speedups in the several thousands range
for large sized ones (or a total single-thread runtime of less than 20
seconds for gcc-13).
dwarf-parse.-pl
--8<---cut here---start->8---
#!perl -w
use common::sense;
use List::Util qw( sum );
my $filter = shift @ARGV
or die "not enough arguments";
my $obj = shift @ARGV
or die "not enough arguments";
my @objdump = qw( /usr/bin/objdump -WNl );
open my $DWARF, "-|", @objdump, $obj
or die "can't invoke objdump\n$!";
my ( @dirs, @files, %fn, %rn );
while (<$DWARF>) {
if (/^ The Directory Table/../^$/) {
if (/^ \d+/) {
my ( $entry, $dir ) = m/^ (\d+)\t.+: (.+)$/;
$dir = "$dirs[0]/$dir" if ($dir =~ m:\A[^/]:);
push @dirs, $dir;
}
}
if (/^ The File Name Table/../^$/) {
if (/^ \d+/) {
my ( $idx, $fn, undef ) = m/^ \d+\t(\d+)\t.+: (.+)$/;
$rn{"$dirs[$idx]/$fn"}++;
push @files, "$dirs[$idx]/$fn";
}
}
if (my $rc = /^ Line Number Statements/../^ Offset:/) {
$fn{"$files[0]"}++ if ($rc == 1);
$fn{"$files[$1]"}++ if m/ Set File Name to entry (\d+) in the File Name
Table/;
@files = () if ($rc =~ m/E0$/);
@dirs = () if ($rc =~ m/E0$/);
}
if (/^ No Line Number Statements./../^$/) {
@files = ();
@dirs = ();
}
}
foreach my $fn (grep m:^$filter:, sort keys %fn) {
say sprintf "%s", $fn;
}
say STDERR sprintf "\tLNS: %6d (%6d locations) <=> FNT: %6d ( %6d locations)",
0+grep( m:^$filter:, keys %fn ), sum( values %fn ),
0+grep( m:^$filter:, keys %rn ), sum( values %rn )
if (0);
close $DWARF
or die "failed to close objdump\n$!";
--8<---cut here---end--->8---
Integration into cygport is made configurable via a variable to be set
in .cygportrc for instance in order to easily revert back to the
original objdump invocation if necessary. I've been producing packages
with that setup for a while now and have not noticed any errors. In
principle the new parser actually produces more complete output as there
can be multiple line number statements and hence source files per
location, but objdump only lists one of them in the disassembly (at
least sometimes). In practise I haven't found a package until now where
the final list (after filtering) is different.
https://repo.or.cz/cygport/rpm-style.git/commitdiff_plain/7ab8b26aaefb8a6ce050a196ddc97ce416ebe7a9
--8<---cut here---start->8---
lib/src_postinst.cygpart: use DWARF_PARSE optionally instead of objdump -dl
---
diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
index f06004e4..3dd6e893 100644
--- a/lib/src_postinst.cygpart
+++ b/lib/src_postinst.cygpart
@@ -1096,7 +1096,12 @@ __prepstrip_one() {
else
dbg="/usr/lib/debug/${exe}.dbg";
- lines=$(${objdump} -d -l "${exe}" 2>/dev/null | sed -ne
"s|.*\(/usr/src/debug/${PF}/.*\):[0-9]*$|\1|gp" | sort -u | tee -a
${T}/.dbgsrc.out.${oxt} | wc -l);
+ if defined DWARF_PARSE
+ then
+ lines=$(${DWARF_PARSE} /usr/src/debug/${PF}/ "${exe}" |
tee -a ${T}/.dbgsrc.out.${oxt} | wc -l);
+
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 out). > If an up-to-date and working tmux package is important to you, please > consider if maybe you want to adopt it? (I'm assuming the existing > maintainer has wandered off since he didn't reply, but our process > requires me to wait a bit longer before that's assumed). I'd be willing to ITA tmux and do an NMU in the interim. I've pushed the package to playground and it has built cleanly on AppVeyor. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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.Stromeko.net/Downloads.html#WaldorfSDada
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 nothing worrisome. Also OCaml bindings need to be disabled for now until the version requirements can be provided. I've not yet tried to get the other LLVM related packages built. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
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 Makefiles. If something else, please explain. Again, there already is a pass in cygport that's supposed to fix up symlinks, if that's not working we need to figure out why and how to fix it if necessary. > For simplicity, I personally think to put all llvm related packages in > an all-in-one "llvm" package is a good idea. I have sympathy for any idea that makes the life of the maintainer easier… > The new llvm package is going to replace the old clang and llvm, and > maybe other llvm related packages. …but ignoring the needs of the user isn't the solution to this problem. Forcing everyone to install everything just because they want to use something that links a library related to LLVM? Please not. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
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 have a look over the weekend. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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 build (didn't look at the other two versions), but the cygport misses all the work to actually produce packaging that can be used to upgrade from the existing Cygwin version. Source file is he whole project instead of just LLVM + Polly and the build also enables clang (which should be in a separate package). Generator has been changed from Ninja to Make (and switching back to Ninja makes the install step fail because that target wasn't made available). Multiple build options have been changed from what they were in Cygwin, I have not had time to investigate what that actually means for the resulting compiler binaries. I don't understand why the process_install_dir_bin_symlinks function is necessary, as cygport should already fix up symlinks in the install dir. I did enable the test suite and it tests with 259 fails (was 180 fails before and looks about the same general pattern as with version 9.0.1). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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 be further changes to the packaging, given how far out of date the cygport you based it on is. > 16.0.6 17.0.6 and 18.0.0(current) are supported. Did you run the test suite? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
[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#BlofeldUserWavetables
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 build was > produced with gcc-g++ 6.4. Newer gcc-g++ releases fail to build > inkscape due to C++ include file evolution. Since apparently you can compile it with that compiler on an otherwise current release of Cygwin (I assume), you should be able to request a previous C++ or G++ standard version and have the current compiler do the same? The baseline for gcc-6 until gcc-10 has been C++14 and gcc-11 switched to C++17. You should also check that the compiler is detected correctly, there are some configure scripts that fail to take higher version numbers (esp. double digits for the main gcc version) correctly into account and then set bogus options. Inkscape shouldn't have been using C++11 until 0.93, so the appropriate standard to invoke is probably C++98 (or thew GNU variant thereof). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
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/pkg_pkg.cygpart __pkg_srcpkg() for > check and definition and __gpg_sign() for use in gpg signing of Cygwin > patches and files. We should just switch to gpg2 an require that, there is no point in trying to use GPG 1.x anymore. https://repo.or.cz/cygport/rpm-style.git/commitdiff/84279e484726a68cc8f08e7c9126bef13d9510d7 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: [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 (especially if we can tell it > failed for that reason). I was about to say the same thing… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
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, *including within functions*. In most > functions in cygport, a non-zero return code will cause cygport to > error, but because the && chain disables `set -e`, failures within > src_install are silently ignored. Counterintuitively, having the && > chain present means that execution will _continue_ after a failure! Well, that's the short story, but the functions themselve can again contain constructs that produce unexpected result now that "set -e" is in effect, plus it'd depend on the call site of whether or not that is true to begin with. So in order to fix the problem you'd need to audit all call sites… > Alternatively, just have a look at the test case I attached to the cover > email; I'd expect that cygport file to fail the install stage, because > the first command in the src_install function is an unhandled failure. > Currently, the src_install succeeds, with no hint of any problems, but > with my patch, it produces an error as expected. Given that it was the model for cygport, looking at Gentoo portage and perticularly ebuild, you're probably right to expect that to happen. However it seems that the Gentoo folks also stepped on that particular mine in the past and have solved the problem in a different way by moving the responsibility for the abort into the helper functions and generally expecting "set +e" on entry (at the very least "-e" is _not_ set in toplevel). I don't know enough about the further details of the current implementation, but clearly by now it's way more complex than what Yaakov took as the inspiration for cygport. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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 from commands in a src_install function being > ignored, don't chain the function calls with &&, and instead just let > Bash's `set -e` behaviour handle failures. That patch circumvents the shortcutting of the execution chain at the first fail and might produce undesirable results elsewhere. Unless there's another interesting behaviour in Bash, it should suffice to follow the last command in the "&&" chain by "|| false" to transfer the status of the chain to PIPESTATUS (provided that the return code of the functions involved is set correctly). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
[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/commit/?h=playground The version used is the last of the 10.3 LTS GA branch which went out of support in May this year. Once this is out we can discuss updating to one of the LTS versions that are still in support, I have not yet looked into whether these build without problems and how much changes to the patch set are required. https://cygwin.com/cgit/cygwin-packages/mariadb-connector-c/commit/?h=playground That's the latest version available from upstream. Appveyor times out before mysql is fully built, the connector library has built without errors. I'd like to get feedback from actual users of these packages before doing an NMU on them… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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, Achim. --
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 your package has no current > upstream I expect no problems from switching. > > Please check that your packages build cleanly with the v3.0 libssl-devel > in place. I shall remind y'all that OpenSSL 1.1 is EOL for a month now. so please stop building packages against it and switch to OpenSSL 3.0… all packages that depend on OpenSSL need to make that switch latest when a new CVE for SSL gets published, which looking at the past year can be expected to happen just about now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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 existing build directory, it's important to > not be an idiot like me, and do a 'make clean' to rebuild everything > with the new _FILE_OFFSET_BITS define) :-) Been there, done that… > (I faintly recall there are some other issues with the use of 'int' > for the progress reporting gauges, which also might need some > attention to work correctly for file sizes >2GB) Currently there isn't any progress indicator either to the number of pending files or extraction in a package. I have that on my list of things to check and maybe correct for quite some time,m but obviously not anywhere near a point where I'd get a round tuit. There are two local int variables in the file reader function that likely should be off_t for i686, to test if that's true you'd need an archive with a file larger than 2GiB that is an exact multiple of 64kiB in size… > Anyhow, I applied it, and I'll try to make a release of setup in the > next few days... Thanks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
[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
@@ -28,7 +28,7 @@ AM_CFLAGS = $(BASECXXFLAGS) -Wmissing-declarations -Winline \
AM_YFLAGS = -d
AM_LFLAGS = -8
WINDRES = @WINDRES@
-AM_CPPFLAGS = -D__USE_MINGW_ANSI_STDIO=1 -DLZMA_API_STATIC\
+AM_CPPFLAGS = -D__USE_MINGW_ANSI_STDIO=1 -D_FILE_OFFSET_BITS=64
-DLZMA_API_STATIC \
-I$(srcdir)/libgetopt++/include \
$(ZLIB_CFLAGS) $(LZMA_CFLAGS) $(ZSTD_CFLAGS) $(LIBCRYPT_CFLAGS)
$(LIBSOLV_CFLAGS)
diff --git a/UserSettings.cc b/UserSettings.cc
index 51497255..c8ddd3d2 100644
--- a/UserSettings.cc
+++ b/UserSettings.cc
@@ -32,7 +32,7 @@ public:
ssize_t read (void *buffer, size_t len) {return 0;}
ssize_t write (const void *buffer, size_t len) {return 0;}
ssize_t peek (void *buffer, size_t len) {return 0;}
- long tell () {return 0;}
+ off_t tell () {return 0;}
off_t seek (off_t, io_stream_seek_t) {return 0;}
int error () {return 0;}
void operator << (std::string);
--
2.42.0
--8<---cut here---end--->8---
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
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 release. Given the general state of things, I'd not bother with anything that isn't officially supported upstream and only provide the LTS version (which at the moment seems to be 4.14.x) as non-test. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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 >> someplace. > > After some digging I believe I've found where the information is > compiled in (a daisy chain of variables starting with Makefile.config > in the toplevel directory...) I suspected something like that, but as I said I didn't find a definite answer and the text files in the system installation didn't have this information, so I concluded it must come from some binary. > To confirm I'm fixing the right thing, could you elaborate what specifically > is the error with "ocaml_config imports stupid flags from the cygport build"? > Is there a specific option within CFLAGS (fdebug-prefix-map perhaps?) > or ocamlc invocation that's causing an error message? Anything specific to the cygport build environment, but specifically the prefix maps. > Regarding other leakage, it looks like almost every file (exe, cma, etc.) > contains provenance compiled into the file due to the fact that they are > compiled with -g to include debugging information. I can obfuscate the > provenance > by building in /mnt/share/cygpkgs (the same approach Cygwin tar, gcc appear > to do). That's just because these are my packages too and that's the location where I built them. >> I don't think that makes any sense given the way the packaging is done >> at the moment. In fact, ever since you updated to 4.14.0 all other >> OCaml packages in Cygwin were dead since you didn't update these at the >> same time and there is no mechanism in place yet to ensure that ocaml-* >> packages and the ocaml package target the same version of the compiler. > > Unless you were already planning to, I'd be happy to adopt some of these > OCaml packages > and package some new releases so they can also work on Cygwin. I wasn't planning to adopt the packages (I really don't know enough about OCaml), but doing a non-maintainer update would have been an option. Having an active maintainer for these again would be a much better solution of course. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
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 packages are exist in current pulseaudio package. > https://bodhi.fedoraproject.org/updates/FEDORA-2021-a10d836640 > > The these old package is not compatible with new pulseaudio, so > these should be going to uninstall. The correct solution would be declare whatever provides suitable functionality as a replacement package, even if it doesn't provide the exact same commands, IMHO. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
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 information in the installed package, so it seems that the information is compiled in someplace. > Re Opam switches: As far as I understand, switches are like "git branch" but > for > different compiler installations instead of different code branches; for > example > you can install ocaml 4.14.0 and 4.12.0 side by side and switch between them > easily. In addition to some other things, it effectively edits your PATH > environment variable so when you type "ocamlc" it'll execute the appropriate > version. Yes, I know that. The complete mystery is why you can't use opam to provide results that can be packaged. > General comment: I don't know much about LLVM, but is there a reason why the > other software (dune, ocamlbuild, etc.) must be installed with the system and > not with opam? Because the expecation is that you can get everything in to a working state just by installing the packages. >> Cygport package changes are in the Cygwin Packages Git repository in the >> respective playground branch as before. > > Re OCaml cygport playground: Thanks for the cygport cleanup and changes. > A couple questions: > > src_compile: > 1. Adding flambda to a default system installation of OCaml can slow down > compile times and produce linking incompatibilities with non-flambda code > [1]. > Additionally, there may be value in a vanilla out-of-the-box OCaml > distribution. I've mainly includeed it because LLVM complained it wasn't enabled (obviously it can build the OCaml bindings with and without flambda) since it seems to work and test OK I just flipped that switch. > Let me know if there is some general Cygwin guidance on what features > packaged > language compilers should support. Otherwise, if flambda is necessary for > LLVM, > I could package an flambda and a non-flambda release for each version, and > the > user can pick which one they prefer. I don't think that makes any sense given the way the packaging is done at the moment. In fact, ever since you updated to 4.14.0 all other OCaml packages in Cygwin were dead since you didn't update these at the same time and there is no mechanism in place yet to ensure that ocaml-* packages and the ocaml package target the same version of the compiler. > 2. What benefit does splitting "cygmake" into the 3-step "cygmake world, opt, > opt.opt" have? Plain old "make/cygmake" with no target appears to be the > recommended compilation step. Hysterical raisins… before I got things to actually build it would stop in various places and I was tring to find out where that happened. I've not gone back to reduce it again since it doewsn't incur any (or at least not noticeable) overhead at the moment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
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 User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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't sure. Thanks for the confirmation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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 recognize -pthread, but will get it from ocamlc under certain conditions - [X] ocaml 4.14.0 ==> 4.14.1 + ocaml_config imports stupid flags from the cygport build + probably from /usr/lib/ocaml/Makefile.config - [X] ocaml-labltk 8.06.8 ==> 8.06.12 (for 4.14!) + CI build runs into trouble, local build is OK - [X] ocaml-findlib 1.2.1 ==> 1.9.6 + CI build would require newer labltk - [X] ocaml-ocamlbuild 0.14.0 ==> 0.14.2 + test complains about missing ocamlbuild.cmo, looks in the wrong place + test requires findlib - [X] opam 2.0.7 ==> 2.1.5 - [X] ocaml-dune 2.5.1 ==> 3.10.0 + no longer builds with the original recipe, missing external libraries that in turn require dune to build + set up build w/ make according to the instructions from upstream + import Fedora patch to kill lwt + doc generation needs sphinx-copybutton, stopgap: pip3 install (needs Cygwin package) + does not test due to missing packages yet + ocaml-dune.cygclass needs to specify --prefix and --libdir + csexp in private libs + ocamlfind shows version as n/a - [X] ocaml-stdlib-shims 0.3.0 - [X] ocaml-integers 0.3.0 ==> 0.7.0 + shown as f77a25b-dirty by ocamlfind - [X] ocaml-bigarray-compat 1.1.0 - [X] ocaml-ctypes 0.17.1 ==> 0.21.1 + tests don't build: flexdll gets a '-pthread' from tests/clib/dune that it can't handle + tests depend on non-existing libraries * LLVM Updates - [X] LLVM 9.0.1 rebuild + update fedora to f31 + update patches + enable/disable OCAML via OCAML_SUPPORT + control build targets via LLVM_TARGETS + enable testing - [ ] clang - [ ] libcxxabi - [ ] libcxx - [ ] libunwind - [ ] compiler-rt - [ ] dtc (?) * Dependencies - [ ] python-sphinx-copybutton --8<---cut here---end--->8--- Cygport package changes are in the Cygwin Packages Git repository in the respective playground branch as before. Staging package repository with the builds is currently available at: root=http://cygwin.stromeko.net/ Point setup at $root/stage as an additional (!) repository and use my signing key via "-K $root/stromeko.gpg" if you want to play with the packages. The fingerprint of my key is: B22B 4890 B89E 5E5A 795C E305 B40B EC75 3152 B1C3 If you have the keyart script (Python, you can just download from https://raw.githubusercontent.com/atoponce/keyart/master/keyart), this is what you should see after importing the key into your public keyring: > keyart stromeko +-[DSA 2048]+ | ^.| |^ .| | ^ E | |. . ^ :| |. . ^ : . | |.^ . ^.:S | | .. . :^. | |. .^ ^.^ | |. ^:.^ .. | | ^:... . | |.^.| +-[3152B1C3]+ +---+ | :X| | . ^^^| |: ..^| | . : . E | | i . . . | | ^ S l : . | |i l ^ ^| | ^ . . | | . .| | . . | | ... | +---+ Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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 trouble when I need to build packages that require the things not in the bootstrap build. Just about every Linux distribution seems to have a different way of working around these dependency problems and none look anything like what Cygwin had. Anyway, I've found a Fedora patch that just removes the lwt dependency and sdurprise, dune still builds and actually packages. > however, i did tried to compile ocaml-dune version 2.9.3 and 3.7.1 > (for ocaml 4.14) previously for some other personal reason (not for > llvm), and here are the prebuilt binaries of dune 3.7.1 if you > need[1], i kinda forgot how i bootstrapped it. I can get to that point with a bootstrap build or even a fully configured one with opam. If I could figure out how to get opam to actually install into the system and not this bloody unexplained thing that it calls "switches" (which are maybe a totally cool thing, but I neither need nor want them) I could likely bootstrap the whole thing and get the packages rebuilt that the OCaml LLVM bindings need. Anyway, now that I have dune (I think), I could build integers as a prerequisite of ctypes, which apparently now also needs bigarry-compat and who knows what else (even though Cygwin didn't have these before). Then maybe that's enough to get the OCaml bindings back in LLVM. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
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]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
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 >> 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). > > I am not sure but there is probably some upstream changes are needed > in cygport source[1] to get latest ocaml-findlib & ocaml-dune to work > properly. the dependency infos in META files seems start to have some > pretty printing and the old regex and patterns for finding the > depended pkg names are no longer working correctly. That's a separate issue, thanks for the patch. What I was talking about is that while I can use an opam "switch" to update ocaml and its dependencies in a private installation, I can not build the Cygwin packages that would need to be distributed or update the system installation of OCaml. If it exists, any option to update the system files has eluded me. In particular, I have not yet figured out how to break the circular dependencies for a bootstrap build. Opam must know how to do this or it wouldn't suceeed, but doesn't show what exactly it's doing by default. THere's probably a way to look at that too… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
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 another variable to control the LLVM target > list). > > * LLVM Updates > - LLVM 9.0.1 revived > + update fedora to f31 > + update patches > + disable OCAML via OCAML_SUPPORT > + control build targets via LLVM_TARGETS + enable testing Many of the (few) failing tests run into trouble with fork errors and sometimes succeed when run again, so from that angle I think the build is good. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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<---cut here---start->8--- * LLVM Updates - LLVM 9.0.1 revived + update fedora to f31 + update patches + disable OCAML via OCAML_SUPPORT + control build targets via LLVM_TARGETS * OCaml Updates - flexdll 0.39 ==> 0.43 - ocaml 4.14.0 ==> 4.14.1 - ocaml-labltk 8.06.8 ==> 8.06.12 (for 4.14!) + CI build runs into trouble, local build is OK - ocaml-findlib 1.2.1 ==> 1.9.6 + CI build would require newer labltk - ocaml-ocamlbuild 0.14.0 ==> 0.14.2 + test complains about missing ocamlbuild.cmo, looks in the wrong place + test requires findlib - ocaml-dune + no longer builds with the original recipe, missing external libraries that in turn require dune to build + bootstrapped dune should still be viable - ocaml-ctype + would be needed for llvm + available version is for ocaml-4.10, which is no longer installable + need to figure out dune build and bootsrap a number of further packages before getting this updated to 4.14 --8<---cut here---end--->8--- The changes (only for packages that actually build) currently live in the playground branches of the respective Cygwin Package Git repositories. PUlling up the LLVM version to at least 12 and then getting all the other dependent packages built is next on my list, but don't hold your breath Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
[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 from switching. Please check that your packages build cleanly with the v3.0 libssl-devel in place. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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. Which might explain why it took so long to discover this bug. 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: [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 > the usage in `__src_prep()`. > Therefore, --keep option can't be used simply. That's true for bunzip2 and gunzip, but not for zstd (where the output file can be independently specified). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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 Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
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 aligns with handling .gz > and .bz2 like > `unzstd -c file.zst > file`. Hmm. I'd would have preferred to use the --keep option (which is the default for unzstd anyway) and save the redirection (also for the other programs that offer that option). 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: [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. > > Given the brittleness of some test suites it might be prudent to keep > the default "serial" for a while and in any case not confound it with > the option of doing the build in parallel. So the suggestion is to add > a variable MAKETESTOPTS following along MAKEOPTS example to be used in > cygport files. I would also suggest to add a command-line option "-jt" > / "--jobs-test" or some other suitable name plus a configuration option > for cygportrc that when set causes cygport to populate MAKETESTOPTS with > the same default as MAKEOPTS and otherwise leave it empty (keep the > current default of "serial" make). POC: https://repo.or.cz/cygport/rpm-style.git/commitdiff/3756290fd1de63e0514aa71eaca62569eb3a782a Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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 documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
[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 the default "serial" for a while and in any case not confound it with the option of doing the build in parallel. So the suggestion is to add a variable MAKETESTOPTS following along MAKEOPTS example to be used in cygport files. I would also suggest to add a command-line option "-jt" / "--jobs-test" or some other suitable name plus a configuration option for cygportrc that when set causes cygport to populate MAKETESTOPTS with the same default as MAKEOPTS and otherwise leave it empty (keep the current default of "serial" make). WDYT? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
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 that it isn't that smart… Anyway, since it won't succeed on anything but empty directories it doesn't make sense to use to attempt a recursive change even if it were just looking at directories (which would of course be way faster at least). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
[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, because then 'finish
> all' wouldn't work as desired. But yeah, it seems that this is in the
> wrong place. I'll look into moving it.
Meanwhile I've done this:
--8<---cut here---start->8---
if [ $OSTYPE = "cygwin" ]
then
+ [ -n "$(find ${workdir} -maxdepth 0 -empty)" ] &&
chattr -fR +C ${workdir} >/dev/null 2>&1 || true
fi
--8<---cut here---end--->8---
I think it should be moved into a function that can be called before the
prep command, but I haven't actually tried it for a longer time or
checked what tests need changing due to the extra output:
--8<---cut here---start->8---
>From 4be00357be8cb14493413b7c8c80777671c21e5d Mon Sep 17 00:00:00 2001
Subject: [PATCH] cygport.in: move case-sensitivity testing / enabling into
functions
---
bin/cygport.in | 46 ++
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/bin/cygport.in b/bin/cygport.in
index 02e9b7bf..a6dabc91 100755
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -577,25 +577,36 @@ declare -r pkg_count=${#pkg_name[*]};
# this requires workdir to be already defined
mkdir -p ${workdir}
-if [ $OSTYPE = "cygwin" ]
-then
- chattr -fR +C ${workdir} >/dev/null 2>&1 || true
-fi
-
-rm -f ${workdir}/.probe_case_sensitivity
-touch ${workdir}/.PROBE_CASE_SENSITIVITY
-probe=$( [ -f ${workdir}/.probe_case_sensitivity ] && echo "failed" || echo ""
)
-rm -f ${workdir}/.PROBE_CASE_SENSITIVITY
-if [ -n "$probe" ]
-then
+__enable_case_sensitivity() {
+inform "Trying to enable case sensitivity on ${workdir}"
+if [ $OSTYPE = "cygwin" ]
+then
+ [ -n "$(find ${workdir} -maxdepth 0 -empty)" ] &&
+ chattr -fR +C ${workdir} >/dev/null 2>&1 || true
+ __probe_case_sensitivity
+fi
+}
+
+__probe_case_sensitivity() {
+mkdir -p ${workdir}
+rm -f ${workdir}/.probe_case_sensitivity
+touch ${workdir}/.PROBE_CASE_SENSITIVITY
+local probe=$( [ -f ${workdir}/.probe_case_sensitivity ] && echo "failed"
|| echo "" )
+rm -f ${workdir}/.PROBE_CASE_SENSITIVITY
+if [ -n "$probe" ]
+then
if defined _CYGPORT_RESTRICT_case_insensitive_
then
- error "Package ${NAME} cannot be built on a case-insensitive
filesystem";
+ error "Package ${NAME} cannot be built on a case-insensitive
filesystem";
else
- warning "Building on a case-insensitive filesystem";
+ warning "Building on a case-insensitive filesystem";
fi
-fi
-unset probe
+ false
+else
+ inform "Building on a case-sensitive filesystem";
+ true
+fi
+}
# this requires S and B to be already defined
if ! defined _CYGPORT_RESTRICT_debuginfo_
@@ -638,15 +649,18 @@ while (( arg_n < argc ))
do
case ${argv[${arg_n}]} in
downloadall|fetchall|wgetall|getall)
+ __probe_case_sensitivity || __enable_case_sensitivity;
__src_fetch;
_status=$?;
;;
download|fetch|wget|get)
+ __probe_case_sensitivity || __enable_case_sensitivity;
__DL_ONLY_MISSING=1 __src_fetch;
_status=$?;
;;
prepare|unpack|prep)
- __stage Preparing;
+ __probe_case_sensitivity || __enable_case_sensitivity;
+ __stage Preparing;
__src_prep;
_status=$?;
;;
--
2.41.0
--8<---cut here---end--->8---
> I think there's possibly something else going wrong if it's taking 5
> minutes, as that seems excessive.
Try it on the gcc build dir…
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
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 update if you like. > Still interested in your opinion about this question. Also whether > it's OK that package italic-man provided a zp script that modified > /etc/man_db.conf. In principle I think replacing one tool with another that has the same name and slightly different functionality should be done via the alternatives system, not hand-rolled scripts. You'd still need postinstall scripts to set it up correctly. >>> About your first question - Can this be done as a patch to man-db and/or groff? >>> Do you mean the whole thing should not be a separate package at all >>> but completely patched into man-db? >> >> Well, yes, that would avoid all the knots caused by post-install >> scripts with uncertain ordering I'm worrying about. > I think I have addressed those uncertainties and the problem with the > man-db patch is that man-db package maintainers would need to take up > the issue... I'd prefer that work be one upstream since none of it is specific to Cygwin, which looks like it would be eminently possible given the nature of your change. >> Can you explain, in general terms, why this isn't a feature of stock >> man-db already? > There is option grotty -i in stock man-db but grotty is a tool deeply > embedded in the man toolchain and there is no user-friendly documented > way to inject this option into the toolchain, other than replacing > grotty with a wrapper script which is effectively all my package does. This is why to me it would make a lot more sense to work with upstream to come to a solution. Colin Watson has been pretty receptive in the past. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
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 Range, 5nm Zen4/RDNA2). The Phoenix mini PC are starting to appear right now, about 15%…20% more performance for about 150€…200€ higher price (about 40…50%) right now. Still waiting for Dragon Range, first teasers have popped up, so I think it'll be available before the end of the year. 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: [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 go. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
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 postinstall will not necessarily have internet access, so you'll need to cope with errors that will produce. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
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 provide a cert chain over the Akamai infrastructure to allow downloading via HTTPS, you should have an SHA256 or SH512 check on the resulting file to assure that the file matches what is expected. It should probably be renamed to .dll only after that step. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
