https://bugzilla.redhat.com/show_bug.cgi?id=1295144 --- Comment #13 from Martin Ueding <von.fedora@xxxxxxxxxxxxxxxx> --- In response to gil (#7): > %global commit0 1e158fb > %global shortcommit0 %(c=%{commit0}; echo ${c:0:11}) I only got it to work with the following: %global commit0 1e158fb20108 %global shortcommit0 %(c=%{commit0}; echo ${c:0:7}) Source0: https://bitbucket.org/raymonad/%{name}/get/%{commit0}.tar.gz#/%{name}-%{shortcommit0}.tar.gz %setup -qn raymonad-%{name}-%{commit0} The hash used in the URLs is also just seven characters long, perhaps they have changed it? I had to deviate quite a bit from [the wiki](https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Hosting_Services) so I would assume that the content in the wiki is a bit outdated. If so I would happily update them. ---- In response to gil (#7) and later Michael (#11): The `%define` was not chosen over `%global` with any particular thought from me. I just searched for “rpm define variable” and stumbled accross [a SO post](http://stackoverflow.com/a/10236104) where somebody used `%define`. Having a C++ background I did not think that there could be another thing that would be better. I just want to reduce repetition (Don't Repeat Yourself) and introduced a variable. Now it uses `%global`. ---- Then about the whole pre-release thing: The version that I use from git is a couple commits *after* 0.3.0 and there is no more recent tag in the upstream repository. Previously I have used xss-lock 0.3.0 on Ubuntu 15.04 and had a bug with it, it would not exit when I logged out. The repository contains commits which suggest that this bug has been addressed but not yet released. I have packaged the latest version in git in my Open Build Service home project and used for a week now, it seems fine. In the sense of xss-lock this should be a post-release version. In terms of the Fedora package I assumed that the Fedora package would be a pre-release. In Debian they upload all the proposed packages with `Release: 0` so to speak. As this is not an official package yet, I thought having `Release: 0.1` was the thing to do here. ---- In response to Michael (#11): > [rpm macros] I have copied the output from `rpmbuild` complaining about unpackaged files there. In the wiki I read that the use of macros just has to be consistent but is not mandatory. Should I now change it back to use the hardcoded paths? >> Requires: xcb-util libxcb glib2 > https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires I read the paragraph there but I am not sure what you want to tell me. Should I add some explicit version there? > [cmake compile step] This part originated from an openSUSE package that I did for another project. I did not really look into detail there and just assumed that it cannot be too wrong as it works. In the log I see that the old version gave the flags twice which seems to be nonsensical. Also the compile commands are not visible which is not helpful. And there are a couple warnings which are not that important. The one warning: 'atom' may be used uninitialized in this function should be something to look into. The `%cmake` already adds verbose output, so this should be fine now. > [bash completion] Quoting [File and Directory Ownership](https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership): > Solution: Both the `git` and `bzr` packages should own the > `/etc/bash_completion.d` directory as `bash-completion` is optional > functionality and the installation of git or bzr should not force the > installation of `bash-completion`. So from this I think that this package should own the whole directory. I have changed that. > [man page] Nice to know, I changed that. > When modifying the spec file during package review, bumping Release and > updating %changelog is good practice. Okay, in Debian they demand that the `Release` only tracks uploads to the actual distributions. Fixing a package in review is not considered a new release. The one after these comments will be `Release: 2` and I filled in the changelog. ---- Thank you for all the helpful comments! Here are the current files, bumped to `Release: 2` and formatted such that `fedora-review` should pick it up: Spec URL: http://chaos.stw-bonn.de/users/mu/uploads/2016-01-04/xss-lock.spec SRPM URL: http://chaos.stw-bonn.de/users/mu/uploads/2016-01-04/xss-lock-0.3.0-2.20140302git.fc23.src.rpm -- 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 https://admin.fedoraproject.org/mailman/listinfo/package-review