Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=773419 Karel Volný <kvolny@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |VERIFIED Flag|fedora-review? |fedora-review+ --- Comment #3 from Karel Volný <kvolny@xxxxxxxxxx> 2012-01-18 11:15:46 EST --- (In reply to comment #2) > (In reply to comment #1) > > 1) package renaming - FAIL > > there is missing > > Provides: wormux = %{version}-%{release} > > > > so the package does NOT provide a clean update path, see > > https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages > > I know, but actually it DOES, see: > https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages#Do_I_need_to_Provide_my_old_package_names.3F > > Anyway, I've added the Provides. ah, I've missed that bit, thanks for pointing that out (maybe the guidelines would need some updating, but ...) however, I thought the way it works is 1. someone has wOrmux installed 2. runs yum upgrade 3. yum looks into repos what provides wOrmux no provides: 4. wOrmux is provided only by wOrmux, yum sees no new version => no upgrade wArmux has Provides: wOrmux: 4. yum finds that wOrmux is provided by wArmux and the provided version is newer => upgrade from wOrmux to wArmux i.e. without Provides, it needs user action to find out that the replacement is available, and to explicitly install wArmux am I mistaken? - is it enough to have Obsoletes? - I though that "Obsoletes" is more like a Conflicts, that it would expel the old package (saying it is safe to uninstall it, unlike Conflicts which needs manual intervention to decide which one to keep) ... reading RPM Guide, I'm really not sure how does that work when it comes to upgrading :-( ... anyways :-) there is now Provides: wormux = %{version}-%{release} Provides: wormux-data = %{version}-%{release} - ok > > * MUST: The package MUST successfully compile and build into binary rpms on at > > least one primary architecture. > > > > - FAIL - this doesn't build in rawhide, due to missing zlib include, see > > http://koji.fedoraproject.org/koji/taskinfo?taskID=3697088 > I've added the include, but there's still some other problem that I can't > figure out. I think it could be related to new GCC 4.7 used in rawhide as I > can't see any problem in the code. > http://koji.fedoraproject.org/koji/taskinfo?taskID=3705602 I've saw some mentions about build failures that were fixed by Petr Písař - not sure if this could be the same issue, but you can try asking ... > --- Summary --- > I think I've fixed all the problems you mentioned except the rawhide building > problem which I'll try to narrow down later. > Spec URL: http://jpopelka.fedorapeople.org/warmux.spec > SRPM URL: http://jpopelka.fedorapeople.org/warmux-11.04.1-2.fc16.src.rpm agreed, thanks unfortunately, one new issue slipped in: SPECS/warmux.spec:60: W: macro-in-comment %configure - not a blocker, but please fix on next update and rpmlint now reports a new error: warmux.x86_64: E: invalid-lc-messages-dir /usr/share/locale/cpf/LC_MESSAGES/warmux.mo - which is a false positive, bug #782818 filed for that (generally, the locales look okay, I've tried to play the game in Czech) => Approved -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review