Re: calm now runs on-demand
On 01/07/2017 15:14, Marco Atzeri wrote: On 01/07/2017 15:54, Jon Turney wrote: On 01/07/2017 06:18, Marco Atzeri wrote: On 17/04/2017 13:34, Jon Turney wrote: If you have shell access on sourceware, and make such changes, you can force calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. Jon, I have shell access but I do not find calm anywhere. I assume "~cygwin-admin" is more restricted than shell access. As I did change to the relarea for gcc test, how to force the update of setup.ini's ? I think I have fixed the permissions, so this should work for you now. Thanks for pointing out this problem. May be I misunderstood how I should use it matzeri@sourceware ~ $ /home/cygwin/bin/calm scan-relarea /home/cygwin/bin/calm: line 13: kill: (14958) - Operation not permitted No, that's me being dumb. I guess I need to think some more about how to make this work for other users...
Re: calm now runs on-demand
On 01/07/2017 15:03, Achim Gratz wrote: Achim Gratz writes: Marco Atzeri writes: As I did change to the relarea for gcc test, how to force the update of setup.ini's ? I guess you can just open and close an sftp session, maybe providing new !ready cookies. No, this is not enough. calm doesn't re-read the release area for every maintainer upload, as this is relatively expensive and usually pointless (the contents usually haven't changed) I tried that, but got: ERROR: not processing uploads or writing setup.ini SUMMARY: 1 ERROR(s) Heh, not a very helpful error message :( Anyway, it looks like Jon is on now, so I assume he'll gets things off the ground again. A setup.ini with gcc test:6.3.0-2 has been generated now and should be mirroring out.
Re: calm now runs on-demand
On 01/07/2017 15:54, Jon Turney wrote: On 01/07/2017 06:18, Marco Atzeri wrote: On 17/04/2017 13:34, Jon Turney wrote: If you have shell access on sourceware, and make such changes, you can force calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. Jon, I have shell access but I do not find calm anywhere. I assume "~cygwin-admin" is more restricted than shell access. As I did change to the relarea for gcc test, how to force the update of setup.ini's ? I think I have fixed the permissions, so this should work for you now. Thanks for pointing out this problem. May be I misunderstood how I should use it matzeri@sourceware ~ $ /home/cygwin/bin/calm scan-relarea /home/cygwin/bin/calm: line 13: kill: (14958) - Operation not permitted $ /home/cygwin/bin/calm scan-uploads /home/cygwin/bin/calm: line 10: kill: (14958) - Operation not permitted
Re: calm now runs on-demand
On 01/07/2017 12:31, Andrew Schulman wrote: On Apr 17 12:34, Jon Turney wrote: I recently deployed an update to calm which should causes it to run on-demand after a maintainer SFTP upload. Hopefully this reduces the inconvenience of having to wait till the next scheduled run, after an upload is made which fails due to some easily correctable problem. calm continues to also run on a schedule at :10 and :40 past the hour, so it will still note changes which have been made directly on sourceware. If you have shell access on sourceware, and make such changes, you can force calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. Given that, it probably makes sense to consider reducing the frequency of scheduled runs. I have upload access, but AFAIK not shell access. I think most maintainers don't, unless that's changed. Correct. But unless you have shell access to make changes by directly moving files around on sourceware, you don't need shell access to run calm. Currently, calm runs (i) if a !ready file exists in your upload area when your sftp session closes, and (ii) at 00:10 UTC and every 4 hours thereafter.
Re: calm now runs on-demand
Achim Gratz writes: > Marco Atzeri writes: >> As I did change to the relarea for gcc test, how to force the >> update of setup.ini's ? > > I guess you can just open and close an sftp session, maybe providing new > !ready cookies. I tried that, but got: ERROR: not processing uploads or writing setup.ini SUMMARY: 1 ERROR(s) Anyway, it looks like Jon is on now, so I assume he'll gets things off the ground again. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: calm now runs on-demand
Marco Atzeri writes: > As I did change to the relarea for gcc test, how to force the > update of setup.ini's ? I guess you can just open and close an sftp session, maybe providing new !ready cookies. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: calm now runs on-demand
On 01/07/2017 06:18, Marco Atzeri wrote: On 17/04/2017 13:34, Jon Turney wrote: If you have shell access on sourceware, and make such changes, you can force calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. Jon, I have shell access but I do not find calm anywhere. I assume "~cygwin-admin" is more restricted than shell access. As I did change to the relarea for gcc test, how to force the update of setup.ini's ? I think I have fixed the permissions, so this should work for you now. Thanks for pointing out this problem.
Re: calm now runs on-demand
> On Apr 17 12:34, Jon Turney wrote: > > > > I recently deployed an update to calm which should causes it to run > > on-demand after a maintainer SFTP upload. > > > > Hopefully this reduces the inconvenience of having to wait till the next > > scheduled run, after an upload is made which fails due to some easily > > correctable problem. > > > > calm continues to also run on a schedule at :10 and :40 past the hour, so it > > will still note changes which have been made directly on sourceware. > > > > If you have shell access on sourceware, and make such changes, you can force > > calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. > > > > Given that, it probably makes sense to consider reducing the frequency of > > scheduled runs. I have upload access, but AFAIK not shell access. I think most maintainers don't, unless that's changed.
Re: libtool not finding /usr/lib/libintl.la or what?
On 01/07/2017 09:18, Mark Geisert wrote: 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 we should remove the not needed /usr/lib/*.la (not all) as we did from start on the 64bit version
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
Re: libtool not finding /usr/lib/libintl.la or what?
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 make[2]: Entering directory '/cygdrive/e/cyg_pub/temp/cygutils-1.4.15-2.src/cygutils-1.4.15-2.i686/build' CCLD src/banner/banner.exe CCLD src/clip/getclip.exe CCLD src/clip/putclip.exe CCLD src/cygstart/cygstart.exe CXXLDsrc/lpr/lpr.exe CCLD src/mkshortcut/mkshortcut.exe CCLD src/readshortcut/readshortcut.exe CCLD src/winln/winln.exe CCLD src/conv/conv.exe CCLD src/dump/dump.exe CCLD src/ipc/semtool.exe CCLD src/ipc/shmtool.exe CCLD src/ipc/msgtool.exe CCLD src/ipc/semstat.exe CXXLDsrc/cygdrop/cygdrop.exe make[2]: Leaving directory '/cygdrive/e/cyg_pub/temp/cygutils-1.4.15-2.src/cygutils-1.4.15-2.i686/build' make[1]: Leaving directory '/cygdrive/e/cyg_pub/temp/cygutils-1.4.15-2.src/cygutils-1.4.15-2.i686/build'
