#11687 notofications do not notify
Opened 4 months ago by vondruch. Modified a day ago

The old notifications app was decommissioned, while the new app does not notify about "anything", therefore it is not useful. Is that going to change?

E.g. I am member of ruby-packagers-sig group, therefore I should have been notified about https://src.fedoraproject.org/rpms/rubygem-actionview/c/3e3f8c83f6b24e4c50991e1dcc77334eabcb1a90?branch=rawhide

The only notifications I receive from src.fedoraproject.org are about pushes into forks, but that is not useful at all.

I don't receive any notifications from Koschei.

I don't receive any notifications from Anitya.

And on top of that, I can't be sure I have the notifications configure properly, because there is not any help, nor the UI would provide any feedback about what I am about to set up.


Metadata Update from @phsmoura:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: medium-gain, medium-trouble, ops

4 months ago

I think it may be because you don't have a rule for the ruby-packagers-sig, only for things related to your username. I would recommend adding such a rule. It's a separate tracking rule because some groups are noisy and people may want to have only a subset of their groups send notifications.

This is linked to an issue 900 in FMN about creating a default set of rules for new (and migrating) users. It's a bit old and I don't think we've come to a conclusion of what this default set should be. Then we'll need time to write the hook that will edit rules on new user creation, addition to groups, removal from groups, etc. Not a quick fix.

You should be getting messages from Anitya already (unless they're for a group, then you should get them when you add the group rule).

Koschei events need a small change in the Koschei deployment, it's tracked as issue 915.

We'd be happy about any suggestions on how the UI would provide better feedback about what is being set up. I've implemented suggested UI changes recently, so it's totally doable.

Could you expand on the useless "pushes into forks" notifications you're getting? Is it on forks of your projects? Do you have an example?

Thanks!

Metadata Update from @abompard:
- Issue assigned to abompard

3 months ago

But I am also missing notifications from Koji. E.g. yesterday, I have handled Ruby 3.3 mass rebuild. I have typically did the builds in a fire and forget mode, but I would still be interested should there be some build failure. I have not received any notification.

Could you expand on the useless "pushes into forks" notifications you're getting? Is it on forks of your projects? Do you have an example?

This is the most recent which has landed in my inbox:

Delivered-To: vondruch@gapps.redhat.com
Received: by 2002:a05:6358:705b:b0:175:3e01:f2fe with SMTP id 27csp1763754rwp;
        Wed, 3 Jan 2024 15:23:59 -0800 (PST)
X-Google-Smtp-Source: AGHT+IGXwm7MQKxZ/gM0u/hByquD8HPUNw5wxumPzdNhiv+LaYyNbhaxpb3qShvfCopk8BKoQm3Q
X-Received: by 2002:a05:6808:1285:b0:3b9:fc7c:b57d with SMTP id a5-20020a056808128500b003b9fc7cb57dmr23131125oiw.35.1704324239698;
        Wed, 03 Jan 2024 15:23:59 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1704324239; cv=none;
        d=google.com; s=arc-20160816;
        b=TItV+wrUugWLu0UaOEpHJ5BsxVxHBwRAiLhRiElouo2P1pBNb5AXkmOUGPqYx5ACMX
         Oc2YPiAO2yqDZ1PWrEzIOBLJ1JBvMr2tmhEkVVcckQlqLaxyMONBWwjxmLN0kc/7u6iH
         45B+YN3nswg9XCM0ZwFBIMZtSW3X4PsyDfqTRGygI6g72EnuMRx2sxxqmD6Qs6+6I/xy
         R7kCedqYlJAuyNcfkZaXD0itZj++LWjvMWt+D7AdU5jtM02umXaISu2Wjs8xyb3+JQNC
         uTTnb4X8ObR1bwSLKrBLSuV340x9xo/XJINA9T56yfZhQUp+odsOMfcRofW0dk0cuduX
         jQlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:date:message-id:mime-version:subject:to
         :from:dkim-filter:delivered-to;
        bh=+66idu18yaZ+6HhBCU2HoTzlPWwGDLmuRubWxgcKK5w=;
        fh=gLgeCFx3kUXz9LfI+aevn5arORMJV745rMAyvIwbW80=;
        b=OaXog2AxTqTy5zLUWCB4PFwaH4i7OhbQnzrC1ic2HZkb2S7EE7Yt7RZ8ghzSzIWuny
         tPrTPcMRibtEgXyf4yTYPRSUN8KpBLYAd5YnXAgarPVSGcgbd1+sVe3xQmsRF+hPNGER
         aRBitGkjMVaZFgblmfFOPOZn+RBBbW8fvS2DFAPgxd7iZF3Yw9V99SnwWlXwmJ8Y5Gl9
         TkyO7kGcL03CMD/Q6qWG/+vQOHed4H8DlgoOKICjL4v4+sxnzii+YIk1Ha/bKAVFaD3l
         gwPZhe6wrHtpn2uU4GEA0nxjM54YA6Ax7ONLpme0wYVRRzEudcRd4KRYADHz/CkXADJd
         wGZg==
ARC-Authentication-Results: i=1; mx.google.com;
       gateway.spf=pass (google.com: domain gapps.redhat.com configured 205.139.110.120 as internal address) smtp.mailfrom=notifications@fedoraproject.org smtp.remote-ip=205.139.110.120 policy.d=gapps.redhat.com
Return-Path: <notifications@fedoraproject.org>
Received: from us-smtp-inbound-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com. [205.139.110.120])
        by mx.google.com with ESMTPS id x3-20020a0cb203000000b006807757903esi15281905qvd.484.2024.01.03.15.23.59
        for <vondruch@gapps.redhat.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 03 Jan 2024 15:23:59 -0800 (PST)
Received-SPF: pass (google.com: domain gapps.redhat.com configured 205.139.110.120 as internal address)
Authentication-Results: mx.google.com;
       gateway.spf=pass (google.com: domain gapps.redhat.com configured 205.139.110.120 as internal address) smtp.mailfrom=notifications@fedoraproject.org smtp.remote-ip=205.139.110.120 policy.d=gapps.redhat.com
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com
 [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-308-DhOBZs0sMBmB0FDt3wdT7Q-1; Wed, 03 Jan 2024 18:23:58 -0500
X-MC-Unique: DhOBZs0sMBmB0FDt3wdT7Q-1
Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
     key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
    (No client certificate requested)
    by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DE43D101A551
    for <vondruch@gapps.redhat.com>; Wed,  3 Jan 2024 23:23:57 +0000 (UTC)
Received: by smtp.corp.redhat.com (Postfix)
    id DB4A2492BC7; Wed,  3 Jan 2024 23:23:57 +0000 (UTC)
Delivered-To: vondruch@redhat.com
Received: from bastion.fedoraproject.org (unknown [10.3.163.31])
    by smtp.corp.redhat.com (Postfix) with ESMTP id D318F492BC6
    for <vondruch@redhat.com>; Wed,  3 Jan 2024 23:23:57 +0000 (UTC)
Received: from sender-email-153-cwl69 (worker01.ocp.iad2.fedoraproject.org [10.3.163.123])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
     key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256)
    (Client did not present a certificate)
    by bastion01.iad2.fedoraproject.org (Postfix) with ESMTPS id B77B3203D66A
    for <vondruch@redhat.com>; Wed,  3 Jan 2024 23:23:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 bastion01.iad2.fedoraproject.org B77B3203D66A
From: Fedora Notifications <notifications@fedoraproject.org>
To: vondruch@redhat.com
Subject: [Pagure] yselkowitz pushed 1 commits on
 forks/yselkowitz/rpms/rubygem-ronn-ng (branch: rawhide)
MIME-Version: 1.0
Message-Id: <20240103232357.B77B3203D66A@bastion01.iad2.fedoraproject.org>
Date: Wed,  3 Jan 2024 23:23:57 +0000 (UTC)
X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: fedoraproject.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Yaakov Selkowitz (yselkowitz) forced-pushed 1 commit on forks/yselkowitz/rp=
ms/rubygem-ronn-ng.
Branch: rawhide

https://src.fedoraproject.org/fork/yselkowitz/rpms/rubygem-ronn-ng/c/1fc55a=
d07797d3ba5131f6bed28609c06a954284

From 1fc55ad07797d3ba5131f6bed28609c06a954284 Mon Sep 17 00:00:00 2001
From: Yaakov Selkowitz <yselkowi@redhat.com>
Date: Jan 03 2024 23:20:49 +0000
Subject: Workaround for libxml2 2.10.3+ test compatibility


Namespace handling has become stricter, and these foo: namespaces are
now being preserved, and perhaps correctly so.

https://github.com/apjanke/ronn-ng/issues/102

---

diff --git a/rubygem-ronn-ng-0.9.1-libxml2-namespace.patch b/rubygem-ronn-n=
g-0.9.1-libxml2-namespace.patch
new file mode 100644
index 0000000..4a82121
--- /dev/null
+++ b/rubygem-ronn-ng-0.9.1-libxml2-namespace.patch
@@ -0,0 +1,13 @@
+Backport of https://github.com/apjanke/ronn-ng/commit/c252a1b620310ebfa602=
29977d7d640441e81af0
+
+diff --git a/test/angle_bracket_syntax.html b/test/angle_bracket_syntax.ht=
ml
+index e10241b..8567d2e 100644
+--- a/test/angle_bracket_syntax.html
++++ b/test/angle_bracket_syntax.html
+@@ -13,5 +13,5 @@ code block,
+=20
+ <p>or when <code>&lt;WORD&gt;</code> is enclosed in backticks.</p>
+=20
+-<p>or when <var>WORD</var> has a <dot.> or <colon>.</colon></dot.></p>
++<p>or when <var>WORD</var> has a <dot.> or <foo:colon>.</foo:colon></dot.=
></p>
+ </div>
diff --git a/rubygem-ronn-ng.spec b/rubygem-ronn-ng.spec
index b8f2c5e..df79a7f 100644
--- a/rubygem-ronn-ng.spec
+++ b/rubygem-ronn-ng.spec
@@ -12,6 +12,9 @@ Source0:        https://rubygems.org/gems/%{gem_name}-%{v=
ersion}.gem
 # https://github.com/apjanke/ronn-ng/issues/80
 # https://github.com/apjanke/ronn-ng/pull/81
 Patch0:         rubygem-ronn-ng-0.9.1-Permit-Time-class-loading-from-YAML.=
patch
+# Workaround for libxml2 2.10.3+ test compatibility
+# https://github.com/apjanke/ronn-ng/issues/102
+Patch1:         rubygem-ronn-ng-0.9.1-libxml2-namespace.patch
 BuildRequires:  ruby(release)
 BuildRequires:  rubygems-devel
 BuildRequires:  ruby
@@ -45,6 +48,7 @@ Documentation for %{name}.
 %setup -q -n %{gem_name}-%{version}
=20
 %patch0 -p1
+%patch -P1 -p1
=20
 # Upstream specifies mustache=3D=3D0.7, but we have 1.1 and it seems to wo=
rk fine...
 %gemspec_remove_dep -g mustache "~> 0.7"

I think it may be because you don't have a rule for the ruby-packagers-sig, only for things related to your username. I would recommend adding such a rule. It's a separate tracking rule because some groups are noisy and people may want to have only a subset of their groups send notifications.

Unfortunately, it is not possible to figure out what I should subscribe to and what effect this will have. Being member of a group, I assumed that I'll receive everything. I might add filter also for the group, but I am not sure how I am supposed to figure this out 🤷

You should be getting messages from Anitya already (unless they're for a group, then you should get them when you add the group rule).

No, I don't. I am receiving messages from the-new-hottness, but not from Anitya. With old FMN, I used to receive combo such as:

A new version of "bundler" has been detected: "2.4.22" newer than "2.4.21", packaged as "rubygem-bundler"
the-new-hotness filed a bug on 'rubygem-bundler'

Since the old FMN was retired, I receive only messages such as:

the-new-hotness filed a bug on 'rubygem-bundler'

But I am also missing notifications from Koji. E.g. yesterday, I have handled Ruby 3.3 mass rebuild. I have typically did the builds in a fire and forget mode, but I would still be interested should there be some build failure. I have not received any notification.

Actually, now I realize that I receive messages from Koji, but not about my actions. This is example of messages I receive

[Koji] Build FAILED: distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org's rubygem-puma-5.6.5-5.eln134
[Koji] Build BUILDING: distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org's rubygem-puma-5.6.5-5.eln134
10:29
[Koji] Build COMPLETE: distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org's ruby-3.3.0-1.eln13

But not a single notification about action I triggered. Yes, such actions might look as superfluous, but in case such as mass rebuild I have mentioned earlier, they are useful.

Actually, now I realize that I receive messages from Koji, but not about my actions.>
But not a single notification about action I triggered. Yes, such actions might look as superfluous, but in case such as mass rebuild I have mentioned earlier, they are useful.

Ah, by default your actions don't generate notifications, but this can be enabled. Go to your notification rule, click on the destinations on the right, and click the "Including actions I initiated" toggle on the modal dialog (bottom left).

Capture_decran_du_2024-01-04_16-32-06.png

"Including actions I initiated"

That make sense. Nevertheless, while it is obvious that if I start the build, I don't necessarily need to be notified about it. But is the finish of the build action I have initiated or not? It is impossible to judge what impact those settings have unfortunately.

Could you expand on the useless "pushes into forks" notifications you're getting? Is it on forks of your projects? Do you have an example?

This is the most recent which has landed in my inbox: [...]

OK I found the message that caused this notification to be sent, it's visible at:

http --pretty all get https://apps.fedoraproject.org/datagrepper/v2/id id==29e88cff-4af8-450d-bc71-32aef0d3a81

That said, if user B opens a PR against one of user A's projects, it seems that user A may want to be notified of updates to this PR, and thus git pushes to the fork, no?

Nevertheless, while it is obvious that if I start the build, I don't necessarily need to be notified about it. But is the finish of the build action I have initiated or not? It is impossible to judge what impact those settings have unfortunately.

That's a very good point. We may want to consider that "build-finished" events haven't been caused by the build owner, but are "concerning" them.

I've opened a ticket for that here: https://github.com/fedora-infra/koji-fedoramessaging-messages/issues/62

Could you expand on the useless "pushes into forks" notifications you're getting? Is it on forks of your projects? Do you have an example?

This is the most recent which has landed in my inbox: [...]

OK I found the message that caused this notification to be sent, it's visible at:
http --pretty all get https://apps.fedoraproject.org/datagrepper/v2/id id==29e88cff-4af8-450d-bc71-32aef0d3a81

That said, if user B opens a PR against one of user A's projects, it seems that user A may want to be notified of updates to this PR, and thus git pushes to the fork, no?

I would kind of understand if the PR was the cause for the notifications. But I don't think it is. Here is another sample:

Delivered-To: vondruch@gapps.redhat.com
Received: by 2002:a05:6358:705b:b0:175:3e01:f2fe with SMTP id 27csp1101992rwp;
        Tue, 2 Jan 2024 11:27:48 -0800 (PST)
X-Google-Smtp-Source: AGHT+IExP6qHpCIkHB17QV06j5WaU7H2dn9XZt7a5NOjdPSH8xI4i1n+BJK4C+0Dg7pMoCbosWMz
X-Received: by 2002:a05:620a:56a:b0:781:b98e:bc00 with SMTP id p10-20020a05620a056a00b00781b98ebc00mr2810677qkp.142.1704223667901;
        Tue, 02 Jan 2024 11:27:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1704223667; cv=none;
        d=google.com; s=arc-20160816;
        b=TZoGQvj6F5W6G5mSEvJfIK2Xe41Lzp9ft0uLOnHo7XBDsgTe9JZ6pg+908wMXg5v+e
         kUcgXF+MLxT2T31EPeLaCQ06tdDwjx+t0td2TZMa6WOwpezrMg++xkNz3zeC9B4+iB5B
         +/iIY7RrMTFtLKTce1BoJ7AO6ZzeOjoi5Zy4zzvhrYzHgnv2hOF65Rgd+I2Yi/sKXt1X
         2tEyw4ZdP2emxLoGjU+0Jc/oKP3ug0WplCbOMNoBZZJ1lN0KNxDnKWds2Aqgau7U0qVa
         8LRnw+OsiMh+0wO0EznWK3N3cDpbcG3gw7uEmmlLo+ishFXCn7yyHciSfdNGoJK7Iz+R
         Nsaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:date:message-id:mime-version:subject:to
         :from:dkim-filter:delivered-to;
        bh=pKY78TXuAYAVbcMJLzjN8unXsdudKPXNshXLpJX4a6w=;
        fh=gLgeCFx3kUXz9LfI+aevn5arORMJV745rMAyvIwbW80=;
        b=fC4KTZQUYPwu3YZh42eVUb3WLwoeY9fRfBh32i5bN1l0rxlw5z1sf7+EzLUuOuJi9/
         XejS+ZdFvf4NyeLa+JTatvNelX0qIc/vSiHlFCNfGu7iFUtVfbQf+e4tu2YhdzJOlV3h
         Qn+VxoxOzhRK+rCAwlJTJ9ip5kpxhS2yB5MbnR5QevqULZdfLd7xK4XHB73+ZAxAUcG8
         98mGk+nnXf8PBhTDkR+SGsho0U+Kw01WURTs9fj7d9Ycqko04FrJfyczlaPu+TmXycr4
         vUnkGNhUtuQJSC7DBRVUA8v7pEiA6yaIO9t4AdQKGELOR9WqqKIp3VdCUnYHIK17OuqN
         Yxvg==
ARC-Authentication-Results: i=1; mx.google.com;
       gateway.spf=pass (google.com: domain gapps.redhat.com configured 205.139.110.120 as internal address) smtp.mailfrom=notifications@fedoraproject.org smtp.remote-ip=205.139.110.120 policy.d=gapps.redhat.com
Return-Path: <notifications@fedoraproject.org>
Received: from us-smtp-inbound-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com. [205.139.110.120])
        by mx.google.com with ESMTPS id l19-20020a05620a28d300b0077f0c19e400si29270413qkp.610.2024.01.02.11.27.47
        for <vondruch@gapps.redhat.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 02 Jan 2024 11:27:47 -0800 (PST)
Received-SPF: pass (google.com: domain gapps.redhat.com configured 205.139.110.120 as internal address)
Authentication-Results: mx.google.com;
       gateway.spf=pass (google.com: domain gapps.redhat.com configured 205.139.110.120 as internal address) smtp.mailfrom=notifications@fedoraproject.org smtp.remote-ip=205.139.110.120 policy.d=gapps.redhat.com
Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73])
 by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-382-Ib_ttVD7NhGdM7fMr5Ra7Q-1; Tue,
 02 Jan 2024 14:27:46 -0500
X-MC-Unique: Ib_ttVD7NhGdM7fMr5Ra7Q-1
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
     key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
    (No client certificate requested)
    by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EA4E03C2E0A3
    for <vondruch@gapps.redhat.com>; Tue,  2 Jan 2024 19:27:45 +0000 (UTC)
Received: by smtp.corp.redhat.com (Postfix)
    id E6C422166B32; Tue,  2 Jan 2024 19:27:45 +0000 (UTC)
Delivered-To: vondruch@redhat.com
Received: from bastion.fedoraproject.org (unknown [10.3.163.31])
    by smtp.corp.redhat.com (Postfix) with ESMTP id DE44D2166B31
    for <vondruch@redhat.com>; Tue,  2 Jan 2024 19:27:45 +0000 (UTC)
Received: from sender-email-153-cwl69 (worker01.ocp.iad2.fedoraproject.org [10.3.163.123])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
     key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256)
    (Client did not present a certificate)
    by bastion01.iad2.fedoraproject.org (Postfix) with ESMTPS id BF9C3203D67A
    for <vondruch@redhat.com>; Tue,  2 Jan 2024 19:27:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 bastion01.iad2.fedoraproject.org BF9C3203D67A
From: Fedora Notifications <notifications@fedoraproject.org>
To: vondruch@redhat.com
Subject: [Pagure] pvalena pushed 1 commits on forks/pvalena/rpms/ruby (branch:
 stream-3.3)
MIME-Version: 1.0
Message-Id: <20240102192745.BF9C3203D67A@bastion01.iad2.fedoraproject.org>
Date: Tue,  2 Jan 2024 19:27:45 +0000 (UTC)
X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: fedoraproject.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Pavel Valena (pvalena) pushed 1 commit on forks/pvalena/rpms/ruby.
Branch: stream-3.3

https://src.fedoraproject.org/fork/pvalena/rpms/ruby/c/7f32705242dd2b55e72d=
3e9e5eed0934e38ad043

From 7f32705242dd2b55e72d3e9e5eed0934e38ad043 Mon Sep 17 00:00:00 2001
From: Pavel Valena <pvalena@redhat.com>
Date: Jan 02 2024 19:27:10 +0000
Subject: Fix for aarch64 fibers and Ractors issues


https://bugs.ruby-lang.org/issues/20085
https://github.com/ruby/ruby/pull/9385

---

diff --git a/9385.patch b/9385.patch
new file mode 100644
index 0000000..14d2c00
--- /dev/null
+++ b/9385.patch
@@ -0,0 +1,28 @@
+From a8af871e29c6c922c4c3aeb94697ab958fc12e9b Mon Sep 17 00:00:00 2001
+From: Yuta Saito <kateinoigakukun@gmail.com>
+Date: Wed, 27 Dec 2023 06:22:45 +0000
+Subject: [PATCH] [Bug #20085] Use consistent default options for
+ `-mbranch-protection`
+
+We need to use the same options for both C compiler and assembler
+when `-mbranch-protection` is guessed by configure. Otherwise,
+`coroutine/arm64/Context.{h,S}` will use incompatible PAC strategies.
+---
+ configure.ac | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 9286946fc15f4..18b4247991d42 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -830,7 +830,10 @@ AS_IF([test "$GCC" =3D yes], [
+ =09AS_FOR(option, opt, [-mbranch-protection=3Dpac-ret -msign-return-addre=
ss=3Dall], [
+             RUBY_TRY_CFLAGS(option, [branch_protection=3Dyes], [branch_pr=
otection=3Dno])
+             AS_IF([test "x$branch_protection" =3D xyes], [
++                # C compiler and assembler must be consistent for -mbranc=
h-protection
++                # since they both check `__ARM_FEATURE_PAC_DEFAULT` defin=
ition.
+                 RUBY_APPEND_OPTION(XCFLAGS, option)
++                RUBY_APPEND_OPTION(ASFLAGS, option)
+                 break
+             ])
+         ])
diff --git a/ruby.spec b/ruby.spec
index cff86f7..bae81f1 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -237,6 +237,9 @@ Patch10: ruby-3.3.0-Revert-Optimize-allocations-in-Hash=
-compare_by_identity.patc
 # https://github.com/ruby/ruby/commit/d3933fc753187a055a4904af82f5f3794c88=
c416
 # https://bugs.ruby-lang.org/issues/20106
 Patch11: ruby-3.4.0-ruby-net-http-Renew-test-certificates.patch
+# Fix for aarch64 fibers and Ractors issues
+# https://bugs.ruby-lang.org/issues/20085
+Patch12: 9385.patch
=20
 Requires: %{name}-libs%{?_isa} =3D %{version}-%{release}
 %{?with_rubypick:Suggests: rubypick}
@@ -708,6 +711,7 @@ analysis result in RBS format, a standard type descript=
ion format for Ruby
 %patch -P 9 -p1
 %patch -P 10 -p1
 %patch -P 11 -p1
+%patch -P 12 -p1
=20
 # Provide an example of usage of the tapset:
 cp -a %{SOURCE3} .

and I don't think there is PR related to this branch

Could you expand on the useless "pushes into forks" notifications you're getting? Is it on forks of your projects? Do you have an example?

This is the most recent which has landed in my inbox: [...]

OK I found the message that caused this notification to be sent, it's visible at:
http --pretty all get https://apps.fedoraproject.org/datagrepper/v2/id id==29e88cff-4af8-450d-bc71-32aef0d3a81

That said, if user B opens a PR against one of user A's projects, it seems that user A may want to be notified of updates to this PR, and thus git pushes to the fork, no?

I would kind of understand if the PR was the cause for the notifications.

BTW it would be actually nice to have notifications such as "The PR was updated", but that was never the case AFAIR

Yet another strange case. There was this PR, which was merged today. I have received two notifications:

1) [Git] pagure pushed to rpms/rubygem-capybara (rawhide). "Update to capybara 3.39.2."
2) [Pagure] pvalena pushed 1 commits on rpms/rubygem-capybara (branch: rawhide)

It gives me hard time to understand why. What is Git actually? And what is Pagure? Aren't they the same where both could be called dist-git?

In any case, I have no clue what is the service sending them, why I have received two notifications and how to control this :/

Thanks for the report, that seems to be a misconfiguration of Pagure. I'm guessing that Pagure has a git hook that sends to fedora-messaging but also sends its own messages to fedora-messaging, hence the duplication. The Git hook seems unnecessary here.
I'll fix that now.

I would kind of understand if the PR was the cause for the notifications. But I don't think it is. Here is another sample: [...]
and I don't think there is PR related to this branch

I found why you're getting this email, the pagure message schema considers that the push to the fork is affecting the "ruby" package, which is obviously a bug. I've reported here: https://www.pagure.io/pagure-messages/issue/14

I've re-enabled the git hook within pagure, so we're back to duplicate messages, because the Pagure-native message doesn't contain enough information for some consumers (for example the Packit folks). I've opened this pagure ticket to add the missing information to the native emitter.

So, we have the git hook back (because the package retirement toddler needs data from the git hook). So, we have to fix that now. ;(

Login to comment on this ticket.

Metadata
Boards 1
ops Status: Backlog
Attachments 1