Update the XZ article with the link of the 'package sources' RFC we j…

…ust published on Arch Linux side

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46

content/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers.md

@@ -39,7 +39,7 @@ I already started the effort of switching the source of the packages I maintain
 
 With the recent xz situation, I think that basing our packages on a more transparent source, at the potential cost of [more complex](https://gitlab.archlinux.org/archlinux/packaging/packages/mupdf/-/commit/9e7f9c55b141833762d7951b81c0a574aa9353d9) packages to maintain (as the eventual pre-required steps needed for the source to be usable in the first place would now be on our side) is worth the price.
 
-Additionally, together with David Runge (Arch Linux Developer), we decided to jointly write an RFC (namely about “how to deal with sources in our packages?”) as a trial / suggestion to establish general guidelines on those matters on Arch Linux side *(I’ll update this part of the article with the links to those RFCs once they have been written and published)*.
+Additionally, together with David Runge (an Arch Linux Developer), we decided to jointly write [an RFC](https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46) which aims to establish some standards regarding the way we deal with our package sources and digital signatures for them.
 
 ## This is not only a downstream / packaging matter but also an upstream one