Quoting Jonas Smedegaard (2023-08-15 17:26:13) > Quoting Boyuan Yang (2023-08-15 16:28:19) > > Hi, > > > > 在 2023-08-15星期二的 16:16 +0200，Jonas Smedegaard写道： > > > Quoting Boyuan Yang (2023-08-15 15:21:22) > > > > I am looking for advice in handling these MBF reports against packages > > > > that do > > > > irreversible changes to the source files during build every time (such > > > > as > > > > updating timestamp). A broad category would be packages using Gettext + > > > > PO > > > > combination with /usr/share/gettext/po/Makefile.in.in involved / > > > > embedded, > > > > where .po file that contains translation is updated every time, causing > > > > dpkg- > > > > source to complain the diff and quit when building twoce in a row. > > > > > > > > Take https://tracker.debian.org/pkg/ibus-array as an example. The > > > > upstream > > > > project does not include .pot template file in the source code. The > > > > logic > > > > of > > > > Makefile.in.in is to call msgmerge to update po translation file with > > > > generated .pot file when .pot file is not present. This causes at least > > > > the > > > > following diff after build: > > > > > > > > --- ibus-array-0.2.2.orig/po/zh_TW.po > > > > +++ ibus-array-0.2.2/po/zh_TW.po > > > > @@ -6,7 +6,7 @@ msgid "" > > > > msgstr "" > > > > "Project-Id-Version: ibus-array 0.2.2\n" > > > > "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n"; > > > > -"POT-Creation-Date: 2019-12-10 22:09+0800\n" > > > > +"POT-Creation-Date: 2023-08-15 09:07-0400\n" > > > > "PO-Revision-Date: 2019-12-10 22:12+0800\n" > > > > "Last-Translator: Anthony Fok <f...@debian.org>\n" > > > > "Language-Team: Chinese (traditional)\n" > > > > > > > > > > > > ... which would raise error on building twice in a row: > > > > > > > > dpkg-source: info: local changes detected, the modified files are: > > > > ibus-array/po/zh_TW.po > > > > dpkg-source: info: Hint: make sure the version in debian/changelog > > > > matches > > > > the > > > > unpacked source tree > > > > dpkg-source: info: you can integrate the local changes with dpkg-source > > > > -- > > > > commit > > > > dpkg-source: error: aborting due to unexpected upstream changes, see > > > > /tmp/ibus-array_0.2.2-2.diff.TnL2Yp > > > > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit > > > > status > > > > 2 > > > > > > > > > > > > I am looking for the advice to implement an elegant solution. What I can > > > > think > > > > of now is to persuade upstream to embed a copy of generated .pot > > > > template > > > > file > > > > in source code, which does not sound reasonable. Meanwhile since > > > > Makefile.in.in is somehow widely used, this issue likely already had > > > > impact on > > > > packages using gettext to handle translation. > > > > > > I see too options (aside from persuading upstream to not ship > > > autogenerated files in the first place, which is arguably the most > > > elegant but they might see it differently): > > > > > > a) repackage upstream source to exclude autogenerated *.pot files > > > > > > b) put aside autogenerated *.pot files during build > > > > > > For a) the common mechanism is to declare an Files-Excluded: field in > > > the header section of debian/copyright, and declare repacksuffix=+ds in > > > debian/watch (or repacksuffix=+dfsg if DFSG-conflicting files also need > > > to be excluded). More details on `man uscan`, e.g. in section > > > COPYRIGHT FILE EXAMPLES. > > > An example package using this method is node-expat. > > > > > > For b) I would suggest to move aside (but only if already done) in > > > debian/rules target execute_before_dh_auto_configure, and move it back > > > (forcefully - i.e. overwriting whatever might be there already - but > > > do nothing if no file was put aside) in debian/rules target > > > execute_after_dh_auto_clean. > > > An example package using this method is librdf-rdfa-parser-perl. > > > > I believe your take was in the reversed direction -- the issue is not about > > upstream including auto-generated files, the issue is that upstream is > > **not** > > including auto-generated POT files. > > > > * If auto-generated POT file is present, the PO file will not be updated > > using > > msgmerge(1). The source code is not modified during build. > > > > * If auto-generated POT file is missing, it will be generated on-the-fly > > with > > a new timestamp, and the PO file (in the source code) will be updated with a > > new timestamp. The source code is thus modified, making dpkg-source(1) to > > fail. > > Ah sorry, I indeed failed to read your scenario properly. > > If PO files are not updated when POT files exist (which sounds odd to > me) then perhaps simply touch those files to bring them into existence > during build, to fool msgmerge? Probably you will then need to touch > them with a date earlier than the PO files for the trick to work. And > make sure the fake POT file are removed in clean, and also excluded from > getting installed if needed.
No wait: If upstream source contains PO files then _those_ are autogenerated. The proper approach is IMO one of these: a) Repackage to exclude PO files, and clean both POT and PO files in clean target. b) put aside PO files during build, and restore upstream-provided PO files and clean POT files in clean (or dh_auto_clean) target. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
