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...)
Re: [ITP] afflib 3.7.20-1
Thanks! libafflib_CONTENTS=" usr/bin/cygafflib-*.dll Any reason why this package doesn't include the soversion, i.e. why not libafflib0? rm -v usr/bin/affuse.exe usr/share/man/man1/affuse.1 # --disable-fuse I guess this comment means something to someone. But it doesn't tell me anything...
Re: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH
On 04/03/2024 21:20, Brian Inglis via Cygwin-apps wrote: On 2024-03-04 13:00, Jon Turney wrote: On 03/03/2024 22:29, Brian Inglis via Cygwin-apps wrote: On 2024-03-03 14:39, Jon Turney via Cygwin-apps wrote: On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote: I am finding mingw package cross tests fail with missing DLLs - CROSS_BINDIR is not in the PATH. I now have to define src_test to run cygtest adding CROSS_BINDIR in the PATH. Is this likely to be upstream (e.g. gnulib) changes or cygport changes? This is a shortcoming of cygport, in that you cannot just write "do the standard src_(compile|install|test), but do this extra thing first (like modifying PATH as you need in this case). (One approach to this I've though about would be to have a hook function (or set of functions) which are called before each phase of operation, to allow this) These test failures have been only in the latest upstream releases. Previously no PATH fiddling was required. For mingw64-x86_64-nghttp2 that was 2024-01-21. Why I asked if anyone noticed any cross build changes as for example in autotools, gnulib, or cygport? I assumed that you were talking about "PATH needs to be set so that dependencies of the built DLL can be loaded" But, now I look, mingw64-x86_64-nghttp2 doesn't have any dependencies. So, I'm not so sure. Maybe you just mean that the test harness can't locate the just built DLL? That could well be an upstream change. Maybe you could show the actual error? Sorry I was not clearer. In previous release build checks there were no issues. Have you tried rebuilding and running the tests for the previous release version of nghttp2? This might at least offer some clue as to if the change is in upstream, or in the toolchain or build environment? In the latest release the test programs have a dependency on winpthreads and failed with popup dialogues: I see. Well, to reiterate, if the test genuinely depends on that DLL, this behavior is to be expected, because cygport (currently) lacks a feature to add CROSS_BINDIR to the PATH before running tests. To me, the obvious theories to explore are that: * the previous version of nghttp2 did not link it's tests with that DLL (e.g. an upstream change has been made to parallelize the tests, or add testing coverage for multithreaded use) * the previous version of nghttp2 arranged to link it's tests statically with the required library, and no longer does so * the MinGW cross winpthreads packages have stopped providing the static library (from a brief check, this does not seem to be the case) Hope that's of some help.
Re: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH
On 03/03/2024 22:29, Brian Inglis via Cygwin-apps wrote: On 2024-03-03 14:39, Jon Turney via Cygwin-apps wrote: On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote: I am finding mingw package cross tests fail with missing DLLs - CROSS_BINDIR is not in the PATH. I now have to define src_test to run cygtest adding CROSS_BINDIR in the PATH. Is this likely to be upstream (e.g. gnulib) changes or cygport changes? This is a shortcoming of cygport, in that you cannot just write "do the standard src_(compile|install|test), but do this extra thing first (like modifying PATH as you need in this case). (One approach to this I've though about would be to have a hook function (or set of functions) which are called before each phase of operation, to allow this) These test failures have been only in the latest upstream releases. Previously no PATH fiddling was required. For mingw64-x86_64-nghttp2 that was 2024-01-21. Why I asked if anyone noticed any cross build changes as for example in autotools, gnulib, or cygport? I assumed that you were talking about "PATH needs to be set so that dependencies of the built DLL can be loaded" But, now I look, mingw64-x86_64-nghttp2 doesn't have any dependencies. So, I'm not so sure. Maybe you just mean that the test harness can't locate the just built DLL? That could well be an upstream change. Maybe you could show the actual error?
Re: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH
On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote: Hi folks, I am finding mingw package cross tests fail with missing DLLs - CROSS_BINDIR is not in the PATH. I now have to define src_test to run cygtest adding CROSS_BINDIR in the PATH. Is this likely to be upstream (e.g. gnulib) changes or cygport changes? This is a shortcoming of cygport, in that you cannot just write "do the standard src_(compile|install|test), but do this extra thing first (like modifying PATH as you need in this case). (One approach to this I've though about would be to have a hook function (or set of functions) which are called before each phase of operation, to allow this)
Re: scallyweg: ‘strcasecmp’ was not declared in this scope
On 02/03/2024 17:01, Marco Atzeri via Cygwin-apps wrote: On 29/02/2024 17:58, Jon Turney wrote: On 29/02/2024 06:21, Marco Atzeri via Cygwin-apps wrote: Hi Jon, I have a strange case with nco https://github.com/cygwin/scallywag/actions/runs/8060036334/job/22015501908 While Scallyweg complains about ‘strcasecmp’ scope, local build runs fine. I saw the same also on previous build Can you check ? I can reproduce the build failure locally. From a brief inspection, this seems to make sense: strcasecmp is unconditionally defined by strings.h, which doesn't seem to be included anywhere in antlr. (There's maybe some way it gets indirectly included, maybe via string.h if __BSD_VISIBLE, but perhaps that's due to some local flags settings?) thanks for double checking No problem. The problem was subtle; the original and ancient https://www.antlr2.org/download/antlr-2.7.7.tar.gz need patching to work with recent compiler. I had a different version, with the same name, on my computer but I forgot to update the SRC_URI, so me locally and scallyweg were working on different source packages. Further info on: https://nco.sourceforge.net/#Source Aha! Two archives with the same name but different contents, always great. There really ought to be a list of hashes for SRC_URI files associated with a .cygport file, and cygport should verify them after downloading (which would avoid this problem, and related ones), but we've needed that feature for a while...
Re: scallyweg: ‘strcasecmp’ was not declared in this scope
On 29/02/2024 06:21, Marco Atzeri via Cygwin-apps wrote: Hi Jon, I have a strange case with nco https://github.com/cygwin/scallywag/actions/runs/8060036334/job/22015501908 While Scallyweg complains about ‘strcasecmp’ scope, local build runs fine. I saw the same also on previous build Can you check ? I can reproduce the build failure locally. From a brief inspection, this seems to make sense: strcasecmp is unconditionally defined by strings.h, which doesn't seem to be included anywhere in antlr. (There's maybe some way it gets indirectly included, maybe via string.h if __BSD_VISIBLE, but perhaps that's due to some local flags settings?)
Re: [PATCH cygport] Add more checks of SOURCE_DATE_EPOCH
On 16/02/2024 12:29, Christian Franke via Cygwin-apps wrote: Fail if it is out of range. Warn if it lies in the future. Inform whether it is set or set but not exported. What is the valid range here? Would it not make more sense to just re-export it if set? (so that commands like "SOURCE_DATE_EPOCH=something cygport foo" work as expected?)
Re: [cygport] enabling a replacement for "objdump -d -l"
Thanks, this is great!
On 18/02/2024 19:51, ASSI via Cygwin-apps wrote:
[...]
dwarf-parse.-pl
There should be some build system changes which install this file,
probably in /usr/share/cygport/tools/, which it can then be run from.
--8<---cut here---start->8---
Please, please make a patch with git format-patch, which I can then just
apply.
#!perl -w
Fifty lines of perl with no comments! This is just line noise to me
unless I spend lots of time staring at it :)
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.
use common::sense;
use List::Util qw( sum );
my $filter = shift @ARGV
or die "not enough arguments";
my $obj = shift @ARGV
or die "not enough arguments";
my @objdump = qw( /usr/bin/objdump -WNl );
cygport goes to some lengths to identify the correct objdump to use when
cross-building, so it should probably should be used here (passed in as
an arg?), rather than assuming it's /usr/bin/objdump.
open my $DWARF, "-|", @objdump, $obj
or die "can't invoke objdump\n$!";
my ( @dirs, @files, %fn, %rn );
while (<$DWARF>) {
if (/^ The Directory Table/../^$/) {
if (/^ \d+/) {
my ( $entry, $dir ) = m/^ (\d+)\t.+: (.+)$/;
$dir = "$dirs[0]/$dir" if ($dir =~ m:\A[^/]:);
push @dirs, $dir;
}
}
if (/^ The File Name Table/../^$/) {
if (/^ \d+/) {
my ( $idx, $fn, undef ) = m/^ \d+\t(\d+)\t.+: (.+)$/;
$rn{"$dirs[$idx]/$fn"}++;
push @files, "$dirs[$idx]/$fn";
}
}
if (my $rc = /^ Line Number Statements/../^ Offset:/) {
$fn{"$files[0]"}++ if ($rc == 1);
$fn{"$files[$1]"}++ if m/ Set File Name to entry (\d+) in the File Name
Table/;
What this line is doing is obvious, the rest of this block, not so much.
You might also like to touch on why we bother looking at the line number
information at all, rather than just producing a (filtered) list of all
the pathnames mentioned?
@files = () if ($rc =~ m/E0$/);
@dirs = () if ($rc =~ m/E0$/);
}
if (/^ No Line Number Statements./../^$/) {
@files = ();
@dirs = ();
}
}
foreach my $fn (grep m:^$filter:, sort keys %fn) {
say sprintf "%s", $fn;
}
say STDERR sprintf "\tLNS: %6d (%6d locations) <=> FNT: %6d ( %6d locations)",
0+grep( m:^$filter:, keys %fn ), sum( values %fn ),
0+grep( m:^$filter:, keys %rn ), sum( values %rn )
if (0);
If you're going to keep this (which you probably should), perhaps it
should be under some 'if (DEBUG)' conditional.
close $DWARF
or die "failed to close objdump\n$!";
--8<---cut here---end--->8---
Integration into cygport is made configurable via a variable to be set
in .cygportrc for instance in order to easily revert back to the
original objdump invocation if necessary. I've been producing packages
DWARF_PARSE should be mentioned in the documentation for cygport.conf
Since the helper script will be installed, it could be made a boolean.
with that setup for a while now and have not noticed any errors. In
principle the new parser actually produces more complete output as there
can be multiple line number statements and hence source files per
location, but objdump only lists one of them in the disassembly (at
least sometimes). In practise I haven't found a package until now where
the final list (after filtering) is different.
--8<---cut here---start->8---
lib/src_postinst.cygpart: use DWARF_PARSE optionally instead of objdump -dl
---
diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
index f06004e4..3dd6e893 100644
--- a/lib/src_postinst.cygpart
+++ b/lib/src_postinst.cygpart
@@ -1096,7 +1096,12 @@ __prepstrip_one() {
else
dbg="/usr/lib/debug/${exe}.dbg";
- lines=$(${objdump} -d -l "${exe}" 2>/dev/null | sed -ne "s|.*\(/usr/src/debug/${PF}/.*\):[0-9]*$|\1|gp" | sort -u | tee -a ${T}/.dbgsrc.out.${oxt} | wc -l);
+ if defined DWARF_PARSE
+ then
+ lines=$(${DWARF_PARSE} /usr/src/debug/${PF}/ "${exe}" |
tee -a ${T}/.dbgsrc.out.${oxt} | wc -l);
+ else
+ lines=$(${objdump} -d -l "${exe}" 2>/dev/null | sed -ne
"s|.*\(/usr/src/debug/${PF}/.*\):[0-9]*$|\1|gp" | sort -u | tee -a ${T}/.dbgsrc.out.${oxt} |
wc -l);
+ fi
# we expect --add-gnu-debuglink to fail if a
# .gnu_debuglink section already exists (e.g. binutils,
--8<---cut here---end--->8---
Re: Fwd: calm: cygwin package report for Ken Brown
On 19/02/2024 18:59, Ken Brown via Cygwin-apps wrote: On 3/20/2023 7:17 PM, Jon Turney wrote: On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote: It looks like my plan for having scallywag deploy all the TeX Live packages won't work (see below). calm would have to be more permissive and allow deploying a package that requires something that will be provided by a future package. In this case, I made asymptote require tl_2023, which will be provided by the next texlive release. But I don't want to deploy the latter until all the other packages for TeX Live 2023 have been deployed. Unless this is easy to fix, I'll just forget about using scallywag and go back to my old method of uploading everything manually. This is trivially fixable. calm already has a list of 'provides which don't exist (yet)', so I think I just need to add tl_2023 and tl_basic_2023 to that list Future work: make these regexes so we don't have same problem again in a years time. Jon, In preparation for TeX Live 2024, please add tl_2024 and tl_basic_2024 to the list of provides which don't exist yet (unless you've already done the regex future work). These are controlled by regex now, so these should already be permitted, and I don't need to do anything (yay!): 'tl_\d+' 'tl_basic_\d+'
Re: [PATCH cygport] git.cygclass: Suppress the depth option
On 16/02/2024 11:59, Daisuke Fujimura via Cygwin-apps wrote:
Thank you for merging.
I have confirmed that this modification has resulted in the intended behaviour.
[...]
$ head -3 agbsum-15-1bl1.cygport
HOMEPAGE="https://mandelbrot.dk/${PN};
GIT_URI="https://mandelbrot.dk/${PN};
GIT_TAG="${PV}"
$ cygport agbsum-15-1bl1.cygport fetch
*** Info: Trying to enable case sensitivity on /tmp/agbsum/agbsum-15-1bl1.x86_64
git clone --depth 1 --branch 15 --no-checkout
https://mandelbrot.dk/agbsum agbsum
Cloning into 'agbsum'...
fatal: dumb http transport does not support shallow capabilities
*** Warning: git clone failed, retrying without --depth option
git clone --branch 15 --no-checkout https://mandelbrot.dk/agbsum agbsum
Cloning into 'agbsum'...
Fetching objects: 251, done.
git checkout tags/15
HEAD is now at bef1780 Rename source directory: 'src' => 'source';
Update naming convention; Update copyright holder name; Update code
style;
```
Thank you very much for testing!
Re: [ITA] libid3tag
On 17/02/2024 13:43, Marco Atzeri via Cygwin-apps wrote: On 17/02/2024 04:18, Takashi Yano via Cygwin-apps wrote: I would like to adopt libid3tag. $ git diff | grep ^+ +++ b/cygwin-pkg-maint +libid3tag Takashi Yano +libmad Takashi Yano +taglib Takashi Yano +taglib-extras Takashi Yano +utf8cpp Takashi Yano Thanks Marco FWIW, I took a look at these cygports and couldn't find anything to comment on. Good job! Thanks for adopting these.
Re: Tmux crashes on copy
On 14/02/2024 00:11, Yasuhiro Kimura via Cygwin-apps wrote: Hello, From: Jon Turney via Cygwin-apps Subject: Re: Tmux crashes on copy Date: Wed, 31 Jan 2024 13:28:41 + Thanks. Since this is a crash bug, which renders the package more or less useless, I made an NMU with these changes. Michael, Sorry about not pinging you before I made this change. You don't seem to have been active for a few years. Are you still interesting in maintaining this package? IF so, do you want to get pinged if/when problems crop up? Tmux 3.4 is released. https://github.com/tmux/tmux/releases/tag/3.4 Just FYI. Thanks. I don't use tmux, so if I were to just bump the version, I'd just be deploying the updated package without any testing, which is something I try to avoid doing. If an up-to-date and working tmux package is important to you, please consider if maybe you want to adopt it? (I'm assuming the existing maintainer has wandered off since he didn't reply, but our process requires me to wait a bit longer before that's assumed) Even if you don't, maybe you would consider submitting an ssh key, so you can push to our package building playground, which would make it a bit less effort for me in future, if you submit other NMUs.
Re: [PATCH cygport] git.cygclass: Suppress the depth option
On 03/12/2023 21:53, Brian Inglis via Cygwin-apps wrote: On 2023-12-03 13:34, Jon Turney via Cygwin-apps wrote: On 30/11/2023 12:17, Daisuke Fujimura via Cygwin-apps wrote: Implementations that conditionally branch on variables are simple. The proposed retry implementation complicates git.cygclass, but I think it reduces the maintainer's effort. I have created a patch for a retry implementation. Could you review it? Thanks very much to Fujimura-san for all his work on this. Attached is the patch after my edits. I've applied a reheated version of this patch. Hopefully that works well enough, but obviously can be further refined if needed. Looks like straight curl HEAD -I tells you about smart transport if you want a quick check rather than a dry run: $ time curl -ILSs https://repo.or.cz/r/git.git/info/refs?service=git-upload-pack | grep -qi '^content-type:\sapplication/x-git-upload-pack'; echo $? real 0m0.630s user 0m0.077s sys 0m0.123s 0 $ time curl -ILSs https://github.com/BrianInglis/apt-cyg.git/info/refs?service=git-upload-pack | grep -qi '^content-type:\sapplication/x-git-upload-pack'; echo $? real 0m0.440s user 0m0.061s sys 0m0.184s 1 Thanks for this. Uh, but it seems like 'git clone --depth 1' works with both of these URLs, so... um... I'm not sure what's going on.
Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS
On 04/02/2024 16:30, Christian Franke via Cygwin-apps wrote: Jon Turney wrote: On 02/02/2024 16:13, Christian Franke via Cygwin-apps wrote: _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). Thanks. I applied this. I'm thinking I want to try to do another cygport release fairly soonish, so please feel free to remind me about any other patches by you (or others) which I need to look at before then. Possibly some initial SOURCE_DATE_EPOCH support: https://sourceware.org/pipermail/cygwin-apps/2023-August/043108.html I've applied this (and I think I might have caught up on most of the pending patches...) It would be nice to have some sort of test, since there's no coverage with SOURCE_DATE_EPOCH defined at the moment. Even if we just verify that an existing test continues to build without problems with it defined, that would be a good start, let alone verifying that it actually sets timestamps as expected...
Re: cygport may not create debug info if top directory contains a symlink
On 30/10/2023 16:37, Christian Franke via Cygwin-apps wrote:
Jon Turney wrote:
On 20/09/2023 11:58, Christian Franke via Cygwin-apps wrote:
Brian Inglis 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.
I think that there was some historical bug with gcc where a
relative path for the old path in this mapping wasn't correctly
handled, which is why were using an absolute path here at all.
So changing it to something like [1] (if that works), might be
better.
[1]
https://github.com/jon-turney/cygport/commit/4175d456a9184c5cdebd8bfb4b5ba30583cedd66
Should bin/cygport.in:534: not have $B between the == as in line 531:
declare ${flags}+=" -fdebug-prefix-map=${B}=/usr/src/debug/${PF}"
...
declare ${flags}+=" -fdebug-prefix-map==/usr/src/debug/${PF}"
or be hoist above the condition if identical, unless that is some
undocumented default for cwd?
I guess the == without ${B} is intentional because it makes the debug
source path relative to ${B} as lines 535-536 also do.
[...]>
(It's unclear to me how gcc compares paths to apply this mapping. If
it's a literal string prefix, rather than on some (semi-)canonicalized
path, then we're maybe going to lose here sometimes, depending on the
vagaries of the build-system, unless we list all of relative,
absolute, and canonical absolute paths?)
(But then maybe we can push dealing with or indicating which of those
is correct off onto the individual cygport?)
Adding this if "$(cd ${S} && pwd -P)" != "${S}" should IMO be safe:
-fdebug-prefix-map=$(cd ${B} && pwd -P)=/usr/src/debug/${PF}
-fdebug-prefix-map=$(cd ${S} && pwd -P)=/usr/src/debug/${PF}
(or use realpath)
So it seems there's a new flag '-fcanon-prefix-map' in GCC 13, which
looks like it maybe solves this problem.
Re: [PATCH] In gcc 13, -Wall turns on -Woverloaded-virtual
On 07/02/2024 10:46, Corinna Vinschen via Cygwin-apps wrote: Also fix ambiguous method declaration by dropping a default parameter. --- Hi Jon, I'm not sure removing virtual from all Create methods really fits the bill in all cases, are you? I had a go at fixing this while keeping the virtuality of the methods intact. While at it it also occured to me that there's a tricky problem for the compiler to differentiate the method This seems like overkill. From auditing the code, as far as I can tell, we only ever instantiate PropPage-derived objects for each of the setup wizard pages, and one PropSheet object to contain them. There are no instantiations of the Window class itself. PropPage::Create() doesn't even call Window::Create(), so that method can actually be totally removed without problem...
[PATCH setup] Fix -Woverloaded-virtual warnings about Window::Create()
In gcc 13, -Wall turns on -Woverloaded-virtual
---
Notes:
I think despite being marked virtual, these methods aren't actually
callable on any derived object because they aren't declared for those
sublasses.
It seems that all calls to these in methods in derived objects use the
method name qualified by an explcit classname.
So we can simply fix this warning by removing the 'virtual' specifier.
But someone double-checking my reasoning here is probably a good idea.
Makefile.am | 2 +-
proppage.h | 10 +-
window.h| 7 +++
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index b459d16..22ad30c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -22,7 +22,7 @@ SUBDIRS := @subdirs@ tests
BASECXXFLAGS = -Werror -Wall -Wpointer-arith -Wcomments \
-Wcast-align -Wwrite-strings -fno-builtin-sscanf \
-Wno-attributes
-AM_CXXFLAGS = $(BASECXXFLAGS) -std=gnu++11 ${$(*F)_CXXFLAGS}
+AM_CXXFLAGS = $(BASECXXFLAGS) -Woverloaded-virtual -std=gnu++11
${$(*F)_CXXFLAGS}
AM_CFLAGS = $(BASECXXFLAGS) -Wmissing-declarations -Winline \
-Wstrict-prototypes -Wmissing-prototypes
AM_YFLAGS = -d
diff --git a/proppage.h b/proppage.h
index 64f822b..9db1a90 100644
--- a/proppage.h
+++ b/proppage.h
@@ -115,11 +115,11 @@ public:
IsLast = false;
};
- virtual bool Create (int TemplateID);
- virtual bool Create (DLGPROC dlgproc, int TemplateID);
- virtual bool Create (DLGPROC dlgproc,
- BOOL (*cmdproc) (HWND h, int id, HWND hwndctl,
- UINT code), int TemplateID);
+ bool Create (int TemplateID);
+ bool Create (DLGPROC dlgproc, int TemplateID);
+ bool Create (DLGPROC dlgproc,
+ BOOL (*cmdproc) (HWND h, int id, HWND hwndctl,
+UINT code), int TemplateID);
virtual void OnInit ()
{
diff --git a/window.h b/window.h
index 1dfb2a9..dcc81c1 100644
--- a/window.h
+++ b/window.h
@@ -82,10 +82,9 @@ public:
Window ();
virtual ~ Window ();
- virtual bool Create (Window * Parent = NULL,
- DWORD Style =
- WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CLIPCHILDREN);
-
+ bool Create (Window * Parent = NULL,
+ DWORD Style = WS_OVERLAPPEDWINDOW | WS_VISIBLE |
WS_CLIPCHILDREN);
+
static void SetAppInstance (HINSTANCE h)
{
// This only has to be called once in the entire app, before
--
2.43.0
Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS
On 02/02/2024 16:13, Christian Franke via Cygwin-apps wrote: _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). Thanks. I applied this. I'm thinking I want to try to do another cygport release fairly soonish, so please feel free to remind me about any other patches by you (or others) which I need to look at before then.
Re: ncurses version
On 31/01/2024 20:45, Brian Inglis via Cygwin-apps wrote: On 2024-01-31 10:36, ASSI via Cygwin wrote: Jon Turney via Cygwin writes: If upstream really is making multiple releases called '6.4', which we're supposed to distinguish by some other means, then there aren't really any good answers... There's only one official 6.4 release, but just about everyone packages one of the roughly weekly snapshots inbetween releases (depending on where you are looking they are also called beta versions), which are named 6.4-mmdd upstream. We can't have a "-" in the version number, hence the suggestion to replace it with a "+". [moving discussion to -apps] Upstream developer is Thomas Dickey at invisible-island.net so no git. My only concern is if 6.4+20240203-1 !> 6.4-20240120 as strvercmp test beds disagree, presumably about the effect of the delimiter, possibly because the + may be treated similarly to a prefix for an RC preceding the 6.4 release? For guidance I have looked at: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ which states that ~ prefixes pre-stable "snapshot" releases and ^ prefixes post-stable "snapshot" releases where . or nothing prefixes upstream bugfix or patch level releases, so perhaps we should just use version suffix .mmdd? So, this is notionally defined here [1]. The important point there "Non-alphanumeric separators for these contiguous chunks are ignored" (after identifying chunks) So '1.2.3' '1+2+3' and '1_2_3' are all equal. [1] https://cygwin.com/packaging-package-files.html#naming Practically, this is controlled by the version comparison which libsolv does, which I am expecting to also work like that. (Perhaps naively. All the details are paged-out at the moment. I think I remember there's a flag which you have to give it to turn on the special behaviour of tilde and caret, which in any case aren't currently in the character set permitted for a cygwin package name) I have downloaded and locally installed Fedora rpmdevtools package but Cygwin python rpm module seems to lack labelCompare(): $ rpmdev-vercmp 6.4+20240203-1 6.4-20240120 /usr/local/lib/python3.9/site-packages/rpm.py:15: UserWarning: The RPM Python bindings are not currently available via PyPI. This can't be cygwin's python rpm module if it's in /usr/local/, I think? If you have calm installed, you can use: $ calm-tool sort-versions 1.2.1 1.2.3 1+2+3 1_2_3 1.2.4 1.2.1 1.2.3 1+2+3 1_2_3 1.2.4 At this point it should be clear that 6.4+2024012 is greater than 6.4. How are Cygwin pre-stable RC releases defined differently from post-stable snapshot releases and upstream patch releases? Generally, I think that following [2], as linked from that, is a good idea. i.e. for pre-release versions use R="0." followed by something that's going to increase as prereleases do e.g. date or an incrementing ordinal and then a githash. for post-releases you can increment R and add a similar identifier. You can instead add things to V to indicate post-label snapshots, but there's there's a risk of coming unstuck unless the upstream versioning scheme is totally predicable (i.e. if you create 1.2+3 for a post-release fix to 1.2, and then upstream releases a 1.2a which you weren't expecting because they've never done it before, you're boned) [2] https://fedoraproject.org/wiki/Package_Versioning_Examples
newlines in ldesc
We now have a few places where the long description (ldesc) for a package is used (in the package summary webpage, in the tooltip for the package description in setup, and now in any automatically generated announce email). Unfortunately, it's underspecified exactly what a newline in ldesc means, and taking it literally causes problems when trying to render it nicely in those places. (Some heuristic hacks are already applied to it in the package summary webpage to try to make things look reasonable) Therefore, I'm proposing to define that the following very minimal subset of MarkDown-compatible markup can be used in ldesc: * A blank line separates paragraphs * A line ending with two (or more spaces) is followed by a line break * Lines starting with '-', '*', or '+' are bulleted lists - Sublists are indented by four spaces (Technically, all of this also applies to the message: hint, being the only other hint which can take a multi-line value, but since that's only used by one package currently, that's not much of a concern)
