budgie-desktop requires papirus-icon-theme. This theme ships 97,113 files. That...seems like a lot. This causes a concrete problem: it makes build of the Onyx ostree container extremely slow, because rpm-ostree walks the entire filesystem as part of the container build process, checksumming every file it hits. I've filed an rpm-ostree issue asking if this can be sped up - https://github.com/coreos/rpm-ostree/issues/4880 - but cutting down the icons would of course help a lot. It seems like this single package ships three separate themes - "Papirus", "Papirus Dark", and "Papirus Light". It seems to include thousands of custom icons for third-party applications (each of which will already come with its own original icon which would probably be fine for most people). Multiply thousands of icons by three themes by multiple resolutions and you get to nearly six figures. Could this perhaps be split up a bit? Perhaps the three themes could be separate subpackages, and budgie-desktop could depend on only one or maybe two (a lighter and darker)? Could the third-party app icons be separated out from the 'core' icons, perhaps, and budgie-desktop made to only depend on the core part? It looks like about half the icons are in "apps" folders: [adamw@xps13a papirus-icon-theme (rawhide)]$ sudo dnf repoquery -l papirus-icon-theme | grep /apps/ | wc -l 48841 Or, alternatively, budgie-desktop could just go with a different default icon theme. Just as a reference point, adwaita-icon-theme contains 802 files. breeze-icon-theme has 35,182, which explains why kinoite takes the second-longest after onyx, but is still a hell of a lot less than 97,113. :D
Papirus Icon Theme is a pretty standard theme used by other distributions that ship Budgie Desktop. For example, Solus ships papirus-icon-theme alongside budgie-desktop. I completely agree that papirus-icon-theme is quite large and maybe could do with more splitting. That said, I do not think it appropriate to assign this to the budgie-desktop component or to me, when I'm not the package maintainer of papirus-icon-theme and this seems like a broader problem that is only noticeable because Papirus ends up being the default, and its size cripples some parts of ostree building. Maybe should be assigned to papirus-icon-theme component? In the case of Solus, it strips out a bunch of icons / icon packs from Papirus that are otherwise found extraneous, see https://github.com/getsolus/packages/blob/main/packages/p/papirus-icon-theme/package.yml > rm -f $installdir/usr/share/icons/Papirus/**/apps/{dcc_nav*,dde*,*deepin*,io.elementary*,uos*,com.github.cassidyjames*} In the above command, it strips out everything related to uos, dde, Deepin, elementary, etc. Looking at https://src.fedoraproject.org/rpms/papirus-icon-theme/blob/rawhide/f/papirus-icon-theme.spec, it splits out ePapirus already, but I wonder if this would be a good opportunity to split out Light and Dark variants, as well as removing some extra icons such as those for Deepin. In terms of choosing another icon theme, I'm not quite sure about that. While large, Papirus provides a massive range of well-crafted icons for third-party applications that help to create a more consistent desktop user experience. This is not something the likes of Adwaita Icon Theme can provide, since those do not have the same goals (and is actually blacklisted by Budgie Desktop because it does not provide sufficient coverage of needed icons). Breeze is also blacklisted for the same reason: https://github.com/BuddiesOfBudgie/budgie-desktop/blob/a040ccb96094f1d3a1ee81a6733c9434722bdf6c/src/panel/settings/themes.vala#L64 Thoughts?
I guess the initial question was "does Budgie really want to use Papirus, given this?" and if the answer's "yes" we can reassign it to papirus to be about maybe splitting it up a bit.
btw, I don't want to open a can of worms, but aren't there copyright/trademark issues around the third party app icons, where they are just takes on the 'official' icon or logo for the app? Just to take a random example: apps/github.svg appears to be more or less the GitHub logo. Is that under an approved content license for Fedora? Are we complying with the GitHub guidelines around using their trademark? https://github.com/logos . Has anyone considered these questions?
tagging FE-Legal for the aspect from comment #3 .
The papirus theme's "Legal" section says: "Every logo in this icon theme is owned by the respective trademark holder. We have not received approval to create these logos from any of the trademark owners, and the existence of an icon in this repository is in no way supported by the trademark owner. Where possible, we stayed true to the branding and official guidelines. If you are a trademark holder or application owner for one of these applications and disapprove of the icons we've created for your application, please submit an issue to this repository." which doesn't seem...hugely reassuring.
The original review ticket was https://bugzilla.redhat.com/show_bug.cgi?id=1635367 , it doesn't seem like the legal aspects were strongly considered there.
Ah, fair enough. Yea, it would be really great if Budgie Desktop could continue using Papirus Icon Theme. I think some easy wins with regards to cleaning up Papirus would be: - Removing Deepin, dde - Removing Steam game icons (steam_icon*) - Removing all the extra start-here icons for non Fedora operating systems - Possibly removing AppImageKit icons? - Brave webapp support (brave-*-Default.svg) - Google Chrome webapp support (chrome-*-Default.svg) - All distributor-logo-*.svg (or only have Fedora's) - Kali Linux icons (kali*) - Lutris icons (lutris_*.svg) Keeping in mind, many of there are symbolic links, so the number is inflated. Removing many of the color variants in places/ might help too, like realistically we could nuke folder-yaru*.
Sorry for the block removal, comment was made at the same time.
The number is relevant to the rpm-ostree issue even if they're symlinks - the walk rpm-ostree does really does consider every node in the filesystem, whether it's a real file or a symlink doesn't matter in that context. fortunately, it seems we may be able to get rid of that walk upstream, which makes that less of a big problem. Let's re-assign this to papirus, then, since budgie still wants to use it.
Hum. Here's another weird thing I noticed: [adamw@xps13a Papirus (rawhide %)]$ diff -u 48x48/apps/Zoom.svg 96x96/apps/Zoom.svg what? Shouldn't SVGs - those are *scalable* vector graphics - be in a scalable/ subdir, not the fixed-size subdirs? AIUI how icon themes are *supposed* to work, the fixed-size subdirectories should contain (only) fixed-size representations (i.e. they should be PNGs), in the size specified. They're usually there for when the scalable icon doesn't scale down to a small size very well. Why is Papirus shipping an identical SVG as both the "48x48" and "96x96" Zoom icon? That just seems wrong.
(In reply to Adam Williamson from comment #5) > The papirus theme's "Legal" section says: > > "Every logo in this icon theme is owned by the respective trademark holder. > We have not received approval to create these logos from any of the > trademark owners, and the existence of an icon in this repository is in no > way supported by the trademark owner. > > Where possible, we stayed true to the branding and official guidelines. > > If you are a trademark holder or application owner for one of these > applications and disapprove of the icons we've created for your application, > please submit an issue to this repository." > > which doesn't seem...hugely reassuring. I took a quick look at some of these icons. I could ask Red Hat's trademark lawyer to look into this, but I'm nearly positive she would say (1) these need to be individually reviewed, and (2) by default these icons are no good unless we can point to some specific permission covering them, and should be replaced somehow by use of plain text.
(In reply to Adam Williamson from comment #10) > Hum. Here's another weird thing I noticed: > > [adamw@xps13a Papirus (rawhide %)]$ diff -u 48x48/apps/Zoom.svg > 96x96/apps/Zoom.svg > > what? > > Shouldn't SVGs - those are *scalable* vector graphics - be in a scalable/ > subdir, not the fixed-size subdirs? AIUI how icon themes are *supposed* to > work, the fixed-size subdirectories should contain (only) fixed-size > representations (i.e. they should be PNGs), in the size specified. They're > usually there for when the scalable icon doesn't scale down to a small size > very well. > > Why is Papirus shipping an identical SVG as both the "48x48" and "96x96" > Zoom icon? That just seems wrong. So I asked upstream, they refer me to https://github.com/PapirusDevelopmentTeam/papirus-icon-theme/wiki/Basic-concepts,-tips,-and-common-mistakes#multiple-icon-sizes Regarding the same icons, they are symlinked: /usr/share/icons/Papirus/96x96 ll lrwxrwxrwx@ - bob 25 mai 02:00 apps -> ../48x48/apps lrwxrwxrwx@ - bob 25 mai 02:00 devices -> ../48x48/devices lrwxrwxrwx@ - bob 25 mai 02:00 mimetypes -> ../48x48/mimetypes lrwxrwxrwx@ - bob 25 mai 02:00 places -> ../48x48/places
(In reply to Richard Fontana from comment #11) > (In reply to Adam Williamson from comment #5) > > The papirus theme's "Legal" section says: > > > > "Every logo in this icon theme is owned by the respective trademark holder. > > We have not received approval to create these logos from any of the > > trademark owners, and the existence of an icon in this repository is in no > > way supported by the trademark owner. > > > > Where possible, we stayed true to the branding and official guidelines. > > > > If you are a trademark holder or application owner for one of these > > applications and disapprove of the icons we've created for your application, > > please submit an issue to this repository." > > > > which doesn't seem...hugely reassuring. > > I took a quick look at some of these icons. I could ask Red Hat's trademark > lawyer to look into this, but I'm nearly positive she would say (1) these > need to be individually reviewed, and (2) by default these icons are no good > unless we can point to some specific permission covering them, and should be > replaced somehow by use of plain text. That would need to include more than Papirus then, we have "trademarked" icons in Breeze too for example: ll /usr/share/icons/breeze/actions/16/im* lrwxrwxrwx@ - root 4 mai 02:00 /usr/share/icons/breeze/actions/16/im-facebook-symbolic.svg -> im-facebook.svg .rw-r--r--@ 497 root 3 mai 14:23 /usr/share/icons/breeze/actions/16/im-facebook.svg lrwxrwxrwx@ - root 4 mai 02:00 /usr/share/icons/breeze/actions/16/im-msn-symbolic.svg -> im-msn.svg .rw-r--r--@ 385 root 3 mai 14:23 /usr/share/icons/breeze/actions/16/im-msn.svg lrwxrwxrwx@ - root 4 mai 02:00 /usr/share/icons/breeze/actions/16/im-qq-symbolic.svg -> im-qq.svg .rw-r--r--@ 794 root 3 mai 14:23 /usr/share/icons/breeze/actions/16/im-qq.svg lrwxrwxrwx@ - root 4 mai 02:00 /usr/share/icons/breeze/actions/16/im-skype-symbolic.svg -> im-skype.svg .rw-r--r--@ 1,9k root 3 mai 14:23 /usr/share/icons/breeze/actions/16/im-skype.svg lrwxrwxrwx@ - root 4 mai 02:00 /usr/share/icons/breeze/actions/16/im-twitter-symbolic.svg -> im-twitter.svg .rw-r--r--@ 1,6k root 3 mai 14:23 /usr/share/icons/breeze/actions/16/im-twitter.svg lrwxrwxrwx@ - root 4 mai 02:00 /usr/share/icons/breeze/actions/16/im-yahoo-symbolic.svg -> im-yahoo.svg .rw-r--r--@ 1,1k root 3 mai 14:23 /usr/share/icons/breeze/actions/16/im-yahoo.svg lrwxrwxrwx@ - root 4 mai 02:00 /usr/share/icons/breeze/actions/16/im-youtube-symbolic.svg -> im-youtube.svg .rw-r--r--@ 500 root 3 mai 14:23 /usr/share/icons/breeze/actions/16/im-youtube.svg
Papirus with apps: 102,7 MiB (107 656 735) 82 345 files, 98 sub-folders Papirus without apps: 26,2 MiB (27 454 070) 33 533 files, 81 sub-folders So apps could be split a bit but i'm not sure according to what logic yet. So far I split dark and light theme but it's mostly symlinks. I am not sure if I should Suggests or Recommends anything.
https://github.com/PapirusDevelopmentTeam/papirus-icon-theme/issues/3563
(In reply to Robert-André Mauchin 🐧 from comment #13) > That would need to include more than Papirus then, we have "trademarked" > icons in Breeze too for example: Filed https://bugs.kde.org/show_bug.cgi?id=487595 and https://bugzilla.redhat.com/show_bug.cgi?id=2283321 . > So far I split dark and light theme but it's mostly symlinks. symlinks aren't free - they still use up an inode and cause things that do directory walks to seize up. So this is still useful. > I am not sure if I should Suggests or Recommends anything. By policy, I believe, the newly split-up packages should each obsolete pre-split versions of the unsplit package, and provide it. This will mean that those updating from the unsplit package get all the split packages (but they can now at least remove ones they don't need, and we can pick and choose which of the split packages to include in each desktop spin). > So I asked upstream, they refer me to https://github.com/PapirusDevelopmentTeam/papirus-icon-theme/wiki/Basic-concepts,-tips,-and-common-mistakes#multiple-icon-sizes Well, sure, but that's only tangentially related. It still seems odd and against usual practice to include symlinked copies of the SVG in the per-size directories; conventionally these contain PNGs, and SVGs go in the scalable/ directory. The thing about a scalable icon not always scaling nicely to every resolution is true, but seems a bit irrelevant if the project doesn't actually *ship* correct 'static' versions for the 'difficult' sizes? It's not like there's a different version of the Zoom icon in the 64x64 or 22x22 directories, so an app that needs a Zoom icon of these sizes is still going to wind up using the same SVG file...I guess I just don't quite understand what they're trying to achieve exactly by doing things this way instead of just using a scalable/ directory...
For the legal aspect and the splittings of apps it is gonna be a clusterfsck. There are so many icons, I don't even know to what apps or products they refer to.
Upstream seems unconcerned back in 2021 when this was mentioned to them : https://github.com/PapirusDevelopmentTeam/papirus-icon-theme/issues/2636 SmartFinn: > This is not an easy task, it is not feasible within this repository. If someone wants to moderate a fork under this organization - welcome. varlesh: > @throwaway1037 How you want analize more 7k apps? You have trademark database or want ask all apps-developer about logo, trademark, politics, license and etc? > 7k apps it's only apps/48px, but also we have 16/22/24/32/64 and tray icons 16/22/24... varlesh: > Ok. Complete audit all Papirus files - it's very very very giant work... I don't know how doing this... There are many pitfalls. I don't like idea > > papirus-icon-theme-libre (contains only icons of free software with no trademarks) > Because some free-apps used trademarks, for example Firefox or Fedora > I hink better solution for us - use only system icons without any all 3d-party apps (non-free & free too) varlesh: > Why Papirus popular? Because contained mostly 3-d party apps, because support hardcode-tray, because support folder colors, because present icons with differrent sizes, because use HIG for icons and etc, because i like it? It's unknown. > @throwaway1037 II'm not against if you want create very clean and absolute free Papirus icon theme. But we can't doing this. We can't audit more thousand files. Also our files present as source XML-files, it's not icons formally. > We are ready to solve the problem if it is in our power ---- My graphics designer sister says no one will sue you for having a Facebook or Twitter icon in your theme, it's common practice in any public icon themes for website etc, even well-known open source ones. But from a Fedora/Redhat/IBM point of view this is exposing a legal risk I guess. If I look at Debian for example, the package is orphaned currently, but they still have it in their repos unchanged : https://tracker.debian.org/pkg/papirus-icon-theme Most distros have it too : https://repology.org/project/papirus-icon-theme/packages
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.