Re: Build machines

ASSI via Cygwin-apps writes: >> I misremembered the code names. The direct successor to the 7735HS >> (Rembrandt Refresh) are the 7840HS / 7940HS (Phoenix-H at 8 cores and >> upgraded to 4nm Zen4/RDNA3 and about 15% better performance per Watt); >> the upcoming 16 core is

Re: [ITP] perl-Parse-Yapp-1.21

Ziemowit Laski via Cygwin-apps writes: > This is a straightforward port, akin to other Perl packages. The question is: what do you need it for and why should it get packaged in Cygwin? […] > I can be the maintainer-at-large for this if you'd like. I'd rather not have separate maintenance of

Re: [PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify

Brian Inglis via Cygwin-apps writes: > Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly, > single operation gpg verification helper designed for use in scripts > instead of gpg2 --verify: see 'info gpg2 helper gpgv' NAK. This tool doesn't check for expired keys and also

Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

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

Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS

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

Re: [cygport] enabling a replacement for "objdump -d -l"

Jon Turney via Cygwin-apps writes: > But I'm not being oblique here. I really do want comments. Well, adding comments or proper POD is about the same effort, so I'd tend towards the latter. > I'm not sure what's so astounding about the suggestion that a fifty > line script should have some

Re: [cygport] enabling a replacement for "objdump -d -l"

Jon Turney via Cygwin-apps writes: > Thanks, this is great! You're welcome. > Please, please make a patch with git format-patch, which I can then > just apply. You can always just pull it in from my repo… when it's ready. > Fifty lines of perl with no comments! This is just line noise to me >

[ATTN. MAINTAINER] units

The postinstall script for units downloads currency exchange rates and hangs up for a long time if it can't access the server (if it ever finishes, I've killed the process on all machines where I've seen this). Can this part please either be removed entirely or moved into a sub-package that

Re: [cygport] enabling a replacement for "objdump -d -l"

Marco Atzeri via Cygwin-apps writes: > if works should not be the default ? Let's start with interested parties giving it a spin, shall we? ONce configured into your .cygportrc it essentially is the default for all your builds. > Reducing that time is very interesting for the big stuff That's

[cygport] enabling a replacement for "objdump -d -l"

Cygport uses "objdump -d -l" to extract the list of source files that need to be copied into the debuginfo package. This operation triggers some O(N²) or even higher complexity and in addition has been getting slower in recent binutils releases due to more and more information being put into

Re: Tmux crashes on copy

Jon Turney via Cygwin-apps writes: > 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. I do, I just built it locally (with the dud patch that doesn't actually fix control mode backed

Re: [ITP] pigz 2.8

Marco Atzeri via Cygwin-apps writes: > BUILD_REQUIRES="zlib-devel ncompress gzip" Why is ncompress a build dependency? Please remove if possible. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2:

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: > now updated to 15.0.7 I've built it and activated the tests, which seem to have roughly the same results as 9.0.1, so that looks good. For 9.0.1 I think I've finally got it to build almost cleanly. I still need to ignore some fallout from documentation bitrot, but

Re: [ITA] llvm

徐持恒 Xu Chiheng via Cygwin-apps writes: > Without process_install_dir_bin_symlinks, you can't get an installable > package *.xz. You have not explained what exactly the issue is you're trying to solve. If you get links to outside DESTDIR then the install targets are broken and you need to fix the

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: > On Thursday, 14 December 2023 at 2:42 PM, 小さい猫 via Cygwin-apps > wrote: > >> By the way, just now I have updated these cygports to 13.0.1 LLVM release in >> my GitHub repo. > > now updated to 14.0.5 THanks for letting us know. I can't promise, but I'll try to

Re: [ITA] llvm

ASSI via Cygwin-apps writes: > That's mildly confusing to me… anyway, I'll try to build LLVM from this > (maybe this weekend). I expect there will need to be further changes to > the packaging, given how far out of date the cygport you based it on is. LLVM 16 does indeed build (di

Re: [ITA] llvm

徐持恒 Xu Chiheng via Cygwin-apps writes: > I'd like to adopt the llvm package. > I have build scripts and patches, and .cygport files at > https://github.com/xu-chiheng/Note. That's mildly confusing to me… anyway, I'll try to build LLVM from this (maybe this weekend). I expect there will need to

Re: Unmaintained packages in base package set

Takashi Yano via Cygwin-apps writes: > I found the cause. DISTCLEANFILES in original cygport file removes them. > Now I can successfully build libatk1.0-doc. Thanks! No, that means the tarball includes files that should get re-built, but apparently you somehow failed to do that. Regards, Achim.

[Attn. MAINTAINER] gpg2

Hi Marco, Since the last update gpg2 segfaults, rolling back step by step points at libgpg-error as the culprit. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld:

Re: [NMU] inkscape 0.92.3-2 (Test)

Mark Geisert via Cygwin-apps writes: > I've uploaded a non-maintainer re-build of the existing inkscape > 0.92.3. This attempts to work around a problem with the current > inkscape reported to exit with 127 error code (missing DLL). This > build was produced with gcc-g++ 7.4 while the current

Re: cygport upgrade to use gnupg2/gpg2 if available

Brian Inglis via Cygwin-apps writes: > After applying the attached patches, which add support for the newer > gpg2 from gnupg2 if installed, the attached log second chunk shows the > new keys verified by gpg2 added to lib/src_prep.cygpart > ___gpg_verify(). > > Similar code has been added to

Re: [PATCH cygport] git.cygclass: Suppress the depth option

Jon Turney via Cygwin-apps writes: > This could just be named something a little shorter, like > "GIT_URI_NO_SMART_TRANSPORT", since it's really a property of the > URI's host? > > But I wonder if wouldn't just be better to try with --depth and then > fallback to without it, if that fails

Re: [cygport RFC PATCH 1/1] Run install functions separately

Adam Dinwoodie via Cygwin-apps writes: > I think you've misunderstood how `set -e` works. Likely, for some definition of "works". I'm the last person to understand bash, really. […] > The issue is that the && chain disables `set -e` for anything other than > the final command in the chain,

Re: [cygport RFC PATCH 1/1] Run install functions separately

Adam Dinwoodie via Cygwin-apps writes: > When running as part of a `&&` chain, Bash's `set -e` behaviour is > suppressed entirely, which means calls that produce non-zero error codes > will be ignored if they're called inside functions that are part of such > a chain. > > To avoid silent failures

[Pending NMU] mysql, mariadb-connector-c

Due to a problem with a new major version of perl-DBD-mysql (trhat hasn't been resolved and will have to wait for an upstream fix) I've been looking at re-building those two packages. The updated packaging is available in the playground branches:

Re: Updated: mingw64-x86_64-/nghttp2 libnghttp2_14/-devel 1.57

Cygwin nghttp2 Maintainer via Cygwin-announce writes: > * libnghttp2_14 1.57 This library pulls in a lot of build dependencies, but then does not have any actual dependencies on anything. You seem to be building a static library? If so, please stop doing that. Regards,

Re: [Attn. Maintainers] OpenSSL v3

ASSI via Cygwin-apps writes: > Support for OpenSSL LTS v1.1.1 is ending on September 11. > > With the next release from upstream I will make OpenSSL LTS v3.0 current > on Cygwin. I've just rebuilt OpenSSH locally using the 3.0.10 test > package without any problems and unless y

Re: [PATCH setup] Enable large files (>2 GiB)

Jon Turney via Cygwin-apps writes: > This seems right, and works for installing qt5-webkit-debuginfo when I > gave it a quick try (seems to work on i686 as well). Oh good to know, so I don't need to boot up the machine that still has the 32bit installation for testing. > (Note that if you have

[PATCH setup] Enable large files (>2 GiB)

This fixes the issue reported here: https://cygwin.com/pipermail/cygwin/2023-October/254562.html Not tested on 32bit. --8<---cut here---start->8--- diff --git a/Makefile.am b/Makefile.am index 3bd83dc4..70bfd032 100644 --- a/Makefile.am +++ b/Makefile.am @@

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

William Hu via Cygwin-apps writes: > Hi All, > > Re OCaml compilers: I should be able to package OCaml 4.14.1 (and hopefully > an > alpha version of 5.1.0 as well) for Cygwin in the coming weeks. OCaml 5.0.0 > temporarily dropped Cygwin support so the Cygwin versions will of course skip > that

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

William Hu via Cygwin-apps writes: > On Wednesday, August 30th, 2023, ASSI wrote: >> NOt immediately, but it makes me wonder if there's other such leakage. >> I have not found a (text) file that stores this information in the >> installed package, so it seems that the in

Re: The correct manner to obsolete subpackage.

Takashi Yano via Cygwin-apps writes: > But, my case is > >> If the package is really being removed without any replacement, there >> are mechanisms to deal with that case, but that case should be really rare. > > this. pulseaudio package no longer provides esound and gconf, > however, these

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

William Hu via Cygwin-apps writes: > Just checked the file and I agree that CFLAGS looks a little funny - are > there any > other stupid flags/variables that you had in mind? NOt immediately, but it makes me wonder if there's other such leakage. I have not found a (text) file that stores this

Re: what license is this?

Andrew Schulman via Cygwin-apps writes: > https://github.com/jqlang/jq/blob/master/COPYING OpenSUSE License:CC-BY-3.0 AND MIT Fedora License:MIT and ASL 2.0 and CC-BY and GPLv3 Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: >> - [ ] dtc (?) > > Ah sorry... that device tree compiler cygport repo in the github org > is not related to LLVM stuffs. just i happened to need it for building > something else and it's adapted from the old cygwinports-extras[1]. OK, I thought so already, but I

Re: [PATCH cygport] Add initial support for SOURCE_DATE_EPOCH

Christian Franke via Cygwin-apps writes: > If the build-path changes, more files differ (cygcheck.exe, ldd.exe, > cygserver.exe) because __FILE__ is used and expands to an absolute > path name. This could be fixed by adding -fmacro-prefix and/or -ffile-prefix arguments. Regards, Achim. --

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

ASSI via Cygwin-apps writes: > I've started a local llvm-revival branch… Progress, OCaml bindings are back again (I've not run the tests yet): --8<---cut here---start->8--- * OCaml Updates - [X] flexdll 0.39 ==> 0.43 + does not recogn

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: > i am not familiar with the ocaml stuffs, and i dont quite understand > what is the problem ur currently getting. Dune cannot be fully built because lwt.unix or one of it's dependencies is missing. I could built a bootstrapped package, but that later runs into

Re: [PATCH cygport] Add initial support for SOURCE_DATE_EPOCH

Christian Franke via Cygwin-apps writes: > If binutils, gzip and tar also would support this, the patch would be > empty :-) GZip has -n though and GNU tar --mtime and --clamp-mtime, so why not use that? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

小さい猫 via Cygwin-apps writes: > On Monday, August 14th, 2023 at 12:50 AM, ASSI via Cygwin-apps > wrote: > >> I've started a local llvm-revival branch… I got sidetracked with OCaml, >> but that will need some more time and currently I have just disabled the >> OCa

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

ASSI via Cygwin-apps writes: > I've started a local llvm-revival branch… I got sidetracked with OCaml, > but that will need some more time and currently I have just disabled the > OCaml bindings in LLVM instead (not removed: this is controlled by a > variable in the script and anot

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

I've started a local llvm-revival branch… I got sidetracked with OCaml, but that will need some more time and currently I have just disabled the OCaml bindings in LLVM instead (not removed: this is controlled by a variable in the script and another variable to control the LLVM target list).

[Attn. Maintainers] OpenSSL v3

Support for OpenSSL LTS v1.1.1 is ending on September 11. With the next release from upstream I will make OpenSSL LTS v3.0 current on Cygwin. I've just rebuilt OpenSSH locally using the 3.0.10 test package without any problems and unless your package has no current upstream I expect no

Re: [PATCH cygport] lib/src_prep.cygpart: Fix incorrect options passed to unzstd in unpack()

Jon Turney via Cygwin-apps writes: > Yes, I had managed to deduce that much. :) > > Providing a specific instance would save me having to find or invent > one, though. Sorry, I did not have one at hand, all such instances in my stack of packages are either uncompressed files or compressed

Re: [PATCH cygport] lib/src_prep.cygpart: Fix incorrect options passed to unzstd in unpack()

Yasutaka ATARASHI via Cygwin-apps writes: > Yeah, I also wonder why the --keep option is not used for .gz and .bz2. > Now, I recognized the reason. Thanks. > `unpack()` is expected to extract the files to the current working > directory regardless of the specified path of the input. Please see >

Re: [PATCH cygport] lib/src_prep.cygpart: Fix incorrect options passed to unzstd in unpack()

Jon Turney via Cygwin-apps writes: > Do you have an example of a cygport which fails without this fix, so I > can add a test for this? Anything with a SRC_URI or PATCH_URI that has .zst suffix but not .tar.zst should suffice. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb

Re: [PATCH cygport] lib/src_prep.cygpart: Fix incorrect options passed to unzstd in unpack()

yak_ex via Cygwin-apps writes: > `unpack()` invokes `unzstd` for a *.zst file as > `unzstd -qo file.zst` > Then, an error occurs as 'stdin is a console, aborting', > because the `-o` option is to specify an output file name. Indeed, sorry for that. > There are some choices to fix it. This patch

Re: [RFC] parallelizing cygport test

ASSI via Cygwin-apps writes: > I've recently updated a few packages that do a serious amount of > compilation during test and it became painfully obvious that cygtest > does not run make with the "-j" option nor does it currently offer an > option to change that. > > G

Re: chattr makes cygport slow

Jon Turney via Cygwin-apps writes: > Ok. I made a cygport 0.36.6 release with this change. Thanks. You haven't tagged that release on GitHub yet it seems. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional

[RFC] parallelizing cygport test

I've recently updated a few packages that do a serious amount of compilation during test and it became painfully obvious that cygtest does not run make with the "-j" option nor does it currently offer an option to change that. Given the brittleness of some test suites it might be prudent to

Re: chattr makes cygport slow

Jon Turney via Cygwin-apps writes: > The warning (error if RESTRICT=case_insensitive) should occur for all > commands, not just prep. OK. > How about the attached. Looks promising. > Even then, it should only be modifying every directory, not every file. Run strace on "chattr -r +C ." and see

[ITA] uchardet

For the record: I have adopted the uchardet package, previously orphaned by Yaakov. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: chattr makes cygport slow

Jon Turney via Cygwin-apps writes: > So, the idea here is that we try to ensure it's on, at least for the > working directory. That IMHO should only be done when the working directory is created, but not retroactively applied to an existing workdir. > Skipping it when 'finish' is used isn't

Re: [ITP] italic-man

[I've had no time to look at this in detail and that will have to wait a bit more.] Thomas Wolff via Cygwin-apps writes: >>> would it actually make a difference whether the zp_ is a script of >>> italic-man or of man-db? I've also added a cygport file to the >>> repository so you can try the

Re: Build machines

Achim Gratz via Cygwin-apps writes: > I misremembered the code names. The direct successor to the 7735HS > (Rembrandt Refresh) are the 7840HS / 7940HS (Phoenix-H at 8 cores and > upgraded to 4nm Zen4/RDNA3 and about 15% better performance per Watt); > the upcoming 16 core is the 7945HX (Dragon

Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent

Marco Atzeri via Cygwin-apps writes: > are you planning to upload 5.36.1 as test ? No. > I will be on the road for 2 weeks in May and I will not be able to > update any package starting from 8th May I need to check another few hundred build logs this evening, then the release should be good to

Re: [ITP] openh264 (2.3.1)

Takashi Yano via Cygwin-apps writes: > Thanks for the advice. I have revised the cygport file. You are getting the file and the hash from the same unprotected source. I was thinking you should put the hash into the cygport file and hence the postinstall script. Also note that the system doing

Re: [ITP] openh264 (2.3.1)

Takashi Yano via Cygwin-apps writes: > - The libopenh264 package includes only /etc/postinstall > and /etc/preremove, which downloads/removes Cisco's dll > (binary) as well as license file. This is a Windows / MingW64 DLL, not a Cygwin one? Also, since Cisco seems to be unable to correctly

Re: [Bug] setup regression #2

Corinna Vinschen writes: > The idea is that the installation tree has POSIXy permissions and > administrative users have the right to change stuff. The administrators > group is part of the user's token if the process has been started > elevated, so, to me, this looks like a natural choice. As I

Re: LICENSE values for non-standard OSS licenses

Adam Dinwoodie writes: […] > Both of these seem to say that "LicenseRef-inherit-git" and similar is > exactly the way to describe a license that isn't covered by the SPDX > License List, at least unless I'm grossly misunderstanding how > license-ref is defined in the ABNF and/or what the LICENSE

Re: [ITP] rsync 3.2.6

Chad Dougherty writes: > I tried but the default src_compile() didn't work. According to the > INSTALL file, the autoconf should only be done on a git checkout, not > the release tarball. You should duly ignore any such upstream nonsense and do a full autoreconf on anything you build for Cygwin

Re: upload to calm: should curr-2 be vaulted while still in setup.ini?

Brian Inglis writes: > After upload, noticed in calm deployment log that release current - 2 > is being vaulted, but it's still showing in setup.ini. > If current - 2 is selected in setup, won't this cause setup to fail, > as as it will no longer be available under release/, nor propagated on >

[ITP] Perl distributions

I need to package a newly introduced build dependency for Cygwin: perl-Alien-Build-Plugin-Download-GitLab Please add this to my list of packages, thank you. Regards Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld:

Re: resolv.conf and gnupg2

Mark Geisert writes: > Could Cygwin itself provide a minimal /etc/resolv.conf pointing to > public DNS server(s)? Some users might object to Google's public DNS > (e.g. 8.8.8.8) though. No, this would be the job for any software that configures the DNS resolver. However, I'd prefer if no

Re: [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2

Brian Inglis writes: > I'd like to release 1.10 which is ABI compatible, as a test release with > libcurl4 depending on it (also mine), a lot of libraries depend on that, > and a lot of packages depend on those; try: > > $ cygcheck-dep -qSN libgsasl7 | less > > Release 2.0 jumps to

Re: Go or Rust Packages?

Marco Atzeri writes: > As it is written in go, you need to go back to the oldest version > written in C and from them forward to the current version. No you don't. Upstream opines that they already support Windows and Linux and thusly do not need Cygwin. The details vary, but Rust climbed up

Re: fuse

Mark Geisert writes: > I see that 'mtr' is another Cygwin package that makes use of a Windows > driver via libpcap. Maybe I can use mtr.cygport etc as a guide; I'm > unsure whether a Cygwin package should be including Windows drivers. No they should not, although there is at least one other

Re: [ITP] autoconf2.7

Corinna Vinschen writes: > Since Fedora did basically the same, as Ken pointed out, maybe we're > a bit meticulous if we create a new package for 2.7x? Well, if we don't, we're SOL if we hit an incompatibility that the Linux folks don't need to care about… that was why I originally suggested to

Re: [ITP] autoconf2.7

Ken Brown writes: > You should probably also adopt and update the autoconf package, which > provides the ac-wrapper script. The latest upstream version is at > > > https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-devel/autoconf-wrapper/files/ac-wrapper-15.sh Hmm. That looks wrong, the Gentoo

Re: autoconf

Jan Nijtmans via Cygwin-apps writes: > My 2c : Cygwin should - at least - allow people to install autoconf-2.71 > and - as long as the packages are prepared for it - things shouldn't break. As I said, I haven't looked at it in any detail, but it seems that autoconf is already multi-version, so I

Re: autoconf

Brian Inglis writes: >> How likely is it that they actually rely on that version already? > > Somewhat likely for some GNU packages and gnulib macros that specify > version prereqs: AC_PREREQ is used in 80 packages I have sources for. Most distros still package 2.69 or even earlier and that

Re: [ITA] openssl, openssl10, mingw64-{i686,x86_64}-openssl

Marco Atzeri via Cygwin-apps writes: > no problem for the 3 orphaned, but we should ask Corinna about openssl She's said numerous times that she doesn't really want it… I wouldn't mind to just co-maintain in any case. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk

Re: [ITP] aide 0.17.3

Jason Pyeron writes: > Not sure I understand this, that file is explicitly patched to build. See: > > A aide-0.17.3-1.cygwin.patch Give that patch file a different name (just changing the . before cygwin to a - would suffice) and add it to PATCH_URI in the cygport file instead.

Re: Question about 'provides' and emacs packaging

Ken Brown via Cygwin-apps writes: > I've only tested setup so far, not calm. Jon, if you're reading this, > does calm allow 'requires' and 'provides' to contain arbitrary names > that are not package names? Yes, Perl is using that to ensure that the distribution packages get updated according to

Re: autorebase and user-installed dynamic objects

Ken Brown via Cygwin-apps writes: > $ ls -al /var/cache/rebase/ > total 579 > drwxr-xr-x+ 1 kbrown-admin None 0 2021-09-27 08:35 ./ > drwxr-xr-x+ 1 kbrown-admin None 0 2021-09-27 08:35 ../ > -rw-r--r-- 1 kbrown-admin None115 2021-09-27 08:35 fullrebase.done > -rw-r--r-- 1

Re: autorebase and user-installed dynamic objects

Ken Brown via Cygwin-apps writes: > I just tried to do a full rebase (by running 'rebase-trigger full'), > but it seems that files from installed packages aren't being rebased. > Looking at /var/cache/rebase, it looks like the files in rebase_pkg > aren't making it into rebase_all. It should

Re: autorebase and user-installed dynamic objects

Ken Brown via Cygwin-apps writes: > 1. Modify rebaseall and rebaselst to recognize 'eln' as a suffix and > to recognize the standard directory where emacs will install the > system-wide .eln files (corresponding to the preloaded libraries). That would be which directory? > 2. Create a script

Re: Please remove a tag 'playground' accidentally pushed to git/cygwin-packages/schroedinger-coordgenlibs.git

Lemures Lemniscati via Cygwin-apps writes: > I've accidentally pushed a tag named 'playground' to the repository > ssh://cygwin.com/git/cygwin-packages/schroedinger-coordgenlibs > ( https://cygwin.com/git/?p=git/cygwin-packages/schroedinger-coordgenlibs.git > ) > > Anyone with the privilege,

Re: is postfix ORPHANED?

Jason Pyeron writes: > Is postfix ORPHANED? If so I can do an ITA. Christian Franke is the current maintainer per the official documentation. https://cygwin.com/cygwin/packages/summary/postfix-src.html Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Re: grep, gzip, readline, dash

Brian Inglis writes: > I can try that next time with dash (see below). From the setup > extracts below you can see that does not change the previous two > releases kept. Yes, test and non-test releases are counted seperately. > I thought in recent discussion, stable releases had to be bumped to

Re: Is it possible to 'cygport upload' with same p-v-r?

Mark Geisert writes: > I'd like to re-spin the latest version of cygutils, that is, upload > newer files with the same release number (1.4.16-5). Is this > possible, or do we now always change the release# when uploading? Re-spin == re-release, so you need to increase the release number. Test

Re: github password policy

Thomas Wolff writes: > As I cannot update mintty anymore right now from the git command line, > is any maintainer here impacted by the same issue and can help out > with some advice how to get rid of this nuisance? Do. Not. Use. GitHub. The raison raison d'être for GitHub is and always has been

Re: attention alternatives maintainer

Doug Henderson via Cygwin-apps writes: > I will volunteer to be the alternatives maintainer. I may need some > help, though. Appreciated. > The package has not been released for over 10 years, for cygwin 1.7, I > think. The download location is worse than 404, it is "We can’t > connect to the

Re: attention alternatives maintainer

Doug Henderson via Cygwin-apps writes: > Please update alternatives to work properly for a first time install > of an alternative when CYGWIN=winsymlinks:nativestrict. I do not think of this as a bug in alternatives. POSIX programs that create symlinks to non-existing files are perfectly valid

Re: GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]

Jon Turney writes: > I'd like feedback on what other improvements are needed for this to > become the preferable way to build packages. As long as you have to have a GitHub account to look at the results I won't be able to use it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb

Re: scallywag build anomaly

Marco Atzeri via Cygwin-apps writes: > can you tell me why scallywag building udunits Oh, and change the homepage URL to use https://, please. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ:

Re: scallywag build anomaly

Marco Atzeri via Cygwin-apps writes: > can you tell me why scallywag building udunits > > https://ci.appveyor.com/project/cygwin/scallywag/builds/39274227 > https://ci.appveyor.com/project/cygwin/scallywag/builds/39274227/job/lyhogat2ku23p8lh > > has decided for a Windows build instead of a Cygwin

Re: cygport test has zero exit status on failures

Jason Pyeron writes: > If I have a CI build for *.cygport - is it expected to have > conditional logic based on which package is being processed? Not necessarily, I understand you were talking about default behaviour and how the current default doesn't match your / your CI's expectation. To

Re: cygport test has zero exit status on failures

Jason Pyeron writes: > What is the historic rationale behind the "OR true" after the make > check? Not historic for the most part, I'd say. Cygport can also do cross-builds of packages and in those cases the tests will seldomly work (at all or at least partly) unless upstream walked the extra

Re: [PATCH setup] Add new option '--compact-os'

Christian Franke writes: >> Is this an assertion that there are no .bz2, .lzma, .zst etc. files >> in the install? >> > > No, but there are only a few occurrences in packages (except src > packages). Extension .bz2 occurs more often, so it should possibly be > added. Adding all compression

Re: cygport test has zero exit status on failures

Jason Pyeron writes: > Cygport test is not returning a non zero exit status on failure! Is > this expected? Yes, it is using 'make -k' under the hood. Again, if you need to do something else than what the standard invocation provides, you would generally write your own src_test() function.

Re: [PATCH setup] Handle '--packages package=version'

Jon Turney writes: > Handle '--packages package=version' to allow specifing the version of a > package to install on the command line. In my internal setup.ini rewriter script I accept both actual versions as well as "curr" (no-op), "prev" and "test". Regards, Achim. -- +<[Q+ Matrix-12

Re: A problem while building xapian-bindindgs for python 3.6 on i686

Lemures Lemniscati via Cygwin-apps writes: > I tried it by 'rebase -s $@' Make that 'rebase -sO $@' since you don't want to rebase the system DLL. > But, sadly, no improvement. Well, you'd generally start with figuring out where the error message comes from and then try to work your way back as

Re: libgccjit-0

Ken Brown via Cygwin-apps writes: > Sorry, I spoke too soon. It's not even working right on x86_64. In > my first build, the ordinary byte-compiled files (.elc) were already > present, and that somehow prevented the native-compiled files (.eln) > from being built. I just tried 'make bootstrap'

Re: [ITA] fortune-mod - please review

Brian Inglis writes: > On 2021-04-11 13:44, Achim Gratz wrote: >> Brian Inglis writes: >>> I just ran cpan Path:Tiny which also updated Unicode::UTF8, >>> Test::MockRandom, and Test::FailWarnings. >> Leave your hands off CPAN when you do packaging. > > I would like to, but do not know how else to

Re: [Attn. Maintainers] prepare your packages for release of perl-5.32

Jon Turney writes: libsolvperl-solvJon Turney >> I'd be sad to see this go since I was planning on replacing my >> hand-written dependency resolution with it. It's not urgent, however. > > This was an oversight on my part, rather than

Re: binutils 2.36.1

Mark Geisert writes: > I have now built and installed x86 binutils 2.36.1 locally. I've been > able to build the Cygwin DLL and mosh without issues. I suspect you > might be right on the edge of running out of address space given your > symptoms are erratically recurring and it's on x86. I

Re: [Attn. Maintainers] prepare your packages for release of perl-5.32

Jon Turney writes: > I've fixed what I needed to in the relarea, so this update can proceed > when Achim gives the go ahead. Please upload your packages, but please double-check that there is a dependency on perl5_032 in the hints. If everything works as intended, then setup will not update to

Re: [Attn. Maintainers] prepare your packages for release of perl-5.32

Jon Turney writes: >> libsolvperl-solvJon Turney I'd be sad to see this go since I was planning on replacing my hand-written dependency resolution with it. It's not urgent, however. >> perl-Crypt-OpenSSL-ECDSA perl-Crypt-OpenSSL-ECDSA

Re: [Attn. Maintainers] prepare your packages for release of perl-5.32

marco atzeri via Cygwin-apps writes: > 4 built > > GraphicsMagick Marco Atzeri > ImageMagick Marco Atzeri > irssiMarco Atzeri > postgresql Marco Atzeri > >> I

  1   2   >