Nicholas D Steeves <sten@debian.org> writes: > Xiyue Deng <manphiz@gmail.com> writes: > >> Nicholas D Steeves <sten@debian.org> writes: >>> Xiyue Deng <manphiz@gmail.com> writes: >>> >>> This action is only correct if all users will use UTF-8 100% of the time >>> because otherwise it sweeps a corner-case under the rug. In other >>> words, NACK at this time. >>> >>> Providing correct functioning to users of non-UTF-8 appears to require >>> this: >>> >>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Converting-Representations.html >>> >>> and alternatively, the mode should throw an error on non-UTF-8 systems. >>> >> >> c65b0989 was an attempt to avoid failure on buildd in case it doesn't >> have the proper locale settings. As I cannot reproduce this issue using >> sbuild which I think the buildds use, and the previous 3.0.0-2 upload >> doesn't fail either, it's probably OK to leave this unresolved for now. > > Yup, I've been aware of the issue for a while, and have been deferring > its resolution for a while because I haven't seriously looked into > encodings, and because the objective isn't to make the tests > superficially pass. > Ack. >>> As the package maintainer, I'm willing to sponsor at commit:fc1fac7 or >>> equivalent. >>> >> >> I can revert to 01379469 which is just before I tried Jeremy's solution >> if you are OK to sponsor this. > > I found time to review your changes. Once again, the changelog should > unambiguously document changes to the package without requiring git > history to interpret any changelog entry. > > See changelog and git log for further info. > I was actually trying to follow the practice to keep a changelog entry concise and focus on high-level description, without exposing too much details which may not be obvious to people not familiar with the package so as not to confuse them. In this case I would consider the changes to the actual test files to be implementation details, which I skipped. (A little more details: I tried to submit the patch upstream, which requires some tweaks to meet their CI requirements, after which I turned back to backport it and hence the refresh. The previous patch works as is, but I'd prefer to be more aligned with upstream.) Just to make it clear that the lack of detail is not a result of carelessness but to make it concise. > The UTF-8 issue appears to be present in autopkgtests, but I can't > remember if this is an old or a new issue. IIRC there was something on > debian-devel about how they're going to become more important for trixie > or trixie+1. I think it said the bounty would be dropped and some sort > of penalty or block would be introduced. Test this with > > $ autopkgtest -- schroot sid-amd64-sbuild > > Do these pass on your systems? I have configured my sbuild to run autopkgtest (which should use the same chroot) and it passes, which I believe is the same effect. > > And here's an interesting discussion that is, at worst, tangentially > related to the problem: > https://stackoverflow.com/questions/2223882/whats-the-difference-between-utf-8-and-utf-8-with-bom > Thanks for the link! BTW, I saw that you started working on syncing to more recent version, so I believe the package is now in good hands :) (Also I believe it now starts to support deadgrep which is not available in Debian yet. More future work it seems.) > > Cheers, > Nicholas > -- Xiyue Deng
Attachment:
signature.asc
Description: PGP signature