On 07/06/2024 07:22, Takashi Yano via Cygwin-apps wrote:
dav1d is a decoder for AV1 video codec, which is faster
as twice as libaom.
This package is available also for fedora.
https://src.fedoraproject.org/rpms/dav1d
I'am planning to release ffmpeg where dav1d is enabled
as fedora.
Thanks in
On 12/08/2016 20:41, Corinna Vinschen wrote:
On Aug 12 11:57, Warren Young wrote:
On Aug 12, 2016, at 7:57 AM, Corinna Vinschen
wrote:
Cool! If you want to take over ctags and test universal ctags for
Cygwin, feel free if Warren agrees. I'll change over maintainership
then.
Warren, does
On 04/06/2024 00:14, Brian Inglis via Cygwin-apps wrote:
On 2024-06-03 13:27, Jon Turney via Cygwin-apps wrote:
On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote:
On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote:
On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:
[...]
Could
On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote:
On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote:
On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:
[...]
Could someone please do any further tweaks for this source git if
required, and do NMU builds and deploys of these?
I've
On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:
On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:
It would be useful if someone could rebuild the two packages
https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
On 21/05/2024 17:22, Brian Inglis via Cygwin-apps wrote:
[...]
Note that because this flag doesn't do anything for non-PE targets,
it's (a) always safe to upstream, and (b) doesn't actually prevent
development from unwittingly introducing unresolved symbols.
In that case, could we ask Bruno
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
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
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:
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
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
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 i
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
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
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
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
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,
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
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
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
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
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
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
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
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_*
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,
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
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
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
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
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 commi
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
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
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/,
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
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
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
: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
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
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
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
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
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
---
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
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
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
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
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
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,
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
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
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)
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?
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
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
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
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
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
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.
...
+
On 23/02/2024 12:09, Christian Franke via Cygwin-apps wrote:
Harmless bug ...
Applied. Thanks.
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
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:
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
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
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
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
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
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
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
* 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
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
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
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
---
Feedback.h | 4
Makefile.am | 2 ++
choose.cc | 4 +++-
cli/CliFeedback.h | 5 +
cli/CliHashCheckFeedback.cc | 30 ++
download.cc | 24
download.h
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 |
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
Rename IniParseFeedback.h to Feedback.h
Do URL fetching progress reporting via an interface defined by the
methods added to the interface defined by the virtual base class
Feedback, which can be implemented for GUI (via ThreeBar) or CLI feedback.
This is all a bit ad-hoc at the moment, based on
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
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 ++---
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 |
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 =>
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
---
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;
//
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
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
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
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
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
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
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)
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
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
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
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
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
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};
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
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
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
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
1 - 100 of 383 matches
Mail list logo