You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@serf.apache.org by Daniel Sahlberg <da...@gmail.com> on 2025/06/01 14:31:02 UTC
Github Actions notifications
Hi,
I like the e-mail notifications from GitHub Actions when a build fails or
when it starts to work again - saves some time from going into the website
to check status.
Should we enable this for Serf?
Should it go to dev@ or should we create a separate notifications@ list?
I presume the safe path would be to just create a separate mailing list and
add notifications there, but maybe there is not really need for a separate
list?
Cheers,
Daniel
Re: Github Actions notifications
Posted by Branko Čibej <br...@apache.org>.
On 5. 6. 25 23:14, Daniel Sahlberg wrote:
> tors 5 juni 2025 kl. 23:03 skrev Branko Čibej <br...@apache.org>:
>
> On 5. 6. 25 22:27, Daniel Sahlberg wrote:
> > Den sön 1 juni 2025 kl 19:39 skrev Nathan Hartman
> <hartman.nathan@gmail.com
> >> :
> >> On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
> >> daniel.l.sahlberg@gmail.com> wrote:
> >>
> >>> Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
> >>> daniel.l.sahlberg@gmail.com>:
> >>>
> >>>> Hi,
> >>>>
> >>>> I like the e-mail notifications from GitHub Actions when a
> build fails
> >>> or
> >>>> when it starts to work again - saves some time from going
> into the
> >>> website
> >>>> to check status.
> >>>>
> >>>> Should we enable this for Serf?
> >>>>
> >>>> Should it go to dev@ or should we create a separate
> notifications@
> >>> list?
> >>>> I presume the safe path would be to just create a separate
> mailing list
> >>>> and add notifications there, but maybe there is not really
> need for a
> >>>> separate list?
> >>>>
> >>> Oh, there IS a notifications@ list already, see
> >>> https://lists.apache.org/list?notifications@serf.apache.org.
> It was last
> >>> used in 2020 by BuildBot (I assume it was never migrated to
> the new
> >>> ci2.apache.org <http://ci2.apache.org>, can't find Serf
> there). The list has TWO subscribers
> >>> (actually: three, since I just joined) so I assume there is
> little harm in
> >>> setting up notifications to that list.
> >>>
> >>> I'm going to assume lazy consensus to do this, if no replies
> within the
> >>> next 72 hours (although it may take longer than that).
> >>
> >>
> >> +1 for this, similarly to how we've done for Subversion. Since
> most/all
> >> (?) of the Serf devs are also Subversion devs, there's an
> advantage in
> >> being consistent!
> >>
> > I went ahead with this.First notification was received earlier
> tonight [1].
> >
> > For the record, this is controlled by the ghactions.py script in ASF
> > Infra's git repo infrastructure-gha-notifier[2]. I made a pull
> request
> > which was kindly merged by Humbedooh [3].
> >
> > Feel free to subscribe tonotifications@serf.apache.org if you
> want to
> > receive those notifications.
>
> Regarding the current state of GitHub actions:
>
> * Windows x86 (32-bit) CMake builds are failing and I have
> absolutely
> no idea why. The last output is during the build, says "Generating
> code...", then exits. No diagnostics, nothing.
>
>
> @Timofei, any ideas?
>
> I also noted that it seems to download and build OpenSSL from source,
> taking quite a bit of time. Is it possible to install a binary version
> from vcpkg?
>
>
> * Linux CMake builds are generally passing, although I just noticed
> that builders running Ubuntu 24.04 don't even start. Again, no
> idea why.
>
>
> I can try to look at this, comparing with Subversion.
>
>
> * Linux SCons builds are failing. Something happened in SCons
> 4.x that
> made the feature checks in OpenSSL mostly fail, killing the
> build. I
> have a working build with SCons 4.7+, but the builders have SCons
> 4.0 or 4.1. I haven't had time to debug that, but I do have a VM
> running Debian 12 now.
>
> I don't have the bandwidth (or, quite frankly, the motivation) to
> chase
> down the Windows x86 bug. I'll try to get SCons up and running
> again on
> Debian.
>
> -- Brane
>
> P.S.: I've built a FreeBSD VM and got the CMake build running there.
> Working on OpenBSD now, then I think I'll have more development
> platforms than I know what to do with... someone else can try AIX and
> HP-UX and Solaris (pardon me, Oracle Unix) and the Red Hat variants.
>
>
> I have a Sun SPARC box running one of the later Solaris 10 releases
> but I’m not sure if I have the bandwidth to work on it. Last time I
> tried it failed with too old dependencies.
Yes, that could be a problem. We pretty much require OpenSSL 1.1.1 or
3.x, things like that would probably have to be installed manually.
-- Brane
Re: Github Actions notifications
Posted by Branko Čibej <br...@apache.org>.
On 6. 6. 25 21:14, Branko Čibej wrote:
> On 6. 6. 25 17:50, Timofei Zhakov wrote:
>
>> But the thing is in the workflow, there is nothing can tell cmake to
>> switch
>> the platform to x86 (cmake defaults the Visual Studio generator to x64
>> platform). Meaning that x64 compiler tries to link it against x86
>> libraries.
>>
>> The simplest way to fix the problem is to pass this extra argument:
>> `-DCMAKE_GENERATOR_PLATFORM=Win32` to cmake, so it could use the
>> proper platform.
>
> We'd have to split the current single YAML into two. Also, this being
> MSBuild, CMAKE_BUILD_TYPE doesn't actually mean anything to the
> generator, and we could run both debug and release builds in a single
> script, saving half of the time spent on fetching dependencies.
I just successfully built and ran tests on Windows, cross-compiled
ARM64->x86, using your suggestion to force CMake to use the Win32
platform. So, indeed, that works!
(One test failed, with a different error code than expected; that's a
minor issue.)
-- Brane
Re: Github Actions notifications
Posted by Branko Čibej <br...@apache.org>.
On 6. 6. 25 17:50, Timofei Zhakov wrote:
>>> Regarding the current state of GitHub actions:
>>>
>>> * Windows x86 (32-bit) CMake builds are failing and I have absolutely
>>> no idea why. The last output is during the build, says "Generating
>>> code...", then exits. No diagnostics, nothing.
>>
>> @Timofei, any ideas?
>>
>>
> I think I have figured this out.
>
> First, maybe you didn't notice that, but it fails when
> buckets\ssl_buckets.c is being built (scroll up the logs a little bit). By
> the way, I don't know why it doesn't inta-fail the build.
It says "fail-fast: false" in the YAML file, that might be it, or not;
MSBuild is strange about that.
Ah, so I'm blind. Yes, the OpenSSL feature tests are failing -- just as
they are in the SCons build, but for different reasons. In this case
it's probably actually a 64bit/32bit mismatch with the OpenSSL
libraries, as you say below.
> So, this workflow is using Visual Studio generate (generate vcxproj files),
> meaning it determines compiler and environment on its own like an average
> Visual Studio project. On the other hand, Ninja is just a set of rules, so
> cmake will need to find a compiler and pass it to the build files on
> its own.
Well, this is how Ivan set up the Windows build for GitHub, I hadn't
even thought about about that we're actually cross-compiling here. Or
should be.
> But the thing is in the workflow, there is nothing can tell cmake to switch
> the platform to x86 (cmake defaults the Visual Studio generator to x64
> platform). Meaning that x64 compiler tries to link it against x86
> libraries.
>
> The simplest way to fix the problem is to pass this extra argument:
> `-DCMAKE_GENERATOR_PLATFORM=Win32` to cmake, so it could use the
> proper platform.
We'd have to split the current single YAML into two. Also, this being
MSBuild, CMAKE_BUILD_TYPE doesn't actually mean anything to the
generator, and we could run both debug and release builds in a single
script, saving half of the time spent on fetching dependencies.
> However, unrelatedly to the original problem, it's much better to use the
> Ninja generator in build scripts, since it's faster, more reliable,
> simpler, and more customisable in terms of platforms and architectures. It
> could be complicated to set up, but I've done it for Subversion, so I can
> do it for Serf as well.
It's just "pip install Ninja" and passing "-G Ninja" to cmake, more or
less. Ninja is a Python package. but we don't have Python on the
builders, that could be added, though. The "other" issue is getting it
to find the right toolchain.
> I also noted that it seems to download and build OpenSSL from source,
>> taking quite a bit of time. Is it possible to install a binary version from
>> vcpkg?
>>
>>
> It seems like they deprecated github actions binary caching:
>
> [[[
> %VCPKG_BINARY_SOURCES%: warning: The 'x-gha' binary caching backend has
> been removed. Consider using a NuGet-based binary caching provider instead,
> see extended documentation at
> https://learn.microsoft.com/vcpkg/users/binarycaching?WT.mc_id=vcpkg_inproduct_cli.
> on expression: clear;x-gha,readwrite
> ]]]
>
> I have no clue what to do then. And why have they even done that, since it
> was working well...
It probably wasn't working as well as you'd imagine, maintaining such a
cache is not trivial. However, it appears that GitHub has a solution:
https://github.com/actions/cache
#notapriority
-- Brane
Re: Github Actions notifications
Posted by Timofei Zhakov <ti...@chemodax.net>.
>
> > Regarding the current state of GitHub actions:
> >
> > * Windows x86 (32-bit) CMake builds are failing and I have absolutely
> > no idea why. The last output is during the build, says "Generating
> > code...", then exits. No diagnostics, nothing.
>
>
> @Timofei, any ideas?
>
>
I think I have figured this out.
First, maybe you didn't notice that, but it fails when
buckets\ssl_buckets.c is being built (scroll up the logs a little bit). By
the way, I don't know why it doesn't inta-fail the build.
So, this workflow is using Visual Studio generate (generate vcxproj files),
meaning it determines compiler and environment on its own like an average
Visual Studio project. On the other hand, Ninja is just a set of rules, so
cmake will need to find a compiler and pass it to the build files on
its own.
But the thing is in the workflow, there is nothing can tell cmake to switch
the platform to x86 (cmake defaults the Visual Studio generator to x64
platform). Meaning that x64 compiler tries to link it against x86
libraries.
The simplest way to fix the problem is to pass this extra argument:
`-DCMAKE_GENERATOR_PLATFORM=Win32` to cmake, so it could use the
proper platform.
However, unrelatedly to the original problem, it's much better to use the
Ninja generator in build scripts, since it's faster, more reliable,
simpler, and more customisable in terms of platforms and architectures. It
could be complicated to set up, but I've done it for Subversion, so I can
do it for Serf as well.
I also noted that it seems to download and build OpenSSL from source,
> taking quite a bit of time. Is it possible to install a binary version from
> vcpkg?
>
>
It seems like they deprecated github actions binary caching:
[[[
%VCPKG_BINARY_SOURCES%: warning: The 'x-gha' binary caching backend has
been removed. Consider using a NuGet-based binary caching provider instead,
see extended documentation at
https://learn.microsoft.com/vcpkg/users/binarycaching?WT.mc_id=vcpkg_inproduct_cli.
on expression: clear;x-gha,readwrite
]]]
I have no clue what to do then. And why have they even done that, since it
was working well...
--
Timofei Zhakov
Re: Github Actions notifications
Posted by Daniel Sahlberg <da...@gmail.com>.
tors 5 juni 2025 kl. 23:03 skrev Branko Čibej <br...@apache.org>:
> On 5. 6. 25 22:27, Daniel Sahlberg wrote:
> > Den sön 1 juni 2025 kl 19:39 skrev Nathan Hartman <
> hartman.nathan@gmail.com
> >> :
> >> On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
> >> daniel.l.sahlberg@gmail.com> wrote:
> >>
> >>> Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
> >>> daniel.l.sahlberg@gmail.com>:
> >>>
> >>>> Hi,
> >>>>
> >>>> I like the e-mail notifications from GitHub Actions when a build fails
> >>> or
> >>>> when it starts to work again - saves some time from going into the
> >>> website
> >>>> to check status.
> >>>>
> >>>> Should we enable this for Serf?
> >>>>
> >>>> Should it go to dev@ or should we create a separate notifications@
> >>> list?
> >>>> I presume the safe path would be to just create a separate mailing
> list
> >>>> and add notifications there, but maybe there is not really need for a
> >>>> separate list?
> >>>>
> >>> Oh, there IS a notifications@ list already, see
> >>> https://lists.apache.org/list?notifications@serf.apache.org. It was
> last
> >>> used in 2020 by BuildBot (I assume it was never migrated to the new
> >>> ci2.apache.org, can't find Serf there). The list has TWO subscribers
> >>> (actually: three, since I just joined) so I assume there is little
> harm in
> >>> setting up notifications to that list.
> >>>
> >>> I'm going to assume lazy consensus to do this, if no replies within the
> >>> next 72 hours (although it may take longer than that).
> >>
> >>
> >> +1 for this, similarly to how we've done for Subversion. Since most/all
> >> (?) of the Serf devs are also Subversion devs, there's an advantage in
> >> being consistent!
> >>
> > I went ahead with this.First notification was received earlier tonight
> [1].
> >
> > For the record, this is controlled by the ghactions.py script in ASF
> > Infra's git repo infrastructure-gha-notifier[2]. I made a pull request
> > which was kindly merged by Humbedooh [3].
> >
> > Feel free to subscribe tonotifications@serf.apache.org if you want to
> > receive those notifications.
>
> Regarding the current state of GitHub actions:
>
> * Windows x86 (32-bit) CMake builds are failing and I have absolutely
> no idea why. The last output is during the build, says "Generating
> code...", then exits. No diagnostics, nothing.
@Timofei, any ideas?
I also noted that it seems to download and build OpenSSL from source,
taking quite a bit of time. Is it possible to install a binary version from
vcpkg?
> * Linux CMake builds are generally passing, although I just noticed
> that builders running Ubuntu 24.04 don't even start. Again, no idea
> why.
I can try to look at this, comparing with Subversion.
> * Linux SCons builds are failing. Something happened in SCons 4.x that
> made the feature checks in OpenSSL mostly fail, killing the build. I
> have a working build with SCons 4.7+, but the builders have SCons
> 4.0 or 4.1. I haven't had time to debug that, but I do have a VM
> running Debian 12 now.
>
> I don't have the bandwidth (or, quite frankly, the motivation) to chase
> down the Windows x86 bug. I'll try to get SCons up and running again on
> Debian.
>
> -- Brane
>
> P.S.: I've built a FreeBSD VM and got the CMake build running there.
> Working on OpenBSD now, then I think I'll have more development
> platforms than I know what to do with... someone else can try AIX and
> HP-UX and Solaris (pardon me, Oracle Unix) and the Red Hat variants.
I have a Sun SPARC box running one of the later Solaris 10 releases but I’m
not sure if I have the bandwidth to work on it. Last time I tried it failed
with too old dependencies.
Cheers
Daniel
Re: Github Actions notifications
Posted by Daniel Sahlberg <da...@gmail.com>.
lör 7 juni 2025 kl. 01:57 skrev Branko Čibej <br...@apache.org>:
> On 5. 6. 25 23:02, Branko Čibej wrote:
> > On 5. 6. 25 22:27, Daniel Sahlberg wrote:
> >> Den sön 1 juni 2025 kl 19:39 skrev Nathan Hartman
> >> <hartman.nathan@gmail.com
> >>> :
> >>> On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
> >>> daniel.l.sahlberg@gmail.com> wrote:
> >>>
> >>>> Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
> >>>> daniel.l.sahlberg@gmail.com>:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I like the e-mail notifications from GitHub Actions when a build
> >>>>> fails
> >>>> or
> >>>>> when it starts to work again - saves some time from going into the
> >>>> website
> >>>>> to check status.
> >>>>>
> >>>>> Should we enable this for Serf?
> >>>>>
> >>>>> Should it go to dev@ or should we create a separate notifications@
> >>>> list?
> >>>>> I presume the safe path would be to just create a separate mailing
> >>>>> list
> >>>>> and add notifications there, but maybe there is not really need for a
> >>>>> separate list?
> >>>>>
> >>>> Oh, there IS a notifications@ list already, see
> >>>> https://lists.apache.org/list?notifications@serf.apache.org. It was
> >>>> last
> >>>> used in 2020 by BuildBot (I assume it was never migrated to the new
> >>>> ci2.apache.org, can't find Serf there). The list has TWO subscribers
> >>>> (actually: three, since I just joined) so I assume there is little
> >>>> harm in
> >>>> setting up notifications to that list.
> >>>>
> >>>> I'm going to assume lazy consensus to do this, if no replies within
> >>>> the
> >>>> next 72 hours (although it may take longer than that).
> >>>
> >>>
> >>> +1 for this, similarly to how we've done for Subversion. Since most/all
> >>> (?) of the Serf devs are also Subversion devs, there's an advantage in
> >>> being consistent!
> >>>
> >> I went ahead with this.First notification was received earlier
> >> tonight [1].
> >>
> >> For the record, this is controlled by the ghactions.py script in ASF
> >> Infra's git repo infrastructure-gha-notifier[2]. I made a pull request
> >> which was kindly merged by Humbedooh [3].
> >>
> >> Feel free to subscribe tonotifications@serf.apache.org if you want to
> >> receive those notifications.
> >
> > Regarding the current state of GitHub actions:
> >
> > * Windows x86 (32-bit) CMake builds are failing and I have absolutely
> > no idea why. The last output is during the build, says "Generating
> > code...", then exits. No diagnostics, nothing.
>
> The Windows builds are working now. Setting the target platform, as Tima
> suggested, does work, for both x64 and x86 builds.
>
> One more thing we can do is to reduce the size of the Windows matrix
> from 4 to 2: as things stand now, a single CMake configuration can
> produce both debug and release builds on Windows. We could reduce the
> time spent on building dependencies by combining debug and release.
+1 if we can reduce complexity.
>
> Or we could enable binary caching again, bit that involves messing with
> NuGet and setting up our own cache (on GitHub), and I'm not going to do
> that; I've other things on my plate.
It seems overly complicated right now.
Cheers
Daniel
Re: Github Actions notifications
Posted by Branko Čibej <br...@apache.org>.
On 5. 6. 25 23:02, Branko Čibej wrote:
> On 5. 6. 25 22:27, Daniel Sahlberg wrote:
>> Den sön 1 juni 2025 kl 19:39 skrev Nathan Hartman
>> <hartman.nathan@gmail.com
>>> :
>>> On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
>>> daniel.l.sahlberg@gmail.com> wrote:
>>>
>>>> Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
>>>> daniel.l.sahlberg@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I like the e-mail notifications from GitHub Actions when a build
>>>>> fails
>>>> or
>>>>> when it starts to work again - saves some time from going into the
>>>> website
>>>>> to check status.
>>>>>
>>>>> Should we enable this for Serf?
>>>>>
>>>>> Should it go to dev@ or should we create a separate notifications@
>>>> list?
>>>>> I presume the safe path would be to just create a separate mailing
>>>>> list
>>>>> and add notifications there, but maybe there is not really need for a
>>>>> separate list?
>>>>>
>>>> Oh, there IS a notifications@ list already, see
>>>> https://lists.apache.org/list?notifications@serf.apache.org. It was
>>>> last
>>>> used in 2020 by BuildBot (I assume it was never migrated to the new
>>>> ci2.apache.org, can't find Serf there). The list has TWO subscribers
>>>> (actually: three, since I just joined) so I assume there is little
>>>> harm in
>>>> setting up notifications to that list.
>>>>
>>>> I'm going to assume lazy consensus to do this, if no replies within
>>>> the
>>>> next 72 hours (although it may take longer than that).
>>>
>>>
>>> +1 for this, similarly to how we've done for Subversion. Since most/all
>>> (?) of the Serf devs are also Subversion devs, there's an advantage in
>>> being consistent!
>>>
>> I went ahead with this.First notification was received earlier
>> tonight [1].
>>
>> For the record, this is controlled by the ghactions.py script in ASF
>> Infra's git repo infrastructure-gha-notifier[2]. I made a pull request
>> which was kindly merged by Humbedooh [3].
>>
>> Feel free to subscribe tonotifications@serf.apache.org if you want to
>> receive those notifications.
>
> Regarding the current state of GitHub actions:
>
> * Windows x86 (32-bit) CMake builds are failing and I have absolutely
> no idea why. The last output is during the build, says "Generating
> code...", then exits. No diagnostics, nothing.
The Windows builds are working now. Setting the target platform, as Tima
suggested, does work, for both x64 and x86 builds.
One more thing we can do is to reduce the size of the Windows matrix
from 4 to 2: as things stand now, a single CMake configuration can
produce both debug and release builds on Windows. We could reduce the
time spent on building dependencies by combining debug and release.
Or we could enable binary caching again, bit that involves messing with
NuGet and setting up our own cache (on GitHub), and I'm not going to do
that; I've other things on my plate.
-- Brane
Re: Github Actions notifications
Posted by Branko Čibej <br...@apache.org>.
On 5. 6. 25 23:02, Branko Čibej wrote:
> * Linux SCons builds are failing. Something happened in SCons 4.x that
> made the feature checks in OpenSSL mostly fail, killing the build. I
> have a working build with SCons 4.7+, but the builders have SCons
> 4.0 or 4.1. I haven't had time to debug that, but I do have a VM
> running Debian 12 now.
And done. Fixed all the way back to SCons 2.3.0 with Python 2.7 -- now
anyone can build Serf on an old AIX box that hasn't been upgraded in 15
years. :)
-- Brane
Re: Github Actions notifications
Posted by Branko Čibej <br...@apache.org>.
On 5. 6. 25 22:27, Daniel Sahlberg wrote:
> Den sön 1 juni 2025 kl 19:39 skrev Nathan Hartman <hartman.nathan@gmail.com
>> :
>> On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
>> daniel.l.sahlberg@gmail.com> wrote:
>>
>>> Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
>>> daniel.l.sahlberg@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I like the e-mail notifications from GitHub Actions when a build fails
>>> or
>>>> when it starts to work again - saves some time from going into the
>>> website
>>>> to check status.
>>>>
>>>> Should we enable this for Serf?
>>>>
>>>> Should it go to dev@ or should we create a separate notifications@
>>> list?
>>>> I presume the safe path would be to just create a separate mailing list
>>>> and add notifications there, but maybe there is not really need for a
>>>> separate list?
>>>>
>>> Oh, there IS a notifications@ list already, see
>>> https://lists.apache.org/list?notifications@serf.apache.org. It was last
>>> used in 2020 by BuildBot (I assume it was never migrated to the new
>>> ci2.apache.org, can't find Serf there). The list has TWO subscribers
>>> (actually: three, since I just joined) so I assume there is little harm in
>>> setting up notifications to that list.
>>>
>>> I'm going to assume lazy consensus to do this, if no replies within the
>>> next 72 hours (although it may take longer than that).
>>
>>
>> +1 for this, similarly to how we've done for Subversion. Since most/all
>> (?) of the Serf devs are also Subversion devs, there's an advantage in
>> being consistent!
>>
> I went ahead with this.First notification was received earlier tonight [1].
>
> For the record, this is controlled by the ghactions.py script in ASF
> Infra's git repo infrastructure-gha-notifier[2]. I made a pull request
> which was kindly merged by Humbedooh [3].
>
> Feel free to subscribe tonotifications@serf.apache.org if you want to
> receive those notifications.
Regarding the current state of GitHub actions:
* Windows x86 (32-bit) CMake builds are failing and I have absolutely
no idea why. The last output is during the build, says "Generating
code...", then exits. No diagnostics, nothing.
* Linux CMake builds are generally passing, although I just noticed
that builders running Ubuntu 24.04 don't even start. Again, no idea why.
* Linux SCons builds are failing. Something happened in SCons 4.x that
made the feature checks in OpenSSL mostly fail, killing the build. I
have a working build with SCons 4.7+, but the builders have SCons
4.0 or 4.1. I haven't had time to debug that, but I do have a VM
running Debian 12 now.
I don't have the bandwidth (or, quite frankly, the motivation) to chase
down the Windows x86 bug. I'll try to get SCons up and running again on
Debian.
-- Brane
P.S.: I've built a FreeBSD VM and got the CMake build running there.
Working on OpenBSD now, then I think I'll have more development
platforms than I know what to do with... someone else can try AIX and
HP-UX and Solaris (pardon me, Oracle Unix) and the Red Hat variants.
Or not. *shrug*
Re: Github Actions notifications
Posted by Daniel Sahlberg <da...@gmail.com>.
Den sön 1 juni 2025 kl 19:39 skrev Nathan Hartman <hartman.nathan@gmail.com
>:
> On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
> daniel.l.sahlberg@gmail.com> wrote:
>
>> Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
>> daniel.l.sahlberg@gmail.com>:
>>
>> > Hi,
>> >
>> > I like the e-mail notifications from GitHub Actions when a build fails
>> or
>> > when it starts to work again - saves some time from going into the
>> website
>> > to check status.
>> >
>> > Should we enable this for Serf?
>> >
>> > Should it go to dev@ or should we create a separate notifications@
>> list?
>> >
>> > I presume the safe path would be to just create a separate mailing list
>> > and add notifications there, but maybe there is not really need for a
>> > separate list?
>> >
>>
>> Oh, there IS a notifications@ list already, see
>> https://lists.apache.org/list?notifications@serf.apache.org. It was last
>> used in 2020 by BuildBot (I assume it was never migrated to the new
>> ci2.apache.org, can't find Serf there). The list has TWO subscribers
>> (actually: three, since I just joined) so I assume there is little harm in
>> setting up notifications to that list.
>>
>> I'm going to assume lazy consensus to do this, if no replies within the
>> next 72 hours (although it may take longer than that).
>
>
>
> +1 for this, similarly to how we've done for Subversion. Since most/all
> (?) of the Serf devs are also Subversion devs, there's an advantage in
> being consistent!
>
I went ahead with this.First notification was received earlier tonight [1].
For the record, this is controlled by the ghactions.py script in ASF
Infra's git repo infrastructure-gha-notifier[2]. I made a pull request
which was kindly merged by Humbedooh [3].
Feel free to subscribe to notifications@serf.apache.org if you want to
receive those notifications.
Cheers,
Daniel
1: https://lists.apache.org/thread/w45rgbr5fk1m3zbv8hl9p8c3y9osrlm9
2: https://github.com/apache/infrastructure-gha-notifier
3:
https://github.com/apache/infrastructure-gha-notifier/commit/4c4416bd1ee49442b0f8105433e17d5ef90d583a
Re: Github Actions notifications
Posted by Branko Čibej <br...@apache.org>.
On 1. 6. 25 23:15, Timofei Zhakov wrote:
> On Sun, 01 Jun 2025 at 7:39 PM, Nathan Hartman<ha...@gmail.com>
> wrote:
>
>> On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
>> daniel.l.sahlberg@gmail.com>
>> wrote:
>>
>>> Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
>>> daniel.l.sahlberg@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I like the e-mail notifications from GitHub Actions when a build fails
>> or
>>>> when it starts to work again - saves some time from going into the
>>> website
>>>> to check status.
>>>>
>>>> Should we enable this for Serf?
>>>>
>>>> Should it go to dev@ or should we create a separate notifications@
>> list?
>>>> I presume the safe path would be to just create a separate mailing list
>>>> and add notifications there, but maybe there is not really need for a
>>>> separate list?
>>>>
>>> Oh, there IS a notifications@ list already, see
>>> https://lists.apache.org/list?notifications@serf.apache.org. It was last
>>> used in 2020 by BuildBot (I assume it was never migrated to the new
>>> ci2.apache.org, can't find Serf there). The list has TWO subscribers
>>> (actually: three, since I just joined) so I assume there is little harm
>> in
>>> setting up notifications to that list.
>>>
>>> I'm going to assume lazy consensus to do this, if no replies within the
>>> next 72 hours (although it may take longer than that).
>>
>>
>> +1 for this, similarly to how we've done for Subversion. Since most/all (?)
>> of the Serf devs are also Subversion devs, there's an advantage in being
>> consistent!
>>
>>
>> I'm also going to do a website change to document this list - I will do it
>>> as soon as time permits, easy to revert if we decide this list is not
>>> useful.
>>
>>
>> Thanks for taking care of this.
>>
>> Cheers,
>> Nathan
>
> Also, in relation to this topic, in subversion we have separate mailing
> lists for commits and dev. This is very useful to setup filters in mail
> client and for example read one list more frequently than another. Would
> this make sense to somehow separate those lists in serf as well?
There was almost never enough traffic on this list to warrant having
another one. Filtering should be quite straight-forward, too: "contains
'svn commit: r'" would work.
-- Brane
Re: Github Actions notifications
Posted by Timofei Zhakov <ti...@chemodax.net>.
On Sun, 01 Jun 2025 at 7:39 PM, Nathan Hartman <ha...@gmail.com>
wrote:
> On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
> daniel.l.sahlberg@gmail.com>
> wrote:
>
> > Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
> > daniel.l.sahlberg@gmail.com>:
> >
> > > Hi,
> > >
> > > I like the e-mail notifications from GitHub Actions when a build fails
> or
> > > when it starts to work again - saves some time from going into the
> > website
> > > to check status.
> > >
> > > Should we enable this for Serf?
> > >
> > > Should it go to dev@ or should we create a separate notifications@
> list?
> > >
> > > I presume the safe path would be to just create a separate mailing list
> > > and add notifications there, but maybe there is not really need for a
> > > separate list?
> > >
> >
> > Oh, there IS a notifications@ list already, see
> > https://lists.apache.org/list?notifications@serf.apache.org. It was last
> > used in 2020 by BuildBot (I assume it was never migrated to the new
> > ci2.apache.org, can't find Serf there). The list has TWO subscribers
> > (actually: three, since I just joined) so I assume there is little harm
> in
> > setting up notifications to that list.
> >
> > I'm going to assume lazy consensus to do this, if no replies within the
> > next 72 hours (although it may take longer than that).
>
>
>
> +1 for this, similarly to how we've done for Subversion. Since most/all (?)
> of the Serf devs are also Subversion devs, there's an advantage in being
> consistent!
>
>
> I'm also going to do a website change to document this list - I will do it
> > as soon as time permits, easy to revert if we decide this list is not
> > useful.
>
>
>
> Thanks for taking care of this.
>
> Cheers,
> Nathan
Also, in relation to this topic, in subversion we have separate mailing
lists for commits and dev. This is very useful to setup filters in mail
client and for example read one list more frequently than another. Would
this make sense to somehow separate those lists in serf as well?
Re: Github Actions notifications
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <da...@gmail.com>
wrote:
> Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
> daniel.l.sahlberg@gmail.com>:
>
> > Hi,
> >
> > I like the e-mail notifications from GitHub Actions when a build fails or
> > when it starts to work again - saves some time from going into the
> website
> > to check status.
> >
> > Should we enable this for Serf?
> >
> > Should it go to dev@ or should we create a separate notifications@ list?
> >
> > I presume the safe path would be to just create a separate mailing list
> > and add notifications there, but maybe there is not really need for a
> > separate list?
> >
>
> Oh, there IS a notifications@ list already, see
> https://lists.apache.org/list?notifications@serf.apache.org. It was last
> used in 2020 by BuildBot (I assume it was never migrated to the new
> ci2.apache.org, can't find Serf there). The list has TWO subscribers
> (actually: three, since I just joined) so I assume there is little harm in
> setting up notifications to that list.
>
> I'm going to assume lazy consensus to do this, if no replies within the
> next 72 hours (although it may take longer than that).
+1 for this, similarly to how we've done for Subversion. Since most/all (?)
of the Serf devs are also Subversion devs, there's an advantage in being
consistent!
I'm also going to do a website change to document this list - I will do it
> as soon as time permits, easy to revert if we decide this list is not
> useful.
Thanks for taking care of this.
Cheers,
Nathan
Re: Github Actions notifications
Posted by Daniel Sahlberg <da...@gmail.com>.
Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
daniel.l.sahlberg@gmail.com>:
> Hi,
>
> I like the e-mail notifications from GitHub Actions when a build fails or
> when it starts to work again - saves some time from going into the website
> to check status.
>
> Should we enable this for Serf?
>
> Should it go to dev@ or should we create a separate notifications@ list?
>
> I presume the safe path would be to just create a separate mailing list
> and add notifications there, but maybe there is not really need for a
> separate list?
>
Oh, there IS a notifications@ list already, see
https://lists.apache.org/list?notifications@serf.apache.org. It was last
used in 2020 by BuildBot (I assume it was never migrated to the new
ci2.apache.org, can't find Serf there). The list has TWO subscribers
(actually: three, since I just joined) so I assume there is little harm in
setting up notifications to that list.
I'm going to assume lazy consensus to do this, if no replies within the
next 72 hours (although it may take longer than that).
I'm also going to do a website change to document this list - I will do it
as soon as time permits, easy to revert if we decide this list is not
useful.
Cheers,
Daniel