Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)
On Fri, Apr 19, 2024 at 2:29 PM Maxwell G wrote: > On Fri Apr 19, 2024 at 14:23 +1000, Nathan Scott wrote: > > The package does not have any Obsoletes, so nothing should happen unless > users take explicit action to install valkey. > Yes, that's my point - if someone installs valkey, their redis installation is essentially trashed. I'd say "fair enough" if this was rawhide and we're working on the transition still, but this is stable Fedora, EPEL and user's data. cheers. -- Nathan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)
Hi Neal, On Thu, Apr 18, 2024 at 1:02 PM Neal Gompa wrote: > On Wed, Apr 17, 2024 at 10:43 PM Nathan Scott wrote: > > On Thu, Apr 18, 2024 at 12:29 PM Neal Gompa wrote: > > > [...] > > > retaining Redis will just hurt us in the long term. > > > > Noone is saying we should retain Redis. I'm advocating for a more > > appropriate transition that is respectful of the work and expertise the > > existing package maintainers bring. > > > > I think f41 is appropriate and possible, but "more haste, less speed" > > is the way to get there, with minimal breakage to Fedora and users. > > > > From my perspective, I don't see any breakage happening. We also > haven't *done* anything yet. > Sooo, about that... :) I see there is a valkey build winging its way toward f39 and f38 now: https://bodhi.fedoraproject.org/updates/?packages=valkey If someone has an active redis installation on those systems and install that - aren't they in for a bit of a surprise? Correct me if I'm wrong, but this will replace redis - leaving /var/lib/redis with their current data, and start a new "redis-server" (aka "valkey-server") process writing into a new, empty rdb file below /var/lib/valkey, no? If so, how do they reconcile those split rdb files? Let's slow down a bit, it's not so urgent that we risk peoples data. cheers. -- Nathan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Redis will no longer be OSS... now what?
On Thu, Apr 18, 2024 at 1:05 AM Leon Fauster via devel wrote: > > > > Thanks for the work on it. I wonder why valkey conflicts with redis, > > redict for instance does not!? Is this a decision for a preferred > > upgrade path? What about leaving this decision to the user (keydb, > > redict, valkey, redis on RHEL, etc) and allowing parallel installation > > for testing, decision making processes and migration. > > > > > > It is due to redict renaming some libs, while valkey has opted to retain > > "redis" on some lib file names. # rpm -ql redis | grep lib | grep -v build-id /usr/lib/systemd/system/redis-sentinel.service /usr/lib/systemd/system/redis.service /usr/lib64/redis /usr/lib64/redis/modules /var/lib/redis There aren't any lib files in either valkey or redis, and none of the directories listed above are in conflict between the two packages. I notice also a Conflict between valkey-devel and redis-devel has been added, and as much as I appreciate the sentiment (we're all disappointed with what has happened), I can't see justification for that either. > It seems to be just links in the bin directory that overlaps (and not > libs). Why not putting these links into the compat subpackage including > also the conflict statement. That would allow to install the main > package side-by-side to the other key-value-db forks. +1 https://src.fedoraproject.org/rpms/valkey/pull-request/2 cheers. -- Nathan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)
Hi Neal, On Thu, Apr 18, 2024 at 12:29 PM Neal Gompa wrote: > [...] > retaining Redis will just hurt us in the long term. Noone is saying we should retain Redis. I'm advocating for a more appropriate transition that is respectful of the work and expertise the existing package maintainers bring. I think f41 is appropriate and possible, but "more haste, less speed" is the way to get there, with minimal breakage to Fedora and users. cheers. -- Nathan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)
Hi all, On Thu, Apr 18, 2024 at 2:38 AM Maxwell G wrote: > > Thank you for submitting this! +1 > > == Owner == > > * Name: [[User:jonathanspw|Jonathan Wright]] > > * Email: jonat...@almalinux.org > > It would be nice to have Remi who currently maintains redis on board as well. > This is the second time this has been requested, but not yet actioned. https://bugzilla.redhat.com/show_bug.cgi?id=2274206 https://src.fedoraproject.org/rpms/valkey https://src.fedoraproject.org/rpms/redis Can we resolve this before allowing this Change Proposal to proceed, please? I think its in Fedora's interest to see 'new redis' maintained by group, rather than an individual, if the existing maintainers wish to (continue to) be involved. The 'new' valkey package is very closely derived from redis packaging which other Fedora maintainers have been looking after for ~14 years. There is no big rush to switch AFAICT though, as Redis[Labs] stated they continue to provide updates for redis-7.2.4 (including CVE fixes, which is a big part of the Fedora workload) for the foreseeable future. Some other technical questions: - it could be advantageous if the new compat sub-package contained the redis binary symlinks & not the primary valkey package (this could allow valkey and redict packages to coexist, for example). Long-term we may want to drop those entirely (along with the compat package, to complete the transition away from Redis). - what happened to the man page patch Remi made? we should carry it forward into the new package (and try again with new upstream folks to get it merged there). - we need to coordinate on the handling of the redis modules in Fedora - RediSearch, rebloom and rejson. I've begun transitioning these working with upstream, but more time would be helpful. cheers. -- Nathan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: python packaging assistance sought for xgboost
Thanks Miro - that size pointer was helpful. Indeed, the only thing in the wheel are 3 metadata files. Things seem to be OK up to this point in the upstream hatchling build: https://github.com/dmlc/xgboost/blob/43897b829680d241491abe1ecd46b2ba9d338967/python-package/packager/pep517.py#L86 ... that temporary directory is populated with all the python files in what looks like a good format, but the generated wheel is essentially empty. Is there any way to see what's happening inside that hatchling.build.build_wheel call I wonder? In related news, a setup.py based build works correctly. Perhaps it would be simpler to just give up on the upstream python build bits? (already having to patch them a fair bit since they don't supported versioned soname on libxgboost). Thanks for all the insights. cheers. -- Nathan -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: python packaging assistance sought for xgboost
Thanks for the assistance Miro. I've uploaded a local build log here: https://nathans.fedorapeople.org/xgboost/build.log AFAICS the python parts of the %install step seemed to have worked, but based on Sandro's pointer I can see many files are missing. cheers. -- Nathan -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: python packaging assistance sought for xgboost
Thanks for the assistance Sandro! What I see is ... BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/[...] <- all manner of files from the C++ build/install, then ... BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12 BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages/xgboost-2.0.2.dist-info BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages/xgboost-2.0.2.dist-info/METADATA BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages/xgboost-2.0.2.dist-info/WHEEL BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages/xgboost-2.0.2.dist-info/INSTALLER But nothing that looks like actual python code has been installed. I'll followup with the build log shortly. cheers. -- Nathan -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
python packaging assistance sought for xgboost
Hi all,
I've recently been packaging xgboost for Fedora. It's a C++ project using
cmake, with a python module on the side (all in one source tarball):
https://nathans.fedorapeople.org/xgboost/
The dependent dmlc-core package is here:
https://nathans.fedorapeople.org/dmlc-core/
Everything is prepared and working from the C++ and shared library
perspectives, but I'm struggling with getting the python module to install
using latest Fedora python spec guidelines. Can anyone point out where I've
gone wrong? (looks like its during the final python step in the spec %install)
https://nathans.fedorapeople.org/xgboost/xgboost.spec+python shows my additions
to add the python sub-package and this is the error I now see (this is from the
"%pyproject_save_files xgboost" line right at the end of %install):
Traceback (most recent call last):
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 775, in
main(cli_args)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 730, in main
file_section, module_names = pyproject_save_files_and_modules(
^
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 720, in
pyproject_save_files_and_modules
generate_file_list(paths_dict, globs, include_auto)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 534, in
generate_file_list
raise ValueError(f"Globs did not match any module: {missed_text}")
ValueError: Globs did not match any module: xgboost
error: Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: hiredis soname bump
On Mon, Jan 17, 2022 at 10:35 AM Iñaki Ucar wrote: > On Mon, 17 Jan 2022 at 00:21, Nathan Scott wrote: > > On Mon, Jan 17, 2022 at 7:05 AM Kevin Fenzi wrote: > > > > > > Greetings. > > > > > > We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to > > > 1.0.2, which includes a soname bump. > > > > I think upstream may have reverted this change FWIW ... > > https://github.com/redis/hiredis/issues/990 > > This refers to the incorrect SONAME bump in 1.0.1 with respect to > 1.0.0. But as Kevin said, we still have 0.13.3 in Fedora, so... Aha - right you are, thanks for the correction. cheers. -- Nathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: hiredis soname bump
Hi Kevin, On Mon, Jan 17, 2022 at 7:05 AM Kevin Fenzi wrote: > > Greetings. > > We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to > 1.0.2, which includes a soname bump. I think upstream may have reverted this change FWIW ... https://github.com/redis/hiredis/issues/990 cheers. -- Nathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Attempting to contact unresponsive maintainers: dkaspar flaper87
Hi there, On Mon, May 20, 2019 at 5:22 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, May 20, 2019 at 11:51:58AM +1000, Nathan Scott wrote: > > Please feel free to set default dstat BZ assignment to me in this case, > > Kevin. > > I don't think you want this package. dstat was (supposed to be) > retired in favour of pcp-dstat. Maybe the retirement wasn't complete? Yes, the old dstat package was retired. I'm one of the maintainers of pcp-dstat(1) which provides the /usr/bin/dstat symlink now. Users are still opening BZs against the dstat though (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1711517 today) so they may as well come to me. cheers. -- Nathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attempting to contact unresponsive maintainers: dkaspar flaper87
Please feel free to set default dstat BZ assignment to me in this case, Kevin. On Tue, May 14, 2019 at 5:21 PM Lukas Nykryn wrote: > > Hi, > sorry for late answer I was on PTO, > > David no longer works in Red HAt and he is not interested in maintaining > those packages anymore. > Could you please set the main admin of initscripts to me? And I don't think > we are interested in the rest of those packages. > > Lukas > > út 7. 5. 2019 v 23:18 odesílatel Kevin Fenzi napsal: >> >> I'd like to appologize for the delay in this email. >> >> The notices I get were being filtered and I didn't realize I wasn't >> seeing them for a while. ;( >> >> >> We've been told that the email addresses for these package maintainers >> are no longer valid. I'm starting the unresponsive maintainer policy to >> find out if they are still interested in maintaining their packages (and >> if so, have them update their email addresses in FAS). >> >> If they're not interested in maintaining or we can't locate them in 1 >> week, I'll have FESCo orphan the packages so that others can take them >> over. >> >> If you have a way to contact these maintainers, please let them know >> that we'd appreciate knowing what to do with their packages. Thanks! >> >> dkaspar: >> >> "dstat": "dkaspar", >> "initscripts": "dkaspar", >> "mtools": "dkaspar", >> "tcsh": "dkaspar", >> >> flaper87: >> >> "redis": "flaper87", >> >> >> Thanks, >> >> kevin >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attempting to contact unresponsive maintainers: dkaspar flaper87
Hi Kevin, On Wed, May 8, 2019 at 7:18 AM Kevin Fenzi wrote: > [...] > flaper87: > > "redis": "flaper87", I've been doing the Redis Fedora and EPEL updates for a few years now, I'm happy to take this one on. cheers. -- Nathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy regarding service preset enabled (e.g. performance co-pilot)
Hi Georg,
On Sun, Feb 10, 2019 at 6:47 AM Georg Sauthoff wrote:
> [...]
> I'm asking because installing the dstat replacement[1] in Fedora 29
> resulted in 3 additional always running systemd services[2] and 2 open
> ports.
The new dstat script resides in the pcp-system-tools sub-package of
PCP. This package depends on python3, python3-pcp and pcp-libs. None
of these packages contain systemd services.
For folks who are new to PCP, the quick start guide describes the
optional services and some of the tools:
https://pcp.io/docs/guide.html
I wonder if you have installed the (optional) pcp-zeroconf package,
Georg? This is a convenience package which automates setup of
frequently needed PCP services for use in customer support situations.
You do not need to install this package to use dstat.
The new dstat does not require running services, by default it runs in
a standalone fashion.
However, you can choose to run it as, e.g.:
$ pcp --host acme.com dstat
and it will sample metrics from pmcd(1) on remote host acme.com. If
you do choose to run the pmlogger(1) service locally, you can use the
new dstat on historical data as well, e.g.:
$ pcp --archive 20190209 --start 2:15pm dstat --time --cpu --disk 2 10
But these are new features missing from the old dstat that are
non-default (i.e. only available if these optional PCP services are
running). The choice is yours.
> Perhaps it's just me, but having 3 services enabled after installing the
> dstat replacement ('which strives for 100% output compatibility with the
> original dstat') feels like a violation of the principle of least
> astonishment.
Agreed - that's why the code is written the way it is, and the
packages are structured the way they are. It is not the case that you
need to have 3 additional services running when using the new dstat.
cheers.
--
Nathan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Redis 5.0 in testing
Hi all, Quick note to mention the Redis 5.0 release builds are available in testing now for all current Fedora versions. This release is backward compatible with the 4.x series and adds a series of new features: https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES I've been running the release candidate snapshots for several months and all is well here - let us know if you run into any issues though. cheers. -- Nathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Redis modules license change and the 'GoodFORM' project
Hi all, This is a general notice about the 'Apache Commons Clause' license change affecting several Redis Labs modules. In Fedora today the 'rejson' and 'rebloom' packages are affected. https://fedoraproject.org/wiki/Licensing:Main#License_Changes After much discussion, the Debian maintainer (of a similarly re-licensed module) and I have decided to collaborate on maintaining forks of the last open versions of these modules. https://goodformcode.com/ Any support you can show would be much appreciated - thanks! cheers. -- Nathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
