Current stable media-fonts/noto-emoji-20220912-r2 is missing functionality that causes breakage at least for net-im/signal-desktop-bin-6.46.0, see bug #923941 I'm not aware of any bugs/issues that would be caused by the newer media-fonts/noto-emoji-20231130.
Don't manually CC arches. Procedure is to fill the package list (ideally with output from nattka make-package-list). Wait for nattka to accept it, and then let the maintainer or someone with sufficient permissions to add CC-ARCHES to signal nattka to finally CC the arch teams. The motivation for this is to avoid CC'ing the arch teams with stabilisation requests that they may not be able to or should not act on.
(In reply to Alfred Wingate from comment #1) > Don't manually CC arches. > > Procedure is to fill the package list (ideally with output from nattka > make-package-list). Wait for nattka to accept it, and then let the > maintainer or someone with sufficient permissions to add CC-ARCHES to signal > nattka to finally CC the arch teams. > > The motivation for this is to avoid CC'ing the arch teams with stabilisation > requests that they may not be able to or should not act on. Ah, thanks! It appears to be documented 'wrong' then at least on https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide#Request_stabilization which is where I looked. I'll take a stab at updating at least the CC aspect of the wiki page. I wasn't aware of nattka at all, and it's not mentioned there or at https://wiki.gentoo.org/wiki/Stable_request#Requesting_stabilization for this use case (it's only mentioned as kind of a backend tool there). Is there a way to 'nattka make-package-list' without cloning the git repo locally?
> It appears to be documented 'wrong' then at least on > https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide#Request_stabilization > which is where I looked. The wiki is not "wrong" from the perspective of the regular user really, just misleading with adding the arches to CC in the example. See: > Users do not need to worry about filling all fields or details in the bug. The maintainer (or Proxied Maintainer) will CC the arches. " A more firm "don't CC arches yourself please" wouldn't hurt in my view. Best to start a discussion on the page if unsure. > I wasn't aware of nattka at all, Its not really a user facing tool, if you get a habit of making stablereq or keywordreq bugs then knowing how it works is nice to have less churn. Bug wranglers and maintainers should really make sure it looks ok at the end of it > Is there a way to 'nattka make-package-list' without cloning the git repo locally? No, which is why I said ideally. Hand writing it works but you may miss reverse dependencies that are required (or get the syntax wrong). nattka would complain in such a situation and wouldn't CC arches until it was fixed.
amd64 done
x86 done
arm64 done all arches done
