Hi, El domingo, 20 de noviembre de 2016 14:49:16 (CET) Clive Johnston escribió: > Hi folks, > > I'm concerned about the following packaging for plasma-discover > > https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/discover > / log/?h=kubuntu_zesty_archive > > 1) Basically a Debian merge was carried out and the VCS fields have somehow > got changed. As far as I understand, this should not and could not happen > using the KA-NG tooling, but yet it is there in black and white?
As you pointed out in your other mail, the Vcs-* fields for discover are correct (apparently), i.e. Vcs-Browser: https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/discover Vcs-Git: git://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/discover > 2) The automatic nature of the tooling does not seem to be flagging up > conflicts that need attention. For example, in the merge the following was > removed, from the rules file: > > -override_dh_gencontrol: > - dh_gencontrol -pmuon-discover -- -v4:$(DEB_VERSION_UPSTREAM_REVISION) > - dh_gencontrol -pmuon-updater -- -v4:$(DEB_VERSION_UPSTREAM_REVISION) > - dh_gencontrol -pmuon-notifier -- -v4:$(DEB_VERSION_UPSTREAM_REVISION) > - dh_gencontrol --remaining-packages > - > > These packages are transitional "dummy" packages from when discover was part > of Muon, they therefore have an epoch in the archive. Without this epoch > they will fail to upload. This, indeed, seems an issue in our packaging which has to be handled manually. I did that in this comit: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/discover/commit/?h=kubuntu_zesty_archive&id=5bbb53e6524f702ae324cc9da6e69270e719379f However, aparently, you still don't understand why this kind of things are happening, and you seem to insist in blaming again and again the merge helper script instead of just understanding what's going on. Just for the record, the process to merge from debian banches is documented here: https://git.launchpad.net/~kubuntu-packagers/+git/kubuntu-automation/tree/README.ng Section 4 - "Merging from debian branches" To sum up this is what the KA merge helper does: 1. It creates a temporary branch on top of debian's branch with some changes to avoid some conflicts in advance 2. Then that temporary branch is merged (with 'git merge') into our kubuntu branch And this is done as a better alternative of doing a plain 'git merge'. The fact that you may get some problems even using the KA tooling to handle the merges doesn't mean that you wouldn't get the same problems (plus some extra problems) if you do a plain 'git merge'. You still don't believe me? Allright, let's simulate what would have happened without using the 'evil' KA script: First let's create a couple of branches to get what we had before doing the merge: git branch debian_merge_sim 1ff8922154542d5b402ec12c211048456ecec865 (this will point to the contents of 'debian/master' before the debian merge) git branch kubuntu_zesty_archive_sim 7cdd5a5beacc40c3461c63bd966e66bec273bb57 (this will point to the contents of 'kubuntu_zesty_archive' before the debian merge) Now lets checkout the target branch for the merge with git checkout kubuntu_zesty_archive_sim And now let's merge the debian branch with git merge debian_merge_sim Output of 'git merge' Auto-merging debian/plasma-discover.install CONFLICT (content): Merge conflict in debian/plasma-discover.install Auto-merging debian/control CONFLICT (content): Merge conflict in debian/control Auto-merging debian/changelog Automatic merge failed; fix conflicts and then commit the result. Output of 'git status' $ git status On branch kubuntu_zesty_archive_sim You have unmerged paths. (fix conflicts and run "git commit") Changes to be committed: modified: debian/changelog new file: debian/patches/01_new-appstreamqt.patch new file: debian/patches/series modified: debian/plasma-discover-common.install modified: debian/rules Unmerged paths: (use "git add <file>..." to mark resolution) both modified: debian/control both modified: debian/plasma-discover.install So as we can see, 'git merge' did some changes automatically in the debian/rules. Now inspect the contents of debian/rules. Does debian/rules have the correct contents with the lines to handle the epochs? Well, no. So now that we realized that the 'debian/rules' would be broken even if we did a plain 'git merge', now it's worth a think why 'git merge' is doing that. There is a good article here about the '3-way merge' algorithm (performed by 'git merge'): http://www.drdobbs.com/tools/three-way-merging-a-look-under-the-hood/240164902 TL:DR -> Unlike us, the human beings, 'git merge' doesn't have a brain, it's just a piece of software applying blindly an algorithm to resolve automatically some conflicts; that will produce in most cases good results, but in a few ones bad results, and we will have to fix them. Let's get over it. > In addition to the above points, I am also concerned about changes/fixes > others (Ubuntu Developers) have uploaded to the archive but have not been > sync'ed into our packaging. The old tooling used to flag these up and move > them into a manual folder for attention. The new tooling does not seem to > pay any regard to this at all. > > If we are doing away with this in the tooling, surely we need another way of > detecting if bug-fixes have been applied by non-Kubuntu people and > reflecting those changes in our archive tracking branches? That's something which we didn't have time to handle yet, there is a trello card which I created some time ago: https://trello.com/c/3lWHpWk3/224-add-script-to-report-packages-in-git-out-of-sync-with-the-archive > > Clive -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
