Question about slow access to file information
Dear Cygwin'ers - I have a separate drive mounted this way: d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0 One thing I use it for is to store backup files. These tend to be 2 Gb chunks, and there can be hundreds of them in the backup directory. (The drive is 5Tb.) The Windows Disk Management tool describes it as NTFS, Basic Data Partition. Doing ls (for example) takes a very perceptible numbers of seconds (though whatever takes a long time seems to be cached, at least for a while, since a second ls soon after is fast). Windows Explorer (for example) and CMD do not seem to suffer this delay. Any notion as to what is happening and what I might do to ameliorate it? If it matters, the drive is removable (an external WD MyPassport hard drive). Regards - Eliot Moss -- 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: newlib-cygwin.git repository: Switching "master" to "main"
On 1/14/2023 7:16 AM, Dave McGuire via Cygwin wrote: On 1/13/23 14:57, Adam Dinwoodie wrote: On Fri, Jan 13, 2023 at 02:23:44PM -0500, Mike Frysinger via Cygwin wrote: thanks for doing this! -mike Seconded! This clearly isn't going to solve racism in a single step, but making our community that bit more welcoming -- particularly when the cost of the change is essentially zero -- has to be a positive move. You guys have GOT to be kidding me. Umm, no. For example, the gem5 project (a computer architecture simulator including estimated timing) has deprecated master/slave terminology for port protocols. The way I would put it is this: We swim in a sea of racism mostly not realizing it, just as we move in air usually without thinking about it. This is true for all people in our culture, no matter their ethnicity. This small change make us more conscious of what is usually unconscious or subconscious, and it does not cost us much to do it. Regards - Eliot Moss -- 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: newlib-cygwin.git repository: Switching "master" to "main"
On 1/13/23 14:57, Adam Dinwoodie wrote: On Fri, Jan 13, 2023 at 02:23:44PM -0500, Mike Frysinger via Cygwin wrote: thanks for doing this! -mike Seconded! This clearly isn't going to solve racism in a single step, but making our community that bit more welcoming -- particularly when the cost of the change is essentially zero -- has to be a positive move. You guys have GOT to be kidding me. -- Dave McGuire, AK4HZ New Kensington, PA -- 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: newlib-cygwin.git repository: Switching "master" to "main"
On Fri, Jan 13, 2023 at 02:23:44PM -0500, Mike Frysinger via Cygwin wrote: > thanks for doing this! > -mike Seconded! This clearly isn't going to solve racism in a single step, but making our community that bit more welcoming -- particularly when the cost of the change is essentially zero -- has to be a positive move. -- 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: [ATTN MAINTAINER] tig
On Fri, Jan 13, 2023 at 06:06:22PM +0100, Libor Ukropec via Cygwin-apps wrote: > Dne 13.01.2023 v 17:59 Libor Ukropec via Cygwin-apps napsal(a): > > Dne 10.01.2023 v 15:04 Jari Aalto via Cygwin-apps napsal(a): > > > > > > > > Hi, Thanks for the heads up. I've uploaded new version and added the > > > *.cygport in my Github repository of tig for possible new maintainer > > > in the future. > > > > > > The patches deal some fixes in the xmlto(1) of manual pages build. > > > > > > Jari > > > > > Hi Jari, > > > > I updated to the latest tig, but when executing, it complains about > > missing dependency, but recently I saw many updates to the cygwin > > packages. Any idea if other package was broken, or tig is missing some > > dependency in the metadata? > > > > C:/cygwin64/bin/tig.exe: error while loading shared libraries: > > cygpcreposix-0.dll: cannot open shared object file: No such file or > > directory > > > > Manual installation of "libpcreposix0 8.45-1" seems resolving the problem. > > > > Libor > > > Problem lies somewhere in the compile process? > here is my output for tig I compiled few weeks ago: > > $ ldd ./ttiigg/tig-2.5.4-1.x86_64/build/src/tig.exe > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659) > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > (0x7ffe8516) > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > (0x7ffe839e) > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d) > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d) > cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3) > > > and here is from the installed: > $ ldd /usr/bin/tig.exe > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659) > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > (0x7ffe8516) > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > (0x7ffe839e) > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d) > cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3) > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d) > cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3fd63) > cygreadline7.dll => /usr/bin/cygreadline7.dll (0x579cd) > cygpcreposix-0.dll => /usr/bin/cygpcreposix-0.dll (0x520b4) I strongly suspect that, like git, tig will use libpcre if it was present at compile time, and won't if it isn't. Typically I'd expect distribution builds to include libpcre support for this sort of thing. That would mean Jari's compilation was correct, but the .hint files didn't correctly list the necessary dependencies. Jari, your email mentioned a possible new maintainer; are you intending to hand over responsibility, or do you just mean for a hypothetical future maintainer at some point in the future?
Re: newlib-cygwin.git repository: Switching "master" to "main"
thanks for doing this! -mike signature.asc Description: PGP signature -- 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: [ATTN MAINTAINER] tig
On 2023-01-13 10:06, Libor Ukropec via Cygwin-apps wrote: Dne 13.01.2023 v 17:59 Libor Ukropec via Cygwin-apps napsal(a): Dne 10.01.2023 v 15:04 Jari Aalto via Cygwin-apps napsal(a): Thanks for the heads up. I've uploaded new version and added the *.cygport in my Github repository of tig for possible new maintainer in the future. The patches deal some fixes in the xmlto(1) of manual pages build. I updated to the latest tig, but when executing, it complains about missing dependency, but recently I saw many updates to the cygwin packages. Any idea if other package was broken, or tig is missing some dependency in the metadata? C:/cygwin64/bin/tig.exe: error while loading shared libraries: cygpcreposix-0.dll: cannot open shared object file: No such file or directory Manual installation of "libpcreposix0 8.45-1" seems resolving the problem. Problem lies somewhere in the compile process? here is my output for tig I compiled few weeks ago: $ ldd ./ttiigg/tig-2.5.4-1.x86_64/build/src/tig.exe ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659) KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffe8516) KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffe839e) cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d) cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3) and here is from the installed: $ ldd /usr/bin/tig.exe ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659) KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffe8516) KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffe839e) cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d) cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d) cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3fd63) cygreadline7.dll => /usr/bin/cygreadline7.dll (0x579cd) cygpcreposix-0.dll => /usr/bin/cygpcreposix-0.dll (0x520b4) Config issues, as you appear not to have installed prerequisite packages libncurses-devel, libpcre-devel, libreadline-devel in your build environment. Those package names should also be added to your cygport DEPEND/BUILD_REQUIRES+= string variables, so that cygport can warn you if the packages are not installed, and will be auto-installed so the package builds cleanly under Scallywag CI, when you push your cygport (and other sources and patches) to git/cygwin-packages playground repo or package branch or master package branch. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: Version string of package
On 2023-01-13 07:21, Takashi Yano via Cygwin-apps wrote: On Fri, 13 Jan 2023 13:22:44 + Jon Turney wrote: On 13/01/2023 11:52, Takashi Yano via Cygwin-apps wrote: Hi, Is it allowed to include '-' in version string (e.g. '20230113-stable')? I'm asking because mksetupini warns: mksetupini: file 'xxx.tar.xz' in package yyy contains '-' in version though it works as expected. Short answer: It's a bug that this isn't a fatal error. Please don't do it! Long answer: Package naming in Cygwin has a long and tangled history. This isn't explicitly precluded by the rules at [1], but probably should be. (Fedora, which we generally follow for packaging rules, now doesn't allow '-' in versions, just digits, letters and '.') We need to be able to unambiguously separate a NVR string into the package name, version and release. Underscores are allowed in package names, so the simple approach of splitting on the rightmost two hyphens would work, if we don't allow exceptions like this. (We can get it right in this case, because we have a piece of extra information: the directory the package is in, which happens to always be named N in the current scheme of things, but we might want to change that) [1] https://cygwin.com/packaging-package-files.html In any case, you should be suspicious of using upstream version names of this form. They may expect the 'stable' string to sort against other strings based on meaning, rather than alphabetically (e.g. '20230113-testing' is considered greater, which is probably not what's wanted) Thanks for the answer. I'll use version 20230113 with release 1.g e.g. package-name-20230113-1.g123456789abc like cygwin test package. We typically use *stable* commit dates of unambiguous commits or incremental versions rather than hashes even when packages are pulled from repos which do not provide releases e.g. ca-certificates, libhsts, publicsuffix-list. We also have packages where the versions have been frozen for historical reasons and new versions have release numbers like 1.mmdd, 2.MMDD, etc. Status like stable is assumed of current releases, as test releases can be promoted to current stable release using 'untest'. Other suffixes normally use release 0 and imply never being promoted to current from pre-release candidates, like Cygwin snapshots and interim test releases. You can keep the hash info around in your build or cygport but it does not help users, as you are already using a date version and a release, so you might as well drop it from the package. We can handle numbering issues using cygport SRC_URI, SRC_DIR, CYGPORT_USE_UNSTABLE_API source hooks, and src_... script overrides. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: [ATTN MAINTAINER] tig
Dne 13.01.2023 v 17:59 Libor Ukropec via Cygwin-apps napsal(a): Dne 10.01.2023 v 15:04 Jari Aalto via Cygwin-apps napsal(a): Hi, Thanks for the heads up. I've uploaded new version and added the *.cygport in my Github repository of tig for possible new maintainer in the future. The patches deal some fixes in the xmlto(1) of manual pages build. Jari Hi Jari, I updated to the latest tig, but when executing, it complains about missing dependency, but recently I saw many updates to the cygwin packages. Any idea if other package was broken, or tig is missing some dependency in the metadata? C:/cygwin64/bin/tig.exe: error while loading shared libraries: cygpcreposix-0.dll: cannot open shared object file: No such file or directory Manual installation of "libpcreposix0 8.45-1" seems resolving the problem. Libor Problem lies somewhere in the compile process? here is my output for tig I compiled few weeks ago: $ ldd ./ttiigg/tig-2.5.4-1.x86_64/build/src/tig.exe ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659) KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffe8516) KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffe839e) cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d) cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3) and here is from the installed: $ ldd /usr/bin/tig.exe ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659) KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffe8516) KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffe839e) cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d) cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d) cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3fd63) cygreadline7.dll => /usr/bin/cygreadline7.dll (0x579cd) cygpcreposix-0.dll => /usr/bin/cygpcreposix-0.dll (0x520b4)
Re: [ATTN MAINTAINER] tig
Dne 10.01.2023 v 15:04 Jari Aalto via Cygwin-apps napsal(a): Hi, Thanks for the heads up. I've uploaded new version and added the *.cygport in my Github repository of tig for possible new maintainer in the future. The patches deal some fixes in the xmlto(1) of manual pages build. Jari Hi Jari, I updated to the latest tig, but when executing, it complains about missing dependency, but recently I saw many updates to the cygwin packages. Any idea if other package was broken, or tig is missing some dependency in the metadata? C:/cygwin64/bin/tig.exe: error while loading shared libraries: cygpcreposix-0.dll: cannot open shared object file: No such file or directory Manual installation of "libpcreposix0 8.45-1" seems resolving the problem. Libor
Re: [clisp-list] FYI: Cygwin package is crippled: no FFI.
[Redirecting from the clisp list.] On 1/12/2023 3:03 AM, Kaz Kylheku wrote: Hi All, Just a heads up that whoever is maintaining the CLISP package for Cygwin seems not to have built it with FFI support. The FFI package doesn't exist. I'm trying to use an old program of mine, and oops! I'm Cygwin's clisp maintainer. But it's been several years since I've thought about it, and I'm not interested in going back and trying to remember what I did and why. If you'd like to take over as maintainer and try to add FFI support, you're welcome to it. Ken -- 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: newlib-cygwin.git repository: Switching "master" to "main"
On Jan 13 14:20, Sam Edge via Cygwin wrote: > On 13/01/2023 11:55, Corinna Vinschen via Cygwin wrote: > > Hey folks, > > > > In the light of recent discussions, and following other projects already > > having done this step, we changed the name of the "master" branch in > > the newlib-cygwin.git upstream repository to "main". > > > > If you fetched from upstream in the last two days, you might already > > have noticed that an "origin/main" branch suddenly showed up, but your > > "master" branch still worked as before. > > > > The reason is that we also added a symbolic reference upstream, so that > > "origin/master" points to "origin/main". Both "branches" are now > > constantly kept in sync upstream. > > > > Therefore, you can continue your work on "master" without disruption, > > if you prefer to do so. > > > > However, on the client side, the "master" and "main" branches are > > treated as two distinct branches. If you work on your local "main" > > clone and commit a patch, it's not keeping your local "master" branch in > > sync. After pushing your change upstream, though, the upstream idea of > > "main" and "master" is, again, the same. After fetching from upstream, > > the patch will show up in both tracking branches, "origin/main" as well > > as "origin/master", so pulling on both local branches will show the same > > tree. > > > > Having said that. Ideally you only use one of the branches locally > > to avoid any confusion: > > > > - If you prefer to work in "master", just continue to do so and don't > > create a local "main" branch tracking "origin/main". > > > > - If you prefer to work in "main", checkout "origin/main" as "main" and > > delete your local "master" branch. > > > > > > Have fun, > > Corinna > > > > > > While I can understand sensitivity over the word 'slave' this is taking > things > too far in my opinion. I just conducted a quick poll of my Afro-Caribbean & > other non-Caucasian workmates who all express the same sentiment. > [...] > Well, it's a fait accompli on the Cygwin repos. That's why we chose the symbolic ref solution. You can use both in future, whichever you like more. Corinna -- 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: [ITP] libinih
On 11/01/2023 23:16, Adam Dinwoodie via Cygwin-apps wrote: On Wed 11 Jan 2023 at 03:14:20PM +, Jon Turney wrote: On 09/01/2023 16:32, Adam Dinwoodie via Cygwin-apps wrote: As requested at [0], I've offered to package libinih for Cygwin. It has a BSD license[1] and is already packaged for a bunch of *nix distros, including Fedora, Debian and Arch[2]. [0]: https://cygwin.com/pipermail/cygwin/2023-January/252780.html [1]: https://github.com/benhoyt/inih/blob/master/LICENSE.txt [2]: https://repology.org/project/inih/versions Provisional release packages are available at [3], and I've copied the main .hint file below for reference. [3]: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc1 Thanks. This looks good, except... I've not maintained this sort of library before; I've defaulted to including everything in a single package, but Lem suggested splitting out a -devel package to contain the header files[4][5]. I don't think it makes much difference either way -- the monolithic package is only ~16 KB compressed -- and it seems plenty of other Cygwin packages have their header files in the same package as the runtime package, but I'd appreciate thoughts from everyone else on what's thought to be best practice these days... I'd ask you to split this into libinih0 and libinih-devel packages. Firstly, I don't want to get into making judgements about what the size threshold is for a package to be "small enough to not bother". Secondly, I think, if there's ever a soversion change (i.e. cyginih-0.dll becomes cyginih-1.dll), structuring it as a single package makes it impossible to parallel install the old and new soversions together, thus breaking any other packages linked with the old soversion until they are rebuilt. Makes sense! Here's a rebuild: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc2 If you're aware of other packages "done wrong" based on that understanding, I guess that's something that needs looking into... Ah, I think I was thinking about this backwards. I'd thought that, for example, make is a problem, because it's not marked as a "*-devel" package, but it puts a header file in /usr/include as well as all the files needed by mere users of make.[0] [0]: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmake%2Fmake-4.4-1 It sounds like that's not a problem at all, though: make doesn't provide any libraries to link against. Wow! So this is a interface for make plugins, new in 4.0 [1] This is actually falling into the "everything is ELF" trap: We also need to provide an import stub lib to link with, so that the PE loader knows which module provides those symbols when they are loaded. (I'd have thought the implib would be named make.exe.a, but the documentation explicitly mentions libgnumake-version.dll.a. Including the version in the implib seems pointless and is going to cause issues if it ever changes, though) Not that there's any evidence anyone actually uses this, but Cc-ing Marco as make maintainer, for information. [1] https://www.gnu.org/software/make/manual/make.html#Loading-Objects Given that it seems intended that the plugin is built as part of the build, I'd speculate that you are saved from soversioning issues by the plugin getting rebuilt when the header changes, but this package is clearly a special case. What might be more of a problem is something like file, which does provide a DLL for other packages to link against, and which isn't separated out into a "lib*" package.[1] [1]: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Ffile%2Ffile-5.41-2=usr%2Fbin%2F.%2A%5C.dll (But maybe there's something about file that means we can be confident it'll never have an soversion change? Almost all my practical I don't know. But that might well be true, if upstream has given it soversion 1 "just in case we ever need to make incompatible changes". So, technically this is wrong, or perhaps just not ideal. Hopefully we'd notice if the soversion changes and evolve the packaging appropriately. At this stage, someone should probably look into the history of this package, and to see if that solib is used by anything other than the python bindings provided by the same package, and how file is packaged by other distros, just to evaluate our risk here. experience with wrangling library linking is with software appliances that ignore the issue by replacing all the binaries in an effectively- atomic operation, so I am well out of my areas of expertise here!) I guess it would be nice if cypgort had some sort of check that you were putting a solib with a version into an unversioned package name, but that might be hard to write reliably...
Re: [ITP] libinih
On 11/01/2023 23:16, Adam Dinwoodie via Cygwin-apps wrote: On Wed 11 Jan 2023 at 03:14:20PM +, Jon Turney wrote: On 09/01/2023 16:32, Adam Dinwoodie via Cygwin-apps wrote: As requested at [0], I've offered to package libinih for Cygwin. It has a BSD license[1] and is already packaged for a bunch of *nix distros, including Fedora, Debian and Arch[2]. [...] This looks good, except... I'd ask you to split this into libinih0 and libinih-devel packages. [...] Makes sense! Here's a rebuild: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc2 Thanks. I added this to your packages. NAME=libinih Since the upstream name is just 'inih', the source package should probably be named that also. libinih0_CONTENTS="\ usr/bin/*.dll\ usr/share/\ " You probably want to write this glob as '*-0.dll', so that when the soversion changes, packaging fails, rather than silently ploughing on to contain a libinit0 containing cyginit-1.dll... (Or factor out the soversion as variable, or something...)
Re: Version string of package
On Fri, 13 Jan 2023 13:22:44 + Jon Turney wrote: > On 13/01/2023 11:52, Takashi Yano via Cygwin-apps wrote: > > Hi, > > > > Is it allowed to include '-' in version string (e.g. '20230113-stable')? > > I'm asking because mksetupini warns: > > > > mksetupini: file 'xxx.tar.xz' in package yyy contains '-' in version > > > > though it works as expected. > > Short answer: > > It's a bug that this isn't a fatal error. Please don't do it! > > Long answer: > > Package naming in Cygwin has a long and tangled history. This isn't > explicitly precluded by the rules at [1], but probably should be. > > (Fedora, which we generally follow for packaging rules, now doesn't > allow '-' in versions, just digits, letters and '.') > > We need to be able to unambiguously separate a NVR string into the > package name, version and release. > > Underscores are allowed in package names, so the simple approach of > splitting on the rightmost two hyphens would work, if we don't allow > exceptions like this. > > (We can get it right in this case, because we have a piece of extra > information: the directory the package is in, which happens to always be > named N in the current scheme of things, but we might want to change that) > > [1] https://cygwin.com/packaging-package-files.html > > > In any case, you should be suspicious of using upstream version names of > this form. They may expect the 'stable' string to sort against other > strings based on meaning, rather than alphabetically (e.g. > '20230113-testing' is considered greater, which is probably not what's > wanted) Thanks for the answer. I'll use version 20230113 with release 1.g e.g. package-name-20230113-1.g123456789abc like cygwin test package. -- Takashi Yano
Re: newlib-cygwin.git repository: Switching "master" to "main"
On 13/01/2023 11:55, Corinna Vinschen via Cygwin wrote: > Hey folks, > > In the light of recent discussions, and following other projects already > having done this step, we changed the name of the "master" branch in > the newlib-cygwin.git upstream repository to "main". > > If you fetched from upstream in the last two days, you might already > have noticed that an "origin/main" branch suddenly showed up, but your > "master" branch still worked as before. > > The reason is that we also added a symbolic reference upstream, so that > "origin/master" points to "origin/main". Both "branches" are now > constantly kept in sync upstream. > > Therefore, you can continue your work on "master" without disruption, > if you prefer to do so. > > However, on the client side, the "master" and "main" branches are > treated as two distinct branches. If you work on your local "main" > clone and commit a patch, it's not keeping your local "master" branch in > sync. After pushing your change upstream, though, the upstream idea of > "main" and "master" is, again, the same. After fetching from upstream, > the patch will show up in both tracking branches, "origin/main" as well > as "origin/master", so pulling on both local branches will show the same > tree. > > Having said that. Ideally you only use one of the branches locally > to avoid any confusion: > > - If you prefer to work in "master", just continue to do so and don't > create a local "main" branch tracking "origin/main". > > - If you prefer to work in "main", checkout "origin/main" as "main" and > delete your local "master" branch. > > > Have fun, > Corinna > > While I can understand sensitivity over the word 'slave' this is taking things too far in my opinion. I just conducted a quick poll of my Afro-Caribbean & other non-Caucasian workmates who all express the same sentiment. There is only one use case that relates to slavery. There are dozens that do not. Are we supposed to stop using all of them? The git usage is not to do with master/slave relationship anyway. See https://www.merriam-webster.com/dictionary/master, for example:- * "In Casablanca, I am the master of my own fate." * "She is a master carpenter." * "He is a master of the violin." * "The professor is the master of the college." * "The maid has a master key to all the hotel rooms." People are enduring slavery all over the world right now - here in the UK & USA as well as elsewhere. Not using the words does not stop it happening. Well, it's a fait accompli on the Cygwin repos. -- Sam Edge -- 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: Version string of package
On 13/01/2023 11:52, Takashi Yano via Cygwin-apps wrote: Hi, Is it allowed to include '-' in version string (e.g. '20230113-stable')? I'm asking because mksetupini warns: mksetupini: file 'xxx.tar.xz' in package yyy contains '-' in version though it works as expected. Short answer: It's a bug that this isn't a fatal error. Please don't do it! Long answer: Package naming in Cygwin has a long and tangled history. This isn't explicitly precluded by the rules at [1], but probably should be. (Fedora, which we generally follow for packaging rules, now doesn't allow '-' in versions, just digits, letters and '.') We need to be able to unambiguously separate a NVR string into the package name, version and release. Underscores are allowed in package names, so the simple approach of splitting on the rightmost two hyphens would work, if we don't allow exceptions like this. (We can get it right in this case, because we have a piece of extra information: the directory the package is in, which happens to always be named N in the current scheme of things, but we might want to change that) [1] https://cygwin.com/packaging-package-files.html In any case, you should be suspicious of using upstream version names of this form. They may expect the 'stable' string to sort against other strings based on meaning, rather than alphabetically (e.g. '20230113-testing' is considered greater, which is probably not what's wanted)
Re: newlib-cygwin.git repository: Switching "master" to "main"
On Jan 13 12:55, Corinna Vinschen wrote: > Hey folks, > > In the light of recent discussions, and following other projects already > having done this step, we changed the name of the "master" branch in > the newlib-cygwin.git upstream repository to "main". > > If you fetched from upstream in the last two days, you might already > have noticed that an "origin/main" branch suddenly showed up, but your > "master" branch still worked as before. > > The reason is that we also added a symbolic reference upstream, so that > "origin/master" points to "origin/main". Both "branches" are now > constantly kept in sync upstream. > > Therefore, you can continue your work on "master" without disruption, > if you prefer to do so. > > However, on the client side, the "master" and "main" branches are > treated as two distinct branches. If you work on your local "main" > clone and commit a patch, it's not keeping your local "master" branch in > sync. After pushing your change upstream, though, the upstream idea of > "main" and "master" is, again, the same. After fetching from upstream, > the patch will show up in both tracking branches, "origin/main" as well > as "origin/master", so pulling on both local branches will show the same > tree. > > Having said that. Ideally you only use one of the branches locally > to avoid any confusion: > > - If you prefer to work in "master", just continue to do so and don't > create a local "main" branch tracking "origin/main". > > - If you prefer to work in "main", checkout "origin/main" as "main" and > delete your local "master" branch. Oh, and, btw., if you clone the newlib-cygwin.git repo anew, you will by default get a local "main" branch tracking "origin/main". Corinna -- 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
newlib-cygwin.git repository: Switching "master" to "main"
Hey folks, In the light of recent discussions, and following other projects already having done this step, we changed the name of the "master" branch in the newlib-cygwin.git upstream repository to "main". If you fetched from upstream in the last two days, you might already have noticed that an "origin/main" branch suddenly showed up, but your "master" branch still worked as before. The reason is that we also added a symbolic reference upstream, so that "origin/master" points to "origin/main". Both "branches" are now constantly kept in sync upstream. Therefore, you can continue your work on "master" without disruption, if you prefer to do so. However, on the client side, the "master" and "main" branches are treated as two distinct branches. If you work on your local "main" clone and commit a patch, it's not keeping your local "master" branch in sync. After pushing your change upstream, though, the upstream idea of "main" and "master" is, again, the same. After fetching from upstream, the patch will show up in both tracking branches, "origin/main" as well as "origin/master", so pulling on both local branches will show the same tree. Having said that. Ideally you only use one of the branches locally to avoid any confusion: - If you prefer to work in "master", just continue to do so and don't create a local "main" branch tracking "origin/main". - If you prefer to work in "main", checkout "origin/main" as "main" and delete your local "master" branch. Have fun, Corinna -- 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
Version string of package
Hi, Is it allowed to include '-' in version string (e.g. '20230113-stable')? I'm asking because mksetupini warns: mksetupini: file 'xxx.tar.xz' in package yyy contains '-' in version though it works as expected. -- Takashi Yano
[ANNOUNCEMENT] rebase 4.6.2-2
The following packages have been uploaded to the Cygwin distribution: * rebase-4.6.2-2 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. This is a minor bug fix release, fixing a confusing warning in peflags. -- 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
rebase 4.6.2-2
The following packages have been uploaded to the Cygwin distribution: * rebase-4.6.2-2 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. This is a minor bug fix release, fixing a confusing warning in peflags.
[ANNOUNCEMENT] cpio 2.13-13
The following packages have been uploaded to the Cygwin distribution: * cpio-2.13-13 GNU cpio copies files into or out of a cpio or tar archive. Archives are files which contain a collection of other files plus information about them, such as their file name, owner, timestamps, and access permissions. The archive can be another file on the disk, a magnetic tape, or a pipe. GNU cpio supports the following archive formats: binary, old ASCII, new ASCII, crc, HPUX binary, HPUX old ASCII, old tar and POSIX.1 tar. By default, cpio creates binary format archives, so that they are compatible with older cpio programs. When it is extracting files from archives, cpio automatically recognizes which kind of archive it is reading and can read archives created on machines with a different byte-order. Install cpio if you need a program to manage file archives. -- 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
cpio 2.13-13
The following packages have been uploaded to the Cygwin distribution: * cpio-2.13-13 GNU cpio copies files into or out of a cpio or tar archive. Archives are files which contain a collection of other files plus information about them, such as their file name, owner, timestamps, and access permissions. The archive can be another file on the disk, a magnetic tape, or a pipe. GNU cpio supports the following archive formats: binary, old ASCII, new ASCII, crc, HPUX binary, HPUX old ASCII, old tar and POSIX.1 tar. By default, cpio creates binary format archives, so that they are compatible with older cpio programs. When it is extracting files from archives, cpio automatically recognizes which kind of archive it is reading and can read archives created on machines with a different byte-order. Install cpio if you need a program to manage file archives.
