If I remove commit-tool, but don't purge it, hg always argues about
missing modules:

$ hg st
*** failed to import extension hgext/hct: No module named hct
? index.mdwn~
$

Seems to work, though.

IMHO the remaining configuration files should check if the appropriate
extensions are available before trying to use them.

   Hi,

   Sorry for the delay, I come back from vacation.

Axel Beckert wrote:
[...]
By design, it prints an error message (but continue) if the extension
is not present.

Another difficulty is that the Debian Policy does not allow me (the
maintainer) to modify a config file in my pre/post install/remove
scripts.
There is the same problem with qct (see #427829). But, for now, no one
shows me a correct way to solve this problem...

   Best regards,
     Vincent

PS: commit-tool will probably be removed after lenny. There is no upstream
anymore and qct does the same kind of thing.

retitle 491329 removed commit-tool breaks the hgk extension
thanks



This breaks the hgk extension when is removed, but not purged.

0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ hg view
0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ dpkg --status commit-tool
Package: commit-tool
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 292
Maintainer: Vincent Danjean <vdanjean@debian.org>
Architecture: all
Version: 0.4-4
Depends: mercurial (>= 0.7-4) | git-core, python2.4, python-support
(>= 0.2), python-qt3
Conffiles:
 /etc/mercurial/hgrc.d/commit-tool.rc 85b98294feb0e6bb8adce4932133499d
Description: GUI commit tool for various Source Control Management systems
 Commit Tool or hgct/gct is a GUI enabled commit tool for Git and
 Mercurial (hg). It allows the user to view diffs, select which files to
 committed (or ignored / reverted) write commit messages and perform the
 commit itself.
 .
 Its generic SCM interface allows easy porting to other SCM systems.
 .
  Homepage: http://www.cyd.liu.se/users/~freku045/gct/



But when removed, it breaks the hgk extension:



0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ dpkg --status commit-tool
Package: commit-tool
Status: deinstall ok config-files
Priority: optional
Section: devel
Installed-Size: 292
Maintainer: Vincent Danjean <vdanjean@debian.org>
Architecture: all
Version: 0.4-4
Config-Version: 0.4-4
Depends: mercurial (>= 0.7-4) | git-core, python2.4, python-support
(>= 0.2), python-qt3
Conffiles:
 /etc/mercurial/hgrc.d/commit-tool.rc 85b98294feb0e6bb8adce4932133499d
Description: GUI commit tool for various Source Control Management systems
 Commit Tool or hgct/gct is a GUI enabled commit tool for Git and
 Mercurial (hg). It allows the user to view diffs, select which files to
 committed (or ignored / reverted) write commit messages and perform the
 commit itself.
 .
 Its generic SCM interface allows easy porting to other SCM systems.
 .
  Homepage: http://www.cyd.liu.se/users/~freku045/gct/
0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ hg view
*** failed to import extension hgext/hct: No module named hct
Error in startup script: k=vdiff
v=
*** failed to import extension hgext/hct: No module named hct
    while executing
"exec $env(HG) debug-config"
    (procedure "getconfig" line 4)
    invoked from within
"getconfig"
    invoked from within
"array set config [getconfig]"
    (file "/usr/share/mercurial/hgk" line 3904)


After purge everything works once again:


0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ hg view
0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ dpkg --status commit-tool
Package: commit-tool
Status: purge ok not-installed
Priority: optional
Section: devel

retitle 491329 removed commit-tool breaks the hgk extension
thanks



This breaks the hgk extension when is removed, but not purged.

0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ hg view
0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ dpkg --status commit-tool
Package: commit-tool
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 292
Maintainer: Vincent Danjean <vdanjean@debian.org>
Architecture: all
Version: 0.4-4
Depends: mercurial (>= 0.7-4) | git-core, python2.4, python-support
(>= 0.2), python-qt3
Conffiles:
 /etc/mercurial/hgrc.d/commit-tool.rc 85b98294feb0e6bb8adce4932133499d
Description: GUI commit tool for various Source Control Management systems
 Commit Tool or hgct/gct is a GUI enabled commit tool for Git and
 Mercurial (hg). It allows the user to view diffs, select which files to
 committed (or ignored / reverted) write commit messages and perform the
 commit itself.
 .
 Its generic SCM interface allows easy porting to other SCM systems.
 .
  Homepage: http://www.cyd.liu.se/users/~freku045/gct/



But when removed, it breaks the hgk extension:



0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ dpkg --status commit-tool
Package: commit-tool
Status: deinstall ok config-files
Priority: optional
Section: devel
Installed-Size: 292
Maintainer: Vincent Danjean <vdanjean@debian.org>
Architecture: all
Version: 0.4-4
Config-Version: 0.4-4
Depends: mercurial (>= 0.7-4) | git-core, python2.4, python-support
(>= 0.2), python-qt3
Conffiles:
 /etc/mercurial/hgrc.d/commit-tool.rc 85b98294feb0e6bb8adce4932133499d
Description: GUI commit tool for various Source Control Management systems
 Commit Tool or hgct/gct is a GUI enabled commit tool for Git and
 Mercurial (hg). It allows the user to view diffs, select which files to
 committed (or ignored / reverted) write commit messages and perform the
 commit itself.
 .
 Its generic SCM interface allows easy porting to other SCM systems.
 .
  Homepage: http://www.cyd.liu.se/users/~freku045/gct/
0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ hg view
*** failed to import extension hgext/hct: No module named hct
Error in startup script: k=vdiff
v=
*** failed to import extension hgext/hct: No module named hct
    while executing
"exec $env(HG) debug-config"
    (procedure "getconfig" line 4)
    invoked from within
"getconfig"
    invoked from within
"array set config [getconfig]"
    (file "/usr/share/mercurial/hgk" line 3904)


After purge everything works once again:


0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ hg view
0 eddy@twix ~/usr/src/perso/aptitude/aptitude-hg $ dpkg --status commit-tool
Package: commit-tool
Status: purge ok not-installed
Priority: optional
Section: devel

severity 491329 minor
retitle 491329 commit-tool: causes hg error messages if removed but not purged
thanks

  Hi,

Debian Bug Tracking System wrote:

  I do not really see why you want to raise the severity to such a level.
I'm downgrading it again. I'm also giving it back its more generic title.
If you want to give information about ANOTHER bug, then open a new bug please.

  The fact is that
* the package 'commit-tool' will NEVER remove its config file on removal
  (only in purge). It would be against strong Debian policy requirements.
  => nothing can be done in commit-tool
* mercurial is designed to print a message on its error output when an
  extension cannot be loaded.
  => you can try to open a bug for this... (upstream because this will not
  be a kind of patch that can be applied only in a Debian package of the software)
  But I find myself that mercurial is sane here
* the hgk extension breaks when mercurial sends it some kind of data (messages
  on stderr)
  => this is probably the real root of error. If you agree with me, you should
  open a bug for this (the best would be a bug upstream and then a bug in
  Debian that reference this upstream bug)

Because, if I read correctly your short report, you complain about the
hgk extension not working as soon as mercurial emits some of its standard
warning messages. Any extensions (not just commit-tool) will trigger this
bad behavior of hgk if they call not be loaded.

  Regards,
    Vincent

clone 491329 -1
reassign -1 mercurial-common
# I will not start to bikeshed here;
# since commit-tools config or other extensions' files are rightfully present,
# it looks like hgk extension breaks under relatively common conditions;
# I don't think it we could call exotic a case where an extension is removed
severity -1 serious
retitle -1 fails to start if some other extension is removed (not purged)
thanks

2009/1/26 Vincent Danjean <vdanjean@debian.org>:

Maybe because it breaks other software? But, anyways, this issue is
not that clear, since it is a bug of hgk triggered by commit-tool's
config (and possibly other extensions).

Well, isn't it a little bit late to wait for upstream? Anyway, I am an
accidental hg user - I was trying to find the root cause of #511708
(hg bisect) and I stumbled over this bug.

Not being able to use "hg view" looks like a pretty ugly bug, taking
into account that is like gitk for hg.

Probably the easiest fix is to redirect the warning about the
inability to load the extenson to stderr.

severity 513183 normal
thanks

  This bug is not in the core mercurial (ie the core software works
correctly). It is in an extension (hgk).
  I really do not think that such a bug should prevent mercurial to be
released with lenny (which would be the case if the severity is kept at
'serious' level).

  I think that this bug in hgk will be corrected now that it has been
discovered. But, unless someone comes quickly with a good patch, I do not
think it will be corrected before lenny.
  And the workaround is simple: just correct the mercurial configuration
so that the warning is not triggered anymore.

Eddy Petrișor wrote:
vdanjean@eyak:~$ cat ~/.hgrc
[extensions]
hgext.yo=
vdanjean@eyak:~$ hg > /dev/null
*** failed to import extension hgext.yo: No module named yo
vdanjean@eyak:~$


  Regards,
    Vincent

2009/1/27 Vincent Danjean <Vincent.Danjean@ens-lyon.org>:

I agree.

Or simply fix the extension not to choke on stderr stuff ;-)

OK.

OTOH, wouldn't the title of this bug (the cloned one) be better if it would be:

hgk/hg view fails to start when hg complains

instead of the current

hgk doesn't like it when hg complains


After all, that's what happens, and "doesn't like it" is not clear
what it means.

tags 513183 patch
thanks

Hello,

I spent some time n this bug, first trying to fix hgk itself, then
realising I was fighting someone else's battle and in the end I
settled for a (quite) elegant workaround.

I prepared an NMU, but the functional changes (without changelog
changes) were also extracted in a separate patch, if you prefer to add
yourself the changelog entry.



The functional changes are present in  513183-no-changelog.patch.

The NMU files are also provided (but are not signed). The orig file is
the same from the archive (obviously, from lenny).




Here is the description of the changes.

    workaround for 513183 so hg view works

    tcl/tk is very sensitive about stuff which is printed to stderr
    and considers anything printed to be on stderr to be a sign of
    an error.

    To avoid hgk's crash because of warnings, we print warnings
    only when the quiet option is absent. We suppress
    warnings in hg by calling from "hg view" a wrapper, hg-hgk,
    which requests quiet operation, disabling warnings.

    In order to preserve user's possible preference for another hg
    via HG environment variable, we make sure in the wrapper we
    call that HG, not the system hg, if HG was initally set.





Now all you have to do is to request an unblock request and upload to unstable.

# tcl/tk/wish chokes if child commands use stderr
retitle 513183 [patch] hgk fails to start when hg emits warnings
# an extenson doesn't work and there is a patch
severity 513183 important
thanks

Err, testing-proposed-updates, since a new mercurial version is
already in unstable.

# tcl/tk/wish chokes if child commands use stderr
retitle 513183 [patch] hgk fails to start when hg emits warnings
# an extenson doesn't work and there is a patch
severity 513183 important
thanks

Err, testing-proposed-updates, since a new mercurial version is
already in unstable.

Hello release team,

Mercurial's hgk extension fails to start if the configuration files of another
extension are still present after a package removal.

This is bug #513183 - hgk fails to start when hg emits warnings.

This happens under relatively common conditions (package of an extension
is removed, but not purged).



The hgk extension provides the command "hg view" which is an equivalent of
gitk in mercurial world. Since I know how important gitk is for me I thought
I should try to fix the problem for mercurial.


I provided a workaround and prepared an NMU which should have made the
problem go away with a simple upload[*] and approval from the release team.

The interdiff, the dsc , the .changes file and the new diff.gz are attached.

Changelog is:

 mercurial (1.0.1-5.2) testing-proposed-updates; urgency=low
 .
   * Non-maintainer upload.
   * added a workaround for the crash of hgk when hg was emitting
     warnings (Closes: #513183)




Since, as I can see, the maintainer of mercurial hasn't acted at all
since I provided
the patch and NMU,

I am requesting pre-aproval and a sponsor for mercurial/1.0.1-5.2.




The detailed description of the problem and the way I worked around it
is described at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513183#67

For your convenience, is reproduced here (unimportant bits removed):




[*] I mistekenly forgot to set the distribution to "testing-proposed-updates"
instead of "unstable" in the files in the NMU proposal, but I built on
lenny, so that is minor edit which is fixed now in the attachments.

* Eddy Petrișor [Fri, 30 Jan 2009 17:54:03 +0200]:

Hello, Eddy (and Mercurial maintainers).

Here are my thoughts on the issue:

  - a patch for this should really get an ACK from the maintainers

  - if not, you should follow the usual procedures for NMUs for < RC
    bugs, which start by waiting at least a week for a response

  - I'm doubtful this bug warrants a t-p-u upload, but since we've
    allowed them for non-RC bugs during this cycle, I won't block it
    if you come to an agreement with the maintainers that this is an
    appropriate solution

(Just for the record, I think it's an unfortunate use of /etc loading of
extensions if a warning is going to be inevitably printed when the
extension packages are removed but not purged. I also realize this does
not have an easy solution without cooperation from upstream.)

So, Eddy, let's wait a bit to hear what the maintainers think.

Cheers,

  Hi,

Adeodato Simó wrote:

I quickly look at your (Eddy) patch and I read your description. It seems
an elegant way to solve the problem.
Did you try to talk to upstream with this problem ? Did they acknowledge
the problem ? Or even your patch ? (but I think they will prefer modify
hgk itself to call hg with the quiet option instead of adding yet a wrapper).

I would prefer to have some input from upstream before modifying our version of
mercurial. But unless upstream strongly oppose to your patch, I will add it
(or a variant) in the Debian package.

  Many thank for your patch
    Vincent

No I haven't talked to them. Indeed, the quick fix I provided is not the
right solution for upstream, but it looks like a good workaround for
lenny since we're closer and closer to the release (now that D-I rc2 was
announced).
pper).

The proper fix is to actually modify the hgk code to actually enclose
each call to hg from hgk into a tcl/tk catch clause and test for the
result of $::errorCode and proceed if that is "NONE".

I can provide my modified hgk in this direction, still I am unsure this
would be really useful since this was my first attempt to change a
tcl/tk program and it would definitely be inappropriate for lenny since
there are many changes in that code to make it ignore warnings.


If fixing hgk proves to be too difficult, upstream could add a "nowarn"
configuration to hg and always call hg with that option on.
rsion of
d it

OK, I can talk with upstream about this issue.

You're welcome.