rpmautospec issue - RPMAUTOSPEC: unresolvable merge

[Leigh Scott]

How do you fix this?

Changelog   * Fri May 02 2025 Leigh Scott  - 
0.6.0-11
- RPMAUTOSPEC: unresolvable merge

https://koji.fedoraproject.org/koji/buildinfo?buildID=2708589
-- 
___
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: updates for "Change: Replace Redis with Valkey"

[deepika Sharma]

The change to replace Redis with Valkey is primarily motivated by licensing and 
community support concerns. Redis recently moved to a more restrictive 
source-available license (RSAL), which has implications for open-source use and 
integration into certain ecosystems. In contrast, Valkey is a community-driven 
fork of Redis that remains under the permissive BSD 3-Clause License, ensuring 
continued openness and broad compatibility.

Functionally, Valkey is a drop-in replacement for Redis and maintains full 
protocol and data format compatibility, making the migration relatively low 
risk. It is backed by many of the same contributors and aims to preserve 
Redis’s performance and reliability, while encouraging broader collaboration 
under a truly open license.

This change positions our stack to remain open-source friendly and avoids 
future licensing uncertainty, without sacrificing performance or functionality.

https://www.travell.co/
-- 
___
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: Any Ruby folks interested in bringing back Taskjuggler?

[Benson Muite]

On Wed, Apr 30, 2025, at 4:47 PM, Ankur Sinha wrote:
> On Tue, Apr 29, 2025 13:44:05 +0200, Vít Ondruch wrote:
>> Seems this is the failing test suite, right?
>> https://download.copr.fedorainfracloud.org/results/ankursinha/rubygem-taskjuggler/fedora-rawhide-x86_64/08910683-rubygem-taskjuggler/builder-live.log.gz
>> Given the test case name:
>> 
>> ~~~
>> 
>>   2) TaskJuggler::StatusSheetTest TaskJuggler::StatusSheetSender should have
>> generated 1 mail
>> 
>> ~~~
>> And comparing with the last know Fedora version of the .spec:
>> 
>> https://src.fedoraproject.org/rpms/rubygem-taskjuggler/blob/20c97f4e0dbf3e5af96bb0688ef8256d467fe0e4/f/rubygem-taskjuggler.spec
>> 
>> Isn't the `BuildRequires: rubygem(mail)` what is missing?
>> 
>> And yes, there seems to be two parts of the test suite, one using
>> rubygem-rspec while the other seems to be using rubygem-test-unit (yes, the
>> former .spec file tried to convert the test suite to be executed by
>> Minitest, but don't do that, stay with rubygem-test-unit and save some
>> troubles to you). Executing the test/all.rb for the latter should be enough.
>
> I've disabled the tests at the moment, so that'll be the first thing
> I'll be working on for the re-review.

It builds with that patch.  With missing deps packaged, tests run and pass:
https://copr.fedorainfracloud.org/coprs/fed500/rubygem-taskjuggler/builds/

>
> The new version, 3.8.1, is out, and that's what the COPR is at. There
> are a few niggles with Ruby 3.4 at the moment from the looks of it[1],
> but upstream is responsive and aware, so they should be fixed soon. I
> did look into them, but they were beyond my limited Ruby-fu, so if any
> Ruby pros want to take a look and submit fixes upstream, that'll be
> great too:
>
> https://github.com/taskjuggler/TaskJuggler/issues/303
>
-- 
___
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: Bugs that maintainers don't respond to

[Leigh Scott]

Since abrt was added to fedora I barely bother looking at them, they rarely 
include steps to reproduce the issue.
auto-closing old bugs is the best way to clear the trash.
-- 
___
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: rpmautospec issue - RPMAUTOSPEC: unresolvable merge

[Luya Tshimbalanga]

On 2025-05-03 00:55, Leigh Scott wrote:

How do you fix this?

Changelog   * Fri May 02 2025 Leigh Scott - 
0.6.0-11
- RPMAUTOSPEC: unresolvable merge

https://koji.fedoraproject.org/koji/buildinfo?buildID=2708589

See

docs.pagure.org

Peculiarities of rpmautospec — rpmautospec documentation <#>

🔗 https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html 



To resolve this manually, take the applicable parts of the changelog 
from the affected branches before the merge and put them in the 
|changelog| file.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer



OpenPGP_0x529982C2682F5484.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
___
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: rpmautospec issue - RPMAUTOSPEC: unresolvable merge

[Leigh Scott]

Thanks, that fixed it.
-- 
___
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

Bugs that maintainers don't respond to

[Chris Adams]

What do you do with bugs that never get addressed in any way?  I've got
a few bugs that I've been testing and rolling over to newer Fedora
releases for years, with little or no maintainer response (not even
bothering to CLOSE WONTFIX).  It's still a bug, so I don't like to close
it... but if nobody else cares, maybe I shouldn't either.

Seems like there needs to be some kind of better process than just
auto-closing old bugs.  If the maintainer doesn't feel like closing
them, maybe packages should just be orphaned and retired.
-- 
Chris Adams 
-- 
___
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: Bugs that maintainers don't respond to

[Fabio Valentini]

On Sat, May 3, 2025 at 7:15 PM Miroslav Suchý  wrote:
>
> Dne 03. 05. 25 v 4:33 odp. Chris Adams napsal(a):
> > What do you do with bugs that never get addressed in any way?  I've got
> > a few bugs that I've been testing and rolling over to newer Fedora
> > releases for years, with little or no maintainer response (not even
> > bothering to CLOSE WONTFIX).  It's still a bug, so I don't like to close
> > it... but if nobody else cares, maybe I shouldn't either.
> >
> > Seems like there needs to be some kind of better process than just
> > auto-closing old bugs.  If the maintainer doesn't feel like closing
> > them, maybe packages should just be orphaned and retired.
>
> Kernel has 1298 bugs in Fedora BZ. Many of them without comment. Does it make 
> kernel non-functional? Does it mean that
> maintainer(s) does not care about the package? Should the package be retired? 
> No. Definitely no.

Note that the bugzilla assignee for the "kernel" package seems to be a
deactivated bugzilla account, since a few months ago, so it's unclear
whether anybody is even getting notifications for bugs filed against
the package.

Fabio
-- 
___
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: Bugs that maintainers don't respond to

[Miroslav Suchý]

Dne 03. 05. 25 v 4:33 odp. Chris Adams napsal(a):

What do you do with bugs that never get addressed in any way?  I've got
a few bugs that I've been testing and rolling over to newer Fedora
releases for years, with little or no maintainer response (not even
bothering to CLOSE WONTFIX).  It's still a bug, so I don't like to close
it... but if nobody else cares, maybe I shouldn't either.

Seems like there needs to be some kind of better process than just
auto-closing old bugs.  If the maintainer doesn't feel like closing
them, maybe packages should just be orphaned and retired.


Kernel has 1298 bugs in Fedora BZ. Many of them without comment. Does it make kernel non-functional? Does it mean that 
maintainer(s) does not care about the package? Should the package be retired? No. Definitely no.


When there is no comment from the maintainer it usually means they do not have time. For that specific report. Day has 
24 hours and people have various priorities.


About closing the bugs... I tried various aproaches as maintainer. Closing the bugs as CLOSE WONTFIX. And people told me 
"why you are doing that? Somebody else may work on that. Please leave it open." I left the bugs open. And people told me 
that I should CLOSE as WONTFIX so there is no false hope that it will be fixed in near future. Autoclosing bugs when the 
Fedora EOL is good compromise for me.


If the bug is priority for you than you can either fix it, provide help, or provide motivation for maintainer. Liberapay 
or an alternative is good motivation https://alternativeto.net/software/liberapay/ I did it myself for bugs that were 
painful for me in the past.



--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

--
___
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: Bugs that maintainers don't respond to

[Kevin Fenzi]

On Sat, May 03, 2025 at 09:33:01AM -0500, Chris Adams wrote:
> What do you do with bugs that never get addressed in any way?  I've got
> a few bugs that I've been testing and rolling over to newer Fedora
> releases for years, with little or no maintainer response (not even
> bothering to CLOSE WONTFIX).  It's still a bug, so I don't like to close
> it... but if nobody else cares, maybe I shouldn't either.
> 
> Seems like there needs to be some kind of better process than just
> auto-closing old bugs.  If the maintainer doesn't feel like closing
> them, maybe packages should just be orphaned and retired.

The problem is that this is nuanced. There's probibly not one process we
could have that would not be bad in some cases. There's a variety of
reasons bugs are unanswered, some of which doesn't mean the
maintainer(s) aren't maintaining.

That said at a high level I would say these may be useful approaches:

* If the bug is a packaging one, perhaps make a PR to fix?
If you do, update the bug that there is a PR and try and keep the
PR up to date. I suspect many maintainers would be willing to merge in
a pr that fixes something if it's not too much extra work for them.

* a PR also could help in the case of a new upstream release.
Do the PR with the new version and some legwork to make sure it works
and doesn't break other things. Mass prebuilds could help the
maintainer know it's good to merge.

* If the bug isn't a packaging one, perhaps try engaging with upstream?
If the bug is known/fixed there it would get pulled in the next release
hopefully...

Its a hard balance. There's way more bugs than people to fix them, so
sometimes there's no good answer.

kevin
-- 
___
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: updates for "Change: Replace Redis with Valkey"

[Samuel Sieb]

On 5/3/25 9:29 PM, Robby Callicotte via devel wrote:

On Saturday, May 3, 2025 2:38:25 AM Central Daylight Time deepika Sharma
wrote:
The redis folks have recently moved away from their source-available license
(RSAL) in favor of AGPLv3[1] for Redis 8.  Just wanted to point this out.  I
don't think it should change our strategy though.  We should move forward with
Valkey.


That message was spam.  Someone copied a very old message and added a 
url (which you included again).


--
___
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

Unannounced / uncoordinated soname bump: magma

[Fabio Valentini]

Hi all,

The update to magma 2.9.0 that landed in rawhide a few hours ago
bumped the soname for libmagma.so (from `libmagma.so.2.8.0()(64bit)`
to `libmagma.so.2.9.0()(64bit)`) which was not announced or
coordinated with dependent packages.

The only directly impacted package seems to be "python-torch", which
is now not installable in rawhide (also rendering any package that
Requires python3-torch not installable, and any package that
BuildRequires python3-torch not buildable).

Looks like rebuilding python-torch against magma 2.9.0 should fix this
issue. Maintainers for magma and python-torch are CCd on this email.

Fabio
-- 
___
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

Fedora eln compose report: 20250504.n.0 changes

[Fedora ELN Report]

OLD: Fedora-eln-20250503.n.0
NEW: Fedora-eln-20250504.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   7
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   12.07 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   170.60 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  cpuinfo-24.09.26-2.git1e83a2f.eln148.1
Old package:  cpuinfo-24.09.26-1.git1e83a2f.eln146.1
Summary:  A library to detect information about host CPU
RPMs: cpuinfo
Size: 44.27 KiB
Size change:  1.04 KiB
Changelog:
  * Sat May 03 2025 Tom Rix  - 24.09.26-2.git1e83a2f.1
  - Move license to main package


Package:  enchant2-2.8.4-1.eln148
Old package:  enchant2-2.8.2-6.eln147
Summary:  An Enchanting Spell Checking Library
RPMs: enchant2 enchant2-devel enchant2-voikko
Size: 473.06 KiB
Size change:  25.56 KiB
Changelog:
  * Sat May 03 2025 Sandro Mani  - 2.8.4-1
  - Update to 2.8.4


Package:  ibus-typing-booster-2.27.46-1.eln148
Old package:  ibus-typing-booster-2.27.42-1.eln147
Summary:  A completion input method
RPMs: ibus-typing-booster
Size: 1.33 MiB
Size change:  57.75 KiB
Changelog:
  * Sat May 03 2025 Mike FABIAN  - 2.27.46-1
  - Update to 2.27.46
  - Add support for .bz2 and .xz to opening files for emoji data
  - Do not add useless dictionary match labels (or flags) (Resolves:
https://github.com/mike-fabian/ibus-typing-booster/issues/702)
  - Load also the Unikemet.txt file from UCD (if available)
  - emoji_picker.py: Improve argument parsing, add --spellcheck option
  - Also match against the Unicode block names from Block.txt
  - Migrate test_0_gtk.py from Gtk.main() to GLib.MainLoop()
  - The search entries for adding dictionaries, inputmethods, and
autosettings should grab focus immediately when the popover is shown
  - Reduce match_limit in emoji-picker by default to 1_000 again but add a
--match-limit command line option
  - Load also the NameAliases.txt file from UCD
  - Load also the old Unicode 1.0 name from UnicodeData.txt (Resolves:
https://github.com/mike-fabian/ibus-typing-booster/issues/698)
  - Migrate from Gtk.main() to GLib.MainLoop() (Resolves:
https://github.com/mike-fabian/ibus-typing-booster/issues/699)
  - Translation update from Weblate (kab 75.5%, zh_TW 100%)


Package:  iptables-1.8.11-8.eln148
Old package:  iptables-1.8.11-7.eln147
Summary:  Tools for managing Linux kernel packet filtering capabilities
RPMs: iptables-devel iptables-legacy iptables-legacy-devel 
iptables-legacy-libs iptables-libs iptables-nft iptables-services iptables-utils
Size: 3.02 MiB
Size change:  1.58 KiB
Changelog:
  * Sat May 03 2025 Phil Sutter  - 1.8.11-8
  - Revert last release, it breaks alternatives symlinks


Package:  perl-CryptX-0.086-1.eln148
Old package:  perl-CryptX-0.085-1.eln146
Summary:  Cryptographic toolkit
RPMs: perl-CryptX
Size: 2.98 MiB
Size change:  32.94 KiB
Changelog:
  * Sat May 03 2025 Xavier Bachelot  - 0.086-1
  - Update to 0.086 (RHBZ#2363852, RHBZ#2354493)


Package:  python-chardet-5.2.0-18.eln148
Old package:  python-chardet-5.2.0-16.eln145
Summary:  Python character encoding detector
RPMs: python3-chardet
Size: 298.41 KiB
Size change:  -359 B
Changelog:
  * Sat May 03 2025 Benjamin A. Beasley  - 5.2.0-17
  - Update .rpmlintrc file for current rpmlint

  * Sat May 03 2025 Benjamin A. Beasley  - 5.2.0-18
  - F41+: Use the provisional pyproject declarative buildsystem


Package:  python-pip-25.1.1-1.eln148
Old package:  python-pip-25.1-1.eln148
Summary:  A tool for installing and managing Python packages
RPMs: python-pip-wheel python3-pip
Size: 3.95 MiB
Size change:  52.09 KiB
Changelog:
  * Sat May 03 2025 Miro Hron??ok  - 25.1-4
  - Stop building the HTML documentation, only build manual pages
  - Also build manual pages on RHEL
  - The python-pip-doc package is gone but not Obsoleted, it has no
dependencies

  * Sat May 03 2025 Miro Hron??ok  - 25.1.1-1
  - Update to 25.1.1
  - Fixes: rhbz#2363801



= DOWNGRADED PACKAGES =
-- 
___
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: updates for "Change: Replace Redis with Valkey"

[Robby Callicotte via devel]

On Saturday, May 3, 2025 2:38:25 AM Central Daylight Time deepika Sharma 
wrote:
> The change to replace Redis with Valkey is primarily motivated by licensing
> and community support concerns. Redis recently moved to a more restrictive
> source-available license (RSAL), which has implications for open-source use
> and integration into certain ecosystems. In contrast, Valkey is a
> community-driven fork of Redis that remains under the permissive BSD
> 3-Clause License, ensuring continued openness and broad compatibility.
 
> Functionally, Valkey is a drop-in replacement for Redis and maintains full
> protocol and data format compatibility, making the migration relatively low
> risk. It is backed by many of the same contributors and aims to preserve
> Redis’s performance and reliability, while encouraging broader
> collaboration under a truly open license.
 
> This change positions our stack to remain open-source friendly and avoids
> future licensing uncertainty, without sacrificing performance or
> functionality.
 
> https://www.travell.co/

The redis folks have recently moved away from their source-available license 
(RSAL) in favor of AGPLv3[1] for Redis 8.  Just wanted to point this out.  I 
don't think it should change our strategy though.  We should move forward with 
Valkey.

[1] - https://redis.io/blog/agplv3/

--
Robby Callicotte



-- 
___
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: apcupsd: co-maintainers needed

[Germano Massullo]

I added you as admin. Thank you
--
___
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