Processed: Re: qhelpgenerator-qt5: emits .qch file attribute entries with unpredictable ordering
Processing control commands: > tags -1 fixed-upstream Bug #1059592 [qhelpgenerator-qt5] qhelpgenerator-qt5: emits .qch file attribute entries with unpredictable ordering Added tag(s) fixed-upstream. -- 1059592: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059592: qhelpgenerator-qt5: emits .qch file attribute entries with unpredictable ordering
Package: qhelpgenerator-qt5 Followup-For: Bug #1059592 Control: tags -1 fixed-upstream Please note: it appears that a fix[1] that addresses this same problem is already included in v6.5.0 of qttools.git upstream. [1] - https://codereview.qt-project.org/c/qt/qttools/+/416699
Processed: Re: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Processing control commands: > forwarded -1 https://codereview.qt-project.org/c/qt/qttools/+/527972 Bug #1059631 [qhelpgenerator-qt5] qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized Set Bug forwarded-to-address to 'https://codereview.qt-project.org/c/qt/qttools/+/527972'. -- 1059631: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059631 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Package: qhelpgenerator-qt5 Followup-For: Bug #1059631 X-Debbugs-Cc: mity...@debian.org Control: forwarded -1 https://codereview.qt-project.org/c/qt/qttools/+/527972 Hi Dmitry, On Sat, 30 Dec 2023 22:50:47, Dmitry wrote: > Thank you for the patch! > > Any chance you can forward it to upstream Qt? See [1] for the details. Yep, certainly - done. Thanks!
Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Hi James! On Sat, Dec 30, 2023 at 05:12:52PM +, James Addison wrote: > Package: qhelpgenerator-qt5 > Followup-For: Bug #1059631 > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > My apologies: I had indeed misdiagnosed the problem here. > > The code that inserts into the SettingsTable, where the problem reported here > manifests, is unrelated to the patch from bug #875847 - there is a separate > check for SOURCE_CODE_EPOCH in the src/assistant/qhelpgenerator/main.cpp file. > > To test a fix, I used the following commands to replicate the problem: > > $ SOURCE_DATE_EPOCH=1503951538 qhelpgenerator > examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o > foo.qch > $ TZ=GMT+8 SOURCE_DATE_EPOCH=1503951538 qhelpgenerator > examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o > bar.qch > > Please find attached a patch to address the problem. Note that I decided to > patch both SOURCE_CODE_EPOCH locations for consistency, despite the fact that > only the main.cpp code site was confirmed affected. Thank you for the patch! Any chance you can forward it to upstream Qt? See [1] for the details. I could forward it myself, but upstream requires signing the CLA so they will not always accept a patch which is forwarded not by its author. [1]: https://wiki.qt.io/Gerrit_Introduction -- Dmitry Shachnev signature.asc Description: PGP signature
Processed: Re: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Processing control commands: > tags -1 patch Bug #1059631 [qhelpgenerator-qt5] qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized Added tag(s) patch. -- 1059631: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059631 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Package: qhelpgenerator-qt5
Followup-For: Bug #1059631
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
My apologies: I had indeed misdiagnosed the problem here.
The code that inserts into the SettingsTable, where the problem reported here
manifests, is unrelated to the patch from bug #875847 - there is a separate
check for SOURCE_CODE_EPOCH in the src/assistant/qhelpgenerator/main.cpp file.
To test a fix, I used the following commands to replicate the problem:
$ SOURCE_DATE_EPOCH=1503951538 qhelpgenerator
examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o
foo.qch
$ TZ=GMT+8 SOURCE_DATE_EPOCH=1503951538 qhelpgenerator
examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o
bar.qch
Please find attached a patch to address the problem. Note that I decided to
patch both SOURCE_CODE_EPOCH locations for consistency, despite the fact that
only the main.cpp code site was confirmed affected.
Description: helpgenerator: clear UTC offset to zero when reading
SOURCE_DATE_EPOCH value
Author: James Addison
Bug-Debian: https://bugs.debian.org/1059631
---
qttools-opensource-src-5.15.10.orig/src/assistant/help/qhelpcollectionhandler.cpp
+++ qttools-opensource-src-5.15.10/src/assistant/help/qhelpcollectionhandler.cpp
@@ -2202,8 +2202,10 @@ bool QHelpCollectionHandler::registerInd
const QString sourceDateEpochStr =
qEnvironmentVariable("SOURCE_DATE_EPOCH");
bool ok;
const qlonglong sourceDateEpoch = sourceDateEpochStr.toLongLong(&ok);
-if (ok && sourceDateEpoch < lastModified.toSecsSinceEpoch())
+if (ok && sourceDateEpoch < lastModified.toSecsSinceEpoch()) {
+lastModified.setOffsetFromUtc(0);
lastModified.setSecsSinceEpoch(sourceDateEpoch);
+}
}
m_query->addBindValue(lastModified.toString(Qt::ISODate));
if (!m_query->exec())
--- qttools-opensource-src-5.15.10.orig/src/assistant/qhelpgenerator/main.cpp
+++ qttools-opensource-src-5.15.10/src/assistant/qhelpgenerator/main.cpp
@@ -116,6 +116,7 @@ int generateCollectionFile(const QByteAr
if (!config.filesToRegister().isEmpty()) {
if (Q_UNLIKELY(qEnvironmentVariableIsSet("SOURCE_DATE_EPOCH"))) {
QDateTime dt;
+dt.setOffsetFromUtc(0);
dt.setSecsSinceEpoch(qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH"));
CollectionConfiguration::updateLastRegisterTime(helpEngine, dt);
} else {
Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Package: qhelpgenerator-qt5 Followup-For: Bug #1059631 X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org On Fri, 29 Dec 2023 15:30:58, I wrote: > Inspecting the patch from #875847 and the values that appear in the diffoscope > output from the build logs: the SOURCE_DATE_EPOCH value of the build is used, > as expected, to improve the reproducibility of the build. It takes the value > of the most recent Debian changelog entry. > > However: the patch mutates an existing QT QDateTime instance (last_modified) > to > store the seconds-since-epoch value -- without specifying a timezone for the > value. ... > My sense is that the LastRegisterTime column value is probably intended to be > stored in UTC; it may be sufficient to set the timezone of the last_modified > instance to UTC -- making careful to ensure that it is indeed a _set_ timezone > operation and not a _translate_ timezone operation. In hindsight: I think I've misunderstood some of the details here. If the root cause is indeed a non-UTC timezone on the last_modified object, then maybe it does in fact make sense to translate that object's value into UTC -- because that would mean that we the date-string we bind is always UTC-based, regardless of whether SOURCE_DATE_EPOCH is set. Related, though: I also don't yet understand why the date string that appears in the INSERT statement does not include a timezone offset (+1200, for example). My reading of the QT documentation[1] is that a timezone offset will be included in the formatted string for non-UTC date+time objects.. I'll do some more investigation. [1] - https://doc.qt.io/qt-5/qt.html#DateFormat-enum
