Bug 4163 (pkgdb_sync) - Tracker of pkgdb sync with rfpkg retire
Summary: Tracker of pkgdb sync with rfpkg retire
Status: NEW
Alias: pkgdb_sync
Product: Infrastructure
Classification: Unclassified
Component: General (show other bugs)
Version: NA
Hardware: All GNU/Linux
: P5 normal
Assignee: Nicolas Chauvet
URL:
Depends on: 4341 4459 4652 4939
Blocks:
  Show dependency treegraph
 
Reported: 2016-08-03 04:29 CEST by Sérgio Basto
Modified: 2021-10-28 20:54 CEST (History)
4 users (show)

See Also:
namespace:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sérgio Basto 2016-08-03 04:29:13 CEST
This bug will track package that are orphan and need be retired on pkgdb . 

please be sure to use rfpkg retire. And block this tracker ? further instruction soon.
Comment 1 leigh scott 2016-09-30 07:38:34 CEST
rfpkg retire doesn't work, can foo2zjs be marked as dead package in the packagedb


https://admin.rpmfusion.org/pkgdb/package/free/foo2zjs/

It's in fedora

https://bugzilla.redhat.com/show_bug.cgi?id=970393
Comment 2 Sérgio Basto 2016-09-30 07:53:55 CEST
(In reply to leigh scott from comment #1)
> rfpkg retire doesn't work, can foo2zjs be marked as dead package in the
> packagedb
> 
> 
> https://admin.rpmfusion.org/pkgdb/package/free/foo2zjs/
> 
> It's in fedora
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=970393

This message "Could not retire package: Un-expected openid provider asked: https://admin.rpmfusion.org/pkgdb/login/" is about login in pkgdb and mark package as retired in pkgdb and is not working . So you can ignore message , cgit is updated with dead.package [1], is the expected, for now. 

[1] https://pkgs.rpmfusion.org/cgit/free/foo2zjs.git/
Comment 3 Nicolas Chauvet 2019-04-01 14:23:49 CEST
According to Leigh pkgdb-cli now work with our pkgdb instance.
rfpkg retire should works as appropriate.

But we still need this report to block build from koji to appear on repos.
Comment 4 leigh scott 2019-04-01 14:30:32 CEST
I think a file edit might be required for the python3-fedora package


/usr/lib/python3.7/site-packages/fedora/client/openidproxyclient.py

and change fedoraproject.org to rpmfusion.org

Example:

#FEDORA_OPENID_API = 'https://id.fedoraproject.org/api/v1/'
FEDORA_OPENID_API = 'https://id.rpmfusion.org/api/v1/'
#FEDORA_OPENID_RE = re.compile(r'^http(s)?:\/\/id\.(|stg.|dev.)?rpmfusion\.org(/)?')
FEDORA_OPENID_RE = re.compile(r'^http(s)?:\/\/id\.(|stg.|dev.)?rpmfusion\.org(/)?')


Perhaps it could be renamed for rpmfusion (python3-rpmfusion)?
Comment 5 Nicolas Chauvet 2019-04-01 14:38:50 CEST
(In reply to leigh scott from comment #4)
> I think a file edit might be required for the python3-fedora package
> 
> 
> /usr/lib/python3.7/site-packages/fedora/client/openidproxyclient.py
I would prefer to avoid having this change to propagate into every tool we need to maintain.

If we could override the FEDORA_OPENID_API and FEDORA_OPENID_RE without having to provide our own fork of python-fedora that would be fine.
Comment 6 Jeffkonaa 2021-10-28 20:54:41 CEST
"The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1." http://www-look-4.com/category/technology/

The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), https://komiya-dental.com/health/healthy-foods/ and both source and destination do not overlap (overlapping depends on the source and destination layout, not on the "n" value) http://www.iu-bloomington.com/computers/invisible-with-vpn/

However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value. https://waytowhatsnext.com/sports/navona/
"The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1."
https://www.webb-dev.co.uk/sports/sports-and-health/
The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination http://www.wearelondonmade.com/category/tech/ do not overlap (overlapping depends on the source and destination layout, not on the "n" value)

However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value. http://www.jopspeech.com/category/technology/
"The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1."
http://joerg.li/category/technology/
The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination do not http://connstr.net/category/technology/ overlap (overlapping depends on the source and destination layout, not on the "n" value)

However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value. http://embermanchester.uk/category/technology/
"The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1."
 http://www.slipstone.co.uk/category/technology/
The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination do not overlap http://www.logoarts.co.uk/category/technology/ (overlapping depends on the source and destination layout, not on the "n" value)

However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value. http://www.acpirateradio.co.uk/category/technology/
"The strncat() function shall append not more than n bytes (a null byte and bytes that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1." http://www.compilatori.com/category/technology/

The wording imply that the third "n" argument is an additional boundary limit, not the destination buffer capacity (ie. the destination buffer is not implicitly SIZE_MAX), and both source and destination do not overlap (overlapping depends on the source and destination layout, not on the "n" value) 

However, it seems that the optimized strncat version of the GLIBC behaves incorrectly, when using this value.