https://bugzilla.redhat.com/show_bug.cgi?id=1532042 Dominik Schubert <mail@xxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@xxxxxxxxxxxxx --- Comment #7 from Dominik Schubert <mail@xxxxxxxxxxxxx> --- First of all, thanks for taking this on. I had actually considered submitting it myself, but felt I couldn't properly support a package where upstream is basically dead without some insight into the code-base. So in the end I decided to leave it in Copr and maintain that on a best-effort basis. But I'll try to help if I can. There used to be a compton package in the past: https://src.fedoraproject.org/rpms/compton/blob/master/f/dead.package I think this means you have to unretire it, there's a process for that... (https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package) (In reply to Iwicki Artur from comment #1) > >Release: 0 > The "Release:" tag should start at 1. > https://fedoraproject.org/wiki/Packaging:Versioning#Simple_versioning As I understand it, simple versioning does not apply here (0.1_beta2 would be higher than 0.1, which is wrong). So the correct way to do this should be: > Version: 0.1 > Release: 0.1.beta2%{?dist} (https://fedoraproject.org/wiki/Package_Versioning_Examples has some examples to this end) Some other possible issues: - the dist tag is missing (https://fedoraproject.org/wiki/Packaging:DistTag) - BuildRequires: gcc is now required (https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B) - libdrm-devel and libXfixes-devel should be explicitly listed as build dependencies; they get pulled in by mesa-libGL-devel, but you shouldn't rely on that (https://fedoraproject.org/wiki/Packaging:Guidelines#Build-Time_Dependencies_.28BuildRequires.29) - BUT, the Makefile uses pkg-config for x11, xcomposite, xfixes, xdamage, xrender, xext, xrandr, xinerama, libconfig, libdrm and dbus-1, so pkgconfig(x11), pkgconfig(xcomposite) and so on should be listed insted (https://fedoraproject.org/wiki/Packaging:PkgConfigBuildRequires) - compton-trans needs xprop or xwininfo, which are in xorg-x11-utils, so this should be a (runtime) dependency - hicolor-icon-theme probably shouldn't be a build dependency, it is only needed so that there is a package owning the directory structure when it is installed (and for running gtk-update-icon-cache, see next point). > dnf repoquery --repo rawhide-source --whatrequires hicolor-icon-theme does list a couple of packages that have BuildRequires: hicolor-icon-theme (and actually lack the runtime dependency!). But I'm pretty sure those are just bugs. - the icon cache scriptlets are no longer needed, there have been file triggers for those for some time now (rpm -q --filetriggers hicolor-icon-theme) (https://fedoraproject.org/w/index.php?title=Packaging%3AScriptlets&type=revision&diff=508538&oldid=500930 https://pagure.io/packaging-committee/issue/736) - the same is true for update-desktop-database (which was actually only needed for .desktop files containing MIME types in the first place) - however, the .desktop file still needs to be validated > %check > desktop-file-validate %{buildroot}/%{_datadir}/applications/compton.desktop This also needs BuildRequires: desktop-file-utils (https://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage) (In reply to Abhiram K from comment #6) > I'm not sure if this is the right way to go about doing this, but I created > a fork of the upstream repo to create a new release and I pointed the spec > file to that fork. You can always package the current master as a snapshot version (see my Copr build for an example https://copr-be.cloud.fedoraproject.org/results/dschubert/compton/fedora-27-x86_64/00688196-compton/compton.spec) and add any additional changes as patch files. It's not exactly pretty, but at least it's clear from the spec file what the changes are relative to upstream. I think if you want to maintain a proper fork, it would be better to have a different (package) name for it. Otherwise we will be left with a nasty mess, if there is ever another upstream release. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
