I'll also note there's a CVE bug on deepin-file-manager which never received a maintainer response.

I should note I don't mean "the package review does not appear to have considered security issues at all" as a criticism of the reviewer, in particular; it is more a weakness in the process. The word "security" occurs zero times in our package review guidelines. We neither require package reviewers to consider security issues in any way, nor provide them with any tools or instructions for doing so.

This might also be a good juncture to ask ourselves why we are apparently a long way behind SUSE in terms of having policies and mechanisms for reviewing security-sensitive package changes.

As someone who contributes to openSUSE, I'm aware of a couple key differences from Fedora:

• All package builds have to pass rpmlint checks, and there is a tuned policy with scores and allow/deny lists for D-Bus and Polkit stuff. Package builds automatically fail if they have a sufficiently high "badness" score. (That means in Fedora parlance, you can't actually submit it as an update because it's marked as failed in Koji.)
• SUSE Security is actively engaged as a stakeholder for package update submissions and have a defined process for triggering reviews. One such example of me going through this resulted in this review for DNF5.

Red Hat Cryptography and Security teams are not engaged with Fedora as a general rule. This has been true for at least the past decade (probably longer). Most of our security-related guidelines were deleted years ago when we realized there was ultimately nobody to care for them.

This will be discussed during today's FESCo meeting (starting 17:00 UTC in #meeting:fedoraproject.org).

This might also be a good juncture to ask ourselves why we are apparently a long way behind SUSE in terms of having policies and mechanisms for reviewing security-sensitive package changes.

This is more important than what we do with Deepin itself.

I believe SUSE is the only distro that provides security reviews for security-critical components. I'm quite grateful to SUSE's security team for their findings, which benefit all distros. If Fedora were to start doing security reviews as well, that would surely be of great benefit.

If Fedora were to start doing security reviews

Well ... who?

Are you volunteering for this new group? ;)

No :)

Looks like Deepin has a response to this: https://bbs.deepin.org/en/post/287017

Can any member of the Deepin DE SIG confirm that Deepin upstream reached out? @felixonmars, @cheeselee, @zsun?

Yes. We're keeping an eye on their progress at https://github.com/orgs/linuxdeepin/projects/246/views/1

The upstream response is very encouraging.

https://github.com/orgs/linuxdeepin/projects/246/views/1 has 3 open and 8 "done". So this seems to be moving in the right direction.

This might also be a good juncture to ask ourselves why we are apparently a long way behind SUSE in terms of having policies and mechanisms for reviewing security-sensitive package changes.

As someone who contributes to openSUSE, I'm aware of a couple key differences from Fedora:

• All package builds have to pass rpmlint checks, and there is a tuned policy with scores and allow/deny lists for D-Bus and Polkit stuff. Package builds automatically fail if they have a sufficiently high "badness" score. (That means in Fedora parlance, you can't actually submit it as an update because it's marked as failed in Koji.)
• SUSE Security is actively engaged as a stakeholder for package update submissions and have a defined process for triggering reviews. One such example of me going through this resulted in this review for DNF5.

Red Hat Cryptography and Security teams are not engaged with Fedora as a general rule. This has been true for at least the past decade (probably longer). Most of our security-related guidelines were deleted years ago when we realized there was ultimately nobody to care for them.

I'll also point out this is specifically what rpminspect was meant to do. As the replacement for the internal rpmdiff tool used on RHEL, rpminspect is built to enforce rules that are maintained in a vendor data package. How the vendor manages the data package is a matter of policy and process, but the idea is that the vendor defines the rules and rpminspect can enforce that. In RHEL this is used to validate built packages in gating and prevent pushing a package through any further until discrepancies are resolved.

Fedora could do this and did for a while with zuul but I don't know that anyone ever really set it up in a blocking way. My thought was always if we do this in Fedora it would make downstream consumers of Fedora packages even easier (like CentOS Stream and RHEL), but historically no one ever listens to me so whatever. ¯_(ツ)_/¯

The biggest mistake we made in Fedora was separating checks from builds. Because builds don't fail checks, only update submissions fail checks. If builds failed, everyone would care a lot more.

My thought was always if we do this in Fedora it would make downstream consumers of Fedora packages even easier (like CentOS Stream and RHEL), but historically no one ever listens to me so whatever.

That would require RHEL people to be involved in Fedora, which has historically not really been the case. There's no incentive for this because the intersection between Fedora and RHEL maintainers shrinks all the time.

My thought was always if we do this in Fedora it would make downstream consumers of Fedora packages even easier (like CentOS Stream and RHEL), but historically no one ever listens to me so whatever.

That would require RHEL people to be involved in Fedora, which has historically not really been the case. There's no incentive for this because the intersection between Fedora and RHEL maintainers shrinks all the time.

It depends on who you mean by "RHEL people". The developers are in Fedora. True, not all of them, but ever since I've been doing this continuing to now the Fedora, RHEL, and CentOS Stream maintainer of a package is the same individual or team. Again, I know this is not the case for everything, but by and large the package maintainers overlap.

RHEL management is another story. The continues to be this thing where RHEL wants to pretend it's unrelated to Fedora and that Fedora is done in a vacuum isolated from RHEL by people 100% outside of the company. I don't know where this idea originated, but it's damaging and exhausting for the people actually working on the code.

At any rate, the things we actually need to do are not easy and I never meant to imply they were.

What's the status here? Did upstream do the work it was planning? Did this land in Fedora?

after-the-holidays-ping

Note that many of the "deepin" related packages appear to be in bad shape (broken dependencies / broken builds) and / or have already been retired recently. Is the Deepin session on Fedora 43+ even still functional?

We removed Deeping from comps in https://pagure.io/fedora-comps/pull-request/1149 as core packages for the desktop failed to build and are not availabe in F43: https://pagure.io/releng/issue/12871.

So it does not look like this is still functional.

It's not listed in https://www.fedoraproject.org/spins anymore.

Do we need to do some kind of cleanup to remove the remaning bits?

Looks like cleanup is happening "semi-automatically", though slowly - five more @deepinde-sig packages will be retired due to long-term FTBFS issues in a few weeks:

https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/QA62XHHV3DLAGA3WZNXQC2XP3WEY2KDL/

Proposal: Unless somebody steps up by the time of the planned retirement of deepin-image-viewer and deepin-menu due to long-term FTBFS issues on March 03, 2026, any remaining Deepin DE specific packages will be retired from Fedora 44+ before the start of the F44 Final Freeze.

Do we have the list of those specific packages? but +1 in general...

+1 from me as well.

Do we have the list of those specific packages?

Maybe "packages maintained by @deepinde-sig that are a self-contained set, i.e. not used by any packages that are not related to Deepin DE or maintained by the SIG"?

I'd support this in general, but I think we need a more concrete list of packages so that people can figure out if a specific package will be retired or not.

Packages maintained by @deepinde-sig:

Deepin DE packages not maintained by @deepinde-sig:

So overall the packages indeed seem to be in quite bad shape - quite a few have already been orphaned / retired due to unfixed FTBFS & FTI issues, but some are apparently still being worked on by @topazus (tagged for visibility).

Ok so it appears that (ping) @topazus is still working on deepin-* related stuff, but isn't responding to any pings (nor to an unrelated package review I'm doing). Not sure what we can / should do here.

If we don't get any response, we may need to just forcibly retire the deepin package set.

This was discussed during today's meeting (logs):

AGREED: Attempt to reach out to deepin-sig maintainers (directly
and / or via their mailing list) and ask for what the current status
of the project is, since the DDE packages appear to have been in very
bad shape for an extended period of time. If there is no response for
four weeks, the DDE packages are retired in rawhide. (+5, 0, -0)
(@decathorpe:fedora.im, 17:54:41)

ACTION: ngompa to do the reaching out (@decathorpe:fedora.im, 17:56:38)

Keeping this issue open to track the issue.

@ngompa Any word here?

Just sent the email for this, you're CC'd to it.

Apparently the email to topazus bounced - since they're the person we'd need most to hear from, where does that leave us? (It would also explain why we're not getting responses on Bugzilla or to @ -pings here.)

Well, the 4 weeks delays started on 2026-05-05 when Neal sent the email. On 2026-06-02 we can retire the packages.

We got this reply from Zamir Sun:

Hi Neal,
Thanks for reaching out.
To make a long story short, all the initial packagers of the Deepin DE
packages(namely felixonmars, mosquito(no longer with Fedoraproject)
and cheeselee in FAS, and me as the coordinator) are being too busy
for the vast amount of work in maintaining DeepinDE. And we never got
active packagers to take the effort so we have to see it going away
from Fedora.
I don't know Felix Wang (topazus@) when I was still active on Deepin
DE, so I'm not sure if he has other progress afterwards or not.
And if Felix Wang (topazus) do not have much to chime in for these
packages, I'm totally fine for retire the whole Deepin DE packages.

That was from a week ago. At this point, with Felix unreachable, I think we should consider retirement.

Well ... don't we have dedicated policy for "non-responsive / no valid email address"?

But there's activity as recent as a few days ago (https://src.fedoraproject.org/user/topazus) ...

According to my observations, topazus is active but nonresponsive. When the FTI policy orphans a deepin package, they simply unorphan it again without taking any apparent action to fix the problem.

Yes, we've had a couple of cases like this before but we have no policy to deal with this.

Technically we do - invoke the policy for removal from the "packager" group:
https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#revoking

From today's meeting: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-05-19/fesco.2026-05-19-17.01.html

AGREED: Retire all packages in the list, with the message mentioning the fesco ticket. Ask releng to not unretire those packages if a request is made, unless they passed review again.
APPROVED (+7, 0, 0)

@gotmax23 Will do / ask for the retirements.

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YFZBLHOTVMINNY5I7JSO4JOXHFH3SARN/

gotmax23 Will do / ask for the retirements.

This is done, and the ticket can be closed. The toddler failed to block {'deepin-application-manager', 'deepin-tray-loader'} in Koji, but those should get blocked by the scheduled process within the next day.

Thanks for the disccussion and attention here. It’s late to comment on this. I’m okay with retiring the deepin-related packages, which it has already been done. My available time is occupied with other stuffs.