Re: libtool can't build shared library unless -no-undefined specified
On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote: Hi folks, Trying to update dateutils, autotools build fails with: libtool: error: can't build x86_64-pc-cygwin shared library unless -no-undefined is specified Suggestions for overrides or fixes? Tried: LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined" CYGCONF_ARGS=" --enable-contrib --enable-tzmap-fetch lt_no_undefined_flag=--no-undefined no_undefined_flag=--no-undefined You and I discussed this a few years ago in connection with curl. The solution there, and in most similar cases, is to add -no-undefined to the appropriate lib*_la_LDFLAGS variable(s) in Makefile.am. See https://cygwin.com/pipermail/cygwin-apps/2020-August/040411.html Ken
Re: Fwd: calm: cygwin package report for Ken Brown
On 3/20/2023 7:17 PM, Jon Turney wrote: On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote: It looks like my plan for having scallywag deploy all the TeX Live packages won't work (see below). calm would have to be more permissive and allow deploying a package that requires something that will be provided by a future package. In this case, I made asymptote require tl_2023, which will be provided by the next texlive release. But I don't want to deploy the latter until all the other packages for TeX Live 2023 have been deployed. Unless this is easy to fix, I'll just forget about using scallywag and go back to my old method of uploading everything manually. This is trivially fixable. calm already has a list of 'provides which don't exist (yet)', so I think I just need to add tl_2023 and tl_basic_2023 to that list Future work: make these regexes so we don't have same problem again in a years time. Jon, In preparation for TeX Live 2024, please add tl_2024 and tl_basic_2024 to the list of provides which don't exist yet (unless you've already done the regex future work). Thanks. Ken
Re: [attn maintainer] latex dependencies
On 12/14/2023 2:46 PM, Marco Atzeri via Cygwin-apps wrote:
On 14/12/2023 16:50, Ken Brown via Cygwin-apps wrote:
On 12/14/2023 4:22 AM, Marco Atzeri via Cygwin-apps wrote:
Hi Ken,
it seems that both
texlive-collection-latex
texlive-collection-latexextra
depend on
texlive-collection-latexrecommended
that seems to me contra intuitive. can you please check ?
Hi Marco,
Do you have an example of a LaTeX file that uses packages only in
texlive-collection-latex but fails to compile if
texlive-collection-latexrecommended is not installed? Without this,
it's very hard for me to check if the occurrences of "pdftexcmds.sty"
that you found really indicate dependencies. My technical knowledge
of LaTeX is not good enough to determine this just from looking at the
.sty files. See below for further comments on a few of the occurrences.
the last gl2ps package had such issue
https://github.com/cygwin/scallywag/actions/runs/7204747329/job/19626758626
adding the texlive-collection-latexrecommended
as dependency, solved that issue
https://github.com/cygwin/scallywag/actions/runs/7206881393/job/19632744288
Thanks. The problem is that line 111 of
/usr/share/texmf-dist/tex/latex/hyperref/hyperref.sty contains
\RequirePackage{pdftexcmds}. Since hyperref is in the latex collection,
pdftexcmds should also be in that collection. I'll report this upstream.
But there's no bug in the latexextra package. The upstream latexextra
collection does indeed depend on the latexrecommended collection, and
this is reflected in the Cygwin packaging. So this dependency is by
design (and it makes intuitive sense to me).
Thanks for the report.
Ken
Re: [attn maintainer] latex dependencies
On 12/14/2023 4:22 AM, Marco Atzeri via Cygwin-apps wrote:
Hi Ken,
it seems that both
texlive-collection-latex
texlive-collection-latexextra
depend on
texlive-collection-latexrecommended
that seems to me contra intuitive. can you please check ?
Hi Marco,
Do you have an example of a LaTeX file that uses packages only in
texlive-collection-latex but fails to compile if
texlive-collection-latexrecommended is not installed? Without this,
it's very hard for me to check if the occurrences of "pdftexcmds.sty"
that you found really indicate dependencies. My technical knowledge of
LaTeX is not good enough to determine this just from looking at the .sty
files. See below for further comments on a few of the occurrences.
$ cd /usr/share/texmf-dist/tex
$ grep -rH pdftexcmds.sty .
./generic/catchfile/catchfile.sty: \input pdftexcmds.sty\relax
The previous line contains "IfFileExists", but I can't parse that line
well enough to know if it prevents a problem.
./generic/filemod/filemod-expmin.tex: \input pdftexcmds.sty
./generic/oberdiek/iflang.sty: \input pdftexcmds.sty\relax
This is wrapped in an \if...\else that I can't parse.
./generic/stringenc/stringenc.sty: \input pdftexcmds.sty\relax
The previous line contains "IfFileExists".
./latex/hardwrap/hardwrap.sty:\IfFileExists{pdftexcmds.sty}{%
Doesn't "IfFileExists" prevent a problem in this case?
./latex/nlctdoc/nlctuserguide.sty: % copied from pdftexcmds.sty
"pdftexcmds.sty" occurs only in a comment.
Ken
Re: Updating glib2 in cygwin
On 6/11/2023 1:55 PM, Jon Turney wrote: On 28/02/2022 13:29, Ken Brown wrote: The last discussion of this that I can recall started here: https://cygwin.com/pipermail/cygwin-apps/2020-May/040105.html What's needed is for someone to adopt all of the GNOME components and maintain them. As you'll see in the discussion I cited, I briefly considered updating only glib2 and a few others, but then I decided that I wasn't willing to take the responsibility of fixing/updating other components that broke as a result of this. So I pushed what I had done and left it there. It would be great if someone would step up and take over, but I'm not in a position to do that myself. Since this is possibly the most important unmaintained package (it's #1 by dependencies on this list [1]), I guess I'll adopt it. I see you got as far as 2.64.3 [2]. I'm inclined to deploy that (maybe as test) and deal with the fallout myself, while I work on bringing it completely up to date. Any issues I should be aware or, or other problems you foresee with that approach? Nothing I'm aware of. Thanks for taking this on! Ken
Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
On 5/6/2023 9:34 AM, Jon Turney wrote: (There's definitely a problematic dependency chain cygport -> automake -> automake1.* -> texinfo -> versioned perl which we need to be aware of in future when rebuilding texinfo for updated perl) In addition to the dependencies above, there's actually a direct dependency cygport -> texinfo. I was aware of this when rebuilding texinfo, after an initial failed attempt using SCALLYWAG. The way I dealt with it was to forcibly update perl, ignoring setup's warnings. I don't know if there's a better way to handle this in the future. Maybe temporarily (or permanently?) remove those dependencies on texinfo? Ken
Fwd: calm: cygwin package report for Ken Brown
INFO: package 'savi': errors in license expression: ['Unknown license key(s): BSD-Advertising-Acknowledgement'] Any idea why calm complained about this license key? It's listed at https://spdx.org/licenses/. Ken
Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
On 5/3/2023 8:19 AM, Ken Brown via Cygwin-apps wrote: I wonder if those obsoleted packages are confusing setup. In a new Cygwin installation, choosing only the base packages and cygport, setup wants to install perl-Test-Harness (and therefore perl 5.32). I just tried a second experiment (with a new installation). I chose base plus perl-Test-Harness. Setup didn't report any problems; it simply added perl 5.32, and I let it complete the installation. I then ran setup again, and the Pending view of the Select Packages page showed perl being upgraded to 5.36 and perl-Test-Harness being uninstalled. So setup ended up doing the right thing with respect to the obsolete package, but it needed two passes. Finally, I reran setup and chose cygport for installation. This went through without a hitch. Ken
Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
On 5/3/2023 9:33 AM, Jon Turney wrote:
On 03/05/2023 13:19, Ken Brown via Cygwin-apps wrote:
I wonder if those obsoleted packages are confusing setup. In a new
Cygwin installation, choosing only the base packages and cygport,
setup wants to install perl-Test-Harness (and therefore perl 5.32).
Or maybe there's something else causing perl 5.32 to be chosen, but I
don't see it.
Yeah, there's something weird going on there:
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.
Could we work around the problem by removing the dependency of the
obsolete packages on perl5_032?
Ken
Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
On 5/2/2023 4:45 PM, Achim Gratz via Cygwin-apps wrote: 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). I wonder if those obsoleted packages are confusing setup. In a new Cygwin installation, choosing only the base packages and cygport, setup wants to install perl-Test-Harness (and therefore perl 5.32). Or maybe there's something else causing perl 5.32 to be chosen, but I don't see it. Ken
Re: ConTeXt no longer available on Cygwin
[This is a follow-up to https://cygwin.com/pipermail/cygwin/2023-March/253326.html, on the cygwin list.] On 3/24/2023 11:00 AM, Ken Brown via Cygwin wrote: On 3/22/2023 12:56 PM, Ken Brown via Cygwin wrote: As I mentioned in the announcement of TeX Live 2023, there has been a major change in ConTeXt; see https://tug.org/texlive/bugs.html Briefly, ConTeXt development has been moved out of TeX Live into a separate project. Unfortunately, the maintainer of that project decided to remove Cygwin support, so I cannot easily provide a context binary. One Cygwin user of ConTeXt complained upstream, to no avail. At some point I will probably remove the texlive-collection-context package, which is now useless. But I am waiting to see how other distros are going to deal with this change. If you will be greatly inconvenienced by the absence of a context binary, please let me know by replying to this message. There may or may not be anything I can do about it. This turned out to be simple to fix. I will do that shortly, but first I want to finish discussing this with TeX Live maintainers for other distros. This turns out to be a complete mess, with no uniformity among maintainers, so I'm on my own. The simplest way for me to handle it is to package the missing binary as part of texlive-collection-context.(*) This presumably means that the latter can no longer be a noarch package. Jon, can you (or calm) cope with a package changing from noarch to x86_64? Alternatively, I could make a completely new package, say texlive-context-bin, which contains only the binary, if you think that's better. Ken (*) It used to be contained in the texlive package, but the sources are no longer in the texlive source tree, and the build system is completely different.
[PATCH cygport] git.cygclass: Try 'main' if there's no master branch
Patch attached.From 048a1e91cc9c4b14f4e17a6b52b6f4edb1843bf9 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Thu, 23 Mar 2023 09:20:14 -0400
Subject: [PATCH] git.cygclass: Try 'main' if there's no master branch
---
cygclass/git.cygclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index dd9aedbacdf2..e53a7985af99 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -93,7 +93,7 @@ git_fetch() {
#v* git.cygclass/GIT_BRANCH
# DESCRIPTION
-# Branch from which to clone. If undefined, the 'master' branch is used.
+# Branch from which to clone. If undefined, the 'master' or 'main' branch is
used.
#
#v* git.cygclass/GIT_REV
# DESCRIPTION
@@ -116,7 +116,7 @@ git_fetch() {
then
verbose git checkout ${GIT_REV} || error "git checkout failed"
else
- verbose git checkout master || error "git checkout failed"
+ verbose git checkout master || verbose git checkout main ||
error "git checkout failed"
fi
if [ -f .gitmodules ]
--
2.39.0
Re: Fwd: calm: cygwin package report for Ken Brown
On 3/20/2023 7:17 PM, Jon Turney wrote: On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote: It looks like my plan for having scallywag deploy all the TeX Live packages won't work (see below). calm would have to be more permissive and allow deploying a package that requires something that will be provided by a future package. [...] This is trivially fixable. calm already has a list of 'provides which don't exist (yet)', so I think I just need to add tl_2023 and tl_basic_2023 to that list Thanks! [...] Maybe calm doesn't need to do this kind of check any more? But then people might write REQUIRES="typoed-package-name" and not notice until it's uninstallable, so I don't know. I don't know either, but I think I lean toward not doing the check, in order to give maintainers maximum flexibility. In your example, the problem is easily fixed as soon as the maintainer (or someone else) notices that the package is uninstallable. And when they try to select it for installation, setup will immediately tell them what the problem is. Ken
Fwd: calm: cygwin package report for Ken Brown
It looks like my plan for having scallywag deploy all the TeX Live packages won't work (see below). calm would have to be more permissive and allow deploying a package that requires something that will be provided by a future package. In this case, I made asymptote require tl_2023, which will be provided by the next texlive release. But I don't want to deploy the latter until all the other packages for TeX Live 2023 have been deployed. Unless this is easy to fix, I'll just forget about using scallywag and go back to my old method of uploading everything manually. Ken Forwarded Message Subject: calm: cygwin package report for Ken Brown Date: Mon, 20 Mar 2023 21:57:12 - From: cygwin-no-re...@cygwin.com Reply-To: cygwin-apps@cygwin.com To: kbr...@cornell.edu ERROR: package 'asymptote' version '2.85-1' depends: 'tl_2023', but nothing satisfies that ERROR: error while validating merged x86_64 packages for Ken Brown SUMMARY: 2 ERROR(s)
Re: How to avoid tying up scallywag
On 3/20/2023 7:22 AM, Jon Turney wrote: On 19/03/2023 23:04, Ken Brown via Cygwin-apps wrote: Jon, I'll be ready to go with TeX Live 2023 in a couple days. That involves about 60 packages. If I push them all at once, I'm afraid that would tie up scallywag and make it unusable by others. I was thinking of pushing them in batches of 5, with a couple hours in between batches. But I don't know how many jobs scallywag can do at once. What do you think? As far as I can tell, the documented limits for the GitHub free service currently used are currently: * 20 concurrent jobs * runs which are queued for more than 45 minutes without starting are discarded. So I should even be able to do 10 or 15 at once without clogging the system. Maybe I'll start with one batch of 15 and see what happens. The implementation of how the build back-end is used in scallywag is moderately modularized, so if these restrictions become irksome, and we ever have access to a better compute service, that could be used instead. Note that if you are just updating the repository, without using scallywag to deploy, then pushing with --push-option=nobuild is more slightly more efficient that SCALLYWAG="nobuild" in the cygport, as it can short-cut things, since it doesn't need to start a job to evaluate the tokens to determine if nobuild is set. Good to know, but in the present case I'm planning to deploy. Ken
How to avoid tying up scallywag
Jon, I'll be ready to go with TeX Live 2023 in a couple days. That involves about 60 packages. If I push them all at once, I'm afraid that would tie up scallywag and make it unusable by others. I was thinking of pushing them in batches of 5, with a couple hours in between batches. But I don't know how many jobs scallywag can do at once. What do you think? Ken
Re: Possible "stage" token for SCALLYWAG builds
On 2/16/2023 7:13 PM, Ken Brown via Cygwin-apps wrote: On 2/16/2023 3:31 PM, Jon Turney wrote: On 15/02/2023 21:48, Ken Brown via Cygwin-apps wrote: Jon, When building TeX Live (once a year), I have to build texlive, asymptote, and all the texlive-collection-* packages. I currently can't use SCALLYWAG to do the builds because these packages need to all be deployed at once. So I have to build them all locally, upload them to my staging area, and then upload !ready files, one for x86_64 and one for noarch. It would be convenient for me if SCALLYWAG would accept a "stage" token that would upload the files to my staging area without deploying them. Then I could let SCALLYWAG do the builds, and I could upload the !ready files when everything is staged. If I'm the only maintainer who would find this useful, then I can continue doing it the way I always have. But maybe others would find it useful too. I'm not opposed to adding a some feature to support this if needed, but from the way you are describing it, this sounds more like a constraint that the dependency solver should be aware of. (just because texlive-2023 and texlive-collection-foo-2023 are made available to download at the same time, doesn't mean that they always end up installed together, as the user might alter the version of one or the other) If they really must be kept in lockstep to work correctly, then there's at least a couple of ways of doing that: * give texlive an additional provide, such as texlive_2023, and make everything that requires it, require that (something similar is done with perl and perl modules) * make things which require texlive do so with a version constraint like 'requires: texlive (>= 2023), texlive (<2024)' (in theory this works, but I have no doubt that a bug will emerge when someone tries to use it, and ofc, it relies on the range of future versions which are compatible being correctly known in advance) Thanks for the suggestions. I think I should be able to make things work with one or both of your ideas. Just to finish this off for the sake of the archives, here's the solution I've decided on. First, the only two packages that absolutely have to be in lockstep are texlive and texlive-collection-basic. I achieve this as follows: - Make texlive provide tl_2023 and require tl_basic_2023. - Make texlive-collection-basic provide tl_basic_2023 and require tl_2023. In addition, I prefer (but don't require) that the other texlive-collection-* packages stay in lockstep with texlive and texlive-collection-basic. To this end, - Make the other texlive-collection-* packages require tl_basic_2023. As long as I deploy texlive after all the collections, I get what I want. Alternatively, I could deploy texlive-collection-basic after all the other collections. If I forget to do one of those things, it won't be a disaster. I've done some local testing, and this appears to work. Ken
Re: scallywag
On 3/11/2023 2:18 AM, Marco Atzeri via Cygwin-apps wrote: may I propose another PLUSH HIPPO for Jon Turney for implementating and maintaining scallywag ? Seconded! Ken
Re: Heads up: Problems with parallel make
On 2/27/2023 4:41 PM, Brian Inglis via Cygwin-apps wrote: Looks like the 4.4.1 release disables FIFO on Hurd and Cygwin. Will be interesting to see if it is based on config test, for clues to what it does not like, or just system? In the case of HURD, it's because of failing tests in the test suite. In the case of Cygwin, it's because of the problem I reported, in which parallel make using a FIFO sometimes hangs when building TeX Live. Anyone who wants to test this with their own builds can build make with CPPFLAGS=-DJOBSERVER_USE_FIFO=1 That will re-enable the use a FIFO for the jobserver. One can then force make to use a pipe on a given project by using the make option --jobserver-style=pipe I plan to do this myself, since I hope to debug the FIFO problem the next time I see it. It's not easy to catch, because it doesn't happen with every build of TeX Live. And when it does happen, the build has typically been going on for close to two hours before it hangs. P.S. Marco, I don't know how much trouble you want to go to on this, but when you release make-4.4.1, you might also make a test release with CPPFLAGS set as above. That would make it easier for adventurous people to try builds that use a FIFO.
[PATCH cygport] texlive.cygclass: remove references to i386-cygwin
Patch attached.From 6d0508ddb08785dd3c8dbcfa64dce4fe21861c62 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Mon, 20 Feb 2023 13:39:34 -0500
Subject: [PATCH cygport] texlive.cygclass: remove references to i386-cygwin
These are no longer relevant now that we're not supporting 32-bit
Cygwin. Moreover, upstream TeX Live is removing all i386-cygwin
packages starting with TeX Live 2023.
---
cygclass/texlive.cygclass | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/cygclass/texlive.cygclass b/cygclass/texlive.cygclass
index 75eae7df44bb..06b4849c3221 100644
--- a/cygclass/texlive.cygclass
+++ b/cygclass/texlive.cygclass
@@ -116,7 +116,6 @@ done
for pkg in ${TEXLIVE_ARCH_PKGS//,/ }
do
SRC_URI+=" ${tlnet}/archive/$pkg.tar.xz"
- SRC_URI+=" ${tlnet}/archive/$pkg.i386-cygwin.tar.xz"
SRC_URI+=" ${tlnet}/archive/$pkg.x86_64-cygwin.tar.xz"
done
for pkg in ${TEXLIVE_DOC_PKGS//,/ }
@@ -149,7 +148,7 @@ texlive_install() {
done
for pkg in ${TEXLIVE_ARCH_PKGS//,/ }
do
- pkgs+="$pkg $pkg.i386-cygwin $pkg.x86_64-cygwin "
+ pkgs+="$pkg $pkg.x86_64-cygwin "
done
for pkg in ${TEXLIVE_DOC_PKGS//,/ }
do
@@ -170,7 +169,7 @@ texlive_install() {
*.bat)
# only needed for native Win32
continue ;;
- bin/i386-cygwin/*)
+ bin/x86_64-cygwin/*)
if [ ! -L ${f} ]
then
dobin $f
@@ -183,9 +182,6 @@ texlive_install() {
esac
fi
continue ;;
- bin/x86_64-cygwin/*)
- # duplicate to i386-cygwin handled above
- continue ;;
*doc/info/dir)
# system-managed file
continue ;;
--
2.39.0
Re: Heads up: Problems with parallel make
On 2/20/2023 6:29 PM, Ken Brown via Cygwin-apps wrote: On 2/20/2023 5:00 PM, Ken Brown via Cygwin-apps wrote: On 2/20/2023 2:12 PM, Marco Atzeri via Cygwin-apps wrote: uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 I doubt if this is related to the pipe vs. fifo issue, but maybe you should test 4.4.0.90-1 to be sure. Do you have a simple way to reproduce the problem? For example, does it happen if you just make a toy cmake project? Ignore what I said about 'make -j13 check' working right in the TeX Live build. I just retried it and saw the "jobserver unavailable" message. When I saw several makes running at once, I think it was because of recursion, not parallelism. So there's a real problem that can be reproduced without cmake. I'm going to report this upstream, as a continuation of the upstream bug report that I filed earlier. Ken
Re: Heads up: Problems with parallel make
On 2/20/2023 5:00 PM, Ken Brown via Cygwin-apps wrote: On 2/20/2023 2:12 PM, Marco Atzeri via Cygwin-apps wrote: uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 I doubt if this is related to the pipe vs. fifo issue, but maybe you should test 4.4.0.90-1 to be sure. Do you have a simple way to reproduce the problem? For example, does it happen if you just make a toy cmake project? Ignore what I said about 'make -j13 check' working right in the TeX Live build. I just retried it and saw the "jobserver unavailable" message. When I saw several makes running at once, I think it was because of recursion, not parallelism. So there's a real problem that can be reproduced without cmake. Ken
Re: Heads up: Problems with parallel make
On 2/20/2023 2:12 PM, Marco Atzeri via Cygwin-apps wrote: uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 I doubt if this is related to the pipe vs. fifo issue, but maybe you should test 4.4.0.90-1 to be sure. Do you have a simple way to reproduce the problem? For example, does it happen if you just make a toy cmake project? Ken
Re: Heads up: Problems with parallel make
On 2/20/2023 2:12 PM, Marco Atzeri via Cygwin-apps wrote: On 20.02.2023 18:34, Marco Atzeri wrote: On 20.02.2023 18:14, Ken Brown via Cygwin-apps wrote: On 2/20/2023 12:00 PM, Achim Gratz via Cygwin-apps wrote: 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. uploaded as test 4.4.0.91-1 following message is still present while missing in 4.4-1 make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. and I do not see clear evidence of parallelism like in 4.4-1 It does for my build of TeX Live. I just tried 'make -j13 check', and I saw many make processes and many sh processes running at once. [But I'm currently testing a self-built make 4.4.0.91.] Ken How are you configuring your build ? Just a plain vanilla build, no configure options. Ken
Re: Heads up: Problems with parallel make
On 2/20/2023 12:00 PM, Achim Gratz via Cygwin-apps wrote: 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. It does for my build of TeX Live. I just tried 'make -j13 check', and I saw many make processes and many sh processes running at once. [But I'm currently testing a self-built make 4.4.0.91.] Ken
Re: Heads up: Problems with parallel make
On 2/16/2023 9:21 PM, Ken Brown via Cygwin-apps wrote:
On 2/16/2023 2:47 AM, Marco Atzeri via Cygwin-apps wrote:
On 15.02.2023 19:09, Ken Brown via Cygwin-apps wrote:
On 2/14/2023 4:23 PM, Marco Atzeri via Cygwin-apps wrote:
On 14.02.2023 17:49, Brian Inglis via Cygwin-apps wrote:
There is a make 4.4.1 release candidate 4.40.0.90 with patches that
may help to deal with this:
https://alpha.gnu.org/gnu/make/make-4.4.0.90.tar.lz{,.sig}
https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=110=custom
test version built and on the way
The problems I reported with make 4.4 still exist in 4.4.0.90.
Until someone can figure out why this happens, you might want to
consider building make so that it doesn't default to using a FIFO for
its jobserver. I suggested to the make developers that they provide
a configure option for this purpose. If they don't do this, I think
you could accomplish the same thing by configuring make with
ac_cv_func_mkfifo=no.
Ken
version 2 uploaded.
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.
Just to finish this off, there's now a new release candidate 4.4.0.91
for make, which makes the jobserver use a pipe by default on Cygwin.
You can override this default when building make by defining
JOBSERVER_USE_FIFO to 1, and you can override it when running make by
using the make option --jobserver-style=fifo. But there's no longer a
need to build make with ac_cv_func_mkfifo=no, and there's no longer a
need to use --jobserver-style=pipe when running make.
I'm very impressed with how responsive the make developer (Paul Smith) was.
Ken
Re: git repositories for cygwin packaging - please test
On 2/18/2023 11:21 AM, Jon Turney via Cygwin-apps wrote: On 05/07/2022 14:12, Jon Turney wrote: On 22/06/2021 20:52, Jon Turney wrote: On 09/05/2021 15:39, Jon Turney wrote: On 23/08/2020 22:01, Jon Turney wrote: On 27/05/2020 23:27, Jon Turney wrote: On 04/08/2019 21:08, Jon Turney wrote: To remedy this lack, using the same ssh key you use for sftp package upload, package maintainers can now also push to git repositories, like so: Package maintainers may have noticed that the output from pushing to these git repositories now includes a line like: "remote: scallywag: build nnn queued" This is a *prototype* of a system to automatically build the packages, where the results appear (some time later) at [1] (URL subject to change) [1] https://cygwin.com/cgi-bin2/jobs.cgi I now have built an (opt-in) system which fetches the packages built by this into your upload area and triggers calm to process them, which I'm looking for a volunteer to test. Since that seems to be working about as well as can be expected, I've bodged together something so maintainers can now opt themselves in (and out) of this, by uploading (or removing) a file called '!scallywag' containing 'deploy' in the root of their upload area. I've updated the brief documentation at [1] to mention this. [1] https://cygwin.com/packaging/build.html I've updated that page to document the fact that the behaviour for an individual push can now be controlled with 'git push --push-option='. Currently, these packages are built using 'cygport all-test', and so will always be marked test: Since my concerns about this producing horribly broken packages seem to be moot, I've changed the default so this now produces stable packages (i.e. uses 'cygport all' rather than 'cygport all-test''). You can request the previous behaviour of labelling as test using the token 'label'. You can now interact with your build jobs in some ways which require authentication using 'ssh cyg...@cygwin.com jobs'. Thanks! Currently, available sub-commands are: cancel (request termination of an unwanted build job) deploy (get a job to deploy (if it's suitable: i.e. successfully built, from master, etc.) (e.g. if you forgot to set the deploy option before hand) I assume we would specify the job id after the cancel or deploy command? rebuild (rebuild a job if it failed due to some transient condition, or optionally with different token options) For the second case, would we specify the new tokens on the command line? After the job id? Ken
Re: Heads up: Problems with parallel make
On 2/16/2023 2:47 AM, Marco Atzeri via Cygwin-apps wrote:
On 15.02.2023 19:09, Ken Brown via Cygwin-apps wrote:
On 2/14/2023 4:23 PM, Marco Atzeri via Cygwin-apps wrote:
On 14.02.2023 17:49, Brian Inglis via Cygwin-apps wrote:
There is a make 4.4.1 release candidate 4.40.0.90 with patches that
may help to deal with this:
https://alpha.gnu.org/gnu/make/make-4.4.0.90.tar.lz{,.sig}
https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=110=custom
test version built and on the way
The problems I reported with make 4.4 still exist in 4.4.0.90.
Until someone can figure out why this happens, you might want to
consider building make so that it doesn't default to using a FIFO for
its jobserver. I suggested to the make developers that they provide a
configure option for this purpose. If they don't do this, I think you
could accomplish the same thing by configuring make with
ac_cv_func_mkfifo=no.
Ken
version 2 uploaded.
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.
Ken
Re: Possible "stage" token for SCALLYWAG builds
On 2/16/2023 3:31 PM, Jon Turney wrote: On 15/02/2023 21:48, Ken Brown via Cygwin-apps wrote: Jon, When building TeX Live (once a year), I have to build texlive, asymptote, and all the texlive-collection-* packages. I currently can't use SCALLYWAG to do the builds because these packages need to all be deployed at once. So I have to build them all locally, upload them to my staging area, and then upload !ready files, one for x86_64 and one for noarch. It would be convenient for me if SCALLYWAG would accept a "stage" token that would upload the files to my staging area without deploying them. Then I could let SCALLYWAG do the builds, and I could upload the !ready files when everything is staged. If I'm the only maintainer who would find this useful, then I can continue doing it the way I always have. But maybe others would find it useful too. I'm not opposed to adding a some feature to support this if needed, but from the way you are describing it, this sounds more like a constraint that the dependency solver should be aware of. (just because texlive-2023 and texlive-collection-foo-2023 are made available to download at the same time, doesn't mean that they always end up installed together, as the user might alter the version of one or the other) If they really must be kept in lockstep to work correctly, then there's at least a couple of ways of doing that: * give texlive an additional provide, such as texlive_2023, and make everything that requires it, require that (something similar is done with perl and perl modules) * make things which require texlive do so with a version constraint like 'requires: texlive (>= 2023), texlive (<2024)' (in theory this works, but I have no doubt that a bug will emerge when someone tries to use it, and ofc, it relies on the range of future versions which are compatible being correctly known in advance) Thanks for the suggestions. I think I should be able to make things work with one or both of your ideas. Ken
Possible "stage" token for SCALLYWAG builds
Jon, When building TeX Live (once a year), I have to build texlive, asymptote, and all the texlive-collection-* packages. I currently can't use SCALLYWAG to do the builds because these packages need to all be deployed at once. So I have to build them all locally, upload them to my staging area, and then upload !ready files, one for x86_64 and one for noarch. It would be convenient for me if SCALLYWAG would accept a "stage" token that would upload the files to my staging area without deploying them. Then I could let SCALLYWAG do the builds, and I could upload the !ready files when everything is staged. If I'm the only maintainer who would find this useful, then I can continue doing it the way I always have. But maybe others would find it useful too. Thanks. Ken
Re: Heads up: Problems with parallel make
On 2/14/2023 4:23 PM, Marco Atzeri via Cygwin-apps wrote:
On 14.02.2023 17:49, Brian Inglis via Cygwin-apps wrote:
There is a make 4.4.1 release candidate 4.40.0.90 with patches that
may help to deal with this:
https://alpha.gnu.org/gnu/make/make-4.4.0.90.tar.lz{,.sig}
https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=110=custom
test version built and on the way
The problems I reported with make 4.4 still exist in 4.4.0.90.
Until someone can figure out why this happens, you might want to
consider building make so that it doesn't default to using a FIFO for
its jobserver. I suggested to the make developers that they provide a
configure option for this purpose. If they don't do this, I think you
could accomplish the same thing by configuring make with
ac_cv_func_mkfifo=no.
Ken
Re: Heads up: Problems with parallel make
On 2/13/2023 6:05 PM, Ken Brown via Cygwin-apps wrote: Several of my packages that used to build fine with parallel make now require 'make -j1'. Without this I either get strange errors or a hang. I can't find any pattern to explain when the problem occurs and when it doesn't, but it seems to be due to a change in make, starting with version 4.4. By default, make now uses a FIFO rather than a pipe in its jobserver implementation. You can override this with the make flag --jobserver-style=pipe In all cases where I've tried this, parallel make works again. It wouldn't surprise me if there's a bug in Cygwin's FIFO implementation that's responsible for this, but I haven't yet tried to track it down. I've now reported this upstream: https://lists.gnu.org/archive/html/bug-make/2023-02/msg00029.html Ken
Re: Heads up: Problems with parallel make
On 2/13/2023 6:44 PM, Brian Inglis wrote: On 2023-02-13 16:05, Ken Brown via Cygwin-apps wrote: Several of my packages that used to build fine with parallel make now require 'make -j1'. Without this I either get strange errors or a hang. I can't find any pattern to explain when the problem occurs and when it doesn't, but it seems to be due to a change in make, starting with version 4.4. By default, make now uses a FIFO rather than a pipe in its jobserver implementation. You can override this with the make flag --jobserver-style=pipe In all cases where I've tried this, parallel make works again. It wouldn't surprise me if there's a bug in Cygwin's FIFO implementation that's responsible for this, but I haven't yet tried to track it down. There is some glibc? compatibility issue also with this recommended workaround. Could you elaborate? I don't know what issue you're seeing. Ken
Heads up: Problems with parallel make
Several of my packages that used to build fine with parallel make now require 'make -j1'. Without this I either get strange errors or a hang. I can't find any pattern to explain when the problem occurs and when it doesn't, but it seems to be due to a change in make, starting with version 4.4. By default, make now uses a FIFO rather than a pipe in its jobserver implementation. You can override this with the make flag --jobserver-style=pipe In all cases where I've tried this, parallel make works again. It wouldn't surprise me if there's a bug in Cygwin's FIFO implementation that's responsible for this, but I haven't yet tried to track it down. Ken
Re: python2 removal
On 1/16/2023 7:49 AM, Jon Turney wrote: On 15/01/2023 19:31, Ken Brown via Cygwin-apps wrote: On 1/15/2023 7:52 AM, Jon Turney via Cygwin-apps wrote: bzr-fastimport python-fastimport Ken Brown I'm not interested in maintaining these any longer. If no one else wants to take over, they could just be removed from the distro as far as I'm concerned. The only package that would suffer from this is cvs2svn, but that's currently unmaintained anyway. That's fine, of course. I meant to write some words saying 'please update or orphan (which will probably lead to removal)', but forgot. Sorry about that. NP. I've marked them as orphaned. Ken
Re: python2 removal
On 1/15/2023 7:52 AM, Jon Turney via Cygwin-apps wrote: bzr-fastimport python-fastimport Ken Brown I'm not interested in maintaining these any longer. If no one else wants to take over, they could just be removed from the distro as far as I'm concerned. The only package that would suffer from this is cvs2svn, but that's currently unmaintained anyway. Ken
[ITP] tree-sitter
cygport file and patch attached.
This package is present in all the major Linux distros. I've tested the build
on SCALLYWAG (https://github.com/cygwin/scallywag/actions/runs/3824702717), and
I've tested that the library works as expected with the development version of
emacs-29.
KenNAME="tree-sitter"
VERSION=0.20.7
RELEASE=1
LICENSE="MIT"
HOMEPAGE="https://tree-sitter.github.io;
SRC_URI="https://github.com/tree-sitter/${NAME}/archive/v${VERSION}/${NAME}-${VERSION}.tar.gz;
PATCH_URI="Makefile.patch"
CATEGORY="Libs Devel"
SUMMARY="An incremental parsing system for programming tools"
DESCRIPTION="Tree-sitter is a parser generator tool and an incremental parsing
library. It can build a concrete syntax tree for a source file and
efficiently update the syntax tree as the source file is edited.
Tree-sitter aims to be:
* General enough to parse any programming language
* Fast enough to parse on every keystroke in a text editor
* Robust enough to provide useful results even in the presence
of syntax errors
* Dependency-free so that the runtime library (which is written
in pure C) can be embedded in any application"
PKG_NAMES="libtree-sitter0 libtree-sitter-devel"
libtree_sitter0_SUMMARY="${SUMMARY} (runtime)"
libtree_sitter0_CONTENTS="usr/bin/cygtree-sitter-0.dll"
libtree_sitter_devel_SUMMARY="${SUMMARY} (development)"
libtree_sitter_devel_CONTENTS="
usr/include
usr/lib
usr/share/doc"
src_compile() {
lndirs
cd ${B}
cygmake
}
src_install() {
cd ${B}
cyginstall PREFIX=/usr
}
SCALLYWAG=nodeploy
--- origsrc/tree-sitter-0.20.7/Makefile 2022-09-02 18:00:47.0 -0400
+++ src/tree-sitter-0.20.7/Makefile 2023-01-02 14:07:08.545346600 -0500
@@ -3,6 +3,7 @@ VERSION := 0.6.3
# install directory layout
PREFIX ?= /usr/local
INCLUDEDIR ?= $(PREFIX)/include
+BINDIR ?= $(PREFIX)/bin
LIBDIR ?= $(PREFIX)/lib
PCLIBDIR ?= $(LIBDIR)/pkgconfig
@@ -26,37 +27,19 @@ SONAME_MAJOR := 0
SONAME_MINOR := 0
# OS-specific bits
-ifeq ($(shell uname),Darwin)
- SOEXT = dylib
- SOEXTVER_MAJOR = $(SONAME_MAJOR).dylib
- SOEXTVER = $(SONAME_MAJOR).$(SONAME_MINOR).dylib
- LINKSHARED += -dynamiclib
-Wl,-install_name,$(LIBDIR)/libtree-sitter.$(SONAME_MAJOR).dylib
-else
- SOEXT = so
- SOEXTVER_MAJOR = so.$(SONAME_MAJOR)
- SOEXTVER = so.$(SONAME_MAJOR).$(SONAME_MINOR)
- LINKSHARED += -shared -Wl,-soname,libtree-sitter.so.$(SONAME_MAJOR)
-endif
-ifneq (,$(filter $(shell uname),FreeBSD NetBSD DragonFly))
- PCLIBDIR := $(PREFIX)/libdata/pkgconfig
-endif
-
-all: libtree-sitter.a libtree-sitter.$(SOEXTVER)
+ SOEXT = dll
+ LINKSHARED += -shared -Wl,--out-implib,libtree-sitter.dll.a
-libtree-sitter.a: $(OBJ)
- $(AR) rcs $@ $^
+all: cygtree-sitter-$(SONAME_MAJOR).$(SOEXT)
-libtree-sitter.$(SOEXTVER): $(OBJ)
+cygtree-sitter-$(SONAME_MAJOR).$(SOEXT): $(OBJ)
$(CC) $(LDFLAGS) $(LINKSHARED) $^ $(LDLIBS) -o $@
- ln -sf $@ libtree-sitter.$(SOEXT)
- ln -sf $@ libtree-sitter.$(SOEXTVER_MAJOR)
install: all
+ install -d '$(DESTDIR)$(BINDIR)'
+ install -m755 cygtree-sitter-$(SONAME_MAJOR).$(SOEXT)
'$(DESTDIR)$(BINDIR)'/cygtree-sitter-$(SONAME_MAJOR).$(SOEXT)
install -d '$(DESTDIR)$(LIBDIR)'
- install -m755 libtree-sitter.a '$(DESTDIR)$(LIBDIR)'/libtree-sitter.a
- install -m755 libtree-sitter.$(SOEXTVER)
'$(DESTDIR)$(LIBDIR)'/libtree-sitter.$(SOEXTVER)
- ln -sf libtree-sitter.$(SOEXTVER)
'$(DESTDIR)$(LIBDIR)'/libtree-sitter.$(SOEXTVER_MAJOR)
- ln -sf libtree-sitter.$(SOEXTVER)
'$(DESTDIR)$(LIBDIR)'/libtree-sitter.$(SOEXT)
+ install -m755 libtree-sitter.dll.a
'$(DESTDIR)$(LIBDIR)'/libtree-sitter.dll.a
install -d '$(DESTDIR)$(INCLUDEDIR)'/tree_sitter
install -m644 lib/include/tree_sitter/*.h
'$(DESTDIR)$(INCLUDEDIR)'/tree_sitter/
install -d '$(DESTDIR)$(PCLIBDIR)'
@@ -66,6 +49,6 @@ install: all
tree-sitter.pc.in > '$(DESTDIR)$(PCLIBDIR)'/tree-sitter.pc
clean:
- rm -f lib/src/*.o libtree-sitter.a libtree-sitter.$(SOEXT)
libtree-sitter.$(SOEXTVER_MAJOR) libtree-sitter.$(SOEXTVER)
+ rm -f lib/src/*.o cygtree-sitter-$(SONAME_MAJOR).$(SOEXT)
libtree-sitter.dll.a
.PHONY: all install clean
Re: autoconf
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 Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 11/28/2021 11:33 AM, Achim Gratz wrote:
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.
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. Running
under gdb I see
(gdb) p fputs
$1 = {int (const char * restrict, FILE * restrict)} 0x1801b0540
This is a change, and it's actually what one would expect. But, as Dave Korn
explained in
https://cygwin.com/pipermail/cygwin/2010-April/186350.html ,
it doesn't mean that weak symbols on Cygwin behave the way they do on ELF
platforms. So I agree with you that this is a bogus test.
Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 11/28/2021 10:42 AM, Achim Gratz wrote: 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. 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 Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 11/26/2021 12:34 PM, Brian Inglis wrote:
On 2021-11-26 06:08, Ken Brown via Cygwin-apps wrote:
On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:
Add gl_cv_have_weak=no to cygconf?
Are you suggesting maintainers should do this, or are you talking about
patching cygport, like this:
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 712f437..8b6fdde 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -735,6 +735,14 @@ cygconf() {
export ac_cv_func_mmap_fixed_mapped=yes ;;
esac
+ # Some versions of gnulib's threadlib.m4:gl_WEAK_SYMBOLS
+ # incorrectly report that Cygwin supports weak symbols. See
+ # https://cygwin.com/pipermail/cygwin-apps/2021-September/041587.html.
+ case ${CHOST} in
+ *-*-cygwin*)
+ export gl_cv_have_weak=no ;;
+ esac
+
# packages that use intltool w/o glib-gettext get this wrong
export DATADIRNAME="share"
Normally in a regular/autotools build the maintainer appends these overrides to:
CYGCONF_ARGS=...gl_cv_have_weak=guessing\ no
or to:
src_compile() {
cd ${S}
cygautoreconf
cd ${B}
cygconf ... gl_cv_have_weak=guessing\ no
cygmake
}
cygport already does this for ac_cv_func_mmap_fixed_mapped. That's why I asked
Yaakov to clarify what he had in mind.
Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:
Add gl_cv_have_weak=no to cygconf?
Are you suggesting maintainers should do this, or are you talking about patching
cygport, like this:
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 712f437..8b6fdde 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -735,6 +735,14 @@ cygconf() {
export ac_cv_func_mmap_fixed_mapped=yes ;;
esac
+ # Some versions of gnulib's threadlib.m4:gl_WEAK_SYMBOLS
+ # incorrectly report that Cygwin supports weak symbols. See
+ # https://cygwin.com/pipermail/cygwin-apps/2021-September/041587.html.
+ case ${CHOST} in
+ *-*-cygwin*)
+ export gl_cv_have_weak=no ;;
+ esac
+
# packages that use intltool w/o glib-gettext get this wrong
export DATADIRNAME="share"
Ken
URL for cygport git repo
According to https://cygwin.com/packages/summary/cygport-src.html, the cygport git repo is at https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/cygport.git But that repo is empty. The correct URL seems to be https://cygwin.com/git/?p=cygwin-apps/cygport.git Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 9/29/2021 7:46 PM, Brian Inglis wrote: There is a gnulib bug in threadlib.m4 from at least serial 29 to serial 31 that incorrectly configures Cygwin support of weak references. This leads to SIGSEGV stack smashing crashes with no backtrace @ 0x1 or 0x0005 etc. normally during tests. Akim Demaille on bug-bison referred the issue to bug-gnulib where Bruno Haible diagnosed and patched the problem to appear in m4/threadlib.m4 serial 32: * m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on Cygwin https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00068.html [gl_cv_have_weak="guessing no"] The patch has now been applied to bison, wget, and wget2, and I have attached my patches for the copies in those packages, in case anyone else has this issue in their (mainly GNU) packages which may incorporate by inclusion recently updated gnulib m4 macros used in autotools builds. Thanks, Brian. I'm writing to reinforce this warning. I just spent 2 days trying to debug mysterious texinfo crashes that were caused by this bug. I could have saved a lot of time if I had remembered your email and had checked the gnulib version being used by texinfo. 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. Ken
Re: Question about 'provides' and emacs packaging
On 10/6/2021 4:22 PM, Jon Turney wrote: On 06/10/2021 17:23, Jon Turney wrote: On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote: This seems to work, with one caveat. Suppose package P requires feature f, and packages Q, R, S,... provide f. If the user selects P and one or more of Q, R, S,..., setup is happy. But if the user simply selects P, then setup/libsolv will choose among Q, R, S,... the one whose name is alphabetically first. In the emacs case, this would be emacs-lucid, which is a stupid default. The default ought to be emacs-nox. So I can make it work if I call that package emacs-basic instead of emacs-nox. Yeah, I think what's wanted here is for the solver to output a problem with the choices, rather than picking one. I'm not sure how to get it to do that. (Ofc, then we need some UI for picking problem solutions, rather than just always using the default) Thinking about this some more, that's probably not how it wants to work, since just installing emacs-common would then require user interaction to solve the problem, rather than just installing emacs-nox as well... Agreed. (and I'm not sure how we'd encode "emacs-basic" should be the default provider of "emacs-bin" as the input into the solver; presumably there'd by some scheme with weights attached to provide names to set the order rather than alphabetic) So all that's left is to fix that. This is discussed somewhat in [1], and it seems that having emacs-common suggest: or weak-dep: on emacs-nox would cause that to be the preferred provide:r by the solver (in the absence of other provide:ing packages being selected or installed) Yes, that sounds right... So I guess we'd need to add something like that to setup.ini and feed that data into the solver as well. ...but I'm not sure it's worth the trouble unless other package maintainers would also have a use for this. As far as emacs is concerned, I'm fine just changing "emacs-nox" to "emacs-basic" so that it's alphabetically first. Ken
Re: Question about 'provides' and emacs packaging
On 10/5/2021 2:24 PM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: There are currently five emacs packages: emacs-common, emacs, emacs-X11, emacs-w32, and emacs-lucid. The first includes things that are needed by each of the other four, and those four each include an emacs binary. The binary in the emacs package is /usr/bin/emacs-nox.exe. The other packages contain /usr/bin/emacs-X11.exe, and so on. This way of naming the packages doesn't really reflect the contents of the emacs package. It also means that anyone who installs emacs gets emacs-nox.exe, even if they plan to use one of the other three binaries. I would rather rename the current emacs-common package to emacs and the current emacs package to emacs-nox. But then the new emacs would have to have a way of requiring the installation of at least one of emacs-nox, emacs-X11, emacs-w32, or emacs-lucid. Is there any way to do this with our current setup machinery? I don't think we have the transaction capability that would be necessary to specify that the meaning of an already existing package name (two, actually) changes in this manner. You might have to use new package names and place the appropriate obsoletions w.r.t. old names instead. My idea three years ago was to have the new emacs package require a "feature" called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature. I have no idea if multiple packages can provide the same feature. It's worth trying if it does what you want (you must pick at least one of those). This seems to work, with one caveat. Suppose package P requires feature f, and packages Q, R, S,... provide f. If the user selects P and one or more of Q, R, S,..., setup is happy. But if the user simply selects P, then setup/libsolv will choose among Q, R, S,... the one whose name is alphabetically first. In the emacs case, this would be emacs-lucid, which is a stupid default. The default ought to be emacs-nox. So I can make it work if I call that package emacs-basic instead of emacs-nox. I've only tested setup so far, not calm. Jon, if you're reading this, does calm allow 'requires' and 'provides' to contain arbitrary names that are not package names? Ken
Re: Question about 'provides' and emacs packaging
On 10/5/2021 12:58 PM, Brian Inglis wrote: On 2021-10-05 09:51, Ken Brown via Cygwin-apps wrote: I asked this question several years ago (https://cygwin.com/pipermail/cygwin-apps/2018-October/039451.html), but I'm repeating it, in a more specific form, in the hope that setup has progressed to the point where I get a different answer. There are currently five emacs packages: emacs-common, emacs, emacs-X11, emacs-w32, and emacs-lucid. The first includes things that are needed by each of the other four, and those four each include an emacs binary. The binary in the emacs package is /usr/bin/emacs-nox.exe. The other packages contain /usr/bin/emacs-X11.exe, and so on. This way of naming the packages doesn't really reflect the contents of the emacs package. It also means that anyone who installs emacs gets emacs-nox.exe, even if they plan to use one of the other three binaries. I would rather rename the current emacs-common package to emacs and the current emacs package to emacs-nox. But then the new emacs would have to have a way of requiring the installation of at least one of emacs-nox, emacs-X11, emacs-w32, or emacs-lucid. Is there any way to do this with our current setup machinery? My idea three years ago was to have the new emacs package require a "feature" called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature. This is what Fedora does. Achim didn't think this was feasible without major changes in setup. Is that still the case? If so, can anyone think of another way to accomplish what I want? Hi Ken, Achim recently restructured gnuplot; I used to install gnuplot, gnuplot-base now obsoletes that, and that is all I have installed; alternatives handles the priorities if different packages provide gnuplot: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gnuplot.git gnuplot-base depends2: cygwin, libcairo2, libcerf1, libgd3, libglib2.0_0, liblua5.3, libpango1.0_0, libreadline7 gnuplot-X11 depends2: cygwin, gnuplot-base, libX11_6, ... gnuplot-qt5 depends2: cygwin, gnuplot-X11, libQt5Core5, libQt5Gui5, libQt5Svg5, libgcc1, ... libstdc++6 gnuplot-wx depends2: cygwin, gnuplot-X11, libgcc1, ... libgtk3_0, libstdc++6, libwx_baseu3.0_0, libwx_gtk3u3.0_0 This is very similar to what I currently have in emacs, although with better names. gnuplot-base is comparable to emacs-common+emacs. It doesn't achieve what I was asking for. But if what I was asking for isn't possible, I might still do some renaming, to make the contents clearer. Thanks. Ken
setup build failure
The current setup sources fail to build because ~StringChoiceOption is not defined: CXXLDsetup.exe /usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: io_stream_cygfile.o:/home/kbrown/src/cygsetup/x86_64/../setup/io_stream_cygfile.cc:40: undefined reference to `StringChoiceOption::~StringChoiceOption()' /usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: io_stream_cygfile.o:/home/kbrown/src/cygsetup/x86_64/../setup/io_stream_cygfile.cc:43: undefined reference to `StringChoiceOption::StringChoiceOption(std::vector, std::allocator > >, char, char const*, std::__cxx11::basic_string, std::allocator > const&, bool, int, int)' /usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: main.o:/home/kbrown/src/cygsetup/x86_64/../setup/main.cc:107: undefined reference to `StringChoiceOption::~StringChoiceOption()' /usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/bin/ld: main.o:/home/kbrown/src/cygsetup/x86_64/../setup/main.cc:107: undefined reference to `StringChoiceOption::StringChoiceOption(std::vectorconst*, int>, std::allocator > >, char, char const*, std::__cxx11::basic_string, std::allocator > const&, bool, int, int)' collect2: error: ld returned 1 exit status Ken
Question about 'provides' and emacs packaging
I asked this question several years ago (https://cygwin.com/pipermail/cygwin-apps/2018-October/039451.html), but I'm repeating it, in a more specific form, in the hope that setup has progressed to the point where I get a different answer. There are currently five emacs packages: emacs-common, emacs, emacs-X11, emacs-w32, and emacs-lucid. The first includes things that are needed by each of the other four, and those four each include an emacs binary. The binary in the emacs package is /usr/bin/emacs-nox.exe. The other packages contain /usr/bin/emacs-X11.exe, and so on. This way of naming the packages doesn't really reflect the contents of the emacs package. It also means that anyone who installs emacs gets emacs-nox.exe, even if they plan to use one of the other three binaries. I would rather rename the current emacs-common package to emacs and the current emacs package to emacs-nox. But then the new emacs would have to have a way of requiring the installation of at least one of emacs-nox, emacs-X11, emacs-w32, or emacs-lucid. Is there any way to do this with our current setup machinery? My idea three years ago was to have the new emacs package require a "feature" called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature. This is what Fedora does. Achim didn't think this was feasible without major changes in setup. Is that still the case? If so, can anyone think of another way to accomplish what I want? Thanks. Ken
Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg
On 10/2/2021 1:48 AM, Brian Inglis wrote: On 2021-10-01 22:15, Achim Gratz wrote: Brian Inglis writes: As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that would be the more appropriate place for an autoconf-archive requirement, otherwise cygport would have to require it, which is not so obvious. No. If a build needs autoconf-archive then require it there. The whole point of having things in separate packages is that you do not have to install things you don't need. Neither autottols nor cygport require this package in any way. See response to Yaakov: the problem is it's just a given in the build systems of the packages that use it, I acknowledge that it's easy to give advice with hindsight, but here are two ways you might have discovered that you needed autoconf-archive as a build requirement for your package. 1. You could have checked the Fedora .spec file for the package. In my experience, Fedora maintainers are generally very good at listing build requirements. I don't think you've said what package you're talking about, so I can't check whether that would have helped in this case. 2. An internet search for AX_CODE_COVERAGE would have immediately told you that it's in autoconf-archive. You also mentioned the gnulib bug you ran into while packaging bison. It's unfortunate that you lost so much time on this, but you handled it exactly right. You reported it upstream, they passed it on to gnulib, and it got fixed. We all appreciate the effort you've been making to adopt orphaned packages. I think you've just run into a string of bad luck that has caused this to be very time consuming. Ken
Re: autorebase and user-installed dynamic objects
On 9/27/2021 9:21 AM, ASSI wrote: Ken Brown via Cygwin-apps writes: Note that there are a lot of complaints about non-existent .eln files. I'm experimenting with native-compilation builds of emacs, and I know why these errors are occurring. But I don't think that should be preventing the full rebase from working. It doesn't, based on this information I'd say everything worked as it should. I've fixed the error that was causing rebase to complain about non-existent .eln files, and emacs seems to be working great now (64-bit only). It's possible that we'll find that little or nothing further needs to be done for the 64-bit case. I'm thinking of putting out a test release of emacs so that we can get some more data. In case you want to try it yourself before I get around to doing that, you can find the current version of the .cygport file on the playground branch of the source repo (https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/emacs.git). Ken
Re: autorebase and user-installed dynamic objects
On 9/27/2021 2:43 AM, ASSI wrote: Ken Brown via Cygwin-apps writes: I just tried to do a full rebase (by running 'rebase-trigger full'), but it seems that files from installed packages aren't being rebased. Looking at /var/cache/rebase, it looks like the files in rebase_pkg aren't making it into rebase_all. It should already do a full rebase when you re-install (the latest version is 001091-0.1). I just reinstalled it. Please do that and post / paste: ls -al /var/cache/rebase $ ls -al /var/cache/rebase/ total 579 drwxr-xr-x+ 1 kbrown-admin None 0 2021-09-27 08:35 ./ drwxr-xr-x+ 1 kbrown-admin None 0 2021-09-27 08:35 ../ -rw-r--r-- 1 kbrown-admin None115 2021-09-27 08:35 fullrebase.done -rw-r--r-- 1 kbrown-admin None 138550 2021-09-27 08:35 rebase_all -r--r--r-- 1 kbrown-admin None 25689 2021-09-27 08:35 rebase_dyn -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_dyn.old -r--r--r-- 1 kbrown-admin None 31 2021-09-27 08:35 rebase_dyn_exe -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_dyn_exe.old -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_epoch -r--r--r-- 1 kbrown-admin None 55862 2021-09-27 08:35 rebase_exe -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_exe.old -r--r--r-- 1 kbrown-admin None 120902 2021-09-27 08:35 rebase_lst -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_lst.old -r--r--r-- 1 kbrown-admin None 236372 2021-09-27 08:35 rebase_pkg -rw-r--r-- 1 kbrown-admin None 0 1969-12-31 19:00 rebase_pkg.old -rw-r--r-- 1 kbrown-admin None 64 2021-09-27 08:35 rebuild_always Note that rebase_pkg is much bigger than rebase_all. /var/log/setup.log.full Attached. Note that there are a lot of complaints about non-existent .eln files. I'm experimenting with native-compilation builds of emacs, and I know why these errors are occurring. But I don't think that should be preventing the full rebase from working. Ken setup.log.full.xz Description: Binary data
Re: autorebase and user-installed dynamic objects
On 9/26/2021 4:07 AM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: Installs fine now, thanks. Please install the latest update. I just tried to do a full rebase (by running 'rebase-trigger full'), but it seems that files from installed packages aren't being rebased. Looking at /var/cache/rebase, it looks like the files in rebase_pkg aren't making it into rebase_all. Ken
Re: autorebase and user-installed dynamic objects
On 9/25/2021 11:45 AM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: I tried to install this with 'setup -X', but I'm getting a Download Incomplete pop-up saying that there was a download error for _autorebase-001090-0.1. Can you try again, please? Installs fine now, thanks. I'll try it out with emacs over the next few days. Ken
Re: autorebase and user-installed dynamic objects
On 9/25/2021 9:26 AM, Achim Gratz wrote: I have an interim update that works more or less like the current implementation plus some fixes to be more resilient against filenames containing spaces somewhere (I'd appreciate if somone would actually test that this works), but allows to have more fine-grained control over the locations or files to be rebased (changed documentation below). The .eln suffix is already included in the list of extensions. This only works on systems where the user directory is fully accessible to setup, as it will still be done during the normal autorebase step. Any user-specific rebase that caters to those installations that do not fulfill that requirement will have to wait for the requisite support in rebase to appear. Point setup to use this additional install source: root=http://cygwin.stromeko.net/ $root/stage and install the test package for _autorebase contained therein. I tried to install this with 'setup -X', but I'm getting a Download Incomplete pop-up saying that there was a download error for _autorebase-001090-0.1. Ken
Re: autorebase and user-installed dynamic objects
On 9/20/2021 8:57 AM, Ken Brown via Cygwin-apps wrote:
On 9/20/2021 1:58 AM, ASSI wrote:
Ken Brown via Cygwin-apps writes:
2. Create a script /usr/bin/rebaselst_usr similar to rebaselst, with a
few modifications:
a) All files are in the user's home directory:
l=${HOME}/.config/rebase
b=${HOME}/.cache/rebase
db=${l}/dynpath.d
I've taken a stab at this (attached). The appropriate command, then, is
'rebaselst_usr dyn rebase'. Within emacs I would use something like
(if (eq system-type 'cygwin)
(call-process "rebaselst_usr" nil
'(:file "")
nil "dyn" "rebase"))
I'm not sure yet where this would go so that it's called after compilation but
before the compiled file is loaded. I'll see if Eli can help.
Ken
#!/bin/dash
export PATH=/bin
l=${HOME}/.config/rebase
b=${HOME}/.cache/rebase
eb="${b}/rebase_epoch"
db="${l}/dynpath.d"
for d in ${b} ${db} ; do
if [ ! -d ${d} ] ; then
echo "Directory ${d} does not exist, trying to re-create."
mkdir -p ${d}
fi
done
BaseAddress=''
if [ "x86_64" = $( uname -m ) ] ; then
DefaultBaseAddress=0x4
else
DefaultBaseAddress=0x07000
fi
rebuild="no"
noaslr="no"
verbose=""
doSuffixes='dll|so|oct|mex|eln'
exeSuffixes='exe'
dynPaths=$( cat ${db}/* | sort -u )
dynLocs=''
for d in ${dynPaths} ; do
[ -d "${d}" ] && dynLocs="${dynLocs} ${d}"
done
usage () {
echo "
rebaselst [-h | --help | [ | ... ]]
Commands, will be executed in order:
--verbose
Run some commands with verbose output.
--rebuild
Later commands will discard information in cache files and
rebuild them from scratch.
--no-rebuild
Keep and use information in cache files. This is the default,
can be used to cancel effect of a \"--rebuild\" earlier on the
command line.
update
Update all caches.
dyn
Update cache for dynamic language modules and libraries. This
currently implies \"--rebuild\" since modules could have been
installed by the user and the cache would be outdated.
--noaslr
Remove ASLR and TSAware flags from dynamic objects.
rebase
Rebase with the information in cache files (i.e does not imply
an \"update\").
peflags
Set PE flags on executables with the information in cache
files (i.e does not imply an \"update\").
"
}
check_file () {
if [ "$2" = "yes" -a -e $1 ] ; then
echo "removing $1"
rm -f $1
fi
if [ ! -e "${eb}" ] ; then
touch -d "@0" "${eb}" || \
touch -d "1980-01-01 00:00 UTC""${eb}" || \
touch -d "1999-05-03 07:29:06 UTC" "${eb}" || \
touch -d "2002-08-17 07:00 CEST" "${eb}"
fi
if [ ! -e "$1" ] ; then
echo "creating empty $1"
touch -r "${eb}" "$1"
fi
if [ "$2" != "nowrite" -a -e $1 ] ; then
chmod 644 "$1"
fi
}
_tr () {
local IFS s r
IFS="/-+.,"
for s in $1; do
r="${r}_${s}"
done
echo "${r}"
}
update_file () {
local IFS f g k l m
f="$1"
g="${f}.old"
mv -f "${f}" "${g}"
cat >"${f}" <>"${f}"
chmod 444 "${f}"
}
rebase_do () {
local g
g="${b}/rebase_all"
echo "Rebasing with list ${g}, built from $@."
cat $@ | grep -vE '^#' | sort -u >"${g}"
if [ ! -e "/etc/rebase.db.i386" -a ! -e "/etc/rebase.db.x86_64" ] ; then
BaseAddress="-b ${DefaultBaseAddress}"
fi
rebase ${BaseAddress} ${verbose} -n -O -T "${g}"
if [ "noaslr" = "yes" ] ; then
peflags ${verbose} -d0 -t0 -T "${g}"
fi
BaseAddress=''
}
peflags_do () {
local g
g="${b}/rebase_all_exe"
echo "Setting PE flags with list ${g}, built from $@."
cat $@ | grep -vE '^#|ddd\/Ddd\.exe$' | sort -u >"${g}"
peflags ${verbose} -t1 -T "${g}"
}
rebase_dyn () {
local g
g="${b}/rebase_dyn"
check_file "${g}" "yes"
if [ "x" = "${dynLocs:-x}" ] ; then
touch "${g}"
else
echo "Looking for dynamic language modules/libraries in:"
for d in ${dynLocs} ; do echo " ${d}" ; done
echo "Updating rebase information for dynamic language modules/libraries
${g}."
find ${dynLocs} -xdev -regextype posix-extended -regex
".*\.(${doSuffixes})$" -newer "${g}" >>"${g}"
fi
update_file "${g}"
}
if [ "$#" = "0" ] ; then
set -- "--help"
fi
while [ $# -gt 0 ] ; do
case "$1" in
--verbose )
verbose=--verbose
;;
--rebuild )
rebuild=yes
;;
--noaslr )
noaslr=yes
;;
--no-rebuild )
rebuild=no
;;
rebase )
rebase_do "${b}/rebase_dyn"
;;
peflags )
peflags_do "${b}/rebase_exe"
;;
update )
shift
set -- dummy dyn $@
;;
dyn )
rebase_dyn
;;
-h|--help|* )
usage
exit 127
;;
esac
shift
done
exit 0
Re: [ANNOUNCEMENT] Updated: dash 0.5.11.5
[Redirected from the main cygwin list.] On 9/21/2021 3:12 PM, Ken Brown via Cygwin wrote: On 9/21/2021 1:55 PM, Brian Inglis via Cygwin wrote: On 2021-09-21 10:58, Ken Brown via Cygwin wrote: On 9/21/2021 11:29 AM, Brian Inglis wrote: so suggest we mandate release 0 for test versions, as that would follow naturally. There's no need for that. Maybe it would be a good suggestion then? From my point of view as a maintainer, there are two main reasons I use test releases. 1. For a package in which I'm also an upstream contributor (like Emacs or TeX Live or Cygwin), I might want to make a test release of an upcoming upstream release to catch bugs prior to the release. I generally use release numbers like 0.1, 0.2,... for these. 2. If there's a new upstream release of a package that I'm less familiar with, I just want to make a standard release, but I might not be confident that there's no breakage on Cygwin. So I start with a test release (with release number 1), and if no problems are reported after a few weeks I untest it, keeping the release number unchanged. I personally wouldn't have any use for a release number 0 in either case. Ken
Re: autorebase and user-installed dynamic objects
On 9/20/2021 1:58 AM, ASSI wrote:
Ken Brown via Cygwin-apps writes:
1. Modify rebaseall and rebaselst to recognize 'eln' as a suffix and
to recognize the standard directory where emacs will install the
system-wide .eln files (corresponding to the preloaded libraries).
That would be which directory?
When I build emacs from the upstream repo (without setting prefix) I see
ELN_DESTDIR='/usr/local/lib/emacs/28.0.50/
So I guess they will be in a subdirectory of /usr/lib/emacs when I build emacs
for Cygwin.
2. Create a script /usr/bin/rebaselst_usr similar to rebaselst, with a
few modifications:
a) All files are in the user's home directory:
l=${HOME}/.config/rebase
b=${HOME}/.cache/rebase
db=${l}/dynpath.d
…and there is this knotty problem. The user has one home directory, but
she might be using many different hosts and both Cygwin architectures.
The rebase information is host and architecture specific. I have no
good solution for that yet and I don't know if XDG provides for that
situation. Things might have to go into /var/run/user or some similar
location instead. Note that the architecture dependence of eln (or
really build dependence on a particular Emacs config if you want to be
precise) already is a problem for Emacs in general and I haven't paid
attention as to how they intend to solve that.
I haven't noticed any discussion of that. I don't know about dependence on a
particular Emacs config. But that was never an issue for elc files, so I doubt
if it's an issue for eln files. There's certainly architecture dependence, but
I don't think that will be a problem for us. If rebase encounters a library
intended for a different architecture, I think it will skip it, just as it skips
in-use files, won't it?
Ken
Re: autorebase and user-installed dynamic objects
On 9/19/2021 3:09 PM, Achim Gratz wrote:
Ken Brown via Cygwin-apps writes:
First of all, I think we should make /var/lib/rebase/user.d/
work as documented.
No, that won't help and I should actually remove that facility since it
can't be fixed. The user directory can not assumed to be even
accessible when setup runs. So anything involving a user directory must
be run under that user account, after setup has completed. Anything
that can be done via setup should be done with packages (and those can
already use the dynpath.d facility).
OK.
Users could list their emacs user directory there, and people who
build emacs themselves could also list their emacs build directory.
That way things could be kept reasonably stable in the long run via
the autorebase postinstall script. Implicit in this is that the
results of all these rebases would be stored in the user's rebase
database.
The question of where to store the result is not really important at the
moment. We can just re-generate the intended result each time; if and
only if that works should we then optimize via caching.
How about this as a starting point:
1. Modify rebaseall and rebaselst to recognize 'eln' as a suffix and to
recognize the standard directory where emacs will install the system-wide .eln
files (corresponding to the preloaded libraries).
2. Create a script /usr/bin/rebaselst_usr similar to rebaselst, with a few
modifications:
a) All files are in the user's home directory:
l=${HOME}/.config/rebase
b=${HOME}/.cache/rebase
db=${l}/dynpath.d
b) Each user can create create files in ${db} containing the directories in
which rebaselst_usr should look for libraries to be rebased. In the case of
emacs, I would probably provide a script that users can call to create the
default ${db}/emacs, containing the line ${HOME}/.emacs.d/eln-cache. I don't
know if there are other packages that would want to do something similar.
c) Other obvious modifications/deletions, such as making the rebase ephemeral
for now.
3. Run emacs from a script that calls rebaselst_usr before launching
/usr/bin/emacs. I'll have to think about naming issues. It would be nice if
the script could just be called "emacs", but then something else has to be renamed.
After each compilation, but before the new .eln file is loaded, emacs
could call rebaselst with suitable arguments to rebase that new file
(and add it to the user database).
Yes, something like that or something else with similar effect. But
first we need to figure out if we can get it working at all.
Actually, we could probably just have emacs call rebaselst_usr after each
compilation. Those .eln files that are already loaded won't be rebaseable, but
so what?
Ken
Re: autorebase and user-installed dynamic objects
On 9/19/2021 12:39 PM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: A per-user database sounds like a good idea. Well, the problem is how to maintain it. So let's for the moment skip that part and see if it would work when we pretend we'd already solved that problem. An ephemeral rebase is essentially a user-defined database that gets thrown away immediately, so you can not re-use its information. We would need to replace emacs with a wrapper script that checks a cookie file against the system wide rebase database and if the latter is newer, trigger an ephemeral rebase of the emacs user directory. The same should be done for each compilation. If that works, then we can try to figure out how to not constantly rebase stuff that doesn't need to get rebased again via some sort of user rebase database. I'm not sure the rebase of the emacs user directory has to be ephemeral. First of all, I think we should make /var/lib/rebase/user.d/ work as documented. Users could list their emacs user directory there, and people who build emacs themselves could also list their emacs build directory. That way things could be kept reasonably stable in the long run via the autorebase postinstall script. Implicit in this is that the results of all these rebases would be stored in the user's rebase database. After each compilation, but before the new .eln file is loaded, emacs could call rebaselst with suitable arguments to rebase that new file (and add it to the user database). Ken
Re: autorebase and user-installed dynamic objects
[Redirected from the main Cygwin list.] On 9/19/2021 2:18 AM, ASSI wrote: Ken Brown via Cygwin writes: Looking into /usr/bin/rebaselst, I think I see the problem. The function rebase_user() greps the file /var/lib/rebase/user.d/kbrown for the relevant suffixes, That's how it was originally intended to work, IIRC (but the documentation indeed wrongly suggests to put paths there). Obviously since we didn't have that situation before I never fully tested and completed this part. instead of looking for files in /home/kbrown/.emacs.d/eln-cache. Shouldn't rebase_user use a variable "userLocs" analogous to the variable "dynLocs" used by rebase_dyn()? Or am I completely misunderstanding how this is supposed to work? For reasons I don't exactly remember, I wanted to avoid that. Probably because the user directory might not be available or accessible for the install user, but then obviously you'd just as likely have a problem with the actual rebasing also. I've been mulling the idea of having user specific rebase databases on top of the system one (or more generally a hierarchy of rebase DB) several times and that's one of the reasons they might be needed. Let's discuss how this can and should work on cygwin-apps. A per-user database sounds like a good idea. Ken
Re: scallywag zp_texlive_finish.dash failing exit code 2 rebuilding installed formats
On 8/23/2021 8:26 PM, Brian Inglis wrote: On 2021-08-23 15:08, Ken Brown via Cygwin-apps wrote: On 8/23/2021 2:46 PM, Brian Inglis wrote: On 2021-08-22 16:58, Ken Brown via Cygwin-apps wrote: OK, your later messages explain it better. I'll have to look at texlive-collection-formatsextra; it's possible that it needs to require texlive-collection-fontsrecommended. But a better solution to your immediate problem would be for someone to look at docbook-utils and see whether it really needs texlive-collection-formatsextra. It currently requires the obsolete texlive-collection-htmlxml, which pulls in a lot of other packages, probably unnecessarily in most cases. See https://cygwin.com/packages/summary/texlive-collection-htmlxml.html That would require a TeX-y who knows the TeX relationships of the files. From what I can see jadetex and pdfjadtex are used by docbook-utils, OK, so docbook-utils definitely needs texlive-collection-formatsextra, which is what I hoped to avoid. In that case, it's probably not worth checking whether it needs the other dependencies of texlive-collection-htmlxml. And jadetex needs texlive-collection-fontsrecommended for marvosym, so I need to fix the dependencies of texlive-collection-formatsextra. I'll do that shortly. Thanks Ken Thanks for reporting the problem. I will trim back the BUILD_REQUIRES to ...formatsextra (and ...plaingeneric? for html?) without other additions to see if zp_texlive_finish.dash completes under scallywag and also whether the package builds with just those packages. Why do you need explicit texlive build dependencies at all? If what you really need is docbook-utils, you should just require it and let it pull in whatever texlive collections are needed. This should work now that I've fixed formatsextra. Ken
Re: scallywag zp_texlive_finish.dash failing exit code 2 rebuilding installed formats
On 8/23/2021 2:46 PM, Brian Inglis wrote: On 2021-08-22 16:58, Ken Brown via Cygwin-apps wrote: OK, your later messages explain it better. I'll have to look at texlive-collection-formatsextra; it's possible that it needs to require texlive-collection-fontsrecommended. But a better solution to your immediate problem would be for someone to look at docbook-utils and see whether it really needs texlive-collection-formatsextra. It currently requires the obsolete texlive-collection-htmlxml, which pulls in a lot of other packages, probably unnecessarily in most cases. See https://cygwin.com/packages/summary/texlive-collection-htmlxml.html That would require a TeX-y who knows the TeX relationships of the files. From what I can see jadetex and pdfjadtex are used by docbook-utils, OK, so docbook-utils definitely needs texlive-collection-formatsextra, which is what I hoped to avoid. In that case, it's probably not worth checking whether it needs the other dependencies of texlive-collection-htmlxml. And jadetex needs texlive-collection-fontsrecommended for marvosym, so I need to fix the dependencies of texlive-collection-formatsextra. I'll do that shortly. Thanks for reporting the problem. Ken
Re: scallywag zp_texlive_finish.dash failing exit code 2 rebuilding installed formats
On 8/22/2021 6:38 PM, Ken Brown via Cygwin-apps wrote:
On 8/22/2021 5:57 PM, Brian Inglis wrote:
On 2021-08-22 09:33, Brian Inglis wrote:
On 2021-08-22 09:15, Jon Turney wrote:
On 22/08/2021 01:48, Brian Inglis wrote:
Any way to see if there is anything useful in scallywag #160 (3181)
fontconfig run 1154600337 build_requires setup /var/log/setup.log.full
without hacking and pushing fontconfig.cygport?
https://github.com/cygwin/scallywag/actions/runs/1154600337/workflow
Trying to build updated fontconfig (to see if continual cache creation
issue has been resolved, or analyze and hopefully debug that issue to
remove or patch the cause, then ITA), but getting weird build issues.
Trying scallywag playground, but it's also having problems installing
prereq texlive-collection-htmlxml, which pulls in other packages including
texlive-collection-formatsextra, which need built by
/etc/postinstall/zp_texlive_finish.dash, which is failing somewhere with
exit code 2 - not a lot of detail!
I've tweaked scallywag so setup.log.full is also preserved in the builddir
artefact.
This might now contain something useful if the post-install script is
emitting an error.
Thanks Jon,
I'll rerun and check, and see if I can mitigate it in cygport under scallywag.
Thanks again Jon,
That allowed me to track it down: it looks like the issue is marvosym:
docbook-utils -> texlive-collection-htmlxml -> texlive-collection-plaingeneric
-> marvosym -> texlive-collection-fontsrecommended
but texlive-collection-plaingeneric does not require
texlive-collection-fontsrecommended, so it looks like that may have to be
explicitly requested in the cygport build.
Opinion sought from Ken Brown!
$ zfgrep marvosym
/etc/setup/texlive-collection-{plaingeneric,fontsrecommended}.lst.gz
/etc/setup/texlive-collection-plaingeneric.lst.gz:usr/share/texmf-dist/tex4ht/ht-fonts/alias/marvosym/
/etc/setup/texlive-collection-plaingeneric.lst.gz:usr/share/texmf-dist/tex4ht/ht-fonts/alias/marvosym/fmvri8x.htf
/etc/setup/texlive-collection-plaingeneric.lst.gz:usr/share/texmf-dist/tex4ht/ht-fonts/unicode/marvosym/
/etc/setup/texlive-collection-plaingeneric.lst.gz:usr/share/texmf-dist/tex4ht/ht-fonts/unicode/marvosym/fmvr8x.htf
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/afm/public/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/afm/public/marvosym/marvosym.afm
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/map/dvips/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/map/dvips/marvosym/marvosym.map
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/tfm/public/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/tfm/public/marvosym/umvs.tfm
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/truetype/public/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/truetype/public/marvosym/marvosym.ttf
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/type1/public/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/type1/public/marvosym/marvosym.pfb
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/tex/latex/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/tex/latex/marvosym/marvosym.sty
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/tex/latex/marvosym/umvs.fd
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/tlpkg/tlpobj/marvosym.tlpobj
Sorry, but I need more detail. I'd be very surprised if
texlive-collection-fontsrecommended is needed in order to rebuild formats, but
maybe I'm missing something. Please start from the beginning and say exactly
what you're doing and exactly how zp_texlive_finish.dash is failing.
OK, your later messages explain it better. I'll have to look at
texlive-collection-formatsextra; it's possible that it needs to require
texlive-collection-fontsrecommended. But a better solution to your immediate
problem would be for someone to look at docbook-utils and see whether it really
needs texlive-collection-formatsextra. It currently requires the obsolete
texlive-collection-htmlxml, which pulls in a lot of other packages, probably
unnecessarily in most cases. See
https://cygwin.com/packages/summary/texlive-collection-htmlxml.html
Ken
Re: scallywag zp_texlive_finish.dash failing exit code 2 rebuilding installed formats
On 8/22/2021 5:57 PM, Brian Inglis wrote:
On 2021-08-22 09:33, Brian Inglis wrote:
On 2021-08-22 09:15, Jon Turney wrote:
On 22/08/2021 01:48, Brian Inglis wrote:
Any way to see if there is anything useful in scallywag #160 (3181)
fontconfig run 1154600337 build_requires setup /var/log/setup.log.full
without hacking and pushing fontconfig.cygport?
https://github.com/cygwin/scallywag/actions/runs/1154600337/workflow
Trying to build updated fontconfig (to see if continual cache creation issue
has been resolved, or analyze and hopefully debug that issue to remove or
patch the cause, then ITA), but getting weird build issues.
Trying scallywag playground, but it's also having problems installing prereq
texlive-collection-htmlxml, which pulls in other packages including
texlive-collection-formatsextra, which need built by
/etc/postinstall/zp_texlive_finish.dash, which is failing somewhere with
exit code 2 - not a lot of detail!
I've tweaked scallywag so setup.log.full is also preserved in the builddir
artefact.
This might now contain something useful if the post-install script is
emitting an error.
Thanks Jon,
I'll rerun and check, and see if I can mitigate it in cygport under scallywag.
Thanks again Jon,
That allowed me to track it down: it looks like the issue is marvosym:
docbook-utils -> texlive-collection-htmlxml -> texlive-collection-plaingeneric
-> marvosym -> texlive-collection-fontsrecommended
but texlive-collection-plaingeneric does not require
texlive-collection-fontsrecommended, so it looks like that may have to be
explicitly requested in the cygport build.
Opinion sought from Ken Brown!
$ zfgrep marvosym
/etc/setup/texlive-collection-{plaingeneric,fontsrecommended}.lst.gz
/etc/setup/texlive-collection-plaingeneric.lst.gz:usr/share/texmf-dist/tex4ht/ht-fonts/alias/marvosym/
/etc/setup/texlive-collection-plaingeneric.lst.gz:usr/share/texmf-dist/tex4ht/ht-fonts/alias/marvosym/fmvri8x.htf
/etc/setup/texlive-collection-plaingeneric.lst.gz:usr/share/texmf-dist/tex4ht/ht-fonts/unicode/marvosym/
/etc/setup/texlive-collection-plaingeneric.lst.gz:usr/share/texmf-dist/tex4ht/ht-fonts/unicode/marvosym/fmvr8x.htf
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/afm/public/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/afm/public/marvosym/marvosym.afm
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/map/dvips/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/map/dvips/marvosym/marvosym.map
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/tfm/public/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/tfm/public/marvosym/umvs.tfm
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/truetype/public/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/truetype/public/marvosym/marvosym.ttf
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/type1/public/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/fonts/type1/public/marvosym/marvosym.pfb
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/tex/latex/marvosym/
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/tex/latex/marvosym/marvosym.sty
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/texmf-dist/tex/latex/marvosym/umvs.fd
/etc/setup/texlive-collection-fontsrecommended.lst.gz:usr/share/tlpkg/tlpobj/marvosym.tlpobj
Sorry, but I need more detail. I'd be very surprised if
texlive-collection-fontsrecommended is needed in order to rebuild formats, but
maybe I'm missing something. Please start from the beginning and say exactly
what you're doing and exactly how zp_texlive_finish.dash is failing.
Thanks.
Ken
Re: attention alternatives maintainer
On 7/15/2021 9:56 PM, Ken Brown via Cygwin-apps wrote: On 7/15/2021 7:07 PM, Doug Henderson via Cygwin-apps wrote: Please update alternatives to work properly for a first time install of an alternative when CYGWIN=winsymlinks:nativestrict. Cygwin doesn't have an alternatives maintainer. Would you like to volunteer? If so, start at https://cygwin.com/packages.html and follow up on the cygwin-apps mailing list if you need help. Sorry, I see you're already a package maintainer, so you know how to do it. Ken
Re: attention alternatives maintainer
On 7/15/2021 7:07 PM, Doug Henderson via Cygwin-apps wrote: Please update alternatives to work properly for a first time install of an alternative when CYGWIN=winsymlinks:nativestrict. Cygwin doesn't have an alternatives maintainer. Would you like to volunteer? If so, start at https://cygwin.com/packages.html and follow up on the cygwin-apps mailing list if you need help. Ken
Re: [ITP] tractorgen 0.31.7
On 6/1/2021 1:36 PM, Marco Atzeri via Cygwin-apps wrote: On 01.06.2021 14:41, Daisuke Fujimura via Cygwin-apps wrote: Hello, [ITP] A new package proposal: tractorgen - tractorgen The package seems not very used. Not sure fit in our scope for missing the need for a vote Opinion from the other maintainers ? Since the package doesn't appear to be in any of the standard Linux distributions, I think our policy is that it needs affirmative votes from 5 maintainers. Ken
Re: duplicate between packages
On 4/26/2021 11:45 PM, Marco Atzeri via Cygwin-apps wrote: Hi Maintainers, as I just found 2 of my packages colliding with same program name $ cygcheck -f /usr/bin/ncgen hdf4-4.2.15-3 netcdf-4.8.0-2 as one is much older than the other, the installation sequence can give some inconsistencies in the system. So I checked on my /etc/setup how many duplicates there are and it seems also other package has the same problem 2 usr/bin/pygmentex This and the other pygmentex duplicates you found are due to a packaging error, in which I included pygmentex in both texlive-collection-latexextra and texlive-collection-mathscience. I've just fixed this with an update of texlive-collection-mathscience. 2 usr/bin/t1ascii.exe 2 usr/bin/t1asm.exe 2 usr/bin/t1binary.exe 2 usr/bin/t1disasm.exe 2 usr/bin/t1mac.exe 2 usr/bin/t1unmac.exe These are in t1utils as well as texlive. The t1utils package is currently orphaned, and the upstream package is included in TeX Live (https://ctan.org/pkg/t1utils?lang=en). So I'm inclined to ignore this for now. If anyone ever wants to take over maintainership of t1utils, we can discuss what to do. 2 usr/share/man/man1/pdfdetach.1.gz 2 usr/share/man/man1/pdffonts.1.gz 2 usr/share/man/man1/pdfimages.1.gz 2 usr/share/man/man1/pdfinfo.1.gz 2 usr/share/man/man1/pdftohtml.1.gz 2 usr/share/man/man1/pdftoppm.1.gz 2 usr/share/man/man1/pdftops.1.gz 2 usr/share/man/man1/pdftotext.1.gz This is another packaging bug. The files are included in both xpdf and poppler, but they should only be in poppler. I'll fix it when xpdf is next updated. 2 usr/share/texmf-dist/doc/generic/tex-ini-files/README.md And another one. This is in both texlive-collection-basic and texlive-collection-basic-doc. I'll fix it in the next update. Ken
g-ir-scanner fails with python-3.8
Trying to build harfbuzz, I get the following python failure with python-3.8 Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 65, in from giscanner.scannermain import scanner_main File "/usr/lib/gobject-introspection/giscanner/scannermain.py", line 41, in from giscanner.dumper import compile_introspection_binary File "/usr/lib/gobject-introspection/giscanner/dumper.py", line 35, in from .gdumpparser import IntrospectionBinary File "/usr/lib/gobject-introspection/giscanner/gdumpparser.py", line 36, in from .transformer import TransformerException File "/usr/lib/gobject-introspection/giscanner/transformer.py", line 34, in from .girparser import GIRParser File "/usr/lib/gobject-introspection/giscanner/girparser.py", line 31, in from .girwriter import COMPATIBLE_GIR_VERSION File "/usr/lib/gobject-introspection/giscanner/girwriter.py", line 29, in from .xmlwriter import XMLWriter File "/usr/lib/gobject-introspection/giscanner/xmlwriter.py", line 46, in from giscanner._giscanner import collect_attributes ImportError: dynamic module does not define module export function (PyInit__giscanner) The log of my last successful build of harfbuzz shows that python-3.6 was installed. Do any of the python experts out there (Marco? Jon?) know what the problem could be? Thanks. Ken
Re: duplicate between packages
On 4/26/2021 11:45 PM, Marco Atzeri via Cygwin-apps wrote: Hi Maintainers, as I just found 2 of my packages colliding with same program name $ cygcheck -f /usr/bin/ncgen hdf4-4.2.15-3 netcdf-4.8.0-2 as one is much older than the other, the installation sequence can give some inconsistencies in the system. So I checked on my /etc/setup how many duplicates there are and it seems also other package has the same problem Some are not an issue, but on the binaries I can not judge $ cygcheck -f /usr/i686-w64-mingw32/sys-root/mingw/include/pthread_signal.h mingw64-i686-headers-8.0.0-1 mingw64-i686-winpthreads-8.0.0-1 $ cygcheck -f /usr/bin/t1asm.exe t1utils-1.39-1 texlive-20210325-1 $ cd /etc/setup $ zcat *.lst.gz | sed '/\/$/d' | sort |uniq -c | awk '$1 > 1' 3 etc/postinstall/python3-wx.sh 2 usr/bin/gpgsplit.exe 2 usr/bin/ncdump.exe 2 usr/bin/ncgen.exe 2 usr/bin/prove 2 usr/bin/pygmentex 2 usr/bin/shasum 2 usr/bin/t1ascii.exe 2 usr/bin/t1asm.exe 2 usr/bin/t1binary.exe 2 usr/bin/t1disasm.exe 2 usr/bin/t1mac.exe 2 usr/bin/t1unmac.exe 2 usr/i686-w64-mingw32/sys-root/mingw/include/pthread_signal.h 2 usr/lib/cygh5bzip2.dll 3 usr/share/aclocal/README 2 usr/share/doc/fltk/CHANGES 2 usr/share/doc/fltk/COPYING 2 usr/share/doc/fltk/CREDITS 2 usr/share/doc/fltk/examples/adjuster.cxx ... 2 usr/share/doc/fltk/examples/valuators.h 2 usr/share/doc/fltk/README 2 usr/share/doc/libsodium/AUTHORS 2 usr/share/doc/libsodium/ChangeLog 2 usr/share/doc/libsodium/LICENSE 2 usr/share/doc/libsodium/THANKS 2 usr/share/doc/libspiro/README 2 usr/share/doc/libuninameslist/COPYING 2 usr/share/doc/libuninameslist/LICENSE 2 usr/share/doc/webrtc-audio-processing/AUTHORS 2 usr/share/doc/webrtc-audio-processing/COPYING 2 usr/share/doc/webrtc-audio-processing/NEWS 2 usr/share/doc/webrtc-audio-processing/README 2 usr/share/info/guile.info.gz 2 usr/share/info/guile.info-9.gz 2 usr/share/info/r5rs.info.gz 2 usr/share/man/man1/ncdump.1.gz 2 usr/share/man/man1/ncgen.1.gz 2 usr/share/man/man1/passwd.1.gz 2 usr/share/man/man1/pdfdetach.1.gz 2 usr/share/man/man1/pdffonts.1.gz 2 usr/share/man/man1/pdfimages.1.gz 2 usr/share/man/man1/pdfinfo.1.gz 2 usr/share/man/man1/pdftohtml.1.gz 2 usr/share/man/man1/pdftoppm.1.gz 2 usr/share/man/man1/pdftops.1.gz 2 usr/share/man/man1/pdftotext.1.gz 2 usr/share/man/man1/ts.1.gz 2 usr/share/texmf-dist/doc/generic/tex-ini-files/README.md 2 usr/share/texmf-dist/scripts/pygmentex/pygmentex.py 2 usr/share/texmf-dist/tex/latex/pygmentex/pygmentex.sty 2 usr/share/tlpkg/tlpobj/pygmentex.i386-cygwin.tlpobj 2 usr/share/tlpkg/tlpobj/pygmentex.tlpobj 2 usr/share/tlpkg/tlpobj/pygmentex.x86_64-cygwin.tlpobj 2 usr/share/tlpkg/tlpobj/tex-ini-files.doc.tlpobj 2 usr/x86_64-w64-mingw32/sys-root/mingw/include/pthread_signal.h Thanks, Marco. Several of these involve my packages. I'll take a look at those. Ken
Re: libgccjit-0
On 4/12/2021 8:18 AM, Ken Brown via Cygwin-apps wrote: On 4/12/2021 1:55 AM, ASSI wrote: Ken Brown via Cygwin-apps writes: Sorry, I spoke too soon. It's not even working right on x86_64. In my first build, the ordinary byte-compiled files (.elc) were already present, and that somehow prevented the native-compiled files (.eln) from being built. I just tried 'make bootstrap' and the build won't complete because of fork errors like this (on x86_64): 0 [main] emacs 5400 child_info_fork::abort: address space needed by 'jit-lock-05ec1a9b-73eb7028.eln' (0x40) is already occupied In an earlier attempt it was a different .eln file that was involved, but the address was the same (0x40). Disappointing, but semi-expected. Can you tell me what peflags thinks are the characteristics of the .eln files produced? $ peflags -v jit-lock-05ec1a9b-73eb7028.eln jit-lock-05ec1a9b-73eb7028.eln: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll]) pe(0x) You could also check if an ephemeral rebase helps. I'll give that a try. Good news: An ephemeral rebase at an appropriate place in the Makefile allows a bootstrap to succeed on both architectures. Thanks for the suggestion. Ken
Re: libgccjit-0
On 4/12/2021 1:55 AM, ASSI wrote: Ken Brown via Cygwin-apps writes: Sorry, I spoke too soon. It's not even working right on x86_64. In my first build, the ordinary byte-compiled files (.elc) were already present, and that somehow prevented the native-compiled files (.eln) from being built. I just tried 'make bootstrap' and the build won't complete because of fork errors like this (on x86_64): 0 [main] emacs 5400 child_info_fork::abort: address space needed by 'jit-lock-05ec1a9b-73eb7028.eln' (0x40) is already occupied In an earlier attempt it was a different .eln file that was involved, but the address was the same (0x40). Disappointing, but semi-expected. Can you tell me what peflags thinks are the characteristics of the .eln files produced? $ peflags -v jit-lock-05ec1a9b-73eb7028.eln jit-lock-05ec1a9b-73eb7028.eln: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll]) pe(0x) You could also check if an ephemeral rebase helps. I'll give that a try. Ken
Re: libgccjit-0
On 4/11/2021 3:48 PM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: On 4/11/2021 11:49 AM, Achim Gratz wrote: Both architectures? For whatever reasons the gcc testsuite on x86 always bombed out on these, so I have no idea if it works there. Yes, it works on x86 too. Great. So I'll have to update the MingW64 toolchains to 10.3 as well (these will not get libgccjit since I'd have to pull in the patches from MSys and I don't think there's a consumer for it anyway) and think about the packaging again. Not sure when I'll get around to wrap things up. Sorry, I spoke too soon. It's not even working right on x86_64. In my first build, the ordinary byte-compiled files (.elc) were already present, and that somehow prevented the native-compiled files (.eln) from being built. I just tried 'make bootstrap' and the build won't complete because of fork errors like this (on x86_64): 0 [main] emacs 5400 child_info_fork::abort: address space needed by 'jit-lock-05ec1a9b-73eb7028.eln' (0x40) is already occupied In an earlier attempt it was a different .eln file that was involved, but the address was the same (0x40). I have no idea what's going on. Ken
Re: libgccjit-0
On 4/11/2021 11:49 AM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: Thanks! It works great for building the feature/native-comp branch of emacs. (configure --with-native-compilation if you want to try it yourself.) Both architectures? For whatever reasons the gcc testsuite on x86 always bombed out on these, so I have no idea if it works there. Yes, it works on x86 too. Ken
Re: libgccjit-0
On 4/10/2021 12:23 PM, Achim Gratz wrote: I've uploaded a test version of gcc-10.3.0 that has the JIT library enabled: Thanks! It works great for building the feature/native-comp branch of emacs. (configure --with-native-compilation if you want to try it yourself.) One minor packaging note: I would have expected the libgccjit0 package to contain only the DLL, with everything else in a libgccgit-devel package. Ken
Re: setup 2.906 release candidate - please test
On 3/17/2021 5:16 PM, Thomas Wolff wrote: Am 17.03.2021 um 21:02 schrieb Jon Turney: A new setup release candidate is available at: https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version) https://cygwin.com/setup/setup-2.906.x86.exe (32 bit version) Please test, and report any problems here. I feel the need to take this occasion to woe about the terrible UI of setup. Two years or more ago there was a major revision, sarcastically accompanied by the comment the UI would have been pushed forward to the 90s. Before that, you could simply select a package by clicking one (!) checkbox. Since then, you have to open a popup, scroll to the latest version and click that. This multiplies the effort to do selections significantly and it's quite a nuisance. If you double-click in the New column, I think it will do what you want. Ken
Re: I14N, L10N impacts: CLDR 39 alpha, ICU 69 dev, git lfs prereq, Unicode 14 alpha
On 3/2/2021 12:21 PM, Brian Inglis wrote: Hi folks, Just a heads up that CLDR is changing a number of its structures impacting ICU, and both CLDR alpha and ICU dev are available for testing "some significant migration issues" before their final release on 2021 Apr 7 Wed: http://blog.unicode.org/2021/03/unicode-cldr-v39-alpha-available-for.html http://cldr.unicode.org/index/downloads/cldr-39 The ICU repo requires git lfs installed and it does not appear to be packaged yet. http://site.icu-project.org/repository https://github.com/unicode-org/icu Also Unicode 14 alpha is available for review as they are changing some of their attributes and uses on code points: http://blog.unicode.org/2021/02/unicode-140-alpha-review.html Emoji proposals: https://www.unicode.org/L2/L2020/20242r2-emoji-recs-14.pdf Thanks for the heads up. If there are significant migration issues, I probably won't package icu-69 right away when it's released. Cygwin is already ahead of Fedora Rawhide, which is still on icu-67. Ken
Re: [ITP] gengetopt 2.23
On 2/25/2021 1:18 PM, Rafel Amer Ramon wrote: El 1/12/20 a les 18:23, Ken Brown via Cygwin-apps ha escrit: On 12/1/2020 11:04 AM, Rafel Amer Ramon wrote: El 30/11/20 a les 21:28, Ken Brown via Cygwin-apps ha escrit: On 11/30/2020 2:46 PM, Ken Brown via Cygwin-apps wrote: On 11/29/2020 2:19 PM, Rafel Amer Ramon wrote: Hi, [ITP] gengetopt 2.23 Program home page: https://www.gnu.org/software/gengetopt License: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. Debian package: https://packages.debian.org/buster/gengetopt I have uploaded the files to https://github.com/rafelamer/cygwin-gengetopt https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt.cygport https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23.tar.xz https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1-src.hint https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1-src.tar.xz https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1.hint https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1.tar.xz This looks good. I just have a few minor comments. - The SUMMARY should generally not start by repeating the package name. "A tool to write command line option parsing code for C programs" suffices. - I suggest adding HOMEPAGE="https://www.gnu.org/software/gengetopt/; - The build produces a source patch because of changes to test files: >>> Creating source patches tests/test_conf_parser_ov2.c | 2 +- tests/test_conf_parser_ov3.c | 4 ++-- tests/test_conf_parser_ov4.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) You can use DIFF_EXCLUDES to avoid this. - There are two failing tests that you might want to look into at some point. - I noticed that your github repo contains all the build files. Once you become maintainer, you will be able to push to the official source repo for the package (see https://cygwin.com/packaging/repos.html). This should not contain only the should contain files needed for building the package (i.e., only the cygport file in your case). Pushing to that repo triggers an automatic build (see https://cygwin.com/cgi-bin2/jobs.cgi). I'll go ahead and add you to https://cygwin.com/cygwin-pkg-maint, but I'm not sure how to parse your name. Should it be "Rafel Amer" or "Rafel Amer Ramon" or something else? Thanks for becoming a maintainer. Ken Hi, I have added the lines HOMEPAGE="https://www.gnu.org/software/gengetopt/; DIFF_EXCLUDES="test_conf_parser_ov2.c test_conf_parser_ov3.c test_conf_parser_ov4.c" to gengetopt.cygport and changed the line SUMMARY="A tool to write command line options parser code for C programs" but I can't find the failed tests. Maybe they are cheking for valgring: no checking for help2man: no I'm talking about the tests that are run if you type "cygport gengetopt.cygport test" (equivalent to running "make check" in an ordinary build that doesn't use cygport). Finding the cause of the test failures is not critical, but you should probably try at some point, not necessarily before uploading. I have installed help2man, but I don't know how to install valgrind. My name can be in both forms, but I prefer Rafel Amer OK, I've added you as maintainer. The next step is to send your SSH key following the instructions at https://cygwin.com/packaging/key.html#sshkey Once you receive an acknowledgement, you can upload the package. Ken Hi, when I try to upload the package with the command $ git push cyg...@cygwin.com:/git/cygwin-packages/gengetopt.git This doesn't upload the package, it just pushes your source repository for the package to a central place. The instructions say to use git push cyg...@cygwin.com:/git/cygwin-packages/packagename with no ".git". I don't know if that's the issue. Or maybe the problem is that you haven't uploaded the package yet. If removing ".git" and/or retrying after you upload the package don't fix the problem, we'll need Jon Turney's help. I get the followin error cyg...@cygwin.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Maybe I don't upload the package correctly. Instructions for uploading a package are here: https://cygwin.com/package-upload.html Ken
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
On 2/15/2021 3:32 PM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: Is this expected? Will the files stay in my upload area and be merged when the time comes? It seems that upload has completed, right? Anything else from you? Yes, it completed, and I'm all set. Ken
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
On 2/12/2021 1:46 AM, ASSI wrote: Jon Turney writes: I've fixed what I needed to in the relarea, so this update can proceed when Achim gives the go ahead. Please upload your packages, but please double-check that there is a dependency on perl5_032 in the hints. If everything works as intended, then setup will not update to any of these new packages until the provide for perl5_032 is available. Please let me know when you have uploaded you packages so I know when I should be uploading the final package that enables the upgrade to perl-5.32.1 via setup. I uploaded biber via cygport and got the following from calm: ERROR: package 'biber' version '2.16-2' requires: 'perl5_032', but nothing satisfies that ERROR: package 'biber' version '2.16-2' depends: 'perl5_032', but nothing satisfies that ERROR: error while validating merged x86 packages for Ken Brown ERROR: package 'biber' version '2.16-2' requires: 'perl5_032', but nothing satisfies that ERROR: package 'biber' version '2.16-2' depends: 'perl5_032', but nothing satisfies that ERROR: error while validating merged x86_64 packages for Ken Brown SUMMARY: 6 ERROR(s) Is this expected? Will the files stay in my upload area and be merged when the time comes? Ken
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
On 2/6/2021 11:13 AM, Achim Gratz wrote: Achim Gratz writes: Please prepare your packages for the release of perl-5.32 and report on this list about their status. The one package that I intend to wait for the release is subversion-perl, everything else either is under my maintenance already or can be updated slightly later without too much disturbance based on the last two updates of Perl. Please note that I can't easily figure out if a package uses an embedded Perl interpreter or sets up its own installation paths for Perl modules. These packages have previously been determined to fall under that category (some may have dropped that dependency in the meantime, but the maintainer would hopefully know): texinfo No problem here. I tested by running 'make check' in the texinfo source tree, with perl-5.32 installed. Ken
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
On 2/4/2021 9:04 AM, Ken Brown via Cygwin-apps wrote: On 2/4/2021 7:10 AM, Andrew Schulman via Cygwin-apps wrote: The Perl 5.32 test repository is now updated with the stage 3 bootstrap packages at: root=http://cygwin.stromeko.net/ $root/perl-5.32 Not sure I understand. In setup I entered http://cygwin.stromeko.net/perl-5.32 as a mirror URL, but setup complains: Mirror error: Setup.ini signature http://cygwin.stromeko.net/perl-5.32/x86_64/setup.xz.sig from http://cygwin.stromeko.net/perl-5.32 failed to verify. Try adding '-K http://cygwin.stromeko.net/stromeko.gpg' to your invocation of setup. P.S. I assume you're asking about this so that you can rebuild perl-Stow. In case you missed it, Achim made a packaging suggestion here: https://cygwin.com/pipermail/cygwin/2021-January/247594.html Ken
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
On 2/4/2021 7:10 AM, Andrew Schulman via Cygwin-apps wrote: The Perl 5.32 test repository is now updated with the stage 3 bootstrap packages at: root=http://cygwin.stromeko.net/ $root/perl-5.32 Not sure I understand. In setup I entered http://cygwin.stromeko.net/perl-5.32 as a mirror URL, but setup complains: Mirror error: Setup.ini signature http://cygwin.stromeko.net/perl-5.32/x86_64/setup.xz.sig from http://cygwin.stromeko.net/perl-5.32 failed to verify. Try adding '-K http://cygwin.stromeko.net/stromeko.gpg' to your invocation of setup. Ken
Re: dblatex needs update
On 2/3/2021 10:18 PM, Marco Atzeri wrote: On 04.02.2021 04:14, Ken Brown wrote: too fast: I assume texlive-collection-mathextra was replaced by texlive-collection-mathscience That's right. texlive-collection-mathscience obsoletes both texlive-collection-mathextra and texlive-collection-science. Ken Hi Ken, 0.3.12 is going up I will announce after you check that is fine Works fine. I tested it by building cygwin, in which dblatex is used to build the docs. Thanks. Ken
Re: dblatex needs update
[Resending. Accidentally replied to Marco instead of to list.]
On 2/3/2021 10:00 PM, Marco Atzeri via Cygwin-apps wrote:
On 04.02.2021 03:44, Marco Atzeri wrote:
On 04.02.2021 03:30, Marco Atzeri wrote:
On 04.02.2021 03:00, Marco Atzeri wrote:
On 04.02.2021 00:30, Yaakov Selkowitz via Cygwin-apps wrote:
On Wed, 2021-02-03 at 16:49 -0500, Ken Brown via Cygwin-apps wrote:
dblatex (still shown as maintained by Yaakov) is currently broken
0.3.12-1
going up with
--
#!/usr/bin/python3
from dbtexmf.dblatex import dblatex
dblatex.main('/usr/share/dblatex')
Regards
Marco
too fast:
I assume
texlive-collection-mathextra
was replaced by
texlive-collection-mathscience
That's right. texlive-collection-mathscience obsoletes both
texlive-collection-mathextra and texlive-collection-science.
Ken
dblatex needs update
dblatex (still shown as maintained by Yaakov) is currently broken because it was built for python2 but its shebang points to python. I could do a quick non-maintainer upload to fix the shebang, but maybe someone wants to adopt it and rebuild it for python3. Ken
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
On 2/3/2021 2:31 AM, Marco Atzeri via Cygwin-apps wrote: On 03.02.2021 07:13, ASSI wrote: Ken Brown via Cygwin-apps writes: biber is ready to go. Off the top of my head I think perl-PAR-Packer is also yours and probably the only one I don't co-own. I can include it in the jumbo update if you give me co-maint. I had forgotten about that. Yes, please include it in the jumbo update. I set it for dual; Thanks, Marco. Ken
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
On 2/2/2021 2:40 PM, Achim Gratz wrote: Please prepare your packages for the release of perl-5.32 and report on this list about their status. biber is ready to go. Ken
Re: python 2 check & cleaning
On 1/18/2021 1:25 PM, Ken Brown via Cygwin-apps wrote: On 1/18/2021 12:33 AM, Marco Atzeri via Cygwin-apps wrote: Hi All, the current python test packages remove the link python->python2.7 and replace with an alternative appraouch. Before making the switch, I would like to review the packages that could be broken, so I looked at all packages, not in "python*-*" form, that pull one of the "python", "python2" and "python27" using $ cygcheck-dep -O -S -q -n python.. as base. There are almost 200 binary packages (of the almost 9000 currently present on 64 bit) The list with source package and maintainer is here: https://drive.google.com/file/d/1xaPzIZ78JzHtJXcdzB77qJoeNlvVQRJq/view?usp=sharing I know that Mercurial need rebuild, and I assume the same for subversion (that I plan to adopt). Could you please check your packages if they will work with preferred python3.8 ? Texlive and fontforge seem the most urgent, IMHO, for a verification. I think TeX Live should be fine. All of the python scripts provided by the texlive-collection-* packages are identical across platforms, so any python3 incompatibilities would almost certainly have been reported and fixed by now. I think all I have to do is rebuild the collections that contain python scripts to make sure I pick up the latest versions of the upstream packages, and also to let cygport update the dependencies. I can do that quickly as soon as cygport is ready for the new system. I've started doing some trial rebuilds on a system with the test python3 packages installed. I'm finding that cygport doesn't pick up any python dependency for some packages (such as texlive-collection-binextra-doc) even though there's a script with a shebang "#!/usr/bin/env python". Marco, you've probably said this already, but could you confirm that this is to be expected until cygport is modified? Ken
Re: python 2 check & cleaning
On 1/18/2021 12:33 AM, Marco Atzeri via Cygwin-apps wrote: Hi All, the current python test packages remove the link python->python2.7 and replace with an alternative appraouch. Before making the switch, I would like to review the packages that could be broken, so I looked at all packages, not in "python*-*" form, that pull one of the "python", "python2" and "python27" using $ cygcheck-dep -O -S -q -n python.. as base. There are almost 200 binary packages (of the almost 9000 currently present on 64 bit) The list with source package and maintainer is here: https://drive.google.com/file/d/1xaPzIZ78JzHtJXcdzB77qJoeNlvVQRJq/view?usp=sharing I know that Mercurial need rebuild, and I assume the same for subversion (that I plan to adopt). Could you please check your packages if they will work with preferred python3.8 ? Texlive and fontforge seem the most urgent, IMHO, for a verification. I think TeX Live should be fine. All of the python scripts provided by the texlive-collection-* packages are identical across platforms, so any python3 incompatibilities would almost certainly have been reported and fixed by now. I think all I have to do is rebuild the collections that contain python scripts to make sure I pick up the latest versions of the upstream packages, and also to let cygport update the dependencies. I can do that quickly as soon as cygport is ready for the new system. My other package listed in your spreadsheet, bzr-fastimport, is of very low priority. It can be dealt with when and if bzr is updated. Since there hasn't been an upstream bzr release in 5 years, updating bzr might simply be a matter of changing the shebang in /usr/bin/bzr to specify python2. But that's up to Jari. Ken
Re: GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]
On 1/16/2021 3:33 PM, Adam Dinwoodie wrote:
On Sat, 16 Jan 2021 at 20:22, Adam Dinwoodie wrote:
Version 0.65-1 of moreutils has been uploaded and should be coming
soon to a distribution server near you.
In case anyone's interested or has thoughts:
As part of working on this release, I've been playing with GitHub's
automation tools. The entire build / test / package / release / upload
process was performed using free ephemeral GitHub-managed VMs. At
least in theory, this reduces the manual work for future releases to:
- Commit a version of the Cygport file with an updated version number.
- Create a tag and push that tag to GitHub
- Wait for the confirmation email to arrive
- Send the announcement email
This is obviously serving a similar purpose to the automated builds
that Scallywag provides; I'm not sure I'd have bothered with this
project had I not already been most of the way through it before I
spotted Scallywag existed. I suspect in theory Scallywag's access to
the Cygwin servers means it's potentially more powerful, but Scallywag
also comes with some general caveats ("at this stage, this is only
probably useful for verifying that BUILD_REQUIRES is correct"),
I assume you're quoting from https://cygwin.com/packaging/build.html. Scallywag
does have some limitations currently, but I think the statement you quoted is
obsolete. I often have Scallywag deploy my packages, as does Jon Turney.
The limitations I've bumped into are:
1. Scallywag will time out after an hour on each arch.
2. Several of my packages fail to build on x86 because of gcc crashes.
I think these limitations are outweighed by the fact that a Scallywag build is
automatically triggered by a push to an official source repo
(https://cygwin.com/packaging/repos.html). All maintainers can use this without
any special setup.
Ken
Re: [ITA] libnice-0.1.18-1
On 1/14/2021 10:11 AM, Ken Brown via Cygwin-apps wrote: On 1/14/2021 1:41 AM, Marco Atzeri via Cygwin-apps wrote: On 14.01.2021 03:53, Ken Brown via Cygwin-apps wrote: On 1/10/2021 8:36 AM, Lemures Lemniscati via Cygwin-apps wrote: On Sun, 10 Jan 2021 12:46:43 +0100, Marco Atzeri via Cygwin-apps On 10.01.2021 01:07, Lemures Lemniscati via Cygwin-apps wrote: Building on my system I found that gobject-introspection will need a rebuild for python3. Although I'm not sure... We might need to rebuild gobject-introspection, as Marco said, and python*-mako also. I am uploading python*mako as test I will also try to rebuild gobject-introspection I've just pushed an update for python 3.8 to the playground branch at https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gobject-introspection.git That should be a good starting point for you. I can do a non-maintainer upload of gobject-introspection, rebuilt for python3, to see if that helps. I'm in the process of testing the build on Scallywag at the moment. I'm using python37 because of the mako requirement. I'd prefer to upgrade gobject-introspection to a more recent release rather than just rebuilding the current release. But, unfortunately, a more recent gobject-introspection would require a more recent glib2.0. I'm not sure it's a good idea to update glib2.0 without updating all of GNOME. I tried to start a discussion about this last May, but it didn't get very far: I will try the current version as first. A further upgrade seems to need a major patch effort. I played with gobject-introspection-1.64.1 last summer and updated the patches. If you're curious, you can find what I did in the 1.64 branch at the same source repo that I cited above. But in order to build it, I had to build and install an updated glib2.0, since it required glib2.0 >= 2.58.0. (I also used pip to install python-markdown, which was a new build requirement.) Maybe I'll take a little time right now to push my glib2.0 work in case someone braver than I am wants to pick this up. This is now on the playground branch at https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/glib2.0.git Ken
Re: [ITA] libnice-0.1.18-1
On 1/14/2021 1:41 AM, Marco Atzeri via Cygwin-apps wrote: On 14.01.2021 03:53, Ken Brown via Cygwin-apps wrote: On 1/10/2021 8:36 AM, Lemures Lemniscati via Cygwin-apps wrote: On Sun, 10 Jan 2021 12:46:43 +0100, Marco Atzeri via Cygwin-apps On 10.01.2021 01:07, Lemures Lemniscati via Cygwin-apps wrote: Building on my system I found that gobject-introspection will need a rebuild for python3. Although I'm not sure... We might need to rebuild gobject-introspection, as Marco said, and python*-mako also. I am uploading python*mako as test I will also try to rebuild gobject-introspection I've just pushed an update for python 3.8 to the playground branch at https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gobject-introspection.git That should be a good starting point for you. I can do a non-maintainer upload of gobject-introspection, rebuilt for python3, to see if that helps. I'm in the process of testing the build on Scallywag at the moment. I'm using python37 because of the mako requirement. I'd prefer to upgrade gobject-introspection to a more recent release rather than just rebuilding the current release. But, unfortunately, a more recent gobject-introspection would require a more recent glib2.0. I'm not sure it's a good idea to update glib2.0 without updating all of GNOME. I tried to start a discussion about this last May, but it didn't get very far: I will try the current version as first. A further upgrade seems to need a major patch effort. I played with gobject-introspection-1.64.1 last summer and updated the patches. If you're curious, you can find what I did in the 1.64 branch at the same source repo that I cited above. But in order to build it, I had to build and install an updated glib2.0, since it required glib2.0 >= 2.58.0. (I also used pip to install python-markdown, which was a new build requirement.) Maybe I'll take a little time right now to push my glib2.0 work in case someone braver than I am wants to pick this up. I'm afraid to do it for the reason Achim gave in his recent email in this thread. Ken
Re: [ITA] libnice-0.1.18-1
On 1/10/2021 8:36 AM, Lemures Lemniscati via Cygwin-apps wrote:
On Sun, 10 Jan 2021 12:46:43 +0100, Marco Atzeri via Cygwin-apps
On 10.01.2021 01:07, Lemures Lemniscati via Cygwin-apps wrote:
Building on my system I found that gobject-introspection will need
a rebuild for python3.
/usr/bin/meson --internal exe --unpickle
/pub/tmp/libnice-0.1.18-1.src/libnice-0.1.18-1.x86_64/src/libnice-0.1.18/x86_64-pc-cygwin/meson-private/meson_exe_g-ir-scanner_2092638958d73a5ee2a2021f7aa8d2c979f4fd4e.dat
On Sun, 10 Jan 2021 13:09:13 +0100, Achim Gratz
Lemures Lemniscati via Cygwin-apps writes:
* On x86, it failed to build.
There's a SEGV killing gcc somewhere in the buils, but I am not sure
where. Is it possible to serialize the build and see if that's
reproducible still?
Thank you, Marco and Achim for review.
Failures are at same points as Marco's
* The first build:
https://ci.appveyor.com/project/cygwin/scallywag/builds/37187728/job/52dy26ao9sv0bedk#L924
[71/150] /usr/bin/meson --internal exe --unpickle
/cygdrive/c/projects/playground/libnice-0.1.18-1.i686/src/libnice-0.1.18/i686-pc-cygwin/meson-private/meson_exe_g-ir-scanner_cb3ca9af3f8a35f0ba5f42f29b14b723f34faffb.dat
FAILED: nice/Nice-0.1.gir
* A serialized build by the following src_compile():
```
src_compile() {
cygmeson ${@}
cygninja -C ${CHOST} -j 1
}
```
https://ci.appveyor.com/project/cygwin/scallywag/builds/37191342/job/ldm5c0kigtj6tuxy#L916
[65/150] /usr/bin/meson --internal exe --unpickle
/cygdrive/c/projects/playground/libnice-0.1.18-1.i686/src/libnice-0.1.18/i686-pc-cygwin/meson-private/meson_exe_g-ir-scanner_cb3ca9af3f8a35f0ba5f42f29b14b723f34faffb.dat
FAILED: nice/Nice-0.1.gir
And, I noticed that my /usr/bin/python is 2.7.18 (both of x86_64 and i686)...
Situations are:
* g-ir-scanner is contained in a package gobject-introspection.
* gobject-introspection requires python27, python27-mako
(cf. https://www.cygwin.com/packages/summary/gobject-introspection.html ).
* Packages python27-mako, python3-mako, python36-mako, python37-mako exists,
but python38-mako don't at present.
(cf. https://www.cygwin.com/packages/summary/python-mako-src.html )
Although I'm not sure...
We might need to rebuild gobject-introspection, as Marco said,
and python*-mako also.
I can do a non-maintainer upload of gobject-introspection, rebuilt for python3,
to see if that helps. I'm in the process of testing the build on Scallywag at
the moment. I'm using python37 because of the mako requirement.
I'd prefer to upgrade gobject-introspection to a more recent release rather than
just rebuilding the current release. But, unfortunately, a more recent
gobject-introspection would require a more recent glib2.0. I'm not sure it's a
good idea to update glib2.0 without updating all of GNOME. I tried to start a
discussion about this last May, but it didn't get very far:
https://cygwin.com/pipermail/cygwin-apps/2020-May/040105.html
Ken
Re: perl 5.32
On 1/10/2021 7:42 AM, Achim Gratz wrote: Achim Gratz writes: The Perl 5.32 test repository is now up at: root=http://cygwin.stromeko.net/ $root/perl-5.32 Additionally the perl-5.32-RC1 is now available in this repo as a test package (perl-5.32.1-0.1). The distributions are all unchanged. I installed it on my test installation and rebuilt biber. No problems. Ken
Re: Moving from python2 to python3
On 12/30/2020 9:10 AM, ASSI wrote: Marco Atzeri via Cygwin-apps writes: it seems the appveyor is not running the postinstall scripts It does run all the other ones, though… so there's something amiss with the logic that triggers that script. python38-3.8.3-1 is missing its postinstall script. All I see is a cygport-generated /etc/postinstall/python38.sh, packaged with idle38-3.8.3-1. Ken
Re: Moving from python2 to python3
On 12/29/2020 7:04 AM, Achim Gratz wrote:
Marco Atzeri via Cygwin-apps writes:
all python packages have been updated.
/usr/bin/python
/usr/bin/python3
both point now to python3.8 as default using alternatives.
You broke the CI:
Traceback (most recent call last):
File "./scallywag", line 69, in
response = urllib.request.urlopen(req, json.dumps(data).encode('utf-8'))
File "/usr/lib/python3.8/urllib/request.py", line 222, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib/python3.8/urllib/request.py", line 525, in open
response = self._open(req, data)
File "/usr/lib/python3.8/urllib/request.py", line 542, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
File "/usr/lib/python3.8/urllib/request.py", line 502, in _call_chain
result = func(*args)
File "/usr/lib/python3.8/urllib/request.py", line 1379, in http_open
return self.do_open(http.client.HTTPConnection, req)
File "/usr/lib/python3.8/urllib/request.py", line 1350, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
File "/usr/lib/python3.8/http/client.py", line 1255, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/usr/lib/python3.8/http/client.py", line 1301, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/usr/lib/python3.8/http/client.py", line 1250, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/lib/python3.8/http/client.py", line 1010, in _send_output
self.send(msg)
File "/usr/lib/python3.8/http/client.py", line 950, in send
self.connect()
File "/usr/lib/python3.8/http/client.py", line 923, in connect
self.sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
AttributeError: module 'socket' has no attribute 'TCP_NODELAY'
An internet search led me to this:
https://bugs.python.org/issue41374
As explained in that report, the TCP_* macros weren't defined in the build of
python on Cygwin because was not included (see
https://github.com/python/cpython/blob/592527f3ee59616eca2bd1da771f7c14cee808d5/Modules/socketmodule.h#L11).
Is that still the case in the current python sources?
Ken
Re: perl 5.32
On 12/27/2020 1:41 AM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: The Perl 5.32 test repository is now up at: root=http://cygwin.stromeko.net/ $root/perl-5.32 including all Perl distributions that I maintain or co-maintain. Thanks very much! It worked fine for building biber. Did you encounter any problems with setup, provided you started with an installation that already has the 5.30 Perl installed? Since I use my own local repository and setup.ini that only contains the packages I am going to install I can't really test that scenario, although I noticed that "Sync" does produce a very strange solution the first time around and I have to cycle through "Keep" and "Best" for it to settle on just upgrading Perl and not removing half of the rest of the system. I used a test installation that had 5.30 installed but didn't have all the Perl distributions that I needed for building Biber. I never had occasion to use "Sync"; I just installed missing packages. Sometimes I ran setup with your repo in addition to a regular mirror, and sometimes just with yours. I ran it several times until I had everything I needed. The only small glitch that I encountered was when upgrading perl-Algorithm-Diff. The version in your test repo was 1.201 instead of 1.2010, so setup didn't recognize it as being newer than the installed version (1.9xxx). Ken
Re: perl 5.32
On 12/26/2020 12:43 PM, Achim Gratz wrote: Achim Gratz writes: Achim Gratz writes: I've cleaned up the patches so they still apply on top of 5.32.0 where applicable and built the initial packages. For the rest I'll have to set up one of my old build machines as I don't want to move my main build box from the official state (which would mean I could no longer update other packages). I ended up creating a completely new build environment and staging repository on that machine. I have completed the stage-1 bootstrap, when I have reviewed the build logs for (new) errors I'll start the stage-2 bootstrap. That'll take about a bit on that machine, but I should get a repo that I can upload for your tests out of it. The Perl 5.32 test repository is now up at: root=http://cygwin.stromeko.net/ $root/perl-5.32 including all Perl distributions that I maintain or co-maintain. This is purely for initial testing of the 5.32 mainline, there is no intention of releasing this version of Perl on Cygwin. Once the first maintenance update becomes available in January (if everything comes together as planned), I'll just start over. I'll also just replace any packages in the repo when I have to rework them for whatever reason. Therefore, don't expect to be able to update installations with these packages installed without manual intervention. I recommend to use either a throwaway installation or having a full backup of the original installation. Thanks very much! It worked fine for building biber. Ken
