Re: Unable to 'git push' to /git/cygwin-packages/*
On 3/14/2024 11:26 AM, Corinna Vinschen via Cygwin-apps wrote: [...] You may also want to use https:// rather than git:// for reading the repository these days, given the insecurity of the git protocol. Right. I now remember this recommendation too. I will make the change in all the git configs for my projects. Thanks much, ..mark
Re: Unable to 'git push' to /git/cygwin-packages/*
On 3/14/2024 9:07 AM, Jon Turney via Cygwin-apps wrote:
On 14/03/2024 15:39, Mark Geisert via Cygwin-apps wrote:
On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote:
On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:
Hi folks,
I'm getting the error:
fatal: remote error: service not enabled: /git/cygwin-packages/sshfs
when I attempt 'git push' to that repository. The same happens with
all the repositories for my packages. It's been this way for a
couple days at least.
Have I forgotten some step in the connection at my end? I'm running
ssh-agent.
[...]
What is the repository URL you are trying to push to (git remote -v)?
/usr/src/upstaging/sshfs git remote -v
origin git://cygwin.com/git/cygwin-packages/sshfs (fetch)
origin git://cygwin.com/git/cygwin-packages/sshfs (push)
This maybe looks like pilot error.
We don't allow pushing using the git:// protocol (since this protocol
doesn't do any authorization, pushes with a it are very rarely enabled)
I suggest you need to do
git push
ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs
to push successfully.
If that works, I suggest you memorialize that by doing
git remote set-url origin --push
ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs
which will cause git to automatically use the ssh URL with a simple 'git
push'.
With a minor correction ("/git" instead of "git" in the URL) this works
fine. I've made the git config change for all my projects.
You might like to review the last time we discussed this at [1]
(Note that's slightly different, as to push to cygwin-apps repositories
you must present the key as
yourusername-rdbxbdvo6bxqt0dzr+a...@public.gmane.org, whereas for
cygwin-packages repositories, you can present the key as
cygwin-rdbxbdvo6bwxj1p+fo2...@public.gmane.org There are just different
due to historical reasons.)
[1] https://cygwin.com/pipermail/cygwin-apps/2021-September/041539.html
Thanks very much, Jon.
..mark
Re: Unable to 'git push' to /git/cygwin-packages/*
On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote: On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote: Hi folks, I'm getting the error: fatal: remote error: service not enabled: /git/cygwin-packages/sshfs when I attempt 'git push' to that repository. The same happens with all the repositories for my packages. It's been this way for a couple days at least. Have I forgotten some step in the connection at my end? I'm running ssh-agent. This is probably due to some recent changes made on sourceware. Apologies for the inconvenience. What is the repository URL you are trying to push to (git remote -v)? /usr/src/upstaging/sshfs git remote -v origin git://cygwin.com/git/cygwin-packages/sshfs (fetch) origin git://cygwin.com/git/cygwin-packages/sshfs (push) and likewise for packages cygfuse, util-linux, inkscape. Thanks much, Jon! ..mark
Unable to 'git push' to /git/cygwin-packages/*
Hi folks, I'm getting the error: fatal: remote error: service not enabled: /git/cygwin-packages/sshfs when I attempt 'git push' to that repository. The same happens with all the repositories for my packages. It's been this way for a couple days at least. Have I forgotten some step in the connection at my end? I'm running ssh-agent. Thanks for any advice, ..mark
Request for import of git repository history
Hi folks, I'm finally getting around to setting up the centralized git repositories for the packages I maintain. There is currently no history for the cygutils package. Could I please have its history imported with ctm2git? Thanks much, ..mark
Re: [NMU] inkscape 0.92.3-2 (Test)
This test version of inkscape has been promoted to current. Apologies to JonT who probably has to help this through again. Next time I do this will be after I ITA the thing. Thanks & Regards, ..mark
Re: Unmaintained packages in base package set
Marco Atzeri via Cygwin-apps wrote: Is anyone looking at QT5 and QT6 ? I've "looked at" Qt5 in the past, though not to the point of being able to take it over. I have a patch for the qterminal issue that I'd like to contribute. There's issues I've had building this I haven't had the time to resolve or even ask about. Not sure I've tried since Achim last did some work on it. I haven't looked at Qt6 at all. Marco, if you've got an itch to see either/both of these through, be my guest as far as I'm concerned. Meanwhile, I'm looking over the Unmaintained list too with some interest. Regards, ..mark
Re: [NMU] inkscape 0.92.3-2 (Test)
ASSI via Cygwin-apps wrote: Mark Geisert via Cygwin-apps writes: I've uploaded a non-maintainer re-build of the existing inkscape 0.92.3. This attempts to work around a problem with the current inkscape reported to exit with 127 error code (missing DLL). This build was produced with gcc-g++ 7.4 while the current build was produced with gcc-g++ 6.4. Newer gcc-g++ releases fail to build inkscape due to C++ include file evolution. Since apparently you can compile it with that compiler on an otherwise current release of Cygwin (I assume), you should be able to request a previous C++ or G++ standard version and have the current compiler do the same? The baseline for gcc-6 until gcc-10 has been C++14 and gcc-11 switched to C++17. You should also check that the compiler is detected correctly, there are some configure scripts that fail to take higher version numbers (esp. double digits for the main gcc version) correctly into account and then set bogus options. Inkscape shouldn't have been using C++11 until 0.93, so the appropriate standard to invoke is probably C++98 (or thew GNU variant thereof). Thanks much, Achim, for pointing out that additional dimension. That should help with my future builds and/or ITA. ..mark
Re: [NMU] inkscape 0.92.3-2 (Test)
Hi Jon,
Jon Turney via Cygwin-apps wrote:
On 30/11/2023 00:38, Mark Geisert via Cygwin-apps wrote:
Not sure of the logistical process for doing a non-maintainer update. If I've
missed something please let me know.
>
Thanks very much for looking into this.
You're welcome. It was a curious report on the main list and I got hooked.
So, this is all a bit ad-hoc at the moment, but only certain ("trusted")
maintainers are currently allowed to do NMUs.
Oops.
If you have ideas about how to make things work better, I'm all ears.
For the moment, I tweaked things to let your upload through.
Thanks Jon. I have only seen a handful of NMUs go by and it didn't occur to me
that those doing them were explicitly allowed to.
ISTM the process works fine as it is. If I happen to have a future itch to do an
NMU should I handle it as I did this one? Or say something on cygwin-apps
beforehand? I don't expect it will be often. I'm totally fine not being on the
"trusted" list for this type of thing.
Thanks,
..mark
[NMU] inkscape 0.92.3-2 (Test)
I've uploaded a non-maintainer re-build of the existing inkscape 0.92.3. This attempts to work around a problem with the current inkscape reported to exit with 127 error code (missing DLL). This build was produced with gcc-g++ 7.4 while the current build was produced with gcc-g++ 6.4. Newer gcc-g++ releases fail to build inkscape due to C++ include file evolution. The only changes in this test build were to the cygport file: - include python3 rather than 'python' - supply a BUILD_REQUIRES containing most if not all requirements Not sure of the logistical process for doing a non-maintainer update. If I've missed something please let me know. I might consider doing an ITA if I have luck with this... we'll see. Thanks, ..mark
Kindly update my SSH public key
Name: Mark Geisert BEGIN SSH2 PUBLIC KEY Comment: "256-bit ED25519, converted by Mark@zotac from OpenSSH" C3NzaC1lZDI1NTE5IP1ks1stdrx1ofmpCBnQWdJ2zt9qlnNqrCX0y15INZHf END SSH2 PUBLIC KEY
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Corinna Vinschen via Cygwin-apps wrote: On Sep 1 03:28, Mark Geisert via Cygwin-apps wrote: I then tried recompiling a CPU affinity test program of mine (that uses cpusets) but it could not link due to missing __cpuset_alloc and __cpuset_free. I think this is likely a local issue of mine in copying newly-built stuff into place, though I've automated that process and do it frequently, so... ? You missed to copy libcygwin.a to /usr/lib. That's what I thought at first as well. However nm showed the __cpuset_* functions present in the newly-created libcygwin.a. Did I mis-copy the new lib somewhere incorrect? Nope. It turned out I had stale files in /usr/x86_64-pc-cygwin/lib that's evidently earlier in the link search path than the directory with newest contents. I just renamed that directory out of the way and now the test program links and runs without issues. I should investigate what populated that directory though. I saw that you've applied your two patches. Excellent! ..mark
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Hi Corinna,
Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 20:10, Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 12:04, Brian Inglis via Cygwin-apps wrote:
On 2023-08-30 06:17, Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
-{
- (void) memset (set, 0, siz);
-}
+void __cpuset_zero_s (size_t, cpu_set_t *);
[...]
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+ (void) memset (set, 0, siz);
+}
+
} /* extern C */
Also, we can avoid an external __cpuset_zero_s function by just using a
loop, kind of like this:
I attached a matching patch. Please give it a try.
Shouldn't cpuset.h #include for size_t and for pid_t?
It shouldn't need that. sys/cpuset.h is a non-standard header which is
only included indirectly via sys/types.h.
We may want to change from size_t to __size_t and from pid_t to __pid_t.
That should eliminate any further dependency.
Try this:
After applying both patches to my system I was able to build coreutils without
issues. After updating my local Cygwin tree's sched.cc and cygwin.din I rebuilt
the Cygwin DLL without issues.
I then tried recompiling a CPU affinity test program of mine (that uses cpusets)
but it could not link due to missing __cpuset_alloc and __cpuset_free. I think
this is likely a local issue of mine in copying newly-built stuff into place,
though I've automated that process and do it frequently, so... ?
I believe those two patches you wrote are fine. Ship when convenient, I say.
Cheers & Regards,
..mark
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
-{
- (void) memset (set, 0, siz);
-}
+void __cpuset_zero_s (size_t, cpu_set_t *);
[...]
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+ (void) memset (set, 0, siz);
+}
+
} /* extern C */
Also, we can avoid an external __cpuset_zero_s function by just using a
loop, kind of like this:
I attached a matching patch. Please give it a try.
I like where this discussion is going. Going to need another day to test..
..mark
Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
[redirected from the main Cygwin ML] Hi Corinna, Corinna Vinschen via Cygwin wrote: On Aug 25 22:50, Mark Geisert via Cygwin wrote: Hi Corinna, Corinna Vinschen via Cygwin wrote: On Aug 24 14:39, Mark Geisert via Cygwin wrote: Denis Excoffier via Cygwin wrote: Hello, When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following error messages (see below). There seems to be a kind of loop in the hierarchy of #includes. It is not a loop. Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i removethe 2 #includes from /usr/include/sys/cpuset.h, this is also ok. This is an important clue. Regards, Denis Excoffier. [...compilation log excerpt elided here...] Usually it's easily fixable. There's typically no loop because of the guards, e.g. #ifndef _SYS_CPUSET_H_ #define _SYS_CPUSET_H_ but some guarding can have side effects. However, somebody needs to come up *at least* with a simple reproducer. It can be reproduced by running 'cygport coreutils.cygport build' in a prep'd coreutils source directory e.g. /usr/src/coreutils-9.0-1.src . Excerpt follows: This is not what I meant. A simple reproducer is ideally a piece of C code which shows ;the problem with a minimum of code. In this case, a pice of C code with the #includes required to reproduce the compiler failing is what I'm looking for. I've always been supportive of the notion of STCs, but for this issue it would mean duplicating a bunch of coreutils-build-built include files (in its lib directory) and I decided, why not just cut the coreutils build process back to the first compilation that exhibits the error? So I modified coreutils.cygport to change "cygmake" to "cygmake --trace" and ran 'cygport build' to see all gcc commands as they're executed. I then extracted the gcc command that compiles chroot.c to a new STC shell script where I could modify gcc options at will. I changed "-c" to "-E" to see the sequence of include file usage and where #defines actually happen. From this I discovered that pthread_attr_t and pthread_t defs are missing because sys/_pthreadtypes.h includes sys/cpuset.h which starts a whole include chain ending up in sys/signal.h where the defs are needed. Note they are defined in sys/_pthreadtypes.h where we started, but haven't been seen yet because sys/cpuset.h has gone off on this detour. Similarly, the timestruc_t def is missing because sys/_pthreadtypes.h again starts an include chain that ends up in sys/stat.h where the def is needed. Note timestruc_t is defined in machine/types.h, which is included (by sys/types.h) after sys/_pthreadtypes.h, so the def hasn't been seen yet because of a similar detour. The fix I'm considering is to (1) move sys/_pthreadtypes.h's "#include sys/cpuset.h" to just before its final #endif, and (2) exchange the positions of "#include " and "#include " within sys/types.h. I could submit for review a patch to do these things. An alternative would be to somehow massage the coreutils build include-file-wrapping to accomplish the same end. I personally don't have the time or skills to figure that out. I hope this info is usable in one form or another. Regards, ..mark
Test failures from 'cygport python39.cygport test' etc
Hi Marco, I'm seeing test failures and hangs on the 'cygport test' step for both Python 3.9 and 3.8. 3.9 has 37 failures out of 423 tests, 3.8 has 39 failures out of 425 tests. Both releases have 3 tests hanging after as much as 20 minutes wait w/no cputime: test_asyncio, test_ssl, test_io. My procedure is to (with cygport) prep, build, test. Do I need to 'install' before 'test'? I believe I tried that but it made no difference. Is there a different procedure you use to test the Python builds? Thanks & Regards, ..mark
Concerning Python patch 3.6.12-socketmodule.patch -- ping Marco
Hi Marco, When I said "could you handle" I meant I would author the revised patch, test it locally, and pass it on to you to integrate into the Cygwin Python packages. Does that sound workable to you? Thank you, ..mark Forwarded Message Subject: Concerning Python patch 3.6.12-socketmodule.patch Date: Mon, 7 Nov 2022 23:07:02 -0800 From: Mark Geisert To: cygwin-apps@cygwin.com Hi Marco, Recently there's been a complaint about that patch on the Cygwin mailing list. The patch was meant to allow same-machine communication between Cygwin Python programs via an AF_UNIX socket. The patch works because both ends of the connection are Python programs that have the patch. The problem reported by the user is that when a Python program attempts to communicate with ssh-agent, the connection freezes. This is due to the above patch being applied only to the Python end (of course). Given that we need the patch for Python build tests, could you handle an environment variable setting to choose the behavior of the patch? In other words. a revised patch would consult an environment variable PYTHON_NET_DISABLE_CREDENTIALS to decide whether to do what the current patch does. I guess the pythonXX.cygport file would have to define that env var. Does that sound like a workable scheme to you? Thanks, ..mark
Concerning Python patch 3.6.12-socketmodule.patch
Hi Marco, Recently there's been a complaint about that patch on the Cygwin mailing list. The patch was meant to allow same-machine communication between Cygwin Python programs via an AF_UNIX socket. The patch works because both ends of the connection are Python programs that have the patch. The problem reported by the user is that when a Python program attempts to communicate with ssh-agent, the connection freezes. This is due to the above patch being applied only to the Python end (of course). Given that we need the patch for Python build tests, could you handle an environment variable setting to choose the behavior of the patch? In other words. a revised patch would consult an environment variable PYTHON_NET_DISABLE_CREDENTIALS to decide whether to do what the current patch does. I guess the pythonXX.cygport file would have to define that env var. Does that sound like a workable scheme to you? Thanks, ..mark
Re: resolv.conf and gnupg2
Marco Atzeri wrote: Hi, currently as default Gnupg 2.x is unable to contact keyservers and recover any key. Gnupg 1.x has not such problem $ /usr/bin/gpg2 --keyserver pgp.mit.edu --recv-keys 5981E818 gpg: keyserver receive failed: No such file or directory The cryptic message is due to the absence of a /etc/resolv.conf as adding a simple one with a public DNS server overcomes the issue $ cat /etc/resolv.conf ; /etc/resolv.conf file for dnsmaster ; domain .com nameserver 0.0.0.0 nameserver 8.8.8.8 $ /usr/bin/gpg2 --keyserver pgp.mit.edu --recv-keys 5981E818 gpg: key D17BF2305981E818: 1 duplicate signature removed gpg: key D17BF2305981E818: "Andrew Makhorin " not chan gpg: Total number processed: 1 gpg: unchanged: 1 I would expect BIND to be a package that creates/manages resolv.conf as it provides a library to parser it, but I do not see any place where this is done. $ cygcheck -p resolv.conf Found 7 matches for resolv.conf .. libirs161-9.11.9-1 - libirs161: BIND resolv.conf parser library man-pages-linux-5.13-1 - man-pages-linux: Linux manual pages Any suggestion on how to solve the absence of /etc/resolv.conf ? I doubt gnupg2 is the proper package to do so. Could Cygwin itself provide a minimal /etc/resolv.conf pointing to public DNS server(s)? Some users might object to Google's public DNS (e.g. 8.8.8.8) though. Or perhaps a new package 'resolv.conf' with either the public DNS pointers or a postinstall script that massages the system's 'ipconfig /all' to obtain Windows' current settings. ..mark
Re: fuse
Hi Jon, Achim, Jon Turney wrote: On 01/02/2022 06:20, ASSI wrote: Mark Geisert writes: I see that 'mtr' is another Cygwin package that makes use of a Windows driver via libpcap. Maybe I can use mtr.cygport etc as a guide; I'm unsure whether a Cygwin package should be including Windows drivers. No they should not, although there is at least one other package (libusb IIRC) that requires non-standard Windows drivers for functioning fully or correctly. How to present that requirement in setup is another question. The 'message:' line in the .hint file (see [1]) can be used for a related purpose of telling people that Windows drivers are needed, although in fact this is only used by libusb0 at the moment. Actually checking for those being installed generically in setup seems fraught. But I guess you could write a postinstall script which checks somehow for it's presence and fails if it's not present? [1] https://cygwin.com/packaging-hint-files.html I had seen "message:" there on [1] and tried once to make use of it, but failed. From reading cygport's pkg_pkg.cygpart, it seemed to me that a 'MESSAGE="foo"' line in the cygfuse.cygport file should cause a 'message: cygfuse "foo"' to be emitted to the .hint file. That didn't seem to happen. Maybe I goofed. I then thought about manually adding the "message: ..." line, but then realized I had two full 75-char lines of info to display and did not know if that was too big or what it would look like. I dropped the idea for the time being and went with an Overview section on the package update announcement instead. I should look at libusb.cygport; thanks Achim for that reminder. Regards, ..mark
Re: [ITP] cygfuse -- cygport issues solved
Mark Geisert wrote: Hi Jon, Thanks for the helpful review comments. cygport is a wondrous tool. My issues were solved by making a simple tar.xz of my local source tree, renaming it to have the version number expected by the cygport script, placing that file and the cygport script in a test directory, then running 'cygport cygfuse.cygport prep'. All the necessary subdirectories are then built and the build, install, package steps run correctly. Next is upload and announce. I was making things more complicated than they needed to be. cygport is a wondrous tool. Thanks Yaakov! ..mark
Re: [ITP] cygfuse
Hi Jon,
Thanks for the helpful review comments. More below.
Jon Turney wrote:
On 10/03/2022 06:16, Mark Geisert wrote:
[...]> A few small comments on the cygport file
HOMEPAGE="https://github.com/mgeisert/cygfuse;
#SRC_URI="http://maxrnd.com/~mark/cygwin/x86_64/release/cygfuse/cygfuse-${PV}.tar.xz;
#NOT YET: GIT_URI="https://github.com/mgeisert/cygfuse.git;
#NOT YET: GIT_TAG="v$VERSION"
#NOT YET: inherit git
It's unclear where the upstream source tarball comes from...
Things were in flux and are now straightened out. There's just a SRC_URI now.
# take over these activities from cygport..
_CYGPORT_RESTRICT_strip_=1
This should be written 'RESTRICT=strip', I think.
Yep, thanks.
src_compile()
{
# fix source tree glitch.. (maybe 'prep' stumbling or bad tarfile layout?)
if [ -e ${S}/src ]; then
mv ${S}/src/cygfuse ${S}
rmdir ${S}/src
fi
I think this can be handled with 'SRC_DIR=src/cygfuse' (and suitable adjustment to
paths throughout)
I had tried several variations on this before the initial ITP post. I tried again
after your comment. I'm still having issues with source layout.
I think my trouble is I'm bootstrapping my own source tree and there seem to be
conventions (that I don't know) on how it should be laid out. It seems the source
tarball generated by cygport doesn't match the layout of my own source tree.
Should my original source be in directory "src" or "src/cygfuse"? If the latter,
should there be a version number as part of the directory name? Should my original
source be placed under "origsrc" or "src"? These questions pertain to layout
before cygport is run to generate the first-ever package tarballs.
Currently the build, install, package steps seem to run to completion. But doing
a fetch and prep of the tarball has got me stymied (in the prep step). Error is
SRC_DIR is not correctly defined
I have been perusing /usr/share/cygport/*.cygpart but haven't found a solution.
Thanks,
..mark
Re: [ITP] sshfs
Marco Atzeri wrote: On 10.03.2022 08:22, Mark Geisert wrote: This is a Cygwin port of the FUSE app sshfs that can be found in various Linux [...] added to cygwin-pkg-maint list Thanks Marco for both adds. Cheers, ..mark
[ITP] sshfs
This is a Cygwin port of the FUSE app sshfs that can be found in various Linux distributions. It allows mounting a remote directory via ssh onto a local directory. It requires cygfuse. sshfs is a subproject of the Linux-focused libfuse project. The initial project files for review are located at: http://maxrnd.com/~mark/cygwin/sshfs/sshfs.cygport http://maxrnd.com/~mark/cygwin/sshfs/sshfs-3.7.2-1-src.tar.xz Thanks for reading and for any feedback you might have, ..mark
[ITP] cygfuse
This is a Cygwin version of libfuse{,3} that can be found in various Linux
distributions. It is a couple of link libraries and additions to
/usr/include to allow porting of FUSE apps. FUSE: File System In User
Space. I will shortly be providing an sshfs FUSE app, to be covered by a
separate ITP.
Importantly, cygfuse depends on an underlying Windows FUSE implementation:
WinFSP. In fact the Cygwin library code was provided by the author of
WinFSP. I'm just providing a bona-fide Cygwin package for the code.
WinFSP, and thus cygfuse, is made available under GPLv3 for Free/Libre and
Open Source Software or under a commercial license.
If another Windows FUSE provider shows interest in supporting Cygwin, I
suspect it could be supported with alternatives(8).
The initial project files for review are located at:
http://maxrnd.com/~mark/cygwin/cygfuse/cygfuse.cygport
http://maxrnd.com/~mark/cygwin/cygfuse/cygfuse-3.2.0-1-src.tar.xz
http://maxrnd.com/~mark/cygwin/cygfuse/cygfuse-3.2.0-1.src.patch
Thanks for reading and for any feedback you might have,
..mark
Re: Go or Rust Packages?
Brian Inglis wrote: On 2022-02-02 02:44, Corinna Vinschen wrote: On Feb 1 21:22, Adam Dinwoodie wrote: The upstream fzf package moved from Ruby to Go some time ago. I had vague but noble intetions to try to maintain a fork on the basis of the last version of the Ruby code, but never managed anything useful. In that context, I expect it's time that I officially throw in the towel, and mark fzf as orphaned. The existing build still works, and I don't think there's likely to be any crass security problems or anything like that. But there's no longer any upstream support, and I clearly don't have the capacity to properly maintain it solo. I'm not quite sure what the process is here, but I suspect it's just a case of someone with the appropriate access making an update to https://cygwin.com/cygwin-pkg-maint Anyone know of anyone trying to build Go or Rust on Cygwin? I made some progress with Go on Cygwin a couple years ago, but had to give up because it required more time than I could give it. I got about 1/3 of the way through it. The last straw was its need for syscall?() and Cygwin not having those functions (or a need for them). It was a lot of looking for "#ifdef Windows" and usually adding "&& !defined(__CYGWIN__)". The goal still tantalizes though... I don't think anybody has mentioned a need for Rust on Cygwin before. That might be easier because of a simpler runtime than Go, but still a major, major project. ..mark
Re: fuse
One final reply to myself on this topic.. Thomas Wolff wrote: What became of the winfsp-fuse project discussed in July 2016? I'd like to be able to use ftpfs or sshfs in cygwin. Integration of the project into Cygwin stalled around that time, or was it 2018? [...] I've now looked at and installed the most recent WinFSP. The Cygwin glue layer works as well as it always had. But something is missing: integration with the usual shell file manipulation commands. For example, one can't 'cd' into the directory on which a foreign file system has been loaded. That seems like a major issue unless I'm misunderstanding things. This turned out to be an issue in Cygwin 3.3.3 but not 3.3.4 or the upcoming 3.4.0. WinFSP is ready to be used from Cygwin. I plan to rename it FUSE for the upcoming ITP, to avoid name conflict with libfuse* common on Linux. Nah, there will be two upcoming ITPs, cygfuse and sshfs. The first will provide the glue layers (libfuse and libfuse3) that ride on top of WinFSP, and also a 'fusermount' command. The second ITP will be a port of the latest sshfs reference implementation to Cygwin. sshfs is known to clean-compile against the glue layer already. ..mark
Re: fuse
Replying to myself... Mark Geisert wrote: Hi Thomas, Thomas Wolff wrote: What became of the winfsp-fuse project discussed in July 2016? I'd like to be able to use ftpfs or sshfs in cygwin. Integration of the project into Cygwin stalled around that time, or was it 2018? [...] I would love to have somebody interested in trying out FUSE on Cygwin. If you require a cygfuse package I guess the first step for that would be for me to reissue the ITP and make the package real. Another alternative would be for you to build from the Github repo https://github.com/mgeisert/cygfuse if you're feeling adventurous. Our fuse package as it stands is not ready for use. When I last looked at it years ago I was too new to both FUSE and project porting to understand what was missing. Currently it's a source package that supplies a glue layer for Cygwin apps to make use of WinFSP, a Windows FUSE driver. It also supplies source for a Cygwin sshfs app that demonstrates correct operation of WinFSP via Cygwin. I've now looked at and installed the most recent WinFSP. The Cygwin glue layer works as well as it always had. But something is missing: integration with the usual shell file manipulation commands. For example, one can't 'cd' into the directory on which a foreign file system has been loaded. That seems like a major issue unless I'm misunderstanding things. Let me reach out to the WinFSP folks and see if I'm doing something wrong or if there's additional work to be done on the Cygwin side. In any case the project needs some smartening up. I plan to rename it FUSE for the upcoming ITP, to avoid name conflict with libfuse* common on Linux. I see that 'mtr' is another Cygwin package that makes use of a Windows driver via libpcap. Maybe I can use mtr.cygport etc as a guide; I'm unsure whether a Cygwin package should be including Windows drivers. Thanks for reading; advice welcome, ..mark
Re: fuse
Hi Thomas, Thomas Wolff wrote: What became of the winfsp-fuse project discussed in July 2016? I'd like to be able to use ftpfs or sshfs in cygwin. Integration of the project into Cygwin stalled around that time, or was it 2018? ISTR there was an objection from the Dokany FUSE project about whether WinFSP FUSE should be the basis for Cygwin's implementation. I tried to mollify that by implementing a poor-man's plugin feature that would allow a user to select which underlying FUSE layer to use. I believe I was waiting for confirmation from Dokany that they could work with that plugin architecture. I think it was my ITP for libfuse that prompted the discussion with Dokany. In any case the ITP was never acted on and the project has since languished. WinFSP itself has been improved over time; I don't know if the improvements would require an update to the Cygwin portion. I would love to have somebody interested in trying out FUSE on Cygwin. If you require a cygfuse package I guess the first step for that would be for me to reissue the ITP and make the package real. Another alternative would be for you to build from the Github repo https://github.com/mgeisert/cygfuse if you're feeling adventurous. ..mark
Re: Unable to push to cygutils git repo on sourceware
Hi Jon, Jon Turney wrote: On 07/09/2021 04:46, Mark Geisert wrote: Something's likely changed in the 4 years since I last did this :-). ..or something allegedly similar to this... too much code under the bridge... $ git push fatal: remote error: service not enabled: /git/cygwin-cygutils.git $ cat .git/config [core] # blah elided [remote "origin"] url = git://sourceware.org/git/cygwin-cygutils.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [...] So, to answer the question actually asked: * While there have been some changes, this specific URL still works. (However, the published path nowadays is /git/cygwin-apps/cygutils.git) * We've never supported pushing using the git:// protocol (since this protocol doesn't do any authorization, pushes with a it are very rarely enabled) OK, makes sense. * So you perhaps explicitly did a "git push ssh://usern...@cygwin.com/git/cygwin-apps/cygutils.git" last time you pushed changes? That seems pretty likely in retrospect, or @sourceware.org, same IP address. * Since git supports configuring a separate push url, I'd suggest something like: git clone git://cygwin.com/git/cygwin-apps/cygutils.git git remote set-url origin --push ssh://usern...@cygwin.com/git/cygwin-apps/cygutils.git I find this convenient (especially when working with remote repositories to which other people will push changes), since it lets you pull without authenticating, but still push with appropriate authentication. I've amended https://sourceware.org/cygwin-apps/ to include that suggestion and hopefully clarify things. Thank you for the advice and for updating the web docs. I'll be trying the push again shortly and will respond with any issues. Regards, ..mark
Unable to push to cygutils git repo on sourceware
Something's likely changed in the 4 years since I last did this :-). $ git push fatal: remote error: service not enabled: /git/cygwin-cygutils.git $ cat .git/config [core] # blah elided [remote "origin"] url = git://sourceware.org/git/cygwin-cygutils.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master I tried cygwin.com in place of sourceware.org but no change. Have the repositories moved or the access policies changed? Thanks for any leads, ..mark
Is it possible to 'cygport upload' with same p-v-r?
HI all,B I'd like to re-spin the latest version of cygutils, that is, upload newer files with the same release number (1.4.16-5). Is this possible, or do we now always change the release# when uploading? Thanks, ..mark
Re: [PATCH] cygutils/cygdrop: fix return type of usageCore
Hi Jeremy, Jeremy Drake via Cygwin-apps wrote: Fixes a warning "no return statement in function returning non-void", and solves a crash running --help. Hopefully this is the right place for this now, since I am not interesting in becoming a package maintainer as the list description says ;) Thanks for the report and patch. I can't reproduce the crash but no worries. The patch will be part of the next update to cygutils in a short while. ..mark
Re: python > 3.5: Issue with unix domain sockets
Hi Marco, Marco Atzeri via Cygwin wrote: On 04.05.2021 06:41, Mark Geisert wrote: Ken Brown via Cygwin wrote: On 5/3/2021 8:57 AM, Maximilian.Blenk--- via Cygwin wrote: Incorrect Behavior: Server: $ python3.7 server.py starting up on ./uds_socket waiting for a connection Traceback (most recent call last): File "server.py", line 27, in connection, client_address = sock.accept() File "/usr/lib/python3.7/socket.py", line 214, in accept sock = socket(self.family, self.type, self.proto, fileno=fd) File "/usr/lib/python3.7/socket.py", line 151, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) SystemError: returned NULL without setting an error Client: $ python3.7 client.py connecting to ./uds_socket sending b'This is the message. It will be repeated.' closing socket Traceback (most recent call last): File "client.py", line 27, in data = sock.recv(16) ConnectionResetError: [Errno 104] Connection reset by peer I wonder if this has the same cause as the problem reported here: https://cygwin.com/pipermail/cygwin/2021-February/247884.html Mark, can you check that? Hmm, the correlation between failing Python versions and patch placements is troubling. I've reproduced the OP's findings and will dig further. ..mark 3.5 has not your patch for asyncio, as I am not updating it. all the others have it. It will be nice to solve this problem and avoid the freeze that your patch solved. It turns out a small adjustment to the existing patch fixes this latest issue and shouldn't affect the situations reported in the original bug report that provoked the patch in the first place. Line 11 of the patch 3.6.12-socketmodule.patch has: return -1; using dots to denote spaces because this mailer might deformat this email. If that patch line is replaced with: /* ignore error returns */; we have a patch that solves the latest issue as well as the original issue. That revised patch should also apply to 3.7 and 3.8 without problems. Thanks & Regards, ..mark
Re: binutils 2.36.1
Achim Gratz wrote: Before releasing binutils 2.35.2, I had already built 2.36 (which was released two days earlier), but it became almost immediately clear that there were problems. Now that 2.36.1 came out I tried again (not that the changes would indicate anything addressing those problems) and of course the problems are still there. With the new binutils installed, I get lots of fork problems on x86, but not exactly reproducible. Like these: --8<---cut here---start->8--- checking for working fork... 1 [main] conftest 7615 D:\Freeware\CygProShare\cygpkgs\mosh\mosh.x86\build\conftest.exe: *** fatal error in forked process - fork: can't reserve memory for parent stack 0x140 - 0x160, (child has 0x84 - 0xA4), Win32 error 487 74330 [main] conftest 7615 cygwin_exception::open_stackdumpfile: Dumping stack trace to conftest.exe.stackdump 1 [main] conftest 7614 dofork: child -1 - forked process 1224 died unexpectedly, retry 0, exit code 0x100, errno 11 no --8<---cut here---end--->8--- I have yet to find any mention of a change to binutils that would explain what is going on, so if anybody could have a look and generate an hypothesis that would be most helpful. You can use the cygport file and just change the version number (plus the name of the patch file to match the version). I have now built and installed x86 binutils 2.36.1 locally. I've been able to build the Cygwin DLL and mosh without issues. I suspect you might be right on the edge of running out of address space given your symptoms are erratically recurring and it's on x86. As a basis for comparison I've got 293 DLLs according to 'rebase -i *.dll|wc -l' in the /usr/bin directory. 'rebase -i *.dll | head' shows this: /usr/bin/tk86.dll base 0x59b8 size 0x0015e000 /usr/bin/libtk8.6.dll base 0x59ce size 0x00149000 /usr/bin/libtcl8.6.dllbase 0x59e3 size 0x001a8000 /usr/bin/libpython3.8.dll base 0x59fe size 0x002d6000 /usr/bin/libpython3.6m.dllbase 0x5a2c size 0x00279000 /usr/bin/libpython2.7.dll base 0x5a54 size 0x001cd000 /usr/bin/libexpect5.45.dllbase 0x5a71 size 0x00031000 /usr/bin/libbtparse.dll base 0x5a75 size 0x0002 /usr/bin/cygzzipwrap-0-13.dll base 0x5a77 size 0xb000 /usr/bin/cygzzipmmapped-0-13.dll base 0x5a78 size 0xc000 The output is sorted by base address. See where your lowest DLL is based; that should tell you if you'll need to prune some lesser-used packages to free up some DLL address space. ..mark
Re: Extreme slowdown due to malloc?
Hi Achim, Thank you very much for the detailed instructions and also the comparison data Linux vs Cygwin for all those testcases. Achim Gratz wrote: ASSI writes: I have a Cygwin malloc speedup patch that *might* help the m-t part. I'll prepare and submit that to cygwin-patches shortly. Well, if you want to test it with the new ZStandard, give it a spin… I'll check how far I can strip that test down so you can use the Cygwin source tree for testing. I've now done this. And I don't see any improvement. Reasons below... OK, it's actually pretty simple, do this inside a checkout of newlib-cygwin: $ find newlib winsup texinfo -type f > flist $ zstd --train-cover --ultra -22 -T0 -vv --filelist=flist -o dict-cover On Linux, it reads in all the files in about two seconds, while it takes quite a while longer on Cygwin. But the real bummer is that constructing the partial suffix arrays (which is single-threaded) will seemingly take forever, while it's done much faster on Linux. You can pare down the number of files like that: $ shuf -n 320 flist > slist I've settled on '-n 1600' for testing. I'm running these Cygwin tests on a 2C/4T i3-something with 8GB memory and an SSD used for filesystem and page file. Not a dog but clearly not a dire-wolf either. The page fault numbers are comparable to what you've shown for Cygwin on your system. The long pause after zstd prints "Constructing partial suffix array" is because zstd is cpu-bound in qsort() for a long time. No paging during that time. Then when the statistics start being printed out, that's when the paging insanity starts. What I discovered is that zstd is repeatedly asking malloc() for large memory blocks, presumably to mmap files in, then free()ing them. Any malloc request 256K or larger is fulfilled by mmap() rather than enlarging the heap for it. But crucially, there is no mechanism for our malloc to hang on to freed mmap()ed pages for future use. If you free an mmap()ed block, it is unmap()ed immediately. So for zstd's usage pattern you get an incredible number of page faults to satisfy the mmap()s and Windows seems to take a non-trivial bit of time for each mmap(). I will be looking at our malloc implementation to see if tuning something can fix this behavior. Adding code is the last resort. Thanks again for the great testcase. ..mark
Re: [ATTN MAINTAINER] qt5-base
Achim Gratz wrote: [some nifty stuff with puzzlers in it...] Unfortunately I can't help with the qt5 build questions. Been down that path and gotten lost. But if/when you have a package ready for test installation, I can shortly thereafter provide a patch to qt5-base that fixes the longstanding Cygwin-specific gnuplot vs qterminal issue. Upstream doesn't seem inclined to fix. Regards, ..mark
Re: python fails asyncio tests (py 3.7 & 3.8)
Hi Marco, On Mon, 28 Dec 2020, Marco Atzeri via Cygwin-apps wrote: On 17.12.2020 10:20, Mark Geisert wrote: Hi Marco, Below is the patch I developed to work around the problem report in https://cygwin.com/pipermail/cygwin/2020-November/246830.html I called the patch file 3.8.3-peercred-cygwin.patch. I am unable to test the patch myself because of continuing problems building a new Python. I don't know if my issues are due to being on latest Cygwin code vs 3.1.7, or gcc 10.2 vs 9.3, or what. Could you tell me what your build environment is like? I'll try to duplicate it. Test the patch by running a Python built with it on the example from the OP. Without the patch, the run would hang in the middle of the test script. With the patch, it should quickly complete with 4 unrelated errors mentioning MSG_OOB. Thanks & Regards, ..mark Hi Mark, is this the expected result ? test_connection_attributes (__main__.TestAPI_UseUnixSocketsPoll) ... ERROR /usr/lib/python3.8/unittest/case.py:704: ResourceWarning: unclosed type=SocketKind.SOCK_STREAM, proto=0> outcome.errors.clear() It does not freeze That's a new error to me; I haven't run that test. I could have been more specific in my test instructions. There are apparently two test series (which is also news to me). They are /usr/lib/python3.8/test and .../unittest. It seems you were in the latter? The script to run is in .../test. Here's how: cd /usr/lib/python3.8/test python3.8 test_asyncore.py -v Separately, I'm still wrestling with build issues. Just as a known-good alternative, how is your test environment set up? Is your cygwin1.dll from standard 3.1.7, or a snapshot, or do you build from git master? Are you using the latest binutils and gcc-g++ packages or something newer? Thanks for any info you can provide. I seem to be having issues with linking programs having many object files. Like any Python 3, or the Flint math library for examples. The link fails with a SIGSEGV or an assertion failure in cofflink.c. Nobody else has reported these. Thanks & Regards, ..mark
Re: Extreme slowdown due to malloc?
Hi Achim, Achim Gratz wrote: I've been experimenting a bit with ZStandard dictionaries. The dictionary builder is probably not the most optimized piece of software Is this what leads you to suspect malloc? Really heavy use of malloc? and if you feed it large amounts of data it needs quite a lot of cycles. So I thought I run some of this on Cygwin since that machine is faster and has more threads than my Linux box. Unfortunately that plan shattered due to extreme slowness of the first (single-threaded) part of the dictionary builder that sets up the partial suffix array. |--+---+---| | | E3-1225v3 | E3-1276v3 | | | 4C/4T | 4C/8T | | | 3.2/3.6GHz| 3.6/4.0GHz| |--+---+---| | 100 | 00:14 / 55s | 00:23 / 126s | | 200 | 00:39 / 145s | 01:10 / 241s | | 400 | 01:12 / 266s | 01:25 / 322s | | 800 | 02:06 / 466s | 11:12 / 1245s | | 1600 | 03:57 / 872s | > 2hr | | 3200 | 08:03 / 1756s | n/a | | 6400 | 16:17 / 3581s | n/a | |--+---+---| The obvious difference is that I/O takes a lot longer on Cygwin (roughly a minute for reading all the data) and that I have an insane amount of page faults on Windows (as reported by time) vs. none on Linux. How much RAM does the Windows machine have? Do you have a paging file? Is it fixed size or "let Windows manage"? How big is it? While doing that I also noticed that top shows the program taking 100% CPU in the multithreaded portion of the program, while it should show close to 800% at that time. I'm not sure if that information just isn't available on Windows or if procps-ng needs to look someplace else for that to be shown as expected. No offense, but are you sure it's actually running multi-threaded on Windows? I have a Cygwin malloc speedup patch that *might* help the m-t part. I'll prepare and submit that to cygwin-patches shortly. Cheers, ..mark
python fails asyncio tests (py 3.7 & 3.8)
Hi Marco,
Below is the patch I developed to work around the problem report in
https://cygwin.com/pipermail/cygwin/2020-November/246830.html
I called the patch file 3.8.3-peercred-cygwin.patch.
I am unable to test the patch myself because of continuing problems building a new
Python. I don't know if my issues are due to being on latest Cygwin code vs
3.1.7, or gcc 10.2 vs 9.3, or what. Could you tell me what your build environment
is like? I'll try to duplicate it.
Test the patch by running a Python built with it on the example from the OP.
Without the patch, the run would hang in the middle of the test script. With the
patch, it should quickly complete with 4 unrelated errors mentioning MSG_OOB.
Thanks & Regards,
..mark
--- origsrc/Python-3.8.3/Modules/socketmodule.c 2020-05-13
10:31:54.0-0700
+++ src/Python-3.8.3/Modules/socketmodule.c 2020-12-15
21:00:15.373059900-0800
@@ -1030,6 +1030,14 @@ init_sockobject(PySocketSockObject *s,
}
}
}
+#ifdef __CYGWIN__
+/* Temporarily work around AF_UNIX credential passing issues */
+if (s->sock_family == AF_UNIX && s->sock_fd != -1) {
+if (setsockopt(s->sock_fd, SOL_SOCKET, SO_PEERCRED, 0, 0) == -1) {
+return -1;
+}
+}
+#endif
return 0;
}
Re: Failure during build of Python 3.8 via cygport
Mark Geisert wrote: This seems to be a problem setting up a platform-specific build directory. The sysconfig.py script wants to use "lib." + platform + pythonversion but the platform string somehow gets corrupted into non-utf8 bytes. For instance, building Python 3.8 comes up with: lib.cygwin-\365\377\377o-\377o-3.8 as the directory name. Broken, but could work. The build failure happens because the script tries to write this directory name into a file but it's not a valid utf8 string. The directory name should have been: lib.cygwin-3.2.0-x86_64-3.8 And the corruption is due to something about a recent change to the operation of Cygwin's uname() function. The change was introduced in Cygwin API version 335; I'm running 340 on my test machine. This being a fairly recent change might possibly explain why nobody else has run into this issue yet. Basically, os.uname within Python is calling Cygwin's uname() passing the address of a buffer declared to be 'struct utsname'. The structure layout changed in API 335. What I've hit is a mismatch between what Python expects and Cygwin delivers. I'll move this discussion over to the developers list tomorrow. ..mark
Re: Failure during build of Python 3.8 via cygport
[replying to myself again...] A similar problem happens when building 3.6 and 3.7 too. Details at end. On Wed, 9 Dec 2020, Mark Geisert wrote: Hi Marco, I was building Python locally so I can later submit a patch against it. It appears the local python.exe was built successfully, but a later step failed with: ./python.exe -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Traceback (most recent call last): File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/runpy.py", line 194, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/runpy.py", line 87, in _run_code exec(code, run_globals) File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 711, in _main() File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 699, in _main _generate_posix_vars() File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 416, in _generate_posix_vars f.write(pybuilddir) UnicodeEncodeError: 'utf-8' codec can't encode characters in position 17-19: surrogates not allowed generate-posix-vars failed make: *** [Makefile:592: pybuilddir.txt] Error 1 *** ERROR: make failed I've seen UnicodeEncodeError before and searched and found how to fix it.. but hitting the issue while building Python itself seems more fraught. Is this a known issue with known fix? This seems to be a problem setting up a platform-specific build directory. The sysconfig.py script wants to use "lib." + platform + pythonversion but the platform string somehow gets corrupted into non-utf8 bytes. For instance, building Python 3.8 comes up with: lib.cygwin-\365\377\377o-\377o-3.8 as the directory name. Broken, but could work. The build failure happens because the script tries to write this directory name into a file but it's not a valid utf8 string. The directory name should have been: lib.cygwin-3.2.0-x86_64-3.8 I'm trying to debug further, learning Python as I go. Whee ..mark
Failure during build of Python 3.8 via cygport
Hi Marco, I was building Python locally so I can later submit a patch against it. It appears the local python.exe was built successfully, but a later step failed with: ./python.exe -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Traceback (most recent call last): File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/runpy.py", line 194, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/runpy.py", line 87, in _run_code exec(code, run_globals) File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 711, in _main() File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 699, in _main _generate_posix_vars() File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 416, in _generate_posix_vars f.write(pybuilddir) UnicodeEncodeError: 'utf-8' codec can't encode characters in position 17-19: surrogates not allowed generate-posix-vars failed make: *** [Makefile:592: pybuilddir.txt] Error 1 *** ERROR: make failed I've seen UnicodeEncodeError before and searched and found how to fix it.. but hitting the issue while building Python itself seems more fraught. Is this a known issue with known fix? Thank you, ..mark
ATWIL ?
Does it mean "All The World Is Linux" or something else? ..mark
Re: cygwinports domains
Yaakov Selkowitz wrote: My domain registrations cygwinports.com, cygwinports.net, and cygwinports.org will expire very soon. If anyone would like to adopt them for the Cygwin project, please let me know ASAP. Otherwise, I will let them lapse. Hi Yaakov, I'm willing to adopt them if only to keep them out of the hands of potential mischief-makers. Are you using the hosting facilities of the domain registrar? I've been using Joker for domain management for years, and have transferred domains from other registrars. Shouldn't be a big deal for these three. Let me know if this sounds OK. Either on this list or PM is OK. Cheers, ..mark
Re: zsh 5.8: configure fails only on 32bit
Yasuhiro KIMURA wrote:
Thank you for reply, and sorry for late response.
From: ASSI
Subject: Re: zsh 5.8: configure fails only on 32bit
Date: Sat, 13 Jun 2020 07:53:25 +0200
To me that indicates either BLODA interference or that you run into some
limit (e.g. on environment size or PATH length).
More generally I'd advise everyone to not build in your Windows user
directory (which Windows specially "protects" in various ways) and never
use any /cygdrive prefix while building packages (these are mounted with
posix=0 mount option by default). If you have the option, use a
separate SSD for all of Cygwin and create a separate mount point for the
build directory that mounts with "posix=1,binary". I haven't sprung for
full case sensitivity yet myself since that still entails mucking with
the registry more than I want to, but I've run into problems with that
once or twice (which I've worked around). Install Cygwin into a
directory two levels down the root (i.e D:\Freeware\Cygwin) in order to
not get "special" treatment from Windows. I have forgotten what the
exact problem was, but putting the Cygwin install directory directly
into the root triggered some BLODA several years ago. Also if you use
Cygwin for yourself on that same machine it is better to have a separate
user account for building (I use a dedicated build machine). Set
CYGWIN_NOWINPATH=1 in the system or user environment options of Windows
for the build user. Be aware that some packages need to build or tested
with admin rights enabled (that's a whole 'nother reason to not use your
main account, as these days it shouldn't have admin rights at all),
which I generally have since I build via ssh. Once in a while you'll
run into some test that fails until you aren't admin, in which case you
can use cygdrop. Lastly, once you need to build GUI applications you
might want to be able to RDC into your build box, which means it should
have at least the "Professional" variant of Windows installed.
I tried what you say with newly clean installed 64bit Windows 10 Pro
1909. But problem still happens.
From: Marco Atzeri via Cygwin-apps
Subject: Re: zsh 5.8: configure fails only on 32bit
Date: Sat, 13 Jun 2020 08:18:56 +0200
what cygwin version and terminal are you using ?
I saw a similar problem in the past
https://sourceware.org/pipermail/cygwin/2020-April/244363.html
https://sourceware.org/pipermail/cygwin-apps/2020-May/040107.html
and it went away with a recent cygwin
yasu@rolling[1070]% cygcheck -c cygwin mintty
Cygwin Package Information
Package VersionStatus
cygwin 3.1.5-1OK
mintty 3.2.0-1OK
yasu@rolling[1071]%
And after number of trials and errors I add following definition of src_compile
function to zsh.cygport.
--
src_compile() {
cd ${S}
cygautoreconf
cd ${B}
dash ${S}/configure --srcdir=${S} --prefix=$(__host_prefix)
--exec-prefix=$(__host_prefix) --localstatedir=$(__host_localstatedir)
--sysconfdir=$(__host_sysconfdir) --infodir=$(__host_prefix)/share/info
--mandir=$(__host_prefix)/share/man -C --enable-function-subdirs --enable-gdbm
--enable-multibyte --enable-pcre --enable-zsh-secure-free || error "configure
failed"
cygmake
}
--
This is same as default definition except that dash is used to
interpret configure script. And with it build succeeded on 32bit
Cygwin console. So It seems I hit bug of bash that only happens under
very limited conditions.
And I'm wondering if I should investigate the problem further or
accept adding the function definition as a workaround.
Not sure if your end result will be a patch to the Cygwin zsh package or an ITA
of same. In either case it seems like the Cygwin zsh maintainer (Peter A.
Castro) ought to be brought into this conversation...
..mark
"non-unique current versions" error from calm
I tried uploading my re-spin of util-linux (2.33.1-2) but received the following error report on both x86_64 and x86 uploads: ERROR: install packages from source package 'e2fsprogs' have non-unique current versions 2.33.1-2 (uuidd), 1.44.5-1 (4 others) I see it's talking about sub-packages of util-linux, but ISTM that even the prior upload of 2.33.1-1 long ago should have provoked this error. I've looked around a bit locally in hopes of figuring this out, but no luck. I can't tell if this is something I could/should fix with a manual "version: 2.33.1-2" added to the appropriate hint files before upload, or something that needs fixing or cleanout on sourceware. Any leads appreciated... Thanks! ..mark
[ITA] util-linux
I'd like to adopt util-linux from Yaakov if that's possible. To that end I've re-spun the current (for Cygwin) 2.33.1 release with additional patches to enable building 'taskset' and 'chrt'. Taskset works, chrt "works" but can't do anything useful. Tested both 64- and 32-bit Cygwin. I've placed a copy of the source tarball at http://maxrnd.com/~mark/cygwin/util-linux/util-linux-2.33.1-2-src.tar.xz for your reviewing pleasure. I'd appreciate any comments or corrections. Thanks, ..mark
util-linux update?
Hi Yaakov,
May I update the version of util-linux available on Cygwin? Your cygport
file for the current 2.33.1 seems to work fine for the latest 2.35.1.
I would add a patch file 2.33.1-cygwin-cpuset.patch (see attached) and
update the cygport file to reference this additional patch and remove the
"--disable-schedutils" from CYGCONF_ARGS. With these changes a working
'taskset.exe' will be an additional build output.
I would package the latest util-linux 2.35.1 unless you'd prefer some
intermediate version.
Thank you,
..mark
--- origsrc/util-linux-2.33.1/lib/cpuset.c 2018-06-04 00:57:02.792445800
-0700
+++ src/util-linux-2.33.1/lib/cpuset.c 2020-01-11 00:37:39.126054200 -0800
@@ -60,7 +60,7 @@ static const char *nexttoken(const char
*/
int get_max_number_of_cpus(void)
{
-#ifdef SYS_sched_getaffinity
+#if defined(SYS_sched_getaffinity) || defined(__CYGWIN__)
int n, cpus = 2048;
size_t setsize;
cpu_set_t *set = cpuset_alloc(cpus, , NULL);
@@ -72,7 +72,11 @@ int get_max_number_of_cpus(void)
CPU_ZERO_S(setsize, set);
/* the library version does not return size of cpumask_t */
+#if defined(__CYGWIN__)
+ n = __sched_getaffinity_sys(0, setsize, set);
+#else
n = syscall(SYS_sched_getaffinity, 0, setsize, set);
+#endif
if (n < 0 && errno == EINVAL && cpus < 1024 * 1024) {
cpuset_free(set);
Towards support of taskset(1) within util-linux package
Hi Yaakov,
I patched util-linux locally to build the 'taskset' tool so I could test
my implementation of the get- and set-affinity functions within Cygwin.
The implementation will be part of the upcoming Cygwin 3.1.0 release.
I'm not sure how to manipulate the build environment so I could supply a
'git send-mail' of a 'git format-patch' that would be usable to you.
I hope the following 'diff -u' outputs will be useful; but if you'd prefer
a different format just let me know.
Thank you for all your work on Cygwin!
..mark
cd /usr/src/util-linux-2.33.1-1.src
diff -u util-linux.cygport.safe util-linux.cygport
--- util-linux.cygport.safe 2019-03-05 12:07:51.0 -0800
+++ util-linux.cygport 2019-05-23 22:43:40.520885600 -0700
@@ -147,7 +147,6 @@
--enable-more
--enable-pg
--disable-setterm
- --disable-schedutils
--disable-wall
--disable-write
--disable-use-tty-group
cd util-linux-2.33.1-1.x86_64/src/util-linux-2.33.1/lib
diff -u cpuset.c.safe cpuset.c
--- cpuset.c.safe 2018-06-04 00:57:02.792445800 -0700
+++ cpuset.c2019-06-21 01:36:44.078702800 -0700
@@ -60,7 +60,7 @@
*/
int get_max_number_of_cpus(void)
{
-#ifdef SYS_sched_getaffinity
+#if defined(SYS_sched_getaffinity) || defined(__CYGWIN__)
int n, cpus = 2048;
size_t setsize;
cpu_set_t *set = cpuset_alloc(cpus, , NULL);
@@ -71,8 +71,12 @@
for (;;) {
CPU_ZERO_S(setsize, set);
+#if defined(__CYGWIN__)
+ n = sched_getaffinity(0, setsize, set);
+#else
/* the library version does not return size of cpumask_t */
n = syscall(SYS_sched_getaffinity, 0, setsize, set);
+#endif
if (n < 0 && errno == EINVAL && cpus < 1024 * 1024) {
cpuset_free(set);
Re: setup 2.894 release candidate - please test
Corinna Vinschen wrote: On Oct 14 13:29, Achim Gratz wrote: Marco Atzeri writes: May I have a hippo for Jon ? +1 +1 +1 Looks and works great in my limited testing. ..mark
Re: [PATCH libtirpc] Disable libtirpc's own bindresvport{,_sa}() in favor of Cygwin's
Yaakov Selkowitz wrote: On 2018-02-07 01:29, Mark Geisert wrote: I don't have libtirpc in git so I'm submitting a text patch. Sorry for any inconvenience. This is Cygwin-specific and against src/bindresvport.c of libtirpc 1.0.1. Unsure if it ought to go upstream; appreciate input on that. As Eric mentioned, ed-script diffs are useless. Nonetheless, I have been following the discussion, and the correct fix is: https://github.com/cygwinports/libtirpc/blob/master/1.0.2-cygwin-bindresvport.patch libtirpc 1.0.2-2 is on its way to the mirrors. Thank you for following the discussion and reworking the patch, Yaakov. Cheers, ..mark
Re: [PATCH libtirpc] Disable libtirpc's own bindresvport{,_sa}() in favor of Cygwin's
Brian Inglis wrote:
On 2018-02-07 08:38, Eric Blake wrote:
On 02/07/2018 01:29 AM, Mark Geisert wrote:
I don't have libtirpc in git so I'm submitting a text patch. Sorry for any
inconvenience. This is Cygwin-specific and against src/bindresvport.c of
libtirpc 1.0.1. Unsure if it ought to go upstream; appreciate input on that.
Thanks much,
..mark
8<
35a36,38
> /* On Cygwin prefer Cygwin's bindresvport{,_sa}() to portable version here */
An ed-script diff is practically useless; without context, it is too easy to
misapply the patch if the file has been edited differently in the meantime.
ALWAYS use 'diff -u' (what git does by default) or 'diff -c' when generating a
patch, so that it has proper context.
Also mandatory to add -p, --show-c-function for patches, and in general for
directory or recursive patch diffs -N, --new-file so new files are diffed as if
against an empty file; --strip-trailing-cr is useful if some files may have CRs.
Understood. Thanks for the advice. I knowingly took a risk here on the
assumption nobody else would be working on this specific file. But with your
advice I don't need to take that kind of risk again. And the patch will be more
robust too.
Cheers,
..mark
[PATCH libtirpc] Disable libtirpc's own bindresvport{,_sa}() in favor of Cygwin's
I don't have libtirpc in git so I'm submitting a text patch. Sorry for any
inconvenience. This is Cygwin-specific and against src/bindresvport.c of
libtirpc 1.0.1. Unsure if it ought to go upstream; appreciate input on that.
Thanks much,
..mark
8<
35a36,38
> /* On Cygwin prefer Cygwin's bindresvport{,_sa}() to portable version here */
> #if !defined(__CYGWIN__)
>
247a251,252
>
> #endif /* !defined(__CYGWIN__) */
Re: libtool not finding /usr/lib/libintl.la or what?
On Sat, 1 Jul 2017, Marco Atzeri wrote: On 01/07/2017 07:47, Mark Geisert wrote: Esteemed co-conspirators, I've been pulling my hair out trying to build a new cygutils package on 32-bit Cygwin. The exact same source package builds fine on 64-bit but 32-bit fails with the following... CC src/ipc/semstat.o CXX src/cygdrop/src_cygdrop_cygdrop-cygdrop.o CCLD src/cygicons/libicons.la CCLD src/banner/banner.exe libtool: error: cannot find the library '/usr/lib/libintl.la' or unhandled argument '/usr/lib/libintl.la' it is pulled by /usr/lib/libpopt.la. try $ cd /usr/lib $ mv libpopt.la libpopt.la_bk and run again make in build Amazing. That does work. But what is the correct way to deal with this when some random user wants to build 32-bit cygutils from source? Should the build procedure actually do what you suggested? I could not figure out which package supplies (or used to supply) libintl.la for 32 bits. Thanks much, ..mark
libtool not finding /usr/lib/libintl.la or what?
Esteemed co-conspirators, I've been pulling my hair out trying to build a new cygutils package on 32-bit Cygwin. The exact same source package builds fine on 64-bit but 32-bit fails with the following... make[2]: Entering directory '/usr/src/cygutils-test/cygutils-1.4.16-1.i686/build' CCRC src/cygicons/cygicons.lo CC src/banner/banner.o CC src/clip/getclip.o CC src/clip/putclip.o CC src/cygstart/cygstart.o CXX src/lpr/Printer.o CXX src/lpr/Win32Utils.o CXX src/lpr/lpr.o CC src/mkshortcut/mkshortcut.o CC src/readshortcut/readshortcut.o CC src/winln/winln.o CC src/conv/conv.o CC src/dump/dump.o CC src/ipc/semtool.o CC src/ipc/shmtool.o CC src/ipc/msgtool.o CC src/ipc/semstat.o CXX src/cygdrop/src_cygdrop_cygdrop-cygdrop.o CCLD src/cygicons/libicons.la CCLD src/banner/banner.exe libtool: error: cannot find the library '/usr/lib/libintl.la' or unhandled argument '/usr/lib/libintl.la' make[2]: *** [Makefile:848: src/banner/banner.exe] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/usr/src/cygutils-test/cygutils-1.4.16-1.i686/build' make[1]: *** [Makefile:1352: all-recursive] Error 1 make[1]: Leaving directory '/usr/src/cygutils-test/cygutils-1.4.16-1.i686/build' make: *** [Makefile:687: all] Error 2 *** ERROR: make failed None of the source files make use of internationalization yet. Package author Charles Wilson made the package i18n-ready in case a future addition to the package needed it. There weren't any issues building for 32-bit on the last go-round ~1.5 years ago. Does anybody recognize the issue? Thanks for any leads. Yours in frustration, ..mark
Re: cygfuse
On Tue, 20 Sep 2016, Bill Zissimopoulos wrote: On 9/8/16, 1:03 AM, Mark Geisert wrote: I've changed Subject: to reflect what's being discussed now. When we have a consensus cygfuse I'll issue an ITP for it. I've now updated the cygfuse repository on GitHub so it is more neutral about FUSE implementations. It can be seen at https://github.com/mgeisert/cygfuse . I've also read up a little on Dokan and Dokany, so I should be able to better respond to any comments Adrien might have about the updated cygfuse. Mark, has there been any additional progress on this? No activity. I was not expecting Dokany to be fully integrated before ITPing cygfuse, but I had hoped to hear at least that the layout of FUSE include files works for them (or doesn't) and that the strategy of dynamic loading Dokany's DLL is workable for them too. Looking at the updated cygfuse I believe one change would be to rename cygfuse.pc back to fuse.pc so that build configuration scripts can find it. I have created a github issue for this. I've now made those changes and updated the GitHub issue. Should the URL named in fuse.pc.in now point at the GitHub cygfuse project? Other than that I would think that the package would be ready for submission. Any changes to support additional projects like Dokany, etc. could easily happen in the future when those projects are ready. Agreed. It would be neet though to find out sooner rather than later whether some other FUSE implementation can coexist with WinFSP. I don't have the bandwidth to check Dokany or any others myself despite interest. ..mark
Re: [ITP] FUSE 2.8
Herbert Stocker wrote: Maybe somebody wants to use WinFSP for Windows programs and Dokan for Cygwin programs. There should be some user setting for the case both are installed. Maybe some cygfuse-admin command could do the job. This kind of flexibility would be nice. We can of course only control the Cygwin environment though. As a first cut I've implemented an environment variable CYGFUSE that can be set to either "WinFSP" or "Dokany" (any case allowed) to select which FUSE DLL to load at runtime. Thanks, ..mark
cygfuse (was Re: [ITP] FUSE 2.8)
Mark Geisert wrote: [... some stuff ...] I've changed Subject: to reflect what's being discussed now. When we have a consensus cygfuse I'll issue an ITP for it. I've now updated the cygfuse repository on GitHub so it is more neutral about FUSE implementations. It can be seen at https://github.com/mgeisert/cygfuse . I've also read up a little on Dokan and Dokany, so I should be able to better respond to any comments Adrien might have about the updated cygfuse. Thanks all, ..mark
Re: [ITP] FUSE 2.8
Hi Adrien, I want to dig a little further into this... Adrien JUND wrote: I have tried to see how to integrate Dokan in cygfuse and it is currently hard linked to WinFSP and makes hard the integration for others FS. A neutral interface with common operations should be made to fix the situation. Cygfuse is intended to be the neutral interface. I'll be making cosmetic changes to it to make it more clear what belongs to cygfuse and what belongs to FUSE implementation DLLs loaded by cygfuse. Does the strategy of testing something in the environment for existence of Dokan, then if found, load a Dokan-specific DLL sound workable for you? I want to be sure I'm not assuming too much about what FUSE implementations provide. If you can be more specific about the gap between cygfuse as it is now and cygfuse being usable for you, please feel free. You could also wait for a cosmetically updated cygfuse which I hope to have in "a few days" modulo real life interruptions. Thanks much, ..mark
Re: [ITP] FUSE 2.8
Adrien JUND wrote: Separate from that, it's been a little work disentangling the meaning of various names used for this project. Here's what I think the names mean: FUSE - a protocol, which exists in different versions WinFSP - a Windows-native DLL mapping FUSE 2.8 ops to/from Windows file ops cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP If that's correct, I'd like to regularize the names of things in the proposed cygfuse package to accurately reflect their meaning. E.g., change fuse.cygport to cygfuse.cygport, etc. The doc inside some files might need updating. About cygfuse description, does the goal of cygfuse is not to wrappe FUSE API for user land file systems like Dokan, WinFSP, CBFS, and others ? I have tried to see how to integrate Dokan in cygfuse and it is currently hard linked to WinFSP and makes hard the integration for others FS. A neutral interface with common operations should be made to fix the situation. I believe all interested parties have agreed we want to support multiple FUSE implementations. cygfuse is intended to be the connector between a FUSE implementation and Cygwin versions of FUSE apps like SSHFS and FUSEPY. The idea was to allow different FUSE implementations (e.g., WinFSP, Dokan, etc) under the hood without having to modify the Cygwin level apps SSHFS, FUSEPY, etc to match. As currently implemented, cygfuse is hardwired to work with WinFSP. That's only a consequence of cygfuse having been provided by WinFSP's author. The plan is to extend cygfuse so that it can support multiple FUSE implementations of which one is selected at runtime. Currently, if WinFSP is installed on the system (determined by the existence of a particular registry key) then cygfuse attaches to the WinFSP DLL. This code needs to be extended to check whether Dokan is installed (determined by some mechanism TBD) and then attach to Dokan's DLL. And so on for other future implementations. I'm trying to get my understanding of the pieces and naming correct in order to modify the cygfuse code to be more generic and less tied to WinFSP. ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: Mark, hi: On 8/22/16, 12:43 PM, cygwin-apps-ow...@cygwin.com on behalf of Mark Geisert wrote: > I'm debugging some faulting test programs so this cygfuse code doesn't seem fully ready for prime time just yet. I'm sure Bill had it working so it's likely to be some kind of local issue, so it's mine to solve. While still on vacation I now have reliable access to the Internet and am able to follow up on any issues. Please let me know what the issue you are seeing is and I will try to help. Sorry for the delay. I've 'git clone'd the cygfuse repository and have been poking around, building and testing things. 'make cygfuse-test.exe' does build a cygfuse-test.exe but running it yields a core dump. Exit status is 134. I'm just running it without any args. Is that abort a symptom of not having the WinFSP driver loaded, or something else? Cygfuse works for both 32- and 64-bit Windows environments, right (assuming you're running the correct one)? Separate from that, it's been a little work disentangling the meaning of various names used for this project. Here's what I think the names mean: FUSE - a protocol, which exists in different versions WinFSP - a Windows-native DLL mapping FUSE 2.8 ops to/from Windows file ops cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP If that's correct, I'd like to regularize the names of things in the proposed cygfuse package to accurately reflect their meaning. E.g., change fuse.cygport to cygfuse.cygport, etc. The doc inside some files might need updating. I wasn't sure from Corinna's comments a while back (re hosting this package) whether she thought cygfuse should be part of Cygwin, as in placed in the Cygwin source tree, or just conveniently hosted on the Cygwin GitHub area. That's where I'm at. Thanks for reading. ..mark
Re: [ITP] FUSE 2.8
On Wed, 17 Aug 2016, Corinna Vinschen wrote: Mark, did you find out how to move the repo under the Cygwin org in the meantime? Is it the "Import repository" functionality by any chance? Hi Corinna, Bill and I worked it out on a different thread of this conversation. I currently have a public repo mgeisert/cygfuse on GitHub. That seemed to be sufficient to me as maintainer. Does it need to be moved under cygwin/ ? If yes, it looks like "Import Repository" is a way to do it. It doesn't *need* to be but it would be neat and helpful to have closley Cygwin-related projects in the Cygwin org. I don't have any objection to that in principle. It's hard for me to tell if this project qualifies that way, though. Conceptually it's kind of like a VFS layer, but the core functionality is in Bill's separate Windows-native WinFSP dll. The Cygwin end of things is just a bunch of wrappers around WinFSP calls all collected in a Cygwin dll. (BTW, I don't see how transparency is supposed to work in a setup like this.) I was planning to make sure the package Bill supplied met all the requirements for a Cygwin package. I figure it's real close but there was something I wasn't sure about and needed to research further, then real life intervened. Something to do with where its cygport file was getting package source from. Directly from git? See, e.g., the cygwin package's cygport. OK. The cygfuse.cygport file is referring to Bill's separate GitHub space for source code. Not sure it ought to do that. Either my GitHub space (as I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems better. I'm debugging some faulting test programs so this cygfuse code doesn't seem fully ready for prime time just yet. I'm sure Bill had it working so it's likely to be some kind of local issue, so it's mine to solve. ..mark
Re: [ITP] FUSE 2.8
Corinna Vinschen wrote: On Jul 29 11:48, Corinna Vinschen wrote: On Jul 29 02:15, Mark Geisert wrote: Corinna Vinschen wrote: On Jul 29 01:19, Mark Geisert wrote: Bill Zissimopoulos wrote: On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: Ok. I did the transfer (twice, because of some ambiguous GitHub messages). Someone from cygwin’s side has to accept the repo within a day according to GitHub. Turns out I can transfer a repo to another user, but not to an organization that I do not have admin rights for: From github’s transfer repo instructions: << Transfer this repository to another user or to an organization where you have admin rights. FWIW I've signed up with GitHub with username mgeisert. I think I need to be invited to join the cygwin@github org. Then maybe I can transfer your repo to me? Corrections welcome... I invited you with email mark AT maxrnd DOT com There appears to be a user account called mgeisert, but it has no further info attached, not even a name. Thanks Corinna, I've accepted the invite and filled in my profile a bit. How would I/we accept the repo as Bill mentions above? Then I guess a transfer needs to be done after that? I really don't know, sorry. I'm not actually using github a lot since the cygwin repo is only mirrored to github. I'd guess there's some kind of documentation on github explaining stuff like that...? Mark, did you find out how to move the repo under the Cygwin org in the meantime? Is it the "Import repository" functionality by any chance? Hi Corinna, Bill and I worked it out on a different thread of this conversation. I currently have a public repo mgeisert/cygfuse on GitHub. That seemed to be sufficient to me as maintainer. Does it need to be moved under cygwin/ ? If yes, it looks like "Import Repository" is a way to do it. I was planning to make sure the package Bill supplied met all the requirements for a Cygwin package. I figure it's real close but there was something I wasn't sure about and needed to research further, then real life intervened. Something to do with where its cygport file was getting package source from. ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: On 7/29/16, 1:19 AM, Mark Geisert wrote: FWIW I've signed up with GitHub with username mgeisert. I think I need to be invited to join the cygwin@github org. Then maybe I can transfer your repo to me? Corrections welcome... Hey, Mark. I just transferred the cygfuse repo under your name. Thanks. Great! Thank you Bill for your contribution of Cygwin support for WinFSP. Have a nice time AWOL :). ..mark
Re: [ITP] FUSE 2.8
Corinna Vinschen wrote: On Jul 29 01:19, Mark Geisert wrote: Bill Zissimopoulos wrote: On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: Ok. I did the transfer (twice, because of some ambiguous GitHub messages). Someone from cygwin’s side has to accept the repo within a day according to GitHub. Turns out I can transfer a repo to another user, but not to an organization that I do not have admin rights for: From github’s transfer repo instructions: << Transfer this repository to another user or to an organization where you have admin rights. FWIW I've signed up with GitHub with username mgeisert. I think I need to be invited to join the cygwin@github org. Then maybe I can transfer your repo to me? Corrections welcome... I invited you with email mark AT maxrnd DOT com There appears to be a user account called mgeisert, but it has no further info attached, not even a name. Thanks Corinna, I've accepted the invite and filled in my profile a bit. How would I/we accept the repo as Bill mentions above? Then I guess a transfer needs to be done after that? ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: Ok. I did the transfer (twice, because of some ambiguous GitHub messages). Someone from cygwin’s side has to accept the repo within a day according to GitHub. Turns out I can transfer a repo to another user, but not to an organization that I do not have admin rights for: From github’s transfer repo instructions: << Transfer this repository to another user or to an organization where you have admin rights. FWIW I've signed up with GitHub with username mgeisert. I think I need to be invited to join the cygwin@github org. Then maybe I can transfer your repo to me? Corrections welcome... ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: Hi, Mark: On 7/28/16, 10:29 AM, Mark Geisert wrote: Please be mindful if you intend to test that the current released binary of WinFsp does not support Windows 7. This is because the last release erroneously uses a Windows 8 only API (GetOverlappedResultEx). It's your call obviously but do you want to forgo Win 7 support when many of the kind of developers who might be interested in FUSE on Windows are delaying or not bothering to upgrade to Win 8.x or Win 10 for various reasons? I agree. Win7 support will return soon. I am trying to get this fixed before I leave tomorrow, but I also have some real (as in paying) work to do so no guarantees. Just wanted to let you know that I have made a new public release of WinFsp, which should correctly work on all versions of Windows 7 and above. You can download it from here: http://www.secfs.net/winfsp/download/ Excellent! Thanks for your patience and diligence on this. I look forward to using WinFSP and taking over maintenance of the Cygwin end of it. Cheers, ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: On 7/28/16, 1:04 PM, Corinna Vinschen wrote: On Jul 28 19:13, Bill Zissimopoulos wrote: Mark: I agree with how you want to adjust license and transfer ownership. I don't have a presence on GitHub but I should be able to grab cygfuse anyway. Thank you very much for agreeing to become the maintainer for [CYGFUSE]. Please consider this post as my public announcement that I am relicensing the [CYGFUSE] files under the BSD 2-clause license and that I am assigning maintainership to Mark. The project has been updated with a README and a LICENSE file that state the same. Source files have been updated to reflect the license change as well. Mark, if at some point you do get a github account, I will be happy to transfer ownership of the project as well. In the mean time do you have somewhere where you intend to host it? github Cygwin org? https://github.com/cygwin Every Cygwin-related project is welcome. If Mark agrees, I am happy to transfer ownership of the github repo to the cygwin@github. Sounds like a fine idea! ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: Mark: I agree with how you want to adjust license and transfer ownership. I don't have a presence on GitHub but I should be able to grab cygfuse anyway. Thank you very much for agreeing to become the maintainer for [CYGFUSE]. Please consider this post as my public announcement that I am relicensing the [CYGFUSE] files under the BSD 2-clause license and that I am assigning maintainership to Mark. The project has been updated with a README and a LICENSE file that state the same. Source files have been updated to reflect the license change as well. Mark, if at some point you do get a github account, I will be happy to transfer ownership of the project as well. In the mean time do you have somewhere where you intend to host it? Regards, Bill Zissimopoulos [CYGFUSE]: https://github.com/billziss-gh/cygfuse I'll likely host it from my private http/ftp server at maxrnd.com, at least initially. The cygutils package was there for review so I know it would work. I've been looking at some of the public repositories over time but haven't moved to one, largely because I haven't really needed it. OK on your changes above including the minor correction you made afterwards. Cheers, ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: On 7/28/16, Mark Geisert wrote: Bill Zissimopoulos wrote: Please be mindful if you intend to test that the current released binary of WinFsp does not support Windows 7. This is because the last release erroneously uses a Windows 8 only API (GetOverlappedResultEx). It's your call obviously but do you want to forgo Win 7 support when many of the kind of developers who might be interested in FUSE on Windows are delaying or not bothering to upgrade to Win 8.x or Win 10 for various reasons? I agree. Win7 support will return soon. I am trying to get this fixed before I leave tomorrow, but I also have some real (as in paying) work to do so no guarantees. Is there an alternative to that particular API that would allow Win 7 support? This particular problem has been fixed by a combination of WaitForSingleObject and GetOverlappedResult (GetOverlappedResultEx is really a wrapper around WaitForSingeObject). But I have also discovered another issue that is less trivial. Argh. Your detailed build instructions worked fine for me. I'll be unable to test until I set up a Win 8.x or Win 10 VM at some point. But so far so good. I am going to really try to get that Win 7 supporting build out by the end of Thursday (Pacific time). That's the timezone I'm in. I'll see what's going on later tonight :) . Since this cygfuse glue DLL is a separate package from your FUSE implementation, I guess it'll need a separate ITP. Will you do the initial package upload and then turn maintainership over to me, or would you prefer I own the package from the start? Either way OK with me. I guess whoever will be doing the initial upload should be the ITP submitter as well. Actually my ITP submission is this cygfuse DLL. Based on what you write above it looks like you are happy to become the maintainer(?). If yes, it would perhaps make sense for you to resubmit the package. Please let me know if you agree and I will place the package under the BSD and transfer ownership to you on GitHub. My mistake. I thought your FUSE implementation had to be compiled for Cygwin, in order to make use of the cygfuse glue logic. But instead you have a native Windows FUSE implementation? Won't you have ABI (not API) problems connecting those two pieces, depending on how the FUSE guts are implemented? Apologies if you've sorted that all out; don't want to hold you up talking about solved aspects. I agree with how you want to adjust license and transfer ownership. I don't have a presence on GitHub but I should be able to grab cygfuse anyway. Thanks much, ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: Please be mindful if you intend to test that the current released binary of WinFsp does not support Windows 7. This is because the last release erroneously uses a Windows 8 only API (GetOverlappedResultEx). It's your call obviously but do you want to forgo Win 7 support when many of the kind of developers who might be interested in FUSE on Windows are delaying or not bothering to upgrade to Win 8.x or Win 10 for various reasons? Is there an alternative to that particular API that would allow Win 7 support? PS: I am going AWOL this Friday. If you don't mind my asking, do you mean for the day, for a couple weeks, for ever, ??? :-D Sorry! I am realizing now this could be taken in a darker way than I intended. I just meant I am going on vacation and that I have to attend to some family matters. It is likely I will not be able to participate in discussions for a few weeks. Appreciate knowing the time frame :). Your detailed build instructions worked fine for me. I'll be unable to test until I set up a Win 8.x or Win 10 VM at some point. But so far so good. Since this cygfuse glue DLL is a separate package from your FUSE implementation, I guess it'll need a separate ITP. Will you do the initial package upload and then turn maintainership over to me, or would you prefer I own the package from the start? Either way OK with me. I guess whoever will be doing the initial upload should be the ITP submitter as well. Thanks, ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos writes: > To test that things work, clone my sshfs repo from: > > https://github.com/billziss-gh/sshfs > > And issue the following commands: > > $ autoreconf -i > $ ./configure On my test machine (Win7 64, Cygwin 64) I get the errors shown below. But first let me ask... > PS: I am going AWOL this Friday. If you don't mind my asking, do you mean for the day, for a couple weeks, for ever, ??? Thanks, ..mark Here is the tail end of the ./configure output: 8< checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for library containing dlsym... none required checking OpenSSH version... 6.9 >= 4.4, disabling NODELAY workaround checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for SSHFS... no configure: error: Package requirements (fuse >= 2.3 glib-2.0 gthread- 2.0) were not met: No package 'fuse' found No package 'glib-2.0' found No package 'gthread-2.0' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables SSHFS_CFLAGS and SSHFS_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. >8 The following shows I have glib2 installed. I can't find a gthread package for Cygwin. I've compiled cygfuse; what cygport command will satisfy the package reference for configure (newbie question this)? $ cygcheck -c | egrep 'fuse|glib|gthread' libglib2.0_0 2.46.2-4 OK
Re: [ITP] FUSE 2.8
Bill Zissimopoulos writes: > BTW, here is another alternative that I have been mulling around. > [...] Very interesting. I'll need a little more time to investigate; github is throwing unicorns at the moment. Could the Dokany folks consider whether this kind of wrapping might work for them too? I'm guessing they'll have a different a list of symbols to be dlsym'd (unless there's a common API) and possibly a different method to determine whether their driver is installed. If this turns out to be a workable solution, I am willing to be maintainer of the glue library Bill is offering. Thanks, ..mark -- captcha: durability
Re: [ITP] FUSE 2.8
Adrien JUND writes: > >You could define a package "fuse" with no contents and a dependency on > >package "winfsp-fuse". Then later when/if another FUSE implementation > >becomes available, "somebody" could replace the "fuse" package with > >whatever is required to get alternatives support for the variants. > I have not officially open request now but right after we found a > solution to handle fuse wrapper packages, > I will apply for dokan as well as winfsp. > > Also, I think that packages binary dependent to a fuse wrapper would not work > if it is another wrapper that is installed. > So shall we not just let the package dependent to fuse, explicit the > wrapper that he will use ? Erm, I'm belatedly comprehending it's two independent FUSE implementations and not two versions with some common history. OK. If there's a documented binary API at some level of the FUSE definition that both implementations provide then that's what the proposed "fuse" package could export. Both implementations would then independently supply code that meets the API. I'm not sure how much extra work this means for both projects. If a common API-level interface is unworkable for whatever reason, then we'll just have to live with two independent fuse implementations. Tools like sshfs will have to be supplied by both projects and will only work with the correct underlying FUSE implementation. Something alternatives-like would be nice for an end user to switch between implementations, but I don't know if that's workable. Should it be possible to have both implementations installed at the same time? ..mark -- captcha: homely
Re: [ITP] FUSE 2.8
Bill Zissimopoulos writes: > - Rename the package to winfsp-fuse, but have it somehow “satisfy” > packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow > multiple *-fuse packages to exist in the setup database and the user > chooses which one they want. My understanding based on Marco’s answer is > that this is not currently supported by Cygwin’s dependency system. You could define a package "fuse" with no contents and a dependency on package "winfsp-fuse". Then later when/if another FUSE implementation becomes available, "somebody" could replace the "fuse" package with whatever is required to get alternatives support for the variants. I'm wondering if "fuse-" is a better name template than "-fuse" in order to keep the variants near each other in setup.exe's displays. ..mark
Re: unison-2.48 build fails with latest ocaml and flexdll (ping: Yaakov, Damien)
Mark Geisert wrote: the relocation error is different in a 5.3.0 object than a 4.9.2 object such as ^ 4.8.2 So for your case I'd first try rebasing flexdll.so down to 0xeff3 (you may collide with something else so pay attention to rebase complaints and try a different address if necessary). If that doesn't help then try rebuilding flexdll.so with gcc 5.3.0 if it is currently being built with an older gcc. Mis-stated the 2nd incantation. Try rebuilding the thing that's linking against flexdll.so with gcc 5.3.0. ..mark
Re: SSH key for upload access
On Sun, 17 Jan 2016, Corinna Vinschen wrote: On Jan 17 01:50, Mark Geisert wrote: Name: Mark Geisert Package: cygutils BEGIN SSH2 PUBLIC KEY Applied, please test that it works. Works fine; thanks much! ..mark
SSH key for upload access
Name: Mark Geisert Package: cygutils BEGIN SSH2 PUBLIC KEY Comment: "4096-bit RSA, converted by Mark@zotac from OpenSSH" B3NzaC1yc2EDAQABAAACAQDaZYFNfPTl20P8ASod06gPtRPVDlwWbDr1YaQcxN G4lfl8+fhcBl4G6X/wrhzo+oDxzVErHniAZfR8TyMp3F4l02/BufQ5JgUzfMG+g2E8y4Sv LTqkgy2H7alyR4s/QxU9pzFrNfOsfK09jGHfmac8oBbJRpz3yFzCgpHsUDekdLKTKxhetN J7vX9f7IQFxJa6O7yn5GoXQ/2sFTU9FAY6jusZ3Gb1eGWvwtCKj35Sc73n33yrPVAyMMmc LvAUFj78HmcS64WZtOaswiK5feIy3CGAcMsmYgzLp9proiy8yenH1YSIIvEYo2ufi7MLnC xqHS60yyLJM4KepssqfHg1UUgtmDeOIklxehL4qk91ab8r+75QshFMAlQUXIAtgw6R8L4H XlxqZyoSJouCTniwqelZ7fI2FaARapM5Fwp+JfH953mRmFrNNLUZ08Zk3Lul0/C4s1eHL7 Cfi6SL0fmCT4iCrNAROzz+QCFDVwGVkU2Fr6dCIXjG0AN9+Di+YzWsTwh/kKtHZbUt/37b 2Uf23f8wOoqAx+lDt3r3Xy58eOz7ynmG6UQBxAwhMpxGA4Xns/3/BkWrhSM1v8tvtMW1/r BJFcEzUPKDUnw3JAux4ZHoBn4yFFp8zbb44tKoKqM8BlhY4la2nIE7Hy33zzhQasrGkyBA pZ2Ab5JhiuGeWQ== END SSH2 PUBLIC KEY
Re: [ITA] cygutils
On Mon, 16 Nov 2015, Corinna Vinschen wrote: Packaging looks good. Just one nit: While this is as Chuck did it way back when, I think the files under /usr/share/doc should go into the base cygutils package, rather than the cygutils-extra package, i.e. usr/share/doc/cygutils/AUTHORS usr/share/doc/cygutils/ChangeLog usr/share/doc/cygutils/COPYING usr/share/doc/cygutils/HOW-TO-CONTRIBUTE usr/share/doc/cygutils/licenses/ usr/share/doc/cygutils/licenses/COPYING.BSD-no-advert usr/share/doc/cygutils/licenses/COPYING.GPLv2 usr/share/doc/cygutils/licenses/COPYING.GPLv3 usr/share/doc/cygutils/NEWS usr/share/doc/cygutils/PROGLIST usr/share/doc/cygutils/README usr/share/doc/cygutils/TODO should be in the cygutils package, while usr/share/doc/cygutils/cygicons/ usr/share/doc/cygutils/cygicons/README usr/share/doc/cygutils/lpr/ usr/share/doc/cygutils/lpr/README should stay in cygutils-extra. That's a minor point and at your discretion, otherwise GTG. I agree and have adjusted the packaging as you suggested. Something I don't understand yet is why, when using this cygutils.cygport, some cygport commands download the source from sourceware via git, while other commands seem to want the .tar.bz2 file. The cygutils.cygport is possibly not completely right yet. You have both, a SRC_URI and a GIT_URI. This might confuse cygport. Drop the SRC_URI and only keep GIT_URI. Even with that change 'cygport all' wants the .tar.bz2 file to be present. Maybe my mistake is assuming "all" means pull the source too? If I do 'cygport fetch all' it works like a charm using the Git tree, so I'll just keep doing that. ..mark
Re: [ITA] cygutils
Sorry, the links are busted. Let me fix and re-post. Sheesh. ..mark On Sun, 15 Nov 2015, Mark Geisert wrote: I think my ITA is sorted out well enough to be reviewed. If you find a sharp edge somewhere, please don't assume it's maintainer preference; it's more likely maintainer ignorance so please do fill me in. The following links are all relative to http://maxrnd.com/~mark/cygwin/. HREF="http://maxrnd.com/~mark/cygwin/cygutils/cygutils-1.4.15-1.src.patch;>cygutils/cygutils-1.4.15-1.src.patch [...]
Re: [ITA] cygutils
I think my ITA is sorted out well enough to be reviewed. If you find a sharp edge somewhere, please don't assume it's maintainer preference; it's more likely maintainer ignorance so please do fill me in. The following links are all relative to http://maxrnd.com/~mark/cygwin/. http://maxrnd.com/~mark/cygwin/cygutils/cygutils-1.4.15-1.src.patch;>cygutils/cygutils-1.4.15-1.src.patch http://maxrnd.com/~mark/cygwin/cygutils/cygutils.cygport;>cygutils/cygutils.cygport http://maxrnd.com/~mark/cygwin/cygutils/cygwin-cygutils-1.4.15.tar.bz2;>cygutils/cygwin-cygutils-1.4.15.tar.bz2 http://maxrnd.com/~mark/cygwin/x86/release/cygutils/cygutils-1.4.15-1-src.tar.xz;>x86/release/cygutils/cygutils-1.4.15-1-src.tar.xz http://maxrnd.com/~mark/cygwin/x86/release/cygutils/cygutils-1.4.15-1.tar.xz;>x86/release/cygutils/cygutils-1.4.15-1.tar.xz http://maxrnd.com/~mark/cygwin/x86/release/cygutils/setup.hint;>x86/release/cygutils/setup.hint http://maxrnd.com/~mark/cygwin/x86/release/cygutils/cygutils-debuginfo/cygutils-debuginfo-1.4.15-1.tar.xz;>x86/release/cygutils/cygutils-debuginfo/cygutils-debuginfo-1.4.15-1.tar.xz http://maxrnd.com/~mark/cygwin/x86/release/cygutils/cygutils-debuginfo/setup.hint;>x86/release/cygutils/cygutils-debuginfo/setup.hint http://maxrnd.com/~mark/cygwin/x86/release/cygutils/cygutils-extra/cygutils-extra-1.4.15-1.tar.xz;>x86/release/cygutils/cygutils-extra/cygutils-extra-1.4.15-1.tar.xz http://maxrnd.com/~mark/cygwin/x86/release/cygutils/cygutils-extra/setup.hint;>x86/release/cygutils/cygutils-extra/setup.hint http://maxrnd.com/~mark/cygwin/x86/release/cygutils/cygutils-x11/cygutils-x11-1.4.15-1.tar.xz;>x86/release/cygutils/cygutils-x11/cygutils-x11-1.4.15-1.tar.xz http://maxrnd.com/~mark/cygwin/x86/release/cygutils/cygutils-x11/setup.hint;>x86/release/cygutils/cygutils-x11/setup.hint http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/cygutils-1.4.15-1-src.tar.xz;>x86_64/release/cygutils/cygutils-1.4.15-1-src.tar.xz http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/cygutils-1.4.15-1.tar.xz;>x86_64/release/cygutils/cygutils-1.4.15-1.tar.xz http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/setup.hint;>x86_64/release/cygutils/setup.hint http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/cygutils-debuginfo/cygutils-debuginfo-1.4.15-1.tar.xz;>x86_64/release/cygutils/cygutils-debuginfo/cygutils-debuginfo-1.4.15-1.tar.xz http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/cygutils-debuginfo/setup.hint;>x86_64/release/cygutils/cygutils-debuginfo/setup.hint http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/cygutils-extra/cygutils-extra-1.4.15-1.tar.xz;>x86_64/release/cygutils/cygutils-extra/cygutils-extra-1.4.15-1.tar.xz http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/cygutils-extra/setup.hint;>x86_64/release/cygutils/cygutils-extra/setup.hint http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/cygutils-x11/cygutils-x11-1.4.15-1.tar.xz;>x86_64/release/cygutils/cygutils-x11/cygutils-x11-1.4.15-1.tar.xz http://maxrnd.com/~mark/cygwin/x86_64/release/cygutils/cygutils-x11/setup.hint;>x86_64/release/cygutils/cygutils-x11/setup.hint Something I don't understand yet is why, when using this cygutils.cygport, some cygport commands download the source from sourceware via git, while other commands seem to want the .tar.bz2 file. The cygutils.cygport is possibly not completely right yet. Thanks for any comments, ..mark
Re: Still unable to 'git push' or ssh to sourceware -- resolved
On Tue, 10 Nov 2015, Corinna Vinschen wrote: You're missing something important. The key you sent to sware and the other key you sent to the cygwin-apps list are both the public part of your keys. This public part of a key *never* requires a passphrase. After all it's supposed to be readable by everyone, right? If ssh asks for a passphrase, it's your local, *private* key which is encrypted using this passphrase. Therefore this has nothing to do with ssh on the remote machine. It can't require passphrases since, obviously, it doesn't know your private key. The private key never leaves your local machine. So this asking for a passphrase is a local problem on your machine which you would have to fix locally. Btw., I never saw the problem that a local key without passphrase results in ssh asking for a passphrase. The difference in the keyfile (encrypted vs. non-encrypted) is obvious to ssh: $ head -2 .ssh/my_key -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED Many thanks for this correction to my broken mental model of passphrases vs passwords. Between these nuggets-o-knowledge and a fix to my ~/.ssh/config (i.e. IdentityFile *must* refer to a private key file) I was able to 'git push' my cygutils updates to sourceware with my original key. I am now debugging a revised cygutils.cygport and figuring out where I can host the updated tar.xz packages for review. I've got a place in mind. Thanks again, ..mark
Still unable to 'git push' or ssh to sourceware
Apologies for my continued stumbling around with this. I'm enough of a newbie in several necessary skills that I can't seem to get a handle on what's going wrong. I had assumed that having sent my "SSH key for upload access", it goes to the same location as my original key supplied on the sourceware.org/cgi-bin/pdw/ps_form.cgi form. That original key I supplied always provoked an 'enter passphrase' prompt when ssh or git contacted sourceware even though I had never supplied a passphrase for it. OK, maybe sourceware requires passphrases so I generated a new key with a passphrase. That's the key I sent recently as "SSH key for upload access". The only way I could think of to test authentication without doing anything potentially damaging was this command: ssh -v -v mgeis...@sourceware.org appendkey < /dev/null Here's the resulting debug log: OpenSSH_6.9p1, OpenSSL 1.0.2d 9 Jul 2015 debug1: Reading configuration data /home/Mark/.ssh/config debug1: /home/Mark/.ssh/config line 1: Applying options for sourceware.org debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to sourceware.org [209.132.180.131] port 22. debug1: Connection established. debug1: identity file /home/Mark/.ssh/id_dsa.pub type 2 debug1: key_load_public: No such file or directory debug1: identity file /home/Mark/.ssh/id_dsa.pub-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.9 debug1: Remote protocol version 1.99, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c00 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to sourceware.org:22 as 'mgeisert' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss debug2: kex_parse_kexinit: chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-...@openssh.com,hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-...@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-...@openssh.com,hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-...@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com
Re: Still unable to 'git push' or ssh to sourceware
On Mon, 9 Nov 2015, Yaakov Selkowitz wrote: On Mon, 2015-11-09 at 17:54 -0800, Mark Geisert wrote: I had assumed that having sent my "SSH key for upload access", it goes to the same location as my original key supplied on the sourceware.org/cgi-bin/pdw/ps_form.cgi form. Incorrect. Upload access is completely separate from shell access to sourceware, and neither implies or requires the other. Thanks for that. I need to update my shell access key but I can't make use of the appendkey trick, catch-22. Sounds like I should contact overseers then. ..mark
SSH key for upload access
Name: Mark Geisert Package: cygutils BEGIN SSH2 PUBLIC KEY B3NzaC1kc3MAAACBAPqsi50rpgqK96tXNgBYvenDeC/cd2uNOlWd6Lnir7UkrouasK cvzTjmonCqcjdNNND8ckSWr0mx2Vr1tlLAFziqRQN6WPzOISBsqbazB8LQ1OMfzjN2QNQN 0I2cQyoxkQGaRJZwucxYHTIRHIK7Os6k9Klwxh76FGNBUtzqrhfPFQDoP+1qKyKwV9 YVvI/uh6cukNjipQAAAIBnxrnRAyqBaZ34nxTiX14ulsROj/NfVNh99qI3z/dyWwseCW5Q 9h9IY8NhrXf6NuDoIuJ0W1S9LLa8qT/vWuHTCfpBkWfN/YZXM7Rd5rYqQTR0lWVIj7JAc6 A2jQTvz4McuECEBEVKF1GvNRxw/Gopi1XUzo8eZ3oH/tpHeIoZyQAAAIEAl7kkPDTSvBnN YrB7gPoS5GHwKGOUx2/6t9JTs7AKjU/BV7jFrCm98bXFahYNvWMmL5sVvkHizC9jLktwUz A4kxNifJVIO1PunwzAontScYkZTjJe67NBwmoqGxNalI90U8vk7i0RwjB60a7HM87qBLAq 3xBRP1hhseI+hk+EDzM= END SSH2 PUBLIC KEY
Re: Questions on package adoption conventions
I was able to 'git clone' the cygutils source tree and fix user-reported issues and my build issues. I'm ready to push the updates but have hit a snag... 8< git push origin master fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >8 I tried creating a git branch and pushing that instead; same error. Adding -v to the 'git push' command shows "Pushing to git://sourceware.org/git/cygwin-cygutils.git" which seems correct. I suspect my login credentials are incorrect. How/where do I specify what my sourceware login is? Or maybe it's some other problem? Separate from that, I will need to update the cygutils.cygport file which resides outside of this cygutils source tree. How do I access that file? And if that wasn't enough, here's another newbie question: Am I really supposed to push to master or is there a review that should be done first? So pushing a revision branch is the right way to allow for a review? Thanks for any hints, ..mark
Re: Questions on package adoption conventions
On Sat, 31 Oct 2015, Corinna Vinschen wrote: On Oct 31 00:18, Jon Turney wrote: On 30/10/2015 23:25, Mark Geisert wrote: I was confused by the SRC_URI= line in cygutils.cygport. Does that merely indicate where this package came from at the time the .cygport file was written, or does it denote a commitment by the maintainer to continue hosting the package from that URI? If the latter, that's why I was asking about access methods. Is SRC_URI required? SRC_URI is the URI for the upstream source. cygport's fetch (aka download) subcommand will fetch the upstream source from the specified SRC_URI cygutils is somewhat a special case as cygwin is the upstream :) The sources are in CVS at pserver:anon...@sourceware.org:/cvs/cygwin-apps, but the tarballs seem to be hosted on fruitbat.org at the moment. I think the best thing to do is to ask for that CVS to be migrated to git, Done: git clone git://sourceware.org/git/cygwin-cygutils.git Gitweb: https://sourceware.org/git/?p=cygwin-cygutils.git Mark, if you're going to maintain the project, you probably want to make changes to the git repo. For that you need ssh access to sourceware.org AKA cygwin.com. Pleae use the form at https://sourceware.org/cgi-bin/pdw/ps_form.cgi to request SSH access to sware. Project is "cygwin-apps", Use my email address for the approver field. then the cygport can be written to fetch the source directly from a specified tag in git, since this will avoid the need for you to make tarballs and work out where to host them. E.g. GIT_URI="git://cygwin.com/git/newlib-cygwin.git" GIT_TAG="..." This does seems like the best way to go, for several reasons. I've sent in the SSH access request form. Thanks much! ..mark
Questions on package adoption conventions
Q1: Does a new maintainer typically put out a new package version upon take-over, or can he/she run with the existing version number and just keep bumping the build number (e.g. for bug fixes)? Q2: Does the location hosting a test build for external review have to be the same location used to host final builds? Q3: What kind of external access is typically used for hosting final builds? I've run a micro-ISP that allowed on-request FTP access, by IP address, to customers, but have not needed to run anonymous FTP to this point. What about SSH/SFTP? Is there such a thing as anonymous SFTP? Does HTTP and/or HTTPS access need to be provided? Detailed suggestions for that last question would be welcomed. I'd like to make it least-hassle for reviewers and whatever a source install of my packages would require, but still keep the hosting machine as secured as can be managed. ..mark
Re: [ITA] cygutils
Corinna is climbing down the vaults to polish goldstars... Awarded! http://cygwin.com/goldstars/#MG A bit early, this one ;) Oops Want me to add a stinkbomb to offset, until he makes good? +1 motivational
