https://bugzilla.redhat.com/show_bug.cgi?id=1448041 Tom "spot" Callaway <tcallawa@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |tcallawa@xxxxxxxxxx Assignee|nobody@xxxxxxxxxxxxxxxxx |tcallawa@xxxxxxxxxx Flags| |fedora-review+ --- Comment #3 from Tom "spot" Callaway <tcallawa@xxxxxxxxxx> --- Review ======= Notes: You will need to be careful with how you update this package. If it were my package, I would macroize the different versions/release values at the top: %global metapyver 0.19.1 %global echover 0.19.1 %global bashver 0.19.1 # Reminder: Do I need to increment these release values? %global metapyrel 3 %global echorel 3 %global bashrel 3 It's easy to push an update and forget to change these values. I'm not sure if koji will notice if subpackages show up with identical nvr if the source nvr is different. Again, if it were me, I'd lock the release value (and never reset it back to 1) across all the subpackages just to ensure that I didn't accidentally screw it up. That said, I _know_ you know what you're doing here. - rpmlint checks return: python2-metakernel-tests.noarch: W: no-documentation python3-metakernel-tests.noarch: W: no-documentation python2-metakernel-python.noarch: W: no-documentation python3-metakernel-python.noarch: W: no-documentation python2-metakernel-echo.noarch: W: no-documentation python3-metakernel-echo.noarch: W: no-documentation python2-metakernel-bash.noarch: W: no-documentation python3-metakernel-bash.noarch: W: no-documentation All safe to ignore - package meets naming guidelines - package meets python and general packaging guidelines - license (BSD) OK, text in %license, matches source - spec file legible, in am. english - source matches upstream (1c7e5badcf8505a550d01f2946d56d2160a5d163633503c97dfe39bc8b0e05f7) - package compiles on f26 (x86_64) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - macro use consistent - code, not content - -docs is appropriate - nothing in %doc affects runtime - no need for .desktop file APPROVED. -- 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