Re: cygport pkg pkg_info:__list_deps() xargs: cannot fit single argument within argument list size limit
Hi again :), On Sun, 29 Dec 2024, Brian Inglis via Cygwin-apps wrote: On 2024-12-28 17:56, Mark Geisert via Cygwin-apps wrote: Hi Brian, On Sat, 28 Dec 2024, Brian Inglis via Cygwin-apps wrote: Hi folks, Packaging bash-completion I noticed during cygport pkg running pkg_info:__list_deps() (I think) produces the error message: xargs: cannot fit single argument within argument list size limit but does not stop the build or affect the results as far as I can see. The scallywag noarch build log for 9116 showing the error message is: https://github.com/cygwin/scallywag/actions/runs/12529311037/job/34944818784 I have attached the cygport --debug pkg.log as I can not spot which arg is causing xargs to fail when trying to find requires for bash-completion binary subpackage. Hopefully if someone else has some time over the holidays they can see what I have failed to narrow in on. I copy/pasted the pkg.log into a temp file and took a look with vim. (I assume Firefox is not truncating the lines...) Starting at the line with the "xargs:" error I backed up a few lines. The line starting with "echo" is 58029 chars long. It has many many duplicate strings in it, FWIW. The line starting with "xargs" is 28836 chars long. It, too, has many many duplicate arg strings in it, though they do start with '^' and end with '$' as reasonable for -e arg strings. I'm not enough of a shell debugging guy to know which line-expressions are pipe starters or pipe members, so that's as far as I can go. Thanks Mark, That's where I'm at too - but there are sort -u commands which should eliminate the duplicates!? [...useful info about arg size limits elided...] Ah, in that case the problem seems to be that 'sort' is being handed a single line by 'echo'. There needs to be something added to the pipe expression to split the 'echo' result at ' ' chars. Something like: tr ' ' '\n' Then 'sort -u' cuts the number of arg strings from 530 down to 110. ..mark
Re: cygport pkg pkg_info:__list_deps() xargs: cannot fit single argument within argument list size limit
I dug into xargs with gdb and found that its maximum arg size is 24215. This despite its man page (describing the '-s' option) saying the default is 128Kib. You could try using '-s 65536' or some larger number to avoid the error xargs is reporting in your test case. HTH, ..mark
Re: cygport pkg pkg_info:__list_deps() xargs: cannot fit single argument within argument list size limit
Hi Brian, On Sat, 28 Dec 2024, Brian Inglis via Cygwin-apps wrote: Hi folks, Packaging bash-completion I noticed during cygport pkg running pkg_info:__list_deps() (I think) produces the error message: xargs: cannot fit single argument within argument list size limit but does not stop the build or affect the results as far as I can see. The scallywag noarch build log for 9116 showing the error message is: https://github.com/cygwin/scallywag/actions/runs/12529311037/job/34944818784 I have attached the cygport --debug pkg.log as I can not spot which arg is causing xargs to fail when trying to find requires for bash-completion binary subpackage. Hopefully if someone else has some time over the holidays they can see what I have failed to narrow in on. I copy/pasted the pkg.log into a temp file and took a look with vim. (I assume Firefox is not truncating the lines...) Starting at the line with the "xargs:" error I backed up a few lines. The line starting with "echo" is 58029 chars long. It has many many duplicate strings in it, FWIW. The line starting with "xargs" is 28836 chars long. It, too, has many many duplicate arg strings in it, though they do start with '^' and end with '$' as reasonable for -e arg strings. I'm not enough of a shell debugging guy to know which line-expressions are pipe starters or pipe members, so that's as far as I can go. HTH, ..mark
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
