It seems that packages.gentoo.org's bugs tab doesn't count full atoms (inc. version) as being associated with the package name. dev-libs/xmlsec has two bugs filed with an atom in their name, not simply the package name: dev-libs/xmlsec-1.2.31: stabilisation dev-libs/xmlsec-1.2.31[nss] test failures: aleksey-xmldsig-01/enveloping-md5-rsa-md5 Nothing is listed here: https://packages.gentoo.org/packages/dev-libs/xmlsec/bugs I've noticed a similar trend with other packages/bugs too.
*** Bug 837191 has been marked as a duplicate of this bug. ***
*** Bug 830332 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/sites/soko.git/commit/?id=33d0f7d12af820f1cad3ab7e16ca157642a69691 commit 33d0f7d12af820f1cad3ab7e16ca157642a69691 Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2023-04-06 06:09:01 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2023-04-06 06:12:22 +0000 updater/bugs: better matching of atoms to bug Better handling when there are whitespaces in the summary which was causing issues with matching. I'm unsure if I fixed the linked bug, but I suspect the answer is still no, I need a reproducer. Bug: https://bugs.gentoo.org/768174 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> pkg/portage/bugs/bugs.go | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
https://gitweb.gentoo.org/sites/soko.git/tree/pkg/portage/bugs/bugs.go?id=33d0f7d12af820f1cad3ab7e16ca157642a69691#n221 Sure that function can't extract even the second example from topic start. Are we interested in it? Is it a good idea to write test cases?
(In reply to Sam James from comment #0) > dev-libs/xmlsec-1.2.31[nss] test failures Another example of this: look at https://packages.gentoo.org/packages/sys-devel/gcc/bugs and compare with https://bugs.gentoo.org/buglist.cgi?quicksearch=sys-devel%2Fgcc&list_id=6813020. For example, "sys-devel/gcc[lto]: bootstrap comparison failure" is missing from the p.g.o list.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/sites/soko.git/commit/?id=115b10e9f9994a71acae84507010dba852f40080 commit 115b10e9f9994a71acae84507010dba852f40080 Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2023-04-12 09:56:19 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2023-04-12 10:02:48 +0000 updater/bugs: fetch old bugs The previous implementation was using the search facility with csv output, which had hard limit of 10000. No passing of offset & limit enabled us to fetch the next pages. By using the REST API, we can fetch beyond that limit without issues. Also implement a better "diff" update, which will only fetch the changed since a week ago. This will reduce the load on the server, and will enable us to update bugs more frequently. Reuse the `last_commit` field in DB to hold the last update time, which enables us to start with "empty" DB and still get the full history on next deploy. Closes: https://bugs.gentoo.org/768174 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> pkg/portage/bugs/bugs.go | 304 +++++++++++++++++++++++++---------------------- soko.go | 10 +- 2 files changed, 168 insertions(+), 146 deletions(-)
(In reply to Larry the Git Cow from comment #6) > The bug has been closed via the following commit(s): Arthur, thanks! But IMHO bug has been closed is incorrect. versionSpecifierToPackageAtom hasn't been changed => https://bugs.gentoo.org/768174#c4 is still totally actual. P.S. I could write test cases if we are interested. versionSpecifierToPackageAtom's semantics is/might be *much* more deep question.
(In reply to Alexander Kurakin from comment #7) > (In reply to Larry the Git Cow from comment #6) > > The bug has been closed via the following commit(s): > > Arthur, thanks! But IMHO bug has been closed is incorrect. > versionSpecifierToPackageAtom hasn't been changed => > https://bugs.gentoo.org/768174#c4 is still totally actual. > > P.S. I could write test cases if we are interested. > versionSpecifierToPackageAtom's semantics is/might be *much* more deep > question. Yeah, it takes time to deploy on production, you can see the current commit at https://packages.gentoo.org/about (it will take another ~5h I think to upgrade and update the bugs) For now, you can use the staging area to see it working better than previously :) https://packagestest.gentoo.org/packages/sys-devel/gcc/bugs
(In reply to Alexander Kurakin from comment #7) > (In reply to Larry the Git Cow from comment #6) > > The bug has been closed via the following commit(s): > > Arthur, thanks! But IMHO bug has been closed is incorrect. > versionSpecifierToPackageAtom hasn't been changed => > https://bugs.gentoo.org/768174#c4 is still totally actual. > > P.S. I could write test cases if we are interested. > versionSpecifierToPackageAtom's semantics is/might be *much* more deep > question. You need to look at the develop branch.
Well, I talked about 33d0f7d12af820f1cad3ab7e16ca157642a69691 exactly. Yes, I was incorrect about `dev-libs/xmlsec-1.2.31[nss]` case. But, explain my comments. In commit 33d0f7d12af820f1cad3ab7e16ca157642a69691 we have (https://gitweb.gentoo.org/sites/soko.git/tree/pkg/portage/bugs/bugs.go?id=115b10e9f9994a71acae84507010dba852f40080#n240): > var versionNumber = regexp.MustCompile(`-[0-9]`) > > // versionSpecifierToPackageAtom returns the package atom from a given version specifier > func versionSpecifierToPackageAtom(versionSpecifier string) string { > gpackage := strings.ReplaceAll(versionSpecifier, ">", "") > gpackage = strings.ReplaceAll(gpackage, "<", "") > gpackage = strings.ReplaceAll(gpackage, "=", "") > gpackage = strings.ReplaceAll(gpackage, "~", "") > > gpackage, _, _ = strings.Cut(gpackage, ":") > > gpackage = versionNumber.Split(gpackage, 2)[0] > > return gpackage > } And some bugs from https://bugs.gentoo.org/buglist.cgi?quicksearch=dev-lang%2Fpython&list_id=6816639 : * [guru] app-backup/pika-backup-0.5.2-r1 fails to compile with dev-lang/python-exec[-native-symlinks] * Building dev-lang/python with GCC 12 and "-g" fails with "error: inlining failed in call to 'always_inline'" * dev-libs/libwacom-2.6.0 fails to compile with dev-lang/python-exec[-native-symlinks] * <dev-lang/python-{3.10.10_p2,3.9.16_p2,3.8.16_p3}, <dev-python/pypy3-7.3.11_p1: urllib.parse blocklist bypass * dev-lang/python-3.8.10_p2/3.9.5_p2 Default-to-TLS-1.2: break some libs: urllib3/httplib2 cause DH_KEY_TOO_SMALL Don't know which packages should be provided by but versionSpecifierToPackageAtom doesn't seem flexible (or strict-formal). But yes, now I understand it's another bug (a new one).
