Re: native symlinks and non-existent targets
On Mon, Apr 29, 2024 at 4:11 PM Csaba Ráduly wrote: > > On 25/04/2024 15:15, Jon Turney via Cygwin wrote: > > On 24/04/2024 23:36, Christopher Layne via Cygwin wrote: > > [...] > >> If it isn't true then this seems trivial to fix. > > > > This assertion is trivially disproven by the lack of a patch attached. :) > > > > > I don't think this is worth a gold star, but a jester's cap is surely > warranted :) I disagree. "This assertion is trivially disproven by the lack of a patch attached." is totally worth a gold star Regards, Lee -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ITA] bash-completion/-devel
I would like to co-maintain or adopt and revive the above package, which was adopted by Eric but not updated since Yaakov. 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 Scallywag runs: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=bash-completion Bash Completions and development bash-completion is a collection of shell functions that use the programmable completion feature of bash. For more information see the project home page: https://github.com/scop/bash-completion See below for details of changes: https://github.com/scop/bash-completion/blob/master/CHANGELOG.md bash-completion Bash Completions Existing package: https://cygwin.com/packages/summary/bash-completion.html bash-completion-devel Bash Completions (development) Existing package: https://cygwin.com/packages/summary/bash-completion-devel.html
Re: native symlinks and non-existent targets
On 25/04/2024 15:15, Jon Turney via Cygwin wrote: On 24/04/2024 23:36, Christopher Layne via Cygwin wrote: [...] If it isn't true then this seems trivial to fix. This assertion is trivially disproven by the lack of a patch attached. :) I don't think this is worth a gold star, but a jester's cap is surely warranted :) Csaba -- Life is complex, with real and imaginary parts. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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.
Re: OpenSSL 3.0.14
FOPPE, JEFFERY B CIV USAF AFMC AFLCMC/WFRQ via Cygwin writes: > Is the OpenSSL 3.0.14 package going to be released soon? You should ask that question upstream first. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
OpenSSL 3.0.14
Is the OpenSSL 3.0.14 package going to be released soon? Jeff Foppe AFLCMC/WFRQ -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
XDMCP connection hangs, then blanks, after a while
I've enabled XDMCP on a local (debian/lightdm) box, and can successfully connect to it from Cygwin using a modified version of startxwin in order to launch /usr/bin/XWin :1 -clipboard -dpi 100 -query [my host] -auth [me]/.serverauth.6351 All works well, useful work is done, go and have a coffee, come back and it's frozen (cursor follows mouse, but no kbd or click has any effect). Leave it a while longer, and it goes black. I _think_ the problem is at the Cygwin end, because if I ssh to the Linux box, I can, for example, connect to and use an (x)emacs instance I launched inside the XDMCP instance while it was still working. But the changes to that editor window are not reflected on what I can see (but not affect) on the Cygwin viewer. Any suggestions welcome, wrt configuration, XWin args or debugging steps I might try, on either side. And yes, I do know about vnc, and will probably give up and go back to that, but it has some frustrating niggles of its own... Thanks, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND e-mail: h...@inf.ed.ac.uk URL: https://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
