Re: cygport may not create debug info if top directory contains a symlink
Am 18.09.2023 um 12:41 schrieb Christian Franke via Cygwin-apps: $ pwd -P /usr/src $ /bin/pwd -L /tmp/source Generally speaking, if you really need to mess with /usr/src (which is a packaged directory, so any Cygwin application can assume it's existence as a directory) you should do that via a (bind) mount. -- Achim. (on the road :-)
Re: PCRE2 interim release 2 requested to support grep 3.11
Brian Inglis via Cygwin-apps writes: > Because of issues with the current release of PCRE2 Unicode matching > in latest grep 3.11 release reverting to ASCII only matches for some > patterns, it would be good to have an updated interim Cygwin release 2 > of PCRE2 10.42+ available incorporating PCRE2_EXTRA_ASCII_... changes, > and for PCRE2_MATCH_INVALID_UTF, between Feb 1 and April 21, submitted > by Carlo Arenas for pcre2 and grep. That patch set is apparently still not merged upstream and other work in this area is still going on, so I don't think it's wise to jump the gun. […] > Otherwise we could not upgrade grep until pcre2 10.43 is released. Yes, we can just wait for uptstream to sort things out. -- 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: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
Jon Turney via Cygwin-apps writes: > There's an updated report available [1], which should list the > affected packages. > > [1] https://cygwin.com/packages/reports/perl_rebuilds.html That list has shrunk a bit. The following packages should have priority in getting updates/re-releases, I think: subversion weechat hexchat znc 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: [ATTN. Maintainer] po4a
Erwin Waterlander via Cygwin-apps writes: > Thanks Achim. I have merged your changes into master. …but didn't actually do a release. :-) Anyway, I have tested the update to 0.68 (now that the new Perl distributions are available on Cygwin) and pushed this to the playground branch for your perusal. 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
[ORPHAN] perl-Finance-Quote
The package can't have actually done something useful for quite some time since most or all of its online data sources have vanished or changed their format over time. There is a new maintainer that tries to fix things up, but in the process of doing so pulled in no less than 44 new dependencies, which I'm unwilling to add to Cygwin. The module is currently a dependency of gnucash, which itself is orphaned and almost 5 years old. I suggest that we remove it from Cygwin, too. 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
[ATTN. Maintainer] po4a
Hi Erwin, since po4a should be re-eleased for perl-5.36.1, I've updated your cygport and pushed it to the playground branch on your repo. Please note that I've downgraded the version to 0.66, since the later releases would need a new dependency that is not yet available on Cygwin (Syntax::Keyword::Try). I've added a dependency on perl-SGMLSpm following Debian and fixed a test fail caused by a wrong assumption about how the build directory looks like (cygport links to the sources rather than creating a copy). Please use a recent cygport version, since it will create the correct perl5_0xy dependency automatically. 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: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
Achim Gratz via Cygwin-apps writes: > Ken Brown via Cygwin-apps writes: >> Could we work around the problem by removing the dependency of the >> obsolete packages on perl5_032? > > Please don't. I'll update automake soon. Wait… these packages are not supposed to be dependent on the perl5_0xy provides, the only Perl dependency should indeed be perl_base since no version dependency is present. Did the extra dependency on perl5_032 get auto-generated at some point? Then please remove it from the hints. I'll probably need to update the automake packages anyway since they don't cleanly build anymore due to some changes in where the upstream patches are. 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: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
Jon Turney via Cygwin-apps writes:
> Just adding just perl 5.36 to base seems to work fine.
>
> Adding cygport, pulls in automake-{12,13,14}, which depend on
> perl-Carp or perl-Test-Harness. I'm not sure why the solver then goes
> on to choose those packages, rather than perl_base which obsoletes
> them.
You may need to tell libsolv to reconsider the information it has based
on the chosen (default) solution. THe solution it currently offers is
correct with both the intial information and the one after the solution
has been found, so there is no need for a satisfability solver to
continue. If you were to use zypper you'd see several more solutions
offered and it can be quite hard to figure out without trying which one
is going to cause the least amount of changes.
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: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
Ken Brown via Cygwin-apps writes: > Could we work around the problem by removing the dependency of the > obsolete packages on perl5_032? Please don't. I'll update automake soon. 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: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
Jon Turney via Cygwin-apps writes: > There's an updated report available [1], which should list the > affected packages. > > [1] https://cygwin.com/packages/reports/perl_rebuilds.html Thanks. The newly obsolated packages (due to core now recent enough) are still shown in this list (that's probably to be expected). The rest looks like I expected. 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: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
Achim Gratz via Cygwin-apps writes: > I'm going to release Perl 5.36.1 to Cygwin in a few days. Done. 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
[Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
I'm going to release Perl 5.36.1 to Cygwin in a few days. I've skipped 5.34 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 updated since at least 5.22. So I hope it will be smooth sailing for anything else depending on Perl also. Any maintainer having packages that depend on perl5_032 should re-release or upgrade these soon-ish after the Perl update is available, as otherwise users are either blocked from upgrading Perl or will have to uninstall the affected packages. The rebuilt packages need to have a dependency on perl5_036, which cygport provides automatically. 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: [PATCH setup 0/2] Detect filename collisions between packages
Corinna Vinschen via Cygwin-apps writes: > Calm could create a database containing all the files from the tar > archives it uploads, and compare that against the newly uploaded files > on the fly. That already exists as the basis for package grep, albeit in the form of a buiinch of text files. […] > There's probably another problem in terms of different file lists in > different package versions, though... That is probably not too onerous to check for, but files moving from one package to another is a different story. 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
[ITP] Perl distributions
One of the existing packages of mine has aquired two new build dependenmcies: perl-Test-FailWarnings perl-Hash-Ordered Please add them to my list of packages, thank you. 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: Build machines
Achim Gratz via Cygwin-apps writes: > The original plan was to make this my new Linux desktop and replace the > 9 year old Haswell I'm using right now and wait until the 16-core > Phoenix processors are finally available, but I'll probably have to > re-think that. 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). Anyway, I just ordered another of one these to become my new Linux desktop, the first one will stay with Win11 Pro and Cygwin and become my new build box in the coming weeks. I added a 4TB SSD for archival storage last weekend, for now I'll keep the 500GB NVMe it came with for OS and builds as it seems to not limit anything in any meaningful way for now. If it turns out later that it does I'll just switch to a speedy 2TB NVMe later on (I already had one, but that will go into #2 as system / home drive as per the original plan). 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
Build machines
Since I've impulse-bought a new mini-PC which came with Windows 11 Pro pre-installed, I did some benchmarking against the other two machines I regularly run Cygwin builds on: | Processor | HW | 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 | 84 | 3600 | 4000 | 3800 | 32/32+256 | 8 |25.6 | 101 |15 | 9 | 445 | 570 | | EPYC 7252 | 2S/16C/32T | 240 | 3100 | 3200 | 3200 | 32/32+512 | 128 | 170.6 | 123 | 9 |10 | 200 | 342 | | Ryzen 7735HS | 1S/8C/16T | 54 | 3200 | 4750 | 3850 | 32/32+512 | 16 |75.0 |68 |32 | 7 | 200 | 307 | The kicker is that it is running at around 9W idle and 70W under full load (measured on primary side), so it's also a lot more energy efficient. It was even cheaper per-core than the used machines I was buying before. Extensibility is of course limited, but works for what I'm going to use. The original plan was to make this my new Linux desktop and replace the 9 year old Haswell I'm using right now and wait until the 16-core Phoenix processors are finally available, but I'll probably have to re-think that. 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: pinfo build fails with undefined macro: AM_INTL_SUBDIR
Andrew Schulman via Cygwin-apps writes: > Thanks. I tried several different values of WANT_AUTOCONF and WANT_AUTOMAKE, > but > they didn't help. From what I can tell, AM_INTL_SUBDIR is just gone from > automake now. It never was there, this is a bug in gettext 0.21. > So I removed the call to AM_INTL_SUBDIR, and that build problem is fixed. > Anyway > thanks for pointing me in a direction. The correct solution seems to be to add 'external' to the arguments of AM_GNU_GETTEXT. 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: [PATCH cygport] lib/src_postinst.cygpart: parallelize __prepstrip
Jon Turney via Cygwin-apps writes: >> Exchange the while loop using an iffy read construct to a for loop using a >> temporary file. > > I think this change from zero-delimited to whitespace means this will > now fail to handle any filenames containing whitespace correctly? Yes, sorry. I thought whitespace in filenames wasn't working anyway, but at least here it was done correctly. > This commentary doesn't clearly identify what is wrong with the usage > of read here. The read itself was OK, piping the data from find into the read wasn't. I've replaced this with a process substitution and thus reinstated the whitespace protection without getting into subshell trouble. >> avoid filename collisions by using an >> SHA256 hash of the full file name. > > I think there is already a perfectly good, filesystem safe, > computationally cheap unique identifier for each filename, which is > it's ordinal number in the list of filenames we are examining. I've implemented a counter now. However I don't see the hashing of a filename as onerous when Git does that much more often and on much larger data. > 'wait -f' seems to be new in bash 5.0. I assume this fails horribly > on earlier bash versions. I'm ok with requiring that, but maybe we > should check the bash version? It should indeed be possible to drop the -f as long as job control is not enabled if I understand the manual correctly after re-reading it several times. I've done that and it looks like things still work. > On the plus side, the testsuite passes! :) Oh goody! 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_postinst.cygpart: parallelize __prepstrip
Jon Turney via Cygwin-apps writes:
> On 26/03/2023 19:12, Jon Turney via Cygwin-apps wrote:
>>> - usr/lib/gcc/*/lib*|usr/lib/gcc/*/*.o)
>>> + usr/lib/gcc/*/*.o)
>> Why this change?
It looks like a mistake that I didn't catch.
>>
>>> + local nproc=$(nproc)
>> This limit should probably be taken from the --jobs command line
>> parameter, if specified
Yes, although one could argue that it should actually oversubscribe
since the CPU load per process is expected to be significantly less than
100% per process.
> Looking at this a bit more, a couple of perhaps more serious problems:
>
> * The parallel invocations of __prepstrip_one are all appending to
> ${T}/.dbgsrc.out
>
> I don't see what makes that safe against interleaving of the output.
Line-buffering and the line being shorter than the buffer should.
> It's probably possible to have each instance write to a separate file
> and collect them together in __prepdebugsrc
Nah, if you insist on making it _really_ safe regardless of line lenght
and buffer size vagaries I'll do file locking on the output file.
> * This patch causes several failures in the testsuite, e.g. with
> autotools/c testcase.
Which?
> On a brief attempt at debugging, it this looks like it's due to not
> waiting for all the __prepstrip_one to complete before moving on, but
> I think the final wait should prevent that, so idk.
I've seen an indication that the final wait doesn't work, but that is
fixable by a sleep apparently. Did You see that the process number
limiting doesn't work?
> I'm not clear that invoking 'jobs', is actually doing anything, if
> job-control is turned off in a non-interactive shell?
No, "jobs" shouldn't do anything, but wait should still work I think
(the manpage talks about jobs, but it really means "children"). But
then again, a bit of googling tells me that the bashism "wait -n"
actually needs job control to be enabled, natch.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Heads up: Problems with parallel make
Ken Brown via Cygwin-apps writes: > Thanks, Marco. As expected, that fixes the problem for my test case > (building TeX Live). Obviously it would be better if the make > developers would provide a configure option to use a pipe for the > jobserver, but this is a good workaround if they don't. Does it actually do a parallel build? I've quickly tested a cmake based project with it and it completely serializes the build. Reverting to 4.4 resolves that problem. 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: [DEPRECATED] perl distributions
Jon Turney via Cygwin-apps writes: > I'm not sure what the word is for the status of these packages (but > they are all deprecated upstream, don't have a direct replacement, > probably aren't of any use to anybody, so clearly keeping them around > any longer is pointless...) When I wrote this originally, there was still the possibility that someone could reasonably keep the previous Perl version around and then expect to still have these packages available. That was my reason for not wanting to just delete them at that time, anyway. 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: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
Jon Turney writes: > The current upload policy is: > - Only the maintainer for a package maintainer is allowed to upload > that package. > - If a package is orphaned (has no maintainer), there are some > "trusted" maintainers who are allowed to upload it. > > I'm kind of inclined to relax that a bit, although I'm not sure what to. Given that any maintainer can push to the playground branch, we could either use that directly for someone(tm) to merge that branch into main and thus trigger the publishing / upload or create a separate NMU branch for the same purpose. 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: [Bug] setup regression #2
Christian Franke writes:
> Anything installed with "All Users" option should IMO be protected
> against modifications by any regular non-elevated user.
Yes.
> This is not the case if the RID=513 group ("HOST\None",
> "DOMAIN\Domain-Users") is used. Many upstream projects install
> directories and files with permissions like 0664, 0775, 0660 or
> 0770. This is safe when the group is "root". On current Cygwin, all
> users have R/W access regardless of the "other" permission bits.
Correct. That's why I was hoping I could use a dedicated group (either
local or domain depending the install) for "Cygwin Administrators".
> Using the administrators group as discussed here would solve this but
> apparently introduces interesting new permission problems with some
> packages. Could these possibly be solved by the maintainers of the
> affected packages?
The problem is not the Administrators group per se AFAICT, but the change
from a different group to another mid-flight. If the group could be
specified as alluded to above, I can keep the "wrong" group for existing
installs until I get around to fix their group ownership and ensure that
any new installs can be administered by whatever group of people will be
responsible for keeping things running smoothly.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: Cygwin x86 end-of-life
Brian Inglis writes: > As mingw64-i686 target is cross for native Windows 32, and we are > dropping Cygwin support for Windows 32, should we not also be dropping > cross support for native Windows 32, as so few people are using it, > and software developers, packagers, and distros, including us, are > dropping it as platform and target? I am unlikely to update that toolchain when I move gcc to version 12 or later. > Also there are 309 unmaintained mingw64 packages, so perhaps reducing > the double (over the base package) extra work of maintaining mingw64 > packages to a single extra cross might enable us to persuade some > maintainers to pick up unmaintained native Windows 64 cross > mingw64-x86_64 packages corresponding to the base packages they > maintain? I can't speak for others, but on my end there's not been much of a problem with having the MingW64 packages in two flavors in addition to the Cygwin dual architecture builds. Maybe we'll end up supporting ARM64 some way down the road and then it's going to be yet another target again for packagers. 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: [Bug] setup regression #2
Jon Turney writes: > I believe that the intent of the code in setup is that there should > only be two modes: > > USER: install "for me", with the users primary group As I understand it, the intention here was that the user can have a "single user installation" in a place that they have access to (say, their home directory) while they have no permission in one of the usual places. In a setup where that place is a certain type of share the user will not be able to change the group the files are owned by anyway (standard NetApp CIFS shares are set up this way) and it may not be the users primary group. > SYSTEM: install "for everyone", with the administrators primary group > (only permitted if you are an administrator) I don't see why the fact the installation is meant to be used by multiple users means that the install must be owned by group Administrators. I'm not sure this is a good idea on Windows anyway, at least when you don't put extra (inheritable) DACL on the install folder. I've never tried installing into the usual place (%ProgramFiles%) as that means that Windows enforces a number of rules that are different from Cygwin's and change non-domain vs. in-domain machines, applied GPO etc. So I'd really just introduce another parameter to specify what the group the installer uses should be and have the default depend on whether the user doing the install has administrative rights or not. A warning should be issued when that group is different from the existing root directory and of course the whole install should abort if the requested group can't be made primary. 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: Updated: mintty 3.6.2
Thomas Wolff writes: > I have uploaded mintty 3.6.2 with the following changes: Shouldn't this mail have been sent to the announce list instead? 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: Cygwin x86 end-of-life
Thomas Wolff writes: > ... Also I'd like to see the hopefully upcoming fix for the grep > package in the final 32 bit version. sed -i -E 's/^(cmd|echo)/#\1/' /bin/[fe]grep 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: [Bug] setup regression #2
Jon Turney writes: > On 08/10/2022 17:56, Achim Gratz wrote: >> I think that setup was essentially treating the install as "for this >> user only" since it was created and maintained by a script that can't >> affect that option and the fact it was also in group Adminsitroators >> didn't actually register until now. > > Yeah, that seems possible, since some of these changes fix what are > arguably bugs in how that works (i.e. I suspect that previously, even > when elevated, if only the registry key > HKEY_CURRENT_USER\\Software\\Cygwin\\setup\rootdir exists (and not the > same key under HKLM), we're going to install for "Just Me", > irrespective of what the UI says) I've checked some old logs and even though the install was identified as "system", there was no line "Changing gid to Administrators" for the main install until setup version 2.921. > I wrote some code for this option (attached), but I have a hard time > seeing how it's functionally different from using '-B/'--no-admin'. This option does nothing to prevent the use of Administrator group when the install is identified as "system" and those rights are actually available (which they are as the scripting needs those rights in other places). > So, I guess a question is, does running with that option work as > expected in your problematic instance? No, it does not, see above. The problem is actually a more knotty than you seem to think: prominently ca-certificates and man-db get their knickers in a twist when the group during post-install is different from the group of the installed files and I suspect some other packages will run into similar problems depending on how fussy they are with the group permissions. The symptom is that you see failures from chmod (for whatever reason "Invalid argument") when these programs try to swap the existing with the newly gerenated (temporary) files. In the case of man-db that results in the /var/cache/man/index.db file getting removed (and depending on the version the PID temporaries getting left in place), for update-ca-trust the mkstemp temporaries will be left over and the original files left in place. So all installs from before the change to setup are affected if the installation wasn't done via the GUI at least. I think it would be best to have an option to directly specify a desired group for both the installed files and running the post-install (which already must be in the user token). The default should be the primary group of the user doing the installation. I don't think the installation should be group-owned by "Administrators" on Windows. If anything it makes it much more difficult to administer the installation from within Cygwin as there doesn't seem to be a way to change to a different than the primary group for domain accounts yet. 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: Cygwin x86 end-of-life
Thomas Wolff writes: >> I plan to pause package uploads this coming Monday (2022-11-14), >> before starting the re-organization of the package repository to >> make this archive. > Although expected for a while, the exact date is now a very short-time > announcement. Can we have a moratorium for a short while? That moratorium is already running for more than a year: https://cygwin.com/pipermail/cygwin/2021-October/249690.html 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: [Bug] setup regression #2
Jon Turney writes: > On 08/10/2022 17:56, Achim Gratz wrote: >> I think that setup was essentially treating the install as "for this >> user only" since it was created and maintained by a script that can't >> affect that option and the fact it was also in group Adminsitroators >> didn't actually register until now. > > Yeah, that seems possible, since some of these changes fix what are > arguably bugs in how that works (i.e. I suspect that previously, even > when elevated, if only the registry key > HKEY_CURRENT_USER\\Software\\Cygwin\\setup\rootdir exists (and not the > same key under HKLM), we're going to install for "Just Me", > irrespective of what the UI says) I haven't checked that. >> The DACL on the server install changed from conferring access to "Everyone" >> to >> just the install user and SYSTEM IIRC. It doesn't do that on the >> (non-domain) build machine at home that runs Win10 Pro. > > That makes less sense to me. We should always creating an entry in > the DACL for 'Everyone' to hold the POSIX permissions for 'other' > users. Well, it wasn't there and whichever way it ended up that way, it was an inconvenient enough fix that I don'*t want to try it again on a productive system. > I wrote some code for this option (attached), but I have a hard time > seeing how it's functionally different from using '-B/'--no-admin'. > > So, I guess a question is, does running with that option work as > expected in your problematic instance? I'm not having enough time for checking right now, but I might test this hypothesis later on. Regard, 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: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
Brian Inglis writes: > Suggest that I could come up with a package grep-nowarn which can only > suppress the [ef]grep warnings, where the package would install > [ef]grep-nowarn, and the postinstall script could rename the > distributed shell scripts to [ef]grep-warn, and install alternatives > with -warn priority 10, -nowarn priority 20; preremove would reverse > the process. > > Suggestions to accommodate -nowarn from grep package postinstall? > I could supply the same postinstall and preremove as -nowarn to check > for -nowarn and install or uninstall the alternative. > > Sequence or timing issues to watch out for during postinstall/preremove? As Corinna already said, why GNU suddenly cares so much about strict POSIX conformance in this case is puzzling. If anything they should have left the decision to packagers and IMNHO the warning should only be presented when POSIXLY_CORRECT is set in the environment, if at all. The patch to the wrapper script(s) in question is trivial and several Linux distributions have removed the warning already (if you do this, also change the interpreter from bash to dash). Just skip any extra packages and do the same. 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: LICENSE values for non-standard OSS licenses
Adam Dinwoodie writes: > ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint > ERROR: package 'git-filter-repo': errors in license expression: ['Unknown > license key(s): LicenseRef-inherit-git, LicenseRef-inherit-libgit2, > LicenseRef-inherit-libgit2-examples'] > ERROR: errors while parsing hints for package 'git-filter-repo' > ERROR: error parsing /sourceware/cygwin-staging/home/Adam > Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint > ERROR: error while reading uploaded arch noarch packages from maintainer Adam > Dinwoodie > SUMMARY: 5 ERROR(s) > ``` > > So it looks like the issue is the way I've encoded the non-standard > licensing options. "LicenseRef-"(idstring) seems to be the way to > encode this sort scenario, per [1] and [2], but that doesn't seem to be > acceptable to calm. > > [1]: > https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ > [2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ As it should, since "inherit-git" or any of the other variations doesn't seem to be a valid license expression per the above. > Are there any suggestions about how to resolve this? I don't think I > can just use the standard license strings: even if we used GPL-2.0-only > in place of LicenseRef-inherit-git -- incorrect as that's the license > *currently* used by Git, but the license for git-filter-repo explicitly > incorporates any future OSS license Git might use -- that still leaves > the problem of LicenseRef-inherit-libgit2, which is currently GPL 2.0 > with an exception that's not covered by any of the SPDX standard > exceptions. Well I think you can, the license explicitely says you can chose any of them as you see fit, so you can pick one today and another tomorrow if you are so inclined. 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: [Bug] setup regression #2
Jon Turney writes: > On 03/10/2022 20:23, Achim Gratz wrote: >> Jon Turney writes: >>> This problem is with files created by setup, or by post-install scripts? >> I think both, although the problematic symlinks were created through >> alternatives. > > That's pretty baffling. Even more baffling is that I have another installation that are completely fine even with their Group now switched to Administrators. The one syxstem where I've had the problems is a server version and might have some GPO that affect thing that an admin user does. > I don't see how any of those commits would change the ownership of > files created by setup itself. The ownership is still with the user that runs the install script, however the group has changed. > The only relevant change seems to be in "Defer setting group until > after All Users/Just For Me is chosen", I've made > nt_sec.resetPrimaryGroup() explicit, but that only happens for > non-admin installs... I think that setup was essentially treating the install as "for this user only" since it was created and maintained by a script that can't affect that option and the fact it was also in group Adminsitroators didn't actually register until now. The DACL on the server install changed from conferring access to "Everyone" to just the install user and SYSTEM IIRC. It doesn't do that on the (non-domain) build machine at home that runs Win10 Pro. 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: [Bug] setup regression
Achim Gratz writes: >> Can you confirm if this fixes package selection for you? > > I'll have to setup a test installation to check this. I am currently > short on time, but I will try to wedge it in somehow. I wasn't able to do an exhaustive test, but the fix seems to be effective for the two scenarios I've tried (I've confirmed that both fail without the fix present). 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: [Bug] setup regression #2
Jon Turney writes: > This problem is with files created by setup, or by post-install scripts? I think both, although the problematic symlinks were created through alternatives. > (I'm not sure how these commits could have caused the former, if the > latter then reverting 45d8e84e "Drop group change while running > postinstall scripts" would be the thing to try...) As I said, I don't understand it either. It seems my installations were all using the primary group for the account that does the install (which does have administrative rights and is separate from my normal user account on most machines). The primary group is either "None" for the build machine that only uses local accounts and is not a member of any domain or "Domain Users" otherwise. The new code uses "Administrators", but that seems to have the side effect of denying "normal" users access to the installation and instead weaves in extra DACL for SYSTEM. As long as there's an option to force it to keep the former behaviour things should be OK, but I haven't really checked if and how this is possible. 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: [Bug] setup regression
Jon Turney writes: > Achim, > > Can you confirm if this fixes package selection for you? I'll have to setup a test installation to check this. I am currently short on time, but I will try to wedge it in somehow. 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
[Bug] setup regression #2
The release_2.91 comes with another regression that still puzzles me. In a nutshell, the three commits that deal with setting up the groups during / after installation 2022-08-27 Jon Turney Drop setting root_scope as a side-effect of read_mounts() 2022-08-16 Jon Turney Defer setting group until after All Users/Just For... 2022-08-16 Jon Turney Drop group change while running postinstall scripts break existing installs in certain circumstances that are not yet completely clear. The server installation @work (which uses exactly the same scripting around the installation that I use for my build system @home) changed from using the "Domain Users" group to "Administrators". Additionally the previous access for "Everyone" has been removed and instead SYSTEM is now part of the (Windows) ACL. In effect certain files have become inaccessible to the normal users (unless they are aso Administrators), in particular (this is the part that I still don't understand) newly created symlinks can't be read by a normal user even when the target is fully accessible. Even doing an ls on such a symlink gets a "permission denied". For the time being I've reverted the three commits and re-installed all packages that I had updated since the new setup was rolled out. Except for a handful of cache files for fontconfig (which I manually removed and recreated) that cleared up the whole thing. 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: [Bug] setup regression
Achim Gratz writes: > Achim Gratz writes: >> I had updated setup to 2.921 recently, so I rolled it back to 2.920 and >> this version does the package selection correctly. I haven't yet looked >> what commit is responsible, but whatever the cause of the regression is >> still in 2.922 as well. > > The most likely change responsible for this is the additions in > package_meta.cc in commit c99e4c14911181636892355a4f1855024051ea1d. I > might not be able to check this tomorrow, though I'll try to free up > some time for that. That was indeed the culprit. I've reverted just these two hunks on top of release_2.922 and things worked again. 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: [Bug] setup regression
Achim Gratz writes: > I had updated setup to 2.921 recently, so I rolled it back to 2.920 and > this version does the package selection correctly. I haven't yet looked > what commit is responsible, but whatever the cause of the regression is > still in 2.922 as well. The most likely change responsible for this is the additions in package_meta.cc in commit c99e4c14911181636892355a4f1855024051ea1d. I might not be able to check this tomorrow, though I'll try to free up some time for that. 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
[Bug] setup regression
Today I did a new installation of Cygwin @work and setup correctly registered around 1500 packages as "manually selected" (I have a setup.ini that has all packages to be installed in one group and setup gets asked to install this group), then somehow decided to only install 75 of those. In other words not even all packages from Base got installed. I had updated setup to 2.921 recently, so I rolled it back to 2.920 and this version does the package selection correctly. I haven't yet looked what commit is responsible, but whatever the cause of the regression is still in 2.922 as well. Apparently updates are not affected or at least I didn't see an issue with it during the time I was using the 2.921 version. 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] Perl distributions
Jon Turney writes: > On 17/09/2022 08:58, Achim Gratz wrote: >> perl-Alien-CFITSIO >> perl-File-ShouldUpdate >> perl-Sort-Versions > > Done. Thank you. 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
[ITP] Perl distributions
I need to package a few newly introsuced nuild dependencies for Cygwin: perl-Alien-CFITSIO perl-File-ShouldUpdate perl-Sort-Versions Can these please be added to my list of packages? 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: cygport
Jon Turney writes: > I'm not keen on reviewing patches supplied that way, but ok... Suggest an alternative perhaps? >> 5bc72c1 lib/pkg_pkg: allow suppression of spurious package dependencies > > As far as I recall, previous discussion of this petered out with > "please give a concrete example where the dependency autodetection is > wrong, and explain why it can't be fixed". > > If I'm misremembering, please point that out. I need to use this in perl.cygport or else perl_base creates a circular dependency to perl. Perl has several modules (the official one is Module::ScanDeps) that try to figure out which deppendencies a Perl program might have, but even these produce both false positives and negatives. The simplistic grep/sed filter that fishes out everything that looks like a use or require statement is mostly produces false positives, since it doesn't consider conditionals. > The new variable this introduces needs documenting. > >> f5764cf lib/pkg_info.cygport: implement automatic determination of the >> appropriate perl5_0xy requirement > > This looks like a fix for the previous commit, mixed in with some > rebase detritus. Yeah, I guess the pkg_bin_requires part hopped over the previous patch. >> f1fdfb4 lib/src_prep.cygpart: process various checksum digests > > The change to cygpatch to allow .xz and .zst compressed patches needs > breaking out as a separate change. That should also improve the > documentation of PATCH_URI to mention that it handles compressed patch > files transparently. OK. > This needs a documentation change to mention when prep will verify > checksums. > > It seems that __chksum_verify() ignores the result of running *sum. Why? The test is not very robust against hand-produced or otherwise slightly modified checksum files. In any case it follows the example of the GPG signature check in that regard. > Ideally, a test should be added or extended to exercise this. > >> 63e00e5 lib/src_prep.cygpart: determine and deal correctly with another type >> of checksum > > This should be combined with the previous patch? Hysterical raisins… that was in fact added later since I hadn't encountered one of those before. I can merge the two patches no problem. >> 8a325c5 bin/cygport.in: make system-wide defaults overrideable by user >> defaults and provide ability to change initial MAKEOPTS via CYGPORT_MAKEOPTS > > This seems to be two separate changes. > > The documentation for cygport.conf should be updated to reflect that > ~/.cygport.conf overrides /etc/cygport.conf. > > What it the use case for being able to override MAKEOPTS with a > environment variable? I've ran into trouble with Makefiles that are not parallel safe a few times, so I wanted a way of playing with that without having to modify the cygport each time. It's more convenient to specify that on the command line. > CYGPORT_MAKEOPTS needs documenting. OK. >> 74935d6 bin/cygport.in, lib/help.cygpart: implement --jobs/-j N option to >> specify number of jobs to use > > This seems to contain part of the previous change, removing the break > when looping over config files. > > Why do we need both -j and CYGPORT_MAKEOPTS? Well strictly we don't need it, ensuring that the approrpiate number of processors get used is important to me for parallel package builds (the more packages that can be built in parallel, the less number of cores each individual job gets assigned). CYGPORT_MAKEOPTS was introduced and proved useful for debugging much earlier, so I kept it around even though I don't want to use it for the purpose of just controlling the number of job slots. >> 191 allow for different package compression types and implement >> ZStandard decompression > > The change to unpack .tar.zst or .zst sources needs to be separate. OK. > Ideally, a test should be added or extended to exercise that. > > If the intention is to set CYGPORT_TAR_EXT and CYGPORT_TAR_CMD in the > cygport, I don't think they need the CYGPORT_ prefix. Since these variables bleed into the environment I'd like to play it safe. > These variables need documenting. > > This seems like a weird implementation to me. Why can't cygport set > TAR_CMD to invoke tar with the appropriate compression option, > depending on what TAR_EXT is set to? Because not all tar implementations support auto-compression based on the extension. In particular, Cygwin's tar did not yet recognise .zst as a valid extension when this was introduced. The other reason is that with auto-compression the compression level can not be modified for several compression types and it's useful to change some other things via this facility. This was briefly discussed when the patch was posted initially: https://inbox.sourceware.org/cygwin-apps/87tuzd7vyp.fsf@Rainer.invalid/ >> 34502d2 (stromenko/to-upstream) lib/src_install.cygpart: make_etc_defaults, >> create diff if files aren't matching > > This seems kind of useful, but what's the reasoning behind saving a > diff vs.
Re: Cygport: How can I ignore duplicated files in packages
Hamish McIntyre-Bhatty writes:
> Today I'm attempting to update my python-imaging package, but I'm now
> finding that cygport has made the warning about duplicated files an
> error.
I don't think anything has changed there lately?
> The source is at: https://gitlab.com/hamishmb/cygwin-python-imaging
>
> Files are duplicated in these packages because there are .py files for
> each python release in /usr/lib/python3.*.
A duplicate is a file that shows up at exactly the same path in more
than one package. These files don't fit that description as files with
the same name are in separate paths, so what is the actual problem?
> This doesn't seem to actually break package creation, but I'd like to
> get this reproducing correctly in scallywag, which I think will flag
> as failed because of this error.
I think you create it yourself here (and analogous for the other Python
versions):
--8<---cut here---start->8---
python36_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python36_imaging_CONTENTS}
"
--8<---cut here---end--->8---
which seems to package the same files twice in one archive when
expanded.
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: Dropping requires: from setup.ini?
Jon Turney writes: > Perhaps it's time to consider dropping the requires: line from setup.ini? I guess the only way to find out is to actually do it and see who complains… maybe if Cygwin 3.4 is imminent that update would be a good time to make that change. 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: gnupg version 1 and 2
Marco Atzeri writes: > I noticed that debian and fedora packages have moved v1 > to provide /usr/bin/gpg1 > and have gpg a link to gpg2 (or reverse) That link, then, should be provided by the alternatives system. > gnupg package to provide gpg1 and gnupg2 to provide gpg and gpg2 I have no clear preference as to what the default alternative should be, but it should be changeable by the user. So simply packaging up the link isn't going to cut it. One of the holdouts for gpg is cygport, I haven't checked if gpg2 would need changes to the invocations there. 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: calm/mksetupini changes
Achim Gratz writes: > Lemures Lemniscati writes: >> Although libiconv2 is contained in the list above, >> I don't think it is deprecated. > > I think you missed the point that Jon was trying to make …or I missed that 1.17 is still test. :-P 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: calm/mksetupini changes
Lemures Lemniscati writes: > Although libiconv2 is contained in the list above, > I don't think it is deprecated. I think you missed the point that Jon was trying to make: we currently have many library packages at various versions (those with the actual libraries) that other packages depended on at some point in time. If there already is a newer version of such a package and there are still dpendencies that point to an older version, that means those packages should eventually get rebuilt to use that newer version (if not ABI compatible) or just use the newest version without any prodding (if ABI compatible), which in turn means that the old versions can get removed along with the corresponding source and debuginfo packages that were solely kept alive by these dependencies. In the case of libiconv2 the current version for Cygwin is 1.17-1 and the library should be ABI compatible with all previous versions, so these old versions up to and including 1.16-2 are deprecated since setup will never install them unless forced manually. 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: [ITA] duplicity
Libor Ukropec writes: > I'll answer it myself. If the cygport is given the filename *without* > ".cygport" extension, it executes, but wrongly detects the PVR - > NAME/VERSION/RELEASE. When I provided full name, it works as I'd > expected. I think this deserves improvement. https://repo.or.cz/cygport/rpm-style.git/commitdiff/f25657a4db0e0054789563b1857cab7ab947e71e Yaakov didn't like the idea for whatever reason I can't remember (the original patch must be at least ten years old by now)), so this is only in my fork. 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
Jon Turney writes:
>> @@ -412,6 +413,7 @@ __list_deps() {
>> do
>> if [ -f ${d}/${pldep//:://}.pm ]
>> then
>> + case "${d##*/}" in 5.[0-9][0-9])
>> plver+="$pldep " ;; esac
>
> Is the mistake thinking pldep here is a pathname, not a module name?
Most likely yes, although I'd have to see what kind of data triggers
this clause.
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
[ITA] {mingw64-{i686,x86_64}-,}zlib
MinGW64 packages currently orphaned by Yaakov, Cygwin package currently maintained by Ken (OK to take over given via IRC). Update to 1.2.12 (security) and removal of minizip (not used on Cygwin and minizip fork is packaged separately already). 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: [ATTN MAINTAINER] opencv
Achim Gratz writes: > I have pushed some patches from a user on IRC to the playground branch > that enable updating opencv to latest upstream. There are some > unresolved issues that need some more attention: […] These are all fixed after installing the proper devel packages and two edits to the cygport, force-pushed to https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/opencv.git;a=shortlog;h=refs/heads/playground Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
[ATTN MAINTAINER] opencv
I have pushed some patches from a user on IRC to the playground branch that enable updating opencv to latest upstream. There are some unresolved issues that need some more attention: 1. Both OpenEXR and protobuf get captive builds via bundled sources instead of using the system libraries. OpenEXR may not be up-to-date enough on Cygwin, although I haven't spotted any attempt to detect it during configuration. The bundled protobuf is older than the one on Cygwin and has a (probably irrelevant for this case) CVE pending. 2. The use of non-free codecs seems to be switched on, I have not checked how to stop that. https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/opencv.git;a=shortlog;h=refs/heads/playground 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: cygport
Jon Turney writes: > A few comments after looking at: > > lib/pkg_info.cygport: implement automatic determination of the > appropriate perl5_0xy requirement > 1. In __list_deps(), this should look at the files list in $@, not at > files in $D, as that causes it to identify a perl5_0xy dependency for > all subpackages, irrespective of which package (if any) contains the > files in the vendor_perl directory. > > 2. This only identifies the perl5_0xy requirement for packages which > own files in the vendor_perl directory, not for packages which contain > executables or shared libraries dynamically linked with > cygperl5_xy.dll. That should at least be mentioned in the patch > commentary. I've fixed both of these on the to-upstream branch I think. 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
Jon Turney writes: > lib/pkg_info.cygport: implement automatic determination of the > appropriate perl5_0xy requirement > 1. In __list_deps(), this should look at the files list in $@, not at > files in $D, as that causes it to identify a perl5_0xy dependency for > all subpackages, irrespective of which package (if any) contains the > files in the vendor_perl directory. I guess I didn't have a package with those characteristics. Will change. > 2. This only identifies the perl5_0xy requirement for packages which > own files in the vendor_perl directory, not for packages which contain > executables or shared libraries dynamically linked with > cygperl5_xy.dll. That should at least be mentioned in the patch > commentary. Hmm. Example package to test this with? 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: scallywag cygport fails to detect perl script runtime dependencies
Brian Inglis writes: > Does cygport require perl modules to be installed as build > dependencies in order to enable their detection as runtime > dependencies for perl scripts in packages? Yes, although the particular way of how this is done frequently produces false dependencies (there is no distinction between optional and required dependencies). In principe you could also end up with missed dependencies, although I know of no example for this. 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: Changes/CurlMinimal as Default - Fedora Project Wiki
Brian Inglis writes: > Any thoughts on whether we should follow Fedora's lead: > > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default > > and should we ask users how much use there is of other protocols? I think setup and users would have trouble chosing between the minimal and the full curl variant. All things considered, I think it's not worth the effort at this time. 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
[ITA] pkgconf, {mingw64-{i686,x86_64},}xz
Packages orphaned by Yaakov, updates available for inspection: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=commitdiff;h=2e3cdeef37b04ac69de0662b0f257b8ff46f1b63 https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/xz.git;a=commitdiff;h=6aa8e8e5f94c6290693c403665703a74a4612a6f (build artifacts 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: Go or Rust Packages?
Achim Gratz writes: > Pulling out this and another stop successfully configures and actually > builds a gccgo executable sometime later. If any of this actually works > remains to be seen. The compiler itself seems to be working (for some definition of working), but the compilation of libgo fails at some point: --8<---cut here---start->8--- make[4]: Entering directory '/mnt/share/packages/gcc/gcc.x86_64/build/x86_64-pc-cygwin/libgo' /usr/bin/mkdir -p os/signal/internal; files=`echo | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile /mnt/share/packages/gcc/gcc.x86_64/build/./gcc/gccgo -B/mnt/share/packages/gcc/gcc.x86_64/build/./gcc/ -B/usr/x86_64-pc-cygwin/bin/ -B/usr/x86_64-pc-cygwin/lib/ -isystem /usr/x86_64-pc-cygwin/include -isystem /usr/x86_64-pc-cygwin/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=`echo os/signal/internal/pty.lo | sed -e 's/.lo$//'` -o os/signal/internal/pty.lo $files libtool: compile: /mnt/share/packages/gcc/gcc.x86_64/build/./gcc/gccgo -B/mnt/share/packages/gcc/gcc.x86_64/build/./gcc/ -B/usr/x86_64-pc-cygwin/bin/ -B/usr/x86_64-pc-cygwin/lib/ -isystem /usr/x86_64-pc-cygwin/include -isystem /usr/x86_64-pc-cygwin/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=os/signal/internal/pty -DDLL_EXPORT -o os/signal/internal/.libs/pty.o gccgo: fatal error: no input files compilation terminated. make[4]: *** [Makefile:3001: os/signal/internal/pty.lo] Error 1 --8<---cut here---end--->8--- Since this is in the os subtree my guess is that this happens due to the non-recognition of Cygwin somewhere else. 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: Go or Rust Packages?
ASSI writes: > Go might be salvageable if the go frontend to go is usable, I haven't > had time to look at that. I've went ahead and tried to activate go in gcc and it doesn't even get past the very beginning of confdigure: --8<---cut here---start->8--- configure: WARNING: go not supported for this target configure: error: The following requested languages could not be built: go --8<---cut here---end--->8--- Pulling out this and another stop successfully configures and actually builds a gccgo executable sometime later. If any of this actually works remains to be seen. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: tcsh /etc/default files
Corinna Vinschen writes: > Fine with me, but these files are not part of the distro package > only. They are part of the upstream tcsh package and just copied > into the right place by a cygwin-specific postinstall step, also > part of the upstream Makefile. Hmm, OK. Preferrably we wouldn't install them with tcsh and leave that to base-files. > I'm going to send the patch upstream, with a very minor tweak it > applies cleanly. That'll hopefully work. 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
tcsh /etc/default files
I'm not certain if I ever discussed this before, but the recent tcsh
update reminded me that I think the defaults should be changed a little
bit. First off, running the scripts in profile.d should IMHO be done in
csh.login to ensure it's only done once. Secondly the (optional)
cleaning up of the PATH variable already introduced for all POSIX shells
in base-files years ago should be replicated for tcsh. Lastly, since
/usr/bin/ and /bin are the same thing on Cygwin, one of them is
redundant and placement of /usr/local/bin should be left at the
discretion of the user since tha directory does not exist by default on
Cygwin.
--8<---cut here---start->8---
--- /etc/defaults/etc/csh.cshrc 2022-02-03 18:25:13.0 +0100
+++ /etc/csh.cshrc 2019-06-02 19:07:20.072715800 +0200
@@ -3,16 +3,6 @@
#
onintr -
-if ( -d /etc/profile.d ) then
- set nonomatch
- foreach _s ( /etc/profile.d/*.csh )
-if ( -r $_s ) then
- source $_s
-endif
- end
- unset _s nonomatch
-endif
-
if (! ${?prompt}) goto end
# This is an interactive session
--- /etc/defaults/etc/csh.login 2022-02-03 18:25:13.0 +0100
+++ /etc/csh.login 2019-06-02 19:07:19.229253700 +0200
@@ -4,7 +4,21 @@
unsetenv TEMP
unsetenv TMP
-set path=( /usr/local/bin /usr/bin /bin $path:q )
+set winpath = ( $path:q )
+if ( ${?CYGWIN_NOWINPATH} ) then
+ set path=( /usr/bin )
+else
+ set path=( /usr/bin $path:q )
+endif
+if ( -d /etc/profile.d ) then
+ set nonomatch
+ foreach _s ( /etc/profile.d/*.csh )
+if ( -r $_s ) then
+ source $_s
+endif
+ end
+ unset _s nonomatch
+endif
if ( ! ${?USER} ) then
set user="`id -un`"
--8<---cut here---end--->8---
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] libwebp (ORPHANED YS)
Brian Inglis writes: > I picked up the package because I thought our images at > cygwin-htdocs/goldstars/img/ seemed large for small icons: > > $ wc -c img/* > 3473 img/dungbomb.png > 1074 img/goldstar.png > 1303 img/goldwatch.png > 9382 img/pinkwatch.jpg >877 img/platinumwatch.jpg >878 img/plush_hippo.jpg > 1055 img/silverstar.png > 18042 total Getting the package up to the latest version is good, but I'm not really fond of the WebP image format at all. > so converted them and found they were much smaller in webp format, and > reconverting using the upgraded package command: > > $ cwebp -blend_alpha 0xff img/$img -o images/$i.webp > > $ wc -c images/* > 220 images/dungbomb.webp > 284 images/goldstar.webp > 286 images/goldwatch.webp > 322 images/pinkwatch.webp > 232 images/platinumwatch.webp > 204 images/plush_hippo.webp > 174 images/silverstar.webp > 1722 total This is with the lossy WebP compression, right? 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: Using ZChunk for setup…
Jon Turney writes: > How would the signature be checked? Is it for the reconstructed full > zchunk file? The signature should be for the full (reconstructed) file I think, the individual chunks of the changeset are locked in by SHA256 checksums anyway. > One slightly related issue which it would be good to address if > possible when adding this is that rsync is only file-atomic, not > repo-atomic, so we may get a compressed ini file and signature which > don't match as they are different moments in time during an update. I > think currently no-one notices this if it happens, as setup silently > falls back to an older compression type, but it would be nice to stop > generating those eventually. One of the things I am still thinking about is switching from the ini format to YAML. In this case the signature could/should be part of the data structure (JOSE/COSE style), so you'd only ever have to look at a single file and it wouldn't matter how you got it together. 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: A change to how calm expires packages
Jon Turney writes: > This change will cause the following packages to be removed: > > _autorebase-001091-0.1 > gcc-11.2.0-0 > mingw64-i686-gcc-11.1.0-0.1 > mingw64-i686-gcc-11.2.0-0 > mingw64-i686-gcc-7.3.0-1 > mingw64-x86_64-gcc-11.1.0-0.1 > mingw64-x86_64-gcc-11.2.0-0.1 > mingw64-x86_64-gcc-7.3.0-1 That looks about right, thanks. 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
ansible
There was a request on IRC to update the ansible package. I've had a quick look, the tentative result is on the playground branch: https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/ansible.git;a=shortlog;h=refs/heads/playground As mentioned by Yaakov, I switched over to ansible-core, updated the patches and made some changes so that th CI would have a chance to build the package. Some of the necessary packages are missing for python39 so I had to keep this at python37 and one (python37-straight.plugin) doesn't currently exist at all. The latter may not actually be needed anymore, but the package build doesn't work anyway. Someone with more knowledge of python would need to look at where exactly the problem is (the "packaging" module seems to be missing even though it's in the BUILD_REQUIRES) and provide a fix. 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: [ITP] biosig [was: Re: newcomer issues when packaging biosig, stimfit, etc.]
Marco Atzeri writes: > add DIFF_EXCLUDES="Makefile" to avoid the artifact DISTCLEANFILES would be more appropriate it seems. 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
cygport
I've rebased the remaining patches on my to-upstream branch onto the current release of cygport: https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream Note that some of these are required to correctly build and distribute Perl and its modules for Cygwin (which is one reason I carry these for several years now). 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
hwloc pulls in clang
The recent (still un-announced) update of hwloc pulls in clang via a dependency chain going through some OpenCL stuff. Can this please be reverted? Personally I'd rather live without whatever functionality is provided that way if that dependency cannot be made optional; also, clang is unmaintained on Cygwin for quite a while, so adding that dependency now seems wrong. 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
Using ZChunk for setup…
I've been experimenting with ZChunk with the idea of eventually using it for setup: https://www.jdieter.net/posts/2018/05/31/what-is-zchunk/ https://github.com/zchunk/zchunk The chunked ini file is ~10…15% larger than the original (after compression). In order to minimize the overhead, I've re-arranged the package entries to have one chunk for every source package. The actual benefit is that the typical download size reduces to less than 5% of the original. Two examples of much longer timespans between updates are provided at the end, which would still download only around a third of the original: --8<---cut here---start->8--- # no changes, only header gets downloaded update from 20220109 to 20220109 Would download 82277 of 4061994 bytes Matched 4103 of 4103 chunks update from 20220106 to 20220109 Would download 112022 of 4061994 bytes Matched 4078 of 4103 chunks update from 20211221 to 20220106 Would download 172069 of 4061583 bytes Matched 4024 of 4103 chunks update from 20211218 to 20211221 Would download 216879 of 4052330 bytes Matched 4012 of 4098 chunks update from 20211204 to 20211218 Would download 248101 of 4020714 bytes Matched 3997 of 4097 chunks update from 20200102 to 20210703 Would download 1438581 of 3960442 bytes Matched 2938 of 4087 chunks update from 20190101 to 20200102 Would download 1139408 of 3723670 bytes Matched 3142 of 3987 chunks --8<---cut here---end--->8--- WDYT? 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: perl_base not in Base ?
Am 29.12.2021 um 17:12 schrieb Jon Turney: I think this was the case, at one time. As I said before, at least info still does; not directly, though (it requires a bunch of Perl module distribution that will then pull in perl_base at least). -- Achim. (on the road :-)
Re: perl_base not in Base ?
Am 29.12.2021 um 15:25 schrieb Ken Brown: It makes sense to me to add it to Base. Were there any objections when that was proposed before? I don't remember, honestly. There were/are a few problems w/ cygport trying to pull in perl as a dependency for perl_base, but I've patched those out locally. Again, most if not all Linux distributions have perl_base in their default installation so it can be used in system scripts. We don't have these at the moment, but we might want to later on. Or is it supposed to be pulled by another Base program ? Base packages should not pull in non-Base packages, but it appears that info currently fails that requirement. A lot of packages fail that requirement. I don't think it should be a requirement. To me, Base packages are those that we've decided should be in every Cygwin installation. If that forces other packages to be installed, so be it. As long as there is no distinction between required and recommended in our packaging system I think we should not have packages that are required from Base packages, but are not themselves in Base, e.g. installing "Category Base" should be idempotent with installing all packages in category Base. We have a bunch of packages that are deliberately split so that one of them can be in category base without pulling in hundreds of dependencies that are only needed for optional functionality. -- Achim. (on the road :-)
Re: perl_base not in Base ?
Am 28.12.2021 um 11:57 schrieb Marco Atzeri: I had the impression it was in the Base category @ perl_base sdesc: "Perl programming language interpreter" ldesc: "Perl programming language interpreter That split was indeed made to enable making it available for Base packages, but that decision was never made I think. Or is it supposed to be pulled by another Base program ? Base packages should not pull in non-Base packages, but it appears that info currently fails that requirement. -- Achim. (on the road :-)
Re: [ITP] autoconf2.7
Ken Brown writes: > I agree, as I already said in a different thread. Either way, there > remains the question of how to get cygport patched. Until that > happens, no maintainers can use autoconf 2.71 unless they patch > cygport locally, and no SCALLYWAG builds can use autoconf 2.71. I've updated the patch: https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream 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: gnulib m4/threadlib.m4 bug crashing package tests
Achim Gratz writes: > The root cause of this mystery is almost surely in binutils, this area > was touched when they moved the default base address past the 4GiB > boundary (obviously that's a 64bit only change and it only affects PE > targets). I still have to figure out if I need to pull in a patch from > after the release or revert commits that went into 2.37. A lengthy git bisect has turned up the offending commit, which was something that shouldn't obviously interact with weak symbol resolution, but does. I've reported it upstream… 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] autoconf2.7
Achim Gratz writes:
> + case "${WANT_AUTOCONF}" in
> + 2.5|'')
> + WANT_AUTOCONF=2.5
> + case $(autoconf --version 2> /dev/null | head -n 1) in
> autoconf*2.[56]?) ;;
> *) error "autoconf2.5 is required to build this
> package" ;;
> + esac
> + ;;
> + 2.7)
> + WANT_AUTOCONF=2.7
If anybody prefers cygport to default to 2.7, then the "|''" part of the
above patch needs to be moved to the pattern clause for 2.7.
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
[PR] cygport (update required for autoconf-2.71)
In order for cygport to work correctly when autoconf 2.71 is requested, please pull the first commit (b25cb3faa) on my to-upstream branch into upstream and release a new version. I'd appreciate if the full branch would be pulled, these are all used by me for quite some time already. e33b0b7f1 * to-upstream lib/src_install.cygpart: make_etc_defaults, create diff if files aren't matching e8c309317 * allow for different package compression types and implement ZStandard decompression 2c965ecf2 * bin/cygport.in, lib/help.cygpart: implement --jobs/-j N option to specify number of jobs to use 7288020d1 * bin/cygport.in: make system-wide defaults overrideable by user defaults and provice ability to change initial MAKEOPTS via CYGPORT_MAKEOPTS 385512226 * lib/src_prep.cygpart: determine and deal correctly with another type of checksum 55d95d676 * lib/src_prep.cygpart: process various checksum digests ff9c374bd * lib/pkg_info.cygport: implement automatic determination of the appropriate perl5_0xy requirement d860387e4 * lib/pkg_pkg: allow suppression of spurious package dependencies 7fc3c4951 * lib/pkg_pkg.cygpart: stop generating packages for obsoletions 6a06d9ef5 * cygclass/perl.cygclass: do not clobber HOMEPAGE and provide a correct default 210b16fa8 * cygclass/git.cygclass: use shallow clones for branches and tags also b25cb3faa * cygclass/autotools.cygclass: recognize WANT_AUTOCONF=2.7 / autoconf2.7 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: [ITP] autoconf2.7
Achim Gratz writes: > I should als get autoconf and autoconf-archive I think, I haven't looked > at the other auto* stuff, but eventually we will need a new automake. It turns aout that automake 1.16 has a minro updtae that deals with autoconf 2.71 stuff. So please give me automake* as well. 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] autoconf2.7
Achim Gratz writes: > As discussed in another thread, Cygwin should have an autoconf2.7 > package going forward. It builds just out of the box, so here's the ITP > for it. https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/autoconf2.7.git;a=shortlog;h=refs/heads/playground https://ci.appveyor.com/project/cygwin/scallywag/builds/41765733/job/3xds3v63e29q9i6b 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: [ITP] autoconf2.7
ASSI writes:
> Hmm. That looks wrong, the Gentoo folks rolled both 2.70 and 2.71 into
> the WANT_AUTOCONF=2.5 category (which likely works for them). So yay,
> I'll have to patch that.
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/autoconf.git;a=shortlog;h=refs/heads/playground
https://ci.appveyor.com/project/cygwin/scallywag/builds/41765363/job/2pix82o872hjofj9
This will also simplify that cygport autotools patch to (default
autoconf is still 2.69 for the moment):
--- /usr/share/cygport/cygclass/autotools.cygclass
+++ #
@@ -391,12 +391,21 @@
warning "libtool is incompatible with autoconf-2.13";
fi
;;
- 2.5|'')
- WANT_AUTOCONF=2.5
-
- case $(autoconf --version 2> /dev/null | head -n 1) in
+ 2.5|2.7|'')
+ case "${WANT_AUTOCONF}" in
+ 2.5|'')
+ WANT_AUTOCONF=2.5
+ case $(autoconf --version 2> /dev/null | head -n 1) in
autoconf*2.[56]?) ;;
*) error "autoconf2.5 is required to build this
package" ;;
+ esac
+ ;;
+ 2.7)
+ WANT_AUTOCONF=2.7
+ case $(autoconf --version 2> /dev/null | head -n 1) in
+ autoconf*2.[7]?) ;;
+ *) error "autoconf2.7 is required to build this
package" ;;
+ esac
esac
if __config_equals with_libtool 1
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: [ITP] autoconf2.7
Marco Atzeri writes: > are you taking also over the current packages ? I don't see them getting updated, but if you feel better about it then let me have them. > Just to patch "cygwin-pkg-maint" only one time ;-) I should als get autoconf and autoconf-archive I think, I haven't looked at the other auto* stuff, but eventually we will need a new automake. Not sure what automoc is, something for cmake I guess. 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
[ITP] autoconf2.7
As discussed in another thread, Cygwin should have an autoconf2.7 package going forward. It builds just out of the box, so here's the ITP for it. Playground (based on autotools2.5, I'll cut the old history in the new repo): https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/autoconf2.7 CI Build: https://ci.appveyor.com/project/cygwin/scallywag/builds/41751127/job/axabuukd3w4xvsy7 I've switched off the tests, they take too long anyway. 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: autoconf
Achim Gratz writes:
> In light of the fact that 2.71 again is not backwards compatible, that
> patch needs to be somewhat more extensive and include different
> WANT_AUTOCONF settings.
Something like this, which keeps the default autoconf version at 2.69
for the moment (and is untested right now).
--- /usr/share/cygport/cygclass/autotools.cygclass
+++ #
@@ -391,12 +391,21 @@
warning "libtool is incompatible with autoconf-2.13";
fi
;;
- 2.5|'')
- WANT_AUTOCONF=2.5
-
- case $(autoconf --version 2> /dev/null | head -n 1) in
+ 2.5|2.7|2.71|'')
+ case "${WANT_AUTOCONF}" in
+ 2.5|'')
+ WANT_AUTOCONF=2.5
+ case $(autoconf --version 2> /dev/null | head -n 1) in
autoconf*2.[56]?) ;;
*) error "autoconf2.5 is required to build this
package" ;;
+ esac
+ ;;
+ 2.7|2.71)
+ WANT_AUTOCONF=2.71
+ case $(autoconf --version 2> /dev/null | head -n 1) in
+ autoconf*2.[7]?) ;;
+ *) error "autoconf2.7 is required to build this
package" ;;
+ esac
esac
if __config_equals with_libtool 1
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
DIY Stuff:
http://Synth.Stromeko.net/DIY.html
Re: autoconf
Ken Brown via Cygwin-apps writes: > On 12/2/2021 5:15 AM, Jan Nijtmans via Cygwin-apps wrote: >> Somewhere in cygport, a check is done for the autoconf version, please >> change this check to allow autoconf 2.71 (as well as 2.59 and 2.69). >> Then I can put back the "cygautoreconf" line in tcl.cygport. > > You can do this locally until someone gets around to patching cygport. > Just patch /usr/share/cygclass/autotools.cygclass like this: > > --- autotools.cygclass~ 2020-05-10 12:06:42.0 -0400 > +++ autotools.cygclass 2021-12-02 08:14:34.546334100 -0500 > @@ -395,7 +395,7 @@ > WANT_AUTOCONF=2.5 > > case $(autoconf --version 2> /dev/null | head -n 1) in > - autoconf*2.[56]?) ;; > + autoconf*2.[567]?) ;; > *) error "autoconf2.5 is required to > build this package" ;; > esac In light of the fact that 2.71 again is not backwards compatible, that patch needs to be somewhat more extensive and include different WANT_AUTOCONF settings. 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: autoconf
Marco Atzeri via Cygwin-apps writes: > anyone working or planning to take over the Autoconf ? I haven't, but looking at the packages I picked up maybe I should. > The 2.71 version seems becoming popular in some package source code. How likely is it that they actually rely on that version already? 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: gnulib m4/threadlib.m4 bug crashing package tests
Brian Inglis writes: > The problem with Cygwin weak symbols is apparently that ld expects > there to be a runtime dynamic loader to resolve NULL weak dynamic > library references, but unlike ELF neither Cygwin nor Windows does so, > and PE may not retain the information to do so, or this project would > likely have done so. No, that part is well understood since more than a decade when that problem first hit, the actual problem is that such symbols no longer resolve to 0x0 on 64bit. 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 MAINTAINER] openssh
Corinna Vinschen via Cygwin-apps writes: > On Nov 28 10:53, Achim Gratz wrote: >> Achim Gratz writes: >> > These patches work for 32bit also and I believe they are correct, but >> > that build should not be made available due to a bug in libfido2 that >> > crashes when trying to free the memory associated with the WebAuthn >> > payload returned. Without these patches applied you can still use the >> > fallback to USB-HID when you are an administrator. >> >> The call into WebAuthn completely messes up the stack apparently. The >> returned object looks OK once you realize it is a version 1 and thus the >> extension fields are bogus, but the whole thing crashes if you do just >> one more call. Gdb session: >> >> https://paste.c-net.org/SerumLoser >> >> Any ideas what that might be? > > For the bystanders, on a hunch I created a libfido2 patch to change > the calling convention for the dynamically loaded windows functions. > Let's see if Achim's testing now succeeds on 32 bit... It does, your hunches are _that_ good. :-) So, once the new libfido2 hits the release area you can pull in the OpenSSH patches and re-release that to take advantage of the now correctly working Webauthn suppport. 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: gnulib m4/threadlib.m4 bug crashing package tests
Ken Brown via Cygwin-apps writes:
> You're right, I was wrong. Here's the gnulib test program for anyone
> else who wants to look at this:
>
> #include
> #pragma weak fputs
> int main ()
> {
> return (fputs == NULL);
> }
>
> As you said, this used to return 1, but now it returns 0 on 64-bit.
The root cause of this mystery is almost surely in binutils, this area
was touched when they moved the default base address past the 4GiB
boundary (obviously that's a 64bit only change and it only affects PE
targets). I still have to figure out if I need to pull in a patch from
after the release or revert commits that went into 2.37.
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: gnulib m4/threadlib.m4 bug crashing package tests
Ken Brown via Cygwin-apps writes: > It's gnulib that changed, not Cygwin or gcc/binutils. This is > actually an old issue: > > https://cygwin.com/pipermail/cygwin/2010-April/186342.html I've built the exact same package (man-db) this Febrary without that problem and now again with that problem (it doesn't help that the test suite never actually runs the failing executable). The gnulib test failed (as it still does on 32bit) for 64bit in February, but succeeds (resulting in gnulib trying to use weak symbols) now. 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: gnulib m4/threadlib.m4 bug crashing package tests
Achim Gratz writes: > I'd rather know why the bleeping heck the test suddenly succeeds when it > clearly doesn't actually work. In other words, I think the linker > should complain, but since it obviously did that before Cygwin 3.2.0 and > not after, something must have changed somewhere that prevent s it from > doing that. So the exact same problem was discussed in 2010 and the test that's still there conceived that checks if the returned symbol for weakly defined fputs is NULL (which would then disable weak symbols for gnulib). That obviously still happens on 32bit, but no longer on 64bit. I think the test is bogus in both cases since the executable will always be linked again cygwin1.dll and so should be able to resolve the symbol either way. 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: gnulib m4/threadlib.m4 bug crashing package tests
Yaakov Selkowitz via Cygwin-apps writes: >> For anyone else who bumps into this, gdb and strace are of no use in >> debugging this crash. I finally thought to look at the stackdump >> file, and the second address from the top was in a gnulib file. That >> was the key clue. > > Add gl_cv_have_weak=no to cygconf? I'd rather know why the bleeping heck the test suddenly succeeds when it clearly doesn't actually work. In other words, I think the linker should complain, but since it obviously did that before Cygwin 3.2.0 and not after, something must have changed somewhere that prevent s it from doing 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
Re: [ITA] openssl, openssl10, mingw64-{i686,x86_64}-openssl
Marco Atzeri via Cygwin-apps writes: > On 28.11.2021 10:43, ASSI wrote: >> Marco Atzeri via Cygwin-apps writes: >>> no problem for the 3 orphaned, but we should ask Corinna about openssl >> She's said numerous times that she doesn't really want it… I >> wouldn't >> mind to just co-maintain in any case. >> > > I must have missed it. Possibly, most recently was on IRC 2021-10-22: [09:49:41] Stromeko, I didn't do anything with OpenSSL for a long time [09:50:13] I would be glad if somebody could take over the package Her earliest offer to yield package maintenance of openssl that I've found was from 2010… :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [ATTN MAINTAINER] openssh
Achim Gratz writes: > These patches work for 32bit also and I believe they are correct, but > that build should not be made available due to a bug in libfido2 that > crashes when trying to free the memory associated with the WebAuthn > payload returned. Without these patches applied you can still use the > fallback to USB-HID when you are an administrator. The call into WebAuthn completely messes up the stack apparently. The returned object looks OK once you realize it is a version 1 and thus the extension fields are bogus, but the whole thing crashes if you do just one more call. Gdb session: https://paste.c-net.org/SerumLoser Any ideas what that might be? 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
[ITA] openssl, openssl10, mingw64-{i686,x86_64}-openssl
As I wrote about a month ago:
https://sourceware.org/pipermail/cygwin-apps/2021-October/041632.html
https://sourceware.org/pipermail/cygwin-apps/2021-November/041651.html
I have updated the recently released Cygwin packages with all upstream
patches from Fedora plus the patches for all CVE affecting version 1.0.2
since the last official version and changed the cygport files so they
build on AppVeyor. The packages have been pushed to the respective
playground branches:
https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/openssl10.git;a=shortlog;h=refs/heads/playground
https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/openssl.git;a=shortlog;h=refs/heads/playground
For the MinGW64 packages the current plan (based on the previous
discussion) is to update them with the 1.0.2 version and provide the
1.1.1 version (without renaming the packages or introducing any new
package names) as a test version only. This means that the existing
packages depending on mingw64-{i686,x86_64}-openssl will still work
correctly, but can be rebuilt using the 1.1.1 version by chosing the
test version (whatever the likelyhood of that actually happening is).
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
[ATTN MAINTAINER] openssh
Here are my fixes to make transparent WebAuthn through libfido2 work w/ OpenSSH. This is required for Win10 from release 1909; the access to USB-HID is since restricted to users with administrative privileges: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/openssh The changes switch to a newer API available from libfido2 that is required for WebAuthn support (which needs the unhashed data instead of the SH256 like the actual FIDO2-Token), make that protocol the preferred one (so that WebAuthn is always used when available w/o being dependent on the order of the device enumeration) and lastly prevent some extra (optional) PIN prompts from WinHello that do not happen when using the USB-HID interface either. The PIN patches were inspired by an OpensSSH-portable fork that seems to be maintened by some folks who also work on libfido, although they seem to have missed a few spots and I opted for slightly different patches. The use of the new API is properly wired into the configury. Unfortunately libfido2 does not provide a way to determine if WebAuthn support has been compiled in (the one exposed function is a predicate that always returns false on builds that do not use WebAuthn), so I'm currently using a heuristic that eventually should be replaced by a configure option. Also, it would probably be a good idea to decide at runtime whether to use WebAuthn or not (maybe via an environment or config variable). These patches work for 32bit also and I believe they are correct, but that build should not be made available due to a bug in libfido2 that crashes when trying to free the memory associated with the WebAuthn payload returned. Without these patches applied you can still use the fallback to USB-HID when you are an administrator. 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
[ATTN MAINTAINER] libedit
The package hint for libedit-devel is missing a dependency on libncursesw-devel for the 32bit version (that dependency is present in the 64bit setup.ini). 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-Image-ExifTool
Achim Gratz writes: > Anyway, I'll have a look if it builds cleanly and if so will ITP it > myself. It does and even is noarch, so please add it to my list of packages. 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] perl-Image-ExifTool
Brian Inglis writes: > This perl module is not built from CPAN as that is 5 releases out of > date 12.30 from the repo release 12.35. NACK. We do not package development releases unless absolutely necessary. The latest production release is 12.30 (Phil only seems to mirror production releases to CPAN). Anyway, I'll have a look if it builds cleanly and if so will ITP it myself. > The cygport and tarballs are available online at: > > https://drive.google.com/drive/folders/1PwBaANQ2fnagJG8zebp0pN1qYujSBP0j Get rid of that Google drive nonsense here, please. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
{ITA] libtool
A rebuild for gcc-11 is required due to stupidly hardcoded paths in the libtool script. https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/libtool.git;a=shortlog;h=refs/heads/playground It seems that the -8 release that supposedly fixes some clang++ linking problem never made it to the repository, so I'm wondering about the status of that change, though. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: FIDO/U2F middleware libraries
Achim Gratz writes: > There is a newer version of libfido (which OpenSSH uses) that should be > able to use the WindowsHello. Corinna has patched it up to the point > were it actually builds and OpenSSH tries to use it, but fails. I have > no idea yet if the fail is triggered by something OpenSSH does or > seomthing in libfido not lining up with WindowsHello. I have to get up > to speed on how to use the fido-tools provided with libfido in order to > see where things go sideways. Now also available on playground (build artifacts on AppVeyor): https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/libfido2 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
