Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hi Andreas and Ralf, On Mon, Jul 17, 2023 at 04:08:48PM +0200, Ralf Treinen wrote: > > Moving the usertag to the qa namespace sounds like a good idea. > > I agree Thank you > Sounds like a good idea. However, I do not think that usertags support > a hierarchy of tags. So maybe different specific usertags with a common > prefix, like > > fileconflict-installation (error occurs when one tries to install two > packages togther) > fileconflict-upgrade (error occurs when upgrading, due to missing > breaks/replaces) > fileconflict-directory (error occuring due to /usr merge) Can either of you elaborate on the need to further classify the kind of conflict (file / directory / symlink / ...) or the kind of cause (installation / upgrade / ...)? Are you ok with explicitly excluding issues that only arise as a result of /usr-merge. These have a temporary cause and will vanish before too long. Due to the automatic bug filing that I hope to be doing, I need very precise tagging for them. Often times, it is initially not trivial to figure out whether a conflict only arises from installation or upgrades. Rather I propose to have a grab-bag tag for all of them. That allows us to move forward with less complexity and makes it easier to understand for everyone. Most of these issues result in an unpack error one way or another, but the symlink vs something else conflicts may result in unpack-dependent behaviour. I think we have consensus on using the debian-qa list, but I've seen file-overwrite and fileconflict-* as proposals with varying subclassification now. While we don't have a tag hierarchy on a technical level, Paul indicated that we may establish a hierarchy using processes. Using fileconflict makes it easy to establish a fileconflict-* subclassification later (by having the qa bot automatically add the super tag when it sees a sub tag). Is this convincing enough to move forward with the generic debian...@lists.debian.org usertag fileconflict rather than something more detailed? Is this also convincing enough to extend it to cover non-file conflicts or do you want a different tag for that? Should the tag also cover m-a:same file conflicts? I certainly won't object to doing a subclassification and I'm happy to add the subclass tags if doing so does not incur unreasonable implementation cost, but I don't want to participate in designing them nor updating existing tags. My need here is automatically ignoring detected issues that already are reported and the generic variant is sufficient for doing that. Helmut
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
On Mon, 2023-07-17 at 07:16 +0200, Helmut Grohne wrote: > Then I found trei...@debian.org using edos-file-overwrite. That latter > one seems like what I need here. Should we move it to the qa space and > drop the edos part? I suggest debian...@lists.debian.org usertags > file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? I have scripts to automate usertags changes and watch weekly diffs. The QA copy runs from cron fixing some typos and my fork is modified and run when I notice any weird changes. The script can be used to easily perform moving and or renaming of usertags as needed here. https://salsa.debian.org/qa/qa/blob/master/data/cronjobs/usertags-fixes https://salsa.debian.org/pabs/qa/blob/master/data/cronjobs/usertags-fixes editor data/cronjobs/usertags-fixes mkdir tmp rsync --timeout=60 --recursive --delete rsync://bugs-mirror.debian.org/bts-spool-index/user/ tmp/all/ ./data/cronjobs/usertags-fixes --debug tmp -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hello, On Mon, Jul 17, 2023 at 10:35:24AM +0200, Andreas Beckmann wrote: > On 17/07/2023 07.16, Helmut Grohne wrote: > > Then I found trei...@debian.org using edos-file-overwrite. That latter > > one seems like what I need here. Should we move it to the qa space and > > drop the edos part? I suggest debian...@lists.debian.org usertags > > file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? > > Moving the usertag to the qa namespace sounds like a good idea. I agree > And dropping the ancient edos prefix ... Yes. At the origin, the edos prefix was useful for us as the tool used to detect these bugs came from the edos project, but that project is over since a long time. And the tag has been used since then by others for tagging these kind of bugs discovered independently. So yes, time to simplify. > edos-file-overwrite has been used primarily for file-vs-file conflicts (as > these are the only ones detectable by analyzing .contents files) That was it's original target, and more specifically between packages in the same distro, but as Andreas explained that was extended by others to upgrading bugs: > We also didn't distinguish between file overwrites happening within a distro > (two packages in sid shipping the same file) and on upgrades (the file in > question moved between packages with insufficient Breaks+Replaces). Maybe we > should. Sounds like a good idea. However, I do not think that usertags support a hierarchy of tags. So maybe different specific usertags with a common prefix, like fileconflict-installation (error occurs when one tries to install two packages togther) fileconflict-upgrade (error occurs when upgrading, due to missing breaks/replaces) fileconflict-directory (error occuring due to /usr merge) Or something in this direction. -Ralf.
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
On 17/07/2023 07.16, Helmut Grohne wrote: Then I found trei...@debian.org using edos-file-overwrite. That latter one seems like what I need here. Should we move it to the qa space and drop the edos part? I suggest debian...@lists.debian.org usertags file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? Moving the usertag to the qa namespace sounds like a good idea. And dropping the ancient edos prefix ... edos-file-overwrite has been used primarily for file-vs-file conflicts (as these are the only ones detectable by analyzing .contents files) IIRC you were looking also for other cases, e.g. file-vs-directory. Maybe we should use two tags in combination, the general file-overwrite and a more fine-grained one describing the actual problem even better. We also didn't distinguish between file overwrites happening within a distro (two packages in sid shipping the same file) and on upgrades (the file in question moved between packages with insufficient Breaks+Replaces). Maybe we should. There is also the case of files that shouldn't be shipped in any package (e.g. /usr/lib/python3/dist-packages/examples/README.txt), which usually shows up with a file-overwrite error if more than one package ships the file. IIRC I didn't tag these with the edos-file-overwrite usertag. (Such files are usually also reported to lintian to flag them as "overly generic filename", e.g. #947264) Is there some place where these tags are documented? Ideally some wiki page with links to the corresponding bts query to get the bug lists ... And information how these errors are searched for (semi-)automatically. Andreas
usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hi, On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > ## Usertagging bugs > > In order to avoid filing duplicates, I need a usertagging scheme for > bugs. Are there opinions on what user I should use for this? In the > simplest instance, I can use my DD login. Roughly speaking every issue > type shall translate to an individual usertag. Is there a common usertag > for undeclared file conflicts to reuse? I did not see any replies towards this aspect. I researched the situation and found that a longer while ago a...@grinser.de and later a...@debian.org used qa-file-conflict. I also discovered that Adreas uses debian...@lists.debian.org together with replaces-without-breaks, which is not what I'm looking for, but closely related. Then I found trei...@debian.org using edos-file-overwrite. That latter one seems like what I need here. Should we move it to the qa space and drop the edos part? I suggest debian...@lists.debian.org usertags file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? What are the precise semantics of the tag? I imagine that it should only be filed against binary packages (one or more) and never with source packages. In case the causing package is known, it should be filed with the causing package and a version while other binary packages should be listed in affects. Otherwise, the bug should be filed against all involved binary packages. It is ok to group related conflicts by filing against multiple binary packages. These bugs should normally be release critical. These semantics allow machine consumption and facilitate avoiding duplicates in an automatic bug filing (to be agreed to). Does anyone have any objections to using this tag with these semantics? It would be most useful if other people filing such bugs would start using this usertag of course. :) I'm adding as possible metadata update at the end of this mail. It only handles conflicts involving possibly aliased paths though as those are my primary interest here. Helmut user debian...@lists.debian.org # android-libnativehelper/bullseye-backports vs android-libnativehelper-dev/bullseye usertags 1040323 + file-overwrite affects 1040323 + android-libnativehelper-dev # cadabra2/bullseye vs python3-notebook usertags 1036021 + file-overwrite affects 1036021 + python3-notebook # discodos/unstable vs mono-devel usertags 966115 + file-overwrite affects 966115 + mono-devel # firebird-utils/experimental vs firebird3.0-server usertags 1040321 + file-overwrite affects 1040321 + firebird3.0-server # kodi-addons-dev/bullseye-backports vs kodi-addons-dev-common/bullseye usertags 1040319 + file-overwrite affects 1040319 + kodi-addons-dev-common # occt vs oce mess usertags 1037067 + file-overwrite affects 1037067 + liboce-modeling-dev liboce-visualization-dev # rawloader usertags 1041299 + file-overwrite affects 1041299 + libplucene-perl graphicsmagick-imagemagick-compat # qt6-base-dev/experimental vs libqt6opengl6-dev usertags 1041300 + file-overwrite affects 1041300 + libqt6opengl6-dev # nex vs nvi usertags 1022957 + file-overwrite affects 1022957 + nvi # nfs-ganesha-ceph/bullseye-backports vs nfs-ganesha/bullseye usertags 1040362 + file-overwrite affects 1040362 + nfs-ganesha
