upload to calm: should curr-2 be vaulted while still in setup.ini?
Hi folks, After upload, noticed in calm deployment log that release current - 2 is being vaulted, but it's still showing in setup.ini. If current - 2 is selected in setup, won't this cause setup to fail, as as it will no longer be available under release/, nor propagated on mirrors? INFO: adding 1 package(s) for arch x86_64 > INFO: move from Brian Inglis's upload area to release area:> INFO: deploying x86_64/release/cpuid/cpuid-20221003-1-src.hint> INFO: deploying x86_64/release/cpuid/cpuid-20221003-1-src.tar.xz> INFO: deploying x86_64/release/cpuid/cpuid-20221003-1.hint> INFO: deploying x86_64/release/cpuid/cpuid-20221003-1.tar.xz> INFO: vaulting 1 old package(s) for arch x86_64> INFO: move from release area to vault:> INFO: vaulting x86_64/release/cpuid/cpuid-20220812-1-src.hint> INFO: vaulting x86_64/release/cpuid/cpuid-20220812-1-src.tar.xz> INFO: vaulting x86_64/release/cpuid/cpuid-20220812-1.hint> INFO: vaulting x86_64/release/cpuid/cpuid-20220812-1.tar.xz> SUMMARY: 12 INFO(s) [prev] version: 20220812-2 install: x86/release/cpuid/cpuid-20220812-2.tar.xz 132096 3eb7f8d86db037c242d7dccbd79b28a4a57771eb08f4e187fd5be124e6b3aff4aa615636e83ed39e6529982869460282b195454914ff6ff573ce2f427b58dcad source: x86/release/cpuid/cpuid-20220812-2-src.tar.xz 139888 e8e958c2f799fdbed04076878f1a2293066f6004dc3754892354f5484bed172e7ae49d0f0043c0a1a4b5ef52a85b803305de136ec5edd71852a3e5dc02d9ac26 depends2: cygwin, perl_base build-depends: binutils, coreutils, cygport, gcc-core, gzip, make, perl, tar -- La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. -- Antoine de Saint-Exupéry
Re: [Bug] setup regression #2
Jon Turney writes: > On 03/10/2022 20:23, Achim Gratz wrote: >> Jon Turney writes: >>> This problem is with files created by setup, or by post-install scripts? >> I think both, although the problematic symlinks were created through >> alternatives. > > That's pretty baffling. Even more baffling is that I have another installation that are completely fine even with their Group now switched to Administrators. The one syxstem where I've had the problems is a server version and might have some GPO that affect thing that an admin user does. > I don't see how any of those commits would change the ownership of > files created by setup itself. The ownership is still with the user that runs the install script, however the group has changed. > The only relevant change seems to be in "Defer setting group until > after All Users/Just For Me is chosen", I've made > nt_sec.resetPrimaryGroup() explicit, but that only happens for > non-admin installs... I think that setup was essentially treating the install as "for this user only" since it was created and maintained by a script that can't affect that option and the fact it was also in group Adminsitroators didn't actually register until now. The DACL on the server install changed from conferring access to "Everyone" to just the install user and SYSTEM IIRC. It doesn't do that on the (non-domain) build machine at home that runs Win10 Pro. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: Scallywag TeX dblatex font requirements dependencies missing
On 10/8/2022 9:04 AM, Jon Turney wrote:
On 30/09/2022 19:25, Brian Inglis wrote:
On 2022-09-30 07:01, Jon Turney wrote:
On 29/09/2022 07:22, Brian Inglis wrote:
Hi folks, [Please Reply All as Cygwin mail blocked by ISP]
Scallywag job failing complaining about TeX fonts.
Any ideas about what extra TeX font dependencies dblatex requires under
gtk-doc building docs for gsasl 2.2 under playground:
https://cygwin.com/cgi-bin2/jobs.cgi?id=4618
https://github.com/cygwin/scallywag/actions/runs/3148865611/jobs/5119913953
Googling the first error message leads me to suggest
texlive-collection-fontsrecommended
Thanks Jon,
I planned to add that and ...extra, but shouldn't presumably required fonts be
TeX/LaTex/dblatex package dependencies, when not mentioned anywhere in
downstream packages, including in build scripts on other systems?
I don't think so. TeX/LaTeX/dblatex can't know what fonts are going to be
required to build documentation for other packages.
How are maintainers and users expected to make the connection, if nobody
mentions you need special "unrelated" font packages, in any of the downstream
packages?
For example, for DbLaTeX, only the Windows install page mentions MikTeX fonts,
and there appears to be no other link between the abstract font specs, the TeX
fonts used, and packages required, although there appear to be mentions of
DejaVu "system" fonts, so do non-TeX font packages also need installed e.g.
dejavu-fonts or urw-base35-fonts{,-legacy}?
Those who are not TeXies need a few more hints.
gsasl should tell you what fonts are required to build its documentation. Since
it apparently doesn't (I haven't checked), you have to go by the error messages.
The first error message I see in the log is
! I can't find file `pzdr'
followed shortly by
...failed to make pzdr.tfm.
Searching Cygwin packages for 'pzdr', you find that pzdr.tfm is in
texlive-collection-fontsrecommended. So you add the latter to BUILD_REQUIRES
and try again. If there are still error messages about missing fonts, repeat
the process.
I don't know any other way to do it.
Ken
Re: [PATCH 2/2] typo: that -> than
On 07/10/2022 18:26, Chad Dougherty wrote: Signed-off-by: Chad Dougherty --- contrib.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib.html b/contrib.html index d5024694..04dc9726 100755 --- a/contrib.html +++ b/contrib.html @@ -132,7 +132,7 @@ in git format-patch format. git format-patch [--cover-letter] -This will produce files with all of your changes newer that origin, +This will produce files with all of your changes newer than origin, making it easy for someone to review and, if you don't have write access, push. Give them a final once-over. Ideally you include a good description of your change with details what it does, how it works, what I applied these, thanks.
Re: [Bug] setup regression #2
On 03/10/2022 20:23, Achim Gratz wrote: Jon Turney writes: This problem is with files created by setup, or by post-install scripts? I think both, although the problematic symlinks were created through alternatives. That's pretty baffling. I don't see how any of those commits would change the ownership of files created by setup itself. The only relevant change seems to be in "Defer setting group until after All Users/Just For Me is chosen", I've made nt_sec.resetPrimaryGroup() explicit, but that only happens for non-admin installs... (I'm not sure how these commits could have caused the former, if the latter then reverting 45d8e84e "Drop group change while running postinstall scripts" would be the thing to try...) As I said, I don't understand it either. It seems my installations were all using the primary group for the account that does the install (which does have administrative rights and is separate from my normal user account on most machines). The primary group is either "None" for the build machine that only uses local accounts and is not a member of any domain or "Domain Users" otherwise. The new code uses "Administrators", but that seems to have the side effect of denying "normal" users access to the installation and instead weaves in extra DACL for SYSTEM. As long as there's an option to force it to keep the former behaviour things should be OK, but I haven't really checked if and how this is possible. Unfortunately, there is no such option.
[ITP] minisign 0.10
Hello, I'm interested in becoming a package maintainer for minisign: https://jedisct1.github.io/minisign/ I suspect the mailing list was blocking my original announcement about this so I have put all of the relevant information in the README here: https://github.com/crd477/cygports/blob/main/minisign/README.md Thanks, and take care... -- -Chad
Re: Cygwin Git repos refusing push
On Sat, 8 Oct 2022 at 14:12, Jon Turney wrote: > > On 04/10/2022 15:02, Adam Dinwoodie wrote: > [...] > >> > >> I've adjusted the gitolite configuration so this should work again. > > > > Would it be possible to add some output to the hooks to provide a useful > > explanation for what's going on? I think anything a hook prints to > > stdout or stderr will be seen by the user in the `git push` output, and > > something a bit more informative than "DENIED" would be nice! > > This is not totally straightforward, as this hook is part of, and > managed by, gitolite. > > > It's not a big issue either way, but having a more informative output in > > this case might have saved me a bit of time trying to ensure the problem > > was genuinely on the server and not just that I was doing something > > daft. > > Do you have a suggestion as to what else the hook should say? Something to the effect of "This server does not permit pushing to any branch other than 'master' or 'playground'" would have made it clearer what was going on, at least for me. But as I say, if it's difficult to do, it's not a big deal!
Re: Cygwin Git repos refusing push
On 04/10/2022 15:02, Adam Dinwoodie wrote: [...] I've adjusted the gitolite configuration so this should work again. Would it be possible to add some output to the hooks to provide a useful explanation for what's going on? I think anything a hook prints to stdout or stderr will be seen by the user in the `git push` output, and something a bit more informative than "DENIED" would be nice! This is not totally straightforward, as this hook is part of, and managed by, gitolite. It's not a big issue either way, but having a more informative output in this case might have saved me a bit of time trying to ensure the problem was genuinely on the server and not just that I was doing something daft. Do you have a suggestion as to what else the hook should say?
Re: Scallywag TeX dblatex font requirements dependencies missing
On 30/09/2022 19:25, Brian Inglis wrote:
On 2022-09-30 07:01, Jon Turney wrote:
On 29/09/2022 07:22, Brian Inglis wrote:
Hi folks, [Please Reply All as Cygwin mail blocked by ISP]
Scallywag job failing complaining about TeX fonts.
Any ideas about what extra TeX font dependencies dblatex requires
under gtk-doc building docs for gsasl 2.2 under playground:
https://cygwin.com/cgi-bin2/jobs.cgi?id=4618
https://github.com/cygwin/scallywag/actions/runs/3148865611/jobs/5119913953
Googling the first error message leads me to suggest
texlive-collection-fontsrecommended
Thanks Jon,
I planned to add that and ...extra, but shouldn't presumably required
fonts be TeX/LaTex/dblatex package dependencies, when not mentioned
anywhere in downstream packages, including in build scripts on other
systems?
How are maintainers and users expected to make the connection, if nobody
mentions you need special "unrelated" font packages, in any of the
downstream packages?
For example, for DbLaTeX, only the Windows install page mentions MikTeX
fonts, and there appears to be no other link between the abstract font
specs, the TeX fonts used, and packages required, although there appear
to be mentions of DejaVu "system" fonts, so do non-TeX font packages
also need installed e.g. dejavu-fonts or urw-base35-fonts{,-legacy}?
Those who are not TeXies need a few more hints.
I don't know.
Maybe Ken has some insight?
Re: libffi: upgrade to libffi-3.4.3 proposed (cygport file attached)
On 04/10/2022 19:11, Hannes Müller wrote: Dear Maintainer(s), libffi is ORPHANED and outdated. Attached a cygport for newest libffi-3.4.3, which needs no extra patches. PS: libffi-3.4.3 is also used on MSYS2 without extra patches. Thanks! Thanks. I'm minded to do a NMU of libffi using your revised cygport, but I notice that many tests fail on x86 (see [1]). Is this expected, or does it indicate some problem there? [1] https://github.com/cygwin/scallywag/actions/runs/3205410540/jobs/5237942271#step:6:2343
