Spec URL: http://scop.fedorapeople.org/packages/reptyr.spec SRPM URL: http://scop.fedorapeople.org/packages/reptyr-0.2-1.fc14.src.rpm reptyr is a utility for taking an existing running program and attaching it to a new terminal. Started a long-running process over ssh, but have to leave and don't want to interrupt it? Just start a screen, use reptyr to grab it, and then kill the ssh session and head on home. https://github.com/nelhage/reptyr#readme
Hi Ville, Some quick notes: -rpmlint output: reptyr.src: I: checking reptyr.src: I: checking-url http://github.com/nelhage/reptyr (timeout 10 seconds) reptyr.src: E: unknown-key (MD5 The package was signed, but with an unknown key. See the rpm --import option for more information. reptyr.src: W: invalid-url Source0: nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz The value should be a valid, public HTTP, HTTPS, or FTP URL. 1 packages and 0 specfiles checked; 1 errors, 1 warnings. *** You should not sign the package, let Fedora Project do it :) - **** Are you sure that you need: - BuildRoot - rm -rf $RPM_BUILD_ROOT in %install section - %clean section Take a look at http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag Hope that helps
I sign the package as long as it is in my web space/repo - my signature will of course not be imported to the Fedora packages in any way. Yes, I need BuildRoot, rm -rf $RPM_BUILD_ROOT, and %clean because I want this package to be buildable as-is on EL-5. I'm not aware of a way to express github tarball download URLs sanely in spec files.
rpmlint output: reptyr.src: W: invalid-url Source0: nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz 3 packages and 0 specfiles checked; 0 errors, 1 warnings. NEEDSWORK: * Replace Source0: nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz with the correct address Source0: https://download.github.com/nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK MUST: The spec file for the package is legible and macros are used consistently. OK MUST: The package must be named according to the Package Naming Guidelines. NEEDSWORK - You're not using a stable release, so you need to conform to http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non-Numeric_Version_in_Release MUST: The spec file name must match the base package %{name}. OK MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines. OK MUST: The License field in the package spec file must match the actual license. OK - License is MIT Modern style with sublicense MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. NEEDSWORK - Add address as stated above. - Source matches upstream f529080ca426371745ab909e84da05ce nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz f529080ca426371745ab909e84da05ce ../SOURCES/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz MUST: The package MUST successfully compile and build into binary rpms. OK MUST: The spec file MUST handle locales properly. N/A MUST: Optflags are used and time stamps preserved. ~OK - To preserve time stamps in install, you should add a '-p' flag to the install command. - However, the time stamp of the original files seems to be the time of the VCS checkout, so this is not necessary. MUST: Packages containing shared library files must call ldconfig. N/A MUST: A package must own all directories that it creates or require the package that owns the directory. OK MUST: Files only listed once in %files listings. OK MUST: Debuginfo package is complete. OK MUST: Permissions on files must be set properly. OK MUST: Large documentation files must go in a -doc subpackage. N/A MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. OK MUST: Header files must be in a -devel package. N/A MUST: Static libraries must be in a -static package. N/A MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. N/A MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. N/A MUST: Packages does not contain any .la libtool archives. N/A MUST: Desktop files are installed properly. N/A MUST: No file conflicts with other packages and no general names. OK SHOULD: %{?dist} tag is used in release. OK SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. NEEDSWORK - No license included. SHOULD: The package builds in mock. OK EPEL: Clean section exists. OK EPEL: Buildroot cleaned before install. OK EPEL: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. N/A
awesome! I'm looking forward to this package. Tested on F14.
(In reply to comment #3) > NEEDSWORK: > * Replace > Source0: nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz > with the correct address > Source0: > https://download.github.com/nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz Not done; that URL results in 404 Not Found for me in wget, curl, and Firefox. $ wget https://download.github.com/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz --2011-03-07 20:30:24-- https://download.github.com/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz Resolving download.github.com... 207.97.227.240 Connecting to download.github.com|207.97.227.240|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2011-03-07 20:30:25 ERROR 404: Not Found. When someone has downloaded the tarball once (e.g. from the links in their web interface), it seems that github caches it for some time making it appear that the URL works, but then it disappears again later as witnessed above. I don't know of a way to link to their tarballs that would actually work with rpm and be stable. If you do, let me know. I *guess* something like https://github.com/nelhage/reptyr/tarball/%{name}-%{version}/nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz would work but there's no way I can be sure right now due to the caching behavior described above (it works for me ATM, but then again I guess the URL you suggested worked for you too when you tried it). > MUST: The package must be named according to the Package Naming Guidelines. > NEEDSWORK > - You're not using a stable release, so you need to conform to > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non-Numeric_Version_in_Release But this is the 0.2 release, not a non-released snapshot. It's what you get from downloading https://github.com/nelhage/reptyr/tarball/reptyr-0.2 . github's tarball names are just ugly, if you know how to get prettier ones, let me know. > SHOULD: If the package does not include license text(s) as separate files from > upstream, the packager should query upstream to include it. NEEDSWORK > - No license included. Hm? COPYING is included in the upstream tarball and shipped in the built binary package.
(In reply to comment #5) > (In reply to comment #3) > > NEEDSWORK: > > * Replace > > Source0: nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz > > with the correct address > > Source0: > > https://download.github.com/nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz > > Not done; that URL results in 404 Not Found for me in wget, curl, and Firefox. Umm.. did you expand the macros? I tested it with $ spectool -g reptyr.spec and it worked. It's not working anymore, since the tarball doesn't exist anymore. The current snapshot from the master branch is nelhage-reptyr-reptyr-0.2-2-g919fff7.tar.gz In the 0.2 tag it is nelhage-reptyr-reptyr-0.2-2-g919fff7.tar.gz Note that this is a review blocker. > When someone has downloaded the tarball once (e.g. from the links in their web > interface), it seems that github caches it for some time making it appear that > the URL works, but then it disappears again later as witnessed above. I don't > know of a way to link to their tarballs that would actually work with rpm and > be stable. If you do, let me know. > > I *guess* something like > https://github.com/nelhage/reptyr/tarball/%{name}-%{version}/nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz > would work but there's no way I can be sure right now due to the caching > behavior described above (it works for me ATM, but then again I guess the URL > you suggested worked for you too when you tried it). I was able to get the same tarball as you before, so this is not true. It's not a problem if the source URL doesn't work anymore after the revision in question has vanished from upstream. However, that way it's just way easier for the maintainer to plug in the correct snapshot ID in the spec file and run $ spectool -g package.spec > But this is the 0.2 release, not a non-released snapshot. It's what you get > from downloading https://github.com/nelhage/reptyr/tarball/reptyr-0.2 . > github's tarball names are just ugly, if you know how to get prettier ones, let > me know. Whenever you use snapshots from VCS, you MUST insert the snapshot revision in the Release field. > > SHOULD: If the package does not include license text(s) as separate files from > > upstream, the packager should query upstream to include it. NEEDSWORK > > - No license included. > > Hm? COPYING is included in the upstream tarball and shipped in the built > binary package. Whoops, my mistake.
(In reply to comment #6) > Umm.. did you expand the macros? Of course. > I tested it with > $ spectool -g reptyr.spec > and it worked. So did I, and it did *not* work. As said, I additionally tested with wget, curl and Firefox, it didn't work in any of them. > It's not working anymore, since the tarball doesn't exist anymore. The current > snapshot from the master branch is > nelhage-reptyr-reptyr-0.2-2-g919fff7.tar.gz > In the 0.2 tag it is > nelhage-reptyr-reptyr-0.2-2-g919fff7.tar.gz Um, those are the same? And I'm NOT packaging the current master branch snapshot, I'm packaging the 0.2 release. > Note that this is a review blocker. Well, your previous suggestion did not work, and I'm not going to put a URL that I *know* does not work there. See end of this comment for more about this. > However, that way it's just way easier for the maintainer to plug in the > correct snapshot ID in the spec file and run > $ spectool -g package.spec Yes, I have quite a bit of experience with packaging and I'm pretty much the upstream of spectool nowadays, so I know about its use cases as well, and I'll be maintaining this package anyway, so... > Whenever you use snapshots from VCS, you MUST insert the snapshot revision in > the Release field. Oh come on. This is as a "release" as it gets and NOT a random VCS snapshot, there's just (to my knowledge) any way to get sane, stable github tarball download URLs. Or don't you think what upstream tagged as 0.2 is the 0.2 release? Then what is? The tarball sha1sums won't match and github has mangled the base dir inside the 0.2 tarball after I packaged it (mine was nelhage-reptyr-31b85ff, new one I just downloaded is nelhage-reptyr-9f9fd83, but both filenames are nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz), but the contents are *exactly* the same otherwise. Please also look at the git revision mentioned for the 0.2 release at https://github.com/nelhage/reptyr/downloads; it's 31b85ff which is the revision in my package. What else do you want in order to not call this a VCS snapshot but a release? The tarball in my package: $ sha1sum ~/rpmbuild/SOURCES/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz b8b56a17d4a7efd9ee93295619b7495161b70732 /home/scop/rpmbuild/SOURCES/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz The 0.2 tarball I get from the tar.gz download link for reptyr-0.2 at https://github.com/nelhage/reptyr/downloads (the tarball link points to "https://github.com/nelhage/reptyr/tarball/reptyr-0.2"): $ wget --no-check-certificate "https://github.com/nelhage/reptyr/tarball/reptyr-0.2" --2011-03-10 23:39:30-- https://github.com/nelhage/reptyr/tarball/reptyr-0.2 Resolving github.com... 207.97.227.239 Connecting to github.com|207.97.227.239|:443... connected. WARNING: certificate common name “*.github.com” doesn’t match requested host name “github.com”. HTTP request sent, awaiting response... 302 Found Location: https://nodeload.github.com/nelhage/reptyr/tarball/reptyr-0.2 [following] --2011-03-10 23:39:31-- https://nodeload.github.com/nelhage/reptyr/tarball/reptyr-0.2 Resolving nodeload.github.com... 207.97.227.252 Connecting to nodeload.github.com|207.97.227.252|:443... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://download.github.com/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz [following] --2011-03-10 23:39:41-- https://download.github.com/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz Resolving download.github.com... 207.97.227.240 Connecting to download.github.com|207.97.227.240|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 12187 (12K) [application/octet-stream] Saving to: “nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz” 100%[===============================================================================================================================================================================================================>] 12,187 --.-K/s in 0s 2011-03-10 23:39:44 (257 MB/s) - “nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz” saved [12187/12187] $ sha1sum nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz e9d305d9a0b8d9a80644e7cf2987f8078350ed80 nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz ...so the sha1sums don't match, but: $ rpmdev-diff ~/rpmbuild/SOURCES/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz ...so the contents of the actual files in them are the same. You can also verify it by doing a checkout of the reptyr-0.2 upstream tag and comparing that to the tarballs' contents ("git checkout reptyr-0.2" also outputs "HEAD is now at 31b85ff... reptyr 0.2" -- note again the 31b85ff git revision which IS the 0.2 release). If you won't approve the package as is, I suggest posting a concrete patch or specific steps what you could approve and I'll have a look if I'm fine with them in the sense that I wouldn't consider them as making the package worse and immediately revert them once the package is in, or to step aside and let someone else finish the review, or someone else can continue this submission or post another one.
With Source0: https://download.github.com/nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz I get the sha1sums $ sha1sum ../SOURCES/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz b8b56a17d4a7efd9ee93295619b7495161b70732 ../SOURCES/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz e9d305d9a0b8d9a80644e7cf2987f8078350ed80 nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz Thus one is able to get a tarball with identical content, but the shasum doesn't match (timestamps probably). This is not a problem, except for the automatical sources check that is performed every now and them, but it shouldn't cause any troubles since you'll know to expect it. It is my *strong* recommendation that you use the explicit source URL. If not, you will have to make the comment more verbose as per http://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control In addition, in either case you MUST use http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages I'll attach a patch that addresses both of these issues shortly.
Created attachment 483621 [details] Patch against specfile to fix issues.
(In reply to comment #8) > With > Source0: > https://download.github.com/nelhage-reptyr-reptyr-%{version}-0-g%{gitrev}.tar.gz I'm not going to use that URL, because again, it does not actually work. $ spectool -g reptyr.spec Getting https://download.github.com/nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz to ./nelhage-reptyr-reptyr-0.2-0-g31b85ff.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 > In addition, in either case you MUST use > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages You did not respond to my question why you think this was a snapshot package. Anyway, because upstream git has a crash fix after 0.2, here's another revision (this time it *is* a VCS snapshot package and properly marked as such). http://scop.fedorapeople.org/packages/reptyr.spec http://scop.fedorapeople.org/packages/reptyr-0.2-2.20110311git919fff7.fc14.src.rpm * Fri Mar 11 2011 Ville Skyttä <ville.skytta> - 0.2-2.20110311git919fff7 - Update to git revision 919fff7, fixes crash with invalid arguments.
(In reply to comment #10) > > In addition, in either case you MUST use > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages > > You did not respond to my question why you think this was a snapshot package. It's a snapshot since you pulled it from the VCS. In the normal case one uses stable release tarballs. Here there is no problem, since one knows what is in, e.g., gcc-4.5.2.tar.gz. You then would get, e.g., gcc-4.5.2-1 as the EVR of the resulting RPM. If you, however, pull out a snapshot - even from a stable branch - it's impossible to know *what* is in the source. The version of the branch *does not* identify the sources. This is why you have to add the snapshot revision to the Release tag.
reptyr.src: W: strange-permission reptyr-snapshot.sh 0755L reptyr.src: W: invalid-url Source0: reptyr-20110311git919fff7.tar.bz2 3 packages and 0 specfiles checked; 0 errors, 2 warnings. You can fix the permission warning by setting 644 (you can always run the script with sh script.sh). ** I highly recommend making the comment more verbose by changing # Source0 generated with Source99 to something of the form # Upstream has not released stable tarballs yet, so we use git snapshots. # The script in Source99 is used to generate a git snapshot tarball. which is IMHO more in line with http://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control ** Looks like the blockers have been fixed. This package has been APPROVED
(In reply to comment #11) > It's a snapshot since you pulled it from the VCS. I did *not* do that. I have tried to tell more than once that it was the tarball I got by following the download URL for the 0.2 release in github's web interface. But... meh. New Package SCM Request ======================= Package Name: reptyr Short Description: Attach a running process to a new terminal Owners: scop Branches: el5 el6 InitialCC:
Git done (by process-git-requests).
(In reply to comment #13) > (In reply to comment #11) > > It's a snapshot since you pulled it from the VCS. > > I did *not* do that. I have tried to tell more than once that it was the > tarball I got by following the download URL for the 0.2 release in github's web > interface. But... meh. It's still a snapshot. The thing is that the contents of the git branch can be modified, that of stable release tarballs cannot. The idea is to identify the content with the version-release combination. If you use stable tarballs (foo-version.tar.gz *that is not generated on-the-fly and has fixed content*), you don't have to put anything extra in the release tag. If you use a snapshot, whether one created yourself with e.g. git pull and tar, or a tarball created by the git server, then you must form the release tag accordingly as instructed in the Naming Guidelines.
(In reply to comment #15) > The thing is that the contents of the git branch can be modified Sure, if it was a branch. If I was packaging the latest of some branch, I agree that it would be a snapshot and would thus obviously need to follow the snapshot naming guidelines. But reptyr-0.2 is not a branch, it's a tag. $ git tag reptyr-0.1 reptyr-0.2 upstream/0.1+git.20110212t183758.d51bfc2d $ git branch -r origin/HEAD -> origin/master origin/attach-fds origin/debian origin/master origin/pristine-tar One could argue that tags could be moved to point to a different revision later, but that's a splitting hairs discussion I have no interest in. >, that of stable release tarballs cannot. That's simply not true. It's not a good practice by any means, but unfortunately it's not uncommon at all for some upstreams to modify/replace "stable release tarballs" in place.
http://koji.fedoraproject.org/koji/buildinfo?buildID=233390
Okay. I'm sorry I've been hardheaded. You are right - it's a *tag*, not a *branch*. You can remove the snapshot ID from the release if you want. The source URL stuff still holds, since the tarball is - unfortunately - not static.