Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On 25/06/2020 12:53, Brian Inglis wrote: In: https://cygwin.com/git/?p=cygwin-htdocs.git;a=blob;f=packaging-package-files.html;hb=HEAD below, do you have a current URL for: https://sourceware.org/viewvc/cygwin-apps/packaging/templates/generic-readme?view=co 161 In your binary package, you may choose to include a file 162 /usr/share/doc/Cygwin/foo-vendor-suffix.README containing (at a minimum) the 163 information needed for an end user to recreate the package. This includes 164 CFLAGS settings, configure parameters, etc. (You can 165 adapt https://sourceware.org/viewvc/cygwin-apps/packaging/templates/generic-readme?view=co;>this 166 generic README.) 167 as I have tried some possible alternatives with the same result Yes, CVS has been retired on sourceware, so thanks for pointing out that broken link. I've obtained that content and updated the link. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On 2020-06-24 15:34, Jon Turney wrote: > On 21/06/2020 17:15, Brian Inglis wrote: >> On 2020-06-20 08:41, Jon Turney wrote: >>> On 19/06/2020 07:55, Brian Inglis wrote: >>> This analysis is not complete or correct because it doesn't take >>> 'obsoletes:' >>> into account: >>> https://sourceware.org/git/?p=cygwin-apps/calm.git;a=commitdiff;h=d75abceedb46749982669236c5c102796a1fbfb1;hp=f92ad1d5c292ed54e7a62f5c52280efab8267f37 >>> >>> It does seem that things aren't working as intended, though. >> >> So does that obsoletes: mean something different than category: _obsoletes, >> which I view as a (Debian-like) virtual package declaration? > > There's no need to guess, when the source code is available to inspect. > > All the '_obsolete' category (note no 's') does is cause packages to get > hidden > by the 'Hide obsolete packages' filter in setup (which is on by default). > > So yes, these are completely different things. > >> Are obsoletes and pre-depends documented anywhere else (and any other new >> keywords)? > > https://cygwin.com/packaging-hint-files.html > https://sourceware.org/cygwin-apps/setup.ini.html Thanks for the pointers. In: https://cygwin.com/git/?p=cygwin-htdocs.git;a=blob;f=packaging-package-files.html;hb=HEAD below, do you have a current URL for: https://sourceware.org/viewvc/cygwin-apps/packaging/templates/generic-readme?view=co 161 In your binary package, you may choose to include a file 162 /usr/share/doc/Cygwin/foo-vendor-suffix.README containing (at a minimum) the 163 information needed for an end user to recreate the package. This includes 164 CFLAGS settings, configure parameters, etc. (You can 165 adapt https://sourceware.org/viewvc/cygwin-apps/packaging/templates/generic-readme?view=co;>this 166 generic README.) 167 as I have tried some possible alternatives with the same result i.e. Forbidden You don't have permission to access /viewvc/cygwin-apps/packaging/templates/generic-readme on this server. e.g. http://sourceware.org/cvsweb.cgi/packaging/templates/generic-readme -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On 21/06/2020 17:15, Brian Inglis wrote: On 2020-06-20 08:41, Jon Turney wrote: On 19/06/2020 07:55, Brian Inglis wrote: This analysis is not complete or correct because it doesn't take 'obsoletes:' into account: https://sourceware.org/git/?p=cygwin-apps/calm.git;a=commitdiff;h=d75abceedb46749982669236c5c102796a1fbfb1;hp=f92ad1d5c292ed54e7a62f5c52280efab8267f37 It does seem that things aren't working as intended, though. So does that obsoletes: mean something different than category: _obsoletes, which I view as a (Debian-like) virtual package declaration? There's no need to guess, when the source code is available to inspect. All the '_obsolete' category (note no 's') does is cause packages to get hidden by the 'Hide obsolete packages' filter in setup (which is on by default). So yes, these are completely different things. Are obsoletes and pre-depends documented anywhere else (and any other new keywords)? https://cygwin.com/packaging-hint-files.html https://sourceware.org/cygwin-apps/setup.ini.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
> -Original Message- > From: My Name > Sent: Monday, June 22, 2020 2:34 AM > To: Allen Hewes > Subject: Re: Apparent bug in either (1) Cygwin default Package-list or (2) > Package "bzr" dependency-list > > > WSL2 > > At your convenience, can you please link to instructions on how to install and > start WSL2? I spent some hours searching and trying, but all I found was > people asking Microsoft for instructions, Microsoft giving answers, people > saying the Microsoft's answers didn't work, and the Microsoft agents > disappearing; and a variety of conflicting instructions on Microsoft's site, > as if > they had changed the installation / startup procedure repeatedly, without > leaving a trail to whichever method is current. I forgot to add that you can't run WSL2 and VirtualBox at the same time. WSL2 uses Hyper-V under the covers and that's incompatible with VirtualBox atm. You can make VirtualBox run with Hyper-V but the scuttlebutt is you'd have much more fun watching paint dry than running VirtualBox guests on Hyper-V... If you use VirtualBox don't use WSL2. /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
> -Original Message- > From: My Name > Sent: Monday, June 22, 2020 2:34 AM > To: Allen Hewes > Subject: Re: Apparent bug in either (1) Cygwin default Package-list or (2) > Package "bzr" dependency-list > > > WSL2 > > At your convenience, can you please link to instructions on how to install and > start WSL2? I spent some hours searching and trying, but all I found was > people asking Microsoft for instructions, Microsoft giving answers, people > saying the Microsoft's answers didn't work, and the Microsoft agents > disappearing; and a variety of conflicting instructions on Microsoft's site, > as if > they had changed the installation / startup procedure repeatedly, without > leaving a trail to whichever method is current. > This is it: https://docs.microsoft.com/en-us/windows/wsl/install-win10. So as with lots of Microsoft docs, you'll need to read the fine print, because it matters with WSL2. Install WSL first, then upgrade to WSL2. You need the just released Windows 10 2004 version. WSL2 just landed "regular folks" in Windows 10 2004 (20H1). ...and we are moving the thread from it's original intent... Now, keep in mind that even with WSL, you will run into Python 2 deprecation issues. For instance, I prefer to use Fedora when I use Linux. The next version of Fedora won't have Python 2 as an installable option. So you'll be in the same Python 2 boat. Now, if you choose to run (and pay for) an "Enterprise OS" (cough, cough), you'll be OK, but in 2020 who does that? :trollface: I guess you could run one of the LTS Ubuntu's... I don't have any direct experience with Ubuntu myself. /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
> > by default "python" is "python2" so anything calling python still requires > python2, see: > > https://www.python.org/dev/peps/pep-0394/ > > and there are a lot of packages in cygwin doing it. > > Packaging requires time and currently on python we are short of it. > > I am moving to package all python-subpackages for 3.8 and after we can look > to move some packages from python2 (2.7) to python 3 (target 3.8) > Thanks Marco. Yep, I know about the python/python2/python3 naming PEP. I just got frustrated a little and went full bore on making my "python" (and all his friends) mean "python3" (). If/when Cygwin gets to Python3 clean, I'll revert my alternatives. For me, I think there's a PostgreSQL contrib package that has a dependency on Python2, which is why I can't remove it (I _think_). But I suspect you would already have it in your list. I have played around with packaging on Cygwin and I found it difficult and inconsistent. Meaning, if it was like koji/rpm, I would find it easier to contribute/participate. I lost arm wrestling matches with cygport and packages that don't cygport... then I got deterred... I would like to pitch in. Is there beginner stuff? There's a different ML for packaging folks isn't there? I have used Cygwin daily for many years but I have found myself trying out WSL2 (I never tried WSL1). Thanks, /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
> -Original Message- > From: My Name > Sent: Monday, June 22, 2020 12:34 AM > To: Allen Hewes > Subject: Re: Apparent bug in either (1) Cygwin default Package-list or > (2) Package "bzr" dependency-list > > I'm intrigued, since you're the second person to recommend Breezy to > me (the first being from the thread I cited previously). But I see > it's not available via Cygwin Setup, and I got the idea that > installing any software via pip for use in Cygwin is risky, because > via pip, the software hasn't been ported for use in Cygwin, so there's > no guarantee the software is compatible with Cygwin's quirks like, IIRC, > symbolic links. Is there validity to my concern? > I think the person that suggested Breezy in your ticket was one of the authors of Bazaar. Well, just because a Python package isn't available via Cygwin setup doesn't mean it's not compatible. There are many Python packages that aren't packaged by the platform/OS packager/vendor. It's this way for Linux also and Perl and Ruby. Pip/PyPy/distuls/wheels are all methods of packaging and distributing Python packages to downstream end-users. I would say they predate Cygwin but Cygwin itself has very long teeth. It's been around for a very long time. If Cygwin folks weren't around or if none of them cared enough to create Python packages as Cygwin packages, Python packages would still exist and need a mechanism for deploy/install to end-users. This is what pip does for Python. There are also methods of keeping your pip installs from the platform/OS packaged ones. There are circumstances which Python package authors don't consider Cygwin or their package is intended to target a specific OS/platform. I have found that this is the exception and not the rule. Generally, for my use cases (AWS), I use pip exclusively and don't want Cygwin's versions of Python packages. I prefer *not* to use them. I also use pipenv/virtualenv and friends. Keep in mind, this is what I do for myself and the folks I help. So this isn't a black or white type of thing. Some of it is A Cygwin Thing (requires a POSIX layer), some of it is A Windows Thing (don't need a POSIX layer), some of if is end-user choice. You can make a general assumption (uh-oh) that if the Python package requires or has a C (but could also be Python) based part to it, you may (or may not) have trouble with it via pip on Cygwin. Here again, "it just depends" and this isn't quantifiable. Generally, the Python packages that don't support Cygwin will include this in the error message during the pip install, this also is a "it just depends". I think a lot of this depends on the effort to make the Python package run on the destination target, like Cygwin. Every platform/OS does things differently with linking, libraries, headers, object files, pathing. For instance, I use mostly (not all) pure Python packages (88 right now) and I install and manage them all via pip/virtualenv and not Cygwin Setup. > How backwards compatible is Breezy with Bazaar? Even if it would be > good for me to switch to Breezy in the long run, I'm trying to finish > some projects important to me, and now wouldn't be a good time for me > to have to learn anything new about version control. > The link I proved suggested full backwards compatibility to Bazaar, but I don't use Bazaar or have ever used it. I (must) use git/GitHub Enterprise, I don't have a choice. > I hadn't known 2020 was a special year for python2, but now I'm > gathering that 2020 might mean something bad for python2. > Well, Python was supposed to be gone in Jan 2020 but they released 2.7.18[1]. 2.7.18 is supposed to be the last release again[1]. The Python project manages these types of thigs with PEPs. The one for Python 2.7 is PEP 0373[2]. > Thanks for giving me an alternative to consider. Last time I tried > git, I wasn't a fan. Too complicated for a one-man, one-machine operation > like mine. > Since you like Bazaar, I would take a serious look at Breezy when you have time. /allen [1] from https://www.python.org/downloads/release/python-2718/, "Python 2.7.18 is the last release of Python 2." [2] https://www.python.org/dev/peps/pep-0373/ Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On 22.06.2020 04:21, Allen Hewes via Cygwin wrote: -Original Message- From: Cygwin On Behalf Of My Name via Cygwin Sent: Sunday, June 21, 2020 2:04 PM To: brian.ing...@systematicsw.ab.ca Cc: The Cygwin Mailing List Subject: Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list This is mostly over my head, so I'm sorry if my comment here is irrelevant, but I'll point out in case anyone here doesn't know, Python 3 doesn't make Python 2 obsolete. They are somewhat incompatible. Python 2 source doesn't always run in Python 3 without extensive modification. If there's any message you all would like me to deliver to the Bazaar (bzr) forum, I will; but I'm not a Bazaar developer either, just a user. Yep, I am in agreement here. I don't understand why Python 2 gets attention from Cygwin maintainers. I have a found a few packages that are "linked" (e.g. they have dependencies on either the Python27 or Python2/Python meta-package), which would explain this to some degree. Usually, it's just a rebuild (e.g. a re-configure) of the depending-ee... I can't get rid of three Python 2.7 packages: python27, python27-pip, python27-setuptools. I switched over to using alternatives (sometime ago) so that I can "stop" the craziness of the meta-package "python". I don't want Python 2 as my 'python'. The need to have two Pythons installed at the same time seems to be over. Shouldn't this remove the need to have meta-packages? Cygiwn isn't alone is keeping Python 2 alive. /allen by default "python" is "python2" so anything calling python still requires python2, see: https://www.python.org/dev/peps/pep-0394/ and there are a lot of packages in cygwin doing it. Packaging requires time and currently on python we are short of it. I am moving to package all python-subpackages for 3.8 and after we can look to move some packages from python2 (2.7) to python 3 (target 3.8) Regards MArco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
Bazaar depends on python2, at least according to this person's suggestion: > Bazaar doesn't support python3, it only supports python2.7. I'm guessing (https://answers.launchpad.net/bzr/+question/691381) I for one want to continue using Bazaar in Cygwin, so I'm grateful that python2 is at least an option in Cygwin. Bazaar is free and open-source, and I'm not a contributor, so I'm in no position to tell them to update their software so that it depends on python3 only. On Sun, Jun 21, 2020 at 7:21 PM Allen Hewes via Cygwin wrote: > > -Original Message- > > From: Cygwin On Behalf Of My Name via > > Cygwin > > Sent: Sunday, June 21, 2020 2:04 PM > > To: brian.ing...@systematicsw.ab.ca > > Cc: The Cygwin Mailing List > > Subject: Re: Apparent bug in either (1) Cygwin default Package-list or > (2) > > Package "bzr" dependency-list > > > > This is mostly over my head, so I'm sorry if my comment here is > irrelevant, > > but I'll point out in case anyone here doesn't know, Python 3 doesn't > make > > Python 2 obsolete. They are somewhat incompatible. Python 2 source > > doesn't always run in Python 3 without extensive modification. If > there's any > > message you all would like me to deliver to the Bazaar (bzr) forum, I > will; but > > I'm not a Bazaar developer either, just a user. > > > > Yep, I am in agreement here. I don't understand why Python 2 gets > attention from Cygwin maintainers. I have a found a few packages that are > "linked" (e.g. they have dependencies on either the Python27 or > Python2/Python meta-package), which would explain this to some degree. > Usually, it's just a rebuild (e.g. a re-configure) of the depending-ee... > > I can't get rid of three Python 2.7 packages: python27, python27-pip, > python27-setuptools. I switched over to using alternatives (sometime ago) > so that I can "stop" the craziness of the meta-package "python". I don't > want Python 2 as my 'python'. > > The need to have two Pythons installed at the same time seems to be over. > Shouldn't this remove the need to have meta-packages? > > Cygiwn isn't alone is keeping Python 2 alive. > > /allen > > > > Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or > documents linked to this email, are intended for the addressee and may > contain information that is privileged, confidential, proprietary, or > otherwise protected by law. Any dissemination, distribution, or copying is > prohibited. This notice serves as a confidentiality marking for the purpose > of any confidentiality or nondisclosure agreement. If you have received > this communication in error, please contact the original sender. > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
> -Original Message- > From: Cygwin On Behalf Of My Name via > Cygwin > Sent: Sunday, June 21, 2020 2:04 PM > To: brian.ing...@systematicsw.ab.ca > Cc: The Cygwin Mailing List > Subject: Re: Apparent bug in either (1) Cygwin default Package-list or (2) > Package "bzr" dependency-list > > This is mostly over my head, so I'm sorry if my comment here is irrelevant, > but I'll point out in case anyone here doesn't know, Python 3 doesn't make > Python 2 obsolete. They are somewhat incompatible. Python 2 source > doesn't always run in Python 3 without extensive modification. If there's any > message you all would like me to deliver to the Bazaar (bzr) forum, I will; > but > I'm not a Bazaar developer either, just a user. > Yep, I am in agreement here. I don't understand why Python 2 gets attention from Cygwin maintainers. I have a found a few packages that are "linked" (e.g. they have dependencies on either the Python27 or Python2/Python meta-package), which would explain this to some degree. Usually, it's just a rebuild (e.g. a re-configure) of the depending-ee... I can't get rid of three Python 2.7 packages: python27, python27-pip, python27-setuptools. I switched over to using alternatives (sometime ago) so that I can "stop" the craziness of the meta-package "python". I don't want Python 2 as my 'python'. The need to have two Pythons installed at the same time seems to be over. Shouldn't this remove the need to have meta-packages? Cygiwn isn't alone is keeping Python 2 alive. /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
This is mostly over my head, so I'm sorry if my comment here is irrelevant, but I'll point out in case anyone here doesn't know, Python 3 doesn't make Python 2 obsolete. They are somewhat incompatible. Python 2 source doesn't always run in Python 3 without extensive modification. If there's any message you all would like me to deliver to the Bazaar (bzr) forum, I will; but I'm not a Bazaar developer either, just a user. On Sun, Jun 21, 2020 at 9:16 AM Brian Inglis < brian.ing...@systematicsw.ab.ca> wrote: > On 2020-06-20 08:41, Jon Turney wrote: > > On 19/06/2020 07:55, Brian Inglis wrote: > > This analysis is not complete or correct because it doesn't take > 'obsoletes:' > > into account: > > > https://sourceware.org/git/?p=cygwin-apps/calm.git;a=commitdiff;h=d75abceedb46749982669236c5c102796a1fbfb1;hp=f92ad1d5c292ed54e7a62f5c52280efab8267f37 > > It does seem that things aren't working as intended, though. > > So does that obsoletes: mean something different than category: _obsoletes, > which I view as a (Debian-like) virtual package declaration? > Are obsoletes and pre-depends documented anywhere else (and any other new > keywords)? > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On 2020-06-20 08:41, Jon Turney wrote: > On 19/06/2020 07:55, Brian Inglis wrote: > This analysis is not complete or correct because it doesn't take 'obsoletes:' > into account: > https://sourceware.org/git/?p=cygwin-apps/calm.git;a=commitdiff;h=d75abceedb46749982669236c5c102796a1fbfb1;hp=f92ad1d5c292ed54e7a62f5c52280efab8267f37 > It does seem that things aren't working as intended, though. So does that obsoletes: mean something different than category: _obsoletes, which I view as a (Debian-like) virtual package declaration? Are obsoletes and pre-depends documented anywhere else (and any other new keywords)? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On 20.06.2020 16:41, Jon Turney wrote: On 19/06/2020 07:55, Brian Inglis wrote: Looks like cygport, calm, and setup disagree about install dependencies; from setup.ini: bzr requires: python depends2: python python requires: python2 depends2: python2 requires: python27 depends2: so although python requires python2, and python2 requires python27, the (newer) depends2 entries are not the same and are empty, so setup ignores requires and does not install the dependency. In these cases, either depends2 should be the same as requires, or depends2 should be omitted, and setup should install requires. This analysis is not complete or correct because it doesn't take 'obsoletes:' into account. (See [1] for the technical details) It does seem that things aren't working as intended, though. [1] https://sourceware.org/git/?p=cygwin-apps/calm.git;a=commitdiff;h=d75abceedb46749982669236c5c102796a1fbfb1;hp=f92ad1d5c292ed54e7a62f5c52280efab8267f37 -- I think I solved the issue re-uploading all the python2 hints for both arch. Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On 19/06/2020 07:55, Brian Inglis wrote: Looks like cygport, calm, and setup disagree about install dependencies; from setup.ini: bzr requires: python depends2: python python requires: python2 depends2: python2 requires: python27 depends2: so although python requires python2, and python2 requires python27, the (newer) depends2 entries are not the same and are empty, so setup ignores requires and does not install the dependency. In these cases, either depends2 should be the same as requires, or depends2 should be omitted, and setup should install requires. This analysis is not complete or correct because it doesn't take 'obsoletes:' into account. (See [1] for the technical details) It does seem that things aren't working as intended, though. [1] https://sourceware.org/git/?p=cygwin-apps/calm.git;a=commitdiff;h=d75abceedb46749982669236c5c102796a1fbfb1;hp=f92ad1d5c292ed54e7a62f5c52280efab8267f37 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On Fri, Jun 19, 2020 at 8:56 AM Brian Inglis wrote: > > On 2020-06-18 21:33, My Name via Cygwin wrote: > > I found an apparent dependency problem in Cygwin, and I'm not enough of a > > Cygwin expert to know whether the bug is in Cygwin or Bazaar (Package > > "bzr"); but if I had to guess, I'd guess it's in Cygwin, and I've already > > reported the issue to the Bazaar forum. > > > > In summary, after I installed Cygwin and Cygwin-Package "bzr", bzr failed > > as it attempted to execute "python27". A detailed description of the issue, > > including input and output from several tests I ran, and including the > > solution posted by someone else (solution = install Cygwin-Package > > "python27") is here, https://answers.launchpad.net/bzr/+question/691381, > > and it's rather concise so I'll end here and refer you to that thread. > > > > Per the directions here, https://cygwin.com/problems.html, I'm > > email-attaching the output from "cygcheck -s -v -r". > > Looks like cygport, calm, and setup disagree about install dependencies; from > setup.ini: > > bzr > requires: python > depends2: python > > python > requires: python2 > depends2: > > python2 > requires: python27 > depends2: > > so although python requires python2, and python2 requires python27, the > (newer) > depends2 entries are not the same and are empty, so setup ignores requires and > does not install the dependency. > > In these cases, either depends2 should be the same as requires, or depends2 > should be omitted, and setup should install requires. > it seems a glitch of the last packing of python2. I will review the dependency and re upload them in the weeked Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
On 2020-06-18 21:33, My Name via Cygwin wrote: > I found an apparent dependency problem in Cygwin, and I'm not enough of a > Cygwin expert to know whether the bug is in Cygwin or Bazaar (Package > "bzr"); but if I had to guess, I'd guess it's in Cygwin, and I've already > reported the issue to the Bazaar forum. > > In summary, after I installed Cygwin and Cygwin-Package "bzr", bzr failed > as it attempted to execute "python27". A detailed description of the issue, > including input and output from several tests I ran, and including the > solution posted by someone else (solution = install Cygwin-Package > "python27") is here, https://answers.launchpad.net/bzr/+question/691381, > and it's rather concise so I'll end here and refer you to that thread. > > Per the directions here, https://cygwin.com/problems.html, I'm > email-attaching the output from "cygcheck -s -v -r". Looks like cygport, calm, and setup disagree about install dependencies; from setup.ini: bzr requires: python depends2: python python requires: python2 depends2: python2 requires: python27 depends2: so although python requires python2, and python2 requires python27, the (newer) depends2 entries are not the same and are empty, so setup ignores requires and does not install the dependency. In these cases, either depends2 should be the same as requires, or depends2 should be omitted, and setup should install requires. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list
I found an apparent dependency problem in Cygwin, and I'm not enough of a Cygwin expert to know whether the bug is in Cygwin or Bazaar (Package "bzr"); but if I had to guess, I'd guess it's in Cygwin, and I've already reported the issue to the Bazaar forum. In summary, after I installed Cygwin and Cygwin-Package "bzr", bzr failed as it attempted to execute "python27". A detailed description of the issue, including input and output from several tests I ran, and including the solution posted by someone else (solution = install Cygwin-Package "python27") is here, https://answers.launchpad.net/bzr/+question/691381, and it's rather concise so I'll end here and refer you to that thread. Per the directions here, https://cygwin.com/problems.html, I'm email-attaching the output from "cygcheck -s -v -r". cygcheck.out Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
