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
ruby-packagers-sig
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
@abompard Could you help with this?
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
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.
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><WORD></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"
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 🤷
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'
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).
<img alt="Capture_decran_du_2024-01-04_16-32-06.png" src="/fedora-infrastructure/issue/raw/files/004c9650a822d3cf0b8be9784a90cc2cc1ff636411c473c86b725c060a5ff9fb-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: [...]
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?
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
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.
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)
[Git] pagure pushed to rpms/rubygem-capybara (rawhide). "Update to capybara 3.39.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?
Git
Pagure
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.