Re: calm not updating master x86_64/sha512.sum after setup updates
On 28/07/2024 00:06, Brian Inglis via Cygwin-apps wrote: Hi folks, After uploading packages, calm does not appear to be updating sha512.sum after updating setup.ini: $ date -ud@`stat -c%Y ~/mirror/x86_64/sha512.sum` 2024 Jul 24 Wed 15:14:03 This is showing up in a script I run a minute or few later to check git/cygwin-packages/repo status, https://cygwin.com/pub/cygwin/x86_64/ timestamps, and download sha512.sum, setup.ini.sig, setup.xz.sig, setup.xz to check whether calm has updated every package as expected, checksums, and signatures, and it is okay to announce, using curl -I and a filter: checking setup status https://cygwin.com/pub/cygwin/x86_64/sha512.sum: last-modified: Wed, 24 Jul 2024 15:14:03 GMT content-length: 1278 checking setup status https://cygwin.com/pub/cygwin/x86_64/setup.ini: last-modified: Sat, 27 Jul 2024 21:56:02 GMT content-length: 18169373 content-type: text/plain; charset=UTF-8 Uh, your expectations aren't well founded here. The sha512.sum files aren't generated by calm, but by another process (which creates/updates them for the entire /var/ftp/pub/ area on sourceware) I wish that calm could update these files but there are some isolation/permissions issues which prevent that currently. (or indeed, better still, have these checksums generated at the package build stage and passed through to setup.ini as an additional check on package integrity),
Re: setup: parameter stickiness
On 21/07/2024 16:21, Thomas Wolff via Cygwin-apps wrote: Hi, if I have two cygwin installations, e.g. C:\cygwin64 and C:\cygwin64test, the setup program is sticky about its root directory, local package directory, and download sites presettings. They tend to stay at the second installation even after updating the first one, so that I have to fix it manually every time I update my main installation (unless I fiddle them out from the registry, or fix them via command-line). Would be good to remember the last-in-use values. That is kind of how it's supposed to work: The last-used root directory is stored in the registry All other settings are read from /etc/setup/setup.rc in the selected Cygwin root directory, if it exists. If that doesn't seem to be what you are seeing, maybe you could give a series of steps to reproduce, clearly stating what behavior you get that is unexpected. You might also find the setup option '--no-write-registry' useful to stop your test installation from writing it's root directory into the registry.
Re: [cygport] Avoid the package's provides appearing in requires
On 30/06/2024 13:02, ASSI via Cygwin-apps wrote: This commit introduces a bug. It will not work for packages that have multiple provides or extra whitespace around the provides name as that will produce a bogus regex for grep. Oh, yeah, that's pretty dumb of me. You can just add any such package or provide names twice at the beginning of the echo invocation, as any package that appears more than once in the resulting output is not recorded as a dependency. Uh, what, really? I can't spot the mechanism in __list_deps which does that, which is certainly worthy of a comment if we're going to rely on it!
Re: [ITP] cmocka required for fortune-mod package update
On 13/07/2024 21:10, Brian Inglis via Cygwin-apps wrote: On 2024-07-13 13:28, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote: ERROR: package 'fortune-mod-src' version '3.22.0-1' build-depends: 'cmocka', but nothing satisfies that ERROR: error while validating merged x86_64 packages for Brian Inglis SUMMARY: 2 ERROR(s) Sorry, I forget to add cmocka to your packages. Done now.
Re: [ITP] cmocka 1.1.7 - C unit testing framework
On 12/07/2024 03:31, Brian Inglis via Cygwin-apps wrote: On 2024-07-10 15:05, Jon Turney wrote: On 10/07/2024 00:35, Brian Inglis via Cygwin-apps wrote: Description: Elegant unit testing framework for C with support for mock objects, derived from Google Cmockery. License: Apache-2.0 I would like to provide a Cygwin package for cmocka, as it is now required for testing my fortune-mod package. For more information see the project home pages: https://cmocka.org It is packaged by major Linux and BSD distros: https://repology.org/project/cmocka/versions There is an error building the docs using doxygen, and that hangs, using either cmake/make or cmake/ninja builds, locally and in GH CI (see previous job 8341 - had to cancel after 3 hours), with current stable and a local build of the latest doxygen release, and an issue has been raised upstream. I suspect this is a problem in cygwin. There is (what sounds like) a similar problem when building libxcb's documentation, in that it gets stuck somewhere in doxygen, waiting for a load of dot.exe processes to finish even after they're all done. I bisected that to working under 3.3.6 and failing under 3.4.0, but there's nothing obviously related in that interval, and I haven't found the time to bisect the commits... Thanks Jon, They agree with that suspicion in doxygen: https://github.com/doxygen/doxygen/issues/10251 Looking at some hints and approaches for doxygen diagnostics and debugging: -DDOXYGEN_DOT_NUM_THREADS=1 Eliminating all other job paramaters, that is the one that switches hangs on and off. When you have time, would you care to retry libxcb docs with that CYGCMAKE_ARGS or equivalent? I can see if upstream can help us narrow the code down to a simple STC for us, or should we loop in, or punt to, Ken as maintainer? ;^> I think the most productive investigation at this stage would be to confirm my observation of the range of commits in cygwin which introduces the regression, and try to bisect that (Due to version skew, you'd probably have to hop in your time machine to make an installation using 3.3.4, then use that to build and test intermediate versions)
Re: [ITP] cmocka 1.1.7 - C unit testing framework
On 10/07/2024 00:35, Brian Inglis via Cygwin-apps wrote: Description: Elegant unit testing framework for C with support for mock objects, derived from Google Cmockery. License: Apache-2.0 I would like to provide a Cygwin package for cmocka, as it is now required for testing my fortune-mod package. For more information see the project home pages: https://cmocka.org It is packaged by major Linux and BSD distros: https://repology.org/project/cmocka/versions There is an error building the docs using doxygen, and that hangs, using either cmake/make or cmake/ninja builds, locally and in GH CI (see previous job 8341 - had to cancel after 3 hours), with current stable and a local build of the latest doxygen release, and an issue has been raised upstream. I suspect this is a problem in cygwin. There is (what sounds like) a similar problem when building libxcb's documentation, in that it gets stuck somewhere in doxygen, waiting for a load of dot.exe processes to finish even after they're all done. I bisected that to working under 3.3.6 and failing under 3.4.0, but there's nothing obviously related in that interval, and I haven't found the time to bisect the commits... For now, there is little justification to split into dll (40KB 1 file), devel (100KB 8 files 2 dirs), doc (24KB 4 files 1 dir) packages, unless for conformity, but can revisit if I can get docs built! Since the DLL has a soversion number, not placing it in a separate package seems contraindicated. (I take the point that we're *probably* not going to be packaging anything linked against is, but gratuitously breaking user-built executables linked against it if the soversion ever changes seems a bit mean... I guess maybe if we really think that's the only use-case, we should only build it as a static library?)
Re: [ITP] lesspipe 2.13 - less pager input file preprocessor
On 26/06/2024 05:49, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 14:12, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 08:01, Jon Turney via Cygwin-apps wrote: On 15/06/2024 16:11, Brian Inglis via Cygwin-apps wrote: [...] Hi folks/Jon, Inadvertently uploaded test instead of prod build of lesspipe. Running untest promoted it from test to (only) current stable. But package source and summary web pages still show the release as in test. Looks like untest action should force a rebuild of the package source and summary web pages. "should" but "does not" currently...
Re: package upload calm error
On 29/06/2024 10:33, Thomas Wolff via Cygwin-apps wrote: Hi, I had uploaded mintty 3.7.3 with the following added to setup.hint: curr: 3.7.3 prev: 3.7.1 This used to be the way to replace and skip the current version but calm fails on it. This used to work when all versions shared a single hint file, and new versions trampled all over previous versions, but we haven't done that for a while (because it was nuts...) What's the way now? The easiest way is: i) Remove the 3.7.2 version by following the instructions at [1], e.g. 'ssh cyg...@cygwin.com vault mintty-3.7.2-1' ii) Upload 3.7.3 [1] https://cygwin.com/package-upload.html#deleting I did this for you.
Re: [ITP] python-license-expression and cygport PoC patch
On 06/06/2024 20:03, Brian Inglis via Cygwin-apps wrote: I found github/nexB/license-expression Python package to do SPDX licence checks developed by the same team doing SPDX-toolkit for SPDX, using the same current data, by and working with Fedora folks et al. Thanks for taking a look at this problem. Having a package for this seems fine, but: this package is what calm uses, and still has the drawbacks I mentioned: * embeds the SPDX license data, doesn't dynamically fetch it * can't really handle LicenseRef reasonably Successful attempt to package Python license-expression (without tests): https://cygwin.com/cgi-bin2/jobs.cgi?id=8210 log at: https://github.com/cygwin/scallywag/actions/runs/9293093201 cygport attached and at: https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a The package installs and runs using PoC attached in spdx-license-expression.py script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition patch attached. I'm not super-keen on adding a cygport dependency on python, just to do this check. It would probably be preferable to do this check initially after the .cygport is read, rather than only telling you about problems when you get around to doing to the package step. I also ran a test of the Python script and module against all package source cygport files declaring licences which I maintain or ever looked at, including a git/cygwin-packages/*.cygport download from 2023-02, showing the results in the attached log. I also attempted to trap the exceptions in the script, but that does not seem to work in any documented obvious manner, but I do not know enough Python to address this fully. Yeah, the way validate() handles parse errors is bizarre and unhelpful. What I ended up doing is calling parse() first to catch those errors, so something like: try: licensing.parse(expression) errs = licensing.validate(expression).errors except (ExpressionError, ExpressionParseError) as e: print(e, file=sys.stderr) return 2 If someone else who knows python cared to adopt and improve this in a more normal manner, and incorporate this more smoothly into cygport, we could all appreciate that. Alternatively, some candid comments and frank feedback might allow me to do so! ;^>
Re: [ITP] lesspipe 2.13 - less pager input file preprocessor
On 15/06/2024 16:11, Brian Inglis via Cygwin-apps wrote:
[Forgot attachments]
On 2024-06-14 23:22, Brian Inglis via Cygwin-apps wrote:
I would like to provide a Cygwin package for lesspipe, to automatically
show archive contents or information about many file types, with
enhanced or coloured output, without having to remember which filter
commands are required to do so, as I have been using it for many years.
Thanks, I added this to your packages.
src_compile() {
cd $S
# cygautoreconf
What value does this comment have?
lndirs
cd $B
# cygconf
Ditto.
./configure --prefix=/usr
cygmake
}
src_install() {
cd $B
# install -D "${srcdir}"/lesspipe.sh "${pkgdir}"/etc/profile.d/lesspipe.sh
# verbose cp lesspipe.sh $C/profile.d.sh
# In bash, please preload the completion, dynamic invocation does not work
# . /usr/share/bash-completion/less_completion
# Or consider installing the file less_completion in /etc/bashcompletion.d [sic]
dodir /etc/bash_completion.d
insinto /etc/bash_completion.d
doins less_completion
cyginstall
verbose rm -f $D/usr/share/bash-completion/less_completion
It seems like this might be more clearly sequenced:
* do standard install
* comment about the following steps
* remove completion file from non-working location
* install completion file in working location
or could the completion file just be moved post-install, from ${D}
/usr/share/bash-completion/ to ${D}/etc/bash_completion.d/ ?
}
Re: [ITA] esound
On 20/06/2024 04:37, Takashi Yano via Cygwin-apps wrote: esound itself has not been changed, however, pulseaudio package dropped pluseaudio-esound-compat in 15.0 and later. Therefore, I would like esd (daemon) to comeback in esound package. Thanks. I added this to your packages.
Re: [ITA] ctags 6.1.0 - programming language source indexing and cross-reference tool
On 15/06/2024 16:10, Brian Inglis via Cygwin-apps wrote:
[Forgot attachments]
On 2024-06-14 23:20, Brian Inglis via Cygwin-apps wrote:
I would like to adopt ctags and update it to successor universal-ctags.
Thanks. I added this to your packages.
Description:
Generates an index (tag) file of language objects found in
source files.
The index makes it easy for text editors or other utilities to locate
the indexed items.
Ctags can also generate a cross reference file which lists information
about the various objects found in a set of language files in human
readable form.
Exuberant Ctags improves on ctags because it can find all types of
This should say "universal-ctags", right?
language tags, including macro definitions, enumerated values (values
inside enum{...}), function and method definitions, enum/struct/union
tags, external function prototypes, typedef names and variable
declarations.
Exuberant Ctags is far less likely to be fooled by code containing
preprocessor conditional constructs than ctags.
Exuberant ctags supports output of Emacs style TAGS files and can be
used to print out a list of selected objects found in source files.
Install ctags if you are going to use your system for C programming.
Re: Up for adoption: ctags and expat
On 17/06/2024 07:28, Frank Fesevur wrote: Hi Jon, Thanks for contacting me. I'm sorry to say, but I haven't used Cygwin for years on my own pc,. So I am not gonna make any packages anymore. It could very well be that my SSH key has expired. If not, I don't mind if it would be deleted. No problem. Thanks for letting me know. I will orphan your 'ctags' and 'shutdown' packages.
Re: Fwd: Howto request an upgrade for keychain package
On 24/04/2024 16:34, Jon Turney via Cygwin-apps wrote: Hi Jari, There do seem to be some incompatibilities between our current keychain package and current gpg/gpg2. Is it possible to get an update of keychain? Or let me know if you want to orphan that package. TIA. Hi Jari, In the absence of any response from you, I did an NMU using the cygport provided by another user asking for an update [1]. If that's not what you wanted to happen, or if you want to orphan this package, please let me know. [1] https://cygwin.com/pipermail/cygwin/2024-May/255982.html
Re: [ITP] dav1d
On 07/06/2024 07:22, Takashi Yano via Cygwin-apps wrote: dav1d is a decoder for AV1 video codec, which is faster as twice as libaom. This package is available also for fedora. https://src.fedoraproject.org/rpms/dav1d I'am planning to release ffmpeg where dav1d is enabled as fedora. Thanks in advance. Looks good. I added this to your packages. Thanks.
Re: Up for adoption: ctags and expat
On 12/08/2016 20:41, Corinna Vinschen wrote: On Aug 12 11:57, Warren Young wrote: On Aug 12, 2016, at 7:57 AM, Corinna Vinschen wrote: Cool! If you want to take over ctags and test universal ctags for Cygwin, feel free if Warren agrees. I'll change over maintainership then. Warren, does that sound good to you? Doug, I hope you don't feel overlooked. Expat is still yours if Warren has no problems with that. Sounds like a plan. I added Frank as ctags maintainer to cygwin-pkg-maint but didn't remove you for the time being until the move over is complete. I've been looking for maintainer ssh keys which have been unused for a very long time, with a view to disabling them. One of the keys identified was for Warren Young. Looking at this piece of history, I guess I should remove Warren as a maintainer, and his ssh key. Frank, It looks like we never got a universal-ctags package, so I'm not sure what the status of exuberant-ctags maintainer-ship is...
Re: newer version of mingw64-*-win-iconv ?
On 04/06/2024 00:14, Brian Inglis via Cygwin-apps wrote: On 2024-06-03 13:27, Jon Turney via Cygwin-apps wrote: On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote: On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote: On 29/05/2024 07:58, Brian Inglis via Cygwin wrote: [...] Could someone please do any further tweaks for this source git if required, and do NMU builds and deploys of these? I've given you NMU privileges, so now that someone can be you! Thanks Jon, [...] No previous debuginfo packages exist - are these not useful with cross builds? I suspect that maybe the previous package is so old we didn't have automatic debuginfo generation when it was built...
Re: newer version of mingw64-*-win-iconv ?
On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote: On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote: On 29/05/2024 07:58, Brian Inglis via Cygwin wrote: [...] Could someone please do any further tweaks for this source git if required, and do NMU builds and deploys of these? I've given you NMU privileges, so now that someone can be you! Thanks Jon, I think and hope! ;^> I uploaded both arch packages and have not heard anything from calm about mingw64-i686-win-iconv but did get a non-maintainer complaint about: From: cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org To: Brian Inglis ... Reply-To: cygwin-apps-rdbxbdvo6bxqt0dzr+a...@public.gmane.org Subject: calm: cygwin package report for Brian Inglis X-Calm-Report: 1 Message-Id: <171738805632.3596610.16241297892116907567-vpjudf68pyp0lzk1ysf9sd64mghar...@public.gmane.org> Date: Mon, 03 Jun 2024 04:14:16 - X-Calm: 1 ... WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for maintainer 'Brian Inglis' WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for maintainer 'Brian Inglis' SUMMARY: 2 WARNING(s) and there is not yet any sign of either being applied to the master setup.ini at cygwin.com, which is my other confirmation that an announcement would be appropriate, without waiting for mirror updates. So is there anything more I have to or can do for these? Do I have to add some kind of NMU flag for the packages somehow? No, that's just me being distracted and forgetting to restart the thing so it re-reads the list. Sorry about that. Hopefully working now.
Re: newer version of mingw64-*-win-iconv ?
On 29/05/2024 07:58, Brian Inglis via Cygwin wrote: On 2024-05-28 19:12, Bruno Haible via Cygwin wrote: It would be useful if someone could rebuild the two packages https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html based off the current git HEAD [1]. Reason: The current git HEAD is a reasonable alternative to GNU libiconv; all encodings that it supports, other than EUC-JP and GB18030, have reasonably good conversion tables. Wherease the current Cygwin packages are based off source code from 2013 and have a major problem already with the ASCII encoding. [1] https://github.com/win-iconv/win-iconv Ran playground local and CI builds of these packages at v0.0.8 successfully: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding? Could someone please do any further tweaks for this source git if required, and do NMU builds and deploys of these? I've given you NMU privileges, so now that someone can be you! [Are we really still building 32 bit mingw packages when we dropped support of 32 bit Windows << 1%? There's a difference between "we don't support running on 32-bit Windows" and "We don't support cross-compiling to 32-bit Windows". Now, I'd like to do this in an evidence based manner e.g. if we had some statistics on packages that cygwin users choose to install, and hardly anyone was bothering with mingw 32-bit packages, then dropping them would be a good way of conserving our very limited maintainer resource. But as previously observed, that depends on building something to collect that data, which SHTDI. (There's also some unfinished work by Yaakov in a branch of the cygport repo which enhances cross-compile support, so that a single source package can produce mingw-cross install packages for multiple architectures, which would make it easier to continue to support these packages, and/or drop them in future, and/or add mingw arm64 cross-packages when the toolchain for them exists...)
Re: libtool can't build shared library unless -no-undefined specified
On 21/05/2024 17:22, Brian Inglis via Cygwin-apps wrote: [...] Note that because this flag doesn't do anything for non-PE targets, it's (a) always safe to upstream, and (b) doesn't actually prevent development from unwittingly introducing unresolved symbols. In that case, could we ask Bruno to add into gnulib somewhere appropriate? This doesn't seem like a solution. There's lots of stuff which uses libtool which doesn't use gnulib. There might be stuff which uses gnulib, but which does platform-specific gymnastics (i.e. has unresolved symbols on ELF platforms, but not on PE, or really, genuinely only wants a static library on PE). All of which is to say, there is no "one size fits all" solution, individual projects need to decide how to handle this point, otherwise we'd (hopefully) be using it... (which is not to say that the default could probably have been chosen to be less hassle) This should probably be mentioned in the FAQ item on PE linkage peculiarities. In libtool info? I meant in https://cygwin.com/faq.html#faq.programming.linker, which touches on the issue, but doesn't go into libtool specifics currently. (But looking at this again, the question would need adding to, also)
Re: [PATCH cygport] bin/cygport.in: Allow `-fdebug-prefix-map` to be selected instead of `-ffile-prefix-map`
On 25/05/2024 08:25, Daisuke Fujimura via Cygwin-apps wrote: Having seen this commit ( https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=commit;h=9e82685e32f6717675e9f6bf55dd1336e3fc3831 ), I understand that this is problematic from a reproducibility point of view, but I would like to be able to specify a `-fdebug-prefix-map` because C sources with code like `#include __FILE__` cannot be compiled. https://github.com/cygwin/scallywag/actions/runs/9002845391/job/24732313857#step:6:1302 ``` /cygdrive/d/a/scallywag/ruby/ruby-3.3.1-1.x86_64/src/ruby-3.3.1/debug_counter.h:359:10: fatal error: /usr/src/debug/ruby-3.3.1-1/debug_counter.h: No such file or directory 359 | #include __FILE__ | ^~~~ compilation terminated. ``` The patch is as follows. Thanks very much for the patch. Yeah, I tripped over this when I was testing your previous patch. This seems like a generic problem which everyone is going to have with ruby, though. And from a brief look at the debug_counter.h header, it does seem like a case of excessive cleverness - on first glance, it looks like this could just be written using a separate header, rather than recursively including itself with some define set... (and I guess it's actually a gcc bug, or at least misfeature, that you can make '#include __FILE__' do something other than it's plain meaning) Nevertheless, I guess this is needed. Shell variable names in the patch should be changed to appropriate ones. Yeah, not sure what a good name for this is. Something like 'DEBUGINFO_ONLY_DEBUG_PREFIX_MAP', maybe? It needs to be mentioned in the documentation somewhere, as well.
Re: calm: SPDX licence list data update please
On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote: Hi folks, Can we please get the SPDX licence list data updated in calm to 3.24 sometime if possible as the licences complained about below have been in I thought I wrote about this the last time you asked, but obviously not. This is not quite straightforward, as the system python on sourceware is currently python3.6, and the last supported nexB/license-expression on that is 30.0.0, and moving to a later one has some wrinkles, since various pieces of interconnected stuff aren't venv'd (yet?). releases for nearly a year since 3.21: [...] If not, perhaps I could be of some help if I knew requirements? So, there aren't any requirements here except "validate the SPDX license expression to detect maintainer mistakes and typos". It looks like using that python module might have been a mistake. I'm not sure why it needs to contain it's own version of the license data, ideally we'd have something that read the official SPDX data (ratelimited to once per day or something. It looks like maybe this would possible to do by feeding our own license list into the module rather than using it's built in one, but one could hope for this to be built in already...) It would also be useful if it could also be taught to accept 'LicenseRef-.*' identifiers. So, suggestions on a different module to use, or patches to make this work better, or cogent arguments why we should just remove this validation are all welcome. You can also now remove the exceptions in calm/fixes.py(licmap): Thanks, will do so.
Re: Package import request from CTM
On 27/05/2024 20:39, Michal Feix via Cygwin-apps wrote: Dear all, as suggested on https://cygwin.com/packaging/repos.html let me kindly ask for an import of a 'nasm' package history from CTM into GIT repository. Sure, no problem. History is now imported at: https://cygwin.com/cgit/cygwin-packages/nasm/ I've given it a brief look over and it seems reasonable, but please check that it's OK before you start using it.
Re: SSH key update
On 27/05/2024 20:20, Michal Feix via Cygwin-apps wrote: BEGIN SSH2 PUBLIC KEY Comment: "3072-bit RSA, converted by feixm@michal-pc from OpenSSH" B3NzaC1yc2EDAQABAAABgQDjQ9jbOytPr/sPDwIbjtFeJqBuDymxzuicJ8NpIN Osoxkagb0WOLPsSjTgDbftDTCw1QOvCrVP09KvLY76MK8zNIt/97N7w/OmB0iWv9v1LEuT sFAqDlC4jRVMC4pabidTqDZy0nVC54POIwYd4N65k7fxwGGU77OaZeKpKRRYeTekVSSOoc jmesIhl+StI8kkPPIZMNpNfsm7DisPoqwZdxxrpCir8xmOMOwU9Wt7CYS+hDqDXSky067O jn0JVty4utXNv/JzVABmiiEpjnFQSwja0vgrbigOrrycJJuGwv4RiYTK63BHfoKgeX1Wqc pxNsvCw7RYumGGXjhSGBicDTM9X81hxEJpzzKNkWsAbjed1HRZ8DgQmTzQPT/mUUB+hD/r 7NYoxzEDvDV0hYpuk89j+7XnqaAltEIkXy0sYGsWpp8AJGDkSlHJDGxzlQAqmgDXyijJpS xgEUxl4nkj8ArBJaFW2mGZxdCDUqMJbYRh1mAfExc+EK2CrkgmlFk= END SSH2 PUBLIC KEY Name: Michal Feix Updating ssh key for Michal Feix Fingerprint: 3072 SHA256:Ie/gfi0gbgbawKADzR/9W2sroK40405A5UGhogoLB5o no comment (RSA) Done. Thanks.
Re: [ITA] bash-completion/-devel
On 03/05/2024 14:40, Jon Turney via Cygwin-apps wrote: On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote: I would like to co-maintain or adopt and revive the above package, which was adopted by Eric but not updated since Yaakov. Thanks. I added this to your packages. I guess I need to ask eblake if he wants to orphan his packages, since he seems to be no longer active... Excluding co-maintained packages, the list is: $ grep 'Eric Blake' cygwin-pkg-maint | grep -v '/' bashdb Eric Blake cppi Eric Blake cvspsORPHANED (Eric Blake) cvsutils Eric Blake gperfEric Blake libsigsegv Eric Blake sharutilsEric Blake
Re: calm: vaulting ancient unifont
On 06/05/2024 17:46, Brian Inglis via Cygwin-apps wrote: On 2024-05-06 09:27, Jon Turney via Cygwin-apps wrote: [...] Anyhow, double checking that the "right thing" happened here, I notice that 'unifont' obsoletes 'unifont-debuginfo', which seems a bit weird, especially since it contains the expected .dbg files etc. Brian, Are you sure that's right? It appears not! My reasoning was that as unifont-viewer was split out from unifont-fonts, unifont-viewer-debuginfo would be generated, but it appears that is not how that works. Is there any way to make that work, or should I just drop it in the next release, or a new -RELEASE? There's only a single debuginfo package generated for each source package. It's unclear to me that finer granularity would be very useful. unifont-viewer seems to be just a script, anyhow, so wouldn't have any useful debug information. I don't think this is of any great importance, so fixing it in the next release seems fine.
Re: libtool can't build shared library unless -no-undefined specified
On 17/05/2024 05:50, Brian Inglis via Cygwin-apps wrote: On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote: 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 Yeah, building stuff for Cygwin often requires adding this flag in the appropriate places, to say "yes, I really do want a shared library". https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode -no-undefined Declare that output-file does not depend on any libraries other than the ones listed on the command line, i.e., after linking, it will not have unresolved symbols. Some platforms require all symbols in shared libraries to be resolved at library creation (see Inter-library dependencies), and using this parameter allows libtool to assume that this will not happen. Note that because this flag doesn't do anything for non-PE targets, it's (a) always safe to upstream, and (b) doesn't actually prevent development from unwittingly introducing unresolved symbols. This should probably be mentioned in the FAQ item on PE linkage peculiarities.
Re: [ITA] dateutils
On 17/05/2024 06:43, Brian Inglis via Cygwin-apps wrote: Date manipulation utilities [...] I would like to adopt the above orphaned package. Thanks. I added this to your packages. https://cygwin.com/cgit/cygwin-packages/dateutils/tree/dateutils.cygport?h=playground Please cleanup all the commented out detritus. What is the reasoning for changing SRC_URI to point to github? The project homepage still points to bitbucket.org for downloads. "*** Warning: DEPEND is deprecated, use BUILD_REQUIRES instead." Scallywag runs: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=dateutils The single test failure is not reproducible standalone, and appears to be a Windows, Cygwin, or shell environment space limitation, due to running 888 tests on a single command line? Can you share the reasoning that lets your reach that conclusion from: FAIL: tzmap_check_02.ctst The build directory should be available as an artifact which may contain more detailed information on the failure. Have you established that this failure is not a regression?
Re: calm: ncurses untest/vault previous version
On 13/05/2024 17:06, Brian Inglis via Cygwin-apps wrote: On 2024-05-13 09:32, Jon Turney via Cygwin-apps wrote: On 13/05/2024 06:25, Brian Inglis via Cygwin-apps wrote: Hi folks, Looks like after untest ncurses-6.5+20240427-1 calm decided the previous version in the recommended format 6.4+20240330-1 was older than prev: 6.4-20231230 So, this would be a bug, if that's actually what happened, because 6.4+20240330 is definitely greater than 6.4 (under the "if all comparison chunks are equal, the string with any suffix remaining is the greater" clause of the comparison rule). What actually seems to have happened is that 6.4+20240330 was still marked as 'test', and so removed by the "packages labelled test: are expired when a superseding non-test version exists" logic. Thanks Jon, Missed that focusing on the versions not the labels in setup.ini. (Yeah, calm should probably be a bit more verbose about the reasons why it's vaulting things in the report) I can vault the old versions but could someone please unvault 6.4+20240330-1? Sure, I'll do that. Do you want me to remove the test label from 6.4+20240330, or turn on keep-superseded-test for this package? Sorry, I should have noticed and untest-ed that immediately before 6.5! Please remove test label to unvault as "prev" not test. I've been running with it since released as test, until 6.5, and it is the final 6.4 we made available, in case anyone has issues with 6.5. OK. Done. 6.4-20231230 was vaulted to stay under the count of kept versions.
Re: calm: ncurses untest/vault previous version
On 13/05/2024 06:25, Brian Inglis via Cygwin-apps wrote: Hi folks, Looks like after untest ncurses-6.5+20240427-1 calm decided the previous version in the recommended format 6.4+20240330-1 was older than prev: 6.4-20231230 So, this would be a bug, if that's actually what happened, because 6.4+20240330 is definitely greater than 6.4 (under the "if all comparison chunks are equal, the string with any suffix remaining is the greater" clause of the comparison rule). What actually seems to have happened is that 6.4+20240330 was still marked as 'test', and so removed by the "packages labelled test: are expired when a superseding non-test version exists" logic. (Yeah, calm should probably be a bit more verbose about the reasons why it's vaulting things in the report) I can vault the old versions but could someone please unvault 6.4+20240330-1? Sure, I'll do that. Do you want me to remove the test label from 6.4+20240330, or turn on keep-superseded-test for this package?
Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages
On 01/05/2024 17:48, Brian Inglis via Cygwin-apps wrote: On 2024-04-30 23:32, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: Some package upstreams offer only checksums, for example .sha512sum, .sha256sum, for verification rather than gpg signatures, for example .asc, .sig, .sign, etc; use these checksum files when provided in a similar manner to gpg signatures; these files are often provided with fixed names which may be renamed on download to unique values using cygport URI fragment support like #/$NAME-VERSION.sha...sum; use coreutils cksum as it supports all modern and legacy checksums and formats. https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d Two similar independent implementations mean it would be a good idea to add the feature! Mine preferred cksum as being the most general approach, while not worrying or knowing too much about ancient sums, although your implementation is better, that is, works properly on those. Mine also preferred sha*sum file types, while still allowing prefixes only without sum, not enumerating them all in the unpack() case, and respecting the cksum crc default. I guess this makes sense as a part of the fetch operation, in thsose cases where upstream provides signatures or checksums. But as briefly discussed in [1], independently of that it would also be a good idea for cygport to specify it's own checksum file, which is incorporated into the source package, and verified at build prep time. (Since this would protect against such screw ups, help with build reproducibility, and defend against supply chain attacks on upstream) [1] https://cygwin.com/pipermail/cygwin-apps/2024-March/043540.html
Re: calm: vaulting ancient unifont
On 04/05/2024 20:21, Brian Inglis via Cygwin-apps wrote: Thanks Jon? - yay! Right, I deployed some changes to calm which will gradually let us get rid of the "old-style" of obsoletion (where, as here, the old name of a package (i.e. font-unifont-misc, font-unifont-ttf) continues to exist with a category of _obsolete and requires: its replacement) (cygport stopped generating these some time ago (0.34.1, 2022), but they've been lingering around indefinitely, because in some cases it's only the existence of these packages which currently records the fact of the obsoletion) Since someone's bound to get the wrong end of the stick: This doesn't mean package maintainers should change anything. And just to reiterate: As a principle, every version of a package must contain complete instructions for upgrading to it. So, it is almost never correct to go "I'll remove these OBSOLETE instruction after one package release with them, since they've already happened everywhere..." On 2024-05-04 09:48, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote: INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz INFO: vaulting x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz INFO: vaulting x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz INFO: vaulting x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz SUMMARY: 8 INFO(s) Anyhow, double checking that the "right thing" happened here, I notice that 'unifont' obsoletes 'unifont-debuginfo', which seems a bit weird, especially since it contains the expected .dbg files etc. Brian, Are you sure that's right?
Re: [PATCH cygport] pkg_info.cygpart: Do not detect dependencies on itself in ruby package
On 03/04/2024 15:18, Daisuke Fujimura via Cygwin-apps wrote:
Thank you for reviewing this.
Can you clarify what the "failure" is here?
[...]
/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)
[...]
Thanks very much for the detailed explanation.
So this is an error (or warning?) generated by invoking the
not-yet-properly installed, just-built ruby in ${D}.
I applied your patch.
On Sun, Mar 10, 2024 at 10:34 PM Jon Turney wrote:
On 16/02/2024 12:51, Daisuke Fujimura via Cygwin-apps wrote:
Attempting to create a package for ruby-3.3, but it fails when trying
to detect a dependency on itself.
Thanks for this patch.
Can you clarify what the "failure" is here?
To avoid this, skip them if the target is `ruby`.
The second hunk seems like a removes the dependency on ruby_xy for the
ruby package, which also provides ruby_xy.
Historically, we've allowed self-dependencies like this, because they
seem to be benign, although it seems like we could do with some generic
code to suppress them
... except I added something to generically prevent a packages provides:
appearing it it's requires:
Re: [ITA] bash-completion/-devel
On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote:
I would like to co-maintain or adopt and revive the above package, which
was adopted by Eric but not updated since Yaakov.
Thanks.
I added this to your packages.
I guess I need to ask eblake if he wants to orphan his packages, since
he seems to be no longer active...
Below are links to existing source packages, build repos, scallywag
runs, and updated package info.
I would like to further improve the sdesc and ldesc provided to reflect
that completions are provided for thousands of commands and their
options and arguments.
Bash Completions and development
Existing source package:
https://cygwin.com/packages/summary/bash-completion-src.html
Updated cygport:
https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground
A few comments:
DEPEND="automake dejagnu make screen" # tcllib
BUILD_REQUIRES="$DEPEND"
Just set BUILD_REQUIRES.
I assume the comment about tcllib means something to someone. :)
src_test() {
cd $B
# For some tests involving non-ASCII filenames
export LANG=C.UTF-8
export -f cygtest
# This stuff borrowed from dejagnu-1.4.4-17 (tests need a terminal)
tmpfile=$(mktemp bash-completion.screen.XX.tmp)
# cygtest
At first glance, because this is commented out, I thought "so this
doesn't run tests at all"
Maybe remove the commented out line, and write a comment saying
something like "run tests under screen, since they need a terminal"
screen -D -m bash -c '( cygtest ; echo $? ) >'$tmpfile
cat $tmpfile
> result=$(tail -n 1 $tmpfile)
This cleverness to propagate the exit code is probably also worthy of
comment, since I had to think about it for a few minutes before I
realized what it was doing...
Perhaps should remove tmpfile here?
return $result
}
Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS
On 28/04/2024 13:21, Christian Franke via Cygwin-apps wrote: ASSI via Cygwin-apps wrote: Christian Franke via Cygwin-apps writes: _FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc 13.2.1 test release. Silently falls back to level 2 if level 3 is unsupported (older headers or gcc) or to level 0 if unsupported at all (C++, clang). Well, if only that was the case… --8<---cut here---start->8--- from /usr/include/w32api/windows.h:9, from /mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/test_utils/test_common.h:88, from /mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/tar/test/test.h:38, from /mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/tar/test/test_extract_tar_lrz.c:25: /usr/include/w32api/_mingw_mac.h:319:8: warning: #warning Using _FORTIFY_SOURCE=2 (level 3 requires __builtin_dynamic_object_size support) [-Wcpp] 319 | # warning Using _FORTIFY_SOURCE=2 (level 3 requires __builtin_dynamic_object_size support) --8<---cut here---end--->8--- Can't we conditiohnalize this to depend on the actual compiler support? This is a bogus warning. Sorry, my bad. In my contribution of _FORTIFY_SOURCE support to MinGW-w64 from 2019, I didn't realize that these warnings also appear if only Win32 API includes (windows.h, ...) are used. The related internal macros have only an effect if MinGW-w64 runtime includes (stdio.h, string.h, ...) are used. Meantime this has been fixed upstream: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/f8e088e I guess that means we need an updated w32api-header package, with this patch added, if it's not yet in a release...
Re: Cygwin - rsync / new release 3.2.7 => 3.3.0
On 29/04/2024 15:10, Jari Aalto wrote: On 2024-04-28 21:41, Chad Dougherty wrote: Hello Jari, On 4/27/24 05:12, Jari Aalto wrote: Hi Chad, you seemed to take care of rsync while I was unavailable. If you still want to maintain rsync, would you update it to latest version. I checked and it compiles ok. ... but you might want to also apply the Debian patches to the latest version It's good to hear from you. I'd be happy for you to resume maintainership of this package if you're willing. I no longer actively use Cygwin so it would make more sense for someone else to do it. Chad, I guess that means that your other packages are orphaned? $ grep 'Chad Dougherty' cygwin-pkg-maint lz4 Chad Dougherty mingw64-i686-lz4 Chad Dougherty mingw64-x86_64-lz4 Chad Dougherty minisign Chad Dougherty passwdqc Chad Dougherty Thanks for your work on these as a maintainer. Thanks Chad, I have the latest ready, so I can continue maintaining. Jon, would someone update the Cygwin Porters file in order to proceed with the upload. Jari, Done. I set your rsync-3.3.0-1 upload to be retried, which seems to have succeeded.
Re: cygport may not create debug info if top directory contains a symlink
On 18/09/2023 18:24, Brian Inglis via Cygwin-apps wrote:
On 2023-09-18 04:41, Christian Franke via Cygwin-apps wrote:
Brian Inglis wrote:
On 2023-09-17 08:01, Jon Turney via Cygwin-apps wrote:
On 16/09/2023 15:17, Christian Franke via Cygwin wrote:
Found during tests of busybox package:
If the path of the top build directory contains a symlink and the
project's build scripts normalize pathnames, no debug info is
created by cygport.
This is because options like
-fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B} contains a symlink but the compiler is
run with the real source path.
[...]
Sidenote: we should probably also be using file-prefix-map, now
we're on a gcc which supports it.
... also macro-prefix-map, although it looks like changing to
-ffile-prefix-map is equivalent to -f*-prefix-map which future proofs
the options!
So I updated to using -ffile-prefix-map in cygport 0.36.8, since that
seems like the "Right Thing(TM)"
I discovered today that, amazingly, this breaks compiling ruby, since in
one place it does:
#include __FILE__
(yeah, that's pretty jaw dropping...)
Re: [PATCH cygport] Add customization support for announce command
On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:
Jon Turney wrote:
On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:
Christian Franke wrote:
The email generated by the cygport announce command is useful, but
actual use cases are somewhat limited due to the hard-coded email
submission.
The attached patch adds more flexibility. The patch is on top of the
"Use correct wording if only one package is announced" patch.
Slightly changed patch attached. Also adjusted to new version of "Use
correct wording if only one package is announced" patch.
[...]
Thanks for this.
Possible (better?) alternative names for the new settings:
ANNOUNCEMENT_EDITOR
ANNOUNCEMENT_MAILER
Hmmm... I think "ANNOUNCE_EDITOR" and "ANNOUNCE_MAILER" would be
the best for clarity and conciseness.
New patch attached. Is still on top of "Use correct wording ..." patch.
I also added HOMEPAGE to the propagated variables as this should be
included in an announcement.
Thanks.
+ /bin/bash -c "cd ${top} || exit 1
+${HOMEPAGE+HOMEPAGE=${HOMEPAGE@Q}}
+P=${P@Q}; PF=${PF@Q}; PN=${PN@Q}; PR=${PR@Q}; PV=(${PV[*]@Q})
+${SMTP_SENDER+SMTP_SENDER=${SMTP_SENDER@Q}}
+${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
+${SMTP_SERVER_PORT+SMTP_SERVER_PORT=${SMTP_SERVER_PORT@Q}}
+${SMTP_ENCRYPTION+SMTP_ENCRYPTION=${SMTP_ENCRYPTION@Q}}
+${SMTP_USER+SMTP_USER=${SMTP_USER@Q}}
+${SMTP_PASS+SMTP_PASS=${SMTP_PASS@Q}}
+${cmd}
+" $0 ${msg} || error "Command '\${${cmdvar}} ${msg}' (cwd=${top})
failed"
+}
Sorry I didn't notice this before, and I am terrible at writing shell,
but perhaps you could share the reasoning behind writing this as above,
and not as, e.g.
(cd ${top} && env BLAH ${cmd})
avoiding all the verbiage in the description of ANNOUNCE_EDITOR about it
being fed into 'bash -c' (and hence getting evaluated twice??) rather
than just run?
Re: [PATCH cygport] Add repro-finish command
On 11/03/2024 11:41, Christian Franke via Cygwin-apps wrote: Thanks for accepting the repro-check patch. A minor enhancement is attached. Applied. Thanks! The function is in pkg_pkg.cygpart instead of pkg_cleanup.cygpart because then it is easier to keep it in sync with the other __repro_* functions. PS: I have a local script which checks SPDX Identifiers and expressions. Any interest to add this to cygport and then check LICENSE settings? Oh, yes please. That sounds like a good idea.
Re: [PATCH cygport] dodoc: Skip a file if a compressed version already exists
On 10/03/2024 15:44, Christian Franke via Cygwin-apps wrote:
Jon Turney wrote:
On 01/03/2024 13:13, Christian Franke via Cygwin-apps wrote:
It IMO makes sense to compress large and rarely viewed doc files like
change logs. This seems to be common practice on Debian etc.
With current cygport, the following results in ChangeLog and
ChangeLog.gz in the docdir:
src_install()
{
...
dodoc ChangeLog
gzip -9 -n "${D}/usr/share/doc/${PN}/ChangeLog"
}
Uh, I don't quite see how this patch will change the behavior of this
fragment.
Yes, it actually doesn't change the behavior of this fragment itself.
Even more confusing, why isn't this already doing what you want?
Unless you specify -k/--keep to gzip, the input file is removed, right?
Yes - but after this src_install() the file will be re-added by
__predoc() unless _CYGPORT_RESTRICT_postinst_doc_ is set. The patch
avoids this because __predoc() also uses dodoc().
Ah, I get it.
Applied with a bit of rewording of the commit commentary for dullards
like myself.
Thanks.
Fwd: Howto request an upgrade for keychain package
Hi Jari, There do seem to be some incompatibilities between our current keychain package and current gpg/gpg2. Is it possible to get an update of keychain? Or let me know if you want to orphan that package. TIA. Forwarded Message Subject: Howto request an upgrade for keychain package Date: Thu, 18 Apr 2024 20:10:43 +0200 From: J M via Cygwin Reply-To: J M To: cyg...@cygwin.com Newsgroups: gmane.os.cygwin Hi, I'm having some problems (gpg2, and some for ssh management) with keychain package: https://www.cygwin.com/packages/summary/keychain.html It version is 2.7.1, can be upgraded to, by example the last 2.8.5? It is here: https://github.com/funtoo/keychain/tree/2.8.5 Regards
Re: Let's Encrypt Dropping Cross-Signed Root and Intermediates; Issuing New Intermediates; New Cert Chains
On 17/04/2024 04:48, Brian Inglis via Cygwin-apps wrote: Hi folks, Is this FYI, or are you suggesting there is some specific action we need to take? https://letsencrypt.org/2023/07/10/cross-sign-expiration Shortening the Let's Encrypt Chain of Trust "On Thursday, Feb 8th, 2024, we stopped providing the cross-sign by default in requests made to our /acme/certificate API endpoint. On Thursday, June 6th, 2024, we will stop providing the longer cross-signed chain entirely. On Monday, September 30th, 2024, the cross-signed certificate will expire." https://letsencrypt.org/2024/03/19/new-intermediate-certificates New Intermediate Certificates "Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 new Intermediate CA Certificates containing the new public keys." https://letsencrypt.org/2024/04/12/changes-to-issuance-chains Deploying Let's Encrypt's New Issuance Chains "On Thursday, June 6th, 2024, we will be switching issuance to use our new intermediate certificates. Simultaneously, we are removing the DST Root CA X3 cross-sign from our API, aligning with our strategy to shorten the Let’s Encrypt chain of trust. We will begin issuing ECDSA end-entity certificates from a default chain that just contains a single ECDSA intermediate, removing a second intermediate and the option to issue an ECDSA end-entity certificate from an RSA intermediate."
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 18/04/2024 07:01, Ake Rehnman wrote: Den tors 28 mars 2024 kl 18:50 skrev Jon Turney : On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote: On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote: On 24/03/2024 15:07, Jon Turney wrote: On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote: I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 3.6 (EOL Dec 2021)? (I'm still dealing with cleaning up the final pieces of python27 detritus, but these should hopefully be much smaller tasks) nothing should depend from 3.5 not sure for 3.6 I've automated some of the analysis I was doing for python2 packages and the results are now available at [1]. So yeah, it looks like nothing uses 3.5. There are just a couple of packages using 3.6, I guess I'll ping the maintainers about those. [1] https://cygwin.com/packages/reports/python_rebuilds.html Ake, Hi Jon, sorry for the late reply. No problem. Is it possible to update/rebuild libftdi1, which only publishes python bindings for the soon-to-be removed python36? I am not sure, I have not looked at it for so many years, I have not even used cygwin since I don't remember... (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Do you have any stats on how many installs it was last year? I'm afraid we don't collect that information. If you are not using it anymore, it seems like the logical thing to do is orphan this package (and libconfuse, it's dependency, your only other package). Thanks for your work in the past.
Re: calm: ERROR: Upload failed: cd: Access failed: No such file (/x86_64/release)
On 17/04/2024 20:26, Brian Inglis via Cygwin-apps wrote: Hi folks, Fairly straightforward upgrade of packages. Is anything demented about my setup: $ cygport GeoIP.cygport upload >>> Uploading GeoIP-1.7.0-1.x86_64 >>> Running lftp sftp://cygwin:@cygwin.com cd: Access failed: No such file (/x86_64/release) *** ERROR: Upload failed Thanks for reporting this. When I connect using `lftp sftp://cygwin` I now seem to be logged in to the sftp *root* instead of /home/Brian\ Inglis! But in future, if you are ever reporting "I think I have access to stuff on sourceware I shouldn't have access to", you may, exceptionally in that situation only, send me a private mail. Or is this just a way to allow my GeoIP... updates to be fixed up before I can do anything more? This was the result of a sshd configuration error which has been rectified by sourceware overseers.
Re: [ITA] GeoIP, GeoIP-database, geoipupdate
On 17/04/2024 00:39, Brian Inglis via Cygwin-apps wrote:
On 2024-04-16 13:31, Jon Turney via Cygwin-apps wrote:
On 13/04/2024 14:09, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and revive the above packages with the last
("unofficial") version of the legacy code committed noted in the
ChangeLog as 1.7.0, and a new upstream source for legacy format free
databases converted when the official current upstream databases are
updated.
My very limited, vague understanding was that GeoIP is obsolete and
users should move to something newer? What packages do we have that
actually depend on this? Are there other ways to update them?
$ cygcheck-dep -nqS libGeoIP1 libmaxminddb0
libGeoIP1: is needed for ( GeoIP libdns1104 libdns1105 libdns166
libdns169 libGeoIP-devel )
libmaxminddb0: is needed for ( bind libdns1106 libmaxminddb-devel
lighttpd-mod_maxminddb )
Looks like older bind used free legacy GeoIP databases, "current" bind
uses current library and current GeoIP2 databases which require free
registration to get an API key with limits.
The new upstream source for free legacy GeoIP databases converts
upstream GeoIP2 databases and makes them available under its CC-by-4.0
licence.
The most recent bind package was built with '--without-geoip'. Does
this need to change back again?
$ cpm-sum libdns1{6{6,9},10{4,5,6}} | grep
'dns\|bind\|maxmind\|GeoIP\|depends:\|ackage:$'
Package: libdns166
depends:
cygwin, libGeoIP1, libgssapi_krb5_2, libisc160, libjson-c2, libkrb5_3,
rdepends:
dnsperf, libbind9_160, libirs160, libisccfg160
source package:
bind
I guess there's another thread to pull on here.
The code which looks for "old soversions we don't need to keep anymore"
isn't smart enough currently to realize that it can get rid of all of
these old libdns soversions.
Assuming that gets fixed (...), do we still have users?
Re: calm: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate
On 17/04/2024 15:17, Brian Inglis via Cygwin-apps wrote: On 2024-04-17 07:08, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate This is the "change things to that the geoipupdate package belongs to GeoIP-database source" I previously mentioned. I've done that, and the upload seems to have succeeded. I also fixed a typo I noticed in the geoipupdate DESCRIPTION: - THe geoipupdate database updater script downloads the latest available + The geoipupdate database updater script downloads the latest available
Re: [ITA] GeoIP, GeoIP-database, geoipupdate
On 13/04/2024 14:09, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and revive the above packages with the last
("unofficial") version of the legacy code committed noted in the
ChangeLog as 1.7.0, and a new upstream source for legacy format free
databases converted when the official current upstream databases are
updated.
My very limited, vague understanding was that GeoIP is obsolete and
users should move to something newer? What packages do we have that
actually depend on this? Are there other ways to update them?
Is there any easy way of overridding package version from
ac_init_version without patching configure.ac?
Generally, no.
As part of this upgrade, the geoipupdate source and databases are no
longer available, so the new upstream database source update script
becomes a new database subpackage and script geoipupdate, and the old
geoipupdate source, binary, and debuginfo packages should become obsolete.
Is there anything special required to replace a source package and
binaries with a binary subpackage?
Uh... I had to reread that several times (and compare with the cygport)
before it this question made sense.
So: when you come to upload, I'll need to change things to that the
geoipupdate package belongs to GeoIP-database source.
geoipupdate should probably obsolete geoipupdate-debuginfo, if it's now
empty.
Reviewing the cygports, everything looks OK.
I'd make the comment that the text about scheduling geoipupdate to run
should be in geoipupdate_DESCRIPTION, rather than in GeopIP-database's
description.
I added GeoIP and GeoIP-database to your packages.
Re: package uploads not being processed again - calm failed or stuck?
On 14/04/2024 22:01, Brian Inglis via Cygwin-apps wrote: On 2024-04-14 13:53, Brian Inglis via Cygwin-apps wrote: Not seeing any progress hours after package upload - master setup.ini not updated and no calm emails received - has calm failed or is it stuck? `ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ command to show us what calm is doing! Sorry, this isn't going to happen for various reasons. Achim - none of your announced releases appear to have been processed yet! Thanks to whoever got the process going again a half hour ago! I could see from curl -I the setup.ini last-modified date updated. No problem. sourceware overseers have re-arranged things so it won't be automatically killed by systemd for lols, and I am assured it should carry on running now... Some emails reporting uploads that had been processed have been lost during the confusion. We apologize for the inconvenience.
Re: package uploads not being processed - calm failed or stuck?
On 13/04/2024 21:12, Brian Inglis via Cygwin-apps wrote: Hi folks, Not seeing any progress hours after package upload - master setup.ini not updated and no calm emails received - has calm failed or is it stuck? Thanks for the report. Not sure what went wrong there, but I've restarted it and it seems to have processed all the pending uploads.
Re: python2 removal
On 10/04/2024 20:19, Hamish McIntyre-Bhatty via Cygwin-apps wrote: On 19/01/2024 18:23, Hamish McIntyre-Bhatty via Cygwin-apps wrote: On 18/01/2024 19:40, Jon Turney wrote: On 18/01/2024 19:31, Jon Turney via Cygwin-apps wrote: [...] python-wx-devel wxWidgets C++ application framework (Python bindings) [...] python-wx-devel is the last remnant of python2 bindings for wx (the python3 binding comes from a different, irregularly named source package python3-wx), so can also be removed. Cc:ing Hamish as a note that if/when python3-wx is updated, we should see if it's now possible to rename the source package to python-wx. [...] Okay, I'd be happy to try renaming the package to python-wx the next time I update python3-wx. [...] I realise I forgot to ask, but how could I go about renaming python3-wx to python-wx when I update? I also maintained python-wx, so I shouldn't need any extra permissions I don't think. Uh, yeah, this is made more complex as we had a 'python-wx' source package (for the python2 bindings, now removed), and a separate 'python3-wx' source package (for python3 bindings). I guess what wants to happen is: * (If you care about such things) Merge the python3-wx history into the python-wx packaging git repo (git merge --allow-unrelated-histories seems like it might be the right voodoo runes). * Rename python3-wx.cygport to python-wx.cygport and update version or bump release. * When it comes to uploading the rebuilt packages, there's unfortunately (currently) a manual step involved (for me to) adjust the "allegiance" of the 'python3n-wx' install packages from the 'python3-wx' source package to 'python-wx', but I'll do that when needed (or maybe even get around to automating it this time...)
Re: Where have svt-av1 1.8.0-2 gone?
On 17/03/2024 01:43, Takashi Yano via Cygwin-apps wrote: On Sun, 17 Mar 2024 10:06:31 +0900 Takashi Yano wrote: On Sat, 16 Mar 2024 17:49:30 + Jon Turney wrote: On 16/03/2024 00:48, Takashi Yano via Cygwin-apps wrote: On Sat, 16 Mar 2024 09:39:33 +0900 Takashi Yano wrote: [...] This expected: 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1 libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2) -> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2) However, this does not seem to work as I expected. What unexpected thing happens? I guess you only get one of libsvtav1enc1 or libsvtav1dec0 (since if these both are marked "obsoletes: libsvtav1", to the dependency solver that mean that either of can replace libsvtav1, and provides everything that it provides. So maybe the best solution is: libsvtav1dec0_OBSOLETES=libsvtav1 libsvtav1dec0_REQUIRES=libsvtav1enc1 So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1 Looks great! My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2) are installed for upgrading libsvtav1(1.8.0-1). Instead, I found 1.8.0-2: libsvtav1_CATEGORY="_obsolete" libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0" libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll" libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll" Yeah, this should work, but is not longer preferred because you end up with an empty libsvtav1 hanging around forever... works as expected. Is it possible to change it like this now? I've tweaked the existing dependencies based on my reasoning above. Please let me know if this still isn't working right. Thanks you very much! Could you please also remove: libsvtav1enc1_OBSOLETES=libsvtav1 because it seems that this conflicts with libsvtav1dec0_OBSOLETES=libsvtav1 ? Oops. I obviously needed to do that, but forget. Then I did it, and forget to tell you that I'd done it. Hopefully, that resolves the misbehavior you describe below. I noticed that the following happen even with obove if the package which requires libsvtav1 is installed. At the first upgrade, Uninstall libsvt1v1 1.8.0-1 Install libsvtav1dec0 1.8.0-2 Install libsvtav1enc1 1.8.0-2 that is as expected except for libsvtav1dec0 is not latest. However, at the next upgrade (just run setup again), Uninstall libsvtav1dec0 1.8.0-2 Install libsvtav1 1.8.0-1 Install libsvtav1dec0 2.0.0-1 happens. This causes conflict: $ cygcheck -f /usr/bin/cygSvtAv1Dec-0.dll libsvtav1-1.8.0-1 libsvtav1dec0-2.0.0-1 Im not sure why this happens. Contrary to your idea, libsvtav1enc1_OBSOLETES="libsvtav1" libsvtav1enc1_REQUIRES="libsvtav1dec0" the followings happen as expected. Uninstall libsvtav1 1.8.0-1 Install libsvtav1dec0 2.0.0-1 Install libsvtav1enc1 1.8.0-2 Of cource, libsvtav1dec0_OBSOLETES=libsvtav1 should be removed in this case. What do you think?
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 02/04/2024 15:58, Takashi Yano via Cygwin-apps wrote: On Tue, 2 Apr 2024 15:38:25 +0100 Jon Turney wrote: On 01/04/2024 18:16, David Rothenberger via Cygwin-apps wrote: On 3/30/2024 8:25 AM, Jon Turney wrote: On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote: On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote: [...] David, Is it possible to update/rebuild rdiff-backup, which replies upon the soon-to-be removed python36? (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Please remove me as the maintainer from that package. I no longer use it, and no longer have an environment for building packages for Cygwin. No problem. Thanks for maintaining it in the past. Is the same true for your other packages? $ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED cyrus-sasl David Rothenberger flac David Rothenberger libao David Rothenberger libapr1 David Rothenberger libaprutil1 David Rothenberger libkate David Rothenberger libogg David Rothenberger librsync David Rothenberger libtheora David Rothenberger libvorbis David Rothenberger rdiff-backup David Rothenberger speex David Rothenberger speexdsp David Rothenberger vorbis-tools David Rothenberger which David Rothenberger whois David Rothenberger Yes, I'm afraid it is. Done. Thanks for all your work on these in the past. Hi, I would like to take over the maintenance of: flac David Rothenberger libao David Rothenberger libogg David Rothenberger libtheora David Rothenberger libvorbis David Rothenberger speex David Rothenberger speexdsp David Rothenberger vorbis-tools David Rothenberger if anyone would not. Thanks. I added these to your packages. I generated missing packaging history repos for some of these from the CTM history. Please let me know if there's any errors or if you'd like those removed. I didn't check, but if any of these are no longer carried by recent linux distros, maybe think about if it's actually useful to keep on having a package for it...
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 01/04/2024 18:16, David Rothenberger via Cygwin-apps wrote: On 3/30/2024 8:25 AM, Jon Turney wrote: On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote: On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote: [...] David, Is it possible to update/rebuild rdiff-backup, which replies upon the soon-to-be removed python36? (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Please remove me as the maintainer from that package. I no longer use it, and no longer have an environment for building packages for Cygwin. No problem. Thanks for maintaining it in the past. Is the same true for your other packages? $ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED cyrus-sasl David Rothenberger flac David Rothenberger libao David Rothenberger libapr1 David Rothenberger libaprutil1 David Rothenberger libkate David Rothenberger libogg David Rothenberger librsync David Rothenberger libtheora David Rothenberger libvorbis David Rothenberger rdiff-backup David Rothenberger speex David Rothenberger speexdsp David Rothenberger vorbis-tools David Rothenberger which David Rothenberger whois David Rothenberger Yes, I'm afraid it is. Done. Thanks for all your work on these in the past. Please accept this virtual gold-plated solid 1/10th-scale pocket watch as a token of our appreciation!
Re: calm now runs on-demand
On 01/07/2017 15:22, Jon Turney wrote: On 01/07/2017 15:14, Marco Atzeri wrote: On 01/07/2017 15:54, Jon Turney wrote: On 01/07/2017 06:18, Marco Atzeri wrote: On 17/04/2017 13:34, Jon Turney wrote: If you have shell access on sourceware, and make such changes, you can force calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. calm now (finally) detects when changes have been made in the relarea via inotify, so this manual step is no longer required. So, if you have shell access, and you make changes directly in the relarea, calm should now notice, reread it, and update the setup.ini package manifest automatically, without you needing to explicitly request that (or wait until the next scheduled rescan, if you can't request it due to the permission problem identified below...) Jon, I have shell access but I do not find calm anywhere. I assume "~cygwin-admin" is more restricted than shell access. As I did change to the relarea for gcc test, how to force the update of setup.ini's ? I think I have fixed the permissions, so this should work for you now. Thanks for pointing out this problem. May be I misunderstood how I should use it matzeri@sourceware ~ $ /home/cygwin/bin/calm scan-relarea /home/cygwin/bin/calm: line 13: kill: (14958) - Operation not permitted No, that's me being dumb. I guess I need to think some more about how to make this work for other users...
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:
On 24/03/2024 15:07, Jon Turney wrote:
On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:
I assume you are OK with the removal of python 3.5 (EOL Sept 2020)
and 3.6 (EOL Dec 2021)?
(I'm still dealing with cleaning up the final pieces of python27
detritus, but these should hopefully be much smaller tasks)
nothing should depend from 3.5
not sure for 3.6
I've automated some of the analysis I was doing for python2 packages and
the results are now available at [1].
So yeah, it looks like nothing uses 3.5.
I've removed some 3.4 detritus, and 3.5
Perhaps you can clarify the situation with python-pip: python-pip
19.0.3-1, 19.1.1-1 and 19.2.3-1 are not evaluated are being removable,
despite python35-pip being not needed anymore, as that source also
produces python-pip-wheel, which is depended upon by
python3{6,7,8,9}-virtualenv.
A similar situation exists with python-setuptools, python35-setuptools
and python-setuptools-wheel.
(virtualenv also depends on python-wheel-wheel, but that tracks the
latest version)
There are just a couple of packages using 3.6, I guess I'll ping the
maintainers about those.
[1] https://cygwin.com/packages/reports/python_rebuilds.html
It looks like the situation with 3.6 is a bit more complex, as some
things have a generic python3 dependency, rather than python36 as they
should, so that report isn't complete.
I have some tools to correct those dependencies, so the situation should
become clearer after I run those...
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote: On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote: [...] David, Is it possible to update/rebuild rdiff-backup, which replies upon the soon-to-be removed python36? (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Please remove me as the maintainer from that package. I no longer use it, and no longer have an environment for building packages for Cygwin. No problem. Thanks for maintaining it in the past. Is the same true for your other packages? $ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED cyrus-sasl David Rothenberger flac David Rothenberger libaoDavid Rothenberger libapr1 David Rothenberger libaprutil1 David Rothenberger libkate David Rothenberger libogg David Rothenberger librsync David Rothenberger libtheoraDavid Rothenberger libvorbisDavid Rothenberger rdiff-backup David Rothenberger speexDavid Rothenberger speexdsp David Rothenberger vorbis-tools David Rothenberger whichDavid Rothenberger whoisDavid Rothenberger
Re: [PATCH setup] Fix Chinese Help Message fall in dead loop .
On 29/03/2024 01:40, 赵伟 via Cygwin-apps wrote:
---
libgetopt++/include/getopt++/DefaultFormatter.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libgetopt++/include/getopt++/DefaultFormatter.h
b/libgetopt++/include/getopt++/DefaultFormatter.h
index ee2397f5..43c253a5 100644
--- a/libgetopt++/include/getopt++/DefaultFormatter.h
+++ b/libgetopt++/include/getopt++/DefaultFormatter.h
@@ -64,6 +64,7 @@ class DefaultFormatter {
{
// TODO: consider using a line breaking strategy here.
int pos = helpmsg.substr(0,h_len).find_last_of(" ");
+ if(!pos)break; /*In Chinese Helpmsg,may has no space,so pos ==0,and
code will fall in dead loop here*/
theStream helpmsg.substr(0,pos)
std::endl std::string (o_len, ' ');
helpmsg.erase (0,pos+1);
--
2.43.0
Thanks very much for bug report, and the patch!
Did you actually try this? When I tested this it didn't help, as
std::string::substr() returns std::string::npos (numerically, -1), not 0
when it cannot find a match.
So, I applied a slightly modified version of the patch.
Please try https://cygwin.com/setup/setup-2.931-1-g0ee13c.x86_64.exe
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote: On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote: On 24/03/2024 15:07, Jon Turney wrote: On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote: I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 3.6 (EOL Dec 2021)? (I'm still dealing with cleaning up the final pieces of python27 detritus, but these should hopefully be much smaller tasks) nothing should depend from 3.5 not sure for 3.6 I've automated some of the analysis I was doing for python2 packages and the results are now available at [1]. So yeah, it looks like nothing uses 3.5. There are just a couple of packages using 3.6, I guess I'll ping the maintainers about those. [1] https://cygwin.com/packages/reports/python_rebuilds.html David, Is it possible to update/rebuild rdiff-backup, which replies upon the soon-to-be removed python36? (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Thanks.
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote: On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote: On 24/03/2024 15:07, Jon Turney wrote: On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote: I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 3.6 (EOL Dec 2021)? (I'm still dealing with cleaning up the final pieces of python27 detritus, but these should hopefully be much smaller tasks) nothing should depend from 3.5 not sure for 3.6 I've automated some of the analysis I was doing for python2 packages and the results are now available at [1]. So yeah, it looks like nothing uses 3.5. There are just a couple of packages using 3.6, I guess I'll ping the maintainers about those. [1] https://cygwin.com/packages/reports/python_rebuilds.html Ake, Is it possible to update/rebuild libftdi1, which only publishes python bindings for the soon-to-be removed python36? (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Thanks.
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 27/03/2024 21:18, Brian Inglis via Cygwin-apps wrote:
On 2024-03-27 14:07, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:
On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:
On 24/03/2024 15:07, Jon Turney wrote:
On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:
[...]
Are they supposed to migrate to some alternate bindings maybe
available from a separate repo? Or are they just out of luck?
SOL! Dropped them in 1.52, probably why 1.31.0..1.51.0 are hanging around.
Nice :S
Feel free to purge as appropriate, or tell me what to add to cygport,
hints, etc!
So, the long list of source versions will hopefully be reduced in the
fullness of time...
Could I just add to nghttp2.cygport that nghttp2 obsoletes
python{2{,7},3{,6,7,8,9}}-nghttp2?
Does this have to remain in the cygport forever to avoid keeping nghttp2
vx.x.x around?
You could, but that's probably not the correct thing to do unless you
really, really want to forcibly uninstall those packages for anyone who
has installed them, which seems like unnecessary breakage.
I don't think you have to do anything. There's nothing "wrong" here.
If it really offends your sense of aesthetics, I suggest you just expire
some subset of the old versions using the vault command [1].
[1] https://cygwin.com/package-upload.html#deleting
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote: On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote: On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote: On 24/03/2024 15:07, Jon Turney wrote: On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote: [...] Not sure why my source package nghttp2 shows python install packages, when they were dropped after 1.43 IIRC: build deps no longer include python/-devel? If you haven't taken any specific action to retire the python-3x-nghttp2 packages, the existing ones will continue to be available indefinitely. Firstly, it seems there's a question here about what are upstream's plans for the users of the python bindings for this library. Are they supposed to migrate to some alternate bindings maybe available from a separate repo? Or are they just out of luck? And why does that nghttp2 source package show a dozen archived source versions, when its installed packages have only three? The simple answer to that is we retain the source package for all available install packages. This seems essential for an open-source project. Now, as to why there are so many installable packages, this is the intersection of a couple of unfortunate issues. 1. 'python3-nghttp2' is an "old-style" obsoletion package, where the package exists, but is of category _obsolete, and requires the replacement package. These are terrible, because we can't remove the obsolete package because that's what records the fact of obsoletion. I actually have some code for calm to internally convert that to a "new-style" obsoletion, where the replacement package itself records the obsoletion (i.e. python36-nghttp2 obsoletes: python3-nghttp2), which it continues to remember about even after the package which contains that obsoleting is expired. Once that's done, all those "old-style" obsoletion packages lingering in our package repository can be removed (along with their corresponding source). But I still need to do some testing before that can be deployed. (However, all that's probably not what's actually wanted with python packages: it's preferable to have python3-foo be a virtual package which pulls in python3x-foo, where python3x is the current python, so that scripted installs can be written which ask for python3 and python3-foo and continue to work while x changes...) 2. We haven't purged old python versions for a long time, so e.g the python36 binding packages are still lingering. As you can see, I'm just now getting around to looking at expiring python36, which eventually should lead to python36-nghttp2 being expired (insert some observations about how it doesn't have to be me doing these things here)... Feel free to purge as appropriate, or tell me what to add to cygport, hints, etc! So, the long list of source versions will hopefully be reduced in the fullness of time...
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote: On 24/03/2024 15:07, Jon Turney wrote: On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote: I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 3.6 (EOL Dec 2021)? (I'm still dealing with cleaning up the final pieces of python27 detritus, but these should hopefully be much smaller tasks) nothing should depend from 3.5 not sure for 3.6 I've automated some of the analysis I was doing for python2 packages and the results are now available at [1]. So yeah, it looks like nothing uses 3.5. There are just a couple of packages using 3.6, I guess I'll ping the maintainers about those. [1] https://cygwin.com/packages/reports/python_rebuilds.html
Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote: Generally, we have a large number of old, unmaintained packages. The policy [1] has always been "Packages without an active maintainer may be pulled from the distribution.", but not actively enforced (in fact prior to 2022, this used to say "are pulled", but I moderated the statement, just to reflect reality). I guess this needs to also mention upstream EOL status as a criteria. [...] Here's my personal list: * python After python27 (the last python2 version, which has been sun-setted since 2020), both python36 and python37 should be removed (after rebuilding any python-* package which don't currently provide 3.8, 3.9 versions) Marco, I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 3.6 (EOL Dec 2021)? (I'm still dealing with cleaning up the final pieces of python27 detritus, but these should hopefully be much smaller tasks)
Re: Fwd: Updating cygwin "libnfs" package ?
On 22/03/2024 16:08, Roland Mainz via Cygwin-apps wrote: Hi! I'd like to take ownership of the Cygwin "libnfs" package (see email below, the package is old and has bugs related to NFSv4.*) ... ... how do we proceed ? Should I send a patch here, or what do I have to do ? [1] should explain this (could probably be improved). A patch against the packaging repo would be a good place to start. [1] https://cygwin.com/packaging-contributors-guide.html#adopt
Re: [ITP] afflib 3.7.20-1
On 21/03/2024 09:04, Christian Franke via Cygwin-apps wrote: On Wed, 6 Mar 2024 23:26:05 +0100, Christian Franke wrote: Jon Turney wrote: ... be added only when needed for new not backward compatible releases. The upstream afflib project is mostly idling, so I don't expect any new major lib versions in the near future. If course, I could rename it to libafflib0 if desired. As far as I know, there is no cost for doing this, and it saves grief if upstream ever bumps the soversion. Also, it's probably best to explicitly list the filename with soversion in the CONTENTS, so that if upstream ever does change the soversion, it will be detected as a packaging failure, rather than producing a package with a mismatch between the soversion in it's name and in it's contents. Good point, new cygport file is attached. Any further issues with this ITP? Seems good. I added this to your packages.
Re: Where have svt-av1 1.8.0-2 gone?
On 16/03/2024 00:48, Takashi Yano via Cygwin-apps wrote: On Sat, 16 Mar 2024 09:39:33 +0900 Takashi Yano wrote: [...] This expected: 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1 libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2) -> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2) However, this does not seem to work as I expected. What unexpected thing happens? I guess you only get one of libsvtav1enc1 or libsvtav1dec0 (since if these both are marked "obsoletes: libsvtav1", to the dependency solver that mean that either of can replace libsvtav1, and provides everything that it provides. So maybe the best solution is: libsvtav1dec0_OBSOLETES=libsvtav1 libsvtav1dec0_REQUIRES=libsvtav1enc1 So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1 My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2) are installed for upgrading libsvtav1(1.8.0-1). Instead, I found 1.8.0-2: libsvtav1_CATEGORY="_obsolete" libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0" libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll" libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll" Yeah, this should work, but is not longer preferred because you end up with an empty libsvtav1 hanging around forever... works as expected. Is it possible to change it like this now? I've tweaked the existing dependencies based on my reasoning above. Please let me know if this still isn't working right.
Re: Where have svt-av1 1.8.0-2 gone?
On 15/03/2024 13:31, Takashi Yano via Cygwin-apps wrote: On Fri, 15 Mar 2024 13:14:49 + Jon Turney wrote: On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote: I uploaded svt-av1 1.8.0-2 few hours ago, however it does not appear on the mirror servers so far. Was anything wrong? Sorry, things will be a little slower than usual (uploads may take up to 4 hours to get processed) until I get around to fixing up things for some changes made on sourceware to provide better isolation. I see that this upload was declined because svt-av1 2.0.0 already exists. I guess you really want to upload it, as it provides a different set of shared libraries to 2.0.0. Please let me know. 1.8.0-2 is necessary for changing packaging. I see. I configured the necessary exception, sot his should be all uploaded now. 1.8.0-1: cygSvtAv1Enc-1.dll and cygSvtAv1Dec-0.dll are in libsvtav1, However, 2.0.0-1: cygSvtAv1Enc-2.dll and cygSvtAv1Dec-0.dll are built. So, I made 1.8.0-2: cygSvtAv1Enc-1.dll is in libsvtav1enc1 and cygSvtAv1Dec-0 is in libsvtav1dec0 both obsolete libsvtav1 for migration. Hmm... maybe your thinking here is not quite clear. You cannot assume that an installation is upgraded often enough that it receives every version of every package. (And in this case, where 1.8.0-2 appears in the repository after 2.0.0 does, it's not going to get automatically installed anywhere) So, as a principle, every version of a package must contain complete instructions for upgrading to it. In this particular case, that means the cygport should contain libsvtav1dec0_OBSOLETES=libsvtav1 for as long as the package produces libsvtav1dec0. (In fact, I think this all happens to work as desired because libsvtav1 is also obsoleted by the non-longer produced libsvtav1enc1, but I just point this out for completeness) The first step I did was wrong, i.e. I should not have package which includes dlls whose versions are different. Sorry. No problem. Mistakes happen.
Re: Unable to 'git push' to /git/cygwin-packages/*
On 15/03/2024 09:00, Mark Geisert via Cygwin-apps wrote:
On 3/14/2024 9:07 AM, Jon Turney via Cygwin-apps wrote:
On 14/03/2024 15:39, Mark Geisert via Cygwin-apps wrote:
On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote:
On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:
Hi folks,
I'm getting the error:
fatal: remote error: service not enabled: /git/cygwin-packages/sshfs
when I attempt 'git push' to that repository. The same happens
with all the repositories for my packages. It's been this way for
a couple days at least.
Have I forgotten some step in the connection at my end? I'm
running ssh-agent.
[...]
What is the repository URL you are trying to push to (git remote -v)?
/usr/src/upstaging/sshfs git remote -v
origin git://cygwin.com/git/cygwin-packages/sshfs (fetch)
origin git://cygwin.com/git/cygwin-packages/sshfs (push)
This maybe looks like pilot error.
We don't allow pushing using the git:// protocol (since this protocol
doesn't do any authorization, pushes with a it are very rarely enabled)
I suggest you need to do
git push
ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:git/cygwin-packages/sshfs
to push successfully.
If that works, I suggest you memorialize that by doing
git remote set-url origin --push
ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:git/cygwin-packages/sshfs
which will cause git to automatically use the ssh URL with a simple
'git push'.
With a minor correction ("/git" instead of "git" in the URL) this works
fine. I've made the git config change for all my projects.
Oops. Yes. Of course that's right, my mistake.
Glad to hear that things are working again for you!
Re: Where have svt-av1 1.8.0-2 gone?
On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote: I uploaded svt-av1 1.8.0-2 few hours ago, however it does not appear on the mirror servers so far. Was anything wrong? Sorry, things will be a little slower than usual (uploads may take up to 4 hours to get processed) until I get around to fixing up things for some changes made on sourceware to provide better isolation. I see that this upload was declined because svt-av1 2.0.0 already exists. I guess you really want to upload it, as it provides a different set of shared libraries to 2.0.0. Please let me know.
Re: Unable to 'git push' to /git/cygwin-packages/*
On 14/03/2024 15:39, Mark Geisert via Cygwin-apps wrote: On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote: On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote: Hi folks, I'm getting the error: fatal: remote error: service not enabled: /git/cygwin-packages/sshfs when I attempt 'git push' to that repository. The same happens with all the repositories for my packages. It's been this way for a couple days at least. Have I forgotten some step in the connection at my end? I'm running ssh-agent. This is probably due to some recent changes made on sourceware. Apologies for the inconvenience. I forget to ask when was the last time this worked for you, so maybe assuming this is related is premature. What is the repository URL you are trying to push to (git remote -v)? /usr/src/upstaging/sshfs git remote -v origin git://cygwin.com/git/cygwin-packages/sshfs (fetch) origin git://cygwin.com/git/cygwin-packages/sshfs (push) This maybe looks like pilot error. We don't allow pushing using the git:// protocol (since this protocol doesn't do any authorization, pushes with a it are very rarely enabled) I suggest you need to do git push ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs to push successfully. If that works, I suggest you memorialize that by doing git remote set-url origin --push ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs which will cause git to automatically use the ssh URL with a simple 'git push'. You might like to review the last time we discussed this at [1] (Note that's slightly different, as to push to cygwin-apps repositories you must present the key as yourusern...@cygwin.com, whereas for cygwin-packages repositories, you can present the key as cyg...@cygwin.com. There are just different due to historical reasons.) [1] https://cygwin.com/pipermail/cygwin-apps/2021-September/041539.html
Re: Unable to 'git push' to /git/cygwin-packages/*
On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote: Hi folks, I'm getting the error: fatal: remote error: service not enabled: /git/cygwin-packages/sshfs when I attempt 'git push' to that repository. The same happens with all the repositories for my packages. It's been this way for a couple days at least. Have I forgotten some step in the connection at my end? I'm running ssh-agent. This is probably due to some recent changes made on sourceware. Apologies for the inconvenience. What is the repository URL you are trying to push to (git remote -v)?
Re: [cygport] enabling a replacement for "objdump -d -l"
On 11/03/2024 19:35, ASSI via Cygwin-apps wrote: Jon Turney via Cygwin-apps writes: [...] Fifty lines of perl with no comments! This is just line noise to me unless I spend lots of time staring at it :) That's what you get from an experiment that went rather more well than planned. Seriously, this should at least say "I'm running objdump -Wl to dump out the .debug_line section containing DWARF XYZ information. Then maybe some comments about what assumptions it's making about the human-readable output it's parsing. So you're asking for a manpage, really. Should be doable with enough round tuits. Well, that would be nice too, but there is is difference between describing what it does and describing how it does what it does. But I'm not being oblique here. I really do want comments. I'm not sure what's so astounding about the suggestion that a fifty line script should have some comments in it that you can't believe I mean that literally... [...] What this line is doing is obvious, the rest of this block, not so much. Nothing to see here, move along… :-P ... [...] Since the helper script will be installed, it could be made a boolean. Out of habit grown over decades, I always keep an escape hatch for using local (modified) copies in such scripts. Well, OK. This is less useful to people who actually want to use it, though, requiring them to know that "DWARF_PARSE=/usr/share/cygport/tools/dwarf-parse.pl" is the right incantation. Perhaps "DWARF_PARSE=1" could be a shorthand for that?
Re: [PATCH cygport] Use correct wording if only one package is announced
On 23/02/2024 11:16, Christian Franke via Cygwin-apps wrote:
Brian Inglis via Cygwin-apps wrote:
On 2024-02-21 07:25, Christian Franke via Cygwin-apps wrote:
Change variable name from $s to $has or $s_have as variable $s usually
implies only the plural letter s or nothing; e.g.
...
+ local has="s have"
+
+ [ $pkg_count != 1 ] || has=" has"
...
+The following package${has} been uploaded to the Cygwin distribution:
...
Agree - new patch attached.
Applied. Thanks!
Re: [PATCH cygport] Fix variable expansion in error message of embedded SMTP perl script
On 23/02/2024 12:09, Christian Franke via Cygwin-apps wrote: Harmless bug ... Applied. Thanks.
Re: [PATCH cygport] Add repro-check command
On 01/03/2024 19:16, Christian Franke via Cygwin-apps wrote: Christian Franke wrote: This could be used to check whether a package is possibly reproducible. Then it could make sense to add a reasonable SOURCE_DATE_EPOCH value to the cygport file. [...] An enhanced version of the patch is attached. The build and diff could now be run also individually and the diff report includes individual files from the packages. As a side effect, this enables another use case: Check whether changes to cygport only change the expected files. $ cygport project.cygport all repro-check ... *** Info: Rebuild produced identical packages Applied. Thanks!
Re: [PATCH cygport] dodoc: Skip a file if a compressed version already exists
On 01/03/2024 13:13, Christian Franke via Cygwin-apps wrote:
It IMO makes sense to compress large and rarely viewed doc files like
change logs. This seems to be common practice on Debian etc.
With current cygport, the following results in ChangeLog and
ChangeLog.gz in the docdir:
src_install()
{
...
dodoc ChangeLog
gzip -9 -n "${D}/usr/share/doc/${PN}/ChangeLog"
}
Uh, I don't quite see how this patch will change the behavior of this
fragment.
Even more confusing, why isn't this already doing what you want? Unless
you specify -k/--keep to gzip, the input file is removed, right?
The attached patch fixes this and also adds some missing documentation.
I applied the documentation change as that is obviously needed.
Re: [PATCH cygport] Modify origsrc timestamp in patch files if SOURCE_DATE_EPOCH is used
On 28/02/2024 15:54, Christian Franke via Cygwin-apps wrote: Found during testing of 'repro-check' patch with getent-2.18.90-5 source package. This patch also removes the requirement to set TZ=UTC before patches are generated. Applied, but the commentary could stand to be clearer about the issue. I guess this we now fix both the orig file and modified file timestamps in the patch file, as the orig timestamp may also vary.
Re: [PATCH cygport] Add customization support for announce command
On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:
Christian Franke wrote:
The email generated by the cygport announce command is useful, but
actual use cases are somewhat limited due to the hard-coded email
submission.
The attached patch adds more flexibility. The patch is on top of the
"Use correct wording if only one package is announced" patch.
Slightly changed patch attached. Also adjusted to new version of "Use
correct wording if only one package is announced" patch.
[...]
Thanks for this.
Possible (better?) alternative names for the new settings:
ANNOUNCEMENT_EDITOR
ANNOUNCEMENT_MAILER
Hmmm... I think "ANNOUNCE_EDITOR" and "ANNOUNCE_MAILER" would be
the best for clarity and conciseness.
-From: ${SMTP_SENDER}
-To: cygwin-annou...@cygwin.com
+${SMTP_SENDER:+From: ${SMTP_SENDER}
+}To: cygwin-annou...@cygwin.com
Date: $(date -R --date=${msgat})
-Message-Id: <$(date "+%Y%m%d%H%M%S.$$" --date=${msgat})-1-$(echo ${SMTP_SENDER} | sed
's|.*<\(.*\)>.*|\1|')>
+Message-Id: <$(date "+%Y%m%d%H%M%S.$$" --date=${msgat})-1-$(echo
${SMTP_SENDER:-cygport} | sed 's|.*<\(.*\)>.*|\1|')>
Subject: ${NAME} ${PVR}
Can you also explain what this is doing in the commit message, since
it's not immediately apparent.
Re: [PATCH cygport] Add more checks of SOURCE_DATE_EPOCH
On 26/02/2024 19:53, Christian Franke via Cygwin-apps wrote: Would it not make more sense to just re-export it if set? If the cygport file decides to set but not export it, there is possibly no need to do it. An example is smartmontools.cygport which passes the unexported variable as a parameter to configure. Ok, but exporting it is harmless there, right? (so that commands like "SOURCE_DATE_EPOCH=something cygport foo" work as expected?) Would make no difference as the 'VAR=val CMD...' syntax already exports the variable to the CMD: $ unset FOO; FOO=bar sh -c 'sh -c "sh -c printenv\ FOO"' bar Ah, right. So you seem to be saying that the only situation where it's set but not exported is where it's set in the cygport. So we're just making people (need to remember to) explicitly write "export SOURCE_DATE_EPOCH" in their cygport where needed?
Re: [PATCH cygport] pkg_info.cygpart: Do not detect dependencies on itself in ruby package
On 16/02/2024 12:51, Daisuke Fujimura via Cygwin-apps wrote: Attempting to create a package for ruby-3.3, but it fails when trying to detect a dependency on itself. Thanks for this patch. Can you clarify what the "failure" is here? To avoid this, skip them if the target is `ruby`. The second hunk seems like a removes the dependency on ruby_xy for the ruby package, which also provides ruby_xy. Historically, we've allowed self-dependencies like this, because they seem to be benign, although it seems like we could do with some generic code to suppress them (e.g. cygport also ends up generating cygwin-debuginfo with a dependency on itself, which is harmless but could be suppressed)
Re: Problem with git on cygwin.com?
On 09/03/2024 16:15, Marco Atzeri via Cygwin-apps wrote: On 09/03/2024 17:10, Jon Turney wrote: On 09/03/2024 15:55, Marco Atzeri via Cygwin-announce wrote: I start to see $ git pull cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Has the configuration been modified ? Probably. What is the repository URL you are trying to fetch from (git remote -v) last one ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org/git/cygwin-packages/xxhash.git Thanks. Overseers have fixed this issue. Thanks for reporting it!
Re: Problem with git on cygwin.com?
On 09/03/2024 15:55, Marco Atzeri via Cygwin-announce wrote: I start to see $ git pull 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. Has the configuration been modified ? Probably. What is the repository URL you are trying to fetch from (git remote -v)
[PATCH setup 16/16] Add beginnings of a command line installation tool
At the moment, all this can do is retrieve setup.ini from a selected
mirror and parse it.
---
Makefile.am| 22 +-
cli/cyclops.cc | 186 +
2 files changed, 207 insertions(+), 1 deletion(-)
create mode 100644 cli/cyclops.cc
diff --git a/Makefile.am b/Makefile.am
index 6ae5dd6..5813e1a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -35,7 +35,10 @@ AM_CPPFLAGS = -D__USE_MINGW_ANSI_STDIO=1
-D_FILE_OFFSET_BITS=64 -DLZMA_API_STATI
inilex_CXXFLAGS:=-Wno-sign-compare
iniparse_CXXFLAGS:=-Wno-free-nonheap-object
-noinst_PROGRAMS = @SETUP@$(EXEEXT) inilint
+noinst_PROGRAMS = \
+ @SETUP@$(EXEEXT) \
+ inilint \
+ cyclops
noinst_LTLIBRARIES = \
libsetupcore.la
@@ -214,6 +217,23 @@ IOSTREAM_PROVIDERS = \
io_stream_file.cc \
io_stream_file.h
+cyclops_SOURCES = \
+ $(IOSTREAM_PROVIDERS) \
+ cli/CliParseFeedback.cc \
+ cli/CliGetNetAuth.cc \
+ cli/CliGetUrlFeedback.cc \
+ cli/CliHashCheckFeedback.cc \
+ cli/CliFeedback.h \
+ cli/cyclops.cc \
+ res.rc
+
+cyclops_LDADD = \
+ libsetupcore.la \
+ libgetopt++/libgetopt++.la \
+ $(WININET)
+
+cyclops_LDFLAGS = -mconsole -Wc,-static -static-libtool-libs
+
@SETUP@_LDADD = \
libsetupcore.la \
libgetopt++/libgetopt++.la \
diff --git a/cli/cyclops.cc b/cli/cyclops.cc
new file mode 100644
index 000..549b65a
--- /dev/null
+++ b/cli/cyclops.cc
@@ -0,0 +1,186 @@
+/*
+ * Copyright (c) 2020 Jon Turney
+ *
+ * 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 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ */
+
+/*
+ * The one-eyed hippo sees all!
+ */
+
+#include "CliGetNetAuth.h"
+#include "CliFeedback.h"
+#include "ini.h"
+#include "LogFile.h"
+#include "resource.h"
+#include "setup_version.h"
+#include "state.h"
+
+#include "ConnectionSetting.h"
+#include "KeysSetting.h"
+#include "SiteSetting.h"
+#include "UserSettings.h"
+#include "netio.h"
+
+#include "getopt++/GetOption.h"
+#include "getopt++/BoolOption.h"
+
+BoolOption UnsupportedOption (false, '\0', "allow-unsupported-windows",
IDS_HELPTEXT_ALLOW_UNSUPPORTED_WINDOWS);
+static BoolOption HelpOption (false, 'h', "help", IDS_HELPTEXT_HELP);
+
+static void
+main_cli ()
+{
+ // installation RootDir is already established by read_mounts()
+ ConnectionSetting ConnectionSettings;
+ ExtraKeysSetting ExtraKeys;
+ SiteSetting ChosenSites;
+
+ // check windows version and abort if too low unless UnsupportedOption
+
+ // announce myself
+ std::cout << "cyclops " << setup_version << std::endl;
+
+ // mode of operation
+ // XXX: probably only support download and install mode
+ source = IDC_SOURCE_NETINST;
+
+ // XXX: local package cache dir (from options or setup.rc)
+ // (fetched setp.ini is stored here)
+ char cwd[MAX_PATH];
+ GetCurrentDirectory (MAX_PATH, cwd);
+ local_dir = std::string (cwd);
+
+ // proxy
+
+ // interactive network auth getter
+ NetIO::auth_getter = new CliGetNetAuth();
+
+ // mirror site
+
+ // fetch and parse ini file(s)
+ CliFeedback feedback;
+ bool succeeded = do_ini_thread(feedback);
+ Log (LOG_PLAIN) << "do_ini_thread: " << succeeded << endLog;
+}
+
+static void
+main_wrap ()
+{
+ UserSettings Settings;
+ Settings.load (std::string());
+ main_cli ();
+ Settings.save (); // Clean exit. save user options.
+}
+
+int
+main (int argc, char **argv)
+{
+ LogSingleton::SetInstance (*LogFile::createLogFile ());
+
+ bool help_option = false;
+ bool invalid_option = false;
+
+ if (!GetOption::GetInstance ().Process (argc, argv, NULL))
+ help_option = invalid_option = true;
+else if (HelpOption)
+ help_option = true;
+
+ if (help_option)
+{
+ if (invalid_option)
+Log (LOG_PLAIN) << "\n" << LoadStringUtf8(IDS_HELPTEXT_ERROR) << "\n"
<< endLog;
+
+ Log (LOG_PLAIN) << "\n" << LoadStringUtf8(IDS_HELPTEXT_HEADER) << "\n"
<< endLog;
+ GetOption::GetInstance ().ParameterUsage (Log (LOG_PLAIN),
LoadStringUtf8);
+
+ Logger ().exit (invalid_option ? 1 : 0, false);
+ return 1;
+}
+
+ LogSingleton::SetInstance (*LogFile::createLogFile ());
+
+ main_wrap();
+
+ return 0;
+}
+
+/* --- */
+
+#include
+#include "String++.h"
+
+int
+mbox (HWND owner, const char *buf, const char *name, int type)
+{
+ Log (LOG_PLAIN) << "mbox " << name << ": " &
[PATCH setup 15/16] Put various shared subcomponents into a convenience library
* logging, settings, netio, iostream, decompressors, packagedb, csu_util, hashes, signature checking, URL fetching, Exception class, ini fetching and parsing, global state, version --- Makefile.am | 246 +++- 1 file changed, 126 insertions(+), 120 deletions(-) diff --git a/Makefile.am b/Makefile.am index def20a4..6ae5dd6 100644 --- a/Makefile.am +++ b/Makefile.am @@ -37,6 +37,9 @@ iniparse_CXXFLAGS:=-Wno-free-nonheap-object noinst_PROGRAMS = @SETUP@$(EXEEXT) inilint +noinst_LTLIBRARIES = \ + libsetupcore.la + EXTRA_DIST = \ CHANGES \ CONTRIBUTORS \ @@ -59,35 +62,15 @@ BUILT_SOURCES = \ CLEANFILES = setup_version.c inilint_LDADD = \ - libgetopt++/libgetopt++.la \ - -lntdll -luuid + libsetupcore.la \ + libgetopt++/libgetopt++.la inilint_SOURCES = \ - filemanip.cc \ - filemanip.h \ cli/CliParseFeedback.cc \ cli/CliGetUrlFeedback.cc \ cli/CliHashCheckFeedback.cc \ cli/CliFeedback.h \ - LogSingleton.cc \ - LogSingleton.h \ - IniDBBuilder.h \ - inilintmain.cc \ - inilex.ll \ - iniparse.yy \ - io_stream.cc \ - io_stream.h \ - io_stream_file.cc \ - io_stream_file.h \ - mkdir.cc \ - mkdir.h \ - mklink2.cc \ - mklink2.h \ - PackageTrust.h \ - String++.cc \ - String++.h \ - win32.cc \ - win32.h + inilintmain.cc # Do not link directly with wininet, as it's vulnerable to sideloading/dll # hijacking. Instead we make and link with a delay-loading stub lib, so it's @@ -116,19 +99,134 @@ WININET=wininet-delaylib.a EXTRA_@SETUP@_DEPENDENCIES=wininet-delaylib.a endif -@SETUP@_LDADD = \ - libgetopt++/libgetopt++.la \ +libsetupcore_la_SOURCES = \ + ConnectionSetting.cc \ + ConnectionSetting.h \ + Exception.cc \ + Exception.h \ + IniDBBuilder.h \ + IniDBBuilderPackage.cc \ + IniDBBuilderPackage.h \ + KeysSetting.cc \ + KeysSetting.h \ + LogFile.cc \ + LogFile.h \ + LogSingleton.cc \ + LogSingleton.h \ + PackageSpecification.cc \ + PackageSpecification.h \ + PackageTrust.h \ + SiteSetting.cc \ + SiteSetting.h \ + SourceSetting.cc \ + SourceSetting.h \ + String++.cc \ + String++.h \ + UserSettings.cc \ + UserSettings.h \ + compactos.cc \ + compactos.h \ + compress.cc \ + compress.h \ + compress_bz.cc \ + compress_bz.h \ + compress_gz.cc \ + compress_gz.h \ + compress_xz.cc \ + compress_xz.h \ + compress_zstd.cc \ + compress_zstd.h \ + crypto.cc \ + crypto.h \ + csu_util/MD5Sum.cc \ + csu_util/MD5Sum.h \ + csu_util/rfc1738.cc \ + csu_util/rfc1738.h \ + csu_util/version_compare.cc \ + csu_util/version_compare.h \ + filemanip.cc \ + filemanip.h \ + geturl.cc \ + geturl.h \ + gpg-packet.cc \ + gpg-packet.h \ + ini.cc \ + ini.h \ + inilex.ll \ + iniparse.yy \ + io_stream.cc \ + io_stream.h \ + io_stream_memory.cc \ + io_stream_memory.h \ + libsolv.cc \ + libsolv.h \ + mkdir.cc \ + mkdir.h \ + mklink2.cc \ + mklink2.h \ + mount.cc \ + netio.cc \ + netio.h \ + nio-ie5.cc \ + nio-ie5.h \ + package_db.cc \ + package_db.h \ + package_depends.cc \ + package_depends.h \ + package_meta.cc \ + package_meta.h \ + package_source.cc \ + package_source.h \ + package_version.h \ + setup_version.c \ + setup_version.h \ + sha2.c \ + sha2.h \ + state.cc \ + state.h \ + win32.cc \ + win32.h + +# warning: always link with mingwex (which gcc specs will cause us to link with +# anyhow) before ntdll, to ensure we don't link with CRT functions (avaliable in +# some versions of) the ntdll import lib which aren't available on XP. +libsetupcore_la_LDFLAGS = \ $(LIBGCRYPT_LIBS) \ $(ZSTD_LIBS) \ $(LZMA_LIBS) \ $(BZ2_LIBS) \ $(ZLIB_LIBS) \ - $(LIBSOLV_LIBS) -lregex \ + $(LIBSOLV_LIBS) \ + -lregex \ -lmingwex \ - -lshlwapi -lcomctl32 -lole32 -lpsapi -luuid -lntdll $(WININET) -lws2_32 \ + -lshlwapi \ + -luuid \ + -lntdll \ + -lws2_32 + +# because of a totally unnecessary "private registration" by static +# constructors, these sources are completely unsuitable for putting in a library +# (as the providers are not referenced and so aren't included in the final +# link), so everything with needs them must include these objects +IOSTREAM_PROVIDERS = \ + io_stream_cygfile.cc \ + io_stream_cygfile.h \ + io_stream_file.cc \ + io_stream_file.h + +@SETUP@_LDADD = \
[PATCH setup 14/16] Push check_for_cached into package_source
This is kind of half-right. It helps make the package database code
self-contained (since that needs to use check_for_cached as part of
ScanDownloadedFiles), but also pulls apart the 'cache checking' and
'download file and put it in the cache'. There's probably some scope
for an package_source interface for "where is the package cache download
location for this package from that site."
---
download.cc | 104 ++
download.h| 6 ---
package_meta.cc | 3 +-
package_source.cc | 95 ++
package_source.h | 4 ++
5 files changed, 103 insertions(+), 109 deletions(-)
diff --git a/download.cc b/download.cc
index fbe36e5..4aba83e 100644
--- a/download.cc
+++ b/download.cc
@@ -19,7 +19,7 @@
#include "csu_util/rfc1738.h"
#include "download.h"
-
+
#include "win32.h"
#include
@@ -28,7 +28,6 @@
#include
#include "resource.h"
-#include "msg.h"
#include "dialog.h"
#include "geturl.h"
#include "state.h"
@@ -48,110 +47,13 @@
extern ThreeBarProgressPage Progress;
-// Return true if selected checks pass, false if they don't and the
-// user chooses to delete the file; otherwise throw an exception.
-static bool
-validateCachedPackage (const std::string& fullname, packagesource & pkgsource,
- Feedback , bool check_hash, bool check_size)
-{
- try
-{
- if (check_size)
- pkgsource.check_size_and_cache (fullname);
- if (check_hash)
- pkgsource.check_hash (feedback);
- return true;
-}
- catch (Exception *e)
-{
- pkgsource.set_cached ("");
- const char *filename = fullname.c_str ();
- if (strncmp (filename, "file://", 7) == 0)
- filename += 7;
- if (e->errNo() == APPERR_CORRUPT_PACKAGE
- && yesno (feedback.owner(), IDS_QUERY_CORRUPT, filename) == IDYES)
- remove (filename);
- else
- throw e;
-}
- return false;
-}
-
-/* 0 if not cached; may throw exception if validation fails.
- */
-int
-check_for_cached (packagesource & pkgsource, Feedback ,
- bool mirror_mode, bool check_hash)
-{
- /* If the packagesource doesn't have a filename, it can't possibly be in the
- cache */
- if (!pkgsource.Canonical())
-{
- return 0;
-}
-
- /* Note that the cache dir is represented by a mirror site of
file://local_dir */
- std::string prefix = "file://" + local_dir + "/";
- std::string fullname = prefix + pkgsource.Canonical();
-
- if (mirror_mode)
-{
- /* Just assume correctness of mirror. */
- if (!pkgsource.Cached())
- pkgsource.set_cached (fullname);
- return 1;
-}
-
- // Already found one, which we can assume to have the right size.
- if (pkgsource.Cached())
-{
- if (validateCachedPackage (pkgsource.Cached(), pkgsource, feedback,
-check_hash, false))
- return 1;
- // If we get here, pkgsource.Cached() was corrupt and deleted.
- pkgsource.set_cached ("");
-}
-
- /*
- 1) is there a legacy version in the cache dir available.
- */
- if (io_stream::exists (fullname))
-{
- if (validateCachedPackage (fullname, pkgsource, feedback, check_hash,
true))
- return 1;
- // If we get here, fullname was corrupt and deleted, but it
- // might have been cached.
- pkgsource.set_cached ("");
-}
-
- /*
- 2) is there a version from one of the selected mirror sites available ?
- */
- for (packagesource::sitestype::const_iterator n = pkgsource.sites.begin();
- n != pkgsource.sites.end(); ++n)
- {
-std::string fullname = prefix + rfc1738_escape_part (n->key) + "/" +
- pkgsource.Canonical ();
-if (io_stream::exists(fullname))
- {
- if (validateCachedPackage (fullname, pkgsource, feedback, check_hash,
-true))
- return 1;
- // If we get here, fullname was corrupt and deleted, but it
- // might have been cached.
- pkgsource.set_cached ("");
- }
- }
- return 0;
-}
-
/* download a file from a mirror site to the local cache. */
static int
download_one (packagesource & pkgsource, Feedback )
{
try
{
- if (check_for_cached (pkgsource, feedback))
+ if (pkgsource.check_for_cached(feedback))
return 0;
}
catch (Exception * e)
@@ -295,7 +197,7 @@ do_download_thread (HINSTANCE h, HWND owner)
try
{
- if (!check_for_cached (*version.source(), feedback))
+ if (!(version.source()->check_for_cached(feedback)))
total_download_bytes += version.source()->size;
}
catch (Exception * e)
diff --git a/download.h b/download.h
index 3f65153..e887c92 100644
--- a/download.h
+++ b/download.h
@@ -16,10 +16,4 @@
#ifndef SETUP_DOWNLOAD_H
#define SETUP_DOWNLOAD_H
-#include "Feedback.h"
-
-class packagesource;
-int check_for_cached (packagesource & pkgsource, Feedback ,
[PATCH setup 12/16] Spit out GetNetAuth from NetIO
There's still all kinds of janky stuff here: The network proxy
configuration fetched by ConnectionSetting is stored into static members
of the NetIO class, rather than held there and accessed.
Again, define a virtual class as the interface through which user
interaction takes place, and implement that for GUI and CLI clients.
While we're at it, we arrange for the GUI dialogs for network auth to be
properly parented.
---
GetNetAuth.h | 30 ++
Makefile.am | 2 +
cli/CliGetNetAuth.cc | 45 ++
cli/CliGetNetAuth.h | 32 ++
gui/GuiGetNetAuth.cc | 138 +++
gui/GuiGetNetAuth.h | 38
net.cc | 5 ++
netio.cc | 125 +--
netio.h | 19 ++
nio-ie5.cc | 4 +-
10 files changed, 298 insertions(+), 140 deletions(-)
create mode 100644 GetNetAuth.h
create mode 100644 cli/CliGetNetAuth.cc
create mode 100644 cli/CliGetNetAuth.h
create mode 100644 gui/GuiGetNetAuth.cc
create mode 100644 gui/GuiGetNetAuth.h
diff --git a/GetNetAuth.h b/GetNetAuth.h
new file mode 100644
index 000..0a26e85
--- /dev/null
+++ b/GetNetAuth.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2000, Red Hat, Inc.
+ *
+ * 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 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ * Written by DJ Delorie
+ *
+ */
+
+#ifndef SETUP_GETNETAUTH_H
+#define SETUP_GETNETAUTH_H
+
+class GetNetAuth
+{
+public:
+ /* Helper functions for http/ftp protocols. Both return nonzero for
+ "cancel", zero for "ok". They set net_proxy_user, etc, in
+ state.h */
+ virtual int get_auth () = 0;
+ virtual int get_proxy_auth () = 0;
+ virtual int get_ftp_auth () = 0;
+};
+
+#endif /* SETUP_GETNETAUTH_H */
diff --git a/Makefile.am b/Makefile.am
index de066b7..f257e3a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -182,6 +182,8 @@ endif
gpg-packet.cc \
gpg-packet.h \
gui/GuiParseFeedback.cc \
+ gui/GuiGetNetAuth.cc \
+ gui/GuiGetNetAuth.h \
gui/GuiGetUrlFeedback.cc \
gui/GuiFeedback.h \
ini.cc \
diff --git a/cli/CliGetNetAuth.cc b/cli/CliGetNetAuth.cc
new file mode 100644
index 000..a1fde3b
--- /dev/null
+++ b/cli/CliGetNetAuth.cc
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2000, 2001, Red Hat, Inc.
+ *
+ * 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 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ */
+
+/* Query user for auth information required */
+
+#include "netio.h"
+#include "CliGetNetAuth.h"
+
+#include "LogFile.h"
+
+static int
+auth_common(const char *mode)
+{
+ Log (LOG_PLAIN) << mode << " not implemented" << endLog;
+ Logger ().exit (1);
+ return 1;
+}
+
+int
+CliGetNetAuth::get_auth ()
+{
+ return auth_common("get_auth");
+}
+
+int
+CliGetNetAuth::get_proxy_auth ()
+{
+ return auth_common("get_proxy_auth");
+}
+
+int
+CliGetNetAuth::get_ftp_auth ()
+{
+ return auth_common("get_ftp_auth");
+}
diff --git a/cli/CliGetNetAuth.h b/cli/CliGetNetAuth.h
new file mode 100644
index 000..7ff4520
--- /dev/null
+++ b/cli/CliGetNetAuth.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2000, Red Hat, Inc.
+ *
+ * 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 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ * Written by DJ Delorie
+ *
+ */
+
+#ifndef SETUP_CLI_GETNETAUTH_H
+#define SETUP_CLI_GETNETAUTH_H
+
+#include "GetNetAuth.h"
+
+class CliGetNetAuth : public GetNetAuth
+{
+public:
+ /* Helper functions for http/ftp protocols. Both return nonzero for
+ "cancel", zero for "ok". They set net_proxy_user, etc, in
+ state.h */
+ int get_auth ();
+ int get_proxy_auth ();
+ int get_ftp_auth ();
+};
+
+#endif /* SETUP_CLI_GETNETAUTH_H */
diff --git a/gui/GuiGetNetAuth.cc b/gui/GuiGetNetAuth.cc
new file mode 100644
index 000..a6d4917
--- /dev/null
+++ b/gui/GuiGetNetAuth.cc
@@ -0,0 +1,138 @@
+/*
+ * Copyright (c) 2000, 2001, Red Hat, Inc.
+ *
+ * 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 2 of
[PATCH setup 08/16] Instantiate found_ini_list in ini.cc
This is the list of ini files found by fromcwd.cc:do_from_local_dir().
Maybe that should be unkinked by actually doing that scan inside ini.cc,
where we could have some progress feedback?
This makes it possible to build ini.cc without fromcwd.cc
---
fromcwd.cc | 2 --
ini.cc | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/fromcwd.cc b/fromcwd.cc
index f58e955..c53eede 100644
--- a/fromcwd.cc
+++ b/fromcwd.cc
@@ -105,8 +105,6 @@ private:
std::vector found_ini;
};
-IniList found_ini_list;
-
bool
do_from_local_dir (HINSTANCE h, HWND owner, std::string _dir)
{
diff --git a/ini.cc b/ini.cc
index 09dda13..2b2da10 100644
--- a/ini.cc
+++ b/ini.cc
@@ -56,6 +56,7 @@ std::string ini_setup_version;
static const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
IniList setup_ext_list (setup_exts,
setup_exts + (sizeof(setup_exts) /
sizeof(*setup_exts)));
+IniList found_ini_list;
static BoolOption NoVerifyOption (false, 'X', "no-verify",
IDS_HELPTEXT_NO_VERIFY);
static BoolOption NoVersionCheckOption (false, '\0', "no-version-check",
IDS_HELPTEXT_NO_VERSION_CHECK);
--
2.43.0
[PATCH setup 13/16] Split out hash checking progress reporting
---
Feedback.h | 4
Makefile.am | 2 ++
choose.cc | 4 +++-
cli/CliFeedback.h | 5 +
cli/CliHashCheckFeedback.cc | 30 ++
download.cc | 24
download.h | 6 +++---
gui/GuiFeedback.h | 5 +
gui/GuiHashCheckFeedback.cc | 34 ++
install.cc | 4 +++-
package_db.cc | 6 +++---
package_db.h| 3 ++-
package_meta.cc | 10 +-
package_meta.h | 5 +++--
package_source.cc | 33 ++---
package_source.h| 8 +---
16 files changed, 129 insertions(+), 54 deletions(-)
create mode 100644 cli/CliHashCheckFeedback.cc
create mode 100644 gui/GuiHashCheckFeedback.cc
diff --git a/Feedback.h b/Feedback.h
index 8f603a6..4db7c4a 100644
--- a/Feedback.h
+++ b/Feedback.h
@@ -47,6 +47,10 @@ public:
virtual void fetch_finish (int total_bytes) = 0;
virtual void fetch_fatal (const char *filename, const char *err) = 0;
+ // hash checking
+ virtual void hash_init (const char *hashalg, const std::string ) = 0;
+ virtual void hash_progress (int bytes, int total_bytes) = 0;
+
//
virtual HWND owner () = 0;
};
diff --git a/Makefile.am b/Makefile.am
index f257e3a..def20a4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -67,6 +67,7 @@ inilint_SOURCES = \
filemanip.h \
cli/CliParseFeedback.cc \
cli/CliGetUrlFeedback.cc \
+ cli/CliHashCheckFeedback.cc \
cli/CliFeedback.h \
LogSingleton.cc \
LogSingleton.h \
@@ -186,6 +187,7 @@ endif
gui/GuiGetNetAuth.h \
gui/GuiGetUrlFeedback.cc \
gui/GuiFeedback.h \
+ gui/GuiHashCheckFeedback.cc \
ini.cc \
ini.h \
IniDBBuilder.h \
diff --git a/choose.cc b/choose.cc
index 8deab87..451b390 100644
--- a/choose.cc
+++ b/choose.cc
@@ -50,6 +50,7 @@
#include "package_meta.h"
#include "threebar.h"
+#include "gui/GuiFeedback.h"
#include "Generic.h"
#include "ControlAdjuster.h"
#include "prereq.h"
@@ -317,9 +318,10 @@ void
ChooserPage::OnActivate()
{
SetBusy();
+ GuiFeedback feedback(GetHWND());
packagedb db;
- db.prep();
+ db.prep(feedback);
if (!activated)
{
diff --git a/cli/CliFeedback.h b/cli/CliFeedback.h
index 3bcc23c..cb59650 100644
--- a/cli/CliFeedback.h
+++ b/cli/CliFeedback.h
@@ -48,6 +48,11 @@ private:
unsigned int last_tics;
unsigned int start_tics;
+ // hash checking
+public:
+ void hash_init (const char *hashalg, const std::string );
+ void hash_progress (int bytes, int total_bytes);
+
// owner
public:
HWND owner () { return NULL; }
diff --git a/cli/CliHashCheckFeedback.cc b/cli/CliHashCheckFeedback.cc
new file mode 100644
index 000..f5df9fc
--- /dev/null
+++ b/cli/CliHashCheckFeedback.cc
@@ -0,0 +1,30 @@
+/*
+ *
+ * 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 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ */
+
+#include "cli/CliFeedback.h"
+#include "resource.h"
+#include "String++.h"
+#include
+
+void
+CliFeedback::hash_init(const char *hashalg, const std::string )
+{
+ std::wstring fmt = LoadStringW(IDS_PROGRESS_CHECKING_HASH);
+ std::wstring s = format(fmt, hashalg, shortname.c_str());
+ std::cout << wstring_to_string(s) << std::endl;
+}
+
+void
+CliFeedback::hash_progress(int bytes, int total_bytes)
+{
+ std::cout << bytes << "/" << total_bytes << "\r";
+}
diff --git a/download.cc b/download.cc
index 02fd484..fbe36e5 100644
--- a/download.cc
+++ b/download.cc
@@ -52,14 +52,14 @@ extern ThreeBarProgressPage Progress;
// user chooses to delete the file; otherwise throw an exception.
static bool
validateCachedPackage (const std::string& fullname, packagesource & pkgsource,
- HWND owner, bool check_hash, bool check_size)
+ Feedback , bool check_hash, bool check_size)
{
try
{
if (check_size)
pkgsource.check_size_and_cache (fullname);
if (check_hash)
- pkgsource.check_hash ();
+ pkgsource.check_hash (feedback);
return true;
}
catch (Exception *e)
@@ -69,7 +69,7 @@ validateCachedPackage (const std::string& fullname,
packagesource & pkgsource,
if (strncmp (filename, "file://", 7) == 0)
filename += 7;
if (e->errNo() == APPERR_CORRUPT_PACKAGE
- && yesno (owner, IDS_QUERY_CORRUPT, filename) == IDYES)
+ && yesno (feedback.owner(), IDS_QUERY_CORRUPT, filename) == IDYES)
remove (filename);
else
throw e;
@@ -80,8 +80,8 @@ validateCachedPackage (const
[PATCH setup 09/16] Move is_64bit to state
Note this controls what we will install, not indicating how we are
built, so it's use in splash is questionable, and is downright wrong in
the messages from IniDbBuilderPackage giving URLs for an updated
version of setup.
This controls stuff all over the place!
---
ini.h | 1 -
main.cc | 34 ++
splash.cc | 2 +-
state.cc | 6 ++
state.h | 2 ++
5 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/ini.h b/ini.h
index f1788e2..2ca4f5b 100644
--- a/ini.h
+++ b/ini.h
@@ -23,7 +23,6 @@
typedef std::vector IniList;
extern IniList found_ini_list, setup_ext_list;
-extern bool is_64bit;
extern bool is_new_install;
extern std::string SetupArch;
extern std::string SetupIniDir;
diff --git a/main.cc b/main.cc
index 2ce3b30..c359ba9 100644
--- a/main.cc
+++ b/main.cc
@@ -83,7 +83,6 @@
extern char **_argv;
#endif
-bool is_64bit;
bool is_new_install = false;
std::string SetupArch;
std::string SetupIniDir;
@@ -263,26 +262,21 @@ WinMain (HINSTANCE h,
else if (HelpOption)
help_option = true;
-if (!((std::string) Arch).size ())
+if (((std::string) Arch).size ())
{
-#ifdef __x86_64__
- is_64bit = true;
-#else
- is_64bit = false;
-#endif
- }
-else if (((std::string) Arch).find ("64") != std::string::npos)
- is_64bit = true;
-else if (((std::string) Arch).find ("32") != std::string::npos
-|| ((std::string) Arch).find ("x86") != std::string::npos)
- is_64bit = false;
-else
- {
- char buff[80 + ((std::string) Arch).size ()];
- sprintf (buff, "Invalid option for --arch: \"%s\"",
-((std::string) Arch).c_str ());
- fprintf (stderr, "*** %s\n", buff);
- exit (1);
+if (((std::string) Arch).find ("64") != std::string::npos)
+ is_64bit = true;
+else if (((std::string) Arch).find ("32") != std::string::npos
+ || ((std::string) Arch).find ("x86") != std::string::npos)
+ is_64bit = false;
+else
+ {
+char buff[80 + ((std::string) Arch).size ()];
+sprintf (buff, "Invalid option for --arch: \"%s\"",
+ ((std::string) Arch).c_str ());
+fprintf (stderr, "*** %s\n", buff);
+exit (1);
+ }
}
if (GuiLangOption.isPresent())
diff --git a/splash.cc b/splash.cc
index 40c1334..8b601db 100644
--- a/splash.cc
+++ b/splash.cc
@@ -19,7 +19,7 @@
#include "setup_version.h"
#include "resource.h"
#include "splash.h"
-#include "ini.h"
+#include "state.h"
#define SPLASH_URL "https://cygwin.com;
#define SPLASH_COPYRIGHT "Copyright 2000-2023"
diff --git a/state.cc b/state.cc
index 111b890..ef14116 100644
--- a/state.cc
+++ b/state.cc
@@ -29,3 +29,9 @@ int root_menu;
int root_desktop;
LANGID langid;
+
+#ifdef __x86_64__
+bool is_64bit = true;
+#else
+bool is_64bit = false;
+#endif
diff --git a/state.h b/state.h
index b211de3..c4b88a4 100644
--- a/state.h
+++ b/state.h
@@ -48,4 +48,6 @@ extern int root_desktop;
extern LANGID langid;
+extern bool is_64bit;
+
#endif /* SETUP_STATE_H */
--
2.43.0
[PATCH setup 11/16] Drop hinstance global
We do not need to retain the hInstance value passed into WinMain(), as
it's always available as GetModuleHandle(NULL).
Note that DialogBox() accepts NULL meaning "the current executable" in
any case.
Future work: there's still some completely unnecessary storing it in
class Window and passing it around.
---
dialog.h| 3 ---
gui/SitePage.cc | 3 +--
install.cc | 2 +-
main.cc | 5 +
msg.cc | 5 ++---
netio.cc| 10 +-
6 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/dialog.h b/dialog.h
index 63c98ee..ebbf661 100644
--- a/dialog.h
+++ b/dialog.h
@@ -20,9 +20,6 @@
#include "win32.h"
-/* global instance for the application; set in main.cc */
-extern HINSTANCE hinstance;
-
/* used by main.cc to select the next do_* function */
extern int next_dialog;
diff --git a/gui/SitePage.cc b/gui/SitePage.cc
index 1cdb1bf..9dacebc 100644
--- a/gui/SitePage.cc
+++ b/gui/SitePage.cc
@@ -367,8 +367,7 @@ int check_dropped_mirrors (HWND h)
{
if (unattended_mode)
return CACHE_ACCEPT_WARN;
- return DialogBox (hinstance, MAKEINTRESOURCE (IDD_DROPPED), h,
- drop_proc);
+ return DialogBox (NULL, MAKEINTRESOURCE (IDD_DROPPED), h, drop_proc);
}
return CACHE_ACCEPT_NOWARN;
}
diff --git a/install.cc b/install.cc
index 628dbd0..001529b 100644
--- a/install.cc
+++ b/install.cc
@@ -660,7 +660,7 @@ Installer::_installOne (packagemeta ,
dlg_data.processlist = plm.c_str ();
dlg_data.iteration = iteration;
-rc = DialogBoxParam(hinstance, MAKEINTRESOURCE
(IDD_FILE_INUSE), owner, FileInuseDlgProc, (LPARAM)_data);
+rc = DialogBoxParam(NULL, MAKEINTRESOURCE
(IDD_FILE_INUSE), owner, FileInuseDlgProc, (LPARAM)_data);
}
else
{
diff --git a/main.cc b/main.cc
index 4c391f5..8a68232 100644
--- a/main.cc
+++ b/main.cc
@@ -86,8 +86,6 @@ extern char **_argv;
bool is_new_install = false;
std::string SetupIniDir;
-HINSTANCE hinstance;
-
static StringChoiceOption::StringChoices symlink_types({
{"native", SymlinkTypeNative},
{"lnk", SymlinkTypeShortcut},
@@ -176,7 +174,7 @@ main_display ()
}
// Init window class lib
- Window::SetAppInstance (hinstance);
+ Window::SetAppInstance (GetModuleHandle(NULL));
// Create pages
Splash.Create ();
@@ -221,7 +219,6 @@ int WINAPI
WinMain (HINSTANCE h,
HINSTANCE hPrevInstance, LPSTR command_line, int cmd_show)
{
- hinstance = h;
// Make sure Windows DLLs only delay-load further DLLs from System32
typedef BOOL (WINAPI *PFNSETDEFAULTDLLDIRECTORIES)(DWORD);
diff --git a/msg.cc b/msg.cc
index 8e344ff..b53df86 100644
--- a/msg.cc
+++ b/msg.cc
@@ -23,7 +23,6 @@
#include
#include
-#include "dialog.h"
#include "state.h"
#include "String++.h"
#include "resource.h"
@@ -66,7 +65,7 @@ mbox (HWND owner, const char *buf, const char *name, int type)
}
char caption[32];
- LoadString (hinstance, IDS_MBOX_CAPTION, caption, sizeof (caption));
+ LoadString (GetModuleHandle(NULL), IDS_MBOX_CAPTION, caption, sizeof
(caption));
return MessageBox (owner, buf, caption, type);
}
@@ -76,7 +75,7 @@ mbox (HWND owner, const char *name, int type, int id, va_list
args)
{
char buf[1000], fmt[1000];
- if (LoadString (hinstance, id, fmt, sizeof (fmt)) <= 0)
+ if (LoadString (GetModuleHandle(NULL), id, fmt, sizeof (fmt)) <= 0)
ExitProcess (0);
vsnprintf (buf, 1000, fmt, args);
diff --git a/netio.cc b/netio.cc
index 631532a..d6bfc24 100644
--- a/netio.cc
+++ b/netio.cc
@@ -185,9 +185,9 @@ auth_proc (HWND h, UINT message, WPARAM wParam, LPARAM
lParam)
}
static int
-auth_common (HINSTANCE h, int id, HWND owner)
+auth_common (int id, HWND owner)
{
- return DialogBox (h, MAKEINTRESOURCE (id), owner, auth_proc);
+ return DialogBox (NULL, MAKEINTRESOURCE (id), owner, auth_proc);
}
int
@@ -195,7 +195,7 @@ NetIO::get_auth (HWND owner)
{
user = _user;
passwd = _passwd;
- return auth_common (hinstance, IDD_NET_AUTH, owner);
+ return auth_common (IDD_NET_AUTH, owner);
}
int
@@ -203,7 +203,7 @@ NetIO::get_proxy_auth (HWND owner)
{
user = _proxy_user;
passwd = _proxy_passwd;
- return auth_common (hinstance, IDD_PROXY_AUTH, owner);
+ return auth_common (IDD_PROXY_AUTH, owner);
}
int
@@ -221,7 +221,7 @@ NetIO::get_ftp_auth (HWND owner)
}
user = _ftp_user;
passwd = _ftp_passwd;
- return auth_common (hinstance, IDD_FTP_AUTH, owner);
+ return auth_common (IDD_FTP_AUTH, owner);
}
const char *
--
2.43.0
[PATCH setup 07/16] Split out URL fetching progress reporting
lderPackage.h b/IniDBBuilderPackage.h
index 3e3a9e4..0f59257 100644
--- a/IniDBBuilderPackage.h
+++ b/IniDBBuilderPackage.h
@@ -24,13 +24,13 @@
#include "String++.h"
#include "libsolv.h"
-class IniParseFeedback;
+class Feedback;
class packagesource;
class IniDBBuilderPackage:public IniDBBuilder
{
public:
- IniDBBuilderPackage (IniParseFeedback const &);
+ IniDBBuilderPackage (Feedback const &);
~IniDBBuilderPackage ();
void buildTimestamp (const std::string& );
@@ -88,7 +88,7 @@ private:
SolverPool::addPackageData cbpv;
std::set replace_versions;
- IniParseFeedback const &_feedback;
+ Feedback const &_feedback;
bool minimum_version_checked;
};
diff --git a/IniParseFeedback.h b/IniParseFeedback.h
deleted file mode 100644
index c3c7803..000
--- a/IniParseFeedback.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Copyright (c) 2002 Robert Collins.
- *
- * 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 2 of the License, or
- * (at your option) any later version.
- *
- * A copy of the GNU General Public License can be found at
- * http://www.gnu.org/
- *
- * Written by Robert Collins
- *
- */
-
-#ifndef SETUP_INIPARSEFEEDBACK_H
-#define SETUP_INIPARSEFEEDBACK_H
-
-
-#include
-/* Strategy for feedback from IniParsing.
- * Used by the builder or parsing classes to send feedback that users need
- * but that should not interrupt parsing.
- * Fatal errors are thrown as exceptions.
- */
-class IniParseFeedback
-{
-public:
- virtual void progress (unsigned long const, unsigned long const) = 0;
- virtual void iniName (const std::string& ) = 0;
- virtual void babble (const std::string& ) const = 0;
- virtual void warning (const std::string& ) const = 0;
- virtual void show_errors () const = 0;
- virtual void note_error(int lineno, const std::string ) = 0;
- virtual bool has_errors () const = 0;
-};
-
-#endif /* SETUP_INIPARSEFEEDBACK_H */
diff --git a/Makefile.am b/Makefile.am
index f753961..de066b7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -65,8 +65,9 @@ inilint_LDADD = \
inilint_SOURCES = \
filemanip.cc \
filemanip.h \
- CliParseFeedback.cc \
- CliParseFeedback.h \
+ cli/CliParseFeedback.cc \
+ cli/CliGetUrlFeedback.cc \
+ cli/CliFeedback.h \
LogSingleton.cc \
LogSingleton.h \
IniDBBuilder.h \
@@ -181,6 +182,8 @@ endif
gpg-packet.cc \
gpg-packet.h \
gui/GuiParseFeedback.cc \
+ gui/GuiGetUrlFeedback.cc \
+ gui/GuiFeedback.h \
ini.cc \
ini.h \
IniDBBuilder.h \
@@ -188,7 +191,7 @@ endif
IniDBBuilderPackage.h \
inilex.ll \
iniparse.yy \
- IniParseFeedback.h \
+ Feedback.h \
install.cc \
io_stream.cc \
io_stream.h \
diff --git a/CliParseFeedback.h b/cli/CliFeedback.h
similarity index 52%
rename from CliParseFeedback.h
rename to cli/CliFeedback.h
index a19659e..3bcc23c 100644
--- a/CliParseFeedback.h
+++ b/cli/CliFeedback.h
@@ -11,11 +11,14 @@
*
*/
-#include "IniParseFeedback.h"
+#include "Feedback.h"
-class CliParseFeedback : public IniParseFeedback
+class CliFeedback : public Feedback
{
+ // ini parse
public:
+ virtual void parse_init ();
+ virtual void parse_finish ();
virtual void progress (unsigned long const pos, unsigned long const max);
virtual void iniName (const std::string& name);
virtual void babble (const std::string& message) const;
@@ -25,4 +28,28 @@ public:
virtual bool has_errors () const;
private:
int error_count = 0;
+
+ // URL fetch
+public:
+ void fetch_progress_disable (bool);
+ void fetch_init (const std::string , int length);
+ void fetch_set_length(int length);
+ void fetch_set_total_length(long long int total_length);
+ void fetch_progress (int bytes);
+ void fetch_total_progress ();
+ void fetch_finish (int total_bytes);
+ void fetch_fatal (const char *filename, const char *err);
+
+private:
+ int max_bytes;
+ long long int total_download_bytes = 0; // meaning ???
+ long long int total_download_bytes_sofar = 0;
+
+ unsigned int last_tics;
+ unsigned int start_tics;
+
+ // owner
+public:
+ HWND owner () { return NULL; }
+
};
diff --git a/cli/CliGetUrlFeedback.cc b/cli/CliGetUrlFeedback.cc
new file mode 100644
index 000..1256118
--- /dev/null
+++ b/cli/CliGetUrlFeedback.cc
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2024 Jon Turney
+ *
+ * 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 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found
[PATCH setup 06/16] Simplify invocation of UserSettings::open_settings()
Simplify how we check for a setup.rc settings file in the local cache
dir (Who knew that setup even did this?): pass the directory down to
UserSettings::open_settings() as a parameter, rather than by storing it
in an (otherwise unused) member.
Also: rename the 'cwd' parameter, because it's actually an arbitrary
directory, not the cwd.
(Archeology seems to indicate that at one stage we'd save settings in
the cwd if we needed to write them before the cygwin root was known, and
migrate that file to the cygwin root when it becomes known; then we
changed to keeping that file in the cache dir, then we forgot to migrate
it, so perhaps all this complexity isn't needed?)
---
UserSettings.cc | 12 +++-
UserSettings.h | 4 +---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/UserSettings.cc b/UserSettings.cc
index c8ddd3d..3ec6798 100644
--- a/UserSettings.cc
+++ b/UserSettings.cc
@@ -65,14 +65,17 @@ UserSettings::extend_table (ssize_t i)
}
io_stream *
-UserSettings::open_settings (const char *filename, std::string )
+UserSettings::open_settings (const char *filename, std::string ,
std::string )
{
+ // first look for a settings file in specified dir
pathname = "file://";
- pathname += cwd;
- if (!isdirsep (cwd[cwd.size () - 1]) && !isdirsep (filename[0]))
+ pathname += dir;
+ if (!isdirsep (dir[dir.size () - 1]) && !isdirsep (filename[0]))
pathname += "/";
pathname += filename;
io_stream *f = io_stream::open(pathname, "rt", 0);
+
+ // if not found, look in cygwin installation
if (!f)
{
pathname = "cygfile:///etc/setup/";
@@ -92,8 +95,7 @@ UserSettings::UserSettings ()
void
UserSettings::load (std::string local_dir)
{
- cwd = local_dir;
- io_stream *f = open_settings ("setup.rc", filename);
+ io_stream *f = open_settings ("setup.rc", local_dir, filename);
if (!f)
return;
diff --git a/UserSettings.h b/UserSettings.h
index 3de06e1..dc06ab2 100644
--- a/UserSettings.h
+++ b/UserSettings.h
@@ -27,7 +27,6 @@ private:
ssize_t table_len;
std::string filename;
- std::string cwd;
public:
static class UserSettings *global;
@@ -44,8 +43,7 @@ public:
private:
void extend_table (ssize_t);
- io_stream *open_settings (const char *, std::string&);
-
+ io_stream *open_settings (const char *, std::string &, std::string&);
};
#endif // SETUP_USERSETTINGS_H
--
2.43.0
[PATCH setup 10/16] Move setup.ini pathame components to ini.cc
Move SetupBaseNameOption to ini.cc
Eliminate SetupIniDir, it's just SetupArch + "/"
Change SetupArch() and SetupBaseName() into functions, to avoid having
to do global initialization at the right time.
---
fromcwd.cc | 8
ini.cc | 22 +-
ini.h | 5 ++---
main.cc| 8
4 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/fromcwd.cc b/fromcwd.cc
index c53eede..b1f1021 100644
--- a/fromcwd.cc
+++ b/fromcwd.cc
@@ -52,7 +52,7 @@ public:
ext != setup_ext_list.end ();
ext++, fi++)
{
- if (!casecompare (SetupBaseName + "." + *ext, theFile->cFileName))
+ if (!casecompare (SetupBaseName() + "." + *ext,
theFile->cFileName))
*fi = true;
}
}
@@ -62,7 +62,7 @@ public:
{
if (level <= 0)
return;
-inidir = !casecompare (SetupArch, aDir->cFileName);
+inidir = !casecompare (SetupArch(), aDir->cFileName);
if (level == 1 && !inidir)
return;
Find aFinder (basePath + aDir->cFileName);
@@ -74,8 +74,8 @@ public:
{
if (*fi)
{
- found_ini_list.push_back (basePath + SetupArch + "/"
- + SetupBaseName + "." + *ext);
+ found_ini_list.push_back (basePath + SetupArch() + "/"
+ + SetupBaseName() + "." + *ext);
/*
* Terminate the search after the first setup file
* found, which shadows any setup files with
diff --git a/ini.cc b/ini.cc
index 2b2da10..42df6a3 100644
--- a/ini.cc
+++ b/ini.cc
@@ -44,6 +44,7 @@
#include "io_stream_memory.h"
#include "getopt++/BoolOption.h"
+#include "getopt++/StringOption.h"
#include "IniDBBuilderPackage.h"
#include "compress.h"
#include "msg.h"
@@ -58,10 +59,21 @@ IniList setup_ext_list (setup_exts,
setup_exts + (sizeof(setup_exts) /
sizeof(*setup_exts)));
IniList found_ini_list;
+static StringOption SetupBaseNameOption ("setup", 'i', "ini-basename",
IDS_HELPTEXT_INI_BASENAME, false);
static BoolOption NoVerifyOption (false, 'X', "no-verify",
IDS_HELPTEXT_NO_VERIFY);
static BoolOption NoVersionCheckOption (false, '\0', "no-version-check",
IDS_HELPTEXT_NO_VERSION_CHECK);
+std::string SetupArch()
+{
+ return is_64bit ? "x86_64" : "x86";
+}
+
+std::string SetupBaseName()
+{
+ return SetupBaseNameOption;
+}
+
static io_stream*
decompress_ini (io_stream *ini_file, std::string _ini_name)
{
@@ -170,7 +182,7 @@ do_local_ini (Feedback )
if (!ini_file || sig_fail)
{
// no setup found or signature invalid
- note (myFeedback.owner(), IDS_SETUPINI_MISSING, SetupBaseName.c_str
(),
+ note (myFeedback.owner(), IDS_SETUPINI_MISSING, SetupBaseName().c_str
(),
"localdir");
ini_error = true;
}
@@ -180,7 +192,7 @@ do_local_ini (Feedback )
myFeedback.babble ("Found ini file - " + current_ini_name);
myFeedback.iniName (current_ini_name);
int ldl = local_dir.length () + 1;
- int cap = current_ini_name.rfind ("/" + SetupArch);
+ int cap = current_ini_name.rfind ("/" + SetupArch());
aBuilder.parse_mirror =
rfc1738_unescape (current_ini_name.substr (ldl, cap - ldl));
ini_init (ini_file, , myFeedback);
@@ -225,7 +237,7 @@ do_remote_ini (Feedback )
ext++)
{
current_ini_ext = *ext;
- current_ini_name = n->url + SetupIniDir + SetupBaseName + "." +
current_ini_ext;
+ current_ini_name = n->url + SetupArch() + "/" + SetupBaseName() + "."
+ current_ini_ext;
current_ini_sig_name = current_ini_name + ".sig";
ini_sig_file = get_url_to_membuf (current_ini_sig_name, myFeedback);
ini_file = get_url_to_membuf (current_ini_name, myFeedback);
@@ -240,7 +252,7 @@ do_remote_ini (Feedback )
if (!ini_file || sig_fail)
{
// no setup found or signature invalid
- note (myFeedback.owner(), IDS_SETUPINI_MISSING, SetupBaseName.c_str
(), n->url.c_str ());
+ note (myFeedback.owner(), IDS_SETUPINI_MISSING, SetupBaseName().c_str
(), n->url.c_str ());
ini_error = true;
}
else
@@ -260,7 +272,7 @@ do_remote_ini (Feedback )
/* save known-good setup.ini locally */
const std::string fp = "file://" + local_dir + "/" +
rfc1738_escape_part (n->url) +
- "/" + SetupIniDir + SetupBaseName +
".ini";
+ "/" + SetupArch() + "/" + SetupBaseName()
+ ".ini";
io_stream::mkpath_p (PATH_TO_FILE, fp, 0);
if (io_stream *out = io_stream::open (fp, "wb", 0))
{
diff --git a/ini.h b/ini.h
index 2ca4f5b..05b31e0 100644
--- a/ini.h
+++ b/ini.h
@@ -24,9 +24,8 @@ typedef std::vector IniList;
[PATCH setup 03/16] Split GuiParseFeedback out from ini fetcher
This will ultimately make it possible to fetch and parse an ini file
without having a GUI.
---
Makefile.am | 1 +
gui/GuiParseFeedback.cc | 139
ini.cc | 134 ++
ini.h | 2 +
4 files changed, 149 insertions(+), 127 deletions(-)
create mode 100644 gui/GuiParseFeedback.cc
diff --git a/Makefile.am b/Makefile.am
index 8a50cb0..82efbd8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -180,6 +180,7 @@ endif
geturl.h \
gpg-packet.cc \
gpg-packet.h \
+ gui/GuiParseFeedback.cc \
ini.cc \
ini.h \
IniDBBuilder.h \
diff --git a/gui/GuiParseFeedback.cc b/gui/GuiParseFeedback.cc
new file mode 100644
index 000..263fae1
--- /dev/null
+++ b/gui/GuiParseFeedback.cc
@@ -0,0 +1,139 @@
+/*
+ * Copyright (c) 2000,2007 Red Hat, Inc.
+ *
+ * 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 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ * Written by DJ Delorie
+ *
+ */
+
+#include "Exception.h"
+#include "IniParseFeedback.h"
+#include "ini.h"
+#include "msg.h"
+#include "resource.h"
+#include "state.h"
+#include "threebar.h"
+
+extern ThreeBarProgressPage Progress;
+
+class GuiParseFeedback : public IniParseFeedback
+{
+public:
+ GuiParseFeedback () : lastpct (0)
+{
+ Progress.SetText1 (IDS_PROGRESS_PARSING);
+ Progress.SetText2 ("");
+ Progress.SetText3 ("");
+ Progress.SetText4 (IDS_PROGRESS_PROGRESS);
+
+ yyerror_count = 0;
+ yyerror_messages.clear ();
+}
+ virtual void progress (unsigned long const pos, unsigned long const max)
+{
+ if (!max)
+/* length not known or eof */
+return;
+ if (lastpct == 100)
+/* rounding down should mean this only ever fires once */
+lastpct = 0;
+ if (pos * 100 / max > lastpct)
+{
+ lastpct = pos * 100 / max;
+ /* Log (LOG_BABBLE) << lastpct << "% (" << pos << " of " << max
+<< " bytes of ini file read)" << endLog; */
+}
+ Progress.SetBar1 (pos, max);
+
+ static char buf[100];
+ sprintf (buf, "%d %% (%ldk/%ldk)", lastpct, pos/1000, max/1000);
+ Progress.SetText3 (buf);
+}
+ virtual void iniName (const std::string& name)
+{
+ Progress.SetText2 (name.c_str ());
+ Progress.SetText3 ("");
+ filename = name;
+}
+ virtual void babble (const std::string& message)const
+{
+ Log (LOG_BABBLE) << message << endLog;
+}
+ virtual void warning (const std::string& message)const
+{
+ mbox (Progress.GetHWND(), message.c_str (), "Warning", 0);
+}
+ virtual void note_error(int lineno, const std::string )
+{
+ char tmp[16];
+ sprintf (tmp, "%d", lineno);
+
+ std::string e = filename + " line " + tmp + ": " + error;
+
+ if (!yyerror_messages.empty ())
+yyerror_messages += "\n";
+
+ yyerror_messages += e;
+ yyerror_count++;
+}
+ virtual bool has_errors () const
+{
+ return (yyerror_count > 0);
+}
+ virtual void show_errors () const
+{
+ mbox (Progress.GetHWND(), yyerror_messages.c_str (), "Parse Errors", 0);
+}
+ virtual ~ GuiParseFeedback ()
+{
+ Progress.SetText2 ("");
+ Progress.SetText3 ("");
+ Progress.SetText4 (IDS_PROGRESS_PACKAGE);
+ Progress.SetBar1 (0);
+}
+private:
+ unsigned int lastpct;
+ std::string filename;
+ std::string yyerror_messages;
+ int yyerror_count;
+};
+
+static DWORD WINAPI
+do_ini_thread_reflector (void* p)
+{
+ HANDLE *context;
+ context = (HANDLE*)p;
+
+ SetThreadUILanguage(langid);
+
+ try
+ {
+GuiParseFeedback feedback;
+bool succeeded = do_ini_thread ((HINSTANCE)context[0], (HWND)context[1],
feedback);
+
+// Tell the progress page that we're done downloading
+Progress.PostMessageNow (WM_APP_SETUP_INI_DOWNLOAD_COMPLETE, 0, succeeded);
+ }
+ TOPLEVEL_CATCH ((HWND) context[1], "ini");
+
+ ExitThread (0);
+}
+
+static HANDLE context[2];
+
+void
+do_ini (HINSTANCE h, HWND owner)
+{
+ context[0] = h;
+ context[1] = owner;
+
+ DWORD threadID;
+ CreateThread (NULL, 0, do_ini_thread_reflector, context, 0, );
+}
diff --git a/ini.cc b/ini.cc
index 112a0ad..95c9964 100644
--- a/ini.cc
+++ b/ini.cc
@@ -33,7 +33,6 @@
#include
#include "resource.h"
-#include "state.h"
#include "geturl.h"
#include "dialog.h"
#include "mount.h"
@@ -44,17 +43,13 @@
#include "io_stream.h"
#include "io_stream_memory.h"
-#include "threebar.h"
-
#include "getopt++/BoolOption.h"
#include "IniDBBuilderPackage.h"
#include "compress.h"
-#include "Exception.h"
+#include "msg.h"
#include "crypto.h"
#include
[PATCH setup 04/16] Split out site into SiteSettings and SitePage
Again, this will ultimately make it possible to specify, or store and
retrieve from settings a site, without having a GUI.
---
Makefile.am| 6 +-
SiteSetting.cc | 193 +
site.h => SiteSetting.h| 57 +++
site.cc => gui/SitePage.cc | 169 +---
gui/SitePage.h | 45 +
ini.cc | 2 +-
main.cc| 3 +-
threebar.cc| 2 +-
8 files changed, 264 insertions(+), 213 deletions(-)
create mode 100644 SiteSetting.cc
rename site.h => SiteSetting.h (74%)
rename site.cc => gui/SitePage.cc (77%)
create mode 100644 gui/SitePage.h
diff --git a/Makefile.am b/Makefile.am
index 82efbd8..f753961 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -266,8 +266,10 @@ endif
setup_version.c \
sha2.h \
sha2.c \
- site.cc \
- site.h \
+ gui/SitePage.cc \
+ gui/SitePage.h \
+ SiteSetting.cc \
+ SiteSetting.h \
source.cc \
source.h \
SourceSetting.cc \
diff --git a/SiteSetting.cc b/SiteSetting.cc
new file mode 100644
index 000..be5f5d8
--- /dev/null
+++ b/SiteSetting.cc
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2000, Red Hat, Inc.
+ *
+ * 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 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ * Written by DJ Delorie
+ *
+ */
+
+#include "io_stream.h"
+#include "SiteSetting.h"
+#include "UserSettings.h"
+#include "getopt++/StringArrayOption.h"
+#include "getopt++/BoolOption.h"
+#include "resource.h"
+
+#include
+#include
+#include
+#include
+
+StringArrayOption SiteOption('s', "site", IDS_HELPTEXT_SITE);
+extern BoolOption UnsupportedOption;
+
+/* Selected sites */
+SiteList site_list;
+
+/* Fresh mirrors + selected sites */
+SiteList all_site_list;
+
+SiteSetting::SiteSetting (): saved (false)
+{
+ std::vector SiteOptionStrings = SiteOption;
+ if (SiteOptionStrings.size())
+{
+ for (std::vector::const_iterator n =
SiteOptionStrings.begin ();
+ n != SiteOptionStrings.end (); ++n)
+registerSavedSite (n->c_str ());
+}
+ else
+getSavedSites ();
+}
+
+const char *
+SiteSetting::lastMirrorKey ()
+{
+ if (UnsupportedOption)
+return "last-mirror-unsupported";
+
+ return "last-mirror";
+}
+
+void
+SiteSetting::save()
+{
+ io_stream *f = UserSettings::instance().open (lastMirrorKey ());
+ if (f)
+{
+ for (SiteList::const_iterator n = site_list.begin ();
+ n != site_list.end (); ++n)
+*f << n->url;
+ delete f;
+}
+ saved = true;
+}
+
+SiteSetting::~SiteSetting ()
+{
+ if (!saved)
+save ();
+}
+
+/* List of machines that should not be used by default when saved
+ in "last-mirror". */
+#define NOSAVE1 "ftp://sourceware.org/;
+#define NOSAVE1_LEN (sizeof (NOSAVE2) - 1)
+#define NOSAVE2 "ftp://sources.redhat.com/;
+#define NOSAVE2_LEN (sizeof (NOSAVE1) - 1)
+#define NOSAVE3 "ftp://gcc.gnu.org/;
+#define NOSAVE3_LEN (sizeof (NOSAVE3) - 1)
+
+void
+SiteSetting::registerSavedSite (const char * site)
+{
+ site_list_type tempSite(site, "", "", "", false);
+
+ /* Don't default to certain machines if they suffer from bandwidth
+ limitations. */
+ if (strnicmp (site, NOSAVE1, NOSAVE1_LEN) == 0
+ || strnicmp (site, NOSAVE2, NOSAVE2_LEN) == 0
+ || strnicmp (site, NOSAVE3, NOSAVE3_LEN) == 0)
+return;
+
+ site_list_insert (all_site_list, tempSite);
+ site_list.push_back (tempSite);
+}
+
+void
+SiteSetting::getSavedSites ()
+{
+ const char *buf = UserSettings::instance().get (lastMirrorKey ());
+ if (!buf)
+return;
+ char *fg_ret = strdup (buf);
+ for (char *site = strtok (fg_ret, "\n"); site; site = strtok (NULL, "\n"))
+registerSavedSite (site);
+ free (fg_ret);
+}
+
+site_list_type::site_list_type (const std::string &_url,
+const std::string &_servername,
+const std::string &_area,
+const std::string &_location,
+bool _from_mirrors_lst,
+bool _noshow /* default: false */)
+{
+ url = _url;
+ servername = _servername;
+ area = _area;
+ location = _location;
+ from_mirrors_lst = _from_mirrors_lst;
+ noshow = _noshow;
+
+ /* Canonicalize URL to ensure it ends with a '/' */
+ if (url.at(url.length()-1) != '/')
+url.append("/");
+
+ /* displayed_url is protocol and site name part of url */
+ std::string::size_type path_offset = url.find ("/", url.find ("//") + 2);
+ displayed_url = url.substr(0, path_offset);
+
+ /* the sorting key is hostname components in reverse order (to sort by
[PATCH setup 05/16] Don't call Antivirus::AtExit() directly from Logger::exit()
The call to Antivirus::AtExit() needs to be take place before we write
the log, so we see in the log if it failed. But calling it directly from
Logger::exit() is a horrible layering violation, which makes it
impossible to use the logger in other executables...
Add LogFile::atexit() method, which registers atexit handlers which are
run by LogFile::exit() before the log is closed.
The real solution here is probably not to exit via Logger::exit() all
over the place. And also perhaps to switch logfile writing from
"defered" to "immediate" once the root directory has been selected
(which establishes where the logfile should be written).
Also update a comment, out of date since 5fa64c3c.
---
AntiVirus.cc | 4 ++--
LogFile.cc | 18 +-
LogFile.h| 8 ++--
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/AntiVirus.cc b/AntiVirus.cc
index cc416cc..cb8e8ee 100644
--- a/AntiVirus.cc
+++ b/AntiVirus.cc
@@ -16,8 +16,7 @@
#include "AntiVirus.h"
#include "getopt++/BoolOption.h"
-
-#include "LogSingleton.h"
+#include "LogFile.h"
#include "win32.h"
#include
@@ -77,6 +76,7 @@ bool
AntiVirusPage::Create ()
{
detect();
+Logger().atexit(AntiVirus::AtExit);
return PropertyPage::Create (NULL, dialog_cmd, IDD_VIRUS);
}
diff --git a/LogFile.cc b/LogFile.cc
index ab2e3ec..0022eff 100644
--- a/LogFile.cc
+++ b/LogFile.cc
@@ -28,7 +28,6 @@
#include
#include
#include
-#include "AntiVirus.h"
#include "filemanip.h"
#include "String++.h"
#include "getopt++/BoolOption.h"
@@ -115,12 +114,21 @@ LogFile::getFileName (int level) const
return "";
}
+void
+LogFile::atexit(void (*func)(void))
+{
+ exit_fns.push_back(func);
+}
+
void
LogFile::exit (int exit_code, bool show_end_install_msg)
{
- AntiVirus::AtExit();
+ /* Execute any functions we want to run at exit (we don't use stdlib atexit()
+ because we want to allow them to potentially write to the log) */
+ for (auto i = exit_fns.rbegin(); i != exit_fns.rend(); ++i)
+ (*i)();
+
static int been_here = 0;
- /* Exitcode -1 is special... */
if (been_here)
::exit (exit_code);
been_here = 1;
@@ -132,8 +140,8 @@ LogFile::exit (int exit_code, bool show_end_install_msg)
Log (LOG_PLAIN) << "note: " << wstring_to_string(buf) << endLog;
}
- /* ... in that it skips the boring log messages. Exit code -1 is used when
- just printing the help output and when we're self-elevating. */
+ /* Skip the log messages when just printing the help/version output, and when
+ we're self-elevating. */
if (show_end_install_msg)
Log (LOG_TIMESTAMP) << "Ending cygwin install" << endLog;
diff --git a/LogFile.h b/LogFile.h
index ddbc2dc..8efa1b0 100644
--- a/LogFile.h
+++ b/LogFile.h
@@ -18,6 +18,7 @@
#include "LogSingleton.h"
#include
+#include
// Logging class. Default logging level is PLAIN.
class LogFile : public LogSingleton {
@@ -36,18 +37,21 @@ public:
* but doesn't call generic C++ destructors
*/
virtual void exit (int exit_code, bool show_end_install_msg = true)
- __attribute__ ((noreturn));
+ __attribute__ ((noreturn));
+ virtual void atexit( void (*func)(void));
+
virtual void flushAll ();
virtual ~LogFile();
// get a specific verbosity stream.
virtual std::ostream () (enum log_level level);
-
+
protected:
LogFile(std::stringbuf *aStream);
LogFile (LogFile const &); // no copy constructor
LogFile = (LogFile const&); // no assignment operator
virtual void endEntry(); // the current in-progress entry is complete.
static int exit_msg;
+ std::vector exit_fns;
private:
void log_save (int babble, const std::string& filename, bool append);
};
--
2.43.0
[PATCH setup 02/16] Move setup_exts[] to the only place it's used
---
ini.cc | 1 +
ini.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/ini.cc b/ini.cc
index 3ef1311..112a0ad 100644
--- a/ini.cc
+++ b/ini.cc
@@ -58,6 +58,7 @@ extern ThreeBarProgressPage Progress;
unsigned int setup_timestamp = 0;
std::string ini_setup_version;
// TODO: use C++11x initializer lists instead and drop the literal array
+static const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
IniList setup_ext_list (setup_exts,
setup_exts + (sizeof(setup_exts) /
sizeof(*setup_exts)));
diff --git a/ini.h b/ini.h
index d4eaf87..4088968 100644
--- a/ini.h
+++ b/ini.h
@@ -21,7 +21,7 @@
typedef std::vector IniList;
extern IniList found_ini_list, setup_ext_list;
-const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
+
extern bool is_64bit;
extern bool is_new_install;
extern std::string SetupArch;
--
2.43.0
[PATCH setup 01/16] Drop forward declaration of non-existent class IniState
Also: move forward declaration of class io_stream after includes with other forward declarations. --- ini.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ini.h b/ini.h index ecc4b78..d4eaf87 100644 --- a/ini.h +++ b/ini.h @@ -16,7 +16,6 @@ #ifndef SETUP_INI_H #define SETUP_INI_H -class io_stream; #include #include @@ -29,10 +28,11 @@ extern std::string SetupArch; extern std::string SetupIniDir; extern std::string SetupBaseName; -class IniState; +class io_stream; class IniDBBuilder; class IniParseFeedback; void ini_init (io_stream *, IniDBBuilder *, IniParseFeedback &); + #define YYSTYPE char * /* When setup.ini is parsed, the information is stored according to -- 2.43.0
[PATCH setup 00/16] Groundwork for a GUI-less installation tool
This is patch sequence I started sometime in 2020, but only got around to finishing off recently. This includes various small tidy-ups, and then lays some groundwork for a command line installation tool. At the moment, all this can do is retrieve a (compressed) setup.ini from a selected mirror and parse it. Package fetching and installation etc. remain to be looked at. Jon Turney (16): Drop forward declaration of non-existent class IniState Move setup_exts[] to the only place it's used Split GuiParseFeedback out from ini fetcher Split out site into SiteSettings and SitePage Don't call Antivirus::AtExit() directly from Logger::exit() Simplify invocation of UserSettings::open_settings() Split out URL fetching progress reporting Instantiate found_ini_list in ini.cc Move is_64bit to state Move setup.ini pathame components to ini.cc Drop hinstance global Spit out GetNetAuth from NetIO Split out hash checking progress reporting Push check_for_cached into package_source Put various shared subcomponents into a convenience library Add beginnings of a command line installation tool AntiVirus.cc | 4 +- CliParseFeedback.h| 28 -- Feedback.h| 58 GetNetAuth.h | 30 ++ IniDBBuilderPackage.cc| 4 +- IniDBBuilderPackage.h | 6 +- IniParseFeedback.h| 38 --- LogFile.cc| 18 +- LogFile.h | 8 +- Makefile.am | 284 ++ SiteSetting.cc| 193 site.h => SiteSetting.h | 57 +--- UserSettings.cc | 12 +- UserSettings.h| 4 +- choose.cc | 4 +- cli/CliFeedback.h | 60 cli/CliGetNetAuth.cc | 45 +++ cli/CliGetNetAuth.h | 32 ++ cli/CliGetUrlFeedback.cc | 91 ++ cli/CliHashCheckFeedback.cc | 30 ++ .../CliParseFeedback.cc | 28 +- cli/cyclops.cc| 186 crypto.cc | 18 +- crypto.h | 9 +- dialog.h | 3 - download.cc | 121 +--- download.h| 6 - fromcwd.cc| 11 +- geturl.cc | 130 ++-- geturl.h | 13 +- gui/GuiFeedback.h | 69 + gui/GuiGetNetAuth.cc | 138 + gui/GuiGetNetAuth.h | 38 +++ gui/GuiGetUrlFeedback.cc | 119 gui/GuiHashCheckFeedback.cc | 34 +++ gui/GuiParseFeedback.cc | 149 + site.cc => gui/SitePage.cc| 191 +--- gui/SitePage.h| 45 +++ ini.cc| 178 +++ ini.h | 19 +- inilex.ll | 6 +- inilintmain.cc| 10 +- install.cc| 6 +- main.cc | 50 ++- msg.cc| 5 +- net.cc| 5 + netio.cc | 125 +--- netio.h | 19 +- nio-ie5.cc| 4 +- package_db.cc | 6 +- package_db.h | 3 +- package_meta.cc | 11 +- package_meta.h| 5 +- package_source.cc | 126 ++-- package_source.h | 12 +- splash.cc | 2 +- state.cc | 6 + state.h | 2 + threebar.cc | 2 +- 59 files changed, 1853 insertions(+), 1063 deletions(-) delete mode 100644 CliParseFeedback.h create mode 100644 Feedback.h create mode 100644 GetNetAuth.h delete mode 100644 IniParseFeedback.h create mode 100644 SiteSetting.cc rename site.h => SiteSetting.h (74%) create mode 100644 cli/CliFeedback.h create mode 100644 cli/CliGetNetAuth.cc create mode 100644 cli/CliGetNetAuth.h create mode 100644 cli/CliGetUrlFeedback.cc create mo
Re: [ITP] afflib 3.7.20-1
On 06/03/2024 15:39, Christian Franke via Cygwin-apps wrote: Jon Turney wrote: Thanks! libafflib_CONTENTS=" usr/bin/cygafflib-*.dll Any reason why this package doesn't include the soversion, i.e. why not libafflib0? Libtsk and libafflib are my first library packages, so I'm not sure what the policy is. My recent package libtsk has been accepted without soversion, so I omitted it also here. I assumed that the soversion will I'm going to suggest that was an oversight in the review. be added only when needed for new not backward compatible releases. The upstream afflib project is mostly idling, so I don't expect any new major lib versions in the near future. If course, I could rename it to libafflib0 if desired. As far as I know, there is no cost for doing this, and it saves grief if upstream ever bumps the soversion. Also, it's probably best to explicitly list the filename with soversion in the CONTENTS, so that if upstream ever does change the soversion, it will be detected as a packaging failure, rather than producing a package with a mismatch between the soversion in it's name and in it's contents. (Cygport should perhaps and detect and warn about apparently soversioned libraries that aren't in appropriately named packages, but...)
