Helmut Grohne:
Hi,
Hi Helmut
Thanks for your work - both on this specific problem and in general!
On Mon, Nov 21, 2022 at 06:08:22PM +0100, Niels Thykier wrote:
Axel Beckert:
Could this be https://bugs.debian.org/1023286 in fakeroot as well as
Niels pointed out in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024520#37 ?
It is.
So the underlying fakeroot bug has been fixed since. I don't think this
actually is a debhelper bug anymore and suggest to just close it once
the pratical effects have been mitigated.
Indeed, will do with this email.
Helmut and I discussed this on IRC and Helmut's findings is based on that
IRC discussion between him and I in relation to #1023286. (Which people not
IRC had no chance of knowing, so putting the context here for good measure)
Given that the fakeroot bug has been fixed, I have rerun the dbgsym
importer (now that no new problems can be added). Quite a number of
packages have fixed themselves since the last run. Very few were added.
I'm attaching a list of affected packages in format
"binarypackage_version_architecture". Can I ask the release team to just
binNMU all of them?
For reference, it was not clear to me that the binNMUs proposed have
been run, so I submitted a formal request to release.debian.org for the
dbgsym packages you already identified (you should get a bug report
about that soon).
I chose to use architecture-less binNMU and recommend an "ANY" binNMU to
avoid M-A:same problems. Feel free to follow up on that bug when you get
the CC from the BTS if you have any concerns in that regard.
What is a bit unclear to me is whether this is sufficient. We know
-dbgsym packages to be affected (and which), but how about regular
packages? Can they be affected as well?
In theory, yes. Though I doubt there will be many left that did not
also build a dbgsym. My guess is that we are in the 0-5 range now with
these binNMUs out the door.
If yes, we could download all .debs and record owner/group/mode for each
file after normalizing s,/${DEB_HOST_MULTIARCH}/,/, and highlight all
packages where these aspects vary accross architectures (with the
intuition that 64bit achitectures should generally be right). Does this
make sense? Does this likely encounter issues? Is this approach
exhaustive?
I think it is much more reliable and easier to check the owner / group
against the /usr/share/base-passwd/{group,passwd}.master files. For me
this:
1) Avoids having to compare a "correct" vs. a "possible faulty"
version, which reduces the amount of packages needed to be scanned.
We can limit ourselves to the 32bit architectures.
2) Avoids having to do path normalization to detect the problem.
But as mentioned above, I doubt there will many left once the dbgsym
binNMU run is complete. So any analysis done now in this space should
remove duplicates from your previous list.
In any case, binNMUing the packages from the attached list is something
actionable right now. It's just 500 packages on four architectures left.
Helmut
Once again, thanks for your work here. I passed it on to the release
managers.
Best regards,
Niels
