On Tue, 7 May 2013 09:12:33 -0600, Jerry James wrote: > On Tue, May 7, 2013 at 5:44 AM, Fedora Koji Build System wrote: > > Package: m4rie-20130416-1.fc19 > > Tag: f19-updates-candidate > > Status: complete > > Built by: pbrobinson > > ID: 416696 > > Started: Tue, 07 May 2013 11:35:25 UTC > > Finished: Tue, 07 May 2013 11:44:10 UTC > > Changelog: > > * Mon May 06 2013 Jerry James <loganjerry@xxxxxxxxx> - 20130416-1 > > - New upstream release > > - Add -aarch64 and -doxygen patches > > - Build PDF documentation instead of HTML, because of numerous TeX-only > > constructs in the documentation > > Peter, this may seem like a personal attack on you. That is not my > intent. You have been very helpful to me in the past, and I > appreciate that help. But this is yet another example of a > provenpackager doing something wrong to one of the packages I > maintain. Each time this happens, I have to do more work to fix the > mistake. I've had this happen 5 times since August, 3 times in 2013. > Each time I have sent a private email to the individual involved, but > since the same mistakes keep being made by different people, I think > it is time to draw some attention to them. > > These are the mistakes I keep seeing: > 1. Building a package in isolation, without considering necessary > buildroot overrides. > 2. Updating a package that is a dependency of other packages without > testing the effects of the update on those other packages. > 3. Updating a package that is a dependency of other packages without > rebuilding those other packages. > 4. Pushing a change to a git branch without also pushing it to master. > 5. Creating a new update in Bodhi instead of editing an existing update. > 6. Not making any attempt to communicate with a package maintainer. > > In this case, Peter, you made mistakes 1, 2, 3, and 6. I imagine you > saw the work I did in Rawhide yesterday, knew that m4rie has been > broken on ARM for some time, and decided to push the new m4rie version > to F-19 so you can build it for ARM and mark that build failure as > being "fixed". But what you must have missed is the email that has > been sent to -devel over the last several days, coordinating the > update of m4rie with several other packages. The plan was this: > > 1. Update in Rawhide > a. Update libfplll, m4ri, and ntl > b. Once those builds are in the buildroot, update eclib, flint, > latte-integrale, m4rie, polybori, and Singular > c. Once those builds are in the buildroot, update linbox and Macaulay2 > d. Once those builds are in the buildroot, update sagemath > 2. Test in Rawhide, going back to step 1 as necessary to fix problems. > 3. Once all packages seem stable, do the same builds for F-19 > > I was still on step 1d, and you leapt ahead to part of step 3, without > talking to me to find out what the plan is, and without doing all of > the other builds that are necessary. The m4rie build you did is now > linked with the wrong version of m4ri, which means that I will have to > bump NEVR to do the build properly, which means that I'll have to do a > useless build in Rawhide just to bump NEVR there. Please cancel the > F-19 update you submitted, as that build is bogus. I will submit a > new update once I get to step 3. > > And a general plea to provenpackagers: don't make mistake #6, please. > Every single time this has happened, I could have told the > provenpackager involved what needed to be done if he had just asked. > But none of them did. They just acted, without having sufficient > knowledge to act correctly, and without making any attempt at > acquiring that knowledge. Don't do that. > > </whine> A summary of what exactly has been done would have been good here. It seems a version upgrade has been copied from Rawhide to F-19. Is that true? https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages Adding to your list of mistakes 1-6, this is also an example where copying the %changelog is not enough. IMHO. The published package appears as if _you_ did the build for F-19, while you only had prepared the spec/package for Rawhide. I wouldn't mind, if a real "official" co-maintainer copied from one branch to another and did builds like that for a version upgrade, but a provenpackager ought to add to the %changelog an explicit comment. The release versioning scheme where a minor ".1" is appended to the Release tag makes that easy (and is the standard way to apply minor fixes anyway). That would create a merge conflict with the master tree, but one would need to figure out why the maintainers did not apply those _version upgrades_ themselves. About the special dependencies of your package, it would be an idea to add more specific EVR details to the BuildRequires (and perhaps even the Requires). That's one common way to request a specific target environment, and the package won't even build without the needed buildroot overrides you refer to. -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-301.fc19.x86_64 loadavg: 0.06 0.05 0.20 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
