When I run dispatch-conf, it tries to merge files with binary content, resulting in some ._mrg0000_* file. These files contain "<<<<<<<", "=======" and ">>>>>>>" markers for conflicting sections. So they really make _no_ sense at all for binary files. But it asks me, if I want to "use-new", nevertheless. For example: Files /etc/entrance_config.db and /etc/._mrg0000_entrance_config.db differ >> (3 of 3) -- /etc/entrance_config.db >> q quit, h help, n next, e edit-new, z zap-new, u use-new m merge, t toggle-merge, l look-merge: Moreover, I then have no choice to use the "real" new file ._cfg0000_*, which is what I would prefer in most cases (this one and things like xkbcomp, rstartd.real, ...), or is that what the "t" option is for? And, while we're at it: For these ._mrg0000_* files the display of a diff and the choices "u" and "m" do not really make sense. The file already contains the conflicts, and hence the lines from the old and the new file, you don't need to diff or merge ("m") them in again, and you probably don't want to use them unmodified ("u"). Reproducible: Always Steps to Reproduce:
This bug should have a higher severity. This can break users keyboard configurations, which will lead to major problems for users using foreign keyboard layouts like Finnish.
This happens on normal config files every now and then too. It's a "fatal" bug that makes dispatch-conf quite useless and should have been fixed a long time ago ...
I recently started using dispatch-conf again and was dismayed this was still an issue, and got bitten on the 2nd day. Trashing configs is a severe bug, yet this is one of the few references to it I could find. How come this hasn't gotten a higher priority? Are only a few of us affected? I'd love to use dispatch-conf, but this silly bugs needs attention :?
I fixed this a couple of days ago. The reason it took so long is because the person that wrote dispatch-conf left some time ago and nobody took over maintenance. It'll be fixed in 2.0.51.20 which should be out within the month.
(In reply to comment #2) > This happens on normal config files every now and then too. It's a "fatal" bug that makes dispatch-conf quite useless and should have been fixed a long time ago ... Happened to me with /etc/conf.d/net just today. The file was basically merged into itself twice, starting with <<<<<<< /etc/config-archive/etc/conf.d/net and ending with >>>>>>> 1.4 I also noticed this problem quite a few times with php.ini. :-/ Will these errors be fixed as well?
(In reply to comment #5) > (In reply to comment #2) > > This happens on normal config files every now and then too. It's a "fatal" bug > that makes dispatch-conf quite useless and should have been fixed a long time > ago ... > > Happened to me with /etc/conf.d/net just today. The file was basically merged > into itself twice, starting with > > <<<<<<< /etc/config-archive/etc/conf.d/net > > and ending with > > >>>>>>> 1.4 > > I also noticed this problem quite a few times with php.ini. :-/ Will these > errors be fixed as well? You didn't state what portage version you are using.
(In reply to comment #6) > You didn't state what portage version you are using. Well, I am using 2.0.51.19 as most people here. (I had so many issues with unstable portage versions related to sandbox that I had to downgrade even on a testing box). Maybe it would be better if dispatch-conf was a separate ebuild.
It's not fixed in 2.0.51.19. It is fixed in >2.0.51.19. That's why this bug is marked InCVS but not closed yet. Those versions have the fix but are not marked stable yet. If you are aware that this bug exists, either watch out for it, upgrade to a version that has the fix, backport the fix or don't use dispatch-conf. Don't complain that it's not fixed.
Uhm, I
Uhm, I´m not complaining that it´s not fixed. I just noted that this bug occurs also without ._mrg0000_* files and asked whether the fix for this bug solves this problem as well.
You quoted comment #2 (which was rude enough on it's own - nobody has the right to say "should have been fixed a long time ago" without supplying a patch) which implies that you share the same sentiment. Was there some other reason for quoting it? The bug occurs due to dispatch-conf not looking at the results of the three-way merge. If the merge failed, it was blindly using the resultant file (which contains the conflicts you see) rather than doing something more intelligent. There's possibly a better fix, but what I chose to do was drop the results altogether when a three-way merge fails and drop back to the etc-update behaviour of merging the current with the new.
*** Bug 98569 has been marked as a duplicate of this bug. ***
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
