Re: Retiring setup.hint
On 13/11/2017 19:59, Thomas Wolff wrote: Am 25.10.2017 um 21:42 schrieb Jon Turney: I propose that calm will stop accepting uploads containing setup.hint some time shortly after 2017-11-18. So, firstly this plan has been superseded... This is approximately one year after the cygport release [1] which, stopped generating these files, so if you're using cygport >= 0.23.0, no action is needed. Warnings that you need to upgrade cygport have been generated for more than 6 months [2]. After setup.hint uploads are disabled, any remaining setup.hint in the cygwin release on sourceware.org will be migrated to pvr.hint(s), as per [3]. [1] https://cygwin.com/ml/cygwin-announce/2016-11/msg00078.html [2] https://cygwin.com/ml/cygwin-apps/2017-04/msg00024.html [3] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html I would appreciate to see some explanation about this. Why the change and what are package maintainers expected to do? ... so, you don't have to do anything. I hope that the:"WARNING: '/sourceware/cygwin-staging/home/Thomas Wolff/x86_64/release/mintty/setup.hint' seen, please update to cygport >= 0.23.0" in the mails you received from calm appropriately indicates the expectation that I'd like you to update the version of cygport you are using, when convenient for you. If calm can simply "rename setup.hint to pvr.hint", what's the purpose of all this? I like to think what I wrote was a bit more nuanced than that. "If the appropriate pvr cannot be determined [...], the upload will fail" In the (common) case where a setup.hint and package archives for a single version are uploaded, renaming is possible. But there are less common, but permitted scenarios where this is not possible, e.g.: - If you decide to upload e.g. 2.9.0-1 and test version 3.0.0-1 at the same time. Not recording the dependencies for these versions separately fundamentally does not work (see [1]) - Uploading just a replacement setup.hint for an existing version is no longer permitted under these rules (but you can still upload a replacement pvr.hint for a specific version) It would have been nice if it had occurred to me that I could do this renaming trick a bit earlier, though... [1] https://cygwin.com/ml/cygwin-apps/2016-06/msg00069.html
Re: Retiring setup.hint
Thomas Wolff writes: > If calm can simply "rename setup.hint to pvr.hint", what's the purpose > of all this? One of the purposes is that dependencies can and do change over time and eventually we will want to have separate dependencies for each released package like everybody else does. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Retiring setup.hint
Am 25.10.2017 um 21:42 schrieb Jon Turney: I propose that calm will stop accepting uploads containing setup.hint some time shortly after 2017-11-18. This is approximately one year after the cygport release [1] which, stopped generating these files, so if you're using cygport >= 0.23.0, no action is needed. Warnings that you need to upgrade cygport have been generated for more than 6 months [2]. After setup.hint uploads are disabled, any remaining setup.hint in the cygwin release on sourceware.org will be migrated to pvr.hint(s), as per [3]. [1] https://cygwin.com/ml/cygwin-announce/2016-11/msg00078.html [2] https://cygwin.com/ml/cygwin-apps/2017-04/msg00024.html [3] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html I would appreciate to see some explanation about this. Why the change and what are package maintainers expected to do? If calm can simply "rename setup.hint to pvr.hint", what's the purpose of all this? Thomas
Re: Retiring setup.hint
On Nov 13 11:39, Jon Turney wrote: > On 25/10/2017 22:18, Corinna Vinschen wrote: > > On Oct 25 21:46, Jon Turney wrote: > > > On 25/10/2017 21:23, Corinna Vinschen wrote: > > > > On Oct 25 20:42, Jon Turney wrote: > > > > > > > > > > I propose that calm will stop accepting uploads containing setup.hint > > > > > some > > > > > time shortly after 2017-11-18. > > Better plan: when uploaded, calm will rename a setup.hint file to pvr.hint. > > (If the appropriate pvr cannot be determined (from the name of tar files in > the same directory), or the setup.hint contains lines which aren't valid in > a pvr.hint, the upload will fail) > > I deployed an update to calm today which does this. > > (It also has some preliminary support for depends:, obsoletes:, > build-depends: hints, along with some cosmetic fixes) > > > > > > This is approximately one year after the cygport release [1] which, > > > > > stopped > > > > > generating these files, so if you're using cygport >= 0.23.0, no > > > > > action is > > > > > needed. > > > > > > > > > > Warnings that you need to upgrade cygport have been generated for > > > > > more than > > > > > 6 months [2]. > > > > > > > > > > After setup.hint uploads are disabled, any remaining setup.hint in the > > > > > cygwin release on sourceware.org will be migrated to pvr.hint(s), as > > > > > per > > > > > [3]. > > > > > > > > > > [1] https://cygwin.com/ml/cygwin-announce/2016-11/msg00078.html > > > > > [2] https://cygwin.com/ml/cygwin-apps/2017-04/msg00024.html > > > > > [3] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html > > > > > > > > I'm still generating setup.hint files for the Cygwin package itself. > > > > > > > > Please have a look into cygwin's cygport file. Do we have an *easy* > > > > replacement for creating test releases from cygport in the meantime? > > > > > > > > Ideally I can simply call cygport with a --test parameter or some such > > > > to create a test release. > > > > > > See https://cygwin.com/ml/cygwin-apps/2017-10/msg00017.html which contains > > > my patch to do this, and an offer to implement this in whatever way is > > > acceptable to Yaakov. > > > > Looks good to me. > > I'll hold off on doing anything further until we've had some successes with > the cygwin package to show this is working to your satisfaction. Thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Retiring setup.hint
On 25/10/2017 22:18, Corinna Vinschen wrote: On Oct 25 21:46, Jon Turney wrote: On 25/10/2017 21:23, Corinna Vinschen wrote: On Oct 25 20:42, Jon Turney wrote: I propose that calm will stop accepting uploads containing setup.hint some time shortly after 2017-11-18. Better plan: when uploaded, calm will rename a setup.hint file to pvr.hint. (If the appropriate pvr cannot be determined (from the name of tar files in the same directory), or the setup.hint contains lines which aren't valid in a pvr.hint, the upload will fail) I deployed an update to calm today which does this. (It also has some preliminary support for depends:, obsoletes:, build-depends: hints, along with some cosmetic fixes) This is approximately one year after the cygport release [1] which, stopped generating these files, so if you're using cygport >= 0.23.0, no action is needed. Warnings that you need to upgrade cygport have been generated for more than 6 months [2]. After setup.hint uploads are disabled, any remaining setup.hint in the cygwin release on sourceware.org will be migrated to pvr.hint(s), as per [3]. [1] https://cygwin.com/ml/cygwin-announce/2016-11/msg00078.html [2] https://cygwin.com/ml/cygwin-apps/2017-04/msg00024.html [3] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html I'm still generating setup.hint files for the Cygwin package itself. Please have a look into cygwin's cygport file. Do we have an *easy* replacement for creating test releases from cygport in the meantime? Ideally I can simply call cygport with a --test parameter or some such to create a test release. See https://cygwin.com/ml/cygwin-apps/2017-10/msg00017.html which contains my patch to do this, and an offer to implement this in whatever way is acceptable to Yaakov. Looks good to me. I'll hold off on doing anything further until we've had some successes with the cygwin package to show this is working to your satisfaction. (I haven't yet started on writing a tool to do the migration, in any case)
Re: Retiring setup.hint
On Oct 25 21:46, Jon Turney wrote: > On 25/10/2017 21:23, Corinna Vinschen wrote: > > On Oct 25 20:42, Jon Turney wrote: > > > > > > I propose that calm will stop accepting uploads containing setup.hint some > > > time shortly after 2017-11-18. > > > > > > This is approximately one year after the cygport release [1] which, > > > stopped > > > generating these files, so if you're using cygport >= 0.23.0, no action is > > > needed. > > > > > > Warnings that you need to upgrade cygport have been generated for more > > > than > > > 6 months [2]. > > > > > > After setup.hint uploads are disabled, any remaining setup.hint in the > > > cygwin release on sourceware.org will be migrated to pvr.hint(s), as per > > > [3]. > > > > > > [1] https://cygwin.com/ml/cygwin-announce/2016-11/msg00078.html > > > [2] https://cygwin.com/ml/cygwin-apps/2017-04/msg00024.html > > > [3] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html > > > > I'm still generating setup.hint files for the Cygwin package itself. > > > > Please have a look into cygwin's cygport file. Do we have an *easy* > > replacement for creating test releases from cygport in the meantime? > > > > Ideally I can simply call cygport with a --test parameter or some such > > to create a test release. > > See https://cygwin.com/ml/cygwin-apps/2017-10/msg00017.html which contains > my patch to do this, and an offer to implement this in whatever way is > acceptable to Yaakov. Looks good to me. > > As long as we don't have that, I'm inclined to veto the idea to drop > > setup.hint. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Retiring setup.hint
On Oct 25 20:42, Jon Turney wrote: > > I propose that calm will stop accepting uploads containing setup.hint some > time shortly after 2017-11-18. > > This is approximately one year after the cygport release [1] which, stopped > generating these files, so if you're using cygport >= 0.23.0, no action is > needed. > > Warnings that you need to upgrade cygport have been generated for more than > 6 months [2]. > > After setup.hint uploads are disabled, any remaining setup.hint in the > cygwin release on sourceware.org will be migrated to pvr.hint(s), as per > [3]. > > [1] https://cygwin.com/ml/cygwin-announce/2016-11/msg00078.html > [2] https://cygwin.com/ml/cygwin-apps/2017-04/msg00024.html > [3] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html I'm still generating setup.hint files for the Cygwin package itself. Please have a look into cygwin's cygport file. Do we have an *easy* replacement for creating test releases from cygport in the meantime? Ideally I can simply call cygport with a --test parameter or some such to create a test release. As long as we don't have that, I'm inclined to veto the idea to drop setup.hint. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Retiring setup.hint
I propose that calm will stop accepting uploads containing setup.hint some time shortly after 2017-11-18. This is approximately one year after the cygport release [1] which, stopped generating these files, so if you're using cygport >= 0.23.0, no action is needed. Warnings that you need to upgrade cygport have been generated for more than 6 months [2]. After setup.hint uploads are disabled, any remaining setup.hint in the cygwin release on sourceware.org will be migrated to pvr.hint(s), as per [3]. [1] https://cygwin.com/ml/cygwin-announce/2016-11/msg00078.html [2] https://cygwin.com/ml/cygwin-apps/2017-04/msg00024.html [3] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html
Re: residual setup.hint
On 06/04/2017 04:39, Marco Atzeri wrote: On 06/04/2017 00:42, Jon Turney wrote: I assume we are all using latest cygport and uploading only package-revison.hint :hollow laughter: Yes, one would assume that, but it turns out not to be the case :) It is not so bad. For what I see in the last 3 months only cygwin, mintty and gcc packages where using setup.hint And probably they are all cross-compiled .. I deployed a small update to calm today: Unneeded setup.hint files will now be removed from the release area. Additionally, a warning telling you to upgrade cygport will now be given when uploading a setup.hint file.
Re: residual setup.hint
On 06/04/2017 00:42, Jon Turney wrote: I assume we are all using latest cygport and uploading only package-revison.hint :hollow laughter: Yes, one would assume that, but it turns out not to be the case :) It is not so bad. For what I see in the last 3 months only cygwin, mintty and gcc packages where using setup.hint And probably they are all cross-compiled .. Regards Marco
Re: residual setup.hint
On 05/04/2017 21:55, Marco Atzeri wrote: On 04/04/2017 19:38, Jon Turney wrote: On 04/04/2017 14:28, Marco Atzeri wrote: Not sure if "calm" is excluding them, but I noticed for some packages we have now an excess of "setup.hint" as all existing revision have their own package-revison.hint These old setup.hint files should be benign, unless they are recording obsolete dependencies which aren't needed any more. I assume there is already some case, but I will need to check to show some evidence. Actually, after looking at the code today, I think in the case where the setup.hint is obsolete, it doesn't contribute anything to dependencies, but I'd need to test that to be sure... Anyhow, I worked out a relatively simple way to clean these up, so I will do that. [...] Is a cleaning needed ? Eventually, yes. Unfortunately, a maintainer removing these files via '-setup.hint' is not permitted, as I haven't implemented it due to the complexity of determining if that is safe. I've noted that there needs to be a migration plan for this (See [1]) I guess the first stage of which is to turn off uploads containing setup.hint (as generated by older versions of cygport), but I'm not sure we've reached that point in time, yet. [1] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html I assume we are all using latest cygport and uploading only package-revison.hint :hollow laughter: Yes, one would assume that, but it turns out not to be the case :)
Re: residual setup.hint
On 04/04/2017 19:38, Jon Turney wrote: On 04/04/2017 14:28, Marco Atzeri wrote: Not sure if "calm" is excluding them, but I noticed for some packages we have now an excess of "setup.hint" as all existing revision have their own package-revison.hint These old setup.hint files should be benign, unless they are recording obsolete dependencies which aren't needed any more. I assume there is already some case, but I will need to check to show some evidence. [...] Is a cleaning needed ? Eventually, yes. Unfortunately, a maintainer removing these files via '-setup.hint' is not permitted, as I haven't implemented it due to the complexity of determining if that is safe. I've noted that there needs to be a migration plan for this (See [1]) I guess the first stage of which is to turn off uploads containing setup.hint (as generated by older versions of cygport), but I'm not sure we've reached that point in time, yet. [1] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html I assume we are all using latest cygport and uploading only package-revison.hint Regards Marco
Re: residual setup.hint
On 04/04/2017 14:28, Marco Atzeri wrote: Not sure if "calm" is excluding them, but I noticed for some packages we have now an excess of "setup.hint" as all existing revision have their own package-revison.hint These old setup.hint files should be benign, unless they are recording obsolete dependencies which aren't needed any more. [...] Is a cleaning needed ? Eventually, yes. Unfortunately, a maintainer removing these files via '-setup.hint' is not permitted, as I haven't implemented it due to the complexity of determining if that is safe. I've noted that there needs to be a migration plan for this (See [1]) I guess the first stage of which is to turn off uploads containing setup.hint (as generated by older versions of cygport), but I'm not sure we've reached that point in time, yet. [1] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html
residual setup.hint
Hi, Not sure if "calm" is excluding them, but I noticed for same packages we have now an excess of "setup.hint" as all existing revision have their own package-revison.hint libopenssl100/ 26-Jan-2017 20:44 - openssl-debuginfo/ 26-Jan-2017 20:44 - openssl-devel/ 26-Jan-2017 20:44 - openssl-perl/ 26-Jan-2017 20:44 - md5.sum26-Jan-2017 21:44 442 openssl-1.0.2j-1-src.tar.xz26-Sep-2016 14:12 5M openssl-1.0.2j-1.hint 26-Sep-2016 14:12 348 openssl-1.0.2j-1.tar.xz26-Sep-2016 14:12572K openssl-1.0.2k-1-src.tar.xz26-Jan-2017 20:25 5M openssl-1.0.2k-1.hint 26-Jan-2017 20:25 348 openssl-1.0.2k-1.tar.xz26-Jan-2017 20:25570K setup.hint 04-May-2016 16:37 348 sha512.sum 26-Jan-2017 21:441207 Is a cleaning needed ? Regards Marco
setup.hint
Hi Jon, following our previous discussion about setup.hint transition. As Yaakov asked to rebuild mutt, that I just rebuild last week I have the problem of what to do of the current "setup.hint", as "calm" did not allow to remove last time. Current situation mutt-1.7.0-1-src.tar.xz 27-Aug-2016 21:00 4M mutt-1.7.0-1.tar.xz 27-Aug-2016 21:00 1M mutt-1.7.1-1-src.tar.xz 09-Oct-2016 13:26 4M mutt-1.7.1-1.hint 09-Oct-2016 13:26 242 mutt-1.7.1-1.tar.xz 09-Oct-2016 13:26 1M setup.hint27-Aug-2016 21:00 242 If I upload a mutt-1.7.1-2 version and remove completely mutt-1.7.0-1 the remaining setup.hint will refer to a not more existing version. Let me know how to proceed. No hurry, I will have no time for a new release before next week anyway. Regards Marco
Re: [PATCH cygport] Write and upload pvr.hint rather than setup.hint
On 2016-09-01 12:12, Jon Turney wrote: On 30/08/2016 13:24, Jon Turney wrote: For a source-only package, rather than just a skip: key, write category:, requires:, ldesc: and sdesc: keys as well. This had a rather unfortunate bug which made it always generate a source-only package hint (i.e. with skip:), rather than only when needed because nothing else has generated the package hint. Updated version attached. Merged and pushed. -- Yaakov
Re: [PATCH cygport] Write and upload pvr.hint rather than setup.hint
On 30/08/2016 13:24, Jon Turney wrote:
For a source-only package, rather than just a skip: key, write category:,
requires:, ldesc: and sdesc: keys as well.
This had a rather unfortunate bug which made it always generate a
source-only package hint (i.e. with skip:), rather than only when needed
because nothing else has generated the package hint.
Updated version attached.
From 1b46756d8b75a296f6802630061c5f56dcf0a9d5 Mon Sep 17 00:00:00 2001
From: Jon Turney <jon.tur...@dronecode.org.uk>
Date: Thu, 23 Jun 2016 18:32:18 +0100
Subject: [PATCH cygport] Write and upload pvr.hint rather than setup.hint
For a source-only package, rather than just a skip: key, write category:,
requires:, ldesc: and sdesc: keys as well.
v2:
Only generate a source-only package hint with skip: when nothing else has
generated the package hint, rather than always
Signed-off-by: Jon Turney <jon.tur...@dronecode.org.uk>
---
lib/pkg_pkg.cygpart| 48 +++-
lib/pkg_upload.cygpart | 6 +++---
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index ef2db6e..d569844 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -536,7 +536,7 @@ __pkg_dist() {
#v* Packaging/CATEGORY
# DESCRIPTION
# A string containing one or more setup package categories. This will be
-# used as the category: field of auto-generated setup.hint files.
+# used as the category: field of auto-generated .hint files.
# NOTE
# A list of official categories is available on the
# |html http://cygwin.com/setup.html#setup.hint;>Cygwin website.
@@ -546,7 +546,7 @@ __pkg_dist() {
#v* Packaging/PKG_CATEGORY
# DESCRIPTION
# A string containing one or more setup package categories. This will be
-# used as the category: field of the corresponding auto-generated setup.hint
+# used as the category: field of the corresponding auto-generated .hint
# file.
#
# Note that the PKG_CATEGORY name is descriptive rather than literal,
@@ -562,14 +562,14 @@ __pkg_dist() {
#v* Packaging/SUMMARY
# DESCRIPTION
# A one-line summary of the package. This will be used as the sdesc: field
-# of auto-generated setup.hint files.
+# of auto-generated .hint files.
# SEE ALSO
# PKG_SUMMARY
#
#v* Packaging/PKG_SUMMARY
# DESCRIPTION
# A one-line summary of the subpackage. This will be used as the sdesc:
-# field of the corresponding auto-generated setup.hint file.
+# field of the corresponding auto-generated .hint file.
#
# Note that the PKG_SUMMARY name is descriptive rather than literal,
# where "PKG" should be substituted with the name of the binary package
@@ -581,14 +581,14 @@ __pkg_dist() {
#v* Packaging/DESCRIPTION
# DESCRIPTION
# A short paragraph description of the package. This will be used as the
-# ldesc: field of auto-generated setup.hint files.
+# ldesc: field of auto-generated .hint files.
# SEE ALSO
# PKG_DESCRIPTION
#
#v* Packaging/PKG_DESCRIPTION
# DESCRIPTION
# A short paragraph description of the subpackage. This will be used as the
-# ldesc: field of the corresponding auto-generated setup.hint file.
+# ldesc: field of the corresponding auto-generated .hint file.
#
# Note that the PKG_DESCRIPTION name is descriptive rather than literal,
# where "PKG" should be substituted with the name of the binary package
@@ -601,7 +601,7 @@ __pkg_dist() {
# DESCRIPTION
# A single-line strings containing a list of packages on which this
# package depends. This will be added to the requires: field of the
-# auto-generated setup.hint file.
+# auto-generated .hint file.
# NOTES
# * cygport attempts to automatically detect many types of package
#dependencies, which do not need to be listed in REQUIRES. This is still
@@ -617,7 +617,7 @@ __pkg_dist() {
# DESCRIPTION
# A single-line strings containing a list of packages on which this
# package depends. This will be added to the requires: field of the
-# auto-generated setup.hint file.
+# auto-generated .hint file.
#
# Note that the PKG_REQUIRES name is descriptive rather than literal,
# where "PKG" should be substituted with the name of the binary package
@@ -684,7 +684,7 @@ __pkg_dist() {
if [ -f ${C}/${pkg_hint[${n}]%.hint}.hint ]
then
- cp ${C}/${pkg_hint[${n}]%.hint}.hint
${distdir}/${PN}/${distsubdir}/setup.hint;
+ cp ${C}/${pkg_hint[${n}]%.hint}.hint
${distdir}/${PN}/${distsubdir}/${pkg_name[${n}]}-${PVR}.hint;
elif [ -n "${!pkg_category_var:-${CATEGORY}}" -a -n
"${!pkg_summary_var:-${SUMMARY}}" ]
then
if [ "${CBUILD##*-}" = "cygwin" ]
@@ -695,10 +695,10 @@ __pkg_dist() {
__step "${pkg_name[${n}]} requires:
${pkg_bin_requires} ${!pkg_re
[PATCH cygport] Write and upload pvr.hint rather than setup.hint
For a source-only package, rather than just a skip: key, write category:,
requires:, ldesc: and sdesc: keys as well.
Signed-off-by: Jon Turney <jon.tur...@dronecode.org.uk>
---
lib/pkg_pkg.cygpart| 46 ++
lib/pkg_upload.cygpart | 6 +++---
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 702c5c2..294260d 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -536,7 +536,7 @@ __pkg_dist() {
#v* Packaging/CATEGORY
# DESCRIPTION
# A string containing one or more setup package categories. This will be
-# used as the category: field of auto-generated setup.hint files.
+# used as the category: field of auto-generated .hint files.
# NOTE
# A list of official categories is available on the
# |html http://cygwin.com/setup.html#setup.hint;>Cygwin website.
@@ -546,7 +546,7 @@ __pkg_dist() {
#v* Packaging/PKG_CATEGORY
# DESCRIPTION
# A string containing one or more setup package categories. This will be
-# used as the category: field of the corresponding auto-generated setup.hint
+# used as the category: field of the corresponding auto-generated .hint
# file.
#
# Note that the PKG_CATEGORY name is descriptive rather than literal,
@@ -562,14 +562,14 @@ __pkg_dist() {
#v* Packaging/SUMMARY
# DESCRIPTION
# A one-line summary of the package. This will be used as the sdesc: field
-# of auto-generated setup.hint files.
+# of auto-generated .hint files.
# SEE ALSO
# PKG_SUMMARY
#
#v* Packaging/PKG_SUMMARY
# DESCRIPTION
# A one-line summary of the subpackage. This will be used as the sdesc:
-# field of the corresponding auto-generated setup.hint file.
+# field of the corresponding auto-generated .hint file.
#
# Note that the PKG_SUMMARY name is descriptive rather than literal,
# where "PKG" should be substituted with the name of the binary package
@@ -581,14 +581,14 @@ __pkg_dist() {
#v* Packaging/DESCRIPTION
# DESCRIPTION
# A short paragraph description of the package. This will be used as the
-# ldesc: field of auto-generated setup.hint files.
+# ldesc: field of auto-generated .hint files.
# SEE ALSO
# PKG_DESCRIPTION
#
#v* Packaging/PKG_DESCRIPTION
# DESCRIPTION
# A short paragraph description of the subpackage. This will be used as the
-# ldesc: field of the corresponding auto-generated setup.hint file.
+# ldesc: field of the corresponding auto-generated .hint file.
#
# Note that the PKG_DESCRIPTION name is descriptive rather than literal,
# where "PKG" should be substituted with the name of the binary package
@@ -601,7 +601,7 @@ __pkg_dist() {
# DESCRIPTION
# A single-line strings containing a list of packages on which this
# package depends. This will be added to the requires: field of the
-# auto-generated setup.hint file.
+# auto-generated .hint file.
# NOTES
# * cygport attempts to automatically detect many types of package
#dependencies, which do not need to be listed in REQUIRES. This is still
@@ -617,7 +617,7 @@ __pkg_dist() {
# DESCRIPTION
# A single-line strings containing a list of packages on which this
# package depends. This will be added to the requires: field of the
-# auto-generated setup.hint file.
+# auto-generated .hint file.
#
# Note that the PKG_REQUIRES name is descriptive rather than literal,
# where "PKG" should be substituted with the name of the binary package
@@ -684,7 +684,7 @@ __pkg_dist() {
if [ -f ${C}/${pkg_hint[${n}]%.hint}.hint ]
then
- cp ${C}/${pkg_hint[${n}]%.hint}.hint
${distdir}/${PN}/${distsubdir}/setup.hint;
+ cp ${C}/${pkg_hint[${n}]%.hint}.hint
${distdir}/${PN}/${distsubdir}/${pkg_name[${n}]}-${PVR}.hint;
elif [ -n "${!pkg_category_var:-${CATEGORY}}" -a -n
"${!pkg_summary_var:-${SUMMARY}}" ]
then
if [ "${CBUILD##*-}" = "cygwin" ]
@@ -695,10 +695,10 @@ __pkg_dist() {
__step "${pkg_name[${n}]} requires:
${pkg_bin_requires} ${!pkg_requires_var}"
else
pkg_bin_requires=
- inform "ADD ${distsubdir:-${PN}} DLL
DEPENDENCIES TO ${PN}${distsubdir:+/}${distsubdir}/setup.hint"
+ inform "ADD ${distsubdir:-${PN}} DLL
DEPENDENCIES TO
${PN}${distsubdir:+/}${distsubdir}/${pkg_name[${n}]}-${PVR}.hint"
fi
- cat > ${distdir}/${PN}/${distsubdir}/setup.hint <<-_EOF
+ cat >
${distdir}/${PN}/${distsubdir}/${pkg_name[${n}]}-${PVR}.hint <<-_EOF
category: ${!pkg_category_var:-${CATEGORY}}
requires: ${pkg_bin_requires} ${!pkg_requires_var}
sdesc: "${!pkg_sum
Re: setup.hint documentation issues
On 17/02/2016 14:23, Jon Turney wrote: On 09/02/2016 17:10, Corinna Vinschen wrote: On Feb 9 13:18, Jon Turney wrote: * 'sdesc' text is mangled in setup.ini (but not the HTML package list) In particular, it is forced to start with a capital letter (which is incorrect when the sdesc starts with a command name which is properly lower-case, e.g. "dash shell", etc.), and any text up to and including the first colon is removed, presumably in an effort to prevent people writing the package name again, (which mangles perl and ruby module names in the description, e.g. "Ruby Net::HTTP persistent connection support", ""Perl Math::Int64 distribution", etc.) I'd suggest this mangling is removed, and sdesc starting "packagename:" is explicitly reported. Sounds good, but where is this mangling performed? Upset? Yes, upset currently does this mangling. This mangling is no longer done. Instead there is an attempt to enforce the rule (from [1]) that, "the package name should not be part of the description", by detecting a sdesc which starts "packagename:" or "packagename -", but this is probably fairly easy to defeat. [1] https://cygwin.com/setup.html
Re: setup.hint documentation issues
Jon Turney writes: >> OK, although we might need some sort of escaping in the long run. > > Yes, I have no problem with later adding escaping e.g. using '\', if > needed, since that can written with a character by character lexer. Indeed and it should also be possible to parse via regex. IN any case, that's not a problem we need to solve now. >> So the proposal is to remove skip or make it mandatory for source-only >> packages? > > I'm not sure. I think I tend towards removing it, since it doesn't > add any information. OK. > But currently cygport generates a setup.hint for source-only package > which only contains 'skip'. I'm not sure that's the best idea, as > having no sdesc, etc. means we can't describe the source package. Hmm. I guess Yaakov perhaps knows what that was supposed to achieve. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: setup.hint documentation issues
On Feb 17 14:23, Jon Turney wrote: > On 09/02/2016 17:10, Corinna Vinschen wrote: > >IMHO we don't need "skip". A source-only package should be > >automatically skipped anyway. What other reason do we need to ignore > >a package? > > Yes, this is why I ask the question. > > I don't see what 'skip' adds above automatically noticing that there are no > install tar files, only source tar files. Nuke it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: setup.hint documentation issues
On 09/02/2016 17:10, Corinna Vinschen wrote: On Feb 9 13:18, Jon Turney wrote: * 'sdesc' text is mangled in setup.ini (but not the HTML package list) In particular, it is forced to start with a capital letter (which is incorrect when the sdesc starts with a command name which is properly lower-case, e.g. "dash shell", etc.), and any text up to and including the first colon is removed, presumably in an effort to prevent people writing the package name again, (which mangles perl and ruby module names in the description, e.g. "Ruby Net::HTTP persistent connection support", ""Perl Math::Int64 distribution", etc.) I'd suggest this mangling is removed, and sdesc starting "packagename:" is explicitly reported. Sounds good, but where is this mangling performed? Upset? Yes, upset currently does this mangling. * Handling of double-quoted text seems over-complicated A multi-line double-quoted value is terminated only by a double-quote at the end of the line, and embedded double-quotes are silently transformed to single-quotes (e.g proj had a sdesc of ""The PROJ Cartographic Projections Software (utilities)", where the erroneous nested double-quote was being transformed to a single-quote) There is no escaping of embedded double-quotes, and no way to represent one. Additionally, spaces after the leading quote are magically removed. Additionally, genini requires that sdesc and ldesc are double-quoted, but upset does not. I'd suggest that double-quoting of those keys is made mandatory, and embedded double-quotes are forbidden, as this permits simpler processing of this text, lexing character by character. What about existing packages? I've fixed the existing uses on sourceware (which were proj and I think one other package I unfortunately didn't take note of) * It's not very clear what 'skip' represents The description "The skip line indicates that that package should not appear in setup. It is intended for directories that exist in the hierarchy that should not be considered." is a bit vague to me. It's not totally clear if it's intended for indicating directories which should be empty, source-only packages, or something else. upset knows enough to omit packages which have no install tarfiles (i.e. are source-only) from from setup.ini, irrespective of 'skip'. However, the presence of 'skip' also causes the package to be omitted from the HTML package list. I think cygport's behaviour has changed over time, but currently will mark source-packages as 'skip', however there are several packages that are source-only (e.g. attica), that are missing 'skip'. IMHO we don't need "skip". A source-only package should be automatically skipped anyway. What other reason do we need to ignore a package? Yes, this is why I ask the question. I don't see what 'skip' adds above automatically noticing that there are no install tar files, only source tar files.
Re: setup.hint documentation issues
Jon Turney writes: > I think currently UTF-8 displays correctly in the HTML package pages, > but neither encoding displays correctly in setup. > > I'd suggest that we specify UTF-8 and eventually fix setup to handle that. UTF-8 these days, please. > I'd suggest this mangling is removed, and sdesc starting > "packagename:" is explicitly reported. OK. > I'd suggest that double-quoting of those keys is made mandatory, and > embedded double-quotes are forbidden, as this permits simpler > processing of this text, lexing character by character. OK, although we might need some sort of escaping in the long run. > upset knows enough to omit packages which have no install tarfiles > (i.e. are source-only) from from setup.ini, irrespective of 'skip'. > > However, the presence of 'skip' also causes the package to be omitted > from the HTML package list. I could be wrong, but it seems it may have been intended to deal with packages that became obsolete, but the previous version was still kept. > I think cygport's behaviour has changed over time, but currently will > mark source-packages as 'skip', however there are several packages > that are source-only (e.g. attica), that are missing 'skip'. So the proposal is to remove skip or make it mandatory for source-only packages? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
setup.hint documentation issues
While I've been looking at replacement/improvement for the current upset script, I've come across some minor issues related to under-specification or under-documentation of setup.hint: * The encoding of setup.hint is unspecified. Historically both ISO-8859-1 and UTF-8 have been used. (e.g. libspiro used 'bézier' with an ISO-8859-1 e-acute, whereas calligra-l10n-nb uses 'Bokmål' with an UTF-8 a-ring. Various other hints use UTF-8 punctuation marks) I think currently UTF-8 displays correctly in the HTML package pages, but neither encoding displays correctly in setup. I'd suggest that we specify UTF-8 and eventually fix setup to handle that. * 'sdesc' text is mangled in setup.ini (but not the HTML package list) In particular, it is forced to start with a capital letter (which is incorrect when the sdesc starts with a command name which is properly lower-case, e.g. "dash shell", etc.), and any text up to and including the first colon is removed, presumably in an effort to prevent people writing the package name again, (which mangles perl and ruby module names in the description, e.g. "Ruby Net::HTTP persistent connection support", ""Perl Math::Int64 distribution", etc.) I'd suggest this mangling is removed, and sdesc starting "packagename:" is explicitly reported. * Handling of double-quoted text seems over-complicated A multi-line double-quoted value is terminated only by a double-quote at the end of the line, and embedded double-quotes are silently transformed to single-quotes (e.g proj had a sdesc of ""The PROJ Cartographic Projections Software (utilities)", where the erroneous nested double-quote was being transformed to a single-quote) There is no escaping of embedded double-quotes, and no way to represent one. Additionally, spaces after the leading quote are magically removed. Additionally, genini requires that sdesc and ldesc are double-quoted, but upset does not. I'd suggest that double-quoting of those keys is made mandatory, and embedded double-quotes are forbidden, as this permits simpler processing of this text, lexing character by character. * It's not very clear what 'skip' represents The description "The skip line indicates that that package should not appear in setup. It is intended for directories that exist in the hierarchy that should not be considered." is a bit vague to me. It's not totally clear if it's intended for indicating directories which should be empty, source-only packages, or something else. upset knows enough to omit packages which have no install tarfiles (i.e. are source-only) from from setup.ini, irrespective of 'skip'. However, the presence of 'skip' also causes the package to be omitted from the HTML package list. I think cygport's behaviour has changed over time, but currently will mark source-packages as 'skip', however there are several packages that are source-only (e.g. attica), that are missing 'skip'.
Re: setup.hint documentation issues
On Feb 9 13:18, Jon Turney wrote: > > While I've been looking at replacement/improvement for the current upset > script, I've come across some minor issues related to under-specification or > under-documentation of setup.hint: > > * The encoding of setup.hint is unspecified. > > Historically both ISO-8859-1 and UTF-8 have been used. (e.g. libspiro used > 'bézier' with an ISO-8859-1 e-acute, whereas calligra-l10n-nb uses 'Bokmål' > with an UTF-8 a-ring. Various other hints use UTF-8 punctuation marks) > > I think currently UTF-8 displays correctly in the HTML package pages, but > neither encoding displays correctly in setup. > > I'd suggest that we specify UTF-8 and eventually fix setup to handle that. ACK > * 'sdesc' text is mangled in setup.ini (but not the HTML package list) > > In particular, it is forced to start with a capital letter (which is > incorrect when the sdesc starts with a command name which is properly > lower-case, e.g. "dash shell", etc.), and any text up to and including the > first colon is removed, presumably in an effort to prevent people writing > the package name again, (which mangles perl and ruby module names in the > description, e.g. "Ruby Net::HTTP persistent connection support", ""Perl > Math::Int64 distribution", etc.) > > I'd suggest this mangling is removed, and sdesc starting "packagename:" is > explicitly reported. Sounds good, but where is this mangling performed? Upset? > * Handling of double-quoted text seems over-complicated > > A multi-line double-quoted value is terminated only by a double-quote at the > end of the line, and embedded double-quotes are silently transformed to > single-quotes (e.g proj had a sdesc of ""The PROJ Cartographic Projections > Software (utilities)", where the erroneous nested double-quote was being > transformed to a single-quote) > > There is no escaping of embedded double-quotes, and no way to represent one. > > Additionally, spaces after the leading quote are magically removed. > > Additionally, genini requires that sdesc and ldesc are double-quoted, but > upset does not. > > I'd suggest that double-quoting of those keys is made mandatory, and > embedded double-quotes are forbidden, as this permits simpler processing of > this text, lexing character by character. What about existing packages? > * It's not very clear what 'skip' represents > > The description "The skip line indicates that that package should not appear > in setup. It is intended for directories that exist in the hierarchy that > should not be considered." is a bit vague to me. > > It's not totally clear if it's intended for indicating directories which > should be empty, source-only packages, or something else. > > upset knows enough to omit packages which have no install tarfiles (i.e. are > source-only) from from setup.ini, irrespective of 'skip'. > > However, the presence of 'skip' also causes the package to be omitted from > the HTML package list. > > I think cygport's behaviour has changed over time, but currently will mark > source-packages as 'skip', however there are several packages that are > source-only (e.g. attica), that are missing 'skip'. IMHO we don't need "skip". A source-only package should be automatically skipped anyway. What other reason do we need to ignore a package? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Please fix your setup.hint files (was: [HEADSUP] requires to obsolete Perl packages)
There are a number of packages still requiring obsoleted Perl packages that I want to delete now, so these setup.hint files need to be fixed. Here is what I've found so far with a proposed replacement in parenthesis. perl_vendor (only on 32bit since it never existed on 64bit): === Yaakov Selkowitzdocbook2X (perl-XML-SAX) Yaakov Selkowitzfvwm, xmltoman (perl-XML-Parser) Yaakov Selkowitzlibexo1_0, svn_load_dirs (perl-URI) David Rothenberger svn_load_dirs (perl-URI) Yaakov Selkowitzsnownews (perl-XML-LibXML) Yaakov Selkowitzhtml2ps(perl-HTTP-Cookies perl-HTTP-Message) Corinna Vinschenpl (probably spurious) Remark: SWI Prolog doesn't compile from the source package. The current stable version 7.2.3 does with minimal changes to the cygport file (the source archive and directory is now "swipl" instead of "pl") and removal of the Cygwin specific patches (which might have been upstreamed). Some files are named differently and don't package into their sub-packages, but the main package seems to depend on perl-JSON for whatever reason, but I think that's a spurious match on "use JSON" (.pl is Prolog, not Perl in this case). Jon Turney writes: > Please ping the individual package maintainers to get the hints fixed. I'm still of the opinion that this list is the proper venue and all of them have been active in the last few weeks, but I've added them on Bcc: with the email addresses that they use for getting the mails from the sourceware uploads anyway. 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: Please fix your setup.hint files
Corinna Vinschen writes: >> Remark: SWI Prolog doesn't compile from the source package. > > It did when I created it. Well, certainly. :-) > Yes, it's spurious. I removed the perl_vendor from setup.hint for now. > I don't intend to repackage SWI-Prolog for a while. Thanks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: Please fix your setup.hint files (was: [HEADSUP] requires to obsolete Perl packages)
On Dec 17 19:27, Achim Gratz wrote: > > There are a number of packages still requiring obsoleted Perl packages > that I want to delete now, so these setup.hint files need to be fixed. > Here is what I've found so far with a proposed replacement in > parenthesis. > > perl_vendor (only on 32bit since it never existed on 64bit): > === > Yaakov Selkowitzdocbook2X (perl-XML-SAX) > Yaakov Selkowitzfvwm, xmltoman (perl-XML-Parser) > Yaakov Selkowitzlibexo1_0, svn_load_dirs (perl-URI) > David Rothenberger svn_load_dirs (perl-URI) > Yaakov Selkowitzsnownews (perl-XML-LibXML) > Yaakov Selkowitzhtml2ps(perl-HTTP-Cookies > perl-HTTP-Message) > Corinna Vinschenpl (probably spurious) > > Remark: SWI Prolog doesn't compile from the source package. It did when I created it. > The current > stable version 7.2.3 does with minimal changes to the cygport file (the > source archive and directory is now "swipl" instead of "pl") and removal > of the Cygwin specific patches (which might have been upstreamed). Some > files are named differently and don't package into their sub-packages, > but the main package seems to depend on perl-JSON for whatever reason, > but I think that's a spurious match on "use JSON" (.pl is Prolog, not > Perl in this case). Yes, it's spurious. I removed the perl_vendor from setup.hint for now. I don't intend to repackage SWI-Prolog for a while. Hope that's ok, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9kJc1hzvLo.pgp Description: PGP signature
Re: setup.hint spelling/typo fixes
Jon Turney writes: > I fixed on cygwin.com various spelling errors or typos in setup.hint: […] > AG: perl-TimeDate: formating -> formatting That typo in the description is from upstream, it gets generated from the META information on CPAN. :-) http://api.metacpan.org/v0/release/TimeDate (see "abstract") Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
setup.hint spelling/typo fixes
I fixed on cygwin.com various spelling errors or typos in setup.hint: Please update your local copy JA: apngdis: invividual -> individual YS: artikulate : pronounciation -> pronunciation YS: autoconf2.1: creattes -> creates JY: binutils: assember -> assembler MA: catdoc: charachers -> characters MA: ccolamd: contrained -> constrained JA: code2html: ource -> source JA: dhttpd: webserser -> webserver YS: flite: syntesis -> synthesis JA: fossil: ther -> their YS: giflib: utilties -> utilities YS: gnu-free-fonts: compatability -> compatibility YS: gob2: intentionaly -> intentionally YS: gt: utilties -> utilities, supportes -> supports JA: gt5: appened -> happened, ercentage -> percentage, sing -> using YS: gvfs: availible -> available YS: ibus-m17n: Mulitlingual -> Multilingual CV: ipc-utils: maintainance -> maintenance JA: joe: immitation -> imitation, allowes -> allows YS: kde-dev-utils: utilties -> utilities YS: kf5-kdeclarative: intergrate -> integrate YS: libLASi: accomodates -> accommodates VZ: libmng: examing -> examining YS: libnice: Interactice -> Interactive YS: libproxy: consistant -> consistent YS: libwps0.3: procesors -> processors YS: libxfce4ui: amoung -> among YS: libxklavier: indended -> intended JA: links: nlike -> unlike JA: lzop: terrabyte -> terabyte JA: nttcp: transfered -> transferred MA: octave-cgi: Gatway -> Gateway MA: octave-mechanics: lassical -> Classical MA: octave-struct: aAdditional -> Additional MA: onig: Onigurama -> Oniguruma YS: pcmanfm: extremly -> extremely AG: perl-TimeDate: formating -> formatting YS: qimageblitz: interm -> interim YS: qwt5: scientifical -> scientific JA: sic: extremly -> extremely JA: signify: umber -> number, uotes -> quotes, ndependently -> independently YS: spice-gtk: utilitzed -> utilized JA: splitpatch: desireable -> desirable, smilar -> similar MA: tesseract-ocr-por: Brasilian Potuguese -> Brazilian Portuguese MA: tesseract-training-por: ditto JA: tnef: por' -> port, auhentication -> authentication YS: trayer: enviroments -> environments YS: unifont: utilties -> utilities DR: which: execuatbles -> executables YS: wv: utilties -> utilities MA: xdelta: lagacy -> legacy, prestine-tar -> pristine-tar
Re: setup.hint spelling/typo fixes
On Fri, 2015-10-23 at 14:48 +0100, Jon Turney wrote: > I fixed on cygwin.com various spelling errors or typos in setup.hint: > > Please update your local copy Done, thanks! -- Yaakov
Re: upload just setup.hint?
On 8/25/2015 7:37 AM, Andrew Schulman wrote: I have a package in test, that I want to promote to current. If I just upload the revised setup.hint and !ready, is that enough? Yes. Ken
upload just setup.hint?
I have a package in test, that I want to promote to current. If I just upload the revised setup.hint and !ready, is that enough? Or do I need to re-upload the package .tar.xz files too, and/or bump the version number?
Re: cygport: allow setting prev:, curr:, and test: in autogenerated setup.hint
On Jun 4 11:51, Andrew Schulman wrote: It seems you've re-invented something that David Rothenberger has implemented before in a slightly different way: http://thread.gmane.org/gmane.os.cygwin.applications/26034 It's also integrated in my patched-up version of cygport here: git://repo.or.cz/cygport/rpm-style.git FWIW, I've been using Dave's patch a few times and it seems slightly less verbose than what you've got. OK. Sure, VERSIONS=curr:1.7.3.0-2 test:2.0.0-b8-1 also works, and it has the advantage of not baking in the current 3-version prev/curr/test setup quite so much. OTOH setting PREV, CURR and TEST feels a little more natural to me with the current 3-version setup. Either way would be fine with me, as long as I have a way of automatically setting the versions in the cygport file, instead of having to manually edit setup.hint after the build. Good idea. I was wondering the same while pushing lots of Cygwin test releases lately. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1mooYXPjTl.pgp Description: PGP signature
Re: cygport: allow setting prev:, curr:, and test: in autogenerated setup.hint
Andrew Schulman writes: I have a package (socat) where I need to set the curr: and test: fields in setup.hint. I got tired of adding them to the autogenerated setup.hint files after every build, so I wrote a patch for cygport to support specifying them in the cygport file. For example, setting CURR=1.7.3.0-2 TEST=2.0.0-b8-1 in the cygport file will give curr: 1.7.3.0-2 test: 2.0.0-b8-1 in setup.hint. The PREV, PKG_PREV, CURR, PKG_CURR, TEST, and PKG_TEST variables are all supported. The variable name TEST might be too generic, but I'm not aware of any other uses for it, and grep -r '\TEST\' in the cygport source turns up none. If necessary it could be renamed to e.g. SETUP_TEST, but then probably CURR, PKG_CURR etc. would all have to be renamed too. At least if it ever gets exported, then TEST will be throwing a monkey wrench into a few build systems, I suspect. The patch is in the setup.hint branch of https://github.com/andrex-e-schulman/cygport.git. It seems you've re-invented something that David Rothenberger has implemented before in a slightly different way: http://thread.gmane.org/gmane.os.cygwin.applications/26034 It's also integrated in my patched-up version of cygport here: git://repo.or.cz/cygport/rpm-style.git FWIW, I've been using Dave's patch a few times and it seems slightly less verbose than what you've got. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: cygport: allow setting prev:, curr:, and test: in autogenerated setup.hint
It seems you've re-invented something that David Rothenberger has implemented before in a slightly different way: http://thread.gmane.org/gmane.os.cygwin.applications/26034 It's also integrated in my patched-up version of cygport here: git://repo.or.cz/cygport/rpm-style.git FWIW, I've been using Dave's patch a few times and it seems slightly less verbose than what you've got. OK. Sure, VERSIONS=curr:1.7.3.0-2 test:2.0.0-b8-1 also works, and it has the advantage of not baking in the current 3-version prev/curr/test setup quite so much. OTOH setting PREV, CURR and TEST feels a little more natural to me with the current 3-version setup. Either way would be fine with me, as long as I have a way of automatically setting the versions in the cygport file, instead of having to manually edit setup.hint after the build. Andrew
cygport: allow setting prev:, curr:, and test: in autogenerated setup.hint
I have a package (socat) where I need to set the curr: and test: fields in setup.hint. I got tired of adding them to the autogenerated setup.hint files after every build, so I wrote a patch for cygport to support specifying them in the cygport file. For example, setting CURR=1.7.3.0-2 TEST=2.0.0-b8-1 in the cygport file will give curr: 1.7.3.0-2 test: 2.0.0-b8-1 in setup.hint. The PREV, PKG_PREV, CURR, PKG_CURR, TEST, and PKG_TEST variables are all supported. The variable name TEST might be too generic, but I'm not aware of any other uses for it, and grep -r '\TEST\' in the cygport source turns up none. If necessary it could be renamed to e.g. SETUP_TEST, but then probably CURR, PKG_CURR etc. would all have to be renamed too. The patch is in the setup.hint branch of https://github.com/andrex-e-schulman/cygport.git. Andrew
Re: cygport 0.17.0: Incorrect 'requires' line in setup.hint
On 25/09/2014 22:05, David Stacey wrote: I am trying to package tinyxml2, to be used by cppcheck. I have split the package into a library package called 'libtinyxml2-2', and a devel package 'libtinyxml2-devel'. However, when I run cygport to generate the packages, the setup.hint file for the devel package claims that it is dependent on 'libtinyxml2' (note the missing '-2' at the end). the package should be called libtinyxml2_2, using that you will have: libtinyxml2_2 requires: libgcc1 libstdc++6 libtinyxml2-devel requires: libtinyxml2_2 I've obviously done something wrong in either my package naming or in the cygport file itself - please could you advise. I am running cygport-0.17.0 in x86 Cygwin. libtinyxml2-2-2.1.0.tar.bz2 makes difficult to split between package name and version libtinyxml2_2-2.1.0.tar.bz2 is more clear Many thanks in advance, Dave. Regards Marco
Re: cygport 0.17.0: Incorrect 'requires' line in setup.hint
On 26/09/2014 17:57, Marco Atzeri wrote: On 25/09/2014 22:05, David Stacey wrote: I am trying to package tinyxml2, to be used by cppcheck. I have split the package into a library package called 'libtinyxml2-2', and a devel package 'libtinyxml2-devel'. However, when I run cygport to generate the packages, the setup.hint file for the devel package claims that it is dependent on 'libtinyxml2' (note the missing '-2' at the end). the package should be called libtinyxml2_2 That fixed it - thank you for your help. Cheers, Dave.
Do I need to upload setup.hint?
Hi, In the web page that describes the new upload method there is no mention of setup.hint. Is it not required to upload setup.hint? How are requires, categories, and descriptions defined? -- Erwin Waterlander http://waterlan.home.xs4all.nl/
Re: Do I need to upload setup.hint?
Il 1/5/2014 9:27 PM, waterlan ha scritto: Hi, In the web page that describes the new upload method there is no mention of setup.hint. Is it not required to upload setup.hint? How are requires, categories, and descriptions defined? setup.hint's are need, of course as they are the base for building setup.ini Categories are defined on the guide http://cygwin.com/setup.html For descriptions you choose. Requires are an easy outcome if you use cygport for building and packaging. Regards Marco
Re: Do I need to upload setup.hint?
marco atzeri schreef op 2014-01-05 21:48: Il 1/5/2014 9:27 PM, waterlan ha scritto: Hi, In the web page that describes the new upload method there is no mention of setup.hint. Is it not required to upload setup.hint? How are requires, categories, and descriptions defined? setup.hint's are need, of course as they are the base for building setup.ini Categories are defined on the guide http://cygwin.com/setup.html For descriptions you choose. Requires are an easy outcome if you use cygport for building and packaging. In the grep example on https://sourceware.org/cygwin-apps/package-upload.html the setup.hint files are not there. -- Erwin Waterlander http://waterlan.home.xs4all.nl/
Re: Do I need to upload setup.hint?
Il 1/5/2014 9:52 PM, waterlan ha scritto: marco atzeri schreef op 2014-01-05 21:48: Il 1/5/2014 9:27 PM, waterlan ha scritto: Hi, In the web page that describes the new upload method there is no mention of setup.hint. Is it not required to upload setup.hint? How are requires, categories, and descriptions defined? setup.hint's are need, of course as they are the base for building setup.ini Categories are defined on the guide http://cygwin.com/setup.html For descriptions you choose. Requires are an easy outcome if you use cygport for building and packaging. In the grep example on https://sourceware.org/cygwin-apps/package-upload.html the setup.hint files are not there. not needed if equal to previous one. but if requires is changed you need to upload the new one.
pcre: setup.hint
The pcre directory has a setup.hint with just skip: as the only entry. This would indicate a source-only package, however pcre does have a package with documentation and binaries that can't be installed due to this. 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: pcre: setup.hint
On 2013-10-07 13:03, Achim Gratz wrote: The pcre directory has a setup.hint with just skip: as the only entry. This would indicate a source-only package, however pcre does have a package with documentation and binaries that can't be installed due to this. Fixed, thanks for noticing. Yaakov
Correct cyggcc_s-seh-1.dll dependency in setup.hint (64bit)?
Some of the *.exe files I compile under 64 report dependencies like this: ... C:\tmp\cygwin\root\bin\cygz.dll C:\tmp\cygwin\root\bin\cygstdc++-6.dll C:\tmp\cygwin\root\bin\cyggcc_s-seh-1.dll The first two are obvious, but what is the last one? What requires: should I put in setup.hint to satisfy it? Jari
Re: Correct cyggcc_s-seh-1.dll dependency in setup.hint (64bit)?
Jari Aalto writes: C:\tmp\cygwin\root\bin\cyggcc_s-seh-1.dll The first two are obvious, but what is the last one? What requires: should I put in setup.hint to satisfy it? Asking the orcale at: http://cygwin.com/cgi-bin2/package-grep.cgi?grep=cyggcc_s-seh-1.dllarch=x86_64 gives the answer libgcc1. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
64bit : missing setup.hint
I noticed on the 64 bit tree that the following files base-cygwin-3.2-1.tar.bz2 gzip-1.4-1.tar.bz2 winsup-20130314-svn-1.tar.bz2 are missing the relevant setup.hint Regards Marco
Re: 64bit : missing setup.hint
On Mar 22 11:30, marco atzeri wrote: I noticed on the 64 bit tree that the following files base-cygwin-3.2-1.tar.bz2 gzip-1.4-1.tar.bz2 winsup-20130314-svn-1.tar.bz2 are missing the relevant setup.hint Thanks for the hint. I added these files. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: RFU: apngtools setup.hint
On Oct 23 07:38, Jari Aalto wrote: Please upload this apngtools metapackage for users that want to get all in download. wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/apngtools/setup.hint \ I would love to, but it looks like there's something amiss here... ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: apngtools setup.hint
On 2012-10-23 09:44, Corinna Vinschen wrote: | I would love to, but it looks like there's something amiss here... ;) Extra backslash removed from URL and commas from setup.hint::required field: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/apngtools/setup.hint Jari
Re: RFU: apngtools setup.hint
On Oct 23 16:24, Jari Aalto wrote: On 2012-10-23 09:44, Corinna Vinschen wrote: | I would love to, but it looks like there's something amiss here... ;) Extra backslash removed from URL and commas from setup.hint::required field: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/apngtools/setup.hint I think we need empty apngtools bin and src packages as well. Just a setup.hint file seems a bit on the lean side. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: apngtools setup.hint
2012-10-23 16:43 Corinna Vinschen | I think we need empty apngtools bin and src packages as well. Just | a setup.hint file seems a bit on the lean side. Ok. Created an empty package for the effect of setup.hint only. wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/apngtools/apngtools-1.0-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/apngtools/apngtools-1.0-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/apngtools/setup.hint Jari
RFU: apngtools setup.hint
Please upload this apngtools metapackage for users that want to get all in download. wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/apngtools/setup.hint \ Jari [ setup.hint ] sdesc: Animated PNG image (APNG) tools ldesc: Collection of utilities: apng2gif (convert), apngasm (assemble APNG from individual PNG images), apngdis (dissamble APNG to individual PNG files), apngopt (optimize APNG by reducing size), gif2apng (convert anmatef GIF to APNG) category: Graphics requires: apng2gif, apngasm, apngdis, apngopt, gif2apng
ITP: apngtools setup.hint (Was: ITP waiting list)
2012-10-20 22:51 marco atzeri marco.atzeri-re5jqeeqqe8avxtiumw...@public.gmane.org: | On 10/20/2012 3:56 PM, Jari Aalto wrote: | | | If you have some free time, here is list of ITPs that would need checking: | | gif2apng http://cygwin.com/ml/cygwin-apps/2012-09/msg00082.html | apngopt http://cygwin.com/ml/cygwin-apps/2012-09/msg00083.html | apngdis http://cygwin.com/ml/cygwin-apps/2012-09/msg00084.html | apngasm http://cygwin.com/ml/cygwin-apps/2012-09/msg00085.html | | have we mentioned that will be better a single apng tools package ? The compilations can be handled through metapackages that depend on individual packages[*]. See Ubuntu etc. After RFU'ing these, we can upload: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/apngtools/setup.hint \ Jari [*] Each project has its own release schedule, project page, issue trackers etc. Metapackages are designed for making collections of utilities. [ setup.hint ] sdesc: Animated PNG image (APNG) tools ldesc: Collection of utilities: apng2gif (convert), apngasm (assemble APNG from individual PNG images), apngdis (dissamble APNG to individual PNG files), apngopt (optimize APNG by reducing size), gif2apng (convert anmatef GIF to APNG) category: Graphics requires: apng2gif, apngasm, apngdis, apngopt, gif2apng
Re: cygport: check setup.hint?
On 7/20/2012 5:20 PM, Ken Brown wrote: On 7/20/2012 3:27 PM, Yaakov (Cygwin/X) wrote: On 2012-07-20 11:19, Ken Brown wrote: 1. The setup.hint generated for emacs (but not emacs-X11) erroneously listed perl and python in the requires. I'm attaching my .cygport file and the associated patches in case you want to try to replicate this. /usr/bin/grep-changelog is a perl script, and there are python modules Ah, I missed that. In the past it wasn't picked up by __list_deps. in /usr/share/emacs/$PV/etc used by python.el. I'd say in this case that the perl dep is correct, but python is optional and could probably be ignored. I'm just not sure how to handle that. AFAICS REQUIRES shouldn't override autogeneration; there are plenty of cases where it will be correct but incomplete and we just need to add. Of course, you could just continue using a pkg_name.hint for just that subpackage, but that defeats the purpose. I'm open to ideas here. How about something like [PKG_]REQUIRE_EXCLUDES for packages that we don't want to require? Yaakov, Any further thoughts about this? Ken
Re: cygport: check setup.hint?
Ken Brown writes: How about something like [PKG_]REQUIRE_EXCLUDES for packages that we don't want to require? Any further thoughts about this? +1 Since I have made a snapshot package, cygport picks up that package as a dependency. I've patched pkg.cygpart to filter these out (grep -Ev '^(…|…)-' before the first sed invocation), but a more general solution to this problem would be most welcome. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: cygport: check setup.hint?
On 2012-07-19 00:22, Yaakov (Cygwin/X) wrote: On 2012-07-18 06:53, Ken Brown wrote: When I build a package using cygport, I sometimes forget to run cygport's dep command to make sure my setup.hint is up to date. I think it would be useful for cygport to do this as part of its packaging step. It could print out a list of dependencies or, better, print a warning if there are dependencies that are not listed in any of the setup.hint files. I'm actually working on setup.hint generation in cygport, which would work by defining [PKG_]CATEGORY, [PKG_]REQUIRES, [PKG_]SUMMARY, and [PKG_]DESCRIPTION variables in the .cygport file itself, rather than having to maintain a set of files for each package. The next natural, albeit more difficult, step would be for cygport to automatically generate the requires for each (sub)package based on the algorithm used in cygport deps, similar to what rpmbuild does for binary packages. Of course, non-binary deps (e.g. commands called in scripts, or by fork(), etc.) would still have to be explicitly defined. The first version is now in cygport git master. See the Packaging section of the manual for the variables you need to set in order for this to work, and be sure to remove your .hint files from $C. Yaakov
Re: cygport: check setup.hint?
On 7/20/2012 8:35 AM, Yaakov (Cygwin/X) wrote:
On 2012-07-19 00:22, Yaakov (Cygwin/X) wrote:
On 2012-07-18 06:53, Ken Brown wrote:
When I build a package using cygport, I sometimes forget to run
cygport's dep command to make sure my setup.hint is up to date. I
think it would be useful for cygport to do this as part of its packaging
step. It could print out a list of dependencies or, better, print a
warning if there are dependencies that are not listed in any of the
setup.hint files.
I'm actually working on setup.hint generation in cygport, which would
work by defining [PKG_]CATEGORY, [PKG_]REQUIRES, [PKG_]SUMMARY, and
[PKG_]DESCRIPTION variables in the .cygport file itself, rather than
having to maintain a set of files for each package. The next natural,
albeit more difficult, step would be for cygport to automatically
generate the requires for each (sub)package based on the algorithm used
in cygport deps, similar to what rpmbuild does for binary packages. Of
course, non-binary deps (e.g. commands called in scripts, or by fork(),
etc.) would still have to be explicitly defined.
The first version is now in cygport git master. See the Packaging
section of the manual for the variables you need to set in order for
this to work, and be sure to remove your .hint files from $C.
Wow, that was fast. Thanks!
I tested it on cygport itself, emacs, and texlive. I only found two
small glitches:
1. The setup.hint generated for emacs (but not emacs-X11) erroneously
listed perl and python in the requires. I'm attaching my .cygport
file and the associated patches in case you want to try to replicate this.
2. If a package is listed in REQUIRES but then cygport also finds it as
a dependency, it gets listed twice in the generated setup.hint file.
Ken
--- origsrc/emacs-24.0.94/lisp/net/browse-url.el2012-02-13
11:13:25.0 -0500
+++ src/emacs-24.0.94/lisp/net/browse-url.el2012-04-01 14:53:40.592684900
-0400
@@ -467,7 +467,7 @@ commands reverses the effect of this var
;; it in anonymous cases. If it's not anonymous the next regexp
;; applies.
(^/\\([^:@]+@\\)?\\([^:]+\\):/* . ftp://\\1\\2/;)
-,@(if (memq system-type '(windows-nt ms-dos cygwin))
+,@(if (memq system-type '(windows-nt ms-dos))
'((^\\([a-zA-Z]:\\)[\\/] . file:///\\1/)
(^[\\/][\\/]+ . file://)))
(^/+ . file:///))
@@ -724,12 +724,6 @@ interactively. Turn the filename into a
(defun browse-url-file-url (file)
Return the URL corresponding to FILE.
Use variable `browse-url-filename-alist' to map filenames to URLs.
- ;; De-munge Cygwin filenames before passing them to Windows browser.
- (if (eq system-type 'cygwin)
- (let ((winfile (with-output-to-string
- (call-process cygpath nil standard-output
-nil -m file
- (setq file (substring winfile 0 -1
(let ((coding (and (default-value 'enable-multibyte-characters)
(or file-name-coding-system
default-file-name-coding-system
=== modified file 'src/s/cygwin.h'
--- src/s/cygwin.h 2011-11-10 08:14:27 +
+++ src/s/cygwin.h 2012-01-02 18:20:53 +
@@ -58,7 +58,8 @@
if (-1 == openpty (fd, dummy, pty_name, 0, 0)) \
fd = -1;\
sigsetmask (mask); \
- emacs_close (dummy); \
+ if (fd = 0) \
+ emacs_close (dummy);\
} \
while (0)
@@ -81,10 +82,6 @@
#define HAVE_SOCKETS
-/* vfork() interacts badly with setsid(), causing ptys to fail to
- change their controlling terminal */
-#define vfork fork
-
/* This should work (at least when compiling with gcc). But I have no way
or intention to verify or even test it. If you encounter a problem with
it, feel free to change this setting, but please add a comment here about
HOMEPAGE=http://www.gnu.org/software/emacs/;
SRC_URI=mirror://gnu/emacs/${P}.tar.gz
DEPEND=libtiff-devel
libgif-devel
libjpeg-devel
pkgconfig(dbus-1)
pkgconfig(fontconfig)
pkgconfig(freetype2)
pkgconfig(gio-2.0)
pkgconfig(glib-2.0)
pkgconfig(gnutls)
pkgconfig(gtk+-2.0)
pkgconfig(librsvg-2.0)
pkgconfig(libxml-2.0)
pkgconfig(libpng14)
pkgconfig(ncursesw)
pkgconfig(sm)
pkgconfig(Wand)
pkgconfig(x11)
pkgconfig(xft)
pkgconfig(xpm)
pkgconfig(xrender)
PATCH_URI=
adapt_to_new_cygstart.patch
cygwin.h.patch
xgselect-24.0.97.patch
PKG_NAMES=${PN} ${PN}-el ${PN}-X11
PKG_HINTS=${PN} ${PN}-el ${PN}-X11
CPPFLAGS=-I/usr/include/ncursesw
LDFLAGS=-L/usr/lib/ncursesw
CATEGORY=Editors Interpreters
emacs_SUMMARY=The extensible, customizable, self
Re: cygport: check setup.hint?
On 2012-07-20 11:19, Ken Brown wrote: On 7/20/2012 8:35 AM, Yaakov (Cygwin/X) wrote: The first version is now in cygport git master. See the Packaging section of the manual for the variables you need to set in order for this to work, and be sure to remove your .hint files from $C. Wow, that was fast. Thanks! I was already working on the setup.hint generation earlier this week; I just had to add in the dependency generation, the framework for which was there already in __list_deps (although I added to it). That being said, it came together even faster than I had anticipated. I tested it on cygport itself, emacs, and texlive. I only found two small glitches: 1. The setup.hint generated for emacs (but not emacs-X11) erroneously listed perl and python in the requires. I'm attaching my .cygport file and the associated patches in case you want to try to replicate this. /usr/bin/grep-changelog is a perl script, and there are python modules in /usr/share/emacs/$PV/etc used by python.el. I'd say in this case that the perl dep is correct, but python is optional and could probably be ignored. I'm just not sure how to handle that. AFAICS REQUIRES shouldn't override autogeneration; there are plenty of cases where it will be correct but incomplete and we just need to add. Of course, you could just continue using a pkg_name.hint for just that subpackage, but that defeats the purpose. I'm open to ideas here. 2. If a package is listed in REQUIRES but then cygport also finds it as a dependency, it gets listed twice in the generated setup.hint file. True; that's why the requires: are shown for autogenerated setup.hints, so you can detect and fix problems. I'd say just don't do that. The good news is that since we don't retest each tarball for its contents during the missing/conflicting files check anymore, rerunning 'package' isn't as expensive as it was previously. Yaakov
Re: cygport: check setup.hint?
On 7/20/2012 3:27 PM, Yaakov (Cygwin/X) wrote: On 2012-07-20 11:19, Ken Brown wrote: On 7/20/2012 8:35 AM, Yaakov (Cygwin/X) wrote: The first version is now in cygport git master. See the Packaging section of the manual for the variables you need to set in order for this to work, and be sure to remove your .hint files from $C. Wow, that was fast. Thanks! I was already working on the setup.hint generation earlier this week; I just had to add in the dependency generation, the framework for which was there already in __list_deps (although I added to it). That being said, it came together even faster than I had anticipated. I tested it on cygport itself, emacs, and texlive. I only found two small glitches: 1. The setup.hint generated for emacs (but not emacs-X11) erroneously listed perl and python in the requires. I'm attaching my .cygport file and the associated patches in case you want to try to replicate this. /usr/bin/grep-changelog is a perl script, and there are python modules Ah, I missed that. In the past it wasn't picked up by __list_deps. in /usr/share/emacs/$PV/etc used by python.el. I'd say in this case that the perl dep is correct, but python is optional and could probably be ignored. I'm just not sure how to handle that. AFAICS REQUIRES shouldn't override autogeneration; there are plenty of cases where it will be correct but incomplete and we just need to add. Of course, you could just continue using a pkg_name.hint for just that subpackage, but that defeats the purpose. I'm open to ideas here. How about something like [PKG_]REQUIRE_EXCLUDES for packages that we don't want to require? 2. If a package is listed in REQUIRES but then cygport also finds it as a dependency, it gets listed twice in the generated setup.hint file. True; that's why the requires: are shown for autogenerated setup.hints, so you can detect and fix problems. I'd say just don't do that. The good news is that since we don't retest each tarball for its contents during the missing/conflicting files check anymore, rerunning 'package' isn't as expensive as it was previously. Fair enough. Ken
cygport: check setup.hint?
When I build a package using cygport, I sometimes forget to run cygport's dep command to make sure my setup.hint is up to date. I think it would be useful for cygport to do this as part of its packaging step. It could print out a list of dependencies or, better, print a warning if there are dependencies that are not listed in any of the setup.hint files. Ken
Re: cygport: check setup.hint?
On 2012-07-18 06:53, Ken Brown wrote: When I build a package using cygport, I sometimes forget to run cygport's dep command to make sure my setup.hint is up to date. I think it would be useful for cygport to do this as part of its packaging step. It could print out a list of dependencies or, better, print a warning if there are dependencies that are not listed in any of the setup.hint files. I'm actually working on setup.hint generation in cygport, which would work by defining [PKG_]CATEGORY, [PKG_]REQUIRES, [PKG_]SUMMARY, and [PKG_]DESCRIPTION variables in the .cygport file itself, rather than having to maintain a set of files for each package. The next natural, albeit more difficult, step would be for cygport to automatically generate the requires for each (sub)package based on the algorithm used in cygport deps, similar to what rpmbuild does for binary packages. Of course, non-binary deps (e.g. commands called in scripts, or by fork(), etc.) would still have to be explicitly defined. Consider it on my todo list, but no guarantees as to when I'll get to it. Yaakov
octave setup.hint error
upset: Error. Parsing failed. - release/octave/setup.hint(9): can't use [] here I've changed octave's setup.hints to add prev:, curr:, test: lines, removing the incorrect setup.ini format.
Re: octave setup.hint error
On 9/21/2011 4:02 PM, Christopher Faylor wrote: upset: Error. Parsing failed. - release/octave/setup.hint(9): can't use [] here I've changed octave's setup.hints to add prev:, curr:, test: lines, removing the incorrect setup.ini format. I wrongly copied the setup.ini structure instead of http://cygwin.com/setup.html Sorry Marco
[RFU] New setup.hint files for emacs, emacs-X11, and emacs-el
I'd like to promote the test releases (23.3-2) to current. I think the following setup.hint files should do the job. wget -x -nH --cut-dirs=2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-X11/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-el/setup.hint Please delete the 23.2-3 packages, leaving 23.3-1 as previous. Thanks. Ken
Re: [RFU] New setup.hint files for emacs, emacs-X11, and emacs-el
On Tue, Apr 19, 2011 at 04:56:05PM -0400, Ken Brown wrote: I'd like to promote the test releases (23.3-2) to current. I think the following setup.hint files should do the job. wget -x -nH --cut-dirs=2 \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-X11/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-el/setup.hint Please delete the 23.2-3 packages, leaving 23.3-1 as previous. Thanks. Uploaded and deleted. Thanks for your continued diligent support of emacs. It's much appreciated. (I'm not an emacs user but I know it has to be a challenge to keep it up to date and to respond to user issues) cgf
Re: Ooops, minor setup.hint glitch - and announce list bouncing my posts
On 22/03/2011 21:45, Christopher Faylor wrote: On Tue, Mar 22, 2011 at 09:16:58PM +, Dave Korn wrote: Also, I can't post the release announcement, because the spam filter complains that I have things that look like raw email addresses in the body. Mailing the global allow address didn't help - can anyone get it through manually? Looking at the blocked message, I don't see any mystery. Just remove the cygwin at cygwin dot com email address. Ah, there we go. I also had to obfuscate my own email address in the pgp key. I see it has an exception for the template unsubscribe-you=yourdomain address though! cheers, DaveK
Ooops, minor setup.hint glitch - and announce list bouncing my posts
Hi folks, I just uploaded gcc4-4.3.4-4, and realised the setup.hint requires: lines don't reflect the extra dependencies that 4.5.0-1 requires. There will be a brief window while I fix this when anyone installing 4.5.0 might not get all the libs like MPC GMP etc. that they need. Also, I can't post the release announcement, because the spam filter complains that I have things that look like raw email addresses in the body. Mailing the global allow address didn't help - can anyone get it through manually? cheers, DaveK
Re: Ooops, minor setup.hint glitch - and announce list bouncing my posts
On 22/03/2011 21:16, Dave Korn wrote: I just uploaded gcc4-4.3.4-4, and realised the setup.hint requires: lines don't reflect the extra dependencies that 4.5.0-1 requires. There will be a brief window while I fix this when anyone installing 4.5.0 might not get all the libs like MPC GMP etc. that they need. Guess I forgot to actually ask: Do we prefer the situation where all users of curr: packages get a few extra libs that they don't need, or would we prefer not to make them download extra libs and rely on users of test: packages to manually download anything they find themselves missing? On the whole I guess loading a few extra libs on normal users is probably not a serious burden but wondered if others had thought about it. cheers, DaveK
Re: Ooops, minor setup.hint glitch - and announce list bouncing my posts
On 3/22/2011 5:19 PM, Dave Korn wrote: Guess I forgot to actually ask: Do we prefer the situation where all users of curr: packages get a few extra libs that they don't need, or would we prefer not to make them download extra libs and rely on users of test: packages to manually download anything they find themselves missing? On the whole I guess loading a few extra libs on normal users is probably not a serious burden but wondered if others had thought about it. I usually go ahead and add the new libs to the global requires. This is similar to the situation when a dependent library gets version bumped; I'll typically include BOTH the libs in my app's requires spec: requires: libncurses7 libncurses8 -- Chuck
Re: Ooops, minor setup.hint glitch - and announce list bouncing my posts
On 22/03/2011 21:44, Charles Wilson wrote: On 3/22/2011 5:19 PM, Dave Korn wrote: Guess I forgot to actually ask: Do we prefer the situation where all users of curr: packages get a few extra libs that they don't need, or would we prefer not to make them download extra libs and rely on users of test: packages to manually download anything they find themselves missing? On the whole I guess loading a few extra libs on normal users is probably not a serious burden but wondered if others had thought about it. I usually go ahead and add the new libs to the global requires. This is similar to the situation when a dependent library gets version bumped; I'll typically include BOTH the libs in my app's requires spec: requires: libncurses7 libncurses8 Yeah, and come to think of it, since it's generally expected that test: packages will one day become stable, everyone's going to need those libs sooner or later anyway. So I restored the requires: lines. (There appeared to be something of a spam bomb going on at sourceware when I was logged in, so I imagine that's why the filters have been turned up to full-sensitivity on the -announce list.) cheers, DaveK
Re: Ooops, minor setup.hint glitch - and announce list bouncing my posts
On Tue, Mar 22, 2011 at 09:16:58PM +, Dave Korn wrote: Also, I can't post the release announcement, because the spam filter complains that I have things that look like raw email addresses in the body. Mailing the global allow address didn't help - can anyone get it through manually? Looking at the blocked message, I don't see any mystery. Just remove the cygwin at cygwin dot com email address.
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Jun 24 18:23, Charles Wilson wrote: On 6/24/2010 5:02 PM, Yaakov (Cygwin/X) wrote: Do you know yet what the actual DLL names are going to be? libkio dlopen()s these instead of linking against them, so I want to fix these for my next KDE release. [...] (obviously those last two would be cygssl-1.0.0.dll and cygcrypto-1.0.0.dll) Correct. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Jun 24 23:21, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: On Jun 24 20:13, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Then please hold your horses. Do it wrong and the upgrade breaks OpenSSL on lots of installations. And: if the upgrade isn't done properly, bug reports about this will often be misfiled with the application programmers as regressions. http://www.fetchmail.info/fetchmail-FAQ.html#R14 and http://www.fetchmail.info/ bear testimonies of such misfilings :) Here's the short scoop: - OpenSSL 1.0.0 uses a different hash for /usr/ssl/certs than 0.9.8 did, so after the default ssl version is upgraded to 1.0.0, c_rehash needs to be run on that directory. Openssl does not come with any certificate and there's no certificate package in Cygwin either. AFAICS it would be sufficient to move to another ssl directory like, say, /usr/share/ssl instead of /usr/ssl. The user can copy and rehash any certificates manually, or install root certificates from scratch for 1.0.0. I see you are taking this upgrade far too lightly. [...] Not shipping certs by default is no excuse for stomping over and breaking user setups. Moving the directory won't break anything. The old dir isn't removed or something. If you change the ssldir to /usr/share, the postinstall script should move the contents from /usr/ssl to /usr/share/ssl. At least users should be told there is manual intervention (move certs, rehash) required BEFORE they can proceed to installation. If we move the dir, I will certainly mention this in the announcement. This was my last unsolicited warning on this matter. You have been warned. Would you like to take over openssl maintainership? Apparently I'm not qualified for this. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
HEADSUP maintainers: Change in openssl package requires change in setup.hint
Hi guys, according to the discussion starting here http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html the layout of the openssl package has changed so that the runtime libraries are now in the libopenssl098 package, rather than in the openssl base package. The openssl package will be switched from 0.98 to 1.0.0 really soon now, and that switch will also introduce the new runtime package libopenssl100. This package is slightly backward incompatible with 0.9.8. So, what we have to do is to convert *ALL* existing package dependencies from openssl to libopenssl098. I'm going to do this in the setup.hint files on cygwin.com, but, please do this in your local copy of your setup.hint files as well. As soon as I upgraded to openssl-1.0.0a-1, make sure that you keep your package dependencies in shape when building a new package. That means to change from libopenssl098 to libopenssl100. Here's the list of affected packages including their maintainers. Unfortunately the list also contains four orphaned packages. However, isn't libcurl3 OBSOLETE, rather than ORPHANED? apache2 ORPHANED (Max Bowsher) aria2 Kostya Altukhov bind/libdns-devel Yaakov S bind/libdns50 Yaakov S ctorrent Yaakov S curl/libcurl-develYaakov S curl/libcurl3 ORPHANED (Brian Dessent) curl/libcurl4 Yaakov S cyrus-sasl/libsasl2 ORPHANED (Gareth Pearce) cyrus-sasl/libsasl2-devel ORPHANED (Gareth Pearce) email Ross Smith II exim Pierre A. Humblet fetchmail Jason Tishler git Eric Blake gnome-vfs2/libgnomevfs2-devel Yaakov S gnome-vfs2/libgnomevfs2_0 Yaakov S gqDr. Volker Zell httping Jari Aalto irssi Kostya Altukhov lftp Andrew Schulman libarchive/libarchive-devel Charles Wilson libarchive/libarchive2Charles Wilson libQtNetwork4 Yaakov S libQtNetwork4-devel Yaakov S libssh2/libssh2-devel Yaakov S libssh2/libssh2_1 Yaakov S links Jari Aalto lynx Corinna Vinschen msmtp Jari Aalto mutt Christopher Faylor neon/libneon-develDr. Volker Zell neon/libneon25Dr. Volker Zell neon/libneon26Dr. Volker Zell neon/libneon27Dr. Volker Zell openldap/libopenldap2 Dr. Volker Zell openldap/libopenldap2_2_7 Dr. Volker Zell openldap/libopenldap2_3_0 Dr. Volker Zell openldap/openldap-devel Dr. Volker Zell openssh Corinna Vinschen parrotReini Urban parrot/parrot-devel Reini Urban postgresqlReini Urban postgresql/libecpg-devel Reini Urban postgresql/libpq-develReini Urban postgresql/libpq3 Reini Urban postgresql/libpq4 Reini Urban postgresql/libpq5 Reini Urban postgresql/postgresql-client Reini Urban postgresql/postgresql-devel Reini Urban pure-ftpd Kostya Altukhov pythonJason Tishler ruby Corinna Vinschen serf/libserf0-devel David Rothenberger serf/libserf0_0 David Rothenberger socat Andrew Schulman squid Dr. Volker Zell ssmtp Charles Wilson stunnel Andrew Schulman suck Jari Aalto suite3270/c3270 Peter A. Castro suite3270/pr3287 Peter A. Castro suite3270/s3270 Peter A. Castro suite3270/tcl3270 Peter A. Castro suite3270/x3270 Peter A. Castro SWI-PrologCorinna Vinschen syslog-ng Corinna Vinschen uw-imap/c-client Dr. Volker Zell uw-imap/uw-imap-imapd Dr. Volker Zell uw-imap/uw-imap-util Dr. Volker Zell w3m Bob Heckel wget Eric Blake xorg-server Yaakov
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
So, what we have to do is to convert *ALL* existing package dependencies from openssl to libopenssl098. I'm going to do this in the setup.hint files on cygwin.com, but, please do this in your local copy of your setup.hint files as well. Done.
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
Corinna Vinschen wrote on 2010-06-24: Hi guys, according to the discussion starting here http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html the layout of the openssl package has changed so that the runtime libraries are now in the libopenssl098 package, rather than in the openssl base package. The openssl package will be switched from 0.98 to 1.0.0 really soon now, and that switch will also introduce the new runtime package libopenssl100. This package is slightly backward incompatible with 0.9.8. What are the plans to deal with the hash vs. oldhash for the CApath directories? All the directories hosting single-cert-per-file stuff will have to be rehashed. Are the openssl maintainers aware there have been c_rehash fixes post-1.0.0 release? I've filed one, and one other to generate dual symlinks with a special c_rehash option which TTBOMK has not been accepted upstream yet, but can also help with sharing such directories between -0.9.8 and 1.0.0+ installations, should that be necessary -- and I guess that would be the case from the existence of separate packages for 0.9.8X and 1.0.0X. URLs: (use guest/guest as login/password for the site below): fixes: http://rt.openssl.org/Ticket/Display.html?id=2234 compat feature: http://rt.openssl.org/Ticket/Display.html?id=2272 HTH -- Matthias Andree
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Jun 24 15:55, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: Hi guys, according to the discussion starting here http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html the layout of the openssl package has changed so that the runtime libraries are now in the libopenssl098 package, rather than in the openssl base package. The openssl package will be switched from 0.98 to 1.0.0 really soon now, and that switch will also introduce the new runtime package libopenssl100. This package is slightly backward incompatible with 0.9.8. What are the plans to deal with the hash vs. oldhash for the CApath directories? All the directories hosting single-cert-per-file stuff will have to be rehashed. There are no plans. Are the openssl maintainers aware there have been c_rehash fixes post-1.0.0 release? I've filed one, and one other to generate dual symlinks with a special c_rehash option which TTBOMK has not been accepted upstream yet, but can also help with sharing such directories between -0.9.8 and 1.0.0+ installations, should that be necessary -- and I guess that would be the case from the existence of separate packages for 0.9.8X and 1.0.0X. I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
Corinna Vinschen wrote on 2010-06-24: On Jun 24 15:55, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: Hi guys, according to the discussion starting here http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html the layout of the openssl package has changed so that the runtime libraries are now in the libopenssl098 package, rather than in the openssl base package. The openssl package will be switched from 0.98 to 1.0.0 really soon now, and that switch will also introduce the new runtime package libopenssl100. This package is slightly backward incompatible with 0.9.8. What are the plans to deal with the hash vs. oldhash for the CApath directories? All the directories hosting single-cert-per-file stuff will have to be rehashed. There are no plans. Are the openssl maintainers aware there have been c_rehash fixes post-1.0.0 release? I've filed one, and one other to generate dual symlinks with a special c_rehash option which TTBOMK has not been accepted upstream yet, but can also help with sharing such directories between -0.9.8 and 1.0.0+ installations, should that be necessary -- and I guess that would be the case from the existence of separate packages for 0.9.8X and 1.0.0X. I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Then please hold your horses. Do it wrong and the upgrade breaks OpenSSL on lots of installations. And: if the upgrade isn't done properly, bug reports about this will often be misfiled with the application programmers as regressions. http://www.fetchmail.info/fetchmail-FAQ.html#R14 and http://www.fetchmail.info/ bear testimonies of such misfilings :) Here's the short scoop: - OpenSSL 1.0.0 uses a different hash for /usr/ssl/certs than 0.9.8 did, so after the default ssl version is upgraded to 1.0.0, c_rehash needs to be run on that directory. RECOMMENDATION: - if the *default* version moves from 0.9.8o to 1.0.0a, c_rehash should be run on /usr/ssl/certs, so that existing certificate configurations just continue to work. HOWEVER: - while the 0.9.8 library has to be c_rehash (without the second patch I posted from ticket 2278, and unless you run the patched version with the extra compatibility argument) removes all old symlinks from /usr/ssl/certs, so if you run 1.0.0's c_rehash, the 0.9.8 library no longer finds certificates. I can fancy the following solutions: A - coordinate efforts so that *all* ssl-dependent packages have been recompiled against to 1.0.0a, and then upgrade openssl and all users in one giant leap, all at the same time. alternatively, if you must keep 0.9.8, B - patch c_rehash as I'd proposed to OpenSSL with the patch so as to get two symlinks for each certificate for a transition period (i. e. until 0.9.8 is gone) - also put prominent notices that users that rely on applications that use 0.9.8 need to run c_rehash with the compatibility option Or: B2 - use my patch against (the 2278 ticket, see previous email) but further modify it to always run compatibility mode, until 0.9.8 is gone Independent of all that, consider a holistic approach to consolidate and manage all certificates for all TLS packages (gnutls, and nss if shipped - dunno) into these flat-file storages. GnuTLS always uses flat files, and perhaps should share the default /usr/ssl/cert.pem location (unless it already does, I didn't check). Samples could be taken from Debian/Ubuntu with the /usr/sbin/update-ca-certificates script found in their ca-certificates package. Regardless of the path chosen, please make sure there are PROMINENT NOTICES that users need to rehash their private certs directories after the upgrade. I'd even propose to patch setup.exe so it can pop up such package-specific notices, or print them at the end of the installation if in non-interactive modes, and bump the setup.ini version to encourage setup.exe upgrades. Hoping for a smooth 1.0.0 transition (after having seen some fail...) -- Matthias Andree
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Jun 24 20:13, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Then please hold your horses. Do it wrong and the upgrade breaks OpenSSL on lots of installations. And: if the upgrade isn't done properly, bug reports about this will often be misfiled with the application programmers as regressions. http://www.fetchmail.info/fetchmail-FAQ.html#R14 and http://www.fetchmail.info/ bear testimonies of such misfilings :) Here's the short scoop: - OpenSSL 1.0.0 uses a different hash for /usr/ssl/certs than 0.9.8 did, so after the default ssl version is upgraded to 1.0.0, c_rehash needs to be run on that directory. Openssl does not come with any certificate and there's no certificate package in Cygwin either. AFAICS it would be sufficient to move to another ssl directory like, say, /usr/share/ssl instead of /usr/ssl. The user can copy and rehash any certificates manually, or install root certificates from scratch for 1.0.0. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Thu, 2010-06-24 at 21:41 +0200, Corinna Vinschen wrote:
Openssl does not come with any certificate and there's no certificate
package in Cygwin either. AFAICS it would be sufficient to move to
another ssl directory like, say, /usr/share/ssl instead of /usr/ssl.
The user can copy and rehash any certificates manually, or install
root certificates from scratch for 1.0.0.
1.0.0 would be a good opportunity to FHS-ize the openssl package.
Move /usr/ssl to /usr/share/{open}ssl, but careful with /usr/ssl/man;
moving that to /usr/share/man would clobber some man1pages. Also,
could /usr/lib/engines be moved to /usr/lib/openssl/engines? The
current path is quite ambiguous as to its purpose.
Yaakov
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Jun 24 14:55, Yaakov S wrote:
On Thu, 2010-06-24 at 21:41 +0200, Corinna Vinschen wrote:
Openssl does not come with any certificate and there's no certificate
package in Cygwin either. AFAICS it would be sufficient to move to
another ssl directory like, say, /usr/share/ssl instead of /usr/ssl.
The user can copy and rehash any certificates manually, or install
root certificates from scratch for 1.0.0.
1.0.0 would be a good opportunity to FHS-ize the openssl package.
Move /usr/ssl to /usr/share/{open}ssl, but careful with /usr/ssl/man;
moving that to /usr/share/man would clobber some man1pages.
Openssl's configuration only allows two location options, --prefix,
which is set to /usr, and --openssldir, which is set to /usr/ssl
by default. So, if we change --openssldir to /usr/share/ssl, all
files will move there, including the man pages.
Also,
could /usr/lib/engines be moved to /usr/lib/openssl/engines? The
current path is quite ambiguous as to its purpose.
I didn't look into the patches applied by Linux distros, but the
upstream, vanilla openssl package does not allow to move directories
other than with --prefix and --openssldir. The engines path is, like
others, hardcoded into the Makefile, like this:
install_sw:
@$(PERL) $(TOP)/util/mkdir-p.pl $(INSTALL_PREFIX)$(INSTALLTOP)/bin \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib/pkgconfig \
$(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl \
$(INSTALL_PREFIX)$(OPENSSLDIR)/misc \
$(INSTALL_PREFIX)$(OPENSSLDIR)/certs \
$(INSTALL_PREFIX)$(OPENSSLDIR)/private
[...]
Being able to build from the vanilla sources is a pretty high priority
for me.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Thu, 2010-06-24 at 22:25 +0200, Corinna Vinschen wrote: Openssl's configuration only allows two location options, --prefix, which is set to /usr, and --openssldir, which is set to /usr/ssl by default. So, if we change --openssldir to /usr/share/ssl, all files will move there, including the man pages. Which is probably better, as long as you change the profile.d scripts accordingly to fix MANPATH. I didn't look into the patches applied by Linux distros, but the upstream, vanilla openssl package does not allow to move directories other than with --prefix and --openssldir. The engines path is, like others, hardcoded into the Makefile, like this: Yuck. I suppose you better leave it then, as ambiguous as it is. Yaakov
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Thu, 2010-06-24 at 11:36 +0200, Corinna Vinschen wrote: So, what we have to do is to convert *ALL* existing package dependencies from openssl to libopenssl098. I'm going to do this in the setup.hint files on cygwin.com, but, please do this in your local copy of your setup.hint files as well. As soon as I upgraded to openssl-1.0.0a-1, make sure that you keep your package dependencies in shape when building a new package. That means to change from libopenssl098 to libopenssl100. Do you know yet what the actual DLL names are going to be? libkio dlopen()s these instead of linking against them, so I want to fix these for my next KDE release. However, isn't libcurl3 OBSOLETE, rather than ORPHANED? You are correct; I fixed this in CVS. apache2 ORPHANED (Max Bowsher) This desperately needs to be ITA'd. I have a version in Ports if anyone who actually uses this wants to pick it up: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ cyrus-sasl/libsasl2 ORPHANED (Gareth Pearce) cyrus-sasl/libsasl2-devel ORPHANED (Gareth Pearce) As previously discussed, these actually use libopenssl097. Yaakov
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
Corinna Vinschen wrote on 2010-06-24: On Jun 24 20:13, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Then please hold your horses. Do it wrong and the upgrade breaks OpenSSL on lots of installations. And: if the upgrade isn't done properly, bug reports about this will often be misfiled with the application programmers as regressions. http://www.fetchmail.info/fetchmail-FAQ.html#R14 and http://www.fetchmail.info/ bear testimonies of such misfilings :) Here's the short scoop: - OpenSSL 1.0.0 uses a different hash for /usr/ssl/certs than 0.9.8 did, so after the default ssl version is upgraded to 1.0.0, c_rehash needs to be run on that directory. Openssl does not come with any certificate and there's no certificate package in Cygwin either. AFAICS it would be sufficient to move to another ssl directory like, say, /usr/share/ssl instead of /usr/ssl. The user can copy and rehash any certificates manually, or install root certificates from scratch for 1.0.0. I see you are taking this upgrade far too lightly. You are *massively* underestimating the dangers and importance of this particular upgrade to 1.0.0 is. It's very different from the 0.9.6-0.9.7-0.9.8 path which was barely noticable to users. SSL in Cygwin has so far just worked, users could install certs in the usual places and things would just work. The 1.0.0 upgrade the way you are (not) planning it is going to break users' setups in spectacular ways, and create considerable astonishment and frustration. Not shipping certs by default is no excuse for stomping over and breaking user setups. If you change the ssldir to /usr/share, the postinstall script should move the contents from /usr/ssl to /usr/share/ssl. At least users should be told there is manual intervention (move certs, rehash) required BEFORE they can proceed to installation. For the rehashing issues, see my previous mail. This really should be done from postinstall, too, if the majority of packages moves to 1.0.0 at the same time. For c_rehash, do consider my two patches, it will help. This was my last unsolicited warning on this matter. You have been warned. -- Matthias Andree
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On 6/24/2010 5:02 PM, Yaakov (Cygwin/X) wrote: Do you know yet what the actual DLL names are going to be? libkio dlopen()s these instead of linking against them, so I want to fix these for my next KDE release. When I built it for (a cygwin fork that shall not be named), they were: lib/openssl/engines-1.0.0/libubsec.so lib/openssl/engines-1.0.0/libsureware.so lib/openssl/engines-1.0.0/libpadlock.so lib/openssl/engines-1.0.0/libnuron.so lib/openssl/engines-1.0.0/libgost.so lib/openssl/engines-1.0.0/libgmp.so lib/openssl/engines-1.0.0/libcswift.so lib/openssl/engines-1.0.0/libchil.so lib/openssl/engines-1.0.0/libcapi.so lib/openssl/engines-1.0.0/libatalla.so lib/openssl/engines-1.0.0/libaep.so lib/openssl/engines-1.0.0/lib4758cca.so lib/openssl/engines-1.0.0/ bin/msys-ssl-1.0.0.dll bin/msys-crypto-1.0.0.dll (obviously those last two would be cygssl-1.0.0.dll and cygcrypto-1.0.0.dll) Now, that build used the following patches make-dummy-cert* Makefile.certificate openssl-0.9.6-x509.patch openssl-0.9.7-beta5-version-add-engines.patch openssl-0.9.8a-defaults.patch-1.0.0 openssl-0.9.8a-enginesdir.patch-1.0.0 openssl-0.9.8-beta6-icpbrasil.diff openssl-0.9.8e-crt.patch derived/taken from Mandriva. But at most those patches only affected the engine path, not the DLL names. -- Chuck
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On 25/06/2010 7:02 AM, Yaakov (Cygwin/X) wrote: On Thu, 2010-06-24 at 11:36 +0200, Corinna Vinschen wrote: So, what we have to do is to convert *ALL* existing package dependencies from openssl to libopenssl098. I'm going to do this in the setup.hint files on cygwin.com, but, please do this in your local copy of your setup.hint files as well. As soon as I upgraded to openssl-1.0.0a-1, make sure that you keep your package dependencies in shape when building a new package. That means to change from libopenssl098 to libopenssl100. Do you know yet what the actual DLL names are going to be? libkio dlopen()s these instead of linking against them, so I want to fix these for my next KDE release. However, isn't libcurl3 OBSOLETE, rather than ORPHANED? You are correct; I fixed this in CVS. apache2 ORPHANED (Max Bowsher) This desperately needs to be ITA'd. I have a version in Ports if anyone who actually uses this wants to pick it up: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ cyrus-sasl/libsasl2 ORPHANED (Gareth Pearce) cyrus-sasl/libsasl2-develORPHANED (Gareth Pearce) As previously discussed, these actually use libopenssl097. Yaakov I have no expectation that I will look at repackaging sasl ever - my motivation for that package is Long gone. --Gareth
[RFU] orpie setup.hint
Please re-upload the setup.hint for orpie. I've relaxed the dependency on lapack to just liblapack0, which will avoid lapack's repeated reinstallation problem in setup. Thanks, Andrew. wget http://home.comcast.net/~andrex2/cygwin/orpie/setup.hint
Re: [RFU] orpie setup.hint
On Jan 21 07:59, Andrew Schulman wrote: Please re-upload the setup.hint for orpie. I've relaxed the dependency on lapack to just liblapack0, which will avoid lapack's repeated reinstallation problem in setup. Thanks, Andrew. wget http://home.comcast.net/~andrex2/cygwin/orpie/setup.hint Thanks, uploaded. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: perl setup.hint changed
2009/12/27 Christopher Faylor: - Forwarded message from Ivanyi Peter - I just fixed the wrong setup.hint yesterday, so it could be that you got a broken setup.hint with no dependencies at all. You need those packages: libgcc1 libgdbm4 libdb4.5 crypt libexpat1 libbz2_1 shows that cygssp-0.dll is in the libssp0 package. So, install that package. Thanks. It solved the problem. Can I suggest that the package dependency should also be updated, since this dependency is missing from it? - End forwarded message - Reini, I just added libssp0 to perl's setup.hint. Hope that's ok. Sure, thanks. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
perl setup.hint changed
- Forwarded message from Ivanyi Peter - I just fixed the wrong setup.hint yesterday, so it could be that you got a broken setup.hint with no dependencies at all. You need those packages: libgcc1 libgdbm4 libdb4.5 crypt libexpat1 libbz2_1 shows that cygssp-0.dll is in the libssp0 package. So, install that package. Thanks. It solved the problem. Can I suggest that the package dependency should also be updated, since this dependency is missing from it? - End forwarded message - Reini, I just added libssp0 to perl's setup.hint. Hope that's ok. cgf
More setup.hint font adjustments
I've adjusted the setup.hint for a few packages to more accurately reflect the fonts they require, notes on which I've been collecting at [1] xedit: remove dependency on dpi100 versions of several font packages xman: change to depend on dpi75 not dpi100 versions of font-adobe and font-bh gvim: add dependency on font-adobe-dpi75, it's default font ddd: add dependency on font-bh-lucidatypewriter-dpi75, it's default font [1] http://sourceware.org/bugzilla/show_bug.cgi?id=9761
[RFU] screen setup.hint
I'm promoting the current test versions of screen to current. Please upload the revised setup.hints (below) to make the change. All I've done is to remove the test: and curr: lines from each setup.hint. Thanks, Andrew. # 1.5 wget http://home.comcast.net/~andrex2/cygwin/1.5/screen/setup.hint # 1.7 wget http://home.comcast.net/~andrex2/cygwin/screen/setup.hint
Re: [RFU] screen setup.hint
On 30/09/2009 10:56, Andrew Schulman wrote: I'm promoting the current test versions of screen to current. Please upload the revised setup.hints (below) to make the change. All I've done is to remove the test: and curr: lines from each setup.hint. Thanks, Done. Yaakov
[RFU] lftp setup.hint
Please upload revised setup.hint files, below, for lftp for Cygwin 1.5 and 1.7. The previous setup.hints were missing some package dependencies. For people whose lftp installations are broken because they didn't get all of the necessary dependencies when they installed lftp the first time, will setup.exe automatically pick up the missing dependencies the next time they run it, or will they have to explicitly choose to reinstall lftp? Thanks, Andrew. # 1.5 wget http://home.comcast.net/~andrex2/cygwin/1.5/lftp/setup.hint # 1.7 wget http://home.comcast.net/~andrex2/cygwin/lftp/setup.hint
Re: [RFU] lftp setup.hint
On Tue, Jul 21, 2009 at 04:14:47PM -0400, Andrew Schulman wrote: Please upload revised setup.hint files, below, for lftp for Cygwin 1.5 and 1.7. The previous setup.hints were missing some package dependencies. For people whose lftp installations are broken because they didn't get all of the necessary dependencies when they installed lftp the first time, will setup.exe automatically pick up the missing dependencies the next time they run it, or will they have to explicitly choose to reinstall lftp? The latter, I think. # 1.5 wget http://home.comcast.net/~andrex2/cygwin/1.5/lftp/setup.hint # 1.7 wget http://home.comcast.net/~andrex2/cygwin/lftp/setup.hint Thanks for fixing this. Uploaded. cgf
Re: [RFU] lftp setup.hint
On Tue, Jul 21, 2009 at 04:39:52PM -0400, Christopher Faylor wrote: On Tue, Jul 21, 2009 at 04:14:47PM -0400, Andrew Schulman wrote: Please upload revised setup.hint files, below, for lftp for Cygwin 1.5 and 1.7. The previous setup.hints were missing some package dependencies. For people whose lftp installations are broken because they didn't get all of the necessary dependencies when they installed lftp the first time, will setup.exe automatically pick up the missing dependencies the next time they run it, or will they have to explicitly choose to reinstall lftp? The latter, I think. # 1.5 wget http://home.comcast.net/~andrex2/cygwin/1.5/lftp/setup.hint Btw, this has a dependency on libreadline7. I changed it to libreadline6 since that is the newest package available for 1.5. cgf
Re: [RFU] lftp setup.hint
# 1.5 wget http://home.comcast.net/~andrex2/cygwin/1.5/lftp/setup.hint Btw, this has a dependency on libreadline7. I changed it to libreadline6 since that is the newest package available for 1.5. Right, thanks.
xterm setup.hint adjustment
Following [1] and other previous difficulties, I've added 'font-misc-misc font-adobe-dpi75 font-alias' to the 'requires:' for xterm This should be the minimal set of additions that xterm now starts up free of warnings [1] http://cygwin.com/ml/cygwin-xfree/2009-06/msg00067.html
