Control: tags 1072733 moreinfo Control: reopen 1071007 = Hello all,
I wasn't subscribed to both bugs so I missed some of the replies, I'm subscribed now. I'm sending this reply to both #1072733 and #1071007 because they are related and I'm trying to clarify the situation on both. Summary: #1072733 is a bug caused by a tentative fix of #1071007, I believe Francisco made the right approach there, but maybe I'm missing something, Chris? #1071007 is still not fully fixed as the approach is problematic. We should not submit workarounds to upstream when they already pointed out a PR which should address the issue. If we need to perform a workaround on our side in the meantime, we need to make sure it works and we should not submit it upstream (they already have the proper fix in progress). Plan: Let's try to fix this issue using upstream's PR. If we spot issues with the PR, we can contribute back (but let's make sure it makes sense to upstream). If we end up performing a workaround, let's make sure it works and doesn't cause other issues. It's ok to let the package be removed from testing until this gets fixed. If we really want to avoid the package being removed from testing, we can package a previous release where the issue wasn't present (using the "+really" versioning mechanism). The end goal is to get this fixed before the freeze, so we have time. Now the lengthy replies below: For #1072733: Chris > Per Debian policy this is not the correct solution for naming conflicts. Both > maintainer (teams), please find a policy compliant solution together. The solution for this one seems correct, it's a Conflict + Replaces because both packages provide a "sherlock" library. Am I missing something? Note that this bug is different from #1071007, they look very similar and initially I thought they were a dupe. Nilson > Your package should not be called in d/rules: > export PYBUILD_NAME=python-sherlock > or something similar that wasn't exactly sherlock? We should keep the same name as changing it will cause issues for users, this is a real case of a conflicting library name. For #1071007: Nilson, > I just pushed a new version of shelock with a fix for the problem in the > "master" branch. If that's ok, I'll do a merge. > https://salsa.debian.org/pkg-security-team/sherlock/-/tree/master?ref_type=heads We follow the DEP14 for git branching, that means we do namespacing. When dealing with temp/wip branches, the recommendation is to push to $username/$branchname. If you push to master, it will lead to confusion as to which branch is the main one (it's debian/master). It looks like that branch has been merged into debian/master but master has not been deleted yet. We have to remove that branch. > This led to the bug being reopened twice as RC, leading to its removal from > "testing" even after > pycrc had resolved its conflict issue. We always try to avoid getting a package removed from testing, but sometimes it happens and that's ok, once the issue is fixed the package will get back. This is only worrying when removing the package causes a cascade effect or when we are close to the freeze for stable. We don't have to rush for a fix in this case, it's better to be precise. > I made a pull request to usptream > https://github.com/sherlock-project/sherlock/pull/2147 We should not be submitting this to upstream when they already pointed us to a PR that solves the issue. We have to try working with that PR. If that's not possible, we can patch it ourselves with a different approach, but we should not submit our workaround to upstream because they already have a proper solution in progress. > In accordance with the other Package Uploaders, > Debian Developer, Francisco Vilmar. > I will be closing the bug. > Since the problem itself, with Sherlock installing its modules in the root of the packages, has been fixed. The upload done by Francisco for #1072733 can't be used to close #1071007, he was fixing an issue caused by one of the uploads that tried to fix #1071007, it was not fixing #1071007 itself. > sherlock (0.14.4+git20240531.e5ad3c4-1) unstable; urgency=medium > . > * New upstream version 0.14.4+git20240531.e5ad3c4 > * debian/patches: Adjusted directory installation package (Closes: #1071007) This upload is indeed trying to solve #1071007 by patching the source code instead of pulling the upstream PR. Looking at the list of files shiped [0], the egginfo files are in the wrong place. I also find the following commit confusing: https://salsa.debian.org/pkg-security-team/sherlock/-/commit/fc6e9929b1018d411df599a68d5898e42bfe6560 The commit description does not mention what/why the changes are being made, for example, why the change from dh_auto_install to dh_install. Cheers, [0] https://packages.debian.org/trixie/all/sherlock/filelist -- Samuel Henrique <samueloph>
