https://bugzilla.redhat.com/show_bug.cgi?id=1268010 Dominique Martinet <dominique.martinet(a)cea.fr&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |177841 (FE-NEEDSPONSOR) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=177841 [Bug 177841] Tracker: Review requests from new Fedora packagers who need a sponsor -- 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

https://bugzilla.redhat.com/show_bug.cgi?id=1268010 --- Comment #2 from Dominique Martinet <dominique.martinet(a)cea.fr&gt; --- (In reply to Dave Love from comment #1) Hmm I'll admit I didn't even try to build on EPEL5, will remove it. Right, will fix. I think I do need to keep the devel package requirements on other -devel packages, though, right? As far as I can tell (rpm -qpi --requires <package>) it could not guess these, and I couldn't find anything in the guidelines about this. Ok. Hmm I wonder why I added the .la there, if anything it should have been in the -devel... But right rhel systems don't even have it, will remove. For the .a though I've pretty much always seen it package in the -devel, but I see the packaging guideline now and it makes sense so I guess I'll strip it off as well. Yes, sorry. Ok No problem, thanks for the review! I'll fix all of that and try fedora-review as soon as I get my laptop back home (might be a few days, will update the ticket with new URLs anyway) Our development servers are behind a kerberized proxy and the fedora tools can't seem to work with that, unfortunately :/ -- 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

https://bugzilla.redhat.com/show_bug.cgi?id=1268010 Orion Poplawski <orion(a)cora.nwra.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |orion(a)cora.nwra.com --- Comment #4 from Orion Poplawski <orion(a)cora.nwra.com&gt; --- (In reply to Dave Love from comment #3) Yes, -devel packages should require the other devel packages needed to build with it. It's a commonly missed aspect. I suspect it's just a bit too messy to try to generate the proper provides/requires automatically. -- 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

https://bugzilla.redhat.com/show_bug.cgi?id=1268010 --- Comment #6 from Dominique Martinet <dominique.martinet(a)cea.fr&gt; --- Thanks for confirming. Here are the new specfile and src.rpm: http://asmadeus.notk.org/CEA/libmooshika-1.0-4.g3bde2d1.spec http://asmadeus.notk.org/CEA/libmooshika-1.0-4.g3bde2d1.fc22.src.rpm I tried fedora-review which gave a few more feedbacks (not required %clean section, obsolete autoconf flag for libtool...), it's pretty nice. Hadn't noticed the local testing parameter the other day, you're right it should work for me. (also noticed the el6 i686 package doesn't seem to build, looks like a system header difference from what I could see. I'm probably not going to try pushing it to epel6 so will ignore that for now unless that's a problem.) I'll try to get attention from the redhat storage people I know to see if I can get it tested. Not sure if many of them have IB adapters available, let's see how it goes. -- 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

https://bugzilla.redhat.com/show_bug.cgi?id=1268010 --- Comment #8 from Michael Schwendt (Fedora Packager Sponsors Group) <bugs.michael(a)gmx.net&gt; --- Oh, as I just saw this: https://fedoraproject.org/wiki/Packaging:Guidelines#Version_and_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

https://bugzilla.redhat.com/show_bug.cgi?id=1268010 --- Comment #10 from Upstream Release Monitoring <upstream-release-monitoring(a)fedoraproject.org&gt; --- martinetd's scratch build of libmooshika-1.0-1.fc22.src.rpm for f24 failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11788301 -- 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

https://bugzilla.redhat.com/show_bug.cgi?id=1268010 --- Comment #12 from Upstream Release Monitoring <upstream-release-monitoring(a)fedoraproject.org&gt; --- martinetd's scratch build of libmooshika-1.0-1.fc22.src.rpm for epel7-candidate failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11788384 -- 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

https://bugzilla.redhat.com/show_bug.cgi?id=1268010 --- Comment #14 from Dominique Martinet <dominique.martinet(a)cea.fr&gt; --- Hmm, I knew I was in the middle of something so this isn't what I wanted to push but this is weird, the same srpm does mock build on my laptop... Ohwell, will teach me to make sure I have a clean tree at least. Correct ones: http://asmadeus.notk.org/CEA/libmooshika/libmooshika.spec http://asmadeus.notk.org/CEA/libmooshika/libmooshika-1.0-1.fc22.src.rpm This is purely personal but I don't like the official guideline for git snapshot version so I'm going back to release (I did upstream release 1.0 for these packages so it isn't a problem), I wouldn't mind adding the date but just the date isn't enough (hence my using git describe, which will give strictly ordered release numbers) Unrelated to the update, but regarding tests of this package, nfs-ganesha will not be packaged with RDMA enabled until we can bundle it separately (there's planned work for this upstream but not short-term), so I doubt this will get any momentum right now... But it's entierely possible to test the lib itself with the utils (-rcat and -rmitm subpackages) -- I doubt anyone has any use for rmitm, but rcat is meant to be similar to netcat in its purpose so it's easy enough to test if you have ibverbs-compatible equipment I'll also be at supercomputing next week if anyone feels like talking about this or anything else :) Thanks, Dominique -- 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

https://bugzilla.redhat.com/show_bug.cgi?id=1268010 --- Comment #16 from Michael Schwendt <bugs.michael(a)gmx.net&gt; --- If you disagree with the guidelines, consider bringing it up on packaging@ mailing-list. Eventually you may want to package a snapshot, and then you would need to return to the topic anyway. It's the release number that will give a strictly ordered sequence. The git hash is meaningless with regard to updates/upgrades. Release: 0.%{X}.%{alphatag}%{?dist} %{X} is the release number to increment for every update of the package. The leading 0. is only for pre-release versions of the package. %{alphatag} is purely informational and may be as complex as 20110102git9e88d7e not adding much value, since inside the spec file you are supposed to add a comment anyway that would explain how to checkout exactly the same snapshot that has been packaged. If %X is the same for multiple builds of the package, you've not increased it properly, and only then package tools would take into account the values right of it during version comparison. https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs This is an example of why package reviews (and creating guidelines) can be a pain. Repeating the package %{name} in %{summary} is really bad style. Can you think of cases when the summary would be displayed without displaying the package name anywhere next to it? https://fedoraproject.org/wiki/Packaging:Guidelines#Summary_and_description https://fedoraproject.org/wiki/Packaging:SourceURL It's a rather small and simple package. Consider pointing the fedora-review tool at this ticket: fedora-review -b 1268010 It will look for the latest package files (such as in the Spec URL and SRPM URL lines) and perform many checks on a local test-build. Stuff you should be interested in when doing self-reviews. -- 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